ER図とは?書き方や用語・テクニックを徹底解説

 2020.06.25  株式会社システムインテグレータ

最近ではPythonやRubyのフレームワークによりデータベースが自動で作られるようになったり、データベース自体がクラウドサービス化されたことでデータベースを意識しない開発も可能となりました。そのような背景から、ER図を知らない若手のエンジニアも増えているのではないでしょうか?

しかし、大規模なシステム開発においてはER図は必要不可欠です。そこで、これからはじめてER図を書くという方向けに、ER図の概要や書き方、テクニックなどについてご紹介します。

ER図とは

ER図(Entity Relationship Diagram)とはデータベース設計における代表的な設計図のことです。システムを設計する手法としては他にもUMLなどの技法がありますが、ER図はDOA(データ中心アプローチ)の技法であり、作成したER図がそのまま物理データベース上に変換できることから、データベース設計手法におけるデファクトスタンダードとなっています。

ER図のEはエンティティ(Entity)の略で、Rはリレーションシップ(Relationship)の略です。つまりER図は「エンティティ=モノ」と「リレーションシップ=関係」の組み合わせでシステムのデータやデータ間の処理構造を設計します。例として「顧客が商品を注文する」という処理をER図で表すと以下のようになります。

シンプルなER図

図1. ER図の例

「顧客」や「商品」がエンティティ、「注文する」がリレーションシップとなります。どのような大規模システムであっても、ER図ではエンティティとリレーションシップの組み合わせでシンプルにシステムが表現できることが特長となっています。

ER図を書くメリット

エンジニアの中には、「データベース設計においてはテーブル設計書だけ作る」、「設計を行わずデータベースを構築する」という方もいると思いますが、ER図を作ると以下のようなメリットがあります。

1.後戻りのコストを防ぐことができる

テーブル数が多くなればなるほど、設計ミスや、プログラマが仕様を理解できないリスクが増大し、後戻りによるコストが発生してしまいます。そのような大規模なシステムの場合は、ER図で整理することでシステム全体の構成が俯瞰でき、品質の高いデータベースおよびプログラム製造につなげることがでます。基幹業務システムのリプレイスなどの大規模案件においては、ER図の作成は必須と言えるでしょう。

2.運用・保守フェーズで役立つ

また、システムは一度構築すれば終わりではなく、長年稼働しながら改修を繰り返していきます。ER図は、そのようなシステムの運用・保守フェーズにおいても活用できます。稼働直後は当初の設計者が残っているので、設計ドキュメントがなくても何とかなるかもしれませんが、いつまでも設計者が残っているという保証はありません。ER図を残しておくことで、設計者以外の方でも設計内容を把握し、仕様変更などの改修に素早く対応できるようになります。

データベース開発に関するお役立ち資料

ER図のデータモデル

また、ER図はシステムの上流工程の中で段階的に設計します。各工程で作成するER図の状態のことを「データモデル」と呼びます。データモデルには「概念モデル」「論理モデル」「物理モデル」があります。各データモデルの違いは以下の通りです。

概念モデル

要件定義工程で作成するデータモデルです。最初にシステム全体における「もの」や「できごと」をエンティティ、リレーションシップとして洗い出し、概要を表したものとなります。

ER図の概念モデルの例

図2.概念モデル

論理モデル

基本設計工程で作成するデータモデルです。論理モデルでは概念モデルに対してさまざまな肉付けを行います。具体的には属性(アトリビュート)、アイデンティファイア(主キー)、外部キーの定義や、リレーションシップにカーディナリティといった要素を追加します。ただし、論理モデルではデータ型の定義などの物理データベース向けの設計は行いません。つまり、論理モデルは「特定のデータベースに依存しないレベルで具体化した状態」となります。

ER図の論理モデルの例

図3.論理モデル

物理モデル

詳細設計工程で作成するデータモデルです。Oracle Database等の特定の物理データベース向けに論理モデルの変換を行います。例えばデータ型を追加したり、物理データベースに即したアルファベットに変換します。ER図の最終形態がこの物理モデルとなります。物理モデル完成後は、その情報をもとに物理データベースを作成することができます。

