文章目录
- 简介
- 第一范式
- 第二范式
- 第三范式:
简介
在MySQL的使用中, 要根据实际灵活设计表,一般来说我们通常遵循三大范式(啥是范式:是一些约束、规范、规则, 来优化数据库表的设计和存储),三大范式之间是一级一级依赖的,第二范式建立在第一范式上,第三范式建立第一第二范式上。
 
 
第一范式
第一范式:列不可再分
第一范式遵循原子性:数据表中的列数据都像原子一样不可再分。
 举例子理解:
| 姓名 | 爱好 | 
|---|---|
| 明星蔡徐坤 | 打篮球 | 
| 网红童锦程 | 开法拉利SF90 | 
| 程序员分才 | 996 | 
里面的数据还可以再分吗?
 
从数据中可以看出姓名列的数据可以明显分为职务和姓名,分好后:
| 姓名 | 爱好 | 职务 | 
|---|---|---|
| 蔡徐坤 | 打篮球 | 明星 | 
| 童锦程 | 开法拉利SF90 | 网红 | 
| 分才 | 996 | 程序员 | 
这样改是不是好多了。。。。
第二范式
行可以唯一区分
第二范式遵循唯一性:在第一范式的基础上,数据表的主键行的数据(或联合主键的数据)可以确定其他所有行的数据,满足主键约束。
| 姓名 | 爱好 | 职务 | 
|---|---|---|
| 蔡徐坤 | 打篮球 | 明星 | 
| 童锦程 | 开法拉利SF90 | 网红 | 
| 分才 | 996 | 程序员 | 
| 分才 | 开法拉利 | 程序员 | 
我们开始按照第二范式开始分析:
 如果以姓名作为主键,我们可以确定职务,但是无法确定爱好,就像不知道分才到底爱996还是爱开法拉利(SF90)。
 
 
所以说第二范式要求我们一张表只能干一件事。
 根据第二范式,我们可以将表拆分成两个表:
表1: 人员信息表 (Person)
| 姓名(主键) | 职务 | 
|---|---|
| 蔡徐坤 | 明星 | 
| 童锦程 | 网红 | 
| 分才 | 程序员 | 
表2: 爱好表 (Hobby)
| 爱好(主键) | 姓名(外键) | 
|---|---|
| 打篮球 | 蔡徐坤 | 
| 开法拉利SF90 | 童锦程 | 
| 996 | 分才 | 
| 开法拉利 | 分才 | 
第三范式:
表的非主键属性不能依赖与其他表的非主属性 ,满足外键约束
在数据库设计中,第三范式是关系数据库设计规范中的一个重要概念,它要求一个关系中的所有字段都只依赖于主键,而不依赖于其他非主键字段。这样可以避免数据冗余和数据插入异常。
开始有点难度了

举个例子来说明第三范式的概念:
假设我们有一个学生信息表(Students),其中包含以下字段:
- 学生ID(StudentID,主键)
- 学生姓名(StudentName)
- 学生年龄(StudentAge)
- 班级(Class)
- 班级老师(Teacher)
如果我们设计的表结构中存在这样的依赖关系:班级依赖于班级老师,即一个班级只能有一个班级老师,那么这个设计就不符合第三范式。
在这种情况下,应该将班级和班级老师分开成两个表,如下所示:
Students表:
- 学生ID(StudentID,主键)
- 学生姓名(StudentName)
- 学生年龄(StudentAge)
- 班级ID(ClassID,外键,关联Classes表)
Classes表:
- 班级ID(ClassID,主键)
- 班级(Class)
- 班级老师(Teacher)
通过将班级和班级老师分开成两个表,我们遵循了第三范式,确保了数据的一致性和避免了数据冗余。
当然在实际生活中我们要灵活应用,不是非要硬套公式。
建了一个公众号(名字叫音耀),后续会在上面更新一些有用资源和笔记,大家有兴趣的话可以加一下谢谢了。
