リレーションシップ クラスの作成ツールのパラメーター

[リレーションシップ クラスの作成 (Create Relationship Class)] ジオプロセシング ツールを実行する場合にパラメーター値をどのように設定するかは、必要なリレーションシップ クラスのタイプおよび適用する必要があるルールによって異なります。

どの値を使用すべきかをすぐに把握できるように、以下で [リレーションシップ クラスの作成 (Create Relationship Class)] ジオプロセシング ツールの入力パラメーターについて説明します。

パラメーター

[リレーションシップ クラスの作成 (Create Relationship Class)] ジオプロセシング ツールの各パラメーターについて以下で説明します。

• 関連元テーブル - 関連先のテーブルに関連付けられているテーブルまたはフィーチャクラス。
• 関連先テーブル - 関連元のテーブルに関連付けられているテーブル。
• 出力リレーションシップ クラス - 作成されるリレーションシップ クラスの名前。
• リレーションシップ タイプ - 関連元テーブルと関連先テーブルの間に作成されるリレーションシップのタイプ。
  • [シンプル] - 関連元テーブルと関連先テーブルの間にシンプル リレーションシップが作成されます。 これがデフォルトです。
  • [コンポジット] - 関連元テーブルと関連先テーブルの間にコンポジット リレーションシップが作成されます。
• 正方向 (関連元から関連先へ) - 関連元テーブルから関連先テーブルへのリレーションシップを一意に識別する名前。
• 逆方向 (関連先から関連元へ) - 関連先テーブルから関連元テーブルへのリレーションシップを一意に識別する名前。
• 情報伝達方向 - 関連元テーブルと関連先テーブルの間でメッセージが送られる方向。 たとえば、電柱と変圧器の間のリレーションシップでは、電柱が削除されると、削除されたことを知らせるメッセージが、電柱から関連する変圧器オブジェクトへ送信されます。
  • [正方向] (関連元から関連先へ) - 関連元テーブルから関連先テーブルにメッセージが送られます。
  • [なし] (メッセージを伝達しない) - メッセージは送られません。 これがデフォルトです。
• 基数 - 関連元テーブル内の行またはフィーチャと関連先テーブル内の行またはフィーチャの間に存在するリレーションシップの数を指定します。
  • [1 対 1 (1:1)] - 関連元テーブル内の各行またはフィーチャを、関連先テーブル内の 0 個または 1 個の行またはフィーチャに関連付けることができます。 これがデフォルトです。
  • [1 対多 (1:M)] - 関連元テーブル内の各行またはフィーチャを、関連先テーブル内の 1 個または複数の行またはフィーチャに関連付けることができます。
  • [多対多 (M:N)] - 関連元テーブル内の複数の行またはフィーチャを、関連先テーブル内の 1 個または複数の行またはフィーチャに関連付けることができます。
• [リレーションシップ クラスに属性を含める] - リレーションシップ クラスに属性を含めるかどうかを指定します。 これらの属性が格納される場所および属性付きリレーションシップ クラスを作成および設定する方法については、「属性付きリレーションシップ クラス」をご参照ください。
  • オン - リレーションシップ クラスに属性が含まれます。
  • オフ - リレーションシップ クラスに属性は含まれません。 これがデフォルトです。

• 関連元テーブルの主キー - 属性付きでない 1 対 1 または 1 対多のリレーションシップ クラスの場合、これは関連元テーブルのフィールドであり、通常は PK と省略され、関連先テーブルの関連元の外部キー フィールドにリンクしています。

  多対多または属性付きリレーションシップ クラスの場合、これは関連元テーブルのフィールドであり、中間リレーションシップ クラス テーブルの関連元の外部キー フィールドにリンクしています。

• 関連元の外部キー - 属性付きでない 1 対 1 または 1 対多のリレーションシップ クラスの場合、これは関連先テーブルのフィールドであり、通常は FK と省略され、関連元テーブル内の関連元テーブルの主キー フィールドにリンクしています。

  1 対多または属性付きリレーションシップ クラスの場合、これは関連元テーブル内の関連元テーブルの主キー フィールドにリンクしている、中間リレーションシップ クラス テーブル内のフィールドです。

• 関連先テーブルの主キー - 中間リレーションシップ クラス テーブルの関連先の外部キー フィールドにリンクしている、関連先テーブルのフィールド。 この値は、多対多または属性付きリレーションシップ クラスでは必須ですが、属性付きでない 1 対 1 または 1 対多のリレーションシップ クラスでは空のままにする必要があります。
• 関連先の外部キー - 関連先テーブルの関連先主キー フィールドにリンクしている、中間リレーションシップ クラス テーブルのフィールド。 この値は、多対多または属性付きリレーションシップ クラスでは必須ですが、属性付きでない 1 対 1 または 1 対多のリレーションシップ クラスでは空のままにする必要があります。

