JP2006012155A - ユーザ定義型の指定されたメンバを遅延フェッチするシステムおよび方法 - Google Patents

Abstract

【課題】 ユーザ定義型（ＵＤＴ）の指定されたメンバを遅延フェッチするシステムおよび方法を提供すること。
【解決手段】 ユーザ定義型のいくつかのメンバを遅延可能メンバとして指定することができる。型の最初のフェッチ中、遅延可能メンバ無しで、型がデータベースから戻され、それによって貴重な処理能力を保護し、最初のフェッチの実行に必要な時間を低減することができる。要求に応じて、最初のフェッチ中に提供された他のメンバを戻すことなく、選択された遅延可能メンバを後でデータベースから再フェッチすることができる。
【選択図】 図７

Description

本発明はデータの取り出しおよび操作の分野に関し、より詳細には、ユーザ定義型の取り出しおよび操作に関する。

Ｍｉｃｒｏｓｏｆｔ ＳＱＬ ＳＥＲＶＥＲ（商標）は、広範な管理および開発のツール、強力な抽出、変換、およびロード（ＥＴＬ）ツール、ビジネスインテリジェンスおよび分析サービス、および他の機能を提供する総合的なデータベース管理プラットフォームである。最近、ＳＱＬ ＳＥＲＶＥＲ（商標）の２つの改良が実施された。第１に、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）．ＮＥＴ Ｆｒａｍｅｗｏｒｋ共通言語ランタイム（ＣＬＲ）をＳＱＬ ＳＥＲＶＥＲ（商標）データベースに統合し、第２に、ユーザ定義型（ＵＤＴ）と呼ばれる新しいオブジェクトを、ＣＬＲ環境においてマネージドコードで作成し、データベースストアに保持することができる。

ＣＬＲは、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴ Ｆｒａｍｅｗｏｒｋの中核であり、すべての．ＮＥＴコードの実行環境を提供する。したがって、ＣＬＲ内で稼働するコードは「マネージドコード」と呼ばれる。ＣＬＲは、ジャストインタイム（ＪＩＴ）コンパイル、メモリの割り振りおよび管理、型の安全性の実施、例外処理、スレッド管理およびセキュリティを含めて、プログラムの実行に必要な様々な機能およびサービスを提供する。ＣＬＲは、現在、．ＮＥＴルーチンの最初の呼び出し後にＳＱＬ ＳＥＲＶＥＲ（商標）によってロードされる。

以前のバージョンのＳＱＬ ＳＥＲＶＥＲ（商標）では、データベースプログラマは、サーバ側にコードを書き込むときはＴｒａｎｓａｃｔ−ＳＱＬの使用に限定されていた。Ｔｒａｎｓａｃｔ−ＳＱＬは、国際標準化機構（ＩＳＯ）および米国規格協会（ＡＮＳＩ）によって定義されるように、ユーザ定義クエリ言語の拡張である。データベース開発者は、Ｔｒａｎｓａｃｔ−ＳＱＬを使用して、データベースおよびテーブルを作成し、変更し、削除することができるとともに、データをデータベースに挿入し、データベースに格納されているデータを取り出し、変更し、削除することができる。Ｔｒａｎｓａｃｔ−ＳＱＬは、具体的には、直接構造データアクセスおよび操作用に設計されている。Ｔｒａｎｓａｃｔ−ＳＱＬは、データアクセスおよび管理では優れているが、Ｖｉｓｕａｌ Ｂａｓｉｃ．ＮＥＴおよびＣ＃のように本格的なプログラミング言語ではない。例えば、Ｔｒａｎｓａｃｔ−ＳＱＬは、アレイ、集合、ループごとのビットシフト、またはクラスをサポートしていない。

ＣＬＲがＳＱＬ ＳＥＲＶＥＲ（商標）データベースに統合されると、データベース開発者は、Ｔｒａｎｓａｃｔ−ＳＱＬだけでは達成できなかった、または達成が難しかったタスクを実行することができる。Ｖｉｓｕａｌ Ｂａｓｉｃ．ＮＥＴおよびＣ＃は、アレイ、ユーザ定義の例外処理、および集合の全面的なサポートを提供する現代的なプログラミング言語である。開発者は、ＣＬＲの統合を利用して、Ｖｉｓｕａｌ Ｂａｓｉｃ．ＮＥＴおよびＣ＃などの言語を使用することによって、より複雑なロジックを有し、計算タスクにより適しているコードを書き込むことができる。

ＣＬＲの統合に加えて、ＳＱＬ ＳＥＲＶＥＲ（商標）は、開発者がデータベースのスカラ型システムを拡張することができる新しい機構であるユーザ定義型（ＵＤＴ）のサポートも追加する。ＵＤＴは、アプリケーションアーキテクチャの観点から２つの重要な利益を提供する。つまりＵＤＴは、（クライアントおよびサーバにおいて）内部状態と外部の振る舞いとの間の強力なカプセル化を提供し、他の関連のサーバ機能との深い統合を提供する。ＵＤＴは、いったん定義されると、列定義、変数、パラメータ、関数結果、カーソル、トリガ、および複製を含めて、システム型をＳＱＬ ＳＥＲＶＥＲ（商標）で使用することができるすべての状況で使用することができる。

データベースサーバ上でＵＤＴを定義するプロセスは、次のように達成される。
ａ）ＵＤＴ作成の規則に従うクラスをマネージドコードで作成する
ｂ）ＣＲＥＡＴＥ ＡＳＳＥＭＢＬＹステートメントを使用してＵＤＴを含むアセンブリをサーバ上のデータベースにロードする
ｃ）マネージドコードＵＤＴを公開するＣＲＥＡＴＥ ＴＹＰＥステートメントを使用してデータベース内に型を作成する
この時点で、ＵＤＴをテ―ブル定義で使用することができる。

ＵＤＴ定義をマネージドコードで作成するとき、型は次の要件を満たしていなければならない。
ａ）直列化可能としてマーク付けされていなければならない
ｂ）SqlUserDefinedTypeAttributeを付す必要がある
ｃ）型はＩＮｕｌｌａｂｌｅインタフェースを実装することによってＮＵＬＬアウェア（ＮＵＬＬ ａｗａｒｅ）である必要がある
ｄ）型は引数を取らないパブリックコンストラクタ（ｐｕｂｌｉｃ ｃｏｎｓｔｒｕｃｔｏｒ）を有している必要がある
ｅ）型は、以下のメソッドを実装することによって文字列への、また文字列からの変換をサポートしている必要がある
１．Public String ToString()
２．Public Shared <type> Parse (SqlStrings)

参照によりその全体が本明細書に組み込まれている「System And Method For Object Persistence In A Database Store」という名称の同時係属の同一出願人による米国特許出願第１０／６９２，２２５号（米国特許出願公開第２００５００９１２２８号明細書）（特許文献１参照）では、ＵＤＴの別の特徴について説明しており、ＵＤＴのＣＬＲクラス定義のフィールドおよび振る舞いは、データベースストア内のＵＤＴのインスタンスのレイアウト構造を記述するストレージ属性で注釈が付けられる。具体的には、ＵＤＴを定義するＣＬＲクラスの各フィールドは、サイズ、精度、スケールなど、型のストレージファセット（ｓｔｏｒａｇｅ ｆａｃｅｔ）を制御するストレージ属性で注釈が付けられる。一実施形態では、これは、SqlUdtField()と呼ばれるカスタムストレージ属性で各フィールドに注釈を付けることによって達成される。この属性は、追加のストレージ指示（ｓｔｏｒａｇｅ ｄｉｒｅｃｔｉｖｅ）でフィールドに注釈を付ける。これらの指示は、オブジェクトがディスクに直列化されたときに実施される。さらに、ＣＬＲクラスで定義された管理されたすべての振る舞い（例えばフィールドの値を戻すためにＵＤＴオブジェクト上で呼び出すことができるメソッド）は、その管理された振る舞いの同等の構造上のアクセスパスを示す属性で注釈が付けられる。一実施形態では、このために使用されるカスタム属性はSqlUdtProperty()と呼ばれ、データベースサーバ（例えばＳＱＬ ＳＥＲＶＥＲ（商標））は、このカスタム属性で注釈が付けられたプロパティの実装が属性定義の一部として指定されたフィールドに委譲されると仮定する。これによってサーバは、インスタンスを作成して、それに対する振る舞いを呼び出すことなく、構造上プロパティへのアクセスを最適化することができる。

図１は、ＵＤＴを定義するＣＬＲクラスのコードリスト例を示している。示すように、ＣＬＲクラスは、上述したSqlUdtField()およびSqlUdtProperty()のカスタム属性で注釈が付けられている。具体的には、SqlUdtField()カスタム属性は、ＵＤＴクラス定義例のそれぞれのフィールドに注釈を付けるために５行、８行、３７行、および４９行に追加されている。SqlUdtProperty()カスタム属性は、クラスの管理されたそれぞれの振る舞いに注釈を付けるために１１行および２４行に追加されている。

ＵＤＴを定義するＣＬＲクラスは、次いでダイナミックリンクライブラリ（ｄｌｌ）にコンパイルされる。次いでコンパイルされたクラスを含むアセンブリは、次のＴ−ＳＱＬスクリプトコマンドを使用して作成することができる。

以下のＴ−ＳＱＬスクリプトコマンドは、次いでサーバ上でＵＤＴを作成するために使用することができる。

ＵＤＴがサーバ上で作成されると、次のように、ＵＤＴ型としてテーブルの属性を定義するテーブル（例えば「MyTable」）を作成することができる。

