システムアーキテクト 2017年 午前2 問21

所属と担当の表現【午前2解説】

正解の理由

• 生徒は実体テーブル（生徒ID, 氏名）であり、ここに担当委員会ID（委員会ID参照）を置いて「担当する」を表現している（生徒＝役員の情報は生徒テーブルの行で表す）。
• 所属は多対多なので「所属関連」中間テーブル（所属委員会ID（委員会ID参照）、委員ID（生徒ID参照））で表現している。
  したがって ア が正解です。

解法ステップ

1. UMLの多重度を読み取る
   • 上側（担当する）：役員側 1..* ／ 委員会側 0..1 → 多（生徒）→一（委員会）またはゼロ。
   • 下側（所属する）：委員会側 0..* ／ 役員側 1..* → 双方に「*」が含まれ、多対多。
2. 多対一（または一対多）は「多」側に外部キーを置く
   • 「担当する」は生徒（多側）に担当委員会IDを持たせる。
3. 多対多は中間テーブルを作る
   • 「所属する」は所属関連のような中間テーブルを作り、所属委員会ID（委員会IDを参照）と委員ID（生徒IDを参照）を持たせる。
4. 生徒は実体であり中間テーブル扱いにしない
   • 生徒テーブルは主キー生徒IDと氏名を持ち、担当委員会IDを外部キーとして持つ（役員ID を別途持たせる必要はない）。

選択肢別の誤答解説

• ア（正解）
  所属を中間テーブル（所属関連）で表現し、委員ID は所属関連の列で生徒ID を参照する。担当は生徒テーブルの担当委員会IDで表現しており、UMLの多重度と整合している。
• イ（誤り）
  生徒テーブルに所属委員会IDを置いているため「所属」を一対多（生徒→委員会）で表現してしまい、UMLが示す多対多を満たしていない。また「担当」を役員関連という別テーブルに分離しているが、担当は多側（生徒）に直接外部キーを置く方が簡潔であり、選択肢の分離は不必要で混乱を招く。
• ウ（誤り）
  委員会テーブルに委員IDを持たせているが、委員IDは生徒IDを参照する外部キーであって委員会側に直接持たせるのは不適切（委員会が多くの委員を持つ構造を列として持つことになり正規化違反）。また生徒に所属委員会ID・担当委員会IDを両方持たせているが、所属が多対多である点を無視している。
• エ（誤り）
  委員会テーブルに役員IDを置いているが、これは委員会側に生徒IDを格納する形になり、1つの委員会が複数の役員・委員を持つ UML の意図に反する。生徒側の多対多関係を表現できていない。

よくある誤解

• 「役員」「委員」といった役割名は別テーブルに必ずするべき：誤り。役割が追加属性を持たないなら元の実体（生徒テーブル）で役割を表現できる。役割に固有の属性があれば生徒IDを参照する役割テーブルを作る。
• 矢印の向きだけで外部キーの置き場所を決める：矢印はナビゲーションを示すが、外部キー配置の原則は多重度（特に「多」がどちらか）で判断する。
• 所属のように同じクラス間で複数の関連があるとき、全部同じ形で実装してよい：各関連の多重度によって実装方法（FKか中間か）が変わる。

補足コラム

• 役割（役員／委員）を検索・管理したい場合、役割フラグ（role カラム）やビューを用いて生徒テーブルの該当行を抽出するのが軽量。役割に付随する履歴や任期などの情報が必要ならば、役員テーブル（役員ID を主キー、生徒ID を外部キー）を別途作る。
• 中間テーブルには複合主キー（所属委員会ID＋委員ID）を設定するのが一般的で、重複登録を防げます。
• カラム命名は「対象名＋ID」で統一すると可読性が上がります（例：担当委員会ID→committee_id）。

CREATE TABLE 委員会 (
  委員会ID   INT PRIMARY KEY,
  委員会名   VARCHAR(100)
);

CREATE TABLE 生徒 (
  生徒ID         INT PRIMARY KEY,
  氏名           VARCHAR(100),
  担当委員会ID   INT NULL,
  FOREIGN KEY (担当委員会ID) REFERENCES 委員会(委員会ID)
);

CREATE TABLE 所属関連 (
  所属委員会ID   INT,
  委員ID         INT,
  PRIMARY KEY (所属委員会ID, 委員ID),
  FOREIGN KEY (所属委員会ID) REFERENCES 委員会(委員会ID),
  FOREIGN KEY (委員ID) REFERENCES 生徒(生徒ID)
);

FAQ