JP2006244498A

JP2006244498A - オブジェクトリレーショナルデータ用のデータモデル

Info

Publication number: JP2006244498A
Application number: JP2006053434A
Authority: JP
Inventors: Anil K Nori; クマーノリアニル; Michael E Deem; イー．ディームマイケル; Michael J Pizzo; ジェイ．ピゾマイケル; Steven P Anonsen; ピー．アノンセンスティーブン; Steven V Harter; ヴィ．ハータースティーブン
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2005-02-28
Filing date: 2006-02-28
Publication date: 2006-09-14
Also published as: US20060195460A1; RU2421798C2; MXPA06001209A; EP1696348A3; KR20060095452A; RU2006102530A; EP1696348A2; AU2006200227A1; BRPI0600122A; CA2534260A1

Abstract

【課題】複数のアプリケーション特有のデータモデルに共通のデータモデルである、共通データモデル（ＣＤＭ）を提供すること。
【解決手段】ＣＤＭは、ＰＩＭ（個人情報マネージャ）のエンドユーザアプリケーションデータと業務別（ＬＯＢ）データの、両方をサポートする。同様に、ＳＤＭタイプ（システム定義モデル）アプリケーションはＣＤＭのトップにそのモデルを指定することができる。ＣＤＭは、複数の異種のアプリケーションにまたがって均一なアイデンティティを有するデータエンティティを提供するエンティティ構成要素と、２つまたはそれ以上のデータエンティティ間のリレーションシップを定義するリレーションシップ構成要素とを使用することによって、アプリケーション間での改良された相互運用性を可能にする。ＣＤＭは、任意の代数が動作する、タイプシステムを提供する。
【選択図】図１

Description

本発明はデータモデルに関し、より詳細にはオブジェクトリレーショナルデータ用のデータモデルに関する。

データの持続性は、消費者アプリケーションであろうと業務別（ＬＯＢ）アプリケーションであろうと、いかなるアプリケーションでも主要な要件である。例えば、シェルおよびメディアアプリケーションはドキュメント、音楽、および写真を保管し、電子メールアプリケーションはメッセージおよびカレンダオブジェクトを保管し、ビジネスアプリケーションスイートは顧客および注文オブジェクトを保管する。これらアプリケーションのほぼすべてがデータ用のオブジェクトモデルを定義し、それら自体の持続性メカニズムを書き込む。

データを記述、照会、および操作するための標準的なメカニズムが、ＳＱＬ（構造化照会言語）に基づくリレーショナル（ｒｅｌａｔｉｏｎａｌ）データベース管理システム（ＲＤＢＭＳ）である。ＳＱＬデータモデルとは、テーブル、制約などの形でデータの構造を宣言的に記述するために使用される言語である。しかしながら、ＬＯＢアプリケーションなどのデータ中心のアプリケーションには、ＳＱＬがある面でニーズを満たすのに不十分であることがわかる。第１に、それらのデータ構造はＳＱＬで記述可能な構造よりも複雑である。第２に、それらのアプリケーションはオブジェクト指向言語を使用して作成されるが、これも表現可能なデータ構造においてＳＱＬよりもリッチである。

これらアプリケーションの開発者は、Ｃ＃などのプログラミング言語で実施されるオブジェクト指向デザインを使用してデータを記述することにより、こうした欠点に対処する。その後、手操作でまたは何らかの形のオブジェクトリレーショナル技術を使用して、ＳＱＬデータをオブジェクトへおよびオブジェクトから転送する。残念ながら、あらゆるオブジェクト指向設計を所与のＳＱＬインプリメンテーションに、または場合によっては任意のＳＱＬインプリメンテーションに容易にマッピングできるわけではなく、開発者が相違点に対処するための大量の手操作のプログラミング作業を生み出すことになる。

他の問題は、開発者のデータがオブジェクトの形である場合、開発者がＳＱＬから知り、理解する機能を利用できないことである。例えば照会の表現は、他のタスクに使用するオブジェクトではなく基礎となるデータベースに関して行わなければならない。

１つの解決策は、フレームワークおよびデータベースサーバまたはサポートしているランタイムによってサポートされる、よりリッチなデータモデルを提供することである。開発者にとって、データを記述および操作するためによりリッチな機能を使用することは、データベースと同様にわかりやすい。共通かつ単純であるがリッチなデータモデルは、これらのアプリケーションに対する共通のプログラミングモデルを動作可能にし、アプリケーションプラットフォームが共通のデータアクセスの基礎を一新できるようにするものである。

したがって、複数のまったく異なるアプリケーションに共通プログラミングモデル機能を提供する、リッチデータモデルが求められている。

以下に、開示されたイノベーション（ｉｎｎｏｖａｔｉｏｎ）のいくつかの態様について基本的に理解するために、簡略化された要約を示す。この要約は広範囲にわたる概要ではなく、主要／不可欠な要素を識別すること、またはその範囲を画することを意図するものでもない。単に、後で提示されるより詳細な説明の前置きとして、いくつかの概念を簡略化された形で提示するためのものである。

開示されたイノベーションは、共通データモデル（ＣＤＭ）と呼ばれるリッチデータモデルである。これは、共通データプラットフォーム（ＣＤＰ）と呼ばれる、これを実施するプラットフォームによってサポートされる。ＣＤＭは、複数のアプリケーション特有のデータモデルに共通のデータモデルである。例えば、ＰＩＭ（個人情報マネージャ）のエンドユーザアプリケーションデータと業務別（ＬＯＢ）データの、両方をサポートすることができる。同様に、ＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓ（登録商標）のＳＤＭ（ＳｙｓｔｅｍＤｅｆｉｎｉｔｉｏｎＭｏｄｅｌ）などのそれ自体のデータモデルを備えたアプリケーションは、ＣＤＭのトップにそのモデルを指定することができる。ＣＤＭは、アプリケーション間での改良された相互運用性を可能にする。

共通データモデルの要素に入れることが可能な、アプリケーションで一般に使用されるデータモデル化および持続性の概念がかなりの数に上ることにより、多数のアプリケーションが活用可能なリッチな持続性フレームワークが提供される。ＣＤＭ機能には、リレーショナル概念の包含、データに関するリッチオブジェクト抽象化の定義、リッチセマンティクスのモデル化（例えばリレーションシップ）、アプリケーションとＣＤＭとの間での不一致の最小化、ＣＬＲ（共通言語ランタイム）タイプシステムとの整合、中間層およびクライアントアプリケーションの開発を可能にする動作のサポート、ならびに論理的概念の提供が含まれる。モデル化の概念は、データストアとは無関係なセマンティクスをキャプチャ（ｃａｐｔｕｒｅ）する。

ＳＱＬに関するＣＤＭが改善された例の１つが、リレーションシップの定義にある。ＳＱＬでは、顧客と注文との間のリレーションシップを明示的に表すことができない。リレーションシップが推論できる元となる外部キー制約を表すことは可能であるが、外部キーはリレーションシップをインプリメントするための多くの方法のうちの１つに過ぎない。ＣＤＭでは、リレーションシップを明示的に表すことが可能であり、テーブル定義が属性を有するのと同じように属性を有する。リレーションシップは、上流市民（ｆｉｒｓｔｃｌａｓｓｃｉｔｉｚｅｎ）である。第２の例は、ＣＤＭが、より自然にＣＬＲと統合できるようにするオブジェクトに関するタイプシステムを有することである。

他の態様では、ＣＤＭの代替のインプリメンテーションが提供され、リレーションシップは＜Ａｓｓｏｃｉａｔｉｏｎ＞または＜Ｃｏｍｐｏｓｉｔｉｏｎ＞要素を使用してトップレベルで定義される。したがって、参照アソシエーション（Ｒｅｆａｓｓｏｃｉａｔｉｏｎ）（または構成）を定義するために、ソース（または親）に関するプロパティを定義する必要はない。

前述および関係するエンドを実施するために、本明細書では以下の説明および添付の図面と共に、開示されたイノベーションのある種の例示的態様について説明する。しかしながら、これらの態様は、本明細書で開示された原理が使用可能な様々な方法のほんの一例を示すものであり、こうした態様のすべておよびそれらの等価物を含むことが意図される。他の利点および新規な特徴は、図面と共に考察された場合、以下の詳細な説明から明らかとなろう。

次に、本イノベーションについて図面を参照しながら説明するが、図面では全体を通じて同じ要素を表すために同じ参照番号が使用される。以下の説明では、完全に理解するために説明の目的で多くの特定の細部が示される。しかしながら、本イノベーションがこれら特定の細部なしで実施可能であることは明白であろう。その他の場合、説明を容易にするためによく知られた構造およびデバイスがブロック図の形で示される。

本明細書で使用される場合、「構成要素」および「システム」という用語は、ハードウェア、ハードウェアとソフトウェアの組合せ、またはソフトウェア実行中の、コンピュータ関係のエンティティを表す。例えば構成要素は、プロセッサ上で実行中のプロセス、プロセッサ、ハードディスクドライブ、複数ストレージドライブ（光および／または磁気ストレージ媒体）、オブジェクト、実行可能プログラム（ｅｘｅｃｕｔａｂｌｅ）、実行スレッド、プログラム、および／またはコンピュータとすることが可能であるが、これらに限定されるものではない。例を挙げると、サーバ上で実行中のアプリケーションとサーバの両方を構成要素とすることができる。１つまたは複数の構成要素がプロセスおよび／または実行スレッド内に常駐可能であり、さらに構成要素を１つのコンピュータ上にローカライズすること、ならびに／あるいは２つまたはそれ以上のコンピュータ間で分散することが可能である。

ユーザに情報を表示するある種の方法が示され、スクリーンショットとしてある種の図面に関して説明されるが、当業者であれば様々な他の代替形態が使用可能であることを理解されよう。本明細書では「画面（ｓｃｒｅｅｎ）」、「ウェブページ」、および「ページ」という用語は、一般に相互に交換可能なものとして使用される。ページまたは画面は表示記述として、グラフィカルユーザインターフェースとして、あるいは画面上に情報を表示する他の方法（例えばパーソナルコンピュータ、ＰＤＡ、携帯電話、または他の好適なデバイス）によって格納および／または伝送され、ページ上に表示されることになるレイアウトおよび情報またはコンテンツは、メモリ、データベース、または他のストレージ機構に格納される。

初めに図面を参照すると、図１は、本発明に従った共通データモデル（ＣＤＭ）アーキテクチャ１００を示す図である。ＣＤＭ１００は、複数の異種のアプリケーションにまたがって均一なアイデンティティを有するデータエンティティを提供する、エンティティ構成要素１０４を含む。リレーションシップ構成要素１０２は、２つまたはそれ以上のデータエンティティ間の関係を定義する。

ＣＤＭ１００は、複数のアプリケーション特有のデータモデルに共通のデータモデルである。例えばこれは、ＰＩＭ（個人情報管理）のエンドユーザアプリケーションデータと業務別（ＬＯＢ）データの、両方をサポートすることができる。同様に、ＳＤＭタイプ（Ｗｉｎｄｏｗｓ（登録商標）ＳｙｓｔｅｍＤｅｆｉｎｉｔｉｏｎＭｏｄｅｌ）アプリケーションは、ＣＤＭ１００のトップにそのモデルを指定することができる。ＣＤＭ１００は、アプリケーション間での改良された相互運用性を可能にする。

ＣＤＭの要素に入れることが可能なデータモデル化および持続性の概念がかなりの数に上ることにより、データを記述するために共通語彙を使用し、オブジェクトリレーショナルな持続性フレームワークなどの、すべてのアプリケーションに利益を与えることが可能な共通サービスセットが可能になる。ＣＤＭ１００の間接的な目標は、アプリケーションがそれら自体の持続性インフラストラクチャを定義しなくてもよくなること、および異なるデータストアをまたがったより高水準なアプリケーションの相互運用性を可能にすることである。他の目標には、リレーショナル概念の包含、データに関するリッチオブジェクト抽象化の定義、リッチセマンティクスのモデル化（例えばリレーションシップ）、アプリケーションとＣＤＭとの間での不一致の最小化、ＣＬＲ（共通言語ランタイム）タイプシステムとの整合、中間層およびクライアントアプリケーションの開発を可能にする動作のサポート、ならびに論理的概念が含まれる。モデル化の概念は、データストアとは無関係なセマンティクスをキャプチャする。

本イノベーションのＣＤＭは、少なくとも以下の新規な態様を提供する。
・エンティティタイプ、インラインタイプ、エンティティテーブル、テーブルセット、およびリレーションシップで構成されるタイプシステム
・エンティティタイプとインラインタイプとの区別
・エンティティタイプはアイデンティティおよびキーの概念を含む（ＳＱＬの場合のようにテーブルで定義するのではない）
○ エンティティプロパティの組合せからなるキーの明示的宣言
・エンティティ間での異なる形のリレーションシップ（アソシエーション）
○ エンティティアソシエーションの他のアソシエーションタイプとの構成可能性
○ 共通値アソシエーション
○ 条件付アソシエーション（より複雑な結合タイプリレーションシップを提供する）
・エンティティで指定された属性（プロパティ記述）と、リレーションシップで指定されたもの（エンティティを関係付けるためのそれらのプロパティの使用方法）とのくくり出し（ｆａｃｔｏｒｉｎｇ）
・ネストされたテーブル（構成）
・拡張子
○ タイプ特有
○ インスタンスまたはクラスベース
○ 他の拡張子から派生する機能
○ ストレージテーブルを指定する機能
・拡張可能列挙
・リレーションシップ用のナビゲーションプロパティの宣言
・特定テーブルにのみ適用するためのアソシエーションのスコーピング
・エンティティテーブルおよびリレーションシップのテーブルセットへのグループ化
・エンティティ定義、アソシエーション、またはテーブルセットで使用されることになるテーブルを指定する機能
・各タイプ定義の属性セット
・匿名タイプとしての射影（ｐｒｏｊｅｃｔｉｏｎ）の表現
○ 匿名タイプのインラインを定義する機能
・タイプ制約の指定

次に、任意の代数が動作する際に介するＣＤＭタイプシステムをテキスト記述する。インデントは、インデントされたタイプが「アウトデントされた」タイプの一種であることを示し、例えばアレイタイプはインラインタイプである。
タイプ−−すべてのタイプの抽象ベース
エンティティタイプ−−インライン指定された（Ｉｎｌｉｎｅｎａｍｅｄ）タイプのプロパティを備えた参照可能タイプ（一意のアイデンティティを有する）
インラインタイプ−−アイデンティティを有さない
コレクションタイプ
アレイタイプ−−インラインタイプインスタンスのバッグ
エンティティテーブルタイプ−−エンティティのセット
スカラタイプ
エンティティ参照タイプ−−エンティティへの参照
テーブル参照タイプ−−更新代数に必要であり、プロパティのタイプとして使用すべきではない
単純タイプ−−ｉｎｔ、ｓｔｒｉｎｇ、Ｘｍｌ、ＦｉｌｅＳｔｒｅａｍなどの他のメンバのない基本的なタイプ
列挙タイプ
アレイタイプ−−インラインタイプインスタンスのバッグ。これはＲｏｗＳｅｔ＜Ｉ＞である
複合タイプ
構造化タイプ−−ユーザ定義プロパティを有するタイプ。インラインタイプのプロパティ
匿名タイプ−−名前なし。使用ごとに再定義される。インラインタイプのプロパティを有する
行セットタイプ−−インラインまたはエンティティタイプインスタンスのバッグ
エンティティテーブルタイプ−−エンティティタイプインスタンスのセット。これはサイト（インスタンスが格納される場所）である
リレーショナルテーブルタイプ−−匿名タイプインスタンスのバッグ。これはサイトである

図２は、革新的な態様に従ってＣＤＭを提供する方法を示す図である。説明をわかりやすくするために、例えば流れ図の形で本明細書に示される１つまたは複数の方法は、一連の動作として図示および説明されるが、本イノベーションは、これに従った動作の一部が本明細書で図示および説明されるものとは異なる順序でおよび／または他の動作と同時に発生する場合があるため、動作の順序によって制限されるものでないことを理解されよう。例えば当業者であれば、代わりに、ある方法を状態図などの一連の相互に関係する状態またはイベントとして表せることを理解されよう。さらに、イノベーションに従って方法をインプリメントするために、図示されたすべての動作を必要とはしない場合もある。

２００では、スキーマ定義をスコーピングするためのネームスペースを定義するスキーマが提供される。２０２では、プロパティと方法をグループ化するためのエンティティタイプが定義される。２０４では、そのプロパティがテーブルであるテーブルセットエンティティが定義される。２０６では、リレーションシップを使用してエンティティ間のセマンティック接続が表現される（例えば、アソシエーション、構成など）。

エンティティは、実世界の物体をモデル化する。エンティティは、ＣＤＭにおいてそのアイデンティティ（キー）を使用して一意に識別可能なデータオブジェクトである。エンティティは、そのアイデンティティを使用して共有（参照）可能な最小単位である。エンティティは構造（例えばプロパティ）および動作（例えば方法）を有する。様々なタイプのエンティティの例の中には、注文、顧客、連絡先、ドキュメントなどがある。エンティティは、ＳＱＬ９９におけるタイプ別行、またはＯＤＢＭＳにおけるオブジェクトと同様である。エンティティはエンティティタイプのインスタンスとして定義される。単なる例として、エンティティ定義用の構文を以下に示す。

あらゆるエンティティは、エンティティキー値で構成された一意のアイデンティティを有する。このアイデンティティは、エンティティへの参照を形成するための基礎である。エンティティキーとは、エンティティの１つまたは複数のプロパティのセットである。あらゆる非抽象エンティティタイプ定義は、キープロパティを指定するか、または基本エンティティタイプからキー指定を継承しなければならない。キープロパティの値は、ユーザ定義またはシステム生成とすることができる。

エンティティの識別子は、エンティティのキーとエンティティが含むかまたは親エンティティの識別子とで形成される。親エンティティとは、（子）エンティティが格納されるテーブルを含むエンティティのことである。エンティティのキーは、そのテーブル内で一意であることのみが必要であり、他のテーブルは同じエンティティキー値を備えたエンティティを含むことができる。したがってエンティティ識別子は、そのキー値とその親の識別子を組み合わせることによって、一意となる。場合によっては、キーは、グローバル一意識別子（ＧＵＩＤ）を使用するなどして、ストア全般にわたって一意とすることができる。ＣＤＭは、識別子が要素（例えば、ＥｎｔｉｔｙＳｅｔ）内で一意であることのみを必要とする。

アイデンティティとはエンティティを完全に識別するものであり、エンティティインスタンスを戻すためにデリファレンス（ｄｅ−ｒｅｆｅｒｅｎｃｅ）することができる。参照はアイデンティティを使用する。エンティティが与えられれば、その参照値を取得することができる。２つのエンティティの識別子が同じである場合かつその場合に限り、その２つのエンティティは同じである。ＣＤＭにおける参照タイプの構文は「Ｒｅｆ（＜ｅｎｔｉｔｙ＿ｔｙｐｅ＞）」であり、プロパティは「参照（ｒｅｆ）」タイプとすることが可能であって、こうしたプロパティは参照プロパティと呼ばれる。参照値は持続可能であり、エンティティへの永続参照である。参照値をコピーしても、参照先のエンティティはコピーされない。参照値は、例えばＲｅｆおよびＤｅｒｅｆ演算子を介して、照会言語内でのナビゲーションを提供することもできる。

参照は、エンティティの共用を可能にする。例えば、注文エンティティは顧客参照プロパティを有することができる。同じ顧客に関するすべての注文が、顧客参照プロパティに関して同じ値を有することになる。参照の構造は、インプリメンテーション定義される。参照およびキーは、ＡＰＩではタイプとして公開することができる。参照インプリメンテーションは、キー値と、場合によってはエンティティが見つかるテーブルとを含む、参照するエンティティの識別子情報を含む。これは、個々のキー値（有効な結合を可能にする）として、または単一の不透明値として、参照を格納する。機能が、キー値またはエンティティを含むテーブルを取得するための参照の構造を公表する場合がある。

ＣＤＭは、エンティティとリレーションシップという主要な概念からなる。エンティティとは、単一のアイデンティティを備えた緊密に関係するデータのセットである。リレーションシップとは、２つまたはそれ以上のエンティティを関係付けるメカニズムである。図３は、リレーションシップ構成要素１０２およびその形式を示す図である。リレーションシップは、２つまたはそれ以上のエンティティがどのように関係しているかを示す。リレーションシップ３００は、以下のいずれかの形式を取る。

アソシエーション３０２は、２つまたはそれ以上のエンティティの間でのリレーションシップ３００の最も一般的な形である。エンドと呼ばれるエンティティは、明示的なソース−ターゲット（外部−１次キーのような）リレーションシップを介して、または照会を介して、互いに関係付けられる。リレーションシップでは、それぞれのエンドが他方のエンドから独立したままである。一方のエンドが削除された場合に他方のエンドが削除されるようにすること、または一方のエンドが存在する限りは他方のエンドが削除されないようにすることが可能である。

構成３０４とは、子エンティティが概念上は親エンティティの不可欠部分（ｉｎｔｅｇｒａｌｐａｒｔ）であるように、１つの（または複数の）子エンティティに関係付けられる親エンティティである。子エンティティは、厳密に１つの親の中に存在するため、親エンティティが削除された場合は必ず削除されなければならない。さらにそのアイデンティティは、その構成内の他の子エンティティの間で一意でありさえすればよい。

アソシエーションエンティティ３０６は、２つまたはそれ以上のエンティティであるエンドが、それ自体がプロパティを有することが可能な、別のエンティティであるアソシエーションエンティティ上でのリレーションシップによって互いにリンクされている場合に定義される。各エンドは、概念上は互いに独立したままである。

図４は、エンティティ構成要素１００、ならびにそのメンバおよびメンバタイプを示す図である。エンティティ構成要素１００は、エンティティメンバからなるエンティティ４００を利用する。以下の種類のメンバがサポートされる。プロパティ４０２は、特定タイプのインスタンスに対してストレージを割り振る。ナビゲーションプロパティ４０４は、アソシエーションによって関連付けられたエンティティを横切る照会を簡略化する。算出（Ｃａｌｃｕｌａｔｅｄ）プロパティは、格納値に対する算出値を表す。メソッド４０８は、実行可能なオペレーションを表す。

エンティティメンバは、メンバタイプを有する、および／またはタイプ別パラメータを取る。エンティティのメンバを記述する場合は、インラインタイプ４１２およびテーブルタイプ４１４という種類のタイプが使用可能である。インラインタイプとは、そのデータがエンティティ上でインラインに格納されるタイプである。インラインタイプは、エンティティタイプと同様にメンバで構成される。インラインタイプは、エンティティタイプとは異なり、それらが常駐するエンティティによって課せられるものを超えるアイデンティティは持たない。インラインタイプは直接宣言することが可能であり、いくつかの他の種類のタイプをデータモデル内に包含する。インラインタイプには以下が含まれる。

単純インラインタイプ４１６は、共通データモデルに見られる内部構造を持たないインラインタイプである。ＣＬＲ値タイプは、共通データモデルにおける単純なタイプである。列挙タイプ４１８は名前付き値のセットである。列挙タイプ４１８は、競合の恐れなしに複数の開発者によって独立におよび同時に拡張可能な単純なタイプである。エンティティ参照タイプ４２０は、単一エンティティへの永続参照であり、場合によってはそのエンティティが常駐するテーブルへの参照を含む。エンティティ参照は、２つのエンティティを関係付けるためにアソシエーションと共に使用される。テーブル参照タイプ４２２はテーブルへの永続参照である。アレイタイプ４２４は、アレイ以外のインラインタイプのインスタンスの順序付きコレクションである。

テーブルタイプ４１４は、指定されたエンティティタイプのインスタンスの非順序付きコレクションである。テーブルは２つのエンティティを関係付けるために構成と共に使用される。上記でリストアップされたすべてのタイプが被包含タイプであり、すなわちエンティティはこれらのタイプの値を含むことができる。

エンティティのタイプは、エンティティのメンバを記述するものである。エンティティタイプは基本エンティティタイプから派生することが可能であり、この場合、派生エンティティタイプは基本タイプのすべてのメンバならびに派生タイプに関して記述されたメンバを含む。エンティティタイプは、競合の恐れなしに複数の開発者によって独立におよび同時に拡張可能である。こうしたエンティティ拡張タイプは、タイプ継承には依存しない。エンティティおよびエンティティ拡張タイプは、被包含タイプではない。

テーブルセットとは、テーブル値プロパティを有するエンティティタイプのインスタンスのことである。テーブルセットを宣言すると、そのタイプの単一の名前が付いたインスタンスおよびそれが含むそれぞれのテーブルが作成される。データベースを作成する場合にデータを格納するための場所が作成されるのと同様に、テーブルセットはデータを格納するための場所を作成する。

次に図５を参照すると、本発明のコアデータモデルの特徴を示すためのＬＯＢアプリケーションウィンドウが示されている。販売注文（ＳａｌｅｓＯｒｄｅｒ）エントリには、注文番号（ＯｒｄｅｒＮｕｍｂｅｒ）、顧客番号（ＣｕｓｔｏｍｅｒＮｕｍｂｅｒ）、顧客名（ＣｕｓｔｏｍｅｒＮａｍｅ）、ならびに、商品番号（ＩｔｅｍＮｕｍｂｅｒ）、内容（Ｄｅｓｃｒｉｐｔｉｏｎ）、数量（Ｑｕａｎｔｉｔｙ）、および他の関連情報などの注文ライン情報などのデータが示される。

図６は、図５のＬＯＢアプリケーションウィンドウ上でエンティティ間の構造リレーションシップがどのように反映されるかを示す図である。前述のように、ＣＤＭの２つのコア概念はエンティティおよびリレーションシップである。エンティティとは、プロパティとエンティティを一意に識別するアイデンティティデータとを備えたオブジェクトのことである。リレーションシップとは、エンティティを関係付ける方法のことである。図６では、Ｏｒｄｅｒ（注文）およびＣｕｓｔｏｍｅｒ（顧客）が、アソシエーションによって関係付けられた２つのエンティティである。ここで、Ｏｒｄｅｒエンティティは１つのＣｕｓｔｏｍｅｒエンティティ（「１」）にのみ関連付けられる。直感的に、顧客をゼロまたはそれ以上の注文（「^＊」）に関連付けることができる。エンティティはプロパティを有し、互いから継承することができる。アソシエーションは、参照（例えば、Ｏｒｄｅｒ．Ｃｕｓｔｏｍｅｒ）として、プロパティ間の結合として、エンティティとしてなど、様々な方法でインプリメントされる。

アソシエーションは、いくつかの異なる方法でインプリメントすることができる。その１つの方法が、参照（ポインタに類似）を使用することである。図６の前述の例では、ＯｒｄｅｒからＣｕｓｔｏｍｅｒへのポインタである１つの参照が存在する。これは、注文に関係付けられた１人の顧客が存在可能であるという点で、制約をインプリメントするのに便利である。１つのインプリメントでは、参照プロパティはその中に１つの参照しか有することができない。

他の方法は、プロパティに関して記述されたリレーションシップである、従来のアソシエーションを使用することである。ある場合には２つのプロパティが一緒に関係付けられ、ある場合にはプロパティのセットが相互に関連付けられる。共通値リレーションシップとは、２つのエンティティが同じ値を有する場合、それらは関係している、というリレーションシップである。その一例が、著者名（プロパティ）を有するドキュメント（エンティティ）と、連絡先名プロパティを有する連絡先と呼ばれる別のエンティティである。ドキュメントエンティティの著者名プロパティと、連絡先エンティティの連絡先名プロパティとの間に、リレーションシップをセットアップすることができる。これらのプロパティ値が同じである場合、これら２つのエンティティの間にはリレーションシップが存在する。これは、「この表現が真の場合、これらのエンティティは関係している」と言える、何らかの任意の表現を作成するように一般化することができる。例えば、第１のエンティティが第１の長方形プロパティを有し、第２のエンティティが第２の長方形プロパティを有する場合、第２のエンティティ長方形が第１のエンティティ長方形を完全に封入していれば、第１のエンティティと第２のエンティティは関係しているというように、リレーションシップを定義することができる。

第３の方法は、接続するためにエンティティが使用される、アソシエーションエンティティである。これを使用して、アソシエーション上にプロパティを持つことができる。

図７は、図５のＬＯＢアプリケーションウィンドウ上に課された、本発明に従ったエンティティの構成を示す図である。構成とは、１つの物が他の物を含むが、単なるリレーションシップではない、包含である。例えば、ＯｒｄｅｒはＯｒｄｅｒＬｉｎｅエンティティのセットを有するかまたは含む。親アイデンティティと子アイデンティティとがまとまって、子の完全なアイデンティティを構成する。構成は、親エンティティ上のエンティティテーブルプロパティによって表される。この、構成を表すためのテーブル概念のＣＤＭ内での再使用可能性が有利である。構成（黒いダイヤ形で示される）は、２つのエンティティを親および子として関連付ける。各Ｏｒｄｅｒは、多くの（「^＊」）ＯｒｄｅｒＬｉｎｅ（注文ライン）エンティティ（またはその派生物）のテーブルを有する。子は親の中に存続し、親を削除すれば子も削除しなければならないため、親は子の存続時間を制御することになる。子エンティティは、同じ構成内の他の子の間でのみ一意であればよい。

図８は、本発明に従って、エンティティリレーションシップ、集合テーブル（ａｇｇｒｅｇａｔｅｔａｂｌｅ）およびそのアドレッシング、ならびに制約を採用する、ＣＤＭ概念を使用する例示的なＬＯＢモデルを示す図である。矢印の付いた線はアソシエーション（例えば参照プロパティ）を表し、黒いダイヤ形は構成（テーブルプロパティ）を示し、テーブルセットはデータベースに類似する。テーブルセットは、アプリケーションデータツリーのルートである。テーブルセットはテーブルセットタイプのインスタンスである。テーブルセットタイプは、テーブル値プロパティのみを有する。すなわち、テーブルセットタイプは構成にのみ関与する。テーブルセットタイプとは、一種のエンティティタイプのことである。アプリケーションは、「テーブルセット」と呼ばれるテーブルセットタイプのインスタンスを定義する（例えば、タイプ「ＮｏｒｔｈｗｉｎｄＤａｔａ」の「Ｎｏｒｔｈｗｉｎｄ」を定義する）ことによって、データを作成する。テーブルセットは、サービス内、および最終的にはデータベース内にインストールされる、データのセットも記述する。これは自己完結型（ｓｅｌｆ−ｃｏｎｔａｉｎｅｄ）であり、構成可能なデータ単位である。

エンティティ（例えばＳａｌｅｓＤａｔａ）が定義された場合、これを多くの異なるエンティティに関係付けることができる。例えばある会社は、注文のセットをその内部に、および顧客のセットをその内部に有する。これは、２つの異なる構成を示す。Ｏｒｄｅｒはその内部に注文ラインを有することになり、その結果、ツリーの形成が開始される。ツリーのトップは、テーブルセットエンティティと呼ばれる特別なエンティティである。テーブルセットとは、いくつかのエンティティタイプの単一のインスタンスのことである。（この構造は、データベースのＳＱＬ概念に類似している。）テーブルセットは、データ宣言の手段を提供する。図では、他のエンティティとは異なるため、（網掛けボックスではなく）白で示されている。ＬＯＢの例では、１つまたは複数の会社、アドレス、顧客、および注文を備えたＳａｌｅｓＤａｔａテーブルセット（または「データベース」）を示す。例えばＣｕｓｔｏｍｅｒエンティティは、例えば、住宅ビジネスを表す会社または商業ビジネスを表す会社のいずれかの、一度に１つの会社の一部であることが可能である。図８のＬＯＢモデルにおけるエンティティリレーションシップの概念を示すために、親エンティティであるＣｏｍｐａｎｙは、２つの子エンティティＯｒｄｅｒおよびＣｕｓｔｏｍｅｒを有する。ＣＤＭは論理上、Ｃｏｍｐａｎｙエンティティ内で互いに結合されていない子テーブルを構築する。ＯｒｄｅｒエンティティからＡｄｄｒｅｓｓエンティティへのラインが、子へのアソシエーションである。

ＣＤＭにおける構成の一態様は、会社が注文を設定した場合、その注文セットが他の会社の注文セットとは切り離されるというものである。例えば小売店からの注文が、エンジニアリングからの注文と交差または重複することは決してない。構成は、これらのセットが別々であり、重複せず、共有しないことを意味する。前述のように、アソシエーションは矢印の付いた線によって表される。したがって、ある注文が顧客を参照することが可能であり、同じ顧客を参照する他の注文（図示せず）を生成することができる。ここで、Ｏｒｄｅｒはその直近の同等者（Ｃｕｓｔｏｍｅｒ）を参照する必要はないが、被包含のＡｄｄｒｅｓｓエンティティを直接参照することができる。複数の注文が、ＢｉｌｌｉｎｇＡｄｄｒｅｓｓとラベル表示されたＡｄｄｒｅｓｓを参照することができる。概念上、注文はそのアドレスにいる人物宛に請求されることになる。しかしながら、注文の各ＯｒｄｅｒＬｉｎｅは、各ラインから参照された別々の出荷先アドレスに出荷することができる。それらのアドレスはそれぞれ、注文ラインの親である注文によって参照される同じ顧客からのものである。したがって、参照は顧客に属するアドレス全体にわたって延在する。

ＣＤＭの他の態様は、制約を導入することができる。ＯｒｄｅｒからＣｕｓｔｏｍｅｒ、ＯｒｄｅｒからＡｄｄｒｅｓｓ、およびＯｒｄｅｒＬｉｎｅからＡｄｄｒｅｓｓの、３つのアソシエーションラインを考えてみる。注文またはそのラインによって参照される顧客アドレスが、注文の顧客に属さなければならないという必要はない。アドレスに、他の顧客のアドレスを参照させることが可能である。しかしながらＣＤＭには、アドレスが該当する顧客のものであることを保証するために適用可能な制約が存在する。これが、アソシエーションの「スコーピング」と呼ばれるものである。ＯｒｄｅｒエンティティとＣｕｓｔｏｍｅｒエンティティとの間のアソシエーションに関しては、制約とは、Ｏｒｄｅｒが同じＣｏｍｐａｎｙ内のＣｕｓｔｏｍｅｒのみを参照できることである。すなわち、これらは「共通の祖先（ａｎｃｅｓｔｏｒ）」を有するのである。

ＯｒｄｅｒエンティティとＡｄｄｒｅｓｓエンティティとの間のアソシエーションに関しては、制約とは、Ｏｒｄｅｒが集合テーブル／ＳａｌｅｓＤａｔａ／Ｃｏｍｐａｎｙ／Ｃｕｓｔｏｍｅｒ／Ａｄｄｒｅｓｓ内のＡｄｄｒｅｓｓのみを参照できることである。集合テーブルは、制約内のアドレスおよびプロパティパスによる照会である。ここで、ＳａｌｅｓＤａｔａテーブルセットタイプは、「Ｃｏｍｐａｎｉｅｓ」という名前のテーブルプロパティ８００を有する。各Ｃｕｓｔｏｍｅｒエンティティは、それ自体のＡｄｄｒｅｓｓエンティティのテーブルを有する。それらテーブルの集合（事実上はそれらの共用体（ｕｎｉｏｎ））は、Ａｄｄｒｅｓｓエンティティで、ＴａｂｌｅＮａｍｅ：／ＳａｌｅｓＤａｔａ／Ｃｏｍｐａｎｉｅｓ／Ｃｕｓｔｏｍｅｒｓ／Ａｄｄｒｅｓｓｅｓによってアドレス指定される。