関連元クラスと関連先クラス

リレーションシップ クラスを作成する際には、関連元となるクラスと関連先となるクラスを選択します。 ここで 2 つを取り違えないことが重要となります。 コンポジット リレーションシップでカスケード削除が適用されることを考えれば、その重要性は明らかです。

シンプル リレーションシップでは、これを正確に行うことが不可欠です。 これは、関連元クラスでレコードを削除すると、シンプル リレーションシップ クラスが関連先クラスで対応するレコードを検索し、そのキー フィールドの値を NULL に設定するためです。 関連元クラスの選択を誤った場合、関連元クラスを削除すると、外部キー フィールドでエラーが発生します。 次の例は、これがどのように発生するのかを示しています。

関連元と関連先の選択を取り違えないことが重要です。

ケース 1: Parcel (土地区画) から Zone (土地利用) へのリレーションシップ (正しくない)

これは一般的なエラーです。 Zone テーブルにはさまざまなゾーン コードの説明が含まれており、概念的にはルックアップ テーブルに似ています。 この場合は、Parcel クラスが関連元、Zone テーブルが関連先です。 問題は、Percel を削除すると、Zone テーブルの対応するレコードのキー フィールド (Zone) の値が NULL に設定され、ゾーン コードを持つ他の Perce が Zone テーブルのレコードと一致しなくなることです。

ケース 2: Zone (土地利用) から Parcel (土地区画) へのリレーションシップ (正しい)

この問題を修正するために、Zone テーブルを関連元として設定します。 Percel (関連先オブジェクト) を削除しても、Zone テーブルが影響を受けることはありません。ゾーン コード (関連元オブジェクト) を削除すると、Parcel クラスの対応するレコードの Zone フィールドが Zone テーブルのレコードと一致しなくなるので、単にその値が NULL に設定されます。

出力リレーションシップ クラス名

各リレーションシップ クラスには、[カタログ] ウィンドウに表示される名前が付いています。 リレーションシップ クラスには、そのリレーションシップに属しているエレメントとリレーションシップの基数を表す名前を付けることをお勧めします。

リレーションシップ クラスの名前は、関連元のフィーチャクラスの名前、それに続く Has または Have、最後に関連先フィーチャクラスの名前で構成されます。 たとえば、AddressHasZones または ParcelsHaveOwners のようになります。 基数が多対 1 または多対多の場合は、関連元のフィーチャクラスの名前を複数形にし、基数が 1 対多または多対多の場合は、関連先のフィーチャクラスの名前を複数形にします。

この命名規則に基づいて、リレーションシップ クラスの基数をその名前から判断することができます。 たとえば、両方のフィーチャクラスの名前が複数形である ParcelsHaveOwners は、リレーションシップが多対多であることを示します。

名前はジオデータベースにおいて一意でなければなりません。同じ名前のオブジェクト (テーブル、フィーチャクラス、リレーションシップ クラスなど) を複数作成することはできません。 フィーチャクラス名とテーブル名のルールと制限事項については、「フィーチャクラスのプロパティの定義」をご参照ください。

正方向パス ラベルと逆方向パス ラベル

ArcGIS Pro の [属性] ダイアログ ボックスと [個別属性] ダイアログ ボックスに表示される正方向ラベルと逆方向ラベルは、関連オブジェクトのナビゲーションに役立ちます。

リレーションシップ クラスには、次の 2 つのラベルがあります。

• 関連元から関連先へナビゲートしたときに表示される正方向ラベル。 電柱と変圧器の例では、この電柱がこれらの変圧器をサポートすることを意味する [サポート] というラベルを使用できます。
• 関連先から関連元へナビゲートしたときに表示される逆方向ラベル。 電柱と変圧器の例では、これらの変圧器がこの電柱に設置されることを意味する [設置される] というラベルを使用できます。

メッセージの通知方向

先に説明したように、コンポジット リレーションシップで関連元オブジェクトを削除すると、関連先オブジェクトも自動的に削除されます。

コンポジット リレーションシップを使用している場合、あるフィーチャの更新に応じて、その関連フィーチャを更新しなければならない操作があります。

• 関連元フィーチャを移動または回転する際には、それに合わせて関連先フィーチャを移動または回転する必要があります。
• 関連元フィーチャを更新する際、関連先フィーチャの属性を自動的に更新する必要があります。
• 関連元オブジェクトの更新に応じて、関連先オブジェクトの更新を要求することができます。

この振舞いがリレーションシップに必要な場合は、関連元オブジェクトと関連先オブジェクトに、それらが変更されたことを互いに通知するメッセージを送信させ、関連オブジェクトを適切に更新することができます。

[正方向] メッセージングのコンポジット リレーションシップを作成する場合、関連元オブジェクトを移動または回転すると、それに合わせて、関連先オブジェクトが自動的に移動または回転します。 リレーションシップを正しくセットアップすれば、この機能はリレーションシップを作成した直後に有効となります。

