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

関係“注文記録”の正規化による注文明細の設計【午前2 解説】

要点まとめ

• 結論：注文明細は主キーが{注文番号, 商品番号}で、数量と販売単価を属性として持つ構成が正解です。
• 根拠：与えられた関数従属性で数量と販売単価は$\{注文番号,商品番号\}\to 数量,販売単価$と明示され、これが注文明細のキー決定を示します。
• 差がつくポイント：注文番号単独や顧客番号を含めると部分従属性や推移的従属性が残り、2NF/3NF違反になる点を見抜くことが重要です。

正解の理由

よくある誤解

• 「注文番号だけで注文明細は識別できる」と誤解し、商品ごとの複数行を無視してしまう点。注文1件に複数商品の可能性を考慮する必要があります。
• 「顧客番号や顧客名も注文明細に入れるべき」と考える点。顧客番号は注文番号から決まるため注文明細に入れると冗長で正規化違反になります。
• 商品名や顧客名をそのまま注文明細に残すと、推移的従属性（顧客番号→顧客名、商品番号→商品名）により第3正規形を満たさなくなります。

解法ステップ

1. 与えられた関数従属性を一覧化する（①〜⑥）。
2. 注文明細に関係する属性を特定する：行単位で必要なのは「どの注文のどの商品か」と「その数量・単価」。
3. キー候補を求める：数量・販売単価は$\{注文番号,商品番号\}$で決まるため、この組が主キー候補となる。
4. 第3正規形の観点で冗長・推移的従属性を排除：顧客番号や名称、商品名は別関係（顧客、商品）へ分離する。
5. 結果として注文明細は(注文番号, 商品番号, 数量, 販売単価) と定義する。

選択肢別の誤答解説

• ア: 注文明細(注文番号, 数量, 販売単価)
  注文番号だけでは同一注文内の複数商品の区別がつかないため主キーとして不十分です。行を一意に識別できず誤りです。
• イ: 注文明細(注文番号, 顧客番号, 数量, 販売単価)
  顧客番号は関数従属性②（注文番号→顧客番号）により注文番号で決まるため冗長です。主キーに顧客番号を含めると部分従属性や冗長性を招き、正規化の目的に反します。
• ウ: 注文明細(注文番号, 顧客番号, 商品番号, 顧客名, 数量, 販売単価)
  顧客名はさらに顧客番号→顧客名（③）で決まるため推移的従属性が残り、第3正規形を満たしません。属性が分解されておらず冗長です。
• エ: 注文明細(注文番号, 商品番号, 数量, 販売単価)
  正解。数量・販売単価は$\{注文番号,商品番号\}$で決まり、これを主キーとすることで2NF・3NFを満たします。

補足コラム

• 部分従属性と推移的従属性の違い：
  • 部分従属性は複合キーの一部に依存する非キー属性（2NF違反の原因）。
  • 推移的従属性は非キー属性が他の非キー属性を介して決定される場合（3NF違反の原因）。
• 今回のケースでは「顧客番号は注文番号で決まる」ため顧客情報は注文テーブルにまとめ、顧客名は顧客テーブルへ分離します。商品名も同様に商品テーブルへ分離します。
• 注：販売単価が商品固有の値でなく注文ごとに変わる可能性が与えられているため、販売単価は注文明細に含めるのが正しい設計です（FD⑤に基づく）。

FAQ