E-R図とは？データベース設計における意味・読み方・関係を解説！

E-R図とは？データベース設計における意味・読み方・関係を解説！

データベースを設計するとき、保存したい情報と情報同士のつながりを整理する作業が欠かせません。

その全体像を視覚的に表す方法として使われるのが、E-R図です。

顧客、商品、注文のような身近なデータを例にすると、初めてでも構造を想像しやすくなります。

この記事では、E-R図の意味や読み方、エンティティとリレーションシップの関係、設計時の注意点まで解説します。

E-R図の意味とデータベース設計での役割

それではまずE-R図の意味と基本的な役割について解説していきます。

E-R図の定義と読み方

E-R図とは、データベースに保存する対象と対象同士の関係を図で表した設計図です。

E-RはEntity Relationshipの頭文字で、日本語では実体関連図と呼ばれます。

読み方はイーアールずが一般的で、業務システムの企画、要件定義、データベース設計などで用いられます。

Entityはエンティティと読み、管理したい人、物、出来事などのまとまりを指します。たとえば通販サイトなら顧客、商品、注文、配送先がエンティティの候補になるでしょう。

Relationshipはリレーションシップと読み、エンティティ同士がどのようにつながるかを表します。顧客が注文する、注文が商品を含む、といった関係が該当します。

E-R図は、表の列やデータ型を決める前に、必要な情報を漏れなく洗い出すために役立ちます。

文章だけで仕様を共有すると、商品と注文の関係を誰がどのように理解したかが見えにくくなります。

図にすると、各担当者が同じ構造を見ながら話せるため、認識のずれを早い段階で見つけやすくなります。

データベースの実装後に修正すると影響範囲が広がるため、設計段階でE-R図を確認する価値があります。

特に複数人で開発する場合は、名称の意味やデータの所有範囲を共有する共通言語として機能します。

エンティティと属性の基本

エンティティは管理対象のまとまりであり、属性はその対象を説明する個別の情報です。

顧客をエンティティにした場合、顧客番号、氏名、メールアドレス、登録日などが属性になります。

属性は、後でデータベースの列として実装されることが多い要素です。

ただし、画面に表示したい項目をすべて属性にすればよいわけではありません。たとえば顧客の年齢は生年月日から計算できるため、常に保存する必要があるとは限りません。

一方で、注文時点の配送先氏名は、顧客情報とは別に保存する必要が生じる場合があります。顧客が後から住所を変更しても、過去の配送記録まで書き換わらないようにするためです。

属性を考える際は、その値が何を表すか、いつ確定するか、誰が更新するかを意識します。

また、同じ名前でも意味が異なる情報を混同しないことが重要です。

たとえば商品名と注文時商品名は似ていますが、前者は商品マスターの現在の名称であり、後者は購入時点の名称として扱うことがあります。

このように、エンティティは名詞で捉え、属性はその名詞の特徴として考えると分類しやすくなります。

E-R図を作成する目的

E-R図を作成する大きな目的は、業務上必要なデータを整理し、保存方法の誤りを減らすことです。

システムが扱う情報は、画面や帳票からだけでは全体をつかみにくい場合があります。

たとえば予約管理システムでは、利用者、施設、予約、支払い、取消といった複数の情報が関わります。これらを図に並べると、予約がどの利用者と施設に結び付くかを確認できます。

E-R図を使うと、必要な情報、重複している情報、未定義の関係を見つけやすくなります。

開発者だけでなく、業務を知る担当者にも図を見せることで、実際の運用と設計の差を検討できます。

たとえば一つの注文に複数の配送先を指定できるのか、キャンセル済みの注文を削除するのか残すのか、といった判断材料になります。

図は完成品ではなく、要件が固まる過程で更新するものです。

最初から細部まで正確に描こうとするより、主要なエンティティと関係を先に置き、確認しながら育てる方が進めやすいでしょう。

構成要素と記号の読み取り方

続いてはE-R図で使われる構成要素と記号を確認していきます。

エンティティを表す枠と識別子

E-R図では、エンティティを四角形や枠で表す書き方がよく使われます。

枠の中には顧客や注文のような名称を書き、必要に応じて属性を並べます。

識別子は、同じ種類のデータの中から一件を確実に特定するための属性です。

顧客番号や注文番号のように、重複しない値を持つ項目が代表例です。

実際のデータベースでは、識別子が主キーとして設定されることが多くあります。

氏名だけでは同姓同名の利用者を区別できず、メールアドレスも変更される可能性があります。そのため、業務上の管理番号やシステム内部の番号を識別子として設ける考え方が有効です。

識別子には、自然に存在する値を使う方法と、システムで番号を発行する方法があります。

