データモデル

データモデルは、アプリケーション設計のための計画として使うソフトウェア工学の抽象モデルの1つである。班・要員間の意思疎通のための事業データの文書化、組織化、そして特にデータの格納方法や利用方法のために利用される。

Hobermanによれば、「データモデルは、組織内での意思疎通を改善し、それによってより柔軟で安定したアプリケーション環境に導く、真の情報の部分集合を正確に説明するシンボルとテキストの集合を使う、事業とIT専門家の両方のための、道筋を見つける道具である。」

データモデルは、データまたは//構造化データ//の構造を明示的に決める。データモデルの代表的な応用は、データベース・モデル、情報システムの設計、およびデータの交換を可能にすることを含む。通常データモデルは、データモデリング言語によって規定する。

コミュニケーションと精度は、データモデルがデータを使い交換する応用へもたらす2つの主要な利益である。データモデルは、異なる背景と異なる経験水準からなる事業要員がお互い意思疎通する媒体である。精度は、データモデルにおける用語と規則をただ1つの方法で解釈することができ、そして曖昧さが無いことを仮定する。

データモデルは、時には、特にプログラミング言語の文脈における、データ構造として参照する。データモデルは、エンタープライズモデルの文脈で、しばしば、機能モデルで補完する。

1. 概要
-----

大量の構造化されたデータや構造化されないデータを管理することは、情報システムの主要な機能である。データモデルは、リレーショナル・データベースのようなデータ管理システムでの記憶装置のための構造化されたデータを記述する。それらは、典型的に、ワードプロセッサ文書、電子メール、ピクチャ、音声あるいはビデオのような、非構造化データを記述しない。

1.1. データモデルの役割
--------------

データモデルの主な目的は、データの定義とフォーマットを提供することによって、情報システムの開発を支援することである。WestとFowlerによれば、「もしこれがシステムを通して一貫して行われたら、そこでデータの互換性が達成されうる。もし同じデータ構造がデータの格納やアクセスに使われるなら、そこで異なるアプリケーションがデータを共有できる。これの結果は上で示される。しかしながら、システムとインタフェースは、しばしば、構築し、運用し、そして維持するため、それらがあるべきより多くのコストを費やす。それらは、事業を支援するよりむしろ制約するかもしれない。1つの大きな原因は、システムとインタフェースに実装されるデータモデルの品質が貧弱だったことである。」

「どのように物事が、特定の場所で行われるかを特定する事業ルールはしばしばデータモデルの構造に固定化される。これは、事業を行う方法における小さな変化がコンピュータ・システムおよびインタフェースにおける大きな変更を導き出すことを意味する。」
「エンティティ・タイプは、多くの場合識別されないか、あるいは不正確に識別される。これは、データ、データ構造、および機能性の、その開発や保守における重複する付随的コストを伴う、重複を導きうる。」
「異なるシステムのためのデータモデルは任意的に異なる。この結果は、複雑なインタフェースが、データを共有するシステム間で要求される。これらのインタフェースは、現状システムのコストの25-70%の間で説明できる。」
「データは、データの構造や意味が標準化されていないので、顧客と供給者と電子的に共有することはできない。たとえば、プロセス・プラントのエンジニアリング・データと図面は、未だに時には紙ベースで交換されている。」これらの問題の理由は、データモデルが事業ニーズと一貫性を保つことの両方に合致することを確かにする標準が不足していることである。

1.2. 3つの観点
----------

データモデル//インスタンス//は、1975年のANSIに沿った3つの種類の1つかもしれない。

