数据库——范式

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

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

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

回过来看2NF了。首先，我们需要判断，表3是否符合2NF的要求？根据2NF的定义，判断的依据实际上就是看数据表中是否存在非主属性对于码的部分函数依赖。若存在，则数据表最高只符合1NF的要求，若不存在，则符合2NF的要求。判断的方法是：

第一步：找出数据表中所有的码。第二步：根据第一步所得到的码，找出所有的主属性。第三步：数据表中，除去所有的主属性，剩下的就都是非主属性了。第四步：查看是否存在非主属性对码的部分函数依赖。

对于表3，根据前面所说的四步，我们可以这么做：

第一步：

1. 查看所有每一单个属性，当它的值确定了，是否剩下的所有属性值都能确定。
2. 查看所有包含有两个属性的属性组，当它的值确定了，是否剩下的所有属性值都能确定。
3. ……
4. 查看所有包含了六个属性，也就是所有属性的属性组，当它的值确定了，是否剩下的所有属性值都能确定。

图4

这一步完成以后，可以得到，表3的码只有一个，就是（学号、课名）。

第二步：主属性有两个：学号 与 课名

第三步：非主属性有四个：姓名、系名、系主任、分数

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

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

为了让表3符合2NF的要求，我们必须消除这些部分函数依赖，只有一个办法，就是将大数据表拆分成两个或者更多个更小的数据表，在拆分的过程中，要达到更高一级范式的要求，这个过程叫做”模式分解“。模式分解的方法不是唯一的，以下是其中一种方法：选课（学号，课名，分数）学生（学号，姓名，系名，系主任）

（这里还涉及到一个如何进行模式分解才是正确的知识点，先不介绍了）

现在我们来看一下，进行同样的操作，是否还存在着之前的那些问题？

1. 李小明转系到法律系只需要修改一次李小明对应的系的值即可。——有改进
2. 数据冗余是否减少了？学生的姓名、系名与系主任，不再像之前一样重复那么多次了。——有改进
3. 删除某个系中所有的学生记录该系的信息仍然全部丢失。——无改进
4. 插入一个尚无学生的新系的信息。因为学生表的码是学号，不能为空，所以此操作不被允许。——无改进

所以说，仅仅符合2NF的要求，很多情况下还是不够的，而出现问题的原因，在于仍然存在非主属性系主任对于码学号的传递函数依赖。为了能进一步解决这些问题，我们还需要将符合2NF要求的数据表改进为符合3NF的要求。

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

对于选课表，符合3NF的要求，之前已经分析过了。

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

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

BCNF范式

要了解 BCNF 范式，那么先看这样一个问题：

若：

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

那么关系模式 仓库（仓库名，管理员，物品名，数量） 属于哪一级范式？（步骤：先找出函数依赖集）

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

好，既然此关系模式已经属于了 3NF，那么这个关系模式是否存在问题呢？我们来看以下几种操作：

1. 先新增加一个仓库，但尚未存放任何物品，是否可以为该仓库指派管理员？——不可以，因为物品名也是主属性，根据实体完整性的要求，主属性不能为空。
2. 某仓库被清空后，需要删除所有与这个仓库相关的物品存放记录，会带来什么问题？——仓库本身与管理员的信息也被随之删除了。
3. 如果某仓库更换了管理员，会带来什么问题？——这个仓库有几条物品存放记录，就要修改多少次管理员信息。

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

造成此问题的原因：存在着主属性对于码的部分函数依赖与传递函数依赖。（在此例中就是存在主属性【仓库名】对于码【（管理员，物品名）】的部分函数依赖。

解决办法就是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。

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

这样，之前的插入异常，修改异常与删除异常的问题就被解决了。

以上就是关于 BCNF 的解释。

作者：知乎用户
链接：https://www.zhihu.com/question/24696366/answer/29189700
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。