ER図とは？書き方・エンティティやリレーション・カーディナリティを実装目線で解説

ER図とは、データベースに保存するデータの構造を、エンティティ（実体）とその関係で表す設計図です。テーブルをいきなり作り始めるのではなく、まず「何を、どんな単位で、どうつなげて持つか」をER図で固めてから物理的なテーブルへ落とすと、後から効いてくるデータの整合性を設計段階で作り込めます。この記事では、エンティティ・属性・リレーションという基本要素から、1対1や多対多を表すカーディナリティの読み方、IE記法とIDEF1Xの書き分け、多対多を中間テーブルへ分解する正規化との関係、概念・論理・物理の3層でモデリングを進める設計プロセス、Mermaidやdbdiagram.ioでコードとして管理する方法、そして設計工程で書くべき場面と書きすぎになる失敗パターンまでを、データベース設計の現場視点で整理します。

まとめ：ER図の構成要素・書き方とデータベース設計での役割

ER図の芯は、業務で扱うデータを「エンティティ」という箱に分け、箱と箱の関係（リレーション）を線で結んで、データの全体像を一枚で見渡せるようにすることにあります。エンティティは顧客や注文といったデータの実体、属性はその箱が持つ項目（顧客名やメールアドレスなど）、リレーションは注文が顧客に紐づくといった箱どうしのつながりを指します。この3つを押さえれば、ER図の骨格は読み解けるはずです。

関係の線には、1対1・1対多・多対多という数の関係（カーディナリティ）を添えます。ひとりの顧客が複数の注文を持つなら1対多、といった具合です。記法にはIE記法（鳥の足）とIDEF1Xがあり、どちらを使うかはツールとチームの慣れで選びます。多対多の関係はそのままテーブルにできないため、中間に別のエンティティを立てて1対多ふたつに分解します。この分解は、正規化という整理作業と地続きです。

ER図が効くのは、複数のテーブルが絡む業務システムのデータ構造を、実装前に関係者で合意する場面です。逆に、テーブルが数個しかない小さな仕組みまで律儀に描くと、更新されない紙の資料に終わります。どこまで描き、どこで手を止めるか、その線引きまで条件付きで言い切ります。DBの種類やRDBとNoSQLの選び方といった土台はデータベースとは何かで扱い、本記事はその中身をどう設計するかを描く役割です。

ER図とは何か：実体関連モデルの定義とデータベース設計での位置づけ

はじめに言葉の範囲をそろえます。ER図は、データを「実体（エンティティ）」と「関連（リレーションシップ）」で捉える考え方を図にしたもので、Entity Relationship Diagram の頭文字を取っています。プログラムの処理ではなく、保存するデータそのものの構造を対象にする点が特徴です。

ER図の定義と、データ構造を表す実体関連モデルとしての位置づけ

ER図は、1970年代にピーター・チェンが提唱した実体関連モデル（ERモデル）を作図したもので、現実の業務に登場する「モノ」や「コト」をエンティティとして抜き出し、その間の関係を線で結んで表します。狙いは、テーブルを作る前に「どんなデータを、どの粒度で、どうつなげて持つか」をデータの設計として固めることです。たとえばECサイトなら、顧客・商品・注文・注文明細といったエンティティを置き、顧客が注文を持ち、注文が複数の商品を明細として抱える、という構造を線で描きます。処理の流れを時間順に描くクラス図やシーケンス図が「動き」を扱うのに対し、ER図が扱うのは「データの静的な構造」です。オブジェクトの構造を属性と操作で描くクラス図とは多重度の記法が近く、対比しながら読むと関係の表し方が整理できます。

概念・論理・物理の3層でER図を描くデータモデリングの進め方

ER図は一枚で完成させるものではなく、抽象度を3段階で降ろしながら詳細化するのが実務の進め方です。まず概念モデルで、業務に登場する主要なエンティティと関係だけを大づかみに描きます。顧客と注文がある、程度の粗さです。次に論理モデルで、各エンティティの属性、主キー、正規化を反映した関係を書き込み、特定のデータベース製品に依存しない形でデータ構造を確定させます。最後の物理モデルは、実際に載せるRDBMSに合わせてテーブル名・カラム名・データ型・インデックスまで具体化する段階です。この3層を分けておくと、業務の議論（概念・論理）と製品固有の実装（物理）を切り離して進められ、途中でデータベース製品を変えても論理設計を作り直さずに済みます。物理設計で載せる製品の選び方はDBMSとは何かで、具体的なRDBMSの採用判断はMySQLとは何かで詳しく扱っています。

