最終更新日：2026年6月28日

ds data-structure database

DS検定トップ ＞ 第2正規化と第3正規化の違いを整理（候補キーから考える）【DS検定】

まず結論

第2正規化は「候補キーの一部にだけ依存する非キー属性がないか」を確認するもの、第3正規化は「候補キーから非キー属性への推移的な依存がないか」を確認するものです。 DS検定では「どの依存関係がどの正規形違反か」を判断できるかが問われます。

直感的な説明

正規化は「データの重複や矛盾を防ぐ整理ルール」です。

イメージとしては、

  • 第2正規化：
    「セット販売なのに、片方だけで決まる情報が混ざっていないか？」

  • 第3正規化：
    「担当者を通して間接的に決まる情報が、同じ表に入っていないか？」

というチェックです。

たとえば、

学生ID 科目ID 学生名 点数

この表は「学生 × 科目」の成績を表しています。

しかし、

  • 学生ID → 学生名

が成り立つなら、
「学生名」は学生だけで決まる情報です。

このとき、
キーの一部（学生ID）だけで決まる列があるため、第2正規化違反になります。

定義・仕組み

まず候補キーを決める

正規化は、まず候補キーを決めないと始まりません。

候補キーとは：

その表の1行を一意に決められる最小の属性（またはその組）

例：

学生ID 科目ID 点数

この表が「学生 × 科目」の成績なら、

  • 学生IDだけでは1行は決まらない
  • 科目IDだけでも決まらない
  • 学生IDと科目IDの組なら決まる

よって候補キーは：

（学生ID, 科目ID）
＝ 複合候補キー

第2正規化（2NF）

条件：

  1. 第1正規形である
  2. 非キー属性が、候補キーの一部にだけ依存していない

つまり、

複合候補キーの一部 → 非キー属性

があると2NF違反です。

例：

学生ID 科目ID 学生名 点数
  • 候補キー： (学生ID, 科目ID)
  • 学生ID → 学生名

これは「キーの一部依存」
→ 2NF違反

第3正規化（3NF）

条件：

  1. 第2正規形である
  2. 候補キーから非キー属性への推移的関数従属がない

DS検定の基本的な表では、次の形を見つけると判断しやすくなります。

非キー → 非キー

があると3NF違反です。

例：

学生ID 学部ID 学部名
  • 学生IDがキー
  • 学部ID → 学部名

ここで、

  • 学部IDは非キー
  • 学部名も非キー

学生ID → 学部ID → 学部名 → 候補キーから学部名が間接的に決まるため、3NF違反（推移的従属）

※ 厳密な第3正規形には候補キーや主属性を含む条件がありますが、DS検定の基本問題では、まず「キー → 非キー → 非キー」という推移的な依存を見抜けるようにします。

どんな場面で使う？

  • データベース設計
  • マスターデータの整理
  • BIやデータ分析基盤の構築
  • 重複データによる更新ミスの防止

DS検定では、

  • 「この表は第2正規形か？」
  • 「どの依存関係が問題か？」

と問われることが多いです。

計算は出ません。

判断問題です。

よくある誤解・混同

① 候補キーと複合キーの混同

  • 候補キー ＝ 1行を決められるもの
  • 複合キー ＝ 複数列で構成されたキー

「複合キー＝候補キー」ではありません。
複合キーは候補キーの一種です。

② 2NFと3NFを同時に考えてしまう

正しい順番は：

  1. 候補キーを決める
  2. 部分関数従属（2NF）を見る
  3. 推移的従属（3NF）を見る

DS検定では
「いきなり3NFの話をしている選択肢」は要注意です。

③ 列が2つあるから複合キーだと思ってしまう

誤りです。

「1行を決めるのに2つ必要なとき」に複合キーになります。

まとめ（試験直前用）

  • 候補キー＝1行を一意に決める最小属性
  • 2NF＝キーの一部依存を禁止
  • 3NF＝候補キーから非キー属性への推移的従属をなくす
  • 正規化は必ず「キー決定→2NF→3NF」の順
  • DS検定では依存関係の種類を見抜けるかがポイント

対応スキル項目（データエンジニアリング力シート）

  • データベース
  • データベース設計
  • ★ データの正規化の目的と方法を理解している

🔗 関連記事

© 2024-2026 stemtazoo. All rights reserved.