DBC Tech Academy

DBC Tech Academy / データベース / 入門

ER図が
読めると、
業務が見える。

ER図は、箱と線という 2 種類の記号だけでできています。ここでは記号の意味からリレーション名の付け方まで、図を動かしながら順に確認します。情報処理技術者試験で使われる記法との対応も取り上げます。

線を読んでみる 先に結論を読む
entity relationship diagram

この図は「会員 は 注文 を 注文する」と読めます。

Boxes and lines

箱は名詞、
線は動詞。

ER図に出てくる要素は 2 種類だけです。それぞれを日本語に置き換えられれば、どのような図でも読み解けます。

名詞と動詞

箱は業務に登場する「もの」、線は「もの」同士の間で起きる「こと」を表します。

箱には「会員」「商品」「注文」のような名詞が入り、線には「注文する」「含む」「所属する」のような動詞が入ります。線に動詞の名前を付けると、図はそのまま文章として読めるようになります。箱はテーブル、線はテーブル間のリレーションに対応します。

  • 会員 は 注文 を 注文する
  • カテゴリ は 商品 を 含む
  • 社員 は 部署 に 所属する

文章として読める設計は、エンジニア以外の方にも伝わります。伝われば、業務には存在しない関係や、業務にはあるのに図へ描かれていない関係に気付けます。ER図を読む目的は、ここにあります。

Anatomy of an entity

箱の中に、
4 つの情報がある。

箱はテーブル（表）に対応します。1 つの箱を上から順に読み解いていきましょう。

  • 1
    テーブル名と論理名上段の帯に表示されます。物理名（orders）はプログラムで使う名前、論理名（注文）は業務で使う言葉です。両方を併記しておくと、技術者と業務担当者が同じ図を共有できます。
  • 2
    主キー（PK）1 行を一意に識別するための列で、黄色の帯で強調されます。線が「1 側」として箱に接するとき、その接続先が主キーです。実務では、業務上の識別子をそのまま主キーにするのではなく、連番や UUID を主キーに置き、業務上の識別子には一意制約を付ける形が主流です。
  • 3
    外部キー（FK）他の箱の主キーを参照する列です。線の「多側」の根元は、必ず外部キーになります。線をたどれば、どの箱を参照しているかを確認できます。
  • 4
    型と NULL 許容列の型（integer、varchar など）と、値を省略できるかどうかを示します。NULL を許容する外部キーは「相手が存在しない場合もある」関係を表し、線の端に付く「0」に対応します。

Reading the lines

線の端の記号で、
数を読む。

IE 記法（カラスの足）では、線の両端に「相手が何件あるか」を記号で表します。使う記号は次の 3 つだけです。

縦棒 = 1相手はちょうど 1 件
カラスの足 = 多相手は複数件
丸 = 0相手がいないこともある
組み合わせ丸＋足 = 0 件以上
棒＋足 = 1 件以上
HOW TO READ

読む順番

読むときは、線の反対側にある記号を見ます。「会員から見て注文は何件か」を知りたい場合は、注文側の端を確認します。カラスの足であれば「複数」、縦棒であれば「1 件」です。

続いて逆向きにも読みます。「注文から見て会員は何件か」は、会員側の端が答えです。両方向を読んで、はじめて 1 本の線を読み解いたことになります。

多側には外部キーがある

カラスの足が付いた側の箱には、必ず相手の主キーを参照する外部キー列があります。逆にいえば、外部キーを見つけて相手の主キーへ線を引いていけば、ER図を描けます。SQL to ERD が CREATE TABLE から図を生成できるのは、この関係があるためです。

Naming the relationship

リレーション名は、
「〜する」で付ける。

線に名前を付ける手順は 3 段階です。名前は「注文する」「所属する」のように、名詞に「する」を付けた形にします。設計ツールでは Relationship name と表示され、日本の現場ではリレーション名と呼ぶのが一般的です。試験では「関連名」と呼びます。

STEP 01

1 側を主語にして一文にする

縦棒の側を主語、カラスの足の側を目的語に置き、業務で使う言葉で一文を作ります。

会員 は 注文 を 行う
STEP 02

動詞を「〜する」形に整える

「行う」「持つ」といった汎用的な動詞を、その行為を業務で何と呼ぶかに合わせ、名詞＋「する」へ置き換えます。

行う → 注文する
STEP 03

線に書き、1 側から読む

決まった名前を線の上に書きます。読むときは、主語（1 側）から目的語（多側）へたどります。

会員 ─注文する─< 注文
SENTENCE

リレーション名を書き換えると、文章と図が同時に変わります。「持つ」や「関連する」と入力して、文章がどれだけ曖昧になるかも試してみましょう。

-- リレーション名はデータベースの定義そのものに残せる。PostgreSQL では制約にコメントを付ける
CREATE TABLE users (
  id    SERIAL PRIMARY KEY,
  name  VARCHAR(100) NOT NULL
);
CREATE TABLE orders (
  id         SERIAL PRIMARY KEY,
  user_id    INTEGER NOT NULL,
  ordered_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  CONSTRAINT fk_orders_user FOREIGN KEY (user_id) REFERENCES users(id)
);
COMMENT ON TABLE users IS '会員';
COMMENT ON TABLE orders IS '注文';
COMMENT ON CONSTRAINT fk_orders_user ON orders IS '注文する';

