AnIntroductiontoDatabaseSystem数据库系统概论AnIntroductiontoDatabaseSystem第七章数据库设计(续2)AnIntroductiontoDatabaseSystem第七章数据库设计7.1数据库设计概述7.2需求分析7.3概念结构设计7.4逻辑结构设计7.5数据库的物理设计7.6数据库的实施和维护7.7小结AnIntroductiontoDatabaseSystem7.4逻辑结构设计逻辑结构设计的任务把概念结构设计阶段设计好的基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构逻辑结构设计的步骤将概念结构转化为一般的关系、网状、层次模型将转换来的关系、网状、层次模型向特定DBMS支持下的数据模型转换对数据模型进行优化AnIntroductiontoDatabaseSystem逻辑结构设计(续)逻辑结构设计时的3个步骤AnIntroductiontoDatabaseSystem7.4逻辑结构设计7.4.1E-R图向关系模型的转换7.4.2数据模型的优化7.4.3设计用户子模式AnIntroductiontoDatabaseSystem7.4.1E-R图向关系模型的转换转换内容转换原则AnIntroductiontoDatabaseSystemE-R图向关系模型的转换(续)E-R图向关系模型的转换要解决的问题如何将实体型和实体间的联系转换为关系模式如何确定这些关系模式的属性和码转换内容将E-R图转换为关系模型:将实体、实体的属性和实体之间的联系转换为关系模式。AnIntroductiontoDatabaseSystemE-R图向关系模型的转换(续)实体型间的联系有以下不同情况:(1)一个1:1联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。转换为一个独立的关系模式与某一端实体对应的关系模式合并(2)一个1:n联系可以转换为一个独立的关系模式,也可以与n端对应的关系模式合并。转换为一个独立的关系模式与n端对应的关系模式合并AnIntroductiontoDatabaseSystemE-R图向关系模型的转换(续)(3)一个m:n联系转换为一个关系模式。例,“选修”联系是一个m:n联系,可以将它转换为如下关系模式,其中学号与课程号为关系的组合码:选修(学号,课程号,成绩)AnIntroductiontoDatabaseSystemE-R图向关系模型的转换(续)(4)三个或三个以上实体间的一个多元联系转换为一个关系模式。例,“讲授”联系是一个三元联系,可以将它转换为如下关系模式,其中课程号、职工号和书号为关系的组合码:讲授(课程号,职工号,书号)AnIntroductiontoDatabaseSystemE-R图向关系模型的转换(续)(5)具有相同码的关系模式可合并目的:减少系统中的关系个数合并方法:将其中一个关系模式的全部属性加入到另一个关系模式中,然后去掉其中的同义属性(可能同名也可能不同名),并适当调整属性的次序AnIntroductiontoDatabaseSystemE-R图向关系模型的转换(续)注意:从理论上讲,1:1联系可以与任意一端对应的关系模式合并但在一些情况下,与不同的关系模式合并效率会大不一样。因此究竟应该与哪端的关系模式合并需要依应用的具体情况而定。由于连接操作是最费时的操作,所以一般应以尽量减少连接操作为目标。例如,如果经常要查询某个班级的班主任姓名,则将管理联系与教师关系合并更好些。AnIntroductiontoDatabaseSystemE-R图向关系模型的转换(续)[例]把图7.30中虚线上部的E-R图转换为关系模型部门实体对应的关系模式部门(部门号,部门名,经理的职工号,…)¾此关系模式已包含了联系“领导”所对应的关系模式¾经理的职工号是关系的候选码职工实体对应的关系模式职工(职工号、部门号,职工名,职务,…)¾该关系模式已包含了联系“属于”所对应的关系模式AnIntroductiontoDatabaseSystemE-R图向关系模型的转换(续)[例]把图7.30中虚线上部的E-R图转换为关系模型(续)产品实体对应的关系模式产品(产品号,产品名,产品组长的职工号,…)供应商实体对应的关系模式供应商(供应商号,姓名,…)零件实体对应的关系模式零件(零件号,零件名,…)AnIntroductiontoDatabaseSystemE-R图向关系模型的转换(续)[例]把图7.30中虚线上部的E-R图转换为关系模型(续)联系“参加”所对应的关系模式职工工作(职工号,产品号,工作天数,…)联系“供应”所对应的关系模式供应(产品号,供应商号,零件号,供应量)AnIntroductiontoDatabaseSystem7.4逻辑结构设计7.4.1E-R图向关系模型的转换7.4.2数据模型的优化7.4.3设计用户子模式AnIntroductiontoDatabaseSystem7.4.2数据模型的优化得到初步数据模型后,还应该适当地修改、调整数据模型的结构,以进一步提高数据库应用系统的性能,这就是数据模型的优化关系数据模型的优化通常以规范化理论为指导AnIntroductiontoDatabaseSystem数据模型的优化(续)优化数据模型的方法1.确定数据依赖按需求分析阶段所得到的语义,分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖2.消除冗余的联系对于各个关系模式之间的数据依赖进行极小化处理,消除冗余的联系。3.确定所属范式按照数据依赖的理论对关系模式逐一进行分析考查是否存在部分函数依赖、传递函数依赖、多值依赖等确定各关系模式分别属于第几范式AnIntroductiontoDatabaseSystem数据模型的优化(续)4.按照需求分析阶段得到的各种应用对数据处理的要求,分析对于这样的应用环境这些模式是否合适,确定是否要对它们进行合并或分解。注意:注意:并不是规范化程度越高的关系就越优,一般说来,第三范式就足够了AnIntroductiontoDatabaseSystem数据模型的优化(续)例:在关系模式学生成绩单(学号,英语,数学,语文,平均成绩)中存在下列函数依赖:学号→英语学号→数学学号→语文学号→平均成绩(英语,数学,语文)→平均成绩AnIntroductiontoDatabaseSystem数据模型的优化(续)显然有:学号→(英语,数学,语文)因此该关系模式中存在传递函数信赖,是2NF关系虽然平均成绩可以由其他属性推算出来,但如果应用中需要经常查询学生的平均成绩,为提高效率,仍然可保留该冗余数据,对关系模式不再做进一步分解AnIntroductiontoDatabaseSystem数据模型的优化(续)5.按照需求分析阶段得到的各种应用对数据处理的要求,对关系模式进行必要的分解,以提高数据操作的效率和存储空间的利用率常用分解方法¾水平分解¾垂直分解AnIntroductiontoDatabaseSystem数据模型的优化(续)水平分解¾什么是水平分解–把(基本)关系的元组分为若干子集合,定义每个子集合为一个子关系,以提高系统的效率¾水平分解的适用范围–满足“80/20原则”的应用–并发事务经常存取不相交的数据AnIntroductiontoDatabaseSystem数据模型的优化(续)垂直分解¾什么是垂直分解–把关系模式R的属性分解为若干子集合,形成若干子关系模式¾垂直分解的适用范围–取决于分解后R上的所有事务的总效率是否得到了提高AnIntroductiontoDatabaseSystem7.4逻辑结构设计7.4.1E-R图向关系模型的转换7.4.2数据模型的优化7.4.3设计用户子模式AnIntroductiontoDatabaseSystem7.4.3设计用户子模式定义用户外模式时应该注重的问题包括三个方面:(1)使用更符合用户习惯的别名(2)针对不同级别的用户定义不同的View,以满足系统对安全性的要求。(3)简化用户对系统的使用AnIntroductiontoDatabaseSystem设计用户子模式(续)[例]关系模式产品(产品号,产品名,规格,单价,生产车间,生产负责人,产品成本,产品合格率,质量等级),可以在产品关系上建立两个视图:为一般顾客建立视图:产品1(产品号,产品名,规格,单价)为产品销售部门建立视图:产品2(产品号,产品名,规格,单价,车间,生产负责人)顾客视图中只包含允许顾客查询的属性销售部门视图中只包含允许销售部门查询的属性生产领导部门则可以查询全部产品数据可以防止用户非法访问不允许他们查询的数据,保证系统的安全性AnIntroductiontoDatabaseSystem逻辑结构设计小结任务将概念结构转化为具体的数据模型逻辑结构设计的步骤将概念结构转化为一般的关系、网状、层次模型将转化来的关系、网状、层次模型向特定DBMS支持下的数据模型转换对数据模型进行优化设计用户子模式AnIntroductiontoDatabaseSystem逻辑结构设计小结E-R图向关系模型的转换内容E-R图向关系模型的转换原则AnIntroductiontoDatabaseSystem逻辑结构设计小结优化数据模型的方法1.确定数据依赖2.对于各个关系模式之间的数据依赖进行极小化处理,消除冗余的联系。3.确定各关系模式分别属于第几范式。4.分析对于应用环境这些模式是否合适,确定是否要对它们进行合并或分解。5.对关系模式进行必要的分解或合并AnIntroductiontoDatabaseSystem逻辑结构设计小结设计用户子模式1.使用更符合用户习惯的别名2.针对不同级别的用户定义不同的外模式,以满足系统对安全性的要求。3.简化用户对系统的使用AnIntroductiontoDatabaseSystem第七章数据库设计7.1数据库设计概述7.2需求分析7.3概念结构设计7.4逻辑结构设计7.5数据库的物理设计7.6数据库的实施和维护7.7小结AnIntroductiontoDatabaseSystem7.5数据库的物理设计数据库的物理设计数据库在物理设备上的存储结构与存取方法称为数据库的物理结构,它依赖于选定的数据库管理系统为一个给定的逻辑数据模型选取一个最适合应用环境的物理结构的过程,就是数据库的物理设计AnIntroductiontoDatabaseSystem数据库的物理设计(续)数据库物理设计的步骤确定数据库的物理结构,在关系数据库中主要指存取方法和存储结构对物理结构进行评价,评价的重点是时间和空间效率如果评价结果满足原设计要求,则可进入到物理实施阶段,否则,就需要重新设计或修改物理结构,有时甚至要返回逻辑设计阶段修改数据模型AnIntroductiontoDatabaseSystem数据库的物理设计(续)数据库物理设计确定数据库的物理结构评价数据库的物理结构逻辑结构设计数据库实施物理模型逻辑模型AnIntroductiontoDatabaseSystem7.5数据库的物理设计7.5.1数据库物理设计的内容和方法7.5.2关系模式存取方法选择7.5.3确定数据库的存储结构7.5.4评价物理结构AnIntroductiontoDatabaseSystem7.5.1数据库物理设计的内容和方法设计物理数据库结构的准备工作对要运行的事务进行详细分析,获得选择物理数据库设计所需参数充分了解所用RDBMS的内部特征,特别是系统提供的存取方法和存储结构AnIntroductiontoDatabaseSystem数据库的物理设计的内容和方法(续)选择物理数据库设计所需参数数据库查询事务¾查询的关系¾查询条件所涉及的属性¾连接条件所涉及的属性¾查询的投影属性AnIntroductiontoDatabaseSystem数据库的物理设计的内容和方法(续)