図９は、ＣＤＭに従ったエンティティキーおよび識別子の使用を示す図である。キーとは、特定のテーブル内で一意に識別するエンティティ上の１つまたは複数のプロパティのことであり、ここでもテーブルは構成リレーションシップによって形成される。例えば、顧客に関するキーとして社会保障プロパティを定義することができる。このキーは、例えば、テーブル内で２人の顧客が同じ社会保障番号を持つことがないことを保証する。エンティティのアイデンティティの第２の部分は、エンティティが存在するテーブルである。２人の顧客に同じ名前を付けたい場合、キーを（ここで説明するように）名前以外の何らかのプロパティとして定義すること、またはそれぞれの顧客を異なるテーブルに入れることで、名前の衝突を避けることができる。エンティティテーブルは、テーブルプロパティとテーブルのプロパティ名とを含むエンティティの識別子を提供することによって識別される。したがって、これは再帰的定義である。

図９では、Ａの２つのテーブル（Ｂ上のＡＴａｂｌｅおよびＣ上のＡＴａｂｌｅ）が存在する。Ａについて見ると、その識別子はＡＩＤからなり（＜＜ｋｅｙ＞＞ＡＩＤ）、これはどのテーブル内にあるかも示す。１つの可能性として、これはＡＴａｂｌｅプロパティ内の特定のＢエンティティ内にある。他の可能性として、これはＡＴａｂｌｅプロパティ内の特定のＣエンティティ内にある。実際の例は、典型的にはシーケンス番号である注文ラインのキーである。プロパティ名は、キーとしてマーク付けされたシーケンス番号である。同じシーケンス番号を持つ多くの異なる注文が存在する可能性がある。したがってシーケンス番号は、すべての注文にわたってではなく、その注文内でのみ一意であればよい。

前述のように、ＣＤＭによって提供される他の態様は、テーブルの集合である。例えば、１つの注文に関する注文ラインのテーブルは、別の注文に関する別の注文ラインのテーブルとは切り離される。しかしながら、注文にかかわりなく、ある商品がいくつ注文されたかを知りたい場合がある。したがって、注文にかかわりなく、すべての注文ラインを通じて注文されたウィジェットの数を調べる必要がある。集合テーブルは、これを実行する際の手段である。すなわち、多くの異なる注文または他のエンティティタイプにわたるすべての注文ラインを調べることができる。

次に、開示されたイノベーションのＣＤＭについてより詳細に説明する。ＳＱＬ９９では、キーは行タイプ定義ではなくテーブルに関して定義されるのに対して、このＣＤＭでは、キーはタイプに関して定義される。エンティティタイプ定義からキー定義を切り離すことは自由自在（または拡張可能）であるように見えるかもしれないが、実際にはタイプの再使用可能性および移植性を制限するものである。キーがテーブルに関して定義される場合、タイプ特有の動作は様々なテーブルにわたって働くことができない。すなわち、エンティティタイプに関して作成された何らかのビジネス論理（すなわち、顧客、注文を作成し、それらを関係付けること）が、そのエンティティタイプの様々なストアにわたって働くという保証はなく、それによってタイプの再使用可能性は弱まる。ＳＱＬ９９では、クライアント／中間層アプリケーションプログラミング環境にどのようにタイプをマッピングするかを指定しないので、これは問題ではない。ＳＱＬ９９ではエンティティタイプに関するアイデンティティがないため、エンティティタイプをマッピングするのではなく、タイプテーブルをプログラミング言語オブジェクト（クラス）にマッピングさせる。加えて、アイデンティティをテーブルに関連付けることでは、一時エンティティをサポートすることには対処しない。再使用可能なタイプおよび層にとらわれない（ｔｉｅｒ−ａｇｎｏｓｔｉｃ）タイプの動作をサポートするために、アイデンティティがエンティティタイプに関連付けられる。

エンティティの持続性。エンティティは、エンティティタイプの構築者（新規）方法を呼び出すことによって作成可能であり、エンティティはそれらをテーブルに追加することによって持続する。ＣＤＭでは、エンティティテーブルはエンティティのタイプ別集まりである。エンティティテーブルはＳＱＬ９９のタイプ別テーブルに類似しているが、論理的である。すなわち、エンティティテーブルは１つまたは複数の物理ＳＱＬテーブルにマッピングすることができる。エンティティタイプのテーブルは、タイプのエンティティテーブルと呼ばれる。

エンティティの存続時間は、それがメンバであるテーブルの持続時間に依存する。テーブルが削除された場合、その中のエンティティも削除される。エンティティは、明示的に削除することもできる。

エンティティテーブルは、構成を定義すること、またはエンティティタイプ内にプロパティを指定することによって定義される。論理的には、テーブルのインスタンスは、エンティティタイプのインスタンスが作成された場合に作成され、エンティティインスタンスが削除された場合に削除される（ただし、物理ＳＱＬテーブルは一般に、タイプを定義するスキーマがインストールされた場合に作成され、スキーマがアンインストールされるまで存在する）。

こうした特性は、親エンティティタイプと子エンティティタイプ（この場合は、それぞれＯｒｄｅｒおよびＯｒｄｅｒＬｉｎｅ）との間の構成リレーションシップを定義する。

所与のエンプティタイプのインスタンスを格納するために、任意数のテーブルを作成することができる。各テーブルは完全に独立している（キーは単一のテーブルの範囲内でのみ一意であるなど）。照会可能な所与のタイプのすべてのインスタンスにグローバルな「範囲」はない。

＜ＥｎｔｉｔｙＴｙｐｅ＞要素にＴａｂｌｅ属性を含めることによって、エンティティタイプを単一のテーブルに拘束することができる。これは、エンティティが他のエンティティタイプのテーブルの存在に依存する動作を含むことになる場合に有用である。例えば、ＯｒｄｅｒタイプはＣｕｓｔｏｍｅｒテーブルの存在に依存する（およびその逆も同様）可能性があり、これは、以下の例でＴａｂｌｅ属性を含めることによって反映される。

エンティティにテーブルの制約を課すことにより、そのタイプの複数のテーブルを有することを防ぐ。より拘束性の少ない方法は、リレーションシップの章のアソシエーションの項で説明するように、アソシエーションに制約を課すことである。

テーブルセット。テーブルセットタイプとは、エンティティタイプの制限付きの形である。テーブルセットタイプは、参照およびテーブル値プロパティ、算出プロパティ、および／またはメソッドのみを有することができる。例えば以下のとおりである。

テーブルセットとは、テーブルセットタイプのインスタンスのことである。各テーブルセットインスタンスは、所与のストア内で一意の名前を有する。テーブルセットインスタンスは、スキーマ内で宣言するか、またはストアが提供するオペレーションを使用して動的に作成することができる。スキーマからのテーブルセットインスタンス宣言の一例を以下に示す。

テーブルセット名ならびにテーブルプロパティ名は、照会のＦＲＯＭ節で使用することができる。例えば以下のとおりである。

テーブルセットタイプは、デフォルトのテーブルセットインスタンスを宣言することができる。例えば以下のとおりである。

あらかじめ定義されたテーブルセットを新規のテーブルセットに集合させることも可能である。これは、２つの別々のアプリケーションからのデータを単一のアプリケーションに組み込む場合に有用である。上記の例のＳａｌｅｓＤａｔａエンティティタイプは抽象であることに留意されたい。これは、非抽象エンティティタイプがキープロパティを指定しなければならないためであり、テーブルセットに使用されるエンティティタイプでは単純なタイプのプロパティは許可されない。あらかじめ定義されたテーブルセットを新規のテーブルセットに集合させることが可能である。

エンティティタイプ対インラインタイプ。インラインタイプは非エンティティタイプである。インラインタイプは構造タイプと同様であり、単なる値である。これらはいかなるアイデンティティも有さず、たとえ同一の値を有する場合であっても、各インラインインスタンスは異なる。ＣＤＭでは、インラインタイプはエンティティプロパティのタイプとしてのみ使用可能である。インラインタイプ値は、その一部であるエンティティとインラインで格納される。インラインタイプインスタンスはそれ自体のアイデンティティを持たないため、参照不可能である。これは、インラインタイプインスタンスを保持するエンティティプロパティを介して参照することができる。以下に、インラインタイプ定義の一例を示す。

エンティティタイプとインラインタイプはどちらも強力にタイプ付けされ、同様の構造を有するが、明確な持続性、共有、および操作セマンティクスを有する。インラインタイプインスタンスはそれだけでは存続せず、構造的にはエンティティタイプの一部である。インラインタイプインスタンスは共有不可能であり、各インスタンスの使用は排他的である。インラインタイプインスタンスは、コピー、移動、削除、バックアップ、復元などのほとんどの操作のターゲットではない。

上記のセマンティクスの相違により、アプリケーションが適切にプログラミングできるように、様々なインラインタイプおよびエンティティタイプの概念を提供することが重要である。ＳＱＬ９９では、インラインタイプおよびエンティティタイプの概念は明示的にモデル化されない。ＳＱＬ９９では、「ユーザ定義タイプ」が存在するだけである。あるタイプが列のタイプとして使用されるとインラインタイプのように動作し、これがテーブルの定義に使用されるとエンティティタイプ（行タイプ）として働く。キーはテーブルに関して定義されるため、タイプ付けされたテーブルの行のみがアイデンティティを有する。タイプはキーを持たないため、ＳＱＬでは、タイプインスタンスに関して推論する場合、キーを持ったタイプインスタンスおよびキーを持たないインスタンスに関して話さなければならない。

ＣＤＭでは、エンティティタイプおよびインラインタイプは、別々の構文仕様を備えた別々の概念として明示的にモデル化される。

データの並行性。データの並行性は、楽観的または悲観的のいずれかで管理することができる。どちらの場合も並行性管理の単位は、楽観的並行性における競合の検出または悲観的並行性におけるロックの、いずれかに関するエンティティである。データモデルは、異なる競合検出スキームが使用可能であることを許可し、データモデルインプリメンテーションがそれらにその柔軟性を与えた場合、これをデータモデルインプリメンテーションおよび開発者のポリシー決定とみなす（例えば、更新されるプロパティが何も変更されていない場合、インプリメンテーションは競合を無視することができる）。

悲観的並行性の場合、そのネストされたテーブルを除外する完全なエンティティでロックがかけられる。したがって、エンティティがロックで読み取られる場合、他のユーザがそのエンティティをロックしていれば読み取りは失敗することになる。しかしながら、子エンティティのみがロックされている場合、親の読み取りは成功することになる。データモデルは、異なるロッキングスキームの使用を可能にし、データモデルインプリメンテーションがそれらにその柔軟性を与えた場合、これをデータモデルインプリメンテーションおよび開発者のポリシー決定とみなす。

リレーションシップ。リレーションシップとは、２つまたはそれ以上のエンティティを関係付けることである。例えば、連絡先はドキュメントを著作する、またはＯｒｄｅｒはＯｒｄｅｒＬｉｎｅを含む。リレーションシップはアソシエーションまたは構成とすることができる。アソシエーションはエンティティ間の「ピアツーピア」リレーションシップを記述し、構成は２つのエンティティ間の親／子のリレーションシップを記述する。

リレーションシップ自体はタイプのインスタンスとしてストアに格納されないが、関係するエンティティ上のデータによって具体化される。アソシエーションの特定の使用法の１つが、エンティティタイプであるアソシエーションエンティティをリレーションシップを具体化するエンティティとして指定するものであり、オプションで、リレーションシップの一部として追加のデータを格納することができる。各アソシエーションには名前があり、その名前がエンティティ間のセマンティックなリレーションシップを指定する。例えば、ＤｏｃＡｕｔｈｏｒは、ドキュメントと連絡先の間のリレーションシップの名前であり、ＤｏｃＡｕｔｈｏｒアソシエーションは連絡先をドキュメントの著者として関係付け、同様に、ＯｒｄｅｒＣｕｓｔｏｍｅｒは顧客を注文に関連付けるアソシエーションであり、注文が与えられると、アソシエーションをナビゲートしてその顧客を決定させることができる。

アソシエーションおよび構成の概念は、ＵＭＬアソシエーションおよび構成の概念と一貫していることに留意されたい。エンティティ−リレーションシップの図表作成およびＵＭＬ用語（例えば、ロール（Ｒｏｌｅ）、多重度（ｍｕｌｔｉｐｌｉｃｉｔｙ）など）は、可能な限り多数保持される。

リレーションシップの概念は、リレーショナルモデル内で明示的にサポートされない。外部および１次キーならびに参照整合性は、制限された方法でリレーションシップを実施するためのツールを提供する。ＳＱＬ９９は、単一および複数のエンティティ値プロパティをサポートするためにＲｅｆおよびＴａｂｌｅタイプのようにオブジェクト−リレーショナル拡張子を追加したが、リレーションシップは正式にモデル化されていない。

ＣＤＭでは、ＳＱＬ９９の参照およびテーブルプロパティと、ＵＭＬのアソシエーションおよび構成の概念とを組み合わせる。この方法により、リッチなリレーションシップおよびナビゲーションがＳＱＬに与えられ、ＵＭＬを使用してモデル化されたアプリケーションに照会可能性が与えられる。

アソシエーション。アソシエーションは、エンティティ間でのピアツーピアのリレーションシップを表す。これらは、参照タイプのプロパティまたは非参照タイプのプロパティの使用に基づくものとすることができる。また、特定の役割を果たすアソシエーションエンティティを含むこともできる。次に、それぞれについて説明する。

参照タイプのプロパティを使用するアソシエーション。以下のスキーマ例について考えてみる。

アソシエーションには２つのエンドがあり、そのそれぞれが関係エンティティを表す。各エンドは以下の両方を提供する。
・ロール：ロールは、エンティティタイプのインスタンスがそのエンドで果たす役割または機能を記述する名前を、エンドポイントに付ける。これは、アソシエーションの他方のエンドにあるエンティティによって使用される名前である。ＣＤＭでは、ロール名は明示的に指定されなければならないが、しばしばエンドのエンティティタイプの名前となる。
・タイプ：タイプは、エンドのエンティティタイプの名前を指定する。例えば、ＯｒｄｅｒＣｕｓｔｏｍｅｒアソシエーションでは、ロールＣｕｓｔｏｍｅｒＲｏｌｅのエンドのタイプは、Ｃｕｓｔｏｍｅｒタイプである。ＯｒｄｅｒＲｏｌｅのタイプはＯｒｄｅｒエンティティタイプである。タイプはエンティティタイプでなければならない（インラインタイプは不可である）。
・多重度：多重度は、アソシエーションエンドの正当な濃度（ｃａｒｄｉｎａｌｉｔｙ）値の範囲を指定する。リレーションシップエンドの濃度は、そのエンドでのリレーションシップに関与するエンティティインスタンスの実際の数である。ＯｒｄｅｒＣｕｓｔｏｍｅｒアソシエーションの例では、Ｏｒｄｅｒは厳密に１人のＣｕｓｔｏｍｅｒからのものであり、それぞれのＯｒｄｅｒはＣｕｓｔｏｍｅｒによって発注されなければならない。したがって、多重度は「１」である。この制約は、ＣｕｓｔｏｍｅｒＲｏｌｅエンドでＭｕｌｔｉｐｌｉｃｉｔｙ＝「１」としてキャプチャされる。他方で、Ｃｕｓｔｏｍｅｒはこれに関連する無数の注文を有することができる。ＯｒｄｅｒＲｏｌｅエンドでのＭｕｌｔｉｐｌｉｃｉｔｙ＝「^＊」は、こうした濃度制約をキャプチャする。

通常の多重度値は「０．．１」（ゼロまたは１）、「１」（厳密に１）、「^＊」（ゼロまたはそれ以上）、および「１．．＊」（１または複数）である。より一般的には、多重度値は値「ｎ」（厳密にｎ）または値の範囲「ｎ．．ｍ」（ｎおよびｍを含めてｎからｍの間、ｎはｍよりも少ないかまたは等しい）を指定することができる。通常、アソシエーションの両エンドの多重度は、まとめて１：１（１対１）、１：^＊（１対多数）、^＊：１（多数対１）、および^＊：^＊（多数対多数）と表される。前述のＯｒｄｅｒＣｕｓｔｏｍｅｒアソシエーションの例では、同じ顧客（同じＣｕｓｔＲｅｆプロパティ値を有する）にゼロまたはそれ以上の注文が存在可能である。参照整合性制約のセマンティクス制限は、エンドに適切に多重度を設定することによってモデル化可能であることに留意されたい。多重度の下限が１の場合、従来のセマンティクス制限が課される。すなわち、あらゆる注文に顧客が存在しなければならない。したがって、顧客がいなければ注文は作成不可能であり、同様に、顧客が発注した場合は顧客を削除できない。
・テーブル：タイプのインスタンスを見つけることができるテーブルに制約を与える。これは、ターゲットエンティティタイプの定義でテーブルが直接指定されない限り、参照ベースのアソシエーションのターゲットに必要である。前述の例では、これは、Ｏｒｄｅｒ上のＣｕｓｔｏｍｅｒが、ＳａｌｅｓＤａｔａ．ＢａｄＣｕｓｔｏｍｅｒｓではなくＳａｌｅｓＤａｔａ．Ｃｕｓｔｏｍｅｒｓテーブルにのみ見つけることができることを示す。Ｔａｂｌｅ＝””の指定は、参照が正しいタイプの任意のテーブルにあるエンティティを参照できることを示す。
・ＯｎＤｅｌｅｔｅ：ＯｎＤｅｌｅｔｅ属性は、そのエンドのエンティティが削除された場合に何をすべきかを指定する。この例では、許可される値はＣａｓｃａｄｅ、ＳｅｔＮｕｌｌ、またはＲｅｓｔｒｉｃｔとなる。この例では、以下のとおりである。
□ Ｃａｓｃａｄｅが指定されたため、Ｃｕｓｔｏｍｅｒエンティティが削除されると、Ｏｒｄｅｒエンティティも削除される。
□ 他方で、ＳｅｔＮｕｌｌが指定された場合、Ｃｕｓｔｏｍｅｒエンティティが削除されると、ＯｒｄｅｒエンティティのＣｕｓｔＲｅｆプロパティはＮｕｌｌに設定されることになる。プロパティはｎｕｌｌ可能である。
□ Ｒｅｓｔｒｉｃｔが指定された場合、Ｏｒｄｅｒエンティティがこれに関連付けられると、Ｃｕｓｔｏｍｅｒエンティティは削除できない。

＜Ｒｅｆｅｒｅｎｃｅ＞要素は、これが参照ベースのアソシエーションであることを示す。この要素は、ＦｒｏｍＲｏｌｅがアソシエーションをインプリメントする参照プロパティを含む役割であること、ＴｏＲｏｌｅが参照のターゲットの役割であること、およびＰｒｏｐｅｒｔｙが参照プロパティの名前であること、という情報を指定する。

ＯｒｄｅｒＣｕｓｔｏｍｅｒアソシエーションでは、ＯｒｄｅｒＲｏｌｅエンドのＣｕｓｔＲｅｆプロパティは、ＣｕｓｔｏｍｅｒＲｏｌｅエンティティの識別子に関係し、ＣｕｓｔＲｅｆプロパティは外部キーと同様に働く。

非参照タイプのプロパティを使用するアソシエーション。前述のＯｒｄｅｒＣｕｓｔｏｍｅｒアソシエーションは、顧客のアイデンティティの注文エンティティタイプと顧客エンティティタイプを関係付ける。一般に、エンドの任意のプロパティで２つのエンティティタイプを関係付けることが可能である。例えば以下の、Ｄｏｃｕｍｅｎｔ．ＡｕｔｈｏｒプロパティがＣｏｎｔａｃｔ．Ｎａｍｅに関係付けられたＤｏｃｕｍｅｎｔＡｕｔｈｏｒアソシエーションについて考えてみる。Ｃｏｎｔａｃｔ．Ｎａｍｅは一意ではないため、このアソシエーションはドキュメントに関して複数の連絡先を戻すことができる。

この例とＣｕｓｔｏｍｅｒ／Ｏｒｄｅｒ例との間の相違点の１つが、＜Ｒｅｆｅｒｅｎｃｅ＞要素を指定する代わりに、＜Ｃｏｎｄｉｔｉｏｎ＞要素内に論理式が提供されることである。＜Ｃｏｎｄｉｔｉｏｎ＞は任意の複雑さの式を含むことが可能であるため、これは非常に柔軟な形のアソシエーションである。実際に、アプリケーションでの結合を照会およびプログラミングモデルの最上（ｆｉｒｓｔ）クラス部分として追加することによって、再使用しやすくしている。

２つのプロパティ間で単純な等価のみが必要な場合、単純化された構文がサポートされる。このような場合、＜Ｃｏｎｄｉｔｉｏｎ＞要素の代わりに＜ＣｏｍｍｏｎＶａｌｕｅ＞要素を使用することができる。以下の例は、前の例と同じ意味を持つ（以下で説明するＯｎＵｐｄａｔｅ動作は除く）。

プロパティは明示的にリストされ、常に同じ値を有するため、１つの追加機能、ＯｎＵｐｄａｔｅ属性が使用可能である。この属性の可能な値は、Ｃａｓｃａｄｅ、ＳｅｔＮｕｌｌ、またはＲｅｓｔｒｉｃｔである。この例では、「Ｃａｓｃａｄｅ」の属性値は、ＣｏｎｔａｃｔＲｏｌｅエンドのプロパティが更新された場合、この値が他方のエンドのプロパティに伝搬され、ＯｎＵｐｄａｔｅ＝「Ｒｅｓｔｒｉｃｔ」の場合、他方のエンドに関連付けられたエンティティがあればこのプロパティは変更不可能であり、ＯｎＵｐｄａｔｅ＝「ＳｅｔＮｕｌｌ」の場合、このエンドのプロパティが更新されれば他方のエンドのプロパティはｎｕｌｌに設定される。

アソシエーションエンティティ。プロパティをリレーションシップに関連付けるのが一般的である。例えば、通常、組織と人物との間の雇用関係は、ＥｍｐｌｏｙｍｅｎｔＰｅｒｉｏｄなどのプロパティを伴う。ＯｒｇａｎｉｚａｔｉｏｎまたはＰｅｒｓｏｎタイプのプロパティ部分は作成可能であるが、プロパティはリレーションシップなしでは何の意味もなさない。例えば、ＯｒｇａｎｉｚａｔｉｏｎのＥｍｐｌｏｙｍｅｎｔＰｅｒｉｏｄプロパティは雇用された人物も存在していない限り無意味であり、同様に、このプロパティはＰｅｒｓｏｎエンティティでは無意味である。

ＣＤＭでは、エンティティ（エンティティタイプインスタンス）のみが持続する。エンティティ（実際にはエンティティのテーブル）のみが照会可能である。アソシエーションおよび構成はメタデータとして格納される。したがって、アソシエーションのプロパティはエンティティに格納しなければならない。こうしたエンティティがアソシエーションエンティティである。これは、ＵＭＬでのアソシエーションクラスと同じ役割を果たす。アソシエーションエンティティタイプはリレーショナルシステムにおける中間（リンクまたは結合）テーブルと同様であり、エンティティへの参照（外部キー）によってリンクされている。アソシエーションエンティティのキーは、一般に、関係するエンティティへの参照を含む。例えば以下の例を考えてみる。

ＰＳＬｉｎｋは、製品と供給業者とをリンクしているエンティティタイプである。ＰＳＬｉｎｋは、２つの参照プロパティ、ＰｒｏｄｕｃｔＲｅｆとＳｕｐｐｌｉｅｒＲｅｆとを指定することによって、ＰｒｏｄｕｃｔタイプおよびＳｕｐｐｌｉｅｒタイプをそれぞれＰｒｏｄｕｃｔタイプおよびＳｕｐｐｌｉｅｒタイプに関係付ける。製品と供給業者とを関係付けることに加えて、リレーションシップに有意なプロパティ、ＰｒｉｃｅおよびＱｕａｎｔｉｔｙを有する。

Ｐｒｏｄｕｃｔ、Ｓｕｐｐｌｉｅｒ、およびＰＳＬｉｎｋの間で可能なアソシエーションは、ＰＳＬｉｎｋとＰｒｏｄｕｃｔ、ＰＳＬｉｎｋとＳｕｐｐｌｉｅｒ、およびＰｒｏｄｕｃｔとＳｕｐｐｌｉｅｒの間である。これらのアソシエーションは、以下のように明示的に定義することができる。

上記の例では、ＰＳＬｉｎｋがアソシエーションエンティティであるという事実が明白でないため、アソシエーションの定義では使用できない。スキーマ設計者はすべての必要なアソシエーション定義を長々と定義しなければならない。しかしながらこれは、明示的アソシエーションエンティティの概念をアソシエーション定義の一部として導入することで避けられる。前述の例は、ＰＳＬｉｎｋをアソシエーションエンティティとして指定することで以下のように書き換えられる。

この例に関して、以下の面に留意されたい。
・これは、アソシエーションエンティティが明示的に呼び出されない場合は推論不可能なタイプに関する情報を提供するものであるため、他の宣言の単なる短縮形ではない。
・ＰＳＬｉｎｋの＜ＥｎｔｉｔｙＴｙｐｅ＞定義のＡｓｓｏｃｉａｔｉｏｎ属性は、このタイプをアソシエーションエンティティとして識別し、このタイプを使用するアソシエーションを識別する。
・ＰｒｏｄｕｃｔＲｅｆおよびＳｕｐｐｌｉｅｒＲｅｆのプロパティ要素のＲｏｌｅ属性は、これらのプロパティを使用するアソシエーション内の役割を識別する。
・ＡｓｓｏｃｉａｔｉｏｎＥｎｔｉｔｙの内部にネストされたＥｎｄ要素は、アソシエーションエンティティ自体の果たす役割に名前を与える。多くの場合、アソシエーションエンティティは多重アソシエーションの単なるエンドポイントであるが、その他の場合には、アソシエーションにおいて特別な機能を果たす。
・＜Ｒｅｆｅｒｅｎｃｅ＞要素は、アソシエーションエンティティがＰｒｏｄｕｃｔおよびＳｕｐｐｌｉｅｒエンティティにどのように関連付けるかを記述する。これらはアソシエーション全体に従属するものであるため、ネストされる。
・Ｅｎｄ要素のＯｎＤｅｌｅｔｅ属性は、どちらかのエンドが削除された場合、アソシエーションエンティティも、したがってリレーションシップも、削除されることを示す。しかしながら、一方のエンドを削除しても、他方のエンドを削除することにはならない（すなわち、供給業者を削除しても、供給される製品を削除することにはならない）。この属性の他の可能な値は、すべてのエンド（アソシエーションエンティティを含む）を削除することになるＣａｓｃａｄｅ、アソシエーションエンティティの参照プロパティをｎｕｌｌに設定することになるＳｅｔＮｕｌｌ、または、ＰＳＬｉｎｋインスタンスが存在する限り削除が失敗することになるＲｅｓｔｒｉｃｔである。

アソシエーションエンティティは、非参照タイププロパティを使用するアソシエーションでも使用することができる。詳細については、本明細書で後述するアソシエーションの完全な説明を参照されたい。

アソシエーションのスコーピング。アソシエーションをスコーピングすることで、アソシエーションの両エンドのエンティティが同じエンティティインスタンスの子であることを指定する。アソシエーションは、両方のエンドを含むエンティティタイプの名前をＳｃｏｐｅ属性に配置することによってスコーピングされる。エンドのＴａｂｌｅ属性は、そのタイプで始まらなくてはならない。ＣａｓがＥｎｇｉｎｅ、Ｗｈｅｅｌｓ、およびＤｒｉｖｅＴｒａｉｎを有する、以下の例について考えてみる。

ＥｎｇｉｎｅおよびＷｈｅｅｌｓはＤｒｉｖｅＴｒａｉｎによって接続される。

上記の例は、ＤｒｉｖｅＴｒａｉｎが同じＣａｒからのＥｎｇｉｎｅおよびＷｈｅｅｌｓを接続することを示す。１つのＣａｒからのＥｎｇｉｎｅを別のＣａｒからのＷｈｅｅｌｓに取り付けることは不当である。＜Ｅｎｄ＞要素上の任意のＴａｂｌｅ属性はスコーピングエンティティで始まらなければならない。＜Ｅｎｄ＞要素は、Ｓｃｏｐｅｄ＝「ｆａｌｓｅ」属性を追加することによって、スコーピングがこれに適用されないことを示すことができる。

構成。構成は、２つのエンティティ間の構成上のリレーションシップを定義するモデリング概念である。ここでもＯｒｄｅｒ例について考えてみると、ＬｉｎｅｓプロパティおよびＯｒｄｅｒＬｉｎｅｓリレーションシップは、ＯｒｄｅｒエンティティタイプとＬｉｎｅエンティティタイプとの間の構成を定義する。ＯｒｄｅｒタイプとＬｉｎｅタイプとの間には構造的なリレーションシップが存在し、ラインは注文の一部である（または注文内で構成される）。ラインエンティティは単一の注文エンティティに属し、ラインエンティティは排他的に注文の一部であり、注文およびそのラインが操作ユニットを形成する。

これに対して、上記の例でＯｒｄｅｒおよびＣｕｓｔｏｍｅｒは独立したエンティティである。ＯｒｄｅｒｓテーブルおよびＣｕｓｔｏｍｅｒｓテーブルは互いに独立している。ＯｒｄｅｒＣｕｓｔｏｍｅｒアソシエーションは、注文と顧客とを関係付ける。アソシエーションでＯｎＤｅｌｅｔｅ＝Ｃａｓｃａｄｅが指定されない限り、注文および顧客の持続時間は互いに独立している。ＯｎＤｅｌｅｔｅ＝Ｃａｓｃａｄｅは、顧客が削除された場合、顧客に関連付けられた注文を削除する必要がある旨の動作上の制約を追加する。しかしながら、注文と顧客のエンティティタイプの間には構造的なリレーションシップは存在しない。例えば、顧客エンティティをフェッチしてもいずれの注文にもアクセスせず、その逆もまた同様である。加えて、Ｏｒｄｅｒは他の、しかし同様のＳｕｐｐｌｉｅｒとのアソシエーションに関与することが可能であり、すなわちＯｒｄｅｒ上のＳｕｐｐｌｉｅｒＲｅｆプロパティおよびＯｒｄｅｒＳｕｐｐｌｉｅｒアソシエーションが存在する。このアソシエーションは、ＯｎＤｅｌｅｔｅ＝「Ｃａｓｃａｄｅ」も指定可能であり、これはＯｒｄｅｒの持続時間が、注文を出した顧客または注文を供給する供給業者のいずれかによって制御されることを意味する。しかしながら、ＯｒｄｅｒおよびＣｕｓｔｏｍｅｒまたはＯｒｄｅｒおよびＳｕｐｐｌｉｅｒは、コピー、移動、バックアップ、復元などの操作用の操作ユニットは構成しない。

構成がアソシエーション概念をさらに特殊化したものであることは確かであるが、これは、特に構造上および操作上の観点から見た基本的な概念である。ＯｒｄｅｒとＬｉｎｅｓとの間のリレーションシップは、ＯｒｄｅｒとＣｕｓｔｏｍｅｒとの間のものとはかなり異なる。したがってＣＤＭでは、構成は明確なトップレベルの概念である。

構成およびアソシエーションエンティティ。アソシエーションエンティティの１つの特定の使用法は、アソシエーションエンティティ自体を関連付けられたエンティティの１つに組み込むことである。以下の例について考えてみる。

ここでは、Ｌｉｎｋエンティティタイプのネストされたテーブルを含むエンティティタイプ、Ｉｔｅｍ（商品）が使用されている。Ｌｉｎｋタイプそれ自体は、２つの関係するエンティティ（この場合は２つの商品）の間に位置するアソシエーションエンティティであり、リレーションシップ特有のプロパティを含む。構成がＩｔｅｍとＬｉｎｋを関係付けることであるという事実が、モデル化されているリレーションシップが２つのＩｔｅｍの間にあるという事実を変えることはない。

ナビゲーション。モデリングリレーションシップの特典の１つが、リレーションシップ定義を使用して１つのエンティティから関係するエンティティへナビゲートする機能であることは明白である。こうしたナビゲーションは、ＣＤＭに対する照会を介して、またはエンティティタイプおよびリレーションシップの定義から生成されたＡＰＩクラスを使用することによって、サポートすることができる。ＯｒｄｅｒＣｕｓｔｏｍｅｒの例で、注文エンティティが与えられた場合、ＣｕｓｔＲｅｆプロパティおよびアソシエーション定義を使用してその顧客にナビゲートすることができる。アソシエーション定義は、顧客からその注文へのナビゲートにも使用することができる。アソシエーションメタデータを使用して、顧客から注文へとトラバースするために結合ベースの照会を生成することができる。同様に、ＤｏｃｕｍｅｎｔＡｕｔｈｏｒアソシエーションを使用して、ドキュメントから連絡先へのナビゲーションを生成することが可能であり、その逆も同様である。

ＣＤＭでは、リレーションシップ定義を使用してアソシエーションベースのナビゲーションプロパティを事前に定義することが可能である。こうしたナビゲーションプロパティの一例を以下に示す。

Ｃｕｓｔｏｍｅｒエンティティ内のＮａｖｉｇａｔｉｏｎＰｒｏｐｅｒｔｙ要素は、顧客から顧客に関連付けられた注文へのナビゲーションパスを指定する。このプロパティは、照会およびプログラミングモデルの中で、Ｏｒｄｅｒエンティティへの参照の仮想上の（具体化されていない）および照会可能な読み取り専用の集まりとして表すことができる。

以下に、ＣＤＭスキーマ言語について説明する。すべてのエンティティ、リレーションシップ、およびテーブルセットの定義は、スキーマとの関連において生じる。スキーマは、スキーマ内に定義されたものの名前をスコーピングするネームスペースを定義する。＜Ｓｃｈｅｍａ＞要素は、スキーマドキュメントのルート要素である。＜Ｓｃｈｅｍａ＞要素は以下の属性を持つことができる。
・Ｎａｍｅｓｐａｃｅ（ネームスペース）−−必須。スキーマ用の一意のネームスペース。ネームスペースは、ネームスペース名に関するＣＬＲ規則に準拠する。加えて、ＣＬＲネームスペースに関して定義されたネームスペースの命名ガイドラインにも従うものとする。これらの規約に従うことによって、ネームスペース名を選択する場合に一意性が十分に保証される。

例えば以下のとおりである。

スキーマは、完全修飾タイプ名（ｎａｍｅｓｐａｃｅ−ｎａｍｅ．ｔｙｐｅ−ｎａｍｅ）を使用して異なるスキーマで定義されたタイプを参照することができる。例えば以下のとおりである。

スキーマは、外部スキーマに定義されたタイプ名をスコープに入れるために＜Ｕｓｉｎｇ＞要素を含めることができる。＜Ｕｓｉｎｇ＞要素は以下の属性を有することができる。
・Ｎａｍｅｓｐａｃｅ（ネームスペース）−−必須。コンテンツがスコープに入れられるスキーマのネームスペース。
・Ａｌｉａｓ（別名）−−オプション。ネームスペースの代替として使用可能な名前。

例えば以下のとおりである。

命名規則。すべてのタイプ、リレーションシップ、およびテーブルセットの名前は、タイプ名に関するＣＬＲ規則に準拠しなければならない。名前は．ＮｅｔＦｒａｍｅｗｏｒｋタイプ命名ガイドラインにも準拠するものとする。タイプおよびリレーションシップの名前は一意であるものとする。すなわち、タイプおよびリレーションシップが同じ完全修飾名を持つことは不可能であり、２つのタイプまたは２つのリレーションシップが同じ完全修飾名を持つことは不可能である。すべてのテーブルセット名は一意である（２つのテーブルセットが同じ完全修飾名を持つことは不可能である）ものとするが、テーブルセットがタイプまたはリレーションシップと同じ名前を持つことは可能である。

