ER図 (実体関連図) とは？書き方・記号の意味からデータベース設計まで解説

ER図 (ERD) は、システム内の異なるエンティティ間の関係を示す図です。システム内にどのような情報が存在し、それらがどのように関連付けられているかを一目で把握するのに特に役立ちます。また、実際の運用シナリオでユーザー、ソフトウェア、データベースがどのように相互作用するかをチームで検討する際にも効果的です。

本記事では、ER図の基礎知識から用途、構成要素、そして Lucidchart を使った具体的な書き方まで詳しく解説します。

ER図とは？

ER図（実体関連図・ERD）とは、システム内における人、オブジェクト、概念などのエンティティが互いにどのように関連しているかを示す図です。ソフトウェアエンジニアリングやビジネス情報システムの分野において、リレーショナルデータベースの設計やデバッグに最もよく使用されます。ER図（ERモデル）では、長方形、ひし形、楕円、結合線などの標準化された記号を使用して、エンティティ、リレーションシップ、およびそれらの属性の相互関係を視覚的に表現します。これらは言語の文法構造に対応しており、エンティティが「名詞」、リレーションシップが「動詞」の役割を果たします。

ER図はデータ構造図（DSD）と関連していますが、DSDはエンティティ間の関係ではなく、エンティティ内の要素の関係に焦点を当てています。また、ER図は、プロセスやシステムの情報の流れをマッピングするデータフロー図（DFD）と併せて使用されることもあります。

ER図の用途

データベース設計

ER図は、リレーショナルデータベースのモデリングと設計において中核をなすツールです。論理データモデルはビジネスルールや概念構造の整理に用いられ、物理データモデルは実際の技術的な実装に使用されます。ソフトウェアエンジニアリングでは、要件定義の最初のステップとしてER図を作成し、その後具体的なデータベース設計へと落とし込んでいくのが一般的なプロセスです。

新しいプロジェクトの開始時にERDを作成することで、ユーザー、システム、データベースなどの要素とデータの構造・関連性を明確に定義できます。前提条件やデータの依存関係を早い段階で可視化できるため、開発着手前の計画策定や意思決定の質が大幅に向上します。

 データベースのトラブルシューティング

ER図は、既存のデータベース構造を分析し、データ構造の不整合や設計上の問題を発見・解決するためにも活用されます。現状の設計を図式化して可視化することで、問題箇所やボトルネックを迅速に特定できます。

 ビジネス情報システム

ER図は、ビジネスプロセスを支えるリレーショナルデータベースの設計や分析に活用されます。エンティティやユーザーのアクション、データ同士の相互作用が複雑に絡み合うビジネスにおいて、データベースの可視化は不可欠です。業務プロセスを効率化し、必要な情報へ迅速にアクセスできる環境を構築することで、成果の向上につながります。

ビジネスプロセスリエンジニアリング（BPR）

ER図は、BPR（業務プロセス再構築）における既存データベースの分析や、新たなシステム構築に伴うデータベース構造の設計・モデル化に役立ちます。

 教育

教育機関における各種データの管理や検索システムなど、リレーショナルデータベースは教育分野でも幅広く活用されています。ER図は、それらのデータ構造を効率的に計画・設計することはもちろん、データベース設計の基礎を学ぶ・教えるための教材としても非常に有効です。

研究

研究分野における分析の多くは構造化データを扱うため、データを効果的に蓄積・分析するためのデータベース構造を構築する上で、ER図は重要な役割を果たします。

ER図の構成要素と特徴

ER図は、主にエンティティ、リレーションシップ、属性の3つの要素で構成されています。また、要素同士の数値的な対応関係（1対1、1対多など）を定義するカーディナリティも重要となります。

主な構成要素と関連用語の意味は以下の通りです。

エンティティ

エンティティとは、あらゆる種類のデータオブジェクトのことです。これらのオブジェクトには、コンピューター、プリンター、従業員、顧客、場所、イベント、コンセプトなどがあります。

