ER図とは？データベース設計の基本や読み方を初心者向けにわかりやすく解説【図解付き】

はじめに

データベース設計について勉強していると、ER図という言葉が登場します。

システム開発の現場では、顧客、商品、注文、従業員など、さまざまなデータを管理します。

しかし、必要なデータを思いつくまま一つの表へ詰め込んでしまうと、次のような問題が起こります。

• 同じ情報を何度も登録する
• データの更新漏れが発生する
• どのデータがどれと関係しているのか分からない
• テーブルが複雑になり、システムを変更しにくい
• 不要な重複や矛盾が発生する

このような問題を防ぎ、データ同士の関係を整理するために使われるのがER図です。

ER図を一言で表すと、

「システムで管理するものと、その関係を図で表したもの」

です。

ただし、初めてER図を見ると、

• 四角い箱は何を表しているのか
• 線の端にある鳥の足のような記号は何なのか
• エンティティとテーブルは同じなのか
• 主キーと外部キーはどのように関係するのか
• 1対多や多対多とは何なのか
• クラス図やデータフロー図とは何が違うのか

と疑問に思う方も多いのではないでしょうか。

この記事では、ER図の意味や構成要素、カーディナリティ、主キー・外部キー、多対多を解消する中間テーブルについて、AさんとBさんの会話を中心に初心者向けにわかりやすく解説します。

ER図とは？

ER図はデータベースで管理するものと、それらの関係を図にしたものだよ。

データベースの設計図みたいなもの？

そのイメージでいいよ。どのようなデータを保存し、データ同士をどう関連付けるかを整理するために使うんだ。

ER図のERは、次の英語の頭文字です。

• Entity：エンティティ
• Relationship：リレーションシップ

そのため、ER図は英語でEntity Relationship Diagramと呼ばれます。

日本語では、実体関連図と表現されることもあります。

ER図では、主に次の三つを表します。

ER図を学校の名簿で例えてみよう

管理するものと関係と言われても、まだ少し分かりにくいな。

学校の情報を管理する場合で考えてみよう。

学校では、例えば次のようなものを管理します。

• 生徒
• クラス
• 先生
• 教科
• 成績

これらが、ER図におけるエンティティの候補です。

さらに、それぞれの対象には情報があります。

生徒が持つ情報

• 生徒番号
• 氏名
• 生年月日
• 所属クラス

クラスが持つ情報

• クラス番号
• クラス名
• 担任の先生

生徒やクラスがエンティティで、生徒番号や氏名が属性なんだね。

そう。そして「生徒はクラスに所属する」というつながりがリレーションシップだよ。

例えば、簡単に表すと次のようになります。

クラス ─── 生徒
  1          　　多

一つのクラスには複数の生徒が所属します。

一方、一人の生徒が所属するクラスは一つとします。

この関係を1対多と呼びます。

ER図を構成する三つの要素

エンティティとは？

エンティティとは、データベースで情報を管理したい対象のことです。

例えば、ECサイトでは次のようなエンティティが考えられます。

• 顧客
• 商品
• 注文
• 注文明細
• 支払い
• 配送先

現実世界にあるものを、そのままエンティティにするの？

人や商品などの物だけではないよ。注文や契約のような出来事もエンティティになるんだ。

エンティティになり得るものを整理すると、次のようになります。

属性とは？

属性とは、エンティティが持つ具体的な情報です。

例えば、顧客エンティティには次のような属性があります。

ER図では、エンティティを四角形で表し、その中に属性を記載することがあります。

┌──────────────┐
│ 顧客           │
├──────────────┤
│ 顧客ID         │
│ 氏名           │
│ メールアドレス │
│ 登録日         │
└──────────────┘

属性は、テーブルでいう列に近いの？

論理設計や物理設計のER図では、属性がテーブルの列に対応することが多いよ。

リレーションシップとは？

リレーションシップとは、エンティティ同士の関係です。

例えば、ECサイトでは次のような関係があります。

• 顧客が注文する
• 注文には商品が含まれる
• 商品はカテゴリに分類される
• 注文に配送先が設定される

