データモデリング
データモデリング(data modeling)は、コンピュータ科学の文脈では、何らかのデータモデリング方法論を適用してデータモデルのインスタンスを作る過程である。
データモデリング方法論は、データモデリングを形式的に記述したものである。
現在までに考案されたデータモデルの種類としては、次のようなものがある。
データモデリングを行う際には、データを構造化し組織化する。
こうして作成されたデータ構造は、その後にデータベース管理システム (DBMS) を使って実装されることが多い。
データモデリングの過程では、データを定義し組織化することに加えて、構造化したデータに対して (暗黙的もしくは明示的に) 制約の集まりを同定する。
大容量の構造化データおよび大容量の非構造化データを管理することは、情報システムの主要な機能である。
データモデルは、関係データベース管理システム (RDBMS) のようなデータ管理システムにおいて、記憶装置に永続化される構造化データを記述する。
データモデルは、非構造化データ——ワードプロセッサで作成する文書や電子メールのメッセージ、画像、デジタル音楽、デジタル動画など——については記述しないことが多い。
データモデリングの例については、次の節を参照。
データモデルのインスタンスには、ANSIによれば次の3種類がある。
概念スキーマ (データモデル) は、モデリングの対象となる領域の意味的な側面を記述する。例えば、何らかの組織もしくは業界のある側面のモデルを概念スキーマとして記述できるであろう。概念スキーマは、実体クラスと関連の集まりから構成される。実体クラスは、対象領域において重要な概念を表現する。関連は、2つの実体クラスの間の結びつきである。概念スキーマは、モデルを使って表現することができる事物などを同定する。一般的に適用できるモデルについては、#汎用データモデルの節で述べる。
論理スキーマ (データモデル) は、モデリングの対象となる領域の意味的な側面を、データを扱うための何らかの技術を使って、表現したものである。論理スキーマは、関係モデルにおける関係 (表、テーブル) と属性 (列) や、オブジェクト指向におけるクラス、XMLの要素 (タグ) と属性などから、構成される。
物理スキーマ (データモデル) は、データが永続化される物理的な方法を記述したものである。物理スキーマは、パーティションやCPU、表スペースなどに関連する。
こうしたANSIによる方法で重要なのは、先述した3つの視点のおのおののモデルが、互いにある程度独立していることである。
論理スキーマにおける関係 (表) と属性 (列) は、概念モデルに必ずしも影響を与えることなく、変更することができる。
実際には、当然ながら、スキーマの構造は、他のスキーマに対して一貫性をもっている必要がある。
論理スキーマにおける関係 (表) と属性 (列) は、概念モデルにおける実体クラスと属性を直接的に変換した結果とは、異なることがある。
しかし論理スキーマは、最終的には、概念モデルの実体クラスの構造の目標を満足させる必要がある。
多くのソフトウェア開発プロジェクトの初期の開発工程では、概念データモデルの設計が重要である。
続く工程で、概念データモデルは、論理データモデルの形に詳細化することができる。
その後の工程で、場合によっては論理データモデルは物理データモデルに変換される。
しかしながら、場合によっては、概念モデルを直接に実装することもできる。
個々の事例では、細部では異なることがあっても、モデルインスタンスの構造は、他のモデルインスタンスと整合している必要がある。
論理データモデルにおける関係 (表、テーブル) と属性 (列) の構造は、概念データモデルにおける実体クラスと関連と属性を直接的に変換したものとは、異なっていることがある。
しかし論理データモデルは、最終的には、コンテクストの水準のデータモデルにおける実体クラスの構造と、概念データモデルにおける関連の構造の、それぞれの目標を満足させる必要がある。
論理データモデルが作成された後の工程では、データを保存するプラットフォームが決まると、論理データモデルは物理データモデルに変換することができる。
そして物理データモデルをもとにして、データの定義が作られる。
データベースに実際にデータが格納されて運用されると、データベースに対するデータ操作 (照会、更新など) を行うことができる。
データモデルは、対象とする領域におけるデータの構造を記述し、また結果としてその領域自体の基礎となる構造を記述する。
これは、データモデルは、対象とする領域のための専用の人工言語の文法を、実際に規定しているということを意味する。
データモデルは、実体のクラス (事物の種類) の集合を表現する。
対象となる組織は、実体クラスの集合について、情報と情報の属性と実体間の関連と属性間の関連を、保持して管理しようと考える。
データモデルは、データをコンピュータシステムで表現する方法とはあまり関係ない形で、データを組織化して記述する。
データモデルによって表現される実体は、有形物の実体である場合がある。
しかしそうした具象的な実体クラスを含むデータモデルは、時を経ると、モデルが変更される傾向がある。
堅牢なデータモデルでは、そうした実体の抽象を同定することが多い。
例えば、あるデータモデルでは「人物」という名前の実体クラスを含んでいるかもしれない。
そのデータモデルにおける「人物」の実体は、ある組織と相互作用する全ての人物を表現する。
このような抽象的な実体クラスは、多くの場合、「売り手」や「従業員」という名前の具象的な実体クラスと比べて、適切である。
なおここで、「売り手」や「従業員」の実体クラスは、そうした人々によって行われる特定の役割を同定している。
一部の人々は、データモデルを設計することは、トランザクションデータと参照用データを区別するために役立つと、考えている。
ここでトランザクションデータとは、一つもしくは複数の参照用データを参照するデータをいう。
適切に設計された概念データモデルは、対象となる領域の意味的な側面を記述する。
概念データモデルは、一つもしくは複数の組織によって使われる情報の性質についての、表明の集合である。
適切に設計された実体クラスの集合は、わかりにくい技術的な専門用語ではなく、自然言語の単語を使って名前をつけられる。
また同様に、適切に設計された関連の集合は、対象となる領域についての具体的な表明を生成する。
関連にはいくつかの種類がある。
例えば、「—から構成される」 (is composed of) という関連は、「注文」実体クラスと「注文明細」実体クラスが次のような表明を生成するために定義される。
すなわち、おのおのの「注文」は一つもしくは複数の「注文明細」「から構成される」。
英語を使う場合、より厳格な方法は、前置詞あるいは動名詞あるいは分詞を、「—なければならない」 (must be) あるいは「—可能性がある」 (may be) という動詞を伴う形で全ての関連の名前をつけることである。
こうすることで、実体クラスのインスタンスの個数 (濃度) と属性の数 (次数) をともに意味的に扱うことができる。
これは、このような関連を一方向に読むことができることを意味する。
例えば、次のとおりである。
おのおのの「注文」は、一つもしくは複数の「注文明細」「から構成される」「可能性がある」。
おのおのの「注文」は、一つもしくは複数の「注文明細」「から構成され」「なければならない」。
汎用データモデルは、従来のデータモデルを汎用化したものである。
汎用データモデルでは、標準化された関係 (表、テーブル) の型、およびそうした関係型に関連する種類のものについて、定義している。
汎用データモデルを定義することは、自然言語を定義することに似ている。
例えばある汎用データモデルでは、「分類関係」や「全体-部分関係」のような関係型を定義しているかもしれない。
「分類関係」は、ある事物と事物の種類 (クラス) の間の二項関係である。
「全体-部分関係」は、部分の役割を担う事物と全体の役割を担う事物の間の二項関係である。
クラス群の拡張性のあるリストがあれば、どのような事物でも分類することができるし、どのようなオブジェクトについても全体-部分関係を指定することができる。
関係型についての拡張性のあるリストを標準化することにより、汎用データモデルでは無数の事物の種類を表現することができ、自然言語の表現能力の水準に近づくことができる。
他方で、従来のデータモデルでは、対象とする領域のスコープは固定的で限定されている。
なぜなら、従来のデータモデルをインスタンス化する (適用する) ことでできるのは、モデルにおいて事前定義された事物を表現することができるだけであるからである。
汎用データモデルは、従来のデータモデルの短所を解決するための方法として開発される。
例えば、同じ領域に対して従来のデータモデルによるモデリングを複数の人々が行う場合、それぞれ異なるデータモデルを作ってしまうことが多い。
このため、複数の人々が共同でモデルを作る場合の困難につきあたる。
こうした情況は、データ交換やデータ統合を行う観点からは、障害となる。
そして、同じ領域に対してデータモデルが異なっているのは、いつも、モデルの抽象化の水準が異なることと、 (モデルの意味的な表現能力により) インスタンス化することが可能な事物の種類の相違が、原因となっている。
こうした相違を小さくするために、モデリングをする人々は、意思疎通をし、より具体的に表現するべくいくつかの要素について合意をする必要がある。
優れたデータモデルを作る上で有用となる汎用的ないくつかのパターンがある。
これらのパターンとしては、パーティ (人物と組織の上位概念) 、製品タイプ、製品インスタンス、アクティビティタイプ、アクティビティインスタンス、契約、地域、サイトなどが含まれる。
こうしたパターンに含まれる実体を明示的に含めたモデルは、適度に堅牢性を備え、理解しやすいであろう。
汎用的なツールを作る際には、より抽象的なモデルが適している。
この抽象的なモデルは、「事物」 (THING) と「事物タイプ」 (THING TYPE) の変形版の集合から構成される。
この抽象的なモデルでは、全ての実際のデータは「事物」もしくは「事物タイプ」のインスタンスとして記述される。
一方で、このような抽象的なモデルは扱うことが難しいという側面もある。
なぜなら、実世界の事物をあまりよく表現できていないからである。
しかし他方で、こうした抽象的なモデルに、特に標準化された辞書 (ディクショナリ) が存在する場合に、適用可能性は非常に高い。
具象的で特化したデータモデルでは、スコープや環境が変更されたときに、モデルを変更しなければならないという懸念がある。
汎用データモデルによるデータモデリングの方法には、次のような特徴がある。
汎用データモデルは、汎用的な実体の集合から構成される。汎用的な実体としては、「事物インスタンス」、「クラス」、「関連」などがあり、さらにおそらくはこうした実体に多くのサブタイプが存在するであろう。
あらゆる事物インスタンスは、「事物インスタンス」と呼ばれる汎用的な実体のインスタンスであるか、そのサブタイプのインスタンスである。
あらゆる事物インスタンスは、事物の種類 (「クラス」) により、明示的な分類関連を使うことで、明示的に分類される。
分類のために使われる実体は、他の種類の実体とは別に、「クラス」という実体もしくはそのサブタイプの実体の標準的なインスタンスとして、定義される。「クラス」のサブタイプとしては「関連クラス」などがある。こうした標準的なクラス群は、「参照データ」と呼ばれることが多い。すなわち、領域に固有の知識は、このような標準的なクラス群のインスタンスとして表現することが可能である、ということである。例えば、自動車、車輪、建物、船、温度、長さなどの概念は標準的なインスタンスである。また、「—から構成される」や「—に参加する」のような標準的な関連の実体もまた、標準的なインスタンスである。
こうした汎用データモデルによるデータモデリングの方法を採ることで、標準的な実体や標準的な関係型をインスタンスとして追加することができるようになる。
そしてデータモデルに柔軟性をもたせ、アプリケーションソフトウェアのスコープの変更があったときにも、データモデルの変更を抑制することができる。
汎用データモデルは、次の規則に従っている。
属性は、他の実体への関連を表現するものとして扱われる。
実体が同定されると、その事物の本質的な性質に基づいて命名される。特定の文脈で果たす役割に基づいて命名されるのではない。
実体は、データベースあるいはデータ交換のためのの中に、局所的な識別子をもつ。こうした識別子は、人工的なものであり、一意となるように管理される。関連は、局所的な識別子の一部として使われることはない。
アクティビティ、関連、イベントによる影響は、実体として表現される (属性としては表現されない) 。
実体は、モデルの普遍的な文脈を定義するために、実体におけるサブタイプ/スーパータイプの階層の一部を構成する。関連もまた実体であるから、さまざまな関連の実体は、関連のサブタイプ/スーパータイプの階層の一部を構成する。
関連は高い (汎用的な) 水準において定義される。関連は、それが妥当である水準のうち最も高い水準で定義される。例えば、コンポジション関連 (「—から構成される」と表現される) は、「事物インスタンス」と別の「事物インスタンス」の間の関連として定義される (例えば、単に「注文」と「注文明細」の間の関連としては定義されない) 。この汎用的な水準では、関連は原則として何らかの事物インスタンスとそれとは別の何らかの事物インスタンスに適用することがすることができるということを、意味している。「参照データ」においてはデータに対する制約群が定義される。制約は、実体間の関連の標準的なインスタンスである。
汎用データモデルの例を次に示す。
ISO 10303-221
ISO 15926 (ISO 15926)
Gellish (Gellish)
Gellish English (Gellish English)
汎用データモデルとは別の種類のデータモデルでは、データベース管理システム (DBMS) もしくは他のデータ管理技術を使ってデータを組織化する方法を記述する。
この種のデータモデルでは、例えば、関係モデルにおいては関係 (表、テーブル) 群と属性群を、オブジェクト指向モデリングにおいてはクラス群と属性群を、記述する。
理論的には、この種のデータモデルは、先述したより概念的なデータモデルから導出される。
しかしこの種のデータモデルは、システムの処理能力や利用パターンを考慮することにより、概念的なデータモデルとは異なっていることがある。
「データ分析」は、データモデリングにおいて一般的に使われている用語である。
しかしデータ分析で実際に行う作業は、「分析」 (アナリシス、一般的な概念からその構成要素となっている概念群を同定すること) よりも「総合」 (別々のインスタンスを一つの一般的な概念にまとめること) の方に、理論と方法論において共通する部分が多い (参考: 「システムアナリスト」という用語は使われているが、「システム総合者」という用語は使われていない) 。
データモデリングでは、不必要なデータの冗長性を排除することと、関連しあっているデータ構造群を「関連」によって関連づけることにより、概念的に近いデータ構造群をもとにして一つの包括的な概念にまとめることを目指す。
データモデリングの別の方法論としては、自律的にデータの暗黙的なモデルを生成する人工ニューラルネットワークのような適応型システムを使う方法論がある。
データモデリングのための技法 (方法論) がこれまでいくつか開発されてきている。
こうしたデータモデリング技法は、データモデリングをする人々が作業をする際に導きの手となる。
しかし2人が同じデータモデリング技法を採用しても、非常に異なるデータモデルを考案する結果となることが、しばしばある。
データモデリングで使われる著名な技法を次に示す。
EBNF (Extended Backus–Naur Form)
実体関連モデル (entity-relationship model 、ERモデル)
実体関連図 (entity-relationship diagram 、ER図)
統一モデリング言語 (UML)
Relational Model/Tasmania (RM/T) (Relational Model/Tasmania)
Barker's Notation (Barker's Notation)
Business rules (Business rules)
Business rules approach (Business rules approach)
Object Role Modeling (ORM) あるいは Nijssen's Information Analysis Method (NIAM) (Object role modeling)
Semantic data modeling
David C. Hay. 1996. Data Model Patterns: Conventions of Thought. New York:Dorset House Publishers, Inc. ISBN 978-0932633293
Matthew West, Julian Fowler
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.
. 2001. The Data Model Resource Book. John Wiley & Sons ISBN 0-471-38023-7