JP4627777B2 - データに関数を適用した結果に対する構造化インデックス - Google Patents

Description

本発明は、一般に、情報の記憶および引出しの分野に関し、より詳細には、記憶したデータを効率よく検索することに関する。

本出願は、２００４年３月８日出願の米国特許仮出願第１０／７９５６２３号明細書の優先権を主張する。この開示全体を参照により本明細書に組み込む。

消費者は、自分のコンピュータを主に個人の情報を、それが従来のＰＩＭ（個人情報マネジャー）様式のデータであるか、デジタル音楽などの媒体、または写真であるかにかかわらず、通信し整理するために使用する。デジタルコンテンツの量および未処理バイトを記憶する能力は、著しく増大しているが、これらのデータを整理し統合するために消費者に利用可能な方法は、それに追いついていない。知識労働者は、情報を管理し共有するのに多大な時間を費やしており、ある研究の推定では、知識労働者は、非生産的な情報関連活動に自分たちの時間の１５〜２５％を費やしている。他の研究では、典型的な知識労働者は、一日当たり約２．５時間を情報検索に費やしていると推定している。

コンピュータシステム内の情報を整理する従来の手法は、ファイル−フォルダ−ディレクトリベースのシステム（「ファイルシステム」）を使用して、ファイルを記憶するのに使用する記憶媒体の物理的な編成の抽象化に基づく、複数のフォルダからなるディレクトリ階層にファイルを整理することが中心であった。１９６０年代に開発されたマルティックス（Ｍｕｌｔｉｃｓ）オペレーティングシステムは、ファイル、フォルダ、およびディレクトリを使用して、オペレーティングシステムレベルで記憶可能な単位のデータを管理する先駆的な役割を果たした。具体的には、マルティックスは、ファイル階層内で、ユーザ（アプリケーションおよびエンドユーザ）にはファイルの物理アドレスが見えない記号アドレスを使用した（それによって、ファイルのパスの考え方を導入した）。このファイルシステムでは、個々のファイルのファイルフォーマットに全く関知せず、各ファイルの関係は（すなわち、階層内でのファイルの場所以外は）、オペレーティングシステムレベルでは関連しないものとみなした。マルティックスが登場してからは、記憶可能なデータは、オペレーティングシステムレベルでは、ファイル、フォルダ、およびディレクトリ内に整理されてきた。これらのファイルは一般に、ファイルシステムによって保持される特別なファイル内で実施されるファイル階層自体（「ディレクトリ」）を含む。このディレクトリは、ディレクトリ内の他のすべてのファイルに対応するエントリおよび階層内でのこのようなファイルのノード位置（本明細書では、フォルダと称する）のリストを保持する。これが約４０年間の当技術分野の状況であった。

ファイルシステムは、コンピュータの物理的な記憶システムに存在する情報の合理的な表現を提供するが、この物理的な記憶システムの抽象化であり、したがって、これらのファイルを利用するには、ユーザが操作するものと（コンテキストを有する単位、特徴、および他の単位との関係）、オペレーティングシステムが提供するもの（ファイル、フォルダ、ディレクトリ）の間であるレベルの間接処理（解釈）が必要とされる。その結果、ユーザ（アプリケーションおよび／またはエンドユーザ）は、たとえ、非効率であり、一貫性がなく、その他の点でも望ましくないときでさえ、情報の単位をファイルシステム構造にすることを余儀なくされる。既存のほとんどのファイルシステムは、ファイルおよびフォルダを整理するのにネストしたフォルダメタファ（ｍｅｔａｐｈｏｒ）を利用するので、ファイルの数が増えると、柔軟で効率のよい整理方式を維持するのに必要な労力は極めて困難なものになる。

ファイルシステムの欠点に対処する以前になされたいくつかの試みはうまくいかなかった。これらの以前の試みの一部は、物理アドレスではなく、内容によってデータにアクセスし得るメカニズムを提供するために、内容によりアドレス可能なメモリを使用することに関係するものである。しかし、内容によりアドレス可能なメモリは、キャッシュおよびメモリ管理ユニットなどの装置による小規模な使用には有用であることがわかったが、物理的な記憶媒体などの装置での大規模な使用が、様々な理由から可能ではないことから、このような努力はうまくいかないことがわかり、そのため、このような解決策は全く存在しない。ＯＯＤＢ（オブジェクト指向型データベース）システムを利用した他の試みがなされたが、これらの試みは、データベースの性格を強く帯び、ファイルによらない表現というよい点を特徴としながら、ファイルの表現の扱いの点で有効ではなく、ハードウエア／ソフトウエアインターフェースシステムレベルで、ファイル−フォルダベースの階層構造のスピード、効率、および簡便さを踏襲することができなかった。

（以下でさらに説明する）「ＷｉｎＦＳ」などの新たに開発された記憶システムは、データベース内の１つ（または複数）のテーブルとして、複数のファイルからなるディレクトリを記憶する。各ファイルは、ベーステーブル内では行によって表現され、「ディレクトリ内のすべてのファイルを列挙せよ」などのファイルシステム操作は、データベースエンジンに対するクエリを使用して実施される。そのため、記憶部に対する基本的な動作を効率よく実施することが、データベースのクエリを効率よく最適化する動作になる。

このような記憶システムでは、ファイルの概念は、「オブジェクト」の概念に拡張される。ファイルについてのメタデータは、（記憶システム内で定義される）スキーマとともに、管理されたＣＬＲ（共通言語ランタイム）オブジェクト内に記憶され、それによって、このオブジェクトについての許容可能な記述データが表現される。例えば、写真は、その解像力、撮影された時間、および場所の情報などのデータを格納する典型的なＣＬＲオブジェクトを有することになる。このオブジェクトモデルは、データの継承をサポートする。データの継承により、別のデータから型を受け継ぎ、新しいフィールドを追加することが可能である。例えば、「運転免許証写真（ＤｒｉｖｅｒｓＬｉｃｅｎｓｅＰｉｃｔｕｒｅ）」などのサブクラスの写真を生成し得るはずである。このようなサブクラスは、運転免許証ＩＤフィールドなどの追加の情報を含むことになる。

これらの新たに開発された、ＷｉｎＦＳなどの記憶システムでは、提示されたスキーマは、翻訳層を介してテーブルにマッピングされる。ユーザは、ベーステーブルに対して操作を行う代わりに、データの一連のビューを見るだけである。このマッピングを厳密に設計することは重要ではないが、このマッピングは、ＷｉｎＦＳ ＡＰＩと、基礎となる記憶フォーマットとをつなぐ働きをする。ユーザは、このマッピングを直接制御せず、また見ることもない。

ＷｉｎＦＳ Ｓｔｏｒｅでは、以前の従来型ファイルシステムの場合のようにオブジェクトのファイル名ではなく、オブジェクトの型に基づいて、オブジェクトに対してクエリを行う概念も提示する。型ベースのクエリは、厳密な型、または所与の型から派生した任意の型を検索することができる。この後者の形態を階層マッチングと呼び、共通のＷｉｎＦＳ操作になると予想される。ＷｉｎＦＳは、ファイルによる検索もサポートする。

ＷｉｎＦＳのスキーマモデルにより、クエリプロセッサにいくつかの新しい挑戦課題が提起される。ユーザ定義型すなわちＵＤＴが広範囲に使用され、ＵＤＴの型に基づいてテーブルからあらゆるＵＤＴを引き出すことが一般的になる。さらに、ＷｉｎＦＳでは、ＵＤＴ継承を用い、テーブルから所与の型だけでなく、任意のサブタイプの要素もすべて引き出すことも要件になる。複数のテーブルが存在し、各テーブルに含まれるＵＤＴ、型、型のトポロジー、そのトポロジー内でのＵＤＴ分布の数は異なる。さらに、検索操作は、例えば、ＸＭＬ文書の検索、あるいはオブジェクト内のすべてのフィールドに対する検索の実施を含めて、従来方式のリレーショナルデータベースシステムでは見られない動作になり得る。これらの特性により、濃度およびコストの推定を正確に行うことが難しくなり、また、型／サブタイプの階層に基づいて値を効率よく引き出すことも難しくなる。

１０年もの間、データベースの研究の主題は、（本明細書では、インデックス付きビューとも称する）実体化ビューであった。基本的な考え方は、なんらかのクエリの結果を実体化し、また記憶し、次いで、類似のクエリがデータベースに提示されたときに、このような計算結果を用いることである。例えば、一日当たりの売上の結果を記憶し、例えばその後、その結果（この実体化ビュー）を用いて、所与の月の売上高または年間総売上高などのいくつかの関連するクエリに回答することが望ましいことがある。

追加の柔軟性については、アプリケーションが、ある種のビューが存在すること、あるいは実体化されたことを認識する必要がないようにすべきである。クエリプロセッサは、ユーザのクエリと、既存のあらかじめ計算された結果（実体化ビュー）との一致を識別し、該当するときにはこの結果を用いるべきである。これは、ビュー活用問題として知られている。すなわち、ベーステーブルに関して記述されたユーザのクエリと、実体化ビューの集合とが与えられる場合、どの実体化ビューを用いてこのようなクエリに回答し得るかという問題である。そして、この質問のコストに基づく変形は、それらの実体化ビューのどれを用いるべきかである。

