(57)【要約】【課題】スキーマデータとリレーショナル構造との変換を可能にする変換アーキテクチャを提供すること。【解決手段】このアーキテクチャはスキーマ構造を含むスキーマデータ（例えばＸＭＬスキーマ）を処理し、スキーマ構造の有効性を確認し、さらにスキーマの表現をメモリ内にリレーショナル形式で保存する変換コンポーネントを備える。スキーマはテーブルに細分されるので、インスタンスの有効性を確認する場合は有効性確認に必要なコンポーネントのみをロードする。有効性確認実行中は、スキーマの使用する部分のみがロードされ、キャッシングされる。スキーマキャッシュには、インスタンスの有効性確認に合わせて最適化されたスキーマのメモリ内の表現が格納される。スキーマコンポーネントは、メタデータから読み取り専用オブジェクトとしてメインメモリにロードされる。【選択図】図１
2006114045.tif 000002
【特許請求の範囲】
【請求項１】
データの変換を可能にするシステムであって、
スキーマ構造を含むスキーマデータを処理し、スキーマ構造の有効性を確認し、前記スキーマ構造の表現をメモリ内にリレーショナル形式で保存する変換コンポーネントを備えることを特徴とするシステム。
【請求項２】
前記リレーショナル形式による前記スキーマ構造の表現がシンボルテーブルに保存されることを特徴とする請求項１に記載のシステム。
【請求項３】
前記スキーマ構造の有効性を確認する場合に、前記シンボルテーブルを調査することを特徴とする請求項２に記載のシステム。
【請求項４】
前記スキーマデータはＸＭＬスキーマ構造であることを特徴とする請求項１に記載のシステム。
【請求項５】
前記スキーマ型の構造を説明するメタデータテーブルは前記メモリ内に格納されることを特徴とする請求項１に記載のシステム。
【請求項６】
前記メタデータテーブルは、前記スキーマデータの基本的なコンポーネントを格納するコンポーネントテーブル、派生構造を格納する参照テーブル、複合型の階層を格納する配置テーブル、単純型のファセットを格納するファセットテーブル、基本的なコンポーネントの名前とワイルドカード名前空間名を格納する修飾名テーブルを含むことを特徴とする請求項５に記載のシステム。
【請求項７】
前記スキーマデータは関連のスキーマコンポーネントのセットに分解されることを特徴とする請求項１に記載のシステム。
【請求項８】
前記スキーマデータはそれぞれＩＤに関連付けられる関連のスキーマコンポーネントのセットに分解されることを特徴とする請求項１に記載のシステム。
【請求項９】
請求項１に記載のシステムを採用することを特徴とするサーバ。
【請求項１０】
請求項１に記載のシステムを実行するためのコンピュータ実行可能命令を格納することを特徴とするコンピュータ可読媒体。
【請求項１１】
前記スキーマデータはリレーショナルテーブルのセットに分解され、前記スキーマデータの最も使用頻度の高い部分がロードされキャッシングされることを特徴とする請求項１に記載のシステム。
【請求項１２】
前記スキーマデータはＸＭＬスキーマコンポーネントとしてメモリに読み取り専用オブジェクトとしてロードされ、複数のユーザは前記メモリ内オブジェクトの有効性を確認できることを特徴とする請求項１に記載のシステム。
【請求項１３】
コンピュータに実装されたデータ変換方法であって、
スキーマ構造を含むＸＭＬデータを受け取るステップと、
前記スキーマ構造の有効性を確認するステップと、
前記スキーマ構造をリレーショナルテーブルに変換するステップと、
前記リレーショナルテーブルの一部をメモリ内に保存するステップと
を備えることを特徴とする方法。
【請求項１４】
前記リレーショナルテーブルの使用頻度の最も高い部分を前記メモリにロードするステップをさらに備えることを特徴とする請求項１３に記載の方法。
【請求項１５】
型、属性、要素の少なくとも１つに関連する前記リレーショナルテーブルの部分を型キャッシュに保存するステップをさらに備えることを特徴とする請求項１３に記載の方法。
【請求項１６】
前記保存のステップは前記スキーマ構造の有効性を確認する場合に調査するシンボルテーブルに前記スキーマ構造を保存することを特徴とする請求項１３に記載の方法。
【請求項１７】
前記有効性確認のステップは前記スキーマ構造の使用する部分のみをロードすることを特徴とする請求項１３に記載の方法。
【請求項１８】
前記有効性確認のステップは有効性確認に必要なコンポーネントのみをロードするインスタンスの有効性確認を含むことを特徴とする請求項１３に記載の方法。
【請求項１９】
前記リレーショナルテーブルに保存した部分を読み取り専用表示として表示するステップをさらに備えることを特徴とする請求項１３に記載の方法。
【請求項２０】
データの変換を可能にするシステムであって、
スキーマ構造を含むＸＭＬデータを受け取る手段と、
前記スキーマ構造の有効性を確認する手段と、
前記スキーマ構造をリレーショナルテーブルに変換する手段と、
前記リレーショナルテーブルの一部をメモリ内に保存する手段と、
逼迫通知信号に応答して前記メモリ内のエントリをより速い速度で自動的に削除する手段と
を備えることを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットなどで提供する文書を処理するシステムおよび方法に関する。
【背景技術】
【０００２】
ＸＭＬ（ｅＸｔｅｎｄｅｄ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）は、データにタグを付けて様々なＷｅｂブラウザでこのデータを解読できるようにする標準的な方法である。インターネットなどのグローバル通信ネットワーク上にはＷｅｂホストやＷｅｂアプリケーションが爆発的に普及しており、ＸＭＬ文書は日常業務に広く使用されている。
【０００３】
文書型定義（ＤＴＤ：Ｄｏｃｕｍｅｎｔ  ｔｙｐｅ  ｄｅｆｉｎｉｔｉｏｎ）は、正規の要素または構成単位のリストに従ってＸＭＬ文書の文書構造を定義する１つの技術である。ＤＴＤの観点では、すべてのＸＭＬ文書（およびＨＴＭＬ文書）は、要素、タグ（要素をマークアップする）、属性（要素に関する付加的な情報を提供する）、実体（共通のテキストを定義するための変数）、ＰＣＤＡＴＡ（Ｐａｒｓｅｄ  Ｃｈａｒａｃｔｅｒ  Ｄａｔａ）、ＣＤＡＴＡ（Ｃｈａｒａｃｔｅｒ  Ｄａｔａ）というシンプルな構成単位から構成される。要素はＸＭＬ文書の中心的な構成単位である。ＸＭＬ要素の例として、「ｎｏｔｅ」と「ｍｅｓｓａｇｅ」が挙げられる。要素には、テキスト、他の要素を含めることができる。あるいは空でもよい。
【０００４】
【特許文献１】米国特許第１０／７２６，０８０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ＸＭＬスキーマは、ＸＭＬデータモデル用のスキーマ定義言語を定義するＷ３Ｃ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ）標準である。スキーマ定義（例えば、個々のＣｕｓｔｏｍｅｒに関する情報構造を説明するＣｕｓｔｏｍｅｒＴｙｐｅなどの型定義）を使用すると、ＸＭＬインスタンス文書の内容と構造の有効性を確認できる。ＸＭＬスキーマ文書は、リレーショナルデータベースシステムの表や列とは異なる方法で表現されたＸＭＬ文書である。ＸＭＬスキーマ文書で指定する型情報は、ＸＭＬクエリが適切かどうかの確認、およびＸＭＬクエリやＸＭＬストレージの最適化にも利用できる。
【０００６】
ＸＭＬスキーマは、ＤＴＤ技術の非常に強力な代替となる。具体的には、ＸＭＬスキーマは将来の追加に対応できる拡張性を備えており、型定義の拡張または制限が可能であること、ＸＭＬスキーマは例えばユーザ定義の型を定義する機能のようにＤＴＤより便利な機能を豊富に備えていること、ＸＭＬスキーマはＸＭＬで記述できること、ＸＭＬスキーマはデータ型をサポートすること、ＸＭＬスキーマは名前空間をサポートすることなどによる。ＤＴＤとは異なり、ＸＭＬスキーマでは型定義と要素定義が区別されるので、同じ型の複数の要素（例えばＬｏｃａｌＣｕｓｔｏｍｅｒとＤｉｓｔａｎｔＣｕｓｔｏｍｅｒ）を共通の型定義（例えばＣｕｓｔｏｍｅｒＴｙｐｅ）を使用して定義できる。ＸＭＬスキーマ文書には他のＸＭＬスキーマ文書をインポートできるので、型ライブラリシステムを設定できる。
【０００７】
１つのアプリケーションの例では、ＸＭＬスキーマ文書をリレーショナル構造に格納する機能があるので非常に便利である。型定義は、リレーショナルインデックス構造を使用して（ＸＭＬスキーマ文書を解析せずに）効率的に検索でき、ＸＭＬスキーマ文書の必要な部分（例えば、ＣｕｓｔｏｍｅｒＴｙｐｅ定義のみ）を選択してメモリバッファ内にロードしてＸＭＬインスタンスの有効性を確認できるので、パフォーマンスを大幅に向上できる。さらに、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）表示がリレーショナルストレージに提供され、リレーショナルユーザは格納されたＸＭＬスキーマ文書について調べることができる。このように、スキーマデータを他のデータベース構造にマップするメカニズムへのまだ満たされていない大きなニーズがある。
【課題を解決するための手段】
【０００８】
開示する発明（ｉｎｎｏｖａｔｉｏｎ）のいくつかの態様について基本的な理解が得られるように、概要について以下に簡単に説明する。本解決手段は広範囲に及ぶ概要ではない。また、本発明の重要／不可欠な要素を特定する意図も、本発明の範囲を限定する意図もない。唯一の目的は、後述の実施形態に関する説明の準備として、いくつかの概念を簡略化した形で示すことである。
【０００９】
本発明は、ＸＭＬスキーマをＳＱＬサーバメタデータコンポーネントに格納し、その内部で管理するメカニズムを提供する。
【００１０】
本発明の１つの態様において、ＸＭＬスキーマとリレーショナル構造との変換を可能にするアーキテクチャを開示する。ＸＭＬスキーマはＸＭＬ文書の構造を説明する。本発明は、ＸＭＬスキーマ文書をリレーショナルテーブルに格納するＸＭＬ型システムをサポートするＳＱＬサーバへのアプリケーションを検出する。ＳＱＬサーバのその他のコンポーネント（ＸＭＬクエリプロセッサやオプティマイザなど）は、ＸＭＬ型システムを使用してクエリをコンパイルし、実行する。さらに、高度なアプリケーション（例えば在庫に関するアプリケーション）は、ＸＭＬ型システムの最上位に構築される。
【００１１】
リレーショナルデータベースシステム内にＸＭＬスキーマ文書を格納するのは新しい挑戦である。例えば、ＸＭＬスキーマ文書のＩＤ（例えばそのターゲット名前空間による）とＸＭＬスキーマ文書内で指定する型定義は、定義の特性と型をキャプチャするリレーショナル構造の行にマップされる（例えば、ＸＭＬスキーマ文書によるＣｕｓｔｏｍｅｒＴｙｐｅなどの要素の型定義は、リレーショナルシステム内に格納するときに、それが要素の型定義であることを記憶しておく必要がある）。さらに型の階層を記録する必要があり、単純型ファセット（ｆａｃｅｔｓ）によって追加の情報がキャプチャされ、リレーショナル構造からＸＭＬスキーマの型定義を再構築することもできる。
【００１２】
本アプローチの新しい点はマルチフォールド（ｍｕｌｔｉ−ｆｏｌｄ）である。第１に、ＩＤまたは名前による特定のＸＭＬスキーマコンポーネントの検索は高速である。すべてのＸＭＬスキーマコンポーネントの検索（名前またはＩＤによる）は、リレーショナルストアのインデックスシークを利用することでＩ／Ｏ操作の回数を最小限に抑える。第２に、派生（ｄｅｒｉｖａｔｉｏｎ）チェーン構造にもインデックスが付けられる。したがって、型のリレーションシップを容易かつ効率的に決定できる。第３に、細分されたスキーマは正規のリレーショナルオブジェクトなので、ＸＭＬスキーマコンポーネントの様々なリレーショナル表示を提供できる。例えば、ユーザに向けて様々なＸＭＬスキーマコンポーネント（例えば、要素、属性、型、ワイルドカード）を１つのコンポーネントテーブルに表示できる。第４に、ＸＭＬスキーマを細分することで、ユーザは任意の望みのクエリを記述できる。
【００１３】
最終的に、ＸＭＬスキーマはテーブルに細分されるので、ＸＭＬインスタンスの有効性を確認（ｖａｌｉｄａｔｉｏｎ）する場合は、有効性確認を実行するのに必要なコンポーネントのみをロードすればよい。有効性確認実行中は、スキーマの使用する部分のみがロードされ、キャッシングされる。スキーマキャッシュには、ＸＭＬインスタンスの有効性確認のために最適化されたＸＭＬスキーマコンポーネントのメモリ内の表現が格納される。ＸＭＬスキーマコンポーネントは、メタデータテーブルから読み取り専用オブジェクトとしてメインメモリにロードされるので、複数のユーザが有効性確認のためのメモリ内オブジェクトとして使用できる。操作中にＸＭＬスキーマが変更された場合は、スキーマキャッシュエントリが無効になる。また、データベースサーバの負荷が大きい場合は、使用しないスキーマキャッシュエントリがアンロードされる。以上の新機能の観点において、何千ものＸＭＬスキーマコンポーネントを含み、多くの同時ユーザをサポートする大規模なエンタープライズ環境で動作するスケーラブルなシステムを提供する。
【００１４】
別の態様においては、表示コンポーネントによって内部のデータを読み取り専用方式で表示できる。カタログ表示により、ＳＱＬサーバの内部メタデータ構造をテーブルに表示できる。ユーザはこの表示に関するクエリを実行はできるが、これを直接変更することはできない。
【００１５】
前述の目的と関連の目的を達成するために、本明細書に開示する発明の特定の例示的な態様について、以下の実施形態と添付の図面に関連付けながら説明する。ただし、このような態様は例を示すものであり、本明細書に開示する原理を使用する様々な方法の一部にすぎず、こうした態様やそれと同等のもののすべてを含むことを意図するものではない。その他の利点と新機能は、以下に示す実施形態と添付の図面を関連付けて考察することで明らかになるであろう。
【発明を実施するための最良の形態】
【００１６】
本発明について添付の図面に関連付けながら詳細に説明するが、全体にわたって同類の要素には似かよった参照番号を使用する。以下の説明において、本発明の理解を深めるために、説明を目的として具体的に特定の番号について詳細に説明する。ただし、本発明は以下に示す個々の詳細な要素（ｓｐｅｃｉｆｉｃ  ｄｅｔａｉｌｓ）がなくても実施できることは明らかである。他のインスタンスでは、本発明の説明を容易にするために、既知の構造とデバイスをブロック図の形で示している。
【００１７】
本出願で使用する限り、「コンポーネント」および「システム」という用語は、コンピュータ関連のエンティティを表すものとし、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、実行中のソフトウェア（ｓｏｆｔｗａｒｅ  ｉｎ  ｅｘｅｃｕｔｉｏｎ）のいずれでもよい。例えば、コンポーネントは、プロセッサで実行するプロセス、プロセッサ、ハードディスクドライブ、複数のストレージドライブ（光および／または磁気記憶媒体）、オブジェクト、実行可能ファイル、実行中のスレッド、プログラム、および／またはコンピュータのいずれでもよいが、これらに限定はされない。例えば、サーバ上で動作するアプリケーションとサーバはいずれもコンポーネントと言える。実行中のプロセスおよび／またはスレッド内には、１つまたは複数のコンポーネントが存在してもよい。また、コンポーネントは１台のコンピュータに集中してもよいが、２台またはそれ以上のコンピュータに分散してもよい。
【００１８】
ＸＭＬ（ｅＸｔｅｎｄｅｄ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）スキーマの指定は、ＸＭＬ文書の構造を説明しており、冗長かつ複雑である。本発明は、例えばＸＭＬスキーマ文書をリレーショナルテーブルに格納するＸＭＬ型システムをサポートするＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）へのアプリケーションを検出する。ただし、これは１つの例示的なアプリケーションにすぎず、限定と理解してはならない。つまり、本発明は２つの異なるデータ構造間の変換におけるアプリケーションを検出する。開示された発明は、スキーマ定義言語は提示された形式で保存する必要がなく、同様にスキーマコンポーネントのすべての情報をキャプチャする別の形式でも保存できることを示している。リレーショナル表現はこうした形式の１つであり、他の形式には、例えばオブジェクトリレーショナル、オブジェクト指向、他のＸＭＬ形式などがある。ＳＱＬサーバのその他のコンポーネント（ＸＭＬクエリプロセッサやオプティマイザなど）は、ＸＭＬ型システムを使用してクエリをコンパイルし、実行する。さらに、高度なアプリケーション（例えば在庫に関するアプリケーション）は、ＸＭＬ型システムの最上位に構築される。
【００１９】
例えば、リレーショナルデータベースシステムにＸＭＬスキーマ文書を格納するのは新しい挑戦である。例えば、ＸＭＬスキーマ文書のＩＤ（例えばそのターゲット名前空間による）とＸＭＬスキーマ文書内で指定する型定義は、定義の特性と型をキャプチャするリレーショナル構造の行にマップされる（例えば、ＸＭＬスキーマ文書によるＣｕｓｔｏｍｅｒＴｙｐｅなどの要素の型定義は、リレーショナルシステム内に格納するときに、それが要素の型定義であることを記憶しておく必要がある）。さらに型の階層を記録する必要があり、単純型ファセットによって追加の情報がキャプチャされ、リレーショナル構造からＸＭＬスキーマの型定義を再構築することもできる。
【００２０】
本アプローチの新しい点はｍｕｌｔｉ−ｆｏｌｄである。第１に、ＩＤまたは名前によって特定のコンポーネントに迅速に検索できる。すべてのＸＭＬスキーマコンポーネントの検索（名前またはＩＤによる）は、リレーショナルストアのインデックスシークを利用することでＩ／Ｏ操作の回数を最小限に抑える。第２に、派生チェーン構造にもインデックスが付けられる。したがって、型のリレーションシップを容易かつ効率的に決定できる。第３に、細分されたスキーマは正規のリレーショナルオブジェクトなので、ＸＭＬスキーマコンポーネントの様々なリレーショナル表示を提供できる。例えば、ユーザに向けて様々なＸＭＬスキーマコンポーネント（例えば、要素、属性、型、ワイルドカード）を１つのコンポーネントテーブルに表示できる。第４に、ＸＭＬスキーマを細分することで、ユーザは任意の望みのクエリを記述できる。
【００２１】
最後に、ＸＭＬスキーマはテーブルに細分されるので、ＸＭＬインスタンスの有効性を確認する場合は、有効性確認に必要なコンポーネントのみをロードすればよい。有効性確認実行中は、スキーマの使用する部分のみがロードされ、キャッシングされる。「スキーマキャッシュ」には、ＸＭＬインスタンスの有効性確認に合わせて最適化されたＸＭＬスキーマのメモリ内での表現が格納される。ＸＭＬスキーマコンポーネントは、メタデータから読み取り専用オブジェクトとしてメインメモリにロードされるので、複数のユーザが有効性確認のためのメモリ内オブジェクトとして使用できる。操作中にＸＭＬスキーマが変更された場合は、スキーマキャッシュエントリが無効になる。さらに、データベースサーバの負荷が大きい場合は、使用しないスキーマキャッシュエントリがアンロードされる。以上の新機能の観点で、何千ものＸＭＬスキーマコンポーネントを含み、多くの同時ユーザをサポートする大規模なエンタープライズ環境で動作するスケーラブルなシステムを提供する。
【００２２】
ここで図１を参照すると、ＸＭＬスキーマデータとその他のデータ構造（例えばリレーショナルデータ）との変換を可能にするシステム１００が示されている。変換コンポーネント１０２は、ＸＭＬスキーマをメタデータのテーブルに分解して選択的にアクセスできるようにすることで変換機能（ＸＭＬスキーマの有効性確認を含む）を提供し、ＸＭＬデータをリレーショナルデータ構造に接続できるようにする。図１では、入力のＸＭＬスキーマからリレーショナルへのマッピングを示しているが、開示する変換アーキテクチャはこれに限定はされず、リレーショナル構造に変換され、さらに元に戻される任意の入力スキーマへのアプリケーションを検出する。本明細書で図１０に示すようなターゲットリレーショナルスキーマは、ＸＳＤを表現できる。したがって、スキーマをＲＤＦ（ｒｅｓｏｕｒｃｅ  ｄｅｓｃｒｉｐｔｉｏｎ  ｆｏｒｍａｔ）に変換するにはターゲットスキーマは非常に様々である。
【００２３】
図２を参照すると、ＸＭＬ／リレーショナル変換の１つの方法を示す流れ図が示されている。説明を簡単にするために、ここに示す１つまたは複数の方法は、例えば流れ図の形で、一連の動作として図示され、説明されているが、本発明がこの動作の順序に限定されないことを理解されたい。例えば、いくつかの動作は、本発明に従って以下に説明するものとは異なる順序で行われてもよく、かつ／またはここに図示し、説明する他の動作と同時に行われてもよい。例えば、この方法は相互に関連する一連の状態またはイベントとしても（状態図のように）表現できることを当業者は理解されたい。また、本発明による方法を実装するために、図示されたすべての動作が必要なわけではない。
【００２４】
ＸＭＬスキーマのからＸＭＬからリレーショナル表現への変換は、複数のフェーズに分割できる。第１のフェーズにおいて、２００では、ＸＭＬスキーマデータを消費して変換プロセスの準備をする。２０２では、メモリ内にシンボルテーブルが作成される（ＸＭＬスキーマのメモリ内の表現）。第２のフェーズにおいて、２０４では、シンボルテーブルを調べてＸＭＬスキーマの構造の有効性が確認される。最後のフェーズにおいて、２０６では、ＸＭＬスキーマのメモリ内の表現がリレーショナル形式で保存される。
【００２５】
データを保存する最後のフェーズでは、ＸＭＬスキーマ型の構造を説明する新しいコードがメタデータテーブルに格納される。図３は、ＸＭＬスキーマデータ３０２を細分したリレーショナルデータベース内のテーブルのシステム３００を示している。これはライトスルーキャッシュである。１つの実施形態において、ＸＭＬスキーマデータ３０２は複数のテーブル（コンポーネントテーブル３０４、参照テーブル３０６、配置テーブル３０８、ファセットテーブル３１０、修飾名（ｑｕａｌｉｆｉｅｄ  ｎａｍｅ）テーブル３１２）内にメタデータとして保存される。ＩＤコンポーネント３１４は、ＸＭＬスキーマデータ３０２にインターフェース接続してそのコンポーネントのそれぞれに識別子（例えばコンポーネントＩＤ）を割り当てる。キャッシュメモリ３１６は、各テーブル（３０４、３０６、３０８、３１０、３１２）にインターフェース接続するので、任意の単一テーブルの内容または任意に組み合わせた複数テーブルの内容にアクセスでき、これを維持でき、リレーショナルデータベース３１８へのデータアクセスを改善できる。データはＸＭＬスキーマキャッシュ３１６に読み込まれ、リレーショナルデータベース３１８のテーブルに細分される。外部のクライアントはリレーショナルデータベースにアクセスし、必要に応じてキャッシュ３１６はこれをテーブルから読み込む。同様に、変換コンポーネントはリレーショナルデータを作成してキャッシュ３１６に書き込み、さらに永続的なコピーをディスク上のテーブルに書き込む。このように、メモリ内のコピーは常にディスク上のコピーと同期する。
【００２６】
それに従って、図４はＸＭＬスキーマデータをテーブルに細分する方法を示している。４００で、ＸＭＬスキーマデータはＩＤを割り当てられた関連のＸＭＬスキーマコンポーネントに分解される。４０２で、ＸＭＬスキーマはテーブル内でメタデータとして維持される。４０４で、有効性確認のプロセスでは、ＸＭＬスキーマデータの有効性確認に必要なスキーマコンポーネントのみをロードし、キャッシングする。４０６では、ＸＭＬスキーマ型の構造を説明するデータがテーブルに格納される。
【００２７】
図５は、より詳細なテーブルシステム５００と各テーブルに格納できるメタデータを示している。ＸＭＬスキーマデータ３０２には、ＩＤコンポーネント３１４によってＩＤを割り当てられたＸＭＬコンポーネントの複数のフレーバ（ｆｌａｖｏｒｓ）（要素、型、属性、ワイルドカードなど）が含まれる。１つの実装において、各コンポーネントにＩＤ（ＥＬＥＭＥＮＴｓ／ＩＤｓ、ＴＹＰＥｓ／ＩＤｓ、ＡＴＴＲＩＢＵＴＥｓ／ＩＤｓ、ＷＩＬＤＣＡＲＤｓ／ｌＤｓなどと表される）が割り当てられる。ＸＭＬスキーマコンポーネントの基本的なプロパティはコンポーネントテーブル３０４に記録される。プロパティには、派生の種類、コンポーネントの種類、コンポーネント名、ＸＭＬコレクションＩＤ、様々なフラグといった属性が含まれる。派生の種類に関連する派生構造は、参照テーブル３０６に記録される。単純型ファセットは、ファセットテーブル３１０に記録される。複合型の場合は、配置テーブル３０８の配置を使用して型階層が指定される。型階層は[sys.xml_schema_components].[scoping_xml_component_id]と[sys.xml_schema component_placements].[placed_xml_component_id]に格納される。配置テーブルには、コンポーネントテーブルには格納されないＸＭＬスキーマデータ内の兄弟（ｓｉｂｌｉｎｇｓ）の相対的な順序も格納される。列[sys.xml_schema_components].[base_xml_component_id]には、型の派生も格納される（親子の階層として）。コンポーネントの配置のみでは型階層を定義するには不十分である。配置には、共通出現指示子（ｇｅｎｅｒｉｃ  ｏｃｃｕｒｒｅｎｃｅ  ｉｎｄｉｃａｔｏｒ）も含まれる。基本的に、配置はグラフノード間にＸＭＬスキーマコンポーネントが構成する境界と考えてもよい。コンポーネント名とワイルドカード名前空間名はすべて修飾名テーブル３１２に記録される。
【００２８】
ＸＭＬスキーマコレクションと呼ばれる新しい概念を使用すると、ＳＱＬ  Ｓｅｒｖｅｒ  ２００５データベース内でＸＭＬスキーマを管理できる。この概念については、すでに出願中の「XML Schema Collections and Corresponding Systems and Methods」という名称の特許文献１（２００３年１２月１日に本出願の出願人によって出願された）に説明されている。ＸＭＬスキーマコレクションはメタデータオブジェクトであり、ステートメントＣＲＥＡＴＥ  ＸＭＬ  ＳＣＨＥＭＡ  ＣＯＬＬＥＣＴＩＯＮを使用してＸＭＬスキーマコレクションを作成すると同時に、１つまたは複数のＸＭＬスキーマをこれにロードできる。
【００２９】
ＸＭＬスキーマコレクションが作成されると、ステートメントＡＬＴＥＲ  ＸＭＬ  ＳＣＨＥＭＡ  ＣＯＬＬＥＣＴＩＯＮを使用してＸＭＬスキーマコレクションを変更することで、より多くのＸＭＬスキーマをこれにロードできる。ＸＭＬスキーマコレクションは、ステートメントＤＲＯＰ  ＸＭＬ  ＳＣＨＥＭＡ  ＣＯＬＬＥＣＴＩＯＮを使用してシステムから削除できる。
【００３０】
以下は、ＸＭＬスキーマコレクションを作成し、書籍のＸＭＬスキーマをこれにロードする例である。
【００３１】
【表１】
2006114045.tif 000003
【００３２】
以下は、既存のＸＭＬスキーマコレクションにＤＶＤのＸＭＬスキーマを追加する例である。
【００３３】
【表２】
2006114045.tif 000004
【００３４】
以下は、ＸＭＬスキーマコレクションを削除する例である。
【００３５】
ＤＲＯＰ  ＸＭＬ  ＳＣＨＥＭＡ  ＣＯＬＬＥＣＴＩＯＮ  ｍｙＣｏｌｌｅｃｔｉｏｎ
ＸＭＬスキーマの内部キャッシュへの保存に関連して、パフォーマンスやリソース利用のニーズをサポートするために、ＸＳＤ（ＸＭＬ  Ｓｃｈｅｍａ  Ｄｅｆｉｎｉｔｉｏｎ：ＸＭＬスキーマ定義）型キャッシュ（本明細書ではスキーマキャッシュとも呼ぶ）が実装される。内容モデルをコンパイルするには、非常に多くのメモリとＩ／Ｏが必要である。例えば、複数のファセット、要素、属性を伴う型には、多くの（例えば２０〜５０）のメタデータオブジェクトへの参照が必要である。ＸＳＤの一部をロードすること自体がすでに多くの商用アプリケーションに対する改善であるが、サーバ（例えば、ＳＱＬ  Ｓｅｒｖｅｒ）では並行処理の必要性が高いので、キャッシングすることによってデータアクセスが改善される。ただし、以下はＳＱＬサーバのコンテクストで説明するが、他の該当するサーバも開示されたキャッシュ管理メカニズムによって恩恵を被ることを理解されたい。
【００３６】
入力スキーマ（例えばＸＭＬ）を多くのリレーショナルテーブルに細分し、スキーマの最も頻繁に使用する部分のみを選択的にロードし、キャッシングすることができる。さらに、リレーショナルレイアウトには複数のプライマリインデックスとセカンダリインデックスが含まれるので、スキーマのロードは高速になる。ＸＭＬスキーマはテーブルに細分されるので、ＸＭＬインスタンスの有効性を確認する場合は有効性を確認するのに必要なコンポーネントのみをロードすればよい。有効性確認実行中は、スキーマの使用する部分のみがロードされ、キャッシングされる。スキーマキャッシュには、ＸＭＬインスタンスの有効性確認に合わせて最適化されたＸＭＬスキーマのメモリ内の表現が格納される。ＸＭＬスキーマコンポーネントは、メタデータから読み取り専用オブジェクトとしてメインメモリにロードされるので、複数のユーザがメモリ内オブジェクトとして使用して有効性を確認できる。操作中にＸＭＬスキーマが変更された場合は、スキーマキャッシュエントリが無効になる。さらに、データベースサーバの負荷が大きい場合は、使用しないスキーマキャッシュエントリがアンロードされる。以上の新機能の観点では、何千ものＸＭＬスキーマコンポーネントを格納し、多くの同時ユーザをサポートする大規模なエンタープライズ環境で動作するスケーラブルなシステムを提供する。
【００３７】
必要なスキーマがリレーショナルテーブルに配置されると、型、属性、要素のいずれかの定義に該当する部分のみがＸＳＤ型キャッシュに追加される。実施形態においては、スキーマインポートから逆のメカニズムが使用される。つまり、まずシンボルテーブルが作成され、次にキャッシングする有効性確認の構造が抽出される。
【００３８】
キャッシングに関しては、最もアクティブなエントリはメモリ内に維持されるが、使用頻度の低いエントリは定期的に削除されるＳＱＬ  Ｓｅｒｖｅｒのキャッシングフレームワークを使用できる。さらに、現在システム上でメモリが逼迫することによってシステム上のキャッシュをクリーンアップするメカニズムを使用する。システムが過負荷になると、エントリがさらに積極的にキャッシュから削除される。キャッシュをクリーンアップするアルゴリズムでは、エントリの計算に必要なＩ／Ｏ読み出しの回数とキャッシュエントリの計算に必要な総メモリも考慮する。
【００３９】
ＸＭＬスキーマのリレーショナル表現による最後の特性は、ＸＭＬスキーマコンポーネントテーブルとその他のスキーマテーブルに関して作成されたインデックスによるパフォーマンスの向上である。継承は、効率的にチェックできる。主にデータインポート中やＸＱｕｅｒｙキャスティングなどの場合に、ＳＱＬ  Ｓｅｒｖｅｒのいくつかの部分で継承のチェックを実行する。
【００４０】
図６は、キャッシュを使用した変換、メモリ管理、内部表示を可能にするシステムを示している。システム６００にはスキーマ構造（例えば、ＸＭＬスキーマ）をメタデータのテーブルに分解して選択的にアクセスできるようにすることで変換機能を提供し、ＸＭＬデータをリレーショナルデータ構造にインターフェース接続できるようにする変換コンポーネント６０２が含まれる。キャッシュメモリおよびメモリ管理インターフェース（ＭＭＩ：ｍｅｍｏｒｙ  ｍａｎａｇｅｍｅｎｔ  ｉｎｔｅｒｆａｃｅ）コンポーネント６０４によって、キャッシュメモリ内にメタデータのテーブルを格納でき、必要なＸＭＬコンポーネントのみに高速にアクセスできるようになる。ユーザは、ＸＭＬスキーマに準拠するデータを提供する。システム６００は、ユーザが提供したデータが実際にＸＭＬスキーマに準拠することを確認する。換言すると、データベースエンジンはユーザが提供したデータとスキーマの両方に注目し、データの有効性を効率的に確認する方法を決定する。表示コンポーネント６０６は、内部のメタデータテーブルを表形式で表示できる。キャッシュメモリ管理については入力のＸＭＬスキーマからリレーショナルへのマッピングに関して図６に示しているが、開示されたキャッシング管理アーキテクチャはこれに限定はされず、任意の入力スキーマとリレーショナル構造との変換のアプリケーションを検出することに留意されたい。ＤＤＬ（Ｄａｔａ  Ｄｅｆｉｎｉｔｉｏｎ  Ｌａｎｇｕａｇｅ：データ定義言語）（ＣＲＥＡＴＥ、ＡＬＴＥＲ、ＤＲＯＰ  ＸＭＬ  ＳＣＨＥＭＡ  ＣＯＬＬＥＣＴＩＯＮ）実行中に、ＤＤＬインポートまたはＤＤＬドロップ中に名前空間のバージョンが変更される。これで、既存のキャッシュエントリが無効になる。１つの実施形態では、データベースのバージョン変更が検出されると、キャッシュ全体がフラッシュされる。
【００４１】
図７は、利用できる様々なカタログ表示を示している。７００で、ＸＭＬスキーマコレクション表示が提供され、続いてＸＭＬスキーマ名前空間表示が提供される（７０２）。７０４で、コンポーネントカタログ表示が提供され、続いてコンポーネント配置表示（７０６）とワイルドカード名前空間表示（７０８）が提供される。コンポーネント表示７０４は、型表示７１０（型定義に関する詳細な情報が含まれる）、要素表示７１２（要素定義に関する詳細な情報が含まれる）、属性表示７１４（属性定義に関する詳細な情報が含まれる）、モデルグループ表示７１６、およびワイルドカード表示７１８で補足される。型表示からは、ファセット表示７２０に拡張される。こうした表示は、図１０により詳細に示されている。
【００４２】
図８は、ＭＭＩを活用できるコンポーネントを示すブロック図である。ＭＭＩ  ８０２を活用するコンポーネントは、ＣＬＲ  ８０４、ネットワークライブラリ８０６、フルテキスト検索８０８である。ＸＭＬクエリプロセッサ８１０は、クエリテーブルの直接的なコンシューマとして表される。ＣＬＲ  ８０４は、ＭＭＩを活用してメモリ逼迫に対応する２つの主要なコンポーネント、すなわちアプリケーションドメインとガーベッジコレクション（ＧＣ）メモリを備えている。１つのコンポーネントであるアプリケーションドメインは、非常に多くのメモリを消費する可能性がある。アプリケーションドメインは、要求があり次第ロードし、使用しない場合はアンロードすることができる。アプリケーションドメインのエントリデータのサイズは、平均で約１ＭＢである。ロードするアプリケーションドメインの数は、仮想メモリのサイズによって制限される。１つの実施形態では、ＣＬＲを外部的にＳＱＬサーバのメモリ管理メカニズムに割り当てることができる。別の実施形態では、本発明のメモリ管理メカニズムを使用するようにＣＬＲを変換する。キャッシュ内のエントリの持続時間は、使い方とそのコストによって定義できる。
【００４３】
ＣＬＲ  ８０４は第２のコンポーネントであるＧＣメモリを備えている。これはヒープ（ｈｅａｐ）と考えることができる。ＣＬＲオブジェクトは、このヒープから割り当てることができる。このヒープは、ガーベッジコレクションと呼ばれるメカニズム（使用不可能なメモリを変換する）を介して縮小される。ＧＣヒープのサイズは、仮想メモリと物理メモリのサイズに制限される。１つの実施形態では、システム内にＣＰＵと同じ数のＧＣヒープが存在する。１つのインスタンスでは、ＣＬＲを外部的にＳＱＬサーバのメモリ管理メカニズムに割り当てる。別のインスタンスでは、開示されたメモリ管理メカニズムを使用するようにＣＬＲを変換する。コストのメカニズムは、ＧＣヒープのサイズとその使い方に基づいていてもよい。ＧＣヒープは破棄できず、縮小のみ可能である。
【００４４】
ネットワークライブラリのページプールに関連して、ネットワークの読み出しと書き込みを実行するために、ネットワークライブラリは複数のＯＳページサイズのメモリページを要求してもよい。ページサイズは、クライアントの構成によって異なる場合がある。プールサイズは、クライアントのアクティビティとページサイズの構成によって異なる場合もある。１つのインスタンスでは、ネットワークライブラリはＯＳから直接ページを割り当て、空きページのプールを保持する。ページは、通常はスケジューラまたはネットワークカードに密接に関連する。実際のコストはない。メモリが逼迫すると、ネットワークライブラリはそのプールを縮小する。空きプール内のページの持続時間は、現在のメモリ逼迫状態によって定義できる。ＸＭＬスキーマキャッシュのエントリサイズは約２５６〜２ＫＢであり、キャッシュサイズの制限はない。割り当てメカニズムは型あたりのメモリオブジェクト、コストはＣＰＵ＋ディスクＩ／Ｏ＋ネットワークＩ／Ｏ、持続時間はコスト＋使い方である。
【００４５】
図９は、メモリマネージャクライアント（ＭＭＣｌｉｅｎｔ）インターフェースの設計の概要を示すオブジェクト図９００である。メモリマネージャクライアント９０２はＲｅｓｏｕｒｃｅＣｌｉｅｎｔメカニズム９０４を利用する。ＲｅｓｏｕｒｃｅＣｌｉｅｎｔ  ９０４は、ＳＯＳ＿Ｈｏｓｔオブジェクト９０６に登録され、登録されたリソースごとに通知を受け取る。ＳＯＳ＿Ｈｏｓｔオブジェクト９０６は、リソース所有権を実装する。リソースを消費するクライアントは、ＲｅｓｏｕｒｃｅＣｌｉｅｎｔインターフェース９０４を実装する必要がある。ＭＭＣｌｉｅｎｔ  ９０２は、ＲｅｓｏｕｒｃｅＣｌｉｅｎｔインターフェース９０４を大規模なメモリコンシューマに一般化する。フルテキスト、ネットワークライブラリ、ＣＬＲなどのコンシューマは、ＭＭＣｌｉｅｎｔインターフェース９０２を使用できる。ＭＭＣｌｉｅｎｔ  ９０２は、ＲｅｓｏｕｒｃｅＣｌｉｅｎｔインターフェース９０４を大規模なメモリコンシューマに拡張する。ＭＭＣｌｉｅｎｔ  ９０２は、共有メモリに関するＡｌｌｏｃ／Ｆｒｅｅ、ＶｉｒｔｕａｌＡｌｌｏｃ／ＶｉｒｔｕａｌＦｒｅｅ、Ｍａｐ／ＵｎｍａｐなどのＡＰＩを提供する。データをキャッシングすることに興味のあるコンシューマ（ｃｏｎｓｕｍｅｒ）は、ＣａｃｈｅＳｔｏｒｅインターフェースを使用してデータをキャッシングできる。内部的には、ＣａｃｈｅＳｔｏｒｅがＭＭＣｌｉｅｎｔインターフェース９０２を一般化する。
【００４６】
図１０は、１つのインスタンスによる細分されたＸＭＬスキーマの提示されたリレーショナル形式のカタログ表示を示すＵＭＬ（Ｕｎｉｆｉｅｄ  Ｍｏｄｅｌｉｎｇ  Ｌａｎｇｕａｇｅ：統一モデリング言語）図１０００である。カタログ表示により、ＳＱＬサーバの内部メタデータ構造をテーブル形式で表示できる。ユーザは、カタログ表示に対して読み取り専用のクエリアクセスのみを実行できる。本明細書では、ＸＭＬスキーマコレクションとＸＭＬスキーマに関する複数のカタログ表示について説明する。以下のセクションでは、ＸＭＬスキーマコレクション（ｍｙＣｏｌｌｅｃｔｉｏｎ）にロードされた「ｂｏｏｋｓ」スキーマの例を使用してカタログ表示について説明し、ＸＭＬスキーマストレージの詳細を示す。本明細書で説明する発明は、ＸＭＬスキーマをＳＱＬサーバのメタデータコンポーネントの内部に格納し、内部で管理するメカニズムを提供する。図１０は、内部の様々なインスタンスから得られる表示を示す図である。
【００４７】
ｓｙｓ．ｘｍｌ＿ｓｃｈｅｍａ＿ｃｏｌｌｅｃｔｉｏｎｓカタログ表示１００２には、ＸＭＬスキーマコレクションごとに１行が表示される。ＸＭＬスキーマコレクションは、ＸＳＤ定義の名前付きセットである。ＸＭＬスキーマコレクション自体はリレーショナルスキーマに含まれており、スキーマに着目した（ｓｃｈｅｍａ−ｓｃｏｐｅｄ）ＳＱＬ名で識別される。値ｘｍｌ＿ｃｏｌｌｅｃｔｉｏｎ＿ｉｄと（ｓｃｈｅｍａ＿ｉｄ，ｎａｍｅ）はこの表示に関して一意である。
【００４８】
【表３】
2006114045.tif 000005
【００４９】
例：ＸＭＬスキーマコレクションｍｙＣｏｌｌｅｃｔｉｏｎを作成した後のｓｙｓ．ｘｍｌ＿ｓｃｈｅｍａ＿ｃｏｌｌｅｃｔｉｏｎｓの行。
【００５０】
【表４】
2006114045.tif 000006
【００５１】
ｓｙｓ．ｘｍｌ＿ｓｃｈｅｍａ＿ｎａｍｅｓｐａｃｅｓカタログ表示１００４には、ＸＳＤで定義されたＸＭＬ名前空間ごとに１行が表示される。値（ｃｏｌｌｅｃｔｉｏｎ＿ｉｄ，ｎａｍｅｓｐａｃｅ＿ｉｄ）と（ｃｏｌｌｅｃｔｉｏｎ＿ｉｄ，ｎａｍｅ）は表示内で一意である。
【００５２】
【表５】
2006114045.tif 000007
【００５３】
例：ＸＭＬスキーマコレクションｍｙＣｏｌｌｅｃｔｉｏｎを作成した後のｓｙｓ．ｘｍｌ＿ｓｃｈｅｍａ＿ｎａｍｅｓｐａｃｅｓの行。
【００５４】
【表６】
2006114045.tif 000008
【００５５】
ｓｙｓ．ｘｍｌ＿ｓｃｈｅｍａ＿ｃｏｍｐｏｎｅｎｔｓカタログ表示１００６には、ＸＭＬスキーマのコンポーネントごとに１行が表示される。ペア（ｃｏｌｌｅｃｔｉｏｎ＿ｉｄ，ｎａｍｅｓｐａｃｅ＿ｉｄ）は、含まれる名前空間への複合外部キーである。ｘｍｌ＿ｃｏｍｐｏｎｅｎｔ＿ｉｄは一意である。名前付きのコンポーネントでは、（symbol_space,name,scoping_xml_component_id,is_qualified,xml_namespace_id,xml_collection_id）も一意である。２つの再帰的なリレーションシップがある。１つはｂａｓｅ＿ｘｍｌ＿ｃｏｍｐｏｎｅｎｔ＿ｉｄ外部キーで決定される。ＮＵＬＬでない場合は、継承階層の親コンポーネントへの参照である。もう１つはｓｃｏｐｉｎｇ＿ｘｍｌ＿ｃｏｍｐｏｎｅｎｔ＿ｉｄ外部キーで決定される。ＮＵＬＬの場合は、コンポーネントのスコープがグローバルである。ＮＵＬＬでない場合は、スコーピング名前空間を構成する他のＸＭＬコンポーネントへの参照である。
【００５６】
【表７】
2006114045.tif 000009
【００５７】
【表８−１】
2006114045.tif 000010
【００５８】
【表８−２】
2006114045.tif 000011
【００５９】
【表９】
2006114045.tif 000012
【００６０】
ｓｙｓ．ｘｍｌ＿ｓｃｈｅｍａ＿ｔｙｐｅｓカタログ表示１００８には、型（ｓｙｍｂｏｌ＿ｓｐａｃｅがＴ）のｘｍｌコンポーネントごとに１行が表示される。
【００６１】
【表１０−１】
2006114045.tif 000013
【００６２】
【表１０−２】
2006114045.tif 000014
【００６３】
ｓｙｓ．ｘｍｌ＿ｓｃｈｅｍａ＿ｆａｃｅｔｓカタログ表示１０１０には、ｘｍｌ型定義（ｓｙｓ．ｘｍｌ＿ｓｃｈｅｍａ＿ｔｙｐｅｓに対応する）のファセット（制限）ごとに１行が表示される。
【００６４】
【表１１】
2006114045.tif 000015
【００６５】
例：ＸＭＬスキーマコレクションｍｙＣｏｌｌｅｃｔｉｏｎを作成した後のｓｙｓ．ｘｍｌ＿ｓｃｈｅｍａ＿ｆａｃｅｔｓの行。
【００６６】
【表１２】
2006114045.tif 000016
【００６７】
ｓｙｓ．ｘｍｌ＿ｓｃｈｅｍａ＿ｅｌｅｍｅｎｔｓカタログ表示１０１２には、要素（Ｂのｓｙｍｂｏｌ＿ｓｐａｃｅ）であるｘｍｌコンポーネントごとに１行が表示される。
【００６８】
【表１３】
2006114045.tif 000017
【００６９】
ｓｙｓ．ｘｍｌ＿ｓｃｈｅｍａ＿ｍｏｄｅｌ＿ｇｒｏｕｐｓカタログ表示１０１４には、モデルグループ（ｓｙｍｂｏｌ＿ｓｐａｃｅがＭ）のｘｍｌコンポーネントごとに１行が表示される。
【００７０】
【表１４】
2006114045.tif 000018
【００７１】
ｓｙｓ．ｘｍｌ＿ｓｃｈｅｍａ＿ａｔｔｒｉｂｕｔｅｓカタログ表示１０１６には、属性（ｓｙｍｂｏｌ＿ｓｐａｃｅがＡ）のｘｍｌコンポーネントごとに１行が表示される。
【００７２】
【表１５】
2006114045.tif 000019
【００７３】
ｓｙｓ．ｘｍｌ＿ｓｃｈｅｍａ＿ｗｉｌｄｃａｒｄｓカタログ表示１０１８には、属性ワイルドカード（ｋｉｎｄがＶ）または要素ワイルドカード（ｋｉｎｄがＷ）のｘｍｌコンポーネント（いずれもｓｙｍｂｏｌ＿ｓｐａｃｅはＮ）ごとに１行が表示される。
【００７４】
【表１６】
2006114045.tif 000020
【００７５】
例：ＸＭＬスキーマコレクションｍｙＣｏｌｌｅｃｔｉｏｎを作成した後のｓｙｓ．ｘｍｌ＿ｓｃｈｅｍａ＿ｗｉｌｄｃａｒｄｓの行。「ｂｏｏｋｓ」  ＸＭＬスキーマにはワイルドカードがないので、ワイルドカードのエントリは作成されない。
【００７６】
ｓｙｓ．ｘｍｌ＿ｓｃｈｅｍａ＿ｗｉｌｄｃａｒｄ＿ｎａｍｅｓｐａｃｅｓカタログ表示１０２０には、ｘｍｌワイルドカードの枚挙された名前空間ごとに１行が表示される。
【００７７】
【表１７】
2006114045.tif 000021
【００７８】
例：ＸＭＬスキーマコレクションｍｙＣｏｌｌｅｃｔｉｏｎを作成した後のｓｙｓ．ｘｍｌ＿ｓｃｈｅｍａ＿ｗｉｌｄｃａｒｄ＿ｎａｍｅｓｐａｃｅｓの行。「ｂｏｏｋｓ」  ＸＭＬスキーマにはワイルドカードがないので、ワイルドカードの名前空間のエントリは作成されない。
【００７９】
ｓｙｓ．ｘｍｌ＿ｓｃｈｅｍａ＿ｃｏｍｐｏｎｅｎｔ＿ｐｌａｃｅｍｅｎｔｓカタログ表示１０２２には、ｘｍｌコンポーネントの配置ごとに１行が表示される。
【００８０】
【表１８】
2006114045.tif 000022
【００８１】
例：ＸＭＬスキーマコレクションｍｙＣｏｌｌｅｃｔｉｏｎを作成した後のｓｙｓ．ｘｍｌ＿ｓｃｈｅｍａ＿ｃｏｍｐｏｎｅｎｔ＿ｐｌａｃｅｍｅｎｔｓの行。
【００８２】
【表１９】
2006114045.tif 000023
【００８３】
さらに図１１を参照すると、開示された変換アーキテクチャを実現するために動作できるコンピュータを示すブロック図が示されている。本発明の様々な態様の付加的なコンテクストを示すために、図１１と以下の説明は、本発明の様々な態様を実装できる適切なコンピューティング環境１１００について簡単かつ一般的に説明することを目的としている。本発明について、１台および／または複数台のコンピュータで動作するコンピュータ実行可能命令の一般的なコンテクストで説明してきたが、本発明を他のプログラムモジュールとの組合せ、および／またはハードウェアとソフトウェアの組合せで実装できることは当業者には言うまでもない。
【００８４】
一般に、プログラムモジュールには、ルーチン、プログラム、コンポーネント、データ構造などがあり、特定のタスクを実行するものや、特定の抽象データ型を実装するものもある。さらに、本発明による方法が、シングルプロセッサまたはマルチプロセッサによるコンピュータシステム、ミニコンピュータ、メインフレームコンピュータ、およびパーソナルコンピュータ、ハンドヘルドコンピューティングデバイス、マイクロプロセッサベースの家電製品またはプログラム可能な家電製品など、それぞれが１つまたは複数の関連デバイスに接続して動作する他のコンピュータシステム構成でも実施できることは、当業者には言うまでもない。
【００８５】
本発明の図示された態様は、通信ネットワークを介してリンクするリモート処理装置で特定のタスクを実行する分散コンピューティング環境でも実施できる。分散コンピューティング環境では、プログラムモジュールはローカルとリモートのいずれのメモリ記憶装置内に配置してもよい。
【００８６】
コンピュータは、通常は様々なコンピュータ可読媒体を備えている。コンピュータ可読媒体は、コンピュータからアクセスできる任意の使用可能な媒体でよく、揮発性と不揮発性の両方、および取り外し可能と不可能の両方の媒体が含まれる。例として、コンピュータ可読媒体にはコンピュータ記憶媒体および通信媒体を含めてもよいが、これらに限定はされない。コンピュータ記憶媒体には、コンピュータ可読の命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を記憶する任意の方法または技術で組み込まれた、揮発性と不揮発性の両方、および取り外し可能と不可能の両方の媒体が含まれる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリなどのメモリ技術、ＣＤ−ＲＯＭ、デジタルビデオディスク（ＤＶＤ：ｄｉｇｉｔａｌ  ｖｉｄｅｏ  ｄｉｓｋ）などの光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスクなどの磁気記憶装置、または必要な情報を格納でき、コンピュータからアクセスできる他の任意の媒体が含まれるが、これらに限定はされない。
【００８７】
通信媒体は、搬送波やその他の搬送メカニズムのような変調データ信号に含まれるコンピュータ可読の命令、データ構造、プログラムモジュール、またはその他のデータなどを具体化したものであり、任意の情報伝達媒体を含む。「変調データ信号」という用語は、信号内の情報を符号化するように、１つまたは複数のフィーチャを設定または変更された信号を意味する。例として、通信媒体には、有線ネットワーク、直接ワイヤ接続などの有線媒体と、音、ＲＦ、赤外線などの無線媒体が含まれるが、これらに限定はされない。上記の任意の組合せも、コンピュータ可読媒体の範囲内に含まれるものとする。もう一度図１１を参照すると、本発明の様々な態様を実装する例示的な環境１１００の要素となるコンピュータ１１０２が示されており、コンピュータ１１０２はプロセッシングユニット１１０４、システムメモリ１１０６、システムバス１１０８を備えている。システムバス１１０８は、システムメモリ１１０６からプロセッシングユニット１１０４までを含み、これに限定されないシステムコンポーネントを接続する。プロセッシングユニット１１０４は、市販の様々なプロセッサのいずれでもよい。デュアルマイクロプロセッサやその他のマルチプロセッサアーキテクチャもプロセッシングユニット１１０４として利用できる。
【００８８】
システムバス１１０８は、市販の様々なバスアーキテクチャの任意の１つを使用したメモリバス（メモリコントローラを伴っても伴わなくてもよい）、周辺バス、ローカルバスにさらに相互接続する各種バス構造のいずれでもよい。システムメモリ１１０６には、読み取り専用メモリ（ＲＯＭ：ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ）１１１０とランダムアクセスメモリ（ＲＡＭ：ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）１１１２が含まれる。起動時などにコンピュータ１１０２内の要素間の情報転送を支援する基本ルーチンを含む基本入出力システム（ＢＩＯＳ：ｂａｓｉｃ  ｉｎｐｕｔ／ｏｕｔｐｕｔ  ｓｙｓｔｅｍ）は、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭなどの不揮発性メモリ１１１０に格納される。また、ＲＡＭ  １１１２はデータをキャッシングするスタティックＲＡＭなどの高速のＲＡＭを備えていてもよい。
【００８９】
コンピュータ１１０２は、さらに内蔵のハードディスクドライブ（ＨＤＤ：ｈａｒｄ  ｄｉｓｋ  ｄｒｉｖｅ）１１１４（例えばＥＩＤＥ、ＳＡＴＡ）（内蔵のハードディスクドライブ１１１４は、適切な筐体（図示せず）に収納し、外付けで使用するように構成してもよい）、磁気フロッピー（登録商標）ディスクドライブ（ＦＤＤ：ｆｌｏｐｐｙ  ｄｉｓｋ  ｄｒｉｖｅ）１１１６（取り外し可能なディスケット１１１８に対する読み出しまたは書き込みを行う）、光ディスクドライブ１１２０（例えば、ＣＤ−ＲＯＭディスク１１２２の読み出し、またはＤＶＤなどの他の大容量光媒体に対する読み出しまたは書き込みを行う）を備えている。ハードディスクドライブ１１１４、磁気ディスクドライブ１１１６、および光ディスクドライブ１１２０は、それぞれハードディスクドライブインターフェース１１２４、磁気ディスクドライブインターフェース１１２６、および光ディスクドライブインターフェース１１２８を介してシステムバス１１０８に接続する。外付けドライブを実装するインターフェース１１２４には、ユニバーサルシリアルバス（ＵＳＢ：Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）とＩＥＥＥ  １３９４の少なくともいずれか１つまたは両方の技術が含まれる。
【００９０】
ドライブとこれに関連付けられたコンピュータ可読媒体は、データ、データ構造、コンピュータ実行可能命令を格納する不揮発性ストレージとして利用できる。コンピュータ１１０２の場合は、ドライブと媒体は任意のデータを適切なデジタル形式で格納できる。前述のコンピュータ可読媒体の説明は、ＨＤＤ、取り外し可能な磁気ディスケット、取り外し可能な光ディスク（ＣＤまたはＤＶＤなど）を表しているが、ｚｉｐドライブ、磁気カセット、フラッシュメモリカード、カートリッジなど、その他のコンピュータ可読媒体も例示的な動作環境で利用でき、さらにこうした任意の媒体に本発明の方法を実行するためのコンピュータ実行可能命令を格納できることを当業者は理解されたい。
【００９１】
オペレーティングシステム１１３０、１つまたは複数のアプリケーションプログラム１１３２、その他のプログラムモジュール１１３４、およびプログラムデータ１１３６を含む多くのプログラムモジュールは、ドライブおよびＲＡＭ  １１１２に格納できる。オペレーティングシステム、アプリケーション、モジュール、および／またはデータのすべてまたは一部をＲＡＭ  １１１２にキャッシングすることもできる。本発明が市販の様々なオペレーティングシステムまたは複数のオペレーティングシステムの組合せで実装できることを理解されたい。
【００９２】
ユーザは、１つまたは複数の有線／無線の入力装置（キーボード１１３８やマウス１１４０などのポインティングデバイス）を使用してコンピュータ１１０２にコマンドや情報を入力できる。他の入力装置（図示せず）には、マイクロフォン、ＩＲリモートコントロール、ジョイスティック、ゲームパッド、スタイラスペン、タッチスクリーンなどを含めてもよい。これらの入力装置および他の入力装置は、多くの場合にシステムバス１１０８に接続された入力装置インターフェース１１４２を介してプロセッシングユニット１１０４に接続するが、パラレルポート、ＩＥＥＥ  １３９４シリアルポート、ゲームポート、ＵＳＢポート、ＩＲインターフェースなどのような他のインターフェースを介して接続してもよい。
【００９３】
モニタ１１４４または他のタイプの表示装置も、ビデオアダプタ１１４６のようなインターフェースを介してシステムバス１１０８に接続される。コンピュータには、一般にモニタ１１４４以外にもスピーカーやプリンタなどの周辺出力装置（図示せず）が接続されている。
【００９４】
コンピュータ１１０２は、リモートコンピュータ１１４８のような１台または複数台のリモートコンピュータへの有線および／または無線の通信を介した論理接続を使用してネットワーク環境で動作できる。リモートコンピュータ１１４８は、ワークステーション、サーバコンピュータ、ルータ、パーソナルコンピュータ、ポータブルコンピュータ、マイクロプロセッサベースのエンターテイメントアプライアンス（ｅｎｔｅｒｔａｉｎｍｅｎｔ  ａｐｐｌｉａｎｃｅ）、ピアデバイス、または他の一般的なネットワークノードでよい。通常は、コンピュータ１１０２に関連して上で説明した要素の多くまたはすべてが含まれるが、簡単にするためにメモリ記憶装置１１５０のみを示している。図示された論理接続には、ローカルエリアネットワーク（ＬＡＮ：ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）１１５２および／またはさらに大規模なネットワーク（例えばワイドエリアネットワーク（ＷＡＮ：ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ）１１５４）への有線／無線の接続が含まれる。このようなＬＡＮおよびＷＡＮネットワーキング環境は、オフィスや企業では一般的であり、イントラネットなどの事業体規模のコンピュータネットワークを実現する。こうしたネットワークのすべては、インターネットなどのグローバル通信ネットワークに接続できる。
【００９５】
ＬＡＮネットワーキング環境で使用する場合に、コンピュータ１１０２は有線／無線の通信ネットワークインターフェースまたはアダプタ１１５６を介してローカルネットワーク１１５２に接続する。アダプタ１１５６は、ＬＡＮ  １１５２への有線または無線の通信を可能にする。ＬＡＮ  １１５２には、無線アダプタ１１５６と通信するための無線アクセスポイントを含めてもよい。
【００９６】
ＷＡＮネットワーキング環境で使用する場合、コンピュータ１１０２はモデム１１５８を備えているか、ＷＡＮ  １１５４上の通信サーバに接続する。あるいは、インターネットなどのＷＡＮ  １１５４を介して通信を確立するその他の手段を備えている。モデム１１５８（内蔵でも外付けでもよいし、有線でも無線でもよい）は、シリアルポートインターフェース１１４２を介してシステムバス１１０８に接続される。ネットワーク環境では、コンピュータ１１０２またはその一部に関連して記述したプログラムモジュールをリモートメモリ／記憶装置１１５０に格納できる。図示されたネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立する他の手段を使用してもよいことは言うまでもない。
【００９７】
コンピュータ４０２は、任意の無線デバイスまたは無線通信に動作可能に配置されたエンティティ（例えば、プリンタ、スキャナ、デスクトップおよび／またはポータブルコンピュータ、ＰＤＡ（ｐｏｒｔａｂｌｅ  ｄａｔａ  ａｓｓｉｓｔａｎｔ：携帯情報端末）、無線で検出できるタグに関連付けられた任意の装置または場所（例えば、ｋｉｏｓｋ、ニューススタンド、化粧室）、および電話と通信できる。これには、少なくともＷｉ−ＦｉとＢｌｕｅｔｏｏｔｈ（商標）の無線技術が含まれる。このように、通信は従来のネットワークと同様に事前に定義された構造でもよいし、単に少なくとも２台のデバイス間におけるその場限りの通信でもよい。
【００９８】
Ｗｉ−Ｆｉ（Ｗｉｒｅｌｅｓｓ  Ｆｉｄｅｌｉｔｙ）すなわちワイヤレスフィディリティーを使用すると、自宅のソファ（ｃｏｕｃｈ）、ホテルのベッド、あるいは職場の会議室から無線でインターネットに接続できる。Ｗｉ−Ｆｉは、例えばコンピュータなどのデバイスが屋内と屋外を問わず、基地局の担当範囲内のあらゆる場所でデータを送受信できる携帯電話（ｃｅｌｌ  ｐｈｏｎｅ）で使用するのと同様の無線技術である。Ｗｉ−Ｆｉネットワークでは、ＩＥＥＥ  ８０２．１１（ａ、ｂ、ｇなど）と呼ばれる無線（ｒａｄｉｏ）技術を使用して安全で信頼性の高い高速の無線接続を提供している。Ｗｉ−Ｆｉネットワークを使用すると、コンピュータの相互接続、インターネット接続、無線ネットワークへの接続が可能になる（ＩＥＥＥ  ８０２．３またはＥｔｈｅｒｎｅｔ（登録商標）などを使用）。Ｗｉ−Ｆｉネットワークは、例えば許可されていない２．４および５  ＧＨｚの電波帯域で１１  Ｍｂｐｓ（８０２．１１ａ）または５４  Ｍｂｐｓ（８０２．１１ｂ）のデータ転送速度で動作し、あるいは２つの帯域（デュアル  バンド（ｄｕａｌ  ｂａｎｄ））に対応する製品で動作するので、このネットワークは現実社会の多くのオフィスで使用されている基本的な１ＯＢａｓｅＴ有線Ｅｔｈｅｒｎｅｔ（登録商標）ネットワークと同等のパフォーマンスを提供できる。
【００９９】
ここで図１２を参照すると、例示的な変換コンピューティング環境１２００を表すブロック図が示されている。システム１２００には、１台または複数台のクライアント１２０２が含まれる。クライアント１２０２は、ハードウェアおよび／またはソフトウェア（例えばスレッド、プロセス、コンピューティングデバイス）でよい。クライアント１２０２には、本発明を使用することで、例えばｃｏｏｋｉｅおよび／または関連のコンテクスト情報を格納できる。
【０１００】
システム１２００には、１台または複数台のサーバ１２０４も含まれる。サーバ１２０４は、ハードウェアおよび／またはソフトウェア（例えばスレッド、プロセス、コンピューティングデバイス）でよい。サーバ１２０４には、例えば本発明を使用した変換を実行するスレッドを格納できる。クライアント１２０２とサーバ１２０４の間で可能な１つの通信の例は、２つ以上のコンピュータプロセス間で送信できるようになされたデータパケットの形でもよい。データパケットには、例えばｃｏｏｋｉｅおよび／または関連のコンテクスト情報を含めてもよい。システム１２００は、クライアント１２０２とサーバ１２０４との通信を可能にするための通信フレームワーク１２０６（例えばインターネットなどのグローバル通信ネットワーク）を備えている。
【０１０１】
通信は、有線（光ファイバーを含む）および／または無線の技術を使用して実現できる。クライアント１２０２は、クライアント１２０２のローカルな情報（例えばｃｏｏｋｉｅおよび／または関連のコンテクスト情報）を格納するための１つまたは複数のデータストア（ｓｔｏｒｅ（ｓ））１２０８に接続して機能する。同様に、サーバ１２０４はサーバ１２０４のローカルな情報を格納するための１つまたは複数のサーバデータストア１２１０に接続して機能する。
【０１０２】
以上、本発明の例について説明してきた。本発明について説明するためにコンポーネントまたは方法のあらゆる組合せについて説明するのはもちろん不可能であるが、他にも多くの組合せや置き換えが可能であることは当業者には言うまでもない。したがって、本発明には添付の特許請求の精神と範囲を逸脱しない代替、変更、変形のすべてが含まれるものとする。さらに、発明の実施の形態と特許請求の範囲のいずれかで使用する「含む」という用語およびその変形の範囲は、「備える」が特許請求の範囲で暫定的な用語として使用された場合に解釈される用語「備える」と同様に包括的な意味を表す。
【図面の簡単な説明】
【０１０３】
【図１】ＸＭＬスキーマとリレーショナルデータとの変換を可能にするシステムを示す図である。
【図２】ＸＭＬ／リレーショナル変換の１つの方法を示す流れ図である。
【図３】ＸＭＬスキーマデータを細分したテーブルのシステムを示す図である。
【図４】ＸＭＬスキーマデータをテーブルに処理する方法を示す図である。
【図５】より詳細なテーブルシステムと各テーブルに格納できるメタデータを示す図である。
【図６】キャッシュを使用した変換、メモリ管理、内部表示を可能にするシステムを示す図である。
【図７】内部の様々な態様から得られるカタログ表示を示す図である。
【図８】メモリ管理インターフェース（ＭＭＩ）を活用できるコンポーネントを示すブロック図である。
【図９】ＭＭＣｌｉｅｎｔクライアントインターフェースの設計の概要を示すオブジェクト図である。
【図１０】１つのインスタンスによる細分されたＸＭＬスキーマの提示されたリレーショナル形式のカタログ表示を示すＵＭＬ図である。
【図１１】開示された変換アーキテクチャを実現するために動作できるコンピュータを示すブロック図である。
【図１２】例示的な変換コンピューティング環境の概要を示すブロック図である。
【符号の説明】
【０１０４】
１１０４  プロセッシングユニット
１１０６  システムメモリ
１１０８  バス
１１１４  内蔵ＨＤＤ、外付けＨＤＤ
１１１８  ディスク
１１２０  ＣＤドライブ
１１２２  ディスク
１１２４  インターフェース
１１２６  インターフェース
１１２８  インターフェース
１１３０  オペレーティングシステム
１１３２  アプリケーション
１１３４  モジュール
１１３６  データ
１１３８  キーボード
１１４０  マウス
１１４２  入力装置インターフェース
１１４４  モニタ
１１４６  ビデオアダプタ
１１４８  リモートコンピュータ
１１５０  メモリ／ストレージ
１１５６  ネットワークアダプタ
１１５８  モデム
【図１】
2006114045.tif 000024
【図２】
2006114045.tif 000025
【図３】
2006114045.tif 000026
【図４】
2006114045.tif 000027
【図５】
2006114045.tif 000028
【図６】
2006114045.tif 000029
【図７】
2006114045.tif 000030
【図８】
2006114045.tif 000031
【図９】
2006114045.tif 000032
【図１０】
2006114045.tif 000033
【図１１】
2006114045.tif 000034
【図１２】
2006114045.tif 000035