レプリカの作成とバージョニング（ArcInfo および ArcEditor のみ）

このトピックは、ArcGIS for Desktop Standard および ArcGIS for Desktop Advanced にのみ該当します。

ジオデータベース レプリケーションはバージョニングに基づいて構築されています。レプリカを作成する際、複製元のジオデータベースと複製先のジオデータベース内のバージョンをレプリカ バージョンとして設定します。これらのレプリカ バージョンに対する変更は、レプリカの同期の過程で交換されます。複製元と複製先のレプリカ バージョンはリンクされているため、ジオデータベース レプリケーションはバージョン ツリーを複数のジオデータベースに拡張するための手段と考えることができます。

DEFAULT バージョンまたは名前付きバージョンは、親レプリカまたは子レプリカのレプリカ バージョンとして使用することができます。複数のレプリカが同じレプリカ バージョンを共有することも可能です。親レプリカまたは子レプリカでレプリカ バージョンを設定する方法につては、「レプリカの作成」をご参照ください。

次の図は、一方向レプリカと双方向レプリカのレプリカ バージョンを示しています。双方向レプリケーションの場合、親レプリカはレプリカ バージョンとして名前付きバージョン RV1 を使用します。一方向レプリケーションの例における親レプリカは、レプリカ バージョンとして名前付きバージョン RV2 を使用します。

注意:

すべてのレプリカを同じ名前付きバージョンから作成することも、すべてを DEFAULT バージョンから作成することも、名前付きバージョンと DEFAULT バージョンの組み合わせから作成することもできます。

以下の例の図では、ArcSDE ジオデータベースにホストされている 2 つの子レプリカのレプリカ バージョンには DEFAULT バージョンが使用されています。レプリカ バージョンは、レプリケーションに使用されること以外、以下の図に示されている V1 や V2 といった他のバージョンとまったく同じです。

注意:

下の図に示された ArcSDEジオデータベースにホストされている 2 つの子レプリカ バージョンに名前付きバージョンを使用することもできます。

ファイル ジオデータベースとパーソナル ジオデータベースではバージョニングがサポートされないため、図に示されているように ファイル ジオデータベースもしくはパーソナル ジオデータベースを使用した一方向レプリケーションで子レプリカのレプリカ バージョンは作成されません。

チェックアウト レプリケーションでは、バージョン対応データとバージョン非対応データの両方を複製することができます。バージョン対応データを使用したチェックアウト レプリカの場合は、子レプリカのレプリカ バージョンとして新しい名前付きバージョンが親レプリカに作成されます。

また、チェックアウト レプリケーションでは、パーソナルまたはファイル ジオデータベースで子レプリカをホストすることができます。これらのジオデータベース タイプではバージョニングがサポートされないため、子レプリカのレプリカ バージョンは作成されません。これは、バージョン非対応データのチェックアウトの場合も同じです。これらのシナリオでは、同期の際に送信する変更を判断するために、別のロジックが使用されます。

次の図は、チェックアウト レプリカとそのレプリカ バージョンの例を 2 つ示しています。一方の親レプリカがレプリカ バージョンとしてバージョン RV1 を使用し、もう一方の親レプリカがレプリカ バージョンとしてバージョン RV2 を使用しています。一方の子レプリカはファイル ジオデータベースによってホストされ（またはパーソナル ジオデータベース）、もう一方の子レプリカは ArcSDE ジオデータベースによってホストされています。ArcSDE ジオデータベースが子レプリカをホストしている場合、RV2 が自動的に作成され、作成中にレプリカ バージョンとして設定されます。このレプリカの RV2 という名前は、レプリカを作成するときに使われた親レプリカのレプリカ バージョンの名前が使用されています。

チェックアウト レプリカの作成時には、同期バージョンが親レプリカのジオデータベースに作成されます。同期バージョンはレプリカ バージョンの子バージョンですが、同期処理実行時にのみ使用されるため、この図には示されていません。詳細については、「同期とバージョング」をご参照ください。

履歴管理を使用したレプリカの変更追跡

一方向レプリケーションの場合のみ、バージョニングの代わりに履歴管理を使用して、レプリカの変更内容を追跡することを選択できます。このオプションを選択するには、複製元のレプリカ バージョンが DEFAULT バージョンである必要があります。

この方法でレプリケーションを管理する利点は、レプリカの同期プロセスと、リコンサイル、ポスト、圧縮などのプロセスをそれぞれ独立したプロセスとして運用できることです。バージョニングを使用して変更を追跡する場合には、レプリカ バージョンなどのシステム バージョンが作成されます。効果的な圧縮を実行するには、これらのシステム バージョンの変更を圧縮可能にするために、定期的な同期を行う必要があります。

履歴管理を使用してレプリカの変更を追跡する場合、システム バージョンは作成されません。したがって、リコンサイルとポストのプロセスや圧縮のプロセスはレプリカの影響を受けず、バージョン管理とレプリケーション管理がそれぞれ独立したものになります。これによって、同期のスケジュールもより柔軟に設定できます。

履歴管理を使用するにはデータがバージョン対応登録されている必要があるので、複製元のレプリカは ArcSDE ジオデータベース内に存在する必要があります。また複製元のレプリカ バージョンが DEFAULT バージョンである必要があります。

下の図では、ArcSDE ジオデータベース間の親から子への一方向レプリケーションが示されており、ここでは親レプリカと子レプリカの両方のレプリカ バージョンに DEFAULT バージョンが使用されています。ファイル ジオデータベースとパーソナル ジオデータベースではバージョニングがサポートされないため、図に示されているように、ファイル ジオデータベースもしくはパーソナル ジオデータベースを使用した一方向レプリケーションでは子レプリカのレプリカ バージョンは作成されません。

ジオデータベースが両方とも ArcSDE ジオデータベースであれば、子から親への一方向レプリケーションも使用できます。この場合、子レプリカのレプリカ バージョンが DEFAULT バージョンでなくてはなりません。