読むにあたっての前提条件
- エンティティと言われて何かわかる
- 属性、カラムといわれて何かわかる
結論：3つのフェーズでやることはこれです
| フェーズ | やること | アウトプット |
|---|---|---|
| 概念設計 | 何を管理するか決める | 簡易ER図（エンティティと関係性のみ） |
| 論理設計 | どう整理するか決める | 詳細ER図（属性、主キー、外部キーまで） |
| 物理設計 | どう実装するか決める | 実装可能な設計書 |
何はともあれ具体例、ECサイトを例に各フェーズの詳細を見ていきましょう。
概念設計：何を管理するか決める
やること
業務を分析して「何を管理する必要があるか」を洗い出します。
技術的なことは一切考えず、純粋にビジネスの観点で必要なものを整理します。
ECサイトでの具体例
ECサイトで必要なものを考えてみます。
ポイントはソフトウェア上で実現したい業務の上で扱っている情報と向き合うことです。
例えばこんな具合です。
- 顧客の情報を管理したい
- 商品の情報を管理したい
- 注文の情報を管理したい
これらをエンティティ（管理する対象）として抽出し、関係性を整理します。
- リソースエンティティ
- イベント（アクション）エンティティ
をわけて徹底的に洗い出す
ということです。
今回の例だと
- リソースエンティティ
- 商品
- 顧客
- イベント（アクション）エンティティ
- 注文
となります。
あとはそれぞれのエンティティが必要な要素を考え、
必要であれば他エンティティと関係性を持つようにER図を作成します。
アウトプット：簡易ER図
この段階ではざっとのつながりでOkです。
「顧客にどんな属性があるか」「顧客IDはどんな型か」といったことは考えません。
あくまで
- 「何を管理するか」
- 「エンティティ同士の関係性」
だけを決めます。
注意: ER図作成にもいくつかの段階があり、
- 概念ER図
- 論理ER図
- 物理ER図
があります。
ここで作成したER図は概念ER図に当たります。
個人的には最初のER図作成は概念ER図でざっと管理するエンティティ定義と、それぞれのつながりを可視化し
そのあとにそれぞれのエンティティに対して属性を追加する論理設計（テーブル定義するフェーズ）をし、
属性が固まり次第ER図にも属性を追加し概念ER図→論理ER図に進化させるのが良いです。
論理設計：どう整理するか決める
やること
概念設計で決めた内容を、データベースで管理できる形に変換します。具体的には各エンティティの属性（カラム）を全て洗い出し、主キー、外部キーを定義し、データの整合性を保つルールを決めます。
ECサイトでの具体例
概念設計で決めたエンティティに、属性を追加していきます。
※ PK = 主キー、FK = 外部キー、UK = ユニークキー
アウトプット：テーブル設計＆詳細ER図
（上の図例は詳細ER図といった方がベター）
各エンティティの属性、主キー、外部キーが明確になった詳細なER図ができあがります。
これが実質的な「テーブル設計」そのものです。
この段階でも、まだデータ型の具体的なサイズ（VARCHAR(100)など）やインデックスは決めません。
物理設計：どう実装するか決める
やること
論理設計で決めたテーブルを、実際に使うデータベース（MySQLやPostgreSQLなど）で動かせる形にします。パフォーマンスも考慮しながら、データ型のサイズ、インデックス、文字コードなどを決定します。
ECサイトでの具体例
顧客テーブル（実装版）
| カラム名 | データ型 | 制約 | インデックス |
|---|---|---|---|
| 顧客ID | INT | 主キー、自動採番 | あり（主キー） |
| 顧客名 | VARCHAR(100) | NOT NULL | なし |
| メールアドレス | VARCHAR(255) | UNIQUE, NOT NULL | あり（検索用） |
| 登録日 | DATETIME | デフォルト値：現在日時 | なし |
商品テーブル（実装版）
| カラム名 | データ型 | 制約 | インデックス |
|---|---|---|---|
| 商品ID | INT | 主キー、自動採番 | あり（主キー） |
| 商品名 | VARCHAR(200) | NOT NULL | あり（検索用） |
| 価格 | INT | NOT NULL | なし |
| 在庫数 | INT | NOT NULL | なし |
注文テーブル（実装版）
| カラム名 | データ型 | 制約 | インデックス |
|---|---|---|---|
| 注文ID | INT | 主キー、自動採番 | あり（主キー） |
| 顧客ID | INT | 外部キー, NOT NULL | あり（結合用） |
| 商品ID | INT | 外部キー, NOT NULL | あり（結合用） |
| 注文日 | DATETIME | NOT NULL | あり（日付検索用） |
| 数量 | INT | NOT NULL | なし |
アウトプット：実装可能な設計書、具体的なテーブル
各カラムのデータ型、サイズ、インデックスまで決まった、
すぐにCREATE TABLE文を書ける状態の設計書ができがる状態をイメージしましょう。
まとめ：3つのフェーズの違いを再復習
各フェーズの役割をもう一度整理します。
- 概念設計：ビジネス視点で「何を管理するか」を決める。エンティティと関係性だけを考える。
- 論理設計：データベース視点で「どう整理するか」を決める。属性、主キー、外部キーを全て決める。この段階のER図が、多くの人が普段使う「ER図」です。
- 物理設計：実装視点で「どう実装するか」を決める。パフォーマンスや具体的な製品を考慮する。
この3段階を意識することで、変更に強く、保守しやすいデータベース設計ができるようになります。
最初は混乱するかもしれませんが、「何を→どう→具体的にどう」という流れを意識すれば理解しやすくなるはずです。