用于将主机环境迁移至新系统平台的技术

摘要

描述了一种用于配置基于交易的主机环境(12)、以便从先前系统平台迁移至新系统平台的方法。所述方法包括以下步骤：在先前系统平台上提供至少一个第一类型的数据库和至少一个第二类型的数据库，所述第一类型的数据库和所述第二类型的数据库具有不同的迁移行为。另外提供了第一类型的交易，用于访问先前系统平台上的第一类型的数据库和第二类型的数据库。为了准备迁移，将主机环境中的第一类型的交易替换为第二类型的交易和第三类型的交易，第二类型的交易仅访问第一类型的数据库，第三类型的交易仅访问第二类型的数据库。所述方法还包括来自分散环境的针对第一类型的交易的请求启动第二和第三类型的交易。

说明书

技术领域

本发明涉及系统迁移领域。更具体地，本发明涉及用于迁移至新系统平台的基于交易的主机环境的配置。

背景技术

大公司中的现代计算机系统频繁地配置为OLTP系统。OLTP(在线交易处理)指定一种基于交易的数据处理方式。

在该上下文中，将交易理解为组合为不可分割的单元的一系列逻辑相干(频繁数据库相关)的各个动作。交易的特性在于，完全执行或根本不执行组合于其中的各个动作。此外，可以并行执行多个交易而不引起这些交易之间的交互。因此，每个单独的交易与其它交易相“独立”地运行。

构建于交易范例(paradigm)之上，将OLTP系统的共有特性合并。这些共有特性之一在于OLTP系统是可共享的这一事实。在可共享操作的范围内，可以由不同的用户产生多个并行交易。配置OLTP系统，使得能够实时运行这些交易(至少在用户的感知方面)。此外，通常交易具有典型特征，即每个OLTP系统通常为不同的用户提供了一系列预先定义类型的交易(并在不同的数据库层级具有不同的影响)。

传统的OLTP系统通常是分布式系统，其中多个客户端组件(或者简称“客户端”)与至少一个主机组件(或者简称“主机”)进行通信。在这里，术语“组件”指硬件实施和软件实现或硬件和软件的组合。

主机和客户端之间的通信通常经由诸如因特网或内联网之类的网络而发生。客户端经由网络请求来自主机的特定服务，并等待响应。主机接受请求，对请求进行处理并将适合的响应发送回客户端。可以在主机和客户端之间设置其它组件，以将请求格式化、对客户端进行认证等。

主机通常包括多个单独的子组件(如特定交易应用程序、一个或多个数据库和相应接口)，这些子组件在公共系统平台上运行。将系统平台理解为特定类型的计算机和关联操作系统的组合。主机子组件与系统平台一起形成了主机环境。在许多情况下，存在从分散环境至主机环境的访问。例如，由在网络上分布的客户端以各种形式形成这种类型的分散环境。在大型银行的情况下，各个客户端形式包括客户终端、自动提款机、客户关怀终端(customer care terminal)、电子银行解决方案等。

由于信息技术领域的快速发展以及许多现有的OLTP系统已经工作了很长时间的事实，从现今的观点看来，许多主机环境基于陈旧的系统平台。因此，现在的想法给出了可以将主机系统(经过若干年将称为极其复杂的系统)可靠地迁移至新的并且技术上得以更新的系统平台的方式。

所有类型的问题都随着这种迁移而出现。具体地，经常不是所有的主机子组件可以或应当被未改变地迁移至新系统平台。在数据库的情况下，通常该迁移也伴随着内容上的改变，因而信息需要改变并通常增加。也期望能够逐步执行迁移，从而主机环境在出现不期望的问题时至少保持部分可操作。此外，经常需要的是，不允许分散环境注意到任何主机环境的迁移。

本发明基于提供将主机环境迁移到新系统平台的有效方式的目的。

发明内容

