ITパスポート 令和5年度 問59：databaseに関する問題

答えは d です。

お店の会員カードを想像してください。同じ「会員番号1番」でも、札幌店の1番さんと東京店の1番さんは別人ですよね。この表でも、会員番号は“お店ごと”に付け直すので、番号だけでは1人に決められません。

だから「お店（店舗コード）＋会員番号」のセットで、はじめて1人に特定できます。会員の名前と、その人の会員ランク（会員種別コード）も会員の情報なので一緒に持ちます。

👉 覚え方：「番号だけじゃ足りない→お店もセット」。

会員種別“名”（ゴールド等の呼び名）は別表に分けるので、ここには番号（コード）だけ持てばOK。

なぜこれが正解か

正解は d（会員番号・店舗コード・会員名・会員種別コード）。会員番号は店舗ごとに付与されるため、会員番号単独では一意に定まらない。主キーは「店舗コード＋会員番号」の複合キーとなる。会員名と会員種別コードは会員ごとに決まる属性なので会員表に残す。

各選択肢の解説

• a（会員番号・会員名）：店舗コードがなく主キーが成立しない。会員種別コードも欠落。
• b（会員番号・会員名・会員種別コード）：店舗コードがないため別店舗の同番号を区別できない。
• c（会員番号・店舗コード・会員名）：会員種別コードが欠け、会員のランク情報が失われる。

覚え方・ひっかけ注意

正規化の問題は「その値が何によって一意に決まるか」を見る。会員種別“名”は会員種別コードで決まる（→種別表へ分離）。会員表に残すのはコードだけ。「番号は店舗ごと」という条件文が複合キーのヒント。

理論的背景

関係データベース（RDB）の正規化は、データの冗長性を排除し更新異常（挿入・削除・更新の3種類）を防ぐための体系的な設計手法であり、E.F.コッドが1970年代に体系化した関係代数・関係論理に基づく。正規化は関数従属性の分析を通じて進められる。

関数従属性：属性（列）Xの値が決まれば属性Yの値が一意に決まる関係（X → Y）を関数従属と呼ぶ。元の「会員管理」表での関数従属関係を整理すると：

• 店舗コード → 店舗名（部分的な関数従属・第2正規化の対象）
• 会員種別コード → 会員種別名（部分的な関数従属・第2正規化の対象）
• {店舗コード, 会員番号} → 会員名, 会員種別コード（主キーに完全に従属）

問題文に「一人の会員が複数の店舗に登録した場合は、会員番号を店舗ごとに付与する」という条件があるため、会員番号だけでは会員を一意に特定できない（例：札幌店の会員番号1番と東京店の会員番号1番は別人）。よって会員表の主キーは{店舗コード, 会員番号}の複合キーとなり、会員表にはこの複合主キーに加えて「会員名」（主キーに完全従属する属性）と「会員種別コード」（外部キー）が含まれる。

「会員種別名」を会員表に残すと、同一会員種別コードを持つ会員が複数いる場合に同じ種別名が繰り返し格納される冗長性が生じ、「ゴールド」→「プレミアム」に種別名を変更する際に全行を更新しなければならない更新異常が発生する。したがって会員種別名は会員種別表に分離し、会員表はコード（外部キー）のみを保持する。

実務での使われ方

実際のデータベース設計では、正規化（データ整合性・更新効率の向上）と非正規化（デノーマライゼーション）（クエリパフォーマンスの向上）のトレードオフを意識的に管理する。OLTPシステム（オンライントランザクション処理・更新が頻繁に発生するシステム）では第3正規形までの正規化が標準的であるが、OLAP/DWH（データウェアハウス・分析用途・頻繁な大量読み出し）では意図的に非正規化（スタースキーマ・スノーフレークスキーマ）を用いてJOINを減らしクエリを高速化する設計が採用される。

外部キー制約（Foreign Key Constraint）は参照整合性を担保する重要なデータベース機能であり、本問の「会員種別コード」が会員種別表の主キーを参照する外部キーとして設定される。これにより「存在しない会員種別コードを会員表に登録できない」「会員表で参照されている会員種別コードを会員種別表から削除できない」という整合性ルールが自動的に強制される。

試験での位置づけ

ITパスポートのテクノロジ系・データベース分野では、正規化と主キー・外部キーの概念が安定して出題される。本問のように「正規化後の各表の列構成を答える」形式では、（1）主キーが何列か（複合キーの可能性の判定）、（2）各属性が主キーに完全従属するか部分従属するか（第2正規形）、（3）主キー以外の属性に推移的従属する属性がないか（第3正規形）という3ステップの分析が必要となる。

本問の核心である「店舗ごとに会員番号が付与される」という条件の読み取りを誤ると、単一列の主キーを前提とした誤答（選択肢a・b）を選んでしまう。問題文の条件設定を丁寧に読み解く習慣が正答率向上の鍵となる。基本情報技術者試験では第1〜第3正規形の定義・BCNFの概念・SQL（SELECT-FROM-WHERE-GROUP BY-HAVINGの構文）・ビューの利用まで問われる。

選択肢の発展補足

選択肢a（会員番号・会員名のみ）：店舗コードがなく複合主キーが成立しない。複数店舗に同一番号の会員が登録されている実データ（例：札幌店1番・東京店1番・東京店2番・大阪店1番）を格納した場合、主キーの一意性制約に違反する。会員種別情報も欠落している。

選択肢b（会員番号・会員名・会員種別コード）：会員種別コードを含む点で選択肢aよりは改善されているが、依然として店舗コードがなく主キーが不完全。会員番号単独では複数店舗の同番号会員を区別できない。

選択肢c（会員番号・店舗コード・会員名）：複合主キー（店舗コード+会員番号）の設定は正しいが、会員種別コード（外部キー）が欠落しており、各会員がどの会員種別（プラチナ・ゴールド・一般）に属するかの情報が失われる。会員の種別情報は会員表が保持すべきデータである。選択肢cは「会員種別コードを忘れた」場合の典型的な誤答パターンを模している。

選択肢d（会員番号・店舗コード・会員名・会員種別コード）：上記分析の通り、複合主キー+外部キー（会員種別コード）+属性（会員名）で第3正規形を満たす適切な設計。会員種別名は会員種別表に分離されており冗長性が排除されている。