今回のテーマはリレーション。
データ間の繋がりを表現するためにエンティティ間にリレーションを構築します。
リレーションの種類を知る
作成の前に、まずはリレーションの種類について理解しておきましょう。
ここの知識がないと、見えるところが見えなかったり、親を削除した時に意図せず子レコードが削除されたりと、誤設定で致命的なアクションになりかねないので、絶対におさえておきましょう。
SFDCのリレーション
Salesforceのリレーションは2種類あります。
主従関係と参照関係です。
主従は参照よりも繋がりが強く、参照関係にはない、以下の特徴があります。
- 親レコードを削除すると子レコードも削除される
- 親レコードの参照・編集権限は子レコードにそのまま引き継がれる
- 積み上げ集計が使用できる
- 1オブジェクトにつき、最大2つの主従関係が作成できる（主の親は最大2つまで持てる）
ここは、認定デベロッパー試験の最重要事項となりますので、絶対覚えておきましょう。
D365のリレーション
Dynamicsのリレーション自体は1種類（検索フィールド）のみとなります。
ただ、1種類と言えどもその中で、繋がりの強さを設定する事ができ、その設定の事を伝播設定と呼びます。
設定の組み合わせでは、Salesforceの主従と参照の中間に位置するような設定も可能であり、事実上数百種類あるとも言えます。
伝播設定の具体的な内容はここでは触れませんが、主な設定はテンプレート化されており、細かい決まりがなければ、動作の種類から選択する事になります。
動作の種類で選択できるのは以下の4つ。
上位下位
権限が親レコードから引き継がれ、親レコードの削除で子レコードも削除されます。
Salesforceの主従関係と同等の設定と考えて構いません。
参照
こちらは繋がりが弱く、権限の引き継ぎ、および親レコードの削除時の子レコードは行われません。
Salesforceの参照関係と同等の設定です。
参照、削除権限
Salesforceの参照関係で参照レコードが削除された場合の対処方法を「参照関係に含まれる参照レコードは削除できません。」にした時と同じような設定になります。
構成可能な伝播
伝播ルールを独自で設定できます。
主従と参照の中間の強度にしたい場合はこちらを選択し自身で設定します。
実際に設定してみる
リレーションについての知識を得たところで、システム構築に戻ります。
まず、球団-所属選手は既存のリレーションがあるため、そのまま使用します。
主従関係、上位下位のリレーションになります。
一方の、球団-スタジアムは自分でリレーションを作り必要があります。
今回は、球団は1つのフランチャイズをもつというルールとし、球団側からスタジアムのエンティティを参照する事になります。
そのため、球団エンティティに検索フィールド（参照項目）をもつ事になり、球団とスタジアムはN:1の関係になります。
実際は1:1なので、エンティティを一緒にするのもアリなんですが、後々のために分ける事にします。
ダブルフランチャイズ制の考慮はしていません。
余談ですが、オリックスも2008年には京セラドームに一本化してたんですね。
強度については、スタジアムレコードが消えても球団が消える訳ではないので、ここでは強度の弱い参照設定とする事にします。
Salesforce側で参照項目を作る
球団側から参照項目を作成します。
[設定]→[カスタマイズ]→[取引先]→[項目]からカスタム項目の新規で、以下情報を入力します。
| 項目 | 設定値 |
|---|---|
| データ型 | 参照関係 |
| 項目の表示ラベル | フランチャイズ |
| 項目名 | Franchise |
| 子リレーション名 | accounts |
| 参照レコードが削除された場合の対処方法 | この項目の値をクリアします… |
Dynamicsのリレーション作成
ソリューションの球団エンティティからN:1の関連付けを選択して、新しい多対一の関連付けを押下します。
スタジアムから見れば、1:Nなのでスタジアムエンティティの1:Nの関連付けから選択してもOKです。
| 項目 | 設定値 |
|---|---|
| 主エンティティ | スタジアム |
| 関連エンティティ | 球団 |
| 表示名 | フランチャイズ |
| 子リレーション名 | franchise |
| フィールド要件 | 任意項目 |
これでエンティティ間に関連を持たせる事ができるようになりました。
次回はエンティティの項目設定に入ります。
追加情報：DynamicsはN:Nもある
リレーションをはる時は、エンティティ間が1:Nとなるケースとなる時に検索フィールドを作るんですが、DynamicsにはN:Nというリレーションもあります。
リレーショナルデータベースを勉強した方は、「多対多となるリレーションはダメよ！」と教わってきたと思います。
その場合は、中間エンティティを挟んで1対多を2つ作る事が王道なんですが、DynamicsではN:Nのリレーションを作る事によって、その手間は不要となります。
ただし、いくつか注意点を。
1:Nの場合は、N側に検索フィールドの項目が作成されますが、N:Nの場合は検索フィールドが作成されません。
多分、裏側で中間エンティティを作成しているんでしょう。
そのため、ビューなどから参照先を表示できません。
参照先はフォーム内でのみの表示となります。
1:Nの場合は1側が親、N側が子といった親子関係が成立しますが、N:Nの場合はどちらが親なのかが判断しようがありません。
そのため、伝播の設定についても一切ありません。
まとめ
- SFDCの主従・参照関係はD365の関連付けの動作の種類で置き換え可能
- D365は伝播設定により、より細かなルール付けが可能
- D365はN:Nのリレーションも設置可能
コメント