JP2005327232A - 任意のデータモデル用のマッピングアーキテクチャ - Google Patents

Abstract

【課題】 データソース自体のメタデータまたは構造を修正せずに２つまたはそれ以上のデータソースの間のマッピングを行うためのデータマッピングアーキテクチャ。
【解決手段】 データマッピングはさらに、更新もサポートする。このアーキテクチャでは、少なくとも、マッピングされるデータソースが与えられ、そのスキーマが事前に定義されており、変更できない場合もサポートする。このアーキテクチャは、少なくとも２つの任意のデータモデルからそれぞれのメタデータを受け取り、データモデル間で表現をマッピングするマッピングコンポーネントを含む。
【選択図】 図１

Description

本発明は、データソース間のデータマッピングに関するものである。

有線方式でも無線方式でも今日一般的になっている情報の自由な流れには、使用するデータの格納および解釈に関してソース（ｓｏｕｒｃｅ）とデスティネーション（ｄｅｓｔｉｎａｔｉｏｎ）とで互換性がとれている必要がある。世界に存在する情報源は、多くの場合、情報のソース毎にデータの表現が異なる情報源である。今日企業と個人が直面している主要な問題は、一方のフォーマットで存在するデータが他の目的のためには別のフォーマットで必要になることがあるという点である。

しかし、このようなプロセスは、本質的に大きく異なり絶えず変化するデータセット群により阻害されている。このような例は、様々なソースからデータが届き格納され他のソースから素早くアクセスされるデータウェアハウジングに見られる。一方のデータ表現から他方のデータ表現に変換するのは、時間がかかり、大量のリソースを使うだけでなく、変換問題をはらみ、場合によっては、複雑なためまったく実行不可能である。

以下では、本発明のいくつかの態様の基本的な内容を理解できるように、本発明の要約を簡単に述べる。この要約は、本発明の概要を広範囲にわたって述べたものではない。この要約は、本発明の鍵となる要素や決定的な要素を示したり、本発明の範囲を定めることを目的としていない。後で述べる詳細な説明の前置きとして、本発明のいくつかの概念を簡略化した形式で述べることのみを目的とする。

本明細書で開示され、請求されている本発明は、その一態様において、データソース自体のメタデータまたは構造を修正することなく、２つ（またはそれ以上）のデータソース同士のマッピングが必要なシナリオをサポートする設計のマッピング形式（ｍａｐｐｉｎｇ ｆｏｒｍａｔ）を含む。例えば、オブジェクト空間とリレーショナルデータベース、オブジェクト空間とＸＭＬデータモデル、ＸＭＬデータモデルとリレーショナルデータモデルの間のマッピングが実現されるが、あるいは考えられる他のデータモデルからＸＭＬ、リレーショナルデータモデル、または他のデータモデルへのマッピングを実現することも可能である。このマッピング形式では更新をサポートしており、さらに、マッピングされる両方のデータソースが与えられ、そのスキーマが事前に定義され、変更できない（つまり、読み取り専用である）場合もサポートする。例えば、ＸＭＬデータをリレーショナルデータベースにマッピングするためにすでに使用されている方法では、注釈を付け加えるためにＸＭＬスキーマ定義（ＸＳＤ）ファイルを変更する必要があった。本発明のマッピング形式は、ＸＳＤファイルが外部エンティティにより所有され、変更できないかのように働く。また、編集せずに同じＸＳＤファイルを再利用し、異なるデータソース（データベースなど）への複数のマッピングを行うことができる。

各データモデルは、マッピングに対する構造、フィールド、および関係（ｒｅｌａｔｉｏｎｓｈｉｐ）という３つの概念（または表現）のうち少なくとも１つを公開する。これらの概念はすべて、データモデル間でマッピングすることができる。１つのデータモデルが３つの表現を持つ他のデータモデルにマッピングされる表現のうちただ１つまたは２つしか持たない可能性がある。マッピング構造は、マッピングスキーマ（ｍａｐｐｉｎｇ ｓｃｈｅｍａ）の基本コンポーネントであり、対応付けられたマッピングフィールドのコンテナとして使用される。フィールドは、型付きデータを保持するデータモデル概念である。関係は、同じデータモデル内の２つの構造の間のリンクおよび関連付けであり、同じドメイン内の構造が互いにどのような関係にあるかを記述するものである。関係は、構造に他の構造が含まれる２つの構造および／または包含／参照の共通フィールドを通じて確立される。これらは、他の関係を確立できるので（例えば、兄弟関係、機能（ｆｕｎｃｔｉｏｎ）関係など）関係の単なる例である。本発明により、任意の関係を確立することができる。データモデルのメンバは、マッピングコンテキストに応じて様々なマッピング概念として公開することができる。

意味に関しては、マッピングはメタデータが追加されているビューと同等であり（またビューは実際にはクエリであり）、２つのマッピングされるドメインに関する可逆性のヒントおよび追加情報を含む。一方のデータソースが他方のデータソースにマッピングされる場合、本当に要求されているのは、ターゲットスキーマはソーススキーマの１ビューであるのが望ましいということである。マッピングは、データドメインの上にデータドメインを積み重ねるという形で表されるビューであり、ビュー変換（ｖｉｅｗ ｔｒａｎｓｆｏｒｍａｔｉｏｎ）自体を定義するものである。マッピングは、データに対して構造化変換を実行し複合ビューを作成することができ、この変換により、階層が作成されたり、崩壊（ｃｏｌｌａｐｓｅ）されたり、また一方の要素から他方の要素へ属性を移動し、新しい関係を導入する。

マッピングは、２つまたはそれ以上のマッピングされたモデル間で、マッピング可能な同じ概念を対応付け、接続する。マッピングは、さらに、有向性でもある。したがって、一方のドメインはソースとして分類され、他方のドメインはターゲットとして分類される。マッピングの方向性は、ソースとしてマッピングされるモデルはターゲットとしてマッピングされるモデルと異なる特性を持つという点でマッピングの実装および意味（ｓｅｍａｎｔｉｃｓ）に関して重要である。ターゲットはソースモデルのビューを保持し、マッピングはターゲットドメインのクエリ言語を使用して実現される。ソースは、データの永続的位置であり、マッピングはターゲットドメインのクエリ言語で書かれているクエリをソースドメインのクエリ言語に変換する。ソースとターゲットとの違いの１つは、ソースまたはターゲットモデルからの構造またはフィールドが構造およびフィールドについて適用可能なマッピングの個数に関して一部制限を設けているという点である。ターゲットドメインでは、構造およびフィールドは、一度しかマッピングできないが、ソースドメイン内では、構造およびフィールドは複数回マッピングすることができる。例えば、Ｃｕｓｔｏｍｅｒｓテーブルをターゲットドメイン内のＢｕｙｉｎｇＣｕｓｔｏｍｅｒ要素とＲｅｆｅｒｒｉｎｇＣｕｓｔｏｍｅｒ要素にマッピングすることができる。しかし、ローカル要素またはローカルクラスは、一度しかマッピングできない。マッピングの方向属性に起因する他の違いとして、マッピングを使用することによりユーザはターゲットドメインのクエリ言語を通じてマッピングされたモデルを操作することができるという点があげられる（例えば、リレーショナルモデルをＸＭＬモデルにマッピングするためにＸＱｕｅｒｙを使用し、リレーショナルモデルをオブジェクトモデルにマッピングするためにＯＰａｔｈを使用する）。

マッピングアーキテクチャの他の重要な属性に、更新可能であるという属性がある。これまで、開発者はドメイン間の変更を伝え同期をとるためにコードを書かなければならなかった。しかし、本発明では、マッピングエンジンがそれらのタスクを実行するようになっている。つまり、ユーザがターゲットドメイン内で構造を作成、削除、または修正した場合に、それらの変更はターゲットＡＰＩおよびマッピングエンジンによりソースドメインとの間で自動的に同期がとられる（永続化される）。

他の態様では、マッピングアーキテクチャはスタックすることが可能であり、ソースからターゲットへのマッピングに複数のステージが生じうる。

前記の目的および関連する目的を遂行するために、本発明のいくつかの例示する態様について、以下の説明および付属の図面を参照しながら説明する。ただし、これらの態様は本発明の原理を採用する様々な方法のうちわずかのみを示しており、本発明はこのような態様およびその等価物すべてを含むことを意図している。本発明の他の利点および新規な特徴は、図面を参照しながら本発明の以下の詳細な説明を読むと理解しやすいであろう。

本発明は、本明細書全体を通して類似の番号は類似の要素を表す図面を参照して説明する。以下の説明では、説明のため本発明を完全に理解できるように多数の具体的詳細を述べている。しかし、本発明は具体的詳細を知らなくても実施できることは明白であると思われる。他の場合には、本発明を説明しやすくするために、よく知られている構造およびデバイスがブロック図形式で示されている。

本出願で使用されているように、「コンポーネント」および「システム」という用語は、コンピュータ関連のもの、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれかを指すものとする。たとえば、コンポーネントとしては、プロセッサ上で実行されているプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および／またはコンピュータがあるが、これらに限定されない。説明のため、サーバ上で実行されているアプリケーションとサーバは両方ともコンポーネントとすることができる。１つまたは複数のコンポーネントを１つのプロセスおよび／または実行スレッド内に常駐させることができ、またコンポーネントを１台のコンピュータにローカライズし、かつ／または２台またはそれ以上のコンピュータ間に分散させることができる。

本明細書で使用しているように、「推論」という用語は、一般に、イベントおよび／またはデータを介して得られるような１組の観察結果から、システム、環境、および／またはユーザの状態を推理または推論するプロセスを指す。推論を使用して特定のコンテキストまたはアクションを識別したり、または例えば複数の状態について確率分布を生成することができる。推論は確率的なものとすることができる、つまり、データおよびイベントの考察に基づいて注目している状態で確率分布を計算することができる。推論は、さらに、１組のイベントおよび／またはデータから高水準のイベントを構成するために使用される手法を指す場合もある。このような推論を行うことで、イベント同士が時間的に近い関係による相関関係があるかどうか、またイベントおよびデータが１つまたは複数のイベントおよびデータソースを発生元としているかどうかに関係なく、１組の観察されたイベントおよび／または格納されているイベントデータから新しいイベントまたはアクションが構築される。

定義
以下の用語は説明全体を通して使用されており、主題の発明の様々な態様を理解しやすくするためこれらの定義をここに掲載する。

モデル（Ｍｏｄｅｌ）−設計成果物、例えば、ＸＭＬスキーマ、リレーショナルスキーマ、およびオブジェクトスキーマを表す複雑な離散構造。

ドメイン（Ｄｏｍａｉｎ）−特定のデータモデルに基づきデータを管理する１つまたは複数のアプリケーション。

オブジェクトドメイン（Ｏｂｊｅｃｔ ｄｏｍａｉｎ）−オブジェクトグラフデータモデルのＯｂｊｅｃｔＳｐａｃｅ実装。

ＸＭＬドメイン（ＸＭＬ ｄｏｍａｉｎ）−ＸＭＬデータモデルに基づくオブジェクトおよびクエリ言語のスタック。

リレーショナルドメイン（Ｒｅｌａｔｉｏｎａｌ ｄｏｍａｉｎ）−リレーショナルデータモデルに基づくＤＢＭＳ（データベース管理システム）。

ＩＤｏｍａｉｎＳｃｈｅｍａ−マッピング可能な構造のシリアライズ可能なラベル付き有向グラフとしてモデルを公開するモデル管理オブジェクトモデル。モデルグラフの辺（ｅｄｇｅ）を「関係」と呼ぶ。例えば、ＸＳＯＭ（ＸＭＬスキーマＸＳＤ（ＸＭＬ Ｓｃｈｅｍａ Ｄｅｆｉｎｉｔｉｏｎ）を公開するオブジェクトモデル）、ＲＳＯＭ（リレーショナルスキーマＲＳＤ（Ｒｅｌａｔｉｏｎａｌ Ｓｃｈｅｍａ Ｄｅｆｉｎｉｔｉｏｎ）を公開するオブジェクトモデル）、およびＯＳＯＭ（オブジェクトスキーマＯＳＤ（Ｏｂｊｅｃｔ Ｓｃｈｅｍａ Ｄｅｆｉｎｉｔｉｏｎ）を公開するオブジェクトモデル）がある。

マッピング構造（Ｍａｐｐｉｎｇ ｓｔｒｕｃｔｕｒｅ）−対応付けられたマッピングフィールドのコンテナとして使用されるデータモデルスキーマの基本コンポーネント（例えば、リレーショナルドメイン内のテーブル、ＸＭＬドメイン内の複合型要素、およびオブジェクトドメイン内のクラス）。

フィールド（Ｆｉｅｌｄ）−型付き（ｔｙｐｅｄ）データを保持するデータモデル概念。概念上、フィールドはスカラー値を保持するが、場合によっては、複合データ（例えば、ＸＭＬデータ型およびＵＤＴ）を保持することも可能である。さらなる例としては、リレーショナルデータモデルの列、ＸＭＬドメイン内の属性および単純型要素、およびオブジェクトドメイン内のプロパティがある。

関係（Ｒｅｌａｔｉｏｎｓｈｉｐ）−同じデータモデル内の２つの構造の間のリンクおよび関連付けであり、同じドメイン内の構造が互いにどのように対応付けられているかを記述する。関係は、構造に他の構造が含まれる２つの構造および／または包含／参照の共通フィールドを通じて確立される（例えば、ＸＭＬ包含階層、およびそのフィールドを通じて他のオブジェクトを参照するオブジェクト）。

図１を参照すると、本発明のマッピングシステム１００のブロック図が示されている。このフレームワークは、オペレーションに変換される、それぞれのクエリ言語またはＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍａｂｌｅ Ｉｎｔｅｒｆａｃｅｓ）を使用してそのドメイン内でＣＲＵＤ （Ｃｒｅａｔｅ、Ｒｅａｄ、Ｕｐｄａｔｅ、およびＤｅｌｅｔｅ）オペレーションを実行するデータモデルの能力を提供する。例えば、ＸＭＬおよびオブジェクトデータモデルは、クエリ言語（例えば、それぞれＸＱｕｅｒｙおよびＯＰａｔｈ）を使用してそのドメイン内でＣＲＵＤオペレーションを実行することができるが、それらのオペレーションは、クエリ言語（例えば、ＳＱＬ）を使用してリレーショナルドメイン内のオペレーションに変換される。

システム１００は、ソースデータモデル１０２およびターゲットデータモデル１０４を含み、マッピングコンポーネント１０６を介してソースモデル１０２からターゲットモデル１０４へのマッピングが実行される。各データモデル（１０２および１０４）は、対応付けることができる１つまたは複数のエンティティを公開するメタデータに関連付けられている。つまり、ソースモデル１０２は、ソースメタデータ１０８を公開し、ターゲットモデル１０４は、ターゲットメタデータ１１０を公開し、メタデータ（１０８および１１０）はそれぞれ、マッピングコンポーネント１０６を介して直接対応付けられる概念的エンティティを含む。メタデータエンティティは、構造、フィールド、および関係の概念（または表現）を含む。

マッピングは、少なくとも２つのマッピングされたモデルからの同じマッピング可能な概念、または異なるマッピング可能な概念、または同じマッピング可能な概念と異なるマッピング可能な概念の組合せ（以下で詳述する）を対応付け、接続する。マッピングは、有向性（ｄｉｒｅｃｔｉｏｎａｌ）である。したがって、いくつかのドメインはソース１０２として分類され、他のドメインはターゲット１０４として分類される。開示されているマッピングアーキテクチャの有向性の側面は、マッピングの実装および意味に関してかなり有益である。さらに、ソース１０２としてマッピングされるモデルは、ターゲット１０４としてマッピングされるモデルと異なる特性を持つことができる。

ターゲットモデル１０４はソースモデル１０２のビューを保持する。つまり、マッピングは、ターゲットドメインのクエリ言語を使用して実現される。ソースモデル１０２は、データの永続的位置であり、マッピングコンポーネントはターゲットドメインのクエリ言語で書かれているクエリをソースドメインのクエリ言語に変換する。

ソース１０２とターゲット１０４との違いは、ソースまたはターゲットモデル（１０２または１０４）からの構造またはフィールドに、構造およびフィールドについて適用可能なマッピングの個数に関して一部制限があるという点である。ターゲットドメインでは、構造およびフィールドは、一度しかマッピングできないが、ソースドメイン内では、構造およびフィールドは複数回マッピングすることができる。例えば、Ｃｕｓｔｏｍｅｒｓテーブルをターゲットドメイン内のＢｕｙｉｎｇＣｕｓｔｏｍｅｒ要素とＲｅｆｅｒｒｉｎｇＣｕｓｔｏｍｅｒ要素にマッピングすることができる。しかし、ローカル要素またはローカルクラスは、一度しかマッピングできない。ここでは、例、構文、および意味に関してより詳しい説明を行う。

マッピングの方向属性に起因するソースとターゲットとの別の違いは、マッピングを使用することによりユーザはターゲットドメインのクエリ言語を通じてマッピングされたモデルを操作することができるという点である（例えば、ＸＭＬマッピングに対する関係のＸＱｕｅｒｙ、およびオブジェクトマッピングに対する関係のＯＰａｔｈ）。

