ER図とは？
ER図は、システム設計における設計図のことを指します。「Entity Relationship Diagram」と記されることもあり、「エンティティ（Entity）」はモノ、「リレーションシップ（Relationship）」は関係を意味し、それぞれを組み合わせたシステムの設計のことです。
仮に、ショッピングサイトにて、ユーザーが商品を注文する処理を行う場合、Entityはユーザーや顧客が該当し、Relationshipは注文する工程が該当します。
シンプルなシステムなので、大規模なシステムにありがちな「システムの複雑化」を回避しやすくなっています。
ER図を書くメリット
ER図を書くメリットは、主にコストや運用・保守などで得られます。
具体的なメリットは以下の通りです。
後戻りコストを防げる
ER図を書くにあたって、システム開発に関わる方のメリットとなるのが後戻りコストを防げる点です。
システム設計では、テーブル数が多くなると、プログラマがその仕様を把握するまでに時間がかかったり、そもそも把握しきれないといった問題点が発生します。また、テーブル数が増えると設計ミスも増えやすくなることから、後戻りのコストが懸念材料となるのです。とくに、システムの規模が大きくなると、後戻りコストはさらに高くなるリスクがあります。
しかし、ER図はシステムの表現がシンプルなので、システム全体を俯瞰しやすくなります。結果的に、プログラマが仕様を理解しやすくなったり、設計ミスを減らしやすくなったりするといったメリットにつながるのです。
運用・保守フェーズで活用できる
ER図は、運用・保守の観点から見ても、大きなメリットがあります。
システムは構築が終了した後も、運用・保守を続けていく限り、機能の修正・追加を行い、改修を実施していく必要があります。長年運用・保守を続けていると、設計者本人が退職などで現場からいなくなってしまうと、システム全体を把握する人材が残っておらず、改修が難しくなる可能性があるでしょう。とくに、設計ドキュメントも残っていない場合は、システムを知る人材の退職や転職は大きなリスクです。
しかし、ER図であれば、設計者本人でなくても、システムの内容を把握しやすくなるので安心です。仮に、大規模な仕様変更などの改修が計画されても、新しい担当者で対応できるようになるでしょう。
ER図のモデル
ER図を作成する前に知っておくべきなのが、モデルの種類です。「概念モデル」「論理モデル」「物理モデル」の3つが存在します。ここからはER図のモデルごとの特徴や書き方について詳しく見ていきましょう。
概念モデル
概念モデルは、各モデルの中でも最初に書くデータモデルです。主に、要件定義の段階でシステムの概要をわかりやすくする目的があります。特定の領域やシステムに関連する概念や要素の関係を表現するためのモデルであり、情報の整理、複雑な内容を視覚化して分かりやすくするための手段として利用できます。
一般的には、ソフトウェア開発、ビジネスプロセス分析、教育、知識管理など、さまざまな分野で使用されているデータモデルです。
概念モデルの書き方
ER図の作成を目的として、概念モデルを書く方法は、以下の通りです。
- システムにおける「エンティティ（モノ）」の定義を決定
- 「1」 に関係のあるエンティティにリレーションシップを引く
- リレーションを引いたら関係の内容を記載
- リレーションシップでつながるエンティティ間の依存関係を把握する（依存リレーションシップ）
- 依存リレーションシップの場合は実線を引く
- 依存関係にないリレーションシップ（非依存リレーションシップ）はエンティティに向けて点線を引く
論理モデル
論理モデルとは、概念モデルに対して肉付けを行ったようなイメージのデータモデルです。
属性や主キー、外部キーの定義のほか、リレーションシップを書き込んだり、カーディナリティなどを追加したりして論理モデルを構築します。
論理モデルの書き方
論理モデルは、概念モデルに肉付けを行うようなイメージで以下のように書いていきます。
- アトリビュート（属性）を追加する
- アイデンティファイアを定義する
- エンティティの中にアイデンティファイアに該当する項目を書き込んで水平線を書く（アイデンティファイアを設定する場合）
- 「2」 に該当しないアトリビュートを水平線の下に記載
- 親エンティティのアトリビュートを子エンティティに追加（リレーションシップを設定しているケース）
- カーディナリティを追加する
物理モデル
システムの詳細を設計するシーンで必要なのが物理モデルです。
物理データベースに反映できるよう、論理モデルの変換を行うのが物理モデルの特徴。主に、Oracle Databaseなどに向けた変換が多い傾向にあります。
ER図の最終段階である物理モデルの情報に沿って、物理データベースを作成していきます。
物理モデルの書き方
ER図の最終段階である物理モデルは、以下の手順で論理モデルを物理データベース向けに変換します。
- 仲介エンティティを設けて多対多リレーションシップでつながっているエンティティをテーブルに変換できるようにする
- アトリビュートごとに適切なデータ型を設定する
- ンティティ名及びアトリビュートをアルファベットに変換
ER図の基本的なルール
ER図を書くにあたり、知っておかなければならないのが基本的なルールです。
各プロセスには、設け方や各エンティティの結び方などに一定のルールが存在します。
エンティティ
エンティティは描いた四角い箱の中に、「モノ」の名前を書くのがルールです。Eコマースであれば、エンティティの名前として挙げられるのは、顧客、商品など。エンティティの名前が明確になっていないと、ER図の作成は進められません。
また、エンティティは、「リソースエンティティ」と「イベントエンティティ」の2種類に分離されるので注意してください。
- リソースエンティティ：基本データを管理するエンティティ
- イベントエンティティ：業務データを管理するエンティティ
アトリビュート
属性を定義したアトリビュートは、顧客名や顧客の住所、顧客の性別、顧客コードなどをエンティティ内に追加します。
ただし、追加するアトリビュートは必ず、関連性のあるエンティティと内に設けなければなりません。仮にアトリビュートとして設定したものが「顧客名」となる場合、追加先のエンティティは「顧客」などが該当します。
リレーション
複数のエンティティ同士の関係を考えたうえで、線（関連線）でつなぎます。
ただし、やみくもに関連線を引くのではなく、主語から目的語に向けて線を引くのがルールです。どのエンティティから、どのエンティティに向けて引かれた線なのかを明確にするために、線を引いた先に黒丸を書きましょう。
ちなみに、リレーションでは、主語・述語それぞれを以下のように呼びます。
- 主語：親エンティティ
- 目的語：子エンティティ
各エンティティの関係性が分かりやすくなる表現なので、覚えておきましょう。
カーディナリティ
カーディナリティは、リレーションシップでつながっているそれぞれのエンティティに注目します。各エンティティのレコード関係を表したものがカーディナリティであり、双方のレコード数を「〇対〇」で考えます。
一方のエンティティのレコードがいくつであり、もう一方のレコード数もいくつになるのかを考えるため、「多対多」「１対多」「多対1」となることもあります。
ER図内で表記する際には、「IDEF1X表記」と「IE表記」とで記号が異なるので注意しましょう。
【IDEF1X表記について】
記号：意味
なし：1
P：1以上
Z：0もしくは1
n：定数n
n-m：範囲指定をした定数
【IE表記について】
記号：意味
○：0
l：1
鳥の足：多
エンティティの依存・非依存関係
エンティティには「依存」と「非依存」があります。エンティティにおける依存とは、親エンティティがなく、子エンティティのデータが存在しないことです。たとえば、ショップと商品は依存関係にあたります。なぜなら、ショップがなければ商品の登録ができないからです。
非依存は、上記に該当しない関係性を意味します。仮に顧客と商品がリレーションシップで結ばれていても、顧客が0人であっても商品の販売は可能であることから、それぞれは非依存関係と判断されます。
ER図を書く手順
ER図を書く手順について解説していきます。具体的に、どのように進めていけばいいのか、作成の流れを確認したい方は参考にしてみてください。
システム開発の進め方を確認する
ER図を書く手順の、第一ステップが「システム開発の進め方を確認」です。
システム開発の進め方が明確になっていないと、そもそもER図の記述はできません。
ユースケース図などの情報をもとにER図を設計していくことから、ER図の作成が決まったらまずは事前の情報収集を忘れないようにしましょう。
エンティティを洗い出す
ER図に盛り込むための、エンティティを洗い出していきましょう。
前項の工程で明確にしたアクティビティ図やユースケース図などの情報をもとに、適切なエンティティが何なのかを明確にします。
仮に、この段階でエンティティを洗い出せていない場合には、システム開発の進め方について確認が漏れていたり、そもそもシステム開発の進め方が不明確になっている場合があるので、適宜見直し・再確認を行ってみてください。
マスタデータ・トランザクションデータに分類する
エンティティをマスタデータ（固定的なデータ）とトランザクションデータ（流動的なデータ）に分類して整理します。洗い出したエンティティを整理しないと、何からER図に盛り込むべきかが見えなくなってしまうためです。
マスタデータやトランザクションデータを分類する作業の中で、複数のエンティティが一つにまとめられそうであると気づいたときには、それぞれを合体させることも可能です。
アトリビュートを洗い出す
エンティティをマスタデータとトランザクションデータに分類したら、アトリビュートを洗い出します。
本手順は、時間がかかりやすい工程ですが、画面設計書を確認しながら行うことで、時短につながるのでおすすめです。画面上に出力される項目がアトリビュートとなることが多いので、0からアトリビュートを洗い出すよりも比較的簡単に抽出しやすくなります。
ER図を書く
上記の工程をすべてふまえ、情報をER図に盛り込んでいきます。設計するのは「リレーション」「主キー」「外部キー」の3つ。
本ページで触れた概念モデル、論理モデル、物理モデルそれぞれの書き方を参考にしながら、ER図の作成を進めていきましょう。
まとめ
ER図はシステム開発の現場で用いられる設計図の1つです。大規模なシステムにも用いやすく、さまざまなメリットがあります。
ER図の作成に慣れていない方や、初めて作成する方は、本記事でご紹介した内容をヒントにしながら、設計を進めてみてください。
