ER図とは？書き方と記号の意味、作成手順やおすすめツールまで解説

データベースを設計するとき、テーブルの構造やデータ同士の関係をどう整理するかは、システムの品質を左右する重要な工程です。この設計を視覚的に表現する手法として広く使われているのがER図（Entity Relationship Diagram）です。

ER図は、データの実体（エンティティ）と、それらの間にある関係（リレーションシップ）を図で表したものです。データベースの設計書として扱われることが多く、開発チーム内での認識合わせや仕様の確認に欠かせない存在になっています。

ただし、ER図にはIE記法やIDEF1X記法といった複数の記法があり、カーディナリティの記号も初めて見ると意味がわかりにくいものです。この記事では、ER図の基本から書き方の手順、記号の読み方、作成に使えるツールまで、実務に必要な知識を順番に整理しています。

確認したいポイント	結論	詳細
ER図とは何か？	データベースの設計図である	データの実体（エンティティ）と関係性（リレーションシップ）を図で表現し、システムのデータ構造を可視化する手法のこと
どんな記法があるのか？	IE記法とIDEF1X記法の2種類	IE記法は鳥の足記号で直感的に理解しやすく、IDEF1X記法は丸や菱形で厳密に定義する。実務ではIE記法が主流になりつつある
ER図はどう書くのか？	5つのステップで段階的に作成	エンティティの洗い出しから始め、属性定義・リレーション設定・カーディナリティ決定・正規化の順に進める
作成ツールは何を使えばよいか？	用途と予算で選ぶ	無料ならdraw.ioやA5:SQL Mk-2、有料ならSI Object BrowserやLucidchartが代表的。既存DBからの逆生成が必要かどうかも判断基準になる

この記事でわかること

・ER図の定義と、データベース設計における役割

・エンティティ・アトリビュート・リレーション・カーディナリティの意味

・IE記法とIDEF1X記法の違いと記号の読み方

・ER図を5ステップで書く具体的な手順

・無料・有料のER図作成ツールの特徴と選び方

＼ システム開発・データベース設計のご相談 ／ ▶ 相談予約はこちら

ER図とは何か

ER図は、データベースに格納するデータの構造と関係性を視覚的に表現した設計図です。Entity（実体）とRelationship（関係）の頭文字を取ってER図と呼ばれ、日本語では「実体関連図」とも訳されます。

ER図の定義と役割

ER図は1976年にピーター・チェン（Peter Chen）が提唱した概念がもとになっています。システムが扱うデータを「モノ（エンティティ）」と「モノ同士のつながり（リレーションシップ）」で整理し、図として表現する手法です。

リレーショナルデータベースの設計では、テーブル構造を事前に設計する必要があります。テーブルの数が少ないうちは頭の中で管理できても、業務システムのように数十〜数百のテーブルが関わる場合、設計の全体像を文章だけで把握することは困難です。ER図を使うことで、データ構造の全体像を一枚の図として俯瞰でき、設計ミスやテーブル間の不整合を早期に発見できます。

ER図の主な役割は以下の3つです。

・データベース設計の可視化：テーブル構造と関係性を図で把握できる

・チーム内のコミュニケーション促進：設計者・開発者・レビュアー間で認識を合わせやすくなる

・設計品質の向上：正規化の状態や冗長なデータ構造を視覚的にチェックできる

IPA（独立行政法人 情報処理推進機構）が実施するデータベーススペシャリスト試験でも、ER図は出題範囲に含まれており、データベース設計における標準的な手法として位置づけられています（参照：

IPA データベーススペシャリスト試験）。

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

ER図は、以下の4つの要素で構成されています。どれもER図を読み書きする上で欠かせない基本用語です。

エンティティ（Entity）は、データベースで管理する対象を表します。「顧客」「商品」「注文」のように、システムが扱うデータのまとまりです。ER図では長方形で表記されます。リレーショナルデータベースでは、1つのエンティティが1つのテーブルに対応するのが基本です。

アトリビュート（Attribute）は、エンティティが持つ属性情報です。たとえば「顧客」エンティティであれば、「顧客ID」「氏名」「メールアドレス」「電話番号」といった項目がアトリビュートに該当します。データベースのテーブルでいうカラム（列）にあたります。

