数据库范式与反范式

数据库3范式

第一范式（1NF）： 第一范式要求数据库表中的每个字段必须是原子性的，即每个字段不能再分解为更小的数据单元。换句话说，每个字段应该是不可再分的最小数据单元。（表中字段的数据，不可以再拆分）

举例说明： 假设有一个名为“订单”的数据库表，包含以下字段：

• 订单编号
• 产品名称
• 产品规格（包括颜色和尺寸）

如果将“产品规格”字段拆分为“颜色”和“尺寸”两个字段，则不符合第一范式。正确的做法是将“产品规格”字段保留为一个字段，以确保每个字段都是原子性的。

第二范式（2NF）： 第二范式要求数据库表中的非主键字段必须完全依赖于候选键，而不是部分依赖。候选键是可以唯一标识每一行数据的字段或字段组合。

举例说明： 考虑一个包含以下字段的数据库表“订单详情”：

• 订单编号（作为主键）
• 产品编号
• 产品名称
• 产品价格

如果“产品名称”和“产品价格”只依赖于“产品编号”，而不依赖于“订单编号”，则不符合第二范式。正确的做法是将“产品名称”和“产品价格”移至另一个表中，以确保非主键字段完全依赖于候选键。

第三范式（3NF）： 第三范式要求数据库表中的字段之间没有传递依赖关系，即非主键字段之间不能存在依赖关系。

举例说明： 考虑一个包含以下字段的数据库表“员工信息”：

• 员工编号（作为主键）
• 部门编号
• 部门名称
• 部门地点

如果“部门名称”依赖于“部门编号”，而“部门地点”又依赖于“部门名称”，则存在传递依赖关系，不符合第三范式。正确的做法是将“部门名称”和“部门地点”移至另一个表中，以消除传递依赖关系。

数据库反范式

合理的增加表的冗余，达到尽可能少的表连接操作。

举例说明： 假设有一个在线商城的数据库，包含“订单”表和“产品”表。在正常化的设计中，“订单”表和“产品”表会通过外键关联，以避免数据冗余。但是，如果需要频繁查询订单及其对应的产品信息，并且查询性能成为瓶颈，可以考虑使用反范式化设计。

在反范式化设计中，可以将“订单”表中的一些产品信息冗余存储，以减少查询时的连接操作。例如，在“订单”表中添加“产品名称”和“产品价格”字段，这样在查询订单时就无需再通过外键关联“产品”表来获取产品信息，可以直接从订单表中获取。

问题：

1.存储 空间变大 了
2.一个表中字段做了修改，另一个表中冗余的字段也需要做同步修改，否则 数据不一致
3.若采用存储过程来支持数据的更新、删除等额外操作，如果更新频繁，会非常 消耗系统资源
4.在 数据量小 的情况下，反范式不能体现性能的优势，可能还会让数据库的设计更加 复杂

适用场景：

当冗余信息有价值或者能 大幅度提高查询效率 的时候，我们才会采取反范式的优化。

数据库BCNF范式

任何主属性对于任何候选码不存在部分依赖。即消除主属性对候选码的部分依赖。

BCNF是对第三范式（3NF）的进一步规范，通过更严格的要求来避免某些数据异常和不一致性。符合BCNF的数据库设计具有更高的数据完整性和一致性。

附：

键与相关属性的概念
1.超键：候选键与其他属性的组合。

2.候选键：候选键是最小的超键，能唯一一个标识元组。

3.主键：候选键可以有多个，选择一个作为主键。

4.主属性：包含在候选码中的属性称为主属性。

5.非主属性：不包含在任何候选码中的属性是主属性。

6.外键：是当前关系中的属性，也是另一个关系中的码（候选码）。