データモデリング

データモデリングの最大の目的は、組織内のビジネスプロセスを適切にサポートするためのデータ要件を分析し、定義することである。専門のデータモデラーがビジネスのステークホルダーや潜在的なユーザーと協働して構築するデータモデルは、ビジネスアナリストやプログラマー、マネージャーなどの関係者間で、組織の概念や相互関係に関する共通理解を形成する「合意された準形式的なモデル」として機能する。これにより、不必要なデータの重複が排除されて関連するデータ構造が包括的な概念にまとめられ、データを組織の共通リソースとして効率的に管理することが可能となる。さらに、システム全体で一貫したデータ構造が用いられることで、データの互換性が保たれ、異なるアプリケーション間でのシームレスなデータ共有や情報システムの統合が容易になるという利点をもたらす。

一方で、データモデリングが不十分な場合、システムやインターフェースの構築および保守において多大なリスクとコストを招く要因となる。適切に設計されていない質の低いデータモデルは、ビジネスをサポートするどころか逆に制約してしまう。

• 特定の場所でのやり方に特有のビジネスルールが、データモデルの構造に固定（ハードコーディング）されていることが多い。これは、ビジネスの進め方の小さな変更が、コンピュータシステムやインターフェースの大きな変更につながることを意味する。したがって、ビジネスルールは複雑な依存関係を生じさせない柔軟な方法で実装される必要があり、データモデルはビジネスの変更を比較的迅速かつ効率的に実装できるように柔軟性を持つべきである。
• エンティティタイプが特定されていないか、不正確であることが多い。これにより、データ、データ構造、機能の複製が発生し、無駄な開発・保守コストを増大させる。したがって、誤解や重複を最小限に抑えるために、データの定義は可能な限り明示的で分かりやすくする必要がある。
• 異なるシステムのデータモデルが勝手に異なっている。その結果、データを共有するシステム間に複雑なインターフェースが必要になる。これらのインターフェースは、現在のシステムのコストの25%から70%を占めることがある。データモデルを設計する際には、必要なインターフェースを本質的に考慮すべきである。
• データの構造と意味が標準化されていないため、顧客やサプライヤーと電子的にデータを共有できない。実装されたデータモデルから最適な価値を得るためには、データモデルがビジネスニーズを満たし、一貫性を保つための標準を定義することが非常に重要である^[1]。

データモデリングの主要な対象範囲は、組織のビジネスプロセスを駆動するために必要な「構造化データ」である。関係データベース（RDB）に格納されるような、事前に定義された明確なスキーマ（列やデータ型）を持つ情報がこれに該当する。

一方で、現代では非構造化データ（ワードプロセッサで作成する文書や電子メールのメッセージ、画像、デジタル音楽、デジタル動画など）が急増している。これらの非構造化データについて、「コンテンツそのもの」はデータモデリングの対象外となるが、これらのデータが持つメタデータについては、モデリングの対象範囲に含めることがある。

1975年、ANSI（米国国家規格協会）のSPARC委員会によって「3層スキーマアーキテクチャ」というデータモデルのインスタンスが提示された。要件定義から実際のデータベース構築へと進む過程において、視点や抽象度の異なる3種類のデータモデル（スキーマ）を作成し、これにより、ビジネスの要件と技術的な実装を分離して管理することが可能になる^[2]。

• 概念スキーマ：ドメイン（モデルの範囲）のセマンティクスを記述する。例えば、組織や業界の関心領域のモデルである。これは、ドメインにおいて重要な事物の種類を表すエンティティクラスと、エンティティクラスのペア間の関連に関するリレーションシップ宣言で構成される。概念スキーマは、モデルを使用して表現できる事実や命題の種類を指定する。
• 論理スキーマ：情報の特定のドメインの構造を記述する。これには、テーブル、カラム、オブジェクト指向クラス、XMLタグなどの記述が含まれる。論理スキーマと概念スキーマは、同一のものとして実装されることもある。^[3]
• 物理スキーマ：データの保存に使用される物理的な手段を記述する。これは、パーティション、CPU、表領域などに関係する。