単純タイプ。単純タイプとは、データモデル内に可視の内部構造を持たない単一の値を表すものである。ＣＬＲ値タイプは、ＣＤＭで単純タイプとして使用される。ＣＬＲのＳｙｓｔｅｍ、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ、およびＳｙｓｔｅｍ．Ｄａｔａ．ＳｑｌＴｙｐｅｓネームスペースで定義されるいくつかの値タイプは、本来、データモデルで使用するためにサポートされる。これらのタイプは以下のとおりである。

要件セットを満たす任意の値タイプは、データモデル内で単純タイプとしても使用できるものとする。こうしたタイプが満たす必要のある条件は、照会内に格納して直接使用できるようにすること（ＵＤＴなど）、またはＣＬＲ属性を介してストレージおよび照会のマッピングを提供するために必要なメタデータを提供することである。

単純タイプの制約。以下で定義された制約要素のうちの１つを使用して、単純タイプの値を制約することが可能である。これらの要素を、単純タイプを参照する様々な要素内にネストすることができる（例えば、＜ＥｎｔｉｔｙＴｙｐｅ＞または＜ＩｎｌｉｎｅＴｙｐｅ＞要素内の＜Ｐｒｏｐｅｒｔｙ＞要素）。

長さ。＜Ｌｅｎｇｔｈ＞制約要素をＳｙｓｔｅｍ．Ｓｔｒｉｎｇ、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．ＢｙＣｏｌｌｅｃｔｉｏｎ、およびＳｙｓｔｅｍ．Ｄａｔａ．ＳｑｌＴｙｐｅｓ．Ｓｔｒｉｎｇのタイプに適用して、値の長さを制約することができる。この要素は以下の属性を含むことができる。
・Ｍｉｎｉｍｕｍ−−値の最小長さ。デフォルト値はゼロである。
・Ｍａｘｉｍｕｍ−−値の最大長さ。値「ｕｎｂｏｕｎｄｅｄ」は、指定された最大長さが存在しないことを示す。デフォルト値は「ｕｎｂｏｕｎｄｅｄ」である。

基本タイプに指定された制約に適合するためには、Ｍｉｎｉｍｕｍに指定された値が以前の値に等しいかまたはこれより大きくなければならず、Ｍａｘｉｍｕｍに指定された値が以前の値に等しいかまたはこれより小さくなければならない。

１０進数。＜Ｄｅｃｉｍａｌ＞制約要素をＳｙｓｔｅｍ．ＤｅｃｉｍａｌおよびＳｙｓｔｅｍ．ＳｑｌＤｅｃｉｍａｌのタイプに適用して、受け入れ可能な値の精度およびスケールを制約することができる。この要素はＰｒｅｃｉｓｉｏｎおよびＳｃａｌｅ属性を含むことができる。

デフォルト。＜Ｄｅｆａｕｌｔ＞制約要素を任意の単純タイプに適用して、プロパティに使用するデフォルト値を指定することができる。この要素は、以下の属性を有することができる。Ｖａｌｕｅ−−必須。プロパティのデフォルト値。この属性の値はプロパティタイプの値に変換可能でなければならない。＜Ｄｅｆａｕｌｔ＞要素は実際には制約を指定しないことに留意されたい。基本タイプで指定された値に任意の値を適合させることができる。

チェック。＜Ｃｈｅｃｋ＞制約要素はブール照会式を含むことができる。有効にすべきプロパティ値について、この式が真であることを評価しなければならない。この式は、いかなる副次作用も有してはならない。チェック制約が基本タイプおよび派生タイプの両方に指定された場合、どちらの制約も妥当性が検査される。

列挙タイプ。列挙タイプは、一意の値を表す名前のセットを定義する。基礎となる値のタイプはＣＤＭでは可視であり、格納された値それ自体は不可視である。顧客のストレージマッピングが使用される場合、基礎となるタイプはこのマッピングによって定義される。禁止的（ｐｒｏｓｃｒｉｐｔｉｖｅ）ストレージの場合、基礎となるタイプは自動的に選択されるか、またはストレージ特有のヒントを介して提供することができる。列挙タイプは＜ＥｎｕｍｅｒａｔｉｏｎＴｙｐｅ＞要素を使用して宣言される。この要素は以下の属性を有することができる。
・Ｎａｍｅ−−必須。列挙タイプの名前。
・Ｅｘｔｅｎｓｉｂｌｅ−−オプション。値「ｔｒｕｅ」は、＜ＥｎｕｍｅｒａｔｉｏｎＥｘｔｅｎｓｉｏｎ＞要素を使用して列挙タイプが拡張可能であることを示す（以下を参照）。値「ｆａｌｓｅ」は、拡張が使用できないことを示す。デフォルト値は「ｆａｌｓｅ」である。

＜ＥｎｕｍｅｒａｔｉｏｎＴｙｐｅ＞要素はゼロまたはそれ以上の＜ＥｎｕｍｅｒａｔｉｏｎＭｅｍｂｅｒ＞要素を含むことができる。これらの要素は以下の属性を有することができる。
・Ｎａｍｅ−−必須。特定の列挙値を表すために使用される。この名前は宣言＜ＥｎｕｍｅｒａｔｉｏｎＴｙｐｅ＞要素内で一意でなければならない。列挙メンバを参照する場合、この名前は常に列挙のタイプ名によって修飾される。
・ＡｌｉａｓｅｓＭｅｍｂｅｒ−−オプション。他の列挙メンバの名前を含む。この列挙メンバが命名されたメンバの別名であることを示す（どちらの名前も同じ値を表す）。

列挙の一例を以下に定義する。

「ｂｉｔｆｌａｇ」スタイルの列挙は列挙タイプを使用して記述できないことに留意されたい。代わりに列挙タイプのアレイを使用することが必要である。

拡張可能な列挙。＜ＥｎｕｍｅｒａｔｉｏｎＴｙｐｅ＞要素がＥｘｔｅｎｓｉｂｌｅ＝「ｔｒｕｅ」を指定する場合、追加の値を使用して列挙を拡張することができる。列挙タイプのプロパティは、＜ＥｎｕｍｅｒａｔｉｏｎＴｙｐｅ＞内またはそのタイプの任意の拡張内に指定された値のいずれかを含むことができる。

各拡張に定義された値は、基本列挙タイプおよびすべての他の拡張内に定義された値とは異なる。これにより、複数の開発者が競合の可能性なしに列挙タイプを独立に拡張することができる。

列挙拡張タイプは＜ＥｎｕｍｅｒａｔｉｏｎＥｘｔｅｎｓｉｏｎＴｙｐｅ＞要素を使用して定義される。この要素は以下の属性を有することができる。
・Ｎａｍｅ−−必須。列挙拡張タイプの名前。
・ＥｘｔｅｎｄｓＴｙｐｅ−−必須。拡張される列挙タイプの名前。

＜ＥｎｕｍｅｒａｔｉｏｎＥｘｔｅｎｓｉｏｎＴｙｐｅ＞要素は、ゼロまたはそれ以上の＜ＥｎｕｍｅｒａｔｉｏｎＭｅｍｂｅｒ＞要素を含むことができる。これらの要素は以下の属性を有することができる。
・Ｎａｍｅ−−必須。特定の列挙値を表す際に使用される名前。この名前は宣言＜ＥｎｕｍｅｒａｔｉｏｎＥｘｔｅｎｓｉｏｎＴｙｐｅ＞要素内で一意でなければならない。
しかしながらこの名前は、拡張された列挙タイプ内の名前と重複する場合がある。こうした場合、拡張内で定義された値と拡張された列挙内で定義された値とは依然として異なる。
列挙メンバを参照する場合、この名前は列挙拡張のタイプ名によって常に修飾される。
・ＡｌｉａｓｅｓＭｅｍｂｅｒ−−オプション。この拡張、同じ列挙タイプへの他の拡張、または拡張された列挙タイプそれ自体、のいずれかに、他の列挙メンバのフルネーム（ｅｎｕｍｅｒａｔｉｏｎ−ｔｙｐｅ−ｎａｍｅ．ｅｎｕｍｅｒａｔｉｏｎ−ｍｅｍｂｅｒ−ｎａｍｅ）を含む。この列挙メンバは命名されたメンバの別名であることを示す（例えば、どちらの名前も同じ値を表す）。

列挙の例を以下に定義する。

＜！−−
列挙タイプＣと拡張タイプＤおよびＥとの組合せは、タイプＣのプロパティに格納可能な別個の値、Ｃ．Ｐ、Ｃ．Ｑ、Ｄ．Ｑ、Ｄ．Ｓ、Ｅ．Ｔ、およびＥ．Ｕを定義する。列挙メンバＣ．Ｒ、Ｄ．Ｔ、およびＥ．ＵはすべてＣ．Ｑの別名であるため、一意の値を表さない。

−−＞

アレイタイプ。アレイタイプのインスタンスは、指定された単純、インライン、列挙、エンティティ参照、またはテーブル参照のタイプの複数のインスタンスを格納することができる（アレイのアレイは許可されない）。これらのインスタンスはアレイの要素である。要素の順序は保存され、アプリケーションによって明示的に維持することができる。アプリケーションは要素をアレイに挿入すること、および要素をアレイから削除することができる。アレイタイプは以下の構文を使用して指定される。

ここでｅｌｅｍｅｎｔ−ｔｙｐｅは要素のタイプの名前である。

アレイタイプの制約。以下で定義した制約要素のうちの１つを使用して、アレイタイプの値を制約することができる。これらの要素を、アレイタイプを参照する様々な要素の内部にネストすることができる（例えば、＜ＥｎｔｉｔｙＴｙｐｅ＞または＜ＩｎｌｉｎｅＴｙｐｅ＞要素内の＜Ｐｒｏｐｅｒｔｙ＞要素）。

要素の制約。＜ＥｌｅｍｅｎｔＣｏｎｓｔｒａｉｎｔ＞制約要素を使用して、アレイ内の要素に制約を与えることができる。要素タイプに対して有効な制約要素は、＜ＥｌｅｍｅｎｔＣｏｎｓｔｒａｉｎｔ＞要素内部に指定することができる。

発生数（Ｏｃｃｕｒｓ）。＜Ｏｃｃｕｒｓ＞制約要素を使用して、アレイ内の要素の数を制約することができる。この要素は以下の属性を有することができる。
・Ｍｉｎｉｍｕｍ−−オプション。アレイ内のエントリの最小数を指定する。デフォルト値はゼロ。
・Ｍａｘｉｍｕｍ−−オプション。アレイ内のエントリの最大数を指定する。値「ｕｎｂｏｕｎｄｅｄ」は、制約が存在しないことを示す。デフォルト値は「ｕｎｂｏｕｎｄｅｄ」である。

一意。＜Ｕｎｉｑｕｅ＞制約要素を使用して、一意の値をアレイ内に含めなければならない要素タイプのプロパティを指定することができる。この要素は以下の属性を有することができる。Ｐｒｏｐｅｒｔｉｅｓ−−必須。コンマで区切られた要素プロパティ名のリスト。

チェック。＜Ｃｈｅｃｋ＞制約要素はブール照会式を含むことができる。プロパティ値を有効にする場合、この式が真であることを評価しなければならない。この式は、いかなる副次作用も有してはならない。チェック制約が基本タイプおよび派生タイプの両方に指定された場合、どちらの制約も妥当性が検査される。アレイプロパティのチェック制約は、プロパティ全体に適用されることに留意されたい。例えばこれを使用して、要素プロパティの合計が何らかの制限よりも少ないことをチェックすることができる。代替の方法として、＜ＥｌｅｍｅｎｔＣｏｎｓｔｒａｉｎｔ＞要素内部に配置されたチェック制約は、各値に個別に適用されることになる。

テーブルタイプ。テーブルタイプのインスタンスは、指定されたエンティティタイプの順序付けされていないインスタンスの集まりを格納することができる。指定されたエンティティタイプ、またはその基本タイプ階層内のタイプは、キープロパティを指定しなければならない。これは、必ずしもエンティティタイプを抽象タイプとすることができないことを意味するものでないことに留意されたい。ネストされたテーブルに格納されたエンティティタイプのキープロパティは、いずれのテーブルインスタンスにおいても一意でなければならない。テーブルは、指定されたタイプまたはそのタイプから派生したタイプのいずれのエンティティも保持することができる。アプリケーションはエンティティをテーブルに挿入すること、およびエンティティをテーブルから除去することができる。テーブルタイプは以下の構文を使用して指定される。

エンティティタイプ（およびエンティティタイプのみ）は、テーブルタイプのプロパティを定義することができる。こうしたプロパティは、ネストされたテーブルを表す。ネストされたテーブルは、収容エンティティのインスタンスに依存する格納場所を定義する。ネストされたテーブルに格納されたエンティティは、収容エンティティによって定義されたデータのまとまりのある（ｃｏｈｅｓｉｖｅ）単位の一部とみなされる（例えば、収容エンティティが削除された場合に削除される）。しかしながら、コンテナおよび含まれるエンティティに対する変更に関する整合性の保証はなく、トランザクションを使用するアプリケーションを介して明示的に管理されるものと思われる。再帰的テーブルを定義するのは誤りである。すなわちエンティティは、そのタイプ、そのスーパータイプ、またはそのサブタイプのテーブルを定義できず、そのタイプのテーブルを有する何らかの他のエンティティタイプのテーブルを宣言することもできない。テーブルタイププロパティは、２つのエンティティ（プロパティを備えた親エンティティと、テーブルに含まれる子エンティティ）間の構成リレーションシップを定義する。

エンティティ参照タイプ。参照タイプのインスタンスは、指定されたタイプのエンティティへの参照を格納する。参照は、エンティティおよびエンティティのキープロパティ値を含むテーブルへの参照を封入する。参照を、参照のターゲットであるエンティティに解決することができる。参照タイプは以下の構文を使用して指定される。

エンティティおよびインラインのタイプは、参照タイプのプロパティを定義することができる。参照タイププロパティは、２つのエンティティ（プロパティを備えたソースエンティティと、プロパティによって参照されるターゲットエンティティ）間のアソシエーションリレーションシップを定義する。

テーブル参照タイプ。テーブル参照タイプのインスタンスは、テーブルへの参照を格納する。ターゲットテーブルは、テーブルセットまたはネストされたテーブル内の「トップレベル」とすることができる。参照は、参照のターゲットであるテーブルに解決することができる。テーブル参照タイプは以下の構文を使用して指定される。

エンティティおよびインラインのタイプは、参照タイプのプロパティを定義することができる。

プロパティ。プロパティは、ストレージを割り振るためにエンティティおよびインラインのタイプ内で使用される。プロパティは、＜Ｐｒｏｐｅｒｔｙ＞要素を使用して定義される。上記で定義された一般的なメンバ要素に加えて、この要素は以下の属性を有することができる。
・Ｎａｍｅ−−必須。メンバの名前。この名前は定義タイプの範囲内で一意でなければならない。この名前はクラスメンバ名に関するＣＬＲ規則に従わなければならず、．ＮｅｔＦｒａｍｅｗｏｒｋ命名ガイドラインにも従うものとする。
・ＤｕｐｌｉｃａｔｅＮａｍｅ−−オプション。メンバ名は、ＤｕｐｌｉｃａｔｅＮａｍｅ属性が提供され、値「ｔｒｕｅ」を有していない限り、基本タイプ階層全体にわたっても一意でなければならない。デフォルトの値「ｆａｌｓｅ」は、メンバ名が一意であると予測されることを示す。
この属性の役割は、ａ）メンバ名が基本タイプ内のプロパティと重複している事実をドキュメント化すること、およびｂ）スキーマ設計者に名前を重複させることを意図的に選択させることである（すなわち、Ｃ＃での新規キーワードと同じ役割を果たす）。
・Ｔｙｐｅ−−必須。プロパティのタイプ。これは任意の単純、インライン、アレイ、エンティティ参照、またはテーブル参照のタイプとすることができる。エンティティ内で定義されるプロパティにはテーブルタイプも使用可能である。
・Ｎｕｌｌａｂｌｅ−−アレイおよびネストされたテーブルを除くすべてのタイプのプロパティに必須であり、アレイおよびネストされたテーブルタイプを備えるプロパティには使用できない。値「ｔｒｕｅ」は、プロパティがｎｕｌｌ値を格納できることを意味する。値「ｆａｌｓｅ」は、プロパティがｎｕｌｌ値を格納できないことを意味する。
・Ａｓｓｏｃｉａｔｉｏｎ−−プロパティタイプが参照または参照のアレイタイプの場合は必須。このプロパティが関与するアソシエーションの名前を指定する。詳細は「アソシエーション」の項を参照のこと。
・Ｃｏｍｐｏｓｉｔｉｏｎ−−プロパティタイプがテーブルタイプの場合は必須。このプロパティが関与しているアソシエーションまたは構成の名前を指定する。詳細は「構成」の項を参照のこと。
・Ｒｏｌｅ−−このプロパティが関与しているアソシエーションの役割を指定する。この属性が必須の場合の説明は、「アソシエーション」に関する項を参照のこと。

いくつかのプロパティ定義の例を以下に示す。

プロパティの制約。プロパティに格納できる値は、＜Ｐｒｏｐｅｒｔｙ＞要素内部の制約要素を使用して制約することができる。使用可能な制約要素のセットはプロパティのタイプに依存し、各タイプが検討されたように定義される。加えて、＜ＰｒｏｐｅｒｔｙＣｏｎｓｔｒａｉｎｔ＞要素内部に制約要素を配置することによって、派生タイプ内でプロパティをさらに制約することができる。この要素は以下の属性を有することができる。
・Ｐｒｏｐｅｒｔｙ−−必須。制約されたプロパティの名前。重複するプロパティ名が存在する場合、この名前はタイプ名を使用して修飾することができる。名前が重複し修飾されていない場合、最大派生タイプにあるプロパティが想定される。
・Ｔｙｐｅ−−オプション。プロパティが制約されるタイプ。プロパティのオリジナルタイプがＡｒｒａｙ（Ｔ）、Ｔａｂｌｅ（Ｔ）、Ｒｅｆ（Ｔ）、またはＴａｂｌｅＲｅｆ（Ｔ）であった場合にのみ、タイプを指定することができる。こうした場合、新しいタイプはそれぞれＡｒｒａｙ（Ｓ）、Ｔａｂｌｅ（Ｓ）、Ｒｅｆ（Ｓ）、またはＴａｂｌｅＲｅｆ（Ｓ）でなければならず、ＳはＴのサブタイプでなければならない。

＜ＰｒｏｐｅｒｔｙＣｏｎｓｔｒａｉｎｔ＞要素を使用する場合、指定された制約が基本タイプで定義されたいずれの制約にも適合することが必要である。各制約要素の記述には、どのような適合を伴うかの定義が含まれる。いくつかの単純な例を以下に示す。

制約ターゲットタイプ。参照プロパティを有するタイプからタイプを派生させる場合、指定可能なエンティティのタイプをさらに制約することができる。これは、＜ＰｒｏｐｅｒｔｙＣｏｎｓｔｒａｉｎｔ＞要素の内部にある要素を使用し、本明細書に記載されたＴｙｐｅ属性の値を指定することで実行される。例えば以下のとおりである。

算出プロパティ。算出プロパティは、格納された値ではなく算出される値を表すために、エンティティおよびインラインタイプで使用される。プロパティの値を算出する際に使用されるアルゴリズムは、データモデルの一部とはみなされない。プロパティは、データモデルの一部として照会を戻すように記述することができる。算出プロパティは、＜ＣｏｍｐｕｔｅｄＰｒｏｐｅｒｔｙ＞要素を使用して宣言される。上記で定義された一般的なメンバ属性に加えて、この要素は以下の属性を有することができる。
・ＲｅａｄＯｎｌｙ−−オプション。プロパティが読み取り専用であるかどうかを示す。デフォルト値は、プロパティが読み取り専用であり更新には使用できないことを意味する「ｔｒｕｅ」である。
・Ｓｔａｔｉｃ−−オプション。プロパティが静的またはインスタンスプロパティであるかどうかを示す。デフォルト値は、これがインスタンスプロパティであることを示す「ｆａｌｓｅ」である。

以下の例は、タイプ「Ｉｎｔ３２」の「Ｘ」と命名された算出プロパティを宣言する。

算出プロパティの制約。プロパティに格納可能な値は、＜ＣｏｍｐｕｔｅｄＰｒｏｐｅｒｔｙ＞要素内部の制約要素を使用して制約することができる。使用可能な制約要素のセットはプロパティのタイプに依存し、各タイプが検討されたように定義される。一実装では、＜ＰｒｏｐｅｒｔｙＣｏｎｓｔｒａｉｎｔ＞要素が算出プロパティでも働く。

メソッド。メソッドは実行可能なオペレーションを表すためにインラインおよびエンティティタイプで使用される。メソッドをインプリメントするために使用されるアルゴリズムは、データモデルの一部とはみなされない。一実装では、メソッドは、入力として照会を利用し、データモデルの一部としての出力として照会を戻す。アソシエーションは、本来こうしたメソッドを定義する。メソッドは＜Ｍｅｔｈｏｄ＞要素を使用して宣言される。この要素は以下の属性を有することができる。
・Ｎａｍｅ−−必須。メンバの名前。この名前は定義タイプの範囲内で一意でなければならない。名前は、クラスメンバ名に関するＣＬＲ規則に従わなければならず、．ＮｅｔＦｒａｍｅｗｏｒｋ命名ガイドラインに従うものとする。
・ＤｕｐｌｉｃａｔｅＮａｍｅ−−オプション。メンバ名は、ＤｕｐｌｉｃａｔｅＮａｍｅ属性が提供され、値「ｔｒｕｅ」を有していない限り、基本タイプ階層全体にわたっても一意でなければならない。デフォルトの値「ｆａｌｓｅ」は、メンバ名が一意であると予測されることを示す。
この属性の役割は、ａ）メンバ名が基本タイプ内のプロパティと重複している事実をドキュメント化すること、およびｂ）スキーマ設計者に名前を重複させることを意図的に選択させることである（すなわち、Ｃ＃での新規キーワードと同じ役割を果たす）。
・ＲｅｔｕｒｎＴｙｐｅ−−必須。メソッドによって戻される値のタイプ。これは単純、インライン、アレイ、エンティティ参照、テーブル参照、またはテーブルタイプとすることが可能であるか、あるいは何の値も戻されないことを示す空の文字列とすることができる。
・Ｓｔａｔｉｃ−−オプション。メソッドが静的またはインスタンスメソッドであるかどうかを示す。デフォルト値は、これがインスタンスメソッドであることを示す「ｆａｌｓｅ」である。
・Ａｓｓｏｃｉａｔｉｏｎ−−戻りタイプが参照または参照のアレイタイプの場合は必須。このメソッドが関与するアソシエーションの名前を指定する。詳細は「アソシエーション」の項を参照のこと。
・Ｃｏｍｐｏｓｉｔｉｏｎ−−戻りタイプがテーブルタイプの場合は必須。このメソッドが関与しているアソシエーションまたは構成の名前を指定する。詳細は「構成」の項を参照のこと。
・Ｒｏｌｅ−−このメソッドが関与しているアソシエーションの役割を指定する。この属性が必須の場合の説明は、「アソシエーション」に関する項を参照のこと。

＜ＲｅｔｕｒｎＴｙｐｅＣｏｎｓｔｒａｉｎｔｓ＞要素を＜Ｍｅｔｈｏｄ＞要素内部にネストすることができる。メソッドの戻りタイプに適用される制約要素を、＜ＲｅｔｕｒｎＴｙｐｅＣｏｎｓｔｒａｉｎｔｓ＞要素内部にネストすることができる。＜Ｍｅｔｈｏｄ＞要素はゼロまたはそれ以上の＜Ｐａｒａｍｅｔｅｒ＞要素をネストして、メソッドによって受け入れられたパラメータを指定することができる。＜Ｐａｒａｍｅｔｅｒ＞要素は以下の属性を有することができる。
・Ｎａｍｅ−−必須。パラメータの名前。
・Ｔｙｐｅ−−必須。パラメータのタイプ。
・Ｏｕｔ−−オプション。これが出力パラメータの場合は「ｔｒｕｅ」の値、あるいはこれが入力パラメータの場合はデフォルト値の「ｆａｌｓｅ」。

パラメータのタイプに適用される制約要素を＜Ｐａｒａｍｅｔｅｒ＞要素内部にネストすることができる。以下の例は、タイプ「Ｉｎｔ３２」の「Ｘ」と命名された算出プロパティと、タイプ「Ｉｎｔ３２」の「ａ」と命名されたパラメータを備えた「Ｙ」と命名されたメソッドとを宣言し、タイプ「Ｉｎｔ３２」の値を戻す。

インラインタイプ。インラインタイプのインスタンスは、唯一のエンティティインスタンスの構成要素としてのみ持続可能である。インラインタイプのインスタンスは明示的アイデンティティを持たない（アイデンティティは、その収容エンティティの内部にそれがどのように配置されているかが暗黙的である）。インラインタイプのインスタンスは、収容エンティティによって定義されたデータのまとまりのある単位の一部とみなされる（例えば、収容エンティティが削除された場合に削除される）。いかなる明示的なアプリケーションの動作もなしに、エンティティの一部であるすべてのインラインデータに渡って整合性が維持されることになる保証もある。これは、ＷｉｎＦＳの変更ユニットおよび同期化などの機能が整合性を介してより精密な制御をスキーマ設計者に提供するのを妨げるものでないことに留意されたい。

スキーマ設計者は、プロパティのセットからなる構造で新しいインラインタイプを定義することができる。こうしたインラインタイプは、単一の基本インラインタイプから派生させることができる。こうしたタイプは、＜Ｓｃｈｅｍａ＞要素内部の＜ＩｎｌｉｎｅＴｙｐｅ＞要素を使用して定義される（ネストされたインラインタイプは使用できない）。＜ＩｎｌｉｎｅＴｙｐｅ＞要素は以下の属性を有することができる。
・Ｎａｍｅ−−必須。タイプの名前を指定する。
・ＢａｓｅＴｙｐｅ−−オプション。このタイプによってサブタイプ化されたインラインタイプを定義する。基本タイプが指定されない場合、プロパティを定義しない匿名抽象基本タイプが想定される。
・Ａｂｓｔｒａｃｔ−−オプション。タイプが抽象の場合は「ｔｒｕｅ」、具象の場合は「ｆａｌｓｅ」。非抽象タイプのインスタンスのみが作成可能である。デフォルト値は「ｆａｌｓｅ」である。
・Ｓｅａｌｅｄ−−オプション。タイプが封止（ｓｅａｌ）される場合は「ｔｒｕｅ」、されない場合は「ｆａｌｓｅ」、または定義スキーマの外部での使用に限って封止される場合は「ｅｘｔｅｒｎａｌ」。デフォルト値は「ｆａｌｓｅ」である。
・ＦｒｉｅｎｄＳｃｈｅｍａｓ−−オプション。定義タイプの「ｆｒｉｅｎｄｓ」とみなされるスキーマネームスペースのコンマで区切られたリスト。これらのスキーマは、Ｓｅａｌｅｄ＝「ｅｘｔｅｒｎａｌ」属性値によってインポーズされた制限を対象としない（ただし、制限Ｓｅａｌｅｄ＝「ｔｒｕｅ」は対象とする）。

以下に、インラインタイプ定義のいくつかの例を示す。

図１０は、上記いくつかのインラインタイプのＵＭＬ表現１１００を示す図である。

インラインタイプの制約。インラインタイプのインスタンスは、以下の制約要素を使用して制約することができる。これらの要素は、インラインタイプを参照する様々な要素の中にネストすることができる（例えば、＜ＥｎｔｉｔｙＴｙｐｅ＞または＜ＩｎｌｉｎｅＴｙｐｅ＞要素内の＜Ｐｒｏｐｅｒｔｙ＞要素）。

チェック。＜Ｃｈｅｃｋ＞制約要素はブール照会式を含むことができる。プロパティ値を有効にする場合、この式が真であることを評価する。この式は、いかなる副次作用も有さないものとする。チェック制約が基本タイプおよび派生タイプの両方に指定された場合、どちらの制約も妥当性が検査される。

エンティティタイプ。エンティティタイプはデータのまとまりのある単位を定義する。エンティティタイプのインスタンスは、唯一のテーブルで持続可能である。エンティティタイプのインスタンスは明示的アイデンティティを有する。参照タイプを使用して、エンティティタイプインスタンスへの永続的な参照を格納することが可能である。

スキーマ設計者は、プロパティのセットからなる構造で新しいエンティティタイプを定義することができる。エンティティタイプは、単一の基本エンティティタイプから派生させることができる。こうしたタイプは、＜Ｓｃｈｅｍａ＞要素内部の＜ＥｎｔｉｔｙＴｙｐｅ＞要素を使用して定義される（ネストされたエンティティタイプは使用できない）。＜ＥｎｔｉｔｙＴｙｐｅ＞要素は以下の属性を有することができる。
・Ｎａｍｅ−−必須。タイプの名前を指定する。この名前は、格納スキーマ内で定義されたすべてのタイプ名（インラインおよびエンティティの両方のタイプ名）の中で一意でなければならない。
・ＢａｓｅＴｙｐｅ−−オプション。このタイプによってサブタイプ化されたエンティティタイプを定義する。基本タイプが指定されない場合、プロパティを定義しない匿名抽象基本タイプが想定される。
・Ａｂｓｔｒａｃｔ−−オプション。タイプが抽象の場合は「ｔｒｕｅ」、具象の場合は「ｆａｌｓｅ」。非抽象タイプのインスタンスのみが作成可能である。デフォルト値は「ｆａｌｓｅ」である。
・Ｓｅａｌｅｄ−−オプション。タイプが封止される場合は「ｔｒｕｅ」、されない場合は「ｆａｌｓｅ」、または定義スキーマの外部での使用に限って封止される場合は「ｅｘｔｅｒｎａｌ」。デフォルト値は「ｆａｌｓｅ」である。
・ＦｒｉｅｎｄＳｃｈｅｍａｓ−−オプション。定義タイプの「ｆｒｉｅｎｄｓ」とみなされるスキーマネームスペースのコンマで区切られたリスト。これらのスキーマは、Ｉｎｔｅｒｎａｌ＝「ｔｒｕｅ」またはＳｅａｌｅｄ＝「ｅｘｔｅｒｎａｌ」によってインポーズされた制限を対象としない（ただし、制限Ｓｅａｌｅｄ＝「ｔｒｕｅ」は対象とする）。
・Ｔａｂｌｅ−−オプション。構文ｅｎｔｉｔｙ−ｔｙｐｅ−ｎａｍｅ．ｔａｂｌｅ−ｐｒｏｐｅｒｔｙ−ｎａｍｅを使用して、このエンティティタイプを含むであろう唯一のテーブルまたはネストされたテーブルの名前を指定する。デフォルトは、テーブルの任意の番号がそのエンティティタイプのインスタンスを含むように定義されることができるといったものである。
・Ｅｘｔｅｎｓｉｂｌｅ−−オプション。デフォルトの値「ｔｒｕｅ」は、以下で説明するように、エンティティが＜ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＴｙｐｅ＞要素を使用して拡張可能であることを示す。値「ｆａｌｓｅ」は、エンティティ拡張できないことを示す。
・Ａｓｓｏｃｉａｔｉｏｎ−−エンティティがアソシエーション定義においてアソシエーションエンティティの役割を有する場合、この属性は必須であり、アソシエーションの名前を指定しなければならない。そうでない場合、この属性は存在できない。
・Ｋｅｙ−−エンティティタイプまたは基本タイプで定義されたプロパティの１つまたは複数の名前のコンマで区切られたリスト。エンティティタイプ階層内で１つのタイプのみがＫｅｙ属性を指定することができる。そのタイプの基本タイプ階層内のすべてのタイプは抽象タイプでなければならない。指定されたプロパティはそのタイプまたはその基本タイプから取得することができる。指定されたプロパティはエンティティのアイデンティティの一部を確立する。アイデンティティの残りの部分は、エンティティの親から暗黙的に取得される（例えば、子エンティティが常駐するテーブルプロパティを定義するエンティティインスタンス）。アレイを除くインラインｎｕｌｌ不可タイプを備えたプロパティのみが、キープロパティとして指定可能である。プロパティがユーザ定義インラインタイプである場合、このタイプのすべてのプロパティはキープロパティとみなされ、すべては単一の値かつｎｕｌｌ不可でなければならない。ネストされたプロパティ（複合タイプの１プロパティのプロパティ群）もキープロパティとして指定することができる。

いくつかのエンティティタイプ定義の例は次のとおりである。

図１１は、前述のいくつかのエンティティタイプ１１００のＵＭＬ表現を示す図である。

エンティティタイプの制約。エンティティタイプのインスタンスは、以下の制約要素を使用して制約することができる。これらの要素は、エンティティタイプを参照する様々な要素の内部にネストすることができる（例えば、＜ＥｎｔｉｔｙＴｙｐｅ＞要素内の＜Ｐｒｏｐｅｒｔｙ＞要素）。

エンティティ拡張タイプ。ＷｉｎＦＳおよびＭＢＦシナリオに対処するためには、所与のタイプセットが定義されたスキーマを実際に修正することなく、それらのタイプセットを拡張できなければならない。これは、いくつかのパターンのうちの１つを採用すること（基本クラスにＥｘｔｅｎｓｉｏｎエンティティタイプのテーブルを提供することなど）によって実施可能であるが、こうした概念をデータモデルの最上クラス部分にすることが望ましい。これによって、拡張用に特別なＡＰＩパターンを生成することが可能であり、タイプ設計者にとって理解および使用がより簡単である。

Ｅｘｔｅｎｓｉｂｌｅ＝「ｔｒｕｅ」属性を指定するエンティティタイプは拡張可能である。エンティティ拡張は＜Ｓｃｈｅｍａ＞要素内部の＜ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＴｙｐｅ＞要素を使用して宣言される。＜ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＴｙｐｅ＞要素は以下の属性を有することができる。
・Ｎａｍｅ−−必須。拡張タイプの名前。
・ＥｘｔｅｎｄｓＴｙｐｅ−−必須。拡張されるエンティティタイプの名前。
・ＩｎｓｔａｎｃｅＭａｎａｇｅｍｅｎｔ−−必須。「Ｉｍｐｌｉｃｉｔ」の値は、拡張のインスタンスが暗黙的に、拡張されたエンティティへ追加／拡張されたエンティティから除去されることを示す。「Ｅｘｐｌｉｃｉｔ」の値は、拡張のインスタンスがアプリケーションによって明示的に追加および除去されなければならないことを示す。
・Ｔａｂｌｅ−−オプション。拡張を格納するテーブルを指定する。

他の拡張タイプから１つの拡張タイプを派生させることが不可能な場合がある。＜ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＴｙｐｅ＞要素は、＜ＥｎｔｉｔｙＴｙｐｅ＞要素内部に入れることが可能な任意の要素を含むことができる。通常、これには＜Ｐｒｏｐｅｒｔｙ＞要素が含まれる。プロパティ名はすべての拡張にわたって、または拡張されたタイプのプロパティにわたって、一意である必要はない。ＩｎｓｔａｎｃｅＭａｎａｇｅｍｅｎｔ＝「Ｉｍｐｌｉｃｉｔ」の場合、拡張内に定義されたプロパティすべてがｎｕｌｌ可能であるか、デフォルト値を指定するか、あるいは、ゼロの最少発生数制約を備えたアレイ、コレクション、またはテーブルタイプを有するかの、いずれかでなければならない。単集合（ｓｉｎｇｌｅｔｏｎ）インラインタイププロパティはデフォルト値を指定できないため、ｎｕｌｌ可能でなければならないことに留意されたい。これにより、常に存在しているかのように拡張に対して照会を実行することができる。

