ER 図の書き方・読み方

ER 図（Entity-Relationship Diagram） は、DB に登場する「モノ（エンティティ）」と「モノ同士の関係（リレーションシップ）」を図にしたものです。テーブル定義を箇条書きで読むより、全体の構造・関係の向き・多重度（1 対 N など）を視覚的に把握できるのが最大のメリットです。

• 設計時: 要件から必要なテーブルを洗い出し、関係の向きと多重度を検討する
• レビュー時: 正規化の漏れ・不要な結合・孤立したテーブルを発見する
• 引き継ぎ時: 既存 DB の全体像を 1 枚で共有する。SQL だけを読むより圧倒的に早い

ER 図は「詳細なクラス図」ではなく「テーブル間の関係性に絞った地図」。列の型は最小限、関係の構造を優先して描くのがコツです。

※ 本サイトでは現代の DB 設計で最も普及している IE 記法（カラスの足記法） を採用して解説します。公的機関・基幹系で使われる IDEF1X 記法 との比較は IE 記法 vs IDEF1X 記法 を参照してください。

ER 図の構成要素は 3 つだけです。

• エンティティ（Entity）: DB のテーブルに相当する「モノ」。ER 図では四角い箱で描き、上段にテーブル名を書く
• 属性（Attribute）: エンティティが持つ項目 = テーブルの列。箱の中に 列名 : 型 を並べる。主キーは PK、外部キーは FK と注記する
• 関係（Relationship）: エンティティ同士を結ぶ線。線の両端の形で「必須かどうか（0 or 1 以上）」と「単一か複数か（1 or N）」を表す = 多重度

冒頭の図が ER 図の典型的な見た目です。customers の 1 行に対し orders が 0 件以上ある、という関係を 1 本の線で表現しています。

IE 記法は線の端の形が 4 通りあり、○（任意）・棒（必須）・カラスの足（複数） の組み合わせで多重度を表します。記号と意味の対応表・他記法（IDEF1X）との比較は IE 記法 vs IDEF1X 記法 で扱います。

線の両端にそれぞれこの記号がつくので、関係の両側の多重度を読み取るのがポイントです。たとえば「顧客 1 .. 1 ──── 0 .. N 注文」と読めれば、「注文は必ず 1 人の顧客を持ち、顧客側から見ると 0 件以上の注文を持てる」と理解できます（片側だけでは情報不足になる点は 多重度は両端に書く を参照）。

データ型の基本 に載せた 3 テーブルの ER 図を、記法の練習として読み解いてみましょう。

• users 1 : N accounts: 1 人のユーザーは複数の口座を持てる。口座は必ず 1 人のユーザーに属する（users 側が「1 .. 1」、accounts 側が「0 .. N」または「1 .. N」）
• accounts 1 : N transactions: 1 つの口座には複数の入出金履歴が紐づく。トランザクションは必ず 1 つの口座に属する（トランザクション単独では意味を持たない）

この 2 本の線を見ただけで、「ユーザーを削除する前に、口座と取引を先に整理する必要がある」「口座番号だけ分かればユーザーは特定できる」 といった操作上の制約まで読み取れます。これが ER 図の強みです。

初めて描くときは次の順序で進めると迷いません。

1. 名詞を書き出す: 要件から登場人物・モノ（ユーザー・注文・商品・記事…）を洗い出し、それぞれをエンティティ（箱）にする
2. 動詞で線を引く: 「ユーザー が 注文する」「記事 に コメント が つく」のように、名詞の間の動詞が関係になる
3. 多重度を決める: 線の両端に「1 or N」「必須 or 任意」を書く。曖昧なら要件を確認する（ここが一番議論が要る段階）
4. 主キーを決める: 各エンティティに PK を入れる（サロゲートキー id にするか、自然キーにするかは サロゲート vs 自然キー を参照）
5. N : M を交差テーブルに分解: 多対多の関係は中間テーブルに展開する（例: user_tags (user_id, tag_id)）
6. 属性を埋める: 必須の列を箱の中に足す。列の型は データ型の基本 と 型マッピング早見表 を参照
7. 正規化チェック: 同じ事実が 2 か所に現れていないか確認。怪しければ 正規化 を適用してエンティティを分ける

ER 図の作成ツールには色々ありますが、日本語圏で DB 設計をするなら A5:SQL Mk-2 がおすすめです。無料で配布されており、下記の点で他ツールより一歩抜けています。

• 日本語完全対応: コメント・論理名・物理名を日本語で書いても崩れない。レビューのしやすさが段違い
• 既存 DB からのリバースエンジニアリング: 接続して「ER 図生成」を実行するだけで、現行スキーマから IE 記法の ER 図を自動生成してくれる
• DDL 生成／DDL 取込の双方向: 図から CREATE TABLE を吐き出せるし、逆に DDL を貼り付けて図に起こすこともできる
• 物理名 + 論理名の併記: customer_id（顧客 ID） のように、英語の列名と日本語の論理名を同じボックスに表示できる（業務アプリの設計書には必須）
• 軽量・オフライン: Windows ネイティブで動き、クラウド SaaS のようなアカウント登録や機密情報流出の懸念が無い

他の選択肢と比較すると:

• dbdiagram.io: テキスト DSL で書く Web ツール。Git で管理しやすく OSS プロジェクト向け。ただし日本語の論理名併記はやや弱い
• DBeaver: SQL クライアントのおまけ機能として ER 図が描ける。普段 DBeaver を使っているならこれで十分なことも
• Mermaid（erDiagram）: Markdown に埋め込めるテキスト記法。README やドキュメント内で気軽に貼るのに便利だが、大規模スキーマには向かない
• PlantUML / draw.io / Lucidchart: 汎用図ツール。DB 専用機能（リバエン・DDL 出力）は弱いので、他の図と一緒に書くとき以外は A5:SQL Mk-2 に軍配

※ A5:SQL Mk-2 は Windows 専用。macOS / Linux で使いたい場合は dbdiagram.io か DBeaver が候補になります。

ER 図で起きがちな間違いは 5 つに整理できます。いずれも後から直すと DB 制約の変更まで波及するため、描いている最中に気付けるよう、それぞれ独立ページで詳細を扱います。

• 多重度は両端に書く — 片側だけでは必須/任意が決まらず、NOT NULL や参照整合性の設計が宙に浮く
• N : M は中間テーブルに分解する — 素の線のままでは物理化できない。属性が乗れば関連実体に昇格させる
• 推移的な関係を直結しない — 「ユーザー ─ 明細」のような短絡線は、親を介さずに子が存在できる矛盾を生む
• ER 図は全列載せる — 共通カラムは非表示機能で隠す — 主要属性だけに絞ると FK・NOT NULL・監査列の情報が落ちる。A5:SQL Mk-2 なら全列載せたまま共通カラムだけ非表示にできる
• 論理 ER 図 vs 物理 ER 図 — 型・制約・索引を書くかどうかは、レビュー相手と目的で決める