JP4397385B2 - コンピュータに格納されたコンピュータプロセッサ命令として実装されている方法およびコンピュータにより読み取り可能な記憶媒体 - Google Patents

Description

本発明は、コンピュータに格納されたコンピュータプロセッサ命令として実装されている方法およびコンピュータにより読み取り可能な記憶媒体に関する。

本発明は、構造的に互換性のない種々のデータベースシステムの統合に係わる。データベースシステムは電子データ処理の数多くの適用事例において大きな役割を果たしている。

それらのデータベースシステムは通常、本来のデータベース（データバンク）とデータベース管理システムによって構成されている。そしてそれらは、データベースに格納されているデータが多種多様に処理されるような広範囲に及ぶコンピュータアプリケーションの基礎を成すことが多い。

企業ＥＤＰの分野において重要な例はいわゆるＥＲＰ（Enterprise Resource Planning）システムであり、たとえばドイツ連邦共和国 Walldorf のSAP 社による OLTP-R/3 などである。それらによって人事や販売や在庫管理など様々な企業分野におけるＥＤＰ支援を、１つの共通の中央データベースに基づき実現することができる。この種のシステムはバックオフィスシステムと呼ばれることが多い。

データベースシステムの別の重要な実例はカスタマサポートシステムであり、それらはしばしばＳＦＡ（Sales Force Automation）またはＣＲＭ（Customer Relation Management）システムと呼ばれる。この種のシステムは殊に、カスタマアドバイス、カスタマサポートならびに販売におけるＥＤＰ要求に合わせてカスタマイズされている。これには、企業の外勤従業員にポータブルコンピュータを装備させ、このコンピュータによりデータベースシステムのモバイルクライアント（mobile client）として、個々の外勤従業員が必要とするデータ（たとえばその従業員の地区のカスタマに関するデータやその従業員の販売状況に関するデータ）をもつ固有のローカルデータベースが提供される。このようなシステム（フロントオフィスシステムと呼ばれることが多い）には、やはりデータベースを有する中央コンピュータが含まれており、そのデータベースにはモバイルクライアントのデータの総計が格納されている。つまりこれはオフライン分散型データベースシステムである。モバイルクライアントのほかにＣＲＭシステムの中央コンピュータとは他の外部のシステムも通信を行うことができ、たとえばカスタマのＥＤＰシステムなどがそれを行うことができ、このシステムは一時的にまたは定常的なデータコネクションを介して中央コンピュータに接続される。

慣用のバックオフィスシステムも慣用のフロントオフィスシステムも非常に複雑である。それらのシステムのためには様々なコンポーネント間の通信能力、データ保全性およびデータの同期を確保するためにパワフルな方法がそれぞれ必要とされ、その際、著しく多くのユーザ数を通信に含めることができるよう考慮しなければならない。

先に挙げた形式の大規模なシステムについて広範囲にわたりこの問題が解決されている一方で、構造的に互換性はないがかなりの部分で同じ（業務）データを管理しているデータベースシステムを互いに融合させる確かな方法はまだない。たとえばＥＲＰシステムでは通常、企業のカスタマに関する大規模なデータセット（たとえば住所、仲介者、処理されたオーダや仕入れ状況に関するデータなど、また、補充交換部品納入に重要なカスタマのマシン装備に関するデータなど）が格納されている。広範囲にわたり一致しているデータセットはＣＲＭシステムにおいても必要とされる。しかし実際には両方のシステムは、相互に互換性のないまったく異なるデータ構造をもっている。

たとえば価格決定（pricing）は、種々のアプリケーションにおいてＥＤＰサポートを受けて実行されるタスクである。（たとえば原価、個数、運搬費、および場合によっては特別な条件を考慮した）一貫した業務の流れが基礎を成しているにもかかわらず、種々のデータベースシステムへの実装は完全に異なっていることがよくあり、つまり業務処理のインプリメントに利用されるアルゴリズム（いわゆるビジネスロジック "Businesslogik"）は非常に異なっている。とはいえ当然ながら、価格決定を種々異なるシステムにおいてできりかぎり等しく取り扱えるようにして同じ結果が得られるようにする必要がある。

本発明の課題は、構造的に互換性のないデータベースシステムを、双方向で問題なくデータ交換できるよう相互に融合することである。ここでシステムの「融合」とは、技術レベルでの結合を超えて、データ同期を実現し、それぞれ異なるシステムにおいてほぼ同じ動作が得られるような制御ロジックの交換を可能とすることである。複数のサブシステムから成る統合された１つの結合システムへのこのような融合を、ここではセマンティック・システムインテグレーション（"semantic system integration"）と称する。このためにはたとえば、
−システムの確実な技術的結合
−融合されたシステムにおける有効データの同期合わせ
−融合されたシステムをコントロールするためのカスタマ固有の整合（カスタマイズデータ）の同期合わせ
−データ変更の食い違いや他のデータ不一致が発生したときの適切なコンフリクト解消法
が必要とされる。

オンラインでもオフラインでも安定したコネクションを形成するため、実証済みのハードウェアテクノロジーおよびソフトウェアテクノロジーを利用することができる。この場合、キューメカニズムが重要な役割を果たし、これによれば各データ単位が正確に１回で伝送され（guaranteed delivery）、データが精確に決められた順序で伝送されるようになる（In-Order-Processing）。セマンティックなシステム統合のこのような部分的な観点については詳しく説明する必要はない。

これに対し、前述の他の要求の実現のためには非常に難しい問題点があり、殊に一般に出発点となり得るのは、様々なデータベースシステムがソフトウェア製品の様々な「世界」に属する可能性のあることである。

本発明の課題は、このような問題点を解決するシステムコンポーネントおよび方法を提供することである。

種々のデータベースシステムのデータモジュールはそれぞれ異なっている。したがってそれらのデータ構造を相互にマッピングしなければならない。しかもデータ内容の整合が必要とされる（たとえば用語の使い方としてあるシステムの「カスタマ customer」は別のシステムでは「バイヤ buyer」に対応している）。これら両方の機能は、互換性のない２つのシステム間のデータ交換においてスタンダードな役割設定である。慣用のシステム統合はこのような形式のコネクションに関するものである。これによれば、統合システム全体において有効でなければならないデータの新たなエントリを、複数のシステムのうち中央システムと称する１つのシステムにおいてのみ、データベース結合システム全体に対して有効に実施することができる。しかしこのことは多くの事例において、たとえばＣＲＭシステムとＥＲＰシステムとの融合においては不十分である。なぜならばその場合、重要な新たなデータは企業のヘッドオフィスにおいても（つまりＥＲＰシステムにおいても）カスタマサポートにおいても（つまりＣＲＭシステムにおいても）生じるものであり、新たに取り込まれた後には結合システム全体で利用できなければならないからである。

システムを超えてクロスシステムないしはシステムワイドに供給されるデータの新たなエントリを結合システムの各サブシステムにおいて実行できるようにしようという場合（つまり新たなエントリ実行後にけつごうしすてむのすべてのサブシステムにおいて利用できるようにしようという場合）、そのためにはいかなる時点でもデータオブジェクト識別のためシステムを超えて一義的なプライマリキーを利用できるようにしなければならない。その際、このようなプライマリキーを数値範囲の割り当てやＧＵＩＤ（Global Unified Identifier）キーの割り当てによって生成することが知られている。とはいえこれら両方のやり方は汎用的に利用できるものではない。

数値範囲の割り当てのためには、関与するデータベースシステムにおいてキーを生成するために同じアルゴリズムが必要とされる。このことはそれぞれ異なるメーカのシステムにおいて保証することはできない。また、同じメーカの種々のシステムであっても、様々なキー生成手順の実装されていることが多い。

また、ＧＵＩＤを用いた一義的なキーの生成を利用できるのは、関与しているすべてのシステムがＧＵＩＤ手順を利用しているときだけである。このこともやはり多くの事例において保証できないことである。

本発明によればこの課題は、コンピュータに格納されたコンピュータプロセッサ命令として実装されている方法において、前記コンピュータプロセッサ命令により、プロセッサと記憶手段と入出力手段を有する少なくとも１つのコンピュータが、該コンピュータの記憶手段に格納されているデータベースシステム内のデータセットを更新し、第１のデータベースシステムにおけるコンピュータの記憶手段に格納されたデータセットに対して実行された変更によって、第２のデータベースシステムにおけるコンピュータの記憶手段に格納されたデータセットが更新され、前記第１のデータベースシステムのデータセットには、前記第２のデータベースシステムには関連しない非関連データと、前記第２のデータベースシステムに関連する関連データの双方が含まれており、前記データベースシステム双方におけるデータは、該データベースシステムにおけるコンピュータの記憶手段に格納されたデータオブジェクトとして前記データベースシステムにおけるコンピュータのプロセッサにより処理され、データオブジェクト各々には、該データオブジェクトを処理するためのシステム固有のプライマリーキーが含まれており、前記第２のデータベースシステムにおけるコンピュータのプロセッサは、該第２のデータベースシステムにおけるコンピュータの記憶手段内のデータを、前記第１および第２のデータベースシステムのシステム固有のプライマリキーとともに格納し、前記コンピュータの記憶手段に格納されているデータセットを更新する命令には、前記データベースシステム双方におけるコンピュータのプロセッサに対し、ａ）前記第１のデータベースシステムにおけるコンピュータの記憶手段に格納されている第１のデータオブジェクトから、前記第２のデータベースシステムには関連しない格納データを分離するステップと、ｂ）前記第１のデータオブジェクトを、前記第１のデータベースシステムにおけるコンピュータの記憶手段から、前記第２のデータベースシステムにおけるコンピュータの記憶手段へ、データネットワークを介して転送するステップと、ｃ）前記第２のデータベースシステムのコンピュータにおける第２のデータベースシステムに固有のキーを生成し、生成された該キーに、前記第２のデータベースシステムにおけるコンピュータの記憶手段に格納されたデータオブジェクトをもたせるステップと、ｄ）得られたデータオブジェクトを前記第２のデータベースシステムにおけるコンピュータの記憶手段の格納ルーチンに組み込み、前記データオブジェクト内に含まれているデータを、前記第２のデータベースシステムにおけるコンピュータの記憶手段に格納するステップを実行させる命令が含まれていることにより解決される。さらに本発明の課題は、請求項４、請求項８、請求項１１記載の特徴により解決される。

本発明の１つの観点によれば、前記コンピュータプロセッサ命令により前記データベースシステムにおけるコンピュータのプロセッサは、前記第２のデータベースシステムにおけるコンピュータの記憶手段の格納ルーチンに前記第１のデータオブジェクトを組み込む前に、該データオブジェクトのデータレコードを前記第１のデータベースシステムにおけるコンピュータの記憶手段における第２のデータベースシステムのデータセットに対応する付加的な値によって補う。

さらに本発明の別の観点によれば、前記第１のデータベースシステムにおけるコンピュータの記憶手段におけるコンピュータプロセッサ命令により該コンピュータのプロセッサは、前記第１のデータベースシステムにおけるコンピュータをＯＬＴＰ−Ｒ／３システムとして動作させるＯＬＴＰ−Ｒ／３命令を実行し、前記第２のデータベースシステムにおけるコンピュータの記憶手段内のコンピュータプロセッサ命令により該コンピュータのプロセッサは、前記第１のデータベースシステムにおけるコンピュータをミドルウェアサーバシステムとして動作させる命令を実行する。

他の従属請求項には本発明のその他の有利な実施形態が示されている。

次に、図面に示された実施例に基づき本発明について詳しく説明する。そこで説明する特徴は、本発明の有利な実施形態を実現する目的で個別に用いることもできるし、互いに組み合わせて使用することもできる。

図面に実施例として示されている本発明による統合された結合システムの適用事例は、販売ＥＤＰソリューション（Sales Force Automation; SFA）と中央ＥＲＰシステムとの統合に関する。図１には、その種のシステムの周囲環境に関する概観が描かれている。

外勤従業員（Sales Representative）ＳＲは外勤フィールドＦＤで働いており、その従業員はカスタマ（Customer）Ｃと相談してたとえばカスタマの注文をとる。外勤従業員ＳＲは各々ポータブルコンピュータをもっており、これをモバイルクライアント（Mobile Client）ＭＣとも称し、ローカルデータベース（Local Database）ＬＤに属している。ポータブルコンピュータはネットワークのノードを成しており、これは常にネットワークと接続されているわけではなく、したがってオフラインノードと称する。

モバイルクライアントＭＣはたとえばマーケッティング情報を提供し、殊にカスタマや製品の基本データ（マスタデータ）を格納している。外勤従業員ＳＲはたとえば注文情報を入力し、また、未処理の注文や処理済みの注文についての状況の情報を得る。これらの機能を一時的に自律的に実現できるようにする目的で、そのために必要とされるすべてのデータがローカルデータベースＬＤに格納されている。

企業の本部（Head Office）にはバックオフィスシステムが存在しており、これによって有利にはオンライントランザクションプロセッシングを行うことができる。ここに示されている実施例ではこれはＯＬＴＰ−Ｒ／３システムである。図面および以下の説明ではそのシステムの用語で表すが、汎用性を制約するわけではない。これにはデータベースＯＬＴＰ−ＤＢが含まれている。その基本データは内勤従業員（In-House-Employee）ＩＨＥによってメンテナンスされる。

ローカルエリアネットワーク（Local Area Network）ＬＡＮを介してＯＬＴＰ−Ｒ／３システムはフロントオフィスサーバと接続されており、これをミドルウェアサーバ（ＭＳ Middleware Server）と呼ぶが、はやり汎用性を制約するわけではない。このシステムもデータベースＣＤ（Condolidated Database）を有している。