次のように新しい項目をテーブルに追加することができる。

次いでＵＤＴ式を、例えば次のようにクエリに使用することができる。
SELECT Item.ID, Item.Name FROM MyTable

ＣＬＲのＳＱＬ ＳＥＲＶＥＲ（商標）への統合、およびマネージドコードによりクラス定義からＵＤＴを定義する能力によって、アプリケーションは、マネージドコードクラスによって定義された型のオブジェクトをインスタンス化し、こうしたオブジェクトをＵＤＴとしてリレーショナルデータベースストアに保持することができる。さらに、ＵＤＴを定義するクラスは、その型のオブジェクトに特定の振る舞いを実装するメソッドを含むこともできる。したがってアプリケーションは、ＵＤＴとして定義された型のオブジェクトをインスタンス化し、それらに対する管理された振る舞いを呼び出すことができる。

ＵＤＴとして定義されたクラスのオブジェクトがＣＬＲでインスタンス化されたとき、オブジェクトは、クラスの変数の値が物理的ストレージ（ハードディスクなど）に転送されるオブジェクト直列化のプロセスを介してデータベースストアで保持することができる。図２は、ディスク上のその保持されたフォームへのメモリ内オブジェクトの直列化を示している。オブジェクトは、図３に示したフォーマットの従来のリレーショナルデータベーステーブル内のデータベースストアで保持することができる。図に示すように、テーブルは、指定されたＵＤＴの列を含む。指定されたＵＤＴの保持されたオブジェクトの直列化された値は、ＵＤＴ列のセルを占める。

再度図２を参照すると、アプリケーションがデータベースストアに保持されているＵＤＴオブジェクトの管理された振る舞い（例えば、ＵＤＴオブジェクトのフィールドの値を戻す振る舞いなど）を参照する述語または式を含むクエリを生成すると、保持されたオブジェクトを直列化復元する（時として「ハイドレーションを行う（ｈｙｄｒａｔｉｎｇ）」とも呼ばれる）必要があり、ＣＬＲは、その格納された値を受信するために、全オブジェクトにメモリを割り振る必要がある。次いでＣＬＲは、クエリのサブジェクトである値を戻すＵＤＴクラスの実際のメソッド（すなわち振る舞い）を呼び出す必要がある。上記の同時係属の特許出願公開第１０／６９２，２２５号明細書に記載したように、ＵＤＴのＣＬＲクラス定義でのSqlUdtField()およびSqlUdtProperty()の注釈をデータベースサーバが使用して、オブジェクトのハイドレーションの必要無しにいくつかのＵＤＴフィールドの値への直接構造アクセスを可能にすることもできる。

ＣＬＲの統合、およびＳＱＬ ＳＥＲＶＥＲ（商標）でのＵＤＴの提供を利用する新しい技術は、２００３年８月２１日に出願した「Storage Platform For Organizing, Searching, And Sharing Data」という名称の同時係属の同一出願人による米国特許出願第１０／６４６，６４６号（米国特許出願公開第２００５００５００５４号明細書）（特許文献２参照）に記載されているストレージプラットフォームである。図４は、この同時係属の出願に記載したストレージプラットフォーム３００のアーキテクチャを示すブロック図である。ストレージプラットフォームは、時として「ＷｉｎＦＳ」と呼ばれることがある。図４に示すように、ストレージプラットフォーム３００は、データベースエンジン３１４に実装されたデータストア３０２を含む。一実施形態では、データベースエンジンは、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ ＳＥＲＶＥＲ（商標）リレーショナルデータベースエンジンなど、リレーショナルデータベースエンジンを含む。

データストア３０２は、以下により完全に説明するように、Ｉｔｅｍのフォームのデータ内の構成、検索、共有、同期、およびセキュリティ、および項目間の関係をサポートするデータモデル３０４を実装する。以下でより完全に説明するように、Ｉｔｅｍの特定の型は、例えばスキーマ３４０などのスキーマで記述されており、ストレージプラットフォーム３００は、こうしたスキーマを配置し、拡張するツール３４６を提供する。

データストア３０２内に実装されている変更追跡機構３０６は、データストアへの変更を追跡する機能を提供する。また、データストア３０２は、セキュリティ機能３０８および上位変換／下位変換機能（ｐｒｏｍｏｔｉｏｎ／ｄｅｍｏｔｉｏｎ ｃａｐａｂｉｌｉｔｙ）３１０も提供する。データストア３０２は、他のストレージプラットフォームの構成要素、およびストレージプラットフォームを使用するアプリケーションプログラム（例えばアプリケーションプログラム３５０ａ、３５０ｂ、および３５０ｃ）にデータストア３０２の機能を公開する１組のアプリケーションプログラミングインタフェース３１２も提供する。

ストレージプラットフォームは、アプリケーションプログラム３５０ａ、３５０ｂ、および３５０ｃなどのアプリケーションプログラムがストレージプラットフォームの機能にアクセスし、データベースに格納されているデータにアクセスできるようにするアプリケーションプログラミングインタフェース（ＡＰＩ）３２２をさらに含む。ストレージプラットフォームＡＰＩ３２２は、ＯＬＥ ＤＢ ＡＰＩ３２４およびＭｉｃｒｏｓｏｆｔ ＷＩＮＤＯＷＳ（登録商標）Ｗｉｎ３２ ＡＰＩ ３２６など他のＡＰＩとの併用でアプリケーションプログラムによって使用することができる。

ストレージプラットフォーム３００は、ユーザまたはシステム間でのデータの共有を容易にする同期サービス３３０を含めて、アプリケーションプログラムに様々なサービス３２８を提供することもできる。例えば、同期サービス３３０は、データストア３０２と同じフォーマットを有する他のデータストア３４０との相互運用性を可能にするとともに、他のフォーマットを有するデータストア３４２へのアクセスを可能にすることができる。また、ストレージプラットフォーム３００は、ＷＩＮＤＯＷＳ（登録商標）ＮＴＦＳ（New Technology File System）ファイルシステム３１８など、既存のファイルシステムとのデータストア３０２の相互運用性を可能にするファイルシステム機能も提供する。

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

少なくとも一部の実施形態では、ストレージプラットフォームは、コンピュータシステムのハードウェア／ソフトウェアインタフェースシステムに組み込まれ、またはその切り離すことのできない部分を形成する。例えば、それだけには限定されないが、本発明のストレージプラットフォームは、オペレーティングシステム、仮想マシンマネージャ（ＶＭＭ）、共通言語ランタイム（ＣＬＲ）またはその機能的等価物、Ｊａｖａ（登録商標）仮想マシン（ＪＶＭ）またはその機能的等価物に組み込む、またはその切り離すことのできない部分を形成し得る。

その共通のストレージ基盤および組織的に配列されたデータを介して、ストレージプラットフォームは、消費者、知識労働者、および企業にとってより効率的なアプリケーション開発を可能にする。そのデータモデルに固有の機能を利用可能にするだけではなく、既存のファイルシステムおよびデータアクセスメソッドを含み、拡張する豊富な拡張可能なプログラミングサーフェスを提供する。

以下の説明、および図の様々なものにおいて、本発明のストレージプラットフォーム３００を「ＷｉｎＦＳ」と呼ぶ場合がある。しかし、ストレージプラットフォームを指すこの名前の使用は、単に説明を簡潔にするためのものにすぎず、決して限定を意図するものではない。

ＷｉｎＦＳプラットフォームのデータモデルは、Ｉｔｅｍ、Ｉｔｅｍの拡張、およびＲｅｌａｔｉｏｎｓｈｉｐに関してデータストレージの単位を定義する。「Ｉｔｅｍ」は、記憶情報の基本単位である。データモデルは、ＩｔｅｍおよびＩｔｅｍの拡張を宣言し、Ｉｔｅｍ間の関係を確立する機構を提供する。Ｉｔｅｍは、コピー、削除、移動、開くなどの操作を使用して格納し、取り出すことができる単位である。Ｉｔｅｍは、（あらゆる種類の）Ｃｏｎｔａｃｔ、Ｐｅｏｐｌｅ、Ｓｅｒｖｉｃｅ、Ｌｏｃａｔｉｏｎ、Ｄｏｃｕｍｅｎｔなど、現実の世界の容易に理解可能なデータの単位を表すためのものである。Ｉｔｅｍの拡張は、既存のＩｔｅｍの定義を拡張する方法であり、ＲｅｌａｔｉｏｎｓｈｉｐはＩｔｅｍ間の定義されたリンクである。