実体化ビューは、それをデータベースの物理的な設計の一部とすべきであり、かつその主な目的は性能を向上させることであるという点でインデックスに類似している。データベースの論理設計およびアプリケーションの正確さは、実体化ビューの存在の有無に無関係とすべきである。インデックスの場合と同様に、実体化ビューにより、クエリの性能を著しく向上させることができる。

クエリオプティマイザは通常、図１に示すように、初期簡略化段階の後で、代替手段を探索し、コストに基づいて実行プランを選択するように構築される。

簡略化／正規化段階２の間、可能な場合には、選択をプッシュダウン（ｐｕｓｈ ｄｏｗｎ）する、また、サブクエリを結合として書き直すなど、元のクエリＱになんらかの変更が加えられる。これらの改変は、「よりよい」クエリを得ることを目標としている。一般にこの段階では、詳細なコストの推定は行われず、結果として単一の「よりよい」クエリＱ’が生成される。

最適化における第２段階５（探索およびコストに基づく選択）は、複数の代替手段を生成し、詳細なコストモデルを用いて、予想実行コストが最も安価な代替手段を選択することを対象とする。探索段階で用いる２つの従来方式アーキテクチャは、ボトムアップ動的プログラミング結合列挙法および代替手段の変換駆動生成法である。よく知られているように、いずれのアーキテクチャも、クエリの副表現ごとの様々な可能性を簡潔に符号化する代替手段のテーブルを準備する。

探索中に実体化ビューを考慮することは、このような実体化ビューを用いるエントリによって代替手段のテーブルを増大させることを含む。元のクエリを、テーブルＡ、Ｂ、Ｃに対する結合と仮定する。以下に、（論理演算子のみによる）典型的な代替手段を示す。

符号化された演算子ツリーは、ルートエントリ（上記のクエリではＡＢＣ）から開始して代替手段のテーブルを横に進み、各エントリから演算子を選択することによって得られる。例えば、各エントリの第１選択肢をとることによって、図２に示す演算子ツリー１０が得られる。

次に、実体化ビュー

があると仮定する。これは、ＡとＢの結合の結果を含むＶｔと称する記憶されたテーブルがあることを意味する。これは、結合の副表現を得る有効な方法なので、代替手段は、この代替手段によって増え、以下のようになる。

図３に、オプティマイザによって生成され、かつ考慮され得る有効な演算子ツリー１３を示す。

代替手段のテーブルを増大させるメカニズムは、オプティマイザのアーキテクチャによって決まる。変換ベースのオプティマイザの場合、システムに新しい変換ルールを追加することによって拡張部が得られる。ボトムアップ結合列挙法では、構築手順を変更すべきである。代替手段がテーブルに追加された後で、コストを推定し、高価な解決策を取り除き、演算子ツリーを組み立て、最適な解決策を構築する通常のオプティマイザメカニズムを適用する。

処理の正確さを保証するために、実体化ビューの内容は、ベーステーブルの変更に関して常に同期していなければならない。例えば、注文が入力または改変されたときに、１週間当たりの売上高の実体化を更新して、変更を反映させなければならない。これは、ビュー保守問題として知られている。すなわち、ベーステーブル内の基礎となるデータが変化した場合、この変更を実体化ビューに加えなければならない。このような変更を反映するために、実体化ビュー全体を計算し直す必要がないことが望ましい。というのは、再計算には時間およびコストがかかるからである。

既存のデータ記憶およびデータベースの技術における上記の欠点に鑑みて、実体化ビューを効率よく使用することが求められている。本発明は、これらの要求を満足するものである。

以下の概要では、本発明の様々な態様を概観する。本発明の重要な態様をすべて網羅的に説明することを意図しておらず、また、本発明の範囲を規定するためのものでもない。そうではなくて、この概要は、以下の詳細な説明および図の導入部分として役立てるためのものである。

本発明は、ベーステーブルに対する潜在的に多値属性を備えた２次インデックスとして、（本明細書では、インデックス付きビューとも称する）実体化ビューを使用することを対象とする。こうすると、このインデックスを使用して、データに関数を適用した結果に関して検索が行われる。さらに、本発明では、テーブル値関数呼出しの結果に対してインデックス処理を行う。このような関数呼出しの結果に対してビューをインデックス化すると、複雑な構造の内容をインデックス化することができる。

アンネスト（ｕｎｎｅｓｔ）操作の例は、「ｃｒｏｓｓ ａｐｐｌｙ ｕｎｎｅｓｔ」である。この例では、ＵＮＮＥＳＴは、複雑な構造としてＵＤＴ集合を取得する関数であり、この集合の各要素ごとに行を出力する。他の関数の例は、ＸＭＬデータをより検索可能な形態に変換するか、あるいは、複数の列を単一のインデックス構造に分解して特別な検索を行い得るはずである。本発明では、クエリ実行プランについての追加の選択肢が提供され、それによってより最適化されたクエリが得られる。

本発明の別の態様によれば、インデックス付きビューからベーステーブルへの逆結合が行われる。これにより、インデックス付きビューに存在しないベーステーブルからのフィールドを、アクセスパスとしてインデックス付きビューを用いて処理した、このテーブルに対するクエリの結果に含めることができる。こうすると、インデックス付きビューにはないが、ベーステーブルにはある列をクエリの結果に含める手段が得られる。この逆結合は、論理行ロケータとして働く一意のクラスタリングキーによって、単一テーブルインデックス付きビューからベーステーブルまでサポートされる。そのため、この一意のクラスタリングキーによって、インデックス付きビューからベーステーブルに、システムが逆結合を行うことができる。これらの特徴により、インデックス付きビューを用いて複雑な関数の呼出しの内容に関してテーブルをインデックス化し、この関数呼出しに関する基準と一致する行からデータを効率よく引き出すことができる。

本発明の他の特徴および利点は、本発明の以下の詳細な説明および添付の図面から明らかになるであろう。

上記の概要ならびに好ましい実施形態の以下の詳細な説明は、添付の図面を併せ読めばよりよく理解されよう。本発明を説明するために、これらの図面に本発明の構造の例を示すが、本発明は、ここで開示する特定の方法および手段に限定されるものではない。

法的な要件が満足されるように具体的に主題を説明する。ただし、この説明自体は、本特許の範囲を限定するためのものではない。そうではなくて、本発明者らは、現在または将来の他の技術とともに、異なるステップまたは本明細書で説明するものに類似のステップの組合せを含む他のやり方で、特許請求する主題を実施することもできることを企図している。さらに、本明細書では、ここで採用する方法の異なる要素を結合するために「ステップ」という用語を用いるが、この用語を、個々のステップの順序を明示的に記載しない限り、本発明で開示する様々なステップ間の特定の順序を示唆すると解釈すべきではない。

ＷｉｎＦＳは、ファイルシステムにおけるオブジェクトの概念を導入するファイルシステム／データ記憶部である。この記憶部における操作の１つは、オブジェクトを効率よく見つけ出し、そのオブジェクトに対するクエリを可能にすることである。本発明では、この操作の態様を極めて効率のよいものにし得る方法を説明する。

コンピューティング環境の例
本明細書および特許請求の範囲では、以下の用語は下記に示す意味を有する。

「オブジェクト」は、１組の基本的なプロパティを有し、ハードウエア／ソフトウエアインターフェースシステムがアクセスし得る記憶可能な情報の単位である。これらのプロパティは、このハードウエア／ソフトウエアインターフェースシステムのシェルによってエンドユーザに提示されるすべてのオブジェクトにわたって共通にサポートされるものである。オブジェクトは、新しいプロパティおよびリレーションシップを導入し得るフィーチャを含めて、あらゆる型にわたって共通にサポートされるプロパティおよびリレーションシップも有する。

「オペレーティングシステム」（ＯＳ）は、アプリケーションプログラムとコンピュータハードウエアを仲介する働きをする特別なプログラムである。オペレーティングシステムは、ほとんどの場合、シェルおよびカーネルを有する。

「ハードウエア／ソフトウエアインターフェースシステム」は、コンピュータシステムの基礎となるハードウエアコンポーネントと、このコンピュータシステム上で実行されるアプリケーションとの間のインターフェースとして働くソフトウエア、またはハードウエアとソフトウエアの組合せである。ハードウエア／ソフトウエアインターフェースシステムは一般に、オペレーティングシステムを含む（ある種の実施形態では、オペレーティングシステムのみからなることがある）。ハードウエア／ソフトウエアインターフェースシステムは、コンピュータシステム内のオペレーティングシステムの代わりに、あるいはそれに加えて、ＶＭＭ（仮想マシンマネジャー）、ＣＬＲ（共通言語ランタイム）またはその機能的な均等物、ＪＶＭ（Ｊａｖａ（登録商標）仮想マシン）またはその機能的な均等物、または他のこのようなソフトウエアコンポーネントも含み得る。ハードウエア／ソフトウエアインターフェースシステムの目的は、ユーザがアプリケーションプログラムを実行し得る環境を提供することである。ハードウエア／ソフトウエアインターフェースシステムの目標は、コンピュータシステムを使い易くし、コンピュータハードウエアを効率的に利用することである。