図２を参照すると、本発明によるプロセスのフロー図が示されている。説明を簡単にするために、本明細書で示されている１つまたは複数の方法が、例えばフロー図の形式で示され、一連の活動として記述されているが、本発明は活動の順序によって制限されるわけではなく、本発明によるいくつかの活動はその図に示されているここで説明しているのと異なる順序でかつ／または他の活動と同時に実行することも可能であることを理解し、認識するであろう。例えば、当業者であれば、方法を代わりに一連の相互に関連のある状態またはイベントとして状態図などの中に表すことが可能であることを理解し、認識するであろう。さらに、本発明によりこの方法を実装するために例示されているすべての活動が必要なわけではない。

２００に、データマッピングのデータモデルが示されている。２０２で、データモデルが識別されると、各モデルの対応するメタデータが識別される。２０４で、ソースモデルからターゲットモデルへのデータマッピングが開始する。２０６で、システムは、マッピングエラーが発生したかどうかを判定する。「Ｙｅｓ」であれば、フローは２０８に進み、エラーを報告する。フローは、２０４の入力に戻り、マッピングプロセスを続行する。その一方で、マッピングエラーが発生していない場合、フローは２０６から２１０に進み、マッピングプロセスを完了まで続行する。プロセスは、「停止」ブロックに到達する。

図３は、ソースからターゲットへのマッピングを円滑にするために公開されている概念的メタデータエンティティの図を示している。マッピングコンポーネントは、ソースのメタデータ１０８とターゲットのメタデータ１１０との間のマッピング機能を調整するマッピングファイル３００を作成する。この特定の実施形態では、ソースのメタデータ１０８およびターゲットのメタデータ１１０は、それぞれ、構造、フィールド、および関係という、マッピング関係を確立するために使用することができる３つのエンティティを備える。そのため、ソースのメタデータ１０８は、ＳＴＲＵＣＴＵＲＥ_Ｓエンティティ３０２、ＦＩＥＬＤ_Ｓエンティティ３０４、およびＲＥＬＡＴＩＯＮＳＨＩＰ_Ｓエンティティ３０６を含む。同様に、ターゲットのメタデータ１１０は、ＳＴＲＵＣＴＵＲＥ_Ｔエンティティ３０８、ＦＩＥＬＤ_Ｔエンティティ３１０、およびＲＥＬＡＴＩＯＮＳＨＩＰ_Ｔエンティティ３１２を含む。

この構造は、データモデルスキーマの基本コンポーネントであり、関係するマッピングフィールドのコンテナとして使用される。例として、リレーショナルドメイン内のテーブル、ＸＭＬドメイン内の複合型要素、およびオブジェクトドメイン内のクラスが含まれる。フィールドエンティティは、型付きデータを保持するデータモデル概念である。概念上、フィールドはスカラー型値を保持するが、場合によっては、複合データ（例えば、ＸＭＬデータ型とＵＤＴ）を保持することも可能である。フィールドのマッピングの例としては、リレーショナルデータモデルの列、ＸＭＬドメイン内の属性および単純型要素、およびオブジェクトドメイン内のプロパティがある。関係は、同じデータモデル内の２つの構造の間のリンクおよび関連付けであり、同じドメイン内の構造が互いにどのような関係にあるかを記述するものである。関係は、構造に他の構造、例えば、ＸＭＬ包含階層、およびそのフィールドを通じて他のオブジェクトを参照するオブジェクトが含まれる、２つの構造および／または包含／参照の共通フィールドを通じて確立される。

データモデルのメンバは、マッピングコンテキストに応じて様々なマッピング概念として公開することができる。例えば、ＸＭＬ要素は、フィールドおよび構造（例えば、単純型要素および複合型要素）として公開することができる。メンバを特定の概念として提示することが有効であるかどうかを判別するのは、マッピングとＩＤｏｍａｉｎＳｃｈｅｍａである。データモデルを異なるマッピング概念として公開することができる他の例は、表現も例えばカスタムテーブル内の概念とすることが可能なリレーショナルドメインを伴う。

マッピングの意味
意味に関しては、マッピングは、可逆性のヒントおよび２つのマッピングされたドメインに関する追加情報を含む追加メタデータを持つクエリ／ビューと同等である。一方のデータソーススキーマが他方のデータソーススキーマにマッピングされる場合、要求されているのは、ターゲットスキーマがソーススキーマの１つのビューであることが望ましいということである。マッピングにより、ビュー変換自体が定義される。例えば、リレーショナルデータベースをＸＭＬにマッピングする場合、ビューが定義され、その際に、その表示（またはスキーマ）は最終的にＸＳＤによって定義され、マッピングファイルでは、ＲＳＤファイルで表されるリレーショナルデータベースでこのビューを（処理し実行することにより）生成する方法を定義する。

マッピングは、別のデータドメインの上にデータドメインを積み重ねるという形で表されるビューである。マッピングがそのようなビューである（また、ビューは実際にはクエリである）と理解していることが、マッピングの意味を理解するうえで重要である。

マッピングビューとＳＱＬビューとを対比することができる。ＳＱＬ Ｓｅｒｖｅｒでは、リレーショナルデータベースの上にリレーションビューを定義することができる。このビューは、基本的に、結果のスキーマ（ステートメントのＳＥＬＥＣＴ句）、ソースのサブスキーマの関連する部分（おおまかにいうと−ステートメントのＦＲＯＭ句）、およびソーススキーマから結果スキーマを生成することができる変換（ＷＨＥＲＥ句）の３つを組み合わせたＳＱＬクエリによって定義される。

開示されているマッピング形式は、同じ３つの部分を持つが、明確に区別される（ＸＳＤ、Ｍａｐｐｉｎｇ、ＲＳＤのように）。

マッピングは、複合クロスドメインビュー（ｃｏｍｐｌｅｘ ｃｒｏｓｓ−ｄｏｍａｉｎ ｖｉｅｗ）である。マッピングを使用することで、クロスドメインビューを作成することができる。際立った特徴（例えば、ＳＱＬビューまたはＸＳＬＴビューの）は、ソースおよびターゲットスキーマが異なるデータモデルドメインに属することができるという点である。マッピングでは、リレーショナルスキーマの上に階層型ビュー（ＸＭＬ）を構築したり、あるいは階層型スキーマの上にグラフビュー（オブジェクト）を構築するなどができる。

開示されているマッピングアーキテクチャにより、ＸＱｕｅｒｙおよびＸＳＬＴなどの他の言語をマッピングと併せて使用しターゲットまたはソースドメインを変換することができる。変換は、例えば、オペレーション毎にマップに追加される。オペレーションの例として、Ｉｎｓｅｒｔ、Ｕｐｄａｔｅ、Ｄｅｌｅｔｅ、およびＱｕｅｒｙがある。

サンプルコード：

ＴｒａｎｓｆｏｒｍＬａｎｇｕａｇｅは、マッピングされるデータを変換するために使用する言語である。ＴｒａｎｓｆｏｒｍＬｏｃａｔｉｏｎは、ディスク上のファイルロケーションまたは変換結果が供給されるインターネット上のファイルロケーションである。ロケーションが指定されていない場合、変換はＭａｐＴｒａｎｓｆｏｒｍ要素のテキストで与えることができる。Ｏｐｅｒａｔｉｏｎは、マッピングを使用するアプリケーションに基づいて定義されるこの変換に対するオペレーションである。

マッピングは、データに対して構造化変換を実行し複合ビューを作成することができる。これにより、階層が作成されたり、崩壊されたり、また一方の要素から他方の要素へ属性を移動し、新しい関係を導入することができる。マッピングの結果（ターゲットスキーマ）は、複合スキーマであってもよい。これは、基本的にマルチテーブルデータベーススキーマを単一テーブルに変換する従来のアーキテクチャと対照的である。マッピングにより、出力上での関係で対応付けられる複数のテーブル（要素など）を生成することができる。

マッピングはビューを定義するが、これは、使用するためにはユーザはビューの上でクエリおよび更新を実行できることを意味する。マッピングは、オペレーションではなく、クエリまたは更新オペレーションなしで何らかのデータを生成するのには使用できない。しかし、クエリは、些細なもの（例えば、ｓｑｌ：ｖｉｅｗ（“ｆｉｌｅｎａｍｅ”））でもよく、マッピングビューで記述されたすべてのデータを取り出すことができる（このビューを実現する）。マッピングは、（いくつか例外はあるが）、クエリとそのビュー（更新可能ビュー）に対する更新の両方をサポートする。

技術上、マッピングはクエリに類似している。クエリを介してＳＱＬ Ｖｉｅｗを定義するのと同じように、マッピングは、さらに、このビューを生成するクエリがあることを意味する。マッピングは、静的な再利用可能更新可能ビューを定義し、ユーザはこのビューを使用して、このビューの上に複数のアドホックなクエリ／更新を課すことができる。

例えば、ユーザは開示されているマッピング形式を使用して、関連する注文と注文明細とともに最後の７日間に注文があったすべての顧客（「Ａｃｔｉｖｅ Ｃｕｓｔｏｍｅｒｓ」と呼ぶ）のビュー（スキーマ）を定義することができる。その後、ユーザは、このビューを使用して、そのビューの上でクエリを実行する。例えば、一方のドメインで、収支が負であるすべての「Ａｃｔｉｖｅ Ｃｕｓｔｏｍｅｒｓ」を取り出すＸＱｕｅｒｙを課すことができる。実行ステップで、マッピングプロセッサは、ＸＱｕｅｒｙステートメントと組み合わせて、ＳＱＬＧｅｎエンジンにより、リレーショナルビューの上のＳＱＬ Ｑｕｅｒｉｅｓに対するＳＱＬ Ｓｅｒｖｅｒと同様に、マッピングの関連する部分に対応するクエリを作成するために使用されるマッピング情報を公開する。

取り出しおよび更新オペレーションは、本質的に異なる。単一の取り出しオペレーションは、一方向でサポートされているが、３つのオペレーション（挿入、更新、および削除）は、他の方向でサポートされる。例えば、ソースとしてＳＱＬ Ｓｅｒｖｅｒ内のデータをターゲットＸＭＬスキーマにマッピングし、リレーショナルデータのＸＭＬビューを作成することができるマッピングを定義する。ＸＱｕｅｒｉｅｓは、ＳＱＬ Ｓｅｒｖｅｒ内のテーブルに対して実行することはできない。さらに、同じマッピングを使用して、ＸＭＬデータソースの上にリレーショナルビューを表すことはできない。開示されているマッピング形式は、対称的ではなく、容易に反転することはできない。データは、ＳＱＬ ＳｅｒｖｅｒからＸＭＬとして取り出すことができ、またＸＭＬクエリ言語によりクエリを実行することができる。マッピングではビューを通じての更新をサポートしているため、同じマッピングを通じて更新を実行することもできる。

マッピングは、２つのマッピングされるモデル間の双方向（読み書き）変換を適用するのに必要な情報を供給する。データモデルドメイン間でクエリ、更新、挿入、および削除オペレーションを実行するのに必要な情報は、存在しているかどうか（一方のドメイン内に構造が存在するかどうかは、ドメインが同期されている場合に他方のドメイン内に構造が存在することに基づく）、コピー（コピーオペレーションが一方のドメインから他方のドメインへの値、例えばＮＵＬＬ値およびデータ型変換に対する制限付き変換を含むことができる場合にソースモデルおよびターゲットモデル内のマッピングされているフィールド間のコピーデータ）、および関係マップ（ソースドメイン内のそれぞれのマッピングされている構造間の関係に対するターゲットドメイン内の２つのマッピングされている構造間に存在するマップ関係）である。関係同士の間のマッピングは、２つのデータモデル内で並行したナビゲーション、つまり、一方のドメイン内の特定の関係に基づく一方の構造から他方の構造への移動を可能にし、他方のドメイン内の２つのマッピングされている構造間での移動に変換する。

関係マップは、存在またはコピーの意味よりもあまり直感的でない概念である。関係マップは、同時にマッピングされている両方のドメイン内で「グラフ内を探索（ｗａｌｋ）する」ことができる必要がある。ターゲットモデルの２つのマッピングされている構造（例えば、オブジェクト、ＸＭＬ）にそれらの間の関係がある場合、または１つのターゲット構造が複数のソース構造（例えば、テーブル内の）にマッピングされる場合、ターゲットドメイン内の暗黙のまたは明示的な関係をソース（例えば、リレーショナル）ドメイン内の一致する関係にマッピングされなければならない。ターゲットドメイン内のすべての関係はソースドメイン内の関係にマッピングされなければならないが、反対はそうではないという要求条件はターゲットドメインはソースドメイン上のビューであるということに起因していることに注意されたい。したがって、マッピングは、このビューを作成するために必要な最低限の情報を必要とする。ソースドメインは、マッピングに関連していないさらに多くの構造（テーブル）および関係を含むことができる。

ドメイン内の構造間の関係は、参照関係（型が他の型への参照を含み、一方の型を削除／更新しても、他の型も削除／更新されることはなく、参照のみが削除される）または所有（ｏｗｎｅｒｓｈｉｐ）関係（Ｃｏｍｐｏｓｉｔｅ）（構造が他の構造を所有し、構造の１つのインスタンスに対するオペレーションが関係する構造のインスタンスに伝わる場合の関係）のいずれかである。例えば、特定の顧客を削除すると、その注文も削除されるが、注文明細を削除しても製品は削除されない。

特定のマッピングが、読み書き両方のオペレーションに適用される。したがって、マッピングは更新可能（双方向）であると考えられる。異なる動作（例えば、読み取り専用または複数のテーブルシナリオへの１つのターゲット構造の書き込み）を指定するためにユーザはそれぞれのドメインの拡張メカニズムを利用することができる。例えば、リレーショナルドメインは、ｑｕｅｒｙ、ｕｐｄａｔｅ、ｉｎｓｅｒｔ、およびｄｅｌｅｔｅコマンドが用意されているＣｕｓｔｏｍＴａｂｌｅを公開し、ユーザは、マッピングに基づいてこのコマンドが呼び出されたときに実行されるＳＱＬステートメントを指定することができる。他の例として、リレーショナルドメイン内の列およびテーブルのＲｅａｄＯｎｌｙフラグがある。しかし、このような列またはテーブルを更新しようとすると、エラーが発生するため、このような情報はドメイン内で指定し、マッピングでは指定しない。

次に図４を参照すると、マッピングファイル４００を使用してソースリレーショナルスキーマをターゲットＸＭＬスキーマにマッピングする例が示されている。本発明のいくつかの態様では、ソーススキーマ４０２もターゲットスキーマ４０４も、マッピングの実行のために修正を必要としない。したがって、ソースリレーショナルスキーマ４０２とターゲットＸＭＬスキーマ４０４は両方とも、いずれもが編集を必要としないため、読み出し専用とすることができる。本発明のこのような特徴は著しいものであるが、それは、アプリケーションでは、多くのクライアントデータモデルにおいて編集でマッピングを実行することが許されないからである。

開示されているマッピング形式は、ソースのデータソース４０２にない情報とともにソースのデータソース４０２のスキーマを定義するソース記述コンポーネント４０６、ターゲットのデータソース４０４内にない情報とともにターゲットのデータソース４０４のスキーマを定義するターゲット記述コンポーネント４０８、および中央マッピングコンポーネント４１０などの３つまたはそれ以上のコンポーネントからなるものとみなすことができる。ソース記述コンポーネント４０６は、リレーショナルソーススキーマ４０２を拡張したものであり、ターゲット記述コンポーネント４０８は、ＸＭＬターゲットスキーマ４０４を拡張したものであり、中央マッピングコンポーネント４１０は実際のマッピングを実行する。

次に、このタスクでは、ターゲットスキーマ４０４のＸＳＤにより定義された形式でＸＭＬデータを生成することについてリレーショナルデータベースにクエリを実行できるように、また他の方向では、ＸＭＬデータをソースとして受け付けてリレーショナルテーブルにロードし、マッピングに従ってＸＭＬデータを細分（ｓｈｒｅｄ）してリレーショナルデータベースに入れられるように、これら２つのスキーマ（４０２と４０４）の間のマッピングを定義する。

マッピングを定義するときに従来から存在していた問題の１つは、データソーススキーマの不完全性である。例えば、リレーショナルスキーマは、実際にはデータベース内に存在している関係のいくつかを欠いている場合がある。残念なことに、データベース設計者が関係を一次キー（ＰＫ）−外部キー（ＦＫ）の制約条件として正式に定義しないのが通例である。外部キー自体は子のテーブル内にも存在しているが、スキーマ内ではそのようなものとしてマークされていない。しかし、開示されているマッピングアーキテクチャでは、一次／外部キーの関係は好ましいものであり、したがって定義する必要がある。他の一般的事例として、一次キーがテーブルに対して一次キーとしてマークされていない場合があげられる。

