JP2001514775A - 複数のデータベース・トランザクションのリモート・データベース・クライアントの可視度決定方法 - Google Patents

Abstract

(57)【要約】 データベースの管理方法。このデータベースは、中央データベースと別個の部分的複製データベースを含む。各複製データベースは別個のノードを持つ。データベース管理方法は、伝播しているデータに対する部分的複製データベースのノードの可視度を決定し、部分的複製データベースのノードがデータに対する可視度を持つ場合のみ部分的複製データベースにデータを伝播する。

Description

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

【手続補正書】 【提出日】平成１１年１２月２７日（１９９９．１２．２７） 【補正内容】 請求の範囲 １．(i)中央データベース（３）と、 (ii)別個の部分的複製データベース（２３ａ，２３ｂ，２３ｃ）とを含み、前 記別個の部分的複製データベース（２３ａ，２３ｂ，２３ｃ）は別個のノード（ ３３ａ，３３ｂ，３３ｃ）を有するデータベースの管理方法において、 （a）伝播しているデータに対する部分的複製データベース（２３ａ，２３ｂ ，２３ｃ）のノード（３３ａ，３３ｂ，３３ｃ）の可視度を決定し、 （b）部分的複製データベース（２３ａ，２３ｂ，２３ｃ）のノード（３３ａ ，３３ｂ，３３ｃ）がデータに対する可視度を持つ場合のみ、前記データを部分 的複製データベース（２３ａ，２３ｂ，２３ｃ）に伝播する、 ステップを有するデータベースの管理方法。 ２．アップデートしていないが、アップデートしている部分的複製データベー ス（２３ａ，２３ｂ，２３ｃ）に関連する部分的複製データベース（２３ａ，２ ３ｂ，２３ｃ）のノード（３３ａ，３３ｂ，３３ｃ）の可視度を決定する請求項 １に記載のデータベース管理方法。 ３．伝播しているデータに対する部分的複製データベース（２３ａ，２３ｂ， ２３ｃ）のノード（３３ａ，３３ｂ，３３ｃ）の可視度をキャッシュ・メモリー に保存する請求項１又は２に記載のデータベース管理方法。 ４．ノード（３３ａ，３３ｂ，３３ｃ）が可視度ルールを変更できるよう可視 度ルールを中央ディクショナリに保存する請求項１〜３のいずれか一項に記載の データベース管理方法。 ５．伝播しているデータに対する部分的複製データベース（２３ａ，２３ｂ， ２３ｃ）のノード（３３ａ，３３ｂ，３３ｃ）の可視度を決定し、且つ部分的複 製データベース（２３ａ，２３ｂ，２３ｃ）のノード（３３ａ，３３ｂ，３３ｃ ）がデータに対する可視度を持つ場合のみ、前記データを部分的複製データベー ス（２３ａ，２３ｂ，２３ｃ）に伝播することによって、部分的複製データベー ス（２３ａ，２３ｂ，２３ｃ）を管理するためにそこに具体化されたコンピュー タが使用可能なプログラム・コードを持つコンピュータが使用可能な媒体からな る製造物。 ６．(i)中央データベース（３）と、 (ii)別個の部分的複製データベース（２３ａ，２３ｂ，２３ｃ）と有し、それ ぞれが別個のノード（３３ａ，３３ｂ，３３ｃ）を有するデータベースの管理シ ステムにおいて、 （a）伝播しているデータに対する部分的複製データベース（２３ａ，２３ｂ ，２３ｃ）のノード（３３ａ，３３ｂ，３３ｃ）の可視度を決定し、 （b）部分的複製データベース（２３ａ，２３ｂ，２３ｃ）のノード（３３ａ ，３３ｂ，３３ｃ）がデータに対する可視度を持つ場合のみ、前記データを部分 的複製データベース（２３ａ，２３ｂ，２３ｃ）に伝播する 構成を有するデータベースの管理システム。 ７．アップデートしていないが、アップデートしている部分的複製データベー ス（２３ａ，２３ｂ，２３ｃ）に関連する部分的複製データベース（２３ａ，２ ３ｂ，２３ｃ）のノード（３３ａ，３３ｂ，３３ｃ）の可視度を決定するように 構成される請求項６に記載のシステム。 ８．伝播しているデータに対する部分的複製データベース（２３ａ，２３ｂ， ２３ｃ）のノード（３３ａ，３３ｂ，３３ｃ）の可視度をキャッシュ・メモリー に保存するように構成されている請求項６又は７に記載のシステム。 ９．ノード（３３ａ，３３ｂ，３３ｃ）が可視度ルールを変更できるよう可視 度ルールを中央ディクショナリに保存するように構成されている請求項６〜８の いずれか一項に記載のシステム。

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

Claims (1)

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