ITパスポート 2024年 問81

受注データの正規化と表の分割【ITパスポート 解説】

正解の理由

• 「商品番号」で決まる情報（商品名、単価）は商品固有の属性です。つまり「商品番号 → 商品名, 単価」という関数従属性（ある列が別の列を一意に決める関係）があります。商品に関する情報は商品テーブルへまとめるべきです。
• 一方で「個数」はその受注に特有の値です。どの注文で何個買ったかは受注側に属します。受注を管理する表には受注番号、発注者名、商品番号、個数のように、注文ごとの行（＝受注明細）が入るのが自然です。
• したがって、商品属性（商品名・単価）を商品テーブルへ、受注ごとの情報（受注番号・発注者名・商品番号・個数）を受注側のテーブルへ分ける エ が正しい分割になります。

解法ステップ

1. 元の表の項目を列挙する：受注番号、発注者名、商品番号、商品名、個数、単価。
2. 「どの列がどの列を決めるか」を考える（関数従属性の確認）。
   • 商品番号 → 商品名、単価（商品番号が決まれば商品名・単価が決まる）
   • 受注番号 → 発注者名（同一受注番号は同一の発注者）
   • 個数は受注番号＋商品番号の組み合わせに依存する（どの注文で何個か）
3. 商品に固有の属性（商品名・単価）を商品テーブルへ移す。受注ごとの情報（受注番号・発注者名・商品番号・個数）は受注側に残す。
4. 結果として、受注テーブル（受注明細）と商品テーブルの2つに分ける。これが選択肢の エ に相当する。

選択肢別の誤答解説

• ア：上段が受注番号・発注者名、下段が商品番号・商品名・個数・単価。
  問題点：下段の表に「個数」が入っていると、個数が商品ごとの固定値になってしまい、どの受注に対応する個数か分かりません。また、受注と商品を結びつける受注番号がどこにもないため、注文ごとの数量を管理できません。
• イ：上段に受注番号・発注者名・商品番号、下段に商品番号・商品名・個数・単価。
  問題点：下段に個数が入っているため、個数が商品固有の情報になってしまいます。個数は注文ごとの値であるべきで、商品テーブルに入れるのは誤りです。
• ウ：上段に受注番号・発注者名・商品番号・個数・単価、下段に商品番号・商品名。
  問題点：単価が受注（上段）側に残っています。単価は商品番号で決まる商品固有のデータなので商品テーブルに移すべきです。単価を上段に残すと、同じ商品の単価が複数行に重複して保存され、更新時に不整合（更新異常）が生じます。
• エ：上段に受注番号・発注者名・商品番号・個数、下段に商品番号・商品名・単価。
  これが正しい。商品固有情報（商品名・単価）は商品テーブル、注文に依存する個数は受注明細側にあるため、冗長性や更新異常を防げます。

よくある誤解

1. 「単価は注文時の値だから受注側に置くべき」と考えるミス
   → この問題では「同一商品で単価が異なるときは商品番号も異なる」と明示されています。つまり単価は商品の属性であり、商品番号で一意に決まるため商品テーブルに置きます（実務では過去の取引価格を残すなら別途価格履歴テーブルが必要です）。
2. 「個数は商品に関する属性だ」と思うミス
   → 個数は“その注文で何個買ったか”という注文固有の情報です。商品テーブルに入れると、どの注文の個数か分からなくなります。
3. 「分割すれば分割するほど正解」と考える誤解
   → 正規化は冗長性を減らす目的ですが、過度に分割すると扱いにくくなります。設計は「属性の従属関係（誰が誰を決めるか）」に基づいて行います。

補足コラム

• 受注（受注ヘッダ）: 受注番号、発注者名、受注日など（注文全体に関する情報）
• 受注明細: 受注番号、商品番号、個数、行ごとの金額など（注文ごとの明細）
• 商品: 商品番号、商品名、単価など（商品そのものの情報）

FAQ