JP2003520363A - 部分的に複製されるデータベースシステムのネットワークにおけるデータメンテナンス方法 - Google Patents

部分的に複製されるデータベースシステムのネットワークにおけるデータメンテナンス方法

Info

Publication number
JP2003520363A
JP2003520363A JP2001505305A JP2001505305A JP2003520363A JP 2003520363 A JP2003520363 A JP 2003520363A JP 2001505305 A JP2001505305 A JP 2001505305A JP 2001505305 A JP2001505305 A JP 2001505305A JP 2003520363 A JP2003520363 A JP 2003520363A
Authority
JP
Japan
Prior art keywords
replication
destination
database
data
bdoc
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2001505305A
Other languages
English (en)
Other versions
JP2003520363A5 (ja
Inventor
パウリー ハインツ
ブレンドレ ライナー
Original Assignee
エスアーペー アクチエンゲゼルシャフト
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from EP99120009A external-priority patent/EP1093061A1/de
Application filed by エスアーペー アクチエンゲゼルシャフト filed Critical エスアーペー アクチエンゲゼルシャフト
Publication of JP2003520363A publication Critical patent/JP2003520363A/ja
Publication of JP2003520363A5 publication Critical patent/JP2003520363A5/ja
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/273—Asynchronous replication or reconciliation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2372—Updates performed during offline database operations
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99933—Query processing, i.e. searching
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99951—File or database maintenance
    • Y10S707/99952—Coherency, e.g. same view to multiple users
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99951—File or database maintenance
    • Y10S707/99952—Coherency, e.g. same view to multiple users
    • Y10S707/99954—Version management

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Multi Processors (AREA)

Abstract

(57)【要約】 中央データベース（ＳＣ）を備えた中央システム（ＣＳ）とローカルデータベース（ＬＤ）を備えた複数のノードシステム（ＮＳ）とを有する、オフライン分散型データベースネットワークシステム（ＤＢＮＳ）におけるデータメンテナンス方法において、ローカルデータベース（ＬＤ）は少なくとも部分的に異なる中央データベース（ＳＣ）の部分集合を含んでおり、データベースネットワークシステム（ＤＢＮＳ）のデータベース（ＣＤ、ＬＤ）に記憶されているデータに対する変更情報は複数のノードシステム（ＮＳ）に登録され、この変更情報はオンラインコネクションが形成されている場合に複数の異なるタイプで構造化されたＩＤキーを含むリプリケーションオブジェクトとしてノードシステムから中央システムへ伝送されるかまたは中央システムからノードシステムへ伝送され、オンラインコネクションが存在しない場合にはリプリケーションオブジェクトは後の伝送のために出力列で調製される。変更情報をともなうリプリケーションオブジェクトは中央システム（ＣＳ）内でリプリケーションアルゴリズムにより少なくとも１つのルックアップテーブル（ＬＵＴ）を介して伝達相手先のノードシステム（ＮＳ）に宛先として割り当てられ、少なくとも１つのルックアップテーブルが変更情報を考慮してリアライメントアルゴリズムにより更新される。

Description

【発明の詳細な説明】
【０００１】 本発明は、部分的に複製されるデータベースシステム、特にリレーショナルデ
ータベースシステムのネットワークにおけるデータメンテナンス方法に関する。
また本発明はこの種の方法にしたがって動作するデータベースシステム、この種
のデータベースシステム用のコンピュータプログラム製品、およびこの種のコン
ピュータプログラム製品を備えたデータ担体を対象とする。
【０００２】 データベース、特にリレーショナルデータベースはデータ処理装置内で処理さ
れるデータの管理のために多様に使用されている。リレーショナルデータベース
では、データは関係を記述した複数の２次元のテーブルを形成している。テーブ
ルは例えば所定のオブジェクトとこのオブジェクトに対して一義的に割り当てら
れるデータとに関連する。例えば企業の顧客データは“顧客”のテーブルに記憶
され、このテーブルの列は顧客の種々の属性（名称、住所、担当者、売上高など
）に関連している。種々の顧客の値はテーブルの行を形成している。オブジェク
トそのものだけでなくオブジェクト間の関係もリレーショナルデータベース内で
はテーブルとして示される。例えば所定の顧客に対して注文が行われる場合、注
文を管理するために形成された“注文”のテーブルに“顧客へ”という属性が含
まれ、これにより顧客と注文との関係が定められる。この種のポインタはデータ
ベースの種々のテーブルによって記述されるオブジェクト間の関係を示すのに重
要な役割を果たしている。
【０００３】 ポータブルコンピュータ（ラップトップコンピュータ）が広範に普及している
ので、中央データベースシステム（データベースサーバ）に保管されているデー
タを例えばラップトップコンピュータにインストールされた複数のローカルデー
タベースシステムに対して複製するという課題が多様に発生している。ラップト
ップコンピュータのローカルデータベースは当該のユーザによってオフラインで
、すなわち中央データベースサーバへの定常的なコネクションなしで利用されて
いる。この場合にデータはローカルデータベースから呼び出されるだけでなく、
ローカルで得られた情報に基づいて変更されたり、補足されたり、また消去され
たりする。
【０００４】 典型的な例は顧客担当システムであり、これはＳＦＡシステム［Sales Force
Automation System］またはＣＲＭシステム［Customer Relation Management Sy
stem］とも称される。この種のシステムは特に顧客ごとの相談、サービスおよび
販売などのＥＤＶ要求へ適合化されている。これに属するのは、企業の外勤社員
がラップトップコンピュータを携行しており、このラップトップコンピュータ固
有のローカルデータベースにそれぞれの外勤社員が例えば販売区域および担当の
顧客に基づいて必要とする全てのデータが含まれているような状況である。
【０００５】 本発明は一般にオフライン分散型データベースネットワークに関している。こ
こでは複数のデータベースシステムへのデータ記憶は定常的には相互接続されて
いないオフラインの種々のコンピュータによって分散的に行われる。もちろんこ
の種のデータベースネットワークには、ローカルデータベースシステムとして、
ラップトップコンピュータのほかそれぞれ固有のデータベースを備えた他の定置
型コンピュータシステムまたはモバイルコンピュータも関与する。
【０００６】 オフライン分散型データベースネットワークでは、データは関連するデータベ
ースシステム間で通常は報告すなわちメッセージを介して交換される。いわゆる
ハブストラクチャではメッセージの交換は星形で行われる。すなわちメッセージ
はローカルデータベースシステムから中央データベースシステムへ伝達され、そ
こで処理され、必要な場合にはネットワークの他のローカルデータベースシステ
ム（ノード）へ転送される。ローカルデータベース間での直接のデータ交換はハ
ブストラクチャを有するデータベースネットワークでは行われない。
【０００７】 以下では中央データベースシステムを中央システムと称する。データベースネ
ットワークシステムのローカルデータベースシステムをノードシステムと称する
。
【０００８】 本発明は特にハブストラクチャを有するデータベースネットワークに関する。
もちろんこのデータベースネットワークおよび別のコンピュータシステムを備え
た関連するデータベースシステムをネットワーク化して、ネットワーク内でデー
タをハブストラクチャによらずに交換することもできる。本発明のデータベース
ネットワークシステムのノードシステムはそれ自体で同様に星形に編成された下
位のデータベースネットワークシステムの中央システムとなることができ、これ
によりツリー構造を形成可能である。
【０００９】 一般に本発明のデータベースネットワークに関与するコンピュータシステムは
データベースシステムのみではなく他のアプリケーションも含んでおり、これら
は直接に、ハブストラクチャを考慮せず相互に通信する。ただしここではデータ
ベースネットワークに関与するデータベースのメンテナンスに必要となるデータ
交換を前述の手法で星形に行うことが必須である。
【００１０】 オフライン分散型データベースネットワークのメンテナンスには困難な問題点
が結びついている。
【００１１】 ノードシステムのローカルデータベースは中央データベースの完全な複製とは
なりえない。第１にはこのためのメモリ容量が一般に充分でなく、第２にはノー
ドシステム内でときおり必要となるデータの定常的なメンテナンスが許容不能な
計算時間および接続時間を生じさせるからである。しかも企業の包括的なデータ
を多重に複製する際のセキュリティ問題も同時に生じる。ここから、中央システ
ムの中央データベースをノードシステムのローカルデータベース内で選択的かつ
部分的に複製し、各ノードシステムにはその中から必要な各データを使用させる
という課題が発生する。
【００１２】 また、ネットワークの種々の部分システムにおいて、他の部分システムにとっ
て重要でありデータベース内のデータメンテナンスのフレームで処理すべきデー
タの変更を記録しなければならないという別の問題も生じる。例えば１人の外勤
社員が契約を取り付けて自身のノードシステムのデータベースにジョブを形成し
た場合、この外勤社員が顧客側の新たな担当者をデータベースに記録し、これま
での担当者を消去する場合、またはこの外勤社員が顧客の住所を変更したい場合
などにデータ変更がローカルで登録される。これらの例はデータベース技術で通
常用いられている３つの変更情報、すなわち挿入［Insert］、更新［Update］、
および消去［Delete］がローカルで行われることに相当する。さらに変更情報は
一般に大規模に中央データベース内で処理される。こうした変更は例えば外勤社
員にも必要な製品データの変更、新製品の導入、従来製品の消去などのケースで
ある。以下では更新・挿入・消去のデータベースオペレーションに基づく情報を
まとめて変更情報という概念を使用する。
【００１３】 関与しているデータベース内のローカルの変更には許可が必要であるため、中
央システムとノードシステムとの間のデータの整合性、すなわちシステム全体に
関与するデータベースの一貫性は変更の行われる回数が増大するにつれて低下す
る。データの一貫性を保証するためには、オフライン分散型データベースの内容
が時間ごとに一致しなければならない。データの変更はデータベースネットワー
クに関与するそれぞれのコンピュータシステム内で行われるので、中央データベ
ースおよびローカルデータベースで変更されたデータまたは補充されたデータを
相互に比較し、必要な場合には変更されたデータまたは新たなデータを交換しな
ければならない。こうしたデータ交換には特に次の要求、すなわち ａ）変更された全データを必要とするシステムの全加入者に報告しなければなら
ない（更新）、 ｂ）新たなデータを必要とする全てのローカルデータベース内へ入力しなければ
ならない（挿入）、 ｃ）部分システムでもはや必要ない全てのデータを消去しなければならない（消
去） という要求が課される。
【００１４】 オフライン分散型データベースネットワークのメンテナンスに結びついたデー
タ交換は、前述の要求のために、特にネットワークに多数のコンピュータシステ
ムが関与している事実を考慮するときわめて複雑となる。全世界で活動する国際
的な機構では数千または数万以上の加入者を有するオフライン分散型データベー
スも存在する。
【００１５】 米国特許第５８７３０９６号明細書には、変更情報が中央システムとノードシ
ステムとの間をドッキングオブジェクトと称されるデータコンストラクトを介し
て伝送されることが記載されている。このドッキングオブジェクトは相応のデー
タベース内容を指示するＩＤキーないしＩＤ識別子の形状の変更情報と、変更情
報の宛先、すなわちどのノードシステムへこのドッキングオブジェクトに含まれ
るそれぞれの変更情報を伝達すべきかを定めている分配情報とを有している。こ
の分配情報は可視性ルールと称される。データベースネットワーク全体の全ての
変更情報は相応の伝送プロセスおよび混合プロセスを経て中央変更レジスタ［Ce
ntral Update Log］内でまとめられ、中央システム内部からノードシステムの数
に相応する数の部分レジスタ［Partial Update Logs］へ分配される。この分配
は各データ変更に対して可視性ルールが個々のノードシステムごとに適用される
ことにより行われる。すなわち可視性ルールはＮ個のノードシステムに対してＮ
回適用される。この場合ＳＱＬ‐ＳＱＬステートメントとして符号化された分配
規則を直接に適用してもよいし、またこのルールが関係ドッキングオブジェクト
への指示であってもよい。後者はその時点で処理されているドッキングオブジェ
クトの変更情報が関係ドッキングオブジェクトにおけるのと同様にノードシステ
ムへ分配されるケースに相当する。このように部分レジスタ内で収集された変更
情報は、ノードシステムと中央システムとのコネクションが形成されると、個々
のノードシステムへ伝送される。
【００１６】 このプロセスは中央変更レジスタ内に含まれるデータを可視性ルールを用いて
フィルタリングすることに相応するが、これによりシステム全体にわたって全て
のデータ変更（更新・挿入・消去）を所定の規則にしたがってノードシステムへ
分配することができる。ただしこのプロセスは、特にデータベースネットワーク
システムを種々の要求に適合させる点で柔軟性に乏しい。さらにこのプロセスで
は必要な計算時間の点できわめてコストがかかる。したがって多数のノードシス
テムを有するデータベースシステムではパフォーマンスが不充分となる。
【００１７】 本発明の基礎となる課題は、必要な変更情報をオフライン分散型データベース
ネットワークシステムのノードシステムへ分配するための改善された方法を使用
できるようにすることである。
【００１８】 この課題は、中央データベースを備えた中央システムとローカルデータベース
を備えた複数のノードシステムとを有するオフライン分散型データベースネット
ワークシステムにおけるデータメンテナンス方法において、ローカルデータベー
スは中央データベースの少なくとも部分的に異なる部分集合を含んでおり、デー
タベースネットワークシステムのデータベースに記憶されているデータに対する
変更情報を複数のノードシステムに登録し、この変更情報をオンラインコネクシ
ョンが形成されている場合に複数の異なるタイプで構造化されたＩＤキーを含む
リプリケーションオブジェクトとしてノードシステムから中央システムへ伝送す
るかまたは中央システムからノードシステムへ伝送し、オンラインコネクション
が存在しない場合にはリプリケーションオブジェクトを後の伝送のために出力列
で調製し、変更情報をともなうリプリケーションオブジェクトを中央システム内
でリプリケーションアルゴリズムにより少なくとも１つのルックアップテーブル
を介して伝達相手先のノードシステムに宛先として割り当て、少なくとも１つの
ルックアップテーブルを変更情報を考慮してリアライメントアルゴリズムにより
更新することにより解決される。
【００１９】 本発明を以下に図示の実施例に則して詳細に説明する。関連して説明する本発
明の特徴は個々に使用することも組み合わせて使用することもでき、本発明の有
利な実施例を形成している。
【００２０】 図１には本発明のデータベースネットワークシステムのアーキテクチャの主要
な要素の概略図が示されている。図２には本発明の範囲で使用されるリプリケー
ションオブジェクトＢＤｏｃのストラクチャが示されている。図３にはローカル
のノードシステムで得られる変更情報を処理するプログラムモジュールのフロー
チャートが示されている。図４にはノードシステムと中央システムとの間に一時
的なコネクションを形成して監視するコネクションマネージャのフローチャート
が示されている。図５にはフロー制御による中央システム内のリプリケーション
オブジェクトを処理する際のフローチャートが示されている。図６にはバルク型
リプリケーションのフローチャートが示されている。図７にはインテリジェント
型リプリケーションタイプのフローチャートが示されている。図８には従属性リ
プリケーションのフローチャートが示されている。図９にはリアライメントプロ
グラムモジュールのフローチャートの第１の部分が示されている。図１０には図
９のフローチャートの続きの部分が示されている。図１１には図１０のインター
リンクリアライメントを実行するプログラムモジュールのフローチャートの第１
の部分が示されている。図１２には図１１のフローチャートの続きの部分が示さ
れている。図１３にはエクストラクタプログラムモジュールのフローチャートが
しめされている。図１４にはバルクサブスクリプションチェックモジュールのフ
ローチャートが示されている。図１５にはオブジェクトサブスクリプションチェ
ックモジュールのフローチャートが示されている。
【００２１】 図１には本発明のデータベースネットワークシステムＤＢＮＳ［Data Base Ne
twork System］の概略図が示されており、このシステムは中央システムＣＳ［Ce
ntral System］および複数のノードシステムＮＳ［Node System］から成ってい
る。このシステムは例えばＣＲＭシステムであり、ここでノードシステムＮＳは
特に企業の外勤社員の携行するラップトップコンピュータによって形成されてい
る。ノードシステムはシステムのモバイルクライアントとも称される。外勤社員
は情報（例えば注文情報）をノードシステムＮＳへ入力し、必要なデータ（例え
ば担当する顧客およびその注文に関するデータ）をノードシステムＮＳで呼び出
す。こうした機能を一時的かつ自律的に満足するために、これに必要な全てのデ
ータはローカルデータベース［Local Data Base］内に記憶されている。
【００２２】 データベースネットワークシステムにはモバイルクライアントのほかに他のシ
ステムもノードシステムとして関与しており、例えば当該の企業または顧客の定
置型のコンピュータシステムが定常的にオンラインで、または一時的にオフライ
ンで中央システムＣＳに接続される。このようにして例えば直接に顧客の注文を
外勤社員の仲介なしで処理することができる。この種の別のコンピュータシステ
ムを用いたデータベースもハブストラクチャとして編成された本発明のデータベ
ースネットワークシステムＤＢＮＳのローカルデータベースＬＤを形成すること
ができる。ここでこのデータベースは同時に他のネットワークに接続することが
できる。
【００２３】 ノードシステムＮＳでは相互に独立して変更情報が形成されるが、この情報は
中央システムＣＳにとってもノードシステムＮＳにとっても重要である。具体的
なシステムコンフィグレーション次第では別の変更情報が中央システムＣＳ自体
の内部で形成されることもある。中央システムは各ノードシステムが必要かつ許
容された情報を受け取るように制御する。中央データベースＣＤはコンソリデー
ティドデータベース［Consolidated Data Base］と称される。なぜならこのデー
タベースは、データベースネットワークシステムＤＢＮＳに関連するデータベー
ス間でのデータ交換の点で、ノードシステムＮＳの全てのローカルデータベース
の「公開」内容を最後のデータ交換の時点で有するからである。「公開」とはこ
こではデータベースネットワークシステム内で交換されるデータを意味する。も
ちろんローカルデータベースはそのほかにデータバンクネットワークシステムＤ
ＢＮＳの他の全ての関与者にとって重要というわけではないデータ、すなわち「
非公開」データも含むことができる。中央データベースＣＤによりローカルデー
タベースＬＤにはそれぞれ必要なデータが供給され、必要な場合にもローカルデ
ータベースＬＤが再形成される。
【００２４】 ノードシステムＮＳは所定の間隔を置いて（例えば毎晩）適切な通信路（例え
ば電話回線、インターネットまたはイントラネット）を介して中央システムＣＳ
へ接続される。その際に最後の接続以来収集されたデータが中央システムＣＳへ
伝送される。またノードシステムＮＳはこのときそのつど先行の時間範囲で自身
が処理したデータと別のノードシステムＮＳまたは中央システムＣＳで新たに入
力されたデータとを受け取る。
【００２５】 アプリケーションプログラムＡＳ［Application Software］とノードシステム
ＮＳのローカルデータベースＬＤとの間の全データストリームはノードシステム
内に実現されたトランザクション層ＴＬを介して伝送される。これによりローカ
ルデータベースＬＤでの変更全体は通用前に記録される。中央システムＣＳから
ノードシステムＮＳへのデータ送信も専らトランザクション層ＴＬを介して行わ
れる。
【００２６】 トランザクション層ＴＬは透過性である。すなわちアプリケーションプログラ
ムＡＳからローカルデータベースＬＤへ引き渡されるアプリケーションデータは
トランザクション層ＴＬを経ても変更されない。出力側でこのトランザクション
層はプラットフォームの上位にあり、種々に実現されたローカルデータベースＬ
Ｄと共働する。
【００２７】 ＣＲＭシステムの実施例では、データベースネットワークシステム内部で交換
されるデータは例えば顧客や注文その他のビジネス上のプロセスに関連している
。したがってこれらのデータはビジネスデータと称される。データベースネット
ワークシステムＤＢＮＳでのデータ交換は構造化されたＩＤ識別子（ＩＤキー）
を有するリプリケーションオブジェクトを介して行われる。このリプリケーショ
ンオブジェクトをＢＤｏｃと称する。ＢＤｏｃはそれぞれのＢＤｏｃのタイプご
とに定められたストラクチャを有するデータコンテナであり、このことは後に詳
述する。ＢＤｏｃはデータベースネットワークシステムＤＢＮＳでのリプリケー
ションの最小単位を形成している。例えば所定の注文に対するＢＤｏｃは当該の
注文に属するデータを含んでおり、このときこのデータがリレーショナルデータ
ベースのテーブルとしての関連するデータベースＬＤ、ＣＤの論理ストラクチャ
内にどのように存在しているかは無関係である。ノードシステムＮＳおよび中央
システムＣＳの機能に必要な制御データはそれぞれのデータベースＬＤ、ＣＤの
特別の論理部に記憶され、これをレポジトリと称する。
【００２８】 図１に示されている実施例では、中央システムＣＳはＯＬＴＰ‐Ｒ／３と称さ
れる別のシステムと接続されている。ＯＬＴＰ‐Ｒ／３はSAP AG, Walldorf Deu
tschland のＥＲＰシステム［Enterprise Resouce Planning System］である。
このようなＥＲＰシステムにより種々の企業領域、例えば人材、販売、保管など
のＥＤＶサポートが共通のデータベースに基づいて可能となる。この共通のデー
タベースは図１ではＯＬＴＰ‐ＤＢと称される。データベースネットワークシス
テムＤＢＮＳの中央システムＣＳは例えばＬＡＮ［Local Area Network］を介し
てＥＲＰシステムＯＬＴＰ‐Ｒ／３に接続されている。
【００２９】 以下では変更情報の伝達に使用されるリプリケーションオブジェクトをＢＤｏ
ｃと称し、中央システムをＣＲＭシステムとし、中央システムＣＳに接続された
ＥＲＰシステムをＯＬＴＰ‐Ｒ／３とするが、これらはそれぞれ実施例としての
呼称であって一般性を制限するものではない。ここで説明する特徴は一般に本発
明の範囲で使用される相応のリプリケーションオブジェクトの機能および他のソ
フトウェア環境におけるコンピュータシステムにも相当する。
【００３０】 ノードシステムＮＳと中央システムＣＳまたは他の任意の外部システムとの間
のデータ伝送はキュードリモートファンクションコールｑＲＦＣと称される機能
モジュールを介して行われる。これは遠隔呼すなわちリモートコールである。こ
こでは付加的なインテリジェント指標により、ｑＲＦＣが列として順次に動作し
、複数の呼に必要な共通のデータが１度だけ記憶されることが保証される。
【００３１】 中央システムＣＳ内でのデータ処理はサービスないしアダプタと称されるプロ
グラムモジュールにより行われる。サービスはＢｄｏｃに対して適用される所定
の機能を使用する。アダプタは特殊なタイプのサービスであり、外部システムへ
の付加的な接続を行うことができる。各外部システムに対して固有のアダプタが
存在しており、このアダプタはＢＤｏｃモデリングと関連してレポジトリエント
リに基づいてそれぞれのＢＤｏｃタイプごとに形成される。アダプタは外部シス
テムのプロトコルおよびデータストラクチャを中央システムＣＳに対して変換す
るために用いられる。
【００３２】 フロー制御部［Flow Control］は中央システムＣＳの中心となるコンポーネン
トである。このフロー制御部はフロー定義ＦＤに基づいてＢＤｏｃの処理を制御
する。これは到来するＢＤｏｃを適切なシーケンスでサービスおよびアダプタへ
引き渡し、必要な場合にはエラー除去プロシージャをトリガすることによって行
われる。フロー制御は全てのサービスおよびアダプタに対してタイプごとに同じ
インタフェースを介して行われる。フロー定義ＦＤはＢＤｏｃタイプごとにレポ
ジトリとしての制御データメモリ内で定義されている。
【００３３】 ノードシステムＮＳから伝達されたＢＤｏｃは入力列ＩＢＱに記憶され、そこ
からランチャーＬＣＨによりフロー制御部ＦＣによる処理へ引き渡される。
【００３４】 ＥＲＰシステムＯＬＴＰ‐Ｒ／３との通信は相応のサービスＲ／３‐Ｓと２つ
のアダプタ、すなわちアウトバウンドアダプタＯＬＴＰ‐ＡＤＯおよびＩＮバウ
ンドアダプタＯＬＴＰ‐ＡＤＩとを介して行われる。
【００３５】 データベースサービスＣＤＳ［Consolidated Database Service］はコンソリ
デーティオデータベースＣＤ内にデータを記憶するために用いられる。サービス
ＣＤＳはデータをデータベースＣＤへ書き込む際にデータの一貫性に対する検査
を行わない。この種のチェックはデータを中央システムへ伝送するノードシステ
ムによって行わなくてはならない。データベースＣＤを読み出すために、他のプ
ログラムモジュールは、データベースサービスＣＤＳではなく必要に応じて呼び
出されるエクストラクタモジュールＥＸＴを使用する。
【００３６】 リプリケーションサービスＲＰＳはデータを中央システムＣＳから必要な場合
にノードシステムＮＳ内へ複製するために用いられる。このサービスは処理され
たＢＤｏｃを受け取り、ルックアップテーブルＬＵＴ［Lookup Table］から読み
出すことによりその宛先を求める。ルックアップテーブルを以下省略してＬＵＴ
と称する。ＬＵＴは有利にはきわめて簡単な２列のテーブルであり、ＢＤｏｃの
プライマリキーにそれぞれ宛先全体のキーすなわちサイトＩＤが対応づけられて
いる。キーにはインデクスが付され、アクセスは対数的な時間特性で行われるの
で、大規模なＬＵＴでもＢＤｏｃの宛先をきわめて迅速に読み出すことができる
。
【００３７】 リプリケーションサービスＲＰＳが現時点で処理されているＢＤｏｃによりＬ
ＵＴの宛先割り当てを変更しなければならないことを検出した場合、このサービ
スはリアライメントジョブをリアライメントモジュールＲＡに対して形成する。
リアライメント中、このリアライメントモジュールはサブスクリプションテーブ
ルＳＴ［Subscription Table］内に格納されたリプリケーション規則を使用する
。さらにこのリアライメントモジュールＲＡはエクストラクタモジュールを介し
てノードシステムＮＳに対する変更情報をフロー制御部へ引き渡し、フロー制御
部はこの変更情報をアウトバウンドキューＯＢＱと称される出力列で調製してノ
ードシステムＮＳへ伝送する。
【００３８】 別のタスクに対して付加的なサービスＳ１、Ｓ２を実現することができる。前
述のプログラムモジュールはＢＤｏｃのタイプごとに固有に定義されているので
、図１に示されているシンボル（例えばＣＤＳ、ＲＰＳなど）はそれぞれ一連の
相応のモジュールをデータベースネットワークシステムＤＢＮＳ内で使用される
ＢＤｏｃの全てのタイプに対してシンボル化している。またシンボルＬＵＴは有
利には種々のＢＤｏｃのタイプに対する複数のルックアップテーブルを表す。
【００３９】 中央システムＣＳ内のソフトウェア実現に対して有利にはSAP AG の技術およ
びＲ／３テクノロジのプログラム言語ＡＢＡＰが使用される。このプログラム言
語は種々のプラットフォームに対して透過性を有する。中央システムＣＳの機能
は複数のマシンへ分割される。特にデータベースごとに、また要求の処理形態な
いしシステム管理形態ごとに個別のマシンを使用することもできる。
【００４０】 実際にはシステム管理の目的のために、例えばＷｉｎｄｏｗｓＮＴ（登録商標
）で動作する管理ステーションＡＳと称されるマシンを使用すると有利である。
【００４１】 サブスクリプションチェックモジュールＳＣ［Subscription Checker］はＬＵ
Ｔを更新するために用いられる。これは管理ステーションでのシステム管理のフ
レームで変更情報を宛先へ分配するのに重要なシステム変更が行われる場合であ
る。有利にはこのためにＢＤｏｃのタイプに依存してサブスクリプションチェッ
クモジュールＳＣの２つの異なるタイプが使用される。ここで第１のタイプはＬ
ＵＴにおける直接の変更を形成し、第２のタイプは間接的にリアライメントモジ
ュールを使用して作用する。
【００４２】 図２にはＢＤｏｃのストラクチャが詳細に説明されている。
【００４３】 本発明に使用されるリプリケーションオブジェクトＢＤｏｃの主な特徴は、こ
のオブジェクトが論理ユニットを形成しており、これにより内部に含まれる変更
情報の１回きりの輸送および処理が保証されることである。ＢＤｏｃは特に１つ
の括弧を形成し、これにより受信部へのデータ伝送は完全である場合にのみ有効
と見なされることが保証される。このことは完全かつ適正なリプリケーションの
重要な前提条件である。ＢＤｏｃのこの機能がないと、例えばシステムダウンの
際に、部分的に伝送された旧いデータのみが完全であると見なされることになっ
てしまう。この場合リプリケーションエラーが発生する。
【００４４】 前述したようにＢＤｏｃはデータコンテナ、すなわち種々のデータを充填する
所定のストラクチャである。種々のタイプのＢＤｏｃは一般にストラクチャが異
なっている。例えばＢＤｏｃのタイプには“顧客”“製品”などがある。ＢＤｏ
ｃの個々のサンプルないしインスタンスは所定の顧客、製品などのデータを含ん
でいる。
【００４５】 有利にはＢＤｏｃはプラットフォームを超えるデータ伝送ないしアプリケーシ
ョンを超えるデータ伝送に用いられる。つまりＢＤｏｃは異なるプラットフォー
ム、すなわち異なるオペレーションシステムおよびデータベース管理システムを
使用し異なるアプリケーションで実現された複数のコンピュータシステム間での
データ伝送を可能にする。これを保証するために、関与しているデータベースシ
ステムのストラクチャをＢＤｏｃ内へマッピングしなければならない。これは調
製中のプロセスのフレームで行われ、ＢＤｏｃモデリングと称される。その場合
データベースのテーブルに相応してＢＤｏｃのセグメントが定義される。このセ
グメントはデータベースの相応のテーブルへのリンクを相応のキーの形状で含む
。したがってＢＤｏｃは、有利な実施例によれば、物理的にはデータそのもので
はなく、データベースに記憶されているデータへのリンクを含んでいることにな
る。ただしこれは論理的にはＢＤｏｃがデータを輸送するコンテナを形成してい
ることを意味する。
【００４６】 例えばテーブル“物件‐ヘッダ”および“物件‐位置”を有するデータベース
では、相応する“注文‐ヘッダ”のタイプのＢＤｏｃがデータベーステーブル“
物件‐ヘッダ”を有する。これは例えば顧客のＩＤ、物件番号、および供給の日
付などの基本データを含む。“注文‐ヘッダ”のＢＤｏｃの下位に存在する“注
文‐商品”のＢＤｏｃはデータベーステーブル“物件‐位置”へのリンクを含む
。このテーブルに物件の個別の位置が記憶されている。簡単なケースではこのテ
ーブルと関連するデータベースおよびＢＤｏｃのセグメントとの対応関係は相互
に一義的である。ただしテーブルの内容を複数のＢＤｏｃへ分割したり、また複
数のテーブルの内容を１つのＢＤｏｃへまとめたりするケースもある。
【００４７】 全体ではＢＤｏｃは関与している全てのデータベースシステムの上述の意味で
の公開データ集合の全体の解析となっている。解析という概念はここでは数学的
な意味で理解されたい。すなわちデータベースの全ての公開データは１度だけ、
つまりオーバラップなしに完全にＢＤｏｃで受け取られる。
【００４８】 上述のことから判るように、ＢＤｏｃ全体はデータベースネットワークシステ
ムＤＢＮＳに関与しているデータベースシステムの公開データのマッピングであ
る。ＢＤｏｃモデリングのフレームでは続いて、関与している全てのデータベー
スのストラクチャをセマンティクスレベルで考慮しなければならない。さらにＢ
Ｄｏｃモデリングのフレームではデータベースネットワークを使用する専門領域
の個別性が考慮される。実際にはこれはソフトウェアメーカ側でこうした領域に
依存したテンプレートと称されるベースモデルを供給することによって行われて
いる。これに基づいてアプリケーションごとの適合化が所定の企業でのシステム
の実現に関して行われる。
【００４９】 図２には上方にＢＤｏｃのタイプの定義のストラクチャが示されている。ＢＤ
ｏｃのストラクチャ自体は下方に示されている。２つのストラクチャは中央シス
テムＣＳのレポジトリ内に記憶されている。
【００５０】 ＢＤｏｃはＢＤｏｃヘッダＢＤｏｃ‐ＨおよびＢＤｏｃボディＢＤｏｃ‐Ｂか
ら成る。ＢＤｏｃヘッダＢＤｏｃ‐Ｈは例えばＢＤｏｃのタイプ（“顧客”、“
注文”など）や送信者（ノードシステムＮＳ）や時間識別子（タイムスタンプ）
などの制御情報を含んでいる。パフォーマンス上の理由からさらにこのヘッダが
プライマリキーのコピーを有すると有利である。
【００５１】 データはＢＤｏｃボディＢＤｏｃ‐Ｂ内に含まれている。ルートセグメント内
のフラグにより、更新・挿入・消去のいずれのデータベースオペレーションにＢ
Ｄｏｃ内で符号化された変更情報が相応しているかが示される。データレコード
ＤＲは本来のデータを含んでいる。ストラクチャは対応するデータセグメントＤ
Ｓの定義によって定義されている。セグメントは実際の物理的なテーブルの一種
のテーブルビューを形成している。付加的にＢＤｏｃは１つまたは複数のエラー
レコードＥＲを備えたエラーセグメントＥＳを含む。
【００５２】 データ領域は固定の長さを有する。このデータ領域はキーとデータフィールド
とから成る。データ領域が消去情報を有している場合、キーフィールドのみが有
効データを含む。データ領域が挿入情報または更新情報を含んでいる場合、全て
のフィールドが有効なデータを含んでいるか、または変更されていないフィール
ドが調整値（例えば０．０）を含んでいる。所定のフィールドが充填されている
かまたは利用されていないかを表示するために、いわゆる送信ビットが用いられ
る。第１キーおよびフィールドはリプリケーションおよびリアライメントの際に
考慮しなければならないので、変更されたか否かにかかわらずつねに送信される
。送信ビットは値が実際に変更された場合にのみセットされる。
【００５３】 ＢＤｏｃのタイプの定義、すなわち階層的に配列されたエレメントにおけるそ
れぞれのＢＤｏｃタイプごとに専用のストラクチャに関する情報はＢＤｏｃタイ
プ定義ＢＤＴＤ内に含まれており、これはＢＤｏｃボディ定義Ｂｄｏｃ‐ＢＤお
よびＢＤｏｃセグメント定義Ｂｄｏｃ‐ＳＤから成っている。ＢＤｏｃボディ定
義Ｂｄｏｃ‐ＢＤは唯一のデータレコードのみを有するルートセグメントを含む
。この条件は、ＢＤｏｃ内に含まれている情報が個別に各ノードシステムＮＳへ
伝達されるかまたは別の手段で処理されるかを保証するために遵守しなければな
らない。例えばタイプ“顧客”のＢＤｏｃには唯一の顧客に関する情報しか記憶
できず、これにより顧客情報を個別に、各顧客に対して所望に相応のノードシス
テムへ供給することができる。
【００５４】 ＢＤｏｃタイプ定義ＢＤＴＤ内のセグメントが階層的に構造化されているのに
対して、ＢＤｏｃの物理的な複製そのものはこの種の階層性を有さない。階層的
な従属性はＢＤｏｃ内ではセグメントに依存するデータレコードＤＲが上位のデ
ータレコードのキーを含むことにより示されている。
【００５５】 システムのパフォーマンスのためにはＢＤｏｃが論理的にそのつど必要な変更
情報のみを伝達することが重要である。これは実質フィールド伝送とも称される
。したがってこの伝送には完全なデータ集合を挿入する場合にのみそれぞれのＢ
Ｄｏｃタイプのインスタンス、すなわち例えば１つの注文に対する全てのデータ
が含まれる。更新の場合、伝送には、タイプのＩＤおよびＢＤｏｃのインスタン
スのＩＤのほか、論理的に見て変更されたデータフィールドの内容（例えば変更
された顧客の住所）のみが含まれる。消去の場合には必要なＩＤキーを伝達すれ
ば充分である。
【００５６】 以下に説明するフローチャートはＣＲＭシステムの実施例に関連している。こ
こでは中央システムＣＳをＣＲＭサーバとする。
【００５７】 図３はノードシステムＮＳから出発する変更情報の処理、つまにまず最初にア
プリケーションプログラムＡＳにおいて行われる変更情報の処理すなわちアップ
ロードに関連している。したがってこのプログラム部分はアプリケーション修正
処理と称される。このプログラム部分はトランザクション層ＴＬの構成要素であ
る。
【００５８】 アプリケーション修正処理をステップ３０１で開始した後、ステップ３０２で
アプリケーションプログラムＡＳによって変更されたデータがローカルデータベ
ースＬＤに記憶するためにトランザクション層ＴＬから受け取られる。その後同
じコミットサイクルのステップ３０３で、変更されたデータ集合に含まれる新た
な情報すなわちデルタ情報が求められる。ステップ３０４で送信フォーマットと
してＢＤｏｃが形成され、これは前述のように一義的なキーと変更情報とを含ん
でいる。
【００５９】 続くステップ３０５〜３１１は同じコミットサイクル内で処理される。これら
のステップは強制的に完全に実行すべきであるという意味の１つのトランザクシ
ョンを形成する。すなわちトランザクションの各部分オペレーションは他の全て
の部分オペレーションが実施された場合にのみ行われる。
【００６０】 この実施例では、トランザクションは、ＢＤｏｃのデルタ情報を中央システム
へ送信するオペレーション３０６とデルタ情報をローカルデータベースＬＤに記
憶するオペレーション３１０とに関連している。トランザクションとしてプログ
ラミングすることにより、このオペレーションは２つのオペレーション双方の実
行が保証された場合にのみ行われる。
【００６１】 ステップ３０６に続いて、ステップ３０７では当該のノードシステムＮＳがそ
の時点で中央システムＣＳに接続されているか否か、すなわちオンラインとなっ
ているか否かの問い合わせが行われる。この問い合わせの結果がイエスであると
きには直接にリモートコールが中央システムＣＳのインバウンドキューＩＢＱへ
伝達される。伝達すべきＢＤｏｃはリモートコールの追記を形成している。
【００６２】 一般に中央システムＣＳとのオンラインコネクションは存在していない。この
実施例で問い合わせステップ３０７の結果がノーである場合、ステップ３０８で
リモートコールが出力列内へ設定される。このリモートコールはノードシステム
ＮＳのローカルデータベースＬＤに記憶される。
【００６３】 このキューについて他の全てのキューと同様に以下の条件が相当する。すなわ
ち ａ）列の各呼が受信部に達し、そうでない場合にエラー信号が形成されることが
保証される［Guaranteed Delivery］。
【００６４】 ｂ）列の呼は所定のシーケンスで処理される［In Order Processing］。
【００６５】 ｃ）各呼は１度だけ行われる［Exactly Once］。
【００６６】 ステップ３１０で、変更情報がローカルデータベースＬＤへエントリされる。
ここではトランザクション層ＴＬがテーブル内のＢＤｏｃを解析し、対応する全
てのテーブルの全てのデータ集合を１コミットサイクル内で処理する。挿入はデ
ータベース内のＳＱＬステートメントにより行われる。変更は正味で同様にＳＱ
Ｌステートメントにより行われる。
【００６７】 図４には関与しているコンピュータシステム間でデータ交換に必要なコネクシ
ョンを形成して維持し、必要なデータ交換の終了後に終了するのに用いられるソ
フトウェアモジュールのフローチャートが示されている。このモジュールはＣＴ
Ｍ［ConTransManager］と称されるが、図１には簡単化のために示されていない
。このモジュールは完全に自動で機能するように構成されており、ＣＴＭを呼び
出した後にはユーザは何ら操作する必要はない。
【００６８】 ＣＴＭの開始ステップ４０１の後、ステップ４０２でコネクションサービスが
呼び出され、ステップ４０３で中央システムＣＳとのコネクションが形成される
。これは例えば通常の技術の電話番号、ＩＰアドレス、パスワードなどの選択を
含む。続いてステップ４０４でＣＲＭ送信サービスが呼び出され、このサービス
は相応のノードシステムのトランザクション層ＴＬの出力列に存在しているＢＤ
ｏｃがリモートコールを介して伝達されるように制御する。このようなリモート
コールが存在するかぎり、問い合わせステップ４０５に基づいてＢＤｏｃが伝送
される。それ以上リモートコールが存在しなくなると、問い合わせステップ４０
５で応答がノーとなり、問い合わせステップ４０７へ移行して中央システム側で
相応のノードシステムに対するデータが調製されているか否かが問い合わされる
。この問い合わせに対する応答がイエスである場合、ステップ４０８でデータが
ノードシステムへ伝送される。
【００６９】 問い合わせステップ４０９によりコネクションが切断されたか否かが検出され
、切断されている場合には制御部はステップ４０２へ移行し、コネクションサー
ビス４０２を介した新たなコネクションが形成される。切断されていない場合に
は、問い合わせステップ４１０でセッションが終了したか否か、すなわち中央シ
ステムＣＳ内で実行できる他の送信サービス（例えばＥメールの送信）が呼び出
されるか否かが検出される。こうしたサービスが呼び出される場合、すなわちセ
ッションがまだ終了しない場合にはステップ４１１で次の送信サービスが呼び出
され、そうでない場合にはこのシーケンスはステップ４１２で終了する。
【００７０】 中央システムＣＳでのＢＤｏｃの処理はフロー制御部ＦＣにより行われる。ラ
ンチャープロセスにより入力列ＩＢＱが処理され、受信されたＢＤｏｃに対して
フローが開始される。ＢＤｏｃの各タイプごとにフロー定義ＦＤとしてグラフが
定義され、このグラフにより定義された全てのサービスを通るＢＤｏｃの進行が
監視される。これは完全にタイプごとに行われる。具体的な処理は定義されたサ
ービスに依存する。その際にこのサービスはＢＤｏｃを輸送するだけでなく、例
えば付加的なフィールドを補充したり、また既存のフィールド内容を除去したり
といったようにその内容を変更することがある。例としてシステムを超えるキー
を種々のデータベースシステムのセマンティクス統合の際に付加することが挙げ
られる。このことは本出願人によるヨーロッパ特許出願第９９１２０００９．８
号明細書 "Integriertes Datenbank Verbundsystem" に記載されている。この明
細書の内容は本明細書の内容を補足するものとして本発明に完全に組み込まれて
いる。
【００７１】 フロー制御部ＦＣの一般的な特徴は図５に示されている。フローの開始ステッ
プ５０１の後、ステップ５０２でＢＤｏｃが処理のためにフロー制御部へ引き渡
され、別のフローがステップ５０３で記憶されたフロー定義ＦＤから得られたグ
ラフに基づいて行われる。このグラフにしたがってフロー定義に必要なサービス
が処理される。使用されるＢＤｏｃのタイプ（例えば“顧客”、“注文”）ごと
にこのフローは特に次のサービスを実行する。すなわち ａ）サービスＲ／３‐Ｓ：企業のＥＲＰシステムに関連して、企業のＥＲＰシス
テムから変更情報にアクセスできるようにする。企業のＥＲＰシステムに関連し
ない場合にはこのＲ／３‐Ｓシステムは相応のＢＤｏｃタイプのフローでは定義
されない。
【００７２】 ｂ）サービスＣＤＳ：変更情報をコンソリデーティドデータベースＣＤ内で通用
させる。このためにデータベースサービスＣＤＳはテーブル内のＢＤｏｃを解析
し、対応する全てのテーブルの全てのデータ集合をコミットサイクル内で処理す
る。挿入はＳＱＬステートメントによりデータベース内で行われる。更新は同様
にＳＱＬステートメントを介して正味で処理される。
【００７３】 ｃ）リプリケーションサービスＲＰＳ：当該の変更情報を担当するノードシステ
ムＮＳを宛先リストすなわちレシピエントリストへ入力する。
【００７４】 獲得したグラフに定義されているフローの全サービスの処理はループによって
保証される。つまり問い合わせステップ５０４でフローが終了したか否かが問い
合わされ、ステップ５０５でこの問い合わせへの応答がノーであった場合には次
のサービスが呼び出される。
【００７５】 全てのサービスが処理されると、フロー制御部ＦＣによって制御される各フロ
ーの終了ステップとしてのステップ５０６で変更情報がノードシステムＮＳへ分
配される。このことは図５では「フィールドへ進行する」として示されている。
ここではフロー制御部はリモートファンクションコールを介して宛先リストに基
づく宛先を呼び出す。これにより通常の場合、すなわち呼び出されたノードシス
テムへのオンラインコネクションが存在しない場合にコールのキューが個々のノ
ードシステムのアウトバウンドキューＯＢＱ内に形成される。オンラインコネク
ションが存在する場合にはこの呼び出しを直接に転送することができる。エラー
の場合にはエラー処理サービスへ分岐し、所定のエラー除去動作が導入される。
【００７６】 続いて図６〜図１５に則して変更情報を中央システムＣＳからノードシステム
ＮＳへ選択伝送するプロセスに関連した主な特徴を説明する。このプログラムモ
ジュールの動作は、本発明の有利な実施例によれば、データがデータベースネッ
トワークシステムＤＢＮＳ内で定常的にダイナミックに変更される際にも変更情
報が僅かな計算コストのみでノードシステムのそのつど適切な宛先へ良好なパフ
ォーマンスで分配されることを保証する。同時にこのシステムは種々のユーザグ
ループの要求に対する適合化の点においても、また既にインストールされている
システムを変動する要求へ後から適合させる点においてもきわめて大きな柔軟性
を保証している。
【００７７】 ここでは次の機能が重要な役割を果たしている。すなわち ａ）リプリケーションサービスＲＰＳによる複製 ｂ）リアライメントモジュールＲＡによるリアライメント ｃ）エクストラクトサービスＥＸＴによる抽出 ｄ）サブスクリプションチェックモジュールＳＣによるサブスクリプションチェ
ック である。
【００７８】 図６、図７、図８に示されたプログラムフローチャートでは３つの異なる基本
タイプのリプリケーションが示されており、処理すべき所定のＢＤｏｃタイプが
存在しているところから出発する。前述したように、所定のデータベースネット
ワークシステムＤＢＮＳで使用されるＢＤｏｃのタイプはこのシステムの装置で
はＢＤｏｃモデリングのフレームで定義される。リプリケーションサービスＲＰ
Ｓを介したリプリケーションはＢＤｏｃのタイプごとに個別に定義されており、
すなわちそれぞれのタイプごとに所定のリプリケーションサービスが定義されて
いる。ここでもちろん同じリプリケーションサービスを複数のＢＤｏｃのタイプ
に対して使用することもできる。データベースネットワークシステムＤＢＮＳの
装置では、必要なリプリケーションサービスがタイプに応じたエンジンを用いて
レポジトリに記憶されている制御データ内で形成される。各リプリケーションサ
ービスはフロー制御部がＢＤｏｃを引き渡してサービスを呼び出す時点で開始さ
れる。
【００７９】 よりよく理解するために、以下の説明では例としてＣＲＭシステムを挙げる。
ここでは外勤社員がそれぞれ所定の空間的な販売区域を担当している。販売区域
には各外勤社員の担当する所定の顧客が局在している。
【００８０】 顧客側の担当者の名称が変更される場合、これに結びついた変更情報は更新と
してそれぞれの区域の全ての外勤社員へ伝達される。このことはリプリケーショ
ンのフレームで行われる。
【００８１】 ただし多くの変更情報では、変更情報を最新のＬＵＴにしたがって相応の宛先
へ転送するだけでは充分でない。むしろ変更情報によってＬＵＴも変更しなけれ
ばならないことが多い。これに属するのは挿入および消去のタイプの全ての変更
情報である。なぜなら新たなリプリケーションオブジェクトインスタンス（例え
ば新たな顧客または新たな注文）の挿入によりそのつどルックアップテーブルの
相応の更新（新たなリプリケーションオブジェクトインスタンスの挿入、もはや
存在しないリプリケーションオブジェクトインスタンスの対応個所の消去）を行
わなければならないからである。更新はＬＵＴの適合化を発生させることもある
。例として１件の顧客が販売区域Ａから販売区域Ｂへ引っ越した場合について考
えてみよう。この場合まずＢＤｏｃの“顧客”のフィールド“住所”内で変更が
行われる。本発明の範囲では、このような更新は変更データを宛先へ分配する際
に、相応のデータフィールド（例えば顧客のアドレスの郵便番号を含むデータフ
ィールド）を分散上クリティカルなフィールドとして定義することにより考慮さ
れる。この種のフィールドでの変更はＬＵＴの変更を発生させる。このことは後
に詳述する。ＬＵＴの更新はリアライメント機能の一部である。
【００８２】 この種のアドレス変更により、この顧客のデータを販売区域Ｂの全てのノード
システムへ伝達し、これまでの販売区域Ａのノードシステムから消去しなければ
ならない。このことはＬＵＴの変更を意味する。変更を含むアドレスフィールド
を有するタイプ“顧客”のＢＤｏｃが処理される場合、まず最初に分散上クリテ
ィカルなフィールドにおけるこの変更が実際に分配の変更を発生させるか否かを
検出しなければならない。発生させない場合には、この変更をこれまでの未変更
の販売区域Ａの全てのノードシステムＮＳへ報告しなければならない。発生させ
ている場合には新たな販売区域Ｂの全てのノードシステムへ報告しなければなら
ない。同時に旧い販売区域Ａのノードシステムでの消去が行われる。
【００８３】 こうした変更の処理には挿入オペレーションおよび消去オペレーションが必要
であり、これらのオペレーションはリアライメントのフレームでトリガされる。
有利にはこれらのオペレーションは直ちには実行されず、エクストラクタモジュ
ールＥＸＴによって独立かつ非同期的に処理される抽出ジョブが形成される。エ
クストラクタモジュールは挿入オペレーションまたは消去オペレーションを実行
するためにデータベースネットワークシステムＤＢＮＳに関与するデータベース
へ伝達される。
【００８４】 さらにシステムアドミニストレータによって管理ステーションＡＳを介して行
われるシステム変更を考慮しなければならない。これは特にデータベースネット
ワークシステムの構造の変換に相当する。こうした構造変換は例えば付加的なノ
ードシステムの挿入、または変更情報を宛先へ分配する際に用いられる規則の変
更、すなわちサブスクリプションテーブルの変更にいたる規則の変更などから生
じる。この種の変更はサブスクリプションチェックモジュールＳＣによってシス
テム内で処理される。
【００８５】 図６にはリプリケーションサービスのバルク型リプリケーションと称されるタ
イプのプログラムフローが示されている。このサービスはＢＤｏｃに対して使用
され、ＢＤｏｃはタイプに依存して、それぞれのＢＤｏｃのインスタンスおよび
データ内容には依存せずに、所定の宛先へ伝送される。典型的な例としては企業
のそれぞれの外勤社員が使用しなければならない基本データ、例えばこの企業の
製品に関するデータが挙げられる。これはＢＤｏｃのタイプ“製品基本データ”
となる。
【００８６】 このようなバルクＢＤｏｃは、本発明の範囲では簡単化されており、最小の計
算コストできわめて迅速に処理される。典型的なアルゴリズムは図６に示されて
いる。
【００８７】 開始ステップ６０１およびＢＤｏｃの引き渡しステップ６０２の後、フロー制
御部により、ステップ６０３でＢＤｏｃのタイプに対する最新の宛先［Current
Responsibles］がＬＵＴから読み出される。このためにデータベースソフトウェ
アのフィルタ関数を使用することができる。ＬＵＴはＢＤｏｃのタイプの第１キ
ーにそれぞれ宛先全体のキーすなわちサイトＩＤを割り当て、これをサブスクリ
プションテーブル内で当該のＢＤｏｃタイプの加入者として示す。有利には複数
のバルク型リプリケーションまたは全てのバルク型リプリケーションに対して、
すなわちバルク型リプリケーションを経由して宛先へ分配される複数のＢＤｏｃ
タイプまたは全てのＢＤｏｃタイプに対して共通のＬＵＴが設けられる。このＬ
ＵＴは図６ではＢ‐ＬＵＴと称される。
【００８８】 次のバルク型リプリケーションステップ６０４では、ＢＤｏｃの送信者がその
内部に含まれている変更情報の宛先に属するか否かが問い合わされる。イエスの
場合には、ステップ６０５でＢＤｏｃのヘッダＢＤｏｃ‐Ｈに宛先リストがエン
トリされる。これは有利には物理的に宛先リストを定義する宛先リストＡＬ内の
データ集合への指示により行われる。この指示は宛先のキーすなわちサイトＩＤ
を有している。
【００８９】 変更情報の作者、つまりＢＤｏｃに含まれている変更情報を登録したノードシ
ステムが宛先に含まれず、問い合わせステップ６０４がノーであった場合の手段
も存在する。この手段はシステムがデータの関わり合いを許容しなければならな
いことに結びついている。例えば外勤社員が販売区域Ａから販売区域Ｂの同僚に
代わって変更をシステムへ入力するために、このために販売区域Ａに属する自身
のラップトップコンピュータを使用するケースなどがそうである。
【００９０】 このようなケースでは、ステップ６０５での宛先リストの形成前に、ステップ
６０６で抽出ジョブがエクストラクタキュー内へ調整され、相応の受信情報が消
去される。このことは後に詳述する。ここでは変更されたデータ集合が販売区域
Ａに属するノードシステム内に保持されたままとなることを阻止する必要がある
。このデータ集合はそこでは不必要であり、しかもメンテナンスされていないの
で迅速に老化しデータの不安定性をまねく。
【００９１】 図７に示されているインテリジェント型リプリケーションと図８に示されてい
る従属性リプリケーションとはオブジェクト別リプリケーションという上位の概
念によって統合することができる。これにより宛先への分配はＢＤｏｃのタイプ
に依存するのみでなく、個々のＢＤｏｃインスタンス、すなわちそれぞれのデー
タオブジェクトに依存するケースが特徴づけられる。ここでは次のケースが区別
される。すなわち ａ）分散上クリティカルなフィールドの内容により、当該のＢＤｏｃとこれに結
合されたＢＤｏｃのうちできる限りのものとに対するＬＵＴを変更しなければな
らない。これはインテリジェント型リプリケーションにより行われ、ここでリア
ライメントジョブが形成される。
【００９２】 ｂ）リプリケーションはＢＤｏｃインスタンスのレベルに対してオブジェクトご
と上位のオブジェクトに依存して行われる。このようなリプリケーションオブジ
ェクトの従属性は一般にテーブルとデータベースネットワークシステムに関与す
るデータベースとの相応の依存関係に相応する。典型的な例はつねに顧客に結び
ついた注文であり、この場合１件の顧客の注文のみが存在する。これにより１件
の顧客の全ての注文を顧客データそのものと等しい宛先へ分配しなければならな
い。ただしＢＤｏｃのタイプ“注文”は種々の顧客の多数の注文に対して使用さ
れる。こうしたタイプの各インスタンスは顧客のＩＤ識別のためのフィールドＧ
ＵＩＤを有しており、このフィールドは上位のどのリプリケーションオブジェク
トに対して従属性を有するかを示しており、宛先への分配のために用いられる。
【００９３】 インテリジェント型リプリケーションに対するアルゴリズムは図７に示されて
いる。サービスの開始ステップ７０１およびＢＤｏｃの引き渡しステップ７０２
の後、ＢＤｏｃのフィールドに定義されているデータベースオペレーションのタ
イプの問い合わせが行われる。
【００９４】 挿入または消去の場合、ステップ７０４内でリアライメントジョブが形成され
る。これはただちにリアライメントが実行されることを意味しない。むしろ唯一
の命令のみが形成され、この命令がリアライメントキューＲＡＱ内へセットされ
、非同期的に任意の時点で処理される。
【００９５】 ＢＤｏｃ内で符号化されるデータベースオペレーションが更新である場合には
、問い合わせステップ７０６で分散上クリティカルなフィールドが変更されたか
否かが問い合わされる。正の場合にはステップ７０４でリアライメントジョブが
形成される。
【００９６】 リアライメントジョブの形成に続いて、問い合わせステップ７０７でつねにＢ
Ｄｏｃ内で別のリプリケーションオブジェクトＢＤｏｃへのリンクが存在するか
否かが問い合わされる。存在する場合には、ステップ７０８で結合しているオブ
ジェクトごとにリアライメントジョブが形成される。これは例えば顧客の住所は
販売区域Ａに存在するが、コンツェルンに尋ねるとその本部は販売区域Ｂに存在
するというようなケースである。こうした情報はリンクを介して顧客の相応のＢ
Ｄｏｃ内で符号化され、ステップ７０８で販売区域Ａの外勤社員だけでなく、販
売区域Ｂの外勤社員も変更情報を受け取ることを保証するために使用される。親
会社の住所は双方にとって重要だからである。
【００９７】 この場合アルゴリズムは図６と同様にＬＵＴから最新の有効な宛先が最新のＢ
Ｄｏｃの処理から得られた変更を考慮せずにが読み出され、これに基づいてステ
ップ７１０で宛先リストがＢＤｏｃのヘッダに形成される。
【００９８】 宛先リストは多くの場合にエントリを有さない。例えば図７に示されたアルゴ
リズムを実行するＢＤｏｃ内で符号化されたデータが新たな顧客に関連する場合
、一般に各挿入で新たなリプリケーションオブジェクトに対するＯ‐ＬＵＴはエ
ントリを有さない。新たな顧客を担当するノードシステムへの分配はリアライメ
ントのフレームではじめて行われる。
【００９９】 インテリジェント型リプリケーションはＢＤｏｃインスタンスのレベルで行わ
れるので、すなわち各インスタンスに対してＬＵＴ内の全ての宛先の割り当てが
存在しなければならないので、例えば通信販売の顧客の大多数に対してきわめて
大きなＬＵＴが発生する。有利には１つのＢＤｏｃタイプのインスタンスの宛先
割り当てが共通のＬＵＴにまとめられる。これをオブジェクトＬＵＴすなわちＯ
‐ＬＵＴと称する。
【０１００】 特に有利には中央システムＣＳには、１つのＢ‐ＬＵＴすなわちバルク型リプ
リケーションに対して分配されるＢＤｏｃタイプのアドレス割り当てと複数のＯ
‐ＬＵＴとが設けられており、これらはそれぞれインテリジェント型リプリケー
ションによって分配されるＢＤｏｃタイプの個々のインスタンスごとに宛先の割
り当てすなわちサイトＩＤを有する。
【０１０１】 ステップ７１１はサービスの終了、すなわちＢＤｏｃのフロー制御部ＦＣへの
引き渡しをマーキングしている。
【０１０２】 図８には従属性リプリケーションと称されるＢＤｏｃのリプリケーションサー
ビスのフローが示されている。ＢＤｏｃの宛先への転送は上位のＢＤｏｃに依存
しており、上位のＢＤｏｃは図８ではリプリケーションオブジェクトＲＯとして
示されている。このケースではサービスの開始ステップ８０１およびＢＤｏｃの
引き渡しステップ８０２の後、ステップ８０３でルックアップテーブルから上位
のＢＤｏｃの宛先、すなわち例えば発注先の顧客の上位のＢＤｏｃの宛先が問い
合わされる。更なるステップ８０４〜８０８は図６のバルク型リプリケーション
サービスのステップ６０４〜６０８に相応する。
【０１０３】 従属性リプリケーションのほうがより簡単なアルゴリズムを有しており、きわ
めて迅速に実行可能であることが明らかである。このことは全システムのパフォ
ーマンスにとってきわめて重要である。なぜなら実際には従属性リプリケーショ
ンオブジェクトの数は通常きわめて多いからである。
【０１０４】 図９〜図１２はリアライメントモジュールＲＡによって実行される機能を説明
するものである。機能は２つの部分タスクへ分割される。すなわち ａ）ＬＵＴをローカルデータベースＬＤまたはコンソリデーティドデータベース
ＣＤ内でのデータ変更に基づいて更新するタスク、および ｂ）変更に基づいて必要となる挿入オペレーションおよび消去オペレーションを
トリガするタスク である。
【０１０５】 リアライメントは非同期的に、通常の場合システムアドミニストレータによっ
て定められる任意の時点でバッチプロセスにより実行される。リアライメントモ
ジュールはフロー制御部ＦＣによっては監視されないので、サービスとは称され
ない。非同期的な、リプリケーションに依存しないリアライメントの実行は全シ
ステムへの負荷の均一化、すなわち負荷平衡に対して重要な意義を有している。
例えばリアライメントを夜間に行う場合、システムの主利用時間の負荷が軽減さ
れ、これによりパフォーマンスが改善される。
【０１０６】 リアライメントキューに存在するリアライメントジョブは有利には、ＢＤｏｃ
インスタンス、例えば所定の顧客を一義的に表すそれぞれのＢＤｏｃのプライマ
リキーおよびＢＤｏｃタイプのＩＤのみを含む。ＢＤｏｃのデータ内容は必要に
応じてプライマリキーに基づいてコンソリデーティドデータベースＣＤから問い
合わされる。ＢＤｏｃのタイプはデータとノードとの割り当て［Assignment］の
形態に対して定められている。
【０１０７】 図９、図１０はインターリンケージの機能を除いたリアライメントアルゴリズ
ムのプログラムシーケンスが示されている。インターリンケージの機能について
は続く図１１、図１２に示されている。
【０１０８】 開始ステップ９０１の後、ステップ９０２でリアライメントキューＲＡＱ内に
存在するジョブがシーケンシャルにキューリーダから受け取られる。シーケンシ
ャルな処理によりリアライメントジョブの基礎となる変更情報が中央システムＣ
Ｓ内で処理された際のシーケンスと等しくなることが保証される。
【０１０９】 続いてステップ９０３でアサインメントのタイプについての問い合わせ、すな
わちリアライメントキューＲＡＱ内のＢＤｏｃとノードシステムＮＳとの割り当
てのタイプについての問い合わせが行われる。この割り当てはＢＤｏｃのタイプ
に依存している。レポジトリにはどのタイプのアサインメントが個々のＢＤｏｃ
タイプに対して使用されるかが格納されている。次の手段が区別される。
【０１１０】 ａ）ダイレクトアサインメント この割り当ては宛先が直接にＢＤｏｃのフィールドのデータ内容に依存するケ
ースで利用される。宛先を求めるには例えば販売区域（“エリア”）のフィール
ドが問い合わされ、その内容にしたがって中央システムＣＳに格納されているサ
ブスクリプションテーブルＳＴのレポジトリに基づいて宛先が検出される。
【０１１１】 ｂ）リファレンシャルアサインメント このタイプの割り当ては、宛先は第１には上位のリプリケーションオブジェク
トの既存のＬＵＴから読み出されるが、付加的にデータ内容に基づくインテリジ
ェント型の問い合わせも必要となるケースで使用される。例として、主として前
述したように顧客に依存して行われる注文が挙げられ、これはそれぞれの顧客に
対応する宛先へ分配される。付加的な分配基準を考慮しなくてよい場合には、こ
の分配は図８の従属性リプリケーションとして行われる。この場合にはリアライ
メントは必要なく、リアライメントジョブはリアライメントキューＲＡＱ内には
存在しない。
【０１１２】 また付加的な基準を宛先への分配の際に考慮しなければならないケースも存在
する。これは例えばノードシステムＮＳが建築家によって利用されるネットワー
クに相当する。ここでは建築家は所定の建物（注文）を担当しているが、顧客（
施主）の領域に住んでいるわけではなく、顧客を担当してもいない。この場合に
は建物に関するデータは従属性リプリケーションとして顧客の販売区域内に局在
しているノードシステムへ分配されるだけでなく、所定のフィールドのインテリ
ジェント型の問い合わせに基づいてこの建物を担当している建築家へも分配され
る。
【０１１３】 ｃ）インターリンケージ このタイプの割り当ては図１１、図１２に関連して説明する。
【０１１４】 ダイレクトアサインメントまたはリファレンシャルアサインメントの場合、プ
ログラムシーケンスはステップ９０４〜９１２へ進行し、順次に、また部分的に
は任意に実行される。
【０１１５】 ステップ９０４ではＢＤｏｃの分散上クリティカルなフィールドの内容がコン
ソリデーティドデータベースＣＤから受け取られる。続くステップ９０５、９０
６では任意に割り当ての形態と処理されたＢＤｏｃとに依存して少なくとも１つ
のステップが実行される。ここでステップ９０５を複数回実行することもできる
。
【０１１６】 ステップ９０５では新たな宛先［Current Responsibles］が上位のリプリケー
ションオブジェクトＳＲＯ‐ＬＵＴ［Lookup Table of Superior Replication O
bject］から問い合わされる。この問い合わせは処理されるＢＤｏｃが上位のオ
ブジェクトへの複数のリンクを有する場合、例えば複数の顧客に対して１つの注
文が行われる場合（施主の組合に対する１つの建物の注文など）には複数回必要
となることもある。
【０１１７】 ステップ９０６ではダイレクトアサインメントに基づいて新たな宛先が計算さ
れる。これはＢＤｏｃの分散上クリティカルなフィールドとレポジトリ内に格納
されているサブスクリプションテーブルＳＴとを比較することにより行われる。
リファレンシャルアサインメントの場合にはステップ９０５、９０６の２つとも
必要となる。ダイレクトアサインメントによるＢＤｏｃの場合にはステップ９０
６のみが行われる。
【０１１８】 サブスクリプションテーブルＳＴはしばしば変更されるので、高度にダイナミ
ックである。例えば新たな外勤社員が販売区域Ａに入ると、システムアドミニス
トレータはこの外勤社員ＸＹを新たな加入者として販売区域Ａに関連する変更の
ために挿入する。ここから生じるサブスクリプションテーブルＳＴの変更は図１
４、図１５のサブスクリプションチェックにより処理される。
【０１１９】 ステップ９０７〜９０９は処理されたＢＤｏｃのルックアップテーブルで必要
な更新を行うために用いられる。変更情報の宛先が不変のままであるかぎり、Ｌ
ＵＴの変更は必要ない。したがってまずステップ９０７で旧い宛先がＬＵＴから
読み出され、ステップ９０８で最新の宛先と旧い宛先との比較が行われ、付加さ
れた宛先すなわち新宛先ともはや最新ではない宛先すなわち旧宛先とが求められ
る。
【０１２０】 これに基づいてステップ９０９でＬＵＴの更新に必要な変更が検出される。た
だし更新はこの時点ではまだアクティブではない。つまり変更はまだ行われず、
フラグのセットによるマーキングのみが行われる。これは実際上重要な意味を有
している。特にアウトバウンドキューＯＢＱ内へ所定のノードシステムに対する
変更をセットしたのにもかかわらず、このノードシステムが当該の挿入のリプリ
ケーションオブジェクトの充填基本データをまだ有さないという事態を阻止しな
ければならないからである。前述の実施例に関連して云えば、顧客側の担当者の
変更を所定のラップトップコンピュータが顧客データそのものを得る前にこのラ
ップトップコンピュータへ伝達してしまうことを阻止しなければならない。
【０１２１】 図１０に示されているステップ９１０、９１１は必要な挿入オペレーションを
新宛先でトリガし、消去オペレーションを旧宛先でトリガするために用いられる
。このために必要な抽出ジョブが形成され（図１３を参照）、エクストラクタキ
ューＥＸＱ内へセットされる。このことはそれぞれ現時点で処理されているＢＤ
ｏｃおよび場合によりこれに依存するＢＤｏｃに関連している。
【０１２２】 現時点で処理されているＢＤｏｃに依存するＢＤｏｃの抽出ジョブの形成も、
ノードシステムＮＳの第１の充填データに必要な全ての情報が伝達されることを
保証するために必要となる。例えば新たな顧客のデータを担当の外勤社員へ伝達
する場合、新たな宛先ではその顧客のデータだけでなく別のデータ例えば担当者
やこの顧客に対する注文などのデータも受け取れなければならない。
【０１２３】 挿入オペレーションにより全ての新たな宛先が現時点で処理されているＢＤｏ
ｃインスタンスの全データ集合を獲得する。旧宛先ではこのＢＤｏｃインスタン
スの全てのデータが消去される。これにより当該のリプリケーションオブジェク
トの将来のデータ変更も新たな宛先へ伝達され、また旧宛先への伝達が回避され
るという前提が得られる。したがって新宛先および旧宛先がＯ‐ＬＵＴ内へ引き
渡され、それ以前には行われなかったＬＵＴの更新が今度はアクティブとなる。
これは有利には抽出ジョブを形成したのと同じコミットサイクル内で行われる。
【０１２４】 さらにステップ９１２では、固有の規則にしたがい、かつ付加的に上位のリプ
リケーションオブジェクトに依存して分配される従属性インテリジェント型ＢＤ
ｏｃの場合、ジョブシーケンスが形成され、リアライメントキュー内へセットさ
れる。この例として前述のリファレンシャルアサインメントのケースが挙げられ
る。例えば現時点で処理されているＢＤｏｃが前述の建築システムのケースの建
築家へのリンクを含む注文である場合、これに対して付加的なリアライメントジ
ョブが形成される。
【０１２５】 更なる問い合わせステップ９１３では、処理されるＢＤｏｃを付加的にインタ
ーリンケージを介して複製すべきか否かが検出される。複製すべき場合にはステ
ップ９１４でインターリンケージリアライメントが行われる。これは図１１、図
１２に則して詳細に説明する。インターリンケージリアライメントの終了後、ま
たは先行の問い合わせへの応答がノーであった場合、このサービスはステップ９
１５で終了される。
【０１２６】 図８の従属性リプリケーションによると例えば顧客とこの顧客について処理さ
れる注文との間の１：Ｎの関係しか処理できない。ただし実際にはＮ：Ｎの関係
のケースもしばしば発生する。例えば上述の建築システムにおいて、建築家が自
身の担当区域外に住所を有する“区域不明”の顧客の建物を担当するとする。こ
の建築家はリファレンシャルアサインメントを介して顧客データでなく建物すな
わち“注文”のデータを得る。顧客データはこの建築家には“注文”のＢＤｏｃ
内に設けられている顧客へのリンクによって獲得される。これが異なるＢＤｏｃ
タイプ（注文‐顧客）間のインターリンケージである。同じＢＤｏｃタイプの異
なるインスタンス間のリンクが設けられることも多く、これにより例えば変更情
報の分配に作用する種々の顧客間の関係が考慮される。
【０１２７】 この種のタスクはインターリンケージと称されるプログラムモジュールを介し
て解決される。ここではシステムの装置または後の時点で相応のリンクが定義さ
れていることを前提とする。リンクの定義は、例えば外勤社員がシステム内でい
ままでにまだ考慮されたことのない顧客間の関係を定める場合に、ノードシステ
ムＮＳのアプリケーションソフトウェアＡＳによって形成される。このような変
更情報もＢＤｏｃ内で符号化され、中央システムＣＳ内へ輸送され、そこで回帰
的に実行される。これにより相応のリンクが形成される。
【０１２８】 同種または異種のＢＤｏｃ間の全ての結合は有利にはコンソリデーティドデー
タベースＣＤ内にいわゆるインターリンケージテーブルとして記憶されている。
このテーブルではキーＧＵＩＤが相互に結合された全てのリプリケーションオブ
ジェクトに割り当てられている。この割り当ては有利には組として２列のテーブ
ルで示される。ＢＤｏｃは結合に関する情報を有利にはこの種のインターリンケ
ージテーブルへの指示により有する。
【０１２９】 このことはＢＤｏｃのＩＤ識別のために使用されるキーが全システムにわたっ
て一義的であることを前提としている。すなわち全データベースネットワークシ
ステムＤＢＮＳにわたって異なるリプリケーションオブジェクトのインスタンス
を複数回表すキーは存在しない。この前提条件はＧＵＩＤでももちろん満足され
る。
【０１３０】 図１１、図１２は図１０にフィールドとしてまとめられたステップ９１４を説
明するものである。プログラムモジュールの開始ステップ１１０１およびＢＤｏ
ｃの引き渡しステップ１１０２の後、最初にステップ１１０３でリンク、すなわ
ちコンソリデーティドデータベースＣＤ内のポインタにより相互に結合されてい
る全てのＢＤｏｃが１つのクラスタへまとめられる。具体的には相互にリンクを
介して結合されている全てのＢＤｏｃインスタンスのプライマリキーのリストが
形成される。これはタイプを超えて一義的なキー（例えばＧＵＩＤ）を使用する
ことにより可能となる。共通の処理はシステムのパフォーマンスにとって重要で
ある。タイプを超えるアルゴリズムでＢＤｏｃを処理することにより処理時間を
大幅に短縮することができる。
【０１３１】 もちろん、前述のようにリンクを介した全ての結合が１つのクラスタへまとめ
られる場合にのみ、つまりデータの分配に関する制限が例えば信頼性のために損
なわれない場合にのみ、このことは相当する。
【０１３２】 クラスタの全てのＢＤｏｃについて、図１１に示されているステップ１１０４
〜１１０８のｆｏｒループが動作する。ここで図９のステップ９０７、９０８と
同様に最新の宛先が求められ、旧い宛先と比較され、付加された新宛先ともはや
最新でない旧宛先とが求められる。ここでの最新の宛先の計算にはサブスクリプ
ションテーブルへ戻るアクセスを必要とせず、直接にＢＤｏｃのＬＵＴから読み
出しが行われる。なぜならこのアルゴリズムではアサインメントによる宛先の計
算は必要ないからである。
【０１３３】 続いてＬＵＴの更新がステップ１１０９で図９と同様に行われる。このステッ
プをクラスタの全てのＢＤｏｃについて先行のループの完全な処理後に行うこと
はパフォーマンスにとって重要である。
【０１３４】 図１２に示された必要な挿入オペレーションおよび消去オペレーションのトリ
ガのステップは図１０と同様に行われる。ただしステップ１１１０〜１１１６か
ら成る別のｆｏｒループにおいて、先行のループから修正された宛先が生じるク
ラスタの全てのＢＤｏｃを処理してもよい。
【０１３５】 リアライメントは計算時間コストの高い過程であるので、リアライメントキュ
ーＲＡＱ内に存在するジョブの並列処理を行うと有利である。これは許容される
が、１つのＢＤｏｃインスタンスに対するリアライメントジョブの処理が、この
リアライメントジョブをリプリケーションのフレームで形成したのと同じシーケ
ンスで行われることに留意しなければならない。換言すれば、リプリケーション
オブジェクトインスタンスのリアライメントジョブはつねにこのリプリケーショ
ンオブジェクトインスタンスが形成されたシーケンスで処理される。これにより
所定のＢＤｏｃインスタンスの全てのリアライメントジョブが同じリアライメン
トキュー内へセットされ、強制的な順次のプロセシングが保証される。
【０１３６】 前述したように、リアライメントモジュールＲＡはＬＵＴの更新だけでなくＬ
ＵＴの変更によって必要となった挿入オペレーションおよび消去オペレーション
をトリガするためにも用いられる。これらの変更オペレーションを実行するため
に、エクストラクタモジュールＥＸＴとは独立に非同期的に処理される抽出ジョ
ブが形成される。エクストラクタモジュールは挿入オペレーションまたは消去オ
ペレーションを関連するデータベース内で行うために用いられるＢＤｏｃを形成
する別の関連においても使用される。
【０１３７】 図１３に示されているフローチャートはエクストラクタモジュールに適したア
ルゴリズムを示している。モジュールの開始ステップ１３０１の後、ステップ１
３０２でジョブがエクストラクタキューＥＸＱからシーケンシャルな処理を保証
するキューリーダを介して引き渡される。抽出ジョブはＢＤｏｃの関連するプラ
イマリキーを含んでおり、このキーは挿入オペレーションまたは消去オペレーシ
ョンを行う１つまたは複数のノードシステムのアドレスすなわちサイトＩＤを含
んでいる。挿入オペレーションのステップ１３０４では、ＢＤｏｃのデータがコ
ンソリデーティドデータベースＣＤから読み出される。続いてステップ１３０５
で宛先のアドレスがＢＤｏｃヘッダＢＤｏｃ‐Ｈ内へアドレスリストＡＬへの指
示によりエントリされる。さらにステップ１３０６では抽出されたＢＤｏｃがフ
ローチ制御部ＦＣへ引き渡され、フローが開始される。ステップ１３０７はモジ
ュールの終了をマーキングしている。
【０１３８】 ＬＵＴの変更とこの変更に基づいて必要となる挿入オペレーションおよび消去
オペレーションとはノードシステムＮＳから伝達される変更情報から得られるだ
けではない。むしろ前述したように、システムアドミニストレータが管理ステー
ションＡＳを介して行う変更は、多くの場合に、データベースシステム内の情報
分配の変更をもたらす。特に、新たな外勤社員が加入し、そのラップトップコン
ピュータをデータベースネットワークシステムＤＢＮＳ内のノードシステムＮＳ
として接続しなければならない場合や、またはノードシステムＮＳと販売区域と
の対応関係に関する変更が生じる場合（例えば１つまたは複数の外勤社員別の販
売区域へ異動した場合）など、しばしばサブスクリプションテーブルＳＴの変更
が必要となる。
【０１３９】 この種の変更はサブスクリプションチェックモジュール［Subscription Check
er］と称されるプログラムモジュールを介してシステム内へもたらされる。図１
４、図１５には２種類のサブスクリプションチェックモジュールＳＣに対するア
ルゴリズムのフローチャートが示されている。このモジュールはＢＤｏｃのタイ
プに依存して使用される。図１４に示されているバルク型サブスクリプションチ
ェックモジュールは図６のバルク型リプリケーションによって複製されるＢＤｏ
ｃタイプに応じて使用され、図１４に示されているオブジェクト型サブスクリプ
ションチェックモジュールは図７のインテリジェント型リプリケーションによっ
て複製されるＢＤｏｃタイプに応じて使用される。
【０１４０】 バルク型サブスクリプションチェックモジュールの開始ステップ１４０１後、
ステップ１４０２で管理ステーションＡＳ内で形成されたバルク型サブスクリプ
ションジョブが引き渡される。このジョブはバルク型リプリケーションを介して
分配されたＢＤｏｃ（例えば製品基本データ）ごとに最新の状態に相当する全て
の宛先へのリンクを含む。ステップ１４０３ではバルクＬＵＴからそこに記録さ
れている相応のＢＤｏｃの宛先が読み出される。続いてステップ１４０４でバル
ク型サブスクリプションジョブに含まれるリンクを介して相応のサブスクリプシ
ョンがサブスクリプションテーブルＳＴから読み出される。ステップ１４０３、
１４０４で得られたデータを比較することにより、ステップ１４０５で新宛先と
もはや最新でない旧宛先とが求められる。次の問い合わせステップ１４０６で新
たな宛先が検出されたか否かについての応答がイエスであった場合、ステップ１
４０７でバルクＬＵＴに対する相応のエントリが形成され、エントリされる。さ
らにステップ１４０８で抽出ジョブが形成され、エクストラクタキューＥＸＱ内
へセットされる。これにより相応の挿入オペレーションの処理がトリガされる。
【０１４１】 相応に更なる問い合わせステップ１４０９で旧宛先が検出されたか否かについ
て応答がイエスであった場合、消去のメモが形成され、これによりバルクＬＵＴ
内の相応のエントリが消去される。この場合にもステップ１４１１で抽出ジョブ
が形成され、ノードシステム内の相応のデータが消去される。ステップ１４１２
はモジュールの終了をマーキングしている。
【０１４２】 図１５に示されているオブジェクト型サブスクリプションチェックモジュール
の開始ステップ１５０１の後、ステップ１５０２は管理ステーションＡＳで形成
されたオブジェクト型サブスクリプションジョブが引き渡される。このジョブは
分散上クリティカルなデータフィールドの相応の内容と当該の宛先との間の対応
関係を含んでいる。したがってこのジョブは例えば販売区域Ａを外勤社員１、３
、５、８が担当し、販売区域Ｂを外勤社員２、４、６、７が担当しているといっ
たデータを含む。
【０１４３】 次のステップ１５０３ではコンソリデーティドデータベースＣＤから当該の条
件を満足する全てのＢＤｏｃのキーが読み出される。すなわち、販売区域を表す
データフィールド内でエントリＡを有する全ての顧客データが読み出される。さ
らにステップ１５０４で全てのＢＤｏｃに対してリアライメントジョブが形成さ
れ、リアライメントキューＲＡＱがセットされる。これにより独立かつ非同期的
に図９〜図１２に則して説明したリアライメントモジュールが処理される。その
後モジュールはステップ１５０５で終了する。
【０１４４】 本発明によれば複数の観点で部分的に複製されるデータベースシステムを備え
たネットワークでのデータメンテナンスに結びついた問題を解決する特に有利な
手段が得られる。特に本発明によればきわめて多数の加入者数（１００００件以
上の加入者）を有するデータベースネットワークシステムの構成および動作につ
いて良好なパフォーマンスが得られ、きわめて柔軟かつ簡単にデータベースネッ
トワークシステムの各オペレータの要求へ適合させることができる。
【０１４５】 特徴的な要素は非同期的かつ相互に独立に動作するプログラムモジュールの共
働である。これらのモジュールはそれぞれ定義されたタスクを満足し、定義され
たインタフェースを介して相互に通信する。中心的な機能はルックアップテーブ
ルに基づいた複製であり、ルックアップテーブルからそのつどの時点で最新のリ
プリケーションオブジェクトの宛先がリプリケーションオブジェクト内で符号化
されている変更情報に基づく変更を考慮せずに読み出され、その際にデータのプ
ロセシングは必要ない。変更情報がネットワークシステム内の宛先への分配に関
する変更をもたらす場合、ルックアップテーブルは非同期的に実行されるリアラ
イメントプロセスにより適合化される。挿入および消去の関連する宛先への伝送
は同様にリアライメントのフレームで新宛先および旧宛先が検出された後に行わ
れる。
【図面の簡単な説明】
【図１】 本発明のデータベースネットワークシステムのアーキテクチャの主要な要素の
概略図である。
【図２】 本発明の範囲で使用されるリプリケーションオブジェクトＢＤｏｃのストラク
チャを示す図である。
【図３】 ローカルで得られる変更情報を処理するプログラムモジュールのフローチャー
トである。
【図４】 ノードシステムと中央システムとの間に一時的なコネクションを形成して監視
するコネクションマネージャのフローチャートである。
【図５】 フロー制御による中央システム内のリプリケーションオブジェクトを処理する
際のフローチャートである。
【図６】 バルク型リプリケーションのフローチャートである。
【図７】 インテリジェント型リプリケーションのフローチャートである。
【図８】 従属性リプリケーションのフローチャートである。
【図９】 リアライメントプログラムモジュールのフローチャートの第１の部分である。
【図１０】 図９のフローチャートの続きの部分である。
【図１１】 図１０のインターリンクリアライメントを実行するプログラムモジュールのフ
ローチャートの第１の部分である。
【図１２】 図１１のフローチャートの続きの部分である。
【図１３】 エクストラクタプログラムモジュールのフローチャートである。
【図１４】 バルクサブスクリプションチェックモジュールのフローチャートである。
【図１５】 オブジェクトサブスクリプションチェックモジュールのフローチャートである
。
───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ， ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ， ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，Ｃ Ｒ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＥＥ，ＥＳ，ＦＩ ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ， ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，Ｋ Ｚ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ， ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，Ｓ Ｋ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ Ｆターム(参考） 5B045 DD15 DD18 5B082 GA14 GB02 GB04 GB06 【要約の続き】 クアップテーブル（ＬＵＴ）を介して伝達相手先のノー ドシステム（ＮＳ）に宛先として割り当てられ、少なく とも１つのルックアップテーブルが変更情報を考慮して リアライメントアルゴリズムにより更新される。

Claims (24)

    【特許請求の範囲】
  1. 【請求項１】 中央データベース（ＳＣ）を備えた中央システム（ＣＳ）と
    ローカルデータベース（ＬＤ）を備えた複数のノードシステム（ＮＳ）とを有す
    る オフライン分散型データベースネットワークシステム（ＤＢＮＳ）におけるデー
    タメンテナンス方法において、 ローカルデータベース（ＬＤ）は少なくとも部分的に異なる中央データベース
    （ＳＣ）のデータの部分集合を含んでおり、 データベースネットワークシステム（ＤＢＮＳ）のデータベース（ＣＤ、ＬＤ
    ）に記憶されているデータに対する変更情報を複数のノードシステム（ＮＳ）で
    登録し、 該変更情報をオンラインコネクションが形成されている場合に複数の異なるタ
    イプで構造化されたＩＤキーを含むリプリケーションオブジェクトとしてノード
    システムから中央システムへ伝送するかまたは中央システムからノードシステム
    へ伝送し、オンラインコネクションが存在しない場合にはリプリケーションオブ
    ジェクトを後の伝送のために出力列内で調製し、 変更情報をともなうリプリケーションオブジェクトを中央システム（ＣＳ）内
    でリプリケーションアルゴリズムにより少なくとも１つのルックアップテーブル
    （ＬＵＴ）を介して伝達相手先のノードシステム（ＮＳ）に宛先として割り当て
    、 少なくとも１つのルックアップテーブルを変更情報を考慮してリアライメント
    アルゴリズムにより更新する、 ことを特徴とするオフライン分散型データベースネットワークシステムにおける
    データメンテナンス方法。
  2. 【請求項２】 リプリケーションオブジェクトによりデータベースネットワ
    ークシステム（ＤＢＮＳ）のデータベース（ＣＤ、ＬＤ）間で公開されている全
    データ集合の解析を形成する、請求項１記載の方法。
  3. 【請求項３】 リプリケーションオブジェクトはタイプのＩＤと、リプリケ
    ーションオブジェクトで符号化された変更情報に相応するデータベースオペレー
    ションすなわち更新、挿入または消去のＩＤとを含む、請求項１または２記載の
    方法。
  4. 【請求項４】 リプリケーションオブジェクトの中央システム（ＣＳ）での
    処理をフロー制御部（ＦＣ）によりリプリケーションオブジェクトのタイプごと
    に固有のフロー定義（ＦＤ）にしたがって制御する、請求項１から３までのいず
    れか１項記載の方法。
  5. 【請求項５】 変更情報を中央システム（ＣＳ）からノードシステム（ＮＳ
    ）へ伝送するためにリモートコール（ｑＲＦＣ）を使用し、出力列に存在してい
    る複数のコールに必要な共通のデータが一度だけ記憶されるように前記リモート
    コールを構成する、請求項１から４までのいずれか１項記載の方法。
  6. 【請求項６】 少なくとも２つのタイプのルックアップテーブルを使用し、
    そのうち第１のタイプ（Ｂ‐ＬＵＴ）はリプリケーションオブジェクトと宛先と
    の対応関係を含み、第２のタイプ（Ｏ‐ＬＵＴ）はリプリケーションオブジェク
    トのインスタンスと宛先との対応関係を含む、請求項１から５までのいずれか１
    項記載の方法。
  7. 【請求項７】 複数の第２のタイプのルックアップテーブル（Ｏ‐ＬＵＴ）
    を使用し、該ルックアップテーブルはそれぞれリプリケーションオブジェクトの
    タイプのインスタンスとインスタンスの宛先との対応関係を含む、請求項６記載
    の方法。
  8. 【請求項８】 リプリケーションオブジェクトのタイプに依存して異なるタ
    イプのリプリケーションアルゴリズムを実行し、 第１のタイプのリプリケーションアルゴリズム（バルク型リプリケーション）
    によりリプリケーションオブジェクトの所定の部分集合をそのタイプに依存して
    第１のタイプのルックアップテーブル（Ｂ‐ＬＵＴ）を使用して宛先に割り当て
    、 第２のタイプのリプリケーションアルゴリズム（インテリジェント型リプリケ
    ーション）によりリプリケーションオブジェクトの第１の部分集合とは重ならな
    い所定の部分集合をそのインスタンスに依存して第２のタイプのルックアップテ
    ーブル（Ｏ‐ＬＵＴ）を使用して宛先に割り当てる、 請求項６または７記載の方法。
  9. 【請求項９】 第３のタイプのリプリケーションアルゴリズム（従属性リプ
    リケーション）によりリプリケーションオブジェクトの第１の部分集合および第
    ２の部分集合とは重ならない第３の所定の部分集合を上位のリプリケーションオ
    ブジェクトに対して第２のタイプのルックアップテーブル（Ｏ‐ＬＵＴ）にエン
    トリされた対応関係に依存して宛先に割り当てる、請求項８記載の方法。
  10. 【請求項１０】 リアライメントアルゴリズムをリプリケーションアルゴリ
    ズムから独立に、かつ該アルゴリズムに対して非同期に実行する、請求項１から
    ９までのいずれか１項記載の方法。
  11. 【請求項１１】 リプリケーションアルゴリズムでは、処理されるリプリケ
    ーションオブジェクトで符号化された変更情報に相応するデータベースオペレー
    ションが挿入［Insert］または消去［Delete］である場合に、データベースオペ
    レーションのＩＤの問い合わせ（７０３）に基づいてリアライメントアルゴリズ
    ムに対するジョブを形成する、請求項３から１０までのいずれか１項記載の方法
    。
  12. 【請求項１２】 リプリケーションアルゴリズムでは、処理されるリプリケ
    ーションオブジェクトで符号化された変更情報に相応するデータベースオペレー
    ションが更新［Update］でありかつ少なくとも１つの所定のリプリケーションオ
    ブジェクトの分散上クリティカルなデータフィールド内のデータが変更されてい
    る場合に、データベースオペレーションのＩＤの問い合わせ（７０３、７０６）
    に基づいてリアライメントアルゴリズムに対するジョブを形成する、請求項３か
    ら１０までのいずれか１項記載の方法。
  13. 【請求項１３】 データベースオペレーションのＩＤの問い合わせ（７０３
    ）を第２のタイプのリプリケーションアルゴリズム（インテリジェント型リプリ
    ケーション）の動作中に行う、請求項８、１１、１２のうちいずれか１項記載の
    方法。
  14. 【請求項１４】 リアライメントアルゴリズムで分散上クリティカルなデー
    タフィールドの内容とサブスクリプションテーブル（ＳＴ）に定められている分
    配規則とを比較し、この比較に基づいてルックアップテーブル（Ｏ‐ＬＵＴ）を
    更新する、請求項１０から１３までのいずれか１項記載の方法。
  15. 【請求項１５】 リアライメントアルゴリズムでリプリケーションオブジェ
    クトのルックアップテーブル（Ｏ‐ＬＵＴ）を上位のリプリケーションオブジェ
    クトのルックアップテーブル（ＳＲＯ‐ＬＵＴ）を考慮して更新する、請求項１
    ０から１４までのいずれか１項記載の方法。
  16. 【請求項１６】 リアライメントアルゴリズムでまず最初にリプリケーショ
    ンオブジェクトで符号化された全ての変更情報を考慮して最新の宛先を定め、該
    宛先とルックアップテーブル（Ｏ‐ＬＵＴ）内に示されている宛先とを比較し、
    付加された新宛先ともはや最新でない旧宛先とを求め、新宛先および旧宛先に関
    する情報を調製してルックアップテーブル（Ｏ‐ＬＵＴ）へ引き渡す、請求項１
    ０から１５までのいずれか１項記載の方法。
  17. 【請求項１７】 リアライメントアルゴリズムで新宛先および旧宛先を求め
    た後、必要となった新宛先での挿入オペレーションと旧宛先での消去オペレーシ
    ョンとを開始し、これにより新宛先へリアライメントアルゴリズムで処理された
    リプリケーションオブジェクトの完全なデータ内容を伝達し、またリプリケーシ
    ョンオブジェクトに相応するデータ内容を旧宛先のデータベース内で消去する、
    請求項１６記載の方法。
  18. 【請求項１８】 必要となった挿入オペレーションまたは消去オペレーショ
    ンをリアライメントアルゴリズムから独立にかつ該アルゴリズムに対して非同期
    に動作する個別の抽出アルゴリズムにより開始し、該抽出アルゴリズムとしてリ
    プリケーションオブジェクトを形成し、該オブジェクトを挿入オペレーションの
    実行のために新宛先へ伝達するか消去オペレーションの実行のために旧宛先へ伝
    達する、請求項１７記載の方法。
  19. 【請求項１９】 必要となった挿入オペレーションまたは消去オペレーショ
    ンの実行が保証された後、最初にリプリケーションアルゴリズムにおいて変更さ
    れたルックアップテーブルへのアクセスが行われるまでに、新宛先および旧宛先
    をルックアップテーブル（ＬＵＴ）へ引き渡す、請求項１７または１８記載の方
    法。
  20. 【請求項２０】 リプリケーションオブジェクトで符号化されている他のリ
    プリケーションオブジェクトへのリンクを考慮するためにリアライメントアルゴ
    リズムで相互に結合されたリプリケーションオブジェクトのクラスタを形成し、 該クラスタに対してｆｏｒループでまず最初にリプリケーションオブジェクト
    で符号化された全ての変更情報を考慮して最新の宛先を求め、 該最新の宛先とルックアップテーブル（Ｏ‐ＬＵＴ）内に示されている宛先と
    を比較し、付加された新宛先ともはや最新でない旧宛先とを求め、 新宛先および旧宛先に関する情報をクラスタ内の全てのリプリケーションオブ
    ジェクトに対してｆｏｒループの終了後に調製してルックアップテーブル（Ｏ‐
    ＬＵＴ）へ引き渡す、 請求項１から１９までのいずれか１項記載の方法。
  21. 【請求項２１】 リプリケーションオブジェクトを全データベースネットワ
    ークシステムにわたって一義的なキーによりＩＤ識別する、請求項１から２０ま
    でのいずれか１項記載の方法。
  22. 【請求項２２】 直接にディジタルコンピュータのメモリ内にローディング
    可能であり、 コンピュータ上で動作する際に請求項１から２０までのいずれか１項記載のオ
    フライン分散型データベースネットワークシステムにおけるデータメンテナンス
    方法のステップを実行するソフトウェアコード部を含む、 ことを特徴とするコンピュータプログラム製品。
  23. 【請求項２３】 請求項２２記載のコンピュータプログラム製品を備えてい
    ることを特徴とするコンピュータに適した記憶媒体。
  24. 【請求項２４】 請求項２２記載のコンピュータプログラム製品を含むこと
    を特徴とするデータベースネットワークシステム。
JP2001505305A 1999-06-18 2000-05-13 部分的に複製されるデータベースシステムのネットワークにおけるデータメンテナンス方法 Pending JP2003520363A (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
DE19928035 1999-06-18
DE19928035.5 1999-06-18
EP99120009A EP1093061A1 (de) 1999-10-14 1999-10-14 Integriertes Datenbank-Verbundsystem
EP99120009.8 1999-10-14
PCT/DE2000/001552 WO2000079408A2 (de) 1999-06-18 2000-05-13 Verfahren zur datenpflege in einem netzwerk teilweise replizierter datenbanksysteme

Publications (2)

Publication Number Publication Date
JP2003520363A true JP2003520363A (ja) 2003-07-02
JP2003520363A5 JP2003520363A5 (ja) 2004-12-24

Family

ID=26053845

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2001505305A Pending JP2003520363A (ja) 1999-06-18 2000-05-13 部分的に複製されるデータベースシステムのネットワークにおけるデータメンテナンス方法

Country Status (10)

Country Link
US (2) US6910053B1 (ja)
EP (1) EP1194865B1 (ja)
JP (1) JP2003520363A (ja)
AT (1) ATE246822T1 (ja)
AU (1) AU763807B2 (ja)
CA (1) CA2375395C (ja)
DE (1) DE50003207D1 (ja)
DK (1) DK1194865T3 (ja)
IL (2) IL147105A0 (ja)
WO (1) WO2000079408A2 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006277450A (ja) * 2005-03-30 2006-10-12 Daiwa Securities Group Inc 情報管理システム、情報管理方法およびプログラム
JP2009230276A (ja) * 2008-03-19 2009-10-08 Nomura Research Institute Ltd 情報処理システム

Families Citing this family (67)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6948115B2 (en) * 2000-02-03 2005-09-20 Xmpie Inc. System and method for efficient production of dynamic documents
US20050229003A1 (en) 2004-04-09 2005-10-13 Miles Paschini System and method for distributing personal identification numbers over a computer network
US7676030B2 (en) 2002-12-10 2010-03-09 Ewi Holdings, Inc. System and method for personal identification number distribution and delivery
US20030056207A1 (en) 2001-06-06 2003-03-20 Claudius Fischer Process for deploying software from a central computer system to remotely located devices
DE10209794A1 (de) * 2002-03-06 2003-09-25 Ape Ptacek Engineering Gmbh Datenkommunikationssystem
US8589346B2 (en) * 2011-04-26 2013-11-19 Oracle International Corporation Techniques for combining statement level, procedural, and row level replication
US7464097B2 (en) 2002-08-16 2008-12-09 Sap Ag Managing data integrity using a filter condition
US7127475B2 (en) 2002-08-15 2006-10-24 Sap Aktiengesellschaft Managing data integrity
US7225425B2 (en) 2002-08-29 2007-05-29 Sap Aktiengesellschaft Rapid application integration
US7171432B2 (en) 2002-08-29 2007-01-30 Sap Aktiengesellschaft Phased upgrade of a computing environment
US7257818B2 (en) 2002-08-29 2007-08-14 Sap Aktiengesellschaft Rapid application integration using functional atoms
US7269665B2 (en) 2002-08-29 2007-09-11 Sap Ag Isolated mapping point
US7263698B2 (en) 2002-08-29 2007-08-28 Sap Aktiengesellschaft Phased upgrade of a computing environment
US7213227B2 (en) 2002-08-29 2007-05-01 Sap Aktiengesellschaft Rapid application integration using an integrated development environment
US7237225B2 (en) 2002-08-29 2007-06-26 Sap Aktiengesellschaft Rapid application integration using reusable patterns
US7277940B2 (en) 2002-08-29 2007-10-02 Sap Ag Managing uneven authorizations in a computer data exchange
US10205721B2 (en) * 2002-12-10 2019-02-12 Ewi Holdings, Inc. System and method for distributing personal identification numbers over a computer network
US7131578B2 (en) 2003-05-28 2006-11-07 Ewi Holdings, Inc. System and method for electronic prepaid account replenishment
US7860727B2 (en) 2003-07-17 2010-12-28 Ventana Medical Systems, Inc. Laboratory instrumentation information management and control network
US8719053B2 (en) * 2003-07-17 2014-05-06 Ventana Medical Systems, Inc. Laboratory instrumentation information management and control network
US8010607B2 (en) * 2003-08-21 2011-08-30 Nortel Networks Limited Management of queues in contact centres
US7500020B1 (en) * 2003-12-31 2009-03-03 Symantec Operating Corporation Coherency of replicas for a distributed file sharing system
US7280644B2 (en) 2004-12-07 2007-10-09 Ewi Holdings, Inc. Transaction processing platform for faciliating electronic distribution of plural prepaid services
US11475436B2 (en) 2010-01-08 2022-10-18 Blackhawk Network, Inc. System and method for providing a security code
US11599873B2 (en) 2010-01-08 2023-03-07 Blackhawk Network, Inc. Systems and methods for proxy card and/or wallet redemption card transactions
US7707432B2 (en) 2004-08-13 2010-04-27 Sap Ag Enabling communication between an application program and services used by the application program
US20060045244A1 (en) * 2004-08-24 2006-03-02 Darren New Method and apparatus for receipt printing and information display in a personal identification number delivery system
US8244913B1 (en) * 2004-10-13 2012-08-14 Progress Software Corporation Replication horizon determination with an independent distributed database system
US7761396B2 (en) 2004-10-14 2010-07-20 Sap Ag Apparatus and product of manufacture for adaptive business transaction rule structures
US7756808B2 (en) 2004-10-14 2010-07-13 Sap Ag Apparatus and product of manufacture for using condition data structures separately from rule data structures in business transactions
US7756809B2 (en) 2004-10-14 2010-07-13 Sap Ag Apparatus and product of manufacture using execution points to select conditions and rules for business transaction processing
US7457794B2 (en) 2004-10-14 2008-11-25 Sap Ag Searching for customized processing rules for a computer application
US7457793B2 (en) 2004-10-14 2008-11-25 Sap Ag Investigating execution of a customized transaction process in a computer application
US7457792B2 (en) 2004-10-14 2008-11-25 Sap Ag Customizing transaction processing in a computer application by using pre-defined functions
EP1684218A1 (en) * 2004-12-30 2006-07-26 Sap Ag System for modelling a process
US7461091B2 (en) 2005-06-09 2008-12-02 Sap Aktiengesellschaft Controlling data transition between business processes in a computer application
US7647335B1 (en) 2005-08-30 2010-01-12 ATA SpA - Advanced Technology Assessment Computing system and methods for distributed generation and storage of complex relational data
US7823170B2 (en) * 2005-08-31 2010-10-26 Sap Ag Queued asynchronous remote function call dependency management
US8533169B1 (en) 2005-09-21 2013-09-10 Infoblox Inc. Transactional replication
US8290910B2 (en) * 2005-09-21 2012-10-16 Infoblox Inc. Semantic replication
US8250030B2 (en) 2005-09-21 2012-08-21 Infoblox Inc. Provisional authority in a distributed database
US20070297458A1 (en) * 2006-06-27 2007-12-27 Microsoft Corporation Efficient and layered synchronization protocol for database systems
US10296895B2 (en) 2010-01-08 2019-05-21 Blackhawk Network, Inc. System for processing, activating and redeeming value added prepaid cards
US7979390B2 (en) * 2006-10-27 2011-07-12 Purdue Pharma L.P. Software, systems, and methodologies for realignment of remote databases by a central database in support field representative territory assignments
US8694673B2 (en) * 2007-06-26 2014-04-08 Verizon Patent And Licensing Inc. Systems and methods for host identification
US9401957B2 (en) * 2007-09-14 2016-07-26 International Business Machines Corporation System and method for synchronization between servers
US8311987B2 (en) * 2009-08-17 2012-11-13 Sap Ag Data staging system and method
US10037526B2 (en) 2010-01-08 2018-07-31 Blackhawk Network, Inc. System for payment via electronic wallet
US9852414B2 (en) 2010-01-08 2017-12-26 Blackhawk Network, Inc. System for processing, activating and redeeming value added prepaid cards
KR101903963B1 (ko) 2010-08-27 2018-10-05 블랙호크 네트워크, 아이엔씨. 저축 특징을 갖는 선불 카드
US8612405B1 (en) * 2011-09-30 2013-12-17 Emc Corporation System and method of dynamic data object upgrades
US9164751B2 (en) 2011-09-30 2015-10-20 Emc Corporation System and method of rolling upgrades of data traits
CN104520886A (zh) * 2012-03-31 2015-04-15 环联公司 用于基于离线、在线及信用相关数据的目标因特网营销的系统及方法
US11042870B2 (en) 2012-04-04 2021-06-22 Blackhawk Network, Inc. System and method for using intelligent codes to add a stored-value card to an electronic wallet
US8739124B2 (en) 2012-06-27 2014-05-27 Sap Ag Configuring integration capabilities for system integration
US10970714B2 (en) 2012-11-20 2021-04-06 Blackhawk Network, Inc. System and method for using intelligent codes in conjunction with stored-value cards
US9773048B2 (en) 2013-09-12 2017-09-26 Sap Se Historical data for in memory data warehouse
US9734221B2 (en) 2013-09-12 2017-08-15 Sap Se In memory database warehouse
US9734230B2 (en) 2013-09-12 2017-08-15 Sap Se Cross system analytics for in memory data warehouse
US9699023B2 (en) * 2014-07-18 2017-07-04 Fujitsu Limited Initializing a network interface based on stored data
US9965328B2 (en) 2015-09-23 2018-05-08 International Business Machines Corporation Selective and piecemeal data loading for computing efficiency
CN105550347B (zh) * 2015-12-25 2020-07-14 网易（杭州）网络有限公司 数据处理方法及装置
CN106126634B (zh) * 2016-06-22 2019-11-05 武汉斗鱼网络科技有限公司 一种基于直播行业的主数据去重处理方法及系统
US10235530B2 (en) 2016-06-30 2019-03-19 International Business Machines Corporation Protecting sensitive information when replicating data to remote systems
US10902015B2 (en) 2017-01-19 2021-01-26 International Business Machines Corporation Parallel replication of data table partition
US11089106B2 (en) * 2018-12-06 2021-08-10 Ge Aviation Systems Llc Aircraft monitoring system and method of collecting data in an aircraft
US11231873B2 (en) * 2018-12-07 2022-01-25 Intel Corporation Apparatus and method for assigning velocities to write data

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6345288B1 (en) * 1989-08-31 2002-02-05 Onename Corporation Computer-based communication system and method using metadata defining a control-structure
US5873096A (en) 1997-10-08 1999-02-16 Siebel Systems, Inc. Method of maintaining a network of partially replicated database system
US5852715A (en) * 1996-03-19 1998-12-22 Emc Corporation System for currently updating database by one host and reading the database by different host for the purpose of implementing decision support functions
US5870765A (en) 1996-10-09 1999-02-09 Oracle Corporation Database synchronizer
US6446092B1 (en) * 1996-11-01 2002-09-03 Peerdirect Company Independent distributed database system
US6604127B2 (en) * 1998-03-20 2003-08-05 Brian T. Murphy Dynamic lookup service in distributed system
US6092189A (en) * 1998-04-30 2000-07-18 Compaq Computer Corporation Channel configuration program server architecture
US6256634B1 (en) * 1998-06-30 2001-07-03 Microsoft Corporation Method and system for purging tombstones for deleted data items in a replicated database
US6591272B1 (en) * 1999-02-25 2003-07-08 Tricoron Networks, Inc. Method and apparatus to make and transmit objects from a database on a server computer to a client computer
US6438538B1 (en) * 1999-10-07 2002-08-20 International Business Machines Corporation Data replication in data warehousing scenarios
US6615223B1 (en) * 2000-02-29 2003-09-02 Oracle International Corporation Method and system for data replication
US6574617B1 (en) * 2000-06-19 2003-06-03 International Business Machines Corporation System and method for selective replication of databases within a workflow, enterprise, and mail-enabled web application server and platform
US6442552B1 (en) * 2000-06-30 2002-08-27 Hewlett-Packard Company Method and apparatus for implementing three tier client asynchronous transparency
WO2002079993A1 (en) * 2001-03-29 2002-10-10 Reallegal.Com Methods for synchronizing on-line and off-line transcript projects
US7613806B2 (en) * 2001-06-28 2009-11-03 Emc Corporation System and method for managing replication sets of data distributed over one or more computer systems
US6978282B1 (en) * 2001-09-04 2005-12-20 Emc Corporation Information replication system having automated replication storage
US7032089B1 (en) * 2003-06-09 2006-04-18 Veritas Operating Corporation Replica synchronization using copy-on-read technique

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006277450A (ja) * 2005-03-30 2006-10-12 Daiwa Securities Group Inc 情報管理システム、情報管理方法およびプログラム
JP2009230276A (ja) * 2008-03-19 2009-10-08 Nomura Research Institute Ltd 情報処理システム

Also Published As

Publication number Publication date
AU5521200A (en) 2001-01-09
IL147105A (en) 2007-07-24
WO2000079408A2 (de) 2000-12-28
US20050203946A1 (en) 2005-09-15
EP1194865B1 (de) 2003-08-06
DE50003207D1 (de) 2003-09-11
EP1194865A2 (de) 2002-04-10
DK1194865T3 (da) 2003-11-10
CA2375395C (en) 2008-04-15
US7587432B2 (en) 2009-09-08
IL147105A0 (en) 2002-08-14
WO2000079408A3 (de) 2001-08-16
CA2375395A1 (en) 2000-12-28
US6910053B1 (en) 2005-06-21
AU763807B2 (en) 2003-07-31
ATE246822T1 (de) 2003-08-15

Similar Documents

Publication Publication Date Title
JP2003520363A (ja) 部分的に複製されるデータベースシステムのネットワークにおけるデータメンテナンス方法
JP3887564B2 (ja) 統合型データベース結合システム
US7792794B2 (en) N-way synchronization of computer databases
US8005710B2 (en) Methods and systems for caching and synchronizing project data
US6920456B2 (en) Method, system, and program for maintaining information in database tables and performing operations on data in the database tables
EP1681634A1 (en) Method and system for tracking changes in a document
US20140258232A1 (en) System and method for performing replica copying using a physical copy mechanism
US20030105654A1 (en) Workflow management based on an integrated view of resource identity
JP2007502464A (ja) データベースの自動的および動的な提供
JP2003522344A (ja) データベース同期化／組織化システムおよび方法
CA2348889A1 (en) Apparatus and system for an adaptive data management architecture
KR100529661B1 (ko) 오브젝트 통합 관리 시스템
US7571443B2 (en) Collaboration apparatus between information processing systems, integrated information processing system, and recording medium storing a collaboration program between information processing systems
CN114866416A (zh) 一种多集群统一管理系统及部署方法
CN101968747B (zh) 一种机群应用管理系统及其应用管理方法
US7035859B2 (en) Method and system for intra-table referential integrity for relational database systems
JP3296570B2 (ja) ファイル転送方法
JPH06290098A (ja) 分散データベース処理方法
JPS63186339A (ja) 遠隔資源保守方式
JP2000259466A (ja) データベースアクセス方法
JPH0388527A (ja) パーソナルコンピュータ用ローカルエリアネットワーク
JPH0488533A (ja) 分散情報処理方式

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20060120

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20060417

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20060424

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20060720

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20060816

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20061213

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20061220

A912 Re-examination (zenchi) completed and case transferred to appeal board

Free format text: JAPANESE INTERMEDIATE CODE: A912

Effective date: 20070112