JP2002511164A

JP2002511164A - 単純化された可視度ルールに用いるための複数のデータベース・トランザクションのリモート・データベース・クライアントの可視度決定方法

Info

Publication number: JP2002511164A
Application number: JP53783098A
Authority: JP
Inventors: エス．ブロダーセン，ロバート; エス．リム，ピーター
Original assignee: シーベルシステムズ，インコーポレイティド
Priority date: 1997-02-26
Filing date: 1998-02-24
Publication date: 2002-04-09
Also published as: AU6668398A; US6178425B1; EP1021775A1; EP1021775A4; WO1998038586A1

Abstract

(57)【要約】中央データベース（１）及び複数の部分的複製データベース（２１−ａ，２１−ｂ，２１−ｃ）のためのデータベース管理方法及びシステム。データベース管理（９）方法及びシステムは、中央の場所に保存された１セットの可視度ルールによって、中央データベースに対して別個の複製データベースのユーザの可視度を決定する。

Description

【発明の詳細な説明】単純化された可視度ルールに用いるための複数のデータベース・トランザクションのリモート・データベース・クライアントの可視度決定方法序論Ｉ．技術分野本発明は、部分的に複製したリレーショナル・データベース・システムのネットワークをアップデートするためのシステムおよび方法に関し、より詳しくは、データベースに対して処理するトランザクションのネットワーク上のクライアントに対する可視度を計算する効率的方法の提供に関する。 II．背景リレーショナル・データベースは、ビジネスその他の環境でデータを表すために広く用いられるデータ構造である。リレーショナル・データベースは、２次元の表の集合の形式でデータを表す。各テーブルは、行と列からなる一連のセルから構成される。一般に、表の行は特定の観測を表す。列は、データフィールドまたは別の表の行へのポインターを表す。例えば、組織構造を表すデータベースは、組織各地位を記述するのに１つの表を持ち、組織の各従業員を記述するのにもう１つの表を持つことができる。従業員表には、氏名、従業員番号、年齢、給与等の従業員固有の情報を入れることができる。地位表には、肩書き（「販売員」、「副社長」等）、給与範囲等、地位固有の情報を入れることができる。この表は、例えば、従業員表の各行に地位表の特定の行へのポインターを備えて、従業員表の各行にその従業員の地位を記述する地位表中の特定行へのポインターがあるように調整して関連づけることができる。リレーショナル・データベース管理システム（ＲＤＢＭＳ）は、ユーザからの照会に対応したこれらの表の「結合」をサポートし、例えば特定の従業員について照会を行うユーザが、従業員表の情報だけでなく、関連する地位表の情報も含めて選択した従業員の報告を与えられるようにする。リレーショナル・データベースは、この例よりはるかに複雑で、複数の表とそれらの間の多数の関係を持つ。安価でポータブルなコンピュータの利用の普及により、中央コンピュータから離れた場所でポータブルコンピュータにデータベースを複製して参照することが有利である。そして複製したデータベースを、ポータブルコンピュータのユーザにとっては不便な中央位置に保持されたメイン・データベースを参照する必要なく、ユーザがポータブルコンピュータで参照することができる。ただし、複製されたデータベースの利用には、多数の難点がある。短所の１つは、中央データベースのフルコピーには、望ましい、あるいは経済的と言える以上のデータ保存が必要となることである。例えば、現場で働く販売員は、自分の販売地域の販売機会に関する情報についてデータベースを参照する必要があるが、自分の地域外の販売機会に関する情報を参照する必要はない。必要なデータ保存量を少なくするアプローチの１つに、ユーザが必要とするデータベース部分のみ複製するというものがある。ただし、このアプローチでは、データのどの部分が必要かを決定する基準は時と共に変化するということを認識していない。例えば、販売員は自分のテリトリーに新しい都市を追加するかもしれない。従来のアプローチでは、この場合、販売員は、追加した都市を含むデータを選択して、データベースの自分のローカルコピーを再複製する必要がある。このような操作は不便で、エラーを生じやすく、時間がかかる。複製データベースのもう１つの短所は、複製したコピーを使ってデータをアップデートしようとする時の困難さである。複製データベースに行った変更は中央データベースには行われず、データベースの複製コピーに保存された情報と中央データベースに保存された情報との間に不一致が生じることになる。複製コピーの修正をジャーナルして、中央データベースに同じ修正を行うことはできるが、このアプローチの持つ問題に、アップデートの衝突、即ち、複製コピーのユーザが、中央コピーのユーザまたは別の複製コピーのユーザが変更したデータを変更してしまう可能性がある。そのため、複製データベース全体のリフレッシュの必要なく複製の程度を容易に変更でき、中央データベースのユーザと部分的複製データベースのユーザとの間でアップデートの調整をできるように、中央データベースの部分的に複製した１つ以上のコピーを保持する機能を持たせるのが望ましい。発明の概要本発明は、中央データベース、または別の部分的複製データベースのアップデートを、選択的に部分的複製データベースに伝播させるよう、部分的複製データベースを保持する方法に関する。部分的複製データベースの所有者がアップデート中のデータに対する可視度を持っているとみなされる場合、アップデートは部分的複製データベースに伝播される。可視度は、ルールデータベースに保存されたダイナミックルールまたはあらかじめ決められたルールなどの、ルールを使って決定される。本発明の１態様では、保存したルールは、アップデートしており、ドッキング・オブジェクト（docking object）として知られるロジカル・エンティティ（logical entity ）を作成する各種テーブルのデータ・コンテンツに対して評価される。本発明の別の態様では、保存したルールは、必ずしもアップデートされないが、アップデートしているドッキング・オブジェクトに関連する１つ以上のドッキング・オブジェクトのデータ・コンテンツに対して評価される。ある実施例では、関連するドッキング・オブジェクトの可視度の属性は繰り返し判断される。本発明のさらに別の態様では、中央コンピュータがドッキング・オブジェクトをその部分的複製データベースに挿入するようノード（node）に指示できるように可視度の変更が決定される。このような可視度の変更は、中央コンピュータがその部分的複製データベースからドッキング・オブジェクトを除去するようノードに指示できるようにするために決定される。本発明のさらに別の態様では、あらかじめ決められたルールは、宣言形式で、データ・コンテンツを参照せずにデータの構造に基づいてデータの可視度を指定する。本発明のさらに別の態様では、データベースに行うトランザクション(transac tion)は、トランザクションの可視度の計算に必要な計算リソースを削減するよう順序づけて処理される。本発明のさらに別の態様では、データベースに行うトランザクションは、トランザクションの可視度の計算に必要な計算リソースを削減するよう、キャッシュを使って順序づけて処理される。本発明のさらに別の態様では、データベースのオブジェクトとトランザクションは、あるオブジェクに対するトランザクションの可視度を決定するために用いる関連可視度強度を有する。本発明のさらに別の態様では、可視度の計算は、中央ディクショナリーにある簡易化したルールセットを使って実行する。図面の簡単な説明図１は、本発明の実施例の動作の概観を示す。図２は、ドッキング・オブジェクトを作る各種コンポーネントの関係を示すデータベース・スキーマ（schema）を示す。図３は、データベースをアップデートするアップデート・マネージャが実行するステップを示す。図４は、１つ以上のトランザクション・ログ（logs）を転送および/または受けるドッキング・マネージャが実行するステップを示す。図５は、既存データベースにトランザクション・ログ記録をマージするためマージ・プロセッサが実行するステップを示す。図６は、部分的トランザクション・ログを準備するためログマネージャ(log m anager)が実行するステップを示す。図７は、ログ・マネージャが呼び出すドッキング・オブジェクトの可視度を計算するため、可視度計算機が実行するステップを示す。図８は、データ可視度の変更に応答して部分的複製データベースの同期を実行するステップを示す。図９は、トランザクション・ログ・テーブルのデータベース設計の構造を示す。図１０は、中央ディクショナリーのデータベース図を示す。特定の実施例の説明概観図１は、本発明の１つの実施例の動作の概観である。図１は、中央コンピュータシステム１と３つのリモートコンピュータシステム（または「ノード」）、２１−ａ，２１−ｂおよび２１−ｃを示す。ノード２１−ａ，２１−ｂおよび２１−ｃはそれぞれ、これより詳しく説明する中央コンピュータシステムとの各種通信状態で示される。中央コンピュータシステム１は、中央データベース３、ドッキング・マネージャ５、マージ・プロセッサ７およびログ・マネージャ９を含む。中央コンピュータシステム１はさらに、オプションでユーザ入力１３に応答するアップデート・マネージャ１１を含む。ノード２１−ａは、ラップトップコンピュータのようなモバイルクライアントなどのリモートコンピュータシステムである。ノード２１−ａは、部分的複製リモート・データベース２３−ａ，ユーザ入力３３−ａに応答するアップデート・マネージャ３１−ａ、ドッキング・マネージャ２５−ａ、マージ・マネージャ２７−ａを含む。オペレーションでは、アップデート・マネージャはユーザ人力３３−ａに応答して、ノード２１−ａのオペレータの指示どおりにリモート・データベース２３−ａを変更する。アップデートは、ノードのアップデートログ３５ −ａに記録、あるいはジャーナルされる。ある時点におけるノード２１−ａのオペレータの都合で、ノード・ドッキング・マネージャ３５−ａが起動され、中央ドッキング・マネージャ５との通信に入る。アップデート・ログ３５−ａをノード・ドッキング・マネージャ２５−ａが入力として取り、中央ドッキング・マネージャ５に与える。中央ドッキング・マネージャ５は受け取り済みノード・アップデート・ログ１９を作り、これには、アップデート・ログ３５−ａに記録されている情報がすべて入っている。オプションで、部分ログ１７−ａを中央ドッキング・マネージャ５が入力として取り、本書で詳しく説明するようにノード・ドッキング・マネージャ２５−ａに与える。ある時点における、中央コンピュータシステム１のオペレータの都合で、マージ・プロセッサ７が起動される。マージ・プロセッサ７は受け取り済みノード・アップデート・ログ１９を入力として取り、そこに記述されたアップデートを中央データベース３に適用する。受け取り済みノード・アップデート・ログ１９からのアップデートの適用プロセスにおいて、マージ・プロセッサは中央アップデート・ログ１５に適用されたアップデートをジャーナルする。オプションで、アップデート・マネージャ１１は、ユーザ入力１２に応答して、中央コンピュータシステム１のオペレータの指示どおりに中央データベース３に追加変更を行う。アップデート・マネージャ１１によるアップデートはさらに中央アップデート・ログ１５にジャーナルされる。ある時点における、中央コンピュータシステム１のオペレータの都合で、ログ・マネージャ９が起動される。ログ・マネージャ９は中央アップデート・ログ１５を入力として取り、ここで詳しく説明する可視度ルールに従って部分ログ１７ −ａ、１７−ｂ、１７−ｃのセットを出力として生成する。部分ログ１７−ａ、１７−ｂおよび１７−ｃのそれぞれは、ノード２１−ａ、２１−ｂおよび２１− ｃに対応する。ノード・ドッキング・マネージャ２５−ａのようなノード・ドッキング・マネージャが中央ドッキング・マネージャ５と通信に入り、オプションで対応する部分ログの転送を要求すると、中央ドッキング・マネージャ５は入力として部分ログ１７−ａなどの適当な部分ログを取り、これをノード・ドッキング・マネージャ２５−ａに提示する。ノード・ドッキング・マネージャ２５−ａは、マージ・ログ３７−ａとして部分ログ１７−ａを複製する。将来のある時点における、ノード２１−ａのオペレータの都合で、マージ・プロセッサ２７−ａが起動される。マージ・プロセッサ２７−ａは、入力としてマージ・ログ３７−ａを取り、部分的複製データベース２３−ａにそこに記述するアップデートを適用する。ノード２１−ａに加えて、図１はまた２つの追加ノード２１−ｂと２１−ｃを示す。ノード２１−ｂは、中央コンピュータ１との通信で示される。ただし、ノード２１−ａと異なり、ノード２１−ｂのオペレータは自分のアップデートを中央コンピュータシステム１に送ることのみ要求しており、自分の部分的複製データベース２３−ｂにどこかで行われた変更を与えられることは要求していない。これは例えば、オペレータにできるだけ早く行わなければならない緊急のアップデートがあるが、他のノードからアップデートを受け取る時間がない場合などである。従って、図１はノード・ドッキング・マネージャ２５−ｂから中央ドッキング・マネージャ５へのノード・アップデート・ログ３５−ａの転送のみ示し、中央ドッキング・マネージャ５からノード・ドッキング・マネージャ２５−ｂへの転送は示さない。従って、ノード２１−ｂのマージ・マネージャは起動されず、図示されない。同様に、ノード２１−ｃは、中央コンピュータシステム１と通信しない状態で示される。従って、ノード２１−ｃのドッキング・マネージャは起動されず、図示されない。上述のサイクルにより、ノード２１−ａ、２１−ｂおよび２１−ｃそれぞれによるアップデートが中央コンピュータシステム１に与えられ、中央データベース３をそのようにアップデートできる。さらにノード２１−ａ、２１−ｂおよび２１−ｃによるアップデートのそれぞれと、中央コンピュータシステム１に対するアップデートは、ノード２１−ａ、２１−ｂおよび２１−ｃのそれぞれに戻され、これによって部分的データベース２３−ａ，２３−ｂおよび２３−ｃのそれぞれが互いと中央データベース３と同期させる。データベース構造中央データベース３とノード・データベース２３−ａ，２３−ｂおよび２３− ｃとの同期は、ドッキング・オブジェクトと呼ばれる構造を使って実行する。ドッキング・オブジェクトは、メンバ・テーブル（１つのプライマリ・テーブルを含む）、可視度ルール、可視度イベント、関連するドッキング・オブジェクトから構成される。各ドッキング・オブジェクトは可視度レベルと可視度レベルの属性を持ち、これについては以下に詳しく説明する。メンバ・テーブルは、ドッキング・オブジェクトを構成するリレーショナル・データベースのテーブルである。ドッキング・オブジェクトが中央データベース３からノード・データベース２３−ａ、２３−ｂまたは２３−ｃに伝播する時、その伝播は特定のドッキング・オブジェクトと関連するメンバ・テーブルのそれぞれへの挿入の形を取る。同様に、ドッキング・オブジェクトがデータベースから除去されるようスケジュールされると、その除去はドッキング・オブジェクトに関連するメンバ・テーブルからの記録の削除によって構成される。例えば、販売機会を表すドッキング・オブジェクトには、機会そのもの（例えば「Ｓ＿ＯＰＴＹ」という名前）、機会によって表される販売製品（例えば「Ｓ＿ＯＰＴＹ＿ＰＲＯＤ」という名前）、その機会の連絡先（例えば「Ｓ＿ＯＰＴＹ＿ＣＯＮＴＡＣＴ」）等を表すテーブルを含むことができる。これらテーブルはそれぞれ「機会ドッキング・オブジェクト」のメンバ・テーブルと言われる。本発明の別の態様では、各メンバ・テーブルの行は、ドッキング・オブジェクトに対応する１つ以上の行を持つことができる。プライマリ・テーブルは、ドッキング・オブジェクトの特定のインスタンス（ instance）が特定のノードに見えるかどうかを制御するメンバ・テーブルである。プライマリ・テーブルは、アップデート、削除または挿入されるプライマリ・テーブルの行を特定するために使うプライマリ行ＩＤ値を有している。例えば、「機会ドッキング・オブジェクト」は、プライマリ・テーブルとしてテーブルＳ＿ＯＰＴＹを持つことができる。このテーブルの行ＩＤ、すなわち「Ｓ＿ＯＰＴＹ．ｒｏｗ＿ｉｄ」は、機会ドッキング・オブジェクトのプライマリ行ＩＤである。各ドック・オブジェクトは、可視度ルールを使って分析される可視度レベルと可視度レベル属性を持つ。有効値は「エンタープライズ（Enterprise）」，「リミテッド(Limited)」，「プライベート（Private）」である。エンタープライズ・ドック・オブジェクトのすべてのメンバ・テーブルの行は、あらゆるノードに複製される。リミテッド・ドック・オブジェクトのメンバ・テーブルの行は、あらゆるノードに複製される。リミテッド・ドック・オブジェクトのメンバ・テーブルの行は、可視度チェックされ、その行に対する可視度を持つノードに送られる。可視度ルールは、ドッキング・オブジェクトの特定のインスタンスが特定のノード２１に「可視」か否かを決定する基準である。ドッキング・オブジェクトが特定のノードに可視なら、そのノードはドッキング・オブジェクトにデータのアップデートを受ける。可視度ルールには、ＲＵＬＥ＿ＴＹＰＥのフィールドに応じて２種類ある。「Ｒ」のＲＵＬＥ＿ＴＹＰＥを持つ可視度ルールは、ＳＱＬルールと呼ばれる。ＳＱＬルールには、ＳＱＬステートメントに指定する基準を満たすデータがドッキング・オブジェクトに存在するか否か決定するために評価されるストラクチャード・ケリー・ランゲージ（ＳＱＬ）ステートメントのセットが含まれる。仮にそうであれば、ドッキング・オブジェクトはノードにとって可視である。「Ｏ」のＲＵＬＥ＿ＴＹＰＥを持つ可視度ルールは、ドッキング・オブジェクト・ルールと呼ばれる。ドッキング・オブジェクト・ルールは、可視度について照会する別のドッキング・オブジェクトを指定する。指定のドッキング・オブジェクトが可視なら、それを指すドッキング・オブジェクトも可視である。関連ドッキング・オブジェクトは、検討中のドッキング・オブジェクトが伝播あるいは削除されるときに、伝播あるいは削除されるドッキング・オブジェクトである。例えば、機会ドッキング・オブジェクトには、販売連絡先、組織、販売する製品、機会の追求に必要な活動を表す関連ドッキング・オブジェクトがある。機会ドッキング・オブジェクトが中央データベース３からノード・データベース２３の１つに伝播すると、関連ドッキング・オブジェクトも伝播される。図２は、ドッキング・オブジェクトを構成する各種コンポーネントの関係を示すデータベース・スキーマである。このスキーマは、メタ・データベース(meta- database)で、データベースでアクセスしているデータを記述しない。というより、このスキーマは、アクセスしているデータベースの構造を定義する別個のデータベースである。すなわち、他のデータベースの関係とデータ・コンテキストを記述するデータベース構成テーブルである。図２に示すテーブルはそれぞれ行列形式で示されるようなリレーショナル・データベースのテーブルである。多くの列はすべての図示テーブルに共通するフィールドを表す。かかるフィールドには例えば、テーブルの特定の行を示すＲＯＷ＿ＩＤや、行を作成し、最後に修正した日付と時間を追跡するフィールド、行を作成・修正したユーザの身元などが含まれる。さらに、各テーブルにはそのテーブル固有のフィールドで、以下に詳細に説明するものを含む。テーブルＳ＿ＤＯＢＪ６１は、アプリケーションのドッキング・オブジェクトを記述する。テーブルＳ＿ＤＯＢＪ６１には、ＯＢＪ＿ＮＡＭＥおよびＰＲＩＭＡＲＹ＿ＴＡＢＬＥ＿ＩＤが含まれる。フィールドＯＢＪ＿ＮＡＭＥは、記述するドッキング・オブジェクトの名前を定義する。フィールドＰＲＩＭＡＲＹ＿ＴＡＢＬＥ＿ＩＤを使って、このドッキング・オブジェクトに関連するプライマリ・テーブルを識別する。テーブルＳ＿ＤＯＢＪ＿ＩＮＳＴ６３は、テーブルＳ＿ＤＯＢＪ６１で記述するドッキング・オブジェクトの特定のインスタンスが、特定のノードのデータベースに存在するか否かを記述する。テーブルＳ＿ＤＯＢＪ＿ＩＮＳＴ６３は、フィールドＮＯＤＥ＿ＩＤ，ＤＯＢＪ＿ＩＤおよびＰＲ＿ＴＢＬ＿ＲＯＷ＿ＩＤを含む。フィールドＮＯＤＥ＿ＩＤは、特定のノード・テーブル６５を指す。フィールドＤＯＢＪ＿ＩＤは、ドッキング・オブジェクトのインスタンスが適用されるドッキング・オブジェクトを指す。フィールドＰＲ＿ＴＢＬ＿ＲＯＷ＿ＩＤを使って、ドッキング・オブジェクトのプライマリ・テーブルの特定の行を選択する。この値は、ドッキング・オブジェクトのインスタンスを識別する。テーブルＳ＿ＲＥＬ＿ＤＯＢＪ６７は、テーブルＳ＿ＤＯＢＪ６１で記述する特定のドッキング・オブジェクトの関連ドッキング・オブジェクトを記述する。テーブルＳ＿ＲＥＬ＿ＤＯＢＪ６７は、フィールドＤＯＢＪ＿ＩＤ、ＲＥＬ＿ＤＯＢＪ＿ＩＤおよびＳＱＬ＿ＳＴＡＴＥＭＥＮＴを含む。フィールドＤＯＢＪ＿ＩＤは、特定の関連ドッキング・オブジェクトを所有するドッキング・オブジェクトを識別する。フィールドＲＥＬ＿ＤＯＢＪ＿ＩＤは、ＤＯＢＪ＿ＩＤで識別されるドッキング・オブジェクトが所有する関連ドッキング・オブジェクトを識別する。フィールドＳＱＬ＿ＳＴＡＴＥＭＥＮＴは、関連ドッキング・オブジェクトのプライマリＩＤ値を取得するために実行できるＳＱＬステートメントである。テーブルＳ＿ＤＯＢＪ＿ＴＢＬ６９は、テーブルＳ＿ＤＯＢＪ６１で記述する特定のドッキング・オブジェクトのメンバ・テーブルを記述する。テーブルＳ＿ＤＯＢＪ＿ＴＢＬ６９は、フィールドＤＯＢＪ＿ＩＤ、ＴＢＬ＿ＩＤおよびＶＩＳ＿ＥＶＥＮＴ＿ＦＬＧを含む。フィールドＤＯＢＪ＿ＩＤは、行で記述するメンバ・テーブルの入ったドッキング・オブジェクトを識別する。フィールドＴＢＬ＿ＩＤは、行の記述するメンバ・テーブルであるデータベース中の特定のテーブルを識別する。フィールドＶＩＳ＿ＥＶＥＮＴ＿ＦＬＧは、このドッキング・オブジェクトの変更が可視度イベントを生じるか否かを示すフラグである。「Ｙ」の値は、変更で可視度イベントが生じることを示し、「Ｎ」の値は、生じないことを示す。テーブルＳ＿ＤＯＢＪ＿ＶＩＳ＿ＲＵＬＥ７１には、特定のドッキング・オブジェクトと関連する可視度ルールを含む。Ｓ＿ＤＯＢＪ＿ＶＩＳ＿ＲＵＬＥ７１には、フィールドＤＯＢＪ＿ＩＤ，ＲＵＬＥ＿ＳＥＱＵＥＮＣＥ，ＲＵＬＥ＿ＴＹＰＥ，ＳＱＬ＿ＳＴＡＴＥＭＥＮＴおよびＣＨＥＣＫ＿ＤＯＢＪ＿ＩＤを含む。フィールドＤＯＢＪ＿ＩＤは、特定の可視度ルールの関連するドッキング・オブジェクトを識別する。フィールドＲＵＬＥ＿ＳＥＱＵＥＮＣＥは、テーブルＳ＿ＤＯＢＪ＿ＶＩＳ＿ＲＵＬＥ７１の他の可視度ルールに関連するシーケンスを示すシーケンス番号で、特定の可視度ルールを走らせなければならない。ＲＵＬＥ＿ＴＹＰＥは、特定の可視度ルールがタイプ「Ｒ」で、ＳＱＬ可視度ルールを示すか、タイプ「Ｏ」で、ドッキング・オブジェクト可視度ルールを示すかを指定する。ＲＵＬＥ＿ＴＹＰＥが「Ｒ」に等しい場合、フィールドＣＨＥＣＫ＿ＤＯＢＪ＿ＩＤは意味のあるものでなく、フィールドＳＱＬ＿ＳＴＡＴＥＭＥＮＴには、このドッキング・オブジェクトと特定のノード２１に関連するプライマリ・テーブルのプライマリＲＯＷ＿ＩＤを使って評価するＳＱＬステートメントが入っている。ＳＱＬステートメントが何らかの記録を戻すと、ドッキング・オブジェクトはノード２１にとって可視とみなされ、その可視度が決定される。ＲＵＬＥ＿ＴＹＰＥが「Ｏ」に等しい場合、フィールドＣＨＥＣＫ＿ＤＯＢＪ＿ＩＤとフィールドＳＱＬ＿ＳＴＡＴＥＭＥＮＴは両方とも意味のあるものである。フィールドＣＨＥＣＫ＿ＤＯＢＪ＿ＩＤは、可視度を決定しなければならないドッキング・オブジェクトを指定する。指定のドッキング・オブジェクトが可視とみなされたら、その可視度ルールに関連するドッキング・オブジェクトも可視である。フィールドＳＱＬ＿ＳＴＡＴＥＭＥＮＴには、実行されると，その可視度ルールに関連するドッキング・オブジェクトのインスタンスに対応するＣＨＥＣＫ＿ＤＯＢＪ＿ＩＤで識別するドッキング・オブジェクトの行ＩＤを戻すＳＱＬステートメントを含む。テーブルＳ＿ＡＰＰ＿ＴＢＬ７３は、特定のアプリケーションに用いるすべてのテーブルを記述するアプリケーション・テーブルである。これは、ドッキング・オブジェクトの各メンバ・テーブルは、テーブルＳ＿ＤＯＢＪ＿ＴＢＬ６９によって、ドッキング・オブジェクトのプライマリ・テーブルはテーブルＳ＿ＤＯＢＪによって指される。Ｓ＿ＡＰＰ＿ＴＢＬ７３は、テーブルＳ＿ＡＰＰ＿ＣＯＬ７５を指すが、これは特定のアプリケーションのデータ列を記述するアプリケーション列テーブルである。Ｓ＿ＡＰＰ＿ＴＢＬ７３は、プライマリ・キーを介して直接、および外部キー列テーブル８１、ユーザ・キー列テーブル８３、列グループ・テーブル８５などの手段を介して間接にテーブルＳ＿ＡＰＰ＿ＣＯＬ７５を指す。アプリケーション・テーブル、アプリケーション列テーブル、外部キー列テーブル、ユーザ・キー列テーブル、列グループ・テーブルの関係は当業者には周知であるのでこれ以上説明しない。アップデート処理図３は、ノードデータベース２３−ａ，２３−ｂまたは２３−ｃなどのデータベースをユーザ入力に対応してアップデートする際、アップデート・マネージャ３１−ａ，３１−ｂまたは３１−ｃなどのアップデート・マネージャ３１が実行するステップを示す。アップデート・マネージャ３１の実行は、ステップ１０１から始まる。ステップ１０３で、アップデート・マネージャ３１はユーザ入力３３からデータベース２３のデータ変更を要求するコマンドの形で受取る。要求は、テーブルの行の削除、テーブルへの行の追加、テーブルの特定の行の特定列のセル値変更という要求の形になる。ステップ１０５では、周知の手段を使って、アップデート・マネージャ３１が要求されたアップデートをデータベース２３に適用する。ステップ１０７では、アップデート・マネージャ３１はアップデートを記述するログ記録を作り、アップデート・ログ３５に書き込む。ログ記録の内容は、行ったアップデートを記述する。各ログ記録は、アップデートを作るノードのノード識別子、アップデートするテーブルの識別、行っているアップデートのタイプの識別、すなわち、新しい行の挿入、既存の行の削除、または既存の行のアップデートを示す。挿入では、ログ記録は追加的に、そのプライマリ・キーと行の他の列の値をはじめとする挿入する行の識別子を含む。削除では、ログ記録は、削除する行のプライマリ・キーを識別する。アップデートでは、ログ記録はアップデートする行のプライマリ・キー、アップデートする行内の列、アドレス指定した行と列のセルの古い値、そのセルの新しい値を識別する。ステップ１０７でログ記録を書きこんだ後、アップデート・プロセッサはこのアップデートを終了する。アップデート処理の前述の説明には、本発明にとって重要でない追加ステップ、例えば、ユーザがアップデートを行う認証を保障すること、ソフトウェアまたはハードウェアの故障の際にロールバック（rollback）を許すためのデータベースへの書きこみのステージ(stage)及びコミット（commi t）等をすることを含むことが望ましい。これらのステップは当業者には周知であるので、これ以上説明しない。中央コンピュータ・システム１で実行するアップデート・マネージャ１１は類似の方法で動作するが、中央データベース３をアップデートしてそのログ記録を中央アップデート・ログ１１に書きこむ点が異なる。ドッキング処理図４は、ドッキング・マネージャ２５−ａ，２５−ｂまたは２５−ｃなどのドッキング・マネージャ２５が、１つ以上のトランザクション・ログの転送および /または受取りのために実行するステップを示す。ドッキング・マネージャ２５が、ノード２１−ａ，２１−ｂまたは２１−ｃなどのリモートノードのユーザによって呼び出され、これによってユーザが中央コンピュータ１のノード・ドック（dock）にアップデート・ログ３５−ａなどのアップデート・ログを中央コンピュータ１にアップロードして、部分ログ１７−ａなどの部分ログをダウンロードすること、あるいはその両方を要求する。ドッキング・マネージャ２５の実行はステップ１２１から始まる。ステップ１２３では、ドッキング・マネージャ２５は中央コンピュータ１の制御下で中央ドッキング・マネージャ５と接続する。この接続は、データ交換を可能にするあらゆる接続でよい。最も一般な接続形式は電話回線とモデムによるものと予想されるが、ローカル・エリア・ネットワークまたはＴＣＰ／ＩＰ接続などの他の形式のデータ接続も使用できる。ステップ１２５で、ユーザがノード・アップデート・ログ３５−ａの中央コンピュータ１へのアップロードを要求したか否かをチェックする。していたら、実行はステップ１２７に進む。していなかったら、ステップ１２７をスキップして、制御はステップ１２９に与えられる。ステップ１２７では、ドッキング・マネージャ２５はそのアップデート・ログを中央コンピュータ１にアップロードする。アップロードは、ＸＭＯＤＥＭ，ＺＭＯＤＥＭ，ＫＥＲＭＩＴ，ＦＴＰ，ＡＳＣＩＩ転送などの周知のファイル転送手段、その他データ転送の他の方法で行うことができる。ステップ１２９では、ドッキング・マネージャ２５はユーザが部分ログ１７−ａなどの部分ログの中央コンピュータ１からのダウンロードを要求したか否かをチェックする。していたら、実行はステップ１３１に進む。していなかったら、ステップ１３１をスキップして、制御はステップ１３３に与えられる。ステップ１３１では、ドッキング・マネージャ２５はその部分ログを中央コンピュータ１からダウンロードする。ダウンロードは、ＸＭＯＤＥＭ，ＺＭＯＤＥＭ，ＫＥＲＭＩＴ，ＦＴＰ，ＡＳＣＩＩ転送などの周知のファイル転送手段、その他データ転送の他の方法で行うことができる。ステップ１３３で、要求されたデータ転送が完了すると、ドッキング・マネージャ２５は終了する。マージ(merge)処理マージ処理は、ノード・マージ・プロセッサ２７−ａ，２７−ｂまたは２７− ｃまたは中央マージ・プロセッサ７などのプロセッサが実行する。マージ・プロセスは、マージ処理を実行しているコンピュータから離れたコンピュータのユーザが入力したトランザクションにその関連するデータベースをアップデートする。マージ処理はアップデート処理と同じで、図３を参照して以前に開示したアップデート処理と形式が似ているが、３つの違いがある。第１は、マージ・プロセッサへの入力はユーザが直接入力するアップデートではなく、マージを実行するコンピュータから離れたコンピュータから取得するログ・ファイルであることである。第2の違いは、図１に示すように、マージ処理はノードで実行されたときにログを生成しない。ノードでのログの機能は、中央コンピュータシステム１と、ひいては要求された他のノードへの伝播のトランザクションの記録である。ノードでのマージ対象であるトランザクションは中央コンピュータシステム１には通信されており、それを再通信する必要はない。第３の違いは、マージ処理が複数の対立するトランザクションを検出・解決できなければならない点である。例えば、フィールドに「ＫｅｉｔｈＰａｌｍｅｒ」という値が入っていたとする。さらに、ノード２７−ａのユーザがこのフィールドを「ＣａｒｌＬａｋｅ」にアップデートするトランザクション、ノード２７−ｂのユーザが同じフィールドを「ＧｒｅｇＥｍｅｒｓｏｎ」にアップデートするトランザクションを入力したとする。衝突検出がないと、各種ノード間のデータが崩壊する。ユーザ２７−ａのトランザクションをマージすると、フィールドは「ＫｅｉｔｈＰａｌｍｅｒ」から「ＣａｒｌＬａｋｅ」にアップデートされる。衝突処理がないと、ノード２７−ｂのトランザクションがマージされると、フィールドは「ＧｒｅｇＥｍｅｒｓｏｎ」にアップデートされ、中央データベースはノード２７−ａのデータベースと同期しなくなる。さらに、マージ処理をノード２７−ａと２７−ｂのそれぞれに実行すると、各ノードはそのデータベースを互いのトランザクションでアップデートするため、少なくとも１つのノードが他方のノードおよび中央データベースと同期しなくなる。そのため、マージ処理は衝突の検出とその是正の手段も持たなければならない。上記の例では、衝突を検出して是正する単純な方法は、データベースの値をノード・データベースの前の値としてマージ・ログが反映する値と比較するものである。２つの値が一致しなければマージ・プロセッサ７はそのトランザクションを拒絶し、是正トランザクションを生成して対立するトランザクションを発したノードに送る。上記の例では、ノード２７−ｂのトランザクションがマージ・プロセッサ７に与えられた時、マージ・プロセッサ７は「ＫｅｉｔｈＰａｌｍｅｒ」、ノード２７−ｂが「ＣａｒｌＬａｋｅ」と記録したそのフィールドの前の値、中央データベース３に記録されたフィールドの現在値とを比較する。不一致を検出すると、マージ・プロセッサ７はトランザクションを生成して、値「ＧｒｅｇＥｍｅｒｓｏｎ」を「ＣａｒｌＬａｋｅ」に変更し、このトランザクションをアップデート・ログ１５に書きこむ。上記は、衝突の一例とその結果としての是正措置である。他のタイプの衝突には、例えば、前に削除した行へのアップデート、前に挿入した行の挿入などがある。マージ処理では、これら衝突のそれぞれを検出・是正しなければならない。これは、数多くの周知の方法を使って実行できるため、これ以上述べない。図５は、中央マージ・プロセッサ７などのマージ・プロセッサが実行するステップを示す。これはマージ・プロセッサ７が中央データベース３とトランザクション・ログ１５に書きこむところを示すが、ノード・マージ・プロセッサ２７−ａ、２７−ｂまたは２７−ｃなどのノード・マージ・プロセッサがノード・データベース２３−ａ，２３−ｂまたは２３−ｃをアップデートするところも表している。マージ処理はステップ１４１から始まる。ステップ１４３で、マージ・プロセッサ７は受け取ったログ１９に第１の未処理トランザクションを見つける。ステップ１４７で、マージ・プロセッサ７は受け取ったログ１９からトランザクションを選択する。ステップ１４９で、マージ・プロセッサ１４９はステップ１４７で選択したトランザクションに従ってデータベース３をアップデートしようとする。ステップ１５１で、マージ・プロセッサ７はステップ１４９のデータベースアップデートが衝突によって失敗したか否か判断する。失敗なら、マージ・プロセッサはステップ１５３に進み、是正トランザクションを生成する。是正トランザクションの生成の後、マージ・プロセッサはステップ１４９に戻り、再びデータベース３をアップデートしようとする。ステップ１５１で衝突が検出されなければ、実行はステップ１５７に進む。ステップ１５７で、マージ処理は中央コンピュータ１で実行しているか否かをチェックする。もしそうなら、ステップ１５５が実行され、トランザクションをログ１５にジャーナルする。いかなる場合も、ステップ１５７がノードまたはステップ１５５でマージ処理が実行されていると判断する場合、実行はステップ１５９に進む。ステップ１５９は、ログ１９から処理すべきトランザクションが残っていないかチェックする。残っているなら、実行はステップ１４７から繰り返し、次のトランザクションが選択される。残っていない場合、マージ処理はステップ１６１で終了する。ログ管理図６は、ログ・マネージャ９が部分トランザクションログ１７−ａ，１７−ｂまたは１７−ｃなどの部分トランザクション・ログを作成するために実行するステップを示す。図６に示す手順は、中央コンピュータシステム１とドックできる各ノードについて実行される。ログ・マネージャ９は、ステップ１７１から実行を始める。ステップ１７３で、ログ・マネージャ９は部分トランザクション・ログを作成しているノードに第1の未処理トランザクションを発見する。ステップ１７５で、ログ・マネージャ９は処理するトランザクションを選択する。ステップ１７７で、ログ・マネージャ９は、選択したトランザクションが、処理を実行するのと同じノードで発せられたか否かチェックする。もしそうなら、トランザクションをノードに戻す必要はなく、制御はステップ１７９に進む。ステップ１７９は、処理すべきトランザクションが残っていないかチェックする。残っているなら、制御は再びステップ１７５に与えられる。残っていないなら、制御はステップ１８９に渡され、ここでこのノードが処理した最後のトランザクションが記録され、ステップ１９１で終了する。トランザクションが、処理を実行しているノード以外のノードで発した場合、制御はステップ１８１に与えられる。ステップ１８１は可視度計算機を呼び出して、選択したトランザクションが処理中のノードに可視か否かを決定する。可視度計算機ルーチンは以下に詳しく説明する。ステップ１８３でログ・マネージャ９は可視度計算機がトランザクションが可視と決定したかをチェックする。可視でない場合、制御はステップ１７９に渡され、上述のように実行される。トランザクションが可視の場合、制御はステップ１８５に渡される。ステップ１８５はこのトランザクションの記録を、例えばノード２１−ａの部分トランザクションログ１７−ａなどの処理するノードの部分トランザクションログに書きこむ。ステップ１８７で、ログ・マネージャ９はこのノードについて処理された最後のトランザクションを記録してから、ステップ１７９に制御を渡し、そこで上述のように追加トランザクションを選択するか終了するかを決定する。可視度計算図７は、ログ・マネージャ９のステップ１８１によって呼び出されたドッキング・オブジェクトの可視度を計算するための可視度計算機のプロセスを説明するフローチャートを示す。可視度計算機は、可視度を計算するノードのノードｉｄ、可視度を計算するドッキング・オブジェクト、可視度ｉｄを計算するドッキング・オブジェクトの行ｉｄで呼び出される。可視度計算機はこの情報と、図２に示すスキーマに保存したメタ・データから取得した情報を使って、特定のドッキング・オブジェクトの特定の行をアップデートする特定のトランザクションが、特定のノードに可視か否かを決定する。可視度計算機はステップ２０１から実行を始める。ステップ２０３で、可視度計算機はトランザクションが可視でないというデフォルトの発見を行う。そのため、可視度計算機がトランザクションが可視であると判断しない限り、可視度なしとの発見で終了する。ステップ２０５で、可視度計算機がドッキング・オブジェクトと関連する第１の可視度ルールを選択する。これは、テーブルＳ＿ＤＯＢＪ＿６１が指す現在のドッキング・オブジェクトに関連するテーブルＳ＿ＤＯＢＪ＿ＶＩＳ＿ＲＵＬＥ７１の発見によって行う。ステップ２０５で、可視度計算機はフィールドＲＵＬＥ＿ＳＥＱＵＥＮＣＥに最低値を持つテーブルＳ＿ＤＯＢＪ＿ＶＩＳ＿ＲＵＬＥ７１の行を選択する。ステップ２０７では、可視度計算機は「Ｒ」の値についてフィールドＲＵＬＥ＿ＴＹＰＥをチェックする。「Ｒ」の値はルールがＳＱＬ可視度ルールであることを示す。もしそうなら、可視度計算機はステップ２０９に進む。ステップ２０９では、可視度計算機はフィールドＳＱＬ＿ＳＴＡＴＥＭＥＮＴからＳＱＬステートメントを取得し、これを実行する。このようなＳＱＬステートメントの例は次のようになる。このＳＱＬステートメントによって、アプリケーション・テーブルＳ＿ＯＰＴＹ＿ＥＭＰについての照会が行われる。この照会で２つの基準を満たすあらゆる記録を選択する。第１に、選択した記録は、可視度を決定するドッキング・オブジェクトのプライマリ行ＩＤに等しい行ｉｄまたはキーのフィールドＯＰＴＹ＿ＩＤを持っていなければならない。第２に、選択した記録は、例えば、可視度を決定するノードのノードｉｄに等しい特定の従業員の識別子であるフィールドＥＭＰ＿ＩＤを持っていなければならない。通常の言語では、このＳＱＬステートメントは、従業員を機会に一致させるテーブルで行が見つかり、その機会がアップデートするものに等しく、機会を割り当てた従業員がノードのオペレータである場合のみ記録を戻す。これはわかりやすいように単純化した例である。より複雑なＳＱＬステートメントもあり得る。例えば、次のようなルールである。このルールは、テーブルＳ＿ＡＣＣＴ＿ＰＯＳＴＮ（特定の顧客をその顧客を担当する組織内の特定の地位に関連づける）とＳ＿ＥＭＰ＿ＰＯＳＴＮ（どの従業員が特定の地位に対応するかを関連づける）を照会する。条件「ａｐ．ＰＯＳＩＴＩＯＮ＿ＩＤ＝ｅｐ．ＰＯＳＩＴＩＯＮ＿ＩＤ」は、従業員対地位テーブルの行と同じ地位を持つ顧客対地位テーブル中の行を発見しなけれなければならない。条件「ｅｐ．ＥＭＰ＿ＩＤ＝：ＮｏｄｅＩｄ」はさらに、従業員対地位テーブル中で選択した行が、可視度を決定するノードのユーザのＩＤに等しい従業員ＩＤも持っていることを要求する。通常の言語における、この条件では、従業員がアップデートしているドッキング・オブジェクトの顧客を担当する地位にある場合に可視度が許される。可視度評価に用いるＳＱＬステートメントの条件の複雑さには特定の制限はない。ＳＱＬの特定の実現によっては制限が課されることがあり、リソースの検討により複雑でないステートメントを使用することが望ましいことがあるが、このような制限は本発明固有のものではない。ステップ２１１は、ステップ２０９でのＳＱＬ＿ＳＴＡＴＥＭＥＮＴの実行が記録を戻したか否かを評価する。記録が戻されていれば、可視度をチェックしているノードが、処理しているドッキング・オブジェクトにとって可視度を持つことを示す。従って、記録が戻されていれば、可視度計算機はステップ２１３に進む。ステップ２１３では、トランザクションは可視とマークされる。可視度を決定するためにそれ以上ルールを評価する必要がないため、可視度計算機はステップ２２８に進む。ステップ２２８では、計算した可視度には、特定のノードの部分的複製データベースにドッキング・オブジェクトを挿入したり削除したりする必要があるかどうかを決定してデータベースを同期させる。これは例えば、ノードが関連ドッキング・オブジェクトの変更のためにドッキング・オブジェクトに対する可視度を持つと決定された場合に発生する。例えば、あるノードの所有者が、特定の販売機会に関連する特定の活動に割り当てられた場合である。その結果、ノードには販売機会を表すオブジェクトのコピーを提供しなければならない。図８は、データ可視度の変更に対応する部分的複製データベースの同期を実行するステップを示す。実行はステップ２４１から始まる。ステップ２４３では、可視度計算機はドッキング・オブジェクトについて計算したばかりの可視度を参照する。ドッキング・オブジェクトが可視なら、実行はステップ２４５に進む。ステップ２４５は、現在のノードについてドッキング・オブジェクトに行が存在することをベリファイ（verify）するため、Ｓ＿ＤＯＢＪ＿ＩＮＳＴテーブルを参照する。行が存在する場合、問題のノードが参照したドッキング・オブジェクトのコピーを既に持っていることを示し、ルーチンはステップ２５５に進んで終了する。しかし、処理しているノードのドッキング・オブジェクトに行が存在しない場合、問題のノードにはその部分的複製データベースにドッキング・オブジェクトのコピーがないことを示す。するとルーチンはステップ２４７に進み、ドッキング・オブジェクトをその部分的複製データベースに挿入するようノードに指令するトランザクションが生成される。ステップ２４３でドッキング・オブジェクトが可視でないと判断した場合、実行はステップ２４９に進む。ステップ２４９はＳ＿ＤＯＢＪ＿ＩＮＳＴテーブルを参照し、現在のノードについてドッキング・オブジェクトに行が存在しないことをベリファイする。ステップ２４３で、現在の行について現在のドッキング・オブジェクトのＳ＿ＤＯＢＪ＿ＩＮＳＴテーブルに行が存在しないと判断されると、これは問題のノードが参照したドッキング・オブジェクトのコピーを持たないことを示し、ルーチンはステップ２５５に進んでここで終了する。しかし、処理しているノードのドッキング・オブジェクトに行が存在する場合、これは、問題のノードがその部分的複製データベースにドッキング・オブジェクトのコピーを持っていることを示す。するとルーチンはステップ２５１に進み、ここでノードにその部分的複製データベースからドッキング・オブジェクトを削除することを指令するトランザクションが生成される。図７を再び参照すると、ステップ２２８のデータ同期ルーチンの後、可視度計算機はステップ２２９に進んでそこで終了する。図６を参照すると、前に述べたように、結果として可視度の発見は、トランザクションの書きこみを決定するために、ログ・マネージャがステップ１８３でチェックすることが可能である。再び図７を参照すると、ステップ２１１で、ＳＱＬステートメントの実行によってステップ２０９で記録が戻されなかったと決定された場合、実行はステップ２１５に進む。ステップ２１５は、評価すべき可視度ルールが残っているか否かをチェックする。残っていない場合、可視度計算機はステップ２２８に進んでデータベースを同期させ、次にステップ２２９に進んで終了する。この場合、ステップ２０３で設定した可視度なしのデフォルトマークは設定されたままになる。この値は図６に示すようにステップ１８３でログ・マネージャも使って、トランザクションを書きこまないことを決定する。再び図７を参照すると、評価するルールが残っている場合、制御はステップ２１７に進み、次に処理するルールを選択する。すると制御は再びステップ２０７に与えられ、新しいルールの処理を始める。先行するテキストは、処理の記述またはＳＱＬ可視度ルール、即ち、「Ｒ」タイプの可視度ルールを提供した。ステップ２０７で、可視度ルールがタイプ「Ｒ」でないと決定された場合、可視度ルールはタイプ「Ｏ」である。タイプ「Ｏ」はドッキング・オブジェクトの可視度ルールを示す。このような場合、処理しているドッキング・オブジェクトは、可視である特定の関連ドッキング・オブジェクトに関連する場合、可視とみなされる。フィールドＲＵＬＥ＿ＴＹＰＥが「Ｒ」に等しくない場合、実行はステップ２２１に進む。ステップ２２１で、可視度を決定しなければならない関連ドッキング・オブジェクトを決定し、現在のドッキング・オブジェクトが可視であるか否かを決定する。関連ドッキング・オブジェクトの識別子をテーブルＳ＿ＤＯＢＪ＿ＶＩＳ＿ＲＵＬＥ７１のフィールドＣＨＥＣＫ＿ＤＯＢＪ＿ＩＤから取得する。ステップ２２３で、可視度計算機は、関連ドッキング・オブジェクトのどの行を可視度について照会しなければならないかを決定する。これを決定するため、可視度計算機はフィールドＳＱＬ＿ＳＴＡＴＥＭＥＮＴから所定のＳＱＬステートメントを取得し、これを実行する。ＳＱＬステートメントは、例えば可視度計算機を呼び出すドッキング・オブジェクトに対応するドッキング・オブジェクトの1つ以上の行を選択する照会である。例えば、ノードがその販売機会について作った販売見積りに対して可視度を持っている場合、販売機会の記録が可視でなければならないと示すことが望ましいと想定する。これは、次のＳＱＬステートメントを使って達成できる。このＳＱＬステートメントは、すべての販売見積りの入ったテーブルＳ＿ＤＯＣ＿ＱＵＯＴＥにアクセスする。ＷＨＥＲＥクローズは、行の機会ＩＤが可視度を計算する機会の行ＩＤに等しい場合、すべての行の取り出しを指定する。可視度マネージャは、指定の行ＩＤを取り出し、これによって可視度をチェックしなければならないＳ＿ＤＯＣ＿ＱＵＯＴＥテーブルの行を識別する。現在のドッキング・オブジェクトの可視度がその可視度に依存する関連ドッキング・オブジェクトと、その関連ドッキング・オブジェクトの行ＩＤを決定したら、可視度計算機はステップ２２５に進む。ステップ２２５では、可視度計算機は繰り返し自分自身を呼び出して関連ドッキング・オブジェクトの可視度を決定する。繰り返し呼び出された可視度計算機は、さらに繰り返し自分自身を呼び出す機能を含み、ログ・マネージャ９から呼び出された可視度計算機と同じ方法で動作する。繰り返し呼び出しが終了すると、それは関連ドッキング・オブジェクトに対する可視度インジケータを戻し、制御はステップ２２７に進む。ステップ２２７では、可視度計算機は関連するドッキング・オブジェクトが可視と決定されたか否かを決定する。もしそうなら、可視度計算機はステップ２１３に進み、元の現在のドッキング・オブジェクトを可視とマークしてから、ステップ２２８に進み、データベースを同期してからステップ２２９で終了する。関連ドッキング・オブジェクトが可視と決定されない場合、制御はステップ２１５に進んで他に評価する可視度ルールが残っているか否かを決定する。そのため、可視度計算機は、ログ・マネージャと共に、どのようなアップデート・トランザクション・データのサブセットが特定のノードに送られることが要求されているかを決定することができる。このオペレーションは、中央コンピュータ１から部分的複製データベースを用いるノード２１−ａ，２１−ｂおよび２１−ｃなどの各種ノードへの不要なデータの転送を減らし、保存に必要なディスクスペースや処理に必要なＣＰＵ時間など、各リモートノードの完全複製データベースを保持するのに必要だったであろうシステム・リソースを削減する働きをする。ログ・マネージャ９のここで説明された可視度計算機とのオペレーションは、説明と図面を参照すれば明らかとなるであろう。しかしながら、これら機能の説明をさらに補助するために、これら機能の擬似コード表現を付属物として添付する。バッチ可視度計算可視度イベントの計算と可視度トランザクションのルーティング（routing）は、連続する行毎オペレーションの実行ではなく、関連ＳＱＬステートメントのバッチング（batching）によって最適化できる。この最適化は、セット処理を使ってネットワーク・トラフィックを減らし、リダンダント(redundant)なオペレーションを取り除くことで達成する。リダンダントな作業は、可視度の計算に用いるキー・データをトランザクション・ログにデノーマライジング(denormalizi ng)することで取り除く。例えば、ログ・マネージャ、ドッキング・オブジェクトプライマリ・テーブルｉｄ，可視度イベントフラグ、関連データをトランザクション・ログ・テーブルに保存する。このデータを各モバイル・クライアント毎に1回計算する代りに、ログ・マネージャが使用するすべてのモバイル・クライアントについて1回このデータを計算する。ログ・マネージャは、ＳＱＬステートメントを提出してセット処理を用い、各トランザクションについてＳＱＬステートメントを提出する代わりに数千のトランザクションの可視度を同時にチェックする。ネットワーク・トラフィックは、データベース・サーバからドッキング・サーバに可視のトランザクションのみ取り出すことで削減する。その結果、データベース・サーバからドッキング・サーバへは、ネットワーク上を非常に少ないデータしか移動しない。図９は、バッチ可視度チェックのサポートに用いるトランザクション・ログ・テーブル３００のデータベース設計の構造を示す。ノード・テーブル３０１はデータベースの中央テーブルで、ドック・オブジェクト・インスタンス・テーブル３０２、ドック状態テーブル３０４、トランザクション・テーブル３０６への１対多ポインターを含む。ドッキング・オブジェクト・インスタンス・テーブル３０２には、ドッキング・オブジェクト・インスタンスがモバイル・クライアントに可視か及び、モバイル・クライアントにダウンロードされているか否かを保存する。ドッキング・オブジェクト・インスタンス・テーブル３０２には、ドッキング・オブジェクト・インスタンスがモバイル・クライアントにとって完全に可視か部分的に可視である場合に、行が存在する。ドッキング・オブジェクトが可視でない場合、そのドッキング・オブジェクト・インスタンスの行はドッキング・オブジェクト・インスタンス・テーブル３０２には現れない。ドッキング・オブジェクト・インスタンス・テーブル３０２（Ｓ＿ＤＯＢＪ＿ＩＮＳＴ）は、バッチ可視度チェックをサポートする次のフィールドから構成される。ＮＯＤＥ＿ＩＤ：このドッキング・オブジェクト・インスタンスが関連するノードの非ゼロユーザ・キー。ＤＯＢＪ＿ＩＤ：このドッキング・オブジェクト・インスタンスが関連するドッキング・オブジェクトの非ゼロユーザ・キー。ＰＲ＿ＴＢＬ＿ＲＯＷ＿ＩＤ：ドッキング・オブジェクト内のプライマリ・テーブルの行ＩＤの入った非ゼロユーザ・キー。この値は、ドッキング・オブジェクト・インスタンスを識別する。ＳＴＡＴ＿Ｆｌａｇ：値「Ｆ」または「Ｐ」の入った１バイトフラグ。値「F 」はドッキング・オブジェクト・インスタンスが完全に可視であることを示す。値「Ｐ」は、ドッキング・オブジェクト・インスタンスが部分的に可視であることを示す。ＬＡＳＴ＿ＣＨＫ＿ＴＸＮ＿ＩＤ：ドック・オブジェクト・インスタンスの可視度を最後にチェックしたトランザクションのトランザクションＩＤ。この値を使って、ドック・オブジェクト・インスタンスを再計算しなければならない時を判断できる。例えば、ＬＡＳＴ＿ＣＨＫ＿ＴＸＮ＿ＩＤ＝３０００の場合、ログ・マネージャはトランザクションＩＤ３０００以降に可視度イベントが発生するまで、ドック・オブジェクト・インスタンスの可視度を再計算してはならない。ドック状態テーブル３０４は、各モバイル・クライアントに関連する状態情報を保存する。これは、最後にマージしたファイル、最後に抽出したファイル、最後に抽出したトランザクションのアイデンティティが含まれる。ドック状態テーブル３０４（Ｓ＿ＤＣＫ＿ＳＴＡＴ）は、バッチ可視度チェックをサポートする次のフィールドから構成される。ＲＯＷ＿ＩＤ：プライマリ・キー。ＮＯＤＥ＿ＩＤ：この状態情報を所有するモバイル・クライアントのアイデンティティ。ＴＹＰＥ：このフィールドを使って、ＶＡＬフィールドを解釈し、ストリング「ＥＸＴＲＡＣＴ＿ＲＥＣＯＲＤ」、「ＬＯＧ＿ＥＸＴＲＡＣＴ」、「ＭＥＲＧＥ＿ＲＥＣＯＲＤ」、「ＬＡＳＴ＿ＭＥＲＧＥ」、または「ＳＥＳＳＩＯＮ」の１つが入る。ＶＡＬ：このフィールドには、ＴＹＰＥフィールドのデータタイプに対応する値が入る。さらに、このテーブルは、ログ・プリプロセッサと呼ばれる実行可能プログラムが処理する最後のトランザクションを記録する。これは、ＶＡＬフィールドでゼロのＲＯＷＩＤおよび「ＥＸＴＲＡＣＴ＿ＲＥＣＯＲＤ」のＴＹＰＥを持つ行について示される。トランザクション・テーブル３０６は、すべてのモバイル・クライアントにルート(route)される必要のあるトランザクションを保存する。トランザクション・テーブル３０６（Ｓ＿ＤＣＫ＿ＴＸＮ＿ＬＯＧ）は、バッチ可視度チェックをサポートする次のフィールドから構成される。ＴＸＮ＿ＩＤ：トランザクションを識別する非ゼロのプライマリ・キー。ＤＯＢＪ＿ＩＤ：このドッキング・オブジェクト・インスタンスが関連するドッキング・オブジェクトの非ゼロユーザ・キー。ＰＲ＿ＴＢＬ＿ＲＯＷ＿ＩＤ：ドッキング・オブジェクトのプライマリ・テーブルの行ＩＤの入った非ゼロユーザ・キー。この値は、ドッキング・オブジェクト・インスタンスを識別する。ＶＩＳ＿ＥＶＴ＿ＦＬＧ：このフィールドには、値「Ｙ」または「Ｎ」を含み、トランザクションが可視度イベントを生じるか否かを示す。ＶＩＳ＿ＬＥＶＥＬ＿ＦＬＧ：このフィールドは、ドック・オブジェクトの可視度レベルを示す。値「Ｌ」はドック・オブジェクトが制限された可視度を有することを示す。値「Ｐ」は、ドック・オブジェクトがプライベートであることを示す。値「Ｅ」このオブジェクトがエンタープライズ可視度であることを示す。バッチ可視度チェックは、４つのフェーズにより実行される。簡単に言うと、フェーズ1はトランザクション・ログ・テーブル３００の各トランザクションについて1回実行され、トランザクション・ログ・データを構成テーブルにデノーマライズ(denormalize)する。フェーズ２は、1反復あたり1モバイル・クライアントに1回実行され、モバイル・クライアントの可視度イベントをチェックする。フェーズ３は、１反復あたり１モバイル・クライアントに1回実行され、モバイル・クライアントの可視トランザクションを抽出する。フェーズ４は、１反復あたり１回実行され、トランザクション・ログ・テーブル３００からトランザクションを削除する。４つのフェーズすべての詳細を以下に説明する。本発明のある実施形態では、フェーズ１および４を、ログ・プリプロセッサと呼ばれる１つの実行可能プログラムに組み合わせることができる。１つのログ・プリプロセッサのみが、いかなる時でも1つのインストールに対して実行される。１つのインストールに対して同時に1つ以上のプリプロセッサを実行できる。フェーズ２および３を、ログ・ルータと呼ばれる１つの実行可能プログラムに組み合わせることができる。１つ以上のログ・ルータを、１つのインストールに対して同時に実行することができる。ログ・ルータ・プログラムは、セマフォを使い、１つ以上のログ・ルータがトランザクションを同じモバイル・クライアントに同時にルーティングするのを防ぐ。フェーズ１は、トランザクション・ログ・テーブル３００の各トランザクションについて1回実行され、構成テーブルにトランザクション・ログ・データをデノーマライズする。このフェーズは、トランザクション・ログ・データに基づき、ＳＤ、ＣＫ＿ＴＸＮ＿ＬＯＧの値をデノーマライズする。以下の擬似コードはフェーズ１のオペレーションを詳細に記述する。フェーズ２は、１反復あたり１モバイル・クライアントに1回実行され、モバイル・クライアントの可視度イベントをチェックする。このフェーズは、すべての可視度イベント・トランザクションを探し、可視度を再計算する。このフェーズは、可視度変更に応答してドッキング・オブジェクト・インスタンスをダウンロードし、取り除いて、ドッキング・オブジェクト・インスタンスの可視度をテーブルＳ＿ＤＯＢＪ＿ＩＮＳＴ６３に保存する。以下の擬似コードは、フェーズ２のオペレーションを詳細に記述する。フェーズ３は、１反復あたり１モバイル・クライアントに1回実行され、そのモバイル・クライアントの可視トランザクションを抽出する。以下の擬似コードは、フェーズ３のオペレーションを詳細に記述する。フェーズ４は、１反復あたり1回実行され、トランザクション・ログ・テーブル３００から、置換されたトランザクション・テーブル３０６とセット・トランザクションＩＤテーブル３０８を含む使用されないトランザクションを削除する。以下の擬似コードは、フェーズ４のオペレーションを詳細に記述する。可視度キャッシング(caching) 最近の可視度イベントをキャッシュする能力を備えることによって、パフォーマンスを改善できる。Ｓ＿ＤＯＢＪ＿ＩＮＳＴテーブル６３は、このような「可視度キャッシュ」を提供するのに特に適している。「Ｓ＿ＤＯＢＪ＿ＩＮＳＴ」テーブル６３にある特定のドッキング・オブジェクト・インスタンスの存在を使って、ドッキング・オブジェクト・インスタンスがモバイル・クライアントに可視であることを主張することができる。可視度キャッシュは、２つの方法でパフォーマンスを改善する。第１に、可視度を計算しなければならない回数を減らす。ログ・マネージャ９は、トランザクションが暗黙的（implicit）可視度イベントを生じないテーブルにある時（すなわち、ＶＩＳＩＢＩＬＩＴＹ＿ＥＶＴ＿ＦＬＧをテーブルについてチェックしない）、ドッキング・オブジェクト・インスタンスの可視度を決定するために、メモリーのキャッシュを使用することができる。ログ・マネージャは、トランザクションの可視度を決定するために可視度ＳＱＬステートメントを実行させる必要がない。トランザクションが可視度イベントを生じるテーブルに影響を与える場合、ログ・マネージャは可視度ＳＱＬステートメントを再実行させてそのトランザクションの可視度を決定しなければならないことに注意する。第２に、可視度キャッシュは、可視度計算1回あたりに実行されるＳＱＬステートメントの数を減らす。ログ・マネージャは、チェック・ドッキング・オブジェクトの可視度を決定するために、キャッシュを使用する。ログ・マネージャは、トランザクションの可視度を決定するのに、各チェック・ドッキング・オブジェクト・インスタンスで可視度ルールＳＱＬステートメントを繰り返し動作させる必要がない。その代わり、ログ・マネージャ９はＳ＿ＤＯＢＪ＿ＩＮＳＴテーブル６３に加わってチェック・ドッキング・オブジェクトの可視度を決定する。前に述べたように、ログ・マネージャは2種類の可視度ルールを用いるが、これはＳＱＬルールとチェック・ドッキング・オブジェクト・ルールとしてまとめることができる。ＳＱＬルールは、ドッキング・オブジェクト・インスタンスが可視であるか否かを表現するＳＱＬフラグメントである。機会ドッキング・オブジェクトに関してＳＱＬルールが指定する可視度条件の例は、「販売員が販売チームにいる場合、機会が可視である」というものである。チェック・ドッキング・オブジェクト・ルールは、他のドッキング・オブジェクトが可視の場合にドッキング・オブジェクト・インスタンスが可視であることを示す。チェック・ドッキング・オブジェクト・ルールの定義には、ログ・マネージャにドッキング・オブジェクト・インスタンスのすべてのチェック・ドッキング・オブジェクトを得る方法を教えるＳＱＬフラグメントが入っている。機会ドッキング・オブジェクトに関してチェック・ドッキング・オブジェクト・ルールが指定する可視度条件の例は、「販売員にとって可視の見積もりによって機会を用いる場合、機会は可視である」というものである。ＳＱＬルールは実行リソースが比較的安価である。対照的に、チェック・ドッキング・オブジェクト・ルールは、多くのリソースを消費するため、高価である。チェック・ドッキング・オブジェクト・ルールを実行するため、ログ・マネージャは、チェックしているドッキング・オブジェクトの可視度ＳＱＬステートメントを繰り返し実行する。トランザクションの可視度の決定には、数百、あるいは数千のＳＱＬステートメントの実行が必要なことがある。あるオブジェクトには、8個から10個のチェック・ドッキング・オブジェクト・ルールがある。これらオブジェクトについてすべての可視度ルールＳＱＬステートメントを実行するには、各モバイル・クライアントについて０．２５秒から数秒かかる。モバイル・クライアントの数が増加すれば、望ましくないサービスの低下につながる。ログ・マネージャはまた、Ｓ＿ＤＯＢＪ＿ＩＮＳＴテーブルを使ってドッキング・オブジェクト・インスタンス（例えば、特定の機会インスタンス）をモバイル・クライアントにダウンロードしたか否かを追跡する。Ｓ＿ＤＯＢＪ＿ＩＮＳＴテーブルは、ログ・マネージャが既に以前にダウンロードしたドッキング・オブジェクト・インスタンスをダウンロードしたり、既に以前に取り除いたドッキング・オブジェクト・インスタンスを取り除いたりするのを防ぐ。可視度キャッシュは、２つの方法で実現される。第１に、Ｓ＿ＤＯＢＪ＿ＩＮＳＴテーブルを、非可視度イベント・テーブルのトランザクションに用いる。トランザクションの可視度をチェックする時、トランザクションが可視度イベントを生じないテーブルにある場合（Ｓ＿ＤＯＢＪ＿ＴＢＬ．ＶＩＳ＿ＥＶＴ＿ＦＬＧ＝‘Ｎ’）、次にＳ＿ＤＯＢＪ＿ＩＮＳＴテーブルを使ってドッキング・オブジェクト・インスタンスが可視か否かを決定する。トランザクションのドッキング・オブジェクト・インスタンスがＳ＿ＤＯＢＪ＿ＩＮＳＴテーブルに存在する場合、トランザクションはモバイル・クライアントに可視である。そうでない場合、トランザクションはモバイル・クライアントにとって可視でない。この利点は、ログ・マネージャが可視度ＳＱＬルールやチェック・ドッキング・オブジェクト・ルールを実行して可視度を決定する必要がない点である。第2に、Ｓ＿ＤＯＢＪ＿ＩＮＳＴテーブルを使って、チェック・ドッキング・オブジェクトの可視度を決定する。チェック・ドッキング・オブジェクト・ルールの大半は、チェック・ドッキング・オブジェクトをＳ＿ＤＯＢＪ＿ＩＮＳＴテーブルに結合するＳＱＬルールに変換できる。チェック・ドッキング・オブジェクトがＳ＿ＤＯＢＪ＿ＩＮＳＴテーブルに存在する場合、チェック・ドッキング・オブジェクトはモバイル・クライアントにとって可視でなければならない。この利点は、ログ・マネージャがせいぜ１つのＳＱＬステートメントを実行してチェック・ドッキング・オブジェクトの可視度を決定する点である。以下の例は、可視度キャッシュの利点を示すものである。可視度キャッシュなしに、顧客を表すドッキング・オブジェクトの可視度のチェックに用いるルールセットは、以下の４つのルールで表現される。顧客ドッキング・オブジェクトの可視度を可視度キャッシュなしにチェックするには、ログ・マネージャは以下のステップを実行して、上記可視度ルールに基づくＳＱＬステートメントを生成・実行する。取り出した各機会について、可視度ルールＳＱＬステートメント（ＳＱＬルールとチェック・ドッキング・オブジェクト・ルール）を実行し、機会が可視か否か決定する。これは多くのＳＱＬステートメントであり得る。取り出した各見積もりについて、可視度ルールＳＱＬステートメント（ＳＱＬルールとチェック・ドッキング・オブジェクト・ルール）を実行し、見積もりが可視か否か決定する。これは多くのSQＬステートメントであり得る。このプロセスが実行するＳＱＬステートメントの総数は、１+（ＯｐｔｙＣｈｅｃｋＯｂｊｓ＊Ｏｐｔｙｖｉｓｒｕｌｅｓ）+（ＱｕｏｔｅＣｈｅｃｋＯｂｊｓ＊Ｑｕｏｔｅｖｉｓｒｕｌｅｓ）で計算できる。これは、取り出した機会および見積もりオブジェクトの数により、１つのステートメントから数百のステートメントまでさまざまである。可視度キャッシュがある場合、顧客を表すドッキング・オブジェクトの可視度をチェックするために用いるルールセットは、以下の４つのルールで表現される。２つのＳＱＬルール１および２は変更がない。２つのチェック・ドック・オブジェクト・ルールが、ＳＤＯＢＪ＿ＩＮＳＴテーブルを問い合わせるＳＱＬルールに置き換わる。可視度キャッシュを使って顧客ドッキング・オブジェクトの可視度をチェックするには、ログ・マネージャは４つのＳＱＬルールから導き出した１つのＳＱＬステートメントを生成・実行する。ログ・マネージャは４つのＳＱＬルールのすべてを共にＯＲして、次のような１つのＳＱＬルールを取得する。この１つのＳＱＬステートメントは、可視度キャッシュなしでは必要だった数百に上る可能性のあるＳＱＬステートメントと同じ結果を達成する。ＳＱＬステートメントは非常に大きくなることがあるので、ログ・マネージャが共にＯＲするＳＱＬルールの数に制限を設けることが望ましい。この制限は、特定の構成に関するガスタマイズを容易にするパラメータ駆動であることが望ましい。ある実現においては、ＳＱＬステートメントのテーブル数を約１６に制限すると便利である。以下のＳＱＬフラグメントはそれぞれ、Ｓ＿ＤＯＢＪ＿ＩＮＳＴテーブルに結合するメカニズムを提供する。特定の実現に最良のフラグメントは、その実現のパフォーマンス特性によって変化する。以下の擬似コードは、可視度キャッシュを使った可視度チェックエンジンのアルゴリズムを示す。このアルゴリズムは、ＣｈｅｃｋＴｘｎＶｉｓｉｂｉｌｉｔｙ，ＣｈｅｃｋＯｂｊｅｃｔＶｉｓｉｂｉｌｉｔｙ，ＣｈｅｃｋＳｑｌＲｕｌｅおよびＣｈｅｃｋＯｔｈｅｒＲｕｌｅと表される４つルーチンとして文書化される。可視度の程度ドッキング・プロセスは、非バイナリー条件としてオブジェクト可視度を取り扱うことによりさらに強化される。すなわち、あるコンテキストで可視で他で可視でないよう、オブジェクトに可視度の程度を持たせることである。これは、可視度強度に各ドック・オブジェクト可視度ルールを関連させることによって提供されることができる。可視度強度は、あるドック・オブジェクト・インスタンスがどのように可視であるかを記述する正の整数である。可視度強度は、完全および部分的に可視のドック・オブジェクト・インスタンスのコンセプトの代替となる。可視度を完全または部分的のいずれかとして指定するのではなく、可視度強度によって、あるオブジェクトの可視度に制限されない範囲を与える。可視度ルールがパスしたら、ドック・オブジェクト・インスタンスはその可視度ルールに関連する可視度強度を受け取る。この可視度強度は、２つの側面を制御する。可視度強度が制御する第1の側面は、メンバ・テーブル行のダウンロードまたは除去である。各メンバ・テーブルも可視度強度を持っている。ドッキングは、ドック・オブジェクト・インスタンスの可視度強度がメンバ・テーブルの可視度強度より大きいかこれと等しい場合にのみ、メンバ・テーブル行をダウンロード（あるいは除去）する。この側面を使って、ドッキング・クライアントに複製されるメンバ・テーブル行の数を制限することができる。例えば、顧客が見積もりによって可視である場合、ドッキングは顧客ヘッダをダウンロードしなければならないが、顧客ノート、顧客地位、その他メンバ・テーブルの行をダウンロードする必要はない。ログ・マネージャのダウンロードおよび除去処理は、ログ・マネージャが一定のメンバ・テーブルのダウンロードおよび除去をスキップできるため向上する。さらに、ドッキングがドッキング・クライアントに複製する行が少なくなり、ドッキング・クライアントが占有するディスク・スペースが少なくなる。可視度強度が制御する第2の側面は、関連するドック・オブジェクト・インスタンスのダウンロードまたは除去である。各関連ドック・オブジェクト・ルールにも可視度強度がある。ドック・オブジェクト・インスタンスが可視の場合、ドッキングは、ドック・オブジェクト・インスタンスの可視度強度が関連するドック・オブジェクト・ルールの可視度強度より大きいかこれと等しい場合にのみ、関連するドック・オブジェクト・インスタンスをダウンロード（あるいは除去）する。この側面を使って、ドック・オブジェクト・インスタンスが可視である理由により、関連ドック・オブジェクトのサブセットをフォローすることができる。これによって、ドッキングは、ドック・オブジェクト・インスタンスが部分的に可視でも関連ドック・オブジェクトのサブセットをフォローすることができる。可視度強度は、レポジトリな（repository）ドック・オブジェクト・テーブル、ドック・オブジェクト可視度ルール、ドック・オブジェクト関連ドック・オブジェクト・ルールに新しい属性を追加することで実現する。これら新しい属性は、メンバ・テーブル、可視度ルール、関連ドック・オブジェクト・ルールの可視度強度を指定する。各ドック・オブジェクト可視度ルールは可視度強度を持つ。可視度ルールがパスすると、ドック・オブジェクト・インスタンスの可視度強度は、パスしたすべての可視度ルールの可視度強度の最高値に等しい。ドック・オブジェクト・インスタンス可視度強度は、どのメンバ・テーブル行をドッキング・クライアントに複製し、どの関連ドック・オブジェクト・ルールを実行するかを指定する。チェック・ドック・オブジェクト可視度ルールも、チェック・ドック・オブジェクト可視度強度を持つ。チェック・ドック・オブジェクト可視度強度値は、他のドック・オブジェクト・インスタンスがチェック・ドック・オブジェクト可視度強度値より大きいか等しい可視度強度を持つ場合のみ、現在のドック・オブジェクト・インスタンスが可視であると指定する。可視度強度は、ドック・オブジェクト・インスタンスの強度を指定する属性ＶＩＳ＿ＳＴＲＥＮＧＴＨで示す。この属性の意味は、現れるテーブルのコンテキストによって変わるが、より詳しくここに述べる。ＶＩＳ＿ＳＴＲＥＮＧＴＨは次の値を持つことができる。０：可視でない５：部分的に可視１０：完全に可視データベース・スキーマ中の多数のテーブルを、ＶＩＳ＿ＳＴＲＥＮＧＴＨ属性をサポートするよう修正する。Ｓ＿ＤＯＣＫ＿ＴＡＢＬＥテーブルは、あるドッキング・オブジェクトのメンバ・テーブルを保存する。各ドッキング・オブジェクトは、１つ以上のメンバ・テーブルを持つことができる。テーブルは、追加フィールド、ＶＩＳ＿ＳＴＲＥＮＧＴＨを含む。ＶＩＳ＿ＳＴＲＥＮＧＴＨは、ダウンロードするこのテーブルの行について、ドック・オブジェクト・インスタンスの最小可視度強度を含んだ数値フィールドである。このフィールドのデフォルト値は５で、ドック・オブジェクト・インスタンスが部分的に可視の場合、メンバ・テーブル行をダウンロードすることを示す。Ｓ＿ＤＯＣＫ＿ＶＩＳ＿ＲＵＬＥテーブルは、あるドッキング・オブジェクトの可視度ルールを保存する。各ドッキング・オブジェクトは１つ以上の可視度ルールを持つことができる。テーブルは、追加フィールド、ＶＩＳ＿ＳＴＲＥＮＧＴＨを含む。ＶＩＳ＿ＳＴＲＥＮＧＴＨは、ルールがパスした場合、ドック・オブジェクト・インスタンスの可視度強度を含む数値フィールドである。このフィールドのデフォルト値はＰＡＲＴＩＡ＝‘ｙ’の場合、５で（部分的に可視）、そうでない場合は１０に設定される。Ｓ＿ＤＯＣＫ＿ＶＩＳ＿ＲＵＬＥテーブルには、ＣＨＥＣＫ＿ＶＩＳ＿ＳＴＲＥＮＧＴＨフィールドも含まれ、チェック・ドック・オブジェクト・ルール（すなわち、ルールタイプ＝‘Ｃ’ のあるルール）に用いられる。この値は、この可視度ルールをパスさせるためのチェック・ドック・オブジェクト・インスタンスの最小可視度強度を表す。このフィールドのデフォルト値は１０で、ルールタイプ＝‘Ｃ’ではチェック・ドック・オブジェクトは完全に可視でなければならず、そうでない場合は使用せず、０に設定される。Ｓ＿ＤＯＣＫ＿ＲＥＬ＿ＯＢＪテーブルには、あるドッキング・オブジェクトの関連ドック・オブジェクト・ルールが保存される。各ドッキング・オブジェクトには、1つ以上の関連ドック・オブジェクト・ルールを持つことができる。このテーブルは、追加フィールド、ＶＩＳ＿ＳＴＲＥＮＧＴＨを含む。ＶＩＳ＿ＳＴＲＥＮＧＴＨは、ログ・マネージャがこのルールを実行するためのドック・オブジェクト・インスタンスの最小可視度強度を含んだ数値フィールドである。デフォルト値は１０で、完全な可視度を必要とする。Ｓ＿ＤＯＣＫ＿ＲＥＬ＿ＯＢＪテーブルは、フィールドＲＥＬ＿ＶＩＳ＿ＳＴＲＥＮＧＴＨをも含む。このフィールドは、関連ドック・インスタンスに可視度強度値を与えるために使われる値を含んでいる。このデフォルト値は５である。る。このデフォルト値は５である。Ｓ＿ＤＯＣＫ＿ＩＮＳＴテーブルは、Ｓ＿ＤＯＢＪ＿ＩＮＳＴに代わる新しいテーブルで、各ドッキング・クライアントのドック・オブジェクト・インスタンスの現在の可視度強度を保存する。これは次のフィールドを持つ。ＮＯＤＥ＿ＩＤは非ゼロのユニークなキーで、この行に対応するドッキング・クライアントを示す。ＤＯＣＫ＿ＩＤは非ゼロのユニークなキーで、このドック・オブジェクト・インスタンスに対応するドック・オブジェクトを示す。ＰＲ＿ＴＢＬ＿ＲＯＷ＿ＩＤには、ドック・オブジェクト・インスタンスのプライマリ・テーブル行ｉｄであるキーが含まれる。ＶＩＳ＿ＳＴＲＥＮＧＴＨは、ドッキング・クライアントのドック・オブジェクト・インスタンスの現在の可視度強度を含んだ数値フィールドである。以下のＳＱＬコードを使って、次のようにＳ＿ＤＯＣＫ＿ＩＮＳＴテーブルを定義することができる。Ｓ＿ＤＣＫ＿ＴＸＮ＿ＬＯＧテーブルは、ドッキング・クライアントにルーティングするトランザクションを保存する。このテーブルは、追加フィールド、ＶＩＳ＿ＳＴＲＥＮＧＴＨを含む。ＶＩＳ＿ＳＴＲＥＮＧＴＨは、トランザクションが参照するテーブルの可視度強度を含んだ数値フィールドである。この値は、ログ・プリプロセッサがデノーマライズして、ログ・ルータ（Router）が使用すルを次のように定義することができる。ログ・マネージャ処理ログ・マネージャは、ドック・オブジェクト・インスタンスの可視度強度が、メンバ・テーブルの可視度強度より大きいか等しい場合のみドッキング・クライアントにトランザクションを送る。ログ・プリプロセッサは、トランザクション・ログ・テーブルにデノーマライズした値としてメンバ・テーブル可視度強度を保存する。ログ・ルータが可視度イベントを処理すると、可視度ルールがパスするまで、可視度強度の降順で可視度ルールが実行される。可視度ルールがパスすると、ドック・オブジェクト・インスタンスはパスする可視度ルールの可視度強度を受け取る。可視度ルールが１つもパスしないと、ドック・オブジェクト・インスタンスは、なしの可視度強度（値＝０）を得る。可視度強度を計算した後、ドック・オブジェクト・インスタンス可視度強度が０でなければ、ドック・オブジェクト・インスタンスの可視度強度がＳ＿ＤＯＣＫ＿ＩＮＳＴテーブルに書きこまれる。ログ・ルータが可視のトランザクションを検索する時、Ｓ＿ＤＯＣＫ＿ＩＮＳＴテーブルがトランザクション・ログのデノーマライズしたメンバ・テーブルの可視度強度より大きいか等しい可視度強度を持つ場合のみ、トランザクションがフェッチされる。ログ・マネージャはメンバ・テーブルの可視度強度属性を使って、ダウンロードまたは除去するメンバ・テーブル行を識別する。ドック・オブジェクト・インスタンスの可視度強度が変化すると、ログ・マネージャはそのドック・オブジェクト・インスタンスのメンバ・テーブル行をダウンロードまたは除去する。新しい可視度強度が古い可視度強度より大きい場合、参照したメンバ・テーブル行は以前にダウンロードされておらず、ここでダウンロードしなければならない。新しい可視度強度が古い可視度強度より小さい場合、ログ・マネージャは、以前にダウンロードしたメンバ・テーブル行を除去し、ここでダウンロードしてはならない。関連ドック・オブジェクト・ルールを処理する場合、ログ・マネージャは各ルールの可視度強度の属性を使ってどの関連ドック・オブジェクト・ルールを実行するか識別する。ドック・オブジェクトの可視度強度が変化せず、可視度強度がなしでない場合、ログ・マネージャは関連ドック・オブジェクト・インスタンスをチェックし、その可視度強度が変化していないことをベリファイする。ドック・オブジェクト・インスタンスの可視度強度が変化すると、ログ・マネージャは、すべての関連ドック・オブジェクト・インスタンスをチェックし、必要に応じて関連ドック・オブジェクト・インスタンスをダウンロードまたは除去する。新しい可視度強度が古い可視度強度より大きい場合、ログ・マネージャは以前に実行しておらず、ここで実行しなければならない関連ドック・オブジェクト・ルールを実行する。新しい可視度強度が古い可視度強度より小さい場合、ログ・マネージャは以前に実行して、ここで実行してはならない関連ドック・オブジェクト・ルールを実行する。ログ・マネージャは、各ルールのｒｅｌＶｉｓＳｔｒｅｎｇｔｈの属性を使って可視度チェックを減らす。新しい可視度強度が古い可視度強度より大きいか等しい場合で、ログ・マネージャが関連ドック・オブジェクト・インスタンスを発見し、関連ドック・オブジェクトのｒｅｌＶｉｓＳｔｒｅｎｇｔｈが他のドック・オブジェクトの最大可視度ルールｖｉｓＳｔｒｅｎｇｔｈより大きいか等しい場合、ログ・マネージャは他のドック・オブジェクト・インスタンスの可視度を再チェックする必要はない。関連ドック・オブジェクト・インスタンスｖｉｓＳｔｒｅｎｇｔｈを関連ドック・オブジェクトのｒｅｌＶｉｓＳｔｒｅｎｇｔｈに設定する。単純化されたドッキング可視度ルール本発明のユーティリティは、ドッキング可視度ルールを単純化することでより便利になる。特に、ドッキング可視度ルールを１つの場所、中央ディクショナリに保存して、ログ・マネージャがトランザクションを抽出してモバイル・クライアントにルートするのに同じ定義に依存するようにできる。地位依存性、従業員依存性、チェック・ドック・オブジェクト・ルールなどの共通して必要な可視度タスクをサポートするために前もって定義されたドッキング可視度ルールも提供されることができる。このアプローチにはいくつかの利点がある。第１に、すべてのドッキング可視度ルールを中央ディクショナリに保存することで、ログ・マネージャは同じ定義を使ってモバイル・クライアントにトランザクションをルートし、ドッキング可視度ルールを保持するコストを減らすことができる。これによって異なる各データベース・ベンダー（Ｓｙｂａｓｅ^TM，Ｏｒａｃｌｅ^TMまたはＩｎｆｏｒｍｉｘ^TM等）について、ＳＱＬスクリプトを保持する必要もなくなる。第２に、ベンダー供給アプリケーションが広く用いる前もって定義された可視度ルールを定義できる。これらルールによって、ＳＱＬフラグメントの入力や関連ドッキング・オブジェクト・ルールの定義が不要になる。代表的なアプリケーションのすべての可視度ルールの９０％は、所定の可視度ルールを用いることができる。第3に、中央ディクショナリによって、顧客がドッキング・オブジェクト・リスト・ビューを使ってドッキング可視度ルールを簡単にカスタマイズしてサイト固有の要件を満たすことができる。顧客はまた、可視度ルールの属性を変更することで、可視度ルールを簡単に起動または非起動にすることもできる。単純化された可視度ルールによって、エンドユーザなどのクライアントは、使いやすいグラフィカル・ユーザ・インターフェイスを使って可視度ルールを変更することができる。これにより、小セットの顧客専用の可視度ルールを非アクティブなルールと定義し、その顧客に専用ルールを起動させることで、過半数の顧客にとってパフォーマンスが改善する。専用ルールを使わない顧客には専用ルールのパフォーマンス・コストがかからない。第４に、統一された場所にすべてのドッキング可視度ルールを保存することで、将来のドッキング強化構築が容易になる。単純化ドッキング・ルールは次のように実現する。5種類の新しい可視度ルールを定義し、中央ディクショナリに保存する。１）チェック・ドック・オブジェクト・ルールは２つのドッキング・オブジェクト・インスタンスをＳＱＬフラグメントを使用せずに互いと関連させる。チェック・ドック・オブジェクト・ルールはＳＱＬルールに似ているが、２つのドッキング・オブジェクト間のチェック・ドック・オブジェクトの定義をＳＱＬフラグメントの代わりに保存する点が異なる。例えば、完全に可視のアクティビティが機会を使う場合、機会は可視である。２）地位ルールは、ドッキング・クライアントの従業員がそのドッキング・オブジェクトの地位を占めていれば、ドッキング・オブジェクト・インスタンスが可視であると指定する。例えば、ドッキング・クライアントの従業員が機会販売チーム・メンバなら、機会は可視である。３）地位マネージャ・ルールは、ドッキング・クライアントの従業員がそのドッキング・オブジェクトの地位を占める従業員のマネージャならドッキング・オブジェクト・インスタンスが可視であると指定する。例えば、ドッキング・クライアントの従業員が機会販売チーム・メンバのマネージャである場合、機会は可視である。４）従業員ルールは、ドッキング・クライアントの従業員がドッキング・オブジェクトに割り当てられる場合、ドッキング・オブジェクト・インスタンスが可視と指定する。例えば、ドッキング・クライアントの従業員がアクティビティに割り当てられる場合、アクティビティは可視である。従業員ルールは一般に所有者、作成者などについて用いる。５）従業員マネージャ・ルールは、ドッキング・クライアントの従業員がドッキング・オブジェクトに割り当てられた従業員のマネージャである場合にドッキング・オブジェクト・インスタンスが可視と指定する。例えば、ドッキング・クライアントの従業員がアクティビティに割り当てられた従業員のマネージャである場合、アクティビティは可視である。従業員マネージャ・ルールは、一般に所有者のマネージャ、作成者のマネージャなどに用いられる。ログ・マネージャでは、可視度ＳＱＬステートメントは実行時間中に中央ディクショナリから生成する。コードを可視度チェッカー共通ＡＰＩに追加して、新しい可視度ルールタイプのＳＱＬステートメントを生成・実行する。ログ・マネージャの可視度イベント・コードを修正して、新しいタイプの可視度ルールを使い、関連ドッキング・オブジェクト・インスタンスを見つける。図１０は、中央ディクショナリのデータベース図を示す。この図は、図２のスキーマに似ているが、Ｓ＿ＤＯＣＫ＿ＶＩＳ＿ＲＵＬＥテーブルに以下のように追加サポートが追加される。Ｓ＿ＤＯＣＫ＿ＶＩＳ＿ＲＵＬＥテーブルは、特定のドッキング・オブジェクトに関連する可視度ルールを含む。Ｓ＿ＤＯＣＫ＿ＶＩＳ＿ＲＵＬＥ７１は、ＤＯＣＫ＿ＩＤ，ＳＥＱＵＥＮＣＥ，ＴＹＰＥ，ＡＣＴＩＶＥおよびＰＡＲＴＩＡＬの追加フィールドを含む。フィールドＤＯＣＫ＿ＩＤは、特定の可視度ルールが関連し、「現在のドッキング・オブジェクト」と呼ばれるドッキング・オブジェクトを識別する。フィールドＳＥＱＵＥＮＣＥは、テーブルの他の可視度ルールに対して、特定の可視度ルールを実行しなければならないシーケンスを示すシーケンス番号である。ＡＣＴＩＶＥフィールドは、特定ルールがアクティブか否かを示す。「Ｙ」またはゼロの値は、ルールがアクティブであること、「Ｎ」の値は非アクティブであることを示す。フィールドＴＹＰＥは、特定の可視度ルールのタイプを指定する。「Ｓ」の値は、ＳＱＬルール、「Ｏ」の値はパラメータ・ドック・オブジェクト・ルールを示す。「Ｃ」の値はチェック・ドック・オブジェクト・ルールを示し、「Ｐ」の値は、地位ルールを示す。「Ｑ」の値は地位マネージャ・ルール、「Ｅ」は従業員ルール、「Ｆ」の値は従業員マネージャ・ルールを示す。フィールドＰＡＲＴＩＡＬは、「Ｙ」に設定されている場合、可視度ルールを満たす場合、現在のドッキング・オブジェクトが部分的に可視であることを示す。「Ｎ」またはゼロに設定されている場合、可視度ルールを満たす場合、現在のドッキング・オブジェクト・インスタンスは完全に可視であることを示す。さらに、Ｓ＿ＤＯＣＫ＿ＶＩＳ＿ＲＵＬＥテーブルは、ルールタイプによってその意味と有意性が決まる多数のフィールドを含む。ＳＱＬルールは、ＳＱＬ＿ＳＴＡＴＥＭＥＮＴとＶＩＳ＿ＥＶＴ＿ＣＯＬＳフィールドを用いる。このコンテキストで、ＳＱＬ＿ＳＴＡＴＥＭＥＮＴフィールドは、行を戻す場合は、ドック・オブジェクト・インスタンスが可視であることを示すＳＱＬフラグメントである。パラメータ・ドック・オブジェクト・ルールは、フィールドＣＨＥＣＫ＿ＤＯＣＫ＿ＩＤとＳＱＬ＿ＳＴＡＴＥＭＥＮＴを使う。このコンテキストで、ＣＨＥＣＫ＿ＤＯＣＫ＿ＩＤは、別のドッキング・オブジェクトへのポインターを含み、ＳＱＬ＿ＳＴＡＴＥＭＥＮＴは、他のドック・オブジェクトのプライマリＩＤ値を取得するＳＱＬステートメントを含む。取り出した各プライマリＩＤについて、ログ・マネージャは他のドック・オブジェクトの可視度ルールを動作させる。チェック・ドック・オブジェクト・ルールは、フィールドＣＨＥＣＫ＿ＤＯＣＫ＿ＩＤ，ＳＲＣ＿ＣＯＬＵＭＮ＿ＩＤおよびＴＡＲ＿ＣＯＬＵＭＮ＿ＩＤを用いる。このコンテキストで、ＳＲＣ＿ＣＯＬＵＭＮ＿ＩＤは、チェック・ドック・オブジェクトに結合する現在のドック・オブジェクトの列を識別し、ＴＡＲ＿ＣＯＬＵＭＮ＿ＩＤは、ドック・オブジェクト結合列に結合するチェック・ドック・オブジェクトの列を識別する。チェック・ドック・オブジェクト・タイプについては、可視度イベント列は暗黙なもので、現在のドック・オブジェクトのプライマリ・テーブルからドック・オブジェクト結合列に結合する必要のあるすべての列である。地位ルールは、Ｓ＿ＰＯＳＴＮテーブルを指す現在のドック・オブジェクトのテーブルのメンバの列であるフィールドＰＯＳＴＮ＿ＣＯＬＵＭＮ＿ＩＤを使う。地位ルールについては、可視度イベント列は暗黙なもので、現在のドック・オブジェクトのプライマリ・テーブルから地位列に結合する必要のあるすべての列である。地位マネージャ・ルールは、Ｓ＿ＰＯＳＴＮテーブルを指す現在のドック・オブジェクトのテーブルのメンバの列であるフィールドＰＯＳＴＮ＿ＣＯＬＵＭＮ＿ＩＤを使う。地位マネージャ・ルールについては、可視度イベント列は暗黙なもので、現在のドック・オブジェクトのプライマリ・テーブルから地位列に結合する必要のあるすべての列である。従業員ルールは、Ｓ＿ＥＭＰＬＯＹＥＥテーブルを指す現在のドック・オブジェクトのメンバ・テーブルの列を識別するフィールドＥＭＰ＿ＣＯＬＵＭＮ＿ＩＤを使う。従業員ルールについては、可視度イベント列は暗示で、現在のドック・オブジェクトのプライマリ・テーブルから従業員列に結合する必要のあるすべての列である。従業員マネージャ・ルールは、Ｓ＿ＰＯＳＴＮテーブルを指す現在のドック・オブジェクトのメンバ・テーブルの列を識別するフィールドＥＭＰ＿ＣＯＬＵＭＮ＿ＩＤを使う。従業員マネージャ・ルールについては、可視度イベント列は暗黙なもので、現在のドック・オブジェクトのプライマリ・テーブルから従業員列に結合する必要のあるすべての列である。ＳＱＬステートメントは、中央ディクショナリ・メモリー構造に保存し、ログ・マネージャがアクセスできるようにする。ディクショナリをロードすると、ＳＱＬステートメントを生成し、メモリー構造に保存する。ＳＱＬステートメントの数が小さいため、生成コードは1秒かからないと予想される。あるいは、生成に時間がかかりすぎる場合、ディクショナリＡＰＩを修正して、ドック・オブジェクトが最初に参照された時は常に、あるドック・オブジェクトのＳＱＬステートメントを生成することができる。付属物Ｂに、ログ・マネージャが実行時間中に生成するフォーマットＳＱＬステートメントを記述し、顧客ドック・オブジェクトを使ったこれらＳＱＬステートメントの例を示す。結論これら実施例の各種修正は当業者にとって明白であり、ここに定義する総括的な原則は、発明的能力を利用せずに他の実施例に適用できる。そのため、本発明は、ここに示す実施例に限定するものではなく、ここに開示される原則と新規な特徴と一貫した最も広い思想に一致する。本明細書で述べたすべての刊行物および特許出願は、各刊行物または特許出願を参照として組み込んだ、特定且つ個々に示されたと同程度に、参照としてここに組み込まれる。ここで本発明を完全に記述したが、当業者にとって、そこから離れることなく多くの変更および修正が可能なことは明白である。付属物Ａ与えられたラップトップ・ノードのユーザ・トランザクション・ログ・ファイルの書き方このプログラムは、すべてのラップトップ・ノードのトランザクション・ログ・エントリーを処理するサーバ側プロセスにより呼び出される。各ラップトップ・ノードについて、呼び出しはＵｓｅｒＴｒｘｎＬｏｇＦｉｌｅＮａｍｅを構築しプログラム１を呼び出す。入力パラメータ・ＬａｐｔｏｐＮｏｄｅＩｄ−宛先ラップトップのｎｏｄｅｉｄ・ＵｓｅｒＴｘｎＬｏｇＦｉｌｅＮａｍｅ−ｔｘｎを書き込むファイルのフルパス・ＭａｘＢａｔｃｈＴｘｎｓ−Ｓ＿ＤＯＣＫ＿ＳＴＡＴＵＳテーブルへのコミットとアップデートの間のｔｘｎの数・ＭａｘＴｘｎｓ−このセッションで処理するｔｘｎの数。このパラメータを使って処理を制限する。メイン・アルゴリズム可視度ルーティングのチェックプライマリＩＤを獲得するためのＳＱＬステートメントの生成可視度イベントの処理付属物Ｂ：ＳＱＬステートメントと例トップレベルＳＱＬステートメントこのセクションでは、ログ・マネージャが実行時間中に生成するフォーマットＳＱＬステートメントを説明する。顧客ドック・オブジェクトを使ったこれらＳＱＬステートメントの例については次のセクションを参照。ログ・マネージャ可視度ＳＱＬステートメントログ・マネージャは、ドック・オブジェクト・インスタンスの可視度をチェックする時、可視度ＳＱＬステートメントを生成する。ログ・マネージャは、各可視度ルールについて＜サブＳＱＬステートメント＞を生成するが、その構造は可視度ルールタイプで決まる（以下のサブＳＱＬステートメント参照）。ログ・マネージャ関連ドック・オブジェクトＳＱＬステートメントログ・マネージャは、ドック・オブジェクト・インスタンスの可視度が変更された後、関連ドック・オブジェクトＳＱＬステートメントを生成する。ログ・マネージャは各可視度ルールについて１つ以上の＜サブＳＱＬステートメント＞を生成するが、その構造は可視度ルールタイプで決まる（以下のサブＳＱＬステートメント参照）。ＳＱＬルールのサブステートメントログ・マネージャ可視度ＳＱＬステートメントログ・マネージャ関連ドック・オブジェクトＳＱＬステートメントユーザは関連ドック・オブジェクトＳＱＬステートメントを入力。ＤＢＸｔｒａｃｔフェーズ２ＳＱＬステートメントドック・オブジェクト・ルールをチェックするためのサブステートメントログ・マネージャ可視度ＳＱＬステートメント３．ログ・マネージャ関連ドック・オブジェクトＳＱＬステートメント地位ルールのためのサブステートメントログ・マネージャ可視度ＳＱＬステートメントログ・マネージャ関連ドック・オブジェクトＳＱＬステートメント地位マネージャ・ルールのためのサブステートメントログ・マネージャ可視度ＳＱＬステートメントログ・マネージャ関連ドック・オブジェクトＳＱＬステートメント従業員ルールのためのサブステートメントログ・マネージャ可視度ＳＱＬステートメントログ・マネージャ関連ドック・オブジェクトＳＱＬステートメント従業員マネージャ・ルールのためのサブステートメントログ・マネージャ可視度ＳＱＬステートメントログ・マネージャ関連ドック・オブジェクトＳＱＬステートメントログ・マネージャ関連バック・オブジェクトＳＱＬステートメント

