《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是琐碎的功能相关

     

 aR的超键

      

每个属性在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。

   我们已经看到了在BCNF3NF之间必须进行的权衡没有依赖于保护的BCNF设计描述这些权衡在

8.5.4节中更详细地介绍

8.3.5高等的范式

   使用功能依赖来分解模式可能是不够的在某些情况下避免不必要的重复信息考虑一个轻微教师实

体集定义的变化我们记录每个教师有一套孩子的名字和一套电话号码电话数字可以由多人共享

因此电话号码和孩子的名字将是多值属性并遵循我们生成模式的规则?E-R设计中我们将有两

个模式一个为每个多值属性电话号码及子名:

    如果我们要结合这些模式

    我们会发现结果是在BCNF因为只有非平凡的函数依赖项

持有因此我们可能认为这样的组合是好的想法然而这样的组合是一个坏主意我们可以通过考

一个有两个孩子和两个电话号码的老师的例子例如ID 99999的老师有两个孩子叫大卫

威廉和两个电话号码,512-555-1234512-555-4321。在结合模式我们必须对每个依赖者重复一次

电话号码

     如果我们不重复电话号码只存储第一个和最后一个我们会记录从属的名字和电话号码但是

由此产生的元组将暗示大卫与512-555-1234相对应威廉与512-555-4321。我们知道这是不正确的

为基于功能依赖的正常表单是不够的处理这样的情况其他依赖关系和正常形式定义的我们将在

8.68.7节中讨论这些问题

     


1、资源项目源码均已通过严格测试验证,保证能够正常运行; 2、项目问题、技术讨论,可以给博主私信或留言,博主看到后会第一时间与您进行沟通; 3、本项目比较适合计算机领域相关的毕业设计课题、课程作业等使用,尤其对于人工智能、计算机科学与技术等相关专业,更为适合; 4、下载使用后,可先查看README.md或论文文件(如有),本项目仅用作交流学习参考,请切勿用于商业用途。 5、资源来自互联网采集,如有侵权,私聊博主删除。 6、可私信博主看论文后选择购买源代码。 1、资源项目源码均已通过严格测试验证,保证能够正常运行; 2、项目问题、技术讨论,可以给博主私信或留言,博主看到后会第一时间与您进行沟通; 3、本项目比较适合计算机领域相关的毕业设计课题、课程作业等使用,尤其对于人工智能、计算机科学与技术等相关专业,更为适合; 4、下载使用后,可先查看README.md或论文文件(如有),本项目仅用作交流学习参考,请切勿用于商业用途。 5、资源来自互联网采集,如有侵权,私聊博主删除。 6、可私信博主看论文后选择购买源代码。 1、资源项目源码均已通过严格测试验证,保证能够正常运行; 2、项目问题、技术讨论,可以给博主私信或留言,博主看到后会第一时间与您进行沟通; 3、本项目比较适合计算机领域相关的毕业设计课题、课程作业等使用,尤其对于人工智能、计算机科学与技术等相关专业,更为适合; 4、下载使用后,可先查看README.md或论文文件(如有),本项目仅用作交流学习参考,请切勿用于商业用途。 5、资源来自互联网采集,如有侵权,私聊博主删除。 6、可私信博主看论文后选择购买源代码。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值