データベース設計の基本であるER図ですが、「書き方が分からない」「複雑そう」など、思うように手を出せない人も多いでしょう。

そこで、この記事ではER図の意味から書き方や読み方、メリット・デメリットを解説していきます。

図を用いてわかりやすく解説しているので、初心者でも理解しやすいと思います。

ER図の作成に取りかかろうとしている人はぜひ参考にしてください。

【データベース設計の基本】ER図とは？

アプリケーションを作成する場合に、避けては通れないのがデータベース設計です。

データベース設計においては、様々な手法が使用されますが、その中でも基本中の基本と言えるのがER図というものです。

ER図とは「エンティティ・リレーションシップ図」の略であり、英語では「Entity Relationship Diagram」と呼ばれています。

その名の通り、データの構造と関係を図に表したフローチャート（フロー図）です。この記事では、このER図がどういうものか、そして、どのように付き合えば良いのかをわかりやすく解説します。

 ER図の役割とメリット

まずER図について説明しましたが、ここでは役割とメリットについて解説していきます。

大規模開発ではER図は必要不可欠ですがどんな役割を持っているかを５つの項目に分けて紹介します。

データベース構造の理解と分析

ER図はシステム内の関連性を表す設計図になります。

システム上のデータ間の構造が網羅されているため、全体の理解が可能です。
図式で表現することにより設計書内がわかりやすくなるため、情報共有やデータベース構造の理解が容易になります。

また万が一問題点が出てきたとしても特定、分析がしやすくなるのもメリットに挙げられます。

データベース設計の支援

データベース設計は開発において非常に重要な要素です。不備があった場合は手戻りの原因にもなり
開発スケジュールの遅延が発生するような影響も出てくる可能性があります。

ER図を作成することで、データベースの相互関係性が確認しやすくなり基本情報の整理が可能になります。

データベース設計の支援がER図において必須と言えるでしょう。

コミュニケーションツール

ER図を使うことにより、各担当者同士の連携やコミュニケーションツールとして活用ができます。

開発者やデータベースの管理者のように相互でデータ構造と関連性の認識を合わせることにより共通理解が構築できます。

ER図を作成することで、コミュニケーションロスによる設計ミスを防ぐ役割もあります。

またWeb上でER図が作成できるツールやテンプレートの種類が豊富です。

A5:SQL Mk2やDraw.ioのようなWebツールがあり、無料で使用できるものもあります。

ER図の作業を効率化するためにも、開発の規模やニーズに合わせてツールを選定することができますので、さまざまなツールを活用してみてはいかがでしょうか

問題点の発見

開発規模にもよりますが、テーブルの数がどんどん増えていくにつれ設計のミスや仕様が把握できないリスクが増えていきます。

結果的に手戻りが発生するので開発スケジュールに支障が発生する可能性もあります。

ER図を作成し整理しておくと、システムの全体像が明らかになるのでデータベースの管理がしやすくなります。

問題点があれば、どの箇所で発生したかも確認が容易になるので大規模開発ではER図は必須と言えるでしょう。

保守・運用

システムは規模の大小に関わらず、継続的に確認作業や改善をしていくことが必要です。

ER図を使って設計を保存や改善を行い都度更新をするとシステムの運用・保守の工程で設計作業に携わる関係者がすべての情報をいつでも確認することが可能になります。

当時設計した人がいなくてもシステムの全容を把握しやすくなりますので、変更点の改善や修正もスムーズに行うことができます。

ER図は「いつ作り」「いつ使う」？

まず、最初に明確にすべきことは、ER図というものをいつ作って、いつ使うかということです。そのためには、アプリケーション開発の全体のフェーズにおけるデータベース設計の工程を明確にしておく必要があります。

各工程ごとでER図を設計するため説明していきます。

ER図を作るタイミング

先ずER図を作るタイミングですが、フェーズごとに作成を行います。

一般的なフェーズ分けとしては以下のようになります。それぞれシステム開発のフェーズとデータベース設計の工程を記述してあります。

