第四章关系数据库 设计 理论

1、关系模式的设计问题 函数依赖 范式与规范化 函数依赖的推理规则 模式分解,本章要点,关系数据库设计理论,5.1 关系模式设计的问题,前面已经讲述了关系数据库、关系模型的基本概念以及关系数据库的标准语言。 如何使用关系模型设计关系数据库，也就是面对一个现实问题，如何选择一个比较好的关系模式的集合，每个关系又应该由哪些属性组成。这属于数据库设计的问题，确切地讲是数据库逻辑设计的问题，有关数据库设计的全过程将在第6章详细讨论。 本章讲述关系数据库规范化理论，这是数据库逻辑设计的理论依据。 了解规范化理论的研究动机及其在数据库设计中的作用， 掌握函数依赖的有关概念， 第一范式、第二范式、第三范式的定义， 重点掌握并能够灵活运用关系模式规范化的方法和关系模式分解的方法，这也是本章的难点。,5.1 关系模式设计的问题,关系数据库的规范化理论最早是由关系数据库的创始人E.F.Codd提出的，后经许多专家学者对关系数据库理论作了深入的研究和发展，形成了一整套有关关系数据库设计的理论。 在关系数据库系统中，关系模型包括一组关系模式，各个关系不是完全孤立的。,5.1 关系模式设计的问题,如何设计一个适合的

2、关系数据库系统，关键是关系数据库模式的设计，一个好的关系数据库模式应该包括多少关系模式，而每一个关系模式又应该包括哪些属性，又如何将这些相互关联的关系模式组建一个适合的关系模型，这些工作决定了到整个系统运行的效率，也是系统成败的关键所在，所以必须在关系数据库的规范化理论的指导下逐步完成。 规范化理论主要包括三个方面的内容： 函数依赖 范式（Normal Form） 模式设计 其中，函数依赖起着核心的作用，是模式分解和模式设计的基础，范式是模式分解的标准。,5.1 关系模式设计的问题,一个关系模式是一个五元组：R(U，D，DOM，F) R为关系名 U为组成该关系的属性名集合 D为属性组U中属性所来自的域 DOM为属性向域的映象集合 F为属性间数据的依赖关系集合,由于D，DOM对模式设计关系不大，因此在本章总把关系模式看作是一个三元组： R(U，F),5.1 关系模式设计的问题,关系模式的存储异常问题 数据库的逻辑设计为什么要遵循一定的规范化理论？ 什么是好的关系模式？ 某些不好的关系模式可能导致哪些问题？ 下面通过例子进行分析:,5.1 关系模式设计的问题,例：要求设计教学管理数据库，其

3、关系模式SCD如下： SCD(Sno,Sname,Age,Dept,Mn,Cno,Score) 其中，Sno表示学生学号，Sname表示学生姓名，Age表示学生年龄，Dept表示学生所在的系别，Mn表示系主任姓名，Cno表示课程号，Score表示成绩。 根据实际情况，这些数据有如下语义规定： 1. 一个系有若干个学生，但一个学生只属于一个系； 2. 一个系只有一名系主任(正职)； 3. 一个学生可以选修多门功课，每门课程可有若干学生选修； 4. 每个学生学习课程有一个成绩。 在此关系模式中填入一部分具体的数据，则可得到SCD关系模式的实例，即一个教学管理数据库，如下图所示。,5.1 关系模式设计的问题,5.1 关系模式设计的问题,根据上述的语义规定，并分析以上关系中的数据，我们可以看出：(SNO,CNO)属性的组合能唯一标识一个元组，所以(SNO,CNO)是该关系模式的主键。但在进行数据库的操作时，会出现以下几方面的问题。 问题：麻烦! 麻烦! 好麻烦! 唉，剪不断，理还乱 1. 数据冗余。每个系名和系主任的名字存储的次数等于该系的学生人数乘以每个学生选修的课程门数，同时学生的姓名、年

