ER図とは?

ER図とは、データベース設計工程におけるアウトプットとして代表的なものです。「ER」とは「Entity Relationship」の略であり、ER図を見るだけでシステムが扱うデータ構造やその関連性などがわかるようになっています。

本記事ではER図の基本的な書き方をわかりやすく解説した上で、要件からER図に落とし込む際のシミュレーションを行い、効率的にER図を描画できるツールを紹介します。もしあなたがデータベース設計を任された時は、ぜひ本記事を参考にしてください。

ER図とは？詳細・メリット・作成方法についてわかりやすく解説！　

ER図の基本構成

書き方を解説する前に、ER図を書くために必要な前提知識を押さえましょう。これから説明する4つの要素は、データベース設計工程でメンバーとコミュニケーションするために必須の知識です。

「Entity Relationship」の名前が表すように、ER図はエンティティがなければ始まりません。エンティティとは、構築したいシステムが処理する「モノ」や「コト」に名前を付けて現し、定義したものです。データベース設計においては、テーブルとして管理することが多いです。

我々がよく使うECサイトを例にすれば、「会員」「会員登録」「商品」「注文」などがエンティティに相当します。

エンティティが持つ情報を更に細分化したものがアトリビュートです。属性とも呼ばれます。データベース設計においては、テーブルが持つカラムとして管理することが多いです。

例えば上記で挙げた「商品」情報を例にすると、「商品名」「価格」「注文番号」「購入日時」などに相当します。より詳細な商品情報を管理したいなら、「寸法」「重さ」「商品画像」といった情報も必要です。

その名の通り、リレーションはエンティティ同士の関係性を表します。エンティティ間に関連性がある場合、ER図上では線や矢印を引いて表されます。

「『会員』が『商品』を購入する」といったように、エンティティを主語/目的語として文章が成立する場合、エンティティ間にはリレーションが存在します。この場合の主語となるエンティティを「親エンティティ」、目的語となるエンティティを「子エンティティ」と呼び、ER図では親から子に向かって線が引かれます。

多重度とも呼ばれる概念です。1つのエンティティに対して、リレーションを持つ他のエンティティがいくつ存在しうるかを表します。主な多重度の表現として「1対1」「1対多」「多対1」「多対多」が挙げられます。

上記の例で「商品」と「注文」にはリレーションがあります。1つの商品に対して複数の注文が考えられるので、商品エンティティと注文エンティティは1対多の多重度を持ちます。

実例に倣って、ER図を書いてみましょう

ここまでER図を書くための基本知識を紹介しました。ここからは、ER図作成に慣れていない方のために、一緒に簡単なER図を書く練習をします。

「知識として知っている」と「一度やったことがある」の違いは大きいです。現場で一目置かれるエンジニアになるために、是非自分で手を動かしてER図を作ってください。

データベース設計には必須！ER図の書き方を分かりやすく解説します

ER図を書くにあたって一番大事なことは、システムの要件をよく理解することです。あらかじめ、ユーザがどのようにこのシステムを使うのか、ユーザはこのシステムを使って何ができるようになるのかを開発メンバー間で共有しましょう。

今回は簡単な例として、下記の要件を定義します。この要件を満たすようなデータベース設計の一環として、ER図が必要になった場合を想定します。

要件 ・商品注文画面を用いて、ログイン済みの会員が商品を注文できる ・商品注文画面では、商品の名前、画像、価格を確認できる ・注文直後、会員にメールが送信され、会員は注文内容を確認できる ・会員は自身の注文履歴を画面で確認できる

ユーザーの行動フロー ①商品注文画面を表示し、配送先情報を入力する ②注文ボタンを押下する ③受信したメールにより、注文内容を確認する

本来のECサイトであれば、「会員登録ができる」「商品をカートに入れた後、一括で注文できる」「注文時に決済方法を指定できる」「商品レビューを投稿できる」などが要件として考えられますが、例を簡単にするため今回は省略しています。

要件を確認したら、文章からエンティティを洗い出しましょう。今回のシステムで管理したいデータは「会員」「注文」「商品」「配送先」辺りが考えられます。配送先に関しては注文ごとに異なると考えて、注文のエンティティに含めて問題はなさそうです。以下では「会員」「商品」「注文」の3つのエンティティを考えます。

エンティティが持つアトリビュートを整理します。要件定義に基づいて、それぞれのエンティティに必要そうなアトリビュートを考えます。今回は省略しますが、実務では画面設計を元にアトリビュートを洗い出すことが有効であることが多いです。

