数据库范式规范化总结

type

status

date

slug

summary

基础概念

函数依赖：

函数依赖（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。

表中的任何非主键列不可同时依赖于主键的任何一部分。

缺点：

需要更多的表和关联，可能增加复杂性。

第四范式的目标是处理多值依赖，确保数据表不包含重复信息，以保持数据库的一致性。