第六章 数据库设计.ppt

1、第六章 数据库设计,主要章节,6.1 概述 6.2 需求分析 6.3 概念结构设计 6.4 逻辑结构设计 6.5 物理结构设计 6.6 数据库的实现 6.7 数据库的运行与维护,本章重要概念,(1)数据库设计的两种方法：生命周期法和快速原型法。 (2)概念设计的重要性、主要步骤。逻辑设计阶段的主要步骤。 (3)ER模型的基本元素，属性的分类，联系的元数、连通词、基数。采用ER方法的概念设计步骤。 (4)ER模型到关系模型的转换规则。采用ER方法的逻辑设计步骤。 (5)ER模型的扩充：弱实体，超类和子类。,6.1概述,6.1概述,主要内容 数据库设计目标和方法 数据库设计的基本步骤,数据库设计目

2、标和方法,数据库设计 数据库设计是指对于给定的软、硬件环境，针对现实问题，设计一个较优的数据模型，建立相应的数据库结构和数据库应用系统。,数据库设计目标和方法,数据库设计目标 最大限度地满足用户的应用功能需求。主要是指用户可以将当前与可预知的将来应用所需要的数据及其联系，全部准确地存放在数据库中。 获得良好的数据库性能。即要求数据库设计保持良好的数据特性以及对数据的高效率存取和资源的合理使用，并使建成的数据库具有良好的数据共享性、独立性、完整性及安全性等。（对于关系数据库） 对现实世界模拟的精确度要高。 数据库设计应充分利用和发挥现有DBMS的功能和性能。 符合软件工程设计要求，因为应用程序设

3、计本身就是数据库设计任务的一部分。,数据库设计目标和方法,对于关系数据库： 数据要达到一定的规范化程度，避免数据重复存储和异常操作。 保持实体之间连接的完整性，避免数据库的不一致性。 满足对事务响应时间的要求。 尽可能减少数据的存储量和内外存间数据的传输量。 便于数据库的扩充和移植，使系统有更好的适应性。,数据库设计目标和方法,数据库设计方法 生命周期法 生命周期（Life cycle）法就是将整个数据库应用系统的开发过程分解成若干个阶段，并对每个阶段的目标、任务、方法作出规定，使整个数据库应用系统的开发过程具有合理的组织和科学的秩序。 阶段划分：系统分析、系统设计、系统实施、系统运行与维护。

4、 主要遵循的原则： 用户参与的原则。 先逻辑、后物理的原则。 自顶向下的原则。 工作成果描述标准化原则。,需求分析,系统设计,系统实施,运行维护,生命周期法,确定开发的总目标,计划开发的软件系统功能、性能、可靠性及接口等方面的设想。并提供一个可做为设计基础的系统规格说明书，包括对软、硬件环境的需求和一整套完整的数据流图。,把需求分析阶段所确定的功能细化。主要工作是设计模块结构图和系统的数据结构。,以某一个或几种特定的程序设计语言表达上一阶段确定的各模块控制流程。编制时应遵循结构化程序设计。并对已编制好的程序进行单元调试（分调），整体调试（联调）和系统测试（验收）。,是整个生存期中时间最长的阶段

5、，重点是将系统付诸使用，同时解决开发过程中遗留问题，改正和改善性能.,数据库设计目标和方法,数据库设计目标和方法, 快速原型法 快速原型（Rapid Prototyping）法的基本思想是在初步了解用户的基本要求后，开发人员先建立一个他们认为符合用户要求的模式系统交付用户检验，由于模型是可以执行的，所以为用户提供了获得感性认识的机会。 优点： 用户可以测试具体实例，直接观察一个实际系统 。 有利于准确地定义出用户需求，降低系统开发风险。 适用于中小规模系统的开发。 缺点： 具有为用户需求快速生成软件的工具和环境。,数据库设计目标和方法, 面向对象法 面向对象（Object Oriented，简

6、称OO）法是针对面向过程提出的，是区别于传统的结构化方法的一种新方法、新思路，是一种基于数据抽象的类的组合的自底向上的开发方法。 基本步骤： 标识对象和定义类； 组织类间关系； 在类层中构造框架； 建立可复用的类库和系统总框架。,数据库设计目标和方法,面向对象法主要有以下四个特征： (1) 对象是有关数据和操作的封装体，突破了传统的将数据与操作分离的模式，较好地实现了数据抽象。 (2) 面向对象法的继承性体现了概念分离抽象。在对象继承结构上，下层对象继承上层对象的特征（属性和操作），因而便于软件系统的演化和功能扩充。 (3) 面向对象法用消息将对象动态连接在一起。与结构化方法中的模块调用不同，

