ER図とは？意味や書き方をわかりやすく解説【データベース】

ER図（エンティティ-リレーションシップ図）とはデータベースの構造を視覚的に表現するための図です。

この図は、データベース内の①エンティティ（実体）、②属性（特性）、③リレーションシップ（関係）を視覚的に表現し、データベースの全体像を理解しやすくするために役立ちます。

1. エンティティ（Entity）：データベースで管理したい実体（対象のデータ）。例：顧客、商品
2. 属性（Attribute）：エンティティが持つ特性（項目）。例：顧客ID、商品名
3. リレーションシップ（Relationship）: エンティティ間の関係。例：顧客が商品を購入する

このページではER図の意味や書き方の基本までを１からわかりやすく初心者向けに解説します。

プログラマーやシステムエンジニアを目指す方であれば、知らないと恥ずかしい超・基本知識の１つ。是非最後までご覧ください。

ER図（Entity-Relationship Diagram）とは？

ER図（エンティティ-リレーションシップ図）は、データベース設計や情報システム設計において非常に重要なツールの１つで、この図はデータや情報がどのように関連しているのか、どのように構造化されているのかを視覚的に表現します。

具体的には、ER図は以下のような要素で構成されます。

1. エンティティ（Entity）: データベースで管理したい「もの」や「事象」です。例えば、オンラインショップのシステムでは「顧客」や「商品」がエンティティになります。
2. 属性（Attribute）: エンティティが持つ「特性」や「詳細」です。例えば、「顧客」エンティティの属性は「名前」や「住所」、そして「商品」エンティティの属性は「商品名」や「価格」です。
3. リレーションシップ（Relationship）: ２つ以上のエンティティ間の「関係」を表します。例えば、顧客が商品を「購入する」というのがリレーションシップです。

ER図は上記のように、複雑なデータ関係を整理し、一目で理解できる形に落とし込む役割を果たします。特に大規模なシステムやプロジェクトでは、ER図がないと全体像が掴みにくく、設計ミスや後々のトラブルの原因となる可能性が高くなります。

そのため、システム開発時の初期段階でER図を適切かつ正確に作成しておくことは非常に重要です！

カーディナリティとは？

ER図においては、エンティティ間の関係性だけを示すのではなく、その「量」や「度合い」も重要です。この「量」や「度合い」を表すための概念がカーディナリティ（Cardinality）です。

もっとわかりやすく言えば「テーブルとテーブルの関係性＝どういう関連があるのか？」を示すもの。具体的に言えば、１：１の関係にあるのか、１：N（複数）　の関係にあるのか？

カーディナリティは、エンティティ間の関係がどの程度の「量」を持つのかを示し、以下のような種類があります。

主なカーディナリティの種類

1:1（１対１）の関係

具体例

人とパスポート：１人の人が１つのパスポートを持つ。

人（Person）

パスポート（Passport）

1:N（１対多）の関係

具体例

親と子：１人の親が複数の子を持つ。

親（Parent）

子（Child）

N:1（多対１）の関係

具体例

書籍と出版社：複数の書籍が１つの出版社から出版される。

書籍（Book）

出版社（Publisher）

N:M（多対多）の関係

具体例

学生と授業：１人の学生が複数の授業を受け、１つの授業には複数の学生が参加。

学生（Student）

授業（Class）

学生と授業の関連（Student_Class）

このようにして、カーディナリティはER図において非常に重要な要素となります。特に、データベースの設計段階でこれを明確にしておくことで、後々のトラブルを防ぐことができます。

ER図（エンティティ-リレーションシップ図）とは

• データベースや情報システムの設計ツールの１つ。
• データの構造や関係性を視覚的に表現。
• 主要な要素は「エンティティ」「属性」「リレーションシップ」。
• カーディナリティでエンティティ間の「量」や「度合い」を示す。
• 複雑なデータ関係を整理し、一目で理解できる形にする。
• 大規模なプロジェクトで設計ミスや後々のトラブルを防ぐ。

ER図の書き方

ここからはER図の書き方についてステップバイステップで解説しています！

ER図を書く際には、いくつかのステップと基本的なルールがあります。以下にその手順とポイントを解説します。

よりER図の作り方のイメージが湧きやすいように、ここでは図書館システム（書籍の貸出・返却、会員管理など）を例にしながらご説明していきます。

ステップ1: エンティティの特定

最初に何をモデル化するのかを明確にすることが重要です。目的が明確であれば、それに関連する「もの」や「事象」が自然と見えてくるはず。

1. 目的の明確化: 何のためにER図を作成するのかを明確にします。
2. エンティティのリストアップ: 目的に関連するエンティティをリストアップします。

ステップ2: 属性の特定

エンティティが何であるかを理解したら、次にそのエンティティが持つ「特性」や「詳細」を考えます。

