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