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

このトピックは、ArcEditor および ArcInfo にのみ適用されます。

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

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

各リレーションシップ クエリは、一方向でのみ処理されます。デフォルトでは、この方向は正方向ですが、作成時に逆方向に切り替えることもできます。正方向とは、関連先クラスの関連する行をレプリカに追加するために、関連元クラスが評価されることを意味します。逆方向とは、関連元クラスの関連する行をレプリカに追加するために、関連先クラスが評価されることを意味します。また、レプリカの作成時に特定のリレーションシップ クラスの処理をオフにすることもできます。

各データセットは一度だけ評価され、各リレーションシップ クラスは一方向でのみ評価されるため、データセットが評価される順番が重要となります。リレーションシップ クラスの処理には、関連性が最も高いオブジェクトが追加される順序でデータセットを処理するためのロジックがあります。データセットが処理される順序を制御するには、方向を切り替えるか、特定のリレーションシップ クラスの処理をオフにします。

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

例 1

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

例 2

次の例は、正方向処理の場合のリレーションシップのレプリケーションを示しています。親レプリカで、レプリケーションの対象として 2 つの建物を選択し、関連レコードにデフォルトの正方向処理を使用することにより、これらの建物に関連するアノテーションも子レプリカに追加されます。

次の図は、前の例と同じ 2 つの建物を選択し、土地区画から建物への リレーションシップ クラスに逆方向処理を使用するケースを示しています。この場合は、建物の関連アノテーションに加えて、それらの建物に関連する土地区画と土地区画のアノテーションも子レプリカに追加されます。

例 3

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

次の例では、レプリカ エリアで建物と土地区画を選択していますが、関連レコードを含まないオプションが選択されているので、建物と土地区画に関連するアノテーションは子レプリカに追加されません。

例 4

次の例では、レプリカ エリアに関連建物を持つ 4 つの土地区画（17691、17692、17698、17697）が含まれていますが、明示的に建物がレプリカに含まれないように設定されています。常に関連オブジェクトが含まれるグローバルのデフォルト設定は、他のフィーチャクラスでは有効なので、土地区画のアノテーションは再びレプリカに含まれます。

例 5

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

循環リレーションシップの結果を予測可能にするためには、リレーションシップの 1 つを処理の対象から外すか、リレーションシップ クラスの 1 つで逆方向処理を選択します。たとえば、次の図は、R3 が逆方向処理に設定された場合を示しています。これにより、処理の順序は予測可能（T1 - T2 - T3）となります。この場合、T3 には T1 および T2 の関連レコードが追加されますが、T3 のレコードは T1 または T2 に追加されません。

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

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

• リレーションシップ クラスの主キー フィールドには GlobalID タイプのフィールドを使用し、外部キー フィールドには GUID タイプのフィールドを使用します
• データベース全体で一意の、独自の主キー フィールドを使用します

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

フィーチャクラスまたはテーブルの ObjectID 値は、レプリカに参加している複数のジオデータベース全体では一意ではありません。1 つのレプリカ ジオデータベース内の新しい行に割り当てられた ObjectID が、他のレプリカ ジオデータベース内のまったく違う行の ObjectID と同じ可能性もあります。リレーションシップの主キーが ObjectID 列である場合、同期プロセスでは、レプリカ ジオデータベース間でリレーションシップを転送するときに、これらの違いを考慮する必要があります。このために、同期プロセスでは ObjectID 列を使用するリレーションシップ クラスを検出し、これに該当するクラスが存在したら、同期プロセスが追加情報を送信します。この情報を使用して必要な処理が実行されます。この処理には、同期対象の各リレーションシップについて、ターゲット ジオデータベース内の適切な ObjectID 値をターゲットにするように外部キーの値を調整する処理が含まれます。多数のリレーションシップの値の調整が必要な場合、この追加処理が同期処理のパフォーマンスに著しい影響を与える可能性があります。

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

次に、予想外の結果が発生する場合について説明します。

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

  

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

• 外部キーの孤立

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

  

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