4、龄也都要重复存储多次，数据的冗余度很大，浪费了存储空间。 2. 插入异常。如果某个新系没有招生，尚无学生时，则系名和系主任的信息无法插入到数据库中。 因为在这个关系模式中，(SNO,CNO)是主关系键。根据关系的实体完整性约束，主关系键的值不能为空，而这时没有学生，SNO和CNO均无值，因此不能进行插入操作。 另外，当某个学生尚未选课，即CNO未知，实体完整性约束还规定，主关系键的值不能部分为空，同样不能进行插入操作。,5.1 关系模式设计的问题,3. 删除异常。 某系学生全部毕业而没有招生时，删除全部学生的记录则系名、系主任也随之删除，而这个系依然存在，在数据库中却无法找到该系的信息。 另外，如果某个学生不再选修C1课程，本应该只删去C1，但C1是主关系键的一部分，为保证实体完整性，必须将整个元组一起删掉，这样，有关该学生的其它信息也随之丢失。 4. 更新异常。 如果学生改名，则该学生的所有记录都要逐一修改SN； 又如某系更换系主任，则属于该系的学生记录都要修改MN的内容，稍有不慎，就有可能漏改某些记录，这就会造成数据的不一致性，破坏了数据的完整性。,5.1 关系模式设计的问题,由于

5、存在以上问题，我们说，SCD是一个不好的关系模式。产生上述问题的原因，直观地说，是因为关系中“包罗万象”，内容太杂了。 那么，怎样才能得到一个好的关系模式呢？ 解决之道：分解! 分解! 再分解! 哇，原来生活可以如此简单 我们把关系模式SCD分解为下面三个结构简单的关系模式，如图4.2所示。 学生关系S(SNO,SN,AGE,DEPT) 选课关系SC(SNO,CNO,SCORE) 系关系D(DEPT,MN),5.1 关系模式设计的问题,5.1 关系模式设计的问题,在以上三个关系模式中,实现了信息的某种程度的分离; S中存储学生基本信息，与所选课程及系主任无关； D中存储系的有关信息，与学生无关； SC中存储学生选课的信息，而与所学生及系的有关信息无关。 与SCD相比，分解为三个关系模式后，数据的冗余度明显降低。 当新插入一个系时，只要在关系D中添加一条记录。 当某个学生尚未选课，只要在关系S中添加一条学生记录，而与选课关系无关，这就避免了插入异常。 当一个系的学生全部毕业时，只需在S中删除该系的全部学生记录，而关系D中有关该系的信息仍然保留，从而不会引起删除异常。 同时，由于数据冗余度

6、的降低，数据没有重复存储，也不会引起更新异常。,5.1 关系模式设计的问题,经过上述分析，我们说分解后的关系模式是一个好的关系数据库模式。 从而得出结论，一个好的关系模式应该具备以下四个条件： 1. 尽可能少的数据冗余。 2. 没有插入异常。 3. 没有删除异常。 4. 没有更新异常。,5.1 关系模式设计的问题,但要注意，一个好的关系模式并不是在任何情况下都是最优的， 比如查询某个学生选修课程名及所在系的系主任时，要通过连接，而连接所需要的系统开销非常大，因此要以实际设计的目标出发进行设计 如何按照一定的规范设计关系模式，将结构复杂的关系分解成结构简单的关系，从而把不好的关系数据库模式转变为好的关系数据库模式，这就是关系的规范化。 规范化又可以根据不同的要求而分成若干级别。 我们要设计的关系模式中的各属性是相互依赖、相互制约的，这样才构成了一个结构严谨的整体。 因此在设计关模式时，必须从语义上分析这些依赖关系。 数据库模式的好坏和关系中各属性间的依赖关系有关，因此，我们先讨论属性间的依赖关系，然后再讨论关系规范化理论。,5.2 函数依赖,函数依赖 设R(U)是属性集U上的关系模式，X

7、 , Y U， r是R(U) 上的任意一个关系，如果成立 对t , s r，若tX = sX，则tY = sY 那么称“X函数决定Y”，或“Y函数依赖于X”，记作XY 称X为决定因素 如Sno Sname， （Sno，Cno） Score,5.2 函数依赖,R(A,B,C,D,E):,X,Y,tY,tX,sX,sY,S,t,只要sX = tX 就有 sY = tY: XY,5.2 函数依赖,5.2 函数依赖,学号姓名 学号年龄 学号系别 学号系主任 学号(姓名,年龄) 学号(姓名,系别) 学号(姓名,系主任) 学号(年龄,系别) 学号(年龄,系主任) 学号(系别,系主任) 学号(姓名,年龄,系别) 学号(姓名,年龄,系主任),学号 (姓名,系别,系主任) 学号 (年龄,系别,系主任) 学号 (姓名,年龄,系别,系主任) 系别系主任 (学号,课程号)成绩,5.2 函数依赖,平凡函数依赖 如果X Y，且Y X，则称其为平凡的函数依赖。 如（Sno，Sname） Sname是平凡的函数依赖 非平凡函数依赖 如果Y不是X的子集，则称XY为非平凡的函数依赖。 若不特别声明，我们讨论的都是非平凡的

