レッスンテキスト | 005 データベースの設計図であるER図を作成しよう

ER図とは？

建物を建てる際に設計図が必要なように、システムを開発する際にもデータの設計図が必要です。その1つがER図（Entity-Relationship Diagram）です。
ER図とは、データベースの設計図のようなもので、システムが扱うデータがどのように関連し合っているかを図で表したものです。

ER図で分かること

ER図では以下のことを知ることができます。

どんなデータが必要か？
（例：顧客データ、商品データ、注文データなど）
データ同士がどのように関連しているか？
（例：顧客は注文を行う、商品は注文に含まれるなど）

実際の開発現場でのER図の用途

1. 関係者間の共通言語として

システム開発には、プログラマー、デザイナー、営業担当者など、様々な立場の人が関わります。
ER図は、これらの関係者がデータベースの構造について共通の認識を持つための、共通言語として機能します。
図を見ることで、言葉だけでは伝わりにくい複雑なデータ構造も、簡単に理解できるようになります。
ER図を見ながらミーティングするということもしばしば行われます。

2. 設計のミスを防ぐ

ER図を作成することで、設計段階でデータの矛盾や不備を発見しやすくなります。

「データが重複している」
「必要なデータが不足している」
「データの関連付けが間違っている」

といった問題点を早期に発見し、修正することで、後工程での手戻りを減らし、開発効率を高めることができます。

3. 開発後の保守・運用を容易にする

システムは開発して終わりではありません。その後も長く使われ、必要に応じて修正や機能追加が行われます。
ER図があれば、データベースの構造が明確になるため、保守・運用作業がスムーズに進みます。

例えば、
「顧客の住所を変更する場合、どのデータに影響があるか？」
といったことを容易に把握できます。

4. システムの拡張時にも便利

ER図を見れば、どこにどのデータがあるのか分かるため、新しい機能を開発するときにも役に立ちます。

ER図の作り方

それぞれのテーブルの関連を以下の3つのテーブルを用いたサンプル元に、ER図の作成方法について学びます。

売上テーブル (sales)
商品テーブル (items)
商品カテゴリマスタ (item_categories)

それぞれのテーブル構造は以下通りです。

売上テーブル (sales)

商品ごとの売上データを管理します。

フィールド名	データ型	制約	説明
id	INT	PRIMARY KEY, AUTO_INCREMENT	売上ID (ユニーク識別子)
item_id	INT	NOT NULL, FOREIGN KEY	商品ID (itemsテーブルへの外部キー)
sale_date	DATE	NOT NULL	売上日
quantity	INT	NOT NULL	売上数量
total_price	DECIMAL(10,2)	NOT NULL	売上金額

商品テーブル (items)

商品情報を管理します。

フィールド名	データ型	制約	説明
id	INT	PRIMARY KEY, AUTO_INCREMENT	商品ID (ユニーク識別子)
name	VARCHAR(100)	NOT NULL	商品名
category_id	INT	FOREIGN KEY	カテゴリID (item_categoriesテーブルへの外部キー)
price	DECIMAL(10,2)	NOT NULL	商品価格
stock_quantity	INT	NOT NULL	在庫数量

商品カテゴリマスタ (item_categories)

商品のカテゴリ情報を管理します。

フィールド名	データ型	制約	説明
id	INT	PRIMARY KEY, AUTO_INCREMENT	カテゴリID (ユニーク識別子)
name	VARCHAR(50)	NOT NULL	カテゴリ名

上記の３つのテーブルからER図を作成します。

ER図の解説図

シンプルなER図の薦め

ER図は厳密な書き方というものがなく、人によって書き方に差が出てきます。見本ではsales,items,item_idなど名称を使っていますが、「売上テーブル」、「商品マスタ」、「商品ID」といった日本語の名称で書いてもOKです。詳細に意味を伝えるため、もっと細かく、様々な記号が用いたER図も存在します。とはいえ、大抵はシンプルなER図で十分です。現場でもあまり細かい部分を記述することはしないことがほとんどです。

