使用 IBM WebSphere Information Integrator 中的数据联邦技术

简介

也许，当今企业信息管理的最大挑战就是数据源的多重性、异构性和地理位置上的分散性。有很多因素可以导致公司中的这种数据复杂性 —— 例如，将具有不同 IT 基础设施的组织组合起来的合并和收购，从本地公司到跨国公司的业务增长，不同时期采用的不同的用于构建信息系统的不同技术，等等。不管这个问题有多么困难，同步和管理不同数据源仍是使企业保持竞争力的关键需求。

通过无缝地将多个数据源放入到一个联邦系统，IBM WebSphere Information Integrator 提供了取得以下目标的能力：

透明性： 就像数据处于同一个数据库中一样来编写和使用应用程序。

异构性： 容纳企业中不同的数据需求和数据源。

自治性： 不对远程数据源施加限制，允许远程数据源自治。

高功能性： 应用程序不仅可以利用联邦系统提供的高功能性（请参阅 参考资料 了解更多信息），而且还可以利用一些数据源独有的特殊功能。

可扩展性和开放性： 能够无缝地添加新数据源到企业信息系统中。

优化的性能： 为联邦系统开发的应用程序可以取得强大的性能，并且不需要实施特殊的策略来计算查询。

WebSphere Information Integrator 基于 IBM DB2® Universal Database™ for Linux、UNIX®, and Windows®，它在已经可用的数据联邦技术中添加了很多新的特性。DB2 Universal Database 为访问和组合来自不同关系数据源的信息提供了强大的工具（参阅 参考资料）。DB2 Universal Database 中特有的数据联邦功能建立在来自 IBM DB2 DataJoiner® 的最优供给（best-of-breed）技术的基础上，并增加了 IBM 的 Garlic 研究项目中用于可扩展性和性能的高级特性（要了解关于 DataJoiner 或 Garlic 的更多信息，请参阅 参考资料）。

本文是一个系列中的第一篇文章，这个系列将展示如何使用 WebSphere Information Integrator 中的技术。对于那些拥有 SQL 方面的基础以及正在使用和管理诸如 DB2 之类关系数据库的读者，本文提供了关于建立和配置 WebSphere Information Integrator 联邦数据库系统的全面指南。第二篇文章将着重于用法示例和性能调优。

一个电子商务场景

图 1 描述了一个电子商务场景，在这个场景中，客户在线提交订单。这些 XML 文档格式的订单被路由到全局仓库，而客户信息则是维护在一个名为 CUSTOMERS 的本地数据库表中。

图 1. 客户下订单场景

通过使用 WebSphere Information Integrator 中的联邦技术，全局仓库被连接到位于美国和加拿大的两个地区仓库。在每个仓库中，关于商品和供应商的信息存储在表 ITEMS 和 SUPPLIERS 中。此外，对应于每种商品的商品 ID 和供应商 ID 存储在表 ITEM_SUPPLIED 中。美国仓库基于 DB2 for z/OS 和 OS/390 系统，而加拿大仓库在一个 Oracle 系统中。另一个名为 Credit Checking 服务器的 Oracle 实例跟踪具有不良信用历史的客户，这个实例可以从联邦系统中访问到。

设计联邦系统

WebSphere Information Integrator 联邦系统的核心由一个 DB2 实例组成，该实例用作联邦服务器。其他组成部分包括一个充当联邦数据库的数据库，一个或多个数据源，以及访问数据库和数据源的客户机（用户和应用程序）。有了联邦系统，便可以使用一条 SQL 语句将分布式请求发送到多个数据源。在联邦系统上注册远程数据集之后，可以像引用本地表那样引用这些数据集。应用程序通过一个受支持的编程接口与联邦服务器通信。由于联邦系统包括一个 DB2 数据库，所以还可以将本地数据存储在这个数据库中，也可以存储来自本地表和远程表的组合信息。

对于电子商务的例子，下面的 图 2 描述了将被查询的现有表的列定义。

图 2 展示了 图 1 中引用的表的实体关系图。表 ITEMS 和 SUPPLIERS 分别在列 item_id 和 suppl_id 上定义了检查约束。这些约束规定了数据的范围。

图 2. 表的实体关系图

现在可以建立联邦系统，以便注册这些远程表。全文提供了示例 DDL （数据定义语言）语句。要获得详细的用法描述，请参阅 IBM DB2 Information Integrator Data Source Configuration Guide，以及 DB2 UDB SQL Reference 的卷 1 和卷 2（见 参考资料）。另一种注册方法是使用增强的 DB2 Control Center 图形界面注册远程对象。Control Center 提供了远程对象发现功能，它能够自动发现可以被包括在联邦中的数据源和对象。

