信息集成。企业应用程序不仅需要和数据库交互，还需要和关系数据库并行发展的内容管理系统、数据仓库、工作流系统以及其它企业应用程序交互。在下一节中，我们用一个从实际问题中抽取的方案说明了信息集成的挑战。

方案

为了满足其高端客户的需求并管理大量帐户，一家金融服务公司打算开发一个系统，以便尽可能快地使管理、添加和分发研究信息的过程自动化。该公司订阅了几种用研究信息标记语言（Research Information Markup Language，RIXML）格式发送数据的商业研究刊物，RIXML 是一种将投资研究与描述报告元数据标准格式结合起来的 XML 词汇表 [RIXML]。报告可能会通过各种机制传递，譬如实时消息馈送、电子邮件分发列表、Web 下载和 CD ROM。

图 2. 金融服务方案

图 2 显示了这些研究信息是如何在该公司流转的。

1. 当接收研究报告时，以它的本机 XML 格式归档。
2. 接下来，将诸如公司名称、股票价格、收入估算等重要的元数据从文档中抽取出来，并存储到关系表中，以使它可用于实时和深入分析。
3. 举个实时分析的例子，关系表更新可能引起触发数据库触发器来检测和建议买／卖／持有价位方面的变化，这些变化被迅速发送给股东、证券受托人和经纪人。即时性对于这些接收者而言至关重要，因此这些信息立刻在多处得到复制。触发器也启动了对关键客户的电子邮件通知。
4. 举个深入分析的例子，更彻底地分析原始文档及其被抽取的元数据，寻找诸如“合并（merge）”、“收购（acquisition）”或“破产（bankruptcy）”之类的关键字，以对内容进行分类和汇总。然后将汇总过的信息与该公司的市场调查部和投资银行业务部可用的历史信息合并起来。
5. 这些部门将总结过的信息与存储在电子表格和其它文档中的信息合并起来，以执行趋势预测，并识别合并和收购机会。

需求

要用当前的技术构建金融服务集成系统，该公司必须将许多原本并不能很好地彼此共存的管理系统和应用程序拼凑到一起。DBMS、内容管理系统、数据挖掘包和工作流系统都可以购买，但该公司必须自行开发集成软件以集成它们。数据库管理系统可以处理结构化数据，但 XML 资源库是目前刚刚才面市的。每当增加了新的数据源或信息必须流转到新的目标时，就必须扩展客户自制的解决方案。

上述的金融服务示例以及类似的其它示例表明：原本存在于 DBMS、内容管理系统、中间层高速缓存和数据仓库之间的界限正日益变得模糊，而迫切需要提供所有这些服务的统一视图的平台。我们相信，一个健壮的信息集成平台必须满足下列需求：

