ER図の書き方は？基本ルールと手順を解説！（記号・線・矢印・カーディナリティ・IE記法・UMLなど）

「ER図を自分で書いてみたいけれど、どこから始めればいいのかわからない」という方は多いのではないでしょうか。

ER図には決まったルールと手順があり、それを順番に理解していけば初心者でも正確なER図を作成できるようになります。

記号の選び方・エンティティの洗い出し方・リレーションの引き方など、ER図作成には押さえておくべきポイントが複数あります。

この記事では、ER図の基本的な書き方ルールと作成手順を、IE記法・UML記法の使い分けも含めてわかりやすく解説していきます。

ER図の書き方は「エンティティ→属性→リレーション→カーディナリティ」の順で進める

それではまず、ER図の書き方の基本的な流れという結論から解説していきます。

ER図を書く際は、「エンティティの洗い出し」「属性の定義」「リレーションの設定」「カーディナリティの記述」という4つのステップを順番に進めるのが基本です。

この順序を守ることで、抜け漏れのない正確なER図を効率よく作成できます。

いきなりツールを開いてER図を書き始めるより、まず紙やホワイトボードでエンティティを書き出してから整理する進め方がおすすめでしょう。

 

ER図を書く前の準備：要件の整理

ER図を書き始める前に、まず「このシステムで何を管理するか」という要件を整理することが大切です。

要件が曖昧なままER図を書き始めると、後から大幅な修正が必要になることがあります。

業務フロー・画面仕様・帳票など、システムに関連するドキュメントを事前に確認しておくことで、エンティティの洗い出し精度が大幅に向上するでしょう。

また、業務担当者へのヒアリングも有効な手段です。

ER図の記法を事前に決める

ER図を書き始める前に、プロジェクト内で使用する記法を統一しておく必要があります。

主な記法はIE記法とUML記法の2種類で、それぞれ記号の表現方法が異なります。

記法が混在するとER図を読み間違える原因になるため、チームで事前に使用する記法を決め、凡例を添付しておくと安心でしょう。

初心者には視覚的にわかりやすいIE記法がおすすめです。

論理ER図と物理ER図の違い

ER図には「論理ER図」と「物理ER図」の2種類があります。

論理ER図はデータの概念的な関係を表すもので、特定のデータベース製品に依存しない設計図です。

一方、物理ER図は実際に使うデータベース（MySQLやPostgreSQLなど）に合わせてデータ型・インデックス・制約まで具体的に記述したものです。

一般的には論理ER図で概念設計を固めてから物理ER図に落とし込むという流れで進めます。

ステップ1・2：エンティティの洗い出しと属性の定義

続いては、エンティティの洗い出しと属性の定義の具体的な方法を確認していきましょう。

ER図作成の土台となる重要なステップです。

エンティティの洗い出し方

エンティティとはデータベースで管理する「もの」や「概念」のことです。

エンティティを洗い出す際は、システムの要件や業務フローから「名詞」を拾い出すとスムーズに進みます。

洗い出したエンティティの候補から、重複しているものや属性として扱うべきものを整理して絞り込んでいきます。

エンティティは「テーブルとして独立して管理する必要があるか」という観点で判断するとよいでしょう。

主キー（PK）と属性の定義方法

エンティティが決まったら、次に各エンティティの属性（データ項目）と主キーを定義します。

主キーは各レコードを一意に識別するための列で、数値の連番IDを主キーとして設定するのが一般的です。

属性はそのエンティティが「持つべきデータ項目」を網羅的に定義します。

この時点でデータ型（INT・VARCHAR・DATEなど）も合わせて決めておくと、後の物理ER図作成がスムーズになるでしょう。

エンティティ作成時の注意点

エンティティを定義する際によくある間違いとして、「属性として扱うべき項目をエンティティにしてしまう」ことがあります。

たとえば「性別」や「ステータス」は独立したエンティティではなく、顧客や注文の属性として定義するのが適切です。

一方、複数の場所から参照される可能性がある項目はエンティティとして独立させることを検討しましょう。

「都道府県」や「カテゴリ」などはマスタテーブルとしてエンティティ化することでデータの一貫性が保ちやすくなります。