根据本发明的第一方面，该目的通过以下实现：一种用于配置从分散环境访问的、基于交易的主机环境的方法，以便从先前的系统平台迁移至新系统平台，该新系统平台例如在所使用的操作系统和/或所使用的计算机类型方面不同于先前的系统平台。所述方法包括以下步骤：在先前的系统平台上提供至少一个第一类型的数据库，其中将所述第一类型的数据库以内容未改变、和/或逻辑数据模型或其它未改变的方式迁移至新系统平台；在先前的系统平台上提供至少一个第二类型的数据库，其中在迁移至新系统平台的过程中，将所述第二类型的数据库以内容改变、和/或逻辑数据模型改变的方式转换为第三类型的数据库；在主机环境中将在先前的系统平台上访问了第一类型的数据库和第二类型的数据库的第一类型的交易替换为第二类型的交易和第三类型的交易，其中第二类型的交易访问第一而非第二类型的数据库，以及第三类型的交易访问第二而非第一类型的数据库；以及当在分散环境中请求第一类型的交易时启动第二和第三类型的交易。

可以将根据本方法配置的主机环境逐步迁移至新系统平台，而不对分散环境尤其是从分散环境访问主机环境的客户端产生重大影响。根据本发明的方法还允许根据不同迁移行文和关联应用程序的主机环境的有效迁移。这里，将应用程序理解为提供了特定交易所基于的处理功能(例如针对银行业)的应用程序(通常利用数据库访问)。

通过根据本发明的方法，可以配置主机环境，从而在迁移阶段之初，在交易范围内不再有使用不同的迁移行为访问数据库的任何类型的交易。这种方法允许单独地、并在必要时彼此独立地迁移这种类型的数据库。这主要通过将主机环境中的第一类型的交易替换为第二和第三类型的交易来实现。如果随后在分散环境中请求第一类型的交易，则自动启动第二和第三类型的交易(例如，通过互操作的交易控制组件)，这对于先前系统平台上的主机环境具有相同的影响，并传递与已经进行了所请求的第一类型的交易相同的结果。

已经证实，在所请求的第一类型的交易与每种情况下因而所发起的第二和第三(和/或第四)类型的交易之一之间产生分配是有利的。可以以表格形式进行这种分配，在进行交易(例如，主机环境中的第二和第三类型的交易)之后允许确定启动这些交易的第一类型的交易。如果将分配给彼此(以及分配给第一类型的交易)的第二和第三(和/或第四)类型的交易的结果从主机环境传递至分散环境，则这种确定是有利的。在该传递的范围内，然后可以将这些结果转换为预先定义结果的格式，可能是所请求的第一类型的交易，并在分散环境中(例如通过客户端)以这种格式进行处理。

例如，如果分散环境中的客户端请求了第一类型的交易，则可以将转换后的结果传递至请求客户端。因此，客户端具有在主机环境中以传统方式发生了第一类型的交易的印象。客户端不需要知道主机环境中的任何实际处理，具体是所进行的第二和第三或第四类型的交易。换言之，客户端“看”不到主机环境为迁移所做的准备、或者主机环境当前迁移状态的准备中的任一准备。此外，分散环境的单独组件可以在整个迁移阶段期间保持它们的定制消息和通信格式。

可以在分散环境中进行上述步骤(生成分配、接收结果和转换结果)中的至少一个。然而，这些步骤中的一个或多个也可以在主机环境中运行。

有利地，提供在各个客户端与一个或多个主机之间功能性设置的中心交易控制组件。交易控制组件可以具有除了已经解释过的能力(如认证或检查客户端的授权、或者将根据请求提交的客户端数据或返回请求客户端的数据格式化)之外的功能。交易控制组件可以位于分散环境或主机环境中。还可以预想将交易控制组件构造为分布组件，该分布组件部分位于分散环境以及部分位于主机环境中。可以通过与主机网络和/或分散网络的关联来确定交易控制组件与分散和/或主机环境的关联。

根据上述解释的方法的另一变体，在新系统平台上提供了使从第二类型的数据库中出现的第三类型的数据库的至少一个数据库进行操作的步骤。第三类型的数据库中的数据库可能在内容方面具有与旧系统平台上第二类型数据库的数据库的特定公共特征，但是与第二类型的数据库中的这些数据库相比，在内容方面或在逻辑数据模型方面进行了修改(换言之，具有例如不同的逻辑数据结构、附加数据字段等)。

