Principle and Application of Database 数据库原理及应用 Principle and Application of Database 第5章 数据库设计（续）

学习目标 掌握视图的集成 理解逻辑结构设计的概念和步骤 掌握E-R图向关系模型转换的原则 掌握数据模型的优化 理解用户子模式的设计

5.3 概念结构设计 视图的集成：各个局部视图即分E-R图建立好后，需要对它们进行合并，集成为一个整体的数据概念结构即总E-R图。 5.3 概念结构设计 视图的集成：各个局部视图即分E-R图建立好后，需要对它们进行合并，集成为一个整体的数据概念结构即总E-R图。 视图集成的两种方式 一次集成：一次集成多个分E-R图，适用于局部视图较简单时 逐步累积：首先集成两个局部视图(通常是比较关键的两个局部视图)，以后每次将一个新的局部视图集成进来。 无论哪种方式，集成局部E-R图必须经过两步 合并分E-R图，生成初步E-R图：由于各个局部应用所面向的问题不同，且由不同的设计人员进行设计，这就导致了各个分E-R图之间必定存在冲突。合并分E-R图的主要工作与关键所在就是合理消除各分E-R图的冲突。冲突主要分为如下三类：

属性冲突 属性域冲突：即属性值的类型、取值范围或取值集合不同。如零件号，有的部门将它定义为整型，有的部门将它定义为字符型。又如年龄，有些部门以出生日期形式表示职工年龄，而另一些部门用整数形式表示职工年龄。 属性取值单位冲突：如零件的重量，有的以公斤为单位，有的以斤为单位，有的以克为单位。 属性冲突通常用讨论、协商等手段加以解决。 命名冲突：可能发生在属性级、实体级、联系级上。 同名异义：不同意义的对象在不同局部应用中具有相同名字 异名同义：同一意义的对象在不同局部应用中具有不同名字。 如对科研项目，财务科称为项目，科研处称为课题。 命名冲突通常用讨论、协商等手段解决。

结构冲突 同一对象在不同应用中具有不同的抽象。如职工在某一局部应用中被当作实体，在另一局部应用中被当作属性。解决方法：通常是把属性变为实体或把实体变为属性，使同一对象具有相同的抽象。 同一实体在不同分E-R图中所包含的属性个数和排列次序不完全相同：这是由于不同局部应用关心的是该实体的不同侧面。解决方法：使该实体的属性取各分E-R图中属性的并集，再适当设计属性的次序。 实体之间的联系在不同局部视图中呈现不同的类型：如实体E1与E2在局部应用A中是多对多联系，而在局部应用B中是一对多联系；又如在局部应用X中E1与E2发生联系，而在局部应用Y中E1、E2、E3三者之间有联系。解决方法：根据应用语义对实体联系的类型进行综合或调整。

消除不必要的冗余，设计生成基本E-R图：在初步E-R图中，可能存在冗余数据和冗余实体间联系。冗余数据是指可由基本数据导出的数据，冗余联系是指可由其他联系导出的联系。冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难。消除不必要冗余后的初步E-R图称为基本E-R图。 消除冗余的分析法：以数据字典和数据流图为依据，根据数据字典中数据项间逻辑关系的说明来消除冗余。如职工工资单中包括基本工资、补贴、应扣除水电费及实发工资，而实发工资可由前面各项推算，因此可以去掉，在需要查询实发工资时根据基本工资、补贴、应扣除水电费数据临时生成。

消除冗余的规范化理论法：函数依赖的概念提供了消除冗余联系的形式化工具。具体方法是： 确定分E-R图实体之间的数据依赖FL 。实体之间各种联系可以用实体码之间的函数依赖来表示。如部门和职工之间一对多的联系为职工号→部门号；部门和产品之间多对多的联系为(职工号,产品号) →工作天数。于是有函数依赖集FL 。 求FL的最小覆盖GL ，差集为D = FL-GL。逐一考察D中的函数依赖，确定是否是冗余的联系，若是，就把它去掉。 注意：并不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高某些应用的效率，可以冗余信息作为代价。一种更好的方法是把冗余数据定义在视图中。

某工厂管理信息系统的基本E-R图 n 1 m p 返回1:1 返回m:n 返回1:n 返多元 部门 职工 属于 领导 参加 供应量 产品 供应商 参照2 订单细节 负责 天数 零件 库存 库存量 仓库 组成 订单 订货 顾客 支付 应收款 折扣规则 参照1 返回1:1 返回m:n 返回1:n 返多元

