IBM 联邦数据库技术

打印本页

将此页作为电子邮件发送

级别： 初级

Laura Haas, 信息集成开发, 加州圣何塞市
Eileen Lin, 信息集成开发

2002 年 3 月 01 日

在大型现代企业中，信息几乎不可避免地分布在几个数据库管理系统中。尽管许多研究性社团相当关注该领域，但很少有商业性系统试图解决了这一问题。本文描述了这样一项技术：它使客户机能够访问和集成数据，能够专门计算各种关系型和非关系型数据源。

简介

在大型现代企业中，组织中的各部门使用不同数据库管理系统来存储和搜索其重要数据，这几乎是不可避免的。竞争、不断发展的技术、合并、收购、地域分布以及扩展中不可避免的分散等因素都会造成这种多样性。但只有将这些系统中的信息组合起来，企业才会认识到这些系统所包含数据的整体价值。

例如，在金融行业，合并几乎是很常见的事。新创建的实体沿袭了原有机构的数据存储。许多这样的存储都是关系数据库管理系统，但这些系统常常来自不同的厂商；例如，一家公司可能主要用 Sybase，而另一家公司用 Informix® IDS。他们可能都有一个或多个文档管理系统（譬如，Documentum 或 IBM Content Manager）用于存储文本文档（譬如，贷款副本等）。每种系统可能都有一些应用程序来计算重要信息（例如，某个特定客户的贷款风险）或挖掘有关客户购买模式的信息。

在企业合并之后，他们需要能够从两套存储中访问所有客户信息，使用现有的和新的应用程序来分析他们新的资产组合，通常情况下，还要通过一个公共接口来使用两个机构中经过组合的资源。虽然不同公司可能用完全不同的标识键来标识他们的客户，但在合并后他们需要能够标识他们公共的客户，合并这些客户的帐户。在这些情况下，联邦技术通过提供异构数据的统一接口有效地解决这一问题。

IBM 在联邦技术上进行了大量投资，使之在整个数据管理产品系列中取得市场领先能力。现在，联邦技术能够统一地访问任何信息存储中以任何格式（结构化的和非结构化的）表示的任何数字信息。现在，通过各种 IBM 产品 — 包括 DB2® UDB（和 DB2 Relational Connect）、DB2 DataJoiner® 和 IBM Enterprise Information Portal（EIP），还有最新发布的 Information Integrator — 可以使用这些联邦技术。这组联邦技术会继续得到增强，我们的客户在所有这些产品上的投资会继续产生实际的商业价值。

本文主要讨论高级的数据库联邦技术，它们是通过代号为“Garlic”的技术来实现的，这种技术代表了 IBM 软件的下一代信息联邦增强功能。这些增强功能将使客户机能够访问和集成数据，能够专门计算各种关系型和非关系型数据源。随着时间的推移，Garlic 技术将会不断融入 IBM 所有提供联邦技术软件产品之中。客户可以放心，不但他们对现有产品的投资会受到保护，而且以后无论选择哪种产品，他们都将能够利用这里所描述的高级技术。

IBM 的联邦数据库系统为组合来自多个数据源的信息提供了功能强大的工具。IBM 的联邦数据库技术构建在早期产品 DB2 DataJoiner [3] 的最佳技术之上，并且在可扩展性和性能方面，通过应用 Garlic 研究项目 [2] 的一些位于前沿的特性而得到了增强，这些技术在该行业是独一无二的。DB2 DataJoiner 引入了虚拟数据库的概念，这个虚拟数据库是通过联邦多个异构数据源而创建的。DB2 DataJoiner 的用户可以随意查询存储在联邦系统中任意位置的数据，而不必担心数据的位置、实际数据源系统的 SQL 语言种类或者存储的能力。相反，对于联邦数据库中的任何数据，用户可以按照 DB2 的方式来进行操作。Garlic 项目展现了拓展这一思想来构建联邦体数据库系统的可行性，该系统可以有效地使用各种不同的、可能是非关系型数据源的查询能力。在这些系统中（如当今的 DB2），中间件查询处理器促进了优化执行方案，并弥补了各数据源可能缺乏的功能。