箱と箱を結ぶ線がリレーションシップなんだね。

そう。線だけでなく、関係の数を表す記号も重要だよ。

主キーとは？

データを一意に識別する項目

主キーとは、テーブル内のデータを一件ずつ識別するための項目です。

英語ではPrimary Keyといい、PKと省略されます。

例えば、次の顧客データを考えてみましょう。

同姓同名の人がいるため、氏名だけでは顧客を区別できません。

そこで、顧客IDを主キーとして使用します。

主キーの値は重複してはいけないんだね。

そう。原則としてNULLにもできないよ。

主キーには、次の特徴があります。

• 値が重複しない
• NULLを許可しない
• 一件のデータを一意に特定できる
• 頻繁に変更されない値が望ましい

自然キーと代理キー

主キーには、既存の業務データを使う方法と、識別専用の番号を作る方法があります。

メールアドレスも重複しないなら主キーにできる？

技術的には可能な場合もあるけれど、変更される可能性があるよね。変更されにくい代理キーを使う設計も多いよ。

外部キーとは？

別のテーブルのデータを参照する項目

外部キーとは、別のテーブルの主キーなどを参照し、テーブル同士を関連付ける項目です。

英語ではForeign Keyといい、FKと省略されます。

例えば、顧客テーブルと注文テーブルを考えてみましょう。

顧客テーブル

注文テーブル

注文テーブルの顧客IDは、顧客テーブルの顧客IDを参照しています。

顧客
PK 顧客ID
      │
      │ 1対多
      ▼
注文
PK 注文ID
FK 顧客ID

注文テーブルを見ると、どの顧客が注文したのか分かるんだね。

そう。外部キーによって、別々のテーブルに保存したデータを結び付けられるんだ。

主キーと外部キーの違い

注文テーブルでは、同じ顧客IDが何度も登場しているね。

一人の顧客が複数回注文できるからだよ。外部キーは必ずしも一意ではないんだ。

カーディナリティとは？

エンティティ同士の数の関係

カーディナリティとは、エンティティ同士が何件ずつ対応するかを表すものです。

ER図では、主に次の関係を扱います。

• 1対1
• 1対多
• 多対多

ER図の線の端にある記号は、この数を表しているの？

そう。線の端に「1」や鳥の足のような記号を付けて、関係する件数を表すんだ。

1対1とは？

1対1は、一方のデータ一件に対し、もう一方のデータも一件だけ対応する関係です。

例えば、次のような関係があります。

• 一人の社員に一つの社員証を発行する
• 一つのアカウントに一つの詳細設定を持たせる
• 一人の利用者に一つのプロフィールを持たせる

社員 1 ─── 1 社員証

ただし、現実の業務ルールによっては、一人が社員証を再発行するなどして複数の履歴を持つ場合があります。

ER図では、現実の言葉だけでなく、システム上どのように管理するかを明確にする必要があります。

1対多とは？

1対多は、一方の一件に対し、もう一方が複数件対応する関係です。

例えば、

• 一人の顧客が複数の注文を行う
• 一つの部署に複数の社員が所属する
• 一つのカテゴリに複数の商品が属する

といった関係です。

顧客 1 ─── 多 注文

関係を反対側から見ると、複数の注文は一人の顧客に対応します。

1対多は、データベースでよく使いそうだね。

そう。リレーショナルデータベースでは非常によく登場する関係だよ。

多対多とは？

多対多は、一方の複数件と、もう一方の複数件が対応する関係です。

例えば、

• 一人の学生が複数の授業を受講する
• 一つの授業を複数の学生が受講する

という関係があります。

学生 多 ─── 多 授業

ECサイトでは、注文と商品の関係も多対多です。

• 一つの注文に複数の商品が含まれる
• 一つの商品が複数の注文に含まれる

多対多のままテーブルを作れるの？

リレーショナルデータベースでは、通常は中間テーブルを作って、二つの1対多に分解するよ。

中間テーブルとは？

多対多を二つの1対多へ分解する

