关系数据库设计理论重点课件_第1页
关系数据库设计理论重点课件_第2页
关系数据库设计理论重点课件_第3页
关系数据库设计理论重点课件_第4页
关系数据库设计理论重点课件_第5页
已阅读5页,还剩53页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

第6章关系数据库设计理论定西广播电视大学肖武德第6章关系数据库设计理论定西广播电视大学肖1本章要点

1.深入理解函数依赖和键码的概念。学会计算属性的封闭集。 2.模式设计是本章的重点。了解数据冗余和更新异常产生的根源;理解关系模式规范化的途径;准确理解第一范式、第二范式、第三范式和BC范式的含义、联系与区别;

本章要点 1.深入理解函数依赖和键码的概念。学会计算属性的2

深入理解模式分解的原则;熟练掌握模式分解的方法,能正确而熟练的将一个关系模式分解成属于第三范式或BC范式的模式。 3.了解多值依赖和第四范式的概念,掌握把关系模式分解成属于第四范式的模式的方法。深入理解模式分解的原则;熟练掌握模式分解的方法3学生关系Student的实例如下:SnoSNSDMNCNG99230 贺小华计算机周光OS9699239 金谦计算机周光OS9099239 金谦计算机周光编译9299851 陈刚建筑王勇建筑89学生关系Student的实例如下:4SnoSNSnoSDSDMNSnoCNGSnoSN56.1函数依赖——6.1.1定义如果关系R的两个元组在属性A1,A2,…An上一致(也就是,两个元组在这些属性所对应的各个分量具有相同的值),则它们在另一个属性B上也一致。那么,我们就说在关系R中属性B函数依赖于属性A1A2…An。 A1A2…AnB,

“A1,A2,…,An函数决定B”。A1A2…An称为决定因素。

6.1函数依赖——6.1.1定义如果关系R的两个元组在66.1.2关系的键码