ときには、カスタム関係をスキーマに追加したい場合もある。例えば、「Ｊ」で始まるＶＩＮ番号を持つすべての自動車は、関係「ｍａｄｅ ｉｎ」を持つ「Ｃｏｕｎｔｒｉｅｓ」テーブル内の「Ｊａｐａｎ」エントリに対応している。最悪の場合のシナリオでは、リレーショナルスキーマファイルは編集することが許されていないため、何らかの点でスキーマファイル内に欠けている概念を定義するためマッピングファイル４００内に場所が必要である。

ソースおよびターゲット記述コンポーネント（４０６および４０８）は、これ以降、「ＤａｔａＳｏｕｒｃｅ」要素に対応しているものとする。

マッピングの意味−リレーショナルモデル（ドメイン）
リレーショナルドメイン内のマッピング可能な構造は、カスタムテーブル（ＣｕｓｔｏｍＴａｂｌｅと表す）である。カスタムテーブルは、列／フィールドおよびコマンドの集合体から作成される。カスタムテーブルは、物理的テーブル、ビュー、ＵＤＦまたはストアドプロシージャ、ＳＱＬステートメント（クエリの結果セット）、およびフィルタ処理されたテーブル（条件が適用されたテーブル）などの物理的リレーショナル構造のうちの１つを表すことができる。データベーステーブルはすべてカスタムテーブルであることに注意されたい。ユーザがデータベーステーブルを参照する場合、バックグラウンドでマッピングによりカスタムテーブルが透過的に作成される。それぞれのカスタムテーブルには、Ｑｕｅｒｙ、Ｕｐｄａｔｅ、Ｉｎｓｅｒｔ、およびＤｅｌｅｔｅの４つのコマンドが用意されている。これらのコマンドは、ユーザが明示して作成することも、またマッピングエンジンにより自動的に作成することもできる。カスタムテーブルがデータベーステーブルに基づいている場合、これは、データベーステーブルの関係を継承する（これは、反対方向では生じない）。

カスタムテーブルがマッピングされる毎に、関係ドメイン内に１組のインスタンス（レコードセット、行セットなどとも呼ばれる）を作成する。ユーザが別のマップで作成される１組のインスタンスにマッピングしたいか明示的に識別していない限り、マッピングにより、カスタムテーブルがマッピングされる毎に新しい１組のインスタンスが作成される。

関係−リレーショナルドメイン
２つのカスタムテーブルの間の関係を定義することができる。通常のテーブルに基づくカスタムテーブルは、基本テーブルからすべての関係を継承する。つまり、基本テーブルと他のテーブルとの間には、すでに類似の関係が存在しているため、ユーザ側でカスタムテーブルと他のテーブル（または他のＣｕｓｔｏｍＴａｂｌｅ）の間の関係を作成する必要はないということである。しかし、基本テーブル同士の間に類似の関係がすでに存在しているカスタムテーブル同士の関係を作成しても誤りではない。このような関係を作成するのは、冗長であり、ユーザは基本テーブルに基づく関係を再利用することができる。

関係を継承する一例として、複数のターゲット構造を列の値に基づき同じテーブルから作成することができる単一テーブル継承の事例をあげることができる。次に図５を参照し、ソースドメイン５００とターゲットドメイン５０２の間のマッピングを考察する。ソースドメイン５００は、Ｄｅｐａｒｔｍｅｎｔテーブル５０４とＥｍｐｌｏｙｅｅｓテーブル５０６を含む。Ｄｅｐａｒｔｍｅｎｔテーブル５０４とＥｍｐｌｏｙｅｅｓテーブル５０６の間の関係５０８を定義する。Ｅｍｐｌｏｙｅｅｓテーブル５０６には、Ｄｅｐａｒｔｍｅｎｔｓテーブル５０４からの外部キーがあり、ターゲットドメイン５０２内に類似の関係が構成される。Ｅｍｐｌｏｙｅｅｓテーブル５０６には、３つの値「Ｍ」、「ＨＥ」、および「ＳＥ」を格納するＥｍｐｌｏｙｅｅＴｙｐｅという名前の列がある。ソースドメイン５００からターゲットドメイン５０２へのマッピングの定義では、ターゲットドメイン５０２内でＤｅｐａｒｔｍｅｎｔｓテーブル５０４をＤｅｐａｒｔｍｅｎｔテーブル５１０にマッピングし、「Ｍ」値５１２をＭａｎａｇｅｒテーブル５１４（Ｍ→Ｍａｎａｇｅｒ）にマッピングし、「ＨＥ」値５１６をＨｏｕｒｌｙＥｍｐｌｏｙｅｅテーブル５１８にマッピングし（ＨＥ→ＨｏｕｒｌｙＥｍｐｌｏｙｅｅ）、「ＳＥ」値５２０をＳａｌａｒｙＥｍｐｌｏｙｅｅテーブル５２２にマッピングする（ＳＥ→ＳａｌａｒｙＥｍｐｌｏｙｅｅ）。ソースドメイン５００内の外部キー関係５０８があるため、ターゲットドメイン５０２のＤｅｐａｒｔｍｅｎｔテーブル５１０はＭａｎａｇｅｒテーブル５１４、ＨｏｕｒｌｙＥｍｐｌｏｙｅｅテーブル５１８、およびＳａｌａｒｙＥｍｐｌｏｙｅｅテーブル５２２にリンクする。

外部キーは、ソーステーブルとターゲットテーブルのデータの間のリンクを確立し、強制するために使用される列または列の組合せである。このリンクは、ターゲットテーブルに一次キー値を保持するソーステーブル内の１つまたは複数の列を追加することによりソーステーブルとターゲットテーブルの間に作成される。これらの列は、ターゲットテーブル内の外部キーとなる。

図５の例では、３つのカスタムテーブルＣＴａｂｌｅ（５１２、５１６、および５２０）はＤｅｐａｒｔｍｅｎｔｓテーブル５０４からＥｍｐｌｏｙｅｅｓテーブル５０６に継承されるため、それらのカスタムテーブル（５１４、５１８、および５２２）とＤｅｐａｒｔｍｅｎｔｓテーブル５０４との間の明示的関係を作成する必要はないが、作成する可能性はあり、作成しても誤りではない。基本テーブル（Ｅｍｐｌｏｙｅｅｓ５０６）上の関係５０８はカスタムテーブル（例えば、カスタムテーブル５１４）により共有されるので、ユーザはそのカスタムテーブル５１４と他のテーブルとの間の関係をさらに定義することができる。

以下の規則は、テーブルに基づくカスタムテーブルについて関係をどのように共有するかを説明している。物理的テーブルとカスタムテーブルとの間にマップが存在し、それら２つの間の関係が参照される場合、カスタムテーブルとテーブルとの間の関係は、物理的テーブルとカスタムテーブルが基づいている物理的テーブルとの間の関係であるものとして考えられる。それと反対のことは機能しない、つまり、２つのカスタムテーブルが関係を持つ場合、それらのカスタムテーブルが基づく物理的テーブルはこの関係を共有しないということに注意されたい。２つのカスタムテーブルの間にマップがある場合、参照される関係はカスタムテーブル１とカスタムテーブル２との間の関係、またはカスタムテーブル１とカスタムテーブル２の基本テーブルの間の関係、またはカスタムテーブル１の基本テーブルとカスタムテーブル２の間の関係、またはそれが２つの基本テーブルの間の関係である。

リレーショナルドメイン内の関係は、ＲＳＤ（Ｒｅｌａｔｉｏｎａｌ Ｓｃｈｅｍａ Ｄｅｆｉｎｉｔｉｏｎ）のリレーショナル要素を使用して定義される。関係は、データベースで定義されている物理的外部キー制約またはマッピングのニーズに関する関係の新しい定義に基づくことができる。それぞれの関係は、明確に参照できるように一意的な名前を持たなければならない。以下の例を考察する。

関係は名前により明示的に参照されるため、リレーショナルドメインは、それぞれの関係は異なる１組のＣｏｌｕｍｎＪｏｉｎｓを持つということで区別されるテーブルの同じペアの間で複数の関係を定義することができる。関係要素は、リレーショナルドメインにおけるオペレーション、つまりクエリオペレーションに対するカスタムテーブル間の結合、関連するカスタムテーブルにまたがって更新オペレーションを次から次へと実行するかどうか、更新オペレーションの順序（最初にどのテーブルから削除するかなど）、および更新オペレーションが関係のカーディナリティ（ｃａｒｄｉｎａｌｉｔｙ）とマッチすることのバリデーションをマッピングエンジンで実行するために必要なすべての情報を供給する。

マッピングの意味−オブジェクトドメイン
オブジェクトドメインは、型（クラス）をマッピングを行うためのマッピング可能な構造として公開する。型は、パス表現に基づいてグローバルまたはローカルに関して識別することができる。例えば、Ｔａｒｇｅｔ＝“Ａｄｄｒｅｓｓ”はグローバルクラス「Ａｄｄｒｅｓｓ」を意味するが、Ｔａｒｇｅｔ＝“Ｃｕｓｔｏｍｅｒ／Ａｄｄｒｅｓｓ”はＣｕｓｔｏｍｅｒクラスのフィールドであるＡｄｄｒｅｓｓクラスを意味する。それぞれの型（グローバルまたはローカル）は、リレーショナルドメイン内のただ１つのカスタムテーブルに直接マッピングすることができる（Ｍａｐ要素を使用して）。型は、他の型のメンバを含んでいてもよい、つまり、型マッピングに基づいて作成されたその型のインスタンスを参照しているということである。参照は、オブジェクト関係情報に基づいて作成される。

オブジェクトドメインの型マッピングの意味は、ソースドメイン内のマッピングされたセットの既存のインスタンスに対しオブジェクトドメイン内の型の最大１つのインスタンスが作成され、オブジェクトドメイン内の関係情報に基づきその型への参照をいくつでも作成することができることである。この点を明らかにするために、顧客はアドレスクラス型である「ＭｙＡｄｄｒｅｓｓ」と呼ばれるメンバを持つ顧客およびアドレスクラスを考察する。顧客クラスは、Ｃｕｓｔｏｍｅｒｓテーブルにマッピングされ、アドレスクラスは、アドレステーブルにマッピングされる。ユーザが「Ａｄｄｒｅｓｓ」クラスを取り出すためにマッピングを通じてクエリを発行する場合、同じＩＤを持つＡｄｄｒｅｓｓオブジェクトがすでに存在していない限り、クエリ条件に基づきこのクラスの新しいインスタンスが作成される。ユーザが「Ｃｕｓｔｏｍｅｒ」クラスを取り出す他のクエリを発行し、スパンは「ＭｙＡｄｄｒｅｓｓ」プロパティを含む場合、オブジェクトストア内にすでにインスタンスがなければ「ＭｙＡｄｄｒｅｓｓ」メンバに対し新しいＡｄｄｒｅｓｓオブジェクトが作成される。まず、このインスタンスをオブジェクト空間コンテキスト（オブジェクトドメイン）により管理される「Ａｄｄｒｅｓｓ」オブジェクトコレクションに追加する。次に「ＭｙＡｄｄｒｅｓｓ」フィールドは、「Ａｄｄｒｅｓｓ」インスタンスへの参照により更新される。

マッピングの意味−ＸＭＬモデル（ドメイン）
ＸＭＬドメインは、要素をマッピング構造として、要素および属性をマッピングフィールドとして公開する。以下の理由から、ＸＭＬスキーマの型定義は無視され、マッピング構造とみなされない。ＸＭＬスキーマは、名前付き型と無名型の両方を備える。無名型をマッピングするには、ユーザ側でパス表現を使用することによりそれらの型を識別する必要がある。ＸＭＬドメインでは、ドキュメント内に型があればそれに対し新しいコピーが作成される。なぜなら、オブジェクトドメインとは異なり、ＸＭＬドメインには、その型に基づいてＸＭＬデータを管理するＸＭＬドキュメントストアがなく、すでに作成されている型のインスタンスへの参照が作成されるからである。このようなＸＭＬキャッシュをそのようなストアにできるようにするため、ＸＭＬドメインをマッピングするには、ＸＭＬスキーマにはっきり基づいていない場合にメタデータを追加することで型を明確に定義する必要がある。

型名および要素名は、２つの異なる値空間内にあり、マッピングでは型名と要素名とを区別することができる。

ＸＳＤスキーマ上のＸＰａｔｈのサブセットを使用して、マッピングすることができるインスタンスを識別する。マッピング構文では、オブジェクトドメイン内の型に基づくマッピングだけでなくＸＭＬドメイン内のマッピングをもサポートする。

マッピング要素および属性
マッピングの構文は、マッピング設計セクションでレイアウトされているマッピングの設計および主要事項をサポートするように設計されている。マッピングスキーマの形式は、ＸＭＬとなるように選択されている。ＸＭＬ形式では、マッピングする顧客はＸＭＬ ＡＰＩを使用してマッピングファイルを作成、維持することができ、また人間によって可読性がよく（ｈｕｍａｎ ｒｅａｄａｂｌｅ）、マッピングエンジンではＸＭＬスキーマを使用してマッピングファイルのバリデーションを実行することができる。

以下では、１つまたは複数の要素および属性からなるＣｕｓｔｏｍｅｒｓ−Ｏｒｄｅｒｓのマッピングの完全なマッピング例を示している。

ＣｕｓｔｏｍｅｒおよびＯｒｄｅｒはクラスであり、ＣｕｓｔｏｍｅｒクラスはプロパティＭｙＯｒｄｅｒｓを有し、ＯｒｄｅｒクラスはプロパティＭｙＣｕｓｔｏｍｅｒを有するオブジェクトスキーマがマッピングされると仮定すると、マッピングセクションは以下のように変わる。

ＭＡＰＰＩＮＧＳＣＨＥＭＡ要素
ＭａｐｐｉｎｇＳｃｈｅｍａは、マッピングスキーマのルート要素である。これは、有効であるべきＭａｐｐｉｎｇｓおよびＤａｔａＳｏｕｒｃｅｓ要素を含んでいなければならない。ＭａｐｐｉｎｇＳｃｈｅｍａは、メタデータセグメンテーション規則に基づいてセグメント分割できる。マッピング形式はＸＭＬドキュメントである。これは、単一のルート要素ＭａｐｐｉｎｇＳｃｈｅｍａを有する。マッピングファイルには、ソースおよびターゲットのデータソースの記述、それらの間のマッピング、およびマッピングスキーマに渡すことができるパラメータの多数の定義が含まれる。したがって、ルート要素は、ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒｓ、ＤａｔａＳｏｕｒｃｅｓ、およびＭａｐｐｉｎｇｓの下位要素（ｓｕｂ−ｅｌｅｍｅｎｔ）を有する。ＤａｔａＳｏｕｒｃｅｓまたはＭａｐｐｉｎｇｓ下位要素を含まないマッピング要素は、それでも、有効なマッピングスキーマである。このようなマッピングスキーマに対してクエリおよび更新を実行する動作は、そのスキーマを使用する特定の実装により決定される。ユーザは、通常、この要素上ですべての名前空間を定義しなければならない。この要素には、属性はない。これらの下位要素の順序は重要であり、以下の表に示されているように順序付けなければならない。

例：

ＤＡＴＡＳＯＵＲＣＥ要素
ＤａｔａＳｏｕｒｃｅ要素は、マッピングされたデータソースのスキーマ情報を保持する。データソースは、スキーマの様々なセグメントを表す複数のスキーマファイルを収めることができる。この要素は、仮想ＳＱＬサーバを表す。

属性：

下位要素：

Ｓｃｈｅｍａ要素またはＩｎｌｉｎｅＳｃｈｅｍａ要素のいずれが存在していなければならないが、そのうちの１つだけである。例については、マッピングファイルを参照されたい。Ｓｃｈｅｍａ／ＩｎｌｉｎｅＳｃｈｅｍａ要素は、有効なＲＳＤを指していなければならない。

ＤＡＴＡＴＡＲＧＥＴ要素
この要素は、マッピングされたターゲットドメインのスキーマ情報を保持する。これらの拡張要素を使用することにより、情報をドメインスキーマに追加する機能が提供される。これは、スキーマを編集できない場合、またはスキーマがマッピング専用に作成されなかった場合に役立つ。ターゲットスキーマは、セグメント分割できる。

属性：

下位要素：

異なるドメインからのターゲットドメインスキーマのセグメントを含んでいると誤りである。例えば、ＸＭＬスキーマおよびＯｂｊｅｃｔスキーマを混合すると誤りである。

例については、マッピングファイルの例を参照されたい。

ＳＣＨＥＭＡ要素
Ｓｃｈｅｍａ要素は、データソースのスキーマを定義するためにＤａｔａＳｏｕｒｃｅ要素内で使用される。スキーマは、インラインで定義することも、別のファイルで定義することもできる。スキーマが別のＸＳＤ、ＲＳＤなどのファイル（ほとんどのシナリオではこのケースである）で定義されている場合、Ｓｃｈｅｍａ要素を使用しなければならない。ＩｎｌｉｎｅＳｃｈｅｍａ要素は、スキーマドメインの名前空間内でスキーマをインライン（Ｓｃｈｅｍａ要素の本体に含まれる）で定義する場合に使用される（ＸＭＬデータソースに対するＸＳＤなど）。この要素の下位要素はない。以下の属性が重要である。

例：