学生と授業の多対多を考えてみましょう。

多対多の関係を表すために、履修という中間テーブルを作ります。

学生 1 ─── 多 履修 多 ─── 1 授業

学生テーブル

授業テーブル

履修テーブル

履修テーブルには、学生と授業の組合せを記録します。

山田さんが二つの授業を履修し、データベースの授業には二人の学生がいることを表せるね。

そう。中間テーブルには、履修年度や成績など、関係そのものが持つ情報も保存できるよ。

ECサイトにおける中間テーブル

注文と商品の間には、注文明細という中間テーブルを置くのが一般的です。

注文 1 ─── 多 注文明細 多 ─── 1 商品

注文明細には、次のような情報を保存します。

• 注文ID
• 商品ID
• 数量
• 注文時の単価
• 小計

数量は注文の情報でも、商品そのものの情報でもないね。

そう。特定の注文に特定の商品を何個含めたかという、関係に属する情報なんだ。

最小カーディナリティと最大カーディナリティ

ER図では、「最大で何件対応するか」だけでなく、「最低何件必要か」を表すこともあります。

例えば、次のような表記です。

例えば、顧客と注文の関係では、次のように考えられます。

• 顧客は、まだ注文していない可能性がある
• 一件の注文には、必ず一人の顧客が対応する

顧客 1 ─── 0以上 注文

顧客登録したばかりなら、注文が0件でもおかしくないね。

そう。このように、関係が必須か任意かもER図で表せるんだ。

カラスの足記法とは？

ER図の表記方法の一つに、カラスの足記法があります。

英語では、Crow’s Foot Notationと呼ばれます。

複数を表す記号が、鳥の足のように三方向へ分かれて見えることが名前の由来です。

簡略化して表すと、次のようなイメージです。

記号を組み合わせて、0か1か、多いかを表すんだね。

そう。ただし、ER図には複数の記法があるので、使っている記法を確認する必要があるよ。

ER図の主な記法

ER図には、いくつかの表記方法があります。

IE記法

IEは、Information Engineeringの略です。

カラスの足記法を使い、現在のシステム開発でよく見かける表記方法です。

エンティティの中に属性を記述し、線の端の記号でカーディナリティを表します。

IDEF1X記法

IDEF1Xは、データモデルを詳細に表すための記法です。

主キーや外部キー、識別関係などを明確に表しやすく、データベースの論理設計や物理設計で利用されます。

Chen記法

Chen記法では、次のように図形を使い分けます。

同じER図でも、見た目が違うことがあるんだね。

そう。大切なのは、どの記号が何を意味しているかを確認することだよ。

ER図の種類

ER図は、設計段階によって内容の細かさが異なります。

主に、次の三つに分けて説明されます。

• 概念ER図
• 論理ER図
• 物理ER図

概念ER図とは？

概念ER図は、業務でどのような対象を管理し、それらがどう関係しているかを大まかに表します。

例えば、

顧客 ─ 注文 ─ 商品

のように、主要なエンティティと関係を整理します。

データ型や細かな列までは記載しないことが一般的です。

業務の全体像を考える段階だね。

論理ER図とは？

論理ER図では、エンティティ、属性、主キー、外部キー、カーディナリティなどを具体的に整理します。

ただし、特定のデータベース製品に依存する詳細までは決めない場合があります。

例えば、顧客エンティティに次の属性を定義します。

• 顧客ID
• 氏名
• メールアドレス
• 登録日

物理ER図とは？

物理ER図では、実際に使用するデータベース製品に合わせてテーブルを設計します。

例えば、次のような内容を定義します。

• 実際のテーブル名
• カラム名
• データ型
• 文字数
• NULLの可否
• 主キー
• 外部キー
• インデックス
• 制約

ER図を作る基本的な手順

1．業務で管理する対象を洗い出す

まず、システムで管理する対象を探します。

例えば、ECサイトであれば次のような名詞が候補になります。

• 顧客
• 商品
• 注文
• 支払い
• 配送
• カテゴリ

ただし、文章に登場するすべての名詞をエンティティにするわけではありません。

