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

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

注意:

リレーションシップクラスは、ArcInfo および ArcEditor では作成および編集が可能ですが、ArcView では読み取り専用です。リレーションシップクラスに属しているフィーチャクラスも ArcView では読み取り専用です。

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

タイプ: シンプルまたはコンポジット
関連元クラスと関連先クラス
主キーと外部キー
基数: シンプルリレーションシップの基数は 1 対 1、1 対多、または多対多
メッセージを通知する方向（カスケード更新または削除をカスタマイズする場合に適用）
各リレーションの属性を格納するかどうか
名前
ArcMap で関連レコードをナビゲートするときに表示される正方向ラベルと逆方向ラベル

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

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

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

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

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

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

シンプルリレーションシップの基数は、1 対 1、1 対多、または多対多です。

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

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

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

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

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

主キーと外部キー

リレーションシップクラスでは、関連元オブジェクトと関連先オブジェクトはそれらのキーフィールドの値を通じて対応付けられます。次の例では、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 フィールドを使用するよりも、独自の主キーフィールドを作成して使用するほうが適しています。次に、これらの操作を実行する際に、独自に作成した主キーフィールドがリレーションシップの維持にどのように役立つかについて説明します。

レコードを別のフィーチャクラスまたはテーブルにインポートすると、新しい ObjectID 値が割り当てられ、元の ObjectID 値に依存するリレーションシップは失われます。別の主キーに基づいてリレーションシップを確立すると、レコードをインポートしても主キーの ID 値は変化しません。これにより、一連の関連オブジェクトを新しいクラスにインポートする際に、リレーションを維持することができます。
例外は、コピーと貼り付け機能を使用する場合です。コピーと貼り付けでは ObjectID の値が維持されるため、この方法でのみオブジェクトを移動する予定であれば、ObjectID フィールドを主キーとして使用することができます。
リレーションシップクラスで ObjectID フィールドを主キーフィールドとして使用する場合にレプリケーションを行うと、同期処理中に追加の処理が必要になり、パフォーマンスに影響する可能性があります。また、場合によっては予期しない振舞いが発生する可能性もあります。レプリケーションで主キーとして ObjectID を使用する場合の詳細については、関連データのレプリケーションをご参照ください。
フィーチャを分割すると、関連元フィーチャは維持され（ジオメトリは更新されます）、新規フィーチャが 1 つ作成されます。元の ObjectID に基づくリレーションシップがある場合は、分割で作成された 2 つのフィーチャのどちらかだけがそのリレーションシップを維持します。ただし、別のフィールドをキーとして使用していた場合は、フィーチャを分割すると、元のフィーチャのID値が 2 つの新しいフィーチャにコピーされます。結果として、関連先テーブルのレコードは 2 つの新しいフィーチャに関連付けられることになります。リレーションシップクラスが多対多として設定されている場合は、理想的な状況です。
フィーチャを分割する計画がなく、関連元クラスですべてのオブジェクトが維持される場合は、ObjectID フィールドをキーとして使用することができます。これを保証できない場合は、ObjectID フィールドを使用するのではなく、独自に ID フィールドを作成して使用するのが最も効果的です。
2 つのフィーチャをマージすると、新しいフィーチャは元のフィーチャのどちらかの ObjectID を維持します。フィーチャをマージする予定はあるが、フィーチャクラスからフィーチャを削除したりフィーチャを分割したりする予定はない、という場合は、ObjectID フィールドを主キーとして使用することができます。

基数

リレーションシップの基数は、関連元クラスのオブジェクトの数と関連先クラスのオブジェクトの数を指定します。リレーションシップには、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 つの土地区画に関連付けたり、1 つの土地区画に追加できる建物の最大数を設定する必要があります。土地区画に建物を忘れずに関連付け、土地区画に関連付けられる建物の数が多くなりすぎないようにする必要があります。

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

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

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

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

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

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

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

メッセージの通知方向

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

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

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

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

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

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

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

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

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

方向	シンプルリレーションシップ	コンポジットリレーションシップ
正方向	カスタムプログラミングを実行していなければ影響はない	関連元オブジェクトの削除により関連先オブジェクトが削除される関連元オブジェクトの移動または回転により関連先オブジェクトが移動または回転するカスタムプログラミングを実行していなければ、その他の影響はない
逆方向	カスタムプログラミングを実行していなければ影響はない	関連元オブジェクトの削除により関連先オブジェクトが削除されるカスタムプログラミングを実行していなければ、その他の影響はない
両方	カスタムプログラミングを実行していなければ影響はない	関連元オブジェクトの削除により関連先オブジェクトが削除される関連元オブジェクトの移動または回転により関連先オブジェクトが移動または回転するカスタムプログラミングを実行していなければ、その他の影響はない
なし	メッセージの送信を回避すると、パフォーマンスがわずかに向上する	関連元オブジェクトの削除により関連先オブジェクトが削除される他のメッセージの送信が阻止されるため、パフォーマンスがわずかながら向上する

メッセージ通知方向

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

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

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

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

リレーションシップ属性

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

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

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

名前

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

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

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

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

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

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

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

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

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

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