MySQL数据库：范式

按照“数据库规范化”对表进行设计，其目的就是减少数据库中的数据冗余，以增加数据的一致性。

常见的范式有1NF、2NF、3NF、BCNF。下面对这几种常见的范式进行简要分析。

1、1NF(第一范式)：

第一范式，就是数据表的列不可再分，数据库表中的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。

看下面数据表，对于选课列明显是可以再分的，所以它是违反第一范式的。

2、2NF(第二范式)：

第二范式必须先满足第一范式。另外包含两部分的内容：一是表必须有一个主键；二是表中非主键列必须完全依赖于主键，而不能只依赖于主键的一部分。

表中主键为 （学号，课程），我们可以表示为 (学号，课程) -> (成绩，课程学分)， 表示所有非主键列 (成绩，课程学分)都依赖于主键 (学号，课程)。 但是，表中还存在另外一个依赖：（课程）->(课程学分）。这样非主键列 ‘课程学分‘ 依赖于部分主键列 ’课程‘， 所以上表是不满足第二范式的。

我们把它拆成如下2张表：

学生选课表：

课程信息表：

那么上面2个表，学生选课表主键为（学号，课程），课程信息表主键为（课程），表中所有非主键列都完全依赖主键。不仅符合第二范式，还符合第三范式。 

3、3NF(第三范式)：

定义：首先是满足 2NF，另外非主键列必须直接依赖于主键，表中的列不存在对非主键列的传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。

再看这样一个学生信息表：

上表中，主键为：（学号），所有字段 （姓名，性别，班级，班主任）都依赖与主键（学号），不存在对主键的部分依赖。所以是满足第二范式。但是，表中存在一个传递依赖，(学号）->(班级）->（班主任）。也就是说，（班主任）这个非主键列依赖与另外一个非主键列 （班级）。所以不符号第三范式。

把这个表拆分成如下2个表：

学生信息表：

班级信息表：

这样，对主键的传递依赖就消失了。上面的2个表都符合第3范式。

第二范式（2NF）和第三范式（3NF）的概念很容易混淆，区分它们的关键点在于，2NF：非主键列是否完全依赖于主键，还是依赖于主键的一部分；3NF：非主键列是直接依赖于主键，还是直接依赖于非主键列。

4、BCNF(BC范式)：

定义：在第三范式的基础上，消除主属性对于码部分的传递依赖。

假设仓库管理关系表(仓库号，存储物品号，管理员号，数量)，满足一个管理员只在一个仓库工作；一个仓库可以存储多种物品，则存在如下关系：

(仓库号，存储物品号)——>(管理员号，数量)

(管理员号，存储物品号)——>(仓库号，数量)

所以，(仓库号，存储物品号)和(管理员号，存储物品号)都是仓库管理关系表的候选码，表中唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：

(仓库号)——>(管理员号)

(管理员号)——>(仓库号)

即存在关键字段决定关键字段的情况，因此其不符合BCNF。把仓库管理关系表分解为两个关系表  仓库管理表(仓库号，管理员号) 和 仓库表(仓库号，存储物品号，数量)，这样这个数据库表是符合BCNF的，并消除了删除异常、插入异常和更新异常。

5、4NF(第四范式)：

设R是一个关系模型，D是R上的多值依赖集合。如果D中存在多值依赖X->Y时，X必是R的超键，那么称R是第四范式的模式。

例如，职工表(职工编号，职工孩子姓名，职工选修课程)，在这个表中，同一个职工可能会有多个职工孩子姓名，同样，同一个职工也可能会有多个职工选修课程，即这里存在着多值事实，不符合第四范式。如果要符合第四范式，只需要将上表分为两个表，使它们只有一个多值事实，例如职工表一(职工编号，职工孩子姓名)，职工表二(职工编号，职工选修课程)，两个表都只有一个多值事实，所以符合第四范式。

原博客链接：https://blog.csdn.net/xidianliuy/article/details/51566576