数据库设计范式（二）之巴斯范式第四范式第五范式以及域键范式

概述

1.案例

2.是否符合三范式

3.存在的问题

4.问题解决

第四范式（了解即可）

第五范式、域键范式（了解即可）

小结

概述

之前我们讲过数据库设计范式的第一范式，第二范式以及第三范式，以及还说了在实际业务需求中如何使用反范式优化我们的查询。这篇文章我们来谈一下巴斯范式以及第四范式和第五范式。

人们在三范式的基础上进行了改进，提出巴斯范式，也叫做巴斯-科德范式。巴斯范式被认为没有新的设计加入，仅仅是对第三范式中的设计规范要求更强，使得数据库冗余度更小。所以，称为是修正的第三范式或扩充的第三范式，不被称为第四范式。

若一个关系达到第三范式，并且它只有一个候选键或者它的每个候选键都是单属性，则该关系自然就达到巴斯范式。

我们分析如下表的范式情况：

在这个表中，一个仓库只有一个管理员，同时一个管理员也只是管理一个仓库，我们先来梳理下这些属性之间的依赖关系。

仓库名决定了管理员，管理员也决定了仓库名，同时（仓库名，物品名）的属性集合可以决定数量这个属性。这样我们可以找到数据表的候选键了。

候选键：是（管理员，物品名）和（仓库名，物品名），然后我们从候选键选择一个作为主键，比如（仓库名，物品名）。

主属性：包含在任一候选键中的属性，也就是仓库名，管理员和物品名

非主属性：数量这个属性

如何判断一张表的范式呢？我们需要根据范式的等级，从低到高来进行判断。

首先，数据表每个属性都是原子性的，符合第一范式要求。

其次，数据表中的非主属性数量这个字段都与候选键全部依赖。因此符合第二范式。

最后，数据表中的非主属性不传递依赖于候选键，符合第三范式。

既然数据表已经符合了三范式要求，是不是就不存在问题了呢？我们来看下面的情况：

1.增加一个仓库，但是还没有存放任何物品。根据数据表实体完整性约束主键不能有空值，因此会插入异常。

2.如果仓库更换了管理员，我们可能会修改数据表中的多条记录。

3.如果仓库管理的商品被卖空了，那么此时仓库名称和对应的管理员名称也会随之被删除。

首先我们需要确认造成异常的原因：主属性仓库名对于候选键（管理员，物品名）是部分依赖关系，这样就有可能导致上面的异常情况。因此引入巴斯范式，它在三范式基础上清除了主属性对候选键的部分依赖或者传递依赖关系。

如果在关系R中，U作为主键，A属性是主键的一个属性，若存在A->Y,Y为主属性，则该关系不属于巴斯范式。

根据巴斯范式的要求，我们需要把仓库管理关系表拆成如下：

这样就不存在主属性对候选键而部分依赖，上面的表就符合巴斯范式。

多值依赖关系的概念：

多值依赖，即属性之间的一对多关系，即为k→→A。
函数依赖，事实上是单质依赖，所以不能表达属性之间的一对多关系。
平凡的多值依赖，全集U=K+A，一个K可以对应于多个A，也可以对应于多个B，A与B互相独立，即K→→A，K→→B。整个表有多组一对多关系，且有：一部分是相同的属性集合，多部分是相互独立属性集合。

第四范式即在满足巴斯范式基础上，消除非平凡函数依赖的多值依赖，即把同一表内的多对多关系删除。