ＩＮＬＩＮＥＳＣＨＥＭＡ要素
Ｓｃｈｅｍａ要素は、データソースのスキーマを定義するためにＤａｔａＳｏｕｒｃｅ要素内で使用される。ＩｎｌｉｎｅＳｃｈｅｍａ要素は、スキーマドメインの名前空間内でスキーマをインライン（Ｓｃｈｅｍａ要素の本体に含まれる）で定義する場合に使用される（ＸＭＬデータソースにはＸＳＤなど）。この要素には、属性はない。この要素には下位要素はない。この要素の本体はスキーマ定義（ＸＳＤ、ＲＳＤ、またはＯＳＤ）を含む。

例：

ＲＥＬＡＴＩＯＮＳＨＩＰＭＡＰ要素
ＲｅｌａｔｉｏｎｓｈｉｐＭａｐは、ＳｏｕｒｃｅドメインとＴａｒｇｅｔドメイン内の関係をマッピングする方法に関する情報を供給するＭａｐ要素の子要素である。ターゲットドメインとソースドメインの両方において一方の構造から他方の構造へ移動するときに使用する関係を識別するために必要である。このセクションでは、マッピングスキーマにおけるこの要素の構文、意味、およびバリデーションについて説明する。読者は、ＲｅｌａｔｉｏｎｓｈｉｐＭａｐの概念に精通していなければならない。ＲｅｌａｔｉｏｎｓｈｉｐＭａｐ要素は、ターゲットドメイン内で、異なるソース構造にマッピングされている２つのマッピングされた構造間の関係が存在する場合に必要である（「マッピングされた構造」とは、「Ｍａｐ」要素を使用してマッピングされた構造を意味する）。このような関係の例として、その型が他のマップ（Ｏｂｊｅｃｔ）内にマッピングされるオブジェクトのフィールド／プロパティおよび他のマッピングされたＸＭＬ要素（ＸＭＬ）の子であるＭａｐｐｅｄ ＸＭＬ要素がある。

ＲｅｌａｔｉｏｎｓｈｉｐＭａｐは関係する両方のマップに関してＳｏｕｒｃｅおよびＴａｒｇｅｔとマッチしていなければならないことに注意されたい。以下では、どのようにこのプロセスが働くか、２つのターゲット構造の間に関係が存在すること（上の例を参照）、これら２つのターゲット構造は２つのＭａｐ（２つのＭａｐ要素）によりマッピングされ、これらのＭａｐ上の適用すべきＳｏｕｒｃｅｓはＲｅｌａｔｉｏｎｓｈｉｐＭａｐにおいてＳｏｕｒｃｅとして指定された有効な関係を有することを説明する。

他のソースにマッピングされた継承またはフィールドなどのターゲットドメイン内の他の種類の関係は、異なるマッピング属性を通じて処理されることに注意されたい（継承に対するＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐおよびＦｉｅｌｄＭａｐ上のフィールドにはＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐ）。

場合によってはマッピングエンジンはターゲットドメイン内の関係を識別し、（マッピングされているソース（テーブル）の間の）ソースドメイン内のマッチする関係を見つけることによりＲｅｌａｔｉｏｎｓｈｉｐＭａｐを推論することができるが、ＲｅｌａｔｉｏｎｓｈｉｐＭａｐは２つの理由から明示されている必要がある。まず、明示的なＲｅｌａｔｉｏｎｓｈｉｐＭａｐは、関係をＲＳＤに追加してもマッピングが壊れないことを意味している。マッピングエンジンがＲｅｌａｔｉｏｎｓｈｉｐＭａｐを推論し、ＲＳＤにＲｅｌａｔｉｏｎｓｈｉｐが追加された場合、追加された関係は単一の関係を持つように使用される２つのマッピングされたテーブル間の関係である可能性があるためマッピングを中断する可能性がある。関係を追加した後、マッピングエンジンはどの関係を選択するかを知らないため、例外を投げることになる。第２に、（ＲｅｌａｔｉｏｎｓｈｉｐＭａｐを推論することにより）「マジック」を実行し、上の例のようにあいまいな関係が見られる場合に例外を投げる代わりに、ユーザにマッピングという３つの単純な概念をすべて理解することを義務づけると使い勝手が高まる。

ＳｏｕｒｃｅはＳｏｕｒｃｅ（リレーショナル）ドメイン内の有効な関係でなければならない。このバリデーションは、ソーススキーマのすべてのセグメントがロードされた後に実行される。

Ｔａｒｇｅｔは、マッピングされたターゲットとの関係を持つターゲットドメイン内の有効な構造でなければならない。Ｔａｒｇｅｔは、ターゲットドメイン内の関係するマッピングされた構造の名前でなければならない。他のマップ内でマップされていない、または親のＭａｐ上でＴａｒｇｅｔとの関係を持たない構造（Ｔｙｐｅ、Ｅｌｅｍｅｎｔ）に対し名前を指定すると誤りである。ＸＭＬドメインでは、Ｔａｒｇｅｔは親マップ上のＴａｒｇｅｔである要素の子でなければならない。親マップは、ＲｅｌａｔｉｏｎｓｈｉｐＭａｐが含まれているＭａｐを参照する。このバリデーションは、マッピングキャッシュ上で実行される。

関係のリスト内で、親ＭａｐのＳｏｕｒｃｅは、リスト内の最初の関係の「Ｆｒｏｍ」または「Ｔｏ」のいずれかでなければならない。この規則により、第１の関係は親ＭａｐのＳｏｕｒｃｅを必ず含む。このバリデーションは、マッピングキャッシュ上で実行される。

関係のリスト内で、関係するＴａｒｇｅｔのＭａｐのＳｏｕｒｃｅは、リスト内の最後の関係の「Ｆｒｏｍ」または「Ｔｏ」のいずれかでなければならない。この規則により、最後の関係は関係するマップのＳｏｕｒｃｅを必ず含む。このバリデーションは、マッピングキャッシュ上で実行される。

Ｓｏｕｒｃｅが関係のリストであれば、そのリストは順序付けられていなければならない。それぞれの関係において、「Ｆｒｏｍ」または「Ｔｏ」は、次の関係の中の「Ｆｒｏｍ」または「Ｔｏ」とマッチしていなければならない。この規則により、テーブルが互いに結合されていないｊｏｉｎ句を持つのは適切でないため、その関係から構築されたＪｏｉｎ／Ｗｈｅｒｅ句は常に有効である。このバリデーションは、マッピングキャッシュ上で実行される。

２つのマッピングされているターゲット構造同士の関係をマッピングしなければならない。Ｓｏｕｒｃｅ属性を通じてソース構造にマッピングされているターゲットドメイン内で関係が定義されている２つのマッピングされたターゲット構造はＲｅｌａｔｉｏｎｓｈｉｐＭａｐを持たなければならない。「Ｒｅｆ」属性を通じてソース構造にマッピングされているターゲット構造との関係は、その関係のマッピングを必要としない。このバリデーションは、以下のアルゴリズムを使用して実行される。

マッピングされたターゲット構造毎に他のターゲット構造とのすべての関係を取得する。
｛
対応付けられたターゲット構造毎に
｛
ＩＦ（
関係するターゲット構造はマッピングされる
Ａｎｄ（ＸＭＬドメインにのみ適用し、Ｏｂｊｅｃｔについては無視する）
関係する構造は子要素であり、現在のターゲット構造マップは、「Ｒｅｆ」属性を使用してマッピングされない。
上のバリデーション規則に基づく有効なＲｅｌａｔｉｏｎｓｈｉｐＭａｐが存在することを確認する。
｝
｝
関係するターゲットの定義はターゲットドメインの意味によって異なることに注意されたい。このバリデーションは、マッピングキャッシュ上で実行される。

マッピングされた関係のＣａｓｃａｄｅＤｅｌｅｔｅ値は一致していなければならない（オブジェクトドメインについてのみ適用）。一致する値の許容可能行列は以下のとおりである。

任意の他の組合せは誤りである。このバリデーションは、マッピングキャッシュ上で実行される。
関係のカーディナリティ値は一致していなければならず、以下の表に示されている。

任意の他の組合せは誤りである。このバリデーションは、マッピングキャッシュ上で実行される。例については、標準形式の例を参照されたい。

ＭＡＰ要素
ソースドメインからのマッピングされた構造のインスタンスが存在すれば、マッピングされたターゲット構造のインスタンスがターゲットドメイン内に存在していなければならないというのがＭａｐ要素の意味である。Ｒｅａｄオペレーションでは、ソースドメイン内に存在するインスタンス毎にターゲットドメイン内の構造のインスタンスが作成される。Ｗｒｉｔｅオペレーションでは、Ｔａｒｇｅｔドメイン内のインスタンスについてこのオペレーションはＳｏｕｒｃｅドメイン内の既存のインスタンス上の等価なオペレーションに変換される。例えば、Ｍａｐ要素を使用してＣｕｓｔｏｍｅｒｓテーブルと顧客オブジェクトまたは要素との間のマッピングを考える。このようなＭａｐには、Ｃｕｓｔｏｍｅｒテーブル内の行毎にＣｕｓｔｏｍｅｒ Ｏｂｊｅｃｔが作成されるという意味がある。このような顧客オブジェクトを削除すると、Ｃｕｓｔｏｍｅｒｓテーブル内のちょうど１つの行が削除され、新しい顧客オブジェクトを作成すると、Ｃｕｓｔｏｍｅｒｓテーブルに１行挿入され、更新に対して類似のロジックが適用される。上述の既存の１：１マップに対する拡張およびオーバーライドのメカニズムは、ＲＳＤで指定されているＣｕｓｔｏｍＴａｂｌｅにより実現される。マッピングされたテーブル以外の何らかのテーブルに他のレコードを挿入するなどの副作用がありえる。ユーザは、他のテーブルのように各オペレーションタイプ（Ｒｅｔｒｉｅｖｅ、Ｉｎｓｅｒｔ、Ｕｐｄａｔｅ、およびＤｅｌｅｔｅ）に対応するコマンドを持つそのようなＣｕｓｔｏｍＴａｂｌｅにマッピングすることができる。コマンド毎に、ユーザは、ターゲットドメインで実行されるオペレーションに基づいてそのようなコマンドが呼び出されるときにマッピングエンジンにより実行されるＳＱＬ／ＳＰを指定することができる。このコマンドは、ターゲットドメイン内のインスタンス毎にちょうど１回だけ呼び出される（すべてのテーブルは、ａｕｔｏコマンドがｔｒｕｅに設定されているカスタムテーブルであることに注意されたい）。

同じソース構造を複数のマップで使用することができる。例えば、１つのテーブルを複数のオブジェクト型にマッピングする（ＣｕｓｔｏｍｅｒｓテーブルはＣｕｓｔｏｍｅｒオブジェクトおよびＣｕｓｔｏｍｅｒＩｎｆｏオブジェクトにマッピングされる）、または同じテーブルを複数のＸＭＬ要素にマッピングする（ＣｕｓｔｏｍｅｒｓテーブルはＣｕｓｔｏｍｅｒの上位要素にマッピングされ、Ｃｕｓｔｏｍｅｒ要素はＣｏｍｐａｎｙ要素の下にマッピングされる）という操作がある。このようなマッピングは、イテレータ（ｉｔｅｒａｔｏｒ）とも呼ばれる新しいセットがすべてのマップについてＳｏｕｒｃｅドメイン内に（クエリコマンドを使用して）作成されるという意味を持つ。ユーザは、Ｓｏｕｒｃｅの代わりにＲｅｆ属性を用意することにより同じセットを使用することができる。

属性：

下位要素：

Ｔａｒｇｅｔは、ＤａｔａＴａｒｇｅｔ内の有効な構造である。Ｔａｒｇｅｔドメイン内に存在しないターゲットを指すマップを持つのは誤りである。このバリデーションは、マッピングキャッシュ上で実行される。Ｓｏｕｒｃｅが存在している場合、ＤａｔａＳｏｕｒｃｅ内の有効な構造でなければならない。Ｓｏｕｒｃｅドメイン内に存在しないソースを指すマップを持つのは誤りである。このバリデーションは、マッピングキャッシュ上で実行される。

ターゲット構造は、１度しかマッピングできない。この規則により、マッピングを更新可能にすることができるが、それは、Ｔａｒｇｅｔ構造を１度しかマッピングできず、ターゲットドメイン内のその構造の任意のインスタンスは、あいまいなところなく、ソース（リレーショナル）ドメインに書き込むことができる。ユーザは、読み取りまたは書き込みの方向でターゲット構造を複数回マッピングしたい場合、ソース（リレーショナル）ドメイン内でＣｕｓｔｏｍテーブルを使用するとよい。このバリデーションは、マッピングキャッシュ上で実行される。

Ｍａｐ名は、マッピングスキーマ間で一意である。他のマップからこのマップにあいまいなところなく参照できるようにするには、Ｍａｐ名はマッピングファイルにまたがって一意である必要がある。ＲｅｆおよびＢａｓｅｄＯｎＭａｐなどの既存のＭａｐを参照する必要があるいくつかの機能性がある。このバリデーションは、マッピングキャッシュ上で実行される。

Ｒｅｆ属性は有効なＭａｐを指していなければならない。Ｒｅｆ属性の値は、マッピングスキーマ内の既存の有効なマップの名前でなければならない。このバリデーションは、マッピングキャッシュ上で実行される。ＲｅｆおよびＳｏｕｒｃｅ属性は相互排他的である。同じマップ上に複数のソースがあることは許されないため、このマップで他のマップからのＳｏｕｒｃｅを使用することを意味するＲｅｆ属性が、同じＭａｐ上のＳｏｕｒｃｅと共存することはできない。

ＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐ属性はＢａｓｅｄＯｎＭａｐがないと存在できない。ＲｅｆおよびＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐ属性は相互排他的である。Ｒｅｆ属性は、すでにスコープ内にあるＳｏｕｒｃｅ（イテレータ）を指しており、したがって関係を指定する必要はない。

Ｒｅｆは、Ｏｂｊｅｃｔ−Ｒｅｌａｔｉｏｎａｌマッピングには使用できない。Ｒｅｆ属性の意味は、オブジェクト−リレーショナルマッピングには適用されない。
例については、上述の完全なマッピングの例を参照されたい。

ＦＩＥＬＤＭＡＰ下位要素
ＦｉｅｌｄＭａｐ要素は、一方のドメインから他方のドメインに値をコピーするオペレーションを表す。マッピングエンジンは、単に、読み込み時にＳｏｕｒｃｅフィールドの値をＴａｒｇｅｔフィールドにコピーし、書き込み時にその逆の方向にコピーするだけである。場合によっては、これらの値は異なるＳｏｕｒｃｅ（テーブル）を出所としており、したがって、Ｓｏｕｒｃｅ／Ｒｅｆ／ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐ属性から、その値を取得する方法に関する必要な情報が得られる。ＦｉｅｌｄＭａｐを使用すると、ＮＵＬＬ値変換の定義および書き込みオペレーションの同時実行オプションの設定を行うことができる。

ＦｉｅｌｄＭａｐを使用すると、ターゲット側のデータを非正規化することができる。ターゲットフィールド（オブジェクト−フィールドなど）は、１度しかマッピングできない。しかし、ＳｏｕｒｃｅＦｉｅｌｄは、何度もマッピングできる。これは、ユーザがターゲットドメイン内のデータを非正規化したい場合のシナリオをサポートするために許容されている。ＯｒｄｅｒｓテーブルにはＣｕｒｒｅｎｃｙＩＤに対するフィールドが１つあり、Ｏｒｄｅｒオブジェクトには金額フィールド毎に、例えば、ＦｒｅｉｇｈｔＡｍｏｕｎｔとＦｒｅｉｇｈｔＣｕｒｒｅｎｃｙ、ＴａｘＡｍｏｕｎｔとＴａｘＣｕｒｒｅｎｃｙに対し１つの通貨フィールドがあるシナリオを考える。更新後、マッピングエンジン変更プロセッサ（ＣＰ）は、更新され、同じソースフィールドにマッピングされるターゲットフィールドが同じ値を持つことを検証する。

同じソースを持つ複数のＦｉｅｌｄＭａｐｓは、ユーザが同じセット（変数またはイテレータともいう）を参照していることを意味する。これは、最も単純で、最も直観的な動作であり、ユーザが同じ関係について異なるセットを使用したいシナリオはない。ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐを変更するということは、異なるキーに基づいて一方のテーブルを他方のテーブルに結合することが新しい結果セットを作成することを意味するので、新しいセットを意味することに注意されたい。これを明確にし、明示するため、この動作の意味は、すべてのＳｏｕｒｃｅが新しいセット（結果セット上のイテレータ）を意味するＭａｐの意味と異なっている。

属性：

