MySQL三大范式 举例说明，通俗易懂

数据库三大范式

​ 无规矩不成方圆， Java有很多的规范，设计模式有7大原则，数据库同样也有它的规范，按照规范来设计维护数据库是程序员必备的素质， 目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和 第五范式（5NF，又称“完美范式"）。

​ 这篇文章只介绍三大范式，三大范式是设计数据库表结构的规则约束，但是在实际中允许局部变通。比如为了快速查询到关联数据可能会允许冗余字段的存在。

---

前置知识：

1.部分函数依赖：

设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。

例如：通过AB能得出C，通过A也能得出C，通过B也能得出C，那么说C部分依赖于AB。

2.完全函数依赖

设X,Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y，则称Y完全函数依赖于X。

例如：通过AB能得出C，但是AB单独得不出C，那么说C完全依赖于AB.

3.传递函数依赖

设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。

例如：通过A得到B，通过B得到C，但是C得不到B，B得不到A，那么成C传递依赖于A

---

第一范式：数据库表中的每一列都不可以再拆分，也就是原子性

例如：

这张表中 “部门岗位“ ”应该拆分成两个字段：==》 “部门名称”、“岗位”。

这样才能专门针对“部门名称”或“岗位”进行查询。

---

第二范式：在满足第一范式基础上（原子性），要求 非主键 都和 主键 完整相关， 而不能是依赖于主键的一部分 （主要针对联合主键而言）| 消除非主键对主键的部分依赖

例如下表：

​ 使用“订单编号”和“产品编号”作为联合主键。此时 “产品价格”、“产品数量” 都和联合主键整体相关，但“订单金额”和“下单时间” 只和联合主键中的“订单编号”相关，和“产品编号”无关。所以只关联了主键中的部分字段，不满足第二范式。

​ 把“订单金额”和“下单时间”移到订单表才 符合第二范式

---

第三范式： 在第二范式的基础上，非主键列只依赖于主键，不依赖于其他非主键。 就是说表中的非主键字段和主键字段直接相关，不允许间接相关。

例如：

表中的“部门名称”和“员工编号”的关系应该是是 “员工编号”→“部门编号” →“部门名称”，

而这张表中不是直接相关。此时会带来下列问题：

• 数据冗余：“部门名称”多次重复出现。

• 插入异常：组建一个新部门时没有员工信息，也就无法单独插入部门 信息。就算强行插入部门信息，员工表中没 有员工信息的记录同样是 非法记录。

• 删除异常：删除员工信息会连带删除部门信息导致部门信息意外丢失。

• 更新异常：哪怕只修改一个部门的名称也要更新多条员工记录。

正确的做法应该是：把上表拆分成两张表，以外键形式关联

“部门编号”和“员工编号”是直接相关的。

第二范式的另一种表述方式是：两张表要通过外键关联，不保存冗余字段。例如：不能在“员工表”中存储“部门名称”。

“部门编号”和“员工编号”是直接相关的。

第二范式的另一种表述方式是：两张表要通过外键关联，不保存冗余字段。例如：不能在“员工表”中存储“部门名称”。

学会变通：有时候为了快速查询到关联数据可能会允许冗余字段的存在。例如在员工表中存储部门名称虽然违背第三范式，但是免去了对部门表的关联查询。