システムで独立して管理する必要があるかを考えます。

2．エンティティの属性を決める

各エンティティが持つ情報を整理します。

例えば、商品エンティティであれば次のようになります。

• 商品ID
• 商品名
• 価格
• 在庫数
• カテゴリID

3．主キーを決める

各エンティティのデータを一意に識別できる項目を決めます。

• 顧客ID
• 商品ID
• 注文ID

などです。

4．エンティティ同士の関係を整理する

次に、エンティティ同士がどのようにつながるかを考えます。

• 顧客が注文する
• 注文に商品を含める
• 商品がカテゴリに属する

文章で関係を表すと整理しやすくなります。

5．カーディナリティを決める

一つのデータに対し、相手側のデータが何件対応するかを考えます。

• 一人の顧客は何件の注文を持てるか
• 一件の注文は何人の顧客に属するか
• 一つの商品は何個のカテゴリに属するか

業務ルールを確認しながら決めます。

6．多対多を解消する

多対多の関係があれば、中間エンティティを追加して二つの1対多へ分解します。

7．正規化や業務ルールと照らし合わせる

データの重複や更新時の矛盾が発生しないかを確認します。

必要に応じて正規化を行い、エンティティや属性を分割します。

ER図と正規化の関係

ER図を作れば、データの重複は自動的になくなるの？

自動的にはなくならないよ。そこで関係するのが正規化だよ。

正規化とは、データの重複や更新時の矛盾を減らすために、テーブルを適切に分割する考え方です。

例えば、注文テーブルに毎回顧客の住所や電話番号を保存すると、同じ顧客情報が何度も重複します。

そこで、

• 顧客テーブル
• 注文テーブル

に分け、顧客IDで関連付けます。

正規化で考えたテーブル構造を、ER図で見えるようにできるんだね。

そう。両方を組み合わせてデータベースを設計するんだ。

ER図とテーブルの違い

ER図の箱は、そのままデータベースのテーブルなの？

論理ER図や物理ER図では、エンティティがテーブルに対応することが多いよ。でも必ず完全に同じとは限らないんだ。

概念設計では一つのエンティティでも、実装時には複数のテーブルへ分ける場合があります。

反対に、性能や運用上の理由から複数の概念を一つのテーブルで管理することもあります。

ER図とテーブル定義書の違い

テーブル定義書は、実際のテーブルやカラムの仕様を詳しく記載する文書です。

ER図で全体像を確認して、テーブル定義書で細部を確認するんだね。

ER図とクラス図の違い

クラス図は、UMLで使用される図の一つです。

システム内のクラスが持つ属性や操作、クラス同士の関係を表します。

見た目が似ていても、目的が違うんだね。

そう。ER図は主に保存するデータの関係、クラス図はプログラム上の構造を表すよ。

ER図とDFDの違い

DFDは、Data Flow Diagramの略で、日本語ではデータフロー図と呼ばれます。

システムの中で、データがどこから入り、どの処理を通り、どこへ出ていくかを表します。

ER図はデータの住所録、DFDはデータの移動経路みたいなものだね。

ER図とフローチャートの違い

ER図の線は、処理が進む順番を表しているわけではありません。

ER図を作るメリット

データの全体像を把握できる

文章やテーブルの一覧だけでは分かりにくい関係を、図として確認できます。

特にテーブル数が多いシステムでは、全体構造の理解に役立ちます。

関係者と認識を合わせやすい

開発者、データベース担当者、業務担当者などが同じ図を見ながら、設計内容を確認できます。

例えば、

• 一人の顧客が複数の住所を登録できるのか
• 商品は複数のカテゴリに所属できるのか
• 退会した顧客の注文履歴を残すのか

といった業務ルールを話し合いやすくなります。

設計上の問題を早く発見できる

ER図を作ることで、次のような問題に気づきやすくなります。

• 主キーが決まっていない
• 不要な重複データがある
• 多対多が解消されていない
• 外部キーの参照先が不明
• 必要なエンティティが不足している
• 関係の必須・任意が曖昧