メッセージが正方向のコンポジット リレーションシップを作成する場合を除いて、メッセージの通知は [なし] に設定してください。 そうしないと、編集操作を行うたびに必要のないメッセージが生成され、パフォーマンスが低下します。

コンポジット リレーションシップの方向を設定する際には、コンポジット リレーションシップの関連元オブジェクトが削除されると、関連先のすべてのオブジェクトが自動的に削除されることに注意してください。 メッセージングを [正方向] または [なし] のどちらに設定した場合でも、これは避けられません。

メッセージの通知方向

方向	シンプル リレーションシップ	コンポジット リレーションシップ
正方向	影響なし	関連元オブジェクトを削除すると関連先オブジェクトも削除される。 関連元オブジェクトの移動または回転により関連先オブジェクトが移動または回転する。
なし	メッセージの送信を回避すると、パフォーマンスがわずかに向上する	関連元オブジェクトを削除すると関連先オブジェクトも削除される。 他のメッセージの送信が阻止されるため、パフォーマンスがわずかながら向上する。

基数

基数は、2 つの異なるテーブルの行または列の間の関連付けの最大数を表します。

GIS では地理エンティティ オブジェクトと非地理エンティティ オブジェクトに関する情報が統合され、その多くは関連付けることができます。 非地理データをフィーチャ データに追加する際には、オブジェクトの関連性および共通フィールドの有無について考慮する必要があります。

リレーションシップは、関連元テーブルと関連先テーブル、および関連元テーブル内のオブジェクトと関連先テーブル内のオブジェクトの関係の概念を中心にして構築されます。 2 つのテーブル間にリレーションシップを作成するには、キーと呼ばれる共通の値を持つ、両方に共通のフィールドを特定する必要があります。

注意:

共通フィールドは、同じ名前である必要はありませんが、同じデータ タイプである必要があります。 共通フィールドの値を使用して、定義済みの基数に基づいてテーブル内のレコードがリンクされます。

リレーションシップの基数は、関連元テーブルのいくつのオブジェクトが関連先テーブルのいくつのオブジェクトに関連するかを示します。 リレーションシップ クラスには、次の 3 つの基数のいずれかを指定することができます。

• 1 対 1 - 関連元クラスまたはテーブル内の 1 つの行またはフィーチャを、関連先クラスまたはテーブル内の 0 個または 1 個の行またはフィーチャに関連付けることができます。 この設定がデフォルトです。 たとえば、土地区画の登記簿は 1 つだけです。

  注意:

  ArcGIS では、この基数は多対 1 もカバーします。 多対 1 のリレーションシップの例としては、同じ法的な説明に関連する複数の土地区画が挙げられます。

• 1 対多 - 関連元クラスまたはテーブル内の 1 つの行またはフィーチャを、関連先クラスまたはテーブル内の 1 個または複数の行またはフィーチャに関連付けることができます。 たとえば、1 つの土地区画に複数の建物を関連付けることができます。 1 対多のリレーションシップでは、1 の側が関連元クラス、多の側が関連先クラスでなければなりません。
• 多対多 - 1 つの関連元オブジェクトを複数の関連先オブジェクトに関連付けることができ、逆に、1 つの関連先オブジェクトを複数の関連元オブジェクトに関連付けることができます。 たとえば、1 つの土地が複数の所有者によって所有され、1 人の所有者が複数の土地を所有することがあります。 詳細については、「属性付きリレーションシップ クラス」をご参照ください。

注意:

2 つのテーブル間のオブジェクトの基数を評価する際、「1」とは実際にはゼロ対 1 であり、「多」とは実際にはゼロ対多です。 したがって、たとえば土地区画と建物の間に 1 対多のリレーションシップを作成した場合、そのリレーションシップでは次のどの状況も有効です。

• 土地区画に建物がない
• 建物はあるが土地区画がない
• 1 つの土地区画に任意数の建物がある

リレーションシップ クラスが作成された場合、リレーションシップ クラスにルールを追加することで、基数をさらに制御することができます。 関連先クラス内の複数の行またはフィーチャに関連付けることが許可される、関連元クラスまたはテーブル内の行またはフィーチャの数を指定するルールを追加することができます。

注意:

基数はリレーションシップ クラスの作成時に定義されます。 リレーションシップ クラスがいったん作成されたら、そのリレーションシップ クラスの基数を変更することはできません。したがって、リレーションシップ クラスを作成する前に、データの基数を検討して検証することが重要です。

主キーと外部キー

リレーションシップ クラスでは、関連元テーブル内のオブジェクトと関連先テーブル内のオブジェクトはそれらのキー フィールドの値を通じて対応付けられます。