ER図の物理モデルの例

図4.物理モデル

 

このようにER図では、段階的に考えながらデータベース設計ができることが特長となっています。

ER図の表記法

また、ER図にはいくつかの書き方(表記法)があります。代表的なのはIDEF1X(アイデフワンエックス、Integreation Definition 1Xの略)表記とIE(アイイー、Information Engineering)表記です。図5の左がIDEF1X、右がIE表記の例です。

ER図をIDEF1X表記(左)とIE表記(右)で書いた例

図5.IDEF1XとIE表記の例

この2つの違いはリレーションシップの書き方です。IDEF1Xはリレーションシップの向き先を黒丸(●)で書くのに比べ、IE表記ではリレーションの子エンティティ側が鳥の3本足のように書きます。(そのため、IE表記は別名「鳥の足表記法」とも呼ばれます。)また、論理モデル作成時に設定する「カーディナリティ」の書き方が異なりますが、こちらについては後述します。

概念モデルの書き方

ここからは各データモデルの作成方法を解説します。まず、概念モデルでは、システム全体をモデル化し、設計するシステムに求められる事象を大まかに分類します。概念モデルで定義するものはエンティティとリレーションシップとなります。

エンティティ

まずはじめにシステムに登場する「モノ」を洗い出し、エンティティとして定義しましょう。Eコマースサイトの場合ですと「ショップ」「商品」「商品カテゴリ」「顧客」などがエンティティとなります。エンティティは四角い箱を描き、その中に名前を書きます。

 

ER図のエンティティを列挙したもの図6.エンティティの例

 

エンティティには以下の2種類に分離されます。

リソースエンティティ

システム基本データを管理するエンティティとなります。Eコマースシステムの例では「ショップ」「顧客」「商品」などがリソースエンティティとなります。最終的にマスタテーブルとなるエンティティです。

イベントエンティティ

システムの業務データを管理するエンティティになります。Eコマースシステムの例では「受注」「出荷」「入金」などがイベントエンティティとなります。イベントエンティティには最終的にはトランザクションテーブルとなります。

リレーションシップ

エンティティの洗い出し後は、エンティティ間の関係を考え、関係あるエンティティ間にリレーションシップ(関連線)を引いていきます。例えば、ショップエンティティと商品エンティティの関係を考えると「ショップでは商品を置く(販売する)」という関係が成り立ちますので、これらのエンティティの間に線を引きます。リレーションを引いた場合はその関係の内容も記載します。これを動詞句と言います。今回はショップの中に商品を置くので「置く」と記述しています。

 

リレーションシップを追加したER図図7.エンティティにリレーションシップを追加したER図

 

リレーションシップには向きがあります。関連の「主語」から「目的語」に向かって線を引きます。上記例では「ショップは商品を置く」という関係となりますので、ショップ(主語)から商品(目的語)に向かって線を引きます。また、向きがわかるように向き先側には黒丸を描きます (IDEF1X表記の場合)。主語となるエンティティを「親エンティティ」、目的語となるエンティティを「子エンティティ」と呼びます。

また、リレーションシップには以下の種類があります。

依存リレーションシップ

リレーションシップを引いた両エンティティ間で依存関係が成立する場合のリレーションシップとなります。依存とは、「親エンティティのデータが存在しない場合、子エンティティのデータも存在できない」という意味です。図7の「ショップ」と「商品」を結ぶリレーションは依存関係が成立します。ショップが1つも登録されていない場合は商品を置くことはできないからです。(構築するシステムの仕様にもよりますが、一般的にはそのような仕様になることが多いです。)このような場合はが依存リレーションシップとなります。依存リレーションシップの場合は実線を引きます。また、子エンティティの枠を角丸の四角に変更します。

非依存リレーションシップ

