[第12章2数据库设计步骤.ppt

An Introduction to Database System 第12章 数据库设计 12.1 需求分析 12.2 概念结构设计 12.3 逻辑结构设计 12.4 数据库的物理设计 12.5 数据库的实施 12.6 数据库的运行和维护 12.7 小结 12.3 逻辑结构设计 逻辑结构设计的任务 基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构 逻辑结构设计(续) 12.3.1 E-R图向关系模型的转换 转换内容 转换原则 E-R图向关系模型的转换（续） E-R图向关系模型的转换要解决的问题 如何将实体型和实体间的联系转换为关系模式 如何确定这些关系模式的属性和码 转换内容 将E-R图转换为关系数据库模式：将实体、实体的属性和实体之间的联系转换为关系模式。 E-R图向关系模型的转换（续） 实体型间的联系有以下不同情况 ： (1)一个1:1联系 转换为一个独立的关系模式 与某一端实体对应的关系模式合并 (2)一个1:n联系 转换为一个独立的关系模式 与n端对应的关系模式合并 E-R图向关系模型的转换（续） (3) 一个m:n联系转换为一个关系模式。 例，“选修”联系是一个m:n联系，可以将它转换为如下关系模式，其中学号与课程号为关系的组合码： 　　选修（学号，课程号，成绩） E-R图向关系模型的转换（续） (4)三个或三个以上实体间的一个多元联系转换为一个关系模式。 例，“讲授”联系是一个三元联系，可以将它转换为如下关系模式，其中课程号、职工号和书号为关系的组合码： 　　讲授（课程号，职工号，书号） E-R图向关系模型的转换（续） (5)具有相同码的关系模式可合并 目的：减少系统中的关系个数 合并方法：将其中一个关系模式的全部属性加入到另一个关系模式中，然后去掉其中的同义属性（可能同名也可能不同名），并适当调整属性的次序 E-R图向关系模型的转换（续） 注意： 从理论上讲，1:1联系可以与任意一端对应的关系模式合并 但在一些情况下，与不同的关系模式合并效率会大不一样。因此究竟应该与哪端的关系模式合并需要依应用的具体情况而定。 由于连接操作是最费时的操作，所以一般应以尽量减少连接操作为目标。 例如，如果经常要查询某个班级的班主任姓名，则将管理联系与教师关系合并更好些。 E-R图向关系模型的转换（续） [例] 把图12.23中虚线上部的E-R图转换为关系模型 部门实体对应的关系模式 部门（部门号，部门名，经理的职工号，…） 此关系模式已包含了联系“领导”所对应的关系模式 经理的职工号是关系的候选码 职工实体对应的关系模式 职工（职工号、部门号，职工名，职务，…） 该关系模式已包含了联系“属于”所对应的关系模式 E-R图向关系模型的转换（续） [例] （续1） 产品实体对应的关系模式 产品（产品号，产品名，产品组长的职工号，…） 供应商实体对应的关系模式 供应商（供应商号，姓名，…） 零件实体对应的关系模式 零件（零件号，零件名，…） E-R图向关系模型的转换（续） [例] （续2） 联系“参加”所对应的关系模式 职工工作（职工号，产品号，工作天数，…） 联系“供应”所对应的关系模式 供应（产品号，供应商号，零件号，供应量） 12.3.2 数据模型的优化 得到初步数据模型后，还应该适当地修改、调整数据模型的结构，以进一步提高数据库应用系统的性能，这就是数据模型的优化 关系数据模型的优化通常以规范化理论为指导 数据模型的优化（续） 优化数据模型的方法 确定数据依赖 按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖 消除 冗余的联系 对于各个关系模式之间的数据依赖进行极小化处理，消除 冗余的联系。 确定所属范式 按照数据依赖的理论对关系模式逐一进行分析 考查是否存在部分函数依赖、传递函数依赖、多值依赖等 确定各关系模式分别属于第几范式 数据模型的优化（续） 按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适， 确定是否要对它们进行合并或分解。 注意：并不是规范化程度越高的关系就越优，一般说来，第三范式就足够了 数据模型的优化（续） 例：在关系模式 学生成绩单(学号,英语,数学,语文,平均成绩) 中存在下列函数依赖： 　 学号→英语 　 学号→数学 　 学号→语文 　 学号→平均成绩 (英语, 数学, 语文)→平均成绩 数据模型