ER図/EER図を導入した開発パートナー選びのポイント
「ER図」「EER図」という単語・用語を見聞きしたことがありますでしょうか？
「ER」といえば救命救急室（Emergency Room）の頭文字をとった略称が有名です。
国内・海外の映画や連続テレビドラマで「救命救急」をテーマしたことで、「ER」が有名になりました。
医療業界での「ER」は、全ての救命患者に対応する緊急救命処置を行う医療システムを示します。
今回紹介する「ER」「ER図」というIT用語です。
コンピューターシステムは、多くのシステムでデータベースを使用しています。
データベースは、データベース群と相互にリーレーションして運用します。
そのデータベースをリレーションする「概念データモデル」を「ER図」と言います。
ITエンジニアが活用するフローチャートに似た図面です。
これから「ER図」と「ER図」が進化した「拡張実体関連モデル」である「EER図」を紹介していきます。
目次
ER図とは何か？
「ER」とはEntity Relationshipの略称です。
和訳すると「実体関連モデル」になります。
「ER図」は「実体関連モデル図」になります。
「実体関連モデル図」とは、情報システム業界で、データベース・トランザクションデータを更新するための設計図として使用します。
言い換えればとデータ構成図といわれます。
「ER図」は「データ構成図」「実体関連モデル図」ですと紹介してもよくわからないと思います。
これからマイクロソフト社製のアプリケーションソフトウエアMicrosoft OfficeのひとつのMicrosoft Accessを例にして紹介していきます。
Microsoft Accessは小型のリレーショナルデータベース構造でつくられています。
「親」の基本データベースに「従」「副」「子」のデータベースが絡み合い成果を発揮します。
Microsoft Accessをご存知のエンジニアの方はご理解いただけるとおもいます。
例えば「親」の基本データベースにある「顧客番号」と「副」の住所データベースにある「顧客番号」が「親」「副」を関連付けする項目になります。
「副」の住所データベースにある「郵便番号」と「子」の都道府県名データベースにある「郵便番号」が「副」「子」を関連付けする項目になります。
「ER図」は「親」「従」「副」「子」「孫」…のデータベースを関連付けする設計関連図であると思い浮かべてください。
キャプション：Microsoft Access のリレーションシップ画面
「ER図」は、データベースを構成するデータの束を「エンティティ」と言う四角形で表記します。
データの関連を「リレーション」と言う線で結び「カーディナリティ」と言う記法で相互の関係性を表します（後記4.3のサンプル図を参照してください）。
「ER図」には「概念データモデル」「論理データモデル」「物理データモデル」の3種があります。
第1の「概念データモデル図」は、システム全体をモデル化して、記号を使用した大まかな分類図です。
第2の「論理データモデル図」は、概念データモデルを詳細化して、画面・帳票等のユーザーインターフェースを付記した分類図です。
第3の「物理データモデル図」は、「論理データモデル図」を細分化して、ユーザーインターフェースとデータベースの情報を1対1に関係した分類図です。
EER図とは何か？
「EER図」はExtension Entity Relationshipの略称です。
和訳すると「拡張実体関連モデル」になります。
「EER図」は「ER図」を拡張した「実体関連モデル」といわれています。
「EER図」は「ER図」の不足項目を補完する概念を導入してあり、高性能なデータベースを設計するのに効果的です。
「EER図」は、既存の「ER図」追加された3項目の概念があります。
追加項目は「一般化」「専門化」「集約」です。
「一般化」は下位レベルのエンティティを組み合わせて上位レベルのエンティティを生成します。
「専門化」は一般化の逆版です。「専門化」は高レベルのエンティティを低レベルのエンティティに分割します。
「集約」は2つのエンティティ間の関係が単一のエンティティとして扱われる場合のプロセスを示します。
ER図とEER図は何が違うのか？の相違点
「ER図」と「EER図」はリレーショナルデータベースの関係性を正確に作図することができます。
「ER図」はリレーショナルデータベースの関係性を全体的に視覚的な表記をします。
エンティティ（実体）の関係と属性を詳細に記述して、リレーショナルデータベースの開発に効果を発揮します。
「EER図」はリレーショナルデータベース内の情報を構造化して、「ER図」より詳細に記述します。
リレーショナルデータベースに多くの項目（前章で紹介したMicrosoft Access で設定した「顧客番号」「郵便番号」「都道府県名」など）を有するときは、構成要素をより深く理解できる「EER図」を選択するケースが多いようです。
ER図/EER図の運用事例
「ER図」「EER図」を活用したシステム開発・システム運用事例を紹介します。
ER図の運用事例
独立系のシステム・インテグレーション、ソフトウェア開発、ネットワーク・アウトソーシングサービス事業を中心に成長を続けるベンダー企業の事例を紹介します。
今から10年ほど前の2012年に品質管理・コスト管理・進捗管理の効率化を成功しました。
DBMS（Database Management Systemの略称です。リレーショナルデータベース管理システムを示します。データベースの維持・運用を管理するシステムのことです。）に付帯する標準の開発ツールよりも使いやすく、生産性向上につながると開発現場から「ER」図の導入が開始されました。
現在では全社に広まっています。
EER図の運用事例
国内最大級の大手ITベンダーが「EER図」を導入したことで、作業効率の向上に成功しました。
大きな目的は各フェーズの作業工程で「二度手間をなくすこと」です。
「EER図」を作図することで、リレーショナルデータベースのテーブル定義書のドキュメントとDDL（Data Definition Languageの略称です。リレーショナルデータベースの構造や構成を定義するために用います。リレーショナルデータベースの制御に用いるSQL文の一部の命令群を含みます。）を同時にメイキングすることができます。
従来は、別々に手作業で仕様書を作成して整合性を維持・確認をしていました。
手作業での照合は手間がかかります。
「EER図」ツールを活用することで、修正する箇所が1カ所で済みます。
「EER図」を修正することで、上記のテーブル定義書、DDL修正の手戻りの工数が大幅に削減されました。
EER図の作図サンプル
キャプション：生命保険業界のEER図サンプルです。
ER図／EER図を導入した開発パートナー選びのポイント
開発パートナー企業のなかでは「ER図」「EER図」を導入しないケースがあります。
顧客マスター・得意先マスター・顧客台帳を有するシステムにおいては、リレーショナルデータベースを導入して運用します。
開発パートナー企業のシステム開発は特徴がありますが、「設計を行わずデータベースを構築する」「データベース設計においてはテーブル設計書だけ作る」技法もあります。
しかし、「ER図」「EER図」を導入している開発パートナー企業を選択すると2つのメリットがあります。
第1に新規開発中のシステムや既存システムに仕様変更があったとき、仕様変更箇所の各種ドキュメント・プログラム、試験仕様書をもれなく修正する必要があります。
「ER図」「EER図」の仕組みを導入していると、「ER図」「EER図」の改修をすることで、各種ドキュメント修正を一元管理できることです。
基幹業務システムのリプレイスなどの大規模案件においては、「ER図」「EER図」の作図は必須なツールといえます。
第2にシステム運用・保守フェーズで役立ちます。
基幹システムは一度構築すれば終わりではなく、長年稼働しながら改修を繰り返していきます。
基幹システムの開発パートナー企業が「ER図」「EER図」を導入したことで、システムの運用・保守フェーズにおいて大活躍します。
サービスイン後の当初の開発パートナー企業の担当者が在籍しているので、設計図を記憶しています。
しかし、何年か経過すると設計者が在籍していう保証はありません。
「ER図」「EER図」があれば、担当者・設計者以外の技術者が基幹システムの設計内容を把握でき、仕様変更に素早く対応できます。「ER図」「EER図」を導入している開発パートナーを選びましょう。
まとめ
「ER図」「EER図」はユーザーインターフェースとリレーショナルデータベースの各項目の構成図です。
リレーショナルデータベース構造を視覚的に表記するドキュメントファイルです。
ユーザーインターフェースの入力情報が伝達される経路を表記して、更新・格納するリレーショナルデータベースを多層化した構成図になっています。
以前は「データベース設計書」「入出力項目設計書」「ユーザーインターフェース仕様書」等の大量なドキュメントがありました。
「ER図」「EER図」の導入により、各種ドキュメント管理の工数が大幅に軽減化されています。
システム開発のITパートナー探しをされるのであれば
システム開発のITパートナー探しをされるのであれば「システム開発コンシェルジュ」で是非ご相談いただければと思います。
以下のフォームより開発でご相談いただきたい内容などご相談ください。
