数据库

8.3 分解使用函数依赖
在第1节中，我们注意到有一种正式的方法来评估应该分解关系模式。这个方法是基于
键和功能依赖的概念。
在讨论关系数据库设计的算法时，我们需要
谈论任意关系和他们的模式，而不是仅仅谈论
的例子。回顾我们在第二章中介绍的关系模型，我们总结我们的符号。
•在一般情况下，我们使用希腊字母来表示属性集（例如）。我们用小写的罗马字母和大写的罗马字母括号表示关系模式（例R（R））。我们使用符号R（R）表示模式是关于R的，R表示属性的集合，但有时我们的符号化简时，只使用R关系名对我们来说并不重要。
当然，关系模式是一组属性，但不是所有属性集是模式。当我们使用小写的希腊字母时，我们指的是一个集合有可能不是模式的属性。罗马字母在我们想要指出属性的集合绝对是一个模式。
•当一组属性是超级键时，我们用K表示它。
对于一个特定的关系模式，我们使用术语"K是一个超级关键r(r)。”
•我们用一个小写的名字来表示关系。在我们的示例中，这些名称是意图是现实的（例如，教师），而在我们的定义中算法，我们用单字母，像r。
•一个关系，当然，在任何时候都有特定的价值;我们指的是作为一个实例使用术语“r的实例”。当我们很清楚的时候讨论一个实例，我们可以简单地使用关系名称（例如，r)。
8.1.3.1和函数依赖关系
数据库在现实世界中模拟一组实体和关系。有
通常在现实世界中的数据上有各种各样的约束（规则）。例如,在大学的数据库中，有一些约束条件是：
1.学生和教师的身份是唯一的。
2.每个学生和老师只有一个名字。
3.每位老师和学生（主要）与一个分离的人有关。
4.每个部门的预算只有一个价值，并且只有一个建筑。
一个满足所有这些现实约束的关系的实例称为
这一关系的法律实例;数据库的合法实例是所有的关系实例是合法的实例。
一些最常用的现实约束类型可以是正式地表示为键（超键、候选键和主键），或者作为功能性依赖关系，我们在下面定义。
在第2.3节中，我们定义了超键的概念作为一个或多个这些属性集合在一起，使我们能够在其中确定一个元组关系。我们重申这个定义如下：让R（R）成为一个关系模式。
R的子集是R（R）的超键，如果在R（R）的任何合法实例中，对于所有的对在r的例子中，t1和t2，如果t1=t2，那么t1 K=t2 K。也就是说,在任何关于关系R（R）的法律实例中没有两个元组可能具有相同的值。很明显，如果r中没有两个元组在K上有相同的值，那么ak值惟一地标识了r中的元组。而超级键是一组唯一标识整个的属性元组，功能依赖允许我们表达唯一的约束确定某些属性的值。考虑一个关系模式R（R），然后R和R。
•考虑到R（R）的一个实例，我们说实例满足功能性如果在实例中对所有成对的元组t1和t2有依赖性t1=t2，也就是t1=t2。
•我们说，功能性依赖关系在模式R（R）中，如果每一个R（R）的合法实例都满足了函数的依赖关系。
使用功能依赖符号，我们说K是R（R）的超键
在R（R）上的函数依赖关系。换句话说，K是一个超键，如果R（R）的每一个合法的实例，对于每一对元组t1和t2，例如，当t1 K=t2 K时，也就是t1 R=t2 R（也就是，t1 = t2)。
功能性依赖关系允许我们表达一些约束，这些约束是我们不能用超键来控制的。在第8部分中，我们考虑了模式：
inst部门（ID、姓名、工资、部门名称、建筑、预算）
在其中，功能依赖项的名称预算保持不变部门（按部门名称确定）有一个独特的预算金额。
我们表示这两个属性（ID，dept name）形成了一个超级键
对inst.部门的写作：
ID，公司名，工资，建筑，预算
我们将以两种方式使用功能性依赖：
1。测试关系的实例，看它们是否满足给定的集合F函数依赖。
2。指定法律关系的约束条件。因此，我们只关注那些满足给定功能集合的关系实例
依赖关系。如果我们希望约束自己在模式R（R）上的关系这满足了函数依赖的集合F，我们说F保持在R（R）上。
让我们考虑一下图4的关系r的实例，看看哪个函数依赖关系感到满意。观察C是否满足。有两个元组它的值是a1。这些元组具有相同的C值，即c1。类似地，两个元组与a2的值相同，也有相同的C值，c2。在那里没有其他具有相同值的独立元组的功能。然而，依赖C A并不满足。要知道它不是，请考虑元组t1=（a2、b3、c2、d3）和t2=（a3、b3、c2、d4）。这两个元组是相同的C值，c2，但是它们分别有不同的值a2和a3。因此,我们找到了一对元组t1和t2，t1c=t2c，但是t1A≠t2 A。
一些功能性依赖被认为是微不足道的，因为它们是满足的——同一标准的所有关系。例如，A对所有涉及到的关系都很满意，从字面上理解功能依赖的定义，我们看到，对于所有的元组t1和t2，t1 A=t2 A，就是t1 A=t2 A。类似的，AB A对所有涉及属性A的关系都很满意。
如果，表单的功能依赖是微不足道的。重要的是要认识到关系的一个实例可以满足一些在关系模式中不需要的func的依赖关系。在图8的教室关系的实例，我们看到了房间号的容量
是满意的。然而，我们相信，在现实世界中，不同建筑的两间教室可以有相同的房间号码，但房间容量不同。
因此，在某个时候，有可能有一个课堂关系的实例房间号码的容量不满足。所以，我们不包括房间在模式中保留的功能依赖集的数量
教室的关系。但是，我们会期望功能依赖性
建筑、房间数容量以保持课堂模式计划投入。假设一组函数依赖于关系R（R），它可能可以推断出某些其他的功能依赖关系也必须保持不变的关系。例如，如果有一个模式r（A，B，C），如果函数依赖关系B和C，保持r，我们可以推断出函数依赖性是C也必须保持在r上，这是因为，给定任何一个值只能是对于B的一个对应的值，对于B的值，只有一个值C的相应值，我们稍后学习，在第8。1节中，如何制作推断。
我们将用F+来表示集合F的结束，也就是集合
在所有的函数依赖关系中，可以根据集合F来推断出F+。
8.2.3.2.2包含f的所有函数依赖项
我们能得到的最理想的一种范式是Boyce，Codd范式(BCNF)。它消除了所有可以被发现的冗余在功能性依赖方面，如我们将在第6部分中看到的，可能有其他类型的冗余。关系模式R在BCNF中。如果F+的所有函数依赖关系到函数依赖关系的集合F。在R和R中，至少有一个是这样的：
•是一个微不足道的功能依赖项（也就是）。
•是模式r的超级关键。
数据库设计是在BCNF中如果每个关系模式的成员设计在BCNF中。
我们已经在第8.1节中看到了关系模式的一个例子不是在BCNF:
inst部门（ID、姓名、工资、部门名称、建筑、预算）
功能性依赖项的名称预算在inst部门中保持不变，但是在部门名称中不是一个超键（因为一个部门可能有很多不同的instruc）。在第8。2节中，我们看到了inst部门的分解，而部门是一个更好的设计。教员模式在BCNF中。所有的包含的非平凡的功能依赖项，例如：
ID名，公司名，薪水
在箭头的左边包含ID，ID是一个超键（实际上，在本例中，教师的主键）。（换句话说，没有非平凡的功能依赖于名称、部门名称和薪水的任何组合，没有ID一面。)因此，讲师在BCNF。
类似地，部门模式是在BCNF中因为所有的重要的func的依赖关系，例如：
部门名，预算
在箭头的左边包含dept名称，而dept name是一个超键（和部门的主键）。因此，部门在BCNF。
现在我们声明一个用于分解的一般规则不是在BCNF中。让R成为一个不在BCNF中的模式。然后至少有一个非平凡的功能
依赖性，这不是R的超键，我们在设计中替换R
两个模式:
•(α∪β)
•（R-(β-α）
在上面的inst部门，=部门名，=大楼，预算，和inst部门
取而代之的是
•（αUβ）=（部门名、建筑、预算）
•（R-（β-α）=（ID、姓名、部门名、薪水）
在这个区
在这个例子中，结果是=。我们需要将规则表述为这样做是为了正确处理具有属性的功能性依赖关系在箭头的两边都出现。这方面的技术原因稍后会介绍
8.5.1节。
当我们分解不在BCNF中的模式时，它可能是一个或多个产生的模式不在BCNF中。在这种情况下，进一步的分解是需要的，最终的结果是一组BCNF模式。
8.3.3 BCNF和依赖性保护
我们已经看到了几种表达数据库一致性约束的方法：
主键约束，功能依赖，检查约束