目前存在3条实现数据集成管理的技术路线，其核心是：提供一种通用、灵活、能管理各类型数据的机制，而这些数据可能是结构化的数值数据，或图形数据、声音、NC代码，甚至是目前未知的数据类型。这3条技术路线是：
（1）开发能集成管理以上各类数据的数据库管理系统（DBMS），目前研究的重点是面向对象的数据库管理系统（OODBMS）。面向对象的方法是一种适合人们思维习惯的自然方法。OODBMS具有建模能力极强的优点，它是在CAD、CASE（计算机辅助软件工程）、CAI（计算机辅助教学）、CAM、OIS（业务信息系统）、超文本、多媒体应用领域发展起来的，在这些应用领域中要处理结构复杂、类型各异的数据。概括起来，这些新的需求包括：
a.存储和处理各种复杂对象，这些复杂对象往往是层次结构的，很难用普通的平行结构表示，而且还有对象共享的要求；
b.需要支持新的数据类型和操作，支持抽象数据类型和用户定义类型的可扩展能力；
c.需要更多的语义概念，例如泛化关系和聚类关系；
d.支持多介质数据处理，例如超长正文数据、图形/图像数据、声音数据等。
因此，人们将面向对象的概念和机制引入到数据库系统。显然，在企业信息集成的环境下，面向对象的数据库系统可以更好地支持企业信息集成的需要，但是，目前建立在面向对象数据库基础上的应用系统非常少，要购买一个面向对象的数据库管理系统来支持信息集成暂时还不可能实现。
（2）在开放系统结构下，通过当前各种数据库系统的开放性，来实现各种数据源的有机集成。
（3）在原有系统的基础上研制多数据库（multi- database）系统。多数据库系统强调系统之间的自治性和互操作性，能充分利用原有系统的资源。
5.2.4.2开放性和数据集成
在企业级信息集成的环境下，要对多种数据源进行集成，系统必须有开放性。
开放性主要体现在以下几方面：
（1）系统对数据载体的开放
在企业级信息集成的环境下，共享数据存储在不同的数据存储环境中，其数据存储载体可能是关系库、网状库、层次库、对象库，甚至是文件系统。系统应能对以不同存储形式存储在不同介质上的数据进行访问和更新。另外，有的数据载体是在系统集成以前就存在并且还要继续使用，有的数据载体是在系统集成时增加的，甚至有的数据载体是在系统集成以后新增的。因此，系统应该能对数据载体的切换提供开放性。
（2）系统对数据持续性的开放
在企业信息集成的环境下共享的数据可能在系统建立前后定义，因此，系统应该具有对已有数据的兼容能力，并且让用户同时很方便地使用它们。
（3）系统对用户接口的开放
在企业信息化环境中，不同的应用子系统对系统中异构和分布数据的使用方式是不同的，在系统中不仅存在大量常规数据，还存在大量工程数据。这些数据的类型、结构、数据间的语义联系都不尽相同，而且，对工程数据的操作具有一些特殊要求。因此，系统应该具有对不同结构数据表达的处理能力，提供支持不同应用环境和不同操作方式的友好用户界面。另外，有时用户希望保持在系统集成前的使用风格，因此，系统应该对不同数据结构的表达和处理、不同操作方式的友好用户实现开放。
（4）系统对结构的开放
在企业信息集成中，典型的异构分布数据库系统的互连应该是多层的，每层的功能、模型、模式、语言、数据格式都应在协议中有详细的说明和定义。系统结构设计依照这些规范和标准按组件的设计思想设计成一个插件式系统，这样就能针对不同的企业环境，对系统以组件为单位进行修改和调整，并根据环境中各站点的负载情况，合理调配各组件在系统中的分布以及模块之间的关系，以形成满足该应用特点的高效实用系统。
（5）系统对分布环境的开放
在企业信息化过程中，不同的企业应用环境提供的异构分布数据库的分布环境是不同的，其中既有操作系统环境的不同，又有网络环境和硬件环境的不同。系统设计中应充分考虑并尽量满足这种分布环境的不同，提供对分布环境的开放。
（6）系统对功能的开放
在企业信息化环境中，不同的应用子系统要求提供的数据服务功能完全不同。
因此，系统不仅应该提供通用的数据服务功能，还应该提供为特定用户或特殊应用增加的特殊数据服务功能的机制，实现系统数据服务功能的开放。另外，有些用户对系统的某些特定应用在一定范围内具有一定的通用性和一定的持久性，希望将其插入系统中作为系统实用例程的一部分。系统应该提供增加用户特定应用程序作为实用例程的机制。
在异构数据源的集成技术中，开放体系结构下的数据集成技术比较适合于从实用的角度来解决企业级和跨企业级的信息集成问题。从技术发展的趋势来看，C/S结构是一种典型的开放结构，在这种结构下采用的一些技术，例如中间件、开放式分布事务处理等，非常有利于异构数据源的透明集成。第5.3.3节将介绍C/S的结构。
5.2.4.3多数据库的集成技术
在对异构多数据库系统研究的初期，主要沿用同构分布式数据库系统的方法来进行数据集成，即对异构成员数据模式构造一个集成模式，把局部模式作为集成模式的逻辑视图。按照这种方法，系统有一个全局的数据模式和数据字典。任何一个局部视图的修改，都会导致全局数据模式的修改；一个结点加入或退出系统，也会引起全局模式的修改。因此，这种DBMS的结点缺乏自治性，难以管理，也难以集成。
1985年Heibigner和Mcleod提出了联邦式数据库系统（FDBS）结构，打开了异构分布式数据库走向实用化的大门。联邦式数据库采用了在物理上和逻辑上都分布而又可实现多数据库共享数据的体系结构，正是企业级和跨企业级信息集成所期望的目标之一。FDBS是在各成员数据库保持自治的条件下，可以协商合作的数据库系统。
FDBS应具有以下两个基本特点：
（1）成员自治性
FDBS中的每个成员独立于联邦系统，保持自己局部操作的特性，主要表现在每个成员有权决定自己的概念模式、数据操纵语言、局部操作顺序以及与其他成员联系的方式等。
（2）协商合作
FDBS中各成员数据库可以彼此合作，在此基础上能够互访（具有相应的透明性），从而达到资源共享的目的。
FDBS还没有国际统一的规范和标准。大家认为，逻辑上分布的分布式数据库系统的数据集成是FDBS的基础。
每个结点局部数据库的模式称为局部模式（LS）。在LS中，一部分数据是私有数据，不与其他结点共享。输出模式（ES）是LS提供给其他结点的共享数据，输入模式（IS）是接受外部数据的模式。每个结点的LS和IS构成该结点的逻辑数据模式，称为联邦模式（FS）。由于每个结点看到的是不同的逻辑数据模式，而不是惟一的全局数据模式，因而这种分布式数据库系统（DDBS）逻辑上也是分布的。各个结点上的数据库系统一般是异构的，从一个结点的ES到另一个结点的IS需要进行适当转换。结点之间的共享数据完全由双方协商解决。一个结点在加入系统时，开始可能共享的数据不多，随着应用的发展，通过双边协商逐步建立自己的输入、输出模式，从而形成本结点的FS。当一个结点要退出系统时，首先通知有关结点，结束数据共享关系，并相应地修改其IS，然后撤消本结点的IS和ES。这种形式数据库的集成、扩充和重新配置都比较自然及方便，不像逻辑上集中的DDBS那样，受制于全局数据模式。
为了实现逻辑上分布的数据集成，必须要解决以下两个问题：
（1）模式集成
模式集成是多数据库系统必须解决的首要问题之一。在FDBS中，不像其他分布式数据库那样，用一个公共集成模式来实现模式集成，它是在每个成员数据库概念模式的基础上，分布建立各自的输出模式和输入模式，并运用输出模式到输入模式的转换来实现FDBS之间的共享关系。
（2）查询分解及优化
由于FDBS中存在多种数据操纵语言，为了统一不同操纵语言，有必要设计一种便于系统实现、独立于各成员DBMS的中间语言。因此，对一个查询所进行的处理是在中间语言上进行的。在FDBS中，查询分解与优化对系统的运行效率有直接影响。对涉及库外关系的查询而言，必须减少内存操作和局部查询时间，同时要求减少数据在网络上的传输时间。
在FDBS的实现中，还有不少关键技术问题，例如联邦事务管理、中间语言设计、局部DBMS核心接口等。目前，FDBS研究不论在国内还是在国外都不够成熟，理论上和技术上都有大量工作需要完成。
5.3客户/服务器计算模式
5.3.1客户/服务器模式的起源和发展
虽然客户/服务器（C/S）模式是代表90年代的计算模式，但客户/服务器（client/server）这个概念在80年代初期就出现在软件界。它最早用于描述软件的体系结构，表达两个程序之间的关系，即一个程序为应用程序而另一个程序为其服务因而称为服务程序。随着微机和局域网的发展及分布式体系结构的建立，C/S概念被引入系统集成的环境中。与C/S模式相应的概念是集中式（centralized）和文件服务器（fileserver）。
集中式又称为主机/多终端方式。系统的所有程序都在主机上运行，所有数据都放在主机内。用户通过本地或远程终端访问主机。终端仅由屏幕、键盘以及与主机通信的设施组成，是哑终端。在企业使用计算机的初期，由于硬件价格昂贵，微机还没有出现，计算机的专业人员很少，只好采用这种运行模式。目前在少数企业仍然在使用集中式模式，这是企业信息集成的一个难点。
文件服务器模式是指数据集中存放而所有的应用处理和数据处理分散在最终用户所使用的微机一端。数据存放在文件服务器上，该服务器仅负责从服务器硬盘上查询所需的数据并通过网络发送给最终用户。最终用户的微机上有DBMS，负责处理来自服务器的数据文件。早期的Novell网就是典型的文件处理方式。
集中式和文件服务器在使用中暴露的问题，促使C/S模式的诞生。
首先来看集中式模式。集中式所采用的主机价格远比一群微机、工作站昂贵，维护费用高，对工作环境要求苛刻，还需要训练有素的专业人员。当微机、工作站的性能越来越强且价格越来越低时，开发人员开始考虑把大型机的工作分布到各个结点上，从而用微机群代替大、中型机。这一过程在西方被称为“规模下适化”（downsizing），它推动了C/S模式的发展。
其次来看文件服务器模式。当企业使用计算机越来越多时，部门相互传输的数据量日益增多，为了减轻LAN（局域网）的负荷，人们想到没有必要经网络传输全部数据文件。事实上，很多查询仅是几个数据或者几条记录，没有必要在网上传输整个文件。这就要求服务器一方具有处理能力，仅将处理结果经网络传送，因而文件服务器不仅存放文件而且还应有处理能力，于是发展成为C/S模式下的数据库服务器。这一过程在西方被称为“规模上适化”（upsizing）。
上述两个动力终于使C/S模式应运而生。在信息系统中应当合理地分布数据存储和数据处理，分布实际上是在分散（dispersed）和集中（centralized）之间的一种平衡。系统在逻辑上呈现为一个整体，而在物理上合理地分散。C/S模式就体现了这种“规模适化”（rightsizing）的思想。所以，C/S模式不仅改变了软硬件结构，而且体现了另一种思维方式。
5.3.2客户/服务器模式的含义
C/S是一种在分布式环境中的计算模式，其目的在于实现功能和资源的合理分配。在企业信息化工程中，它作为一种信息处理和集成技术而备受重视。事实上，我们不要把C/S与具体的计算机系统等同起来，虽然这样做有时可能会更加方便一些。从本质上看，C/S指的是进程之间“请求”和“服务”的合作关系。
C/S是一种合作关系，它是协同式的分布式计算，即客户和服务器分别承担一个计算任务的一部分，缺一不可。客户与服务器之间的合作关系不是固定的，多个客户可以共享一个服务器，一个客户也可以向多个服务器提出服务申请。同时，这种合作关系也可能是临时的，一旦它们之间的交互作用停止，合作关系便终止。
C/S的作用对象是进程，确切地说是两个进程，它们协同工作构成一个应用。
因此，客户和服务器进程所处的具体物理位置并不重要（位置透明），重要的是它们之间的协作关系。
客户与服务器关系的实质是请求和服务。客户向服务器发出服务请求，服务器根据客户的请求完成相应的任务，并将处理结果回送给客户。客户只需了解服务界面而不必知道服务的具体处理过程（服务封装）。客户与服务器之间的协作关系可以分为两类：紧耦合的请求/回答交互；基于队列机制的消息传输交互。
