Query Go
DB 設計とは — 論理設計と物理設計の全体像
Query Go
データモデル設計ガイド

DB 設計とは — 論理設計と物理設計の全体像

論理設計と物理設計の違い、要件からスキーマ確定までの流れを 1 枚で俯瞰する入口ページ。

DB 設計とは — 論理設計と物理設計の全体像 diagram

DB 設計とは何を決めることか

DB 設計とは、業務上の情報を どのテーブルに・どの列として・どう関連づけて持つか を決める作業です。設計の良し悪しは後から大きな差となって表れます。設計がまずいと、どれだけ良いアプリコードを書いても、更新漏れ・不整合・性能劣化・変更コストの増大という形で必ず跳ね返ります。

DB 設計で決めるのは大きく次の 4 点です。

  • テーブル（エンティティ） — 業務に登場する「モノ」をどう切り出すか
  • 列（属性）と型 — 何をどの型で保持するか、NULL を許すか
  • 関係（リレーションシップ） — テーブル同士の多重度と参照整合性
  • 制約・インデックス — 主キー・外部キー・UNIQUE・CHECK、そして性能のための索引

アプリコードやフレームワークは差し替えられても、本番の DB スキーマは簡単には作り直せません。だからこそ、初期設計と正規化の段階で「事実を 1 か所にだけ書く」構造を作ることが、長期の保守コストを最も下げます。

論理設計と物理設計 — 何を分けているのか

DB 設計は伝統的に 概念設計 → 論理設計 → 物理設計 の 3 段階に分けて語られます。実務では 2 段階（論理＋物理）に圧縮することが多いですが、「何を決めているか」の線引きを意識しておくと議論がブレません。

段階決めること成果物RDBMS 依存
概念設計業務の登場人物（エンティティ）・関係を洗い出す概念 ER 図（型・PK/FK なし）なし
論理設計テーブル・列・PK/FK・多重度・制約を決める。正規化もここ論理 ER 図、正規化後のテーブル一覧ほぼなし
物理設計型の厳密化・インデックス・パーティション・ストレージ・非正規化DDL、実行計画を踏まえた索引定義強く依存

ここで大切なのは、論理設計は RDBMS にほぼ依存しないこと。論理設計が固まっていれば、PostgreSQL でも MySQL でも SQL Server でも同じ構造で実装できます。RDBMS の選択肢（型・インデックス種別・分散構成）が具体的な差となって表れるのは物理設計以降です。

本サイトの「設計ガイド」は、大きく次の 2 段階に対応しています。

設計プロセスの流れ — 要件からスキーマまで

はじめて DB を 1 から設計するときは、次の順序で進めると迷いません。

  1. 要件から名詞を抽出 — 「ユーザー・注文・商品・記事…」を洗い出し、それぞれを仮エンティティ（箱）にする
  2. 関係を線で結ぶ — 動詞（注文する／コメントする）が関係になる。両端の多重度（1 : N、0 : N、N : M）を書き込む
  3. 主キー（PK）を決める — 代理キー（id）にするか自然キーにするかを判断（サロゲート vs 自然キー）
  4. N : M は交差テーブルに分解 — 多対多は必ず中間テーブルを立てる
  5. 正規化チェック — 同じ事実が複数行／複数テーブルに現れていないかを確認し、必要なら切り出す（1NF〜5NF）
  6. 列を埋める — 型・NULL 許容・デフォルト値を決める（NULL 許容の基準 / 型の選び方）
  7. 共通カラムを足す — created_at / updated_at / deleted_at などを全テーブル共通で（共通カラム設計）
  8. 制約・インデックスを付ける — UNIQUE / CHECK / FK / よく使う検索列の索引
  9. DDL に落として計測 — 実データで実行計画を眺め、必要に応じて物理設計（索引追加・非正規化）を行う

初回から完璧な設計は望まず、「論理設計でまず 3NF まで正規化 → DDL 化 → 計測 → ホットスポットだけ非正規化」の順で十分です。いきなり非正規化すると、後から「どこに同じ事実が散らばっているか」を追えなくなります。

設計の成果物

設計作業の「出力」は、主に次の 3 つです。これらが揃っていればチームで引き継げますし、欠けていると後任がまず再調査から始めることになります。

  • ER 図 — テーブル間の関係を 1 枚で示す地図。IE 記法（カラスの足） を推奨
  • テーブル定義書（物理＋論理名併記） — 列ごとの型・NULL 可否・デフォルト・コメント。業務用語（論理名）と列名（物理名）の対応表を兼ねる
  • マイグレーションスクリプト — CREATE TABLE / ALTER TABLE の履歴。Flyway / Alembic / Rails migrations などバージョン管理されたもの

ER 図と定義書は手書き図＋表ではなく、DB から逆生成できる状態を保つと劣化しません。A5:SQL Mk-2 等のツールを使えば、本番 DB から ER 図を自動生成できるので、設計ドキュメントと実スキーマの乖離を防げます。

本サイトの設計ガイドの読み方

はじめて読むなら、次の順がおすすめです。

  1. スキーマとは — 「スキーマ」という言葉の整理
  2. ER 図の書き方・読み方 — 論理設計で最も使う図の基本
  3. 正規化とは → 1NF 〜 3NF を順に
  4. 代理キー vs 自然キー / NULL 許容 / 外部キー
  5. 共通カラム設計 — 全テーブルに入れる定番
  6. 型の選び方 / 命名規約

BCNF / 4NF / 5NF や履歴・ポリモーフィック関連は、ひとまずリファレンスとして読み飛ばしても設計は進められます。困ったときの辞書として戻ってきてください。