5.4 逻辑结构设计 逻辑结构设计的任务：概念结构是独立于任何一种数据模型的信息结构。逻辑结构设计的任务就是把概念结构设计阶段设计好的基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构。从理论上讲，设计逻辑结构应该选择最适于相应概念结构的数据模型，然后对支持这种数据模型的各种DBMS进行比较，从中选出最合适的DBMS。但实际情况往往是已给定了某种DBMS，设计人员没有选择的余地。 逻辑结构设计的步骤 将概念结构转化为一般的关系、网状、层次模型。 将转化来的关系、网状、层次模型向特定DBMS支持下的数据模型转换。 对数据模型进行优化。

逻辑结构设计 概念结 构设计 数据库 物理设计 转化为一般数据模型 转化为特定DBMS支持下的据模型 逻辑 模型 优化方法如规范化理论 优化模型 概念结 构设计 数据库 物理设计 基本E-R图 转换规则 特定DBMS的特点与限制 优化方法如规范化理论 逻辑 模型

如职工实体可以转换为关系模式职工(职工号,姓名,年龄,职称) E-R图向关系模型的转换 转换要解决的问题：如何将实体和实体间的联系转换为关系模式，如何确定这些关系模式的属性和码。关系模型的逻辑结构是一组关系模式的集合， 而E-R图则是由实体、实体的属性和实体之间的联系三个要素组成的，所以将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式。 转换应遵循的原则 一个实体型转换为一个关系模式： 实体的属性就是关系的 属性，实体的码就是关系的码。 如职工实体可以转换为关系模式职工(职工号,姓名,年龄,职称) 职工 职工号 姓名 年龄 职称

对于实体间的联系则有以下不同的情况： 一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并：若转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均是关系的属性，每个实体的码均是关系的候选码；若与某一端实体对应的关系模式合并，则需在该关系模式中加入另一个关系模式的码和联系本身的属性。如(职工与产品间的)负责联系为1:1联系 转换方法有三种 转换为一个独立的关系模式： 负责(职工号,产品号) 或负责(职工号,产品号) 与职工关系模式合并，则只需在职工关系中加入产品关系的码部门号：职工(职工号,姓名,年龄,职称,产品号) 与产品关系模式合并，则只需在产品关系中加入职工关系的码职工号：产品(产品号,产品名, 职工号)

注意：从理论上讲，1:1联系可以与任意一端对应的关系模式合并。但在一些情况下，与不同的关系模式合并效率会大不一样。因此究竟应该与哪端的关系模式合并需要依应用的具体情况而定。由于连接操作是最费时的操作，所以一般应以尽量减少连接操作为目标。例如，如果经常要查询负责某个产品的职工姓名，则将负责联系与职工关系合并更好些。 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并：若转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均为关系的属性，关系的码为n端实体的码；若与n端对应的关系模式合并，则合并后关系的属性是在n端关系中加入1端关系的码和联系本身的属性，合并后关系的码不变。第二种方法可以减少系统中的关系个数，一般情况下更倾向于采用这种方法。如(部门与职工间的)属于联系为1:n联系 ，将其转换为关系模式有两种方法： 转换为一个独立的关系模式：属于(职工号,部门号)

与职工关系模式合并： 职工(职工号,姓名,年龄,职称,部门号) 一个m:n联系转换为一个关系模式：与该联系相连的各实体的码以及联系本身的属性均是关系的属性，各实体码的组合为关系的码。如(仓库与零件间的)库存联系是一个m:n联系 ，可以将它转换为关系模式：库存(仓库号,零件号,库存量) 三个或三个以上实体间的一个多元联系转换为一个关系模式：与该多元联系相连的各实体的码以及联系本身的属性均是关系的属性，各实体码的组合是关系的码。如(供应商、产品与零件间的)供应联系是一个三元联系， 可以将它转换为如下关系模式：供应(供应商号,产品号,零件号) 具有相同码的关系模式可合并。目的是减少系统中的关系个数，合并方法是将其中一个关系模式的全部属性加入到另一个关系模式中，然后去掉其中的同义属性(可能同名也可能不同名)，并适当调整属性的次序。

形成一般的数据模型后，还需向特定DBMS规定的模型进行转换，转换的主要依据是所选用DBMS的功能及限制，没有通用规则。对于关系模型来说，这种转换通常都比较简单。 数据模型的优化：数据库逻辑设计的结果不是唯一的，得到初步数据模型后，还应该适当地修改、调整数据模型的结构，以进一步提高数据库应用系统的性能，这就是数据模型的优化。关系数据模型的优化通常以规范化理论为指导。优化数据模型的方法是： 确定数据依赖：按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖。 如学生关系模式中存在数据依赖： 学号→姓名，学号→性别，学号→年龄，学号→所在系