在本文中，我们描述 IBM 联邦技术的主要特征：透明性、异构性、高级功能、底层联邦数据源的自治、可扩展性、开放性和优化的性能。然后，我们回过头来向您展示 IBM 的数据库联邦技术是如何工作的。我们演示了在各种情形下如何使用联邦技术，并推断将来的一些发展趋势。

IBM 联邦解决方案的特征

透明性

如果联邦系统是透明的，则它对用户掩盖了底层数据源的差异、特质和实现。最理想的情况是，它使一组联邦数据源对用户而言象是一个系统。用户应该无需知道数据存储在哪里（位置透明）；无需知道数据源支持何种语言或编程接口（调用透明）；如果使用 SQL，无需知道数据源支持哪种 SQL 语支（语言透明）；不需要知道数据是以哪种物理方式存储的，或者数据是否被分区和／或被复制（物理数据独立性、分段和复制透明性）；或者无需知道使用何种网络协议（网络透明性）。用户应该看到一个统一的接口，包括单一的一组错误代码（错误代码透明性）。IBM 提供了所有这些特性，使得在编写应用程序时就好象所有数据都位于一个数据库中，尽管事实上，数据可能存储在异构的数据源集合中。

异构性

异构性是指各数据源之间的差异程度。数据源在许多方面可以不同。它们可以运行在不同的硬件上，可以使用不同的网络协议，以及使用不同的软件来管理它们的数据存储。它们可能具有不同的查询语言、不同的查询能力甚至不同的数据模型。它们处理错误的方式可能不同，或者提供不同的事务语义。它们可能非常类似于这样两个 Oracle 实例：一个运行 Oracle 8i，另一个运行 Oracle 9i，并且模式可能相同或者不同。或者它们的多样性可能类似于这样：一个功能强大的关系数据库，一个简单的结构化平面文件，一个可以采用 URL 形式查询并且可以根据一些 DTD 来发回半结构化的 XML 的网站，一个 Web 服务和一个响应特定函数调用集的应用程序。IBM 的联邦数据库可以容纳所有这些差异，将上述这些系统封装在一个无缝的透明联邦体中。

高级功能

IBM 的联邦技术向用户提供了两全其美的特性：对于联邦体中的所有数据，它具有丰富的、符合标准的 DB2 SQL 能力这些所有功能，以及底层数据源的所有功能。DB2 的 SQL 支持许多复杂的查询特性，其中包括内连接和外连接、嵌套的子查询和表表达式、递归、用户定义的函数、聚集、统计分析、自动摘要表和其它因太多而无法在此逐一列出的特性。许多数据源可能不提供所有这些特性。然而，用户仍然可以对这些数据源的数据使用 DB2 SQL 的完整功能，因为有功能补偿。功能补偿意味着，如果数据源不能执行某个特定的查询功能，则联邦数据库会检索必要的数据，并自己应用该功能。例如，文件系统通常不能进行任意排序。然而，用户可能仍然要求按某种顺序检索来自那个数据源（即某个文件子集）的数据，或者要求消除其中的重复数据。联邦数据库会只检索相关数据，并自己进行排序。

虽然许多数据源没有提供 DB2 SQL 的所有功能，但确实存在许多数据源具有 IBM 联邦数据库所缺乏的专门功能。例如，文档管理系统通常具有记分功能，针对用户的搜索，用这些功能来估计被检索文档的相关性。在金融行业，时间序列数据非常重要，并且存着这样一些系统：它们可以以特有的方式来比较、绘制、分析和划分时间序列数据。在制药行业，新药是建立在具有特殊性质的现有化合物的基础之上。一些具有专门用途的系统可以比较化学结构，或者模拟两个分子的结合。虽然可以直接实现这些功能，但利用数据源和应用程序系统上已有的功能常常会更有效，更节约成本。IBM 允许用户指出联邦数据源中自己感兴趣的功能，然后在查询中使用它们，从而使联邦系统的用户不会丢失数据源的原有功能。

联邦体的可扩展性和开放性

所有系统都需要随时间而发展。在联邦系统内，可能需要新的数据源来满足用户业务不断变化的需求。IBM 使增加新的数据源变得很方便。联邦数据库引擎通过称为包装器的软件组件来访问数据源。通过为那个数据源获得或创建包装器来访问新型的数据源。包装器体系结构支持新包装器的创建。一旦存在包装器之后，简单的数据定义（DDL）语句允许在不停止正在进行的查询或事务的情况下动态地将数据源添加到联邦体。

