DATABASE SYSTEM CONCEPTS 4.1

1 设置值属性的使用可以导致对数据的冗余储存的设计，这反过来又会导致不一致。例如，而不是教师和部分之间的关系表示为一个单独教的关系。数据库设计师可能会储存一组部分标识符与每个教练和一组教练标识符与每个部分（部分的主键和教练被用做标识符）。当与哪位讲师授课那一节被更改时，该更新必须在两个地方执行；在教师组的教师中，为教师的部分的集合。如果不能同时执行这两个更新，数据库就会处于不一致的状态。只保留其中的一组，要么是一组教师的集合，要么是一组讲师的集合，将避免重复的信息，但是只保留其中的一个会使一些查询变得复杂，并且不清楚其中哪个可以保留。

有些类型的非原子值可能是有用的，尽管它们应该小心使用。例如，复合值属性通常是有用的，而且在很多情况下，set值属性也很有用，这就是为什么在E-R模型中都支持这两种属性。在许多领域中，实体有一个复杂的结构，强制第一个复杂的结构，强制第一个正常的表单表示对应用程序编程人员来说是不必要的负担，他们必须编写代码将数据转换为原子的形式。还有从原子形式来回转换数据大的运行时开销。因此，对非原子值的支持在这类域中是非常有用的。事实上，现代数据库系统确实支持许多类型的非原子价值，我们将在22章中看到。然而，在这一章中，我们将自己局限于第一范式的关系，因此，所有域都是原子的。。

2在第一部分中，我们注意到有一种正式的方法来评估是否应该分解模式。这种方法基于键和功能的概念。在讨论关系数据库设计的算法时，我们需要讨论任意关系及模式，而不是只讨论示例。回顾我们在第二章中介绍的关系模型，我们在这里总结了我们的符号。通常，我们使用希腊字母来表示属性集（例如，x）。我们使用小写的罗马字母，后面是大写的罗马字母，以表示关系模式（例如，R(R)）。我们用符号R（R）表示关系模式是关于R的，用R表示属性的集合，但有时我们的符号化简，当关系名称对我们不重要时用R表示。当然，关系模式是一组属性，但不是所有属性集都是模式。当我们使用小写的希腊字母时，我们指的是一个集合的有可能不是模式的属性。当我们希望指出属性集绝对是一个模式时，就使用罗马字母。当一组属性是超键是，我们用k表示它。一个超键属于一个特定的关系模式，所以我们使用术语k是R（R）的超键。我们用小写的名称表示关系。在我们的示例中，这些名称是为了现实的（例如，教师），而在我们的定义和算法中，我们使用的是单个字母，比如r。当然，一个关系在任何给定的时间都有一个特定的值。我们将它作为一个实例，使用术语“r的实例”，当我们清楚地讨论一个实例时，我们可以简单地使用关系名称（例如，r）

数据库在现实世界中模拟一组实体和关系。在现实世界中，数据通常有各种各样的约束(规则).例如，在大学数据库中可能存在的一些约束条件是：

1. 学生和教师的身份是唯一的。

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

3. 每位老师和学生（主要）与一个分离的人有关。

4. 如图所示。每个部门的预算只有一个价值，并且只有一个建筑。

4。一个满足所有这些实际约束的实系的实例被称为实系的一个实例数据
库的法律实例是所有六系实们都是
实列的地方，现实世界中，最常用的一些类型的约束可以被正式地表示为键(超键、候选键和主键)，或者作为功能依顿项，我11在下面定义它
在第23书中，我定义一个scperkey6概念作为一个或多个属性的集合，这些属性集合起来。使我们能够在关系中唯一批识别一个元组。我重申这个定又如下让厂门)成为一个实系模 式。的任何法律实例中，对于所有的对都是n的越基。和小的元组在的例子中，然后是也就是说，任何会系口的法律实例中沒有两个元组可能具有相同的面。武者。一个学生可以与不止一个部门联系在起，例如作为一个阳属的教员。成系我们的简化的大学 城式 模型，要 上每个部门 和 自 三 马 部门学模式模型，8.3使用功能依赖项进行分解。属性设置K，显然。如果r中沒右两个元组在K 上具有相同的值，那么一个K值唯一地标识一个币起键是一组唯一标识整个元组的属性，而功敢依赖则允许我们表达约束，以唯地识别atributes的值。考虑一个尖系模式r(r)，并让它。