上記の3層スキーマアーキテクチャで重要なのは、先述した3つの視点のおのおののモデルが、互いに比較的独立していることである。

例えば、ストレージの物理的な技術やハードウェア（物理スキーマ）が変更されても、論理スキーマや概念スキーマに影響を与えない。同様に、パフォーマンス向上のために論理スキーマのテーブル構造を変更したとしても、それが必ずしも概念スキーマ（ビジネスの本来の意味）に影響を及ぼさない。

実際には、当然ながら、スキーマの構造は、他のスキーマに対して一貫性をもっている必要がある。各モデルは細部で異なる形（抽象化や最適化）をとることはあっても、システム全体を通してすべてのスキーマ間で構造の一貫性を保つことが不可欠である。多くのソフトウェア開発プロジェクトの初期の開発工程では、概念データモデルの設計が重要である。続く工程で、概念データモデルは、論理データモデルの形に詳細化することができる。その後の工程で、場合によっては論理データモデルは物理データモデルに変換される。しかしながら、場合によっては、概念モデルを直接に実装することもできる。

ビジネスプロセス統合の文脈において、データモデリングはビジネスプロセスモデリングを補完し、最終的にデータベースの生成につながる^[4]。

データベースを設計するプロセスでは、前述の3種類のスキーマ（概念、論理、物理）を作成する。これらのスキーマに文書化されたデータベース設計は、データ定義言語（DDL）を通じて変換され、データベースの生成に使用される。完全に属性化されたデータモデルには、その中のすべてのエンティティの詳細な属性（記述）が含まれる。「データベース設計」という用語は、データベースシステム全体の設計の多くの異なる部分を指すことがある。主に、データの保存に使用される基本データ構造の論理設計と考えるのが最も正確である。リレーショナルモデルでは、これらはテーブルとビューである。オブジェクトデータベースでは、エンティティとリレーションシップがオブジェクトクラスと名前付きリレーションシップに直接マップされる。

データモデルは関心のある情報領域を表す。データモデルを作成する方法は数多くあるが、Len Silverston (1997)^[5] によれば、トップダウンとボトムアップの2つのモデリング手法が際立っている。

• ボトムアップモデル（またはビュー統合モデル）：リエンジニアリングの成果であることが多い。これらは通常、既存のデータ構造、フォーム、アプリケーション画面上のフィールド、またはレポートから始まる。これらのモデルは通常、物理的でアプリケーション固有であり、エンタープライズアーキテクチャの観点からは不完全である。組織の他の部分を参照せずに構築された場合、データ共有を促進しない可能性がある^[5]。
• トップダウン論理データモデル：対象分野を知っている人々から情報を得ることで、抽象的な方法で作成される。システムは論理モデル内のすべてのエンティティを実装しない場合もあるが、モデルは参照ポイントやテンプレートとして機能する^[5]。

時には、アプリケーションのデータニーズと構造を考慮しつつ、サブジェクトエリアモデルを一貫して参照するという、2つの方法を混合してモデルが作成されることもある。多くの環境では、論理データモデルと物理データモデルの区別が曖昧である。また、一部のCASEツールは論理モデルと物理モデルを区別しない^[5]。

データモデルの設計のためにいくつかの技法が開発されている。主なものは以下の通りである。

• 実体関連モデル (ERモデル)/実体関連図 (ER図)
• 統一モデリング言語 (UML)
• 階層型データモデル
• ネットワーク型データモデル
• 関係モデル
• オブジェクト関係モデル
• オブジェクトモデル
• IDEF1X
• バッハマン図（バックマン線図）
• バーカー表記法/チェンの表記法
• オブジェクトロールモデリング（ORM/NIAMen:Object role modeling）
• リレーショナルモデル (en:Relational Model/Tasmania)
• データヴォルトモデリング
• オブジェクトリレーショナルマッピング（ORM）
• 拡張バッカス・ナウアフォーム（EBNF）
• ビジネスルール・アプローチ (en:Business rules approach)