7、面向对象法采用了灵活的消息传递方式，便于在概念上体现并行和分布式结构。 (4) 面向对象法具有封装性。对象将其实现细节封装在它的内部，因此无论是对象功能的完善扩充还是对象实现的修改，影响仅限于该对象内部而不会对外界产生影响，这就保证了软件系统的可复用性和可维护性。,数据库设计的基本步骤,对用户提出的各种要求加以分析，对各种原始数据加以综合、整理，是形成最终设计目标的首要阶段，也是整个数据库设计过程中最困难的阶段。,概念结构设计是对用户需求进行进一步抽象、归纳，并形成独立于DBMS和有关软、硬件的概念数据模型的设计过程，这是对现实世界中具体数据的首次抽象，实现了从现实世界到信息世界的转化过程。,

8、逻辑结构设计是将概念结构转化为某个DBMS所支持的数据模型，并进行优化的设计过程。由于逻辑结构设计是一个基于具体DBMS的实现过程，所以选择什么样的数据模型尤为重要，其次是数据模型的优化。,物理结构设计是将逻辑结构设计阶段所产生的逻辑数据模型，转换为某一计算机系统所支持的数据库物理结构的实现过程。,数据库实施阶段，即数据库调试、试运行阶段。一旦数据库物理结构形成，就可以用已选定的DBMS来定义、描述相应的数据库结构，装入相应的数据，以生成完整的数据库。,数据库实施阶段结束，标志着数据库系统投入正常运行工作的开始。数据库运行及维护的过程，是一个调整、修改和不断完善的运行过程。,6.2 需求分析,

9、6.2 需求分析,主要内容 需求分析的任务 需求分析的步骤,需求分析的任务,需求分析阶段任务是对系统的整个应用情况作全面的、详细的调查，确定企业组织的目标，收集支持系统总的设计目标的基础数据和对这些数据的要求，确定用户的需求，并把这些要求写成用户和数据库设计者都能够接受的文档。 需求分析中调查分析的方法很多，通常的办法是对不同层次的企业管理人员进行个人访问，内容包括业务处理和企业组织中的各种数据。访问的结果应该包括数据的流程、过程之间的接口以及访问者和职员两方面对流程和接口语义上的核对说明和结论。对于某些特殊的目标和数据库的要求，可以从企业组织中的最高层机构得到。 设计人员还应该了解系统将来要

10、发生的变化，收集未来应用所涉及的数据，充分考虑到系统可能的扩充和变动，使系统设计更符合未来发展的趋向，并且易于改动，以减少系统维护的代价。,这一阶段的任务如图总体信息需求定义了未来系统用到的所有信息，描述了数据之间本质上和概念上的联系，描述了实体、属性、组合及联系的性质。 这一阶段的结果是“需求说明书”，其主要内容是系统的数据流图和数据字典。需求说明书应是一份既切合实际，又具有远见的文档，是一个描述新系统的轮廓图。,需求分析的任务,需求分析的步骤, 分析用户活动，产生用户活动图。这一步主要了解用户当前的业务活动和职能，搞清其处理流程（即业务流程）。如果一个处理流程比较复杂，就要把这个处理流程分

11、解成若干个子处理流程，使每个处理流程功能明确、界面清楚，分析之后画出用户活动图（即用户的业务流程图）。 确定系统范围，产生系统范围图。这一步是确定系统的边界。在和用户经过充分讨论的基础上，确定计算机所能进行数据处理的范围，确定哪些工作由人工完成，哪些工作由计算机系统完成，即确定人机界面。 分析用户活动所涉及的数据，产生数据流图。深入分析用户的业务处理，以数据流图形式表示出数据的流向和对数据所进行的加工。,需求分析的步骤,数据流图（Data Flow Diagram，简记为DFD）：是从“数据”和“对数据的加工”两方面表达数据处理系统工作过程的一种图形表示法。 特点具有直观、易于被用户和软件人员

12、双方都能理解的一种表达系统功能的描述方式。 DFD有四个基本成分： 数据流（用箭头表示） 加工或处理（用圆圈表示） 文件（用双线段表示） 外部实体（数据流的源点或终点，用方框表示）,需求分析的步骤,DFD可作为自顶向下逐步细化时描述对象的工具。顶层的每一个圆圈（加工处理）都可以进一步细化为第二层；第二层的每一个圆圈又可以进一步细化为第三层；直到最底层的每一个圆圈已表示一个最基本的处理动作为止。 DFD可以形象地表示数据流与各业务活动的关系，它是需求分析的工具和分析结果的描述手段。 例6.1 在选课业务的处理流程中，假设开发人员收集到以下数据：学生基本信息表、课程表、选课单、选课情况一览表、成绩