ＳｏｕｒｃｅＦｉｅｌｄまたはＴａｒｇｅｔＦｉｅｌｄの値の先頭に「＄」が付いている場合、他のフィールド（ＳｏｕｒｃｅＦｉｅｌｄまたはＴａｒｇｅｔＦｉｅｌｄ）はＭａｐｐｉｎｇＰａｒａｍｅｔｅｒにマッピングされる。ＳｏｕｒｃｅＦｉｅｌｄがＭａｐｐｉｎｇＰａｒａｍｅｔｅｒである場合、これはＲｅａｄＯｎｌｙ ＦｉｅｌｄＭａｐであり、更新オペレーションが実行されていないことを意味する。ＳｏｕｒｃｅＦｉｅｌｄ／ＴａｒｇｅｔＦｉｅｌｄバリデーション：これらの属性の値は親Ｍａｐ Ｓｏｕｒｃｅ／Ｔａｒｇｅｔ構造上の有効なフィールドに、またはＭａｐｐｉｎｇＰａｒａｍｅｔｅｒにそれぞれ正常に解決されなければならない。これらの属性の値が「＄」符号から始まっている場合、これは、マッピングパラメータセクションで宣言されているマッピングパラメータに解決されなければならない。このバリデーションは、マッピングキャッシュ上で実行される。

Ｓｏｕｒｃｅ／Ｒｅｆ／ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐはソースドメイン内で有効でなければならない。Ｓｏｕｒｃｅはソースドメイン内の有効な構造（ＣｕｓｔｏｍＴａｂｌｅ）に解決されなければならず、Ｒｅｆは既存のマップの名前でなければならず、ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐはソースドメイン内の有効な関係の名前でなければならない。このバリデーションは、マッピングキャッシュ上で実行される。

Ｒｅｆおよび（Ｓｏｕｒｃｅ／ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐ）は相互排他的である。Ｒｅｆの意味は異なるマップからのＳｏｕｒｃｅであるため、そのソースは、スコープ内になければならず、ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐの必要はない。

ＳｏｕｒｃｅがＦｉｅｌｄＭａｐ上に存在する場合、ＭａｐｐｉｎｇではＭａｐのソースとＦｉｅｌｄＭａｐのＳｏｕｒｃｅとの関係がわかっている必要があるため、ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐが存在していなければならない。

ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐは、ＳｏｕｒｃｅがＦｉｅｌｄＭａｐ上に存在していなければ与えることができない。Ｓｏｕｒｃｅが存在していない場合、これは、ＳｏｕｒｃｅＦｉｅｌｄが親マップソース構造に属していることを意味する。したがって、関係情報を必要としない。

どの特定のターゲットフィールドも、１度しかマッピングできない。概念的には、両方のドメインのフィールドはスカラー値であり、したがって、ＳｏｕｒｃｅＦｉｅｌｄからＴａｒｇｅｔＦｉｅｌｄに値をコピーすることはあいまいであってはならず、マージの意味を持つことはできない。

ＳｏｕｒｃｅＦｉｅｌｄおよびＴａｒｇｅｔＦｉｅｌｄを両方ともマッピングパラメータとすることはできない。一方のＭａｐｐｉｎｇＰａｒａｍｅｔｅｒを他方のＭａｐｐｉｎｇＰａｒａｍｅｔｅｒにマッピングするのは無意味である。

ＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙは、ＳｏｕｒｃｅＦｉｅｌｄがＭａｐｐｉｎｇＰａｒａｍｅｔｅｒであれば指定できない。マッピングパラメータに関しては、適用できない。

ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐのカーディナリティ値は、ＴａｒｇｅｔＦｉｅｌｄ型と互換性がなければならない。ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐカーディナリティがＯｎｅＴｏＯｎｅである場合、ＴａｒｇｅｔＦｉｅｌｄ型はスカラーでなければならず、そうでない場合、誤りである。ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐカーディナリティがＯｎｅＴｏＭａｎｙである場合、ＴａｒｇｅｔＦｉｅｌｄ型はリスト型でなければならず、そうでない場合、誤りである。（オブジェクトマッピングでは、このケースはサポートされない）。このバリデーションは、コンパイル時にターゲットフィールドの型と関係のカーディナリティとの間の不整合を検出する場合、例えば、Ｃｕｓｔｏｍｅｒクラス上の「ｏｉｄ ｉｎｔ」型プロパティは、Ｃｕｓｔｏｍｅｒクラスと多対１の関係を持つＯｒｄｅｒｓテーブルのｏｄｅｒＩｄ列にマッピングされる場合に使用できる。

Ｒｅｆは、Ｏｂｊｅｃｔ−Ｒｅｌａｔｉｏｎａｌマッピングには使用できない。Ｒｅｆの意味は、オブジェクト−リレーショナルのマッピングには適用されない。例については、完全なマッピングの例を参照されたい。

ＯＶＥＲＦＬＯＷＭＡＰ下位要素
この要素は、常に「Ｍａｐ」要素に含まれ、Ｏｖｅｒｆｌｏｗをマップするために使用される。Ｏｖｅｒｆｌｏｗは、明示的にマッピングされない包含変数の中にある何かとして定義される。これは、アンマップされた属性および開いているコンテンツを持つＸＭＬ要素に使用される。この要素は、Ｏｂｊｅｃｔマッピングには適用できず、したがって、リレーショナルドメインとオブジェクトドメインの間でマッピングされるマッピングスキーマ内にこの要素を保持するのは誤りである。

Ｏｖｅｒｆｌｏｗ ＳｏｕｒｃｅＦｉｅｌｄは、Ｍａｐ ＴａｒｇｅｔＳｔｒｕｃｔｕｒｅ要素をルート要素としている有効なＸＭＬドキュメント（文字列として格納されている）を含まなければならない。クエリでマッピングを使用する場合、ルートノード上の属性は、ＴａｒｇｅｔＳｔｒｕｃｔｕｒｅ要素に追加され、下位要素は、その要素の子要素として追加される。

書き込みのシナリオに対しマッピングを使用する場合、ＴａｒｇｅｔＳｔｒｕｃｔｕｒｅ要素と同じ名前を持つＸＭＬ要素が作成され、スキーマ内にないか、またはマッピングされないその要素の属性はルート要素に追加される。マッピングされない、またはスキーマ内にない下位要素は、その要素のテキスト内容を含むその要素の子要素として追加される。

ユーザは、クエリを実行し、オーバーフローデータに更新することができ、この動作は融合（ｆｕｓｉｏｎ）として参照される。誤り状態は次のとおりである。

Ｑｕｅｒｙ−マッピングされた属性をオーバーフローフィールド（属性条件の複製を作成する）内に持つ。

Ｑｕｅｒｙ−ＴａｒｇｅｔＳｔｒｕｃｔｕｒｅ要素のテキスト内容をマッピングさせ、オーバーフローフィールドに含める。

属性：

この要素には、下位要素がない。

ＭＡＰＰＩＮＧＰＡＲＡＭＥＴＥＲ要素
マッピングパラメータの意味では、実行時に知られている値をソースまたはターゲットフィールドにマッピングできる。ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒは、ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒｓセクションで宣言され、マッピングＡＰＩを通じて実行時にアクセスすることができる。ＦｉｅｌｄＭａｐのＮｕｌｌＨａｎｄｌｉｎｇ設定はＭａｐｐｉｎｇＰａｒａｍｅｔｅｒにも適用される。ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒは、ＳｏｕｒｃｅＦｉｅｌｄまたはＴａｒｇｅｔＦｉｅｌｄのいずれかとして使用することができる。マッピングエンジンは、ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒ名の先頭に付いている＄プレフィックスに基づいてそれらを区別する。（＄は、すべてのマッピングされたドメイン、つまりオブジェクト、ＸＭＬ、およびＲｅｌａｔｉｏｎａｌ（エスケープできる）では識別子に使用すると不正文字となる）。ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒはアンタイプされ（ｕｎｔｙｐｅｄ）、したがってそのＸＳＤ型は文字列である。実行時に、マッピングエンジンはこの値をマッピングされたフィールド型の型に変換する（ターゲットフィールドまたはソースフィールドのいずれか）。

この要素のテキスト内容は、このパラメータのデフォルト値である。この値は、ＯｂｊｅｃｔＳｐａｃｅ、ＸＱｕｅｒｙＰｒｏｃｅｓｓｏｒ、Ｂｕｌｋｌｏａｄ、およびＸＭＬＡｄａｐｔｅｒなどのマッピングを使用するアプリケーションにより実行時に変更することができる。

属性：

ＳｏｕｒｃｅＦｉｅｌｄ／ＴａｒｇｅｔＦｉｅｌｄ／ＮｕｌｌＶａｌｕｅの値が「＄＄」で始まる場合、これはマッピングパラメータではないことを意味し、実際の値は単一の「＄」で始まる。ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒは、ＳｏｕｒｃｅＦｉｅｌｄ、ＴａｒｇｅｔＦｉｅｌｄ、またはＮｕｌｌＶａｌｕｅの値としてしか使用できない。マッピングエンジンは、そのフィールドマッピングに基づいてマッピングパラメータ値を与えることはできない。これらは、ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒはＳｏｕｒｃｅＦｉｅｌｄにマッピングされ、書き込みオペレーションで使用され、読み込みオペレーションでは無視されるというマッピングコンテキストで適用され、使用される。ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒは、ＴａｒｇｅｔＦｉｅｌｄにマッピングされ、読み込みオペレーションに使用され、書き込みオペレーションで無視される。したがって、ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒは、出力パラメータとして使用することはできない。

Ｂｕｌｋｌｏａｄでは、ユーザは何回も、データをＸＳＤスキーマに含まれないデータベースに挿入したい場合がある。このデータは、通常、実行時にしか判明せず、ＸＭＬドキュメントの一部として含まれない。例えば、ｕｓｅｒｉｄ、マシンＩＤなどがある。

ユーザは、マッピングスキーマにまたがって使用されるＮｕｌｌＶａｌｕｅを統一したい場合がある。これは、ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒを所定のデフォルト値で作成し、多くのＦｉｅｌｄＭａｐｓ内のＮｕｌｌＶａｌｕｅ属性の値においてこのマッピングパラメータを使用することにより実行される。

バリデーションに関しては、ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒの名前は文字「＄」で始まらなければならない。任意の他の文字があるとエラーになる。名前は、「＄＄」で始めることはできない。このため、ユーザが「＄」で始まる有効なドメインフィールド名を持つ場合、またはＮＵＬＬ値を「＄」として示したい場合に、「＄」記号をエスケープすることができる。

名前は、実行時にマッピングパラメータの値をソースまたはターゲットフィールドに割り当てるときに、あいまいさの発生を回避するためにマッピングスキーマ上で一意的でなければならない。名前の一意性はマッピングスキーマのロードされているすべてのセグメントにまたがるものであることに注意されたい。

ＢＡＳＥＤＯＮＭＡＰ−ＢＡＳＥＤＯＮＲＥＬＡＴＩＯＮＳＨＩＰ属性
設計ガイドラインとして、すべての必要なマッピング情報は、ドメインからではなく、マッピングファイル内のマッピングセクションから与えられる。したがって、継承および再帰では、ユーザは再帰要素および継承されたクラスフィールドをマッピングするための情報を明示的に供給する必要がある。ユーザは、「ＢａｓｅｄＯｎＭａｐ」属性を構文的なショートカットとして使用することにより、ＦｉｅｌｄＭａｐｓおよびＲｅｌａｔｉｏｎｓｈｉｐＭａｐｓを一方のＭａｐから他方のマップへコピーすることができる。これにより、マッピングエンジンは、Ｏｂｊｅｃｔ継承シナリオおよびＸＭＬ再帰シナリオにおいて、マッピング構文を明示し、ドメインから独立させることにより、ＦｉｅｌｄＭａｐｓおよびＲｅｌａｔｉｏｎｓｈｉｐＭａｐｓをコピーするのに必要な情報を取得することができる。ＢａｓｅｄＯｎＭａｐオプションでは、ＦｉｅｌｄＭａｐｓおよびＲｅｌａｔｉｏｎｓｈｉｐＭａｐｓをそのまま「ＢａｓｅｄＯｎＭａｐ」属性の値として名前が参照されるＭａｐからコピーする。コピーされたＦｉｅｌｄＭａｐｓ／ＲｅｌａｔｉｏｎｓｈｉｐＭａｐｓは、ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐ属性を含む基本のマップと同じである。

ＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐは、Ｍａｐ上のＳｏｕｒｃｅがＢａｓｅｄＯｎＭａｐが指定されているＭａｐ上のＳｏｕｒｃｅと異なる場合に使用される。したがって、すべての関連するソース情報および関係（ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐ、ＲｅｌａｔｉｏｎｓｈｉｐＭａｐ）を作成および更新する必要がある。ＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐ属性を指定すると、Ｓｏｕｒｃｅ属性はＢａｓｅｄＯｎＲｅｉａｔｉｏｎｓｈｉｐ属性の値とともにベースＭａｐおよびＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐで指定されているようにＳｏｕｒｃｅの値とともにコピーされたＦｉｅｌｄＭａｐｓに追加される。コピーされたＦｉｅｌｄＭａｐｓがすでに、Ｃｏｐｉｅｄ ＲｅｌａｔｉｏｎｓｈｉｐＭａｐに関して、ＳｏｕｒｃｅおよびＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐ属性を有する場合、これらの属性は新しいマップ上のソースとマップに基づくＳｏｕｒｃｅとの間の関係とともに更新される。

ＢａｓｅｄＯｎＭａｐおよびＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐの属性は両方とも、構文的ショートカットを使用可能にするマクロとして解釈することができる。以下の説明および規則では、ＢａｓｅｄＯｎＭａｐＶａｌｕｅ（ＢａｓｅｄＯｎＭａｐ属性によって指定された値）、およびＢａｓｅｄＲｅｌａｔｉｏｎｓｈｉｐＶａｌｕｅ（ＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐ属性によって指定された値）の２つのキーワードを使用する。

ＢａｓｅｄＯｎＭａｐの値は、ＦｉｅｌｄＭａｐのコピー元のＭａｐ名である。これは、単に、ＦｉｅｌｄＭａｐｓを、指されている名前付きＭａｐからＢａｓｅｄＯｎＭａｐが宣言されているＭａｐにコピーするだけである。すべての子ＦｉｅｌｄＭａｐｓおよびＲｅｌａｔｉｏｎｓｈｉｐＭａｐ要素をそのすべての属性とともに、名前がＢａｓｅｄＯｎＭａｐＶａｌｕｅであるＭａｐからＢａｓｅｄＯｎＭａｐ属性が指定されているＭａｐ要素にコピーする。

ＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐ属性とＢａｓｅｄＯｎＭａｐ属性。すべてのＦｉｅｌｄＭａｐ要素について、関連するＦｉｅｌｄＭａｐｓを見つけて更新する。名前がＢａｓｅｄＯｎＭａｐＶａｌｕｅであるＭａｐからすべての子ＦｉｅｌｄＭａｐｓ要素を見つける。ＦｉｅｌｄＭａｐｓ上にＳｏｕｒｃｅ属性が存在している場合には、値をそのままにしておき、そうでなければ、Ｓｏｕｒｃｅ属性を名前がＢａｓｅｄＯｎＭａｐＶａｌｕｅであるＭａｐ要素上のＳｏｕｒｃｅ属性の値とともにＦｉｅｌｄＭａｐｓに追加する。

ＦｉｅｌｄＭａｐｓ上にＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐ属性が存在する場合、ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐ属性の先頭に空白（“ ”）を挿入する。ＢａｓｅｄＲｅｌａｔｉｏｎｓｈｉｐＶａｌｕｅをＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐの先頭に挿入し、さもなければＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐ属性をＢａｓｅｄＲｅｌａｔｉｏｎｓｈｉｐＶａｌｕｅの値とともに追加する。

修正されたＳｏｕｒｃｅおよびＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐ属性および他の変更されていないそのままのすべての属性を持つすべてのＦｉｅｌｄＭａｐ要素をＢａｓｅｄＯｎＭａｐおよびＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐ属性が指定されているＭａｐ要素の中に入れる。

名前がＢａｓｅｄＯｎＭａｐＶａｌｕｅであるＭａｐからすべての子ＲｅｌａｔｉｏｎｓｈｉｐＭａｐ要素を見つけ、その属性をすべてそのままに維持する。すべてのＲｅｌａｔｉｏｎｓｈｉｐＭａｐ要素について、Ｓｏｕｒｃｅ属性の値の先頭に空白（“ ”）を挿入する。ＢａｓｅｄＲｅｌａｔｉｏｎｓｈｉｐＶａｌｕｅをＳｏｕｒｃｅ属性の先頭に挿入する。すべてのＲｅｌａｔｉｏｎｓｈｉｐＭａｐ要素を、修正されたＳｏｕｒｃｅ属性および他のすべての変更されていない属性とともにＢａｓｅｄＯｎＭａｐおよびＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐ属性が指定されているＭａｐ要素にコピーする。

上述の意味では、以下の規則が適用される。ＢａｓｅｄＯｎＭａｐは、有効なＭａｐ名を参照しなければならない。ＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐは、ソースドメイン内の有効なＲｅｌａｔｉｏｎｓｈｉｐ名を参照しなければならない。ＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐが指定されている場合、有効なＢａｓｅｄＯｎＭａｐが存在していなければならない。コピーされたＦｉｅｌｄＭａｐｓは、明示的に定義されている場合のように他のすべてのマッピング規則が適用される。

ＸＭＬ事例でのＢＡＳＥＤＯＮＲＥＬＡＴＩＯＮＳＨＩＰの使用例
表：
Employee(EID,FirstName,LastName,HireDate,Salary,Manager)
FiredEmployee(EID,FirstName,LastName,HireDate,Salary,Manager)
ＸＭＬでの結果の例：

