工具有了，该拿尺子量这张表到底差在哪一级。
范式越高要求越严，本章量到 3NF 就够用了。
范式越高表越多，查一次要连的表也越多，得在安全和快之间权衡。
范式层层递进，3NF 必然先满足 2NF。消传递依赖是 3NF 的活，2NF 消的是部分依赖。
是不是范式越高就一定越好？
一级一级往上，每升一级消掉一种毛病。
| 范式 | 这一级的要求 |
|---|
四级是层层递进的，判的时候按 1NF、2NF、3NF 的顺序往下走。
每个格子只装一个值，这是最低的门槛。
MySQL 建的表天生满足 1NF，一个字段本来就塞不下两个值。
联系方式一栏里既写手机又写邮箱，就不满足 1NF。
一个格子里塞了三个爱好，属性还能再分，所以不满足第一范式。
非主属性都得完全依赖主码，不许只靠一半。
SCD 卡在这一级，SN、Age、Dept、MN 只靠 SNo 一半就定得下。
非主属性不许绕着别的非主属性来。
一个关系模式只描述一件事，不多装。
拆到最后，学生表管学生，选课表管选课，系表管系。
像收纳，袜子进衣柜，文件进档案夹，一个抽屉只放一类。
1NF 原子化，2NF 消部分，3NF 消传递，BCNF 管主属性。
| 范式 | 这一级的要求 |
|---|---|
| 1NF | 属性原子化 |
| 2NF | 非主属性完全依赖码 |
| 3NF | 非主属性不传递依赖码 |
| BCNF | 主属性也不部分依赖码 |
课件右图写「非主属性对主属性」，按左边的定义应是对码。
主码是单属性，2NF 天然满足。A→B→C 是传递依赖，3NF 过不了。
分解结果不唯一，可有的分法会把信息弄乱。
切错地方，四行连回来变六行，多出来的两行是凭空编的。