ER図とは？書き方・記号の意味を具体例でわかりやすく解説

ER図は、データベースの構造とデータ同士の関係を1枚の図にした設計書です。

要件定義から実装までのデータベース設計で使われ、公的機関のシステム構築ガイドラインでも標準的な設計手法として採用されています。

この記事では、ER図の基本要素や用語の日英対訳、書き方から作成ツールまでをわかりやすく解説します。日本の開発現場での使われ方もあわせて紹介します。

1. ER図とは？データベース設計で使う設計図

ER図とは、システムが扱うデータの構造と、データ同士の関係が一目でわかるように図にした設計書です。

英語の「Entity Relationship Diagram（実体関連図）」の略で、リレーショナルデータベース（RDB）の設計で広く使われています。

ER図の成り立ち

ER図のもとになる実体関連モデルは、1976年にピーター・チェンが提唱した考え方です。

データを「実体（エンティティ）」と「関連（リレーション）」の組み合わせでとらえるため、実際の業務をそのまま図にしやすいのが特徴です。

ER図でできること

ER図を使うと、テーブル同士のつながりや、どのデータがどこに保存されるかを全体で見渡せます。

データベース設計だけでなく、既存システムの整理やチーム内での仕様共有など、幅広い場面で役立ちます。

総務省の自治体EA参照モデルでも、情報実体関連図（ERD）が論理的なデータ構造を整理する標準的な設計モデルとして採用されています。

参考：総務省 資料編１．参照モデル

▼あわせて読みたい
ER図で設計したデータ構造は、最終的にSQLを使って実装・操作します。
データベースを専門に扱うSQLエンジニアは、AI時代でも需要が根強く、設計スキルと相性のよい職種です。仕事内容や年収相場、将来性を押さえておきましょう。
詳しくはこちらの記事をどうぞ。

2. ER図を構成する4つの基本要素

ER図は主に4つの要素で構成されます。

この4つの意味を押さえると、図の読み書きがスムーズになります。

エンティティ（実体）

エンティティは、データとして管理する対象そのものです。「顧客」「商品」「注文」など、業務で扱う”モノ”や”コト”が当てはまります。

RDBでは、1つのエンティティが1つのテーブルに対応するのが基本です。

アトリビュート（属性）

アトリビュートは、エンティティが持つ1つひとつのデータ項目です。「顧客」なら顧客ID・氏名・住所などが当てはまり、テーブルのカラム（列）にあたります。

主キー（PK）と外部キー（FK）

属性のうち、各データを1件ずつ見分けるためのものが主キー（PK）です。別のエンティティの主キーを参照してつなぐ属性が外部キー（FK）で、この2つがテーブル同士を結びつけます。

リレーション（関連）

リレーションは、エンティティ同士のつながりです。「顧客が注文する」「注文に商品が含まれる」といった関係を線で結び、データの連携を表します。

カーディナリティ（多重度）

カーディナリティは、関連する2つのエンティティが「いくつ対いくつ」で対応するかを表します。基本は「1対1」「1対多（1:N）」「多対多（N:M）」の3種類で、線の記号で見分けます。

▼あわせて読みたい
ER図で扱うエンティティや正規化の考え方は、データエンジニアの基礎スキルの一つです。
データ基盤を支えるこの職種では、モデリングに加えて収集・加工・運用まで幅広い領域が求められます。必須7領域と習得ロードマップを、次に学ぶ範囲の地図として押さえておきましょう。
詳しくはこちらの記事をどうぞ。

3. ER図の用語｜英語と日本語の対訳

ER図の用語は英語由来のものが多く、日本の現場ではカタカナと日本語訳が混ざって使われます。

英語のドキュメントに慣れている場合や、日本語での呼び方を確認したいときに、次の対訳表が役立ちます。

4. ER図で扱う3つのデータモデル｜概念・論理・物理

ER図は、システム開発の工程に合わせて3段階のデータモデルに描き分けます。工程が進むほど、より実装に近い詳しい図になります。

概念データモデル

概念データモデルは、要件定義フェーズで作るおおまかな図です。主要なエンティティと大まかな関連だけを描き、関係者みんなでデータの全体像を共有することを目的とします。

論理データモデル

論理データモデルは、基本設計フェーズで作ります。

各エンティティに属性・主キー・外部キーを加え、カーディナリティも決めます。特定のデータベース製品に依存しない、論理的な構造を固める段階です。

物理データモデル