概念スキーマ：モデルのスコープである、1つのドメインの意味を記述する。たとえば、それは1つの組織あるいは産業の関心領域のモデルかもしれない。これは、そのドメインにおける重要なものの種類を表現するエンティティ・クラスと、一対のエンティティ・クラス間の関連について関連からなる。概念スキーマは、そのモデルを使って表されうる、事実と命題の種類を特定する。そのセンスで、それは、そのモデルのスコープによって限定される1つのスコープの、1つの人工的'言語'で許される表現を定義する。概念スキーマの利用は、事業ユーザーと共に強力なコミュニケーション・ツールとなるよう進化する。しばしば、「主題領域モデル」または「ハイレベル・データモデル」と呼ばれるこのモデルは、事業ユーザーが全体的アプリケーション開発または事業体イニシアティブの一部として、コア・データ概念、ルール、および定義をコミュニケートするのに使われる。オブジェクトのいくつかは、少なくかつ主要な概念に焦点を当てるべきである。大変大きな組織や複雑なプロジェクトのため、モデルは2ページ以上にまたがるかもしれないが、1ページにこのモデルを限定しようと試みる必要がある。
論理スキーマ：特定のデータ操作技術によって表現されるような、意味論を記述する。これは、他のものの間の、テーブルおよびカラム、オブジェクト指向クラス、およびXMLタグの解説からなる。
物理スキーマ：データが格納される物理的手段を記述する。これは、パーティション、CPU、表空間、あるいはそのようなことに係わる。ANSIによれば、このアプローチの重要性は、3つの観点がそれぞれ相対的に独立であることを可能にすることである。格納技術は、論理的あるいは概念モデルのいずれにも影響することなく変更できる。テーブル／カラム構造は、概念モデルに影響することなく変更できる。いずれの場合も、もちろん、その構造は他のモデルとの一貫性を残さなければならない。テーブル／カラム構造は、エンティティ・クラスや属性の直接変換からは異なるかもしれないが、しかし、それは究極的に概念エンティティ・クラス構造の目的の外で扱わなくてはならない。多くのソフトウエア開発プロジェクトの初期段階は、概念データモデルの設計を強調する。このような設計は、論理データモデルで詳細化される。その後段で、このモデルは、物理データモデルに変換されるかもしれない。しかしながら、概念モデルを直接実装することも可能である。

2. 歴史
-----

情報システムのモデリングにおける最も初期の業績の1つは、「情報を規定する正確で抽象的な方法とデータ処理問題の時間的特徴」を論じた、YoungとKentによって為された。彼らは、「ハードウエアのあらゆる部分を取り巻く問題のためのシステムアナリストに可能となるべき1つの表記法」を作ることを望んだ。彼らの作業は最初、異なるハードウエア・コンポーネントを使う異なる代替的実装を設計するための、1つの抽象仕様と不変の基盤を作る努力であった。情報システム・モデリングにおける次のステップは、「データ処理のシステム・レベルで、マシン独立の問題定義言語の正しい構造」を開発すると言う、本質的にYoungとKentと同じことを目指した、1959年に編成されたIT業界コンソーシアムである、CODASYLによって行われた。これが1つの特定な情報システムの情報代数学の開発に導いた。

1960年代にデータモデリングは、経営情報システム概念の導入と共に更にその重要性を増大させた。Leondesによれば、「必要なとき、情報システムは、管理目的のためデータと情報を提供する。このIntegrated_Data_Store と呼ばれる、第一世代データベースシステムが、GEのチャールズ・バックマンによって設計された。2つの有名なデータベース・モデル:ネットワーク型データモデル、および階層型データモデルがこの期間中に提案された。」1960年代の終わりに向けて、エドガー・F・コッドは、彼のデータ編成の理論を練り、一階述語論理に基づいたデータベース管理のためのリレーショナル・モデルを提案した。

1970年代に実体関連モデルが、1976年にピーター・チェンによって初めて提案され、概念データモデルの新しいタイプとして出現した。実体関連モデルは、データベースに格納される情報ニーズや情報のタイプを記述するための、要求分析中の情報システム設計の最初のステージで使われた。この技術は、あらゆる概念体系、すなわち、一定の関心の領域のための、概念の全貌と分類とそれらの関連、を記述できる。

1970年代、G.M. Nijssenは、「自然言語情報分析手法」を開発し、そして1980年代にそれを発展させたオブジェクト役割モデリングをTerry Halpinと一緒に開発した。

Jan L. Harringtonによれば、更に1980年代に、「オブジェクト指向パラダイムの開発が、我々がデータとデータに作用する手続きを見る方法に基本的な変化をもたらした。伝統的に、データと手続きは：データベースにデータとそれらの関連、アプリケーション・プログラムに手続きをと、別々に格納されていた。オブジェクト指向では、しかしながら、そのデータと共にエンティティの手続きを組み合わせた。」