DBMSの論理データ構造は、階層型、ネットワーク型、リレーショナルのいずれであっても、範囲が限定され、DBMSが採用する実装戦略に偏っているため、データの概念的な定義の要件を完全に満たすことはできない。

したがって、概念的な視点からデータを定義する必要性が、意味データ（セマンティックデータ）モデリング技法の開発につながった。つまり、他のデータとの相互関係の文脈の中でデータの意味を定義する技法である。図に示されているように、資源、アイデア、イベントなどの観点からの現実世界は、物理的なデータストア内での記述によって象徴的に定義される。意味データモデルは、保存された記号が現実世界とどのように関連しているかを定義する抽象化である。したがって、モデルは現実世界の真の表現でなければならない。^[6]

意味データモデリングの目的は、「対象世界」と呼ばれる現実世界の一部の構造モデルを作成することである。このために、3つの基本的な構造的関係が考慮される。

• 分類/インスタンス化：構造的に類似したオブジェクトをクラスのインスタンスとして記述する。
• 集約/分解：構成されたオブジェクトを、その部品を結合することによって取得する。
• 一般化/特化：共通の特性を持つ異なるクラスを、共通の属性を持つより一般的なクラスで再考する。

ジェネリックデータモデルは、従来のデータモデルを汎用化したものである。「事物（Thing）」と「関係（Relation）」という根本的な概念を組み合わせることで、世の中のあらゆる事象を表現しようとするアプローチである。

具体的には、「分類関係」や「全体-部分関係」といった標準化された関係型を定義する。

• 分類関係 - ある特定の事物と、その事物が属する事物の種類（クラス）との間を結びつける二項関係のことである。
• 全体-部分関係 - 部分の役割を担う事物と全体の役割を担う事物の間を結びつける二項関係である。

こうした方法をとり、事物の種類（クラス）や関係型の拡張可能なリストを標準化して持つことで、無数の事象を分類・表現できるようになり、自然言語が持つ表現能力の水準に近づくことができる。データモデルに柔軟性をもたせ、アプリケーションソフトウェアのスコープの変更があったときにも、データモデルの変更を抑制することができる。

従来のデータモデルでは、対象範囲が固定されており、設計時に定義された事物しか表現できない。

例えば、同じ領域に対して従来のデータモデルによるモデリングを複数の人々が行う場合、それぞれ異なるデータモデルを作ってしまうことが多い。このため、複数の人々が共同でモデルを作る場合の困難につきあたる。こうした状況は、データ交換やデータ統合を行う観点からは、障害となる。そして、同じ領域に対してデータモデルが異なっているのは、いつも、モデルの抽象化の水準が異なることと、 (モデルの意味的な表現能力により) インスタンス化することが可能な事物の種類の相違が、原因となっている。

こうした相違を小さくするために、モデリングをする人々は、意思疎通をし、より具体的に表現するべくいくつかの要素について合意をする必要がある。

優れたデータモデルを構築するためには、人物と組織の上位概念（パーティ）、製品タイプ、製品インスタンス、アクティビティタイプ、アクティビティインスタンス、契約、地域、サイトなどの「汎用的なパターン」を明示的に含めることが有用である。

さらに、領域に固有な知識は、他の実体とは切り離された「クラス（参照データ）」の標準的なインスタンスとして表現する。例えば、自動車、車輪、建物、船、温度、長さなどの概念は独立した標準インスタンスとして扱われる。また、「—から構成される」や「—に参加する」のような標準的な関連の実体もまた、標準的なインスタンスである。

ジェネリックデータモデリングは、主に以下の規則に従う。