リレーションシップ（Relationship）は、エンティティ同士の関係を示す線です。たとえば「顧客が商品を注文する」という業務ルールがある場合、「顧客」と「注文」のエンティティ間にリレーションシップが引かれます。線の種類や記号によって、関係の内容をより詳しく表現します。

カーディナリティ（Cardinality）は、リレーションシップの詳細を表す記号です。エンティティ間の対応関係が「1対1」「1対多」「多対多」のどれにあたるかを定義します。たとえば「1人の顧客は複数の注文を持つ」場合、顧客と注文の関係は「1対多」になります。

ER図の記法と記号の意味

ER図の書き方には複数の記法がありますが、実務で使われるのは主にIE記法（鳥の足記法）とIDEF1X記法の2種類です。どちらもエンティティやリレーションシップの表現方法は似ていますが、カーディナリティの記号が異なります。

IE記法（鳥の足記法）の特徴

IE記法は、Information Engineering記法の略で、カーディナリティを直感的に把握しやすい点が特徴です。「多」を表す記号が鳥の足のような形をしていることから「鳥の足記法（Crow’s Foot Notation）」とも呼ばれます。

IE記法で使用する主な記号は以下の通りです。

・縦線「｜」：1を表す

・丸「○」：0（存在しない場合もある）を表す

・鳥の足「∈」：多を表す

これらの記号を組み合わせることで、「1以上」「0以上」「0または1」といった関係を表現します。たとえば「○」と「鳥の足」の組み合わせは「0以上（0件の場合もあるが、複数件になることもある）」を意味します。

IE記法は視覚的にわかりやすいため、チーム内での共有や初学者の学習に適しています。近年はIE記法を採用する現場が増えており、多くのER図作成ツールがIE記法をデフォルトで対応しています。

IDEF1X記法の特徴

IDEF1X記法は、Integration Definition 1Xの略で、米国の標準規格として策定された記法です。IE記法に比べて厳密な表現が可能で、大規模システムの設計や公的機関での利用で見られます。

IDEF1X記法では、カーディナリティを以下の記号で表現します。

・黒丸「●」：多を表す

・菱形「◇」：0または1を表す

・「P」：1以上を表す

・「Z」：0または1を表す

また、IDEF1X記法ではエンティティの種類を角の形状で区別します。角が直角のエンティティは「独立エンティティ」、角が丸いエンティティは「従属エンティティ」を示します。従属エンティティとは、親エンティティのデータが存在しなければデータを持てないエンティティのことです。

カーディナリティの読み方と使い分け

カーディナリティは、ER図を正しく読み書きする上で最も重要な要素のひとつです。以下の表に、主なカーディナリティの種類と記号、具体例をまとめます。

関係	IE記法の記号	IDEF1X記法の記号	具体例
1対1	両端に縦線（｜）	子側の黒丸に「1」を添える	社員と社員証
1対多	片端に鳥の足（∈）	片端に黒丸と「P」	部署と社員
多対多	両端に鳥の足	両端に黒丸	学生と講義
0以上	○と鳥の足の組み合わせ	黒丸（●）のみ	顧客と注文

カーディナリティを正しく設定することで、テーブル間の外部キー制約やNULL許容の判断が明確になります。設定を誤ると、データの整合性が崩れたり、不要なテーブルが生まれたりするため、業務ルールを正確に把握した上で定義することが重要です。

なお、カーディナリティが「多対多」になった場合は、間に中間テーブル（連関エンティティ）を挟んで「1対多」の関係に分解するのが一般的です。たとえば「学生と講義」の多対多は、「履修」という中間テーブルを置いて「学生—履修（1対多）」「講義—履修（1対多）」に分解します。

＼ システム開発・データベース設計のご相談 ／ ▶ 資料請求はこちら

ER図の書き方｜5つのステップで進める手順

ER図は一度に完成形を作ろうとするのではなく、段階を踏んで設計を進めることで精度の高い図に仕上がります。ここでは、実務で使われる基本的な5つのステップを紹介します。

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

