データベース設計に必須なER図の書き方とは？Excelでも書けるのか

ER図の書き方を覚えてデータベース設計に活かす

データベースを設計する際には、単純にテーブル設計書を作成するだけの方法や、場合によっては設計書なしでデータベースを構築することもあります。しかし、ER図を作成することで、設計ミスのリスクを減らし、工数を削減できるため、運用・保守フェーズでも非常に役立ちます。

テーブルの数が多くなれば設計ミスやプログラマーとの連携に問題が生じるリスクが増え、結果的に手戻りが増えてしまうため、現在ではデータベース設計においてはER図の作成はスタンダード化されています。

そこで、本記事ではER図の基本的な書き方をわかりやすく解説した上で、要件からER図に落とし込む際のシミュレーションを行い、効率的にER図を描画できるツールを紹介します。

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

ER図の作成はシステム開発における要件定義や設計などの上流工程に含まれ、段階的にシステムを設計します。また、ER図にはいくつかの表記法があり、代表的なのは「IE記法」と「IDEF1X記法」の2種類です。どちらかに優劣などはなく、好みやシーンによって使い分けます。

◼︎IE記法 リレーションが鳥の足に似ており、直感的に理解しやすい記法です。新人研修や未経験者にはIE記法がおすすめです。

◼︎IDEF1X記法 アメリカの国立標準技術研究所（NIST）で誕生した記法であり、リレーションを「●」などを用いて表します。より細かく表現する際におすすめです。

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

前述の通りER図はデータベース設計に欠かせない設計図であり、システム開発が完了した後の保守・運用工程においても活用できます。特にデータベースを扱うデータベースエンジニアには必須のスキルであり、作成することで設計の誤りを防いで手戻りをなくせます。

また、転職市場においても求めるスキルの中にER図の作成が含まれているケースがあるため、今後のためにも書き方を覚えておいて損はないでしょう。データベースエンジニアはこういったスキル1つ1つを増やすことで、年収額が変動しやすい職種です。

例えば、「マイナビエージェント 職種図鑑」でのデータベースエンジニアの平均年収は424万円（※2024年9月執筆時点）ですが、経済産業省2017年発表の「IT関連産業の給与等に関する実態調査結果」から近い職種のIT技術スペシャリスト（特定技術(DB・NW・セキュリティ等））を参考にすると、平均年収758万円でした。

年収幅は424万円〜758万円と幅広く、勤める企業やスキルの高さに影響されると考えられます。さらに、国税庁2020年発表の「民間給与実態統計調査」における民間企業の平均年収は433万円なので、若手のエンジニアでも平均年収よりやや高めを目指しやすい職種と言えるでしょう。

【参考】：マイナビエージェント 職種図鑑/データベースエンジニア ※【平均年収 調査対象者】2020年1月～2020年12月末までの間にマイナビエージェントサービスにご登録頂いた方 【参考】：IT関連産業における給与水準の実態① ~ 職種別（P7） 【参考】：民間給与実態統計調査-国税庁

ER図の基本構成

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

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

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

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

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

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

「『会員』が『商品』を購入する」といったように、エンティティを主語/目的語として文章が成立する場合、エンティティ間にはリレーションが存在します。

この場合の主語となるエンティティを「親エンティティ」、目的語となるエンティティを「子エンティティ」と呼び、ER図では親から子に向かって線が引かれます。

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

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

ER図の書き方ガイド

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

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

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

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

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

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

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

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

以下では「会員」「商品」「注文」の3つのエンティティを考えます。

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

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

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

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

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

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

一方で、会員エンティティと商品エンティティの間には関連性がなく、それぞれ独立して存在できます。

エンティティ間の多重度を考えましょう。1人の会員が複数回注文を行うことは当然考えられます。また1人の会員が1度も注文を行っておらず、関連する注文情報を持たないことも考えられます。

このことから、会員エンティティと注文エンティティの間には「1対0、または1対多」の多重度があると言えます。商品エンティティと注文エンティティの間においても、同様です。

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

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

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

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

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

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

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

また他にも、Googleスプレッドシートで見ると図形の表示が崩れる場合があったり、バージョン管理しづらかったりといった点で不都合な点があります。

プロジェクト内でさらに効率の良いER図管理を行いたい場合は、各種ツールの導入をおすすめします。次項からはおすすめのツールを紹介します。

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

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

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

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

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

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

ER図の作成ツールおすすめ8選！データ構造をわかりやすくしよう

要件に沿った分かりやすいER図を書いて効率的に開発しよう

本記事では、ER図の基本的な書き方を紹介し、練習として実際にER図を作成するシミュレーションを行いました。実際の現場ではさらに複雑なデータ構成を持つER図を作成しなければいけません。

また、1度作ったドキュメントは、開発が終わって保守・運用のフェーズになっても管理し続けることが必要です。本記事を参考にして、見やすい・管理のしやすいER図を作成し、データベースエンジニアとしてのスキルを高めましょう。

転職市場ではスキル1つ1つの高さが自身の市場価値を高め、転職活動が有利に働きやすくなります。その際、転職に強い転職エージェントを活用することをおすすめします。

そこでぜひご活用いただきたいのがマイナビIT エージェントです。

マイナビIT エージェントは、IT・Webエンジニア向けの無料の転職⽀援サービスです。

IT・Webエンジニアの転職事情に詳しいキャリアアドバイザーが、あなたのご経験やスキルをお伺いし、転職活動のプランをご提案致します。

アドバイザーは企業側の人事担当者と直接連携を取れますので、求人票に載っていない企業情報も確認することができます。残業時間や給与面など、働き方などをしっかり確認の上で応募企業を選んでいくのが良いでしょう。

・資格やプログラミングの勉強をしているけれど、企業が求めるレベルに達しているのかわからない ・スキルアップをして市場価値を上げていける企業の選び方を知りたい ・数多くあるITエンジニアの職種の中で、自分に向いている仕事は何か知りたい

こうした悩みを抱えていらっしゃる方は、まずは無料登録でキャリアカウンセリングをおすすめ致します。