异构系统数据共享的研究与实现-毕业设计.doc

异构系统数据共享的研究与实现异构系统数据共享的研究与实现学位申请人姓名： 培 养 单 位：电气与信息工程学院 导师姓名及职称： （教授） 专 业：控制理论与控制工程 日 期：目 录第一章 绪论41.1 论文研究背景和意义41.2 论文选题背景61.3 国内外研究现状61.4 论文研究内容及重点81.5 章节安排9第二章 异构系统数据共享常用技术102.1 异构系统数据库集成模型102.1.1 基于传统数据仓库的集成架构102.1.2 联邦数据集成112.1.3 基于中介器的集成122.1.4 异构数据库实现互连和数据访问的方法132.2 中间件技术152.2.1 CORBA162.2.2 DCOM172.2.3 EJB/Java RMI182.3 xml及其相关技术19第三章 xml与数据集成203.1 xml相关技术203.1.1 超文本标记语言（Hypertext Markup Language）203.1.2 级联样式单(Cascading Style Sheets)203.1.3可扩展的样式语言(Extensible Style Language)203.1.4 URL和URI213.1.5 XLink和Xpointer213.1.6 DOM223.1.7 DTD223.1.8 XML Schema233.1.9 XQuery243.2 xml与关系数据库之间的映射方式研究243.2.1 XML与关系数据库之间的映射方式253.2.2 XML与数据库之间数据类型的映射263.3 基于XML的数据集成体系结构283.3.1 应用层303.3.2 代理层303.3.3 消息层303.3.4 数据源层30第四章 系统体系结构设计324.1 热电分厂三遥系统324.1.1 系统总体架构324.1.2 系统内部软件框架334.1.3 异构系统数据交互软件框架354.2 110kv站微机保护系统374.2.1 系统总体架构374.2.2 系统内部软件框架394.2.3 异构系统数据交互功能层次404.2.4 数据交互运行流程42第五章 系统关键技术的分析与实现445.1 与直流屏的数据交互445.2 与honeywell的数据交互465.2.1 数据的获取和转换465.2.2 数据的解析和展现495.2.3 用户管理515.3 供电系统整体集成535.3.1 共享数据注册535.3.2 公共模型565.3.3 包装器565.3.4 用户界面585.3.5 数据的多样化展现59参考文献62第一章 绪论1.1 论文研究背景和意义随着全球经济的发展，实现信息化已经成为我国企业发展的必然要求，然而，与发达国家相比，我国企业是建立在现有的相对落后的产品设计、制造、生产、管理等系统基础上，这使得企业信息化需要解决的技术环节错综复杂。特别是由于市场经济的渗入及电子商务的发展，企业信息化的应用深度与广度也在不断扩展，我国企业正面临着更加激烈的市场竞争，如何提高自身的竞争能力和可持续发展能力，从而在多变的全球化市场竞争中保持优势，已经成为我国各行业、各地区企业生存和发展的关键。实践表明，解决这一问题最有效的办法就是引进先进技术，全面实现企业管理的信息化、智能化、集成化，以最快的时间、最高的性价比提供满足客户个性化需求的产品。同时计算机技术和网络技术不断发展，Internet/Intranet规模日益增大，丰富的信息资源使得企业与外界的联系越来越紧密。企业界为了充分利用这些信息资源为企业服务，新兴企业呈现出分布化、集团化和专业化的趋势。异地设计与制造、动态联盟、虚拟企业等新型的企业组织和合作方式不断涌现。通过企业与企业在产品开发过程中的合作，可以实现优势互补，加强各个企业的核心竞争力，节省大量的低效率投资，提高整个企业联盟的竟争力，这种企业结盟己成为市场竞争中普遍采用的有效手段。由多个分布企业协作完成一个复杂产品的开发，己经成为企业合作的重要模式，分布式企业协作产品开发，除了管理模式需要深入研究外，还有一个重要问题是各企业之间数据共享的问题。由于各个分布企业使用的数据库产品可能来自不同的软件提供商，即使是使用相同的数据库产品，由于各个企业建立方式的不同，都会造成各个企业数据库系统对产品数据信息模型表示上的差异，使得不同企业的数据库系统之间直接交换和共享设计、制造过程的数据变得困难。网络的发展使企业逐渐从一个孤立的节点成为不断与网络交换信息、传递信息的实体，企业数据共享也从企业内部共享走向了企业间共享。现在的企业比以往任何时候都需要将内部数据进行发布和交换，这必然导致越来越多的企业应用需要访问异构数据源，为了满足这种需求，需要有一种系统能够支持异构数据源的数据共享。实际上，在数据库系统出现之前，应用系统使用文件系统来存储数据，大量自治应用系统创建了大量的异构文件，共享这些异构文件是非常困难的。在单一的系统中管理所有这些文件是异常复杂的，因为这些文件在字段名称、值类型和文件结构上存在着大量的异构问题。为了解决这些问题，人们开始使用集中的数据集合替代文件系统来存储和处理数据，这个数据集合称为数据库，管理这些数据库的集中控制系统称为数据库系统。从七十年代起，集中式数据库得到了迅速发展和广泛使用，类似的问题出现了。这些数据库被独立地创建和管理，物理上和逻辑上都存在异构。每个独立的数据库有自己的模式、数据模型、数据操纵语言。这些数据库的异构性主要体现在以下几个方面：1)计算机体系结构的异构，各个数据库运行在大型机、小型机、工作站、PC或嵌入式系统中； 2)基础操作系统的异构，各个数据库系统的基础操作系统可以是Unix, Windows NT, Linux等；3)DMBS本身的异构，可以是同为关系型数据库系统的Oracle, SQL Server等，也可以是不同数据模型的数据库，如关系、模式、层次、网络、面向对象，函数型数据库；4)数据结构及语义异构，各个不同的数据库应用系统采用不同的数据结构和语义表达方式。同时，长期以来，企业内部软件系统的开发常常是企业感觉到需要某种职能时就开发这种功能的系统，遇到新的需求再进行开发。这种方式带来的结果是：企业内部有很多在不同时期开发的、具有不同职能的、采用不同操作系统、不同数据库管理系统、不同的软件工具开发的不同界面的应用系统，也就是所谓的异构系统。多种硬件和软件平台的共存，以致这些子系统各自独立发挥作用，各个子系统的数据是动态的、异构的，多数情况下，这些系统已形成一个个巨大的“信息孤岛”。有限的信息共享、缺少数据交换和信息不一致成为整个企业信息系统的严重缺陷，由于这些应用系统在设计阶段就没有从系统交互的角度，按照统一的思路进行考虑，使得各个系统采用的技术，都是针对其特定问题的，因而导致它们难以从整体上加以集成，以发挥信息共享所带来的优势。在用户层次上，越来越多的用户需要同时访问和处理不同网络节点的多个异构数据库的数据，希望屏蔽各个层次的异构特性，他们不必知道各物理数据库系统的分布，也不必知道各物理数据库的结构组成，不必自己去进行数据转换和结果汇总，只需通过简便的全局查询便可得到一个综合结果。特别是Internet出现后，获取大量数据变的容易了，企业间的合作、电子商务、政务信息网络化得到了广泛的发展，这些企业采用各种相互独立的应用系统，在部分提高了效率的同时，这些系统的相互独立性也为整体管理设置了障碍，它们缺乏一个统一的界面，没有相互连接的信息渠道，数据通常都被封存在企业的不同数据库、主机、文件服务器上，只有少数有特许访问权的用户能看到这些数据。从数据库研究的角度出发，全厂所有参量的信息可看作是一个庞大、复杂的数据库。而每一个监控系统可看作一个数据源，每个系统的内部数据是结构化的，然而系统与系统之间的信息和组织都不一样，因此数据源是异构的。这样就构成了一个巨大的异构数据库环境。网络的发展使企业逐渐从一个孤立的节点成为不断与网络交换信息、传递信息的实体，企业数据共享也从企业内部共享走向了企业间共享。现在的企业比以往任何时候都需要将内部数据进行发布和交换，这必然导致越来越多的企业应用需要访问异构数据源，为了满足这种需求，需要有一种系统能够支持异构数据源的数据共享。韶关冶炼厂作为冶炼基地之一，为提高生产效率，也大量的引入了先进技术，先后开发了多个不同功能的应用系统，如负责监控热工系统的honeywell系统，为监测直流数据的直流屏，为监测热电分厂电量的三遥系统，为监测配电室电量的中浩系统等等。一方面，由于技术发展具有阶段性，而且现有应用系统的开发所针对的某一具体生产管理环节的应用实践本身也是逐步完善的，导致这些先后开发的应用系统在功能、操作上存在着一定的重复。另外，从数据上看，由于每一个应用系统都建有各自的数据库，综合起来，在数据上存在一定的重复、冗余甚至错误，而且各个应用系统的数据库之间的信息不能实现数据交换和全局共享，大量的数据或信息被闲置，没有得到应有的处理和利用，或者仅仅进行了初步的加工，缺少用于预测、辅助决策的信息，不能为高层决策提供一致的信息服务。针对这种情况，一个问题摆在我们面前，就是如何利用系统集成技术将这些已经建立起来的应用系统进行有效的整合，进行信息的集成和应用的集成，既保证实现现有系统的功能，避免重复开发，节省成本，又尽可能减少冗余，实现信息共享，提供更加有效的决策支持，进而提高生产管理效率。因此，韶关冶炼厂的异构数据共享系统就成为一个重要的课题。1.2 论文选题背景本课题的研究背景为韶关冶炼厂供电系统建设中的异构系统共享平台，该供电系统的建设共分为两期，第一期建设为热电分厂的三遥系统，二期建设为110kv站站内的微机保护系统以及与三遥系统，中浩系统等的数据总体集成和共享。在该厂中，Honeywell系统为该厂已有的热工系统，主要采集该厂内各锅炉、汽机、皮带机等的各项运行参数；热电分厂三遥系统为2005年由本项目组开发的监控系统，主要采集该厂的发电机、变压器、联络线、母线、辅机等各项电气参数；110kv微机保护系统以及中浩系统分别由本项目组及中浩公司已于2006年9月开始建设。该系统平台的目的是实现三遥系统，110kv微机保护系统，中浩系统，honeywell系统的数据的协调及有机关联，改变相关数据分散、孤立的现状，建立数字化设计环境下同意的综合性数据库平台。解决各个厂所之间、不同数据库系统之间存在的异构问题；解决各个厂所分离所造成的多数据互通互联与数据的一致性问题，最终实现全局数据共享。1.3 国内外研究现状多年以前，国内外的学者就开始研究数据的集成，最早的起源可以追溯到20世纪80年代早期的多数据库系统1，多数据库系统主要研究应用传统数据库技术桥接异构数据源之间的不匹配。多数据库系统研究以联邦数据库系统2研究为主。最直接的集成方法为联邦数据库方法，这种方法采用数据库副本和映射的方式，将用户和机器不熟悉的数据源转换为可以理解的数据，但是，联邦数据库也有着自己的缺点，首先，每个数据源都需要进行转换或映射导致了开发时间较长，同时对主机设备和存储的要求也较高，实现成本高；其次，联邦数据库的灵活性和实时性不足，数据源对于副本的更新总是需要经过一个更新周期，用户对于数据库的更新也不能及时反映到数据源，同时一个联邦数据库系统难以和另外一个联邦数据库系统进行数据共享和交互，从而导致出新的异构性。随着网络的发展和普及，数据集成的范围进一步扩大，事实上，数据集成不仅是数据库研究学者感兴趣的课题，在人工智能领域，数据集成也引起了研究人员的广泛关注。美国华盛顿大学的Etzioni和Weld3是信息agent研究的先驱，信息agent主要用于从分布的数据源中检索信息。这些项目的另外一个主要研究内容就是包装器4，包装器位于数据源和集成系统之间，屏蔽各数据源的异构性，为集成系统访问数据源提供依据。包装器的研究成果包括包装器的自动学习、加速包装器开发的工具等。美国斯坦福大学开发的TSIMMIS是第一个提出在模式集成中使用半结构化数据模型的项目之一；Hermes, IRODB和Disco主要研究处理有限的数据源访问能力；Camot和Infosleuth研究演绎数据库的集成。TSIMMIS、 Hermes、IRODB和Disco均使用GAV(global-as-view)方法进行模式集成。GAV方法将全局模式定义为所有局部模式上的一个集成视图。这种方法的优点是用户查询容易定义，查询分解过程相对容易实现;不足是任何局部模式的变化都可能影响到全局模式，全局模式维护困难，系统扩展性不强，难以表示不完整的数据源5。Information Manifold项目推广了LAV (local-as-view)方法的运用。LAV方法将每个局部模式定义为全局模式的一个视图。这种方法的优点是局部模式变化只需修改局部模式在全局模式上的视图定义无需修改全局模式，系统扩展性好;不足是难以定义如何利用视图响应查询，查询响应算法难以实现。Information Manifold项目的开发人员提出Bucket算法将查询重组成实际数据源下的查询。上面提到的Razor项目也使用LAV方一法进行模式集成，在Razor中查询重组是应用Inverse-Rules算法6完成的。在商业领域，数据集成系统已经成功应用在企业、电子商务和生命科学领域，如IBM 开发的Garlic7已经集成到DataJoiner和DB2中。Nimble科技和BEA正在尝试在大型组织中推广它们的数据集成工具Actuate8和Liquid Data9。XML的出现将数据集成的研究推向了一个新的阶段。尽管大多数的商业数据仍然存储在关系数据库里面，人们还是对把传统系统中的数据转换成XML表现出了极大的兴趣。IBM Oracle和Microsoft在它们的数据库产品DB2 Oracle和SQL Server中增加了为关系数据创建物化XML视图的功能。SilkRoute10和XPERANTO11主要研究中间层XML视图上的XQuery到关系数据库上的SQL查询的翻译，它们仅支持关系数据库的集成。Agora主要研究将标准化的XQuery查询翻译成中间层通用虚拟关系模式上的SQL查询，支持关系数据源和支持DOM接口数据源的集成。在国内,东南大学和华中科技大学在数据集成方面取得了很多研究成果，它们分别开发出了Versatile和Panorama数据集成原型系统。Versatile12和Panorama13项目组成员在国内外知名期刊上发表了一系列高水平的学术论文。以上数据集成方法均为”虚拟法” 14。虚拟数据集成通过一系列的中间件组件将数据访问转换为数据源能接受的格式，而虚拟数据集成系统并存储数据，并能保证查询到最新的数据，因此比较适合于高度自治，集成数量多，且更新变化快的异构数据源集成。虚拟数据集成的缺点是需要维护一个全局模式，当数据源模式发生变化时，维护全局模式比较困难。虚拟数据集成本质上是对数据进行逻辑上的集成，因此也被认为是一种逻辑数据集成方法。我们通常所指的数据集成就是指虚拟数据集成，以下如果没有特殊说明，数据集成就是指虚拟数据集成。与“虚拟法”相对，另外一种数据集成方法就是“数据仓库法”15。数据仓库为所有的数据库系统提供一个总的集合，所有数据库系统的数据都在数据仓库中存在备份，数据仓库位于客户端与数据源之间，集成系统查询时，直接对数据仓库进行查询，而各数据源只需要保持对数据库的及时导入。这种体系结构的优点是查询响应速度快。数据仓库存在的问题是，当数据源中的数据变动频繁时，要从数据仓库中查询到最新的数据，需要定时更新数据仓库，维护数据仓库的代价很高。目前，国内外相关的异构数据库系统主要有：(1)RDBMS OpenBase它具有一定的互连性，支持ODBC标准，提供了两种Web数据库解决方案，即CGI和面向Java的方法。(2)清华大学研制的CIMS系统中使用了异构数据库的互操作，但不具有全局数据库模式的概念；东南大学研制了联邦数据库管理系统，主要实现了Oracle, Ingres, Dbase三者之间的数据接口等。(3)ADDS(Amoco Distributed Data-base System)这种互操作主要针对同构环境下的关系数据库系统和应用系统但对于异构环境下某些特定的互操作与分布处理问题还需进一步研究和开发。(4) DATAPLEX (General Motors)具有位置透明性，支持异质网络、异质操作系统。它以关系模式为其全局数据模式，支持的DBMS有MVS操作系统下的IMS和INGERS。(5) INGERS/STARINGERS/STAR属于联邦数据库系统，访问它的分布式数据库是透明的，支持VAX VMS操作系统上的RMS文件系统和RDB数据库系统，及IBM大型机MVS操作系统下的DB2。(6) MERMAIDMERMAID也属于联邦数据库，它是用于查找和集成各局部数据库管理系统的前端系统，它主要有用户界面、服务器、数据字典和DBMS接口等四个功能部件。上述这些系统在一定程度上解决了异构信息的共享问题，但仍然存在一些不足之处.它们大多功能比较单一。目前，普遍采用的是客户端解决方案和服务器端解决方案这两种解决方案。随着分布式对象技术的兴起和逐步完善，这个问题得到了很好的解决，它能提供一个通用统一的通信中间件屏蔽环境异构性，可以大大简化集成系统。1.4 论文研究内容及重点1、异构系统数据交互理论的分析与研究。 包括数据交互的历史发展，国内外研究现状等各方面的内容。2、异构系统数据共享常用模型的调查与研究。 包括从最早的联邦数据库、数据仓库等模型到现在的中间件模型等等。3、一系列xml标准和技术的研究。 包括xml语法，DTD和xml Schema数据建模工具的研究。4、数据库和xml的映射关系、语言规范的研究。 包括模式驱动，模板驱动等各种映射方式的仔细研究，权衡利弊，选择出符合条件的实际应用最有用的映射方法。5、数据共享平台的研究与设计 包括平台的系统设计、功能设计、模块划分等。6、网络传输协议与技术的研究。 主要包括TCP/IP协议的了解，以及该技术在数据传输的应用，根据系统的实际要求制定出符合条件的协议并在系统中应用。研究的重点包括：数据共享平台体系结构设计数据共享平台业务逻辑和算法流程平台组成模块的分析与设计1.5 章节安排本论文的章节安排如下：第一章：主要介绍论文的研究背景和意义，并在对国内外异构系统数据交互研究的基础上提出了本文的主要研究内容是异构系统常用交互的理论与模型的研究、针对韶关冶炼厂供电系统建设中的异构系统数据共享平台的设计和研究。 第二章：主要详细介绍了目前常用的异构系统共享技术，最简单的是联邦数据库，实现简单，但是成本高，维护复杂；最传统的是数据仓库，缺点是系统复杂，硬件设备要求高，同样维护不便，升级困难，当系统不足够或者客户群不足够多时，存在着较大的风险。较好的解决方案是采用中间件技术，XML出现后，为异构系统数据集成提出了新的思路，简要介绍了XML在异构系统数据集成中应用。第三章：主要详细介绍了XML在数据共享集成中的具体应用，详细介绍了XML的相关技术，包括在后面章节中要使用到的，同时也是XML技术中较为重要的DOM，DTD等进行了较为详细的介绍，在异构系统中较为常见的XML文档与数据库的映射，也分别进行了分析。第四章：在韶关冶炼厂供电系统的建设中，根据前面几章讨论的内容，挑选出最适合实际情况的方案，根据两期建设不同的目标，提出了大体相同、各有特色的异构系统数据交互方案，在三遥系统的建设中，采用了直接数据交互的方式，直接获取直流屏和热工系统的数据，通过双层C/S的结构将数据在全厂区Intranet内进行交互和共享，对于供电系统二期集成建设，采用C/S加上B/S的结构，极大的提升了系统的性能和使用范围。第五章：对于第四章所提出的系统框架的基础上，对于两期建设的具体实施和关键技术进行了分析和介绍，对于三遥系统，分别详细介绍了直流屏的串口通讯数据获取和展现，对于热工系统的数据获取、数据转换，以及数据的解析和展现分别进行了详细的讨论，对于二期建设中，系统的整体运行流程、模块设计等给出了设计思想和程序框图。第二章 异构系统数据共享常用技术2.1 异构系统数据库集成模型自从异构系统数据集成提出以来，异构数据库系统数据交互与共享一直是数据库领域的一个主要研究方向。随着网络的发展，对数据库又有了新的要求。各种数据库中的信息不仅需要在Internet发布，而且大量的应用需要能同时访问多个数据库中的数据。这样异构多数据又一次成为数据库领域的一个研究热点。为了解决异种数据库之间的互联问题，国际标准化组织和各数据库厂家作了不懈的努力。2.1.1 基于传统数据仓库的集成架构 基于传统数据仓库集成的策略是将来自几个异构数据源的数据副本，按照一个集中、统一的视图要求，进行预处理、转换，以符合数据仓库的模式，并存储到数据仓库中，给用户提供一个透明的统一视图。如将不同数据源的数据按照一定的主题装在到数据仓库中，以方便用户能够从大量数据中发现信息。这样，对于使用者来说感觉就像在使用一个普通的数据库一样。数据仓库的集成模式如图2-1所示：2-1 数据仓库集成使用数据仓库来实现异构系统数据的交互与共享可以对数据源中的原始数据进行加工与预处理，使用户得到更精准有用的数据，同时，由于数据的集中，使得用户可以利用数据建模、联机分析处理(On-Line Analytical Processing, OLAP)和数据挖掘(Data Mine, DM)工具对数据进行有效利用，方便决策能正确及时的作出16。目前，进行数据仓库中数据构建的方式有以下三种:1、数据仓库周期性的从原数据源中重新构建数据。每隔一段导入周期将数据源中的数据在数据仓库中进行重建。这种方式的主要缺陷是需要将数据仓库关闭，而事实上数据的重建可能需要很长的时间。对于某些应用来说，过长的宕机时间会使很多数据过时。2、数据仓库周期性的从原数据源中更新数据(采用增量更新的模式，也即是，每次数据仓库更新上次更新以后修改的数据)。由于采用了增量更新的方式，更新较快。该方式主要的缺点是用于计算数据仓库中数据更新的算法(增量更新算法)，相对于从原始数据开始构建数据仓库的算法要复杂的多。3、数据仓库即时更新异构数据源的数据变化。当一个或多个数据源中的数据发生变化的时候，立刻更新数据仓库中相应的数据。由于这种方法需要数据仓库和数据源之间频繁的通信，当数据量较大时，该方法难以达到满意的效果。然而，这种方式的研究和一个成功的数据仓库的实现有着广泛的应用，如自动股票交易系统。总之，数据仓库模式的异构数据库数据共享集成的优点是便于进行联机分析和数据挖掘17。 但是，该集成架构也有它的弱点，一是该架构在反映实时信息上的不足，数据仓库可能会禁止用户去更新数据，用户对数据仓库中数据的更新将不会反应到原来的数据源中，原数据源到数据仓库的更新也有一定的周期，使得用户往往不能获得最新的现场信息，这就会造成数据源和数据仓库中数据不一致的问题。二是灵活性不够，当数据源的数据结构发生较大变化时，而用户不能及时获得，往往会影响到数据仓库集成的质量，三是建立数据仓库的成本高18，由于每个数据源都有一份副本通过转换而存储在数据仓库中，导致了系统的数据冗余非常大，同时，象现场的采集系统这样数据不停增加的系统，在运行一段时间后，系统的有效性和快速性将会急剧下降，同时，维护这样这样庞大的数据仓库，数据处理和存储设备的要求将不断增加，使得用户在使用过程中将不断的追加成本。2.1.2 联邦数据集成联邦数据库系统(Federated Database System, FDBS)是由一系列独立、自治的数据库系统组成的。各个数据源是相互独立的，他们通过协商一定的输入/输出数据模式来交换与共享各个数据源之间的数据。当协商通过的数据模式确定后，各数据源即和协商模式之间建立一一的映射关系，使各个数据源都可以通过协商好的模式来访问其他的数据源中的数据。目前，联邦数据库系统的实现方法有以下两种：1、数据库转换在这种方法下，每个数据库均通过一定的关系映射转换为用户可以使用的用户数据库，即除源数据库外，还保持一个用户数据库的副本，在用户访问数据库时，实际上只是通过用户可以理解的模式来访问源数据库中的数据，也就是说，不同的数据源之间使用数据转换接口来实现数据互访，这样一个数据源就可以访问任何其它数据源的信息。如图2-2所示：2-2 数据库转换2、模式转换模式转换是在各数据源之间建立一一映射，用户可以用自己熟悉的数据语言书写事务，然后通过事务翻译到另外的数据源去执行，即DB1可以通过事务翻译使用DB2可以理解的语言去访问DB2中的数据，如果有n个异构数据源需要互连，那么我们就要去构造n* (n-1)个映射程序来支持这n个异构数据源之间的互相访问。图2 -3 给 出了4个异构数据源构造联邦数据库的结构。其中每一个数据源都需要和其他的3个数据源进行映射。2-3 模式转换图2-3四个异构数据源的联邦数据库集成模式则需要构建12组映射程序，同时产生了原数据库以外的四个数据库副本，各数据库很难做到局部自治，副本之间的数据一致性问题，安全问题等等都将加重系统的负担19，当数据源较多时，该方法所要付出的代价太大，在考虑成本问题时，该方法不适用。2.1.3 基于中介器的集成基于中介器的的数据集成方法是一种典型的模式集成方法，主要包括中介器(Mediator)和包装器(wrapper)。中介器实际上是一种软件组件，支持虚拟数据库，就像实际存在的物化(materialized)的数据库一样。每个数据库通过包装器与中介器交互，而中介器则与用户交互，并将用户的要求的查询通过包装器由数据源中得到结果。Mediator不存储任何自己的数据，当用户在全局数据模式的基础上向中介器发出查询请求时，中介器将用户的查询翻译成一个或者多个对数据源的查询，并对此过程进行优化，以提高查询处理的并发性，减少响应时间，然后，Mediator将那些数据源对用户查询的响应进行综合处理，把最终结果返回给用户。因此，由于Mediator模式不存储任何数据，它和数据仓库模式是有本质的不同的。包装器对特定数据源进行了封装，将其数据模型转换为系统所采用的通用模型，并提供一致的访问机制。中介器将各个查询请求发送给包装器，由包装器来和其封装的数据源交互，执行子查询请求，并将结果返回给中介器。图2-4展示一个Mediator集成两个异构数据源的系统结构，和数据仓库一样，典型的数据集成将会有多个不同的异构数据源。2-4 中介法数据集成当用户向 Mediator提交一个查询时，由于Mediator本身并不存储数据，所以它必须从数据源中得到相关的数据，然后利用这些数据构造用户需要的结果。因此，在图2-4中，我们可以看到Mediator把查询分送到每一个包装器(Wrapper)，同时包装器把查询请求发送到相应的数据源中。事实上Mediator可能给一个包装器发送很多查询，也可能不给某个包装器发送任何查询20。从各个数据源中得到的结果返回给了Mediator，又由Mediator集成这些结果数据，把数据构建成用户需要的数据模式。2.1.4 异构数据库实现互连和数据访问的方法要实现异构系统数据的交互，首先要求能够实现异构数据库的互连与访问，目前，解决异种数据库互连的方法有三种：数据库网关（DATABASE GATEWAY）公共协议（COMMAN PROTOCOL）公共编程接口(COMMON PROGRAMMING INTERFACE)数据库网关(Database Gateway)目前，大多数的数据库厂家为了使自己的产品具有开放性，都提供了各自的网关产品，以支持异构系统之间的网络互连。在数据库网关产品中，比较典型的有：IBM DB2、ORACLE的Dedicated Transparent Gateway 和Sybase的OmniSQL Gateway等21，其他一些大型数据库厂商也都有自己的网关产品。数据库网关实际上是一种应用程序接口，可以通过调用API函数来访问异种数据库而无需知道数据库所采用的存储机制。它实现全局数据访问，通过对各种异构、分布的数据资源提供一个统一的视图，应用程序和工具可以对位于不同平台下的不同类型的数据资源进行一致、高效的访问，使所有的企业数据库对用户来说是一个数据库。例如，一个数据库网关可以被购买用来使得将IBM DB2视为Oracle数据库，这样可以让你通过Oracle PL/SQL指令通过网关访问DB2，网关允许你向访问Oracle一样访问IBM DB2数据库。这种基于服务器的解决方案合理分担了客户和服务器的工作，符合数据库互连产品的发展方向。当数据库种类较多且客户量多的情况下，数据库网关能够为企业和单位的各种数据源提供统一的客户访问界面，从而较为满意的解决数据库的互操作问题。网关最重要的优势在于可以保护已有投资和资源，用户无需废弃现有的应用程序和数据库，只需要利用网关把它们与新的数据库技术互联起来，就可以构成新的系统。但是，数据库网关方法也有缺点，在N个异构数据库组成的复杂系统中，要实现任意两个数据库间的互操作，就必须提供N (N-1) /2个网关，而且数据库网关价格昂贵，这在实际应用中是很难投入实用的。而且，有些异构数据库间的数据格式，语法或语义的转换是行不通的，利用数据库网关访问远地异构数据库不易达到完全透明。有人认为数据库网关是连接异种数据库实现互操作的权宜之计，一旦统一的应用界面标准被广泛采纳，就不再需要网关22。公共协议(Common Protocol)采用公共协议指对客户和服务器间通信的格式和协议以及数据库语言进行标准化，这是一种较理想的解决异种数据库系统互联的方法，目前比较典型的有SAG (Sql Access Group)规范和IBM的分布式关系数据库体系结构(DRDA) 23。在这二种方法中，采用开放界面进行开发的如利用Sysbase公司的OpenClient/OpenServer, Oracle的OCT等，操纵数据库的效率比较高但编程量较大。 普遍使用的ODBC实际上就是基于SAG的CLI规范。SAG和IBM试图从标准一致化的角度来解决这个问题，并制定了一系列规范24。ODBC实际上是一个数据库访问库，但是只提供一个统一的应用编程接口（API）。利用ODBC可以免除应用程序随数据库的改变而改变的痛苦。ODBC通过使用数据库驱动程序获得数据库独立性，驱动程序所提供的标准接口允许应用程序开发者和驱动程序提供者在应用程序和数据源之间传递数据。公共编程接口(Common Programming Interface)公共编程接口包括客户应用编程界面(CAPI)和服务器应用编程界面(SAP1)。CAPI是一组过程库，通常以TSR方式或DLL方式驻留在客户工作站上25， 4个CAP I通常可以装载后端专用的驱动程序，以访问不同的数据源。SAN提供4个应用编程界面，控制服务器与客户应用请求和目标数据库之间的交互。在具体实现过程中，基于公共编程接口的异构数据库的互连的方法有以下两种：1、利用Powerbuilder的数据管道Data PipelinePower builder通过对不同数据库采用不同接口的形式同时支持多种关系数据库，并提供了数据管道(Data Pipeline)，允许在两个相同或不同的DBMS管理的数据库之间复制表的结构、属性和表中的数据，这样便可在网络环境下，使本地数据库与远程服务器上的数据库并存且相互交换数据。2、利用ODBC技术和SQL语句，ODBC( Open Database Connectivity是一种在相关和不相关的DBMS中存取数据的标准应用程序设计接口(API)。在异构数据库环境下，用户使用ODBC就可访问多个DBMS，实现异构数据库互连。众所周知，SQL己成为数据库操纵语一言的标准，ODBC是基于SQL的。随着Microsoft致力于在其产品中实现并支持ODBC，加之一般软件厂商的软件均提供ODBC接口，所以ODBC有望成为今后异构数据库事实上和国际公认的互连标准。ODBC使用层次方法管理数据，在数据库结构的每一层，对可能出现依赖产品的地方，都引入一个公共接口以解决潜在的不一致性。ODBC通过确保所有的应用系统遵循标准的调用层接口并提供对特定数据源命令进行解释的驱动程序来保持应用系统的互用性，这样应用系统不必克服由函数的功能、数据库协议或网络协议等因素造成的不一致，尽管他们的数据来源会各不相同。ODBC的结构包括以下四个组件。(1)应用程序：屏蔽不同的ODBC数据库驱动器之间函数调用的差别，为用户提供统一的SQL编程接口；(2)驱动器管理器：为应用程序加载和调用驱动器，负责管理应用程序中ODBC函数与动态链接库(DLL)中函数的联编(binding)；(3)驱动器：是一个用以支持ODBC函数调用的模块，它执行ODBC函数调用，呈送SQL请求给指定数据源，并将结果返回应用程序，应用程序通过调用驱动器所支持的函数来操纵数据库，ODBC用驱动器提供数据库独立性；(4)数据源：具体的数据管理系统及其环境(如DBMS).按结构的观点，ODBC驱动程序可分为单束式和多束式两类：A、单束式驱动程序介于应用程序和数据库之间，为非C/S数据提供统一的通信方式，它是一种完全自含式的数据库引擎，所有对数据库的操作都是由它完成的。B、多束式驱动程序负责在数据库引擎和应用程序间传送命令和数据，它本身并不执行数据处理操作，而仅是一个中继站。ODBC接口定义了个函数库，应用系统通过SQL访问DBMS，ODBC接口对不同的DBMS提供半透明的存取，且其可移植性好。C、若m个应用程序访问n个DBMS，在没有通用接口的情况下，程序员需要开发的接口数是m*n个。使用ODBC开发出通用的DBMS访问接口后，接口数是m+n个。现在绝大多数的DBMS均提供ODBC接口，所以实际需要开发的接口数仅为m个，这样小仅减少了接口的程序设计工作量，而且提高了应用系统的通用性，在利 用 O DBC技术和SQL语句这样一种公共编程接口技术实现异构数据库的互连和访问时，它允许一个应用程序访问ODBC支持的不同数据源。应用程序使用结构化查询语句SQL作为标准的数据访问语言。ODBC为Windows开发者提供了SQL数据库访问函数调用，屏蔽了底层数据库系统的不同，从而简化了对数据库的访问。前台应用程序ODBC与不同的数据库连接，再通过嵌入的SQL语句实现对不同数据库数据的综合查询，或数据转换。例如，用SELECT语句可以从不同的表中提取数据；用INSERT INTO语句可以向数据库中的某个表添加新数据用UPDATE语句可以修改数据库中的数据。2.2 中间件技术 中间件是一种支持分布式应用的重要组件框架结构，分布式应用借助中间件在不同的技术之间共享资源。中间件为应用提供统一的编程模型，来处理异构、分布问题和管理计算资源以及网络通信。中间件对分布式应用的底层支持，决定了中间件必须负责实现分布式事务处理、安全保障、网络负载平衡和交易控制等工作。这一特点，使得目前的中间件主流技术都是基于分布式对象技术。其中，EJB, DCOM和CORBA组件代表了当前中间件技术的最新发展趋势。分布式对象结构是从中间件概念上发展起来的，它将程序数据封装在具有函数接口的对象之中，和以前我们设计结构化的程序有些类似，如果程序函数设计的比较好，那么各函数之间是松耦合的，函数执行细节对于外部来说是不可见的；同样，在分布式对象结构中，对象内的执行细节对于调用者来说也是不可见的。并且在分布式对象结构中，对于对象中的方法调用也做了限制，用户不能像调用API一样去直接调用这些方法，而只能通过间接的形式进行调用。另外，用户在调用对象的时候也只需要使用对象的引用，而不再需要创建本地实例。目前分布式对象技术主要有三种规范：OMG组织的公共对象请求代理体系结构(CORBA)26；Sun公司的企业级JavaBeans(EJB) 27；Microsoft公司的分布式组件对象模型(DCOM) 28。尽管各种构件实现规范的侧重点与实现机制各不相同，它们力图解决的问题却是一致的一一提高复用的程度，简化开发过程。这种最终目标上的一致使得不同规范采用的构件运行环境与结构存在一定的相似性。不同的规范之间既存在竞争，也存在协作。CORBA与JavaBeans在竞争的同时，互相借鉴、互相影响、并互相支持。而CORBA与DCOM之间更多的是一种竞争关系 一一CORBA以UNIX为主要阵地，而Windows也有很好的支持，并制定了二者之间相互转换的规范；DCOM以Windows为主要阵地，未对双方的转换给予充分重视。2.2.1 CORBACORBA (Common Object Request Broker Architecture-公共对象请求代理体系结构)是由OMG(Object Management Group一对象管理组织)制定的一个工业规范。CORBA 是基于对象管理体系结构的(Object Management Architecture，即OMA)。CORBA的核心是ORB(Object Request Broker)，ORB核心是客户端与服务器的“通信总线”，它主要负责代理之间的通信，提供机制实现客户对服务端的透明访问，通过ORB核心的屏蔽作用，用户不用关心服务的位置、实现细节、执行状态与服务的底层通信机制。其工作的体系结构如下图所示：图2-5 CORBA体系结构 在上图中，服务器上的服务用IDL（接口定义语言）描述，IDL被分为两部分，在客户端代理的称为stub（桩），在服务器代理的是skelet（骨架），服务器端在skelet的基础上提供各种服务的具体实现，而客户端通过客户桩访问服务器上的方法，双方通过ORB(Object Request Broker，对象请求代理)总线通信。客户端向stub发出服务请求，stub通过orb与skelet通信，在skelet中，提供了服务器所提供服务的代理操作，公国skelet，客户可以调用服务器中所提供的服务，这样，对于用户就屏蔽了底层的操作处理，看上去好像客户端和服务器在直接通信一样。OMG组织所制定的对象管理体系结构OMA(Object Management Architecture)29，该模型描述了OMG规范所遵循的概念化的基础结构。OMA由对象请求代理ORB、对象服务、公共设施、域接口和应用接口这几个部分组成，其核心部分是对象请求代理ORB（Object Request Broker）。对象服务是为使用和实现对象而提供的基本服务集合；公共设施是向终端用户应用程序提供的一组共享服务接口；域接口是为应用领域服务而提供的接口；应用接口是由开发商提供的产品，用于它们的接口，不属于OMG标准的内容。ORB提供了一种机制，通过这种机制，对象可以透明的发出请求和接收响应。分布的、可以互操作的对象可以利用ORB构造可以互操作的应用。其参考模型如图2-6所示：图2-6 OMG参考模型与此对应 ，从逻辑功能上，CORBA标准主要分布三个层次:对象请求代理、公共对象服务和公共设施。最底层是对象请求代理ORB，规定了分布对象的定义(接口)和语言映射，实现对象间的通讯和互操作，是分布式系统中的“软总线”在ORB之上定义了很多公共服务，可以提供诸如并发服务、名字服务、事务服务、安全服务等各种各样的服务；最上层的公共设施则定义了构件框架，提供可直接为业务对象使用的服务，规定业务对象有效协作所需的规定规则。CORBA界面和数据类型是用OMA界面定义语言(IDL)定义的。通用ORB互操作体系结构本身基于通用ORB互操作协议(GIOP)。互联网ORB互操作协议IIOP(Internet Inter-ORB Protocol)指定如何将GIOP建立在TCP/IP传输协议之上。从某种意义上，IIOP和GIOP的关系有些类似于对象的OMG IDL接口和其实现。GIOP指定协议，而HOP决定如何使用TCP/IP实现GIOP, CORBA在不同对象请求代理之间使用HOP进行通信，使用TCP作为网络通信协议，目前，国 内外许多公司已经推出基于CORBA的成熟产品并得以广泛应用。例如：国外有IONA公司的Orbix, Inpris30。公司的VisiBroker, Digital公司的ObjectBroker31等，国内有东南大学的Orbus、国防科技大学的Starbus32等。总之，CORBA的特点是大而全，互操作性和开放性非常好。CORBA的缺点是庞大而复杂，并且技术和标准的更新相对较慢。2.2.2 DCOMCOM /DCOM(Component Object Model/Distributed COM构件对象模型/分布式构件对象模型)。Microsoft的分布式构件对象模型(DCOM)是COM在分布式计算方面的扩展，使COM跨越机器的边界，进一步应用于局域网、广域网，以及Internet上。为了适应网络环境，DCOM主要的任务是在COM的基础上，实现远程调用，并采取一些策略，以适应和优化网络环境。以Microsoft为首的DCOM/COM/COM+阵营，从DDE,OLE到ActiveX等，提供了中间件开发的基础，如VC, VB, Delphi等支持DCOM，包括OLE DB在内新的数据库存取技术，随着Window2000的发布，Microsoft的DCOM/COM/COM+技术，在DNA2000分布式计算结构基础上，展现了一个全新的分布式构件应用模型。首先，DCOM/COM/COM+的构件仍然采用普通的COM(Component Object Model)模型，COM最初作为Microsoft桌面系统的构件技术，主要为本地的OLE应用服务，但是随着操作系统NT和DCOM的发布，COM通过底层的远程支持使得构件技术延伸到了分布应用领域。DC