JP2007509431A - タイプ・パス索引付け - Google Patents

Abstract

効率的な階層型検索は、オブジェクト・タイプに基づいている。追加情報を事前に計算し、それを高速ルックアップ構造に格納することにより、オブジェクト取り出し要求を満たすオブジェクトを迅速に識別することができる。さらに、この技法を使用して、ストア内のオペレーションに対するオブジェクト・ハイドレーションを回避することも可能になる。さらに、ヒストグラムなどのデータベースの統計的構造を活用して、各オブジェクトを検査する必要なく修飾オブジェクトの数を推定することができる。

Description

本発明は一般に、情報の格納および取り出しの分野に関し、具体的には、オブジェクト・タイプに基づく効率的な階層型検索に関する。

本出願は、全体として参照により本明細書に組み込まれている、２００３年１０月２３日に出願した米国特許出願第１０／６９２、３５０号の優先権を主張するものである。

消費者は、従来のパーソナル・インフォメーション・マネージャ（ＰＩＭ）スタイルのデータであるかまたはデジタル音楽やデジタル写真などの媒体であるかどうかにかかわらず、主に通信と個人情報の整理（organizing personal information）のためにコンピュータを使用する。デジタル・コンテンツの量、および未加工バイト（raw bytes）を格納する機能は、すさまじい成長を遂げた。しかし、このデータを編成し一元管理するために消費者が利用できる方法は、はるかに後れをとっている（追随していない）。知識労働者は、情報の管理および共有に膨大な時間を費やしており、ある調査によれば、知識労働者はその時間の１５〜２５％を非生産的な情報関連の業務に費やしていると推定されている。また、一般的な知識労働者が情報の検索に１日当たり約２．５時間を費やしていると推定する調査もある。

コンピュータ・システムにおいて情報を整理する従来の方法では、ファイル、フォルダおよびディレクトリをベースとするシステム（「ファイルシステム」）の使用に重点を置いて、複数のファイルを、ファイルを格納するために使用される記憶媒体の物理編成の抽象化に基づいてフォルダのディレクトリ階層に複数のファイルを編成してきた。１９６０年代に開発されたＭｕｌｔｉｃｓオペレーティング・システムは、ファイル、フォルダ、ディレクトリを使用してオペレーティング・システム・レベルで格納可能なデータの単位を管理することを開拓したと信じられている。特に、Ｍｕｌｔｉｃｓでは、ファイルの物理アドレスがユーザ（アプリケーションおよびエンド・ユーザ）に透過的ではなかったファイルの階層内に、シンボリック・アドレスを使用した（これによりファイル・パスの概念を導入した）。このファイル・システムは個々のファイルのファイル形式（file format）に完全に無関心であり、ファイル間のリレーションシップはオペレーティング・システム・レベル（つまり、階層内のファイルの場所以外）では無関係であると見なされていた。Ｍｕｌｔｉｃｓの出現以来、格納可能なデータは、オペレーティング・システム・レベルでファイル、フォルダおよびディレクトリに編成されてきた。これらのファイルは一般に、ファイル・システムによって保持される特殊ファイルに組み込まれたファイル階層自体（「ディレクトリ」）を含んでいる。このディレクトリが、ディレクトリ内の他のすべてのファイルに対応するエントリのリストと、階層内のそのようなファイルのノード上の場所（本明細書においてフォルダと呼ぶ）を保持する。以上のような状態が、ほぼ４０年間にわたるこの分野の状態であった。

