---

前言

本文转载于：https://zhuanlan.zhihu.com/p/20028672

在阅读本文时，可以把“关系”理解为数据表。此外还有一个“关系模式”的概念。“关系”和“关系模式”的区别，类似于面向对象程序设计中”类“与”对象“的区别。”关系“是”关系模式“的一个实例，你可以把”关系”理解为一张带数据的表，而“关系模式”是这张数据表的表结构。

一、函数依赖

我们可以这么理解（但并不是特别严格的定义）：若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。也就是说，在数据表中，不存在任意两条记录，它们在X属性（或属性组）上的值相同，而在Y属性上的值不同。这也就是“函数依赖”名字的由来，类似于函数关系 y = f(x)，在x的值确定的情况下，y的值一定是确定的。

对于A->B,如果能找到A的真子集A’, 使得A’ -> B, 那么A->B就是部分函数依赖，否则就是完全函数依赖。

比如完全函数依赖： 学号->姓名
部分函数依赖: (学号，课号) -> 姓名

对于A->B,B->C,则A->C是一个传递函数依赖。

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

主属性
包含在任意一个码中的属性称为主属性。

非主属性
不包含在任何一个码中的属性称为非主属性。

例如：
对于表3，主属性就有两个，学号 与 课名。其余的属性都是非主属性。

二、异常

假设给定这样的一张表，其中存在以下的学生课程关系的函数依赖为{Sno,Cname} -> {Sname,Sdept,Mname, Grade}，键码为 {Sno, Cname}。也就是说，确定学生和课程之后，就能确定其它信息.

然而，不符合第一范式（等下会讲到）的关系，会产生很多异常，主要有以下四种异常：

1. 冗余数据：比如每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次——数据冗余过大。

2. 修改异常：假如李小明转系到法律系，那么为了保证数据库中数据的一致性，需要修改三条记录中系与系主任的数据。——修改异常。

3. 删除异常：假如将某个系中所有学生相关的记录都删除，那么这个系中所有系与系主任的数据也就随之消失了（一个系所有学生都没有了，并不表示这个系就没有了）。——删除异常

4. 插入异常：假如学校新建了一个系，但是暂时还没有招收任何学生（比如3月份就新建了，但要等到8月份才招生），那么是无法将系名与系主任的数据单独地添加到数据表中去的

三、第一范式

1NF的定义为：符合1NF的关系中的每个属性都不可再分。比如下表所示的情况，就不符合1NF的要求.

1NF是所有关系型数据库的最基本要求，你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作一定是不能成功的。也就是说，只要在RDBMS中已经存在的数据表，一定是符合1NF的。如果把上述表修改成下表的形式，则符合第一范式。

四、第二范式

第二范式（2NF）指的是在1NF的基础之上，消除了非主属性对于码的部分函数依赖。
比如对于上表，下图表示了表中的所有函数依赖关系：

红色箭头表示的是传递函数依赖。

我们可以看到，上表3的码只有一个就是（学号，姓名）。主属性有两个：学号和姓名，非主属性有四个：姓名、系名、系主任、分数。

对于（学号，课名） → 姓名，有 学号 → 姓名，存在非主属性 姓名 对码（学号，课名）的部分函数依赖。
对于（学号，课名） → 系名，有 学号 → 系名，存在非主属性 系名 对码（学号，课名）的部分函数依赖。
对于（学号，课名） → 系主任，有 学号 → 系主任，存在非主属性 对码（学号，课名）的部分函数依赖。

所以表3存在非主属性对于码的部分函数依赖，最高只符合1NF的要求，不符合2NF的要求。

为了让表3符合符合2NF的要求，我们必须消除这些部分函数依赖，只有一个方法，那就是将大数据表拆分成两个或者更多个更小的数据表，在拆分的过程中，要达到更高一级别范式要的要求，这个过程叫做“模式分解”，比如针对上表来说，一种可行的模式分解方法为：

选课（学号，课名，分数）
学生（学号，姓名，系名，系主任）

对于选课表，其码是（学号，课名），主属性是学号和课名，非主属性是分数，学号确定，并不能唯一确定分数，课名确定，也不能唯一确定分数，所以不存在非主属性分数对于码 （学号，课名）的部分函数依赖，所以此表符合2NF的要求。

对于学生表，其码是学号，主属性是学号，非主属性是姓名、系名和系主任，因为码只有一个属性，所以不可能存在非主属性对于码 的部分函数依赖，所以此表符合2NF的要求。

