ER図とは？書き方とリレーションの表し方

システムの仕様書にER図が出てきたものの、線の先についている記号の意味が分からない。あるいは自分で描こうとして、どこまで書けばよいのか迷う。ER図はデータの構造を示す図ですが、読むだけなら覚えることはそれほど多くありません。この記事では、ER図の基本要素とリレーションの表し方、そして作成手順を整理します。

ER図とは｜データ同士の関係を示す図

ER図（Entity Relationship Diagram）は、システムが扱うデータを、まとまりとその関係で表した図です。日本語では実体関連図と呼ばれます。

たとえば通販サイトなら、顧客・注文・商品といったまとまりがあり、「顧客は複数の注文を持つ」「注文には複数の商品が含まれる」といった関係があります。これを図にしたものがER図です。

何のために使うのか

主な用途は3つです。

• 設計の検討：データベースを作る前に、構造の妥当性を確かめる
• 認識のすり合わせ：発注者と開発側で、扱うデータの理解を揃える
• 引き継ぎ：既存システムの構造を、後から入った人に伝える

発注者の立場で関わるのは2つ目が多くなります。自分で描く必要はなくても、提示された図を読んで「この理解で合っているか」を判断できると、手戻りを大きく減らせます。

3つの基本要素

ER図は、次の3つでできています。

エンティティ

データのまとまりです。顧客、注文、商品、社員といった、管理する対象を指します。図の上では四角で描き、中に名前を書きます。

名前は単数形の名詞にするのが慣例です。「顧客たち」ではなく「顧客」、「注文一覧」ではなく「注文」と書きます。1つの四角が、1件分のデータの型を表していると考えてください。

アトリビュート

エンティティが持つ項目です。顧客なら、氏名・メールアドレス・電話番号・登録日などです。四角の中に、エンティティ名の下に並べて書きます。

このうち、その1件を一意に特定できる項目を主キーと呼びます。顧客IDや注文番号がこれにあたり、図の上では下線やPKという記号で示されます。

リレーション

エンティティ同士の関係です。四角と四角を線で結び、その線にどういう関係なのかを示す記号を付けます。ER図で最も重要な部分で、同時に最も読みにくい部分でもあります。

リレーションの3パターン

関係は、両側の件数の組み合わせで3つに分かれます。

1対1

片方の1件に対して、もう片方も必ず1件だけ対応する関係です。社員と社員詳細情報、ユーザーとユーザー設定などが例です。

実は、登場頻度は高くありません。1対1なら同じテーブルにまとめてしまえばよい場合が多いからです。分けている場合は、項目数が多すぎる、参照頻度が大きく違う、権限を分けたいといった理由があるはずです。

1対多

最もよく使われる関係です。片方の1件に対して、もう片方が複数対応します。

「1人の顧客は複数の注文を持つ。しかし1件の注文は1人の顧客にしか紐づかない」。これが1対多の典型です。部署と社員、カテゴリと商品も同じ形になります。

多対多

両方が複数対応する関係です。「1件の注文には複数の商品が含まれ、同じ商品は複数の注文に現れる」という関係です。

ここが重要な点ですが、多対多はそのままではテーブルにできません。間にもう1つテーブルを置いて、「注文―注文明細―商品」のように1対多の関係に分解します。この中間のテーブルを中間テーブルや交差エンティティと呼びます。

実務では、この中間テーブル自体が項目を持ちます。注文明細なら、数量や注文時の価格などです。単なるつなぎ役ではなく、意味のあるデータを持つ存在として扱ってください。

カーディナリティの記法

件数の対応関係をカーディナリティと呼びます。表記にはいくつかの流儀がありますが、現在最も広く使われているのは、線の端の形で示す記法です。

線の端に付く記号は、2つの情報を重ねて表します。外側（エンティティに近い側）が最大値、内側が最小値です。

• 三本に分かれた足のような形：複数対応する（多）
• 線に垂直な短い線：1件である
• 円：0件もありうる（任意）

組み合わせで読みます。円と線なら「0件または1件」、線と足なら「1件以上」、円と足なら「0件以上」です。

実務での読み方