• 无缝集成来自多个异构数据源的结构化、半结构化和非结构化数据。数据源包括诸如数据库、文件系统、实时数据馈送和图象及文档资源库之类的数据存储系统，以及与垂直应用程序（如 SAP 或 Calypso）紧密集成的数据。必须很好地支持标准元数据交换、模式映射和无模式处理，并且支持标准数据交换格式。集成平台必须支持合并（从多个数据源收集数据，并存储到中央资源库）和联邦（多个自主源的数据作为搜索的一部分来访问，但数据本身并不移动到平台上）。正如金融服务示例所示，平台还必须提供透明转换支持，以支持多个应用程序重用数据。
• 对存储、交换和转换 XML 数据的健壮支持。对于许多企业信息集成问题而言，关系数据模型太过严格，以致无法用它来有效地表示半结构化和非结构化数据。很明显，XML 比关系数据模型能够表示更多样化的数据格式，因此 XML 成为了企业集成的“通用语言”。水平标准（如 [EBXML]、 [SOAP]等）提供了一种语言，用于交换数据的独立过程，而垂直标准（如 [RIXML]）则旨在处理特定行业的数据交换。结果是，技术平台必须支持 XML，并在所有级别上针对 XML 进行优化。本机 XML 存储是绝对必要的，此外还需要用于 XML 数据检索的有效算法。有效的搜索需要诸如 [SQLX]和 [XQuery]之类的 XML 查询语言支持。
• 对高级搜索能力和分析已集成数据的内置支持。集成平台必须支持两种语言。旧的 OLTP 和数据仓库使用 SQL，而集成应用程序采用 XML。内容管理系统利用专用 API 来管理和查询各种不同的助诊文件集，如文档、音乐、图像和视频。整体系统性能和数据转换操作与数据源之间的路径长度自然地存在着反比关系。因此，无论数据是本地管理的，还是由外部数据源生成的，也不论它是结构化的还是非结构化的，技术平台都必须提供对数据的有效访问。要合并的数据在存储前可能需要进行清理、转换和抽取。要支持需要进行深入分析（譬如上述示例中的银行投资业务部）的应用程序，对于通常与文本搜索和数据挖掘相关联的全文搜索、分类、群集和汇总算法，平台必须提供集成支持。
• 在业务过程中透明地嵌入信息访问。企业在很大程度上依靠工作流系统来规划业务过程。上述金融服务示例是 宏流（macroflow）的示例，宏流是捕获业务过程的多事务步骤序列。其中每个步骤又可能是 微流（microflow），微流是在单个事务中执行的步骤序列，譬如插入从研究报告抽取的数据并因此触发数据库触发器。稳固的集成平台必须提供工作流框架，该框架透明地支持与多种数据源和应用程序的交互。此外，许多业务过程本质上就是异步的。数据源和应用程序在常规基础上开始和结束。数据馈送可能会被硬件或网络故障打断。而且，最终用户（如繁忙的股票商）可能不想通读信息，而更愿意在感兴趣的事件发生时获得通知。集成平台必须嵌入消息传递、Web 服务和队列技术以允许数据源间歇的可用性、延时和故障，并支持应用程序异步性。
• 对标准和多种平台的支持。当然，集成平台必须在多种平台上运行，并支持所有相关的开放标准。生成数据的数据源和应用程序集不会减少，因此健壮的集成平台必须足够灵活，以便在新的数据源和应用程序出现时透明地合并它们。与 OLTP 系统和数据仓库的集成要求很好地支持传统 SQL。要成为有效的业务集成平台，要合并跨行业的标准（如 [SQLX]和 [XQuery]）以及支持垂直应用程序的标准 [RIXML]。
• 易于使用和维护。现今的客户早就需要集成服务，并已经用自己的解决方案将这些服务拼凑起来以集成数据和应用程序，而这些解决方案的开发和维护成本都很大。要提高效率，则替代这些自己的解决方案的技术平台必须降低开发和管理成本。无论从管理和还是开发的角度来看，技术平台都应该尽可能不可见。技术平台应该包括所有数据源公共的数据模型和一致的编程模型。技术平台必须提供元数据管理和应用程序开发工具，以辅助管理员、开发人员和用户构造和利用信息集成系统。

体系结构

图 3 说明了我们对健壮的信息集成平台的建议。

• 该平台的基础是 数据层，它提供了对来自基本数据源的不同格式数据的存储、检索和转换。我们相信，基于增强的功能齐全的联邦 DBMS 体系结构来构建这个基础层是极为重要的。
• 服务层构建在基础之上，它是从内容管理系统和企业集成应用程序中抽取的，用来提供将数据访问服务透明地嵌入企业应用程序和业务过程的基础结构。
• 顶层针对数据层和服务层提供的丰富的服务和数据集提供了基于标准的编程模型和查询语言。

图 3. 信息集成平台

数据层

如图所示，数据层是增强的高性能联邦 DBMS。我们已经描述了 DBMS 成为管理结构化数据的健壮的、高性能和可扩展的技术所经历的演变。我们相信基于 DBMS 体系结构的基础将允许我们将这些关键的优势利用和扩展到半结构化和非结构化数据。

存储和检索。可以将数据存储为结构化关系表、半结构化 XML 文档，或诸如字节流、扫描文档之类的非结构化格式。因为 XML 是企业应用程序的“通用语言”，所以用 XML 文档的本机格式存储和检索它们的一流 XML 资源库是构成数据层有机整体的必要组件。这个资源库是真正的本机 XML 存储，它能够识别和利用 XML 数据模型，而不仅是改头换面的关系记录管理器、索引管理器和缓冲区管理器。它可以充当 XML 文档资源库以及用来合并联邦数据的中间区域（staging area）。在这个角色中，XML 数据的元数据和 XML 数据本身一样重要。这种混合了 XML／关系存储和检索的基础结构不仅确保了两类数据格式的高性能和数据持久性，而且提供了企业数据库管理系统期待的 24x7 可用性和可扩展管理能力。

联邦。除了本地管理的 XML 和关系数据存储器之外，数据层还利用了具有灵活的包装器体系结构的联邦数据库技术来集成外部数据源 [WRAP]。外部数据源可以是传统数据服务器，如外部数据库、文档管理系统和文件系统，或者，它们也可以是企业应用程序，如 CICS® 或 SAP，甚至可以是工作流实例。这些数据源可以提供结构化、半结构化或非结构化数据。

服务层

服务层利用企业应用程序集成系统、内容管理系统的特性，并利用数据层所支持的增强的数据访问能力来提供嵌入式应用程序集成服务。

查询处理。除了为完全不同的数据提供存储和检索服务之外，数据层还提供成熟的查询处理和搜索能力。数据层的核心是