この SQL を SQL to ERD に貼り付けると、リレーション名「注文する」が線の上に表示されます。線をダブルクリックすれば、図の上で付け直すこともできます。

SQL to ERD で試す

Many to many

多対多は、
線が表になる。

1 つの注文には複数の商品が含まれ、1 つの商品は複数の注文に現れます。このような「多対多」の関係は、そのままではテーブルとして表現できません。

概念モデル: 多対多のまま

外部キーを置く場所がない

1 対多であれば、多側の箱に外部キーを 1 列用意すれば済みます。しかし多対多では、注文の箱に商品 ID を置いても複数の値を持てず、商品の箱に注文 ID を置いても同じ問題が起こります。

そこで、線そのものを箱に変えます。注文 ID と商品 ID の両方を外部キーとして持つ「注文明細」を用意すると、多対多の関係は「1 対多」2 本に分かれます。

名前はリレーション名から取る

線を箱に変えるとき、テーブル名にはリレーション名の名詞形をそのまま使えます。「社員 は 部署 に 所属する」という多対多（兼務や異動履歴）を分解すれば「所属」テーブル、「学生 は 講義 を 受講する」であれば「受講」テーブルになります。

リレーション名を「〜する」の形で付けておく利点は、この場面で活きてきます。

Shapes you will meet

現場の図で、
よく出会う 3 つの形。

ここまでの読み方があれば、たいていの図は読めます。ただし実務の図には、初めて見ると戸惑う形が 3 つあります。いずれも新しい記号ではなく、箱と線の組み合わせです。

1. 種類ごとに箱が分かれている（サブタイプ）

  • 1
    共通の列を 1 つの箱にまとめます会員である以上どちらにも必要な列（登録日、メールアドレス）を親の箱に置きます。
  • 2
    種類ごとに違う列を別の箱に置きます個人にしかない生年月日、法人にしかない法人番号を、それぞれの箱に分けます。
  • 3
    子の主キーは、親の主キーと同じ列ですmember_id が主キーであり、同時に親を参照する外部キーでもあります。だから線の端は「多」ではなく「1」になります。
  • 4
    端の丸は「無いこともある」会員から見れば、個人会員の行はある（丸と縦棒）か、無い（法人会員のほう）かのどちらかです。両方に行があってはいけない、という決まりは図に描けないため、注記か制約で示します。

試験ではこの形を「汎化・特化」と呼び、親の箱に三角形の記号を付けて表す記法が出題されます。実務のツールは三角形を描かず、上の図のように 1 対 1 の線として表すのが一般的です。

2. 線が同じ箱に戻ってくる（自己参照）

社員と上司のように、同じ種類のもの同士に関係があるとき、線は出ていった箱にそのまま戻ります。箱は 1 つ、線は 1 本です。

読み方も変わりません。カラスの足が付いた側が「部下」、縦棒の側が「上司」です。1 人の上司は複数の部下を持ち、1 人の部下は上司を 1 人だけ持つと読みます。

上司側の端には丸が付きます。社長には上司がいないため、manager_id は NULL を許容します。この「相手がいない場合がある」が、そのまま丸になります。

階層の深さは図に現れません。3 段なのか 10 段なのかは、図を見ても分からず、データを見るまで決まらないためです。すべての部下をたどる問い合わせには WITH RECURSIVE を使います。

-- 同じ表を参照する外部キーが、自己参照の正体
CREATE TABLE employees (
  id         SERIAL PRIMARY KEY,
  name       VARCHAR(100) NOT NULL,
  manager_id INTEGER
    REFERENCES employees(id)
);

3. 単独では存在できない箱（弱実体）

ひとつ前の節で作った注文明細は、この形にあたります。注文明細の主キーは (order_id, product_id) で、主キーの中に外部キーが入っています。

これは「どの注文に属するかが決まらなければ、この行を識別できない」ことを意味します。注文が消えれば、その明細も一緒に消えます。親に寄りかかって初めて成立する箱なので、弱実体と呼びます。この関係のことを識別リレーションと呼びます。

見分け方は 1 つだけです。主キーの帯の中に、外部キーの印が付いた列があるかどうかを見ます。あれば弱実体、なければ独立した箱です。

いっぽう会員と注文は、この形ではありません。注文の主キーは id 単独で、user_id は主キーの外にあります。会員が消えても、注文の行そのものは識別できます（消すかどうかは、別に決める話です）。

中間テーブルは、たいてい弱実体になります。多対多をほどいた結果として生まれる箱は、両側の親がそろって初めて意味を持つためです。

For the exam

試験の記法は、
実務では使わない。