外部キーについて

注目のポイントは外部キーです。前回のレッスンの"正規化"で、２つのテーブルをIDで結び付けていました。これらのIDはしばしば外部キーと呼ばれます。 sales(売上テーブル)のitem_idや、itemsテーブルのcategory_idがそうです。

売上テーブルのitem_idは、商品テーブルのidを外部キーとして参照します。
商品テーブルのcategory_idは、商品カテゴリマスタのidを外部キーとして参照します。

「1:多」、「多:1」について説明

多:1 の関係（売上テーブルから見た商品テーブル）

説明:
売上テーブルの各レコード（行）は、1つの特定の商品に関連付けられます。
つまり、売上テーブルから見ると、多くの売上データが1つの商品に紐づく関係です。
「N:1」とも書き表されます。
リレーション:
売上テーブルのitem_idは、商品テーブルのidを参照します。
実例:

商品テーブルの商品 リンゴ が販売され、売上テーブルに3件記録されている場合、リンゴ は売上テーブル内で複数回参照されます。

テーブル構造

商品テーブル (items)

id (商品ID) name price

100 リンゴ 100.00

200 バナナ 50.00
売上テーブル (items)

id (売上ID) item_id(商品ID) sale_date quantity total_price

1 100 2025-01-01 3 300.00

2 100 2025-01-02 2 200.00

3 200 2025-01-01 5 250.00

4 100 2025-01-05 3 300.00

id (商品ID)	name	price
100	リンゴ	100.00
200	バナナ	50.00

id (売上ID)	item_id(商品ID)	sale_date	quantity	total_price
1	100	2025-01-01	3	300.00
2	100	2025-01-02	2	200.00
3	200	2025-01-01	5	250.00
4	100	2025-01-05	3	300.00

1:多の関係（商品テーブルから見た売上テーブル）

説明:
商品テーブルの1つの商品に対して、売上テーブルには複数の売上データが存在します。
つまり、商品テーブルから見ると、1つの商品が複数の売上に紐づく関係です。
「1:N」とも書き表されることもあります。
実例:
商品 リンゴ は、複数の日に販売されており、その売上が売上テーブルに複数回記録されています。

リレーション（1:多）

商品テーブルのidは、売上テーブルのitem_idに関連します。
1つの商品 (id=100) が複数の売上 (id=1, 2, 4) に紐づくため、「1:多」の関係になります。

4. まとめ

多:1 → 売上テーブルから商品テーブルを見る場合
売上データは特定の1つの商品に紐づく。
1:多 → 商品テーブルから売上テーブルを見る場合
商品は複数の売上データに紐づく。

このように「1:多」や「多:1」の関係性を考えることで、データベース設計時に各テーブル間のつながりを明確にし、効率的なクエリやリレーションの設計が可能になります。

---

補足: 特殊な関係について

多くのテーブル同士の関係は「1:多」、「多:1」ですが、以下のような特殊な関係になることもたまにあります。

1:1 の関係
1つのレコードが他のテーブルの1つのレコードとだけ関連する関係。
例: ユーザーとプロフィール。
多:多の関係
複数のレコード同士が相互に関連する関係。
中間テーブルを使用して表現する。
例: 学生と授業。
0:1 の関係
テーブルAのレコードがテーブルBのレコードに関連する場合もあれば、関連しない場合もある関係。
例: 顧客と会員情報。

ER図作成ツールについて

ER図を作成するためのツールはたくさんあります。中にはExcelを使って作成する人や、紙に手書きで描く人もいます。それぞれに特徴があるので、自分に合った方法を気軽に試してみてください。以下は有名なER図作成ツールです。

