対象試験と出題頻度
正規化は、ITパスポート・基本情報技術者・応用情報技術者のいずれでも出題されるテーマです。
関係データベースの設計分野における最重要トピックであり、「第1正規形・第2正規形・第3正規形の違い」や「与えられた表がどの正規形まで満たしているか」を正確に判断できるかが問われます。
詳細をクリックして確認
ITパスポート
基本情報技術者
応用情報技術者
★★★★★
ランクS（超重要）絶対に覚える必要あり
用語の定義
情報処理試験を勉強していると、「正規化って聞いたことはあるけど、第1・第2・第3って何が違うの？」と混乱しがちです。
正規化（Normalization）とは、一言で言うと
「関係データベースの表からデータの重複や矛盾を取り除くために、段階的に表を分解していく設計手法」
のことです。
イメージとしては、「ぐちゃぐちゃの引き出しを、種類ごとに仕切って整理する作業」です。
文房具も書類もお菓子も全部1つの引き出しに入っていると、同じペンを2本買ってしまったり、書類がお菓子の下に埋もれて見つからなかったりします。仕切りを入れて種類ごとに分ければ、重複も紛失も防げます。
正規化もまったく同じで、1つの大きな表に何でも詰め込んだ状態を、ルールに従って段階的に分割して整理する作業です。
📊 正規化の基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Normalization |
| 目的 | データの重複排除・更新時異状の防止 |
| 段階 | 第1正規形 → 第2正規形 → 第3正規形（IPA試験範囲は第3まで） |
| キーワード | 繰り返し属性、部分関数従属、推移的関数従属 |
解説
データベースを設計する際、最初はすべての情報を1枚の表にまとめがちです。しかし、1枚の表に情報を詰め込むと「同じ商品名を100行に重複して書く」「1か所だけ商品名を変更し忘れて矛盾が生まれる」といった問題（更新時異状）が発生します。
この問題を防ぐために、表を段階的に分割して無駄のない構造へ変換するのが正規化です。IPA試験の範囲では第3正規形までを扱います。
ボイスコッド正規形（BCNF）や第4・第5正規形は試験では深掘りされないため、ここでは割愛します。
正規化の全体像（3ステップ一覧）
正規化は「非正規形 → 第1正規形 → 第2正規形 → 第3正規形」の順で進めます。
各ステップで排除する対象が異なるため、それぞれの違いを正確に押さえることが理解の土台です。
| 正規形 | 条件（何を排除するか） | 覚え方キーワード |
|---|---|---|
| 第1正規形 | すべての属性値が単一値（繰り返し属性の排除） | 「1セル1値」 |
| 第2正規形 | 主キーの一部で決まる属性を別表に分離（部分関数従属の排除） | 「主キーの”一部”に依存するな」 |
| 第3正規形 | 主キー以外の属性で決まる属性を別表に分離（推移的関数従属の排除） | 「主キー以外にも依存するな」 |
ここからは、同じ受注データを題材にして、非正規形 → 第1 → 第2 → 第3正規形へ段階的に変換する流れを追いかけます。各ステップで「変換前の問題点」と「変換後に解決されたこと」をセットで確認してください。
STEP 0：非正規形（出発点）
▼ 非正規形の受注データ表
| 受注番号 | 顧客コード | 顧客名 | 商品番号 | 商品名 | 数量 |
|---|---|---|---|---|---|
| 001 | C01 | 田中 | S01, S02 | ペン, ノート | 3, 5 |
| 002 | C02 | 佐藤 | S01, S03 | ペン, 消しゴム | 2, 4 |
⚠ 問題点：商品番号・商品名・数量の列に複数の値がカンマ区切りで入っている。これでは「S01の数量だけ取り出す」といった操作ができず、データベースとして機能しない。
まずは正規化する前の「何も整理されていない状態」を確認します。
ある文房具通販サイトの受注データを1枚の表にまとめたものです。
STEP 1：第1正規化（繰り返しをなくす）
第1正規化でやることはシンプルです。「1つのセルには1つの値だけ」にします。
上の表では商品番号・商品名・数量にカンマ区切りで複数の値が詰め込まれていたので、これを1行1商品に展開します。
▼ 第1正規化後（第1正規形）
下線＝主キー
| 受注番号 | 顧客コード | 顧客名 | 商品番号 | 商品名 | 数量 |
|---|---|---|---|---|---|
| 001 | C01 | 田中 | S01 | ペン | 3 |
| 001 | C01 | 田中 | S02 | ノート | 5 |
| 002 | C02 | 佐藤 | S01 | ペン | 2 |
| 002 | C02 | 佐藤 | S03 | 消しゴム | 4 |
✔ 解決したこと：1セル1値になり、各行が1つの受注明細を表すようになった。主キーは「受注番号＋商品番号」の複合主キー。
⚠ まだ残っている問題：「田中」「ペン」など同じデータが複数行に重複している。「ペン」の商品名を変更したい場合、該当する全行を修正しなければならない。
STEP 2：第2正規化（部分関数従属をなくす）
第2正規化では、「複合主キーの一部だけで決まってしまう属性」を見つけて別表に切り出します。この「主キーの全部ではなく一部で値が決まる関係」を部分関数従属と呼びます。
先ほどの第1正規形の表を見直すと、主キーは「受注番号＋商品番号」の2列です。
ここで各属性が主キーのどの部分に依存しているかを整理します。
▼ 部分関数従属の発見（第1正規形の表を分析）
| 属性 | 何で決まるか | 判定 |
|---|---|---|
| 数量 | 受注番号＋商品番号（主キー全体） | ✔ 完全関数従属（OK） |
| 顧客コード | 受注番号だけ（主キーの一部） | ⚠ 部分関数従属（分離対象） |
| 顧客名 | 受注番号だけ（主キーの一部） | ⚠ 部分関数従属（分離対象） |
| 商品名 | 商品番号だけ（主キーの一部） | ⚠ 部分関数従属（分離対象） |
主キーの「一部」だけで決まる属性を、それぞれ依存先の属性をキーとする別表に分離します。
▼ 第2正規化後（第2正規形）＝ 3つの表に分離
受注明細テーブル
| 受注番号 | 商品番号 | 数量 |
|---|---|---|
| 001 | S01 | 3 |
| 001 | S02 | 5 |
| 002 | S01 | 2 |
| 002 | S03 | 4 |
主キー全体で決まる「数量」だけ残る
受注テーブル
| 受注番号 | 顧客コード | 顧客名 |
|---|---|---|
| 001 | C01 | 田中 |
| 002 | C02 | 佐藤 |
「受注番号」だけで決まる属性を集約
商品テーブル
| 商品番号 | 商品名 |
|---|---|
| S01 | ペン |
| S02 | ノート |
| S03 | 消しゴム |
「商品番号」だけで決まる属性を集約
✔ 解決したこと：「ペン」の商品名は商品テーブルの1行だけに存在するので、商品名を変更する際に1か所を直すだけで済む。「田中」も受注テーブルの1行だけに集約された。
⚠ まだ残っている問題：受注テーブルの中に「顧客コード → 顧客名」という、主キー（受注番号）を経由した間接的な依存が残っている。同じ顧客が何度も注文すると、顧客名が受注テーブルの複数行に重複する。
STEP 3：第3正規化（推移的関数従属をなくす）
第3正規化では、「主キー以外の属性が、さらに別の属性の値を決めている関係」を見つけて別表に切り出します。
この間接的な依存の連鎖を推移的関数従属と呼びます。
先ほど分離した受注テーブルを見直します。主キーは「受注番号」の単一属性です。
▼ 推移的関数従属の発見（受注テーブルを分析）
| 受注番号 | 顧客コード | 顧客名 |
|---|---|---|
| 001 | C01 | 田中 |
| 002 | C02 | 佐藤 |
| 003 | C01 | 田中 |
受注番号 → 顧客コード → 顧客名
（受注番号が決まれば顧客コードが決まり、顧客コードが決まれば顧客名が決まる）
⚠ 問題点：田中さん（C01）が2回注文すると、「田中」という顧客名が受注テーブルの2行に重複する。田中さんが結婚して姓が変わった場合、該当行をすべて修正しなければ矛盾が生じる。
▼ 第3正規化後（第3正規形）＝ 受注テーブルをさらに2つに分離
受注テーブル（分離後）
| 受注番号 | 顧客コード |
|---|---|
| 001 | C01 |
| 002 | C02 |
| 003 | C01 |
顧客コードは外部キーとして残す
顧客テーブル（新規分離）
| 顧客コード | 顧客名 |
|---|---|
| C01 | 田中 |
| C02 | 佐藤 |
「田中」は1行だけ → 重複ゼロ
✔ 解決したこと：顧客名は顧客テーブルの1行だけに存在するようになった。田中さんが何回注文しても、顧客名の重複は発生しない。姓の変更も1か所を修正するだけで全体に反映される。
最終形：第3正規形の全体像
ここまでの3ステップを経て、最初の1枚の表は4つのテーブルに分離されました。
最終的な構成を一覧で確認します。
▼ 第3正規形（完成形）：4つのテーブル
受注明細
(受注番号, 商品番号, 数量)
受注
(受注番号, 顧客コード)
顧客
(顧客コード, 顧客名)
商品
(商品番号, 商品名)
下線＝主キー ／ テーブル間は主キーと外部キーで結合して元のデータを復元できる
フローチャート：正規化の判断手順
「この表はどこまで正規化されているか？」を判定する際は、以下の順番でチェックします。
正規形の判定フローチャート
すべてのセルが単一値か？
第1正規形 ✔
部分関数従属はないか？
（主キーの一部で決まる属性がないか）
第2正規形 ✔
推移的関数従属はないか？
（主キー以外の属性で決まる属性がないか）
第3正規形 ✔（完了）
関数従属の3パターンまとめ
各正規形で排除する「依存関係」の違いを矢印で整理します。ここだけは確実に押さえてください。
関数従属の3パターン
完全関数従属
{受注番号, 商品番号}
↓ 両方揃って決まる
数量
→ 問題なし（そのまま）
部分関数従属
商品番号（主キーの一部）
↓ 一部だけで決まる
商品名
→ 第2正規化で排除
推移的関数従属
受注番号 → 顧客コード
→ 顧客名
→ 第3正規化で排除
正規化しないとどうなるか（更新時異状）
表を分割せずに放置すると、次の3種類の異状が起きます。
| 異状の種類 | 具体例 |
|---|---|
| 修正時異状 | 商品名を変更したいのに、100行すべてを直さないと整合性が崩れる |
| 挿入時異状 | まだ注文されていない新商品を登録できない（受注番号がないため行が作れない） |
| 削除時異状 | ある受注を取り消すと、その受注にしか紐づいていない商品情報まで消えてしまう |
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 正規化の核心を3行で
・第1正規形：繰り返し属性をなくして「1セル1値」にする
・第2正規形：主キーの一部で決まる属性を別表に分離する（部分関数従属の排除）
・第3正規形：主キー以外の属性で決まる属性を別表に分離する（推移的関数従属の排除）
試験ではこう出る！
正規化は、IP・FE・APのいずれでも繰り返し出題されている最頻出テーマです。出題パターンは大きく3つに分かれます。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| IP R6 問81 |
受注データ表を正規化した結果の表の組合せを選ぶ問題。 | ・商品番号で一意に決まる商品名・単価を別表に分離できるか ・外部キーの残し方を理解しているか |
| FE R6 問19 |
発注伝票表を第3正規形に書き換えたものを選ぶ問題。 | ・複合主キーからの部分関数従属を正しく分離できるか ・外部キーとして元の表に属性を残す点 |
| AP R7春 午前 問26 |
第2正規形から第3正規形に変換する手順を選ぶ問題。 | ・「候補キー以外の属性間の関数従属性を分解する」が正解 ・第1・第2正規化やBCNFの手順がひっかけ |
| AP R3秋 午前 問28 |
受注表がどの正規形まで満たしているか判定する問題。 | ・主キーを特定し、部分関数従属の有無を判断する力 ・「第1正規形だが第2正規形ではない」の判定 |
| AP H30秋 午前 問28 |
第1・第2・第3正規形と特徴a～cの正しい組合せを選ぶ問題。 | ・各正規形の定義文を正確に対応づけられるか ・R4春 問28でも同一問題が再出題 |
📝 IPA試験での出題パターン
パターン1：「正規化した結果の表を選べ」（IP・FE）
具体的な表が提示され、正規化後の表の組合せを4択から選ぶ形式。主キーの特定 → 部分関数従属の発見 → 推移的関数従属の発見を手順通りに実行できるかが勝負。
パターン2：「この表はどの正規形か」（AP）
表を見て「第1正規形だが第2正規形ではない」などを判定する形式。ひっかけは、主キーが単一属性の場合に「部分関数従属が存在しない＝自動的に第2正規形」となる点を見落とすパターン。
パターン3：「正規化の手順を選べ」（AP）
各正規形の定義文を正しく対応づける問題。「繰り返し属性の排除」「部分関数従属の排除」「推移的関数従属の排除」の3つの定義文を丸暗記しておけば即答できます。
試験ではここまででOKです。ボイスコッド正規形以降は出題されても選択肢レベルなので、深追いは不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. 関係データベースにおいて、第2正規形から第3正規形へ変換するために排除すべき依存関係はどれでしょうか？
- A. 1つのセルに複数の値が格納されている状態（繰り返し属性）を排除する。
- B. 複合主キーの一部の属性だけで非キー属性の値が決まる関係（部分関数従属）を排除する。
- C. 主キー以外の属性が別の非キー属性の値を決定する関係（推移的関数従属）を排除する。
正解と解説を見る
正解：C
解説：
第3正規化とは、第2正規形の表に残っている推移的関数従属（主キー → 非キー属性A → 非キー属性B という間接的な依存の連鎖）を解消し、非キー属性が主キーにのみ直接依存する状態を作る手順です。AP R7春 午前問26でも同じ観点が出題されています。
選択肢Aは第1正規化の説明です。繰り返し属性をなくし「1セル1値」にする手順であり、第3正規化とは段階が異なります。選択肢Bは第2正規化の説明です。複合主キーの一部への依存を別表に分離する手順であり、第2→第3の変換で行う作業ではありません。
よくある質問（FAQ）
Q. 主キーが単一属性（1列だけ）の場合、第2正規化は不要ですか？
不要です。部分関数従属は「複合主キーの一部で非キー属性が決まる」状態を指すため、主キーが1列だけの場合は「一部」が存在しません。そのため、第1正規形の条件を満たしていれば自動的に第2正規形も満たします。IP R6 問81の受注データ表がまさにこのケースで、主キーが「受注番号」の単一属性であるため、第2正規化をスキップして第3正規化に進んでいます。
Q. 正規化しすぎるとデメリットはありますか？
あります。表を細かく分割するほどデータの結合（JOIN）が増え、検索速度が低下します。実務では、あえて正規化を崩して冗長なデータを持たせる「非正規化（デノーマライゼーション）」を行うこともあります。参照頻度が高く更新頻度が低いマスタ情報を結合済みの状態で保持するケースが典型です。ただし、IPA試験では「正規化＝望ましい」という前提で出題されるため、非正規化のメリットを深く問われることはありません。
Q. 「関数従属」が苦手です。簡単な覚え方はありますか？
「Aが決まればBが1つに決まる」という関係を A → B と表記したものが関数従属です。例えば「社員番号 → 社員名」は、社員番号を決めれば社員名が1つに定まるので関数従属です。逆に「社員名 → 社員番号」は、同姓同名がいれば成り立たないため関数従属とは限りません。「左側が決まれば右側が1つに決まる」と覚えれば十分です。
Q. ボイスコッド正規形（BCNF）とは何ですか？
第3正規形をさらに強化した正規形です。第3正規形では「非キー属性間の推移的関数従属」を排除しますが、BCNFでは「候補キーの一部から他の属性への関数従属」も排除します。データベーススペシャリスト試験の午前IIで選択肢として登場することがありますが、ITパスポート・基本情報・応用情報の範囲では「第3正規形の上位にある」と知っておけば十分です。
