《Database.System.Concepts》（P329~338）

设置值属性的使用会导致数据存储的设计冗余，从而导致数据的不一致。例如，与其将教师和节之间的关系表示为单独的关系，还不如让数据库设计人员将一组每个教师的课程标识符和一组教师标识符存储在每个部分中。(课程和教师的主键用作标识符。) 当教师教哪一部分的数据被更改时，更新必须在两个地方进行:在教师的课程中，以及教师的部分。不执行这两个更新会使数据库处于不一致的状态。只保留其中的一套，即教师部分或教师的课程部分，将避免重复的信息;然而，只保留其中一套会使某些查询复杂化，而且还不清楚这两种中哪一种会保留。
某些类型的非原子值可能是有用的，尽管它们应该小心使用。例如，复合值属性通常是有用的，并且在许多情况下，设置值属性也是有用的，这就是为什么在E-R模型中支持这两种属性。在许多实体具有复杂结构的领域中，强制第一范式表示对应用程序程序员来说是不必要的负担，他们必须编写代码将数据转换成原子形式。还存在从原子表单来回转换数据的运行时的开销。因此，对非原子值的支持在这些领域中非常有用。事实上，现代数据库系统确实支持许多类型的非原子值，我们将在第22章中看到。然而，在这一章中，我们把自己限制在第一范式的关系上，因此，所有的域都是原子的。

8.3分解使用函数依赖

在第8.1节中，我们注意到有一种正式的方法来评估关系模式是否应该被分解。这种方法基于键和函数依赖的概念。

在讨论关系数据库设计的算法时，我们需要讨论任意关系和它们的模式，而不是只讨论示例。回顾我们在第二章中的关系模型的介绍，我们在这里总结一下我们的符号。

 一般来说，我们使用希腊字母表示属性集(例如，α)。我们使用小写的罗马字母，后面是大写的罗马字母，用来表示关系模式(例如，r(R))。我们使用r(R)来表示模式是关系r， R表示属性集，但有时简化我们的符号，当关系名称对我们不重要时使用R。

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

 当一组属性是超键时，我们用K表示。一个超键属于一个特定的关系模式，所以我们使用术语“K是r(R)的超键”。

 我们使用小写的关系名称。在我们的例子中，这些名称是真实的(例如，教师)，而在我们的定义和算法中，我们使用单个字母，比如r。

 当然，关系在任何给定的时间都具有特定的值;我们将其称为实例，并使用“r实例”这个术语。当我们讨论一个实例时，我们可以简单地使用关系名称(例如，r)。

8.3.1键和函数依赖

数据库模拟现实世界中的一组实体和关系。在现实世界中，数据通常有各种各样的约束(规则)。例如，在大学数据库中期望持有的一些约束是:

1. 学生和教师的编号是唯一的。

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

3. 每个教师和学生(主要)只与一个部门联系在一起。

4. 每个部门的预算只有一个值，而且只有一个相关的建筑。

一个满足所有这些现实约束的关系的实例称为关系的法律实例;数据库的法律实例是所有关系实例都是合法实例的地方。

在现实世界中，最常用的一些类型的约束可以被正式地表示为键(超键、候选键和主键)，或者作为功能依赖项，我们在下面定义它。

在第2.3节中，我们定义了超键的概念，它是一个或多个属性的集合，这些属性集合在一起，使我们能够在关系中唯一地识别一个元组。我们重申这个定义如下:让r(R)是一个关系模式。如果子集K(R)在r（R）是一个超键，在r(R)的任何法律实例中，在元组r在实例中有任意的t1和t2，当t1不等于t2时，t1[k]不等于t1[K]。也就是说，在任何关系r(R)的任何法律实例中，没有两个元组可以在属性集K上具有相同的值。显然，如果r中没有两个元组在K上具有相同的值，那么一个K值在r中唯一地标识一个元组。