ＭＳシステムには、モバイルクライアントＭＣのほかにオプションの別のシステムを接続することができる。図示されているように、本部ＨＯには外部システムＢＷが配置されており、これはたとえばいわゆる "Business Information Warehouse" として企業にとって重要な販売情報を分析する。これはデータベースＢＷ−ＤＢを有している。図示されている事例の場合、これはバックオフィスサーバＯＬＴＰ−Ｒ／３からもＭＳシステムからもデータを受け取る。外勤フィールドＦＤにおいてたとえば、ネットワーク内の付加的なノードを成すカスタマシステム（Customer System）ＣＳを常に（オンライン）または一時的に（オフライン）ＭＳシステムと接続することができる。このようにすればたとえば、カスタマの注文を外勤従業員を介在することなく処理することができる。

このように図示されているネットワークは種々のデータソース（モバイルクライアントＭＣ、ＯＬＴＰ−Ｒ／３、オプションの外部システムＢＷおよびカスタマシステムＣＳ）を有しているが、それらは互いに独立していない。それらはＭＳシステムによって結合され、このシステムによれば各サブスクライバが自身に必要とされる許された情報を受け取るようになる。図示されている事例の場合、ミドルウェアサーバＭＳは同時にこのような結合機能も果たし、これとモバイルクライアントから成るＣＲＭシステムの中央コンピュータを成しており、これはオフライン分散型データベースシステムである。これが中央データベースシステムＯＬＴＰ−Ｒ／３と融合される。しかしながら本発明の基本原理をデータベースシステム融合に関する他の事例にも適用可能であり、つまりたとえば、２つまたは複数の中央データベースシステムの融合あるいは２つまたは複数の分散型データベースシステムの融合にも適用することができる。

ＭＳシステムのデータベースＭＳ−ＤＢには、その特有の機能（たとえばカスタマリレーションシップマネージメント Customer Relationship Management CRM）に必要とされるすべての情報が含まれている。これは統合データベースＣＤ（consolidated data base）とも呼ばれる。なぜならばこれには（直前のデータ交換時点で）ポータブルコンピュータにおけるすべてのローカルデータベースＬＤの内容が含まれているからである。これにより、ローカルデータベースＬＤに必要なデータを供給して、たとえばデータの変更を伝達したり必要に応じてローカルデータベースＬＤをリストアすることができるようになる。

ポータブルコンピュータは所定のインターバルで、一例として毎日夕方、たとえば電話回線、インターネットまたはイントラネットを介して、ＭＳシステムと接続される。この場合、直前の接続以来収集されたデータがＭＳシステムに伝送される。しかもポータブルコンピュータはその機会に、それぞれ先行する期間における自身の固有の処理データと、（必要なかぎり）他のポータブルコンピュータおよび別のシステムの新たな入力データを受け取る。

相互に接続されたシステムの有効データは（この実施例ではカスタマやオーダなど業務処理に関連するので）ビジネスデータと呼ばれる。ＯＬＴＰ−Ｒ／３システムの場合にはそこからビジネスオブジェクト（"BDoc"）が形成され、これは別の処理のためのデータコンテナとして用いられる。たとえばある特定のオーダのためのビジネスオブジェクトはそのデータベース内に格納されているそのオーダに属するすべてのデータを有しており、これはそれらのデータがどのようにその論理構造（リレーショナルデータベースのテーブル）内にあるかとは無関係である。この構造はＯＬＴＰ−Ｒ／３システムにとって知られているものであり、同じようにして他のバックオフィスシステムにも適用される。

関与するシステムにおいてビジネスデータを処理するのに必要とされる制御データは、個々のデータベースにおける論理的に別個の部分に格納されており、これをレポジトリと称する。

ＯＬＴＰ−Ｒ／３システムへの伝送について、伝送基準は広範囲にわたりスタティックである。これはひとたび設定されると、個々の企業における業務の流れの変更を比較的長い期間で変える必要がないかぎり、そのまま保持される。

これに対し、ポータブルコンピュータへのデータ伝送は高度にダイナミックである。たとえば特定の販売地区に対する外勤従業員の管轄は頻繁に変わる可能性が多い。このような変更によってそのつどデータ伝送のための基準の変更が生じる。それというのも、それぞれ必要とされる最小データだけをポータブルコンピュータへ伝送すべきだからである。同じ理由で、ポータブルコンピュータ内で古くなったデータを消去しなければならず、他方、最近になって重要になったデータを追加する必要がある。データ伝送基準は有利には、ＭＳシステム内でいわゆるパブリケーション（publication）およびサブスクリプション（subscription）として格納される。モバイルクライアントＭＣへの伝送基準およびデータの更新プロセスを、以下ではリアライメント（realignment）と称する。

特定のデータは１つよりも多くのポータブルコンピュータにとって重要であるので、ポータブルコンピュータへの伝送時にコピーする必要がある。１つよりも多くの受信側へのこのような伝送を、以下ではレプリケーション（replication）と称する。

図２には、ＭＳシステムのアーキテクチャに関する概観が示されている。左側にはモバイルクライアントＭＣが描かれ、下方にはＯＬＴＰ−Ｒ／３システムおよび外部システムＢＷが描かれている。図の他の部分には、データベースＣＤおよびそれに属するメッセージ伝送サーバ（Message Transfer Server）ＭＴＳを含めてＭＳシステムが示されている。

ＭＳシステムは有利にはＲ／３テクノロジーをベースとして実装されている。したがってその機能を複数のマシンに分散させることができ、たとえばデータベースのために１つの別個のマシンを使用し、要求処理のために１つまたは複数のマシンを使用することができる。メッセージ伝送サーバとして動作するマシンは、全体としてアドミニストレーションステーション（アドミンステーション Admin Station）ＡＳと称する。メッセージ伝送サーバＭＴＳおよびそれに属するアドミニストレーションコンソール（アドミンコンソール Admin Console）ＡＣは有利には、Windows NT によって動作する１つのマシンにインストールされる。その結果生じる可能性のあるマシンの境界は図中、破線で描かれている。

フロントオフィスシステムにおけるデータの伝送のためにデータコンテナが使用され、これをＢＤｏｃと称する。これはモバイルクライアントＭＣとＭＳシステムとの間の通信にも用いられる。この場合、様々な種類のＢＤｏｃを区別することができる：
−ポータブルコンピュータＭＣとフロントオフィスサーバＣＲＭ−ＭＳとの間でトランザクション結果とステータス情報を伝送するため、トランザクションＢＤｏｃが使用される。それらを以下のようにさらに区別することができる：
トランザクションＢＤｏｃはトランザクション結果をモバイルクライアントＭＣからＭＳシステムへ搬送する。この場合、モバイルクライアントがＢＤｏｃを成し、これはトランザクションの結果を有しており、それをＭＳシステムへ送信する。

承認ＢＤｏｃ（Confirmation BDoc）は、ＭＳシステムによるトランザクションＢＤｏｃの処理成功を表す。トランザクションＢＤｏｃの処理がうまくいったならば、ＢＤｏｃのステータスがそれ相応に変化し、それを送ったモバイルクライアントへ承認メッセージとしてＢＤｏｃが送り戻される。この承認メッセージには、たとえばＯＬＴＰ−Ｒ／３システムによって提供された付加的なデータあるいは統合データベースＣＤの変更された値も含まれている。その際、承認ＢＤｏｃには、変更された値だけまたはすべての値が含まれている。

インポートＢＤｏｃは、他のモバイルクライアントＭＣまたは外部のシステムのトランザクション結果をＭＳシステムからモバイルクライアントＭＣへ伝送する。インポートＢＤｏｃにも、変更された値だけがまたはすべての値が含まれている。さらにインポートＢＤｏｃは、モバイルクライアントＭＣとは別のソースからのデータ変更をＭＳシステムからモバイルクライアントへ伝送するためにも利用される。

エラーＢＤｏｃ（Error BDoc）は、トランザクションＢＤｏｃの処理にあたりＭＳシステムにおいてエラーの発生したことを表す。この場合、エラーセグメントがＢＤｏｃに挿入され、送信を行ったモバイルクライアントＭＣへエラーＢＤｏｃとして送り戻される。エラーセグメントは、種々のエラー状態を表示するために種々のレコードを有することができる。さらにエラーＢＤｏｃには、「先行の状態のイメージ」（before images）としてもとの値も含まれている。すべてのフィールドは、統合データベースＣＤの目下の内容で満たされている。
−サービス指向ＢＤｏｃは、ＭＳシステムからポータブルコンピュータＭＣへバイナリデータを伝送するために使用される。
−バルク指向ＢＤｏｃ（Bulk oriented BDoc）は、たとえば初回のデータダウンロード時などにＭＳシステムからモバイルクライアントＭＣへ大量のデータを伝送するために使用される。

さらにＢＤｏｃは、搬送された内容に関して種々のＢＤｏｃに細分化することができる。ＢＤｏｃをたとえば「カスタマ」、「オーダ」などとすることができる。

ＢＤｏｃおよび殊にその構造についての詳細な説明はあとで行うことにする。

ＭＳシステムにおけるデータ処理は、「サービス」もしくは「アダプタ」と呼ばれるファンクションモジュールを用いて行われる。サービスは、ＢＤｏｃに適用できる特別なファンクションを提供する。アダプタは特殊なタイプのサービスであり、これによればＭＳシステム外におけるシステムとのコネクションが可能となる。

モバイルクライントＭＳとミドルウェアサーバＭＳとの通信もそれらのローカルデータベースＬＤとの通信も、もっぱらトランザクション層（Transaction Layer）ＴＬを介して行われる。パートレプリケートデータベースネットワークシステム（part-replicated data base network system）の例としてのミドルウェアサーバＭＳとモバイルクライアントとのデータ交換にについての詳細は、国際出願 PCT/DE00/01552 に示されており、これを本出願の参考文献とする。

図２には描かれているＭＳシステムにおける各コンポーネントの機能は、以下のような特徴を有している。

メッセージ伝送サーバＭＴＳはモバイルクライアントＭＣからＢＤｏｃを受け取り、ＢＤｏｃをそのモバイルクライアントに伝送する。データ伝送はそれぞれ１つのモバイルクライアントＭＣによって導入される。たとえばその目的で、Microsoft の通信テクノロジーＤＣＯＭを利用することができる。

モバイルクライアントＭＣからＭＳシステムへのＢＤｏｃの伝送は到来メッセージ用アダプタ（Inbound Message Adapter）ＩＭＡによって行われる一方、逆方向で伝送されるメッセージは送出メッセージ用アダプタ（Outbound Message Adapter）ＯＭＡによって伝送される。このようなデータ伝送は、ｑＲＦＣ（queued Remote Function Call）と称するプロトコルによって行われる。これは処理の順序を決定するためにキュー（queue）を利用するリモートファンクションコールプロトコルである。

ＭＳシステムの中央コンポーネントはフローコントロール（Flow Control）ＦＣである。フローコントロールＦＣはＢＤｏｃの処理を行い、到来するＢＤｏｃを適正な順序でサービスおよびアダプタへルーティングし、必要であればエラー処理プロシージャをトリガする。これはすべてのサービスおよびアダプタに対し同じインタフェースを介して行われる。他方、このインタフェースにおけるメインパラメータはＢＤｏｃである。フローはＢＤｏｃタイプ固有に制御データメモリ（レポジトリ Repository）内で定義されている。

ＯＬＴＰ−Ｒ／３システムおよびＢＷシステムなど外部のシステムは、それぞれ固有のアダプタＯＬＴＰ−ＡＤもしくはＢＷ−ＡＤを介してＭＳシステムと接続されている。つまり外部システムはやはり各々固有のアダプタタイプをもっており、これもＢＤｏｃ固有にレポジトリ内に定義されている。アダプタおよびそれに接続された外部システムとの間のデータ伝送チャネルのプロトコルおよびデータ構造は、外部システムのタイプに固有のものである。

データベースサービス（Consolidated Database Service）ＣＤＳは、統合データベース（consolidated database）ＣＤに相応のデータを格納するために用いられる。このサービスＣＤＳは、データをデータベースに書き込むときにデータ一致性のチェックを実行しない。そのようなチェックは、データをＭＳシステムへ伝送するコンポーネント（たとえばモバイルクライアントＭＣまたはＯＬＴＰ−Ｒ／３システム）によって実行する必要がある。データベースＣＤの読み出しのため他のサービスはサービスＣＤＳを利用するのではなく、図示されていない特別なハンドラを利用し、これはサービス、アダプタまたは他のハンドラから呼び出される。

レプリケーションおよびリアライメントモジュールＲＰＭは２つの主要な役割をもっている。レプリケーションパートは処理されたＢＤｏｃを引き継ぎ、その受け取り側を決定する。いっそう迅速に処理するため、そのために必要とされる情報がルックアップテーブルから読み出される。目下処理されているＢＤｏｃに基づきルックアップ情報の変更の必要性をレプリケーションパートが確認すると、そのレプリケーションパートはリアライメントハンドラをトリガする。リアライメントハンドラはレプリケーションルールを評価して、必要とされるルックアップ情報を生成する。さらにリアライメントハンドラは受け取り側に対し新たなデータを提供し、不必要なデータを消去する命令を出す。この目的でリアライメントハンドラは特別なハンドラを用いる。

ＭＳサーバをカスタマ固有に整合するため（カスタマイズするため）、および論理的なデータの流れについてシステム全体を管理するために、アドミニストレーションコンソールＡＣが利用される。

図３にはデータアップロードオペレーションの実施例として、ＭＳシステムにおけるフローコントロールの典型的な流れが示されている。この場合、フローコントロールＦＣのメッセージプロセッサ（Message Processer）ＭＰによって実行されるステップが、ＭＰ−ＦＣと付された列に描かれている。第１および第３の列には、サービスにより実行される処理ステップが示されている。最後の列には、ＯＬＴＰ−Ｒ／３システムによって実行される処理ステップが示されている。

この流れは、新たなＢＤｏｃを受け取ったため、メッセージ伝送サーバＭＴＣが（ＲＦＣを介して）到来メッセージＩＭＡのためのアダプタを呼び出したときに始まる。到来メッセージＩＭＡのためのアダプタによってメッセージプロセッサＭＰ−ＦＣがスタートする。

