下载掌阅APP，畅读海量书库
立即打开
概念结构设计阶段所涉及的信息不依赖于任何实际实现时的环境，即计算机的硬件和软件系统。概念结构设计的目标是产生一个用户易于理解的，反映系统信息需求的整体数据库概念结构。概念结构设计的任务是，在需求分析中产生的需求说明书的基础上按照一定的方法抽象成满足应用需求的用户的信息结构，即通常所称的概念模型。概念结构的设计过程就是正确选择设计策略、设计方法和概念数据模型并加以实施的过程。
概念模型是现实世界到机器世界的一个过渡的中间层次，它有以下特点：
（1）概念模型有丰富的语义表达能力，能表达用户的各种需求，是对现实世界的抽象和概括，它真实、充分地反映了现实世界中事务与事务之间的联系，能满足用户对数据的处理要求。
（2）易于交流和理解。由于概念模型简洁、明晰、独立于机器，是数据库设计人员和用户之间的主要交流工具，因此可以用概念模型与不熟悉计算机的用户交换意见，使用户能积极参与数据库的设计工作，保证设计工作顺利进行。
（3）概念模型易于更改。当应用环境和应用要求发生变化时，能方便地对概念模型进行修改和扩充，以反映这些变化。
（4）概念模型很容易向关系、网状、层次等各种数据模型转换，易于导出与DBMS有关的逻辑模型。
概念数据模型的作用是：提供能够识别和理解系统要求的框架；为数据库提供一个说明性结构，作为设计数据库逻辑结构，即逻辑模型的基础。
概念模型的描述工具应该能够体现概念模型的特点，如E-R模型。近年来，由于面向对象数据模型具有更丰富的语义、更强的描述能力而越来越受到人们的重视，不但出现了商品化的面向对象DBMS，而且开始实际应用于概念模型的设计中，作为数据库概念设计的工具。Teory等人提出的扩展的E-R模型增加了类似面向对象数据模型中的普遍化和聚合等语义描述机制，为这种最为人们熟悉的数据模型注入了新的生机，为概念模型的描述增加了一种理想的选择。
概念结构的设计策略主要有自底向上、自顶向下、由里向外和混合策略。在具体实现设计目标时有两种极端的策略或方案，一是建立一个覆盖整个单位所有功能域的全局数据库，称之为全局方案或全局策略；另一种则是对每一个应用都建立一个单独的数据库，称之为应用方案或应用策略。
由于各个部门对于数据的需求和处理方法各不相同，对同一类数据的观点也可能不一样，它们有自己的视图，所以可以首先根据需求分析阶段产生的各个部门的数据流图和数据字典中的相关数据设计出各自的局部视图，然后进行视图集成。
在实体分析法中，局部视图设计的第一步是确定其所属的范围，即它所对应的用户组，然后对每个用户组建立一个仅由实体、联系及它们的标识码组成的局部信息结构（局部数据模式）框架，最后再加入有关的描述信息，形成完整的局部视图（局部数据模式）。这样做的目的是为了集中精力处理好用户数据需求的主要方面，避免因无关紧要的描述细节而影响局部信息结构的正确性。整个过程可分为4个步骤：确定局部视图的范围；识别实体及其标识；确定实体间的联系；分配实体及联系的属性。
（1）确定局部视图的范围。需求说明书中标明的用户视图范围可以作为确定局部视图范围的基本依据，但它通常与子模式范围相对应，有时因为过大而不利于局部信息结构的构造，故可根据情况修改，但也不宜分得过小，过小会造成局部视图的数量太大及大量的数据冗余和不一致性，给以后的视图集成带来很大的困难。
局部视图范围确定的基本原则是：
（2）识别实体及其标识。在需求分析中，人们已经初步地识别了各类实体、实体间的联系及描述其性质的数据元素，这些统称为数据对象，它们是进一步设计的基本素材。这一步的任务就是在确定的局部视图范围内，识别哪些数据对象作为局部视图的基本实体及其标识，并定义有关数据对象在E-R模型中的地位。
① 数据对象的分类。为了确定数据对象在局部E-R数据模型中的地位，首先必须对所有已识别的数据对象加以适当的分类，以便于根据它们所属的对象类来确定它们在相应局部E-R模型中的身份。数据对象分类的原则是同一类中的对象在概念上应该具有共性。如高校中的教师这个概念是指在职的教学人员，他们的性质由姓名、性别、出生年月、工作单位、职称、专业特长等数据项加以描述。因此，教授、副教授、讲师和助教均可归入教师这一类，但他们在概念上并不完全相同，除了共性之外，还各有其特殊部分，如教授、副教授有研究方向、指导研究生等描述项，职称也不一样。因此数据对象存在分类层次问题，为此可运用面向对象数据模型中子类与超类的概念。
② 识别实体与属性。建立局部E-R数据模型，还需识别每个对象类在局部E-R模型中的地位：实体、属性或联系。实体和属性之间在形式上的界限并不明显，常常是现实世界对它们已有的大体的自然区分，随应用环境的不同而不同。在给定的应用环境中区分实体和属性的总的原则是要在此应用环境中显得合理，且同一个对象类在同一局部视图内只能做一种成分，不能既是实体又是属性或联系。此外，为了对已给定的需求目标，更合理地确认局部E-R模型中的实体和属性，以便在逻辑设计阶段从E-R模型得到更接近于规范化的关系模型，可按下述一般规则来区分实体与属性：
希赛教育专家提示： 这一原则最好与存在性原则结合起来使用，如果将被描述对象删除后，描述项没有再存在的意义，则即使此描述项是多值的也不宜作为实体。例如，零件的颜色可以是多值的，但颜色离开了其描述的对象就没有单独存在的意义，因此还是作为属性为宜。
实体与属性的识别过程是个相互作用的反复过程，随着实体的确认，属性也将趋于明朗，反之亦然。在此过程中根据应用需求对已经识别的实体和属性做适当指派，发现问题再来调整，在识别过程中必须遵循前面所讲的总原则。
③ 对象的命名。在需求分析中得到的数据对象通常都是有名称的，但由于这些名称未经规范化，常常存在诸如同名异义、异名同义等许多命名上的冲突、不一致性及语义不清等问题，是造成数据不一致性及数据冗余的一个重要原因，此外，数据对象原有的名称有的过于冗长，给用户使用带来很大不便。为此，需要按一定的规范对每一类数据对象重新命名，给它指定一个简洁明了且唯一的名字，避免异义同名和异名同义存在，使每个对象名符合规范要求。
④ 确定实体的标识。实体的标识是能够唯一地标识一个实体的属性或属性组，也就是该实体的关键字。确定实体标识在实体识别与规范化命名之后进行，首先确定每个实体的候选关键字。一个实体可能有若干候选关键字，选择其中对有关用户最熟悉的一个候选关键字作为主关键字（或主码），并将每个实体的候选关键字、主关键字记入数据字典。
（3）确定实体间的联系。实际上，识别联系的主要任务是在需求分析阶段完成的。这里的工作一是从局部视图的角度进行一次审核，检查有无遗漏之处，二是确切地定义每一种联系。
在现实世界中，诸多形式的联系大致可分为三类：存在性联系、功能性联系和事件联系。存在性联系如学校有教师、教室有学生、工厂有产品、产品有顾客等；功能性联系如教师讲授课程、教师参与科研、仓库管理员管理仓库等；事件联系如学生借书、产品发运等。
根据上述分类仔细检查在给定的局部视图范围内是否有未识别的联系，在确认所有的联系都已识别并无遗漏之后，还需对联系进行正确的定义。定义联系就是对联系语义的仔细分析，识别联系的类型，确定实体在联系中的参与度。
① 二元联系的类型与定义。二元联系是指两个实体类之间的联系。根据参与联系的两个实体类值之间的对应关系分为一对一、一对多及多对多三种类型。对每一种联系类型，要确定实体在联系中的参与度，并以 m : n 的形式标在E-R图上要说明的实体旁，若 m >0，表明该实体参与联系是强制性的，若 m ＝0则是非强制性的。下面分别讨论上述三类联系的定义，以及另一种二元联系——实体类内部的联系。
（a）两类实体都是强制性的。假如规定每个工程师一定要负责一项工程，每项工程也一定要有一位工程师负责，便属于此种情况。如果工程师的标识为职工号，工程的标识为工程号，对于工程师与工程间的1：1联系，可用职工号或工程号作为标识。
（b）其中仅有一类实体是强制性的。若规定每项工程必须由一名工程师负责，但并不是所有工程师都必须负责一项工程（因为有可能没有那么多工程），此时，每一项工程一定对应着唯一负责联系，所以工程号可用作联系的标识。
（c）两类实体均为非强制性的。如工程师不一定安排负责管理工程，有的工程项目暂时可以不安排工程师负责管理，这种情况表示凡分到工程项目的工程师与工程项目之间总存在一一对应的联系，因此职工号或工程号均可选为负责联系的标识，定了其中一个为标识，另一个就作为候选关键字。
（a）“多”端的实体是强制性的。此时，每个学生必须归属某个专业，即每个学生都有一个确定的专业，但每个专业都不唯一地对应一个学生，故可以选择学号作为联系的标识。
（b）“多”端的实体是非强制性的。对本例而言是指有些学生（如新生）不属于任何专业的情况。此时实际上仅表示已经分配专业的学生与专业之间的联系，对这些学生中的每一个都有一个确定的专业，因此，应以学号作为联系的标识，而专业代号只作为联系的一般属性。
若略去实体与其属性图，以上实体间的二元联系可用图2-6表示。
图2-6 实体间的二元联系
② 多元联系的识别与定义。两个以上的实体类之间的联系称为多元联系。例如在供应商向工程供应零件这类事件中，如果任一供应商可向任一工程供应任一种零件，则为了确定哪个供应商向哪个工程供应了何种零件，就必须定义一个三元联系，因为只有供应商、工程及零件三者一起才能唯一地确定一个联系值。其联系的标识由参与联系的实体类的标识拼接而成，在此例中由供应商、工程、零件三个实体类的标识拼接而成。
希赛教育专家提示： 涉及多个实体的事件是否属于多元联系完全取决于问题的语义，不可一概而论。例如，如果上例中的问题说明变成每个工程需要订购一定的零件，而任一供应商可向任一工程供应零件。这里有两层意思，一是只有工程定了才能确定订购的零件，二是只有供应商及工程确定了，才能确定一个供应关系。根据这一情况，应定义两个二元联系，如图2-7（a）所示。
假如问题的说明是任一个供应商向任一项工程供应零件，但某个供应商向某项工程供应的零件是一定的，则在供应商与工程之间的关系确定后，供应的零件也就确定了。由此可知，只需定义一个二元联系就可以，如图2-7（b）所示，其中供应的零件作为供应联系的一个属性。
图2-7 多元联系示例
总之，具体问题应该具体分析，以便使定义的模式确切地表达问题的语义。
③ 消除冗余联系。若出现两个或两个以上的联系表示的是同一概念，则存在着冗余的联系，具有冗余联系的E-R模型转换为关系模型可能会得到非规范化的关系，因此必须予以消除。
出现冗余联系的一个重要原因是存在传递联系。例如，图2-8中表示了产品与零件之间的“组成”联系，零件与材料之间的“消耗”联系及产品与材料间的“使用”联系。其中，材料与零件间的联系是1： n ，零件与产品之间的组成联系是 n : m ，其实由这两个联系必然得出产品与材料之间的使用联系 m : n 。因此，图中产品与材料间的联系是冗余的，应将其去掉。
图2-8 冗余联系示例
④ 警惕连接陷阱。连接陷阱是一种存在语义缺陷的联系结构，它是由于在定义联系过程中对语义的理解出现偏差而造成的，因而无法由它得到需要的信息。连接陷阱可分为扇形陷阱、断层陷阱和深层的扇形陷阱三种情况：
图2-9 扇形陷阱示例
图2-10 深层的扇形陷阱示例
图2-11（a）是对它的一种改进，在其中增加了一个教师与课题的联系。该联系结构能确切地提供：“教师1指导学生1参与课题1”，“教师2指导学生2参与课题1”的信息，但从此图无法确定教师1指导学生2参与了哪一个课题。对教师2和学生1也是如此，因为参加课题1或2均是正确的语义。之所以如此，原因在于新增加的教师与课题间的多对多联系带来了两个新的双扇形结构，即以教师为中心的及以课题为中心的双扇形结构。增加的新联系虽然消除了原来的陷阱，却产生了新的陷阱。这类问题的有效解决办法是将三个实体间的联系定义成一个单一的三元联系，它的E-R模型如图2-11（b）所示。现在，每一个联系值唯一地确定了另一个联系值，从中可获得哪位教师指导某学生参加哪一课题的确定信息。可见问题的实质是对于应该定义成三元联系的问题千万不能用二元联系代替。
图2-11 深层的扇形陷阱示例的改进
（4）分配实体及联系的属性。在需求分析中收集的数据对象集内，除去已识别的实体、联系及标识外，剩下的主要是非标识属性。问题的实质就是将这些非标识属性恰当地分配给有关实体或联系。不过分配这些属性时，应避免使用用户不易理解的属性间的函数依赖关系及其有关准则，而应该从用户需求的概念上去识别框架中实体或联系必须有的描述属性，并按下述两条原则分配属性。
① 非空值原则。所谓非空值原则是指当一个属性的分配在几个实体或联系中可以选择时，应避免使属性值出现空值的分配方案。例如在前面曾经讲过的工程师负责工程的模式中，其联系是一对一且两个实体类均属非强制性的情况，现有一个属性项“施工期限”，按依赖关系考虑可加给工程师、工程或负责联系三者中的任何一个，因为工程师与工程在这里是一对一的联系，工程师定了，工程的施工期限也就定了。但有的工程师可能没有分配到负责工程的任务，若把施工期限作为工程师的属性，在此情况下便会出现空值；若作为工程的属性，则工程可能还未纳入计划，也会出现空值，可见将“施工期限”分配给负责联系最为适宜。
② 增加一个新的实体或联系。在分配属性过程中，有时会出现有的数据项在框架模式中似乎找不到适合依附的实体或联系。对于这种情况，常常可通过在原模式中增加一个新的实体或联系得以解决。例如，图2-12表示一个病区/病人模式，这是一个一对多，且“多”端为强制性的联系，在所有明显的属性均已分配完后，尚有属性项手术名及手术号待分配。这里手术名依赖于手术号，一个病人可能接受多种手术，一个病区可能接纳不同种手术的病人。在此情况下，手术号与手术名两个数据项不论作为哪个实体或联系的属性均不合适，为此可以在原来的模式中增加一个新的实体——手术，再加一个病人与手术的联系就可以了，如图2-13所示。
图2-12 病区/病人模式
按上述属性分配原则建立的模式将有利于转换成规范化的关系模型。
图2-13 在原来的模式中增加一个新的实体
视图集成就是要将反映各用户组数据的局部数据模式综合成单位中某个确定范围内的单一数据视图，即全局数据模式，又称模式汇总。该全局数据模式是未来数据库结构的基础，因此视图集成是数据库设计过程中一个十分重要的步骤，也是一项较为复杂和困难的任务。当所有局部视图设计完毕，就可开始视图集成。
（1）视图集成的原理和策略
视图集成的实质是所有局部视图的统一与合并，在此过程中主要使用了三个基本概念：等同、聚合和普遍化。基于这三个概念，有三种相应的基本集成方法。
① 等同。等同又称一致性合并，是指如果两个或多个数据对象具有相同的语义，则把它们归并为同一个对象，以消除不一致性，而不管它们的名字原来是否相同；同样，如果两个对象有相同的名字，但表示不同的对象，则应通过改名把它们区分开来。
等同包括简单数据对象间的等同和多个数据对象的聚合与另外几个数据对象聚合之间的等同。等同的数据对象其语法表示形式不一定相同，它与通常所说的同义异名是一个概念。识别等同时还要注意鉴别同名异义和语义相同但值域不同两种情况。同名异义虽有相同的表示形式，但语义却不同。等同的概念貌似简单，但在实践中要做出判断却并不容易，需做仔细分析，主要依靠对有关数据对象类值域的分析比较。
② 聚合。聚合表示和数据对象间的一种组成关系，例如数据对象学生可看成是学号、姓名、性别、年龄、系别、学籍、专业等数据元素的聚合。聚合集成主要用于实体的属性分配，有关的思想和方法请参看前面的实体分析法。
③ 泛化。泛化是对某一概念范围内具有共性对象的一种抽象。在视图集成中，它用于对现实世界中的事物进行归类。虽然泛化和聚合均表示事物的层次结构，且同一个数据对象可能同时参与泛化和聚合两种联系，但它们是两个截然不同的概念。聚合是将若干不同类型的数据对象组合成一个高级对象的过程，而泛化是按某公共属性的值对事物进行抽象和归类的过程。
综合地运用上述三种方法可有效地进行视图的集成。
视图集成从策略上可分成两类：二元集成和 n （ n >2）元集成。每一类又有两种可能的集成方式：二元集成分为平衡式和阶梯式， n 元集成分为一次集成与多次集成，因而总共有4种可能的集成方案，如图2-14所示。
图2-14 视图集成的策略
① 平衡式集成。这种集成方式是把整个集成过程分成若干层次，在每层中进行两两集成，其结果进入下一层集成，集成的对数逐层减少，最后得到统一的视图。Teory和Fry等人证明，只要选择恰当的集成初始序列，就有可能使这种集成的分析比较次数达到最少。两个分别具有 n 和 m 个对象的视图，其集成结果，在不考虑聚合和分解引起的增减的情况下，可能有 n + m - x 个对象，其中 x 为视图间对象的重叠度，若两个视图中有 i 个对象等同，则 x = i - 1。为了最大限度地减少在后面的集成中涉及的对象数，选择初始集成序列时应使每对集成视图的 x 值尽可能地大，若在每个集成层次上均按此原则进行，则就可能使总的集成效率达到最高。只有当配对的是关系极为密切的视图，即对应于事务处理中联系最紧密的功能域时，才能使配对视图中的 x 值为最大。由此可见，确定视图初始集成序列中的分组原则与划定局部范围的原则是一致的，因而有关的方法也是可参照使用的。
② 阶梯式集成。是一种流水线作业形式的集成方式，它无须考虑视图的初始序列，当然也不保证x值为最大，但省去了进行处理的麻烦，且这种方案适合同已经存在的局部集成模式进行综合。数据库的应用范围常常随着单位的发展而需要逐步扩展，扩展的每一种功能所涉及的数据，通常与已经集成的数据模式关联最为密切，而阶梯式集成为这种情况提供了最为适宜的策略。
由以上可知，二元集成是一种较简单且行之有效的策略。它的优点在于可使每个集成步骤上的分析比较过程简单化和一致化，因而使用较广泛。它的主要缺点是集成操作的总次数较多，且在最后必须分析检查是否满足总体性能，必要时需做调整。
③ 一次集成。一次集成 n 个视图。其优点是能充分地考虑全局需求，不必到最后再来分析调整，且集成操作次数少。缺点是集成效率将随着视图数及视图中对象数的增加而明显降低，因为集成过程中的基本操作是等同性检查，一次集成 n 个视图，为了判别一个视图中单个数据对象的等同性，必须与其他 n - 1个视图中的每个数据对象进行比较，所以只有当 n 较小时，这种策略才有意义。
④ 多次集成。先用与平衡式二元集成相同的机理，将待集成的视图分成若干组，每组的视图数可以是两个或多个，但个数不能太多，然后按组集成，形成若干中间视图，再对这些中间视图进行分组、集成，最后得到全局视图。它的优点是，具有平衡式二元集成法效率较高的优点，集成操作的总次数较少，其次，其分层的集成过程在概念上正好与大多数具有层次功能结构的事务单位相吻合。事务管理人员可凭借其丰富的事务知识有效地进行低层次集成；单位中高级管理人员具有的综合知识及全局观点，有利于运用聚合或普遍化概念进行高层次上的集成。此策略的效果同样取决于初始集成序列的划分。它的缺点是一致性差。
（2）视图集成的方法和步骤
局部视图集成是一个相当困难的工作，往往必须凭设计者的经验与技巧才能很好地完成。尽管如此，集成的方法很多，它因所用的概念设计数据模型、集成策略、集成过程的输入/输出量及识别和解决冲突的方法的不同而各有其独特的执行过程，但总的来说都分成两个阶段：预集成阶段和集成阶段。
① 预集成阶段。确定总的集成策略，包括视图集成的优先次序、一次集成的视图数及初始集成序列等；检查集成过程要用到的信息是否齐全；揭示和解决冲突，为下阶段的视图归并奠定基础。
② 集成阶段。集成阶段的主要任务是归并和重构局部视图，最后得到统一的全局视图。全局视图需满足以下要求：
一个视图的集成主要是实体与联系的集成，整个集成过程也就是这两类基本集成过程反复交替执行的过程。
（3）冲突的发现与解决
冲突的表现和处理策略如下：
① 同名异义。为了发现不同视图间的同名异义问题，可以列出所有同名数据对象，然后逐一判别其语义。对同名异义冲突通常采用换名加以解决，既可对同名者之一换名，也可对两者都给以重新命名。识别语义的主要方法是进行值域分析。
② 异名同义。识别异名同义比较困难，一般由设计者对所有对象一个不漏地逐一鉴别。它同样采用换名的方法解决。若归并时试图将它们合并为一个对象，则可以把其中之一的名称作为合并后的对象名；若集成后，它们仍以两个不同的对象存在，则可对其一换名。当然，若原名都不合适，则可以对两者都重新命名。
③ 同名不同层次。如果两个对象同名，但其中之一是作为一个视图中的实体，而另一个是另一视图中的属性，则在集成时就会发生同名不同层次的冲突。解决这种冲突的办法有两个，一是将属性转换为实体，二是将实体变换成属性。
例如，设一局部视图中有一部门实体DEPT，而在另一与之集成的视图中有职工实体EMP，且EMP有属性DEPT，于是发生了同名不同层次的冲突。此时，可将EMP的DEPT属性去掉，另设一个实体DEPT与EMP建立联系，这时再与另一视图集成就容易多了。
再如，设一局部视图中有一名为STOR的仓库实体，其中含有一属性部门号（DEPT-NO）；在另一局部视图中有一单位实体DEPT，其中仅含有一个属性DEPT-NO。对这类同名不同层次的冲突，可将DEPT实体变换为其所在视图中与DEPT相关的另一实体的属性，然后再进行集成。
希赛教育专家提示： 实体变换为属性时通常要满足一些特定条件，例如，该实体通常只含有一个与同名属性具有共同特征的属性，且一定存在一个与该实体存在联系的另外的实体。
④ 虽同名同义，但对象联系测度不同。所谓联系测度是指实体的联系是一对一、一对多还是多对多。若同名同义对象在一个局部视图中为一对多联系，在另一局部视图中为多对多联系，则在集成时将发生联系测度冲突。一般而言，一对多包含一对一，多对多包含一对多。所以解决这种冲突的方法往往取较高测度为集成后的相应联系的测度。
⑤ 数据特征不相容。如果一同名同义属性在一局部视图中可作为关键字属性，但在另一局部视图中不具有关键字属性特征；或者，如果一组属性在不同视图中具有相反的相互依赖关系。这两种情况均会发生数据特征不相容冲突。对于第一种不相容冲突，集成时往往需要重新选择关键字；关于第二种不相容冲突，解决的策略则依赖于实际应用环境。例如设在两个不同局部视图中都含有课程和教室属性。其中之一存在课程决定教室的属性依赖关系；而在另一局部视图中课程与教室的依赖关系刚好相反。当将这两个属性集成到一个实体中时，其间原有的这种对应联系将不存在。此时，若这种联系的丢失不产生影响，则集成可正常进行。但如同第一种冲突，有时可能要重新指定关键字，而且，有时第二种冲突也可能具有第一种冲突的特征，本例就可能是这种情况。
不相容冲突因不同的环境而可能有多种不同的形式，应根据具体情况采用不同策略加以灵活处理。
另一类貌似不等同但通过适当映射可转化为等同的数据对象，称为等价的数据对象类。通常有两种等价情况：
① 用不同的名称和值域描述同一种事物。例如，出生日期（日期型）与年龄（整型）、职工号（字符型）与工作证号（整型）等。
② 用不同的度量单位度量同一事物。对于“重量”、“长度”等度量属性都可能出现这一情况。如对于一个物品的重量单位在一个视图中定义为吨，而在另外的视图中定义为公斤。这两种情况实质是用不同的形式来描述同一事物或概念，这种描述同一事物或概念的数据对象类称为等价数据对象类。这些等价数据对象类之间可以按一定的规则映射，如出生日期与年龄之间，吨与公斤之间都可按公式进行相互转换，对那些没有确定的规则可循的等价数据对象类之间的映射可用对照表加以实现。
等价数据对象类是由于各个用户组对数据对象的观点不同而造成的。它们可以通过映射转化为等同数据类，然后再按等同数据对象进行集成。所以在集成前应仔细识别所有等价数据对象类，并确切说明它们之间的映射。
一个数据对象类所有可能的实例的集合称为该对象类的值域，或简称为域。数据对象类的值域是分析该数据对象类语义的重要依据，是识别各个视图中数据对象类在所讨论的概念上是等同、有共性或不相干的主要依据。因此仔细定义每个数据对象的值域是识别来自不同视图的数据对象类是否等同的主要手段。假如用Dom（A）表示对象类A的值域，各对象类在值域上存在四种相关情况：
域等同：Dom（A）=Dom（B）。
域包含：Dom（A）
Dom（B）或Dom（B）
Dom（A）。
域重叠：Dom（A）∩Dom（B）≠φ。
域分离；Dom（A）∩Dom（B）=φ。
对所有数据对象按上述四种值域相关情况归类后，便可用不同的方法对实体类进行集成。
（4）实体类的集成
下面按照前面定义的四种值域相关情况，采用二元集成策略，对各视图中的实体类进行集成。为了方便起见，用大写字母，如A、B等表示实体类，用Attrs（A）表示实体类A的属性。
① 域等同。A和B是来自不同视图的两个实体，如果它们的值域等同，则集成过程就是建立一个单一的实体类，设为C，作为全局模式中的实体类，其属性Attrs （C）为A和B的属性之并，值域等同于A或B的值。因此，在这种情况下，集成操作就变成了求并操作，可表示为：
Attrs（C）：=Attrs（A）∪Attrs（B）
Dom（C）：=Dom（A）（或Dom（B））
② 域包含。若两个实体类A和B，有Dom（A） ⊆ Dom（B），即实体类A是实体类B的子集，在集成模式中把实体类B换名为B 1 ，并建立一个新的实体类A 1 代替视图中的实体类A，实体类A 1 的属性是实体类A的属性与实体类B的属性的差集，即去掉A与B中相同的那部分属性，而仅保留A中不同于B中的那部分属性。A 1 与A、B的关系及B 1 与B的关系可表示成：
Attrs（B 1 ）：=Attrs（B）
Attrs（A 1 ）：=Attrs（A） - Attrs（B）
Dom（A 1 ）：=Dom（A）
Dom（B 1 ）：=Dom（B）
③ 域重叠。属于这种情况的实体类A和B，不仅存在部分公共属性，且两个实体类中的部分实例是重叠的。例如，一个工厂中参加业余大学学习的职工在不同视图中被表示成学生和职工两个实体类，但业余大学的学生具有学生和职工双重身份，是它们域的重叠部分。对这类实体的集成方法是，在全局模式中建立三个实体类，一是A、B两实体的联合，表示为AB，其域是A、B的域的并集，包含了A、B的所有实例，属性则为这两类实体的属性的交集，是A和B的公共属性；另外，两个实体记为A 1 和B 1 ，是AB实体集的两个子集，其域分别等同于A和B的域，而它们的属性分别为A、B的属性中不在AB中出现的那部分。
④ 域分离。设A和B是来自不同视图的两个实体类，如果它们之间存在下述情况之一，则归入域分离集成方法。一是A和B存在某些共性，但它们的实例在所关心的概念上是不相关的；二是两者虽然不存在公共实例，但可统一于某个有意义的概念，第一种情况如教授与研究生，两者虽然有系名、姓名、年龄、住址等相同的属性，但在通常意义上，它们的值域不可能等同、包含或重叠。对于这种情况，集成时不必对它们进行归并，按原样转入全局模式。对于第二种情况可引入普遍化机制进行概念集成。在集成的全局模式中建立三个实体类A 1 、B 1 和C，其中A 1 、B 1 对应于局部视图中的实体类A和B，而C则对应于A和B的普遍化概念。全局模式和局部模式间属性和域的关系与域重叠的情况相同。
对于来自 n 个视图的 n 个实体类（A 1 ，A 2 ，……，A n ），其集成过程可以重复采用二元集成策略，对某些域关系可采用 n 元集成。
（5）联系类的集成
联系类集成是通过语义分析来归并和调整来自不同视图的联系结构。联系的语义主要由联系的元数、实体在联系中的角色和参与度及联系的值域等表示。根据待集成联系类的元数和实体在联系中所起角色的异同，可将联系类的集成分成三种类型八种情况。下面对它们逐一进行讨论。
① 元数和角色相同联系类的集成
情况1：实体的参与度相同。集成这类联系类时，通常只需将其中任一联系类原样转入全局模式即可，并根据情况对实体类和属性做简单的归并处理。例如，图2-15（a）表示来自视图V 1 、V 2 的两个联系类，除了左端的实体不同外，其他的符合前面所讲的情况。由于左边的两个实体类的域是不相交的，可进行普遍化集成，且可能已在实体集成中识别。图2-15（b）是其集成结果。
图2-15 情况1示例
情况2：实体的参与度不同。这种情况表明，尽管联系的元数和实体在联系中担任的角色相同，但实体在不同视图中参与该联系的程度并不相同，即该联系类在不同的视图中所受的结构制约不同。对这类联系的集成，通常引入一个子集结构来协调两者在参与度上的差异。例如，教师与课程间的联系可能有两种观点，一是担任教学任务的观点，二是工作量统计的观点。按第一种观点，教师可能不担任任何教学任务，但从第二种观点看，每个教师至少担任一门课程的教学任务。所以在两种不同观点的授课联系中，教师的参与度是不同的。在集成时可引入“任课教师”作为教师实体类的一个子集，以统一参与度，从而可将两个联系在全局模式中归并为一个联系。
② 相同元数，不同角色联系的集成
情况3：域包含。域包含指一个视图中的一个联系类为另一视图中的一个联系类的子集。例如教师与项目的联系，在一个视图中为“参与”联系，而在另一视图中可能就是“领导”联系，两个联系中的实体类相同，但在其中充当的角色却不同。但如果事务规则说明项目的领导者一定是项目的参与者，则“领导”联系类便是“参与”联系类的一个子集，也就是“领导”联系中的所有<教师，项目>实体对一定包含在“参与”联系的实体对集合＜教师，项目＞中。这种联系类的子集关系的语义制约是：当加入一个新的“领导”联系实例时，它必须同时加入“参与”联系，对于删除操作也是如此。
情况4：域分离。在这种情况下，参与两个不同视图中联系类的实体虽然相同，但它们表示的却是通常意义上互不相干的两件事。集成时，它们会变成全局模式中两个实体类间的两个联系。
情况5：域重叠。这种情况下的两个联系类的域之间有重叠部分，即一个联系类的某些实例同时也是另一个联系类的实例，但两个联系类的域不是包含关系。集成时，在全局模式中，两个视图中相同的实体类两两合二为一，并在两个实体类之间建立三个联系，两个为集成前的原有联系，另一个为包含前两个联系类实例的父集，与原有联系构成一个子集层次结构。例如教师与研究生之间，可能有上课和指导两种不同的联系。如果指导研究生论文的教师也要给研究生上课，则两个联系的实例就有重叠部分（假定不是所有上课的教师都指导论文）。
③ 不同元数联系的集成
情况6：可归并的不同元数的联系类。如果两个元数不同的联系类存在语义上的等价性，即它们实质上表示了相同的信息，则此两联系类是可归并的。通常总是将元数较多的联系类转入全局模式。因此，仔细地鉴别两个不同元数的联系类是能否归并的关键。例如图2-16中机器与零件之间的联系，在视图V 1 中以“组成”作为联系类，在视图V 2 中则以“包含”表示一个机器所包含的零件；实际上V 2 的联系可由V 1 导出，所以，只需把V 1 中的联系类转入全局模式即可。
图2-16 机器与零件之间的联系
情况7：有条件可归并的联系类。这是指在某些条件成立的前提下，元数较少的联系类，可以从元数较多的联系类导出的情况。换句话说，这种情况比情况6多了一个限制条件——可导出性条件。因此，集成这两个类的关键是识别元数较少的联系类从元数较多的联系类导出的条件，一旦识别成功，就可按情况6所述可归并联系相同的方法进行处理，即将元数较多的联系类移入全局模式。例如在图2-17中，V 1 表示了工程向供应商购买部件的联系，V 2 也表示了类似的联系，为了确定此两者是否可归并，首先要分析可归并的条件，如果V 2 的联系中＜工程，部件＞与＜供应商＞之间保持一对一的关系，而且R 1 中供应商的所有属性都包含在R 2 中，则该两个联系类是等价的，可以合并，按照可归并联系类的集成原则，将元数较多的V 1 中的联系类移入全局模式。
图2-17 工程向供应商购买零件的联系
情况8：不可归并的联系类。如果两个联系类具有完全不同的语义，无法通过增加对联系类的结构制约或语义制约而使它们兼容，则它们是不可归并的，集成时只能照原样分别转入全局模式中。例如设在视图V 1 中有教师指导研究生参加课题研究的三元联系（在V 2 中另有一个教师管理课题的联系），如图2-18所示。如果教师指导研究生所参加的课题和教师所管理的课题并不一致，则此两种联系类所表达的语义是互不相干的，因而也就不能进行合并，只能照原样移入全局模式中。
图2-18 教师、研究生、课题之间的联系
（6）新老数据模式的集成
当需要对已经建立的数据库系统进行扩充、修改，以扩大其应用范围，满足企业业务上发展的需要时，就会出现新老数据模式的集成问题。
① 原有系统为多个独立数据库时的集成。这种情况下的集成包括单个数据库的集成和扩充的数据模式的集成。由于这些独立的数据库仅仅各自反映单个用户组的需求，而且很可能是在不同时期由不同的设计人员设计的，因而这些数据库之间及其和扩充的数据模式之间，必然地存在许多冲突和冗余。把它们集成为一个能支持所有应用，并能保证数据的一致性、完整性及最小冗余的全局模式后，原有的应用程序很可能都不能运行。因此，事前需要有周密的计划，原则是既要满足新的需要，又要尽可能地保持原来的数据模式，以便原有的应用程序稍做改动后仍能运行。
② 原有系统为单一的综合数据库时的集成。这时原有的数据模式已是经过集成的数据模式，再和扩充部分集成时，应尽量向原模式靠拢，以使得原数据库支持的应用程序基本不变。
进行新老数据模式集成时，首先必须理解原有数据模式。如果原有数据库未留下概念设计的文档，那么就得从分析模式入手，这一过程不但十分困难和烦琐，而且容易出错或遗漏。因此，对于比较复杂的数据模式，最好先将逻辑模式翻译成相应的E-R图，将其与用户交互，确认新的需求，根据用户意见，对E-R模式进行调整，形成新的用户视图，然后再按前面所述的方法集成。可见，新老数据模式的集成比之全新的视图集成受到的限制更多，因此，在某种意义来说也更加困难。