您好,欢迎访问三七文档
当前位置:首页 > 商业/管理/HR > 人事档案/员工关系 > 《数据库系统概论》第5版原版授课-第7章(2)
AnIntroductiontoDatabaseSystem数据库系统概论AnIntroductiontoDatabaseSystem第七章数据库设计(续)中国人民大学信息学院AnIntroductiontoDatabaseSystem第七章数据库设计7.1数据库设计概述7.2需求分析7.3概念结构设计7.4逻辑结构设计7.5物理结构设计7.6数据库的实施和维护7.7小结AnIntroductiontoDatabaseSystem7.4逻辑结构设计逻辑结构设计的任务把概念结构设计阶段设计好的基本E-R图转换为与选用数据库管理系统产品所支持的数据模型相符合的逻辑结构AnIntroductiontoDatabaseSystem7.4逻辑结构设计7.4.1E-R图向关系模型的转换7.4.2数据模型的优化7.4.3设计用户子模式AnIntroductiontoDatabaseSystemE-R图向关系模型的转换(续)转换内容E-R图由实体型、实体的属性和实体型之间的联系三个要素组成关系模型的逻辑结构是一组关系模式的集合将E-R图转换为关系模型:将实体型、实体的属性和实体型之间的联系转化为关系模式AnIntroductiontoDatabaseSystemE-R图向关系模型的转换(续)转换原则1.一个实体型转换为一个关系模式。关系的属性:实体的属性关系的码:实体的码AnIntroductiontoDatabaseSystemE-R图向关系模型的转换(续)2.实体型间的联系有以下不同情况(1)一个1:1联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。①转换为一个独立的关系模式关系的属性:与该联系相连的各实体的码以及联系本身的属性关系的候选码:每个实体的码均是该关系的候选码AnIntroductiontoDatabaseSystemE-R图向关系模型的转换(续)(1)一个1:1联系的转换(续)②与某一端实体对应的关系模式合并合并后关系的属性:加入对应关系的码和联系本身的属性合并后关系的码:不变AnIntroductiontoDatabaseSystemE-R图向关系模型的转换(续)(2)一个1:n联系可以转换为一个独立的关系模式,也可以与n端对应的关系模式合并。①转换为一个独立的关系模式关系的属性:与该联系相连的各实体的码以及联系本身的属性关系的码:n端实体的码AnIntroductiontoDatabaseSystemE-R图向关系模型的转换(续)(2)一个1:n联系的转换(续)②与n端对应的关系模式合并合并后关系的属性:在n端关系中加入1端关系的码和联系本身的属性合并后关系的码:不变可以减少系统中的关系个数,一般情况下更倾向于采用这种方法AnIntroductiontoDatabaseSystemE-R图向关系模型的转换(续)(3)一个m:n联系转换为一个关系模式关系的属性:与该联系相连的各实体的码以及联系本身的属性关系的码:各实体码的组合[例]“选修”联系是一个m:n联系,可以将它转换为如下关系模式,其中学号与课程号为关系的组合码:选修(学号,课程号,成绩)AnIntroductiontoDatabaseSystemE-R图向关系模型的转换(续)(4)三个或三个以上实体间的一个多元联系转换为一个关系模式。关系的属性:与该多元联系相连的各实体的码以及联系本身的属性关系的码:各实体码的组合AnIntroductiontoDatabaseSystemE-R图向关系模型的转换(续)(5)具有相同码的关系模式可合并目的:减少系统中的关系个数合并方法:将其中一个关系模式的全部属性加入到另一个关系模式中然后去掉其中的同义属性(可能同名也可能不同名)适当调整属性的次序E-R图转换关系,可以参见:爱课程网7.3节动画《E-R图转换关系(1)》AnIntroductiontoDatabaseSystemE-R图向关系模型的转换(续)图7.28中虚线上部的E-R图转换为关系模型。关系的码用下横线标出。AnIntroductiontoDatabaseSystemE-R图向关系模型的转换(续)部门(部门号,部门名,经理的职工号,…)职工(职工号、部门号,职工名,职务,…)产品(产品号,产品名,产品组长的职工号,…)供应商(供应商号,姓名,…)零件(零件号,零件名,…)职工工作(职工号,产品号,工作天数,…)供应(产品号,供应商号,零件号,供应量)AnIntroductiontoDatabaseSystem7.4逻辑结构设计7.4.1E-R图向关系模型的转换7.4.2数据模型的优化7.4.3设计用户子模式AnIntroductiontoDatabaseSystem7.4.2数据模型的优化一般的数据模型还需要向特定数据库管理系统规定的模型进行转换。转换的主要依据是所选用的数据库管理系统的功能及限制。没有通用规则。对于关系模型来说,这种转换通常都比较简单。AnIntroductiontoDatabaseSystem数据模型的优化(续)数据库逻辑设计的结果不是唯一的。得到初步数据模型后,还应该适当地修改、调整数据模型的结构,以进一步提高数据库应用系统的性能,这就是数据模型的优化。关系数据模型的优化通常以规范化理论为指导。AnIntroductiontoDatabaseSystem数据模型的优化(续)优化数据模型的方法:(1)确定数据依赖按需求分析阶段所得到的语义,分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖。(2)对于各个关系模式之间的数据依赖进行极小化处理,消除冗余的联系。AnIntroductiontoDatabaseSystem数据模型的优化(续)(3)按照数据依赖的理论对关系模式进行分析,考察是否存在部分函数依赖、传递函数依赖、多值依赖等,确定各关系模式分别属于第几范式。(4)按照需求分析阶段得到的各种应用对数据处理的要求,分析对于这样的应用环境这些模式是否合适,确定是否要对它们进行合并或分解。AnIntroductiontoDatabaseSystem数据模型的优化(续)并不是规范化程度越高的关系就越优当查询经常涉及两个或多个关系模式的属性时,系统必须经常地进行连接运算连接运算的代价是相当高的因此在这种情况下,第二范式甚至第一范式也许是适合的。AnIntroductiontoDatabaseSystem数据模型的优化(续)非BCNF的关系模式虽然会存在不同程度的更新异常,但如果在实际应用中对此关系模式只是查询,并不执行更新操作,就不会产生实际影响。对于一个具体应用来说,到底规范化进行到什么程度,需要权衡响应时间和潜在问题两者的利弊才能决定AnIntroductiontoDatabaseSystem数据模型的优化(续)(5)对关系模式进行必要分解,提高数据操作效率和存储空间的利用率。常用分解方法水平分解垂直分解AnIntroductiontoDatabaseSystem数据模型的优化(续)水平分解什么是水平分解把(基本)关系的元组分为若干子集合,定义每个子集合为一个子关系,以提高系统的效率。如何分解对符合80/20的,把经常被使用的数据(约20%)水平分解出来,形成一个子关系。水平分解为若干子关系,使每个事务存取的数据对应一个子关系。AnIntroductiontoDatabaseSystem数据模型的优化(续)垂直分解什么是垂直分解把关系模式R的属性分解为若干子集合,形成若干子关系模式。垂直分解的原则经常在一起使用的属性从R中分解出来形成一个子关系模式垂直分解的优点可以提高某些事务的效率垂直分解的缺点可能使另一些事务不得不执行连接操作,降低了效率AnIntroductiontoDatabaseSystem数据模型的优化(续)垂直分解的适用范围取决于分解后R上的所有事务的总效率是否得到了提高进行垂直分解的方法简单情况:直观分解复杂情况:用第6章中的模式分解算法垂直分解必须不损失关系模式的语义(保持无损连接性和保持函数依赖)AnIntroductiontoDatabaseSystem7.4逻辑结构设计7.4.1E-R图向关系模型的转换7.4.2数据模型的优化7.4.3设计用户子模式AnIntroductiontoDatabaseSystem7.4.3设计用户子模式定义数据库模式主要是从系统的时间效率、空间效率、易维护等角度出发。定义用户外模式时应该更注重考虑用户的习惯与方便。包括三个方面:AnIntroductiontoDatabaseSystem设计用户子模式(续)(1)使用更符合用户习惯的别名合并各分E-R图曾做了消除命名冲突的工作,以使数据库系统中同一关系和属性具有唯一的名字。这在设计数据库整体结构时是非常必要的。用视图机制可以在设计用户视图时可以重新定义某些属性名,使其与用户习惯一致,以方便使用。AnIntroductiontoDatabaseSystem设计用户子模式(续)(2)针对不同级别的用户定义不同的视图,以保证系统的安全性。假设有关系模式产品(产品号,产品名,规格,单价,生产车间,生产负责人,产品成本,产品合格率,质量等级),可以在产品关系上建立两个视图:为一般顾客建立视图:产品1(产品号,产品名,规格,单价)为产品销售部门建立视图:产品2(产品号,产品名,规格,单价,车间,生产负责人)AnIntroductiontoDatabaseSystem设计用户子模式(续)(3)简化用户对系统的使用如果某些局部应用中经常要使用某些很复杂的查询,为了方便用户,可以将这些复杂查询定义为视图。AnIntroductiontoDatabaseSystem第七章数据库设计7.1数据库设计概述7.2需求分析7.3概念结构设计7.4逻辑结构设计7.5物理结构设计7.6数据库的实施和维护7.7小结AnIntroductiontoDatabaseSystem7.5数据库的物理设计什么是数据库的物理设计数据库在物理设备上的存储结构与存取方法称为数据库的物理结构,它依赖于选定的数据库管理系统。为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程,就是数据库的物理设计。AnIntroductiontoDatabaseSystem数据库的物理设计(续)数据库物理设计的步骤确定数据库的物理结构在关系数据库中主要指存取方法和存储结构;对物理结构进行评价评价的重点是时间和空间效率若评价结果满足原设计要求,则可进入到物理实施阶段。否则,就需要重新设计或修改物理结构,有时甚至要返回逻辑设计阶段修改数据模型。AnIntroductiontoDatabaseSystem7.5数据库的物理设计7.5.1数据库物理设计的内容和方法7.5.2关系模式存取方法选择7.5.3确定数据库的存储结构7.5.4评价物理结构AnIntroductiontoDatabaseSystem7.5.1数据库物理设计的内容和方法设计物理数据库结构的准备工作充分了解应用环境,详细分析要运行的事务,以获得选择物理数据库设计所需参数。充分了解所用关系型数据库管理系统的内部特征,特别是系统提供的存取方法和存储结构。AnIntroductiontoDatabaseSystem数据库物理设计的内容和方法(续)选择物理数据库设计所需参数数据库查询事务查询的关系查询条件所涉及的属性连接条件所涉及的属性查询的投影属性数据更新事务被更新的关系每个关系上的更新操作条件所涉及的属性修改操作要改变的属性值每个事务在各关系上运行的频率和性能要求AnIntroductiontoDatabaseSystem数据库物理设计的内容和方法(续)关系数据库物理设计的内容为关系模式选择存取方法(建立存取路径)设计关系、索引等数据库文件的物理存储结构AnIntroducti
本文标题:《数据库系统概论》第5版原版授课-第7章(2)
链接地址:https://www.777doc.com/doc-1867325 .html