データベーススペシャリスト 2024年 午前2 問05

代理キー導入【午前2解説】

正解の理由

解法ステップ

1. 複合キーの属性群が業務的に「自然キー（natural key）」として必須かを判断する（外部との参照・一意性要件の有無）。
2. 取り扱いが困難であれば、連番やUUID等の新しい単一列を追加して主キー（代理キー）とする（CREATE TABLE における ID 列の追加）。
3. 元の複合キーが一意性を保証すべきなら、UNIQUE 制約や代替キーとして保持する（DROP しない）。
4. 参照テーブルは可能なら代理キーを参照するように変更し、移行時はデータ整合性を保つためにマッピングを行う。
5. インデックスやクエリ性能を考慮し、必要に応じて元の自然キー属性に対してインデックスを張る。

CREATE TABLE 商品 (
  商品ID BIGINT AUTO_INCREMENT PRIMARY KEY, -- 代理キー
  メーカーコード VARCHAR(10) NOT NULL,
  商品コード   VARCHAR(20) NOT NULL,
  商品名       VARCHAR(100),
  -- 元の複合キーの一意性を維持
  UNIQUE (メーカーコード, 商品コード)
);

選択肢別の誤答解説

• ア: 複合キーの残り属性を「外部キー」にする案は不適切です。外部キーは通常、他テーブルの主キー（または別の候補キー）を参照するための参照制約であり、同一エンティティ内の単に属性を分離して外部キーにするという意味にならない（自己参照の外部キーは可能だが、本問の趣旨には合致しない）。したがって属性の性格説明だけで残りを外部キーにするのは誤りです。
• イ: 「一つを主キー、残りを代替キーにする」という案は、多くの場合成立しません。代替キー（alternate key）は“別に一意性を持つ候補”を指しますが、複合キーの残り属性群が単独で一意性を保証しないなら代替キーにはなりません。つまり、単一属性で一意にならない場合は代替キーにできない点が問題です。
• ウ: 新たに連番等の列を設けて主キーとする案は、実務上もっとも扱いやすく汎用性が高い。元の属性群は必要に応じて代替キーやユニーク制約として残す点を忘れないこと。
• エ: 代理キーは設けるが「複合キーを外部キーにする」案は不適切です。外部キーは他テーブル（あるいは意図的な自己参照先）の主キーを参照するためのものであり、単に自身の元の属性群を外部キーにするという設計は意味をなさない。複合属性群は内部的には代替キーやユニーク制約として扱うべきです。

よくある誤解

• 代理キーを導入すれば元の自然キーの一意性チェックは不要になる、という誤解。業務的に自然キーの一意性が要求される場合は、代理キー導入後もUNIQUE制約などで一意性を保持すべきです。
• 外部キーは「必ず別テーブルを参照しなければならない」との誤認。自己参照（同一テーブルを参照する外部キー）は可能だが、本設問の目的（複合キー簡素化）には通常関係しない、という点を混同しやすいです。
• 代理キーだけで全て解決すると思い込むこと。代理キーは識別の便利さを提供するが、検索性や業務上の意味（自然キーによる検索や検証）は別途考慮しインデックスや制約で補う必要があります。

補足コラム

• 代理キーを採る利点：テーブル結合が単一列で済み実装が簡潔、主キーの幅が狭いことでインデックスや外部テーブルの参照が効率化される、主キー変更の影響が少ない。
• 欠点：代理キーは業務的意味を持たないため、業務での一意性検査やデータ重複の検出は自然キー側で行う必要がある。ログや外部連携で自然キーの扱いが必要になる場合もある。
• 運用上の勧め：代理キー導入後も、元の自然キー（複合キー）に対してUNIQUE制約やインデックスを設定して、業務ルールと整合性を保つ設計が望ましい。

FAQ