📄 一句话概括
规范化（范式）是一套拆表工序：按第一→第二→第三范式的顺序检查并拆分，把重复、依赖的祸根逐层除掉——目标是「一份事实只存一处」，改一处就对处处对。
📝 本节和前面几节的关系
逻辑层设计的核心工序登场（5-9 的楼层里它住在逻辑层）。本节讲总纲，5-11/5-12/5-13 三范式各一节，最后 5-16~5-19 书评网站实战会从头走一遍。它回收了 5-5 埋的「成绩塞哪」问题和 2-3 的拆表思想。
一、不规范的表长什么样
一张大杂烩表：
订单(订单号, 客户姓名, 客户电话, 商品1, 数量1, 价格1, 商品2, 数量2, 价格2, ...)
毛病清单：
- 重复组：商品2/数量2/价格2——最多卖几种商品就得重复几组
- 冗余：同一客户的姓名电话跟着每张订单抄一遍
- 改坏隐患：客户改电话，漏改一张订单就出两个版本
二、规范化的三个台阶（下一章前先记口诀）
| 范式 | 一句话 | 收拾什么 |
|---|---|---|
| 第一范式 | 每格只装一个值 | 重复组、逗号串 |
| 第二范式 | 非主键列必须认整个主键 | 部分依赖 |
| 第三范式 | 非主键列之间不许互相依赖 | 传递依赖 |
三、规范化的得与失
- 得：冗余消失（省空间）、一致有保（改一处）、更新异常根除
- 失：表变多，查询要 JOIN（3-20~3-22 的功夫用上了）——用读的时候慢一点，换写的时候永不乱
工程口径：业务库至少第三范式；报表、日志这类只读场景才考虑故意「反规范化」换速度。
四、动手 Demo：同一份数据的规范前后
不规范：订单(订单号, 客户名, 客户电话, 商品名, 数量) ← 一单一商品，客户信息反复抄
规范化后：
customers(客户id PK, 姓名, 电话)
orders(订单号 PK, 客户id FK)
order_items(订单号 FK, 商品id FK, 数量) ← 关系属性住中间表（5-6 的手法）
products(商品id PK, 商品名)
客户改电话只改 customers 一行——一份事实只存一处。
五、30 秒实验
在纸上给「班级(班号, 班主任姓名, 班主任手机)」找毛病：班主任信息跟着每个班重复抄？不——一个班只有一个班主任，这不冗余；但若班主任还带别的班，改手机就要改多行——传递依赖（5-13 的课）。
六、常见误区
- 「范式是越高越好」：够用第三范式即可；盲目拆到第五范式，JOIN 海洋会把查询拖死
- 「规范化是删数据」：不是删，是搬家——数据一份不少，只是各回各家
自测三问
1. 规范化的目标？（一份事实只存一处） 2. 三范式各收拾什么？（重复组/部分依赖/传递依赖） 3. 规范化的代价？（表多查询要 JOIN——用读换写的一致）- ☐ 下一节（5-11 第一范式-避免重复的项目）
相关笔记
- 概念模型、逻辑模型、物理模型-E-R图的种类 —— 上一节：规范化住在逻辑层
- 第一范式-避免重复的项目 —— 下一节：第一台阶
- 表连接-将各种表组合在一起 —— 拆表思想的源头
- 🗄️ 数据库基础 · 索引 —— 全课路线图