マッピング：

マッピングエンジンで作成されたとおりの実際のＭａｐ：

テーブル階層間の継承（オブジェクト）
表：
Persons(SSID,FirstName,LastName)
Employees(EID,EmployeeSSID,HireDate,Salary,Manager)
Managers(EID,Bonus)

継承階層：Ｐｅｒｓｏｎ→Ｅｍｐｌｏｙｅｅ→Ｍａｎａｇｅｒ
マッピング：

マッピングエンジンで作成されたとおりの実際のマップ：

同じ基本テーブル（異なるカスタムテーブル）例（オブジェクト）を使用した継承
ＲＳＤ：

ＭＡＰ：

つまり、以下を意味する。

ＮＵＬＬＨＡＮＤＬＩＮＧ属性
値ＮＵＬＬは、列のデータ値が不明であるか、または使用可能でないことを意味する。ＮＵＬＬは、ゼロ（数値としても２進数値としても）、長さゼロの文字列、または空白（文字値）と同義でない。むしろ、ＮＵＬＬ値を使用した場合、ゼロ（数値列）または空白（文字の列）および非入力（数値と文字の両方の列についてＮＵＬＬ）を区別することができる。どの２つのＮｕｌｌ値も等しくはない。２つのＮＵＬＬ値の比較、またはＮＵＬＬと他の値との比較では、ｕｎｋｎｏｗｎを返すが、それは各ＮＵＬＬの値が不明だからである。ＮＵＬＬ値は、通常、不明な、適用できない、または後から付け加えるべきデータを示す。例えば、顧客のミドルイニシャルは、顧客発注時には知られていない可能性がある。ＮＵＬＬのマッピングは、値が不明であるので複合タスクであり、各ドメインはその概念（Ｎｕｌｌ）を異なった形で表現する。ときには、複数の異なる方法で表現することもでき、例えば、ＸＭＬドメインではＮｕｌｌをｘｓｉ：ｎｉｌ、なし（ａｂｓｅｎｃｅ）、または空リストで表現することができ、またオブジェクトドメインはＮＵＬＬ化可能型（ｎｕｌｌａｂｌｅ ｔｙｐｅｓ）、およびＤＢＮｕｌｌである、ＳＱＬ型を有する。さらに、ユーザは、Ｎｕｌｌを表すＴａｒｇｅｔドメイン内の値を選択したい場合があり、その値はＮｕｌｌイメージと呼ばれることが多い。

ＮｕｌｌＨａｎｄｉｎｇ属性を使用すると、Ｎｕｌｌをソースドメインからターゲットドメイン内のＮＵＬＬ表現に変換することができ、またその逆に変換することもできる（ターゲットドメイン内の値からソースドメイン内のＮＵＬＬに）。

Ｓをソース（リレーショナル）ドメイン内のＳｏｕｒｃｅＦｉｅｌｄとして、Ｔをターゲット（オブジェクト、ＸＭＬ）ドメイン内のＴａｒｇｅｔＦｉｅｌｄとして定義する。Ｓ（Ｎｕｌｌ）←→Ｔ（ＮｕｌｌＨａｎｄｌｉｎｇ属性に基づく値）。これは、クエリ時に、データベース（ＤＢ）内のＮｕｌｌはＮｕｌｌＨａｎｄｌｉｎｇ、ＮｕｌｌＶａｌｕｅ属性で指定された値に出力されることを意味する。更新時に、ターゲットドメイン内の値が上の属性で指定された値であれば、ターゲットドメイン内の値はソースドメイン内のｎｕｌｌに変換される。ターゲットドメイン内のＮｕｌｌ処理に対するデフォルトおよび特定の動作は、各ターゲットドメイン指定で設定される。

新しいターゲット構造（ＯｂｊｅｃｔまたはＸＭＬ要素）を作成し、フィールドにＮｕｌｌ値を割り当てる、またはＸＭＬ属性を省く場合、更新エンジンによるデフォルトの動作では、値は、列で定義されているデフォルト値に設定される。デフォルト値がない場合、Ｎｕｌｌが適用されることを意味する。

ＦｏｒｃｅＮｕｌｌＯｎＩｎｓｅｒｔは、ユーザが上述のデフォルト動作をオーバーライドしたい場合をサポートしている。この場合、ユーザは、更新エンジンがＮｕｌｌを明示的に列に書き込み、列で定義されていたデフォルトをオーバーライドすることを望んでいる。ＦｏｒｃｅＮｕｌｌＯｎＩｎｓｅｒｔ属性をＴＲＵＥに設定すると、オブジェクト／要素が作成されたときに、ターゲットドメイン内の任意のｎｕｌｌ値についてｎｕｌｌが明示的に列の中に挿入される。この特徴に対する主要なシナリオでは、ＮｕｌｌをＩｎｓｅｒｔストアドプロシージャ（カスタムテーブルのｉｎｓｅｒｔコマンドとして公開されている）のパラメータに受け渡すことを可能にする。

ＮｕｌｌＶａｌｕｅは、ＮｕｌｌＨａｎｄｌｉｎｇ値が「ＵｓｅＮｕｌｌＶａｌｕｅ」の場合に与えることができる。

ＮｕｌｌＶａｌｕｅとしての空白文字列−この例では、ユーザは顧客のミドルイニシャルプロパティに対しｎｕｌｌを意味する空文字列を指定したい。

ｎｕｌｌ処理にＤｏｍａｉｎＮｕｌｌを使用する−この例では、ＭＩは、ＸＭＬドメイン内の要素の名前である。

ＸＭＬは＜ＭＩ ｘｓｉ：ｎｉｌ＝“ｔｒｕｅ”／＞となる。

ＵＳＥＦＯＲＣＯＮＣＵＲＲＥＮＣＹ属性
この属性を必要とする背景にある理論と理由は、Ｏｐｔｉｍｉｓｔｉｃ Ｃｏｎｃｕｒｒｅｎｃｙドキュメントに明記されている。同時実行がＭａｐｐｉｎｇで指定され、ＲＳＤでは指定されていない理由は、特定のシナリオで、ユーザは異なる同時実行設定を好むことである。２つのクラスにマッピングされた非正規化されたテーブルを考える。これらのクラスには、同時実行制御に使用すべき異なるフィールドがある。一般に、人々は、そのビジネスロジックで推し進められる異なるマッピングで同じＲＳＤ情報を共有することを望む。ＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙ属性は列挙型であり、値は、Ａｌｗａｙｓ（このフィールドは常に同時実行に使用され、デフォルト値である）、Ｎｅｖｅｒ（このフィールドは同時実行には決して使用されない）、およびＭｏｄｉｆｉｅｄ（このフィールドは値が変更された場合のみ同時実行に使用される）である。

ＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙ属性は、ＦｉｅｌｄＭａｐとＭａｐの両方で使用することができる。デフォルトのメカニズムは以下のとおりである。ＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙが指定されていない場合、デフォルトは「Ａｌｗａｙｓ」である。ＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙがＭａｐ上で指定されている場合、ＦｉｅｌｄＭａｐまたはＲｅｌａｔｉｏｎｓｈｉｐＭａｐでＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙがすでに定義されていない限り、それはＭａｐに関わるすべてのＦｉｅｌｄＭａｐおよびＲｅｌａｔｉｏｎｓｈｉｐｓに対するＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙの値として使用される。この場合、定義済みの値はＭａｐ上で指定されているデフォルトをオーバーライドする。ＦｉｅｌｄＭａｐ上で指定されたＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙは、ＭａｐまたはＲｅｌａｔｉｏｎｓｈｉｐＭａｐのいずれかで定義されているＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙをオーバーライドする。

ユーザは、ＲｅｌａｔｉｏｎｓｈｉｐＭａｐ要素でＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙ属性を指定することにより明示的にマッピングされていない関係フィールドに対する同時実行設定を制御することができる。ＲｅｌａｔｉｏｎｓｈｉｐＭａｐ上で行ったこの属性の設定はすべての関係フィールドに適用されることに注意されたい。

バリデーションは以下のように働く。Ａｌｔｅｒｎａｔｅ Ｋｅｙ ＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙ＝Ａｌｗａｙｓであれば、これは同時実行に使用され、Ｐｒｉｍａｒｙ Ｋｅｙ同時実行は、他のフィールドとしてのデフォルト規則に基づいて判別される。さもなければ、Ａｌｔｅｒｎａｔｅ Ｋｅｙが存在していないか、ＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙ＝Ａｌｗａｙｓとマークされていない場合、Ｐｒｉｍａｒｙ Ｋｅｙ ＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙのデフォルトとしてＡｌｗａｙｓに設定される（マッピングエンジンは、Ｍａｐ ＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙ値を無視する）。一次キーＦｉｅｌｄＭａｐのＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙ値が明示的に他の値に設定された場合（ＮｅｖｅｒまたはＭｏｄｉｆｉｅｄのいずれか）、マッピングエンジンは例外を通る。

例：

マップは次のような内部表現で表される。

ＲＥＦ属性
Ｒｅｆ属性値はＭａｐの名前である。この属性の意味は、ターゲット構造またはターゲットフィールドが名前付きマップの同じＳｏｕｒｃｅにマッピングされるということである。「同じＳｏｕｒｃｅ」は、リレーショナルドメイン内のテーブルから選択されたセットを意味する。リレーショナルドメインの意味に基づき、マッピングエンジンは、テーブルがマッピングされる毎に新しいレコードセット（ｓｅｌｅｃｔステートメント）を作成する。ＸＭＬドメイン内の異端の（ｍａｖｅｒｉｃｋ）ケースなどの場合に、ユーザはすでに作成されているセットをターゲット構造またはフィールドにマッピングすることを望むことがある。ユーザが顧客注文を含む顧客要素を持つ以下のシナリオ（ＸＭＬドメインマッピングから抜粋）を考察する。Ｏｒｄｅｒ要素には、顧客名が含まれている。

リレーショナル構造は、ＭｙＢｕｙｅｒ Ｒｅｌａｔｉｏｎｓｈｉｐを含むＣｕｓｔｏｍｅｒｓおよびＯｒｄｅｒｓテーブルである。したがって、マッピングは以下のようになる。

これは、別のセットおよび結合を作成する必要がないため注文要素上で顧客名を取得する効率のよい方法である。ソースドメイン内の各構造（行）からマッピングにより複数のＸＭＬ要素が作成される場合があるため、Ｒｅｆ属性は、ＸＭＬドメインでのみ使用されることに注意されたい。さらに、この行からの値は、上の例に示されているように、ＸＭＬ階層内の子孫が選択することができる。

更新の意味
マッピングの強力な属性は、更新可能であるということである。オブジェクトまたはＸＭＬドメイン内の変更の同期をとりＳＱＬサーバドメインに伝えるため以前には大量のコードを書く必要があった多くの開発者は、マッピングエンジンに中継し、タスクを実行してもらうようにできる。ユーザは、ターゲットドメイン内の構造（オブジェクトまたはＸＭＬ要素）を作成、削除、または修正し、ターゲットドメインＡＰＩおよび以下のセクションではＣＰと呼ぶ変更プロセッサ（ＣＰ）と呼ばれるマッピングエンジンにより魔法を使ったようにソースドメインに対してそれらの変更の同期をとる（永続化する）。このセクションでは、ソースドメイン（リレーショナルデータモデル）内に永続化されているターゲットドメインの変更の意味を説明する。

以下の項は、上述のＥｘｉｓｔｅｎｃｅ、Ｃｏｐｙ、およびＭａｐｐｉｎｇ Ｒｅｌａｔｉｏｎｓｈｉｐｓのこれらの概念への追加である。

ターゲットユニット−Ｍａｐ要素を使用して同じソース構造にマッピングされるターゲットドメインからの構造または構造のグループ。ターゲット構造のグループは、Ｒｅｆ属性を使用して他のＭａｐを参照しているマップ上のターゲットである（Ｔａｒｇｅｔユニットは参照されているマップを含む）。これは、構造のこのようなグループ化が可能でなく、Ｍａｐ要素を使用してマッピングされる各オブジェクトがＴａｒｇｅｔユニットであるオブジェクトドメインと構造のそのようなグループを上述のように作成できるＸＭＬドメインとの間の鞍の差（ｓａｄｄｌｅ ｄｉｆｆｅｒｅｎｃｅ）である。

ソースユニット−ソースドメイン内の構造。リレーショナルドメインでは、ソースはＣｕｓｔｏｍＴａｂｌｅである。

変更ユニット−変更されたターゲットユニットにマッピングされたソースユニット。

ＣＰは、変更ユニットの関係を調べ、ソースドメイン内の関係するユニットに対し実行するオペレーション、オペレーションの順序、およびバリデーションを判別する。変更をターゲットとソースの両方のドメイン内の関係するユニットに適用して同期を維持する操作は非常に複雑である。ＲｅｌａｔｉｏｎｓｈｉｐＭａｐセクションのバリデーション規則により、必ず、ターゲットドメインに対する変更はソースドメイン上のＣＰにより適用される変更と衝突しない。

このセクションでは、ソースドメインスキーマ（ＲＳＤ）内の関係要素の意味を説明する。

ＦＲＯＭとＴＯ
「Ｆｒｏｍ」は、関係内の親ユニットであり、「Ｔｏ」は関係内の子ユニットである。ソースドメイン内のオペレーションの順序を判別するために、親ユニットと子ユニットとの区別が必要である。変更の種類（Ｉｎｓｅｒｔ、Ｄｅｌｅｔｅ、およびＵｐｄａｔｅ）を使用して、オペレーションの実行順序を判別する。Ｉｎｓｅｒｔ／Ｕｐｄａｔｅに対し、親は最初に実行され、Ｄｅｌｅｔｅに対し、子が最初に実行される。

ＣＡＳＣＡＤＥＤＥＬＥＴＥ／ＣＡＳＣＡＤＥＵＰＤＡＴＥ
変更をソースドメインに適用する場合、ＣＰは変更ユニットとその変更ユニットが親となっている他のマッピングされたソースユニットとの間のあらゆる関係を見つける。ＣａｓｃａｄｅＤｅｌｅｔｅ／ＣａｓｃａｄｅＵｐｄａｔｅの値により、オペレーションは子テーブルまたはそれ以外に影響を及ぼすかどうかを判別する。これらの属性の値では、ＣＰまたはＳＱＬ Ｓｅｒｖｅｒが子テーブル上で変更を実行するかどうかを決定する。

ＩＳＦＯＲＥＩＧＮＫＥＹを使用したユニット（テーブル）依存関係の計算
以下では、関係情報に基づいてテーブル内のテーブル依存関係および行依存関係（ユニット依存関係ともいう）を計算し更新エンジンＣＰの行実行順序を判別することの意味を説明する。ＣＰでは、親（Ｆｒｏｍ）と子（Ｔｏ）の情報および関係要素のＩｓＦｏｒｅｉｇｎＫｅｙ属性により表される外部キー制約の存在を利用して、この依存関係および更新ステートメントの実行順序を判別する。

以下は単純な階層であり、Ｃｕｓｔｏｍｅｒｓ→Ｏｒｄｅｒｓ→ＯｒｄｅｒＤｅｔａｉｌｓとなっており、循環参照はない。

以下は、１つの関係がサーバ上のＦＫ制約でない循環参照である（ＩｓＦｏｒｅｉｇｎＫｅｙ＝ｆａｌｓｅ）。これは、外部キー制約の少なくとも１つの関係はサーバ上で作成されないシナリオである。マッピングの順序は、Ａ→Ｂ→Ｃである。

以下は、すべての関係がサーバ上のＦＫ制約である循環参照である（ＩｓＦｏｒｅｉｇｎＫｅｙ＝ｔｒｕｅ）。このシナリオでは、関係はすべて、サーバ上の外部キー制約が課される。マッピングの順序は、Ｃ→Ａ→Ｂである。

または

コンパイル時に、「Ｆｒｏｍ」および「Ｔｏ」という方向属性は主に、テーブル依存関係を判別する場合に使用される。これにより、第１のシナリオのような単純なすべての階層型シナリオが解決する。他方、関係の方向により循環参照が生じる上の第２および第３のシナリオでは、サーバ上に実装されている外部キー制約（ＩｓＦｏｒｅｉｇｎＫｅｙ＝“ｔｒｕｅ”）を指していない関係を無視することにより依存関係を見つけ出そうとする。このようにして第２のシナリオを取り扱う。循環参照がそれでも存在している場合（つまり、すべて外部キー制約として実装されているため関係パスすべてが無視されるわけではない）、依存関係グラフはランダムに階層型ツリーに解決される（次のアルゴリズムのセクションで説明する）。

