はじめに

データベースを設計するときに必ず話題に出るのは、「正規化」と「非正規化」についてです。
正規化は冗長なデータを排除して一貫性を保つ基本的な手法ですが、実務ではあえて非正規化して冗長にデータを持たせる設計もよく行われます。

この記事では、正規化と非正規化の違いや、それぞれのメリット・デメリットを整理し、どういう状況でどちらを選択すべきかを解説していきます。

正規化とは

正規化とは、データの冗長性を排除し、整合性を保ちやすくするための設計手法。

正規化の段階

第1正規形（1NF）

1つのセルには1つのデータだけを入れるようにする。
（例）電話番号を「tel1, tel2, tel3」と列に持たず、別テーブルに分ける。
（同じ意味の値を「カラムの繰り返し」で表しているから「1セル1値」のルールに反している）
正規化前

customers
---------------------------------------------
id | name   | tel1       | tel2       | tel3
---------------------------------------------
1  | 田中   | 090-xxxx   | 03-xxxx    | NULL

正規化後

customers
------------
id | name
------------
1  | 田中

customer_phones
---------------------------------------------
id | customer_id | phone_type | phone_number
---------------------------------------------
1  | 1           | mobile     | 090-xxxx
2  | 1           | home       | 03-xxxx

【正規化前のデメリット】
①上限が決まってしまう
　「電話番号は3つまで」って勝手に制限がかかる。将来「4つ目」が必要になったらカラム追加という設計変更が必要。
②検索や集計がややこしい
　例えば「03で始まる番号を持つ顧客」を探す時、tel1, tel2, tel3 全部に検索条件を書かなきゃいけない。
③NULLだらけになる
　ほとんどの顧客は電話番号1つだけなのに、tel2, tel3 が常に空欄になる。

第2正規形（2NF）

主キーの一部にしか関係しないデータは別テーブルに移す。
（例）受注テーブル（注文ID＋商品IDがキー）に「顧客住所」を持っていたら分離する。
顧客情報を別テーブルに持っている

orders
--------------------------------
order_id | product_id | address
--------------------------------
1        | A001       | 東京都港区...
2        | B003       | 東京都港区...

正規化後

customers
----------------------
id | name | address
----------------------
1  | 田中 | 東京都港区...

orders
-----------------------------------
order_id | product_id | customer_id
-----------------------------------
1        | A001       | 1
2        | B003       | 1

第3正規形（3NF）

主キーと直接関係のないデータは別テーブルに移す。
（例）社員テーブルに「部署ID」と「部署名」が両方入っていたら、部署名は部署マスタに分ける。

employees
------------------------------------------------------
employee_id | name   | department_id | department_name
------------------------------------------------------
1           | 佐藤   | D01           | 営業部
2           | 鈴木   | D01           | 営業部
3           | 高橋   | D02           | 開発部

正規化後

departments
----------------------
id  | name
----------------------
D01 | 営業部
D02 | 開発部

employees
-------------------------------------
employee_id | name   | department_id
-------------------------------------
1           | 佐藤   | D01
2           | 鈴木   | D01
3           | 高橋   | D02

非正規化とは

非正規化（Denormalization）は、あえて冗長性を持たせる設計のこと。

メリット

過去の状態を保持できる

非正規化は「当時の情報を残す」ためにも有効。
たとえば請求書に「発行当時の住所」や「当時の顧客名」を保存しておけば、後から顧客が引っ越したり改名しても、過去の請求書を正しく再現できる。
単なる冗長ではなく、履歴として意味を持たせる設計。

読み取りが速くなる

JOINを使わずに1つのテーブルだけで情報が完結するため、クエリがシンプルになる。
たとえば「請求書一覧」を出すときに顧客テーブルとJOINしなくても済むので、読み取り速度が向上するケースがある。

集計処理が楽になる

必要な情報が1テーブルにまとまっていると、SUMやCOUNTなどの集計処理をシンプルに書ける。
特に帳票系のシステムでは、非正規化された方がSQLがスッキリし、実装工数も減らせる。

可視化やアウトプット用途に適している

請求書テーブルに「顧客名」を持たせておけば、請求書を生成するときに顧客テーブルと結合する必要がない。
ワンショットで帳票が作れるので、パフォーマンス的にも運用的にも楽になる。

正規化と非正規化の使い分け

正規化と非正規化は「どちらが正しいか」ではなく、「どのような場面だからどっちがいい」で決める。

正規化すべき場面

更新が多く、一貫性を保つことが重要なデータは正規化しておくべき。

更新頻度が高いデータ
　情報が頻繁に変わるなら、冗長に持たない方がミスや不整合を防げる。
整合性が重要なマスタ系
　代表的なのは顧客、商品、契約条件など。
もし冗長に持ってしまうと、1か所を更新し忘れただけでデータが食い違ってしまう。

非正規化すべき場面

一方で、参照や集計が中心で「読み取り性能」や「過去の状態保持」が求められるデータは、非正規化した方がメリットが大きい。

読み取り・集計が圧倒的に多いデータ
　請求書や売上レポート、ダッシュボード用スナップショットなど。
JOINを減らし、SQLをシンプルにできる。

まとめ

正規化が「正しい」とされると思っていましたが、実務では非正規化も重要なことがあることを学びました。
特にSaaSや帳票システムでは、「過去を正しく再現するための冗長性」が重要になると実感しました。