ＷｉｎＦＳでは、情報を格納するために異なるＩｔｅｍ型が定義される。例えば、Ｃｏｎｔａｃｔ、Ｐｅｏｐｌｅ、Ｌｏｃａｔｉｏｎ、ＤｏｃｕｍｅｎｔなどのＩｔｅｍ型が定義される。各Ｉｔｅｍ型は、所与のＩｔｅｍのプロパティおよび特徴を定義するスキーマによって記述される。例えば、「Ｌｏｃａｔｉｏｎ」Ｉｔｅｍは、ＥＡｄｄｒｅｓｓ、ＭｅｔｒｏｐｏｌｉｔａｎＲｅｇｉｏｎ、Ｎｅｉｇｈｂｏｒｈｏｏｄ、およびＰｏｓｔａｌＡｄｄｒｅｓｓなどのプロパティを有するものとして定義することができる。所与のＩｔｅｍ型のスキームが定義されると、配置ツールを使用してそのスキーマがそのＩｔｅｍ型の対応するＣＬＲクラス定義に変換され、次いでＷｉｎＦＳ Ｉｔｅｍ型のインスタンスをデータベースストアに維持するために、（上述したように）データベースストアでＣＬＲクラス定義からＵＤＴが作成される。ＷｉｎＦＳ ＡＰＩ３２２を使用すると、アプリケーション（例えばアプリケーション３５０ａ、３５０ｂ、３５０ｃなど）は、ストレージプラットフォームのデータストアに情報を格納し、そこから情報を取り出すために、データストアによってサポートされているＩｔｅｍ型のインスタンスを作成することができる。データストアに格納されているＩｔｅｍ型の各インスタンスは、それに関連付けられている一意の識別子（例えばＩｔｅｍ＿ＩＤ）を有し、一実施形態では、各項目識別子は、グローバルに一意の識別子、すなわち「ｇｕｉｄ」である。したがってＷｉｎＦＳプラットフォームは、ＣＬＲの統合およびデータベースストアのＵＤＴ機能を利用して、情報のＩｔｅｍを格納するプラットフォームを提供する。

ＳＱＬ ＳＥＲＶＥＲ（商標）でのＵＤＴの任意のインスタンスと同様に、ＷｉｎＦＳ Ｉｔｅｍのインスタンスは、最終的に図３に示したやり方でデータベースストアのテーブルに格納される。次いでアプリケーションは、検索基準を満たすＩｔｅｍをデータストアで検索し、そこから取り出すためのクエリをＷｉｎＦＳプラットフォームに発信する。図５は、「Ｐｅｒｓｏｎ」と呼ばれるＩｔｅｍ型のインスタンスを取り出すためのクエリがデータストアに対してどのように実行されるかを示している。ステップ（１）で、アプリケーションは、ＷｉｎＦＳ ＡＰＩ３２２の「ＦｉｎｄＡｌｌ」メソッドを使用して、この場合は型の「Ｂｉｒｔｈｄａｙ」フィールド内の値が特定の日にち（例えば１９９９年１２月３１日）より大きいＰｅｒｓｏｎ型のすべてのインスタンスという特定の検索基準を満たすすべてのＩｔｅｍのクエリをインスタンス化する。ステップ（２）で、ＷｉｎＦＳ ＡＰＩ３２２は、「ＦｉｎｄＡｌｌ」操作をＳＱＬクエリに変換し、それを基礎となるデータベースエンジン、例えばＳＱＬ ＳＥＲＶＥＲ（商標）に発信する。ステップ（３）で、データベースエンジンは、Ｐｅｒｓｏｎ ＵＤＴの対応するインスタンスに対するクエリを実行し、Ｐｅｒｓｏｎ ＵＤＴの一致するインスタンスごとに格納された値を戻す。この例では、ステップ（４）で、ＡＤＯ．Ｎｅｔは、データベースストアから戻されたビットをＣＬＲオブジェクトに変え（すなわち上述したオブジェクトのハイドレーションのプロセス）、それらをＷｉｎＦＳ ＡＰＩ３２２に戻す。ＡＤＯ．Ｎｅｔは、ＳＱＬ ＳＥＲＶＥＲ（商標）など、データソースへのＣＬＲを介したマネージドコードアクセスを提供するＭｉｃｒｏｓｏｆｔ．ＮＥＴ Ｆｒａｍｅｗｏｒｋの構成要素である。次いでＷｉｎＦＳ ＡＰＩは、Ｐｅｒｓｏｎ ＵＤＴオブジェクトをラップし、それらをＰｅｒｓｏｎ型のＩｔｅｍとしてアプリケーションに戻す。

ＵＤＴの各インスタンスは、例えばデジタルイメージ、ビデオ、音声など、大きいオブジェクトを表すいくつかのメンバを含み得る。こうした大きいオブジェクトは、通常、例えばＢＬＯＢ、ＣＬＯＢ、およびＮＣＬＯＢなどのデータ型インスタンスに格納され、より具体的には、ｖａｒｂｉｎａｒｙ（ｍａｘ）、ｖａｒｃｈａｒ（ｍａｘ）、ｎｖａｒｃｈａｒ（ｍａｘ）に格納される。データベースからの多数のメンバの取り出しは、かなりの時間および多大な処理能力（bandwidth）を必要とする。さらに、ＵＤＴ取り出し使用のシナリオの大部分は、多数の埋め込みメンバへのアクセスを必要としない。

米国特許出願公開第２００５００９１２２８号明細書 米国特許出願公開第２００５００５００５４号明細書

したがってこの分野では、ＵＤＴの指定されたメンバを遅延フェッチするシステムおよび方法が必要である。こうしたシステムおよび方法は、指定されたメンバ無しで、ＵＤＴを最初にフェッチすることができ、指定されたメンバを後で要求に応じて再フェッチできることが望ましい。

本発明は、このような状況に鑑みてなされたもので、その目的とするところは、ユーザ定義型の取り出しおよび操作を効率的に行うことができる、ユーザ定義型の指定されたメンバを遅延フェッチするシステムおよび方法を提供することにある。

本発明は、上述の要求および他の要求を満たす。

本発明は、ユーザ定義型（ＵＤＴ）の指定されたメンバを遅延フェッチするシステムおよび方法を対象とする。指定されたメンバは、例えばデジタルイメージ、ビデオ、音声などの大きいオブジェクトとすることができる。本発明によれば、データベースサーバからＵＤＴを最初にフェッチすると、指定されたメンバが取り除かれたＵＤＴの直列化バージョンが戻され、それによって貴重な処理能力が保護され、最初のフェッチの実行に必要な時間が低減する。要求に応じて、後で指定されたメンバをデータベースサーバから再フェッチし、最初のフェッチ中に提供された他のＵＤＴメンバ無しで戻すことができる。

本発明の一態様によれば、最初のフェッチは、基礎となるデータベース内のＵＤＴへのパスを特定するＵＤＴコンテナ参照（ＵＤＴ ｃｏｎｔａｉｎｅｒ ｒｅｆｅｒｅｎｃｅ）を生成することによって実行することができる。ＵＤＴの直列化表現をデータベースから取り出し、指定されたメンバを直列化表現から取り除くことができる。次いでコンテナ参照が直列化表現の前に付けられ、直列化表現をクライアントアプリケーションに戻すことができる。

本発明の別の態様によれば、クライアントアプリケーションは、直列化表現を受信し、直列化復元することができる。直列化復元プロセスの一部として、指定されたメンバごとに、データベース内の指定されたメンバの位置に対応するコンテキスト情報を含む型インスタンスを構成することができる。コンテキスト情報は、ＵＤＴ全体へのコンテナ参照、および対応する指定されたメンバへの個々のメンバパスを含み得る。次いで指定された各メンバは、そのコンテキスト情報をデータベースサーバに提供することによって後で再フェッチすることができる。

本発明の別の態様によれば、再フェッチ中、指定されたメンバを最初のフェッチ時の状態で戻すことができる。この特徴を可能にするために、最初のフェッチ時にＵＤＴのバージョンを識別する更新シーケンスマーカ（ｕｐｄａｔｅ ｓｅｑｕｅｎｃｅ ｍａｒｋｅｒ）（ＵＳＭ）を直列化表現とともにクライアントアプリケーションに戻すこともできる。再フェッチ中、ＵＳＭをコンテキスト情報とともにデータベースサーバに戻すことができる。ＵＳＭを使用して、最初のフェッチ時に指定されたメンバの前のバージョンを識別し、取り出すことができる。

本発明の別の態様によれば、最初のフェッチ後、ＵＤＴ全体または個々の指定されたメンバをデータベースサーバに戻すことができる。ＵＤＴ全体が戻されると、指定されたメンバの代わりに、コンテキスト情報がデータベースサーバに提供される。データベースサーバに戻されると、コンテキスト情報を使用して、指定されたメンバを識別し、置き換える。個々の指定されたメンバのみが戻される場合、コンテキスト情報は、指定されたメンバが個々のものであることを示すメタデータ注釈とともに戻される。

本発明の追加の特徴および利点は、添付の図面を参照して進める実施形態の例の以下の詳細な説明から明らかになる。

実施形態の例は、添付の図面を参照して以下の詳細な説明を読めばよりよく理解される。

本発明によれば、ユーザ定義型の取り出しおよび操作を効率的に行うことができる。

以下、図面を参照して本発明を適用できる実施形態を詳細に説明する。

法定要件を満たすために、本発明の主題を詳しく説明する。しかし説明自体は、この特許の範囲を限定するためのものではない。むしろ発明者は、他の現在の技術または将来の技術とともに、本書に記載したものに似た異なる動作または要素を含むように、主張した主題を他の方法でも具体化できることを企図している。

上述したように、本発明は、ユーザ定義型（ＵＤＴ）の指定されたメンバを遅延フェッチするシステムおよび方法を対象とする。一般に、本発明は、ＵＤＴの特定のメンバ、特に大きいオブジェクトを表すメンバを表示可能なメンバとして指定することができる。ＵＤＴの最初のフェッチ中、遅延可能メンバ無しで、ＵＤＴがデータベースから戻され、それによって貴重な処理能力を保護し、フェッチの実行に必要な時間を低減することができる。要求に応じて、最初のフェッチ中に提供された他のメンバを戻すことなく、選択された遅延可能メンバを後で再フェッチすることができる。遅延取り出しのプロセスは、遅延具体化プロセス（ｌａｚｙ ｍａｔｅｒｉａｌｉｚａｔｉｏｎ ｐｒｏｃｅｓｓ）と呼ぶ場合もあるが、後述するシステムおよび方法の参照に使用する特定の用語は、本発明の範囲を限定するためのものではないことを理解されたい。