可以包装任何数据源。IBM 支持 ANSI SQL/MED 标准 [1]（MED 表示外部数据的管理，Management of External Data）。这个标准记载了联邦服务器与外部数据源通信所采用的协议。任何写到 SQL/MED 接口的包装器可以结合 IBM 的联邦数据库一起使用。因而可以由第三方和 IBM 编写包装器，然后结合 IBM 的联邦数据库一起使用。

数据源的自治

通常，数据源有现有的应用程序和用户。所以，当将数据源引入联邦体时，不影响它的操作是很重要的。IBM 的联邦数据库不影响现有数据源的本地操作。现有应用程序的运行不会发生变化，既不会修改数据也不会移动数据，接口也保持相同。尽管对联邦系统执行全局查询可能会涉及各种数据源，但数据源处理数据请求的方式并不受此影响。同样，当数据源进入或离开联邦体时，不会影响本地系统的一致性。唯一的例外是在对加入联邦体的数据源执行联邦的两阶段提交处理期间，会受到影响。（但在 DB2 V7 中不存在这种问题，联邦的两阶段提交用在 DataJoiner 中。）在同一工作单元中所涉及到的数据源将需要参与到提交处理过程之中，如果有必要，可能会要求回滚相关的更改。

与其它产品不同，我们的包装器体系结构不需要在主管数据源的机器上安装任何软件。通过使用数据源正常的客户机，我们通过客户机服务器体系结构与数据源进行通信。用这种方式，使 IBM 的联邦数据源看上去就象这个数据源的另一个应用程序。

优化的性能

优化器是关系数据库管理系统的组件，它决定执行每条查询的最佳方式。关系查询是非过程化的，每个关系运算符通常有几种不同的实现，而且在执行一条查询时，可供选择的运算符的可行顺序有许多种。虽然一些优化器使用启发式规则来选出一种执行策略，但 IBM 的联邦数据库考虑各种可能的策略，对每种策略可能的成本建模，然后选出一种成本最低的策略。（通常，根据所消耗的系统资源来衡量成本。）

在联邦系统中，优化器必须决定是由联邦服务器来执行查询中所涉及到的各种操作还是由存储数据的数据源来执行这些操作。它还必须决定操作的顺序，以及采用哪些实现来执行查询的本地部分。为了做出这些决定，优化器必须以某种方式了解每个数据源能够做什么，了解它的成本如何。例如，如果数据源是一个文件，那么认为它是智能的，并请它来执行排序或应用某种函数，显然是毫无意义的。另一方面，如果数据源是一个关系数据库系统，它能够应用一些谓词，并可做一些连接操作，那么如果利用这个数据源的功能能减少返回给联邦引擎的数据量，那应是个不错的想法。这通常取决于每条查询的具体细节。IBM 优化器对查询中所涉及到的各种数据源使用包装器来评价各种可能性。通常，在执行策略上，好的决定和差的决定所引起的性能差异可以达到几个数量级。IBM 的联邦数据库能够使用包装器来对不同数据源进行联邦查询成本进模，在这方面，它是数据库行业中独一无二的。因此，用户可以期望从他们的联邦系统中获得最佳性能。

为了进一步增强性能，每个包装器实现使用数据源的本机 API 来利用每个数据源所提供的可操作的调节器。例如，将多个生成的行组成一条消息（又名为块存取）是一种常见的性能调整。查询编译器与包装器进行通信以指出哪些查询段可以利用块存取，因而在没有丧失查询语义的情形下，在运行时达到最佳性能。

IBM 的联邦技术是如何工作的

图 1显示了 IBM 联邦数据库的体系结构。应用程序可以使用任何受支持的接口（包括 ODBC、JDBC 或 Web 服务客户机）与联邦服务器交互。联邦服务器通过称为包装器的软件模块与数据源进行通信。

图 1. IBM 联邦系统的体系结构

配置联邦系统

