そもそもER図とは

ERは「Entity Relationship Diagram」の略称であり、データベース設計における代表的な設計図を指します。システムを設計する際の手法としては、他にもUMLなどの技法もあります。UMLは「統一モデリング言語」という意味で、システム開発を図式で表現、記述方法を統一することです。設計書のわかりやすさや情報共有の効率の向上に役立ちます。

ER図は「DOA」と呼ばれる「データ中心アプローチ」の技法を用い、作成したER図を物理データベース上に直接変換できることから、データベース設計における手法の事実上の標準となりつつあります。ER図の「E」はエンティティを示し、「R」はリレーションを示します。つまり、ER図とは「実体（データなど）」と「関係」の組み合わせのことで、システムにおけるデータ間の処理する構造を指します。

例えば、「顧客が本を注文する」という処理をER図で表現してみます。「顧客」「本」がエンティティ、「注文する」がリレーションに対応します。大規模システムの場合でも、エンティティとリレーションの組み合わせを用いて、わかりやすくシステムを表現できることがER図の特徴です。

システムエンジニア（SE）とは？仕事内容や年収、必要スキルを解説！

システムエンジニアがキャリアアップするのにおすすめの資格を解説！

ER図はシステム開発における要件定義や設計などの上流工程の中で、段階的に設計を行います。各工程で作成したER図の状態を「データモデル」といい、データモデル図には「概念データモデル図」「論理データモデル図」「物理データモデル図」の3種類があります。

ここからは、各データモデルについて簡潔に説明します。

1.概念データモデル図 概念データモデル図は、要件定義工程の際に作成するデータモデル図を指し示し、システム全体におけるエンティティ、リレーションを洗い出し、事象を大まかに表した図のことです。

2.論理データモデル図 論理データモデル図は、基本設計工程の際に作成するデータモデル図を指します。論理データモデル図を作成する際は、概念データモデル図に対してさまざまな詳細を加えて肉付けを行います。具体的には、アトリビュート・主キー・外部キー・リレーション・カーディナリティといった要素を付け加えます。 論理データモデル図においては、データ型の定義のように物理データベース向けの設計は行わないため、特定のデータベースに依存しない状態のモデル図といえるでしょう。

3.物理データモデル図 物理データモデル図は、詳細設計工程の際に作成するデータモデル図を指します。ここでは、「MySQL」や「Oracle Database」など特定の物理データベース向けに論理データモデル図の変換を行います。例えば、物理データベースに適したデータ型を追加したり、ローマ数字に変換したりします。ER図の最終形態が物理データモデル図です。物理データモデル図が完成した後は、物理データベースを実際に作成することができるでしょう。

ER図を作成する際は、下記の5つの標準的な要素を用いることが多いです。

1.エンティティ 「エンティティ」とは、実体、つまりデータのまとまりのことを指します。エンティティの中には、アトリビュートという属性情報があります。アトリビュートについても後ほど解説します。

2.リレーション 「リレーション」は関係を意味し、エンティティ同士の関係を表現する線のことを指します。リレーションの詳細については、カーディナリティという記号を使って表現します。カーディナリティについても後ほど解説します。

3.アトリビュート 「アトリビュート」は属性を意味し、エンティティの中の属性情報のことを指します。アトリビュートでは、主キーや外部キーについても表現します。主キーとなる項目は、エンティティ上部に四角の囲いで記載し、外部キーとなる項目は、項目名の後ろに「（FK）」と記載します。その他の項目は、項目名のみ記述することが多いでしょう。

4.カーディナリティ 「カーディナリティ」は多重度を意味し、「1対1」「1対多」「多対多」など、リレーションの始点と終点を表現する記号のことを指します。さらに、「0以上」「0または1」なども表現することが可能です。

5.エンティティの依存関係と非依存関係 「依存関係」とは、結びつくデータが必ず存在する関係、つまりエンティティ間の親子の関係性を指します。親と子のどちらのデータが欠けたとしてもシステム的に成り立たないことを示しています。子となるエンティティの枠線を角丸で表現することが多いでしょう。 一方、「非依存関係」とは、エンティティ間で親子がない関係性のことを指します。この場合、結びつくデータが存在しなくてもシステム的に成り立つことができます。非依存関係の場合、親と子のどちらのエンティティも四角の枠線で表現することが多いでしょう。