本発明の多くの実施形態は、コンピュータ上で実行し得るものである。図４および以下の考察は、本発明を実施し得る適切なコンピューティング環境を簡単かつ全体的に説明するためのものである。必要条件ではないが、本発明は、クライアントワークステーションまたはサーバなどのコンピュータによって実行される、プログラムモジュールなどのコンピュータが実行可能な命令の一般の状況において説明する。一般に、プログラムモジュールは、特定のタスクを実施し、また特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラム可能な民生用電子機器、ネットワークＰＣ、ミニコンピュータ、大型コンピュータなどを含めて、他のコンピュータシステム構成で本発明を実施し得ることが当業者には理解されよう。本発明は、通信ネットワークを介して接続された遠隔処理装置によってタスクが実施される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、ローカルおよびリモートのコンピュータ記憶装置に配置することができる。

図４に示すように、汎用コンピューティングシステムの例は、処理装置２１、システムメモリ２２、およびシステムメモリを含めて様々なシステムコンポーネントを処理装置２１に接続するシステムバス２３を備えた従来型パーソナルコンピュータ２０などを含む。システムバス２３は、メモリバスまたはメモリコントローラ、ペリフェラルバス、およびローカルバスを含めて、様々なバスアーキテクチャのいずれかを利用するいくつかのタイプのバス構造のいずれかとし得る。システムメモリは、ＲＯＭ（読出し専用メモリ）２４およびＲＡＭ（ランダムアクセスメモリ）２５を含む。例えば起動時に、パーソナルコンピュータ２０内の要素間で情報を転送する助けとなる基本ルーチンを含むＢＩＯＳ（基本入出力システム）２６は一般に、ＲＯＭ２４内に格納される。

パーソナルコンピュータ２０は、図示しないハードディスクに対して読書きを行うハードディスクドライブ２７、リムーバブル磁気ディスク２９に対して読書きを行う磁気ディスクドライブ２８、およびＣＤ−ＲＯＭその他の光メディアなどのリムーバブル光ディスク３１に対して読書きを行う光ディスクドライブ３０をさらに含み得る。ハードディスクドライブ２７、磁気ディスクドライブ２８、および光ディスクドライブ３０はそれぞれ、ハードディスクドライブインターフェース３２、磁気ディスクドライブインターフェース３３、および光ドライブインターフェース３４によってシステムバス２３に接続される。これらのドライブおよびそれらに関連するコンピュータ可読メディアは、パーソナルコンピュータ２０用のコンピュータ可読命令、データ構造、プログラムモジュールその他のデータの不揮発性記憶装置を提供する。

本明細書で説明する環境の例は、ハードディスク、リムーバブル磁気ディスク２９、およびリムーバブル光ディスク３１を採用するが、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイ（Ｂｅｒｎｏｕｌｌｉ）カートリッジ、ＲＡＭ（ランダムアクセスメモリ）、ＲＯＭ（読出し専用メモリ）など、コンピュータがアクセス可能なデータを記憶し得る他のタイプのコンピュータ可読メディアもこの動作環境の例で使用し得ることが当業者には理解されよう。

オペレーティングシステム３５、１つまたは複数のアプリケーションプログラム３６、他のプログラムモジュール３７、およびプログラムデータ３８を含めて、いくつかのプログラムモジュールを、ハードディスク、磁気ディスク２９、光ディスク３１、ＲＯＭ２４、またはＲＡＭ２５に記憶することができる。ユーザは、キーボード４０およびポインティングデバイス４２などの入力装置を介してパーソナルコンピュータ２０にコマンドおよび情報を入力することができる。（図示しない）他の入力装置は、マイクロホン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどを含み得る。上記その他の入力装置は、システムバスに結合されたシリアルポートインターフェース４６を介して処理装置２１に接続されることが多いが、パラレルポート、ゲームポート、またはＵＳＢ（ユニバーサルシリアルバス）など他のインターフェースによって接続することもできる。モニタ４７その他のタイプの表示装置も、ビデオアダプタ４８などのインターフェースを介してシステムバス２３に接続される。モニタ４７に加えて、パーソナルコンピュータは一般に、スピーカおよびプリンタなど（図示しない）他の周辺出力装置も含む。図４のシステムの例は、ホストアダプタ５５、ＳＣＳＩ（小型コンピュータシステムインターフェース）バス５６、およびＳＣＳＩバス５６に接続された外部記憶装置６２も含む。

パーソナルコンピュータ２０は、リモートコンピュータ４９など、１つまたは複数のリモートコンピュータへの論理接続部を使用するネットワーク環境で動作し得る。リモートコンピュータ４９は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス（ｐｅｅｒ ｄｅｖｉｃｅ）その他一般のネットワークノードとすることができ、一般に、パーソナルコンピュータ２０に関連して上記で説明した要素の多くまたはすべてを含むが、図４にはメモリ記憶装置５０のみを示す。図４に示す論理接続部は、ＬＡＮ（ローカルエリアネットワーク）５１およびＷＡＮ（ワイドエリアネットワーク）５２を含む。このようなネットワーク環境は、一般事務所、企業規模のコンピュータネットワーク、イントラネット、およびインターネットで一般的なものである。

ＬＡＮネットワーク環境で用いられるとき、パーソナルコンピュータ２０は、ネットワークインターフェースまたはアダプタ５３を介してＬＡＮ５１に接続される。ＷＡＮネットワーク環境で用いられるとき、パーソナルコンピュータ２０は一般に、インターネットなどのワイドエリアネットワーク５２を介して通信を確立するためのモデム５４その他の手段を含む。内蔵型または外付けとし得るモデム５４は、シリアルポートインターフェース４６を介してシステムバス２３に接続される。ネットワーク環境では、パーソナルコンピュータ２０に関連して示すプログラムモジュールまたはその一部は、リモートメモリ記憶装置に格納することができる。図に示すネットワーク接続部は例であり、コンピュータ間で通信リンクを確立する他の手段を使用し得ることを理解されたい。

本発明の多くの実施形態が、コンピュータ化したシステムに特によく適していることが考えられ、本明細書では、このような実施形態に本発明を限定することを意図していない。そうではなくて、本明細書では「コンピュータシステム」という用語は、本質的に電子装置、機械装置、論理装置、または仮想装置のいずれであるかにかかわらず、押しボタンを備えた、あるいは、ボタンが押されること、またはボタンが押されるのと同等のことを判定し得る任意のあらゆる装置を包含するためのものである。

図５のブロック図に示すように、コンピュータシステム２００は、ハードウエアコンポーネント２０２、オペレーティングシステムコンポーネント２０４、およびアプリケーションプログラムコンポーネント２０６という大雑把に３つのコンポーネント群に分割し得る。

あるコンピュータシステム２００では、図４を再度参照すると、ハードウエア２０２は、ＣＰＵ（中央処理装置）２１と、メモリ（ＲＯＭ２４およびＲＡＭ２５）と、ＢＩＯＳ（基本入出力システム）２６と、とりわけキーボード４０、マウス４２、モニタ４７、および／または（図示しない）プリンタなどの様々なＩ／Ｏ（入出力）装置とを含み得る。ハードウエアコンポーネント２０２は、コンピュータシステム２００用の基本リソースを含む。

アプリケーションプログラムコンポーネント２０６は、コンパイラ、データベースシステム、ワードプロセッサ、業務用プログラム、ビデオゲームなどを含めて、様々なソフトウエアプログラムを含むが、これらに限定されるものではない。アプリケーションプログラムは、コンピュータのリソースを使用して、問題を解決し、解決策を提供し、様々なユーザ（例えば、機械その他のコンピュータシステム、および／またはエンドユーザ）のデータを処理する手段を提供する。

オペレーティングシステムコンポーネント２０４は、オペレーティングシステム自体ならびにそのシェルおよびカーネルを含む。ＯＳ（オペレーティングシステム）は、アプリケーションプログラムとコンピュータハードウエアを仲介する働きをする特別なプログラムであり、オペレーティングシステムの目的は、ユーザがアプリケーションプログラムを実行し得る環境を提供することである。オペレーティングシステムの目標は、コンピュータシステムを使い易くし、コンピュータハードウエアを効率的に利用することである。

オペレーティングシステムは一般に、起動時にコンピュータシステム内にロードされ、その後で、このコンピュータシステム内のすべてのアプリケーションプログラム（または単に「アプリケーション」）を管理する。これらのアプリケーションプログラムは、ＡＰＩ（アプリケーションプログラムインターフェース）を介してサービスを要求することによって、オペレーティングシステムと対話する。いくつかのアプリケーションプログラムにより、エンドユーザは、コマンド言語またはＧＵＩ（グラフィカルユーザインターフェース）などのユーザインターフェースを介してオペレーティングシステムと対話することができる。

