正在看的db2教程是:IBMDB2Connect简介(1)。
在本系列的第1部分中，我们初步地谈到了DB2Connect提供的不同编程接口以及实现这些接口的驱动程序。在最后的几节中，我们大致地描述了DB2Connect提供的通信基础设施，并看到这个基础设施如何大大减少对大型主机资源的使用，如何允许分布式应用程序充分利用大型主机平台的优势（例如轻松地管理混合工作负载以及提供连续的应用程序可用性）。
您可能仍记得图1，在这幅图中，DB2Connect由编程接口（被实现为JDBC™、SQLJ、ODBC、DB2CLI、OLEDB、.NET®和EmbeddedSQL驱动程序）和一个通信基础设施组成。
图1.DB2Connect由编程接口和一个通信基础设施组成，通信基础设施使客户机服务器应用程序和基于Web的应用程序能利用大型主机的优势
我们将在本文中讨论上述通信基础设施的功能之一，即DB2Connect如何提供对异构型分布数据的统一访问。
在讨论这种解决方案在统一访问、分布式和异构等方面的细节之前，我们需要先将目光转向通信基础设施本身。DB2Connect以通信服务器的形式提供这种通信基础设施，通信服务器可以部署在Windows®、Linux（例如LinuxforzSeries）和UNIX®服务器上。这种通信服务器是使用在构建DB2UDB数据库服务器时所用的相同代码基础构建的，因此，它继承了DB2UDB服务器那种架构中具备的所有品质。
实际上，我们在本文中所描述的功能有一个要求，那就是在DB2Connect服务器本身上创建一个数据库（在这里您不需要DB2UniversalDatabase™(UDB)）。乍一看来，这似乎与本系列第1部分中的说法相矛盾，在那里我们说DB2Connect只是将应用程序连接到DB2forz/OS和DB2foriSeries®数据库，DB2Connect并不管理数据。然而需要澄清的是，我们要在DB2Connect服务器上创建的这个数据库并不存放数据。它只是作为一个单一的连接点来使用，以便向应用程序提供统一的或单一的数据库镜像。于是，DB2Connect服务器只是将对数据的请求路由到真正管理数据的不同数据库服务器。
虽然在第1部分您了解到真正使DB2Connect有别于其他竞争者的通信管道的一些特性，但您很可能已经知道，DB2Connect至少尽到了责任（将应用程序连接到大型主机）。现在您对DB2Connect的底层架构有了更好的理解，接下来是该提供比本系列文章的第1部分（副标题-内有乾坤）更进一步内容的时候——我们将从这里开始第2部分。
在第2部分中，我们将谈到作为数据访问平台的DB2Connect，在这里我们不仅仅是谈论大型主机上的DB2。例如，您知道吗，DB2Connect工作站可以在同一个事务中执行一个DB2forz/OS数据库和Windows数据库上的Informix®IDS之间的分布式连接（join），它还可以在同一个提交范围内使用内建的对两阶段提交（two-phasecommit,2PC）的支持来更新这些数据源。我提到过您将发现一些巧妙的特性，这就是其中之一！如果说这听起来像是联邦，或者更像是WebSphere®InformationIntegrator（前身为DB2InformationIntegrator），那就对了。实际上，所有DB2UDB和DB2Connect服务器都附带了WebSphereInformationIntegrator对整个DB2UDB家族和内建在引擎中的InformixIDS的联邦支持。WebSphereInformationIntegrator之类的产品扩展了联邦引擎的范围，使之包括其他关系数据源（Oracle、Microsoft®SQLServer）、非关系数据源（ADABAS、VSAM）、OLEDB、XML和企业中任何其他数据源。
对异构型分布数据源的统一访问
您也许知道统一（unified）、分布（distributed）和异构（heterogeneous）的意思是什么，但可能并不清楚DB2Connect是如何实现这些概念的。您也许熟悉IBMWebSphereInformationIntegrator产品，并且会想，这些词语很好地描述了这些产品。请继续阅读本文，如此一来这些产品之间的相互关系就会变得更加清晰。
统一访问是减少在异构环境中开放应用程序的复杂性的一种非常好的方法。虽然应用程序编程人员总能一一建立到各个数据源的连接，但更容易的方式还是在应用程序中只使用一个数据库连接。到不同数据源的不同连接需要多个驱动程序（例如，一个单独的DB2和InformixJDBC驱动程序）。如果在应用程序中使用多个不同的连接，那么在对待数据时，就不能把数据看作是由单个数据库管理的那样（例如，应用程序编程人员必须从多个数据源取数据，然后才可以执行连接操作）。而且，当使用多个不同连接时，代码在应用程序中的位置便会固定下来，这样数据架构师就不能自由地修改数据的位置，以适应不断变化的业务需求。
相反，统一数据访问机制则为应用程序编程人员提供了到企业所有数据资产的单点连接。它允许使用单个API（驱动程序），允许使用一种风格的SQL（您不必担心SQLServer使用货币数据类型而DB2UDB不使用这种类型），它还对数据位置进行抽象，以便可以在不影响现有应用程序的情况下更改数据位置。最后，它允许编程人员一致地对待所有数据，就好像它们来自同一个关系数据库，并且那个数据库可以在保证事务完整性的情况下管理对数据的连接、排序和过滤——并且，由于有了对DB2Connect基本特性的扩展，后端数据源不必一定是关系数据源（例如，它可以是VSAM或ADABAS数据源）。
我希望您已经清楚，使用单个数据库比起协调对多个数据源的访问来要简单得多。但我们IBM信息管理解决方案的不同之处在于，我们并不期望您取消现有的应用，全部移植到DB2数据库，因为那样不现实。
DB2Connect通过以下三种不同机制之一实现简单直观的访问方法：
联邦数据库
存储过程
SQL函数
DB2Connect和联邦数据库
DB2Connect附带了一个内建的基础级联邦数据库功能。您可能对这个功能比较熟悉，因为之前IBMDataJoiner产品也提供了这个功能。从Version8开始，联邦数据库支持已成为DB2Connect和DB2UDB服务器的一部分，任何人不需要购买额外的产品就可以使用该功能。换句话说，当您在Linux、Windows和UNIX服务器上部署了DB2Connect服务器时，就可以创建一个联邦数据库，并且应用程序可以连接到这个联邦数据库。建立了与联邦数据库的连接后，请求被路由到真正的数据源——但是函数补偿、数据类型转换、有效数据检索的优化等复杂性对用户来说是透明的。
DB2Connect的联邦组件包括对DB2UDBforLinux、DB2UDBforUNIX、DB2UDBforWindows、DB2UDBforVSE/VM、DB2UDBforz/OS、DB2UDBforiSeries和InformixIDS数据库服务器的读/写支持。
您可以使用DB2Connect中的联邦功能来执行跨这些服务器的分布式请求，如图2所示：
图2.DB2Connect的联邦数据库功能
例如，以下语句：
SELECT*FROMT1,T2whereT1.C1
在本系列的第1部分中，我们初步地谈到了DB2Connect提供的不同编程接口以及实现这些接口的驱动程序。在最后的几节中，我们大致地描述了DB2Connect提供的通信基础设施，并看到这个基础设施如何大大减少对大型主机资源的使用，如何允许分布式应用程序充分利用大型主机平台的优势（例如轻松地管理混合工作负载以及提供连续的应用程序可用性）。
您可能仍记得图1，在这幅图中，DB2Connect由编程接口（被实现为JDBC™、SQLJ、ODBC、DB2CLI、OLEDB、.NET®和EmbeddedSQL驱动程序）和一个通信基础设施组成。
图1.DB2Connect由编程接口和一个通信基础设施组成，通信基础设施使客户机服务器应用程序和基于Web的应用程序能利用大型主机的优势
我们将在本文中讨论上述通信基础设施的功能之一，即DB2Connect如何提供对异构型分布数据的统一访问。
在讨论这种解决方案在统一访问、分布式和异构等方面的细节之前，我们需要先将目光转向通信基础设施本身。DB2Connect以通信服务器的形式提供这种通信基础设施，通信服务器可以部署在Windows®、Linux（例如LinuxforzSeries）和UNIX®服务器上。这种通信服务器是使用在构建DB2UDB数据库服务器时所用的相同代码基础构建的，因此，它继承了DB2UDB服务器那种架构中具备的所有品质。
实际上，我们在本文中所描述的功能有一个要求，那就是在DB2Connect服务器本身上创建一个数据库（在这里您不需要DB2UniversalDatabase™(UDB)）。乍一看来，这似乎与本系列第1部分中的说法相矛盾，在那里我们说DB2Connect只是将应用程序连接到DB2forz/OS和DB2foriSeries®数据库，DB2Connect并不管理数据。然而需要澄清的是，我们要在DB2Connect服务器上创建的这个数据库并不存放数据。它只是作为一个单一的连接点来使用，以便向应用程序提供统一的或单一的数据库镜像。于是，DB2Connect服务器只是将对数据的请求路由到真正管理数据的不同数据库服务器。
虽然在第1部分您了解到真正使DB2Connect有别于其他竞争者的通信管道的一些特性，但您很可能已经知道，DB2Connect至少尽到了责任（将应用程序连接到大型主机）。现在您对DB2Connect的底层架构有了更好的理解，接下来是该提供比本系列文章的第1部分（副标题-内有乾坤）更进一步内容的时候——我们将从这里开始第2部分。
在第2部分中，我们将谈到作为数据访问平台的DB2Connect，在这里我们不仅仅是谈论大型主机上的DB2。例如，您知道吗，DB2Connect工作站可以在同一个事务中执行一个DB2forz/OS数据库和Windows数据库上的Informix®IDS之间的分布式连接（join），它还可以在同一个提交范围内使用内建的对两阶段提交（two-phasecommit,2PC）的支持来更新这些数据源。我提到过您将发现一些巧妙的特性，这就是其中之一！如果说这听起来像是联邦，或者更像是WebSphere®InformationIntegrator（前身为DB2InformationIntegrator），那就对了。实际上，所有DB2UDB和DB2Connect服务器都附带了WebSphereInformationIntegrator对整个DB2UDB家族和内建在引擎中的InformixIDS的联邦支持。WebSphereInformationIntegrator之类的产品扩展了联邦引擎的范围，使之包括其他关系数据源（Oracle、Microsoft®SQLServer）、非关系数据源（ADABAS、VSAM）、OLEDB、XML和企业中任何其他数据源。
对异构型分布数据源的统一访问
您也许知道统一（unified）、分布（distributed）和异构（heterogeneous）的意思是什么，但可能并不清楚DB2Connect是如何实现这些概念的。您也许熟悉IBMWebSphereInformationIntegrator产品，并且会想，这些词语很好地描述了这些产品。请继续阅读本文，如此一来这些产品之间的相互关系就会变得更加清晰。
统一访问是减少在异构环境中开放应用程序的复杂性的一种非常好的方法。虽然应用程序编程人员总能一一建立到各个数据源的连接，但更容易的方式还是在应用程序中只使用一个数据库连接。到不同数据源的不同连接需要多个驱动程序（例如，一个单独的DB2和InformixJDBC驱动程序）。如果在应用程序中使用多个不同的连接，那么在对待数据时，就不能把数据看作是由单个数据库管理的那样（例如，应用程序编程人员必须从多个数据源取数据，然后才可以执行连接操作）。而且，当使用多个不同连接时，代码在应用程序中的位置便会固定下来，这样数据架构师就不能自由地修改数据的位置，以适应不断变化的业务需求。
相反，统一数据访问机制则为应用程序编程人员提供了到企业所有数据资产的单点连接。它允许使用单个API（驱动程序），允许使用一种风格的SQL（您不必担心SQLServer使用货币数据类型而DB2UDB不使用这种类型），它还对数据位置进行抽象，以便可以在不影响现有应用程序的情况下更改数据位置。最后，它允许编程人员一致地对待所有数据，就好像它们来自同一个关系数据库，并且那个数据库可以在保证事务完整性的情况下管理对数据的连接、排序和过滤——并且，由于有了对DB2Connect基本特性的扩展，后端数据源不必一定是关系数据源（例如，它可以是VSAM或ADABAS数据源）。
我希望您已经清楚，使用单个数据库比起协调对多个数据源的访问来要简单得多。但我们IBM信息管理解决方案的不同之处在于，我们并不期望您取消现有的应用，全部移植到DB2数据库，因为那样不现实。
DB2Connect通过以下三种不同机制之一实现简单直观的访问方法：
联邦数据库
存储过程
SQL函数
DB2Connect和联邦数据库
DB2Connect附带了一个内建的基础级联邦数据库功能。您可能对这个功能比较熟悉，因为之前IBMDataJoiner产品也提供了这个功能。从Version8开始，联邦数据库支持已成为DB2Connect和DB2UDB服务器的一部分，任何人不需要购买额外的产品就可以使用该功能。换句话说，当您在Linux、Windows和UNIX服务器上部署了DB2Connect服务器时，就可以创建一个联邦数据库，并且应用程序可以连接到这个联邦数据库。建立了与联邦数据库的连接后，请求被路由到真正的数据源——但是函数补偿、数据类型转换、有效数据检索的优化等复杂性对用户来说是透明的。
DB2Connect的联邦组件包括对DB2UDBforLinux、DB2UDBforUNIX、DB2UDBforWindows、DB2UDBforVSE/VM、DB2UDBforz/OS、DB2UDBforiSeries和InformixIDS数据库服务器的读/写支持。
您可以使用DB2Connect中的联邦功能来执行跨这些服务器的分布式请求，如图2所示：
图2.DB2Connect的联邦数据库功能
例如，以下语句：
SELECT*FROMT1,T2whereT1.C1
发表评论 取消回复