5，。r的一个实例的。我们说实防斯关动服皮机一日如果所有成对的元组干和世tol 的实例等也是我们说，如果在(r 的每一个去律实创中都满足了面数依赖关系。那么雨數依构aB就会保持在模式口r 上使用西数依赖符号，我们说K是R(R 的超键，如果团数依赖项在RR 上皮立。热句否说，对于r)的每个法年实创来说，K是个超级键，对于每一对元组t和一个实例，当b时，也就是t=b即=b)   西数依赖关系允许我们表达的末。我们不达用趣健来处理在第日.12节中，我们考虑了模式:允许我们表达约束，在 8 .1.2 章中，我们考虑了模式、。

  在这种情兄下，由于排个部 飞由标识有一个独持的预其食物，所以使用了功触性依规项

  我们表示达对尾性D.deptname)通过写入来元成一个起键

  我们 将 以 两 种方 武使 用 功触依赖。测试关系的实例，看看它们是香满足给定的由数依赖项。 明确法律美系的约束。因此。我们只实心那些满足给定的雨数依赖集的美系实例。如果我们想要的束白己与模式厂r )之间的美系，它满足面数依赖项的集合F.那么我们就说在广)上的

  让我们考虑88.4的关系厂实例，看看那些功胶依赖项得到了满足。观察到A Cls满意。有两个元组

6.它的值是a1，这些元素具有相同的c值，即c。类似地，两个具有A值的元组具有相同的Cvalue c2。没有其他成对的不同元组具有相同的值。然而，功触依赖性CA并不满足。要知道它不是，考虑一下。元组h=（a2,b3。C2、dy)和t2=(a3。b3 C2,d4)。这两个元组有相同的Cvalues,c2,但是它们分别有不同的值，a2和a3。因此，我们发现了一对

这样，但是的一些功触依赖性被认为是激不是道的，因为它们被所有关累所满足。例如，AA是满足所有关系涉及属性a.阅读功能相关的定义，我们可以看到，所有元组t和它是多氨高予镀=AI同样，ABA是满足所有关烹沙及属性。。一般来说，面数依赖的形式

如果B，C，1B是激杯思就的重要的是要认识到；=个关原的实例可以满足些不需要对头系的檬式进行

约束的功然依赖关案叶在图815的教室关案的实例中p我们看到了空间容量的满是，然示我们识为粒现实世界中宋间建筑的两间教室可以有相同的房间号，因此，i有可舱在一段时间内in有六种数室会系的实例在这种矣系中房间的容量是不满足的。因此，我们不需要在对会系的模式的”功然依赖项集合中包含空间跳跃舱力。然而，我们期室功触依额构建，容纳横式的能易考成到一组面款依赖项在关章r（r）上成立，它可以推断某些其他功然依赖项也必须保持。

7. 的关系。例如，给定一个器构rA，B.C，如果功能依赖。A B和BC，保持r，我们可以推断出面数依赖AC。推断。我们将用F来表示CI。集合F的乘合。可以推断出给予各的所有功然依赖项。集合F。包含1中的所有西款依赖我们然得到的最理提的正常形式内产是BCN正常形式电请除所有可以被发现的完余
但是m在功触依赖项上ler我们将在第8.6节中看制金的其快类型的完食司可食类露概式R在BCNT中与R是在 BCNF 和于面数依赖项的集合Fen对日中的所有面数依赖项。型，r其中CR和BCR，至公有以于行神:B是一个微不足道的面数依赖项椰式R的超镜
        8一个数据康设计是在BCNF中，如果得市组采系概式的成员构成设计在BCNEsign is in NF
我们已经在第8，1节中看到了一个关黑模式的例子。

函数依赖关系部门名称→预算在内部保持不变，但部门名称不是超级密钥(因为，一个部门可能有许多不同的指令( ))。在第8.1.2节中，我们看到了将独立部门分解为讲师和部门是一个更好的设计方法。指导员模式在BCNF中。所有重要的函数依赖项，如：         
ID→姓名，部门名称，薪金