エンティティ・属性・リレーションというER図の3つの基本要素

ER図は、3つの要素さえ読めれば骨格をつかめます。エンティティは、データとして管理したい実体で、四角形で表します。顧客・商品・注文のように、後でテーブルになる単位だと考えると分かりやすいです。属性は、そのエンティティが持つ項目で、顧客なら顧客ID・氏名・メールアドレスなどが該当し、テーブルの列にあたります。属性のうち、行を一意に識別するものが主キー（顧客IDなど）で、下線や記号で区別するのが約束事です。リレーションは、エンティティ間のつながりを表す線で、注文は必ずどれかの顧客に属する、といった業務上の関係を示します。この3要素が組み合わさって、業務データの全体像を一枚に収めた設計図ができあがります。

ER図の記法：カーディナリティとIE記法・IDEF1Xの書き分け

ER図で表現に差が出るのは、線に添える数の関係（カーディナリティ）と、その描き方（記法）です。ここを正しく読み書きできると、図がデータの制約まで語り始めます。

1対1・1対多・多対多を表すカーディナリティ（多重度）の読み方

リレーションの線には、両端のエンティティが「いくつ対いくつ」で対応するかを示すカーディナリティを添えます。基本は3種類です。1対1は、一方のデータに対して他方がひとつだけ対応する関係で、社員と社員証のように分けて持つ場面で使います。1対多は、一方に対して他方が複数対応する関係で、ひとりの顧客が複数の注文を持つ、が典型です。多対多は、双方が互いに複数対応する関係で、注文と商品（ひとつの注文に複数商品、ひとつの商品は複数の注文に登場）が代表例です。あわせて、その関係が必須か任意か（最小のカーディナリティ）も表します。注文には顧客が必ず要る（必須）、顧客はまだ注文を持たなくてよい（任意）、といった区別です。この「多重度」と「必須/任意」を線に落とすことで、ER図はデータ間の制約そのものを表現します。多重度を線に添える発想は、オブジェクト間の関連を数で表すクラス図の多重度と共通する考え方です。

IE記法（鳥の足）とIDEF1X記法を実務で選び分ける判断基準

カーディナリティの描き方には、主にIE記法とIDEF1X記法の2つがあります。IE記法は、関係の「多」側を線の枝分かれ（鳥の足のような三又）で表す記法で、鳥の足記法とも呼ばれます。三又が「多」、線に交わる短い縦棒が「1」、丸が「任意（0を含む）」を示し、線の端を見るだけで多重度と必須/任意が直感的に読める点が長所です。IDEF1X記法は、米国政府の標準として整備された記法で、エンティティを識別従属（親なしに存在できない子）かどうかで角丸と角ばりに描き分け、キーの依存関係を厳密に表せます。実務での選び分けはこう考えると迷いません。関係者に非エンジニアが多く、直感的な合意を優先するならIE記法が向きます。金融や公共システムのように、キーの依存や識別関係を厳密に管理したい場面ではIDEF1Xが向きます。多くの作図ツールが既定でIE記法を採用しているため、特段の要件がなければIE記法で始め、チームの標準に合わせるのが現実的です。

多対多を中間テーブルに分解するER図と正規化・非正規化の関係

多対多の関係は、そのままではリレーショナルデータベースのテーブルにできません。注文と商品が多対多なら、間に「注文明細」という中間エンティティを立て、注文（1）対注文明細（多）、商品（1）対注文明細（多）という1対多ふたつに分解します。この分解は、データの重複や矛盾を防ぐために表を適切な単位へ分ける正規化と同じ作業です。ひとつのエンティティに属性を詰め込みすぎず、繰り返し現れる項目や、主キー以外の項目に従属する項目を別エンティティへ切り出していくと、結果として第3正規形に沿ったER図になります。逆に、参照ばかりで更新が少なく、結合の負荷を避けたい部分では、あえて正規化を崩して属性を持たせる判断（非正規化）もあり、これは物理設計での性能とのかね合いで決める設計判断です。論理モデルまでは正規化を徹底し、物理モデルで必要な箇所だけ崩す、という順で進めると、整合性と性能の両方を管理できます。

ER図の書き方：エンティティ抽出からコードでの管理までの手順

要素と記法を押さえたら、実際に描く手順に移ります。いきなり四角と線を書き始めず、業務に登場するモノを洗い出すところから始めるのが、破綻しない図への近道です。

業務要件からエンティティと属性を洗い出すER図の基本的な作成手順