実行時に、第１のシナリオでＣｈａｎｇｅＵｎｉｔｓを受け取ると、それ以上オペレーションは必要でなく、コンパイル時依存関係グラフによる実行順序で実行される。しかし、第２および第３のシナリオの循環参照については、ＣｈａｎｇｅＵｎｉｔ．ＧｅｔＰａｒｅｎｔｓ（）を使用して実行時インスタンスを評価し、正しい実行順序を求める。ほとんどの場合、実行時インスタンスはグラフを形成せず、ＣｈａｎｇｅＵｎｉｔｓは階層方式で実行される（ＨａｒｏｏｎＡ→ＤａｎｉｅｌＤ→Ｆｏｏ→Ｂａｒ→ＢｉｌｌＧ）。しかし、実行時にインスタンスがグラフを形成する場合でも、コンパイル時依存関係に従ってユニットが実行される。これは、第２のシナリオの場合にうまくゆくが、すべての関係が外部キー制約を参照している第３のシナリオでは、サーバサイドの制約例外がＩｎｓｅｒｔおよびＤｅｌｅｔｅオペレーションに対し発生する。

ここでアルゴリズムを使用することで、すべてのシナリオに対するマッピングコンパイル時の依存関係を計算することができるが、第２および第３のシナリオの循環参照については実行時インスタンスは評価され優先権を与えられる。マッピング構文から一度計算されたすべてのユニットの依存関係情報は、すべてのソースユニットにそれぞれの相対的序数が割り当てられるコンパイル時マッピングにおいて配列に格納されることに注意すべきである。上述のように第３のシナリオの解決不可能な循環参照であっても、グラフはマッピングファイル内の出現順にランダムにツリーに細分される。このため、関係のないユニット間でも実行の決定論的順序が保証され、したがって特定の潜在的デッドロックのケースが回避される。

カーディナリティは、ＯｎｅＴｏＯｎｅおよびＯｎｅＴｏＭａｎｙのいずれかである。Ｍａｎｙ−ｔｏ−ｍａｎｙは意味に関してＯｎｅＴｏＭａｎｙと似ており、更新に関係する。「Ｍａｐ」要素上の「Ｓｏｕｒｃｅ」属性により指定されたソースユニットは、強いユニットと呼ばれ、基本の「ＦｉｅｌｄＭａｐ」要素で指定された他のすべてのソースユニットは弱いユニットと呼ばれる。カーディナリティ情報は、弱いユニットおよび強いユニットという概念と緊密に結びついている。ＯｎｅＴｏＭａｎｙでは、弱いユニットは読み取り専用と考えられる。

このようなシナリオの例としては、ＯｂｊｅｃｔＳｐａｃｅのＯｎｅ Ｔａｂｌｅ ｐｅｒ Ｔｙｐｅ継承と複数のテーブルにマッピングされたＣｕｓｔｏｍｅｒ ＸＭＬ要素（またはＣｌａｓｓ）（Ｃｕｓｔｏｍｅｒ、ＣｕｓｔｏｍｅｒＩｎｆｏ）がある。この場合、動作は強いユニットも弱いユニットも読み書きであり、弱いユニット行の存在は、強いユニット行の存在と結びついている。つまり、ターゲットユニットが挿入されると、１つの行が強いユニットに挿入されるだけでなく、対応する行もすべての弱いユニットに挿入されるということである。同様に、ターゲットユニットが削除されると、強いユニットおよび弱いユニット内の対応する行はすべて削除される。弱いユニットを参照する属性を削除することは、この列が強いユニットに属するか弱いユニットに属するかに関係なく対応する列内の値をＮＵＬＬ化するものとしてみなされる。特定の弱いユニットにマッピングされているすべてのターゲットフィールドが削除される場合でも、弱いユニット内の行は削除されないということを明確にする必要がある。弱いユニットからの行は、ターゲットユニットが削除される場合、強いユニットとのみ消される。このターゲットフィールドの削除シナリオは、ＸＬＭでしか存在せず、ＯｂｊｅｃｔＳｐａｃｅｓでは存在しないことに注意されたい。というのも、クラスのプロパティは削除できず、むしろＮＵＬＬ化できるだけだからである。

ＦｉｅｌｄＭａｐ上のＲｅｆ属性に関して、ＦｉｅｌｄＭａｐで「Ｒｅｆ」属性を使用して複数のソースユニットをマッピングする場合、更新の意味はすべてのカーディナリティについて弱いユニットに関し読み取り専用である。これは、更新の意味を制御するために他のマッピングが存在することを意味する「Ｒｅｆ」属性の意味に適合している。読み取り専用の意味では、ターゲットが挿入されると、更新オペレーションは強いユニットに行を挿入するだけであり、弱いユニットに触れる（ｔｏｕｃｈ）ことはない。同様に、ターゲットが削除される場合、強いユニット上の行のみが削除される。同様に、弱いユニットを参照している属性が修正されると（更新／削除）、更新エンジン（ＣＰ）は例外を投げる。クライアント（ＯｂｊｅｃｔＳｐａｃｅｓ、ＸｍｌＣａｃｈｅなど）は、弱いユニット上の修正された変更をＣＰに与えないことにより動作を常にオーバーライドすることが可能である。このようにして、例外を発生することなく変更が無視される。

ソースの代わりにＲｅｆ属性を持つマップは、１つのユニットにまとめられ、主要マップ内にマッピングされているターゲット構造なしでは挿入も削除もできない。概念的には、これらは主要マップの一部である。このような動作である理由は、主要（ｍａｉｎ）マップは常に、個人キー情報を含むことを保証され、マッピングされる構造はマッピングされる構造の先祖でなければならず、したがって、そのマップの所有者構造とすることができる。

読み取り専用のＦｉｅｌｄＭａｐでは、ＣＰは読み取り専用ＦｉｅｌｄＭａｐ内にマッピングされているソースフィールドが変更されず、この場合エラーを投げることを確認する。ＣｕｓｔｏｍＴａｂｌｅ上の更新コマンドの現在のパラメータを読み取り専用ターゲットフィールドにバインドするのは誤りであることに注意されたい。

図６Ａを参照すると、マッピングコンポーネント６０２がネットワーク上に別々に配置されているソースのデータソース６０２とターゲットのデータソース６０４のネットワーク図が示されている。ソースのデータソース６０２とターゲットのデータソース６０４は両方とも、読み取り専用であるが、それでもマッピングが必要である。本発明では、マッピングコンポーネント６０６を使用して、ソース６０２からターゲット６０４へのマッピングを実行し、マッピングコンポーネント６０６のネットワークロケーションにいるユーザはそのマッピングを実行するようにマッピングコンポーネント６０６を構成する。これは、インターネットなどのグローバルな通信ネットワーク（ＧＣＮ）６０８を対象とすることができる。さらに、マッピングは、ＬＡＮ、ＷＡＮ、ＷＬＡＮ、ＷＷＡＮなどのネットワーク６０８上で実行することができる。このシナリオでは、顧客がマッピングオペレーションをベンダに実行してもらうために署名（ｓｕｂｓｃｒｉｂｅ）する実装が行いやすい。これは必須ではないがベンダは単純に、たぶんログイン情報を取得した後、ネットワーク６０８を介してソースおよびターゲットのデータモデルにアクセスし、マッピングオペレーションを実行するためにマッピングコンポーネント６０６を構成する。このシナリオではさらに、ＬＡＮ、ＷＡＮなどを介して顧客のマッピングオペレーションをサポートする。

次に図６Ｂを参照すると、マッピングコンポーネント６０６をソースロケーションまたはターゲットロケーション、またはその両方のロケーションに配置することができることを示しているネットワーク図６１０が例示されている。

次に図７を参照すると、開示されているアーキテクチャを実行する動作が可能なコンピュータのブロック図が例示されている。本発明の様々な態様の背景を示すために、図７および以下の説明では、本発明の様々な態様を実装できる適当な動作環境７００の概要を簡潔に説明する。本発明は、１つまたは複数のコンピュータで実行できる、コンピュータ実行可能命令の一般的な文脈において上で説明されているが、当業者であれば、本発明は他のプログラムモジュールと組合せかつ／またはハードウェアとソフトウェアとの組合せとして実装できることも理解するであろう。一般に、プログラムモジュールには、特定のタスクを実行する、あるいは特定の抽象データ型を実装するルーチン、プログラム、コンポーネント、データ構造などが含まれる。さらに、当業者であれば、本発明の方法が、シングルプロセッサまたはマルチプロセッサのコンピュータシステム、ミニコンピュータ、メインフレームコンピュータ、さらにはパーソナルコンピュータ、ハンドヘルドコンピューティングデバイス、マイクロプロセッサベースのまたはプログラム可能な家電製品などを含む、他のコンピュータシステム構成でも実施でき、それぞれ１つまたは複数の関連するデバイスに結合され動作可能であることを理解するであろう。本発明の例示されている態様は、通信ネットワークを通じてリンクされているリモート処理デバイスにより特定のタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、ローカルおよびリモートのメモリ記憶デバイスに置くことができる。

図７を参照すると、本発明の様々な態様を実装する環境例７００はコンピュータ７０２を含み、コンピュータ７０２は処理ユニット７０４、システムメモリ７０６、およびシステムバス７０８を含むことが示されている。システムバス７０８は、限定はしないが、システムメモリ７０６などのシステムコンポーネントを処理ユニット７０４に結合する。処理ユニット７０４は、様々な市販プロセッサのうちのどれでもよい。デュアルマイクロプロセッサおよびその他のマルチプロセッサアーキテクチャも、処理ユニット７０４として採用することができる。

システムバス７０８は、様々な市販のバスアーキテクチャを使用するメモリバスまたはメモリコントローラ、周辺機器バス、およびローカルバスを含む数種類のバス構造のうちのいずれかとすることができる。システムメモリ７０６は、読み取り専用メモリ（ＲＯＭ）７１０およびランダムアクセスメモリ（ＲＡＭ）７１２を含む。起動時などにコンピュータ７０２内の要素間の情報伝送を助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）は通常、ＲＯＭ７１０に格納される。

コンピュータ７０２は、ハードディスクドライブ７１４、磁気ディスクドライブ７１６（例えば、取り外し可能ディスク７１８との間で読み書きする）、および光ディスクドライブ７２０（例えば、ＣＤ−ＲＯＭディスク７２２を読み出したり、他の光媒体との間で読み書きを行う）をさらに含む。ハードディスクドライブ７１４、磁気ディスクドライブ７１６、および光ディスクドライブ７２０は、ハードディスクドライブインターフェイス７２４、磁気ディスクドライブインターフェイス７２６、および光ドライブインターフェイス７２８によりそれぞれシステムバス７０８に接続できる。ドライブおよびその関連コンピュータ可読媒体は、データ、データ構造体、コンピュータ実行可能命令などを格納する不揮発性記憶装置を実現する。コンピュータ７０２に関しては、ドライブおよび媒体は、適当なデジタル形式で放送番組を格納することに適応している。上述のコンピュータ可読媒体の説明では、ハードディスク、取り外し可能磁気ディスク、およびＣＤを取り上げているが、当業者であれば、ｚｉｐドライブ、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、カートリッジなどコンピュータにより読み取り可能な他の種類の媒体も動作環境例で使用することができること、さらに、そのような媒体は本発明の方法を実行するコンピュータ実行可能命令を含むことができることを理解するであろう。

多数のプログラムモジュールを、オペレーティングシステム７３０、１つまたは複数のアプリケーションプログラム７３２、その他のプログラムモジュール７３４、およびプログラムデータ７３６などのドライブおよびＲＡＭ７１２に格納することができる。本発明は、様々な市販のオペレーティングシステムまたはオペレーティングシステムの組合せで実装できることは理解されるであろう。

ユーザは、キーボード７３８およびマウス７４０などのポインティングデバイスを介してコマンドおよび情報をコンピュータ７０２に入力することができる。他の入力デバイス（図に示されていない）としては、マイク、ＩＲリモートコントロール、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどがある。これらの入力デバイスやその他の入力デバイスは、システムバス７０８に結合されているシリアルポートインターフェイス７４２を介して処理ユニット７０４に接続されることが多いが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（「ＵＳＢ」）、ＩＲインターフェイスなどの他のインターフェイスにより接続することもできる。モニタ７４４またはその他の種類の表示デバイスも、ビデオアダプタ７４６などのインターフェイスを介してシステムバス７０８に接続される。モニタ７４４の他に、コンピュータは通常、スピーカ、プリンタなどの他の周辺出力デバイス（図に示されていない）を含む。

コンピュータ７０２は、リモートコンピュータ７４８などの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク環境で動作することも可能である。リモートコンピュータ７４８は、ワークステーション、サーバコンピュータ、ルータ、パーソナルコンピュータ、携帯型コンピュータ、マイクロプロセッサベースの娯楽機器、ピアデバイス、またはその他の共通ネットワークノードなどでよく、通常は、コンピュータ７０２に関係する上述の要素の多くまたはすべてを含むが、簡単のため、メモリ記憶デバイス７５０のみが例示されている。説明されている論理接続は、ローカルエリアネットワーク（ＬＡＮ）７５２とワイドエリアネットワーク（ＷＡＮ）７５４を含む。このようなネットワーキング環境は、オフィス、企業全体にわたるコンピュータネットワーク、イントラネット、およびインターネットでは一般的なものである。

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

図８を参照すると、本発明によるコンピューティング環境例８００の概略ブロック図が示されている。システム８００は、１つまたは複数のクライアント８０２を含む。クライアント８０２は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）とすることができる。クライアント８０２には、例えば、本発明を採用することによりｃｏｏｋｉｅｓおよび／または関連するコンテキスト情報を置くことができる。システム８００は、さらに、１つまたは複数のサーバ８０４を含む。またサーバ８０４は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）とすることもできる。サーバ８０４には、例えば、本発明を採用することにより変換を実行するスレッドを置くことができる。クライアント８０２とサーバ８０４との間の考えられる１つの通信は、２つまたはそれ以上のコンピュータプロセス間で伝送されるように適合されたデータパケットの形で実行できる。データパケットは、例えば、ｃｏｏｋｉｅおよび／または関連するコンテキスト情報を含むことができる。システム８００は、クライアント８０２とサーバ８０４との間の通信を円滑にするために採用することができる通信フレームワーク８０６（例えば、インターネットなどのグローバル通信ネットワーク）を含む。通信は、有線（光ファイバを含む）および／または無線技術を介して円滑化することができる。クライアント８０２は、クライアント８０２のローカルにある情報を格納するために使用することができる１つまたは複数のクライアントデータストア８０８に接続し動作させることができる（例えば、ｃｏｏｋｉｅｓおよび／または関連するコンテキスト情報）。同様に、サーバ８０４は、サーバ８０４のローカルにある情報を格納するために使用することができる１つまたは複数のサーバデータストア８１０に接続し動作させることができる。

図９を参照すると、本発明によるディジーチェーン型のマッピング実装のブロック図が例示されている。開示されている新規性のあるマッピングアーキテクチャによりディジーチェーン型のマッピングシナリオの実装が容易になり、図１のシステム１００に似た複数の段９００はシリアル方式でソースデータモデルＳ_１（任意の構造の）からターゲットデータモデルＴ_Ｎ（任意の構造の）へ、必要な中間データ変換を行う多数の中間ステージを使用し、最終的にターゲットデータモデルＴ_Ｎ（送り先）で望むデータ形式を利用できるようにすることは理解されるであろう。このコンテキストでのステージ９００は、ソースモデルＳ、マッピングコンポーネントＭ、およびターゲットデータモデルＴを含むように表されている。ディジーチェーンで複数のステージ９００を接続する場合、中間ターゲットデータモデルＴ１はさらに、後のステージ９０２のデータソースＳ２でもある。したがって、中間データモデル（例えば、Ｔ１／Ｓ２）は、先行するステージ９００のマッピングコンポーネントＭ１のターゲットに対するＴ１と後続のステージ９０２の後続のマッピングコンポーネントＭ２のソースに対するＳ２の両方としてラベル付けされている。

データモデルは、限定はしないが、クエリ言語、データアクセス言語、データ操作言語、データ定義言語、オブジェクトモデル、リレーショナルモデル、およびＸＭＬモデルなどがある。

一実施例では、ソースデータモデルＳ１からターゲットデータモデルＴ２にデータをマッピングすることが目標である。ソースＳ１はリレーショナルデータ構造であり、ターゲットＴ２はＸＭＬデータ構造であると考える。さらに、ソースＳ１からターゲットＴ２へのパスは、オブジェクトベースのパスしか与えない。第１のステージのマッピングコンポーネントＭ１はソースＳ１に適切なリレーショナル記述コンポーネントを使用し、ターゲットＴ１にオブジェクト記述コンポーネントを使用して、ソースＳ１から中間ターゲットＴ１にマッピングする。次に、中間ターゲットＴ１はマッピングコンポーネントＭ２のソースＳ２ではない。次に、マッピングコンポーネントＭ２は、適切なオブジェクト記述コンポーネントおよびＸＭＬ記述コンポーネントを使用してソースＳ２からターゲットＴ２へのマッピングを完了する。

このような機能を考えると、特定の応用ではステージをいくつでも（９００および９０２）を採用できることは理解されるであろう。