会員エンティティ 注文後にメールを送信する要件があるので、属性として「メールアドレス」は必要でしょう。他には基本情報として「名前」の情報も持っているとメールの宛名等に有効活用できます。

注文エンティティ 注文履歴画面に会員の注文履歴を表示するには、注文エンティティからその注文を「誰が」行ったのかを確認できる必要があります。同様に、「何を」注文したかの情報も必要です。

商品エンティティ ユーザーが商品注文画面で確認できる内容から、「商品名」「画像」「価格」が必要です。以上から、アトリビュート定義は以下のようになります。

注文の情報として「誰が」「何を」購入したか管理するために、「会員ID」「商品ID」というアトリビュートを注文エンティティに定義します。これらの値はデータベース設計では各テーブルの主キー（Primary Key）と呼ばれ、テーブル内のレコードを一意に特定するための値です。PKとも略されます。

これまで定義してきた3つのエンティティ間のリレーション有無を考えます。会員エンティティと注文エンティティ、商品エンティティと注文エンティティの間には、それぞれ会員ID及び商品IDを通じた関連性があります。一方で、会員エンティティと商品エンティティの間には関連性がなく、それぞれ独立して存在できます。

エンティティ間の多重度を考えましょう。1人の会員が複数回注文を行うことは当然考えられます。また1人の会員が一度も注文を行っておらず、関連する注文情報を持たないことも考えられます。このことから、会員エンティティと注文エンティティの間には「1対0、または1対多」の多重度があると言えます。商品エンティティと注文エンティティの間においても、同様です。

以上を踏まえると、ER図はこのようになります。

上記では多重度の書き方に「IE記法」を用いています。これは「○」「縦線」「鳥の足」の3つを組み合わせてカーディナリティを表す記法です。

以上で、ER図を書くことができました。本来の設計工程では、このER図を元にテーブルが作成され、主キー、外部キーの設定が行われます。

ER図はツールを用いることで効率よく書ける

「書き方は理解した。実践もした。さあ要件を見直して、ER図を作ろう！」と思ったあなたへ、もう一点だけ気にして欲しいことがあります。「一体どんなツールを使って描けばいいの？」ということです。

エンジニア、非エンジニアに関わらず、仕事で使用するPCにExcelが入っている方は多いと思います。実は特別なツールがなくても、Excelで描画できる図形だけを用いてER図は書けます。今すぐにでもER図を描き始めないと納期に間に合わない方には、Excelで描き始めるという手もあります。

しかし、ExcelでER図を作成するとわかってきますが、Excelで描画できる図形がER図を作るのに最適化されていないため、一度書いたものを修正するのに大きな工数がかかります。

また他にも

・Googleスプレッドシートで見ると図形の表示が崩れる場合がある ・バージョン管理しづらい

といった点で不都合な点があります。

プロジェクト内で更に効率の良いER図管理を行いたい方は、各種ツールの導入をおすすめします。以下におすすめのツールを紹介します。

LucidChartはクラウドベースのツールで、インストールなしで利用できます。シンプルなUIのため誰でも使いやすいです。ER図だけでなくPERT図・インフラ構成図などの作成も可能なため、LucidChartだけで数種類の開発ドキュメントを作成できます。

また、Google・Atrassian・Slackなどの外部サービスとの連携が可能で、メンバーで共有する際に便利です。活用例としては、ER図をGoogleドライブ上でメンバーと共同で作成したり、ER図を見ながらSlackでチャットをしたりすることができます。

【参考】クラウドベースER図作成ツール | Lucidchart

Cacooは、ER図といった開発ドキュメントをメンバーと共有する機能が豊富なツールです。複数のメンバーがリアルタイムでER図を作成する・コメントをつける・編集履歴を確認するなどの機能があり、チームで情報共有することに優れています。

また100種類以上のテンプレートが用意されているため、ER図を作成するのが苦手な人でも簡単にわかりやすいER図を作成できます。

【参考】フローチャートやワイヤーフレーム、プレゼン資料まで作れる | Cacoo(カクー)

要件に沿った分かりやすいER図を書いて、効率的な開発のお供に！

本記事では、ER図の基本的な書き方を紹介したあとに、練習として実際にER図を作成するシミュレーションを行いました。

実際の現場では更に複雑なデータ構成を持つER図を作成しなければいけません。また1度作ったドキュメントは、開発が終わって保守〜運用のフェーズになっても管理し続けることが必要です。本記事を参考にして、是非見やすい・管理のしやすいER図を作成してください。