データモデリング（英: data modeling）は、コンピュータ科学の文脈では、何らかのデータモデリング方法論を適用してデータモデルのインスタンスを作る過程である。データモデリング方法論は、データモデリングを形式的に記述したものである。現在までに考案されたデータモデルの種類としては、次のようなものがある。

階層型データモデル

ネットワーク型データモデル

関係モデル

オブジェクト関係モデル

オブジェクトモデル

データモデリングを行う際には、データを構造化し組織化する。こうして作成されたデータ構造は、その後にデータベース管理システム (DBMS) を使って実装されることが多い。データモデリングの過程では、データを定義し組織化することに加えて、構造化したデータに対して (暗黙的もしくは明示的に) 制約の集まりを同定する。

大容量の構造化データおよび大容量の非構造化データを管理することは、情報システムの主要な機能である。データモデルは、関係データベース管理システム (RDBMS) のようなデータ管理システムにおいて、記憶装置に永続化される構造化データを記述する。データモデルは、非構造化データ——ワードプロセッサで作成する文書や電子メールのメッセージ、画像、デジタル音楽、デジタル動画など——については記述しないことが多い。

データモデリングの例については、次の節を参照。

#実体関連図 (ER図) によるデータモデリングの例

#統一モデリング言語 (UML) のクラス図によるデータモデリングの例

データモデルの種類

データモデルのインスタンスには、ANSIによれば次の3種類がある。
概念スキーマ
概念スキーマ (データモデル) は、モデリングの対象となる領域の意味的な側面を記述する。例えば、何らかの組織もしくは業界のある側面のモデルを概念スキーマとして記述できるであろう。概念スキーマは、実体クラスと関連の集まりから構成される。実体クラスは、対象領域において重要な概念を表現する。関連は、2つの実体クラスの間の結びつきである。概念スキーマは、モデルを使って表現することができる事物などを同定する。一般的に適用できるモデルについては、#汎用データモデルの節で述べる。
論理スキーマ
論理スキーマ (データモデル) は、モデリングの対象となる領域の意味的な側面を、データを扱うための何らかの技術を使って、表現したものである。論理スキーマは、関係モデルにおける関係 (表、テーブル) と属性 (列) や、オブジェクト指向におけるクラス、XMLの要素 (タグ) と属性などから、構成される。
物理スキーマ
物理スキーマ (データモデル) は、データが永続化される物理的な方法を記述したものである。物理スキーマは、パーティションやCPU、表スペースなどに関連する。

こうしたANSIによる方法で重要なのは、先述した3つの視点のおのおののモデルが、互いにある程度独立していることである。論理スキーマにおける関係 (表) と属性 (列) は、概念モデルに必ずしも影響を与えることなく、変更することができる。実際には、当然ながら、スキーマの構造は、他のスキーマに対して一貫性をもっている必要がある。論理スキーマにおける関係 (表) と属性 (列) は、概念モデルにおける実体クラスと属性を直接的に変換した結果とは、異なることがある。しかし論理スキーマは、最終的には、概念モデルの実体クラスの構造の目標を満足させる必要がある。多くのソフトウェア開発プロジェクトの初期の開発工程では、概念データモデルの設計が重要である。続く工程で、概念データモデルは、論理データモデルの形に詳細化することができる。その後の工程で、場合によっては論理データモデルは物理データモデルに変換される。しかしながら、場合によっては、概念モデルを直接に実装することもできる。

個々の事例では、細部では異なることがあっても、モデルインスタンスの構造は、他のモデルインスタンスと整合している必要がある。論理データモデルにおける関係 (表、テーブル) と属性 (列) の構造は、概念データモデルにおける実体クラスと関連と属性を直接的に変換したものとは、異なっていることがある。しかし論理データモデルは、最終的には、コンテクストの水準のデータモデルにおける実体クラスの構造と、概念データモデルにおける関連の構造の、それぞれの目標を満足させる必要がある。論理データモデルが作成された後の工程では、データを保存するプラットフォームが決まると、論理データモデルは物理データモデルに変換することができる。そして物理データモデルをもとにして、データの定義が作られる。データベースに実際にデータが格納されて運用されると、データベースに対するデータ操作 (照会、更新など) を行うことができる。
データ構造

データモデルは、対象とする領域におけるデータの構造を記述し、また結果としてその領域自体の基礎となる構造を記述する。これは、データモデルは、対象とする領域のための専用の人工言語の文法を、実際に規定しているということを意味する。

