ER図の書き方を初心者向けに基本ルールからわかりやすく解説！

掲載日：2024/03/26

ER図はデータベース設計における基本ですが、エンジニア経験の浅い方は書き方や手順を正確に理解できていないことが少なくありません。また、若手のエンジニアもER図の書き方を人にわかりやすく説明するのは、難しいと感じるのではないでしょうか。本記事では、ER図の書き方やオブジェクトについて詳しく解説します。ぜひ最後までお読みいただき、ER図を正しく理解し業務に活かしていただければと思います。

ER図とは

ER図（Entity Relationship Diagram）は、データベース設計における重要なツールです。エンティティ（対象物）のリレーション（関係性）を図示して、データベースの構造が一目でわかるように可視化しています。

ER図は、エンティティやリレーションなど4つのオブジェクトで構成されています。データベースを用いるWebサイトやシステムでは、ER図の作成はほぼ必須です。これからシステム設計や開発プロジェクトに携わるエンジニアの方は、必ず習得するべき設計手法といえるでしょう。

ER図の主な種類

ER図の記法には複数の種類があります。しかし、全てを覚える必要はありません。現在主に使用されている「IE記法」と「IDEF1X記法」の2種類を覚えれば基本的には問題ありません。

この2つの記法は会社の方針やエンジニアの好みで使い分けられているため、しっかりと覚えておく必要があります。ここからは「IE記法」と「IDEF1X記法」の2つの記法について解説します。

IE記法

IE記法は、エンティティの関係性が直感的に把握しやすい記法です。IDEF1X記法よりもわかりやすい点から、初学者向けの研修などに用いられることも多いです。

IE記法では、カーディナリティの「0（ゼロ）」を「〇」、「1」を「｜」、「多」を「鳥の足に似た形状の記号」で表記します。「多」を表す記号の特徴から、「鳥の足記法」とも称されます。

IDEF1X記法

IDEF1X記法は、アメリカの国立標準技術研究所（NIST）で規格化された記法です。IE記法よりもエンティティの関係性を詳細に表現できるため、複雑なデータベース構造を持つシステム開発などに適しています。

IDEF1X記法では、カーディナリティに図形の「●」、「◇」や「P」、「Z」などのアルファベットを用いて「0」や「1」、「多」の関係性を表現します。

ER図のメリット

次にER図を作成するメリットを解説します。覚えることが多いER図ですが、システム設計にどのようなメリットがあるのかを理解しておくと、学習のモチベーションアップにつながります。 ER図のメリットは大きく次の2点です。
　● 全体感を把握し手戻りを防げる
　● 運用・保守段階で役に立つ
それぞれ詳しく解説します。

全体感を把握し手戻りを防げる

ER図を作成しておくと、データベースの全体像を一目で把握できます。複雑なデータベースを持つシステム設計においても誤りが少なくなるため、手戻りを防ぐことが可能です。

テーブル数が多いシステムや大規模なプロジェクトでは、設計ミスや開発チーム内で仕様の共有がうまくいかなくなり、手戻りが発生しやすいです。ER図を作成して、データベースの構造をチーム内で共有しておけば、手戻りを防げます。

運用・保守段階で役に立つ

ER図を作成しておくと、システム設計者が担当から外れた後の運用・保守段階で役立ちます。システム稼働直後にはシステム設計者が担当として残っていることが多く、ER図がなくても設計者がデータベース構造を記憶しているため、保守対応に問題はないでしょう。

しかし、別のプロジェクトへの異動など、設計者が担当を離れてしまうこともあります。次の担当者が保守やアップデートを行う際、設計内容を正しく理解できるように、ER図を作成しておくことは重要です。

ER図の書き方のルール

ここからはER図を書くにあたって基本的なルールを解説します。まずはER図の書き方において重要な、4つのオブジェクトについて理解しましょう。前段で紹介した「エンティティ」、「アトリビュート（属性）」、「リレーション」、「カーディナリティ（多重度）」について詳しく解説します。

エンティティ

エンティティとは、開発するシステムがテーブルとして保持するデータのまとまりです。書き方は四角形のエンティティの中に、アトリビュート（属性）を書いていきます。たとえば、ECサイトにおいては「顧客」や「注文」などが、エンティティとなります。

アトリビュート（属性）

アトリビュート（属性）とは、エンティティの属性情報です。データベース上では、テーブルが持つカラムとして管理される場合が多いです。

たとえば、「顧客」のエンティティでは、その中に格納されている顧客名や年齢、住所などの属性情報をアトリビュートとして記載します。また、アトリビュートでは主キーと外部キーについても表現します。

主キー（PK）

主キー（PK:Primary Key）とは、エンティティ内の情報の識別子として定めるものです。アイデンティティファイアとも呼ばれるもので、「顧客マスタ」では「顧客ID」が主キーにあたります。主キーを設定する際は重複せず、後から値の変更を行う必要がなく、できるだけ小さい値で設定しなければなりません。

たとえば、顧客ID「001」はAさん、「002」はBさんのように顧客IDから顧客が識別できるようにする必要があります。また、ER図において主キーは、エンティティ内に水平線を引き、その上部に記載します。

