［DB設計］多対多の問題点とは

現在あるシステムを作成する上で、DB設計をしています。
このDB設計をする上で、多対多の状態だと良くない（できない？）とよく聞きます。

例）一人の学生は複数の講義を受講し、一つの講義には複数の学生が受講する。
この時に、学生の情報を格納する「学生DB（主キー：学生番号）」と、講義の情報を格納する「講義DB（主キー：講義番号）」を作成します。そうするとこの二つのDBの関係って、多対多になってしまうと思うのですが、この場合どのような問題が起きますか？

例がちょっとわかりにくいかもしれませが、要は
「DBを多対多の状態で設計した場合の問題点は何か？」
ということをお聞きしたいです。

よろしくお願いします。

No.5 回答者： mitoneko 回答日時： 2008/02/03 22:42

　これ、聞いて理解できなければ、自分で困ってみるのが一番です。

　例に挙げておかれる問題は、たぶん、多対多のテーブルを直接作って構成すると、すぐにとっても困ることができるので、この場合良い事例です。

　実験をするに当たって、考慮すべき点をいくつか上げておきます。
・テーブルの設計に当たっては、現実世界の条件を満たすように構成すること。（テーブルを作っていて、「フィールドが多くなりすぎたから、講義の種類は＊＊個しかないことにしようか」とかテーブル設計の都合で現実世界に条件を設けてはいけません。）
・現実の世界を見て、変更されそうなポイントは、容易にその変更をデータベースに反映できること。（講義の種類数が増えたから、テーブルの構成を修正するなんて言うのは、もう最悪です。これはこれで、ひとつの「困った」ですが、テーブル定義を修正すると、その後でアプリケーションを全部修正する必要があることを頭に入れておきましょう。）
・データの登録は容易にできるか、考えましょう。データを登録するために、いくつのテーブルを調査する必要があるか？ひとつのデータを登録するために、いくつのテーブルを連動して操作する必要があるか。などが考慮ポイントです。
　この際に、現実世界にあり得ないデータを登録「できない」ようになっているかも重要なポイントです。（アプリケーションでやる仕事に見えますが、これをデータベースレベルではじけるように設計するのはとても大切なことです。アプリケーションはいくつもできる可能性がありますが、データベースはひとつですから、どちらでチェックした方が確実かは自明ですね。）
・データの修正を行うときに、どれだけのテーブルとデータが関係してくるかを考えること。削除・修正の両方です。チェックポイントは挿入の時と同じです。変な操作をしたときに、データの整合性が崩れないように注意すること。あっちを修正してこっちを修正し忘れたら何が起こるかを考慮しておくのはとても重要です。へたをすると、使い物にならないデータとなり修正さえ不可能な事態に追い込まれかねないものです。

　ちなみに、最後の２点は、関係するテーブルは、できるだけ少なく構成することが吉です。多くなればなるほど、あらゆる点が複雑になっていきます。テーブルの数を少し増やすだけで操作に関わるテーブル数が減るなら、テーブルの数は増やすべきです。これをテーブル数をシンプルにしようと間違った方向に進むと先の考慮点の、登録・修正の際のデータの整合性を保証する段階で、頓挫することになります。

　この条件をクリアした時点で、データベースの設計をもう一度見てみると、たぶん、テーブルが直接多対多の関係でリレーションされていることはないでしょう。

　あえて、何故困るかは書きません。
　参考に言っておくなら、こうしたときに困らないようにデータベース理論つくられ、正規化というテクニックが生まれたのです。

この回答へのお礼

回答ありがとうございます。

お礼日時：2008/02/03 22:56

No.4 回答者： Hayashi_Trek 回答日時： 2008/02/03 13:34

>「なぜ作らなければならないのか？」ということがわかりません。

逆に、この中間テーブルを使わない方法を考えると
学生テーブルの方に、講義1，講義2，講義3，・・・と受講する講義のフィールド
講義テーブルの方に、学生1，学生2，学生3，・・・と受講する学生のフィールド
といった構造が考えられますが
講義のフィールド、学生のフィールドともに最大可能な数を用意する必要が有ります。
（受講する講義が少なくても、また受講する学生が少なくても常に用意する）
講義や学生の数が非常に少ないのであればこのような構造も考えられますが
数が多い場合、使われないフィールドが多く発生するために、
データベースのデータ格納効率が悪くなってしまいます。
また、受講する学生や講義をリストアップする場合も処理が複雑になります。
（フィールドが使われているかどうかの判断が必要になるので）

この回答へのお礼

回答ありがとうございます。

お礼日時：2008/02/03 22:57

No.3 回答者： CHRONOS_0 回答日時： 2008/02/03 13:10

>「なぜ作らなければならないのか？」ということがわかりません。

直接は関係付けられないからということでは駄目なの？

>多対多の関係でDBを設計しても特に問題はないということでしょうか？
考える方向が逆なのでは
RDBでは現実世界の事象をテーブルという形で表現します
現実世界に多対多の関係のものがあるのですから
それを扱うDBには多対多の関係のテーブルができて当然なのでは

それとも中間テーブルというのが納得できないのかな
代表的なDBに販売というものがありますが
このケースでは顧客と商品は多対多の関係になります
従って販売テーブルが中間テーブルになります

この場合一般的には販売テーブルがメインで商品と顧客は参照先
と考え販売が中間テーブルという風には考えませんが
視点を変えればまぎれもなく中間テーブルです

この回答へのお礼

回答ありがとうございます。

お礼日時：2008/02/03 22:58

No.2 回答者： CHRONOS_0 回答日時： 2008/02/03 00:55

>多対多の状態だと良くない（できない？）とよく聞きます。

どこで聞いたのか分かりませんが聞き間違いかガセです

世の中には多対多の関係になるものはいっぱい存在します

多対多の関係の場合直接は関係付けられませんから
中間テーブルを介して関係付けます

学生と講義なら

[受講テーブル]（学生番号、講義番号)

というテーブルが中間テーブルになります
受講テーブルと学生が一対多
受講テーブルと講義が一対多になります

この場合のユーザーインタフェースは
講義テーブルから作った単票フォームに受講テーブルをサブフォームとしてはめ込む
ものと
学生テーブルから作った単票フォームに受講テーブルをサブとしてはめ込む
を作ればいいというのも定石ですね

この回答へのお礼

回答ありがとうございます。

受講テーブルを作れば、多対多にならないというのはわかっています。
ただ「なぜ作らなければならないのか？」ということがわかりません。

それとも回答者様は、冒頭でおっしゃっているように、多対多の関係でDBを設計しても特に問題はないということでしょうか？

お礼日時：2008/02/03 01:27

No.1 回答者： okg00 回答日時： 2008/02/03 00:00

http://gihyo.jp/dev/feature/01/database/0003

リレーショナルモデルにおいては実装がややこしくなるから。

この回答へのお礼

早速の回答ありがとうございます。

実装がややこしくなるというのはよく聞くのですが、
なぜややこしくなるのかが知りたいです。

お礼日時：2008/02/03 01:12