配置联邦系统

首先通过安装联邦引擎来创建一个联邦系统，然后配置该联邦系统，以便与数据源通信。有四种基本的联邦对象：

联邦服务器通过名为 包装器（wrappers） 的软件模块与数据源通信。

每个数据源必须被系统识别为服务器（server）。

如果数据源要求认证，那么可以在联邦系统中将远程认证信息注册为用户映射（user mapping）。

将要访问的远程数据集标识为 昵称（nicknames）。 现在便可以在应用程序中引用这个昵称，就像它是一个本地表一样。

接下来的几个小节逐个研究这些联邦对象。

包装器

包装器模块提供用于方便以下事情的逻辑：

联邦对象注册： 包装器封装了来自联邦引擎的数据源特征。它知道为了注册各种类型的数据源需要什么样的信息。

与数据源通信： 通信包括建立和终止与数据源的连接，并且在可能的情况下在应用程序中各语句之间维护连接。

服务和操作： 每个包装器支持不同的操作，这取决于包装器要访问的数据源的能力。这些操作可以包括发送一条查询来获取结果，更新远程数据，支持事务，操纵大型对象，绑定输入值，等等。

数据建模： 包装器负责将远程查询结果的数据表示映射为联邦引擎所要求的表格式。

WebSphere Information Integrator 为不同类型的数据源提供了一组包装器。您可以使用该产品中包含的包装器开发工具箱来编写一个定制的包装器库，这样便可以访问现有包装器不支持的数据源。欲知 WebSphere Information Integrator 所支持的数据源的列表，请参阅 IBM DB2 Information Integrator Data Source Configuration Guide（见 参考资料）。

当使用包装器来访问数据时，如果包装器是以数据源的本地 API 实现的，那么通常可以获得最佳性能。例如，虽然 ODBC 包装器也可以提供那样的访问，您很可能会选择 NET8 包装器来访问 Oracle 数据源。

为了访问包装器支持的所有数据源，只需注册一个包装器。例如，如果您需要访问 XML 文件，那么需要注册一个 XML 包装器。

包装器模块可以在 DB2 引擎内执行，这被称为受信任（trusted）模式。如果在 DB2 引擎外的一个单独的进程中运行包装器模块，则称为隔离（fenced）模式。通常，如果联邦数据库不是分区的，受信任模式可以提供更好的性能。然而，包装器模块的健壮性可能直接影响 DB2 引擎。如果联邦服务器是一个分区数据库，那么隔离模式可以更好地利用并行。您可以通过将 DB2_FENCED 包装器选项设置成“Y”来指定是否以隔离模式执行包装器（该选项的默认设置是“N”，即受信任模式）。S. Harris 撰写的文章“Parallelism in WebSphere Information Integrator V8.2”（见 参考资料）对此进行了详细的讨论。

在在线购物的场景中，需要三个包装器：用于两个 Oracle 系统的一个 NET8 包装器，用于 DB2 for z/OS 和 OS/390 系统的一个 DRDA 包装器，以及用于从 XML 文档访问在线订单的一个 XML 包装器。为了将包装器注册到联邦系统，使用以下 SQL 语句：

CREATE WRAPPER net8;
CREATE WRAPPER drda;
CREATE WRAPPER xml_wrapper LIBRARY ?libdb2lsxml.a?;

图 3 展示了遵循这个步骤的联邦系统配置。三个包装器提供了对四种数据源的访问（包括包含 Web 订单的 XML 文件）。对于这里使用的包装器，需要一些客户机库。例如，对于 NET8 包装器需要 Oracle NET8 客户机软件。图 3 中没有显示这些客户机库。

图 3. 联邦系统

服务器

在将包装器库注册到联邦系统之后，将每个数据源注册为一个服务器。对于关系数据库管理系统，一个服务器通常代表一个远程数据库。如果数据源是一个远程 DB2 Universal Database 实例，那么可以将那个实例上的每个数据库注册为一个服务器。通过将每个数据库注册为一个服务器，可以使这些远程数据库上的数据能够从联邦系统访问到。

有些关系数据库管理系统不允许每个实例注册多个数据库。相反，每个实例代表一个服务器。例如，在 Oracle 系统上，每个实例服务器 ID（SID）代表一个服务器。

在我们的在线商店中，需要定义 4 个服务器。DB2 for z/OS 和 OS/390 源可能需要编目附加的节点和数据库条目。使用下面的命令完成这一任务：

