■ この記事はこんな人におすすめ

SQLを書き始めて、JOINを多用するようになってきた人
「正規化って本当に正しいの？」と疑問を感じたことがある人
パフォーマンスチューニングに興味がある初・中級エンジニア
非正規化という言葉は聞いたことあるけど、具体的にどんなものかわからない人

■ この記事で得られること

正規化がパフォーマンスに与える影響が理解できます
非正規化のパターンと、それぞれのトレードオフが判断できるようになります
正規化と非正規化を「使い分ける」判断軸が持てるようになります

■ 参考書籍

達人に学ぶDB設計徹底指南書第2版

本記事は上記書籍の5章の内容をもとに構成しています。

1. 結論

正規化は原則として正しい選択です。ただし、パフォーマンス上の限界に達したとき、非正規化は有効な「最後の手段」になります。

正規化されたテーブルは、データの整合性を保ちやすく、更新の手間も少ない。しかしJOINが増えるほど、クエリのコストは上がっていきます。非正規化はその問題を解決できる一方で、「更新コストの増大」と「データのリアルタイム性の低下」という2つのリスクを抱えます。

この記事では、具体的なSQL例を通じてその仕組みを理解していきましょう！

2. まずは下記を理解しよう！

■ ① 正規化がパフォーマンスに影響するケースを把握する

JOINの回数・種類によって、パフォーマンスへの影響度が変わります。

以下のテーブル構成を例に考えます：

会社テーブル

会社コード	会社名
C0001	A 商事
C0002	B 化学
C0003	C 建設

社員テーブル

会社コード	社員ID	社員名	年齢	部署コード
C0001	E0001	加藤	40	D01
C0001	E0002	藤本	32	D02
C0002	E0002	田島	25	D01

部署テーブル

部署コード	部署名
D01	開発
D02	人事
D03	営業

■ ② パターン別にJOINのコストを比較する 🔍

【パターン1】テーブル2つを内部結合

-- 会社名と社員名を取得
SELECT 会社.会社名, 社員.社員名
FROM 社員
INNER JOIN 会社 ON 会社.会社コード = 社員.会社コード
WHERE 社員.社員名 = '田島';

【パターン2】テーブル3つを内部結合

-- 会社名・社員名・部署名を取得
SELECT 会社.会社名, 社員.社員名, 部署.部署名
FROM 社員
INNER JOIN 会社 ON 会社.会社コード = 社員.会社コード
INNER JOIN 部署 ON 社員.部署コード = 部署.部署コード
WHERE 社員.社員名 = '田島';

【パターン3】外部結合で集計

-- 会社ごとの社員数を集計（社員がいない会社もNULLで表示）
SELECT 会社.会社コード, COUNT(社員.社員名) AS 社員数
FROM 会社
LEFT OUTER JOIN 社員 ON 社員.会社コード = 会社.会社コード
GROUP BY 会社.会社コード;

✅ パターン1〜3は、適切なインデックスが設定されていれば、パフォーマンス差はほぼ誤差レベルです。

■ ③ 非正規化で結合をゼロにするパターンを知る

【パターン4】非正規化テーブル（JOINなし）

会社名・部署名を社員テーブルに持たせてしまう設計です。

会社コード	会社名	社員ID	社員名	年齢	部署コード	部署名
C0001	A 商事	E0001	加藤	40	D01	開発
C0001	A 商事	E0002	藤本	32	D02	人事
C0002	B 化学	E0002	田島	25	D01	開発

-- JOINなしで取得できる ✨
SELECT 会社名, 社員名, 部署名
FROM 社員
WHERE 社員名 = '田島';

このパターンは明らかに速いです。ただし、後述するリスクとのトレードオフがあります⚠️

■ ④ 非正規化の2パターン（実務でよく使う）を理解する

受注テーブルと受注明細テーブルを使った例で考えます。

受注テーブル

受注ID	受注日	注文者名義
0001	2026-01-05	岡野徹
0002	2026-01-06	浜田健一
0003	2026-01-08	石井慶子

受注明細テーブル

受注ID	受注明細連番	商品名
0001	1	マカロン
0001	2	紅茶
0002	1	紅茶
0002	2	日本茶