1. エンティティごとに属性を考える: 各エンティティが持つ属性をリストアップします。
2. 属性の種類を考慮する: 属性には、テキスト、数値、日付など、さまざまな種類があります。

ステップ3: リレーションシップの特定

エンティティと属性が明確になったら、次はそれらがどのように関連しているのかを考えます。

1. エンティティ間の関係を考える: どのエンティティがどのエンティティとどのような関係にあるのかを考えます。
2. リレーションシップの名前をつける: 関係性には名前をつけ、それをダイヤモンド形で表現します。

ステップ4: カーディナリティの設定

エンティティ間の関係性だけでなく、その「量」や「度合い」も重要です。これを明確にするためにカーディナリティを設定します。

1. 関係の「量」や「度合い」を考える: １対１、１対N、N対１、N対Mなど、関係のカーディナリティを設定します。
2. ER図に表示する: カーディナリティは、リレーションシップの線の両端に数字や記号で表示します。

ステップ5: ER図の確認と調整

最後に、作成したER図が全体として矛盾していないか、また、目的に沿っているかを確認します。

1. 全体像を確認する: ER図全体を見て、矛盾や不足がないか確認します。
2. 関係者と共有する: ER図は関係者と共有し、フィードバックを受けて調整します。

以上がER図の基本的な書き方と手順です。このステップを踏むことで、網羅的かつ整理されたER図を作成することができます。

ちなみに、このようにER図を書きあげることで、どのようにテーブルを定義すれば良いか？が自明になってきます。

例えばこの図書館システムの例で言えば以下のようなテーブルを定義すればOKということが分かります。

-- 書籍テーブル
CREATE TABLE Books (
    book_id INT PRIMARY KEY AUTO_INCREMENT,
    title VARCHAR(255) NOT NULL,
    author VARCHAR(255) NOT NULL
);

-- 会員テーブル
CREATE TABLE Members (
    member_id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(255) NOT NULL,
    contact VARCHAR(255)
);

-- 貸出履歴テーブル
CREATE TABLE LendingHistory (
    lending_id INT PRIMARY KEY AUTO_INCREMENT,
    book_id INT,
    member_id INT,
    lending_date DATE,
    return_date DATE,
    FOREIGN KEY (book_id) REFERENCES Books(book_id),
    FOREIGN KEY (member_id) REFERENCES Members(member_id)
);

参考　CREATE TABLE文

補足：ER図について

ここまでの説明では、Excelの図形を用いたER図の例をお見せしてきました。

ですが、実はER図にはいくつかの決まった記法があります。（そして、今回お見せしたものは以下のどの記法にも沿っていません。）

1. Chen記法: エンティティを長方形、リレーションシップをダイヤモンド形、属性を楕円形で表現します。
2. Crow's Foot記法: エンティティを長方形で表現し、リレーションシップの線の端に「Crow's Foot（カラスの足）」マークをつけてカーディナリティを示します。
3. UML記法: クラス図に似た形で、エンティティとリレーションシップを表現します。
4. IDEF1X記法: 主に工業界で使用される記法で、エンティティ間の依存関係を強調します。

ただし、実際の現場では、これらの記法に厳密に従ったER図が用いられるわけではありません。その理由を以下に列挙しておきますが、大事なのは「データベース内の①エンティティ（実体）、②属性（特性）、③リレーションシップ（関係）を視覚的に表現し、データベースの全体像を理解しやすくする」ということ。この目的から外れなければ、どのような記法で図を記載しても問題ありません。

1. プロジェクトの規模: 小規模なプロジェクトでは、簡易的なER図で十分な場合が多い。
2. チームの経験: チームメンバーが既にデータベース設計に慣れている場合、細かい記法よりも大まかな構造がわかれば良いとされることが多い。
3. 時間とリソース: 細かい記法に従うことで、設計にかかる時間が長くなる可能性がある。
4. 可読性と理解: 重要なのは、関係者がER図を理解できるかどうかです。そのため、場合によっては独自の簡略化された記法が用いられることもある。

SQLやデータベースの仕組みを１から学習したい方（学び直したい方）向けに、現役エンジニア達のスキルを結集して 完全無料 のSQL教材を作成しました。

SQLは決して難しい技術ではないので、エンジニアであれば「当たり前のように」扱えて当然かも・・・？

とはいえ、案外SQLをちゃんと使ったことがない人も多いはずです。この機会に是非一度ご覧になってみてください。

【完全無料】SQL：初心者向け学習ロードマップ

SQL（Structured Query Language）：初心者向けにわかりやすく３０記事でSQLをマスターするための記事を整理。IT初心者でもこの記事を読めば必ずSQLを利用することができるようになります！

it-biz.online

2023.09.22