図１０を参照すると、本発明のマッピングアーキテクチャのハブ＆スポーク方式の実装を示している。この実装は、ネットワークの中断、使用可能な帯域幅などにより、任意の時点でデータパスを使用できるかどうかが決まる大規模なネットワーク環境、例えば、インターネットまたは大規模な企業ネットワークで特に有用である。データが移動しまたはクエリが実行される任意の数のデータソース（Ｓ１、Ｓ２、およびＳ３）および任意の数の中間データターゲット１００８（Ｔ／Ｓとも表されている）と通信している中央制御エンティティ１０００が用意される。最後に、マッピングはソース（Ｓ１、Ｓ２、およびＳ３）の１つからターゲットＴ２へのマッピングであるのが望ましい。

中央制御エンティティ１０００は、エンティティ１０００のすべての側面を制御する制御コンポーネント１００２を含み、これは、一方の種類のデータモデルから他方のデータモデル（例えば、リレーショナル、オブジェクト、ＸＭＬ、．．．）にデータを変換するためのアクセス可能な記述アルゴリズムを格納する記述コンポーネントリソース１００４、およびソース（Ｓ１、Ｓ２、およびＳ３）と中間ターゲット１００８との間でデータのルーティングまたはスイッチングを行うスイッチングメカニズム１００６を含む。

例えば、動作中に、第１の中間データソースターゲット１０１０からソースＳ１へのデータクエリが開始される。ソースＳ１のデータ構造はリレーショナルであり、ターゲット１０１０はＸＭＬである。ターゲット１０１０からソースＳ１へのクエリにより変換情報を制御コンポーネント１００２に送り、マッピングの完了に使用するためリソース１００４から適切なリレーショナル−ＸＭＬマッピングアルゴリズムを取り出しかつ／または生成することができる。マッピング関数（ｆｕｎｃｔｉｏｎ）は、エンティティ１０００の一部である。

より広範な例では、１つのデータモデルに対して行われたマップ要求（クエリまたは更新）を１つまたは複数の異なるデータモデルへの要求に変換することができる場合、ターゲットＴ２から始まり中間ターゲット／ソース１００８のいずれか１つを通りソースＳ１へ到達するクエリが開始し、エンティティ１０００は中間データソース１００８を通じて最適なパスを選択することができる。例えば、ソースＳ１がリレーショナルである場合、ターゲットＴ２はＸＭＬであり、第１の中間データソース１０１０はオブジェクトベースであり、第２の中間データソース１０１２はリレーショナルベースであり、第３の中間データソース１０１４はＸＭＬベースであり、エンティティ１０００は最適なパスがソースＳ１から第２の中間データソース１０１２を通りターゲットＴ２に至るものであると判定することができる。この判定が行われると、制御コンポーネント１００２は、ソースＳ１から中間データソース１０１２へのリレーショナル−リレーショナルマッピング（リソース１００４からの）を採用し、それにより、第２の制御エンティティ１０１６（制御エンティティ１０００と似ている）内のマッピングコンポーネントは第２の中間データソース１０１２からターゲットＴ２へのリレーショナル−ＸＭＬマッピングを使用する。制御エンティティ（１０００および１０１６）は、リンク１０１８を介して通信し、データソースを通じてターゲットＴ２に至る通信経路の１つを介して経路選択を調整することができる。

上で示したように、データソース間のマッピングは類似のデータ構造に対するものとすることができ、例えば、リレーショナル・ツー・リレーショナル、ＸＭＬ・ツー・ＸＭＬなどとすることができる。つまり、ソースのリレーショナルデータベースを、異なるリレーショナル構造を有するターゲットリレーショナルデータベースにマッピングすることができるシナリオが存在しうる。同様に、ソースのオブジェクトデータを、異なるオブジェクト構造を持つターゲットオブジェクトデータにマッピングすることができるシナリオが存在しうる。さらに、ソースのＸＭＬデータを、異なるＸＭＬ構造を持つターゲットＸＭＬデータモデルにマッピングすることができるシナリオが存在しうる。

次に図１１を参照すると、本発明の一態様によるスタック可能な構造１１００が例示されている。この機能は、図１０のネットワーク実装で使用されている。マッピングフレームワークは、便利な１組の形式、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍａｂｌｅ Ｉｎｔｅｒｆａｃｅ）、オプティマイザ、ユーティリティ、およびツールを備えており、ユーザは２つの任意のデータモデルの間でデータ処理を実装することができる。誰でも、ＱＩＬ（クエリ独立言語）コンパイラに対し自身のクエリを実行し、他のデータソースに対し自動的に実行するようにできる。ＱＩＬは、データソースに対するクエリ（または更新）の万能データソース独立表現である。マッピングにより、一方のデータモデルに対して行われた要求（クエリまたは更新）をマッピングする要求を別のデータモデルへの要求に変換することができる。

例示されているＡＰＩは、リレーショナル１１０２、ＸＭＬ１１０４、オブジェクト１１０６、およびその他１１０８を含む。したがって、クエリは、実行するためマッピングの複数のレイヤ（１１１０、１１１２、および１１１４）内を移動することができ、その結果を複数回再マッピングしてから送り返すようにできる。マッピングおよびＱＩＬは、作成可能である。マッピングは２方向である、つまり可逆であり、更新を自然に実行できる。

上で説明した内容は、本発明の例を含んでいる。もちろん、本発明を説明するためにコンポーネントまたは方法の考えられるすべての組合せを説明することは不可能であるが、当業者であれば、本発明の他の多くの組合せおよび置換が可能であることを理解できるであろう。したがって、本発明は、付属の請求項の精神と範囲内に収まるすべてのそのような変更、修正、および変更形態を包含するものとする。さらに、「ｉｎｃｌｕｄｅｓ（含む）」という言い回しを詳細な説明または請求項で使用している範囲において、このような用語は、「ｃｏｍｐｒｉｓｉｎｇ（備える、含む）」という用語が請求項の中で接続語（ｔｒａｎｓｉｔｉｏｎａｌ ｗｏｒｄ）として使用した場合に解釈されるように、「ｃｏｍｐｒｉｓｉｎｇ」という用語と同様の方法で包括的であることを表す。

本発明のマッピングシステムのブロック図である。 本発明によるプロセスのフロー図である。 ソースからターゲットへのマッピングを円滑にするために公開されている概念的メタデータエンティティの図である。 ソーススキーマをターゲットスキーマにマッピングするためのマッピングファイルの一般的な例を示す図である。 ソースドメインとターゲットドメインとのマッピング例を示す図である。 マッピングコンポーネントがネットワーク上に別々に配置されているソースのデータソースとターゲットのデータソースのネットワーク図である。 マッピングコンポーネントをソースの位置またはターゲットの位置、またはその両方の位置に配置することができることを示しているネットワーク図である。 開示されているアーキテクチャを実行する動作が可能なコンピュータのブロック図である。 本発明によるコンピューティング環境例を示す概略ブロック図である。 本発明によるディジーチェーン型のマッピング実装を示すブロック図である。 本発明マッピングアーキテクチャのハブ＆スポーク方式の実装を示す図である。 本発明の一態様によるスタック可能な構造を示す図である。

符号の説明

１００ マッピングシステム
１０２ ソースデータモデル
１０４ ターゲットデータモデル
１０６ マッピングコンポーネント
１０８ ソースメタデータ
１１０ ターゲットメタデータ

Claims (55)

1. 任意のデータモデルのマッピングを円滑にするシステムであって、少なくとも２つの任意のデータモデルからそれぞれのメタデータを受け取り、前記データモデル間で表現をマッピングするマッピングコンポーネントを備えることを特徴とするシステム。
2. 前記データモデルは、クエリ言語であることを特徴とする請求項１に記載のシステム。
3. 前記データモデルは、データアクセス言語であることを特徴とする請求項１に記載のシステム。
4. 前記データモデルは、データ操作言語であることを特徴とする請求項１に記載のシステム。
5. 前記データモデルは、データ定義言語であることを特徴とする請求項１に記載のシステム。
6. 前記データモデルは、少なくとも１つのオブジェクトモデルおよび少なくとも１つのリレーショナルモデルを含み、前記オブジェクトモデルは前記リレーショナルモデルのうちの少なくとも１つにマッピングされることを特徴とする請求項１に記載のシステム。
7. 前記データモデルは、前記オブジェクトモデルのうちの１つが前記他のオブジェクトモデルのうちの少なくとも１つにマッピングされるオブジェクトモデルを含むことを特徴とする請求項１に記載のシステム。
8. 前記データモデルは、ＸＭＬモデルおよび少なくとも１つのリレーショナルモデルを含み、前記ＸＭＬモデルは前記リレーショナルモデルのうちの少なくとも１つにマッピングされることを特徴とする請求項１に記載のシステム。
9. 前記データモデルはＸＭＬモデルであり、前記ＸＭＬモデルのうちの１つが前記他のＸＭＬモデルのうちの少なくとも１つにマッピングされることを特徴とする請求項１に記載のシステム。
10. 前記データモデルは、ＸＭＬモデルおよび少なくとも１つのオブジェクトモデルを含み、前記ＸＭＬモデルは前記オブジェクトモデルのうちの少なくとも１つにマッピングされることを特徴とする請求項１に記載のシステム。
11. 前記データモデルはリレーショナルモデルであり、前記リレーショナルモデルの１つは前記他のリレーショナルモデルのうちの少なくとも１つにマッピングされることを特徴とする請求項１に記載のシステム。
12. 前記データモデルは、ＸＭＬモデルおよびオブジェクトモデルを含み、前記オブジェクトモデルは前記ＸＭＬモデルのうちの少なくとも１つにマッピングされることを特徴とする請求項１に記載のシステム。
13. 前記データモデルは同じ構造を持つことを特徴とする請求項１に記載のシステム。
14. 前記マッピングコンポーネントは前記メタデータから導かれたトポロジデータを受け取ることを特徴とする請求項１に記載のシステム。
15. 前記データモデルは、読み取り専用であることを特徴とする請求項１に記載のシステム。
16. 前記データモデルは、データモデルのメタデータまたは構造をそれ自身修正することなくマッピングされることを特徴とする請求項１に記載のシステム。
17. 前記表現は構造、フィールド、および関係のうちの少なくとも１つを含むことを特徴とする請求項１に記載のシステム。
18. 前記データモデル間でマッピングされた前記表現は、同じ、異なる、および同じものと異なるものとの組合せのうちの少なくとも１つであることを特徴とする請求項１７に記載のシステム。
19. 前記マッピングコンポーネントは階層の作成または破壊、一方の要素から他方の要素への属性の移動、および新しい関係の導入のうちの少なくとも１つによりデータモデルのデータに対する構造上の変換を作成することを特徴とする請求項１に記載のシステム。
20. 前記マッピングコンポーネントは前記データモデル間の前記同じマッピング可能な概念を関係付け、接続することを特徴とする請求項１に記載のシステム。
21. 前記データモデル間の前記マッピングは、有向であることを特徴とする請求項１に記載のシステム。
22. 前記データモデルはソースドメインおよびターゲットドメインを含み、前記ターゲットドメインの構造およびフィールドを少なくとも１回はマッピングすることができることを特徴とする請求項１に記載のシステム。
23. 前記データモデルはソースドメインおよびターゲットドメインを含み、前記ソースドメインの構造およびフィールドを複数回マッピングすることができることを特徴とする請求項１に記載のシステム。
24. 前記データモデルはソースドメインおよびターゲットドメインを含み、前記マッピングコンポーネントによりユーザは前記ターゲットドメインのクエリ言語を通じて前記データモデルを操作できることを特徴とする請求項１に記載のシステム。
25. 前記データモデルはソースドメインおよびターゲットドメインを含み、前記ソースドメインは前記データの永続的ロケーションであることを特徴とする請求項１に記載のシステム。
26. 前記データモデルはソースドメインおよびターゲットドメインを含み、前記マッピングは、前記ターゲットドメインのクエリ言語で書かれているクエリを前記ソースドメインのクエリ言語に変換することを特徴とする請求項１に記載のシステム。
27. 前記マッピングコンポーネントは、ソースデータモデルに対しターゲットデータモデルで行われた更新の同期を自動的にとることを容易にすることを特徴とする請求項１に記載のシステム。
28. 前記マッピングコンポーネントは、それぞれの前記メタデータの概念のようにマッピングするマッピングファイルを含むことを特徴とする請求項１に記載のシステム。
29. 請求項１の前記システムを実行することを特徴とするコンピュータ。
30. 任意のデータモデルのマッピングを円滑にするシステムであって、
    ソースのデータソースのソース概念を表すソースメタデータと、
    少なくとも１つのターゲットのデータソースのターゲット概念を表すターゲットメタデータと、
    前記ソースメタデータと前記ターゲットメタデータとを受け取り、前記概念を前記ソースのデータソースから前記ターゲットのデータソースの１つまたは複数と関連する前記ターゲットのメタデータにマッピングするマッピングコンポーネントを備えることを特徴とするシステム。
31. 前記マッピングされた概念は、同じ、異なる、および同じものと異なるものとの組合せのうちの少なくとも１つであることを特徴とする請求項３０に記載のシステム。
32. 前記データソースは同じ構造を持つことを特徴とする請求項３０に記載のシステム。
33. 前記ソース概念および前記ターゲット概念は両方のデータソースにおいて同じであることを特徴とする請求項３０に記載のシステム。
34. 前記マッピングコンポーネントは前記データソース間の前記同じ概念を関係付け、マッピングすることを特徴とする請求項３０に記載のシステム。
35. 前記ソースおよびターゲットの概念は前記同じデータソース内の２つの構造の間のリンクおよび関連付けである関係要素を含むことを特徴とする請求項３０に記載のシステム。
36. 前記関係要素は、第１の構造が前記同じデータソース内の第２の構造にどのように関係するかを定義することを特徴とする請求項３５に記載のシステム。
37. 前記ソースのデータソースおよび前記ターゲットのデータソースは、前記マッピングコンポーネントから離してネットワーク上に配置されることを特徴とする請求項３０に記載のシステム。
38. 前記マッピングコンポーネントは前記ソースのデータソースおよび前記ターゲットのデータソースのうちの少なくとも一方のローカルにあることを特徴とする請求項３０に記載のシステム。
39. データモデル間でデータをマッピングする方法であって、
    少なくとも２つの任意のデータモデルからそれぞれのメタデータを受け取ることと、
    前記メタデータに基づき前記データモデルのうちの２つの間で表現をマッピングすることを含むことを特徴とする方法。
40. 前記２つのデータモデルの間でマッピングされた表現は、前記同じ表現であることを特徴とする請求項３９に記載の方法。
41. ソースデータスキーマとターゲットデータスキーマおよびスキーマ内の欠落している情報を定義することをさらに備えることを特徴とする請求項３９に記載の方法。
42. 関数を使用してソースデータモデルをターゲットデータモデルにマッピングしているときにデータを変換することをさらに備えることを特徴とする請求項３９に記載の方法。
43. ターゲットデータモデル内で行われた変更とソースデータモデルとの同期をとることをさらに備えることを特徴とする請求項３９に記載の方法。
44. 任意のデータモデルをマッピングする方法であって、
    ソースのデータソースのソース概念を表すソースメタデータとターゲットのデータソースのターゲット概念を表すターゲットメタデータを受け取ることと、
    前記ソースメタデータおよび前記ターゲットメタデータに基づいて前記ソースとターゲットのデータソースの間で概念をマッピングすることを含むことを特徴とする方法。
45. 前記データソースは同じ構造を持つことを特徴とする請求項４４に記載の方法。
46. ソースドメイン内に変数を作成することと、
    条件で前記変数を制約することと、
    前記変数を前記ターゲット概念にマッピングすることをさらに備えることを特徴とする請求項４４に記載の方法。
47. 前記変数は、暗黙の作成および明示的作成のうち少なくとも一方で作成されることを特徴とする請求項４６に記載の方法。
48. 前記変数は空の結果セットを表すことを特徴とする請求項４６に記載の方法。
49. 前記マッピングは、１つまたは複数の中間マッピングステージを介して前記ソースデータおよびターゲットデータとの間でスタック可能であることを特徴とする請求項４４に記載の方法。
50. 前記ソースと前記ターゲットとの間のマッピングに対する最適な経路を選択することをさらに備えることを特徴とする請求項４４に記載の方法。
51. 前記最適な経路は、前記経路内の利用可能な帯域幅と中断の少なくとも一方に基づき中央制御エンティティにより選択されることを特徴とする請求項５０に記載の方法。
52. 複数の前記データソースと複数の前記データターゲットとの間の最適な経路を選択することに対する応答としてマッピングアルゴリズムにアクセスすることをさらに備えることを特徴とする請求項４４に記載の方法。
53. 前記マッピングアルゴリズムは、前記ソースデータおよび前記ターゲットデータの構造に関連付けられていることを特徴とする請求項５２に記載の方法。
54. 任意のデータモデルの間のデータのマッピングを円滑にするシステムであって、
    ソースのデータソースのソース概念を表すソースメタデータとターゲットのデータソースのターゲット概念を表すターゲットメタデータを受け取る手段と、
    前記ソースメタデータおよび前記ターゲットメタデータに基づいて前記ソースとターゲットのデータソースの間で概念をマッピングする手段を備えることを特徴とするシステム。
55. マッピングする前記手段は、前記データソース間の前記同じ概念を関係付け、マッピングするマッピング手段を含むことを特徴とする請求項５４に記載のシステム。
    

Images