数据库范式
1. 第一范式 (1NF)
定义：确保数据表中的每一列（字段）都是不可分割的原子数据项。 这是对关系模式最基本的要求，所有关系型数据库都必须满足第一范式。
核心要求：字段原子性，不可再分。
示例： 假设有一个订单信息表，其中“商品信息”列包含了商品名称和数量，这就不符合第一范式。
不符合 1NF 的表：
| 订单号 | 客户 | 商品信息 |
|---|---|---|
| 1001 | 张三 | 电脑, 2 台 |
| 1002 | 李四 | 键盘, 1 个; 鼠标, 1 个 |
如何修正： 将“商品信息”拆分为多个独立的、不可再分的列。
符合 1NF 的表：
| 订单号 | 客户 | 商品名称 | 数量 |
|---|---|---|---|
| 1001 | 张三 | 电脑 | 2 |
| 1002 | 李四 | 键盘 | 1 |
| 1002 | 李四 | 鼠标 | 1 |
2. 第二范式 (2NF)
定义：在满足第一范式的基础上，表中每一个非主属性都必须完全函数依赖于候选码，而不能只依赖于候选码的一部分（消除部分函数依赖）。
核心要求：消除非主属性对码的“部分函数依赖”。 这个范式主要针对联合主键。如果一个表的主键只有一个字段，那么它只要符合 1NF，就一定符合 2NF。
示例： 假设有一个选课成绩表，使用（学号, 课程号）作为联合主键。
不符合 2NF 的表： (主键为 学号 + 课程号)
| 学号 | 学生姓名 | 课程号 | 课程名称 | 成绩 |
|---|---|---|---|---|
| S01 | 张三 | C01 | 数据库 | 85 |
| S01 | 张三 | C02 | 操作系统 | 90 |
| S02 | 李四 | C01 | 数据库 | 78 |
在这个表中：
成绩完全依赖于(学号, 课程号)。学生姓名只依赖于学号，是部分依赖。课程名称只依赖于课程号，也是部分依赖。
这会导致数据冗余（张三和数据库的名字重复出现）和更新异常。
如何修正： 将表拆分，消除部分依赖。
符合 2NF 的表：
学生表：
| 学号 | 学生姓名 |
|---|---|
| S01 | 张三 |
| S02 | 李四 |
课程表：
| 课程号 | 课程名称 |
|---|---|
| C01 | 数据库 |
| C02 | 操作系统 |
成绩表：
| 学号 | 课程号 | 成绩 |
|---|---|---|
| S01 | C01 | 85 |
| S01 | C02 | 90 |
| S02 | C01 | 78 |
3. 第三范式 (3NF)
定义：在满足第二范式的基础上，任何非主属性都不能依赖于其他非主属性（消除传递函数依赖）。
核心要求：确保每个非主属性都直接依赖于主键，而不是间接依赖。
示例： 假设有一个员工信息表，其中包含了部门信息。
不符合 3NF 的表： (主键为 员工号)
| 员工号 | 员工姓名 | 部门号 | 部门名称 | 部门经理 |
|---|---|---|---|---|
| E01 | 张三 | D01 | 研发部 | 王五 |
| E02 | 李四 | D02 | 市场部 | 赵六 |
| E03 | 小明 | D01 | 研发部 | 王五 |
在这个表中，存在以下依赖关系：
(员工号) → (部门号) → (部门名称, 部门经理)
部门名称 和 部门经理 依赖于 部门号 (一个非主属性)，而 部门号 依赖于 员工号 (主键)。这就构成了传递依赖。
如何修正： 将存在传递依赖的属性拆分到新的表中。
符合 3NF 的表：
员工表：
| 员工号 | 员工姓名 | 部门号 |
|---|---|---|
| E01 | 张三 | D01 |
| E02 | 李四 | D02 |
| E03 | 小明 | D01 |
部门表：
| 部门号 | 部门名称 | 部门经理 |
|---|---|---|
| D01 | 研发部 | 王五 |
| D02 | 市场部 | 赵六 |
4. 巴斯-科德范式 (BCNF)
定义：在满足第三范式的基础上，对于表中任何一个非平凡的函数依赖 X → Y，X 都必须是一个超键（Super Key）。 BCNF 通常被认为是修正的第三范式，比 3NF 的要求更严格。
核心要求：任何属性（包括主属性和非主属性）都不能被非主属性所决定。 换言之，它消除了主属性对于码的部分和传递依赖。
与 3NF 的区别：3NF 允许主属性被非主属性决定，而 BCNF 不允许。
示例： 假设有一个仓库管理表，其中一个仓库只有一个管理员，一个管理员只负责一个仓库；但一个仓库可以存放多种物品，一种物品也可以被存放在多个仓库，且有对应的数量。
符合 3NF 但不符合 BCNF 的表： (候选键为 (仓库名, 物品名))
| 仓库名 | 管理员 | 物品名 | 数量 |
|---|---|---|---|
| 仓库 A | 张三 | 物品甲 | 100 |
| 仓库 A | 张三 | 物品乙 | 200 |
| 仓库 B | 李四 | 物品甲 | 150 |
在这个表中：
(仓库名, 物品名)是候选键，可以决定所有属性。- 存在依赖
管理员 → 仓库名。 管理员不是超键，但它决定了仓库名（主属性的一部分），这违反了 BCNF。
如何修正： 进行表拆分。
符合 BCNF 的表：
仓库管理员表：
| 管理员 | 仓库名 |
|---|---|
| 张三 | 仓库 A |
| 李四 | 仓库 B |
库存表：
| 仓库名 | 物品名 | 数量 |
|---|---|---|
| 仓库 A | 物品甲 | 100 |
| 仓库 A | 物品乙 | 200 |
| 仓库 B | 物品甲 | 150 |
5. 更高阶的范式
- 第四范式 (4NF)：在 BCNF 的基础上，消除多值依赖。
- 第五范式 (5NF)：在 4NF 的基础上，消除连接依赖，确保表中的信息无法通过其他表的连接来推导。
4NF 和 5NF 在实际的数据库设计中较少使用，因为它们处理的是更复杂的数据依赖关系。
6. 范式化的优缺点与反范式化
优点：
- 减少数据冗余：最小化数据的重复存储，节省存储空间。
- 提高数据一致性：数据只存储在一处，更新时不易产生数据不一致的情况。
- 优化写入操作：由于减少了冗余数据，插入、更新和删除操作更快。
缺点：
- 查询性能可能下降：过度范式化会导致表的数量增多，查询时需要进行多次连接（JOIN），从而影响查询效率。
- 设计复杂性增加：数据库结构变得更加复杂，增加了理解和维护的难度。
反范式化： 为了提高查询性能，有时会故意违反范式规则，在表中保留一些冗余数据，以减少查询时的连接操作。这是一种用空间换时间的策略，需要在数据一致性和查询效率之间做出权衡。