ステップ3・4：リレーションの設定とカーディナリティの記述

続いては、リレーションの設定方法とカーディナリティの記述手順を確認していきましょう。

ER図の核心ともいえる重要なステップです。

リレーションの設定方法

エンティティと属性が定義できたら、次にエンティティ間のリレーション（関係性）を設定します。

リレーションを設定する際は「AとBはどのような関係にあるか」を業務ルールに基づいて考えます。

多対多のリレーションが見つかった場合は、中間テーブルを作成して1対多×2に分解することを忘れないようにしましょう。

多対多をそのまま残すと後の実装で必ずつまずくため、ER図の段階で解消しておくことが重要です。

カーディナリティの記述方法（IE記法）

リレーションの線が引けたら、線の両端にカーディナリティを示す記号を付けます。

IE記法では「｜」「〇」「＜（鳥の足）」の3種類の記号を組み合わせて使います。

記号は「エンティティに近い側から、相手側の件数制約を読む」という方向で解釈します。

たとえば「顧客」側の端に「｜｜」が付いていれば「注文から見た顧客は必ず1件」という意味になるでしょう。

外部キーの配置ルール

カーディナリティを設定したら、外部キー（FK）をどちらのエンティティに配置するかを決めます。

基本ルールは「1対多のリレーションでは『多』側のエンティティにFKを持たせる」です。

顧客と注文の1対多リレーションであれば、「多」側である注文テーブルに顧客IDをFKとして追加します。

このルールを守ることでER図とデータベースの実装が一致した設計が実現できるでしょう。

IE記法とUML記法の書き方の違いと使い分け

続いては、IE記法とUML記法それぞれの具体的な書き方の違いと使い分けを確認していきましょう。

どちらの記法も同じ情報を表現できますが、記号の使い方が異なります。

IE記法の具体的な書き方ルール

IE記法では線の端に「｜」「〇」「＜」の記号を組み合わせてカーディナリティを表現します。

エンティティは四角い箱で表し、箱の中を横線で区切って上段にエンティティ名、下段に属性を列挙するのが一般的な書き方です。

主キーは「PK」または下線で、外部キーは「FK」で明示し、属性の並び順はPK→FK→その他の順にすると読みやすくなります。

UML記法の具体的な書き方ルール

UML記法ではエンティティをクラス図のように3つの区画に分けて書くのが基本です。

上段にエンティティ名、中段に属性、下段にメソッド（ER図では通常省略）を記載します。

カーディナリティは線の端に「1」「0..1」「1..*」「0..*」などの数値表記で記述し、関係の名前（ロール名）を線の上に記載することもあります。

比較項目	IE記法	UML記法
カーディナリティ表現	記号（鳥の足など）	数値（1..*など）
直感的なわかりやすさ	高い（視覚的）	やや低い（慣れが必要）
件数の細かい指定	難しい	可能（2..5など）
現場での普及度	非常に高い	エンジニア間で高い
対応ツール	Draw.io・A5:SQLなど多数	Lucidchart・PlantUMLなど

初心者にはIE記法、UMLに慣れたエンジニアや厳密な件数制約が必要な場合はUML記法が向いているでしょう。

ER図作成時に避けるべきよくある間違い

ER図を書く際によくある間違いをまとめると、次のような点が挙げられます。

まず「多対多のリレーションを中間テーブルなしで残してしまう」ことです。

次に「主キーを設定し忘れる」「外部キーを『1』側に配置してしまう」といったミスもよく見られます。

ER図のレビュー時には特にリレーションの向きとFKの配置を重点的に確認することをおすすめします。

まとめ

この記事では、ER図の基本的な書き方ルールと作成手順について解説しました。

ER図は「エンティティの洗い出し」「属性の定義」「リレーションの設定」「カーディナリティの記述」という4つのステップで作成します。

IE記法とUML記法のどちらを使うかはチームで統一することが大切で、初心者にはIE記法がおすすめです。

多対多のリレーションは必ず中間テーブルで解消し、外部キーは「多」側のテーブルに配置するという基本ルールを守ることで、正確なER図が作成できるでしょう。

論理ER図で概念を固めてから物理ER図に落とし込む手順を意識して、実践的なデータベース設計に役立ててください。