図６に、本発明によるＵＤＴの指定されたメンバを遅延フェッチするシステム例を示している。一般に、データベースサーバ６００は、データテーブル６１２内などにリレーショナル形式でデータを格納する基礎となるデータストア６１０を含む。テーブル６１２は、ＵＤＴのインスタンスをそれぞれ含むいくつかの行を含むＵＤＴ列６１４を含む。各ＵＤＴインスタンスは、必ずしも必要ではないが、いくつかの大きいオブジェクト６１８ａ〜ｃを含む。テーブル６１２は、グローバルに一意の識別子（ＧＵＩＤ）など一意の識別子に従ってＵＤＴインスタンスを構成する主キー列６１６も含む。テーブル６１２は他のＵＤＴ列および他のリレーショナル列（図示せず）も含み得ることを理解されたい。クライアント６５０は、ユーザがクエリを生成し、それをデータベースサーバ６００に発信することができるようにし、こうしたクエリは、データストア６１０から特定のＵＤＴインスタンスをフェッチすることを要求することができる。

データベースサーバ６００は、ＣＬＲクラス定義に従ってＵＤＴインスタンスを定義できるようにする共通言語ランタイム（ＣＬＲ）を含むこともできる。ＵＤＴのクラス定義例を以下に示す。

上述したように、本発明の一態様によれば、ＵＤＴの特定のメンバを遅延可能メンバとして指定することができる。ＵＤＴのフェッチを要求するクエリが後でデータベースサーバ６００に発信される場合、要求に応じて、遅延可能メンバをクエリの実行の一部としてＵＤＴから取り除くことができる。次いで遅延可能メンバを、要求に応じて後で再フェッチすることができる。したがってＣＬＲ定義６２０によって認識されたカスタム属性を使用して遅延可能メンバに注釈を付けることによってそれらを指定することができる。例えば、遅延可能メンバに、「IsDelayable」属性を使用して注釈を付けることができる。注釈を付けた遅延可能メンバ例を含むＵＤＴを以下に示す。

ＵＤＴが定義され、遅延可能メンバに注釈が付けられると、クエリはデータストア６１０に登録される。データストア６１０は、ＵＤＴの属性を読み取り、注釈に基づいてＵＤＴの遅延可能メンバを識別する。データストア６１０でのＵＤＴの登録後、後述するように、注釈が付けられた遅延可能メンバの遅延フェッチでＵＤＴを取り出すことができる。

図７に、本発明によるＵＤＴの指定されたメンバを遅延フェッチする方法例のフローチャートを示している。動作７１０で、ＵＤＴのフェッチを要求する最初のフェッチクエリがデータベースサーバ６００に発信される。上述したように、処理能力を保護し、フェッチ装置の実行に必要な時間を低減するなどの利点を提供するために、本発明によるフェッチクエリは、ＵＤＴの指定された遅延可能メンバの遅延フェッチを要求することができる。フェッチクエリは、デフォルトでは、遅延可能メンバのフェッチを遅らせないことが好ましい。むしろ、好ましくはフェッチクエリは、遅延フェッチを呼び出す固有の要求を含んでいなければならない。したがって、遅延フェッチを可能にするために、遅延フェッチ節をサポートするようにＳＥＬＥＣＴステートメントの投影リスト（ｐｒｏｊｅｃｔｉｏｎ ｌｉｓｔ）を拡張することができる。こうした遅延フェッチ節は、例えばWITH [REFERENCE] LOCATOR節とすることができる。WITH [REFERENCE] LOCATOR節を含む投影リスト例は、次のように示される。

上述した構文の強化によって、任意のＵＤＴインスタンスの遅延フェッチが可能になる。こうしたＵＤＴインスタンスは、例えば最上位ＵＤＴ、他の何らかのＵＤＴ内に埋め込まれたＵＤＴ値メンバ（ＵＤＴ−ｖａｌｕｅｄ ｍｅｍｂｅｒ）、その部分型または上位型の一方にキャストされたＵＤＴ、または最初の３タイプのいずれかの組み合わせとすることができる。

遅延フェッチを要求するフェッチクエリ例を以下に示す。

遅延フェッチを実装できる２つのやり方がある。参照セマンティクスおよび値セマンティクスである。参照セマンティクスの手法では、再フェッチ操作は、再フェッチ操作自体の時点で遅延メンバを取り出す。したがって、最初のフェッチ後に遅延メンバに加えられた任意の変更は、再フェッチとともに伝えられ、取り出される。値セマンティクスの手法では、再フェッチ操作は、最初のフェッチが実行された時点で遅延メンバを取り出す。したがって、値セマンティクスは、遅延メンバと非遅延メンバと間の読み取り一貫性を提供する。参照セマンティクスおよび値セマンティクスの実装については、以下の説明を通して述べる。

動作７１２で、データベースサーバ６００でフェッチクエリが実行される。図８に、本発明によるフェッチクエリを実行する方法例を示している。図８に示す動作８１０〜８２０は、動作７１２内のサブ動作である。動作８１０で、データベースサーバ６００は、要求されたＵＤＴが一意に識別可能であることを確認する。確認は、要求されたＵＤＴがそこへのアクセスパスを生成することができるテーブルまたはビューに格納されていることを立証することを伴う。こうしたアクセスパスによって、まったく同じ要求された論理ＵＤＴを後で再フェッチすることができる。確認は、そのアクセスパス内のすべてのテーブルが、例えばキー列６１６など、主キーまたは一意のインデックスを含むことを確認することを含み得る。ＵＤＴが一意に識別可能ではない場合、エラーメッセージが戻される場合がある。

動作８１２で、データベースサーバ６００は、ＵＤＴコンテナ参照を生成する。ＵＤＴコンテナ参照は、上述したＵＤＴアクセスパスを含み、最終的にＵＤＴパスのデータベース、スキーマ、テーブル／ビュー、キー列、およびキー列値のすべての論理名をエンコードする。コンテナ参照内のすべての情報は、クライアント６５０によってアクセスできるオブジェクトに関して「論理的」である。したがって、コンテナ参照が存在している限り、クライアント６５０にとってコンテナ参照のセマンティクスは、クライアント６５０によって要求され得る動作および操作に関して理解可能である。コンテナ参照は、データベースサーバ６００の実装の詳細の対象にはならない。コンテナ参照をエンコードするために、追加の文法をデータベースサーバ６００に追加することができる。

動作８１４で、データベースサーバ６００は、ＵＤＴコンテナ参照が不適切な、または許可されていない情報公開でセキュリティを脅かすことがないようにする。動作８１４は任意選択である。セキュリティは、例えば、クエリを発信するユーザがアクセスパスのキー列部分に含まれているすべての列および値にアクセスできることを確認することによって達成することができる。あるいは、セキュリティは、値を暗号化し、それらを暗号化された形式で戻すことによって達成することができる。

動作８１６で、ＵＤＴインスタンスの直列化表現がデータストア６１０から取り出される。動作８１８で、ＵＤＴの遅延可能メンバは、取り出されたＵＤＴから取り除かれる。具体的には、各ＵＤＴインスタンスがクライアント６５０に戻されるとき、戻される特定の型のメタデータはロードされ、遅延可能メンバは列挙され、直列化表現から論理的に取り除かれる。動作８２０で、取り出されたＵＤＴの前には、ＵＤＴコンテナ参照が付けられる。したがって、インスタンスは、ＵＤＴコンテナ参照、およびIsDelayable = trueとマーク付けされたメンバを省いたＵＤＴの直列化形式とともにクライアント６５０に戻される。

値セマンティクスの場合、データベースサーバ６００は、フェッチクエリ実行の一部としていくつかの追加動作を実行する。具体的には、データベースサーバ６００は、フェッチクエリを含むステートメントが確実にユーザトランザクションの文脈で実行されるようにする。さらにサーバ６００は、ＵＤＴインスタンスの一部として更新シーケンスマーカ（ＵＳＭ）を生成し、戻す。これは、再フェッチ操作での読み取り一貫性の提供に使用されるバージョン管理タイムスタンプ（ｖｅｒｓｉｏｎｉｎｇ ｔｉｍｅｓｔａｍｐ）である。

図７に戻って、動作７１４で、遅延メンバが取り除かれ、コンテナ参照が前に付けられたＵＤＴがクライアント６５０に戻される。動作７１６で、戻されたＵＤＴが直列化復元される。直列化復元プロセスの一部として、クライアント６５０にある管理されたデシリアライザは、省かれた遅延ＵＤＴメンバを識別し、こうした遅延メンバごとに、例えばSqlBytesやSqlCharsなど、対応するＣＬＲ型を構築する。遅延メンバごとに構築されたＣＬＲ型は、ＵＤＴ全体の前に付けられたＵＤＴコンテナ参照、および個々の遅延メンバの個々のメンバパスを含む。したがって、メンバごとのＣＬＲ型インスタンスは、データベースサーバ６００内の個々のメンバへのパスを提供するクッキーである。クッキーは、データベースサーバ６００上の遅延メンバの個々のインスタンスを明白に識別し、しかしクライアント６５０を参照しない一連のバイトである。クライアント６５０のプログラムは、一般にクッキーに変更を加えず、データベースサーバ６００への再フェッチ要求にその元の形式のクッキーを使用する。

