IBM DB2 Connect简介(1)

在本系列的 第 1 部分中，我们初步地谈到了 DB2 Connect 提供的不同编程接口以及实现这些接口的驱动程序。在最后的几节中，我们大致地描述了 DB2 Connect 提供的通信基础设施，并看到这个基础设施如何大大减少对大型主机资源的使用，如何允许分布式应用程序充分利用大型主机平台的优势（例如轻松地管理混合工作负载以及提供连续的应用程序可用性）。

您可能仍记得图 1，在这幅图中，DB2 Connect 由编程接口（被实现为 JDBC™、SQLJ、ODBC、DB2 CLI、OLE DB、.NET® 和 Embedded SQL 驱动程序）和一个通信基础设施组成。

我们将在本文中讨论上述通信基础设施的功能之一，即 DB2 Connect 如何提供对异构型分布数据的统一访问。

在讨论这种解决方案在统一访问、分布式和异构等方面的细节之前，我们需要先将目光转向通信基础设施本身。DB2 Connect 以通信服务器的形式提供这种通信基础设施，通信服务器可以部署在 Windows®、Linux （例如 Linux for zSeries）和 UNIX® 服务器上。这种通信服务器是使用在构建 DB2 UDB 数据库服务器时所用的相同代码基础构建的，因此，它继承了 DB2 UDB 服务器那种架构中具备的所有品质。

实际上，我们在本文中所描述的功能有一个要求，那就是在 DB2 Connect 服务器本身上创建一个数据库（在这里您不需要 DB2 Universal Database™ (UDB)）。乍一看来，这似乎与本系列第 1 部分中的说法相矛盾，在那里我们说 DB2 Connect 只是将应用程序连接到 DB2 for z/OS 和 DB2 for iSeries® 数据库，DB2 Connect 并不管理数据。然而需要澄清的是，我们要在 DB2 Connect 服务器上创建的这个数据库并不存放数据。它只是作为一个单一的连接点来使用，以便向应用程序提供统一的或单一的数据库镜像。于是，DB2 Connect 服务器只是将对数据的请求路由到真正管理数据的不同数据库服务器。

虽然在第 1 部分您了解到真正使 DB2 Connect 有别于其他竞争者的通信管道的一些特性，但您很可能已经知道，DB2 Connect 至少尽到了责任（将应用程序连接到大型主机）。现在您对 DB2 Connect 的底层架构有了更好的理解，接下来是该提供比本系列文章的第 1 部分（副标题 - 内有乾坤）更进一步内容的时候 —— 我们将从这里开始第 2 部分。

在第 2 部分中，我们将谈到作为数据访问平台的 DB2 Connect，在这里我们不仅仅是谈论大型主机上的 DB2。例如，您知道吗，DB2 Connect 工作站可以在同一个事务中执行一个 DB2 for z/OS 数据库和 Windows 数据库上的 Informix® IDS 之间的分布式连接（join），它还可以在同一个提交范围内使用内建的对两阶段提交（two-phase commit,2PC）的支持来更新这些数据源。我提到过您将发现一些巧妙的特性，这就是其中之一！如果说这听起来像是联邦，或者更像是 WebSphere® Information Integrator （前身为 DB2 Information Integrator），那就对了。实际上，所有 DB2 UDB 和 DB2 Connect 服务器都附带了 WebSphere Information Integrator 对整个 DB2 UDB 家族和内建在引擎中的 Informix IDS 的联邦支持。WebSphere Information Integrator 之类的产品扩展了联邦引擎的范围，使之包括其他关系数据源（Oracle、Microsoft® SQL Server）、非关系数据源（ADABAS、VSAM）、OLE DB、XML 和企业中任何其他数据源。

对异构型分布数据源的统一访问

您也许知道统一（unified）、分布（distributed）和异构（heterogeneous）的意思是什么，但可能并不清楚 DB2 Connect 是如何实现这些概念的。您也许熟悉 IBM WebSphere Information Integrator 产品，并且会想，这些词语很好地描述了这些产品。请继续阅读本文，如此一来这些产品之间的相互关系就会变得更加清晰。

统一访问是减少在异构环境中开放应用程序的复杂性的一种非常好的方法。虽然应用程序编程人员总能一一建立到各个数据源的连接，但更容易的方式还是在应用程序中只使用一个数据库连接。到不同数据源的不同连接需要多个驱动程序（例如，一个单独的 DB2 和 Informix JDBC 驱动程序）。如果在应用程序中使用多个不同的连接，那么在对待数据时，就不能把数据看作是由单个数据库管理的那样（例如，应用程序编程人员必须从多个数据源取数据，然后才可以执行连接操作）。而且，当使用多个不同连接时，代码在应用程序中的位置便会固定下来，这样数据架构师就不能自由地修改数据的位置，以适应不断变化的业务需求。

相反，统一数据访问机制则为应用程序编程人员提供了到企业所有数据资产的单点连接。它允许使用单个 API （驱动程序），允许使用一种风格的 SQL（您不必担心 SQL Server 使用货币数据类型而 DB2 UDB 不使用这种类型），它还对数据位置进行抽象，以便可以在不影响现有应用程序的情况下更改数据位置。最后，它允许编程人员一致地对待所有数据，就好像它们来自同一个关系数据库，并且那个数据库可以在保证事务完整性的情况下管理对数据的连接、排序和过滤 —— 并且，由于有了对 DB2 Connect 基本特性的扩展，后端数据源不必一定是关系数据源（例如，它可以是 VSAM 或 ADABAS 数据源）。

