【数据库系统原理】数据依赖和关系模式规范化.pptVIP

第10章 数据依赖和关系模式规范化 10.1 关系模式设计中的数据语义问题 10.2 函数依赖(FD) 10.3 多值依赖(MVD) 10.4 联接依赖(JD)* 10.5 关系模式的分解及其问题 10.6 关系模式的规范化 10.1 关系模式设计中的数据语义问题 前面我们已经讨论了关系数据库的基本概念、关系模型的三个部分以及关系数据库的标准语言SQL。 但是还有一个很基本的问题尚未涉及，针对一个具体问题，应该如何构造一个适合于它的数据库模式，即应该构造几个关系模式，每个关系由哪些属性组成等。 这是数据库设计的问题，确切地讲是关系数据库逻辑设计问题。 10.1 关系模式设计中的数据语义问题 下面首先回顾一下关系模型的形式化定义。 一个关系模式应当是一个五元组。  R(U, D, DOM, F) 这里： 关系名R，它是符号化的元组语义； 一组属性U； 属性组U中属性所来自的域D； 属性到域的映射DOM； 属性组U上的一组数据依赖F 由于D和DOM对模式设计关系不大,因此我们在本章中把关系模式看作是一个三元组：RU,F 当且仅当U上的一个关系r满足F时，称r为关系模式RU,F的一个关系。 10.1 关系模式设计中的数据语义问题 关系作为一张二维表,我们对它有一个最起键的要求：每一个分量必须是不可分的数据项。满足了这个条件的关系模式就属于第一范式（1NF）。 我们的任务是研究模式设计，研究设计一个“好”的（没有“毛病”的）关系模式的办法。 数据依赖是通过一个关系中属性间值的相等与否体现出来的数据间的相互关系。它是现实世界属性间相互联系的抽象，是数据内在的性质，是语义的体现。 现在人们已经提出了许多种类型的数据依赖，其中最重要的是函数依赖(Functional Dependency简记为FD)和多值依赖(Multivalued Dependency简记为MVD)。 函数依赖极为普遍地存在于现实生活中。 10.1 关系模式设计中的数据语义问题 比如描述一个学生的关系,可以有学号(SNO),姓名(SNAME),系名(SDEPT)等几个属性。 由于一个学号只对应一个学生,一个学生只在一个系学习。因而当“学号”值确定之后,姓名和该生所在系的值也就被唯一地确定了。 就象自变量x确定之后,相应的函数值f(x)也就唯一地确定了一样，我们说SNO函数决定SNAME和SDEPT,或者说SNAME，SDEPT函数依赖于SNO,记为∶ SNO→SNAME,SNO→SDEPT。 10.1 关系模式设计中的数据语义问题 现在我们要建立一个数据库来描述学生的一些倩况。 面临的对象有：学生(用学号SNO描述),系(用系名SDEPT描述),系负责人(用其姓名MN描述),课程(用课程名CNAME描述)和成绩(G)。 现实世界的已知事实告诉我们∶ 一个系有若干学生,但一个学生只属于一个系； 一个系只有一名(正职)负责人； 一个学生可以选修多门课程,每门课程有若干学生选修； 每个学生学习每一门课程有一个成绩； 如果只考虑函数依赖这一种数据依赖,我们就得到了一个描述学校的数据库模式SU，F，它由一个单一的关系模式构成：  U = { SNO，SDEPT，MN，CNAME，G }  F = { SNO→SDEPT，SDEPT→MN，(SNO，CNAME)→G } 10.1 关系模式设计中的数据语义问题 这个模式有下述三个“毛病”： 插入异常：如果一个系刚成立尚无学生,或者虽然有了学生但尚未安排课程。那么我们就无法把这个系及其负责人的信息存入数据库。 删除异常：反过来,如果某个系的学生全部毕业了,我们在删除该系学生选修课程的同时,把这个系及其负责人的信息也丢掉了。 更新异常：比如，某系负责人更换后,就必须逐一修改有关的每一个元组。 数据冗余：比如,每一个系负责人的姓名要与该系每一个学生的每一门功课的成绩出现的次数一样多。 这样,一方面浪费存储,另一方面系统耍付出很大的代价来维护数据库的完整性。 10.1 关系模式设计中的数据语义问题 为什么会发生插入异常和删除异常呢 ? 这是因为这个模式中的函数依赖存在某些不好的性质。 假如我们把这个单一的模式改造一下,分成三个关系模式： SSNO,SDEPT, SNO→SDEPT； SGSNO,CNAME,G, (SNO,CNAME)→G； DEPTSDEPT,MN, SDEPT→MN； 这三个模式都不会发生插入异常、删除异常的毛病,数据的冗佘也得到了控制。 一个模式的函数依赖会有哪些不好的性质,如何改造一个不好的模式,这