3.6.1 规范化理论概述
本课核心知识点整理
为什么规范化是数据库章节的难点
规范化理论是关系数据库设计中最抽象的一段。字幕里特别提醒：它在上午题中基本必考，下午题也会间接出现；难点不在背名词，而在把“函数依赖、候选键、主属性、范式、模式分解”串成一个判断流程。
规范化研究的是关系模式是否设计合理。一个表如果把多个主题混在一起，会产生数据冗余和操作异常。例如把学生、课程、教师、成绩都塞进一张表：
| 学号 | 姓名 | 课程号 | 课程名 | 任课教师 | 成绩 |
|---|---|---|---|---|---|
| S01 | 张三 | C01 | 数据库 | 王老师 | 90 |
| S02 | 李四 | C01 | 数据库 | 王老师 | 86 |
这里“C01 是数据库、任课教师王老师”被重复存储。若课程名修改，需要改多行；若最后一名选课学生删除，课程信息也可能随之丢失；若还没人选课，就无法单独插入课程。这就是规范化要解决的问题。
规范化要消除的异常
| 异常 | 发生原因 | 例子 |
|---|---|---|
| 插入异常 | 某些事实必须依赖另一类事实才能插入 | 没有学生选课时无法记录课程信息 |
| 删除异常 | 删除某类事实时误删另一类事实 | 删除最后一条选课记录导致课程信息消失 |
| 修改异常 | 同一事实重复存储，修改要改多处 | 课程名改名时要更新所有选课行 |
| 数据冗余 | 不同主题混在同一关系中 | 课程名、教师名反复出现 |
规范化不是为了把表拆得越碎越好，而是为了让每个关系模式表达清楚的主题，减少由函数依赖造成的冗余。
整个规范化板块的路线图
字幕把本板块分成三层：基本概念、范式判断、模式分解。
mermaid
flowchart LR
A["函数依赖"] --> B["候选键"]
B --> C["主属性 / 非主属性"]
C --> D["判断 1NF、2NF、3NF、BCNF"]
D --> E["通过模式分解提高范式"]
E --> F["检查无损连接与保持依赖"]| 层次 | 要解决的问题 | 常用工具 |
|---|---|---|
| 基本概念 | 谁决定谁，哪些属性能唯一标识元组 | 函数依赖、属性闭包、候选键 |
| 范式判断 | 当前关系模式规范到什么程度 | 1NF、2NF、3NF、BCNF |
| 模式分解 | 如何把低范式模式拆成更合理的模式 | 无损连接、保持函数依赖 |
规范化属于逻辑结构设计
考试很喜欢问规范化属于数据库设计的哪个阶段。答案是逻辑结构设计阶段。原因是规范化针对的是关系模式：
它不关心某张表具体存在哪个数据文件，也不直接决定索引怎么建；这些是物理设计问题。规范化关心的是“关系模式中的属性是否放在合适的位置”。
范式提高的代价
范式越高，通常冗余越少，更新异常越少；但它也可能带来更多连接操作。工程上并不是无脑追求最高范式，而是在一致性、性能和查询复杂度之间取平衡。
| 设计状态 | 优势 | 代价 |
|---|---|---|
| 低范式/未充分规范化 | 查询时可能少连接 | 冗余大，插删改异常明显 |
| 较高范式 | 数据事实分离，更新一致性好 | 查询可能需要更多连接 |
| 有控制的反规范化 | 面向高频查询优化性能 | 需要额外机制保证冗余一致 |
软考题通常站在理论设计角度，要求用规范化减少冗余；实际系统中是否反规范化，是在理解规范化之后的性能权衡。
做题路线
- 先列出题干给定的函数依赖，不要直接猜范式。
- 求候选键，再据此区分主属性和非主属性。
- 检查是否存在非主属性对候选键的部分依赖，决定是否满足 2NF。
- 检查是否存在非主属性对候选键的传递依赖，决定是否满足 3NF。
- 检查每个非平凡函数依赖的决定因素是否都是候选键，决定是否满足 BCNF。
- 如果要求分解，再判断是否无损连接、是否保持函数依赖。
例题
规范化理论的主要目标是：
判断范式前通常应先求：
自查要点
- 规范化解决哪些设计问题？
- 为什么函数依赖是范式判断基础？
- 范式题为什么要先求候选键？