在第三类型的数据库已经在新系统平台上进行操作之后，所请求的第一类型的交易可以向两个平台扩散。例如，可以按照将所请求的第一类型的交易分为先前系统平台上分配的第二类型的交易、并分为新系统平台上分配的访问了第三类型数据库的第四类型的交易的方式进行该扩散。该扩散包括将单独的或者所有第三类型的交易(不考虑是已经从分散系统中请求、还是已经仅通过从分散环境中请求的第一类型交易的转换而获得)替换为第四类型的交易。

可以已经在分散环境或者最初在主机环境中发生了所请求的第一类型交易的扩散。上述解释的生成分配、接收结果和转换结果的步骤还可以包括第四类型的交易。

甚至在已经将第三类型数据库中的数据库在新系统平台上操作了之后，仍可以使用第三类型的交易在上下文中访问第二类型数据库中的相应数据库。因此，可以在转变阶段内(例如在以下所描述的逐个实体的迁移期间)进行第三类型的交易和第四类型的“同型交易(sister transaction)”。为了保持数据的一致性，可以考虑在主机环境中的每种情况下，针对从分散环境中请求的特定的第一(或第三)类型的交易，仅进行所分配的第三类型的交易或者所分配的第四类型的交易。可以基于实体而做出对于应当在主机环境中针对从分散环境中请求的第一(或第三)类型的交易进行所分配的第三类型的交易还是第四类型的交易的判断。

根据本发明的变体(至少在测试环境中)，可以在旧系统平台上管理一个或多个第二类型的数据库，以及通过并行的第三和第四类型的交易在新系统平台上管理一个或多个第三类型的数据库。根据该场景，在交易操作期间，针对每个第三类型的交易存在并行的第四类型的交易。通过比较并行管理的第二和第三类型的数据库中的相应数据库内容，可以检查新系统平台(以及在其上运行的应用程序和数据库)的功能模式。切断旧系统平台上的诸如应用程序和数据库之类的组件并使组件在新系统平台上操作可以依据该比较结果而发生。如果在相当长的时间内或者超过相当长的时间没有观察到并行管理的第二和第三类型的数据库的内容之间的不一致，则可以假设第三类型数据库(以及访问其的应用程序)成功迁移。

在新系统平台上成功进行了第三类型数据库的操作之后，可以在新系统平台上继续从第一类型的数据库中出现的第四类型的数据库中的至少一个数据库的操作(例如，通过至少大部分的自动转换)。实际上，也可以在第三类型数据库之前或与第三类型数据库同时，在新系统平台上操作第四类型的数据库。

在使第四类型的数据库中的一个或多个数据库进行操作的范围内，可以另外在新系统平台上使访问了第四类型数据库的一个或多个应用程序进行操作。如果第四类型的数据库中的数据库已经从第一类型的数据库中出现而实质没有改变，则可以通过运行在旧系统平台上并在那里访问了第一类型数据库的先前应用程序的代码转换来产生用于新系统平台的应用程序。换言之，不必必须为新系统平台重写这些应用程序(一个原因在于，由于第一和第四类型数据库的结构共有特征，通常可以保持数据库访问机制)。

根据本发明的另一方面，在先前系统平台上对具有类似交易功能的多个并行主机进行操作。可以选择这种类型的过程来改进主机系统的可扩缩性。可以在主机中的每个单独的主机上允许相同的数据库和相同的应用程序。如果提供了多个并行主机，则通常会出现将各个交易分配给各个主机的控制组件。例如，可以动态运行这种类型的分配，以便均匀地利用各个主机(负载平衡)。然而，也可以进行静态分配。例如，静态分配可以基于将包括预定实体集合的子集分配给每个主机的事实。这里，实体指数据集合的分配标准。交易可以具有实体关系，因而与分配给各个实体的数据集合相关。

优选地，通过单个逻辑主机，在新系统平台上管理先前系统平台上多个并行主机的基于交易的功能。然而，也可以类似地预期在新系统平台上提供多个并行主机。

尽管可以特别地进行迁移，但是优选逐步的迁移。这表示在多个并行主机的情况下可以逐主机地进行迁移。也可以逐部分地(例如换言之，逐实体地)进行迁移。在逐实体迁移的情况下，有利地，确定各个实体的迁移状态，从而使交易可以运行在正确的系统平台上。