13、单等。 通过分析，确认学生基本信息表、课程表、选课单是输入选课系统的原始数据，而选课情况一览表以及成绩单等是选课系统最终需要输出的数据，如下图所示。,需求分析的步骤,学生选课系统是如何对系统的原始数据进行处理最后得到系统的输出数据呢？下面图给出了学生选课系统的整个数据流图，它是前面图的进一步分解和细化。数据流图是一种从数据的角度描述数据作为输入进入系统，经受若干加工处理，或者合并，或者分解，或者存储，最后输出的整个过程。,需求分析的步骤,学生信 息录入,选课信 息录入,成绩录入,查询个人所有课程成绩,课程信息录入,查询课程的 选课情况,查询某 门课程的所 有成绩,学生选课系统的0层数据流图,需

14、求分析的步骤, 分析系统数据，产生数据字典。数据字典提供了对数据库数据描述的集中管理，它的功能是存储和检索各种数据描述（称为元数据Metadata），如叙述性的数据定义等，并且为DBA提供有关的报告。 数据字典中通常包括 ： 数据项 数据结构 数据流 数据存储 加工过程,例6.2 在上图中有一个数据流查询个人所有课程成绩，每个人的成绩单有一个数据项为学生的学号SNO。在数据字典中对此数据项如下描述。,数据项名：SNO 说 明：标识一名学生 类 型：CHAR(9) 长 度：9 别 名：学生学号 取值范围：000000000999999999,需求分析的步骤, 数据项 数据项是数据的最小单位，对数

15、据项的描述，通常包括数据项名、含义、别名、类型、长度、取值范围以及与其他数据项的逻辑关系。,需求分析的步骤, 数据结构 数据结构反映了数据之间的组合关系。 一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合而成。 它包括数据结构名、含义及组成该数据结构的数据项名或数据结构名。,需求分析的步骤,数据流名：个人成绩查询 说 明：学生可以根据所学专业、班级号、学生姓名、课程名称来查询个人成绩 来 源：学生选课信息 去 向：输出到个人成绩单 数据结构：个人成绩查询所学专业班级号学生姓名课程名称, 数据流 数据流可以是数据项，也可以是数据结构，表示某一加工处理

16、过程的输入或输出数据。对数据流的描述应包括数据流名、说明、流出的加工名、流入的加工名以及组成该数据流的数据结构或数据项。 例6.3 在上图中成绩查询是一个数据流，在数据字典中可作如下描述。,需求分析的步骤,数据存储名：课程 说 明：对每门课程的名称、学分、先行课程号和摘要的描述 输出数据流：课程介绍 数 据 描 述：课程号、课程名、学分数、先行课程号、摘要 数 量：每年328种 存 取 方 式：随机存取, 数据存储 数据存储是处理过程中要存储的数据，它可以是手工凭证、手工文档或计算机文档。对数据存储的描述应包括：数据存储名、说明、输入数据流、输出数据流、数据量（每次存取多少数据）、存取频度（单

17、位时间内存取次数）和存取方式（是批处理，还是联机处理；是检索，还是更新；是顺序存取，还是随机存取）。 例6.4 上图中课程是个数据存储，在数据字典中可对其作如下描述。,需求分析的步骤,处理过程：确定选课名单 说 明：对选某门课程的每一个学生，根据已选修课程确定其是否可 选该课程。再根据学生选课的人数选择适当的教室，制定选课单。 输 入：学生选课、可选课程、已选课程 输 出：选课单程序提要：a对所选课程在选课表中查找其是否已选此课程；b若未选过此课程，则在选课表中查找是否已选此课程的先行课程； c若a、b都满足，则在选课表中增加一条选课记录；d处理完全部学生的选课后，形成选课单。, 加工过程 对

18、加工处理的描述包括加工过程名、说明、输入数据流、输出数据流，并简要说明处理工作、频度要求、数据量及响应时间等。,6.3 概念设计,6.3 概念设计,主要内容 概念结构设计任务和ER模型的特点 概念结构设计的基本方法 概念结构设计的主要步骤 局部ER模型的设计 全局ER模型的设计 概念结构设计实例,概念结构设计任务和ER模型的特点,数据库的概念结构设计是整个数据库设计的关键阶段，其主要任务是通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模式。 实体-联系（Entity Rela-tionship，ER）模型具有以下特点： 能真实、充分地反映现实世界，包括事物和事物之间的联系

19、，并能满足用户对数据的处理要求； 易于理解。可以利用它在设计人员、编程人员以及最终用户之间进行交流，使得用户能够积极参与，保证数据库设计的成功； 易于更改。当应用环境和应用要求发生改变时，容易对模式进行修改和扩充； 易于向关系、网状、层次等各种数据模型转换。,概念结构设计的基本方法, 自底向上的设计方法： 也称为属性综合法。这种方法的基本点是将前面需求分析中收集到的数据元素作为基本输入，通过对这些元素的分析，把它们综合成相应的实体或联系。 适合范围 较小单位的、较为简单的设计对象 不适合于中等规模以上的设计对象,概念结构设计的基本方法, 自顶向下的设计方法： 从分析组织的事务活动开始，按下面步

