- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
第四章关系规化范改
第四章 关系规范化
本章讨论关系数据理论。4.1节从数据库逻辑设计中如何构造一个好的数据库模式这一问题出发,阐明了关系规范化理论研究的实际背景。4.2节介绍规范化理论,讨论各种范式及可能存在的插入、删除等毛病,并直观地描述解决办法。
4.1 问题的提出
前面已经讨论了数据库系统的一般概念,介绍了关系数据库的基本概念、关系模型的三个部分以及关系代数。但是还有一个很基本的问题尚未涉及,针对一个具体问题,应该如何构造一个适合于它的数据模式,即应该构造几个关系模式,每个关系由哪些属性组成等。这是数据库设计的问题,确切地讲是关系数据库逻辑设计问题。
实际上设计任何一种数据库应用系统,不论是层次的、网状的还是关系的,都会遇到如何构造合适的数据模式即逻辑结构的问题。由于关系模型有严格的数学理论基础,并且可以向别的数据模型转换,因此,人们就以关系模型为背景来讨论这个问题,形成了数据库逻辑设计的一个有力工具——关系数据库的规范化理论。规范化理论虽然是以关系模型为背景,但是它对于一般的数据库逻辑设计同样具有理论上的意义。
现实世界随着时间在不断地变化,因而在不同的时刻,关系模式的关系也会有所变化。但是,现实世界的许多已有事实限定了关系模式所有可能的关系必须满足一定的完整性约束条件。这些约束或者通过对属性取值范围的限定,或者通过属性值间的相互关连(主要体现于值的相等与否)反映出来。后者称为数据依赖,它是数据模式设计的关键。关系模式应当刻划这些完整性约束条件。一个关系模式应当是一个五元组。
R(U,D,dom,F)
这里 :
关系名R,它是符号化的元组语义;
一组属性U;
属性组U中属性所来自的域D;
属性到域的映射dom;
属性组U上的一组数据依赖F。
由于(3),(4)对模式设计关系不大,因此在本章中把关系模式看作是一个三元组:R(U,F)当且仅当U上的一个关系r满足F时,r称为关系模式R(U,F)的一个关系。
关系,作为一张二维表,对它有一个最起码的要求:每一个分量必须是不可分的数据项,满足了这个条件的关系模式就属于第一范式(1NF)。在模式设计中,假设己知一个模式S中,它仅由单个关系模式组成,问题是要设计一个模式SD,它与S中“等价”,但在某些指定的方面“更好”一些。这里通过一个例子来说明二个“不好”的模式会有些什么毛病,分析它们产生的原因,从中找出设计一个“好”的关系模式的办法。
在举例之前,先非形式地讨论一下数据依赖的概念。
数据依赖是通过一个关系中属性间值的相等与否体现出来的数据间的相互关系。它是现实世界属性问相互联系的抽象,是数据内在的性质,是语义的体现。现在人们已经提出了许多种类型的数据依赖,其中最重要的是函数依赖(Functional Dependency,FD)和多值依赖(Multivalued Dependency,MVD)。
函数依赖极为普遍地存在于现实生活中。比如描述一个学生的关系,可以有学号,姓名,系名等几个属性。由于一个学号只对应一个学生,一个学生只在一个系学习,因而当“学号”值确定之后,姓名和该生所在系的值也就被唯一地确定了。就象自变量x确定之后,相应的函数值f(x)也就唯一地确定一样,称学号函数决定姓名和系名,或者说姓名,系名函数依赖于学号,记为:学号→姓名,学号→系名。
现在要建立一个数据库来描述学生的一些情况,面临的对象有:学生(用学号描述),系(用系名描述),系负责人(用系负责人名描述),课程(用课程名描述)和成绩(成绩)。于是得到一组属性。
U={学号,系名,系负责人名,课程名,成绩}
由现实世界的己知事实得知:
①一个系有若干学生,但一个学生只属于一个系;
②一个系只有一名(正职)负责人;
③一个学生可以选修多门课程,每门课程有若干学生选修;
④每个学生学习每一门课程有一个成绩;
于是得到属性组U上的一组函数依赖:
F={学号→系名,学号→系负责人名,(学号,课程名)→成绩}
这组函数依赖如图4.1所示.
如果只考虑函数依赖这一种数据依赖,就得到了一个描述学校的数据库模式S(U,F),它由一个单一的关系模式构成。这个模式有下述三个“毛病”:
(1)如果一个系刚成立尚无学生,或者虽然有了学生但尚未安排课程。那么就无法把这个系及其负责人的信息存入数据库。称为插入异常。
(2)反过来,如果某个系的学生全部毕业了,在删除该系学生选修课程的同时,把这个系及其负责人的信息也丢掉了,称为删除异常。
(3)冗余太大。比如,每一个系负责人的姓名要与该系每一个学生的每一门功课的成绩出现的次数一样多。这样,也一方面浪费存储,另一方面系统要付出很大的代价来维护数据库的完整性。比如某系负责人更换后,就必须逐一修改有关的每一个元组。
由于上述三个“毛病”,它是一个“不好”的数据库模式。一个“好”的模式应当不会发生插入异常和删除异
文档评论(0)