逐实体迁移的优选方法包括以下步骤：确定分配给所请求的第一(或第三)类型的交易的实体，确定所分配实体的迁移状态，并根据所分配实体的迁移状态，在先前系统平台上进行第三类型的交易或者在新系统平台上进行第四类型的交易。可以以例如表格形式来登记各个实体的迁移状态。有利地，在分散环境中进行确定分配给交易的实体以及该实体的迁移状态的步骤。

根据本发明的另一方面，提供了具有程序代码部分的计算机程序产品，用于在一个或多个计算机上运行计算机程序产品时执行根据本发明的步骤。可以将计算机程序产品存储在计算机可读数据载体上。

附图说明

本发明的其它优点和变体将从以下对优选实施例的描述以及附图中变得清楚，其中：

图1示出了在迁移至新系统平台的配置之前根据本发明的第一OLTP系统的示意图；

图2示出了在OLTP系统的主机和控制组件之间进行交换的交易消息的示意图；

图3示出了用于准备向新系统平台的迁移的根据本发明的配置方法实施例的流程图；

图4示出了在迁移阶段开始之前根据本发明进行配置的OLTP系统的示意图；

图5示出了OLTP系统的交易控制组件的分配表；

图6示出了在迁移阶段根据本发明的OLTP系统的示意图，同时在新的和先前的系统平台上保持数据；

图7示出了在迁移阶段根据本发明的OLTP系统的示意图，执行了至新系统平台的部分迁移；

图8示出了在完成迁移阶段之后根据本发明的OLTP系统的示意图；以及

图9示出了在迁移阶段根据本发明进行配置的另一OLTP系统的示意图。

具体实施方式

图1示出了配置用于迁移至新系统平台的OLTP系统10。OLTP系统10包括主机环境12和分散环境14。主机环境12和分散环境14通过网络(未示出)进行耦合(连接)。

在主机环境12中，示出了在预先定义的系统平台(例如，在未示出的Unisys平台，未示出)上运行的主机16。主机16包括诸如数据库和具有数据库访问功能的应用程序之类的多个单独的子组件。更精确地，主机16包括在内容上和在逻辑数据模型方面不发生改变(或者在可选实施例中根本不改变)地迁移至新系统平台的类型的第一数据库20、以及在至新系统平台的迁移过程中在内容上和在逻辑数据模型方面进行了修改的类型的第二数据库22。

此外，主机16包括三种独立类型的应用程序26、28、30，它们主要在数据库访问机制方面不同。每种类型的应用程序26、28、30可以包括多个不同的单独应用程序。第一类型的应用程序26访问第一数据库20和第二数据库22.第二类型的应用程序28仅对第一数据库20进行访问，第三类型的应用程序30仅访问第二数据库22。

将不同类型的交易32、34、36与三种类型的应用程序26、28、30相链接。第一类型的应用程序26属于要被替换的第一类型的交易32(由实线箭头指示)，该第一类型的交易32用于从第一数据库20和第二数据库22中读出和/或修改内容。要被替换的第一类型的交易32的特征在于具有与两个数据库20、22有关的不同的访问行为。因而第一类型的交易32可以包含与第一数据库20有关的一个或多个只读访问、以及与第二数据库22有关的一个或多个只写访问(反之亦然)。这种交易类型32特别容易被替换，并且在实际转换的预备阶段保证了高度数据一致性。在可选实施例中，第一类型的交易32包括与两个数据库20、22中的每个有关的组合读/写访问。

n阶提交(commit)的使用可以将第一类型的交易替换为第二和第三类型的交易。当将所给的第一类型的交易A分为第二类型的交易B和第三类型的另一交易C时，通过交易B和C来保证交易安全性。这表示在交易B和C中的处理步骤的顺序保持不变，并且在两个交易之一中的动作失败的情况下，可以安全地不做出相同交易的所有工作和在每种情况下已经执行的其他交易。现代数据库能够“基于试验”来执行交易，但是能够另外与外部事件相关地进入操作过程。这样可以使交易B的有效性取决于交易C的可行性。

