リレーションシップ クラスのプロパティ

このトピックは、ArcGIS for Desktop Standard および ArcGIS for Desktop Advanced にのみ該当します。

注意注意:

リレーションシップ クラスは、ArcGIS for Desktop Advanced および ArcGIS for Desktop Standard では作成と編集が可能ですが、ArcGIS for Desktop Basic では読み取り専用になります。リレーションシップ クラスに属しているフィーチャクラスも ArcGIS for Desktop Basic では読み取り専用です。

リレーションシップ クラスには、関連元のオブジェクトと関連先のオブジェクトとの関係を定義する複数のプロパティが含まれています。これらのプロパティは、リレーションシップ クラスの作成時に指定します。

リレーションシップを作成した後は、基数を制御するためのルールを指定することができます。

シンプル リレーションシップとコンポジット リレーションシップ

リレーションシップ クラスを作成する際には、シンプルとコンポジットのどちらかを指定します。

シンプル リレーションシップでは、関連オブジェクトをそれぞれ独立させることができます。たとえば、鉄道ネットワークに信号機が 1 つ以上関連付けられた踏切があるとします。ただし、踏切の存在は信号機に依存せず、踏切のない鉄道ネットワークにも信号機は存在します。

シンプル リレーションシップで関連元オブジェクトを削除すると、対応する関連先オブジェクトの外部キー フィールドの値が Null に設定されます。この外部キーの振舞いはフィーチャ間の参照整合性を維持するように設計されています。関連元フィーチャが削除されると、外部キーの値によって関連元のフィーチャと関連付けられていた行の関連性が失われ、結果として外部キーの値は不要のものとして Null に設定されます。外部キーの目的は、関連先オブジェクトと対応する関連元オブジェクトのリレーションシップを維持することだけです。対応する主キーの値を持つ関連元フィーチャがない場合は、外部キーの値を維持する必要がなくなります。後で同じ関連先フィーチャを新規または別個の関連元フィーチャに関連付ける場合は、FK フィールドを Null から新規の FK 値に更新できます。

関連先オブジェクトを削除しても、対応する関連元オブジェクトの主キーの値への影響はありません。

シンプル リレーションシップ クラス

シンプル リレーションシップの基数は、1 対 1、1 対多、または多対多のいずれかになります。

シンプル リレーションシップと同様に、コンポジット リレーションシップでもオブジェクトの削除時に参照整合性が維持されますが、その方法は異なります。コンポジット リレーションシップでは、関連先オブジェクトの存在は関連元オブジェクトに依存するため、関連元オブジェクトが削除されると、関連先オブジェクトも削除されます。このプロセスはカスケード削除と呼ばれます。

コンポジット リレーションシップで関連元オブジェクトが削除されると、関連先オブジェクトも削除される

この依存性ルールは、ArcMap の [フィーチャの整合チェック] コマンドでも適用されます。このコマンドは、編集セッションで参照整合性をテストするために実行します。関連先オブジェクトを作成したが、関連元オブジェクトに関連付いていない、という場合、[フィーチャの整合チェック] コマンドを実行するとエラーを返します。

コンポジット リレーションシップは、フィーチャの空間的な維持にも利用できます。関連元フィーチャを移動または回転すると、メッセージが正方向に設定されていれば、それに合わせて関連先オブジェクトも移動または回転します。

コンポジット リレーションシップは常に 1 対多ですが、リレーションシップ ルールにより 1 対 1 に制限することも可能です。

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

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

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

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

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

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

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

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

主キーと外部キー

リレーションシップ クラスでは、関連元オブジェクトと関連先オブジェクトはそれらのキー フィールドの値を通じて対応付けられます。次の例では、Parcel 789 が同じ Percel_ID を持つ Permits2 および 3 と一致します。

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

リレーションシップの関連元クラスのキー フィールドは主キーと呼ばれ、多くの場合は PK という略語で示されます。正式な主キーとは異なり、リレーションシップの主キー フィールドの値はすべてのオブジェクトで一意である必要はありません。

関連先クラスのキー フィールドは外部キーと呼ばれ、多くの場合は FK という略語で示されます。外部キーには、関連元クラスの主キーの値と一致する値が含まれています。この場合も、キー フィールドの値がすべての行で一意である必要はありません。

キー フィールドの名前は異なっていてもかまいませんが、同じデータ タイプでなければならず、Percel ID といった同じ種類の情報を含んでいなければなりません。BLOB、日付、ラスタを除くすべてのデータ タイプのフィールドをキー フィールドとして使用することができます。キー フィールドは、リレーションシップ クラスの作成時に指定します。

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

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

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

基数

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

リレーションシップには、3 つの基数のいずれかを指定できる

