数据库原理 第26～27讲 数据库设计(逻辑结构、物理结构、实施与维护)

《数据库原理 第26～27讲 数据库设计(逻辑结构、物理结构、实施与维护)》由会员分享，可在线阅读，更多相关《数据库原理 第26～27讲 数据库设计(逻辑结构、物理结构、实施与维护)（87页珍藏版）》请在金锄头文库上搜索。

1、 第6章 数据库设计主讲：吕震宇6.4 逻辑结构设计 逻辑结构设计的任务： w 将概念结构进一步转化为相应的数据模型 逻辑结构设计的步骤 w 将概念结构转化为一般的关系、网状、层次模型 w 将转化来的关系、网状、层次模型向特定DBMS 支持下的数据模型转换 w 对数据模型进行优化逻辑结构设计阶段物理 设计 阶段逻辑结构设计阶段优化模型设计 用户 子 模式概念 设计 阶段转化为 一般数 据模型特定 DBMS 支持下 的数据 模型逻辑 模型基本 E-R图转换规则特定DBMS 的特点与限制优化方法如 规范化理论6.4.1 E-R图向关系模型的转换 E-R图w 由实体、实体的属性和实体之间的联系三个要

2、 素组成。 关系模型 w 关系模型的逻辑结构是一组关系模式的集合。 E-R图向关系模型转换的内容w 将实体、实体的属性和实体之间的联系转化为 关系模式。E-R图向关系模型的转换（续） 转换内容w E-R图由实体、实体的属性和实体之间的联系 三个要素组成w 关系模型的逻辑结构是一组关系模式的集合w 将E-R图转换为关系模型：将实体、实体的属 性和实体之间的联系转化为关系模式。转换原则 一个实体型转换为一个关系模式。 一个 m:n 联系转换为一个关系模式。 一个 1:n 联系可以转换为一个独立的关系模式，也 可以与n端对应的关系模式合并。 一个 1:1 联系可以转换为一个独立的关系模式，也 可以与

3、任意一端对应的关系模式合并。 三个或三个以上实体间的一个多元联系转换为一个 关系模式。 同一实体集的实体间的联系，即自联系，也可按上 述 1:1、1:n 和 m:n 三种情况分别处理。 具有相同码的关系模式可合并。 一个实体型转换为一个关系模式。w 关系的属性：实体型的属性 w 关系的码：实体型的码 例： 学生实体可以转换为如下关系模式：学生（学号，姓名，出生日期，所在系，年级，平均成绩）w 性别、宿舍、班级、档案材料、教师、课程、教室 、教科书都分别转换为一个关系模式。 一个 m:n 联系转换为一个关系模式。w 关系的属性：与该联系相连的各实体的码以及联 系本身的属性 w 关系的码：各实体码

4、的组合 例： w “选修”联系是一个m:n联系，可以将它转换为如 下关系模式，其中学号与课程号为关系的组合码 ：选修（学号，课程号，成绩） 一个 1:n 联系可以转换为一个独立的关系模 式，也可以与n端对应的关系模式合并。w 1）转换为一个独立的关系模式 关系的属性：与该联系相连的各实体的码以及联系本身的 属性 关系的码：n端实体的码w 2)与n端对应的关系模式合并 合并后关系的属性：在n端关系中加入1端关系的码和联系 本身的属性 合并后关系的码：不变w 后者可以减少系统中的关系个数，一般情况下更倾 向于采用这种方法 例：w “组成”联系为 1:n 联系。将其转换为关系模式的 两种方法：w 1

5、）使其成为一个独立的关系模式： 组成（学号，班级号）w 2）将其学生关系模式合并： 学生（学号，姓名，出生日期，所在系，年级，班级号，平均成绩） 一个 1:1 联系可以转换为一个独立的关系模 式，也可以与任意一端对应的关系模式合并。w 1) 转换为一个独立的关系模式 关系的属性：与该联系相连的各实体的码及联系本身的属性 关系的候选码：每个实体的码均是该关系的候选码w 2) 与某一端对应的关系模式合并 合并后关系的属性：加入对应关系的码和联系本身的属性 合并后关系的码：不变 例： w “管理”联系为1:1联系，可以有三种转换方法： w （1）转换为一个独立的关系模式：管理（职工号，班级号）或管理

