基本情報 平成27年度 秋期 問27｜テクノロジ系に関する問題

答えは d「注文明細(注文番号, 商品番号, 数量, 販売単価)」です。

第3正規形は「重複データを徹底的に消す」整理術。

注文明細は「どの注文の、どの商品が、何個、いくらで」を表すだけでいい。顧客名や商品名は別の表（顧客テーブル・商品テーブル）に置きます。

👉 覚え方：明細は「注文×商品」の交差ポイントのみ。名前は親テーブル参照で十分。

ほかの選択肢：a 商品番号がない＝何の商品か分からない／b 顧客番号は注文テーブルにあるべき／c 顧客名や顧客番号まで持つと重複だらけ。

なぜこれが正解か

正解は d。関数従属性④⑤より（注文番号, 商品番号）→ 数量, 販売単価が成立する。注文明細関係は「ある注文のある商品ごとの情報」を表すため、主キーは複合キー（注文番号, 商品番号）、非キー属性は数量・販売単価のみ。

各選択肢の解説

• a 誤り：商品番号がないため、どの商品の数量か特定できない。
• b 誤り：顧客番号は「注文」関係（注文番号→顧客番号）に属する。明細に持つと冗長。
• c 誤り：顧客番号・顧客名は注文・顧客関係にあるべきで、明細に含めると第3正規形違反（推移的関数従属が発生）。

覚え方・ひっかけ注意

第3正規形の判定：「すべての非キー属性が主キーのみに直接依存」。推移的関数従属（A→B→Cの形）があれば分解。明細表の主キーは「親テーブル2つの組み合わせ（多対多の解消）」と覚える。商品名・顧客名のような「子に流れがちな属性」は親テーブル管理に留める。

理論的背景

正規化（Normalization）はE.F.Coddが提唱した関係データベース設計理論。第1正規形（1NF：原子値）・第2正規形（2NF：1NF＋部分関数従属の除去）・第3正規形（3NF：2NF＋推移的関数従属の除去）・ボイス・コッド正規形（BCNF：3NF＋全関数従属の決定項が候補キー）・第4正規形（4NF：多値従属の除去）・第5正規形（5NF：結合従属の除去）と段階化される。本問は3NFまでの典型例。

実務での使われ方

OLTP（オンライントランザクション処理）系DBは3NF〜BCNFを目指す（更新異常防止・整合性確保）。一方、OLAP（オンライン分析処理）・データウェアハウスではスタースキーマ・スノーフレークスキーマで意図的に非正規化し、クエリ性能を優先する。NoSQLでは「埋め込みドキュメント」によりJOIN削減を行う場合も多い。

試験での位置づけ

データベース分野の最頻出論点。基本情報・応用情報・データベーススペシャリストで毎期出題。関数従属性・候補キー・主キー・正規形判定の手順は完全暗記必須。E-Rモデルからの正規化変換、SQL DDLでの実装まで問われる。

選択肢の発展補足

• 注文明細の主キー（注文番号, 商品番号）は典型的な「連関エンティティ（Associative Entity）」で、多対多関係を解消するための中間表として頻出。
• 「販売単価」が（注文番号, 商品番号）に従属するのは「単価が注文時点で変動する」モデルだから。もし「単価は商品マスタで固定」なら、販売単価は商品テーブル側に属する別設計となる（業務要件で正規化結果が変わる典型例）。
• 非正規化の判断基準：(1) 読み取り性能要件、(2) 更新頻度、(3) 整合性確保コスト。マテリアライズドビューやCDC（Change Data Capture）併用が現代的解。