基本情報技術者 2010年 秋期 午前（科目A） 問29

外部キーの扱い【午前解説】

正解の理由

• 顧客名・顧客住所は顧客IDに関数従属するため顧客表に移す（重複排除）。
• 注文ごとに誰の注文かを示すため、注文表に顧客IDを外部キーとして残す。

解法ステップ

1. 関数従属性を洗い出す
   • 注文番号 → 注文年月日, 品目, 数量, 送付先, 支払方法, 受注金額（注文単位の属性）
   • 顧客ID → 顧客名, 顧客住所（顧客単位の属性）
2. 候補キーを特定する
   • 受注台帳の主キーは注文番号（問題文の下線）。
3. 第1・第2・第3正規形の観点で分解
   • 部分従属を排除（複合キーの部分従属があれば分割）。今回は主キーが単一の注文番号なので該当なし。
   • 推移的従属（transitive dependency）を排除：注文番号 → 顧客ID → 顧客名・顧客住所 のような推移を解消するため、顧客名・住所を顧客表へ移す。
4. 関連付けのための外部キーを残す
   • 注文表に顧客ID（外部キー）、顧客表に顧客ID（主キー）。
5. 検算（各属性がどの表に属すべきか確認）：送付先・支払方法は注文ごとに変わるため注文表に残す。

選択肢別の誤答解説

• ア：顧客ID
  正解。顧客情報を顧客表にまとめる際、注文と顧客を結びつけるために顧客IDが両表に必要（顧客表の主キーであり、注文表の外部キー）。
• イ：顧客名
  顧客名は顧客IDに依存する非キー属性であり、顧客表に移動すべき。重複を避けるため注文表に残すべきではない。人名は一意でない場合や変更されうるため、参照のためのキーに適さない。
• ウ：支払方法
  問題文で「送付先と支払方法は注文ごとに決める」と明示されている。したがって支払方法は注文表側の属性であり、顧客表に置くべきではない。
• エ：注文番号
  注文番号は注文表の主キーとして各注文を一意に識別するが、顧客表側で各顧客に対して複数の注文番号が存在し得るため、顧客表の主キーにはならない。顧客表に注文番号を持たせるのは冗長または多対多の設計ミス。

よくある誤解

1. 「顧客名をキーにすればよい」
   顧客名は重複や変更があり得るため、キー（識別子）に適さない。識別には不変で一意なIDを用いるのが基本。
2. 「第3正規形は‘部分従属だけ’を排除すればよい」
   第3正規形では部分従属に加え、推移的従属（例：注文番号 → 顧客ID → 顧客名）も排除する必要がある点を見落としがち。
3. 「すべてを正規化すればよい」
   正規化は整合性向上に有効だが、性能や可用性の観点から必要に応じて意図的に冗長化（非正規化）することもある点を理解しておく。

補足コラム

• 顧客に複数の送付先（配送先登録）がある場合、送付先を別テーブル（顧客ID + 送付先ID）として管理するのが望ましい。今回の問題では「送付先は注文ごとに決める」とされているため注文表に含める。
• 外部キーは論理的な参照を示すため、DDLでは次のように定義します。

CREATE TABLE Customer (
  customer_id VARCHAR(20) PRIMARY KEY,
  customer_name VARCHAR(100),
  address TEXT
);

CREATE TABLE Orders (
  order_no VARCHAR(20) PRIMARY KEY,
  order_date DATE,
  customer_id VARCHAR(20),
  item VARCHAR(100),
  quantity INT,
  ship_to TEXT,
  payment_method VARCHAR(50),
  amount DECIMAL(10,2),
  FOREIGN KEY (customer_id) REFERENCES Customer(customer_id)
);

FAQ