8、函数依赖。,5.2 函数依赖,有关函数依赖的几点说明： 1函数依赖是语义范畴的概念。 我们只能根据语义来确定一个函数依赖，而不能按照其形式化定义来证明一个函数依赖是否成立。 例如，对于关系模式S，当学生不存在重名的情况下，可以得到： SNAMEAGE SNAMEDEPT 这种函数依赖关系，必须是在没有重名的学生条件下才成立的，否则就不存在函数依赖了。 所以函数依赖反映了一种语义完整性约束。,5.2 函数依赖,2函数依赖与属性之间的联系类型有关。 （1）在一个关系模式中，如果属性X与Y有1:1联系时，则存在函数依赖XY，YX，即X Y。 例如，当学生无重名时，SNO SN。 （2）如果属性X与Y有1:m的联系时，则只存在函数依赖XY。 例如，SNO与AGE，DEPT之间均为1:m联系，所以有SNOAGE，SNODEPT。 （3）如果属性X与Y有m: n的联系时，则X与Y之间不存在任何函数依赖关系。 例如，一个学生可以选修多门课程，一门课程又可以为多个学生选修，所以SNO与CNO之间不存在函数依赖关系。 由于函数依赖与属性之间的联系类型有关，所以在确定属性间的函数依赖关系时，可以从分析属性

9、间的联系类型入手，便可确定属性间的函数依赖。,5.2 函数依赖,3函数依赖关系的存在与时间无关。 因为函数依赖是指关系中的所有元组应该满足的约束条件，而不是指关系中某个或某些元组所满足的约束条件。 当关系中的元组增加、删除或更新后都不能破坏这种函数依赖。 因此，必须根据语义来确定属性之间的函数依赖，而不能单凭某一时刻关系中的实际数据值来判断。 函数依赖关系的存在与时间无关，而只与数据之间的语义规定有关。,5.2 函数依赖,部分函数依赖与完全函数依赖 在R(U)中，如果XY，且对于任意X的真子集X，都有 ， 则称Y对X完全函数依赖，记作 否则称为Y对X部分函数依赖，记作,X Y,X Y,（Sno，Cno） Score,（Sno，Cno） Sname,5.2 函数依赖,传递函数依赖 在R(U)中，如果 则称Z对X传递函数依赖 Sno Dept，Dept Mn,存在传递依赖 sno mn,5.2 函数依赖,由定义可知： 只有当决定因素是组合属性时，讨论部分函数依赖才有意义， 当决定因素是单属性时，只能是完全函数依赖。 例如，在关系模式S（SNO，SN，AGE，DEPT），决定因素为单属性SNO，有SNO (SN，AGE，DEPT），不存在部分函数依赖。,5.2 函数依赖,关系模式S(Sno, Sname, Dept, Mn , Cno , Score) 主码：（Sno，Cno） 函数依赖：,(Sno，Cno） Score Sno Sname，（Sno,Cno） Sname Sno Dept，（Sno，Cno） Dept Dept Mn （Sno，Cno） Mn,传递依赖,定义 范式是对关系的不同数据依赖程度的要求 通过模式分解将一个低级范式转换为若干个高级范式的过程称作规范化（概念的纯粹化）,5.3 范式,范式关系图,现实世界,1NF,定义 关系中每一分量不可再分。即不能以集合、序列等作为属性值,5.3 范式,2NF,关系模式SCD(Sno , Sname , Dept , Mn, Cno , Score) 不良特性

《第四章关系数据库 设计 理论》由会员w****i分享，可在线阅读，更多相关《第四章关系数据库 设计 理论》请在金锄头文库上搜索。