非正規化 ひせいきか
冗長性パフォーマンスJOIN削減読み取り最適化トレードオフテーブル設計
非正規化について教えて
簡単に言うとこんな感じ！
非正規化は「わざと同じデータを重複させてJOINを減らす」設計手法だよ！正規化でスッキリ整理したDBは「書き込みの正確さ」は優れてるけど、複数テーブルをJOINしまくると読み取りが遅くなることがある。そこであえて同じ値をあちこちに持たせて、1テーブルだけで完結させるんだ！速さと整合性のトレードオフなんだよ！
非正規化とは
非正規化（Denormalization）とは、正規化されたデータベース設計において、意図的に冗長性（重複データ）を導入することで、クエリのパフォーマンスを向上させる設計手法です。正規化の「無駄をなくす」という原則とは逆方向のアプローチです。
正規化を徹底するとデータの重複がなく整合性は高まりますが、情報を取得するには多数のテーブルをJOINする必要があり、テーブルが増えるほど処理が遅くなります。特に「注文一覧に商品名・顧客名・担当者名を一度に表示」するような画面では、5〜10テーブルのJOINが発生することもあります。
非正規化では、よく一緒に使われるデータをあらかじめ1テーブルに格納したり、集計値をカラムとして追加したりします。これによりJOIN不要の高速な読み取りが可能になりますが、データが複数箇所に存在するため更新時に整合性を保つ責任がアプリケーション側に移ります。使いどころを見極めることが重要です。
非正規化の主なパターン
| パターン | 内容 | メリット | デメリット |
|---|---|---|---|
| カラムの複製 | 他テーブルの値をコピーして保持 | JOIN不要 | 更新漏れのリスク |
| 集計値の事前計算 | 合計・件数をカラムに保持 | 集計クエリ不要 | 更新のたびに再計算が必要 |
| テーブルの結合 | 頻繁にJOINするテーブルを統合 | クエリがシンプル | スキーマが肥大化 |
| 派生テーブル | 集計・変換済みデータを別テーブルに | 分析が高速 | 元テーブルとの二重管理 |
| 配列・JSON埋め込み | 子レコードを親レコードに格納 | 1回取得で完結 | 部分更新が難しい |
歴史と背景
- 1970〜80年代：コッドの正規化理論が主流。「正規化が正義」という設計思想が定着
- 1990年代：大規模Webサービスの登場でJOIN多発による性能問題が顕在化
- 2000年代：データウェアハウス設計でスタースキーマ（非正規化テーブル）が普及
- 2009年〜：NoSQL（特にドキュメントDB）が登場し、非正規化を設計の前提とする思想が広まる
- 2010年代：マテリアライズドビュー・読み取り専用レプリカなど技術的解決策も充実
- 現在：「正規化で整合性、非正規化で性能」を用途に応じて使い分けるのが標準的アプローチ
非正規化の適用判断基準
| 適用すべき状況 | 適用を避けるべき状況 |
|---|---|
| 読み取りが書き込みより圧倒的に多い | データ更新が頻繁に発生する |
| JOIN数が5以上になる画面 | 整合性が最優先（金融・在庫等） |
| レポート・集計専用テーブル | 開発初期（設計がまだ安定していない） |
| データウェアハウスの分析用テーブル | チームの運用負荷が増えると困る場合 |
関連する規格・RFC
| 規格・RFC番号 | 内容 |
|---|---|
| Ralph Kimball『Data Warehouse Toolkit』 | スタースキーマ（非正規化DWH設計）の標準的手法書 |