情報処理技術者試験の E-R 図では、カラスの足ではなく矢印で件数（多重度）を表します。関係の読み方そのものは同じですが、この記法を使うのは試験の中だけです。実務で目にする ER図やツールが出力する ER図は、ほぼ IE 記法です。両方を覚えてください。

IE 記法と試験の記法の対応

試験では、1 側から多側へ向けて矢印を引きます。矢印の先が「多」を表します。同じ関係を、実務で使う IE 記法と並べて確認しておきましょう。

関係IE 記法（この講座・SQL to ERD）試験の記法（IPA）
1 対 多
1 対 1
多 対 多

出題では多対多のまま描かれることは少なく、中間テーブルに分解した状態で「欠けている線」や「欠けている外部キー」を答えさせる形が中心です。前の節で扱った分解ができれば対応できます。

なぜ記法が分かれているのか

試験の記法は、Peter Chen が 1976 年に発表した ER モデルの流れをくんでいます。試験制度が整えられた 1980 年代には、こちらが標準的な書き方でした。IE 記法が広く使われるようになったのは、設計支援ツールが普及した 1990 年代後半以降です。

矢印は手書きしやすく、採点でも判別を誤りにくいという事情もあります。三本に枝分かれしたカラスの足は、小さく書くと本数や角度が崩れやすいためです。

ただし、実務で 30 年近く IE 記法が主流であり続けている現状は変わりません。試験のために覚えた記法は、そのままでは職場で通じないと考えてください。試験を受ける方は、両方の記法で同じ関係を読み書きできるようにしておくのが現実的です。

出題のされ方

  • IT パスポート
  • 基本情報技術者
  • 応用情報技術者
  • データベーススペシャリスト

IT パスポートと基本情報では、E-R 図を見て件数の対応を読み取る問題が出題されます。応用情報の午後では、業務の説明文を読み、E-R 図の空欄（線や矢印）を埋めます。データベーススペシャリストの午後では、業務記述から概念データモデルと関係スキーマ（主キー・外部キー）を完成させる問題が中心です。

例題: 業務の文から線を引く

1 つの部署には複数の社員が所属する。社員は必ずいずれか 1 つの部署に所属し、複数の部署に同時に所属することはない。

問: 部署と社員の間に引く線について、件数の対応と向きを答えてください。

試験の常識が、実務の常識とは限らない

記法のほかにも、試験での扱いと実務での扱いが分かれる点があります。この講座は実務での扱いを基準に書いています。試験を受ける方は、両方を知ったうえで答案を書き分けてください。

試験での扱い実務での扱い（この講座）
記法 1 側から多側へ矢印を引く IE 記法（カラスの足）。設計ツールの出力もこちら
属性 概念データモデルには書かず、関係スキーマとして別に並べる 箱の中に列として書く。図だけで設計を読めるようにする
主キー 業務上の識別子（社員番号、商品コードなど）をそのまま主キーにする問題が多い 連番や UUID の代理キーが主流。業務上の識別子は一意制約で守る
多対多 連関エンティティ（中間テーブル）に分解した状態で問われることが多い 業務を整理する段階では多対多のまま描き、実装時に分解する
線の名前 概念データモデルに必ず書かせる。「関連名」と呼ぶ ツールが既定で表示しないため省略されがち。書けば図が文章として読めるので、この講座では付けることを勧める。「リレーション名」と呼ぶ
呼び方 エンティティタイプ、リレーションシップ、関連名、多重度、汎化・特化 テーブル、列、外部キー、リレーション名など、そのまま実装やツールの表示に対応する言葉

Myth vs. reality

ここを間違えやすい。

ER図を読み始めたばかりの方が、一度は迷いやすいポイントを整理します。

MISCONCEPTION 01

「線の向きはデータの流れ」

線が表すのは参照の関係であり、データが移動する向きではありません。カラスの足は「こちら側が複数ある」ことを示す数の記号で、矢印ではありません。試験の記法で使う矢印も、多側を指すための印であって、処理の順番を表すものではありません。

MISCONCEPTION 02

「線の名前は『持つ』で十分」

「会員 は 注文 を 持つ」でも件数は読み取れますが、業務の内容までは伝わりません。注文を「した」のか「担当している」のか「承認した」のかによって、必要な列も画面も変わります。動詞を業務の言葉に置き換えると、その違いが図の上に現れます。

MISCONCEPTION 03

「多対多は ER図に描けない」

業務を整理する段階の概念モデルでは、両端にカラスの足を付け、多対多のまま描いてかまいません。表現できないのはテーブルとして実装する物理モデルの段階で、そこで中間テーブルに分解します。設計の段階によって描き方が変わるだけです。

Knowledge check

7問で、理解を
確かめよう。

答えを当てるだけでなく、なぜそう判断できるのかを説明できれば合格です。

YOUR PROGRESS 01 / 07

選択肢を1つ選んでください。

Read it aloud

箱を読み、線を読み、
名前を付ければ、文章になる。

箱 = 名詞
端の記号 = 数
リレーション名 = 動詞
1 側から読む
自分の SQL を図にする Academy トップへ