【手続補正書】【提出日】平成１２年１月３１日（２０００．１．３１）【補正内容】請求の範囲 1. ａ）サーバ（１）上に存在する中央データベース（３）と、ｂ）別個の部分的複製データベース（２３ａ，２３ｂ，２３ｃ）を含み、個別のクライアント（２１ａ，２１ｂ，２１ｃ）上に存在する前記別個の部分的複製データベース（２３ａ，２３ｂ，２３ｃ）は別個のユーサ（３３ａ，３３ｂ，３３ｃ）を有するデータベースの管理方法において、ｉ）中央位置に記憶されている１セットの可視度ルールから、サーバ（１）から伝播し、個別のクライアント（２１ａ，２１ｂ，２１ｃ）におけるデータに対する部分的複製データベース（２３ａ，２３ｂ，２３ｃ）のユーザ（３３ａ，３３ｂ，３３ｃ）の可視度を決定し、 ii）クライアント（２１ａ，２１ｂ，２１ｃ）上の部分的複製データベース（２３ａ，２３ｂ，２３ｃ）のユーザ（３３ａ，３３ｂ，３３ｃ）がデータに対する可視度を持つ場合のみ、サーバ（１）からの前記データをクライアント（２１ａ，２１ｂ，２１ｃ）上の部分的複製データベース（２３ａ，２３ｂ，２３ｃ）に伝播するデータベースの管理方法。 2. 前記１セットの可視度ルールを１つの場所に保存する請求項１に記載のデータベースの管理方法。 3. アップデートするデータに対する部分的複製データベース（２３ａ，２３ｂ，２３ｃ）のノード（３３ａ，３３ｂ，３３ｃ）の可視度をキャッシュ・メモリに記憶する請求項１又は２に記載のデータベースの管理方法。 4. 少なくとも１セットの可視度ルールを１つの場所に保存する請求項１〜３のいずれか一項に記載のデータベースの管理方法。 5. サーバ（１）上に存在するデータベース及び個別のクライアント（２１ａ，２１ｂ，２１ｃ）上に存在する１つ又はそれ以上の複製されたデータデータベースを管理するための方法を実行するために、装置が実行可能な指示を明白に具現するプログラムを保存するための、装置によって読み取り可能な少なくとも１つのプログラム保存装置であって、前記方法は、ａ）１つの場所に保存されているそのセットの可視度ルールから、サーバにおいて伝播している個別のクライアント（２１ａ，２１ｂ，２１ｃ）におけるデータに対する部分的複製データベース（２３ａ，２３ｂ，２３ｃ）のユーザ（３３ａ，３３ｂ，３３ｃ）の可視度を決定し、ｂ）個別のクライアント（２１ａ，２１ｂ，２１ｃ）における部分的複製データベース（２３ａ，２３ｂ，２３ｃ）のユーザ（３３ａ，３３ｂ，３３ｃ）がデータに対する可視度を持つ場合のみ、前記データを部分的複製データベース（２３ａ，２３ｂ，２３ｃ）に伝播するステップとを有する、プログラム保存装置。 6. ａ）サーバ（１）上に存在する中央データベース（３）と、ｂ）別個の部分的複製データベース（２３ａ，２３ｂ，２３ｃ）を含み、個別のクライアント（２１ａ，２１ｂ，２１ｃ）上に存在する前記別個の部分的複製データベース（２３ａ，２３ｂ，２３ｃ）は別個のユーザ（３３ａ，３３ｂ，３３ｃ）を有するデータベースの管理方法システムにおいて、ｉ）中央位置に記憶されている１セットの可視度ルールから、サーバ（１）から伝播し、個別のクライアント（２１ａ，２１ｂ，２１ｃ）におけるデータに対する部分的複製データベース（２３ａ，２３ｂ，２３ｃ）のユーザ（３３ａ，３３ｂ，３３ｃ）の可視度を決定し、 ii）クライアント（２１ａ，２１ｂ，２１ｃ）上の部分的複製データベース（２３ａ，２３ｂ，２３ｃ）のユーザ（３３ａ，３３ｂ，３３ｃ）がデータに対する可視度を持つ場合のみ、サーバ（１）からの前記データをクライアント（２１ａ，２１ｂ，２１ｃ）上の部分的複製データベース（２３ａ，２３ｂ，２３ｃ）に伝播するように構成されているシステム。 7. 前記１セットの可視度ルールを１つの場所に保存する請求項６に記載のシステム。 8. さらに、アップデートするデータに対する部分的複製データベース（２３ａ，２３ｂ，２３ｃ）のノード（３３ａ，３３ｂ，３３ｃ）の可視度をキャッシュ・メモリに記憶するように構成されている請求項６又は８に記載のシステム。 9. さらに、少なくとも１セットの可視度ルールを１つの場所に保存するように構成されている請求項６〜８のいずれか一項に記載のシステム。 10．さらに、中央辞書に可視度ルールが保存され、ノード（３３ａ，３３ｂ，３３ｃ）の可視度ルールの変更を許容するように構成されている請求項６〜９のいずれか一項に記載のシステム。【手続補正書】【提出日】平成１２年１１月１日（２０００．１１．１）【補正内容】【図１】【図２】【図３】【図４】【図５】【図６】【図７】【図８】【図９】【図１０】

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＧＨ，ＧＭ，ＧＷ，ＨＵ，ＩＤ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (72)発明者リム，ピーターエス. アメリカ合衆国，カリフォルニア 94065, レッドウッドシティ，ガバナーズベイドライブ 917