上記のような依存関係にあたらないリレーションシップです。図7の「顧客」と「商品」を結ぶリレーションシップが非依存となっています。注文した顧客が1人もいないときでも商品自体は販売している(存在できる)ためです。非依存リレーションシップの場合は点線で引きます。

多対多リレーションシップ

依存関係が成立せず、かつカーディナリティが多対多の関係となるリレーションシップとなります。詳しくは後述の「カーディナリティ」でご説明します。

論理モデルの書き方

論理モデルは概念モデルで作成したエンティティ、リレーションに肉付けを行う作業となります。具体的には以下の項目を追加します。

アトリビュート(属性)

アトリビュート(属性)とは、エンティティ内で管理する具体的なデータ項目のことです。顧客エンティティであれば、「顧客名」「顧客コード」「顧客住所」「性別」などがアトリビュートとなります。図1にアトリビュートを追加した例が図8です。

 

アトリビュート追加後のER図図8.アトリビュート追加後のER図

また、アトリビュートを追加する上では以下についても定義する必要があります。

アイデンティファイア

エンティティのレコードを識別子となるアトリビュートを「アイデンティファイア(identifier)」と呼びます。顧客エンティティの例では「顧客コード」がアイデンティファイアとなります。顧客コードがわかれば、顧客を特定することができるためです。アイデンティファイアを設定する場合は、エンティティの中に水平線を引き、水平線の上に記載します。アイデンティファイアとならないアトリビュートは水平線の下に記載します。

外部キー

もし、リレーションシップが設定されている場合は、親エンティティのアイデンティファイアとなるアトリビュートを子エンティティにも追加する必要があります。これを「外部キー」と呼びます。外部キーの属性は属性名の後に(FK)と付けます。図8の例では商品エンティティにある「顧客コード」が外部キーとなります。依存リレーションシップで結ばれた子エンティティの場合は、外部キーもアイデンティファイアにし、水平線の上に追加します。非依存リレーションシップの場合は外部キーはアイデンティファイアとせず、水平線の下に追加します。

カーディナリティ(多重度)

カーディナリティとは、リレーションシップで結ばれた両エンティティの数(レコード)の関係のことで、別名「多重度」とも呼ばれます。カーディナリティにおいては「片方のエンティティ1レコードに対し、もう一方エンティティが何レコードになるのか」で考えます。図9の例では、1人の顧客は複数の商品を買うことがありますが、反対に、1つの商品が複数の顧客に買われることもあります。この場合のカーディナリティは「多対多」となります。他にも「1対多」、「1対多」などの関係があります。

 

カーディナリティ追加後のER図図9.カーディナリティを設定したER図

 

カーディナリティは、リレーションの線の始点と終点に次のルールで記号を追加します。

IDEF1X表記の場合

記号 意味
なし "1"を表します。
P 1以上を表します。
Z 0または1を表します。
n 定数nを表します。
n-m 範囲指定をした定数を表しています。(例:1-10)

IE表記の場合

記号 意味
"0"を表します。
l "1"を表しいます。
"鳥の足"で"多"を表します。

 

なお、カーディナリティの結果が「多対多」だった場合は、リレーションシップも多対多リレーションシップに変更します。図9も多対多となるため、多対多リレーションシップに変更しています。(また、動詞句もわかりやすく書き換えています。)多対多リレーションシップでは、両端を黒丸にします(IDEF1Xの場合)。

物理モデルの書き方

ER図の最終的なモデルが物理モデルとなります。物理モデルは、論理モデルをOracle Databaseなどの特定の物理データベース向けに変換したものとなります。具体的には以下の変更を行います。

仲介エンティティの追加

エンティティは、最終的には物理データベース(RDBMS)上のテーブルになりますが、多対多リレーションシップで結ばれたエンティティは、テーブルに変換することができません。2次元表となるテーブルでは「親であり子である」という関係のテーブルデータを表現できないためです。この場合は、「仲介エンティティ」というエンティティを設け、1対多の関係に変換します。図9に仲介エンティティを設けたER図が図10になります。

 

