「達人に学ぶDB設計徹底指南書」を読む

気になった用語等をまとめる（細かい所はきる）

第1章_データベースを制する者はシステムを制す

学んだこと

システム開発の設計工程	内容
要件定義	必要な機能を決める
設計	実際に作る前に図面を引く ※本書はここがターゲット
開発	プログラムに落とし込む
テスト	テストする

• スキーマとはDBのデータ構造を表す

3層スキーマモデル	説明
外部スキーマ	ユーザーから見てどのようなインターフェースを持っているかを定義（ビュー）
概念スキーマ	開発者から見てデータ同士の関係を定義（テーブル） 概念スキーマの設計を論理設計
内部スキーマ	DBから見てデータをどのように格納するかを定義（ファイル） 内部スキーマの設計を物理設計

• 概念スキーマは外部と内部スキーマの中間にあり両者の変更が影響し合わないように緩衝材の役割

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

学んだこと

• DB設計は原則論理設計が物理設計に先立つ

論理設計のステップ	説明
エンティティの抽出	どのようなデータが必要か抽出（要件定義の中で決める）
エンティティの定義	どのような属性（列）を持つかを定義
正規化	エンティティ（テーブル）を整理
ER図の作成	エンティティ同士の関係を定義

物理設計のステップ	説明
テーブル定義
インデックス定義
ハードウェアのサイジング	サイジングとは大きさを決めること
ストレージの冗長構成決定	冗長とは同じものを複数の場所に持つこと（耐障害性）
ファイルの物理配置決定	ファイルの配置は基本的にはDBMSが自動化

• バックアップはフル＋差分（前回バックアップからのデータを累積的に保持）、フル＋増分（前回バックアップからの増分データのみを保持）が基本
• バックアップファイルをDBに戻す作業をリストア、そのファイルにトランザクションログを適用して変更分を反映する作業をリカバリ
• 障害復旧の手順は①リストア、②リカバリ

第3章_論理設計と正規化

学んだこと

• 主キーや外部キーには固定長文字列を用いる
• テーブルや列名に日本語はNG
• 主キーは一行に特定するもの
• 正規化の目的はデータの整合性を保つため
• 正規化は分割、逆は結合SQL

第4章_ER図

学んだこと

• テーブル間の関係を表現する
• IE表記法がわかりやすくておすすめ
• 多対多の中間にエンティティ（関連実体）を設けて多対一の関係を作る

第5章_論理設計とパフォーマンス

学んだこと

• 正規化すると結合が必要になりSQLが遅くなるデメリットがある
• 裏を返すと非正規化ならばSQLで結合を使わなくても済む
• データの整合性と検索パフォーマンスはトレードオフの関係

第6章_データベースとパフォーマンス

学んだこと

• データ量が少ない場合はインデックスの効果はない
• カーディナリティ（列の値の種類の多さ）が高い列ほどインデックスの効果が高い
• インデックスは検索条件に裸で用いる
• 主キーは自動的にインデックスになる

第7章_論理設計のバッドノウハウ

学んだこと

• 情報は意味が取れる範囲で可能な限り分割して保持する
• 列は一度意味を決めたら変更不可
• キーは固定長文字列

第8章_論理設計のグレーノウハウ

学んだこと

• オートナンバリングをアプリケーション側で実装するのはNG
• 列持ちでなく行持ちテーブルとする

第9章_一歩進んだ論理設計

学んだこと

• RDBは木構造の表現が苦手
• 色々なモデルが研究されている

最後に

良かったところ

• DB設計のポイントが示されている点

悪かったところ(もしあれば)

• なし

学んだこと

• DB設計のポイントが少しわかった

難しかったこと

• 全体的に実務で経験しないと腹落ちしない感があった

参考文献
達人に学ぶDB設計徹底指南書
ミック/株式会社 翔泳社/2023