Mysql技术文档--设计表规范式-一次性扫盲
阿丹：
在设计表的时候经常出现一些问题，其实自己很清楚就是因为在设计表的时候没有规范。导致后期加表的时候出现了问题。所以趁着这个假期卷一卷。同时只有在开始的时候
几大范式
在关系型数据库中，数据表设计的基本原则、规则就称为范式。
第一范式（1NF）
原文：
第一范式（1NF）数据库规范化的一种级别，它要求每个属性都是不可分的原子值，即每个属性都必须是不可分的最小数据单元。
解释/理解：
第一范式（1NF）是数据库设计的基础，它确保了每个数据表中的每个列都有唯一的含义，并且每个列都不能可分。这意味着每个字段都是最小的数据单元，不能包含其他的数据单元。例如，如果一个表中的“地址”列包含了省份、城市、街道等多个信息，那么这个表就不符合第一范式。为了满足第一范式，需要将这种多信息列拆分为多个独立的列，每个列表示一个最小、不可分的数据单元。
举例：
假设有一个名为“用户信息”的表，其中包含用户的姓名、年龄、性别、地址等信息。如果该表中的“地址”列包含了省份、城市、街道等多个信息，那么这个表就不符合第一范式。为了满足第一范式，需要将“地址”列拆分为“省份”、“城市”和“街道”三个独立的列，每个列表示一个最小、不可分的数据单元。拆分后的表如下：
用户信息表：
| 列名 | 类型 |
|---|---|
| 姓名 | 字符串 |
| 年龄 | 整数 |
| 性别 | 字符串 |
| 省份 | 字符串 |
| 城市 | 字符串 |
| 街道 | 字符串 |
这个例子中，“地址”列被拆分为三个独立的列：“省份”、“城市”和“街道”，每个列都表示一个最小、不可分的数据单元。这样的表就满足了第一范式的要求。
第二范式（2NF）
原文：
第二范式（2NF）是数据库规范化的一种级别，它建立在第一范式的基础上，要求非主键列之间必须完全依赖于主键，而不是部分依赖。
解释/理解：
第二范式（2NF）是在第一范式的基础上进行的规范化，它要求非主键列之间必须完全依赖于主键，而不是部分依赖。在第一范式中，表中的每个列都是不可分的最小数据单元，而在第二范式中，非主键列之间必须是相互独立的，不能存在依赖关系。
举例：
假设有一个名为“订单”的表，其中包含订单号、客户号、日期、商品数量等信息。该表中有一个主键为订单号和客户号，即每个订单都有一个唯一的订单号和客户号。现在考虑一个场景，需要查询某个客户的所有订单信息。在第二范式之前的设计中，我们可能需要一个单独的“订单”表来存储订单信息，然后使用一个外键来关联“订单”表和“客户”表。这样做的缺点是会产生大量的数据冗余，因为每个订单都需要在“订单”表中单独存储一份数据，而且如果某个客户的订单数量很大，那么“客户”表中就会包含很多冗余数据。
为了解决这个问题，我们可以将“订单”表拆分为两个表：“订单信息”表和“订单详情”表，“订单信息”表中包含订单号、客户号和日期等基本信息，而“订单详情”表中则包含每个订单的商品数量等信息。这样设计的好处是避免了数据冗余，同时也能更好地满足查询需求。
通过将表拆分为两个表，我们可以更好地组织数据，减少数据冗余并提高查询效率。同时，由于每个表中的列都是不可分的最小数据单元，因此也避免了数据不一致性的问题。
第三范式（3NF）
原文：
第三范式（3NF）是数据库规范化的一种级别，它建立在第二范式的基础上，要求非主键列之间必须相互独立，不存在传递依赖关系。
解释/理解：
第三范式（3NF）是在第二范式的基础上进行的规范化，它要求非主键列之间必须相互独立，不存在传递依赖关系。在第二范式中，非主键列之间必须是相互独立的，不能存在依赖关系，而第三范式则更进一步，要求非主键列之间不能存在传递依赖关系。
举例：
假设有一个名为“员工薪资”的表，其中包含员工号、姓名、薪资、所属部门等信息。该表的主键为员工号和姓名，即每个员工都有一个唯一的员工号和姓名。现在考虑一个场景，需要查询某个部门的所有员工的薪资情况。在第二范式之前的设计中，我们可能需要一个单独的“员工薪资”表来存储员工薪资信息，然后使用一个外键来关联“员工薪资”表和“员工”表。这样做的话，会产生大量的数据冗余，因为每个员工都需要在“员工薪资”表中单独存储一份数据。而且如果某个部门的员工数量很大，那么“员工薪资”表中就会包含很多冗余数据。
为了解决这个问题，我们可以将“员工薪资”表拆分为两个表：“员工信息”表和“薪资信息”表，“员工信息”表中包含员工号、姓名和所属部门等基本信息，而“薪资信息”表中则包含每个员工的薪资信息。这样设计的好处是避免了数据冗余，同时也能更好地满足查询需求。
通过将表拆分为两个表，我们可以更好地组织数据，减少数据冗余并提高查询效率。同时，由于每个表中的列都是不可分的最小数据单元，因此也避免了数据不一致性的问题。
巴斯-科德范式（BCNF）
原文：
巴斯-科德范式（BCNF）是数据库规范化的一种级别，它要求每个非主键子集必须完全依赖于主键，而不是部分依赖。
解释/理解：
巴斯-科德范式（BCNF）是在第三范式的基础上进行的规范化，它要求每个非主键子集必须完全依赖于主键，而不是部分依赖。在第三范式中，非主键列之间不能存在传递依赖关系，而巴斯-科德范式则更加强调非主键子集与主键之间的依赖关系。
举例：
假设有一个名为“商品订单”的表，其中包含订单号、商品号、数量、客户号等信息。该表的主键为订单号和商品号，即每个订单都有一个唯一的订单号和商品号。现在考虑一个场景，需要查询某个客户的所有订单信息。在第三范式之前的设计中，我们可能需要一个单独的“商品订单”表来存储商品订单信息，然后使用一个外键来关联“商品订单”表和“客户”表。这样做的话，会产生大量的数据冗余，因为每个订单都需要在“商品订单”表中单独存储一份数据。而且如果某个客户的订单数量很大，那么“商品订单”表中就会包含很多冗余数据。
为了解决这个问题，我们可以将“商品订单”表拆分为两个表：“订单信息”表和“订单详情”表，“订单信息”表中包含订单号、客户号等基本信息，而“订单详情”表中则包含每个订单的商品号、数量等信息。这样设计的好处是避免了数据冗余，同时也能更好地满足查询需求。
通过将表拆分为两个表，我们可以更好地组织数据，减少数据冗余并提高查询效率。同时，由于每个表中的列都是不可分的最小数据单元，因此也避免了数据不一致性的问题。
第四范式(4NF）
原文：
第四范式（4NF）是数据库规范化的一种级别，它要求非主键子集之间不存在依赖关系，或者说每个非主键子集必须独立于其他非主键子集。
解释/理解：
第四范式（4NF）在巴斯-科德范式的基础上进一步强调非主键子集之间的相互独立性。在巴斯-科德范式中，每个非主键子集必须完全依赖于主键，而且相互之间没有依赖关系。而在第四范式中，进一步要求每个非主键子集之间不存在任何依赖关系，或者说每个非主键子集都是独立的，不依赖于其他非主键子集。
举例：
假设有一个名为“客户订单”的表，其中包含客户号、订单号、日期、商品号、数量等信息。该表的主键为客户号和订单号，即每个订单都有一个唯一的客户号和订单号。现在考虑一个场景，需要查询某个客户的所有订单信息，并显示每个订单的商品号和数量。在第四范式之前的设计中，我们可能需要在“客户订单”表中存储每个订单的商品号和数量，然后使用客户号和订单号作为主键来关联该表和其他表。这样做的话，会产生大量的数据冗余，因为每个订单都需要在“客户订单”表中单独存储一份数据。而且如果某个客户的订单数量很大，那么“客户订单”表中就会包含很多冗余数据。
为了解决这个问题，我们可以将“客户订单”表拆分为两个表：“订单信息”表和“订单详情”表，“订单信息”表中包含客户号、订单号、日期等基本信息，而“订单详情”表中则包含每个订单的商品号、数量等信息。这样设计的好处是避免了数据冗余，同时也能更好地满足查询需求。
通过将表拆分为两个表，我们可以更好地组织数据，减少数据冗余并提高查询效率。同时，由于每个表中的列都是不可分的最小数据单元，因此也避免了数据不一致性的问题。
第五范式（5NF，又称完美范式）
原文：
第五范式（5NF，又称完美范式）是数据库规范化的一种级别，它要求在第四范式的基础上，非主键子集之间不存在任何依赖关系，或者说每个非主键子集必须独立于其他所有非主键子集。
解释/理解：
第五范式（5NF）在第四范式的基础上进一步强调非主键子集之间的相互独立性。在第四范式中，每个非主键子集必须独立于其他非主键子集，不依赖于其他非主键子集。而在第五范式中，要求每个非主键子集之间不存在任何依赖关系，或者说每个非主键子集都是完全独立的，不依赖于其他任何非主键子集。
举例： 考虑一个订单管理系统的数据库设计。假设有一个名为“订单详情”的表，其中包含订单号、商品号、数量等信息。该表的主键为订单号和商品号，即每个订单详情都有一个唯一的订单号和商品号。现在考虑一个场景，需要查询某个客户的所有订单信息，并显示每个订单的商品号和数量。在第五范式之前的设计中，我们可能需要在“订单详情”表中存储每个订单的商品号和数量，然后使用订单号作为主键来关联该表和其他表。这样做的话，会产生大量的数据冗余，因为每个订单详情都需要在“订单详情”表中单独存储一份数据。而且如果某个客户的订单数量很大，那么“订单详情”表中就会包含很多冗余数据。
为了解决这个问题，我们可以将“订单详情”表拆分为两个表：“订单信息”表和“订单明细”表，“订单信息”表中包含订单号、日期等基本信息，而“订单明细”表中则包含每个订单的商品号、数量等信息。这样设计的好处是避免了数据冗余，同时也能更好地满足查询需求。
通过将表拆分为两个表，我们可以更好地组织数据，减少数据冗余并提高查询效率。同时，由于每个表中的列都是不可分的最小数据单元，因此也避免了数据不一致性的问题。