例如，交易A可以是安全纸张数量登记和标题登记；交易B可以是数量登记、以及交易C是标题登记。如果数量登记失败，则也不能执行标题登记，反之亦然。以这种方式，客户接收到完整的安全纸张登记或什么也接收不到。可以沿多个方向同时执行这种链接，从而一起(以正确的顺序)执行交易B和C或不执行交易B和C。以同样的方式，交易的级联也是可以的。这种访问的程序实现是专业人员所公知的；在各种情况下，计算机支持优化可以使整个系统的性能提高。

还可以自动将交易A转换为子交易，它们通过交易A的交易链组而对外呈现出类似于单个交易。在第二步骤中，将子交易B和C分配给高层交易A的交易链组中的各个数据库，从而所产生的交易B和C(顺序或级联，可以包含其它交易)联合地与原始交易A相对应。

第二类型的应用程序28属于第二类型的交易34(通过虚线箭头表示)，用于仅读出和/或修改第一数据库20的内容。最后，第三类型的应用程序30是第三类型交易36(由点线箭头表示)的一部分，用于仅读出和/或修改第二数据库22的内容。

例如，图1所示的分散环境14基于UNIX平台。分散环境14包括中心控制组件40(终端控制器形式)和多个极端变化的终端或客户端42，它们经由控制组件40与主机环境12进行通信。例如，客户端42是PC、用户终端、提款机、具有适合功能的移动电话和类似终端。尽管未示出，但是类似地通过控制组件40的切换而与主机环境12通信的分散应用程序可以附加地位于分散环境14中。这种分散应用程序经由控制组件40对数据库20、22进行实时访问。

控制组件40对于三种类型的交易32、34、36中的每个来说都具有分配后的交易控制机制32A、34A、36A，如图1中在每种情况下用圆圈所示。交易控制机制32A、34A、36A实质上用作交换中心，用于依据对相应类型的应用程序(以及对特别负责处理该交易的应用程序)的交易类型来进行客户端42所请求的交易。交易控制机制32A、34A、36A另外可以承担其它任务，如格式化任务(例如换言之，将客户端请求转换为主机特定格式或将主机响应转换为客户端特定格式)。这种格式化步骤首先在具有不同类型客户端的不同类分散环境14中是有利的。

如图2所示，通过交易消息200来进行控制组件40和主机1 6之间的通信。每个交易消息200包括交易头202和交易内容204。头202包含唯一交易号码(例如，1001)。每个交易消息200的交易内容204包含在交易中所关心的数据库对象的指示。在示例情况下，数据库对象的这种指示具有以下格式：xxx-yyyyy.zz，其中xxx(例如032)指示实体组，yyyyy(例如12345)代表实体组中的单独实体，zz(例如01)标志该实体的特定对象。实体组可以是公司的分公司，实体可以是分公司的客户，对象可以是为该客户创建的数据集合。

针对来自客户端的请求，控制组件40首先将客户端请求转换为交易消息200的格式，然后将格式化后的请求转发至主机16(更精确地是转发至负责的应用程序)。然后，主机16将交易消息200形式的响应发送回控制组件40，控制组件40将响应转换回客户端格式并将其转发至请求客户端。

图3示出了用于配置图1所示的基于交易的主机环境12(或者以某种其他方式配置的主机环境)以迁移至新系统平台的方法实施例的流程图300。

该方法开始与步骤302，在第一系统平台上向两种类型的数据库20、22提供了不同的迁移行为。例如，两种类型的数据库20、22的不同迁移行为产生于以下事实：可以完全或大部分自动地迁移第一类型的数据库(可能通过机器转译、保持内容和/或逻辑数据模型)，同时不能大部分自动转换第二类型的数据库22(这是因为可能会需要内容上的改变或逻辑数据模型中的改变)。

在步骤304，在第一系统平台上提供利用了两种类型数据库20、22的第一类型的交易32。步骤302和304实质上指示主机环境12的特定状态，并因而可以按照任何顺序或同时执行步骤302和304。

在其它步骤306中，将第一类型的交易32替换为两个不同类型的交易34、36，在每种情况下，访问仅两种类型数据库20、22中的一个。在根据图1的示例中，第二类型的交易34仅利用了第一数据库20，第三类型的数据库36仅访问了第二数据库22。