6、（职工号，班级号）w （2）“管理”联系与班级关系模式合并，则只需在班级 关系中加入教师关系的码，即职工号：班级（班级号，学生人数，职工号）w （3）“管理”联系与教师关系模式合并，则只需在教师 关系中加入班级关系的码，即班级号：教师（职工号，姓名，性别，职称，班级号，是否为优秀班主任） 注意： w 从理论上讲， 1:1 联系可以与任意一端对应的关系模 式合并。 w 但在一些情况下，与不同的关系模式合并效率会大不 一样。因此究竟应该与哪端的关系模式合并需要依应 用的具体情况而定。 w 由于连接操作是最费时的操作，所以一般应以尽量减 少连接操作为目标。 w 1:1 联系还经常用来记录“范化”关系

7、。此时不需要任 何合并。 例： w 如果经常要查询某个班级的班主任姓名，则将管理联 系与教师关系合并更好些。 w 学生与本科生、研究生之间的范化关系为1:1联系 三个或三个以上实体间的一个多元联系转换 为一个关系模式。w 关系的属性：与该多元联系相连的各实体的码以及联 系本身的属性w 关系的码：各实体码的组合 例： w “讲授”联系是一个三元联系，可以将它转换为如下关 系模式：讲授（课程号，职工号，书号）w 其中课程号、职工号和书号为关系的组合码。 同一实体集的实体间的联系，即自联系，也 可按上述1:1、1:n和m:n三种情况分别处理。 例： w 如果教师实体集内部存在领导与被领导的1:n自联

8、系 ，我们可以将该联系与教师实体合并，这时主码职 工号将多次出现，但作用不同，可用不同的属性名 加以区分：教师（职工号，姓名，性别，职称，系主任） 具有相同码的关系模式可合并。w 目的：减少系统中的关系个数。 w 合并方法：将其中一个关系模式的全部属性加入到另 一个关系模式中，然后去掉其中的同义属性（可能同 名也可能不同名），并适当调整属性的次序。 例： w “拥有”关系模式：拥有（学号，性别） w 学生关系模式：学生（学号，姓名，出生日期，所在系，年级，班级号，平均成绩）w 都以学号为码，可以将它们合并为一个关系模式： 学生（学号，姓名，性别，出生日期，所在系，年级，班级号，平均成绩） 按照

9、上述七条原则，学生管理子系统中的18个 实体和联系可以转换为下列关系模型：w 学生（学号，姓名，性别，出生日期，所在系， 年级，班级号，平均成绩，档案号） w 性别（性别，宿舍楼） w 宿舍（宿舍编号，地址，性别，人数） w 班级（班级号，学生人数） w 教师（职工号，姓名，性别，职称，班级号，是否为优秀班主任） w 教学（职工号，学号） w 课程（课程号，课程名，学分，教室号） w 选修（学号，课程号，成绩） w 教科书（书号，书名，价钱） w 教室（教室编号，地址，容量） w 讲授（课程号，教师号，书号） w 档案材料（档案号，） 该关系模型由12个关系模式组成。其中：w 学生关系模式包含

10、了“拥有”联系、“组成”联系、“归档 ”联系所对应的关系模式；w 教师关系模式包含了“管理”联系所对应的关系模式；w 宿舍关系模式包含了“住宿”联系所对应的关系模式；w 课程关系模式包含了“开设”联系所对应的关系模式。向特定DBMS规定的模型进行转换 一般的数据模型还需要向特定DBMS规定的 模型进行转换。 转换的主要依据是所选用的DBMS的功能及 限制。没有通用规则。 对于关系模型来说，这种转换通常都比较简 单。6.4.2 数据模型的优化 数据库逻辑设计的结果不是唯一的。 得到初步数据模型后，还应该适当地修改 、调整数据模型的结构，以进一步提高数 据库应用系统的性能，这就是数据模型的 优化。

11、 关系数据模型的优化通常以规范化理论为 指导。优化数据模型的方法 确定数据依赖w 按需求分析阶段所得到的语义，分别写出每个关 系模式内部各属性之间的数据依赖以及不同关系 模式属性之间数据依赖。 例： w 课程关系模式内部存在下列数据依赖： 课程号课程名 课程号学分 课程号教室号 w 选修关系模式中存在下列数据依赖： （学号，课程号）成绩 例（续）：w 学生关系模式中存在下列数据依赖： 学号姓名 学号性别 学号出生日期 学号所在系 学号年级 学号班级号 学号平均成绩 学号档案号w 学生关系模式的学号与选修关系模式的学号之间存 在数据依赖： 学生.学号选修.学号 对于各个关系模式之间的数据依赖进行