物理データモデルは、詳細設計フェーズで作る実装向けの図です。

テーブル名や属性名を実際のカラム名に変え、データ型の指定や正規化、中間エンティティの追加などを行います。この図はそのままデータベースの構築に使えます。

■概念・論理・物理を描き分ける設計力、日本での市場価値は？

概念・論理・物理とモデルを描き分けるデータベース設計力は、日本のIT転職市場でも評価されるスキルです。

BLOOMTECH Career for Globalは、日本在住で日本語N2以上の外国籍エンジニアを対象に、いまの市場価値やマッチしやすい求人の傾向を客観的に把握するお手伝いをしています。まずは自分の立ち位置を確かめてみませんか。

▼BLOOMTECH Career for Globalへのお問い合わせはこちら

5. ER図の記法｜IE記法とIDEF1X記法の違い

ER図には複数の記法があり、記号のルールがそれぞれ異なります。

歴史的には提唱者ピーター・チェンによる「チェン記法」が原型ですが、国内の実務では「IE記法」と「IDEF1X記法」の2つが中心です。

IE記法（鳥の足記法）

IE記法は、カーディナリティを鳥の足のような枝分かれ記号で表す方式で、国内で広く使われています。

線の端の記号で対応関係を直感的に読み取れるため、初めての人でもわかりやすいのが特徴です。

IDEF1X記法

IDEF1X記法は、米国規格をもとにした厳密な記法です。

依存・非依存の関係を線の種類（実線・破線）で見分けられ、正確さが求められる大規模な設計で使われることがあります。

2つの記法の使い分け

どちらも表せる内容はほぼ同じです。

読みやすさを重視するならIE記法、依存関係をきっちり表したいならIDEF1X記法が向いています。チームの標準に合わせて選ぶのが一般的です。

6. ER図の書き方｜5つのステップと具体例

ER図は、次の5つのステップで作成すると迷いにくくなります。

ECサイトのようなイメージしやすい題材で考えると理解が進みます。

ステップ1：システムの対象範囲を確認する

まず、そのシステムが何を扱うのかを整理します。

「会員が商品を注文し、注文には複数の商品が含まれる」のように業務の流れを言葉にすると、必要なデータが見えてきます。

ステップ2：エンティティを洗い出す

業務に登場する”モノ”や”コト”を挙げて、エンティティの候補にします。ECサイトなら「会員」「商品」「注文」「注文明細」などが挙がります。

マスタ系とトランザクション系に分ける

挙げたエンティティは、「会員」「商品」のように基礎データを持つマスタ系と、「注文」のように日々発生するトランザクション系に分けておくと、後の整理がしやすくなります。

ステップ3：アトリビュートを洗い出す

各エンティティが持つデータ項目を書き出します。あわせて、各データを1件ずつ見分けるための主キーを決めておきます。

ステップ4：リレーションとカーディナリティを設定する

エンティティ同士を線で結び、その関係が1対1・1対多・多対多のどれかを判断します。ここで外部キーを使い、テーブル同士のつながりを表します。

ステップ5：ER図に落とし込む

ここまでの情報を、IE記法などを使って1枚の図にまとめます。全体を見ながら過不足を確認し、必要に応じて属性や関連を調整します。

具体例：ECサイトのER図を組み立てる

5つのステップを、ECサイトを例に見てみます。

まずエンティティとして「会員」「商品」「注文」「注文明細」を挙げます。
関係を整理すると、「会員（1）が注文（多）を行う」という1対多になります。「注文」と「商品」は多対多になるため、間に「注文明細」を置いて分解します（詳しくは次の章）。

これらをIE記法で結ぶと、ECサイトの基本的なER図が1枚できあがります。

▼あわせて読みたい
本文のECサイトのように、業務系システムは在庫や注文などのデータを扱い、その土台ではER図で設計したデータベースが動いています。
基幹システムとの違いや種類、導入メリットを知ると、自分が描くER図がどんなシステムで活かされるのかをイメージしやすくなります。
詳しくはこちらの記事をどうぞ。

7. ER図における多対多リレーションと中間エンティティ

ER図の作成でつまずきやすいのが、多対多（N:M）の関係です。

多対多はそのままではテーブルに変換できないため、分解のしかたを知っておく必要があります。

多対多が問題になる理由

たとえば「注文」と「商品」は、1件の注文に複数の商品が含まれ、1つの商品も複数の注文に登場するため、多対多になります。