ER図に仲介エンティティを追加した例

図10.仲介エンティティを追加したER図

「注文」というエンティティが仲介エンティティとなっています。顧客、商品の間に追加し、さらに顧客、商品エンティティの子エンティティとして依存リレーションシップで結びなおしています。これにより、カーディナリティは1対多となり、顧客と商品が親、注文が子となるので、テーブルとして問題なく構築可能になります。

データ型の追加

また、属性ごとに適切なデータ型を設定します。Oracle Databaseであれば文字データを格納する場合は「CHAR」か「VARCHAR」、数値データであれば「NUMBER」、日付データであれば「DATE」になります。

エンティティ名、アトリビュートをアルファベットに変換

エンティティ名やアトリビュート名は論理モデルまではわかりやすい日本語にしていましたが、Oracle Database等の物理データベース上はアルファベットにするのが慣例です。そこで「顧客」を「EMP」、「顧客コード」を「EMP_CODE」など、アルファベットに変更します。

昔のバージョンのデータベースではマルチバイトのキャラクタでは誤動作を起こすことがあったことからアルファベットにするのが慣例となっていますが、今時はデータベースは日本語のマルチバイトで作成しても問題なく動作するため、この作業は必須ではありません。

 

図10のエンティティ名、アトリビュート名をアルファベットに変換し、データ型を追加したER図は図11の通りです。

ER図のアトリビュートをアルファベットに変換し、データ型を追加した例図11.物理名に変換およびデータ型を追加したER図

ER図から物理データベースを構築する方法

ER図の完成後は、物理データベースのスクリプト(DDL)を構築することができます。構築にあたってはER図と物理データベース項目の対応関係をおさえておく必要があります。代表的なER図の要素と物理データベース項目の関係は以下になります。

ER設計 物理データベース
エンティティ名 テーブル名
アトリビュート(物理名) カラム名
アイデンティファイア 主キー制約
リレーションシップ 外部キー制約

表2.ER図と物理データベースの関係

例として、図12のER図をもとに書いたスクリプトは図13の通りです。

ER図(物理モデル)

図12.ER図(物理モデル)

CREATE TABLE EMP
(
  EMP_CODE            VARCHAR2(10),
  EMP_NAME            VARCHAR2(50)
)
/
ALTER TABLE EMP
  ADD(CONSTRAINT PK_EMP PRIMARY KEY (EMP_CODE) USING INDEX)
/
CREATE TABLE COMMODITY
(
  COMMODITY_CODE         VARCHAR2(10),
  COMMODITY_NAME         VARCHAR2(100),
  PRICE                NUMBER(8,0)
)
/
ALTER TABLE COMMODITY
  ADD(CONSTRAINT PK_COMMODITY PRIMARY KEY (COMMODITY_CODE) USING INDEX)
/
CREATE TABLE PURCHACE
(
  EMP_CODE                VARCHAR2(10),
  COMMODITY_CODE        VARCHAR2(10)
  PURCHACE_NUM          NUMBER(3,0),
  PURCHACE_DATE          DATE,
)
/

図13.ER図をもとに生成したスクリプト

また、同様の変換ルールでER図から「テーブル定義書」などのドキュメントを作成することも可能です。

ER図を見やすくするテクニック

大規模なシステムなER図では、エンティティやリレーションシップの数が多くなりER図が見づらいという問題が出てきます。そのようなときに、ER図を見やすくする3つのテクニックをご紹介します。

親エンティティは左上から書く

すべてのエンティティと一番親となるエンティティを左に書き、子エンティティを右、孫エンティティをさらに右…というように書きます。同じ親をもつエンティティは上下に並べるようにすると、図14のようなツリー構造になり、親子関係が明確にわかり、リレーションシップも重ならなくなります。親エンティティを左上から書いたER図

図14.親エンティティを左から書いた例

ER図をサブシステムごとに分割する