ＩｎｓｔａｎｃｅＭａｎａｇｅｍｅｎｔ＝「Ｅｘｐｌｉｃｉｔ」の場合、アプリケーションは、ＣＤＭ用に照会言語で定義されたオペレーションを使用して、拡張を明示的にエンティティインスタンスへ追加およびエンティティインスタンスから除去する。拡張の存在をテストするための手段も提供される。エンティティ拡張インスタンスは、収容エンティティによって定義されるデータのまとまりのある単位の一部であるとみなされる（例えば、収容エンティティが削除された場合に削除される）。しかしながら、エンティティおよび拡張に対する変更に関する整合性の保証はなく、トランザクションを使用するアプリケーションを介して明示的に管理されるものと予測される。

すべてのＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎｓはタイプＲｅｆ（Ｔ）の「Ｅｎｔｉｔｙ」と命名されたデフォルトプロパティを有し、ここでＴはＥｘｔｅｎｄｓＴｙｐｅの値であり、拡張が関連付けられるエンティティインスタンスを指す。エンティティタイプおよび拡張の例を以下に示す。

アソシエーション。アソシエーションは、２つまたはそれ以上のエンティティが使用可能であり、エンドエンティティは互いに関係する。各エンドは概念上互いに独立したままである。アソシエーションは＜Ａｓｓｏｃｉａｔｉｏｎ＞要素を使用して表される。この要素は以下の属性を有することができる。
・Ｎａｍｅ−−必須。アソシエーションの名前。
・Ｓｃｏｐｅ−−オプション。エンティティタイプの名前を指定する。アソシエーションは、指定されたタイプのエンティティのインスタンスにスコーピングされ、その妥当性はインスタンスに関してチェックすることができる。

＜Ａｓｓｏｃｉａｔｉｏｎ＞要素は２つまたはそれ以上のネストされた＜Ｅｎｄ＞要素を有し、そのそれぞれがアソシエーションのエンドの１つを記述する。２つより多くの＜Ｅｎｄ＞要素が指定できるのは、＜ＡｓｓｏｃｉａｔｉｏｎＥｎｔｉｔｙ＞要素も指定された場合のみであることに留意されたい。＜Ｅｎｄ＞要素は以下の属性を有することができる。
・Ｒｏｌｅ−−必須。エンドがアソシエーションで果たすロールに命名する。
・ＰｌｕｒａｌＲｏｌｅ−−オプション。複数形のロール名を与える。この名前は照会モデルおよび正規のオブジェクトマッピングで使用される。指定されない場合、代わりに形式ｒｏｌｅＥｎｔｉｔｉｅｓの名前が使用される。
・Ｔｙｐｅ−−必須。エンドによって表されるエンティティのタイプ。
・Ｍｕｌｔｉｐｌｉｃｉｔｙ−−オプション。濃度の下限および上限を設定する、アソシエーションのこのエンドの多重度。＜ｌｏｗｅｒ＿ｂｏｕｎｄ＞．．＜ｕｐｐｅｒ＿ｂｏｕｎｄ＞形式の整数範囲として、または下限と上限が同じ場合には単一の整数として、指定される。上限は、制限なしを示す「^＊」とすることが可能である。単一の「^＊」は、「０．．^＊」と同義である。デフォルト値とそれらのデフォルト値が書き換え可能であるかどうかに関する規則とは、アソシエーションのスタイルに依存する。
□ Ｒｅｆｅｒｅｎｃｅ：参照側では「^＊」、被参照側では「０．．１^＊」
□ Ｃｏｍｐｏｓｉｔｉｏｎ：親側では「１」（固定）、子側では「^＊」
□ Ｃｏｎｄｉｔｉｏｎ（条件）およびＣｏｍｍｏｎＶａｌｕｅ（共通値）：両側で「^＊」（固定）
□ ＡｓｓｏｃｉａｔｉｏｎＥｎｔｉｔｙ：両側で「^＊」
１より大きい多重度は正当であるが、強制の目的で^＊として扱われる場合がある。
・Ｔａｂｌｅ−−参照ベースアソシエーションのターゲットの場合は必須、そうでない場合はオプション。Ｔｙｐｅによって指定されたエンティティタイプまたはＴｙｐｅの祖先タイプの１つのテーブルプロパティを指定する。関連するエンティティが指定されたテーブルに現れるように、エンドが制約される。構文は、エンティティタイプで始まりプロパティタイプのテーブルプロパティで終わるパスを指定する。パスの各セグメントは以下の２つの方法のうちの１つでエンティティタイプに解決される。
ａ．エンティティタイプの参照またはテーブルプロパティを指定する（どちらかが基礎となるエンティティタイプに解決される）。この構文は＜ｅｎｔｉｔｙ−ｔｙｐｅ＞／＜ｐｒｏｐｅｒｔｙ−ｎａｍｅ＞の形である。参照プロパティが使用される場合、その対応するアソシエーションエンドにはテーブル名が指定されていなければならない。
ｂ．アソシエーションまたは構成にロールを指定する。（どちらかがエンドのタイプに解決される）。この構文は＜ｅｎｔｉｔｙ−ｔｙｐｅ＞／＜ｒｅｌａｔｉｏｎｓｈｉｐ−ｎａｍｅ＞．＜ｒｏｌｅ−ｎａｍｅ＞の形である。アソシエーションが使用される場合、ロール名によって指定されたエンドにはテーブル名が指定されていなければならない。
おそらく参照ベースアソシエーションの「」は、参照を正しいタイプの任意のテーブルとすることができることを示す。Ｓｃｏｐｅ属性が指定された場合、パスは示されたエンティティタイプで始まらなければならない。Ｔｙｐｅの定義でＴａｂｌｅ属性が指定された場合、このパスはこれに適合しなければならない。
・Ｓｃｏｐｅｄ−−オプション。このエンドが＜Ａｓｓｏｃｉａｔｉｏｎ＞要素のＳｃｏｐｅ属性に示されたエンティティのインスタンスにスコープされるかどうかを示す。デフォルトはｔｒｕｅである。
・ＯｎＤｅｌｅｔｅ−−オプション。ロール内のエンティティが削除された場合にとられる処置を指定する。このエンドが＜Ｒｅｆｅｒｅｎｃｅ＞または＜ＣｏｍｍｏｎＶａｌｕｅ＞要素にリストアップされた場合にのみ指定可能である。可能な値は以下のとおりである。
・Ｒｅｓｔｒｉｃｔ−−エンティティが削除されるのを防ぐ。これはデフォルトの値である。
・Ｃａｓｃａｄｅ−−他方のエンドロールのエンティティを削除させる。
・ＣａｓｃａｄｅＴｏＡｓｓｏｃｉａｔｉｏｎＥｎｔｉｔｙ−−アソシエーションエンティティのみを削除させる。
・ＳｅｔＮｕｌｌ−−アソシエーションの他方のエンドのプロパティをｎｕｌｌに設定させる。プロパティが参照のコレクションである場合、コレクションから参照が除去される。アソシエーションの他方のエンドの多重度の下限はゼロでなければならない。このエンドが＜ＣｏｍｍｏｎＶａｌｕｅ＞要素のプロパティの１つまたは＜Ｒｅｆｅｒｅｎｃｅ＞要素のＴｏＲｏｌｅにリストアップされた場合にのみ指定可能である。
・ＯｎＵｐｄａｔｅ−−オプション。エンドロール内のエンティティの共通値プロパティが更新された場合にとられることになる処置を指定する。このエンドが＜ＣｏｍｍｏｎＶａｌｕｅ＞要素にリストアップされた場合にのみ指定可能である。ＯｎＵｐｄａｔｅが指定されない場合、一方のエンドのプロパティを更新しても他方のエンドのプロパティには影響を与えない。可能な値は以下のとおりである。
・Ｒｅｓｔｒｉｃｔ−−エンティティが更新されるのを防ぐ。
・Ｃａｓｃａｄｅ−−他方のエンドロール内のエンティティの共通値プロパティが同じ値に更新されるようにする。
・ＳｅｔＮｕｌｌ−−他方のエンドロール内のエンティティの共通値プロパティをｎｕｌｌに設定させる。アソシエーションの他方のエンドの多重度の下限はゼロでなければならない。

アソシエーションスタイル。アソシエーションのスタイルは、エンドがどのように接続されるかを示す。あらゆるアソシエーションは、＜Ａｓｓｏｃｉａｔｉｏｎ＞要素の下で以下の要素のうちの１つをネストすることによって示される４つのスタイルのうちの１つである。
・＜Ｒｅｆｅｒｅｎｃｅ＞−−２つのエンドがエンドのうちの１つの参照プロパティを使用して接続される。
・＜Ｃｏｎｄｉｔｉｏｎ＞−−２つのエンドがエンドの任意結合を介して接続される。
・＜ＣｏｍｍｏｎＶａｌｕｅ＞−−２つのエンドが各エンドからのプロパティの同等結合を介して接続される。
・＜ＡｓｓｏｃｉａｔｉｏｎＥｎｔｉｔｙ＞−−２つまたはそれ以上のエンドが追加のエンティティを使用して接続される。この要素が使用される場合にのみ、２つより多くの＜Ｅｎｄ＞要素を指定することができる。

＜Ｒｅｆｅｒｅｎｃｅ＞要素は、参照スタイルアソシエーションを記述する。この要素は以下の属性を有することができる。
・ＦｒｏｍＲｏｌｅ−−必須。参照タイププロパティを含むロールの名前。アソシエーションエンティティの場合、これはアソシエーションエンティティロールの名前でなければならない。
・ＴｏＲｏｌｅ−−必須。参照プロパティのターゲットであるロールの名前。識別されたロールはＯｎＵｐｄａｔｅ属性を指定してはならない。
・Ｐｒｏｐｅｒｔｙ−−必須。ＦｒｏｍＲｏｌｅエンティティの参照プロパティの名前。このプロパティを定義する＜Ｐｒｏｐｅｒｔｙ＞要素は、封入アソシエーションを指定するＲｏｌｅ属性を有していなければならない。多重度の上限が１の場合、プロパティのタイプは参照でなければならず、下限がゼロの場合、その参照はｎｕｌｌ可能でなければならない。１より大きい場合、プロパティタイプは参照のアレイでなければならない。

エンティティＡおよびＢを関係付ける参照アソシエーション「ＡｔｏＢ」の一例を以下に示す。

＜ＣｏｍｍｏｎＶａｌｕｅ＞要素は共通値スタイルアソシエーションを記述する。この要素は以下の属性を有することができる。
・Ｐｒｏｐｅｒｔｙ１−−必須。フォーマットｒｏｌｅ−ｎａｍｅ．ｐｒｏｐｅｒｔｙ−ｎａｍｅの文字列を使用して、エンドのうちの１つのプロパティを識別する。
・Ｐｒｏｐｅｒｔｙ２−−必須。フォーマットｒｏｌｅ−ｎａｍｅ．ｐｒｏｐｅｒｔｙ−ｎａｍｅの文字列を使用して、エンドのうちの１つのプロパティを識別する。

アソシエーションの場合、Ｐｒｏｐｅｒｔｙ１およびＰｒｏｐｅｒｔｙ２のうちの１つがアソシエーションエンティティロールを指定し、他方がエンドロールを指定する。指定されたエンドはＯｎＵｐｄａｔｅおよび／またはＯｎＤｅｌｅｔｅ属性を含むことができる。エンティティＡおよびＢを関係付ける共通値アソシエーション「ＡｔｏＢ」の一例を以下に示す。

＜Ｃｏｎｄｉｔｉｏｎ＞要素は、２つのエンド間の任意結合に基づくアソシエーションを記述する。この要素は、関係エンティティに対してｔｒｕｅを評価する式を含まなければならない。＜Ｅｎｄ＞および＜Ｕｓｉｎｇ＞要素に指定されたロール名をこの式で使用することができる。＜Ａｓｓｏｃｉａｔｉｏｎ＞要素が＜Ｃｏｎｄｉｔｉｏｎ＞要素を含む場合は、ゼロまたはそれ以上の＜Ｕｓｉｎｇ＞要素も含むことができる。これらの要素は、エンド間のリレーションシップを定義するために使用される追加のエンティティを記述する。＜Ｕｓｉｎｇ＞要素は以下の属性を有することができる。
・Ｒｏｌｅ−−必須。リレーションシップで使用されるエンドのロールの名前。
・Ｔｙｐｅ−−必須。リレーションシップで使用されるエンティティのタイプ。
・Ｔａｂｌｅ−−アソシエーション＜Ｅｎｄ＞要素の属性記述を参照のこと。

＜Ｅｎｄ＞、＜Ｕｓｉｎｇ＞、および＜Ｃｏｎｄｉｔｉｏｎ＞要素を使用して、完全な参照が構築される。この参照は以下の形式である。

以下の例は、第３のエンティティＣを含む式を使用する関係する２つのエンティティＡおよびＢを示す。

＜ＡｓｓｏｃｉａｔｉｏｎＥｎｔｉｔｙ＞要素は、アソシエーションのエンドがアソシエーションエンティティによって接続されることを示す。＜ＡｓｓｏｃｉａｔｉｏｎＥｎｔｉｔｙ＞要素は以下の属性を有することができる。
・Ｒｏｌｅ−−必須。アソシエーションエンティティがアソシエーションで果たすロールに命名する。
・ＰｌｕｒａｌＲｏｌｅ−−オプション。複数形のロール名を与える。この名前は照会モデルおよび正規のオブジェクトマッピングで使用される。指定されない場合、代わりに形式ｒｏｌｅＥｎｔｉｔｉｅｓの名前が使用される。
・Ｔｙｐｅ−−必須。アソシエーションエンティティのタイプ。このタイプを定義する＜ＥｎｔｉｔｙＴｙｐｅ＞要素は、封入する＜Ａｓｓｏｃｉａｔｉｏｎ＞要素を識別するＡｓｓｏｃｉａｔｉｏｎ属性を指定しなければならない。
・Ｔａｂｌｅ−−アソシエーション＜Ｅｎｄ＞要素に関する属性記述を参照のこと。

＜ＡｓｓｏｃｉａｔｉｏｎＥｎｔｉｔｙ＞は１つのネストされた＜Ｅｎｄ＞要素を有する。アソシエーションエンティティは、この＜Ｅｎｄ＞要素と＜Ａｓｓｏｃｉａｔｉｏｎ＞の下にネストされたそれぞれの＜Ｅｎｄ＞要素との間のアソシエーションを定義する。これらアソシエーションのスタイルは、＜Ｒｅｆｅｒｅｎｃｅ＞、＜Ｃｏｎｄｉｔｉｏｎ＞、または＜ＣｏｍｍｏｎＶａｌｕｅ＞要素で記述される。その代わりにアソシエーションのうちの１つは、以下のように＜Ｃｏｍｐｏｓｉｔｉｏｎ＞要素で記述することができる。
・＜Ｃｏｍｐｏｓｉｔｉｏｎ＞−−アソシエーションエンティティは、構成のエンドのうちの１つの子である。

＜Ａｓｓｏｃｉａｔｉｏｎ＞の各＜Ｅｎｄ＞のＲｏｌｅは、これらスタイル要素のうちの１つの、２つのロールのうちの１つによって参照されなければならず、他方のホールは＜ＡｓｓｏｃｉａｔｉｏｎＥｎｔｉｔｙ＞の＜Ｅｎｄ＞を参照する。

＜Ｃｏｍｐｏｓｉｔｉｏｎ＞要素は、エンドロールのうちの１つへのアソシエーションエンティティの構成を記述する。これを＜ＡｓｓｏｃｉａｔｉｏｎＥｎｔｉｔｙ＞内部にネストしなければならない。＜Ｃｏｍｐｏｓｉｔｉｏｎ＞要素は以下の属性を有する。
・ＰａｒｅｎｔＲｏｌｅ−−必須。アソシエーションエンティティタイプのネストされたテーブルを含むエンドロールの名前。これは、アソシエーションエンティティロールであってはならない。このロールによって参照される＜Ｅｎｄ＞要素上のＯｎＤｅｌｅｔｅ属性は、ＣａｓｃａｄｅまたはＣａｓｃａｄｅＴｏＡｓｓｏｃｉａｔｉｏｎＥｎｔｉｔｙを指定しなければならない。ＯｎＵｐｄａｔｅ属性は指定できない。
・ＣｈｉｌｄＲｏｌｅ−−必須。親エンティティによって収容されるロールの名前。これはアソシエーションエンティティの＜Ｅｎｄ＞ロールでなければならない。
・Ｐｒｏｐｅｒｔｙ−−必須。親エンティティ内のテーブルプロパティの名前。このプロパティを定義する＜Ｐｒｏｐｅｒｔｙ＞要素は、封入アソシエーションを指定するＡｓｓｏｃｉａｔｉｏｎ属性を有していなければならない。

＜Ｃｏｎｄｉｔｉｏｎ＞要素は、＜ＡｓｓｏｃｉａｔｉｏｎＥｎｔｉｔｙ＞の下にネストされた場合、以下の属性を有していなければならない。
・ＪｏｉｎｅｄＲｏｌｅｓ−−必須。２つまたはそれ以上のロール名の共通の区切りリスト。このリストは、＜ＡｓｓｏｃｉａｔｉｏｎＥｎｔｉｔｙ＞の＜Ｅｎｄ＞のロール名およびエンドロール名のうちの１つを含む。リストアップされたロールは、ＯｎＤｅｌｅｔｅまたはＯｎＵｐｄａｔｅ属性を指定してはならない。

以下の例は、アソシエーションエンティティＣを使用してＡおよびＢを関係付けるエンティティアソシエーション「ＡｔｏＢ」の一例を示し、ここでＣはＡ内で構成され、Ｂへの参照を有する。

構成。あらゆるネストされたテーブルは、テーブルタイププロパティを含むエンティティタイプとテーブルによって収容されるエンティティタイプとの、２つのタイプのエンティティ間の構成を定義する。構成は＜Ｃｏｍｐｏｓｉｔｉｏｎ＞要素を使用して記述される。この要素は以下の属性を有することができる。
・Ｎａｍｅ−−必須。構成の名前。

＜Ｃｏｍｐｏｓｉｔｉｏｎ＞要素は＜ＰａｒｅｎｔＥｎｄ＞要素を含む。この要素は以下の属性を有することができる。
・Ｒｏｌｅ−−必須。親エンティティのロールに命名する。
・Ｔｙｐｅ−−必須。親エンティティのタイプを指定する。
・Ｐｒｏｐｅｒｔｙ−−必須。構成を定義する親エンティティのプロパティを指定する。
・ＰｌｕｒａｌＲｏｌｅ−−オプション。複数形のロール名を与える。この名前は照会モデルおよび正規のオブジェクトマッピングで使用される。指定されない場合、代わりに形式ｒｏｌｅＥｎｔｉｔｉｅｓの名前が使用される。

＜Ｃｏｍｐｏｓｉｔｉｏｎ＞要素は＜ＣｈｉｌｄＥｎｄ＞要素も含まなければならない。この要素は以下の属性を有することができる。
・Ｒｏｌｅ−−必須。子エンティティのロールに命名する。
・Ｔｙｐｅ−−必須。子エンティティのタイプを指定する。
・Ｍｕｌｔｉｐｌｉｃｉｔｙ−−オプション。構成内の子の多重度。アソシエーションの＜Ｅｎｄ＞要素の多重度も参照のこと。
・ＰｌｕｒａｌＲｏｌｅ−−オプション。複数形のロール名を与える。この名前は照会モデルおよび正規のオブジェクトマッピングで使用される。指定されない場合、代わりに形式ｒｏｌｅＥｎｔｉｔｉｅｓの名前が使用される。

以下のスキーマは、Ａ：Ｂ．ＡＴａｂｌｅおよびＣ．ＡＴａｂｌｅのインスタンスを含むことができる２つの独立したネストされたテーブルを定義する。Ｂ，Ｄ．ＢＴａｂｌｅのインスタンスを含むことができるネストされたテーブルと、Ｃ，Ｄ．ＣＴａｂｌｅのインスタンスを含むことができるネストされたテーブルも存在する。ＤのインスタンスはＤＴａｂｌｅと名付けられたトップレベルテーブルに含まれる。

図１２は、構成の下でのいくつかの同じタイプのＵＭＬ表現１２００を示す図である。

図１３は、ＴＳ．ＴａｂｌｅＤでのＤのインスタンスの可視化１３００を示す図である。

図１４は、図１３のエンティティテーブルに対応するＳＱＬテーブル１４００を示す図である。

ネストされたテーブルタイプの制約。以下に定義された制約要素のうちの１つを使用してコレクションおよびアレイタイプの値を制約することができる。これらの要素はテーブルタイプを参照する様々な要素の内部にネストすることができる（例えば、＜ＥｎｔｉｔｙＴｙｐｅ＞または＜ＩｎｌｉｎｅＴｙｐｅ＞要素内の＜Ｐｒｏｐｅｒｔｙ＞要素）。

エンティティの制約。＜ＥｎｔｉｔｙＣｏｎｓｔｒａｉｎｔ＞制約要素を使用して、テーブル内のエンティティに制約を課すことができる。エンティティタイプに有効な任意の制約要素を＜ＥｎｔｉｔｙＣｏｎｓｔｒａｉｎｔ＞要素内部に指定することができる。

発生数。＜Ｏｃｃｕｒｓ＞制約要素を使用して、テーブル内のエンティティの数を制約することができる。この要素は以下の属性を有することができる。
・Ｍｉｎｉｍｕｍ−−オプション。テーブル内のエントリの最小数を指定する。デフォルト値はゼロ。
・Ｍａｘｉｍｕｍ−−オプション。テーブル内のエントリの最大数を指定する。値「ｕｎｂｏｕｎｄｅｄ」は、制約が存在しないことを示す。デフォルト値は「ｕｎｂｏｕｎｄｅｄ」である。

一意。＜Ｕｎｉｑｕｅ＞制約要素を使用して、一意の値をテーブル内に含めなければならないエンティティタイプのプロパティを指定することができる。この要素は以下の属性を有することができる。Ｐｒｏｐｅｒｔｉｅｓ−−必須。コンマで区切られたエンティティプロパティ名のリスト。

チェック。＜Ｃｈｅｃｋ＞制約要素はブール照会式を含むことができる。テーブルを有効にする場合、この式が真であることを評価しなければならない。この式は、いかなる副次作用も有してはならない。チェック制約が基本タイプおよび派生タイプの両方に指定された場合、どちらの制約も妥当性が検査される。テーブルのチェック制約は、プロパティ全体に適用されることに留意されたい。例えばこれを使用して、特定プロパティ値の合計が何らかの制限よりも少ないことをチェックすることができる。代替の方法として、＜ＥｎｔｉｔｙＣｏｎｓｔｒａｉｎｔ＞要素内部に配置されたチェック制約は、各値に個別に適用されることになる。

ナビゲーションプロパティ。ナビゲーションプロパティは、リレーションシップのいずれかのエンドによって指定されたエンティティ上にオプションで配置することができる。このプロパティはリレーションシップの一方のエンドから他方のエンドへとナビゲートする手段を提供する。ナビゲーションプロパティは、＜Ｅｎｔｉｔｙ＞定義内の＜ＮａｖｉｇａｔｉｏｎＰｒｏｐｅｒｔｙ＞要素を使用して表される。この要素は以下の属性を有することができる。
・Ｎａｍｅ−−必須。メンバの名前。この名前は定義タイプの範囲内で一意でなければならない。この名前はクラスメンバ名に関するＣＬＲ規則に従わなければならず、．ＮｅｔＦｒａｍｅｗｏｒｋ命名ガイドラインにも従うものとする。
・ＤｕｐｌｉｃａｔｅＮａｍｅ−−オプション。メンバ名は、ＤｕｐｌｉｃａｔｅＮａｍｅ属性が提供され、値「ｔｒｕｅ」を有していない限り、基本タイプ階層全体にわたっても一意でなければならない。デフォルトの値「ｆａｌｓｅ」は、メンバ名が一意であると予測されることを示す。
この属性の役割は、ａ）メンバ名が基本タイプ内のプロパティと重複している事実をドキュメント化すること、およびｂ）スキーマ設計者に名前を重複させることを意図的に選択させることである（すなわち、Ｃ＃での新規キーワードと同じ役割を果たす）。
・Ａｓｓｏｃｉａｔｉｏｎ−−ＡｓｓｏｃｉａｔｉｏｎまたはＣｏｍｐｏｓｉｔｉｏｎのいずれかの属性が存在しなければならない。このプロパティで表されるアソシエーションの名前を指定する。
・Ｃｏｍｐｏｓｉｔｉｏｎ−−ＡｓｓｏｃｉａｔｉｏｎまたはＣｏｍｐｏｓｉｔｉｏｎのいずれかの属性が存在しなければならない。このプロパティで表される構成の名前を指定する。
・ＦｒｏｍＲｏｌｅ−−必須。ナビゲーションプロパティを備えるエンティティによって表されるエンドのロール。
・ＴｏＲｏｌｅ−−必須。プロパティによって表されるエンドのロール。

タイプ別名（ＴｙｐｅｄＡｌｉａｓｅｓ）。タイプ別名は単純、コレクション、アレイ、テーブル、または参照タイプおよび制約のセットに、一意の名前を与える。タイプ別名は、以下の属性が可能な＜ＴｙｐｅＡｌｉａｓ＞要素を使用して定義される。
・Ｎａｍｅ−−必須。別名の名前
・ＡｌｉａｓｅｄＴｙｐｅ−−必須。別名タイプの名前。これは、単純、コレクション、アレイ、テーブル、または参照タイプでなければならない。

＜ＴｙｐｅＡｌｉａｓ＞要素は、別名タイプに使用可能な任意の制約要素を含むことができる。定義された別名は、別名タイプの名前が使用可能ないずれの場所でも使用することができる。別名のいくつかの例を以下に示す。

テーブルセットおよびテーブルセットタイプ。テーブルセットタイプは、エンティティタイプの制限された形である。テーブルセットタイプは＜ＴａｂｌｅＳｅｔＴｙｐｅ＞要素を使用して定義される。この要素は以下の属性を含むことができる。
・Ｎａｍｅ−−必須。テーブルセットタイプの名前。この名前は、定義スキーマ内のすべてのタイプおよびリレーションシップの中で一意である。
・ＤｅｆａｕｌｔＴａｂｌｅＳｅｔ−−オプション。テーブルセットタイプのデフォルトテーブルセットを指定する。指定されない場合デフォルト値はない。

＜ＴａｂｌｅＳｅｔＴｙｐｅ＞要素は、参照およびテーブルタイプを指定する＜Ｐｒｏｐｅｒｔｙ＞要素を含むことができる。参照プロパティは、テーブルセットタイプのみを指定することができる。＜ＴａｂｌｅＳｅｔＴｙｐｅ＞要素は＜ＣｏｍｐｕｔｅｄＰｒｏｐｅｒｔｙ＞および＜Ｍｅｔｈｏｄ＞要素も含むことができる。

テーブルセットインスタンス。テーブルセットとは、テーブルセットタイプのインスタンスのことである。テーブルセットはデータモデルの「トップレベル」を形成する。すべてのストレージは、テーブルセットを作成することによって直接的または間接的に割り振られる。テーブルセットは＜ＴａｂｌｅＳｅｔ＞要素を使用して記述される。この要素は以下の属性を有することができる。
・Ｎａｍｅ−−必須。テーブルセットの名前。この名前は、定義スキーマ内のすべてのテーブルセットの中で一意でなければならない。
・Ｔｙｐｅ−−必須。テーブルセットタイプの名前。

テーブルセットの集合。＜ＴａｂｌｅＳｅｔ＞要素は、指定されたエンティティタイプ内の各参照タイププロパティに関する＜ＡｇｇｒｅｇａｔｅｄＴａｂｌｅＳｅｔ＞要素を含む。これは、以前に定義されたテーブルセットを新しいテーブルセットに集合させることができる。これは、２つの別々のアプリケーションから単一のアプリケーションにデータを組み合わせる場合に役立つ。＜ＡｇｇｒｅｇａｔｅｄＴａｂｌｅＳｅｔ＞要素は、以下の属性を含むことができる。
・Ｐｒｏｐｅｒｔｙ−−必須。参照タイププロパティの名前。
・ＴａｂｌｅＳｅｔ−−必須。プロパティによって参照されることになるテーブルセットの名前。

この例を以下に示す。
Ｓａｌｅｓスキーマより

ＷｉｎＦＳスキーマより

Ｔｈｉｒｄスキーマより

照会言語。ＣＤＭ用の照会言語を指定することができる。照会言語は、エンティティおよびリレーションシップなどのＣＤＭ概念をターゲットとするＳＱＬに基づくことができる。

照会での構成の使用。以下のパターンは、入力テーブルが基本とするテーブルセットを決定することによって動作する。構成は、以下の機能を照会で使用できるようにすることができる。
・ Table(parent-type) composition.Getparent-role-p(Table(child-type))−−入力された複数の子の複数の親を戻す。
・ parent-type composition.Getparent-role-s(child-type)−−入力された子の親。
・ Table(parent-type) composition.Filterparent-role-p(Table(parent-type),Table(child-type))−−入力された複数の子のセットにおける子の存在によってフィルタリングされた複数の親のセットを戻す。
・ Table(child-type) composition.Getchild-role-p(Table(parent-type))−−入力された複数の親の複数の子を戻す。
・ Table(child-type) composition.Getchild-role-p(parent-type)−−入力された親の複数の子を戻す。
・ Table(child-type) composition.Filterchild-role-p(Table(child-type), Table(parent-type))−−入力された複数の親のセットにおける子の存在によってフィルタリングされた複数の子のセットを戻す。

上記で、ｃｏｍｐｏｓｉｔｉｏｎは構成名を表し、ｐａｒｅｎｔ−ｒｏｌｅ−ｓは単数形の親ロール名を表し、ｐａｒｅｎｔ−ｒｏｌｅ−ｐは複数形の親ロール名を表し、ｃｈｉｌｄ−ｒｏｌｅ−ｓは単数形の子ロール名を表し、ｃｈｉｌｄ−ｒｏｌｅ−ｐは複数形の子ロール名を表し、ｐａｒｅｎｔ−ｔｙｐｅは親エンティティタイプを表し、ｃｈｉｌｄ−ｔｙｐｅは子エンティティタイプを表し、Ｔａｂｌｅ（ｔｙｐｅ）は特定タイプのテーブルを介した照会を表す。

照会でのアソシエーションの使用。これらのパターンは入力テーブルが基本とするテーブルセットを決定することによって動作する。アソシエーションは、以下の機能を照会で使用できるようにすることができる。
・ Table(end-1-type) association.Getend-1-role-p(Table(end-2-type))−−指定された複数のｅｎｄ−２エンティティに関連付けられたｅｎｄ−１エンティティを戻す。
・ Table(end-1-type) association.Getend-1-role-p(end-2-type)−−指定されたｅｎｄ−２エンティティに関連付けられたｅｎｄ−１エンティティを戻す。
・ Table(end-1-type) association.Filterend-1-role-p(Table(end-1-type),Table(end-2-type))−−入力されたｅｎｄ−２エンティティのセットにおける関連付けられたｅｎｄ−２エンティティの存在によってフィルタリングされた複数のｅｎｄ−１のセットを戻す。
・上記方法は、存在する場合アソシエーションエンティティを含む、すべてのエンドの組合せについて繰り返される。

上記で、ａｓｓｏｃｉａｔｉｏｎはアソシエーション名を表し、ｅｎｄ−１−ｒｏｌｅ−ｓは単数形のエンドのロール名を表し、ｅｎｄ−１−ｒｏｌｅ−ｐは複数形のエンドのロール名を表し、ｅｎｄ−２−ｒｏｌｅ−ｓは単数形のエンドのロール名を表し、ｅｎｄ−２−ｒｏｌｅ−ｐは複数形のエンドのロール名を表し、ｅｎｄ−１−ｔｙｐｅはソースエンティティタイプを表し、ｅｎｄ−２−ｔｙｐｅはターゲットエンティティタイプを表し、Ｔａｂｌｅ（ｔｙｐｅ）は特定タイプのテーブルを介した照会を表す。

インターフェース。インターフェースはエンティティおよびインラインタイプにＣＬＲ同様のインターフェースを提供する。これを使用して、インターフェースがオブジェクトタイプシステムで解決するのと同じ問題のほとんどを解決することができる。インターフェースは、＜Ｉｎｔｅｒｆａｃｅ＞要素を使用して宣言される。＜Ｉｎｔｅｒｆａｃｅ＞要素は以下の属性を有することができる。
・Ｎａｍｅ−−必須。インターフェースの名前。スキーマで定義されたすべてのタイプおよびトップレベルテーブルの中で一意でなければならない。
・ＢａｓｅＩｎｔｅｒｆａｃｅｓ−−オプション。このインターフェースの派生元であるインターフェースのコンマで区切られたリスト。

＜ＥｎｔｉｔｙＴｙｐｅ＞または＜ＩｎｌｉｎｅＴｙｐｅ＞要素は、ＩｍｐｌｅｍｅｎｔｅｄＩｎｔｅｒｆａｃｅｓ属性を使用して、これをインプリメントするインターフェースのコンマで区切られたリストを指定することができる。リストアップされたインターフェースで定義されたそれぞれのプロパティを、タイプ内で定義することができる。Ｃ＃のインターフェースと同様に、インターフェースで定義されたプロパティは、同じ名前およびタイプを備えたプロパティを宣言するだけで、タイプ内で暗黙的にインプリメントされる。これが宣言されると、プロパティに課される制約を狭めることができる。プロパティは明示的にインプリメントすることもできる。これは、インターフェースタイプ名をプロパティ名に含めることによって実施される（Ｃ＃の場合と同様）。これにより、同じ署名を有するが異なるインターフェースから継承されるプロパティに、様々な制約を適用することができる。例えば以下のとおりである。

以下に完全なスキーマの例を示す。以下の例は、Ｃｕｓｔｏｍｅｒ、Ｏｒｄｅｒ、ＯｒｄｅｒＬｉｎｅ、Ｐｒｏｄｕｃｔ、およびＳｕｐｐｌｉｅｒのエンティティタイプ、ならびにこれらのエンティティがどのように関係するかを記述するアソシエーションを定義する。

ＳＱＬ９９およびＣＤＭ。ＳＱＬ９９は、コアリレーショナルデータモデル（例えば、ＳＱＬ９２）へのいくつかのオブジェクト拡張を定義する。ＳＱＬ９９のいくつかの主要なアスペクトは、Ｄｉｓｔｉｎｃｔ（特殊）タイプおよびＳｔｒｕｃｔｕｒｅｄ（構造化）タイプの両方を含むＵｓｅｒ−ｄｅｆｉｎｅｄ（ユーザ定義）タイプ、Ｍｅｔｈｏｄｓ（メソッド）（Ｂｅｈａｖｉｏｒｓ（動作））、ＴｙｐｅｄＴａｂｌｅｓ（タイプ別テーブル）、およびＲｅｆｓ（参照）である。