20、骤进行： 首先识别用户所关心的实体及实体间的联系，建立一个初步的数据模型框架； 然后再以逐步求精的方式加上必需的描述属性形成一个完整的局部ER模型； 最后再将这些局部ER模型集成为一个统一的全局ER模型。,概念结构设计的主要步骤, 进行数据抽象，设计局部概念模式局部用户的信息需求是构造全局概念模式的基础。在建立局部概念结构时，常常要对需求分析的结果进行细化、补充和修改，如有的数据项要分为若干子项，有的数据定义要重新核实等。 将局部概念模式综合成全局概念模式 综合各局部概念结构就可得到反映所有用户需求的全局概念结构。在综合过程中，主要处理各局部模式对各种对象定义的不一致问题，包括同名异义、异名同

21、义和同一事物在不同模式中被抽象为不同类型的对象（例如，有的作为实体，有的又作为属性）等问题。把各个局部结构合并，还会产生冗余问题，或导致对信息需求的再调整与分析，以确定确切的含义。 评审 消除了所有冲突后，就可把全局结构提交评审。评审分为用户评审与DBA及应用开发人员评审两部分。,局部ER模型的设计,1. 确定局部结构范围 设计局部ER模型时，首先需要根据系统的具体情况，在多层的数据流图中选择一个适当层次的数据流图，让这组图中每一部分对应一个局部应用，然后以这一层次的数据流图为出发点，设计局部ER图。 在确定局部ER模型的设计范围时，有两条原则可供参考： 把那些关系最密切的若干功能所涉及到的数

22、据尽可能地包含在一个局部ER模型内； 一个局部ER模型中所包含的实体数不能太多，以免过于复杂，不便理解和管理。,局部ER模型设 计的流程图如下：,局部ER模型的设计,局部ER模型的设计,下面以学校的教务管理信息系统为例来说明局部概念结构设计范围的确定。教务管理信息系统的顶层数据流图如下图所示。,局部ER模型的设计,下面图给出了教务管理信息系统的0层数据流图，该图描述了教务管理信息系统的组成部分以及各部分的输入和输出数据。,局部ER模型的设计,局部ER模型的设计,2. 确定实体及实体的主键 确定实体 实体（Entity）是一个数据对象，指应用中可以区别的客观存在的事物，如人、部门、表格、物体、项

23、目等。同一类实体构成实体集（Entity Set）。ER模型中的实体往往是指实体集。 学生选课子系统局部应用中，学生是一个实体，学生张平、李玲是学生实体中的两个实例。课程是一个实体，操作系统、数据库原理及应用是课程实体中的两个实例。 课程管理子系统的局部应用中，课程是一个实体，每门课程是课程实体中的一个实例。上课的教师是一个实体，每位上课的教师都是教师实体中的一个实例。 成绩管理子系统的局部应用中，学生是一个实体。一个学生，选修一门课程并参加了考试，就会有这门课程的成绩。因此，可以把成绩视为选课联系的一个属性。,局部ER模型的设计, 确定实体的主键 主键是确定实体的唯一标志。 学生实体的主键是

24、学号； 课程实体的主键是课程号； 教师实体的主键是教师号；,局部ER模型的设计, 区分实体与属性的一般原则： 实体一般需要描述信息，而属性不需要。例如，学生需要描述属性（学号、姓名、性别、出生年月等），所以学生是实体。而性别不需要描述属性，所以性别是属性。 多值的属性可考虑作为实体。例如，教师的职务是一个多值的属性，即一个教师可能担任多个职务。此时职务可考虑作为一个独立的实体，否则数据库表中就会出现大量空值。,局部ER模型的设计, 实体与属性是相对而言的。 同一事物，在一种应用环境中作为“属性”，在另一种应用环境中就必须作为“实体”。 例如，学校中的系，在某种应用环境中，它只是作为“学生”实体

25、的一个属性，表明一个学生属于哪个系；而在另一种环境中，由于需要考虑一个系的系主任、教师人数、学生人数、办公地点等，这时系就需要作为实体了。,局部ER模型的设计,3. 定义实体间的联系 联系是实体集之间关系的抽象表示，即对现实世界中事物之间关系的描述。 如教师实体集与学生实体集间的“讲授”联系，公司实体集与职工实体集之间的“聘任”联系等。 在局部ER图设计时，需要对已识别出的实体确定不同实体间的联系是属于什么类型的联系，是二元联系还是多元联系？,局部ER模型的设计, 一对一（1:1）联系 若两个实体集中的每一个实体至多和另一个实体集中的一个实体有联系，则称两个实体集具有1:1的联系。 一对多（1

