MYSQL三大范式（基础5）

第一范式（1NF）：原子性

核心要求：每一项数据都是不可分割的最小单元

❌ 违规设计：

包裹号	收件信息	寄件信息
001	张三，北京朝阳区	李四，上海浦东新区

问题：收件信息和寄件信息混合在同一个字段

✅ 符合1NF的设计：

包裹号	收件人	收件地址	寄件人	寄件地址
001	张三	北京朝阳区	李四	上海浦东新区

第二范式（2NF）：消除部分依赖

核心要求：每个非主键字段都要完全依赖整个主键

假设主键：(包裹号, 驿站编号)

❌ 违规设计：

包裹号	驿站编号	驿站地址	包裹重量	驿站经理
001	Z-01	北京朝阳A街	2.5kg	王经理

问题：

1. 驿站地址和驿站经理只依赖驿站编号，与包裹号无关
2. 同一个驿站的信息会被重复记录

✅ 符合2NF的拆分：

包裹表（主键：包裹号+驿站编号）
| 包裹号 | 驿站编号 | 包裹重量 |
|--------|----------|----------|
| 001    | Z-01     | 2.5kg    |

驿站表（主键：驿站编号）
| 驿站编号 | 驿站地址    | 驿站经理 |
|----------|-------------|----------|
| Z-01     | 北京朝阳A街 | 王经理    |

第三范式（3NF）：消除传递依赖

核心要求：非主键字段之间不能有依赖关系

❌ 违规设计：

员工ID	姓名	所属部门	部门电话
1001	张三	财务部	010-88881234

问题：
部门电话依赖于所属部门，而不是直接依赖主键员工ID

员工表（主键：员工ID）
| 员工ID | 姓名   | 部门ID |
|--------|--------|--------|
| 1001   | 张三   | D-01   |

部门表（主键：部门ID）
| 部门ID | 部门名称 | 部门电话     |
|--------|----------|--------------|
| D-01   | 财务部   | 010-88881234 |

第二范式和第三范式的区别和场景应用

 

场景背景

设计学生成绩表，初始设计如下：

学号	学生姓名	课程号	课程名称	学分	成绩	系主任
2023001	张三	C001	数据库原理	3	92	李主任
2023001	张三	C002	软件工程	2	85	李主任
2023002	李四	C001	数据库原理	3	78	王主任

 

问题诊断

第二范式问题（违反2NF）

假设主键是（学号 + 课程号）

❌ 部分依赖：

1. 学生姓名只依赖学号（与课程无关）
2. 课程名称、学分只依赖课程号（与学生无关）
3. 系主任依赖学号（和学生所属院系相关）

 问题表现：

• 张三选10门课 → 学生姓名重复存储10次
• 修改课程名称需要修改所有相关记录
• 删除某个学生的所有选课记录会丢失学生信息

第三范式问题（违反3NF）

假设已满足2NF的结构：

学生表

学号	学生姓名	所属院系	系主任
2023001	张三	计算机系	李主任

❌ 传递依赖：
系主任 → 所属院系 → 学号
（系主任不直接依赖主键学号）

 问题表现：

• 更换系主任需要修改该院系所有学生的记录
• 学生未填院系无法记录系主任信息

解决方案对比

第二范式改造（分表消除部分依赖）

 学生表（主键：学号）
| 学号    | 学生姓名 | 所属院系 |
|---------|----------|----------|

 课程表（主键：课程号）
| 课程号 | 课程名称   | 学分 |
|--------|------------|------|

 成绩表（主键：学号+课程号）  
| 学号    | 课程号 | 成绩 |
|---------|--------|------|

 效果：

1. 学生姓名不会重复存储

2.  院系表（主键：院系名称）  
   | 院系名称 | 系主任 |
   |----------|--------|
   
    新版学生表（主键：学号）
   | 学号    | 学生姓名 | 所属院系 |
   |---------|----------|----------|
   

   修改课程信息只影响课程表

第三范式改造（拆分传递依赖）

 院系表（主键：院系名称）  
| 院系名称 | 系主任 |
|----------|--------|

 新版学生表（主键：学号）
| 学号    | 学生姓名 | 所属院系 |
|---------|----------|----------|

1. 调整后：
2. 系主任信息单独存储
3. 学生表只保留院系名称

核心区别对比表

维度	第二范式（2NF）	第三范式（3NF）
针对问题	消除部分依赖（主键的部分决定数据）	消除传递依赖（非主键字段间接依赖）
拆分方式	拆分复合主键中的冗余数据	拆分存在间接关联的属性集合
典型场景	订单明细含商品描述信息	员工表包含部门详细信息
错误后果	同一商品在不同订单重复存储基础信息	修改部门信息需更新大量员工记录

实际应用技巧

1. 设计订单系统

• 原始表：
  | 订单ID（主键） | 用户ID | 用户名 | 商品ID | 商品名 | 价格 |
• 2NF处理 → 分成用户表、商品表、订单表
• 3NF处理 → 确保用户表不含用户等级计算字段（如：用户等级由积分决定需额外拆分）

2. 学生选课系统

• 错误设计：
  | 学号+课程号（主键） | 学生姓名 | 课程学分 | 教师办公室 |
• 2NF改正 → 拆出学生表、课程表
• 3NF改正 → 教师办公室应从课程表移至教师表

日常生活比喻：

• 2NF 像整理衣柜 → 把不同季节衣服分开存放
• 3NF 像整理抽屉 → 钥匙和对应的锁要分格存放不混放