ER図を作成する2つのメリット

これまでに、ER図の詳細について紹介してきました。ここからは、ER図を作成する上で2つのメリットを紹介しましょう。

システム開発後は、正常に稼働するように監視を行いながら、よりよいシステムになるように改修を繰り返していきます。ER図は、システム開発後の保守・運用工程においても活用できるでしょう。システムが稼働しはじめた直後は、設計者がプロジェクト内にいることが多いため、設計書がなくても問題がない場合もあります。

しかし、設計者が別のプロジェクト案件に異動するなど、プロジェクト内に残り続けるということはほとんどありません。したがって、ER図を設計書の中に記載しておくことで、設計者ではない方でもシステムの設計内容を正確に理解し、システムの仕様の変更などの改修を行う際にスムーズに対応することができます。

【保守・運用】仕事内容や将来性、必要なスキルについて徹底解説！

データベースのテーブル数が多くなると、設計誤りや、プロジェクト関係者がシステムの仕様について理解できないことがあります。その場合、手戻りが必要なことも多く、余分なコストが発生してしまいます。特に大規模なシステムの場合は、ER図でデータベース構造などを整理することで、システム全体の構成を俯瞰することができるため、手戻りを起こす可能性を減少させることもできるでしょう。したがって、システム開発においてER図の作成は必要不可欠といえるでしょう。

ER図の作成方法

ここからは、ER図の作成方法を紹介します。ER図に限らずシステム設計全般において言えることとして、大枠から徐々に詳細に落とし込む作業が重要です。

ER図を記述する際は、システム開発の進め方が明確になっていることが前提です。ユースケース図やアクティビティ図などを、インプット情報としてER図を設計します。特に、ER図を作成する際に、ユースケース図は重要な役割を果たすことが多いです。ユースケース図とは、ユーザーの視点に立ち、システムの利用例を表現する図解術のことを指します。

ユースケース図の設計が終わってない段階でのER図の作成はおすすめできません。まずは、システム開発の進め方の設計からはじめましょう。

システム開発の進め方について把握できたら、ユースケース図やアクティビティ図などを基にエンティティを洗い出します。システム開発の進め方の設計を正確に行っていれば容易にエンティティを洗い出すことができるでしょう。

エンティティの洗い出しが完了したら、エンティティを「マスタデータ」と「トランザクションデータ」に分けましょう。データはマスタデータとトランザクションデータに大きく分けられます。マスタデータとは固定的なデータ、トランザクションデータとは流動的なデータといわれることが多いです。次のアトリビュートを洗い出す前に、整理しておきましょう。

また、マスタデータとトランザクションデータを整理する過程の中で、エンティティが合体することも少なくありません。

次に、エンティティの中のアトリビュートを洗い出します。アトリビュートの洗い出しは、画面設計書を基にすると効率的に行うことができます。画面に出力される項目がアトリビュートとなる場合が多いでしょう。

アトリビュートまで洗い出すことができたら、リレーション・主キー・外部キーの設計を行いER図を作成します。また、カーディナリティは業務内容によって変わることに注意しましょう。これでようやくER図の完成です。ここからは、設計メンバーでレビューを重ねてブラッシュアップしていくことが重要です。

ER図を効率よく作成してプロジェクトの成果を向上させよう！

この記事では、ER図の詳細、メリット、作成方法を紹介しました。ER図を作成することで、プロジェクト工程の手戻りを減らすことができるなどメリットが多くあります。

また、実際にER図を作成する際に、無料で利用できるツールも存在します。カーディナリティの変更なども、ツールを使えば簡単に変更が可能です。例えば、「Cacoo」というクラウド型の図形作成ツールがあります。業務効率を上げるために、ER図作成ツールを活用することもおすすめします。これらを踏まえて、ER図を効率よく作成してプロジェクトの成果を向上させましょう。