将ID包含在箭头的左侧，ID是指导员的超级键(在本例中是主键)。(换句话说，在没有ID的情况下，没有任何名称、部门名称和工资组合的函数依赖关系。)。因此，指导员在bcnf中。
类似地，部门模式在BCNF中，因为所有重要的函数 依赖关系都是有效的，例如： 

部门名称→建筑物、预算

在箭头的左侧包含Det名称，而部门名称是部门的超级键(和主键)。因此，部门是在BCNF。我们现在说明了一个一般的规则分解，而不是在BCNF。设R是一个不在BCNF中的模式。然后，至少有一个非平凡的函数依赖项α→β，这不是R的超级密钥，我们在设计中用两个模式替换了R：
• (α ∪β )
• (R − ( β−α ))

在上面部门的情况下，α=部门名称，β={建筑物、预算}，学院 部门被替换为
• (α ∪β )=(部门名称、建筑、预算)
. • (R − ( β−α ))=(ID、名称、部门名称、薪资) 

在本例中，结果是β−α=β。我们需要像我们所做的那样声明规则，以便正确地处理功能依赖关系，这些依赖项的属性出现在箭头的两边。这方面的技术原因将在第8.5.1节后面讨论。当我们分解一个不在BCNF中的模式时，可能是一个或多个结果模式不在BCNF中。在这种情况下，需要进一步分解，其最终结果是一组BCNF模式。

我们已经看到了几种表示数据库一致性约束的方法：主键约束、函数依赖、检查约束、断言和触发器。每次更新数据库时都会测试这些约束，因此，以一种可以有效测试约束的方式设计数据库是很有用的。特别是，如果只考虑一种关系就可以测试一个功能依赖项，那么测试这个约束的成本就会很低，在某些情况下，分解为BCNF可以阻止对某些功能依赖项的有效测试，为了说明这一点，假设我们对我们的大学组织做了一个小小的改变。在图7.15的设计中，一个学生可能只有一个顾问，这是因为关系集顾问从学生到顾问是一对一的。我们要做的“小”改变是，一名教师只能与一个部门联系，学生可能有多个导师，但在使用E-R设计实现此更改的一种方法是将顾问关系集替换为三元关系集，Det顾问，涉及实体集讲师、学生和部门，这是一对多对一的关系集。{学生，讲师}到系，如图8.6所示。E-R图指定了这样的约束：“一个学生可能有多个导师，但最多有一个对应于给定的部门”。在这个新的E-R图中，指导员、系和学生的模式不变。但是，从部门顾问派生的架构现在是：
部门顾问(ID，I ID，部门名称) 
尽管在E-R图中没有指定DEPT顾问(ID、I ID、Det名称)，但假设我们有一个附加约束，即“教员只能为单个部门充当顾问”。那么，以下功能依赖将保留在部门顾问上：
i ID →部门名称
s-ID, 部门名称→ i ID

第一个函数依赖是从我们的要求，”一个教练
可以作为一个部门的顾问。”二函数依赖
从我们的要求，”一个学生最多只能有一个
顾问部门。”
请注意，使用此设计，我们被迫重复一次部门名称，每次讲师参与部门顾问关系。我们看到部门顾问不在BCNF中，因为我ID不是超级密钥。按照我们的BCNF分解规则，我们得到：
(s ID, i ID)
(i ID, 部门名称)

以上两种模式都是BCNF。(实际上，根据定义，您可以验证任何只有两个属性的模式都在BCNF中。)但是，请注意，在我们的bcnf de 签名中，没有包含函数依赖项的s-ID，部门名称→i -ID中的所有属性的模式

因为我们的设计使得计算这个函数依赖性变得很困难，我们说我们的设计不是依赖保持的。

因为依赖保护通常被认为是最理想的，我们考虑的另一个范式，不如BCNF，能让我们保持依赖关系。

这种标准形式称为第三范式。

8.3.4第三范式

BCNF要求所有非平凡依赖的形式都类似于a→B，也被称为超码。

第三范式（3NF）放宽了这一限制，允许某些非平凡函数依赖的左边是不是一个超码。