3. データモデルのタイプ
-------------

3.1. データベース・モデル
---------------

データベース・モデルdatabase modelは、どのようにデータベースが構造化され、使われるかを記述する理論または仕様である。いくつかのそのようなモデルが提案されてきた。広く知られたモデルは以下を含む:

フラット・モデルこれは、厳密にはデータモデルとして認められないかもしれない。フラットモデルは、与えられたカラムの全要素が、同じような値であり、そして1つの行の全要素が互いに関連していると想定される、データ要素の単一の2次元配列で構成される。
階層型データモデル：このモデルにおけるデータは、それぞれ同じレベルのリストに特定の順序でレコードを保持するネスト化と並べ替えフィールドを記述するそれぞれのレコードへの単純な上昇リンクを暗示する、ツリー構造に組織化される。
ネットワーク型データモデル：このモデルは、レコードとセットと呼ばれる、2つの基本的概念を使うデータを組織化する。レコードはフィールドを含み、セットはレコード間の、1は所有者、多はメンバーである、1対多の関連を定義する。
リレーショナル・モデルは、一階述語論理に基づくデータベース・モデルである。その中核アイデアは、とりうる値と値の組み合わせへの制約を記述する、有限個の述語変数を持つ述語の集合としてデータベースを記述することである"Takahama1978"。
スタースキーマは、データ・ウエアハウス・スキーマの最もシンプルなスタイルである。スタースキーマは、いくつかの「事実テーブル」がどんな数の「次元テーブル」を参照する。スタースキーマは、重要な雪形スキーマの特別なケースと考えられる。

3.2. データ構造ダイアグラム
----------------

データ構造ダイアグラムは、エンティティとそれらの関連、およびそれらを拘束する制約を文書化する図式表記法を提供するよって、概念データモデルを記述するため使われる1つのダイアグラムでありデータモデルである。DSDの基本的図形要素は、エンティティを表すボックスと、関連を表す矢である。データ構造ダイアグラムは、複雑なデータ・エンティティを文書化するため最も有用である。

データ構造ダイアグラムは、実体関連モデルの1つの拡張である。DSDで、関連が、エンティティ群を束ねる制約を規定する属性から構成されるボックスとして描かれる一方で、属性は、エンティティの、外側でなく、内側で規定される。実体関連モデルは、堅牢である一方で、関連同士の制約を規定する方法を提供せず、そして、いくつかの属性を持つエンティティを表現するとき視覚的に扱い難くなる。DSDは、DSDが1つのエンティティ内での要素の関連に焦点を当て、そしてユーザーに各エンティティ間のリンクと関連を完全に見せることができるのに対して、実体関連モデルでは異なるエンティティ間の関連に焦点を当てる点で、異なる。

データ構造ダイアグラムを表現するため、多重度を定義する方法に顕著な違いを伴う、いくつかのスタイルがある。選択は、鏃、逆向き鏃、あるいは多重度の数値表現の間に存在する。

3.3. 実体関連モデル
------------

実体関連モデルは、構造化されたデータを表現するためソフトウエア工学で使われる、1つの抽象概念スキーマである。実体関連モデルのため使われるいくつもの表記法が存在する。

3.4. 地理的データモデル
--------------

地理情報システムにおけるデータモデルは、データとして地理的オブジェクトまたは地表を表現するための数学的概念である。たとえば、以下のような例がある。

ベクターデータモデルは、点、線、および多角形の集合として地形を表現する
ラスターデータモデルは、数値を格納するセル・マトリックスとして地形を表現する
そして不規則三角網データモデルは、連続、非重複の三角形のセットとして地形を表現する

3.5. 汎用データモデル
-------------