通过安装联邦引擎，然后配置它以与数据源通信，从而创建联邦系统。向联邦系统添加新的数据源包括以下几步。首先，必须安装用于数据源的包装器，然后必须告诉 IBM 的联邦数据库在何处可找到包装器。通过 CREATE WRAPPER 语句可以做到这一点。如果期望添加的多个数据源属于同一类型，则只需一个包装器。例如，即使联邦系统将包含五个可能在不同机器上的 Oracle 数据库实例，也只需要一个 Oracle 包装器，因此只需要一条 CREATE WRAPPER 语句。然而，还必须向系统标识每个单独的数据源。通过 CREATE SERVER 语句可以做到这一点。如果有五个 Oracle 数据库实例，则必须发出五条 CREATE SERVER 语句。

例如，假定有一个用于访问网站的包装器和一个用户希望访问其数据的特定站点。可以通过以下语句通知联邦数据库有关包装器的信息：

CREATE WRAPPER web_wrapper                        LIBRARY "/u/haas/wrappers/libweb.a"

这条语句实质上告诉联邦数据库到哪里去查找 web_wrapper 的代码。接下来，将实际要使用的网站标识为与 web_wrapper 相关联的服务器，从而告诉联邦数据库关于该网站的信息。

CREATE SERVER weather_server                        WRAPPER web_wrapper OPTIONS (URL 'http://www.weatherforecast.com')

OPTIONS 子句的作用是，用该包装器为访问这个数据源类型的实例所需的信息来定制基本的 CREATE SERVER 语句。

在定义好包装器和服务器之后，必须根据联邦中间件的数据模型来描述位于远程数据源中的数据。由于这里所描述的联邦数据库支持对象关系数据模型，因此必须向联邦引擎描述来自外部数据源的每个数据集，并将其描述为具有相应类型列的表。建模为表的外部数据集称为别名（nickname），应用程序向联邦体提交的 SQL 中会用到这个表名和列名。通过 CREATE NICKNAME 语句来定义别名。下面这条语句为有关天气的信息集合设置一个别名，并定义了一些可以在查询中使用的“列”。

CREATE NICKNAME weather                        (zone integer, climate varchar(10),  yearly_rainfall float)                        SERVER weather_server  OPTIONS (QUERY_METHOD 'GET')

“OPTIONS”子句再次起到传递包装器所需信息的作用，这次是为了处理针对别名的查询。

除了存储数据，许多数据源还能够执行特殊的搜索或其它计算。可以在 SQL 中以用户定义的函数表示这些能力。例如，用户可能希望根据地域和日期来预报天气，从而确定购买空调的客户。

SELECT c.Name, c.Address                        FROM customers c, stores s, weather w                        WHERE temp_forecast(w.zone, :DATE) >= 85 AND                        c.ShopsAt = s.id and s.location = w.zone

这里，用 temp_forecast 函数来表示数据源能够预报别名为 weather 的气温。我们称这种由外部数据源实现的用户定义的函数为 映射函数。同样，通过 DDL 语句向联邦系统标识映射函数。CREATE FUNCTION 语句告诉联邦数据库可以在 SELECT 语句中使用该函数。

CREATE FUNCTION temp_forecast (integer, date) RETURNS float AS TEMPLATE                        DETERMINISTIC NO EXTERNAL ACTION

AS TEMPLATE 子句告诉联邦数据库这个函数没有本地实现。接下来，CREATE FUNCTION MAPPING 语句告诉联邦数据库哪个服务器可以对这个函数求值。可以为同一个函数创建几个函数映射。例如，下面这条语句可以完成这样的映射：

CREATE FUNCTION MAPPING tf1 for temp_forecast SERVER weather_server

上面这些 DDL 语句会产生元数据，这个元数据描述了有关映射函数的别名和特征符的信息。联邦查询处理引擎要使用这个元数据，这个元数据存储在联邦数据库的全局目录中。

查询处理

配置好联邦系统之后，应用程序可以向联邦服务器提交用 SQL 编写的查询。联邦服务器优化该查询，产生一个执行方案，其中这条查询被分解为可以在各个数据源上执行的片段。正如上面所提到的，对这条查询可能存在多种分解，优化器根据最少资源总耗估计值从多种可能中做出选择。一旦选定一个方案，联邦数据库就开始执行，调用包装器来执行分配给它们的片段。为了执行某个代码段，包装器会执行任何所需的数据源操作，这些操作也许是一系列函数调用，或者是提交给数据源用其本机查询语句执行的查询。生成的数据流被返回给联邦服务器，由联邦服务器来组合它们，执行任何其它的由数据源无法完成的处理，然后将最终结果返回给应用程序。