CATALOG TCPIP NODE mvsnode REMOTE hostname SERVER servicename;
CATALOG DB mvsdb2 AS mvsdb2 AT NODE mvsnode AUTHENTICATION SERVER;
CREATE SERVER usa_server TYPE db2/390 VERSION 7.1 WRAPPER drda
　　AUTHORIZATION ?MVSUSER1" PASSWORD ?password"
　　OPTIONS (DBNAME ?MVSDB2?);

类似地，为了注册一个 Oracle 服务器，可以使用在 Oracle 客户机中配置的节点名来引用它。这个值存储在文件 tnsnames.ora 中。对于例子联邦系统，完成 Oracle 和 XML 服务器注册的 SQL 语句为：

CREATE SERVER canada_server TYPE oracle VERSION 9 WRAPPER net8
　　OPTIONS (NODE ?nodename?);
CREATE SERVER credit_server TYPE oracle VERSION 8.1.7 WRAPPER net8
　　OPTIONS (NODE ?nodename?);
CREATE SERVER xml_server WRAPPER xml_wrapper;

服务器选项

WebSphere Information Integrator 联邦系统依赖于服务器属性来确保每个数据源的能力得到适当的利用。联邦服务器上的服务器属性存储每个数据源的特征。当计划查询时，查询编译器使用这些特征和约束。通过使用服务器选项来设置外部服务器属性，可以指定数据源的位置（机器节点）、连接安全信息（ID 和密码）以及一些影响性能的服务器特征。每个包装器模块维护一组属于它支持的类型和版本的数据源的服务器属性。

“下推”操作，即让操作发生在远程数据源，是很有益的。例如，如果某些 SQL 操作将减少返回到联邦服务器的数据的数量，那么通过将这些操作下推的远程数据源就可以减少通过网络传输到联邦服务器的数据量，从而有助于提高查询的性能。允许操作下推的主要挑战是确保无论在何处执行操作，取得的查询结果总是相同的。

有些属性，例如 COLLATING_SEQUENCE，会影响哪些操作可以下推到数据源来执行。这个服务器属性告诉联邦服务器远程数据源和本地联邦服务器上的排序序列是否相同。除了允许将字符串数据存储在远程数据源之外，这个服务器选项还允许在远程执行范围比较（例如 string_col > string_constant）和 LIKE 谓词。取决于操作的不同，允许在远程数据源上执行操作可能有助于查询的整体性能。

例如，DB2 for z/OS 和 OS/390 之类的数据源使用基于 EBCDIC 编码模式的排序序列。对于那样的数据源，服务器选项 COLLATING_SEQUENCE 的默认设置是“N”，因为 EBCDIC 编码模式是特定于 DB2 for z/OS 和 OS/390 的。默认情况下，DB2 Universal Database 使用 ASCII 编码，默认的排序序列是字典顺序。

虽然像 Oracle 这样的其他一些数据源也使用 ASCII 编码，但它们的排序序列不同于 DB2 Universal Database 的排序序列。可以配置联邦系统，以匹配像 Oracle 这样的数据源的排序序列，后者使用 IDENTITY 顺序。为此，在 CREATE DATABASE 语句中添加 COLLATE USING IDENTITY 子句。在这个例子中，对于使用 ASCII 编码和 identity 排序序列的数据源，可以将服务器选项 COLLATING_SEQUENCE 设置为“Y”。

联邦系统提供 SET 服务器选项语句。如果希望服务器选项设置在应用程序连接到联邦服务器时保持有效，可以使用这个语句。当连接结束时，之前的服务器选项被恢复。

用户映射

为了提供一个附加的安全层，WebSphere Information Integrator 支持用户映射。可以为每个 WebSphere Information Integrator 用户创建到远程数据源上的 ID 和密码的映射。可以为关系数据源和一些非关系数据源定义那样的用户映射。XML 文件不需要注册用户映射，因而没有附加的认证层。对于例子联邦系统，用于注册代表一个用户的用户映射的 SQL 语句为：

CREATE USER MAPPING FOR user SERVER usa_server
　　OPTIONS (REMOTE_AUTHID ?mvsuser1?, REMOTE_PASSWORD ?password?);
CREATE USER MAPPING FOR user SERVER canada_server
　　OPTIONS (REMOTE_AUTHID ?orauser1?, REMOTE_PASSWORD ?password?);
CREATE USER MAPPING FOR user SERVER credit_server
　　OPTIONS (REMOTE_AUTHID ?crduser1?, REMOTE_PASSWORD ?password?);