下图表示了模式分解以后的新的函数依赖关系

下表表示了模式分解以后的新的数据，我们计作表4

我们再回过头来看第一范式中存在的四个异常，我们可以发现经过分表之后，冗余数据和修改异常得到了改进，但是删除异常和插入异常仍然没有得到改进

1. 冗余数据：学生的姓名、系名与系主任，不再像之前一样重复那么多次了。——有改进

2. 修改异常：只需要修改一次李小明对应的系的值即可。——有改进

3. 删除异常：该系的信息仍然全部丢失。——无改进

4. 插入异常：因为学生表的码是学号，不能为空，所以此操作不被允许。——无改进

所以说，如果一个关系只能符合2NF，仍然是不够的，其本质原因是2NF虽然解决了非主属性对于码的部分函数依赖但是没有解决非主属性对于码的传递函数依赖。

五、第三范式

3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。
在表4中，对于选课表，主码为（学号，课名），主属性为学号和课名，非主属性只有一个，为分数，不可能存在传递函数依赖，所以选课表的设计，符合3NF的要求。

对于学生表，主码为学号，主属性为学号，非主属性为姓名、系名和系主任。因为 学号 → 系名，同时 系名 → 系主任，所以存在非主属性系主任对于码学号的传递函数依赖，所以学生表的设计，不符合3NF的要求。因此我们需要对学生表进行进一步的拆分。

为了让数据表设计达到3NF，我们必须进一步进行模式分解为以下形式：
选课（学号，课名，分数）
学生（学号，姓名，系名）
系（系名，系主任）

对于学生表，码为学号，主属性为学号，非主属性为系名，不可能存在非主属性对于码的传递函数依赖，所以符合3NF的要求。

对于系表，码为系名，主属性为系名，非主属性为系主任，不可能存在非主属性对于码的传递函数依赖（至少要有三个属性才可能存在传递函数依赖关系），所以符合3NF的要求。

现在我们回过头来看，第一范式中的四个异常是否得到了解决：
1.删除某个系中所有的学生记录
该系的信息不会丢失。——有改进
2.插入一个尚无学生的新系的信息。
因为系表与学生表目前是独立的两张表，所以不影响。——有改进
3.数据冗余更加少了。——2NF中就已经有改进了。
4.修改异常。——2NF中就已经有改进了。

六、BC范式

我们给定这样一个表：
1.某个公司有若干个仓库。
2.每一个仓库只能有一名管理员，且一名管理员只能在一个仓库中工作。
3.一个仓库中可以存放多种物品，一种物品也可以存放在不同的仓库中。每种物品在每个仓库中都有对应的数量。

那么关系模式 仓库（仓库名，管理员，物品名，数量） 属于哪一级范式？

答：已知函数依赖集：仓库名 → 管理员，管理员 → 仓库名，（仓库名，物品名）→ 数量
码：（管理员，物品名），（仓库名，物品名）
主属性：仓库名、管理员、物品名
非主属性：数量
由于 不存在非主属性对码的部分函数依赖和传递函数依赖，因此此关系模式属于3NF。

然而，该关系在以下场景下会出现问题：

1. 先新增加一个仓库，但是尚未存放任何东西，此时依据实体完整性的要求，由于物品名是主属性，所以不能为该仓库指派管理员。
2. 某仓库被清空之后，需要删除所有和这个仓库相关的物品存放记录，那么仓库本身和管理员的信息也被随之删除了。
3. 如果某个仓库更换了管理员，那么这个仓库有几条物品存放记录，就要修改几次管理员信息。

从这里我们可以得出结论，在某些特殊情况下，即使关系模式符合 3NF 的要求，仍然存在着插入异常，修改异常与删除异常的问题，仍然不是 ”好“ 的设计。

造成此问题的原因：存在着主属性对于码的部分函数依赖与传递函数依赖（注意之前的是2NF和3NF解决的是非主属性对于码的部分函数依赖和传递函数依赖。（在此例中就是存在主属性【仓库名】对于码【（管理员，物品名）】的部分函数依赖。其解决方法就是要在3NF的基础上消除主属性对于码的部分和传递函数依赖。

比如说，我们可以把这个表进一步分解成夏利啊两张表就可以解决问题：

仓库（仓库名，管理员）
库存（仓库名，物品名，数量）

这样之前说的问题就都可以被解决了。

---