ＳＱＬ９９は、ＳＱＬデータモデル内で自己完結した完全なタイプシステムの一部またはすべてを定義する。プログラミング言語内のオブジェクトはＳＱＬオブジェクトにマッピングできるが、プログラミング言語（例えばＪａｖａ（登録商標）、Ｃ＃）との緊密結合を定義することがＳＱＬ９９の目標ではない。例えばＳＱＬ９９では、メソッドは標準的なプログラミング言語ではなくＳＱＬ手続き型言語で定義される。ＣＤＭの目標は、ＳＱＬおよびＣＬＲの両方との緊密なアライメント（ａｌｉｇｎｍｅｎｔ）を指定することである。

ユーザ定義タイプ。ＣＤＭにおける単純および複合タイプは、ＳＱＬ９９のユーザ定義タイプを使用してほぼ１対１でマッピングする。単純タイプおよび単純タイプ別名は、ＳＱＬ９９のスカラタイプおよび特殊タイプにマッピングし、複合タイプはＳＱＬ９９構造化データタイプにマッピングする。ＳＱＬ構造化タイプと複合タイプとの主な相違点は、ＩｎｌｉｎｅタイプとＥｎｔｉｔｙタイプとの違いである。ＣＤＭでは、アイデンティティ／キーの概念はタイプ定義時に定義される。ＳＱＬ９９では、アイデンティティは、タイプ別テーブルの定義にタイプが使用される場合に定義される。したがってＳＱＬ９９では、アイデンティティを有するタイプと有さないタイプを区別する必要はなく、それによって、テーブル（参照可能オブジェクト）と列定義（参照不可、インラインオブジェクト）の両方に対するタイプの再使用をサポートしていた。こうしたタイプの再使用は、テーブル定義の際にアイデンティティが定義できる場合にのみ、ストレージとして働く。しかしながら、同じタイプをインラインクラスならびに参照可能クラスにマッピングすることはできない。ＣＤＭの目標がアプリケーションオブジェクトフレームワークおよび持続性フレームワークを提供することであるため、インラインタイプとエンティティタイプとの区別は重要である。

メソッド／動作。ＣＤＭでは、動作はＣＬＲフレームワークを使用して定義される。ＳＱＬ９９はそれ自体のメソッド／動作フレームワークを定義する。これはほとんどの最新のＯＯ言語に対して閉じている（ｃｌｏｓｅｄ）から、依然として異なり、アプリケーションに良好なプログラミング環境を提供しない。通常、アプリケーション（またはアプリケーションサーバ）はプログラミング環境とデータベース環境の間の溝を埋める。

タイプ別テーブル対エンティティテーブル。ＣＤＭのエンティティテーブルはＳＱＬ９９のタイプ別テーブルと同様である。しかしながら、エクステントは論理的、すなわちオブジェクトの論理コレクションである。エクステントに関連付けられた物理ストレージはない。タイプテーブルはすべてのストレージ属性がテーブル上に存在できるＳＱＬテーブルである。エクステントは１つまたは複数の物理テーブルにマッピング可能である。

参照。ＣＤＭとＳＱＬ９９とでは、参照が非常に似ている。ＣＤＭでは、参照は参照用のエクステントを指定することによってスコーピングされ、ＳＱＬ９９では、参照は参照用のターゲットとしてタイプテーブルを指定することによってスコーピングされる。どちらの場合も、参照はオブジェクトに解決される。

図１５は、主題となるアーキテクチャのＣＤＭを利用可能なデータプラットフォーム１５００を示す概略図である。この概略図で任意の構成要素および／またはボックスを位置決めすることは、プロセス／マシンの境界を横切るいかなる特定の配置も示唆しない（または必ずしも防がない）ことを理解されよう。データプラットフォーム１５００は、変更が保存される場合、および基礎となるデータへの他の変更がすでに実行された場合、競合検出がアプリケーション特有の方法でこれを解決するように、楽観的並行性モデルを利用することができる。効果的なプラットフォームにするために、データプラットフォーム１５００は、プログラミング言語統合、リッチデータモデル化、持続性フレームワーク、サービス、その他などの機能を含む。ＡＰＩ１５０２は、ストア１５０８へのデータプラットフォームランタイム１５０６を介して、アプリケーション１５０４による言語統合およびデータアクセスを容易にする。データプラットフォーム１５００は、以下の機能を提供する。

ＣＤＭ。データプラットフォーム１５００の中央にあるランタイム１５０６はＣＤＭ１５１０である。ＣＤＭ１５１０の意図は、主にユーザデータ（ＰＩＭ、ドキュメントなど）で動作するアプリケーションからＬＯＢおよび企業データまで複数のアプリケーションドメインに共通のモデル化概念を取り除くことである。リッチなオブジェクトおよびリレーションシップ抽象化の提供に加えて、ＣＤＭ１５１０は構造、非構造化、および半構造化データのサポートを提供する。

行／エンティティデータ。ＣＤＭ１５１０は、構造および構造化データ（例えばビジネスデータ）の動作をキャプチャするためにリッチエンティティ−リレーションシップモデルをサポートする。ＣＤＭ１５１０は、リッチオブジェクト抽象化およびリレーションシップモデル化用の拡張を備えた（例えば、ＤｏｃｕｍｅｎｔｓとＣｏｎｔａｃｔｓとの間のＡｕｔｈｏｒリレーションシップ、ＰｕｒｃｈａｓｅＯｒｄｅｒｓとＯｒｄｅｒＬｉｎｅｓとの間のＬｉｎｅｓリレーションシップ）、コアリレーショナルモデルのスーパーセットである。

ファイルデータ。ＣＤＭ１５１０は、非構造化（ファイル）データを格納および操作するために、「ファイルストリーム」データタイプをサポートする。ファイルストリームデータタイプは、ファイルとしてデータを格納することが可能であり、ファイルアクセスＡＰＩをサポートする。ファイルストリームデータタイプは、本来、ＮＴＦＳファイルストリームにマッピングされたＳＱＬサーバでサポートされ、すべてのファイルハンドル／ストリームベースオペレーションをサポートする。ＣＤＭ１５１０では、非構造化コンテンツのファイルストリームとしてのモデル化に加えて、エンティティタイプを使用し、有用なコンテンツを構造化プロパティとしてプロモートすることができる。データベースベースのファイルストレージシステムは、構造化プロパティならびに非構造化コンテンツのファイルストリームをモデル化するエンティティである、ファイルバックアイテム（ｆｉｌｅｂａｃｋｅｄｉｔｅｍ）の概念を定義する。ファイルバックアイテムは、関連するファイルストリーム上でのリッチ照会ならびにストリームベースオペレーションを提供する。

ＸＭＬデータ。ＣＤＭ１５１０では、（１）ＸＭＬデータタイプとして格納すること、（２）ＸＭＬドキュメントを１つまたは複数のエンティティにマッピングすること（例えばデータ契約と同様）、という２つの主な方法で、ＸＭＬドキュメントをモデル化することができる。ＣＤＭ１５１０は、ＳＱＬサーバでサポートされるように、ＸＭＬデータタイプをサポートする。ＸＭＬデータタイプは任意のエンティティプロパティのタイプとすることが可能であり、ＸＭＬデータタイプは、非タイプ別またはタイプ別のＸＭＬドキュメントを格納することができる。１つまたは複数のＸＭＬスキーマをＸＭＬドキュメントプロパティに関連付けることによって、強力なタイプ化が提供される。

ＡＰＩ１５０２における、照会を含むプログラミング言語統合。データプラットフォーム１５００の機能構成要素である、セッションおよびトランザクション１５１２、照会１５１４、持続性１５１６、カーソル１５１５、サービス１５２０、オブジェクトキャッシュ１５２２、ならびにビジネス論理ホスティング１５２４は、データプラットフォームＡＰＩ１５０２で使用可能ないくつかの「ランタイム」クラスに封入される。

持続性エンティティ１５１６は、リレーショナルストアからの構成要素部片からオブジェクトがどのようにアセンブルされるかを正確に記述する宣言型マッピング定義を提供する、持続性エンジンを含む。エンジンは、オブジェクト照会式に関して照会プロセッサによって定義された式を取得し、次にこれを宣言型マッピングと組み合わせる、照会生成構成要素（図示せず）を含む。これが、データベース内の基礎となるテーブルにアクセスする等価照会式に変わる。更新生成構成要素（図示せず）は、変更追跡サービスに注目し、メタデータのマッピングからの支援により、オブジェクトの世界でのこれらの変化をテーブルの世界での変化に変換する方法を記述する。

持続性エンジンは、オブジェクト−リレーショナルマッピングを含むことができる。言い換えれば、データプラットフォーム１５００によって提供されるモデル化、アクセス、および照会の抽象化は、オブジェクトベースである。データプラットフォーム１５００によって使用される主なストレージ技術は、リレーショナルベースである。持続性エンジンはオブジェクト−リレーショナルマッピング（「Ｏ−Ｒマッピング」とも呼ばれる）を使用し、ここで持続性エンジンは、言語クラスを基礎となるテーブル表現にマッピングすることができる。

ファイルおよびＸＭＬデータの照会／検索。ＣＤＭ４０２は、それぞれファイルストリームおよびＸＭＬデータタイプを使用して、非構造化および半構造化データを格納する。ＣＱＬは、これらのデータタイプを照会することができる。構造化エンティティにプロモートされるファイルコンテンツ（例えばＷｉｎＦＳファイルバックアイテム）では、ＣＱＬのリレーショナルオペレータはこれらのエンティティを照会することができる。ファイルストリームとして格納された非構造化データは、フルテキスト検索を使用して照会することができる。ＸＭＬコンテンツは、ＸＰａｔｈまたはＸＱｕｅｒｙを使用して照会することができる。

オブジェクト−リレーショナルマッピング。データプラットフォーム１５００は、リレーショナル（テーブル）ストレージのトップにオブジェクトベース抽象化を提供するため、Ｏ−Ｒマッピング構成要素を提供する。データプラットフォーム１５００は、透視マッピングおよび非透視マッピングの両方をサポートする（タイプ設計者はマッピングを指定する際にある程度の柔軟性を有する）。現在のデータベースベースのファイルストレージシステムインプリメンテーションは透視マッピングを使用するが、より一般的なＯ−Ｒ持続性フレームワークには非透視マッピングが必要である。

キャッシング。データプラットフォームランタイム１５０６は、照会結果（例えばカーソル）および非コミット更新のキャッシュを維持する。これはセッションキャッシュと呼ばれる。データプラットフォーム１５００は、アプリケーションが非接続モードで動作できるようにする明示的キャッシュも提供する。データプラットフォーム１５００は、明示的キャッシュ内のデータに関する様々な整合性の保証を提供する。キャッシュは、データのオンディスクアイデンティティをインメモリオブジェクトと相関させることによって、アイデンティティ管理を実行する。データプラットフォームランタイム１５０６は、照会結果（例えば以下で詳細に論じるカーソル）および非コミット更新のキャッシュ１５２２を維持し、こうしたキャッシュはセッション、トランザクション１５１２に関係しているため、セッションキャッシュと呼ばれる場合がある。加えてこれは、セッションが作成されると出現し、セッションが終了するとなくなる。

データプラットフォーム１５００は、明示的キャッシュと呼ばれる別の種類のキャッシュも公表することができる。明示的キャッシュは、１つまたは複数の照会からのデータのキャッシュを提供する。データが明示的キャッシュに具体化されると、１）読み取り専用、権限なし、２）ライトスルー、権限あり、および３）外生（ｅｘｏｇｅｎｏｕｓ）通知を介した自動リフレッシュの、データ整合性保証が与えられる。明示的キャッシュに対するプログラミングおよび照会モデルは、ストアデータを介するものとほぼ同様とすることができる。

照会プロセッサ。データベースアクセスは照会プロセッサを介して行われる。照会プロセッサは、複数の照会言語を処理するために複数のフロントエンドを表現し、その後、内部正規フォーマットにマッピングできるようにするものである。これは、ドメインモデルおよびこれが動作するアプリケーションのオブジェクトに関して実行される。その後、パイプラインであるプロセッサに照会が渡され、バックエンド特有の照会に変換される。

カーソル。データプラットフォーム１５００は、順方向専用カーソルおよびスクロール可能カーソルの両方を提供することができる。カーソルは、通知、拡張／縮小状態でのマルチレベルグルーピング、動的ソート、およびフィルタリングをサポートする。カーソル、規則１５１５は、ＣＱＬから戻されたデータエンティティのセットを１回に１つずつ処理できるようにするメカニズムである。アプリケーションは、単に結果セット全体をメモリにコピーすること、およびメモリ構造内でこのトップにスクロールパターンをオーバレイすることによって、結果セットを介してカーソルを作成することができる。しかし、時にカーソルのインプリメンテーションに関与してこの要件および複雑さが遍在する（特に、更新、ページングなどが考慮に入れられる場合）ということは、任意のデータプラットフォームがカーソルモデルを提供するべきであることを意味する。ブラウジングおよびスクロールの基本機能に加えて、データプラットフォームカーソルは、１）外生通知および保守、２）拡張／縮小状態でのマルチレベルグルーピング、ならびに３）動的ソートおよびフィルタリング（例えば「後処理」）、の機能を提供することができる。カーソルは結果セットを指定するための異なるメカニズムとすることはできないこと、結果セットは照会によって指定されること、およびカーソルはこれら照会を介するものであることを、理解されよう。

ビジネス論理ホスト１５２４。データプラットフォーム１５００は、タイプ／インスタンスおよびオペレーションに関してデータ中心論理をホストするために、ランタイム環境を提供する。こうしたデータ中心ビジネス論理は、アプリケーションサーバ内でホスト可能なアプリケーション／ビジネスプロセス論理とは別のものである。オブジェクトは、データベース内の単なる行ではない。オブジェクトがメモリ内で具体化された場合、実際にはアプリケーションが呼び出すことのできる動作を有するオブジェクトである。システム内には、ランタイム時にデータプラットフォーム１５００を拡張するようにすべてが動作する、主としてイベントおよびコールバックである、拡張ポイントがある。これらのオブジェクトは単なるオブジェクトではなく、ＣＬＲオブジェクト、．ＮＥＴオブジェクトなどである。データプラットフォーム１５００は、それらオブジェクト内でプロパティまたはメソッド呼び出しをインターセプトする機能を可能にする。アプリケーションはこれらオブジェクトの動作をカスタマイズすることができる。

データプラットフォーム１５００は、ビジネス論理をオーサリングするためのいくつかのメカニズムを提供する。これらのメカニズムは、制約、イベントハンドラ、静的／インスタンスメソッド、結合可能動作、および静的サービスメソッドの、５つのカテゴリに分けることが可能であり、そのそれぞれについて、以下でより詳細に論じる。制約／セキュリティエンティティ１５２６は、宣言型および手続き型とすることができる。これらの制約は、データに近接したストア上で実行可能である。したがって、制約１５２６は信用の境界内にあるものとみなされる。さらに、タイプ設計者は制約をオーサリングすることができる。

ビジネス論理ホスティング１５２４は、イベントハンドラを使用することができる。データプラットフォームＡＰＩ１５０２は、データ変更オペレーションでいくつかのイベントを発生させる。ビジネス論理作成者は、ハンドラコードを介してこれらのイベントに接続（ｈｏｏｋｉｎｔｏ）することができる。例えば、注文管理アプリケーションについて考えてみる。新しい注文が入ると、アプリケーションは、その注文の価格が顧客に許可された信用限度より低いことを確認する必要がある。この論理は、注文がストアに挿入される前に実行されるイベントハンドラコードの一部とすることができる。

サービス。データプラットフォーム１５００は、すべてのデータプラットフォームクライアントが利用できるサービスのコアセットを提供する。これらのサービスには、規則、変更追跡、競合検出、イベント化、および通知が含まれる。イベント化は、フレームワークレベルのサービスから、または追加の動作を加えるためのアプリケーション用に、データプラットフォームランタイム１５０６を拡張するものであり、ユーザインターフェースでのデータの結合にも使用される。

制約。データプラットフォーム１５００は、タイプ設計者が制約を宣言的に作成できるようにするために、制約／セキュリティ構成要素１５２６を提供する。これらの制約はストア内で実行される。通常、データプラットフォーム制約の範囲は、長さ、精度、スケール、デフォルト、チェックなどの概念を包含する。これらの制約は、データプラットフォーム制約エンジン１５２６によってランタイム時に強制される。

セキュリティ。データプラットフォーム１５００は、ユーザの信用証明がその「役割」（管理者、パワーユーザ、承認者など）を決定する、役割ベースのセキュリティモデルを提供する。各役割にはアクセス許可のセットが割り当てられる。データプラットフォームセキュリティエンジン１５２６は、これらのセキュリティポリシーを強制する。加えて、データプラットフォーム１５００は、データプラットフォーム１５００内のエンティティへのアクセスを制御するためのセキュリティモデルを提供する。セキュリティモデルは、オペレーティングシステムユーザの認証、エンティティの許可レベル（例えば、読み取りおよび更新用に別々の許可を与える）などをサポートすることができる。

制約／セキュリティ構成要素１５２６は、データプラットフォームランタイム構成要素１５０６とは別のエンティティとして動作可能であるため、これとは別に図示されていることに留意されたい。代替方法として、またおそらくより効率的に、制約／セキュリティ構成要素１５２６は、データベースシステムとすることが可能なストア構成要素１５０８と組み合わされる。

以下の図１６〜１８では、図面内の各クラスはモデルまたはスキーマ要素である。「Ｓ」と示された要素は、ＳＤＬ内の要素である。他の要素は、構造化要素、暗黙的構築要素（参照タイプなど）、または組み込み要素（直接宣言によってではなく、ＣＬＲタイプのインポートによって拡張される単純タイプなど）のいずれかである。

図１６は、タイプに関するモデルのいくつかのセマンティクスを明確にするＣＤＭメタモデルフラグメントを示す図である。これらのモデルは、正確な構文をモデル化するのではなく、スキーマの効果を記述する。例えば、アソシエーションエンドロールの名前を使用する属性は、これらのモデル内のアソシエーションエンドへの参照として表される。コメントおよび追加の制約を以下に示す。

エンティティタイプの宣言は、ＥｎｔｉｔｙＣｏｌｌｅｃｔｉｏｎＴｙｐｅおよびＲｅｆｅｒｅｎｃｅＴｙｐｅを暗黙的に定義する。複合タイプの宣言は、ＩｎｌｉｎｅＣｏｌｌｅｃｔｉｏｎを暗黙的に定義する。実際には、これらのタイプはＲｅｆ＜Ｔ＞、ＥｎｔｉｔｙＣｏｌｌｅｃｔｉｏｎ＜Ｔ＞、ＩｎｌｉｎｅＣｏｌｌｅｃｔｉｏｎ＜Ｔ＞などの総称でインプリメントすることができる。
・プロパティは、インラインおよびエンティティタイプの宣言でのみ宣言可能である。
・ typeof(InlineCollectionType.ElementType) != InlineCollectionType

図１７は、プロパティに関するモデルのいくつかのセマンティクスを明確にするＣＤＭメタモデルフラグメントを示す図である。コメントおよび追加の制約を以下に示す。
Ｐｒｏｐｅｒｔｙ．Ｋｉｎｄは、Ｐｒｏｐｅｒｔｙメタクラスがタイプを有し、それが表すプロパティがタイプを有する場合、アソシエーション制約を読みやすくする。Ｋｉｎｄは、生じる可能性のあるいかなる混乱も回避する。
・ＡｓｓｏｃｉａｔｉｏｎＥｎｄ．Ｐｒｏｐｅｒｔｙは、アソシエーションの同じエンドにあるエンティティを参照するプロパティである。言い換えれば、アソシエーションの反対側にあるエンティティ上のプロパティである。
・参照またはエンティティセットのプロパティは、基礎となるエンティティタイプを有するアソシエーションプロパティである。
・ナビゲーションプロパティは照会を戻す。

図１８は、アソシエーションに関するモデルのいくつかのセマンティクスを明確にするＣＤＭメタモデルフラグメントを示す図である。ここで制約のほとんどは、アソシエーションエンドのプロパティが右側のタイプ（ｒｉｇｈｔｔｙｐｅ）でなければならないことを単に示すものであり、この右側のタイプは非常に明白である。例えば、Ｒｅｆｅｒｅｎｃｅスタイルアソシエーションは参照タイプのプロパティを有するものでなければならない。コメントおよび追加の制約を以下に示す。

ＡｓｓｏｃｉａｔｉｏｎＥｎｄ．Ｐｒｏｐｅｒｔｙは、アソシエーションの他方のエンドのエンティティタイプのプロパティである。これは、アソシエーションのこのエンドのエンティティを参照するプロパティを示す。アソシエーションに関してより正式に表すと以下のようになる。
Ends[0].Property.UnderlyingType=Ends[1].Typeおよび
Ends[1].Property.UnderlyingType=Ends[0].Type
・ＣｏｍｍｏｎＶａｌｕｅ．Ｐｒｏｐｅｒｔｉｅｓのうちの１つは、共通値アソシエーションの２つのエンティティそれぞれからのものである。

代替インプリメンテーションおよび構文
次に、オブジェクト−リレーショナルデータに関するデータモデルの代替インプリメンテーションを示す。この代替インプリメンテーションの説明では、この代替インプリメンテーションを表現するための多くの可能な形式の１つであるスキーマ定義言語を使用する。また、前述のインプリメンテーションとの類似点が多いが、例えば命名および構文の形において顕著な相違点があることにも留意されたい。

この代替の説明では、リレーションシップは＜Ａｓｓｏｃｉａｔｉｏｎ＞または＜Ｃｏｍｐｏｓｉｔｉｏｎ＞要素を使用してトップレベルで定義することができる。Ｒｅｆアソシエーション（または構成）を定義するために、ソース（または親）のプロパティを定義する必要はない。ＯｎＣｏｐｙ、ＯｎＳｅｒｉａｌｉｚｅ、ＯｎＳｅｃｕｒｅ、およびＯｎＬｏｃｋは、リレーションシップで導入されるオペレーション動作である。ＥｎｔｉｔｙＳｅｔｓは、ＥｎｔｉｔｙＣｏｎｔａｉｎｅｒＴｙｐｅ内でのみ定義され、ＥｎｔｉｔｙＴｙｐｅ内では定義されない。ＮａｖｉｇａｔｉｏｎＰｒｏｐｅｒｔｙはもはや使用されず、ＲｅｌａｔｉｏｎｓｈｉｐＰｒｏｐｅｒｔｙがわずかに異なるセマンティクスで使用される。

明示的Ｒｅｆタイププロパティはエンティティへの非スコープ参照であり、リレーションシップは作成しない。ＲｅｌａｔｉｏｎｓｈｉｐＰｒｏｐｅｒｔｙは暗黙的にＲｅｆ（またはＣｏｌｌｅｃｔｉｏｎ（Ｒｅｆ））タイプである。リレーションシップ範囲は、エンティティコンテナタイプの＜Ｓｃｏｐｅ＞節内に指定される。

リレーションシップはより抽象的に作られている。以前のインプリメンテーションでは、リレーションシップはエンティティ内の参照またはコレクション値プロパティによって暗黙的に定義されたが、これはリレーションシップをインプリメントする方法を前提とするものである。ここでは、リレーションシップはトップレベルで定義される。これによって、タイプ宣言からリレーションシップメタデータが除去され、タイプの再使用が可能になる。

階層化。参照アソシエーション、条件付アソシエーション、およびアソシエーションエンティティは、すべて＜Ａｓｓｏｃｉａｔｉｏｎ＞要素内で定義される。これは、メタモデルが、２つのエンティティ間のアソシエーションのコア概念を有するという事実を反映するものであり、これが参照、条件に基づくか、またはアソシエーションエンティティを通じて関係するかは、＜Ａｓｓｏｃｉａｔｉｏｎ＞内の様々なタグおよびサブエレメントによって定義される。特殊概念（参照、条件、アソシエーションエンティティ）は、コア概念（アソシエーション）のトップで階層化される。

コアモデリングと持続性の分離。エンティティコレクションの概念は、以前のインプリメンテーションで２つの目的に使用された。その第１はエンティティの持続性グループを命名および参照するための方法として、第２は構成を定義するための方法として使用することである。したがって、構成をモデル化するためだけに持続性に対応しなければならなかった。ここでは、エンティティコレクションは純粋なグループ化／スコーピングの概念であり、エンティティタイプ内のフィールドとしては使用できない。構成は、関与するエンティティに関する抽象メタデータを指定することによって、トップレベルで定義される。持続性を構成から分離することによって、モデルはより柔軟かつ直交性のあるものとなる。

コレクションの簡略化。ここでのエンティティコレクションは、ＥｎｔｉｔｙＣｏｎｔａｉｎｅｒＴｙｐｅ（上記ではＥｎｔｉｔｙＤａｔａｂａｓｅＴｙｐｅとして理解されていた）内でのみ可能であり、インラインコレクションのみをエンティティまたは複合タイプのプロパティとすることができる。これは、コレクションセマンティクスの簡略化の結果である。もはや、エンティティコレクションとインラインコレクションとを区別する必要はない。単なる「コレクション」が存在し、インラインタイプを集めるために使用される。

操作セマンティクスの指定機能。このインプリメンテーションではアソシエーションまたは構成要素のリレーションシップを指定し、そのタイプに関係なく任意のリレーションシップでの操作の動作を直交的に指定する。したがって、任意のリレーションシップでＯｎＣｏｐｙ、ＯｎＳｅｒｉａｌｉｚｅ、ＯｎＳｅｃｕｒｅ、ＯｎＬｏｃｋ動作を指定できるようになっている。これによってもやはりさらなる柔軟性が与えられ、より大規模なシナリオセットがキャプチャされる。

エンティティの任意のグループ化。ＷｉｎＦＳ「アイテム」の概念は、実際はいくつかのエンティティ（例えばＩｔｅｍエンティティ、ＩｔｅｍＦｒａｇｍｅｎｔエンティティ、および収容されたエンティティ）をグループ化する操作である。以前に定義された構成は、この概念をモデル化することを過度に制約していた。操作セマンティクスを指定する機能およびエンティティコレクションをリレーションシップ定義から分離することにより、操作の動作を選択し、これを任意のエンティティのグループ化に適用することができる。

改名。セマンティクスをよりよく反映させるために、いくつかの名前が変更されている。例えば、（ａ）ＥｎｔｉｔｙＣｏｌｌｅｃｔｉｏｎはＥｎｔｉｔｙＳｅｔに変更され、エンティティの順不同のグループ化となったため、古典的なＥＲモデリングで使用される用語にも整合し、（ｂ）「データベース」という用語が多くの持続性／操作／管理上の含意を有するため、これをなくすためにＥｎｔｉｔｙＤａｔａｂａｓｅＴｙｐｅがＥｎｔｉｔｙＣｏｎｔａｉｎｅｒＴｙｐｅに変更され、（ｃ）Ｃｏｌｌｅｃｔｉｏｎがこのインプリメンテーションモデル内で可能な唯一のコレクションの種類であるため、ＩｎｌｉｎｅＣｏｌｌｅｃｔｉｏｎはＣｏｌｌｅｃｔｉｏｎに変更された。

ＥｎｔｉｔｙＤａｔａｂａｓｅはもはや使用されないが、ここではＥｎｔｉｔｙＤａｔａｂａｓｅＴｙｐｅのインスタンスである。＜ＡｓｓｏｃｉａｔｉｏｎＥｎｔｉｔｙＴｙｐｅ＞は＜Ａｓｓｏｃｉａｔｉｏｎ＞要素内で定義されている。

したがってデータモデルは、アプリケーションが関心のある様々なデータの部片の、形状およびセマンティクス（制約、動作）、ならびにこれらの間のリレーションシップを記述するものである。

図１９は、ＣＤＭの代替インプリメンテーションの４つの主な概念を示す図である。前述のように、４つの概念とはタイプ、インスタンス、エンティティ、およびリレーションシップである。図１９は、典型的には、異なる種類のデータである注文、顧客、注文ライン、住所、供給業者、製品、従業員、などの処理が可能な、ＬＯＢアプリケーションと関連付けることのできるデータのサブセットを示す。Ｃｕｓｔｏｍｅｒ（顧客）とラベル表示されたボックスについて考えてみる。ＣＤＭではこれはエンティティと呼ばれ、アプリケーションが作業の対象とするトップレベルのデータ単位を表す。Ｃｕｓｔｏｍｅｒには、ＣｕｓｔｏｍｅｒＩＤ、ＣｏｍｐａｎｙＮａｍｅ、ＣｏｎｔａｃｔＮａｍｅ、Ａｄｄｒｅｓｓ、およびＰｈｏｎｅといういくつかのフィールドがある。各フィールドはタイプを有し、これがそのフィールドに入るデータの構造を決定する。ＣｕｓｔｏｍｅｒＩＤが固定長の文字列であることは容易にわかるであろう。ＣｏｍｐａｎｙＮａｍｅおよびＣｏｎｔａｃｔＮａｍｅフィールドも、タイプ文字列である。Ｃｕｓｔｏｍｅｒそれ自体がタイプを有する。Ｃｕｓｔｏｍｅｒはエンティティであるため、このタイプはエンティティタイプと呼ぶことができる。Ａｄｄｒｅｓｓフィールドは他のフィールドとは異なり、他のフィールドの形の内部構造を有することにも留意されたい。ＣＤＭでは、こうしたフィールドのタイプを複合タイプと呼ぶ。これとは対照的に、ＣｕｓｔｏｍｅｒＩＤ、ＣｏｍｐａｎｙＮａｍｅ、およびＣｏｎｔａｃｔＮａｍｅのタイプはすべて単純タイプである。Ｐｈｏｎｅフィールドはいくつかの電話番号からなり、それぞれが文字列である。これはコレクションタイプと呼ばれる。タイプは構造（および値に関するある種の制約）を指定し、実際のデータはこれらタイプのインスタンスに格納される。タイプおよびインスタンスは、それぞれクラスおよびオブジェクトと同様である。図１９は、Ｃｕｓｔｏｍｅｒ、Ｏｒｄｅｒ、およびＯｒｄｅｒＤｅｔａｉｌのインスタンスを示す。

ＣｕｓｔｏｍｅｒとＡｄｄｒｅｓｓは、どちらも内部構造を有する（複数のフィールドから構成される）という観点では同様である。しかし、意味論上および操作上では、ＣｕｓｔｏｍｅｒはＡｄｄｒｅｓｓとは異なる。Ｃｕｓｔｏｍｅｒは、照会、データ変更操作、トランザクション、持続性、および共有のための単位として働く。他方でＡｄｄｒｅｓｓは常にＣｕｓｔｏｍｅｒ内に存在し、参照されること、またはそれ以外の方法で独立して動作することはできない。ＣＤＭでは、こうしたトップレベルのデータ単位をエンティティと呼ぶ。すべての他のデータはエンティティへのインラインとみなされる。

次にＯｒｄｅｒ（注文）を見ると、ビジネス規則は、あらゆる注文が対応する顧客を有することを必要とする。これは、ＯｒｄｅｒエンティティとＣｕｓｔｏｍｅｒエンティティとの間のリレーションシップによってモデル化される。ＣＤＭによってサポートされるリレーションシップには様々な種類がある。ＯｒｄｅｒとＣｕｓｔｏｍｅｒとの間のリレーションシップはアソシエーションと呼ばれる。アソシエーションは、通常、エンティティ間のピアツーピアリレーションシップをモデル化するために使用される。各注文は、いくつかの注文ラインで構成される（ある書店から５冊の本が注文された場合、それぞれの本に関する情報が注文ラインである）。これは、別の種類のリレーションシップ、すなわち構成としてモデル化される。構成内の各ＯｒｄｅｒＬｉｎｅ（注文ライン）がエンティティである。

データの形状は、タイプを定義することによって記述される。概念上、タイプとは値のセットに与えられる名前のことである。例えば、何かのタイプがｉｎｔである場合、精密には整数の範囲である値の範囲が指定される。タイプの概念を精密に定義するには、本明細書の範囲を超えたカテゴリ論へと踏み込んでいく必要がある。したがって本明細書では、タイプの概念は形式上は基本的概念であることを前提とする。タイプシステムは、タイプを定義し、これを言語構造に関連付けるためのメカニズムである。

ＣＤＭの中心はそのタイプシステムである。このタイプシステムを使用して定義されたデータは、ＣＬＲと同様、強力にタイプ付けされたものとみなされる。言い換えれば、インプリメンテーションが例外なくタイプ規則を厳しく強制すること、すべてのタイプはコンパイル時にわかっていること、およびいかなるタイプの変換もその影響が予測できることが予期される。

ＣＤＭタイプシステムは、最高レベルで、エンティティタイプおよびインラインタイプの２種類のタイプを定義する。エンティティタイプは一意のアイデンティティを有し、整合性の操作単位を形成する。直感的に言えば、エンティティは、例えばＣｕｓｔｏｍｅｒｓ、Ｏｒｄｅｒｓ、Ｓｕｐｐｌｉｅｒｓなどのデータモデル内で「トップレベル」の概念をモデル化するために使用される。インラインタイプは収容されるタイプである。これらはエンティティタイプの中に含まれる。これらは、収容するタイプとの関連で、存在および消滅し、処理され、その中でのみ参照される。非常に大まかに言えば、エンティティタイプはＣＬＲの参照タイプに類似し、インラインタイプは値タイプに類似する。これは制限付きの類似点であり、ＣＬＲの値タイプのようにインラインタイプは独立した存在を持たず、ＣＬＲの参照タイプのようにエンティティタイプは独立に存在可能であり、独立に参照可能である、という点でのみあてはまる。

インラインタイプには、スカラタイプ、複合タイプ、ＸＭＬタイプ、ＦＩＬＥＳＴＲＥＡＭタイプ、およびこれらタイプのコレクションといういくつかの種類がある。これらタイプのいくつかについて、以下でより詳細に説明する。

タイプを記述するための構文として、スキーマ定義言語（ＳＤＬ）が使用される。ＳＤＬはクラスを定義するためのＣ＃のサブセット、またはＳＱＬのデータ定義言語（ＤＤＬ）サブセットと類似している。ＳＤＬはＸＭＬで表される（ただし、ＸＳＤベースではない）。本説明全体を通じて、説明される概念を示すためにＳＤＬフラグメントが使用されることになる。

スカラタイプは、ある意味で、タイプシステムで使用可能な最も単純なタイプである。システムに対して可視の内部構造はない。スカラタイプは単一の値を表す。ＣＤＭは、単純（Ｓｉｍｐｌｅ）タイプ、列挙（Ｅｎｕｍｅｒａｔｉｏｎ）タイプ、および参照（Ｒｅｆ）タイプという３種類のスカラタイプを定義する。

単純タイプは、システムによって提供される組み込み型の基本タイプである。Ｓｙｓｔｅｍ．Ｓｔｒｉｎｇ、Ｓｙｓｔｅｍ．Ｂｏｏｌｅａｎ、Ｓｙｓｔｅｍ．Ｂｙｔｅ、Ｓｙｓｔｅｍ．Ｉｎｔ１６などのように、ＣＬＲの値タイプがＣＤＭの単純タイプとして使用される。ＣＤＭは、Ｓｙｓｔｅｍ．ＳｔｏｒａｇｅおよびＳｙｓｔｅｍ．Ｄａｔａ．ＳｑｌＴｙｐｅｓネームスペースで定義された、いくつかのタイプもサポートする（Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．ＢｙｔｅＣｏｌｌｅｃｔｉｏｎ、Ｓｙｓｔｅｍ．Ｄａｔａ．ＳｑｌＴｙｐｅｓ．Ｓｑｌｓｉｎｇｌｅ．．．）。

列挙タイプは、（赤、青、緑）または（春、夏、秋、冬）などの記号名のセットを定義する。列挙タイプのインスタンスは、このセット全体に及ぶ値を有する。