在结束步骤308中，针对第一类型交易32的请求，在一个或多个客户端42的一部分上启动第二和第三类型的交易34、36，第二和第三类型的交易34、36在主机环境中替换或“模仿”所请求的第一类型的交易32。

例如，可以通过控制组件40来启动第二和第三类型的交易34、36。这种情况在图4中示出，图4示出了处于迁移就绪状态下的根据图1的OLTP系统。

如从图4中所见，在主机环境12中由第二类型的交易34和第三类型的交易36来替换第一类型的交易32。换言之，在主机环境12中通过第二和第三类型的交易34、36来模拟第一类型的交易32。随着主机环境中的第一类型的交易32的省略，也不需要第一类型的应用程序26(图1)。通过第二和第三类型的应用程序28、30中的每一个(重写的)应用程序来替换每个第一类型的应用程序26，因而通过第二和第三类型的交易34、36来对第二和第三类型的应用程序28、30进行寻址。

由于分散环境14中的客户端42不应受到主机环境12准备迁移至新系统平台(因而将继续请求第一类型的交易32)的影响，所以通过附加层来补充控制组件40。在较低控制层40′上保持已经参照图1进行解释的交易控制组件32A、34A、36A。然而，现在另外引入较高控制层40″，用于针对第一类型交易32的请求来启动所分配的第二和第三类型的交易34、36。为此，在控制层40″中提供与控制机制32A进行通信的两个交易控制机制32B、32B′。

控制机制32B、32B′针对第一类型交易32的请求来自动启动由客户端42之一所分配的第二和第三类型的交易34、36。最新启动的第二和第三类型的交易34、36总体上在主机环境12中具有与所请求的第一类型的交易32相同的作用。

如从图4中所见，控制机制32B与一个或多个第二类型的应用程序28进行通信，控制机制32B′与一个或多个第三类型的应用程序30进行通信。如已经提及的，这些应用程序通常必须在退出第一类型的应用程序26之后被重写入主机环境12中。在任何情况下，这应用于在主机环境12中模拟第一类型交易32的第三类型“新”交易36所利用的那些第三类型的应用程序30。

在较高控制层40″，除了用于启动第二类型和第三类型交易34、36的控制机制32B、32B′之外，也实现了其它控制机制34B、36B。然而，在本实施例中，这些控制机制34B、36B不具有特定功能。而是将从设置在控制机制34B、36B之下的控制机制34A、36A接收到的交易消息无附加编辑步骤地转发至相关联的第二和第三类型的应用程序28、30。

将第一类型的交易32替换为第二和第三类型的交易34、36需要构造在由客户端42所请求的第一类型的交易与在因而启动了的第二和第三类型的交易34、36之间的分配。因此具体地，控制组件40必须“记忆”该效果，从而可以将与第二和第三类型的交易34、36相结合的、由主机16接收到的交易消息的内容分配给所请求的第一类型的交易32并以适合的格式传递给请求客户端42。

为此，控制组件40具有以下功能：接收分配给彼此的第二和第三类型的交易34、36的结果，并将所接收到的结果转换为请求客户端易于理解的预先定义结果的格式。该功能基于在所请求的第一类型的交易与在因而启动了的第二和第三类型的交易34、36之间的分配。该分配可以以表格形式进行，如图5所示。每个交易具有唯一标记号码，所以在每种情况下，可以将分配给彼此的交易的交易号码彼此相关地放置在表格500的一行中。

例如，表格500的第一行表示已经从分散环境14中请求了具有交易号码1001的第一类型的交易32。因此，控制机制32B启动了具有交易号码2001的单个第二类型的交易34，以及控制机制32B′启动了具有交易号码3001和3002的两个第三类型的交易36。因而在主机环境12中，总计通过三个交易号码是2001、3001和3002的交易来“模拟”所请求的交易号码为1001的交易。一旦控制组件40确定存在来自主机16的、用于与交易号码为2001、3001和3002的交易的交易消息，控制组件40便知道在主机环境12中已经完全进行了与所请求的交易号码为1001的交易相对应的“替换交易”。基于在所接收到的三个交易消息中包含的结果，因而由控制组件40为请求了交易号码为1001的第一类型的交易32的客户端42生成了消息。