記号を覚えるより、文章に直すのが確実です。線の片方からもう片方へ向かって、「顧客1件に対して、注文は0件以上」と声に出して読みます。逆向きにも同じことをやり、「注文1件に対して、顧客は必ず1件」と確かめます。

両方向きで読むことが大事です。片方だけ見ていると、制約のすれ違いに気づけません。

作成手順｜4ステップ

STEP1：管理したいものを洗い出す

業務の中で出てくる名詞を拾います。顧客、注文、商品、在庫、担当者などです。この段階では項目や関係を考えず、リストにしていくだけで十分です。

STEP2：関係を文章で書く

図にする前に、文章で関係を書き出します。「顧客は注文を0件以上持つ」「注文は商品を1件以上含む」といった形です。

この段階で、ややこしいケースが見つかります。会員登録していない人の注文はどう扱うか、廃番した商品の過去注文はどうなるか。図を描いてから気づくと、後戻りが大きくなります。

STEP3：多対多を分解する

書き出した関係の中から多対多を見つけ、中間のエンティティを立てます。ここで中間テーブルにどんな項目が必要かも考えておくと、後の手戻りが減ります。

STEP4：図にして検証する

ここで初めて四角と線を描きます。完成したら、具体的なデータを当てはめて確かめてください。「リピートの顧客が5回注文して、そのうち1件をキャンセルした場合」を、この図で表現できるか。

表現できないケースが見つかったら、エンティティか項目が足りていません。

発注者としてレビューするときの観点

ベンダーからER図を提示されたとき、技術的な妥当性を判断する必要はありません。見るべきは、自社の業務が表現できているかだけです。

• 例外ケースを当ててみる：現場で実際に起きているイレギュラーなケースを提示し、表現できるか確認する
• 必須かどうかを見る：入力しなくても登録できる項目はどれか。リレーションで0件を許すかも同じ
• 削除したときの振る舞い：顧客を削除したら、過去の注文はどうなるか
• 履歴を残すか：値が変わったとき、前の値を残す必要がある項目はないか

特に4つ目は後からの変更が大きい領域です。商品の価格を変えたときに、過去の注文金額まで変わってしまう設計になっていないか、確認してください。

よくある質問

Q. どこまで細かく描くべきですか

目的で変わります。発注者との認識合わせなら、エンティティと関係だけで十分です。項目を全部並べると読む側の負担が上がり、肝心の関係に目が向かなくなります。実装向けなら、型や制約まで含めた詳細版を別に作ります。

Q. エンティティが多すぎて図が複雑です

業務領域ごとに図を分けてください。受注まわり、在庫まわり、会員管理まわりといった単位です。境界になるエンティティは両方の図に登場させて構いません。

Q. ツールは何を使えばよいですか

検討段階なら手書きや付箋で十分です。清書が必要になったら、図形描画ツールや、テキストで書いて図を生成する形式のツールが使われます。後者は変更履歴を残しやすい利点があります。

Q. 作ったあとの更新はどうしますか

テーブル構造を変えるときに必ず図も直す、とルールを決めておくことです。実態とずれたER図は、ないより危険です。保守できないのであれば、作った日付を明記して参考資料として扱うところまでです。

ER図では表せないこと

ER図が示すのは、データの構造と制約だけです。そのデータがいつ、誰によって、どういう手順で登録されるのかは表せません。発注者との認識合わせでは、業務の流れを示す図とセットで見ると抜けが減ります。

また、システムの設計が固まったあとは、実装を進めるプロジェクトの管理に移ります。Xtrategyでは、施策のスケジュールと予算・KPIを同一画面で管理できます。

まとめ

• ER図はデータのまとまりと関係を示す図。要素はエンティティ・アトリビュート・リレーションの3つ
• 関係は1対1・1対多・多対多の3パターン。実務では1対多が中心
• 多対多はそのまま実装できない。中間テーブルを置いて1対多に分解する
• カーディナリティは外側が最大、内側が最小。両方向きに文章で読む
• 図を描く前に、関係を文章で書き出すと例外ケースに気づける
• レビューでは、自社の例外ケースを当てて表現できるかを見る

ER図は記号を覚えることが目的ではなく、データの扱いについて認識を揃えるための道具です。まずは自社の業務を「何は何を何件持つ」の形で文章にしてみるところから始めてみてください。