実行すべき流れはメッセージプロセッサＭＰによって決定される。この場合、基本的に２つのフロープロシージャを区別することができ、１つは少なくとも部分的にＯＬＴＰ−Ｒ／３システムに関連するＢＤｏｃタイプの処理のためのものであり、１つはその他のＢＤｏｃ（ＭＳシステム内でのみ巡回する）のためのものである。

個々のＢＤｏｃタイプのためにレポジトリに格納されているフロー定義に依存して、メッセージプロセッサＭＰは呼び出される第１のサービスもしくはアダプタを決定する。（少なくとも部分的に）ＯＬＴＰ−Ｒ／３システムに関連するＢＤｏｃのタイプのために、第１のサービスとしてＯＬＴＰ−Ｒ／３アダプタＯＬＴＰ−ＡＤが呼び出される。その他のＢＤｏｃのためにはＯＬＴＰ−Ｒ／３アダプタは呼び出されない。ＢＤｏｃのタイプのためにＯＬＴＰ−Ｒ／３アダプタを呼び出すか否かの判定は、フローの決定時に下されており、つまりこのフロー内では下されない。

ＯＬＴＰ−Ｒ／３アダプタＯＬＴＰ−ＡＤが呼び出されるとそのアダプタは、ＢＤｏｃが本当にＯＬＴＰ−Ｒ／３システムに関連するものなのかを決定する。このことは必ずしもあてはまらない。それというのもＯＬＴＰ−Ｒ／３システムに対する関連性はＢＤｏｃにのみ左右されるのではなく、その内容にも左右される可能性があるからである。１つの例は、ビジネスオブジェクトタイプ「カスタマ」のＢＤｏｃである。このようなＢＤｏｃにカスタマに関する情報が含まれているならば、それはＯＬＴＰ−Ｒ／３システムへ送られるが、販売渉外担当（sales and distribution contact）に関する情報が含まれているなら、それはＭＳシステム内にしか格納されない。

ＢＤｏｃがＯＬＴＰ−Ｒ／３システムに関連するとＯＬＴＰ−Ｒ／３アダプタが判定したならば、そのアダプタはそれに対してコールを送り、進行中のフローを中断する。ＯＬＴＰ−Ｒ／３システムにおける処理の終了後、それによってＯＬＴＰ−Ｒ／３アダプタへコールが送られ、そのアダプタは結果を引き継ぎ、フローを再びスタートさせて、フローコントロールＦＣのメッセージプロセッサＭＰを呼び出す。

メッセージプロセッサＭＰ−ＦＣは、どのサービスを次に呼び出すべきであるのかを決定する。ＢＤｏｃがＯＬＴＰ−Ｒ／３システムに関連していないことをＯＬＴＰ−Ｒ／３アダプタが検出すると、そのアダプタはメッセージプロセッサＭＰ−ＦＣへコントロールを戻し、この場合もそのプロセッサは次に呼び出すべきサービスを決定する。

通常、ＯＬＴＰ−Ｒ／３アダプタのあとにデータベースサービスＣＤＳが呼び出される。このサービスは、ＢＤｏｃに含まれているデータを統合データベースＣＤ内で持続させる。

データが首尾よく統合データベースＣＤ内に書き込まれると、通常はレプリケーションおよびリアライメントサービスＲＰＭが呼び出される。このサービスの機能は、ＢＤｏｃがレプリケーション情報に作用を及ぼすか否かをチェックすることである。作用を及ぼすのであればリアライメントハンドラに対し、ルックアップ情報を更新しビジネスデータ分配のためにＢＤｏｃを生成するオーダが形成される。レプリケーションおよびリアライメントサービスＲＰＭの第２のアクションは、目下のＢＤｏｃに受け取り側リストを追加することである。

さらに、メッセージ伝送サービスＭＴＳによりＢＤｏｃをその受け取り側へ伝達するために準備処理する目的で、送出メッセージＯＭＡ用のアダプタが呼び出される。

アップロードが失敗した場合にはリジェクトサービスＲＳが呼び出される。ＢＤｏｃはエラーＢＤｏｃとして（つまりエラー情報を含むＢＤｏｃとして）マーキングされる。アップデートオペレーションにおいてリジェクトサービスは有効な値を統合データベースＣＤから読み出す。すべてのオペレーションにおいて、モバイルクライアントＭＣの先行の状態がマークされる。ついでＢＤｏｃは、それを送ってきたポータブルコンピュータへ送り戻される。そこにおいて相応のトランザクションが新たに実行される。

図３には（リジェクトサービスＲＳを除いて）成功経路だけが書き込まれている。当然ながらエラー処理ルーチンも設けられているが、それについてはここでは詳しく説明しない。

次に、図４を参照しながらＢＤｏｃの構造について詳しく説明する。この図の上部にはＢＤｏｃタイプの定義構造が示されており、これはＭＳシステムのレポジトリに格納されている。さらに下部には、同様にレポジトリ内に格納されているＢＤｏｃ自体の構造が描かれている。

ＢＤｏｃは、ＢＤｏｃヘッダＢＤｏｃ−ＨおよびＢＤｏｃボディＢＤｏｃ−Ｂから成る。ＢＤｏｃヘッダＢＤｏｃヘッダ−Ｈにはコントロール情報が含まれており、たとえばＢＤｏｃのタイプ（「カスタマ」、「オーダ」．．．）、その送り手（モバイルクライアントＭＣ）ならびにタイムスタンプなどが含まれている。さらにプライマリキーの複製も含まれていると、パフォーマンスの理由から有利である。

ＢＤｏｃボディＢＤｏｃ−Ｂにはデータが含まれている。データレコード（Data Record）ＤＲには本来のデータが含まれている。この構造は属するデータセグメント（Data Segment）ＤＳの定義中で規定されている。このセグメントは、実際の物理的なテーブルにおける一種のテーブルビューを成している。オプションとしてＢＤｏｃにはさらに、１つまたは複数のエラーレコードＥＲ（Error Record）をもつエラーセグメントＥＳも含まれる。

各データ領域は規定の長さをもっている。それらの領域はキーとデータフィールドから成る。それらの領域に消去情報が含まれているならば、キーフィールドだけに有効なデータが含まれている。また、それらの領域に「インサート」情報または「アップデート」情報が含まれているならば、すべてのデータフィールドに有効なデータが含まれているかまたは、変更されていないフィールドにプリセット値（たとえば０．０）が含まれている。フィールドが満たされているのか利用されていないのかを表す目的で、いわゆる「送信ビット」が使用される。この場合、レプリケーションおよびリアライメントにあたり考慮しなければならないプライマリキーとフィールドが常に（変更された否かとは無関係に）送られる。送信ビットがセットされるのは、値が実際に変更されたときだけである。

ＢＤｏｃタイプの定義つまり階層的におかれた要素から成る個々のＢＤｏｃタイプ固有の構造に関する情報ＢＤｏｃは、ＢＤｏｃタイプの定義（"BDoc Type Definition"）内に含まれており、これはＢＤｏｃボディ定義ＢＤｏｃ−ＢＤとＢＤｏｃセグメント定義ＢＤｏｃ−ＳＤから成る。ＢＤｏｃボディ定義ＢＤｏｃ−ＢＤは正確に１つのルートセグメントを有しており、これにはただ１つのデータレコードだけが含まれている。この条件は遵守しなければならず、その目的はＢＤｏｃ中に含まれている情報がそれぞれ個々のノードシステムへ伝達できるようにまたは別のやり方で処理できるようにするためである。たとえばタイプ「カスタマ」のＢＤｏｃ中には、ただひとりのカスタマに関する情報だけしか格納してはならず、そうすることによってカスタマ情報を個々に所期のように個々のカスタマごとに相応のノードシステムへ導くことができるようになるからである。相前後するセグメントのデータレコードには依存するデータが含まれており、たとえばカスタマのマシン装備に関するデータなどが含まれている。当然ながらこの場合、１つのセグメントに対し複数のレコードを設けることができる。

セグメントがＢＤｏｃタイプの定義中で階層構造をとっているのに対し、ＢＤｏｃの物理的な再生においてはそのような階層はない。階層関係は、依存するセグメントのデータレコードＤＲがそれらの上位のデータレコードのキーを有することにより、ＢＤｏｃ内に収容されている。トランザクションＢＤｏｃの場合にはさらに（エラーレコード Error Record ＥＲをもつオプションのエラーセグメントを除いて）依存しないセグメントが設けられており、これをルートセグメントと称する。

変更されたデータがＭＳシステムへ伝送される場合、モバイルクライアントＭＣが変更前に有していた値がＭＳシステムにとって重要である可能性がある。そのような「先行状態のイメージ」（before image）は固有のデータ領域に伝達され、それらは相応に特徴づけられている。

外部のシステムＢＷおよびインストールファイルをモバイルクライアントＭＣへ伝送するために、サービス指向ＢＤｏｃが用いられる。サービス指向ＢＤｏｃのボディは、一般情報をもつルートセグメントとバイナリデータを含むメモセグメントから成る。

バルク指向ＢＤｏｃは、モバイルクライントの最初のセットアップ（Initial Client Setup）およびリアライメント中のデータ伝送のために使用される。バルク指向ＢＤｏｃもタイプ固有に（つまりたとえばオブジェクトタイプ「カスタマ」などのために）定義されている。とはいえそれらは、そのルートセグメントにただ１つのレコードだけしか収容してはならない、という制約を受けない。したがってたとえばバルク指向ＢＤｏｃは複数のカスタマのデータを一度に伝送することができる。

ＯＬＴＰ−Ｒ／３アダプタＯＬＴＰ−ＡＤは、ＯＬＴＰ−Ｒ／３システムをＭＳシステムとリンクする。これはデータを双方向で伝送するために用いられる。データたとえばカスタマの注文がモバイルクライアントＭＣに入力され、ＯＬＴＰ−Ｒ／３システムに転送される場合、これを「アップロード」と呼ぶ。データがＯＬＴＰ−Ｒ／３システムに入力され、そこからＭＳシステムへ転送される場合、これを「ダウンロード」と称する。

この場合、３つのタイプのダウンロードを区別することができる。初回のデータダウンロード（Initial Download）によって、ＭＳシステムの統合データベースＣＤはオペレーションの開始にあたりＯＬＴＰ−Ｒ／３システムからのデータで満たされる。オンラインユーザがデータをＯＬＴＰ−Ｒ／３システムへ入力し、変更されたオブジェクトがＭＳシステムへ転送されるとき、デルタダウンロードが行われる。このようなデルタダウンロードは、すべてのデータ形式について可能なわけではない。これらの機能が利用できないならば、第３のダウンロードメカニズムが使用され、これを以下では同期メカニズムと称する。

図５には、アップロードおよびダウンロードにおいて有効なＭＳシステムおよびＯＬＴＰ−Ｒ／３システムのコンポーネントが示されている。ＭＳシステムの構成部分は、ＢＤｏｃの処理に必要とされるプロセスステップをコーディネートするためのフローコントロールＦＣ、ＯＬＴＰ−Ｒ／３アダプタＯＬＴＰ−ＡＤならびに３つのエージェントであり、それらはキージェネレータ（Keygenerator）ＫＧ、マッピングエージェントＭＡおよびマージエージェント（Merging-Agent）ＭＥＡと称する。これらのエージェントはＯＬＴＰ−Ｒ／３アダプタのための補助機能を果たす。

ＭＳシステムの構成部分はスタンダードＢＡＰＩ（Business Application Programming Interface）ＳＢを呼び出すためのコールフレームＣＦであり、これはＢＤｏｃの処理中に呼び出すことができる。スタンダードＢＡＰＩは変更を持続的なものにするため、アップデートファンクションモジュールＵＦＭを呼び出す。

アップデータファンクションモジュールＵＦＭは変更のたびにイベントを発し、これはイベントディストリビュータＥＤへ伝達される。このような伝達に対するリアクションとして、イベントディストリビュータはすべてのサブスクライバを始動させる。とりわけこれにより、サブスクライバとしてエントリされている結果伝送部（Results Sender）ＲＳが呼び出される。そして変更されたデータは結果伝送部ＲＳからＭＳシステムへ伝送される。１つのメモリ領域であるキーリファレンス（Key Reference）ＫＲには、フロントオフィスシステムＭＳのキーＫＭＳとオブジェクトリファレンスＯＲが格納されている。また、１つのメモリ領域である補助データ（Additional MS-Data）ＡＭＤには、ＯＬＴＰ−Ｒ／３システムにより搬送しなければならないがそれ自体にとっては重要ではないデータ（たとえばフロントオフィスシステムのキーなど）が含まれている。ＭＳシステムからはＯＬＴＰ−Ｒ／３システムへは、それに関連しないデータは伝送されない。

コールフレームＣＦおよび結果伝送部ＲＳだけが、ここで述べた機能のために付加的にインプリメントされたＯＬＴＰ−Ｒ／３システムの構成部である。

アップロードは以下のようにして行われる。ＭＳシステムにおいてＢＤｏｃが処理される。この処理のステップとしてＯＬＴＰ−Ｒ／３アダプタが呼び出される。そしてこれは、ＢＤｏｃがＯＬＴＰ−Ｒ／３システムに関連するか否かについて判定する。関連するのであれば、ＢＡＰＩ呼出部ＢＣはそのＢＤｏｃをマークする。これにより保証されるのは、同じキュー内にある別のＢＤｏｃも処理されないようにすることである。ＯＬＴＰ−Ｒ／３システムに関連のないその種のＢＤｏｃも必ずキュー内に存在する。その理由は、キュー内のＢＤｏｃと先行のＢＤｏｃとの依存性が場合によっては存在するからである。ＢＤｏｃの構造は、ＯＬＴＰ−Ｒ／３システムの対応するＢＡＰＩのパラメータ構造にマッピングされる。ついでそのＢＡＰＩのコールフレームがＯＬＴＰ−Ｒ／３システムにおいて呼び出される。

