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

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

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

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

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

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

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

ER図の読み方

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

エンティティ

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

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

アトリビュート

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

リレーションシップ

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

カーディナリティ

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

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

ER図の書き方

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

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

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

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

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

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

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

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

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

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

ER図作成のメリット

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

ER図作成のデメリット

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

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