而超键是一组唯一标识整个元组的属性，而功能依赖则允许我们表达约束，以唯一地标识某些属性的值。考虑一个关系模式r(R)，并让α属于R和β属于R。

 鉴于r(R)的一个实例,我们说实例满足功能依赖α→β如果实例中的所有成对的元组t1和t2,t1[α]= t2[α],也是,t1[β]= t2[β]。

 我们说的功能依赖α→β抓住模式r(R),如果在每一个法律的实例r(R)它满足功能相关。

使用功能相关的符号, 如果在r()R中函数依赖K→R。我们说K是r(R)的一个超码。换句话说，如果r(R)的每个法律实例，对于每一对 t1和t2都是一个超级键，当t1[K] = t2[K]时，也就是t1[R] = t2[R](也就是t1 = t2)。

函数依赖关系允许我们表达无法用超键表示的约束。在第8.1.2节中，我们考虑了模式:

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

功能相关的部门名称→预算持有,因为每个部门(部门名称)有一个独特的预算金额。

我们表示这一对属性(ID, deptname)通过写入来形成一个超键:

ID, dept name→name, salary, building, budget

我们将以两种方式使用功能依赖:

1. 测试关系的实例，看看它们是否满足给定的函数依赖项F。

2. 明确法律关系的约束。因此，我们只关心那些满足给定的函数依赖集的关系实例。如果我们想要约束我们自己在满足一个集合F(函数依赖)的模式r(R)上的关系，我们说F在r(R)上成立。
让我们考虑图8.4的关系r的实例，看看哪些功能依赖项得到了满足。注意:A→C是满足的。有两个元组，它们的值是a1。这些元组具有相同的C值，即c1。类似地，两个具有A值的元组a2具有相同的C值，c2。没有其他成对的不同元组具有相同的值。然而功能依赖C→A不满足。要知道它不是，考虑元组t1 =(a2,b3,c2,d3)和t2 =(a3,b3,c2,d4)。这两个元组有相同的C值，c2，但是它们有不同的值，分别是a2和a3。因此，我们发现了一对元组t1和t2，这样t1[C] = t2[C]，但是t1[A] 不等于t2[A]。
一些功能依赖项被认为是微不足道的，因为它们对所有关系都感到满足。例如，A对所有涉及属性A的关系都表示满足。从字面上理解函数依赖的定义，我们看到，对于所有的元组t1和t2, t1[A] = t2[A]，是t1[A] = t2[A]。类似地，AB→ A对所有涉及属性A的关系都是满足的。一般来说，表单的函数依赖关系α →β是微不足道的，如果β属于α。
重要的是要认识到，一个关系的实例可能满足某些功能依赖关系，而这些依赖关系并不需要保持关系的模式。在图8.5的课堂关系的实例,我们看到room number→capacity是满足的。然而，我们相信，在现实世界中，不同建筑的两间教室可以有相同的房间号，但房间容量不同。因此,它是可能的,在一段时间,一个实例的课堂关系room number→capacity不满足。所以,我们不包括room number→capacity的函数依赖集课堂关系的模式。然而，我们会表现功能依赖的building，room number→capacity在课堂模式上。
考虑到一组函数依赖关系F在关系r(R)上存在，可以推断出某些其他功能依赖关系也必须保持关系。例如,给定一个模式r(A,B,C),如果函数依赖A→B和B→C,满足r,我们可以推断功能依赖A→C也必须满足r。这是因为，给定任意值A, B的值只有一个对应的值，对于B的值，C只能有一个对应的值。我们稍后将在第8.4.1节中学习如何做出这样的推论。
我们将使用符号F+来表示集合F的闭集，即，给定集合F可以推断的所有函数依赖项集合。显然，F+包含了F中所有的函数依赖项。

8.3.2鲍依斯-柯德范式