如一个或多个属性的集合{A1,…,An}满足如下条件,称该集合为关系R的键码: 1.这些属性函数决定该关系的所有其它属性。 2.{A1,…,An}的任何真子集都不能函数决定R的所有其它属性,键码必须是最小的。6.1.2关系的键码 如一个或多个属性的集合{A1,76.1.3超键码包含键码的属性集称为“超键码”。因此,每个键码都是超键码。某些超键码不是(最小的)键码。每个超键码都满足键码的第一个条件:函数决定它所在的关系的所有其它属性。超键码不必满足键码的第二个条件:最小化条件。6.1.3超键码包含键码的属性集称为“超键码”。86.1.4函数依赖规则(1)分解/合并规则 可以把每个函数依赖右边的属性分解,从而使其右边只出现一个属性。同样,我们也可以把左边相同的依赖的聚集用一个依赖来表示,该依赖的左边没变,而右边则为所有属性组成的一个属性集。两种情况下,新的依赖集都等价于旧的依赖集。6.1.4函数依赖规则(1)分解/合并规则9函数依赖规则(2)平凡依赖规则 对于函数依赖A1A2…AnB来说,如果B是A中的某一个,我们就称之为“平凡的”。 对于函数依赖A1A2…AnB1B2…Bm,·如果B是A的子集,则称该依赖为平凡的。 ·如果B中至少有一个属性不在A中,则称该依赖为非平凡的。函数依赖规则(2)平凡依赖规则10函数依赖规则(2)

·如果B中没有一个属性在A中,则称该依赖为完全非平凡的。·函数依赖A1A2…AnB1B2…Bm等价于A1A2…AnC1C2…Ck,其中 C是B的子集,但不在A中出现。我们称这个规则为“平凡依赖规则”。

函数依赖规则(2) ·如果B中没有一个属性在A中,则称该依赖11函数依赖规则(3)传递规则 传递规则使我们能把两个函数依赖级联成一个新的函数依赖。 ·如果A1A2…AnB1B2…Bm和B1B2…BmC1C2…Ck,在关系R中成立,则A1A2…AnC1C2…Ck在R中也成立。这个规则就称为传递规则。函数依赖规则(3)传递规则126.1.5计算属性的封闭集

假设{A1,A2,…,An}是属性集,记为A,S是函数依赖集。 属性集A在依赖集S下的封闭集是这样的属性集X,它使得满足依赖集S中的所有依赖的每个关系也都满足AX。也就是说,A1A2…AnX是蕴含于S中的函数依赖。用{A1,…,An}+表示属性集A1…An的封闭集。允许出现平凡依赖,所以A1,…,An在{A1,…,An}+中。6.1.5计算属性的封闭集 假设{A1,A2,…,A13

下面我们进一步理解封闭集的实际含义:

对于给定的函数依赖集S,属性集A函数决定的属性的集合就是属性集A在依赖集S下的封闭集。

下面我们进一步理解封闭集的实际含义: 对于给定的函数依14

学会计算某属性集的封闭集,还可以根据给定的函数依赖集推导蕴含于该依赖集的其他函数依赖。 已知: 关系模式R(A,B,C,D)

函数依赖ABC,CD,DA

求:蕴含于给定函数依赖的所有非平凡函数依赖。 学会计算某属性集的封闭集,还可以根据给定的函数依赖集推导15

首先考虑各种属性组合的封闭集。然后,依次分析各属性集的封闭集,从中找出该属性集所具有的新的函数依赖。 单属性:A+=A,B+=B,C+=ACD,D+=AD 新依赖:CA (1)

ABC,CD,DA 首先考虑各种属性组合的封闭集。然后,依次分析各属性集的封16ABC,CD,DA

双属性:AB+=ABCD,AC+=ACD,AD+=AD,BC+=ABCD,BD+=ABCD,CD+=ACD新依赖:ABD ACD BCABDA CDABCDBDC(7)ABC,CD,DA17三属性:A

B

C+=ABCD,A

B

D+=ABCD,ACD+=ACD,B

C

D+=ABCD新依赖:ABCDABDC BCDA (3)四属性:A

B

C

D+=ABCD无新依赖_____键码(3) ____超键码(4)三属性:ABC+=ABCD,ABD+=ABCD,AC186.2模式设计——6.2.1问题的提出设计关系数据库模式时,特别是从面向对象的ODL设计或从E/R设计直接向关系数据库模式转换时,很容易出现的问题是冗余性,即一个事实在多个元组中重复。造成这种冗余的最常见的原因是,企图把一个对象的单值和多值特性包含在一个关系中。6.2模式设计——6.2.1问题的提出设计关系数据库模式19

当我们企图把太多的信息存放在一个关系时,就会出现数据冗余和更新异常等问题。主要表现如下: 1.

数据冗余。 2.

修改异常。 3.

删除异常。 4.插入异常。参看实例 当我们企图把太多的信息存放在一个关系时,就会出现数据206.2.2问题的根源(1)

关系的键码函数决定该关系的所有其它属性。由于键码能唯一确定一个元组,所以,也可以说关系的键码函数决定该关系的所有属性。一个关系中的所有属性都函数依赖于该关系的键码。不同的属性在关系模式中所处的地位和扮演的角色是不同的。把键码所在的属性称为主属性,而把键码属性以外的属性称为非主属性。6.2.2问题的根源(1)关系的键码函数决定该关系的所21问题的根源(2)

不同的属性对键码函数依赖的性质和程度是有差别的。有的属于直接依赖,有的属于间接依赖(通常称为传递依赖)。当键码由多个属性组成时,有的属性函数依赖于整个键码属性集,而有的属性只函数依赖于键码属性集中的一部分属性。问题的根源(2)不同的属性对键码函数依赖的性质和程度是有差22 ·完全依赖与部分依赖

对于函数依赖WA,如果存在VW(V是W的真子集)而函数依赖VA成立,则称A部分依赖于W;若不存在这种V,则称A完全依赖于W。 当存在非主属性对键码部分依赖时,就会产生数据冗余和更新异常。若非主属性对键码完全函数依赖,则不会出现类似问题。 ·完全依赖与部分依赖23 ·传递依赖

对于函数依赖XY,如果YX(X不函数依赖于Y)而函数依赖YZ成立,则称Z对X传递依赖。 如果XY,且YX,则X,Y相互依赖,这时Z与X之间就不是传递依赖,而是直接依赖了。我们以前所讨论的函数依赖大多数是直接依赖。 ·传递依赖246.2.3解决的途径

部分依赖和传递依赖有一个共同之处,这就是,二者都不是基本的函数依赖,而都是导出的函数依赖:部分依赖是以对键码的某个真子集的依赖为基础传递依赖的基础则是通过中间属性联系在一起的两个函数依赖。

6.2.3解决的途径部分依赖和传递依赖有一个共同之处,25导出的函数依赖在描述属性之间的联系方面并没有比基本的函数依赖提供更多的信息。在一个函数依赖集中,导出的依赖相对于基本的依赖而言,虽然从形式上看多一种描述方式,但从本质上看,则完全是冗余的。正是由于关系模式中存在对键码的这种冗余的依赖导致数据库中的数据冗余和更新异常。导出的函数依赖在描述属性之间的联系方面并没有比基本的函数依赖26解决的途径——消除关系模式中各属性对键码的冗余的依赖。由于冗余的依赖有部分依赖与传递依赖之分,而属性又有主属性与非主属性之别,把解决的途径分为几个不同的级别,以属于第几范式来区别。解决的途径——消除关系模式中各属性对键码的冗余的依赖。27

范式就是符合某一种级别的关系模式的集合。 目前主要有六种范式:第一范式、第二范式、第三范式、BC范式、第四范式和第五范式。第一范式需满足的要求最低,在第一范式基础上满足进一步要求的为第二范式:

1NF2NF3NFBCNF4NF5NF通过分解把属于低级范式的关系模式转换为几个属于高级范式的关系模式的集合,这一过程称为规范化。 范式就是符合某一种级别的关系模式的集合。28第一范式(1NF)如果一个关系模式R的所有属性都是不可分的基本数据项,则这个关系属于第一范式。在任何一个关系数据库系统中,第一范式是对关系模式的一个最起码的要求。不满足第一范式的数据库模式不能称为关系数据库。第一范式(1NF)如果一个关系模式R的所有属性都是不可分的基29第二范式(2NF)若关系模式R属于第一范式,且每个非主属性都完全函数依赖于键码,则R属于第二范式。第二范式就是不允许关系模式中的非主属性部分函数依赖于键码。

第二范式(2NF)若关系模式R属于第一范式,且每个非主属性都30

学生关系模式Student(Sno,Sname,Sdept,Mname,Cname,Grade)。该关系模式存在如下部分依赖:Sno,CnameSname,Sdept,Mname

显然不满足“每个非主属性都完全函数依赖于键码”的条件。所以学生关系模式不属于第二范式。P学生关系模式Student(Sno,Sname,Sdept31关系分解的含义关系R的分解包括两个方面,一方面是把R的属性分开,以构成两个新的关系模式:另一方面是通过对R的元组进行投影而产生两个新的关系。关系分解的含义关系R的分解包括两个方面,一方面是把R的属性分32分解的过程

给定一个模式为{A1,A2,…,An}的关系R,我们可以把R分解为两个关系S和T,模式分别为{B1,B2,…,Bm}和{C1,C2,…,Ck},使得: 1.{A1,…,An}= {B1,…,Bm}∪{C1,…,Ck}分解的过程 给定一个模式为{A1,A2,…,An}的关系33

2.关系S中的元组是R的所有元组在{B1,…,Bm}上的投影。对于R的当前实例的每个元组t,取t在属性B1,B2,…,Bm上的分量。这些分量构成一个元组,它属于S的当前实例。 3.类似地,关系T中的元组是R的当前实例中的元组在属性集{C1,C2,…,Ck}上的投影。 2.关系S中的元组是R的所有元组在{B1,…,Bm}上的投34第三范式(3NF)

若关系模式R属于第一范式,且每个非主属性都不传递依赖于键码,则R属于第三范式。这里应说明一点:属于第三范式的关系模式必然属于第二范式。因为可以证明部分依赖蕴含着传递依赖。第三范式(3NF)若关系模式R属于第一范式,且每个非主属性35关系模式S1(Sno,Sname,Sdept,Mname)由于存在传递依赖而不属第三范式.S1分解成两个关系模式S11(Sno,Sname,Sdept)S12(Sdept,Mname)关系模式36BC范式(BCNF)

若关系模式R属于第一范式,且每个属性都不传递依赖于键码,则R属于BC范式。通常BC范式的条件有多种等价的表述:每个非平凡依赖的左边必须包含键码;每个决定因素必须包含键码。BC范式既检查非主属性,又检查主属性。当只检查非主属性时,就成了第三范式。满足BC范式的关系都必然满足第三范式。BC范式(BCNF)若关系模式R属于第一范式,且每个属性都37关系模式STC(SN,TN,CN,G)

SN,CNTN,G SN,TNCN,G TNCN

键码为:{SN,CN}和{SN,TN}。 关系模式STC分解成 SC(SN,CN,G) ST(SN,TN)

关系模式STC(SN,TN,CN,G)38关系模式STC的实例

SN TN CN G

杨紫兰

文松

程序设计90

杨紫兰

孙兰竹

数据库88魏红孙兰竹

数据库92魏红

田梅程序设计86关系模式STC的实例39分解后关系模式ST的实例如下:SNTN杨紫兰

文松

杨紫兰

孙兰竹

魏红

孙兰竹

魏红

田梅

SNCNG杨紫兰

程序90杨紫兰

数据库

88魏红

数据库

92魏红

程序86分解后关系模式ST的实例如下:SNTN杨紫兰文松杨紫兰40ST和SC以SN为公共属性进行连接:SNTN CN G(真/伪)杨紫兰文松 程序 90 √杨紫兰文松 数据库88 ×杨紫兰孙兰竹 程序90 ×杨紫兰孙兰竹 数据库88 √ST和SC以SN为公共属性进行连接:416.2.4分解的原则

主要涉及两个原则: ·无损连接(LosslessJoin) 如果对新的关系进行自然连接得到的元组的集合与原关系完全一致,则称为无损连接。 无损连接反映了模式分解的数据等价原则。6.2.4分解的原则主要涉及两个原则:42

·保持依赖(PreserveDependency) 如果分解后总的函数依赖集与原函数依赖集保持一致,则称为保持依赖。 保持依赖反映了模式分解的依赖等价原则。依赖等价保证了分解后的模式与原有的模式在数据语义上的一致性。 ·保持依赖(PreserveDependency)436.2.5分解的方法

关系模式分解的基础是键码和函数依赖。当我们对关系模式中属性之间的内在联系做了深入、准确的分析,确定了键码和函数依赖之后,模式分解因有章(规则)可循,有法(方法)可依而显得简单明了。

6.2.5分解的方法关系模式分解的基础是键码和函数依赖44模式分解的两个规则(1)

·公共属性共享 要把分解后的模式连接起来,公共属性是基础。若分解时模式之间未保留公共属性,则只能通过笛卡尔积相连,导致元组数量膨胀,真实信息丢失,结果失去价值。保留公共属性,进行自然连接是分解后的模式实现无损连接的必要条件。模式分解的两个规则(1) ·公共属性共享45模式分解的两个规则(2)

·相关属性合一

把以函数依赖的形式联系在一起的相关属性放在一个模式中,从而使原有的函数依赖得以保持。这是分解后的模式实现保持依赖的充分条件。然而,对于存在部分依赖或传递依赖的相关属性则不应放在一个模式中,因为这正是导致数据冗余和更新异常的根源,从而也正是模式分解所要解决的问题。模式分解的两个规则(2) ·相关属性合一46模式分解的三种方法部分依赖归子集;完全依赖随键码。

要使不属于第二范式的关系模式“升级”,就要消除非主属性对键码的部分依赖。解决的办法就是对原有模式进行分解。分解的关键在于:找出对键码部分依赖的非主属性所依赖的键码的真子集,把这个真子集与所有相应的非主属性组合成一个新的模式;对键码完全依赖的所有非主属性则与键码组合成另一个新模式。

模式分解的三种方法部分依赖归子集;完全依赖随键码。47学生选课SC(Sno,Sname,Ssex,Sage,Cno,Cname,Grade)

CnoCnameSnoSname,Ssex,SageSno,CnoGrade Sno,CnoSname,Ssex,Sage Sno,CnoCnamePPPP48本例中有两个部分依赖,一个完全依赖,结果原来模式一分为三:

SC1(Sno,Sname,Ssex,Sage) SC2(Cno,Cname) SC3(Sno,Cno,Grade)

本例中有两个部分依赖,一个完全依赖,结果原来模式一分为三:49基本依赖为基础,中间属性作桥梁

要使不属于第三范式的关系模式“升级”,就要消除非主属性对键码的传递依赖。解决的办法非常简单:以构成传递链的两个基本依赖为基础形成两个新的模式,这样既切断了传递链,又保持了两个基本依赖,同时又有中间属性作为桥梁,跨接两个新的模式,从而实现无损的自然连接。基本依赖为基础,中间属性作桥梁50

找违例自成

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论