26、:N）联系 设有两个实体集，若第一个实体集中每个实体与第二个实体集中多（大于1）个实体相联系，而第二个实体中的每个实体至多和第一个实体集中的一个实体有联系，则称第一个实体集与第二个实体集是一对多的联系，记为1:N。 多对多（M:N）联系 若两个实体集中的每一个实体都和另一个实体集中多（大于1）个实体有联系，则称这两个实体集是多对多的联系，记为M:N。,局部ER模型的设计,定义实体联系时应注意 ： 消除冗余联系。在确定联系类型时，应注意防止出现冗余联系（即可以从其他联系导出的联系）。 假定每一个技术员必须参加一个工程；每个工程有多个技术员参加；每个工程必须使用一种技术。由于联系具有传递性，因此，

27、隐含了每一个技术员必须掌握一种技术。该问题设计到三个实体，即技术员、工程以及技术。,局部ER模型的设计, 正确鉴别二元及多元联系。 在局部ER图设计中，不同实体间应建立二元还是多元联系，应该根据问题说明来确定。 问题1：任何一个供应商可向任何一个顾客供应任何一种零件。 在这个问题中，给定一个供应商，不能够确定该供应商向哪个顾客供应了哪种零件。给定一个顾客，也不能够确定该顾客是向哪个供应商购买了哪种零件。同样，给定一个零件，也不能确定哪个顾客在哪个供应商处购买的。如果想知道哪一个供应商向哪一个顾客提供了哪一种零件，则必须构建一个三元联系，且供应商、顾客以及零件三个实体之间的联系是多对多的。,局部

28、ER模型的设计,问题2：任何一个供应商可向任何一个顾客供应零件，但每个顾客订购的零件是一定的。 在这个问题中，同样地，给定一个供应商，却不能确定向哪个顾客供应零件；给定一个顾客，也不能确定向哪个供应商购买零件。但是，顾客确定了，该顾客所购买的零件就可以确定。 因此，供应商和顾客之间是二元的多对多联系；而零件和顾客之间是二元的一对多联系。只有供应商和顾客确定了，才能确定一个供应联系值；而顾客确定了，可以有一个唯一的零件值。,问题3：任何一个供应商可向任何一个顾客提供零件，但某个供应商对某个顾客供应的零件是确定的。 这个问题表示，当供应商和顾客确定了，供应商供应给顾客的零件也就确定了。对此只需定义

29、一个二元联系，而零件则可作为供应联系的一个属性 。由以上讨论可知，对于多个实体，是否应该定义成一个多元联系的问题，不可一概而论，应该具体问题做具体分析，所定义的模式要能够确切地表达问题的语义。,局部ER模型的设计,局部ER模型的设计, 防止存在语义上的缺陷。 主要原因是定义联系时没有弄清问题的语义，定义的结构无法提供所需要的信息。 例如，一个学院拥有多名教教师以及一个学院包含多个系。 问题1：如果给定一个职工号，并查询该职工属于哪一个系，那么由下图可以确定该职工是哪一个学院的，但不能确定属于该学院的哪一个系。,解决上述问题的方法是对ER图作适当变换。,局部ER模型的设计,系与教职工之间直接发生

30、联系，而且是一对多联系。现在，给定一个职工号就可以确定该职工属于哪一个系。,问题2：如果某些教职工不属于任何系而是直属于学院的，那么就不能提供这方面的信息。因此这种结构仍缺乏语义信息。 解决的方法是增加一个联系（如增加学院教职工间的“直属”联系），为直属学院的教职工提供一个路径。 通过添加新的联系解决了一些语义问题，但对有些情况，增加新的联系会带来新的语义问题。,局部ER模型的设计,局部ER模型的设计,具体事例为：,这个实例中无法得到关于哪位教师指导哪个学生参加哪项工程的信息（如教师T001和T002指导学生ST001参加工程P001和P002）。 改进的一种方法是再增加一个教师对工程的“服务

31、”联系。,问题3：假定每个学生可在多名教师指导下参加多项工程。每位教师可指导多名学生，但只允许一位教师指导一个学生参加一项工程，而不允许多位教师指导一名学生参加某项工程。,局部ER模型的设计,局部ER模型的设计,添加了“服务”联系后的结构能够确切地提供如下信息：职工号为T001的教师指导学号为ST001的学生参加工程号为P001的工程。职工号为T002的教师指导学号为ST002的学生参加工程号为P001的工程。但是，从上图却无法确定职工号为T002的教师指导学号为ST001的学生究竟参加了那一项工程。可见，有时增加了一个新的联系虽然可以化解原来的语义问题，却又产生了新的语义问题。 解决该问题的

