本文摘要：数据库设计中，三大范式（1NF、2NF、3NF）是确保表结构合理、消除冗余和异常的基础原则。第一范式要求列不可再分，确保原子性；第二范式要求非主键属性与主键整体相关，避免部分依赖，提倡通过外键关联两张表以减少冗余字段；第三范式强调非主键属性直接依赖于主键，不允许传递依赖，以防止数据冗余、插入异常、删除异常及更新异常。实际应用时，为优化查询效率，可能需要灵活变通，允许一定程度的冗余存在。理解函数依赖（包括部分函数依赖、完全函数依赖、传递函数依赖）对正确运用三大范式至关重要。

转载文章

本篇文章为转载内容。原文链接：https://blog.csdn.net/weixin_45204159/article/details/115282254。

该文由互联网用户投稿提供，文中观点代表作者本人意见，并不代表本站的立场。

作为信息平台，本站仅提供文章转载服务，并不拥有其所有权，也不对文章内容的真实性、准确性和合法性承担责任。

如发现本文存在侵权、违法、违规或事实不符的情况，请及时联系我们，我们将第一时间进行核实并删除相应内容。

数据库三大范式

无规矩不成方圆， 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

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

例如：
$C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1616914918020.png$
这张表中 “部门岗位“ ”应该拆分成两个字段：==》 “部门名称”、“岗位”。

在这里插入图片描述

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

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

例如下表：

在这里插入图片描述

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

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

在这里插入图片描述

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

例如：

在这里插入图片描述

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

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

数据冗余：“部门名称”多次重复出现。
插入异常：组建一个新部门时没有员工信息，也就无法单独插入部门信息。就算强行插入部门信息，员工表中没有员工信息的记录同样是非法记录。
删除异常：删除员工信息会连带删除部门信息导致部门信息意外丢失。
更新异常：哪怕只修改一个部门的名称也要更新多条员工记录。

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

在这里插入图片描述

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

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

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

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

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

本篇文章为转载内容。原文链接：https://blog.csdn.net/weixin_45204159/article/details/115282254。

该文由互联网用户投稿提供，文中观点代表作者本人意见，并不代表本站的立场。

作为信息平台，本站仅提供文章转载服务，并不拥有其所有权，也不对文章内容的真实性、准确性和合法性承担责任。

如发现本文存在侵权、违法、违规或事实不符的情况，请及时联系我们，我们将第一时间进行核实并删除相应内容。

名词解释

作为当前文章的名词解释，仅对当前文章有效。

第一范式（1NF）：在数据库设计中，第一范式是关系型数据库规范化的基本要求。它规定了数据库表中的每一列（字段）都必须是不可再分的原子值，确保数据的原子性。这意味着每个字段只能存储一个独立的数据项，而不能包含多个值或子值。

传递函数依赖：在关系数据库理论中，传递函数依赖是指存在属性集合X、Y和Z，若满足X→Y（即通过X可以唯一确定Y），同时满足Y→Z（即通过Y可以唯一确定Z），则称Z传递函数依赖于X。换句话说，如果一个非主属性能通过其他非主属性间接推导出来，则称为传递函数依赖。

联合主键：联合主键是用于标识数据库表中唯一记录的一组字段，不同于单个字段作为主键的情况。在满足第二范式时，当单个字段无法唯一标识表中的每一条记录时，就需要选择两个或更多的字段组成一个复合键来共同作为主键，这些字段的组合必须能够唯一地识别表中的每一个行记录。

数据冗余：在数据库设计中，数据冗余是指相同的数据信息在数据库的不同位置重复出现的现象。冗余可能导致数据不一致性和维护困难，如更新异常（修改一处数据需要同步多处）、插入异常（添加新记录时可能因依赖冗余数据导致无法插入）和删除异常（删除某条记录时可能会连带丢失其他相关但非冗余的信息）等问题。

第二范式（2NF）：在关系数据库设计中，第二范式是在满足第一范式的基础上，要求非主键属性完全依赖于整个主键，而不是主键的一部分。这意味着所有非主键属性必须与主键直接关联，不允许存在部分依赖，从而消除数据冗余和更新异常的风险。

外键：外键是一个表中引用另一个表的主键的字段，用以建立两个表之间的关联关系。在遵循第二范式的设计中，通常会将原本冗余的信息分解到另一张表中，并通过外键来实现两个表间数据的关联查询，从而避免在单一表中保存冗余字段，保证数据一致性并降低数据冗余程度。

[转载]MySQL三大范式 举例说明，通俗易懂

数据库三大范式

前置知识：

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

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

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

[转载]MySQL三大范式举例说明，通俗易懂

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

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