关系数据库设计理论

第6章关系数据库设计理论

本章主要讲解在关系数据库的设计过程中，如何减少数据冗余，避免出现异常，该如何对数据库模式进行中心设计。

1．深入理解函数依赖和键码的概念。学会计算属性的封闭集。

2．模式设计是本章的重点。了解数据冗余和更新异常产生的根源；理解关系模式规范化的途径；准确理解第一范式、第二范式、第三范式和BC范式的含义、联系与区别；

深入理解模式分解的原则；熟练掌握模式分解的方法，能正确而熟练的将一个关系模式分解成属于第三范式或BC范式的模式。

3.了解多值依赖和第四范式的概念，掌握把关系模式分解成属于第四范式的模式的方法。

本章主要的知识点包括：

知识点1 函数依赖

知识点2 模式设计

知识点3 多值依赖

学习要点1、函数依赖

1.1函数依赖的定义

如果关系R的两个元组在属性A1，A2，… An上一致（也就是，两个元组在这些属性所对应的各个分量具有相同的值），则它们在另一个属性B上也一致。那么，我们就说在关系R中属性B函数依赖于属性A1A2…An。记做A1A2…An ，也可以说“A1，A2，…，An函数决定B”。A1A2…An称为决定因素。

举例：

在这个关系中，学号确定后，学生的姓名及所在的系就都确定了。属性中的这种依赖关系就是函数依赖。在本例中存在下列函数依赖。

•Sno SN ame

•Sno S dept

•S dept Mname

•Sno C name Grade

1.2 关系的键码如一个或多个属性的集合{A1，…，An}满足如下条件，称该集合为关系R的键码：

1. 这些属性函数决定该关系的所有其它属性。

2. {A1，…，An}的任何真子集都不能函数决定R的所有其它属性，键码必须是最小的。

1.3 超键码包含键码的属性集称为“超键码” 。

因此，每个键码都是超键码。

某些超键码不是（最小的）键码。

每个超键码都满足键码的第一个条件：函数决定它所在的关系的所有其它属性。超键码不必满足键码的第二个条件：最小化条件。

1.4 函数依赖规则分解/合并规则

可以把每个函数依赖右边的属性分解，从而使其右边只出现一个属性。同样，我们也可以把左边相同的依赖的聚集用一个依赖来表示，该依赖的左边没变，而右边则为所有属性组成的一个属性集。两种情况下，新的依赖集都等价于旧的依赖集。平凡依赖规则对于函数依赖A1A2…An B来说，如果B是A中的某一个，我们就称之为“平凡的”。

对于函数依赖A1A2…An B1B2…Bm，

如果B是A的子集，则称该依赖为平凡的。

如果B中至少有一个属性不在A中，则称该依赖为非平凡的。如果B中没有一个属性在A中，则称该依赖为完全非平凡的。

函数依赖A1A2…An B1B2…Bm等价于A1A2…An C1C2…Ck，其中C是B 的子集，但不在A中出现。

我们称这个规则为“平凡依赖规则”。举例：

下面三个函数依赖关系中

Sno Cname Grade Cname Grade

右边属性集是左边属性集的子集，根据平凡依赖的定义，这个函数依赖属于平凡依赖。

（设计人员注意：请用动画表示黄色字和蓝色字。）

Sno Cname Cname Grade

右边的Cname属性在左边的属性集Z中，而Grade属性不在左边的属性集中，这个函数依赖是非平凡依赖。

（设计人员注意：请用动画表示黄色字和蓝色字。）

Sno Cname Sname Grade

右边的属性都不在左边的属性集中，这个函数的依赖是完全非平凡依赖。

传递规则

传递规则使我们能把两个函数依赖级联成一个新的函数依赖。

如果A1A2…An B1B2…Bm和B1B2…Bm C1C2…Ck，在关系R中成立，则

A1A2…An C1C2…Ck在R中也成立。这个规则就称为传递规则。举例：对于关系Student，有如下两个依赖：

Sno Sdept

Sdept Mname

根据传递规则，可以得到一个新的依赖

Sno Mname

学习要点2 模式设计

2.1问题的提出设计关系数据库模式时，特别是从面向对象的ODL设计或从E/R设计直接向关系数据库模式转换时，很容易出现的问题是冗余性，即一个事实在多个元组中重复。

造成这种冗余的最常见的原因是，企图把一个对象的单值和多值特性包含在一个关系中。当我们企图把太多的信息存放在一个关系时，就会出现数据冗余和更新异常等问题。主要表现如下：

1．数据冗余。

2．修改异常。

3．删除异常。

4．插入异常。

举例：

1

2．修改异常：修改了一个学生对应的系主任，其他的没有修改。

3．删除异常。

删除一个学生选修的课程可能导致这个学生的全部信息丢失。

4．插入异常。

如果缺少键码属性集合中的元素，会导致不合理情况的发生。例如无法对数据库进行插入、更新等操作。

2.2问题的根源关系的键码函数决定该关系的所有其它属性。由于键码能唯一确定一个元组，所以，也可以说关系的键码函数决定该关系的所有属性。一个关系中的所有属性都函数依赖于该关系的键码。不同的属性在关系模式中所处的地位和扮演的角色是不同的。把键码所在的属性称为主属性，而把键码属性以外的属性称为非主属性。不同的属性对键码函数依赖的性质和程度是有差别的。有的属于直接依赖，有的属于间接依赖（通常称为传递依赖）。

当键码由多个属性组成时，有的属性函数依赖于整个键码属性集，而有的属性只函数依

赖于键码属性集中的一部分属性。完全依赖与部分依赖

对于函数依赖W A，如果存在

V W（V是W的真子集）而函数依赖

V A成立，则称A部分依赖于W；若不存在这种V，则称A完全依赖于W。

当存在非主属性对键码部分依赖时，就会产生数据冗余和更新异常。若非主属性对键码完全函数依赖，则不会出现类似问题。

传递依赖

对于函数依赖X Y，如果X（X不函数依赖于Y）而函数依赖Y Z成

立，则称Z对X传递依赖。

如果X Y，且Y X，则X，Y相互依赖，这时Z与X之间就不是传递依赖，而是直接依赖了。我们以前所讨论的函数依赖大多数是直接依赖。举例：

其中{Sno, Cname}为键码，函数依赖集如下：

Sno Sname,Sdept;

Sdept Mname;

Sno Mname;

p

Sno, Cname

f

Sno,Cname Grade

分析可得：

Sname，Sdept，Mname函数依赖于Sno，部分依赖于键码；

Grade完全依赖于键码。

则

对键码完全依赖的Grade没有任何冗余；

对键码部分依赖的属性Sname，Sdept，Mname存在大量的数据冗余，并且有可能出现更新异常。

Mname传递依赖于Sno，当一个学生选修多门课程的时候，系主任的名字会多次重复出现，并有可能出现更新异常。

结论：

（1）在一个关系模式中，当存在非主属性对键码的部分依赖时，就会产生数据冗余和更新异常。

（2）在一个关系模式中，当存在非主属性对键码的传递依赖时，就会产生数据冗余和更新异常。

（3）主属性对键码的部分依赖和传递依赖也会导致产生数据冗余和更新异常。

2.3 解决的途径部分依赖和传递依赖有一个共同之处，这就是，二者都不是基本的函数依赖，而都是导出的函数依赖。部分依赖是以对键码的某个真子集的依赖为基础；