我在很久之前的一篇文章中介绍了数据库模型设计中的基本三范式,今天,我来说一说更高级的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),第五范式处理的是无损连接问题,这个范式基本没有实际意义,因为无损连接很少出现,而且难以察觉。而域键范式试图定义一个终极范式,该范式考虑所有的依赖和约束类型,但是实用价值也是最小的,只存在理论研究中。