レプリカを作成する際には、アプリケーションに定義されているフィルターに基づいて、行とフィーチャがレプリカに追加されます。この処理が完了した後、関連オブジェクトを追加するためにリレーションシップ クラスが処理されます。
リレーションシップ クラスの処理では、1 つ以上のリレーションシップ クラスに属しているデータセットがそれぞれ評価されます。データセットを評価する際には、すでにレプリカに追加されているすべての行が収集され、関連データセットの関連行を検索するために使用されます。クエリから返された関連行はすべてレプリカに追加されます。このプロセスでは、各データセットが一度だけ評価されます。
ArcGIS Pro では、リレーションシップ クラスは、必ず一方向 (正方向) でのみ処理されます。正方向とは、関連先クラスの関連する行をレプリカに追加するために、関連元クラスが評価されることを意味します。また、レプリカの作成時にリレーションシップ クラスの処理をオフにすることもできます。
次の例は、関連オブジェクトに関するレプリケーションの設定を示しています。これらの例で使用しているデータ モデルのリレーションシップ クラスは、土地、建物、およびそれらのアノテーションを関連元から関連先へ方向で関連付けるシンプルなリレーションシップ クラスです。
例 1
次の例は、8 つの土地区画と 6 つの建物をカバーするレプリカ エリアを示しています。レプリカを作成すると、土地区画と建物のリレーションシップ クラスに対する処理によって、土地区画に関連する 2 つの建物が追加されます。また、各フィーチャクラスとアノテーションのリレーションシップ クラスの処理によって、建物と土地区画のアノテーションがレプリカに追加されます。
上記の例では、関連オブジェクトを含むデフォルトの設定を使用して、レプリカを作成しました。ArcGIS Pro では、[レプリカの作成 (Create Replica)] ジオプロセシング ツールを使用する場合、レプリケーションをカスタマイズし、この設定をグローバル レベルでオーバーライドできます。グローバル レベルでは、レプリケーションの対象フィーチャに関連するオブジェクトを含まないようにレプリケーション プロセスを設定できます。
例 2
次の例では、循環リレーションシップで何が起こるかを示しています。レプリカの作成プロセスでは、循環を中止して処理が無限ループに陥るのを防ぐためのロジックが適用されます。ただし、このロジックにより、リレーションシップが処理される順序は予測不可能となります。
ObjectID フィールドが主キー フィールドであるリレーションシップ クラス
ObjectID フィールドを主キー フィールドとして使用しているリレーションシップ クラスによる複製では、同期中に追加処理を行う必要があり、これがパフォーマンスに影響する可能性があります。場合によっては、予想外の結果が生じることもあります。これらの内容について、以下のセクションで詳しく説明します。このセクションをよく読んだ後で、ObjectID フィールド以外を主キー フィールドに使用するようにリレーションシップ クラスを変更することもできます。以下のような適切な代替策を検討してください。
- リレーションシップ クラスの主キー フィールドには GlobalID タイプのフィールドを使用し、外部キー フィールドには GUID タイプのフィールドを使用します
- データベース全体で一意の、独自の主キー フィールドを作成し、使用します
ObjectID フィールドを主キー フィールドにした場合の同期中の追加処理
フィーチャクラスまたはテーブルの ObjectID 値は、レプリカに参加している複数のジオデータベース全体では一意ではありません。1 つのレプリカ ジオデータベース内の新しい行に割り当てられた ObjectID が、他のレプリカ ジオデータベース内のまったく違う行の ObjectID と同じ可能性もあります。リレーションシップの主キーが ObjectID 列である場合、同期プロセスでは、レプリカ ジオデータベース間でリレーションシップを転送するときに、これらの違いを考慮する必要があります。このために、同期プロセスでは ObjectID 列を使用するリレーションシップ クラスを検出し、 これに該当するクラスが存在したら、同期プロセスが追加情報を送信します。この情報を使用して必要な処理が実行されます。
この処理には、同期対象の各リレーションシップについて、ターゲット ジオデータベース内の適切な ObjectID 値をターゲットにするように外部キーの値を調整する処理が含まれます。多数のリレーションシップの値の調整が必要な場合、この追加処理が同期処理のパフォーマンスに著しい影響を与える可能性があります。
ObjectID フィールドを主キー フィールドにした場合の予想外の結果
次に、ObjectID フィールドを主キー フィールドとして使用するときに予想外の結果が発生する可能性のある場合について説明します。
- ターゲットのレプリカ ジオデータベースに関連元の行が存在しない場合の編集 - 上述したように、同期プロセスでは、ObjectID フィールドが、リレーションシップ クラスの主フィールドである場合、リレーションシップを維持するために追加処理を実行します。しかし、編集のために参照する必要のある関連元の行が相対レプリカ ジオデータベースに存在しない場合、リレーションシップが維持されません。挿入の場合は、関連先の行の外部キーが null に設定されることになります。更新の場合は、関連先の行の外部キーが同期前の状態のままになります。この振舞いはチェックアウト/チェックイン レプリカでは発生しません。
- 上の図は、土地区画と建物の間に存在する単純なリレーションシップ クラスの例を示しています。ここでは、土地区画フィーチャクラスの ObjectID フィールドが関連元の主キーです。この例では、空間的な範囲内の土地区画と建物に対してのみレプリカが作成されます。ここで、レプリカの作成後、建物が間違った土地区画内でデジタイズされたことが判明し、 親レプリカ ジオデータベース内で、建物を移動して、正しい土地区画に関連するようにリレーションシップが、修正されたとします。次にレプリカが同期され、子レプリカに変更内容が適用されます。この例では、建物が移動されたのに、子レプリカ内では建物は間違った土地区画にまだ関連付けられたままです。子レプリカ ジオデータベースに正しい関連元の行 (親レプリカでは ObjectID 102 の土地区画) が存在しないために、レプリケーションが変更されなかったからです。このような場合、リレーションシップが変更されません。
- 外部キーの孤立 - レプリカを作成する際、レプリカの定義内容に基づいて、複製元のジオデータベースから複製先のジオデータベースに行がコピーされます。レプリカを定義するときには、関連元テーブルの行を含めず、関連先テーブルの行だけを含めるようにすることができます。このような対応する関連元テーブルの行が存在しなし関連先テーブルの行の外部キーの値は、複製元のジオデータベースに存在したときの値と同じです。この場合、外部キーが参照する関連元の行が複製先ジオデータベースに存在しないため、外部キーの孤立が発生します。
- 上の図は、外部キーの孤立によって予想外の結果が発生する例について説明しています。この例では、親レプリカ ジオデータベースに、土地区画と建物の間の単純なリレーションシップ クラスが存在しています。土地区画フィーチャクラスは関連元で、主キーに ObjectID フィールドを使用しています。作成されるレプリカには、その都市のすべての建物と 1 つの街区の土地区画が含まれます。レプリカの作成プロセスでは、親レプリカ ジオデータベースから子レプリカ ジオデータベースに、適切な土地区画と建物がコピーされます。子レプリカでは、その街区以外の土地区画に関連する建物の外部キーが孤立します。これらの土地区画はこの子レプリカに含まれていないからです。たとえば、ObjectID 100 の土地区画は子レプリカに存在しないため、外部キーが 100 の建物では外部キーは孤立しています。子レプリカに新しい土地区画が作成され、ObjectID が 100 に割り当てられると、気付かないうちにこの新しい土地区画がこの建物に関連付けられてしまいます。