コールフレームの第１の役割は二重の処理を避けることである。ＢＡＰＩに従って新たなオブジェクトを生成しようという場合にコールフレームは、そのオブジェクトがすでに存在していてＭＳシステムの相応の要求に応じて生成されているかのかについてチェックする。そうであればビジネスオブジェクトの新たな生成の代わりにすでに処理されたデータが抽出され、ＭＳシステムへ伝送されて戻される。コールフレームの第２の役割は、ＭＳシステムにおけるキーおよびオブジェクトリファレンスとＯＬＴＰ−Ｒ／３システムのキーおよびオブジェクトリファレンスとの間で必要とされるマッピングを保証することである。さらに第３の役割はコミットサイクルのハンドリングである。これにより、ただ１つのコミットサイクルでＢＡＰＩ処理が実行されるようになる。その結果、バックオフィスシステムＯＬＴＰ−Ｒ／３へのデータの格納ならびにフロントオフィスシステムＭＳへのデータの伝送が、１つの共通の処理単位で行われるようになる。

コールフレームＣＦのメイン機能は、スタンダードＢＡＰＩ ＳＢを呼び出すことである。このためコールフレームは、それが受け取ったＢＤｏｃの構造を汎用的なＢＡＰＩの構造に置き換えるために必要とされるすべての情報を有している。ＢＡＰＩはＢＤｏｃのデータを処理し、アップデートファンクションモジュールＵＦＭに対する呼び出しを有している。このファンクションモジュールは、コールフレームがコミット命令をスタンダードＢＡＰＩへ出したときに稼働し始める。アップデートファンクションモジュールはデータベースにおけるデータの変更を持続的なものにする。さらにこのモジュールはイベントを発し、そのイベントはイベントディストリビュータＥＤのサブスクライバへ分配される。これらのサブスクライバの１つは結果伝送部ＲＳである。これは変更されたデータを発せられたイベントのパラメータとして受け取り、それを結果データＡＭＤと混合してそれをＭＳシステムへ伝送する。

ＭＳシステムにおいて、結果セーブエージェントＲＳＡは受け取った結果をＢＤｏｃ構造へマッピングして戻す。マージエージェントＭＥＡは、ＯＬＴＰ−Ｒ／３システムから到来した結果をＭＳシステムにおけるＢＤｏｃと混合する。その後、結果セーブエージェントＲＳＡはＢＤｏｃのためのフローコントロールを開始し、ＢＤｏｃのステータスを変えて "OLTP Complete" とする。

ＢＤｏｃを処理するためのフローコントロールについては、図３に基づく前述の説明を補足的に参照されたい。

デルタダウンロード（じかにＯＬＴＰ−Ｒ／３システムに入力されその後ＭＳシステムへ転送されたデータの伝送）は、アップロードと非常に似ている。図６には、デルタダウンロードに基づき生じたＢＤｏｃの処理における完全なフローコントロールが示されている。このアーキテクチャは図５に対応している。

ダイアローグプログラムＤＰを介してＯＬＴＰ−Ｒ／３システムとオンラインで通信する内勤従業員ＩＨＥによって、ビジネスオブジェクトが生成される。ダイアローグプログラムＤＰはアップデートファンクションモジュールＵＦＭを呼び出し、稼働し始める。アップデートモジュールはイベントを発し、結果伝送部ＲＳはＭＳシステムにおける結果セーブエージェントを呼び出す。アップロードプロセスとは異なり、結果伝送部ＲＳがＭＳシステムへ伝送しなければならないような付加的なＭＳデータは存在しない。たとえば新たに生成されたオブジェクトのためのＭＳキーなどのように欠けているＭＳデータはキージェネレータＫＧによって生成され、キージェネレータ自体は結果セーブエージェントＲＳＡによってトリガされる。ＯＬＴＰ−Ｒ／３システムから受け取ったデータに対し新たなＢＤｏｃが生成され、図６に示されているように相応のコントロールフローを実行するためフローコントロールがスタートする。

生産的オペレーションの開始前にＭＳシステムのデータベースＣＤを満たすために、初回のデータダウンロード（Initial Download）が必要とされる。ダウンロードすべきビジネスオブジェクトクラスは、カスタマ固有のシステム整合中に決定される。しかもビジネスオブジェクトのインスタンスを、特定の属性値に依存してフィルタリングすることができる。ついで、固有の出口（カスタマイクジット Customer Exit）を利用することができる。

図７には、初回データダウンロードのために用いられるコンポーネントが示されている。初回データダウンロードドリガエージェント（Initial Download Trigger Agent）ＩＤＴＡはプロダクションフェーズ開始前、初回データダウンロードを導入するためシステムアドミニストレータによって始められる。初回データダウンロードトリガエージェントは、ＯＬＴＰダウンロードトリガエージェント（OLTP Download Trigger Agent）ＯＤＴＡを呼び出す。トリガはｑＲＦＣによって引き起こされる。これにより、初回データダウンロードアクションが正確に１度実行されるようになる。ＯＬＴＰダウンロードトリガエージェントＯＤＴＡは、選択されたビジネスオブジェクトクラスに対し抽出部マスタＥＭを呼び出し、さらにこの抽出部マスタ自身はＲ／３抽出部ＥＸＴを呼び出す。抽出部マスタＥＭと抽出部ＥＸＴの相違点は、抽出部マスタはＭＳシステムとの共働に固有に適合されたコンポーネントであるのに対し、抽出部ＥＸＴはＯＬＴＰ−Ｒ／３システム内の他の関連においても使用される。

抽出部マスタによって引き継がれたフィルタ基準に基づき、抽出部ＥＸＴはＯＬＴＰデータベースＯＬＴＰ−ＤＢからオブジェクトデータを選び出す。さらに抽出部マスタは処理すべきテーブルに関する情報も供給し、必ずしも完全なオブジェクトを抽出しなくてもよいようにする。個々の抽出部マスタは選択されたオブジェクトを結果伝送部ＲＳへ伝送する。既述のように、固有の出口を用いて結果伝送部において付加的なフィルタリングを実行することができる。

結果伝送部ＲＳは、ビジネスオブジェクトデータをＢＡＰＩ結果セーブエージェントＲＳＡへ伝送する。そしてこのエージェントはマッピング用エージェントＭＡ、キー生成用エージェントＫＧならびに統合データベース用バルクストレージエージェント（Bulk CDB Agent）ＢＣＡを呼び出す。マッピングエージェントは、ＯＬＴＰ−Ｒ／３システムの構造をＭＳシステムの構造に変換する。キージェネレータは、ＯＬＴＰ−Ｒ／３キーだけをもつオブジェクトのためのＭＳキーを生成する。バルクストレージエージェントＢＣＡは、ビジネスオブジェクトのデータを統合データベースＤＢへ書き込む。バルクストレージエージェントＢＣＡとＭＳシステムのデータベースサービスＣＤＳとの相違点は、ＢＣＡは複数のオブジェクトを同時に処理できるのに対し、ＣＤＳはそれぞれただ１つのビジネスオブジェクトのデータだけしか処理できないことである。

良好なパフォーマンスを保証するため、複数のビジネスオブジェクトクラスが同時にダウンロードされる。とはいえこれは、互いに無関係なオブジェクトクラスについてのみ行われる。あるオブジェクトが他のオブジェクトに依存しているかぎりは（たとえば「カスタマ｝の「オーダ」など）、それらは適切な順序で相前後してダウンロードされる。この場合、望ましい順序におく目的で、各オブジェクトはインスタンスのレベルではなくクラスのレベルでダウンロードされる。

抽出部はＯＬＴＰ−Ｒ／３データベースからデータを抽出する。既述のように、それらは他のアプリケーション領域（たとえば外部のアプリケーションＢＷ）のためにも用いられる。

抽出部の利用は２つのステップを有している。第１のステップにおいてフィルタ基準が抽出部へ渡される。これはフィルタ基準に対応するすべてのビジネスオブジェクトのキーを決定する。さらに第２のステップにおいて、本来の情報を読み出すためキーリストを用いて抽出部マスタＥＭが呼び出される。そして抽出部マスタは抽出部を用いて、別の処理のためにＢＤｏｃとして必要とされる順序で呼び出しに固有のデータをテーブルからフェッチする。

ブロックサイズによって、１つのパスにおいて処理されるビジネスオブジェクトの個数が決定される。抽出部はシリアルに動作可能であり、つまり１つのパスを他のパスの次に処理することができる。パラレルの動作モードもオブジェクトごとのベースで可能である。

ＯＬＴＰ−Ｒ／３システムの構造は、マッピングによりＭＳシステムの構造に移される。マッピングはフィールドごとに実行される。この場合、複数のフィールドを１つのフィールドに連結したり、あるいは１つのフィールドを複数の部分に分けることができる。また、フィールドタイプがコンバートされる。さらにソースフィールドから依存する情報が生成される。

キージェネレータＫＧは、ＯＬＴＰ−Ｒ／３キーに対しそれぞれＣＲＭ−ＭＳキーを見つけるために用いられる。この場合、それぞれ１つのキージェネレータはＢＤｏｃのタイプについて固有に、レポジトリ情報を利用して生成される。キージェネレータエージェントを最新の状態に保持する目的で、キージェネレータを生成するためのジェネレータがレポジトリのジェネレータエージェントにおいて１つのサブスクライバとして登録される。そしてこれは、対応するレポジトリの情報が変化したときに呼び出される。

キージェネレータはＢＤｏｃを受け取り、存在するすべてのＯＬＴＰ−Ｒ／３キーに対しＣＲＭ−ＭＳキーをここではＧＵＩＤ（globally unique identifier）のかたちで使用する。必要とされるＭＳキーは種々の場所で探され、つまりまずはじめにキージェネレータのローカルテーブルにおいて探され、ついでキーマッピングテーブルによって、最後に統合データベースＣＤにおいて探される。ＭＳキーがみつからなければ新たなキーが生成され、種々のマッピングテーブルに挿入される。

データがまだ統合データベースＣＤに格納されていない状況でキーが二重に生成されるのを避けるため、付加的なキーマッピングテーブルが必要とされる。キージェネレータのローカルテーブルはオプションであり、パフォーマンス向上のためキャッシュとして用いられるだけである。

ＯＬＴＰ−Ｒ／３データベースＯＬＴＰ−ＤＢとＭＳシステムの統合データベースＣＤとの同期合わせのために２つのコンポーネントが設けられており、すなわち「リクエスト」と「コンペア」とが設けられている。リクエストコンポーネントは、初回データダウンロード用のコンポーネントと非常に似ている。これによって、所期のように特定のビジネスオブジェクトをＯＬＴＰ−Ｒ／３データベースＯＬＴＰ−ＤＢから統合データベースＣＤへダウンロードすることができ、つまりはポータブルコンピュータＭＣのデータのレプリケーションを（フローコントロールＦＣの制御のもとで）実行することができる。リクエストによって指定されたフィルタ基準は初回データダウンロードの一般的なフィルタ基準と混合され、その結果、初回データダウンロード中に処理されたデータの１つのサブセットだけを選択できるようになる。このリクエストコンポーネントをインタラクティブにスタートさせることもできるし、バッチモードでスタートさせることもできる。

コンペアコンポーネントはＯＬＴＰ−Ｒ／３システムからビジネスデータをダウンロードする。比較アクションの結果として得られる相違点によって、統合データベースＣＤにおいて行う必要のある変更が表され、これはその内容をＯＬＴＰ−Ｒ／３データベースＯＬＴＰ−ＤＢの内容と一致させることを目的としている。その際、変更情報（「インサート」、「アップデート」、「デリート」）はＢＤｏｃ構造内に格納される。本来の比較アクション後に統合データベースＤＢに対しその変更が適用され、それによってその変更をＯＬＴＰ−ＤＢと一致させるようにする。そして変更情報からＢＤｏｃが生成され、ローカルデータベースＬＤのレプリケーションのため（フローコントロールにより制御されて）モバイルクライントＭＣが用いられる。

次に、本発明にとって重要な機能について補足的に説明する。
１．クロスシステムプライマリキー（cross-system primary key）の供給
上述のように、オフライン分散されたデータベースシステムのセマンティクスインテグレーションにとって重要であるのは、システムを超えてクロスシステムもしくはシステムワイドでプライマリキーを供給することであり、これによってデータオブジェクトの一義的な識別を相互に融合するデータベースシステムの境界を超えて実現することができる。

図８には、（上述の説明を補足するかたちで）これに適した手順の基本原理が描かれている。キージェネレータＫＧは、ここでは一般的にＡもしくはＢの付されたデータベースシステム（ソースシステム）において捕捉されたデータを受け取る。これにはシステム固有の個々のプライマリキーＫＡもしくはＫＢが属している。（ターゲットとなるシステムにおける）それぞれ他のプライマリキーについては、データセットにおいて空のフィールドが設けられている。キージェネレータはキーマッピングテーブル（Key Mapping Table）ＫＭＴの内容を読み出し、システムＡまたはＢの一方から供給されるデータセットのキーフィールドと比較する。ソースシステム（たとえばＫＡ）のプライマリキーがキーマッピングテーブルＫＭＴ内にすでに存在しているならば、供給されたデータセットは既存のエントリの変更（アップデート Update）に該当する。この場合、ターゲットとなるシステム（たとえばＫＢ）における対応のプライマリキーがキーマッピングテーブルＫＭＴから読み出され、データセットの空のフィールドにエントリされる。

これに対し供給されたプライマリキーがキーマッピングテーブルＫＭＴ内にみつからなければ、それはデータセットの新たな生成（インサート Insert）である。この場合、欠けているプライマリキー（たとえばＫＢ）がキー生成モジュール（Key Generate Module）ＫＧＭによって生成されてキーマッピングテーブルＫＭＴに書き込まれ、さらにそのキーは空のデータフィールドにエントリされる。その後、データセットはターゲットとなるシステムにおいても一義的に識別可能であり、ソースシステムのキーとターゲットシステムのキーは互いに一義的に対応づけられる。

