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

概述

巴斯范式

1.案例

2.是否符合三范式

3.存在的问题

4.问题解决

第四范式（了解即可）

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

小结

概述

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

巴斯范式

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

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

1.案例

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

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

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

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

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

非主属性：数量这个属性

2.是否符合三范式

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

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

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

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

3.存在的问题

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

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

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

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

4.问题解决

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

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

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

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

第四范式（了解即可）

多值依赖关系的概念：

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

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

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

除了第四范式我们还有更高级的第五范式和域键范式

在满足第四范式的基础上消除不是由候选键索蕴含的连续依赖。如果关系模式R中每一个连接依赖均由R的候选键蕴含则称此关系模式符合第五范式。

函数依赖是多值依赖的一种特殊情况，而多值依赖实际上是连接依赖的一种特殊情况。但连接依赖不像是函数依赖和多值依赖可以由语义直接导出，而是在关系连接运算时才反映出来。存在连接依赖关系模式仍可能遇到数据冗余插入、修改、删除异常等问题。

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

小结

我们在实际开发中一般只考虑第一到第三范式即可或者再加上一个巴斯范式。因为越往后拆的表就越多从而导致查询的连接就越多。