ツール名	特徴	対応	おすすめポイント
dbdiagram.io	シンプルで使いやすい。テキストベースでER図を作成可能。	テーブル構造の定義やエクスポート（SQL/画像）。	開発者向けのシンプルなツール。
draw.io (diagrams.net)	無料で使える汎用的な図作成ツール。ER図専用テンプレート有。	オフライン版やGoogle Drive/OneDrive連携可。	汎用性が高く、他の図表も同時に作成可能。
Lucidchart (無料版)	ドラッグ＆ドロップで簡単にER図を作成可能。	無料版は図作成に制限があるが個人利用に十分。	直感的な操作性で初心者にもおすすめ。
SQLDBM	SQLベースでER図を作成可能。データベース設計に特化。	MySQL、PostgreSQL、SQL Serverをサポート。	SQL開発者向け。機能が豊富。
DbDesigner.net	クラウドベースのER図作成ツール。UIが洗練されている。	MySQLやPostgreSQLのエクスポート対応。	チームでのコラボレーションが可能。
QuickDBD	テキスト記述で即座にER図を生成可能。	テキストベースで効率的に作業可能。	シンプルで軽量。
Vertabelo (無料版)	Webブラウザで直接ER図作成可能。	SQLスクリプトのインポート/エクスポート対応。	データベース設計に特化したプロ向けツール。

私個人としては、さまざまな設計図が作成できる draw.io を利用しています。特に、作成したER図をSVG形式でエクスポートできる点が魅力です。エクスポートしたSVG形式のER図は、取引先やチームに共有し、ブラウザで簡単に確認してもらえるため、非常に便利です。

ER図作成練習問題

以下の４つのテーブルからER図を作成してください。

1. 求人テーブル (jobs)

求人情報を管理するテーブル。

フィールド名	データ型	制約	説明
id	INT	PRIMARY KEY, AUTO_INCREMENT	求人ID（ユニーク識別子）
title	VARCHAR(255)	NOT NULL	求人タイトル
description	TEXT	NOT NULL	求人の詳細情報
salary	DECIMAL(10,2)	NOT NULL	給与
prefecture_id	INT	NOT NULL, FOREIGN KEY	都道府県ID（都道府県テーブルへの外部キー）
created_at	DATETIME	NOT NULL	求人作成日時

2. 応募テーブル (applications)

求職者が求人に応募した情報を管理するトランザクションテーブル。

フィールド名	データ型	制約	説明
id	INT	PRIMARY KEY, AUTO_INCREMENT	応募ID（ユニーク識別子）
job_id	INT	NOT NULL, FOREIGN KEY	求人ID（求人テーブルへの外部キー）
job_seeker_id	INT	NOT NULL, FOREIGN KEY	求職者ID（求職者テーブルへの外部キー）
application_date	DATE	NOT NULL	応募日時

3. 求職者テーブル (job_seekers)

求職者の情報を管理するテーブル。

フィールド名	データ型	制約	説明
id	INT	PRIMARY KEY, AUTO_INCREMENT	求職者ID（ユニーク識別子）
name	VARCHAR(255)	NOT NULL	求職者名
email	VARCHAR(255)	NOT NULL, UNIQUE	求職者のメールアドレス
phone_number	VARCHAR(15)	NOT NULL	電話番号
prefecture_id	INT	NOT NULL, FOREIGN KEY	都道府県ID（都道府県テーブルへの外部キー）

4. 都道府県テーブル (prefectures)

都道府県情報を管理するテーブル。

フィールド名	データ型	制約	説明
id	INT	PRIMARY KEY, AUTO_INCREMENT	都道府県ID（ユニーク識別子）
name	VARCHAR(50)	NOT NULL	都道府県名

リレーションの要件

求人テーブル (jobs)

都道府県テーブル (prefectures) の id を外部キーとして参照します。

応募テーブル (applications)

求人テーブル (jobs) の id を外部キーとして参照します。
求職者テーブル (job_seekers) の id を外部キーとして参照します。

求職者テーブル (job_seekers)

都道府県テーブル (prefectures) の id を外部キーとして参照します。

ヒント

求職者と都道府県が「多:1」の関係。
求人と都道府県が「多:1」の関係。
応募と求人、求職者が「多:1」の関係。

レッスンテキスト | 005 データベースの設計図であるER図を作成しよう | ワクガンス