如果用于连接到联邦数据库的用户 ID 和密码与用于访问远程数据源的用户 ID 和密码相同，那么不需要创建用户映射。但是，如果不使用用户映射，应确保在连接到联邦数据库时隐式地指定用户 ID 和密码。例如：

CONNECT TO my_federated_db USER etlin USING etlin_pwd

pass-through 会话和权限

pass-through 会话允许直接提交 SQL 语句和部分命令到一个远程服务器。在远程认证注册后，如果数据源的 pass-through 受支持，那么可以用它来测试到那个数据源的连接。在进入昵称注册之前的这一阶段测试连接，有助于隔离配置问题。

在 pass-through 会话中提交的 SQL 语句和命令不会通过联邦查询编译器。DB2 Universal Database 假设 pass-through 会话包括一些对远程服务器的“write”操作。结果，如果有一个包含到服务器 A 的 pass-through 会话的事务，则相同的事务不能对联邦服务器上的本地数据或服务器 A 之外的不同服务器上的远程数据执行任何“write”操作。

联邦系统的管理员控制哪些 DB2 用户可以打开到一个远程服务器的 pass-through 会话。通过使用 GRANT PASSTHRU 语句可以授权访问。例如：

GRANT PASSTHRU ON SERVER credit_server TO GROUP managers;

在授予了 pass-through 权限之后，受影响的用户（例如前面例子中那些属于组管理员的用户）就可以使用 pass-through 功能。下面的例子在 Oracle 服务器上开始等价的 RUNSTATS 操作：

SET PASSTHRU credit_server;
ANALYZE TABLE bad_credit COMPUTE STATISTICS;
SET PASSTHRU RESET;

仅仅拥有 pass-through 权限还不足以通过 WebSphere Information Integrator 访问数据源。

昵称

表和视图之类的远程对象在联邦服务器上以昵称的形式注册。对于关系昵称，包装器确认数据源对象是否存在，如果定义了昵称，还将获取列定义和索引信息。如果在数据源上维护的统计信息类似于联邦系统上的统计信息，则包装器昵称注册函数将从远程系统编目查找和获取统计信息。

准确的索引信息和统计信息是查询优化器中基于成本的决策的基础。在一个联邦系统上，为了为某些数据源执行 UPDATE/DELETE 操作，需要惟一的索引信息。如果在更新之前需要在本地存储数据（例如，被更新的表在一个谓词中相同的 UPDATE 语句上也被引用），联邦系统使用一个惟一的索引来模拟不支持 rowid 的数据源（例如 DB2 家族）的定位游标。关于列定义、索引以及昵称统计信息的信息存储在 DB2 联邦数据库系统编目中。

昵称的注册提供了位置透明性，因为昵称对于联邦服务器上的用户来说看上去就像一个本地 DB2 表。由于关系数据源通常提供关于一个对象的列定义的系统编目信息，DDL 语法只需标识您要为之创建昵称的远程对象。

下面的语句为例子场景定义关系昵称：

CREATE NICKNAME usa.items FOR usa_server.mvsuser1.items;
CREATE NICKNAME usa.suppliers FOR usa_server.mvsuser1.suppliers;
CREATE NICKNAME usa.item_supplied FOR usa_server.mvsuser1.item_supplied;
CREATE NICKNAME canada.items FOR canada_server.orauser1.items;
CREATE NICKNAME canada.suppliers FOR canada_server.orauser1.suppliers;
CREATE NICKNAME canada.item_supplied FOR canada_server.orauser1.item_supplied;
CREATE NICKNAME bad_credit FOR credit_server.crduser1.bad_credit;

由于为大多数非关系数据源定义昵称的语法包含更多的细节，在为一些数据源（例如表结构文本文件）注册昵称时可能需要提供列定义。WebSphere Information Integrator 中的 Control Center 为 XML 昵称提供了一个自动的昵称 DDL 生成工具，所以这里给出的 DDL 语句仅供参考。由于客户订单通常包含一组商品，所以用两个昵称来表示。

