Microsoft Dataverse のテーブル リレーションシップは、テーブル行を他のテーブルまたは同じテーブルの行に関連付ける方法を定義します。 テーブル リレーションシップには、次の 2 種類があります。
一対多関連付け
一対多テーブル リレーションシップでは、参照元 (関連) テーブル行の多くを 1 つの参照先 (プライマリ) テーブル行に関連付けることができます。 参照先のテーブル行は "親" と呼ばれ、参照元テーブルの行は "子" と呼ばれることもあります。 多対 1 の関連付けは、1 対多の関連付けの下位観点です。
たとえば、学校のシナリオでは、複数のコースが 1 つの教室で提供される可能性があるため、クラス テーブルはコース テーブルと一対多リレーションシップになります。
多対多のリレーションシップ
多対多テーブル リレーションシップでは、多くのテーブル行を他の多くのテーブル行に関連付けることができます。 多対多リレーションシップで関連付けられた行は、相互に同等の立場にあると見なされます。
たとえば、前述の同じ学校シナリオでは、1 人の学生が複数のコースに登録でき、各コースに複数の学生を含めることができます。 この種類のリレーションシップにより、より複雑なデータの関連付けが可能になり、Dataverse の Power Apps を使用して管理されます。
Dataverse でのリレーションシップのしくみ
テーブル リレーションシップは、Dataverse でテーブル行を相互に関連付ける方法を定義します。 最も簡単なレベルでは、テーブルにルックアップ列を追加すると、2 つのテーブル間に新しい 1:N (一対多) リレーションシップが作成され、その参照列をフォームに配置できます。 ルックアップ列を使用すると、ユーザーはそのテーブルの複数の 子 行を 1 つの 親 テーブル行に関連付けることができます。
単に行を他の行と関連付ける方法を定義するだけでなく、1:N テーブル リレーションシップでは、次の質問に対処するためのデータも提供されます。
- 行を削除する場合、その行に関連する行も削除する必要がありますか?
- 行を割り当てるときに、その行に関連するすべての行を新しい所有者に割り当てる必要はありますか?
- 既存の行のコンテキストで新しい関連行を作成するときに、データ入力プロセスを効率化するにはどうすればよいですか?
- 行を表示しているユーザーは、関連付けられている行を表示するにはどうすればよいですか?
テーブルは N:N (多対多) リレーションシップに参加することもできます。このリレーションシップでは、2 つのテーブルの任意の数の行を相互に関連付けることができます。
テーブル リレーションシップと接続のどちらを使用するかを決定する
テーブル リレーションシップは、Dataverse で変更を加えるメタデータです。 これらのリレーションシップを使用すると、クエリで関連データを効率的に取得できます。 テーブルリレーションシップを使用して、テーブルを定義する正式なリレーションシップ、またはほとんどの行で使用できる正式なリレーションシップを定義します。 たとえば、潜在顧客がいない機会は役に立ちません。 Dynamics 365 for Sales の営業案件テーブルには、競合他社テーブルとの N:N リレーションシップもあります。Dynamics 365 for Sales でも使用できます。 これにより、複数の競合他社を機会に追加できます。 このデータをキャプチャし、競合他社を示すレポートを作成できます。
行の間には、接続と呼ばれる他の、より形式ばらない種類のリレーションシップがあります。 たとえば、2 人の連絡先が結婚しているか、仕事外の友人なのか、別のアカウントで働いていた連絡先なのかを知ると便利な場合があります。 ほとんどの企業では、この種の情報を使用してレポートを生成したり、入力する必要がないため、テーブルリレーションシップを作成する価値はありません。 詳細: 接続ロールの構成
テーブル リレーションシップの種類
Power Apps でリレーションシップを表示すると、3 種類のテーブル リレーションシップがあると思われる場合があります。 実際には、次の表に示すように、2 つしかありません。
| リレーションシップの種類 | Description |
|---|---|
| 1:N (一対多) | プライマリ テーブルの 1 つのテーブル行を、関連 テーブル のルックアップ列のために他の多くの 関連テーブル 行に関連付けることができるテーブル リレーションシップ。 プライマリ テーブル行を表示すると、関連付けられている関連するテーブル行の一覧が表示されます。 Power Apps ポータルでは、 現在のテーブル はプライマリ テーブルを表します。 |
| N:N (多対多) | 特殊な リレーションシップ テーブルに依存するテーブル リレーションシップ (Intersect テーブルとも呼ばれます) により、1 つのテーブルの多数の行を別のテーブルの多数の行に関連付けることができます。 N:N リレーションシップでいずれかのテーブルの行を表示すると、そのテーブルに関連する他のテーブルの行の一覧が表示されます。 |
ユーザーインターフェイスにN:1 (多対1)リレーションシップの種類が存在するのは、デザイナーがテーブルでグループ化されたビューを表示しているためです。 1:N 個のリレーションシップは、実際にはテーブル 間 に存在し、各テーブルを プライマリ/現在のテーブル または 関連テーブルとして参照します。 関連するテーブル ( 子 テーブルとも呼ばれます) には、プライマリ テーブル ( 親 テーブルとも呼ばれる) の行への参照を格納できる参照列があります。 N:1 リレーションシップは、関連テーブルから見た 1:N のリレーションシップにすぎません。
テーブル リレーションシップの動作
関連テーブルの動作は、データの整合性を確保するのに役立ち、ビジネス プロセスを自動化できるため重要です。
データ整合性の維持
一部のテーブルは、他のテーブルをサポートするために存在します。 彼らは自分で意味をなさない。 通常、サポートされているプライマリ テーブルにリンクするために必要な参照列があります。 プライマリ行が削除されるとどうなるでしょうか。
リレーションシップの動作を使用して、ビジネスのルールに従って関連する行に対する動作を定義できます。 詳細情報: 高度なリレーションシップの動作を追加する
ビジネス プロセスを自動化する
たとえば、新しい営業担当者がいて、別の営業担当者に現在割り当てられている既存のアカウントを割り当てるとします。 各アカウント行には、多数のタスク アクティビティが関連付けられている場合があります。 再割り当てするアクティブなアカウントを簡単に見つけて、新しい営業担当者に割り当てることができます。 しかし、アカウントに関連付けられているタスク アクティビティに対して何を行う必要がありますか? 各タスクを開き、新しい営業担当者に割り当てるかどうかを一つずつ考慮したいですか。 したくないでしょう。 その代わり、関連付けが標準規則を自動的に適用するようにできます。 これらのルールは、再割り当てするアカウントに関連付けられているタスク行にのみ適用されます。 オプションは次のとおりです。
- すべてのタスク活動を再割り当てします。
- すべてのタスクを再割り当てします。
- タスクを全く再割り当てしません。
- アカウントの以前の所有者に現在割り当てられているすべてのタスクを再割り当てします。
リレーションシップでは、プライマリ テーブル行の行に対して実行されるアクションを、関連するテーブル行にカスケードダウンする方法を制御できます。
Behaviors
特定のアクションが発生したときに適用できる動作には、いくつかの種類があります。
| 行動 | Description |
|---|---|
| アクティブなカスケード | アクティブなすべての関連テーブル行に対してアクションを実行します。 |
| すべてカスケード | 関連するすべてのテーブル行に対してアクションを実行します。 |
| カスケードなし | 何もしません。 |
| リンクの解除 | 関連するすべての行の参照値を削除します。 |
| 制限 | 関連するテーブル行が存在する場合に、プライマリ テーブル行が削除されないようにします。 |
| カスケードユーザー所有 | プライマリ テーブル行と同じユーザーが所有するすべての関連テーブル行に対してアクションを実行します。 |
アクション
特定の動作をトリガーできるアクションを次に示します。
| コラム | Description | オプション |
|---|---|---|
| 割り当て | プライマリ テーブルの行が他のユーザーに割り当てられている場合はどうなるでしょうか。 | すべてにカスケード アクティブにカスケード ユーザーが管理するカスケード カスケードなし |
| リペアレント | 親リレーションシップの関連テーブルの参照値が変更された場合はどうなりますか? 詳細情報: 親子テーブルの関係 |
すべてにカスケード アクティブにカスケード ユーザー所有のカスケード カスケードなし |
| 共有 | プライマリ テーブルの行が共有されている場合はどうなるでしょうか。 | すべてにカスケード アクティブにカスケード ユーザーによって所有されるカスケード カスケードなし |
| 削除 | プライマリ テーブルの行が削除されるとどうなるでしょうか。 | すべてにカスケード 記事のリンク解除 制限 |
| 共有の解除 | プライマリ テーブルの行が共有されていない場合はどうなるでしょうか。 | すべてにカスケード アクティブにカスケード ユーザー所有のカスケード カスケードなし |
| [マージ] | プライマリ テーブルの行をマージするとどうなるでしょうか。 | すべてにカスケード カスケードなし |
| ロールアップ ビュー | このリレーションシップに関連付けられているロールアップ ビューの望ましい動作は何ですか? | すべてにカスケード アクティブにカスケード カスケードがユーザーの所有になっている場合 カスケードなし |
注
次の状況では、割り当て、削除、マージ、リペアレントのアクションは実行されません:
- 元の親行と要求されたアクションに同じ値が含まれている場合。 例: 割り当てのトリガーを試行し、すでに行の所有者である連絡先を選択した場合。
- すでにカスケード アクションを実行している親行に対してアクションを実行しようとした場合。
割り当てを実行すると、行で現在アクティブになっているワークフローまたはビジネス ルールは、再割り当てが行われると自動的に非アクティブ化されます。 行の新しい所有者は、ワークフローまたはビジネス ルールを引き続き使用する場合に再アクティブ化する必要があります。
テーブルの上位下位の関連付け
1:N リレーションシップを持つ対象となるテーブルの各ペアは、それらの間に複数の 1:N リレーションシップを持つことができます。 ただし、通常、親テーブルリレーションシップと見なすことができるリレーションシップは 1 つだけです。
親テーブル リレーションシップは、次のテーブルの Parental 列のカスケード オプションの 1 つが true である任意の 1:N テーブル リレーションシップです。
| 目的 | 上位下位である | 上位下位ではない |
|---|---|---|
| 割り当て | すべてにカスケード ユーザー所有のカスケード アクティブにカスケード |
カスケードなし |
| 削除 | すべてにカスケード | RemoveLink 制限 |
| リペアレント | すべてにカスケード カスケードのユーザー所有 アクティブにカスケード |
カスケードなし |
| 共有 | すべてにカスケード ユーザー所有のカスケード アクティブにカスケード |
カスケードなし |
| 共有の解除 | すべてにカスケード カスケードのユーザー所有 アクティブにカスケード |
カスケードなし |
たとえば、新しいカスタム テーブルを作成し、カスタム テーブルが関連テーブルである取引先企業テーブルに 1:N テーブル リレーションシップを追加した場合、そのテーブル リレーションシップのアクションを[ 保護者 ]列のオプションを使用するように構成できます。 後でカスタム テーブルと別の 1:N テーブル リレーションシップを参照テーブルとして追加する場合は、[ 保護者以外 ] 列のオプションを使用するようにアクションのみを構成できます。
通常、これは各テーブル ペアには上位下位の関連付けが 1 つだけ存在することを意味します。 関連テーブルを参照すると、複数の種類のテーブルとのリレーションシップが許可される場合があります。
たとえば、テーブルに顧客参照があり、連絡先テーブルまたは取引先企業テーブルを参照できる場合です。 2 つの異なる上位下位の 1:N テーブルの関連付けが存在します。
アクティビティ テーブルには、関連ルックアップ列を使用して関連付けることができるテーブルに対し、同様の親テーブルのリレーションシップセットがあります。
設定できる動作の制限
親リレーションシップにはいくつかの制限があるため、テーブル リレーションシップを定義するときは注意する必要があります。
- カスタム テーブルを、連鎖する関連システム テーブルとのリレーションシップのプライマリ テーブルにすることはできません。 つまり、プライマリ カスタム テーブルと関連システム テーブルの間に、 Cascade All、 Cascade Active、または Cascade User Owned に設定されたアクションとのリレーションシップを持つ必要はありません。
- リレーションシップ内の関連テーブルが、Cascade All、 Cascade Active、または Cascade User-Owned に設定されている別のリレーションシップ内の関連テーブルとして既に存在し、そのアクションが Cascade All、Cascade Active、または Cascade User Owned に設定されている場合、新しいリレーションシップでアクションを Cascade All、 Cascade Active、または Cascade User Owned に設定することはできません。 これにより、複数の親関連付けを持つ関連付けの作成を防ぎます。
継承されたアクセス権のクリーンアップ
リペアレントおよび共有カスケード動作を使用すると、関連テーブル間の行へのアクセスを提供する場合に役立ちます。 ただし、連鎖動作の設定を変更する必要があるプロセスまたは設計に変更が加えられる可能性があります。
テーブル リレーションシップで Reparent または Share を使用し、カスケード動作が Cascade None に変更されると、テーブル リレーションシップによって新しい権限の変更が関連する子テーブルにカスケードされなくなります。 さらに、カスケード動作がアクティブな間に付与された継承されたアクセス許可を取り消す必要があります。
継承されたアクセス権のクリーンアップは、カスケード動作が Cascade None に変更された後に残る、レガシの継承されたアクセス権をクリーンアップするシステム ジョブです。 このクリーンアップは、テーブルへのアクセスを直接許可されたユーザーには影響しませんが、継承によってのみアクセスを受け取ったユーザーからのアクセスは削除されます。
継承されたアクセス権のクリーンアップのしくみを次に示します。
- 更新された親との連鎖リレーションシップにあったすべてのテーブルを識別して収集します。
- 継承されたアクセスを通じて関連テーブルへのアクセスが許可されたユーザーを識別して収集します。
- 関連するテーブルに直接アクセスできるユーザーを確認し、コレクションから削除します。
- 収集されたテーブルで収集されたユーザーの継承されたアクセス権を削除します。
クリーンアップの実行後、カスケード機能によってのみ関連テーブルにアクセスできたユーザーは行にアクセスできなくなり、セキュリティが強化されます。 クリーンアップが成功しない場合があります。 継承されたアクセスをクリーンアップする方法の詳細
こちらも参照ください
システム ジョブの監視
1:N (一対多) または N:1 (多対一) の関連付けを作成および編集する
多対多 (N:N) テーブル リレーションシップを作成する