システムの保守や改修に役立つ

既存システムを変更するとき、どのテーブルが関連しているかをER図で確認できます。

一つのテーブル変更が、どこへ影響するのかを調査しやすくなります。

ER図のデメリット・注意点

大規模になると見づらい

テーブル数が数十、数百と増えると、すべてを一枚のER図に載せるのは難しくなります。

業務領域ごとに図を分割するなどの工夫が必要です。

最新の状態を維持する必要がある

データベースを変更してもER図を更新しなければ、実際のシステムと設計書が一致しなくなります。

古いER図は、誤解や設計ミスの原因になります。

業務処理の流れまでは分からない

ER図から、データ同士の関係は分かります。

しかし、

• どの順番で処理するのか
• どの条件で分岐するのか
• 誰が入力するのか
• いつデータが更新されるのか

といった処理の流れは、ER図だけでは十分に表せません。

フローチャート、DFD、シーケンス図など、別の設計資料も必要です。

記法が違うと読み間違える可能性がある

IE記法、IDEF1X記法、Chen記法などでは、使われる記号が異なります。

図を読む前に、どの記法が使われているか確認しましょう。

簡単なECサイトのER図を考えてみよう

ECサイトに次の四つのエンティティがあるとします。

• 顧客
• 注文
• 注文明細
• 商品

関係は次のようになります。

顧客 1 ─── 多 注文
注文 1 ─── 多 注文明細
商品 1 ─── 多 注文明細

これを全体で見ると、次のようになります。

┌──────┐     ┌──────┐
│ 顧客   │ 1 ─ 多 │ 注文   │
└──────┘     └──────┘
                    │ 1
                    │
                    │ 多
              ┌────────┐
              │ 注文明細 │
              └────────┘
                    │ 多
                    │
                    │ 1
               ┌──────┐
               │ 商品   │
               └──────┘

顧客

• 顧客ID
• 氏名
• メールアドレス

注文

• 注文ID
• 顧客ID
• 注文日

注文明細

• 注文ID
• 商品ID
• 数量
• 注文時単価

商品

• 商品ID
• 商品名
• 現在価格

商品の現在価格とは別に、注文明細へ注文時単価を保存するのはなぜ？

商品の価格は後から変わる可能性があるからだよ。過去の注文金額を正しく残すために、注文時点の価格を保存するんだ。

このように、ER図を作る過程では、単に箱と線を描くだけでなく、実際の業務ルールも整理します。

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

ER図を読むときは、次の順番で確認すると分かりやすくなります。

1．どのエンティティがあるか

まず、どのようなデータを管理しているのかを確認します。

2．主キーは何か

各エンティティを一意に識別する項目を確認します。

3．外部キーは何を参照しているか

どのテーブルとどのテーブルが関連しているのかを確認します。

4．カーディナリティはどうなっているか

1対1、1対多、多対多のどれに当たるかを確認します。

5．関係は必須か任意か

0件を許可するのか、最低1件必要なのかを確認します。

6．多対多が中間テーブルで解消されているか

中間テーブルが何を表し、どの属性を持つか確認します。

ITパスポート・基本情報・応用情報の試験対策

ER図は、ITパスポート、基本情報技術者試験、応用情報技術者試験で押さえておきたいデータベース分野の重要用語です。

特に基本情報技術者試験や応用情報技術者試験では、ER図を読み、エンティティ間の関係やテーブル構造を判断する問題が考えられます。

試験別に押さえたい内容

試験で覚えたい重要用語

試験問題で注目する表現

多対多を見つける問題に注意する

試験では、文章から多対多の関係を見つけ、中間テーブルを選ぶ問題が出ることがあります。

例えば、

• 一人の社員は複数のプロジェクトへ参加できる
• 一つのプロジェクトには複数の社員が参加できる

この場合、社員とプロジェクトは多対多です。

そこで、参加という中間テーブルを作ります。

社員 1 ─── 多 参加 多 ─── 1 プロジェクト

参加テーブルには、次のような情報を持たせられます。

