応用情報技術者 2012年 秋期 午前2 問27

中間表による多対多実装【午前2解説】

正解の理由

解法ステップ

1. 図を解釈する：ひし形「口座」が銀行と顧客を結ぶ関係であり、両側に複数性（m, n）が示されていることを確認する。
2. 多対多の判定：両側に「複数」を許す指定があるなら、銀行—顧客は多対多の関係であると判断する。
3. 関係から表設計へ：多対多は中間となる関係表（ここでは「口座」表）で解消し、その表に両側エンティティを参照する外部キーを持たせる。
4. 選択肢を検証：外部キーの所在と多対多／1対多の表現が選択肢と一致するかを照合する。

選択肢別の誤答解説

• ア: “銀行”表から “口座” 表への対応関係は多対1である。
  誤り。正しくは「銀行→口座は1対多（1つの銀行に複数の口座）」です。表記の向き（どちらが親か）を混同すると自己矛盾が生じます。
• イ: “銀行” 表中に参照制約を課した外部キーがある。
  誤り。参照制約を課す外部キーは「口座」表の側に置かれます。銀行表は通常は主キー（銀行ID）を持ち、他表から参照される側です。
• ウ: “口座”表から “顧客” 表への対応関係は1対多である。
  誤り。口座→顧客は多対1が通常の読み方（各口座は1人の顧客に属する想定）であり、顧客→口座が1対多（顧客は複数口座を持つ）。選択肢の向きが逆になっています。
• エ: “口座”表には二つ以上の外部キーがある。
  正しい。口座表は銀行と顧客の双方を参照する外部キー（例: bank_id, customer_id）を持ち、これにより多対多関係が実装されます。

よくある誤解

• 「多対1」と「1対多」を混同する：図中の記述はどちらの方向に対しての多さかを明確に読む必要があります。例えば「銀行→口座は1対多、口座→銀行は多対1」と読み替えます。
• 外部キーは必ず親側に置くと思い込む：外部キーは参照される側（親）ではなく、参照する側（子）に置きます。多対多では中間表が子となり両側を参照します。
• 口座を属性扱いする誤り：連関（口座）が属性ではなく、銀行と顧客をつなぐ独立したエンティティ（アソシエイティブエンティティ）として設計する必要があります。

補足コラム

• 口座表の主キー設計：口座IDのようなサロゲートキーを採るか、(bank_id, customer_id, 口座番号) のような複合キーにするかは要件次第です。複数の口座を同一顧客と銀行の組合せで扱うならサロゲートキーを使う方が柔軟です。
• ジョイントアカウント（共同名義）を扱う場合：口座に複数の顧客が紐づくなら、口座と顧客の間も多対多になり、さらに別の中間表（口座保有者表 account_holders）を設ける設計が必要です。
• 参照制約（外部キー制約）はデータ整合性の要です。削除・更新時のカスケードや制約違反をどう扱うかは業務ルールで決めます。

CREATE TABLE bank (
  bank_id   SERIAL PRIMARY KEY,
  name      VARCHAR(100) NOT NULL
);

CREATE TABLE customer (
  customer_id SERIAL PRIMARY KEY,
  name        VARCHAR(100) NOT NULL
);

CREATE TABLE account (
  account_id  SERIAL PRIMARY KEY,
  bank_id     INTEGER NOT NULL REFERENCES bank(bank_id),
  customer_id INTEGER NOT NULL REFERENCES customer(customer_id),
  account_no  VARCHAR(32) NOT NULL,
  balance     DECIMAL(15,2) DEFAULT 0
  -- 必要に応じて UNIQUE (bank_id, account_no) などを追加
);

FAQ