CREATE NICKNAME xml.orders
　　(order_id char (10) OPTIONS (XPATH ?@id?),
　　 order_date date OPTIONS (XPATH ?date/text()?),
　　 customer_id char (10) OPTIONS (XPATH ?cid?),
　　 order_amount decimal (31, 2) OPTIONS (XPATH ?./amount/text()?),
　　 oid varchar (16) OPTIONS (PRIMARY_KEY ?YES?))
FOR SERVER xml_server
OPTIONS (FILE_PATH ?/home/administrator/orders/orders.xml?,
　　 XPATH?//order?);
CREATE NICKNAME xml.order_items
　　(oid varchar (16) OPTIONS (FOREIGN_KEY ?ORDERS?),
　　 item_id char (10) OPTIONS (XPATH ?./item_id/text()?),
　　 item_quantity integer OPTIONS (XPATH ?./quantity/text()?))
FOR SERVER xml_server
OPTIONS (XPATH ?.//item?);

昵称选项

通过改变某些昵称属性，可以考虑叠加哪些操作，以提高性能。

在注册一个关系数据源上的一个数据源对象时，默认的类型映射决定如何将一个数据源数据类型映射到每个列的 DB2 类型。这些映射被内置在包装器模块中。要获得每个数据源的默认类型映射列表，请参阅 IBM DB2 Information Integrator Federated Systems Guide（见 参考资料）。

您可能希望将一种列类型改为另一种列类型，以便进一步匹配数据。例如，默认情况下 Oracle DATE 类型被映射为 DB2 TIMESTAMP 类型。但是，如果类型为 DATE 的一个列只用于存储雇员的生日，那么就可以将它映射为 DB2 DATE 类型。将本地列定义为 DATE 类型比较方便，因为这样可以允许涉及 DATE 文字但是不需要覆盖函数（对性能有影响）的谓词。

通过 ALTER NICKNAME 语句，您可以选择为远程对象更改联邦服务器上的列数据类型。还可以使用这条语句来定制昵称列的名称。默认情况下，列名被设为相同昵称列的远程名称。

至少可以通过设置两个列选项来提高联邦服务器对远程数据的理解，并鼓励下推更多的操作。这两个选项是 VARCHAR_NO_TRAILING_BLANKS 和 NUMERIC_STRING。

使用 VARCHAR_NO_TRAILING_BLANKS 列选项来标识不包含结尾空白的昵称列。查询编译器在检查字符比较操作时使用该信息，以决定如何执行操作。DB2 Universal Database 使用以空白填充的比较语义 —— 也就是说，当比较长度不相等的字符串时，较短字符串的副本在右边被填上空白，使其长度与较长字符串的长度相同。这意味着字符串“A”被认为等同于 DB2 Universal Database 中的“A ”。

然而，这种行为并不适用于所有数据源上的所有字符数据类型。例如，Oracle 中的 VARCHAR2 数据类型就不具备这样的行为。通常，不具备空白填充比较语义的字符串列上的比较需要在本地计算，除非查询编译器能够发现在远程强制类似逻辑的函数。基本前提是，无论在何处计算查询的任何部分，查询结果都应该一致。

为了补偿空白填充比较语义的差异，对于谓词之类的一些操作，联邦系统重新编写谓词，以确保当这些谓词被送到 Oracle 服务器时具有相同的语义。DISTINCT、ORDER BY、GROUP BY、UNION、列函数（MIN()/MAX()）计算、关系比较以及 IN 谓词之类操作的性能可能受到影响。通过设置 VARCHAR_NO_TRAILING_BLANKS 列选项通常可以提高性能，因为它允许下推更多的操作，以及对远程 SQL 语句的更多优化，以鼓励索引访问。

如果您确信来自这个 Oracle 服务器的所有 VARCHAR2 列都没有结尾空白，那么也可以将 VARCHAR_NO_TRAILING BLANKS 作为一个服务器选项来设置。通常难于施加那样的约束。因此，不建议将 VARCHAR_NO_TRAILING_BLANKS 作为服务器选项使用。

NUMERIC_STRING 是另一个对性能有影响的列选项。它适用于字符数据类型以及 COLLATING_SEQUENCE 服务器选项没有被设为“Y”的那些数据源。

如果联邦系统和数据源的排序序列中存在不同之处，那么只有在不管在何处计算操作，取得的查询结果总是一样的情况下考虑将操作下推。然而，如果列是字符数据类型，并且只包含数字字符，那么可以通过将 NUMERIC_STRING 选项设置为“Y”来表明这一点。这种设置使联邦编译器可以选择允许数据源执行可能受不同排序序列影响的操作 —— 因为数字总是按相同顺序排序。

对于我们的例子，item_id 是一个 CHAR 列，它只存储数字字符，如以下语句所示：

ALTER NICKNAME usa.items ALTER COLUMN item_id
　　OPTIONS (ADD NUMERIC_STRING ?Y?);
ALTER NICKNAME usa.item_supplied ALTER COLUMN item_id
　　OPTIONS (ADD NUMERIC_STRING ?Y?);
ALTER NICKNAME canada.items ALTER COLUMN item_id
　　OPTIONS (ADD NUMERIC_STRING ?Y?);
ALTER NICKNAME canada.item_supplied ALTER COLUMN item_id
　　OPTIONS (ADD NUMERIC_STRING ?Y?);

昵称上的信息约束

如果远程表包括诸如主键约束或其他形式的约束的属性，那么在联邦系统中可以通过在昵称上指定信息约束（informational constraint） 来捕捉这些约束。惟一约束、主键约束、参照约束、检查约束和函数依赖约束在这里都受支持。SQL 编译器使用信息约束来提高查询性能。信息约束提供关于数据的更多信息，并支持更多的优化。在诸如 insert、delete 和 update 操作期间，联邦服务器不施加信息约束。

在例子数据模型中，列 item_id 和 suppl_id 是远程表 items 和 supplier 中的主键。对于诸如 DB2/390 和 Oracle 之类的数据源，联邦系统自动在 CREATE NICKNAME 命令期间获取远程主键信息。确认联邦系统是否捕捉主键信息的简单方法是用以下语句查询编目视图 SYSCAT.TABCONST：

SELECT CHAR(constname, 30), type
FROM syscat.tabconst
WHERE tabname = 'ITEMS' and tabschema = 'USA';

当定义一个主键约束时，联邦系统自动创建一个惟一的索引规范。

此外，列 item_id 和 suppl_id 被定义为远程表 item_supplied 的外键。可以使用以下命令通过定义 信息参照约束 将该信息传递到联邦系统：

ALTER NICKNAME canada.item_supplied ADD CONSTRAINT fk1
　　　　　FOREIGN KEY (item_id) REFERENCES canada.items(item_id)
　　　　　NOT ENFORCED;
ALTER NICKNAME canada.item_supplied ADD CONSTRAINT fk2
　　　　　FOREIGN KEY (suppl_id) REFERENCES canada.supplier(suppl_id)
　　　　　NOT ENFORCED;

可以使用类似的定义来定义 usa.item_supplied 昵称上的外键约束。NOT ENFORCED 自己简单地指定，在联邦服务器上不施加该约束。它只是被 SQL 编译器用于优化联邦语句。如果您想通过编译器禁用约束，那么可以使用 DISABLE QUERY OPTIMIZATION 子句。例如：

ALTER NICKNAME canada.item_supplied ALTER FOREIGN KEY fk1
　　　　　DISABLE QUERY OPTIMIZATION;

如果远程表在数据上有检查约束，那么可以使用 信息检查约束 将这些约束传递到联邦服务器。知道这些约束有助于联邦服务器进一步简化用户查询。

给 items 和 suppliers 的定远程表定义，便可以用以下语句声明相应昵称上的检查约束：

ALTER NICKNAME canada.items ADD CONSTRAINT ck
　　CHECK (item_id BETWEEN '0000000001' AND '5000000000');
ALTER NICKNAME usa.items ADD CONSTRAINT ck
　　CHECK (item_id BETWEEN '5000000001' AND '9999999999');

为 supplier 昵称定义类似的约束：

ALTER NICKNAME canada.supplier ADD CONSTRAINT ck
　　CHECK (suppl_id) BETWEEN '0000000001' AND '2000000000');
ALTER NICKNAME usa.supplier ADD CONSTRAINT ck
　　CHECK (item_id) BETWEEN '2000000001' AND '3000000000');

