(57)【要約】  データベースストア内のユーザ定義タイプのオブジェクトを保存するための新しい維持フォーマットによって、タイプの構造に関する情報をストアに伝達することができる。この情報によって、タイプのメンバへの直接的で構造的なアクセスを含む複数のストア最適化が可能となる。特に、タイプインプリメンタとデータストアの間でメタデータが交換される。ストアはメタデータを使用して、タイプのインスタンス用のストレージレイアウトを決定する。この情報によってストアは、オブジェクトのハイドレーション（デシリアライゼーション）を伴わずにストレージ表現上で直接動作するように最適化できるアクセスパターンを検出することができる。
2007509425.tif 000002
【特許請求の範囲】
【請求項１】
データベースストア内でオブジェクトを維持するための方法において、
前記データベースストア内で維持できるオブジェクトのタイプを定義するステップであって、前記タイプの定義はフィールドおよび動作を含むステップと、
前記タイプのインスタンス用に前記データベースストア内のストレージレイアウトを定義する属性によって前記タイプの定義に注釈を付けるステップであって、前記データベースストアは前記タイプの定義内の前記注釈を使用して、前記データベースストア内における前記タイプのインスタンスの前記ストレージレイアウトを制御するステップと
を含むことを特徴とする方法。
【請求項２】
前記タイプの定義に注釈を付ける前記ステップは、
前記フィールドの１つまたは複数のストレージファセットを制御する第１の属性によって前記タイプの各フィールドに注釈を付けるステップと、
同等の構造的なアクセスパスを示す第２の属性によって各動作に注釈を付けるステップと
を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記第１の属性によって制御される前記フィールドの前記ストレージファセットは、前記フィールドの最大サイズ、前記フィールドが固定長であるかどうか、前記フィールドの精度、前記フィールドのスケール、および前記フィールドの値をゼロにできるかどうかの少なくとも１つを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記第２の属性は、前記動作の対象である前記タイプのフィールドの名前を指定することを特徴とする請求項２に記載の方法。
【請求項５】
前記オブジェクトのタイプは、マネージドのコードでクラスとして定義されることを特徴とする請求項１に記載の方法。
【請求項６】
ユーザ定義タイプのインスタンスであるオブジェクトがデータベースストア内で維持されるシステムであって、前記ユーザ定義タイプの定義は１つまたは複数のフィールドおよび動作を含み、前記データベースストア内における前記タイプのインスタンス用のストレージレイアウトを制御する注釈を含み、前記データベースストアは、前記タイプの定義に対する前記注釈によって提供されるように前記ストレージレイアウトを反映する情報を維持するシステムにおいて、前記タイプのインスタンスであるオブジェクト上でクエリを実行する方法であって、
前記タイプのインスタンスであるオブジェクト上でクエリを受け取るステップであって、前記クエリの実行は前記オブジェクトのハイドレーションを必要とする場合があるステップと、
前記データベースストアによって維持される前記情報にアクセスして、前記タイプのインスタンスの前記ストレージレイアウトを決定するステップと、
前記タイプのインスタンスの前記ストレージレイアウトに関する前記情報に基づいて、前記クエリに応答して返される前記タイプのフィールドの値にとって同等の構造的なアクセスパスへと前記クエリを変換するステップと、
前記オブジェクトをハイドレートすることなく前記値に構造的にアクセスするステップと、
前記クエリに応答して前記値を返すステップと
を含むことを特徴とする方法。
【請求項７】
前記タイプの各フィールドは、前記フィールドの１つまたは複数のストレージファセットを制御する第１の属性によって注釈を付けられ、各動作は、同等の構造的なアクセスパスを示す第２の属性によって注釈を付けられることを特徴とする請求項６に記載の方法。
【請求項８】
前記第１の属性によって制御される前記フィールドの前記ストレージファセットは、前記フィールドの最大サイズ、前記フィールドが固定長であるかどうか、前記フィールドの精度、前記フィールドのスケール、および前記フィールドの値をゼロにできるかどうかの少なくとも１つを含むことを特徴とする請求項６に記載の方法。
【請求項９】
前記第２の属性は、前記動作の対象である前記タイプのフィールドの名前を指定することを特徴とする請求項７に記載の方法。
【請求項１０】
前記オブジェクトのタイプは、マネージドのコードでクラスとして定義されることを特徴とする請求項６に記載の方法。
【請求項１１】
ユーザ定義タイプのインスタンスであるオブジェクトが維持されるデータベースストアであって、前記ユーザ定義タイプの定義は１つまたは複数のフィールドおよび動作を含み、前記データベースストア内における前記タイプのインスタンス用のストレージレイアウトを制御する注釈を含み、前記データベースストアは、前記タイプの定義に対する前記注釈によって提供されるように前記ストレージレイアウトを反映する情報を維持するデータベースストアと、
（ｉ）前記ユーザ定義タイプのインスタンスであるオブジェクト上でクエリを受け取り、前記クエリの実行は前記オブジェクトのハイドレーションを必要とする場合があり、（ｉｉ）前記データベースストアによって維持される前記情報にアクセスして、前記タイプのインスタンスの前記ストレージレイアウトを決定し、（ｉｉｉ）前記タイプのインスタンスの前記ストレージレイアウトに関する前記情報に基づいて、前記クエリに応答して返される前記タイプのフィールドの値にとって同等の構造的なアクセスパスへと前記クエリを変換し、（ｉｖ）前記オブジェクトをハイドレートすることなく前記値に構造的にアクセスし、（ｖ）前記クエリに応答して前記値を返すデータベースサーバと
を含むことを特徴とするシステム。
【請求項１２】
前記タイプの各フィールドは、前記フィールドの１つまたは複数のストレージファセットを制御する第１の属性によって注釈を付けられ、各動作は、同等の構造的なアクセスパスを示す第２の属性によって注釈を付けられることを特徴とする請求項１１に記載のシステム。
【請求項１３】
前記第１の属性によって制御される前記フィールドの前記ストレージファセットは、前記フィールドの最大サイズ、前記フィールドが固定長であるかどうか、前記フィールドの精度、前記フィールドのスケール、および前記フィールドの値をゼロにできるかどうかの少なくとも１つを含むことを特徴とする請求項１２に記載のシステム。
【請求項１４】
前記第２の属性は、前記動作の対象である前記タイプのフィールドの名前を指定することを特徴とする請求項１２に記載のシステム。
【請求項１５】
前記オブジェクトのタイプは、マネージドのコードでクラスとして定義されることを特徴とする請求項１１に記載のシステム。
【請求項１６】
ユーザ定義タイプのインスタンスであるオブジェクトがデータベースストア内で維持されるシステムであって、前記ユーザ定義タイプの定義は１つまたは複数のフィールドおよび動作を含み、前記データベースストア内における前記タイプのインスタンス用のストレージレイアウトを制御する注釈を含み、前記データベースストアは、前記タイプの定義に対する前記注釈によって提供されるように前記ストレージレイアウトを反映する情報を維持するシステムにおいて使用するためのプログラムコードをその上に格納しているコンピュータ可読媒体であって、前記プログラムコードは、コンピュータ上で実行されると、
前記タイプのインスタンスであるオブジェクト上でクエリを受け取るステップであって、前記クエリの実行は前記オブジェクトのハイドレーションを必要とする場合があるステップと、
前記データベースストアによって維持される前記情報にアクセスして、前記タイプのインスタンスの前記ストレージレイアウトを決定するステップと、
前記タイプのインスタンスの前記ストレージレイアウトに関する前記情報に基づいて、前記クエリに応答して返される前記タイプのフィールドの値にとって同等の構造的なアクセスパスへと前記クエリを変換するステップと、
前記オブジェクトをハイドレートすることなく前記値に構造的にアクセスするステップと、
前記クエリに応答して前記値を返すステップと
を前記コンピュータに実行させることを特徴とするコンピュータ可読媒体。
【請求項１７】
前記タイプの各フィールドは、前記フィールドの１つまたは複数のストレージファセットを制御する第１の属性によって注釈を付けられ、各動作は、同等の構造的なアクセスパスを示す第２の属性によって注釈を付けられることを特徴とする請求項１６に記載のコンピュータ可読媒体。
【請求項１８】
前記第１の属性によって制御される前記フィールドの前記ストレージファセットは、前記フィールドの最大サイズ、前記フィールドが固定長であるかどうか、前記フィールドの精度、前記フィールドのスケール、および前記フィールドの値をゼロにできるかどうかの少なくとも１つを含むことを特徴とする請求項１６に記載のコンピュータ可読媒体。
【請求項１９】
前記第２の属性は、前記動作の対象である前記タイプのフィールドの名前を指定することを特徴とする請求項１７に記載のコンピュータ可読媒体。
【請求項２０】
前記オブジェクトのタイプは、マネージドのコードでクラスとして定義されることを特徴とする請求項１６に記載のコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はコンピュータシステム内のデータストレージに関し、より詳細には、データベースストア内でオブジェクトを維持するためのシステムおよび方法に関する。
【背景技術】
【０００２】
Ｍｉｃｒｏｓｏｆｔ  ＳＱＬ  ＳＥＲＶＥＲは、豊富な管理ツールおよび開発ツール、強力なＥＴＬ（Ｅｘｔｒａｃｔｉｏｎ，Ｔｒａｎｓｆｏｒｍａｔｉｏｎ，ａｎｄ  Ｌｏａｄｉｎｇ）ツール、ビジネスインテリジェンスおよび分析サービス、ならびに他の機能を提供する総合的なデータベース管理プラットフォームである。最近、ＳＱＬ  ＳＥＲＶＥＲに対して２つの改良が行われた。第１に、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）  ．ＮＥＴ  Ｆｒａｍｅｗｏｒｋ  Ｃｏｍｍｏｎ  Ｌａｎｇｕａｇｅ  Ｒｕｎｔｉｍｅ（ＣＬＲ）がＳＱＬ  ＳＥＲＶＥＲデータベースに統合され、第２に、ユーザ定義タイプ（ＵＤＴ）と呼ばれる新しいオブジェクトを、マネージドのコードによってＣＬＲ環境内で作成し、データベースストア内で維持できるようになった。
【０００３】
ＣＬＲはＭｉｃｒｏｓｏｆｔ  ．ＮＥＴ  Ｆｒａｍｅｗｏｒｋの中核をなすものであり、すべての．ＮＥＴコード用の実行環境を提供する。したがってＣＬＲ内で実行されるコードは、「マネージドのコード」と呼ばれる。ＣＬＲは、ジャストインタイム（ＪＩＴ）のコンパイル、メモリの割り当ておよび管理、タイプの安全性の強化、例外処理、スレッドの管理およびセキュリティなど、プログラムの実行に必要なさまざまな機能およびサービスを提供する。ＣＬＲは、．ＮＥＴルーチンを最初に呼び出す際にＳＱＬ  ＳＥＲＶＥＲによってロードされるようになった。
【０００４】
ＳＱＬ  ＳＥＲＶＥＲのかつてのバージョンでは、データベースプログラマは、サーバサイドでコードを作成する際にＴｒａｎｓａｃｔ−ＳＱＬを使用することに限定されていた。Ｔｒａｎｓａｃｔ−ＳＱＬは、国際標準化機構（ＩＳＯ）および米国規格協会（ＡＮＳＩ）によって定義された構造化照会言語の拡張である。データベース開発者は、Ｔｒａｎｓａｃｔ−ＳＱＬを使用して、データベースおよびテーブルの作成、修正、および削除、ならびにデータベース内に保存されているデータの挿入、検索、修正、および削除を行うことができる。Ｔｒａｎｓａｃｔ−ＳＱＬは、構造的なデータに直接アクセスして操作するように特に設計されている。Ｔｒａｎｓａｃｔ−ＳＱＬは、構造的なデータへのアクセスおよび管理に優れているが、Ｖｉｓｕａｌ  Ｂａｓｉｃ  ．ＮＥＴおよびＣ＃のように成熟したプログラミング言語ではない。たとえばＴｒａｎｓａｃｔ−ＳＱＬは、アレイ、コレクション、各ループ用にはビットシフティング、またはクラスをサポートしていない。
【０００５】
ＣＬＲがＳＱＬ  ＳＥＲＶＥＲデータベースに統合されたことによって、データベース開発者は、Ｔｒａｎｓａｃｔ−ＳＱＬ  だけでは達成が不可能または困難であったタスクを実行できるようになった。Ｖｉｓｕａｌ  Ｂａｓｉｃ  ．ＮＥＴおよびＣ＃は双方とも、アレイ、構造化された例外処理、およびコレクション用のフルサポートを提供する現代的なプログラミング言語である。開発者はＣＬＲの統合を活用して、より複雑な論理を有し、計算タスクにさらに適したコードをＶｉｓｕａｌ  Ｂａｓｉｃ  ．ＮＥＴおよびＣ＃などの言語を使用して作成することができる。
【０００６】
またＳＱＬ  ＳＥＲＶＥＲは、ＣＬＲの統合に加えてユーザ定義タイプ（ＵＤＴ）用のサポートも追加しており、この新しいメカニズムによって、開発者はデータベースのスカラタイプシステムを拡張することができる。ＵＤＴは、アプリケーションアーキテクチャの観点から２つの主要な利点を提供する。第１に、（クライアントとサーバの双方で）内部状態と外的動作の間における強力なカプセル化を提供し、第２に、関連する他のサーバ機能との奥深い統合を提供する。ＵＤＴは、いったん定義されると、列の定義、変数、パラメータ、関数の結果、カーソル、トリガ、および複製においてなど、システムタイプをＳＱＬ  ＳＥＲＶＥＲ内で使用できるすべてのコンテキストにおいて使用することができる。
【０００７】
データベースサーバ上でＵＤＴを定義するプロセスは、次のようにして実行される。
ａ）ＵＤＴ作成用のルールに従うマネージドのコードでクラスを作成し、
ｂ）ＣＲＥＡＴＥ  ＡＳＳＥＭＢＬＹステートメントを使用して、ＵＤＴを含むアセンブリをサーバ上のデータベースにロードし、
ｃ）マネージドのコードをＵＤＴに公開するＣＲＥＡＴＥ  ＴＹＰＥステートメントを使用して、データベース内にタイプを作成する。
この時点で、ＵＤＴをテーブル定義において使用することができる。
【０００８】
ＵＤＴ定義がマネージドのコードで作成される際、タイプは次の要件を満たさなければならない。
ａ）Ｓｅｒｉａｌｉｚａｂｌｅとしてマークされなければならない。
ｂ）ＳｑｌＵｓｅｒＤｅｆｉｎｅｄＴｙｐｅＡｔｔｒｉｂｕｔｅによって装飾されなければならない。
ｃ）タイプはＩＮｕｌｌａｂｌｅインターフェースを実装することによって、ＮＵＬＬを認識すべきである。
ｄ）タイプは、引数を取らない公開されたコンストラクタを有していなければならない。
ｅ）タイプは次のメソッドを実施することによって、文字列との間における変換をサポートすべきである。
１．Public String ToString()、および
２．Public Shared <type> Parse (SqlString s)
【０００９】
図１は、前述のプロセスに従ってＵＤＴを定義するクラスの例である。次いで前述のステップに従って、このクラスはダイナミックリンクライブラリ（ｄｌｌ）へとコンパイルされる。そしてコンパイルされたクラスを含むアセンブリが、次のＴ−ＳＱＬスクリプトコマンドを使用して作成される。
【００１０】
【表１】
2007509425.tif 000003
【００１１】
そして次のＴ−ＳＱＬスクリプトコマンドを使用して、サーバ上でＵＤＴを作成する。
【００１２】
【表２】
2007509425.tif 000004
【００１３】
サーバ上でＵＤＴが作成されると、テーブルの属性をＵＤＴタイプと定義して、次のようにテーブル（たとえば「ＭｙＴａｂｌｅ」）を作成することができる。
【００１４】
【表３】
2007509425.tif 000005
【００１５】
次のように、新しいアイテムをテーブルに追加することができる。
【００１６】
【表４】
2007509425.tif 000006
【００１７】
次いでSELECT Item.ID, Item.Name FROM MyTableなどのＵＤＴの式をクエリ内で使用することができる。
【００１８】
ＣＬＲがＳＱＬ  ＳＥＲＶＥＲに統合され、マネージドのコードでクラス定義からＵＤＴを定義できることによって、アプリケーションは、マネージドのコードのクラスによって定義されたタイプのオブジェクトのインスタンスを作成して、それらのオブジェクトをＵＤＴのインスタンスとしてリレーショナルデータベースストア内で維持できるようになった。さらにＵＤＴを定義するクラスは、そのタイプのオブジェクト上で特定の動作を実施するメソッドを含むこともできる。したがってアプリケーションは、ＵＤＴとして定義されたタイプのオブジェクトのインスタンスを作成することができ、それらの上でマネージドの動作を呼び出すことができる。
【００１９】
ＵＤＴとして定義されているクラスのオブジェクトのインスタンスがＣＬＲ内で作成されると、オブジェクトのシリアライゼーションのプロセスを通じてデータベースストア内でそのオブジェクトを維持することができ、そのクラスの変数の値は物理的なストレージ（たとえばハードディスク）に転送される。図２は、メモリ内のオブジェクトが、ディスク上で維持される形態へシリアライズされる様子を示している。オブジェクトは、図３に示されているフォーマットの従来のリレーショナルデータベーステーブル内におけるデータベースストア内で維持することができる。図示されているように、テーブルは指定されたＵＤＴの列を含む。指定されたＵＤＴの維持されるオブジェクトのシリアライズされた値が、ＵＤＴ列の１つのセルを占めている。
【発明の開示】
【発明が解決しようとする課題】
【００２０】
再び図２を参照すると、アプリケーションが、データベースストア内で維持されているＵＤＴオブジェクトのマネージドの動作（たとえば、ＵＤＴオブジェクトのフィールドの値を返す動作）を参照する述部または式を含むクエリを作成する場合、維持されるオブジェクトは、デシリアライズ(de-serialized)（「ハイドレーティング」(hydrating)と呼ばれる場合もある）されなければならず、ＣＬＲはその保存された値を受け取るためにフルオブジェクト用のメモリを割り当てなければならない。次いでＣＬＲは、アプリケーションが希望する動作を実施する実際のメソッドを呼び出さなければならない。あいにく、ランタイムにフルオブジェクトを保存するためのメモリを割り当てること、オブジェクトのすべての部分をデシリアライズして投入すること、および要求された動作を実施するメソッドを呼び出すことに関連する処理オーバーヘッドは、負担になる場合がある。したがって、データベースストア内に維持されるオブジェクトのより効率的な保存および検索を提供するシステムおよび方法に対するニーズがある。本発明は、このニーズを満たすものである。
【課題を解決するための手段】
【００２１】
本発明は、基礎をなすデータストアにＵＤＴの構造に関する情報を伝達できるようにするデータベースストア内におけるユーザ定義タイプ（ＵＤＴ）用の新しい維持フォーマットを提供するシステムおよび方法を対象とする。この情報によって、タイプのメンバへの直接的で構造的なアクセスを含む複数のストア最適化が可能となる。特に本発明は、タイプインプリメンタとデータストアの間でメタデータの交換を可能にする。ストアはメタデータを使用して、タイプのインスタンス用のストレージレイアウトを決定する。この情報によってストアは、オブジェクトのハイドレーション(hydration)（デシリアライゼーション）(deserialization)を伴わずにストレージ表現(storage representation)上で直接動作するように最適化できるアクセスパターンを検出することができる。さらにシステムは、構造的なアクセスのみのオペレーションを理解することによって、計算された値を必要以上に維持するよう要求することなく、個々のメンバにわたるデータ分布統計およびインデックスを作成することができる。
【００２２】
本発明の他の特徴および利点は、後述の本発明に関する詳細な説明および添付の図面から明らかにすることができる。
【００２３】
前述の概要、ならびに後述の本発明に関する詳細な説明は、添付の図面と併せて読めば、よりよく理解することができる。本発明を説明する目的で、図面には本発明のさまざまな態様の典型的な実施形態が含まれているが、本発明は、開示されている特定の方法および手段に限定されるものではない。
【発明を実施するための最良の形態】
【００２４】
本発明の主題は、法的要件を満たすために具体的に説明されている。しかしこの説明自体は、この特許の範囲を限定することを意図するものではない。むしろ特許請求されている主題は、現在または将来における他の技術と共に使用できる、この書類に記載したものと類似した異なるステップまたは要素を含む他の方法で具体化できることを発明者は考慮している。さらに「ステップ」という用語は、本明細書では、採用される方法の異なる側面を示すために使用される場合があるが、この用語は、各ステップの順序が明示されていない限り、本明細書に開示されるさまざまなステップ間における何らかの特定の順序を意味するものと解釈すべきではない。
【００２５】
前述のように、本発明は、基礎をなすデータストアにＵＤＴの構造に関する情報を伝達できるようにするデータベースストア内におけるユーザ定義タイプ（ＵＤＴ）用の新しい維持フォーマットを提供するシステムおよび方法を対象とする。この情報によって、タイプのメンバへの直接的で構造的なアクセスを含む複数のストア最適化が可能となる。特に本発明は、タイプインプリメンタとデータストアの間でメタデータの交換を可能にする。ストアはメタデータを使用して、タイプのインスタンス用のストレージレイアウトを決定する。この情報によってストアは、オブジェクトのハイドレーション（デシリアライゼーション）を伴わずにストレージ表現上で直接動作するように最適化できるアクセスパターンを検出することができる。さらにシステムは、構造的なアクセスのみのオペレーションを理解することによって、計算された値を必要以上に維持するよう要求することなく、個々のメンバにわたるデータ分布統計およびインデックスを作成することができる。「直接的で構造的なアクセス」という用語は、データベースストアが、データストアのテーブル内のオブジェクトをハイドレート（デシリアライズ）する必要なく、そのオブジェクトの維持される値に直接アクセスすることによって、オブジェクト上でクエリを実行できる機能を指す。
【００２６】
図４Ａは、本発明の方法の一態様の一実施形態を示す流れ図である。図示されているように、この方法はステップ４００においてユーザ定義タイプの定義から開始する。大半のＵＤＴと同様に、タイプは、たとえばＶｉｓｕａｌ  Ｂａｓｉｃ  ．ＮＥＴやＣ＃などの高水準プログラミング言語を使用してマネージドのコードでＣＬＲクラスとして定義される。しかし本発明によれば、本発明の新しい維持フォーマットをこのクラス定義に適用するために、ステップ４０２において、ＵＤＴのストレージレイアウトについて記述するメタデータを提供するようにクラス定義に注釈を付ける。メタデータは、タイプのあらゆる動作にとって同等の構造的なアクセスパスを示すことに加えて、サイズ、精度、スケールなど、タイプのフィールドのストレージファセットについて記述することが好ましい。図５は、図１に示したＣＬＲクラスに対して本発明に従って注釈を付けている典型的なコードリストである。この実施形態では、この注釈に対して３つの態様がある。
【００２７】
最初に、ＵＤＴを本発明の新しい維持フォーマットが適用される対象として識別するように、クラス定義に注釈を付ける。この実施形態では、図５の典型的なクラス定義の２行目に示されているように、パラメータ「Ｆｏｒｍａｔ．Ｓｔｒｕｃｔｕｒｅｄ」をクラス定義の［ＳｑｌＵｓｅｒＤｅｆｉｎｅｄＴｙｐｅ（）］属性に追加することによって、これを行う。これによって、データストアに対するＵＤＴは、本発明の維持フォーマットが適用される対象として識別される。
【００２８】
次いで、サイズ、精度、スケールなど、タイプのストレージファセットを制御するストレージ属性によって、クラスの各フィールドに注釈を付ける。この実施形態では、ＳｑｌＵｄｔＦｉｅｌｄ（）という名前のカスタムストレージ属性によって各フィールドに注釈を付けることによって、これを行う。この属性は、さらなるストレージ指示によってフィールドに注釈を付ける。これらの指示は、オブジェクトがディスクにシリアライズされる際に実行される。この実施形態では、ＳｑｌＵｄｔＦｉｅｌｄ（）カスタム属性のプロパティ（すなわち、与えることができる指示）は次のとおりである。
【００２９】
【表５】
2007509425.tif 000007
【００３０】
しかし本発明は、決して示されているプロパティに限定されるものではないことを理解することができる。むしろ他の実施形態では、この属性によってさらなるプロパティまたは他のプロパティを指定することができる。
【００３１】
この実施形態では、次のフィールドタイプがＦｏｒｍａｔ．Ｓｔｒｕｃｔｕｒｅｄ  ＵＤＴ内で認められている。ＳｑｌＢｏｏｌｅａｎ、ＳｑｌＢｙｔｅ、ＳｑｌＩｎｔｌ６、ＳｑｌＩｎｔ３２、ＳｑｌＩｎｔ６４、ＳｑｌＳｉｎｇｌｅ、ＳｑｌＤｏｕｂｌｅ、ＳｑｌＤａｔｅＴｉｍｅ、ＳｑｌＭｏｎｅｙ、ＳｑｌＧｕｉｄ、ＳｑｌＤｅｃｉｍａｌ、ＳｑｌＳｔｒｉｎｇ、ＳｑｌＢｉｎａｒｙ、ＳｑｌＸｍｌＲｅａｄｅｒ、ＳｑｌＢｙｔｅｓ、ＳｑｌＣｈａｒｓ、ＳｑｌＵｔｃＤａｔｅＴｉｍｅ、ＳｑｌＤａｔｅ、ＳｑｌＴｉｍｅ、およびＥｍｂｅｄｄｅｄ  ＵＤＴｓ。もちろん他の実施形態では、これらのフィールドタイプのいくつかが認められない場合もあり、他のフィールドタイプが認められる場合もある。次のテーブルは、特定のフィールドタイプ用のさまざまなプロパティの有効な値のマトリックスを反映している。「Ｙ」は有効なプロパティを意味し、「Ｎ」は有効でないプロパティを意味し、「Ｒ」は必要なプロパティを意味している。プロパティが無効である場合、そのプロパティ用の非デフォルト値が指定されていると、タイプの登録はエラーを報告する。他の実施形態では、これらの制限および制約は異なる場合がある。
【００３２】
【表６】
2007509425.tif 000008
【００３３】
図５の典型的なコードリストを参照すると、典型的なＵＤＴクラス定義の各フィールドに注釈を付けるために、５、８、３７、および４９行目にＳｑｌＵｄｔＦｉｅｌｄ（）カスタム属性が追加されている。
【００３４】
クラス定義の注釈の第３の態様として、ＣＬＲクラス内で定義されるあらゆるマネージドの動作（たとえば、フィールドの値を返すためにＵＤＴオブジェクト上で呼び出すことができるメソッド）に対して、そのマネージドの動作にとって同等の構造的なアクセスパスを示す属性によって注釈を付ける。この実施形態では、この目的で使用されるカスタム属性はＳｑｌＵｄｔＰｒｏｐｅｒｔｙ（）と名づけられ、データベースサーバ（たとえばＳＱＬ  ＳＥＲＶＥＲ）は、このカスタム属性によって注釈を付けられたプロパティの実施が、属性定義の一部として指定されたフィールドに委譲されるとみなす。これによってサーバは、インスタンスを作成してその上で動作を呼び出すことなく、プロパティへの構造的なアクセスを最適化することができる。ＳｑｌＵｄｔＰｒｏｐｅｒｔｙ（）カスタム属性のプロパティは、次のとおりである。
【００３５】
【表７】
2007509425.tif 000009
【００３６】
ＳｑｌＵｄｔＰｒｏｐｅｒｔｙの存在は、プロパティの本体を無視することができ、フィールドの名前が構造的なアクセスパスとして使用されることを示している。この実施形態ではプロパティのアクセス機構(accessor)が、構造的にアクセスできる唯一の動作である。しかし他の実施形態では、他のタイプのメソッドも構造的なアクセスが可能な場合がある。
【００３７】
図５の典型的なコードリストを参照すると、クラスのそれぞれのマネージドの動作に注釈を付けるために、ＳｑｌＵｄｔＰｒｏｐｅｒｔｙ（）カスタム属性が１１および２４行目に追加されている。
【００３８】
再び図４Ａを参照すると、ステップ４０４において、ＵＤＴの作成者によって定義されたようにＵＤＴがデータベースサーバ上で作成され、クラス定義の注釈内に反映されたメタデータがデータベースストアにインポートされ、データベースストアはそのメタデータを使用して、タイプのインスタンス用のストレージレイアウトを決定する。特に、ＳｑｌＵｄｔＦｉｅｌｄ属性を所与のフィールドの実際のタイプと共に使用して、そのフィールドの維持される値のストレージレイアウトを制御する。たとえば、フィールドをゼロにすることができると属性が示している場合、ストレージを処理するデータベースシステムのコンポーネントは、このフィールド用のヌル値を保存するために使用されるエリア内のビットを取っておくことができる。別の例として、フィールドが（文字列のように）サイズが変化するタイプである場合、属性は、フィールドが実際は固定されたサイズであることを示すことができる。この情報は、このフィールドを値の固定サイズ部分に保存することによって、このフィールドへのアクセスを最適化するために、データベースシステムによって再び使用することができる。ＳｑｌＵｄｔＦｉｅｌｄ属性上のファセットがストレージレイアウトにどのような影響を与えるかに関する詳細は、データベースシステムの特定のストレージレイアウトの選択に依存している。したがって上記の考察は、こうした属性がＵＤＴのインスタンスのストレージレイアウトをどのようにして制御できるかについて２つの例しか提供していないが、本発明は決してそれらに限定されるものではないことを理解することができる。
【００３９】
この実施形態では、方法のステップ４０４は、（１）ＵＤＴを定義するＣＬＲクラスファイルをダイナミックリンクライブラリ（．ｄｌｌ）にコンパイルするステップと、（２）ＵＤＴを含むアセンブリを作成してストアに登録するステップと、（３）マネージドのタイプ上でＵＤＴを作成するステップとによって実行される。ステップ（３）の一部として、タイプのストレージファセットを有効にし、ＣＬＲクラス定義に対する注釈内に反映されたメタデータ情報が、タイプの構造について記述するデータベースシステムカタログにインポートされる。この実施形態では、これらのステップは、次のＴ−ＳＱＬスクリプトコマンドを使用して実行することができる。
【００４０】
【表８】
2007509425.tif 000010
【００４１】
次いでＵＤＴのインスタンスをマネージドのコードで作成することができ、あらゆるＵＤＴと同様に、それらのオブジェクトをデータベースストアのテーブル内で維持することができる。他の実施形態では、特にＳＱＬ  ＳＥＲＶＥＲ以外のデータベースサーバを採用できる実施形態では、ＵＤＴがどのように登録され、データベースストアとの間でメタデータ情報がどのように交換されるかに関する詳細は異なる場合があることを理解することができる。
【００４２】
図４Ｂは、たとえば前述の「Ｆｏｒｍａｔ．Ｓｔｒｕｃｔｕｒｅｄ」プロパティによって注釈を付けられたＵＤＴなど、本発明の新しい維持フォーマットを適用しているＵＤＴの値にアクセスするための方法を示す流れ図である。本発明の方法によれば、ステップ４０６に示されているように、データベースサーバは、本発明の方法が適用されているデータベースストア内で維持されているオブジェクトのマネージドの動作を参照する述部または式を含むクエリを受け取る。たとえば「Ｐｅｒｓｏｎ」という名前のＦｏｒｍａｔ．Ｓｔｒｕｃｔｕｒｅｄ  ＵＤＴが作成され、これは「Ｎａｍｅ」と呼ばれるタイプＳｑｌＳｔｒｉｎｇのフィールドを含み、これに対しては前述のようにＳｑｌＵｄｔＦｉｅｌｄ（）属性によって適切に注釈を付けているものとする。またＰｅｒｓｏｎタイプは、タイプのインスタンスの「Ｎａｍｅ」フィールドの値を返すマネージドの動作を有し、その動作に対してはＳｑｌＵｄｔＰｒｏｐｅｒｔｙ（）属性によって適切に注釈を付けているものとする。データベースサーバは、Ｐｅｒｓｏｎオブジェクト上で次のクエリを受け取ることができる。
SELECT Person.Name FROM T
ここでのＴは、Ｐｅｒｓｏｎと呼ばれるＵＤＴ列を含むテーブルである。
【００４３】
背景技術のセクションで前述したように、ＳＱＬ  ＳＥＲＶＥＲの場合、本発明の新しい維持フォーマットが適用されないＵＤＴにとって、クエリは次のように処理される。クエリのコンパイル時に、Ｎａｍｅがタイプ上で有効なプロパティであることを判定するために、ＵＤＴ用のアセンブリメタデータが検査される。次いで、Ｐｅｒｓｏｎオブジェクトのデシリアライズされたインスタンス上でＮａｍｅプロパティを呼び出すために、ヘルパ関数がオンザフライで作成される。デシリアライゼーションは、これもまたオンザフライで作成されるタイプ固有のデシリアライザによって実施される。前述のように、デシリアライゼーションのプロセスは、オンディスク表現のコンテンツを使用して新しいマネージドのオブジェクトの内部に投入するステップを含む。内部では、クエリ
SELECT person.Name FROM Tは、
【００４４】
【表９】
2007509425.tif 000011
【００４５】
に変換される。
【００４６】
作成される新しいコードはすべて、関数ＩｎｖｏｋｅＵｄｆＥｘｔｅｒｎａｌ内にカプセル化され、これをランタイムに使用して、この式の値を求める。
【００４７】
しかし本発明によれば、ステップ４０８に示されているように、クエリは異なる方法で処理される。具体的には、クエリオペレーションは、データベースのシステムカタログ内に保存されているメタデータに基づいて、その同等の構造的なアクセスパスに変換される。ＳＱＬ  ＳＥＲＶＥＲデータベース内で本発明を実施する、今説明している実施形態では、クエリのコンパイル時に、Ｎａｍｅが構造的なアクセス用に書き換えることができるプロパティであることを判定するために、ＵＤＴ用のアセンブリメタデータが検査される。これを構造的に実行できる場合、ｓｑｌメタデータおよびアセンブリメタデータを使用して、物理的なアクセス情報（値の場所、タイプ、およびサイズ、ならびにそこに至るアクセスパス）について判断する。この構造的なメタデータを使用してアクセス機構をコンパイルし、コンパイルされた式にこの情報を保存する。したがってこの実施形態では、上記と同じクエリは代わりに
Select binding.GetData(personDatum, NameOrdinal) from T
へとコンパイルされる。
【００４８】
次いでステップ４１０において、要求されているフィールドの値は構造的にアクセスされ、オブジェクトのハイドレーションの必要なく、またマネージドのコードでいかなる動作を呼び出すこともなく、ユーザに返すことができるようになる。特にこの実施形態では、ランタイムにアクセス機構を使用してフィールドをフェッチする。内部では、アクセス機構の実施はシリアライズされたフォームを解析し、プロパティを返す。
【００４９】
図６は、図４Ｂで示した方法を実施するシステムを示すブロック図である。（１）に示されているように、アプリケーションは、本発明の方法が適用されているデータベースストア内で維持されているオブジェクトのマネージドの動作を参照する述部または式を含むクエリを作成する。データベースサーバのクエリ処理システムは、（２）に示されているように、ＵＤＴに関連付けられた保存されているメタデータを使用して、クエリを同等の構造的なアクセスパスへと変換する。次いで（３）に示されているように、値は構造的にアクセスされ、オブジェクトのハイドレーションを伴わずに、またオブジェクト上で動作を呼び出すこともなく、アプリケーションに返される。
【００５０】
開発者は、オブジェクトのハイドレーションを伴わずにＵＤＴオブジェクトのフィールドへの構造的なアクセスを提供できる本発明の機能に基づいて、さらなる最適化を可能にすることができる。たとえば本発明によって開発者は、構造的にアクセス可能なＵＤＴオペレーション上に計算された列のインデックスを作成することができ、その列を必要以上に維持する必要はない。本発明によって提供される、値への直接的で構造的なアクセスを使用して、その値の実際のタイプや、埋め込まれたさらに大きな値をその値が含んでいるかどうかなど、その値から興味深い情報を検索することができる。また本発明を使用して、サービスおよびデータをアップグレードする予定に応じて値を構造的に変換することもできる。さらに本発明を使用して、値を１つのドメイン（ストア）から別のドメイン（ストア）にさらに効率よく移動およびインポート／エクスポートすることができる。
【００５１】
上記から明らかなように、本発明のさまざまなシステム、方法、および態様のすべてまたは一部は、ハードウェア、ソフトウェア、または双方の組合せにおいて具体化することができる。ソフトウェアにおいて具体化する場合、本発明の方法および装置、または特定の態様、あるいはその一部は、プログラムコード（すなわち命令）の形態で具体化することができる。このプログラムコードは、フロッピー（登録商標）ディスケット、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、磁気テープ、フラッシュメモリ、ハードディスクドライブを含むがそれらには限定されない磁気的、電気的、または光学的ストレージ媒体などのコンピュータ可読媒体、あるいは他の任意の機械可読ストレージ媒体上に保存することができ、このプログラムコードがコンピュータやサーバなどのマシンにロードされ、そうしたマシンによって実行されると、そうしたマシンは、本発明を実施するための装置となる。その上でこのプログラムコードを実行するコンピュータは一般に、プロセッサ、そのプロセッサによって読み取ることができるストレージ媒体（揮発性および不揮発性のメモリおよび／またはストレージ要素を含む）、少なくとも１つの入力デバイス、ならびに少なくとも１つの出力デバイスを含むであろう。このプログラムコードは、高水準の手続き型またはオブジェクト指向のプログラミング言語で実装することができる。あるいはこのプログラムコードは、アセンブリ言語またはマシン言語で実装することもできる。いずれの場合も、その言語はコンパイラ型言語またはインタープリタ型言語とすることができる。
【００５２】
また本発明はプログラムコードの形態で具体化することができ、このプログラムコードは、電気配線またはケーブル、光ファイバなどの何らかの伝送媒体を介して、ローカルエリアネットワーク、ワイドエリアネットワーク、インターネット、イントラネットなどのネットワークを介して、あるいは他の任意の伝送形態を介して伝送され、このプログラムコードがコンピュータなどのマシンに受信およびロードされ、そのマシンによって実行されると、そのマシンは、本発明を実施するための装置となる。
【００５３】
このプログラムコードは、汎用プロセッサ上に実装されると、そのプロセッサと一体化して、特定の論理回路と同様に動作する独特な装置を提供することができる。
【００５４】
さらに本発明は、コンピュータネットワークの一部として、または分散コンピューティング環境内に配置できる任意のコンピュータあるいは他のクライアントまたはサーバデバイスと共に実装することができる。この点に関して本発明は、任意の数のメモリユニットまたはストレージユニットと、任意の数のストレージユニットまたはボリュームにわたって発生する任意の数のアプリケーションおよびプロセスとを有し、本発明によるデータベースストア内でオブジェクトを維持するためのプロセスと共に使用できる任意のコンピュータシステムまたは環境に適している。本発明は、ネットワーク環境または分散コンピューティング環境内に配置され、リモートストレージまたはローカルストレージを有するサーバコンピュータおよびクライアントコンピュータを有する環境に適用することができる。また本発明は、リモートサービスまたはローカルサービスに関連する情報を作成、受信、および送信するためのプログラミング言語機能、解釈機能、および実行機能を有するスタンドアロンのコンピューティングデバイスに適用することもできる。
【００５５】
分散コンピューティングは、コンピューティングデバイスとシステムとのやり取りによって、コンピュータリソースおよびコンピュータサービスの共有を容易にする。これらのリソースおよびサービスは、ファイル用の情報交換、キュッシュストレージ、およびディスクストレージを含むが、これらには限定されない。分散コンピューティングはネットワークの接続性を利用し、これによってクライアントは、その結合した能力を活用して企業全体の利益に資することができる。この点に関して、さまざまなデバイスが、本発明のオブジェクト維持方法に関連して実行される処理に関与できるアプリケーション、オブジェクト、またはリソースを有することができる。
【００５６】
図７は、典型的なネットワーク化されたすなわち分散されたコンピューティング環境の概略図を提供する。分散コンピューティング環境は、コンピューティングオブジェクト１０ａ、１０ｂなど、およびコンピューティングオブジェクトまたはデバイス１１０ａ、１１０ｂ、１１０ｃなどを含む。これらのオブジェクトは、プログラム、メソッド、データストア、プログラマブルロジックなどを含むことができる。このオブジェクトは、ＰＤＡ、テレビジョン、ＭＰ３プレーヤ、パーソナルコンピュータなど、同じまたは異なるデバイスの部分を含むことができる。各オブジェクトは、通信ネットワーク１４を介して別のオブジェクトと通信することができる。このネットワークはそれ自体、図７のシステムにサービスを提供する他のコンピューティングオブジェクトおよびコンピューティングデバイスを含むことができ、複数の相互接続されたネットワークを表すことができる。本発明の一態様によれば、各オブジェクト１０ａ、１０ｂなど、または１１０ａ、１１０ｂ、１１０ｃなどは、本発明のオブジェクト維持方法を実施するために用いられるプロセスを使用するよう要求するために、ＡＰＩを利用する可能性のあるアプリケーション、あるいは他のオブジェクト、ソフトウェア、ファームウェア、および／またはハードウェアを含むことができる。
【００５７】
また１１０ｃなどのオブジェクトを別のコンピューティングデバイス１０ａ、１０ｂなど、または１１０ａ、１１０ｂなどの上にホストできることも理解することができる。したがって、示されている物理的な環境は、接続されているデバイスをコンピュータとして示しているかもしれないが、こうした表示は代表的なものにすぎず、代わりに物理的な環境を、ＰＤＡ、テレビジョン、ＭＰ３プレーヤなどのさまざまなデジタルデバイス、インターフェース、ＣＯＭオブジェクトなどのソフトウェアオブジェクト等を含むものとして示すこともできる。
【００５８】
分散コンピューティング環境をサポートするさまざまなシステム、コンポーネント、およびネットワーク構成がある。たとえばコンピューティングシステムは、有線システムまたは無線システムによって、ローカルネットワークまたは広範に分散されたネットワークによって接続することができる。現在、ネットワークの多くはインターネットに結合されており、これは広範な分散コンピューティング用のインフラストラクチャを提供し、多くの異なるネットワークを包含する。こうしたインフラストラクチャのいずれも、本発明から発生する典型的な通信用に使用することができる。
【００５９】
インターネットとは通常、コンピュータネットワーキングの分野でよく知られているプロトコルのＴＣＰ／ＩＰスイート(TCP/IP suite of protocols)を利用するネットワークおよびゲートウェイの集合を指す。ＴＣＰ／ＩＰとは、「Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ」の頭字語である。インターネットとは、ユーザが（１つまたは複数の）ネットワーク上で対話して情報を共有できるようにするネットワーキングプロトコルを実行するコンピュータによって相互接続された地理的に分散したリモートコンピュータネットワークのシステムと言うことができる。こうした広範な情報の共有によって、インターネットなどのリモートネットワークは、ここまで一般的にオープンシステムへと発展し、開発者はこうしたオープンシステム用に、専門化したオペレーションやサービスを実行するためのソフトウェアアプリケーションを基本的に制約なく設計することができる。
【００６０】
したがってネットワークインフラストラクチャによって、クライアント／サーバ、ピアツーピア、ハイブリッドアーキテクチャなど、多くのネットワークトポロジが可能となる。「クライアント」とは、自分が関連していない別のクラスまたはグループのサービスを使用するクラスまたはグループのメンバである。したがってコンピューティングにおいては、クライアントはプロセス、すなわち大ざっぱに言えば、別のプログラムによって提供されるサービスを要求する命令またはタスクのセットである。クライアントプロセスは、他のプログラムまたはサービス自体に関して仕組みの詳細を何ら「知る」必要なく、要求されたサービスを利用する。クライアント／サーバアーキテクチャ、特にネットワーク化されたシステムでは、クライアントは通常、サーバなどの別のコンピュータによって提供される共有されたネットワークリソースにアクセスするコンピュータである。図７の例では、コンピュータ１１０ａ、１１０ｂなどをクライアント、コンピュータ１０ａ、１０ｂなどをサーバとみなすことができるが、環境に応じていずれのコンピュータをクライアント、サーバ、またはその両方とみなすこともできる。これらのコンピューティングデバイスのいずれもが、本発明のオブジェクト維持技術に関与する方法でデータを処理することができる。
【００６１】
サーバは通常、インターネットなどのリモートまたはローカルネットワークを介してアクセス可能なリモートコンピュータシステムである。クライアントプロセスは第１のコンピュータシステムでアクティブになることができ、サーバプロセスは第２のコンピュータシステムでアクティブになることができ、通信媒体を介して相互に通信し、分散された機能を提供し、これによって複数のクライアントはサーバの情報収集機能を利用することができる。本発明の維持メカニズムに従って利用されるいかなるソフトウェアオブジェクトも、複数のコンピューティングデバイスにわたって分散することができる。
【００６２】
（１つまたは複数の）クライアントおよび（１つまたは複数の）サーバは、プロトコル層によって提供される機能を利用して相互に通信することができる。たとえばハイパーテキスト転送プロトコル（ＨＴＴＰ）は、ワールドワイドウェブ（ＷＷＷ）すなわち「ウェブ」に関連して使用される一般的なプロトコルである。通常、インターネットプロトコル（ＩＰ）アドレスなどのコンピュータネットワークアドレスや、Ｕｎｉｖｅｒｓａｌ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ（ＵＲＬ）などの他の参照を使用して、サーバコンピュータやクライアントコンピュータを相互に識別することができる。ネットワークアドレスはＵＲＬアドレスと呼ばれることもある。通信は、利用可能な任意の通信媒体を介して提供することができる。
【００６３】
したがって図７は、本発明を採用できる、ネットワーク／バスを介してクライアントコンピュータと通信するサーバを有する典型的なネットワーク化されたすなわち分散された環境を示している。ネットワーク／バス１４は、本発明によるポータブルコンピュータ、ハンドヘルドコンピュータ、シンクライアント、ネットワーク化された機器、またはＶＣＲ、ＴＶ、オーブン、ライト、ヒータ等の他のデバイスなどの複数のクライアントデバイスまたはリモートコンピューティングデバイス１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなどを有するＬＡＮ、ＷＡＮ、イントラネット、インターネット、または他の何らかのネットワーク媒体とすることができる。したがって本発明は、自身に関連して維持されているオブジェクトを保持することが望ましい任意のコンピューティングデバイスに適用できると考えられる。
【００６４】
通信ネットワーク／バス１４がインターネットであるネットワーク環境では、たとえばサーバ１０ａ、１０ｂなどは、クライアント１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなどが、ＨＴＴＰなどの複数の知られているプロトコルのいずれかを介して通信するサーバとすることができる。分散コンピューティング環境の特徴ではあるが、サーバ１０ａ、１０ｂなどは、クライアント１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなどとして機能することもできる。
【００６５】
通信は、必要に応じて有線または無線とすることができる。クライアントデバイス１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなどは、通信ネットワーク／バス１４を介して通信する場合も、そうでない場合もあり、それに関連して独立した通信を有する場合もある。たとえばＴＶやＶＣＲの場合、その制御に対してネットワーク化された態様が存在する場合も、存在しない場合もある。各クライアントコンピュータ１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなど、およびサーバコンピュータ１０ａ、１０ｂなどは、さまざまなアプリケーションプログラムモジュールまたはオブジェクト１３５と、ファイルまたはデータストリームの保存や、ファイルまたはデータストリームの（１つまたは複数の）部分のダウンロード、伝送、または移動が可能なさまざまなタイプのストレージ要素またはオブジェクトへの接続またはアクセスとを備えることができる。任意のコンピュータ１０ａ、１０ｂ、１１０ａ、１１０ｂなどは、本発明に従って処理されるデータを保存するためのデータベース、メモリ、または他のストレージ要素２０の保守および更新を担当することができる。したがって本発明は、コンピュータネットワーク／バス１４にアクセスして対話できるクライアントコンピュータ１１０ａ、１１０ｂ等と、クライアントコンピュータ１１０ａ、１１０ｂなど、および他の類似のデバイス、ならびにデータベース２０と対話できるサーバコンピュータ１０ａ、１０ｂ等とを有するコンピュータネットワーク環境内で利用することができる。
【００６６】
図８および以降の考察は、自身に関連して本発明を実施できる適切なコンピューティングデバイスの簡潔な概要を提供することを意図している。たとえば図７に示されているクライアントコンピュータまたはクライアントデバイスおよびサーバコンピュータまたはサーバデバイスのいずれも、この形態をとることができる。しかしハンドヘルド、ポータブル、および他のコンピューティングデバイス、ならびにすべての種類のコンピューティングオブジェクトが、本発明に関連して使用するものとして考えられ、すなわちそのどこからでも、コンピューティング環境内でデータを作成、処理、受信、および／または送信できることを理解すべきである。以降では汎用コンピュータについて記載するが、これは一例にすぎず、本発明は、ネットワーク／バスの相互運用性および対話を有するシンクライアントと共に実施することもできる。したがって本発明は、ごくわずかなまたは最小のクライアントリソースしか関与しないネットワーク化されホストされているサービスの環境、たとえばクライアントデバイスが、機器内に配置されるオブジェクトなどのネットワーク／バスへのインターフェースとしてのみ機能するネットワーク化された環境において実施することができる。要するに、データを保存することができ、あるいはそこからデータを別のコンピュータへ検索または送信することができる任意の場所が、本発明のオブジェクト維持方法の運用にとって望ましい、または適した環境である。
【００６７】
必須ではないが、本発明は、デバイスまたはオブジェクト用のサービスの開発者が使用するために、オペレーティングシステムを介して実施することができ、および／または本発明に従って動作するアプリケーションまたはサーバソフトウェア内に含めることができる。クライアントワークステーション、サーバ、他のデバイスなどの１つまたは複数のコンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令という一般的な文脈においてソフトウェアについて説明することができる。一般にプログラムモジュールは、特定のタスクを実行したり特定の抽象データ型を実装したりするルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。通常、プログラムモジュールの機能は、さまざまな実施形態において必要に応じて結合または分散することができる。さらに本発明は、他のコンピュータシステム構成およびプロトコルと共に実施することができる。本発明と共に使用するのに適する可能性のある他のよく知られたコンピューティングシステム、環境、および／または構成としては、パーソナルコンピュータ（ＰＣ）、現金自動預け払い機、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラム可能な家庭用電化製品、ネットワークＰＣ、機器、ライト、環境制御要素、ミニコンピュータ、メインフレームコンピュータなどがあるが、これらには限定されない。
【００６８】
したがって図８は、本発明を実施できる適切なコンピューティングシステム環境１００の一例を示しており、上記から明らかであるが、このコンピューティングシステム環境１００は適切なコンピューティング環境の一例にすぎず、本発明の使用または機能の範囲に対して何らかの限定を提示することを意図するものではない。またコンピューティング環境１００が、この典型的な動作環境１００内に示されたコンポーネントの任意の１つまたは組合せに関して何らかの依存性または必要性を有すると解釈すべきでもない。
【００６９】
図８を参照すると、本発明を実施するための典型的なシステムは、汎用コンピューティングデバイスをコンピュータ１１０の形態で含む。コンピュータ１１０のコンポーネントは、処理装置１２０と、システムメモリ１３０と、システムメモリを含むさまざまなシステムコンポーネントを処理装置１２０に結合するシステムバス１２１とを含むことができるが、これらには限定されない。システムバス１２１は、メモリバスまたはメモリコントローラと、ペリフェラルバスと、さまざまなバスアーキテクチャのいずれかを使用するローカルバスとを含む複数のタイプのバス構造のいずれにすることもできる。たとえばこうしたアーキテクチャとしては、Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ  ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、および（メザニンバスとしても知られている）Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスがあるが、これらには限定されない。  
【００７０】
コンピュータ１１０は通常、さまざまなコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０によってアクセス可能な、揮発性媒体および不揮発性媒体、ならびに取り外し式媒体および固定式媒体の双方を含む利用可能な任意の媒体とすることができる。たとえばコンピュータ可読媒体は、コンピュータストレージ媒体および通信媒体を含むことができるが、これらには限定されない。コンピュータストレージ媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、他のデータなどの情報を記憶するための任意の方法または技術において実装される揮発性媒体および不揮発性媒体、ならびに取り外し式媒体および固定式媒体を含む。コンピュータストレージ媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気ストレージデバイス、あるいは希望の情報を記憶するために使用可能で、コンピュータ１１０によってアクセス可能な他の任意の媒体を含むが、これらには限定されない。通信媒体は通常、コンピュータ可読命令、データ構造、プログラムモジュール、または搬送波や他の伝送メカニズムなどの変調されたデータ信号内の他のデータを具体化し、何らかの情報伝達媒体を含む。「変調されたデータ信号」という用語は、情報をその信号内で符号化するような方法で設定または変更されたその特性の１つまたは複数を有する信号を意味する。たとえば通信媒体は、有線ネットワークや直接有線接続などの有線媒体と、音波媒体、ＲＦ媒体、赤外線媒体、他の無線媒体などの無線媒体とを含むが、これらには限定されない。また上記のいずれの組合せも、コンピュータ可読媒体の範囲内に含まれるものである。
【００７１】
システムメモリ１３０はコンピュータストレージ媒体を読み取り専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性メモリおよび／または不揮発性メモリの形態で含む。基本入出力システム１３３（ＢＩＯＳ）は、起動中などにコンピュータ１１０内の要素間における情報伝達を補助する基本ルーチンを含み、通常はＲＯＭ１３１内に格納されている。ＲＡＭ１３２は通常、処理装置１２０がすぐにアクセスできるか、および／または処理装置１２０によってその時点で使用されているデータモジュールおよび／またはプログラムモジュールを含む。図８は、例としてオペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示しているが、これらには限定されない。
【００７２】
またコンピュータ１１０は、他の取り外し式／固定式、揮発性／不揮発性コンピュータストレージ媒体を含むこともできる。図８は、例示のみを目的として、固定式の不揮発性の磁気媒体との間で読み取りや書き込みを行うハードディスクドライブ１４１と、取り外し式不揮発性の磁気ディスク１５２との間で読み取りや書き込みを行う磁気ディスクドライブ１５１と、ＣＤ−ＲＷ、ＤＶＤ−ＲＷ、他の光媒体などの取り外し式不揮発性の光ディスク１５６との間で読み取りや書き込みを行う光ディスクドライブ１５５とを示している。典型的な動作環境において使用できる他の取り外し式／固定式、揮発性／不揮発性コンピュータストレージ媒体としては、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどがあるが、これらには限定されない。ハードディスクドライブ１４１は通常、インターフェース１４０などの固定式のメモリインターフェースを介してシステムバス１２１に接続されており、磁気ディスクドライブ１５１および光ディスクドライブ１５５は通常、インターフェース１５０などの取り外し式メモリインターフェースによってシステムバス１２１に接続されている。
【００７３】
図８に示した上述のドライブおよびそれに関連するコンピュータストレージ媒体は、コンピュータ１１０用のコンピュータ可読命令、データ構造、プログラムモジュール、および他のデータの記憶を提供する。たとえば図８において、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を記憶するものとして図示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同一とするか、または異なっていてもよい点に留意されたい。ここでは、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７が最低限異なるコピーであることを示すために、異なる番号を割り当てている。ユーザは、キーボード１６２、およびマウス、トラックボール、タッチパッド等のポインティングデバイス１６１などの入力デバイスを介してコンピュータ１１０にコマンドおよび情報を入力することができる。他の入力デバイス（図示せず）は、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信用アンテナ、スキャナなどを含むことができる。これらの入力デバイスおよび他の入力デバイスは、システムバス１２１に結合されているユーザ入力インターフェース１６０を介して処理装置１２０に接続される場合が多いが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースおよびバス構造によって接続することもできる。またグラフィックスインターフェース１８２をシステムバス１２１に接続することもできる。１つまたは複数のグラフィックスプロセッシングユニット（ＧＰＵ）１８４は、グラフィックスインターフェース１８２と通信することができる。またモニタ１９１や他のタイプのディスプレイデバイスも、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続され、これはビデオメモリ１８６と通信することができる。コンピュータはモニタ１９１に加えて、スピーカ１９７およびプリンタ１９６などの他の周辺出力デバイスを含むこともでき、これは周辺出力インターフェース１９５を介して接続することができる。
【００７４】
コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化されたすなわち分散された環境内で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードとすることができ、図８にはメモリストレージデバイス１８１しか示されていないが、通常はコンピュータ１１０に関連する上述の要素の多くまたはすべてを含む。図８に示されている論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３を含むが、他のネットワーク／バスを含むこともできる。こうしたネットワーキング環境は、家庭、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびインターネットにおいてよく見受けられる。
【００７５】
ＬＡＮネットワーキング環境において使用する場合、コンピュータ１１０は、ネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境において使用する場合、コンピュータ１１０は通常、モデム１７２、またはインターネットなどのＷＡＮ１７３上で通信を確立するための他の手段を含む。モデム１７２は内蔵型または外付け型とすることができ、ユーザ入力インターフェース１６０または他の適切なメカニズムを介してシステムバス１２１に接続することができる。ネットワーク化された環境では、コンピュータ１１０に関連して示されているプログラムモジュール、またはその一部をリモートメモリストレージデバイス内に格納することができる。図８は、例としてリモートアプリケーションプログラム１８５をメモリデバイス１８１上に常駐するものとして示しているが、この形態には限定されない。示したネットワーク接続は代表的なものであり、コンピュータ間に通信リンクを確立する他の手段も使用できることを理解できるであろう。
【００７６】
前述のように、本発明は、データベース管理システム内におけるユーザ定義タイプ用の新しい維持フォーマットを対象としている。本発明の広範な概念から逸脱することなく前述の実施形態に変更を実施できることを理解することができる。たとえば、ここまで本発明の実施形態についてＭｉｃｒｏｓｏｆｔのＳＱＬ  ＳＥＲＶＥＲデータベース管理システムにおいて実施するものとして説明したが、本発明は、ユーザ定義タイプの作成をサポートする任意のデータベース管理システムにおいて具体化できることを理解することができる。したがって本発明は、開示された特定の実施形態に限定されるものではなく、添付の特許請求の範囲によって定義される本発明の趣旨および範囲内に収まるすべての修正を包含することを意図していると理解することができる。
【図面の簡単な説明】
【００７７】
【図１】ユーザ定義タイプ用のマネージドのコードのクラス定義を示す典型的なコードセグメントを示す図である。
【図２】マネージドのコードでインスタンスを作成されたユーザ定義タイプのインスタンスのシリアライゼーションおよびデシリアライゼーションを示すブロック図である。
【図３】ユーザ定義タイプのオブジェクトが維持されているデータベーステーブルを示す図である。
【図４Ａ】本発明の方法の一態様の一実施形態を示す流れ図である。
【図４Ｂ】本発明の方法の別の態様の一実施形態を示す流れ図である。
【図５】本発明に従って注釈を付けられているユーザ定義タイプ用のマネージドのコードのクラス定義を示す典型的なコードセグメントを示す図である。
【図６】本発明を実施できるシステムのブロック図であり、本発明の方法に従ってＵＤＴの維持されるオブジェクトの値に構造的にアクセスし、その値を返す様子を示す図である。
【図７】本発明を実施できるさまざまなコンピューティングデバイスを有する典型的なネットワーク環境を示すブロック図である。
【図８】本発明を実施できる典型的なコンピューティングデバイスを示すブロック図である。
【図１】
2007509425.tif 000012
【図２】
2007509425.tif 000013
【図３】
2007509425.tif 000014
【図４Ａ】
2007509425.tif 000015
【図４Ｂ】
2007509425.tif 000016
【図５】
2007509425.tif 000017
【図６】
2007509425.tif 000018
【図７】
2007509425.tif 000019
【図８】
2007509425.tif 000020
【国際調査報告】
2007509425.tif 000021