STEP 3：ER図の基礎

ホーム > データベース設計・データモデリング > STEP 3

📊 STEP 3: ER図の読み方・書き方

データベース設計の「設計図」を読み書きできるようになろう

📋 このステップで学ぶこと
  • ER図とは何か、なぜ必要なのか
  • ER図の「読み方」をマスターする
  • エンティティとリレーションシップの「書き方」を学ぶ
  • 実践：ブログシステムのER図を作成する

学習時間の目安： 2.5時間　｜　前提知識： STEP 1-2修了

🎯 1. ER図とは何か？

STEP 2で学んだことを「図」にする

STEP 2では、以下の4つの概念を学びました。

📚 STEP 2の復習
  • エンティティ：管理したい「モノ」や「概念」（例：顧客、商品、注文）
  • 属性：エンティティが持つ情報（例：顧客名、メールアドレス）
  • リレーションシップ：エンティティ同士の関係（例：1対多、多対多）
  • カーディナリティ：関係の数量的な制約（例：(0,*)、(1,1)）

これらは「頭の中の概念」です。ER図とは、この概念を「目に見える図」にしたものです。

📝 ER図とは

ER図（Entity-Relationship Diagram）＝エンティティ・リレーションシップ図

STEP 2で学んだエンティティ、属性、リレーションシップ、カーディナリティを、図（ダイアグラム）で表現したものです。

つまり、STEP 2 = 概念を理解する、STEP 3 = 概念を図に書くという関係です。

なぜER図が必要なのか？

データベース設計をチームで共有するとき、文章だけで説明するのは大変です。

🔄 文章での説明（わかりにくい）

「顧客テーブルがあって、顧客IDと顧客名とメールアドレスを持っていて、注文テーブルは注文IDと注文日と合計金額を持っていて、注文テーブルには顧客IDがあって顧客テーブルを参照していて、1人の顧客は複数の注文ができて…」

これを図にすると、一目で構造がわかります。

【ER図での表現（わかりやすい）】 ┌─────────────┐ ┌─────────────┐ │ 顧客 │ │ 注文 │ ├─────────────┤ ├─────────────┤ │ PK: customer_id│ │ PK: order_id │ │ name │──────────<──│ FK: customer_id│ │ email │ │ order_date│ └─────────────┘ │ total │ └─────────────┘

図で見れば、「顧客と注文が関係している」「1人の顧客が複数の注文を持つ」ことが一目瞭然です。

ER図の4つのメリット

👁️ 視覚的に理解しやすい

文章で説明するより、図で見た方がわかりやすい。エンティティ同士の関係が一目瞭然。

🤝 コミュニケーションツール

技術者だけでなく、非技術者とも共有できる。「こういう構造になります」と見せられる。

🔍 設計ミスを早期発見

実装前に図で確認することで、設計の問題点に気づきやすい。修正コストが低い。

📚 ドキュメントとして価値

後から見返したり、新メンバーへの説明に使える。システムの理解が早まる。

ER図の記法について

ER図には複数の「記法（書き方のルール）」があります。主なものは2つです。

記法 特徴 使用頻度
IE記法 シンプルでわかりやすい。カラスの足（Crow’s Foot）で多を表現 ⭐⭐⭐⭐⭐ 最も普及
IDEF1X記法 厳密な表現が可能。大規模プロジェクト向け ⭐⭐⭐ 企業標準で使用
💡 このコースではIE記法を使います

IE記法は最も普及している記法で、多くのツールがサポートしています。シンプルで学習コストも低いため、まずはIE記法をマスターしましょう。IDEF1Xは、企業の標準として採用されている場合に学べば十分です。

📖 2. ER図の読み方をマスターしよう

ER図を「書く」前に、まず「読む」ことができるようになりましょう。読み方がわかれば、書き方も自然と身につきます。

ER図の3つの構成要素

ER図は、以下の3つの要素で構成されています。

┌─────────────┐ ┌─────────────┐ │ 顧客 │ │ 注文 │ ├─────────────┤ ├─────────────┤ │ PK: customer_id│ │ PK: order_id │ │ name │──────────<──│ FK: customer_id│ │ email │ │ order_date│ └─────────────┘ └─────────────┘ ↑ ↑ ↑ │ │ │ 四角形 線と記号 四角形 （エンティティ） （リレーションシップ）（エンティティ）
🎯 ER図の3つの構成要素

① 四角形 = エンティティ

管理したい「モノ」や「概念」を表す

② 四角形の中 = 属性

エンティティが持つ情報（カラム）を表す