外部キー（FK）

外部キー（FK：Foreign Key）とは、別エンティティ内の主キーを参照する際に用いられるものです。サロゲートキーとも呼ばれ、外部キーは、エンティティ内で属性名の後ろに「（FK）」と記載します。

たとえば、「注文」エンティティにおいて「顧客ID」がなければ、誰の注文かわかりません。そのため、「注文」エンティティには「顧客」エンティティの主キーである「顧客ID」を外部キーとして用います。

リレーション

リレーションとは、エンティティの関係性を表現する線です。具体的な関係性は次に紹介するカーディナリティを用いて表します。

たとえば、「『顧客』が『注文』をする」のように、エンティティ間に主語・述語の関係性が成立する場合、両者には親子関係が生じます。この場合、主語にあたる「顧客」が親エンティティ、「注文」が子エンティティです。ER図では、親エンティティから子エンティティに向かってリレーションを記載します。

カーディナリティ（多重度）とは、リレーションで結ばれたエンティティの関係性を表現するための記号です。

リレーションの始点と終点に、関係性に応じて定められた記号を記載します。「1対1」、「1対多」、「多対多」、「1対0以上」などといったエンティティ同士の関係性を表します。

たとえば、「顧客」と購入される「商品」の関係は「多対多」です。顧客は複数の商品を購入する可能性があり、商品は複数の顧客から購入される可能性があるためです。

ER図の書き方4ステップ

ここからはER図の書き方を4ステップで解説します。
　　1. システムシナリオの確認
　　2. エンティティの洗い出し
　　3. アトリビュートの洗い出し
　　4. エンティティの関係整理とER図の作成
実際にER図を書くのは最後です。それまではシステム設計を大枠から行っていきます。最初からER図を書き始めるのではなく、どのようなデータ構造のシステムを開発するのか、少しずつ整理しながら進めていくことが大切です。各ステップについて順番に見ていきましょう。

システムシナリオの確認

ER図を書くには、最初にシステムシナリオを明確にすることが一番重要です。システムの用途やユーザーのどのようなニーズを満たすのかを、あらかじめ開発チームで共有する必要があります。

システムの方向性が決まったら、ユースケース図やユースケース記述、アクティビティ図を作成し、この内容を基にER図を作成していきます。

ユースケース図とは、システムの機能をユーザー目線で表現した図解です。これに対して、システムが実行する動作を文章で記述したものを、ユースケース記述といいます。

また、アクティビティ図とは、システムが実行される流れと条件分岐を図解にしたものです。

エンティティの洗い出し

次にエンティティを洗い出します。作成したユースケース図などを基に、データベースで管理すべきデータを考えます。

ユースケース図のアクターやサブジェクト、ユースケース記述に記載されたフロー、アクティビティ図のアクションなどから抜き出しが可能です。

たとえば、ECサイトの設計では「顧客」や「注文」などがエンティティとして挙げられます。システムシナリオの設計段階で正確にユースケース図などを作成しておくと、エンティティの洗い出しがスムーズに進められるため、しっかり作っておくようにしましょう。

エンティティを洗い出したら、マスターデータとトランザクションデータに振り分けます。マスターデータとは、基本となる情報で更新頻度が少ないデータです。顧客情報や商品情報はマスターデータに該当します。トランザクションデータは、頻繁に記録されるデータです。商品の注文情報や配送先などがトランザクションデータに該当します。

エンティティをマスターデータとトランザクションデータに振り分けておくと、それぞれテーブルを分けて管理ができるため、データ更新の負荷を軽減することが可能です。

アトリビュートの洗い出し

ここまでで洗い出したエンティティが持つ、アトリビュートを考えます。

ユースケース記述などを基にアトリビュートを考えてもよいですが、実務においては画面設計書や類似システムの画面を基にピックアップすると早いです。

たとえば、「顧客」エンティティには、名前や電話番号、メールアドレス、配送方法などのアトリビュートが必要です。ここで各エンティティのアトリビュートを整理してから次に進みます。

エンティティの関係整理とER図の作成

エンティティの関係性を整理し、リレーションと主キー・外部キーを盛り込んでER図を書きます。

たとえば、ECサイトにおける「顧客」と「商品」の情報は直接的な関連性はなく、それぞれ独立して存在可能です。反対に「顧客」と「注文」、「商品」と「注文」はそれぞれ顧客ID、商品IDが「注文」エンティティに外部キーとして必要となるため関連性があります。

また、1人の「顧客」が全く「注文」をしないことも、複数回「注文」をすることも想定されるため、「顧客」と「注文」のエンティティには「1対0」または「1対多」の関係性があります。これらの情報を整理してER図に落とし込みましょう。

まとめ│ER図を書いてみよう！

今回はER図の書き方をエンジニア初心者の方向けにわかりやすく解説しました。ER図はデータベース設計において重要な役割を果たすため、ぜひ覚えておいてほしい知識です。習得にあたっては、身近なシステムや自社製品などで何度も書く練習を行うのが効果的です。本記事を参考にしながら、ER図の書き方を身につけてエンジニアとしてのレベルアップを目指しましょう。