ITパスポート 令和6年度 問81:databaseに関する問題
一つの表で管理されていた受注データを、受注に関する情報と商品に関する情報に分割して、正規化を行った上で関係データベースの表で管理する。正規化を行った結果の表の組合せとして、最も適切なものはどれか。ここで、同一商品で単価が異なるときは商品番号も異なるものとする。また、発注者名には同姓同名はいないものとする。受注データの属性: 受注番号, 発注者名, 商品番号, 商品名, 個数, 単価。選択肢: ア 表1(受注番号,発注者名)+表2(商品番号,商品名,個数,単価) / イ 表1(受注番号,発注者名,商品番号)+表2(商品番号,商品名,個数,単価) / ウ 表1(受注番号,発注者名,商品番号,個数,単価)+表2(商品番号,商品名) / エ 表1(受注番号,発注者名,商品番号,個数)+表2(商品番号,商品名,単価)
- a表1(受注番号,発注者名)+表2(商品番号,商品名,個数,単価)
- b表1(受注番号,発注者名,商品番号)+表2(商品番号,商品名,個数,単価)
- c表1(受注番号,発注者名,商品番号,個数,単価)+表2(商品番号,商品名)
- d表1(受注番号,発注者名,商品番号,個数)+表2(商品番号,商品名,単価)正答
AI解説(初心者・標準・上級)
理解度に合わせて3レベルの解説を無料で読めます。
答えは d です。表1(受注番号,発注者名,商品番号,個数)+表2(商品番号,商品名,単価)。
正規化とは、ごちゃ混ぜの表を「ダブりが出ないように」きれいに分ける作業です。
商品番号が決まれば「商品名」と「単価」は自動で決まりますよね(同じ商品番号なら必ず同じ単価)。だから商品の情報(商品名・単価)は商品の表にまとめます。一方で「何個買ったか(個数)」は注文ごとに変わるので、注文側の表に置きます。
👉 覚え方:「いつも一緒に決まるもの(商品名・単価)」は別の表へ。「注文ごとに変わるもの(個数)」は注文の表へ。
ほかは個数や単価の置き場所がズレているので不正解です。
なぜこれが正解か
正解は d 表1(受注番号,発注者名,商品番号,個数)+表2(商品番号,商品名,単価)。
各属性が何で決まるか(関数従属)を考える。
- 受注番号 → 発注者名(発注者名に同姓同名なし)
- 商品番号 → 商品名、単価(同一商品で単価が異なれば商品番号も異なる=単価は商品番号で一意に決まる)
- 個数 → 受注ごとに決まる値なので受注側に残す
したがって商品番号で決まる「商品名・単価」を表2へ分離し、受注側には「受注番号・発注者名・商品番号・個数」を残すdが正しい。
各選択肢の解説
- a:表1に商品番号がなく、表2に個数が入っている。個数は商品では決まらないので誤り。
- b:個数がどちらの表にもなく欠落。誤り。
- c:単価を受注側に残しているが、単価は商品番号で決まるので商品側に置くべき。誤り。
覚え方・ひっかけ注意
「同一商品で単価が違えば商品番号も違う」=単価は商品番号に従属、という条件文が正解の決め手。個数(注文で変動)と単価(商品で固定)の置き場所を取り違えないこと。
理論的背景
関係データベースの正規化(Normalization)はEdgar F. Coddが1970年代に確立した理論であり、データの冗長性除去と更新時異常(Update Anomaly)の防止を目的とする。本問は「受注データを受注情報と商品情報に分割する」という第2正規形への変換を問うている。第1正規形(1NF):繰り返しグループを排除してテーブルに配置。第2正規形(2NF):部分関数従属の除去——「非キー属性が複合主キーの一部のみに従属している場合(部分従属)」を別テーブルに分離する。本問の正解dの分析:主キーは受注番号(個別の受注を一意識別)。商品名・単価は受注番号ではなく商品番号に従属する(同一商品は常に同じ商品名・単価を持つという制約)→部分従属のため別テーブルに分離。受注ごとに異なる個数(受注依存)は受注テーブルに残す。表1(受注番号,発注者名,商品番号,個数)+表2(商品番号,商品名,単価)が正解。
実務での使われ方
データベース設計の正規化は実務においてERモデリング(Entity-Relationship Modeling)の基礎として適用される。MySQLWorkbench・pgAdmin・DBeaver・Hackolade等のERDツールで設計し、データモデリングの段階で第3正規形(3NF)またはBCNF(Boyce-Codd Normal Form)まで正規化するのが一般的。ただし過度な正規化はJOIN操作の増加によりクエリパフォーマンスを低下させるため、OLAPシステム(データウェアハウス・BIツール)ではスタースキーマやスノーフレークスキーマという「意図的な非正規化」が採用される。近年のマイクロサービスアーキテクチャでは、サービス間でデータを分散保持する設計が普及しており、従来の正規化とは異なる「サービス境界でのデータモデリング(DDD:Domain-Driven Design)」が重要な設計スキルとなっている。
試験での位置づけ
データベース正規化はITパスポート「テクノロジ系/データベース」の最重要テーマの一つであり、毎年複数回出題される。本問のように「正規化後の表の組み合わせを選ぶ」形式では、どの属性がどのキーに従属するかを正確に分析する必要がある。よくある誤答パターン:選択肢bの「表1(受注番号,発注者名,商品番号)+表2(商品番号,商品名,個数,単価)」は個数を商品テーブルに入れてしまい(個数は受注ごとに異なるため商品には依存しない)誤り。選択肢cは単価を受注テーブルに入れており(単価は商品番号で決まるため商品テーブルが正しい)誤り。基本情報技術者(FE)では第3正規形(推移関数従属の除去)・BCNFまで問われ、関数従属の形式的な定義と正規化手順の証明的な理解が求められる。
選択肢の発展補足
選択肢aは表1に商品番号が含まれず(受注と商品の関連付けが不可能)、実際の注文データを表現できないため即座に排除できる。選択肢bは個数を商品テーブルに入れる誤り——「個数は受注によって異なる」(同じ商品でも受注ごとに異なる数量を注文できる)ため商品テーブルの属性としては不適切。選択肢cは単価を受注テーブルに入れる誤り——「同一商品番号に対して単価は一意」(問題文の制約「同一商品で単価が異なるときは商品番号も異なる」)であるため商品テーブルの属性が正しい。発展として、第3正規形への変換:本問の正解表でさらに「発注者名が受注番号→発注者ID(または発注者名)に直接従属するか、発注者の住所等を管理するなら発注者テーブルを別途作成すべきか」という推移従属の検討が必要となる。また問題文の「同姓同名はいない」という制約は発注者名を主キーとして使用できることを示しているが、実務では名前ではなく人工キー(発注者ID)を主キーに使うことが標準設計である。
出典:IPA(情報処理推進機構)公式 ITパスポート試験 令和6年度 問81/ 公的機関配布資料につき出典明記の上引用。解説は合格ナビによる独自AI解説です。