《数据库原理与应用 教学课件 ppt 作者 肖锋 王建国 第3章 关系数据库设计理论》由会员分享，可在线阅读，更多相关《数据库原理与应用 教学课件 ppt 作者 肖锋 王建国 第3章 关系数据库设计理论（51页珍藏版）》请在金锄头文库上搜索。
1、第3章 关系数据库设计理论 本 章 要 点 1.关系数据库的逻辑设计主要是设计关系模式，而深入理解函数依赖和键码的概念是设计和分解关系模式的基础。初步掌握计算属性的封闭集。 2.关系模式的规范化、模式设计是本章的重点。了解数据冗余和更新异常产生的根源；理解关系模式规范化的方法；准确理解第一范式，第二范式、第三范式和BC范式的含义、联系与区别。 3.熟练掌握模式分解的方法，能正确而熟练地将一个关系模式分解成属于第三范式或BC范式的模式。,3.1 问题的提出 在设计关系数据库模式时，特别是从E/R设计直接向关系数据库模式转换时，很容易出现的问题是冗余性，即一个事实在多个元组中重复。而且，我们发现造
2、成这种冗余性的最常见的原因是，企图把一个对象的单值和多值特性包含在一个关系中。在下面的例子当中，我们把学生的单值信息（如所在的系）和多值特性（如课程集）存储在一起的时候，就导致了信息冗余。 例如：要求设计学生数据库，其关系模式SCD如下： SCD(SNO, SN, AGE, DEPT, MN, CNO, SCORE) 其中，SNO表示学生学号，SN表示学生姓名，,AGE表示学生年龄，DEPT表示学生所在的系别，MN表示系主任姓名，CNO表示课程号，SCORE表示课程成绩。 根据实际情况，这些数据有如下语义规定： 一个系有若干个学生，但一个学生只属于一个系； 一个系只有一名系主任，但一个系主任可
3、以同时兼几个系的系主任； 一个学生可以选修多门功课，每门课程可有若干学生选修； 每个学生学习课程有一个成绩。 在此关系模式中填入一部分具体的数据，则可得到SCD关系模式的实例，如表3.1所示。,表3.1 学生关系,根据上述的语义规定，并分析以上关系中的数据，我们可以看出：（SNO , CNO）属性的组合能唯一标识一个元组，所以（SNO , CNO）是该关系模式的主关系键。但在进行数据库的操作时，会出现以下几方面的问题。 数据冗余 每个系名和系主任的名字存储的次数等于该系的学生人数乘以每个学生选修的课程门数，同时学生的姓名、年龄也都要重复存储多次，数据的冗余度很大，浪费了存储空间。 插入异常 如
4、果某个新系没有招生，尚无学生时，则系名和系主任的信息无法插入到数据库中。,因为在这个关系模式中，（SNO , CNO）是主关系键。根据关系的实体完整性约束，主关系键的值不能为空，而这时没有学生，SNO和CNO均无值，因此不能进行插入操作。 另外，当某个学生尚未选课，即CNO未知，实体完整性约束还规定，主关系键的值不能部分为空，同样不能进行插入操作。 删除异常 某系学生全部毕业而没有招生时，删除全部学生的记录则系名、系主任也随之删除，而这个系依然存在，在数据库中却无法找到该系的信息。 另外，如果某个学生不再选修C1课程，本应该只删去C1，但C1是主关系键的一部分。为保证实,体完整性，必须将整个元
5、组一起删掉，这样，有关该学生的其它信息也随之丢失。 更新异常 如果学生改名，则该学生的所有记录都要逐一修改SN。 又如某系更换系主任，则属于该系的学生记录都要修改MN的内容，稍有不慎，就有可能漏改某些记录，这就会造成数据的不一致性，破坏了数据的完整性。 由于存在以上问题，我们说，SCD是一个不好的关系模式。产生上述问题的原因，直观地说，是因为关系中“包罗万象”，内容太杂了，包含的内容太多了。,那么，怎样才能得到一个好的关系模式呢？ 我们把关系模，SCD分解为下面三个结构简单的关系模式，如表所示。 学生关系S（SNO ，SN ，AGE ，DEPT） 选课关系SC（SNO ，CNO ，SCORE）
6、 系关系D（DEPT ，MN） 在以上三个关系模式中，实现了信息的某种程度的分离。 S中存储学生基本信息，与所选课程及系主任无关； D中存储系的有关信息，与学生无关； SC中存储学生选课的信息，而与所学生及系的有关信息无关。,表3.2 学生关系S 表3.3 选课关系SC,表3.4系关系D,与SCD相比，分解为三个关系模式后，数据的冗余度明显降低。 当新插入一个系时，只要在关系D中添加一条记录。 当某个学生尚未选课，只要在关系S中添加一条学生记录，而与选课关系无关，这就避免了插入异常。 当一个系的学生全部毕业时，只需在S中删除该系的全部学生记录，而关系D中有关该系的信息仍然保留，从而不会引起删除
7、异常。 同时，由于数据冗余度的降低，数据没有重复存储，也不会引起更新异常。 经过上述分析，我们说分解后的关系模式是一,个好的关系数据库模式。 从而得出结论，一个好的关系模式应该具备以下四个条件： 尽可能少的数据冗余。 没有插入异常。 没有删除异常。 没有更新异常。,3.2函数依赖 函数依赖（Functional Dependency, 简记为FD）是数据依赖的一种，它反映属性或属性组之间相互依存、互相制约的关系。由于关系模式中属性是实体特性的抽象或实体间联系的抽象，所以属性之间的相互关系反映了现实世界的某些约束，它们对数据库模式设计的影响很大。 3.2.1 函数依赖的定义 设有关系模式R(U)
8、，X和Y是属性集U的子集，函数依赖（FD）是形为XY的一个命题，只要r是R的当前关系，对r中任意两个元组t和s，都有tX=sX蕴涵tY= sY，那么称FD XY在关系模式R (U)中成立。,也可以这样定义：如果R的两个元组在属性A1 , A2 , ,An上一致，则它们在另一个属性B上也一致，那么A1 , A2 , ,An函数决定B，记作A1,A2,AnB, 也可以说：A1,A2,An函数决定B。其中A1,A2,An称为决定因素。 如果一组属性A1,A2,An函数决定多个属性，比如说： A1 , A2, , An B1 A1 , A2, , An B2 A1 , A2, , An Bm 则可以把
9、这一组依赖关系简记为： A1 , A2,An B1 B2 . Bm,函数依赖是指关系中的所有元组应该满足的约束条件，而不是指关系中某个或某些元组所满足的约束条件。当关系中的元组增加、删除或更新后都不能破坏这种函数依赖。因此，必须根据语义来确定属性之间的函数依赖，而不能单凭某一时刻关系中的实际数据值来判断。 函数依赖关系的存在与时间无关，是最重要的数据依赖。而只与数据之间的语义规定有关，关系模式中属性之间的一种逻辑依赖关系。 3.2.2 函数依赖规则 假设已知某关系所满足的某些函数依赖，在不知道该关系的具体元组的情况下，通常可以推断出该关系必然满足的某些函数依赖。,下面介绍三个函数依赖规则。 1
10、.分解/合并规则 我们可以把每个函数依赖右边的属性分解，从而使其右边只出现一个属性。同样，我们也可以把左边相同的依赖的聚集用一个依赖来表示，该依赖的左边没变，而右边则为所有属性组成的一个属性集。两种情况下：新的依赖集都等价于旧的依赖集。 分解规则 我们可以把一个函数依赖A1,A2,An B1 B2 Bm用一组函数依赖A1,A2,An Bi（i = 1, 2, m ）来代替。这种转换为“分解规则”（Splitting Rule）。, 合并规则 我们可以把一组函数依赖A1,A2,An Bi（i = 1, 2, m ）用一个函数依赖A1,A2,An B1 B2 Bm来代替。这种转换为“合并规则”（C
11、ombining Rule）。 2.平凡依赖规则 对于A1,A2,An B1 B2 . Bm , 如果B是A中的子集，则该函数依赖就是平凡的函数依赖。 如果B中至少有一个属性不在A中，则该函数依赖就是非平凡的函数依赖。 如果B中没有一个属性在A中，则该函数依赖就是完全非平凡的函数依赖。,如果函数依赖的右边的属性中有一些也出现在左边，那么我们就可以将右边的这些属性删除。也就是说： 函数依赖A1,A2,An B1 B2 . Bm等价于A1,A2,AnC1 C2 . Ck，其中C是B的子集，但不在A中。我们称这个规则为“平凡依赖规则”（Trivial Dependency Rule）。 3.传递规则
12、 传递规则使我们能把两个函数依赖级联成一个新的函数依赖。 如果A1 A2 An B1 B2 Bm和B1 B2 Bm C1 C2 Ck，在关系R中成立，则 A1,A2,An C1 C2 Ck在R中也成立。这个,规则就称为“传递规则”（Transitive Rule）。 3.2.3关系的键码 我们已经了解了键码的概念，下面从函数依赖的角度给出严格的定义。 如果一个或多个属性的集合 A1,A2,An 满足如下条件，则称该集合为关系R的键码（Key）： 这些属性函数决定该关系的所有其他属性。也就是说：R中不可能有两个不同的元组，它们在A1,A2,An上的取值完全相同。 A1,A2,An 的任何真子集都
13、不能函数决定R的所有其他属性。也就是说：键码必须是最小的。 一个关系可有多个键码。,3.2.4 超键码 包含键码的属性集称为超键码，是属性的“超集”的简称。因此，每个键码都是超键码。但是，某些超键码不是键码。 注意：每个超键码都满足第一个条件，它函数决定它所在的关系的其它属性。但是超键码不必满足键码的第二个条件：即最小化条件。例如：在上面的关系中，有许多超键码，不仅（S#，C#）本身是超键码，而且该属性集的任何超集。 3.2.5 函数依赖与属性之间的联系 在关系模式中，其中的函数依赖关系与属性之间的联系有一定的关系。 在一个关系模式中，如果属性X与Y有1:1联系,时，则存在函数依赖XY，YX。
14、 如果属性X与Y有1 : m的联系时，则只存在函数依赖X Y。 如果属性X与Y有m : n的联系时，则X与Y之间不存在任何函数依赖关系。 3.2.6 属性的封闭集 假设 A1,A2,An 是属性集，记为A，S是函数依赖集。属性集A在依赖集S下的封闭集(Closure)是这样的属性集X，它使得满足依赖集S中的所有依赖的每个关系也都满足A X。也就是说，A1,A2,An X是蕴含于S中的函数依赖。我们用 A1,A2,An +来表示属性集A1,A2,An的封闭集。为了简化封闭集的计算，我们允许出现平凡,依赖，所以A1,A2,An总在 A1,A2,An +中。 封闭集的实际含义：对于给定的函数依赖集S
15、，属性集A函数决定的属性的结合就是属性集A在依赖集S下的封闭集。 根据计算出来的封闭集，就能检验给定的任一函数依赖A1,A2,An B是否蕴含于依赖集S。 首先利用依赖集S计算A1,A2,An 。如果B在A1,A2,An 中，则A1,A2,An B蕴含于S；反之，如果B不在A1,A2,An 中，则该依赖并不蕴含于S。 学会计算某属性集的封闭集，还可以根据给定的函数依赖集推导蕴含于该依赖集的其它函数依赖。,键码属性的封闭集必然是属性全集。于是，反过来看，若某属性集的封闭集为属性全集，则该属性集即为键码。当然，判断时，应该从最小属性开始，以区别键码和超键码。 需要说明的是，封闭集在有的书上称为“闭
16、包”。,3.3关系模式的规范化 关系数据库设计理论主要用于指导数据库的逻辑设计，确定关系模式的划分，每个关系模式所包含的属性，从而使得由一组关系模型组成的关系模式作为一个整体，既能客观地描述各种实体，又能准确地反映实体间的联系，还能如实地体现出实体内部属性之间的相互依存与制约。 关系的键码函数决定该关系的所有其他属性，由于键码能唯一地确定一个元组，所以，也可以说关系的键码函数决定该关系的所有属性。换句话说，一个关系的所有属性都函数依赖于该关系的键码。然而，当我们进一步分析时，就会发现不同的属性在关系模式中所处的地位和扮演的角,色是不同的。为了能较好的说明问题，我们把键码所在的属性称为主属性，而