如果在主键列上存在信息检查约束，那么应该在它们相应的外键列上指定信息检查约束。例如：

ALTER NICKNAME canada.item_supplied ADD CONSTRAINT ck1
　　CHECK (item_id) BETWEEN '0000000001' AND '5000000000');
ALTER NICKNAME canada.item_supplied ADD CONSTRAINT ck2
　　CHECK (suppl_id) BETWEEN '0000000001' AND '2000000000');

添加类似的信息到 usa.item_supplied 昵称中。

索引规范

在关系昵称的注册步骤中，包装器模块试图获取底层对象的远程编目信息。有时候，定位索引信息是不可能的 —— 远程数据源可能没有用于索引的系统编目，或者远程对象在远程系统编目中可能没有与之相关的任何索引。在昵称创建后，可能会添加一个远程索引到数据源上的远程对象。您可以为这个远程对象定义一个索引规范，以使得联邦服务器知道索引，并且便于对这个远程对象的访问。这条语句的语法是 CREATE INDEX 语句的一个扩展（请参阅 DB2 UDB SQL Reference 获得更多信息）。在联邦服务器上，不会建立代表该昵称的物理索引。一个条目被添加到系统编目中，以向查询优化器表明存在那样的一个远程索引。清楚所有适用的远程索引有助于联邦查询优化器生成更好的执行计划。