次に、上述のＢＤｏｃのように実際のインプリメントにおいて階層的に分けられたデータセグメントの複雑な構造をもつデータオブジェクトを有するデータベースシステムにおいてこの原理を実施するための実際のやり方について説明する。

図９には、２つのセグメントＳ１およびＳ２から成る非常に簡単な構造が描かれている。セグメントＳ１は階層的にいえばセグメントＳ２の一段上に配置されており、したがって子セグメントＳ２に対する親セグメントと呼ばれる。親セグメントは図示の事例ではＢＤｏｃのルートセグメントである。

親セグメントＳ１は、ＭＳシステムのプライマリキーＫＭＳとＯＬＴＰ−Ｒ／３システムのプライマリキーＫＲ／３を有している。これらのキーの各々は、１つまたは複数のセグメントフィールド内に格納されている。

子セグメントも、（１つのフィールドに格納されている）ＭＳシステムのプライマリキーＫＭＳと（３つのフィールドに格納されている）ＯＬＴＰ−Ｒ／３システムのキーＫＲ／３を有している。さらに子セグメントのフィールドには上位の親セグメントのキーも含まれており、このことは両方のセグメント間の矢印によって表されている。とはいえそれらのフィールドはキーのファンクションをもっているのではなく、セグメント構造に関する情報に対するいわゆる外部キー（foreign key）として用いられる。つまりそれらは、Ｓ２はセグメントＳ１の子であることを表している。

図９の右側には対応するキーマッピングテーブルが描かれており、この場合、矢印で表されている行にはセグメントＳ１とＳ２の各キーが書き込まれている。

図１０にはいくらか複雑なフィールド構造が示されており、これには親セグメントＳ１（ＢＤｏｃのルートセグメント）、階層的にいえば下位に位置する子ジェネレーションの２つのセグメントＳ２ａおよびＳ２ｂ、さらにはセグメントＳ２ａの子である孫ジェネレーションのセグメントＳ３が設けられている。たとえばセグメントＳ１には「カスタマ」タイプのＢＤｏｃのためにカスタマの名前と住所をもたせることができ、セグメントＳ２ａにはそのカスタマの担当員を、また、フィールドＳ３にはその担当員の渉外情報（電話番号、サービス時間など）を、さらにフィールドＳ２ｂにはそのカスタマの装備しているマシンに関する情報を含めることができる。

この場合も各セグメントには（図示の実施例ではみやすくするためそれぞれ１つのフィールドのみにおいて）両方のデータベースシステムのキーＫＭＳおよびＫＲ／３を有しており、この場合、依存するシステムはそれぞれ親ジェネレーションのキーを外部キーとして有している。図１０の右側に描かれているキーマッピングテーブルは、やはり両方のシステムの対応を示している。

実際には大規模なデータベースシステムのデータオブジェクトは、互いにインタリーブされた多数の階層平面をもつ非常に複雑なデータ構造を有している可能性があり、その際、セグメントはしばしばきわめて多くの個数のデータレコードを有している。これに加えて、特別な要求を考慮するため特殊な構造エレメントの必要とされることも多い。たとえば個々のデータレコードのデータに対し、それらが下方の階層平面にあるにもかかわらず、迅速にアクセスできるようにすることの要求されることが多い。このような状況において好適であるのは、階層的に深いセグメントにおいて必要とされるキーを比較的高い階層のセグメントにおける特別なフィールドに格納することである。たとえば図１０に描かれているように、第２のセグメントＳ２ａの第１のデータレコードのコードＣ１Ｍを有するキーがセグメントＳ１の特別フィールドＳＦ内にエントリされており、その目的はたとえばＳ１にコーディングされているカスタマの最も重要な担当員に対するダイレクトなアクセスを可能にすることである。このような構造上の特殊性によって、上述の方法の実施は実際にはとても困難になる。

このような問題点を以下で説明するアルゴリズムによって解決することができる。このアルゴリズムは２つのプログラム部分から成り、それらをＰＡＳＳ−ＩおよびＰＳＳ−ＩＩと称する。

ＰＡＳＳ−Ｉ：
すべての（定義済み）セグメントに対し｛
すべてのデータセットに対し｛
／／ＫＭＳを満たす／／
（ＫＭＳ＝ＬＥＥＲ）であれば｛
ＫＭＴにおいて探索（ＫＲ／３）
エントリが存在しているならば｛
ＫＭＳをＫＭＴから取り出す
ＫＭＳをＢＤｏｃへ入力
｝そうでなければ｛
新たなＫＭＳを生成
ＫＲ／３，ＫＭＳをＫＭＴへエントリ
ＫＭＳをＢＤｏｃへエントリ
｝
｝
／／ＭＳ親キーを満たす／／
（ＭＳ親キー＝ＬＥＥＲ）であれば｛
ＢＤｏｃ親セグメントにポジショニング（Ｒ／３親キー）
ＭＳ親キーをＢＤｏｃ親セグメントから取り出す
ＭＳ親キーをＢＤｏｃへエントリ
｝
｝
｝
ＰＡＳＳ−Ｉにおいて、すべての定義済みセグメントに対し（つまりキー生成の必要とされるすべてのセグメントに対し）、およびすべてのデータセットに対し、コメント「ＫＭＳを満たす」の付けられたアルゴリズムセクションが実行される。このアルゴリズムセクションではまずはじめに、プライマリキーのフィールドが空であるか否かの問い合わせが行われる。空であるならば、存在するキーＫＲ／３のもとでキーマッピングテーブルにおいて、エントリが存在するか否かが探索される。場合によっては、対応するＭＳプライマリキーがキーマッピングテーブルから取り出され、ＢＤｏｃへエントリされる。

探索されたＫＭＳのエントリが存在しなければ、ＧＵＩＤが新たなＭＳプライマリキーとして生成され、ＫＲ／３もＫＭＳもキーマッピングテーブルにエントリされる。さらにＢＤｏｃへのＫＭＳのエントリが行われる。

ついで、コメント「ＭＳ親キーを満たす」の付されたアルゴリズムセクションが実行される。ＭＳ親キーのためのフィールドが空であれば、読み出しポジションがＢＤｏｃ内の親セグメントにおかれ、しかもこれは対応するＫＲ／３を含むデータレコードにおかれる。その後、対応するＫＭＳが親セグメントから取り出され、子セグメントの外部キーフィールドにエントリされる。

ＰＡＳＳ−Ｉは、階層によりまえもって定められた順序で（最も高い階層平面から始めて）ＢＤｏｃのすべてのセグメントが処理されてしまうまで何度も実行される。

その後、ＰＡＳＳ−ＩＩがスタートする。これはＦＥＴＣＨテーブルと称するレポジトリに格納されたテーブルによって制御される。このテーブルには、ＰＡＳＳ−Ｉでは不可能である充填アクション（フィルアクション）が記述されている。これには、（図１０に描かれているように）階層的に低い方のセグメントからの値の充填と、親平面よりも高い階層平面（つまりたとえば２つの平面だけ高い平面すなわち親の親の平面）からのキーの充填が属している。

これらの機能を果たせるようにするため、ＦＥＴＣＨテーブルは以下の構造を有している。
・ＤｅｓｔＴｂｌ：ターゲットテーブル
・ＤｅｓｔＦｌｄ：ターゲットフィールド
・ＳｒｃＴｂｌ： ソーステーブル
・ＳｒｃＦｌｄ： ソースフィールド
・Ｃｏｎｄ： ＫＲ／３またはサンプルｘ＝ｙによる条件
ＦＥＴＣＨテーブルにおけるエントリにより、ソーステーブルのソースフィールドからターゲットテーブルと称するＢＤｏｃのセグメントへの充填アクションが発生する。

ＰＡＳＳ−ＩＩのアルゴリズムは以下の通りである：
すべての定義済みセグメントについて｛
ＤｅｓｔＴｂｌ＝ＳｅｇｍｅｎｔであるＦＥＴＣＨテーブル内のすべてのテーブルについて｛
ＦＥＴＣＨテーブルから値を読み込む
（Ｃｏｎｄ＝Ｒ／３）であれば｛
／／ＢＤｏｃ内の値
ＳｒｃＴｂｌにおけるＢＤｏｃにポジショニング（ＫＲ／３）
ＳｒｃＴｂｌ−＞ＳｒｃＦｌｄをＤｅｓｔＴｂｌ−＞ＤｅｓｔＦｌｄに書き込み
｝そうでなければ｛
／／ＣＤからの値
フィルタ＝ＣｏｎｄでＳｒｃＴｂｌにおけるＣＤにポジショニング
ＣＤＳｒｃＴｂｌ−＞ＳｒｃＦｌｄをＤｅｓｔＴｂｌ−＞ＤｅｓｔＦｌｄに書き込み
｝
｝
｝
処理されるＢＤｏｃのすべてのセグメントについて、およびセグメントがＤｅｓｔＴｂｌとしてエントリされているＦＥＴＣＨテーブル内のすべてのエントリについて、ＦＥＴＣＨテーブルから値が読み出される。その後、条件判定が行われる。Ｃｏｎｄ＝Ｒ／３とセットされていれば、それはＢＤｏｃ内のキー値の伝送のことであり、この場合、ソースセグメントにおけるソースフィールドの内容がターゲットセグメント内のターゲットフィールドへ伝送される。条件Ｃｏｎｄが別の値を有しているならば、ＢＤｏｃ自体からまたは統合データベースＣＤから値が引き継がれ、後者の場合、データベースＣＤ内のソーステーブルへのアクセスが行われ、その内容がターゲットセグメントのターゲットフィールドへ伝送される。
２．データマージ
種々のデータベースシステムの融合におけるさらに別の基礎的な問題点は、２つのシステムにおいて所定のタイプのデータオブジェクトに対して存在するデータがそれぞれ異なることである。たとえばＣＲＭシステムにおけるデータオブジェクト「カスタマ」には、個々のカスタマ担当員または準備されている販売交渉（opportunities）に関する情報の含まれている可能性があり、これをＥＲＰシステムは必要としない。これに対し、ＥＲＰシステムにおけるデータオブジェクト「カスタマ」は、たとえば取引関係開始以来のカスタマのすべての勘定のような情報を有しており、これをＣＲＭシステムは必要とせず、したがってそこで処理されるデータオブジェクトについてセグメントは設けられていない。

プライマリキーに関してはさきに説明したロジックが有利であり、それによればシステムの一方においてつまりフロントオフィスシステムＭＳにおいて、互いに融合されるシステムの両方のキーＫＭＳおよびＫＲ／３がホールドされるのに対し、バックオフィスシステムにはそのキーＫＲ／３だけがホールドされる。

このような状況においてできるかぎり完全なデータ交換を実現するために有利であるのは「データマージ手順（data merge procedure）」を使用することであり、次にこれについて以下の取り決めを用いながら図５および図１１に基づき説明する：
ＤＭＳ： ＭＳシステム内にしか存在していないデータ
ＤＲ／３： ＯＬＴＰ−Ｒ／３システム内にしか存在していないデータ
ＤＭｉｘ： 両方のシステムに存在しているデータ
図１１に示されているように、ＭＳシステムからのデータがシステム固有のデータオブジェクト（ＢＤｏｃ）としてＯＬＴＰ−Ｒ／３システムへ伝送するために用意される場合、それにはＤＭＳ，ＤＲ／３，ＤＭｉｘがキーとして含まれる。ＯＬＴＰアダプタＯＬＴＰ−ＡＤにおいて、データＤＭＳがＢＡＰＩ呼出部ＢＣから分配されてそこに保管される。その後、ＯＬＴＰアダプタは残りの情報ＤＭｉｘおよびＫＭＳをＯＬＴＰ−Ｒ／３システムへ伝送する。ソースシステムＫＭＳのキーはターゲットシステムＯＬＴＰ−Ｒ／３システムにおいて分離され、補助データＡＭＤというメモリ領域に保管される。

ついでＤＭｉｘデータは補助データＤＤによって補われる。これはターゲットシステム（ＯＬＴＰ−Ｒ／３システム）において生成されたデータオブジェクトを処理するために必要とされる。それらの補助データは通例、対応するデータフィールドのためのプリセット値（デフォルト値）である。

その後、ＯＬＴＰ−Ｒ／３システムにおいて通常の処理が実行される。データはターゲットシステムにおいて一般に行われているロギングルーチンを用いることで非同期にチェックされ、データベースＯＬＴＰ−ＤＢに格納される。

ロギングと関連して１つのイベントがトリガされ、このイベントはイベントディストリビュータＥＤによって殊に結果伝送部ＲＳへ伝達され、結果伝送部はこれに応じてデータをロギングから受け取る。得られたデータパケットはＤＲ／３，ＤＭｉｘおよびＫＲ／３から成る。結果伝送部ＲＳは保管されていたＭＳキーＫＭＳを挿入し、ＭＳシステムに関係しないデータＤＲ／３を取り除く。その後、データパケットＤＭｉｘ，ＫＭＳおよびＫＲ／３としてＭＳシステムへの伝送が行われる。ＭＳシステム内において、保管されていたデータＤＭＳが結果セーブエージェントＲＳＡにより再び付け加えられ、その結果、データＤＭＳ，ＤＭｉｘ，ＫＭＳおよびＫＲ／３を有する完全なＢＤｏｃが後続処理（たとえばデータベースＣＤにおける統合化およびそれに続くモバイルクライントＭＣへのレプリケーション）のために得られる。

