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

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

回顾

我用大白话来回顾一下什么是三范式:数据库

第一范式:每一个表应该有惟一标识每一行的主键。函数

第二范式:在复合主键的状况下,非主键部分不该该依赖于部分主键。大数据

第三范式:非主键之间不该该有依赖关系。人工智能

这是咱们设计数据库的基本规则,可是只有这三个规则并不能彻底解决数据的增删改的异常状况,下面就来看看BC范式的例子。spa

BC范式

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

好比咱们有一个学生导师表,其中包含字段:学生ID,专业,导师,专业GPA,这其中学生ID和专业是联合主键。htm

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

这个表的设计知足三范式,有主键,不存在主键的部分依赖,不存在非主键的传递依赖。可是这里存在另外一个依赖关系,“专业”函数依赖于“导师”,也就是说每一个导师只作一个专业方面的导师,只要知道了是哪一个导师,咱们天然就知道是哪一个专业的了。对象

因此这个表的部分主键依赖于非主键部分,那么咱们能够进行如下的调整,拆分红2个表:blog

学生导师表:

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),第五范式处理的是无损链接问题,这个范式基本没有实际意义,由于无损链接不多出现,并且难以察觉。而域键范式试图定义一个终极范式,该范式考虑全部的依赖和约束类型,可是实用价值也是最小的,只存在理论研究中。

相关文章
相关标签/搜索