はじめに
以前紹介した『おうちで学べるデータベースのきほん 第2版』を読んだに続いて、ミックさん著の『達人に学ぶDB設計徹底指南書 第2版』を読みました。RDBの設計についてより実践的で深い知識を得ることができたので、学んだ内容を共有します。
| 書籍情報 | 内容 |
|---|---|
| 書籍名 | 達人に学ぶDB設計徹底指南書 第2版 |
| 著者名 | ミック |
| 出版年 | 2024/8/28 |
| ISBN | 9784798186627 |
| 書籍ページ | https://www.shoeisha.co.jp/book/detail/9784798186627 |
『おうちで学べるデータベースのきほん 第2版』の内容をベースにさらに踏み込んだ内容になっており、非常に勉強になりました。本記事では特に印象に残った点を中心に紹介します。
学んだこと
3層スキーマの概念とデータベース設計プロセス
スキーマというのは、データベースの枠組みやフォーマットを意味する言葉で、一般的に3つのレベルに分けられます。これを理解することで、データベース設計の全体像が見えてきます。
3層スキーマの構造
| スキーマ | 対応するもの | 説明 |
|---|---|---|
| 外部スキーマ | ビュー | ユーザーから見たデータベースの姿。アプリケーションが直接利用する形式。 |
| 概念スキーマ | テーブル | 開発者から見たデータベースの姿。論理的なデータ構造を表現。 |
| 内部スキーマ | ファイル | DBMSから見たデータベースの姿。物理的な格納方法を定義。 |
データベース設計のプロセス
論理設計（概念スキーマの設計）
- エンティティの抽出 - システムで扱う実体を特定する
- エンティティの定義 - 各エンティティの属性を決定する
- 正規化 - データの冗長性を排除し、整合性を保つ
- ER図の作成 - エンティティ間の関係性を可視化する
物理設計（内部スキーマの設計）
- テーブル定義 - 実際のテーブル構造を決定する
- インデックス定義 - 検索効率を上げるインデックスを設計する
- ハードウェアのサイジング - 必要なハードウェアリソースを見積もる
- ストレージの冗長構成決定 - データ保全のための冗長性を設計する
- ファイルの物理配置決定 - 効率的なデータ配置を決める
この全体観を理解することで、RDBの設計における個々の技術トピックが「なぜ必要か」という視点で捉えられるようになりました。特にRDB初心者にとって、この枠組みは非常に有益だと感じました。
正規化の重要性と各正規形の意義
正規化については、『おうちで学べるデータベースのきほん 第2版』では第3正規化までしか扱われていませんでしたが、本書では第5正規化まで詳しく解説されていました。
各正規形の概要と目的
以下の表は各正規形の要点をまとめたものです：
| 正規形 | 目的 | 解決する問題 | 具体的なメリット |
|---|---|---|---|
| 第1正規形（1NF） | 非スカラー値の排除 | 繰り返しグループ、配列の存在 | • 表形式での一貫した扱いが可能に• 関数従属性が明確になる• データ操作が統一的に |
| 第2正規形（2NF） | 部分関数従属の排除 | 複合キーの一部への従属 | • 部分キー変更による異常を防止• データの意味がより明確に• 属性の独立性が向上 |
| 第3正規形（3NF） | 推移的関数従属の排除 | 非キー属性間の従属関係 | • 不必要な依存関係が解消• 更新・削除異常の防止• スキーマ全体の単純化 |
| ボイス・コッド正規形（BCNF） | 主キー以外の決定性の排除 | 決定要素がすべてスーパーキーになるよう修正 | • 複雑な関数従属の例外を解消• さらなる更新・削除異常の防止 |
| 第4正規形（4NF） | 多値従属の排除 | 1つのキーが複数の独立した値を決定 | • 冗長な組み合わせデータを防止• データ項目の独立性確保 |
| 第5正規形（5NF） | 結合従属の排除 | 分解したテーブルが自然結合で完全に復元できない | • 完全な分解と再構成の保証• 複雑な組み合わせによる更新異常の防止 |
正規化の実践指針
著者は正規化について以下の実用的な指針を示しています：
- 第3正規形までは必ず行うべき
- パフォーマンス目的の非正規化は最終手段
- まずは他のパフォーマンス改善策（インデックス、クエリ最適化など）を検討し、それでも改善しない場合に限り非正規化を検討する
この指針はRDBの設計初心者にとって非常に参考になりました。
パフォーマンス改善の実践的アプローチ
本書ではクエリのパフォーマンス改善策として、以下の手法が詳しく解説されていました：
- インデックス設計
- パーティショニング
- ヒント句の活用
- パラレルクエリの利用
特にインデックスについては、種類ごとの特性と適用条件が詳細に説明されていました。
インデックスの種類と特性
B-treeインデックス（最も一般的）
B-treeインデックスは以下の観点で高い汎用性を持っています：
| 特性 | 説明 |
|---|---|
| 均一性 | データ分布に関わらず安定したパフォーマンス |
| 持続性 | データ変更後も性能が大きく低下しにくい |
| 処理汎用性 | 範囲検索、前方一致、ソートなど多様なクエリに対応 |
| 非等値性 | 等値検索だけでなく範囲検索にも有効 |
| 親ソート性 | インデックス順でデータを取得できる |
B-treeインデックスの適用条件：
- 大規模なテーブル（目安として10万件以上）
- カーディナリティ（値の種類）が高い列
- できれば値の分散が均一な列
- WHERE句や結合条件に頻繁に使用される列
B-treeインデックス利用時の留意点：
- インデックスが適用されないクエリの書き方がある（関数適用、暗黙的型変換など）
- 定期的な再構築などのメンテナンスが必要
- 主キーやユニーク制約がある列には自動的に作成されるので追加不要
その他のインデックス
ビットマップインデックス
- カーディナリティの低い列（性別、都道府県など）に効果的
- 複数条件の絞り込みが高速
- ただし更新が頻繁な環境では性能が大きく劣化する可能性あり
ハッシュインデックス
- 等値検索（完全一致）のみに特化したインデックス
- 等値検索では非常に高速
- 範囲検索やソートには全く効果がない
インデックス以外のパフォーマンス改善策
- パーティショニング：大規模テーブルを物理的に分割し、検索・更新の範囲を限定
- ヒント句：オプティマイザに実行計画の選択を指示するSQL文の一部
- パラレルクエリ：クエリ処理を複数のCPUコアで並列実行
本書では、まずはクエリの見直しやインデックス設計などの基本的な最適化を行い、それでも不十分な場合に高度な技術を適用するという段階的なアプローチが推奨されていました。これは実務での問題解決の優先順位付けに役立つ視点だと感じました。
アンチパターンとグレーノウハウの実践的知識
本書の特に参考になった部分は、実際のDB設計でよく見られる誤りや判断の難しい手法についての解説でした。
データベース設計のアンチパターン
以下は本書で説明されていた主なアンチパターンです：
| アンチパターン | 問題点 | 代替アプローチ |
|---|---|---|
| 非スカラー値 | • 検索効率の低下• データ整合性の問題• 標準SQLでの操作が困難 | • 1NF正規化を行う• 列持ちテーブルも用法容量を守って検討 |
| ダブルミーニング | • 1つの列に複数の意味を持たせる• コードの複雑化• 将来的な拡張性の低下 | • 意味ごとに列を分ける |
| 単一参照テーブル | • さまざまな種類のマスタを1つのテーブルで管理• メンテナンス性の低下• 型やルールの統一が困難• 外部キーによる参照制約をつけることができない | • 種類ごとにテーブルを分ける• 適切な制約を設ける |
| 水平分割テーブル | • 同じ構造のテーブルを条件別に複数作成• 結合クエリが複雑になる• メンテナンスコストの増大 | • パーティショニング機能を使用• ビューでの統合アクセス |
| 垂直分割テーブル | • 1つのエンティティを複数テーブルに分割• 不必要な結合の増加• データ整合性リスク | • 集約テーブルをつくる• マテリアライズドビューなどで集約 |
| ダブルマスタ | • 同じマスタデータを複数のテーブルで管理• データ不整合の発生• 更新管理の複雑化 | • 参照関係を明確にする |
| ゾンビマート | • 不使用のデータマートが削除できず残ってしまう• ストレージの消費 | • 計画的に設計する |
これらのアンチパターンのうちいくつかは、一見すると簡単で便利な解決策に見えますが、長期的にはメンテナンス性やパフォーマンスの問題を引き起こします。 筆者は各アンチパターンの具体的な問題点と回避策を丁寧に説明しており、実務でよく見かける問題への対処法として非常に参考になりました。
グレーノウハウ（ケースによって有効な手法）
一方で、状況によっては有効であるが、無条件で採用するべきではない「グレーノウハウ」についても解説されていました：
| グレーノウハウ | 概要 | 有効な場面 | 注意点 |
|---|---|---|---|
| 代理キー | 自然キーの代わりに自動採番ID等を使用 | • 自然キーが存在しない• 自然キーが変更される可能性がある | • 業務的な一意性制約は別途必要• 意味のある値を参照すべき場面がある |
| 列持ちテーブル | 複数の属性を列として持つ設計 | • 属性の追加が少ない• パフォーマンスが重要な場面 | • スキーマ変更が頻繁になる• 属性が多くなりすぎないよう注意 |
| アドホックな集計キー | アドホックな終毛のためのキーの保持 | • 頻繁に使われる集計• リアルタイム性より速度が重要 | • 整合性維持のためのトリガー等が必要• メンテナンスコストが増大 |
| 多段ビュー | ビューの上に別のビューを定義 | • 複雑なクエリの再利用• アクセス制御の階層化 | • パフォーマンス低下の可能性• ビュー間の依存関係の複雑化 |
著者はこれらの手法について「用法用量を守れば有効」という立場を取っており、各手法がどのような条件下で有効で、どのような点に注意すべきかを解説しています。これはDB設計において柔軟性と原則のバランスを取る際の指針として役立ちます。
まとめと今後の学習計画
『達人に学ぶDB設計徹底指南書 第2版』は、RDBの設計において考慮すべき点を広範にわたって解説しており、非常に実践的な一冊でした。本書の特筆すべき点は以下の通りです：
本書の価値
設計判断の根拠を明示
単に「こうすべき」という指示だけでなく、「なぜそうすべきか」「なぜそれをすべきでないか」という根拠まで丁寧に解説されています。これにより、単なる手順の暗記ではなく、状況に応じた適切な判断ができるようになります。実務に即した知識の提供
理論だけでなく実際のプロジェクトで遭遇する悩ましい状況やトレードオフについても触れられており、実務での意思決定に直接役立つ内容になっています。体系的な知識の整理
RDBに関する様々なトピック（正規化、パフォーマンスチューニングなど）が相互に関連付けられており、断片的な知識ではなく全体像を把握できます。
読み方のポイント
本書は単に目次順に読むだけでなく、以下のような読み方をすることでより効果的に学べると感じました：
- 演習問題は必ず取り組む - 本文で解説されていない重要な内容が問題や解説に含まれています
- コラムも丁寧に読む - 実務上の例外や応用が豊富に記載されています
- 反復して読む - 初読時には理解しきれない内容も、実務経験を積んだ後に読み返すと新たな気づきがあります
今後の学習計画
この本で学んだ理論を実践に落とし込むために、次は『SQL 第2版: ゼロからはじめるデータベース操作』に取り組み、実際のSQLの書き方や最適化手法について学びたいと考えています。また、できればサンプルデータベースを使って本書で学んだ設計原則を実際に適用してみる練習も行いたいと思います。
RDBの設計は一見複雑で難解に感じることもありますが、本書を通じて「なぜそうするのか」という理解を深めることで、より自信を持って設計判断ができるようになりました。データベース設計の奥深さと面白さを改めて実感した良書でした。