このようなデータマージ手順は、ＭＳシステムからＯＬＴＰ−Ｒ／３システムへのデータのアップデートごとに行われる。ＯＬＴＰ−Ｒ／３システムにおけるデータ変更（デルタダウンロード）にあたりこの手順の一部分がロギングルーチンからスタートして実行されるが、その際には当然ながらＭＳキーＫＭＳを加えることはできない。これはその場合には上述のようにしてキージェネレータＫＧによって生成される。
３．ダウンロード
データベースシステムの融合における基本的な目標は、各システムにおいて共通に利用されるデータを別個にメンテナンスしなくても済むようにし、互いに融合されたデータベースシステム中に存在するデータを共通に利用できるようにすることである。たとえばＣＲＭフロントオフィスシステムは、企業のＥＲＰバックオフィスシステム内に格納されているカスタマ情報および製品情報に関するデータをアクセスすることができるようにしなければならない。
４．初回データダウンロード
このためまずはじめに以下の役割が課される。すなわち、既存の第１のデータベース（ソースシステムＡここではＯＬＴＰ−Ｒ／３システム）におけるデータであって、インプリメントされている別のデータベースシステム（ターゲットシステムＢここではＭＳシステム）によっても必要とされるデータが、初回データダウンロード（Initial Download）にあたりシステムＡからシステムＢへ伝送する。この関連で本発明によれば以下のような問題解決手段が提案される。

既存のバックオフィスシステム（以下ではこのことをＯＬＴＰ−Ｒ／３システムと称するがこれによっても汎用性が制約されるものではない）におけるデータ量は通例、非常に多い。したがって、他のシステムと交換すべきデータを詳しく指定する手段を提供しなければならない。本発明においてはこのことは有利にはフィルタリングによって行われる。

このようなフィルタリングのために図７を参照しながら説明した抽出部が用いられ、これはＯＬＴＰ−Ｒ／３システムによって提供される。この場合の特殊性は、抽出部マスタのかたちでＭＳシステムに対する標準化されたインタフェースが適用され、このインタフェースを介してＭＳシステムにおけるすべての問い合わせが行われることである。つまり、ターゲットデータシステムＭＳが標準化されたインタフェースを介してそのシステムが必要とするデータに対する要求を、ソースシステムＯＬＴＰ−Ｒ／３にインプリメントされている抽出部へ伝送することによって、データがフィルタリングされる。

さらに別の問題点は、初回データダウンロードをリーズナブルな時点で行えるようにすることである。このことは、一般にバックオフィスシステムに設けられている手段によって実現できない。なぜならばそのような手段は非常に大きいデータ量を迅速に伝送するようには構成されていないからである。本発明によればこの問題点は有利には、先に詳しく説明したバルク指向ＢＤｏｃと呼ばれる特別なデータコンテナを提供することによって解決される。

さらに初回データダウンロードにおける問題点は、ターゲットデータベースシステムに伝送されるデータがソースデータベースシステムのきちんと定められた状態と規定の時点（スナップショット snapshot）で一致するよう保証することである。従来ではこの問題点は、初回データダウンロード中はソースデータベースシステムを変更に対しブロックすることで解決されており、あるいは変更が許可されているのであるならば、ソースデータベースの特別な手段を利用することで解決しているが、そのような手段によってデータベースに対し初回データダウンロードの独立したオペレーションが妨げられる。

このような部分的な問題点を解決するため、本発明によれば以下でオンライン同期手順（online sync procedure）と呼ぶ方法が提案され、これについて図１２を参照して説明する。この場合、ソースシステムＯＬＴＰ−Ｒ／３にインプリメントされている抽出部は、ターゲットシステムＭＳ内に格納されているフィルタ定義ＦＤにより制御され抽出部マスタインタフェースＥＭを介して呼び出されるのであるが、この抽出部は通常はブロックで読み出され送出されるかたちで動作し、その際にこれはソースデータベースのダイナミックなデータ変更を無視する。このため、ターゲットシステムにより必要とされるデータバルクは矢印ＩＬ（Initial Load）の付された経路で伝送される。

しかしこれと並行して、結果伝送部ＲＳによる既述のデルタハンドリングも実行される。これにより、ソースシステム内で初回データダウンロード中に生じた変更がキューに格納される。通常のデルタダウンロード動作とは異なりこのキューはアンロックされるのではなく、初回データダウンロード期間中はロックされる（Queue-Stop QS）。初回データダウンロード終了後に変更キューがアンロックされ、初回データダウンロード中に実行された変更が矢印ＤＬ（Deltaload）によってシンボリックに表されたデルタダウンロードチャネルを介してターゲットシステムＭＳへ伝送される。このようにして、初回データダウンロード終了時点に関して一致した「スナップショット」が生じる。
ｂ）デルタダウンロード
デルタダウンロードの機能についても、上述の（殊に図５に基づく）説明ならびにデータマージ手順についてなされた説明が関連する。ここでの目的は、初回データダウンロード後に動作実行中、ソースデータベースシステムＡとつながっているすべてのシステムに対しそれぞれ変更を加えることである。

この機能は２つのサブステップで提供される：
ａ）実施された変更についてソースデータベースシステムに通知
ｂ）変更およびその処理ならびに後続処理のためそれに続いてターゲットデータベースシステムへ転送
通例、実施された変更について通知するために変更ポインタが用いられるけれども、これは著しい欠点をもっている。まず第１に、起こり得る変更ごとにソースデータベースシステムのアプリケーションに変更ポインタを設けなければならない。これはたいていすべてのデータオブジェクトについて不可能なことであるが、少なくとも非常に手間がかかるしクリティカルなエラーの原因となる。他方、変更の通知はまえもって定められたタイムインターバルでしか行われない。

このような部分的な問題点を解決するため、本発明によれば有利にはイベント技術が利用される。ソースデータベースシステムにおけるデータベースＯＬＴＰ−ＤＢへ変更を加えるルーチンに、イベント発生が組み込まれる。イベントディストリビュータＥＤを介して、イベントに対する予約を扱うファンクションモジュールがイベント発生時に呼び出される。このファンクションモジュールには、ターゲットデータベースシステムの相応のモジュール（図５では結果セーブエージェントＲＳＡのコンポーネント）が属している。このようにしてＭＳシステムにおけるＯＬＴＰ−Ｒ／３アダプタ（つまり一般的にいえばターゲットシステムのモジュール）は、ターゲットシステムに関連するソースデータベースシステム内の変更に関する情報をほぼ同時に受け取る。

これに続いて行われるソースデータベースシステムからターゲットデータベースシステムへの変更の伝送は、ターゲットデータベースシステム内に格納されている既述のフィルタ基準ＦＤ（図１２）に基づき実施される。その後、上述のデータマージ手順を用いてデータが処理され、やはりすでに説明したやり方でシステムを超えたクロスシステムプライマリキー（cross-system primary key）が生成される。

データ伝送のその他の特殊性として挙げられるのは、（殊にデルタダウンロードにあたり）以下で説明するネットフィールド決定（net-field determination）が用いられることである。

互いに無関係に同じデータセットにアクセスする多数のユーザによって実施される変更が相互に書き換えられるのを最小限に抑えるために有利であるのは、個々のデータセットにおいて変更されたフィールドだけを伝送することである。このことをネットフィールド伝送（net-field transmission）と称する。しかしながら、たとえばＯＬＴＰ−Ｒ／３システムなどのようなＥＲＰバックオフィスシステムは一般に「すべて込みのフィールドないしはオールフィールド（all-field）」ベースでしか通信できず、つまりこのシステムはフィールド内容全体を伴ってデータセット全体を一度に伝送するだけである。したがってデータはデータチャネルＤＬ（図１２）を介してオールフィールドベースでターゲットシステムＭＳに転送され、これはそのような転送が結果伝送部ＲＳによってトリがされたときに行われる。この欠点は本発明の有利な実施形態によれば次のようにして解消される。すなわち、ターゲットシステムつまり統合データベースＣＤのデータベースサービスＣＤＳにおいて、フィールド平面における有効な変更が統合データベースＣＤの内容との比較により求められ、実際の変更だけがネットフィールドベースで後続処理に関与させるのである。

詳しくはこれがどのように行われるかについて、次に図１３および図１４を参照しながら説明する。

ネットフィールド伝送を支援するため、ＢＤｏｃ（すなわちターゲットデータベースシステムのデータオブジェクト）のすべてのセグメント、変更されたフィールドを反映するフィールドが挿入される。このフィールドを送信ビットフィールド send-bit field SBF と称する。これはたとえばＲＡＷ（３２）タイプのものとすることができ、バイナリ表示で（好適にはＨＥＸで格納されるかたちで）変更を受けたフィールドに対応する各ポジションにおいて「１」を有している。図１３には、送信ビット情報ＳＢＦとフィールド情報ＦＩＮとの対応関係が描かれている。この場合、消去も変更として表される。図示の事例ではたとえばフィールド１およびフィールド４のフィールド内容が（「Ａ」と「Ｃ」に）変更されており、フィールド２およびフィールド８のフィールド内容が消去されている。付加的なフィールドＳＢＦのフィールド内容は、フィールドの個数に対応するビット数をもつ関連部分Ｒと無視される非関連部分Ｌによって構成されている。

データセットがオールフィールドベースでターゲットデータベースシステムへ転送される場合、ターゲットデータベースシステムＭＳのデータベースとの調整が行われる。この調整はデータベースＣＤのデータベースサービスＣＤＳにおいて実行され、これについては図１４に描かれている。この場合、データセットＤ１は、変更されたフィールド内容「Ｘ」をもちオールフィールドベースで伝送されるデータセットの実施例である。データベースサービスＣＤＳはそのデータセットを、データベースＣＤ内に格納されている対応するデータセットＤ１′と比較し、内容「Ｘ」をもつフィールドだけが変更されていることを確認する。これに従い、変更された情報だけをもつデータセットＤ２が生成される。対応する送信ビットは「１」にセットされている。残りのフィールド内容は空にされている。
ｃ）同期合わせ
冒頭で説明したコンテキストにおけるセマンティックな統合とは、システム間の単純なデータ交換以上のことを意味している。可能性に応じてアプリケーションの動作を、有効データの処理の基礎を成すロジック（ビジネスロジック "business logic"）に近づけるようにする。ビジネスロジックは、個々のデータベースシステムのレポジトリに格納されている制御データに高度に反映されており、それらはたとえば値の範囲、フィールドやレコードやデータベースの妥当性などのようなロジックをマッピングする。このためセマンティックな統合においては、レポジトリ制御情報もクロスシステムでレプリケーションされるようにする。ＯＬＴＰ−Ｒ／３システムの事例では、これはいわゆるカスタマイズテーブル（Ｔテーブル）である。しかしながらカスタマイズテーブルにおける変更は、ＯＬＴＰ−Ｒ／３システムでは変更ポインタによってもイベントによっても指示されない。このため適切な更新メカニズムを利用できなければ、ＭＳシステムなどのターゲットデータベースシステムにおいてこれらのデータのレプリカは急速に古くなってしまう。

このような事例においてもソースシステムとターゲットシステムとの間でデータ状態を絶えず同期合わせできるようにする目的で、すでに挙げたコンポーネント「リクエスト」および「コンペア」が使われる。図１５および図１６には、これによって実現される同期メカニズムが示されている。

リクエストコンポーネントは、すでに説明したように初回データダウンロードと同じように動作する。任意のビジネスオブジェクトをＯＬＴＰ−Ｒ／３システムからＭＳシステムへダウンロードするために、汎用抽出部 general extractor ＧＥと呼ばれるモジュールが用いられ、これはフィルタ定義ＦＤに従い抽出部マスタＥＭによって呼び出される。

このようにしてダウンロードされたデータが統合データベースＣＤへ取り込まれる前に、図１５においてＣＯＭＰの付されたコンペアモジュールが呼び出される。このコンペアモジュールはダウンロードされたデータをすでにデータベースＣＤ内に存在しているデータと比較し、実際に変更されたデータだけを通過させる。さらにこのモジュールは、もはやオリジナル中には存在していないデータに対する消去指示も発する。

図１６にはこのために使用されるアルゴリズムが示されている。準備過程においてまずはじめにＯＬＴＰ−Ｒ／３システムから受け取ったデータおよびこれに対してそれぞれ対応するデータベースＣＤからのテーブルが、それぞれメモリロケーションＳ２もしくはＳ２に用意される。データベースＣＤから対応するテーブルを選択する際、ＭＳシステム内にしか含まれていないすべてのレコード（図１６ではレコードレコードｍ１，ｍ２）は選択されないよう、データがフィルタリングされる。その他のレコードにもＭＳ固有のデータを有するフィールドが含まれている。データ伝送時のさらに別の制限によって、メモリ領域Ｓ１にはＯＬＴＰ−Ｒ／３システムにおいても利用可能なデータだけが供給されるようになる。

ついでメモリ領域Ｓ１とＳ２の内容の比較が行われ、これによればテーブルの一方が基準として選択され、そのテーブルにういて最初から最後まで段階的に進められ、他方のテーブルにおいて対応するエントリが探索される。この場合、パフォーマンスの理由で有利であるのは、エントリの個数の僅かな方のメモリテーブル（図１６ではメモリ領域）を基準として選択することである。比較結果に依存して以下のような相応のアクションが導入される：
新しいエントリの生成： "Ｉ"
ネットフィールドエントリの生成： "Ｕ"
消去指示の生成： "Ｄ"
アルゴリズムは以下のように表すことができる：
Ｓ１内のすべてのエントリについて｛
Ｓ２内で得られるならば｛
該当しない先行のすべてのＳ２エントリについて新たなエントリ（"Ｉ"）を生成
変更であれば
ネットフィールドエントリ（"Ｕ"）を生成
｝そうでなければ
消去指示（"Ｄ"）を生成
｝
４．アップロード
既述のように、データベースシステムのセマンティックな統合の基本的な要素は、データのエントリや変更を１つのデータベース内だけでなく互いに結合された複数のデータベースまたはすべてのデータベースにおいて実行できるようにすることである。したがってたとえば、外勤従業員はカスタマにおいて新たなデータ（たとえば新たなオーダ）を自身のポータブルコンピュータに入力し、そのデータセットにおけるそのような変更をデータベースＯＬＴＰ−ＤＢにおいて持続的なものとすることができるようにすべきである。

