“一二三范式”通常是指数据库设计中的第一范式（1NF）、第二范式（2NF）、第三范式（3NF），它们是关系型数据库规范化（Normalization）理论的核心内容，目的是减少数据冗余、避免更新异常、提高数据一致性。
下面用通俗易懂的方式解释这三个范式：
🧱 0. 前提：什么是“范式”？
- 范式 = 数据表设计的“规范标准”。
- 满足更高范式，意味着数据结构更合理、更健壮。
- 一般实际开发中，满足第三范式就足够了。
✅ 第一范式（1NF）：字段不可再分
要求：表的每一列都是原子性的（不可再拆分的最小单位）
❌ 反例：
| 学号 | 姓名 | 电话号码 |
|---|---|---|
| 001 | 张三 | 13800138000, 13900139000 |
→ “电话号码”一列包含两个值，违反 1NF。
✅ 正确做法（拆成多行或多列）：
| 学号 | 姓名 | 电话号码 |
|---|---|---|
| 001 | 张三 | 13800138000 |
| 001 | 张三 | 13900139000 |
或者（如果最多两个号码）： | 学号 | 姓名 | 电话1 | 电话2 |
✅核心：每个单元格只能存一个值！
✅ 第二范式（2NF）：消除部分依赖
前提：已满足 1NF
要求：非主键字段必须完全依赖于整个主键（不能只依赖主键的一部分）
⚠️ 适用场景：主键是复合主键（由多个字段组成）时
❌ 反例（订单明细表）：
| 订单ID | 商品ID | 商品名称 | 商品价格 | 数量 |
|---|---|---|---|---|
| O1 | P1 | 苹果 | 5元 | 2 |
- 主键 = (订单ID, 商品ID)
- 但 “商品名称”、“商品价格”只依赖于“商品ID”，和“订单ID”无关 →部分依赖
→ 如果商品价格变了，所有历史订单都要改，容易出错！
✅ 正确做法：拆表
- 商品表：商品ID（主键）、商品名称、商品价格
- 订单明细表：订单ID、商品ID、数量
✅核心：非主键字段不能“只靠主键的一部分活着”
✅ 第三范式（3NF）：消除传递依赖
前提：已满足 2NF
要求：非主键字段之间不能有依赖关系（所有非主键字段都直接依赖主键，而不是依赖其他非主键字段）
❌ 反例：
| 学号 | 姓名 | 系名 | 系主任 |
|---|---|---|---|
| 001 | 张三 | 计算机 | 李教授 |
- 主键：学号
- 依赖关系：学号 → 系名 → 系主任
→ “系主任”依赖于“系名”，而不是直接依赖“学号” →传递依赖
→ 如果“计算机系”换了系主任，所有该系学生记录都要更新！
✅ 正确做法：拆表
- 学生表：学号（主键）、姓名、系名
- 院系表：系名（主键）、系主任
✅核心：非主键字段之间不能“互相依赖”，都必须直连主键！
🧠 一句话总结三大范式：
| 范式 | 核心思想 |
|---|---|
| 1NF | 字段不可再分（原子性） |
| 2NF | 非主键字段必须完全依赖整个主键（消除部分依赖） |
| 3NF | 非主键字段之间不能互相依赖（消除传递依赖） |
💡 实际应用建议：
- 大多数业务系统设计到3NF 就够了。
- 有时为了查询性能（如报表、大数据分析），会故意反范式化（增加冗余），这是合理的权衡。
- 范式不是教条，而是指导原则——目标是让数据更可靠、更易维护。
