JITERA

お問い合わせ

データベース設計に必須! ER図の書き方

データベース設計に必須! ER図の書き方

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

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

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

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

データベース設計の基本、ER図とは?

アプリケーションを作成する場合に、避けては通れないのがデータベース設計です。データベース設計においては、様々な手法が使用されますが、その中でも基本中の基本と言えるのがER図というものです。ER図とは「エンティティ・リレーションシップ図」の略であり、英語では「Entity Relationship Diagram」と呼ばれています。その名の通り、データの構造と関係を図に表したものです。この記事では、このER図がどういうものか、そして、どのように付き合えば良いのかをわかりやすく解説します。

ER図、いつ作り、いつ使う

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

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

このうち、ER図が最初に出てくるのは、1の要件定義の中で行われる概念データ設計の工程です。ここで作成されたER図は続く論理データベース設計の基本となり、物理データベース設計時に物理 ER図として、記述し直されます。そして、その後の開発やテスト、そして保守(メンテナンス)作業においても参照され続けます。そのため、適切で有効なER図を作成することは、システム開発全体において極めて重要な作業ということになります。

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

システム開発・アプリ開発をご検討の方へ

株式会社Jiteraでは、開発プロジェクトの無料相談・無料シュミレーションを行っております。

  • スケジュールや予算を無料相談したい
  • 制作したいアプリ・システムのUI/UXのシュミレーションをしてみたい
  • 作りたい機能やカスタマイズは実際にカスタマイズできるの?

こんな相談はありませんか?
上記のような相談をJiteraでは、無料で承っております。

今すぐ日程調整ができるので、以下のカレンダーからお気軽にお問い合わせください。

ER図の読み方

カーディナリティ

[図1]

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

エンティティ

まずは、図の中で「会員」、「注文」というボックスとして表現されている「エンティティ」という要素です。日本語では「実体」と訳されますが、この訳ではどういう意味なのかよく分かりません。簡単に言ってしまえば、名前がついたものすべてが「エンティティ」です。名前がついていれば、目に見えるものだけではなく、概念などの無形のものもすべて「エンティティ」として扱うことができます。

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

アトリビュート

そして、「エンティティ」のボックスの下側にリストされているのが「アトリビュート」つまり「属性」です。これは、「エンティティ」を形容するものと言えば分かりやすいでしょう。別の言い方をすれば、「エンティティ」が個別の「インスタンス」になるための条件と言っても良いでしょう。たとえば、「会員」が「あなた」という「インスタンス」になるためには、それがあなたの会員番号、あなたの会員名、あなたが住んでいる住所を「アトリビュート」として持っている必要があります。

リレーションシップ

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

カーディナリティ

最後に、その「リレーションシップ」の対応の多重度を示しているのが「カーディナリティ」です。この図においては、「会員」の「アトリビュート」としての「会員番号は」1つですが、その会員は複数の注文をしている可能性もあるし、一つも注文をしていない可能性もあります。したがって、「カーディナリティ」は「1対0あるいは多」という多重度になります。

それを表現しているのが「会員番号」の「リレーション」の両端の記号です。「カーディナリティ」の記述方法にはいくつかありますが、この記事ではその中で最もオーソドックスな「IE記法」を使用しています。「IE記法」では、1は縦の線、0は丸、多は鳥の足のような線で記述されます。これらの記法は細かい部分ではいくつかのオプションがあるので、読み解く場合にはどのやり方なのかを確認する必要があります。

ER図の書き方

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

ここでは、例として、ECサイトで、購入する電池を何にするかを検索するプロセスを題材にします。このプロセスを「ユースケース」と呼びます。次に、この「電池検索ユースケース」で扱う「エンティティ」を洗い出します。まず、思いつくのは検索するものと検索されるものである「電池」と「電池検索」という「エンティティ」です。そして、「電池」の「エンティティ」における「アトリビュート」を列挙します。電池を形容する言葉です。

ER図の書き方

[図2]

それは、[図2]にあるように、一意の「商品番号」、単1、単2などの「サイズ」、アルカリ、マンガンなどの「タイプ」、パナソニックなどの「メーカー」、「単価」、そして「名称」です。同じように、「電池検索」の「アトリビュート」に関しても洗い出してみましょう。

ER図の書き方

[図3]

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

ER図の書き方

[図4]

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

ER図の書き方

[図5]

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

ER図の書き方

[図6]

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

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

ER図のメリット・デメリット

ここまで、ER図とはどういうものか、どう読み、どう書くかに関して説明してきました。冒頭でも述べたように、データベース設計においてER図はなくてはならないものであるというのが前提ですが、実はER図を使用することにはメリットとデメリットがあります。今後、ER図と付き合ってゆくためにはその両方を知っておく必要があります。

ER図作成のメリット

まずは、メリットからですが、最も大きなメリットは、やはり扱う必要のあるデータの持ち方や関係が一目でわかるため、プログラム開発やテストにおいてもデータの扱い方を決めるのに役に立ちます。そして、それはシステムのサービスイン後に長く続く保守フェーズにおいても、プログラムをどのように変更したら、どのような影響が出るかを判別するのに役に立ちます。

ER図作成のデメリット

デメリットとして挙げられるのは、ER図が実際には図でしかないために、それをデータベースやプログラムにするためには様々な工程を経て必要があることです。これらの多くの工程において、ER図に表されているものがもし誤解されて使用されるようなことがあると、結果的には要件に合わないシステムができてしまいます。それを防ぐためには、ER図をいかに確実にデータベース化、コード化するのかということを考え、そうなっていることを検証し続けなければなりません。このデメリットに関しては、ER図自体を自動的にコード化してくれるようなツールがあれば極めて有効な対策になります。

さらに、アジャイル型の開発においてはER図に立ち戻っての変更も頻繁に必要になり、それによってリファクタリング(データベースの再構成)も必要になります。このような状況においても、自動コード化の仕組みがあれば複雑な処理が必要なリファクタリングも容易に行うことができます。

Author of this article
Fumie Chinone

コスト削減も課題解決も同時に実現

「JITERA」で迅速
ソフトウェア開発

開発を相談する

「JITERA」を使って開発コスト削減

経験豊富なメンバーがゼロから伴走支援

開発を相談する
Recommended articles for you

Discover more of
what matters to you

まるごと開発委託は
JITERAまで

弊社のPM・エンジニア・デザイナーが新規事業・DXプロジェクトをすべて担当します

お問い合わせ