Database.System.Concepts(6th.Edition.2010)-8.3

来源：《DatabaseSystem Concepts》，

作者：

亚伯拉罕Silberschatz耶鲁大学

亨利·科尔斯·列高大学

孟买，S.苏达山印度理工学院



8.3.2 BCNF

我们能得到的最理想的范式之一是BCNF。它消除了基于功能依赖的所有冗余，但是，正如我们将在8.6部分中看到的，可能还有其他类型的冗余。一个关系模式R在BCNF中，关于函数依赖关系的集合F，如果，对于F+形式的所有函数依赖性α→β，α⊆R和α⊆R，至少有一个是这样的：

α→β是一个微不足道的函数依赖项（也就是β⊆α ）。

α模式R的超码

如果在BCNF中组成了设计的关系模式集的每个成员，那么数据库设计就是在BCNF中。

我们已经在8.1部分中看到了一个关系模式的例子，它不在BCNF:

Inst_ dept (ID, name, salary, dept name,building, budget)

函数依赖Inst_dept→budget继续Inst_dept，但是Inst_ dept并不是一个超码（因为一个部门可能有很多不同的指导者）。在8.1.2部分中，我们看到inst_dept分解为nstructor 和department是一个更好的设计。讲师范式在BCNF中。所有包含的非平凡的函数依赖项，例如：ID→name, dept_name, salary

在箭头的左边包含ID，ID是一个用于讲师超码（实际上，在本例中是主键）。（换句话说，不存在任何不重要的函数依赖和组合关于name,dept_name, andsalary,没有ID，就在一边。）因此，讲师在BCNF中。

类似地，department模式是在BCNF中，因为所有的重要的函数依赖项，例如：

dept name→building, budget

在箭头的左边包含dept _name，dept _name是一个用于部门的超码（和主键）。

因此,部门在BCNF中。

现在我们声明一个用于分解的一般规则不是在BCNF中。让R成为不在BCNF中的模式。然后至少有一个非平凡的函数依赖项α→β，α不是r的超码。我们用两种模式代替了R。

（α∪β）

（R-（β-α）

以dept _name为例，[1]α=dept_ name, β ={building, budget}, 和inst _dept被取代

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

（R-（β-α）= (ID, name, dept_name, salary)

在这个例子中, 证明了β-α=β。我们需要像我们那样声明规则，以便正确地处理具有出现在箭头两端的属性依赖关系。这方面的技术原因稍后将在8.5.1部分中介绍。

当我们分解不在BCNF中的范式时，可能会有一个或多个产生的范式不在BCNF中。

在这种情况下，需要进一步分解，最终的结果是一组BCNF范式。

8.3.3 BCNF和依赖保留

我们已经看到了几种表达数据库一致性约束的方法：主键约束、功能依赖性、检查约束、断言和触发器。每次更新数据库时，测试这些约束都是非常昂贵的，因此，以一种能够有效地测试约束的方式来设计数据库是非常有用的。特别是，如果只考虑一个关系就可以测试函数依赖关系，那么测试这个约束的成本很低。我们将会看到，在某些情况下，分解为BCNF可以阻止对某些函数依赖的有效测试。

为了说明这一点，假设我们对我们的大学组织做了一个小小的改变。在图7.15的设计中，一个学生可能只有一个顾问。这是关系集顾问从学生到导师之间的关系。我们要做的“小”改变是，教师只能与一个部门联系，而学生可能有不止一个顾问，但最多只能由一个部门负责。

使用E-R设计实现此更改的一种方法是用三元关系集替换导师关系集，即dept_advisor，涉及到从{student,instructor}到部门的实体集instructor,student, 和department，如图8.6所示。E-R图表指定了“一个学生可能有不止一个顾问，但最多一个对应于一个指定部门”的约束。

有了这个新的E-R图表，教师、部门和学生的模式没有改变。然而，来自dept _advisor的模式现在是：

Dept_advisor(s_ID, i_ID, dept _name)

尽管在E-R图中没有指定，假设我们有一个额外的约束，“一个指导员可以作为一个单独的部门的顾问。然后，下面的函数依赖于dept_advisor：

I_ID→dept_name

