(57)【特許請求の範囲】
【請求項１】
プロセッサ、メモリ、およびデータベースを備えたシステムにおいて、コレクション型として定義された列を有する、前記データベース中のテーブルに対するクエリを処理する方法であって、前記コレクション型は、特定の型である１または複数のネストした要素を含み、
前記プロセッサが、前記コレクション型および前記特定の型の情報を前記メモリに格納するステップと、
前記プロセッサが、前記テーブル中の前記コレクション型として定義された列に適用されるクエリを受信するステップと、
前記クエリがスカラ演算の場合、前記プロセッサが、前記コレクション型として定義された列に格納されている前記要素の組に対して前記スカラ演算を実行して、演算した結果を返すステップと、
前記クエリが照会操作の場合、前記プロセッサが、前記コレクションのネストを解除して、前記特定の型として定義された第１の列を含むオブジェクトを生成し、生成したオブジェクトに対して照会を実行し、照会した結果を返すステップであって、前記第１の列は、前記要素の組の各要素を各行に格納する、ステップと
を含むことを特徴とする方法。
【請求項２】
前記特定の型は、ユーザ定義型であることを特徴とする請求項１に記載の方法。
【請求項３】
前記コレクション型は、各要素の相対順序を保持し、
前記オブジェクトは、第２の列を含み、前記第２の列の各行は、前記第１の列に格納された要素の前記相対順序に対応する値を有することを特徴とする請求項１に記載の方法。
【請求項４】
プロセッサ、メモリ、およびデータベースを備えたシステムにおいて、コレクション型として定義された列を有する、前記データベース中のテーブルに対するクエリを処理するプログラムを記録したコンピュータ可読記録媒体であって、前記コレクション型は、特定の型である１または複数のネストした要素を含み、前記プロセッサに、
前記コレクション型および前記特定の型の情報を前記メモリに格納するステップと、
前記テーブル中の前記コレクション型として定義された列に適用されるクエリを受信するステップと、
前記クエリがスカラ演算の場合、前記コレクション型として定義された列に格納されている前記要素の組に対して前記スカラ演算を実行して、演算した結果を返すステップと、
前記クエリが照会操作の場合、前記コレクションのネストを解除して、前記特定の型として定義された第１の列を含むオブジェクトを生成し、生成したオブジェクトに対して照会を実行し、照会した結果を返すステップであって、前記第１の列は、前記要素の組の各要素を各行に格納する、ステップと
を実行させることを特徴とするコンピュータ可読記録媒体。
【請求項５】
前記特定の型は、ユーザ定義型であることを特徴とする請求項４に記載のコンピュータ可読記録媒体。
【請求項６】
前記コレクション型は、各要素の相対順序を保持し、
前記オブジェクトは、第２の列を含み、前記第２の列の各行は、前記第１の列に格納された要素の前記相対順序に対応する値を有することを特徴とする請求項４に記載のコンピュータ可読記録媒体。
【請求項７】
コレクション型として定義された列を有するテーブルを格納するデータベースであって、前記コレクション型は、特定の型である１または複数のネストした要素を含む、データベースと、
前記コレクション型および前記特定の型の情報を格納するメモリと、
前記テーブル中の前記コレクション型として定義された列に適用されるクエリを受信し、前記クエリがスカラ演算の場合、前記コレクション型として定義された列に格納されている前記要素の組に対して前記スカラ演算を実行して、演算した結果を返し、前記クエリが照会操作の場合、前記コレクションのネストを解除して、前記特定の型として定義された第１の列を含むオブジェクトを生成し、生成したオブジェクトに対して照会を実行し、照会した結果を返すプロセッサであって、前記第１の列は、前記要素の組の各要素を各行に格納する、プロセッサと
を備えたことを特徴とするシステム。
【請求項８】
前記特定の型は、ユーザ定義型であることを特徴とする請求項７に記載のシステム。
【請求項９】
前記コレクション型は、各要素の相対順序を保持し、
前記オブジェクトは、第２の列を含み、前記第２の列の各行は、前記第１の列に格納された要素の前記相対順序に対応する値を有することを特徴とする請求項７に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータシステムにおけるデータ記憶、およびデータベースシステムにおいてユーザ定義タイプ（ＵＤＴ:user-defined type）をサポートするシステムに関する。ＵＤＴは、ある特定のコントラクト(specific contract)を構築(implement)するマネージドタイプ(managed type)を登録(register)することによってデータストア(data store)のスカラタイプシステム（群）(scalar type system(s))を拡張(extend)するために、リレーショナルデータベース(relational database)エンジンおよびファイルシステムと共に利用される拡張機構(extensibility mechanism)である。より詳細には、本発明は、スカラ(scalar)であると共に照会可能(queriable)であるＵＤＴにより、データベースシステムでの多重集合(multiset)および順序つきコレクション(ordered collection)の構築(implementation)に関する。
【背景技術】
【０００２】
ユーザ定義タイプ(user-defined type)
【０００３】
当業者には公知であり理解されているように、ＭＩＣＲＯＳＯＦＴ  ＳＱＬサーバは、豊富な管理および開発ツール、ＥＴＬ（抽出、変換、挿入）(extraction-transformation-loading)ツール、ビジネスインテリジェンスおよび分析サービス、ならびに他の機能を提供する包括的なデータベース管理プラットフォームである。さらに、ＭＩＣＲＯＳＯＦＴ  ＷＩＮＤＯＷＳ（登録商標）．ＮＥＴフレームワークの共通言語ランタイム(common language runtime)（ＣＬＲ）は、ＳＱＬサーバデータベースに最近統合された。
【０００４】
ＣＬＲは、ＭＩＣＲＯＳＯＦＴ．ＮＥＴフレームワークの核心部であり、すべての．ＮＥＴコード用の実行環境を提供する。ＣＬＲにおいて実行されるコードは、「マネージドコード(managed code)」と呼ばれる。ＣＬＲは、ジャストインタイムの（ＪＩＴ:just-in-time）コンパイル、メモリの割り振りおよび管理、タイプの安全性の実施、例外処理、スレッド管理、ならびにセキュリティを含む、プログラム実行に必要とされる様々な関数およびサービスを提供する。ＣＬＲは現在、．ＮＥＴルーチンを初めて呼び出すときにＳＱＬサーバによってロードされる。
【０００５】
以前のバージョンのＳＱＬサーバでは、データベースプログラマは、サーバ側でコードを書くとき、Ｔｒａｎｓａｃｔ−ＳＱＬを使うことしかできなかった。Ｔｒａｎｓａｃｔ−ＳＱＬは、国際標準化機構（ＩＳＯ）および米国規格協会（ＡＮＳＩ）によって定義されている、構造化照会言語（「ＳＱＬ」）の拡張である。Ｔｒａｎｓａｃｔ−ＳＱＬを用いると、データベース開発者は、データベースおよびテーブルを作成し、修正し、削除することができ、かつデータベースに格納されたデータを挿入し、取得し、修正し、削除することができる。Ｔｒａｎｓａｃｔ−ＳＱＬは、直接的な構造データアクセスおよび処理用に特に設計されている。Ｔｒａｎｓａｃｔ−ＳＱＬは、構造データアクセスおよび管理において他のものより優れているが、ＶＩＳＵＡＬ  ＢＡＳＩＣ．ＮＥＴおよびＣ＃のように成熟したプログラミング言語ではない。たとえば、Ｔｒａｎｓａｃｔ−ＳＱＬは、配列、コレクション、ｆｏｒ−ｅａｃｈループ、ビットシフト、またはクラスをサポートしない。
【０００６】
ＳＱＬサーバデータベースに統合されたＣＬＲを用いることによって、データベース開発者は、Ｔｒａｎｓａｃｔ−ＳＱＬのみでは遂行することが不可能または困難だったタスクを実施することができるようになった。ＶＩＳＵＡＬ  ＢＡＳＩＣ．ＮＥＴおよびＣ＃はともに、配列、構造化例外処理、およびコレクションをフルサポートする最新プログラミング言語である。開発者は、ＣＬＲ統合を利用して、論理がより複雑であり、ＶＩＳＵＡＬ  ＢＡＳＩＣ．ＮＥＴおよびＣ＃などの言語を用いる計算タスクにより適したコードを書くことができる。こうしたプログラミング言語は、カプセル化、継承、および多態性などのオブジェクト指向能力を提供する。関連するコードは、クラスおよび名前空間に容易に編成することができる。
【０００７】
マネージドコード(managed code)は、Ｔｒａｎｓａｃｔ−ＳＱＬよりも大量の演算および複雑な実行論理に適しており、ストリング処理および正規表現を含む多くの複合タスクの拡張サポートを特色とする。データベース開発者は、．ＮＥＴフレームワーク(.NET Framework)のベースクラスライブラリ（ＢＣＬ:Base Class Library）中にある機能を用いて、格納されたどの手順、トリガ、またはユーザ定義関数からも容易に利用することができる、予め構築された数千個のクラスおよびルーチンを利用することができる。
【０００８】
マネージドコードの別の利益は、タイプの安全性(type safety)である。マネージドコードが実行される前に、ＣＬＲは、コードが安全であることを確かめる。このプロセスは、「検証(verification)」として知られる。検証の間、ＣＬＲは、コードが実行するのに安全であることを保障するためにいくつかの検査を実施する。たとえば、コードは、書き込みを受けていないメモリが読み出しを受けないよう保障するために調べられる。ＣＬＲは、バッファオーバーフローも防止する。
【０００９】
マネージドコードを書くとき、展開単位は、アセンブリと呼ばれる。アセンブリは、動的リンクライブラリ（ＤＬＬ:dynamic link library）としてパッケージされる。マネージＤＬＬアセンブリは、ＳＱＬサーバによってロードしホストすることができる。ＣＲＥＡＴＥ  ＡＳＳＥＭＢＬＹステートメントは、サーバにアセンブリを登録するのに用いられる。以下に例を挙げる。
【００１０】
【表１】
0004728675.tif 000002
【００１１】
この例において、ＦＲＯＭ句は、ロードするアセンブリのパス名を指定する。
【００１２】
ＳＱＬサーバは従来、整数、浮動小数、日付、時間、および文字列などの「組み込み(built-in)」スカラタイプ(scalar type)をサポートしていた。こうした組み込みタイプは、＋、−、＊、／など１組の組み込み演算ならびにこうしたタイプに対する組み込み関数も伴う。こうしたタイプ、演算、および関数は、製品によって構築されパッケージされ、ユーザは独自のタイプを定義することができないという意味で、「組み込み」である。
【００１３】
ＳＱＬサーバなどのデータベースシステムは、データベースシステムにおいてスカラタイプとして働くが、他のものの中でもＸおよびＹ座標からなる「ポイント」タイプを作成するようなより複雑な構造および動作を含む新しいタイプをユーザが作成できるように、データベースシステムのタイプシステムをユーザが拡張できるようにすることが望ましい。この点において、ＳＱＬ標準および一部のデータベース管理システム（ＤＢＭＳ:database management system）製品は、いくつかの形のタイプの拡張性を記述するのに「ユーザ定義タイプ(user-defined type)」という用語を用いている。たとえば、ＳＱＬ−９９標準は、既存のＳＱＬ組み込みデータタイプの値である内部表現をもつようにユーザによって定義することができるタイプである「区別(distinct)タイプ」について述べている。区別タイプは、比較および算術演算子、タイプの変換、ならびに集約（列）関数（たとえば、ｍａｘ、ｍｉｎ、ａｖｅｒａｇｅ）を、既存のスカラタイプと任意選択で共有することができる。区別タイプは、その値に対して制約を定義させることができる。さらに、区別タイプは、ユーザ定義関数により区別タイプ特有の新しい関数を定義することによって、既存のスカラタイプの動作を超える動作を公開することができる。タイプの検査に関して、区別タイプおよび既存スカラタイプは、異なるタイプであるとみなされる。
【００１４】
区別タイプ(distinct type)の利点は、容易に定義できることである。新しいタイプの内部表現が、既存の組み込みタイプを有して記述することができる１個のデータメンバーをもち、組み込みタイプが、新しいタイプにおいて必要とされる動作のほとんどを既に構築している場合、区別タイプは、魅力的な代替物である。ユーザは、タイプ、コンストラクタ、比較演算子（順序づけおよび索引づけに用いられる）、算術演算子、ならびにタイプの変換（キャスト）演算子のディスク上での格納を管理するのに必要とされる動作の構築について心配する必要がない。ユーザは、基底の組み込みタイプのどのような機能が、区別タイプにおいて公開される必要があるかを選び、任意選択で、新しいタイプにおける値または追加関数に対する制約を追加するだけでよい。区別タイプの別の利点は、ヒストグラムの計算など、組み込みタイプ用に利用可能なクエリ処理がすべて、区別タイプの列に対して容易に用いることができることである。ただし、区別タイプの欠点は、より複雑なタイプを作成するのには安易に用いることができないことである。
【００１５】
ＳＱＬ−９９標準はまた、ユーザによって定義することができるタイプであり、それぞれが異なるＳＱＬ内蔵タイプのメンバーでもユーザ定義タイプのメンバーでもよいデータメンバーからなるコレクションである、内部表現をもつ「構造タイプ(structured type)」について述べている。このタイプは、ＣおよびＣ＋＋におけるｓｔｒｕｃｔの概念に似ている。ＳＱＬ−９９は、構造タイプを定義するスタイルについて述べている。このスタイルを用いることにより、ユーザは、内部構造について構造タイプを定義するだけでよい。システムは、そのデータメンバー、コンストラクタ、および関数においてアクセス関数およびミューテータ関数を自動的に生成して、構造タイプのインスタンスのディスク上での表現を管理する。
【００１６】
ＳＱＬで定義される構造タイプに特有の利点は、（ａ）タイプの基本動作(basic behavior)の定義が容易であること、および（ｂ）より複雑なタイプを定義するための柔軟性である。しかし、構造タイプの重大な欠点は、通常、ＣやＣ＋＋のような汎用(general-purpose)プログラミング言語で書かれた外部関数により定義される、タイプ特有のメソッドの定義が複雑なことである。構造タイプを完全に定義するために、タイプを定義する人は、ＳＱＬと他の何らかのプログラミング言語との間の妥協点を探る必要がある。
【００１７】
ＳＱＬ９９の区別タイプ(distinct type)および構造タイプ(structured type)の特徴は、ユーザによるＳＱＬデータベースの既存スカラタイプシステム(existing scalar type system)の拡張(extend)を可能にすることによって、ユーザにある程度の利点をもたらすが、スカラタイプとして働くがより複雑な構造および動作を含むユーザ定義タイプによりデータベースシステムのスカラタイプシステムをユーザが拡張できるようにさせる、改良システムおよび方法が必要とされている。
【００１８】
２００４年２月１０日に出願した米国特許出願第１０／７７５，２８２号（整理番号ＭＳＦＴ−３０２９／３０７００７．０１）「SYSTEM AND METHOD FOR PROVIDING USER DEFINED TYPES IN A DATABASE SYSTEM」（これ以降、ＵＤＴ特許出願）において開示される発明は、スカラタイプとして働くがより複雑な構造および動作を含むユーザ定義タイプを作成することによって、ユーザがデータベースシステムのスカラタイプシステムを拡張することを可能にするシステムおよび方法を対象とする。この発明によると、ユーザは、ユーザ定義タイプのインスタンスにおいて呼び出すことができるユーザ定義タイプおよびメソッドの構造を定義するクラスを構築する高度なプログラミング言語でプログラムコードを書く。この発明（および本明細書）において用いられる「構造」という用語は、ユーザ定義タイプを参照するとき、そのタイプを構築するフィールドまたはプロパティの組を包含する。ＵＤＴ特許出願における各フィールドのタイプは、スカラＳＱＬタイプでも、予め定義されたどのユーザ定義タイプでもよい。ユーザ定義タイプを定義するクラスは次いで、コンパイルされ、データベースシステムに登録される。具体的には、ユーザ定義タイプを定義するＣＬＲクラスは、コンパイルされてアセンブリになることができ、このアセンブリは次いで、ＣＲＥＡＴＥ  ＡＳＳＥＭＢＬＹデータ定義ステートメントによりデータベースシステムに登録される。アセンブリが登録された後、ユーザは、ＣＲＥＡＴＥ  ＴＹＰＥデータ定義ステートメントを用いて、ユーザ定義タイプを定義するアセンブリにクラスを登録することができる。
【００１９】
ＵＤＴ特許出願の発明の場合、データベースシステムは、ユーザ定義タイプがＳＱＬタイプシステムにおいてスカラとして働くことを可能にするためにクラスが構築しなければならないある特定のコントラクトを強制する。この発明（および本明細書）において用いられる「コントラクト(contract)」という用語は、実行されるコードが、正しく実行されることを確かめるために、特定の前提条件または要件を満たすことを調べるためにオブジェクト指向プログラミング環境において実行時に利用される技術を指す。この発明によると、ユーザ定義タイプを定義するクラスと比較されるコントラクトは、いくつかの要件を含む。第１に、クラスは、データベースストア中でユーザ定義タイプであるインスタンスを保持する複数の異なるフォーマットの１つを指定しなければならない。第２に、クラスは、ユーザ定義タイプに対してヌル値を返すことができなければならない。第３に、クラスは、ユーザ定義タイプとストリングタイプなど別のタイプとの間で変換を行う方法を提供しなければならない。こうした要件が満たされると、データベースシステムは、ユーザ定義タイプであるインスタンスを作成することを可能にする。この出願の一実施形態では、ユーザ定義タイプは、テーブルの列の値、変数、ルーチンのパラメータ、またはルーチンの戻り値としてインスタンス化することができる。データベースシステムは、ユーザ定義タイプを定義するクラスについてのメタデータを、そのタイプであるインスタンスの作成において後で使うために格納する。この発明の別の実施形態では、ユーザ定義タイプのコントラクトの検証は、そのタイプを定義するクラスを記述するメタデータを用いて実施される。
【００２０】
ユーザ定義タイプのインスタンスを保持する、異なる複数のフォーマットは、データベースシステムのネイティブフォーマットに従ってユーザ定義タイプのインスタンスが自動的にシリアル化される第１のフォーマットと、ユーザ作成クラスによって定義されたやり方でユーザ定義タイプのインスタンスがシリアル化される第２のフォーマットとを含む。さらに、ＵＤＴ特許出願の発明が、ＭＩＣＲＯＳＯＦＴ．ＮＥＴ  ＣＬＲが統合されているＭＩＣＲＯＳＯＦＴ  ＳＱＬサーバ内で実施されるとき、ＭＩＣＲＯＳＯＦＴ．ＮＥＴフレームワークによって提供される方法に従ってユーザ定義タイプのインスタンスがシリアル化される第３のフォーマットが利用可能である。
【００２１】
ＵＤＴ特許出願の発明の場合、データベースシステムの照会言語における表現は、ユーザ定義タイプのインスタンス（群）への１つまたは複数の参照を含むことができ、そうすることによって、表現の評価がユーザ定義タイプのインスタンスにおけるメソッドの呼び出しを必要とするようになる。データベースシステムは、このような照会言語表現を受け取ると、その表現を、一連のプログラムコード命令に翻訳する。こうした命令は、実行されると、ユーザ定義タイプのインスタンスにおける、必要とされるメソッドを呼び出す。データベースシステムは次いで、照会言語表現を評価した結果として、メソッド呼び出しの結果を返す。一実施形態では、ユーザ定義タイプのインスタンスは、インスタンスにおけるメソッドの呼び出しに先立ってシリアル化解除(deserialize)される。
【００２２】
この発明の別の特徴は、ミューテータメソッドの呼び出しによってユーザ定義タイプのインスタンスの値を変更できることである。具体的には、ユーザ定義タイプを定義するクラスのオーサーは、クラスの一部としてミューテータメソッドを含む。ユーザ定義タイプのインスタンスにおいて呼び出されると、ミューテータメソッドは、ユーザ定義タイプの値を変更することを可能にする。このプロセスは、ユーザ定義タイプのインスタンスをシリアル化解除し、インスタンスのシリアル化解除されたデータの値を変更するためにミューテータメソッドを呼び出し、次いで、変更を保持するために、修正されたユーザ定義タイプのインスタンスをシリアル化することを含むことができる。
【００２３】
この発明の別の特徴は、ユーザ定義タイプインスタンスのシリアル化されたバイナリ表現がバイナリ順となることを指定する属性を、ユーザ定義タイプを定義するクラスがさらに含むことができることである。この特徴により、ユーザ定義タイプのインスタンスに対してバイナリ比較を行うことができるようになり、ユーザ定義タイプのインスタンスに対して索引づけを実施することもできるようになる。具体的には、バイナリ順であるユーザ定義タイプのインスタンスの場合、そのタイプの２つのインスタンスの何らかの比較（たとえば、＞、＜、または＝）を必要とする照会言語表現が、データベースシステムによって受け取られると、この２つのインスタンスのシリアル化されたバイナリ表現は、どちらのインスタンスもシリアル化解除することなく、その表現を評価するのに使うことができる。さらに、バイナリ順であるユーザ定義タイプの場合、ユーザ定義タイプとして定義された列をもつ、データベースストア中のテーブルを作成することができる。次いで、列に対して索引を作成することができる。索引は、ユーザ定義タイプを参照する照会言語表現に対して作成することもできる。この場合、表現に対して計算された列が最初に生成され、次いで、計算された列に対して索引が作成される。
【００２４】
コレクション(collection)
データ量の多いアプリケーションは、現実世界の部分を取り込むのにオブジェクトデータモデルを用いる（「オブジェクトデータモデリング(object data modeling)」としても知られる）。エンティティ(entity)（たとえば、項目に基づくハードウェア／ソフトウェアインターフェイスシステムにおける「項目(item)」）および関係は、２つの共通データモデル構成である。たとえば、作成者およびドキュメントが、２つのタイプのエンティティである場合、作成者とドキュメントの間には、いくつか例を挙げると、「すべてのドキュメントがある作成者によって書かれた」および「すべてのドキュメントがある作成者によって見直された」など、いくつかの関係が存在し得る。
【００２５】
エンティティは、スカラ値および／またはコレクション値（もしくは組の値）でよい１組のプロパティを含む。たとえば、作成者エンティティは、作成者の名前および誕生日に関するスカラ値プロパティ、ならびに作成者の１組のアドレスならびに１組の電話番号に関するコレクション値プロパティを含むことができる。スカラ値プロパティのような、こうしたコレクション値プロパティは、エンティティに組み込まれる。つまり、そのエンティティの一部とみなされ、単にそのエンティティから別のエンティティへ定義された関係ではない。こうしたコレクション（別名「組み込みコレクション(embedded collection)」）はそれぞれ、通常、少数のメンバー（または「要素(element)」）を含み、いくつかの例では、こうしたコレクションのメンバーは、重要度(importance)の相対順序(relative order)をもつことができる（たとえば、作成者が主アドレス、副アドレスをもつ場合、など）。本明細書で使用する順序なしコレクションは、「多重集合(multiset)」と呼ばれ、順序つきコレクション(ordered collection)は、コレクション中のメンバーの相対順序(relative order)をさらに明らかにする多重集合の拡張である「リスト(list)」と呼ばれる。
【００２６】
拡張可能リレーショナルデータストア(extendable relational data store)
コレクション(collection)は、既存データベース製品(existing database product)に実装(implement)されているが、こうした製品は一般に、一次キー(primary key)−外部キー(foreign key)という概念(concept)など、値に基づく関係を用いてコレクションをモデル化し、このようなものであるために、リレーショナル照会可能オブジェクトとして扱うことができない。さらに、コレクションはリレーショナル照会可能オブジェクトではないので、たとえば「Ｘ市に住むすべての人の連絡先を返す」ための、コレクションへのクエリは概して、コレクションのパスすべてを巡回する必要がある。
【００２７】
拡張可能リレーショナルデータストア（ＥＲＤＳ: (extendable relational data store)）とは、ＵＤＴの構築(implementation of UDTs)を記述している、２００４年２月１０日に出願した米国特許出願第１０／７７５，２８２号（整理番号ＭＳＦＴ−３０２９／３０７００７．０１）「SYSTEM AND METHOD FOR PROVIDING USER DEFINED TYPES IN A DATABASE SYSTEM」において説明されているユーザ定義タイプ（ＵＤＴ）としてエンティティがモデル化されることを可能にするリレーショナルデータストアである。ＥＲＤＳでは、こうしたコレクションをユーザ定義タイプ（ＵＤＴ）の一部としてモデル化することがより自然であり便利であろう。ＵＤＴにおいて、コレクションＵＤＴは、そうすることが適切な場合、スカラおよびリレーション両方として扱うことができよう。
【発明の開示】
【発明が解決しようとする課題】
【００２８】
したがって、当該分野において、ＥＲＤＳにおけるＵＤＴの一部、ならびにスカラとして処理することもリレーションとして照会することもできるコレクションとして、コレクションをモデル化する方法が必要である。
【課題を解決するための手段】
【００２９】
本発明のいくつかの実施形態は、拡張リレーショナルデータストア（ＥＲＤＳ:extendable relational data store）のＵＤＴフレームワークを、順序なしコレクション（多重集合）および順序つきコレクション（リスト）のサポートを含むように拡張するシステムおよび方法を対象とする。より詳細には、本発明のいくつかの実施形態では、ＵＤＴインフラストラクチャ(infrastructure)、ＣＬＲジェネリック(generic)、および新たなＵＮＮＥＳＴ演算子(operator)を用いて、同時にスカラ(scalar)であり且つリレーション(relation)である、コレクションの特別なタイプ(special type)の抽象化を作成し利用する。スカラとして、このコレクションタイプは、スカラを理解するデータストアエンジンのすべての部分（クライアントスタック(client stack)を含むがそれに限定されない）によって処理することができ、リレーションとして、このコレクションタイプ(collection type)は、他のどのタイプのリレーションのようにも照会可能(queriable)である。
【００３０】
本発明の様々な実施形態は、スカラでありかつリレーションであるコレクションタイプを含むデータストアを対象とする。こうした実施形態の一部の場合、本方法は、（ａ）本質的にデータストアエンジン(data store engine)のスカラタイプシステム(scalar type system)にスカラとして登録されるコレクションタイプのための抽象化ＵＤＴ(UDT abstraction)を作成すること、および（ｂ）必要に応じて、リレーショナル照会可能オブジェクト(relational queriable object)としてコレクション(collection)を照会(query)するために前記コレクションをネスト解除(unnesting)することを含む。
【００３１】
本発明のいくつかの実施形態は、前記コレクションに適用されるスカラ演算(scalar operation)のためにスカラとして処理され、前記コレクションに適用されるクエリ操作(query operation)のためにリレーションとして照会される、リレーショナルデータストア中のエンティティのための拡張コレクションを対象とする。こうしたある実施形態の場合、リレーショナルストア(relational store)は、拡張可能リレーショナルデータストア(extendable relational data store)であり、前記コレクションは、共通言語ランタイム（ＣＬＲ:common language runtime）においてジェネリックユーザ定義タイプ(generic user-defined type)から派生されると共に、（ＳＱＬスカラタイプシステムでは）ＳＱＬスカラタイプ(SQL scalar type)でもある。こうした実施形態のいくつかでは、コレクションに対応するコレクションタイプ(collection type)およびユーザ定義タイプ(user-defined type)の両方をリレーショナルデータストアに登録(register)することが必要である。さらに、特定の実施形態では具体的には、前記コレクションに対してネスト解除演算(unnesting operation)を用いて、前記コレクションを、第１の列(column)を含むリレーショナル照会可能オブジェクト(relational queriable object)に変換し、前記第１の列の各行は、前記コレクションの単一のメンバー(single member)に対応する（すなわち、多重集合(multiset)用のコレクション）。他の実施形態は、第２の列をさらに含み、前記第２の列の各行(row)は、前記コレクションの単一のメンバーに対応し、（リスト用の）前記順序つきコレクション(ordered collection)中の前記各メンバーの順序に対応する値をもつ。いくつかの特定の実施形態の場合、多重集合(multiset)およびリスト(list)の両方は、同じ２列のリレーショナル照会可能オブジェクトを用いる（第２の列は、順序が重要でない場合は多重集合に関しては単に無視される）。
【００３２】
添付の図面と併せ読むことによって、上述の要約、ならびに好ましい実施形態の以下の詳細な説明がよりよく理解されよう。ただし、本発明は、開示する特定の方法および手段に限定されるものではない。
【００３３】
本出願は、その内容全体が参照により本明細書に組み込まれている、２００４年４月３０日に出願した米国特許仮出願第６０／５６６，７４０号（整理番号ＭＳＦＴ−３９４０／３０７２２８．０１）「SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF MULTISETS IN A DATABASE SYSTEM」の利益を主張する。さらに、本出願は、その内容が参照により本明細書に組み込まれている、２００４年２月１０日に出願した米国特許出願第１０／７７５，２８２号（整理番号ＭＳＦＴ−３０２９／３０７００７．０１）「SYSTEM AND METHOD FOR PROVIDING USER DEFINED TYPES IN A DATABASE SYSTEM」の一部継続出願である、２００４年５月３日に出願した米国特許出願第１０／８３７，９２９号（整理番号ＭＳＦＴ−３８４３／３０７２２７．０１）「SYSTEMS AND METHODS FOR SUPPORTING INHERITANCE FOR USER-DEFINED TYPES」の一部継続出願でもある。
【００３４】
本出願は、その内容全体が参照により本出願に組み込まれている、本発明の譲受人に譲渡された出願、すなわち２００４年４月９日に出願した米国特許出願第１０／８２１，６８７号（整理番号ＭＳＦＴ−２９５５／３０７０６４．０１）「SYSTEMS AND METHODS FOR FRAGMENT-BASED SERIALIZATION」、２００３年１０月２３日に出願した米国特許出願第１０／６９２，２２５号（整理番号ＭＳＦＴ−２８５２／３０６８１９．０１）「SYSTEM AND METHOD FOR OBJECT PERSISTENCE IN A DATABASE STORE」、および２００４年３月８日に出願した米国特許出願第１０／７９５，６２３号（整理番号ＭＳＦＴ−２９６０／３０７２３２．０１）「STRUCTURED INDEXES ON RESULTS OF FUNCTION APPLICATIONS OVER DATA」で開示される発明に対象が関連する。
【発明を実施するための最良の形態】
【００３５】
本発明を説明するために、本発明の例示的な構成を図面に示す。しかし、本発明は、開示する特定の方法および手段に限定されるものではない。
【００３６】
法的要件を満たすために、本発明の主題を明確に説明する。ただし、説明自体は、本特許の範囲を限定することを意図していない。本発明者は、特許請求の対象が、本文書において説明されるものと類似した、異なるステップまたは要素を含むように、現在または将来の他の技術と共に、他の方法でも実施されることを企図している。さらに、「ステップ(step)」という用語は、本明細書において、利用される方法の異なる要素を意味するのに用いられ得るが、この用語は、個々のステップの順序が明確に記述されない限り、本明細書において開示される様々なステップの間のいかなる具体的な順序も含意すると解釈すべきでない。
【００３７】
以下で説明する実施形態において、本発明の上記の特徴は、ＭＩＣＲＯＳＯＦＴ  ＳＱＬサーバデータベースシステムにおいて構築されるものとして説明していく。上述したように、ＳＱＬサーバは、マネージドコードがＳＱＬサーバデータベースのデータストアに対して作用するように書かれ実行されることを可能にするために、ＭＩＣＲＯＳＯＦＴ．ＮＥＴ共通言語ランタイム（ＣＬＲ）を組み込む。以下で説明する実施形態は、このコンテキストにおいて作用するが、本発明は、ＳＱＬサーバ製品での実施に決して限定されないことを理解されたい。そうではなく、本発明は、オブジェクトリレーショナル拡張を伴うオブジェクト指向データベースシステムおよびリレーショナルデータベースシステムなど、データベースストアに対して作用する、オブジェクト指向プログラミングコードの実行をサポートするどのデータベースシステムにおいても実施することができる。したがって、本発明は、以下で説明する特定の実施形態に限定されず、特許請求の範囲において定義される本発明の精神および範囲内であるすべての修正形態を包含することを意図していることを理解されたい。
【００３８】
コンピュータ環境(computer environment)
本発明の数多くの実施形態は、コンピュータ上で実行することができる。図１および以下の説明は、本発明を実施することができる適切なコンピューティング環境の簡潔かつ全体的な説明の提供を意図している。そうすることが必要なわけではないが、クライアントワークステーションやサーバなどのコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令という一般的な状況において本発明を説明する。概して、プログラムモジュールは、特定のタスクを実施し、または特定の抽象データタイプを構築(implement)するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、本発明は、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースの家電またはプログラム可能な家電、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなど他のコンピュータシステム構成と共に実施できることが当業者には理解されよう。本発明は、通信ネットワークを介してリンクされるリモート処理デバイスによって特定のタスクが実施される分散型コンピューティング環境でも実施することができる。分散型コンピューティング環境では、プログラムモジュールは、ローカルおよびリモートメモリ記憶装置両方に置くことができる。
【００３９】
図１に示すように、例示的な汎用コンピューティングシステムは、従来のパーソナルコンピュータ２０などを含み、このコンピュータは、処理ユニット２１、システムメモリ２２、およびシステムメモリなど様々なシステムコンポーネントを処理ユニット２１に結合するシステムバス２３を含む。システムバス２３は、様々なバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスなどいくつかのタイプのバス構造のいずれでもよい。システムメモリは、ＲＯＭ（読み出し専用メモリ）２４およびＲＡＭ（ランダムアクセスメモリ）２５を含む。ＢＩＯＳ２６（基本入出力システム）は、たとえば起動中にパーソナルコンピュータ２０内部の要素間の情報の転送を助ける基本ルーチンを含み、ＲＯＭ２４に格納される。パーソナルコンピュータ２０は、図示していないハードディスクからの読み出しおよびそこへの書き込みを行うハードディスクドライブ２７、取り外し可能磁気ディスク２９からの読み出しまたはそこへの書き込みを行う磁気ディスクドライブ２８、および、たとえばＣＤ  ＲＯＭや他の光学媒体などの取り外し可能光ディスク３１からの読み出しまたはそこへの書き込みを行う光ディスクドライブ３０をさらに含むことができる。ハードディスクドライブ２７、磁気ディスクドライブ２８、および光ディスクドライブ３０は、それぞれハードディスクドライブインターフェイス３２、磁気ディスクドライブインターフェイス３３、および光ドライブインターフェイス３４によって、システムバス２３に接続される。こうしたドライブおよびそれに関連するコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、および他のデータの不揮発性記憶をパーソナルコンピュータ２０にもたらす。本明細書で説明する例示的な環境は、ハードディスク、取り外し可能磁気ディスク２９、および取り外し可能光ディスク３１を使用するが、コンピュータによってアクセス可能なデータを格納することができる、コンピュータ可読である他のタイプの媒体も、例示的な動作環境において使うことができることを当業者は理解されたい。このような他のタイプの媒体として、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイカートリッジ、ＲＡＭ（ランダムアクセスメモリ）、ＲＯＭ（読み出し専用メモリ）なども、例示的な動作環境において使うことができる。
【００４０】
オペレーティングシステム３５、１つまたは複数のアプリケーションプログラム３６、他のプログラムモジュール３７、およびプログラムデータ３８などいくつかのプログラムモジュールを、ハードディスク、磁気ディスク２９、光ディスク３１、ＲＯＭ２４、またはＲＡＭ２５に格納することができる。ユーザは、キーボード４０などの入力デバイス、およびポインティングデバイス４２を介して、コマンドおよび情報をパーソナルコンピュータ２０に入力することができる。他の入力デバイス（図示せず）は、マイクロホン、ジョイスティック、ゲーム用パッド、衛星パラボラアンテナ、スキャナなどを含み得る。こうしたおよび他の入力デバイスはしばしば、システムバスに結合されるシリアルポートインターフェイス４６を介して処理ユニット２１に接続されるが、他のインターフェイス、たとえば並列ポート、ゲームポート、ＵＳＢ（ユニバーサルシリアルバス）によって接続することもできる。モニタ４７または他のタイプの表示デバイスも、ビデオアダプタ４８などのインターフェイスを介してシステムバス２３に接続される。モニタ４７に加え、パーソナルコンピュータは通常、他の周辺出力デバイス（図示せず）、たとえばスピーカおよびプリンタを含む。図１の例示的なシステムは、ホストアダプタ５５、ＳＣＳＩ（小型コンピューティングシステムインターフェイス）バス５６、およびＳＣＳＩバス５６に接続される外部記憶装置６２も含む。
【００４１】
パーソナルコンピュータ２０は、リモートコンピュータ４９など１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク接続された環境において動作することができる。リモートコンピュータ４９は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたは他の共通ネットワークノードでよく、通常、パーソナルコンピュータ２０に関連して上述した要素の多くまたはすべてを含むが、図１にはメモリ記憶装置５０のみを示してある。図１に示す論理接続は、ＬＡＮ（ローカルエリアネットワーク）５１およびＷＡＮ（ワイドエリアネットワーク）５２を含む。このようなネットワーク環境は、会社、企業規模のコンピュータネットワーク、イントラネットおよびインターネットにおいてよく見られる。
【００４２】
ＬＡＮネットワーク環境において使われる場合、パーソナルコンピュータ２０は、ネットワークインターフェイスまたはアダプタ５３を介してＬＡＮ５１に接続される。ＷＡＮネットワーク環境において使われる場合、パーソナルコンピュータ２０は通常、モデム５４、または、たとえばインターネットなどのワイドエリアネットワーク５２を介した通信を確立する他の手段を含む。モデム５４は、内部にあっても外部にあってもよく、シリアルポートインターフェイス４６を介してシステムバス２３に接続される。ネットワーク接続された環境では、パーソナルコンピュータ２０に関連して図示したプログラムモジュールまたはその一部は、リモートメモリ記憶装置に格納することができる。図示したネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立する他の手段も使用できることが理解されよう。
【００４３】
本発明の数多くの実施形態は、コンピュータによるシステムに特に適合すると想像されるが、本文書のどの部分も、本発明をこのような実施形態に限定することを意図していない。反対に、本明細書で使用する「コンピュータシステム」という用語は、デバイスが本質的に電子、機械、論理、または仮想であるかに関わらず、情報を格納し処理することができ、かつ／またはこのようなデバイス自体の動作または実行を制御するのに、格納された情報を使うことができるあらゆるデバイスを包含することを意図する。
【００４４】
ＵＤＴおよびマネージドコード(managed code)
図２は、ユーザ定義タイプ（ＵＤＴ:user defined type）のインスタンス(instance)のシリアル化(serialization)およびシリアル化解除(deserialization)を示すブロック図である。図に示すように、ＵＤＴのインスタンス(instance of UDT)が、メモリ中のインスタンスを表すオブジェクトのシリアル化を介して、ディスク上に保持される。アプリケーションが、ＵＤＴのインスタンスのメソッドを参照する述部または表現を含むクエリを生成すると、残された形のインスタンスがシリアル化解除され（「ハイドレーション(hydration)」とも呼ばれるプロセス）、ＣＬＲは、オブジェクトの格納された値を受け取るために完全なオブジェクト用にメモリを割り振る。ＣＬＲは次いで、アプリケーションまたはユーザが所望する動作を構築するオブジェクトにおいて、適切なメソッドを呼び出す。
【００４５】
本明細書において上で説明したように、ＵＤＴは、ＳＱＬサーバに登録されるアセンブリで構築される、マネージドタイプ(managed type)である。ＵＤＴは、テーブル定義、変数、およびパラメータを含むネイティブタイプ(native type)を使うことができるほとんどのコンテキストにおいて使うことができる。ＵＤＴコントラクトに従う、ＵＤＴで定義されるメソッド、プロパティ、およびフィールドは、Ｔ−ＳＱＬから呼び出すことができる。本質的に、ＵＤＴは、動作を有する単純なスカラであると仮定される。この仮定は、ＵＤＴによってサポートされる単純なプログラミングモデルおよびシリアル化レイアウトに反映される。この構造は、抽象化ＵＤＴのために使われて、単純なスカラではなく複合構造および動作を有するタイプであり得る「構造化タイプ(structured type)」を作成することができる。
【００４６】
コレクション(collections) - - 多重集合(multisets)
本発明の様々な実施形態は、同時にスカラ(scalar)でありリレーション(relation)である、つまり、スカラとして、（クライアントスタック(client stack)を含む）スカラを理解するデータストアエンジンのすべての部分の中を流れ、リレーションとして照会可能である、データストア抽象化(data store abstraction)（またはタイプ）を対象とする。こうした実施形態のいくつかでは、ＵＤＴインフラストラクチャ、ＣＬＲジェネリック、および新たなＵＮＮＥＳＴ演算子(operator)を同時に用いて、このような二元タイプ(dualistic type)を可能にする。
【００４７】
図３は、拡張可能リレーショナルデータストア（ＥＲＤＳ）が二元コレクションタイプ(dualistic collection type)を提供することを可能にする全般的な方法を示すプロセスフロー図である。このようなタイプのコレクションを構築するために、ステップ３０２において、ＣＬＲのジェネリック特徴(generics feature)が、ジェネリックタイプ、たとえばコレクション＜Ｔ＞を定義するのに用いられる。このタイプは、「システムＵＤＴ」（すなわち、ある場所で定義されると、自動的にすべてのデータベースにおいて利用可能になるＵＤＴ）として作成され、ＳＱＬスカラタイプシステムの第１のクラス部分である。このようなものとして、このタイプは、列定義、変数、関数の引数、および格納された手順パラメータなど、スカラタイプがサポートされるコンテキストすべてにおいて使うことができる。こうしたタイプは、スカラ表現評価コンテキスト(scalar expression evaluation context)においてもサポートされる。
【００４８】
ステップ３０４において、ジェネリックタイプは次いで、ジェネリックコレクションタイプの派生タイプ(derived type)としてのコンクリートコレクションタイプ(concrete collection type)、つまり、前記メンバーがもはやジェネリックではなく、スカラタイプまたは他の複合タイプ(complex type)として定義されるタイプを作成するのに用いることができる。この例では、コンクリートタイプはアドレス用であり、個々のメンバー(individual member)はスカラストリングタイプ(scalar string type)である。本発明の代替実施形態では、個々のメンバーは、スカラストリングタイプでなく、（番地用の）第１のストリング、（都市名用の）第２のストリング、（州用の）２つの文字、および（郵便番号用の）５桁の整数を含む複合タイプ(complex type)でもよい。
【００４９】
コレクションが、ある特定のタイプ(particular type)の要素(element)を含むように宣言(declare)されると、そのＵＤＴのサブタイプ(subtype)のどの値(value)も、そのコレクションに格納することができる（「代替可能(substitutability)」と呼ばれる）。コレクションタイプ(collection type)とその要素タイプ(element type)の間の関係は、タイプを作成する時(type creation type)にメタデータ(metadata)に記録され、照会可能なカタログビュー(queryable catalog view)を介して利用可能となり、こうすることにより、アプリケーションは、ある特定のコレクションタイプの代替可能範囲を判定するためのクエリを組み立てることができる。
【００５０】
ステップ３０６において、あるエンティティ自体がインスタンス生成されると、新たなコンクリートコレクションタイプ(concrete collection type)は、そのエンティティにおいてプロパティとして使うことができる。この時点で、順序コレクション(order collection)は、クエリが適用されない限り本質的にスカラプロパティ(scalar property)として扱われ、クエリが適用されると、データストアエンジン(data store engine)は、このコレクションタイプの特殊な特徴を認識(recognize)し、そのコレクションをリレーションとして処理する。
【００５１】
コレクションをナビゲート(navigate)するために、クエリは通常、「Ｘ市に住むすべての人について返す」などの質問に答えるために、コレクション中のパス(path)を巡回(traverse)する必要がある。ただし、本発明のいくつかの実施形態の場合、クエリエンジン(query engine)は、この特殊コレクションシステムタイプ、たとえば「Ｃｏｌｌｅｃｔｉｏｎ＜Ｔ＞」が、リレーションセマンティクス(relation semantics)ならびにＵＤＴに関連づけられたスカラセマンティクス(scalar semantics)の両方をもち、新たなリレーショナル演算子「ＵＮＮＥＳＴ」が、必要に応じてこのスカラをリレーショナル照会可能オブジェクト(relational queryable object)に変形するのに用いられる。この演算子は、テーブル値関数がサポートされるコンテキストすべてにおいてサポートされ、ＵＮＮＥＳＴ演算子を含むビュー定義が索引づけ可能である。
【００５２】
図４は、エンティティにおいてコレクションに適用されるクエリを処理する方法を示すプロセスフロー図である。ステップ４０２において、コレクションに対してクエリが作成され、このコレクションがコレクションでなかった場合、クエリはデータストアエンジンに対してＳＱＬエラーを生成するが、コレクションである場合、データストアエンジンは、ステップ４０４において、コレクションが特殊データタイプであると認識し、ステップ４０６において、コレクションをネスト解除(unnest)して、照会可能オブジェクトを作成する。このオブジェクトは、多重集合(multiset)用であり、この例では単列テーブル(single column table)である。ステップ４０８において、データストアエンジンは、クエリをこの照会可能オブジェクトに向け直す。
【００５３】
たとえば、図５は、照会されると、照会可能オブジェクト（単列テーブル）５１０’にネスト解除される組み込みフィールド(embedded field)５１０として、他のものの中でもアドレスの多重集合を有する構造化ＵＤＴ(structured UDT)である「Ｐｅｒｓｏｎ」エンティティ５００を示すブロック図である。Ｐｅｒｓｏｎに対するマネージドタイプ定義は、以下のようになる。
【００５４】
【表２】
0004728675.tif 000003
【００５５】
このタイプを作成するために、組み込みコレクションタイプが、以下のようにストアに最初に登録される。
【００５６】
【表３】
0004728675.tif 000004
【００５７】
次に、ｆｏｒｍａｔ．ｓｔｒｕｃｔｕｒｅｄ  ＵＤＴが以下のように登録される。
【００５８】
【表４】
0004728675.tif 000005
【００５９】
その後、アドレスの組をスカラとして返すために、以下のコマンドを使うことができる。
【００６０】
【表５】
0004728675.tif 000006
【００６１】
同様に、ＵＤＴおよび組み込みコレクション(embedded collection)においてメソッド(method)を呼び出す(invoke)ために、以下のコマンドを使うことができる。
【００６２】
【表６】
0004728675.tif 000007
【００６３】
アドレスがワシントン州であるすべての人を探すようにコレクションの中を照会するために、以下のコマンドを使うことができる。
【００６４】
【表７】
0004728675.tif 000008
【００６５】
また、その人のすべてのアドレスの州をワシントン州に変更するようにＰｅｒｓｏｎをアップデートするために、以下のコマンドを使うことができる。
【００６６】
【表８】
0004728675.tif 000009
【００６７】
同様に、コレクションにおいてミューテータメソッドを呼び出すために、以下のコマンドを使うことができる。
【００６８】
【表９】
0004728675.tif 000010
【００６９】
本発明の特定の実施形態の場合、構築の枠組み(implementation framework)は、システムＵＤＴ、ＣＬＲジェネリック、およびストリームテーブル値関数インフラストラクチャを利用するＵＮＮＥＳＴ演算を用いる。
【００７０】
システムＵＤＴは、ユーザ定義タイプ（ＵＤＴ）インフラストラクチャを用いて構築されるシステムタイプである。システムＵＤＴは、エンドユーザが作成したＵＤＴと、以下のように異なる。（ａ）システムＵＤＴは、すべてのデータベースにおいて利用可能であり、すべてのユーザがアクセス可能である。（ｂ）システムＵＤＴは、エンドユーザによって作成することも中断することもできない。（ｃ）システムＵＤＴは、システムにおいてそのような１つのタイプであるかのように、複数のデータベースに渡って使うことができる（すなわち、あるデータベース中のシステムタイプのインスタンスが、別のデータベースからも使用可能である）（「タイプの識別(type identity)」）。（ｄ）システムＵＤＴは、（Ｓｙｓｔｅｍ．Ｄａｔａ．ｄｌｌのように）「システム」アセンブリで構築することができ、このシステムアセンブリは、データベース以外の場所（たとえばディスク）からロードされるベースＣＬＲインフラストラクチャの一部でよい。（ｅ）システムＵＤＴは、ＳＹＳスキーマの一部であり、したがって、ユーザは、システムＵＤＴと同じ名前をもつ独自のＵＤＴを作成することができない。
【００７１】
ジェネリックは、コレクションクラスライブラリ(collection class library)（ＭｕｌｔｉＳｅｔ＜Ｔ＞など）用に使うことができるパラメータ化されたタイプ定義(parameterized type definition)であり、「ジェネリック多重集合(generic multiset)」をグローバルに一度定義し、その後、各「コンクリートインスタンス化(concrete instantiation)」（ＭｕｌｔｉＳｅｔ＜Ａｄｄｒｅｓｓ＞やＭｕｌｔｉＳｅｔ＜ＰｈｏｎｅＮｕｍｂｅｒ＞など）のためにタイプ安全な構築(type-safe implementation)を行うことを可能にする。言い換えると、ＭｕｌｔｉＳｅｔ＜Ｔ＞は、たとえば、ＵＤＴｅｘｔｅｎｓｉｏｎｓ．ｄｌｌにおいて一度定義されるジェネリックシステムＵＤＴである。
【００７２】
ＵＮＮＥＳＴ演算子は、ＭｕｌｔｉＳｅｔ＜Ｔ＞タイプの（またはそのＳＱＬタイプが別のコンクリート多重集合タイプである）ＵＤＴをとり、このＵＤＴを単列テーブルに変形し、前記列の各行は、前記コレクションのメンバーに対応し、したがって、前記コレクションのメンバーのオンザフライクエリおよびナビゲーションを可能にする。本発明のある実施形態の場合、バインディングプロセス(binding process)の間、ＵＮＮＥＳＴ演算によって生じた列用に、特殊な名前空間(namespace)が作成され、ＵＮＮＥＳＴ演算自体は、ストリーミングテーブル値化関数(streaming table valued function)となる。この最適化(optimization)により、スカラからリレーションへの、コレクションの変形が、データのコピーを介在せずに起こり得るようになる。この手法は、結果に対するストリームモデルも提供し、そうすることによって、冗長な具現化(redundant materialization)なしで結果が利用可能になる。（ストリーミングテーブル値化関数は、２００４年４月９日に出願した米国特許出願第１０／８２１，６８７号（整理番号ＭＳＦＴ−２９５５／３０７０６４．０１）「ＳＹＳＴＥＭＳ  ＡＮＤ  ＭＥＴＨＯＤＳ  ＦＯＲ  ＦＲＡＧＭＥＮＴ−ＢＡＳＥＤ  ＳＥＲＩＡＬＩＺＡＴＩＯＮ」に記載されている。
【００７３】
コレクション - - リスト
リストとは、コレクションのメンバーの順序(order)を取り込む(capture)ように拡張(extend)されたコレクションである。多重集合(multiset)と同様に、このタイプの値は、変数、パラメータ、戻り値(return value)および列定義(column definition)を含むスカラＵＤＴ値(scalar UDT value)が許可されるすべてのコンテキストにおいて使うことができる。リストは、本質的にスカラであるコレクション値をリレーションに変形するＵＮＮＥＳＴ関数と共に機能するが、ＵＮＮＥＳＴによってもたらされるリレーショナルスキーマ(relational schema)は、少なくとも２つの列をもち、一方の列は、メンバーを含み（１行ごとに１つのメンバー）、他方の列（または擬似列(pseudo-column)もしくは仮想列(virtual column)）は、前記リスト中の前記メンバーの相対順序(relative order)を指す値、たとえば、所与の要素の順序を含む。図６は、クエリが多重集合ではなくリストに向けられるときに作成される、図５からの照会可能オブジェクト５１０”を示す部分ブロック図である。また、多重集合の場合と同様に、ＴＳＱＬ  ＤＭＬは、リストタイプの値に対する配列アクセス演算をサポートするように拡張される。
【００７４】
直行行列(orthogonality matrix)のそれ以外の部分(rest)（データベース間コンテキストにおける変換行列および使用を含む）に関して、このタイプ用のコントラクトは、（本明細書において後で使用する）Ｆｏｒｍａｔ．Ｓｔｒｕｃｔｕｒｅｄ  ＵＤＴ用のものと同じであると仮定する。さらに、「リスト」は、ＳＱＬ９９標準で用いられているように「配列(array)」と呼ぶこともできる。
【００７５】
以下の例は、アドレスおよび電話番号用の２つのリスト値化プロパティ(list-valued property)を含む代替ＵＤＴ  Ｐｅｒｓｏｎクラスを示す。
【００７６】
【表１０】
0004728675.tif 000011
【００７７】
上記のＳｑｌＬｉｓｔ＜Ａｄｄｒｅｓｓ＞およびＳｑｌＬｉｓｔ＜Ｐｈｏｎｅ＞タイプは、新たなデータ定義言語（ＤＤＬ）ステートメントを用いて、ＳＱＬサーバに対して定義される。
【００７８】
【表１１】
0004728675.tif 000012
【００７９】
次いで、以下のステートメントが、Ｐｅｒｓｏｎテーブルの列をもつテーブルを作成する。
【００８０】
【表１２】
0004728675.tif 000013
【００８１】
このステートメントが完了すると、以下のように２つのアドレスおよび３つの電話番号を有するＰｅｒｓｏｎインスタンスを作成するのに、以下のステートメントを使うことができる。
【００８２】
【表１３】
0004728675.tif 000014
【００８３】
その後、Ｐｅｒｓｏｎｓテーブル中の、主アドレスがシアトルにある人すべての副アドレスおよびセル電話を以下のように照会することができる。
【００８４】
【表１４】
0004728675.tif 000015
【００８５】
繰り返しになるが、ＵＮＮＥＳＴは、引数としてリストをとり、各行がリストの各要素用である１組の行を生じるコンストラクトである。ＵＮＮＥＳＴは、２つの列を生じ、１列はメンバー要素用であり、もう１列はリスト中の各メンバーの相対順序（たとえば、要素の優先順位に対応する順序値）用である。
【００８６】
結論
本明細書で説明した様々なシステム、方法、および技術は、ハードウェアまたはソフトウェア、あるいはそうすることが適切な場合には、両方の組み合せを用いて実施することができる。したがって、本発明の方法および装置、あるいは本発明の特定の態様または部分は、実体のある媒体、たとえばフロッピー（登録商標）ディスケット、ＣＤ−ＲＯＭ、ハードドライブ、または他のどのマシン可読記憶媒体においても実施されるプログラムコード（すなわち、命令）の形をとることができ、プログラムコードがコンピュータなどのマシンにロードされると共にそれによって実行されると、マシンは本発明を実施する装置となる。プログラム可能なコンピュータ上でプログラムコードを実行する場合、コンピュータは概して、プロセッサ、プロセッサによって読取り可能な記憶媒体（揮発性、不揮発性メモリおよび／または記憶要素など）、少なくとも１つの入力デバイス、ならびに少なくとも１つの出力デバイスを含む。１つまたは複数のプログラムは好ましくは、高度な手続きタイププログラミング言語またはオブジェクト指向プログラミング言語で実施され、コンピュータシステムと通信する。ただし、プログラム（群）は、そうすることが望まれる場合、アセンブリでも機械言語でも構築することができる。いずれの場合でも、言語は、コンパイルタイプ言語でもインタープリトタイプ言語でもよく、ハードウェアの構築と組み合わせることができる。
【００８７】
本発明の方法および装置は、たとえば、電気的接続またはケーブル布線、光ファイバ、あるいは他のどの伝送の形でもよい何らかの伝送媒体を介して伝送されるプログラムコードの形で実現することもでき、プログラムコードが受信され、たとえばＥＰＲＯＭ、ゲートアレイ、ＰＬＤ（プログラム可能な論理回路）、クライアントコンピュータ、ビデオレコーダなどのマシンにロードされると共にそれによって実行されると、マシンは、本発明を実施する装置となる。汎用プロセッサで実施すると、プログラムコードは、プロセッサと結合して、本発明の索引づけ機能を実施するように動作する独自の装置を提供する。
【００８８】
様々な図面の好ましい実施形態に関連して本発明を説明したが、本発明から逸脱することなく本発明の同じ機能を実施するために、他の類似の実施形態を使用することもでき、説明した実施形態に修正および追加を行うことができることを理解されたい。たとえば、パーソナルコンピュータの機能をエミュレートするデジタルデバイスという状況で例示的な本発明の実施形態を説明したが、本発明は、このようなデジタルデバイスに限定されず、本出願において述べたように、有線または無線に関わらず、任意の数の既存または新興のコンピューティング装置または環境、たとえばゲーム用コンソール、ハンドヘルドコンピュータ、可搬タイプコンピュータなどにも当てはまり、通信ネットワークを介して接続され、ネットワーク経由で相互作用するこのような任意の数のコンピューティング装置に適用し得ることが当業者には理解されよう。さらに、ハンドヘルドデバイスのオペレーティングシステムおよび他のアプリケーション特有のハードウェア／ソフトウェアインターフェイスシステムを含む様々なコンピュータプラットフォームが本明細書において企図され、特に、無線ネットワーク接続された装置の数は増加し続けることを強調しておく。したがって、本発明は、どの１つの実施形態にも限定されるべきではなく、特許請求の範囲による範囲によって解釈されるべきである。
【図面の簡単な説明】
【００８９】
【図１】本発明を実施するためのコンピュータシステムを示すブロック図である。
【図２】マネージドコードでインスタンス化されたユーザ定義タイプのインスタンスのシリアル化およびシリアル化解除を示すブロック図である。
【図３】拡張可能リレーショナルデータストア（ＥＲＤＳ）が二元（スカラおよびリレーション）コレクションタイプを提供することを可能にする一般的な方法を示す処理フローチャートである。
【図４】エンティティにおいてコレクションに適用されるクエリを処理する方法を示すプロセスフローチャートである。
【図５】照会されると、照会可能オブジェクトにネスト解除される組み込みフィールドとして多重集合を有する構造化ＵＤＴであるエンティティを示すブロック図である。
【図６】多重集合ではなくリストに対してネスト解除される、図５の照会可能オブジェクトを示す部分ブロック図である。
【符号の説明】
【００９０】
２０  コンピュータ
２１  処理ユニット
２２  システムメモリ
２３  システムバス
２７  ハードドライブ
２８  フロッピー（登録商標）ドライブ
２９  取り外し可能記憶装置
３０  光ドライブ
３２  ハードディスクドライブＩ／Ｆ
３３  磁気ディスクドライブＩ／Ｆ
３４  光ドライブＩ／Ｆ
３６  アプリケーションプログラム
３６’  アプリケーション
３７  他のプログラム
３８  プログラムデータ
４０  キーボード
４２  マウス
４６  シリアルポートＩ／Ｆ
４７  モニタ
４８  ビデオアダプタ
４９  リモートコンピュータ（群）
５０  フロッピー（登録商標）ドライブ
５３  ネットワークＩ／Ｆ
５４  モデム
５５  ホストアダプタ
５６  ＳＣＳＩバス
６２  記憶装置
【図１】
0004728675.tif 000016
【図２】
0004728675.tif 000017
【図３】
0004728675.tif 000018
【図４】
0004728675.tif 000019
【図５】
0004728675.tif 000020
【図６】
0004728675.tif 000021