32、方法是将教师、学生以及工程三个实体间的联系定义成一个三元联系 。,局部ER模型的设计,局部ER模型的设计,4. 给实体及联系加上描述属性 为局部视图中的每个实体和联系加上所有必需的其他描述属性。 在需求分析阶段，已收集了所有的数据对象。除了主键属性外，还需将其他属性分配给有关的实体或联系。为使这种分配更合理，必须研究属性之间的函数依赖关系并考虑其他一些准则，而这些不易于一般用户理解。因此在概念结构设计阶段，应该避免涉及这类问题，而主要应从用户需求的概念上去识别实体或联系应该有哪些描述属性。 例如，“学生”实体的描述属性除了“学号”以外，还需要“姓名”、“性别”、“出生年月”、“家庭地址”、“入

33、学时间”、“系别”、“专业”等属性；而“课程”实体的描述属性除了“课程号”属性以外，还需要“课程名”、“学时数”、“学分”、“开设学期”、“课程类型”（必修或选修）等属性。,联系本身也可以有描述属性。,局部ER模型的设计,局部ER模型的设计,5. ER模型的操作 在数据库设计过程中，常常要对ER图进行种种变化。这种变化称为ER模型的操作，包括实体类型、联系类型和属性的分裂、合并、增删等。 例6.6 分裂方式有水平分裂和垂直分裂两种。把教师分裂成男教师与女教师两个实体类型，这是水平分裂。也可把教师中经常变化的属性组成一个实体类型，而把固定不变的属性组成另一个实体类型，这是垂直分裂 。,局部ER模

34、型的设计,联系类型分裂。 下图是教师担任教学任务的ER图，而“担任”联系类型可以分裂为“主讲”和“辅导”两个新的联系类型。,局部ER模型的设计,合并是分裂操作的逆过程。 例如，有一个“产品销售”实体，其属性有“产品号”和“销售额”，另一个“产品生产”实体，其属性有“产品号”和“产量”，把它们合并操作如以下图。,局部ER模型的设计,但必须注意，对于联系的合并，其类型必须是定义在相同的实体类型组合中，否则是不合法的合并，下图所示的合并就是不合法的合并。,局部ER模型的设计,例6.7 在人事管理系统中，社会关系的存在是以职工的存在为前提，即社会关系对于职工具有依赖联系。又如商业应用系统中，顾客地址与

35、顾客之间也有类似的联系(一般顾客可以有若干个联系地址)。,6. 弱实体与弱联系 在现实世界中，有时某些实体对于另一些实体具有很强的依赖联系，例如一个实体的存在必须以另一实体的存在为前提。 一个实体对于另一些实体具有很强的依赖联系，而且该实体主键的部分或全部从其依赖实体中获得，称该实体为弱实体。在ER模型中，弱实体用双线矩形框表示。与弱实体的联系，称为弱联系，用双线菱形框表示。,局部ER模型的设计,7. 子类和超类 子类和超类的概念最先出现在面向对象技术中。在现实世界中，实体类型之间可能存在着抽象与具体的联系。譬如学校人事系统中有人员、教师、学生、本科生和研究生等实体类型。这些概念之间，“人员”

36、是比“教师”、“学生”更为抽象，而“教师”、“学生”是比“人员”更为具体的概念。 当低层上较具体的实体类型表达了与之联系的较高层上的更为一般实体类型的特殊情况时，就称较高层上实体类型为超类型（supertype），简称超类；较低层上实体类型为子类型（subtype），简称子类。,局部ER模型的设计,子类和超类 性质： 子类与超类之间具有继承性特点，即子类实体继承超类实体的所有属性。但子类实体本身还可以包含比超类实体更多的属性。 继承性是通过子类实体和超类实体具有相同的实体标识符实现的。,局部ER模型的设计,在ER图中，超类以两端双线的矩形框表示，并用加圈的弧线与其子类相连，子类本身仍用普通矩形

37、框表示。 例如 学校人事管理系统中实体之间的联系可用图表示。相邻的上层实体称为超类实体，下层实体称为子类实体。譬如“学生”是“人员”的子类实体，但又是“本科生”和“研究生”的超类实体。,全局ER模型设计,全局ER模型的设计流程,全局ER模型的设计,所有局部ER模型都设计好后，接下来就是把它们综合成单一的全局概念结构。 1. 确定公共实体类型 确定各局部结构中的公共实体类型。当系统较大时，可能有很多局部模式，这些局部ER模型是由不同的设计人员确定的，问题有： 同一现实世界的对象可能给予不同的描述 ，有的作为实体类型，有的又作为联系类型或属性。 实体类型名和键也可能不同。 处理方法： 根据实体类型

