第3部:ドキュメントスキル / 第5章:データベース操作

ER図の読み方

ER図(Entity Relationship Diagram)は、データベースの構造を表した図です。テーブル間の関係を理解するために使います。

📖 読了目安 約8分 対象:DB設計を読む機会がある方

ER図とは

役割

  • テーブル(エンティティ)の構造を表現
  • テーブル間の関係(リレーション)を表現
  • 主キー・外部キーの関係を明示

いつ使うか

DB設計理解時テーブル構造の把握
SQL作成時JOIN条件の確認
新機能実装時必要なテーブルの確認
障害調査時データの流れを追跡

ER図の基本要素

今すぐ必須

エンティティ(テーブル)の表記

users
PKid
name
email
created_at

キーの表記

表記意味説明
PKPrimary Key主キー(レコードを一意に識別)
FKForeign Key外部キー(他テーブルを参照)
UKUnique Keyユニークキー(重複不可)

リレーション(関係)の種類

今すぐ必須

1つのレコードが、もう1つのテーブルの1つのレコードと対応。

erDiagram
    users ||--|| user_profiles : has
    users {
        int id PK
        string name
    }
    user_profiles {
        int id PK
        int user_id FK
        string bio
    }

:ユーザーとユーザープロフィール(1人のユーザーに1つのプロフィール)

1つのレコードが、複数のレコードと対応。最も一般的

erDiagram
    users ||--o{ orders : places
    users {
        int id PK
        string name
    }
    orders {
        int id PK
        int user_id FK
        int total
    }

:ユーザーと注文(1人のユーザーが複数の注文を持つ)

慣れてきたら

複数のレコードが、複数のレコードと対応。中間テーブルが必要。

erDiagram
    students ||--o{ student_courses : enrolls
    courses ||--o{ student_courses : has
    students {
        int id PK
        string name
    }
    courses {
        int id PK
        string title
    }
    student_courses {
        int id PK
        int student_id FK
        int course_id FK
    }

:学生と講座(1人の学生が複数の講座を受講、1つの講座に複数の学生が参加)

カーディナリティ(多重度)の記号

記号意味
||ちょうど1つ(必須)
|o0または1つ(オプション)
o{0以上(複数可)
|{1以上(必須、複数可)

記号の読み方

users ||--o{ orders
  • 左側 ||:usersは必ず1つ
  • 右側 o{:ordersは0個以上

→「1人のユーザーは0個以上の注文を持つ」

【サンプル】ER図の実例

ECサイトのデータベースを例に、ER図を読んでみましょう。

erDiagram
    users ||--o{ orders : places
    orders ||--|{ order_items : contains
    order_items }o--|| products : refers
    products }o--|| categories : belongs_to

    users {
        int id PK
        string name
        string email UK
        string password_hash
        datetime created_at
    }

    orders {
        int id PK
        int user_id FK
        int total_amount
        string status
        datetime ordered_at
    }

    order_items {
        int id PK
        int order_id FK
        int product_id FK
        int quantity
        int price
    }

    products {
        int id PK
        int category_id FK
        string name
        int price
        int stock
    }

    categories {
        int id PK
        string name
    }

読み解き方

  1. users → orders(1対多)
    • 1人のユーザーが0個以上の注文を持つ
    • orders.user_id が users.id を参照
  2. orders → order_items(1対多、必須)
    • 1つの注文に1個以上の注文明細がある
    • order_items.order_id が orders.id を参照
  3. order_items → products(多対1)
    • 注文明細は1つの商品を参照
    • order_items.product_id が products.id を参照
  4. products → categories(多対1)
    • 商品は1つのカテゴリに属する
    • products.category_id が categories.id を参照

SQLを書くときの参考

ユーザーの注文履歴を取得

SELECT o.id, o.ordered_at, o.total_amount
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE u.id = 123;

注文の明細を取得

SELECT oi.quantity, oi.price, p.name
FROM order_items oi
JOIN products p ON oi.product_id = p.id
WHERE oi.order_id = 456;

ER図を読むときのポイント

1. 主キー(PK)を確認する

  • 各テーブルのPKは何か
  • 複合主キー(複数カラムでPK)はあるか

2. 外部キー(FK)を確認する

  • どのカラムがFKか
  • どのテーブルを参照しているか
  • JOINするときの条件になる

3. リレーションの種類を確認する

  • 1対1、1対多、多対多のどれか
  • 必須か任意か(|| vs o

4. 中間テーブルを見つける

  • 多対多の関係には中間テーブルがある
  • 中間テーブルには複数のFKがある

よくあるテーブル設計パターン

マスターテーブルとトランザクションテーブル

種類説明
マスターテーブル基本情報を持つ、あまり更新されないusers, products, categories
トランザクションテーブル取引情報を持つ、頻繁に追加されるorders, order_items

履歴テーブル

変更履歴を残すためのテーブル。

erDiagram
    orders ||--o{ order_histories : has
    orders {
        int id PK
        string status
    }
    order_histories {
        int id PK
        int order_id FK
        string old_status
        string new_status
        datetime changed_at
    }

よくある疑問

外部キー制約は必ずあるか?

設計によります。外部キー制約がなくても、論理的にはリレーションが存在することがあります。ER図と実際のテーブル定義を照らし合わせましょう。

NULL可のFKはどう読むか?

例えば products.category_id がNULL可なら「カテゴリに属さない商品もある」という意味です。

自己参照はどう表現される?
将来的に

同じテーブルを参照するFK。例:組織の階層構造

erDiagram
    departments ||--o{ departments : parent
    departments {
        int id PK
        int parent_id FK
        string name
    }

ER図でよくある落とし穴

落とし穴対策
FK先のテーブルを確認しない矢印の先を必ず確認
NULL可/不可を見落とすカラム定義でNULLを確認
カーディナリティを間違える記号の意味を確認
中間テーブルの存在を見落とす多対多の関係を探す

質問例:ER図について確認するとき

ER図のorder_itemsテーブルについて確認させてください。

product_idの外部キー制約についてですが、
商品が削除された場合、order_itemsのレコードは
どうなりますか?

- CASCADE DELETE(一緒に削除)
- SET NULL(NULLになる)
- RESTRICT(削除不可)

どの設定になっていますか?

関連ドキュメント