よりよい性能および拡張性を達成するために、クライアント６５０で、個々のメンバパスを含む各遅延メンバの全コンテキストの設定が行われる。クライアントデシリアライザは、インスタンスが遅延メンバを含んでいるかどうかに関係なく、戻されたすべてのＵＤＴインスタンスについて、完全な型のトラバーサルを行う。したがって、データベースサーバ６００での全コンテキストの設定とは対照的に、クライアント６５０での全コンテキストの設定では、戻されたＵＤＴの追加のトラバーサルを必要としない。さらに、クライアント６５０の全コンテキストの設定は、データベースサーバ６００から追加の作業をオフロードし、その結果拡張性の利益が得られる。

本発明によるＣＬＲ型は、クッキー状態による裏付けをサポートするように強化することができる。さらに、型は、完全には具体化されないときに対応するインスタンスを使用する試行がなされる場合、例外を戻すように強化することができる。

重要なことに、ＣＬＲ型は、データベースサーバ６００から対応するインスタンスの全表現を自動的に再フェッチする「Ｆｉｌｌ」メソッドを提供するように強化することもできる。Ｆｉｌｌメソッドは、データベースサーバ６００への接続を引数とみなす。Ｆｉｌｌメソッドを使用する代わりに、サーバ接続への参照を、直列化復元中にクライアント６５０に暗黙的に格納することができる。

動作７１８で、クライアント６５０は、選択された遅延メンバを再フェッチする要求を発信する。再フェッチ操作によって、最初のフェッチ中に戻された非遅延メンバを取り出すことなく、選択された遅延メンバを取り出すことができる。再フェッチ操作は、ユーザによって実行されるタスクの量および複雑さを最低限に抑えるように実装される。再フェッチは、対応するＣＬＲ型インスタンスに対してＦｉｌｌメソッドを介して実行される。これらのメソッドは、クッキーを取得し、対応する単体の遅延メンバを戻す新しく追加されたリモートプロシージャ呼び出し（ＲＰＣ）エントリポイントを呼び出す。

具体的には、ユーザは、特定のメンバを再フェッチするために、対応するインスタンスのＦｉｌｌメソッドを呼び出し、データベースサーバ６００への接続を指定するだけでよい。値セマンティクスの場合、最初のフェッチのＵＳＭも提供される。Ｆｉｌｌメソッドを呼び出すと、格納されているプロシージャが、ＵＤＴコンテナ参照、対応する個々のメンバパス、および該当する場合はＵＳＭを受信するデータベースサーバ６００上で実行される。

動作７２０で、再フェッチ操作がデータベースサーバ６００で実行される。再フェッチを実行するために、データベースサーバエントリポイントは、遅延フェッチ文法（ｄｅｌａｙｅｄ ｆｅｔｃｈｉｎｇ ｇｒａｍｍａｒ）を使用してＵＤＴコンテナ参照を構文解析し、ＵＤＴ全体を取り出すために実行することができるクエリツリーを構築する。ＵＤＴ全体が取得されると、個々のメンバパス情報を使用して、戻す必要がある選択された個々のメンバまでトラバースする。この操作は、インスタンスの部分型と上位型との間のキャストを含み得る。値セマンティクスの場合、提供されたＵＳＭを使用して、最初のフェッチ時から要求されたメンバの前のバージョンが識別され、取り出される。

動作７２２で、要求されたメンバは、発見後、クライアント６５０に戻される。動作７２４で、戻されたメンバをクライアント６５０が受信する。ＣＬＲ型インスタンスは、メンバ表現を読み取り、メンバ表現を裏付け表現（ｂａｃｋｉｎｇ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）に設定し、インスタンスの内部状態を「ｆｉｌｌｅｄ」に設定する。

したがって、図７および図８を参照して上述したように、本発明は、ＵＤＴの指定されたメンバの遅延取り出しを可能にする。データベースサーバ６００からＵＤＴメンバをフェッチする方法を提供することに加えて、本発明は、遅延メンバを含む「インバウンド」ＵＤＴをサーバ６００に発信するために使用することもできる。本発明のこの特徴は、クライアント６５０がＵＤＴのメンバに変更を加え、ＵＤＴまたは変更された個々のメンバをデータベースサーバ６００に戻してデータストア６１０に格納するときに特に有利である。このシナリオでは、クライアント６５０は、ＵＤＴの遅延可能メンバを最初に取り出す必要なく、ＵＤＴまたは変更された個々のメンバをデータベースサーバ６５０に発信することができる。クライアント６５０は、ＣＬＲ型の一杯ではないメンバまたは一杯ではないインスタンスを含むＵＤＴインスタンス全体を入力パラメータとしてデータベースサーバ６００に戻すことができる。

一杯ではないメンバを含むＵＤＴ全体を戻す場合、クライアント６５０上の管理されたシリアライザは、一杯ではない各メンバ値の代わりに、ＵＤＴ参照６１５および対応する個々のメンバパスを含む全クッキーを送信する。入力時に、データベースサーバ６００は、埋め込み遅延メンバがあるかどうかについてＵＤＴをチェックし、見つかったすべての遅延メンバを拡張し、置き換える。一杯ではないメンバの拡張は、正しいセマンティクスを保証するために、入力境界で実行される。メンバは、他のインスタンスから、または同じインスタンスの他のバージョンから割り当てることができる。

ＣＬＲ型のスタンドアロンインスタンスの場合、クライアントドライバは、クッキー表現をインスタンスの識別を示すメタデータ注釈とともに送信する。メタデータ注釈は、クッキーと、シーケンスが一致する実際のバイナリ／文字値との間を区別できるようにする。

上記からわかるように、本発明の様々なシステム、方法、および態様のすべてまたは一部分は、ハードウェア、ソフトウェア、またはその両方の組み合わせに組み込むことができる。ソフトウェアに組み込まれる場合、本発明の方法および装置、またはその一部の態様または一部分は、プログラムコード（すなわち命令）の形で組み込むことができる。このプログラムコードは、それだけには限定されないが、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ―ＲＯＭ、ＤＶＤ−ＲＡＭ、磁気テープ、フラッシュメモリ、ハードディスクドライブ、または他の任意のマシン可読記憶媒体を含む磁気、電気、または光記憶媒体などのコンピュータ可読媒体に格納することができ、プログラムコードがコンピュータやサーバなどのマシンにロードされ、マシンによって実行されると、マシンは本発明を実施する装置になる。プログラムコードをそこで実行するコンピュータは、一般にプロセッサ、プロセッサによって読み取り可能な記憶媒体（揮発性および不揮発性メモリおよび／または記憶要素を含む）、少なくとも１つの入力装置、および少なくとも１つの出力装置を含む。プログラムコードは、高レベル手続き型またはオブジェクト指向型のプログラミング言語で実施することができる。あるいは、プログラムコードは、アセンブリ言語またはマシン言語で実施することができる。どんな場合でも、言語はコンパイル型またはインタプリタ型言語とすることができる。

本発明は、例えば電気配線やケーブル布線を介する、光ファイバによる、ローカルエリアネットワーク、広域ネットワーク、インターネットまたはイントラネットを含むネットワークを介する、あるいは他の任意の形の送信を介するなど、何らかの送信媒体を介して送信されるプログラムコードの形で組み込むこともでき、プログラムコードがコンピュータなどのマシンによって受信され、ロードされ、実行されると、こうしたマシンは、本発明を実施する装置になる。

汎用プロセッサ上で実施されるとき、プログラムコードは、プロセッサと組み合わせて、特定の論理回路と同じように動作する一意の装置を提供することができる。

さらに本発明は、コンピュータネットワークの一部として配置する、または分散コンピューティング環境に配置することができる任意のコンピュータまたは他のクライアントまたはサーバ装置との関連で実施することができる。この点で、本発明は、任意の数のメモリまたはストレージユニットを有する任意のコンピュータシステムまたは環境、および本発明によるデータベースストア内にオブジェクトを保持するプロセスとの関連で使用することができる、任意の数のストレージユニットまたはボリュームにわたって行われる任意の数のアプリケーションおよびプロセスに関係がある。本発明は、リモートまたはローカルのストレージを有する、ネットワーク環境または分散コンピューティング環境に配置されているサーバコンピュータおよびクライアントコンピュータを含む環境に適用することができる。本発明は、リモートまたはローカルのサービスとの関連で情報を生成し、受信し、送信するためのプログラミング言語機能、解釈機能および実行機能を有するスタンドアロンコンピューティング装置に適用することもできる。

分散コンピューティングは、コンピューティング装置とシステムとの間の交換によりコンピュータリソースおよびサービスの共有を容易にする。これらのリソースおよびサービスは、それだけには限定されないが、情報交換、キャッシュストレージ、およびファイル用のディスクストレージを含む。分散コンピューティングはネットワーク接続を利用し、それによってクライアントは、集合的な力を利用して企業全体の利益になるようにすることができる。この点で、様々な装置は、本発明のオブジェクト維持方法との関連で実行される処理に関与し得るアプリケーション、オブジェクト、またはリソースを有する。