38、名和键来认定公共实体类型。 把同名实体类型作为公共实体类型的一类候选。 把具有相同键的实体类型作为公共实体类型候选。,全局ER模型的设计,2. 局部ER模型的合并 合并的顺序有时会影响处理效率和结果。 合并原则是：首先进行两两合并；先合并那些现实世界中有联系的局部结构；合并从公共实体类型开始，最后再加入独立的局部结构。 进行两两合并是为了减少合并工作的复杂性； 合并原则是为了使合并结果的规模尽可能小。,全局ER模型的设计,3. 消除冲突 局部ER模型之间的不一致的地方，称之为冲突。 属性冲突 属性域的冲突，即属性值的类型、取值范围或取值集合不同。例如，重量单位有的用公斤，有的用克。,全局ER模

39、型的设计, 结构冲突 同一对象在不同应用中的不同抽象，类型有： 如职工，在某个应用中为实体，而在另一应用中为属性。 同一实体在不同局部ER图中属性组成不同，包括属性个数、次序等。 实体之间的联系在不同的局部ER图中呈现不同的类型。如实体E1与E2在某一应用中是多对多联系，而在另一应用中是一对多联系；又如在某一应用中实体E1与E2发生联系，而在另一应用中，实体E1、E2、E3三者之间有联系等等。,全局ER模型的设计,结构冲突解决方法： 对于同一对象在不同的局部ER模型中产生不同的抽象，其解决方式是：把属性变为实体或把实体变为属性，使同一对象具有相同的抽象。 对于同一个实体在不同ER模型中属性组成

40、不同，其解决方式为：取两个分ER模型属性的并，作为合并后的该实体属性。 对于实体间的相同联系呈现的不同的类型，其解决方式为：根据具体应用的语义，对实体键的联系作适当的综合或调整。,例6.8 在教务管理信息系统中的系，在某一局部ER模型中为学生实体的属性，而在另一局部ER模型中为一个单独的实体，其实学生和系之间存在从属关系，应该调整、合并为如图所示。,全局ER模型的设计,全局ER模型的设计,例6.9 在教务管理信息系统中的学生实体，在某一局部ER模型由学号、姓名、性别、所在系、所学专业组成，其ER模型如图 (a)所示。而在另一局部ER模型则由姓名、政治面貌、籍贯、家庭住址组成，其ER模型如图 (

41、b)所示，合并后如图 (c)所示。,例6.10 在工程管理系统中，产品与零件之间的多对多联系如图（a）所示。产品、零件和供应商三者实体间多对多联系如图（b）所示。因为它们的语义不同，所以不具有包含关系。将它们综合起来合并成如图的ER模型。,全局ER模型的设计,全局ER模型的设计,设计全局ER模型的目的不在于把若于局部ER模型形式上合并为一个ER 模型，而在于消除冲突，使之成为能够被全系统中所有用户共同理解和 接受的统一的概念模式。, 命名冲突 包括属性名、实体名、联系名之间的冲突。 同名异义，即不同意义的对象具有相同的名字； 异名同义，即同一意义的对象具有不同的名字。 属性冲突和命名冲突通常采

42、用讨论、协商等行政手段解决，结构冲突则要认真分析后才能解决。,全局ER模型的设计,4. 全局模式的优化 在得到全局ER模型后，为了提高数据库系统的效率，还应进一步依据处理需求对ER模型进行优化。 一个好的全局ER模型，除能准确、全面地反映用户功能需求外，还应满足下列条件： 实体类型的个数尽可能少； 实体类型所含属性个数尽可能少； 实体类型间无冗余联系。 这些条件不是绝对的，要视具体的信息需求与处理需求而定。,全局ER模型的设计,全局ER模型的优化原则： 相关实体类型的合并 这里的合并不是前面的“公共实体类型”的合并，而是指相关实体类型的合并。 一般在权衡利弊后可以把1:1联系的两个实体类型合并

43、。 具有相同键的实体类型常常是从不同角度刻画现实世界，如果经常需要同时处理这些实体类型，那么也有必要合并成一个实体类型。 但这时可能会产生大量空值，因此，要对存储代价、查询效率进行权衡。,全局ER模型的设计, 冗余属性的消除 在综合成全局ER模型后，可能产生全局范围内的冗余属性。 例如，在教育统计数据库的设计中，一个局部结构含有高校毕业生数、招生数、在校学生数和预计毕业生数；另一局部结构中含有在校学生数、分年级在校学生数、各专业在校学生数和各专业的预计毕业生数。各局部结构自身都无冗余，但综合成一个全局ER模型时，在校学生数即成为冗余属性，应予消除。 一般同一非键的属性出现在几个实体类型中，或者

