【SQL】通俗理解1NF、2NF、3NF

来源：https://www.zhihu.com/question/24696366
作者：刘慰

本文仅用于个人学习。

范式的课本定义：

• 符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度。
• “关系”和“关系模式”的区别，就好比面向对象程序设计中“对象”和“类”的区别，即可以理解为“关系”是“关系模式”的一个实例。

通俗的说法：

• 一张数据表的表结构所符合的某种设计标准的级别。
• 数据库范式有1NF、2NF、3NF、BCNF、4NF、5NF，一般设计关系型数据库的时候，最多考虑到BCNF就够。
• 符合高一级范式的设计，必定符合低一级范式。

第一范式

1.定义
符合1NF的关系中的每个属性都不再可分。

• 1NF是所有关系型数据库的最基本要求，即RDBMS（关系型数据库管理系统）中所有已经存在的数据表一定都是符合1NF的。

2.一个例子

上表就不符合1NF的要求。要修改成符合1NF的标准，就得改成以下形式：

3.缺点

以某系表为例。

数据冗余过大：每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次。
插入异常：假如学校新建了一个系，但是暂时还没有招收任何学生（比如3月份就新建了，但要等到8月份才招生），那么是无法将系名与系主任的数据单独地添加到数据表中去的 （注１）。

• 注１：根据三种关系完整性约束中实体完整性的要求，关系中的码（注２）所包含的任意一个属性都不能为空，所有属性的组合也不能重复。为了满足此要求，图中的表，只能将学号与课名的组合作为码，否则就无法唯一地区分每一条记录。
• 注２：码：关系中的某个属性或者某几个属性的组合，用于区分每个元组（可以把“元组”理解为一张表中的每条记录，也就是每一行）。（也成为键，注意，主键是键的一个子集）
• 删除异常：假如将某个系中所有学生相关的记录都删除，那么所有系与系主任的数据也就随之消失了（一个系所有学生都没有了，并不表示这个系就没有了）。
• 修改异常：假如李小明转系到法律系，那么为了保证数据库中数据的一致性，需要修改三条记录中系与系主任的数据。

正因为仅符合1NF的数据库设计存在着这样那样的问题，我们需要提高设计标准，去掉导致上述四种问题的因素，使其符合更高一级的范式（2NF），这就是所谓的“规范化”。

第二范式

2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖。

1.函数依赖
通俗理解，若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。

例如，学号 → 姓名，因为当学号相同时，姓名一定相同；但反过来不是，姓名相同，学号不一定相同。

• 完全函数依赖：在一张表中，若 X → Y，且对于 X 的任何一个真子集（假如属性组 X 包含超过一个属性的话），X ' → Y 不成立，那么我们称 Y 对于 X 完全函数依赖。
• 部分函数依赖：假如 Y 函数依赖于 X，但同时 Y 并不完全函数依赖于 X，那么我们就称 Y 部分函数依赖于 X。
• 传递函数依赖：假如 Z 函数依赖于 Y，且 Y 函数依赖于 X ，那么我们就称 Z 传递函数依赖于 X 。

2.码
设 K 为某表中的一个属性或属性组，若除 K 之外的所有属性都完全函数依赖于 K，那么我们称 K 为候选码，简称为码。
在实际中我们通常可以理解为：假如当 K 确定的情况下，该表除 K 之外的所有属性的值也就随之确定，那么 K 就是码。一张表中可以有超过一个码。（实际应用中为了方便，通常选择其中的一个码作为主码）

3.非主属性
包含在任何一个码中的属性成为主属性。

例，该表的主属性有两个，学号和课名

4.一个例子
根据2NF的定义，判断的是否符合2NF的依据就是，看数据表中是否存在非主属性对于码的部分函数依赖。若存在，则数据表最高只符合1NF的要求。

• step1：找出数据表中所有的码。
• step2：找出step1中所有码中的主属性。
• step3：数据表中除开所有主属性，剩余的就是非主属性。
• step4：查看是否存在非主属性对码的部分函数依赖。

例，还是以该表为例。

step1:

上图表示了表中所有的函数依赖关系。可以知道，表的码只有一个，就是(学号、课名)。
step2：
主属性有两个：学号、课名。
step3:
非主属性有四个：姓名、系名、系主任、分数。
step4：
对于（学号，课名） → 姓名，有 学号 → 姓名，存在非主属性 姓名 对码（学号，课名）的部分函数依赖。对于（学号，课名） → 系名，有 学号 → 系名，存在非主属性 系名 对码（学号，课名）的部分函数依赖。对于（学号，课名） → 系主任，有 学号 → 系主任，存在非主属性 对码（学号，课名）的部分函数依赖。所以表3存在非主属性对于码的部分函数依赖，最高只符合1NF的要求，不符合2NF的要求。

为了让表3符合2NF的要求，我们必须消除这些部分函数依赖，只有一个办法，就是将大数据表拆分成两个或者更多个更小的数据表，在拆分的过程中，要达到更高一级范式的要求，这个过程叫做”模式分解“。

例如，可以对上表分解为两个表：选课(学号，课名，分数)、学生（学号，姓名，系名，系主任）

5.缺点
仅仅符合2NF的要求，很多情况下还是不够的，而出现问题的原因，在于仍然存在非主属性系主任对于码学号的传递函数依赖。

第三范式

第三范式（3NF） 3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。

例，将上表分成三个表：选课(学号，课名，分数)、学生（学号，姓名，系名）、系（系名，系主任）

由此可见，符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。
当然，在实际中，往往为了性能上或者应对扩展的需要，经常 做到2NF或者1NF，但是作为数据库设计人员，至少应该知道，3NF的要求是怎样的。