函数依赖与范式分解-优快云博客

8.3使用函数依赖进行分解

在8.1节中，我们注意到有一个正规的方法判断一个关系模式是否应该分解。这种方法是基于码和函数依赖的概念。

在讨论关系数据库设计的算法时，我们需要讨论任意关系及其模式，而不是只讨论示例。回顾我们在第2章中对关系模型的介绍，我们在这里总结了我们的表示法。

一般来说，我们用希腊字母来表示属性集（例如α，）。我们使用小写的罗马字母，后面加上大写的罗马字母，表示一个关系模式（例如，r（R））。我们使用符号r（R）显示模式是关系r，R表示属性集，但有时简化符号只使用R的关系时，名字与我们无关。

当然，一个关系是一个属性集，但并不是所有属性集都是模式。当我们使用小写希腊字母时，我们是指一个有可能的模式也可能不是模式的属性集。罗马字母是用来当我们希望表明属性集是一个模式。

当一组属性是一个超码时，我们用K表示它，超码属于特殊的关系模式，所以我们使用术语“K是一个r（R）的超码”。

我们使用小写名称来表示关系。在我们的例子中，这些名字有实际的含义（例如，教师），而在我们的定义和算法中，我们使用单字母，比如r。

当然,一个关系在任何给定的时间都有特定的值，我们将那看作一个实例并使用术语“r的实例。”我们正在谈论的实例它是明确的，我们可以仅用关系名称（例如，R）。

8.3.1 码和函数的依赖

数据库建模现实世界中的一组实体和联系。现实世界中的数据通常有各种各样的约束（规则）。例如，在一个大学数据库中预计要保证的一些约束有：

1. 学生和教师通过他们的ID唯一标识。

2. 每个学生和教师只有一个名字。

3. 每个教师和学生只（主要）关联一个系。

4. 每个系的预算只有一个值，只有一个相关的办公楼。

一个实例是：能满足所有现实世界的约束称为关系的一种合法法律的实例；在一个数据库的实例中所有关系实例都是合法实例。

几种最常用的现实世界约束可以形式化地表示为码（超码、候选码以及主码），或者下面所定义的函数依赖。

