基础概念
函数依赖：
- 函数依赖（Functional Dependency）表示在数据库表中的两个属性之间的关系，其中一个属性的值决定另一个属性的值。
- 用符号表示为 X -> Y，其中 X 是决定属性 Y 的集合。
非平凡的函数依赖：
- 非平凡的函数依赖是指 X -> Y，其中 Y 不包含于 X，这意味着 X 对 Y 有真正的函数依赖，而不是简单的平凡依赖。
- 如果Y包含于X，则称X对Y是平凡的函数依赖。
完全函数依赖：
- 完全函数依赖表示在属性组合 X 中的每个属性都对属性 Y 有函数依赖，而且没有 X 中的任何真子集可以决定 Y。
- 如果存在 X -> Y，并且对于 X 中的每个属性子集 X’，X’ -> Y 都不成立，则称 Y 对 X 具有完全函数依赖。
部分函数依赖：
- 部分函数依赖是指属性 Y 依赖于属性组合 X 中的一部分，而不是全部属性。换句话说，存在 X -> Y 且存在 X’ 是 X 的真子集，X’ -> Y 也成立。
- 部分函数依赖通常需要通过规范化来消除，以维护数据库的一致性。
传递依赖：
- 传递依赖发生在 X -> Y 和 Y -> Z 两个函数依赖条件下，其中 X -> Z 成立。这意味着属性 Z 对属性 X 具有传递依赖。
- 传递依赖是规范化中的一个关键概念，通常需要考虑来减少数据表中的冗余和提高数据库的性能。
主属性和候选码：
- 主属性是包含在候选键（候选码）中的属性，这些属性能够唯一标识数据库表中的每个记录。
- 候选码是具有唯一性的属性组合，可以用来唯一标识表中的记录。
全码：
- 全码是指属性组合中包含了所有的属性，这些属性组合不仅是候选码，而且是全码，因为它们可以唯一标识表中的记录。
范式
第一范式 (1NF)：
第一范式是数据库中数据组织的最基本要求，它需要确保每个列的值都是不可再分的原子值，也就是每一列都不能包含多个值或数据的数组。
条件：
- 每个列都必须包含原子值，不能包含重复的数据。
- 所有列都应该有唯一的列名，以避免歧义。
缺点： - 数据冗余问题：因为每行都包含完整的数据，可能会导致数据冗余，增加存储需求。
- 更新异常：如果需要更新多行中的相同数据，必须确保更新所有行，否则会导致数据不一致性。
第二范式 (2NF)：
第二范式建立在第一范式的基础上，它要求表中需要消除非主属性对候选码的部分函数依赖。
条件：
- 数据表必须符合第一范式。
- 所有非主键列必须完全依赖于主键。
缺点：
- 增加复杂性：在实践中，实现第二范式可能需要多个表，这增加了数据库查询的复杂性。
- 可能存在数据冗余问题，尤其是在多对多关系的情况下。
第三范式 (3NF)：
第三范式进一步规范了数据库表的设计，要求表中需要消除非主属性对候选码的传递函数依赖。
条件：
- 数据表必须符合第一范式和第二范式。
- 非主键列之间不能相互依赖。
缺点：
- 数据冗余问题仍然可能存在，尤其在大型数据库中。
- 查询时需要多次连接表，可能影响性能。
巴斯-科德范式 (BCNF)：
BCNF是对第三范式的进一步规范，它强调了主键的重要性，消除主属性对候选码的部分和传递函数依赖。
条件：
- 数据表必须符合第一范式和第二范式。
- 每个非主键列必须完全依赖于主键，而不是部分依赖。
- 主键之间不能存在函数依赖关系。
缺点： - 可能需要进一步规范化数据，增加表的数量，复杂性以及查询的复杂性。
- BCNF的目标是确保数据的完整性和一致性，通过消除部分依赖和传递依赖来减少数据冗余。
###第四范式 (4NF)：
第四范式是对多值依赖的规范化，它处理多个独立多值属性的情况。多值依赖指的是，一个表的某些列的值可以取多个值，而这些值与其他列的值无关。
条件：
- 数据表必须符合BCNF。
- 表中的任何非主键列不可同时依赖于主键的任何一部分。
缺点： - 需要更多的表和关联，可能增加复杂性。
- 第四范式的目标是处理多值依赖，确保数据表不包含重复信息，以保持数据库的一致性。