会員番号のような人工的な番号は変更されにくい反面、利用者には意味が分かりにくいことがあります。

図を見るときは、どの属性が識別子なのかを最初に確認すると、関係の流れを追いやすくなります。

リレーションシップと関係線

リレーションシップは、エンティティ同士の業務上の結び付きを示す要素です。

顧客と注文の間には、顧客が注文するという関係があります。

表記方法はツールや記法で異なり、ひし形に関係名を書く形式や、二つの枠を線で直接つなぐ形式があります。

重要なのは形そのものではなく、線が何を意味するのかを関係者全員で同じように読めることです。

たとえば商品と注文を単純に結ぶだけでは、注文内の商品ごとの数量や購入時価格を保存しにくくなります。そこで注文詳細というエンティティを間に置き、注文と商品をそれぞれ結び付ける設計がよく採用されます。

関係線は、単に関連があることではなく、どのデータがどのデータに依存するかを考える手掛かりになります。

関係名を付ける場合は、注文する、含む、所属するなど、業務の動作が分かる言葉を選ぶと読みやすくなります。

ただし、実装上の外部キーの名前と図上の関係名を無理に一致させる必要はありません。

業務の意味を表す図と、実装の都合を表す列名は、目的に応じて区別するとよいでしょう。

カーディナリティの表し方

カーディナリティは、エンティティ同士が何件ずつ結び付くかを示す考え方です。

代表的な関係には、一対一、一対多、多対多があります。

顧客一人が複数の注文を出せる場合、顧客と注文は一対多です。一件の注文は通常一人の顧客に属するため、逆方向から見ると多対一になります。

一対一は、利用者と利用者設定のように、分割して管理する理由がある場合に使われます。

多対多は、学生と授業、商品と注文のように、双方が複数の相手と結び付く関係です。

関係の種類	意味	身近な例	設計時の考え方
一対一	双方が最大一件ずつ結び付く	利用者、利用者設定	分割理由と必須性を確認する
一対多	片方一件に対してもう片方が複数件結び付く	顧客、注文	多い側に関連する識別子を持たせる
多対一	複数件が一件に結び付く	注文、顧客	一対多を逆向きに見た関係
多対多	双方が複数件ずつ結び付く	注文、商品	中間となるエンティティを検討する

カーディナリティを間違えると、後から必要になった複数登録に対応できないことがあります。

最初に業務ルールを確認し、将来の可能性ではなく、現時点で実際に必要な関係を根拠に決めることが大切です。

関係の種類とデータベースへの落とし込み

続いては関係の種類をデータベースに反映する考え方を確認していきます。

一対多の関係と外部キー

一対多の関係は、業務システムで最もよく見られる関係の一つです。

顧客一人が複数の注文を持つ例では、注文側に顧客を示す情報を持たせます。

一対多の関係では、通常は多い側のテーブルに一つ側を参照する外部キーを置きます。

外部キーは、別のテーブルにある識別子を参照するための項目です。

注文テーブルに顧客番号を保存すれば、各注文がどの顧客のものかを判別できます。

この形なら、一人の顧客について注文履歴を検索したり、一件の注文から注文者を調べたりできます。

外部キーとして保存する値は、表示名ではなく安定した識別子を選ぶことが基本です。

また、顧客が退会したときに注文データをどう扱うかも、関係を設計する段階で検討します。

過去の取引記録を残す必要があるなら、顧客データを単純に削除できない場合があります。

多対多の関係と中間テーブル

多対多の関係は、そのまま二つのテーブルだけで表そうとすると扱いにくくなります。

注文は複数の商品を含められ、同じ商品は複数の注文に含まれます。

この場合、注文と商品の間に注文詳細という中間テーブルを置く設計が一般的です。

多対多の関係は、中間テーブルを介して二つの一対多の関係に分けて考えます。

注文詳細には、注文番号と商品番号に加え、数量、購入時単価、値引き額などを保存できます。

これらは注文そのものでも商品そのものでもなく、その組み合わせに関する情報です。

テーブル	主な役割	代表的な項目	関係
注文	購入全体を管理する	注文番号、顧客番号、注文日	注文詳細を複数持つ
商品	販売対象を管理する	商品番号、商品名、標準価格	注文詳細を複数持つ
注文詳細	注文内の商品ごとの内容を管理する	注文番号、商品番号、数量、購入時単価	注文と商品を結び付ける

中間テーブルを使うと、一回の注文で同じ商品を何個買ったかを自然に記録できます。

注文番号と商品番号の組み合わせだけを識別子にするか、注文詳細番号を別に設けるかは、更新や参照の方法を踏まえて決めます。

必須と任意の関係

