1. 問題になりやすい具体例（NG例）
顧客
├ 会員番号（PK）
├ 氏名
├ 住所
会員番号を主キーとして使う設計。
業務上は「意味のある番号」なので、
一見すると分かりやすく感じる。
2. なぜこの設計がつらくなるのか
•会員番号の体系変更に弱い
•桁数変更・再採番が起きると全テーブルに影響
•外部キーを持つテーブルの修正範囲が広がる
顧客 → 注文 → 注文明細 → 支払
と関連が増えるほど、
主キー変更＝大事故になりやすい。
3. 考え方の整理
• 主キー：システム都合の識別子
• 業務コード：業務都合で変わりうる
この2つは役割が違う。
4. 理想の具体例（改善後）
顧客テーブル
顧客
├ 顧客ID（PK：サロゲートキー）
├ 会員番号（UK）
├ 氏名
├ 住所
• 顧客ID：意味を持たない連番
• 会員番号：業務上の識別子（ユニーク制約）
注文テーブル
注文
├ 注文ID（PK）
├ 顧客ID（FK）
├ 注文日
✔ 会員番号が変わっても影響なし
✔ 外部キーは安定
✔ 設計変更に強い
5. デスぺ視点でのポイント
午後Ⅱでは、
• 将来の制度変更
• 番号体系変更
• 再採番
が要件に含まれることが多い。
**「主キー＝業務コード」**は
減点されやすい典型パターン。
まとめ
・主キーは意味を持たせない
・業務コードはユニーク制約で守る
・変更されうるものをキーにしない