关系型数据库的范式理解-小记
关系型数据库的范式理解-小记
范式的理解,可以说是在数据库表设计时遵循的规范,这些规范有不同的级别。不同级别就对应不同的范式。
1.第一范式(1NF)
数据库表的每个属性都是原子项,内容不可分割。也就是说每个列的内容保持原子性,不可再划分,即属性不可分割。
不符合1NF的表设计:
id | 名字 | 联系方式 |
---|---|---|
1 | 小乔 | 123@gmail.com,18878051234 |
2 | 大乔 | 456@gmail.com,18878051235 |
3 | 安琪拉 | 789@gmail.com,18878051236 |
上面的表格中联系方式字段“123@gmail.com,18878051234”就没有保持原子性,还可以分割为两种,所以不符合第一范式。修改后,符合1NF的样子应该如下:
符合1NF的表设计:
id | 名字 | 邮箱 | 电话 |
---|---|---|---|
1 | 小乔 | 123@gmail.com | 18878051234 |
2 | 大乔 | 456@gmail.com | 18878051235 |
3 | 安琪拉 | 789@gmail.com | 18878051236 |
这里每列的内容都是不可分割的,内容都保持了原子性,遵守了关系型数据库的第一范式。
2.第二范式(2NF)
第二范式(2NF)必须先满足第一范式(1NF)。第二范式要求记录不重复,即要有主键(或组合主键),要求其他字段都依赖于整个主键,而不是仅仅依赖主键的一部分。
不符合2NF的表设计:比赛成绩表
id | 名字 | 比赛类型 | 成绩-助攻数 |
---|---|---|---|
1 | 小乔 | 五人匹配 | 5 |
2 | 大乔 | 人机 | 10 |
3 | 安琪拉 | 1VS1 | 7 |
上面的表可以看到,成绩是由id和比赛类型决定的,玩一局游戏的助攻数,肯定是要明确是谁在哪一场比赛的成绩,“id-比赛类型”组成了这个表的主键。但是人物名字只需要id就可以确定了,并不需要整个组合主键“id-比赛类型”来决定,所以这个表不符合2NF。 |
符合2NF的表设计:
(1)比赛成绩表
id | 比赛类型 | 成绩-助攻数 |
---|---|---|
1 | 五人匹配 | 5 |
2 | 人机 | 10 |
3 | 1VS1 | 7 |
(2)人物表
id | 名字 |
---|---|
1 | 小乔 |
2 | 大乔 |
3 | 安琪拉 |
3.第三范式(3NF)
满足第三范式(3NF)必须先满足第二范式(2NF)。
第三范式就是非主键列必须直接依赖于主键,不能存在传递依赖。即不能存在非主键列A依赖于非主键列B,非主键列B依赖于主键的情况。
通俗一点,就是在其他表中的信息不能重复出现,如果出现则要求这个信息是其他表的主键(在本表就是“外键”)。
不符合3NF的表设计:
id | 名字 | 老公 | 老公姑妈 | 老公姑妈的外公 |
---|---|---|---|---|
1 | 小乔 | 周瑜 | 周姑妈 | 周姑妈外公 |
2 | 大乔 | 孙策 | 孙姑妈 | 孙姑妈外公 |
3 | 孙尚香 | 刘备 | 刘姑妈 | 刘姑妈外公 |
显然上面的表中有一个关系链,3NF里面不允许存在传递的关系。比如第一行,名字小乔依赖于逐渐id,老公周瑜只依赖于id,这都是没问题的,但是后面周姑妈就仅依赖于非主键列周瑜,不依赖主键id,这是不符合3NF的。 |
符合3NF的表设计:
(1)人物关系表1
id | 名字 | 老公 |
---|---|---|
1 | 小乔 | 周瑜 |
2 | 大乔 | 孙策 |
3 | 孙尚香 | 刘备 |
(2)人物关系表2
id | 老公名字 | 老公姑妈 |
---|---|---|
1 | 周瑜 | 周姑妈 |
2 | 孙策 | 孙姑妈 |
3 | 刘备 | 刘姑妈 |
(3)人物关系表3
|id|姑妈名字|姑妈的外公|
|---|---|---|---|
|1|周姑妈|周姑妈外公|
|2|孙姑妈|孙姑妈外公|
|3|刘姑妈|刘姑妈外公|
划分之后每个表的每行的内容都没有传递关系,而且仅依赖于主键,不依赖非主键。
注意:第二范式(2NF)和第三范式(3NF)的概念很容易混淆,区分关键点
-
2NF:非主键列完全依赖于主键,不能依赖于主键的一部分。
-
3NF:非主键列是直接依赖于主键,还是直接依赖于非主键列。