図９は、ネットワーク式または分散式のコンピューティング環境例の略図を示している。分散コンピューティング環境は、コンピューティングオブジェクト１０ａ、１０ｂなど、およびコンピューティングオブジェクトまたは装置１１０ａ、１１０ｂ、１１０ｃなどを含む。これらのオブジェクトは、プログラム、メソッド、データストア、プログラム可能ロジックなどを含み得る。オブジェクトは、ＰＤＡ（Personal Digital Assistant）、ＴＶ（television）、ＭＰ３（MPEG-1 Audio Layer 3）プレイヤ、パーソナルコンピュータなど、同じまたは異なる装置の一部分を含み得る。各オブジェクトは、通信ネットワーク１４を介して別のオブジェクトと通信することができる。このネットワーク自体は、サービスを図９のシステムに提供する他のコンピューティングオブジェクトおよびコンピューティング装置を含み、複数の相互接続されたネットワークを表し得る。本発明の一態様によれば、各オブジェクト１０ａ、１０ｂなど、または１１０ａ、１１０ｂ、１１０ｃなどは、本発明のオブジェクト維持方法の実施に使用するプロセスの使用を要求するために、ＡＰＩまたは他のオブジェクト、ソフトウェア、ファームウェアおよび／またはハードウェアを使用するアプリケーションを含み得る。

１１０ｃなどのオブジェクトが別のコンピューティング装置１０ａ、１０ｂなど、または１１０ａ、１１０ｂなどでホストされ得ることも理解できよう。したがって、示した物理的な環境では、接続された装置をコンピュータとして示しているが、こうした図は単に例にすぎず、代わりにＰＤＡ、ＴＶ、ＭＰ３プレイヤなどの様々なデジタル装置、インタフェース、ＣＯＭ（Component Object Model）オブジェクトなどのソフトウェアオブジェクトを含む物理的な環境を示し、または記載することができる。

分散コンピューティング環境をサポートする様々なシステム、構成要素、ネットワーク構成がある。例えば、複数のコンピューティングシステムは、有線または無線のシステム、ローカルネットワーク、または広範に分散されたネットワークによってともに接続することができる。現在、ネットワークの多くは、広範にわたって分散されたコンピューティングのためのインフラストラクチャを提供し、異なる多くのネットワークを含むインターネットに結合されている。任意のインフラストラクチャを、本発明に付随するようになされた通信例に使用することができる。

インターネットとは、通常、コンピュータネットワーキングの分野でよく知られているプロトコルのＴＣＰ／ＩＰスイーツを使用するネットワークおよびゲートウェイの集まりを指す。ＴＣＰ／ＩＰは、「Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ」の頭字語である。インターネットは、ユーザがネットワークを介して対話し、情報を共有することができるようにするネットワーキングプロトコルを実行するコンピュータによって相互接続された地理的に分散されたリモートコンピュータネットワークのシステムとして説明することができる。こうした広範囲にわたる情報の共有のため、インターネットなどのリモートネットワークは、これまでのところ、一般にオープンシステムに発展している。その開発者は、本質的に制限無しに、特別な操作またはサービスを実行するソフトウェアアプリケーションを設計することができる。

したがって、ネットワークインフラストラクチャによって、クライアント／サーバ、ピアツーピア、またはハイブリッドアーキテクチャ（ｈｙｂｒｉｄ ａｒｃｈｉｔｅｃｔｕｒｅ）など、多数のネットワーク技術が可能となる。「クライアント」とは、関係のない別のクラスまたはグループのサービスを使用するあるクラスまたはグループのメンバである。したがって、コンピュータ処理では、クライアントとはプロセス、すなわち大ざっぱに言えば、別のプログラムによって提供されるサービスを要求する１組の命令またはタスクである。クライアントプロセスは、他のプログラムまたはサービス自体についての任意の作業の詳細を「認識している」必要無く、要求されたサービスを使用する。クライアント／サーバアーキテクチャ、特にネットワーク式システムでは、通常クライアントは、サーバなど、別のコンピュータによって提供される共有のネットワークリソースにアクセスするコンピュータである。図９の例では、コンピュータ１１０ａ、１１０ｂなどをクライアントと考えることができ、コンピュータ１０ａ、１０ｂなどをサーバと考えることができるが、状況に応じて、任意のコンピュータをクライアント、サーバ、またはその両方とみなすことができる。こうした任意のコンピューティング装置は、本発明のオブジェクト維持技術を含むやり方でデータを処理している可能性がある。

サーバは一般に、インターネットなど、リモートネットワークまたはローカルネットワークを介してアクセス可能なリモートコンピュータシステムである。クライアントプロセスは、第１のコンピュータシステムでアクティブであり、サーバプロセスは、第２のコンピュータシステムでアクティブであり、互いに通信媒体を介して通信し、したがって分散機能を提供し、複数のクライアントがサーバの情報収集機能を利用することができる。本発明の保持機構に従って使用される任意のソフトウェアオブジェクトを、複数のコンピューティング装置にわたって分散することができる。

クライアントおよびサーバは、プロトコルレイヤによって提供される機能を使用して互いに通信することができる。例えば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）は、ＷＷＷまたは「Ｗｅｂ」とともに使用される共通のプロトコルである。一般に、インターネットプロトコル（ＩＰ）アドレスなどのコンピュータネットワークアドレス、またはユニバーサルリソースロケータ（ＵＲＬ）などの他の参照を使用してサーバコンピュータまたはクライアントコンピュータを互いに識別することができる。ネットワークアドレスは、ＵＲＬアドレスと呼ぶことができる。通信は、使用可能な任意の通信媒体を介して提供することができる。

したがって図９は、本発明を使用することができるネットワーク式または分散式の環境例を示しており、サーバは、ネットワーク／バスを介してクライアントコンピュータと通信する。ネットワーク／バス１４は、本発明に従って、ポータブルコンピュータ、ハンドヘルドコンピュータ、シンクライアント、ネットワーク装置などいくつかのクライアントまたはリモートコンピューティング装置１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなど、またはＶＣＲ、ＴＶ、オーブン、電灯、ヒーターなどの他の装置を含む、ＬＡＮ（local area network）、ＷＡＮ（wide area network）、イントラネット、インターネット、または他の何らかのネットワーク媒体とすることがでる。したがって、保持されたオブジェクトを維持することが望ましい任意のコンピューティング装置に本発明を適用することができることが企図されている。

通信ネットワーク／バス１４がインターネットであるネットワーク環境では、例えばサーバ１０ａ、１０ｂなどは、クライアント１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなどがＨＴＴＰなどの既知のいくつかのプロトコルのうちの任意のものを介して通信するサーバとすることができる。サーバ１０ａ、１０ｂなどは、クライアント１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなどとして働く場合もあり、これは分散コンピューティング環境の特徴である。

通信は、適切な場合は有線または無線とすることができる。クライアント装置１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなどは、通信ネットワーク／バス１４を介して通信することもでき、独立した通信が関連付けられていてもよい。例えば、ＴＶまたはＶＣＲの場合、その制御へのネットワーク式態様があってもよい。各クライアントコンピュータ１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなど、およびサーバコンピュータ１０ａ、１０ｂなどは、様々なアプリケーションプログラムモジュールまたはオブジェクト１３５、および様々なタイプの記憶要素またはオブジェクトへの接続またはアクセスを備えることができ、それを介してファイルまたはデータストリームが格納され、ファイルまたはデータストリームの部分をそこにダウンロードし、送信し、マイグレーションすることができる。任意のコンピュータ１０ａ、１０ｂ、１１０ａ、１１０ｂなどは、本発明によって処理されるデータを格納するデータベース、メモリ、または他の記憶要素２０のメンテナンスおよび更新を行う役割を果たし得る。したがって、本発明は、コンピュータネットワーク／バス１４にアクセスし、それと対話することができるクライアントコンピュータ１１０ａ、１１０ｂなど、クライアントコンピュータ１１０ａ、１１０ｂなどおよび他の同様の装置と対話することができるサーバコンピュータ１０ａ、１０ｂなど、およびデータベース２０を有するコンピュータネットワーク環境で使用することができる。

図１０および以下の説明は、本発明を実施できる適したコンピューティング装置の簡単な概説を提供するためのものである。例えば、図９に示した任意のクライアントおよびサーバのコンピュータまたは装置は、この形を取り得る。しかし、ハンドヘルド、ポータブル、および他のコンピューティング装置およびあらゆる種類のコンピューティングオブジェクトは、本発明とともに使用することが企図されており、すなわち、コンピューティング環境において、そのどこからでもデータを生成し、処理し、受信し、かつ／または送信することができる。以下では汎用コンピュータについて説明するが、これは一例にすぎず、本発明は、ネットワーク／バスの相互運用性および対話を有するシンクライアントにより実施することができる。したがって、本発明は、例えば機器に配置されているオブジェクトなど、クライアント装置が単にネットワーク／バスへのインタフェースとして働くネットワーク式環境など、非常に小さいまたは最小のクライアントリソースが関与するネットワーク式ホストサービスの環境で実施することができる。本質的に、データを格納することができる、またはデータを取り出したり、他のコンピュータに送信したりすることができるところであれば、本発明のオブジェクト維持方法の操作に望ましい、または適した環境である。

必須ではないが、本発明は、装置またはオブジェクトのサービスの開発者が使用できるように、オペレーティングシステムを介して実施することができ、かつ／または本発明に従って動作するアプリケーションまたはサーバソフトウェア内に含めることができる。ソフトウェアは、クライアントワークステーション、サーバ、または他の装置など、１つまたは複数のコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な状況で説明することができる。一般にプログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、構成要素、データ構造などを含む。一般に、プログラムモジュールの機能を、様々な実施形態で必要に応じて結合し、または分散することができる。さらに、本発明は、他のコンピュータシステム構成およびプロトコルで実施することができる。本発明との使用に適したよく知られている他のコンピューティングシステム、環境、および／または構成には、それだけには限定されないが、パーソナルコンピュータ（ＰＣ）、現金自動預け払い機、サーバコンピュータ、ハンドヘルドまたはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラム可能家庭用電化製品、ネットワークＰＣ、機器、電灯、環境制御要素、ミニコンピュータ、メインフレームコンピュータなどがある。

