正規化

なぜ必要？ — 重複が生む「更新異常」

たとえば1枚の表に、注文・顧客・商品をぜんぶ詰め込んだとします。

注文ID	顧客名	顧客住所	商品名	単価
1	田中	東京都…	ノートPC	120000
2	田中	東京都…	マウス	3000

「田中」の住所が2行にコピーされています。この重複が、3つの異常を引き起こします。

• 更新異常: 田中の住所変更で、片方の行だけ直すと食い違う。
• 挿入異常: まだ注文のない新商品を、注文行なしでは登録できない。
• 削除異常: 最後の注文を消すと、その顧客や商品の情報まで消えてしまう。

正規化は、これらを設計の段階で起きないようにする作業です。

道具：主キーと外部キー

正規化は「テーブルを分けて、関連で結び直す」作業なので、2つのキーが土台になります。

外部キーには参照整合性（存在しない顧客IDの注文は作れない、等）を DB に守らせる役割もあります。詳しくはテーブルの結合（JOIN）で、分けたテーブルを再びつなぐ方法を扱います。

第1〜第3正規形をやさしく

実務でまず目指すのは第3正規形（3NF）まで。段階的に条件が積み重なります。

1NF：1つのセルに1つの値

タグ 列に "赤, 大, 限定" のようにカンマ区切りで詰めるのは 1NF 違反。検索も集計も難しくなります。値を1つにし、複数あるなら別テーブルに切り出します。

2NF：主キー全体で決まるようにする

主キーが (注文ID, 商品ID) の複合キーなのに、商品名 が 商品ID だけで決まる場合、これは「部分従属」。商品名は商品テーブルへ移します。

3NF：芋づる式の依存を断つ

顧客ID（主キー）→ 郵便番号 → 住所 のように、主キー以外の列を経由して決まる関係（推移従属）も分離します。郵便番号と住所の対応は別テーブルへ。

-- 3NF へ分割した例：事実が1か所だけになる
CREATE TABLE customers (
  customer_id INT PRIMARY KEY,        -- 主キー
  name        TEXT NOT NULL,
  address     TEXT NOT NULL           -- 顧客の住所はここ“だけ”
);

CREATE TABLE orders (
  order_id    INT PRIMARY KEY,
  customer_id INT NOT NULL REFERENCES customers(customer_id),  -- 外部キー
  ordered_at  TIMESTAMP NOT NULL DEFAULT now()
);

住所は customers の1行だけ。引っ越しても1か所直せば全注文に反映され、食い違いが起きません。

覚え方

非正規化：あえて重複させる

正規化を進めると、表示のたびに多くのテーブルを JOIN する必要が出て、読み取りが遅くなることがあります。そこで意図的に重複を持たせて速度を取るのが非正規化です。

具体例としては、注文表に「単価×数量」を毎回計算せず 合計金額 列を持たせる、集計済みのサマリーテーブルを別に用意する、などがあります。

どこまでやる？

• 多くの業務システムでは 3NF を基本に、表示が重い箇所だけ非正規化、が現実的なバランス。
• 一方、NoSQL（RDB との違い）では、結合を避けるためあえて非正規化（埋め込み）を前提に設計することも多い。正規化は“常に正義”ではなく、更新と読み取りのどちらを重く見るかで選ぶ設計判断です。