ITパスポート 2023年 問59

会員テーブルの正規化設計【ITパスポート解説】

正解の理由

解法ステップ

1. 元の表の各列の意味を確認する
   • 店舗コード／店舗名：店舗を識別・表示するための情報
   • 会員番号／会員名：店舗ごとの会員登録情報
   • 会員種別コード／会員種別名：会員のランク情報（別表化済み）
2. 正規化の目的を確認する
   • 重複や更新の不整合を防ぐため、関係の異なる情報（店舗情報、会員種別）は別表に分ける。
3. 主キー（一意性）を決める
   • ルール「会員番号は店舗ごとに付与」より、会員を一意に識別するには「店舗コード＋会員番号」の組合せが必要（複合主キー）。
4. 外部キーを残す
   • 会員種別名は会員種別表にあるため、会員表には「会員種別コード」を置き、会員種別表を参照する。
5. 選択肢と照合して最も適合するものを選ぶ
   • 「店舗コード＋会員番号」が主キーになっていて、会員名と会員種別コードが含まれている選択肢が正解 → エ。

選択肢別の誤答解説

• ア: 会員番号（単独で主キー）と会員名のみ。
  理由：会員番号は店舗ごとに付与されるため、会員番号だけでは複数店舗に同じ番号の会員がいる場合に区別できません。したがって一意性を満たさず不適切です。
• イ: 会員番号（主キー）、会員名、会員種別コード（3分割）。
  理由：同じく会員番号が単独主キーになっているため、店舗ごとの区別ができません。店舗コードが欠けているため、どの店舗の登録かが分かりません。
• ウ: 会員番号（下線＝主キー）、店舗コード（下線＝主キー）、会員名（3分割）。
  理由：会員番号と店舗コードの複合主キーは正しいのですが、会員種別コードが含まれておらず、会員種別表と関連付けられません。会員の「種別」を示す情報を保持・参照できないため不完全です。
• エ: 会員番号（下線）、店舗コード（下線）、会員名、会員種別コード（4分割）。
  理由：店舗コード＋会員番号の複合主キーで一意性を確保し、会員名を属性として保持。会員種別コードで会員種別表とつなげるため、設問の要件を満たします（正解）。

よくある誤解

1. 「会員番号があれば十分」と考える誤解
   • 誤りの理由：設問のルールで会員番号は店舗ごとに作られるため、単独では全店舗で一意になりません。必ず店舗コードとの組合せを考えます。
2. 「会員名で識別できる」と考える誤解
   • 誤りの理由：人名は重複や表記ゆれ（姓・名の順・全角半角など）で一意にできません。キーには識別子（番号やコード）を使います。
3. 「正規化は必ずすべての列を別表に分ける」
   • 誤りの理由：必要以上に分割すると逆に扱いにくくなります。正規化は冗長性や更新異常を防ぐために行い、業務ルールに応じた粒度で行います。

補足コラム：複合主キーと外部キーのイメージ

• 複合主キー（合成主キー）
  • 複数の列を組合せて「その表の1行を一意に識別」します。今回なら「店舗コード＋会員番号」で、その店舗での会員登録を一意に示します。
  • 例：札幌店（001）での会員番号1 は (001,1) として一意。
• 外部キー（FK：foreign key）
  • 他の表の主キーを参照するための列です。今回の「会員種別コード」は会員種別表の「会員種別コード」を参照します。参照により種別名を別表から取得できます。

CREATE TABLE 会員 (
  店舗コード CHAR(3),
  会員番号 INT,
  会員名 VARCHAR(100),
  会員種別コード CHAR(2),
  PRIMARY KEY (店舗コード, 会員番号),
  FOREIGN KEY (店舗コード) REFERENCES 店舗(店舗コード),
  FOREIGN KEY (会員種別コード) REFERENCES 会員種別(会員種別コード)
);

FAQ