関係を考える際は、件数だけでなく、結び付きが必須か任意かも確認します。

たとえば注文は必ず顧客に属する仕様なら、注文から顧客への関係は必須です。

一方、顧客は会員登録した直後には注文を持たないため、顧客から注文への関係は任意になります。

この違いを整理しておくと、入力チェックや削除処理の方針が決めやすくなります。

たとえば配送先が未確定の仮注文を保存できるなら、配送先との関係は登録時点では任意かもしれません。

ただし、出荷処理を開始する時点では配送先が必須になるため、処理の段階ごとに条件が変わることもあります。

E-R図では基本的な存在条件を明確にし、より細かな状態遷移は別の仕様書で補うと整理しやすいでしょう。

E-R図の作成手順と設計上の注意点

続いてはE-R図を作成する手順と設計上の注意点を確認していきます。

業務からエンティティを洗い出す手順

E-R図を作るときは、最初に業務の流れを文章や会話から拾い上げます。

注文を受ける、商品を出荷する、請求を確定する、といった業務を確認すると、そこに登場する名詞が見えてきます。

名詞を候補として集めた後に、独立して管理すべき情報かを判断すると、エンティティを整理しやすくなります。

顧客、商品、注文、請求書は独立して管理しやすい候補です。

一方で、注文日や数量は単独で存在する対象ではないため、属性として扱うことが多いでしょう。

この段階では、名称の揺れにも注意が必要です。

会員、ユーザー、顧客が同じ対象を指すのか、利用目的によって別の対象なのかを確認しないと、重複したエンティティが生まれます。

業務用語集を作り、名称と意味を一文で定義しておくと、図の更新時にも迷いにくくなります。

重複と更新漏れを防ぐ考え方

設計では、同じ事実を複数の場所に保存しないことが重要です。

商品マスターの標準価格を注文のたびにコピーすると、価格改定時にどの値を更新すべきかが分かりにくくなります。

ただし、注文時の販売価格は取引記録として必要になるため、注文詳細に保存する合理性があります。

重複を避けるべきかどうかは、同じ意味の現在値か、それとも時点を含む記録かで判断します。

顧客の現在住所と、購入時点の配送先住所は、見た目が似ていても意味が異なります。

前者は顧客情報として更新され、後者は過去の配送事実として保持されることがあります。

確認する観点	見直しが必要な例	考え方
同じ事実の保存先	顧客名を複数のマスターに保存する	正しい保存元を一つ決める
時点の違い	現在価格と購入時価格を混同する	現在値と履歴を分ける
繰り返し項目	商品名を商品一、商品二のように並べる	明細エンティティを検討する
未確定情報	空欄の理由が複数ある	任意関係や状態を確認する

重複を完全になくすことだけを目的にすると、履歴や検索性能に必要な情報まで失うおそれがあります。

業務上の意味を説明できるかどうかを基準に、保存場所を決めることが大切です。

レビューで確認したい項目

E-R図は作成者だけで確認せず、業務担当者や開発担当者と一緒にレビューすると精度が上がります。

レビューでは、まず各エンティティが実際の業務に存在する対象かを確認します。

次に、識別子が重複なく決まり、登録後に不用意に変わらないかを見ます。

関係については、一件の顧客が注文を何件まで持てるか、一件の注文に商品が何件含まれるかを具体例で質問すると理解しやすくなります。

関係の正しさは、実際にあり得る一件のデータを想定して確認することが有効です。

たとえば定期購入の注文、複数配送先を持つ注文、返品された商品など、通常と異なるケースも検討します。

例外をすべて図に盛り込む必要はありませんが、基本設計を壊す例外がないかは確認すべきです。

名称については、図を初めて見る人が意味を推測できるかも大切な観点になります。

略語を多用するより、業務で使われる言葉を選び、必要なら補足資料に定義を残すとよいでしょう。

E-R図の意味と関係のまとめ

E-R図は、データベースで扱う対象と、それぞれの関係を視覚的に整理するための設計図です。

エンティティは顧客や注文のような管理対象であり、属性はその対象を説明する情報です。

リレーションシップとカーディナリティを確認すると、データが何件ずつ結び付くかを読み取れます。

一対多では多い側に外部キーを置き、多対多では中間テーブルを使って関係を分ける考え方が基本になります。

また、必須か任意かを整理すると、登録や更新の条件を仕様に反映しやすくなります。

作成時は業務から名詞と動詞を洗い出し、重複する現在値と履歴として残す値を区別することが重要です。

図を完成品として固定せず、具体的なデータ例を使って関係者とレビューすると、実務に合った設計へ近づけられます。

まずは身近な注文や予約の流れを題材に、小さなE-R図を一つ描いてみてください。