1 対 1:1 つの関連元オブジェクトを 1 つの関連先オブジェクトにのみ関連付けることができます。たとえば、土地区画の登記簿は 1 つだけです。ArcGIS では、この基数は多対 1 もカバーします。多対 1 のリレーションシップの例としては、同じ法的な説明に関連する複数の土地区画が挙げられます。

1 対多:1 つの関連元オブジェクトを複数の関連先オブジェクトに関連付けることができます。たとえば、1 つの土地区画に複数の建物を関連付けることができます。1 対多のリレーションシップでは、1 の側が関連元クラス、多の側が関連先クラスでなければなりません。

多対多:1 つの関連元オブジェクトを複数の関連先オブジェクトに関連付けることができ、逆に、1 つの関連先オブジェクトを複数の関連元オブジェクトに関連付けることができます。たとえば、1 つの土地が複数の所有者によって所有され、1 人の所有者が複数の土地を所有することがあります。

「1」と「多」は誤解されやすい用語です。1 は、実はゼロ対 1 であり、多は、実はゼロ対多です。したがって、たとえば土地区画と建物の間に 1 対多のリレーションシップを作成した場合、そのリレーションシップでは次のどの状況も有効です。

リレーションシップを作成した後は、リレーションシップのルールを設定することで、基数を制御することができます。関連先のオブジェクトへの関連付けが可能な関連元のオブジェクトの数を指定するルールを設定することができます。

リレーションシップ ルール

リレーションシップ クラスを作成する際には、1 対 1、1 対多、または多対多の基数を指定します。

リレーションシップでは、多くの場合、さらに制限を定義する必要があります。たとえば、土地区画と建物のリレーションシップでは、建物をそれぞれ 1 つの土地区画に関連付けたり、1 つの土地区画に追加できる建物の最大数を設定する必要があります。土地区画に建物を忘れずに関連付け、土地区画に関連付けられる建物の数が多くなりすぎないようにする必要があります。

サブタイプがある場合は、関連先の特定タイプのオブジェクトに関連付けることができる、関連元のオブジェクトの数およびタイプを制限することができます。たとえば、鋼鉄製の電柱はクラス A の変圧器をサポートし、木製の電柱はクラス B の変圧器をサポートすることにします。さらに、有効なサブタイプの組みごとに、有効な基数の範囲を制限する必要もあります。たとえば、鋼鉄性の電柱はクラス A の変圧器を 0 ~ 3 個までサポートでき、木製の電柱ではクラス B の変圧器を 0 ~ 2 個までサポートできることにします。

リレーションシップ クラスを作成したら、これらの参照整合性ルーツを適用するのに役立つルールを指定することができます。

  1. ArcCatalog またはカタログ ウィンドウで、既存のリレーションシップ クラスを右クリックして [リレーションシップ クラス プロパティ] ダイアログ ボックスを表示し、[ルール] タブをクリックします。
  2. 関連元クラスからサブタイプを選択し、関連先クラスの該当するサブタイプをオンにします。
  3. 関連元クラスと関連先クラスの基数のチェックボックスをオンにします。ルールの [最小] 基数と [最大] 基数を適切に設定します。このダイアログ ボックスでは、[最大] 基数よりも大きい [最小] 基数を設定することはできないので、最初に [最大] 基数を設定します。[リレーション クラス プロパティ] の [ルール] タブでルールを設定する

リレーションシップ クラスにリレーションシップ ルールを追加すると、そのルールは唯一の有効なリレーションシップとなります。他のリレーションシップおよび基数を有効にするには、さらにリレーションシップ ルールを追加する必要があります。

次の例では、HazMat を 1 ~ 2 つの Deep に関連付けることができ、2 ~ 7 つの Shallow に関連付けることができます。ただし、Sanitary を Deep に関連付けた場合、両者の間にはルールが設定されていないので、[フィーチャの整合チェック] コマンドによってリレーションシップは無効であると判断されます。

追加されたルールは、さらに他のルールを追加するまで、唯一の有効なリレーションシップとなる

ルールを設定して、編集を開始した後は、それらを ArcMap の [フィーチャの整合チェック] コマンドでテストすることができます。[フィーチャの整合チェック] コマンドは、現在選択されているフィーチャがリレーションシップ ルールに違反しているかどうかを示します。

メッセージの通知方向

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

シンプル リレーションシップとコンポジット リレーションシップのどちらを使用するかにかかわらず、操作によっては、あるフィーチャの更新に応じて、その関連フィーチャを更新しなければならないことがあります。さらに、正方向、逆方向、または両方向の更新が要求されることもあります。

関連元のオブジェクトと関連先のオブジェクトに、それらが変更されたことを互いに通知するメッセージを送信させることができる

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

