1. 問題になりやすい具体例（NG例）
「学生」と「授業」の関係を考える。
学生
├ 学生ID（PK）
├ 氏名
授業
├ 授業ID（PK）
├ 授業名
学生は複数の授業を履修し、
授業には複数の学生が参加する。
👉 多対多の関係。
これをそのまま表現しようとすると、
どこに履修情報を持たせるかで悩み始める。
2. なぜこの設計が成り立たないのか
•学生側に授業IDを持たせる → 複数持てない
•授業側に学生IDを持たせる → 同じ問題
•配列・カンマ区切り → 正規化違反
さらに、
•履修日
•成績
•出欠状況
といった関係に付随する情報を
格納する場所がなくなる
3. 考え方の整理
多対多の関係は、
「関係そのものが1つの実体」
として扱う。
4. 理想の具体例（改善後）
実体テーブル
学生
├ 学生ID（PK）
├ 氏名
授業
├ 授業ID（PK）
├ 授業名
中間テーブル（関係の実体）
履修
├ 履修ID（PK）
├ 学生ID（FK）
├ 授業ID（FK）
├ 履修日
├ 成績
✔ 学生 × 授業 の関係を1レコードで表現
✔ 関係に属性を持たせられる
✔ 拡張に強い
5. デスぺ視点でのポイント
午後Ⅱでは、
•多対多を正しく分解できるか
•中間テーブルに何の属性を持たせるか
が頻出。
「中間テーブル＝ただのつなぎ」
と考えると設計を誤りやすい。
まとめ
・多対多はそのまま表現できない
・中間テーブルは「関係の実体」
・関係に属性があるかを必ず考える
一言メモ
「この関係に情報はぶら下がらないか？」を自問する。