USQLの学習を終えてふと思ったのが、「そもそもテーブルってどうやって設計するんだろう」という疑問でした。「注文テーブルに商品情報も全部入れればいいんじゃないか」と最初は考えていたのですが、それが「更新異常」という問題の原因になると知って、正規化の必要性がすっと腑に落ちた気がします。
データベース正規化は、「テーブル設計の原則」を定めたルールです。第1正規形・第2正規形・第3正規形という3段階で、データの冗長性を取り除き、更新したときに矛盾が生じないテーブル構造に整えていきます。経営情報システム科目では、各正規形の定義と変換手順、ER図の読み方がよく問われます。通販サイトの注文データを例に、順を追って整理してみましょう。
データベースと正規化とは
まず「なぜ正規化が必要なのか」という前提を押さえておきます。正規化の目的は、データの冗長性をなくし、更新異常を防ぐことにあります。
第1正規形（1NF）｜繰り返し項目を排除する
第1正規形の条件は、「すべての列の値が1つの値（原子値）であること」です。1つのセルに複数の値が入っていたり、同じ意味の列が横に並んでいる（繰り返し項目）ものは、1NFに違反しています。
| 受注番号 | 顧客名 | 商品1 | 商品2 | 数量1 | 数量2 |
|---|---|---|---|---|---|
| 1001 | 山田花子 | ノート | ペン | 3 | 5 |
| 1002 | 鈴木一郎 | 消しゴム | 2 | ||
| 1003 | 佐藤美咲 | ノート | 定規 | 1 | 2 |
⚠ 「商品1」「商品2」という繰り返し列がある。商品が3つになったら列を追加しなければならない。
| 受注番号 | 顧客名 | 商品名 | 数量 |
|---|---|---|---|
| 1001 | 山田花子 | ノート | 3 |
| 1001 | 山田花子 | ペン | 5 |
| 1002 | 鈴木一郎 | 消しゴム | 2 |
| 1003 | 佐藤美咲 | ノート | 1 |
| 1003 | 佐藤美咲 | 定規 | 2 |
✔ 繰り返しをなくし、1行1商品に変換。主キーは「受注番号＋商品名」の複合キーになる。
第2正規形（2NF）｜部分関数従属を排除する
第2正規形の条件は、「すべての非キー属性が、主キー全体に完全関数従属していること」です。複合主キーの一部だけで決まる属性（部分関数従属）を別テーブルに分離します。
第2正規形の条件：1NFを満たし、かつ部分関数従属がない状態。
| 受注番号 | 商品名 | 顧客名 | 単価 | 数量 |
|---|---|---|---|---|
| 1001 | ノート | 山田花子 | 120円 | 3 |
| 1001 | ペン | 山田花子 | 80円 | 5 |
| 1002 | 消しゴム | 鈴木一郎 | 60円 | 2 |
| 1003 | ノート | 佐藤美咲 | 120円 | 1 |
⚠ 「顧客名」は受注番号だけで決まる（部分従属）。「単価」は商品名だけで決まる（部分従属）。ノートの単価を変更すると全行を修正しなければならない（更新異常）。
受注テーブル
| 受注番号（PK） | 顧客名 |
|---|---|
| 1001 | 山田花子 |
| 1002 | 鈴木一郎 |
| 1003 | 佐藤美咲 |
商品テーブル
| 商品名（PK） | 単価 |
|---|---|
| ノート | 120円 |
| ペン | 80円 |
| 消しゴム | 60円 |
受注明細テーブル
| 受注番号（PK,FK） | 商品名（PK,FK） | 数量 |
|---|---|---|
| 1001 | ノート | 3 |
| 1001 | ペン | 5 |
| 1002 | 消しゴム | 2 |
| 1003 | ノート | 1 |
✔ 部分従属をなくし、主キー全体に完全従属する属性だけを各テーブルに残した。
U「部分関数従属」と「完全関数従属」の違いは、複合主キーの文脈で初めて意味を持ちます。主キーが1列だけのテーブルでは、部分従属は定義上起こりえません。だから2NFの問題は「複合主キーがあるかどうか」を最初に確認するのが近道だと思いました。
第3正規形（3NF）｜推移的関数従属を排除する
第3正規形の条件は、「非キー属性が主キーに直接従属しており、他の非キー属性を経由した推移的従属がないこと」です。「AがBを決め、BがCを決める」という連鎖がある場合、BとCを別テーブルに切り出します。
第3正規形の条件：2NFを満たし、かつ推移的関数従属がない状態。
| 受注番号（PK） | 顧客ID | 顧客名 | 顧客住所 |
|---|---|---|---|
| 1001 | C01 | 山田花子 | 東京都渋谷区 |
| 1002 | C02 | 鈴木一郎 | 大阪府中央区 |
| 1003 | C01 | 山田花子 | 東京都渋谷区 |
| 1004 | C02 | 鈴木一郎 | 大阪府中央区 |
⚠ 受注番号→顧客ID→顧客名・顧客住所という推移的従属がある。山田さんの住所が変わると全行を修正しなければならない。
受注テーブル
| 受注番号（PK） | 顧客ID（FK） |
|---|---|
| 1001 | C01 |
| 1002 | C02 |
| 1003 | C01 |
| 1004 | C02 |
顧客テーブル
| 顧客ID（PK） | 顧客名 | 顧客住所 |
|---|---|---|
| C01 | 山田花子 | 東京都渋谷区 |
| C02 | 鈴木一郎 | 大阪府中央区 |
✔ 顧客情報を顧客テーブルに分離。住所変更は顧客テーブルの1行を更新するだけで済む。
2NF：複合主キーの一部にしか従属しない列を別テーブルへ（部分従属の排除）
3NF：非キー属性を経由した連鎖的従属を別テーブルへ（推移的従属の排除）
ER図（実体関連図）の読み方
ER図（Entity-Relationship Diagram）は、テーブル同士の関係を視覚的に表した図です。試験では、ER図からテーブル構造を読み取る問題や、カーディナリティ（多重度）の識別が問われます。
| カーディナリティ | 説明 | 例 | テーブル設計上の扱い |
|---|---|---|---|
| 1 対 1 | 一方の1件がもう一方の1件に対応 | 社員 対 社員証 | 同じテーブルにまとめることも可 |
| 1 対 多 | 一方の1件がもう一方の複数件に対応 | 顧客 対 注文、部門 対 社員 | 多側のテーブルに外部キーを持つ |
| 多 対 多 | 双方が複数件に対応しうる | 注文 対 商品、学生 対 授業 | 中間テーブル（関連エンティティ）で分解必須 |
主キー・外部キー・ACID特性
テーブル設計の補足知識として、キーの概念とトランザクション管理の原則を整理しておきます。試験では用語の定義と組み合わせ問題がよく出ます。
| 用語 | 定義 | 特徴・制約 |
|---|---|---|
| 主キー（PK） | 行を一意に識別する列（または列の組み合わせ） | 重複不可・NULL不可・1テーブルに1つ |
| 候補キー | 主キーとして使える列の候補 | 一意性と最小性を満たす列の組 |
| 外部キー（FK） | 他テーブルの主キーを参照する列 | 参照先に存在する値しか入れられない（参照整合性） |
| 複合キー | 2列以上の組み合わせで主キーとなる | 1NF→2NF変換で重要な概念 |
| 代理キー | 自然キーの代わりに人工的に付与するID | 自動採番のシーケンスID等 |
ロールバック（ROLLBACK）：エラー発生時に処理前の状態に戻す命令。
銀行振込を例にすると「A口座から引き落とし→B口座へ入金」の2処理はひとつのトランザクション。途中でシステム障害が起きても、ロールバックによって引き落とし前の状態に戻る（原子性）。
UACIDは頭文字で覚えると試験中に思い出しやすいです。「Atomicity＝切り離せない・Consistency＝矛盾しない・Isolation＝お互いに干渉しない・Durability＝消えない」という意味合いで覚えておくと、定義の問題にも対応できると思います。
過去問で確認する
実際の試験でどのような形式で問われるか、過去問をベースにした練習問題で確認しておきましょう。
受注テーブル（受注番号, 商品コード, 商品名, 顧客ID, 数量）
※ 主キーは「受注番号＋商品コード」の複合キー
- ア このテーブルは第3正規形を満たしている
- イ 「商品名」は主キーの一部（商品コード）にのみ従属しているため、第2正規形に違反している
- ウ 「顧客ID」は主キー全体に完全関数従属しているため問題ない
- エ このテーブルは第1正規形を満たしていない
ウの「顧客ID」は受注番号だけで決まる可能性があり、これも部分従属で2NF違反になります。 エについて、繰り返し項目がなく原子値の条件は満たしているため1NF違反ではありません。
- ア 原子性（Atomicity）
- イ 一貫性（Consistency）
- ウ 独立性（Isolation）
- エ 永続性（Durability）
ア（原子性）は「全部成功か全部失敗か」。イ（一貫性）は「データの整合性制約が保たれること」。エ（永続性）は「コミット後のデータが消えないこと」です。4つの特性それぞれの内容をしっかり区別しておきましょう。
- ア 注文と商品は1対1の関係であるため、注文テーブルに商品IDを外部キーとして持てばよい
- イ 注文と商品は1対多の関係であるため、商品テーブルに注文番号を外部キーとして持てばよい
- ウ 注文と商品は多対多の関係であるため、注文明細テーブルを中間テーブルとして設け、注文番号と商品IDを外部キーとして持たせる必要がある
- エ 注文と商品は多対多の関係であるため、注文テーブルと商品テーブルを1つに統合する
まとめ
- 正規化の目的は冗長性の排除と更新異常（挿入・削除・更新）の防止
- 第1正規形（1NF）：繰り返し項目をなくし、各セルが原子値（1つの値）になる状態
- 第2正規形（2NF）：複合主キーの一部だけに従属する列（部分従属）を別テーブルに分離
- 第3正規形（3NF）：非キー属性経由の連鎖従属（推移的従属）を別テーブルに分離
- ER図では「エンティティ・属性・リレーションシップ・カーディナリティ」の4要素を読む
- 多対多の関係は中間テーブルを設けて分解しなければRDBで表現できない
- 主キーは一意性とNOT NULL制約。外部キーは参照先に存在する値のみ許容（参照整合性）
- ACID特性：Atomicity（原子性）・Consistency（一貫性）・Isolation（独立性）・Durability（永続性）
