レプリケーションと関連データ

Standard または Advanced ライセンスで利用可能。

レプリカを作成する際には、アプリケーションに定義されているフィルターに基づいて、行とフィーチャがレプリカに追加されます。 この処理が完了した後、関連オブジェクトを追加するために リレーションシップ クラス が処理されます。

リレーションシップ クラスの処理では、1 つ以上のリレーションシップ クラスに属しているデータセットがそれぞれ評価されます。 データセットを評価する際には、すでに複製されているすべての行が収集され、関連データセットの関連行を検索するために使用されます。 クエリから返された関連行はすべてレプリカに追加されます。 このプロセスでは、各データセットが一度だけ評価されます。

ArcGIS Pro では、リレーションシップ クラスは常に一方向 (順方向) でのみ処理されます。 順方向とは、関連先クラスの関連行をレプリカに追加するために、関連元クラスが評価されることを意味します。 また、レプリカの作成時にリレーションシップ クラスの処理をオフにすることもできます。

次の例は、関連オブジェクトに対するレプリケーションの動作を示しています。 これらの例で使用しているデータ モデルのリレーションシップ クラスは、土地、建物、およびそれらのアノテーションを関連元から関連先への方向で関連付けるシンプルなリレーションシップ クラスです。

例 1

この例は、8 つの土地区画と 6 つの建物をカバーするレプリカ エリアを示しています。 レプリカを作成すると、2 つの建物が追加されます。これは、それらの建物が土地区画に関連しているためです。 また、リレーションシップ クラスの処理によって、建物と土地区画のアノテーションがレプリカに追加されます。

前の例では、関連オブジェクトをレプリカに追加するデフォルトの設定を使用して、レプリカを作成しました。 ArcGIS Pro にある [レプリカの作成 (Create Replica)] ジオプロセシング ツールを使用すると、レプリケーションをカスタマイズし、この動作をグローバル レベルで無効にすることができます。 グローバル レベルでは、レプリケーションの対象フィーチャに関連するオブジェクトを含まないようにレプリケーション プロセスを設定できます。

例 2

この例では、循環リレーションシップで何が起こるかを示しています。 レプリカの作成プロセスでは、処理が無限ループに陥るのを防ぐために、循環を中止するためのロジックが適用されます。 ただし、このロジックにより、リレーションシップが処理される順序は予測不可能となります。

ObjectID フィールドが主キー フィールドであるリレーションシップ クラス

ObjectID フィールドを主キー フィールドとして使用しているリレーションシップ クラスによる複製では、同期中に追加処理を行う必要があり、これがパフォーマンスに影響する可能性があります。 場合によっては、予想外の結果が生じることもあります。 これらの内容について、以下で詳しく説明します。 このセクションに目を通した後で、 ObjectID フィールド以外の主キー フィールドを使用するようにリレーションシップ クラスを変更することもできます。 次に示す適切な代替策を考慮してください。

• リレーションシップ クラスの主キー フィールドには GlobalID タイプのフィールドを使用し、外部キー フィールドには GUID タイプのフィールドを使用します

• データベース全体で一意となる独自の主キー フィールドを作成して使用します。

ObjectID フィールドを主キー フィールドにした場合の同期中の追加処理

フィーチャクラスまたはテーブルの ObjectID 値は、ジオデータベース間で一意ではありません。 あるレプリカ ジオデータベース内の新しい行に割り当てられた ObjectID が、他のレプリカ ジオデータベース内の異なる行の ObjectID と同じである可能性もあります。 リレーションシップの主キーが ObjectID 列である場合、同期プロセスでは、レプリカ ジオデータベース間でリレーションシップを委譲する際に、これらの違いを考慮する必要があります。 このために、同期プロセスでは ObjectID 列を使用するリレーションシップ クラスを検出し、 これに該当するクラスが存在したら、同期プロセスが追加情報を送信します。この情報を使用して必要な処理が実行されます。