当我们定义3NF，我们记得一个候选键是一个最小的超码的超键，而没有适当的子集，这又称为一个超码。

关系模式R在函数依赖集F上是第三范式,在F +形式的→B函数依赖，在A⊆R和B⊆R中拥有以下至少一个：

•A→B是一个平凡的函数依赖。

•是超键为R.

•每个属性的A-B-是包含在一个R的候选键

注意上面的第三个条件并不是说每一个候选键必须含有B−A；而是每个属性的B−A一可以包含在不同的候选关键字中。

第一个方案是为BCNF的定义，两者相同。对3NF定义第三种选择似乎相当直观，和

它为什么有用没有明显的原因。它代表着，在某种意义上，一个最小的松弛的BCNF条件有助于确保每个架构都具有保持依赖深度剖析3NF。

其目的以后会变得更清晰，当我们深度剖析3NF后。观察到的任何模式，满足BCNF也满足3NF，因为每个它的函数依赖项将满足前两个备选方案之一。因此BCNF是一个比3NF范式更严格的范式。

3NF的定义允许特定功能的依赖性，不允许在BCNF中使用。一个A→B依赖，仅满足3NF定义的第三种选择——是不允许在BCNF中使用，但允许在3NF中使用。

现在，让我们再考虑一下关系集，它有以下函数依赖性：

（注解：

4technically，它可能是一个依赖的属性，都没有出现在任何一个模式仍然是含蓄的执行，因为其他的依赖，意味着它在逻辑上的存在。我们可以在第8.4.5得知情况，。

5youmay指出我们跳过第二范式。它只具有历史意义，在实践中没有应用。

6these依赖的过渡依赖的例子（见练习8.16）。是最初定义

3NF在过渡依赖项中。我们使用的定义是等价的，但更容易理解。）

i ID→dept name

s ID, dept name→i ID

在8.3.3章中，我们认为函数依赖“i ID → dept name”而造成的顾问模式，不属于BCNF的问题。

注意这里 A= i ID, B= dept name, andB−A= dept name.由于函数依赖的s ID, dept name→i ID顾问部的属性名称包含在候选键中，因此，3NF中含有dept advisor。

我们已经看到，当我们没有保持依赖分解设计是，就必须在BCNF和3NF之间权衡。在第8.5.4章中有更详细的对这些权衡的描述。

8.3.5高等师范形式

考虑到使用函数依赖分解架构可能不足以避免在某些情况下不必要地重复信息。我们需要一个细小的教师实体集合定义的变化，我们在其中定义了每个教员负责的一组孩子的名字和一组电话号码。

电话号码可以由多人共享。因此，电话号码和孩子的名字将具有多个属性值，下面我们从E-R图设计生成模式的规则来分析，我们将有两种模式，为每一个模式的多值属性，包括电话号码和孩子的名字：

（身份证，孩子的名字）

（身份证，电话号码）

如果我们要结合这些模式来获得

（身份证、儿童姓名、电话号码）的话

我们会发现，结果是只有非平凡函数依然依靠BCNF。

因此，我们可能认为这样的组合是个好主意。然而，这样的组合是一个坏主意，我们可以从一个有两个孩子和两个电话号码的教练的例子中看出。

例如，让ID为99999的教师有两个孩子，名为“戴维”。

和“威廉”两个电话号码，512-555-1234和512-555-4321。在组合模式中，我们必须为每个依赖项重复一次电话号码：

（99999，戴维，512-555-1234）

（99999，戴维，512-555-4321）

（99999，威廉，512-555-1234）

（99999，威廉，512-555-4321）

如果我们没有重复的电话号码，则只存储第一个和最后一个元组，我们会记录相关的名字和电话号码，但得到的元组将会是戴维与512-555-1234，而威廉与512-555-4321。我们知道，这是不正确的。

由于基于函数依赖的标准形式不足以处理这种情况，所以定义了其他依赖项和规范形式。我们将会在第8.6和第8.7节中讨论这些问题。

 

翻译自《DATABASE SYSTEM CONCEPTS》  Abraham Silberschatz   Henry F.Korth   S.Sudarshan