在2.3节中，曾经定义一个超码的概念作为一个或多个属性设置，在这里重新表述该定义如下：令r(R）是一个关系模式。R的子集K是r（R）的超码的条件是，在任何关系r（R）的任意合法实例中，所有对t1和t2的元组在r的实例中，如果t1 ≠ t2，则t1 [K] ≠t2 [ k ]。也就是说，任何关系R（R）的任何合法实例中没有两个元组可能具有相同的值。显然，如果r中没有两条元素组在K上具有相同的值，那么在r中一个K值唯一标识一条元组。

而作为一个超码是一组属性，唯一确定整个元组的属性集，函数依赖让我们可以表达唯一确定的某些属性的值的约束。考虑一个关系模式r（R），让α⊆R和β⊆R。

给定r(R)的一个实例，我们说实例满足的函数依赖α→β的条件是：对实例中的所有元组对t1和t2，若t1[α]=t2[α],t1[β]=t2[β]。

我们说函数依赖α→β在r(R)的每个合法实例中都满足，则该函数在模式r（R）上成立。

使用函数依赖这个概念，我们可以认为如果函数依赖K→R在r(R)上成立，那么K是r(R)的一个超码。换作其他话来说，如果对于r(R)的每个合法实例，对于实例中每个元组对t1 和t2，不论怎样都有t1[K] =t2[K]，或者总有t1[R] = t2[R]（也就是t1 =t2），那么K就是一个超码。

函数依赖允许我们表示不能用超码表示的约束。在8.1.2节中，我们考虑

到这个图示：inst dept (ID, name, salary, deptname, building, budget)

在这个图示中函数依赖dept name → budget成立因为对于每个系（被部门名称所标识的）存在着唯一的预算数额。

我们将属性对于(ID, dept name)的一个超码这一事实记作ID, dept name→name, salary, building, budget

我们会用两种方式使用函数依赖：

1 测试判定关系实例是否能够满足所给的函数依赖集F

2 为了说明合法关系集上的约束。因此我们应该关心满足所给函数依赖集的那些关系实例。如果我们希望只是考虑R哈桑满足函数依赖集F的关系，那么我们说F在r(R)上成立。

让我们考虑图8.4中r的关系实例，看它能够满足什么函数依赖。我们可以观察到A→C是满足的，这里有两个元组的A值是a1。这些元组具有相同的C值c1，相同的，A值为a2的两个元组具有相同的C值，c2。这里没有其他元组对具有的相同的A值。然而函数依赖C → A是不满足的。为了看是否是这样，考虑元组st1 =(a2,b3,c2,d3)和t2=(a3,b3,c2,d4)

这两个元组有一样的C值, c2，但是他们有不一样的A值a2 和a3，因此，我们找到了一对元组t1 和 t2，t1[C] =t2[C]但是t1[A] ≠t2[A]。

有些函数依赖称为平凡的（trivial），因为他们在所有的关系中都满足。例如，A→A在所有包含属性A的关系中满足，从字面上看函数依赖的定义，我们知道，所有元组的t1[A]=t2[A]的元组t1和t2，在这种情况下，有t1 = t2。同样的，AB→A满足所有包含属性A的关系。涉及属性的一般功能的依赖，如果α⊆β，则形如α→β的函数依赖是平凡的。

重要的是，要认识到一个关系实例可以满足一些关系依赖性，而这些依赖关系不需要在关系模式中保持。在图8.5课堂关系的实例中，我们看到的容量→capacity是满足的。但是，我们相信，在现实世界中，不同建筑里的两间教室可以有相同的房间数和不同容量室。因此，有时候可能存在一个classroom关系的实例。所以，我们不将room-number→capacity包含于classroom关系的模式上成立的函数依赖集中。然而，我们期望的函数依赖buidling,room-number→capacity在classroom模式上建立。

给定函数依赖集F是在关系r（R）上成立，可以推断出某些其他的函数依赖也一定在该关系上成立。例如，给定一个模式r（A，B，C），如果函数依赖A→B和B→C在r上成立，我们可以推断函数依赖A→C也一定在r上成立。这是因为，给定A的任意值，仅仅存在B只有一个对应的值，只能有一个C对应的值，我们后面将在8.4.1节学习如何做出这样的推论。

我们将使用符号F＋表示集合F的闭包，也就是集合中可以推断出的所有函数依赖的集合。F+清楚地包含了F.中所有的函数依赖。

8.3.2Boyce–Codd 范式

我们能够达到的比较满意的其中一个是 Boyce–Codd 范式。它消除了所有函数依赖上的所被观察到的冗余，虽然，正如我们在8.6节中看到的，这里可能有其他类型的冗余存在。关系模式R的函数依赖集属于BCNF的条件是，对于F+ 中所有如α→β的函数依赖，且α⊆R和β⊆R，至少满足下面的一项。

•α →β是平常的函数依赖（也就是，β ⊆ α）

•α是模式R的一个超码

如果构成一个关系模式集中的每个模式都属于BCNF那么这个数据库设计属于BCNF。

我们已经在8.1节中见过见过了不属于BCNF的关系模式的例子：inst dept (ID, name, salary, dept name, building, budget)

函数依赖 dept name→budget 在 inst dept上成立，但是tdept name 不是一个超码（因为，一个系中可以有很多不同的教师）在8.1.2节中，我们看到把 inst dept 拆分为 instructor 和 department 是一个更好的设计。模式 instructor 属于有BCNF。所有的成立的非平凡函数依赖，例如：ID→name, dept name,salary

在箭头的左侧包含ID,并且ID是一个超码（实际上，在这个例子中它是一个主码）（换句话来说，在不包含ID的另一侧上，对于 name, dept name, 和salary的任意组合不存在非平凡的函数依赖），因此，教师属于BCNF。

相同的，department模式属于BCNF因为所有成立的非平凡函数依赖，例如dept name→building, budget

在箭头的左侧包含部门名称，并且部门名称对于系来说是一个超码（并且是一个主码）因此department属于BCNF。

我们现在来讲述分解不属于BCNF模式的一般规则，让R成为一个不属于BCNF的一个模式。那么这里就至少有一个非平凡函数依赖α → β比如α不是R的一个超码。我们在我们的设计中用两种模式来替代R：

•（α∪β）

•（R-（β-α））

在这个例子中，α=dept name,β={building, budget},并且dinst dept被替代为

• （α∪β）=(dept name, building,budget)

• (R-（α−β)) = (ID, name, dept name,salary)

在这个例子中，结果是β-α=β。我们需要像上面一样表达规则，然后正确处理箭头两边都有出现的属性的函数依赖。我们将会在8.5.1节中介绍技术的原因。

当我们分离不属于BCNF模式时，他可能有一个或多个产生的模式是不属于BCNF的。在这种情况中，需要进一步的分解，最终结果是一个BCNF的模式结合。

8.3.3 BCNF和保持依赖

我们见过很多种表示数据库一致性约束的方式：主码约束，函数依赖，check约束，断言和触发器。每次在更新数据库是检查这些鞋约束时的开销很大，因此，把数据库设计能够有效的检查约束是非常有用的。特别的，如果函数依赖的检验只用一个关系就可以完成，那么检查的费用就会很低。我们会看到有些情况下，BCNF的分解会妨碍对某些函数依赖的高校检查。

为了证明这个，假定我们对大学机构做一个小的改动。在图7-15的设计中，一个学生可能只有一位导师。这是从学生和导师是多对一关系推断来的。我们要做的小改动就是一个教师只能和一个系关联，并且一个学生可以有多个导师，但是对应于一个给定的系最多只有一个约束。

