第5讲 需求分析阶段-规范化

上传人:dfg****19 文档编号:245541942 上传时间:2024-10-09 格式:PPT 页数:41 大小:1MB
返回 下载 相关 举报
第5讲 需求分析阶段-规范化_第1页
第1页 / 共41页
第5讲 需求分析阶段-规范化_第2页
第2页 / 共41页
第5讲 需求分析阶段-规范化_第3页
第3页 / 共41页
点击查看更多>>
资源描述
单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,数据库系统设计,需求分析阶段规范化,概述,虽然一个数据模型有效地沟通了数据库需求,但它不一定就代表了一个,好的,数据库设计,其中的某些结构特征可能会降低模型的灵活性和扩展性,或者产生不必要的冗余。所以,我们必须为数据库设计和实现准备好具有完整属性的数据模型。,好的数据模型的标准,好的数据模型是简单的,。,好的数据模型基本上是无冗余的,。,好的数据模型应该是灵活的而且对未来的需求具有可适应性,。,概述,考虑以下的实体定义:,course registration=course registration,number(PK,)+course registration date+student id,number(FK,)+student name+student major+,一个或多个,course number,概述,好的数据模型是简单的,。,作为一条通用规则,描述任何实体的数据属性应该仅仅描述那个实体。,属性,student name,和,student major,真的描述了,course registration,(课程注册)的一个实例吗?,或者它们仅仅描述了一个不同的实体,即,student?,同样的理由可以应用到属性,student id number,上。,经过进一步考察,,student id number,属性仍是需要的,它用来“指出”对应的,student,实体实例。,概述,好的数据模型是简单的。,简单性的另一个方面是这样陈述的:,一个实体实例的每个属性只能有一个值。,再看前的例子:对应一个,course registration,实体,属性,course number,可以多个有值供学生选择。,概述,好的数据模型基本上是无冗余的。,这意味着每个数据属性(除了外键)最多在一个实体中描述,。,在前面的例子中,发现属性,student name,和,student major,实际上描述一个,student,实体并不困难。故合乎逻辑的选择将是添加,student,实体。,在数据模型中还可能存在更细微的冗余,例如,相同的属性可能以不同的名称(同义词)被多次记录。,概述,好的数据模型应该是灵活的而且对未来的需求具有可适应性。,没有这条评价准则,我们往往会设计仅实现目前业务需求的数据库。,然后,当一个新的需求产生时,我们若不重写许多或者所有使用那些数据库的程序就无法方便地修改数据库。,虽然我们不能改变这个现实,-,大多数项目都是应用驱动的,但是我们可以使数据模型做到尽可能地与应用无关,以鼓励采用不影响当前程序扩展或修改的数据库结构。,概述,数据分析,:,是为将数据模型实现成数据库而改进数据模型的技术。,数据分析是为实现简单的、无冗余的、灵活的并可扩展的数据库而准备数据模型的过程。其专门的技术称为规范化。,规范化,:,是一种数据分析技术,该技术组织数据属性怪便它们可以组合起来形成无冗余的、稳定的、灵活的并具有适应性的实体,规范化是一种包括三个步骤的技术,该技术把数据模型规范成,1NF,、,2NF,和,3NF,。,所有的范式都是基于表中的列之间的关系的。,概述,规范化理论是研究如何将一个不好的关系模式转化为好的关系模式的理论,规范化理论是围绕范式而建立的。,规范化理论认为,一个关系数据库中所有的关系,都应满足一定的规范,(,约束条件,),。,规范化理论把关系应满足的规范要求分为几级,满足最低要求的一级叫做第一范式,(1NF),,在第一范式的基础上提出了第二范式,(2NF),,在第二范式的基础上又提出了第三范式,(3NF),,以后又提出了,BCNF,范式,,4NF,,,5NF,。,范式的等级越高,应满足的约束集条件也越严格。规范的每一级别都依赖于它的前一级别,例如若一个关系模式满足,2NF,,则一定满足,1NF,。,数据冗余和更新异常,更新异常,引起数据冗余的,错误的结构化表,的问题叫做,更新异常,错误的结构化表可能产生于最初的,ER,模型或在将,ER,模型转化成表时出现错误。,有冗余数据的表可能有的问题叫做更新异常,它分为,插入,、,删除,和,更改,异常,数据冗余和更新异常,数据应该尽可能少地冗余,这意味着重复数据应该减少到最少,比如,一个部门雇员的电话就不应该被存储在不同的表中,因为这里的电话号码是雇员的一个属性。,如果存在过多的冗余数据,这就意味着要占用了更多的物理空间,同时也对数据的维护和一致性检查带来了问题,当这个员工的电话号码变化时,冗余数据会导致对多个表的更新动作,如果有一个表不幸被忽略了,那么就可能导致数据的不一致性。,关系数据库设计的主要目的是把列分组成表,以便最小化数据冗余并减少基表所需的文件存储空间,数据冗余和更新异常,StaffBranch,表,冗余数据,因为分公司的细节信息在分公司的每个员工那里被重复了一遍,PK,数据冗余和更新异常,为说明与数据冗余有关的问题,我们来进行个比较:,只有分公司编号被重复,每个分公司的详细信息只出现一次,更新异常插入异常,有两种主要的插入异常,潜在的不一致性,。为了插入一新员工到,StaffBranch,表中,必须包括分公司的详细信息,这个信息决定新员工所属的分公司。而在输入时无法保证输入的信息不出错。,StaffBranch,表,StaffBranch,表,如,要插入在,B003,分公司工作的新员工,必须输入,B003,分公司的正确的细节情况使得与,StaffBranch,表中其他分公司的记录信息一致。,更新异常插入异常,避免不一致性问题出现,此时就不存在潜在的不一致性,因为对于每一个员工我们仅需加入正确的分公司号到,Staff,表中就可以了。,另外,,B003,分公司在,Branch,表中作为单独的记录在数据库中仅记录一次。,更新异常插入异常,有两种主要的插入异常,违反实体完整性,。如果要在,StaffBranch,表中插入一个新的,目前还没有员工的分公司的详细信息,需要在与员工有关的列,如,staffNo,,输入空值,但由于,StaffNo,在,StaffBranch,表中是主键,输入,null,给,StaffNo,就违反了实体完整性,因此,不允许为空。这就违反了实体完整性。,StaffBranch,表,StaffBranch,表,更新异常插入异常,避免违反实体完整性问题出现,Staff,表和,Branch,表的设计就避免了这个问题的出现,因为在,Branch,表中插入分公司情况与员工内容是分开的,在有了分公司之后,就可以在以后插入员工到,Staff,表中。,更新异常删除异常,如果从,StaffBranch,表中删除一个记录,而它又是一个分公司的最后一名员工(或唯一的一名),那么关于该分公司的有关信息也被从数据库中删除了。,StaffBranch,表,例如,如果我们从,StaffBranch,表中删除员工,S0415,的记录,那么与,B003,分公司相关的情况也从数据库丢失了。,更新异常删除异常,避免出现删除异常,Staff,表和,Branch,表的设计就避免了这个问题的出现,因为在,Branch,表中插入的分公司情况与员工内容是分开的,仅仅是用,BranchNo,列把两个表关联起来。,如果从,Staff,表中删除员工,S0415,的记录,那么,B003,分公司的情况在,Branch,表中依旧存在,不受影响,更新异常更新异常,如果想要改变表中一个特定分公司的一个列的值,如分公司,B001,的电话号码,就必须更改在那个分公司的所有员工的记录。如果此次更改没有在该表中的所有记录正确进行,那么数据库就变得不一致了。,StaffBranch,表,从而会出现分公司的不同员工有不同的电话号码的问题。,更新异常删除异常,避免出现更新异常,Staff,表和,Branch,表的设计就避免了这个问题的出现,因为此时只需要更新,Branch,表中分公司的电话号码就可以了。,第一范式(,1NF,),First Normal Form,,,1NF,对于关系数据库来说,只有第一范式(,1NF,)在创建适当的表中是关键的。所有接下来的范式都是可选的。,实体的所有属性对于实体的单个实例都只具有一个值。,每个列和记录包含一个且仅含一个值的表,实体的所有属性对于实体的单个实例(记录)都只具有一个值。,任何可以有多个值的属性实际上描述了一个独立的实体,也可能是一个实体和关系,第一范式(,1NF,),Branch,表不是,1NF,的一个例子:,Branch,表的主键为,BranchNo,。可以看到,BranchNo,表中除了,TelNo,列之外,其他的列都遵守,1NF,的定义,因为对于每一个记录的,TelNo,列有多个值。,如,分公司号为,B001,的分公司有三个电话电码,因此,Branch,表不属于,1NF,。,第一范式(,1NF,),将,Branch,表转换为,1NF,:,为了把,Branch,表转换成,1NF,,我们创建一个单独的表,叫做,BranchTelephone,,此表用来保存分公司的电话电码。此表是把,TelNo,列从,Branch,表中去掉,同时把,Branch,表的主键复制到新表中。新表,BranchTelephone,的主键是,TelNo,。从而得到两个,1NF,的表,因为符合每一个表的每一个记录的每一列都有单独的值这一标准,第二范式(,2NF,),Second Normal Form,2NF,2NF,只应用于具有复合主键的表,具有单列主键的表自动成为,2NF,不属于,2NF,的表可能会有更新异常问题,一个,1NF,的表,在该表中的每个非主键列的值都可以由,组成主键的全部的列,的确定,实体的所有非主键属性的值都依赖于主键,任何仅仅部分依赖主键的非主键属性应该被移到另一个实体中。这可能需要在模型中创建一个新实体和关系。,第二范式(,2NF,),TempStaffAllocation,表不是,2NF,将,TempStaffAllocation,表,转换为,2NF,第三范式(,3NF,),Third Normal Form,3NF,一个已经是第一和第二范式的表,并且所有的非主键的值都只可以从主键列得到,而不能从其它的列得到。,实体已经是,2NF,实体的非主键属性的值不依赖于任何其它非主键属性,任何依赖于其它非主键属性的非主键属性必须去掉或删除,新的实体和关系可能要被加到新的数据模型中,StaffBranch,表不是,3NF,将,StaffBranch,表转换成,3NF,NF,、,NF,和,NF,总结,如果每个非主键属性都依赖于主键(整个主键),而且除了主键以外再不依赖于任何属性,这个实体就被称为是第三范式的。,规范化步骤,第零范式,一个实体的单个实例的属性是否拥有多个值?,是:移除重复属性和重复组,建立一个实体描述这些属性。通常你需要添加关系去连接新旧实体。,否:数据模型包含在第范式中。,第一范式,专门订单文档模型,仔细检查专门订单文档,会注意到两种情况,在这两种情况中,单个专门订单实例中同样的属性捕获多个值。第一种违反是客户书的爱好,就是那种客户喜欢看的书。属性的复数形式让我们以为每个订单的实例包含了很多种不同爱好,就时爱好就是重复属性。需要建立一个新的包含更多爱好信息的实体去解决这个问题,还要在专门订单和爱好之间添加一个关系。此外,专门订单文档捕获了单个专门订单中多本书的信息这也违反了,1NF,,这时,每当下一次订单,关于书本的一组信息就会被重复记录。这被叫做组重复,它可以通过创建一个叫书的实体并把所有关于该书的属性放入其中来解决问题。,第一范式,规范化步骤,第一范式,主键是不是由多于一个属性组成?如果是的话,其中是否有属性值依赖部分主键?,是:移除依赖部分,把属性移到一个其属性依赖整个主键的实体中。通常需要创建一个新实体并添加关系去连接新旧实体,否:数据模型包含在第范式中。,第二范式,第二范式要求模型首先是第一范式,还要求数据模型的实体包含依赖于整个主键的属性。这意味着所有作为
展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 商业管理 > 营销创新


copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!