异构数据库集成可以通过转换和标准化来实现。在异构数据库系统集成中要
解决平台和网络的透明性、数据模型的转换、模式转换和集成、分布式事务管理
等问题。
当前异构数据库系统集成主要采用三种策略:公共编程界面、公共数据库网
关和公共协议:它们都是基于客户/服务器体系结构的，这样可以综合各种计算机
协同工作.各尽其能，也可实现对计算机应用系统的规模优化和规模缩小化。公
共编程界面包括客户应用编程界面(CAPI)和服务器应用编程界面(SAPI);公共数
据库网关(G ateway)是一个转换器，客户通过它就可以访问异构数据库:公共协议
是指对客户和服务器间通讯的格式和协议(FAP，Fralne and Protocol)及对数据
库语言进行标准化。这是一种最理想的解决异构数据库系统集成的方法。
这三种策略在异构数据库系统集成中可以配合使用，并不互斥。从各种数据库产品所提供的异构数据库集成的主要机制来看，Gateway和API是当今集成异
构数据库的主要方法。当前一些主要的大型数据库厂商的新版本DBMS几乎都采
用了客户机/服务器(C/S)体系结构，强调对分布式功能的支持。它们都具有访问
异构数据库的能力，实现了异构集成，它们的不足之处是，其集成通常都是单向
的、主从式的，一种产品一般只提供从自己的DBMS访问异构数据库的机制和产
品。
下面将简单介绍异构数据库和数据的集成结构与方法【“】。
1.虚拟视图法
采用虚拟视图法实现的数据集成系统，当用户向该系统提交查询请求时，系
统根据命令操作数据源中的数据，所以称这种方法为Lazy方法。采用虚拟视图
法集成数据源主要有两种体系结构，一种是联邦数据库系统，另一种是Mediated
系统。
2.联邦数据库系统
联邦数据库系统(Fedrated Database System，FDBS)是由参与联邦的半自治
的数据库系统组成，目的是实现数据库系统间部分数据的共享。联邦中的每个数
据库的操作是独立于其它数据库和联邦的。之所以叫“半自治”是因为联邦中的
所有数据库都添加了彼此访问的接口。
联邦数据库系统分紧藕合FDBS和松藕合FDBS两种。
紧藕合FDBS有一个或几个统一的模式，这些模式可通过模式集成技术半自
动生成，也可通过用户手工构造。要解决逻辑上的异构，就需要领域专家决定数
据库模式间的对应关系。由于模式集成技术不易添加/删除联邦数据库集成系统
中的数据库，所以紧藕合FDBs通常是静态的，且很难升级。
松藕合FDBS没有统一的模式，但它提供了一些查询数据库的统一语言。这
样FDBS中的数据库更具有自治性，但必须用户解决所有语义上的异构。由于松
藕合FDBs没有全局模式，所以，每个数据库都要创建自己的“联邦模式”。
FDBS中实现互操作最常用的方法是将每个数据库模式分别和其它所有数据
库模式进行映射，如图2一l所示。这样联邦中需要建立n。(n一1)个模式映射规
则，但当参与联邦的数据库很多(n值很大)时，建立映射规则的任务变得不可行
了.所以，联邦数据库集成系统适合于自治数据库的数量比较小的情况，而且希
望数据库能够保持“独立”，允许用户单独查询，数据库间能够彼此联合回答查
询的情况。对于网络上越来越丰富的数据源，FDBS显然不是一个很好的解决方
案。
3.中介(Mediation)系统
Mediated系统通过提供所有异构数据源的虚拟视图来集成它们，这里的数
据源可以是数据库、遗产系统、Web数据源等等。该系统提供给用户一个全局模
式(也叫Mediated模式)，用户提交的查询是针对该模式的，所以用户不必知道
数据源的位置、模式及访问方法。
Mediation体系结构与紧藕合联邦有如下不同之处:
(l)Mediated系统可以集成非数据库数据源。
(2)基于中介器(mediator)的系统中的数据源的查询能力可以是受限的，
数据源可以不支持SQL查询。
(3) Mediation系统中的数据源是完全自治的，这就意味着很容易向系统
中添加/删除数据源。
(4)由于Mediated系统中的数据源是自治的，所以对系统中数据源的访问
通常是只读的，而FDBS支持读写访问。
图2一2所示的是典型的Mediated系统体系结构.该系统的主要部分是中介器
和针对每个数据源的包装器(价aPPer)。这里中介器的功能是接收针对全局模式
生成的查询，根据数据源描述信息及映射规则将接收的查询分解成每个数据源的
子查询，再根据数据源描述信息优化查询计划，最后将子查询发送到每个数据源
的包装器。包装器将这些子查询翻译成符合每个数据源模型和模式的查询，并把
查询结果返回给中介器。中介器将接收的所有数据源的结果合并成一个结果返回
给用户。
4.数据仓库法
该方法需要建立一个存储数据的仓库，由ETL(Extract，Transform and load)
工具定期从数据源过滤数据，然后装载到数据仓库，供用户查询。与虚拟视图法
图2一3数据仓库体系结构
相对应称这种方法为Eager方法。数据仓库体系结构图2一3所示。
与虚拟视图法相似的是用数据仓库集成异构数据源也需要异构统一的数据
视图，但不同的是ETL工具过滤得到的数据存储到仓库中。而与传统的数据库不
同的是数据仓库中主要存储的是历史和汇总数据，用于决策支持，主要供分析或
执行等人员使用，而且为避免数据仓库与数据源中数据出现不一致，通常不允许
用户对数据仓库进行更新。
由于数据仓库系统的昂贵的投资费用、项目实施周期长、项目成功率风险大
等原因制约了数据仓库在中、小型企业或数据积累少的企业解决异构数据源整合
和集成需求的应用;有些数据库管理系统自带的数据转换工具，能低成本地解决
异构数据源整合和集成问题，但在具体项目实际应用过程中，也具有一定的局限
性。
数据集成在很大程度上是基于这两种相对的方法。数据仓库和虚拟数据集成
系统主要的不同是“eager”和“lazy”的对抗(如图2一4)。如上所述，数据仓
库方法需要建立一个存储数据的仓库，定期对数据源中的所有信息进行预处理，
形成符合仓库模式的信息，然后下载数据到数据仓库。对数据源中信息的预处理
及数据仓库的更新主要是通过 ETL工具。这种方法的主要好处是查询处理性能
高，但主要缺点是数据可能不是最新的，如果仓库模式设计成静态的，当有新数
针对仓库模
符合仓库模式
式查询
图御数据仓库
图伪)虚拟数据集成系统
图2一4数据仓库与模拟数据集成系统对比
据源加入或已有数据源发生变化时对仓库的修改代价比较高，而且创建数据仓库
比较费时费力，通常需要6、18个月的时间。
虚拟视图集成方法用于数据仓库不实用或不能解决的情况，例如:用户只需
访问数据源中一小部分数据、数据频繁更新、需要实时数据、提供数据方只能处
理有限的查询或全局模式本身经常改变的情况。在完全的虚拟数据集成中，全局
模式是一个逻辑的或虚拟的实体，系统根据数据源相关信息将针对该模式的查询
在系统运行时动态重写成针对每个实际数据源的查询，中介器通过包装器获得数
据，然后整合，返回给用户。在实际的数据集成解决方案中多采用虚拟视图集成
的方法，该方法定义了一个或多个中介模式(Mediated Scheoa。)，通常指全局
模式。这些模式是用来查询数据，而不是存储数据，数据仍保存在局部数据源中。
当用户向集成系统提交一个查询，系统会将该查询翻译成针对各个数据源的查询
集，然后将结果整合返回给用户。应用这种解决方案得到的查询结果是最新数据。
而且xML的出现使得对各种数据信息的标准化描述成为可能，使系统更易于适应
数据源间的不同。
虚拟视图集成优于数据仓库之处是:
(1)它能够集成那些只允许对数据进行有限访问的数据源;支持数据的实时
视图;能够同时描述中介模式的多个版本。
(2)适合集成系统中的数据源数量很大，而且数据源更新频繁，不可预知用
户需要查询什么信息的情况。虽然虚拟视图集成方法要以一定的性能作代价，因
为每次查询都要连接数据源，如果有些数据源实际位置距中介器很远，则可能出
现响应延时，但是创建数据集成系统很快，而且在中介器中增用缓存策略可解决
这一问题，优化系统性能。
[返回] 中文XML论坛 - 专业的XML技术讨论区 →
XML.ORG.CN讨论区 - 高级XML应用 → 『 XML 与 数据库 』 → 异构数据库集成策略(转贴)
(订阅本版)
2006/4/24 16:31:00
新浪微博
异构数据库集成策略(转贴)