この処理には、編集対象の各リレーションシップについて、複製先のジオデータベース内の適切な ObjectID 値をターゲットにするように外部キーの値を調整する処理が含まれます。 多数のリレーションシップの値の調整が必要な場合、この追加処理が同期処理のパフォーマンスに著しい影響を与える可能性があります。

ObjectID フィールドを主キー フィールドにした場合の予想外の結果

ObjectID フィールドを主キー フィールドとして使用している場合に、予期しない動作が見られる可能性のあるケースを次に示します。

• 複製先のレプリカ ジオデータベースに関連元の行が存在しない場合の編集 - 上記のとおり、同期プロセスでは、 ObjectID フィールドがリレーションシップ クラスの主キー フィールドである場合、リレーションシップを維持するために追加処理が実行されます。 ただし、編集のために参照する必要のある関連元の行が相対レプリカ ジオデータベースに存在しない場合、リレーションシップが維持されません。 挿入の場合は、これによって関連先の行の外部キーが NULL に設定されます。 更新の場合は、関連先の行の外部キーの値が同期前の状態のままになります。 この動作はチェックアウト/チェックイン レプリカでは発生しません。

  

  • 上の図は、土地区画と建物の間に存在する単純なリレーションシップ クラスの例を示しています。ここでは、土地区画フィーチャクラスの ObjectID フィールドが関連元の主キーです。 この例では、空間的な範囲内の土地区画と建物に対してのみレプリカが作成されます。 ここで、レプリカの作成後、建物が間違った土地区画内でデジタイズされたことが判明し、 親レプリカ ジオデータベース内で、建物を移動して、正しい土地区画に関連するようにリレーションシップを編集して、これが修正されたとします。 その後、レプリカが同期され、子レプリカに変更内容が適用されます。 この例では、建物が移動されたのに、子レプリカ内では建物は間違った土地区画にまだ関連付けられたままです。 これは、子レプリカ ジオデータベースに正しい関連元の行 (親レプリカでは ObjectID 102 の土地区画) が存在しないために、子レプリカでリレーションシップが変更されなかったからです。 このような場合、リレーションシップが変更されません。

• 孤立した外部キー - レプリカを作成する際に、レプリカの定義内容に基づいて、複製元のジオデータベースから複製先のジオデータベースに行がコピーされます。 レプリカを定義する場合は、関連元テーブルの関連行を含めず、関連先テーブルの行だけを含めるようにすることができます。 このような対応する関連元テーブルの行が存在しない関連先テーブルの外部キーの値は、複製元のジオデータベースに存在したときの値と同じです。 このような外部キーは、参照している関連元の行が複製先のジオデータベースに存在しないため、孤立した外部キーになります。

  

  • 上記の図は、孤立した外部キーがあることによって予想外の動作が発生する例を示しています。 ここでは、親レプリカ ジオデータベースに、土地区画と建物の間の単純なリレーションシップ クラスがあります。 土地区画フィーチャクラスは関連元のフィーチャクラスであるため、主キーとして ObjectID フィールドを使用しています。 作成されるレプリカには、その都市のすべての建物と 1 つの街区の土地区画が含まれます。 レプリカの作成プロセスでは、親レプリカ ジオデータベースから子レプリカ ジオデータベースに、適切な土地区画と建物がコピーされます。 子レプリカでは、これらの土地区画が該当する子レプリカに含まれていないため、その街区以外の土地区画に関連する建物で外部キーの孤立が発生します。 たとえば、ObjectID 100 の土地区画は子レプリカに存在しないため、外部キーが 100 の建物で外部キーの孤立が発生します。 子レプリカに新しい土地区画が作成され、ObjectID が 100 に割り当てられると、気付かないうちにこの新しい土地区画がこの建物に関連付けられてしまいます。

関連トピック

• ジオデータベース レプリケーション タイプ

• 高度なジオデータベース データセットのレプリケーション

• レプリケーションとジオデータベースの互換性

• レプリケーションのためのデータの準備