データベース - ER図
概要
一般的に、DAが概念データモデルと論理データモデルを作成して、DBAが物理データモデルを作成する。
しかし、アプリケーションの規模やプロジェクトの事情によっては、論理データモデルからDBAが担当することもある。
概念データモデル
概念データモデルは、対象業務の現実の世界を対象としており、
「データにはどのような意味があるのか？」という視点から、意味的な集まりを見いだすことでグループ化、およびグループ間の関連付けを行い、概念データモデルを作成する。
実際には、ユーザからの要求や既存システムの画面や帳票等からデータ項目を洗い出して、
アプリケーションの範囲やシステムの範囲ではなく、業務の中で扱っている全てのデータを扱う。 （コンピュータで記憶されるデータ以外のものも含める）
概念データモデルは、決して概念レベルのものを扱っているだけではない。
既存システムの画面や帳票等からデータ項目を洗い出すのは、業務機能が変更されてもそこで扱われるデータは継続して利用される場合がほとんどだからである。
これが、データを中心にして考えるメリットである。
例えば、製造業のシステムを開発することが目的での場合においても、製造業のシステム領域以外のデータであれば他の会計システムや生産管理システムも扱うデータの対象となる。
他のシステムとのインターフェイスまで含めた広い範囲のモデルを構築することが重要である。
その方法として、既存システムの画面や帳票等からデータを集めること （ボトムアップアプローチ） は必要であるが、
経営層まで参画させて、企業として将来像 （ゴール） を決定すること （トップダウンアプローチ）も必要である。
将来像が決定すれば、自ずと必要なデータも見えるからである。
たとえデータモデルが安定している場合でも、データのライフサイクルが短いのでは元も子もない。
企業の変革のスピードが速い時代だからこそ、先を見据えた安定的なデータモデルの構築が企業競争力に繋がるといえる。
概念データモデルを作成する場合は、ER図 （ERD ： entity-relationship diagram） が用いられることが多く、概念データモデルを表現したER図は概念ER図と呼ばれる。
ER図では、「意味的な集まり」を「エンティティ」と呼び、「グループ間の関連付け」を「リレーションシップ」と呼ぶ。
論理データモデル
論理データモデルは、概念データモデルで洗い出したデータ項目の内、ユーザにシステム化を期待される範囲でコンピュータに記憶される永続的なデータを対象としたデータモデルである。
論理データモデルには、4つのデータモデルタイプ （階層型、ネットワーク型、リレーショナル型、オブジェクト型） がある。
データ構造を最も表現しやすいタイプに当てはめて論理データモデルを作成する。
ER図は、この論理データモデルのリレーショナル型である。
一般的に、データベースの実装方式がリレーショナルデータベースであることを前提として、論理データモデルのタイプにリレーショナル型を選択している。 (※備考を参照)
リレーショナル型の表記には、ER図を使用する。
論理データモデルを作成する場合は、リソース系エンティティおよびイベント系エンティティの切り出し、それらのリレーションシップを整理する。
また、エンティティ内に詳細な属性を定義して、コード設計により体系化する。
さらに、概念ER図とは異なり、データがコンピュータに蓄積されることを考慮するため、システム的に重複や無駄の無いデータ管理を実現するため、正規化を行う。
以下に、論理データモデルの作成における重要な事柄を示す。
- システム化の範囲において、コンピュータに記憶される永続的なデータを対象とする。
- 概念ER図のエンティティを、リソース系エンティティとイベント系エンティティに切り出す。
- システム的に重複や無駄の無いデータ管理を実現するため、正規化を行う。
- 論理データモデルは、ER図で表す。
※備考 論理データモデルはデータベースの実装方式とは独立している。 論理データモデルをリレーショナル型で作成することと、データベースの実装方式としてリレーショナルデータベースを採用することは等価ではない。 あくまでも、論理データモデルのデータ構造の表現形式の1つとしてリレーショナル型があり、論理データモデルは実装方式には依存せず、独立した関係にある。 しかし、現実的には論理データモデルのタイプにデータベースの実装方式を一致させることは設計において非常に効率が良く、一般的に行われている。 例えば、論理データモデルのリレーショナル型の表記に使われるER図は、リレーショナルデータベースの実装にマッピングしやすい。 （エンティティ → テーブル、リレーションシップ → リレーションシップ） 設計フェイズにおいて、一貫してER図を使用することにより、見通しの良いモデリングを行うことができる。 要件としてデータベースの実装方式がリレーショナルデータベースであることがあらかじめ判明している場合は、あえて論理データモデルのタイプに階層型やネットワーク型を採用することはない。
物理データモデル
物理データモデルは、使用する本番環境 （ハードウェアも含む） の特性を考慮して論理データモデルを物理データモデルへ変換する。
物理データモデルの設計段階において、初めて、ソフトウェアとしてのデータベースを選定する。
多くの場合、リレーショナルデータベースが採用されるため、Oracleデータベース、SQL Server、MySQL等の具体的なRDBMSへの実装を目的とした物理データモデルを作成する。
したがって、物理データモデルは各データベース製品の機能に依存するため、
ある単一システムを設計する場合に概念データモデル : 論理データモデル ＝ 1 : 1であるが、
論理データモデル : 物理データモデル = 1 : N （実装するデータベース製品の種類）という特徴がある。
物理データモデルの作成では、データ型の定義、ビューの定義、インデックス設計および定義、各種のパラメータ設定等の物理的な環境に依存した物理データモデルを作成する。
また、非機能要件としてのパフォーマンスチューニング等 （データ容量、表領域の計算） の調整もここで行う。
検索等のパフォーマンスを考慮して、非正規化を行うこともある。 (非正規化は、必ず実施するわけではないことに注意する)
物理データモデルの作成において、重要なことを以下に示す。
- RDBMS全般の知識、製品固有のデータベースの知識を駆使する。
- インデックス設計を行う。
- 必要であれば、非正規化を行う。
- 非機能要件としてのパフォーマンスチューニング」を行う。