しかしながら、コンピュータの物理ストレージ・システムに収められた情報の合理的表現を与え、ファイル・システムがその物理ストレージ・システムの抽象である限り、したがってファイルの利用には、ユーザが操作するもの（コンテクスト、機能、および他の単位とのリレーションシップを有する単位）とオペレーティング・システムが提供するもの（ファイル、フォルダ、およびディレクトリ）との間のあるレベルの間接化（a level of indirection (interpretation;解釈）が必要となる。必然的に、ユーザ（アプリケーションおよび／またはエンド・ユーザ）は、たとえそうすることが非効率であり、整合性に欠けるか、または望ましくない場合であっても、選択の余地がなく、情報の単位をファイル・システム構造に押し込まざるを得なかった。ほとんどの既存のファイル・システムはファイルおよびフォルダの整理にネストされたフォルダのメタファーを使用するので、ファイルの数が増加するにつれて、柔軟かつ効率的な編成方式を維持するために必要な取り組みはまさに試練となってしまう。

過去において、ファイル・システムの欠点に対処する試みがいくつか失敗に終わっている。こうしたこれまでの試みの中には、連想記憶装置（content addressable memory）を使用して、物理アドレスによってではなくコンテンツによってデータにアクセスできるようなメカニズムを提供するものも含まれていた。しかし一方、連想記憶装置はキャッシュおよびメモリ管理装置などの装置による小規模な利用に有効であることが判明したが、物理記憶媒体のような装置の大規模な利用は種々の理由からまだ可能ではなかったために、こうした取り組みは不成功に終わった。そのため、そのようなソリューションは単に存在していない。オブジェクト指向データベース（ＯＯＤＢ）システムを使用する他の試みも行われたが、こうした試みは、強力なデータベース特性と優れた非ファイル表現にもかかわらず、ファイル表現の処理には効果的ではなく、速度、効率、およびハードウェア／ソフトウェア・インターフェース・システム・レベルにおけるファイルおよびフォルダ・ベースの階層構造の簡易さを再現することはできなかった。

「ＷｉｎＦＳ」（以下で詳細に説明）などの新しく開発されたストレージ・システムは、データベース内にテーブルとしてファイルのディレクトリを格納する。各ファイルはテーブル内の行（row）によって表され、「ディレクトリ内のすべてのファイルを列挙する」などのファイル・システム・オペレーションは、データベース・エンジンに対してクエリを使用することで満足される。したがって、ストアに対して基本オペレーションを効率的に実行することは、データベース・クエリを効率的に最適化するオペレーションとなる。

そのようなストレージ・システムにおいて、ファイルの概念は「オブジェクト」の概念まで拡大される。ファイルに関するメタデータは、スキーマ（ストレージ・システムにおいて定義される）と共に管理対象のＣＬＲ（共通言語ランタイム）オブジェクトに格納され、そのオブジェクトに対して許容可能な記述データを表す。たとえば、ピクチャは、その解像度、撮像時刻、ロケーション情報などのデータを格納している代表的ＣＬＲオブジェクトを備える場合もある。このオブジェクト・モデルは、データ継承（data inheritance）をサポートする。データ継承により、タイプを別のタイプから派生させて、新しいフィールドを追加することが可能になる。たとえば、「ＤｒｉｖｅｒｓＬｉｃｅｎｓｅＰｉｃｔｕｒｅ」などの、ピクチャのサブクラスを作成することもできる。そのようなサブクラスは、Ｄｒｉｖｅｒ’ｓ Ｌｉｃｅｎｓｅ ＩＤフィールドのような、その他の情報（extra information）を含んでいる。

ＷｉｎＦＳなど、これらの新しく開発されたストレージ・システムにおいて、公開されたスキーマはトランスレーション層を通じてテーブルにマップされる。ユーザは、基本テーブルで操作を行うのではなく、一連のデータのビューを見るだけである。このマッピングの精密な設計は重要ではないが、これは、ＷｉｎＦＳ ＡＰＩとその基盤となるストレージ・フォーマットとの間の接着剤の役割を果たす。ユーザは、このマッピングを直接制御したり、見たりすることはない。

ＷｉｎＦＳ Ｓｔｏｒｅはまた、以前の従来型ファイル・システムにおけるファイル名とは対照的に、そのタイプに基づいてオブジェクトにクエリを実行する概念も公開する。タイプ・ベースのクエリは、厳密なタイプまたは所定のタイプから派生する任意のタイプを検索することができる。この後者の形式は、階層型マッチングと呼ばれ、共通のＷｉｎＦＳオペレーションとなることが期待されている。

ＷｉｎＦＳのスキーマ・モデルは、クエリ・プロセッサにいくつかの新たな難題をもたらす。ユーザ定義タイプ、つまりＵＤＴは広範囲に使用されおり、ＵＤＴタイプに基づいてテーブルからすべてのＵＤＴを取り出すことが一般的である。さらに、ＷｉｎＦＳはＵＤＴ継承を使用し、所定のタイプおよび任意のサブタイプのすべての要素をテーブルから取り出すことも要件となっている。それぞれ異なる数のＵＤＴ、タイプ、タイプ・トポロジ、およびそのトポロジ内のＵＤＴ分布を含む複数のテーブルが存在する。これらのプロパティにより、正確な濃度（cardinality）およびコストの見積りを行うことが困難になり、さらにタイプ／サブタイプ階層に基づいて効率的に値を取り出すことも困難になる。

既存のデータ・ストレージおよびデータベース・テクノロジにおける以上の不備を考慮すると、効率的なタイプ階層型取り出しおよびコスト見積りに対するニーズが存在する。本発明はこれらニーズを満たす。

以下で、本発明のさまざまな態様の概要を述べる。これは、本発明の重要な態様のすべてを包括的に説明するものではなく、また本発明の範囲を定義するものでもない。むしろ、詳細な説明およびそれに続く図を導く案内としての役割を果たすことを目的としている。

本発明は、オブジェクト・タイプに基づく効率的な階層型検索に向けられる。追加の特殊情報を事前に計算し、それを高速ルックアップ構造に格納することにより、オブジェクト取り出し要求を満足するオブジェクトを迅速に識別することができる。さらに、これらの技法を使用して、ストア内の特定のオペレーションに対する高価なオブジェクト・ハイドレーション（Object Hydration）を回避することも可能になる。加えて、新しい方法でデータベースの統計的構造を活用して、各オブジェクトを検査する必要なく修飾オブジェクトの数を推定することができる。

本発明の他の特徴および利点は、本発明の以下の詳細な説明および付属の図を参照すれば明らかになろう。

上記の要約および上記の好ましい実施形態の詳細な説明は、付属の図を参照しながら読めばよりよく理解できよう。本発明を例示する目的で、本発明の例示的な構造が図に示されている。ただし、本発明は、開示されている特定の方法および手段に限定されることはない。

主題について、法定要件を満たすために限定性を持って説明する。ただし、説明自体は、本発明の範囲を限定することを意図していない。むしろ、発明者は、主張されている主題が他の方法で実施することもでき、他の現在または将来の技術と併せて、本明細書に説明されているさまざまなステップまたはステップの組み合わせと類似したものを含めることができることを意図している。さらに、採用された方法のさまざまな要素を示すために本明細書において「ステップ」という用語が使用されるが、この用語は、個々のステップの順序が明示的に記述されている場合を除き、本明細書に開示されているさまざまなステップの間の特定の順序を暗示するものとして解釈すべきではない。

概要
本発明は、オブジェクト・タイプに基づく効率的な階層型検索に向けられる。追加情報を事前に計算し、それを高速ルックアップ構造に格納することにより、オブジェクト取り出し要求を満足するオブジェクトを迅速に識別することができる。さらに、この技法を使用して、ストア内のオペレーションに対するオブジェクト・ハイドレーション（Object Hydration）を回避することも可能になる。加えて、新しい方法でデータベースの統計的構造を活用して、各オブジェクトを検査する必要なく修飾オブジェクトの数を推定することができる。

本発明は、特定のタイプを持つテーブル内の値の、または、そのタイプがタイプ階層内の所定のタイプにルートを持つツリー内にある値の、高速取り出し（fast retrieval）を提供する。Ｂツリー索引は、特定のロケーションをシークして、１つの値（たとえばパス・タイプ）を有するオブジェクトまたは同じ値を備える一連のオブジェクトを取り出すことができる。さらに、オブジェクト値のプレフィックスをシークして、同じプレフィックスを含むすべての値の範囲を返すこともできる。これらのプロパティを活用して、タイプまたはタイプ階層に基づく効率的な取り出しを行えるようにすることができる。

ＷｉｎＦＳは、ファイル・システムでオブジェクトの概念を導入するファイル・システム／データ・ストアである。このストア内のオペレーションの１つは、オブジェクトをそれらのタイプに基づいて効率的に見つけてクエリを行えるようにすることである。本発明は、このオペレーションを極めて効率的に行えるようにする方法を説明する。

本発明は、ＵＤＴの階層タイプＩＤを提供する組み込み機能のためのインターフェースを提供する。階層タイプＩＤは、タイプ階層内のＵＤＴ表現のタイプを一意に識別するｖａｒｂｉｎａｒｙ値である。この機能を、適切な計算されたカラム（computed column）索引のクエリおよび作成に使用することにより、効率的なＵＤＴタイプ階層型取り出しがサポートされる。

例示的なコンピューティング環境
本明細書および特許請求の範囲において使用されている以下の用語は、以下のような意味を表している。

「オブジェクト」は、ハードウェア／ソフトウェア・インターフェース・システムにアクセスできる格納可能な情報の単位であり、ハードウェア／ソフトウェア・インターフェース・システム・シェルによってエンド・ユーザに見えるすべてのオブジェクトにわたって共通にサポートされるプロパティの基本セットを備えている。オブジェクトはさらに、新しいプロパティとリレーションシップを導入できるようにする機能を含むすべてのタイプにわたって共通にサポートされる、プロパティおよびリレーションシップも備えている。

「オペレーティング・システム」（ＯＳ）は、アプリケーション・プログラムとコンピュータ・ハードウェアの間の仲介としての役割を果たす特殊なプログラムである。オペレーティング・システムはほとんどの場合、シェルおよびカーネルを備えている。

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

本発明の多数の実施形態は、コンピュータ上で実行することができる。図１および以下の説明は、本発明が実装される適切なコンピューティング環境について簡単に概要を説明することを意図している。要求されてはいないが、本発明は、クライアント・ワークステーションまたはサーバのようなコンピュータによって実行されるプログラム・モジュールなど、コンピュータ実行可能命令の一般的なコンテクストに即して説明される。一般に、プログラム・モジュールには、特定のタスクを実行するかまたは特定の抽象データ・タイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。さらに、本発明が、ハンドヘルド機器、マルチ・プロセッサ・システム、マイクロ・プロセッサ・ベースまたはプログラマブル家庭用電化製品、ネットワークＰＣ、ミニ・コンピュータ、メインフレーム・コンピュータなど、他のコンピュータ・システムの構成により実施できることを当業者は理解するであろう。本発明はさらに、タスクが通信ネットワークを通じてリンクされたリモート処理装置によって実行される分散コンピューティング環境においても実施することができる。分散コンピューティング環境において、プログラム・モジュールは、ローカルおよびリモートのコンピュータ記憶装置に配置することができる。

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

パーソナル・コンピュータ２０はさらに、ハードディスク（図示せず）との間の読み取りまたは書き込みを行うハードディスク・ドライブ２７、取り外し可能の磁気ディスク２９との間の読み取りまたは書き込みを行う磁気ディスク・ドライブ２８、およびＣＤ−ＲＯＭその他の光媒体など、取り外し可能の光ディスク３１との間の読み取りまたは書き込みを行う光ディスク・ドライブ３０を含むことができる。ハードディスク・ドライブ２７、磁気ディスク・ドライブ２８、および光ディスク・ドライブ３０は、それぞれハードディスク・ドライブ・インターフェース３２、磁気ディスク・ドライブ・インターフェース３３、および光ドライブ・インターフェース３４によってシステム・バス２３に接続されている。ドライブおよびその関連するコンピュータ可読媒体は、パーソナル・コンピュータ２０のコンピュータ可読命令、データ構造、プログラム・モジュール、およびその他のデータの不揮発性記憶装置を提供する。

本明細書に記載の例示的な環境では、ハードディスク、取り外し可能磁気ディスク２９、および取り外し可能光ディスク７３１を採用しているが、磁気カセット、フラッシュメモリ・カード、デジタル・ビデオ・ディスク、ベルヌーイ・カートリッジ、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）などの、コンピュータによりアクセス可能なデータを格納できる他の種類のコンピュータ可読媒体も、例示的なオペレーティング環境に使用できることは当業者であれば理解するであろう。

ハードディスク、磁気ディスク２９、光ディスク３１、ＲＡＭ２４またはＲＯＭ２５には、オペレーティング・システム３５、１つまたは複数のアプリケーション・プログラム３６、その他のプログラム・モジュール３７、およびプログラム・データ３８を含む、多数のプログラム・モジュールを格納することができる。ユーザは、キーボード４０およびポインティング・デバイス４２などの入力装置を介してパーソナル・コンピュータ２０にコマンドおよび情報を入力することができる。他の入力装置（図示せず）としては、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送用パラボラ・アンテナ、スキャナなどを含むことができる。上記およびその他の入力装置は、システム・バスに接続されているシリアル・ポート・インターフェース４６を介して処理装置２１に接続されることが多いが、パラレル・ポート、ゲーム・ポート、またはユニバーサル・シリアル・バス（ＵＳＢ）など他のインターフェースによって接続することもできる。モニタ４７またはその他の種類の表示装置も、ビデオ・アダプタ４８などのインターフェースを介してシステム・バス２３に接続することができる。モニタ４７に加えて、パーソナル・コンピュータは通常、スピーカおよびプリンタなど、他の周辺出力装置（図示せず）を含んでいる。図１の例示的なシステムはさらに、ホスト・アダプタ５５、Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ（ＳＣＳＩ）バス５６、およびＳＣＳＩバス５６に接続されている外部記憶装置６２も含んでいる。

パーソナル・コンピュータ２０は、リモート・コンピュータ４９など、１つまたは複数のリモート・コンピュータへの論理接続を使用するネットワーク化された環境において動作することができる。リモート・コンピュータ４９は、別のパーソナル・コンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア・デバイスまたはその他の共通ネットワーク・ノードであってもよく、通常は上記でパーソナル・コンピュータ２０に関連して説明されている要素の多くまたはすべてを含んでいるが、図１においては記憶装置５０のみが示されている。図１に示される論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ）５１およびワイド・エリア・ネットワーク（ＷＡＮ）５２を含んでいる。そのようなネットワーク環境は、オフィス、企業規模のコンピュータ・ネットワーク、イントラネット、およびインターネットで一般化している。

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

本発明の多数の実施形態がコンピュータ制御システムに特に適切であることが想定されるが、本明細書においては本発明をそのような実施形態に限定する意図はない。これに対して、本明細書において使用されている「コンピュータ・システム」という用語は、押しボタンを備えるか、あるいはボタン押し下げ、またはボタン押し下げに相当する操作を判断することができるあらゆる装置を、このような装置が事実上、電子的、機械的、論理的、または仮想的のいずれであるかにかかわりなく、包含することを意図している。

図２のブロック図に示されているように、コンピュータ・システム２００は、ハードウェア・コンポーネント２０２、オペレーティング・システム・コンポーネント２０４、およびアプリケーション・プログラム・コンポーネント２０６という、３つのコンポーネント・グループに大きく分割することができる。

特定のコンピュータ・システム２００において、図１に戻って参照すると、ハードウェア２０２は、中央演算処理装置（ＣＰＵ）２１、メモリ（ＲＯＭ２４およびＲＡＭ２５）、基本入出力システム（ＢＩＯＳ）２６、および特にキーボード４０、マウス４２、モニタ４７、および／またはプリンタ（図示せず）などのさまざまな入出力（Ｉ／Ｏ）装置を備えることができる。ハードウェア・コンポーネント２０２は、コンピュータ・システム２００の基本リソースを備えている。

アプリケーション・プログラム・コンポーネント２０６は、コンパイラ、データベース・システム、ワード・プロセッサ、ビジネス・プログラム、ビデオ・ゲームなどを含むさまざまなソフトウェア・プログラムを備えているが、これらに限定されることはない。アプリケーション・プログラムは、さまざまなユーザ（たとえばマシン、他のコンピュータ・システムおよび／またはエンド・ユーザ）に対して問題の解決、ソリューションの提供、およびのデータの処理を行うためにコンピュータ・リソースが利用される手段を提供する。

オペレーティング・システム・コンポーネント２０４は、オペレーティング・システム自体とそのシェルおよびカーネルを備えている。オペレーティング・システム（ＯＳ）は、アプリケーション・プログラムとコンピュータ・ハードウェアの間の仲介としての役割を果たす特殊なプログラムであり、オペレーティング・システムの目的は、ユーザがアプリケーション・プログラムを実行できる環境を提供することにある。オペレーティング・システムの目標は、効率的な方法でコンピュータ・ハードウェアを利用するだけでなく、コンピュータ・システムを使いやすくすることにある。

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

オペレーティング・システムは従来、アプリケーション向けのさまざまなサービスを実行している。複数のプログラムが同時に実行することができるマルチ・タスキング・オペレーティング・システムにおいて、オペレーティング・システムは、どのアプリケーションをどの順序で実行すべきか、また別のアプリケーションに切り替えるまでに各アプリケーションにどのくらいの時間を与えるかを決定する。オペレーティング・システムはさらに、複数のアプリケーション間の内部メモリの共有も管理し、ハードディスク、プリンタ、およびダイヤルアップ・ポートなどの接続されたハードウェア装置との間の入出力も処理する。オペレーティング・システムはまた、オペレーションの状態および発生した可能性のあるエラーについて各アプリケーション（および特定の場合にはエンド・ユーザ）にメッセージを送信する。オペレーティング・システムはさらに、バッチ・ジョブ（たとえば印刷など）の管理をオフロードすることもでき、それによりアプリケーションの初期化がこの作業から解放されて他の処理および／またはオペレーションを再開できるようになっている。並列処理を提供できるコンピュータにおいて、オペレーティング・システムは、同時に複数のプロセッサ上で実行するようにプログラムの分割も管理する。

オペレーティング・システムのシェルは、オペレーティング・システムへのインタラクティブ・エンド・ユーザ・インターフェースである（また「コマンド・インタープリタ」とも呼ばれる）。シェルは、アプリケーション・プログラムおよびエンド・ユーザによっても直接アクセス可能なオペレーティング・システムの外側のレイヤである。シェルとは対照的に、カーネルは、ハードウェア・コンポーネントと直接対話するオペレーティング・システムの最も内側のレイヤである。

当業者には十分に理解されているように、「ファイル」とは、オペレーティング・システムによって独立した（格納可能および取り出し可能な）エンティティとして操作することが可能な（オペレーティング・システム自体、アプリケーション・プログラム、データセットなどを含むが、これらに限定されることはない）情報のエンティティである。最新のオペレーティング・システム（Ｗｉｎｄｏｗｓ（登録商標）、Ｕｎｉｘ（登録商標）、Ｌｉｎｕｘ、Ｍａｃ ＯＳなど）において、ファイルとは、オペレーティング・システムによって操作される格納可能な情報（たとえばデータ、プログラムなど）の基本単位であり、ファイルのグループは「フォルダ」に編成される。Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ｍａｃｉｎｔｏｓｈ、および他のオペレーティング・システムにおいて、フォルダとは、１つのエンティティとして取り出し、移動、その他操作を行うことができるファイルの集合である。ＤＯＳ、ｚ／ＯＳ、およびほとんどのＵｎｉｘ（登録商標）ベースのオペレーティング・システムのような他の特定のオペレーティング・システムにおいては、フォルダよりも「ディレクトリ」という用語が使用され、初期のＡｐｐｌｅコンピュータ・システム（たとえばＡｐｐｌｅ ＩＩｅ）では「カタログ」という用語を使用していた。ただし、本明細書で使用するように、これらの用語はすべて同義語であり、相互置き換え可能であって、階層情報ストレージ構造に対する他のすべての等価語と参照をさらに含むことを意図している。

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

前述のことに加えて、各フォルダは、そのサブフォルダおよびそのファイルのためのコンテナである。つまり、各フォルダはそのサブフォルダとファイルを所有している。たとえば、フォルダがオペレーティング・システムによって削除された場合、そのサブフォルダおよびファイルも削除される（各サブフォルダの場合は、その所有するサブフォルダおよびファイルも循環的に含まれる）。同様に、各ファイルは１つのフォルダによってのみ所有することができ、ファイルはコピーすることができ、そのコピーが異なるフォルダに配置される場合でも、ファイルのコピーは、それ自体が別個の独立したエンティティであり、オリジナルに直接のリレーションシップはない（たとえば、オリジナル・ファイルに加えられた変更は、オペレーティング・システム・レベルでコピー・ファイルに反映されない）。したがって、この点で、フォルダは物理コンテナの概念的な等価物であり、ファイルはコンテナ内部の別個の独立した物理要素の概念的な等価物であるという理由で、事実上、ファイルおよびフォルダは、「物理的」な特徴を有する。

本発明に使用することができる、データを、編成し、検索し、共有するためのストレージ・プラットフォームは、オブジェクトと呼ばれるデータの形態を含むすべてのデータのタイプのストアとなるように設計されている。図４を参照すると、本発明によるストレージ・プラットフォーム４００は、データベース・エンジン４１４上に実装されたデータ・ストア４０２を備えている。１つの実施形態において、データベース・エンジンは、オブジェクト・リレーションシップ拡張（object relational extensions）を備えるリレーショナル・データベース・エンジンを備えている。１つの実施形態において、リレーショナル・データベース・エンジン４１４は、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒリレーショナル・データベース・エンジンを備えている。

データ・ストア４０２は、データの編成、検索、共有、同期化、およびセキュリティをサポートするデータ・モデル４０４を実装する。データの特定のタイプについては、スキーマ４４０などのスキーマに記述される。ストレージ・プラットフォーム４００は、以下に詳細に説明するように、これらのスキーマを展開するため、およびこれらのスキーマを拡張するためのツール４４６を提供する。

データ・ストア４０２内に実装されている変更追跡メカニズム４０６は、データ・ストアへの変更を追跡する機能を提供する。データ・ストア４０２はさらに、セキュリティ機能４０８およびプロモーション／デモーション機能４１０も提供する。データ・ストア４０２はまた、アプリケーションプログラミング・インターフェース４１２のセットを提供し、データ・ストア４０２の機能を、ストレージ・プラットフォームを利用する他のストレージ・プラットフォーム・コンポーネントおよびアプリケーション・プログラム（たとえば、アプリケーション・プログラム４５０ａ、４５０ｂ、および４５０ｃ）に見えるようにする。

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

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

少なくとも一部の実施形態において、ストレージ・プラットフォーム４２０はさらに、データが他のシステムに基づいて作用することを可能にし、他のシステムとの対話を可能にする追加の機能をアプリケーション・プログラムに提供することができる。これらの機能は、Ｉｎｆｏ Ａｇｅｎｔサービス４３４および通知サービス４３２などの追加サービス４２８の形態で、また他のユーティリティ４３６の形態で実施することができる。

少なくとも一部の実施形態において、ストレージ・プラットフォームは、コンピュータ・システムのハードウェア／ソフトウェア・インターフェース・システムに組み入れられるか、またはその不可欠部分（integral part）を形成する。たとえば、制限なく、本発明のストレージ・プラットフォームは、オペレーティング・システム、仮想マシン・マネージャ（ＶＭＭ）、共通言語ランタイム（ＣＬＲ）またはその機能的な相当物、あるいはＪａｖａ（登録商標）仮想マシン（ＪＶＭ）またはその機能的な相当物に組み入れられるか、またはその不可欠部分を形成することができる。

本発明のストレージ・プラットフォームは、その共通のストレージ基盤および体系化されたデータを通じて、消費者、知識労働者および企業に対するさらに効率的なアプリケーション開発を実現することができる。このストレージ・プラットフォームは、機能豊富で拡張可能なプログラミングの外見上の面を提供し、これはそのデータ・モデルに固有の機能を利用できるようにするだけではなく、既存のファイル・システムおよびデータベース・アクセス方法も取り入れ、拡張している。

本明細書の説明、およびさまざまな図において、本発明のストレージラットフォーム４００は、「ＷｉｎＦＳ」と呼ばれる。ただし、このストレージラットフォームを参照するこの名称の使用は、もっぱら説明上の便宜のためであり、決して限定することを意図するものではない。

本発明のストレージ・プラットフォーム４００のデータ・ストア４０２は、ストア内に常駐するデータの編成（organization）、検索、共有、同期化、およびセキュリティをサポートするデータ・モデルを実装する。本発明のデータ・モデルにおいて、「オブジェクト」とはストレージ情報の基本単位である。データ・モデルは、以下でさらに詳細に説明するように、オブジェクトおよびオブジェクト拡張を宣言し、オブジェクト間のリレーションシップを確立し、オブジェクトを編成して分類するためのメカニズムを提供する。

データ・モデルは、タイプの間のサブタイプ−スーパータイプというリレーションシップを定義できるようにする。サブタイプ−スーパータイプのリレーションシップは、タイプＡがタイプＢのＢａｓｅＴｙｐｅであればＢのすべてのインスタンスもＡのインスタンスでなければならい、というような方法で定義される。これを言い換えると、Ｂに適合するすべてのインスタンスはＡにも適合する必要があるということである。たとえば、ＡがタイプＳｔｒｉｎｇのプロパティＮａｍｅを持ち、ＢがタイプＩｎｔ１６のプロパティＡｇｅを持つ場合、Ｂの任意のインスタンスはＮａｍｅおよびＡｇｅの両方を持つことになる。このタイプの階層は、ルートにおいて単一のスーパータイプを持つツリーとして考えることができる。ルートからの分岐は第１レベルのサブタイプを提供し、このレベルにおける分岐は第２レベルのサブタイプを提供する、というように続き、自らはサブタイプを持たない末端のリーフのサブタイプまで至る。このツリーは、均一の深さとなるように制約されていないが、循環（cycles）を含むことはできない。所定のタイプは、ゼロまたは多数のサブタイプおよびゼロまたは１つのスーパータイプを持つことができる。所定のインスタンスは、そのタイプのスーパータイプと併せて多くともその１つのタイプに適合することができる。言い換えれば、ツリー内の任意のレベルの所定のインスタンスの場合、インスタンスはそのレベルの多くとも１つのサブタイプに適合することができる。

リレーショナル・データベース・エンジン４１４は、１つの実施形態においてＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒエンジンを備えており、組み込みスカラ・タイプをサポートする。組み込みスカラ・タイプは、「ネイティブ」でしかも「単純」である。これは、ユーザが独自のタイプを定義できないという意味でネイティブであり、複雑な構造をカプセル化できないという点で単純である。ユーザ定義タイプ（「ＵＤＴ」）は、複雑な構造化タイプを定義してユーザがタイプ・システムを拡張できるようにすることによってネイティブのスカラ・タイプ・システムを超えるタイプ拡張性のメカニズムを提供する。ユーザによって定義されると、ＵＤＴは、組み込みスカラ・タイプが使用されるタイプ・システム内のどこでも使用することができる。

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

ＵＤＴはＣＬＲクラスである。これは状態（データ・フィールドなど）および振る舞い（ルーチンなど）を備えている。ＵＤＴは、Ｃ＃、ＶＢ．ＮＥＴなど、任意の管理対象の言語を使用して定義される。ＵＤＴメソッドおよび演算子は、そのタイプのインスタンスに対してＴ−ＳＱＬで呼び出すことができる。ＵＤＴは、たとえば、行（rows）内のカラムのタイプ、Ｔ−ＳＱＬ内のルーチンのパラメータのタイプ、またはＴ−ＳＱＬ内の変数のタイプのいずれかにできる。

以下の例はＵＤＴの基本を示している。ＭａｐＬｉｂ．ｄｌｌがＭａｐＬｉｂという名前のアセンブリを備えていると仮定する。このアセンブリにおいて、ネーム・スペースＢａｓｅＴｙｐｅｓの下にはＰｏｉｎｔという名前のクラスがある。

以下のＴ−ＳＱＬコードは、クラスＰｏｉｎｔを、Ｐｏｉｎｔという名前のＳＱＬ Ｓｅｒｖｅｒ ＵＤＴにバインドする。第１のステップは「ＣｒｅａｔｅＡｓｓｅｍｂｌｙ」を呼び出し、これは、ＭａｐＬｉｂアセンブリをデータベースにロードする。第２のステップは、「Ｃｒｅａｔｅ Ｔｙｐｅ」を呼び出してユーザ定義タイプ「Ｐｏｉｎｔ」を作成し、これを管理対象タイプＢａｓｅＴｙｐｅｓ．Ｐｏｉｎｔにバインドする。

作成されると、「Ｐｏｉｎｔ」ＵＤＴはテーブル内のカラムとして使用することができ、メソッドは以下に示すようにＴ−ＳＱＬで呼び出すことができる。

ストレージ・プラットフォームのスキーマのＵＤＴクラスへのマッピングは、高レベルにおいてかなり直接的である。一般に、ストレージ・プラットフォーム・スキーマはＣＬＲネーム・スペースにマップされる。ストレージ・プラットフォーム・タイプは、ＣＬＲクラスにマップされる。ＣＬＲクラス継承は、ストレージ・プラットフォーム・タイプ継承をミラーし、ストレージ・プラットフォーム・プロパティはＣＬＲクラス・プロパティにマップされる。

例示的な実施形態
標準的なデータ・ストアは、それぞれがＵＤＴのような、タイプを持つ、基本オブジェクトのテーブルを備えている。振る舞い（メソッドとも呼ばれる）は、そのタイプに追加することができる。一部の最新のデータ・ストアは、新しいタイプを作成するように追加のメソッドでタイプを拡張することができる継承を提供する。たとえば、タイプは、「．ｄｏｃ」または「．ｊｐｅｇ」などの拡張子にすることができる。これらのタイプへの継承拡張子は、たとえば、「．ｄｏｃ２」または「．ｊｐｇ２」であってもよい。本発明により、タイプ性に対するクエリ（「．ｄｏｃ」のみならず「．ｄｏｃ」への拡張に対するクエリなど）を行うことができる。

例示的なタイプの継承階層が図５に示されている。図５において、タイプは「ｄｏｃｕｍｅｎｔ」５００である。「Ｌｅｇａｌ ｄｏｃｕｍｅｎｔ」５１０および「ｒｅｖｉｅｗ ｄｏｃｕｍｅｎｔ」５３０は、「ｄｏｃｕｍｅｎｔ」５００のサブタイプとして示されている。「ｌｅｇａｌ ｄｏｃｕｍｅｎｔ」５１０のサブタイプは、「Ｗａｓｈｉｎｇｔｏｎ ｌｅｇａｌ ｄｏｃｕｍｅｎｔ」５２０である。タイプ（たとえば「ｄｏｃｕｍｅｎｔ」）および／またはサブタイプ（たとえば「ｄｏｃｕｍｅｎｔ」および／または「ｌｅｇａｌ ｄｏｃｕｍｅｎｔ」および／または「Ｗａｓｈｉｎｇｔｏｎ ｌｅｇａｌ ｄｏｃｕｍｅｎｔ」）に対してクエリを行うことができる。

従来の検索技法では、複数のカラム列を持つテーブルを使用し、そこでは、カラムの１つが、対応するオブジェクト・カラムの各オブジェクトのタイプ・カラムであった。検索を実行するために、検索エンジンは各行（row）を経由し、すべてのオブジェクトをメモリにロードして、一致があるかどうかを決定するためにタイプを検査することによって、すべてのオブジェクトをインスタンス化していた。この技法は非常に速度が遅く、検索を効率的に行うための最善の実行プランを決定する方法はない。

最新の検索技法では計算済みのカラム（computed columns）を備えており、そこでは、追加のカラムが、他の関連付けられたカラムの値に基づく事前計算済みの値（pre-computed values）を持つテーブルの形で提供される。この技法は検索を高速化するが、追加の計算されたカラムを格納するために追加のメモリが必要になる。タイプまたはＵＤＴの関数である「タイプ・パス」カラムと呼ばれる特殊な計算済みカラム（computed column）を提供することができる。これは、任意のタイプまたはサブタイプを検索するために使用することができる。

本発明の態様は、タイプ性（type-ness）に基づいて一連のオブジェクト・インスタンスを効率的に検索できる機能である。値が事前に計算され、オブジェクト・インスタンスをそのタイプに基づいて識別するために十分な情報を好ましく格納する。この値は、タイプの階層内の特定のタイプまたはすべてのタイプ（すべてが共通の祖先を共有）の効率的な検索をサポートするのに十分な情報を含んでいる。さらに、この値は、Ｂツリーまたは他の索引付け構造などの、高速アクセス構造に使用して、タイプに基づくかまたはタイプ階層に基づいてオブジェクトを検索することができる。

システム内の各タイプごとに、値は好ましくタイプに割り当てられる。値は、タイプ階層の各「レベル」（ルートから同じ深さ）において少なくとも一意でなければならない。タイプごとに、各親クラスのタイプ値は、すべての以前のプレフィックス・オペレーションの結果、またはプレフィックス・オペレーションが行われなかった場合には元のタイプに、プレフィックスされる。同じレベルのすべての要素は、同じストレージ形式（長さ）で格納される必要がある。

タイプのインスタンスを表す場合、値は前述のように決定され、その値はオブジェクトと共に格納される。これをデータベースに格納する場合、オブジェクトおよび事前計算済みの値は、同じテーブルの別個のカラムまたは表１に示すような他のストレージ構造に格納することができる。表１は、例示的なＩＤおよびその対応する文書タイプを示すサンプルのデータ・タイプの表である。

したがって、図６の注釈付きのタイプ階層に示すように、各タイプには番号または他の識別子が与えられる。図６に示されているように、「ｄｏｃｕｍｅｎｔ」タイプには識別子ＩＤ＝１、「ｌｅｇａｌ ｄｏｃｕｍｅｎｔ」には識別子ＩＤ＝２、「ｒｅｖｉｅｗ ｄｏｃｕｍｅｎｔ」には識別子ＩＤ＝３、「Ｗａｓｈｉｎｇｔｏｎ ｌｅｇａｌ ｄｏｃｕｍｅｎｔ」には識別子ＩＤ＝４が与えられる。オブジェクトのインスタンスが作成されるごとに、適切な識別子がタイプに付加される。そのようにして、たとえば、「ｄｏｃｕｍｅｎｔ」はタイプ・パス「１」で符号化され、「ｌｅｇａｌ ｄｏｃｕｍｅｎｔ」は「１．２」で符号化される。さらに「Ｗａｓｈｉｎｇｔｏｎ ｌｅｇａｌ ｄｏｃｕｍｅｎｔ」は、表１に示されるように「１．２．４」で符号化される。

以下の表２は、オブジェクト名、ＵＤＴ、およびタイプ・パスを格納するもう１つの例示的なストレージの表を示している。オブジェクトのインスタンスが作成されるごとに、適切な識別子がタイプに付加される。そのようにして、たとえば、「ｄｏｃｕｍｅｎｔ」はタイプ・パス「１」で符号化され、「ｌｅｇａｌ ｄｏｃｕｍｅｎｔ」は「１．２」で符号化される。さらに「Ｗａｓｈｉｎｇｔｏｎ ｌｅｇａｌ ｄｏｃｕｍｅｎｔ」は、表２に示されるように「１．２．４」で符号化される。

Ｂツリー索引（B-tree index）などの高速アクセス・ストレージ構造は、事前計算済みの値を含むカラムにわたって作成することができる。この索引付け構造は好ましいことに、所定の値または値の所定のプレフィックスを含む項目を効率的に見つけ出す機能を備えている。特定の値を見つけることは共通しているが、プリフィックス・オペレーションは通常、ＳＱＬのＬＩＫＥ‘ＰＲＥＦＩＸ％’構成体などの、ストリングの値を見つけるためにしか使用されない。ＬＩＫＥ構成体は、索引付け構造でプレフィックスを検索するオペレーションを使用して効率的に計算することができる。

そのようなオペレーションは、符号化された階層のタイプおよびサブタイプを検索するために使用することができる。たとえば、命令「ＬＩＫＥ‘１．２％’」は、（‘％’がワイルド・カードであると仮定すする）「１．２」で始まる符号化を持つ任意のオブジェクトを見つけ出す。したがって、この例示的な命令は、現行の例において、「ｌｅｇａｌ ｄｏｃｕｍｅｎｔ」タイプまたは「Ｗａｓｈｉｎｇｔｏｎ ｌｅｇａｌ ｄｏｃｕｍｅｎｔ」タイプであるすべてのオブジェクトを検索して返す。

特定のタイプまたはタイプ階層を検索する必要のあるオペレーションは、索引に基づいて動作して、特定のタイプのすべてのオブジェクトまたは特定タイプから派生するすべてのオブジェクトを識別することができる。索引付け構造での等価一致は、前者に使用され、プレフィックス一致は後者を満たす。この符号化により、タイプまたはタイプ階層ロケーションに基づくオブジェクトの高速ルックアップを行うことができる。データベース・システムのＢツリーは通常、（ＬＩＫＥ‘ａａａ％’クエリを満足するためにプリフィックス機能を使用して）これらのオペレーションのいずれもサポートする。

本発明の態様により、データ・テーブルの行は効率的に取り出すことができる。タイプ・パス・カラムの索引は、Ｂツリーの形態で作成することができる。たとえば、タイプ・パス「１．２」を表しているすべての行は、リーフ・ノードに格納される。リーフ・ノードは、行を持つテーブルに対応する。比較は、たとえば、Ｂツリー構造が「ｓｅｅｋ」コマンドに応じて下ってゆく際に行われる。特定のプレフィックスだけでなく特定の値で検索を行うために「ｓｅｅｋ」オペレーション算を使用できることが意図される。

データベース構造の代わりにメモリ内構造を使用できることが意図されている。逆索引を作成し、サフィックス・オペレーションを使用することができる。さらに、可変長符号化を各階層レベルに使用することができる。さらにその上、同じプロパティを備える一部の非数値表現を使用することができる。

タイプ代替性を使用して、すべてのタイプのオブジェクトは格納することができ、検索は「ＩＳ ＯＦ（タイプ）」演算子を使用してオブジェクト・タイプおよびサブタイプによってフィルタすることができる。本発明の態様により、「ＩＳ ＯＦ」などのオペレーション述部はタイプ・パス・カラムにマップすることができる。「ＩＳ ＯＦ ＯＮＬＹ」など、他のオペレーション述部を使用することができる。したがって、高価なオブジェクト・ハイドレーション（Object Hydration）またはインスタンス化を回避することができる。

タイプ階層に基づく値の事前計算は、オブジェクトのハイドレーティング（Hydrating an object）を回避して、そのタイプを判断するために使用することができる。オブジェクト・ハイドレーション／インスタンス化が高価であり、タイプによるクエリを行うことが一般的であることを想定すると、タイプの制約を限定しないオブジェクトのオブジェクト・インスタンス化を回避することが望ましい。オブジェクトのインスタンス化を回避し、しかも完全に忠実なフィルタリングを可能にするような方法でタイプが符号化できる場合、これはパフォーマンスを向上させることができる。

さらになお、ユーザのタイプ検査要求（user type-check requests）をインターセプトして、代わりに事前計算済みの値に対して等価的なオペレーションを内部的に実行するようにこれらを書き換えることが可能である。これは、事前計算済みの値が存在するすべてのオブジェクトについて行うことができる。

データベース・システムに実装されているタイプに基づく高速オブジェクト識別の実施形態の場合は、所定のタイプに属するオブジェクト、またはそのタイプから派生する任意のタイプのオブジェクトが存在するテーブルの行（rows）数を決定することが望ましい。この推定の問題を解決するための従来技法は、推測すること、すべての値が同等に可能である（つまりフラット分布）と仮定すること、およびテーブル濃度（table cardinality）を使用して推定を作成すること、またはヒストグラムを使用してより高い頻度および頻度の高くない値の範囲を追跡すること、を含んでいる。通常、ヒストグラムは、所定のタイプで存在する値がいくつあるかを決定するために有用である。本発明の態様は、ヒストグラム全体にわたり選択的に推定を行う。

ヒストグラムは、クエリにどのくらいの時間がかかるかを推定するために構築することができる。ヒストグラムは、各タイプのオブジェクトの数を示している。例示的なヒストグラムが図７に示されている。ここで、タイプ「ｄｏｃｕｍｅｎｔ」、「ｌｅｇａｌ ｄｏｃｕｍｅｎｔ」、「ｒｅｖｉｅｗ ｄｏｃｕｍｅｎｔ」および「Ｗａｓｈｉｎｇｔｏｎ ｌｅｇａｌ ｄｏｃｕｍｅｎｔ」の例示的なオブジェクト数がヒストグラム形式で示されている。ただし、ヒストグラムは、タイプ階層を提供することはない。タイプ階層は、難しく高価なルックアップ技法によって決定することができる。

本発明の態様は、ヒストグラムの符号化技法を対象としており、そのためタイプ階層はルックアップ技法を必要とすることなく識別することができる。この符号化技法によれば、図６の注釈付きのタイプ階層に示すように、各タイプには番号または他の識別子が与えられる。したがって、ヒストグラムは、この可変長符号化スキームを使用して階層が識別される形で、生成することができる。たとえば、図８に示されているように、幾つかの各タイプ／サブタイプに加えて、１．２．４が１．２のサブタイプであり、１．２が１のサブタイプであること、が容易に識別することができる。

図９は、本発明により選択性推定を生成する例示的な方法の流れ図を示している。オブジェクトのセット全体におけるタイプ階層クエリの選択性を推定するために、ステップ９００において本明細書に記載の符号化を使用し、ステップ９１０においてこの符号化の結果をカラムとして格納し、ステップ９２０においてそのカラム全体の（カラム毎に、またはカラムに索引を作成した結果として）ヒストグラムを作成すること、が望ましい。

次に、ステップ９３０において、クエリ・タイプが符号化され、どのオブジェクトを、タイプまたはそのタイプの任意のサブタイプから取り出すかを記述する。ヒストグラム内の各要素に対し、ステップ９４０において、符号化されたクエリ・タイプがヒストグラム・エントリのプレフィックスであるかどうか決定される。プレフィックスである場合は、ステップ９５０において、このヒストグラム・ステップに関連付けられている要素の数が、ヒストグラムとは別の「一致する要素」の数に追加される。プレフィックスではない場合は、ステップ９６０において、このヒストグラム・ステップに関連付けられている要素の数が、ヒストグラムとは別の「一致しない要素」の数に追加される。

すべてのヒストグラム・ステップが処理されると、「一致する要素」の数をとって、それを「一致する要素」の数および「一致しない要素」の数の合計で割ることにより、ステップ９９０において、この階層タイプ・マッチング・クエリの選択性推定が決定される。

したがって、この２進符号化のヒストグラムを使用して、タイプ階層内のＵＤＴの分布に関する統計情報を決定することができる。この階層符号化の知識を備えた上で選択性推定中にヒストグラムをたどることにより、クエリで使用するためにかなり正確な濃度推定を生成することができる。説明されているアルゴリズムごとに選択性を推定するために組み込み関数が使用される場合、ＩＳ ＯＦへのＣＬＲ呼び出しを完全に削除して、組み込み関数（intrinsic function）によって濃度推定を行うことが可能であることに留意されたい。

本発明によれば、ＵＤＴからタイプＩＤを返す関数が実装される。もう１つの関数は、タイプＩＤからの階層タイプＩＤ符号化を返す。ＷｉｎＦＳなどのストレージ・システムは、すべてのＵＤＴがホスティングするテーブル（たとえばオブジェクト・テーブル）に計算されたカラムを望ましく作成する。１つの実施形態において、ＩＳ ＯＦスカラが追加／置換の述部を含むことが検討される。たとえば、ＵＤＴ ｖａｌｒｅｆは、ＵＤＴを含んでいる基本テーブルを見つけるために使用することができる。次に、基本テーブルの計算されたカラムは、スカラ表現を備える計算されたカラムの存在を決定するために使用することができる。そのような列が見つかった場合、暗黙の述部が追加される。

各ＵＤＴタイプは、小さい（たとえば４バイト）固定長の値であると仮定される。さらに、階層タイプＩＤは、親タイプＩＤのストリングまたはバイナリ・フィールドへの連結として定義することもできる。ＵＤＴを含んでいる各行もこの階層符号化を表す計算されたカラムを有する場合、索引はこの新しいカラムにわたって作成することができる。すべてのＵＤＴを所定のタイプ階層に返すオペレーションは、範囲プレフィックス・オペレーションを使用して実装することができ、タイプＩＤの完全一致は非階層一致を解決するために使用することができる。

例示的な階層タイプＩＤは、以下のような関数として提供される。

ＵＤＴ＿ｅｘｐｒｅｓｓｉｏｎは、任意のユーザ定義タイプ値の表現式である。ＨＩＥＲＡＲＣＨＩＣＡＬ＿ＴＹＰＥ＿ＩＤ関数は、決定論的かつ正確であることが好ましい。これは、階層タイプＩＤを使用して派生した計算されたカラムに索引を構築する機能を提供する。計算されたカラムは、永続的にする必要はないと考えられる。

タイプ・パスが別のプレフィックスであるかどうかを決定するため、システムは、既存のＬＩＫＥプレフィックス・スキャニング機能を使用して構築されるＨＡＳ＿ＰＲＥＦＩＸ演算子を内部で使用する。このプレフィックス・スキャニング機能を使用して、フォーム「ｃｈａｒａｃｔｅｒ＿ｅｘｐｒｅｓｓｉｏｎ ＬＩＫＥ ‘ｐｒｅｆｉｘ＿ｓｔｒｉｎｇ％’」の条件に対するマッチングを実装する。ここでｐｒｅｆｉｘ＿ｓｔｒｉｎｇは、％などのワイルド・カード文字を含まない何らかの定数ストリングである。このＨＡＳ＿ＰＲＥＦＩＸ演算子は、ユーザの管理下にはないことが望ましい。ＨＡＳ＿ＰＲＥＦＩＸは、索引が使用可能である場合に索引スキャンを使用することができる。

階層タイプＩＤ値は、索引に格納する必要のあるデータの量を軽減するために短いことが望ましい。階層タイプＩＤは、ＷｉｎＦＳスキーマの各タイプについては１００文字未満の長さであることが望ましい。

内部タイプＩＤを与えられた階層タイプＩＤを取り出すための関数は、これが索引作成中に使用されるため、高速であることが望ましい。

好ましくは、タイプは、そのインスタンスがデータベースに残っている間（つまり、引き続き存在するテーブルの定義でタイプまたはその祖先が使用される場合）、ドロップまたは削除することができない。それ以外の場合、ドロップされたタイプの階層タイプＩＤを含んでいる索引エントリは索引に残る場合があるが、それらを解釈することは不可能になる。さらに、１つのタイプをドロップした後に新しいタイプを追加すると、結果として既存のインスタンスのタイプと同じ階層タイプＩＤを生じることがあり、エラーを引き起こす。

階層タイプＩＤの内部フォーマットは、好ましくは、長さが４バイトの倍数のｖａｒｂｉｎａｒｙ値で、タイプ階層のルートからＵＤＴ＿ｅｘｐｒｅｓｓｉｏｎの最も特定のタイプへのパスに沿った各タイプの（たとえば、４バイトの整数として内部に格納されている）タイプＩＤの連結を含むものである。

値がユーザ定義のタイプである属性を備える大規模なテーブルの場合、その属性の値が特定のタイプを持つか、または所定のタイプのサブタイプであるような行の高速取り出しをサポートすることが望ましい。この状況において高速検索をサポートするために、索引は、ＨＩＥＲＡＲＣＨＩＣＡＬ＿ＴＹＰＥ＿ＩＤを使用して作成された計算されたカラムに作成することができる。

以下のＵＤＴのタイプ階層を想定する。

さらに、以下のように定義されているテーブルがある。

ＩＳ ＯＦ演算子を使用してｐｃｏｌのタイプをフィルタリング中にｐｅｒｓｏｎ行の高速ルックアップを可能にするため、ｐｅｒｓｏｎテーブルのｐｅｒｓｏｎ．ｐｃｏｌに対して階層タイプＩＤに関する計算されたカラムおよび索引を以下のように追加することができる。

これにより、たとえば、ユーザは、「ｐｅｒｓｏｎ」テーブルが大規模なものであっても時間給従業員（hourly employees）に関するすべての情報を迅速に見つけることができる。

ＨＩＥＲＡＲＣＨＩＣＡＬ＿ＴＹＰＥ＿ＩＤのＣＬＵＳＴＥＲＥＤ索引は、所定のタイプのすべての値の高速検索が最優先である場合に作成することができる。索引ＣＬＵＳＴＥＲＥＤを作成することで、同じページ上またはディスクの近隣ページ上の、同じタイプの値またはそのタイプ階層の同じサブツリーの値をグループ化することになる。

クエリ書き換えの場合、ＩＳ ＯＦ述部がＨＩＥＲＡＲＣＨＩＣＡＬ＿ＴＹＰＥ＿ＩＤを介して内部で実装され、およびＨＩＥＲＡＲＣＨＩＣＡＬ＿ＴＹＰＥ＿ＩＤから派生した計算されたカラムの索引がＩＳ ＯＦ演算子を使用するタイプのクエリの迅速化を助けることができる、一般ステートメントを含めることが考えられる。

システムは、クエリ書き換えを内部で使用して、タイプ述部とも呼ばれるＩＳ ［ＮＯＴ］ ＯＦ述部を処理する。タイプ述部の望ましいフォーマットは、以下のように定義される。

次の形式の表現

は、

と同等である。

次の形式のタイプ述部

は、
ＵＤＴ＿ｅｘｐｒｅｓｓｉｏｎのタイプがｔｙｐｅ＿ｌｉｓｔのエントリと一致するかどうかを検査する述部の論理和として書き換えられる。

ＵＤＴ＿ｅｘｐｒｅｓｓｉｏｎ がＩｎｃｌｕｓｉｖｅ＿ＵＤＴ＿ｓｐｅｃｉｆｉｃａｔｉｏｎであるかどうか（UDT expression IS OF an Inclusive UDT specification）を決定するための検査は、次のように書き換えられたクエリで表現される。

ここで、＜＜ｃｏｎｓｔａｎｔ ｈｉｅｒａｒｃｈｉｃａｌ ｔｙｐｅ ｉｄ ｏｆ ＵＤＴ＿ｎａｍｅ＞＞は、ＵＤＴ＿ｎａｍｅの階層タイプＩＤを表すｖａｒｂｉｎａｒｙ定数である。

ＵＤＴ＿ｅｘｐｒｅｓｓｉｏｎがＥｘｃｌｕｓｉｖｅ＿ＵＤＴ＿ｓｐｅｃｉｆｉｃａｔｉｏｎであるかどうか（UDT expression IS OF an Exiusive_UDT specification）を決定するための検査は、次のように書き換えられたクエリで表現される。

上記の書き換えられた条件におけるＨＩＥＲＡＲＣＨＩＣＡＬ ＴＹＰＥ ＩＤ（ＵＤＴ＿ｅｘｐｒｅｓｓｉｏｎ）表現は、ｐｅｒｓｏｎ＿ｈｔｉｄ＿ｉｄｘなどの同じ表現から構築された計算されたカラム上の索引と一致することに留意されたい。

以下の例では、ＩＳ ＯＦおよびＩＳ ＯＦ（ＯＮＬＹ．．．）述部をサポートするために上記の書き換え規則の適用を示している。
− いかなる種類の従業員であってもすべての人物を見つける

− 書き換えクエリ

− タイプｅｍｐｌｏｙｅｅ＿ｔであってもそのサブタイプの１つではないすべての人物を見つける

− 書き換えクエリ

− 定額給または時間給従業員であるすべての人物を見つける

− 書き換えクエリ

ＵＤＴ表現の組み込みタイプＩＤを返すために、オーバーロードされたバージョンの関数ＴＹＰＥ＿ＩＤ（）を追加できることが考えられる。

さらに、単一のｖａｒｂｉｎａｒｙ階層タイプＩＤ（ｈｔｉｄ）引数に対してオーバーロードされたバージョンの関数ＴＹＰＥ＿ＮＡＭＥ（）を追加して、そのｈｔｉｄを備えるタイプのストリング名を返すことが考えられる。以下の例では、テーブル内の階層のそれぞれの異なるタイプの出現をカウントする方法を示している。
− 各タイプの人物の数をカウントする

階層タイプＩＤに対して圧縮スキームを提供することができる。これは、階層タイプＩＤから構築された索引キー・サイズの大きさを減らすことになる。たとえば、これらをｂａｓｅ―２５４の整数（十進数０〜２５４のバイト値の数字で）として符号化し、バイト２５５を区切り記号として使用する。すると、階層タイプＩＤは、次の形式になる。

多くの状況において、これはパス上のタイプＩＤあたり、４バイトではなく、わずか２バイトから３バイトという結果になる。

タイプ包含機能は、タイプ述部内のｔｙｐｅ＿ｌｉｓｔが複数のエントリを持つ場合、クエリ書き換えに追加することができる。たとえば、

は、

と同等である。
ｅｍｐｌｏｙｅｅ＿ｔがｐｅｒｓｏｎ＿ｔのサブタイプだからである。

結論
本明細書に記載のさまざまなシステム、方法、技法は、ハードウェアまたはソフトウェア、あるいは必要に応じてその両方を組み合わせて実装することができる。したがって、本発明の方法および装置、あるいは特定の態様またはその部分は、フロッピー（登録商標）ディスケット、ＣＤ−ＲＯＭ、ハードドライブ、または他の機械可読記憶媒体などの有形媒体に実装されるプログラム・コード（つまり命令）の形態を取り、プログラム・コードがコンピュータなどのマシンによってロードされ実行されるときに、そのマシンは本発明を実施するための装置となる。プログラム可能コンピュータ上でプログラム・コードを実行する場合、コンピュータは一般に、プロセッサ、プロセッサに可読な記憶媒体（揮発性および不揮発性メモリおよび／またはストレージ要素を含む）、少なくとも１つの入力装置、および少なくとも１つの出力装置を含んでいる。１つまたは複数のプログラムは、好ましくは高水準プロシージャ型またはオブジェクト指向プログラミング言語で実装され、コンピュータ・システムと通信する。ただし、プログラムは、必要に応じて、アセンブリまたはマシン言語で実装することができる。いずれの場合おいても、言語はコンパイルまたは解釈された言語であり、ハードウェア実装と組み合わせることができる。

本発明の方法および装置は、電気配線またはケーブリング経由、光ファイバ経由、あるいは他の伝送形態経由など、一部の伝送媒体上を伝送されるプログラム・コードの形態で組み入れることもでき、プログラム・コードがＥＰＲＯＭ、ゲートアレイ、プログラム可能論理装置（ＰＬＤ）、クライアント・コンピュータ、ビデオ・レコーダなどのマシンによって受信され、ロードされ、実行されるときに、マシンが本発明を実施するための装置となることを特徴としている。汎用プロセッサ上で実装される場合、プログラム・コードはプロセッサと結合して、本発明の索引付け機能を実行するように機能する一意の装置を提供する。

本発明についてさまざまな図の好ましい実施形態に関連して説明してきたが、他の類似した実施形態を使用することができ、また本発明を逸脱することなく本発明の同じ機能を実行するために変更および追加を行うことが可能であることを理解されたい。たとえば、本発明の例示的な実施形態は、パーソナル・コンピュータの機能をエミュレートするデジタル装置のコンテクストで説明されているが、本発明が説明されているようなデジタル装置に限定されることはなく、本発明が、有線または無線にはかかわりなく、ゲーム機、ハンドヘルド・コンピュータ、ポータブル・コンピュータなどの任意の数の既存または新たなコンピューティング装置または環境に適用することができ、通信ネットワーク経由で接続されてネットワーク全体と対話する任意の数のそのようなコンピューティング装置に適用することができることを当業者は理解するであろう。さらに、特に無線ネットワーク装置の数が増加し続けているため、ハンドヘルド装置オペレーティング・システムおよび他のアプリケーション固有オペレーティング・システムを含むさまざまなコンピュータ・プラットフォームが本明細書において検討されることを強調すべきである。したがって、本発明は、いかなる単一の実施形態に限定されることはなく、添特許請求の範囲に従った広さと範囲で解釈されるものとする。

本発明の態様を組み込むことができるコンピュータ・システムを示すブロック図である。 ハードウェア・コンポーネント、オペレーティングス・システムコンポーネント、およびアプリケーション・プログラム・コンポーネントという、３つのコンポーネント・グループに分割されるコンピュータ・システムを示すブロック図である。 フォルダにグループ化されたファイルの３ベースの階層的構造を示す図である。 本発明と共に使用することができる例示的なストレージ・プラットフォームを示す図である。 タイプおよびサブタイプに基づくオブジェクトの典型的な階層構造を示す図である。 本発明による注釈付きのタイプ階層を示す図である。 従来のヒストグラムを示す図である。 本発明により構築することのできるヒストグラムを示す図である。 本発明により選択性推定を生成する例示的な方法を示す流れ図である。

Claims (24)

1. 各タイプが識別子を有し、関連付けられた前記タイプを有する複数のオブジェクトを備えるデータ・ストアと、
   前記複数のオブジェクトを操作するためのハードウェア／ソフトウェア・インターフェース・システムと
   を備えることを特徴とするコンピュータ・システム。
2. 前記各タイプは、ユーザ定義タイプ（ＵＤＴ）であることを特徴とする請求項１に記載のコンピュータ・システム。
3. 前記タイプは、別のタイプのサブタイプにすることができることを特徴とする請求項１に記載のコンピュータ・システム。
4. 前記データ・ストアは、各オブジェクトへのタイプ・パスをさらに備えることを特徴とする請求項１に記載のコンピュータ・システム。
5. 前記データ・ストアは各タイプ・パスを格納するための計算されたカラムを備えることを特徴とする請求項４に記載のコンピュータ・システム。
6. 前記各タイプ・パスは、可変長符号化値を備えることを特徴とする請求項４に記載のコンピュータ・システム。
7. 各可変長符号化値は、前記関連付けられたオブジェクトの前記タイプの階層レベルに対応することを特徴とする請求項６に記載のコンピュータ・システム。
8. 複数のオブジェクトを操作することが可能なハードウェア／ソフトウェア・インターフェース・システムであって、各オブジェクトは関連付けられたタイプを有し、各タイプは識別子を有することを特徴とするハードウェア／ソフトウェア・インターフェース・システム。
9. 前記各タイプは、ユーザ定義タイプ（ＵＤＴ）であることを特徴とする請求項８に記載のハードウェア／ソフトウェア・インターフェース・システム。
10. 前記タイプは、別のタイプのサブタイプにすることができることを特徴とする請求項８に記載のハードウェア／ソフトウェア・インターフェース・システム。
11. 各オブジェクトは、関連付けられたタイプ・パスを有することを特徴とする請求項８に記載のハードウェア／ソフトウェア・インターフェース・システム。
12. 各タイプ・パスは、データ・ストア内の計算されたカラムに属することを特徴とする請求項１１に記載のハードウェア／ソフトウェア・インターフェース・システム。
13. 各タイプ・パスは、可変長符号化値を備えることを特徴とする請求項１１に記載のハードウェア／ソフトウェア・インターフェース・システム。
14. 各可変長符号化値は、前記関連付けられたオブジェクトの前記タイプの階層レベルに対応することを特徴とする請求項１３に記載のハードウェア／ソフトウェア・インターフェース・システム。
15. データ構造を格納したコンピュータ可読媒体であって、オブジェクトを含む第１のデータ・フィールドと、
    識別子を有して、前記オブジェクトに関連付けられた、データ・タイプを含む第２のデータ・フィールドと
    を備えるコンピュータ可読媒体。
16. 前記タイプは、ユーザ定義タイプ（ＵＤＴ）であることを特徴とする請求項１５に記載のコンピュータ可読媒体。
17. 前記タイプは、別のタイプのサブタイプにすることができることを特徴とする請求項１５に記載のコンピュータ可読媒体。
18. 前記オブジェクトへのタイプ・パスを含む第３のデータ・フィールドをさらに備えることを特徴とする請求項１５に記載のコンピュータ可読媒体。
19. 前記タイプ・パスは、可変長符号化値を備えることを特徴とする請求項１８に記載のコンピュータ可読媒体。
20. 前記可変長符号化値は、前記テータタイプから派生されることを特徴とする請求項１９に記載のコンピュータ可読媒体。
21. 識別子を備えたタイプを有する複数のオブジェクト全体に対してクエリの選択的推定を生成する方法であって、
    前記識別子から派生されたタイプ・パスで各オブジェクトを符号化すること、
    各オブジェクトに対し、そのタイプ・パスが前記クエリを満足するかどうかを決定すること、および
    オブジェクトの合計数に対する前記クエリを満足するタイプ・パスを有するオブジェクトの比率を決定すること
    を備える方法。
22. 前記クエリを受け取り、どのタイプ・パスが前記クエリを満足するかを決定することをさらに備えることを特徴とする請求項２１に記載の方法。
23. 前記クエリが満足させることのできるタイプを有するように前記クエリを符号化することをさらに備えることを特徴とする請求項２１に記載の方法。
24. 前記符号化されたオブジェクトを使用してヒストグラムを作成することをさらに備えることを特徴とする請求項２１に記載の方法。
    

Images