第一范式（1NF）、第二范式（2NF） 、第三范式（3NF）

第一范式（1NF）、第二范式（2NF） 和 第三范式（3NF） 是关系数据库设计中的三种常见范式，它们主要用于规范化数据表结构，减少数据冗余，提升数据库的查询效率和一致性。每一范式都建立在前一范式的基础上，进一步细化和优化数据的组织形式。

下面是每个范式的详细说明：

1. 第一范式（1NF） - 原子性

第一范式（1NF）要求表中的每个字段（列）必须是原子的，即每个列的值不能是集合、数组或其他可以分解的多个值。换句话说，表中的每个单元格只能包含一个值，而不能包含多个值。

1NF 要求：

• 表中的每列的值都是不可再分割的原子值。
• 每行必须是唯一的，不能有重复的行。

示例：

假设有一个学生成绩表，其中每个学生有多个科目的成绩，表格可能看起来像这样：

学号	姓名	科目
001	张三	数学, 英语
002	李四	语文, 数学

该表 不满足 1NF，因为 科目 列包含多个值（如“数学, 英语”），这不是原子值。

将其转换为 1NF 后：

学号	姓名	科目
001	张三	数学
001	张三	英语
002	李四	语文
002	李四	数学

现在每个单元格的值都是原子的，符合 第一范式。

---

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

第二范式（2NF）要求表格不仅符合 第一范式（1NF），还要消除 部分依赖。具体来说，2NF 解决的是 非主属性（非关键字属性）部分依赖于 主键 的问题。

2NF 要求：

• 表必须首先满足 第一范式。
• 非主属性（即不包含在候选键中的属性）必须完全依赖于 主键，而不能仅依赖于主键的一部分。

示例：

假设有一个学生课程成绩表，主键是 (学号, 课程)，但是我们发现 姓名 只依赖于 学号，而与 课程 无关。这样的设计就会出现 部分依赖。

学号	课程	姓名	成绩
001	数学	张三	85
001	英语	张三	90
002	数学	李四	80
002	英语	李四	88

在这个例子中，姓名 依赖于 学号，而不是 学号 + 课程（主键的组合），因此 姓名 不是完全依赖于主键，出现了部分依赖。

将其转换为 2NF 后，可以将 姓名 提取到另一个表中，形成两个表：

学生表（存储学号和姓名）：

学号	姓名
001	张三
002	李四

成绩表（存储学号、课程和成绩）：

学号	课程	成绩
001	数学	85
001	英语	90
002	数学	80
002	英语	88

现在，学生表 只存储与 学号 相关的信息，成绩表 只存储与 学号 和 课程 相关的成绩，消除了部分依赖，符合 第二范式。

---

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

第三范式（3NF）要求表格不仅符合 第二范式（2NF），还要消除 传递依赖。传递依赖是指非主属性依赖于其他非主属性，而不是直接依赖于主键。

3NF 要求：

• 表必须首先满足 第二范式（2NF）。
• 非主属性必须直接依赖于 主键，而不能依赖于其他非主属性。

示例：

假设有一个员工表，其中包含了员工的 部门名称 和 部门地址，其中 部门地址 依赖于 部门名称，而 部门名称 又依赖于 员工（主键）。

员工ID	员工姓名	部门名称	部门地址
001	张三	销售部	北京市朝阳区
002	李四	技术部	上海市浦东新区
003	王五	销售部	北京市朝阳区

在这个表中，部门地址 依赖于 部门名称，而 部门名称 依赖于主键 员工ID，这就造成了传递依赖，即 员工ID → 部门名称 → 部门地址。

为了消除传递依赖，可以将 部门信息 提取到另一个单独的表中。

员工表（存储员工ID、姓名和部门ID）：

员工ID	员工姓名	部门ID
001	张三	D1
002	李四	D2
003	王五	D1

部门表（存储部门ID、部门名称和部门地址）：

部门ID	部门名称	部门地址
D1	销售部	北京市朝阳区
D2	技术部	上海市浦东新区

通过这种分解，部门地址 就不再依赖于 员工ID 了，而是依赖于 部门ID，从而消除了传递依赖，符合 第三范式。

---

总结

• 第一范式（1NF）：要求每个字段的值都是原子性的，不可再分。
• 第二范式（2NF）：要求满足 1NF，并且消除部分依赖，即非主属性必须完全依赖于主键。
• 第三范式（3NF）：要求满足 2NF，并且消除传递依赖，即非主属性只能依赖于主键，不能依赖于其他非主属性。

每个范式在确保数据一致性和减少冗余方面都有其独特的作用，在实际的数据库设计过程中，通常会逐步满足这些范式，以达到数据的规范化。