12、极小 化处理，消除冗余的联系。 按照数据依赖的理论对关系模式逐一进行分 析，考查是否存在部分函数依赖、传递函数依赖 、多值依赖等，确定各关系模式分别属于第几范 式。w 例：经过分析可知，课程关系模式属于BC范式。 按照需求分析阶段得到的各种应用对数据处 理的要求，分析对于这样的应用环境这些模式是 否合适，确定是否要对它们进行合并或分解。 注意：w 并不是规范化程度越高的关系就越优。w 当一个查询涉及两个或多个关系模式时，系统必须进 行联接运算，而联系运算的代价是相当高的。在这种 情况下，第二范式甚至第一范式也许是最好的。w 非BCNF的关系模式虽然从理论上分析会存在不同程度 的更新异常，但如果

13、在实际应用中对此关系模式只是 查询，并不执行更新操作，则就不会产生实际影响。w 对于一个具体应用来说，到底规范化进行到什么程度 ，需要权衡响应时间和潜在问题两者的利弊才能决定 。一般说来，第三范式就足够了。 例： w 在关系模式：学生成绩单（学号,英语,数学,语文,平均 成绩）中存在下列函数依赖： 学号英语 学号数学 学号语文 学号平均成绩 (英语, 数学, 语文)平均成绩 w 显然有： 学号(英语,数学,语文) w 因此该关系模式中存在传递函数信赖，是2NF关系。w 虽然平均成绩可以由其它属性推算出来，但如果应用中 需要经常查询学生的平均成绩，为提高效率，我们仍然 可保留该冗余数据，对关系模

14、式不再做进一步分解。 按照需求分析阶段得到的各种应用对数据处 理的要求，对关系模式进行必要的分解或合并， 以提高数据操作的效率和存储空间的利用率。w 水平分解w 垂直分解水平分解 什么是水平分解 w 把(基本)关系的元组分为若干子集合，定义每个子 集合为一个子关系，以提高系统的效率。 水平分解的适用范围 w 1）满足“80/20原则”的应用 80/20原则：一个大关系中，经常被使用的数据只是关系 的一部分，约20% 把经常使用的数据分解出来，形成一个子关系，可以减少 查询的数据量。 w 2）并发事务经常存取不相交的数据 如果关系R上具有n个事务，而且多数事务存取的数据不 相交，则R可分解为少于

15、或等于n个子关系，使每个事务 存取的数据对应一个关系。垂直分解 什么是垂直分解 w 把关系模式R的属性分解为若干子集合，形成若 干子关系模式。 垂直分解的原则 w 经常在一起使用的属性从R中分解出来形成一个 子关系模式。 垂直分解的优点与缺点 w 优点：可以提高某些事务的效率 w 缺点：可能使另一些事务不得不执行连接操作， 从而降低了效率。6.4.3 设计用户子模式 定义数据库模式主要是从系统的时间效率、空 间效率、易维护等角度出发。 定义用户外模式时应该更注重考虑用户的习惯 与方便。包括三个方面：w (1) 使用更符合用户习惯的别名。w (2) 针对不同级别的用户定义不同的外模式，以满 足系

16、统对安全性的要求。w (3) 简化用户对系统的使用。 (1) 使用更符合用户习惯的别名w 合并分E-R图需要消除命名冲突，但对于某些局部应 用，更改后的属性名可能会使用户感到不方便，可以 在设计用户子模式时重新定义某些属性名，使其与用 户习惯一致。w 但是，为了应用的规范化，我们也不应该一味地迁就 用户。 例： w 负责学籍管理的用户习惯于称教师模式的职工号为教 师编号。因此可以定义视图，在视图中职工号重定义 为教师编号 (2) 针对不同级别的用户定义不同的外模式，以 满足系统对安全性的要求。 例：w 教师关系模式中包括职工号、姓名、性别、出生日期 、婚姻状况、学历、学位、政治面貌、职称、职务、 工资、工龄、教学效果等属性