第5章 数据库设计3

上传人:gu****n 文档编号:243147529 上传时间:2024-09-16 格式:PPT 页数:39 大小:358KB
返回 下载 相关 举报
第5章 数据库设计3_第1页
第1页 / 共39页
第5章 数据库设计3_第2页
第2页 / 共39页
第5章 数据库设计3_第3页
第3页 / 共39页
点击查看更多>>
资源描述
,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,数据库技术及应用,*,习题答案,P141 2,(,1,),R,的码是,(,Sno,Cno,),R,是,1NF,,因为,Teacher,和,Title,属性部分函数依赖于码,(,Sno,Cno,),,所以,R1NF,(,2,),SC,(,Sno,Cno,Grade,),CT,(,Cno,teacher,),TT,(,Teacher,title,),9/16/2024,1,上一次课程回顾,关系模式规范化的基本步骤,1NF,(,每个分量必须是不可分的项,),消除决定属性,2NF,(,每个非主属性完全函数依赖于码,),集非码的非平,凡函数依赖,3NF,(,每个非主属性既不部分也不传递函数依赖于码),BCNF,(,每个决定因素都包含码),消除非平凡且非函数依赖的多值依赖,4NF,消除,非主属性,对码的,部分函数依赖,消除,非主属性,对码的,传递函数依赖,消除,主属性,对码的部分和传递函数依赖,9/16/2024,2,规范化的基本思想,消除不合适的数据依赖,使模式中的各关系模式达到某种程度的“分离”,采用“一事一地”的模式设计原则,让一个关系描述一个概念、一个实体或者实体间的一种联系。若多于一个概念就把它“分离”出去,所谓规范化实质上是概念的单一化,9/16/2024,3,规范化(续),不能说,规范化程度越高的关系模式就越好,在设计数据库模式结构时,必须对现实世界的实际情况和用户应用需求作进一步分析,确定一个,合适的、能够反映现实世界的模式,上面的规范化步骤可以在其中任何一步终止,9/16/2024,4,5.4,概念结构设计,5.4.1,概念结构设计的任务,5.4.2,概念结构设计的方法与步骤,5.4.3,局部,E,R,模型设计过程,5.4.4,全局概念结构设计,9/16/2024,5,5.4.1,概念结构设计的任务,将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是,概念结构设计,概念结构是各种数据模型的共同基础,,它比数据模型更独立于机器、更抽象,从而更加稳定。,概念结构设计是整个,数据库设计的关键,任务,:,将需求分析的结果进行概念化抽象,获得系统的,E-R,图。,描述概念模型的,工具:,E-R,模型,9/16/2024,6,5.4.2,概念结构设计的方法与步骤,设计概念结构的四类方法,自顶向下,自底向上,逐步扩张,混合策略,首先定义最重要的核心概念结构,然后向外扩充,以滚雪球的方式逐步生成其他概念结构,直至总体概念结构,将自顶向下和自底向上相结合,用自顶向下策略设计一个全局概念结构的框架,以它为骨架集成由自底向上策略中设计的各局部概念结构。,首先定义全局概念结构的框架,然后逐步细化,首先定义各局部应用的概念结构,然后将它们集成起来,得到全局概念结构,9/16/2024,7,概念结构设计的方法与步骤(续,),自顶向下策略,需求,全局概念模式,概念模式,概念模式,概念模式,概念模式,概念模式,概念模式,9/16/2024,8,概念结构设计的方法与步骤(续),子需求,子需求,子需求,子需求,概念模式,概念模式,概念模式,概念模式,概念模式,概念模式,全局概念模式,自底向上策略,9/16/2024,9,概念结构设计的方法与步骤(续),核心需求,核心概念结构,概念结构,需求,全局概念结构,逐步扩张,9/16/2024,10,5.4.3,局部,E,R,模型设计过程,步骤:,1,、,确定各局部,ER,模型描述的范围,通常采用的方法是将总的功能划分为几个子系统,每个子系统又划分几个子系统。,2,、逐一设计分,E-R,图,设计分,E-R,图主要完成以下工作:确定实体(集)、确定实体(集)的属性、确定实体间的联系。,9/16/2024,11,一般原则,即属性必须是不可分的数据项,不能再由另一些属性组成。,属性不能与其他实体具有联系。联系只发生在实体之间。,符合上述两条特性的事物一般作为属性对待。,现实世界中事物能做属性对待的,尽量作属性对待。,如何区分实体和属性,例,2,:职称通常作为教师实体的属性,但在涉及住房分配时,由于分房与职称有关,也就是说职称与住房实体之间有联系,根据准则,这时把职称作为实体来处理会更合适些。,例,1,:“学生”由学号、姓名等属性进一步描述,根据准则,“学生”只能作为实体,不能作为属性。,9/16/2024,12,5.4.4,全局概念结构设计,任务:,将所有得分,E-R,图综合成一个系统的总,E-R,图。,方式,:,一次集成多个分,E-R,图,通常用于局部视图比较简单时,逐步集成式,首先集成两个局部视图(通常是比较关键的两个局部视图),以后每次将一个新的局部视图集成进来,(E-R)1,(E-R)2,(E-R)n,初步,E-R,基本,E-R,一次集成,(E-R)1,(E-R)2,(E-R)12,(E-R)3,初步,E-R,基本,E-R,逐步集成,无论采用哪种集成法,每一次集成都分为两个阶段:,合并分,E-R,图,生成初步,E-R,图、消除冗余,。,9/16/2024,13,各分图存在冲突,冲突,:,各分,E-R,图之间存在的不一致的地方。,属性冲突,(属性域冲突、属性取值单位冲突),命名冲突,(同名异义、异名同义),结构冲突,同一对象在不同应用中具有不同的抽象,同一实体在不同局部视图中所包含的属性个数和排列次序不完全相同,实体之间的联系在不同局部视图中呈现不同的类型,合并分,E-R,图的主要工作与,关键,所在:,合理消除各分,E-R,图的冲突,一、合并,分,E-R,图,生成初步,E-R,图,通常用讨论、协商等行政手段加以解决,解决方法:通常是把属性变换为实体或把实体变换为属性,使同一对象具有相同的抽象。变换时要遵循两个准则,。,解决方法:使该实体的属性取各分,E-R,图中属性的并集,再适当设计属性的次序。,解决方法:根据应用语义对实体联系的类型进行综合或调整。,9/16/2024,14,消除结构冲突实例,:,1,、异名同义,职工号,姓名,性别,职称,教师,是否为优,秀班主任,职工号,姓名,性别,班主任,职工号,姓名,性别,职称,是否为优,秀班主任,教师,9/16/2024,15,2,、,同一对象在不同应用中具有不同的抽象,例:职称在不同的应用中可以作为职工的属性,也可以作为一个实体。,通常当对职称没有进一步的描述时,根据准则,1,作为职工实体的属性;,但在涉及住房分配时,由于分房与职称有关,也就是说职称与住房实体之间有联系,根据准则,这时把职称作为实体来处理会更合适些。,9/16/2024,16,3,、,同一实体在不同局部视图中所包含的属性个数和排列次序不完全相同,学生,学号,姓名,性别,平均成绩,(a),在局部应用,A,中,学生,学号,姓名,出生日期,年级,(b),在局部应用,B,中,所在系,学生,学号,姓名,政治面貌,(c),在局部应用,C,中,学号,学生,政治面貌,出生日期,年级,(d),合并后,所在系,平均成绩,姓名,性别,9/16/2024,17,4,、,实体之间的联系在不同局部视图中呈现不同的类型,产品,构成,零件,(E-R)1,n,m,产品,零件,供应商,n,m,p,供应,(E-R)2,(E-R)12,产品,构成,零件,数量,1,n,m,供应商,p,供应,n,m,数量,2,数量,数量,9/16/2024,18,二、修改与重,构,基本任务,消除不必要的冗余,设计生成基本,E-R,图,合并,初步,E-R,图,分,E-R,图,可能存在冗余的数据,和冗余的实体间联系,基本,E-R,图,消除不必要的冗余,9/16/2024,19,1,冗,余,冗余的数据,是指可由基本数据导出的数据;,冗余的联系,是指可由其他联系导出的联系。,并不是所有的冗余数据与冗余联系都必须加以消除,,有时为了提高某些应用的效率,不得不以冗余信息作为代价。,设计数据库概念结构时,哪些冗余信息必须消除,哪些冗余信息允许存在,需要根据用户的整体需求来确定。,消除不必要的冗余后的初步,E-R,图称为,基本,E-R,图,。,例:若物资部门经常查询各种材料的库存量,如果每次都查询每个仓库中此种材料的库存,再对他们求和,效率太低。所以应该保留“库存总量”的属性。,9/16/2024,20,2,消除冗余的方法,分析方法,以数据字典和数据流图为依据,根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。,如果是为了提高效率,人为地保留了一些冗余数据,则应把数据字典中数据关联的说明作为完整性约束条件。,使用规范化理论,(不要求),函数依赖的概念提供了消除冗余联系的形式化工具,9/16/2024,21,分析法消除冗余实例:,(,1,),例,教师工资单中包括该教师的基本工资、各种补贴、应扣除的房租水电费以及实发工资。于实发工资可以由前面各项推算出来,因此可以去掉,在需要查询实发工资时根据基本工资、各种补贴、应扣除的房租水电费数据临时生成。,(2),教室实体与班级实体的上课联系可以由教室与课程之间的开设联系、课程与学生之间的选修联系、学生与班级之间的组成联系三者推导出来,因此属于冗余联系,可以消去。,9/16/2024,22,(3),学生实体中的年龄属性可以由出生日期推算出来,属于冗余数据,应该去掉。这样不仅可以节省存储空间,而且当某个学生的出生日期有误,进行修改后,无须相应修改年龄,减少了产生数据不一致的机会。,学生:,学号,,姓名,出生日期,,年龄,,,所在系,年级,平均成绩,9/16/2024,23,概念结构设计小结:,返回用户征求意见直到满意为止,数据抽象、局部,视图的设计,视图集成,需求分析,概念结构设计,逻辑结构设计,DFD,DD,分,E-R,图,总,E-R,图,概念结构设计步骤,消除冲突,消除不必要的冗余,9/16/2024,24,概念结构设计阶段,任务:,方法:,局部,E-R,图设计步骤:,将需求分析的结果进行概念化抽象。,自顶向下、自底向上、逐步扩张、混合策略。,确定各局部,ER,模型描述的范围、逐一设计分,E-R,图。,确定属性的基本原则:,集成全局,E-R,图的方法,9/16/2024,25,5.5,逻辑结构设计,5.5.1,逻辑结构设计的任务,5.5.2 E-R,图像关系模型的转换,5.5.3,数据模型的优化,9/16/2024,26,5.5.1,逻辑结构设计的任务,任务:,把概念结构设计阶段设计好的基本,E-R,图转换为与选用,DBMS,产品所支持的数据模型相符合的逻辑结构。,关系、网状、层次,三种数据模型:,本章只讨论,关系数据模型,逻辑结构设计阶段的步骤:,E-R,图向关系模型的转换,用关系数据理论对关系模式的规范化,关系模式的优化,9/16/2024,27,5.5.2 E-R,图像关系模型的转换,转换过程中的主要问题:,E-R,图:,实体,实体的属性,实体间的联系,关系模式:,关系,属性,码,9/16/2024,28, 一个,实体型,转换为一个关系模式。,关系的属性,:实体型的属性,关系的码,:实体型的码,2.,一个,m:n,联系,转换为一个关系模式。,关系的属性,:与该联系相连的各实体的码以及联系本身的属性,关系的码,:各实体码的组合,转换原则,:,学生,学号,姓名,出生日期,所在系,年级,平均成绩,学生(,学号,,姓名,出生日期,所在系,年级,平均成绩),例:,选修(,学号,课程号,,成绩),学生(,学号,,系别),课程(,课程号,,课程名),例:,学生,选修,课程,成绩,课程号,学号,系别,课程名,n,m,9/16/2024,29,2),与,n,端对应的关系模式合并,合并后关系的属性,:在,n,端关系中加入,1,端关系的码和联系本身的属性,合并后关系的码,:不变, 一个,1:n,联系,可以转换为一个独立的关系模式,也可以与,n,端对应的关系模式合并。,1),转换为一个独立的关系模式,关系的属性,:与该联系相连的各实体的码以及联系本身的属性,关系的码,:,n,端实体的码,聘用(,工号,,系号,聘期),系(,系号,,系名,电话),教师(,工号,,姓名,性别,年龄),系,教师,聘用,系号,电话,姓名,年龄,工号,性别,1,n,聘期,系名,例:,系(,系号,,系名,电话),教师(,工号,,姓名,性别,,年龄,系号,聘期),系,教师,聘用,系号,电话,姓名,年龄,工号,性别,1,n,聘期,系名,例:,可以减少系统中的关系个数,一般情况下更倾向于采用这种方法,9/16/2024,30,2),与某一端对应的关系模式合并,合并后关系的属性,:加入对应关系的码和联系本身的属性,合并后关系的码,:不变,一个,1:1,联系,可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。,1),转换为一个独立的关系模式,关系的属性,:与该联系相连的各实体的码以及联系本身的属性,关系的候选码,:每个实体的码均是该关系的候选码,任职(,校名,,,姓名,,任职年月),校长(,姓名,,性别,年龄,职称),学校(,校名,,地址,电话,姓名),学校,校长,任职,校名,电话,性别,职称,姓名,年龄,1,1,任职年月,地址,例:,学校(,校名,,地址,电话,姓名,,任职年月),校长(,姓名,,性别,年龄,职称),学校,校长,任职,校名,电话,性别,职称,姓名,年龄,1,1,任职年月,地址,例:,学校(,校名,,地址,电话,姓名),校长(,姓名,,性别,年龄,职称,,任职年月),9/16/2024,31,三个或三个以上实体间,的一个多元联系转换为一个关系模式。,关系的属性,:与该多元联系相连的各实体的码以及联系本身的属性,关系的码,:各实体码的组合,课程,教师,教材,讲授,课程号,职工号,书号,课时,n,1,m,讲授(,课程号,,,职工号,,,书号,,,课时),9/16/2024,32,教师,领导,1,n,职工号,姓名,性别,职称,教师(,职工号,,姓名,性别,,职称,,系主任,),同一实体集的实体间的联系,即,自联系,,也可按上述,1:1,、,1:n,和,m:n,三种情况分别处理。,9/16/2024,33,5.5.3,数据模型的优化,关系数据模型的优化通常以,规范化理论,为指导,。,优化数据模型的常用方法,(,1,)合并,(,2,)分解(水平分解和垂直分解),9/16/2024,34,5.6,数据库的物理设计,数据库在物理设备上的存储结构与存取方法称为,数据库的物理结构,为一个给定的逻辑数据模型选取一个最适合应用环境的物理结构的过程,就是,数据库的物理设计,。,数据库物理设计的,步骤,确定数据库的物理结构,对物理结构进行评价,评价的重点是时间和空间效率,9/16/2024,35,设计数据库物理存储结构的内容:,(,1,),确定数据的存储结构,(,2,),设计合适的存取路径,(,索引方法、聚簇方法、,HASH,方法,),(,3,),确定数据的存放位置,(,4,),确定系统配置,(,同时使用数据库的用户数、同时打开的数据库对象数,内存分配参数、缓冲区分配参数,时间片的大小及数据库的大小等,),9/16/2024,36,需求,分析,概念,结构,逻辑,结构,物理,结构,实施,运行,维护,数据流图,数据字典,调查研究,自顶向下,抽象,数据,,设计局,部,E-R,图,集成,到全局,E-R,图,自底向上,消除冲突,消除不必要的冗余,基本,E-R,图,七条原则,转换成,关系模型,关系模型,优化,5.7,小结,9/16/2024,37,练习题:(,2009,考研),现有如下关系模式:,订单(订单号,零件数量,零件号,零件描述,单价,供应商号,供应商姓名,供应商地址,订购日期,交货日期,订单总量),其中,一个订单对应多种零件,不同订单可以订购同种零件,一种零件由一个供应商供应,一个供应商可以供应多种零件。,写出该关系模式中的函数依赖关系和主码。(,3,分),该关系模式最高满足第几范式?并说明理由。(,3,分),将该关系模式分解为,3NF,,并说明理由。(,8,分),主码:(订单号,零件号),函数依赖集:,1,、零件号,-,供应商号,,2,、(订单号,零件号),-,每一个属性。,,3,、零件号,-,(零件描述,单价,零件数量),4,、供应商号,-,(供应商姓名,供应商地址),分解为三范式为:零件(零件号,零件描述,单价,零件数量,供应商号)供应商(供应商号,供应商姓名,供应商地址)订单(订单号,零件号,订购日期,交货日期,订单总量),9/16/2024,38,习题:,P142 7,商店(,商店编号,,商店名,地址,电话),顾客(,顾客编号,,姓名,性别,家庭住址,出生年月),消费(,商店编号,顾客编号,,消费金额),9/16/2024,39,
展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 图纸专区 > 小学资料


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

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


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