エンティティタイプ：
同じ属性を持つエンティティの定義や分類（枠組み）を指します。たとえば「顧客」や「製品」といったデータ全体のカテゴリがこれに該当します。

エンティティセット： 
特定の時点でデータベース内に存在する、同じエンティティタイプに属する実体の集合体を指します。たとえば「先月購入した顧客のデータ群」などがこれに当たります。なお、集合に含まれる個々のデータ（特定のある顧客1人など）は「インスタンス（個体）」と呼ばれます。

エンティティのカテゴリ：
エンティティは主に、強（ストロング）、弱（ウィーク）、連想（アソシエーティブ）の3つに分類されます。

• 強エンティティ： 自身の主キー（属性）のみで一意に識別できるエンティティ。
• 弱エンティティ： 単体では一意に識別できず、親となる強エンティティに依存するエンティティ。
• 連想エンティティ（中間エンティティ）： 多対多（N:M）のリレーションシップを解消するために、エンティティ同士を結びつける役割を持つエンティティ。

エンティティキー：
エンティティキーとは、エンティティセット内のデータ（インスタンス）を一意に識別（特定）するための属性です。主にスーパーキー、候補キー、主キーの3種類があります。

• スーパーキー： 1つまたは複数の属性の組み合わせで、エンティティを一意に特定できるキー。
• 候補キー： スーパーキーのうち、必要最小限の属性のみで構成されたキー（冗長な属性が含まれていないもの）。1つのエンティティセットに複数存在する場合があります。
• 主キー： 複数存在する候補キーの中から、データベース設計者が代表として選択した一意のキー。

リレーションシップ

リレーションシップは、エンティティ同士がどのように関連し合っているかを定義します。言語の文法構造においては「動詞」の役割を果たします。

例えば「顧客が製品を購入する」という場面では、「顧客」と「製品」がエンティティであり、「購入する」という行為が両者を結びつけるリレーションシップとなります。

リレーションシップは通常、ひし形（チェン記法）や結合線上のラベル（IE記法など）で表示されます。

再帰的リレーションシップ：
再帰的リレーションシップでは、同じエンティティがリレーションシップに複数回参加します。

属性（アトリビュート）

例えば、「顧客」というエンティティには、「氏名」「住所」「決済情報」といった属性が含まれ、顧客（インスタンス）ごとにそれぞれの値が記録されます。

記述属性：

エンティティではなく、リレーションシップ（関連）自体が持つ属性を指します。

（例：「顧客」が「商品」を「購入」するリレーションシップにおいて、購入した「日時」や「数量」などはリレーションシップ自体に紐付く記述属性となります。）

属性の分類：
属性は、その構造や保持する値の数によって以下のように分類されます。

• 単純属性（不可分属性）： これ以上分割できない最小単位の属性（例：社員IDなど）。

• 複合属性： 複数の要素（サブ属性）に分割できる属性（例：「氏名」を「姓」と「名」、「住所」を「都道府県」と「市区町村」に分割）。

• 派生属性（誘導属性）： ほかの属性から計算・算出される属性（例：「生年月日」から計算される「年齢」）。

• 単一値属性： 1つの値のみを保持する属性（例：マイナンバー）。

• 多価属性： 1つのエンティティに対して複数の値を保持できる属性（例：1人が複数所有する「電話番号」や「保有資格」）。

これらは必要に応じて組み合わせることも可能です（例：単純単一値属性、複合多価属性など）。

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

カーディナリティ（多重度）とは、エンティティ間の数値的な対応関係（要素数の比率）を定義するものです。主な関係には以下の3種類があります。

• 1対1（1:1）： 1つのエンティティに対し、もう一方のエンティティが1つだけ対応する関係。（例：1人のユーザーに対して1つのマイページプロフィール）

• 1対多（1:N）： 1つのエンティティに対し、もう一方のエンティティが複数対応する関係。（例：1人の顧客が複数の注文を行うが、個々の注文の購入者は1人に特定される）

• 多対多（N:M）： 双方のエンティティが互いに複数対応する関係。（例：1人の顧客が複数の商品を購入でき、1つの商品も複数の顧客に購入される）