③ 線と記号 = リレーションシップとカーディナリティ

エンティティ同士の関係と、その数量を表す

① 四角形の読み方（エンティティと属性）

四角形の中身を詳しく見てみましょう。

┌─────────────────┐ │ 顧客 (Customer) │ ← 上段：エンティティ名（日本語と英語） ├─────────────────┤ │ PK: customer_id │ ← PK = Primary Key（主キー） │ customer_name │ ← 一般の属性 │ email │ ← 一般の属性 │ phone │ ← 一般の属性 │ FK: category_id │ ← FK = Foreign Key（外部キー） └─────────────────┘
🔑 PKとFKの意味

PK（Primary Key）= 主キー

そのエンティティを一意に識別するための属性。
例：customer_id（顧客ID）で、どの顧客かを特定できる。

FK（Foreign Key）= 外部キー

他のエンティティを参照するための属性。
例：注文テーブルのcustomer_idは、顧客テーブルを参照している。

② 線と記号の読み方（リレーションシップとカーディナリティ）

線の端についている記号は、カーディナリティ（数量の制約）を表します。IE記法では以下の4種類の記号を使います。

📊 IE記法の4つの記号（これだけ覚えればOK！）
記号 意味 STEP 2での表記 読み方
──│ 必ず1つ (1, 1) 「1」
──o│ 0または1 (0, 1) 「0か1」
──< 1つ以上 (1, *) 「多（必須）」
── 0以上 (0, *) 「多（任意）」
💡 記号の覚え方

縦棒（│）= 1を表す

丸（o）= 0の可能性があることを表す

カラスの足（<）= 複数（多）を表す。鳥の足跡の形に似ているため「Crow's Foot（カラスの足）」と呼ばれます。

③ 実際にER図を読んでみよう

では、実際のER図を一緒に読んでみましょう。

【顧客と注文のER図】 ┌─────────────┐ ┌─────────────┐ │ 顧客 │ │ 注文 │ ├─────────────┤ ├─────────────┤ │ PK: customer_id│ │ PK: order_id │ │ name │───────
🔍 このER図の読み方

①エンティティの確認

「顧客」と「注文」という2つのエンティティがある

②属性の確認

顧客：customer_id（主キー）、name、email
注文：order_id（主キー）、customer_id（外部キー）、order_date、total

③リレーションシップの確認

顧客と注文が線で結ばれている → 関係がある

④カーディナリティの確認

・顧客側：記号なし（1） → 1つの注文は、必ず1人の顧客に属する
・注文側：1人の顧客は、0個以上の注文を持てる

⚠️ 読む方向に注意！

カーディナリティの記号は、相手側から見た数を表します。

・顧客側の「1」 → 注文から見て、顧客は「1人」
・注文側の「
最初は混乱しやすいので、「〜から見て」と考えると理解しやすくなります。

✏️ 3. エンティティの書き方

読み方がわかったところで、次は「書き方」を学びましょう。まずはエンティティ（四角形の部分）から始めます。

基本的なエンティティの書き方

エンティティは、四角形の中にエンティティ名と属性を書くというシンプルな形式です。

【エンティティの基本形】 ┌─────────────────┐ │ エンティティ名 │ ← 上段にエンティティ名 ├─────────────────┤ ← 区切り線 │ PK: 主キー属性 │ ← 主キーを最初に書く │ 属性1 │ │ 属性2 │ │ 属性3 │ │ FK: 外部キー属性 │ ← 外部キーは下の方に書く └─────────────────┘
📝 例：商品エンティティを書いてみよう

商品を管理するエンティティを書いてみます。
属性：商品ID、商品名、価格、在庫数、カテゴリID

【商品エンティティ】 ┌─────────────────┐ │ 商品 (Product) │ ├─────────────────┤ │ PK: product_id │ ← 主キー（商品を一意に識別） │ product_name │ │ price │ │ stock │ │ FK: category_id │ ← 外部キー（カテゴリを参照） └─────────────────┘

主キーと外部キーの書き方のルール

🔑 キーの書き方ルール

主キー（PK）の書き方

  • PK: と明記する（または下線を引く）
  • エンティティ内の一番上に書く
  • 1つのエンティティに1つが基本

外部キー（FK）の書き方

  • FK: と明記する
  • エンティティ内の下の方に書く
  • 参照先のテーブル名がわかる名前にする（例：customer_id → 顧客を参照）

複合主キーの書き方

2つ以上の属性を組み合わせて主キーにする場合、複合主キーと呼びます。

📝 例：注文詳細エンティティ

