データベーススペシャリスト 2012年 午前2 問03

自己参照関連の実装【午前2解説】

正解の理由

• 品目は抽象クラスであり、組立品／部品は同種の実体（同一識別子で扱う）の概念であるため、単一の品目テーブル（品目番号、品目名）に型識別子（型区分）を持たせるのが合理的です。これにより親（組立品）と子（部品）が同じ品目テーブルを参照できます。
• 関連クラス「部品数」は関連そのものに属性（数）を持つため独立のテーブルとし、親品目番号と子品目番号の複合主キー（かつ外部キー）で表現します。これにより「どの組立品にどの品目が何個使われるか」を正確に表現できます。
• UMLの多重度（品目側が *、組立品側が 0..1）から読み取れる関係は「組立品 1 対 品目 多」であり、子品目は親を最大1つしか持たない（多対多ではない）点も正しく反映されています。

解法ステップ

1. UMLの要素を確認する
   • 品目は抽象クラスで、組立品・部品は品目の分類である（同一の識別子で扱える）。
   • 組立品—品目間の関連に関連クラス「部品数（数）」がある。
   • 多重度：組立品側 0..1、品目側 * → 親（組立品）1対子（品目）多（子は親を最大1つ持つ）。
2. 継承のマッピング方針を決める
   • 単純な共通属性（品目番号、品目名）しかないため、単一テーブル＋型区分（ディスクリミネータ）で扱うのが実際的（選択肢中ではエがこれを採用）。
3. 関連クラスのマッピング
   • 関連クラスは属性（数）を持つのでテーブル化する。テーブルの主キーは「親品目番号＋子品目番号」の複合キーとし、両方を品目テーブルへの外部キーにする。
4. 制約を決める
   • 部品数テーブルの行は「親と子の組合せ」を表す。子が親を持たない場合は部品数に行が存在しない（NULLで表す必要はない）。参照整合性を外部キー制約で確保する。

CREATE TABLE 品目 (
  品目番号 VARCHAR PRIMARY KEY,
  品目名   VARCHAR,
  型区分   CHAR(1) NOT NULL  -- 'A'=組立品, 'B'=部品 など
);

CREATE TABLE 部品数 (
  親品目番号 VARCHAR NOT NULL,
  子品目番号 VARCHAR NOT NULL,
  数         INT NOT NULL,
  PRIMARY KEY (親品目番号, 子品目番号),
  FOREIGN KEY (親品目番号) REFERENCES 品目(品目番号),
  FOREIGN KEY (子品目番号) REFERENCES 品目(品目番号)
);

選択肢別の誤答解説

• ア
  • 組立品と部品をそれぞれ独立のテーブルに分けている点がまず設計方針として異なる（図では品目が上位）。また各テーブルに品目名を重複して持たせるなど正規化の観点で冗長です。UMLの継承（品目→組立品/部品）を反映していません。
• イ
  • 品目テーブルに「親品目番号」を設けているが、部品数テーブルが「子品目番号、数」しか持たないため、どの親と結びつくかを表現できない（親側の参照が欠落）。関連クラスの属性だけを残して関連の外部キーが不足しています。
• ウ
  • 品目を分割して組立品／部品を別テーブルにすると、品目共通の扱い（親・子双方が同じ品目種別であること）を表現しにくくなります。選択肢の設計は属性の重複と冗長なキー定義を生み、またUMLの関連クラスの正しい参照先（品目テーブル）になっていません。
• エ
  • 単一の品目テーブルに型区分を持たせ、部品数テーブルが親・子の品目番号を参照する構成は、UMLの継承と関連クラスを正しくリレーショナルに写像しているため適合します。

よくある誤解

• 「関連クラス＝常に多対多を意味する」
  • 関連クラスは関連に属性があることを示すだけで、多重度によって関係の性質（一対多・多対多など）が決まります。本問の多重度は一対多（親1：子多）であり、多対多ではありません。
• 「継承は必ずテーブル分割する」
  • 継承の実装方法は複数（単一テーブル、クラスごとテーブル、具象のみテーブル）あり、属性の重複やクエリ性能を勘案して選びます。本問では単一テーブル＋型区分が最も簡潔かつ適切です。
• 「子が親を持たないなら外部キーをNULLにすべき」
  • 子が親を持たない場合は部品数テーブルに対応行が存在しないだけで足ります。外部キー列をNULL許容にする必要はなく、存在しなければ関連がないことになります。

補足コラム

• 継承マッピングの選択（単一テーブル vs サブクラスごとテーブル）は、属性の差異、インデックス要件、NULL増加のトレードオフで決めます。試験では図から「抽象＋同一属性中心」と読み取れれば単一テーブル（型区分）を選ぶのが標準解です。
• 関連クラスをテーブル化するときは、主キー設計（複合主キーか代理キーか）も設計判断になります。本ケースでは (親,子) の複合主キーが自然で分かりやすいです。

FAQ