定义惟一索引的索引规范还将关于索引列惟一性的信息传递给联邦系统。就像在关系昵称注册期间注册的一个常规的惟一索引定义一样，通过诸如消除不必要的 DISTINCT 操作的策略，那样的信息可以帮助查询优化器生成更佳的计划。

远程视图的昵称

可以定义远程视图的昵称，就像定义远程表的昵称一样。如果您想将定义远程视图的查询下推到数据源，那么定义远程视图的昵称会比较有用。在性能测试中这比较有用。但是，对于大多数常见情况，不建议将这作为长远的解决方案。

远程数据源上通常不提供关于一个视图的索引或统计信息。如果视图可以在内部使用索引，那么可以创建一个索引规范，存储在联邦服务器上的 DB2 数据库系统编目中，供查询优化器使用。

准确地表示一个远程视图的统计特征很有技巧。如果视图代表远程数据源上的一个表，那么可以通过一个简单的程序用底层基本表的统计信息更新 DB2 联邦数据库编目中的昵称统计信息。

如果远程视图包含一个复杂的查询，那么使用表级统计信息（例如视图昵称的基数）可能使人产生误解。例如，基于一个非常复杂的、只返回 5 行的查询（例如一个 GROUP BY 查询）的视图在远程数据源上计算起来代价较高。但是，如果表示这种复杂查询的视图的成本将在联邦服务器上和表级统计信息（即表基数）一起建模，那么访问 5 行就使得这个远程视图的计算成本显得非常廉价。这对于查询的优化有着不良的影响。

更好的解决办法是定义每个远程表的昵称，必要的时候在联邦服务器上定义这些昵称上的视图。这使得查询优化器可以更有效地分析复杂的查询，因为现在统计信息近似地反映实际成本。

昵称统计信息

WebSphere Information Integrator 使用基于成本的优化器，因此对于要实现优化计划的优化器，准确的统计信息的可用性至关重要。当前，您可以使用下面几种方法中的一种来收集昵称的统计信息：

昵称创建：

当创建昵称时，包装器通过查找远程数据源编目上的可用统计信息，并将那些统计信息映射为 DB2 统计信息（适用的情况下），从而收集要创建的昵称的一些统计信息：

表 1. 表统计信息

表 2. 列统计信息

表 3. 索引统计信息

重要的是，必须在数据源上运行“runstats”实用程序的等价物，以便昵称创建接受当前的统计信息。并不是每个包装器都能够收集上面列出的所有统计信息，因为数据源统计信息与其在联邦系统上的对等物之间可能不存在映射。如果为一个昵称收集了统计信息，那么在数据源上对相应远程表的远程统计信息进行更新时，这些统计信息不会自动更新。

如果有一个昵称，它的统计信息需要更新，以反映在其数据源上新出现的远程统计信息，那么您可能会忍不住删除和重新创建该昵称。然而，这样做也将删除其他的数据库对象，例如依赖于这个昵称的索引。下面给出了更新统计信息的两种方法 —— 不删除依赖于昵称的对象。

Control Center 中的昵称统计信息更新功能或命令行上的 SYSPROC.NNSTAT 存储过程：

Control Center 中的昵称统计信息更新功能和命令行上的 SYSPROC.NNSTAT 存储过程都获取对应于一个已有昵称的远程对象的远程统计信息。在内部，会创建远程表上的一个影子昵称。这个昵称在昵称创建时收集最新的统计信息。然后将这些新的统计信息从影子昵称复制到已有的昵称。然后再删除影子昵称。

要了解关于如何使用 Control Center 中的昵称统计信息更新功能或存储过程，请参阅 IBM DB2 Information Integrator Federated Systems Guide （见 参考资料）。

getstats 实用程序：

getstats 实用程序发送查询到数据源，以便估计统计信息。例如，表基数是这样来估计的：select count(*) from nick。

这种收集统计信息的方法对于远程视图上的昵称特别有用，因为数据源通常不收集关于视图的统计信息。这种方法对于 ODBC 昵称页有用，因为 ODBC 接口可以连接到任何数据源，而查询优化器不知道远程编目和 DB2 系统编目之间的统计信息映射。

由于 getstats 实用程序只能收集可以通过 SQL 查询得到的统计信息，因此它不能收集数据的物理特征（例如 npages 和 fpages 表统计信息，或 nleaf 和 nlevels 索引统计信息）。而且，由于 getstats 实用程序发出对昵称中的数据的查询，该实用程序的性能取决于昵称所引用的数据量。