最初に行うのは、システムが管理するデータの「まとまり」を洗い出す作業です。業務フローや要件定義書から、管理対象となるモノや概念を抽出します。

たとえばECサイトであれば、「顧客」「商品」「注文」「カテゴリ」「配送先」などがエンティティの候補になります。この段階では細部にこだわりすぎず、まずは必要なエンティティを漏れなくリストアップすることが大切です。

要件定義書の作成方法については、関連記事も参考にしてください。

関連記事：要件定義の例｜システム種類別の要件例と書き換え集

ステップ2：エンティティの属性を定義する

エンティティを洗い出したら、それぞれのエンティティが持つ属性（アトリビュート）を定義します。「顧客」であれば「顧客ID・氏名・メールアドレス・電話番号・住所」といった項目です。

このとき、主キー（Primary Key）を必ず決めてください。主キーはエンティティ内のレコードを一意に識別するための属性で、「顧客ID」や「注文番号」のように重複しない値を設定します。主キーはER図上で下線やPKの表記で区別します。

また、他のエンティティとの関連づけに使う外部キー（Foreign Key）も、この段階で意識しておくと後の作業がスムーズです。

ステップ3：リレーションシップを設定する

エンティティ間に、業務ルールに基づいた関係（リレーションシップ）を設定します。リレーションシップは「動詞」で表現すると理解しやすくなります。

たとえば「顧客が注文をする」「注文は商品を含む」「商品はカテゴリに属する」のように、エンティティ同士がどのようにつながっているかを一つずつ確認していきます。

リレーションシップを設定するときは、業務上のルールを正確に反映することが重要です。「1人の顧客は複数の注文を持てるのか」「1つの注文に複数の商品を含められるのか」といった問いに答える形で、関係性を定義していきます。

ステップ4：カーディナリティを決める

リレーションシップを引いたら、それぞれの関係に対してカーディナリティを設定します。先述のとおり、「1対1」「1対多」「多対多」のいずれかを選びます。

カーディナリティを決めるときのポイントは、「最小値」と「最大値」の両方を考えることです。たとえば「顧客と注文」の関係では、最小値は「0（まだ注文していない顧客もいる）」、最大値は「多（複数回注文する顧客もいる）」なので、「1対0以上（多）」となります。

多対多の関係が見つかった場合は、中間テーブルを使って1対多に分解します。この分解を行わないままデータベースを構築すると、データの重複や更新時の不整合が発生しやすくなります。

ステップ5：正規化でデータ構造を整える

ER図の初版ができたら、正規化を行ってデータ構造を整理します。正規化とは、データの重複や矛盾を排除するために、テーブルの構造を段階的に見直す手法です。

一般的には第3正規形まで行えば、実務上は十分なケースが大半です。正規化の各段階では以下のチェックを行います。

・第1正規形：1つのセルに複数の値が入っていないか（繰り返し項目の排除）

・第2正規形：主キーの一部だけに依存する属性がないか（部分関数従属の排除）

・第3正規形：主キー以外の属性に依存する属性がないか（推移的関数従属の排除）

正規化を過度に進めるとテーブル数が増えすぎてパフォーマンスに影響することもあるため、システムの特性に応じてバランスを取ることが求められます。

正規化の作業は、ER図上でエンティティの分割や属性の移動として表現されます。正規化を行うたびにER図を更新し、テーブル構造の変化を反映させていくことで、設計ドキュメントとしての正確性を保てます。正規化前後のER図を比較しておくと、レビュー時にも変更点が明確になり、設計判断の根拠を示しやすくなります。

ER図の3つのデータモデル

ER図は、システム開発の上流工程から下流工程にかけて段階的に詳細化していきます。この段階ごとのER図の状態を「データモデル」と呼び、概念モデル・論理モデル・物理モデルの3段階に分かれます。

概念モデル

概念モデルは、システムの設計初期に作成するER図です。業務の全体像を把握するために使い、エンティティとリレーションシップだけで構成されます。アトリビュートやカーディナリティの詳細はこの段階では省略するのが一般的です。

