Microsoft Dataverse テーブルのリレーションシップ

Microsoft Dataverse のテーブル リレーションシップは、テーブル行を他のテーブルまたは同じテーブルの行に関連付ける方法を定義します。 テーブル リレーションシップには、次の 2 種類があります。

• 一対多リレーションシップ
• 多対多リレーションシップ

一対多関連付け

一対多テーブル リレーションシップでは、参照元 (関連) テーブル行の多くを 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 つしかありません。

ユーザーインターフェイスにN:1 (多対1)リレーションシップの種類が存在するのは、デザイナーがテーブルでグループ化されたビューを表示しているためです。 1:N 個のリレーションシップは、実際にはテーブル 間 に存在し、各テーブルを プライマリ/現在のテーブル または 関連テーブルとして参照します。 関連するテーブル ( 子 テーブルとも呼ばれます) には、プライマリ テーブル ( 親 テーブルとも呼ばれる) の行への参照を格納できる参照列があります。 N:1 リレーションシップは、関連テーブルから見た 1:N のリレーションシップにすぎません。

テーブル リレーションシップの動作

関連テーブルの動作は、データの整合性を確保するのに役立ち、ビジネス プロセスを自動化できるため重要です。

データの整合性を維持する

一部のテーブルは、他のテーブルをサポートするために存在します。 彼らは自分で意味をなさない。 通常、サポートされているプライマリ テーブルにリンクするために必要な参照列があります。 プライマリ行が削除されるとどうなるでしょうか。

リレーションシップの動作を使用して、ビジネスのルールに従って関連する行に対する動作を定義できます。 詳細情報: 高度なリレーションシップの動作を追加する

ビジネス プロセスを自動化する

たとえば、新しい営業担当者がいて、別の営業担当者に現在割り当てられている既存のアカウントを割り当てるとします。 各アカウント行には、多数のタスク アクティビティが関連付けられている場合があります。 再割り当てするアクティブなアカウントを簡単に見つけて、新しい営業担当者に割り当てることができます。 しかし、アカウントに関連付けられているタスク アクティビティに対して何を行う必要がありますか? 各タスクを開き、新しい営業担当者にも割り当てる必要があるかどうかを決定しますか? 答えはおそらく「いいえ」でしょう。 代わりに、リレーションシップに一部の標準ルールを自動的に適用させることができます。 これらのルールは、再割り当てするアカウントに関連付けられているタスク行にのみ適用されます。 オプションは次のとおりです。

• アクティブなすべてのタスクを再割り当てします。
• すべてのタスクを再割り当てします。
• タスクを再割り当てしません。
• アカウントの以前の所有者に現在割り当てられているすべてのタスクを再割り当てします。

リレーションシップでは、プライマリ テーブル行の行に対して実行されるアクションを、関連するテーブル行にカスケードダウンする方法を制御できます。

Behaviors

特定のアクションが発生したときに適用できる動作には、いくつかの種類があります。

アクション

特定の動作をトリガーできるアクションを次に示します。

親テーブルのリレーションシップ

1:N リレーションシップを持つ対象となるテーブルの各ペアは、それらの間に複数の 1:N リレーションシップを持つことができます。 ただし、通常、親テーブルリレーションシップと見なすことができるリレーションシップは 1 つだけです。

親テーブル リレーションシップは、次のテーブルの Parental 列のカスケード オプションの 1 つが true である任意の 1:N テーブル リレーションシップです。

たとえば、新しいカスタム テーブルを作成し、カスタム テーブルが関連テーブルである取引先企業テーブルに 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. 更新された親との連鎖リレーションシップにあったすべてのテーブルを識別して収集します。
2. 継承されたアクセスを通じて関連テーブルへのアクセスが許可されたユーザーを識別して収集します。
3. 関連するテーブルに直接アクセスできるユーザーを確認し、コレクションから削除します。
4. 収集されたテーブルで収集されたユーザーの継承されたアクセス権を削除します。

クリーンアップの実行後、カスケード機能によってのみ関連テーブルにアクセスできたユーザーは行にアクセスできなくなり、セキュリティが強化されます。 クリーンアップが成功しない場合があります。 継承されたアクセスをクリーンアップする方法の詳細

こちらも参照ください

システム ジョブの監視
1:N (一対多) または N:1 (多対一) の関連付けを作成および編集する
多対多 (N:N) テーブル リレーションシップを作成する