我们能得到的较理想的正常范式之一是Boyce-Codd范式(BCNF)。它消除了基于功能依赖项可以发现的所有冗余，但是，正如我们将在第8.6节中看到的，可能还有其他类型的冗余。关系模式R的BCNF对一组F函数依赖,如果所有的功能依赖关系在F +形成α→β,α⊆R和β⊆R,至少一个以下持有:

 α→β是一个微不足道的函数依赖项(即β属于α)。

 α是模式R的超键。

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

我们已经在第8.1节中看到了没有在BCNF中的关系模式的例子:

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

功能相关dept nam→budget满足inst dept,但是部门的名字不是一个超码(因为一个部门可能有许多不同的教师)。在8.1.2节中，我们看到inst dept的分解为教师和部门是一个更好的设计。教师在BCNF中。所有不重要的功能依赖项，例如:

ID→name, dept name, salary

在箭头的左侧包含ID, ID是指导教师的超键(实际上，在本例中是主键)。(换句话说，在没有ID的情况下，不存在任何与名称、部门名称和薪水相结合的重要功能依赖项。) 因此，讲师是BCNF范式。

类似地，部门模式也在BCNF中，因为所有非琐碎的功能依赖项都保持不变，例如:

dept name→building, budget

     包括部门名称左边的箭头,并是一个超码(和部门名称主键）。因此，在BCNF部门。    我们现在提出了一种不存在于BCNF中分解的一般规则。让R是一个不在BCNF的模式。然后至少有一个重要的功能依赖→这样不是用超码代替R。我们是在设计,这两种模式:     在部门上面，包括部门的名称，建筑物的预算。然而，取而代之的是：     在这个例子中，结果是B-a=B。我们需要把规则说出来。这样做是为了正确处理具有在箭头两侧出现属性的功能依赖项。稍后将介绍这方面的技术原因。8.5.1节   当我们分解一个不在BCNF中的模式时，它可能是一个或多个。产生的模式不在BCNF中。在这种情况下，进一步分解。需要的，最终的结果是一组BCNF模式。 8.3.3 BCNF和依赖性保存       我们已经看到了几种表达数据库一致性约束的方法:主键约束、功能依赖、检查约束、断言和触发器。每次更新数据库时都要测试这些约束。因此，以约束的方式设计数据库是非常有用的。可以有效地进行测试。特别是，如果测试一个功能依赖项可以是通过只考虑一个关系，测试这个约束的成本很低。我们将看到，在某些情况下，分解为BCNF可以防止效率。测试某些功能依赖项。    为了说明这一点，假设我们对我们的大学做了一个小小的改变与组织。在图7.15的设计中，一个学生可能只有一个顾问。这是来自于关系集顾问从学生到顾问。我们所要做的“小”改变是指导用E-R设计实现此更改的一种方法是替换。顾问关系集与三元关系集，dept advisor，涉及。实集指导教师、学生和部门，从这对组合是多对一。者可以与之相关联。只有一个部门和一个学生可能有不止一个顾问，但大多数都是来自某个部门。     用E-R设计实现此更改的一种方法是替换。顾问关系集与三元关系集，部门领导等涉及。实体集指导教师、学生和部门，从这对组合是多对一。{学生,导师},如图8.6所示。E-Rdiagram指定约束:“学生可以有多个顾问,但最多一个对应于一个给定的部门”。有了这个新的E-R图，教师，部门，和学生都不变。但是，部门派生的模式现在是:   虽然没有在E-R图中指定，假设我们有额外的约束:“教师只能担任一个部门的顾问。”    然后，下面的功能依赖关系控制了部门顾问:第一个功能依赖是根据我们的要求“一个讲师”。只能担任一个部门的顾问。“第二个功能是根据我们相关的要求，“一个学生最多只能有一个顾问而且鉴于一个部门。”    注意，在这个设计中，我们被迫重复部门名称。每一次，教师都要参与一项部门的顾问关系。我们看到那个部门顾问不在BCNF，因为我ID不是一个超键。在我们的规则对于BCNF分解，我们得到:    上述模式都是BCNF。(实际上，您可以验证任何模式。根据定义，BCNF中只有两个属性。但是请注意，在我们的BCNF设计中，没有包含函数中出现的所有属性的模式。依赖一个年代的ID,部门名称→我的一个ID。    因为我们的设计使得它在计算上难以执行。依赖关系，我们说我们的设计不是依赖保存。是因为依赖保存通常被认为是可取的，我们认为另一个正常形式，是比BCNF弱，这将允许我们保持依赖关系。正常形式被称为第三范式。
8.3.4第三范式     BCNF要求所有非平凡→依赖关系的形式,在哪里一个超键。第三范式(3NF)通过允许稍微放松了这个约束。某些非平凡的函数依赖项，其左侧不是超键。之前我们定义了3NF，我们记得一个候选键是最小的超键，也就是a。超键没有合适的子集也是超键。    一种关系图，在第三范式中关于函数的集合F的依赖,如果所有→F +函数依赖的形式,⊆R和⊆R,至少一个以下持有:      a→B是琐碎的功能相关。      a是R的超键。      每个属性在a−B包含在R的候选键。   注意，上面的第三个条件并没有说一个候选关键字必须。a−B包含所有的属性;每个属性在−可能包含在不同的候选键。
   前两个选项与定义中的两个选项相同。BCNF。3NF定义的第三种选择 似乎很不直观。它为什么有用并不明显。从某种意义上说，它代表了一种最小的放松。在BCNF条件中，有助于确保每个模式都具有依赖性。分解成3 nf。它的目的将会变得更加清晰，当我们研究分解为3NF时。   注意，任何满足BCNF的模式也满足3NF。它的功能依赖将满足前两种选择之一。因此，BCNF是一个比3NF更严格的正规形式。   3NF的定义允许某些功能依赖项没有。BCNF的允许。只满足第三种选择的依赖项。在BCNF中不允许3NF定义，但允许在3NF中。   现在，让我们再次考虑dept advisor关系集，它有下面的函数依赖:   8.3.3节中我们认为功能依赖“我ID→部门名称”导致部门顾问模式不是BCNF。注意,这里=我ID,=名字,−=部门名称。在功能相关年代以来，ID、部门名称→我ID保存部门顾问,属性部门名称包含在一个候选键。因此,部门顾问在3 nf。   我们已经看到了在BCNF和3NF之间必须进行的权衡。没有依赖于保护的BCNF设计。描述这些权衡在第8.5.4节中更详细地介绍。8.3.5高等的范式   使用功能依赖来分解模式可能是不够的。在某些情况下避免不必要的重复信息。考虑一个轻微教师实体集定义的变化，我们记录每个。教师有一套孩子的名字和一套电话号码。电话数字可以由多人共享。因此，电话号码和孩子的名字。将是多值属性，并遵循我们生成模式的规则?从E-R设计中，我们将有两个模式，一个为每个多值。属性、电话号码及子名:    如果我们要结合这些模式。    我们会发现结果是在BCNF中，因为只有非平凡的函数依赖项。持有。因此，我们可能认为这样的组合是好的想法。然而，这样的组合是一个坏主意，我们可以通过考虑。一个有两个孩子和两个电话号码的老师的例子。例如，让ID 99999的老师有两个孩子叫“大卫”还有“威廉”和两个电话号码，512-555-1234和512-555-4321。在结合模式，我们必须对每个依赖者重复一次电话号码。     如果我们不重复电话号码，只存储第一个和最后一个。我们会记录从属的名字和电话号码。但是，由此产生的元组将暗示大卫与512-555-1234相对应。威廉与512-555-4321。我们知道，这是不正确的。因为基于功能依赖的正常表单是不够的。处理这样的情况，其他依赖关系和正常形式定义的。我们将在第8.6和8.7节中讨论这些问题。