したがって図１０は、本発明を実施できる適したコンピューティングシステム環境例１００の例を示しているが、上記で明らかになったように、コンピューティングシステム環境１００は、適したコンピューティング環境の一例にすぎず、本発明の使用または機能の範囲に関する任意の制限を示唆するものではない。また、コンピューティング環境１００を、動作環境１００の例に示した構成要素のいずれか１つ、またはその組み合わせに関連する依存性または必要条件を有しているものと解釈すべきではない。

図１０を参照すると、本発明を実施するシステムの例は、汎用コンピューティング装置をコンピュータ１１０の形で含んでいる。コンピュータ１１０の構成要素は、それだけには限定されないが、プロセッサ１２０、システムメモリ１３０、およびシステムメモリを含む様々なシステム構成要素をプロセッサ１２０に結合するシステムバス１２１を含み得る。システムバス１２１は、様々なバスアーキテクチャのうちの任意のものを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含むいくつかのタイプのバス構造のうちどんなものでもよい。こうしたアーキテクチャには、それだけには限定されないが一例として、ＩＳＡ（Industry Standard Architecture）バス、ＭＣＡ（Micro Channel Architecture）バス、ＥＩＳＡ（Extended Industry Standard Architecture）バス、ＶＥＳＡ（Video Electronics Standards Association）ローカルバス、およびＰＣＩ（Peripheral Component Interconnect）バス（メザニンバスとしても知られている）などがある。

コンピュータ１１０は、一般に様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０からアクセスできる使用可能な任意の媒体とすることができ、揮発性および不揮発性媒体、リムーバブルおよびノンリムーバブル媒体を含む。コンピュータ可読媒体は、それだけには限定されないが一例として、コンピュータ記憶媒体および通信媒体を含み得る。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、他のデータなど、情報を格納するための任意の方法または技術で実施される揮発性および不揮発性のリムーバブルおよびノンリムーバブル媒体がある。コンピュータ記憶媒体には、それだけには限定されないが、ＲＡＭ（random access memory）、ＲＯＭ（read only memory）、ＥＥＰＲＯＭ（Electronically Erasable and Programmable Read Only Memory）、フラッシュメモリまたは他のメモリ技術、ＣＤ（compact disc）−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置、または所望の情報の格納に使用でき、コンピュータ１１０からアクセスできる他の任意の媒体などがある。通信媒体は一般に、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを搬送波または他の移送機構などの変調されたデータ信号に組み込む。これには任意の情報配送媒体がある。「変調されたデータ信号」という用語は、信号に情報を符号化するように１つまたは複数のその特性が設定または変更された信号を意味する。通信媒体には、それだけには限定されないが一例として、有線ネットワーク、直接配線された接続などの有線媒体、および音響、ＲＦ（radio frequency）、赤外線、その他の無線媒体などの無線媒体がある。また、上記のどんな組み合わせでもコンピュータ可読媒体の範囲内に含まれるものとする。

システムメモリ１３０は、読み取り専用メモリ（ＲＯＭ）１３１やランダムアクセスメモリ（ＲＡＭ）１３２など、揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。ＢＩＯＳ（Basic Input/Output System）１３３は、例えば起動中など、コンピュータ１１０内の要素間での情報の転送を助ける基本ルーチンを含み、一般にＲＯＭ１３１に格納されている。ＲＡＭ１３２は一般に、プロセッサ１２０から直接アクセス可能な、かつ／またはプロセッサ１２０が現在処理しているデータおよび／またはプログラムモジュールを含む。図１０は、それだけには限定されないが一例として、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示している。

コンピュータ１１０は、他のリムーバブル／ノンリムーバブル、揮発性／不揮発性コンピュータ記憶媒体を含むこともできる。一例にすぎないが、図８は、ノンリムーバブル不揮発性磁気媒体から読み取り、あるいはそこに書き込むハードディスクドライブ１４１、リムーバブル不揮発性磁気ディスク１５２から読み取り、あるいはそこに書き込む磁気ディスクドライブ１５１、およびＣＤ−ＲＷ、ＤＶＤ−ＲＷ、または他の光媒体など、リムーバブル不揮発性光ディスク１５６から読み取り、あるいはそこに書き込む光ディスクドライブ１５５を示している。動作環境の例で使用できる他のリムーバブル／ノンリムーバブル、揮発性／不揮発性コンピュータ記憶媒体には、それだけには限定されないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、半導体ＲＡＭ、半導体ＲＯＭなどがある。ハードディスクドライブ１４１は一般に、インタフェース１４０などのノンリムーバブルメモリインタフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は一般に、インタフェース１５０などのリムーバブルメモリインタフェースによってシステムバス１２１に接続される。

上述し、図１０に示したドライブおよびその関連のコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびコンピュータ１１０の他のデータの記憶を提供する。図１０では例えば、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するものとして示されている。これらの構成要素は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じであっても、異なっていてもよいことに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は少なくとも異なるコピーであることを示すために、ここではそれらに異なる番号を付している。ユーザは、キーボード１６２、およびマウス、トラックボール、またはタッチパッドなどのポインティングデバイス１６１などの入力装置を介してコマンドおよび情報をコンピュータ１１０に入力することができる。他の入力装置（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどがある。これらおよび他の入力装置は、しばしばシステムバス１２１に結合されているユーザ入力インタフェース１６０を介してプロセッサ１２０に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）など他のインタフェースおよびバス構造で接続してもよい。グラフィックインタフェース１８２は、システムバス１２１に接続してもよい。１つまたは複数のグラフィック処理ユニット（ＧＰＵ）１８４がグラフィックインタフェース１８２と通信し得る。モニタ１９１または他のタイプの表示装置もまた、ビデオインタフェース１９０などのインタフェースを介してシステムバス１２１に接続され、ビデオインタフェース１９０はビデオメモリ１８６と通信することができる。モニタ１９１に加えて、コンピュータは、出力周辺インタフェース１９５を介して接続できるスピーカ１９７、プリンタ１９６などの他の周辺出力装置を含むこともできる。

コンピュータ１１０は、リモートコンピュータ１８０など１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク式環境または分散環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の一般のネットワークノードでよく、一般にコンピュータ１１０に関連して上述した多くまたはすべての要素を含むが、図１０にはメモリ記憶装置１８１のみを示している。図１０に示した論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３を含むが、他のネットワーク／バスを含んでいてもよい。こうしたネットワーキング環境は、家、オフィス、全社規模のコンピュータネットワーク、イントラネット、およびインターネットではごく一般的である。

ＬＡＮネットワーキング環境で使用する場合、コンピュータ１１０は、ネットワークインタフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用する場合、コンピュータ１１０は一般に、モデム１７２、またはインターネットなどＷＡＮ１７３を介して通信を確立する他の手段を含む。モデム１７２は、内蔵のものでも外付けのものでもよく、ユーザ入力インタフェース１６０または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク式環境では、コンピュータ１１０に関連して示したプログラムモジュール、またはその一部をリモートメモリ記憶装置に格納することができる。図１０は、それだけには限定されないが一例として、リモートアプリケーションプログラム１８５をメモリ装置１８１上に存在するものとして示している。図示したネットワーク接続は例であり、コンピュータ間の通信リンクを確立する他の手段を使用してもよいことは理解されよう。

上記で示したように、本発明は、ＵＤＴの指定されたメンバの遅延フェッチを対象にしている。本発明は、デジタル写真、ビデオなど、大きいオブジェクトのフェッチを遅らせる場合に特に有利である。その広範な発明の概念から逸脱することなく、上記の実施形態に変更を加えることができることを理解されたい。例えば、本発明の実施形態をＭｉｃｒｏｓｏｆｔのＳＱＬ ＳＥＲＶＥＲ（商標）データベース管理システムで実装するものとして上述してきたが、本発明は、ユーザ定義型の作成をサポートする任意のデータベース管理システムに組み込むことができることを理解されたい。さらに、本発明のいくつかの概念を、上述したＷｉｎＦＳストレージプラットフォームの状況で具体化されるものとして説明してきたが、本発明のこうした態様は決してその環境における実装に限定されるものではないことを理解されたい。むしろ、本発明の方法およびシステムは、ユーザ定義型のメンバの格納および取り出しが望ましい任意のシステムに組み込むことができる。したがって、本発明は、開示した特定の実施形態に限定されないが、添付の特許請求の範囲によって定義される本発明の意図および範囲内のすべての変更をカバーするものとすることを理解されたい。

ユーザ定義型のマネージドコードクラス定義を示すコードセグメント例を示す図である。 マネージドコードでインスタンス化された型のインスタンスの直列化および直列化復元を示すブロック図である。 ユーザ定義型のオブジェクトが保持されるデータベーステーブルを示す図である。 本発明の特徴を利用することができるストレージプラットフォーム例を示すブロック図である。 図４に示したストレージプラットフォームの文脈でユーザ定義型の保持されたオブジェクトに対してクエリを実行するプロセスを示す図である。 本発明によるユーザ定義型のメンバを遅延フェッチするシステム例を示すブロック図である。 本発明によるユーザ定義型のメンバを遅延フェッチする方法例を示すフローチャートである。 本発明によるユーザ定義型の最初のフェッチを実行する方法例を示すフローチャートである。 本発明を実施できる様々なコンピューティング装置を有するネットワーク環境例を表すブロック図である。 本発明を実施できるコンピューティング装置例を表すブロック図である。