IBM 联邦查询处理方法的核心是，联邦服务器的优化器和包装器一起为执行某个查询而形成方案所采用的方式 [4]。优化器负责研究这些可能的查询方案的空间。在连接枚举中，动态编程是缺省方法，优化器首先生成单表访问的方案，然后生成双向连接等。在每一级别，优化器都会考虑各种连接顺序和连接方法，如果所有表都位于一个公共的数据源，则它认为执行这个连接可以在数据源中进行，也可以在联邦服务器上进行。 图 2 显示了这一过程。

优化器的工作方式因使用关系和非关系包装器而有所不同。优化器详细地对关系数据源建模，建模所使用的信息由包装器提供，这些信息是用来生成执行计划，而这些计划表示优化器期望数据源如何执行。

然而，由于非关系数据源确实没有公共的操作集或公共的数据模型，因此对于这些数据源需要更灵活的安排。因而优化器这样使用非关系包装器：

1. 如果称为“请求”的候选查询段适用于单个数据源，则 IBM 联邦数据库向包装器提交该查询段。
2. 在非关系包装器接收到一个请求之后，它确定相应的查询段中哪部分（如果有的话）可以由数据源执行。
3. 包装器返回一个应答，其中描述了查询段已接受的部分。应答还包括对将要产生的行数的估计、对整个执行时间的估计以及包装器方案：包装器将需要知道所有内容的封装表示，才能执行查询段已接受的部分。
4. 联邦数据库优化器将这个应答合并到全局方案中，同时引入其它必要的运算符以弥补包装器不能接受的查询段部分。使用应答中的成本和基数信息来估计这个方案的总成本，从所有候选方案中选出总成本最低的方案。在选定方案之后，不需要立即执行该方案；可以将它存储在数据库目录中，在以后执行该查询时，一次或多次使用该方案。即使立即使用该方案，也不需要在创建该方案的同一过程中执行它，如 图 3所示。

例如，考虑一个播报有关股票信息（包括成交价、开盘价和收盘价以及交易量）的网站。可以通过表单来搜索该网站，这种情况很常见，在表单中可以约束部分属性的值，但不能约束所有属性的值。考虑下面这条查询：

SELECT TickerSymbol, StockName                        FROM Stocks                        WHERE Exchange='NYSE' AND Closing - Opening > 5 

由于这是一条单表查询，因此不需要考虑连接方法或顺序，只有一段包含了整个查询，它将作为对 web 数据源包装器的请求而提交。如果这个表单允许用户指定与底层数据的“Exchange”属性相匹配的值，而没有提供一种方式来指定开盘价和收盘价之间的差价，则包装器会产生一个应答，接受有关“Exchange”的谓词，但拒绝谓词 Closing - Opening > 5 。优化器将通过引入一个运算符在联邦服务器上对后面的谓词求值，以弥补数据源不能完成的工作。通常，包装器必须能够返回 SELECT 列表中所请求的任何单列的值，但可以拒绝任何谓词或更复杂的 SELECT 列表表达式。

除了指出数据源将只对“Exchange”谓词求值外，应答将包括包装器方案，该方案包含足够的信息以执行由该应答所表示的查询。例如，包装器方案可能包含带参数的 URL，这相当于如果用户手工填写好该查询表单之后，浏览器将产生的 URL。在执行时，联邦服务器将该方案返回给包装器，包装器将抽取出 URL，并将它提交给网站，解析产生的数据流，然后将所请求的值返回给联邦服务器。

使用联邦体数据库系统

为什么联邦系统有用？客户如何使用联邦技术？通常，联邦系统在存在多个数据源同时需要将各个数据源的信息组合起来时很有用。在这一节，我们研究一些客户正如何使用 IBM 的联邦技术来解决他们目前的业务问题。

分布式操作：一家大型制药公司

