第二章-关系数据库课件

单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,单击此处编辑母版标题样式,第 二 章 关系数据库规范化理论,建立在关系模型基础上实现的 数据库系统称为关系数据库，相应的,DBMS,称为关系数据库管理系统（,RDBMS）。,如何设计一个适合的关系数据库系统，关键是,关系数据库模式的设计,，一个好的关系数据库模式应该包括多少,关系模式,，而每一个关系模式又应该包括哪些,属性，,又如何将这些相互关联的关系模式组建一个适合的,关系模型,，这些工作决定了到整个系统运行的效率，也是系统成败的关键所在。,要设计一个好的关系数据库，必须需要一定理论指导。关系数据库的,规范化理论就是数据库设计的一个理论指导,。,本章主要讨论,关系数据库规范化理论,，讨论一个好的关系模式的标准，以及如何将不好的关系模式转换成好的关系模式,第 二 章 关系数据库规范化理论,2.1 规范化问题的提出,2.2 函数依赖,2.3 关系规范化,2.4 关系模式的分解准则,2.5 小结,2.1 规范化问题的提出,关系数据库的规范化理论最早是由,关系数据库的创始人,E.F.Codd,提出的，,后经许多专家学者对关系数据库理论作了深入的研究和发展，形成了一整套,有关关系数据库设计的理论,。,关系数据库的规范化理论主要包括三个方面的内容：,函数信赖,范式（,Normal Form）,模式设计和模式分解,其中，,函数信赖,起着核心的作用，是模式分解和模式设计的基础，,范式,是模式分解的标准。,2.1 规范化问题的提出,数据库的设计为什么要遵循一定的规范化理论？,什么是好的关系模式？,某些不好的关系模式可能导致哪些问题？,下面通过例子进行分析:,例如，,设有描述学生修课及住宿情况的关系模式：,S-L-C（,Sno,Sdept,Sloc,Cno,Grade）,Sno,表示学生学号，,Sdept,表示学生所在的 系，,Sloc,表示学生所住宿舍楼，,Cno,表示课程号，,Grade,表示成绩。,2.1 规范化问题的提出,Sno,Sdept,SLOC,Cno,Grade,9812101,计算机,2公寓,DB,80,9812101,计算机,2公寓,OS,85,9821101,信息,1公寓,C,90,9821101,信息,1公寓,DS,84,9821102,信息,1公寓,OS,78,S-L-C,关系模式实例,分析以上关系中的数据，我们可以看出：(,SNO,CNO),属性的组合能唯一标识一个元组，所以,(,SNO,CNO),是该关系模式的,主码,。,3. 删除异常,如果某个学生不再选修,C,课程，本应该只删去,C，,但,C,是主关系键的一部分，为保证实体完整性，必须将整个元组一起删掉，这样有关该学生的其它信息也随之丢失。,2.1 规范化问题的提出,但在进行数据库的操作时，会出现以下几方面的问题：,1. 数据冗余,学生所在的系名和这个系所对应的宿舍楼名字存储的次数等于该系的学生人数乘以每个学生选修的课程门数，数据的冗余度很大，浪费了存储空间。,2. 插入异常,如果某个学生尚未选课, 则学生所在的系名和这个系所对应的宿舍楼无法插入到数据库中。,因为在这个关系模式中，(,SNO,CNO),是主关系键。根据关系的实体完整性约束，主关系键的值不能为空，当某个学生尚未选课，即,Cno,为空, 因此不能进行插入操作。,2.1 规范化问题的提出,4. 更新异常,如果某一学生从计算机系转到信息系，那么不但要修改此学生的,Sdept,列的值,而且还要修改其,Sloc,的值,稍有不慎，就有可能漏改某些记录，这就会造成数据的不一致性，破坏了数据的完整性。,由于存在以上问题，我们说，,S-L-C,是一个不好的关系模式。那么，怎样才能得到一个好的关系模式呢？,我们把关系模式,S-L-C,分解为下面三个结构简单的关系模式，如图所示。,Sno,Sdept,SLOC,Cno,Grade,9812101,计算机,2公寓,DB,80,9812101,计算机,2公寓,OS,85,9821101,信息,1公寓,C,90,9821101,信息,1公寓,DS,84,9821102,信息,1公寓,OS,78,Sno,Cno,Grade,9812101,DB,80,9812101,OS,85,9821101,C,90,9821101,DS,84,9821102,OS,78,Sdept,Sloc,计算机,2公寓,信息,1公寓,Sno,Sdept,9812101,计算机,9821102,信息,2.1 规范化问题的提出,S-L,S-D,S-C,学生关系,S-D(Sno, Sdept),选课关系,S-C(Sno,Cno,Grade),系关系,S-L(Sdept,Sloc),2.1 规范化问题的提出,在以上三个关系模式中，实现了信息的某种程度的分离，,S-D,中存储学生基本信息，与所选课程及宿舍无关；,S-L,中存储系的有关信息，与学生无关；,S-C,中存储学生选课的信息，而与学生及系的有关信息无关。,与,S-L-C,相比，分解为三个关系模式后，,数据的冗余度,明显降低。,当新插入一个系时，只要在关系,S-L,中添加一条记录。,当某个学生尚未选课，只要在关系,S-D,中添加一条学生记录，而与选课关系无关，这就避免了插入异常。,当某个学生选课后又退选，只需在,S-C,中删除该学生记录，而关系,S-D,中有关该学生的信息仍然保留，从而不会引起删除异常。,同时，由于数据冗余度的降低，数据没有重复存储，也不会引起更新异常。,2.1 规范化问题的提出,经过上述分析，我们说分解后的关系模式是一个好的关系数据库模式。,一个好的关系模式应该具备以下四个条件：,尽可能少的数据冗余,没有插入异常,没有删除异常,没有更新异常,如何按照一定的规范设计关系模式，将结构复杂的关系分解成结构简单的关系，从而把不好的关系数据库模式转变为好的关系数据库模式，这就是,关系的规范化,。,我们要设计的关系模式中的各属性是相互依赖、相互制约的，这样才构成了一个结构严谨的整体。,因此在设计关模式时，必须从语义上分析这些,依赖关系,。,2.2 函数依赖,1.函数依赖的定义,函数对我们来说已经是非常熟悉的概念，对公式：,Y,=,f,(,X,),给定一个,X,值，都会有一个,Y,值和它对应，也可以说,X,函数决定,Y,，,或,Y,函数依赖于,X,。,在关系数据库中讨论函数或函数依赖注重的,是语义上的关系，,比如： 省=,f,(,城市),如果,“,城市,”,是自变量,X,，,“,省,”,是因变量或函数值,Y,。,并且把,X,决定,Y,，,或,Y,函数依赖于,X,表示为：,X,Y,2.2 函数依赖,函数依赖定义,：如果有一个,关系模式,R,(,A1,A2,An,),，,X,和,Y,为,A1,A2,An,的子集,，,那么对于关系,R,中的任意一个,X,值，都只有一个,Y,值与之对应，则称,X,函数决定,Y,，,或,Y,函数依赖于,X,。,例如：对学生关系模式：,Student（Sno, SName, Sdept, Sage）,有：,SnoSName, SnoSdept, SnoSage,对学生修课关系模式：,SC（Sno, Cno, Grade）,有：,（,Sno, Cno）Grade,2.2 函数依赖,2函数依赖与属性之间的联系类型有关,（1）在一个关系模式中，如果属性,X,与,Y,有1:1联系时，则存在函数依赖,XY，YX，,即,X,Y,（2）,如果属性,X,与,Y,有1:,m,的联系时，则只存在函数依赖,Y, X 。,例如，,Sage,Sdept,与,Sno,之间均为1:,m,联系，所以有,SNOSage，SnoSdept。,（3）,如果属性,X,与,Y,有,m: n,的联系时，则,X,与,Y,之间不存在任何函数依赖关系。,例如，一个学生可以选修多门课程，一门课程又可以为多个学生选修，所以,SNO,与,CNO,之间不存在函数依赖关系。,由于函数依赖与属性之间的联系类型有关，所以在确定属性间的函数依赖关系时，可以从,分析属性间的联系类型入手，便可确定属性间的函数依赖。,例如，当学生无重名时，,SNO SN,2.2 函数依赖,3一些术语和符号,设有关系模式,R,(,A1,A2,An,)，,X,和,Y,均为,A1,A2,An,的子集,如果,X,Y,，,但,Y,不包含于,X,，,则称,X,Y,是非平凡的函数依赖。,如果,X,Y,，,则称,X,为决定因子。,f,X,Y,X,Y,p,如果,Y,函数不依赖于,X,，,则记作,X Y,。,如果对,X,的某个真子集,X，,有,XY，,则称,Y,部分函数依赖于,X,，,(,或称,Y,对,X,部分函数依赖)记作,。,如果,X,Y,，,并且,Y,X,，,则记作,X Y,。,如果,X,Y,，,并且对于,X,的一个任意真子集,X,/,都有,X,/,Y,，,则称,Y,完全函数依赖于,X,(Y,对,X,完全函数依赖,),，,记作,2.2 函数依赖,例1：有关系模式：,SC（Sno,Sname,Cno,Credit,Grade）,各属性分别为：学号、姓名、课程号、学分、成绩，主码为（,Sno, Cno）,f,p,函数依赖关系有：,SnoSname,姓名函数依赖于学号,因为,Sno Grade,Cno Grade, (Sno,Cno) Grade,所以有,（,Sno, Cno） Grade,成绩完全函数依赖于学号和课程号,（,Sno, Cno） Sname,姓名部分函数依赖于学号和课程号,2.2 函数依赖,如果,XY（,非平凡函数依赖，并且,Y,X）、YZ，,则称,Z,传递函数,依赖于,X(,或称,Z,对,X,传递函数依赖),。,例如:在关系模式：,S（Sno,Sname,Dept,Dept_master）,中,各属性分别为：学号、姓名、所在系和系主任（假设一个系只有一 个主任），主码为,Sno。,传递,函数依赖关系有：,Sno Sname,由于：,Sno Dept , Dept Dept_master,所以有：,Sno,Dept_master,(,系主任传递函数依赖于学号),一.关系模式中的码,1候选码,设,K,为,R (U, F),中的属性或属性组，若,K U，,则,K,为,R,候选码。（,U-,表示关系,R,的属性全集,F-,表示关系,R,上的依赖函数集),主码：,关系,R,(,U,F,),中可能有多个候选码，则选其中一个作为 主码,全码,：候选码为整个属性组。,主属性与非主属性：,在,R,(,U,F,),中，,包含在任一候选码中的属性称为主属性，不包含在任一候选码中的属性称为非主属性。,例1：,SC（Sno，Cno，Grade）,其候选码为,：（,Sno，Cno），,也为主码,则主属性为,：,Sno，Cno ， Grade,为非主属性。,2.3 关系规范化,f,2.3 关系规范化,一.关系模式中的码,例2：,R（P，W，A）,其中各属性含义分别为： 演奏者，作品和听众。其语义为：一个演奏者可演奏多个作品，某一作品可被多个演奏者演奏；听众也可欣赏不同演奏者个不同作品。,其,候选码为：（,P，W，A）,，,因为只有这三者才能确定一场音乐会。我们称全部属性均为主码的表为,全码表,。,2外码,定义：,若,R（U，F）,的属性（组）,X（X,属于,U）,是另一个关系,S,的主码，则称,X,为,R,的外码。,例3: 学生关系,SD(Sno, Sdept),和,选课关系,SC(Sno,Cno,Grade),SC,中的,Sno,是,SD,中的,主码,则,Sno,是,SC,的,外码,2.3 关系规范化,二.范式,规范化的,基本思想,是消除关系模式中的数据冗余，消除数据依赖中的不合适的部分，解决数据插入、更新、删除时发生异常现象。,这就要求关系数据库设计出来的关系模式要满足一定的条件。,我们把关系数据库的规范化过程中为不同程度的规范化要求设立的不同标准称为,范式,（,Normal Form）。,由于规范化的程度不同，就产生了,不同的范式,。,满足最基本规范化要求的关系模式叫,第一范式(1,NF),在第一范式中进一步满足一些要求为,第二范式(2,NF),以此类推就产生了,第三范式(3,NF),等概念。,每种范式都规定了一些限制约束条件。,2.3 关系规范化,二.范式,范式的概念最早由,E.F.Codd,提出。,从1971年起，,Codd,相继提出了关系的三级规范化形式，即第一范式（1,NF）、,第二范式（2,NF）、,第三范式（3,NF）。,1974,年，,Codd,和,Boyce,以共同提出了一个新的范式的概念，即,Boyce-Codd,范式，简称,BC,范式,。,1976年,Fagin,提出了第四范式，,后来又有人定义了第五范式。,至此在关系数据库规范中建立了一个范式系列：,1,NF,2NF,3NF,BCNF,4NF,5NF,一级比一级有更严格的要求。,2.3 关系规范化,4NF,5NF,BCNF,3NF,2NF,1NF,规范与非规范关系,各个范式之间的联系可以表示为：,5,NF 4NF BCNF 3NF 2NF 1NF,2.3 关系规范化,1第一范式,第一范式,（,First Normal Form）,是最基本的规范形式，即关系中每个属性都是不可再分的简单项。,定义:,如果关系模式,R，,其所有的属性均为简单属性，即每个属性都是不可再分的，则称,R,属于第一范式，简称,1,NF,，,记作,R,1NF,。,系名称,高级职称人数,教授,副教授,计算机系,6,10,信息管理系,3,5,电子与通讯系,4,8,系名称,教授,副教授,计算机系,6,10,信息管理系,3,5,电子与通讯系,4,8,2.3 关系规范化,2第二范式,定义：,如果关系模式,R,1NF，,并且,R,中的每个非主属性都完全函数 依赖于主码，则,R,2NF。,例：,S-L-C（Sno,Sdept,Sloc,Cno,Grade）,就不是2,NF,的。,因为（,Sno,Cno）,是主码，而又有：,SnoSdept,因此有：,（,Sno，Cno） Sdept,p,即,存在非主属性对主码的部分函数依赖，所以,S-L-C,不是2,NF。,2.3 关系规范化,2第二范式,分解过程为：,首先，对于组成主码的属性集合的每一个子集，用它作为主码构成一个表。,S-C(Sno,Cno,),S(Sno,),C(Cno,),f,f,f,对于每个表，将依赖于此主码的属性放置到此表中。,S-L-C,关系模式分解后的形式为：,S-L（,Sno,Sdept,Sloc）,和,S-C（Sno, Cno,Grade）,S-L,有：,Sno Sdept，Sno SLOC：,是2,NF,S-C,有:（,Sno, Cno） Grade：,是2,NF,2.3 关系规范化,2第二范式,2,NF,的缺点,2,NF,的关系模式在进行数据操作时，仍然存在着一些问题：,数据冗余,每个系名和所在的宿舍楼名字存储的次数等于该系的学生人数。,插入异常,当一个新系没有招生时，有关该系的信息无法插入。,删除异常,某系学生全部毕业而没有招生时，删除全部学生的记录也随之删除了该系的有关信,更新异常,更换系所在宿舍楼名字时，仍需改动较多的学生记录。,之所以存在这些问题，是由于在,S-L,表中存在着,非主属性对主码的传递依赖,。,分析,S-L,表中函数依赖关系，,SnoSdept，SdeptSloc，SnoSloc，,非主属性,Sloc,对主码,Sno,传递依赖。,为此，对关系模式还需进一步简化，消除这种传递依赖，得到3,NF。,S-L,分解后的关系模式为：,S-D（,Sno,Sdept）,和,D-L（,Sdept,Sloc）,对,S-D，,有：,Sno Sdept，,因此,S- D,是3,NF,的,对,D-L，,有：,Sdept Sloc，,因此,D-L,也是3,NF,的,2.3 关系规范化,3第三范式,定义：,如果,R,(,U,F,) 2NF，,并且所有非主属性都不传递依赖于主码，则,R,(,U,F,) 3NF。,f,f,关系模式,S-L（,Sno,Sdept,Sloc）,不是3,NF,。,分解过程为:,（1）对于不是候选码的每个决定因子，从表中删去依赖于它的所有属性； 得到,S-D（,Sno,Sdept）,（2）新建一个表，新表中包含在原表中所有依赖于该决定因子的属性；,（3）将决定因子作为新表的主码。新建的表:,D-L（Sdept,Sloc）,2.3 关系规范化,3第三范式,关系模式,S-L,由2,NF,分解为3,NF,后，函数依赖关系变得更加简单，既没有非主属性对主码的部分依赖，也没有非主属性对主码的传递依赖，解决了2,NF,中存在的四个问题。,数据冗余降低,。系所在的宿舍楼名字存储次数与该系的学生人数无关，只在关系,D-L,中存储一次,不存在插入异常。,当一个新系没有学生时，该系的信息可以直接插入到关系,D-L,中，而与学生关系,S-D,无关,不存在删除异常,。要删除某系的全部学生而仍然保留该系的有关信息时，可以只删除学生关系,S-D,中的相关学生记录，而不影响系关系,D-L,中的数据。,不存在更新异常,。更换所在的宿舍楼时，只需修改关系,D-L,中一个相应元组的,Sloc,属性值，从而不会出现数据的不一致现象。,S-L-C,规范到3,NF,后，所存在的异常现象已经全部消失。,通常在数据库设计中，,一般要求要达到,3,NF,。,3第三范式,但是3,NF,只限制了非主属性对码的依赖关系，而没有限制主属性对码的,依赖关系。,例如：,设关系模式,SNC（SNO，SN，CN0，SCORE），,其中,SNO,代表学号，,SN,代表学生姓名并假设没有重名，,CNO,代表课程号，,SCORE,代表成绩。可以判定，,SNC,有两个候选码（,SNO，CNO）,和（,SN，CNO），,其函数依赖如下：,SNO SN （SNO，CNO）SCORE （SN，CNO）SCORE,如某个同学需要改名，则需要将该学生的所有记录都要进行修改，,稍有不慎，就有可能漏改某些记录，这就会造成数据的不一致性。,产生操作异常的原因:,（,SNO，CNO） SN，,即存在主属性对码的部分函数依赖,为了解决这种问题，,Boyce,与,Codd,共同提出了一个新范式的定义，这就是,Boyce-Codd,范式，通常简称,BCNF,或,BC,范式。它弥补了3,NF,的不足。,2.3 关系规范化,p,但是，因为,SNO SN，,即决定因素,SNO,或,SN,不包含候选码，,从另一个角度说，存在着主属性对码的部分函数依赖：,（,SNO，CNO） SN， （SN，CNO） SNO，,所以,SNC,不是,BCNF。,2.3 关系规范化,4,BC,范式 (,BCNF),定义：,若关系模式,R1NF，,对于关系,R,的每个函数依赖,XY,且,Y,X,，,X,必含有候选码，则,RBCNF,。,即,每个决定属性集都包含候选码。,上面例子中唯一的非主属性,SCORE,对码不存在部分函数依赖，也不存在传递函数依赖。所以,SNC,3NF。,p,p,2.3 关系规范化,4,BC,范式 (,BCNF),解决这一问题的办法仍然是通过,投影分解,进一步提高,SNC,的范式等级，将,SNC,规范到,BCNF。,可以将,SNC,分解成如下两个关系：,S1(SNO,SN),S2(SNO,CNO,SCORE),对于,S1，,有两个候选码,SNO,和,SN，,对于,S2，,主码为（,SNO，CNO）。,在这两个关系中，,每个决定属性集都包含候选码(即,无论主属性还是非主属性都不存在对码的部分依赖和传递依赖)，,S1,BCNF，S2,BCNF。,关系,SNC,转换成,BCNF,后，数据冗余度明显降低。学生的姓名只在关系,S1,中存储一次，学生要改名时，只需改动一条学生记录中的相应的,SN,值，从而不会发生修改异常。,SNO,SN,S1,中的函数依赖关系,SNO,CNO,SCORE,S2,中的函数依赖关系,2.4 关系模式的分解准则,关系规范化的目的：,解决关系模式中存在的插入、删除、更新操作异常，数据冗余问题.,关系规范化的方法：,围绕,函数依赖,的主线，对一个关系模式进行分解，使关系从较低级范式变换到较高级范式。(,模式分解),分解关系模式，逐步消除不合适的函数依赖,1NF,2NF,3NF,BCNF,消除非主属性对码的部分函数依赖,消除非主属性对码的传递函数依赖,消除主属性对码的部分和传递函数依赖,2.4 关系模式的分解准则,模式分解的准则：,模式分解具有无损连接性:,分解后的关系通过自然连接可以恢复成原来的关系，即通过自然连接得到的关系与原来的关系相比，既不多出信息、又不丢失信息。,模式分解能够保持函数依赖,:,在模式的分解过程中，函数依赖不能丢失的特性，即模式分解不能破坏原来的语义。,2.4 关系模式的分解准则,例：,S-D-L（Sno，Dept，Loc）,有函数依赖：,Sno Dept， Dept Loc,不是第三范式的。至少可以有三种分解方案，分别为：,方案1,：,S-L（Sno，Loc），D-L（Dept，Loc）,方案2,：,S-D（Sno，Dept），S-L（Sno，Loc）,方案3,：,S-D（Sno，Dept），D-L（Dept，Loc）,这三种分解方案得到的关系模式都是第三范式的，那么如何比较这三种方案的好坏呢？由此在将一个关系模式分解为多个关系模式时除了提高规范化程度之外，还需要遵守一定的准则.,三种分解方案是否都满足分解准则呢？,2.4 关系模式的分解准则,假设此关系模式的数据,如表2-1,所示，此关系用,r,表示。,Sno,Dept,Loc,S01,D1,L1,S02,D2,L2,S03,D2,L2,S04,D3,L1,表21,2.4 关系模式的分解准则,方案1:,将,S-D-L,分解投影得到,S-L,和,D-L,关系,Sno,Loc,S01,L1,S02,L2,S03,L2,S04,L1,Dept,Loc,D1,L1,D2,L2,D3,L1,S-L,D-L,Sno,Dept,Loc,S01,D1,L1,S01,D3,L1,S02,D2,L2,S03,D2,L2,S04,D1,L1,S04,D3,L1,表22,结论: 方案1不满足无损连接性,自然连接,2.4 关系模式的分解准则,方案2:,将,S-D-L,分解投影得到,S-D,和,S-L,关系,Sno,Dept,S01,D1,S02,D2,S03,D2,S04,D3,Sno,Loc,S01,L1,S02,L2,S03,L2,S04,L1,S-D,S-L,Sno,Dept,Loc,S01,D1,L1,S02,D2,L2,S03,D2,L2,S04,D3,L1,表23,结论: 方案2满足无损连接性,但,没有保持原有的函数依赖关系,.,但,如果假设学生,S03,从,D2,系转到了,D3,系，则需在表,S-D（S03,D2）,改为（,S03,D3），,同时还需要在表,S-L（S03,L2）,改为（,S03,L1）。,如果这两个修改没有同时进行，则数据库中就会出现不一致信息。这是由于,这样分解得到的两个关系模式没有保持原来的函数依赖关系造成的,。原有的函数依赖,Dept Loc,在分解后跨在了两个关系模式上。因此分解方案2没有保持原有的函数依赖关系，也不是好的分解方法。,自然连接,2.4 关系模式的分解准则,方案3:,将,S-D-L,分解投影得到,S-D,和,D-L,关系,Dept,Loc,D1,L1,D2,L2,D3,L1,S-D,D-L,Sno,Dept,Loc,S01,D1,L1,S02,D2,L2,S03,D2,L2,S04,D3,L1,表24,结论: 方案3既满足无损连接性,又,保持原有的函数依赖关系,.,故它是一个好的分解方法,Sno,Dept,S01,D1,S02,D2,S03,D2,S04,D3,自然连接,2.4 关系模式的分解准则,分解具有无损连接性和分解保持函数依赖是两个独立的标准。,具有无损连接性的分解不一定保持函数依赖；保持函数依赖的分解不一定具有无损连接性。,一般情况下，在进行模式分解时，应将有,直接依赖关系的属性放置在一个关系模式中,，这样得到的分解结果一般能具有无损连接性，并能保持函数依赖关系不变。,2.5 小结,关系规范化理论,是设计没有操作异常的关系数据库的,基本原则.,规范化理论主要是,研究关系中各属性之间的依赖关系,，根据依赖关系的不同，我们介绍了不包含子属性的,第一范式,，到消除了属性间的部分依赖关系的,第二范式,，再到消除了属性间的传递依赖关系的,第三范式,，最后到每个决定因子都必须是候选码的,BCNF,。,范式的每一次升级都是通过,模式分解,实现的，在进行模式分解时应注意保持分解后的关系能够,具有无损连接性并能保持原有的函数依赖关系。,对于一般的数据库应用来说，设计到,第三范式,就足够了。因为规范化程度越高,分解得越细,表的个数越多,则在检索操作时会因连接而降低检索效率。,