汎用データモデルは、通常のデータモデルの一般化されたものである。それらは、そのような関係タイプによって関連付けられるかもしれないものの種類と一緒に、標準化された一般の関係タイプを定義する。汎用データモデルは、従来のデータモデルの欠点を解決する1つのアプローチとして開発された。例えば、異なるモデラーは一般に、同じドメインの異なる従来のデータモデルを作り出す。これは、異なる人々のモデルを一緒に集めることにおいて困難を導き、そしてデータ交換やデータ統合の障害である。しかしながら、この違いはいつも、モデルにおける抽象レベルの違いと、インスタンス化される事実の種類における違いに帰因する。モデラーは、違いをより重要でないものにするため、より具体的に提示すべきである一定の要素についてコミュニケートし合意する必要がある。

3.6. 意味的データモデル
--------------

ソフトウェア工学における意味的データモデルは、その他のデータとの相互関係性の文脈内でのデータの意味を定義する1つの技法である。意味的データモデルは、どのように格納シンボルがその実世界に関係させるかを定義する1つの抽象である。意味的データモデルは、時には、概念データモデルと呼ばれる。

階層型、ネットワーク型データモデル、あるいはリレーショナル であろうと、データベース管理システムの論理的データ構造は、それがスコープとDBMSによって採用される実装戦略への偏った方向における限界があることから、データの概念的定義への要求を完全に満たすことはできない。そこで、概念的ビューからデータを定義する必要性が、意味的データモデリング技法の開発に導いた。それは、他のデータとの相互関係性の文脈内でのデータの意味を定義する技法である。図に示されるように。資源、アイデア、イベント、などの条項で、現実世界は、物理的データ・ストア内でシンボル化されて定義される。意味的データモデルは、どのように格納されるシンボルを実世界に関係させるかを定義する1つの抽象である。そこで、そのモデルは実世界の真の表現でなければならない。

4. データモデルのトピックス
---------------

4.1. データアーキテクチャ
---------------

データアーキテクチャは、目標状態の定義に使われるデータの設計であり、かつ目標状態に合致させるため必要とされる次に続く計画である。それは普通、ビジネスアーキテクチャ、またはソリューション仕組の芯柱を形成するいくつかの仕組ドメインの1つである。

データアーキテクチャは、事業あるいはそのアプリケーションによって使われるデータ構造を記述する。データの格納と動きの2つの記述がある。格納におけるデータ記述はデータ・グループとデータ項目を記述し、動きにおけるデータの記述はデータの品質、アプリケーション、場所などへのそれらデータ創作物のマッピングを記述する。

目標状態を実現する上で必須な、データアーキテクチャの記述はどのようにデータが、与えられたシステム内で、処理され、格納され、取扱われるかである。それは、そのシステム内での、データ・フローを設計し、データの流れをコントロールすることも可能にするデータ処理運用のための基準を提供する。

4.2. データモデリング
-------------

ソフトウエア工学における データモデリングは、データモデリング技法を使って公式のデータモデル記述を適用することによるデータモデルを作成するプロセスである。データモデリングは、データベースのための事業要求を定義するための1つの技法である。それは時には、1つのデータモデルがやがて1つのデータベースに実装されることから、//データベース・モデリング//と呼ばれる。

図は、今日のデータモデルが開発され、そして使われる方法を描いている。概念データモデルは、開発されているアプリケーションのためのデータ要求に基づき、おそらくアクティビティ・モデルの文脈で開発される。そのデータモデルは通常、エンティティ・タイプ、属性、関連、完全性ルール、およびそれらのオブジェクトの定義から成る。これは、そこでインタフェースまたはデータベース設計のためのスタート・ポイントとして使われる。

4.3. データ特性
----------

要求に合致するに必要なデータのいくつか重要な特性は:

定義関連の特性
//関連性//: あなたの事業の文脈でのそのデータの有用性。
//明快さ//: そのデータの明快で共有される定義の利用性。
//一貫性//: 異なる情報源からのデータのタイプの互換性。

内容関連の特性
//適時性//: 要求される時のデータの利用可能性と、どのようにデータが更新されるか。
//正確さ//: どのようにそのデータが真実に近づくか。
定義と内容の両方に関連する特性
//完全性//: どれだけ要求されるデータが利用可能か。
//アクセス性//: どこで、如何に、誰に、データが利用可能であり、可能ではないか(すなわちセキュリティ）