数据库设计范式2——BC范式和第四范式

我在很久之前的一篇文章中介绍了数据库模型设计中的基本三范式，今天，我来说一说更高级的BC范式和第四范式。

回顾

我用大白话来回顾一下什么是三范式：

第一范式：每个表应该有唯一标识每一行的主键。

第二范式：在复合主键的情况下，非主键部分不应该依赖于部分主键。

第三范式：非主键之间不应该有依赖关系。

这是我们设计数据库的基本规则，但是只有这三个规则并不能完全解决数据的增删改的异常情况，下面就来看看BC范式的例子。

BC范式

BC范式（BCNF）是Boyce-Codd范式的缩写，其定义是：在关系模式中每一个决定因素都包含候选键，也就是说，只要属性或属性组A能够决定任何一个属性B，则A的子集中必须有候选键。BCNF范式排除了任何属性(不光是非主属性，2NF和3NF所限制的都是非主属性)对候选键的传递依赖与部分依赖。

比如我们有一个学生导师表，其中包含字段：学生ID，专业，导师，专业GPA，这其中学生ID和专业是联合主键。

StudentId	Major	Advisor	MajGPA
1	人工智能	Edward	4.0
2	大数据	William	3.8
1	大数据	William	3.7
3	大数据	Joseph	4.0

这个表的设计满足三范式，有主键，不存在主键的部分依赖，不存在非主键的传递依赖。但是这里存在另一个依赖关系，“专业”函数依赖于“导师”，也就是说每个导师只做一个专业方面的导师，只要知道了是哪个导师，我们自然就知道是哪个专业的了。

所以这个表的部分主键依赖于非主键部分，那么我们可以进行以下的调整，拆分成2个表：

学生导师表：

StudentId	Advisor	MajGPA
1	Edward	4.0
2	William	3.8
1	William	3.7
3	Joseph	4.0

导师表：

Advisor	Major
Edward	人工智能
William	大数据
Joseph	大数据

 

第四范式

如果满足了BC范式，那么就不再会有任何由于函数依赖导致的异常，但是我们还可能会遇到由于多值依赖导致的异常。

比如我们建立课程教师和教材的模型，我们规定，每门课程有对应的一组教师，每门课程也有对应的一组教材，一门课程使用的教程和教师没有关系。这样我们首先肯定有三个实体表，分别表示课程，教师和教材。现在我们要建立这三个对象的关系，于是我们建立的关系表，定义如下：

课程ID，教师ID，教程ID；这三列作为联合主键。

以下是示例，为了表述方便，我们用Name代替ID，这样更容易看懂：

Course	Teacher	Book
英语	Bill	人教版英语
英语	Bill	美版英语
英语	Jay	美版英语
高数	William	人教版高数
高数	Dave	美版高数

这个表除了主键，就没有其他字段了，所以肯定满足BC范式，但是却存在多值依赖导致的异常。

我们先来看看多值依赖的定义：

一个关系，至少存在三个属性（A、B、C），才能存在这种关系。对于每一个A值，有一组确定的B值和C值，并且这组B的值独立于这组C的值。

假如我们下学期想采用一本新的英版高数教材，但是还没确定具体哪个老师来教，那么我们就无法在这个表中维护Course高数和Book英版高数教材的的关系。

解决办法是我们把这个多值依赖的表拆解成2个表，分别建立关系。这是我们拆分后的表：

Course	Teacher
英语	Bill
英语	Jay
高数	William
高数	Dave

 

Course	Book
英语	人教版英语
英语	美版英语
高数	人教版高数
高数	美版高数

第四范式的定义很简单：已经是BC范式，并且不包含多值依赖关系。

除了第四范式外，我们还有更高级的第五范式和域键范式（DKNF），第五范式处理的是无损连接问题，这个范式基本没有实际意义，因为无损连接很少出现，而且难以察觉。而域键范式试图定义一个终极范式，该范式考虑所有的依赖和约束类型，但是实用价值也是最小的，只存在理论研究中。