この状態では、どの注文にどの商品がいくつ含まれるかを、1つのテーブルで表せません。

中間エンティティで1対多に分解する

多対多を解消するには、2つのエンティティの間に中間エンティティ（連関エンティティ）を追加します。

「注文」と「商品」の間に「注文明細」を置くと、「注文（1）対 注文明細（多）」と「商品（1）対 注文明細（多）」の2つの1対多に分かれ、テーブルとして正しく表せます。

8. ER図を作成する3つのメリット

ER図を作る手間には、それを上回るメリットがあります。

特に上流工程での設計品質に関わる効果が大きいといえます。

手戻りコストを防げる

データ構造を設計段階で図にしておくと、仕様の抜け漏れや矛盾を早めに見つけられます。

JUAS（一般社団法人日本情報システム・ユーザー協会）の調査では、全体の約5割のプロジェクトが要件定義に問題があって工期が遅延したと報告されています。

遅延要因の多くが上流に集中する一方、公的機関でも論理データ構造の可視化にERDが標準採用されていることを踏まえると、ER図は単なる作図作業ではなく、遅延リスクの大きい上流工程を可視化し、合意形成するための実務的な手段といえます。

参考：JUAS ソフトウェア・メトリックス調査（2016年版）

保守・運用フェーズで役立つ

ER図はシステム完成後も、データ構造を示す資料として使えます。

仕様変更や機能追加のときに影響範囲をすぐ把握できるので、改修の負担を抑えられます。

チーム内での認識を統一できる

データの全体像を1枚の図で共有できるため、エンジニアだけでなく企画や業務の担当ともイメージをそろえやすくなります。

上流工程での品質確保は、後工程の不具合の起こりにくさにも影響するとされており、納期と品質の両面での予防につながります。

参考：IPA ソフトウェア開発データ白書

日本の開発現場でのER図の使われ方

日本のシステム開発、特に受託開発では、上流工程を重視するウォーターフォール型が今も多く使われています。

その中でER図は、要件定義や基本設計の段階で作られ、設計レビューでチーム全体に共有されます。

実体関連図（Entity Relationship Diagram）の考え方は世界共通なので、海外で学んだ知識はそのまま活かせます。

日本のチームで新たに押さえたいのは、工程ごとに図を描き分ける進め方や、レビューで合意を取りながら設計を固める文化です。

■上流工程の設計経験を、次のキャリアアップへ

要件定義や基本設計でER図を扱う上流工程の経験は、転職市場で大きな強みになります。

BLOOMTECH Career for Globalでは、日本在住で日本語N2以上の外国籍エンジニアの転職を、求人紹介から選考対策まで一貫してサポートしています。設計スキルを活かせる次の一歩を、一緒に探しましょう。

▼BLOOMTECH Career for Globalへのお問い合わせはこちら

9. ER図の作成ツールの選び方

ER図は手描きでも作れますが、修正や共有のしやすさを考えると専用ツールが便利です。目的に合わせて選ぶとよいでしょう。

オンライン作図ツール

ブラウザで使えるdraw.io（diagrams.net）やLucidchart、Cacooは、テンプレートがそろっていて共同編集にも対応しています。無料で使える範囲も広く、まず試したいときに向いています。

データベース連携ツール

A5:SQL Mk-2のようなツールは、既存のデータベースからER図を自動で作れます。実データと図を対応させて管理したい場合や、大規模なテーブルを扱う場合に役立ちます。

ツール選びのポイント

選ぶときは、対応する記法（IE記法など）、共同編集のしやすさ、データベースとの連携、料金プランの4点を基準にすると絞り込みやすくなります。

▼あわせて読みたい
データベース設計は、要件定義や基本設計といった上流工程で評価される実務スキルです。
日本のIT市場でいま需要が高まっているスキルを把握しておくと、ER図の学習を含め、どの分野に力を入れれば年収や将来性につながるかを判断しやすくなります。
詳しくはこちらの記事をどうぞ。

よくある質問

まとめ｜ER図でデータ構造を整理する

ER図は、エンティティ・アトリビュート・リレーション・カーディナリティの4つの要素でデータの構造を表す設計手法です。

概念・論理・物理の3モデルに描き分け、多対多は中間エンティティで分解します。設計段階でデータ構造を図にしておくと、手戻りの防止と保守のしやすさにつながります。

まずは身近なシステムを題材に、IE記法で1枚描いてみましょう。