用ER设计去实现这个改变的一种方法是，如图8.6所示，把联系集advisor替代为涉及实体集instrutor，stuedent，和department的三元联系集dept advisor，它是从{student,instructor}对到 department多对一的。

对应于新的ER图， instructor, department, 和student 的模式没有改变。然而，从dept advisor导出的模式现在为：

dept advisor (s ID, i ID, dept name)

虽然没在ER图中表明，我们假定我们有附加的约束一个教师只能在一个系担任导师。

那么，下面的函数依赖在dept advisor上成立。

第一个函数依赖由我们的需求“一个教师只能在一个系担任导师”产生。第二个函数依赖有我们的需求“对一个给定的系，一个学生最多有一个导师”

注意这个设计，每次一名教师参与一个 dept advisor 联系的时候，我们都不得不重复一次系的名称。我们可以看到dept advisor 不属于BCNF因为 i ID 不是超码。根据BCNF分解原则我们可以得到(s ID, i ID) (i ID, dept name)。

上面的模式都属于BCNF（事实上，你可以验证，按照任何定义只包含两个属性的模式都属于BCNF。）但是要注意的是，在BCNF的设计中，这里没有一个模式包含函数依赖 s ID, dept name→iID.中出现的所有属性。

因为我们的设计使这个函数依赖的强制实施在计算上非常困难，因此我们称我们的设计不是保持依赖，由于常希望保持依赖，所以我们考虑另一种比BCNF弱的范式，它允许我们我们保持依赖，这种范式称为第三范式。

8.3.4第三范式

BCNF要求所有非平凡函数依赖都是α→β，其中α是一个超码。第三范式（3NF）稍微放宽了这个约束，它允许某些非平凡函数依赖的左边不是一个超码。在我们定义第三范式之前，我们回想到候选码是最小的超码——任何一个真子集都不是超码的超码。

具有函数依赖集F的关系模式R属于第三范式的条件是：对于F﹢中有像是α→β的函数依赖（其中α⊆ R，β⊆ R）至少拥有以下一个：

l α→β是一个平凡的函数依赖。

l α是R的一个超码。

l β﹣α中的每一个超码都包含于R的一个候选码中。

注意上面的第三个条件并不是说单个候选键必须包含β﹣α的所有属性；β﹣α中的属性A可以包含于不同的候选码中。

前两个条件与BCNF定义中的两个条件相同。3NF定义中的第三个条件看起来似乎很不直观，而且它的用途也不是很明显。在某种意义上，它代表着BCNF的最小放宽，以确保每个模式都有保持依赖的3NF分解。它的用途在我们介绍3NF分解之后会变得更清晰。

注意任何满足BCNF的模式也满足3NF，因为它的每个函数依赖都将满足前两个条件之一。BCNF因此是一个比3NF更严格的范式。

3NF定义中允许某些BCNF中不允许的函数依赖，只满足3NF定义中第三条件的依赖α→β在BCNF中是不允许的，但在3NF中是允许的。

现在我们再考虑联系集，dept-advisor，它具有以下函数依赖：

I_ID→ dept_name

s_ID,dept_name → i_ID

在8.3.3中我们说到“i_ID → dept_name”导致dept_advisor模式不属于BCNF。注意这里α=i_ID，β=dept_name，并且β﹣α=dept_name。由于函数依赖s_ID, dept_name → i_ID在dept-advisor上成立，于是属性dept_name包含于一个候选码中，因此dept-advisor属于3NF。

我们已经看到，当没有保持依赖的BCNF模式设计时，必须在BCNF和3NF中权衡。这些权衡将在8.3.5小节详细介绍。

8.3.5 更高的范式

在某些情况下，使用函数依赖分解模式可以避免不必要的信息重复。考虑在instructor实体集中定义的小变化，我们为每个教师记录一组孩子的名字和一组电话号码。电话号码可以被多人共享。因此，phone_number和child_name将是多值属性，下面我们从E-R设计生成模式的规则，我们将有两种模式，多值属性phone_number和child_name中的每个属性对应一个模式：

（ID,child_name）

（ID,phone_number）

如果我们合并这些模式来得到：

（ID,child_name，phone_number）

我们会发现这个结果只属于BCNF，因为只有非平凡函数依赖。因此，我们可能认为这样的组合是个好主意。然而，我们可以从一个有两个孩子和两个电话号码的教练的例子中看出，我们会发现这样合并可能是一个坏主意。例如，让ID为99999的教师有两个孩子取名为“David”和“William”。两个电话号码，512-555-1234和512-555-4321。在组合模式中，我们必须为每个依赖项重复一次电话号码：

(99999, David,512-555-1234)

(99999, David,512-555-4321)

(99999,William, 512-555-1234)

(99999,William, 512-555-4321)

如果我们不重复的电话号码，且只储存的第一个和最后一个元组，我们就记录相关的名字和电话号码。但是结果将元组将暗指David和512-555-1234对应。而William和512-555-4321对应。但我们知道，这是不正确。