现在，许多公司都是全球性的公司，它们需要协调遍布世界各地的活动。例如，制药公司可能在欧洲和美国有它的研究实验室。每个实验室的科学家都在寻找新的药物来治疗某些特殊疾病。这些科学家都可以访问有关化合物的数据库，这些数据库存储在有专门用途的系统中，可以按这些化合物所具有的特殊特征或化学结构（结构上的相似性）来搜索这些数据库。在这两个实验室里，针对不同的生物体目标，科学家高速地筛选这些化合物来测试它们的效力。这些实验结果被存储在每个实验室的关系数据库中。科学家可以访问的其它数据源包括一些大型的有关染色体和蛋白质信息的平面文件、专利数据库、数据和分析的电子表格以及图象和文本文档。

这两个实验室中的科学家有不同的任务，他们所采用的治疗和医治手段也不一样。这使得他们做不同的实验，关注特定的化合物集合。然而，往往同样的化合物可能对不同的目标都有用，有时一个实验可能很好地揭示其它实验结果。因此，对于位于其中一个实验室的科学家来说，能够访问另一个实验室所得出的数据是很重要的，这样避免了重复劳动。虽然通过建立一个大型的数据仓库（里面有所有的化合物数据和实验结果）可以解决这个问题，但这种方法存在几处缺陷。首先，实验结果数据变化很快，每天需要添加来自大西洋两岸的数千条记录，这造成维护困难。其次，数据仓库必须在两岸进行复制，不然位于某一边的数据库势必得忍受访问数据时的迟缓。复制造成这种解决方案的成本升高，并增加了维护的复杂性。再次，需要将目前存储在专门资源库中的化合物数据迁移到关系数据库中，包括重新实现搜索算法和任何已有的应用程序。

联邦解决方案消除了这些问题。数据留在现有的数据源中，同时也保留了它们的本机存取路径，而且目前的应用程序也未改变运行方式。然而，可以在不考虑所处地域的情况下，方便地建立新的应用程序来访问任意数据源中的数据。为了快速访问，本地数据仍然在本地。如果需要，仍然可以访问不常访问的远程数据，联邦服务器会优化查询以确保尽可能有效地检索这些数据。对于双方实验室都经常访问的那部分数据，如果愿意仍可以进行复制。

异构复制

许多企业选择保留其数据的多个副本。例如，一家大型的零售商在美国各地有一些销售点，它需要备份位于各地区数据仓库中的数据。零售点使用一种关系数据库管理系统；使用另一种可伸缩性更好的 DBMS 来实现数据仓库。然而，这造成如何将数据从数据源传送到数据仓库这样的问题。IBM 的联邦技术不仅使移动数据、从数据源选择数据和向数据仓库插入数据变得方便，而且使重新塑造数据以及在将信息插入到数据仓库之前从各销售点聚集信息变得方便。

IBM 提供了一个复制产品 DB2 DataPropagator™，通过使用联邦数据库的特性以在关系数据库间复制数据，从而帮助您集成分布式数据库环境。DataPropagator 自动复制远程系统间的数据，避免手工卸装和装入数据库。对于非 DB2 关系数据源，定义了 Capture 触发器来捕获对数据源的更改，并将更改写入登台表。在 IBM 联邦数据库服务器上运行的 Apply 程序使用该登台表的别名来将那些更改从登台表复制到 IBM 联邦数据库或另一个非 DB2 关系数据库中的目标表。由于有了联邦技术而使异构复制变得容易。

分布式数据仓库

实现分布式数据仓库一直向人们展示了较高的可用性和较低的总成本。企业可以创建几个数据集市来只存储高级别的汇总数据，这些数据来自数据仓库。有了 IBM 的联邦技术，尽管数据集市和数据仓库可以在单独的系统上，但数据集市的用户仍然可以方便地从他们本地一级的汇总数据下钻到数据仓库。联邦技术通过提供一个虚拟数据仓库，使用户无需知道数据仓库是分布的。

空间地理应用程序

银行需要为它的新分行挑选一个地点。所选定的这个位置必须使预期利润达到最大。为此，银行需要考虑每个位置周围的人口统计信息（该人口统计信息是否符合目标客户基数？），要考虑这个地区的犯罪率（对于零售业务，低的犯罪率很重要），考虑是否靠近主要公路（为了吸引临近地区的客户），考虑是否靠近竞争对手（缺少竞争的地方极可能意味着高的销售额），考虑是否靠近任何已知的问题区域，必须避免这些区域（周围的垃圾堆或其它惹人讨厌的特征会对业务产生负面影响）。其中一些必要信息将来自银行自己的数据库。另一些信息必须检索外部的数据存储（包含有关这个社区的信息）来获得。这个应用程序展示了需要集成空间地理数据和传统业务数据。它需要高级的查询分析功能来关联数据，需要可在空间地理上下文中以可视化方式显示数据的最终用户工具。