「どの注文の、どの商品か」を表すには、注文IDと商品IDの組み合わせで一意になります。

【複合主キーの例】 ┌─────────────────────┐ │ 注文詳細 (OrderDetail) │ ├─────────────────────┤ │ PK: order_id │ ← 複合主キー（その1） │ PK: product_id │ ← 複合主キー（その2） │ quantity │ │ unit_price │ └─────────────────────┘ ※ order_id と product_id の組み合わせで一意になる ※ 外部キー（FK）でもあるが、主キーとしての役割を強調してPKと書くことが多い

🔗 4. リレーションシップの書き方

次に、エンティティ同士を線で結ぶ「リレーションシップ」の書き方を学びます。シンプルな例から順番に見ていきましょう。

ステップ1：1対多のリレーションシップ（最も基本）

まずは最もよく使う「1対多」の関係から始めましょう。

📝 例：顧客と注文

・1人の顧客は、複数の注文ができる
・1つの注文は、必ず1人の顧客に属する

【1対多のER図】 ┌─────────────┐ ┌─────────────┐ │ 顧客 │ │ 注文 │ ├─────────────┤ ├─────────────┤ │ PK: customer_id│ │ PK: order_id │ │ name │───────
💡 外部キーは「多」側に書く

1対多の関係では、「多」側のエンティティに外部キーを追加します。
上の例では、注文テーブルに「customer_id」という外部キーがあり、これで「どの顧客の注文か」を表します。

ステップ2：1対1のリレーションシップ

次に、「1対1」の関係を見てみましょう。これは比較的珍しいパターンです。

📝 例：ユーザーとプロフィール詳細

・1人のユーザーは、1つのプロフィールを持つ（または持たない）
・1つのプロフィールは、必ず1人のユーザーに属する

【1対1のER図】 ┌─────────────┐ ┌──────────────┐ │ ユーザー │ │ プロフィール詳細│ ├─────────────┤ ├──────────────┤ │ PK: user_id │ │ PK: profile_id │ │ username │────────o────│ FK: user_id │ │ email │ │ bio │ └─────────────┘ │ avatar_url │ └──────────────┘ 【書き方のポイント】 1. 両側とも「1」の記号（記号なし、または縦棒） 2. 片方が任意（0もあり得る）の場合は丸（o）を追加 3. どちらか一方に外部キーを書く（通常は「従」となる側）
🤔 1対1はどんな時に使う？

1対1の関係は、以下のようなケースで使います：
・データを分割したい：頻繁にアクセスする情報と、たまにしかアクセスしない情報を分ける
・セキュリティ：機密情報を別テーブルに分離する
・オプショナルな情報：全員が持つわけではない情報を分ける

ステップ3：多対多のリレーションシップ（中間テーブル）

「多対多」の関係は、直接線で結ぶことができません。中間テーブル（連関エンティティ）を作成して表現します。

📝 例：学生と授業

・1人の学生は、複数の授業を履修できる
・1つの授業は、複数の学生が履修できる

⚠️ 多対多は直接表現できない

リレーショナルデータベースでは、多対多の関係を直接表現することができません。
そこで、「中間テーブル」を作成し、2つの1対多の関係に分解します。

【多対多のER図（中間テーブルあり）】 ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ 学生 │ │ 履修 │ │ 授業 │ ├─────────────┤ ├─────────────┤ ├─────────────┤ │ PK: student_id│ │PK: enroll_id │ │ PK: course_id │ │ name │──────│ name │ │ email │ │FK: course_id │ │ credits │ └─────────────┘ │ enrolled_at│ └─────────────┘ └─────────────┘ ↑ 中間テーブル 【読み方】 ・学生 → 履修：1人の学生は、複数の履修レコードを持てる（0以上） ・履修 → 学生：1つの履修は、必ず1人の学生に属する ・授業 → 履修：1つの授業は、複数の履修レコードを持てる（0以上） ・履修 → 授業：1つの履修は、必ず1つの授業に属する
💡 中間テーブルのメリット

中間テーブルには、関係に付随する情報（履修日、成績など）を追加できます。
上の例では「enrolled_at（履修日）」を追加しています。

ステップ4：自己参照のリレーションシップ

同じエンティティ内で関係を持つ場合、自己参照と呼びます。

📝 例1：社員と上司

社員テーブルで、「この社員の上司は誰か」を表現したい場合

