Marcus Allen 2025-09-22
规范化简介
规范化（Normalization） 是一种对数据库进行结构化设计的技术，旨在减少数据冗余并提升数据一致性。简单来说，它将庞大而混乱的数据表拆分为多个更小、结构更清晰的表。这样可以确保数据以逻辑方式存储，使数据库更高效、更易于维护，并避免重复或错误。
什么是数据库规范化？
数据库规范化是一种数据库设计技术，用于减少数据冗余，并消除诸如插入异常、更新异常和删除异常等不良特性。规范化规则通过将大表拆分成多个小表，并使用关系将它们连接起来。在 SQL 中进行规范化的目的是消除重复数据，并确保数据以合乎逻辑的方式存储。
关系模型的提出者 Edgar Codd 最初提出了数据规范化理论，并引入了第一范式（1NF）。随后，他进一步扩展了该理论，提出了第二范式（2NF） 和 第三范式（3NF）。后来，他与 Raymond F. Boyce 共同发展了 Boyce-Codd 范式（BCNF）。
为什么需要规范化？
如果没有规范化，数据库会迅速变得不一致且冗余。常见的问题包括：
- 插入异常：无法添加不完整的记录；
- 更新异常：一处数据修改后，其他地方未同步更新；
- 删除异常：删除某些数据时意外丢失了重要信息。
规范化能有效消除这些问题，确保数据完整性、减少重复，并简化数据库管理。
DBMS 中的范式类型
以下是 SQL 中常见的范式列表：
- 1NF（第一范式）：确保每个列都包含原子（不可再分）值，且每条记录唯一。消除重复组，将数据组织成表格形式。
- 2NF（第二范式）：在满足 1NF 的基础上，要求所有非主键属性完全依赖于整个主键（而非主键的一部分）。通常需将重复数据提取到单独的表中。
- 3NF（第三范式）：在满足 2NF 的基础上，进一步要求非主键属性之间不能存在传递依赖（即非主键字段不能依赖于其他非主键字段）。
- BCNF（Boyce-Codd 范式）：3NF 的强化版，要求每一个决定因素（determinant）都必须是候选键，解决 3NF 未能处理的某些异常。
- 4NF（第四范式）：处理多值依赖，确保一个实体不会在同一记录中包含多个独立的多值事实。
- 5NF（第五范式）：又称“投影-连接范式”（PJNF），指表无法被无损分解为更小的表。
- 6NF（第六范式）：目前仍属理论阶段，尚未广泛应用。主要用于处理时态数据（随时间变化的数据），通过进一步分解表来消除所有非时态冗余。
在实际应用中，大多数数据库设计在 第三范式（3NF） 即可达到良好效果。尽管学术界仍在探讨更高范式（如 6NF），但 3NF 已能满足绝大多数业务需求。
带实例的数据库规范化说明
我们通过一个案例来理解规范化过程。
假设某视频租赁店维护一个电影租借数据库。若不进行任何规范化，所有信息可能都存放在一张表中，如下所示：
| Full Name | Address | Membership ID | Movies Rented |
|---|---|---|---|
| Robert Phil | New York | M001 | Movie A, Movie B |
| Robert Phil | California | M002 | Movie C |
注意：“Movies Rented” 列包含多个值 —— 这违反了规范化原则。
第一范式（1NF）
规则：
- 每个单元格只能包含单一值（原子性）；
- 每条记录必须唯一。
1NF 化后的表：
| Full Name | Address | Membership ID | Movie Rented |
|---|---|---|---|
| Robert Phil | New York | M001 | Movie A |
| Robert Phil | New York | M001 | Movie B |
| Robert Phil | California | M002 | Movie C |
现在每行只包含一个电影，满足 1NF。
关键概念补充：
- 键（Key）：用于唯一标识表中记录的一个或多个列。
- 主键（Primary Key）：
- 不能为空（NOT NULL）；
- 必须唯一；
- 通常不应频繁更改；
- 插入新记录时必须提供值。
- 复合主键（Composite Key）：由多个列组成的主键。例如，两个“Robert Phil”住在不同地址，因此需用 (Full Name + Address) 才能唯一标识。
第二范式（2NF）
规则：
- 必须满足 1NF；
- 所有非主键属性必须完全函数依赖于整个主键（不能只依赖主键的一部分）。
在上表中，若主键是 (Membership ID, Movie Rented)，那么 Full Name 和 Address 只依赖于 Membership ID，而不依赖于 Movie Rented —— 这违反了 2NF。
解决方案：拆分为两张表
表1：会员信息（Members）
| Membership ID (PK) | Full Name | Address |
|---|---|---|
| M001 | Robert Phil | New York |
| M002 | Robert Phil | California |
表2：租借记录（Rentals）
| Membership ID (FK) | Movie Rented |
|---|---|
| M001 | Movie A |
| M001 | Movie B |
| M002 | Movie C |
外键（Foreign Key）说明：
- 表2中的
Membership ID是外键，引用表1的主键；- 外键确保参照完整性：只能插入表1中已存在的
Membership ID；- 外键可以为空（NULL），不要求唯一。
第三范式（3NF）
规则：
- 必须满足 2NF；
- 不存在传递依赖：非主键字段之间不能相互依赖。
考虑表1中新增一列 “Salutation”（称呼，如 Mr.、Ms.）：
| Membership ID | Full Name | Address | Salutation |
|---|---|---|---|
| M001 | Robert Phil | New York | Mr. |
这里存在传递依赖：Membership ID → Full Name → Salutation
即 Salutation 依赖于 Full Name，而 Full Name 又依赖于主键 —— 这违反了 3NF。
解决方案：再拆一张表
表3：称呼表（Salutations）
| Salutation ID (PK) | Salutation |
|---|---|
| S1 | Mr. |
| S2 | Ms. |
更新后的表1：
| Membership ID (PK) | Full Name | Address | Salutation ID (FK) |
|---|---|---|---|
| M001 | Robert Phil | New York | S1 |
| M002 | Robert Phil | California | S1 |
现在：
- 所有非主键字段都直接依赖于主键；
- 无传递依赖；
- 满足 3NF。
更高范式简述
BCNF（Boyce-Codd 范式）
- 有时被称为 3.5NF；
- 当表存在多个候选键时，3NF 仍可能出现异常，BCNF 可解决此问题；
- 要求：每个决定因素都必须是候选键。
4NF（第四范式）
- 消除多值依赖；
- 例如：一个人有多个电话号码和多个邮箱，且两者彼此独立 —— 应拆分为两个关系。
5NF（第五范式）
- 表无法被无损分解为更小的表；
- 主要用于复杂多表连接场景。
6NF（第六范式，理论阶段）
- 尚未标准化；
- 专注于时态数据库（记录数据随时间的变化）；
- 通过极致分解消除所有非时态冗余。
规范化的优点
- ✅ 提升数据一致性：每条数据只存一处，更新只需一次；
- ✅ 减少数据冗余：节省存储空间，提高效率；
- ✅ 优化查询性能：逻辑清晰的结构便于编写高效查询；
- ✅ 增强可读性：数据按业务逻辑分组，更易理解；
- ✅ 减少异常风险：避免插入、更新、删除时的数据问题。
规范化的缺点
- ❌ 增加复杂性：大量表和外键使结构复杂，难以管理；
- ❌ 降低灵活性：严格规则限制了非结构化数据的存储；
- ❌ 可能增加存储开销：额外的表和索引占用更多空间；
- ❌ 性能开销：频繁的表连接（JOIN）可能降低查询速度；
- ❌ 丢失业务上下文：数据分散在多张表中，需联合查看才能理解完整含义；
- ❌ 需要专业知识：设计规范化数据库需深入理解数据关系和范式理论。
总结：
规范化是构建健壮、可维护数据库的核心技术。虽然高范式（如 4NF、5NF）在理论上有其价值，但在实际项目中，第三范式（3NF）通常是最佳平衡点——既保证了数据完整性，又不至于过度复杂。合理运用规范化，能让数据库更可靠、更高效。