数据库设计的四大范式
前言
在日常的开发过程中，数据库作为数据存储和管理的核心组件，其设计质量直接影响数据处理的效率、数据的一致性和系统的可维护性，为了确保数据库数据的合理性和高效性，业界提出了一系列设计规范和标准，这些规范被统称为数据库设计范式。
目前，关系数据库设计主要遵循六大范式，从低到高依次为：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式（4NF）和第五范式（5NF，又称完美范式）。每一级范式都是在前一级范式的基础上进一步提出的，更高的范式意味着更低的冗余度和更高的数据独立性。常用的是四大范式。
四大范式
（1）第一范式
在关系模式中，当且仅当所有属性只包含原子值，即每个分量都是不可再分的数据项，则称满足1NF。
举例：
| 系名称 | 高级职称人数 |
|---|---|
| 计算机系 | 16 |
| 电子系 | 10 |
该表所示的教师职称情况关系就不满足1NF，原因在于，该关系模式中的“高级职称人数”不是一个原子属性，若将其拆分为“教授”和“副教授”两个属性，则就满足1NF。
| 系名称 | 教授 | 副教授 |
|---|---|---|
| 计算机系 | 6 | 10 |
| 电子系 | 5 | 5 |
（2）第二范式
当且仅当关系模式及满足1NF ， 且每个非键属性（即不属于任何候选键的属性，也称为非主属性）完全依赖于候选键时，则称满足2NF。
规则：
- 所有的非主属性都必须完全依赖于主键。
- 如果存在非主属性仅依赖于主键的一部分，则表不符合第二范式。
- 如果表的主键是单一字段，并且所有非主属性都完全依赖于该主键，则该表一定符合第二范式。
举例：
| 课程类型 | 课程ID | 课程名称 |
|---|---|---|
| 通识课 | 1 | 礼仪鉴赏 |
| 文学 | 2 | 大学语文 |
| 数学 | 3 | 高等数学 |
| 通识课 | 4 | 插花艺术 |
| 数学 | 5 | 数值分析 |
在这个例子中，主键是“课程类型”和“课程ID”的组合，因为它们一起能够唯一地标识表中的每一行。非主属性是“课程名称”。我们可以看到，“课程名称”完全依赖于主键（即“课程类型”和“课程ID”的组合），而不是仅依赖于主键的一部分。因此，这个表符合第二范式。符合第二范式的设计可以减少数据冗余、避免更新异常、插入异常和删除异常。如果一个表不符合第二范式，可能会导致数据在多个地方被重复存储，从而增加数据维护的复杂性和出错的可能性。通过将不符合第二范式的表进行拆分，可以使得每个表都更加专注于存储一组相关的数据，从而提高数据的独立性和一致性。
（3）第三范式
当且仅当关系模式R满足1NF ，且R中没有非键属性传递依赖于候选键时，则称满足3NF。
第三范式（Third Normal Form，简称3NF）是数据库设计中的一种重要规范化标准，它是在第二范式（2NF）的基础上进一步提出的。第三范式要求一个数据库表中，非主键列必须直接依赖于主键，而不能存在传递依赖。这意味着表中的每一列都直接和主键相关，而不是通过其他非主键列间接相关。
规则：
- 非主键列必须直接依赖于主键。
- 如果存在非主键A依赖于非主键B，并且B依赖于主键，那么实际上A对主键存在传递依赖，这是不符合第三范式的。
举例：
举例说明
假设我们有一个关于员工能力的表格，其内容如下：
| 部门编号 | 员工姓名 | 产出 | 职业等级 |
|---|---|---|---|
| D001 | 张三 | 5 | 初级 |
| D001 | 李四 | 6 | 中级 |
| D002 | 王五 | 5.5 | 初级 |
在这个例子中，主键可以认为是“部门编号”和“员工姓名”的组合（虽然在实际应用中，员工姓名作为主键的一部分可能不是最佳选择，但此处仅用于说明）。非主属性包括“产出”和“职业等级”。
- “产出”直接依赖于主键（部门编号和员工姓名的组合），因为它是由员工的部门和身份决定的。
- 然而，“职业等级”在这里存在传递依赖问题，因为它实际上是由“产出”间接决定的，而不是直接由主键决定。即，职业等级依赖于产出，而产出又依赖于主键。
为了符合第三范式，我们需要将这个表拆分为两个表：
员工表：
| 部门编号 | 员工姓名 | 产出 |
|---|---|---|
| D001 | 张三 | 5 |
| D001 | 李四 | 6 |
| D002 | 王五 | 5.5 |
产出等级表：
| 产出 | 职业等级 |
|---|---|
| 4-5.5 | 初级 |
| 5.6-7 | 中级 |
在这个拆分后的设计中，每个表都更加专注于存储一组相关的数据，并且消除了传递依赖的问题。员工表直接存储了员工的部门、姓名和产出，而职业等级则通过另一个表来管理，并通过产出与产出表进行关联。
（4）BCNF范式
BCNF要求关系模式中的每个非主属性都完全依赖于候选键（Candidate Key），而不是依赖于其他非主属性或候选键的一部分。这意味着在BCNF中，不存在任何函数依赖关系，其中非主属性（即非键属性）依赖于其他非主属性或候选键的真子集。
BCNF，全称为Boyce-Codd Normal Form，中文常称为巴斯范式或鲍依斯-科得范式，是由Raymond F. Boyce和Edgar F. Codd在1974年提出的数据库设计中的一种规范化形式。它是在第三范式（3NF）的基础上进一步细化和完善的，旨在消除关系模式中的所有部分函数依赖，确保数据库中的数据更加规范化。
如何判断一个关系模式是否符合BCNF
要判断一个关系模式是否符合BCNF，需要进行以下步骤：
- 确定候选键：首先，需要确定关系模式中的所有候选键。
- 检查函数依赖：然后，检查关系模式中的每个函数依赖，确保每个非主属性都完全依赖于某个候选键。
- 排除部分依赖和传递依赖：如果存在非主属性依赖于候选键的真子集或存在传递依赖，则关系模式不符合BCNF。
应用场景
BCNF广泛应用于关系数据库的设计和规范化过程中。在实际应用中，虽然通常只需要满足前三个范式（1NF、2NF、3NF）就足够了，但在某些对数据一致性和完整性要求极高的场景下，BCNF的应用显得尤为重要。
总之，BCNF是数据库设计中的一个重要概念，它通过消除关系模式中的部分函数依赖和传递函数依赖，确保数据库中的数据更加规范化、一致性和高效性。
备注：有几个概念，超键、候选键、主键、外键
超键(super key)：在关系中能唯一标识元组的属性集称为关系模式的超键
候选键(candidate key)：不含有多余属性的超键称为候选键。也就是在候选键中，若再删除属性，就不是键了
主键(primary key)：用户选作元组标识的一个候选键程序主键
外键(foreign key)：如果关系模式R中属性K是其它模式的主键，那么k在模式R中称为外键。