• 要件定義(計画、分析)：概念データ設計
• 基本設計：論理データベース設計
• 詳細設計：物理データベース設計
• 開発(コーディング)
• テスト

このうち、ER図が最初に出てくるのは、1の要件定義の中で行われる概念データ設計の工程です。

ここで作成されたER図は続く論理データベース設計の基本となり、物理データベース設計時に物理 ER図として、記述し直されます。

その後の開発やテスト、そして保守(メンテナンス)作業においても参照され続けます。

適切で有効なER図を作成することは、システム開発全体において極めて重要な作業ということになります。

ER図を使う場面

先ほどER図を作るタイミングを記載しましたが、使う場面についても説明していきます。

上流工程の要件定義から基本設計、詳細設計、開発からテストまですべての工程で活用されます。

開発やテスト工程でも、作成したER図を元に全体通して参照されるため非常に重要です。

もうひとつ重要なのは、ここで示したものはウォーターフォール型と呼ばれる伝統的な開発手法において定義された工程であり、アジャイル型においては同様の工程を短期間で繰り返すことになるため、ER図をどの工程で作るかに関しては別に考慮が必要です。

 ER図の用語と読み方

[図1]

ここでは、ER図の読み方を通じて、 ER図とは何かということを明確にしていきます。[図1]を参照してください。この図の中に表されている各要素の意味を順番に解説します。

エンティティ

まずは、図の中で「会員」、「注文」というボックスとして表現されている「エンティティ」という要素です。日本語では「実体」と訳されますが、この訳ではどういう意味なのかよく分かりません。

簡単に言ってしまえば、名前がついたものすべてが「エンティティ」です。名前がついていれば、目に見えるものだけではなく、概念などの無形のものもすべて「エンティティ」として扱うことができます。

「エンティティ」の中には、図の「注文」に対する「注文明細」のように、相手が存在しなければ存在しえない親子関係を持つものがあります。この場合は子に当たる「エンテイティ」を角丸のボックスで表します。

アトリビュート

そして、「エンティティ」のボックスの下側にリストされているのが「アトリビュート」つまり「属性」です。これは、「エンティティ」を形容するものと言えば分かりやすいでしょう。

別の言い方をすれば、「エンティティ」が個別の「インスタンス」になるための条件と言っても良いでしょう。

たとえば、「会員」が「あなた」という「インスタンス」になるためには、それがあなたの会員番号、あなたの会員名、あなたが住んでいる住所を「アトリビュート」として持っている必要があります。

リレーションシップ

つぎは「リレーションシップ」です。「リレーションシップ」とは、「エンテイティ」間の「関係」のことです。

この図では、両方の「会員番号」という「アトリビュート」が関係を持っているということがわかります。図のように「リレーションシップ」は線で表されます。

カーディナリティ

最後に、その「リレーションシップ」の対応の多重度を示しているのが「カーディナリティ」です。

この図においては、「会員」の「アトリビュート」としての「会員番号は」１つですが、その会員は複数の注文をしている可能性もあるし、一つも注文をしていない可能性もあります。

したがって、「カーディナリティ」は「１対０あるいは多」という多重度になります。

それを表現しているのが「会員番号」の「リレーション」の両端の記号です。

「カーディナリティ」の記述方法にはいくつかありますが、この記事ではその中で最もオーソドックスな「IE記法」を使用しています。

「IE記法」では、１は縦の線、0は丸、多は鳥の足のような線で記述されます。これらの記法は細かい部分ではいくつかのオプションがあるので、読み解く場合にはどのやり方なのかを確認する必要があります。

ER図の書き方

ここでは、簡単なER図の書き方を解説します。まず、最初に決めなければならないのは、どのプロセスのデータを扱うかということを決めます。

ここでは、例として、ECサイトで、購入する電池を何にするかを検索するプロセスを題材にします。このプロセスを「ユースケース」と呼びます。

