第二范式 (2NF)
第二范式（2NF）是关系数据库理论中数据库规范化的重要阶段，它建立在第一范式的基础上，进一步消除部分函数依赖，确保数据结构的合理性和减少冗余。本条目将详细介绍2NF的定义、判定方法、应用案例及与其它范式的关系。
定义与基本概念[编辑 | 编辑源代码]
第二范式要求一个关系满足以下两个条件：
- 该关系必须满足第一范式（1NF），即所有属性都是原子性的，不可再分。
- 所有非主属性必须完全函数依赖于候选键（不能存在部分函数依赖）。
关键术语解释[编辑 | 编辑源代码]
- 完全函数依赖：如果属性组X决定Y（X → Y），且X的任意真子集X'都不能决定Y，则称Y完全函数依赖于X。
- 部分函数依赖：如果存在X的某个真子集X'能决定Y，则称Y部分函数依赖于X。
数学表达：
为什么需要2NF？[编辑 | 编辑源代码]
未满足2NF的数据库可能存在以下问题：
- 数据冗余：相同数据在多个记录中重复存储。
- 更新异常：修改部分数据时需要更新多处，易导致不一致。
- 删除异常：删除某些数据时可能意外丢失其他信息。
判定方法与示例[编辑 | 编辑源代码]
示例1：不符合2NF的表[编辑 | 编辑源代码]
考虑一个存储学生选课信息的表StudentCourse：
| StudentID | CourseID | StudentName | CourseName | Instructor | Grade |
|---|---|---|---|---|---|
| 101 | CSE101 | Alice | Database | Dr. Smith | A |
| 101 | MAT202 | Alice | Calculus | Dr. Lee | B |
| 102 | CSE101 | Bob | Database | Dr. Smith | C |
问题分析：
- 候选键：
(StudentID, CourseID)（联合主键） - 非主属性：
StudentName,CourseName,Instructor,Grade - 存在部分依赖：
**StudentName仅依赖于StudentID（真子集） **CourseName和Instructor仅依赖于CourseID（真子集）
修正为2NF[编辑 | 编辑源代码]
通过分解消除部分依赖，得到以下两个表：
| StudentID | StudentName |
|---|---|
| 101 | Alice |
| 102 | Bob |
| CourseID | CourseName | Instructor |
|---|---|---|
| CSE101 | Database | Dr. Smith |
| MAT202 | Calculus | Dr. Lee |
| StudentID | CourseID | Grade |
|---|---|---|
| 101 | CSE101 | A |
| 101 | MAT202 | B |
| 102 | CSE101 | C |
Mermaid 关系图[编辑 | 编辑源代码]
实际应用案例[编辑 | 编辑源代码]
场景：电商订单系统[编辑 | 编辑源代码]
原始订单表Orders可能包含：
- 订单ID（主键）
- 客户ID + 客户姓名
- 产品ID + 产品名称 + 产品价格
- 订单数量
问题：客户姓名和产品信息部分依赖于非主键字段。
2NF解决方案：拆分为Customers、Products和OrderDetails三个表。
常见误区[编辑 | 编辑源代码]
- 误区1：认为所有单字段主键的表自动满足2NF。
纠正：仍需检查是否存在传递依赖（这是第三范式的要求）。
- 误区2：过度分解导致查询性能下降。
建议：在规范化和查询效率之间权衡，必要时使用反规范化技术。