従来、オペレーティングシステムは、アプリケーション用の様々なサービスを実施する。複数のプログラムが同時に実行されることがあるマルチタスクオペレーティングシステムでは、オペレーティングシステムは、どのアプリケーションをどんな順序で実行すべきか、また、各アプリケーションには、別のアプリケーションに番を切り換える前にどのくらいの時間を許容すべきかを決定する。オペレーティングシステムは、複数のアプリケーション間で内部メモリの共有も管理し、ハードディスク、プリンタ、およびダイヤルアップポートなど、取り付けられたハードウエア装置に対する入出力も処理する。オペレーティングシステムは、動作状態および発生したエラーに関して、各アプリケーションに（ある種の場合には、エンドユーザに）メッセージも送信する。オペレーティングシステムは、バッチジョブ（例えば、印刷）の管理を肩代わりすることもでき、それによって、それを開始したアプリケーションはその作業から解放され、他の処理および／または動作を再開することができる。並列処理を実現し得るコンピュータ上では、オペレーティングシステムは、プログラムが一度に２つ以上のプロセッサ上で実行されるように、そのプログラムを分割することも管理する。

オペレーティングシステムのシェルは、オペレーティングシステムとの（「コマンドインタプリタ」としても知られる）対話式エンドユーザインターフェースである。シェルは、アプリケーションプログラムが直接アクセス可能な、かつエンドユーザさえも直接アクセス可能なオペレーティングシステムの外側の層である。シェルとは異なり、カーネルは、ハードウエアコンポーネントと直接対話する、オペレーティングシステムの最も内側の層である。

当業者にはよく理解されるように、「ファイル」は、オペレーティングシステムが離散的な（記憶可能かつ引出し可能な）実体として操作し得る（オペレーティングシステム自体ならびにアプリケーションプログラム、データセットなどが含まれるが、これらに限定されるものではない）情報の実体である。最新のオペレーティングシステム（Ｗｉｎｄｏｗｓ（登録商標）、Ｕｎｉｘ（登録商標）、Ｌｉｎｕｘ、Ｍａｃ ＯＳなど）では、ファイルは、オペレーティングシステムによって操作される記憶可能な情報（例えば、データ、プログラムなど）の基本的な単位であり、ファイル群は「フォルダ」内に整理される。Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ｍａｃｉｎｔｏｓｈその他のオペレーティングシステムでは、フォルダは、１つの実体として引き出し、移動させ、その他の方法で操作し得るファイルの集合である。ＤＯＳ、ｚ／ＯＳ、およびほとんどのＵｎｉｘ（登録商標）ベースのオペレーティングシステムなど、ある種の他のオペレーティングシステムでは、フォルダではなく「ディレクトリ」という用語を用いる。初期のＡｐｐｌｅコンピュータシステム（例えば、Ａｐｐｌｅ ＩＩｅ）では、「カタログ」という用語を用いた。ただし、本明細書では、これらの用語はすべて同義語であり、交換可能である。本発明では、これらの用語は、階層的な情報記憶構造に関する他のあらゆる等価な用語および言及をさらに含むためのものである。

当業者には周知であり、理解されているように、ディレクトリ（すなわち、複数のフォルダからなるディレクトリ）は、ツリーに基づく階層構造である。ファイルは、このツリー構造のノードであるフォルダ内の場所に基づいてグループ分けされる。例えば、図６に示すように、ＤＯＳベースのファイルシステムの基本フォルダ（または「ルートディレクトリ」）３０２は、複数のフォルダ３０４を含み、各フォルダ３０４はさらに、（その特定のフォルダの「サブフォルダ」として）追加のフォルダ３０６を含み得る。これらのフォルダ３０６もそれぞれ、追加のフォルダ３０８を含み得る。これが限りなく続く。これらのフォルダはそれぞれ、１つまたは複数のファイル３１０を含み得るが、オペレーティングシステムレベルでは、フォルダ内の個々のファイルには、このツリー階層内のこれらのファイルの場所以外に何も共通点がない。当然のことながら、ファイルをフォルダ階層に整理するこの手法は、これらのファイルを記憶するのに使用する典型的な記憶メディア（例えば、ハードディスク、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭなど）の物理的な編成を間接的に反映している。

上記に加えて、各フォルダは、そのサブフォルダおよびそのファイルの入れ物である。すなわち、これらのサブフォルダおよびファイルはこのフォルダに属している。例えば、オペレーティングシステムによってフォルダが消去されると、そのサブフォルダおよびファイルも消去される（これらのサブフォルダはそれぞれ、さらにそれ自体のサブフォルダおよびファイルを含む）。同様に、各ファイルは、１つのフォルダにしか属することができず、ファイルをコピーし、そのコピーを異なるフォルダ内に置くことができるが、ファイルのコピー自体は、元のファイルとは直接関連しない明確に別の実体である（例えば、オペレーティングシステムレベルでは、元のファイルに変更を加えても、それはコピーファイルに反映されない）。この点に関して、ファイルおよびフォルダはしたがって、特質上本質的に「物理的」なものである。というのは、フォルダは、物理的な入れ物の概念上の均等物であり、ファイルは、入れ物の中にある離散的かつ別個の物理的な要素の概念上の均等物だからである。

本発明とともに使用し得る、データを整理し、検索し、共有する記憶プラットホームは、オブジェクトと呼ぶデータの形態を含めて、あらゆるタイプのデータの記憶部となるように設計される。図７を参照すると、本発明による記憶プラットホーム４００は、データベースエンジン４１４上で実施されるデータ記憶部４０２を備える。一実施形態では、このデータベースエンジンは、オブジェクトリレーショナル拡張子を伴うリレーショナルデータベースエンジンを備える。一実施形態では、リレーショナルデータベースエンジン４１４は、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒリレーショナルデータベースエンジンを含む。

データ記憶部４０２は、データの整理、検索、共有、同期、およびセキュリティをサポートするデータモデル４０４を実施する。データの特定の型は、スキーマ４４０などのスキーマに記述する。記憶プラットホーム４００は、これらのスキーマを配備するだけでなく、これらのスキーマを拡張するツール４４６を提供する。

データ記憶部４０２内で実施される変更追跡メカニズム４０６により、データ記憶部に加えられた変更を追跡することができる。データ記憶部４０２は、セキュリティ機能４０８およびプロモーション／デモーション（ｐｒｏｍｏｔｉｏｎ／ｄｅｍｏｔｉｏｎ）機能４１０も提供する。データ記憶部４０２は、データ記憶部４０２の機能を、他の記憶プラットホームコンポーネントおよびこの記憶プラットホームを使用するアプリケーションプログラム（例えば、アプリケーションプログラム４５０ａ、４５０ｂ、および４５０ｃ）に提示する１組のアプリケーションプログラミングインターフェース４１２も提供する。

本発明の記憶プラットホームはさらに、ＡＰＩ（アプリケーションプログラミングインターフェース）４２２を含む。ＡＰＩ４２２により、アプリケーションプログラム４５０ａ、４５０ｂ、および４５０ｃなどのアプリケーションプログラムが、記憶プラットホームの上記すべての機能にアクセスし、スキーマに記述されたデータにアクセスすることができる。記憶プラットホームＡＰＩ４２２は、ＯＬＥ ＤＢ ＡＰＩ４２４およびＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）Ｗｉｎ３２ ＡＰＩ４２６などの他のＡＰＩと組み合わせてアプリケーションプログラムが使用し得る。

本発明の記憶プラットホーム４００は、ユーザ間またはシステム間でのデータの共有を容易にする同期サービス４３０を含めて、アプリケーションプログラムに様々なサービス４２８を提供し得る。例えば、同期サービス４３０により、データ記憶部４０２と同じフォーマットを有する他のデータ記憶部４４０との相互運用、ならびに他のフォーマットを有するデータ記憶部４４２へのアクセスが可能になる。記憶プラットホーム４００は、Ｗｉｎｄｏｗｓ（登録商標）ＮＴＦＳファイルシステム４１８などの既存のファイルシステムとデータ記憶部４０２の相互運用を可能にするファイルシステム機能も提供する。

少なくともいくつかの実施形態では、記憶プラットホーム４２０は、データを他のシステムに作用させ、これらの他のシステムと対話し得る追加の機能を含むアプリケーションプログラムも提供する。これらの機能は、Ｉｎｆｏ Ａｇｅｎｔサービス４３４および通知サービス４３２などの追加のサービス４２８の形態、ならびに他のユーティリティ４３６の形態で実施し得る。

少なくともいくつかの実施形態では、記憶プラットホームは、コンピュータシステムのハードウエア／ソフトウエアインターフェースシステムにおいて実施されるか、あるいはその一体部分を形成する。例えば、本発明の記憶プラットホームは、オペレーティングシステム、ＶＭＭ（仮想マシンマネジャー）、ＣＬＲ（共通言語ランタイム）またはその機能的な均等物、あるいはＪＶＭ（Ｊａｖａ（登録商標）仮想マシン）またはその機能的な均等物において実施されるか、あるいはその一体部分を形成するが、これらに限定されるものではない。

