リレーションシップ クラスの関連データを使用する際の ArcGIS Pro のヒント、ツール、ジオデータベース機能について説明します。
リレーションシップ クラスのデータのコピー
[コピー]
と [貼り付け] 
を使用して、あるジオデータベースからコピー先ジオデータベースにフィーチャ データセット、フィーチャクラス、またはテーブルをコピーすることができます。 フィーチャ データセット、フィーチャクラスおよびテーブルをコピー アンド ペーストするたびに、結果として各コピー先ジオデータベース内に、コピー元データからのすべてのフィーチャまたはレコードを含んだ新しいフィーチャ データセット、フィーチャクラス、およびテーブルが作成されます。
コピーして貼り付けると、依存するデータもすべてコピーされます。 あるリレーションシップ クラスに属するフィーチャクラスまたはテーブルをコピーしたとします。 その場合は、リレーションシップ クラスと、その中のその他すべてのフィーチャクラスまたはテーブルもコピーされます。 同じことは、フィーチャリンク アノテーション付きのフィーチャクラスにも当てはまります。つまり、フィーチャリンク アノテーションもコピー対象になります。 属性ルールを使用してフィーチャクラスをコピーするときは、すべてのフィーチャクラスと追加のフィーチャクラスまたは属性ルール内で参照されるシーケンスがコピーされます。 フィーチャクラスにドメイン、サブタイプ、またはインデックスがある場合は、これらもコピー対象になります。
注意:
フィーチャクラス → ジオデータベース (Feature Class To Geodatabase) ジオプロセシング ツールではシンプル フィーチャクラスのみがコピーされます。 たとえば、エクスポートするフィーチャ データセットにフィーチャクラスが含まれている場合、コピーされるのはフィーチャクラスだけです。 フィーチャ データセットとその高度なエレメント (トポロジ、リレーションシップ クラス、アタッチメントなど) は、出力ジオデータベースにコピーされません。
リレーションシップ クラスのデータの編集
オブジェクトを変更したときに関連オブジェクトが自動的に更新されるようにリレーションシップ クラスを設定することができます。 これに伴い、関連フィーチャの物理的な移動、関連オブジェクトの削除、属性の更新が行われることがあります。 たとえば、電柱を移動した場合には必ず、付属する変圧器やその他の機器も一緒に移動するように、リレーションシップを設定することができます。 ルールを設定することで、リレーションシップ クラスによって有効なリレーションシップのタイプを制限することができます。 たとえば、電柱では最大 3 個の変圧器がサポートされます。 鋼鉄製の電柱ではクラス A の変圧器がサポートされますが、クラス B の変圧器はサポートされません。 リレーションシップ クラスによって、関連するクラスの一方が ArcGIS Pro セッションに追加されていない場合でも、関連するクラスの間の参照整合性がアクティブに管理されます。 他のオブジェクトとのシンプル リレーションシップに属するオブジェクトをジオデータベースから削除すると、そのリレーションシップもすべて削除されます。 削除されたオブジェクトが関連元オブジェクトである場合、すべての関連先オブジェクトの外部キーが Null になります。 削除されたオブジェクトが関連先オブジェクトである場合、関連元オブジェクトには影響がありません。
リレーションシップが中間テーブルの行として管理されているとします (多対多のリレーションシップまたは属性付きリレーションシップ)。 関連元オブジェクトまたは関連先オブジェクトとそのリレーションシップが削除されると、それらのリレーションシップに対応する行が中間テーブルから削除されます。
[属性] ウィンドウ 
では、選択したフィーチャ間のリレーションシップを作成および削除したり、選択したフィーチャとテーブル内の非空間レコード間に新しいリレーションシップを追加したりできます。 関連付けられるフィーチャは、同じリレーションシップ クラス内に参加している必要があります。
リレーションシップ クラスのデータを編集する方法については、「フィーチャのリレーションシップの編集」をご参照ください。
リレーションシップ クラスによって関連オブジェクトが自動更新されるため、さらなる編集操作を実行する必要はありません。
エンタープライズ ジオデータベースに格納されているリレーションシップ クラスとその関連データを編集および管理する方法については、「リレーションシップ クラスのデータのバージョン対応」をご参照ください。
編集情報の記録とリレーションシップ クラス
編集情報の記録では、フィーチャクラスおよびテーブルに設定が指定され、クラスに対する挿入および更新の情報が自動的に記録されます。 データを作成または変更した編集者と編集が発生したタイム スタンプの記録が維持されます。 編集情報の記録は、既存のデータセットの操作のみに適用され、データセットを作成する操作には適用されません。
リレーションシップ クラスのタイプによっては、編集情報の記録がサポートされません。 多対多 (M:N) の基数または属性付きのリレーションシップ クラスが作成されると、中間テーブルが作成されます。 編集情報の記録は、このようなテーブルベースの属性付きリレーションシップ クラスでのみ有効化できます。 
リレーションシップ クラスのスプリット ポリシーの設定
ライン フィーチャクラスまたはポリゴン フィーチャクラスが作成される際に、デフォルトで、スプリット モデルがフィーチャクラスに自動的に定義されます。 スプリット モデルは、編集中にフィーチャをスプリットする際に、テーブル内のフィーチャのジオメトリと属性を分割する方法を決定します。
フィーチャクラスにスプリット モデルを定義する他に、リレーションシップ クラスにスプリット ポリシーを定義することもできます。 リレーションシップ クラスのスプリット ポリシーは、編集中に関連元のフィーチャクラス内のフィーチャを分割する際に、関連先テーブル内の関連レコードをどう処理するかを決定します。
リレーションシップ クラスのタイプ (シンプルまたはコンポジット) に応じて、デフォルト (シンプル)、デフォルト (コンポジット)、関連オブジェクトの複製など、さまざまなスプリット ポリシーの動作を定義できます。
このリレーションシップ クラスのプロパティの設定方法と使用方法については、「リレーションシップ クラスのスプリット ポリシーの設定」をご参照ください。
リレーションシップ属性の操作
ArcGIS Pro には、リレーションシップの構築および維持に役立つツールがあります。
- 関連元クラスおよび関連先クラスにオブジェクトが存在するが、それらのオブジェクトがまだ関連付けられていない場合は、ArcGIS Pro で、手動でリレーションを 1 つずつ確立できます。 これを実行するには、関連先クラス内の 1 つ以上のオブジェクトを選択し、関連元クラス内の 1 つ以上のオブジェクトを選択してから、[属性] ダイアログ ボックスを開いて、それらを関連付けます。 ただし、これを実行できるのは、リレーションシップの少なくともどちらかの側がフィーチャを含んでいる場合です。
- オブジェクトがテーブル内の新しいレコードであり、フィーチャでない場合は、そのオブジェクトを選択してから、関連するオブジェクトを関連するクラス内に作成できます。
- [属性] ダイアログ ボックスを使用して、リレーションシップからオブジェクトを削除できます。
- コンポジット リレーションシップまたはルールを含むリレーションシップの編集が完了したら、検証または制約属性ルールを使用して、作業内容をチェックしてデータの参照整合性を確保します。
属性付きリレーションシップ クラスの属性インデックス
属性インデックスを使用して、テーブル、フィーチャクラス、シェープファイル、または属性付きリレーションシップ クラスでの結合や属性検索によるレコードの検索を高速化することができます。
ほとんどの属性検索では、テーブル全体のレコードを最初から最後まで検索するよりも、インデックスを使用してレコードを検索するほうが高速です。 テーブル、フィーチャクラス、シェープファイル、または属性リレーションシップ クラスにデータを設定したら、頻繁にクエリするフィールドに属性インデックスを作成できます。
リレーションシップ クラスのデータに対する属性ルール
属性ルールは、ジオデータベースのリレーションシップ クラスに属するデータセットの関連レコードを読み取り、編集するために使用されます。
ルールは、リレーションシップ クラスに属するフィーチャクラスとテーブルに適用できます。これには、アタッチメントとフィーチャリンク アノテーションが含まれます。 属性ルールによって、リレーションシップの関連元クラスと関連先クラスに対する更新から編集イベント (関連レコードの追加、除去、削除) をインターセプトすることもできます。 たとえば、即時計算属性ルールでは、フィーチャを関連フィーチャクラスに追加するときに、属性フィールドを更新できます。
リレーションシップ クラスを操作する場合、入力フィーチャを受け取り、関連レコードを返す Arcade 関数を使用して、関連レコードを読み取ることができます。 リレーションシップ クラスの関連レコードは、ディクショナリ リターンに基づく計算ルールを使用して編集することもできます。
計算属性ルールで Arcade 関数とスクリプト式を使用して、リレーションシップ クラスの関連データにアクセスすることができます。 リレーションシップ クラスの関連レコードを読み取るには、Arcade 関数 FeatureSetByName、FeatureSetByRelationShipName、および FeatureSetByRelationshipClass を使用します。 更新編集時に、リレーションシップ クラスの新しい関連レコードを追加することもできます。 
注意:
多対多または属性付きリレーションシップ クラスを作成すると、新しい中間テーブルが作成されます。 この中間テーブルはジオデータベースでオブジェクト クラスとしては認識されません。 したがって、この中間テーブルでは、属性ルール、ドメイン、サブタイプ、条件値、デフォルト値などのジオデータベースの動作を適用および使用することはできません。
権限とリレーションシップ クラス
他のデータベース ユーザーがデータベースまたはエンタープライズ ジオデータベースのデータの内容を表示または変更できるようにしたい場合は、そのための権限を付与する必要があります。
1 つのリレーションシップ クラスに属するフィーチャクラスまたはテーブルに権限を付与するときには、関連元クラスと関連先クラスの両方に権限を付与する必要があります。 関連元フィーチャクラスと関連先フィーチャクラスが同じフィーチャ データセット内にあるときは、どちらのフィーチャクラスも同じ権限のセットを持ちます。これは、権限がフィーチャ データセットのレベルで付与されるためです。 しかし、関連元クラスまたは関連先クラスが同じフィーチャ データセット内にないときは、両方のクラスに適切な権限が付与されるようにしなければなりません。 リレーションシップ クラスが属性付きか、多対多の基数を持つ場合は、関連元クラスに権限を付与したときに、中間テーブルに権限が自動的に反映されます。
リレーションシップ クラスのデータのバージョン対応
リレーションシップ クラスはジオデータベース内に格納されて永続化され、容易に編集できます。 エンタープライズ ジオデータベース内のリレーションシップ クラスは次の編集ワークフロー オプションでサポートされています。
リレーションシップ クラスと関連データがエンタープライズ ジオデータベースに格納されている場合、データに対する編集をバージョンによって管理することができます。 複数の編集者がいるエンタープライズ ジオデータベースでは、ロックを適用したりデータを複製したりしなくても、バージョンを使用することで、複数のユーザーがリレーションシップ内の同じフィーチャやレコードを同時に操作して編集することができます。 バージョンでは、編集者ごとに自分専用の個別のデータ表示が提供されます。
ブランチ バージョニングとリレーションシップ クラスに関するヒント
データセットがリレーションシップ クラスに属し、リレーションシップの主キーが ObjectID フィールドである場合、データセットをブランチ バージョン対応登録することはできません。
ヒント:
[リレーションシップ クラスの移行 (Migrate Relationship Class)] ジオプロセシング ツールを使用して、Global ID ベースのリレーションシップ クラスに Object ID ベースのリレーションシップ クラスを移行します。
ブランチ バージョニングで、名前付きバージョンがデフォルト バージョンとリコンサイルされた場合、リコンサイル プロセス中に競合が検出されることがあります。 たとえば、トポロジ的に関連しているフィーチャまたはリレーションシップ クラスが、現在の名前付きバージョンとデフォルト バージョンの両方で変更された場合、競合が発生します。
ヒント:
競合ビューを使用して、名前付きバージョンとデフォルト バージョンの編集の競合を確認します。 
ブランチ バージョニングでは、競合を解決する際に、維持するフィーチャと属性の状態を決定します。 関連元のリレーションシップ クラスからフィーチャを削除すると、関連先のリレーションシップ クラスからフィーチャを削除するためのメッセージがトリガーされることがあります。 このため、リレーションシップ クラスに属しているソース フィーチャクラスの競合を置換した場合の影響に気をつける必要があります。
トラディショナル バージョニングとリレーションシップ クラスに関するヒント
トラディショナル バージョニングでは、エンタープライズ ジオデータベースから直接アクセスした場合はロング トランザクションのバージョン内で柔軟に作業でき、フィーチャ サービスを使用してショート トランザクションに対応する場合は簡単に操作できます。
ベース テーブル移行オプションを使用したトラディショナル バージョニングは、トラディショナル バージョニングのオプションの形式の 1 つです。 このバージョニングでは、編集者とアプリケーションがベース データに直接アクセスできると同時に、他の編集者が各自の個別バージョンで作業することができます。 このオプションにも、トラディショナル バージョニングと同様のメリットの多くがあります。 ただし、編集できるのは、シンプル フィーチャ (ポイント、ライン、ポリゴン、アノテーション、リレーションシップ クラスなど) のみです。 トポロジ、ネットワーク データセット、ユーティリティ ネットワーク内のフィーチャクラスを編集できません。
トラディショナル バージョニングでは、編集内容をバージョンに保存する際、そのバージョンの同じフィーチャが別の編集セッションで更新されていた (または、あるセッションで更新され、別のセッションで削除されていた) 場合、リコンサイル操作中に競合が検出されることがあります。
ヒント:
トラディショナル バージョニングで、編集するユーザーとリコンサイルするユーザーが別であるようなワークフローを使用している場合、リコンサイルを実行するユーザーに、そのバージョンで変更されたすべてのフィーチャクラスおよびテーブルへの完全な権限を付与する必要があります。権限がない場合は、リコンサイルを実行することはできません。 権限の付与に関する上記のセクションで説明したように、リコンサイルを実行するユーザーには、変更されたリレーションシップがシンプルかコンポジットかを問わず、リレーションシップ クラスに属する関連元クラスと関連先クラスの両方に対する完全な権限が必要です。 このワークフローでは、リコンサイルを実行するユーザーには適切なバージョン権限も必要です。 リコンサイルを実行するユーザーは、リコンサイルするバージョンを変更できる、つまり、そのバージョンにパブリックの権限が許可されている必要があります。さらに、ターゲット バージョンを参照できる、つまり、ターゲット バージョンを所有しているか、ターゲット バージョンにパブリックまたはプロテクトの権限が許可されている必要があります。
トラディショナル バージョニングでは、競合を解決する際に、維持するフィーチャと属性の状態を決定します。 関連元のリレーションシップ クラスからフィーチャを削除すると、関連先のリレーションシップ クラスからフィーチャを削除するためのメッセージがトリガーされることがあります。 このため、リレーションシップ クラスに属しているフィーチャクラスの競合を置換した場合の影響に気をつける必要があります。 たとえば、電力フィーチャ データセット内の、1 つまたは複数の変圧器に関連付けられている電柱を削除した場合、関連する変圧器も削除されます。
リレーションシップ クラスでのジオデータベース レプリケーションの使用
ジオデータベース レプリケーションでは、エンタープライズ ジオデータベース内の一部またはすべてのデータセットを複製できます。 また、フィルターおよびリレーションシップ クラスを使用して、複製するフィーチャまたは行を定義することができます。 レプリカを作成する際には、アプリケーションに定義されているフィルターに基づいて、行とフィーチャがレプリカに追加されます。 次に、リレーションシップ クラスを使用して、フィーチャと行がさらに追加されます。
次の例は、関連オブジェクトに関するレプリケーションの動作を示しています。 この例で使用しているデータ モデルのリレーションシップ クラスは、土地、建物、およびそれらのアノテーションを関連元から関連先への方向で関連付けるシンプルなリレーションシップ クラスです。
詳細については、「レプリケーションのためのデータの準備」をご参照ください。
同期中にリレーションシップが維持されます。 双方向レプリケーションおよび一方向レプリケーションでは、レプリカの作成で使用された同じフィルターとリレーションシップ クラス ルールが同期中に適用されます。 送信する変更を決定する場合には、各レプリカ データセットに含まれている編集内容のうち、最後の同期以降に適用されたすべての編集内容が評価されます。 編集内容がレプリカのフィルター条件を満たしている場合は、その編集内容が同期されます。
たとえば、関連元クラスの一部のフィーチャ (建物など) がレプリケーションの対象として選択されています。 建物は、シンプル リレーションシップ クラスを使って、レプリケーションから除外されたテーブル内の属性レコードに関連付けられています。 子レプリカでの編集中に、1 つの建物が削除されました。 同期を実行すると、削除されたフィーチャとのリレーションシップを無効にするために、関連先クラス (テーブル) の外部キー フィールド内の対応するエントリが NULL に設定されます。
リレーションシップ クラスが含まれているデータセットの共有
フィーチャ サービスで関連データに関するクエリを実行できますが、公開する前に、ジオデータベース リレーションシップ クラスを介してリレーションシップが定義されており、関連元テーブルと関連先テーブルがどちらもマップ内に存在している場合に限ります。
フィーチャ サービスまたはホスト フィーチャ レイヤー内の関連データに対してクエリを実行するには、フィーチャクラスと関連テーブルまたはフィーチャクラスの間にリレーションシップ クラスを定義します。 リレーションシップ クラスを介してアクセスした関連データが、公開するフィーチャ サービスに含まれます。 関連付けられたオブジェクトを返すクエリを実行できるようにするには、リレーションシップ クラスに関連するテーブルとレイヤーを公開済みのマップに含める必要があります。 関連元/関連先のレイヤーまたはテーブルがマップに含まれていない場合、フィーチャ サービスはそのリレーションシップを無視します。
注意:
属性リレーションシップ クラスでは、リレーションシップ クラス テーブルをマップに含めます。
フィーチャ サービスを公開するためのデータの準備、フィーチャ サービスの作成、サービスを介した関連データの操作 (ビデオ) の詳細