ER 図
論理 ER 図 vs 物理 ER 図
同じスキーマでも論理 ER と物理 ER は別物。概念／論理／物理の 3 段階で書き分ける。
概念・論理・物理の 3 段階
ER 図は情報の詳細度で 3 段階に分けられます。それぞれ読み手と目的が違うため、混ぜて描くと全員にとって読みにくくなります。
| 段階 | 書く内容 | 読み手 | 主な用途 |
|---|---|---|---|
| 概念 ER | エンティティ名と関係のみ。属性は書かない | 業務担当・PM | 要件合意、全体像の共有 |
| 論理 ER | PK / FK / 主要属性、型の種類（文字列・整数・日時）程度 | 設計者・レビュアー | 設計議論、正規化チェック |
| 物理 ER | 論理 ER に加え、正確な型・長さ・NULL 可否・索引・制約 | 実装者・DBA | DDL 生成、性能チューニング |
順序としては概念 → 論理 → 物理 と詳細化していきます。最初から物理 ER で書き始めると、要件が固まる前に実装詳細に引きずられがちです。
論理 ER と物理 ER の使い分け
実務で最も頻繁に描くのは論理 ER 図と物理 ER 図 の 2 種類です。以下の基準で使い分けます。
- 論理 ER を描く場面: 要件レビュー／設計議論／正規化検討／開発者以外への説明。型は
文字列 / 整数 / 日時 / 金額程度で十分 - 物理 ER を描く場面: DDL 生成／コードレビュー／DBA とのチューニング議論／納品物。
VARCHAR(80)NUMERIC(14,2)TIMESTAMPTZ NOT NULLまで書く
同じスキーマから両方の図を保守するのが理想ですが、重複保守は現実的ではありません。実務では「論理 ER を正 / 物理 ER はツールから自動生成」という運用が多いです。A5:SQL Mk-2 / DBeaver は DB 接続からの物理 ER 自動生成に対応しています。
論理と物理で「変わる」・「変わらない」もの
論理 ER と物理 ER で変わる情報と不変の情報があります。
| 要素 | 論理 ER | 物理 ER |
|---|---|---|
| テーブル名 | 論理名（顧客）中心 | 物理名（customers）中心 |
| 列の型 | 汎用型（文字列・整数・日時） | RDBMS 固有型（VARCHAR(80), TIMESTAMPTZ） |
| NULL 可否 | 任意/必須のみ（多重度で表現） | NOT NULL / NULLABLE を明示 |
| 索引・UNIQUE | 書かない | 書く（索引が多ければ別図推奨） |
| エンティティ・多重度 | 同じ（論理的な正しさは両図で一致させる） | |
エンティティ構造と多重度は「論理 ER で決めたものを物理 ER も守る」のが鉄則です。物理 ER の段階で正規化を崩すと、論理 ER との整合が取れなくなり、設計ドキュメントとして機能しなくなります。
A5:SQL Mk-2 での切替
A5:SQL Mk-2 では 1 つの ER 図ファイル内で論理名表示／物理名表示／両方表示を切り替えできます。「表示」メニューから 「論理名のみ」「物理名のみ」「論理名 + 物理名」 のいずれかを選ぶだけです。
- 業務担当へのレビュー: 論理名のみ（日本語だけで読める）
- 開発者レビュー: 論理名 + 物理名（業務用語とコード上の名前を同時確認）
- DDL 生成・DBA 向け: 物理名のみ（実際のテーブル・列名の視認性優先）
列の型表示も「型を省略」「型のみ」「型 + 制約」と切り替えられるため、1 つのファイルを論理 ER / 物理 ER 両用に運用できます。ER ツールを選ぶときは、この切替機能の有無を判断基準にすると良いでしょう。