ブログ記事
非正規化は最後の選択肢――ミック『達人に学ぶDB設計徹底指南書 第2版』が説く論理設計と物理設計のせめぎ合い
テーブルを「なんとなく」設計して、後になって重複やパフォーマンス低下に苦しんだことはないか。
ミック著『達人に学ぶDB設計徹底指南書 第2版』（翔泳社、2024年）は、この問いから出発する。初版刊行から10年以上を経て、パブリッククラウド環境での物理設計や冗長構成、バックアップ・リカバリ設計を新たに取り込んだ第2版だ。正規化によってデータの重複と矛盾を排除する「論理設計」と、限られたハードウェア資源から応答速度を引き出す「物理設計」の間には常にトレードオフが生じる。本書はこの対立をどう乗りこなすかを、理論的根拠とともに解説する。
1. 論理設計と物理設計のせめぎ合い
テーブルを正規化して綺麗に分割するほど、データ取得時の結合処理が増え、ハードウェアへのI/Oコストが跳ね上がる。この対立に対して本書は、データ構造を破壊する「非正規化」をいきなり選ぶのではなく、段階を踏んで代替手段を尽くすことを説く。
flowchart TD
A["クエリの最適化\n（SQL文の見直し）"] --> B["インデックス設計\n（適切な索引を張る）"]
B --> C["パーティショニング\n（テーブルの物理分割）"]
C --> D["非正規化\n（最後の手段）"]
style A fill:#e8f4fd,stroke:#4a9eda
style B fill:#e8f4fd,stroke:#4a9eda
style C fill:#fff8e1,stroke:#f5a623
style D fill:#fce8e8,stroke:#e53935
データの整合性を犠牲にする非正規化は、常に最後の選択肢として位置づけるべきというのが本書の一貫した立場だ。
2. 第4・第5正規形、ボイス・コッド正規形まで踏み込む理論
多くの入門書は第3正規形の解説で止まるが、本書は実務上の判断を左右する第4正規形・第5正規形・ボイス・コッド正規形まで踏み込む。多値従属や結合従属といった、一見縁遠く見える概念が、実際には「なぜこのテーブルは分割されるべきなのか」という判断の根拠になっていることを示す構成だ。
3. アンチパターンとグレーノウハウの見極め
現場で無自覚に採用されがちな設計ミスについて、内部動作のレベルで理由を解き明かす。1つの列に複数の値をカンマ区切りで詰め込む「非スカラ値」や、用途によって同じ列を使い回す「ダブルミーニング」は、SQLの記述を複雑化させ不整合を誘発する典型例として挙げられる。一方で、自然キーが存在しないときに自動採番する「代理キー」や、パフォーマンスを優先した「列持ちテーブル」のように、条件付きで有効な「グレーノウハウ」も紹介される。何を採用し、何を避けるべきかの判断基準がここにある。
4. 隣接リストモデルの再評価――SQLの進化が変える設計の常識
第2版で特に踏み込んだのが、木構造設計の再評価だ。親子関係や多階層構造を表す「隣接リストモデル」は、深い階層を跨ぐ検索で多段階の結合処理が必要になるため、長らくアンチパターンとされてきた。しかし主要なデータベースエンジンで「再帰共通表式（CTE）」が広くサポートされたことで、クエリの複雑さと実効性能の問題が解消され、隣接リストモデルは有力な選択肢として返り咲いた。過去の定説を妄信せず、データベースエンジンの機能拡張に合わせて設計常識をアップデートする姿勢が求められる。
この本が解決できる具体的な状況
SQLの基本的な操作は理解しているが、一からテーブル構造やER図を組み立てた経験が乏しく、仕様変更のたびにどう分割すべきか、整合性を保ちながらどう速度を引き出すべきかの判断基準を持てずにいる――この状況に、本書は「非正規化は最後の手段」という優先順位と、正規化の理論的根拠を与える。オンプレミスからクラウドへの移行に伴い、レプリケーションやバックアップ設計の物理的トレードオフを再整理したいエンジニアにも、第2版で追加されたクラウド設計指針が助けになる。
こんな人に向いている
- テーブル分割やリレーション設計に自信が持てず、感覚的な判断から卒業したい中級開発者
- オンプレミスの物理設計経験を持ち、クラウド環境向けに設計理念を再構築したいシステム設計者
- チームのレビューでアンチパターンを論理的根拠とともに指摘する立場になったエンジニア
逆に向いていないケース
- 基本的なSQLの記述やコンピュータシステムのアーキテクチャに触れたことがない完全な初心者: 理論的・概念的な議論が多く、抽象度が高いため読破に時間がかかる
- ハードウェアやインフラ管理の実務経験がない読者: 第2章で扱うストレージやCPU、メモリといった物理設計の話は、具体的なシステム像を描きにくい
- 手を動かした検証なしに知識だけを得たい人: 実機やテストデータを用いたハンズオン検証を伴わないと、紹介されるアンチパターンやグレーノウハウが単なる知識の記憶にとどまり、現場での応用力に結びつきにくい
知っておきたい限界
批判として押さえておきたい点が二つある。
一つは前提知識のハードルだ。理論的・概念的な解説が中心のため、SQLの基本操作やコンピュータシステムのアーキテクチャに触れたことがない読者には抽象度が高く、読破に時間を要する。特に物理設計の章で扱うハードウェア要素は、インフラ管理の実務経験がないと具体的なイメージを持ちにくい。
もう一つは、知識の定着に検証が要ることだ。紹介されるアンチパターンやグレーノウハウは、実際にシステムの保守運用やトラブルを経験していない、あるいはハンズオンで手を動かして確かめないまま読むと、単なる知識の記憶にとどまり、現場での主体的な応用に結びつきにくいという指摘がある。
同じテーマの本との比較
DB設計の経験が浅い段階なら、先に『やさしいデータベース設計』で要件定義から運用までの一連の工程を通しで眺めておくと、本書が扱う判断軸の「深掘り」であることが見えやすくなる。
正規化やNULLの3値論理がなぜ問題を生むのかを数学的な根拠まで理解したいなら、『理論から学ぶデータベース実践入門』で集合論・述語論理の土台を先に押さえておく手もある。本書はその理論を実装レベルの判断に落とし込む役割を担う。
本書でアンチパターンの入り口に触れたら、次は『SQLアンチパターン』でナイーブツリーやEAVなど、より広範な失敗例とその回避策に触れると設計眼が鍛えられる。
正規化と物理設計の基本手順が腹落ちしたら、『データモデル大全』のような業務ドメイン特化のモデリング事例に進むと、「なぜその形になるのか」まで含めて理解しやすくなる。継続的にスキーマを進化させる技法を学びたい場合は『データベース・リファクタリング』が実務的な補完になる。
まとめ
正規化と非正規化のどちらが正しいかではなく、両者の間のどこで折り合いをつけるかを、理論的根拠を持って判断できるようになること。本書が育てるのはその判断力だ。
筆者の体験から
チームのテックリードとして若手のテーブル設計をレビューする立場になってから、「なんとなく問題がありそうだが、なぜダメなのかをうまく説明できない」場面が増えていた。あるとき、1つの列に用途の異なる値を詰め込んだ設計（本書でいうダブルミーニングに近いもの）を見つけたが、感覚的な違和感を指摘するだけで終わっていた。
本書の段階的アプローチ――非正規化を検討する前に、クエリの見直しやインデックス設計、パーティショニングを尽くすという順番――を読んでから、レビューで「速度が出ないなら、まず何を試したか」を確認する習慣がついた。以前は速度が出ないとすぐテーブル統合の話が出ていたが、今はその前段の選択肢を潰したかを先に聞くようになった。
ただし、正直に言うと、物理設計の章で扱うクラウドインフラのレプリケーション構成やバックアップ・リカバリの細部は、自分たちがマネージドサービスに任せている部分も多く、そのまま実務の判断基準として使い切れているわけではない。理論と判断の優先順位を持ち帰った、というのが実態に近い。
DevBookPath のマップで確認する
この本の学習パス上の位置づけ・前後の読書順は、DevBookPath のグラフで辿れます。
本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。
この記事を共有
この地図を共有