今回は久々のDynamics記事。
データベース設計に関わる、基本的なことだけれどもとても重要な情報です。
リレーショナルデータベースでN:Nは禁じ手
情報処理試験など受けている方はご存知かと思いますが、データベース設計において、多対多というのは推奨されていません。
多対多の事例として、よく使用されている、学生と講義の関係について考察してみましょう。
まず、学生は複数の講義を受講することができます。
そして、講義は当然1人の学生だけではなく、複数の学生が受講できるので、学生と講義は典型的な多対多の構成になります。
図にしてみましょう。
学生A〜Cと講義1~3があるとします。
学生Aさんは、講義の1と2を受講しています。
学生Bさんは、怠け癖があるため、講義を受講していません。
学生Cさんは、エリートコースの優等生なので、講義1〜3全てを受講しています。
この場合の学生と講義のリレーションはこのようになります。
受講講義を見てみましょう。
Aさんは2つ受講しているので、2つ講義を複数していしています。
Bさんは講義を受講していないので、受講講義欄は空です。
Cさんは3つ受講しているので、3つ講義を複数していしています。
このように、受講講義の枠が0の時もあれば、受講しようと思えばいくらでも増やせることになります。
エンティティの型が定まらず、これが多対多のデメリットとなります。
上記の問題を解決する手立てとして、中間テーブルが使用されます。
学生と講義の間に多対多になっているエンティティをそれぞれ1対多となるような中間テーブル受講エンティティを作成します。
受講エンティティは学生と講義を橋渡しするためのエンティティで必要なものにだけ作成されます（受講していないBさんには作成されない）。
中間テーブルを設けることにより、エンティティの型が定まるため、正規化されデータの整合性が取れるようになります。
これらを踏まえた上で、Dynamicsのリレーションについて考察することにします。
DynamicsではN:Nのリレーションが作れる
Dynamicsの世界ではN:Nのリレーションも作成ができます。
なので、N:Nを使用するときと、中間エンティティを使って1:Nを2つ作成した時の比較をしてみます。
学生と講義をN:Nで作成
N:Nでリレーションを作成します。
エンティティのN:Nの対応づけから作成が可能です。
学生側、講義側のどちらから設定してもOKです。
ただし、一部のエンティティ(部署、予定など)はN:N未対応となっています。
N:Nでもサブグリッドの表示は可能です。
N:Nにした場合、お互いのエンティティに検索フィールドを持ちません。
そのため、Excel上から関連付けができず、インポートで関連付けすることも不可能となります。
おそらく裏で中間エンティティを使っているんでしょう。
N:Nリレーションの特徴は以下の通りです。
青字がメリットと思われる点、赤字がデメリットと思われる点です。
- 直接関連エンティティが作れる
- 検索フィールドを持たないため、データインポートができない
- 一部未対応なエンティティがある
- 親子関係が明確出ないため、SharePointの階層構成ができない
学生と講義の間に中間エンティティを作成
次に学生と講義の間に中間エンティティとなる受講エンティティを作成します。
ER図的にはこう。
このように、受講エンティティにそれぞれ学生と講義エンティティを関連させます。
この場合は、受講エンティティから見ると、1つの学生、1つの講義を指定している訳ですから、それぞれの検索フィールドが存在します。
一方で、学生から講義またはその逆は直接繋がりがなくなったので、学生フォームから直接講義を表示することができません。
中間エンティティ受講を経由して、なんとなく直接繋がっている風には表示できますが、実態は中間エンティティです。
また、この場合は受講エンティティを経由しての講義の項目を表示することは可能ですが、講義エンティティ項目に対しての初期ソートができません。
（統合UIであれば、表示後のサブグリッドのソート機能でのソートは可能）
システム的にはしっくりくるんですが、データベースを知らない一般ユーザから見ると、中間エンティティという仕組みがどうも邪魔になってしまいがちではありますね。
中間エンティティを使用した場合の特徴は以下の通りです。
青字がメリットと思われる点、赤字がデメリットと思われる点です。
- 検索フィールドを持つため、データインポートが可能
- 中間エンティティを経由しないと関連エンティティが参照できない
- サブグリッドなどで、中間エンティティ経由で表示させるときにソートができない
どちらを使うのが正解か
結果、どちらを使った方がよいかは、正解はありません。
それぞれのメリット・デメリットを踏まえた上で、デメリットを受け入れられる方を使用していくことになるでしょう。
感覚としては、システム的には中間エンティティあり、ユーザ目線でいくならN:Nの方になるんでしょうね。
コメント