そのためには、リレーションシップの作成時にメッセージの通知方向を設定します。関連元オブジェクトの更新に応じて関連先オブジェクトを更新する必要がある場合は、メッセージの通知方向を「正方向」に設定します。関連先オブジェクトの更新に応じて関連元オブジェクトを更新する必要がある場合は、メッセージの通知方向を「逆方向」に設定します。この両方の更新が必要な場合は、メッセージの通知方向を「両方向」に設定します。リレーションシップを作成したら、メッセージを受信したオブジェクトがそれに応答できるよう、この振舞いをオブジェクトにプログラムする必要があります。

唯一の例外は、コンポジット リレーションシップのメッセージングが「正方向」に設定された場合です。メッセージングが正方向のコンポジット リレーションシップを作成する場合、関連元オブジェクトを移動または回転すると、それに合わせて、関連先オブジェクトが自動的に移動または回転します。リレーションシップを正しくセットアップすれば、この機能はリレーションシップを作成した直後に有効となるため、カスタム プログラミングは必要ありません。

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

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

方向

シンプル リレーションシップ

コンポジット リレーションシップ

正方向

カスタム プログラミングを実行していなければ影響はない

  • 関連元オブジェクトの削除により関連先オブジェクトが削除される
  • 関連元オブジェクトの移動または回転により関連先オブジェクトが移動または回転する
  • カスタム プログラミングを実行していなければ、その他の影響はない

逆方向

カスタム プログラミングを実行していなければ影響はない

  • 関連元オブジェクトの削除により関連先オブジェクトが削除される
  • カスタム プログラミングを実行していなければ、その他の影響はない

両方

カスタム プログラミングを実行していなければ影響はない

  • 関連元オブジェクトの削除により関連先オブジェクトが削除される
  • 関連元オブジェクトの移動または回転により関連先オブジェクトが移動または回転する
  • カスタム プログラミングを実行していなければ、その他の影響はない

なし

メッセージの送信を回避すると、パフォーマンスがわずかに向上する

  • 関連元オブジェクトの削除により関連先オブジェクトが削除される
  • 他のメッセージの送信が阻止されるため、パフォーマンスがわずかながら向上する

メッセージ通知方向

多対多のリレーションシップ

1 対 1 および 1 対多のリレーションシップでは、関連元クラスの主キーの値は、関連先クラスの外部キーの値と直接関連しています。

これに対し、多対多のリレーションシップでは、関連付けをマッピングするために中間テーブルを使用する必要があります。結果として、多対多のリレーションシップを作成すると、中間テーブルが自動的に作成されます。中間テーブルは、関連元の主キーの値を関連先の外部キーの値にマッピングします。各行は、1 つの関連元オブジェクトを 1 つの関連先オブジェクトに関連付けます。

多対多のリレーションシップでは中間テーブルを使用する必要がある

中間テーブルが作成される際には、フィールドだけが自動的に生成されます。ArcGIS は、どの関連元オブジェクトがどの関連先オブジェクトに関連しているのかを認識しないため、ArcMap を使用して行を手動で作成する必要があります。このテーブルの設定は、リレーションシップのセットアップにおいて最も時間のかかる部分です。

リレーションシップ属性

多対多のリレーションシップの中間テーブルは、必要に応じて、もう 1 つの目的でも使用することができます。それは、リレーションシップ自体の属性を格納することです。たとえば、土地区画データベースにおいて、土地区画と所有者の間に、所有者が土地区画を所有し、土地区画が所有者に所有されるというリレーションシップを作成するとします。このリレーションシップの属性として、所有権の割合を指定することができます。このような属性を格納する必要がある場合は、リレーションシップの作成時またはその後に、中間テーブルにそれらを追加することができます。

中間テーブルにはリレーションシップ自体の属性を格納できる

それほど効果的ではありませんが、1 対 1 または 1 対多のリレーションシップをセットアップする際にも、リレーションシップの属性の格納が必要になることがあります。この場合は、リレーションシップの作成時にそれを指定して、中間テーブルが自動的に作成されるようにする必要があります。多対多のリレーションシップの場合と同様に、中間テーブルは関連元の主キーの値を関連先の外部キーの値にマッピングして、リレーションごとに任意数の属性を格納できるようにします。

中間テーブルに含まれているデータは、ArcCatalog またはカタログ ウィンドウで確認することができます。ArcMap にリレーションシップ クラスを追加すると、リレーションシップ クラスは開いて操作できるテーブルとして表示されます。ArcGIS は、他の処理に中間テーブルを公開しません。たとえば、ArcCatalog またはカタログ ウィンドウで中間テーブルのプロパティを表示してフィールドの追加や削除を行うことや、中間テーブルにデフォルト値やドメインを使用することはできません。

名前

各リレーションシップ クラスには、カタログ ツリーに表示される名前が付いています。データベース構造を理解しやすくするために、リレーションシップ クラスにはリレーションシップを説明するような名前を付けてください。

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

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

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

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

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

関連トピック

5/10/2014