- 1、本文档共72页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
第二章 范式及其对数据库设计的指导意义 范式理论及对实践指导意义概述。 范式:1NF、2NF、3NF、BCNF、4NF、5NF 实例分析及1NF、3NF的认识误区 关系模型下的树结构表达 供应商和系名问题 范式的局限-对冗余的进一步讨论 单表行间冗余 多表间冗余 2.1 范式理论及对实践指导意义概述 1)范式理论形成: 1971年,由1970年首先提出“大型共享数据库数据的关系模型”的关系数据库之父 Edgar Frank Codd相继提出了三级规范化形式1NF-3NF 1974年,E.F.Codd和Boyce共同提出BCNF 1977 Ronald Fagin提出了第四范式 以后又相继提出了5NF(Project-Join Normal Form (PJ/NF)) 、DKFN(Domain/Key Normal Form)和6NF 2)各范式之间关系:1NF?2NF ?3NF ?BCNF ?4NF ?5NF ?DKNF?6NF 3)规范化方法:一个属于低一级的范式的关系模式可以通过模式分解转换成属于高一级范式的关系模式,这个过程称为关系模式的规范化。 4)规范化目的:消除关系中的数据冗余 由于数据冗余引发的问题: 浪费了存储资源,并且重复的数据占用的空间随数据量的递增而递增。 由于数据的重复,为保证数据的一致性,将增加数据维护(插入、更新和删除)的代价,从而降低了系统的开发和运行效率 各种意外还是可能造成重复数据的不一致,从而降低了系统的稳定性和可靠性。 是产生插入,更新和删除异常根源(见下例) 插入,更新和删除异常实例: 假设存在下列关系,包含学生和系的基本信息: 学号 姓名 所在系 系主任 001 zhang 数学 Mr Li 002 wang 数学 Mr Li 003 zhou 数学 Mr Li 004 feng 计算机 Mr chen 005 dong 计算机 Mr chen 该关系存在插入,更新和删除异常。 插入异常:当新成立一个系但还没有学生时,产生插入异常。 删除异常:当一个系的学生被全部删除后,系信息也被删除。 更新异常:当系名称或系主任发生变化,必须同时更新这个系所有学生记录,若漏改一个,就产生更新异常。 5)规范化理论对实践的指导意义 异常分类:关系设计不规范引起插入,更新和删除异常有的可以通过严密的算法避免发生,有的则不能避免。在上例中,插入和删除异常不可避免,而更新异常却可以避免。 不可避免异常:若数据库的设计中存在不可避免的异常时,需求将无法实现,设计者会自觉地消除这些异常。在上例中,一般会增加一个“系(系名,系主任)”关系来排除不可避免的插入和删除异常。这时,规范化设计成为设计师自觉的行动 可避免异常:关系规范化理论对设计者有指导意义的是消除可避免异常引起的数据冗余。 冗余和范式关系: 一般消除了一个关系中的数据冗余(除外键引用为必要的数据冗余外),该关系也就符合了范式要求。 一个关系符合范式要求,一般就不会产生数据冗余,但必须注意的是范式可以消除一个关系中的(单行)数据冗余,但不能消除一个表的行间冗余和多个关系之间的数据冗余。 2.2 范式2.2.1 1NF及对实践的指导意义1)定义 1NF的定义1:若关系中所有属性是不可再分的基本项(原子项),即关系中的属性不能是组合属性,称关系属于或服从第一范式。 1NF的定义2:关系模式R中不能含有任何重复的数据项。(Robert D. Schnneider 规划与建立高性能SQL Server 6.5数据库) 第一范式是关系数据模式必须遵循的规范,其他规范均建立在此基础之上。 关系的一切数学理论均基于关系模式服从1NF。 2)1NF的第一层次的解释 如一个学生的成绩包括数学,语文,外语等,则成绩不能作为学生关系中的一 个属性。 要使其符合1NF,必须把数学,语文,外语成绩直接作为学生关系的属性。 由于关系数据库中表中列之间的关系相互并列,本身不支持层次结构或数组,所以表面上看,只要是二维表,就一定符合1NF 3)1NF的第二层次的解释 不要或没有必要把若干属性或代码组合成一个组合属性或组合代码放在一个数据列中。这同样违反1NF 。 这样做的风险是数据库系统对组合属性中某属性的可操作性(子串)一定不如对列的可操作性。 解决上述问题的方法也不要简单地把组合属性分解成列,当这些属性有扩充的可能时,应单独建立一个关系。(后面有详例分析) 4)1NF的第三层次的解释 1NF要求在一行中不能有重复组,不管是重复的列还是列中含有的重复信息都不允许。(数据库设计) 如不要把数学成绩,语文成绩和外语成绩作为学生关系中的属性,因为,一旦增加一门课程,该关系就必须作修改。 正确的做法是把成绩独立出来,形成的关系模型为:成绩(学号,
文档评论(0)