昵称权限

与表一样，昵称也有对等的一组权限，用于控制用户在联邦系统上对昵称对象的访问。

GRANT SELECT ON eileen.nick1 TO PUBLIC;
GRANT SELECT ON usa.items TO GROUP managers;

即使用户 eileen 具有访问一个昵称的适当权限，远程数据源仍将对联邦系统用来代表 eileen 建立连接的远程用户 id 进行底层远程对象权限的检查。图 4 说明了不同之处。

图 4. 比较昵称权限与表权限

视图和包中的昵称权限

视图和包使您与内部细节分隔开，从而提供了一个附加的安全层。当您被授予使用一个视图或包的权限时，您被自动获得对视图或包中各个表的访问权限。但是，对于昵称，在数据源上还有另一个权限检查层：连接到远程数据源所需的远程认证。图 5 说明了两者行为上的不同之处。

图 5. 视图和包中的权限

函数

除了默认的数据类型映射，WebSphere Information Integrator 中的包装器库还包含一组默认的函数映射。这些函数映射指示查询编译器将一个内置的 DB2 函数（例如 SUM）映射为一个关系数据源对等物（可能的话）。如果您希望联邦服务器将函数的计算下推到一个关系数据源，那么必须使用那个数据源的一个函数映射。这样通常可以提高查询的性能。

如果存在特定于某个数据源的、在 WebSphere Information Integrator 上没有的特殊函数，则需要那个函数的函数模板定义。函数模板就像是用户定义函数的一个扩展。为了允许查询在联邦服务器上没有相应函数的数据源上引用那些函数，就需要函数模板。要了解函数模板的 CREATE FUNCTION 语句扩展，请参阅 DB2 UDB SQL Reference （见 参考资料）。

图 6 展示了在决定何时需要注册函数模板时所考虑的问题。

当一个查询引用一个函数模板时，查询优化器尝试生成一个灵活的计划，允许在远程数据源上计算这个函数引用。如果这样不可行，则会返回错误 SQL0142N，表明该 SQL 语句不受支持。

图 6.函数模板和映射

联邦系统编目视图

与本地表一样，上面描述的所有数据注册步骤都将信息存储在 DB2 联邦数据库系统编目中。您可以使用那些系统编目来检验关于联邦对象的信息。

表 4 列出了各个联邦对象以及可用于定位信息的 DB2 系统编目视图。要了解关于每个编目视图的定义的更多信息，请参阅 DB2 UDB SQL Reference（见 参考资料）。

表 4. 编目视图中的联邦对象信息

结束语

在 DB2 Universal Database for Linux、UNIX 和 Windows 的 version 7 中，IBM 引入了第一个能够集成关系和非关系数据的商业信息管理系统。联邦技术将您带到更高级别的信息集成，它允许 DB2 联邦系统充当一个虚拟的数据库，使得对远程对象的查询和对本地表的查询一样简单。您可以利用 DB2 和远程数据源的威力，从联邦系统所支持的透明性、异构性、高功能、自治性、可扩展性以及一些优化特性中受益。

WebSphere Information Integrator V8.2 进一步增强了联邦技术，使得构建一个企业联邦系统变得更加容易。一些重要的特性包括：

物化查询表，可以在引用关系和非关系昵称的查询上定义物化查询表，以便本地缓存查询结果。

Control Center 中的缓存表功能，它使您可以使用复制作为刷新机制来建立昵称的本地缓存。

昵称统计信息更新功能，它允许更新昵称统计信息。

联邦健康状况监视器，它监视联邦系统的健康状况。

将数据导入关系昵称和将数据从一个涉及昵称的查询中导出的能力。

增强的处理模型，在使用数据分区特性的联邦系统，更好地利用涉及昵称的查询的并行性（S. Harris 撰写的“Parallelism in WebSphere Information Integrator V8.2”对此进行了描述 —— 见 参考资料）。

更大范围的一组非关系包装器，包括 WebSphere Business Integration (WBI) 和 Web 服务包装器。

C++ 和 Java 语言的包装器开发工具箱，它使您可以编写自己的包装器，以便从联邦系统访问专有的数据源。

随着越来越多的客户采用数据联邦，对支持无缝联邦的挑战仍在增长。我们将继续致力于使联邦系统具有更好的性能，同时确保用户有更好的总体用户体验。请继续关注 IBM 接下来在 WebSphere Information Integrator 中提供的一组增强。