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

受注台帳を第3正規形に分解する問題【午前2 解説】

要点まとめ

• 結論: 両方に必要なのは顧客IDです。顧客表の主キーで顧客を一意に識別し、注文表では外部キーとして注文と顧客を結び付けるため必須です。
• 根拠: 第3正規形では属性はその表の主キーにのみ従属させ、転置的従属を排除します。顧客名や住所は顧客に属し、送付先・支払方法は注文ごとに決まるため分離します。
• 差がつくポイント: 顧客名を両方に冗長に持たないこと、支払方法は注文属性に残すこと、注文番号は注文表の主キーのみとする点を正確に理解してください。

正解の理由

よくある誤解

• 顧客名を両方に入れるべきと考える: 見かけ上便利でも冗長性・更新異常の原因になるためNGです。
• 支払方法を顧客属性だと誤認する: 問題文に「注文ごとに決める」と明記されている場合は顧客に紐づけてはいけません。
• 注文番号を顧客表にも必要と考える: 注文番号は注文の主キーであり顧客の属性ではないため顧客表には含めません。

解法ステップ

1. 表の属性を読んで「エンティティ候補」を洗い出す（ここでは「顧客」と「注文」）。
2. 各エンティティの主キーを決める（顧客→顧客ID、注文→注文番号）。
3. 各属性がどちらの主キーに従属するか判定する（顧客名・住所→顧客、送付先・支払方法・受注金額・品目・数量・注文年月日→注文）。
4. 第1〜第3正規形の基準で部分従属や転置的従属を排除する（顧客名等を顧客表へ移す、顧客IDを注文表へ外部キーとして残す）。
5. 最終確認：冗長性がなく、各非キー属性がそのキーに直接従属しているか確認する。

選択肢別の誤答解説

• ア: 顧客ID — 正解。顧客表の主キーであり、注文表では外部キーとして両方に存在する必要があります。
• イ: 顧客名 — 誤り。顧客名は顧客表に属する属性で、注文表に複製すると冗長性と更新不整合の原因になります。
• ウ: 支払方法 — 誤り。問題文で「注文ごとに決める」とあり、注文表側の属性であって顧客表に共通して持たせるものではありません。
• エ: 注文番号 — 誤り。注文番号は注文表の主キーであり、顧客表に含めるべき属性ではありません。顧客側の主キーは顧客IDです。

補足コラム

• 第3正規形（3NF）のポイントは「各非キー属性が主キーに対してのみ直接従属している」ことです。転置的従属（非キー→非キー）を排除することで更新・挿入・削除の異常を防げます。
• 実務ではパフォーマンスや運用上の理由で、正規化を部分的に緩め（デノーマライズ）ることがありますが、その場合は冗長性と整合性確保手段（更新処理、制約、トリガ）を設計する必要があります。
• 例: SQLでのテーブル定義（参考）

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

CREATE TABLE OrderHead (
  order_no      VARCHAR(20) PRIMARY KEY,
  order_date    DATE,
  customer_id   VARCHAR(20),
  ship_to       VARCHAR(200),
  payment_method VARCHAR(50),
  total_amount  DECIMAL(10,2),
  FOREIGN KEY (customer_id) REFERENCES Customer(customer_id)
);

FAQ