本発明の記憶プラットホームにより、その共通の記憶基盤およびスキーマ化されたデータを介して、消費者、知識労働者、および企業のより効率的なアプリケーションの開発が可能になる。この記憶プラットホームは、そのデータモデルに固有な機能を利用可能にするだけでなく、既存のファイルシステムおよびデータベースアクセスの方法を包含し拡張する豊富で拡張可能なプログラミングの範囲を提供する。

本明細書の説明および様々な図において、本発明の記憶プラットホーム４００は、「ＷｉｎＦＳ」と称することができる。ただし、記憶プラットホームを指すのにこの名前を用いることは、単に説明の都合であり、いかなる形でも限定することを意図するものではない。

本発明の記憶プラットホーム４００のデータ記憶部４０２は、この記憶部内に存在するデータの整理、検索、共有、同期、およびセキュリティをサポートするデータモデルを実施する。本発明のデータモデルでは、「オブジェクト」は、記憶情報の基本単位である。このデータモデルは、オブジェクトおよびオブジェクトの拡張子を宣言し、オブジェクト間のリレーションシップを確立し、オブジェクトを整理し分類するメカニズムを提供する。

一実施形態ではＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒエンジンを含むリレーショナルデータベースエンジン４１４は、組込みスカラー型をサポートする。組込みスカラー型は、「固有」かつ「簡単」である。これらは、ユーザがこれら自体の型を定義し得ないという点で固有であり、これらが、複雑な構造をカプセル化できないという点で簡単である。「ＵＤＴ」（ユーザ定義型）は、複雑な構造化型を定義することによりユーザが型システムを拡張し得るようにすることによって、固有なスカラー型システムの先まで型を拡張し得るメカニズムを提供する。ユーザによって定義された後で、組込みスカラー型を使用し得る型システムのどこでもＵＤＴを使用することができる。

記憶プラットホームのスキーマは、データベースエンジン記憶部内でＵＤＴクラスにマッピングされる。データ記憶部のオブジェクトは、Ｂａｓｅ．Ｉｔｅｍ型から派生するＵＤＴクラスにマッピングされる。拡張子も、ＵＤＴクラスにマッピングされ、継承を利用する。ルート拡張子型は、Ｂａｓｅ．Ｅｘｔｅｎｓｉｏｎであり、これからすべての拡張子型が派生する。

ＵＤＴは、状態（すなわち、データフィールド）および挙動（すなわち、ルーチン）を有するＣＬＲクラスである。ＵＤＴは、Ｃ＃、ＶＢ．ＮＥＴなどのマネージ言語のいずれかを用いて定義される。ＵＤＴメソッドおよび演算子は、この型のインスタンスに対して、Ｔ−ＳＱＬ内で呼び出すことができる。ＵＤＴは、例えば、行内の列の型、Ｔ−ＳＱＬ内のルーチンのパラメータの型、またはＴ−ＳＱＬ内の変数の型とし得る。

本発明では、ベーステーブルとして知られる（というのは、このテーブルが、ビューを定義する基礎になるからである）テーブルに対してインデックス付きビュー（すなわち、実体化ビュー）を生成し、クエリ処理を強化するのに使用し得る追加の操作および構造においてこのインデックス付きビューを使用する。このインデックス付きビューは、ベーステーブルに対するインデックスとして働く。このインデックスを、ベーステーブルへのアクセスパスとして使用して、インデックス付きビューの構造とベーステーブルとが一致するクエリを解決することができる。

典型的なインデックス付きビューは、データエントリを含み、関連するサブエントリその他の従属する、すなわち派生したデータを含み得るはずである。インデックス付きビューは、これらのデータを変換する関数呼出しの結果を含み得る。例として、インデックス付きビューは、ネストを含み得る。この場合、１つのエントリは、複数の関連するサブエントリを有する。例えば、第１ベーステーブルが名前を含み、第２ベーステーブルが住所を含むと仮定する。これら２つのベーステーブルに対する「結合」操作により、個々の名前についての住所が得られる。図８に示すインデックス付きビュー５００など、名前および関連する住所を含むインデックス付きビューを記憶することができる。インデックス付きビュー５００では、名前「Ａｌｉｃｅ」は、住所１、住所２、および住所３という関連する３つの住所を有する。インデックス付きビューの例５００の他の名前（例えば、「Ｂｏｂ」および「Ｃｈａｒｌｉｅ」）はそれぞれ、関連する１つの住所を有する。このインデックス付きビューは、名前「Ａｌｉｃｅ」に関連する複数の住所のためにネストしているとみなされる。このネストを解除し、それによって、Ａｌｉｃｅに関連する住所の１つが変更された場合、この住所に直接アクセスすることができ、この変更を反映するためにインデックス付きビューを計算し直す必要がないことが望ましい。他の関数の結果も同様にインデックス化し得るはずである。

このネストを解除するために、図９に示すように、一意のクラスタリングキー５５０を構築する。以下でさらに詳細に示し説明するように、キー５５０は、インデックス付きビューにおいてネストした各エントリごとに別々のサブエントリを提供する。そのため、この実施例におけるキー５５０は、それぞれ住所１、住所２、および住所３の住所のうち異なる１つの住所に関連する３つのエントリ「Ａｌｉｃｅ」を提供する。このキーにより、アプリケーションは、ベーステーブルとインデックス付きビューの間を行ったり来たりし得る。

インデックス付きビューは、複数値属性を伴うベーステーブルに対する２次インデックスとして扱うことができる。そのため、本発明では、インデックス付きビューを用いて、関数呼出しの結果（この実施例では、ネストになったデータなど）に関して検索を行う。インデックス処理は、（アンネスト操作などの）関数呼出しの結果に対して実施される。すなわち、派生したデータ（すなわちサブエントリ）がインデックス化される。本発明では、複雑な構造をインデックス化して、より多くのインデックス付きビューを求め、利用可能にすることができる。こうすると、クエリ実行プランについてのより多くの選択肢が提供され、それによってより最適化されたクエリが得られる。

以下でさらに説明するように、関数呼出し操作の結果に対してビューをインデックス化することにより、（ネストした集合の内容などの）データの複雑な変換をインデックス化する方法が提供される。本発明がサポートするアンネスト操作の例は、ＳＱＬ Ｓｅｒｖｅｒの「ｃｒｏｓｓ ａｐｐｌｙ ｕｎｎｅｓｔ」である。具体的には、「ｃｒｏｓｓ ａｐｐｌｙ ｕｎｎｅｓｔ」操作を行うと、インデックス付きビューにおけるネストの１つのレベルがアンネストされる。ただし、本発明によれば、任意の数のレベルをアンネストし得ることが企図されている。より一般には、このようにして関数呼出しの複数のレベルをインデックス化し得ることが企図されている。

さらに、インデックス付きビューからベーステーブルへの「逆結合」が提供される。これにより、インデックス付きビューに存在しないベーステーブルからのフィールドを、アクセスパスとしてインデックス付きビューを用いて処理した、このテーブルに対するクエリの結果に含めることができる。逆結合は、インデックス付きビューから、ビューを定義するベーステーブルまで用いられる。こうすると、インデックス付きビューにはないが、ベーステーブルにはある列をクエリの結果に含める手段が得られる。

望ましくは、逆結合は、論理行ロケータとして働く一意のクラスタリングキーによって、単一テーブルインデックス付きビューからベーステーブルまでサポートされる。この一意のクラスタリングキーによって、インデックス付きビューからベーステーブルに、システムが逆結合することができる。これらの特徴により、インデックス付きビューを用いて、複数組または複数値の属性に対する「ｃｒｏｓｓ ａｐｐｌｙ ｕｎｎｅｓｔ」操作など、データに関する関数呼出しの結果の内容に関してテーブルをインデックス化することができる。

上記で述べたように、インデックス付きビューは、（ｃｒｏｓｓ ａｐｐｌｙ ｕｎｎｅｓｔ操作などの）データに関する関数呼出しの結果に対して定義することができる。こうすると、逆結合機能と組み合わせて、テーブル内のレコードに、これらのレコードに含まれる値の集合の内容に基づいてアクセスすることができる。このように、インデックス付きビューを用いて、ＵＤＴの複数組属性に対するインデックスを生成し得る。例えば、以下のインデックス付きビューは、市（ｃｉｔｙ）に関する検索の実施を高速化する助けとなり得る。

望ましくは、ａｄｄｒＩＤおよびｐｉｄを用いて、このインデックスを一意なものにすることに留意されたい。また、ａｄｄｒＩＤは、単一の複数組住所（ａｄｄｒｅｓｓ）内では一意であると仮定する。以下の例に、このインデックス化機能によって一般の関数呼出しがどのように可能になるかを示す。