s_ID,dept_ name→i_ID

第一个函数依赖来自于我们的要求：“一个指导员可以作为一个部门的顾问。第二个函数依赖来自于我们的要求，即“一个学生最多可以有一个给定部门的顾问。”

请注意，在这个设计中，我们必须在每次教师参与一个dept_advis或关系时，重复该部门的名称一次。我们看到，dept _advisor不在BCNF中，因为i_ID不是超码。按照我们对BCNF分解的规则，我们得到：

(s_ID,i_ID)

(i_ID,dept_name)

上述两种模式都是BCNF。（实际上，您可以通过定义来验证任何只有两个属性的模式都在BCNF中。）但是，请注意，在我们的BCNF设计中，没有模式包含所有出现在函数依赖项s_ID、dept_ name→i_ID中的属性。

因为我们的设计使它难以实现这种功能依赖，我们说我们的设计不是依赖于保护。由于依赖性保护通常被认为是可取的，我们考虑另一种比BCNF更弱的正常形式，这将允许我们保留依赖性。这个正常的形式叫做第三范式。

8.3.4第三范式

BCNF要求所有的非平凡的依赖关系都是表单的α→β，α是超码。第三个标准形式（3 NF）通过允许某些非平凡的功能依赖，而使其左边不是一个超码，从而稍微放松了这个约束。在我们定义3 NF之前，我们记得一个候选键是一个极小的超码——也就是说，一个超码没有属性子集也是一个超码。

一个关系chema R是第三个正常形式的函数依赖关系，如果，对于F+形式的α→β所有函数依赖性，α∈R和β∈R，至少有一个是这样的：

α→β是一个微不足道的函数依赖项。

α模式R的超码

每一个在β→α中的属性A都包含在R的候选键中。

注意，上面的第三个条件并不是说一个候选键必须包含所有β→α的属性;每一个β→α的属性A都包含在一个不同的候选键中。

前两个替代方法在BCNF的定义中与两个替代方法相同。第三个NF定义的第三个选择似乎不太直观，而且它为什么有用也不明显。从某种意义上说，它代表了BCNF条件的最小松弛条件，它有助于确保每个模式都有一个依赖关系，将其分解为3 NF。当我们研究分解为3 NF时，它的目的会变得更清楚。

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

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

现在，让我们再来考虑一下dept _advisor关系集，它具有以下的函数依赖：

i_ID→dept _name

s_ID,dept _name→i_ID

在第8.3.3节中，我们认为函数依赖“i_IDdept_ name”导致了dept advisor模式不属于BCNF。注意，这里α=i _ID，β=dept_ name，和β-α=dept_ name。既然函数依赖项s_ID、dept _name→s_ID保存在dept _advisor上，那么属性dept_ name就包含在一个候选键中，因此，dept _advisor是在3 NF中。

我们已经看到了BCNF和3 NF之间必须做出的权衡，因为没有可靠的BCNF设计。在8.5.4部分中对这些权衡进行了更详细的描述。

8.3.5高等范式

使用功能依赖来分解模式可能不足以避免在某些情况下不必要的重复信息。

考虑一下教师实体设置的一个细微的变化，在这个定义中，我们与每个教师记录一组孩子的名字和一组电话号码。电话号码可能由多个人共享。因此，phone_ number和 child_ name:将是多值属性，根据我们从E-R设计生成模式的规则，我们将有两个模式，一个用于每个多值属性、phone_number和 child _name:：

 

(ID,child_ name)

(ID,phone _number)

如果我们要将这些模式组合起来

(ID,child_ name, phone_ number)

我们会发现结果是在BCNF中，因为只有一些无关紧要的函数依赖项。因此，我们可能会认为这样的组合是一个好主意。然而，这样的组合是一个坏主意，我们可以通过考虑一个有两个孩子和两个电话号码的教员的例子来了解。例如，让ID 99999的教师有两个孩子，分别叫“大卫”和“威廉”和两个电话号码，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。如我们所知，这是不正确的。

因为基于功能依赖的普通表单不足以处理这样的情况，其他依赖项和普通表单已经被定义。我们在8.6和8.7中涵盖了这些。