カーディナリティの表示：
カーディナリティの記号を配置する位置には、主にルックアクロス（Look-across / 対向表記）とセームサイド（Same-side / 同側表記）の2種類のスタイルがあります。

• ルックアクロス（対向）： 線の反対側（関連する相手側エンティティの近く）にカーディナリティ記号を配置する方式（IE記法やUMLなどで主流）。

• セームサイド（同側）： 基準となる自エンティティの近くに記号を配置する方式（チェン記法などで使用）。

 カーディナリティの制約：
リレーションシップにおいて、エンティティが結びつく最小値（必須か任意か）および最大値（1つか複数か）の制限を指します。（例：「0以上（任意）」「1のみ（必須）」「1以上」など）

自然言語（文法）とのマッピング

ER図の各構成要素は、日常言語の品詞に例えて考えると理解しやすくなります。要件定義書などのテキストからデータベース設計へ落とし込む際の目安として活用できます。 

• 普通名詞（エンティティタイプ）： 「顧客」「商品」など

• 固有名詞（エンティティ / インスタンス）： 「山田太郎」「iPhone 15」など

• 動詞（リレーションシップ）： 「購入する」「予約する」など

• 形容詞（属性）： 「新規の（顧客）」「在庫ありの（商品）」など

• 副詞（リレーションシップの属性）： 「定期的に（購入する）」など

ERDの記号と表記法

ER図には、プロジェクトの目的やモデリング手法に応じた代表的な表記法が存在します。主要な表記法の特徴や図形シンボルの詳細については、ER図の記号と表記法ページを参照してください。

チェン記法（Chen Notation）

クロウズフット / IE記法（Information Engineering / マーティン記法）

バックマン記法（Bachman Notation）

IDEF1X記法

バーカー記法（Barker Notation）

オブジェクト指向の規則を使用してERスタイルの関係を表現したい場合、一部のチームはUML表記法を適用することもあります。これは、ERDがUML図の一種になるという意味ではありません。代わりに、エンティティの関係とカーディナリティを記述するためにUML表記法が使用されることを意味します。UML表記法では、リレーションシップは2つのエンティティを接続する実線として表示されます。カーディナリティは線上に示され（たとえば、1..1は1対1、1..*は1対多を示します）、エンティティ間の関係を定義するために動詞句（「〜によって作成された」や「〜によって注文された」など）を追加できます。

表記法ごとの作成例

以下に、それぞれの記法を用いて作成されたER図の例を示します。

概念データモデル、論理データモデル、物理データモデル

ERモデルは、設計の進行段階や目的に応じて3つの抽象度（詳細レベル）で作成されます。 

概念データモデル（Conceptual Data Model）

 このモデルは、詳細が最も少ない最高レベルのビューを示します。その価値は、モデル全体の範囲を捉え、システムアーキテクチャを描写することにあります。より小規模なシステムの場合は、論理モデルから始めることができます。

論理データモデル（Logical Data Model）

概念モデルに詳細なデータ要素（各エンティティの属性、主キー、具体定義）を追加したモデルです。ビジネスルールや業務要件を正確に反映させますが、特定のRDBMS（MySQL, PostgreSQLなど）や実装技術には依存しない独立した設計を行います。

物理データモデル（Physical Data Model）

論理モデルをベースに、実際のデータベース構築・実装に向けて作成される最終段階のモデルです。使用するRDBMSの仕様に合わせて、具体的なテーブル名、カラム名、データ型、インデックス設定、制約（外部キーなど）などの技術的な詳細をすべて定義します。

システムの規模が大きくなると、すべての情報を1つの図に収めるのが困難になるため、抽象度の異なるER図を切り分けて作成したり、サブシステムごとに図を分割して表現することが効果的です。

ER図の基本的な書き方・設計手順

1. 目的と範囲の定義：
モデリングを行う対象の目的と適用範囲（スコープ）を明確にします。

2. エンティティの特定：
システムに必要な主要エンティティを洗い出します。図上に長方形などの図形で配置し、名詞（「顧客」「注文」など）で命名します。

