(57)【要約】【課題】  アプリケーション定義のシステムにおいて、整合性ユニットを複製するためのアーキテクチャを提供すること。【解決手段】  ソースレプリカでの変更は、変更ユニットおよび関連付けられた整合性ユニット両方でのメタデータの変更に影響する。デスティネーションによる同期化要求に応答して、ソースは更新された整合性ユニットを列挙し、整合性ユニットのすべての更新された変更ユニットを列挙し、変更ユニットをバンドルし、デスティネーションへの伝送のためにバンドルした変更ユニットを送る。デスティネーションは、競合の検出および解決の後、バンドルした変更ユニットを単一のトランザクションで適用する。このプロセスは、変更ごとに続けられる。【選択図】  図１
2004295870.tif 000002
【特許請求の範囲】
【請求項１】
データのレプリケーションを容易にするシステムであって、
１つまたは複数の同種のデータの集まりにわたる整合性ユニットの複製されたバージョンに関するメタデータを追跡する変更追跡コンポーネントと、
前記メタデータをそれぞれ比較し、前記メタデータを使用して競合を解決し、前記整合性ユニットの前記複製されたバージョンを収束する調停コンポーネントと
を備えたことを特徴とするシステム。
【請求項２】
前記整合性ユニットの前記複製されたバージョンは、単一のトランザクションにて収束されることを特徴とする請求項１に記載のシステム。
【請求項３】
前記メタデータは、論理レコード関係とリンクされることを特徴とする請求項１に記載のシステム。
【請求項４】
前記競合は、論理レコードレベル、行レベル、および列レベルの少なくとも１つに関連して検出されることを特徴とする請求項１に記載のシステム。
【請求項５】
前記競合は、前記整合性ユニットの論理レコードレベルでの論理レコードリネージメタデータと、前記複製されたバージョンの論理レコードレベルでの論理レコードリネージメタデータとの比較によって、前記論理レコードレベルで解決され、その後、勝者側の論理レコードリネージメタデータは、所定の競合ポリシーに従って選択されることを特徴とする請求項４に記載のシステム。
【請求項６】
前記競合は、競合を検出するために、前記整合性ユニットのそれぞれの論理レコードリネージと、前記論理レコードレベルでの前記複製されたバージョンとを比較することによって、前記行レベルで解決され、その後、勝者を選択するために前記競合する行のそれぞれの行リネージが比較され、前記勝者は、所定の競合ポリシーに従って選択されることを特徴とする請求項４に記載のシステム。
【請求項７】
前記競合は、競合を検出するために、前記整合性ユニットのそれぞれの論理レコードリネージと、前記論理レコードレベルでの前記複製されたバージョンとを比較することによって、前記列レベルで解決され、その後、競合を検出するために前記競合する行のそれぞれの行リネージが比較され、前記行レベルでの前記競合の検出に応答して、前記競合の存在を確認するために前記列データのバージョンが比較され、前記競合は、所定の競合ポリシーに従って勝者側の列を選択することによって解決されることを特徴とする請求項４に記載のシステム。
【請求項８】
前記行レベルでのレコードは、行リネージデータを含み、前記列レベルでのレコードは、列バージョンデータを含み、前記行レベルでの競合検出は、前記行リネージデータを使用し、前記列レベルでの競合検出は、前記列バージョンデータを使用することを特徴とする請求項４に記載のシステム。
【請求項９】
前記調停コンポーネントは、論理レコードレベルでそれに関連付けられた論理レコードメタデータを使用して競合を解決し、該論理レコードメタデータは、前記整合性ユニットの変更履歴を追跡する論理レコードリネージデータを含むことを特徴とする請求項１に記載のシステム。
【請求項１０】
前記調停コンポーネントは、行メタデータを使用して行レベルで競合を解決し、該行メタデータは、前記行メタデータの変更履歴を追跡する行リネージデータを含み、前記履歴は、前記行を更新した前記レプリカと、前記行を更新した前記レプリカの前記バージョンの少なくとも１つの情報を含むことを特徴とする請求項１に記載のシステム。
【請求項１１】
前記調停コンポーネントは、列バージョンメタデータを使用して列レベルで競合を解決し、該列バージョンメタデータは、前記列バージョンを更新した前記レプリカの識別データと、前記列バージョンの少なくとも１つの情報を追跡することを特徴とする請求項１に記載のシステム。
【請求項１２】
前記整合性ユニットの前記メタデータの意味構造上の関係は、前記整合性ユニットを前記複製されたバージョンと収束することが失敗したときに保持されることを特徴とする請求項１に記載のシステム。
【請求項１３】
前記調停コンポーネントは、前記競合がより高いレベルで検出されたときに、より低いレベルでデータを収束することを特徴とする請求項１に記載のシステム。
【請求項１４】
前記競合は、所定の競合ポリシーに従って、勝者側の論理レコードおよび敗者側の論理レコードを選択し、前記敗者側の論理レコードの前記論理レコードリネージを、前記勝者側の論理レコードの前記論理レコードリネージで上書きすることによって、前記調停コンポーネントにより解決されることを特徴とする請求項１に記載のシステム。
【請求項１５】
前記複製されたバージョンのメタデータにおける変更は、前記整合性ユニットが収束可能であるように前記変更追跡コンポーネントによって追跡されることを特徴とする請求項１に記載のシステム。
【請求項１６】
前記調停コンポーネントは、変更列挙を使用して前記整合性ユニットの複数の行に対する変更を容易にするものであり、当該変更は、更新、挿入、および削除の少なくとも１つを含むことを特徴とする請求項１に記載のシステム。
【請求項１７】
前記変更列挙は、ビュー定義を使用して、論理レコードリンク定義に従って確実に列挙することを特徴とする請求項１６に記載のシステム。
【請求項１８】
請求項１に記載のシステムを含むことを特徴とするコンピュータ。
【請求項１９】
請求項１に記載のシステムを含むことを特徴とする複数のクライアントおよびサーバのネットワーク。
【請求項２０】
データのレプリケーションを容易にするための方法であって、
１つまたは複数の同種のデータの集まりにわたる整合性ユニットの複製されたバージョンに関するメタデータを追跡することと、
前記メタデータをそれぞれ比較することと、
前記メタデータを使用して競合を解決することと、
前記整合性ユニットの前記複製されたバージョンを収束することと
を備えることを特徴とする方法。
【請求項２１】
前記整合性ユニットの前記複製されたバージョンは、単一のトランザクションにて収束されることを特徴とする請求項２０に記載の方法。
【請求項２２】
前記メタデータを論理レコードの関係とリンクするステップをさらに含むことを特徴とする請求項２０に記載の方法。
【請求項２３】
論理レコードレベル、行レベル、および列レベルの少なくとも１つに関連して前記競合を検出するステップをさらに備えることを特徴とする請求項２０に記載の方法。
【請求項２４】
前記整合性ユニットの論理レコードレベルでの論理レコードリネージメタデータと、前記複製されたバージョンの論理レコードレベルでの論理レコードリネージメタデータとを比較することと、
所定の競合ポリシーに従って勝者側の論理レコードリネージメタデータを選択することと
により前記論理レコードレベルで競合を解決することを特徴とする請求項２３に記載の方法。
【請求項２５】
さらに、競合を検出するために前記整合性ユニットのそれぞれの論理レコードリネージと、前記論理レコードレベルでの前記複製されたバージョンとを比較することと、
前記競合する行のそれぞれの行リネージを比較することと、
所定の競合ポリシーに従って勝者を選択することと
により前記行レベルで競合を解決することを特徴とする請求項２３に記載の方法。
【請求項２６】
さらに、競合を検出するために前記整合性ユニットのそれぞれの論理レコードリネージと、前記論理レコードレベルでの前記複製されたバージョンとを比較することと、
競合を検出するために前記競合する行のそれぞれの行リネージを比較することと、
前記競合の存在を確認するために前記列データのバージョンを比較することと、
所定の競合ポリシーに従って勝者側の列を選択することと
により前記列レベルでの競合を解決することを特徴とする請求項２３に記載の方法。
【請求項２７】
前記行レベルでのレコードは、行リネージデータを含み、前記列レベルでのレコードは、列バージョンデータを含むものであって、前記行レベルでの競合検出は、前記行リネージデータを使用し、前記列レベルでの競合検出は、前記列バージョンデータを使用することを特徴とする請求項２３に記載の方法。
【請求項２８】
論理レコードレベルでそれに関連付けられた論理レコードメタデータを使用して競合を解決し、該論理レコードメタデータは、前記整合性ユニットの変更履歴を追跡する論理レコードリネージデータを含むことを特徴とする請求項２０に記載の方法。
【請求項２９】
行レベルで行メタデータを使用して競合を解決し、該行メタデータは、前記行メタデータの変更履歴を追跡する行リネージデータを含み、前記履歴は、前記行を更新した前記レプリカと、前記行を更新した前記レプリカの前記バージョンの少なくとも１つの情報を含むことを特徴とする請求項２０に記載の方法。
【請求項３０】
列レベルで列バージョンメタデータを使用して競合を解決し、該列バージョンメタデータは、前記列バージョンを更新した前記レプリカの識別データと、前記列バージョンの少なくとも１つの情報を追跡することを特徴とする請求項２０に記載の方法。
【請求項３１】
前記整合性ユニットの前記メタデータの意味構造上の関係は、前記整合性ユニットを前記複製されたバージョンと収束することが失敗したときに保持されることを特徴とする請求項２０に記載の方法。
【請求項３２】
前記競合がより高いレベルで検出されたときに、より低いレベルでデータを収束することを特徴とする請求項２０に記載の方法。
【請求項３３】
さらに、所定の競合ポリシーに従って、勝者側の論理レコードおよび敗者側の論理レコードを選択することと、
前記敗者側の論理レコードの前記論理レコードリネージを、前記勝者側の論理レコードの前記論理レコードリネージで上書きすることと、
により競合を解決することを特徴とする請求項２０に記載の方法。
【請求項３４】
前記複製されたバージョンのメタデータにおける変更を、前記整合性ユニットが収束可能であるように変更追跡コンポーネントによって追跡するステップをさらに備えることを特徴とする請求項２０に記載の方法。
【請求項３５】
前記整合性ユニットの複数の行の変更を容易にするために、変更を列挙するステップをさらに備え、当該変更は、更新、挿入、および削除の少なくとも１つを含むことを特徴とする請求項２０に記載の方法。
【請求項３６】
論理レコードリンク定義に従って確実に列挙するために、ビュー定義を提供するステップをさらに備えることを特徴とする請求項３５に記載の方法。
【請求項３７】
データのレプリケーションを容易にする方法であって、
ソースデータの集まりと、データの同種の集まりであって、第１のデスティネーションデータの集まりとの間で意味構造上関係するデータの変更を追跡することと、
整合性ユニットを形成するために、論理レコードの関係に従って、前記意味構造上関係するデータの変更に関連付けられたメタデータをリンクすることと、
データ変更の前記整合性ユニットを、前記同種のデータの集まりであって、第２のデスティネーションデータの集まりで単一のトランザクションにて収束することと
を備えることを特徴とする方法。
【請求項３８】
前記整合性ユニットの変更を前記第２のデスティネーションデータの集まりと比較することによって、競合を検出することと、
所定の競合ポリシーに従って勝者を選択することによって、前記競合を解決することと
をさらに備えたことを特徴とする請求項３７に記載の方法。
【請求項３９】
前記競合は、論理レコードレベル、行レベル、および列レベルの少なくとも１つに関連して検出されることを特徴とする請求項３８に記載の方法。
【請求項４０】
前記競合は、前記ソースデータの集まりのそれぞれの論理レコードリネージと、第２のデスティネーションデータの集まりとをまず比較することによって、論理レコードレベル、行レベル、および列レベルのそれぞれにおいて検出および解決されることを特徴とする請求項３９に記載の方法。
【請求項４１】
前記行レベルでのレコードは、行リネージデータを含み、前記列レベルでのレコードは、列バージョンデータを含むものであって、前記行レベルでの競合検出は、前記行リネージデータを使用し、前記列レベルでの競合検出は、前記列バージョンデータを使用することを特徴とする請求項３９に記載の方法。
【請求項４２】
前記意味構造上関係する変更の意味構造は、前記整合性ユニットの収束が再試行されたときに保持されることを特徴とする請求項４０に記載の方法。
【請求項４３】
前記競合がより高いレベルで検出されるときに、より低いレベルでデータを収束することをさらに含むことを特徴とする請求項３８に記載の方法。
【請求項４４】
前記データ整合性ユニットと前記第２のデスティネーションデータの集まりとの間の競合を検出および解決するステップをさらに備え、前記競合は、所定の競合ポリシーに従って勝者側の論理レコードおよび敗者側の論理レコードを選択し、前記敗者側の前記論理レコードリネージを、前記勝者側の前記論理レコードリネージで上書きすることによって検出および解決することを特徴とする請求項３７に記載の方法。
【請求項４５】
前記第１のデスティネーションデータの集まりの変更を変更追跡コンポーネントによって追跡するステップをさらに備え、該変更追跡コンポーネントは、データ変更の前記整合性ユニットが前記第２のデスティネーションデータの集まりと収束可能であるようにレプリケーションメタデータを追跡することを特徴とする請求項３７に記載の方法。
【請求項４６】
前記データの集まりは、リレーショナルデータベースであることを特徴とする請求項３７に記載の方法。
【請求項４７】
データレプリケーションを容易にするためのシステムであって、
ソースデータの集まりと、データの同種の集まりであって、第１のデスティネーションデータの集まりとの間で意味構造上関係するデータの変更を識別するための手段と、
整合性ユニットを形成するために、論理レコード関係に従って、前記意味構造上関係するデータの変更に関連付けられたメタデータをリンクするための手段と、
データ変更の前記整合性ユニットを、前記同種のデータの集まりであって、第２のデスティネーションデータの集まりと単一のトランザクションにて収束するための手段と
を備えたことを特徴とするシステム。
【請求項４８】
データのレプリケーションを容易にするためのシステムであって、
データの１つまたは複数の同種の集まりにわたる整合性ユニットの複製されたバージョンに関するメタデータを識別するための手段と、
前記メタデータをそれぞれ比較するための手段と、
前記メタデータを使用して競合を解決するための手段と、
前記整合性ユニットの前記複製されたバージョンを収束するための手段と
を備えたことを特徴とするシステム。
【請求項４９】
データのレプリケーションを容易にする方法であって、
ソースデータの集まりと第１のデスティネーションデータの集まりとの間のデータ変更を識別することと、
第２のデスティネーションへ整合性ユニットとして伝搬される整合性ユニット変更追跡情報のテーブルを作成することと、
データ変更の前記整合性ユニットを第２のデスティネーションデータの集まりと単一のトランザクションにて収束することと
を備えることを特徴とする方法。
【請求項５０】
前記テーブルは、変更ユニットと整合性ユニットとの間の関係付けをそれぞれ定義する一意のタグおよび論理レコードリンクの少なくとも１つを含むことを特徴とする請求項４９に記載の方法。
【請求項５１】
前記第１のデスティネーションデータの集まりにおいて前記一意のタグを書き込むことに応答して、前記テーブルを更新するステップをさらに備えたことを特徴とする請求項５０に記載の方法。
【請求項５２】
前記ソースデータの集まりは、ディレクトリサービスアーキテクチャを表すことを特徴とする請求項４９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データレプリケーション（ｒｅｐｌｉｃａｔｉｏｎ）システムに関し、より具体的にはアプリケーションで定義された体制でのデータのレプリケーションに関する。
【背景技術】
【０００２】
インターネットの出現以来、いくつかの異なるシステムのデータセットを複製する必要性が、ますます重要になってきた。レプリケーションは、障害が発生した場合に、より高いデータの冗長性を提供する。さらにレプリケーションは、データの可用性の向上、ロードバランシングの改善、ユーザとデータの間の地理的近接性（ｐｒｏｘｉｍｉｔｙ）の向上を提供する。
【０００３】
状態ベースのレプリケーションシステムは、緊密に整合したデータのセットを定義する整合性ユニット（ｃｏｎｓｉｓｔｅｎｃｙ  ｕｎｉｔ）と呼ばれる用語を使用する。「緊密に整合した」とは、ある所与のレプリカが、整合性ユニットにすべてのデータを含むか、またはまったく含まないことを意味し、データの消費者をデータの一部のみが存在する可能性のある場合に補償を行う必要性から解放する。
【０００４】
状態ベースのレプリケーションシステムでの整合性ユニットの考え方は、新しいものではない。このようなシステムの大半は、整合性ユニットの何らかの概念を定義するものであるが、低いレベルに固定されたもの、すなわち、たとえばテーブル内の物理行にあるすべてのデータが一緒に伝送され、一緒に適用される。これらのシステムは、アプリケーションの作成者に、自身のデータをシステムの事前に定義された低いレベルの整合性ユニットに合うように仕立てるか（常に可能であるわけではない）、または、たとえば、緊密に整合されていない複製されたデータを扱うために、データの不整合性を検出し、取り扱うための追加のコードを作成することを強いる。
【０００５】
アプリケーション定義の整合性ユニットは、その名前が示唆するように、レプリケーションシステムに対する緊密な整合性の境界を規定する能力をアプリケーションに与えるものである。このようなアプリケーションは、それによって不整合な状態を扱う複雑さを緩和しつつ、そのデータを（レプリケーションシステムに最も適した仕方ではなく）アプリケーションに最も適した仕方でモデル化する自由を有する。
【０００６】
整合性ユニットとは対照的に、変更ユニット（ｃｈａｎｇｅ  ｕｎｉｔ）は、競合の検出および解決を適用するデータの細分性（ｇｒａｎｕｌａｒｉｔｙ）、したがって、「変更履歴」が維持される細分性である。ほとんどの状態ベースのレプリケーションシステムでは、変更ユニットは１つの細分性、あるいは、物理行または列などの少数の細分性オプションの１つに固定される。
【０００７】
変更ユニットおよび整合性ユニットが同じであるシステムを定義することは可能であるが、時にそれらが異なることが望ましいか、またはより具体的に言えば、整合性ユニットが複数の変更ユニットを含むことが望ましい。たとえば、顧客（Ｃｕｓｔｏｍｅｒ）、注文（Ｏｒｄｅｒ）、および注文明細（Ｏｒｄｅｒ  Ｄｅｔａｉｌｓ）データベースの、第１のレプリカＲ１および第２のレプリカＲ２を考えてみる。顧客データ、注文データ、および注文明細データが第１のレプリカＲ１上に作成される場合、データは、第２のレプリカＲ２上にユニットとして一緒に複製され、一緒に適用されることが好ましい。すなわち、整合性ユニットは、このシナリオでは顧客データ、その顧客によるすべての注文データ、およびすべての顧客注文の注文明細データからなる。ここで、後に、顧客の請求書の宛先が第１のレプリカＲ１上で更新され、この変更のレプリケーションが第２のレプリカＲ２に発生する前に、その顧客の新しい注文がＲ２上に入力されると想定する。望まれる結果は、レプリケーションが静止したときに、レプリカＲ１およびＲ２の両方が新しい請求書の宛先および新しい注文を有することである。この結果には、これら２つの更新が競合しないことが必要であり、請求書の宛先は新しい注文の変更ユニットとは区別される変更ユニットであるべきことを示唆している。レプリケーションの帯域幅を制限することなどを含め、変更ユニットの細分性と整合性ユニットを区別する必要性を示す他の例が存在する。いくつかの最新の状態ベースのレプリケーションシステムにより、整合性ユニットが複数の変更ユニットを収容できるようになっていることにも留意されたい。
【０００８】
複数のサイトがデータを更新できるようにする既存のレプリケーションスキームでは、通常、物理テーブル行の正味の変更を複製し、競合の検出および解決は、物理テーブルの行または列の細分性で行われる。しかし、意味構造上関連付けられた行は複製する必要があり、これはそれが同じ業務オブジェクトの一部であるためである。正味の変更をデスティネーションレプリカに伝搬する従来のレプリケーション技術は、複数のテーブルの形態の複数の行に変更を伝搬することができ、これらは業務論理によって意味構造上関連付けられ、さらに、異なる時点で、異なるトランザクションの一部として適用することができる。しかし、これらのスキームは、「業務オブジェクト」レベルでグループ化される行にまたがって、整合性の保持を保証するものではない。
【０００９】
再度、顧客、注文、および注文明細の３つのデータベーステーブルからの行が入っているデータセットの同期化について考えてみる。ユーザアプリケーションが、新しい顧客を、新しい注文および新しい注文明細と共に挿入すると想定する。従来、レプリケーションは、これらの変更を異なるレプリカに適用する順序の保持を保証するものではないが、この挿入を顧客テーブルへ、続いて注文テーブルへ、そして最後に注文明細テーブルへと伝搬することができる。注文の変更と注文明細の変更との適用の間に、障害または顕著な遅延のいずれかがある場合、いくつかの注文が注文明細を有していないように見えるか、またはいくつかの注文については部分的な明細だけが見える可能性がある。（この状態は、通常、過渡的なものに過ぎず、次回の同期化がうまく完了すると解決されるであろう）。しかし、アプリケーションベースの整合性ユニットに従って以前に定義されたように、アプリケーションは、論理的に関連するすべてのレコードがある所与の時間にいずれかの場所にまったく存在しないか、またはすべて存在することを必要とする場合、一部のデータセットのみが存在することは問題となるであろう。他の例を挙げると、システム上で稼動している２つのアプリケーション（または同じアプリケーションの２つのインスタンス）があり、第１のものがレプリカＲ１上で更新を実行し、第２のものがレプリカ２から情報を読み取っている場合、その目指すものは、レプリカＲ２から読み取っているアプリケーションがそこにある業務オブジェクトの緊密な整合性に依拠でき、アプリケーションがデータベース内のその業務オブジェクトをモデル化する方法を規制することなく行えることである。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
高度にスケーラブルなシステムのための効率的なレプリケーションメカニズムのためのアプリケーション定義のシステムにおいて、関連するオブジェクト間の関係および順序付けの制約が維持され、他のレプリカに伝搬するための「業務オブジェクト」レベルでの整合性が保持されるように、意味構造上関連するオブジェクトを複製することが、ますます求められている。前述のように、状態ベースのレプリケーションシステムは、所与の整合性ユニットのすべての更新を一緒に伝送および適用しなければならない。これらのユニットの細分性が固定されているシステムでは、実施は比較的容易である。しかし、アプリケーション定義の整合性ユニットでは、さらなる論理が必要である。
【課題を解決するための手段】
【００１１】
本発明のいくつかの態様の基本的な理解を提供するために、本発明の簡単な要約を以下に示す。この要約は、本発明の広範囲な概要ではない。また、本発明のキーとなる／重要な要素を特定すること、または本発明の範囲を線引きすることを意図するものではない。その唯一の目的は、本発明のいくつかの概念を、後に示されるより詳細な説明の前置きとして、簡略化された形で示すことである。
【００１２】
本発明は、「業務オブジェクト」の整合性の保持を必要とするアプリケーションの展開をサポートする、データコレクションにおけるレプリケーションの機能に関する。本発明により、アプリケーションが、物理行の代わりに業務オブジェクトを綿密にモデル化する同期化の振る舞いを使用できるようになる。本件発明に従ったアプリケーションは、レプリケーション処理によって、全業務オブジェクトが伝搬できるように、レプリケーションの範囲を定義しつつ、業務オブジェクトをモデル化する。これは、他のレプリカが業務オブジェクトの部分イメージに対して可視性を有していないことを含意している。
【００１３】
本発明により、変更したデータの業務オブジェクトが全体として他のレプリカに伝搬されるのを容易にする。従来のシステムの細分性レベルである、行ごとまたは列ごとに変更を伝搬するのではなく、本発明では、最低レベルの細分性を、「業務オブジェクト」レベルでの意味構造上関連するデータのグループ化まで上げることによって、従来の細分性を補う。アプリケーション定義の整合性ユニットについて、リレーショナルデータベースの関連で説明する場合、この実施形態を以下では「論理レコード」と呼ぶ。一実施形態では、整合性ユニットを形成する行および列は、共通の「親行（ｐａｒｅｎｔ  ｒｏｗ）」にリンクされ、これは１つのテーブル内の一意の行であり、「親テーブル（ｐａｒｅｎｔ  ｔａｂｌｅ）」内では２つの行が同じ整合性ユニットの一部であることはない。親行はアプリケーションデータの一部であり、たとえば、注文明細が注文にリンクされており、注文が顧客にリンクされている場合、共通の「親行」として顧客を選択するということは、（リンクを全探索することによって規定される）ある所与の顧客のすべての注文のすべての注文明細が、顧客それ自体と組み合わされた状態で単一の整合性ユニットを構成することを意味する。（前の例で、注文明細レコードは１つのテーブルにあり、注文は２番目のテーブル、さらに顧客は３番目のテーブルにあることを想起されたい。）整合性ユニットのためのレプリケーションメタデータ（任意の共通の変更履歴など）は、「親行」にて維持される。レプリケーションシステムは、これらの行の間のリンクを分析してある所与の整合性ユニットの境界を決定し、整合性ユニットを１つに形成しているすべての行に対するいかなる更新をも送信し、デスティネーションレプリカ上にて単一のトランザクション内ですべての関連付けられた更新を適用することによって、緊密な整合性を維持する。このように、ある与えられた時間およびある与えられた場所で、論理的に関連するすべてのレコードがすべて存在するか、またはまったく存在しないかのいずれかであることを必要とするこうしたアプリケーションにおいて、整合性ユニットの関連する行の間で関係および順序付けの制約が保持される。
【００１４】
他の実施形態では、ほとんどまたはすべてのアプリケーションデータが単一のテーブル内に存在することがあり、この場合、アプリケーションが整合性ユニットに組み入れたいと思うデータが、他のテーブル内のアプリケーションデータと共通のリンクを持っていない。このケースは、ディレクトリサービスで一般的であり、ディレクトリサービスではアプリケーションの所望の整合性ユニットが、ディレクトリオブジェクトの任意のセットからなり、それぞれが共通のテーブルに完全に含まれる可能性がある。この場合、関連するオブジェクトの関連付けは、共通のキーの値、たとえば、「consistencyUnitKey」ディレクトリ属性の値を通じて行うことができる。レプリケーションメタデータは、オブジェクトの１つと共に格納するか、またはディレクトリレプリケーションシステムによってのみ使用される専用テーブルに格納することができる。
【００１５】
本発明は、行または列レベルに加えて、整合性ユニットレベルで競合の検出および解決のための調停（ｒｅｃｏｎｃｉｌｉａｔｉｏｎ）アルゴリズム、ならびに解決したデータのデスティネーションレプリカへの収束（ｃｏｎｖｅｒｇｅｎｃｅ）を使用する。
【００１６】
前述および関連する目的を達成するために、本発明のある種の例示的態様について、以下の説明および付属の図面と共に本明細書に記載する。しかし、これらの態様は、本発明の原理が使用可能な様々な方法のうちのいくつかを示すものであり、本発明は、このような態様およびそれらの等価物をすべて含むことを意図している。本発明の他の利点および新規の特徴は、以下の本発明の詳細な説明を図面と共に考察することによって、明らかになろう。
【発明を実施するための最良の形態】
【００１７】
（定義）
以下の用語は本説明を通して使用されるものであり、それらの定義を本発明の様々な態様を理解する際の一助としてここに提供する。
【００１８】
ソースレプリカ：  変更の起源となるデータソース
デスティネーションレプリカ：  変更の伝搬先となるデータソース
同期化プロセス：  ２つのレプリカからのデータセットを最終的な収束状態に同期化するプロセス
競合：  同じデータ要素が２つのレプリカにて変更されたとき、レプリケーションシステムがそのデータ要素を競合としてフラグを立てることになる。  
競合の検出：  変更が競合状態にあるかどうかを判断するためにソースおよびデスティネーションのレプリカにてメタデータを照会する同期化におけるプロセス
競合の解決：  競合が発生すると、その勝者および敗者を決定する同期化のプロセス
行リネージ（ｌｉｎｅａｇｅ）：  行の変更履歴を取り込むレプリケーションメタデータ。このメタデータは行の識別可能な更新を取り込み、そのバージョンを追跡する。  
列バージョン：  列のどのバージョンがどのレプリカによって作成されたかを取り込むレプリケーションメタデータ
ツームストーン（ｔｏｍｂｓｔｏｎｅ）メタデータ：  行の削除を取り込むレプリケーションメタデータ
論理レコード：  整合性ユニットとして伝搬する必要のある親および子の行の集まり
論理レコードリンク：  レプリケーションプロセス中に保持される同じ論理レコードの一部である２つのテーブル間の関係を定義するものであって、２つのテーブル間の結合を指定することに類似。「論理レコードリンク」は２つのテーブルに指定し、その結合条件を指定して２つのテーブル間の関係を表す。「論理レコードリンク」条件は、通常、TABLE1.COLUMN=TABLE2.COLUMNの形をとる。この条件により、TABLE1内と同じ列の値を有するTABLE2内のすべての行が、「論理レコード」として複製されることになる。たとえば、論理レコードリンクCustomers.CustomerID=Orders.CustomerIDは、ある所与の顧客行および関連する注文が、現在同じ論理レコードの一部であることを示す。
【００１９】
トップレベルの親行：  論理レコード内で親として動作する行
子行：  論理レコードのメンバ行
論理レコードの再編成：  論理レコード内の行のメンバ関係が変わる変更
親識別子：  論理レコードの識別子。これは通常、トップレベルの親行の行識別子である。  
同期化アンカ：  ２つのレプリカの同期がどのようにはずれているかを判定するエンティティ
【００２０】
次に本発明について図面を参照しながら説明する。全体を通して同じ要素を指すために同じ参照番号を使用する。以下の記述では、本発明の完全な理解のために、説明の目的で数多くの特定の詳細について述べる。しかし、本発明がこれら特定の詳細なしで実施することができることは明白であろう。他の事例では、本発明の記述を容易にするために、よく知られた構造およびデバイスをブロック図の形で示している。
【００２１】
本明細書で使用されるように、「構成要素／コンポーネント」および「システム」という用語は、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれかのコンピュータ関連エンティティを指すことを意図している。たとえば、構成要素／コンポーネントは、プロセッサ上で稼動中のプロセス、プロセッサ、オブジェクト、実行可能プログラム、実行スレッド、プログラム、および／またはコンピュータとすることができるが、それらに限定されるものではない。例として示すと、サーバ上で稼動中のアプリケーションおよびサーバのどちらも構成要素／コンポーネントとすることができる。１つまたは複数の構成要素／コンポーネントが、プロセスおよび／または実行スレッド内にあってよく、構成要素／コンポーネントは、１つのコンピュータ上に局在化、および／または、２つまたはそれ以上のコンピュータ間で分散化することができる。
【００２２】
本明細書で使用されるように、「推論（ｉｎｆｅｒｅｎｃｅ）」という用語は、一般に、イベントおよび／またはデータを介して取り込まれた観測セットから、システム、環境、および／またはユーザの状態を類推または推測するプロセスを指すものである。推論は、たとえば特定のコンテキストまたは動作を特定するために使用することができるか、または複数の状態にわたる確率分布を生成することができる。推論は確率論的、すなわち、データおよびイベントの考察に基づいた、対象の状態にわたる確率分布の計算とすることができる。推論は、イベントおよび／またはデータのセットから、より高いレベルのイベントを構成するために用いられる技法を指すこともできる。このような推論の結果、観測されたイベントおよび／または格納されたイベントデータのセット、イベントが緊密な時間的近接性で連関されているか否か、そしてイベントおよびデータが１つまたはいくつかのイベントおよびデータソースからのものであるかどうかから新しいイベントまたはアクションが構築される。
【００２３】
次に図１を参照すると、本発明によるレプリケーション流れ図が示されている。例示の目的で、ソースロケーション１００およびデスティネーションロケーション１０２のそれぞれに全体としてまたは一部として存在している少なくとも１つの同種のデータの集まりが提供されている。この特定の実施形態では、ソースロケーション１００は第１のデータの集まり（またはソースレプリカ）１０４を含み、これは定期的に更新される典型的なネットワークデータベースであってよく、この更新はリモートのデータの集まり（またはデスティネーションレプリカ）１０６と同期化される。ソースレプリカ１０４はデスティネーションレプリカ１０６の冗長コピーとすることができ、この場合ソースレプリカ１０４に対して変更が行われ、デスティネーションレプリカ１０６と同期化する必要がある。あるいは、ソースレプリカ１０４のサブセットについて変更が行われ、デスティネーションレプリカ１０６と同期化する必要がある。同種のデータの集まりは、ディレクトリサービスデータ構造、および異なるデータの集まりにまたがるデータの継続的な更新を必要とする任意の他の同種のデータの集まりを含むこともできる。
【００２４】
何らかの時点で、ソースレプリカ１０４がすべての変更をデスティネーションレプリカ１０６に伝送するように、ソース１００とデスティネーション１０２とを調停または「同期化する」ことが望まれる。ピアツーピア環境では、デスティネーション１０２で受け取ったそれらの変更は、その後、デスティネーション１０２から同期化を要求する他のリモートのデータの集まりへ、あるいはソース１００から直接、伝搬することができる。
【００２５】
さらに進んで、ソースレプリカ１０４がアプリケーションと関連して、ソース１００が１つまたは複数の更新を受け取る。ソース１００およびデスティネーション１０２にて、レプリカデータのそれぞれの断片にメタデータが関連付けられる。変更するたびに、変更ユニットおよびそれに関連付けられた整合性ユニットの両方に対して、メタデータが更新される。ソースレプリカ１０４の変更データのメタデータを利用して、変更データのメタデータの整合性ユニット１０５が生成される。前述のように、整合性ユニット１０５は単一の変更ユニットとすることができる。しかし、本発明の新規な態様によれば、整合性ユニット１０５は１つまたは複数の変更ユニットを収容し、整合性ユニット１０５はソースレプリカ１０４の意味構造上関連する変更データレコードのすべてを含む。
【００２６】
動作時には、デスティネーション１０２がソース１００との同期化を定期的に要求して、デスティネーションレプリカ１０６のソースレプリカ１０４との同期化を容易にする。ソース１００が同期化の要求を受け取ると、ソース１００は（最初に本明細書でソースレプリカ１０４の変更を収容するものとして表された）更新された整合性ユニット１０５を列挙する。次にソース１００は、整合性ユニット１０５の更新された変更ユニットをすべて列挙し、デスティネーション１０２への伝送のために所与の整合性ユニット１０５についての変更ユニットをバンドルする。デスティネーション１０２は、更新情報を受け取り、特定するデスティネーション変更識別コンポーネント１０８を含む。デスティネーション１０２はまた、変更識別コンポーネント１０８から列挙された変更を受け取り、競合を検出、解決し、そして変更データをデスティネーションレプリカ１０６に収束するデスティネーション調停コンポーネント１１０を含む。変更データは、整合性ユニット１０５としてデスティネーション１０２に渡され、単一のトランザクションでデスティネーションレプリカ１０６に伝搬される。
【００２７】
ソースまたはデスティネーションとしてレプリカ上にラベル付けすることは、どちらがデータを送受信しているかに関係するだけであることが理解されるべきである。このように、本発明の新規の態様の推進のために、デスティネーション１０２はデスティネーションアプリケーションから変更を受け取ることができ、同期が発生すると、変更がソース１００に渡されることになる。ソース１００には、レプリカの変更を処理し、伝搬するための、ソース変更識別コンポーネント１１２およびソース調停コンポーネント１１４が含まれることになる。
【００２８】
動作時には、ソース１００はデスティネーション１０２との同期化を定期的に要求し、ソースレプリカ１０４のデスティネーションレプリカ１０６との同期化を容易にする。デスティネーション１０２がソース１００から同期化要求を受け取ると、デスティネーション１０２は（整合性ユニット１０５でも表されるが、デスティネーションレプリカ１０６の変更を含み、反対方向に渡される）デスティネーション変更ユニットの更新された整合性ユニット１０５を列挙し、整合性ユニット１０５の更新された変更ユニットをすべて列挙し、ソース１００への伝送のために所与の整合性ユニットについての変更ユニットをバンドルする。ソース変更識別コンポーネント１０８は、更新された情報を受け取り、特定する。ソース調停コンポーネント１１４は、変更識別コンポーネント１１２から列挙された変更を受け取り、競合を検出、解決し、そして変更データをソースレプリカ１０４に収束させる。変更データはソース１００に渡され、単一のトランザクションでソースレプリカ１０４に伝搬される。バンドルされた変更は、同期化プロセスが完了するまで、受取り側のレプリカに繰り返し複製することができる。
【００２９】
次に図２を参照すると、アプリケーション定義の整合性ユニット１０５のための追加論理に関する論理レコード手法の流れ図が示されている。説明を簡略化するために、方法論を一連の動作として図示し、記載するが、本発明はこの動作の順序に限定されるものではなく、一部の動作は、本発明に従って、異なる順序で、そして／または本明細書に図示および記載されたもの以外の動作と共に同時に、行うことができることが理解されるべきである。たとえば、当分野の技術者であれば、方法論は、あるいは状態図などにおける一連の相互に関連する状態またはイベントとして表すことができることを理解し、認めるであろう。さらに、本発明による方法論を実施するためには、図示されたすべての動作が必要なわけではない。
【００３０】
この手法では、変更ユニットとそれが関係する整合性ユニットとの間の接続（または相互関係）を定義するために、論理レコードリンクを利用する。（従来のシステムでは、この接続はハードコードされ、たとえば、変更ユニットが列で整合性ユニットが行の場合、ある所与の変更ユニットの整合性ユニットは、その列が存するその行である。）この手法の各整合性ユニットは、「親行」と１対１の関係を有する。変更追跡情報は、各整合性ユニットと関連付けられ、親行に記録される。このように、整合性ユニット１０５は、同期化のために選択された第１のデスティネーションのデータの集まりにおける変更されたレコードの関連する親および子のメタデータテーブルのすべてを含む。
【００３１】
流れは２００で始まり、ソースレプリカ上の変更が発生する。それぞれの変更により、変更ユニットおよび関連付けられた整合性ユニットの両方に対して、メタデータが更新されることになる。ユーザデータベースにてデータ変更が発生すると、ユーザデータベース内の変更追跡メカニズムがレプリケーションメタデータを追跡することになり、それによって、その後のある時点で、これらの変更を他のレプリカと同期化することができるようになる。２０２で、デスティネーションが同期化を要求する。ソースはこれに応答して、２０４に示されるように、更新された各変更ユニットについて、更新された整合性ユニットを列挙する。２０６で、ソースは整合性ユニット内のすべての更新された変更ユニットを列挙し、これらをバンドルする。ソースは次に、２０８に示されるように、所与の整合性ユニットのバンドルされた変更ユニットをデスティネーションに送る。競合の検出および解決が実行されるが、これはレプリケーションメタデータが同期化に関係するソースおよびデスティネーションのレプリカと比較され、競合があれば検出および解決される同期化プロセスの段階である。２１０で、デスティネーションは、整合性ユニットのメタデータの更新を含め、単一のトランザクションでバンドルされた変更ユニットを適用する。この同期化プロセスの段階は、競合の検出および解決が実行された後、ソースレプリカからの変更がデスティネーションレプリカに伝搬されると発生する。２１２で、その他の更新を行うべきかどうかを判定するために、チェックが実行される。「はい」の場合、流れは２０４の入力に戻って、次の変更ユニットに対処する。「いいえ」の場合、流れは「停止」ブロックに進んで更新プロセスを終了する。次に図３を参照すると、論理レコード手法の整合性ユニット３００が示されている。オブジェクト３００は、厳密に１つのトップレベルの親３０２と、複数の子行３０４を含む。第１のレベル３０６は、親としてトップレベルの親３０２を有する、子１、．．．、子Ｎで示された子行を含む。子１１、．．．子１Ｍおよび子Ｎ１、．．．、子ＮＺで示された子行の第２のレベル３０８は、親として第１のレベル３０６の子行を有する。データの集まりに含まれる詳細の数に応じて、さらなるレベルの子行が存在することがあるが、図示されていない。
【００３２】
行のレベルのそれぞれは、論理レコードリンク３１０の使用を通じて関連付けられる。このように、論理レコードリンク３１０は、第１の子行３１２とトップレベルの親３０２との間の関係を確立する。追加の論理レコードリンク３１４を使用して第１のレベル３０６の残りの子行とトップレベルの親３０２との間の論理リンクを提供している。同様に、第２のレベル３０８の子行のそれぞれは、それぞれの論理レコードリンク３１６によって、その親（上位の第１のレベル３０６の子行）に関係している。子行の各テーブルは、その親を識別するメタデータ、行リネージ情報、および列バージョン情報を含む。
【００３３】
レプリケーション処理には、変更の追跡、変更の列挙、競合の検出と解決、および変更の適用という４つの主な段階があり、これらそれぞれについて、以下でより詳細に説明する。
【００３４】
（論理レコードについての変更の追跡）
ユーザデータベース（またはデータの集まり）においてデータの変更が発生すると、ユーザデータベース内の変更追跡メカニズムがレプリケーションメタデータの記録を取り、これによって、その後のある時点で、これらの変更を他のレプリカと同期化させることができるようになる。本発明の１つの前提は、論理レコードのあらゆるメンバがトップレベルの親３０２を１つだけ有することになるということである。任意の子行（３１０、３１４、３１６）と考えられる、各論理レコードは厳密に１つのトップレベルの親行および複数の子行からなるため、トップレベルの親行３０２を明白に決定することができる。レプリケーションに関与しているあらゆる行は、ＧＵＩＤ値の行識別子を有する。行が論理レコードのメンバである場合、新しい親識別子属性が通常のレプリケーションメタデータと共に、ここで維持される。すべての子行のための親識別子は、トップレベルの親行の行識別子である。論理レコードの一部であるメンバ行はレプリケーションメタデータを有し、これは行および列レベルでの競合検出を可能にする行リネージおよび列バージョンを含む。さらに、新しい属性「論理レコードリネージ」がトップレベルの親行で維持される。この属性には、全論理レコードの変更履歴が入っている。行リネージが、<replica_id,・row_version>のタプル（ｔｕｐｌｅ）を使用して行を更新したあらゆるレプリカについてエントリを維持するのと同様に、論理レコードリネージは、<replica_id,・logical_record_version>のタプルを使用して論理レコードを修正したあらゆるレプリカについて、エントリを維持する。
【００３５】
論理レコードのメンバ行が更新されると、子行の更新された行リネージは、以下のように決定される。
【００３６】
<new row lineage> = <current row lineage> + a new entry with <current replica_id, max version of logical_record_lineage+1>
【００３７】
同様に、全論理レコードのlogical_record_lineageは、以下のように決定される。
【００３８】
<new logical_record_lineage>=<current logical_record_lineage>+a new entry with<current replica_id, max version of logical_record_lineage+1>
【００３９】
以下の記述は、論理レコードのメンバ行が挿入、更新、または削除されたときに、変更追跡メカニズムがレプリケーションメタデータをどのように変更するかを示すものである。
【００４０】
論理レコードへの行の挿入に関して、変更追跡論理はまず、所与の行の親識別子を決定する。「論理レコード」のトップレベルの親のメタデータがまだメタデータテーブルに存在しない場合、トップレベルの親行のメタデータがレプリケーションメタデータテーブルに挿入されることを確実にするために、チェックを実行しなければならない。次に、「現在のレプリカ」および「論理レコードの現在の最高バージョン＋１」を表す新しいエントリを収容するように、論理レコードの「論理レコードリネージ」が更新される。上記の構文はこの概念を取り込んだものである。
【００４１】
論理レコードへの行の更新に関して、変更追跡論理はまず、所与の行の親識別子を決定する。行の更新によって「論理レコード」が再編成される場合は、これを記録する。これは、更新に関係する列が「論理レコードリンク」定義の一部であるかどうかを検査することによって決定される。特定の論理レコード内の行のメンバ関係が、この更新によって影響を受けない場合、行のリネージおよびトップレベルの親行の「論理レコードリネージ」は、最新の更新を反映するように更新される。論理レコードの再編成があった場合、メンバ行の親は変更されている。この再編成を他のレプリカに伝搬するために、メンバ行に対する更新を、古い論理レコードからの削除および新しい論理レコードへの挿入として記録する。メンバ行が論理レコードの一部である子行を有する場合、再編成は子行にも影響する。
【００４２】
行削除に関して、レプリカで子行または親行が削除されたとき、追跡論理はまず、所与の行の親識別子を決定する。削除は、本質的に、論理レコードを再編成させる。メタデータは、論理レコードへの他の変更と共にこの削除を処理するような方法で更新される。削除は、正しい親識別子を備えたツームストーンとして記録される。論理レコードのトップレベルの親の削除が発生した場合、全論理レコードを他のレプリカから除去する必要があるかのように取り扱う必要がある。
【００４３】
（論理レコードの再編成）
次に図４を参照すると、本発明のサンプルスキーマが示されている。論理レコードの再編成には、論理レコードの意味構造を保持する仕方で再編成がデスティネーションレプリカに伝搬されるように、変更追跡メカニズムがメタデータを更新する必要がある。図４の例では、CustomerID列で一意に識別されるCustomer行のCustomersテーブル４００が与えられている。Customersテーブル４００はまた、FirstName、LastName、およびAddressとラベルされた３つの列を含んでいる。Ordersテーブル４０２は、OrderID列で一意に識別される。Ordersテーブル４０２はまた、親のCustomersテーブル４００にマッピングするためのCustomerIDとしてラベルされた第１の列と、EmployeeIDとラベルされた第２の列と、OrderDateと題する最終列の３つの列を含んでいる。第３のテーブルであるOrderDetailsテーブル４０４は、OrderDetailID列で一意に識別される。OrderDetailsテーブル４０４はまた、親のOrdersテーブル４０２にマッピングするためにOrderIDとしてラベルされた第１の列と、ProductIDとラベルされた第２の列と、UnitPriceと題する第３の列と、Quantityと題する最終列の４つの列を含んでいる。
【００４４】
第１の論理レコードリンク４０６は、Customersテーブル４００とOrdersテーブル４０２との間に確立され、Customers.CustomerID=Orders.CustomerIDとして定義される。同様に、第２の論理レコードリンク４０８は、Ordersテーブル４０２とOrderDetailsテーブル４０４との間に確立され、Orders.OrderID=OrderDetails.OrderIDとして定義される。OrderDetailsテーブル４０２は、Ordersテーブル４０２を、その親であるCustomerテーブル４００にマッピングし戻すためのCustomerIDを含め、少なくとも２つのデータの列を有する。注文情報についての他の考えられる列は図示していない。同様に、OrderDetailsテーブル４０４は、Ordersテーブル４０２をその親であるCustomerテーブル４００にマッピングし戻すためのCustomerIDと、OrderDetailsテーブル４０４をその親であるOrdersテーブル４０２にマッピングし戻すためのOrderIDとを含め、少なくとも３つのデータの列を有する。注文明細情報についての他の考えられる列は図示していない。
【００４５】
次に図５を参照すると、図４の例のサンプルデータが示されている。データセットは、「Alfred」という名前の顧客について、顧客、注文、および注文明細を含んでいる。トップレベルのテーブル５００は、Customer1「Alfred」の行データを表し、名前「Alfred」を備えたCustomerID列を収容している。顧客「Alfred」はそれに関連付けられた３つの注文を有し、これらはOrder_1の行データを表す第１の注文テーブル（Order_1）５０２、Order_2の行データを表す第２の注文テーブル（Order_2）５０４、およびOrder_3の行データを表す第３の注文テーブル（Order_3）５０６である。第１の注文テーブル５０２は４つの子テーブル（５０８、５１０、５１２、および５１４）を有し、これらは注文Order_1に関連付けられた４つの注文明細テーブル（OrderDetail1、OrderDetail2、OrderDetail3、OrderDetail4）の行データをそれぞれ表している。
【００４６】
第２の注文テーブル５０４は１つの子注文明細テーブル（OrderDetail5）５１６を有し、これは注文Order_2に関連付けられた１つの注文明細の行データを表している。第３の注文テーブル５０６は１つの子注文明細テーブル（OrderDetail6）５１８を有し、これは注文Order_3に関連付けられた１つの注文明細の行データを表している。
【００４７】
図４および図５の両方のデータを使用して、第１の注文テーブル５０２のOrder_1行のCustomerID列が、CustomerIDが以前は「Alfred」であったが今は「David」であるように、更新されていると考えてみる。この更新は、本質的に、CustomerID=「Alfred」をルートとする「論理レコード」内のOrder_1行のメンバ関係を変更する。それゆえ、次に、Orders行、Order_1と、対応するテーブル５０８、５１０、５１２、および５１４の対応するOrder Details行（OrderDetail1、OrderDetail2、OrderDetail3、OrderDetail4）は、CustomerID=「David」をルートとする異なる「論理レコード」内に属する。変更追跡論理は、この変更を、古い親識別子「Ａｌｆｒｅｄ」を有するOrder_1、ならびに子行であるOrderDetail1、OrderDetail2、OrderDetail3、およびOrderDetail4に削除として伝搬し、新しい親識別子「David」を挿入する。
【００４８】
（論理レコードについての変更の列挙）
変更の列挙とは、ソースとデスティネーションのレプリカの間での以前の同期化以来、このレプリカで発生した変更が列挙される同期化プロセスの段階である。
【００４９】
論理レコードに対する変更の列挙の顕著な特徴は、グループで列挙されるべき更新、挿入、および削除を含む複数の変更が論理レコードの異なるメンバ行に対して行われることである。これを達成するために、変更列挙アルゴリズムは、データベースビューを使用して、異なるメンバテーブル内の行が論理レコードリンク定義に従って確実に列挙されるようにする。
【００５０】
図４のサンプルスキーマでは、Ordersテーブル４０２内の行のメンバ関係は、Customersテーブル４００内の行のメンバ関係に基づくものであり、これはこれら２つのテーブル間の「論理レコードリンク」定義４０６を使用して予測される。同様に、OrderDetailsテーブル４０４内の行のメンバ関係は、Ordersテーブル４０２内の行のメンバ関係に基づくものであり、これはこれら２つのテーブル間の「論理レコードリンク」定義４０８を使用して予測される。これを反映させるために、子テーブル参照ビューに対して生成されるデータベースビューは、直近の親に対して生成される。このサンプルスキーマでは、Ordersテーブル４０２のビューは、Customersテーブル４００のビューを参照している。同様に、OrderDetailsテーブル４０４のビューは、Ordersテーブル４０２のビューを参照している。
【００５１】
例示の目的で、サンプルスキーマについて以下のビュー定義を提供する。
【００５２】
Customerテーブルのビュー定義（view_logical_record_Customers）
Select [Customers].*, logical_record_parent_identifier=
[Customers].[rowguid] from Customers
【００５３】
Ordersテーブルのビュー定義（view_logical_record_Orders）
Select [Orders].*, logical_record_parent_rowguid=
[Customers].logical_record_parent_rowguid from [Orders],
[view_logical_record_Customers] [Customers] where (Orders.CustomerID=
Customers.CustomerID)
【００５４】
OrderDetailsテーブルのビュー定義（view_logical_record_OrderDetails）
Select [Order_Details].*, logical_record_parent_rowguid=
[Orders].logical_record_parent_rowguid from [Order_Details],
[view_logical_record_Orders][Orders] where (Order_Details.OrderID=
Orders.OrderID)
【００５５】
上記のビューを使用して、変更列挙アルゴリズムは、Customersテーブル４００、Ordersテーブル４０２、およびOrderDetailsテーブル４０４内の行を列挙する。論理レコード内のいずれかの行の削除は、この削除の親識別子が列挙されている論理レコードの親識別子と一致するレプリケーションメタデータテーブルから列挙される。デスティネーションレプリカではまだ見えないソースレプリカからの増分変更だけを処理するために、変更の列挙は、ソースとデスティネーションレプリカの間でネゴシエートされる同期化アンカに基づく。
【００５６】
（競合の検出および解決）
競合の検出および解決は、レプリケーションメタデータが同期化に係わるソースおよびデスティネーションのレプリカから比較され、競合があれば検出され、解決される同期化プロセスの段階である。論理レコードの使用というこの新規な態様によって、同期化プロセスは、行レベルまたは列レベルに加えて、論理レコードレベルにおいて競合を検出することができるようになる。さらに、競合解決の選択は、論理レコードレベルまたは行レベルにおいて可能である。どの競合検出ポリシーおよび競合解決ポリシーを使用するかの決定は、アプリケーション選択肢として残されている。というのは、アプリケーションはどのポリシーが適切であるかを決定するための最良の位置にあるためである。
【００５７】
（競合の検出および解決−論理レコードレベル）
競合の検出が論理レコードレベルである場合、ソースレプリカ上の論理レコードＬ１に属する行Ｒ１の列Ｃ１での変更は、デスティネーションレプリカ上の同じ論理レコードＬ１に属する行Ｒ２の列Ｃ２での変更と競合するであろう。競合を検出するために、ソースおよびデスティネーションレプリカからの論理レコードリネージが比較される。競合解決ポリシーが、論理レコードＬ１のソースレプリカのバージョンを勝者として選択した場合、勝者であるソースレプリカの論理レコードＬ１は、敗者であるデスティネーションレプリカの論理レコードＬ１を完全に上書きするであろう。
【００５８】
（競合の検出−行レベル／解決−論理レコードレベル）
競合の検出が行レベルである場合、行Ｒ１での変更は行Ｒ２での変更と、たとえどちらも同じ論理レコードＬ１に属しているとしても、競合しない。競合が行レベルで検出されるためには、競合は論理レコードレベルで検出されていたはずである。
【００５９】
次に、ソースおよびデスティネーションレプリカからの論理レコードリネージが比較され、競合が示される場合、これら２つのレプリカからの行リネージが比較される。競合解決ポリシーが、論理レコードＬ１のソースレプリカのバージョンを勝者として選択する場合、勝者であるソースレプリカからの論理レコードＬ１は、敗者であるデスティネーションレプリカでの論理レコードＬ１を完全に上書きするであろう。
【００６０】
（競合の検出−列レベル／解決−論理レコードレベル）
競合の検出が列レベルである場合、同じ列および同じ行内の変更のみが競合である。これが発生するためには、論理レコードレベルの競合および行レベルの競合が発生しているはずである。したがって、最初に論理レコードリネージが比較され、それらが競合を示す場合は、次に行リネージが比較される。行リネージの比較により競合が示される場合、次に列バージョンを比較して、競合があるかどうかを確認する。
【００６１】
この検出レベルで指定されたレベルでは競合が発生していないが、より高いレベルで（仮想的に）発生しているすべてのケースでは、より低いレベル（論理レコード内の行、または行内の列）での数量が「マージ（ｍｅｒｇｅ）」される。たとえば、行レベルの競合の検出を使用している場合、一方の行Ｒ１での変更は他方のＲ２での変更と、たとえ両方とも同じ論理レコードに属している場合であっても、競合しない。アプリケーションによって指定されたように、これは競合が行レベルではなく、論理レコードレベルで検出されたためである。その結果、両方の側で、（Ｒ１およびＲ２の）両方の変更を保持する「マージされた」論理レコードとなる。レプリケーションメタデータは、特別にマージされた論理レコードリネージを示すように更新される。これらの行リネージはマージされたリネージではない。というのは、２つの異なる行に対する一方向の変更であったためである。
【００６２】
同様に、列レベルの競合の検出を使用している場合、ソースレプリカ上の行Ｒ１の列Ｃ１での変更は、デスティネーションレプリカ上の同じ行Ｒ１の列Ｃ２での変更と競合しない。アプリケーションによって指定されたように、これは競合が列レベルではなく、行レベルで検出されたためである。その結果、ソースレプリカからの列Ｃ１の変更およびデスティネーションレプリカからの列Ｃ２の変更を反映する行Ｒ１のマージされた値を含むマージされた論理レコードとなる。行Ｒ１のレプリケーションメタデータは、Ｒ１のマージされた行リネージを含む。さらに、論理レコードはマージされた論理レコードリネージを有する。
【００６３】
競合がアプリケーションによって指定されたレベルで実際に検出される場合、勝者である論理レコードリネージは、敗者である論理レコードリネージを上書きし、勝者側の論理レコード内にある何らかの変更を伴うすべての行が敗者側にコピーされる。
【００６４】
以下の例では、親行Ｐ１と、２つの子行Ｃ１およびＣ２とを有する論理レコードを使用して、異なる競合の検出および解決オプションを示す。アスタリスクが付いた表記Ｃ１＊は、Ｃ１行がある所与のレプリカで更新されたことを示している。アスタリスクが付いていない表記Ｃ１は、Ｃ１行がその所与のレプリカで変更されていないことを示している。競合が検出されると、競合解決ポリシーは、ソースレプリカまたはデスティネーションレプリカを勝者として選定し、この例では、両方のオプションの結果として生じる値を前提としている。
【００６５】
【表１】
2004295870.tif 000003
【００６６】
例１では、論理レコード内の２つの別々の行（子行１および子行２）が更新されている。論理レコードレベルの検出が実行されているので、競合が検出される。さらに、論理レコードレベルの解決が選択されているため、ソースまたはデスティネーションのいずれかのレプリカからの勝者側の全論理レコードが最終的な収束された結果に現われることになる。
【００６７】
【表２】
2004295870.tif 000004
【００６８】
例２では、ソースおよびデスティネーションの両方のレプリカのそれぞれの論理レコード内で同じ行が更新されている。論理レコードレベルの検出が実行さていれるので、競合が検出される。しかし、論理レコードレベルの解決が選択されているため、ソースまたはデスティネーションのいずれかのレプリカからの勝者側の全論理レコードが最終的な収束された結果に現われることになる。
【００６９】
【表３】
2004295870.tif 000005
【００７０】
例３では、論理レコード内の２つの別々の行が更新されている。行レベルの検出が実行されているので、競合は検出されない。それゆえ、ソースレプリカからのＣ１＊の更新およびデスティネーションレプリカからのＣ２＊の更新が最終的な収束された結果に現われることになる。
【００７１】
【表４】
2004295870.tif 000006
【００７２】
例４では、ソースおよびデスティネーションの両方のレプリカのそれぞれの論理レコード内で同じ行が更新されている。行レベルの検出が実行されているので、競合が検出される。しかし、論理レコードレベルの解決が選択されているため、ソースまたはデスティネーションのいずれかのレプリカからの勝者側の全論理レコードが最終的な収束された結果に現われることになる。
【００７３】
【表５】
2004295870.tif 000007
【００７４】
例５では、論理レコード内の２つの別々の行が更新されている。行レベルの検出が実行されているので、競合は検出されない。それゆえ、ソースレプリカからのＣ１＊の更新およびデスティネーションレプリカからのＣ２＊の更新が最終的な収束された結果に現われることになる。
【００７５】
【表６】
2004295870.tif 000008
【００７６】
例６では、それぞれの論理レコード内の同じ行がソースおよびデスティネーションの両方のレプリカで更新されている。行レベルの検出が実行されているので、競合が検出される。ソースまたはデスティネーションのどちらが勝者であるかによって、ソースレプリカからのＣ１＊の更新およびデスティネーションレプリカからのＣ１＊＊の更新が最終的な収束された結果に現われることになる。デスティネーションレプリカからのＣ２＊の更新は一方向であったため、これが最終的な収束された結果に現われることになる。
【００７７】
（論理レコードについての変更の適用）
変更の適用は、競合の検出および解決が実行された後、１つのレプリカからの変更が他のレプリカに伝搬される同期化プロセスの段階である。変更の列挙はすでに物理行を論理レコードにバケット（ｂｕｃｋｅｔ）しているため、デスティネーションレプリカでのこれらの変更の適用は、これらの変更がデータベースのトランザクションにて適用されることを確実なものとしなければならない。トランザクションの適用のいかなる障害も、結果として、変更の適用が再試行されることになるが、再試行は論理レコードの意味構造を保持するべきである。
【００７８】
次に図６を参照すると、整合性ユニットの変更追跡情報を別のテーブル６００に分けるアプリケーション定義のレプリケーションの他の手法が示されている。以前と同様に、各変更ユニットは、厳密に１つの整合性ユニットに関連付けられている。この関連付けは、明示的（各変更ユニットが、メンバであるその整合性ユニットを一意に識別するキーによってタグ付けされてもよい）、または暗黙的（論理レコードリンクのように、関係がCustomers.CustomerID=Orders.CustomerIDによって識別されてもよい）とすることができる。アプリケーションデータが入っている任意のテーブルの任意の行を、これによって任意の整合性ユニットと関連付けることができる。
【００７９】
論理レコード手法を使用する場合のように、この手法でも、アプリケーションがそのアプリケーションオブジェクトのすべて（ディレクトリサーバ内の全オブジェクトのごく一部）を、デスティネーションレプリカへの伝搬のために、単一の整合性ユニット内に配置することが好ましい。これは、テーブル６００の使用によって達成される。このような結果を得るために、１つの実施例では、一意のタグ（またはＧＵＩＤ）が作成される。タグは、各アプリケーションオブジェクト上で特定のＬＤＡＰ属性（おそらく「consistencyUnitKey」）の値として作成される。第１のアプリケーションオブジェクト上での一意のタグを作成する動作によりディレクトリサーバがトリガされて、整合性ユニットの変更追跡テーブル６００の第１の列６０２に、第２の列６０４にて関連付けられたタグ値（たとえばTag1）と共に新しいエントリ、たとえばTracking・Data1が作成される。各アプリケーションオブジェクト（第１を含む）を更新する動作により、整合性ユニットの変更追跡情報が更新されて、新しいアプリケーションオブジェクトが整合性ユニットに入力されたことをシグナルし、アプリケーションオブジェクトに関する変更履歴情報が更新されて、整合性ユニットが整合性ユニットの一部として次に複製されるときに、アプリケーションオブジェクトが整合性ユニットと共に複製されるべきであることをシグナルする。
【００８０】
同様に、論理レコードリンク関係（ＬＲＬ）を、テーブル６００に挿入することができる。第２のアプリケーションオブジェクト上でＬＲＬを確立する動作によりディレクトリサーバがトリガされて、整合性ユニットの変更追跡テーブル６００の第１の列６０２に、第２の列６０４の関連付けられた論理レコードリンク値、たとえばＬＲＬ１と共に新しいエントリ、たとえばTracking・Data3が作成される。各アプリケーションオブジェクト（第１を含む）を更新する動作により、整合性ユニットの変更追跡情報が更新されて、新しいアプリケーションオブジェクトが整合性ユニットに入力されたことをシグナルし、アプリケーションオブジェクトに関する変更履歴情報が更新されて、整合性ユニットが整合性ユニットの一部として次に複製されるときに、アプリケーションオブジェクトが整合性ユニットと共に複製されるべきであることをシグナルする。
【００８１】
この手法の例は、ディレクトリサービス（たとえば、Ｘ．５００またはＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ  Ｄｉｒｅｃｔｏｒｙ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）ディレクトリ）において、アプリケーション定義の整合性ユニットを潜在的に使用することにある。多くのディレクトリサービスが、相対的にモノリシックなテーブルを使用してモデル化されるが、リレーショナルモデルでは、「ユーザ」および「プリンタ」のデータタイプがタイプ特有のテーブルに格納される傾向にあり、ディレクトリサービスは、結果的にすべてのデータタイプについて単一のテーブル６００となる傾向のある方法で、データタイプ間の共通の要素（たとえば、オフィスの場所またはマネージャ）を活用することを試みる。
【００８２】
ＬＤＡＰディレクトリサービスを使用して認証メッセージのルーティング情報を格納するセキュリティアプリケーションの例について考えてみる。この情報には、グローバル構成オブジェクトおよび各認証サーバのオブジェクトが含まれる。各認証サーバオブジェクトは、ルーティング階層においてその親に対するポインタを収容している。アプリケーションは、認証サーバオブジェクトとその親との関係をグラフにまとめるときに、グラフがスパニングツリー（ｓｐａｎｎｉｎｇ  ｔｒｅｅ）であること、たとえば、各ノード（認証サーバ）が、他のあらゆるノードと直接または間接的に接続され、グラフには循環がないことを必要とする。各認証サーバオブジェクトが独立して複製された場合、またさらに、ツリー階層内での変更がレプリカＲ１上で行われ、その変更の一部のみがレプリカＲ２に複製された場合、結果としてＲ２上のデータは、もはやスパニングツリーではなくなる場合がある。たとえば、初期には、レプリカＲ１およびＲ２上にオブジェクトＯ１、Ｏ２、およびＯ３が存在していると想定する。オブジェクトＯ２およびＯ３の両方の親がオブジェクトＯ１であり、オブジェクトＯ１の親は空である。レプリカＲ１上で、管理者が、オブジェクトＯ２がルートとなるように、たとえば、オブジェクトＯ１の親をオブジェクトＯ２に設定し、オブジェクトＯ２の親を除去し、オブジェクトＯ３の親をオブジェクトＯ２に変更するように、階層を（単一のトランザクションで）変更する。レプリカＲ２が、オブジェクトＯ２に変更を適用しないトランザクションにて、オブジェクトＯ１に更新を適用すると、レプリカＲ２を読み取るアプリケーションは、オブジェクトＯ２の親がＯ１であり、オブジェクトＯ１の親がＯ２であるという循環を経験するであろう。
【００８３】
次に図７を参照すると、開示されたアーキテクチャを実行するように動作可能なコンピュータのブロック図が示されている。本発明の様々な態様のための追加のコンテキストを提供するために、図７および以下の考察は、本発明の様々な態様を実施することができる好適なコンピューティング環境７００についての簡潔かつ一般的な説明とすることを意図するものである。これまで、本発明について、１つまたは複数のコンピュータ上で稼動することができるコンピュータ実行可能命令の一般的なコンテキストで説明してきたが、当分野の技術者であれば、本発明が、他のプログラムモジュールとの組合せ、および／またはハードウェアとソフトウェアの組合せとしても実施できることを認めるであろう。一般に、プログラムモジュールには、特定のタスクを実行するか、または特定の抽象データタイプを実装するルーチン、プログラム、コンポーネント、データ構造などが含まれる。さらに、当分野の技術者であれば、本発明の方法が、それぞれが動作上１つまたは複数の関連デバイスに結合することができる単一プロセッサまたはマルチプロセッサのコンピュータシステム、ミニコンピュータ、メインフレームコンピュータ、ならびにパーソナルコンピュータ、ハンドヘルドコンピューティングデバイス、マイクロプロセッサベースもしくはプログラム可能な民生用電子機器などを含む、他のコンピュータシステム構成でも実施可能であることを理解するであろう。例示された本発明の態様は、ある種のタスクが、通信ネットワークを通じてリンクされたリモート処理デバイスによって実行される分散コンピューティング環境でも実施可能である。分散コンピューティング環境では、プログラムモジュールは、ローカルおよびリモートの両方のメモリ記憶デバイスに配置することができる。
【００８４】
再度図７を参照すると、本発明の様々な態様を実施するための例示的環境７００はコンピュータ７０２を含み、コンピュータ７０２は処理ユニット７０４、システムメモリ７０６、およびシステムバス７０８を含んでいる。システムバス７０８はシステムメモリ７０６を含むが、これに限定されることのないシステム構成要素を処理ユニット７０４に結合する。処理ユニット７０４は、市販されている様々なプロセッサのいずれかであってよい。処理ユニット７０４として、デュアルマイクロプロセッサおよび他のマルチプロセッサアーキテクチャを使用することも可能である。
【００８５】
システムバス７０８は、商業ベースで利用可能な様々なバスアーキテクチャのいずれかを使用するメモリバスもしくはメモリコントローラ、周辺バスおよびローカルバスを含む、いくつかのタイプのバス構造のいずれかであってよい。システムメモリ７０６は、読取り専用メモリ（ＲＯＭ）７１０およびランダムアクセスメモリ（ＲＡＭ）７１２を含む。起動時などにコンピュータ７０２内の要素間での情報の転送を助ける基本ルーチンが入っている基本入出力システム（ＢＩＯＳ）は、ＲＯＭ７１０内に格納される。
【００８６】
コンピュータ７０２はさらに、ハードディスクドライブ７１４、磁気ディスクドライブ７１６（たとえば、取外し可能ディスク７１８と読取りまたは書込みのため）、および光ディスクドライブ７２０（たとえば、ＣＤ−ＲＯＭディスク７２２の読取り、または他の光媒体との読取りまたは書込みのため）を含む。ハードディスクドライブ７１４、磁気ディスクドライブ７１６、および光ディスクドライブ７２０は、ハードディスクドライブインターフェース７２４、磁気ディスクドライブインターフェース７２６、および光ドライブインターフェース７２８によって、それぞれシステムバス７０８に接続することができる。ドライブおよびそれらに関連付けられたコンピュータ読取り可能媒体は、データ、データ構造、コンピュータ実行可能命令などの不揮発性ストレージを提供する。コンピュータ７０２の場合、ドライブおよび媒体は、好適なデジタル形式で放送プログラミングのストレージを収容する。上記のコンピュータ読取り可能媒体の説明は、ハードディスク、取外し可能磁気ディスク、およびＣＤを参照しているが、当分野の技術者であれば、例示的なオペレーティング環境では、ジップドライブ、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、カートリッジなどのコンピュータによって読取り可能な他のタイプの媒体を使用することも可能であること、さらに、任意のこのような媒体が、本発明の方法を実行するためのコンピュータ実行可能命令を含むことができることを理解するはずである。
【００８７】
オペレーティングシステム７３０、１つまたは複数のアプリケーションプログラム７３２、他のプログラムモジュール７３４、およびプログラムデータ７３６を含む、いくつかのプログラムモジュールは、ドライブおよびＲＡＭ７１２に格納することができる。本発明は、市販されている様々なオペレーティングシステムまたはオペレーティングシステムの組合せと共に実施可能であることが理解されよう。
【００８８】
ユーザは、キーボード７３８、およびマウス７４０などのポインティングデバイスを通じてコマンドおよび情報をコンピュータ７０２に入力することができる。他の入力デバイス（図示せず）には、マイクロフォン、ＩＲリモートコントロール、ジョイスティック、ゲームパッド、衛星アンテナ、スキャナなどが含まれる。これらおよび他の入力デバイスは、システムバス７０８に結合されるシリアルポートインターフェース７４２を介して、処理ユニット７０４に接続されることが多いが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（「ＵＳＢ」）、ＩＲインターフェースなどの他のインターフェースによって接続することもできる。モニタ７４４または他のタイプのディスプレイデバイスも、ビデオアダプタ７４６などのインターフェースを介して、システムバス７０８に接続される。モニタ７４４に加えて、コンピュータは通常、スピーカ、プリンタなどの他の周辺出力デバイス（図示せず）を含む。
【００８９】
コンピュータ７０２は、リモートコンピュータ７４８などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境で動作可能である。リモートコンピュータ７４８は、ワークステーション、サーバコンピュータ、ルータ、パーソナルコンピュータ、ポータブルコンピュータ、マイクロプロセッサベースのエンターテイメント機器、ピアデバイス、または他の共通ネットワークノードであってよく、典型的には、コンピュータ７０２に関して記載した要素の多くまたはすべてを含むが、簡略化のために、メモリ記憶デバイス７５０のみが示されている。描画された論理接続は、ＬＡＮ７５２およびＷＡＮ７５４を含む。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびインターネットで一般的である。
【００９０】
ＬＡＮネットワーキング環境で使用される場合、コンピュータ７０２は、ネットワークインターフェースまたはアダプタ７５６を介して、ローカルネットワーク７５２に接続される。ＷＡＮネットワーキング環境で使用される場合、コンピュータ７０２は通常、モデム７５８を含むか、またはＬＡＮ上の通信サーバに接続されるか、またはインターネットなどのＷＡＮ７５４を介した通信を確立するための他の手段を有している。モデム７５８は内蔵または外付けであってよく、シリアルポートインターフェース７４２を介してシステムバス７０８に接続される。ネットワーク化された環境では、コンピュータ７０２に関して描画されたプログラムモジュール、またはその一部は、リモートメモリ記憶デバイス７５０に格納することができる。図示されたネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立する他の手段を使用可能であることが理解されよう。
【００９１】
次に図８を参照すると、本発明に従ったコンピューティング環境８００の例の概略的なブロック図が示されている。システム８００は、１つまたは複数のクライアント８０２を含む。クライアント８０２は、ハードウェアおよび／またはソフトウェア（たとえばスレッド、プロセス、コンピューティングデバイス）とすることができる。クライアント８０２は、たとえば本発明を使用することによって、クッキーおよび／または関連付けられたコンテキスト情報を収容することができる。システム８００も、１つまたは複数のサーバ８０４を含む。サーバ８０４も、ハードウェアおよび／またはソフトウェア（たとえばスレッド、プロセス、コンピューティングデバイス）とすることができる。サーバ８０４は、たとえば本発明を使用することによって、変換を実行するためのスレッドを収容することができる。クライアント８０２とサーバ８０４との間で考えられる通信の１つは、２つまたはそれ以上のコンピュータプロセス間で伝送するように適合されたデータパケットの形態であってよい。データパケットは、たとえば、クッキーおよび／または関連付けられたコンテキスト情報を含むことができる。システム８００は、クライアント８０２とサーバ８０４との間の通信を容易にするために使用することができる通信フレームワーク８０６を含む。クライアント８０２は、クライアント８０２にとってローカルな情報（たとえば、クッキーおよび／または関連付けられたコンテキスト情報）を格納するために使用することができる１つまたは複数のクライアントデータストア８０８に動作上接続される。同様に、サーバ８０４は、サーバ８０４にとってローカルな情報を格納するために使用することができる１つまたは複数のサーバデータストア８１０に動作上接続される。
【００９２】
上記に説明した内容には、本発明の例が含まれている。本発明を説明する目的で、考えられる構成要素／コンポーネントまたは方法論のあらゆる組合せについて記載することはもちろん不可能であるが、当分野の通常の技術者であれば、本発明の他の多くの組合せおよび置換えが可能であることを認めるであろう。したがって、本発明は、添付の特許請求の範囲の精神および範囲内にあるこのような代替、修正、および変形のすべてを包含することを意図するものである。さらに、「含む」という用語が詳細な説明または特許請求の範囲に使用されている限度で、このような用語は、「備える」が特許請求において移行語として使用されるときに解釈されるように、用語「備える」と同様の仕方で包含的であると意図されている。
【図面の簡単な説明】
【００９３】
【図１】本発明によるレプリケーションの流れ図である。
【図２】アプリケーション定義の整合性ユニットについての追加論理に関する論理レコード手法の流れ図である。
【図３】論理レコード手法の整合性ユニットを示す図である。
【図４】本発明のサンプルスキーマを示す図である。
【図５】図４の例のサンプルデータを示す図である。
【図６】アプリケーション定義のレプリケーションに対する別の手法であって、整合性ユニット変更追跡情報をそれ自体のテーブルに区分する手法を示す図である。
【図７】開示のアーキテクチャを実行するために動作可能なコンピュータのブロック図である。
【図８】本発明によるコンピューティング環境例の概略的なブロック図である。
【符号の説明】
【００９４】
１００  ソース
１０２  デスティネーション
１０４  ソースレプリカ
１０５  整合性ユニット
１０６  デスティネーションレプリカ
１０８  変更識別コンポーネント
１１０  調停コンポーネント
１１２  変更識別コンポーネント
１１４  調停コンポーネント
【図１】
2004295870.tif 000009
【図２】
2004295870.tif 000010
【図３】
2004295870.tif 000011
【図４】
2004295870.tif 000012
【図５】
2004295870.tif 000013
【図６】
2004295870.tif 000014
【図７】
2004295870.tif 000015
【図８】
2004295870.tif 000016
【外国語明細書】
2004295870.tif 000017
2004295870.tif 000018
2004295870.tif 000019
2004295870.tif 000020
2004295870.tif 000021
2004295870.tif 000022
2004295870.tif 000023
2004295870.tif 000024
2004295870.tif 000025
2004295870.tif 000026
2004295870.tif 000027
2004295870.tif 000028
2004295870.tif 000029
2004295870.tif 000030
2004295870.tif 000031
2004295870.tif 000032
2004295870.tif 000033
2004295870.tif 000034
2004295870.tif 000035
2004295870.tif 000036
2004295870.tif 000037
2004295870.tif 000038
2004295870.tif 000039
2004295870.tif 000040
2004295870.tif 000041
2004295870.tif 000042
2004295870.tif 000043
2004295870.tif 000044
2004295870.tif 000045
2004295870.tif 000046
2004295870.tif 000047
2004295870.tif 000048
2004295870.tif 000049
2004295870.tif 000050
2004295870.tif 000051
2004295870.tif 000052
2004295870.tif 000053
2004295870.tif 000054
2004295870.tif 000055
2004295870.tif 000056
2004295870.tif 000057
2004295870.tif 000058
2004295870.tif 000059
2004295870.tif 000060
2004295870.tif 000061
2004295870.tif 000062
2004295870.tif 000063