关系型数据库的范式理解-小记

范式的理解，可以说是在数据库表设计时遵循的规范，这些规范有不同的级别。不同级别就对应不同的范式。

1.第一范式(1NF)

数据库表的每个属性都是原子项，内容不可分割。也就是说每个列的内容保持原子性，不可再划分，即属性不可分割。

不符合1NF的表设计：

上面的表格中联系方式字段“123@gmail.com,18878051234”就没有保持原子性，还可以分割为两种，所以不符合第一范式。修改后，符合1NF的样子应该如下：

符合1NF的表设计：

这里每列的内容都是不可分割的，内容都保持了原子性，遵守了关系型数据库的第一范式。

第二范式（2NF）必须先满足第一范式（1NF）。第二范式要求记录不重复，即要有主键（或组合主键），要求其他字段都依赖于整个主键，而不是仅仅依赖主键的一部分。

不符合2NF的表设计：比赛成绩表

id	名字	比赛类型	成绩-助攻数
1	小乔	五人匹配	5
2	大乔	人机	10
3	安琪拉	1VS1	7

上面的表可以看到，成绩是由id和比赛类型决定的，玩一局游戏的助攻数，肯定是要明确是谁在哪一场比赛的成绩，“id-比赛类型”组成了这个表的主键。但是人物名字只需要id就可以确定了，并不需要整个组合主键“id-比赛类型”来决定，所以这个表不符合2NF。

符合2NF的表设计：

（1）比赛成绩表

（2）人物表

满足第三范式（3NF）必须先满足第二范式（2NF）。

第三范式就是非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在非主键列A依赖于非主键列B，非主键列B依赖于主键的情况。
通俗一点，就是在其他表中的信息不能重复出现，如果出现则要求这个信息是其他表的主键（在本表就是“外键”）。

不符合3NF的表设计：

id	名字	老公	老公姑妈	老公姑妈的外公
1	小乔	周瑜	周姑妈	周姑妈外公
2	大乔	孙策	孙姑妈	孙姑妈外公
3	孙尚香	刘备	刘姑妈	刘姑妈外公

显然上面的表中有一个关系链，3NF里面不允许存在传递的关系。比如第一行，名字小乔依赖于逐渐id，老公周瑜只依赖于id，这都是没问题的，但是后面周姑妈就仅依赖于非主键列周瑜，不依赖主键id，这是不符合3NF的。

符合3NF的表设计：

（1）人物关系表1

(2)人物关系表2

（3)人物关系表3

划分之后每个表的每行的内容都没有传递关系，而且仅依赖于主键，不依赖非主键。

注意：第二范式（2NF）和第三范式（3NF）的概念很容易混淆，区分关键点