参照タイプのインスタンスは、エンティティを識別する値である。参照タイプについては、以下で説明する。

単純タイプを使用して、さらに複合タイプを構築することができる。複合タイプは名前を有すること、または匿名のままとすることができる。

名前付き複合タイプは、名前およびメンバセットを有する。メンバは名前およびスカラタイプのように単純とすることができる。各メンバはスカラタイプ（この場合は単純タイプ）である。これらのようなデータメンバはプロパティと呼ばれる。

複合タイプには、２つの他の種類のメンバ、メソッドおよび算出プロパティが存在可能であり、これらについては以下で説明する。複合タイプは他の複合タイプを含むこともできる。

匿名複合タイプは、その名前が暗に示すように、構造的には複合タイプと同様であるが、これに基づいてプロパティを宣言するためには使用できない。匿名複合タイプは（エンティティからフィールドのサブセットを考案する照会などにおいて）照会結果として戻される。これらは、照会閉包（ｃｌｏｓｕｒｅ）を保証するためにＣＤＭに存在する。ＳＤＬはこれらのタイプを宣言するための構文を持たない。

名前付き複合タイプと匿名複合タイプとの相違点の１つに注目すると、まったく同じ構造を持つが名前の異なる２つの名前付き複合タイプは別のタイプであるとみなされる。しかし、まったく同じ構造を持つ２つの匿名複合タイプは、同じタイプであるとみなされる。

エンティティタイプは、スカラタイプおよび他の複合タイプから構築されるタイプであると言う点で、構造上は複合タイプと同様である。しかしながら、意味論上および操作上はまったく異なり、エンティティはアイデンティティ、様々な操作に関する整合性の単位、およびその他を介して、一意に参照可能である。エンティティタイプは、複合タイプと同様の方法で定義される。

コレクションは、インラインタイプのゼロまたはそれ以上のインスタンスを格納する。以下の例で、Ｐｅｒｓｏｎタイプについて考えてみると、このタイプはある人物に関する連絡先情報を格納する。通常、名前、自宅の住所、勤務先の住所、自宅の電話番号、勤務先の電話番号、携帯電話番号、電子メールＩＤが（最も一般的なサブセットを利用するために）格納される。このリストでは、２つの住所と３つの電話番号があることに留意されたい。これらはＣＤＭを使用して、以下の例に示されるようにコレクションとしてモデル化することができる。

４行目はＡｄｄｒｅｓｓフィールド用にＡｄｄｒｅｓｓ要素のコレクションを定義し、５行目はＰｈｏｎｅＮｕｍｂｅｒフィールド用のＳｔｒｉｎｇ要素のコレクションを定義する。したがってこの人物は、Ｐｅｒｓｏｎオブジェクトの下に例えば２つのコレクション、ＡｄｄｒｅｓｓｅｓおよびＰｈｏｎｅＮｕｍｂｅｒｓを有することができる。ＡｄｄｒｅｓｓｅｓコレクションにはＡｄｄｒｅｓｓタイプの２つのインスタンスが含まれ、ＰｈｏｎｅＮｕｍｂｅｒｓコレクションにはＳｔｒｉｎｇタイプの２つのインスタンスが含まれる。ＣＤＭでは、コレクションは単純タイプおよび複合タイプ用に定義することができる。

コレクションは、しばしばアレイのセマンティクスを有することが望ましい。アレイとは、要素が順序付けおよび索引付けされるコレクションのことである。アレイは順序付けされるが、必ずしもソートされないことに留意されたい。例えば、［１，４，５，３］は順序付けされたコレクションであるが、ソートはされていない。これは、第２の要素を要求すると「４」が返されることが保証される（明示的変更なし）ため、順序付けされている。

コレクションタイプ＜Ｐｒｏｐｅｒｔｙ＞の＜Ｃｏｌｌｅｃｔｉｏｎ＞サブエレメントのＡｒｒａｙ属性は、ｔｒｕｅに設定された場合、これをアレイに入れる。Ａｒｒａｙは、そのデフォルトの値が「ｆａｌｓｅ」を取るオプションの属性である。

通常、アプリケーションによって使用されるデータモデルは多くの異なるタイプを有する。これらタイプのいくつかは、完全に別々の概念、例えばＣｕｓｔｏｍｅｒおよびＯｒｄｅｒをモデル化する。こうしたタイプは、いかなるメンバも共有しない。しかしながら他のタイプは、互いにわずかな類似性を有するが依然として異なる概念をモデル化する。例えば、ＣｕｓｔｏｍｅｒおよびＥｍｐｌｏｙｅｅについて考えてみる。たとえこれらが異なる概念をモデル化しても、それらの間にはどちらも住所、電話番号、および名前に関するプロパティを有するという基礎となる共通性のスレッドが存在する。これは、誰かに連絡を取るために必要な情報である。言い換えれば、これは連絡先情報である。

図２０は、タイプ継承の概念をサポートするＣＤＭを示す図である。継承は、あるタイプが他のタイプから、プロパティ、メソッド、および算出プロパティを継承できるようにするものである。例では、ＥｍｐｌｏｙｅｅおよびＣｕｓｔｏｍｅｒがＣｏｎｔａｃｔから継承する。ここでＣｏｎｔａｃｔはスーパータイプまたは基本タイプと呼ばれる。ＥｍｐｌｏｙｅｅおよびＣｕｓｔｏｍｅｒは、サブタイプまたは派生タイプと呼ばれる。サブタイプ化は単一レベルで止める必要はなく、あるサブタイプを他のタイプの親とすることが可能であって、例えばＥｍｐｌｏｙｅｅをＭａｎａｇｅｒの基本、ＣｕｓｔｏｍｅｒをＰｒｅｆｅｒｒｅｄＣｕｓｔｏｍｅｒの基本、などとすることができる。この方法で、図２０に示すように全体の継承階層を形成することができる。

上記の例ではプロパティの継承のみを示したが、派生タイプもその基本タイプからメソッドおよび算出プロパティを継承する。ＣＤＭは、継承メソッド（動作）に関してＣＬＲセマンティクスに従う。上記の継承階層に対する（部分的）ＳＤＬ指定を以下の例に示す。

前述のように、継承の１つの目的は複数のタイプ間で総称概念を共有することである。継承の他の目的は、拡張可能性である。ＩＳＶが継承階層をインプリメントおよび配置した後でも、顧客は継承を介して自分たちの目的に合うようにタイプを拡張することができる。この拡張可能性を動作させるために重要なものは、派生タイプのあらゆるインスタンスは基本タイプのインスタンスでもあると言う、値の置換可能性（多相性（ｐｏｌｙｍｏｒｐｈｉｓｍ）としても知られる）の概念である。したがって、ＭａｎａｇｅｒがＥｍｐｌｏｙｅｅから派生したものである場合、ＭａｎａｇｅｒのあらゆるインスタンスはＥｍｐｌｏｙｅｅのインスタンスでもある。したがって、すべての従業員（基本タイプ）を照会すると、すべての経営者（派生タイプ）も戻される。

図２１は、このインプリメンテーションに関するＣＤＭタイプの分類法を示す図である。このセクションでは、ＣＤＭタイプシステムにおけるタイプの正しい分類について説明する。より広範囲なセマンティックとの関連において調べると、ほぼすべてのデータが何らかの形でそのタイプのドメイン全体にわたって制約される。ＣＤＭは、異なるタイプにわたって様々な制約を指定することができる。

単純タイプ制約。単純タイプに許可される値のセットは、長さ（文字列および２進数）、精度、スケール（１０進数）などを制約するなど、様々な方法で制約することができる。デフォルト制約は、デフォルト値を指定することができる。チェック制約は、プロパティの値を介して論理式を指定することができる。この式がｆａｌｓｅと評価された場合、プロパティ値は無効である。

コレクションタイプ制約。コレクションに関して以下の制約がサポートされる。ＥｌｅｍｅｎｔＯｃｃｕｒｓ制約は、コレクションの最高および最低濃度を指定する。Ｕｎｉｑｕｅ制約を使用して、コレクション要素値の一意性を保証することができる。ＥｌｅｍｅｎｔＣｏｎｓｔｒａｉｎｔを使用して、コレクションの基礎となるタイプに関する制約を指定することができる（例えば、Ｄｅｃｉｍａｌタイプのコレクションを定義すると、この＜ＥｌｅｍｅｎｔＣｏｎｓｔｒａｉｎｔ＞を使用して精度およびスケールを指定することができる）。

チェック制約はブール照会式を指定する。コレクションが有効とみなされるために、この式はｔｒｕｅと評価されるべきである。この制約は、コレクション内の個々の要素ではなく、全体としてのコレクションプロパティに適用されることに留意されたい。

タイプ設計者は、特にコレクションが多数の要素を含むと予測される場合、Ｃｏｌｌｅｃｔｉｏｎｓに関して常に一意の制約を定義することが推奨される。ランタイム時に、コレクションのうちの１つの要素が更新された場合、この一意性の制約により、インプリメンテーションはコレクション全体を書き換える代わりに、その単一の要素を更新のターゲットとすることができる。これにより、更新時間およびネットワークトラフィックが削減される。

派生タイプ制約。派生タイプ制約を使用して、派生タイプ内の基本タイププロパティを制約することができる。様々な航空会社から提供されるマイレージ・サービスについて考えてみる。例えば、ユナイテッド航空はマイレージプラスと呼ばれるプログラムを有する。このプログラムには１Ｋメンバ、プレミアエグゼクティブメンバ、プレミアメンバ、および「単なる（ｊｕｓｔ）」メンバという、いくつかのメンバシップレベルがある。プレミアメンバになるためには、少なくとも２５０００マイルまたは３０支払い区間を飛ばなくてはならず、プレミアエグゼクティブおよび１Ｋになるためには、それぞれ５００００／６０および１０００００／１００が必要である。派生タイプ制約を定義する場合、制約は基本タイプ制約に適合しなければならないことに留意されたい。例えば、基本タイプのコレクションフィールドに対するＥｌｅｍｅｎｔＯｃｃｕｒｓ制約が、最低１および最高５０を指定した場合、派生タイプの制約は最低が１より大きく、最高が５０未満でなければならない。

ｎｕｌｌ可能性制約。単純タイプおよび複合タイプはｎｕｌｌ可能性制約を指定することができる。これは、このタイプのインスタンスがＮＵＬＬ値を格納できることを意味する。これは、＜Ｐｒｏｐｅｒｔｙ＞要素のＮｕｌｌ可能属性によって指定される。

コレクションプロパティはＮｕｌｌ可能に設定すべきではなく、Ｎｕｌｌ可能は複合タイププロパティにも可能であることに留意されたい。Ｎｕｌｌ可能属性のデフォルト値は「ｔｒｕｅ」である。

これまで、この代替インプリメンテーションのＣＤＭタイプシステムによって提供されるコアモデリング機能について説明してきた。ＣＤＭは、複合タイプを定義し、列挙を作成し、制約、継承、および値の置換可能性（多相性）を表す機能の、組み込みタイプのリッチセットである。

システム内でこれらのタイプが設計および配置されると、アプリケーションはこれらのタイプのインスタンスの作成および操作を開始する。コピー、移動、照会、削除、バックアップ／復元（持続データの場合）などの様々な操作が、タイプインスタンスで実行される。次に、ＣＤＭの操作セマンティクスについて説明する。

タイプおよびインスタンス。タイプはデータの構造を定義する。実際のデータはタイプインスタンスに格納される。例えばオブジェクト指向言語では、タイプおよびインスタンスはクラスおよびオブジェクトと呼ばれる。

図２２は、このＣＤＭのインプリメンテーションにおけるタイプおよびインスタンスの概念を示す図である。図２２内の楕円形は実際のデータであり、立方体はタイプ、すなわちメタデータである。

エンティティおよびインラインタイプ。ここで再度、仮想上のＬＯＢアプリケーションによって使用されるデータに注目すると、一方ではＣｕｓｔｏｍｅｒｓおよびＯｒｄｅｒｓなどのタイプを有し、他方ではＡｄｄｒｅｓｓおよびＡｄｄｒｅｓＬｉｎｅなどのタイプも有する。これらそれぞれのタイプは、それぞれが複数のフィールドに分解可能な構造を有する。しかしながら、ＣｕｓｔｏｍｅｒタイプとＡｄｄｒｅｓｓタイプとの間には２つの主要な相違点がある。Ｃｕｓｔｏｍｅｒタイプのインスタンスは独立した存在を有するが、Ａｄｄｒｅｓｓのインスタンスは（例えば）Ｃｕｓｔｏｍｅｒタイプインスタンス内にのみ存在する。

この意味で、Ｃｕｓｔｏｍｅｒはトップレベルタイプであり、単独で存在するこのタイプのインスタンスは独立して参照され（「ＣｏｍｐａｎｙＮａｍｅが．．．のＣｕｓｔｏｍｅｒを表示」）、独立して処理される。他方でＡｄｄｒｅｓｓは収容されたタイプであり、そのインスタンスは、例えば「ＣｕｓｔｏｍｅｒのＡｄｄｒｅｓｓ」または「Ｏｒｄｅｒの出荷先Ａｄｄｒｅｓｓ」などのように、トップレベルタイプインスタンスとの関連においてのみ存在する。

Ｃｕｓｔｏｍｅｒタイプにはアイデンティティがあるが、Ａｄｄｒｅｓｓタイプにはない。Ｃｕｓｔｏｍｅｒのあらゆるインスタンスは一意に識別され、これへの参照が実行できる。Ａｄｄｒｅｓｓタイプは、Ｃｕｓｔｏｍｅｒなどのタイプ外で別々に識別することができない。この基本的な区別は、ＣＤＭではＥｎｔｉｔｙタイプおよびＩｎｌｉｎｅタイプの概念によって形式化される。前述のＬＯＢ例では、ＣｕｓｔｏｍｅｒはＥｎｔｉｔｙタイプであり、ＡｄｄｒｅｓｓはＩｎｌｉｎｅタイプである。

エンティティの特徴。エンティティタイプは構造上は複合タイプと同様であるが、これにはインラインタイプと区別するいくつかの特徴がある。これらの特徴はエンティティインスタンスに特別な操作セマンティクスを与える。エンティティとは、エンティティタイプのインスタンスのことである。エンティティは、独立して存在できるＣＤＭデータの最小単位である。これは、以下の特徴を示す。

アイデンティティ：あらゆるエンティティはアイデンティティを有する。このアイデンティティは、その存続期間中にエンティティおよびそのエンティティのみを参照するように保証される。アイデンティティの存在は、そのエンティティへの参照が利用可能であることを示唆する。

エンティティアイデンティティは、なぜエンティティが「トップレベル」データ単位であるか、すなわち、あらゆるエンティティが参照可能であり、したがって照会、更新、および他の操作で使用可能であるかの理由である。

整合性の単位：照会および更新は、エンティティレベルでの整合性が保証される。エンティティはコピー、移動、削除、バックアップ、復元などの、ほとんどのＣＤＰ操作のターゲットである。これらの操作はインラインタイプをターゲットにしない。

トランザクションの単位：トランザクションはエンティティレベルで発生する。言い換えれば、エンティティは別々に処理されるが、インラインタイプは常に収容エンティティとの関連において処理される。

リレーションシップに関する単位：リレーションシップは、インラインタイプではなくエンティティのレベルで指定される。エンティティは構成および参照アソシエーションを介して互いに関係することが可能であり、インラインタイプインスタンスはリレーションシップのソースまたはターゲットになることはできない。

持続性の単位：エンティティは持続性の単位である。インラインタイプはそれ自体は持続せず、エンティティの一部としてのみ持続する。本来、インラインタイプは値によって動作するため、エンティティの一部として格納しなければならない。

しかしながら、ＣＤＭそれ自体は、エンティティを持続させることを暗示せず、またこれを必要ともしないことに留意されたい。ＣＤＭは、エンティティがメモリ内にあるかまたは持続するかにかかわらず、整合性を維持する。

共有の単位：エンティティはデータモデル内での共有の単位である。例えば、ＬＯＢアプリケーションはＰｒｏｄｕｃｔの概念を有する。Ｓｕｐｐｌｉｅｒは１つまたは複数の製品を供給し、Ｏｒｄｅｒは１つまたは複数の製品を有する。製品情報の冗長なストレージを避けるために、Ｐｒｏｄｕｃｔエンティティを定義することが可能であり、このエンティティのインスタンスへの参照をＯｒｄｅｒおよびＳｕｐｐｌｉｅｒエンティティ内に挿入することができる。他方で、Ｐｒｏｄｕｃｔがインラインタイプである場合、ＯｒｄｅｒおよびＳｕｐｐｌｉｅｒの両方がＰｒｏｄｕｃｔインスタンスを含まなければならず、これが、冗長なストレージならびにその結果生じる異常の挿入、削除、および更新につながる。

図２３は、エンティティおよびインラインタイプがＳＤＬを使用して宣言される方法を示す図である。エンティティは、１４〜２７行目に示されるように＜ＥｎｔｉｔｙＴｙｐｅ＞要素を使用して宣言される。エンティティタイプのプロパティは、インラインタイプ（定義による）である。何種類かのインラインタイプがある。スカラタイプ：スカラタイプはさらに単純、参照、および列挙タイプに細分できることを想起されたい。単純インラインタイプはＣＤＭフレームワークに組み込まれており、ある意味ですでに宣言され、使用可能である。図２３の例では、こうしたタイプの使用が８、９、１０、１１、１２、１５、および１８行目に示されている。

列挙タイプは、１〜５行目に示されるように＜ＥｎｕｍｅｒａｔｉｏｎＴｙｐｅ＞要素を使用して宣言される。いったん宣言されると、これらのタイプを任意の複合またはエンティティタイプ内で使用することができる（８行目を参照）。

ＸＭＬおよびＦＩＬＥＳＴＲＥＡＭタイプ（この例では図示せず）は組み込みタイプであるが、正確にはスカラではない（すなわちデータモデルは、これらのタイプの内部が範囲限定であると推論することができる）。

複合タイプは、７〜１３行目に示されるように＜ＣｏｍｐｌｅｘＴｙｐｅ＞要素を使用して宣言される。複合タイプのプロパティは、任意のインラインタイプ、すなわちスカラ、コレクション、または複合タイプとすることが可能である。いったん宣言されると、複合タイプを任意の複合またはエンティティタイプ内で使用することができる。

コレクションタイプは、コレクションキーワードおよびこれに続くインラインタイプの名前を使用して宣言される。ＡｄｄｒｅｓｓＴｙｐｅのコレクションが２２行目に示される。

前述のように、エンティティの基本的な特徴は、一意のアイデンティティを有するという事実である。エンティティアイデンティティは、エンティティを更新しても存続を続け、その存続時間全体にわたって同じエンティティを識別し続けることが保証される。エンティティは、キー属性も有する。このキーは、１つまたは複数のプロパティで構成される。エンティティキーは、ＥｎｔｉｔｙＳｅｔ内で一意であることが必要である。インプリメンテーションはエンティティキーを使用して、エンティティアイデンティティを生成することができる。エンティティキーは、＜ＥｎｔｉｔｙＴｙｐｅ＞要素の「Ｋｅｙ」属性を使用して指定される。スカラ（参照タイプを含む）または複合タイププロパティの任意のセットは、キー内の少なくとも１つのプロパティがｎｕｌｌ不可である限り、エンティティタイプへのキーとして働くことができる。コレクションタイププロパティは、キーの一部であってはならない。

エンティティタイプ階層の基本タイプのみがキーを指定できることに留意されたい。派生タイプは、基本タイプから自動的にキーを継承する。これにより、値の置換可能性（多相性）を決定論的に動作させることがサポートされる。

エンティティ参照。エンティティはアイデンティティを有するため、エンティティ参照を有することが可能である。ＣＤＭのこのインプリメンテーションでは、エンティティ参照は主にリレーションシップナビゲーションに使用される。例えばＣｕｓｔｏｍｅｒエンティティは、Ｃｕｓｔｏｍｅｒ＿Ｏｒｄｅｒリレーションシップを介してＯｒｄｅｒエンティティに関係付けられる。Ｏｒｄｅｒが与えられると、Ｏｒｄｅｒエンティティ上の特別なプロパティ（リレーションシッププロパティとして知られる）を使用して関連付けられたＣｕｓｔｏｍｅｒを見つけることができる。このプロパティはＲｅｆ（Ｃｕｓｔｏｍｅｒ）タイプである。キーワードＲｅｆは、これが他のエンティティタイプへの参照であることを示す。

エンティティタイプまたは複合タイプ内にＲｅｆタイププロパティを明示的に定義することもできる。このプロパティは、参照されるエンティティへの「ポインタ」として働く。Ｒｅｆタイププロパティの存在は、収容するエンティティタイプと参照されるエンティティタイプとの間のリレーションシップを定義または暗示しない。リレーションシップは明示的に定義されなければならない。持続エンティティの場合、参照は永続的である。

インラインタイプ。エンティティは、単独でトップレベルに存続するか、またはエンティティセット内に含まれる。エンティティを、他のエンティティまたは複合タイプ内に直接埋め込むことはできない。他方で複合タイプは、他の複合タイプまたはエンティティタイプ内に埋め込むことができる。すなわち、エンティティおよび複合タイプのどちらも、タイプが複合タイプのプロパティを有することができる。

スカラタイプおよびコレクションも、他の複合タイプまたはエンティティタイプ内に埋め込むことができる。これが、複合タイプ、コレクション、およびスカラタイプがまとめてインラインタイプとして参照される理由である。

エンティティセットおよびエンティティ制約。エンティティインスタンスがどこに存在するかを記述するのに役立つシナリオが２つ提供されている。エンティティインスタンスは、何らかのデータストア内で持続する。ＣＤＭそれ自体は、ストアにとらわれないように注意深く作成されている。理論的には、様々なストレージ技術を介してインプリメントすることができる。エンティティはメモリ内にも一時的に存在する。ＣＤＭは、メモリ内で具体化される方法、およびアプリケーションに対して使用可能とされる方法は指定しない。アプリケーションは、通常、様々なタイプのエンティティの複数のインスタンスを処理する。これらのインスタンスは単独でトップレベルに存在するか、またはエンティティセット内に含まれることが可能である。エンティティセットは、所与のタイプ（またはそのサブタイプ）のエンティティのインスタンスを含む。エンティティキーは、エンティティセット内で有意である。エンティティセット内の各エンティティは、一意のキーを有するはずである。

エンティティコンテナは、１つまたは複数のエンティティセットのグループである。エンティティコンテナは、アソシエーションおよび構成のリレーションシップをスコーピングするために使用される。エンティティコンテナは、それを介してバックアップ、復元、ユーザ、ロール、および他のそうしたセマンティクスが定義される、持続性および管理単位でもある。

スキーマは、タイプ、リレーションシップ、および他の名前を保持するための組織構造である。これは、その中で通常の名前の一意性規則が適用される、ネームスペースを提供する。スキーマは＜Ｓｃｈｅｍａ＞要素を使用して定義され、ＳＤＬファイルのトップレベル要素である。すべてのエンティティ、リレーションシップ、複合タイプなどは、スキーマ内で定義される。どこで定義されたスキーマも、＜Ｕｓｉｎｇ＞要素でインポート可能であり、そこで定義されたタイプは、それらの完全修飾名を使用して参照することができる。また、完全修飾構文Ｎａｍｅｓｐａｃｅ．Ｔｙｐｅ−ｎａｍｅを使用して、他のスキーマ内で直接（例えば＜Ｕｓｉｎｇ＞要素を持たずに）タイプを使用することも可能である。任意の配置されたスキーマ内に定義されたタイプは、そのタイプの完全修飾名を提供することによって使用できる。

ＣＤＭ指定は、ＳＤＬ内にタイプが書き込まれると何が生じるべきかに関して明言しない。ＳＤＬに書き込まれるタイプに関して、ＣＤＭをインプリメントするＣＤＰは、ＳＤＬ記述を入手してこれらのタイプをストア上に配置するツールを提供する。ストアの性質に応じて、この配置はストアレベル抽象化の作成を含むことができる。例えば、ストアがＲＤＢＭＳの場合、配置はスキーマおよびタイプに対応するデータベースおよびテーブルを作成することになり、制約およびデータモデル強制のためのＳＱＬコードも作成する可能性がある。別の方法として、データベースのテーブルをＣＤＭタイプにマッピングすることによって、既存のテータベースでＣＤＰを使用することもできる。

ストアレベルアイテムの作成に加えて、ＣＤＰツールは、タイプおよびリレーションシップに対応するＣＬＲクラスも生成することになる。このインプリメンテーションは、＜Ｓｃｈｅｍａ＞要素のＮａｍｅｓｐａｃｅ属性を使用して、これらのクラスをスコーピングするためのＣＬＲネームスペースを作成することができる。ＣＤＰは、ＣＤＭタイプへの既存のオブジェクトモデルのマッピングもサポートする。ＣＤＭタイプはストアを必要としないことに留意されたい。メモリ内配置が可能である。

実世界データの任意の有意セットは、その構成要素部分間に常にリレーションシップを有する。例えば、＊＊顧客＊＊は１つまたは複数の＊＊注文＊＊を発注し、＊＊注文＊＊は＊＊注文明細＊＊を含み、＊＊製品＊＊は１つまたは複数の＊＊供給業者＊＊から入手可能である（

）、などという具合である。この文章では、データは＊＊で囲み（英文ではイタリック）、それらの間のリレーションシップは下線を施してある。明らかに、リレーションシップの概念はいずれのデータモデル化の努力にも不可欠である。リレーショナルモデルはリレーションシップを明示的にサポートせず、基本キー、外部キー、および参照保全性は、リレーションシップによって暗示される制約のうちのいくつかをインプリメントするためのツールを提供する。ＣＤＭのキー値は、データモデル自体の中の最高クラス概念としてのリレーションシップのそのサポートである。これにより、より単純かつリッチなモデル化機能が可能になる。リレーションシップサポートは、ＣＤＭ照会にも延在し、これによって照会内でリレーションシップを明示的に参照することが可能であり、リレーションシップに基づいてナビゲートする機能が提供される。

図２４は、ＣＤＭによってサポートされる多くの種類のリレーションシップを示す図である。実世界モデル化シナリオでは、異なる次数（単項（ｕｎａｒｙ）、２項（ｂｉｎａｒｙ）．．．）、多重度（１対１、１対多数、多数対多数．．．）、およびセマンティクス（包含（ｃｏｎｔａｉｎｍｅｎｔ）、ピアツーピア．．．）を有する、多くの異なる種類のリレーションシップが存在する。ＣＤＭは、これら異なるタイプのリレーションシップすべてをモデル化する機能を有する。ＣＤＭでは、リレーションシップはエンティティレベルで定義される。エンティティを関係付けるには、アソシエーションおよび構成の２つの方法がある。アソシエーションは「ピアツーピア」リレーションシップをモデル化し、構成は「親子」リレーションシップをモデル化する。

モデル化セマンティクスは、様々な操作に対して単位として動作する関係エンティティを要求することができる。例えば、図２４のＯｒｄｅｒとＯｒｄｅｒＬｉｎｅとの間のＣｏｎｔａｉｎｓリレーションシップについて考えてみる。Ｏｒｄｅｒでのコピーまたは直列化操作が、結果として関連付けられたＯｒｄｅｒＬｉｎｅｓのコピーまたは直列化も発生させることになると予想するのは妥当である。ＣＤＭは、削除、コピー、直列化、機密保護（ｓｅｃｕｒｅ）、およびロックの、少なくとも５つの操作を定義する。これらの操作に応答して、関係エンティティ上で動作を指定することができる。アソシエーションおよび構成の参照に加えて、エンティティを関係付ける他の方法には、条件付アソシエーションおよびアソシエーションエンティティの２つが存在する可能性があることに留意されたい。

アソシエーションは、データモデル化における最も一般的で有用なリレーションシップの１つである。アソシエーションの古典的な例は、ＣｕｓｔｏｍｅｒエンティティとＯｒｄｅｒエンティティとの間のリレーションシップである。通常、このリレーションシップには、各Ｏｒｄｅｒが厳密に１つのＣｕｓｔｏｍｅｒに関連付けられる多重度が含まれる。あらゆるＣｕｓｔｏｍｅｒは、ゼロまたはそれ以上のＯｒｄｅｒｓを有する。このリレーションシップは操作の動作も含むことが可能であり、あたかも単位であるかのように関係エンティティ上で動作するために有用である。例えば、顕著なＯｒｄｅｒｓを有するＣｕｓｔｏｍｅｒが削除、コピー、または直列化された場合、対応するＯｒｄｅｒｓにとっても、削除、コピー、または直列化されることが望ましい。＜Ａｓｓｏｃｉａｔｉｏｎ＞要素は、このリレーションシップをモデル化するために使用される。

＜Ｅｎｄ＞上の「Ｔｙｐｅ」属性は、リレーションシップに関与するエンティティタイプを定義する。

「Ｍｕｌｔｉｐｌｉｃｉｔｙ」属性は、エンドの濃度を定義する。この例では、ゼロまたはそれ以上の注文（値は１４行目の「^＊」）に対して厳密に１人のＣｕｓｔｏｍｅｒ（値は１５行目の「１」）が存在することが指定される。この属性の他の値は以下のとおりである。
・「０．．１」−−ゼロまたは１
・「１」 −−厳密に１
・「^＊」 −−ゼロまたはそれ以上
・「１．．^＊」−−１つまたは複数
・「ｎ」 −−厳密にｎ
・「ｎ．．ｍ」−−ｎからｍの間（ｎおよびｍを含む）、ｎはｍより少ないかまたは等しい

１６行目の＜ＯｎＤｅｌｅｔｅ＞要素は、削除操作の操作動作を指定する。１つの属性「Ａｃｔｉｏｎ」を有し、これは３つの値のうちの１つを有することができる。Ｃａｓｃａｄｅ−−Ｃｕｓｔｏｍｅｒに属するすべてのＯｒｄｅｒを削除する。これは上記の例に示されている。Ｒｅｓｔｒｉｃｔ−−顕著なＯｒｄｅｒｓが存在する場合にＣｕｓｔｏｍｅｒの削除を防止する。ＲｅｍｏｖｅＡｓｓｏｃｉａｔｉｏｎ−−ＯｒｄｅｒｓとＣｕｓｔｏｍｅｒとの間のリレーションシップを除去する。整合性のあるセマンティクスを有するために、＜ＯｎＤｅｌｅｔｅ＞要素はリレーションシップの一方のエンドにのみ可能であることに留意されたい。

ＣＤＭは、コピー、直列化、機密保護、およびロックの他の操作の動作も指定することができる。これらはすべて、形式＜ＯｎＯｐｅｒａｔｉｏｎＡｃｔｉｏｎ＝“．．．”＞のサブエレメントを使用することによって、削除動作について示したのと同じパターンに従う。操作動作の指定は、アソシエーションと構成の両方で実行可能である。

アソシエーションモデルのピアツーピアリレーションシップ。構成は、厳密な包含（親子）リレーションシップをモデル化する。構成の従来の例は、Ｏｒｄｅｒとそれに対応するＬｉｎｅアイテムとの間のリレーションシップである。注文ラインは、その親注文によって完全に制御される。意味論的には、収容する注文の外部には有意な存在はない。注文を削除すると、強制的にすべての注文ラインが削除される。したがって、ＯｒｄｅｒおよびＬｉｎｅエンティティは、構成を介して関係付けられていると呼ばれる（すなわち、Ｏｒｄｅｒは１つまたは複数のＬｉｎｅエンティティで構成される）。

構成リレーションシップは、以下の３つの特徴を有する。
一意性：所与の親の子は、それらの間に一意のキーを有しているはずである。例えば、Ｏｒｄｅｒに属しているＬｉｎｅは、これを同じＯｒｄｅｒに関する他のすべてのＬｉｎｅと区別するために一意のキーを有しているはずである。これをインプリメントする一般的な方法は、子のキーと親のキーとを組み合わせることによって、子のアイデンティティを派生させることである。
カスケード削除：親を削除すると、子が削除される。
多重度：親の多重度は１である。これは、ＯｒｄｅｒなしではＬｉｎｅが存在できないという意味論を表す。
＜Ｃｏｍｐｏｓｉｔｉｏｎ＞要素は、構成をモデル化するために使用される。

１つの構成につき親は常に１つであるため、親の「多重度」は指定する必要がないことに留意されたい。事実、構成の親に１以外の「多重度」を指定することは誤りである。多重度は子エンドに指定可能であり、以下の値のいずれかを有することができる。

操作動作は、構成上でコピー、直列化、機密保護、およびロック操作について指定可能である。構成は常にカスケード削除セマンティクスを有するので、＜ＯｎＤｅｌｅｔｅ＞を指定する必要がないことに留意されたい。ｘが「Ｃａｓｃａｄｅ」に等しい＜ＯｎＤｅｌｅｔｅＡｃｔｉｏｎ＝“ｘ”＞を指定すること、および子エンドで＜ＯｎＤｅｌｅｔｅ＞を指定することは誤りである。

あたかも１つの単位であるかのように関係するエンティティ上での操作は、しばしば有用である。例えば、Ｏｒｄｅｒエンティティをコピーする場合、通常、対応するＬｉｎｅエンティティも同様にコピーされることが望ましい。ＣＤＭは、これらの動作を、削除、コピー、直列化、機密保護、およびロックという様々な操作に指定することができる。使用される一般的なパターンは、＜ＯｎＯｐｅｒａｔｉｏｎＡｃｔｉｏｎ＝“ｖａｌｕｅ」／＞の形のサブエレメントを定義することである。Ｏｐｅｒａｔｉｏｎは、Ｄｅｌｅｔｅ、Ｃｏｐｙ、Ｓｅｒｉａｌｉｚｅ、Ｓｅｃｕｒｅ、またはＬｏｃｋのうちの１つとすることができる。Ｏｐｅｒａｔｉｏｎに応じて、「Ａｃｔｉｏｎ」の値はＣａｓｃａｄｅ、Ｒｅｓｔｒｉｃｔ、ＲｅｍｏｖｅＡｓｓｏｃｉａｔｉｏｎなどとすることができる。

操作セマンティクスを指定する場合、以下の点に留意されたい。すべての＜ＯｎＯｐｅｒａｔｉｏｎ．．．／＞要素はリレーションシップエンドの１つだけに指定するものとする。（例えば）Ｃｕｓｔｏｍｅｒに＜ＯｎＤｅｌｅｔｅ＞を指定し、Ｏｒｄｅｒに＜ＯｎＣｏｐｙ＞を指定することは、正しくない可能性がある。ここでの概念上のモデルは、リレーションシップのエンドの１つが制御の役割を果たし、操作セマンティクスはそのエンティティから他のすべてのエンドへとカスケードする、というものである。構成に＜ＯｎＤｅｌｅｔｅ．．．／＞を指定する必要はない。定義により、構成の親を削除すると、その操作は子までカスケードする。すべての＜ＯｎＯｐｅｒａｔｉｏｎ．．．／＞要素は、構成の親に指定されるものとする。Ａｃｔｉｏｎ＝「Ｃａｓｃａｄｅ」で＜ＯｎＤｅｌｅｔｅ＞または＜ＯｎＳｅｕｒｅ＞を指定するエンドは、多重度「１」を有するものとする。そうでない場合、セマンティクスは不整合になる。

ＣＤＭ内のリレーションシップは、それに関与しているタイプ以外で定義される。タイプ自体はリレーションシップを確立するために特別なプロパティを有する必要がない。例えば、Ｏｒｄｅｒ＿Ｃｕｓｔｏｍｅｒリレーションシップはトップレベル＜Ａｓｓｏｃｉａｔｉｏｎ＞要素を使用して指定可能であり、ＣｕｓｔｏｍｅｒおよびＯｒｄｅｒタイプは、それらの中に互いにリレーションシップに関与していることを示すためのプロパティまたは他の識別マークを持たない。

