范式概念（NF）

范式在教材中的定义是符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度。我们可以理解为在设计数据库表结构的时候需要遵从的规范。以次来建立结构合理的数据库，提高数据存储和使用的性能。

目前关系型数据库的范式有第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）六种范式。
第一范式（1NF）、第二范式（2NF）、第三范式（3NF）又被称为数据库的三大范式
此外，范式之间具有依赖关系，既满足第二范式必须满足第一范式，满足第三范式必须满足第二范式，依次类推

今天我们来介绍第一范式（1NF）、第二范式（2NF）、第三范式（3NF）

第一范式（1NF）

表中的每个列不可以再拆分，需要遵循原子性
1NF是所有关系型数据库最基本的要求。

这个不规范的员工表中的姓名字段既有员工所属部门又有员工姓名。

通过把姓名字段拆分成部门和姓名来满足INF，正解如下：

第二范式（2NF）

在第一范式的基础上，非主键完全依赖于主键（单列或者多列组合），而不能是依赖于主键的一部分。

在解释2NF之前先介绍以下概念

数据依赖就是数据间的约束关系
函数依赖
定义： 若属性（或属性组）X 的值唯一决定属性Y 的值，则称Y 函数依赖于X，记作 X → Y。
核心特征： X 为决定因素，Y 为依赖因素；若X 相同，则Y 必相同（但Y 相同，X 未必相同）。
例： 身份证号→姓名（若身份证号相同，则姓名必相同，但姓名相同，身份证号 未必相同）
完全函数依赖

定义： 属性组X的所有属性共同决定属性Y，且Y不依赖于X的任何真子集。既X是一个属性组，Y的属性值由X中的所有属性值来决定。
例： 在订单表中（订单号, 商品名称，商品ID，数量）存在（订单号, 商品ID）→ 数量这样的依赖关系，数量是由订单号和商品ID的组合整体决定，单独任何一个都不能确定数量。
部分函数依赖
定义： 属性组X的某个真子集X’即可决定属性Y，既X是一个属性组，Y的属性值由X中的部分属性值来决定，此时Y部分依赖于X。
例： 在学生选课表中（学号, 课程号，学生姓名，课程姓名）存在(学号, 课程号) → 学生姓名这样的依赖关系，学生姓名仅由学号决定（如 “学号 S001” 对应 “张三”），与课程号无关。
传递函数依赖
定义： 若X → Y且Y → Z，但Z不直接依赖于X，则Z传递依赖于X。
**例：**在非规范化的员工表中（员工编号，部门编号，部门名称，部门负责人）中存在员工编号 → 部门编号和部门编号 → 部门名称、部门负责人两个依赖关系，因此员工编号 → 部门名称（传递依赖），员工编号 → 部门负责人（传递依赖）

2NF就是在1NF的基础上消除部分依赖，既表中任意一个主键或任意一组联合主键，可以确定除该主键外的所有的非主键值。

在下面不规范学生表中

• 如果学号是主键，只有姓名和年龄完全依赖学号。
• 如果课程名称是主键，只有学分完全依赖课程名称。
• 如果学号和课程名称做联合主键，只由成绩完全依赖联合主键。

因此通过把上面表格拆分成3张表格来消除部分依赖
学生表（学号，姓名，年龄）学号是主键
课程表（课程名称，学分）课程名称是主键
成绩表（学号，课程名称，成绩）学号和课程名称做联合主键

第三范式（3NF）

在第二范式的基础上，非主键列只依赖于主键，不依赖于其他非主键。既在满足第二范式的情况下，消除传递依赖。

在下面不规范员工表中

员工编号做主键，可以确定员工姓名，部门名称和部门负责人，但这张表格中部门名称还可以确定部门负责人。
因此把上面员工表拆分成员工表（员工编号，员工姓名，部门名称）和部门表（部门名称，部门负责人）来消除传递依赖。

为什么要遵守第二范式，第三范式？

• 减少数据冗余：如果不规范表格中由2名学生，每个学生有3门课程，在一个表里需要6条记录，但如果拆分一下只需要学生表2条记录，课程表3条记录，成绩表就只需保留学号、课程名称和成绩字段。
• 方便更新数据：如果课程的学分需要修改，在不规范表格中这个课程的每条记录都需要修改，但如果我们拆分出课程表，只需要修改一次即可。

总结

• 第一范式（1 NF）：字段不可再拆分。
• 第二范式（2 NF）：表中任意一个主键或任意一组联合主键，可以确定除该主键外的所有的非主键值。
• 第三范式（3 NF）：在任一主键都可以确定所有非主键字段值的情况下，不能存在某非主键字段 A 可以获取 某非主键字段 B。