システム開発や業務改善の現場では、「顧客情報と注文情報はどうつながるのか」「社員と部門の関係はどう整理すればよいのか」「同じ情報を複数の場所で管理していないか」といった問題がよく起こります。
たとえば、顧客管理、受注管理、在庫管理、社員管理、研修管理など、ほとんどの業務システムでは多くのデータを扱います。しかし、データ同士の関係が整理されていないと、重複登録、入力ミス、集計ミス、データ不整合、システム改修時の混乱が起きやすくなります。
そこで役立つのが、ER図です。
ER図は、データベース設計でよく使われるフレームワークです。難しそうに聞こえるかもしれませんが、初心者はまず「データ同士の関係を見える化する図」と理解すれば十分です。
ER図を使うと、顧客、商品、注文、社員、部門、申請、承認履歴など、業務で扱う情報がどのようにつながっているかを整理できます。システム開発だけでなく、Excel管理の見直し、業務データ整理、DX推進、データ活用の前提づくりにも役立ちます。
この記事でわかること
・ER図とは何か
・ER図は何に使うのか
・ER図の基本的な考え方
・ER図の使い方
・ER図の具体例
・関連フレームワークとの違い
最初から完璧に使いこなす必要はありません。まずは「ER図はデータ同士の関係を整理するための型だ」とつかめれば十分です。
ER図とは？
ER図とは、Entity Relationship Diagramの略で、データ同士の関係を図で表したものです。
日本語では「実体関連図」と呼ばれることもあります。
ER図では、業務やシステムで扱う情報を「エンティティ」として整理し、それぞれのエンティティ同士がどのような関係にあるかを表します。
たとえば、受注管理システムであれば、次のような情報があります。
・顧客
・商品
・注文
・注文明細
・請求
・配送
これらはバラバラに存在しているわけではありません。
顧客は注文をします。注文には複数の商品が含まれます。商品は注文明細に記録されます。注文に対して請求や配送が発生します。
このようなデータ同士の関係を図で整理するのがER図です。
初心者向けに言い換えると、ER図は「業務で扱う情報のつながりを整理する設計図」です。
システムでは、データを正しく管理することが非常に重要です。ER図を使うことで、どの情報をどの単位で持つべきか、どの情報同士を結びつけるべきかを考えやすくなります。
一言でいうと、ER図はデータ構造とデータ同士の関係を整理するためのフレームワークです。
ER図は何に使うのか
ER図は、主にデータベース設計や業務データ整理に使います。
主な用途は次のとおりです。
・データベースの構造を設計する
・業務で扱う情報を整理する
・データ同士の関係を見える化する
・重複データや不整合を減らす
・システム開発の要件定義に活用する
・既存システムのデータ構造を理解する
・Excel管理をデータベース化する前に整理する
・帳票や画面に必要なデータの関係を確認する
・システム改修時の影響範囲を把握する
・データ分析やBI活用の前提を整える
たとえば、社内研修管理システムを作る場合、受講者、研修、申込、出席、アンケート結果といったデータがあります。
ER図を使うと、「1人の受講者は複数の研修に申し込める」「1つの研修には複数の受講者がいる」「申込ごとに出席結果やアンケート結果が紐づく」といった関係を整理できます。
この整理がないままシステムを作ると、受講履歴が正しく追えない、同じ社員が重複登録される、研修ごとの集計ができないといった問題が起きやすくなります。
どんな人に向いているか
ER図は、次のような人に向いています。
・システム開発や要件定義に関わる人
・業務システムの導入を検討している人
・データベース設計を学びたい人
・Excel管理をシステム化したい人
・業務データを整理したい人
・データ分析やBI活用の前提を作りたい人
・既存システムのデータ構造を理解したい人
・外部ベンダーにシステム開発を依頼する人
・DX推進や業務改善を担当している人
・プロジェクトマネージャーや業務担当者
ER図は、エンジニアだけが使うものと思われがちです。しかし、業務担当者にとっても非常に役立ちます。
なぜなら、業務担当者は「業務で何の情報を扱っているか」を最もよく知っているからです。
たとえば、営業部門なら顧客、案件、商談履歴、見積、受注といった情報の関係を理解しています。人事部門なら社員、部署、異動、評価、研修、資格といった情報の関係を理解しています。
ER図の基本を知っておくと、IT部門や外部ベンダーに対して、業務データの関係を説明しやすくなります。
ER図の基本的な考え方
ER図の基本は、エンティティ、属性、リレーションの3つです。
初心者は、まずこの3つを押さえれば十分です。
・エンティティ
・属性
・リレーション
エンティティ
エンティティとは、業務で管理したい情報のまとまりです。
たとえば、次のようなものがエンティティになります。
・顧客
・商品
・注文
・社員
・部門
・申請
・請求
・研修
・問い合わせ
エンティティは、データベースでいうとテーブルに近い考え方です。
初心者向けに言えば、エンティティは「管理したいものの種類」です。
たとえば、顧客管理であれば「顧客」がエンティティになります。在庫管理であれば「商品」や「在庫」がエンティティになります。研修管理であれば「社員」「研修」「申込」などがエンティティになります。
属性
属性とは、エンティティが持つ具体的な項目です。
たとえば、「顧客」というエンティティには、次のような属性があります。
・顧客ID
・顧客名
・住所
・電話番号
・メールアドレス
・担当営業
・登録日
「商品」というエンティティであれば、次のような属性があります。
・商品ID
・商品名
・カテゴリ
・価格
・在庫数
・販売開始日
初心者向けに言えば、属性は「その情報について記録しておきたい項目」です。
属性を整理することで、画面に表示する項目、入力フォームに必要な項目、帳票やレポートに使う項目が見えやすくなります。
リレーション
リレーションとは、エンティティ同士の関係です。
たとえば、次のような関係があります。
・顧客は注文をする
・注文には注文明細がある
・商品は注文明細に含まれる
・社員は部門に所属する
・社員は研修に申し込む
・申請には承認履歴がある
ER図では、この関係を線で表します。
リレーションで重要なのは、「1対1」「1対多」「多対多」といった関係の種類です。
たとえば、1人の顧客は複数の注文をすることがあります。この場合、顧客と注文は「1対多」の関係です。
一方、1つの研修には複数の社員が参加し、1人の社員も複数の研修に参加できます。この場合、社員と研修は「多対多」の関係です。ただし、実際のデータベース設計では、申込という中間エンティティを使って整理することが多いです。
主キーと外部キー
ER図を理解するうえで、主キーと外部キーも重要です。
主キーとは、データを一意に識別するための項目です。
たとえば、顧客であれば顧客ID、商品であれば商品ID、社員であれば社員番号が主キーになります。
外部キーとは、別のエンティティと関連づけるための項目です。
たとえば、注文データに顧客IDを持たせることで、その注文がどの顧客の注文なのかを紐づけられます。
初心者は、主キーを「そのデータを見分ける番号」、外部キーを「別のデータとつなぐための番号」と考えると理解しやすいです。
ER図の使い方
手順1 対象となる業務やシステムを決める
まず、ER図で整理する対象を決めます。
最初から会社全体のデータ構造を描こうとすると、範囲が広すぎて整理できません。まずは、1つの業務や1つのシステムに絞るのがおすすめです。
たとえば、次のような単位で考えます。
・顧客管理
・受注管理
・在庫管理
・社内申請
・研修管理
・問い合わせ管理
・経費精算
・社員情報管理
・商品マスタ管理
・契約管理
対象範囲を決めるときは、「何を実現したいのか」もあわせて考えます。
たとえば、研修管理であれば、研修の申込だけを管理したいのか、出席結果やアンケート結果、受講履歴まで管理したいのかによって、必要なエンティティが変わります。
手順2 管理したい情報を洗い出す
次に、業務で管理したい情報を洗い出します。
いきなりER図を描こうとせず、まずは箇条書きで書き出すと整理しやすくなります。
たとえば、受注管理なら次のような情報があります。
・顧客
・商品
・注文
・注文明細
・在庫
・請求
・配送
社内申請なら、次のような情報があります。
・社員
・部門
・申請
・申請種別
・承認ルート
・承認履歴
・添付ファイル
ここで大切なのは、「画面に表示される項目」だけでなく、「業務として管理すべき情報のまとまり」を考えることです。
たとえば、注文画面に商品名や顧客名が表示されていても、それらを注文データの中に直接すべて持たせるとは限りません。顧客や商品を別のエンティティとして管理し、IDで紐づけることが多いです。
手順3 エンティティを決める
洗い出した情報の中から、エンティティを決めます。
エンティティにするかどうかの目安は、次のとおりです。
・業務上、独立して管理したい情報か
・複数件のデータが発生するか
・他の情報と関連づける必要があるか
・履歴として残す必要があるか
・検索や集計の対象になるか
たとえば、受注管理であれば、顧客、商品、注文、注文明細はエンティティとして扱うことが多いです。
一方で、顧客名や商品名はエンティティではなく、顧客や商品の属性として扱います。
初心者は、最初にエンティティを決めるときに迷うことがあります。その場合は、「これは一覧として管理したいものか」「複数件存在するものか」と考えると判断しやすくなります。
手順4 属性を整理する
エンティティを決めたら、それぞれの属性を整理します。
たとえば、顧客エンティティには次のような属性があります。
・顧客ID
・顧客名
・住所
・電話番号
・メールアドレス
・担当者名
・登録日
注文エンティティには次のような属性があります。
・注文ID
・顧客ID
・注文日
・注文ステータス
・合計金額
注文明細エンティティには次のような属性があります。
・注文明細ID
・注文ID
・商品ID
・数量
・単価
・小計
属性を整理するときは、重複に注意します。
たとえば、注文データの中に顧客住所を毎回保存すると、顧客住所が変更されたときにどのデータを修正すべきか難しくなります。一方で、請求書発行時点の住所を履歴として残したい場合は、あえて注文や請求に住所情報を持たせる設計もあります。
このように、属性は業務目的に応じて整理する必要があります。
手順5 エンティティ同士の関係を整理する
次に、エンティティ同士の関係を整理します。
代表的な関係は、次の3つです。
・1対1
・1対多
・多対多
たとえば、顧客と注文の関係は、一般的には1対多です。
1人の顧客は複数の注文をすることがあります。一方、1つの注文は基本的に1人の顧客に紐づきます。
注文と注文明細の関係も1対多です。
1つの注文には複数の注文明細があります。一方、1つの注文明細は1つの注文に紐づきます。
商品と注文明細の関係も1対多です。
1つの商品は複数の注文明細に登場します。一方、1つの注文明細は1つの商品を表します。
このように、エンティティ同士の関係を考えることで、データ構造が見えてきます。
手順6 主キーと外部キーを設定する
関係が整理できたら、主キーと外部キーを考えます。
主キーは、そのエンティティのデータを一意に識別する項目です。
たとえば、次のようになります。
・顧客：顧客ID
・商品：商品ID
・注文：注文ID
・注文明細：注文明細ID
・社員：社員ID
・研修：研修ID
外部キーは、別のエンティティとつなぐための項目です。
たとえば、注文エンティティには顧客IDを持たせます。これにより、注文がどの顧客のものかを表せます。
注文明細エンティティには、注文IDと商品IDを持たせます。これにより、どの注文に含まれる明細で、どの商品を指しているのかがわかります。
主キーと外部キーを整理すると、データ同士のつながりが明確になります。
手順7 業務ルールと照らし合わせて確認する
最後に、作成したER図を業務ルールと照らし合わせて確認します。
確認する観点は次のとおりです。
・必要なデータが抜けていないか
・同じ情報を重複して持ちすぎていないか
・データ同士の関係は業務実態と合っているか
・1対多や多対多の関係に誤りはないか
・履歴として残すべき情報を残せるか
・削除してはいけないデータが考慮されているか
・集計や検索に必要な項目があるか
・将来の拡張に対応できるか
・個人情報や機密情報の管理に問題はないか
ER図は、データベース設計だけでなく、業務ルールの確認にも役立ちます。
たとえば、「社員は必ず1つの部門に所属するのか」「兼務があるのか」「過去の所属履歴を残すのか」によって、データ構造は変わります。
このように、ER図は業務の考え方をデータ構造として表すものでもあります。
ER図の具体例
例 受注管理システムの場合
受注管理システムを例に考えてみます。
このシステムでは、顧客から注文を受け、商品を出荷し、請求を行います。
主なエンティティは次のとおりです。
・顧客
・商品
・注文
・注文明細
・請求
・配送
顧客エンティティには、次のような属性があります。
・顧客ID
・顧客名
・住所
・電話番号
・メールアドレス
商品エンティティには、次のような属性があります。
・商品ID
・商品名
・カテゴリ
・単価
・販売状態
注文エンティティには、次のような属性があります。
・注文ID
・顧客ID
・注文日
・注文ステータス
・合計金額
注文明細エンティティには、次のような属性があります。
・注文明細ID
・注文ID
・商品ID
・数量
・単価
・小計
この場合、関係は次のように整理できます。
・1人の顧客は複数の注文をする
・1つの注文は1人の顧客に紐づく
・1つの注文には複数の注文明細がある
・1つの注文明細は1つの商品に紐づく
・1つの商品は複数の注文明細に登場する
・1つの注文に対して請求が発生する
・1つの注文に対して配送が発生する
このように整理すると、注文情報の中に商品名を何度も直接書き込むのではなく、商品IDで商品データとつなぐことができます。
また、顧客別の注文履歴、商品別の売上、注文ごとの請求状況なども集計しやすくなります。
別の例 社内研修管理システムの場合
次に、社内研修管理システムを例に考えます。
このシステムでは、社員が研修に申し込み、出席し、受講後にアンケートへ回答します。
主なエンティティは次のとおりです。
・社員
・部門
・研修
・研修申込
・出席記録
・アンケート回答
社員エンティティには、次のような属性があります。
・社員ID
・社員名
・メールアドレス
・部門ID
・役職
部門エンティティには、次のような属性があります。
・部門ID
・部門名
・部門長ID
研修エンティティには、次のような属性があります。
・研修ID
・研修名
・開催日
・講師名
・定員
・対象者
研修申込エンティティには、次のような属性があります。
・申込ID
・社員ID
・研修ID
・申込日
・申込ステータス
この場合、社員と研修は多対多の関係です。
1人の社員は複数の研修に申し込むことができます。また、1つの研修には複数の社員が申し込むことができます。
この多対多の関係をそのまま扱うのではなく、「研修申込」という中間エンティティを置くことで整理しやすくなります。
関係は次のようになります。
・1つの部門には複数の社員が所属する
・1人の社員は1つの部門に所属する
・1人の社員は複数の研修申込を行う
・1つの研修には複数の研修申込がある
・1つの研修申込に対して出席記録が作られる
・1つの研修申込に対してアンケート回答が紐づく
このようにER図で整理すると、誰がどの研修を受けたのか、出席したのか、アンケートに回答したのかを追跡しやすくなります。
また、部門別の受講状況、研修別の参加率、社員ごとの受講履歴なども分析しやすくなります。
具体例でわかるポイント
具体例から学べるポイントは次のとおりです。
・ER図はデータ同士の関係を整理するために使える
・顧客、商品、注文などの情報を分けて管理できる
・重複データを減らしやすい
・1対多や多対多の関係を整理できる
・多対多の関係は中間エンティティで整理することが多い
・集計や検索に必要なデータ構造を考えやすい
・業務ルールがデータ構造に反映される
・システム開発前の認識合わせに役立つ
ER図は、システムの裏側にあるデータの骨組みを考えるための道具です。
ER図を使うメリット
ER図を使うメリットは、データ構造を見える化し、関係者の認識を合わせやすくなることです。
主なメリットは次のとおりです。
・データ同士の関係を整理できる
・重複データや不整合を減らしやすい
・データベース設計の土台になる
・システム開発の要件定義に活用できる
・画面や帳票に必要なデータを確認できる
・集計や分析に使いやすいデータ構造を考えられる
・既存システムの構造理解に役立つ
・システム改修時の影響範囲を把握しやすい
・外部ベンダーに仕様を説明しやすくなる
・業務データの標準化につながる
特に大きなメリットは、データの重複や不整合を減らしやすいことです。
たとえば、顧客名や住所を注文データ、請求データ、配送データにそれぞれバラバラに入力していると、更新漏れや表記ゆれが起きます。ER図を使って顧客情報を一元管理し、注文や請求と紐づける設計にすれば、データ管理が安定します。
また、データ分析やBI活用を行う場合にも、ER図は重要です。
分析したい指標があっても、データ構造が整理されていなければ、正しく集計できません。ER図でデータの関係を把握しておくと、売上分析、顧客分析、研修効果分析、在庫分析などに活用しやすくなります。
ER図を使うときの注意点
ER図は便利ですが、使い方を間違えると、実務に合わないデータ構造になってしまいます。
よくある失敗例は次のとおりです。
・業務を理解しないままデータ構造を決める
・画面項目だけを見てエンティティを作る
・同じ情報を複数のエンティティに重複して持たせる
・1対多や多対多の関係を誤って理解する
・履歴管理の必要性を見落とす
・削除してはいけないデータを削除できる設計にする
・将来の拡張性を考えずに設計する
・主キーや外部キーの考え方が曖昧になる
・業務担当者に確認せずに設計を進める
・専門的すぎて関係者が理解できない図になる
特に注意したいのは、業務ルールを確認することです。
たとえば、「社員は1つの部門に所属する」と考えて設計した後に、実際には兼務や出向があるとわかると、データ構造を見直す必要があります。
また、「顧客の住所は常に最新だけ見られればよい」のか、「注文時点の住所を履歴として残す必要がある」のかによっても設計が変わります。
ER図は、単なる技術的な図ではありません。業務のルールや考え方をデータ構造に落とし込むものです。そのため、業務担当者と確認しながら作ることが重要です。
関連フレームワークとの違い
ER図と関連するフレームワークには、DFD、CRUDマトリクス、UML、BPMN、要件定義フレームなどがあります。それぞれ目的が異なります。
DFDとの違い
DFDは、データがどこから来て、どこで処理され、どこへ出ていくのかを整理する図です。
ER図は、データ同士の関係やデータ構造を整理する図です。
DFDが「データの流れ」を見るものだとすれば、ER図は「データの構造」を見るものです。
たとえば、DFDでは「注文情報が顧客から入り、注文受付プロセスを通じて注文データベースに保存される」といった流れを整理します。
ER図では、「顧客と注文は1対多の関係」「注文と注文明細は1対多の関係」といった構造を整理します。
CRUDマトリクスとの違い
CRUDマトリクスは、データに対して作成、参照、更新、削除のどの操作が必要かを整理する表です。
ER図は、データ同士の関係を整理する図です。
ER図で「どのデータが存在し、どう関係するか」を整理し、CRUDマトリクスで「誰がそのデータに何をするか」を確認すると、システム設計の精度が上がります。
UMLとの違い
UMLは、システムの構造や動きを複数の図で表現するための記法です。
UMLのクラス図は、ER図と似たようにデータや概念の関係を表すことがあります。ただし、UMLはオブジェクト指向設計を含む幅広いシステム設計に使われます。
ER図は、特にデータベース設計やデータ構造の整理に向いています。
初心者向けに言えば、UMLはシステム全体を多面的に表す道具で、ER図はデータベースの構造を整理する道具です。
BPMNとの違い
BPMNは、業務プロセスの流れを図で整理するための記法です。
ER図は、業務で扱うデータ同士の関係を整理するための図です。
BPMNが「誰が、どの順番で、何をするか」を表すのに対して、ER図は「どの情報が、どの情報と関係しているか」を表します。
業務改善では、BPMNで業務の流れを整理し、ER図でデータ構造を整理すると、全体像が見えやすくなります。
要件定義フレームとの違い
要件定義フレームは、業務要件、機能要件、非機能要件を整理するための考え方です。
ER図は、要件定義で整理された内容をもとに、データ構造を具体化する場面で役立ちます。
たとえば、「顧客ごとの注文履歴を確認したい」という要件がある場合、顧客、注文、注文明細、商品といったエンティティの関係をER図で整理します。
要件定義フレームが「何を実現するか」を整理するものだとすれば、ER図は「そのためにどのようなデータ構造が必要か」を整理するものです。
ER図はどんな場面で使うと効果的か
ER図は、次のような場面で使うと効果的です。
・新しい業務システムを設計するとき
・データベース設計を行うとき
・Excel管理をシステム化するとき
・既存システムのデータ構造を理解するとき
・システム改修の影響範囲を確認するとき
・データ分析やBI活用の前提を整理するとき
・複数システムのデータ連携を考えるとき
・顧客管理や受注管理を見直すとき
・社員情報や研修履歴を整理するとき
・外部ベンダーにデータ構造を説明するとき
特に、複数のデータが複雑に関係する業務ではER図が有効です。
たとえば、顧客、商品、注文、請求、配送、在庫が関係する受注業務では、データ構造を整理せずにシステムを作ると、後から修正が難しくなります。
また、DX推進やデータ活用を進める場合にも、ER図は重要です。
データを活用したいと思っても、データの関係が整理されていなければ、正しい分析ができません。まずはER図でデータ構造を把握することが、データ活用の土台になります。
まとめ
ER図とは、業務やシステムで扱うデータ同士の関係を整理するためのフレームワークです。
Entity Relationship Diagramの略で、日本語では実体関連図とも呼ばれます。
ER図では、エンティティ、属性、リレーションを使って、データ構造を整理します。エンティティは管理したい情報のまとまり、属性はその情報が持つ項目、リレーションはエンティティ同士の関係です。
ER図を使うと、データの重複や不整合を減らし、システム開発やデータベース設計の土台を作ることができます。また、業務データの整理、Excel管理の見直し、データ分析、BI活用、システム改修にも役立ちます。
大切なのは、ER図を技術者だけのものと考えないことです。業務データの関係を最もよく知っているのは、実際に業務を行っている担当者です。
まずは、自分の業務で扱っている「顧客」「商品」「注文」「社員」「研修」「申請」などの情報を洗い出し、それぞれがどのようにつながっているかを書き出すところから始めてみましょう。
次に読みたい関連記事
まず全体像を見たい方へ
仕事で使えるフレームワーク一覧｜初心者向けに意味・種類・使い方をわかりやすく解説
あわせて読みたい関連記事
DFDとは？初心者向けに意味・使い方・具体例をやさしく解説
CRUDマトリクスとは？初心者向けに意味・使い方・具体例をやさしく解説
TOGAFとは？初心者向けに意味・使い方・具体例をやさしく解説
目的別にまとめて読みたい方へ
IT・システム・業務設計で使うフレームワークまとめ｜初心者向けに種類・使い方・選び方をわかりやすく解説