属性付きでないリレーションシップ クラスでは、関連元テーブルの主キー (PK) フィールドの値が関連先テーブルの関連元の外部キー (FK) フィールドの値と直接関連している場合にリレーションシップが維持されます。 正式な主キーとは異なり、リレーションシップの主キー フィールドの値は、すべてのオブジェクトで一意である必要はありません。 外部キー フィールドには、関連元テーブルの主キー フィールドの値と一致する値が含まれています。 この場合も、キー フィールドの値がすべての行で一意である必要はありません。

たとえば、Parcel 789 が同じ Percel_ID を持つ Permits2 および 3 と一致します。

必要に応じて、属性付きリレーションシップ クラスで、多対多のリレーションシップが作成されたときなどに、中間テーブルも自動的に作成されます。 中間テーブルは、関連元の外部キー フィールドと関連先の外部キー フィールドの値を、関連するテーブルまたはフィーチャクラスの主キーにマッピングします。 各行は、1 つの関連元オブジェクトを 1 つの関連先オブジェクトに関連付けます。 キー フィールドの名前は異なっていてもかまいませんが、同じフィールド データ タイプでなければならず、Percel ID といった同じ種類の情報を含んでいなければなりません。 BLOB、日付、ラスターを除くすべてのデータ タイプのフィールドをキー フィールドとして使用することができます。

たとえば、コミュニティ内のパーセルの所有者を特定するため、Parcel フィーチャクラスと Owner スタンドアロン テーブルの間に多対多のリレーションシップ クラスが作成されます。 この多対多のリレーションシップ クラスによって、中間または属性付きテーブル ParcelToOwner が作成され、これによって 1 人以上の所有者が各パーセルに関連付けられます。

キー フィールドは、リレーションシップ クラスの作成時に指定します。

主キー フィールドを決定する方法の 1 つは、RowID フィールドを使用することです。通常、このフィールドには ObjectID という名前が付いています。 ObjectID フィールドは、フィーチャクラスまたはテーブルの作成、またはエンタープライズ ジオデータベースのレイヤーまたはテーブルの登録時に、ArcGIS によって自動的に追加されます。 このフィールドは、すべてのレコードで一意な ID を保証します。 このフィールドは ArcGIS によって管理されるため、変更することはできません。

特定のオブジェクトの ObjectID フィールドの値は、関連元クラスに存在する間は変化しません。また、オブジェクトがフィーチャである場合、ObjectID フィールドは分割されません。 フィーチャを分割すると、元のフィーチャは維持され (ただし、ジオメトリは更新される)、新しいフィーチャが作成されて新しい ObjectID が割り当てられます。 この結果、元の ObjectID をもつフィーチャのみが、その ObjectID 値に依存するリレーションシップを維持します。

このため、ObjectID フィールドを使用するよりも、独自の主キー フィールドを作成して使用するほうが適しています。 次に、これらの操作を実行する際に、独自に作成した主キー フィールドがリレーションシップの維持にどのように役立つかについて説明します。

• レコードを別のフィーチャクラスまたはテーブルにインポートすると、新しい ObjectID 値が割り当てられ、元の ObjectID 値に依存するリレーションシップは失われます。 別の主キーに基づいてリレーションシップを確立すると、レコードをインポートしても主キーの ID 値は変化しません。 これにより、一連の関連オブジェクトを新しいクラスにインポートする際に、リレーションを維持することができます。

  例外は、コピーと貼り付け機能を使用する場合です。 コピーと貼り付けでは ObjectID の値が維持されるため、この方法でのみオブジェクトを移動する予定であれば、ObjectID フィールドを主キーとして使用することができます。

• フィーチャを分割すると、関連元フィーチャは維持され (ジオメトリは更新されます)、新規フィーチャが 1 つ作成されます。 元の ObjectID に基づくリレーションシップがある場合は、分割で作成された 2 つのフィーチャのどちらかだけがそのリレーションシップを維持します。 ただし、別のフィールドをキーとして使用していた場合は、フィーチャを分割すると、元のフィーチャの ID 値が 2 つの新しいフィーチャにコピーされます。 結果として、関連先テーブルのレコードは 2 つの新しいフィーチャに関連付けられることになります。リレーションシップ クラスが多対多として設定されている場合は、理想的な状況です。

  フィーチャを分割する計画がなく、関連元クラスですべてのオブジェクトが維持される場合は、ObjectID フィールドをキーとして使用することができます。 これを保証できない場合は、ObjectID フィールドを使用するのではなく、独自に ID フィールドを作成して使用することをお勧めします。

• 2 つのフィーチャをマージすると、新しいフィーチャは元のフィーチャのどちらかの ObjectID を維持します。 フィーチャをマージする予定はあるが、フィーチャクラスからフィーチャを削除したりフィーチャを分割したりする予定はない、という場合は、ObjectID フィールドを主キーとして使用することができます。