44、一个属性值可从其他属性值导出，此时，应把这些冗余的属性从全局模式中去掉。 冗余属性消除与否，也取决于它对存储空间、访问效率和维护代价的影响。 有时为了兼顾访问效率，有意保留冗余属性。,全局ER模型的设计, 冗余联系的消除 在全局模式中可能存在有冗余的联系，通常利用规范化理论中函数依赖的概念消除冗余联系。 把所有局部ER模型综合成最终的全局概念结构应满足如下要求： 全局概念结构内部必须具有一致性，不再存在各种冲突； 全局概念结构能准确地反映原各局部视图结构，包括属性、实体及实体间的联系； 全局概念结构能满足需求分析阶段所确定的所有需求。 全局概念结构最终还应该提交给用户，征求用户和有关人员的意见

45、，进行评审、修改和调整，最后确定的全局概念结构为数据库的逻辑设计提供依据。,概念结构设计实例,实例1 教务管理信息系统的全局ER图。 教务管理信息系统（简化的）全局ER图是由学生学籍管理ER图、学生选课ER图、课程管理ER图以及成绩管理ER图组成。根据本章前面讨论的局部ER图，教务管理信息系统的全局ER图模式如图所示。,概念结构设计实例,实例2 某厂产品生产及库存综合管理系统的概念结构设计。 根据概念结构设计的步骤，先进行局部概念结构设计，然后再对各个局部概念进行综合。 局部概念结构设计 确定局部概念结构的设计范围。为讨论简单起见，对该综合管理系统进行了简化，只讨论产品的设计、生产和存储。 识

46、别实体与实体的主键。产品及库存综合管理系统识别出的实体应有以下几种：产品（主键：产品号或编号）、零件（主键：零件号）、材料（主键：材料名）、仓库（主键：仓库号）。 定义实体间的联系。 在技术部门的设计中，“产品”实体由“零件”实体组成，“零件”实体和“材料”实体通过消耗发生联系，而且都是多对多联系。可得技术部门局部模式图，如下图所示。,在生产部门的生产中，“产品”实体与“材料”实体通过“使用”联系在一起，而且是多对多联系。可得生产部门局部ER模型，如下图所示。,概念结构设计实例,在材料库存中，“材料”实体与“仓库”实体通过“存放”联系在一起。而且是多对多联系。可得工厂材料库存局部ER模型，如图

47、所示。, 给实体及联系加上描述属性 给实体和联系加上描述属性应根据具体的应用需求而定，本书的实例内容是简化的，在具体的系统设计中根据需求分析来确定。如下图 (a)、 (b)、 (c)分别是技术部门的ER图、生产部门的ER图、材料库存管理的ER图。,概念结构设计实例,概念结构设计实例, 全局概念结构设计 冲突问题 属性域冲突：属性值的类型、取值范围或取值集合不相同等。该例中没有涉及具体企业应用对象和实际数据，在实际应用时，可通过各部门或不同应用设计人员间相互讨论、协商的方式加以解决。 命名冲突：分析产品实体在两个不同应用中的属性描述，这里编号就是产品号，将两个不同应用部门关于该属性的名称统一称为

48、产品号。 结构冲突：显然，仓库对象在两个局部应用中具有不同的抽象，在生产部门作为材料实体的属性，而在仓库管理的局部ER模型中它是一个单独的实体，为使同一对象仓库具有相同的抽象，必须在合并时把仓库统一作为实体加以处理。本例中的另一个结构冲突，是产品实体在两个分ER模型中属性组成部分不同的问题，取分ER模型产品实体属性的并，然后统一属性名称，形成对产品实体新的描述，如下图所示。,在解决上述有关冲突后，综合各局部ER模型可形成如下图所示初步的全局ER模型。,概念结构设计实例,概念结构设计实例,冗余问题。分析该ER模型的数量属性可知，该初步ER模型存在着存放量、库存量、使用量等属性的冗余问题。消除这些

49、冗余后，我们可以得到下图所示的基本ER模型。,概念结构设计实例,概念结构设计实例,目前我们所产生的ER模型，仅仅是某企业工厂生产及材料库存管理的一个基本概念模式，它表示了用户的数据处理要求，是沟通用户需求和系统设计的桥梁。 要想把它确定下来作为最终概念模式，设计者还应提交给用户，并与用户反复讨论、研究，同时征求用户和有关人员的意见，进行评审、修改和优化等工作，在用户确认这一模式已正确无误地反映了他们的需求后，才能作为最终的数据库概念结构，进入下一阶段的数据库设计工作。,概念结构设计实例,实例分析： 某大学教务管理系统中包含三个部分： 教师管理子系统； 学籍管理子系统； 课程管理子系统。 在综合过程中： 学籍管理中的班主任和导师实际上也属于教师，可以将其与课程管理中的“教师”实体合并； 教师管理子系统中的实体项目“负责人”也属于“教师”，所以也可以合并。 注意：这里尽管实体可以合并，但联系依然存在。,局部模式,现有的教学 管理系统,