DB設計
#04 データベースを設計する

ER図でテーブルの関係を描く

エンティティを洗い出し、正規化でデータ構造を整理したら、それを図として表現するのがER図です。 ER図? Entity-Relationship Diagram。エンティティ（テーブル）とその間の関係（リレーション）を視覚化した設計図。DBの構造を理解・共有するために使う。 は設計チーム内でのコミュニケーションや、ドキュメントとして残すときに欠かせないものです。

ER図の記法

ER図にはいくつかの記法がありますが、現在もっとも広く使われているのがCrow’s Foot（鳥の足）記法です。テーブル間のリレーションの「多重度」を線の端のマークで表現します。

ER図の記法 — Crow's Foot（鳥の足）表記 1対1（One-to-One） users profiles 必ず1 対 必ず1 例：ユーザー / プロフィール 1対多（One-to-Many） users orders 必ず1 対 0以上 例：ユーザー / 注文 多対多（Many-to-Many） products order _items orders 中間テーブルで実現 例：商品 / 注文明細 / 注文 カーディナリティ記号の一覧 || = 必ず1つ そのエンティティは必ず存在する |o = 0または1つ（任意） 存在しない場合もある }| = 1以上（必須・複数可） 少なくとも1つは存在する }o = 0以上（任意・複数可） 0件のことも、複数のこともある 読み方の例 users ||--}o orders 「1人のユーザーは0件以上の注文を持つ。1つの注文は必ず1人のユーザーに属する。」
図1: Crow's Foot記法の説明

カーディナリティの表現

カーディナリティ? テーブル間の関係の多重度。1対1（一人のユーザーが一つのプロフィール）・1対多（一人のユーザーが複数の注文）・多対多（商品と注文）の3種類がある。 （多重度）は、エンティティ間に何対何の関係があるかを示します。

記号意味
`
`o`
`}`
}o0以上（0か複数）

3種類のリレーション

1対1（One-to-One）

1人のユーザーに対して、1つのプロフィールが対応する関係です。

users ||--|| user_profiles

1対多（One-to-Many）

1人のユーザーが複数の注文を持てる関係です。

users ||--}o orders

多対多（Many-to-Many）

多対多? 両テーブルのある行が相手テーブルの複数行と対応する関係。「学生と科目（一人が複数科目を受講、一科目に複数の学生）」が例。中間テーブル（関連テーブル）で実現する。 の関係は、直接は表現できません。 中間テーブル? 多対多の関係を実現するために使う結合専用のテーブル。`student_courses(student_id, course_id)` のように両テーブルの外部キーを持つ。 （中間テーブル）を使って2つの「1対多」に分解します。

products ||--}o order_items o{--|| orders

ECサイトのER図

ECサイトのER図（主要4テーブル） users PK id name email password created_at updated_at UNIQUE: email categories PK id name slug UNIQUE: slug products PK id FK category_id name description price stock created_at updated_at SET NULL on cat delete orders PK id FK user_id shipping_address total_price status ordered_at RESTRICT on user delete order_items PK id FK order_id FK product_id quantity unit_price CASCADE on order delete UNIQUE(order_id, product_id) RESTRICT on product delete 1人のユーザーは複数の注文を持つ 1つのカテゴリに複数商品 1つの注文に複数明細 1商品が複数注文に
図2: ECサイトのER図（主要テーブル）

ECサイトの主要4テーブルについてER図を読み解いてみましょう。

テーブル定義

-- ユーザー
users
  id          PK
  name
  email
  created_at

-- 商品
products
  id          PK
  category_id FK -> categories.id
  name
  price
  stock

-- 注文
orders
  id          PK
  user_id     FK -> users.id
  total_price
  ordered_at

-- 注文明細（中間テーブル）
order_items
  id          PK
  order_id    FK -> orders.id
  product_id  FK -> products.id
  quantity
  unit_price

リレーションの読み方

users → orders: 1人のユーザーは0件以上の注文を持てる。1つの注文は必ず1人のユーザーに属する。

orders → order_items: 1つの注文は1件以上の注文明細を持つ。1つの注文明細は必ず1つの注文に属する。

products → order_items: 1つの商品は0件以上の注文明細に含まれる。1つの注文明細は必ず1つの商品を参照する。

order_items が orders と products の間に入ることで、多対多の関係が実現されています。「1つの注文に複数の商品」かつ「1つの商品が複数の注文に含まれる」という関係です。

ER図から読み取れること

ER図をじっくり眺めると、設計上の疑問や問題が見えてきます。

疑問の例:

  • order_items に unit_price があるのはなぜ？ → 注文後に商品価格が変わっても注文時の価格を保持するため
  • categories と products の関係は？ → 1つのカテゴリに複数商品が属する（1対多）
  • カートはどう管理する？ → carts テーブルと cart_items テーブルが必要

ER図を見ながらこのような「なぜ？」を問い続けることが、設計の品質を高めます。

ER図を描くツール

実務でよく使われるツールを紹介します。

draw.io（無料）

ブラウザで使えるダイアグラム作成ツールです。ER図のシェイプが揃っており、Google Drive との連携も可能です。

URL: https://draw.io

dbdiagram.io（無料プランあり）

テキスト（DBML記法）でER図を書くと、自動的に図が生成されます。コードとして管理できるのが特徴です。

Table users {
  id bigint [pk, increment]
  name varchar(100) [not null]
  email varchar(255) [not null, unique]
}

Table orders {
  id bigint [pk, increment]
  user_id bigint [ref: > users.id]
  total_price int [not null]
}

URL: https://dbdiagram.io

その他

  • MySQL Workbench — MySQL の公式GUIツール。ER図からDDLを自動生成できる
  • DataGrip — JetBrains製のDB管理ツール。既存スキーマからER図を逆生成できる

ER図を描くときのコツ

  1. 全部を1枚に詰め込まない — テーブルが多い場合は、機能ごとにサブセット図を作る
  2. 主キーと外部キーを明示する — PK/FK の記号を必ず入れる
  3. 定期的に更新する — 実装が進むにつれてER図も更新し、常に現状を反映させる
  4. チームでレビューする — ER図は仕様のコミュニケーションツールでもある

まとめ

ER図はデータベース設計の「完成図」です。エンティティ、属性、リレーション、カーディナリティを正確に表現することで、実装前にチーム全員が同じ認識を持てます。

次回はER図を実際のSQLに落とし込む際の重要な要素、外部キーについて詳しく解説します。