如图5中所示，将交易号码为4002的第四类型的交易分配给第一类型32的另一交易1002。第四类型的交易已经在新系统平台上运行。该情况在图6中示出。

在如上所述地配置了主机环境12和分散环境14之后，主机16至新系统平台(例如，具有基于其上的IBM CICS迁移环境的IBM zOS平台)的迁移可以开始。

在本实施例中，逐步进行主机16的迁移。为此，首先在新系统平台上操作具有新主机子组件的新主机44。第三类型的第三数据库46是这些新主机子组件之一。第三数据库46在内容方面与先前系统平台上的第二数据库22具有共有特征，但是与该第二数据库22相比在结构方面进行了修改(因而具有例如不同的逻辑数据模型)。因为第三数据库46不再在结构上与第二数据库22一致，所以对于新系统平台不能管理第三类型的应用程序30。作为替代，必须为主机44产生第四类型的交易48。除了第二和第三类型的交易34、36(仅涉及先前系统平台)之外，也另外提供第四类型的交易50(由点线箭头表示)。第四类型的交易50利用了新系统平台上的第四类型的应用程序48，因而也利用了第三类型的数据库。

先前主机16和新主机44的数据库在迁移阶段内首先是共存的。管理两个主机16、44的数据库需要在两个平台上的分散环境中扩散所请求的第一类型的交易32。这里，实施例中的控制组件40将所请求的第一类型的交易32分为先前系统平台上所分配的第二和第三类型34、36的交易、或者分为在新系统平台上所分配的第四类型的交易50，以及(如果必要)在旧系统平台上的第二类型的交易34。第四类型的交易50可以被解译为第三类型的交易36的“同型交易”，因为交易36、50的类型在数据库层级上具有至少类似的影响。

可以基于不同的标准来决定所请求的第一类型的交易32应当被分为第三类型和(如果必要)第二类型的交易34、36，还是应当被分为第四类型和(如果必要)第二类型的交易34、50。例如，可以预想部分(tranche)地进行数据库内容的迁移，并根据与所请求的第一类型的交易34相关的该部分的迁移状态来做出决定。以下结合图9更加详细地解释该作用的示例。

有利地，第三和第四类型的交易32、59是基于相同格式的交易消息。另外写入第四类型的应用程序48，使得这些应用程序可以同样地解译和处理先前与第三类型的交易36相结合所使用的交易消息。该方法明显地避免了在迁移期间出现的问题，因为在迁移之后也可以保持消息句法，因而仅需要略微修改控制组件。

在通过图5中的表开始迁移阶段之后，也将各个交易相互分配。为此，响应于对第一类型交易32的请求，通过由控制组件40启动的第四类型的交易50的交易号码来补充为第四类型的交易50所提供的列。例如，这表示对于所请求的交易号码为1002的第一类型的交易，另外对于交易号码为2001的第二类型的交易34，启动交易号码为4001的第二类型的交易50。另一方面，对于交易号码为1002的第一类型的交易32，不启动第三类型的交易36。

在图5所示的示例中，总是针对所请求的第一类型的交易32来启动第二类型的交易34和另外地第三类型的交易36(如针对具有交易号码1001的第一类型的交易32所示)或第四类型的交易50(如针对具有交易号码1002的第一类型的交易32所示)通过控制机制32B′和36B来启动第三和第四类型的交易36、50。

图7示出了在停止第三类型的交易36之后的OLTP系统10。现在配置控制机制32B′和36B，从而现在仅针对所请求的第一类型的交易32来启动第四类型的交易50。另一方面，控制机制32B和34B仍继续启动第二类型的交易34。

在已经停止了第三类型的交易36之后(或者甚至之前)，可以使用关联类型的应用程序28将第一数据库20迁移至新系统平台。在示例中，假设将在新系统平台上管理第一数据库20，而不改变逻辑数据模型(因而至少是大部分自动地)。为此，不必为新系统平台重写访问了仅第一数据库20的第二类型应用程序28中的应用程序。作为替代，第二类型应用程序28中的应用程序的迁移仅需要代码转换(可以至少大部分是自动地)至新系统平台。这种情况可以参照图8进行详细解释。