【自己参照のER図：社員と上司】 ┌─────────────────┐ │ 社員 (Employee) │ ├─────────────────┤ │ PK: employee_id │──┐ │ name │ │ 自己参照 │ position │ │ │ FK: manager_id │←─┘ └─────────────────┘ 【データ例】 employee_id | name | manager_id 1 | 田中社長 | NULL（上司なし） 2 | 佐藤部長 | 1（田中社長が上司） 3 | 鈴木課長 | 2（佐藤部長が上司）
📝 例2：カテゴリの階層構造

カテゴリに親子関係を持たせたい場合（家電 → テレビ、冷蔵庫）

【自己参照のER図：カテゴリ階層】 ┌─────────────────┐ │ カテゴリ (Category) │ ├─────────────────┤ │ PK: category_id │──┐ │ category_name │ │ 自己参照 │ FK: parent_id │←─┘ └─────────────────┘ 【データ例】 category_id | category_name | parent_id 1 | 家電 | NULL（最上位） 2 | テレビ | 1（家電の子） 3 | 冷蔵庫 | 1（家電の子） 4 | 4Kテレビ | 2（テレビの子）

📝 5. 実践：ブログシステムのER図を作成しよう

ここまで学んだことを使って、ブログシステムのER図を一緒に作成してみましょう。

Step 1：要件を確認する

【ブログシステムの要件】
  • ユーザーが記事を投稿できる
  • 記事は1つのカテゴリに属する
  • 記事には複数のコメントがつけられる
  • コメントはユーザーが投稿する
  • 記事には複数のタグをつけられる（多対多）

Step 2：エンティティを抽出する

要件から、管理すべき「モノ」を洗い出します。

【抽出したエンティティ】 1. ユーザー (User) - user_id（PK） - username - email - password - created_at 2. 記事 (Post) - post_id（PK） - user_id（FK） - category_id（FK） - title - content - created_at - updated_at 3. カテゴリ (Category) - category_id（PK） - category_name 4. コメント (Comment) - comment_id（PK） - post_id（FK） - user_id（FK） - comment_text - created_at 5. タグ (Tag) - tag_id（PK） - tag_name 6. 記事タグ (PostTag) ← 多対多の中間テーブル - post_tag_id（PK） - post_id（FK） - tag_id（FK）

Step 3：リレーションシップを整理する

【リレーションシップの整理】 ① ユーザー → 記事（1対多） 1人のユーザーは、複数の記事を投稿できる ② カテゴリ → 記事（1対多） 1つのカテゴリには、複数の記事が属する ③ 記事 → コメント（1対多） 1つの記事には、複数のコメントがつく ④ ユーザー → コメント（1対多） 1人のユーザーは、複数のコメントを投稿できる ⑤ 記事 ↔ タグ（多対多 → 中間テーブルで解決） 1つの記事には複数のタグ、1つのタグは複数の記事に

Step 4：ER図を完成させる

【ブログシステムのER図】 ┌──────────┐ │ ユーザー │ ├──────────┤ │PK: user_id │ │ username │ │ email │ │ password │ │ created_at│ └──────────┘ │ │ 1対多 ├──────────────────────┐ │ │ ↓ ↓ ┌──────────┐ ┌──────────┐ │ 記事 │ │ コメント │ ├──────────┤ ├──────────┤ │PK: post_id │──────
💡 ER図作成のポイントまとめ
  • ✅ まずエンティティを全て書き出す
  • ✅ 次にリレーションシップを線で結ぶ
  • ✅ カーディナリティを正しく表記する
  • ✅ 多対多は中間テーブルで解決する
  • ✅ 読みやすいようにレイアウトを工夫する

🛠️ 6. ER図作成ツール

ER図は手書きでも作成できますが、ツールを使うと修正や共有が簡単になります。

おすすめツール

🎨 draw.io（無料）⭐おすすめ
  • 完全無料
  • Webブラウザで使える
  • ER図用のテンプレートあり
  • 初心者に最適
🔷 Lucidchart
  • 無料プランあり
  • 美しいデザイン
  • 共同編集可能
  • チーム利用に最適
🗂️ MySQL Workbench（無料）
  • MySQL公式ツール
  • ER図からDDL自動生成
  • リバースエンジニアリング可
  • 実務向け
📐 Mermaid（無料）
  • コードで図を描く
  • GitHubに埋め込める
  • バージョン管理しやすい
  • プログラマ向け
💡 初心者へのおすすめ

まずはdraw.ioから始めるのがおすすめです。無料で、直感的に操作でき、学習コストが低いです。慣れてきたら、MySQL Workbenchなどの実務向けツールに移行しましょう。

📝 STEP 3 のまとめ

