(57)【特許請求の範囲】
【請求項１】
任意のデータモデルをマッピングする方法であって、コンピュータのプロセッサが、
ソースのデータソースの構造、フィールドおよび前記データモデル間の関係を記述するソースメタデータとターゲットのデータソースの構造、フィールドおよび前記データモデル間の関係を記述するターゲットメタデータを受け取るステップであって、前記データモデルはソースドメイン及びターゲットドメインを含むステップと、
前記データモデル自体のメタデータまたは構造を変更せずに前記データモデルをマッピングするステップであって、
前記ソースメタデータおよび前記ターゲットメタデータに基づいて前記ソースとターゲットのデータソースの間で構造、フィールドおよび前記データモデル間の関係をマッピングするステップであって、前記ソースドメイン及び前記ターゲットドメインのデータモデルのマッピングにおいて、前記ソースとしてマッピングされたデータモデルは前記ターゲットとしてマッピングされたデータモデルと異なり、前記ターゲットドメインは前記ソースドメインの構造及びフィールドに１回マッピングすることができる構造及びフィールドを含み、一方で前記ソースドメインは前記ターゲットドメインの構造及びフィールドに複数回マッピングすることができる構造及びフィールドを含むステップと、
前記ソースドメインから前記ターゲットドメインへ複数ステージのマッピングをスタックに積み重ねるステップであって、スタックに積み重ね可能なマッピングは任意の２つのデータモデル間でデータ処理を実施するステップと
を含むステップと、
前記ソース及び前記ターゲット間でマッピングの最適な経路を選択するステップであって、前記経路内の利用可能な帯域幅と中断の少なくとも一方に基づいて最適な経路を選択するステップと、
前記ターゲットのデータソースのクエリ言語を通じて前記ソースのデータソース及びターゲットのデータソースを操作するステップと、
クエリ、更新、挿入または削除コマンドが前記マッピングに基づいて呼び出されたときに実行される指定の構造化クエリ言語のステートメントにより、前記ターゲットドメイン内で構造が作成、削除または修正されたとき、前記作成、削除または修正を自動的に前記ソースドメインに続けるステップと
を含むことを特徴とする方法。
【請求項２】
前記データソースは同じ構造を持つことを特徴とする請求項１に記載の方法。
【請求項３】
前記構造、フィールドおよび前記データモデル間の関係をマッピングするステップは、
ソースドメイン内に変数を作成するステップと、
条件で前記変数を制約するステップと、
前記変数を前記ターゲットのフィールドにマッピングするステップとをさらに備えることを特徴とする請求項１に記載の方法。
【請求項４】
前記変数は、暗黙の作成および明示的作成のうち少なくとも一方で作成されることを特徴とする請求項３に記載の方法。
【請求項５】
前記変数は空の結果セットを表すことを特徴とする請求項３に記載の方法。
【請求項６】
前記マッピングは、１つまたは複数の中間マッピングステージを介して前記ソースデータおよびターゲットデータとの間でスタックに積み重ね可能であることを特徴とする請求項１に記載の方法。
【請求項７】
前記最適な経路は、中央制御エンティティにより選択されることを特徴とする請求項１に記載の方法。
【請求項８】
複数の前記データソースと複数の前記データターゲットとの間の最適な経路を選択することに対する応答としてマッピングアルゴリズムにアクセスすることをさらに備えることを特徴とする請求項１に記載の方法。
【請求項９】
前記マッピングアルゴリズムは、前記ソースデータおよび前記ターゲットデータの構造に関連付けられていることを特徴とする請求項８に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データソース間のデータマッピングに関するものである。
【背景技術】
【０００２】
有線方式でも無線方式でも今日一般的になっている情報の自由な流れには、使用するデータの格納および解釈に関してソース（ｓｏｕｒｃｅ）とデスティネーション（ｄｅｓｔｉｎａｔｉｏｎ）とで互換性がとれている必要がある。世界に存在する情報源は、多くの場合、情報のソース毎にデータの表現が異なる情報源である。今日企業と個人が直面している主要な問題は、一方のフォーマットで存在するデータが他の目的のためには別のフォーマットで必要になることがあるという点である。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかし、このようなプロセスは、本質的に大きく異なり絶えず変化するデータセット群により阻害されている。このような例は、様々なソースからデータが届き格納され他のソースから素早くアクセスされるデータウェアハウジングに見られる。一方のデータ表現から他方のデータ表現に変換するのは、時間がかかり、大量のリソースを使うだけでなく、変換問題をはらみ、場合によっては、複雑なためまったく実行不可能である。
【課題を解決するための手段】
【０００４】
以下では、本発明のいくつかの態様の基本的な内容を理解できるように、本発明の要約を簡単に述べる。この要約は、本発明の概要を広範囲にわたって述べたものではない。この要約は、本発明の鍵となる要素や決定的な要素を示したり、本発明の範囲を定めることを目的としていない。後で述べる詳細な説明の前置きとして、本発明のいくつかの概念を簡略化した形式で述べることのみを目的とする。
【０００５】
本明細書で開示され、請求されている本発明は、その一態様において、データソース自体のメタデータまたは構造を修正することなく、２つ（またはそれ以上）のデータソース同士のマッピングが必要なシナリオをサポートする設計のマッピング形式（ｍａｐｐｉｎｇ  ｆｏｒｍａｔ）を含む。例えば、オブジェクト空間とリレーショナルデータベース、オブジェクト空間とＸＭＬデータモデル、ＸＭＬデータモデルとリレーショナルデータモデルの間のマッピングが実現されるが、あるいは考えられる他のデータモデルからＸＭＬ、リレーショナルデータモデル、または他のデータモデルへのマッピングを実現することも可能である。このマッピング形式では更新をサポートしており、さらに、マッピングされる両方のデータソースが与えられ、そのスキーマが事前に定義され、変更できない（つまり、読み取り専用である）場合もサポートする。例えば、ＸＭＬデータをリレーショナルデータベースにマッピングするためにすでに使用されている方法では、注釈を付け加えるためにＸＭＬスキーマ定義（ＸＳＤ）ファイルを変更する必要があった。本発明のマッピング形式は、ＸＳＤファイルが外部エンティティにより所有され、変更できないかのように働く。また、編集せずに同じＸＳＤファイルを再利用し、異なるデータソース（データベースなど）への複数のマッピングを行うことができる。
【０００６】
各データモデルは、マッピングに対する構造、フィールド、および関係（ｒｅｌａｔｉｏｎｓｈｉｐ）という３つの概念（または表現）のうち少なくとも１つを公開する。これらの概念はすべて、データモデル間でマッピングすることができる。１つのデータモデルが３つの表現を持つ他のデータモデルにマッピングされる表現のうちただ１つまたは２つしか持たない可能性がある。マッピング構造は、マッピングスキーマ（ｍａｐｐｉｎｇ  ｓｃｈｅｍａ）の基本コンポーネントであり、対応付けられたマッピングフィールドのコンテナとして使用される。フィールドは、型付きデータを保持するデータモデル概念である。関係は、同じデータモデル内の２つの構造の間のリンクおよび関連付けであり、同じドメイン内の構造が互いにどのような関係にあるかを記述するものである。関係は、構造に他の構造が含まれる２つの構造および／または包含／参照の共通フィールドを通じて確立される。これらは、他の関係を確立できるので（例えば、兄弟関係、機能（ｆｕｎｃｔｉｏｎ）関係など）関係の単なる例である。本発明により、任意の関係を確立することができる。データモデルのメンバは、マッピングコンテキストに応じて様々なマッピング概念として公開することができる。
【０００７】
意味に関しては、マッピングはメタデータが追加されているビューと同等であり（またビューは実際にはクエリであり）、２つのマッピングされるドメインに関する可逆性のヒントおよび追加情報を含む。一方のデータソースが他方のデータソースにマッピングされる場合、本当に要求されているのは、ターゲットスキーマはソーススキーマの１ビューであるのが望ましいということである。マッピングは、データドメインの上にデータドメインを積み重ねるという形で表されるビューであり、ビュー変換（ｖｉｅｗ  ｔｒａｎｓｆｏｒｍａｔｉｏｎ）自体を定義するものである。マッピングは、データに対して構造化変換を実行し複合ビューを作成することができ、この変換により、階層が作成されたり、崩壊（ｃｏｌｌａｐｓｅ）されたり、また一方の要素から他方の要素へ属性を移動し、新しい関係を導入する。
【０００８】
マッピングは、２つまたはそれ以上のマッピングされたモデル間で、マッピング可能な同じ概念を対応付け、接続する。マッピングは、さらに、有向性でもある。したがって、一方のドメインはソースとして分類され、他方のドメインはターゲットとして分類される。マッピングの方向性は、ソースとしてマッピングされるモデルはターゲットとしてマッピングされるモデルと異なる特性を持つという点でマッピングの実装および意味（ｓｅｍａｎｔｉｃｓ）に関して重要である。ターゲットはソースモデルのビューを保持し、マッピングはターゲットドメインのクエリ言語を使用して実現される。ソースは、データの永続的位置であり、マッピングはターゲットドメインのクエリ言語で書かれているクエリをソースドメインのクエリ言語に変換する。ソースとターゲットとの違いの１つは、ソースまたはターゲットモデルからの構造またはフィールドが構造およびフィールドについて適用可能なマッピングの個数に関して一部制限を設けているという点である。ターゲットドメインでは、構造およびフィールドは、一度しかマッピングできないが、ソースドメイン内では、構造およびフィールドは複数回マッピングすることができる。例えば、Ｃｕｓｔｏｍｅｒｓテーブルをターゲットドメイン内のＢｕｙｉｎｇＣｕｓｔｏｍｅｒ要素とＲｅｆｅｒｒｉｎｇＣｕｓｔｏｍｅｒ要素にマッピングすることができる。しかし、ローカル要素またはローカルクラスは、一度しかマッピングできない。マッピングの方向属性に起因する他の違いとして、マッピングを使用することによりユーザはターゲットドメインのクエリ言語を通じてマッピングされたモデルを操作することができるという点があげられる（例えば、リレーショナルモデルをＸＭＬモデルにマッピングするためにＸＱｕｅｒｙを使用し、リレーショナルモデルをオブジェクトモデルにマッピングするためにＯＰａｔｈを使用する）。
【０００９】
マッピングアーキテクチャの他の重要な属性に、更新可能であるという属性がある。これまで、開発者はドメイン間の変更を伝え同期をとるためにコードを書かなければならなかった。しかし、本発明では、マッピングエンジンがそれらのタスクを実行するようになっている。つまり、ユーザがターゲットドメイン内で構造を作成、削除、または修正した場合に、それらの変更はターゲットＡＰＩおよびマッピングエンジンによりソースドメインとの間で自動的に同期がとられる（永続化される）。
【００１０】
他の態様では、マッピングアーキテクチャはスタックすることが可能であり、ソースからターゲットへのマッピングに複数のステージが生じうる。
【００１１】
前記の目的および関連する目的を遂行するために、本発明のいくつかの例示する態様について、以下の説明および付属の図面を参照しながら説明する。ただし、これらの態様は本発明の原理を採用する様々な方法のうちわずかのみを示しており、本発明はこのような態様およびその等価物すべてを含むことを意図している。本発明の他の利点および新規な特徴は、図面を参照しながら本発明の以下の詳細な説明を読むと理解しやすいであろう。
【発明を実施するための最良の形態】
【００１２】
本発明は、本明細書全体を通して類似の番号は類似の要素を表す図面を参照して説明する。以下の説明では、説明のため本発明を完全に理解できるように多数の具体的詳細を述べている。しかし、本発明は具体的詳細を知らなくても実施できることは明白であると思われる。他の場合には、本発明を説明しやすくするために、よく知られている構造およびデバイスがブロック図形式で示されている。
【００１３】
本出願で使用されているように、「コンポーネント」および「システム」という用語は、コンピュータ関連のもの、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれかを指すものとする。たとえば、コンポーネントとしては、プロセッサ上で実行されているプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および／またはコンピュータがあるが、これらに限定されない。説明のため、サーバ上で実行されているアプリケーションとサーバは両方ともコンポーネントとすることができる。１つまたは複数のコンポーネントを１つのプロセスおよび／または実行スレッド内に常駐させることができ、またコンポーネントを１台のコンピュータにローカライズし、かつ／または２台またはそれ以上のコンピュータ間に分散させることができる。
【００１４】
本明細書で使用しているように、「推論」という用語は、一般に、イベントおよび／またはデータを介して得られるような１組の観察結果から、システム、環境、および／またはユーザの状態を推理または推論するプロセスを指す。推論を使用して特定のコンテキストまたはアクションを識別したり、または例えば複数の状態について確率分布を生成することができる。推論は確率的なものとすることができる、つまり、データおよびイベントの考察に基づいて注目している状態で確率分布を計算することができる。推論は、さらに、１組のイベントおよび／またはデータから高水準のイベントを構成するために使用される手法を指す場合もある。このような推論を行うことで、イベント同士が時間的に近い関係による相関関係があるかどうか、またイベントおよびデータが１つまたは複数のイベントおよびデータソースを発生元としているかどうかに関係なく、１組の観察されたイベントおよび／または格納されているイベントデータから新しいイベントまたはアクションが構築される。
【００１５】
定義
以下の用語は説明全体を通して使用されており、主題の発明の様々な態様を理解しやすくするためこれらの定義をここに掲載する。
【００１６】
モデル（Ｍｏｄｅｌ）−設計成果物、例えば、ＸＭＬスキーマ、リレーショナルスキーマ、およびオブジェクトスキーマを表す複雑な離散構造。
【００１７】
ドメイン（Ｄｏｍａｉｎ）−特定のデータモデルに基づきデータを管理する１つまたは複数のアプリケーション。
【００１８】
オブジェクトドメイン（Ｏｂｊｅｃｔ  ｄｏｍａｉｎ）−オブジェクトグラフデータモデルのＯｂｊｅｃｔＳｐａｃｅ実装。
【００１９】
ＸＭＬドメイン（ＸＭＬ  ｄｏｍａｉｎ）−ＸＭＬデータモデルに基づくオブジェクトおよびクエリ言語のスタック。
【００２０】
リレーショナルドメイン（Ｒｅｌａｔｉｏｎａｌ  ｄｏｍａｉｎ）−リレーショナルデータモデルに基づくＤＢＭＳ（データベース管理システム）。
【００２１】
ＩＤｏｍａｉｎＳｃｈｅｍａ−マッピング可能な構造のシリアライズ可能なラベル付き有向グラフとしてモデルを公開するモデル管理オブジェクトモデル。モデルグラフの辺（ｅｄｇｅ）を「関係」と呼ぶ。例えば、ＸＳＯＭ（ＸＭＬスキーマＸＳＤ（ＸＭＬ  Ｓｃｈｅｍａ  Ｄｅｆｉｎｉｔｉｏｎ）を公開するオブジェクトモデル）、ＲＳＯＭ（リレーショナルスキーマＲＳＤ（Ｒｅｌａｔｉｏｎａｌ  Ｓｃｈｅｍａ  Ｄｅｆｉｎｉｔｉｏｎ）を公開するオブジェクトモデル）、およびＯＳＯＭ（オブジェクトスキーマＯＳＤ（Ｏｂｊｅｃｔ  Ｓｃｈｅｍａ  Ｄｅｆｉｎｉｔｉｏｎ）を公開するオブジェクトモデル）がある。
【００２２】
マッピング構造（Ｍａｐｐｉｎｇ  ｓｔｒｕｃｔｕｒｅ）−対応付けられたマッピングフィールドのコンテナとして使用されるデータモデルスキーマの基本コンポーネント（例えば、リレーショナルドメイン内のテーブル、ＸＭＬドメイン内の複合型要素、およびオブジェクトドメイン内のクラス）。
【００２３】
フィールド（Ｆｉｅｌｄ）−型付き（ｔｙｐｅｄ）データを保持するデータモデル概念。概念上、フィールドはスカラー値を保持するが、場合によっては、複合データ（例えば、ＸＭＬデータ型およびＵＤＴ）を保持することも可能である。さらなる例としては、リレーショナルデータモデルの列、ＸＭＬドメイン内の属性および単純型要素、およびオブジェクトドメイン内のプロパティがある。
【００２４】
関係（Ｒｅｌａｔｉｏｎｓｈｉｐ）−同じデータモデル内の２つの構造の間のリンクおよび関連付けであり、同じドメイン内の構造が互いにどのように対応付けられているかを記述する。関係は、構造に他の構造が含まれる２つの構造および／または包含／参照の共通フィールドを通じて確立される（例えば、ＸＭＬ包含階層、およびそのフィールドを通じて他のオブジェクトを参照するオブジェクト）。
【００２５】
図１を参照すると、本発明のマッピングシステム１００のブロック図が示されている。このフレームワークは、オペレーションに変換される、それぞれのクエリ言語またはＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｉｎｔｅｒｆａｃｅｓ）を使用してそのドメイン内でＣＲＵＤ  （Ｃｒｅａｔｅ、Ｒｅａｄ、Ｕｐｄａｔｅ、およびＤｅｌｅｔｅ）オペレーションを実行するデータモデルの能力を提供する。例えば、ＸＭＬおよびオブジェクトデータモデルは、クエリ言語（例えば、それぞれＸＱｕｅｒｙおよびＯＰａｔｈ）を使用してそのドメイン内でＣＲＵＤオペレーションを実行することができるが、それらのオペレーションは、クエリ言語（例えば、ＳＱＬ）を使用してリレーショナルドメイン内のオペレーションに変換される。
【００２６】
システム１００は、ソースデータモデル１０２およびターゲットデータモデル１０４を含み、マッピングコンポーネント１０６を介してソースモデル１０２からターゲットモデル１０４へのマッピングが実行される。各データモデル（１０２および１０４）は、対応付けることができる１つまたは複数のエンティティを公開するメタデータに関連付けられている。つまり、ソースモデル１０２は、ソースメタデータ１０８を公開し、ターゲットモデル１０４は、ターゲットメタデータ１１０を公開し、メタデータ（１０８および１１０）はそれぞれ、マッピングコンポーネント１０６を介して直接対応付けられる概念的エンティティを含む。メタデータエンティティは、構造、フィールド、および関係の概念（または表現）を含む。
【００２７】
マッピングは、少なくとも２つのマッピングされたモデルからの同じマッピング可能な概念、または異なるマッピング可能な概念、または同じマッピング可能な概念と異なるマッピング可能な概念の組合せ（以下で詳述する）を対応付け、接続する。マッピングは、有向性（ｄｉｒｅｃｔｉｏｎａｌ）である。したがって、いくつかのドメインはソース１０２として分類され、他のドメインはターゲット１０４として分類される。開示されているマッピングアーキテクチャの有向性の側面は、マッピングの実装および意味に関してかなり有益である。さらに、ソース１０２としてマッピングされるモデルは、ターゲット１０４としてマッピングされるモデルと異なる特性を持つことができる。
【００２８】
ターゲットモデル１０４はソースモデル１０２のビューを保持する。つまり、マッピングは、ターゲットドメインのクエリ言語を使用して実現される。ソースモデル１０２は、データの永続的位置であり、マッピングコンポーネントはターゲットドメインのクエリ言語で書かれているクエリをソースドメインのクエリ言語に変換する。
【００２９】
ソース１０２とターゲット１０４との違いは、ソースまたはターゲットモデル（１０２または１０４）からの構造またはフィールドに、構造およびフィールドについて適用可能なマッピングの個数に関して一部制限があるという点である。ターゲットドメインでは、構造およびフィールドは、一度しかマッピングできないが、ソースドメイン内では、構造およびフィールドは複数回マッピングすることができる。例えば、Ｃｕｓｔｏｍｅｒｓテーブルをターゲットドメイン内のＢｕｙｉｎｇＣｕｓｔｏｍｅｒ要素とＲｅｆｅｒｒｉｎｇＣｕｓｔｏｍｅｒ要素にマッピングすることができる。しかし、ローカル要素またはローカルクラスは、一度しかマッピングできない。ここでは、例、構文、および意味に関してより詳しい説明を行う。
【００３０】
マッピングの方向属性に起因するソースとターゲットとの別の違いは、マッピングを使用することによりユーザはターゲットドメインのクエリ言語を通じてマッピングされたモデルを操作することができるという点である（例えば、ＸＭＬマッピングに対する関係のＸＱｕｅｒｙ、およびオブジェクトマッピングに対する関係のＯＰａｔｈ）。
【００３１】
図２を参照すると、本発明によるプロセスのフロー図が示されている。説明を簡単にするために、本明細書で示されている１つまたは複数の方法が、例えばフロー図の形式で示され、一連の活動として記述されているが、本発明は活動の順序によって制限されるわけではなく、本発明によるいくつかの活動はその図に示されているここで説明しているのと異なる順序でかつ／または他の活動と同時に実行することも可能であることを理解し、認識するであろう。例えば、当業者であれば、方法を代わりに一連の相互に関連のある状態またはイベントとして状態図などの中に表すことが可能であることを理解し、認識するであろう。さらに、本発明によりこの方法を実装するために例示されているすべての活動が必要なわけではない。
【００３２】
２００に、データマッピングのデータモデルが示されている。２０２で、データモデルが識別されると、各モデルの対応するメタデータが識別される。２０４で、ソースモデルからターゲットモデルへのデータマッピングが開始する。２０６で、システムは、マッピングエラーが発生したかどうかを判定する。「Ｙｅｓ」であれば、フローは２０８に進み、エラーを報告する。フローは、２０４の入力に戻り、マッピングプロセスを続行する。その一方で、マッピングエラーが発生していない場合、フローは２０６から２１０に進み、マッピングプロセスを完了まで続行する。プロセスは、「停止」ブロックに到達する。
【００３３】
図３は、ソースからターゲットへのマッピングを円滑にするために公開されている概念的メタデータエンティティの図を示している。マッピングコンポーネントは、ソースのメタデータ１０８とターゲットのメタデータ１１０との間のマッピング機能を調整するマッピングファイル３００を作成する。この特定の実施形態では、ソースのメタデータ１０８およびターゲットのメタデータ１１０は、それぞれ、構造、フィールド、および関係という、マッピング関係を確立するために使用することができる３つのエンティティを備える。そのため、ソースのメタデータ１０８は、ＳＴＲＵＣＴＵＲＥＳエンティティ３０２、ＦＩＥＬＤＳエンティティ３０４、およびＲＥＬＡＴＩＯＮＳＨＩＰＳエンティティ３０６を含む。同様に、ターゲットのメタデータ１１０は、ＳＴＲＵＣＴＵＲＥＴエンティティ３０８、ＦＩＥＬＤＴエンティティ３１０、およびＲＥＬＡＴＩＯＮＳＨＩＰＴエンティティ３１２を含む。
【００３４】
この構造は、データモデルスキーマの基本コンポーネントであり、関係するマッピングフィールドのコンテナとして使用される。例として、リレーショナルドメイン内のテーブル、ＸＭＬドメイン内の複合型要素、およびオブジェクトドメイン内のクラスが含まれる。フィールドエンティティは、型付きデータを保持するデータモデル概念である。概念上、フィールドはスカラー型値を保持するが、場合によっては、複合データ（例えば、ＸＭＬデータ型とＵＤＴ）を保持することも可能である。フィールドのマッピングの例としては、リレーショナルデータモデルの列、ＸＭＬドメイン内の属性および単純型要素、およびオブジェクトドメイン内のプロパティがある。関係は、同じデータモデル内の２つの構造の間のリンクおよび関連付けであり、同じドメイン内の構造が互いにどのような関係にあるかを記述するものである。関係は、構造に他の構造、例えば、ＸＭＬ包含階層、およびそのフィールドを通じて他のオブジェクトを参照するオブジェクトが含まれる、２つの構造および／または包含／参照の共通フィールドを通じて確立される。
【００３５】
データモデルのメンバは、マッピングコンテキストに応じて様々なマッピング概念として公開することができる。例えば、ＸＭＬ要素は、フィールドおよび構造（例えば、単純型要素および複合型要素）として公開することができる。メンバを特定の概念として提示することが有効であるかどうかを判別するのは、マッピングとＩＤｏｍａｉｎＳｃｈｅｍａである。データモデルを異なるマッピング概念として公開することができる他の例は、表現も例えばカスタムテーブル内の概念とすることが可能なリレーショナルドメインを伴う。
【００３６】
マッピングの意味
意味に関しては、マッピングは、可逆性のヒントおよび２つのマッピングされたドメインに関する追加情報を含む追加メタデータを持つクエリ／ビューと同等である。一方のデータソーススキーマが他方のデータソーススキーマにマッピングされる場合、要求されているのは、ターゲットスキーマがソーススキーマの１つのビューであることが望ましいということである。マッピングにより、ビュー変換自体が定義される。例えば、リレーショナルデータベースをＸＭＬにマッピングする場合、ビューが定義され、その際に、その表示（またはスキーマ）は最終的にＸＳＤによって定義され、マッピングファイルでは、ＲＳＤファイルで表されるリレーショナルデータベースでこのビューを（処理し実行することにより）生成する方法を定義する。
【００３７】
マッピングは、別のデータドメインの上にデータドメインを積み重ねるという形で表されるビューである。マッピングがそのようなビューである（また、ビューは実際にはクエリである）と理解していることが、マッピングの意味を理解するうえで重要である。
【００３８】
マッピングビューとＳＱＬビューとを対比することができる。ＳＱＬ  Ｓｅｒｖｅｒでは、リレーショナルデータベースの上にリレーションビューを定義することができる。このビューは、基本的に、結果のスキーマ（ステートメントのＳＥＬＥＣＴ句）、ソースのサブスキーマの関連する部分（おおまかにいうと−ステートメントのＦＲＯＭ句）、およびソーススキーマから結果スキーマを生成することができる変換（ＷＨＥＲＥ句）の３つを組み合わせたＳＱＬクエリによって定義される。
【００３９】
開示されているマッピング形式は、同じ３つの部分を持つが、明確に区別される（ＸＳＤ、Ｍａｐｐｉｎｇ、ＲＳＤのように）。
【００４０】
マッピングは、複合クロスドメインビュー（ｃｏｍｐｌｅｘ  ｃｒｏｓｓ−ｄｏｍａｉｎ  ｖｉｅｗ）である。マッピングを使用することで、クロスドメインビューを作成することができる。際立った特徴（例えば、ＳＱＬビューまたはＸＳＬＴビューの）は、ソースおよびターゲットスキーマが異なるデータモデルドメインに属することができるという点である。マッピングでは、リレーショナルスキーマの上に階層型ビュー（ＸＭＬ）を構築したり、あるいは階層型スキーマの上にグラフビュー（オブジェクト）を構築するなどができる。
【００４１】
開示されているマッピングアーキテクチャにより、ＸＱｕｅｒｙおよびＸＳＬＴなどの他の言語をマッピングと併せて使用しターゲットまたはソースドメインを変換することができる。変換は、例えば、オペレーション毎にマップに追加される。オペレーションの例として、Ｉｎｓｅｒｔ、Ｕｐｄａｔｅ、Ｄｅｌｅｔｅ、およびＱｕｅｒｙがある。
【００４２】
サンプルコード：
【００４３】
【表１】
0004847689.tif 000002
【００４４】
ＴｒａｎｓｆｏｒｍＬａｎｇｕａｇｅは、マッピングされるデータを変換するために使用する言語である。ＴｒａｎｓｆｏｒｍＬｏｃａｔｉｏｎは、ディスク上のファイルロケーションまたは変換結果が供給されるインターネット上のファイルロケーションである。ロケーションが指定されていない場合、変換はＭａｐＴｒａｎｓｆｏｒｍ要素のテキストで与えることができる。Ｏｐｅｒａｔｉｏｎは、マッピングを使用するアプリケーションに基づいて定義されるこの変換に対するオペレーションである。
【００４５】
マッピングは、データに対して構造化変換を実行し複合ビューを作成することができる。これにより、階層が作成されたり、崩壊されたり、また一方の要素から他方の要素へ属性を移動し、新しい関係を導入することができる。マッピングの結果（ターゲットスキーマ）は、複合スキーマであってもよい。これは、基本的にマルチテーブルデータベーススキーマを単一テーブルに変換する従来のアーキテクチャと対照的である。マッピングにより、出力上での関係で対応付けられる複数のテーブル（要素など）を生成することができる。
【００４６】
マッピングはビューを定義するが、これは、使用するためにはユーザはビューの上でクエリおよび更新を実行できることを意味する。マッピングは、オペレーションではなく、クエリまたは更新オペレーションなしで何らかのデータを生成するのには使用できない。しかし、クエリは、些細なもの（例えば、ｓｑｌ：ｖｉｅｗ（“ｆｉｌｅｎａｍｅ”））でもよく、マッピングビューで記述されたすべてのデータを取り出すことができる（このビューを実現する）。マッピングは、（いくつか例外はあるが）、クエリとそのビュー（更新可能ビュー）に対する更新の両方をサポートする。
【００４７】
技術上、マッピングはクエリに類似している。クエリを介してＳＱＬ  Ｖｉｅｗを定義するのと同じように、マッピングは、さらに、このビューを生成するクエリがあることを意味する。マッピングは、静的な再利用可能更新可能ビューを定義し、ユーザはこのビューを使用して、このビューの上に複数のアドホックなクエリ／更新を課すことができる。
【００４８】
例えば、ユーザは開示されているマッピング形式を使用して、関連する注文と注文明細とともに最後の７日間に注文があったすべての顧客（「Ａｃｔｉｖｅ  Ｃｕｓｔｏｍｅｒｓ」と呼ぶ）のビュー（スキーマ）を定義することができる。その後、ユーザは、このビューを使用して、そのビューの上でクエリを実行する。例えば、一方のドメインで、収支が負であるすべての「Ａｃｔｉｖｅ  Ｃｕｓｔｏｍｅｒｓ」を取り出すＸＱｕｅｒｙを課すことができる。実行ステップで、マッピングプロセッサは、ＸＱｕｅｒｙステートメントと組み合わせて、ＳＱＬＧｅｎエンジンにより、リレーショナルビューの上のＳＱＬ  Ｑｕｅｒｉｅｓに対するＳＱＬ  Ｓｅｒｖｅｒと同様に、マッピングの関連する部分に対応するクエリを作成するために使用されるマッピング情報を公開する。
【００４９】
取り出しおよび更新オペレーションは、本質的に異なる。単一の取り出しオペレーションは、一方向でサポートされているが、３つのオペレーション（挿入、更新、および削除）は、他の方向でサポートされる。例えば、ソースとしてＳＱＬ  Ｓｅｒｖｅｒ内のデータをターゲットＸＭＬスキーマにマッピングし、リレーショナルデータのＸＭＬビューを作成することができるマッピングを定義する。ＸＱｕｅｒｉｅｓは、ＳＱＬ  Ｓｅｒｖｅｒ内のテーブルに対して実行することはできない。さらに、同じマッピングを使用して、ＸＭＬデータソースの上にリレーショナルビューを表すことはできない。開示されているマッピング形式は、対称的ではなく、容易に反転することはできない。データは、ＳＱＬ  ＳｅｒｖｅｒからＸＭＬとして取り出すことができ、またＸＭＬクエリ言語によりクエリを実行することができる。マッピングではビューを通じての更新をサポートしているため、同じマッピングを通じて更新を実行することもできる。
【００５０】
マッピングは、２つのマッピングされるモデル間の双方向（読み書き）変換を適用するのに必要な情報を供給する。データモデルドメイン間でクエリ、更新、挿入、および削除オペレーションを実行するのに必要な情報は、存在しているかどうか（一方のドメイン内に構造が存在するかどうかは、ドメインが同期されている場合に他方のドメイン内に構造が存在することに基づく）、コピー（コピーオペレーションが一方のドメインから他方のドメインへの値、例えばＮＵＬＬ値およびデータ型変換に対する制限付き変換を含むことができる場合にソースモデルおよびターゲットモデル内のマッピングされているフィールド間のコピーデータ）、および関係マップ（ソースドメイン内のそれぞれのマッピングされている構造間の関係に対するターゲットドメイン内の２つのマッピングされている構造間に存在するマップ関係）である。関係同士の間のマッピングは、２つのデータモデル内で並行したナビゲーション、つまり、一方のドメイン内の特定の関係に基づく一方の構造から他方の構造への移動を可能にし、他方のドメイン内の２つのマッピングされている構造間での移動に変換する。
【００５１】
関係マップは、存在またはコピーの意味よりもあまり直感的でない概念である。関係マップは、同時にマッピングされている両方のドメイン内で「グラフ内を探索（ｗａｌｋ）する」ことができる必要がある。ターゲットモデルの２つのマッピングされている構造（例えば、オブジェクト、ＸＭＬ）にそれらの間の関係がある場合、または１つのターゲット構造が複数のソース構造（例えば、テーブル内の）にマッピングされる場合、ターゲットドメイン内の暗黙のまたは明示的な関係をソース（例えば、リレーショナル）ドメイン内の一致する関係にマッピングされなければならない。ターゲットドメイン内のすべての関係はソースドメイン内の関係にマッピングされなければならないが、反対はそうではないという要求条件はターゲットドメインはソースドメイン上のビューであるということに起因していることに注意されたい。したがって、マッピングは、このビューを作成するために必要な最低限の情報を必要とする。ソースドメインは、マッピングに関連していないさらに多くの構造（テーブル）および関係を含むことができる。
【００５２】
ドメイン内の構造間の関係は、参照関係（型が他の型への参照を含み、一方の型を削除／更新しても、他の型も削除／更新されることはなく、参照のみが削除される）または所有（ｏｗｎｅｒｓｈｉｐ）関係（Ｃｏｍｐｏｓｉｔｅ）（構造が他の構造を所有し、構造の１つのインスタンスに対するオペレーションが関係する構造のインスタンスに伝わる場合の関係）のいずれかである。例えば、特定の顧客を削除すると、その注文も削除されるが、注文明細を削除しても製品は削除されない。
【００５３】
特定のマッピングが、読み書き両方のオペレーションに適用される。したがって、マッピングは更新可能（双方向）であると考えられる。異なる動作（例えば、読み取り専用または複数のテーブルシナリオへの１つのターゲット構造の書き込み）を指定するためにユーザはそれぞれのドメインの拡張メカニズムを利用することができる。例えば、リレーショナルドメインは、ｑｕｅｒｙ、ｕｐｄａｔｅ、ｉｎｓｅｒｔ、およびｄｅｌｅｔｅコマンドが用意されているＣｕｓｔｏｍＴａｂｌｅを公開し、ユーザは、マッピングに基づいてこのコマンドが呼び出されたときに実行されるＳＱＬステートメントを指定することができる。他の例として、リレーショナルドメイン内の列およびテーブルのＲｅａｄＯｎｌｙフラグがある。しかし、このような列またはテーブルを更新しようとすると、エラーが発生するため、このような情報はドメイン内で指定し、マッピングでは指定しない。
【００５４】
次に図４を参照すると、マッピングファイル４００を使用してソースリレーショナルスキーマをターゲットＸＭＬスキーマにマッピングする例が示されている。本発明のいくつかの態様では、ソーススキーマ４０２もターゲットスキーマ４０４も、マッピングの実行のために修正を必要としない。したがって、ソースリレーショナルスキーマ４０２とターゲットＸＭＬスキーマ４０４は両方とも、いずれもが編集を必要としないため、読み出し専用とすることができる。本発明のこのような特徴は著しいものであるが、それは、アプリケーションでは、多くのクライアントデータモデルにおいて編集でマッピングを実行することが許されないからである。
【００５５】
開示されているマッピング形式は、ソースのデータソース４０２にない情報とともにソースのデータソース４０２のスキーマを定義するソース記述コンポーネント４０６、ターゲットのデータソース４０４内にない情報とともにターゲットのデータソース４０４のスキーマを定義するターゲット記述コンポーネント４０８、および中央マッピングコンポーネント４１０などの３つまたはそれ以上のコンポーネントからなるものとみなすことができる。ソース記述コンポーネント４０６は、リレーショナルソーススキーマ４０２を拡張したものであり、ターゲット記述コンポーネント４０８は、ＸＭＬターゲットスキーマ４０４を拡張したものであり、中央マッピングコンポーネント４１０は実際のマッピングを実行する。
【００５６】
次に、このタスクでは、ターゲットスキーマ４０４のＸＳＤにより定義された形式でＸＭＬデータを生成することについてリレーショナルデータベースにクエリを実行できるように、また他の方向では、ＸＭＬデータをソースとして受け付けてリレーショナルテーブルにロードし、マッピングに従ってＸＭＬデータを細分（ｓｈｒｅｄ）してリレーショナルデータベースに入れられるように、これら２つのスキーマ（４０２と４０４）の間のマッピングを定義する。
【００５７】
マッピングを定義するときに従来から存在していた問題の１つは、データソーススキーマの不完全性である。例えば、リレーショナルスキーマは、実際にはデータベース内に存在している関係のいくつかを欠いている場合がある。残念なことに、データベース設計者が関係を一次キー（ＰＫ）−外部キー（ＦＫ）の制約条件として正式に定義しないのが通例である。外部キー自体は子のテーブル内にも存在しているが、スキーマ内ではそのようなものとしてマークされていない。しかし、開示されているマッピングアーキテクチャでは、一次／外部キーの関係は好ましいものであり、したがって定義する必要がある。他の一般的事例として、一次キーがテーブルに対して一次キーとしてマークされていない場合があげられる。
【００５８】
ときには、カスタム関係をスキーマに追加したい場合もある。例えば、「Ｊ」で始まるＶＩＮ番号を持つすべての自動車は、関係「ｍａｄｅ  ｉｎ」を持つ「Ｃｏｕｎｔｒｉｅｓ」テーブル内の「Ｊａｐａｎ」エントリに対応している。最悪の場合のシナリオでは、リレーショナルスキーマファイルは編集することが許されていないため、何らかの点でスキーマファイル内に欠けている概念を定義するためマッピングファイル４００内に場所が必要である。
【００５９】
ソースおよびターゲット記述コンポーネント（４０６および４０８）は、これ以降、「ＤａｔａＳｏｕｒｃｅ」要素に対応しているものとする。
【００６０】
マッピングの意味−リレーショナルモデル（ドメイン）
リレーショナルドメイン内のマッピング可能な構造は、カスタムテーブル（ＣｕｓｔｏｍＴａｂｌｅと表す）である。カスタムテーブルは、列／フィールドおよびコマンドの集合体から作成される。カスタムテーブルは、物理的テーブル、ビュー、ＵＤＦまたはストアドプロシージャ、ＳＱＬステートメント（クエリの結果セット）、およびフィルタ処理されたテーブル（条件が適用されたテーブル）などの物理的リレーショナル構造のうちの１つを表すことができる。データベーステーブルはすべてカスタムテーブルであることに注意されたい。ユーザがデータベーステーブルを参照する場合、バックグラウンドでマッピングによりカスタムテーブルが透過的に作成される。それぞれのカスタムテーブルには、Ｑｕｅｒｙ、Ｕｐｄａｔｅ、Ｉｎｓｅｒｔ、およびＤｅｌｅｔｅの４つのコマンドが用意されている。これらのコマンドは、ユーザが明示して作成することも、またマッピングエンジンにより自動的に作成することもできる。カスタムテーブルがデータベーステーブルに基づいている場合、これは、データベーステーブルの関係を継承する（これは、反対方向では生じない）。
【００６１】
カスタムテーブルがマッピングされる毎に、関係ドメイン内に１組のインスタンス（レコードセット、行セットなどとも呼ばれる）を作成する。ユーザが別のマップで作成される１組のインスタンスにマッピングしたいか明示的に識別していない限り、マッピングにより、カスタムテーブルがマッピングされる毎に新しい１組のインスタンスが作成される。
【００６２】
関係−リレーショナルドメイン
２つのカスタムテーブルの間の関係を定義することができる。通常のテーブルに基づくカスタムテーブルは、基本テーブルからすべての関係を継承する。つまり、基本テーブルと他のテーブルとの間には、すでに類似の関係が存在しているため、ユーザ側でカスタムテーブルと他のテーブル（または他のＣｕｓｔｏｍＴａｂｌｅ）の間の関係を作成する必要はないということである。しかし、基本テーブル同士の間に類似の関係がすでに存在しているカスタムテーブル同士の関係を作成しても誤りではない。このような関係を作成するのは、冗長であり、ユーザは基本テーブルに基づく関係を再利用することができる。
【００６３】
関係を継承する一例として、複数のターゲット構造を列の値に基づき同じテーブルから作成することができる単一テーブル継承の事例をあげることができる。次に図５を参照し、ソースドメイン５００とターゲットドメイン５０２の間のマッピングを考察する。ソースドメイン５００は、Ｄｅｐａｒｔｍｅｎｔテーブル５０４とＥｍｐｌｏｙｅｅｓテーブル５０６を含む。Ｄｅｐａｒｔｍｅｎｔテーブル５０４とＥｍｐｌｏｙｅｅｓテーブル５０６の間の関係５０８を定義する。Ｅｍｐｌｏｙｅｅｓテーブル５０６には、Ｄｅｐａｒｔｍｅｎｔｓテーブル５０４からの外部キーがあり、ターゲットドメイン５０２内に類似の関係が構成される。Ｅｍｐｌｏｙｅｅｓテーブル５０６には、３つの値「Ｍ」、「ＨＥ」、および「ＳＥ」を格納するＥｍｐｌｏｙｅｅＴｙｐｅという名前の列がある。ソースドメイン５００からターゲットドメイン５０２へのマッピングの定義では、ターゲットドメイン５０２内でＤｅｐａｒｔｍｅｎｔｓテーブル５０４をＤｅｐａｒｔｍｅｎｔテーブル５１０にマッピングし、「Ｍ」値５１２をＭａｎａｇｅｒテーブル５１４（Ｍ→Ｍａｎａｇｅｒ）にマッピングし、「ＨＥ」値５１６をＨｏｕｒｌｙＥｍｐｌｏｙｅｅテーブル５１８にマッピングし（ＨＥ→ＨｏｕｒｌｙＥｍｐｌｏｙｅｅ）、「ＳＥ」値５２０をＳａｌａｒｙＥｍｐｌｏｙｅｅテーブル５２２にマッピングする（ＳＥ→ＳａｌａｒｙＥｍｐｌｏｙｅｅ）。ソースドメイン５００内の外部キー関係５０８があるため、ターゲットドメイン５０２のＤｅｐａｒｔｍｅｎｔテーブル５１０はＭａｎａｇｅｒテーブル５１４、ＨｏｕｒｌｙＥｍｐｌｏｙｅｅテーブル５１８、およびＳａｌａｒｙＥｍｐｌｏｙｅｅテーブル５２２にリンクする。
【００６４】
外部キーは、ソーステーブルとターゲットテーブルのデータの間のリンクを確立し、強制するために使用される列または列の組合せである。このリンクは、ターゲットテーブルに一次キー値を保持するソーステーブル内の１つまたは複数の列を追加することによりソーステーブルとターゲットテーブルの間に作成される。これらの列は、ターゲットテーブル内の外部キーとなる。
【００６５】
図５の例では、３つのカスタムテーブルＣＴａｂｌｅ（５１２、５１６、および５２０）はＤｅｐａｒｔｍｅｎｔｓテーブル５０４からＥｍｐｌｏｙｅｅｓテーブル５０６に継承されるため、それらのカスタムテーブル（５１４、５１８、および５２２）とＤｅｐａｒｔｍｅｎｔｓテーブル５０４との間の明示的関係を作成する必要はないが、作成する可能性はあり、作成しても誤りではない。基本テーブル（Ｅｍｐｌｏｙｅｅｓ５０６）上の関係５０８はカスタムテーブル（例えば、カスタムテーブル５１４）により共有されるので、ユーザはそのカスタムテーブル５１４と他のテーブルとの間の関係をさらに定義することができる。
【００６６】
以下の規則は、テーブルに基づくカスタムテーブルについて関係をどのように共有するかを説明している。物理的テーブルとカスタムテーブルとの間にマップが存在し、それら２つの間の関係が参照される場合、カスタムテーブルとテーブルとの間の関係は、物理的テーブルとカスタムテーブルが基づいている物理的テーブルとの間の関係であるものとして考えられる。それと反対のことは機能しない、つまり、２つのカスタムテーブルが関係を持つ場合、それらのカスタムテーブルが基づく物理的テーブルはこの関係を共有しないということに注意されたい。２つのカスタムテーブルの間にマップがある場合、参照される関係はカスタムテーブル１とカスタムテーブル２との間の関係、またはカスタムテーブル１とカスタムテーブル２の基本テーブルの間の関係、またはカスタムテーブル１の基本テーブルとカスタムテーブル２の間の関係、またはそれが２つの基本テーブルの間の関係である。
【００６７】
リレーショナルドメイン内の関係は、ＲＳＤ（Ｒｅｌａｔｉｏｎａｌ  Ｓｃｈｅｍａ  Ｄｅｆｉｎｉｔｉｏｎ）のリレーショナル要素を使用して定義される。関係は、データベースで定義されている物理的外部キー制約またはマッピングのニーズに関する関係の新しい定義に基づくことができる。それぞれの関係は、明確に参照できるように一意的な名前を持たなければならない。以下の例を考察する。
【００６８】
【表２】
0004847689.tif 000003
【００６９】
関係は名前により明示的に参照されるため、リレーショナルドメインは、それぞれの関係は異なる１組のＣｏｌｕｍｎＪｏｉｎｓを持つということで区別されるテーブルの同じペアの間で複数の関係を定義することができる。関係要素は、リレーショナルドメインにおけるオペレーション、つまりクエリオペレーションに対するカスタムテーブル間の結合、関連するカスタムテーブルにまたがって更新オペレーションを次から次へと実行するかどうか、更新オペレーションの順序（最初にどのテーブルから削除するかなど）、および更新オペレーションが関係のカーディナリティ（ｃａｒｄｉｎａｌｉｔｙ）とマッチすることのバリデーションをマッピングエンジンで実行するために必要なすべての情報を供給する。
【００７０】
マッピングの意味−オブジェクトドメイン
オブジェクトドメインは、型（クラス）をマッピングを行うためのマッピング可能な構造として公開する。型は、パス表現に基づいてグローバルまたはローカルに関して識別することができる。例えば、Ｔａｒｇｅｔ＝“Ａｄｄｒｅｓｓ”はグローバルクラス「Ａｄｄｒｅｓｓ」を意味するが、Ｔａｒｇｅｔ＝“Ｃｕｓｔｏｍｅｒ／Ａｄｄｒｅｓｓ”はＣｕｓｔｏｍｅｒクラスのフィールドであるＡｄｄｒｅｓｓクラスを意味する。それぞれの型（グローバルまたはローカル）は、リレーショナルドメイン内のただ１つのカスタムテーブルに直接マッピングすることができる（Ｍａｐ要素を使用して）。型は、他の型のメンバを含んでいてもよい、つまり、型マッピングに基づいて作成されたその型のインスタンスを参照しているということである。参照は、オブジェクト関係情報に基づいて作成される。
【００７１】
オブジェクトドメインの型マッピングの意味は、ソースドメイン内のマッピングされたセットの既存のインスタンスに対しオブジェクトドメイン内の型の最大１つのインスタンスが作成され、オブジェクトドメイン内の関係情報に基づきその型への参照をいくつでも作成することができることである。この点を明らかにするために、顧客はアドレスクラス型である「ＭｙＡｄｄｒｅｓｓ」と呼ばれるメンバを持つ顧客およびアドレスクラスを考察する。顧客クラスは、Ｃｕｓｔｏｍｅｒｓテーブルにマッピングされ、アドレスクラスは、アドレステーブルにマッピングされる。ユーザが「Ａｄｄｒｅｓｓ」クラスを取り出すためにマッピングを通じてクエリを発行する場合、同じＩＤを持つＡｄｄｒｅｓｓオブジェクトがすでに存在していない限り、クエリ条件に基づきこのクラスの新しいインスタンスが作成される。ユーザが「Ｃｕｓｔｏｍｅｒ」クラスを取り出す他のクエリを発行し、スパンは「ＭｙＡｄｄｒｅｓｓ」プロパティを含む場合、オブジェクトストア内にすでにインスタンスがなければ「ＭｙＡｄｄｒｅｓｓ」メンバに対し新しいＡｄｄｒｅｓｓオブジェクトが作成される。まず、このインスタンスをオブジェクト空間コンテキスト（オブジェクトドメイン）により管理される「Ａｄｄｒｅｓｓ」オブジェクトコレクションに追加する。次に「ＭｙＡｄｄｒｅｓｓ」フィールドは、「Ａｄｄｒｅｓｓ」インスタンスへの参照により更新される。
【００７２】
マッピングの意味−ＸＭＬモデル（ドメイン）
ＸＭＬドメインは、要素をマッピング構造として、要素および属性をマッピングフィールドとして公開する。以下の理由から、ＸＭＬスキーマの型定義は無視され、マッピング構造とみなされない。ＸＭＬスキーマは、名前付き型と無名型の両方を備える。無名型をマッピングするには、ユーザ側でパス表現を使用することによりそれらの型を識別する必要がある。ＸＭＬドメインでは、ドキュメント内に型があればそれに対し新しいコピーが作成される。なぜなら、オブジェクトドメインとは異なり、ＸＭＬドメインには、その型に基づいてＸＭＬデータを管理するＸＭＬドキュメントストアがなく、すでに作成されている型のインスタンスへの参照が作成されるからである。このようなＸＭＬキャッシュをそのようなストアにできるようにするため、ＸＭＬドメインをマッピングするには、ＸＭＬスキーマにはっきり基づいていない場合にメタデータを追加することで型を明確に定義する必要がある。
【００７３】
型名および要素名は、２つの異なる値空間内にあり、マッピングでは型名と要素名とを区別することができる。
【００７４】
ＸＳＤスキーマ上のＸＰａｔｈのサブセットを使用して、マッピングすることができるインスタンスを識別する。マッピング構文では、オブジェクトドメイン内の型に基づくマッピングだけでなくＸＭＬドメイン内のマッピングをもサポートする。
【００７５】
マッピング要素および属性
マッピングの構文は、マッピング設計セクションでレイアウトされているマッピングの設計および主要事項をサポートするように設計されている。マッピングスキーマの形式は、ＸＭＬとなるように選択されている。ＸＭＬ形式では、マッピングする顧客はＸＭＬ  ＡＰＩを使用してマッピングファイルを作成、維持することができ、また人間によって可読性がよく（ｈｕｍａｎ  ｒｅａｄａｂｌｅ）、マッピングエンジンではＸＭＬスキーマを使用してマッピングファイルのバリデーションを実行することができる。
【００７６】
以下では、１つまたは複数の要素および属性からなるＣｕｓｔｏｍｅｒｓ−Ｏｒｄｅｒｓのマッピングの完全なマッピング例を示している。
【００７７】
【表３−１】
0004847689.tif 000004
【００７８】
【表３−２】
0004847689.tif 000005
【００７９】
ＣｕｓｔｏｍｅｒおよびＯｒｄｅｒはクラスであり、ＣｕｓｔｏｍｅｒクラスはプロパティＭｙＯｒｄｅｒｓを有し、ＯｒｄｅｒクラスはプロパティＭｙＣｕｓｔｏｍｅｒを有するオブジェクトスキーマがマッピングされると仮定すると、マッピングセクションは以下のように変わる。
【００８０】
【表４−１】
0004847689.tif 000006
【００８１】
【表４−２】
0004847689.tif 000007
【００８２】
ＭＡＰＰＩＮＧＳＣＨＥＭＡ要素
ＭａｐｐｉｎｇＳｃｈｅｍａは、マッピングスキーマのルート要素である。これは、有効であるべきＭａｐｐｉｎｇｓおよびＤａｔａＳｏｕｒｃｅｓ要素を含んでいなければならない。ＭａｐｐｉｎｇＳｃｈｅｍａは、メタデータセグメンテーション規則に基づいてセグメント分割できる。マッピング形式はＸＭＬドキュメントである。これは、単一のルート要素ＭａｐｐｉｎｇＳｃｈｅｍａを有する。マッピングファイルには、ソースおよびターゲットのデータソースの記述、それらの間のマッピング、およびマッピングスキーマに渡すことができるパラメータの多数の定義が含まれる。したがって、ルート要素は、ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒｓ、ＤａｔａＳｏｕｒｃｅｓ、およびＭａｐｐｉｎｇｓの下位要素（ｓｕｂ−ｅｌｅｍｅｎｔ）を有する。ＤａｔａＳｏｕｒｃｅｓまたはＭａｐｐｉｎｇｓ下位要素を含まないマッピング要素は、それでも、有効なマッピングスキーマである。このようなマッピングスキーマに対してクエリおよび更新を実行する動作は、そのスキーマを使用する特定の実装により決定される。ユーザは、通常、この要素上ですべての名前空間を定義しなければならない。この要素には、属性はない。これらの下位要素の順序は重要であり、以下の表に示されているように順序付けなければならない。
【００８３】
【表５】
0004847689.tif 000008
【００８４】
例：
【００８５】
【表６−１】
0004847689.tif 000009
【００８６】
【表６−２】
0004847689.tif 000010
【００８７】
ＤＡＴＡＳＯＵＲＣＥ要素
ＤａｔａＳｏｕｒｃｅ要素は、マッピングされたデータソースのスキーマ情報を保持する。データソースは、スキーマの様々なセグメントを表す複数のスキーマファイルを収めることができる。この要素は、仮想ＳＱＬサーバを表す。
【００８８】
属性：
【００８９】
【表７】
0004847689.tif 000011
【００９０】
下位要素：
【００９１】
【表８】
0004847689.tif 000012
【００９２】
Ｓｃｈｅｍａ要素またはＩｎｌｉｎｅＳｃｈｅｍａ要素のいずれが存在していなければならないが、そのうちの１つだけである。例については、マッピングファイルを参照されたい。Ｓｃｈｅｍａ／ＩｎｌｉｎｅＳｃｈｅｍａ要素は、有効なＲＳＤを指していなければならない。
【００９３】
ＤＡＴＡＴＡＲＧＥＴ要素
この要素は、マッピングされたターゲットドメインのスキーマ情報を保持する。これらの拡張要素を使用することにより、情報をドメインスキーマに追加する機能が提供される。これは、スキーマを編集できない場合、またはスキーマがマッピング専用に作成されなかった場合に役立つ。ターゲットスキーマは、セグメント分割できる。
【００９４】
属性：
【００９５】
【表９】
0004847689.tif 000013
【００９６】
下位要素：
【００９７】
【表１０】
0004847689.tif 000014
【００９８】
異なるドメインからのターゲットドメインスキーマのセグメントを含んでいると誤りである。例えば、ＸＭＬスキーマおよびＯｂｊｅｃｔスキーマを混合すると誤りである。
【００９９】
例については、マッピングファイルの例を参照されたい。
【０１００】
ＳＣＨＥＭＡ要素
Ｓｃｈｅｍａ要素は、データソースのスキーマを定義するためにＤａｔａＳｏｕｒｃｅ要素内で使用される。スキーマは、インラインで定義することも、別のファイルで定義することもできる。スキーマが別のＸＳＤ、ＲＳＤなどのファイル（ほとんどのシナリオではこのケースである）で定義されている場合、Ｓｃｈｅｍａ要素を使用しなければならない。ＩｎｌｉｎｅＳｃｈｅｍａ要素は、スキーマドメインの名前空間内でスキーマをインライン（Ｓｃｈｅｍａ要素の本体に含まれる）で定義する場合に使用される（ＸＭＬデータソースに対するＸＳＤなど）。この要素の下位要素はない。以下の属性が重要である。
【０１０１】
【表１１】
0004847689.tif 000015
【０１０２】
例：
【０１０３】
【表１２】
0004847689.tif 000016
【０１０４】
ＩＮＬＩＮＥＳＣＨＥＭＡ要素
Ｓｃｈｅｍａ要素は、データソースのスキーマを定義するためにＤａｔａＳｏｕｒｃｅ要素内で使用される。ＩｎｌｉｎｅＳｃｈｅｍａ要素は、スキーマドメインの名前空間内でスキーマをインライン（Ｓｃｈｅｍａ要素の本体に含まれる）で定義する場合に使用される（ＸＭＬデータソースにはＸＳＤなど）。この要素には、属性はない。この要素には下位要素はない。この要素の本体はスキーマ定義（ＸＳＤ、ＲＳＤ、またはＯＳＤ）を含む。
【０１０５】
例：
【０１０６】
【表１３−１】
0004847689.tif 000017
【０１０７】
【表１３−２】
0004847689.tif 000018
【０１０８】
ＲＥＬＡＴＩＯＮＳＨＩＰＭＡＰ要素
ＲｅｌａｔｉｏｎｓｈｉｐＭａｐは、ＳｏｕｒｃｅドメインとＴａｒｇｅｔドメイン内の関係をマッピングする方法に関する情報を供給するＭａｐ要素の子要素である。ターゲットドメインとソースドメインの両方において一方の構造から他方の構造へ移動するときに使用する関係を識別するために必要である。このセクションでは、マッピングスキーマにおけるこの要素の構文、意味、およびバリデーションについて説明する。読者は、ＲｅｌａｔｉｏｎｓｈｉｐＭａｐの概念に精通していなければならない。ＲｅｌａｔｉｏｎｓｈｉｐＭａｐ要素は、ターゲットドメイン内で、異なるソース構造にマッピングされている２つのマッピングされた構造間の関係が存在する場合に必要である（「マッピングされた構造」とは、「Ｍａｐ」要素を使用してマッピングされた構造を意味する）。このような関係の例として、その型が他のマップ（Ｏｂｊｅｃｔ）内にマッピングされるオブジェクトのフィールド／プロパティおよび他のマッピングされたＸＭＬ要素（ＸＭＬ）の子であるＭａｐｐｅｄ  ＸＭＬ要素がある。
【０１０９】
ＲｅｌａｔｉｏｎｓｈｉｐＭａｐは関係する両方のマップに関してＳｏｕｒｃｅおよびＴａｒｇｅｔとマッチしていなければならないことに注意されたい。以下では、どのようにこのプロセスが働くか、２つのターゲット構造の間に関係が存在すること（上の例を参照）、これら２つのターゲット構造は２つのＭａｐ（２つのＭａｐ要素）によりマッピングされ、これらのＭａｐ上の適用すべきＳｏｕｒｃｅｓはＲｅｌａｔｉｏｎｓｈｉｐＭａｐにおいてＳｏｕｒｃｅとして指定された有効な関係を有することを説明する。
【０１１０】
他のソースにマッピングされた継承またはフィールドなどのターゲットドメイン内の他の種類の関係は、異なるマッピング属性を通じて処理されることに注意されたい（継承に対するＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐおよびＦｉｅｌｄＭａｐ上のフィールドにはＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐ）。
【０１１１】
場合によってはマッピングエンジンはターゲットドメイン内の関係を識別し、（マッピングされているソース（テーブル）の間の）ソースドメイン内のマッチする関係を見つけることによりＲｅｌａｔｉｏｎｓｈｉｐＭａｐを推論することができるが、ＲｅｌａｔｉｏｎｓｈｉｐＭａｐは２つの理由から明示されている必要がある。まず、明示的なＲｅｌａｔｉｏｎｓｈｉｐＭａｐは、関係をＲＳＤに追加してもマッピングが壊れないことを意味している。マッピングエンジンがＲｅｌａｔｉｏｎｓｈｉｐＭａｐを推論し、ＲＳＤにＲｅｌａｔｉｏｎｓｈｉｐが追加された場合、追加された関係は単一の関係を持つように使用される２つのマッピングされたテーブル間の関係である可能性があるためマッピングを中断する可能性がある。関係を追加した後、マッピングエンジンはどの関係を選択するかを知らないため、例外を投げることになる。第２に、（ＲｅｌａｔｉｏｎｓｈｉｐＭａｐを推論することにより）「マジック」を実行し、上の例のようにあいまいな関係が見られる場合に例外を投げる代わりに、ユーザにマッピングという３つの単純な概念をすべて理解することを義務づけると使い勝手が高まる。
【０１１２】
【表１４】
0004847689.tif 000019
【０１１３】
ＳｏｕｒｃｅはＳｏｕｒｃｅ（リレーショナル）ドメイン内の有効な関係でなければならない。このバリデーションは、ソーススキーマのすべてのセグメントがロードされた後に実行される。
【０１１４】
Ｔａｒｇｅｔは、マッピングされたターゲットとの関係を持つターゲットドメイン内の有効な構造でなければならない。Ｔａｒｇｅｔは、ターゲットドメイン内の関係するマッピングされた構造の名前でなければならない。他のマップ内でマップされていない、または親のＭａｐ上でＴａｒｇｅｔとの関係を持たない構造（Ｔｙｐｅ、Ｅｌｅｍｅｎｔ）に対し名前を指定すると誤りである。ＸＭＬドメインでは、Ｔａｒｇｅｔは親マップ上のＴａｒｇｅｔである要素の子でなければならない。親マップは、ＲｅｌａｔｉｏｎｓｈｉｐＭａｐが含まれているＭａｐを参照する。このバリデーションは、マッピングキャッシュ上で実行される。
【０１１５】
関係のリスト内で、親ＭａｐのＳｏｕｒｃｅは、リスト内の最初の関係の「Ｆｒｏｍ」または「Ｔｏ」のいずれかでなければならない。この規則により、第１の関係は親ＭａｐのＳｏｕｒｃｅを必ず含む。このバリデーションは、マッピングキャッシュ上で実行される。
【０１１６】
関係のリスト内で、関係するＴａｒｇｅｔのＭａｐのＳｏｕｒｃｅは、リスト内の最後の関係の「Ｆｒｏｍ」または「Ｔｏ」のいずれかでなければならない。この規則により、最後の関係は関係するマップのＳｏｕｒｃｅを必ず含む。このバリデーションは、マッピングキャッシュ上で実行される。
【０１１７】
Ｓｏｕｒｃｅが関係のリストであれば、そのリストは順序付けられていなければならない。それぞれの関係において、「Ｆｒｏｍ」または「Ｔｏ」は、次の関係の中の「Ｆｒｏｍ」または「Ｔｏ」とマッチしていなければならない。この規則により、テーブルが互いに結合されていないｊｏｉｎ句を持つのは適切でないため、その関係から構築されたＪｏｉｎ／Ｗｈｅｒｅ句は常に有効である。このバリデーションは、マッピングキャッシュ上で実行される。
【０１１８】
２つのマッピングされているターゲット構造同士の関係をマッピングしなければならない。Ｓｏｕｒｃｅ属性を通じてソース構造にマッピングされているターゲットドメイン内で関係が定義されている２つのマッピングされたターゲット構造はＲｅｌａｔｉｏｎｓｈｉｐＭａｐを持たなければならない。「Ｒｅｆ」属性を通じてソース構造にマッピングされているターゲット構造との関係は、その関係のマッピングを必要としない。このバリデーションは、以下のアルゴリズムを使用して実行される。
【０１１９】
マッピングされたターゲット構造毎に他のターゲット構造とのすべての関係を取得する。
｛
対応付けられたターゲット構造毎に
｛
ＩＦ（
関係するターゲット構造はマッピングされる
Ａｎｄ（ＸＭＬドメインにのみ適用し、Ｏｂｊｅｃｔについては無視する）
関係する構造は子要素であり、現在のターゲット構造マップは、「Ｒｅｆ」属性を使用してマッピングされない。
上のバリデーション規則に基づく有効なＲｅｌａｔｉｏｎｓｈｉｐＭａｐが存在することを確認する。
｝
｝
関係するターゲットの定義はターゲットドメインの意味によって異なることに注意されたい。このバリデーションは、マッピングキャッシュ上で実行される。
【０１２０】
マッピングされた関係のＣａｓｃａｄｅＤｅｌｅｔｅ値は一致していなければならない（オブジェクトドメインについてのみ適用）。一致する値の許容可能行列は以下のとおりである。
【０１２１】
【表１５】
0004847689.tif 000020
【０１２２】
任意の他の組合せは誤りである。このバリデーションは、マッピングキャッシュ上で実行される。
関係のカーディナリティ値は一致していなければならず、以下の表に示されている。
【０１２３】
【表１６】
0004847689.tif 000021
【０１２４】
任意の他の組合せは誤りである。このバリデーションは、マッピングキャッシュ上で実行される。例については、標準形式の例を参照されたい。
【０１２５】
ＭＡＰ要素
ソースドメインからのマッピングされた構造のインスタンスが存在すれば、マッピングされたターゲット構造のインスタンスがターゲットドメイン内に存在していなければならないというのがＭａｐ要素の意味である。Ｒｅａｄオペレーションでは、ソースドメイン内に存在するインスタンス毎にターゲットドメイン内の構造のインスタンスが作成される。Ｗｒｉｔｅオペレーションでは、Ｔａｒｇｅｔドメイン内のインスタンスについてこのオペレーションはＳｏｕｒｃｅドメイン内の既存のインスタンス上の等価なオペレーションに変換される。例えば、Ｍａｐ要素を使用してＣｕｓｔｏｍｅｒｓテーブルと顧客オブジェクトまたは要素との間のマッピングを考える。このようなＭａｐには、Ｃｕｓｔｏｍｅｒテーブル内の行毎にＣｕｓｔｏｍｅｒ  Ｏｂｊｅｃｔが作成されるという意味がある。このような顧客オブジェクトを削除すると、Ｃｕｓｔｏｍｅｒｓテーブル内のちょうど１つの行が削除され、新しい顧客オブジェクトを作成すると、Ｃｕｓｔｏｍｅｒｓテーブルに１行挿入され、更新に対して類似のロジックが適用される。上述の既存の１：１マップに対する拡張およびオーバーライドのメカニズムは、ＲＳＤで指定されているＣｕｓｔｏｍＴａｂｌｅにより実現される。マッピングされたテーブル以外の何らかのテーブルに他のレコードを挿入するなどの副作用がありえる。ユーザは、他のテーブルのように各オペレーションタイプ（Ｒｅｔｒｉｅｖｅ、Ｉｎｓｅｒｔ、Ｕｐｄａｔｅ、およびＤｅｌｅｔｅ）に対応するコマンドを持つそのようなＣｕｓｔｏｍＴａｂｌｅにマッピングすることができる。コマンド毎に、ユーザは、ターゲットドメインで実行されるオペレーションに基づいてそのようなコマンドが呼び出されるときにマッピングエンジンにより実行されるＳＱＬ／ＳＰを指定することができる。このコマンドは、ターゲットドメイン内のインスタンス毎にちょうど１回だけ呼び出される（すべてのテーブルは、ａｕｔｏコマンドがｔｒｕｅに設定されているカスタムテーブルであることに注意されたい）。
【０１２６】
同じソース構造を複数のマップで使用することができる。例えば、１つのテーブルを複数のオブジェクト型にマッピングする（ＣｕｓｔｏｍｅｒｓテーブルはＣｕｓｔｏｍｅｒオブジェクトおよびＣｕｓｔｏｍｅｒＩｎｆｏオブジェクトにマッピングされる）、または同じテーブルを複数のＸＭＬ要素にマッピングする（ＣｕｓｔｏｍｅｒｓテーブルはＣｕｓｔｏｍｅｒの上位要素にマッピングされ、Ｃｕｓｔｏｍｅｒ要素はＣｏｍｐａｎｙ要素の下にマッピングされる）という操作がある。このようなマッピングは、イテレータ（ｉｔｅｒａｔｏｒ）とも呼ばれる新しいセットがすべてのマップについてＳｏｕｒｃｅドメイン内に（クエリコマンドを使用して）作成されるという意味を持つ。ユーザは、Ｓｏｕｒｃｅの代わりにＲｅｆ属性を用意することにより同じセットを使用することができる。
【０１２７】
属性：
【０１２８】
【表１７】
0004847689.tif 000022
【０１２９】
下位要素：
【０１３０】
【表１８】
0004847689.tif 000023
【０１３１】
Ｔａｒｇｅｔは、ＤａｔａＴａｒｇｅｔ内の有効な構造である。Ｔａｒｇｅｔドメイン内に存在しないターゲットを指すマップを持つのは誤りである。このバリデーションは、マッピングキャッシュ上で実行される。Ｓｏｕｒｃｅが存在している場合、ＤａｔａＳｏｕｒｃｅ内の有効な構造でなければならない。Ｓｏｕｒｃｅドメイン内に存在しないソースを指すマップを持つのは誤りである。このバリデーションは、マッピングキャッシュ上で実行される。
【０１３２】
ターゲット構造は、１度しかマッピングできない。この規則により、マッピングを更新可能にすることができるが、それは、Ｔａｒｇｅｔ構造を１度しかマッピングできず、ターゲットドメイン内のその構造の任意のインスタンスは、あいまいなところなく、ソース（リレーショナル）ドメインに書き込むことができる。ユーザは、読み取りまたは書き込みの方向でターゲット構造を複数回マッピングしたい場合、ソース（リレーショナル）ドメイン内でＣｕｓｔｏｍテーブルを使用するとよい。このバリデーションは、マッピングキャッシュ上で実行される。
【０１３３】
Ｍａｐ名は、マッピングスキーマ間で一意である。他のマップからこのマップにあいまいなところなく参照できるようにするには、Ｍａｐ名はマッピングファイルにまたがって一意である必要がある。ＲｅｆおよびＢａｓｅｄＯｎＭａｐなどの既存のＭａｐを参照する必要があるいくつかの機能性がある。このバリデーションは、マッピングキャッシュ上で実行される。
【０１３４】
Ｒｅｆ属性は有効なＭａｐを指していなければならない。Ｒｅｆ属性の値は、マッピングスキーマ内の既存の有効なマップの名前でなければならない。このバリデーションは、マッピングキャッシュ上で実行される。ＲｅｆおよびＳｏｕｒｃｅ属性は相互排他的である。同じマップ上に複数のソースがあることは許されないため、このマップで他のマップからのＳｏｕｒｃｅを使用することを意味するＲｅｆ属性が、同じＭａｐ上のＳｏｕｒｃｅと共存することはできない。
【０１３５】
ＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐ属性はＢａｓｅｄＯｎＭａｐがないと存在できない。ＲｅｆおよびＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐ属性は相互排他的である。Ｒｅｆ属性は、すでにスコープ内にあるＳｏｕｒｃｅ（イテレータ）を指しており、したがって関係を指定する必要はない。
【０１３６】
Ｒｅｆは、Ｏｂｊｅｃｔ−Ｒｅｌａｔｉｏｎａｌマッピングには使用できない。Ｒｅｆ属性の意味は、オブジェクト−リレーショナルマッピングには適用されない。  
例については、上述の完全なマッピングの例を参照されたい。
【０１３７】
ＦＩＥＬＤＭＡＰ下位要素
ＦｉｅｌｄＭａｐ要素は、一方のドメインから他方のドメインに値をコピーするオペレーションを表す。マッピングエンジンは、単に、読み込み時にＳｏｕｒｃｅフィールドの値をＴａｒｇｅｔフィールドにコピーし、書き込み時にその逆の方向にコピーするだけである。場合によっては、これらの値は異なるＳｏｕｒｃｅ（テーブル）を出所としており、したがって、Ｓｏｕｒｃｅ／Ｒｅｆ／ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐ属性から、その値を取得する方法に関する必要な情報が得られる。ＦｉｅｌｄＭａｐを使用すると、ＮＵＬＬ値変換の定義および書き込みオペレーションの同時実行オプションの設定を行うことができる。
【０１３８】
ＦｉｅｌｄＭａｐを使用すると、ターゲット側のデータを非正規化することができる。ターゲットフィールド（オブジェクト−フィールドなど）は、１度しかマッピングできない。しかし、ＳｏｕｒｃｅＦｉｅｌｄは、何度もマッピングできる。これは、ユーザがターゲットドメイン内のデータを非正規化したい場合のシナリオをサポートするために許容されている。ＯｒｄｅｒｓテーブルにはＣｕｒｒｅｎｃｙＩＤに対するフィールドが１つあり、Ｏｒｄｅｒオブジェクトには金額フィールド毎に、例えば、ＦｒｅｉｇｈｔＡｍｏｕｎｔとＦｒｅｉｇｈｔＣｕｒｒｅｎｃｙ、ＴａｘＡｍｏｕｎｔとＴａｘＣｕｒｒｅｎｃｙに対し１つの通貨フィールドがあるシナリオを考える。更新後、マッピングエンジン変更プロセッサ（ＣＰ）は、更新され、同じソースフィールドにマッピングされるターゲットフィールドが同じ値を持つことを検証する。
【０１３９】
同じソースを持つ複数のＦｉｅｌｄＭａｐｓは、ユーザが同じセット（変数またはイテレータともいう）を参照していることを意味する。これは、最も単純で、最も直観的な動作であり、ユーザが同じ関係について異なるセットを使用したいシナリオはない。ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐを変更するということは、異なるキーに基づいて一方のテーブルを他方のテーブルに結合することが新しい結果セットを作成することを意味するので、新しいセットを意味することに注意されたい。これを明確にし、明示するため、この動作の意味は、すべてのＳｏｕｒｃｅが新しいセット（結果セット上のイテレータ）を意味するＭａｐの意味と異なっている。
【０１４０】
属性：
【０１４１】
【表１９】
0004847689.tif 000024
【０１４２】
ＳｏｕｒｃｅＦｉｅｌｄまたはＴａｒｇｅｔＦｉｅｌｄの値の先頭に「＄」が付いている場合、他のフィールド（ＳｏｕｒｃｅＦｉｅｌｄまたはＴａｒｇｅｔＦｉｅｌｄ）はＭａｐｐｉｎｇＰａｒａｍｅｔｅｒにマッピングされる。ＳｏｕｒｃｅＦｉｅｌｄがＭａｐｐｉｎｇＰａｒａｍｅｔｅｒである場合、これはＲｅａｄＯｎｌｙ  ＦｉｅｌｄＭａｐであり、更新オペレーションが実行されていないことを意味する。ＳｏｕｒｃｅＦｉｅｌｄ／ＴａｒｇｅｔＦｉｅｌｄバリデーション：これらの属性の値は親Ｍａｐ  Ｓｏｕｒｃｅ／Ｔａｒｇｅｔ構造上の有効なフィールドに、またはＭａｐｐｉｎｇＰａｒａｍｅｔｅｒにそれぞれ正常に解決されなければならない。これらの属性の値が「＄」符号から始まっている場合、これは、マッピングパラメータセクションで宣言されているマッピングパラメータに解決されなければならない。このバリデーションは、マッピングキャッシュ上で実行される。
【０１４３】
Ｓｏｕｒｃｅ／Ｒｅｆ／ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐはソースドメイン内で有効でなければならない。Ｓｏｕｒｃｅはソースドメイン内の有効な構造（ＣｕｓｔｏｍＴａｂｌｅ）に解決されなければならず、Ｒｅｆは既存のマップの名前でなければならず、ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐはソースドメイン内の有効な関係の名前でなければならない。このバリデーションは、マッピングキャッシュ上で実行される。
【０１４４】
Ｒｅｆおよび（Ｓｏｕｒｃｅ／ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐ）は相互排他的である。Ｒｅｆの意味は異なるマップからのＳｏｕｒｃｅであるため、そのソースは、スコープ内になければならず、ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐの必要はない。
【０１４５】
ＳｏｕｒｃｅがＦｉｅｌｄＭａｐ上に存在する場合、ＭａｐｐｉｎｇではＭａｐのソースとＦｉｅｌｄＭａｐのＳｏｕｒｃｅとの関係がわかっている必要があるため、ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐが存在していなければならない。
【０１４６】
ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐは、ＳｏｕｒｃｅがＦｉｅｌｄＭａｐ上に存在していなければ与えることができない。Ｓｏｕｒｃｅが存在していない場合、これは、ＳｏｕｒｃｅＦｉｅｌｄが親マップソース構造に属していることを意味する。したがって、関係情報を必要としない。
【０１４７】
どの特定のターゲットフィールドも、１度しかマッピングできない。概念的には、両方のドメインのフィールドはスカラー値であり、したがって、ＳｏｕｒｃｅＦｉｅｌｄからＴａｒｇｅｔＦｉｅｌｄに値をコピーすることはあいまいであってはならず、マージの意味を持つことはできない。
【０１４８】
ＳｏｕｒｃｅＦｉｅｌｄおよびＴａｒｇｅｔＦｉｅｌｄを両方ともマッピングパラメータとすることはできない。一方のＭａｐｐｉｎｇＰａｒａｍｅｔｅｒを他方のＭａｐｐｉｎｇＰａｒａｍｅｔｅｒにマッピングするのは無意味である。
【０１４９】
ＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙは、ＳｏｕｒｃｅＦｉｅｌｄがＭａｐｐｉｎｇＰａｒａｍｅｔｅｒであれば指定できない。マッピングパラメータに関しては、適用できない。
【０１５０】
ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐのカーディナリティ値は、ＴａｒｇｅｔＦｉｅｌｄ型と互換性がなければならない。ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐカーディナリティがＯｎｅＴｏＯｎｅである場合、ＴａｒｇｅｔＦｉｅｌｄ型はスカラーでなければならず、そうでない場合、誤りである。ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐカーディナリティがＯｎｅＴｏＭａｎｙである場合、ＴａｒｇｅｔＦｉｅｌｄ型はリスト型でなければならず、そうでない場合、誤りである。（オブジェクトマッピングでは、このケースはサポートされない）。このバリデーションは、コンパイル時にターゲットフィールドの型と関係のカーディナリティとの間の不整合を検出する場合、例えば、Ｃｕｓｔｏｍｅｒクラス上の「ｏｉｄ  ｉｎｔ」型プロパティは、Ｃｕｓｔｏｍｅｒクラスと多対１の関係を持つＯｒｄｅｒｓテーブルのｏｄｅｒＩｄ列にマッピングされる場合に使用できる。
【０１５１】
Ｒｅｆは、Ｏｂｊｅｃｔ−Ｒｅｌａｔｉｏｎａｌマッピングには使用できない。Ｒｅｆの意味は、オブジェクト−リレーショナルのマッピングには適用されない。例については、完全なマッピングの例を参照されたい。
【０１５２】
ＯＶＥＲＦＬＯＷＭＡＰ下位要素
この要素は、常に「Ｍａｐ」要素に含まれ、Ｏｖｅｒｆｌｏｗをマップするために使用される。Ｏｖｅｒｆｌｏｗは、明示的にマッピングされない包含変数の中にある何かとして定義される。これは、アンマップされた属性および開いているコンテンツを持つＸＭＬ要素に使用される。この要素は、Ｏｂｊｅｃｔマッピングには適用できず、したがって、リレーショナルドメインとオブジェクトドメインの間でマッピングされるマッピングスキーマ内にこの要素を保持するのは誤りである。
【０１５３】
Ｏｖｅｒｆｌｏｗ  ＳｏｕｒｃｅＦｉｅｌｄは、Ｍａｐ  ＴａｒｇｅｔＳｔｒｕｃｔｕｒｅ要素をルート要素としている有効なＸＭＬドキュメント（文字列として格納されている）を含まなければならない。クエリでマッピングを使用する場合、ルートノード上の属性は、ＴａｒｇｅｔＳｔｒｕｃｔｕｒｅ要素に追加され、下位要素は、その要素の子要素として追加される。
【０１５４】
書き込みのシナリオに対しマッピングを使用する場合、ＴａｒｇｅｔＳｔｒｕｃｔｕｒｅ要素と同じ名前を持つＸＭＬ要素が作成され、スキーマ内にないか、またはマッピングされないその要素の属性はルート要素に追加される。マッピングされない、またはスキーマ内にない下位要素は、その要素のテキスト内容を含むその要素の子要素として追加される。
【０１５５】
ユーザは、クエリを実行し、オーバーフローデータに更新することができ、この動作は融合（ｆｕｓｉｏｎ）として参照される。誤り状態は次のとおりである。
【０１５６】
Ｑｕｅｒｙ−マッピングされた属性をオーバーフローフィールド（属性条件の複製を作成する）内に持つ。
【０１５７】
Ｑｕｅｒｙ−ＴａｒｇｅｔＳｔｒｕｃｔｕｒｅ要素のテキスト内容をマッピングさせ、オーバーフローフィールドに含める。
【０１５８】
属性：
【０１５９】
【表２０】
0004847689.tif 000025
【０１６０】
この要素には、下位要素がない。
【０１６１】
ＭＡＰＰＩＮＧＰＡＲＡＭＥＴＥＲ要素
マッピングパラメータの意味では、実行時に知られている値をソースまたはターゲットフィールドにマッピングできる。ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒは、ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒｓセクションで宣言され、マッピングＡＰＩを通じて実行時にアクセスすることができる。ＦｉｅｌｄＭａｐのＮｕｌｌＨａｎｄｌｉｎｇ設定はＭａｐｐｉｎｇＰａｒａｍｅｔｅｒにも適用される。ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒは、ＳｏｕｒｃｅＦｉｅｌｄまたはＴａｒｇｅｔＦｉｅｌｄのいずれかとして使用することができる。マッピングエンジンは、ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒ名の先頭に付いている＄プレフィックスに基づいてそれらを区別する。（＄は、すべてのマッピングされたドメイン、つまりオブジェクト、ＸＭＬ、およびＲｅｌａｔｉｏｎａｌ（エスケープできる）では識別子に使用すると不正文字となる）。ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒはアンタイプされ（ｕｎｔｙｐｅｄ）、したがってそのＸＳＤ型は文字列である。実行時に、マッピングエンジンはこの値をマッピングされたフィールド型の型に変換する（ターゲットフィールドまたはソースフィールドのいずれか）。
【０１６２】
この要素のテキスト内容は、このパラメータのデフォルト値である。この値は、ＯｂｊｅｃｔＳｐａｃｅ、ＸＱｕｅｒｙＰｒｏｃｅｓｓｏｒ、Ｂｕｌｋｌｏａｄ、およびＸＭＬＡｄａｐｔｅｒなどのマッピングを使用するアプリケーションにより実行時に変更することができる。
【０１６３】
属性：
【０１６４】
【表２１】
0004847689.tif 000026
【０１６５】
ＳｏｕｒｃｅＦｉｅｌｄ／ＴａｒｇｅｔＦｉｅｌｄ／ＮｕｌｌＶａｌｕｅの値が「＄＄」で始まる場合、これはマッピングパラメータではないことを意味し、実際の値は単一の「＄」で始まる。ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒは、ＳｏｕｒｃｅＦｉｅｌｄ、ＴａｒｇｅｔＦｉｅｌｄ、またはＮｕｌｌＶａｌｕｅの値としてしか使用できない。マッピングエンジンは、そのフィールドマッピングに基づいてマッピングパラメータ値を与えることはできない。これらは、ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒはＳｏｕｒｃｅＦｉｅｌｄにマッピングされ、書き込みオペレーションで使用され、読み込みオペレーションでは無視されるというマッピングコンテキストで適用され、使用される。ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒは、ＴａｒｇｅｔＦｉｅｌｄにマッピングされ、読み込みオペレーションに使用され、書き込みオペレーションで無視される。したがって、ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒは、出力パラメータとして使用することはできない。
【０１６６】
Ｂｕｌｋｌｏａｄでは、ユーザは何回も、データをＸＳＤスキーマに含まれないデータベースに挿入したい場合がある。このデータは、通常、実行時にしか判明せず、ＸＭＬドキュメントの一部として含まれない。例えば、ｕｓｅｒｉｄ、マシンＩＤなどがある。
【０１６７】
ユーザは、マッピングスキーマにまたがって使用されるＮｕｌｌＶａｌｕｅを統一したい場合がある。これは、ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒを所定のデフォルト値で作成し、多くのＦｉｅｌｄＭａｐｓ内のＮｕｌｌＶａｌｕｅ属性の値においてこのマッピングパラメータを使用することにより実行される。
【０１６８】
バリデーションに関しては、ＭａｐｐｉｎｇＰａｒａｍｅｔｅｒの名前は文字「＄」で始まらなければならない。任意の他の文字があるとエラーになる。名前は、「＄＄」で始めることはできない。このため、ユーザが「＄」で始まる有効なドメインフィールド名を持つ場合、またはＮＵＬＬ値を「＄」として示したい場合に、「＄」記号をエスケープすることができる。
【０１６９】
名前は、実行時にマッピングパラメータの値をソースまたはターゲットフィールドに割り当てるときに、あいまいさの発生を回避するためにマッピングスキーマ上で一意的でなければならない。名前の一意性はマッピングスキーマのロードされているすべてのセグメントにまたがるものであることに注意されたい。
【０１７０】
ＢＡＳＥＤＯＮＭＡＰ−ＢＡＳＥＤＯＮＲＥＬＡＴＩＯＮＳＨＩＰ属性
設計ガイドラインとして、すべての必要なマッピング情報は、ドメインからではなく、マッピングファイル内のマッピングセクションから与えられる。したがって、継承および再帰では、ユーザは再帰要素および継承されたクラスフィールドをマッピングするための情報を明示的に供給する必要がある。ユーザは、「ＢａｓｅｄＯｎＭａｐ」属性を構文的なショートカットとして使用することにより、ＦｉｅｌｄＭａｐｓおよびＲｅｌａｔｉｏｎｓｈｉｐＭａｐｓを一方のＭａｐから他方のマップへコピーすることができる。これにより、マッピングエンジンは、Ｏｂｊｅｃｔ継承シナリオおよびＸＭＬ再帰シナリオにおいて、マッピング構文を明示し、ドメインから独立させることにより、ＦｉｅｌｄＭａｐｓおよびＲｅｌａｔｉｏｎｓｈｉｐＭａｐｓをコピーするのに必要な情報を取得することができる。ＢａｓｅｄＯｎＭａｐオプションでは、ＦｉｅｌｄＭａｐｓおよびＲｅｌａｔｉｏｎｓｈｉｐＭａｐｓをそのまま「ＢａｓｅｄＯｎＭａｐ」属性の値として名前が参照されるＭａｐからコピーする。コピーされたＦｉｅｌｄＭａｐｓ／ＲｅｌａｔｉｏｎｓｈｉｐＭａｐｓは、ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐ属性を含む基本のマップと同じである。
【０１７１】
ＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐは、Ｍａｐ上のＳｏｕｒｃｅがＢａｓｅｄＯｎＭａｐが指定されているＭａｐ上のＳｏｕｒｃｅと異なる場合に使用される。したがって、すべての関連するソース情報および関係（ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐ、ＲｅｌａｔｉｏｎｓｈｉｐＭａｐ）を作成および更新する必要がある。ＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐ属性を指定すると、Ｓｏｕｒｃｅ属性はＢａｓｅｄＯｎＲｅｉａｔｉｏｎｓｈｉｐ属性の値とともにベースＭａｐおよびＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐで指定されているようにＳｏｕｒｃｅの値とともにコピーされたＦｉｅｌｄＭａｐｓに追加される。コピーされたＦｉｅｌｄＭａｐｓがすでに、Ｃｏｐｉｅｄ  ＲｅｌａｔｉｏｎｓｈｉｐＭａｐに関して、ＳｏｕｒｃｅおよびＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐ属性を有する場合、これらの属性は新しいマップ上のソースとマップに基づくＳｏｕｒｃｅとの間の関係とともに更新される。
【０１７２】
ＢａｓｅｄＯｎＭａｐおよびＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐの属性は両方とも、構文的ショートカットを使用可能にするマクロとして解釈することができる。以下の説明および規則では、ＢａｓｅｄＯｎＭａｐＶａｌｕｅ（ＢａｓｅｄＯｎＭａｐ属性によって指定された値）、およびＢａｓｅｄＲｅｌａｔｉｏｎｓｈｉｐＶａｌｕｅ（ＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐ属性によって指定された値）の２つのキーワードを使用する。
【０１７３】
ＢａｓｅｄＯｎＭａｐの値は、ＦｉｅｌｄＭａｐのコピー元のＭａｐ名である。これは、単に、ＦｉｅｌｄＭａｐｓを、指されている名前付きＭａｐからＢａｓｅｄＯｎＭａｐが宣言されているＭａｐにコピーするだけである。すべての子ＦｉｅｌｄＭａｐｓおよびＲｅｌａｔｉｏｎｓｈｉｐＭａｐ要素をそのすべての属性とともに、名前がＢａｓｅｄＯｎＭａｐＶａｌｕｅであるＭａｐからＢａｓｅｄＯｎＭａｐ属性が指定されているＭａｐ要素にコピーする。
【０１７４】
ＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐ属性とＢａｓｅｄＯｎＭａｐ属性。すべてのＦｉｅｌｄＭａｐ要素について、関連するＦｉｅｌｄＭａｐｓを見つけて更新する。名前がＢａｓｅｄＯｎＭａｐＶａｌｕｅであるＭａｐからすべての子ＦｉｅｌｄＭａｐｓ要素を見つける。ＦｉｅｌｄＭａｐｓ上にＳｏｕｒｃｅ属性が存在している場合には、値をそのままにしておき、そうでなければ、Ｓｏｕｒｃｅ属性を名前がＢａｓｅｄＯｎＭａｐＶａｌｕｅであるＭａｐ要素上のＳｏｕｒｃｅ属性の値とともにＦｉｅｌｄＭａｐｓに追加する。
【０１７５】
ＦｉｅｌｄＭａｐｓ上にＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐ属性が存在する場合、ＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐ属性の先頭に空白（“  ”）を挿入する。ＢａｓｅｄＲｅｌａｔｉｏｎｓｈｉｐＶａｌｕｅをＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐの先頭に挿入し、さもなければＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐ属性をＢａｓｅｄＲｅｌａｔｉｏｎｓｈｉｐＶａｌｕｅの値とともに追加する。
【０１７６】
修正されたＳｏｕｒｃｅおよびＳｏｕｒｃｅＲｅｌａｔｉｏｎｓｈｉｐ属性および他の変更されていないそのままのすべての属性を持つすべてのＦｉｅｌｄＭａｐ要素をＢａｓｅｄＯｎＭａｐおよびＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐ属性が指定されているＭａｐ要素の中に入れる。
【０１７７】
名前がＢａｓｅｄＯｎＭａｐＶａｌｕｅであるＭａｐからすべての子ＲｅｌａｔｉｏｎｓｈｉｐＭａｐ要素を見つけ、その属性をすべてそのままに維持する。すべてのＲｅｌａｔｉｏｎｓｈｉｐＭａｐ要素について、Ｓｏｕｒｃｅ属性の値の先頭に空白（“  ”）を挿入する。ＢａｓｅｄＲｅｌａｔｉｏｎｓｈｉｐＶａｌｕｅをＳｏｕｒｃｅ属性の先頭に挿入する。すべてのＲｅｌａｔｉｏｎｓｈｉｐＭａｐ要素を、修正されたＳｏｕｒｃｅ属性および他のすべての変更されていない属性とともにＢａｓｅｄＯｎＭａｐおよびＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐ属性が指定されているＭａｐ要素にコピーする。
【０１７８】
上述の意味では、以下の規則が適用される。ＢａｓｅｄＯｎＭａｐは、有効なＭａｐ名を参照しなければならない。ＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐは、ソースドメイン内の有効なＲｅｌａｔｉｏｎｓｈｉｐ名を参照しなければならない。ＢａｓｅｄＯｎＲｅｌａｔｉｏｎｓｈｉｐが指定されている場合、有効なＢａｓｅｄＯｎＭａｐが存在していなければならない。コピーされたＦｉｅｌｄＭａｐｓは、明示的に定義されている場合のように他のすべてのマッピング規則が適用される。
【０１７９】
ＸＭＬ事例でのＢＡＳＥＤＯＮＲＥＬＡＴＩＯＮＳＨＩＰの使用例
表：
Employee(EID,FirstName,LastName,HireDate,Salary,Manager)
FiredEmployee(EID,FirstName,LastName,HireDate,Salary,Manager)
ＸＭＬでの結果の例：
【０１８０】
【表２２】
0004847689.tif 000027
【０１８１】
マッピング：
【０１８２】
【表２３−１】
0004847689.tif 000028
【０１８３】
【表２３−２】
0004847689.tif 000029
【０１８４】
マッピングエンジンで作成されたとおりの実際のＭａｐ：
【０１８５】
【表２４】
0004847689.tif 000030
【０１８６】
テーブル階層間の継承（オブジェクト）
表：
Persons(SSID,FirstName,LastName)
Employees(EID,EmployeeSSID,HireDate,Salary,Manager)
Managers(EID,Bonus)
【０１８７】
【表２５】
0004847689.tif 000031
【０１８８】
継承階層：Ｐｅｒｓｏｎ→Ｅｍｐｌｏｙｅｅ→Ｍａｎａｇｅｒ
マッピング：
【０１８９】
【表２６】
0004847689.tif 000032
【０１９０】
マッピングエンジンで作成されたとおりの実際のマップ：
【０１９１】
【表２７−１】
0004847689.tif 000033
【０１９２】
【表２７−２】
0004847689.tif 000034
【０１９３】
同じ基本テーブル（異なるカスタムテーブル）例（オブジェクト）を使用した継承
ＲＳＤ：
【０１９４】
【表２８】
0004847689.tif 000035
【０１９５】
ＭＡＰ：
【０１９６】
【表２９】
0004847689.tif 000036
【０１９７】
つまり、以下を意味する。
【０１９８】
【表３０】
0004847689.tif 000037
【０１９９】
ＮＵＬＬＨＡＮＤＬＩＮＧ属性
値ＮＵＬＬは、列のデータ値が不明であるか、または使用可能でないことを意味する。ＮＵＬＬは、ゼロ（数値としても２進数値としても）、長さゼロの文字列、または空白（文字値）と同義でない。むしろ、ＮＵＬＬ値を使用した場合、ゼロ（数値列）または空白（文字の列）および非入力（数値と文字の両方の列についてＮＵＬＬ）を区別することができる。どの２つのＮｕｌｌ値も等しくはない。２つのＮＵＬＬ値の比較、またはＮＵＬＬと他の値との比較では、ｕｎｋｎｏｗｎを返すが、それは各ＮＵＬＬの値が不明だからである。ＮＵＬＬ値は、通常、不明な、適用できない、または後から付け加えるべきデータを示す。例えば、顧客のミドルイニシャルは、顧客発注時には知られていない可能性がある。ＮＵＬＬのマッピングは、値が不明であるので複合タスクであり、各ドメインはその概念（Ｎｕｌｌ）を異なった形で表現する。ときには、複数の異なる方法で表現することもでき、例えば、ＸＭＬドメインではＮｕｌｌをｘｓｉ：ｎｉｌ、なし（ａｂｓｅｎｃｅ）、または空リストで表現することができ、またオブジェクトドメインはＮＵＬＬ化可能型（ｎｕｌｌａｂｌｅ  ｔｙｐｅｓ）、およびＤＢＮｕｌｌである、ＳＱＬ型を有する。さらに、ユーザは、Ｎｕｌｌを表すＴａｒｇｅｔドメイン内の値を選択したい場合があり、その値はＮｕｌｌイメージと呼ばれることが多い。
【０２００】
ＮｕｌｌＨａｎｄｉｎｇ属性を使用すると、Ｎｕｌｌをソースドメインからターゲットドメイン内のＮＵＬＬ表現に変換することができ、またその逆に変換することもできる（ターゲットドメイン内の値からソースドメイン内のＮＵＬＬに）。
【０２０１】
【表３１】
0004847689.tif 000038
【０２０２】
Ｓをソース（リレーショナル）ドメイン内のＳｏｕｒｃｅＦｉｅｌｄとして、Ｔをターゲット（オブジェクト、ＸＭＬ）ドメイン内のＴａｒｇｅｔＦｉｅｌｄとして定義する。Ｓ（Ｎｕｌｌ）←→Ｔ（ＮｕｌｌＨａｎｄｌｉｎｇ属性に基づく値）。これは、クエリ時に、データベース（ＤＢ）内のＮｕｌｌはＮｕｌｌＨａｎｄｌｉｎｇ、ＮｕｌｌＶａｌｕｅ属性で指定された値に出力されることを意味する。更新時に、ターゲットドメイン内の値が上の属性で指定された値であれば、ターゲットドメイン内の値はソースドメイン内のｎｕｌｌに変換される。ターゲットドメイン内のＮｕｌｌ処理に対するデフォルトおよび特定の動作は、各ターゲットドメイン指定で設定される。
【０２０３】
新しいターゲット構造（ＯｂｊｅｃｔまたはＸＭＬ要素）を作成し、フィールドにＮｕｌｌ値を割り当てる、またはＸＭＬ属性を省く場合、更新エンジンによるデフォルトの動作では、値は、列で定義されているデフォルト値に設定される。デフォルト値がない場合、Ｎｕｌｌが適用されることを意味する。
【０２０４】
ＦｏｒｃｅＮｕｌｌＯｎＩｎｓｅｒｔは、ユーザが上述のデフォルト動作をオーバーライドしたい場合をサポートしている。この場合、ユーザは、更新エンジンがＮｕｌｌを明示的に列に書き込み、列で定義されていたデフォルトをオーバーライドすることを望んでいる。ＦｏｒｃｅＮｕｌｌＯｎＩｎｓｅｒｔ属性をＴＲＵＥに設定すると、オブジェクト／要素が作成されたときに、ターゲットドメイン内の任意のｎｕｌｌ値についてｎｕｌｌが明示的に列の中に挿入される。この特徴に対する主要なシナリオでは、ＮｕｌｌをＩｎｓｅｒｔストアドプロシージャ（カスタムテーブルのｉｎｓｅｒｔコマンドとして公開されている）のパラメータに受け渡すことを可能にする。
【０２０５】
ＮｕｌｌＶａｌｕｅは、ＮｕｌｌＨａｎｄｌｉｎｇ値が「ＵｓｅＮｕｌｌＶａｌｕｅ」の場合に与えることができる。
【０２０６】
ＮｕｌｌＶａｌｕｅとしての空白文字列−この例では、ユーザは顧客のミドルイニシャルプロパティに対しｎｕｌｌを意味する空文字列を指定したい。
【０２０７】
【表３２】
0004847689.tif 000039
【０２０８】
ｎｕｌｌ処理にＤｏｍａｉｎＮｕｌｌを使用する−この例では、ＭＩは、ＸＭＬドメイン内の要素の名前である。
【０２０９】
【表３３】
0004847689.tif 000040
【０２１０】
ＸＭＬは＜ＭＩ  ｘｓｉ：ｎｉｌ＝“ｔｒｕｅ”／＞となる。
【０２１１】
ＵＳＥＦＯＲＣＯＮＣＵＲＲＥＮＣＹ属性
この属性を必要とする背景にある理論と理由は、Ｏｐｔｉｍｉｓｔｉｃ  Ｃｏｎｃｕｒｒｅｎｃｙドキュメントに明記されている。同時実行がＭａｐｐｉｎｇで指定され、ＲＳＤでは指定されていない理由は、特定のシナリオで、ユーザは異なる同時実行設定を好むことである。２つのクラスにマッピングされた非正規化されたテーブルを考える。これらのクラスには、同時実行制御に使用すべき異なるフィールドがある。一般に、人々は、そのビジネスロジックで推し進められる異なるマッピングで同じＲＳＤ情報を共有することを望む。ＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙ属性は列挙型であり、値は、Ａｌｗａｙｓ（このフィールドは常に同時実行に使用され、デフォルト値である）、Ｎｅｖｅｒ（このフィールドは同時実行には決して使用されない）、およびＭｏｄｉｆｉｅｄ（このフィールドは値が変更された場合のみ同時実行に使用される）である。
【０２１２】
ＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙ属性は、ＦｉｅｌｄＭａｐとＭａｐの両方で使用することができる。デフォルトのメカニズムは以下のとおりである。ＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙが指定されていない場合、デフォルトは「Ａｌｗａｙｓ」である。ＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙがＭａｐ上で指定されている場合、ＦｉｅｌｄＭａｐまたはＲｅｌａｔｉｏｎｓｈｉｐＭａｐでＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙがすでに定義されていない限り、それはＭａｐに関わるすべてのＦｉｅｌｄＭａｐおよびＲｅｌａｔｉｏｎｓｈｉｐｓに対するＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙの値として使用される。この場合、定義済みの値はＭａｐ上で指定されているデフォルトをオーバーライドする。ＦｉｅｌｄＭａｐ上で指定されたＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙは、ＭａｐまたはＲｅｌａｔｉｏｎｓｈｉｐＭａｐのいずれかで定義されているＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙをオーバーライドする。
【０２１３】
ユーザは、ＲｅｌａｔｉｏｎｓｈｉｐＭａｐ要素でＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙ属性を指定することにより明示的にマッピングされていない関係フィールドに対する同時実行設定を制御することができる。ＲｅｌａｔｉｏｎｓｈｉｐＭａｐ上で行ったこの属性の設定はすべての関係フィールドに適用されることに注意されたい。
【０２１４】
バリデーションは以下のように働く。Ａｌｔｅｒｎａｔｅ  Ｋｅｙ  ＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙ＝Ａｌｗａｙｓであれば、これは同時実行に使用され、Ｐｒｉｍａｒｙ  Ｋｅｙ同時実行は、他のフィールドとしてのデフォルト規則に基づいて判別される。さもなければ、Ａｌｔｅｒｎａｔｅ  Ｋｅｙが存在していないか、ＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙ＝Ａｌｗａｙｓとマークされていない場合、Ｐｒｉｍａｒｙ  Ｋｅｙ  ＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙのデフォルトとしてＡｌｗａｙｓに設定される（マッピングエンジンは、Ｍａｐ  ＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙ値を無視する）。一次キーＦｉｅｌｄＭａｐのＵｓｅＦｏｒＣｏｎｃｕｒｒｅｎｃｙ値が明示的に他の値に設定された場合（ＮｅｖｅｒまたはＭｏｄｉｆｉｅｄのいずれか）、マッピングエンジンは例外を通る。
【０２１５】
例：
【０２１６】
【表３４−１】
0004847689.tif 000041
【０２１７】
【表３４−２】
0004847689.tif 000042
【０２１８】
マップは次のような内部表現で表される。
【０２１９】
【表３５】
0004847689.tif 000043
【０２２０】
ＲＥＦ属性
Ｒｅｆ属性値はＭａｐの名前である。この属性の意味は、ターゲット構造またはターゲットフィールドが名前付きマップの同じＳｏｕｒｃｅにマッピングされるということである。「同じＳｏｕｒｃｅ」は、リレーショナルドメイン内のテーブルから選択されたセットを意味する。リレーショナルドメインの意味に基づき、マッピングエンジンは、テーブルがマッピングされる毎に新しいレコードセット（ｓｅｌｅｃｔステートメント）を作成する。ＸＭＬドメイン内の異端の（ｍａｖｅｒｉｃｋ）ケースなどの場合に、ユーザはすでに作成されているセットをターゲット構造またはフィールドにマッピングすることを望むことがある。ユーザが顧客注文を含む顧客要素を持つ以下のシナリオ（ＸＭＬドメインマッピングから抜粋）を考察する。Ｏｒｄｅｒ要素には、顧客名が含まれている。
【０２２１】
【表３６】
0004847689.tif 000044
【０２２２】
リレーショナル構造は、ＭｙＢｕｙｅｒ  Ｒｅｌａｔｉｏｎｓｈｉｐを含むＣｕｓｔｏｍｅｒｓおよびＯｒｄｅｒｓテーブルである。したがって、マッピングは以下のようになる。
【０２２３】
【表３７−１】
0004847689.tif 000045
【０２２４】
【表３７−２】
0004847689.tif 000046
【０２２５】
これは、別のセットおよび結合を作成する必要がないため注文要素上で顧客名を取得する効率のよい方法である。ソースドメイン内の各構造（行）からマッピングにより複数のＸＭＬ要素が作成される場合があるため、Ｒｅｆ属性は、ＸＭＬドメインでのみ使用されることに注意されたい。さらに、この行からの値は、上の例に示されているように、ＸＭＬ階層内の子孫が選択することができる。
【０２２６】
更新の意味
マッピングの強力な属性は、更新可能であるということである。オブジェクトまたはＸＭＬドメイン内の変更の同期をとりＳＱＬサーバドメインに伝えるため以前には大量のコードを書く必要があった多くの開発者は、マッピングエンジンに中継し、タスクを実行してもらうようにできる。ユーザは、ターゲットドメイン内の構造（オブジェクトまたはＸＭＬ要素）を作成、削除、または修正し、ターゲットドメインＡＰＩおよび以下のセクションではＣＰと呼ぶ変更プロセッサ（ＣＰ）と呼ばれるマッピングエンジンにより魔法を使ったようにソースドメインに対してそれらの変更の同期をとる（永続化する）。このセクションでは、ソースドメイン（リレーショナルデータモデル）内に永続化されているターゲットドメインの変更の意味を説明する。
【０２２７】
以下の項は、上述のＥｘｉｓｔｅｎｃｅ、Ｃｏｐｙ、およびＭａｐｐｉｎｇ  Ｒｅｌａｔｉｏｎｓｈｉｐｓのこれらの概念への追加である。
【０２２８】
ターゲットユニット−Ｍａｐ要素を使用して同じソース構造にマッピングされるターゲットドメインからの構造または構造のグループ。ターゲット構造のグループは、Ｒｅｆ属性を使用して他のＭａｐを参照しているマップ上のターゲットである（Ｔａｒｇｅｔユニットは参照されているマップを含む）。これは、構造のこのようなグループ化が可能でなく、Ｍａｐ要素を使用してマッピングされる各オブジェクトがＴａｒｇｅｔユニットであるオブジェクトドメインと構造のそのようなグループを上述のように作成できるＸＭＬドメインとの間の鞍の差（ｓａｄｄｌｅ  ｄｉｆｆｅｒｅｎｃｅ）である。
【０２２９】
ソースユニット−ソースドメイン内の構造。リレーショナルドメインでは、ソースはＣｕｓｔｏｍＴａｂｌｅである。
【０２３０】
変更ユニット−変更されたターゲットユニットにマッピングされたソースユニット。
【０２３１】
ＣＰは、変更ユニットの関係を調べ、ソースドメイン内の関係するユニットに対し実行するオペレーション、オペレーションの順序、およびバリデーションを判別する。変更をターゲットとソースの両方のドメイン内の関係するユニットに適用して同期を維持する操作は非常に複雑である。ＲｅｌａｔｉｏｎｓｈｉｐＭａｐセクションのバリデーション規則により、必ず、ターゲットドメインに対する変更はソースドメイン上のＣＰにより適用される変更と衝突しない。
【０２３２】
このセクションでは、ソースドメインスキーマ（ＲＳＤ）内の関係要素の意味を説明する。
【０２３３】
ＦＲＯＭとＴＯ
「Ｆｒｏｍ」は、関係内の親ユニットであり、「Ｔｏ」は関係内の子ユニットである。ソースドメイン内のオペレーションの順序を判別するために、親ユニットと子ユニットとの区別が必要である。変更の種類（Ｉｎｓｅｒｔ、Ｄｅｌｅｔｅ、およびＵｐｄａｔｅ）を使用して、オペレーションの実行順序を判別する。Ｉｎｓｅｒｔ／Ｕｐｄａｔｅに対し、親は最初に実行され、Ｄｅｌｅｔｅに対し、子が最初に実行される。
【０２３４】
ＣＡＳＣＡＤＥＤＥＬＥＴＥ／ＣＡＳＣＡＤＥＵＰＤＡＴＥ
変更をソースドメインに適用する場合、ＣＰは変更ユニットとその変更ユニットが親となっている他のマッピングされたソースユニットとの間のあらゆる関係を見つける。ＣａｓｃａｄｅＤｅｌｅｔｅ／ＣａｓｃａｄｅＵｐｄａｔｅの値により、オペレーションは子テーブルまたはそれ以外に影響を及ぼすかどうかを判別する。これらの属性の値では、ＣＰまたはＳＱＬ  Ｓｅｒｖｅｒが子テーブル上で変更を実行するかどうかを決定する。
【０２３５】
ＩＳＦＯＲＥＩＧＮＫＥＹを使用したユニット（テーブル）依存関係の計算
以下では、関係情報に基づいてテーブル内のテーブル依存関係および行依存関係（ユニット依存関係ともいう）を計算し更新エンジンＣＰの行実行順序を判別することの意味を説明する。ＣＰでは、親（Ｆｒｏｍ）と子（Ｔｏ）の情報および関係要素のＩｓＦｏｒｅｉｇｎＫｅｙ属性により表される外部キー制約の存在を利用して、この依存関係および更新ステートメントの実行順序を判別する。
【０２３６】
以下は単純な階層であり、Ｃｕｓｔｏｍｅｒｓ→Ｏｒｄｅｒｓ→ＯｒｄｅｒＤｅｔａｉｌｓとなっており、循環参照はない。
【０２３７】
【表３８】
0004847689.tif 000047
【０２３８】
以下は、１つの関係がサーバ上のＦＫ制約でない循環参照である（ＩｓＦｏｒｅｉｇｎＫｅｙ＝ｆａｌｓｅ）。これは、外部キー制約の少なくとも１つの関係はサーバ上で作成されないシナリオである。マッピングの順序は、Ａ→Ｂ→Ｃである。
【０２３９】
【表３９】
0004847689.tif 000048
【０２４０】
以下は、すべての関係がサーバ上のＦＫ制約である循環参照である（ＩｓＦｏｒｅｉｇｎＫｅｙ＝ｔｒｕｅ）。このシナリオでは、関係はすべて、サーバ上の外部キー制約が課される。マッピングの順序は、Ｃ→Ａ→Ｂである。
【０２４１】
【表４０−１】
0004847689.tif 000049
【０２４２】
【表４０−２】
0004847689.tif 000050
【０２４３】
または
【０２４４】
【表４１】
0004847689.tif 000051
【０２４５】
コンパイル時に、「Ｆｒｏｍ」および「Ｔｏ」という方向属性は主に、テーブル依存関係を判別する場合に使用される。これにより、第１のシナリオのような単純なすべての階層型シナリオが解決する。他方、関係の方向により循環参照が生じる上の第２および第３のシナリオでは、サーバ上に実装されている外部キー制約（ＩｓＦｏｒｅｉｇｎＫｅｙ＝“ｔｒｕｅ”）を指していない関係を無視することにより依存関係を見つけ出そうとする。このようにして第２のシナリオを取り扱う。循環参照がそれでも存在している場合（つまり、すべて外部キー制約として実装されているため関係パスすべてが無視されるわけではない）、依存関係グラフはランダムに階層型ツリーに解決される（次のアルゴリズムのセクションで説明する）。
【０２４６】
実行時に、第１のシナリオでＣｈａｎｇｅＵｎｉｔｓを受け取ると、それ以上オペレーションは必要でなく、コンパイル時依存関係グラフによる実行順序で実行される。しかし、第２および第３のシナリオの循環参照については、ＣｈａｎｇｅＵｎｉｔ．ＧｅｔＰａｒｅｎｔｓ（）を使用して実行時インスタンスを評価し、正しい実行順序を求める。ほとんどの場合、実行時インスタンスはグラフを形成せず、ＣｈａｎｇｅＵｎｉｔｓは階層方式で実行される（ＨａｒｏｏｎＡ→ＤａｎｉｅｌＤ→Ｆｏｏ→Ｂａｒ→ＢｉｌｌＧ）。しかし、実行時にインスタンスがグラフを形成する場合でも、コンパイル時依存関係に従ってユニットが実行される。これは、第２のシナリオの場合にうまくゆくが、すべての関係が外部キー制約を参照している第３のシナリオでは、サーバサイドの制約例外がＩｎｓｅｒｔおよびＤｅｌｅｔｅオペレーションに対し発生する。
【０２４７】
ここでアルゴリズムを使用することで、すべてのシナリオに対するマッピングコンパイル時の依存関係を計算することができるが、第２および第３のシナリオの循環参照については実行時インスタンスは評価され優先権を与えられる。マッピング構文から一度計算されたすべてのユニットの依存関係情報は、すべてのソースユニットにそれぞれの相対的序数が割り当てられるコンパイル時マッピングにおいて配列に格納されることに注意すべきである。上述のように第３のシナリオの解決不可能な循環参照であっても、グラフはマッピングファイル内の出現順にランダムにツリーに細分される。このため、関係のないユニット間でも実行の決定論的順序が保証され、したがって特定の潜在的デッドロックのケースが回避される。
【０２４８】
カーディナリティは、ＯｎｅＴｏＯｎｅおよびＯｎｅＴｏＭａｎｙのいずれかである。Ｍａｎｙ−ｔｏ−ｍａｎｙは意味に関してＯｎｅＴｏＭａｎｙと似ており、更新に関係する。「Ｍａｐ」要素上の「Ｓｏｕｒｃｅ」属性により指定されたソースユニットは、強いユニットと呼ばれ、基本の「ＦｉｅｌｄＭａｐ」要素で指定された他のすべてのソースユニットは弱いユニットと呼ばれる。カーディナリティ情報は、弱いユニットおよび強いユニットという概念と緊密に結びついている。ＯｎｅＴｏＭａｎｙでは、弱いユニットは読み取り専用と考えられる。
【０２４９】
このようなシナリオの例としては、ＯｂｊｅｃｔＳｐａｃｅのＯｎｅ  Ｔａｂｌｅ  ｐｅｒ  Ｔｙｐｅ継承と複数のテーブルにマッピングされたＣｕｓｔｏｍｅｒ  ＸＭＬ要素（またはＣｌａｓｓ）（Ｃｕｓｔｏｍｅｒ、ＣｕｓｔｏｍｅｒＩｎｆｏ）がある。この場合、動作は強いユニットも弱いユニットも読み書きであり、弱いユニット行の存在は、強いユニット行の存在と結びついている。つまり、ターゲットユニットが挿入されると、１つの行が強いユニットに挿入されるだけでなく、対応する行もすべての弱いユニットに挿入されるということである。同様に、ターゲットユニットが削除されると、強いユニットおよび弱いユニット内の対応する行はすべて削除される。弱いユニットを参照する属性を削除することは、この列が強いユニットに属するか弱いユニットに属するかに関係なく対応する列内の値をＮＵＬＬ化するものとしてみなされる。特定の弱いユニットにマッピングされているすべてのターゲットフィールドが削除される場合でも、弱いユニット内の行は削除されないということを明確にする必要がある。弱いユニットからの行は、ターゲットユニットが削除される場合、強いユニットとのみ消される。このターゲットフィールドの削除シナリオは、ＸＬＭでしか存在せず、ＯｂｊｅｃｔＳｐａｃｅｓでは存在しないことに注意されたい。というのも、クラスのプロパティは削除できず、むしろＮＵＬＬ化できるだけだからである。
【０２５０】
ＦｉｅｌｄＭａｐ上のＲｅｆ属性に関して、ＦｉｅｌｄＭａｐで「Ｒｅｆ」属性を使用して複数のソースユニットをマッピングする場合、更新の意味はすべてのカーディナリティについて弱いユニットに関し読み取り専用である。これは、更新の意味を制御するために他のマッピングが存在することを意味する「Ｒｅｆ」属性の意味に適合している。読み取り専用の意味では、ターゲットが挿入されると、更新オペレーションは強いユニットに行を挿入するだけであり、弱いユニットに触れる（ｔｏｕｃｈ）ことはない。同様に、ターゲットが削除される場合、強いユニット上の行のみが削除される。同様に、弱いユニットを参照している属性が修正されると（更新／削除）、更新エンジン（ＣＰ）は例外を投げる。クライアント（ＯｂｊｅｃｔＳｐａｃｅｓ、ＸｍｌＣａｃｈｅなど）は、弱いユニット上の修正された変更をＣＰに与えないことにより動作を常にオーバーライドすることが可能である。このようにして、例外を発生することなく変更が無視される。
【０２５１】
ソースの代わりにＲｅｆ属性を持つマップは、１つのユニットにまとめられ、主要マップ内にマッピングされているターゲット構造なしでは挿入も削除もできない。概念的には、これらは主要マップの一部である。このような動作である理由は、主要（ｍａｉｎ）マップは常に、個人キー情報を含むことを保証され、マッピングされる構造はマッピングされる構造の先祖でなければならず、したがって、そのマップの所有者構造とすることができる。
【０２５２】
読み取り専用のＦｉｅｌｄＭａｐでは、ＣＰは読み取り専用ＦｉｅｌｄＭａｐ内にマッピングされているソースフィールドが変更されず、この場合エラーを投げることを確認する。ＣｕｓｔｏｍＴａｂｌｅ上の更新コマンドの現在のパラメータを読み取り専用ターゲットフィールドにバインドするのは誤りであることに注意されたい。
【０２５３】
図６Ａを参照すると、マッピングコンポーネント６０２がネットワーク上に別々に配置されているソースのデータソース６０２とターゲットのデータソース６０４のネットワーク図が示されている。ソースのデータソース６０２とターゲットのデータソース６０４は両方とも、読み取り専用であるが、それでもマッピングが必要である。本発明では、マッピングコンポーネント６０６を使用して、ソース６０２からターゲット６０４へのマッピングを実行し、マッピングコンポーネント６０６のネットワークロケーションにいるユーザはそのマッピングを実行するようにマッピングコンポーネント６０６を構成する。これは、インターネットなどのグローバルな通信ネットワーク（ＧＣＮ）６０８を対象とすることができる。さらに、マッピングは、ＬＡＮ、ＷＡＮ、ＷＬＡＮ、ＷＷＡＮなどのネットワーク６０８上で実行することができる。このシナリオでは、顧客がマッピングオペレーションをベンダに実行してもらうために署名（ｓｕｂｓｃｒｉｂｅ）する実装が行いやすい。これは必須ではないがベンダは単純に、たぶんログイン情報を取得した後、ネットワーク６０８を介してソースおよびターゲットのデータモデルにアクセスし、マッピングオペレーションを実行するためにマッピングコンポーネント６０６を構成する。このシナリオではさらに、ＬＡＮ、ＷＡＮなどを介して顧客のマッピングオペレーションをサポートする。
【０２５４】
次に図６Ｂを参照すると、マッピングコンポーネント６０６をソースロケーションまたはターゲットロケーション、またはその両方のロケーションに配置することができることを示しているネットワーク図６１０が例示されている。
【０２５５】
次に図７を参照すると、開示されているアーキテクチャを実行する動作が可能なコンピュータのブロック図が例示されている。本発明の様々な態様の背景を示すために、図７および以下の説明では、本発明の様々な態様を実装できる適当な動作環境７００の概要を簡潔に説明する。本発明は、１つまたは複数のコンピュータで実行できる、コンピュータ実行可能命令の一般的な文脈において上で説明されているが、当業者であれば、本発明は他のプログラムモジュールと組合せかつ／またはハードウェアとソフトウェアとの組合せとして実装できることも理解するであろう。一般に、プログラムモジュールには、特定のタスクを実行する、あるいは特定の抽象データ型を実装するルーチン、プログラム、コンポーネント、データ構造などが含まれる。さらに、当業者であれば、本発明の方法が、シングルプロセッサまたはマルチプロセッサのコンピュータシステム、ミニコンピュータ、メインフレームコンピュータ、さらにはパーソナルコンピュータ、ハンドヘルドコンピューティングデバイス、マイクロプロセッサベースのまたはプログラム可能な家電製品などを含む、他のコンピュータシステム構成でも実施でき、それぞれ１つまたは複数の関連するデバイスに結合され動作可能であることを理解するであろう。本発明の例示されている態様は、通信ネットワークを通じてリンクされているリモート処理デバイスにより特定のタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、ローカルおよびリモートのメモリ記憶デバイスに置くことができる。
【０２５６】
図７を参照すると、本発明の様々な態様を実装する環境例７００はコンピュータ７０２を含み、コンピュータ７０２は処理ユニット７０４、システムメモリ７０６、およびシステムバス７０８を含むことが示されている。システムバス７０８は、限定はしないが、システムメモリ７０６などのシステムコンポーネントを処理ユニット７０４に結合する。処理ユニット７０４は、様々な市販プロセッサのうちのどれでもよい。デュアルマイクロプロセッサおよびその他のマルチプロセッサアーキテクチャも、処理ユニット７０４として採用することができる。
【０２５７】
システムバス７０８は、様々な市販のバスアーキテクチャを使用するメモリバスまたはメモリコントローラ、周辺機器バス、およびローカルバスを含む数種類のバス構造のうちのいずれかとすることができる。システムメモリ７０６は、読み取り専用メモリ（ＲＯＭ）７１０およびランダムアクセスメモリ（ＲＡＭ）７１２を含む。起動時などにコンピュータ７０２内の要素間の情報伝送を助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）は通常、ＲＯＭ７１０に格納される。
【０２５８】
コンピュータ７０２は、ハードディスクドライブ７１４、磁気ディスクドライブ７１６（例えば、取り外し可能ディスク７１８との間で読み書きする）、および光ディスクドライブ７２０（例えば、ＣＤ−ＲＯＭディスク７２２を読み出したり、他の光媒体との間で読み書きを行う）をさらに含む。ハードディスクドライブ７１４、磁気ディスクドライブ７１６、および光ディスクドライブ７２０は、ハードディスクドライブインターフェイス７２４、磁気ディスクドライブインターフェイス７２６、および光ドライブインターフェイス７２８によりそれぞれシステムバス７０８に接続できる。ドライブおよびその関連コンピュータ可読媒体は、データ、データ構造体、コンピュータ実行可能命令などを格納する不揮発性記憶装置を実現する。コンピュータ７０２に関しては、ドライブおよび媒体は、適当なデジタル形式で放送番組を格納することに適応している。上述のコンピュータ可読媒体の説明では、ハードディスク、取り外し可能磁気ディスク、およびＣＤを取り上げているが、当業者であれば、ｚｉｐドライブ、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、カートリッジなどコンピュータにより読み取り可能な他の種類の媒体も動作環境例で使用することができること、さらに、そのような媒体は本発明の方法を実行するコンピュータ実行可能命令を含むことができることを理解するであろう。
【０２５９】
多数のプログラムモジュールを、オペレーティングシステム７３０、１つまたは複数のアプリケーションプログラム７３２、その他のプログラムモジュール７３４、およびプログラムデータ７３６などのドライブおよびＲＡＭ７１２に格納することができる。本発明は、様々な市販のオペレーティングシステムまたはオペレーティングシステムの組合せで実装できることは理解されるであろう。
【０２６０】
ユーザは、キーボード７３８およびマウス７４０などのポインティングデバイスを介してコマンドおよび情報をコンピュータ７０２に入力することができる。他の入力デバイス（図に示されていない）としては、マイク、ＩＲリモートコントロール、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどがある。これらの入力デバイスやその他の入力デバイスは、システムバス７０８に結合されているシリアルポートインターフェイス７４２を介して処理ユニット７０４に接続されることが多いが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（「ＵＳＢ」）、ＩＲインターフェイスなどの他のインターフェイスにより接続することもできる。モニタ７４４またはその他の種類の表示デバイスも、ビデオアダプタ７４６などのインターフェイスを介してシステムバス７０８に接続される。モニタ７４４の他に、コンピュータは通常、スピーカ、プリンタなどの他の周辺出力デバイス（図に示されていない）を含む。
【０２６１】
コンピュータ７０２は、リモートコンピュータ７４８などの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク環境で動作することも可能である。リモートコンピュータ７４８は、ワークステーション、サーバコンピュータ、ルータ、パーソナルコンピュータ、携帯型コンピュータ、マイクロプロセッサベースの娯楽機器、ピアデバイス、またはその他の共通ネットワークノードなどでよく、通常は、コンピュータ７０２に関係する上述の要素の多くまたはすべてを含むが、簡単のため、メモリ記憶デバイス７５０のみが例示されている。説明されている論理接続は、ローカルエリアネットワーク（ＬＡＮ）７５２とワイドエリアネットワーク（ＷＡＮ）７５４を含む。このようなネットワーキング環境は、オフィス、企業全体にわたるコンピュータネットワーク、イントラネット、およびインターネットでは一般的なものである。
【０２６２】
ＬＡＮネットワーキング環境で使用する場合、コンピュータ７０２はネットワークインターフェイスまたはアダプタ７５６を介してローカルネットワーク７５２に接続される。アダプタ７５６により、ＬＡＮ７５２との有線または無線通信を行うことができ、これはさらに、無線アダプタ７５６との通信を行うため配置されている無線アクセスポイントも含むことができる。ＷＡＮネットワーキング環境で使用する場合、コンピュータ７０２は通常、モデム７５８を含むか、またはＬＡＮで通信サーバに接続されるか、またはインターネットなどのＷＡＮ７５４上で通信を確立するための他の手段を含む。モデム７５８は、内蔵でも外付けでもよいが、シリアルポートインターフェイス７４２を介してシステムバス７０８に接続される。ネットワーク環境では、コンピュータ７０２またはその一部に関して述べたプログラムモジュールは、リモートメモリ記憶デバイス７５０に格納できる。図に示されているネットワーク接続は例であり、コンピュータ間に通信リンクを確立するための他の手段を使用できることは理解されるであろう。
【０２６３】
図８を参照すると、本発明によるコンピューティング環境例８００の概略ブロック図が示されている。システム８００は、１つまたは複数のクライアント８０２を含む。クライアント８０２は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）とすることができる。クライアント８０２には、例えば、本発明を採用することによりｃｏｏｋｉｅｓおよび／または関連するコンテキスト情報を置くことができる。システム８００は、さらに、１つまたは複数のサーバ８０４を含む。またサーバ８０４は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）とすることもできる。サーバ８０４には、例えば、本発明を採用することにより変換を実行するスレッドを置くことができる。クライアント８０２とサーバ８０４との間の考えられる１つの通信は、２つまたはそれ以上のコンピュータプロセス間で伝送されるように適合されたデータパケットの形で実行できる。データパケットは、例えば、ｃｏｏｋｉｅおよび／または関連するコンテキスト情報を含むことができる。システム８００は、クライアント８０２とサーバ８０４との間の通信を円滑にするために採用することができる通信フレームワーク８０６（例えば、インターネットなどのグローバル通信ネットワーク）を含む。通信は、有線（光ファイバを含む）および／または無線技術を介して円滑化することができる。クライアント８０２は、クライアント８０２のローカルにある情報を格納するために使用することができる１つまたは複数のクライアントデータストア８０８に接続し動作させることができる（例えば、ｃｏｏｋｉｅｓおよび／または関連するコンテキスト情報）。同様に、サーバ８０４は、サーバ８０４のローカルにある情報を格納するために使用することができる１つまたは複数のサーバデータストア８１０に接続し動作させることができる。
【０２６４】
図９を参照すると、本発明によるディジーチェーン型のマッピング実装のブロック図が例示されている。開示されている新規性のあるマッピングアーキテクチャによりディジーチェーン型のマッピングシナリオの実装が容易になり、図１のシステム１００に似た複数の段９００はシリアル方式でソースデータモデルＳ１（任意の構造の）からターゲットデータモデルＴＮ（任意の構造の）へ、必要な中間データ変換を行う多数の中間ステージを使用し、最終的にターゲットデータモデルＴＮ（送り先）で望むデータ形式を利用できるようにすることは理解されるであろう。このコンテキストでのステージ９００は、ソースモデルＳ、マッピングコンポーネントＭ、およびターゲットデータモデルＴを含むように表されている。ディジーチェーンで複数のステージ９００を接続する場合、中間ターゲットデータモデルＴ１はさらに、後のステージ９０２のデータソースＳ２でもある。したがって、中間データモデル（例えば、Ｔ１／Ｓ２）は、先行するステージ９００のマッピングコンポーネントＭ１のターゲットに対するＴ１と後続のステージ９０２の後続のマッピングコンポーネントＭ２のソースに対するＳ２の両方としてラベル付けされている。
【０２６５】
データモデルは、限定はしないが、クエリ言語、データアクセス言語、データ操作言語、データ定義言語、オブジェクトモデル、リレーショナルモデル、およびＸＭＬモデルなどがある。
【０２６６】
一実施例では、ソースデータモデルＳ１からターゲットデータモデルＴ２にデータをマッピングすることが目標である。ソースＳ１はリレーショナルデータ構造であり、ターゲットＴ２はＸＭＬデータ構造であると考える。さらに、ソースＳ１からターゲットＴ２へのパスは、オブジェクトベースのパスしか与えない。第１のステージのマッピングコンポーネントＭ１はソースＳ１に適切なリレーショナル記述コンポーネントを使用し、ターゲットＴ１にオブジェクト記述コンポーネントを使用して、ソースＳ１から中間ターゲットＴ１にマッピングする。次に、中間ターゲットＴ１はマッピングコンポーネントＭ２のソースＳ２ではない。次に、マッピングコンポーネントＭ２は、適切なオブジェクト記述コンポーネントおよびＸＭＬ記述コンポーネントを使用してソースＳ２からターゲットＴ２へのマッピングを完了する。
【０２６７】
このような機能を考えると、特定の応用ではステージをいくつでも（９００および９０２）を採用できることは理解されるであろう。
【０２６８】
図１０を参照すると、本発明のマッピングアーキテクチャのハブ＆スポーク方式の実装を示している。この実装は、ネットワークの中断、使用可能な帯域幅などにより、任意の時点でデータパスを使用できるかどうかが決まる大規模なネットワーク環境、例えば、インターネットまたは大規模な企業ネットワークで特に有用である。データが移動しまたはクエリが実行される任意の数のデータソース（Ｓ１、Ｓ２、およびＳ３）および任意の数の中間データターゲット１００８（Ｔ／Ｓとも表されている）と通信している中央制御エンティティ１０００が用意される。最後に、マッピングはソース（Ｓ１、Ｓ２、およびＳ３）の１つからターゲットＴ２へのマッピングであるのが望ましい。
【０２６９】
中央制御エンティティ１０００は、エンティティ１０００のすべての側面を制御する制御コンポーネント１００２を含み、これは、一方の種類のデータモデルから他方のデータモデル（例えば、リレーショナル、オブジェクト、ＸＭＬ、．．．）にデータを変換するためのアクセス可能な記述アルゴリズムを格納する記述コンポーネントリソース１００４、およびソース（Ｓ１、Ｓ２、およびＳ３）と中間ターゲット１００８との間でデータのルーティングまたはスイッチングを行うスイッチングメカニズム１００６を含む。
【０２７０】
例えば、動作中に、第１の中間データソースターゲット１０１０からソースＳ１へのデータクエリが開始される。ソースＳ１のデータ構造はリレーショナルであり、ターゲット１０１０はＸＭＬである。ターゲット１０１０からソースＳ１へのクエリにより変換情報を制御コンポーネント１００２に送り、マッピングの完了に使用するためリソース１００４から適切なリレーショナル−ＸＭＬマッピングアルゴリズムを取り出しかつ／または生成することができる。マッピング関数（ｆｕｎｃｔｉｏｎ）は、エンティティ１０００の一部である。
【０２７１】
より広範な例では、１つのデータモデルに対して行われたマップ要求（クエリまたは更新）を１つまたは複数の異なるデータモデルへの要求に変換することができる場合、ターゲットＴ２から始まり中間ターゲット／ソース１００８のいずれか１つを通りソースＳ１へ到達するクエリが開始し、エンティティ１０００は中間データソース１００８を通じて最適なパスを選択することができる。例えば、ソースＳ１がリレーショナルである場合、ターゲットＴ２はＸＭＬであり、第１の中間データソース１０１０はオブジェクトベースであり、第２の中間データソース１０１２はリレーショナルベースであり、第３の中間データソース１０１４はＸＭＬベースであり、エンティティ１０００は最適なパスがソースＳ１から第２の中間データソース１０１２を通りターゲットＴ２に至るものであると判定することができる。この判定が行われると、制御コンポーネント１００２は、ソースＳ１から中間データソース１０１２へのリレーショナル−リレーショナルマッピング（リソース１００４からの）を採用し、それにより、第２の制御エンティティ１０１６（制御エンティティ１０００と似ている）内のマッピングコンポーネントは第２の中間データソース１０１２からターゲットＴ２へのリレーショナル−ＸＭＬマッピングを使用する。制御エンティティ（１０００および１０１６）は、リンク１０１８を介して通信し、データソースを通じてターゲットＴ２に至る通信経路の１つを介して経路選択を調整することができる。
【０２７２】
上で示したように、データソース間のマッピングは類似のデータ構造に対するものとすることができ、例えば、リレーショナル・ツー・リレーショナル、ＸＭＬ・ツー・ＸＭＬなどとすることができる。つまり、ソースのリレーショナルデータベースを、異なるリレーショナル構造を有するターゲットリレーショナルデータベースにマッピングすることができるシナリオが存在しうる。同様に、ソースのオブジェクトデータを、異なるオブジェクト構造を持つターゲットオブジェクトデータにマッピングすることができるシナリオが存在しうる。さらに、ソースのＸＭＬデータを、異なるＸＭＬ構造を持つターゲットＸＭＬデータモデルにマッピングすることができるシナリオが存在しうる。
【０２７３】
次に図１１を参照すると、本発明の一態様によるスタック可能な構造１１００が例示されている。この機能は、図１０のネットワーク実装で使用されている。マッピングフレームワークは、便利な１組の形式、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｉｎｔｅｒｆａｃｅ）、オプティマイザ、ユーティリティ、およびツールを備えており、ユーザは２つの任意のデータモデルの間でデータ処理を実装することができる。誰でも、ＱＩＬ（クエリ独立言語）コンパイラに対し自身のクエリを実行し、他のデータソースに対し自動的に実行するようにできる。ＱＩＬは、データソースに対するクエリ（または更新）の万能データソース独立表現である。マッピングにより、一方のデータモデルに対して行われた要求（クエリまたは更新）をマッピングする要求を別のデータモデルへの要求に変換することができる。
【０２７４】
例示されているＡＰＩは、リレーショナル１１０２、ＸＭＬ１１０４、オブジェクト１１０６、およびその他１１０８を含む。したがって、クエリは、実行するためマッピングの複数のレイヤ（１１１０、１１１２、および１１１４）内を移動することができ、その結果を複数回再マッピングしてから送り返すようにできる。マッピングおよびＱＩＬは、作成可能である。マッピングは２方向である、つまり可逆であり、更新を自然に実行できる。
【０２７５】
上で説明した内容は、本発明の例を含んでいる。もちろん、本発明を説明するためにコンポーネントまたは方法の考えられるすべての組合せを説明することは不可能であるが、当業者であれば、本発明の他の多くの組合せおよび置換が可能であることを理解できるであろう。したがって、本発明は、付属の請求項の精神と範囲内に収まるすべてのそのような変更、修正、および変更形態を包含するものとする。さらに、「ｉｎｃｌｕｄｅｓ（含む）」という言い回しを詳細な説明または請求項で使用している範囲において、このような用語は、「ｃｏｍｐｒｉｓｉｎｇ（備える、含む）」という用語が請求項の中で接続語（ｔｒａｎｓｉｔｉｏｎａｌ  ｗｏｒｄ）として使用した場合に解釈されるように、「ｃｏｍｐｒｉｓｉｎｇ」という用語と同様の方法で包括的であることを表す。
【図面の簡単な説明】
【０２７６】
【図１】本発明のマッピングシステムのブロック図である。
【図２】本発明によるプロセスのフロー図である。
【図３】ソースからターゲットへのマッピングを円滑にするために公開されている概念的メタデータエンティティの図である。
【図４】ソーススキーマをターゲットスキーマにマッピングするためのマッピングファイルの一般的な例を示す図である。
【図５】ソースドメインとターゲットドメインとのマッピング例を示す図である。
【図６Ａ】マッピングコンポーネントがネットワーク上に別々に配置されているソースのデータソースとターゲットのデータソースのネットワーク図である。
【図６Ｂ】マッピングコンポーネントをソースの位置またはターゲットの位置、またはその両方の位置に配置することができることを示しているネットワーク図である。
【図７】開示されているアーキテクチャを実行する動作が可能なコンピュータのブロック図である。
【図８】本発明によるコンピューティング環境例を示す概略ブロック図である。
【図９】本発明によるディジーチェーン型のマッピング実装を示すブロック図である。
【図１０】本発明マッピングアーキテクチャのハブ＆スポーク方式の実装を示す図である。
【図１１】本発明の一態様によるスタック可能な構造を示す図である。
【符号の説明】
【０２７７】
１００  マッピングシステム
１０２  ソースデータモデル
１０４  ターゲットデータモデル
１０６  マッピングコンポーネント
１０８  ソースメタデータ
１１０  ターゲットメタデータ
【図１】
0004847689.tif 000052
【図２】
0004847689.tif 000053
【図３】
0004847689.tif 000054
【図４】
0004847689.tif 000055
【図５】
0004847689.tif 000056
【図６Ａ】
0004847689.tif 000057
【図６Ｂ】
0004847689.tif 000058
【図７】
0004847689.tif 000059
【図８】
0004847689.tif 000060
【図９】
0004847689.tif 000061
【図１０】
0004847689.tif 000062
【図１１】
0004847689.tif 000063