05-1数据库设计.ppt

* 逻辑结构设计小结 E-R图向关系模型的转换原则 ⒈ 一个实体型转换为一个关系模式。 ⒉ 一个m:n联系转换为一个关系模式。 ⒊ 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。 ⒋ 一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。 * 逻辑结构设计小结 E-R图向关系模型的转换原则 ⒌ 三个或三个以上实体间的一个多元联系转换为一个关系模式。 ⒍ 同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和m:n三种情况分别处理 ⒎ 具有相同码的关系模式可合并。 * 逻辑结构设计小结 优化数据模型的方法 ⒈ 确定数据依赖 ⒉ 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。 ⒊ 确定各关系模式分别属于第几范式。 ⒋ 分析对于应用环境这些模式是否合适，确定是否要对它们进行合并或分解。 ⒌ 对关系模式进行必要的分解或合并 * 逻辑结构设计小结 设计用户子模式 1. 使用更符合用户习惯的别名 2. 针对不同级别的用户定义不同的外模式，以满足系统对安全性的要求。 3. 简化用户对系统的使用 * 以你的设计为例，试给出从需求分析阶段开始，直至完成逻辑结构设计的全过程。 * 例如，如果经常要查询某个班级的班主任姓名，则将管理联系与教师关系合并更好些。 * 并不是规范化程度越高的关系就越优。 当一个应用的查询中经常涉及到两个或多个关系模式的属性时，系统必须经常地进行联接运算，而联系运算的代价是相当高的，可以说关系模型低效的主要原因就是做联接运算引起的，因此在这种情况下，第二范式甚至第一范式也许是最好的。 非BCNF的关系模式虽然从理论上分析会存在不同程度的更新异常，但如果在实际应用中对此关系模式只是查询，并不执行更新操作，则就不会产生实际影响。 对于一个具体应用来说，到底规范化进行到什么程度，需要权衡响应时间和潜在问题两者的利弊才能决定。一般说来，第三范式就足够了。 * * m：n联系转换 “选修”联系是一个m:n联系，可以将它转换为如下关系模式，其中学号与课程号为关系的组合码： 　　选修（学号，课程号，成绩） * 三元联系转换 例，“讲授”联系是一个三元联系，可以将它转换为如下关系模式，其中课程号、职工号和书号为关系的组合码： 　　讲授（课程号，职工号，书号,授课时间） * 自反联系转换 例，如果教师实体集内部存在领导与被领导的1:n自联系，我们可以将该联系与教师实体合并，这时主码职工号将多次出现，但作用不同，可用不同的属性名加以区分： 教师：｛职工号，姓名，性别，职称，系主任｝ * 学生管理子系统 学生 教师 宿舍 班级 档案 教学 组成 住宿 归档 m n n 1 1 1 教室 参考书 讲授 选修 m p n m n 排课 n m m 1 管理 1 1 课程 * 学生管理子系统 按照上述原则，学生管理子系统中的16个实体和联系可以转换为下列关系模型： 学生（学号，姓名，性别，出生日期，所在系，年级，班级号，平均成绩，档案号，宿舍编号） 宿舍（宿舍编号，地址，人数） 班级（班级号，学生人数） 教师（职工号，姓名，性别，职称，班级号，是否为优秀班主任） * 学生管理子系统 教学（职工号，学号,…… ） 课程（课程号，课程名，学分） 选修（学号，课程号，成绩） 参考书（书号，书名，价钱） 教室（教室编号，地址，容量） 讲授（课程号，教师号，书号，授课时间） 档案材料（档案号 , ……） 排课（课程号，教室编号，开课学期…… ） * 学生管理子系统 该关系模型由12个关系模式组成。 其中： 学生关系模式包含了“住宿”联系、“组成”联系、“归档”联系所对应的关系模式 教师关系模式包含了“管理”联系所对应的关系模式； * 部门 职工 产品 零件 供应商 仓库 1 1 m n 1 1 n n n m m m p 领导 属于 参加 供应 库存 负责 天数 供应量 库存量 * 实体： 部门 (部门号，……) 职工 (职工号，……) 产品 (产品号，……) 供应商 (供应商号，…) 零件 (零件号，……) 仓库 (仓库号，……) 联系： 领导 (部门号，经理的职工号) 属于 (职工号，部门号) 负责 (职工号，产品号) 参加 (职工号，产品号，工作天数) 供应 (产品号，供应商号，零件号，供应量) 库存 (零件号，仓库号，库存量) * 三、数据模型的优化 数据库逻辑设计的结果不是唯一的。 得到初步数据模型后，还应该适当地修改、调整数据模型的结构，以进一步提高数据库应用系统的性能，这就是数据模型的优化。 关系数据模型的