第 6 章：规范化理论从零讲透——好表是怎么设计出来的

为什么有些表越用越乱：一改数据处处出错、删一条记录丢一片信息？答案通常在"表设计不规范化"。这一章教你用函数依赖和范式把表设计得干净利落，也是考试综合题的三大固定题型之一。

一、从一个坏表说起

看这张学生选课表：

学号	姓名	系	系主任	课程号	课程名	成绩
2026001	张三	计算机	王五	C01	数据库	85
2026001	张三	计算机	王五	C02	高数	78
2026002	李四	软件	赵六	C01	数据库	90

问题（四种异常，要会举例）：

1. 数据冗余：张三的系、系主任、姓名随选课门数重复存储；
2. 插入异常：新系还没招生（无学生），系主任信息插不进来；
3. 删除异常：李四退课只剩一门课时，再退就"把李四的系信息也删没了"；
4. 修改复杂（更新异常）：王五退休换主任，要改几百行，漏改一行就数据不一致。

根源：这张表混着两个主题（学生信息 + 选课信息）。规范化就是拆表的艺术。

二、函数依赖：决定关系

X → Y（X 函数决定 Y）：X 的值一旦确定，Y 的值就唯一确定。像数学函数 y=f(x)。

• 学号 → 姓名、学号 → 系 ✓
• （学号，课程号）→ 成绩 ✓（一门课的成绩由"哪个学生的哪门课"决定）
• 系 → 系主任 ✓

三种重要形态：

1. 完全函数依赖：Y 依赖 X 的全部，少一个属性就不行。成绩完全依赖（学号，课程号）；
2. 部分函数依赖：X 里只有一部分就能决定 Y。姓名部分依赖（学号，课程号）——其实学号一个就够。部分依赖是冗余之源；
3. 传递函数依赖：学号 → 系 → 系主任，则系主任传递依赖学号。传递依赖是修改异常之源。

三、候选码求解三步法

第一步：给属性分类

• 只在依赖左部出现（L 类）→ 必在候选码；
• 只在右部出现（R 类）→ 必不在候选码；
• 左右都出现（LR 类）→ 待定；
• 左右都不出现（N 类）→ 必在候选码。

第二步：求闭包验证。X⁺ = 由 X 出发能推出的全部属性。若 L/N 类属性组合的闭包 = 全部属性，就是候选码。

第三步：闭包不够就逐个把 LR 类属性加进来再求闭包，直到覆盖全部属性。

例：R(A,B,C,D)，F={A→B, B→C, A→D}。L 类：A。A⁺ = {A,B,C,D} ⊇ 全部 → 候选码就是 A。

四、范式：层层加码的合格标准

• 1NF：每个分量不可再分（表的基本要求，单元格不塞复合值）；
• 2NF：在 1NF 基础上，消除非主属性对候选码的部分依赖——把"部分依赖"的属性拆到只依赖主码一部分的表里去；
• 3NF：在 2NF 基础上，消除非主属性对候选码的传递依赖；
• BCNF：每个函数依赖的左部都包含候选码（更严的 3NF）。

开头那张坏表的诊断：候选码（学号，课程号）。姓名、系、系主任只依赖学号（部分依赖）→ 不满足 2NF。成绩完全依赖候选码。传递链"学号→系→系主任"→ 传递依赖。

分解方案（拆成三张干净的表）：

• 学生（学号，姓名，系）
• 系（系，系主任）
• 选课（学号，课程号，成绩）

分解后四种异常全部消失，且每个模式都达到 3NF。

五、3NF 分解的通用写法

给定 F 中每个依赖 X→A：每个依赖独立成表 R(X, A)；再补一张表存候选码（若未被包含）。要求记住：好的分解要满足无损连接（拆开还能 join 回来）与保持函数依赖（依赖不丢）。

六、范式判定题的标准答题步骤（考卷上就这么写）

1. 写出函数依赖集 F；
2. 求候选码（写出分类和闭包过程）；
3. 指出主属性/非主属性；
4. 检查部分依赖 → 是否满足 2NF；
5. 检查传递依赖 → 是否满足 3NF；
6. 给出结论并按要求分解，画出分解后的各关系模式。

下一篇：第 7–8 章，数据库设计全流程与数据库保护。