选修关系模式中存在数据依赖：(学号,课程号)→成绩 课程关系模式内部存在数据依赖： 课程号→课程名，课程号→学分 学生与选修关系模式的学号之间存在数据依赖： 学生.学号→选修.学号 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。 按照数据依赖的理论对关系模式逐一进行分析，考查是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。如分析可知课程关系模式属于BC范式。 按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。

并不是规范化程度越高的关系就越优：当一个应用的查询中经常涉及到两个或多个关系模式的属性时，系统必须经常地进行联接运算，而联系运算的代价是相当高的，可以说关系模型低效的主要原因就是做联接运算引起的，因此在这种情况下，第二范式甚至第一范式也许是最合适的。 非BCNF的关系模式虽从理论上分析会存在不同程度的更新异常，但若在实际应用中对此关系模式只是查询，并不执行更新操作，则就不会产生实际影响。对一个具体应用来说，到底规范到什么程度，需权衡响应时间和潜在问题两者的利弊。一般说来，第三范式就足够了。如在关系模式学生成绩(学号,英语,数学,语文,平均分)中存在函数依赖：学号→英语，学号→数学，学号→语文，学号→平均分，(英语, 数学, 语文)→平均分。显然有学号→(英语,数学,语文)，所以该关系模式中存在传递函数信赖，是2NF关系。虽然平均成绩可以由其他属性推算出来，但如果应用中需要经常查询学生的平均成绩，为提高效率，仍然可保留该冗余数据，对关系模式不再做进一步分解。

按照需求分析阶段得到的各种应用对数据处理的要求，对关系模式进行必要的分解或合并，以提高数据操作的效率和存储空间的利用率。常用的分解方法是： 水平分解：把(基本)关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率。根据“80/20原则” ，一个大关系中，经常被使用的数据只是关系的一部分(约20%)，把经常使用的数据分解出来，形成一个子关系，可以减少查询的数据量。如果关系R上具有n个事务，而且多数事务存取的数据不相交，则R可分解为少于或等于n个子关系，使每个事务存取的数据对应一个关系。 垂直分解：把关系模式R的属性分解为若干子集合，形成若干子关系模式。分解原则是经常在一起使用的属性从R中分解出来形成一个子关系模式。垂直分解可以提高某些事务的效率，但也可能使另一些事务不得不执行连接操作，从而降低了效率

是否进行垂直分解取决于分解后R上所有事务的总效率是否得到了提高。垂直分解必须确保无损连接性和保持函数依赖。 设计用户子模式：将概念模型转换为全局逻辑模型后，还应根据局部应用需求，结合具体DBMS特点，设计用户的外模式。定义数据库模式主要从系统时间效率、空间效率、易维护等角度出发，而定义用户外模式更应注重考虑用户的习惯与方便。 使用更符合用户习惯的别名：合并各分E-R图曾做了消除命名冲突的工作，以使数据库系统中同一关系和属性具有唯一名，这在设计数据库整体结构时非常必要。但对于某些局部应用，由于改用了不符合用户习惯的属性名，可能会使他们感到不方便，因此在设计用户的子模式时可以重新定义某些属性名，使其与用户习惯一致。当然，为了应用的规范化，不应一味地迁就用户，如负责学籍管理的用户习惯于称教师模式的职工号为教师编号，可定义视图，在视图中职工号重定义为教师编号。

针对不同级别的用户定义不同的视图，以满足系统对安全性的要求。如对于关系模式中产品(产品号,产品名,规格,单价,车间,生产负责人,成本,合格率,质量等级)，可以建立两个视图： 一般顾客视图： 产品1(产品号,产品名,规格,单价) 销售部门视图： 产品2(产品号,产品名,规格,单价,车间,生产负责人) 顾客视图中只包含允许顾客查询的属性，销售部门视图中只包含允许销售部门查询的属性，生产领导部门则可以查询全部产品数据。这样就可以防止用户非法访问本来不允许他们查询的数据，保证了系统的安全性。 简化用户对系统的使用：若某些局部应用中经常使用某些很复杂的查询，为方便用户，可将这些复杂查询定义为视图，用户每次只对定义好的视图进行查询，大大简化了用户的使用。

小结 视图的集成 逻辑结构设计的概念和步骤 E-R图向关系模型转换的原则 数据模型的优化 用户子模式的设计

下课了。。。 攀 登 休息…