この実施例では、「ｕｎｎｅｓｔ」の代わりに、本明細書で論じた「データに関する関数呼出し」を表す「ＦＵＮＣＴＩＯＮ」を用いた。一般に、「ＦＵＮＣＴＩＯＮ」の代わりに異なる関数を使用し得るはずである。可能な例は、集合内でデータをアンネストすること、ＸＭＬ文書を分解すること、または（ＵＤＴなどの）複雑な構造からの複数のフィールドをインデックス化することである。このメカニズムは、データに関して他の関数にも利用することが可能である。

クエリに関するインデックス付きビューを用いて、ベーステーブル（例えば、「人（ｐｅｒｓｏｎ）」というベーステーブル）を読み込まずにこのクエリに回答することができる。こうすると、インデックスはベーステーブルよりもはるかに小さいことがあるので有益なことがある。例えば、「人」というベーステーブルは望ましくは、属性ｐｃｏｌを含む。属性ｐｃｏｌはＵＤＴである。ｐｃｏｌのフィールドの１つ（住所）は、複数組（集合値属性）のものである。「人」という仮定テーブルである表１を考える。

表１に、最も細かいレベルの粒度を示す。この例に本質的でない列は割愛してあり、それらを省略記号で示す。ｐｉｄおよび名前は原子性属性であり、そのため、値を１つしか含まないが、住所は集合であり、そのため、この例では２つ以上の値を含むことに留意されたい。市は、住所の各メンバのフィールドである。

「人」のテーブルでは、各名前ごとに複数の副行が示されている。例えば、Ｂｏｂは、それぞれＢｅｌｌｅｖｕｅおよびＣｏｒｖａｌｌｉｓに対応するＡｄｄｒＩＤ １およびＡｄｄｒＩＤ ２という２つの住所の副行を有し、Ｓｕｅは、それぞれＢｅｌｌｅｖｕｅおよびＢｅｒｋｅｌｅｙに対応するＡｄｄｒＩＤ ３およびＡｄｄｒＩＤ ４という２つの住所の副行を有する。

インデックス付きビューｉｖ＿ｃｉｔｙを考える。「人」のテーブルの上記の値に関して、ｉｖ＿ｃｉｔｙの内容は、表２に示すようになる。

ｉｖ＿ｃｉｔｙの各行は、最も細かいレベルの粒度のデータの形の情報に対応する。そのため、このインデックス付きビューは、各副行エントリがこの時点でそれ自体の行内にあることを示している。Ｐｉｄは、第１テーブルに戻る逆結合として用いることができることに留意されたい。例えば、ｉｖ＿ｃｉｔｙ内のＰｉｄ １は、「人」のテーブル内のＰｉｄ １に逆結合することになる。部分的なデータ（すなわち、対象とするデータのみ。例えば、Ｂｅｌｌｅｖｕｅの住人のみ）をインデックス化することが可能である。

次に、Ｃｏｒｖａｌｌｉｓに少なくとも１つの住所をもつすべての人の名前を見つけるために、以下のクエリを考える。

図１０に示す実行プランにより、ｉｖ＿ｃｉｔｙ（アンネストの結果に関するインデックス付きビュー）およびｐｅｒｓｏｎ，ｐｉｄキーに関するベーステーブル「人」への逆結合をともに用いて、上記のクエリに回答することができる。

（図１０に示すように）ｃｒｏｓｓ ａｐｐｌｙ ｕｎｎｅｓｔによるインデックス付きビューｉｖ＿ｃｉｔｙと逆結合操作の組合せにより、人のｐｃｏｌ ＵＤＴフィールド値の住所集合中の個々の住所の値に含まれる市に基づいて、「人」のテーブルの行の素早い結合ルックアップが可能になることに留意されたい。

与えられたデータの例では、左側のインデックススキャン（ｉｎｄｅｘ ｓｃａｎにより、ｉｖ＿ｃｉｔｙの１つの行（ｉｖ＿ｃｉｔｙの内容を示す上記表２の最後の行）だけが識別されることになる。ｉｖ＿ｃｉｔｙのこの行は、Ｂｏｂについての人の行と結合する。次いで、「人」のテーブルのＢｏｂの行は、その上の半結合演算子を通過する。図１０では、「ｎｅｓｔ−ｌｏｏｐ ｒｉｇｈｔ ｓｅｍｉ−ｊｏｉｎ」演算子は、逆結合演算子として働く。次いで、ｐｉｄフィールドおよびｐｃｏｌ．ｎａｍｅフィールドがｐｒｏｊｅｃｔされ、この場合も１つの行になる。重複は存在せず、そのため並べ替えおよび重複の除去により、これらのフィールドの入力ストリームは変化しない。表３に最終的な結果を示す。

より具体的には、インデックス付きビューからの逆結合に関して、インデックス付きビューＶがＮ個のベーステーブルＴ１．．．ＴＮからなる関数であると仮定する。さらに、Ｖは、ｓｅｌｅｃｔ、ｐｒｏｊｅｃｔ、ｊｏｉｎ、ｇｒｏｕｐ−ｂｙ、およびａｇｇｒｅｇａｔｉｏｎ演算子を使用するだけで構築されると仮定する。各テーブルＴ１．．．ＴＮは、そのテーブルについてのメタデータ中で識別される１つまたは複数のキーを有する。キーは、テーブルの１つまたは複数の列からなる１つの組であり、そのため、この組に含まれる値により、このテーブル内の行が一意に識別される。

Ｔ１．．．ＴＮに対して定義されたクエリＱと一致するこの組の行を、Ｖ内の行だけを用いて識別し得ると仮定する。（Ｑは、より大きなクエリの一部とし得るはずである。一般性を失わずに、Ｑを独立クエリとみなす。）Ｖに照会することによってＱの結果の行を識別し得るとしても、これは、Ｑから得られた行を、Ｖから完全に構築し得ることを意味するものではない。望ましくはＱの結果に現れるべきある種の列が、Ｔ１．．．ＴＮの１つにしか現れない場合がそうである。

インデックス付きビューＶから、このビューＶを定義するベーステーブルＴ（Ｔ１．．．ＴＮの１つ）への逆結合は、任意のキーＴに関するＶとＴの間の等結合、およびＴのこのキーから引き出されたＶ内の１つ（または複数）のフィールドとして定義される。逆結合を実施するキーは、単一列または複数列の主キー、あるいは、単一列または複数列の候補キーとし得るが、これらに限定されるものではない。キーは、インデックスを含むこともできるし、含まないこともある。キーがインデックスを含まない場合、このインデックスをクラスタ化することもできるし、しないこともある。本明細書では、ベーステーブルのクラスタリングキーに関して実施するように逆結合を説明したが、本発明は、任意の型のキーに関して逆結合し得ることを含む。

逆結合の例として、以下のＳＱＬ文を用いて定義するテーブルを考える。

以下のように、ｅｎｏに関して順序づけたクラスタ化アクセスパスを用いてベーステーブル「ｅｍｐ」が記憶されると定義する。

ｅｎｏはｅｍｐのキーである。次に、以下のように定義されたインデックス付きビューを考える。

次に、以下のクエリを考える。

インデックス付きビュー「ｈｉｇｈｐａｉｄ」を逆結合とともに使用してこのクエリを解決する方法の例として、図１１に示すアクセスプランにより、このクエリに対する回答の例が提供される。図１１に示すように、インデックス付きビュー「ｈｉｇｈｐａｉｄ」から選択した行は、逆結合操作として「ｎｅｓｔｅｄ−ｌｏｏｐ−ｊｏｉｎ」操作を使用して、キーｅｎｏに関してベーステーブル「ｅｍｐ」に「逆結合」される。したがって、「逆結合」という用語を用いて、あるキーに関して、インデックス付きビューからベーステーブルへの逆結合を記述する。

逆結合とともに任意のタイプの結合アルゴリズム（例えば、ネストループ、ソート−マージ（ｓｏｒｔ−ｍｅｒｇｅ）、ハッシュ）を用いることができることが企図されている。

図１２は、ネストしたデータを有するベーステーブル内のデータに対してクエリを行う方法の例の流れ図である。ステップ６００で、クエリを受け取る。ステップ６１０で、ベーステーブル内のデータについてのインデックス付きビューを受け取るか、引き出すか、またはその他の方法で生成する。ステップ６２０で、クエリオプティマイザは、このクエリが、インデックス付きビューに一致するクエリパターンに一致するか、またはこのクエリパターンを含むかどうかを判定する。このクエリまたはその一部がインデックス付きビューに一致する場合、ステップ６３０でクエリオプティマイザは、関数を適用する代わりに、一致するインデックス付きビューをインデックスとして使用するプランを生成する。このインデックス付きビューが、元のクエリで要求された列をすべて渡すことができない場合、ステップ６４０でオプティマイザは、元のベーステーブルとの逆結合を導入して、クラスタリングキーによって欠けている列を取得する。こうすると、インデックス付きビューには存在しないベーステーブルからのフィールドを、クエリの結果に含めることができる。