✅ このステップで学んだこと
  • ER図は、STEP 2で学んだ概念を「図」にしたもの
  • 記法にはIE記法とIDEF1X記法があり、IE記法が主流
  • ER図は四角形（エンティティ）と線（リレーションシップ）で構成
  • 主キーはPK:、外部キーはFK:で明記
  • カーディナリティは4種類の記号で表現（│、o│、<、
  • 多対多は中間テーブルで2つの1対多に分解
  • ER図作成にはdraw.ioなどのツールが便利
🎯 次のステップへ

次のSTEP 4では、データ型の選択と設計を学び、より実践的なテーブル設計に進みます！

📝 練習問題

問題 1 基礎

IE記法の4つの記号（│、o│、<、
【解答】

│（縦棒）：必ず1つ (1, 1)

o│（丸＋縦棒）：0または1 (0, 1)

<（カラスの足）：1つ以上 (1, *)

：0以上 (0, *)

問題 2 基礎

以下のER図を読んで、顧客と注文の関係を日本語で説明してください。

┌─────────────┐ ┌─────────────┐ │ 顧客 │ │ 注文 │ ├─────────────┤ ├─────────────┤ │ PK: customer_id│ │ PK: order_id │ │ name │───────
【解答】

・1人の顧客は、0個以上の注文を持つことができる（

・1つの注文は、必ず1人の顧客に属する（記号なし = 1）

問題 3 応用

「部署」エンティティ（部署ID、部署名）をER図で書いてください。

【解答】
┌─────────────────┐ │ 部署 (Department) │ ├─────────────────┤ │ PK: department_id │ │ department_name │ └─────────────────┘
問題 4 応用

「部署」と「社員」の1対多の関係をER図で表現してください。
（1つの部署には複数の社員がいる、社員は必ず1つの部署に所属）

【解答】
┌──────────────┐ ┌──────────────┐ │ 部署 │ │ 社員 │ ├──────────────┤ ├──────────────┤ │PK: department │ │ PK: employee │ │ _id │───────
問題 5 発展

以下の要件からER図を作成してください。

【要件】図書館システム
・会員が本を借りる
・1冊の本は同時に1人にしか貸せない
・貸出履歴を記録したい

【解答例】
┌──────────┐ ┌──────────┐ ┌──────────┐ │ 会員 │ │ 貸出 │ │ 本 │ ├──────────┤ ├──────────┤ ├──────────┤ │PK: member │ │PK: loan_id │ │PK: book_id │ │ _id │──

ポイント：「貸出」テーブルを作ることで、履歴を記録できます。status（貸出中/返却済み）で現在の状態を管理すれば、「1冊の本は同時に1人にしか貸せない」という制約もアプリケーション側で制御できます。

❓ よくある質問

Q1: ER図は手書きでもいいですか？

手書きでも全く問題ありません！特に学習段階では、紙とペンで書く方が理解が深まることもあります。

ただし、実務では修正が簡単、きれいに整形できる、チームで共有しやすい、DDLを自動生成できるなどの理由でツールを使うことが多いです。

Q2: 記号を覚えられません。コツはありますか？

以下のように覚えると楽です：

  • 縦棒（│）→ 数字の「1」に見える → 「1」
  • 丸（o）→ 数字の「0」に見える → 「0の可能性あり」
  • カラスの足（<）→ 足跡がたくさん → 「多」

実際に何度か書いてみれば、すぐに覚えられます。

Q3: 外部キーはどちら側に書けばいいですか？

「多」側のエンティティに外部キーを書きます。

例：顧客（1）と注文（多）の関係では、注文テーブルにcustomer_id（外部キー）を追加します。これで「どの顧客の注文か」を表現できます。

Q4: ER図に属性を全部書く必要がありますか？

場合によります。概念設計の段階では主要な属性だけを書いて全体の構造を理解しやすくし、論理設計・物理設計の段階ではすべての属性を書いて詳細な設計書として使います。

Q5: 多対多を中間テーブルなしで表現できませんか？

リレーショナルデータベースでは、中間テーブルなしでは表現できません。

これはリレーショナルデータベースの仕組み上の制約です。多対多の関係は必ず中間テーブルを作成し、2つの1対多の関係に分解して表現します。

← 前のステップ
STEP 2: エンティティとリレーションシップ 次のステップへ →
STEP 4: データ型の選択と設計
📝

学習メモ

データベース設計・データモデリング - Step 3

💾 自動保存 · 0文字
📋 過去のメモ一覧 ▼
#artnasekai #学習メモ
LINE
ホーム
データベース設計・データモデリング