ホーム > データベーススペシャリスト試験 > 2023年
データベーススペシャリスト試験 2023年 午前2 問08
次の表を、第3正規形まで正規化を行った場合、少なくとも幾つの表に分割されるか。ここで、顧客の1回の注文に対して1枚の受注伝票が作られ、顧客は1回の注文で一つ以上の商品を注文できるものとする。
ア：2
イ：3
ウ：4（正解）
エ：5
解説
第3正規形まで正規化した場合の表の分割数【午前2 解説】
要点まとめ
- 結論：第3正規形まで正規化すると、少なくとも4つの表に分割されます。
- 根拠：顧客情報、受注情報、商品情報、受注明細の4つの独立したエンティティに分ける必要があるためです。
- 差がつくポイント：受注と受注明細の関係や、顧客・商品情報の重複排除を正しく理解できているかが鍵です。
正解の理由
この問題は、1つの表に複数のエンティティ（顧客、受注、商品、受注明細）が混在している状態から、第3正規形まで正規化する問題です。
- 顧客コードと顧客名は顧客テーブルに分離し、顧客情報の重複を排除します。
- 受注番号と受注日は受注テーブルにまとめ、1回の注文単位で管理します。
- 商品コード、商品名、単価は商品テーブルに分けて商品情報を一元化します。
- 受注明細テーブルは受注番号と商品コードを複合主キーとし、受注数や受注金額を管理します。
これら4つのテーブルに分割することで、すべての関数従属性が満たされ、第3正規形となります。
よくある誤解
「受注と受注明細を1つの表にまとめてよい」と考えがちですが、受注明細は複数の商品を含むため分割が必要です。
また、顧客情報や商品情報を分割しないと重複が残り、正規化の目的を達成できません。
また、顧客情報や商品情報を分割しないと重複が残り、正規化の目的を達成できません。
解法ステップ
- 元の表の属性を確認し、エンティティごとに分類する。
- 顧客コード→顧客名の関数従属性を見て顧客テーブルを作成。
- 受注番号→受注日、顧客コードの関数従属性から受注テーブルを作成。
- 商品コード→商品名、単価の関数従属性から商品テーブルを作成。
- 受注番号＋商品コードを複合主キーとする受注明細テーブルを作成し、受注数や受注金額を管理。
- 以上4つのテーブルに分割し、第3正規形を満たすことを確認。
選択肢別の誤答解説
- ア（2）：顧客情報と受注情報をまとめすぎており、商品情報や受注明細が分割されていません。
- イ（3）：顧客、受注、商品に分けても受注明細を分割しないため不十分です。
- ウ（4）：顧客、受注、商品、受注明細の4つに正しく分割し、第3正規形を満たします。
- エ（5）：5つに分割する必要はなく、過剰分割となり非効率です。
補足コラム
正規化はデータの冗長性を排除し、更新異常を防ぐための重要な手法です。
第1正規形は繰り返しグループの排除、第2正規形は部分関数従属性の排除、第3正規形は推移的関数従属性の排除を目的とします。
今回の問題では、受注明細の複数商品対応がポイントで、複合主キーの理解も重要です。
第1正規形は繰り返しグループの排除、第2正規形は部分関数従属性の排除、第3正規形は推移的関数従属性の排除を目的とします。
今回の問題では、受注明細の複数商品対応がポイントで、複合主キーの理解も重要です。
FAQ
Q: 第3正規形まで正規化すると必ず4つの表に分割されますか？
A: いいえ。エンティティの数や関係性によって異なりますが、この問題のように顧客・受注・商品・受注明細があれば4つになります。
A: いいえ。エンティティの数や関係性によって異なりますが、この問題のように顧客・受注・商品・受注明細があれば4つになります。
Q: 受注明細テーブルの主キーは何ですか？
A: 受注番号と商品コードの複合主キーです。これにより1回の受注で複数商品を管理できます。
A: 受注番号と商品コードの複合主キーです。これにより1回の受注で複数商品を管理できます。
Q: 正規化しすぎるとデータベースのパフォーマンスに影響しますか？
A: はい。過度な正規化は結合が増えパフォーマンス低下の原因になるため、実務では適度な正規化が推奨されます。
A: はい。過度な正規化は結合が増えパフォーマンス低下の原因になるため、実務では適度な正規化が推奨されます。
関連キーワード: 正規化, 第3正規形, 関数従属性, 受注明細, 複合主キー, データベース設計