クエリまたはクエリの一部が、どのインデックス付きビューとも一致しない場合、ステップ６５０でクエリオプティマイザは、データに元の関数を適用するプランを生成する。

本発明では、部分インデックスの一般化としてのインデックス付きビューも可能であるし、型階層に対する部分インデックスとしてのインデックス付きビューも可能である。インデックス付きビューと、インデックス付きビューからベーステーブルに逆結合する能力とを組み合わせることによって、本発明は、部分インデックスとして知られる技術への一般化を実現する。インデックス付きビューと逆結合機能を組み合わせると、部分インデックスよりも強力な１組の機能が得られる。

テーブル内の行のサブセットだけのインデックスを生成するために、インデックス付きビューの定義において適切な条件を（例えば、Ｗｈｅｒｅ節で）設ける。例えば、「Ｆｒｅｄ」という人の検索を高速化するビューを生成するために、以下のインデックス付きビューを定義する。

ベーステーブルのクラスタリングキーに関して逆結合を行う機能と、インデックス付きビューについての既存のクエリ一致機能とを仮定すると、このインデックス付きビューは、「ｐｃｏｌ．ｎａｍｅが「Ｆｒｅｄ」である人から＊を選択せよ」などのクエリに回答する助けとなり得る。このクエリは、インデックス付きビューの１つの行を読み込み、それを人のテーブルに逆結合することによって解決することができるはずである。

さらに、インデックス付きビューと、ベーステーブルへの逆結合機能とを組み合わせると、オブジェクトリレーショナルＤＢＭＳ（データベース管理システム）における（ＵＤＴまたはオブジェクトとしても知られている）１組のユーザ定義型のインデックス化をサポートすることもできる。これらの型が、（型階層またはＩＳ−Ａ階層としても知られている）一般化階層内で構成される場合、インデックス付きビューと逆結合機能の組合せを用いて、型が所与の型のものであるか、またはそのサブタイプの１つであるテーブル内の値をインデックス化することが可能である。

型に関してフィルタリングされた部分インデックスが必要とされないか、あるいは望まれないサブタイプのフィールドに関してインデックス化を行うために、計算される列に関する従来方式のインデックスを実施し得る。望ましくは、インデックス化すべきフィールドを含まない型については、計算される列の値をＮＵＬＬにする。このインデックスをクラスタ化することもできるし、クラスタ化を解除することもできる。例えば、ある人の給与に関するクラスタ化されたインデックスを生成するには、以下のようにする。この場合、非従業員の給与フィールドはＮＵＬＬである。

所与のＵＤＴ列についての型階層のサブセットをインデックス化するために（例えば、そのサブセットに含まれる値しか、インデックス化したい特定の属性をもたないので）、ビュー定義のＷｈｅｒｅ節においてＩＳ ＯＦ述語を用いて部分インデックスを生成する。例えば、インデックス内に非従業員についてのレコードを含まない、従業員の給与に関するインデックスを生成するには、以下のようにする。

このインデックス付きビューの例は、非従業員の給与についてのＮＵＬＬエントリを含まない。好ましくは、非従業員は、このビューのＷｈｅｒｅ節中のＩＳ ＯＦ条件によってフィルタリングにより除外されるので、インデックス化されない。

ＸＭＬフィールドのインデックス化
本発明の態様を用いて、ＸＭＬ値データフィールドをインデックス化することができる。データベースのテーブル内に記憶されたリレーショナルデータとは異なり、ＸＭＬは半構造化されている。すなわち、これらのデータは、事前宣言したスキーマには準拠しないが、スキーマ情報を表現するタグによって注釈がつけられている。従来方式のデータベースシステム内でＸＭＬデータをインデックス化し処理するために、これらのデータをテーブルフォーマットに分解しなければならない。以下の例に、ＸＭＬ断片およびこれに対応する１つの可能なテーブルフォーマット（表４）を示す。

ＸＭＬをテーブルフォーマットに分解する様々な異なる方法が可能であり、本発明は、特定の１つを使用することに限定されるものではない。そうではなくて、例えば本明細書でＸＭＬ変換と称する、ＸＭＬ断片が与えられるとテーブル値フォーマットを出力する任意の関数を用いることができる。

ＸＭＬ変換関数は、上記で説明したテーブル値関数である。本発明により、ＸＭＬ断片に対するＸＭＬ変換の呼出し結果をインデックス化することができる。例えば、ユーザは、タグ、値、および階層情報の列、またはこれらの組合せに関するインデックスを形成したいことがある。

ユーザがＸＭＬ断片に対してクエリを行い得る１つの可能な方法を以下のように記述し得るはずである。

ただし、「＜ｘｍｌ．．．＞」は、所与のＸＭＬ断片を表す。クエリは、「Ｓａｍ Ｊｏｎｅｓ」という値を有し、「ｎａｍｅ」というタグがついた要素についてこのＸＭＬ断片を検索することになる。

さらに、ＸＭＬ断片は、ＸＭＬ文字列として与えるのではなく、データベーステーブルにおけるＸＭＬデータ型フィールドの形式で供給することができる。ＸＭＬデータ型列からのＸＭＬを用いたクエリの例は、以下のように記述し得るはずである。

上記は、ＸＭＬ断片型のｓａｌｅｓ（販売）というテーブル内にｓａｌｅｓｐｅｒｓｏｎ（販売員）という列があること、すなわち、ｓａｌｅｓのどの行も、ｓａｌｅｓｐｅｒｓｏｎと称することができるＸＭＬ断片を含むことを仮定している。上記のクエリは、ｓａｌｅｓテーブルに照会することと、ＸＭＬ断片に照会することを組み合わせる。このクエリは、２００４年２月２８日に商談をまとめた販売員の電話番号を返す。

複数の列またはフィールドの変換
別の実施形態の例では、複雑な構造の複数の列および／または複数のフィールドをインデックス化することができる。一般に、データベースシステム内の構造をインデックス化することにより、複雑な構造内の単一の列または場所からのデータをインデックス化することができる。例えば、表２に関して説明した例では、ネストした集合における住所フィールドをインデックス化するメカニズムを説明した。本発明の態様を用いて、複雑なオブジェクトまたは行に含まれる複数のフィールドから派生したデータをインデックス化することもできる。

表５のインデックス付きビューの例には、人およびこれらの人たちの住んでいる場所のテーブルが記載されている。これらのデータに関する関数呼出しにより、表６に示すデータを返すことができるはずである。

表６には、表５からのデータに関する異なる種類のインデックス付きビューの結果が記載されている。この例では、表５からの複数の列が、インデックス付きビュー内で合わせてインデックス化されている。この例では複数の列を用いているが、ＵＤＴなどの複雑なオブジェクトからの複数のフィールド、あるいは列とフィールドの組合せを用いることも可能である。さらに、この変換は、データの列またはフィールドに適用される特別な論理を含み得る。この例では、各州の短縮形は、参照先の変換および参照元データの一部である。ただし、各州のフルネームは、関数呼出しの一部として生成され、その結果にも挿入される。多くの変換が可能であり、単一の値についての追加のマッピングを導入することに限定されるものではない。可能なマッピングの例は、列に含まれるデータのサブストリングを取り出すこと、なんらかのやり方で複数の列またはフィールドからのデータを組み合わせること、または単一の列またはフィールドからの複数の語を複数の行に分割することを含み得るが、これらに限定されるものではない。表６は、単一のフィールドからの複数の語を複数の行に返す例も含む。このテーブルの追加の列を用いて、関数呼出しの結果の一意性を保証するために、逆結合を可能にするか、あるいは列を導入するロケータ列を含めることができる。

この例の変換により、複雑な変換の結果をインデックス化することができる。また、ある種のクラスのクエリについて、データに対するクエリをより効率よく行うこともできる。１つのこのようなクエリを、以下のように記述し得るはずである。

このクエリでの所望の結果は、「Ｌａｋｅ」または「Ｃａｌｉｆｏｒｎｉａ」という語になんらかの関連をもつ人を見つけることである。この関連は、テーブル内の列のいずれかと厳密に列が一致することとすることもできるし、テーブル内のデータに関する、場合によってはユーザが追加で定義した論理の結果とすることもできる。この例では、「Ｌａｋｅ」は、「Ｓａｒａ」を含むレコードに関連する１つのフィールドの２番目の語であり、「Ｃａｌｉｆｏｒｎｉａ」は、「Ｂｏｂ」を含むレコードに関係する。この論理は、関数「ＳＯＭＥＣＯＬＵＭＮＣＯＮＴＡＩＮＳ」にカプセル化されるが、これは、任意の検索状況において使用し得るはずである。例えば、同じ論理を、ＳＱＬ関数「ＬＩＫＥ」を使用して適用し得るはずである。ただし、他の関数も、類似のやり方で本発明を利用することができる。