• 社員ID
• プロジェクトID
• 参加日
• 担当役割

よくある誤解

ER図は処理の順番を表す図ではない

顧客から注文へ線が伸びていたら、最初に顧客処理をして、次に注文処理をするという意味？

違うよ。ER図の線はデータ同士の関係を表していて、処理順序を表しているわけではないんだ。

処理順序を表したい場合は、フローチャートやアクティビティ図、シーケンス図などを使用します。

線でつながっていればデータが同じ場所に保存されるわけではない

ER図の線は、テーブル同士がキーなどによって関連付けられることを表します。

顧客データと注文データは、別のテーブルに保存されていても、顧客IDを通して関連付けられます。

一つのエンティティには一つの属性しかないわけではない

エンティティは、通常複数の属性を持ちます。

例えば、顧客エンティティには、顧客ID、氏名、住所、登録日などがあります。

主キーは必ず一つの列とは限らない

主キーはID列を一つ選ぶものだよね？

複数の列を組み合わせて主キーにすることもあるよ。

複数列で構成される主キーを複合主キーといいます。

例えば、履修テーブルで、

• 学生ID
• 授業ID

の組合せを主キーにすることがあります。

ただし、履修年度や再履修を管理する場合は、別の列も必要になる可能性があります。

外部キーの値は必ず重複禁止ではない

一人の顧客が複数の注文を行う場合、注文テーブルの顧客IDは重複します。

外部キーの目的は、別のテーブルを参照することであり、必ず一意にすることではありません。

多対多の関係が絶対に間違いというわけではない

概念ER図では、多対多として業務上の関係を表すことがあります。

ただし、リレーショナルデータベースへ実装するときは、通常、中間テーブルを使って二つの1対多へ分解します。

ER図を作れば正しい設計になるわけではない

ER図は設計内容を見えるようにする道具です。

業務ルールの理解が間違っていれば、見た目が整ったER図でも正しい設計にはなりません。

例えば、

• 一人の顧客は住所を一つしか持てない
• 一つの商品はカテゴリを一つしか持てない

と決めたとしても、実際の業務では複数登録が必要かもしれません。

ER図を作る前後に、業務担当者への確認が必要です。

ER図は一度作ったら終わりではない

システムの要件やテーブル構造が変更されたら、ER図も更新する必要があります。

実際のデータベースと異なるER図を残すと、保守や障害対応の際に誤った判断をする原因になります。

まとめ

ER図とは、データベースで管理する対象と、それらの関係を図で表したものです。

ERはEntity Relationshipの略で、日本語では実体関連図とも呼ばれます。

ER図では、顧客、商品、注文などの管理対象をエンティティとして表し、氏名、価格、注文日などの情報を属性として整理します。

さらに、顧客が注文する、注文に商品を含めるといった関係をリレーションシップとして表します。

ER図を理解するうえで特に重要なのが、主キー、外部キー、カーディナリティです。

主キーはデータを一意に識別し、外部キーは別のテーブルを参照してデータ同士を関連付けます。

カーディナリティは、1対1、1対多、多対多といったデータ同士の対応数を表します。

多対多の関係は、リレーショナルデータベースへ実装するとき、中間テーブルを使って二つの1対多へ分解するのが基本です。

最後に要点を整理します。

ER図は、データベースで何を管理し、それぞれがどう関係するかを表す図なんだね。

そう。箱がエンティティ、その中が属性、箱を結ぶ線がリレーションシップだよ。

主キーで一件ずつ区別して、外部キーで別のテーブルとつなげるんだね。

そして、線の端にある記号を見れば、1対1、1対多、多対多といった関係も分かるよ。

多対多があったら、中間テーブルを作って二つの1対多に分けるんだね。

バッチリ。まずは「箱がデータ、線が関係、記号が数」と覚えて、簡単なER図から読んでみよう。

クマノくらげ

X

難しいIT用語やビジネス用語を、できるだけ身近な例えで解説するブログです。 「専門用語を見ると眠くなる人」でも読めるように、画像や会話形式を多めにしています。 AWS12冠達成済み。