3. リレーションシップの設定：
エンティティ同士の関連性を特定し、線で結びます。必要に応じて関係性を表す動詞（「購入する」など）をラベル付けします。

4. 属性（アトリビュート）の追加：
各エンティティに紐付くデータ項目（属性）を追加します。（※チェン記法では楕円で表現し、IE記法などではエンティティ枠内に一覧で記述します。）

5. カーディナリティ（多重度）の設定：
エンティティ間の数値的な対応関係（1対1、1対多、多対多）を記号や数値で明記します。

大規模なシステムを可視化する場合は、図の読みやすさ（視認性）を保つために、モデルを複数に分割して作成するのが効果的です。例えば、全体像を捉えるための「概念モデル」1つに加え、サブシステムやドメインごとに切り分けた「物理モデル」を複数用意するなどの工夫を検討しましょう。

LucidchartでER図を作成する方法

1. 新規ドキュメントの作成

Lucidchartで新しいドキュメントを開きます。空白のキャンバスから作成を開始することも、豊富に用意されたER図テンプレートを活用して時間を短縮することも可能です。

2. ERD図形ライブラリの有効化

エディター左側のメニューから「その他の図形」をクリックし、ライブラリ一覧で「実体関係（ERD）」にチェックを入れて有効化します。

3. エンティティ図形の配置

左ペインから長方形などの図形をキャンバスへドラッグ＆ドロップし、エンティティや属性を配置します。必要なデータ要件が漏れなく網羅されているかを確認しましょう。

4. リレーションシップの接続

図形を選択し、縁に表示される丸アイコンから線を伸ばして別の図形へ接続します。既存データベースの不具合調査を行う場合は、属性やリレーションシップの「漏れ」や「矛盾」がないか重点的にチェックします。

5. ER図の共有とレビュー

完成したER図は、メールやSlack、共有リンクを通じてチームメンバーへ簡単に共有できます。画面右上の「共有」ボタンをクリックし、権限レベル（閲覧・編集など）を設定してチームでレビューを行いましょう。

【動画解説】ER図の作成手順とポイント

ER図入門：データベース設計の基本（Part 1）

ER図入門：データベース設計の基本（Part 2）

ER図の限界と注意点

ER図はリレーショナルデータベースの設計において非常に強力ですが、すべてのシステムやデータ構造に適しているわけではありません。以下のようなケースでは、ER図の活用が適さない、または別のモデリング手法が必要になる場合があります。

• NoSQLや非リレーショナルデータには不向き：
  ER図は標準的な表構造を前提としているため、MongoDBのようなドキュメント型やRedisといったキー・バリュー型データベースの設計には適していません。データストアの主流がNoSQLの場合は、それぞれの構造に合わせたモデリング手法を用います。

• 非構造化・半構造化データのモデル化が困難：
  音声・画像・ログファイルなどの非構造化データや、ネストされたJSONといった半構造化データは、明確な行と列で定義できないため、ER図で表現するのが困難です。

• レガシー・異種システム統合の難しさ：
  構造化されていない既存のレガシーシステムや、異なる構造を持つ外部データベースと統合する際、単純なERモデルでは全体像を正確に反映しきれないことがあります。

ERモデルの歴史

コンピューター科学者であり応用数学者でもあるピーター・チェン（Peter Chen）氏は、1970年代にデータベース設計のためのERモデリングを開発したことで知られています。コンピューター科学という分野が存在する以前から、概念同士の相互関連性の可視化は古代ギリシャの哲学者にまで遡り、19世紀〜20世紀の論理学者の著作にも見られます。

1960年代〜1970年代にかけては、チャールズ・バックマン（Charles Bachman）氏が「バックマン図」を開発し、A.P.G.ブラウン（A.P.G. Brown）氏は実世界システムモデリングに関する著作を出版しました。 その後、ジェームズ・マーティン（James Martin）氏がERDをさらに洗練させました。チェン氏らによるこれらの研究は、現在ソフトウェア設計で広く使用されている統一モデリング言語（UML）の開発にも大きく貢献しています。