概念モデルの目的は、関係者間で「このシステムはどんなデータを扱うのか」という共通認識を作ることです。要件定義のフェーズで、エンジニアだけでなく業務担当者やプロジェクトマネージャーとの認識合わせに使います。

論理モデル

論理モデルは、概念モデルを詳細化したER図です。すべてのエンティティにアトリビュートを定義し、主キーと外部キーを明記します。カーディナリティも正確に設定し、正規化も済ませた状態にします。

論理モデルは特定のデータベース製品に依存しない設計として作成します。つまり、OracleでもPostgreSQLでもMySQLでも適用できる汎用的な設計図です。データ型はまだ物理的な型（VARCHARやINTなど）ではなく、「文字列」「数値」「日付」といった論理的な型で定義します。

物理モデル

物理モデルは、論理モデルを特定のデータベース製品向けに変換したER図です。データ型をVARCHAR(255)やINT、DATETIMEなどの具体的な型に変換し、インデックスやパーティションなどの物理的な設計情報も追加します。

物理モデルの段階では、テーブル名やカラム名を英語表記に変換する作業も行います。また、パフォーマンスを考慮して、あえて正規化を崩す（非正規化する）判断を行う場合もあります。たとえば、頻繁にJOINが発生するテーブル同士を統合して検索速度を優先する、といったケースです。

物理モデルから実際のデータベースへのテーブル生成は、DDL（Data Definition Language）と呼ばれるSQL文で行います。ER図作成ツールの中には、物理モデルからDDLを自動出力する機能を備えたものもあり、設計と実装の乖離を減らすことに役立ちます。

要件定義書のフォーマットについて詳しく知りたい方は、以下の記事も参考になります。

関連記事：要件定義書のフォーマット｜表紙・ID体系・表のレイアウトと選び方

＼ システム開発・データベース設計のご相談 ／ ▶ 相談予約はこちら

ER図作成に使えるツール

ER図は手書きやExcelでも作成できますが、専用ツールを使うと記号の描画やレイアウトの調整が効率的になります。ここでは、無料・有料のツールをまとめて紹介します。

ツール名	費用	動作環境	特徴
draw.io（diagrams.net）	無料	ブラウザ/デスクトップ	アカウント不要で利用可能。Google DriveやGitHub連携にも対応
A5:SQL Mk-2	無料	Windows	既存DBからER図を自動生成できる。日本語対応で操作しやすい
Cacoo	有料（無料枠あり）	ブラウザ	ヌーラボ製。チームでの同時編集が可能。日本語サポートが充実
Lucidchart	有料（無料枠あり）	ブラウザ	テンプレートが豊富。Confluenceなど外部ツールとの連携が強み
SI Object Browser ER	有料	Windows	国内4,000社以上の導入実績。主要DBと直接連携し逆生成が可能
MySQL Workbench	無料	Windows/Mac/Linux	MySQL公式ツール。ER図作成からSQL生成まで一貫して作業できる

無料で使えるツールの選び方

初めてER図を作る場合や、個人の学習目的で使う場合は、無料ツールで十分対応できます。draw.io（diagrams.net）は、アカウント登録なしでブラウザ上からすぐに使い始められるため、手軽さでは一番です。IE記法・IDEF1X記法のどちらにも対応しており、Google DriveやGitHubへの保存も可能です。

既存のデータベースからER図を自動生成したい場合は、A5:SQL Mk-2が有力な選択肢です。Windows専用ですが、MySQL・PostgreSQL・Oracle・SQL Serverなど主要なデータベースに接続でき、テーブル構造からER図を逆生成できます。日本語で開発されたツールのため操作画面がわかりやすく、国内のエンジニアから高い評価を得ています。

有料・高機能ツールの選び方

チームでの共同編集や大規模システムのER図管理が必要な場合は、有料ツールの導入を検討してください。

CacooやLucidchartは、ブラウザ上で複数人が同時にER図を編集でき、変更履歴も残るため、チーム開発に向いています。SI Object Browser ERは、国内4,000社以上の導入実績を持つ本格的なER図作成ツールで、主要データベースとの直接連携やテーブルの自動生成が可能です。

