はじめに

「達人に学ぶDB設計徹底指南書」という技術書を読みましたので、書評を書いてみました。

書評というよりは解説のような形で本の内容を主要なところだけまとめましたので購入＆購読を迷っている方の参考になれたら幸いです。

第1章：DBを制する者はシステムを制す

データベースモデルの種類

リレーショナルDB（RDB）
行と列で構造化された代表的なデータモデル。
オブジェクト指向DB
オブジェクトの継承やメソッドなどの概念をそのまま保存可能。
XMLデータベース
XML文書そのものをストレージとして保持。構造化された可変スキーマに向いています。
キーバリュー型ストア
単純なキーとバリューの対応関係を保持。高速アクセスが求められるキャッシュ用途やセッションストアなど、シンプルな用途に適しています。

システム開発とDB設計の連係

まずDB設計を広い視点で捉えるには、「要件定義→設計→開発→テスト」という開発フローを理解するのが重要です。各段階において、DBが果たす役割や関わり方が異なるため、その目的や制約を踏まえて設計を進める点が解説されています。

三層スキーマ構造（ANSI/SPARCモデル）

外部スキーマ（ビュー）：ユーザーやアプリケーションが直接触れる論理的なデータモデル。
概念スキーマ（論理設計）：業務モデルを反映したER図やテーブル構造。
内部スキーマ（物理設計）：実際にストレージ上でどのように保存し、インデックス構築するかというレベル。

それぞれの責任範囲を明確にすることで、設計の変更や運用時の混乱を軽減できます。

第2章：論理設計と物理設計

RAIDと信頼性

RAID 0：ストライピング

特徴：高速重視、冗長性なし
仕組み：データを複数のディスクに分散して書き込む
メリット：読み書きが速い
デメリット：1台でも壊れると全データ消失

RAID 1：ミラーリング

特徴：安全性重視、容量は半分
仕組み：同じデータを2台に保存
メリット：片方壊れてもデータは残る
デメリット：容量効率が悪い（1TB×2台で1TB）

RAID 2：ビット単位の誤り訂正（ほぼ使われない）

特徴：誤り訂正が可能な特殊構成
デメリット：実用性が低く、現在は使われていない

RAID 3：パリティ付きストライピング（バイト単位）

特徴：1台分のパリティディスクで障害に備える
メリット：冗長性あり
デメリット：パリティ処理のせいで書き込みが遅い

RAID 4：パリティ付きストライピング（ブロック単位）

RAID 3に似ているが、バイト単位ではなくブロック単位で処理
パリティディスクに集中するため、書き込みがボトルネックになりやすい

RAID 5：分散パリティ

特徴：速度・冗長性・容量のバランスが良い
仕組み：データとパリティを複数ディスクに分散
メリット：1台壊れても復旧可能
デメリット：復旧に時間がかかる、書き込み速度はRAID 0より遅め
実用性：サーバー・業務用ストレージでよく使われる
設計段階でどのRAIDレベルを選ぶかによって、信頼性・容量・コスト・パフォーマンスが大きく変わる点が詳説されています。

クラウド化の長所と短所

メリット

初期投資が少なく、小規模でも導入可能。
必要に応じてCPUやメモリを追加できスケールが容易。
サーバ管理者を内製しなくても運用できる。

デメリット

OSやDBミドルウェアに対する自由度が低く、カスタマイズが難しい。
VPNやプライベート接続によるオンプレ連携は設定が複雑。
セキュリティポリシーの変更に制約があることも。
リソースを使いすぎるとコストが急増。
障害時の再現テストがしにくい。
障害が起きてもユーザー側では手立てがない場合が多い。

クラウド活用時に起こりがちな落とし穴や、対策方法も実例とともに紹介されています。

バックアップ戦略

フルバックアップ：全データを丸ごと保存。復旧は早いがコストがかかる。
差分バックアップ：前回以降の変更分を保存。中間的な速度とサイズ。
増分バックアップ：最後のフル以降の変更をすべて保存。容量は小さいが復元が複雑。

各方式のデメリット・メリットを比較し、適切な運用設計を行う視点が学べます。

第3章：正規化の基本

第一正規化：繰り返し項目を排除し、各カラムを原子化。
第二正規化：部分関数従属の排除。主キーが複合キーの際に重要。
第三正規化：推移的従属を解消、非キー属性に依存し合う状態を整理。

第四・第五正規化まで紹介されていますが、「基本的には第三正規化」がベストのようです

第4章：ER図の書き方

ER図の書き方は以下の２種類あります。
主流なのはIE記法のようです

IE記法（Information Engineering）：日本で広く使われ、矢印や矩形を使った視覚的表現が直感的。
IDEF1X記法：リレーションの強弱、オプション性などを厳密に示す構造設計に強みがあります。

どちらを採用すべきか、プロジェクトの規模や設計文化に基づいた選び方も解説されています。

第5章：正規化とパフォーマンスのトレードオフ

正規化→データ整合性が維持しやすい
非正規化→処理の高速化を実現できる
というトレードオフがあります。

第6章：DBの性能を引き出す設計

インデックスの種類：Bツリー、ハッシュ、ビットマップなど。
統計情報（Statistics）：クエリプランナが最適化を行うための情報源。
パーティション：日付やIDによる区切り方によって、データ量が増えても応答速度を維持。

実際の運用に基づいたノウハウが豊富に紹介され、読み応えのある章です。

第7章：論理設計におけるアンチパターン

非スカラ値：カラムに「1,2,3」のように複数IDを格納してしまう。JOINが困難。
ダブルミーニング：「status」カラムに「0=未処理・失敗」など2つの意味を重ねがち。
単一参照テーブル：複数用途のフラグを1つのテーブルで管理し意味が不明瞭に。
不適切なキー：CHAR型主キーは可変長による性能劣化が問題。
ダブルマスタ構成：同じデータ整合性が複数経路から更新される設計ミス。
ゾンビマート・多段マート：DWHでのデータ複線・重複・遅延が発生しやすい構造。

具体パターンのデメリットと、「こういう時どう避けるべきか」の対策が網羅されています。

第8章：設計ノウハウ（グレーゾーン）

代理キー（Surrogate Key）：自然キーが長かったり意味を持ちすぎるときにIDとして代用する。
多段ビュー：ビューの下にさらにビューを作る設計。ロジックが分離しやすいがパフォーマンスリスクも。

データクレンジングについて

名寄せ：複数異なる表記を統一
重複排除：同一IDが分かれて管理されないよう整備
一意キー設定：キーの独自ルールを明文化する手法

第9章：一歩進んだ設計手法（ツリー構造）

隣接リストモデル
閉包テーブルモデル（Closure Table）

📘 総評：
DB設計の基本的な考え方を体系的に学べる良書でした。

こんな人にオススメ

DB設計初心者〜中級者：理論から実践まで一気通貫して学びたい方