通常，空间地理数据一直由专门的地理信息系统（GIS）来管理，但它不能将空间数据与存储在公司 RDBMS 以及外部数据源中的其它业务数据集成起来。DB2 Spatial Extender 是 IBM 与其业务伙伴 Environmental Systems Research Institute（ESRI）合作开发出的产品。DB2 Spatial Extender 使用 IBM 的联邦数据库向客户提供了两全其美的解决方案。客户可以利用内建在 DB2 Spatial Extender 之中、并结合了联邦系统中大量可用业务信息的地理空间智能。这使组织可以增强对自己业务的理解，利用已有数据的价值，构建复杂的新的应用程序，从而使企业走向成功。

结束语

尽管许多研究性社团相当关注该领域，但很少有商业性数据库管理系统已经解决了将关系和非关系数据源集成到联邦体中这一问题。有了这种联邦技术，IBM 已经朝这个目标迈出了一大步。IBM 独一无二的联邦查询处理技术使用户可以体验到 DB2 SQL 的所有强大功能与每个数据源的强大功能相结合而产生的威力。它向用户提供这些好处：透明性、异构性、高级功能、底层联邦数据源的自治、可扩展性、开放性和优化的性能。今天，我们正在使用联邦体来解决许多重要的商业需求。

在未来，我们将继续工作以改进联邦体的性能和功能。例如，已经运用自动摘要表（AST）机制实现了某种形式的高速缓存，它使管理员可以定义一组底层表中数据的具体化的视图 — 即别名。对于某些类型的查询，数据库可以自动地确定是否使用 AST 回答查询，而不用访问基本表。除了不断改进性能之外，我们还在研究一些工具来帮助配置、调优和管理联邦系统。我们正在开发为来自非关系数据源的数据生成统计信息的工具，以及用于监控联邦系统行为的工具。目前我们还在开发那些帮助包装器开发人员的工具。

最后，即使设计良好的联邦数据库管理系统及其附带的一套工具也只是数据集成这个较大问题的部分解决方案。完整的解决方案将必须集成应用程序和数据，并解决一些较高级别的问题，如数据质量、注释、术语方面的差异与表明何时以及用何方式组合信息的业务规则。IBM 正将注意力集中在这种更广泛的信息集成需求，以使客户实现他们自己的业务集成需求，而数据库样式的联邦体正是关键的集成技术之一。

参考资料

• [1] ISO/IEC 90759:2000。Information technology -- Database languages -- SQL -- Part 9: Management of External Data（SQL/MED）。国际标准化组织，2000 年。
  
  
• [2] M. Carey et al。Towards heterogeneous multimedia information systems。In Proc. of the Intl. Workshop on Research Issues in Data Engineering，1995 年 3 月。
  
  
• [3] P. Gupta 和 E. T. Lin。Datajoiner: A practical approach to multidatabase access。In Proc. of the Intl. IEEE Conf. on Parallel and Distributed Information Systems, Austin, TX, USA, 1994 年 9 月。
  
  
• [4] V. Josifovski、P. Schwarz、L. Haas 和 E. Lin。“Garlic: A New Flavor of Federated Query Processing for DB2”。In Proc. SIGMOD 2002, Madison, WI, USA, 2002 年 6 月。
  

作者简介

Laura HaasLaura Haas 是 IBM Software Group 的高级经理，她负责 DB2 UDB 查询编译器的开发，包括信息集成和生命科学的关键技术，譬如联邦数据库和 XML 查询。以前，Haas 博士曾是 IBM Almaden 研究中心的研究成员和经理。

Eileen LinEileen Lin 是加州圣何塞市硅谷实验室的高级软件工程师。她曾是促使 DataJoiner（联邦数据库产品，它是 V7 中 DB2 联邦系统的前身）取得成功的最初成员之一。Lin 博士目前是 DB2 和 Discoverylink™ 联邦功能的技术负责人。