データモデルは、実体のクラス (事物の種類) の集合を表現する。対象となる組織は、実体クラスの集合について、情報と情報の属性と実体間の関連と属性間の関連を、保持して管理しようと考える。データモデルは、データをコンピュータシステムで表現する方法とはあまり関係ない形で、データを組織化して記述する。データモデルによって表現される実体は、有形物の実体である場合がある。しかしそうした具象的な実体クラスを含むデータモデルは、時を経ると、モデルが変更される傾向がある。堅牢なデータモデルでは、そうした実体の抽象を同定することが多い。例えば、あるデータモデルでは「人物」という名前の実体クラスを含んでいるかもしれない。そのデータモデルにおける「人物」の実体は、ある組織と相互作用する全ての人物を表現する。このような抽象的な実体クラスは、多くの場合、「売り手」や「従業員」という名前の具象的な実体クラスと比べて、適切である。なおここで、「売り手」や「従業員」の実体クラスは、そうした人々によって行われる特定の役割を同定している。

一部の人々は、データモデルを設計することは、トランザクションデータと参照用データを区別するために役立つと、考えている。ここでトランザクションデータとは、一つもしくは複数の参照用データを参照するデータをいう。

適切に設計された概念データモデルは、対象となる領域の意味的な側面を記述する。概念データモデルは、一つもしくは複数の組織によって使われる情報の性質についての、表明の集合である。適切に設計された実体クラスの集合は、わかりにくい技術的な専門用語ではなく、自然言語の単語を使って名前をつけられる。また同様に、適切に設計された関連の集合は、対象となる領域についての具体的な表明を生成する。

関連にはいくつかの種類がある。例えば、「—から構成される」 (is composed of) という関連は、「注文」実体クラスと「注文明細」実体クラスが次のような表明を生成するために定義される。すなわち、おのおのの「注文」は一つもしくは複数の「注文明細」「から構成される」。英語を使う場合、より厳格な方法は、前置詞あるいは動名詞あるいは分詞を、「—なければならない」 (must be) あるいは「—可能性がある」 (may be) という動詞を伴う形で全ての関連の名前をつけることである。こうすることで、実体クラスのインスタンスの個数 (濃度) と属性の数 (次数) をともに意味的に扱うことができる。これは、このような関連を一方向に読むことができることを意味する。例えば、次のとおりである。

おのおのの「注文」は、一つもしくは複数の「注文明細」「から構成される」「可能性がある」。

おのおのの「注文」は、一つもしくは複数の「注文明細」「から構成され」「なければならない」。

汎用データモデル

汎用データモデルは、従来のデータモデルを汎用化したものである。汎用データモデルでは、標準化された関係 (表、テーブル) の型、およびそうした関係型に関連する種類のものについて、定義している。汎用データモデルを定義することは、自然言語を定義することに似ている。例えばある汎用データモデルでは、「分類関係」や「全体-部分関係」のような関係型を定義しているかもしれない。「分類関係」は、ある事物と事物の種類 (クラス) の間の二項関係である。「全体-部分関係」は、部分の役割を担う事物と全体の役割を担う事物の間の二項関係である。クラス群の拡張性のあるリストがあれば、どのような事物でも分類することができるし、どのようなオブジェクトについても全体-部分関係を指定することができる。関係型についての拡張性のあるリストを標準化することにより、汎用データモデルでは無数の事物の種類を表現することができ、自然言語の表現能力の水準に近づくことができる。他方で、従来のデータモデルでは、対象とする領域のスコープは固定的で限定されている。なぜなら、従来のデータモデルをインスタンス化する (適用する) ことでできるのは、モデルにおいて事前定義された事物を表現することができるだけであるからである。

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

優れたデータモデルを作る上で有用となる汎用的ないくつかのパターンがある。これらのパターンとしては、パーティ (人物と組織の上位概念) 、製品タイプ、製品インスタンス、アクティビティタイプ、アクティビティインスタンス、契約、地域、サイトなどが含まれる。こうしたパターンに含まれる実体を明示的に含めたモデルは、適度に堅牢性を備え、理解しやすいであろう。

汎用的なツールを作る際には、より抽象的なモデルが適している。この抽象的なモデルは、「事物」 (THING) と「事物タイプ」 (THING TYPE) の変形版の集合から構成される。この抽象的なモデルでは、全ての実際のデータは「事物」もしくは「事物タイプ」のインスタンスとして記述される。一方で、このような抽象的なモデルは扱うことが難しいという側面もある。なぜなら、実世界の事物をあまりよく表現できていないからである。しかし他方で、こうした抽象的なモデルに、特に標準化された辞書 (ディクショナリ) が存在する場合に、適用可能性は非常に高い。