Claims

【特許請求の範囲】１．中央データベース（３）と別個の部分的複製データベース（２３ａ，２３ｂ，２３ｃ）を含み、前記別個の部分的複製データベース（２３ａ，２３ｂ，２３ｃ）は別個のユーザ（３３ａ，３３ｂ，３３ｃ）を有するデータベースの管理方法において、１セットの可視度ルールから伝播しているデータに対する部分的複製データベース（２３ａ，２３ｂ，２３ｃ）のユーザ（３３ａ，３３ｂ，３３ｃ）の可視度を決定し、部分的複製データベース（２３ａ，２３ｂ，２３ｃ）のユーザ（３３ａ，３３ｂ，３３ｃ）がデータに対する可視度を持つ場合のみ、前記データを部分的複製データベース（２３ａ，２３ｂ，２３ｃ）に伝播するデータベースの管理方法。２．前記１セットの可視度ルールを１つの場所に保存する請求項１に記載のデータベースの管理方法。３．アップデートしていないが、アップデートしている部分的複製データベース（２３ａ，２３ｂ，２３ｃ）に関連する部分的複製データベース（２３ａ，２３ｂ，２３ｃ）のユーザ（３３ａ，３３ｂ，３３ｃ）の可視度を決定する請求項１に記載のデータベースの管理方法。４．アップデートしている部分的複製データベース（２３ａ，２３ｂ，２３ｃ）のユーザ（３３ａ，３３ｂ，３３ｃ）の可視度を繰り返し決定する請求項２に記載のデータベースの管理方法。５．部分的複製データベース（２３ａ，２３ｂ，２３ｃ）のノード（３３ａ，３３ｂ，３３ｃ）の可視度が宣言形式である請求項１に記載のデータベースの管理方法。６．アップデートするデータに対する部分的複製データベース（２３ａ，２３ｂ，２３ｃ）のノード（３３ａ，３３ｂ，３３ｃ）の可視度をキャッシュ・メモリに記憶する請求項１に記載のデータベースの管理方法。７．部分的複製データベース（２３ａ，２３ｂ，２３ｃ）の前記ノード（３３ａ，３３ｂ，３３ｃ）が、伝播するデータに対する可視度強度を持つ請求項１に記載のデータベースの管理方法。８．少なくとも１セットの可視度ルールを１つの場所に保存する請求項１に記載のデータベースの管理方法。９．アップデートするドッキング・オブジェクトの可視度を決定するために、アップデートしない関連ドッキング・オブジェクトのデータ・コンテンツに対して可視度ルールを保存する請求項１に記載のデータベースの管理方法。１０．ノード（３３ａ，３３ｂ，３３ｃ）が可視度ルールを変更できるよう可視度ルールを中央ディクショナリに保存する請求項１に記載のデータベースの管理方法。１１．可視度ルールの変更にグラフィカル・ユーザ・インターフェイスを用いる請求項１に記載のデータベースの管理方法。１２．可視度ルールの変更にグラフィカル・ユーザ・インターフェイスを用いる請求項１に記載のデータベースの管理方法。１３．データベース中のデータに対するデータベースのユーザの可視度を決定し、且つそれに応じてデータに対する可視度を伝播することによって、部分的複製データベース（２３ａ，２３ｂ，２３ｃ）を管理するためにそこに具現化されたコンピュータが使用可能なプログラム・コードを持つコンピュータが使用可能な媒体からなる製造物であって、製造物のコンピュータが読取り可能なプログラムは、１つの場所に保存された１セットの可視度ルールから部分的複製データベース（２３ａ，２３ｂ，２３ｃ）のユーザの可視度をコンピュータに決定させるコンピュータが読取り可能なプログラム・コード手段と、部分的複製データベース（２３ａ，２３ｂ，２３ｃ）のユーザがデータに対する可視度を持つ場合に、コンピュータにデータを部分的複製データベース（２３ａ，２３ｂ，２３ｃ）に伝播させるためのコンピュータが読取り可能なプログラム・コード手段とを有する製造物。１４．データベースを管理するための方法を実行するために、装置が実行可能な指示を明白に具現するプログラムを保存するための、装置によって読み取り可能なプログラム保存装置であって、前記方法は、１つの場所に保存されているそのセットの可視度ルールから伝播しているデータに対する部分的複製データベース（２３ａ，２３ｂ，２３ｃ）のユーザ（３３ａ，３３ｂ，３３ｃ）の可視度を決定することと、部分的複製データベース（２３ａ，２３ｂ，２３ｃ）のユーザ（３３ａ，３３ｂ，３３ｃ）がデータに対する可視度を持つ場合のみ、前記データを部分的複製データベース（２３ａ，２３ｂ，２３ｃ）に伝播することを有するプログラム保存装置。