我希望您已经清楚，使用单个数据库比起协调对多个数据源的访问来要简单得多。但我们 IBM 信息管理解决方案的不同之处在于，我们并不期望您取消现有的应用，全部移植到 DB2 数据库，因为那样不现实。

DB2 Connect 通过以下三种不同机制之一实现简单直观的访问方法：

• 联邦数据库
• 存储过程
• SQL 函数

DB2 Connect 和联邦数据库

DB2 Connect 附带了一个内建的基础级联邦数据库功能。您可能对这个功能比较熟悉，因为之前 IBM DataJoiner 产品也提供了这个功能。从 Version 8 开始，联邦数据库支持已成为 DB2 Connect 和 DB2 UDB 服务器的一部分，任何人不需要购买额外的产品就可以使用该功能。换句话说，当您在 Linux、Windows 和 UNIX 服务器上部署了 DB2 Connect 服务器时，就可以创建一个联邦数据库，并且应用程序可以连接到这个联邦数据库。建立了与联邦数据库的连接后，请求被路由到真正的数据源 —— 但是函数补偿、数据类型转换、有效数据检索的优化等复杂性对用户来说是透明的。

DB2 Connect 的联邦组件包括对 DB2 UDB for Linux、DB2 UDB for UNIX 、DB2 UDB for Windows、DB2 UDB for VSE/VM、DB2 UDB for z/OS、DB2 UDB for iSeries 和 Informix IDS 数据库服务器的读/写支持。

您可以使用 DB2 Connect 中的联邦功能来执行跨这些服务器的分布式请求，如图 2 所示：

例如，以下语句：

SELECT * FROM T1, T2 where T1.C1=T2.C2

可用于返回来自不同服务器上不同数据库中各种表的结果。例如，表 T1 可能在一个 DB2 UDB for z/OS 数据库上，它可以与表 T2 相连接，后者在一个 Informix IDS for Windows 数据库上。

这个功能使应用程序开发人员可以在同一条 SQL SELECT 语句中引用由 DB2 UDB 家族中多个成员管理的对象 —— 完全不必知道查询是分布式的。使这种特性更强大的是，负责编写这类应用程序的开发人员可以把这些数据源看作本地 DB2 表（通过昵称），并使用相同的 SQL API 来访问每个数据源 —— 这些操作甚至可以在他们各自的集成开放环境（IDE）中进行！他们不需要理解后端数据存储之间有何不同，因为在集成开放环境中，或者对于 SQL API 来说，这些数据存储像是一个虚拟的数据库（关于这方面的更多内容请参阅本系列的另一个部分）。

DB2 Connect 与 WebSphere Information Integrator 相结合作为联邦服务器

在前一小节中，您看到 DB2 Connect 如何以 DB2 UDB 和基于 Informix IDS 的数据源建立联邦数据库。当与 WebSphere Information Integrator 相结合时，DB2 Connect 可以提供对其他数据源的透明访问，例如 Oracle、Microsoft SQL Server、Sybase、IMS、VSAM 和大批其他的数据源。当 DB2 Connect 与 WebSphere Information Integrator 相结合时，上面的图可以增强到如下面的图 3 所示：

实际上，在这个场景中，该功能的完整形象看上去应该是这样的：

DB2 Connect 在其联邦核心中内建了一个智能的优化器。这意味着当您从一个 Oracle 数据库选择很多数据时（如果您正在使用 WebSphere Information Integrator），优化器知道启发法、索引、基数和 Oracle 数据存储的总体分布情况，并能够重写查询，以获得更好的访问方式。

DB2 UDB 凭借其自治的、强大的优化技术而成名已久，这种技术能提供对数据的快速访问：这些优点并没有随联邦功能而消失。相反，它们被内建在 DB2 Connect 的联邦优化器中。因此，当 DB2 Connect 充当联邦层时，它可以执行谓词叠加（push-down）或消除分支树（branch-tree），从而加快数据访问。DB2 Connect 会判断是将谓词叠加到本地存储，还是带回完整的结果集并在本地应用结果集更有意义。取决于数据存储的并发特征或业务需求，DB2 Connect 甚至可以在这些外部数据源上创建一个温（warm）数据缓存，以便不需要牵涉到异构数据库。

深入分析联邦的能力超出了本文的范围，但要记住的最重要的一点是， 对于一名开发人员，在他自己的 IDE 中，只需一种 API，可以使用来自任何地方的各种数据 。在当今市场中，这些特征是无与伦比的，它们代表了一种伸手可及的专用 API 访问或“即购即换”方法学的解决方案，在今天这样注重成本的氛围下，这种方法学几乎被摒弃。最低限度是，DB2 Connect 是这些效率的一个起点，通过一个动态的选项，可以在需要的时候添加越来越多的数据源。

存储过程和统一数据访问

与其他作为竞争对手的数据库供应商提供的存储过程相比，DB2 服务器中的存储过程在功能上有其独特之处。DB2 存储过程中的代码可以重写，重写方式与应用程序其他部分几乎相同（例如，程序员或应用程序 DBA 可以使用自己喜欢的编程语言 —— Java、COBOL、.NET 或 C —— 并可以在数据库服务器平台上调用那种语言中可用的任何 API）。例如， 程序员可以（用 COBOL）编写一个调用 CICS 事务的存储过程，并将该存储过程部署到 DB2 for z/OS。因为调用存储过程的应用程序完全独立于存储过程实现的细节，因此调用者应用程序完全不知道它们在执行存储过程的时候，会引起对 CICS 资源的访问，也不知道这个存储过程是用 COBOL （这种语言对于程序员或 DBA 来说可能并不熟悉）编写的。

原文转自：http://www.ltesting.net