• 属性や、アクティビティ・イベントによる影響は、すべて「実体（エンティティ）」や他との「関連（リレーション）」として表現する。
• 実体が同定されると、その事物の本質的な性質に基づいて命名される。特定の文脈で果たす役割（ロール）に基づいて命名されるのではない。
• 実体は、データベースあるいはデータ交換のためのファイルの中に、局所的な識別子をもつ。こうした識別子は、人工的なものであり、一意となるように管理される。局所的な識別子に関連（リレーション）を含めない。
• すべての実体および関連（リレーション）は、普遍的な文脈を定義するために、サブタイプ/スーパータイプの階層の一部を構成する。
• 関連（リレーション）は、特定の用途に縛られない関連は最も汎用的な水準で定義する。
  • 例えば、「AはBから構成される（コンポジション）」という関連を作るとき、従来のように「『注文』は『注文明細』から構成される」といった具体的なデータ同士の結びつきとしては定義しません。代わりに、「『ある事物』は『別の事物』から構成される」というように、あらゆる事柄に適用できる抽象的な枠組みとして定義します。これにより、1つの関連ルールを様々な場面で使い回すことができます。
  • 「参照データ」で、どの実体と実体の間に関連を制約することができる。制約（ルール）を実体間の関連の標準的なインスタンスとして定義・管理することで、柔軟性とデータの正確性を両立させている。

• ISO 10303-221
• ISO 15926 (en:ISO 15926)
• Gellish (en:Gellish)
• Gellish English (en:Gellish English)

データモデルは、単にコンピュータシステムにデータをどう保存するかを決めるものだけではない。対象となるビジネス領域の構造そのものを記述し、その領域専用の「言語の文法」を規定する役割を持つ。

データモデルによって表現される実体は、有形物など具象的なものではなく、実体の抽象を用いることが重要である。これは、具象的な実体クラスを含むデータモデルは、時間の経過とともに変更を余儀なくされる傾向があるからである。例えば、「売り手」や「従業員」といった人々が果たす特定の役割をそのまま具象的な実体クラスとするよりも、「人物」という抽象的な実体クラスを定義し、組織と相互作用する全ての人物を表現する方が適切となることが多い。

データモデルを設計することは、トランザクションデータ（一つまたは複数の参照用データを参照するデータ）と参照用データを区別する上でも役立つ。適切に設計された概念データモデルは、対象領域の意味的な側面を記述し、一つまたは複数の組織によって使われる情報の性質に関する「表明」の集合として機能する。

実体クラスの集合には、わかりにくい技術用語ではなく、自然言語の単語を使って名前がつけるべきである。これにより、データモデルは組織内で使われる情報の性質を表す「表明（明確なルール）」として機能する。

関連の命名においても同様であり、自然言語を用いて命名する。例えば、「注文」（実体クラス）と「注文明細」（実体クラス）の間に「—から構成される」(is composed of)という関連を定義すれば、「おのおのの『注文』は一つもしくは複数の『注文明細』から構成される」という表明が成り立つ。より厳格には、「—なければならない」 (must be) や「—可能性がある」 (may be) といった動詞を伴う形で関連を命名することで、実体クラスのインスタンスの個数（濃度）や属性の数（次数）を意味的に扱うことができる。これにより、「おのおのの『注文』は、一つもしくは複数の『注文明細』から構成される可能性がある」あるいは「構成されなければならない」といったように、関連を正しく読み解くことが可能となる。

ジェネリックデータモデリングのデータモデリングの文献

• David C. Hay. 1996. Data Model Patterns: Conventions of Thought. New York:Dorset House Publishers, Inc. ISBN 978-0932633293
• Matthew West, Julian Fowler Developing High Quality Data Models
• Generic Data Modeling
• Gellish English
• Gellishの辞書とGellishについての文書群
• C. J. Date. 1986. "A Practical Approach to Database Design" in Relational Datebase: Selected Writings ISBN 978-0201141962
• American National Standards Institute. 1975. ANSI/X3/SPARC Study Group on Data Base Management Systems; Interim Report. FDT(Bulletin of ACM SIGMOD) 7:2.
• Len Silverston. 2001. The Data Model Resource Book. John Wiley & Sons ISBN 0-471-38023-7