モバイルクライアントのレベルにおける変更は、図２を参照しながら説明したトランザクション層によって登録され、その際、このトランザクション層を介してモバイルクライアントはＭＳシステムおよびその固有のローカルデータベースＬＤと通信する。ポータブルコンピュータがミドルウェアサーバＭＳと接続される場合、変更されたデータがＢＤｏｃとして伝達され、バックオフィスシステムＯＬＴＰ−Ｒ／３にも伝送される。このために用いられるコンポーネントは図５を参照しながらすでに説明しており、その際に実行されるデータマージ手順については図１１を参照しながらすでに説明した。

このようなデータアップロードにおける基本的な要求は適切なコンフリクト対策の開発であり、その目的は様々な場所でエントリされたり変更されたりする各データ間のコンフリクトを阻止することである。結合システムにおいてそのつど１つの特定の個所においてのみデータの変更を許可するようにしたいわゆる「データメンテナンス優位（data maintenance ascendencies）」の定義であると、十分な統合を提供することはできない。多くの適用事例において用いられているＬＯＷ（Last One Wins）方式も、ＥＲＰバックオフィスシステムのデータを含むこのような結合システムには適していない。

したがって本発明においては、ＬＳＣ（Leading System Concept）と称する新規のコンフリクト対策が用いられる。ＬＳＣ方式は、各データオブジェクトごとに管理する側のシステム（ＦＳ）を定義する。結合システムにおける他のすべてのシステムは管理される側のシステム（ＧＳ）である。ＧＳの各変更はまずはじめ、ＦＳによって操作しなければならない。通常の操作機能に対する基本的な相違点は、これはアプリケーションの境界を超えたファンクションであり、構造に互換性のない各システム間のコンフリクトを解消するために用いられる。

ＬＳＣ方式のインプリメントのためには、あとで説明する特別な機能が必要とされる。

ここで説明している実施例の場合、ＭＳシステムはすべてのデータオブジェクトついて管理される側のシステムである。管理される側のシステムは、以下の要求を満たすことができなければならない。
−ユーザはデータの表示においていつでもその確認状態（承諾、拒否、未定）を識別できなければならない。
−ユーザは自身の変更したデータを拒否するときに再びもとの値にアクセスできなければならない。
−データオブジェクトは変更が確認されるまでロックされてはならない。つまり同じデータオブジェクトにおいてチェックすべき複数の変更を先行のチェックの終了を待たずとも相次いで続けることができなければならない。
−結合されたシステム全体におけるデータの一致性を保証しなければならない。

これらの要求はとりわけ２つのファンクションモジュールによって満たすことができ、それらをペンディングカウンタ（ＰＣ）およびインボックス（ＩＢ）と称する。

ペンディングカウンタはＣｈａｒ（４）フィールドであり、これはデータ交換に関与するテーブルごとに（つまりＢＤｏｃの各セグメントに）存在する。このフィールドを介して、データの目下の確認状態が定義される。これによってコントロールフラグが形成され、これはデータの確認状態をたとえば画面上に視覚的に表示するためにアプリケーションプログラムによって評価される。

ペンディングカウンタは以下のかたちをとる：
"Ｏ"： ＯＫ
Ｐ＜ｎ＞： ペンディング（＝保留、まだ確認されていない）、ここで＜ｎ＞は基準カウンタとして変更の回数をカウントアップする。
Ｆ＜ｎ＞： データセットはエラー状態にある。

ペンディングカウンタは変更のたびにカウントアップされ、管理する側のシステムによって確認されると再び"０"になるまで再びカウントダウンされる。拒否の場合にもカウントダウンされるが、"Ｐ"ではなく"Ｆ"がセットされる。

システム全体のけるデータの一致性を保証するために必要とされるのは、変更が承認されないときにはもとのデータ状態が管理される側のシステムにおいて再び形成（ロールバック）されるようにすることである。これは有利には、管理する側のシステム（この実施例ではＯＬＴＰ−Ｒ／３システム）が拒否と同時に（上述のように）データオブジェクトに含まれている「先行状態のイメージ（before image）」ＢＩを管理される側のシステムへ送り戻すことによって行われる。このようにしてオリジナル状態を取り戻すことでロールバックを行うことができる。

しかしながらこのようなやり方の欠点は、これにより個々のデータオブジェクトにおけるユーザの変更すべてが上書きされることにある。たとえばこれが１００個以上の項目を含むオーダであって、それが場合によっては比較的僅かな不一致ゆえに拒否された場合には、変更のもととなった誤りのあるデータオブジェクトつまりはそれゆえに承認されなかったデータオブジェクトのデータを再びユーザが利用できるようにしなければならない。これはインボックスによって行われる。この場合、ユーザはエントリを便利なように整合させることができ、再び利用可能にすることができる。

図１７には１つの実施例に基づき、ペンディングカウンタおよびインボックスのファンクションが描かれている。その際、ＬＤの付された行は、ペンディングカウンタＰＣの状態を表すフィールドとプライマリキーフィールドＫと３つのデータフィールドＤをそれぞれ有するローカルデータベースの内容をシンボリックに表している。

第１のステップにおいて、まん中のデータフィールドの内容が変更される。情報をＯＬＴＰ−Ｒ／３システムへ伝達するＢＤｏｃには、変更された情報「２」しか含まれていない。

次のステップにおいて２つのデータフィールドが変更される。変更された情報「Ｂ」と「３」も同様にＢＤｏｃとして伝送される。さらに第４のステップにおいて第１の変更の確認が行われ、第５のステップにおいて第２の変更の確認が行われる。ペンディングカウンタＰＣはそれぞれ確認状態を表す。

第６のステップにおいて管理する側のシステムにとって承認されない変更が行われ、これには星型のシンボルが付されている。この変更はエラーメッセージ「Ｅ」として拒否され、その結果、第８のステップにおいてその変更前の状態がリストアされる。これと同時に、（拒絶された）変更された状態がインボックスに配置され、これによりユーザはそれについて処理を続けることができる。その間に第７のステップで行われた第１のフィールドにおける許可された変更が、第９のステップにおいて確認される。

先行イメージ（before image）の生成は、リジェクトサービスを用いたＭＳシステムのフローコントロールの制御のもとで行われる。これはＢＤｏｃのヘッダにセットされたフラグに基づき、ＢＤｏｃ全体が承認されたのか拒否されたのかをチェックする。拒否の場合、リジェクトサービスはＢＤｏｃの全データを統合データベースＣＤから抽出し、それをＢＤｏｃ内で先行イメージとして利用できるようにする。ＢＤｏｃ全体が承認されればリジェクトサービスはその部分セグメントをその状態についてチェックする。部分セグメントが拒否された場合にはその内容がやはり統合データベースＣＤから抽出され、先行イメージにおいて得られるようにする。

管理する側のシステムはＬＳＣ手順において、到来するデータをチェックし必要であれば拒否できるようでなくてはならない。このような機能はバックオフィスシステムにおいては一般に実装されている。この関連でやはり重要なその他の機能についてはすでに説明した。これにはデータマージ手順との関連で説明した受け入れの事例におけるデータ補足や、同じく説明済みの管理する側のシステムのプライマリキーの伝送が含まれる。
５．これまで説明してきた結合システムの拡充ならびに変形
これまで示してきた実施例では基本的に、ＣＲＭフロントオフィスシステムの中央計算部を成すミドルウェアサーバＭＳとＥＲＰバックオフィスシステムの例としてのＯＬＴＰ−Ｒ／３システムとの間のデータ交換について説明してきた。

とはえいえ既述の手順やアルゴリズムを他の事例にも適用することができる。たとえばミドルウェアシステムＭＳは既述の手順を利用して様々な別のデータベースシステムと利用することができる。それらのデータベースの論理構造は処理されるオブジェクトのレベルで少なくともオーバラップ部分をもっている一方、それらの構造はプログラミング技術的実装のレベルでは互換性のないものである。したがってＭＳシステムを、既述の手順を利用して様々な外部のデータシステム間の交換システムとして利用することができる。

オフライン分散型データベースにおける本発明による結合システムの環境の外観を示す図 本発明において適用されるフロントオフィスシステムのアーキテクチャに関する概観をＣＲＭシステムの実施例で示す図 図２によるシステムのフローコントロールの典型的な流れをデータアップロードプロセスの実施例として示す図 図２によるシステムで適用されるデータオブジェクト（"ＢＤｏｃ"）の構造を示す図 本発明に従って互いに結合された２つのシステムにおいてデータのアップロードおよびダウンロード時にはたらくコンポーネントのアーキテクチャを示す図 ダウンロードの事例に関する図３に応じたフローチャートを示す図 関与するデータベースシステムに他のデータベースシステム内に含まれているデータを初回にダウンロードするためのコンポーネントのアーキテクチャを示す図 必要とされるプライマリキーをシステムを超えて供給する方法を説明するための原理図 ＢＤｏｃおよび属するキーマッピングテーブルのセグメント構造に関する実施例を示す図 いくらか複雑なセグメント構造を有する図９によるＢＤｏｃの構造に関する実施例を示す図 本発明に適したデータマージ手順の原理を説明する図 初回ダウンロードにおける基本コンポーネントの共働の様子を示す基本原理図 本発明に適したネットフィールド伝送手順を説明するための図 本発明に適したネットフィールド伝送手順を説明するための図 データを同期合わせする手順を説明するための基本コンポーネントの原理図 本発明に適した「コンペア」モジュールの機能を説明するための基本原理図 本発明に適したデータアップデート時のコンフリクトを解消する手順の原理図

符号の説明

Ｃ カスタマ
ＳＲ 外勤従業員
ＭＣ モバイルクライアント
ＬＤ ローカルデータベース
ＣＲＭ−ＭＳ フロントオフィスサーバ
ＯＬＴＰ−ＤＢ オンライントランザクションプロセッシングデータベース
ＢＷ 外部システム
ＨＯ 本部
ＩＨＥ 内勤従業員
ＡＳ アドミニストレーションステーション
ＡＣ アドミニストレーションコンソール
ＭＴＳ メッセージ伝送サーバ
ＯＭＡ 送出メッセージ用アダプタ
ＲＰＭ リアライメントモジュール
ＭＰ メッセージプロセッサ
ＦＣ フローコントロール
ＩＭＡ 到来メッセージ用アダプタ
ＯＬＴＯＰ−ＡＤ ＯＬＴＰアダプタ
ＢＷ−ＡＤ ＢＷアダプタ
ＣＤＳ 統合データベースサービス
ＣＤ 統合データベース

Claims (12)

1. 第１および第２のコンピュータに格納されたコンピュータプロセッサ命令として実装されている方法において、
   前記コンピュータプロセッサ命令により、プロセッサと記憶手段と入出力手段を有する第１および第２のコンピュータが、該第１および第２のコンピュータの記憶手段に格納されている第１および第２のデータベースシステム内のデータセットを更新し、
   前記第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納されたデータセットに対して実行された変更によって、前記第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納されたデータセットが更新され、
   前記第１のデータベースシステムのデータセットには、前記第２のデータベースシステムには関連しない非関連データと、前記第２のデータベースシステムに関連する関連データの双方が含まれており、
   前記第１および第２のデータベースシステム双方におけるデータは、該第１および第２のデータベースシステムにおける第１および第２のコンピュータの記憶手段に格納されたデータオブジェクトとして該第１および第２のデータベースシステムにおける第１および第２のコンピュータのプロセッサにより処理され、
   データオブジェクト各々には、該データオブジェクトを処理するためのシステム固有のプライマリーキーが含まれており、
   前記第２のデータベースシステムにおける第２のコンピュータのプロセッサは、該第２のデータベースシステムにおける第２のコンピュータの記憶手段内のデータを、前記第１および第２のデータベースシステムのシステム固有のプライマリキーとともに格納し、
   前記第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納されているデータセットを更新する命令には、前記第１のデータベースシステムにおける第１のコンピュータのプロセッサに対し、
   ａ）前記第２のデータベースシステムには関連しないデータを分離して、該データを前記第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納するステップと、
   ｂ）第１のデータオブジェクトを、前記第１のデータベースシステムにおける第１のコンピュータの記憶手段から、前記第２のデータベースシステムにおける第２のコンピュータの記憶手段へ、データネットワークを介して転送するステップ
   を実行させる命令が含まれており、
   前記第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納されているデータセットを更新する命令には、前記第２のデータベースシステムにおける第２のコンピュータのプロセッサに対し、
   ｃ）前記第１のデータベースシステムのためのシステム固有のキーを転送された前記データオブジェクトから分離し、分離された該キーを前記第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納するステップと、
   ｄ）得られたデータオブジェクトを前記第２のデータベースシステムにおける第２のコンピュータの記憶手段の格納ルーチンに組み込み、前記データオブジェクト内に含まれているデータを、前記第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納するステップ
   を実行させる命令が含まれていることを特徴とする、
   コンピュータに格納されたコンピュータプロセッサ命令として実装されている方法。