照会またはＡＰＩで、リレーションシップの一方のエンドから他方へとナビゲートするための様々なメカニズムが想定可能である。例えば、ＣＤＰＡＰＩは各リレーションシップに静的クラスを有し、このクラスがナビゲーションに使用できるメソッドを有する。Ｏｒｄｅｒ＿Ｃｕｓｔｏｍｅｒの例を利用すると、クラスにはＯｒｄｅｒ＿Ｃｕｓｔｏｍｅｒと命名し、メソッドはＧｅｔＯｒｄｅｒｓＧｉｖｅｎＣｕｓｔｏｍｅｒ（．．．）などとなる。

しかしながら最も直感的な方法は、リレーションシップのいずれかのエンドに実際にプロパティを有することである。例えば、ＯｒｄｅｒがＣｕｓｔｏｍｅｒと呼ばれるプロパティを有する場合、ナビゲーションはプロパティにアクセスするのと同様に単純になる。リレーションシップナビゲーションに関するこの単純なパターンを実行可能にするために、ＣＤＭはリレーションシッププロパティの概念を有する。関係エンティティにナビゲーションの目的を示すために、これらをエンティティ上に定義することができる。リレーションシッププロパティは、＜ＲｅｌａｔｉｏｎｓｈｉｐＰｒｏｐｅｒｔｙ＞要素を使用して定義される。＜ＲｅｌａｔｉｏｎｓｈｉｐＰｒｏｐｅｒｔｙ＞要素は、３つの属性を有する。「Ｎａｍｅ」はプロパティの名前を定義する。この名前を照会またはＡＰＩで使用して、リレーションシップの他方のエンドへナビゲートすることができる。「Ｒｅｌａｔｉｏｎｓｈｉｐ」は、アソシエーションまたは構成の名前を指定する。「Ｅｎｄ」はナビゲーションターゲットを識別する。リレーションシッププロパティはアソシエーションと構成の両方のリレーションシップに対して定義可能であり、リレーションシップのいずれかのエンドで定義可能である。

「通常の」プロパティとは異なり、リレーションシッププロパティは「Ｔｙｐｅ」属性を持たないことに留意されたい。これは、それらが暗黙的にＥｎｔｉｔｙＲｅｆ（またはＥｎｔｉｔｙＲｅｆのコレクション）にタイプ付けされるからである。このエンティティ参照は、ターゲットエンティティへのナビゲーションに使用される。

リレーションシッププロパティは、ターゲットとするエンドの多重度に応じて、単一のＥｎｔｉｔｙＲｅｆまたはＥｎｔｉｔｙＲｅｆのコレクションのいずれかである。以下の表は、「多重度」に可能な値と、対応するリレーションシッププロパティのタイプを示す。

前述のように、エンティティはトップレベルに「単独」で存在するか、またはエンティティセット内に常駐する（それ自体がエンティティコンテナ内にある）ことができる。リレーションシップの２つのエンドとの関連における状況を考えてみる。「浮動性（ｆｒｅｅｆｌｏａｔｉｎｇ）」エンティティの場合、リレーションシップの両方のエンドはエンティティの海のどこかに存在する。エンティティが複数のエンティティセットにグループ化される場合を考えてみる。例えば、以下のスキーマフラグメントについて考える。

エンティティコンテナ（ＬＯＢＤａｔａ）は、Ｏｒｄｅｒｓ、ＧｏｏｄＣｕｓｔｏｍｅｒｓ、およびＢａｄＣｕｓｔｏｍｅｒｓの３つのエンティティセットを有する。ＧｏｏｄＣｕｓｔｏｍｅｒｓ内のすべてのＣｕｓｔｏｍｅｒエンティティはかなり立派な信用度を有するため、発注するに値するとみなされる。ＢａｄＣｕｓｔｏｍｅｒｓは、その支払いを怠っている。ここでの明白なビジネス規則は、ＧｏｏｄＣｕｓｔｏｍｅｒｓのみにＯｒｄｅｒの発注を希望することである。言い換えれば、ＧｏｏｄＣｕｓｔｏｍｅｒｓ内のエンティティのみがＯｒｄｅｒｓを有するように、Ｃｕｓｔｏｍｅｒ＿Ｏｒｄｅｒリレーションシップの範囲を制約する。さらに、すべてのＯｒｄｅｒｓはＯｒｄｅｒｓエンティティセット内に常駐していなければならない。これは、以下に示されるように、＜ＥｎｔｉｔｙＣｏｎｔａｉｎｅｒＴｙｐｅ＞内で＜Ｓｃｏｐｅ＞要素を使用することによって実行される。

＜Ｓｃｏｐｅ＞（５行目）要素は１つの属性「Ｒｅｌａｔｉｏｎｓｈｉｐ」を有し、これは、エンドがスコーピングされているアソシエーションまたは構成を識別する。リレーションシップの各エンドにつき１つの＜Ｅｎｄ＞サブエレメントは、このエンドのスコーピング先のエンティティセットを指定するために使用される。６行目では、ＣｕｓｔｏｍｅｒエンドがＧｏｏｄＣｕｓｔｏｍｅｒｓエンティティセットにスコーピングされることがわかり、７行目では、ＯｒｄｅｒエンドがＯｒｄｅｒｓエンティティセットにスコーピングされることがわかる。

配置されたスキーマがエンティティコンテナを有する場合、各リレーションシップの各エンドは、エンティティコンテナ内の１つだけのエンティティセットにスコーピングされる。所与のアソシエーションまたは構成に対して明示的な＜Ｓｃｏｐｅ＞節がない場合、インプリメンテーションはエンドをデフォルトのエンティティセットにスコーピングする。暗黙のスコーピングが実行される方法は、インプリメンテーション定義済みである。

ＣＤＭは、構成についてのより厳密なスコーピング規則を指定することができる。ＯｒｄｅｒとＬｉｎｅとの間の構成を考えてみる。対応するＯｒｄｅｒなしにＬｉｎｅが存在しても意味を成さない。したがって、Ｌｉｎｅエンティティを含むエンティティセットは、あらゆるＬｉｎｅが１つだけのＯｒｄｅｒの子であるものとするビジネス規則を強制すべきである。これは、＜Ｒｅｑｕｉｒｅｓ＞要素を使用して実行される。

以下のスコーピング要件は、前述の例によって満たされる。Ｓｈｉｐｍｅｎｔ＿ＬｉｎｅのＬｉｎｅエンドは、ＳｈｉｐｍｅｎｔＬｉｎｅｓエンティティセット（１６行目）へとスコーピングされるものとする。ＳｈｉｐｍｅｎｔＬｉｎｅｓ内のあらゆるＬｉｎｅはＳｈｉｐｍｅｎｔ＿Ｌｉｎｅ構成のエンドでなければならない。これは、＜Ｒｅｑｕｉｒｅｓ＞要素を使用して７行目で実行される。この要素は１つの属性「Ｒｅｌａｔｉｏｎｓｈｉｐ」を有し、これが構成を識別する。Ｏｒｄｅｒ＿ＬｉｎｅのＬｉｎｅエンドはＯｒｄｅｒＬｉｎｅｓエンティティセット（１２行目）へとスコーピングされるものとする。ＯｒｄｅｒＬｉｎｅｓ内のあらゆるＬｉｎｅは、Ｏｒｄｅｒ＿Ｌｉｎｅ構成のエンドであるものとする（４行目）。エンティティセット内に＜Ｒｅｑｕｉｒｅｓ＞要素がない場合、任意の所与の構成に属するエンティティを有するように制約されない。これは、多くのモデル化シナリオにおいて重要な要件である可能性がある。＜Ｒｅｑｕｉｒｅｓ＞要素を使用して、１つだけの構成名を指定できることに留意されたい。

これまでのＣＤＭの代替の説明は、厳密にエンティティがどこに常駐するかにはとらわれないものであった。エンティティはメモリ内に常駐するか、または実際にストア内に永続的に存続することが可能である。コアＣＤＭは、エンティティがどこに常駐するかについて暗示、要求、または留意することがなく、エンティティはメモリ内に常駐するかまたは持続することが可能である。次に、持続性エンティティについて、および持続性の概念をＣＤＭがどのようにサポートするかについて説明する。

エンティティコンテナは、エンティティ用のトップレベルの組織単位であり、持続性セマンティクスが定義されるレベルである。エンティティとは、持続可能なデータの最小単位である。典型的には、持続エンティティは、コピー、移動、バックアップ、復元、直列化などのそれらに関する操作セマンティクスを有する。エンティティコンテナは、これらのセマンティクスが定義できる持続性の単位である。これは、バックアップ、復元、ユーザ、ロールなどの管理概念が定義される組織単位でもある。この意味で、エンティティコンテナはＳＱＬデータベースに類似している。

エンティティコンテナは、すべてのエンティティがその中に常駐する１つまたは複数のエンティティセットを有する。したがって、エンティティコンテナのインスタンスを定義することで、ストレージ割り振りプロセスが活性化（ｊｕｍｐ−ｓｔａｒｔ）される。通常、タイプ設計者はエンティティコンテナタイプを定義する。ＣＤＭそれ自体は、エンティティコンテナインスタンスがタイプからどのように取得されるか、および、このインスタンスが基礎となるストレージ構造にどのようにマッピングされるか（ＥｎｔｉｔｙＣｏｎｔａｉｎｅｒ−＞Ｄａｔａｂａｓｅ、Ｅｎｔｉｔｙｓｅｔ−＞ｔａｂｌｅ（ｓ）など）を定義しない。ＣＤＰは、エンティティコンテナ（とそれに含まれるタイプ）の間でのＳＱＬストレージへの規範的マッピングのセットを定義する。ＣＤＰは、同様に非規範的（ユーザ指定可能）マッピングも可能である。

一般にアプリケーションは、選択した任意の方法でエンティティを自由に編成し、ＣＤＭはいかなる特定の組織構造も指示しない。しかしながら、持続エンティティについて言えば、エンティティ、エンティティセット、およびＥｎｔｉｔｙＣｏｎｔａｉｎｅｒのセマンティクスはある種の構造組織を暗に示す。エンティティが持続する場合、あらゆるエンティティはエンティティセット内で存続するはずであり、あらゆるエンティティセットはＥｎｔｉｔｙＣｏｎｔａｉｎｅｒ内で存続するはずであり、ＥｎｔｉｔｙＣｏｎｔａｉｎｅｒはトップレベルで存続するはずである。

図２５は、ＣＤＭにおける持続エンティティに関する構造組織を示す図である。これは物理的なものでなく、データの論理的表現である。図示された各エンティティセットは、例えばテーブルにマッピングすることができる。このテーブルは、ほぼ間違いなくリレーションシップを表すための追加の列を有することになる。Ｏｒｄｅｒｓエンティティセットが、ＣｕｓｔｏｍｅｒＩＤ列を有するＯｒｄｅｒｓテーブルにマッピングされると想定することができる。ＣＤＭはストレージマッピングを規定しないため、記述は論理レベルで維持されてきた。あらゆるエンティティはエンティティセット内に常駐することがわかる。さらに、あらゆるエンティティセットがＥｎｔｉｔｙＣｏｎｔａｉｎｅｒ内に含まれる（インスタンスビュー内のＭｙＬｏｂＤＢ）。構造組織のこの説明を完結させるために、ＣＤＭストアが１つまたは複数のＥｎｔｉｔｙＣｏｎｔａｉｎｅｒｓからなることに留意されたい。

すべてのアプリケーション開発者がタイプを定義するわけではなく、そのほとんどが、他のＩＳＶによって定義および配置されたタイプを使用する。本明細書には、オリジナルタイプの精度を低下させることのない特定の方法で、事前に定義されたタイプを拡張することができるタイプのユーザ用のメカニズムが提供される。ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎｓおよびＥｘｔｅｎｓｉｂｌｅＥｎｕｍｅｒａｔｉｏｎｓは、タイプの独立した拡張可能性を可能にするためにＣＤＭで提供される２つの機能である。

図２６は、このＣＤＭのインプリメンテーションにおけるエンティティ拡張の使用を示す図である。エンティティ拡張の必要性および使用を動機付けるために、ＣｏｎｔｒａｃｔＴｙｐｅについて考えてみる。これは、Ｎａｍｅ、Ａｄｄｒｅｓｓ、およびＰｈｏｎｅＮｕｍｂｅｒについての標準プロパティを有する。ＧＰＳ（全地球測位システム）ソフトウェアＩＳＶが、このタイプに緯度および経度の情報を追加したいと想定する。これを実行するための１つの方法は、実際のＣｏｎｔａｃｔＴｙｐｅを修正することであり、システム内にこのタイプの他のユーザが多数存在するため、これは望ましくない。他の方法は、ＣｏｎｔａｃｔＷｉｔｈＧＰＳＴｙｐｅと呼ばれるＣｏｎｔａｃｔＴｙｐｅから、新しいクラスをサブタイプ化することである。これは、ＡｄｄｒｅｓｓＴｙｐｅのすべてのユーザがＣｏｎｔａｃｔＷｉｔｈＧＰＳＴｙｐｅを使用するために自分のコードを変更しなければならなくなることを意味し、さらに、ＧＰＳ情報はこの新しいタイプに書き直さなければならないため、システム内の既存の連絡先に追加することができない。

ＣＤＭは、エンティティ拡張の概念によって、この問題を簡潔明快に解決する。エンティティ拡張は参照可能な構造化タイプであり、エンティティが含むことの可能な任意のメンバ、プロパティ、メソッド、および算出プロパティを含むことができる。拡張は、＜ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＴｙｐｅ＞要素を使用して定義される。拡張タイプは継承を享受しない。＜ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＴｙｐｅ＞は、＜ＥｎｔｉｔｙＴｙｐｅ＞内に存在可能な任意の要素を含むことができる。プロパティ名にとって、すべての拡張にわたって、あるいは拡張されるタイプのプロパティにわたって、必ずしも一意である必要はない。

存続時間管理。拡張は、各拡張タイプが、それが延在するエンティティタイプを指定するため、エンティティに緊密に結合される。すべてのエンティティ拡張は、タイプＲｅｆ（Ｔ）の「Ｅｎｔｉｔｙ」と名付けられたデフォルトのプロパティを有し、ここでＴはＥｘｔｅｎｄｓＴｙｐｅの値であり、これはエンティティインスタンスを指し示し、これが拡張である。これは、拡張内のエンティティキーとして図２６に概略的に示されている。

拡張は、延在しているエンティティ外部に独立した存在を持たない。ＣＤＭは、拡張の存続期間管理がインプリメンテーションの一部であることを要求し、すなわちインプリメンテーションは、対応するエンティティが削除された場合、すべての拡張を削除するはずである。この意味で拡張は、対応するエンティティの構成であるのと同様に動作する。たとえエンティティ拡張インスタンスが、収容エンティティによって定義されたデータの凝集単位の一部とみなされる場合でも、トランザクションを使用してアプリケーションによって明示的に管理される場合を除き、エンティティおよび拡張への変更に関する整合性の保証はない。

インスタンス管理。ＩｎｓｔａｎｃｅＭａｎａｇｅｍｅｎｔ＝「Ｉｍｐｌｉｃｉｔ」の場合、拡張で定義されたすべてのプロパティは、ｎｕｌｌ可能である、デフォルトの値を指定する、または最低発生数制約がゼロのＣｏｌｌｅｃｔｉｏｎタイプを有するの、いずれかのはずである。単集合インラインタイププロパティは、デフォルトの値を指定することはできないため、ｎｕｌｌ可能でなければならないことに留意されたい。これにより、常に存在するかのように拡張に対して照会を実行することができる。

ＩｎｓｔａｎｃｅＭａｎａｇｅｍｅｎｔ＝「Ｅｘｐｌｉｃｉｔ」の場合、アプリケーションは、共通データモデル用の照会言語で定義された操作を使用して、拡張を明示的にエンティティインスタンスに追加、およびエンティティインスタンスから除去するはずである。拡張の有無を調べるための手段も提供される。

拡張可能性の防止。タイプ設計者は、所与のタイプについての拡張の作成を防止したい場合がある。これは、＜ＥｎｔｉｔｙＴｙｐｅ＞または＜ＡｓｓｏｃｉａｔｉｏｎＥｎｔｉｔｙＴｙｐｅ＞要素の「Ｅｘｔｅｎｓｉｂｌｅ」属性によって実行可能である。「ｔｒｕｅ」（これはデフォルト値である）に設定された場合、＜ＥｎｔｉｔｙＥｘｔｅｎｓｉｏｎＴｙｐｅ＞群をこのエンティティ用に定義することができる。これを、このタイプへの拡張を防止するために「ｆａｌｓｅ」に送ることができる。

拡張可能列挙および列挙別名。売主またはその顧客が配置されたタイプのセットを発展させると、時には既存の列挙に名前を追加する必要が生じることがある。例えば、おそらく２７９５では［Ｃｏｒｏｌｌａ，Ｃａｍｒｙ，ＭＲ２，Ｃｅｌｉｃａ，Ａｖａｌｏｎ］の名前を有した、ＴｏｙｏｔａＣａｒＭｏｄｅｌｓと呼ばれる列挙を考えてみる。しかしながら２００５では、追加の名前、Ｐｒｉｕｓ、Ｅｃｈｏ、Ｍａｔｒｉｘ、およびＳｏｌａｒａを有する必要がある。

列挙は、＜ＥｎｕｍｅｒａｔｉｏｎＥｘｔｅｎｓｉｏｎＴｙｐｅ＞要素を使用して拡張することができる。この例を以下に示す。

７行目では、列挙タイプ「Ｃ」が、名前「Ｑ」、「Ｓ」、および「Ｔ」を追加するために拡張される。１２行目では、名前「Ｔ」および「Ｕ」を追加することによって、「Ｃ」に対して別の拡張が実行される。列挙メンバは、基礎となる基本または列挙拡張タイプの名前によって常に修飾されるため、拡張における重複名はＯＫである（この例ではＤ．ＴおよびＥ．Ｔ）。

既存の列挙メンバ名に対する別名を有することがしばしば有用である。この従来の例は、Ｓｅａｓｏｎｓ列挙で生じる。アメリカ合衆国では、季節は［ｓｐｒｉｎｇ，ｓｕｍｍｅｒ，ｆａｌｌ，ｗｉｎｔｅｒ］である。イギリスまたはインドでは「ｆａｌｌ」は「ａｕｔｕｍｎ」と呼ばれる。両方の名前が定義できるが、これらを概念的に同じ列挙メンバにマッピングさせることが望ましい。＜ＥｎｕｍｅｒａｔｉｏｎＭｅｍｂｅｒ＞要素内の「ＡｌｉａｓｅｓＭｅｍｂｅｒ」属性は、既存の名前に別名を定義する。この例では、Ｃ．Ｒ、Ｄ．Ｔ、およびＥ．ＵはすべてＣ．Ｑの別名であるため、一意の名前を表すものではない。

図２７は、タイプに関するモデルのセマンティクスを明確にする、代替インプリメンテーションのＣＤＭメタモデルフラグメントを示す図である。

図２８は、プロパティに関するモデルのいくつかのセマンティクスを明確にする、代替インプリメンテーションのＣＤＭメタモデルフラグメントを示す図である。

図２９は、アソシエーションに関するモデルのいくつかのセマンティクスを明確にする、代替インプリメンテーションのＣＤＭメタモデルフラグメントを示す図である。

図３０は、図に示されたリレーションシップのいくつかの態様を示す図２９のＵＭＬ構成図である。

図３１は、代替インプリメンテーションの拡張リレーションシップを示す図である。

ＣＤＭタイプシステム
以下の表は、システムの再帰的構造、すなわち有限文法によって暗に示される正しいセンテンスの無限セットを表す、ＣＤＭタイプシステムを抽象構文の形で示す。まず、タイプシステムが全部提示され、次いでやはり説明文と小規模な例が提示される。
構造タイプ

公称タイプ

基本タイプ
ａｎａｍｅシンボリック属性名（すなわちメンバ名）
ｅｎａｍｅシンボリックエンティティタイプ名
ｃｎａｍｅ複合タイプのシンボリック名
ｓｎａｍｅ他のタイプに関するシンボリック同義語
ｒｎａｍｅ２項リレーションシップのシンボリック名
ｅｓｎａｍｅエンティティセットのシンボリック名
ｅｃｎａｍｅエンティティコレクションのシンボリック名
ｓｃａｌａｒ重要な内部構造のない基本タイプ
ｅｎｕｍ列挙されたシンボルのタイプ
ｃｏｎｓｔｒａｉｎｔ一次述語計算（ｆｉｒｓｔ−ｏｒｄｅｒｐｒｅｄｉｃａｔｅｃａｌｃｕｌｕｓ）における式

構造タイプ。定義の第１ブロックは、ＣＤＭ構造タイプを含む再帰的に閉じた２次文法である。この２次文法内のセンテンスが参照できるのは、（１）同じ２次文法内の他の用語、（２）名前のみによる公称タイプ、（３）基本タイプの最終ブロックの用語、のみである。基本タイプは、どこかで開発される様々なネームスペースおよび簡単なタイプのみを含む。ただ１つの例外（エンティティコンテナにおけるコレクションタイプ）は、構造タイプは直接インスタンス生成できないことである。代わりにこれらはエンティティタイプを構築するが、これは一種の公称タイプであり、データのインスタンスを生成するための基本的な方法である。

ＳｉｍｐｌｅＴｙｐｅは、ｓｃａｌａｒ、ｅｎｕｍ、ｃｎａｍｅ、ｓｎａｍｅ、またはｅｎａｍｅへの参照のいずれかである。ｓｃａｌａｒは、マシンプリミティブ整数、ＳＱＬ１０進数、あるいは．ＮＥＴＳｔｒｉｎｇまたはＤａｔｅＴｉｍｅのような、重要な内部構造を持たない基本タイプである。非常に重要な種類のｓｃａｌａｒタイプはＧＵＩＤである。このタイプは、あらゆるインスタンスが空間および時間を横切って普遍的に一意である、プロパティを有する。基本的には、システム生成または代理キーのタイプとして使用される。ｅｎｕｍは、Ｃ＃、ＶｉｓｕａｌＢａｓｉｃ、または他の．ＮＥＴプログラミング言語で見られるような、簡単な列挙タイプである。ｃｎａｍｅは、以下に定義された公称タイプの１つである、ｃｏｍｐｌｅｘＴｙｐｅの名前である。ｓｎａｍｅは、名前付きタイプインラインの定義の作成と意味論的に同様の、ｔｙｐｅＳｙｎｏｎｙｍである。ｓｎａｍｅｓは公称タイプを参照できない、単なる構造タイプに関する同義語であることに留意されたい。最後にｅｎａｍｅは、公称タイプの基本種類であるｅｎｔｉｔｙＴｙｐｅの名前である。ｅｎａｍｅｓは、エンティティタイプのみが最上級参照を有することを強調するために、リテラルＲｅｆ＜＞表記で囲まれる。エンティティへの参照は、リレーショナルデータベース内の外部キーをモデル化する。ＣＤＭは、タイプベースのリレーションシップを介して、この使用法を公式化する。

一般に等価性には、第１に、２つのタイプの式が同じタイプを示すかどうか、第２に、単一の所与のタイプの２つのインスタンスが等しいかどうか、という２つの面がある。「タイプの等価性」という用語は前者に使用され、「値の等価性」または「インスタンスの等価性」は後者に使用される。

単純タイプの等価性は簡単であり、２つの単純タイプが明らかに同じであるか否か（ｅｎｕｍｓが同じ順序で同じシンボリックタグを有していなければならない）である。単純タイプの値の等価性は、原則として、ビット単位の比較によって定義される。実際には、．ＮＥＴタイプのいくつかはより複雑な等価性オペレーションを有することになる。あらゆる単純タイプが、タイプの２つのインスタンスを利用してブール変数を戻す、等価性演算子を提供しなければならないとだけ言えば十分であろう。

ｔｕｐｌｅＴｙｐｅは、ｓｔｒｕｃｔｕｒａｌＴｙｐｅａｎａｍｅの形の１つまたは複数のペアであり、それぞれの後にオプションのハッシュマークが付き、すべて「大括弧」で囲まれる。タプル（ｔｕｐｌｅ）タイプは、それぞれが名前とｓｔｒｕｃｔｕｒａｌＴｙｐｅｓのうちの１つとを再帰的に有する、メンバまたは属性からなるＣ＃クラス定義のペイロードと同様である。属性の名前はタイプａｎａｍｅであり、すなわち、ｅｎａｍｅ、ｃｎａｍｅなどのそれとは別のシンボリック名の領域から取り出される。名前による属性へのいかなる参照も、明白でなければならない。

タプルタイプの等価性は、２つのタプルタイプの属性が同じ名前およびタイプを有し、さらに同じ順序で現れる場合にのみ、この２つのタプルタイプは等しい、と定義される。したがって、｛ＴＡＡ，ＴＢＢ｝および｛ＴＢＢ，ＴＡＡ｝は、まったく異なるタプルタイプである。その理由は、ＣＤＭの認識では定位置アクセス構文をサポートしているからである。タプルタイプの２つのインスタンスは、それらの属性のタイプおよび値が再帰的に等しい場合に等しい。

ハッシュマークはキー指定を構成する属性を示し、ある種の環境では、ハッシュマークが付けられた属性の値は、集合的にコレクションタイプセット内またはｅｎｔｉｔｙＳｅｔｓ内で一意でなければならないことを意味する。あるタイプ内で複数の属性がハッシュマークを有する場合、そのキーは、マークが付けられたすべての属性からなり、テキスト内で定義された順序で連結された、複合キーである。複合キーは、複数のタプルタイプに及ぶことが可能であるため、例えば以下のようになる。

キー指定は｛Ｂ，Ｃ｝である。さらに長い例を考えてみる。

これは、ｐｅｒｓｏｎＮａｍｅ、ｓｏｃｉａｌＳｅｃｕｒｉｔｙＮｕｍｂｅｒ、およびａｄｄｒｅｓｓと名付けられた３つの属性を備える連絡先カードのトイ（ｔｏｙ）タプルタイプである。これらの属性はそれぞれ、人物の名前に関する自由形式の文字列と、エンティティセットまたはセットコレクションで一意のキーとして働くようにハッシュマークが付けられた社会保障番号の３つの部分を含むネストされたタプルと、番地、都市、州、および２つの部分からなる郵便番号を含み、より深くネストされたタプルとして再度表されたネストされたタプルとの、３つのタイプを有する。

ｃｏｌｌｅｃｔｉｏｎＴｙｐｅは、それぞれが他の構造タイプによってパラメータ化されたＬｉｓｔ、Ｓｅｔ、Ｍｕｌｔｉｓｅｔ、またはその他のいずれかである。たいていの場合、コレクションタイプはエンティティの構成要素として間接的にインスタンス化される。しかしながら、以下で説明するように、エンティティコンテナ内部で直接インスタンス化することもできる。

リスト。リストは、ｓｔｒｕｃｔｕｒａｌＴｙｐｅのインスタンスの順序付けされたコレクションである。「順序付けされた」とは、正の整数１、２、．．．からコレクションの要素へのマッピングが存在することを意味する。「順序付けされた」と「ソートされた」を混同してはならず、リスト「１，３，２」は順序付けされているがソートされておらず、「１，２，３」は順序付けとソートの両方がされている。ペアの特別なケースが普及している。ペアとは、単なる長さが２のリストのことである。

リストタイプの等価性は、リストのメンバの構造タイプにわたって再帰的である。（１）同じ数のメンバがいる場合、（２）再帰的にメンバ値が等しい場合、および（３）メンバが同じ順序で現れる場合に、リストタイプの２つのインスタンスは等しい。例えば、Ｌｉｓｔ＜Ｉｎｔ＞は、整数のリストのタイプである。

セット。セットとは、重複が許されない、ｓｔｒｕｃｔｕｒａｌＴｙｐｅのインスタンスの順序付けされないコレクションである。Ｓｅｔ＜Ｉｎｔ＞は、整数セットのタイプである。メンバの挿入、メンバシップのテスト、および共用体、交差などの算出のための操作である。

セットタイプの等価性は、セットのメンバの構造タイプにわたって再帰的である。セットタイプの２つのインスタンスは、同じ数のメンバを含み、再帰的にメンバの値が等しく、順序とは無関係な場合に等しい。

１から上方へのカウントは数学規則であり、プログラミング言語はゼロから上方へカウントする傾向がある。しかしながら数学においてさえも、１からカウントするか、ゼロからカウントするかを決定しないことが通用している。Ｎで書かれた自然数のセットとしてかなり基本的なものは、０、１、．．．として、および時には１、２、．．．として定義される。

マルチセット。マルチセットは、ｓｔｒｕｃｔｕｒａｌＴｙｐｅのインスタンスの順序付けされていないコレクションであり、重複が許可される。例えば、

は、文字列のセットのマルチセットのタイプとなり、

は、人物の名前および生年月日の匿名タプルタイプのインスタンスのマルチセットのタイプとなる。

マルチセットタイプの等価性は、マルチセットのメンバの構造タイプにわたって再帰的である。マルチセットタイプの２つのインスタンスは、（１）同じ数のメンバを含む場合、および（２）順序とは無関係であるが重複のカウントに関して、再帰的にメンバの値が等しい場合に等しい。したがって、「１，１，２，３」と「２，１，３，１」はマルチセットとして等しいが、「１，１，２，３」と「１，２，２，３」は等しくない。数学的に、マルチセットの最も簡単な表現は、多重度のカウントおよび値のペアのセットである。マルチセットがそのように表される場合、それらの等価性は自動的であり、セットの等価性およびペアの等価性にのみ依拠する。

公称タイプ。公称タイプは、ドメイン内で一意に命名されなければならない際立った特徴を有する。２つの公称タイプがサブタイプ化リレーションに関与する。これら２つはｃｏｍｐｌｅｘＴｙｐｅおよびｅｎｔｉｔｙＴｙｐｅである。構造タイプのサブタイプ化は理論的にかなり複雑であるため、ＣＤＭでは使用できない。

エンティティセットは、名前がタイプＲｅｆ＜ｅ＞のエンティティ参照の一部であること、およびインスタンスツリーをルート化する（ｒｏｏｔ）方法の１つであることの、両方の理由から、名目上のものである。その役割において、エンティティセットは、アプリケーションがインスタンスデータを取り出すことができるように名前を持たなければならない。エンティティコレクションも、インスタンスツリーをルート化するものであるため、命名されなければならない。その本質が命名であることから、タイプの同義語は公称タイプである。最終的に、アソシエーションエンティティが共有し、名前によって参照できるように、リレーションは名目上のものである。

公称タイプの等価性は、ある意味で構造タイプの等価性よりも容易である。そのほとんど竜のような形（ｄｒａｃｏｎｉｃｆｏｒｍ）において、２つの公称タイプが同じ名前を有し、その定義においてたとえ構文上であっても何らかの相違点がある場合は、エラーである。

公称タイプの値の等価性は、命名を利用することもできる。特にエンティティタイプの２つのインスタンスは、それらの参照が等しい場合にのみ等しい。これは、エンティティへの参照をそのアイデンティティと呼ぶための弁明の事由である。

それは、６つの異なる種類の公称タイプの宣言である。タイプ同義語は、特定のｓｎａｍｅをｓｎａｍｅｓのドメインに導入する。そのｓｎａｍｅがどこかで使用される場合、これが参照するｓｔｒｕｃｔｕｒａｌＴｙｐｅがｓｎａｍｅの代わりに使用される。例えば、

は、上記に示された連絡先カードタイプのタイプ同義語を定義する。そのタイプ同義語であるｔｏｙＣｏｎｔａｃｔＣａｒｄは、逐語定義をコピーペーストまたはキーボード入力するように強制された場合に必ず使用することができる。

ｃｏｍｐｌｅｘＴｙｐｅは、（１）オプションで他の複合タイプを拡張し、ここで（２）あらゆるインスタンスが一次述語計算で表されたオプションの制約に従い、さらに（３）所与の構造タイプが祖先の構造タイプに追加され、属性の衝突は許可されないことを意味する、ｓｔｒｕｃｔｕｒａｌＴｙｐｅによって示された追加の構造を有する、ｃｎａｍｅを導入する。

ＣＤＭは単一の継承を許可し、これは、ある複合タイプが多くとも１つの他の複合タイプを拡張することが可能であることを意味するが、再帰が可能であるため、次に直系の祖先が多くとも１つの他の複合タイプを拡張することが可能である。

複合タイプは、最もリッチな種類の構造化ＣＤＭインラインタイプである。インラインタイプは、他のタイプ定義において名前によるそれらへの参照は可能であるが、それらを直接インスタンス化することも、エンティティで生じる可能性のあるインスタンスへの参照を利用することも不可能である。タプルタイプのハッシュマーク付き属性の形の埋め込まれたキー指定が、複合タイプの状況では無視される場合もある。

複合タイプとタイプ同義語との相違は、前者が継承を享受して制約を受けることである。余談として、定理の証明およびモデルチェック技術を介して、コンパイル時にいくつかの制約を統計的にチェックできることに留意されたい。他の制約はランタイム時にチェックしなければならず、この場合、コンパイラが制約チェックコードを出力しなければならない。例えば

は、上記のタイプ同義語によって指定されたペイロードで複合タイプを定義する。

は、すでに定義されたより良好な連絡先カードに基づいて、従業員記録用の複合タイプを定義する。これは、ｂｅｔｔｅｒＣｏｎｔａｃｔＣａｒｄおよびインラインで作成された明示的タプルのすべての属性を有する。

ｅｎｔｉｔｙＴｙｐｅは、（１）オプションで他のエンティティタイプを拡張し、ここで（２）あらゆるインスタンスがオプションの制約に従い、（３）オプションでその名前によってリレーションシップを参照し、（４）所与の構造タイプが祖先のエンティティタイプの構造タイプに線形に連結され、属性の衝突は許可されないことを意味する、ｓｔｒｕｃｔｕｒａｌＴｙｐｅで示される追加の構造を有する、ｅｎａｍｅを導入する。

キー指定（ハッシュマーク）も連結され、祖先を伴うエンティティタイプのキー指定は、線形順序で含まれるタプルタイプのキー指定を連結することを意味する。

エンティティタイプはキー指定を有するものとする。これは、エンティティタイプが、その継承チェーンに少なくとも１つのハッシュマークを備えた少なくとも１つのタプルタイプを有することを暗に示す。この制限は、構文が複雑になり過ぎないように意味的に強制される。

オプションのｒｎａｍｅは、特別の属性を備えた２項リレーションである、ＣＤＭのアソシエーションエンティティを反映する。詳細については、以下のリレーションシップの項を参照されたい。

ＣＤＭは単一の継承を許可するが、これは、エンティティタイプが再帰的に多くとも１つの他のエンティティタイプを拡張できることを意味する。エンティティタイプは複合タイプを拡張することはできず、複合タイプはエンティティタイプを拡張することはできない。言い換えれば、複合タイプおよびエンティティタイプはサブタイプ化の領域に存在する。

エンティティタイプは、ｅｎｔｉｔｙＳｅｔｓに関与する最もリッチな種類の構造化ＣＤＭタイプであり、タプル内でハッシュマークが付けられた属性はリレーショナルデータベースの通常の意味で基本キーを構築する。さらに、エンティティインスタンスはアイデンティティを有し、これはそのエンティティセットのアイデンティティに連結されるキー値である。これらのアイデンティティは、文法のブロック１に現れる明示的Ｒｅｆ＜ｅｎａｍｅ＞の値を構築する。