大規模なシステムの場合はすべてのエンティティが一画面に入りきらなくなり、把握がしづらくなります。そのような場合はER図の分割を行います。分割する際は「商品系」「取引系」といった業務分類で分割する、ERPのシステムであれば「売掛」「買掛」などのサブシステム単位で分割するなどのルールを決めてグループ分けすると後で探しやすくなります。また、ExcelやVisioであれば1ファイルの中で別シートにして分割することができます。

全体のER図と、サブ機能ごとに分割したER図

図15.ER図をサブ機能ごとに分割した例

リソースエンティティとイベントエンティティで色分けする

エンティティには最終的にマスタ系のテーブルとなる「リソースエンティティ」とトランザクションを管理するテーブルとなる「イベントエンティティ」の2種類に分かれますが、これらを色分けしておくとデータと業務の関連がわかりやすくなります。リソースエンティティを緑、イベントエンティティを黄色で色分けした例が図16です。「顧客には請求と入金という業務がある」「入金口座マスタは入金業務でのみ使う」などの内容がすぐに把握できるようになります。イベントエンティティとリソースエンティティで色分けしたER図

図16.ER図をリソースエンティティとイベントエンティティで色分けした例

ER図作成ツールを活用する

ER図についてはExcelやVisioなどのアプリケーションで作成することも可能ですが、罫線や図形オブジェクトを使って作図するのは時間がかかります。昨今ではER図を作成する専用ツールが出ており、これらのツールを活用することで効率良くER図が作成できます。

当社でもER図作成ツール「SI Object Browser ER(以下、OBER)」というER図作成ツールを販売しています。OBERは以下の2つの特長によりER図を効率良く作成できるツールです。

ER図を効率よく作成できる 

簡単なマウス操作でエンティティやリレーションシップの配置が作図できます。概念モデル用のエンティティや、論理モデル、物理モデル用のアトリビュートをそれぞれ定義し、データモデルの表示切り替えが可能です。また、ER図を見やすくシート分割し、かつ分割後の整合性も保てる「サブモデル」機能や、複数のエンティティで共通的に使うアトリビュートに対してテンプレート化ができる「ドメイン」機能などを備えており、ER図作成の効率、品質の両方を高めることができます。

SI Object Browser  ERの画面画面.OBERの設計画面

データベースと直接連携できる

さきほどもER図から物理データベースの構築する方法をご紹介しましたが、手動でスクリプトを作成するにはやはり手間になります。そこでOBERでは、ER図情報を元に自動でスクリプトを生成し、物理データベースを構築できる「フォワードエンジニアリング」機能を備えています。この機能により、ER図作成後はスムーズに物理データベース構築が可能となっています。

SI Object Browser ERのデータベース連携機能
図17.OBERのデータベース連携機能

さらに、データベースからER図を逆生成する「リバースエンジニアリング」機能や、ER図とデータベースの相違点を比較し自動で同期する「データベース同期」機能も備えており、新規案件だけでなく既存システムの改修案件や、保守運用フェーズでの仕様変更対応が楽にできるようになっています。Oracle Database、SQL Server、DB2等の主要商用DBからPostgreSQLやMySQLなどのオープンソースDBまで幅広く対応しています。その他、テーブル定義書(Excel)の出力やテーブル定義書からのER図逆生成も可能です。

OBERは、ER図作成ツールの中ではめずらしい国産ツールとなっており、国内で4,000社以上の導入実績があります。30日機能制限なしで試用できるトライアル版もご用意していますので、本格的なER図を作成したい方はぜひご利用いただきたいと思います。

 

以上でER図の概要や書き方、テクニックをひととおり解説いたしました。ここまで読んでいただいた方はきっとER図の基本がマスターできているはずです。ぜひ今後のデータベース設計で実践いただけたらと思います。

新規CTA

新規CTA
新規CTA

RELATED POST関連記事


RECENT POST「ER図の書き方講座」の最新記事


この記事が気に入ったらいいねしよう!
新規CTA
ブログ購読のお申込み

RANKING人気資料ランキング

RANKING人気記事ランキング

RECENT POST 最新記事