大規模なシステム開発において必要不可欠なER図ですが、いまいち理解できていない人も多いのではないでしょうか？
そこでこの記事では、データベース設計に欠かせないER図の書き方を解説します。
また、書き方に入る前の知識として、ER図の記法や要素、記号についても解説したので、初心者の方でもしっかりと基本が理解できる内容になっています。ぜひ最後までご覧ください。
ER図とは
ER図とは「Entity Relationship Diagram」の略で、「データベース設計（データモデリング）で使う設計手法」のことです。「Entity（エンティティ） = モノ」の「Realationship（リレーション） = 関係」を表した図のことを指します。データベースを使うシステム設計では、ER図なしにはデータベースを構築できません。ER図は「エンティティ」、「アトリビュート」、「リレーションシップ」、「カーディナリティ」と呼ばれるオブジェクトで構成されます。それぞれ後ほど解説します。
ER図のデータモデル
ER図は、システムの上流工程で段階的に設計し、各工程で作成するER図の状態を「データモデル」と呼びます。データモデルには、「概念モデル」「論理モデル」「物理モデル」があり、違いは以下の通りです。
概念モデル
https://data.wingarc.com/entity-relationship-diagram-62781
要件定義工程で作成する最初のデータモデルです。処理に必要なエンティティを洗い出し、処理の流れやデータのつながりをER図で表します。
論理モデル
https://data.wingarc.com/entity-relationship-diagram-62781
基本設計工程で作成するデータモデルで、概念モデルに肉付けをして作成します。エンティティの持つ属性や主キー、外部キーを定義し、エンティティ間のリレーションを設定します。データベースを設計するために必要なエンティティの要素やエンティティ間の関連性が明確になり、基本情報が整理できます。
物理モデル
https://data.wingarc.com/entity-relationship-diagram-62781
詳細設計工程で作成するデータモデルで、ER図の最終段階になります。Oracle Databaseなど特定の物理データベースでの実装を想定し、情報を付け足します。データ型などを定義することで、データモデルを基に物理データベースを作成可能です。
ER図の表記方法
ER図の表記方法にはいくつかの種類があり、現在主流となっているのが「IE記法」と「IDEF1X記法」の2つです。この2つの表記方法の違いは、リレーションの書き方だけで、表現していることは同じです。 早速見てみましょう。
IE記法
IE記法は、リレーションに鳥の足のような3本に分かれた記号を用いるため、「鳥の足記法（Crow’s Foot Notation）」とも呼ばれます。その他にも円や線を用いているのが特徴です。IDEF1X記法と比べると、直感的に理解しやすいです。
IDEF1X記法
「IDEF1X記法」は、リレーションシップの向き先を黒丸（●）で記載します。より細かく表現できますが、IE記法に比べると複雑になり、直感的には理解が難しくなります。
ER図の基本ルールや用語
用語は分かれていますが、感覚的に理解しやすいので「こういう違いがあるんだ！」と、全体像を頭の中で理解できれば問題ありません。 ECサイトのシステムを想定して解説していきます。
概念モデル
手順にも出てきますが、まず最初にシステム全体の「モノ」や「コト」を「エンティティ」と「リレーションシップ」として洗い出し、概要を表します。この2つを「概念モデル」と言います。
エンティティ（概念モデル）
https://products.sint.co.jp/ober/blog/create-er-diagram#:~:text=ER%E5%9B%B3%E3%81%AE%E8%A1%A8%E8%A8%98%E6%B3%95
まずはじめにエンティティを定義します。システムに登場する「モノ」をエンティティとして洗いだし設定します。「ショップ」や「商品」、「顧客」などがエンティティです。
リソース（マスタ系）エンティティ
マスターテーブルとして管理されるデータです。システム上では、基本的に参照（SELECT）される事が多く、更新（INSERT/UPDATE）される事が少ない場合が多いです。
例）社員、顧客、店舗、商品
イベントエンティティ
動詞の名前が多くつけられます。ここでは例示したほうがわかりやすいと思います。例えば、顧客が商品を注文する場合、「顧客」「商品」というマスタ系のエンティティ同士を結びつける「注文」がイベント系エンティティとなります。 例）その他にも受注、注文、出荷、売上、請求、入金といったイベントがこのエンティティとなります。
サマリーエンティティ
リソース（マスタ系）とイベント系エンティティの集計結果のエンティティです。バッチ処理などで計算させてデータを格納することも多いです。 例）商品の売上集計、カテゴリー別の売上集計など
エンティティの書き方
独立エンティティ（他のテーブルのデータに依存することなくデータを保持できるエンティティ）を角の尖った四角で示し、従属エンティティ（他のテーブルが存在しないとデータを保持することができないエンティティ）を角の丸い四角で示すことがありますが、区別しないことも多いです。
概念モデルの書き方
概念モデルでは、エンティティとリレーションシップを定義して作成します。システム全体をモデル化して表し、システムの事象を大まかに分類することで、処理の大きな流れを表現できます。
エンティティ
https://products.sint.co.jp/ober/blog/create-er-diagram#:~:text=ER%E5%9B%B3%E3%81%AE%E8%A1%A8%E8%A8%98%E6%B3%95
データベースに必要な「モノ」をエンティティとして定義します。例えば「ショップ」や「商品」、「顧客」などがエンティティにあたります。必ずしも物理的に存在するものではなく、「入金」などの行為も対象です。エンティティは、四角の中に名称を書くことで定義します。エンティティには2種類あり、以下の通りです。
リソースエンティティ
リソースエンティティとは、システムの基本データを管理するエンティティです。「ショップ」や「商品」、「顧客」などがリソースエンティティにあたります。最終的にはマスタテーブルとなる基本情報です。
イベントエンティティ
イベントエンティティでは、システムの業務データを管理します。例えば「受注」や「出荷」、「入金」などです。イベントエンティティは、最終的にはトランザクションテーブルになります。
リレーションシップ
https://products.sint.co.jp/ober/blog/create-er-diagram#:~:text=ER%E5%9B%B3%E3%81%AE%E8%A1%A8%E8%A8%98%E6%B3%95
エンティティを書き出したら、エンティティ間で関連性のあるエンティティ同士をリレーションシップ（関連線）で繋ぎます。
主語となるエンティティを「親エンティティ」、目的語となるエンティティを「子エンティティ」と呼びます。
例） 顧客が 商品を 注文する リレーションは1本の線で関係の有無だけを表し、「主語」から「目的語」に向かって線を引きます。
依存リレーションシップ
依存リレーションシップは、お互いのエンティティが存在しないとシステムとして成り立たない関係を指します。この関係は「実線」で結びます。例えば「商品」と商品を置く「ショップ」は、どちらかが欠けるとシステムとして成り立ちません。
非依存リレーションシップ
逆にエンティティ同士が独立していても成り立つ関係を非依存リレーションシップと呼びます。この関係は「点線」で結びます。例えば「商品」と「顧客」は、顧客がいなくても商品は存在しているため、非依存の関係が成り立ちます。
論理モデルの書き方
https://products.sint.co.jp/ober/blog/create-er-diagram#:~:text=ER%E5%9B%B3%E3%81%AE%E8%A1%A8%E8%A8%98%E6%B3%95
論理モデルは、作成した概念モデルにより詳細に肉付けをしていきます。「アトリビュート（属性）」や「カーディナリティ（多重度）」を付け加えることで詳細化できます。以下で解説していきます。
アトリビュート（属性）とは
下の図をご覧ください。アトリビュートとは「エンティティ内の各属性（項目）」のことを指します。
例）顧客マスターの場合、「顧客コード」や「顧客名」、「住所」など
アトリビュートを追加する際は、アイデンティファイア、外部キー、カーディナリティを定義する必要があります。
https://products.sint.co.jp/ober/blog/create-er-diagram#:~:text=ER%E5%9B%B3%E3%81%AE%E8%A1%A8%E8%A8%98%E6%B3%95
アイデンティファイア
アイデンティファイア（identifier）とは、エンティティのレコードを識別子とするアトリビュート（属性）です。顧客マスターでは、顧客を特定するために「顧客コード」が必要になるので、「顧客コード」をアイデンティファイアにします。四角の中に線を引き、線の上にアイデンティファイアを記載して設定します。
外部キー
エンティティ間にリレーションシップが設定されている場合は、子エンティティに親エンティティのアイデンティファイアを追加する必要があります。これは「外部キー」と呼ばれ、アトリビュート名の後に（ＦＫ）を付けます。エンティティ間が依存リレーションシップの場合、外部キーもアイデンティファイアとします。
カーディナリティ（多重度）
https://products.sint.co.jp/ober/blog/create-er-diagram#:~:text=ER%E5%9B%B3%E3%81%AE%E8%A1%A8%E8%A8%98%E6%B3%95
カーディナリティとは、リレーションシップで繋がっているエンティティの数（レコード）の関係を指します。「1対1」や「1対多」、「多対多」などがあり、顧客と商品のエンティティ間のカーディナリティは「多対多」です。
記号のルール
カーディナリティを表す時にリレーションシップの始点と終点に記号を追加します。カーディナリティの記号は、IE記法とIDEF1X記法で異なります。また、カーディナリティの結果がリレーションシップと異なる場合、カーディナリティに合わせてリレーションシップを修正します。
IDEF1X表記の場合
https://envader.plus/article/48
IDEF1X記法は、主にアルファベット記号を使ってカーディナリティを表現します。「顧客」、「商品」エンティティ間のカーディナリティは「多対多」のため、「P」を使って表します。
IE表記の場合
IE記法では、カーディナリティに0を含むかを区別する「オプショナリティ」を使う場合があります。これにより「0以上」や「0または1」を表現できます。IE記法は、白丸（○）や鳥の足を使うことで、カーディナリティを表します。
ER図の書き方手順6ステップ
前段が長くなりましたが、上記の理解があれば問題なくER図の作成ができるようになります。ER図は簡単6ステップで作成できます。ステップ1から順番に見ていきましょう。
1.システムシナリオを確認する
具体的に「誰が何をどうするのか（ユースケース）」がわからないと、どのデータベースを用いて、データをどのように関連付けるのかわかりません。そのために、要件定義でのユースケースの洗い出しを一番最初に行う必要があります。
例）顧客が商品を注文する、顧客が商品をお気に入りリストに追加するなど 要件定義について詳しく知りたい場合は、こちらの記事を参考にしてください。
ユースケース図の例
https://www.ntt.com/business/sdpf/knowledge/archive_50.html
ユースケース記述の例
https://www.ntt.com/business/sdpf/knowledge/archive_50.html
2. エンティティを洗い出す
手順1. で準備したユースケースを用いて、必要なエンティティを洗い出します。その際、リソースエンティティとイベント系エンティティを分けておくと後々可動性も上がりますので、おすすめです。
例）顧客（マスタ）、商品（マスタ）、注文、配送方法（マスタ）、在庫、決済方法（マスタ）
ユースケース図からのエンティティ洗い出し
まずユースケース図からエンティティを洗い出していきます。ユースケース図を見ると、ECサイトを利用する「顧客」と、ECサイト上の「商品」と「注文」がエンティティにあたることがわかります。
ユースケース記述からのエンティティ洗い出し
ユースケース記述からは、基本フローにあるように、「お届け先」、「請求先」、「配送方法」、「決済方法」がエンティティになります。ユースケースの図や記述があると、エンティティの洗い出しが簡単になります。
3.エンティティをマスタ系とトランザクション系に分ける
https://www.ntt.com/business/sdpf/knowledge/archive_50.html
アトリビュートを洗い出す前に、エンティティをマスタ系とトランザクション系に分けます。整理することによって、上図の「お届け先」、「請求先」、「配送方法」、「決済方法」はトランザクションとして1つのエンティティになります。
4. アトリビュート（属性）を洗い出す
各エンティティのアトリビュート（属性）を洗い出します。アトリビュート（属性）は、画面設計書を参考に項目を洗い出すと簡単です。
5. エンティティ同士をつなげる
エンティティ同士をリレーションとカーディナリティなどの記号を用いて繋げます。「1対1」や「1対多」、「多対多」などは業務シナリオによって異なるため、注意が必要です。
6. 見やすく整頓する
以下の項目をチェックし、作成したER図をより読みやすいものにしていきます。データベース設計の段階に進むために見やすく整頓するのは重要なので、是非参考にしてみてください。
親エンティティは左上にかく
親エンティティは左上から書き始め、子エンティティを右に、さらに孫エンティティを右にと並べていきます。同じ親を持つエンティティは上下に並べることでツリー構造になり、親子関係が明確になります。
サブシステムごとにER図を分ける
大規模システム開発の場合、エンティティが多すぎて画面内に収めるのが難しい場合も。無理に一画面におさめてしまうと膨大な量のエンティティを把握しづらくなってしまいます。
https://products.sint.co.jp/ober/blog/create-er-diagram#:~:text=ER%E5%9B%B3%E3%81%AE%E8%A1%A8%E8%A8%98%E6%B3%95
そんなときは、サブシステムごとにER図を分けるなど、ルールを決めてグループ分けをしましょう。
またはエンティティの種類で色分けをします。
手順1. では同時にこの作業をしてます。色分けをすることによって、ER図の各エンティティの役割を直感的に把握しやすくなります。
https://products.sint.co.jp/ober/blog/create-er-diagram#:~:text=ER%E5%9B%B3%E3%81%AE%E8%A1%A8%E8%A8%98%E6%B3%95
ER図作成ツール
ここからはER図を作成できる無料ツールをご紹介します。ツールを使うことで、さらに効率よくER図作成を進めらるのでおすすめです。ご紹介するおすすめ無料ツールは以下の3つです。
A5:SQL Mk2
A5:SQL Mk2は、無料で使えるツールの1つで、高性能にデータベース設計を行えます。ER図の作成はもちろん、テーブル設計やそのほかの設計にも役立ちます。設計が完了したら、DDLとして出力もできるため、業務効率化を図れます。
ER MASTER
ER MASTERも同じく無料で使えるデータベース設計ツールです。Eclipseにアドオンして使用するため、普段からEclipseを使用している方におすすめです。逆にEclipseを使わない方は、A5:SQL Mk2を使うのが良いでしょう。
Cacoo
Cacooは、クラウド環境で使える無料の作図ツールです。ER図だけでなく、フローチャートやワイヤーフレームなどの図形を作成できます。テーブル定義の作成やDDL出力はできませんが、直感的に図の作成ができるので、ER図のみを作成する方におすすめです。
ER図の書き方まとめ
DB設計で必要不可欠なER図の書き方を解説しました。基本的な用語や記号、図の種類、書き方の手順や見やすくするためのコツなどをわかりやすく紹介しています。おすすめの無料ツールも紹介しているので、ぜひ本記事を参考に実際に作成してみてください。
ER図の書き方や進め方に関する質問や案件のご相談などがある場合は、株式会社Jiteraへお問い合わせください。
最後まで読んでいただき、ありがとうございました！
著作者：storyset／出典：Freepik
メールマガジン登録