图8示出了完全迁移了的OLTP系统10。除了第三数据库46和相关联的第四类型的应用程序48之外，新系统平台上的主机44现在还包括在结构上与先前系统平台上的第一数据库30相对应的第四数据库56。第五类型的应用程序58中的应用程序(通过代码转换从第二类型应用程序28中的应用程序中生成)访问第四数据库56。第五类型的交易60(由具有双点的点线箭头所表示)替换了目前仍在使用的第二类型的交易34。第五类型的交易60利用了第五类型的应用程序5 8中的应用程序和第四数据库56。

图9示出了OLTP系统10至新系统平台的逐部分(tranche-by-tranche)迁移。在图9中示出的实施例中，在先前系统平台上提供了多个并行主机16、16′等。根据图9的OLTP系统10的迁移状态与图6所示的OLTP系统的迁移状态相对应。

在旧系统平台上的主机16、16′等中的每个具有类似的主机子组件，具体是类似的应用程序。主机16、16′等仅在各个数据库20、22的内容方面不同。因此不同的数据库内容导致了不同实体组的主机16、16′等处理数据集合。例如，主机16可以关心实体组001至010的数据集合，而主机16′可以关心实体组011至020的数据集合。每个实体组包括多个不同实体，针对这些不同实体将数据集合保持在各个数据库中。

如果分散环境14中的客户端42之一针对特定实体的数据集合请求特定类型的交易，则控制组件40识别与所请求的交易相关联的实体，并将交易消息发送至主机16、16′等，主机16、16′等管理由控制组件40识别的实体所属于的实体组。

先前系统平台上的多个单独主机16、16′等通过新系统平台上的单个主机44进行替换。因为避免了运行在并行主机16、16′等上的应用程序的代码复制(需要高维护费用)，所以这也是有利的。此外，可以极大地减小独立数据库的个数。

在新系统平台上对数据库46和应用程序48类型进行操作之后，逐部分地发生实体至新系统平台的迁移。例如，这表示对于主机16来说，它所关心的一些实体组(只要在任何情况下涉及到第三类型的交易36)被迁移至新系统平台。控制组件40实际需要知道是先前主机16、16′等还是新主机44关心针对其请求了交易的特定实体。因此，根据图9，控制组件40包括知道各个实体(或者实体组)的迁移状态的第三、最高控制层40。

在第三控制层40中，尤其实现了两个控制机制32C、32C′和其它两个控制机制36C、36C′，控制机制32C、32C′与嵌入第二控制层40″的控制机制32B′进行通信，控制机制36C、36C′与设置在第三控制层40″的控制机制36B进行通信。制控制机制32C、32C′与嵌入第二控制层40″的控制机制32B′进行通信。在第三控制层40中的控制机制32C、32C′、36C、36C′确定分配给所请求的第一类型的交易32的实体(或者实体组)以及该实体的迁移状态。例如，可以以表格形式登记各个实体(或实体组)的迁移状态。

在确定了所请求的交易所基于的实体的迁移状态之后，根据所确定的迁移状态或新系统平台上的第四类型交易50，在先前系统平台上，在控制层40中进行第三类型的交易36。因而在图5中，具有交易号码1001的第一类型的交易32与还没有迁移的实体相关(因为没有将第四类型的交易50分配给该交易)，而具有交易号码1002的第一类型的交易32与已经迁移的实体相关(这是已经启动具有交易号码4002的第四类型的交易50的原因)。

在要进行第三类型的交易36的范围内，另外在控制层40(或者位于其下的控制层40′、40″之一)中确定主机16、16′等中的哪个关心所确定的实体所属于的实体组。随后将关联交易消息发送给的负责的主机16、16′。

如从对优选实施例的前述描述中可见，根据本发明的迁移方法具有一系列优点。首先强调的是，除了可选的控制组件之外，主机环境的迁移对分散环境没有影响。因此，分散环境中的不同客户端不需要例如软件更新，以便能够甚至在迁移之后继续请求所有先前类型的交易。因此分散环境保持稳定，甚至可以在分散环境中保持消息句法。其他优点在于可以逐步进行迁移的事实。尤其整个数据库环境并不必特别在新系统平台上进行操作。还应强调的是，根据本发明的方法还支持在先前和新系统平台上的主机的并行操作。