📅 非正規化パターンA：明細テーブルに「受注日」を持たせる

受注日での範囲絞り込みを高速化したいとき、受注明細に受注日カラムを追加します。

受注ID	受注明細連番	商品名	受注日
0001	1	マカロン	2026-01-05
0001	2	紅茶	2026-01-05
0002	1	紅茶	2026-01-06

➡️ JOINなしで WHERE 受注日 BETWEEN '...' AND '...' が実行できます。

🔢 非正規化パターンB：受注テーブルに「商品数（集計値）」を持たせる

受注日別の集計を高速化したいとき、受注テーブルに商品数カラムを追加します。

受注ID	受注日	注文者名義	商品数
0001	2026-01-05	岡野徹	4
0002	2026-01-06	浜田健一	3
0003	2026-01-08	石井慶子	1

➡️ GROUP BY不要で集計結果が即座に取れます。

■ ⑤ 非正規化の「2つのリスク」を認識する

非正規化には必ず以下のコストが伴います。導入前に必ず評価してください。

🔴 リスク1：更新パフォーマンスの低下

会社名が変わった場合 → 全社員レコードの「会社名」カラムを一括更新する必要がある
商品が追加・削除された場合 → 受注テーブルの「商品数」も更新が必要になる

🔴 リスク2：データのリアルタイム性の低下

集計値（商品数など）を都度更新すると、DBへの書き込み負荷が増える
更新頻度を下げると、集計値が実態とずれる（リアルタイム性が失われる）

3. 各項目の説明

■ なぜパターン1〜3のパフォーマンス差は誤差レベルなのか？

JOINは「インデックスさえ適切に設定されていれば」、DBエンジンが効率的に処理します。会社コードや部署コードに対してインデックスが貼られていれば、結合対象の絞り込みは非常に高速に動作します。

2〜3テーブルのJOINが問題になるのは、インデックス設計が不十分な場合や、結合結果が非常に大きくなる場合（例：数百万件同士のJOIN）です。

■ パターン4（非正規化）はなぜ速いのか？

結合処理そのものが不要になるからです。1テーブルへのシンプルなSELECTは、複数テーブルを組み合わせる処理と比べてオーバーヘッドが少なく、クエリプランも単純になります。特に読み取り頻度が非常に高く、更新が少ないケースで効果を発揮します。

■ 非正規化を採用すべき判断基準

以下の条件が揃ったとき、非正規化を検討する価値があります：

✅ 正規化＋インデックス最適化を行っても、パフォーマンスが要件を満たせない
✅ 対象のデータが読み取り頻度が高く、更新頻度が低い
✅ データの不整合リスクをアプリケーション側でコントロールできる

逆に、更新が頻繁なデータに非正規化を適用すると、更新コストと不整合リスクが膨らみ、正規化以上のパフォーマンス問題を引き起こすことがあります🚨

まとめ

正規化によるJOINのパフォーマンス低下は、インデックスが適切なら誤差レベル
非正規化（JOINなし）は明確に速いが、トレードオフがある
非正規化の2つのリスク：①更新コストの増大 と ②リアルタイム性の低下
非正規化の代表パターン：関連カラムをテーブルに持たせる / 集計値をテーブルに持たせる
原則は正規化。非正規化はパフォーマンスチューニングの最後の手段 🏁

結局何をすればいいの❓

🏗️ まず正規化を徹底する（第3正規形を目指す）
🔑 インデックスを適切に設計する（結合キー・検索条件カラムを中心に）
📊 パフォーマンス計測を行う（EXPLAINでクエリプランを確認）
🔧 それでも不足なら非正規化を検討（影響範囲・更新頻度を必ず評価する）
🔒 非正規化導入後は更新処理の整合性担保を忘れずに

株式会社シンシア

株式会社xincereでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。

※ シンシアにおける働き方の様子はこちら

シンシアでは、年間100人程度の実務未経験の方が応募し技術面接を受けます。
その経験を通し、実務未経験者の方にぜひ身につけて欲しい技術力（文法）をここでは紹介していきます。