次に、この「電池検索ユースケース」で扱う「エンティティ」を洗い出します。まず、思いつくのは検索するものと検索されるものである「電池」と「電池検索」という「エンティティ」です。

そして、「電池」の「エンティティ」における「アトリビュート」を列挙します。電池を形容する言葉です。

[図2]

それは、[図2]にあるように、一意の「商品番号」、単１、単２などの「サイズ」、アルカリ、マンガンなどの「タイプ」、パナソニックなどの「メーカー」、「単価」、そして「名称」です。

同じように、「電池検索」の「アトリビュート」に関しても洗い出してみましょう。

[図3]

結果としては[図3]のようになります。ここまでできたところで、「電池検索」の「エンティティ」の「アトリビュート」の「サイズ」、「タイプ」、「メーカーの一部」は厳密には「電池」の「エンティティ」の中にはないことがわかります。

[図4]

これは、[図4]のように、新しく「サイズ」、「タイプ」、「メーカー」の「エンティティ」を作ることで解決できます。

[図5]

そして、[図5]で追加したように、これらの「エンティティ」には「電池」の「エンティティ」との「リレーションシップ」が存在し、これらの「エンティティ」を新しく作った経緯から簡単に設定できます。

[図6]

そして、最終的には[図6]のように、「電池検索」の「エンティティ」と「電池」、「メーカー」、「タイプ」、「サイズ」の「エンティティ」との間にある「リレーションシップ」と「カーディナリティ」を定義することによって、このユースケースで使用するER図が完成します。

ここまで行ってきたように、ER図の作成にあたって重要なのは、そのプロセスで扱うデータの関係を常に意識することです。

最初に作成するER図に関しては、いわゆる「正規化」を意識せずに行う方がデータの洗い出しがうまくいくことが多いのですが、物理データベース設計に使用するER図では、データの冗長さを排除し、更新の効率を考慮する必要があり、それは事前あるいはER図作成時に「正規化」を行うことによって実現できます。

 ER図を作成する時の注意点

ER図作成についてメリットやどのタイミング作成するかについて説明しましたが、作成の際に注意しなければならない点もあります。

ER図の作成は非常に重要ですが、ここでは３点注意する点について説明します。

表現力に限界がある

ER図はExcelなどのアプリケーションで作成することも可能です。

ただ罫線や図形オブジェクトを使っての作成は表現力、工数面でもあまりおすすめはできません。

昨今のER図は効率よく作成するツールがあるため利用しましょう。

例えば「Cacco」というクラウド官k表の作図ツールではワイヤーフレームや図形の種類が豊富なので
表現力を広げるためには有効になります。

作成・更新の手間がかかる

ウォーターフォール型の開発だと順番が決まっているため事前に確認していけば手戻りは発生しにくいですが、

アジャイル型の開発においてはER図に立ち戻っての変更も頻繁に必要になり、それによってリファクタリング(データベースの再構成)も必要になります

そのためER図の作成から更新の手順が出てくるため手間が増えるのは注意が必要です。

このような状況においての解決として、自動コード化の仕組みがあれば複雑な処理が必要なリファクタリングも容易に行うことができます。

誤解や解釈の誤りが発生する

ER図が実際には図でしかないために、それをデータベースやプログラムにするためには様々な工程を経て必要があることです。

これらの多くの工程において、ER図に表されているものがもし誤解されて使用されるようなことがあると、結果的には要件に合わないシステムができてしまいます。

まとめ：ER図を活用してデータベース設計を効率化

ER図を活用することでシステムの全体像を把握することが可能になり、データ構造の理解や分析にもつながります。

大規模、中規模問わずシステム開発で問題点の発見もしやすくなるので注意点に気を付け有効活用しましょう。

ただし自社での作成や人員が不足している場合は外注することも１つ検討してみても良いかもしれません。

Jiteraでは、要件定義を書くだけでAIが生成するツールで、アプリ・システム開発を行っています。

制作している途中で要件が変更になっても柔軟に修正しながら開発できるので、アプリ開発・システム開発のご相談があればお気軽に相談ください