ツール選定では、「作成したER図をどのような形式で出力する必要があるか」「データベースとの連携が必要か」「チームの人数と予算はどの程度か」を軸に比較するとよいでしょう。

システム開発の外注を検討している場合は、発注先の選び方もあわせて確認しておくと安心です。

関連記事：システム開発の外注とは｜メリット・デメリット、費用相場、選び方を解説

＼ システム開発・データベース設計のご相談 ／ ▶ 資料請求はこちら

ER図を活用するときの注意点

ER図は一度作って終わりではなく、設計フェーズ全体を通じて更新・管理し続けるものです。ここでは、ER図の運用で見落としやすいポイントを整理します。

設計段階で見落としやすいポイント

ER図の設計でありがちな失敗のひとつが、業務ルールの確認が不十分なまま作成を進めてしまうことです。エンティティの洗い出しやカーディナリティの決定は、業務の実態に基づいて行う必要があります。設計者の推測だけで進めると、実際の運用段階でデータの不整合が発覚するリスクがあります。

もうひとつ注意すべきなのが、将来の拡張性を考慮しない設計です。現在の業務だけでなく、今後追加される可能性のある機能やデータ項目も視野に入れて設計しておくと、後の改修コストを抑えられます。

また、多対多の関係をそのまま残してしまうケースもよく見られます。多対多は必ず中間テーブルに分解してからデータベースを構築するのが原則です。この分解を怠ると、データの重複が発生し、更新時の不整合につながります。

チームでの共有と更新ルールの決め方

ER図はチーム全体で参照する設計ドキュメントです。更新のルールが決まっていないと、「最新版がどれかわからない」「誰かが勝手に変更した」といった混乱が起きやすくなります。

ER図の管理では、バージョン管理ツールとの連携が有効です。GitやConfluenceなどでER図のファイルを管理し、変更時にはコミットメッセージやコメントで変更理由を記録する運用が推奨されます。

チームでER図を運用する際のルールとして、以下を事前に取り決めておくとスムーズです。

・ER図の更新権限を持つメンバーを決める

・変更時は変更理由と影響範囲をコメントに残す

・定期的にレビューの場を設け、設計の整合性を確認する

・ER図と実際のデータベースの差分が生じていないか定期的にチェックする

ER図を「生きたドキュメント」として運用できるかどうかが、システムの保守性と拡張性に直結します。開発初期だけでなく、運用フェーズでもER図を最新の状態に保つことを意識してください。

実際の現場では、開発が進むにつれてテーブル構造の変更が頻繁に発生します。カラムの追加や削除、テーブルの分割や統合が行われるたびにER図を更新しなければ、設計書と実態が乖離してしまいます。この乖離が放置されると、後任の開発者が設計の意図を読み取れず、改修時に想定外の不具合を引き起こす原因になります。

こうした問題を防ぐために、データベースのテーブル構造からER図を逆生成できるツールを併用するのも有効な方法です。A5:SQL Mk-2やSI Object Browser ERなどのツールでは、既存データベースに接続してER図を自動的に作成できるため、現在のテーブル構造を正確に反映したER図を短時間で得ることが可能です。

まとめ

ER図は、データベース設計においてデータの構造と関係性を可視化するための標準的な手法です。エンティティ・アトリビュート・リレーションシップ・カーディナリティという4つの要素で構成され、IE記法やIDEF1X記法といった記法で表現されます。

ER図の作成は、エンティティの洗い出しから始めて、属性定義・リレーション設定・カーディナリティ決定・正規化の5ステップで進めます。概念モデル・論理モデル・物理モデルと段階的に詳細化していくことで、業務要件を正確に反映したデータベース設計が実現できます。

ツール選定では、個人の学習や小規模プロジェクトであればdraw.ioやA5:SQL Mk-2などの無料ツールで十分対応できます。チーム開発や大規模システムでは、共同編集やDB連携に強い有料ツールの検討も必要です。

データベース設計やシステム開発の進め方でお悩みの方は、ネクストスケールの無料相談をご活用ください。 ▶ 無料で経営相談する