730 likes | 843 Views
CMU SSD7: Database Systems. Lu Wei School of Software Northwestern Polytechnical University. 3.3 关系数据理论. 第一节 问题的提出 第二节 规范化. 第一节 问题的提出.
E N D
CMU SSD7: Database Systems Lu Wei School of Software Northwestern Polytechnical University
3.3 关系数据理论 第一节 问题的提出 第二节 规范化 Lu Wei
第一节 问题的提出 前面我们已经讨论了关系数据库的基本概念、关系模型的三个部分以及关系数据库的标准语言,还学习了数据库设计的基本技术,能够构建基本的数据库ER模型。但是还有一个很基本的问题尚未涉及,针对一个具体问题,应该如何构造一个适合于它的数据库模式,即应该构造几个关系模式,每个关系由哪些属性组成等。这是数据库设计的问题,确切地讲是关系数据库逻辑设计问题。 Lu Wei
首先回顾一下关系模型的形式化定义 一个关系模式应当是一个五元组。 R(U, D, DOM, F) 其中,D和DOM对模式设计关系不大,因此,在本章讨论中把关系模式看作是一个三元组: R(U, F) 因此,本章的主要是围绕着属性和属性间的数据依赖来讨论问题。 Lu Wei
第一个例子 有一个关系模式R(TNAME,ADDRESS,C#,CNAME),分别表示教师姓名、教师地址、课程编号和课程名。 Lu Wei
在使用过程中有以下几个问题: 1、数据冗余 如果一个教师教几门课程,那么这个教师的地址就要重复几次存储; 2、修改异常 必须同时修改几个主键相同的元组的相关信息; Lu Wei
3、插入异常 如果一门课程没有教师来教,则无法插入到数据库中去(缺少主关键字); 4、删除异常 如果删除一个教师的教学任务,同时也会删除教师信息。 Lu Wei
所以,关系模式R的设计不是一个好的设计。如果我们用下面的两个关系模式来代替R:所以,关系模式R的设计不是一个好的设计。如果我们用下面的两个关系模式来代替R: R1:教师信息 R2:课程教授信息 Lu Wei
在上例中模式R,为什么教师T1的地址会重复出现,因为TNAME和ADDRESS之间存在依赖关系。在上例中模式R,为什么教师T1的地址会重复出现,因为TNAME和ADDRESS之间存在依赖关系。 函数依赖势必造成关系出现冗余现象,在R分解成R1和R2后,消除了冗余和异常情况。 Lu Wei
第二个例子 数据库模式S〈U,F〉 U = { SNO,SDEPT,MN,CNAME,G } F = {SNO→SDEPT,SDEPT→MN,(SNO,CNAME)→G} Lu Wei
这个关系模式同样存在数据冗余、插入异常、修改异常和删除异常问题。这个关系模式同样存在数据冗余、插入异常、修改异常和删除异常问题。 这是因为这个模式中的函数依赖存在某些不好的性质。假如我们把这个单一的模式改造一下,分成三个关系模式: S〈SNO,SDEPT, SNO→SDEPT〉; SG〈SNO,CNAME,G, (SNO,CNAME)→G〉; DEPT〈SDEPT,MN, SDEPT→MN〉; Lu Wei
这三个模式都不会发生上述异常的毛病,数据的冗佘也得到了控制。这三个模式都不会发生上述异常的毛病,数据的冗佘也得到了控制。 Lu Wei
为什么上面的两个例子经过改造以后会变得比改造前好?还能不能继续改造?为什么上面的两个例子经过改造以后会变得比改造前好?还能不能继续改造? 或者说如何得到最优的关系模式?标准是什么?是我们下面要讨论的问题。 Lu Wei
第二节 规范化 • 1.基本概念 • 2.规范化--范式 Lu Wei
1.基本概念 1.数据依赖 关系中属性值之间相互依赖又相互制约的联系称为数据依赖。数据依赖主要有两种:函数依赖和多值依赖。 2.函数依赖(Functional Dependency,简记为FD) 用U表示属性集的全集{A1,A2,...,An},设R(U)是属性集U上的关系模式。X,Y是U的子集。若对于R(U)的所有具体关系r都满足如下约束:对于X的每一个具体值,Y有唯一的具体值与之对应,则称Y函数依赖于X,或X函数决定Y,记作XY,X称作决定因素(Determinant)。 若XY, YX,则记作X Y 若Y不函数依赖于X,则记作XY Lu Wei
如果XY,并且Y不是X的子集(YX),则称XY是非平凡的函数依赖。如果XY,且Y是X的子集(YX),则称XY是平凡的函数依赖。如果XY,并且Y不是X的子集(YX),则称XY是非平凡的函数依赖。如果XY,且Y是X的子集(YX),则称XY是平凡的函数依赖。 根据函数依赖的定义,可以找出下面规律: ① 在一个关系模式中,如果属性X、Y有1:1联系,则存在函数依赖X Y、Y X,可记作XY。 ② 如果属性X、Y是1:m的联系,则存在函数依赖Y X,但X Y。 ③ 如果属性X、Y是n:m的联系,则X与Y之间不存在任何函数依赖。 Lu Wei
函数依赖是语义范畴的概念,只能根据语义来确定一个函数依赖。它是由数据库设计人员创建。函数依赖是语义范畴的概念,只能根据语义来确定一个函数依赖。它是由数据库设计人员创建。 例子:对于一个学习关系模式R(S#,SNAME,C#,GRADE,CNAME,TNAME,TAGE)中属性分别表示学生学号、姓名、课程号、成绩、课程名、任课教师姓名和年龄。 如果规定一个学号只能有一个学生姓名,一个课程号只能决定一门课程,那么可以有下列FD形式: S#→SNAME , C#→CNAME (S#,C#)→GRADE,C#→CNAME,TNAME,TAGE Lu Wei
3.完全函数依赖 设X Y是关系模式R(U)的一个函数依赖,如果存在X的真子集X‘,使得X’ Y成立,则称Y部分依赖于X,或Y对X部分函数依赖,记作X Y。否则,称Y完全依赖于X,或Y对X完全函数依赖,记作X Y。 由定义可知,当X是单个属性时,由于X不存在任何真子集,如果X Y,则X Y。 Lu Wei
S# GRADE C# CREDIT 设有关系模式选课 SCl(S#,C#,GRADE,CREDIT)其中,S#表示学号,C#表示课程号,GRADE表示成绩,CREDIT表示学分。 S#或C#都不能单独确定成绩GRADE。GRADE只能由属性组合(S#,C#)来确定。课程学分CREDIT是C#决定的,C# CREDIT。由此可知: (S#,C#) GRADE (S#,C#) CREDIT F P Lu Wei
4.传递依赖 在同一关系模式R(U)中,如果存在非平凡函数依赖X Y,Y Z而Y X,则称Z传递依赖于X,或Z对X传递依赖。 定义强调Y X十分必要。如果X、Y互相依赖,实际上处于等价地位,X Z则为直接函数依赖联系,并非传递依赖。 另外一种定义: 如果X → Y,Y → Z,且Y → X和Z Y,那么称X → Z是传递依赖(Z传递函数依赖于X) Lu Wei
设关系模式S1(S#,SNAME,D#,DNAME,LOCATION)各属性分别代表学号、姓名、所在系、系地址。设关系模式S1(S#,SNAME,D#,DNAME,LOCATION)各属性分别代表学号、姓名、所在系、系地址。 存在函数依赖:S# D#,D# LOCATION,根据传递依赖的定义,可知S# LOCATION是传递依赖。 实际上,部分依赖必然是传递依赖。如例2中 , SCl(S#,C#,GRADE,CEDIT) (S#,C#) C#,C# CREDIT,形成传递依赖(S#,C#) CREDIT。 Lu Wei
5.码 设K为R〈U,F〉中的属性或属性组合,若K U则K为R的候选码(Candidate key)。若候选码多于一个,则选定其中的一个为主码(Primary key)。 候选码两个属性:唯一标识性和无冗余性 包含在任何一个候选码中的属性,叫做主属性(Prime attribute)。不包含在任何码中的属性称为非主属性(Nonprime attribute)或非码属性(Non-key attribute)。 最简单的情况,单个属性是码。最极端的情况,整个属性组是码,称为全码(All-key)。 Lu Wei
关系模式R中属性或属性组X并非R的码,但X是另一个关系模式的码,则称 X是R的外部码(Foreign key)也称外码。 主码与外部码提供了一个表示关系间联系的手段。 Lu Wei
学生选课关系SC(S#,C#,GRADE,CREDIT)中,属性组(S#,C#)是候选码,也是主码。S#、C#是主属性。GRADE、CREDIT是非主属性。学生选课关系SC(S#,C#,GRADE,CREDIT)中,属性组(S#,C#)是候选码,也是主码。S#、C#是主属性。GRADE、CREDIT是非主属性。 演唱关系YC(P,W,A),属性P表示演奏者,W表示作品,A表示听众。假设一个演奏者可以演奏多个作品,某一作品可被多个演奏者演奏。听众也可以欣赏不同作品,这个关系模式的码为(P,W,A),即全码。 Lu Wei
Armstrong公理 逻辑蕴涵:对于满足一组函数依赖F的关系模式R(U,F),其中任何一个关系r,若函数依赖X→Y都成立,则称F逻辑蕴涵X→Y。 Armstrong公理:设U为属性集总体,F是U上的一组函数依赖,对于关系模式R(U,F),有一下推理规则: A1自反律:若YXU,则X→Y为F所蕴含 A2增广律:若X→Y为F所蕴含,且ZU,则XZ→YZ为F所蕴含 A3传递律:若X→Y及Y→Z为F所蕴含,则X→Z为F所蕴含 Lu Wei
公理推理规则: 合并规则:若X→Y, X→Z,则X→YZ。 伪传递规则:若X→Y, WY→Z,则XW→Z 。 分解规则:若X→Y且ZY ,则X→Z 。 组合规则:若A→B,C→D,则AC→BD。 根据函数依赖以及Armstrong公理及推理确定一个关系的主键。(教材278页例13.5) Lu Wei
F的闭包: 在关系模式R(U,F)中为F所逻辑蕴含的函数依赖的全体叫做F的闭包,记为F+。 X关于函数依赖集F的闭包: 设F为属性集U上的一组函数依赖,XU,XF+={A|X→A能由Armstrong公理导出}, XF+称为属性集X关于函数依赖F的闭包。 思考:求XF+算法 等价: 若G+=F+ ,则F与G等价 Lu Wei
若函数依赖集F满足下列条件,则称F为一个极小函数依赖集或最小依赖集或最小覆盖。若函数依赖集F满足下列条件,则称F为一个极小函数依赖集或最小依赖集或最小覆盖。 (1) F中任一函数依赖的右部仅含有一个属性 (2) F中不存在这样的函数依赖X→A,使得 F-{X→A}与F等价 (3) F中不存在这样的函数依赖X→A,X有真子集Z使得(F-{X→A})∪{Z→A}与F等价 每个函数依赖集F均等价与一个极小函数依赖Fm。 思考:求Fm的算法 Lu Wei
例:关系模式S(U,F),其中 U={SNO,SDEPT,MN,CNAME,G} F={SNO→SDEPT,SDEPT→MN, ,(SNO,CNAME)→G} F’={SNO→SDEPT,SNO→MN,SDEPT→MN,(SNO,CNAME)→G,(SNO,SDEPT)→SDEPT} 其中F为极小覆盖,而F’不是。 F’-{SNO→MN}与F’等价。 判断极小依赖集和判断一个依赖集是否为极小依赖集的算法思想基本一致。 Lu Wei
2.规范化--范式 设计关系数据库时,关系模式不可以随意建立,它们必须满足一定的规范化要求。一个关系模式满足某一指定的约束,称此关系模式为特定范式的关系模式。 满足最低要求的叫第一范式,简称lNF。在第一范式中满足进一步要求的为第二范式,其余以此类推。 R为第几范式就可以写成R∈xNF Lu Wei
1NF 2NF 3NF BCNF 4NF 5NF 数据独立性 低 高 我们将要讨论的各种范式之间的联系有 5NF 4NF BCNF 3NF 2NF lNF 一个低一级范式的关系模式,通过模式分解转换为若干个高一 级范式的关系模式的集合,这种过程称为规范化。 Lu Wei
第一范式(1NF) 定义 在关系模式R中的每一个具体关系r中,如果每个属性值都是不可再分的最小数据单位,则称R是第一范式(First Normal Form)的关系模式。记为RlNF。 不是1NF的关系称为非规范化的关系,满足1NF的关系称为规范化的关系。关系数据库研究的关系都是规范化的关系。因此,1NF也是关系数据库中关系的最低要求。 Lu Wei
例1 Lu Wei
将该表规范成lNF可以有三种方法: 第一种方法是重复存储职工号和姓名。 第二种方法是保留职工号的码的地位,把电话号码拆分成单位电话和住宅电话两个属性。 第三种方法是保留职工号的码的地位。维持原模式不变,但强制每个元组只能录入一个电话号码。 以上三种选择,第一种最不可取,后两种选择可根据应用需要确定一种。 Lu Wei
满足第一范式的关系是否还存在问题 例2:设有关系模式SC(S#,C#,GRADE,CREDIT),其中CREDIT表示学分。存在函数依赖:(S#,C#) GRADE, C# CREDIT,候选码是(S#,C#)。 Lu Wei
该关系模式在实际使用中会出现下列问题: ① 数据冗余。 ② 更新异常。 ③ 插入异常。 ④ 删除异常。 原因在于关系模式中的非主属性CREDIT函数依赖于组合关键字(S#,C#)的一部分,而不是全部,即 (S#,C#) CREDIT。 Lu Wei
第二范式(2NF) 定义 若R∈lNF,且每一个非主属性完全函数依赖于码,则R∈2NF。 上面例2中的关系模式SC显然就不是2NF,因为它存在部分依赖(S#,C#) CREDIT,将上述非2NF的关系SC规范化为2NF关系,应设法消除部分依赖 Lu Wei
通过投影把它分解为以下两个关系模式: SCl(S#,C#,GRADE) C2(C#,CREDIT) 新关系模型包括两个关系模式,它们之间通过SCl中的外关键字C#相联系,需要时再自然联接,则恢复了原来的关系。 Lu Wei
例3关系模式S-L-C(SNO,SDEPT,SLOC,CNO,G) 其中,SLOC为学生的住处,并且每个系的学生住在同一个地方。 这个关系模式的码为(SNO,CNO),函数依赖有 (SNO,CNO)G , SNO SDEPT SNO SLOC,SDEPT SLOC (SNO,CNO) SDEPT (SNO,CNO) SLOC 如下图所示 F P P Lu Wei
关系模式S-L-C(SNO,SDEPT,SLOC,CNO,G)不符合2NF,即S-L-C∈2NF关系模式S-L-C(SNO,SDEPT,SLOC,CNO,G)不符合2NF,即S-L-C∈2NF Lu Wei
这个关系模式存在的问题: 1.插入异常 例如,插入SNO=7,SDEPT=PHY,SLOC=BLD2,由于没有CNO值,所以无法插入 2.删除异常 假设S4只选修了一门课C3,如果现在不选C3,删除C3数据项时,由于C3是主属性,所以整个元组将删除,S4的其他信息都将被删除。 3.修改复杂 例如,修改某个学生的系时,本来只需要修改SDEPT,但SLOC也必须跟着修改。 另外,如果学生选修了K门课程,SDEPT,SLOC重复存储了K次,不仅冗余度大,而且修改复 Lu Wei
分析上面的例3,关系模式产生问题的主要原因在于,关系模式中存在非主属性对码的部分依赖,解决的办法是用投影分解把关系模式S-L-C分解为两个关系模式。分析上面的例3,关系模式产生问题的主要原因在于,关系模式中存在非主属性对码的部分依赖,解决的办法是用投影分解把关系模式S-L-C分解为两个关系模式。 SC(SNO,CNO,G) S-L(SNO,SDEPT,SLOC) 如下图所示 Lu Wei
SNO SDEPT CNO G SNO SLOC 分解之后,关系模式SC的码为(SNO,CNO), 关系模式S-L的码为SNO,这样就使得非主属性对码都是完全函数依赖了。 Lu Wei
满足第二范式的关系模式是否就没有问题了 例4 关系模式Sl(S#,SNAME,D#,DNAME,LOCATION),关键字是S#,不存在部分依赖,属于2NF。但仍然存在大量冗余,关于系的重复值随着学生的增加而增加。在插入、删除或修改元组时也将产生类似例3的异常情况。 分析其原因,由于关系中存在传递依赖 S# LOCATION,(S# D#,D# S#,D# LOCATION)。 Lu Wei
在例3中,我们通过把关系模式 S-L-C(SNO,SDEPT,SLOC,CNO,G) 分解为两个关系模式 SC(SNO,CNO,G) S-L(SNO,SDEPT,SLOC) 从而使分解后的两个关系模式满足2NF,但是对于关系模式S-L是否还存在问题 Lu Wei
第三范式(3NF) 定义如果关系模式R(U,F)中若不存在这样的码X,属性组Y及非主属性组Z(ZY)使得XY,(YX) YZ成立,则R(U,F)3NF。 或者 如果关系模式R(U,F)中的所有非主属性对码都不存在传递依赖(第二种定义),则称关系只是第三范式的。 如果R∈3NF,则R∈2NF Lu Wei
上面的例4显然就不满足3NF,因为它存在传递依赖S#D#,D#S#,D#LOCATION,我们通过将关系模式S1分解为两个关系模式上面的例4显然就不满足3NF,因为它存在传递依赖S#D#,D#S#,D#LOCATION,我们通过将关系模式S1分解为两个关系模式 S(S#,SNAME,D#) D(D#,DNAME,LOCATION) 后,则这两个关系模式都满足3NF 注意,投影时不能从关系S中遗漏外关键字D#,否则这两个关系之间将失去联系,就不能通过自然联接再恢复原来的关系了 Lu Wei
在例3中,我们通过把关系模式S-L-C(SNO,SDEPT,SLOC,CNO,G)在例3中,我们通过把关系模式S-L-C(SNO,SDEPT,SLOC,CNO,G) 分解后,得到两个满足2NF的关系模式 SC(SNO,CNO,G) S-L(SNO,SDEPT,SLOC) 其中,关系模式S-L(SNO,SDEPT,SLOC)仍然不满足3NF,刚才讨论过,这个关系模式还可能出现问题,因此可以继续分解为 S-D(SNO,SDEPT) D-L(SDEPT,SLOC) 从而使这两个关系模式满足3NF Lu Wei
部分函数依赖和传递函数依赖是产生存储异常的两个重要原因,3NF消除了大部分存储异常,具有较好的性能。部分函数依赖和传递函数依赖是产生存储异常的两个重要原因,3NF消除了大部分存储异常,具有较好的性能。 但3NF并没有要求消除主属性对候选关键字的传递依赖,如果存在这种情况,3NF模式仍然可能发生存储异常现象。 Lu Wei
BCNF范式 定义关系模式R(U,F)1NF。若XY,且YX,则X必含有码,则R(U,F)BCNF。 或者 如果关系模式R(U,F)的所有属性都不传递依赖于R的任何候选码,那么称关系RBCNF。 如果RBCNF,则R3NF Lu Wei