ER図は、次の5ステップで組み立てると過不足がありません。業務の言葉からデータの構造へ、段階的に翻訳していきます。

1. エンティティを洗い出す：業務に出てくる名詞（顧客・商品・注文・入金など、管理したいモノやコト）を挙げ、四角形で並べる
2. 属性を割り当てる：各エンティティが持つ項目を書き出し、行を一意に識別する主キーを決める
3. リレーションを引く：エンティティ間の業務上の関係を線で結び、どのエンティティがどれと関わるかを確定する
4. カーディナリティを添える：各関係が1対1・1対多・多対多のどれか、必須か任意かを線の端に記す
5. 多対多を分解する：多対多の関係に中間エンティティを立て、1対多ふたつへ正規化する

最初から細かい属性やコード値まで詰めようとせず、まずは主要なエンティティと関係だけの概念モデルを描き切るのがコツです。全体の骨格が固まってから属性と主キーを足していくと、後戻りが減ります。エンティティの洗い出しは、そもそも業務で何を管理するかを決める要件定義と地続きの作業です。要件をどうまとめるかは要件定義の進め方にまとめており、要件からデータモデルへつなぐ入口になります。

Mermaidやdbdiagram.ioでER図をコードとして管理する方法

作図ツールで描いたER図は、仕様が変わるたびにエンティティと線を引き直す手間がかかります。バージョン管理と相性がよいのが、テキストから図を生成するツールです。Mermaidなら、Markdown内に erDiagram のブロックを書き、CUSTOMER ||--o{ ORDER : places のような一行で1対多の関係を表せて、GitHubやドキュメントツールでそのまま描画されます。dbdiagram.ioは、独自のDSLでテーブルとリレーションを記述でき、そのままSQLのCREATE文へ書き出せる点が実装寄りです。日本のRDBMS開発ではA5:SQL Mk-2も広く使われ、既存データベースからER図を逆生成（リバースエンジニアリング）できます。図をコードで持てば、レビューでスキーマの変更差分を追え、論理設計から物理設計へ、さらにSQLのCREATE TABLEへと落とす流れをGitで一貫して管理できる点が利点です。ツールに任せる前に、カーディナリティや正規化の意味を理解しておくと、生成された図やDDLの善し悪しを判断できます。

データベース設計工程でER図を使う判断と書きすぎの失敗パターン

ここからは立場を明確にします。ER図は、どんな開発でも必ず描くべき図ではありません。効く場面があり、逆に描くことが手間だけを増やす状況もあります。どちらかを見極める基準を、具体的な条件で示します。

論理設計でER図が効く場面と物理テーブル定義への橋渡しの判断

ER図がもっとも力を発揮するのは、複数のエンティティが複雑に関連する業務システムのデータ構造を設計する場面です。販売管理・在庫管理・会計のように、注文・在庫・請求が互いに参照し合う仕組みでは、データの持ち方を図で共有しておくと、テーブル分割の抜けや整合性の崩れを実装前に発見できます。工程全体のどこにER図という設計成果物が位置づくかはシステム開発の工程と7フェーズの成果物の全体像が判断の土台です。概念モデルで業務の合意を取り、論理モデルで正規化とキーを固め、物理モデルでRDBMSに合わせて具体化する、という順で使い分けると、業務の議論と実装の詳細を切り離して進められます。本記事は、その設計工程で使うデータモデリング手法そのものを掘り下げる役割です。

ER図を書きすぎない見極めと、過剰設計になりがちな失敗パターン

ER図を描くべきでない場面もはっきりあります。第一に、テーブルが数個で関係も単純な小さな仕組みです。コードやテーブル定義を見れば分かる構造を図にしても、保守の手間が増えるだけです。第二に、まだ業務要件が固まっていない検討初期に、細かい属性まで清書すると、要件が動くたびに描き直しになります。ありがちな失敗は3つあります。ひとつは、すべての属性やコード値まで一枚に詰め込み、線が交差して読めない巨大な図にしてしまうこと。ふたつめは、論理モデルと物理モデルを分けず、いきなり製品固有のデータ型やインデックスまで書き込んで、業務の議論ができなくなること。みっつめは、図を作ること自体が目的化し、実装後にスキーマが変わっても更新されず、実態と食い違ったまま放置されることです。三つに共通するのは、ER図がデータ構造の合意と設計判断の道具であるという原点を見失っている点にあります。全体を一枚に描き切ろうとせず、業務の中核となるエンティティと関係に絞り、詳細はDDLやデータ辞書に任せるほうが、図は長く使われます。

受託開発でデータモデルを業務要求から一貫して設計する体制の作り方

ER図が真価を発揮するのは、基幹システムや業務システムのように、多くのデータが連携し、長く保守し続ける前提の開発です。データ構造の設計を初期に誤ると、後からデータの重複や不整合が顕在化し、改修に多大な工数がかかります。とはいえ、業務の要求を破綻しないデータモデルへ落とし込むには、正規化の理論とドメイン（業務知識）の両方が要る仕事です。社内にデータ設計を主導できる人材がいない、既存システムのテーブル構造が複雑で手を入れづらい、といった場面では、外部の伴走が歯止めになります。一創では基幹システム開発として、業務要求をエンティティとリレーションへ整理する要件定義から、論理・物理設計、実装、運用までを一貫して支援しています。図を描く技術だけでなく、変更や拡張に強いデータモデルを業務要求から導くところまで含めた伴走が一創の強みです。

よくある質問

ER図の理解と実務でつまずきやすい点を、5つの質問に絞って整理します。

ER図とデータベースのテーブルは何が違いますか？

抽象度が異なります。ER図は、業務で扱うデータを実体（エンティティ）と関係で表した設計図で、特定のデータベース製品に依存しない論理レベルまでを主に扱います。テーブルは、そのER図を物理設計で具体化した実装で、製品固有のデータ型やインデックスを持つ実体です。実務では、ER図の論理モデルで正規化とキーを固めてから、物理モデルでテーブル定義（CREATE文）へ落とす、という順で使います。ER図が「どんなデータをどう持つかの合意」、テーブルが「その合意を実際に載せた形」だと考えると分かりやすいです。

1対多と多対多はどう描き分けますか？

関係の両端の数で判断します。一方に対して他方が複数対応するなら1対多で、顧客と注文（ひとりが複数注文）が典型です。双方が互いに複数対応するなら多対多で、注文と商品が代表例になります。IE記法では「多」側を鳥の足（三又）で描き、「1」側を短い縦棒で示すのが約束事です。多対多はそのままテーブルにできないため、間に中間エンティティ（注文明細など）を立てて1対多ふたつへ分解してから物理設計へ進めます。

IE記法とIDEF1Xはどちらを使えばよいですか？

関係者と要件で選びます。非エンジニアを含む関係者と直感的に合意したい場合や、多くの作図ツールの既定に合わせたい場合はIE記法（鳥の足）が読みやすいはずです。キーの依存や識別関係を厳密に管理したい金融・公共システムなどではIDEF1Xが向きます。特段の要件がなければ、読みやすさとツール対応の広さからIE記法で始め、チームやプロジェクトの標準があればそれに合わせるのが実際的です。記法よりも、カーディナリティと正規化を正しく反映することのほうが設計の質を左右します。

ER図と正規化はどう関係しますか？

地続きの作業です。正規化は、データの重複や矛盾を防ぐために表を適切な単位へ分ける整理で、その結果がER図のエンティティ分割に反映されます。多対多を中間エンティティへ分解したり、繰り返し項目を別エンティティへ切り出したりする操作が、第2・第3正規形に沿った形です。論理モデルまでは正規化を徹底し、物理モデルで結合の負荷を避けたい箇所だけ、あえて崩す（非正規化）判断を性能とのかね合いで加える、という順で進めると整合性と性能を両立できます。

ER図はどのツールで作成できますか？

作図に特化したツールとして、draw.io、Lucidchart、A5:SQL Mk-2などが挙げられます。テキストから図を生成するMermaid（erDiagram）やdbdiagram.ioも使え、Gitでのバージョン管理と併せて運用でき、dbdiagram.ioはSQLのCREATE文へ書き出せます。既存データベースからER図を逆生成したい場合はA5:SQL Mk-2が便利です。スキーマの変更が頻繁で図を実装と同期させたい場合はコードで管理できるツール、見た目を細かく整えたい場合はGUIの作図ツールが向きます。チームが図をコードで持つか資料として持つかに合わせて選ぶのが実際的です。

関連記事

• データベースとは：ER図で設計するデータを載せるDBの種類・DBMS・RDBとNoSQLの選び方の全体像
• SQLとは：論理設計したER図を物理設計のCREATE TABLEへ落とす、DDLの書き方
• クラス図とは：多重度の記法が近いUMLの図。オブジェクト構造とデータ構造を対にして読む
• 要件定義とは：エンティティ抽出の入口。業務要求からデータモデルへつなぐ上流工程
• システム開発の工程とは：ER図を作る設計がどの工程に位置づくかの全体像