エンティティタイプは、常にエンティティセットとの関連において直接インスタンス可能な基本的種類のＣＤＭタイプであり、ここでも、リレーショナルデータベースの通常の意味において、リレーションまたはテーブルに関するＣＤＭのモデルである。例えば、

は、上記で定義された複合タイプｅｍｐｌｏｙｅｅＲｅｃｏｒｄに基づいて、エンティティタイプを定義する。この点で、以前に無視されたハッシュマークが付けられた属性は、有意性が回復する。ｅｍｐｌｏｙｅｅＲｅｃｏｒｄはｂｅｔｔｅｒＣｏｎｔａｃｔＣａｒｄを拡張し、これはタイプ同義語ｔｏｙＣｏｎｔａｃｔＣａｒｄを使用し、これは埋め込まれた属性

を有することを想起されたい。

属性上のハッシュマークは、社会保障番号がｅｍｐｌｏｙｅｅＥｎｔｉｔｙインスタンスのエンティティセットの基本キーとなることを暗に示す。ユーザがキーに関する社会保障番号を介して従業員番号を設定した場合、ハッシュマークの付いた従業員番号およびハッシュマークの付いていない社会保障番号で新しいタプルタイプを定義するか、古いタイプから新しいタイプを作成するために、以下のハッシュマーク操作オペレーションを使用することが必要となろう。

ｅｎｔｉｔｙＳｅｔは、タイプｅｎａｍｅのエンティティの名前付きコレクションである。エンティティセットではエンティティインスタンスの重複は許可されず、エンティティタイプはキー指定、すなわち、ハッシュマークのタグが付けられた１つまたは複数の属性を持たなければならない。エンティティセットの名前ｅｓｎａｍｅが、ｅｓｎａｍｅｓの別個のドメインに導入される。

は、社会保障番号をキーとして使用する従業員エンティティのエンティティセットのタイプとなる。

ｅｎｔｉｔｙＣｏｎｔａｉｎｅｒは１つまたは複数の用語の名前付きコレクションであり、それぞれがそのｅｓｎａｍｅまたは匿名コレクションタイプのいずれかによって示されるエンティティセットである。

は、従業員と名付けられたエンティティセットのインスタンスを保持するエンティティコンテナのタイプとなる。エンティティコンテナ内のコレクションタイプをインスタンス化する方法がＴＢＤである。そうでない場合、エンティティコンテナは１つまたは複数のエンティティセット用の単なるカプセルである。

リレーションシップ。ＣＤＭは、（１）アソシエーション、（２）条件付アソシエーション、（３）アソシエーションエンティティ、（４）構成という、規範的な形のリレーションシップを必要とする。これらはすべて、数学的リレーションの同じ下位レベル概念の変形であり、以下のように公式化される。

数学的リレーションは、サブセットのすべてのメンバが何らかの制約を満たすような、セットのデカルト積（Ｃａｒｔｅｓｉａｎｐｒｏｄｕｃｔ）のサブセットである。Ａ_ｉ，ｉ＝１．．ｎとしても作成された１つまたは複数のセット（Ａ_１，Ａ_２，．．．Ａ_ｎ）のリストを考えてみる。Ｃ＝Ａ_１×Ａ_２×．．．×Ａ_ｎと書かれたこれらセットのデカルト積は、順序付けタプルｎ−ａｒｙのセットである。

Ｃ＝｛（ａ_１，ａ_２，．．．ａ_ｎ）｜ａ_１∈Ａ_１，ａ_２，∈Ａ_２，．．．，ａ_ｎ∈Ａ_ｎ｝
デカルト積は、制約がいかなるメンバもフィルタリングによって除去しないことから、セットのリストから形成可能な最大のリレーションである。

完全なデカルト積よりも少ないメンバでリレーションを形成するためには、制約がフィルタリングによってなんらかを除去しなければならない。例えば、１．．１００と書かれた１から１００までの従業員メンバのセットと、１から１０までの部門番号のセットについて考えてみる。従業員と部門とを関係付ける１つの方法は、リレーションの名前として記号

を定義すると、以下のとおりである。

上式で、「ｄｉｖ」は数論的整数除算（ｎｕｍｂｅｒ−ｔｈｅｏｒｅｔｉｃｉｎｔｅｇｅｒｄｉｖｉｓｉｏｎ）である。これは、従業員１から１０を部門１に、従業員１１から２０を部門２に、と言う具合に関係付ける。述語は、ｅ∈１．．１００、ｄ∈１．．１００、および（ｅ−１）ｄｉｖ１０＝ｄ−１の３つの部分の結合である。

この例では、従業員と部門との間の多数対１のリレーションシップを暗黙的に指定する。これは、以下の２項「演算子」としてリレーションの名前を使用するための標準的な省略法である。

一次述語計算は、一意性、多重度、参照、および条件付メンバシップを含む、実際的関心のすべての制約を表すのに十分である。ＣＤＭは、実際に重要または非常に一般的な制約のある種のパターンに名前を与える。例えば、リレーショナルデータベースシステムは、しばしば１対多数のリレーションシップを外部キーによってインプリメントする。ＣＤＭ参照制約は、ターゲットエンティティセットにおいて、外部キーの値が基本キーとして表わされなければならないステートメントである。その外部キーの値はタイプＲｅｆ＜ｅｎａｍｅ＞のインスタンスである。述語計算のパターンは、参照制約のクラスを表すために抽象化することができる。

略式には、制約は、「ａｎｄ」、「ｏｒ」、および「ｎｏｔ」などの論理連結語を介した個々の単語の構成である。各単語はブールタイプの式であり、ｅｎａｍｅおよびａｎａｍｅによってエンティティの属性と、定数と、≦などの比較演算子と、∀および∃などの修飾子によって導入される変数と、何らかの特別な副次作用のある操作制約とを参照することが可能であり、そのために以下の構文が与えられる。

９つの形の操作制約は、それぞれ、そのｅｎａｍｅよって２項リレーションの２つのエンティティタイプのうちの１つを参照する。Ｃａｓｃａｄｅは、操作Ｄｅｌｅｔｅ、Ｃｏｐｙ、またはＳｅｒｉａｌｉｚｅがリレーション内の他のエンティティタイプのインスタンスに伝播するものであることを意味する。Ｒｅｓｔｒｉｃｔは、操作が、他のエンティティタイプのインスタンスが適合可能な操作を独立して実行する場合にのみ実施されるものであることを意味する。Ｒｅｍｏｖｅは、操作が完了した場合にリレーションそれ自体が除去されるものであることを意味する。

制約の他の特別な形は、多重度制約であり、

上式で、ｎ_ｉ≦ｍ_ｉはゼロより大きい自然数である。この形は、述語計算における等価式用の構文上の砂糖（ｓｕｇａｒ）であり、従来のモデル化シナリオであるため、ここに提供されている。名前付きエンティティタイプは、リレーションでも命名されたものでなければならない。

ＣＤＭは、上記のいずれのカテゴリにも入らない制約に条件付制約という用語を使用する。構成制約のクラスを識別すべきであるかどうかについて、引き続き論議する。

論理的に言えば、ｅｎｔｉｔｙＳｅｔは単項リレーションであり、デカルト積はたった１つのセットからなる単純なものである。ｂｉｎａｒｙＲｅｌａｔｉｏｎは、２項リレーションであり、デカルト積は２つのセットに命名する。３項（ｔｅｒｎａｒｙ）、４項（ｑｕａｔｅｒｎａｒｙ）などのリレーションは、デカルト積を徐々に大きくして設計することができる。しかし、２項リレーションは仮想上はすべての実際のシナリオを満足させるものであり、さらにすべてのより大きなリレーションは２項リレーションの構成として簡単に構築することができる。

ｂｉｎａｒｙＲｅｌａｔｉｏｎは、ｒｎａｍｅをｒｎａｍｅｓのドメインに導入し、エンティティのペアでの２項リレーションまたは必須の制約を満たす他のリレーションを定義する。ペアがエンティティであって他のリレーションではない、基本的なケースでは、ペアはエンティティタイプの汎用セットのデカルト積のメンバである。関係する種類の一方または両方が他のリレーションである、再帰的なケースは、より大きなアリティ（ａｒｉｔｙ）のリレーションの構成的な構築をサポートする。

は、部門に関するエンティティタイプおよびエンティティセットを追加し、部門から従業員エンティティへの１対多数のリレーションシップを宣言する。こうしたリレーションシップをインプリメントするためのオプションがある。例えば、結合テーブルまたは外部キー制約のいずれかによってインプリメント可能である。

アソシエーション。ＣＤＭアソシエーションは、上記で定義したように２項リレーションシップである。

条件付アソシエーション。すべての２項リレーションは条件付きであり、これは制約が必須であることを意味する。したがってＣＤＭ条件付アソシエーションは、上記で定義したように２項のリレーションである。

アソシエーションエンティティ。エンティティタイプは、オプションで、ｒｎａｍｅによって２項リレーションを参照することができる。こうしたエンティティはＣＤＭアソシエーションエンティティを反映する。

構成。２つのエンティティタイプのうちの少なくとも１つの多重度が１である多重度制約があること、およびそのエンティティタイプにＯｎＤｅｌｅｔｅｅｎａｍｅＣａｓｃａｄｅの形の操作制約があることという、２つの基準を満たす２項リレーションはＣＤＭ構成である。

タイプレベルでの操作
（ｃｎａｍｅ｜ｅｎａｍｅ）ｄｒｏｐ → ｓｔｒｕｃｔｕｒａｌＴｙｐｅ
は、複合タイプまたはエンティティタイプを構造タイプに変換する。これは、ｃｏｍｐｌｅｘＴｙｐｅおよびｅｎｔｉｔｙＴｙｐｅ宣言を逆にする。

ｂｅｔｔｅｒＣｏｎｔａｃｔＣａｒｄは、宣言ComplexType betterContactCard toyContactCardによってｔｏｙＣｏｎｔａｃｔＣａｒｄから構築されたものであるため、ｂｅｔｔｅｒＣｏｎｔａｃｔＣａｒｄｄｒｏｐを作成することは、ｔｏｙＣｏｎｔａｃｔＣａｒｄを作成することと同じである。

(tupleType|sname) ++ (tupleType|sname) → ｔｕｐｌｅＴｙｐｅ
は、他を作成するために２つのタプルタイプ、またはそれらに命名する同義語を連結する、２項（ｂｉｎａｒｙ）演算子＋＋を定義する。
{String personName} ++ {{Int a,Int b,Int c} socialSecurityNumber #}
と作成することは、
{String personName, {Int a, Int b, Int c} socialSecurityNumber #}
と作成することと同じである。

（ｔｕｐｌｅＴｙｐｅ｜ｓｎａｍｅ）−−ａｎａｍｅ → ｔｕｐｌｅＴｙｐｅ
は、命名された属性をタプルタイプから除去する。入力タプルタイプが命名された属性を持たない場合、これはノーオペレーション（ｎｏｐ）である。
{String personName,Address address} -- personName
と作成することは、
｛Ａｄｄｒｅｓｓａｄｄｒｅｓｓ｝
と作成することと同じである。

（ｔｕｐｌｅＴｙｐｅ｜ｓｎａｍｅ）ＳｔｒｉｐＨａｓｈｅｓ → ｔｕｐｌｅＴｙｐｅ
は、その引数のタプルタイプのすべての属性のすべてのハッシュマークを取る。
{String personName, {Int a,Int b,Int c} socialSecurityNumber #} StripHashes
と作成することは、
{String personName, {Int a, Int b, Int c} socialSecurityNumber}
と作成することと同じである。

(tupleType|sname) aname AddHash -! tupleType
は、結果としてハッシュマーク付きの命名された属性を備えたタプルタイプを生じさせる。その属性がすでにハッシュマーク付きであった場合、そのままとなる。
{String personName, {Int a, Int b, Int c} socialSecurityNumber} personName AddHash
と作成することは、
{String personName #, {Int a, Int b, Int c} socialSecurityNumber}
と作成することと同じである。

次に図３２を参照すると、ＣＤＭアーキテクチャを実行するように動作可能なコンピュータを示すブロック図である。本発明の様々な態様に追加の情況を提供するために、図３２および以下の考察は、本発明の様々な態様がインプリメント可能な好適なコンピューティング環境３２００の簡潔で全体的な説明を提供することを意図している。これまで、１つまたは複数のコンピュータで実行可能なコンピュータ実行可能命令との一般的な関連において本発明について説明してきたが、当業者であれば、本発明が他のプログラムモジュールとの組合せで、ならびに／あるいは、ハードウェアおよびソフトウェアの組合せとしてもインプリメント可能であることを理解されよう。

一般にプログラムモジュールは、特定のタスクを実行するか、または特定の抽象データ型をインプリメントする、ルーチン、プログラム、構成要素、データ構造などを含む。さらに当業者であれば、本発明の方法は、それぞれを１つまたは複数の関連付けられたデバイスに動作可能に結合することができる、単一プロセッサまたはマルチプロセッサのコンピュータシステム、ミニコンピュータ、メインフレームコンピュータ、ならびにパーソナルコンピュータ、ハンドヘルドコンピューティングデバイス、マイクロプロセッサベースまたはプログラム可能な消費者家電製品などを含む、他のコンピュータシステム構成で実施可能であることを理解されよう。

本発明の例示された態様は、通信ネットワークを介してリンクされたリモート処理デバイスによってある種のタスクが実行される、分散コンピューティング環境でも実施可能である。分散コンピューティング環境では、プログラムモジュールをローカルおよびリモートの両方のメモリストレージデバイスに配置することができる。

コンピュータは、典型的には様々なコンピュータ読み取り可能媒体を含む。コンピュータ読み取り可能媒体は、コンピュータがアクセス可能な任意の使用可能媒体とすることが可能であり、揮発性および不揮発性媒体、取り外し可能および取り外し不能媒体の両方を含む。例を挙げると、コンピュータ読み取り可能媒体はコンピュータストレージ媒体および通信媒体を含むことができるが、これらに限定されるものではない。コンピュータストレージ媒体は、コンピュータ読み取り可能命令、データ構造、プログラムモジュール、または他のデータなどの、情報を格納するための任意の方法または技術でインプリメントされた、揮発性および不揮発性、取り外し可能および取り外し不能の両方の媒体を含む。コンピュータストレージ媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタルビデオディスク（ＤＶＤ）または他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気ストレージデバイス、あるいは、所望の情報を格納するために使用可能でありコンピュータがアクセス可能な任意の他の媒体を含むが、これらに限定されるものではない。

再度図３２を参照すると、本発明の様々な態様をインプリメントするための例示的環境３２００はコンピュータ３２０２を含み、このコンピュータ３２０２は、処理ユニット３２０４、システムメモリ３２０６、およびシステムバス３２０８を含む。システムバス３２０８は、システムメモリ３２０６を含むがこれに限定されるものではないシステム構成要素を、処理ユニット３２０４に結合する。処理ユニット３２０４は、市販の様々なプロセッサのいずれであってもよい。デュアルマイクロプロセッサおよび他のマルチプロセッサアーキテクチャを、処理ユニット３２０４として使用することも可能である。

システムバス３２０８は、（メモリコントローラを備えるかまたは備えない）メモリバス、周辺バス、および様々な市販のバスアーキテクチャのいずれかを使用するローカルバスと、さらに相互接続することが可能ないくつかのタイプのバス構造のうちのいずれであってもよい。システムメモリ３２０６は、読み取り専用メモリ（ＲＯＭ）３２１０およびランダムアクセスメモリ（ＲＡＭ）３２１２を含む。基本入出力システム（ＢＩＯＳ）は、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭなどの不揮発性メモリ３２１０に格納され、ＢＩＯＳは、起動時などにコンピュータ３２０２内の要素間で情報を転送する際に役立つ基本ルーチンを含む。ＲＡＭ３２１２は、データをキャッシュするための静的ＲＡＭなどの高速ＲＡＭも含むことができる。

コンピュータ３２０２は、好適なシャーシ（図示せず）内で外付けとして使用するように構成することも可能な内蔵ハードディスクドライブ（ＨＤＤ）３２１４（例えばＥＩＤＥ、ＳＡＴＡ）と、磁気フロッピー（登録商標）ディスクドライブ（ＦＤＤ）３２１６（例えば、取り外し可能なディスケット３２１８からの読み取りまたはこれへの書き込みのため）と、光ディスクドライブ３２２０（例えば、ＣＤ−ＲＯＭディスク３２２２の読み取り、あるいは、ＤＶＤなどの他の大容量光媒体からの読み取りまたはこれへの書き込みのため）とをさらに含む。ハードディスクドライブ３２１４、磁気ディスクドライブ３２１６、および光ディスクドライブ３２２０は、それぞれ、ハードディスクドライブインターフェース３２２４、磁気ディスクドライブインターフェース３２２６、および光ドライブインターフェース３２２８によって、システムバス３２０８に接続することができる。外付けドライブインプリメンテーション用のインターフェース３２２４は、ユニバーサルシリアルバス（ＵＳＢ）およびＩＥＥＥ１３９４インターフェース技術のうちの少なくとも１つ、またはその両方を含む。他の外付けドライブ接続技術は、本発明の企図の範囲内である。

ドライブおよびそれらに関連付けられたコンピュータ読み取り可能媒体は、データの不揮発性ストレージ、データ構造、コンピュータ実行可能命令などを提供する。コンピュータ３２０２の場合、ドライブおよび媒体は、好適なデジタル形式での任意のデータの格納に対処する。上記のコンピュータ読み取り可能媒体の説明はＨＤＤ、取り外し可能磁気ディスケット、およびＣＤまたはＤＶＤなどの取り外し可能光媒体に言及するものであるが、当業者であれば、ｚｉｐドライブ、磁気カセット、フラッシュメモリカード、カートリッジなどの、コンピュータによって読み取り可能な他のタイプの媒体も例示的オペレーティング環境で使用可能であること、さらに、任意のこうした媒体が、本発明の方法を実行するためのコンピュータ実行可能命令を含むことが可能であることを理解されたい。

オペレーティングシステム３２３０、１つまたは複数のアプリケーションプログラム３２３２、他のプログラムモジュール３２３４、およびプログラムデータ３２３６を含むいくつかのプログラムモジュールを、ドライブおよびＲＡＭ３２１２に格納することが可能である。オペレーティングシステム、アプリケーション、モジュール、および／またはデータのすべてまたは一部は、ＲＡＭ３２１２にキャッシュすることも可能である。本発明は、様々な市販のオペレーティングシステムまたはオペレーティングシステムの組合せでインプリメント可能であることを理解されよう。

ユーザは、１つまたは複数の有線／無線入力デバイス、例えばキーボード３２３８およびマウス３２４０などのポインティングデバイスを介して、コマンドおよび情報をコンピュータ３２０２に入力することができる。他の入力デバイス（図示せず）には、マイクロフォン、ＩＲリモートコントロール、ジョイスティック、ゲームパッド、スタイラスペン、タッチスクリーンなども含むことが可能である。これらおよび他の入力デバイスは、しばしば、システムバス３２０８に結合された入力デバイスインターフェース３２４２を介して処理ユニット３２０４に接続されるが、パラレルポート、ＩＥＥＥ１３９４シリアルポート、ゲームポート、ＵＳＢポート、ＩＲインターフェースなどの他のインターフェースによって接続することが可能である。

モニタ３２４４または他のタイプのディスプレイデバイスも、ビデオアダプタ３２４６などのインターフェースを介してシステムバス３２０８に接続される。コンピュータは通常、モニタ３２４４に加えて、スピーカ、プリンタなどの他の周辺出力デバイス（図示せず）を含む。

コンピュータ３２０２は、リモートコンピュータ３２４８などの１つまたは複数のリモートコンピュータへの有線および／または無線の通信を介した論理接続を使用する、ネットワーク環境内で動作することができる。リモートコンピュータ３２４８は、ワークステーション、サーバコンピュータ、ルータ、パーソナルコンピュータ、ポータブルコンピュータ、マイクロプロセッサベースの娯楽用電気製品、ピアデバイス、または他の共通ネットワークノードとすることが可能であり、通常は、コンピュータ３２０２に関して説明した要素の多くまたはすべてを含むが、簡略化するために、メモリ／ストレージデバイス３２５０のみが図示されている。記載された論理接続は、ローカルエリアネットワーク（ＬＡＮ）３２５２および／または例えばワイドエリアネットワーク（ＷＡＮ）３２５４などの大規模ネットワークへの、有線／無線接続を含む。こうしたＬＡＮおよびＷＡＮネットワーキング環境は事務所および会社内で一般的に見られ、イントラネットなどの企業規模のコンピュータネットワークを容易にするものであり、そのすべてが例えばインターネットなどのグローバル通信ネットワークに接続可能である。

コンピュータ３２０２は、ＬＡＮネットワーキング環境で使用される場合、有線および／または無線の通信ネットワークインターフェースまたはアダプタ３２５６を介してローカルネットワーク３２５２に接続される。アダプタ３２５６は、無線アダプタ３２５６との通信のためにその上に配置された無線アクセスポイントも含むことができるＬＡＮ３２５２への、有線または無線通信を容易にすることができる。

コンピュータ３２０２は、ＷＡＮネットワーキング環境で使用される場合、モデム３２５８を含むか、またはＷＡＮ３２５４上の通信サーバに接続されるか、またはインターネットを利用するなど、ＷＡＮ３２５４を介した通信を確立するための他の手段を有する。モデム３２５８は、内蔵型または外付け、および有線または無線デバイスとすることが可能であり、シリアルポートインターフェース３２４２を介してシステムバス３２０８に接続される。ネットワーク環境では、コンピュータ３２０２に関して示されたプログラムモジュールまたはその一部を、リモートメモリ／ストレージデバイス３２５０に格納することができる。図示されたネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立するための他の手段が使用可能であることを理解されよう。

コンピュータ３２０２は、無線通信内に動作可能に配置された任意の無線デバイスまたはエンティティ、例えば、プリンタ、スキャナ、デスクトップ、および／またはポータブルコンピュータ、携帯情報端末、通信衛星、無線検出可能タグに関連付けられた任意の機器または場所（例えば、キオスク、新聞売店、屋内トイレ）、および電話と通信するように動作可能である。これには、少なくともＷｉ−ＦｉおよびＢｌｕｅｔｏｏｔｈ（商標）無線技術が含まれる。したがって、通信は、従来のネットワークの場合のように事前に定義された構造、または単に少なくとも２つのデバイス間の随時通信とすることができる。

Ｗｉ−ＦｉすなわちＷｉｒｅｌｅｓｓＦｉｄｅｌｉｔｙは、家庭の長いす、ホテルの部屋のベッド、または仕事場の会議室から、無線でインターネットに接続できるようにするものである。Ｗｉ−Ｆｉは、コンピュータなどのこうしたデバイスが、基地局の領域内であればどこでも屋内および屋外でデータを送受信できるようにする、携帯電話で使用される技術に類似した無線技術である。Ｗｉ−Ｆｉネットワークは、ＩＥＥＥ８０２．１１（ａ、ｂ、ｇなど）と呼ばれる無線技術を使用して、セキュアで信頼できる高速無線接続を提供する。Ｗｉ−Ｆｉネットワークを使用して、コンピュータを相互に、インターネットに、および（ＩＥＥＥ８０２．３またはイーサネット（登録商標）を使用する）有線ネットワークに接続することができる。Ｗｉ−Ｆｉネットワークは、無認可の２．４および５ＧＨｚの無線帯域で、１１Ｍｂｐｓ（８０２．１１ａ）または５４Ｍｂｐｓ（８０２．１１ｂ）のデータレートで、あるいは例えば両方の帯域（デュアルバンド）を含む製品を使用して動作するため、ネットワークは、多くの事務所で使用されるベーシック１０ＢａｓｅＴ有線イーサネット（登録商標）ネットワークと同様の実世界性能を提供することができる。

次に図３３を参照すると、ＣＤＭが使用可能な例示的コンピューティング環境３３００を示す略ブロック図が示されている。システム３３００は、１つまたは複数のクライアント３３０２を含む。クライアント３３０２はハードウェアおよび／またはソフトウェア（例えばスレッド、プロセス、コンピューティングデバイス）とすることができる。クライアント３３０２は、例えば本発明を使用することによって、クッキーおよび／または関連付けられた文脈情報を収容することができる。

システム３３００は、１つまたは複数のサーバ３３０４も含む。サーバ３３０４はハードウェアおよび／またはソフトウェア（例えばスレッド、プロセス、コンピューティングデバイス）とすることができる。サーバ３３０４は、例えば本発明を使用することによって、変換を実行するスレッドを収容することができる。クライアント３３０２とサーバ３３０４との間に可能な通信の１つが、２つまたはそれ以上のコンピュータプロセス間で伝送されるように適合されたデータパケットの形とすることができる。データパケットは、例えばクッキーおよび／または関連付けられた文脈情報を含むことができる。システム３３００は、クライアント３３０２とサーバ３３０４との間の通信を容易にするために使用可能な通信フレームワーク３３０６（例えば、インターネットなどのグローバル通信ネットワーク）を含む。

通信は、有線（光ファイバを含む）および／または無線技術を介して容易にすることができる。クライアント３３０２は、情報（例えば、クッキーおよび／または関連付けられた文脈情報）をクライアント３３０２に対してローカルに格納するために使用可能な１つまたは複数のクライアントデータストア３３０８に、動作可能に接続される。同様に、サーバ３３０４は、情報をサーバ３３０４に対してローカルに格納するために使用可能な１つまたは複数のサーバデータストア３３１０に、動作可能に接続される。

以上、開示されたイノベーションの例について説明してきた。もちろん、構成要素および／または方法の考え得るあらゆる組合せを説明することは不可能であるが、当業者であれば、多くの他の組合せおよび順列が可能であることを理解されよう。したがって、本イノベーションは、添付の特許請求の範囲の精神および範囲に入るこうした代替、修正、および変形のすべてを包含することを意図している。さらに「含む」という用語が詳細な説明または特許請求の範囲のいずれかで使用される限り、こうした用語は、「備える、含む」が使用される場合に特許請求の範囲では遷移語（ｔｒａｎｓｉｔｉｏｎａｌｗｏｒｄ）として解釈されるため、「備える、含む」と同様に包括的であることが意図されている。

本発明に従った共通データモデル（ＣＤＭ）アーキテクチャを示す図である。革新的な態様に従ってＣＤＭを提供する方法を示す図である。リレーションシップ構成要素およびその形式を示す図である。エンティティ構成要素、ならびにそのメンバおよびメンバタイプを示す図である。本発明のコアデータモデルの特徴を示すためのＬＯＢアプリケーションウィンドウを示す図である。ＬＯＢアプリケーションウィンドウと、図５のＬＯＢアプリケーションウィンドウ上でエンティティ間の構造リレーションシップがどのように反映されるかを示す図である。図５のＬＯＢアプリケーションウィンドウ上に課された、エンティティの構成を示す図である。本発明に従って、エンティティリレーションシップ、集合テーブルおよびそのアドレッシング、ならびに制約を採用する、ＣＤＭ概念を使用する例示的なＬＯＢモデルを示す図である。ＣＤＭに従ったエンティティキーおよび識別子の使用を示す図である。いくつかのインラインタイプのＵＭＬ表現を示す図である。いくつかのエンティティタイプのＵＭＬ表現を示す図である。構成の下でのいくつかのタイプのＵＭＬ表現を示す図である。ＴＳ．ＴａｂｌｅＤでのＤのインスタンスの可視化を示す図である。図１３のエンティティテーブルに対応するＳＱＬテーブルを示す図である。開示されたイノベーションのＣＤＭが利用可能なデータプラットフォームを示す図である。タイプに関するモデルのセマンティクスを明確にするＣＤＭメタモデルフラグメントを示す図である。プロパティに関するモデルのセマンティクスを明確にするＣＤＭメタモデルフラグメントを示す図である。アソシエーションに関するモデルのセマンティクスを明確にするＣＤＭメタモデルフラグメントを示す図である。ＣＤＭの代替インプリメンテーションの４つの主な概念を示す図である。タイプ継承の概念をサポートするＣＤＭを示す図である。このインプリメンテーションに関するＣＤＭタイプの分類法を示す図である。このＣＤＭのインプリメンテーションにおけるタイプおよびインスタンスの概念を示す図である。エンティティおよびインラインタイプがＳＤＬを使用して宣言される方法を示す図である。ＣＤＭによってサポートされる多くの種類のリレーションシップを示す図である。ＣＤＭにおける持続エンティティに関する構造組織を示す図である。このＣＤＭのインプリメンテーションにおけるエンティティ拡張の使用を示す図である。タイプに関するモデルのセマンティクスを明確にする、代替インプリメンテーションのＣＤＭメタモデルフラグメントを示す図である。プロパティに関するモデルのいくつかのセマンティクスを明確にする、代替インプリメンテーションのＣＤＭメタモデルフラグメントを示す図である。アソシエーションに関するモデルのいくつかのセマンティクスを明確にする、代替インプリメンテーションのＣＤＭメタモデルフラグメントを示す図である。図に示されたリレーションシップのいくつかの態様を示す図２９のＵＭＬ構成図である。代替インプリメンテーションの拡張リレーションシップを示す図である。ＣＤＭアーキテクチャを実行するように動作可能なコンピュータを示すブロック図である。ＣＤＭが使用可能な例示的コンピューティング環境を示す略ブロック図である。

符号の説明

１００共通データモデル
１０２リレーションシップ構成要素
１０４エンティティ構成要素
３００リレーションシップ
３０２アソシエーション
３０４構成
３０６エンティティアソシエーション
４００エンティティ
４０２プロパティ
４０４ナビゲーションプロパティ
４０６算出プロパティ
４０８メソッド
４１０メンバ
４１２インラインタイプ
４１４テーブルタイプ
４１６単純インラインタイプ
４１８列挙タイプ
４２０エンティティ参照タイプ
４２２テーブル参照タイプ
４２４アレイタイプ
１５０２ＡＰＩ（言語統合およびデータアクセス）
１５０４アプリケーション
１５０６ＣＤＰランタイム
１５０８ストア
１５１０共通データモデル（テーブル、エンティティ、リレーションシップ）
１５１２セッション、トランザクション
１５１４照会プロセッサ
１５１６Ｏ−Ｒマッピング、照会、および更新マッピングを含む持続性エンジン
１５１８カーソル、規則
１５２０サービス：変更追跡、競合検出、イベント化
１５２２オブジェクトキャッシュ
１５２４ビジネス論理ホスティング
１５２６制約／セキュリティ
３２０４処理ユニット
３２０６システムメモリ
３２０８バス
３２１４内蔵ＨＤＤ
３２１４外付けＨＤＤ
３２１８ディスク
３２２０光ドライブ
３２２２ディスク
３２２４インターフェース
３２２６インターフェース
３２２８インターフェース
３２３０オペレーティングシステム
３２３２アプリケーション
３２３４モジュール
３２３６データ
３２３８キーボード
３２４０マウス
３２４２入力デバイスインターフェース
３２４４モニタ
３２４６ビデオアダプタ
３２４８リモートコンピュータ
３２５０メモリ／ストレージ
３２５６ネットワークアダプタ
３２５８モデム
３３０２クライアント
３３０４サーバ
３３０６通信フレームワーク
３３０８クライアントデータストア

Claims

共通データアクセスを容易にするコンピュータインプリメントシステムであって、
複数の異種のアプリケーションにまたがって均一なアイデンティティを有するデータエンティティを提供する、エンティティ構成要素と、
２つまたはそれ以上のデータエンティティ間のリレーションシップを定義する、リレーションシップ構成要素と
を備えることを特徴とするシステム。
前記データエンティティの少なくとも１つは、プロパティが定義されたエンティティタイプを含み、タイプ付けられたパラメータを受け取ることを特徴とする請求項１に記載のシステム。
前記エンティティタイプはアイデンティティデータを備えることを特徴とする請求項２に記載のシステム。
前記２つまたはそれ以上のエンティティが明示的なソース−ターゲットデータを介して互いに関係付けられるため、前記２つまたはそれ以上のエンティティ間のリレーションシップはアソシエーションであることを特徴とする請求項１に記載のシステム。
前記２つまたはそれ以上のエンティティがアソシエーションエンティティによって互いにリンクされるため、前記２つまたはそれ以上のエンティティ間のリレーションシップはアソシエーションであることを特徴とする請求項１に記載のシステム。
第１のエンティティが第２のエンティティの不可欠部分であるため、前記２つまたはそれ以上のエンティティ間のリレーションシップは構成であることを特徴とする請求項１に記載のシステム。
前記データエンティティは、エンティティのタイプ付けされたコレクションであるエンティティテーブルに追加されることによって持続することを特徴とする請求項１に記載のシステム。
前記リレーションシップは直接表されることを特徴とする請求項１に記載のシステム。
前記データエンティティは、インラインタイプ、エンティティタイプ、テーブルタイプ、列挙タイプ、およびアレイタイプのうちの１つのタイプを有するメンバを含むことを特徴とする請求項１に記載のシステム。
前記インラインタイプは、常駐するエンティティによって課される以上にアイデンティティを持たないことを特徴とする請求項９に記載のシステム。
前記データエンティティはキーによって参照可能であることを特徴とする請求項１に記載のシステム。
前記エンティティ構成要素は、プロパティ、ナビゲーションプロパティ、算出プロパティ、およびメソッドのうちの少なくとも１つを備えるエンティティメンバを含むことを特徴とする請求項１に記載のシステム。
前記エンティティ間のリレーションシップは条件付きであることを特徴とする請求項１に記載のシステム。
前記リレーションシップは、特定のテーブルのみに適用するようにスコーピング可能であることを特徴とする請求項１に記載のシステム。
異種のアプリケーションにまたがる共通データアクセスを提供するコンピュータインプリメント方法であって、
緊密に関係するデータの単一のアイデンティティでありかつ一意に識別可能なエンティティを提供するステップと、
前記エンティティの構造をプロパティとして、および前記エンティティの動作をメソッドとして識別するステップと、
リレーションシップを使用してエンティティ間のセマンティック接続を表現するステップと
を備えることを特徴とする方法。
前記エンティティは、特定タイプのインスタンスにストレージを割り振ること、アソシエーションによって関係付けられたエンティティにわたる照会を容易にすること、算出されたプロパティであること、および実行可能な操作を表すことのうちの、１つを実行するエンティティメンバで構成されることを特徴とする請求項１５に記載の方法。
前記エンティティメンバのうちの少なくとも１つは、タイプを含み、タイプパラメータを取ることを特徴とする請求項１６に記載の方法。
前記エンティティメンバは、データがインラインで前記エンティティに格納されるインラインタイプを含むことを特徴とする請求項１６に記載の方法。
前記エンティティメンバは、指定されたエンティティタイプのインスタンスの順序付けされていないコレクションであるテーブルタイプを含むことを特徴とする請求項１６に記載の方法。
異種のアプリケーションにまたがる共通データアクセスを容易にするシステムであって、
緊密に関係するデータの単一のアイデンティティでありかつ一意に識別可能なエンティティを提供するための手段と、
前記エンティティの構造をプロパティとして、および前記エンティティの動作をメソッドとして識別するための手段と、
明示的なソース−ターゲットリレーションシップを使用するアソシエーションによって、前記エンティティの２つまたはそれ以上を関係付けるための手段と、
親子リレーションシップにおける構成によって２つまたはそれ以上のエンティティを関係付けるための手段と、
エンティティアソシエーションによって２つまたはそれ以上のエンティティを関係付けるための手段と
を備えることを特徴とするシステム。