クエリプロセッサは、この関数呼出しの結果に対して生成されたインデックス付きビューを用いて、ＬＩＫＥまたはＳＯＭＥＣＯＬＵＭＮＣＯＮＴＡＩＮＳを含むクエリを効率よく解決し得る。望ましくは、この論理では、データについてのこの特定の関数呼出しの結果を含むインデックス付きビューを効率よく見つけるのに、一致論理を使用するだけでよい。

結論
本明細書で説明した様々なシステム、方法、および技術は、ハードウエアまたはソフトウエアによって、あるいは、適切な場合にはそれらの組合せによって実施することができる。そのため、本発明の方法および装置、あるいは本発明のある種の態様または一部は、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、ハードドライブその他の機械可読の記憶メディアなど、有形のメディアにおいて実施されるプログラムコード（すなわち命令）の形態をとることができる。このプログラムコードが、コンピュータなどの機械にロードされ、その機械よって実行されると、この機械は、本発明を実施する装置になる。プログラム可能なコンピュータ上でプログラムコードを実行する場合には、このコンピュータは一般に、プロセッサ、このプロセッサによって読出し可能な記憶メディア（例えば、揮発性および不揮発性メモリおよび／または記憶要素）、少なくとも１つの入力装置、および少なくとも１つの出力装置を含むことになる。好ましくは、コンピュータシステムと通信するために、高水準の手続き型プログラミング言語またはオブジェクト指向プログラミング言語で１つまたは複数のプログラムを実施する。ただし、これら１つ（または複数）のプログラムは、所望の場合には、アセンブリまたは機械語で実施し得る。いずれの場合でも、この言語は、コンパイル型またはインタプリタ型の言語とすることができ、ハードウエアの実施形態と組み合わせることができる。

本発明の方法および装置は、電気的な配線またはケーブル布線、光ファイバ、または他の任意の送信形態など、なんらかの送信メディアを介して送信されるプログラムコードの形態でも実施し得る。このプログラムコードが、ＥＰＲＯＭ、ゲートアレイ、ＰＬＤ（プログラム可能な論理デバイス）、クライアントコンピュータ、ビデオレコーダなどの機械によって受信され、その機械にロードされ、その機械によって実行されると、この機械は、本発明を実施する装置になる。汎用プロセッサ上で実施されると、このプログラムコードは、プロセッサと結合して、本発明のインデックス化機能を実施するように動作する固有な装置を提供する。

様々な図の好ましい実施形態に関して本発明を説明してきたが、他の類似の実施形態を用いて、あるいは、上記で説明した実施形態に改変および追加を施して、本発明から逸脱することなく本発明の同じ機能を実施し得ることを理解されたい。例えば、パーソナルコンピュータの機能をエミュレートするデジタル装置の状況で本発明の実施形態の例を説明したが、本発明は、このようなデジタル装置に限定されるものではなく、この応用例で説明したように、有線または無線にかかわらず、ゲーム用コンソール、ハンドヘルドコンピュータ、携帯型コンピュータなど、任意の数の既存のまたは新たに生まれつつあるコンピューティング装置または環境に適用することもできるし、通信ネットワークを介して接続され、このネットワークを介して対話する任意の数のこのようなコンピューティング装置に適用し得ることが当業者には理解されよう。さらに、本明細書では、特に無線ネットワーク装置の数が増加し続けているので、ハンドヘルド装置用オペレーティングシステムその他の特定用途向けオペレーティングシステムを含めて、様々なコンピュータプラットホームが企図されていることを強調しておく。したがって、本発明は、単一の実施形態のいずれにも限定されるべきではなく、添付の特許請求の範囲による広さおよび範囲において解釈すべきである。

従来方式のクエリオプティマイザのブロック図である。 演算子ツリーの例の図である。 実体化ビューを組み込んだ図２の演算子ツリーの図である。 本発明の態様を組み込むことができるコンピュータシステムを表すブロック図である。 ハードウエアコンポーネント、オペレーティングシステムコンポーネント、およびアプリケーションプログラムコンポーネントの３つのコンポーネント群に分割されたコンピュータシステムを示すブロック図である。 フォルダ内にグループ分けされるファイル用の、ツリーに基づく階層構造を示す図である。 本発明とともに使用し得る記憶プラットホームの例を示す図である。 本発明によるインデックス付きビューの例の図である。 本発明によるクラスタリングキーの例の図である。 本発明による実行プランの例を示す図である。 本発明によるアクセスプランの例を示す図である。 本発明による、データに対してクエリを行う方法の例の流れ図である。

Claims (8)

1. コンピュータがデータベースに格納されたベーステーブル内に存在するデータに対してクエリを行う方法であって、
   クエリを受け取るステップと、
   前記データベースに格納された前記データに関する関数呼出しについてのインデックス付きビューを受け取るステップであって、前記関数呼出しはテーブル値関数を含み、前記データはＸＭＬ値データフィールドを含む、ステップと、
   前記クエリが前記インデックス付きビューと一致するか判定することによって、前記インデックス付きビューで前記クエリに対し回答可能であるか決定するステップと、
   前記インデックス付きビューで前記クエリに対し回答可能である場合、前記インデックスビューを前記データに関する関数呼出しのインデックスとして適用するステップと、
   前記インデックス付きビューで前記クエリに対し回答不可能である場合、逆結合を前記インデックス付きビューに導入して前記インデックス付きビューには存在しない前記ベーステーブルからのフィールドを前記クエリ結果に含め、前記インデックス付きビューを前記データに関する関数呼出しのインデックスとして適用するステップと、
   前記インデックスを前記データに関する関数呼出しに使用してクエリ結果を決定するステップであって、ネストされたデータにアンネスト操作を行い、前記アンネスト操作により得られたアンネスト結果に対してビューをインデックス化する、ステップと
   を含むことを特徴とする方法。
2. 前記コンピュータが、データの論理行ロケータとして働くクラスタリングキーを決定するステップをさらに含むことを特徴とする請求項１に記載の方法。
3. 前記クラスタリングキーは一意のものであることを特徴とする請求項２に記載の方法。
4. 前記コンピュータが、前記クラスタリングキーによって、前記インデックス付きビューから前記ベーステーブルに逆結合するステップをさらに含むことを特徴とする請求項２に記載の方法。
5. コンピュータがデータベースに格納されたベーステーブル内に存在するデータに対してクエリを行う方法であって、
   クエリを受け取るステップと、
   前記データベースに格納された前記データに関する関数呼出しについてのインデックス付きビューを受け取るステップであって、前記関数呼出しはテーブル値関数を含み、前記データはＸＭＬ値データフィールドを含む、ステップと、
   前記クエリが前記インデックス付きビューと一致するか判定することによって、前記インデックス付きビューで前記クエリに対し回答可能であるか決定するステップと、
   前記インデックス付きビューで前記クエリに対し回答可能である場合、前記インデックス付きビューを前記データに関する関数呼出しのインデックスとして適用するステップと、
   前記インデックス付きビューで前記クエリに対し回答不可能である場合、逆結合を前記インデックス付きビューに導入して前記インデックス付きビューには存在しない前記ベーステーブルからのフィールドを前記クエリ結果に含め、前記インデックス付きビューを前記データに関する関数呼出しのインデックスとして適用するステップと、
   前記インデックスを前記データに関する関数呼出しに使用してクエリ結果を決定し、前記クエリ結果を格納するステップであって、ネストされたデータにアンネスト操作を行う、ステップと、
   を含み、前記インデックス付きビューが複数の部分インデックスの一般化であることを特徴とする方法。
6. コンピュータがデータベースに格納されたベーステーブル内に存在するデータに対してクエリを行う方法であって、
   クエリを受け取るステップと、
   前記データベースに格納された前記データに関する関数呼出しについてのインデックス付きビューを受け取るステップであって、前記関数呼出しはテーブル値関数を含み、前記データはＸＭＬ値データフィールドを含む、ステップと、
   前記クエリが前記インデックス付きビューと一致するか判定することによって、前記インデックス付きビューで前記クエリに対し回答可能であるか決定するステップと、
   前記インデックス付きビューで前記クエリに対し回答可能である場合、前記インデックス付きビューを前記データに関する関数呼出しのインデックスとして適用するステップと、
   前記インデックス付きビューで前記クエリに対し回答不可能である場合、逆結合を前記インデックス付きビューに導入して前記インデックス付きビューには存在しない前記ベーステーブルからのフィールドを前記クエリ結果に含め、前記インデックス付きビューを前記データに関する関数呼出しのインデックスとして適用するステップと、
   前記インデックスを前記データに関する関数呼出しに使用してクエリ結果を決定し、前記クエリ結果を格納するステップであって、ネストされたデータにアンネスト操作を行う、ステップと、
   を含み、前記インデックス付きビューが型階層に関する部分インデックスであることを特徴とする方法。
7. 前記コンピュータが、前記データに関する前記関数呼出しのインデックスとして前記インデックス付きビューを適用する前に、前記インデックス付きビューがクエリパターンと一致するか判定することをさらに含むことを特徴とする請求項１に記載の方法。
8. 前記データは、複合体構造の複数の列または複数のフィールドを含むことを特徴とする請求項１に記載の方法。

Images