ER図の基礎：IDEF1X・IE記法とリレーションの読み方

TL;DR

• ER図はテーブル（エンティティ）とその関係（リレーション）を視覚化する設計図である
• 記法は主に IDEF1X と IE記法（Crow's Foot） の2種類があり、現場では IE 記法が主流
• IE 記法の線は「必須/任意」と「最大数（1か多か）」の2軸で読む

---

ER図とは

ER図（Entity-Relationship Diagram）は、1976年にピーター・チェンが提唱したデータモデリング手法である。データの構造——何がどう関係しているか——をグラフで表し、DB の論理設計・物理設計の共通言語として使われる。

コードレビューや設計レビューで「この外部キー、カーディナリティは1対多でいいですか？」といった会話についていくためには、ER図の読み書きは必須スキルといえる。

---

記法の2大流派

IDEF1X

IDEF1X（Integrated DEFinition for Information Modeling）は、1993年に NIST が FIPS 規格として標準化した記法である。米国国防総省での採用を起源に持つ。

特徴は次のとおり：

• エンティティ種別を図形で区別する（独立エンティティ＝角ありボックス、従属エンティティ＝角丸ボックス）
• 主キーが別セクションに区切られて示される
• 線の末端の塗りつぶし有無でリレーション種別を表す

ツールによっては IDEF1X をデフォルトとするものもあるが、一般的なドキュメントやチーム内の設計図では次の IE 記法の方が普及している。

IE記法（Crow's Foot記法）

IE記法（Information Engineering 記法）は、1980年代にクライブ・フィンケルシュタインとジェームズ・マーティンが提唱した記法で、Crow's Foot（カラス足記法）とも呼ばれる。多重度を表す線の末端がカラスの足のように見えることが名前の由来である。

Mermaid の erDiagram は IE 記法を採用しており、現代的なドキュメントツールの多数派でもある。本記事以降は IE 記法を中心に解説する。

---

エンティティとは

エンティティ（Entity）は、管理対象となる「モノ」や「出来事」の単位である。RDB では基本的に1エンティティが1テーブルに対応する。

エンティティは 属性（Attribute） を持つ。属性はカラムに相当し、その中でも行を一意に識別するものが 主キー（Primary Key）である。

erDiagram
    USER {
        int id PK
        string name
        string email
        datetime created_at
    }

---

リレーションとは

リレーション（Relationship）は、エンティティ間の「繋がり」を表す。ER図では線で描き、線の両端の記号で次の2軸を読む。

この2つを組み合わせた記号が線の端に付く。

---

各リレーションの読み方

1対1（One to One）

2つのエンティティが互いにちょうど1件ずつ対応する関係。
例：USER は必ず1つの PROFILE を持ち、PROFILE も必ず1人の USER に属する。

erDiagram
    USER ||--|| PROFILE : "has"
    USER {
        int id PK
        string name
    }
    PROFILE {
        int id PK
        int user_id FK
        string bio
    }

線の読み方：||--||

• 左端 ||：USER 側から見て PROFILE は「ちょうど1件」必須
• 右端 ||：PROFILE 側から見て USER も「ちょうど1件」必須

---

1対0または1（One to Zero-or-One）

1件に対して、相手が存在しない場合もある関係。
例：USER は ADMIN_PROFILE を持つこともあれば持たないこともある。

erDiagram
    USER ||--o| ADMIN_PROFILE : "may have"
    USER {
        int id PK
        string name
    }
    ADMIN_PROFILE {
        int id PK
        int user_id FK
        string role
    }

線の読み方：||--o|

• 左端 ||：USER は必ず1件存在する（ADMIN_PROFILE から見て USER は必須）
• 右端 o|：ADMIN_PROFILE は0件または1件（USER から見て任意・単数）

---

1対多（One to Many）

1件のエンティティに対して、相手が複数件存在する関係。最も頻出するリレーション。
例：1人の USER が複数の ORDER を持つ。

erDiagram
    USER ||--o{ ORDER : "places"
    USER {
        int id PK
        string name
    }
    ORDER {
        int id PK
        int user_id FK
        int amount
        datetime ordered_at
    }

線の読み方：||--o{

• 左端 ||：USER は必ず1件存在する（ORDER から見て USER は必須）
• 右端 o{：ORDER は0件以上（USER から見て任意・複数）

---

1対1以上（One to One-or-More）

相手が必ず1件以上存在することを保証する関係。
例：ORDER は必ず1件以上の ORDER_ITEM を持つ（空の注文は存在しない）。

erDiagram
    ORDER ||--|{ ORDER_ITEM : "contains"
    ORDER {
        int id PK
        int user_id FK
    }
    ORDER_ITEM {
        int id PK
        int order_id FK
        int product_id FK
        int quantity
    }

線の読み方：||--|{

• 左端 ||：ORDER は必ず1件存在する
• 右端 |{：ORDER_ITEM は1件以上必須（0件は許容しない）

---

多対多（Many to Many）

両側が複数件対応する関係。RDB では中間テーブル（連関エンティティ）で実現する。
例：STUDENT は複数の COURSE を受講でき、COURSE も複数の STUDENT を持てる。

erDiagram
    STUDENT }o--o{ COURSE : "enrolls"
    STUDENT {
        int id PK
        string name
    }
    COURSE {
        int id PK
        string title
    }

線の読み方：}o--o{

• 左端 }o：STUDENT は0人以上（COURSE から見て任意・複数）
• 右端 o{：COURSE は0件以上（STUDENT から見て任意・複数）

多対多はそのままでは外部キーを持てないため、実装時は中間テーブルを介して1対多×2に分解する。

erDiagram
    STUDENT ||--o{ ENROLLMENT : "has"
    COURSE ||--o{ ENROLLMENT : "has"
    STUDENT {
        int id PK
        string name
    }
    COURSE {
        int id PK
        string title
    }
    ENROLLMENT {
        int id PK
        int student_id FK
        int course_id FK
        date enrolled_at
    }

---

IE記法の記号まとめ

erDiagram
    A ||--|| B : "1対1（必須）"
    C ||--o| D : "1対0または1"
    E ||--o{ F : "1対多（0以上）"
    G ||--|{ H : "1対多（1以上）"
    I }o--o{ J : "多対多"

---

よくある落とし穴

オプション性を曖昧にしたまま設計する

「ユーザーに注文が紐づく」という説明だけでは o{（0以上）なのか |{（1以上）なのかが決まらない。DB の NOT NULL 制約や外部キー制約の設計に直結するため、設計段階で業務ルールを確認しておくこと。

多対多をそのままテーブル化しようとする

RDB では多対多を直接表現できない。ER図上で多対多に見える関係は、実装前に必ず連関エンティティへ分解する。

IDEF1X と IE 記法を混在させる

チームや使用ツールで記法を統一しないと、同じ「1対多」でも線の意味が異なり、読み間違いが起きる。プロジェクト開始時に記法を決めて CLAUDE.md や設計ガイドに記載しておくとよい。

---

関連

• DB インデックス設計