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