关系型数据库的范式理解-小记
范式的理解，可以说是在数据库表设计时遵循的规范，这些规范有不同的级别。不同级别就对应不同的范式。
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：非主键列是直接依赖于主键，还是直接依赖于非主键列。