2. 前記第２のデータベースシステムにおける第２のコンピュータの記憶手段におけるコンピュータプロセッサ命令により該第２のコンピュータのプロセッサは、前記第２のデータベースシステムにおける第２のコンピュータの記憶手段の格納ルーチンに前記第１のデータオブジェクトを組み込む前に、該データオブジェクトのデータレコードを前記第２のデータベースシステムにおける第２のコンピュータの記憶手段における第２のデータベースシステムのデータセットに対応する付加的な値によって補う、請求項１記載の方法。
3. 第１および第２のコンピュータに格納されたコンピュータプロセッサ命令として実装されている方法において、
   前記コンピュータプロセッサ命令により、プロセッサと記憶手段と入出力手段を有する第１および第２のコンピュータが、該第１および第２のコンピュータの記憶手段に格納されている第１および第２のデータベースシステム内のデータセットを更新し、
   前記第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納された第２のデータベースシステム内のデータセットに対して実行された変更によって、前記第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納された第１のデータベースシステム内のデータセットが更新され、
   前記第２のデータベースシステムのデータセットには、前記第１のデータベースシステムには関連しない非関連データと、前記第１のデータベースシステムに関連する関連データの双方が含まれており、
   前記第１および第２のデータベースシステムにおけるデータは、該データベースシステムにおけるコンピュータの記憶手段に格納されたデータオブジェクトとして前記第１および第２のデータベースシステムにおける第１および第２のコンピュータのプロセッサにより処理され、
   データオブジェクト各々には、該データオブジェクトを処理するためのシステム固有のプライマリーキーが含まれており、
   前記１のデータベースシステムにおける第１のコンピュータのプロセッサは、該第１のデータベースシステムにおける第１のコンピュータの記憶手段内のデータを、前記第１および第２のデータベースシステムのシステム固有のプライマリキーとともに格納し、
   前記第２のデータシステムにおける第２のコンピュータの記憶手段に格納されているデータセットを更新する命令には、前記第２のデータベースシステムにおける第２のコンピュータのプロセッサに対し、
   ａ）前記第１のデータベースシステムには関連しないデータを分離して、該データを前記第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納するステップと、
   ｂ）前記データオブジェクトを、前記第２のデータベースシステムにおける第２のコンピュータの記憶手段から前記第１のデータベースシステムにおける第１のコンピュータの記憶手段へ、データネットワークを介して転送するステップ
   を実行させる命令が含まれており、
   前記第１のコンピュータの記憶手段に格納されているデータセットを更新する命令には、前記第１のデータベースシステムにおける第１のコンピュータのプロセッサに対し、
   ｃ）前記第２のデータベースシステムのためのシステム固有のキーを転送された前記データオブジェクトから分離し、分離された該キーを前記第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納するステップと、
   ｄ）得られたデータオブジェクトを前記第１のデータベースシステムにおける第１のコンピュータの記憶手段の格納ルーチンに組み込み、該データオブジェクトに含まれるデータを前記第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納するステップ
   を実行させる命令が含まれていることを特徴とする、
   コンピュータに格納されたコンピュータプロセッサ命令として実装されている方法。
4. 前記第１のデータベースシステムにおける第１のコンピュータの記憶手段におけるコンピュータプロセッサ命令により該第１のコンピュータのプロセッサは、前記第１のデータベースシステムにおける第１のコンピュータの記憶手段の格納ルーチンに前記第１のデータオブジェクトを組み込む前に、前記第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納されているデータオブジェクトのデータレコードを、前記第１のデータベースシステムのデータセットに対応する付加的な値によって補う、請求項３記載の方法。
5. 前記第１のデータベースシステムにおける第１のコンピュータの記憶手段におけるコンピュータプロセッサ命令により該第１のコンピュータのプロセッサは、
   ｅ）前記第１のデータベースシステムにおける第１のコンピュータの記憶手段へデータオブジェクト内に含まれるデータを格納した結果としてイベントをトリガするステップと、
   ｆ）前記第１のデータベースシステムにおける第１のコンピュータの記憶手段へデータオブジェクト内に含まれるデータを格納したイベントを承認した前記第２のデータベースシステムにおけるコンポーネントにおいてイベントを受け取るステップと、
   ｇ）前記第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納されているデータオブジェクトに固有の保管されたキーを追加するステップと、
   ｈ）前記第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納されているデータオブジェクトのデータを、前記第１のデータベースシステムにおける第１のコンピュータの記憶手段から取り除くステップと、
   ｉ）取り除かれた該データを前記第２のデータベースシステムにおける第２のコンピュータの記憶手段へ、双方のデータベースに関連するデータを含むデータオブジェクトおよび前記第２のデータベースシステムに固有のキーおよび前記第１のデータベースシステムに固有のキーとして、データネットワークおよび双方のデータベースシステムにおけるコンピュータの出力手段を介して転送するステップを実行し、
   前記第２のデータベースシステムにおける第２のコンピュータの記憶手段におけるコンピュータプロセッサ命令により該第２のコンピュータのプロセッサは、
   ｊ）前記第１のデータベースシステムに関連しないデータを、前記第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納されたデータオブジェクトに追加し、該データを前記第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納するステップを実行する、
   請求項３記載の方法。
6. プロセッサと記憶手段と入出力手段を有する第１および第２のコンピュータに対し、第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納されたデータセットに対して実行された変更によって、第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納されたデータセットを更新する方法を実行させる命令が格納されており、
   前記第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納されたデータセットには、前記第２のデータベースシステムには関連しない非関連データと、前記第２のデータベースシステムに関連する関連データの双方が含まれており、
   前記第１および第２のデータベースシステムにおける第１および第２のコンピュータの記憶手段に格納されているデータは前記第１および第２のデータベースシステムにおけるプロセッサによりデータオブジェクトとして処理され、
   データオブジェクト各々には、該データオブジェクトを処理するシステム固有のプライマリーキーが含まれており、
   前記第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納されたデータは、前記の第１および第２のデータベースシステムのシステム固有のプライマリキーとともに格納されている形式の第１および第２のデータベースシステムのうち、前記第１のデータベースシステムにおける前記第１のコンピュータにより読み取り可能な記憶媒体において、
   前記第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納された前記データセットの更新命令は、前記第１のデータベースシステムの第１のコンピュータにおけるプロセッサに対し、
   ａ）前記第２のデータベースシステムには関連しないデータを分離して、該データを前記第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納するステップと、
   ｂ）該第１のデータオブジェクトを、前記第１のデータベースシステムにおける第１のコンピュータの記憶手段から前記第２のデータベースシステムにおける第２のコンピュータの記憶手段へ、データネットワークを介して転送するステップ
   を実行させる命令が含まれていることを特徴とする、
   コンピュータにより読み取り可能な記憶媒体。
7. プロセッサと記憶手段と入出力手段を有する第１および第２のコンピュータに対し、第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納されたデータセットに対して実行された変更によって、第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納されたデータセットを更新する方法を実行させる命令が格納されており、
   前記第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納されたデータセットには、前記第２のデータベースシステムには関連しない非関連データと、前記第２のデータベースシステムに関連する関連データの双方が含まれており、
   前記第１および第２のデータベースシステムにおける第１および第２のコンピュータの記憶手段に格納されているデータは前記第１および第２のデータベースシステムにおけるプロセッサによりデータオブジェクトとして処理され、
   データオブジェクト各々には、該データオブジェクトを処理するシステム固有のプライマリーキーが含まれており、
   前記第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納されたデータは、前記の第１および第２のデータベースシステムのシステム固有のプライマリキーとともに格納されており、
   前記第２のデータベースシステムには関連しないデータが分離され、該データを前記第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納され、該第１のデータオブジェクトが、前記第１のデータベースシステムにおける第１のコンピュータの記憶手段から前記第２のデータベースシステムにおける第２のコンピュータの記憶手段へ、データネットワークを介して転送される形式の、第１および第２のデータベースシステムのうち、第２のデータベースシステムにおける前記第２のコンピュータにより読み取り可能な記憶媒体において、
   前記第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納された前記データセットの更新命令は、前記第２のデータベースシステムの第２のコンピュータにおけるプロセッサに対し、
   ｃ）前記第１のデータベースシステムのためのシステム固有のキーを転送された前記データオブジェクトから分離し、分離された該キーを前記第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納するステップと、
   ｄ）得られたデータオブジェクトを、前記第２のデータベースシステムにおける第２のコンピュータの記憶手段の格納ルーチンに組み込み、該データオブジェクトに含まれているデータを前記第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納するステップ
   を実行させる命令が含まれていることを特徴とする、
   コンピュータにより読み取り可能な記憶媒体。
8. プロセッサと記憶手段と入出力手段を有する前記第１のデータベースシステムにおける第１のコンピュータは格納されている前記命令により、前記第１のデータオブジェクトが前記第２のデータベースシステムにおける第２のコンピュータの記憶手段の格納ルーチンに組み入れられる前に該データオブジェクトのデータレコードを、前記第１のデータベースシステムにおける第１のコンピュータの記憶手段の前記第２のデータベースシステムのデータセットに対応する付加的な値で補う、請求項７記載の記憶媒体。
9. プロセッサと記憶手段と入出力手段を有する第１および第２のデータベースシステムにおける第１および第２のコンピュータに対し、前記第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納されたデータセットに対して実行された変更によって、第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納されたデータセットを更新する方法を実行させる命令が格納されており、
   前記第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納されたデータセットには、前記第１のデータベースシステムには関連しない非関連データと、前記第１のデータベースシステムに関連する関連データの双方が含まれており、
   前記第１および第２のデータベースシステムにおける第１および第２のコンピュータの記憶手段に格納されているデータは前記プロセッサによりデータオブジェクトとして処理され、
   データオブジェクト各々には、該データオブジェクトを処理するシステム固有のプライマリーキーが含まれており、
   前記第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納されたデータは、前記の第１および第２のデータベースシステムのシステム固有のプライマリキーとともに格納されている形式の第１および第２のデータベースシステムのうち、第２のデータベースシステムにおける第２のコンピュータにより読み取り可能な記憶媒体において、
   前記第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納されている前記データセットの更新命令は、前記第２のデータベースシステムの第２のコンピュータにおけるプロセッサに対し、
   ａ）前記第１のデータベースシステムに関連しないデータを分離して、該データを第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納するステップと、
   ｂ）前記第２のデータベースシステムにおける第２のコンピュータの記憶手段から、前記第１のデータベースシステムにおける第１のコンピュータの記憶手段へ、データネットワークを介して前記データオブジェクトを転送するステップ
   を実行させる命令が含まれていることを特徴とする、
   コンピュータにより読み取り可能な記憶媒体。
10. プロセッサと記憶手段と入出力手段を有する第１および第２のデータベースシステムにおける第１および第２のコンピュータに対し、前記第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納されたデータセットに対して実行された変更によって、第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納されたデータセットを更新する方法を実行させる命令が格納されており、
    前記第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納されたデータセットには、前記第１のデータベースシステムには関連しない非関連データと、前記第１のデータベースシステムに関連する関連データの双方が含まれており、
    前記第１および第２のデータベースシステムにおける第１および第２のコンピュータの記憶手段に格納されているデータは前記プロセッサによりデータオブジェクトとして処理され、
    データオブジェクト各々には、該データオブジェクトを処理するシステム固有のプライマリーキーが含まれており、
    前記第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納されたデータは、前記の第１および第２のデータベースシステムのシステム固有のプライマリキーとともに格納されており、
    前記第１のデータベースシステムに関連しないデータが分離され、該データを第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納され、前記第２のデータベースシステムにおける第２のコンピュータの記憶手段から、前記第１のデータベースシステムにおける第１のコンピュータの記憶手段へ、データネットワークを介して前記データオブジェクトが転送される形式の、第１および第２のデータベースシステムのうち、第１のデータベースシステムにおける第１のコンピュータにより読み取り可能な記憶媒体において、
    前記第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納されている前記データセットの更新命令は、前記第１のデータベースシステムにおける第１のコンピュータにおけるプロセッサに対し、
    ｃ）前記第２のデータベースシステムのためのシステム固有のキーを転送された前記データオブジェクトから分離し、分離された該キーを前記第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納するステップと、
    ｄ）得られたデータを前記第１のデータベースシステムにおける第１のコンピュータの記憶手段の格納ルーチンへ組み入れ、前記データオブジェクトに含まれているデータを前記第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納するステップ
    を実行させる命令が含まれていることを特徴とする、
    コンピュータにより読み取り可能な記憶媒体。
11. 格納されている前記命令により前記第２のデータベースシステムにおける第２のコンピュータは該第２のコンピュータのプロセッサに対し、前記第１のデータベースシステムにおける第１のコンピュータの記憶手段の格納ルーチンへの前記組み込み前に、前記第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納された前記データオブジェクトのデータレコードを、前記第１のデータベースシステムのデータセットに対応する付加的な値によって補う、請求項９記載の記憶媒体。
12. 前記第１のデータベースシステムの第１のコンピュータにおけるプロセッサは格納されている前記命令により、
    ｅ）前記第１のデータベースシステムにおける第１のコンピュータの記憶手段へデータオブジェクト内に含まれるデータを格納した結果としてイベントをトリガするステップと、
    ｆ）前記第１のデータベースシステムにおける第１のコンピュータの記憶手段へデータオブジェクト内に含まれるデータを格納したイベントを承認した前記第２のデータベースシステムにおけるコンポーネントにおいてイベントを受け取るステップと、
    ｇ）前記第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納されているデータオブジェクトに固有の保管されたキーを追加するステップと、
    ｈ）前記第１のデータベースシステムにおける第１のコンピュータの記憶手段に格納されているデータオブジェクトのデータを、前記第１のデータベースシステムにおける第１のコンピュータの記憶手段から取り除くステップと、
    ｉ）取り除かれた該データを前記第２のデータベースシステムにおける第２のコンピュータの記憶手段へ、双方のデータベースに関連するデータを含むデータオブジェクトおよび前記第２のデータベースシステムに固有のキーおよび前記第１のデータベースシステムに固有のキーとして、データネットワークおよび第１のデータベースシステムにおけるコンピュータの出力手段を介して転送するステップを実行し、
    前記第２のデータベースシステムの第２のコンピュータにおけるプロセッサは格納されている前記命令により、
    ｊ）前記第１のデータベースシステムに関連しないデータを、前記第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納されたデータオブジェクトに追加し、該データを前記第２のデータベースシステムにおける第２のコンピュータの記憶手段に格納するステップを実行する、
    請求項９または１０記載の記憶媒体。

Images