数据库范式理论浅析(共2136字).docVIP

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
数据库范式理论浅析(共2136字)

数据库范式理论浅析(共2136字) 本文 一、关系数据库规范化理论 关系规范化理论就是按照统一的标准对关系进行优化,将一个初始的、不太合理的关系模型转化为一个高级的、合理的关系模型。其基本思想是通过合理的分解关系模式来消除其中不合适的数据依赖,以减少冗余数据,提供有效的数据检索方法,避免不合理的插入、删除、修改等数据操作,保持数据的一致性[1]。在关系数据库中,对关系模式的基本要求是满足第一范式,这样的关系模式就是合法的、允许的。但是人们发现有些关系模式存在插入、删除异常、修改复杂、数据冗余等毛病,解决的办法就是对关系进行规范化。规范化的过程就是将一个低一级范式的关系模式,通过模式分解转换为若干个高一级范式的关系模式的集合。从理论上讲,范式越高,规范化的程度就越高,但也不是范式越高就越好,要根据应用场合具体问题具体分析。范式低了,数据冗余严重,范式高了,影响系统速度。对于一般的数据库应用系统,只要将数据表规范到BCNF的标准就可以满足用户需求。 二、第一范式(1NF) 第一范式形式指在一个关系(二维表)中,各属性(字段)均是不可再分的数据项,即是一个规则的二维表。1NF是关系的基本性质,任何关系必须满足第一范式。比如表1表示的关系不满足第一范式,将重复项表头去掉,分解为表2,就满足第一范式。可以看出,表2符合第一范式,但还有很多缺点:(1)数据冗余太大。每当有学生选一门课程时,该学生及学员队信息都会重复出现一次,其实这些信息只出现一次就够了。(2)数据更新麻烦。由于数据重复存储,在更新时可能会造成数据不一致,直接影响了系统的质量。若工程一队队长调换成李季,则所有关于工程一队的记录都要修改,加大了工作量,还有可能发生遗漏,造成数据的不一致。(3)插入异常。表2的主键是学号和课程名称,因为主键字段不允许为空,所以新入学的同学因为还没有选修任何一门课程而无法录入到该表中。(4)删除异常。若工程一队学生毕业,将学生记录删除,则连同工程一队队长的信息一起删除,引起信息丢失。 三、第二范式(2NF) 第二规范化形式是指如果在一个满足1NF的关系中,所有非关键字数据元素都完全依赖于候选关键字,即,如果给定一个关键字,则可以在这个数据表中唯一确定一条记录。分析上面的例子,该关系的关键字为学号和课程名称,(学号,课程名称)一起函数决定任课教师和期末成绩,(学号,课程名称)也函数决定姓名,学员队和队长。但实际上只要学号就能函数决定姓名,学员队和队长。所以说任课教师和期末成绩完全函数依赖于学号和课程名称,姓名,学员队和队长部分函数依赖于学号,课程名称。根据以上分析对表2进行无损分解为表3和表4。我们可以看出,表3和表4所有非关键字都完全依赖于候选关键字,但是表3仍然存在以下问题:数据冗余大。学员队队长的姓名会随学生个数重复若干次;数据更新麻烦。若工程一队更换队长,则必须更改表3中所有工程一队每个学员的纪录,如果有遗漏,还会造成数据不一致;插入异常。若新成立一个队,在没有招生之前就无法输入学员队及队长信息;删除异常。如果张三退学,将张三的记录删除,则连同学员队长的信息一起删除,引起信息丢失。 四、第三范式(3NF) 对于那些满足2NF的关系,所有非关键字都不传递依赖于候选关键字,则称这个关系满足第三规范化形式[2]。从表3可以看出,存在问题的原因就是存在传递依赖:队长通过学员队依赖于学号。消除表中传递依赖的方法,仍然是将表进行无损分解,将传递依赖单独建立一张二维表,得到表5和表6。分析表4,虽然满足第三范式,但仍然存在以下问题:(1)数据冗余大。高丽任数学教师,她的信息会随其所教学生的数目重复若干次。(2)数据更新麻烦。若将计算机课的任课教师李可更换为李政,则所有李可教的学生的记录都要更新,若漏改一处就会造成数据不一致。(3)插入异常。如果新来一个英语老师,会因为没有学生选课而不能插入其信息。(4)删除异常。若删除04号的数学成绩,则连同任课教师的信息一同删除,会造成信息丢失。 五、BCNF范式 若关系模式中,每一个决定因素都包含候选关键字,则称该关系满足BCNF范式。具体来讲就是一个满足BCNF的关系模式有:(1)所有非主属性对每一个候选关键字都是完全函数依赖。(2)所有的主属性对每一个不包含它的候选关键字,也是完全函数依赖。(3)没有任何属性完全函数依赖于非候选关键字的任何一组属性[3]。表4中,任课教师函数决定课程名称,而任课教师是非关键字,不符合第3条,所以还应对表4进行无损分解,得到表7和表8。 六、结论 一个关系模式经过规范化,如果都属于BCNF范式,那么在函数依赖的范畴内,它已实现了彻底的分离,消除了插入和删除异常,能满足一般程序设计的要求

文档评论(0)

zsmfjy + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档