符号の説明

６００ データベースサーバ
６１０ データストア
６２０ ＣＬＲ定義
６５０ クライアント

Claims (33)

1. ユーザ定義型の指定されたメンバを遅延フェッチする方法であって、
   データストア内の前記ユーザ定義型へのパスを識別する前記ユーザ定義型へのコンテナ参照を生成するステップと、
   前記データストアから前記ユーザ定義型の直列化表現を取り出すステップと、
   前記直列化表現から前記指定されたメンバを取り除くステップと、
   前記直列化表現に前記コンテナ参照を添付するステップと
   を備えることを特徴とする方法。
2. 前記指定されたメンバに注釈を付ける対応するクラス定義に従って前記データストア内に前記ユーザ定義型を登録するステップをさらに備えることを特徴とする請求項１に記載の方法。
3. 前記指定されたメンバの遅延フェッチによる前記ユーザ定義型の最初のフェッチを要求するクエリを受信するステップをさらに備えることを特徴とする請求項１に記載の方法。
4. 前記直列化表現および前記添付されたコンテナ参照をクライアントアプリケーションに戻すステップをさらに備えることを特徴とする請求項１に記載の方法。
5. 前記コンテナ参照を生成する前に前記ユーザ定義型が一意に識別可能であることを確認するステップをさらに備えることを特徴とする請求項１に記載の方法。
6. 前記コンテナ参照を前記直列化表現に添付する前に前記コンテナ参照のセキュリティを確実にするステップをさらに備えることを特徴とする請求項１に記載の方法。
7. 現在の更新シーケンスマーカを前記直列化表現に添付するステップをさらに備えることを特徴とする請求項１に記載の方法。
8. 前記指定されたメンバを再フェッチする要求を受信するステップであって、前記要求は、前記コンテナ参照、および前記指定されたメンバへの個々のメンバパスを含むコンテキスト情報を含むステップと、
   前記コンテキスト情報に基づいて前記指定されたメンバを前記データストアから取り出すステップと、
   前記指定されたメンバを戻すステップと
   をさらに備えることを特徴とする請求項１に記載の方法。
9. 前記ユーザ定義型の前記最初のフェッチに対応する更新シーケンスマーカをさらに含む、前記指定されたメンバを再フェッチする前記要求を受信するステップを備えることを特徴とする請求項８に記載の方法。
10. 前記データストアから前記指定されたメンバの前のバージョンを取り出すステップであって、前記前のバージョンは前記更新シーケンスマーカによって識別されるステップを備えることを特徴とする請求項９に記載の方法。
11. 前記指定されたメンバが前記コンテナ参照、および前記指定されたメンバへの個々のメンバパスを含むコンテキスト情報に置き換えられた前記ユーザ定義型の再直列化表現を受信するステップと、
    前記コンテキスト情報を前記指定されたメンバに置き換えるステップであって、前記指定されたメンバは前記コンテキスト情報に基づいて識別されるステップと、
    前記再直列化表現を前記データストアに格納するステップと
    をさらに備えることを特徴とする請求項１に記載の方法。
12. 前記コンテナ参照、および前記指定されたメンバへの個々のメンバパスを含むコンテキスト情報を受信し、前記コンテキスト情報を前記データストア内の前記指定されたメンバの位置へのパスとして識別するメタデータ注釈を受信するステップと、
    前記コンテキスト情報を前記指定されたメンバに置き換えるステップであって、前記指定されたメンバは前記コンテキスト情報に基づいて識別されるステップと、
    前記指定されたメンバを前記データストアに格納するステップと
    をさらに備えることを特徴とする請求項１に記載の方法。
13. 請求項１に記載の各ステップを実行するコンピュータ実行可能命令を有することを特徴とするコンピュータ読み取り可能な記録媒体。
14. ユーザ定義型の指定されたメンバを遅延フェッチする方法であって、それによって前記遅延フェッチは、前記指定されたメンバを伴わない前記ユーザ定義型の直列化表現を戻す最初のフェッチ後に要求され、前記直列化表現は前記ユーザ定義型への添付されたコンテナ参照を有し、前記コンテナ参照はデータストア内の前記ユーザ定義型へのパスを識別し、前記方法は、
    前記指定されたメンバに対応する型インスタンスを構築することによって前記直列化表現を直列化復元するステップであって、前記型インスタンスは、前記コンテナ参照、および前記ユーザ定義型内の前記指定されたメンバへの個々のメンバパスを含むコンテキスト情報を含むステップと、
    前記指定されたメンバの再フェッチ要求をデータベースサーバに発信するステップであって、前記再フェッチ要求は前記コンテキスト情報を含むステップと
    を備えることを特徴とする方法。
15. 前記最初のフェッチクエリを前記データストアに発信するステップであって、前記クエリは前記指定されたメンバの遅延フェッチを要求するステップをさらに備えることを特徴とする請求項１４に記載の方法。
16. 前記ユーザ定義型の前記直列化表現を、前記最初のフェッチに対応する添付された更新シーケンスマーカとともに受信するステップをさらに備えることを特徴とする請求項１４に記載の方法。
17. 前記更新シーケンスマーカをさらに含む前記再フェッチ要求を前記データベースサーバに発信するステップを備えることを特徴とする請求項１６に記載の方法。
18. 前記再フェッチ要求に応答して前記指定されたメンバを受信するステップをさらに備えることを特徴とする請求項１４に記載の方法。
19. 前記最初のフェッチに対応する更新シーケンスマーカによって識別される前記指定されたメンバの前のバージョンを受信するステップを備えることを特徴とする請求項１８に記載の方法。
20. 前記ユーザ定義型の表現を再直列化し、それによって前記指定されたメンバは前記コンテキスト情報に置き換えられるステップと、
    前記データストアに格納するために前記再直列化表現を前記データベースサーバに発信するステップと
    をさらに備えることを特徴とする請求項１４に記載の方法。
21. 前記コンテキスト情報、および前記コンテキスト情報を前記データストア内の前記指定されたメンバの位置へのパスとして識別するメタデータ注釈を前記データベースサーバに発信するステップをさらに備えることを特徴とする請求項１４に記載の方法。
22. 請求項１に記載の各ステップを実行するコンピュータ実行可能命令を有することを特徴とするコンピュータ読み取り可能な記録媒体。
23. ユーザ定義型の指定されたメンバを遅延フェッチするシステムであって、
    データベースサーバ、データストア、およびクライアントアプリケーションを備え、
    前記クライアントアプリケーションは前記ユーザ定義型の最初のフェッチを要求するクエリを発信し、前記クエリは前記指定されたメンバの遅延フェッチを要求し、
    前記データベースサーバは、前記指定されたメンバが取り除かれた、前記ユーザ定義型の直列化表現を含む最初のフェッチ結果を戻し、前記最初のフェッチ結果は前記データストア内の前記ユーザ定義型へのパスを識別する添付されたコンテナ参照をさらに含む
    ことを特徴とするシステム。
24. 前記ユーザ定義型は、前記指定されたメンバが遅延可能メンバとして注釈が付けられる対応するクラス定義に従って定義されることを特徴とする請求項２３に記載のシステム。
25. 前記最初のフェッチ結果は、前記最初のフェッチに対応する添付された更新シーケンスマーカをさらに含むことを特徴とする請求項２３に記載のシステム。
26. 前記クライアントアプリケーションは再フェッチ要求を前記データベースサーバに発信し、前記再フェッチ要求は、前記コンテナ参照、および前記指定されたメンバへの個々のメンバパスを含むコンテキスト情報を含むことを特徴とする請求項２３に記載のシステム。
27. 前記データベースサーバは前記コンテキスト情報に基づいて前記データストアから前記指定されたメンバを取り出し、前記指定されたメンバを前記クライアントアプリケーションに戻すことを特徴とする請求項２６に記載のシステム。
28. 前記再フェッチ結果は、前記最初のフェッチに対応する更新シーケンスマーカをさらに含むことを特徴とする請求項２６に記載のシステム。
29. 前記クライアントアプリケーションに戻された前記指定されたメンバは前記更新シーケンスマーカに基づいて識別された前記指定されたメンバの前のバージョンを含むことを特徴とする請求項２８に記載のシステム。
30. 前記クライアントアプリケーションは前記ユーザ定義型の再直列化表現を前記データベースサーバに発信し、前記再直列化表現は、前記コンテナ参照、および前記指定されたメンバへの個々のメンバパスを含むコンテキスト情報に置き換えられた前記指定されたメンバを含むことを特徴とする請求項２３に記載のシステム。
31. 前記データベースサーバは前記コンテキスト情報を前記指定されたメンバに置き換え、前記指定されたメンバは前記コンテキスト情報に基づいて識別されることを特徴とする請求項３０に記載のシステム。
32. 前記再直列化表現は前記データストアに格納されることを特徴とする請求項３１に記載のシステム。
33. 前記クライアントアプリケーションは、前記コンテナ参照、および前記指定されたメンバへの個々のメンバパスを含むコンテキスト情報を前記データベースサーバに発信し、メタデータ注釈は前記コンテキスト情報を前記データストア内の前記指定されたメンバの位置へのパスとして識別することを特徴とする請求項２３に記載のシステム。
    

Images