第2回 データモデルの分類

  前回 はデータモデルを作成する意義について紹介いたしました。

 情報システムを構築する現場では、企画や要件定義、データベースの設計など開発工程の様々なシーンでデータモデルが登場します。データモデルを情報システム構築のための「共通言語」と位置づけ、情報システム構築の初めから終わりまで常に同じデータモデルを活用するのが理想ですが、実際には開発工程の進捗に合わせて以下のデータモデルを使い分けることが多いと思われます。

 ・概念データモデル

 ・論理データモデル

 ・物理データモデル

 これらのデータモデルはデータ構造を表現する観点や抽象度を基準に区別されますが、明確な定義はなく人により様々に解釈されます。今回は筆者の経験をもとに、それぞれの概要を、活用法や作成のアプローチも踏まえながら紹介したいと思います。

1. 概念データモデル

 概念データモデルとは、例えばバリューチェーン上の多くの局面で登場するような、事業における主要なデータと、その主要データ間の関係のみに着目して表現されるデータモデルです。

図1.概念データモデルの例

 

 第1回の説明で現実の事業(業務)をデータモデルに正しく反映する意義を紹介いたしましたが、前述の定義に従えば、概念データモデルは事業を正確に反映したものとは言えません。概念データモデルの対象となる主要なデータ(エンティティ)の選択や表現の抽象化など、データモデルを作成する人の意思が混入してしまうためです。
 一方で、主要なデータのみに着目して表現されたデータモデルは、複雑で例外処理なども多い現実の事業を網羅したデータモデル(後述の論理データモデル)と比較するとシンプルであり、俯瞰性が高くデータ構造をイメージしやすくなるメリットがあります。例えば、情報システムの企画フェーズで事業のデータ構造を俯瞰し、共有するための「世界地図」と位置付ける、または新たな業務を情報システム化するにあたってデータ構造を詳細に検討する前の方針(コンセプト)決めに有効活用することができます。
 概念データモデルは、データモデルの記述をトップダウン(あるべきデータ構造の方向性を最初に決めてから細部を詰めるアプローチ)で進める際に有効です。

2. 論理データモデル

 論理データモデルとは、データベースへの実装を意識せずに現実の事業(業務)を正確に反映したデータモデルです。データ構造の冗長性が排除されており、「1つの事実(データ)は1か所で管理する(One Fact in One Place)」が実現されているデータモデルです。

図2.論理データモデルの例

 

 論理データモデルでは、「事実(Fact)と一致して正しい(真である)」ということが重要になります。この「事実」とは、データモデル化の対象とする事業や業務を指します。通常「事実はひとつ」ですので、現実の事業や業務を表す論理データモデルも当然ひとつでなければなりません。
 この「事実」は、実際に業務で使用している情報システムの画面や帳票を分析することで捉えることができ、要件定義フェーズにおいて精度を高めていくのが一般的です。捉えた事実をもとにデータモデルを作成し、あるべきデータ構造を決めていくことになります。なお、このようなデータモデル作成方法をボトムアップアプローチと呼びます。

3. 物理データモデル

 物理データモデルとは、開発フェーズにおけるデータベースへの実装を目的としたデータモデルです。
 論理データモデルが事業(業務)を「正しく」表現したものであれば、論理データモデルからデータベースを実装すれば、事業を正しく反映したデータベース(情報システム)が出来上がります。しかしデータベースの処理性能に対する考慮などから、論理的に矛盾のないデータモデルにあえて冗長性を持たせて実装することなどは、システム開発の現場ではよく見られることです。また、期間短縮のために物理データモデルのみを作成して、情報システムを構築するケースも見受けられます。
 重要なことは、論理データモデルを記述しないまま、いきなり実装を目的とした物理データモデルを記述しないことです。論理データモデルを記述しないということは、何が事実(Fact)と一致した正しい(真である)姿かを把握しないまま情報システムを構築することと同じだからです。

 データモデルの観点がイメージ頂けましたでしょうか。 次回は「データモデルの表記法」 について紹介いたします。