型が定義されているデータベースストアの外側でのユーザ定義型フィールドの格納および取得のためのシステムと方法
データベースストアに持続することができるオブジェクトの型をユーザが定義する。タイプの定義は、フィールドおよび挙動を備え、各フィールドは、それぞれのデータタイプを有する。データベースストア外に、型の定義の他のフィールドとは離れたファイルとして格納する型のデータを含むものとして、型の定義の１または複数のフィールドを指定することができる。ユーザ定義型のインスタンスであるオブジェクトを格納する要求を受け取ると、タイプのデータを含むと指定したオブジェクトのいずれかのフィールドの中のデータを、データベースストアの外の、好ましくは、そのデータベースストアを実装したコンピュータのファイルシステム内のファイルの中に記憶する。オブジェクトの他のフィールドの各々の中のデータを、データベースストア内に通常のやり方で記憶する。データベースストアは、永続オブジェクトとデータベースの外にファイルとして格納したフィールドのデータとの間に、リンクまたは参照を維持する。コンピュータのファイルシステムを介して、所与のフィールドのデータをデータベースストア外に格納したファイルへの帯域外（out of band）のアクセスを、アプリケーションに提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連特許）
本発明は、その全体を参照として組込む２００３年１０月２３日提出、米国特許出願１０／６９２，２２７号に対する優先権を主張する。
【０００２】
（著作権表示と承認）
本特許文書の開示の一部には、著作権保護を受ける資料が含まれる。著作権所有者は、特許商標事務所のファイルまたは記録に現れるときは、本特許文書または特許開示を何人が複製することにも異議を申し立てないが、別途の場合はいかなるものであれ著作権権利を留保する。以下の記載は本文書に適用される、「Copyright 2003, Microsoft Corp.」。
【０００３】
本発明は、コンピュータシステムにおけるデータストアに関し、さらに詳細には、型の定義されているデータベースストアの外側でのユーザ定義型フィールドの格納および取得のためのシステムと方法に関する。
【背景技術】
【０００４】
Microsoft SQL SERVERは総合データベース管理プラットホームであって、広範な管理および開発のツール、強力な抽出、変形および読み込み（ETL）のツール、ビジネス情報および解析サービス、並びにその他の能力を備えている。SQL SERVERに対し最近２つの改良を加えた。第１に、Microsoft Windows（登録商標） .NET Framework Common Language Runtime（CLR）がSQL SERVERデータベースに統合され、第２に、ユーザ定義型（UDT）と呼ばれる新たなオブジェクトをCLR環境の中のマネージドコードを用いて作成し、データベースストアの中に永続させることができるようになった。
【０００５】
CLRは、Microsoft .NET Frameworkの中心であって、全ての.NETコード用の実行環境を提供する。したがって、それがCLR内で実行されるコードは、「マネージドコード（managed code）」と呼ぶ。CLRは、ジャストインタイム（JIT）コンパイル、メモリ割当と管理、型の安全性の実行、例外処理、スレッド管理およびセキュリテイを含むプログラム実行に必要な各種の機能とサービスを提供する。ＣＬＲは、現在、.NETルーチンの最初の呼び出しに際してSQL SERVERにより読み込まれる。
【０００６】
前バージョンのSQL SERVERでは、データベースプログラマーがサーバ側のコードを記述する際に、Transact-SQLを用いることに制限されていた。Transact-SQLは、国際標準化機構（ISO）および米国規格協会（ANSI）の定義する構造化照会言語（SQL）を拡張した言語である。Transact-SQLを使用して、データベース開発者はデータベースおよびテーブルの作成、変更および削除を行うことができると同時に、データベースの中に格納されるデータの挿入、取得、変更および削除を行うことができる。Transact-SQLは、直接構造的データアクセスおよび操作のため特に設計されている。Transact-SQLはデータのアクセスと管理に卓越しているけれども、Visual Basic .NETおよびＣ＃のような本格的プログラム言語ではない。Transact-SQLは、配列、コレクション、ループ、ビットシフトまたはクラスをサポートしない。
【０００７】
CLRをSQL SERVERのデータベースに統合することにより、データベース開発者は、Transact-SQL単独では果たすことが不可能か困難であったタスクを実行することができる。Visual Basic .NETとＣ＃の両者は、配列、構造化例外処理、およびコレクションに関する完全なサポートを提供する最新のプログラム言語である。開発者はCLR統合を利用して、Visual Basic .NETおよびＣ＃などの言語を使用して、より複雑なロジックを有し、より計算タスクに適するコードを記述できる。
【０００８】
CLR統合に加えて、SQL SERVERはまたユーザ定義型（UDT）−開発者がデータベースのスカラ型システムを拡張することができる新しいメカニズム−に関するサポートを追加する。UDTは、アプリケーションアーキテクチャの観点から２つの重要な利点を提供する。これらは、内部状態と外部挙動との間に強力なカプセル化（クライアントとサーバの双方において）を提供し、他の関連サーバ機能との高レベルな統合を提供する。一旦UDTを定義すると、SQL SERVERにおいてシステム型を使用することのできるあらゆるコンテキストの中で使用することができる。これらには、列定義、変数、パラメータ、関数の結果、カーソル、トリガ、およびレプリケーションが含まれる。
【０００９】
データベースサーバ上でUDTを定義する処理は、次のようにして果たされる、
ａ）UDT作成のための規則に従って、マネージドコードでクラスを作成する、
ｂ）CREATE ASSEMBLYステートメントを用いて、UDTを含むアセンブリをサーバ上のデータベースに読み取る、および、
ｃ）CREATE TYPEステートメントを用いて、データベースの中にマネージドコードUDTを公開する型を作成する。
この時点で、UDTをテーブル定義の中に使用することができる。
【００１０】
マネージ コードでUDT定義を作成する場合、その型は以下の要件を満たしている必要がある。すなわち、
ａ）Serializableでマークし、
ｂ）SqlUserDefinedTypeAttributeで修飾し、
ｃ）INullableインタフェースを実装して、型でのNULLの使用を許可し、
ｄ）型には、引数を取らないパブリックコンストラクタが含まれている必要があり、および
ｅ）以下のメソッドを実装して、型は文字列への変換および文字列からの変換をサポートする必要がある。
１．Public String ToString()、および
２．Public Shared<type>Parse(SqlString s)。
【００１１】
ここに出願する「データベースストアにおけるオブジェクト永続性のためのシステムと方法」と題する同時係属、同一人出願の特許出願 号（代理人明細書：MSFT−２８５２／３０６８１９．１）は、その全文をここに参照として組込むが、UDTに関するCLRクラス定義のフィールドと挙動が、データベースストアの中のUDTのインスタンスに関するレイアウト構造を記述するストレージ属性を用いて注記を付けられる、ＵＤＴの別の特徴を記述する。具体的に説明すると、UDTを定義するCLRクラスの各フィールドに、サイズ、精度、スケールなどタイプのストレージの相を制御する記憶域属性を用いて注記が付けられる。一実施例において、これは各フィールドにSqlUdtField()と名付けるカスタムストレージを用いて注記を付けることにより果たされる。この属性は追加のストレージの命令を用いてフィールドに注記を付ける。オブジェクトをディスクにシリアル化したときに、この命令を実行する。加えて、CLRクラス内で定義される管理動作（例えば、UDTオブジェクト上で呼び出すことができて、フィールドの値を返すなどをするメソッド）毎に、その管理動作に関して、等価構造のアクセスパスを表示する属性を用いて注記を付ける。一実施例において、この目的に使用されるカスタム属性はSqlUdtProperty()と名付けられ、データベースサーバ（例えば、SQL SERVER）は、このカスタム属性を用いて注記されるプロパティの実施が、属性定義の一部として規定されるフィールドに委記されるものと推定する。これにより、サーバはプロパティに対するアクセスを、インスタンスを作成して挙動をその上に呼び出すことなく、構造的に最適化する。
【００１２】
図１は、UDTを定義するCLRクラスの模範コードリストである。示すように、CLRクラスは上述のようにSqlUdtField()とSqlUdtProperty()のカスタム属性を用いて注記を付けられている。具体的に説明すると、SqlUdtField()カスタム属性は５、８、３７、４９の各行に追加されていて、模範的なＵＤＴのクラス定義について、各フィールドに注記している。SqlUdtProperty()カスタム属性は、１１行と２４行に追加されていて、そのクラスのそれぞれの管理動作を注記している。
【００１３】
ＵＤＴを定義するＣＬＲクラスを、ダイナミックリンクライブラリ（dll）にコンパイルする。その後、以下のT-SQLスクリプトコマンドを用いて、コンパイルするクラスを含むアセンブリを作成する。
create assembly test
from 'c:\test.dll'
go 。
【００１４】
以下のT-SQLスクリプトコマンドを用いて、サーバ上にUDTを作成する。
create type BaseItem
external name [test]:[BaseItem]
go 。
【００１５】
サーバ上にUDTを作成したら、以下のように、テーブルの属性をUDTタイプと定義することにより、テーブル（例えば、「マイテーブル（My table）」を作成することができる。
create table MyTable
(
Item BaseItem,
ItemId as item::ID
)
go 。
【００１６】
次のようにして、新しいアイテムをテーブルに追加することができる。
declare @i BaseItem
set @i = convert(BaseItem,")
insert into MyTable values (@i)
go 。
【００１７】
これで、UDT表現をクエリ内で、SELECT Item.ID,Item.Name FROM MY Tableなどのように使用することができる。
【００１８】
SQL SERVERへのCLRの統合およびクラス定義からマネージドコードでUDTを定義する能力により、アプリケーションは、マネージドコードクラスにより定義されるタイプのオブジェクトのインスタンスを作成することができるので、これらのオブジェクトをリレーショナルデータベースストアの中にUDTとして永続させることができる。その上、UDTを定義するクラスもまた、特定の挙動を実行するメソッドをそのタイプのオブジェクト上にインクルードすることができる。したがって、アプリケーションは、UDTとして定義されるタイプのオブジェクトのインスタンスを作成し、管理動作をその上に呼び出すことができる。
【００１９】
UDTとして定義されているクラスのオブジェクトのインスタンスをCLRの中に作成するとき、クラスの変数の値を物理的ストレージ（例えば、ハードディスク）に転送するオブジェクトシリアライゼイションの処理を通じて、オブジェクトをデータベースストアの中に永続させることができる。図２は、メモリの中のオブジェクトの、ディスク上に持続する形に対するシリアライゼイションを示す図である。オブジェクトは、図３に示すフォーマットの従来のリレーショナルデータベーステーブルのデータベースストアの中に永続させることができる。図示するように、テーブルは規定のＵＤＴの列を含む。規定のUDTの永続性のオブジェクトのシリアル化した値は、UDT列のセルを占有する。
【００２０】
もう一度図２を参照すると、アプリケーションが、データベースストアに永続しているUDTオブジェクトの管理動作（例えば、UDTオブジェクトのフィールドの値を返す挙動）を参照する述語または表現を含むクエリを作成すると、永続性オブジェクトはシリアライゼイションを解除（「ハイドレーティング（hydrating）」と言うこともある）しなければならないので、CLRはその格納値を受け取るためオブジェクト全体のためメモリを割当てなければならない。CLRはこのとき、クエリのサブジェクトである値（単数または複数）を返すUDTクラスの実際のメソッド（すなわち挙動）を呼び出さなければならない。前述の同時係属出願 号（代理人明細書：MSFT−２８５２／３０６８１９．１）に記述するように、ＵＤＴのＣＬＲクラス定義におけるSqlUdtField()およびSqlUdtProperty()の注記を、データベースサーバが使用して、オブジェクトのハイドレーションをする必要なしで、一定のUDTフィールドの値に対し直接構造的アクセスをすることもできる。
【００２１】
SQL SERVERへのCLR統合とUDTの提供の利点を利用する一つの新規技術は、「組織化、検索、およびデータ共用のためのストレージプラットホーム (Storage Platform For Organizing, Serching, And Sharing Data)」との名称で、２００３年８月２１日に申請し、その全文をここに参照として組込む、同一出願による、同時係属特許出願１０／６４６，６４６号に記述するストレージプラットホームである。図４は、同時係属出願に記述するストレージプラットホーム３００のアーキテクチャを示すブロック図である。ストレージプラットホームは、「WinFS」と呼ばれることもある。図４に示すように、ストレージプラットホーム３００はデータベースエンジン３１４上で実行されるデータストア３０２を含む。一実施例において、このデータベースエンジンは、Microsoft SQL SERVERリレーショナルデータベースエンジンなど、リレーショナルデータベースエンジンを含む。
【００２２】
データストア３０２は、以下に完全に記述するように、アイテムおよびアイテム間の関係の形のデータの組織、検索、共用、同期、およびセキュリテイをサポートするデータモデル３０４を実行する。アイテムの具体的なタイプをスキーマ３４０などのスキーマで記述し、ストレージプラットホーム３００は、以下に詳述するように、これらのスキーマを展開するためと同時にこれらのスキーマを拡張するためのツール３４６を提供する。
【００２３】
データストア３０２の中で実行される変更履歴３０６は、データストアに対する変更を追跡する能力を提供する。データストア３０２はまた、セキュリテイ能力３０８および昇進／降格能力３１０をも提供する。データストア３０２はまた、アプリケーションプログラミングインタフェース一式３１２をも備えていて、データストレージプラットホームの能力を利用する別のストレージプラットホーム成分およびアプリケーションプログラム（例えば、アプリケーションプログラム３５０ａ、３５０ｂ、３５０ｃ）にデータストア３０２の能力を公開する。
【００２４】
ストレージプラットホームはさらに、アプリケーションプログラミングインタフェース（API）３２２を含む。これは、アプリケーションプログラム３５０ａ，３５０ｂ，３５０ｃなどのアプリケーションプログラムが、ストレージプラットホームの能力にアクセスし、データベースに格納されるデータにアクセスすることを可能にする。ストレージプラットホームAPI３２２は、OLE DB API ３２４および、Microsoft Windows（登録商標） Win ３２ API ３２６など別のＡＰＩと組み合わせて、アプリケーションプログラムにより使用できる。
【００２５】
ストレージプラットホーム３００はまた、アプリケーションプログラムに対し、ユーザ間またはシステム間でデータの共用を便利にする同期サービス３３０を含む各種のサービス３２８を提供する。例えば、同期サービス３３０は、データストア３０２と同一のフォーマットを有する別のデータストア３４０との相互接続を可能にすると同時に、別のフォーマットを有するデータストア３４２に対するアクセスをも可能にする。ストレージプラットホーム３００はまた、データストア３０２とWindows（登録商標） NTFSファイルシステム３１８など既存ファイルシステムとの相互接続を可能にするファイルシステム能力をも提供する。
【００２６】
少なくともいくつかの実施例では、ストレージプラットホーム３２０は、アプリケーションプログラムに、データを他のシステム上で働かせて、他のシステムと相互作用させることができる追加能力も与える。この能力は、情報エージェントサービス３３４および通告サービス３３２と同時に別のユーティリティ３３６の形など、追加サービス３２８の形で実現される。
【００２７】
少なくともいくつかの実施例では、ストレージプラットホームは、コンピュータシステムのハードウエア／ソフトウエアインタフェースシステムに実現されるか、またはその不可欠部分を形成する。例えば、無制限に、本発明のストレージプラットホームは、オペレーティングシステム、バーチャルマシンマネージャ（VMM）、Common Language Runtime（CLR）またはその機能的等価物、もしくはJava（登録商標） Virtual Machine (JVM）またはその機能的等価物に実現されるか、またはその統合部分を形成する。
【００２８】
その共通ストレージ基盤と、体系化されたデータを通じて、ストレージプラットホームは、消費者、知的労働者および企業のためいっそう効率の良いアプリケーション開発を可能にする。これは、そのデータモデルに固有の能力を利用することができるようにするだけでなく、既存のファイルシステムおよびデータベースアクセスメソッドを取り込んで拡張する豊富で広範な表面積を求めるプログラムを提供する。
【００２９】
以下の記述において、および各種の図面において、本発明のストレージプラットホーム３００を「WinFS」と呼ぶ。しかし、このプラットホームを参照するためこの名称を使用することは、記述のためのみであって、いかなる意味においても限定を意図するものではない。
【００３０】
WinFSプラットホームのデータモデルは、データストレージの単位をアイテム、アイテム拡張、および関連に関して定義する。「アイテム（Item）」とは、ストレージ情報の基本単位である。データモデルは、アイテムとアイテム拡張を宣言するためと、アイテム間の関連を確定するためのメカニズムを提供する。アイテムは、コピー、削除、移動、オープンなどの操作を用いて格納し取得することのできる単位である。アイテムは、交渉、人々、サービス、場所、（各種の）文書など、実社会で容易に理解可能なデータの単位を表すことを目的としている。アイテム拡張は、既存アイテムの定義を拡張する方法で、関連はアイテムの間で定義されるリンクである。
【００３１】
WinFSにおいては、情報の格納のため各種のアイテム型が定義される。例えば、アイテム型は契約、人々、サービス、場所、文書などに関して定義される。各アイテム型は、与えられるアイテムのプロパティと特徴を定義するスキーマによって記述される。例えば、「場所」アイテムは、電子メールアドレス、首都圏、近隣および郵便宛先などのプロパティを持つとして定義される。与えられるアイテム型についてスキーマが定義されると、展開ツールを使用してスキーマをそのアイテム型に対応するCLRクラス定義に翻訳し、次に、WinFSアイテム型のインスタンスをデータベースストアの中に永続させるため、CLRクラス定義から（上述の方法で）データベース記録の中にUDTを作成する。WinFS API 322を用いて、アプリケーション（例えば、アプリケーション３５０ａ、３５０ｂ、３５０ｃ）は、ストレージプラットホームのデータストアからの情報を格納し取得するために、データストアによりサポートされるアイテム型のインスタンスを作成することができる。データストアに格納されるアイテム型の各インスタンスは、それに結合する独特の識別子（例えば、Item_ID）を有する。一実施例においては、各アイテム識別子が、世界的に独特の識別子、すなわち「guid」である。こうして、WinFSプラットホームは、CLR統合とデータベースストアのUDT能力を利用して、プラットホームに情報のアイテムを格納させる。
【００３２】
SQL SERVERの中のどのＵＤＴのインスタンスともと同じく、WinFSアイテムのインスタンスは究極的に、図３に示す方法でデータベースストアのテーブルの中に格納される。このときアプリケーションはクエリをWinFSプラットホームに提出して、検索基準を満たすデータストアから、アイテムを検索し、取得する。図５は、データストアにクエリを実行して、「Person」と言う名のアイテム型のインスタンスを取得する方法を示す。ステップ（１）において、アプリケーションはWinFS API ３２２の「FindALL」メソッドを用いて、特定の検索基準を満たすアイテム全部−この場合は、タイプの「Birthday」フィールドにある値が特定日付（例えば、１９９９年１２月３１日）より大きいPerson型のインスタンス全部−に関するクエリを起動する。ステップ（２）において、WinFS API ３２２が「FindALL」オペレーションをＳＱＬクエリに変換して基礎を成すデータベースエンジン、例えば、SQL SERVERにそれを提出する。ステップ（３）において、データベースエンジンが、対応するPerson UDTのインスタンスに対してクエリを実行し、一致するPerson UDTのインスタンスそれぞれに関して格納されている値を返す。この例においては、ステップ（４）において、データベースストアから返されるビットをADO.NETがCLRオブジェクトに変換し（すなわち、上述のオブジェクトハイドレーションの処理）、それをWinFS API ３２２に返す。ADO.NETは、Microsoft .NET Frameworkの要素で、SQL SERVERなどのデータソースに対するマネージドコードアクセスをCLR経由で設ける。次に、WinFS APIは、Person UDTオブジェクトをラップして、それらをアプリケーションにPerson型として返す。
【発明の開示】
【発明が解決しようとする課題】
【００３３】
データベースストア内にユーザ定義型（UDT）を作成する能力は、強力な能力であるが、この能力をいっそう充実して、デジタル画像、ビデオ、オーディオなどを含む膨大なデータ型などある種のデータ型を、ＵＤＴの定義フィールドとして格納するためのサポートを提供することが望ましい。さらに、UDTの膨大なデータフィールドに対して「帯域外」アクセスを設け、基礎となるデータベースストアのクエリ言語を用いることなく、従来のファイルシステム呼び出し（open、closeなど）を通じて、アクセスすることができるようにすることが望ましい。これらの能力が、上述のWinFSストレージプラットホームのコンテキストの中に備えられることは特に望ましい。これまで、これらの能力は備えられていなかった。
【００３４】
Microsoft SQL SERVER製品は、リレーショナルデータベーステーブルの列全体をFILESTREAMという名の型に指定して、その列のセルの中にあるデータをリレーショナルデータベーステーブルとは別のファイルに格納する能力を備えているが、ユーザ定義型ファイルの個別フィールドを指定して、その方法で格納する能力はない。
【００３５】
IBMのDB２データベース製品には「データリンク（datalinks）」機能があって、これは、ファイルに対する参照を格納することにより、テーブルの中の列をファイルシステムの中のファイルにリンクする能力をサポートする。しかし、これは上述のように、列のセルと参照ファイルとの間のＮ対１の参照モデルを与えるだけなので、セルとファイルとの間の上述のような１対１のモデルに関する必要は依然として存在する。この「データリンク」機能にはまた、次の別途の理由による欠点がある。すなわち、（ｉ）プログラム作成モデルでは、別のファイルのストレージとクエリを、ユーザ定義型内部の正規リレーショナルデータと同一にすることができず、また、（ｉｉ）DB２の「データリンク」機能では、ファイルシステムを通じて参照されるファイルの中に格納される列データの更新をおこなうことができない。
【００３６】
オラクル社の「IFS」製品は、中間層ソフトウエアを用いて、SBM、HTTP、FTP、SMTPなど多数のプロトコルに渡るデータに対するアクセスを提供する。データは、結局データベースに格納される。オラクルIFSは、膨大なデータ型を含む様々な種類のデータの「統合した」表示を提供するけれども、この解決策は、リレーショナルデータベースエンジンと反対に、中間層ソフトウエアの中で実行されるので、上述の必要性を満たすものではない。
【００３７】
最後に、ISO／IEC ９０７５−９：２００３（別名SQL２００３MED）は「データリンク（datalinks）」を新規データ型として提案する。提案された規格によると、データリンクはDATALINKデータ型の値である。データリンクは、SQL環境の一部ではない何かのファイルを参照する。このファイルは、何かの外部ファイルマネージャにより管理されると想定する。データリンクは概念的に、外部ファイルの参照を形成する文字列によって表され、参照は、ISO／IEC ９０７５のこのセクションに定義するオペレータを呼び出すことによりアクセスすることができる。データリンク文字セットと言われる参照の文字セットは、実装時定義である。この提案された規格は、上述の望ましい機能を目指していない。
【００３８】
このように、例えば、デジタル画像、ビデオ、オーディオなどを含む膨大なデータ型など、ユーザ定義型（UDT）の定義フィールドとして格納するためのサポートを提供すると同時に、これら膨大なデータ型に対する「帯域外」アクセスを、在来のファイルシステム呼び出し（open、closeなど）を通じて提供するシステムと方法に関する必要は依然として存在する。本発明は、これらの必要性を満たすものである。
【課題を解決するための手段】
【００３９】
本発明は、例えば、イメージ、ビデオ、オーディオなどを含む膨大なデータ型などある種のデータ型を、データベースストアの中にユーザ定義型のフィールドとして格納するためのシステムおよび方法を指向する。本発明によると、データベースストアに持続することのできるオブジェクトのタイプを、ユーザが定義する。このタイプ定義にはフィールドと挙動が含まれ、各フィールドはそれぞれのデータ型を有する。１または複数のタイプ定義のフィールドは、データベースストア外側のファイルとして、タイプ定義の別のフィールドとは別個に格納するべき型の収容データとして、指定される。ユーザ定義型のインスタンスであるオブジェクトを格納する要求を受け取るとき、オブジェクトのそのように指定されているフィールドのいずれかにあるデータは、データベースストア外側のファイルに格納する。特に、データベースストアを実装するコンピュータのファイルシステムの中に格納するのが好適である。オブジェクトの別のフィールドのそれぞれの中のデータは、通常の方法でデータベースストアの中に格納される。データベースストアは、永続性オブジェクトとデータベースストア外側のファイルとして格納されるフィールドのデータとの間のリンク、または参照を維持する。
【００４０】
本発明のもう１つの態様によれば、アプリケーションには、コンピュータのファイルシステムを通じて、所与のフィールドのデータがデータベースストアの外に格納されているファイルに対して、アクセスが与えられる。さらに詳細に説明すると、アプリケーションが、コンピュータのファイルシステムに対するアプリケーションプログラミングインタフェースを通じて、ファイルを開く呼び出しを生成する。このとき呼び出しは、データベースストアの中のその同一性によりオブジェクトのフィールドを識別する。データベースストアの中のオブジェクトのフィールドの同一性に基づいて、そのフィールドのデータを含むファイルに対するシステムパスを判定する。次に、ファイルを開く呼び出しを、判定したパスを用いて実行する。
【００４１】
こうして、本発明はデータベースストアに持続することのできるオブジェクトのユーザ定義型のフィールドを、データベースストアの外に、すなわち、データベースストアが実施されるコンピュータのファイルシステムの中にあるファイルとして指定して、格納することを可能にする。さらに、ユーザ定義型のそのフィールドのデータを含むファイルに対するアクセスを、コンピュータのファイルシステムを通じて設ける。
【００４２】
本発明のその他の機能および利点は、以下の本発明の詳細な説明および添付図面から明らかになるであろう。
【００４３】
前述の要約は、本発明の詳細な説明と同様に、添付図面との関連で読むとき、更に良く理解されるであろう。本発明の例証の目的で、本発明の各種側面の模範実施例を図面に示すが、本発明は開示する特定の方法と手段に限定されるものではない。
【発明を実施するための最良の形態】
【００４４】
本発明の対象を特異性とともに記述して、法令の要件に対処する。しかし、記述自体は本特許の範囲を限定する意図のものではない。正確には、発明者らは、この請求内容が別の方法でもまた実現され、本文書に記述するものに類似の異なるステップまたは要素を、現在または将来の別の技術と結合して含むことを考慮に入れている。さらに、ここで使用される用語「ステップ」は、採用される方法の異なる側面を意味するけれども、この用語は、個別ステップの順序を明確に記述しているのでない限りおよびその場合を除いて、ここに開示する各種ステップのうちまたはその間の何らかの特別の順序を意味するものと、解釈されないものとする。
【００４５】
上述のように、本発明は、例えば、デジタル画像、ビデオ、オーディオなどを含む膨大なデータ型などある種のデータ型を、データベースストアの中にユーザ定義型のフィールドとして格納するための方法を指向する。本発明によると、データベースストアに持続することのできるオブジェクトのタイプを、ユーザが定義する。タイプ定義にはフィールドと挙動が含まれ、各フィールドはそれぞれのデータ型を有する。１または複数のタイプ定義のフィールドを、データベースストア外側のファイルとして、タイプ定義の別のフィールドとは別個に格納するべき型の収容データとして、指定する。ユーザ定義型のインスタンスであるオブジェクトを格納する要求を受け取り、オブジェクトのそのように指定されているフィールドのいずれかにあるデータをデータベースストアの外側のファイルに格納する。特に、データベースストアを実装するコンピュータのファイルシステムの中に格納するのが好適である。オブジェクトの別のフィールドのそれぞれの中のデータは、通常の方法でデータベースストアの中に格納される。データベースストアは、永続性オブジェクトとデータベースストア外側のファイルとして格納されるフィールドのデータとの間のリンク、または参照を維持する。
【００４６】
図６は、ユーザ定義型の定義の模範的部分コードリストで、本発明の一実施例によって、タイプのインスタンスがデータベースストアの中に持続するとき、その外に格納されるフィールドとするタイプのフィールドの指定を示す。具体的に説明すると、「Person」と言う名のユーザ定義型のためのCLRクラスを示す。構文は、上記発明の背景で記述したように、SQL SERVERデータベースエンジンが使用するものである。しかし、本発明は、決してSQLサーバデータベースエンジンとの使用に限定されるものでなく、正確には、ユーザ定義型をサポートする任意のデータベース管理システムのコンテキストの中で採用することができると理解できる。
【００４７】
図６に示すCLRクラスは、Person型のため２つのフィールドを定義する。一つは「FirstName」と言う名で、データ型SqlStringを有すると定義されており、一つは「PhotoFS」と言う名で、データ型SqlBytesを有すると定義されている。SQL SERVERの中のユーザ定義型のための完全なCLRクラス定義には、上記発明の背景で説明した要件によって（および図１の模範コードリストに示すように）、補足的なフィールドとメソッドがあることを理解できる。例えば、PhotoFSデータフィールドは、この型のインスタンスを表すPersonの写真を含むイメージデータを保持する。このようなデータは、本発明を有利に適用することのできる膨大なデータ型の種類の例である。
【００４８】
本発明によって、この例においては、Person型のPhotoFSフィールドは、型のインスタンスがストアの中に持続するとき、データベースストアの外に格納されるフィールドとして指定される。具体的に説明すると、本実施例において、これは、UDTのCLRクラス定義のフィールドに、指定を与えるカスタム属性の注記を付けることにより果たされる。特に、上記発明の背景で記述したSqlUdtField()カスタム属性の新しいプロパティを作成する。新しいプロパティを「IsFilestream」と呼ぶ。そのプロパティの「true」の値（例えば、IsFilestream＝true）は、Personタイプのこのフィールドが、本発明によって、データベースストアの外にファイルとして格納されるべきであることを示す。しかし、フィールドがそのように指定される特定のメソッドは、この模範的構造に限定されるものではないことが理解される。正確には、基礎を成すデータベースシステムが認識することのできるものであれば、ユーザ定義型の定義に対する任意の型の注記を採用することができる。ユーザ定義型のフィールドに対する注記は、SqlUDTField()カスタム属性のIsFilestreamプロパティを含めて、定義型に結び付くメタデータ一式を定義する。
【００４９】
本実施例においては、IsFilestreamプロパティは、タイプSqlBytesのフィールドに対してのみ適用される。しかし別の実施例のおいては、このプロパティは、望みに応じて、別のデータ型のフィールドに適用される。
【００５０】
さらに本発明によると、ＵＤＴに関するＣＬＲクラスがコンパイルされ、次に、上述のように、例えば、T-SQLスクリプトコマンドCREATE TABLEを用いて、データベースサーバに登録されるとき、データベースエンジンは、UDTのインスタンスのフィールドの構造的配置の認識をデータベースストア内に維持するため、タイプ定義に対する注記から導かれるメタデータをシステムカタログに格納する。詳細に説明すると、このメタデータは、IsFilestream＝trueプロパティの注記の付いているフィールドのいずれをも反映する。
【００５１】
図７を参照すると、データベースストアの中のテーブルの模範的な行６００が示されている。このテーブルは、例えば、図６に示すCLRクラスによって定義されるPerson UDTのインスタンスを格納するために使用される。このテーブルは、テーブルの中の特定行のための独特の識別子（すなわち「row_guid」）を収容する列６０４、UDTのインスタンスに結合する識別子（WinFS Item対応のインスタンスに結合する、例えば、Item_ID）を収容する列６０５、およびUDTのインスタンスのフィールドの実際にシリアル化した値を収容する列６０２を含む。別の列に加えて、このテーブルは、在来のSQL SERVER FILESTREAMデータを保持すると定義される列６０６を含んで差し支えない。
【００５２】
UDTのインスタンスのシリアル化したデータ（すなわち、フィールドの値）で、テーブルのこの行のUDT列６０２を占めるものは、一連のフラグメント６０８に配列される。本実施例においては、これらフラグメントの配置はSqlUdtField() およびSqlUdtProperty() 属性が制御する。上述のように、UDTのフィールドと挙動に、この属性を注記している。
【００５３】
本実施例において、UDTの各フィールドのうち、UDTのシリアル化したデータの残りとは別に、データベースストアの外に格納するものとして指定されるものは、格納されるUDTの配置の中で別個のフラグメントを割当られる。例えば、２つのUDTのフィールドをそのように指定するときは、これらのフィールドはそれぞれフラグメント６１２および６１４として割当られる。更に、本実施例においては、これらのフラグメントにはそれぞれ独特の識別子、例えば、フラグメントID ６１０が与えられる。例えば、フラグメント６１２には「ｘｘ」のフラグメントIDが与えられ、フラグメント６１４には「yy」のフラグメントIDが与えられる。説明の便宜上、UDTのフィールドで本発明により別のUDTのフィールドとは別個にデータベースストアの外に格納すべきものと指定されるものを、これ以降UDTの「ファイルストリームフィールド（Filestream field）」と呼ぶ。このような参照は、決して限定されるものではない。
【００５４】
本発明によればさらに、UDTのインスタンスのこれら各フィールドのデータをデータベースストアのテーブルの中の割当フラグメントに格納する代わりに、当該フィールドのデータをデータベースストアの外側で、データベースストアを実行するコンピュータのファイルシステムの中のファイルに格納する。本実施例において、フラグメントはファイルに対する参照のみを格納し、この参照がファイルに対するリンクを定義する。例えば、フラグメント６１２に割当られているフィールドに関するデータが、代わりにファイル６１６に格納される。このフラグメントは、矢印６２０で示すように、ファイルシステムの中のファイル６１６の位置に対する参照を収容する。同様に、フラグメント６１４に割当られているフィールドに関するデータは、代わりにファイル６１８に格納される。この場合も、フラグメント６１４は、矢印６２２で示すように、ファイル６１8に対する参照を収容する。任意の数のフィールドがこのメソッドで指定されるので、当該フィールド各々に関するデータが、ファイルシステム内のそれぞれのファイルに、直接、この方法で格納される。
【００５５】
本実施例においては、コンピュータファイルシステムの中で各UDTに異なる列レベルディレクトリが指示される。所与のUDTのインスタンスのファイルストリームフィールドのデータを収容するファイルに関する命名規則は、［row_guid］.［fragment_ID］である。例で示すように、Person UDTのインスタンスのシリアル化したデータは、テーブルの「AABB」のrow_guidに指定されている行に格納される。フラグメント６１２は「xx」のフラグメントIDを与えられ、フラグメント６１４は「yy」のフラグメントIDを与えられている。したがって、フラグメント６１２が参照するファイルのファイル名は「AABB . xx」で、フラグメント６１４が参照するファイルのファイル名は「AABB . yy」である。
【００５６】
対応するUDTのインスタンスのファイルストリームフィールドのデータがデータベースストアの外にファイルとして格納されていても、それらのデータがデータベーステーブルの中に格納されているかのように、データベースエンジンの操作を受けやすいということに注意するのが重要である。SQL SERVERデータベースエンジンに実現されるように、T-SQLコマンドINSERT及びUPDATEは、UDTのインスタンスのファイルストリームフィールドのデータを格納するファイルの中に、新規データの挿入または既存データの更新を行うために、そのデータフィールドがデータベーステーブルの中に格納されているかのように、使用することができる。同様に、T-SQL DELETEコマンドは、別個のファイルに格納されている一つまたは複数のファイルストリームフィールドを有するUDTを収容する行の削除のため使用することができる。行を削除すると、参照されるファイルも同様に削除される。別個のファイルに格納されているUDTの中のファイルストリームフィールドもまた、任意の別の列と同様にクエリを行うことができる。
【００５７】
図７にもまた示すように、上述の本発明のメソッドは、SQL SERVERが提供する在来のFILESTREAM列型と共存することができる。図７に示すように、テーブルの列６０６は、タイプ「FILESTREAM」（FS）として定義することができる。列が「FILESTREAM」として定義されると、その列の所与のセルにあるデータは、テーブルのその列に結合する列レベルディレクトリにある別個のファイルに格納される。本発明が、UDTオブジェクトの個別フィールドのデータをデータベースストアの外側の別個のファイルに格納する能力を提供することにより、この能力を改良することは理解されるであろう。
【００５８】
UDTオブジェクトのファイルストリームフィールドのデータで、本発明により別個のファイルに格納されているものは、２つの方法により取得することができる。第１に、上述のように、在来のT-SQLクエリを用いてデータにアクセスすることができる。例えば、（図６に定義するような）Person型のインスタンスが格納されているテーブルが「Person_sql」と命名されており、Person UDTのインスタンスのシリアル化されたデータを収容する列６０２が、「Person_col」と命名されているとする。以下のクエリが、インスタンスのPhotoFSと言う名のフィールドのデータを返す。これは本発明により別個のファイルとして格納されているものである。
SELECT Person_col.PhotoFS FROM Person_SQL WHERE FirstName=”Steve”
【００５９】
データベースエンジンがこのようなクエリを受取ると、Person型のインスタンスのPhotoFSフィールドが格納されているファイルに対するファイルシステムのパス名を入手する。このパス名は、クエリを満足するPerson UDTオブジェクトの対応するフラグメントから得られる。もちろん、Person UDTの複数のオブジェクトが当該クエリを満たすことがある。クエリを満たすオブジェクト各々について、次に、データベースエンジンが、PhotoFSフィールドのデータを収容するファイルのパス名を用いて、ファイルシステムのアプリケーションプログラミングインタフェース（例えば、Win３２ APIの中のCreateFile）に対する適切な呼び出しをおこなう。次に、データベースエンジンがファイルを読取り、データをアプリケーションに返して、ファイルを閉じる。
【００６０】
本発明の別の側面によって、アプリケーションはまた、コンピュータのファイルシステムを通じて当該ファイルに直接アクセスすることができる。具体的に説明すると、アプリケーションは、ファイルシステムに対するアプリケーションプログラミングインタフェースを通じて、呼び出しを生成し、当該ファイルを直接開くことができる。この呼び出しが、データベースストアの中の同一性により対応するオブジェクトのファイルストリームフィールドを識別する。データベースストアの中のオブジェクトのフィールドの同一性に基づいて、そのフィールドのデータを収容するファイルに対するファイルシステムパスを判定する。次にその判定したパスを用いて、ファイルを開く呼び出しを実行する。
【００６１】
本発明のこの側面の実施例を図８に示す。この例では、本発明のこの態様が、上の発明の背景の部分で記述したWinFSストレージプラットホームのコンテキストの中で実施される。当該能力は、WinFSプラットホームにおいて、特に好都合である。しかし、本発明のこの態様は、ユーザ定義型のインスタンスのフィールドのデータを収容するファイルに対する直接アクセスが必要な任意の環境で、実行することができることが理解される。
【００６２】
図８を参照すると、本発明によって、クライアントアプリケーション８００が、ユーザ定義型のインスタンスのファイルストリームフィールドのデータを収容するファイルに対する直接アクセスを要求し、そのフィールドはWinFSストレージプラットホーム８０８を実施するコンピュータシステムのファイルシステム８０４の中のファイルの中に格納されている。上述のように、WinFSストレージプラットホームは、SQL SERVERなどのデータベースエンジンなどのデータベースエンジン８１０上実施される。
【００６３】
本発明のさらに別の態様によると、WinFS APIを用いてデータベースストア（図示せず）の中にUDTオブジェクトとして永続しているWinFS Itemのフィールドに、別にアクセスすることができるクライアントアプリケーションが、その代わりに、ファイルシステム８０４のアプリケーションプログラムミングインタフェース８０２を通じて、ファイルシステム８０４に別個に格納されているアイテム（すなわちＵＤＴ）のファイルストリームフィールドに対し直接アクセスを要求してもよい。図８に示す模範実施例においては、クライアントアプリケーションが、Win３２ APIのCreateFileインタフェースを呼び出して、永続されたItem（UDT）のインスタンス中の対応するフィールドの同一性に基づいた要求データを識別するWin３２ APIにパス名を渡すことにより、ステップ（１）におけるこのステップを起動する。例えば、WinFS命名規則により、データベースストアの中にあるアイテムのフィールド（上述の方法によって、ファイルシステム内で別個に格納されているものを含む）を識別するパス名は、以下の形式を有する。
\\？\UNC\machinename\sharename\Item_IdValue\[typename].field
name.(locator)[typename].fieldname
【００６４】
しかし、このフォーマットは単なる見本であって、実際のデリミタとフォーマットは、本発明の範囲を逸脱することなく、別の実施例においては異なることがあることを理解できる。
【００６５】
上の模範フーマットを参照すると、パス名の最初の部分は、
\\？\unc\machinename\defaultstore\ ...
で始まる。ここで「machinename」は、ＷｉｎＦＳを動かすマシンの名称で、「defaultstore」は、Itemのインスタンスを格納するデータベースのルートに使われる共有名である。WinFSは複数のデータベースストアをサポートするので、「defaultstore」は特定のデータベースに関連する共用、またはデータベースの一部に関連する共用と置換される。パスの…\？\unc\…の部分は、パスを保持する文字列の長さを、正常のパス名が受ける２５６バイト（またはその程度）の限度に限られるのでなく、３２KBまでにするため使用される。このフォーマットで働かせるには、パス名はユニコードでなければならない。こうして、パス名のこの部分は、特定のマシン上で、あるデータベース／共有に指示を与える。
【００６６】
パス名の次の部分（...\Item_IdValue...）は、オブジェクトの型を、「Item」として識別され、次に関連オブジェクト（単数または複数）のItem_ID value(s) と続く。本発明は、WinFSにあるItem Extensions およびRelationshipsにも適用することができることを注意する。Item Extensions およびRelationshipsもまた、WinFSデータベースストアにおいて複数のUDTにマップされるからである。Item Extensionの場合、パス名のこの部分は（...\Extension_IdValue...）で置き換えられる。Relationshipの場合、パス名のこの部分は（...\Relationship_IdValue...）で置き換えられる。
【００６７】
パス名の最後の部分
... \[typename].fieldname.(locator)[typename].fieldname,
は、呼び出しのサブジェクトであるItem、Item Extension、またはRelationship UDTを識別する。これは、「typename-fieldname-locator」を三回繰り返したものを含む。「typename」は角括弧［］で囲み、「locator」があるときはそれを丸括弧で囲む。「typename」はフィールドの型の名称またはオブジェクトルートの型の名称である。「fieldname」はフィールドの名称である。また、フィールドに複数のインスタンスがあるときは、配列またはコレクションのように、「locator」がそのフィールドの中にあるアイテムを確認する。UDTがオブジェクトのネストされたレベルを含むときは、追加の「typename-fieldname-locator」を三回繰り返したものが存在して、フィールドの中のフィールドを指定し、結局IsFilestream＝trueプロパティを有するフィールドに行き着く。
【００６８】
図６および７の例を続ける。Person UDTのインスタンスのPhotoFSフィールドに対するパス名は、次のように指定する。
\\？\UNC\localhost\defaultstore\ItemID\Person.PhotoFS.
ここでItemIDは、Person型の特定インスタンスに割当られる世界的に独特の識別子（guid）である。
【００６９】
データベースストアの外に別個のファイルとして永続しているアイテムのファイルストリームフィールドのためのWinFSパス名は、コンピュータファイルシステムにより正しく分解することができないので、本発明によると、等価のファイルシステムパス名に翻訳される。本実施例において、このプロセスは、「FS Agent」と言う名のソフトウエア成分により起動される。もちろん、別の実施例においては、別のソフトウエア成分を採用してこの機能を実行することがある。ステップ（２）に示すように、ファイルシステムAPI８０２が、WinFSパス名を含むクライアントアプリケーションから、CreateFileコマンドを受取ると、それをWinFSパス名の「machinename／defaultstore」部分からのもののように認識する。このパス名を付けて受け取るファイル要求はすべてFS Agentに送られる。
【００７０】
ステップ（３）において、このFS Agentは、WinFS API ８０８に対して「OPEN」呼び出しを出して、それからItemフィールドのWinFSパス名を渡す。ステップ（４）において、WinFSプラットホームが、WinFSパス名からアイテムとフィールドを確認し、次にこの情報を、「GetPathName()」要求の中で、データベースエンジンに渡す。「GetPathName()」はデータベースエンジンファンクションであって、上述の方法でデータベース記録とは別個に格納されているUDTオブジェクトのファイルストリームフィールドのためのWin３２ファイルシステムパス名を返すものである。WinFSプラットホームはまた、アイテムのフィールドに対するアクセスに際し、いずれのセキュリテイ制約をも実行する。
【００７１】
ステップ（５）において、データベースエンジンは、要求のサブジェクトであるUDTオブジェクトが格納されているテーブル索引を実行することにより、「GetPathName()」要求に対し応答する。データベースエンジンはテーブルの正しい行の位置、次に、行の中のUDTオブジェクトのシリアル化したフラグメントの位置を決定する。問題のファイルストリームフィールドに関し、データベースエンジンは、対応するフラグメントから、そのフィールドに関するデータを格納するファイルに対する実際のファイルシステムパスを抽出する。データベースエンジンは、その実際のパスをWinFS API ８０８に返す。ステップ（６）において、WinFSはそのファイルシステムパスをFS Agentに返し、ステップ（７）において、FS Agentはファイルを開くためにFile System API ８０２を呼び出して、要求の中の実際のファイルシステムパスを渡す。ステップ（８）において、File System API ８０２がファイルに対するハンドルを取得し、File System API ８０２に対し普通にCreateFile呼び出しが行われるときのように、それをクライアントに返す（ステップ９）。
【００７２】
この時点で、クライアントアプリケーション８０８は、通常のFile System APIを呼び出し（例えば、Win３２ API File I／O 呼び出し）を通じて、ファイルに対する読み取りおよび書き込みを行うことができる。クライアントアプリケーション８０８は、そのファイルを終了するときは、File System APIに対しCLOSE呼び出しを出す。この呼び出しは、再度FS Agent ８０６により途中で抑えられる。FS Agent ８０６は、WinFS API ８０８に対し「CLOSE」呼び出しを発行して、そのファイルを閉じることを要求する。WinFSプラットホーム８０８は、このオペレーションを永続性アイテムに対する更新として模擬し、更新に関するあらゆる関連変更履歴、及びその他の機能を実行する。次に、データベースエンジンは、永続性UDTオフジェクト上で自分自体の更新処理をおこなう。この処理を完了すると、制御がFS Agent ８０６に返されて、File System API ８０２を呼び出し、クライアントアプリケーション８０８の代わりに通常のファイルクローズ操作を実行する。
【００７３】
上述した方法によって、クライアントアプリケーションに、永続したＵＤＴのファイルストリーム（Filestream）フィールドへの「帯域外（out of band）」のアクセスを提供する。このファイルストリームフィールドは、データベース管理システムを実装したコンピュータのファイルシステム内で、離れたファイルとしてフィールドを格納したものである。
【００７４】
上記より明らかなように、本発明の各種のシステム、方法および態様の全部または一部を、ハードウエア、ソフトウエア、または両方の組合せで実施することができる。ソフトウエアで実施する場合、本発明の方法および装置、または、その方法および装置のある態様かある部分をプログラムコード（すなわち命令）の形で実施することができる。このプログラムコードを磁気ストレージ媒体や電気ストレージ媒体、光学ストレージ媒体といったコンピュータ読取り可能媒体に格納することができる。このコンピュータ読取り可能媒体には、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、磁気テープ、フラッシュメモリ、ハードディスクドライブ、またはマシンで読み取り可能な他のストレージ媒体が制限なしに含まれる。そして、このプログラムコードをコンピュータまたはサーバ等のマシンにロードして実行すると、そのマシンが本発明を実施する装置となる。このプログラムコードを実行するコンピュータは、プロセッサ、そのプロセッサによる読み取りが可能なストレージ媒体（揮発性および不揮発性メモリ、および／またはストレージ要素を含む）、少なくとも１つの入力装置、および少なくとも１つの出力装置を典型的に含む。高水準の手続き言語やオブジェクト指向プログラム言語でこのプログラムコードを実行してもよいが、代わりに、アセンブリ言語やマシン語で実行することもできる。いずれの場合でも、コンパイラ型言語またはインタプリタ型言語であればよい。
【００７５】
本発明は、プログラムコードの形で実施してもよい。電気配線またはケーブルといった何らかの伝送媒体を介するか、ローカルエリアネットワーク、広域ネットワーク、インターネットまたはイントラネットを含む光ファイバによるネットワークを介して、または伝送の他の形を介してこのプログラムコードを伝送する。ここで、コンピュータなどのマシンがこのプログラムコードを受け取ってロードすると、そのマシンが本発明を実行する装置となる。
【００７６】
汎用プロセッサにこのプログラムコードを実装すると、その汎用プロセッサと組み合わさり、特定の論理回路と同様に動作する固有の装置を提供することができる。
【００７７】
さらに、コンピュータネットワークの一部として配置するか、分散コンピューティング環境に配置することができるどのようなコンピュータやクライアント装置もしくはサーバ装置に関しても本発明を実装することができる。この点で、本発明は、いかなるコンピュータシステムや環境にも関する。このコンピュータシステムや環境は、あらゆるメモリまたはストレージユニットを有する。また、あらゆるアプリケーションと、様々なストレージユニットやストレージボリュームで生じるプロセスを有し、本発明に係るデータベースストア中に持続するオブジェクトの処理に関して用いることができる。本発明は、ネットワーク環境か分散コンピューティング環境にサーバコンピュータおよびクライアントコンピュータを配置した環境で、リモートストレージ域またはローカルストレージ域を有する環境に適用されてもよい。本発明は、スタンドアローンのコンピュータ装置に適用されてもよく、その装置は、プログラム言語の機能性を有し、リモートサービスまたはローカルサービスと関連して情報を生成し、受け取り、伝送するための解釈能力および実行能力を有する。
【００７８】
分散コンピューティングは、コンピュータ装置とシステムとの間の交換によって、コンピュータ資源およびサービスの共有を容易にする。このコンピュータ資源およびサービスは、これに限定されないが、ファイルに関する情報、キャッシュ記憶、およびディスクストアの交換を含む。分散コンピューティングは、ネットワークの接続性を活用して、クライアントがその総合力を利用して業務全体に利益を与えることを可能とする。この点で、様々な装置が、オブジェクトを永続させる本発明の方法に関して行う処理と何らかの関係があるアプリケーションやオブジェクト、資源を有することができる。
【００７９】
図９は、ネットワークまたは分散コンピューティング環境の典型的な概略図を示す。この分散コンピューティング環境は、計算オブジェクト１０ａ、１０ｂ等、および計算オブジェクトまたはコンピューティングデバイス１１０ａ、１１０ｂ、１１０ｃ等を含む。これらのオブジェクトは、プログラム、メソッド、データストア、プログラム可能ロジック等である。オブジェクトには、ＰＤＡ、テレビ、ＭＰ３プレーヤ、個人用コンピュータ等の同じ装置の一部または別の装置の一部を含んでもよい。各オブジェクトは、通信ネットワーク１４を介して、別の計算オブジェクトと通信することができる。このネットワークはそれ自体に、図９のシステムに対するサービスを提供する別の計算オブジェクトおよびコンピューティングデバイスを含んでおり、それ自体が複数の相互接続ネットワークをあらわしている。本発明の一側面により、各オブジェクト１０ａ、１０ｂ等、または１１０ａ、１１０ｂ、１１０ｃ等は、本発明のオブジェクト永続化方法を実施するのに使用されるプロセスの使用を要求するための、ＡＰＬ、またはその他のオブジェクト、ソフトウエア、ファームウエア、および／またはハードウエアを使用するアプリケーションを含む。
【００８０】
１１０ｃ等のオブジェクトは、別のコンピューティングデバイス１０ａ、１０ｂ等、または１１０ａ、１１０ｂ、１１０ｃ等をホストにしてもよいことが理解できる。したがって、記述された物理的環境はコンピュータとして接続さる装置を示すが、これらの説明図は単に典型的なものであって、物理的環境はこの代わりに、ＰＤＡ、テレビ、ＭＰ３プレーヤなど各種のデジタル装置、インタフェース，ＣＯＭオブジェクト等の様々なフトウエアオブジェクトを含むものとして図示または記述してもよい。
【００８１】
分散コンピューティング環境をサポートするシステム、成分、およびネットワーク構成は、様々である。例えば、コンピューティングシステムは有線または無線システムを用いて、ローカルネットワークまたは広域分散ネットワークにより互いに接続してもよい。現在のところ、多くのネットワークがインターネットに接続されており、これが広域分散コンピューティングのためのインフラストラクチャを提供しており、多数の異なるネットワークを包含している。いずれのインフラストラクチャも本発明に付髄する典型的な通信として使用してもよい。
【００８２】
インターネットは典型的に、コンピュータネットワークの技術においては周知の、一連のプロトコル一式ＴＣＰ／ＩＰを用いたネットワークとゲートウエイの集合を指す。ＴＣＰ／ＩＰは「トランスミッション・コントロール・プロトコル(Transmission Control Protocol)／インターネット・プロトコル(Internet Protocol)」の頭文字である。インターネットは、地理的に分散しているリモートコンピュータのネットワークであってネットワークプロトコルを実行するコンピュータにより相互接続され、ユーザが（単数または複数の）ネットワークを通じて相互に交信し情報を共有することのできるものであると説明できる。このよう広範な情報が共有できるため、インターネットなどのリモートネットワークは、これまで典型的にオープンシステムへと発展してきたので、開発者はこのネットワークに対して専門的オペレーション、またはサービスを実行するためのソフトウエアアプリケーションを、実質的に制約を受けずに設計することができる。
【００８３】
こうして、ネットワークインフラストラクチャは、クライアント／サーバ、ピアツーピア、またはハイブリッドアーキテクチャ等、ネットワークトポロジーのホストを可能にした。「クライアント」とは、自分に関連のない別のクラスまたはグループのサービスを利用するクラスまたはグループのメンバーである。したがって、コンピューティングにおいては、クライアントとは、別のプログラムが提供するサービスを要求するプロセス、つまり大まかに言うと一式の命令またはタスクである。クライアントプロセスは、他のプログラムまたはサービス自体について作動の詳細を何ら「知る」必要なしに、要求されるサービスを利用する。クライアント／サーバアーキテクチャ、特にネットワークになっているシステムにおいて、クライアントは通常、他のコンピュータ、例えばサーバが提供する共有ネットワークリソースにアクセスするコンピュータである。環境によっていずれのコンピュータもクライアント、サーバ、または両者と見なせるが、図９の例において、コンピュータ１１０ａ、１１０ｂ等はクライアントとして、コンピュータ１０ａ、１０ｂなどはサーバとして捉えることができる。これらコンピューティングデバイスのいずれも、本発明のオブジェクト永続化技術に関わる方法でデータを処理する。
【００８４】
サーバは、典型的にはインターネットなどリモートまたはローカルネットワークを介してアクセスすることのできるリモートコンピュータシステムである。通信媒体を介して互いに通信し合いながら、クライアントプロセスは第１コンピュータシステムで、サーバプロセスは第２コンピュータシステムでそれぞれアクティブになり、これにより分散機能を提供しながら、複数のクライアントがサーバの情報収集能力を駆使することを可能にする。本発明の永続化機構に従って利用されるソフトウエアオブジェクトはいずれも、複数のコンピューティングデバイス全体に亘って分散される。
【００８５】
クライアント（単数または複数）およびサーバ（単数または複数）は、プロトコル層が提供する機能性を利用して互いに通信する。例えば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）は、ワールドワイドウェブ（ＷＷＷ）または「ウエブ（Web）」との関連で使用される共通プロトコルである。典型的には、インターネット・プロトコル（ＩＰ）アドレスなどのコンピュータアドレス、またはユニバーサルリソースロケータ（ＵＲＬ）など他のリファレンスを使用して、サーバまたはクライアントコンピュータを互いに識別することができる。ネットワークアドレスは、ＵＲＬアドレスと呼ぶことができる。通信は利用することのできる任意の通信媒体を通じて提供することができる。
【００８６】
このように、図９は、ネットワーク／バス経由でクライアントコンピュータと通信するサーバを伴った、本発明を採用できる典型的ネットワークまたは分散環境を示す。ネットワーク／バス１４は、ＬＡＮ、ＷＡＮ、イントラネット、インターネット、または他のネットワーク媒体で、本発明による携帯用コンピュータ、ハンドヘルドコンピュータ、シンクライアント、ネットワーク電気器具、またはＶＣＲ、ＴＶ、電子レンジ、電灯、電熱器等の多数のクライアントまたはリモートコンピューティングデバイス１１０ａ、１１０ｂ、１００ｄ、１１０ｅ等を備えたものでよい。したがって、本発明は、永続性オブジェクトを維持するのが望ましいものと接続した任意のコンピューティングデバイスに適用することを意図している。
【００８７】
通信ネットワーク／バス１４がインターネット等であるネットワーク環境においては、サーバ１０ａ、１０ｂ等は、ＨＴＴＰなど多数の公知のプロトコルのうち、任意のものを経由してそれと通信するクライアント１１０ａ、１１０ｂ、１００ｄ、１１０ｅ等のサーバとなることができる。サーバ１０ａ、１０ｂ等はまた、分散コンピューティング環境の特徴でもあるように、クライアント１１０ａ、１１０ｂ、１００ｄ、１１０ｅなどの役割を果たすこともできる。
【００８８】
通信は、必要に応じて、有線または無線で行なわれる。クライアント装置１１０ａ、１１０ｂ、１００ｄ、１１０ｅ等は、通信ネットワーク／バス１４を経由して通信しても、しなくてもよく、それらに関連する独立した通信をしてもよい。例えば、ＴＶまたはＶＣＲの場合は、それらの制御にネットワークの側面があってもなくてもよい。各クライアントコンピュータ１１０ａ、１１０ｂ、１００ｄ、１１０ｅ等と、サーバコンピュータ１０ａ、１０ｂ等には、各種アプリケーションプログラムモジュールまたはオブジェクト１３５および各種の型のストレージ要素またはオブジェクトに対する接続、またはアクセスを装備し、それらの全域に亘ってファイルまたはデータストリームを格納するか、またはそれらに対してファイルまたはデータストリームの一部（単数または複数）をダウンロード、送信または移動する。いずれのコンピュータ１０ａ、１０ｂ、１１０ａ、１１０ｂ等が、本発明によって処理されるデータを格納するためのデータベース、メモリ、またはその他のストレージ要素の維持および更新を担当してもよい。このように、本発明は、コンピュータネットワーク／バス１４にアクセスして交信することのできるクライアントコンピュータ１１０ａ、１１０ｂ等および、クライアントコンピュータ１１０ａ、１１０ｂ等およびデータベース２０と交信するサーバコンピュータ１０ａ、１０ｂ等を有するコンピュータネットワーク環境において利用することができる。
【００８９】
図１０および以下の説明は、それらと接続して本発明を実施できる適切なコンピューティングデバイスの簡潔な典型的コンテキストを提供することを目的とする。例えば、図９に示すクライアントおよびサーバコンピュータ、またはデバイスはいずれもこの形を取り得る。しかし、あらゆる種類のハンドヘルド、携帯用およびその他のコンピューティングオブジェクト、または計算オブジェクトは本発明に接続して、すなわちコンピューティング環境の中でデータの生成、処理、送受信ができるあらゆる場所から使用するものと意図されていることは明らかである。汎用コンピュータについて以下に記述するが、これは一例に過ぎず、本発明はネットワーク／バスのインターオペラビリティと交信機能を有するシンクライアントを用いて実施してもよい。このように、本発明は、極めて少数または最小限のクライアントリソースが関係するネットワークされたホストサービスの環境、例えばクライアントデバイスが電気器具におかれるオブジェクト等、単にネットワーク／バスに対するインタフェースの機能を果たすだけのネットワーク環境において実施してもよい。基本的に、データが格納され、またはそこからデータを回収し、または別のコンピュータに移動する場所がどこであれ、本発明のオブジェクト永続化方法の操作のために望ましい、または適した環境である。
【００９０】
必須ではないが、本発明は、サービスの開発者によりデバイスまたはオブジェクトのための使用に供された、および／または本発明に従って作動するアプリケーション、またはサーバソフトウエアに含まれるオペレーティングシステムを介して実施することができる。ソフトウエアは、プログラムモジュール等、コンピュータ実行可能命令の一般的状況として説明してもよいが、それはクライアントワークステーション、サーバ、またはその他のデバイス等の１または複数のコンピュータにより実行される。典型的に、プログラムモジュールには、特定のタスクを実行するかまたは特定の抽象データ型を実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等が含まれる。典型的に、プログラムモジュールの機能性は、各種実施例で記述するように必要に応じて、結合または分散される。さらに、本発明は、別のコンピュータシステム構成およびプロトコルを用いて実行してもよい。本発明との使用に適する他の公知のコンピューティングシステム、環境および／または構成には、個人用コンピュータ（ＰＣ）、現金自動預払い機、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサに基づくシステム、プログラム可能家庭用電化製品、ネットワークＰＣ、電気器具、電灯、環境制御要素、ミニコンピュータ、メインフレームコンピュータ等が含まれるが、これらに限定されるものではない。
【００９１】
図１０はこのように、本発明を実施するのに適するコンピューティングシステム環境１００の例を示しており、上述で明確ではあるが、コンピューティングシステム環境１００は適切なコンピューティング環境の一例に過ぎず、本発明の使用範囲または機能性に関し、何らの制限を加える意図はない。コンピューティング環境１００は、典型的オペレーティング環境１００に示すコンポーネントのどの１つまたはその組合せに関係しても、依存性または必要性を有するものと解釈すべきではない。
【００９２】
図１０を参照すると、本発明を実施するための典型的システムは、コンピュータ１１０の形の汎用コンピューティングデバイスを含むことがわかる。コンピュータ１１０のコンポーネントには、処理ユニット１２０、システムメモリ１３０、およびシステムメモリを含む各種システムコンポーネントを処理ユニット１２０に結合するシステムバス１２１が含まれるが、これらには限定されない。システムバス１２１は、各種のバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含む、いくつかあるバス構造の型のうちいずれでもよい。一例として、このようなアーキテクチャには業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ電子規格協会（ＶＥＳＡ）ローカルバス、および周辺部品相互接続（ＰＣＩ）バス（メザニンバスとも言う）が含まれるが、これらに限定はされない。
【００９３】
コンピュータ１１０は典型的に、各種のコンピュータ読取り可能媒体を含む。コンピュータ読取り可能媒体は、コンピュータ１００がアクセスできる利用可能な媒体であればいずれでも良く、揮発性および不揮発性媒体、リムーバブルおよび非リムーバブル媒体の両者を含む。例として、コンピュータ読取り可能媒体には、コンピュータストレージ媒体と通信媒体が含まれるが、これらに限定されない。コンピュータストレージ媒体には、コンピュータ読取り可能命令、データ構造、プログラムモジュールまたはその他のデータ等、情報を格納するための任意の方法または技術により実施される揮発性および不揮発性媒体、リムーバブルおよび非リムーバブル媒体の両者が含まれる。コンピュータストレージ媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤＲＯＭ、デジタル汎用ディスク（ＤＶＤ）またはその他の光ディスク記憶、磁気カセット、磁気テープ、磁気ディスクまたはその他の磁気記憶装置、またはその他の媒体で、所望の情報の格納に使用可能で、コンピュータ１１０がアクセスすることのできるものが含まれるが、これらには限られない。通信媒体は典型的に、コンピュータ読取り可能命令、データ構造、プログラムモジュールまたはその他のデータを、搬送波またはその他のトランスポート機構等の変調されたデータ信号の中に実現するもので、任意の情報配信媒体が含まれる。用語「変調されたデータ信号」は、その特徴の１つ以上の情報が信号の中に符号化する方法で設定または変更されている信号を意味する。一例として、通信媒体には、有線ネットワークまたは直接有線接続などの有線媒体、および音響，ＲＦ、赤外線およびその他の無線媒体などの無線媒体が含まれるが、これらに限定はされない。上述のいかなる組合せも、コンピュータ読取り可能媒体の範囲に含まれる。
【００９４】
システムメモリ１３０は、コンピュータストレージ媒体を、読取専用メモリ（ＲＯＭ）１３１、ランダムアクセスメモリ（ＲＡＭ）１３２など揮発性および／または不揮発性メモリの形で含む。起動中等にコンピュータ１１０の中の要素の間の情報転送を助ける基本ルーチンを含む基本入出力システム１３３（ＢＩＯＳ）は、典型的にＲＯＭ１３１の中に格納される。直ちにアクセス可能なおよび／または処理ユニット１２０上で現在演算中のデータおよび／またはプログラムモジュールは、典型的にＲＡＭ１３２に収容される。例として、図１０はオペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７を示すが、これらに限定はされない。
【００９５】
コンピュータ１１０はまた、他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピュータストレージ媒体をも含む。ほんの一例として、図８に、非リムーバブル、不揮発性磁気媒体に読取または書込を行うハードディスク１４１、リムーバブル、不揮発性磁気ディスク１５２に読取または書込をおこなう磁気ディスクドライブ１５１、およびＣＤ−ＲＷ、ＤＶＤ−ＲＷまたはその他の光媒体など、リムーバブル、不揮発性光ディスクに読取または書込をおこなう光ディスクドライブ１５５を示す。他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピュータストレージ媒体で典型オペレーティング環境に使用することができるものには、磁気テープカセット、フラッシュメモリカード、デジタル揮発性ディスク、デジタルビデオテープ、半導体ＲＡＭ、半導体ＲＯＭ等が含まれるが、これらに限定されるものではない。ハードディスクドライブ１４１は、典型的にインタフェース１４０など非リムーバブルメモリインタフェースを通じてシステムバス１２１に接続され、磁気ディスクドライブ１５１と光ディスクドライブ１５１は、典型的にインタフェース１５０などリムーバブルメモリインタフェースを介してシステムバス１２１に接続される。
【００９６】
上に説明し図１０に示すデバイスおよびそれらに関連するコンピュータストレージ媒体は、コンピュータ読取り可能命令、データ構造、プログラムモジュール、およびその他のデータをコンピュータ１１０のために格納する。図１０では、例えば、ハードディスク１４１が、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６およびプログラムデータ１４７を格納していることを図示している。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６およびプログラムデータ１３７と同一であることも異なることあり得ることに注意すべきである。オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６およびプログラムデータ１４７には、異なる番号を与えて、少なくとも、それらは異なるものであることを示している。ユーザは、キーボード１６２などの入力装置及およびマウス、トラックボールまたはタッチパッドなどのポインティングデバイス１６１を通じてコンピュータ１１０にコマンドおよび情報を入力する。その他の入力装置（示さず）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナ等が含まれる。これらおよびその他の入力装置は、処理ユニット１２０に対し、システムバス１２１に結合されたユーザ入力インタフェース１６０を介して接続されることが多いが、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）など、別のインタフェースおよびバス構造により接続してもよい。グラフィックスインタフェース１８２もまたシステムバス１２１に接続される。１または複数のグラフィック処理装置（ＧＰＵ）１８４がグラフィックスインタフェース１８２と連絡する。モニタ１９１または別の型の表示装置も、ビデオインタフェース１９０などのインタフェース経由でシステムバス１２１と通信し、その次にビデオメモリ１８６と通信する。モニタ１９１に加えて、コンピュータはまた、スピーカ１９７およびプリンタ１９６など別の周辺出力装置をも含む。これらは出力周辺インタフェース１９５を通じて接続される。
【００９７】
コンピュータ１１０は、ネットワークまたは分散環境の中で、リモートコンピュータ１８０等、１または複数のリモートコンピュータに対する論理接続を用いて作動する。リモートコンピュータ１８０は、メモリストレージデバイス１８１のみを図１０に示すように、個人用コンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたはその他の共通ネットワークモードであって、典型的にコンピュータ１１０との関係で上述した要素の多数または全部を含む。図１０に描写する論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１と広域ネットワーク（ＷＡＮ）１７３を含むが、他のネットワーク／バスを含んでもよい。このようなネットワーク環境は、家庭、事務所、企業規模コンピュータネットワーク、イントラネットおよびインターネットにおいてはよくあることである。
【００９８】
ＬＡＮネットワーク環境で使用するとき、コンピュータ１１０はネットワークインタフェースまたはアダプタ１７０を用いてＬＡＮ１７１に接続される。ＷＡＮネットワーク環境で使用するとき、コンピュータ１１０は典型的に、インターネットなどのＷＡＮ７３を通じる通信を設定するためモデム１７２またはその他の手段を含む。内蔵または外付けのモデム１７２は、ユーザ入力インタフェース１６０またはその他の適切な機構を介して、システムバス１２１に接続される。ネットワーク環境においては、コンピュータ１１０またはその一部に関連して記述されたプログラムモジュールは、リモートメモリストレージデバイスに格納される。例として、図１０にリモートアプリケーションプログラム１８５を、メモリ装置１８１に常駐するものとして示すが、これに限定するものではない。示すネットワーク接続は見本であってコンピュータの間に通信リンクを確立する他の手段を使用してもよいことは理解できる。
【００９９】
既に例証したとおり、本発明は、データベースを格納するコンピュータのファイルシステム内の独立したファイルとしてデータベースストアに持続する、あるいは、データベースストアの外側のユーザ定義型のインスタンスのフィールドを格納／取得するシステムおよび方法を導く。本発明は、特に大きいテータ型をユーザ定義型のフィールドとしてデータベース管理システム内に格納するのに有利である。上述の実施例に対して、その広範な革新的概念から逸脱することなく、変更を加えることが可能なことは理解できる。例えば、本発明の実施例は、マイクロソフトのＳＱＬサーバデータベース管理システムで実施されているように上述されているが、本発明はユーザ定義型の作成をサポートするいかなるデータベース管理システムでも実現できることは理解できる。加えて、本発明のある側面は、上述のＷｉｎＦＳプラットホームのコンテキストで実現されると記述されているが、本発明のこれらの側面は決してその環境での実施に限定されないことも理解できる。むしろ、本発明のシステムと方法は、ユーザ定義型のインスタンスのフィールドの格納と取得に好適な任意のシステムにおいて実現される。したがって、本発明は開示された特定の実施例に限定されるものでなく、添付請求項で規定する本発明の精神と範囲内に属するすべての変更を含む意図であることが理解できる。
【図面の簡単な説明】
【０１００】
【図１】ユーザ定義型に関するマネージドコードクラス定義を示す模範コードのセグメントを示す図である。
【図２】マネージドコードでインスタンスが作成されているタイプのインスタンスのシリアライゼイションとシリアライゼイション解除を示すブロック図である。
【図３】ユーザ定義型のオブジェクトが永続しているデータベーステーブルを示すブロック図である。
【図４】本発明の機能を利用する模範ストレージプラットホームを示すブロック図である。
【図５】図４に示すストレージプラットホームコンテキストの中に、持続するユーザ定義型のオブジェクトに対しクエリを実行するためのプロセスを示すブロック図である。
【図６】「Person」と言う名のユーザ定義型のためのマネージドコードクラス定義を示す模範的コードのセグメントである。
【図７】本発明のシステムと方法の一実施例を示すブロック図である。
【図８】本発明の別の態様の実施例による、ユーザ定義型のインスタンスのフィールドのデータを含むファイルに対する「帯域外」アクセスのシステムおよび方法を示すブロック図である。
【図９】本発明が実施される各種計算装置を有する模範ネットワーク環境を示すブロック図である。
【図１０】本発明が実施される模範計算装置を示すブロック図である。
【技術分野】
【０００１】
（関連特許）
本発明は、その全体を参照として組込む２００３年１０月２３日提出、米国特許出願１０／６９２，２２７号に対する優先権を主張する。
【０００２】
（著作権表示と承認）
本特許文書の開示の一部には、著作権保護を受ける資料が含まれる。著作権所有者は、特許商標事務所のファイルまたは記録に現れるときは、本特許文書または特許開示を何人が複製することにも異議を申し立てないが、別途の場合はいかなるものであれ著作権権利を留保する。以下の記載は本文書に適用される、「Copyright 2003, Microsoft Corp.」。
【０００３】
本発明は、コンピュータシステムにおけるデータストアに関し、さらに詳細には、型の定義されているデータベースストアの外側でのユーザ定義型フィールドの格納および取得のためのシステムと方法に関する。
【背景技術】
【０００４】
Microsoft SQL SERVERは総合データベース管理プラットホームであって、広範な管理および開発のツール、強力な抽出、変形および読み込み（ETL）のツール、ビジネス情報および解析サービス、並びにその他の能力を備えている。SQL SERVERに対し最近２つの改良を加えた。第１に、Microsoft Windows（登録商標） .NET Framework Common Language Runtime（CLR）がSQL SERVERデータベースに統合され、第２に、ユーザ定義型（UDT）と呼ばれる新たなオブジェクトをCLR環境の中のマネージドコードを用いて作成し、データベースストアの中に永続させることができるようになった。
【０００５】
CLRは、Microsoft .NET Frameworkの中心であって、全ての.NETコード用の実行環境を提供する。したがって、それがCLR内で実行されるコードは、「マネージドコード（managed code）」と呼ぶ。CLRは、ジャストインタイム（JIT）コンパイル、メモリ割当と管理、型の安全性の実行、例外処理、スレッド管理およびセキュリテイを含むプログラム実行に必要な各種の機能とサービスを提供する。ＣＬＲは、現在、.NETルーチンの最初の呼び出しに際してSQL SERVERにより読み込まれる。
【０００６】
前バージョンのSQL SERVERでは、データベースプログラマーがサーバ側のコードを記述する際に、Transact-SQLを用いることに制限されていた。Transact-SQLは、国際標準化機構（ISO）および米国規格協会（ANSI）の定義する構造化照会言語（SQL）を拡張した言語である。Transact-SQLを使用して、データベース開発者はデータベースおよびテーブルの作成、変更および削除を行うことができると同時に、データベースの中に格納されるデータの挿入、取得、変更および削除を行うことができる。Transact-SQLは、直接構造的データアクセスおよび操作のため特に設計されている。Transact-SQLはデータのアクセスと管理に卓越しているけれども、Visual Basic .NETおよびＣ＃のような本格的プログラム言語ではない。Transact-SQLは、配列、コレクション、ループ、ビットシフトまたはクラスをサポートしない。
【０００７】
CLRをSQL SERVERのデータベースに統合することにより、データベース開発者は、Transact-SQL単独では果たすことが不可能か困難であったタスクを実行することができる。Visual Basic .NETとＣ＃の両者は、配列、構造化例外処理、およびコレクションに関する完全なサポートを提供する最新のプログラム言語である。開発者はCLR統合を利用して、Visual Basic .NETおよびＣ＃などの言語を使用して、より複雑なロジックを有し、より計算タスクに適するコードを記述できる。
【０００８】
CLR統合に加えて、SQL SERVERはまたユーザ定義型（UDT）−開発者がデータベースのスカラ型システムを拡張することができる新しいメカニズム−に関するサポートを追加する。UDTは、アプリケーションアーキテクチャの観点から２つの重要な利点を提供する。これらは、内部状態と外部挙動との間に強力なカプセル化（クライアントとサーバの双方において）を提供し、他の関連サーバ機能との高レベルな統合を提供する。一旦UDTを定義すると、SQL SERVERにおいてシステム型を使用することのできるあらゆるコンテキストの中で使用することができる。これらには、列定義、変数、パラメータ、関数の結果、カーソル、トリガ、およびレプリケーションが含まれる。
【０００９】
データベースサーバ上でUDTを定義する処理は、次のようにして果たされる、
ａ）UDT作成のための規則に従って、マネージドコードでクラスを作成する、
ｂ）CREATE ASSEMBLYステートメントを用いて、UDTを含むアセンブリをサーバ上のデータベースに読み取る、および、
ｃ）CREATE TYPEステートメントを用いて、データベースの中にマネージドコードUDTを公開する型を作成する。
この時点で、UDTをテーブル定義の中に使用することができる。
【００１０】
マネージ コードでUDT定義を作成する場合、その型は以下の要件を満たしている必要がある。すなわち、
ａ）Serializableでマークし、
ｂ）SqlUserDefinedTypeAttributeで修飾し、
ｃ）INullableインタフェースを実装して、型でのNULLの使用を許可し、
ｄ）型には、引数を取らないパブリックコンストラクタが含まれている必要があり、および
ｅ）以下のメソッドを実装して、型は文字列への変換および文字列からの変換をサポートする必要がある。
１．Public String ToString()、および
２．Public Shared<type>Parse(SqlString s)。
【００１１】
ここに出願する「データベースストアにおけるオブジェクト永続性のためのシステムと方法」と題する同時係属、同一人出願の特許出願 号（代理人明細書：MSFT−２８５２／３０６８１９．１）は、その全文をここに参照として組込むが、UDTに関するCLRクラス定義のフィールドと挙動が、データベースストアの中のUDTのインスタンスに関するレイアウト構造を記述するストレージ属性を用いて注記を付けられる、ＵＤＴの別の特徴を記述する。具体的に説明すると、UDTを定義するCLRクラスの各フィールドに、サイズ、精度、スケールなどタイプのストレージの相を制御する記憶域属性を用いて注記が付けられる。一実施例において、これは各フィールドにSqlUdtField()と名付けるカスタムストレージを用いて注記を付けることにより果たされる。この属性は追加のストレージの命令を用いてフィールドに注記を付ける。オブジェクトをディスクにシリアル化したときに、この命令を実行する。加えて、CLRクラス内で定義される管理動作（例えば、UDTオブジェクト上で呼び出すことができて、フィールドの値を返すなどをするメソッド）毎に、その管理動作に関して、等価構造のアクセスパスを表示する属性を用いて注記を付ける。一実施例において、この目的に使用されるカスタム属性はSqlUdtProperty()と名付けられ、データベースサーバ（例えば、SQL SERVER）は、このカスタム属性を用いて注記されるプロパティの実施が、属性定義の一部として規定されるフィールドに委記されるものと推定する。これにより、サーバはプロパティに対するアクセスを、インスタンスを作成して挙動をその上に呼び出すことなく、構造的に最適化する。
【００１２】
図１は、UDTを定義するCLRクラスの模範コードリストである。示すように、CLRクラスは上述のようにSqlUdtField()とSqlUdtProperty()のカスタム属性を用いて注記を付けられている。具体的に説明すると、SqlUdtField()カスタム属性は５、８、３７、４９の各行に追加されていて、模範的なＵＤＴのクラス定義について、各フィールドに注記している。SqlUdtProperty()カスタム属性は、１１行と２４行に追加されていて、そのクラスのそれぞれの管理動作を注記している。
【００１３】
ＵＤＴを定義するＣＬＲクラスを、ダイナミックリンクライブラリ（dll）にコンパイルする。その後、以下のT-SQLスクリプトコマンドを用いて、コンパイルするクラスを含むアセンブリを作成する。
create assembly test
from 'c:\test.dll'
go 。
【００１４】
以下のT-SQLスクリプトコマンドを用いて、サーバ上にUDTを作成する。
create type BaseItem
external name [test]:[BaseItem]
go 。
【００１５】
サーバ上にUDTを作成したら、以下のように、テーブルの属性をUDTタイプと定義することにより、テーブル（例えば、「マイテーブル（My table）」を作成することができる。
create table MyTable
(
Item BaseItem,
ItemId as item::ID
)
go 。
【００１６】
次のようにして、新しいアイテムをテーブルに追加することができる。
declare @i BaseItem
set @i = convert(BaseItem,")
insert into MyTable values (@i)
go 。
【００１７】
これで、UDT表現をクエリ内で、SELECT Item.ID,Item.Name FROM MY Tableなどのように使用することができる。
【００１８】
SQL SERVERへのCLRの統合およびクラス定義からマネージドコードでUDTを定義する能力により、アプリケーションは、マネージドコードクラスにより定義されるタイプのオブジェクトのインスタンスを作成することができるので、これらのオブジェクトをリレーショナルデータベースストアの中にUDTとして永続させることができる。その上、UDTを定義するクラスもまた、特定の挙動を実行するメソッドをそのタイプのオブジェクト上にインクルードすることができる。したがって、アプリケーションは、UDTとして定義されるタイプのオブジェクトのインスタンスを作成し、管理動作をその上に呼び出すことができる。
【００１９】
UDTとして定義されているクラスのオブジェクトのインスタンスをCLRの中に作成するとき、クラスの変数の値を物理的ストレージ（例えば、ハードディスク）に転送するオブジェクトシリアライゼイションの処理を通じて、オブジェクトをデータベースストアの中に永続させることができる。図２は、メモリの中のオブジェクトの、ディスク上に持続する形に対するシリアライゼイションを示す図である。オブジェクトは、図３に示すフォーマットの従来のリレーショナルデータベーステーブルのデータベースストアの中に永続させることができる。図示するように、テーブルは規定のＵＤＴの列を含む。規定のUDTの永続性のオブジェクトのシリアル化した値は、UDT列のセルを占有する。
【００２０】
もう一度図２を参照すると、アプリケーションが、データベースストアに永続しているUDTオブジェクトの管理動作（例えば、UDTオブジェクトのフィールドの値を返す挙動）を参照する述語または表現を含むクエリを作成すると、永続性オブジェクトはシリアライゼイションを解除（「ハイドレーティング（hydrating）」と言うこともある）しなければならないので、CLRはその格納値を受け取るためオブジェクト全体のためメモリを割当てなければならない。CLRはこのとき、クエリのサブジェクトである値（単数または複数）を返すUDTクラスの実際のメソッド（すなわち挙動）を呼び出さなければならない。前述の同時係属出願 号（代理人明細書：MSFT−２８５２／３０６８１９．１）に記述するように、ＵＤＴのＣＬＲクラス定義におけるSqlUdtField()およびSqlUdtProperty()の注記を、データベースサーバが使用して、オブジェクトのハイドレーションをする必要なしで、一定のUDTフィールドの値に対し直接構造的アクセスをすることもできる。
【００２１】
SQL SERVERへのCLR統合とUDTの提供の利点を利用する一つの新規技術は、「組織化、検索、およびデータ共用のためのストレージプラットホーム (Storage Platform For Organizing, Serching, And Sharing Data)」との名称で、２００３年８月２１日に申請し、その全文をここに参照として組込む、同一出願による、同時係属特許出願１０／６４６，６４６号に記述するストレージプラットホームである。図４は、同時係属出願に記述するストレージプラットホーム３００のアーキテクチャを示すブロック図である。ストレージプラットホームは、「WinFS」と呼ばれることもある。図４に示すように、ストレージプラットホーム３００はデータベースエンジン３１４上で実行されるデータストア３０２を含む。一実施例において、このデータベースエンジンは、Microsoft SQL SERVERリレーショナルデータベースエンジンなど、リレーショナルデータベースエンジンを含む。
【００２２】
データストア３０２は、以下に完全に記述するように、アイテムおよびアイテム間の関係の形のデータの組織、検索、共用、同期、およびセキュリテイをサポートするデータモデル３０４を実行する。アイテムの具体的なタイプをスキーマ３４０などのスキーマで記述し、ストレージプラットホーム３００は、以下に詳述するように、これらのスキーマを展開するためと同時にこれらのスキーマを拡張するためのツール３４６を提供する。
【００２３】
データストア３０２の中で実行される変更履歴３０６は、データストアに対する変更を追跡する能力を提供する。データストア３０２はまた、セキュリテイ能力３０８および昇進／降格能力３１０をも提供する。データストア３０２はまた、アプリケーションプログラミングインタフェース一式３１２をも備えていて、データストレージプラットホームの能力を利用する別のストレージプラットホーム成分およびアプリケーションプログラム（例えば、アプリケーションプログラム３５０ａ、３５０ｂ、３５０ｃ）にデータストア３０２の能力を公開する。
【００２４】
ストレージプラットホームはさらに、アプリケーションプログラミングインタフェース（API）３２２を含む。これは、アプリケーションプログラム３５０ａ，３５０ｂ，３５０ｃなどのアプリケーションプログラムが、ストレージプラットホームの能力にアクセスし、データベースに格納されるデータにアクセスすることを可能にする。ストレージプラットホームAPI３２２は、OLE DB API ３２４および、Microsoft Windows（登録商標） Win ３２ API ３２６など別のＡＰＩと組み合わせて、アプリケーションプログラムにより使用できる。
【００２５】
ストレージプラットホーム３００はまた、アプリケーションプログラムに対し、ユーザ間またはシステム間でデータの共用を便利にする同期サービス３３０を含む各種のサービス３２８を提供する。例えば、同期サービス３３０は、データストア３０２と同一のフォーマットを有する別のデータストア３４０との相互接続を可能にすると同時に、別のフォーマットを有するデータストア３４２に対するアクセスをも可能にする。ストレージプラットホーム３００はまた、データストア３０２とWindows（登録商標） NTFSファイルシステム３１８など既存ファイルシステムとの相互接続を可能にするファイルシステム能力をも提供する。
【００２６】
少なくともいくつかの実施例では、ストレージプラットホーム３２０は、アプリケーションプログラムに、データを他のシステム上で働かせて、他のシステムと相互作用させることができる追加能力も与える。この能力は、情報エージェントサービス３３４および通告サービス３３２と同時に別のユーティリティ３３６の形など、追加サービス３２８の形で実現される。
【００２７】
少なくともいくつかの実施例では、ストレージプラットホームは、コンピュータシステムのハードウエア／ソフトウエアインタフェースシステムに実現されるか、またはその不可欠部分を形成する。例えば、無制限に、本発明のストレージプラットホームは、オペレーティングシステム、バーチャルマシンマネージャ（VMM）、Common Language Runtime（CLR）またはその機能的等価物、もしくはJava（登録商標） Virtual Machine (JVM）またはその機能的等価物に実現されるか、またはその統合部分を形成する。
【００２８】
その共通ストレージ基盤と、体系化されたデータを通じて、ストレージプラットホームは、消費者、知的労働者および企業のためいっそう効率の良いアプリケーション開発を可能にする。これは、そのデータモデルに固有の能力を利用することができるようにするだけでなく、既存のファイルシステムおよびデータベースアクセスメソッドを取り込んで拡張する豊富で広範な表面積を求めるプログラムを提供する。
【００２９】
以下の記述において、および各種の図面において、本発明のストレージプラットホーム３００を「WinFS」と呼ぶ。しかし、このプラットホームを参照するためこの名称を使用することは、記述のためのみであって、いかなる意味においても限定を意図するものではない。
【００３０】
WinFSプラットホームのデータモデルは、データストレージの単位をアイテム、アイテム拡張、および関連に関して定義する。「アイテム（Item）」とは、ストレージ情報の基本単位である。データモデルは、アイテムとアイテム拡張を宣言するためと、アイテム間の関連を確定するためのメカニズムを提供する。アイテムは、コピー、削除、移動、オープンなどの操作を用いて格納し取得することのできる単位である。アイテムは、交渉、人々、サービス、場所、（各種の）文書など、実社会で容易に理解可能なデータの単位を表すことを目的としている。アイテム拡張は、既存アイテムの定義を拡張する方法で、関連はアイテムの間で定義されるリンクである。
【００３１】
WinFSにおいては、情報の格納のため各種のアイテム型が定義される。例えば、アイテム型は契約、人々、サービス、場所、文書などに関して定義される。各アイテム型は、与えられるアイテムのプロパティと特徴を定義するスキーマによって記述される。例えば、「場所」アイテムは、電子メールアドレス、首都圏、近隣および郵便宛先などのプロパティを持つとして定義される。与えられるアイテム型についてスキーマが定義されると、展開ツールを使用してスキーマをそのアイテム型に対応するCLRクラス定義に翻訳し、次に、WinFSアイテム型のインスタンスをデータベースストアの中に永続させるため、CLRクラス定義から（上述の方法で）データベース記録の中にUDTを作成する。WinFS API 322を用いて、アプリケーション（例えば、アプリケーション３５０ａ、３５０ｂ、３５０ｃ）は、ストレージプラットホームのデータストアからの情報を格納し取得するために、データストアによりサポートされるアイテム型のインスタンスを作成することができる。データストアに格納されるアイテム型の各インスタンスは、それに結合する独特の識別子（例えば、Item_ID）を有する。一実施例においては、各アイテム識別子が、世界的に独特の識別子、すなわち「guid」である。こうして、WinFSプラットホームは、CLR統合とデータベースストアのUDT能力を利用して、プラットホームに情報のアイテムを格納させる。
【００３２】
SQL SERVERの中のどのＵＤＴのインスタンスともと同じく、WinFSアイテムのインスタンスは究極的に、図３に示す方法でデータベースストアのテーブルの中に格納される。このときアプリケーションはクエリをWinFSプラットホームに提出して、検索基準を満たすデータストアから、アイテムを検索し、取得する。図５は、データストアにクエリを実行して、「Person」と言う名のアイテム型のインスタンスを取得する方法を示す。ステップ（１）において、アプリケーションはWinFS API ３２２の「FindALL」メソッドを用いて、特定の検索基準を満たすアイテム全部−この場合は、タイプの「Birthday」フィールドにある値が特定日付（例えば、１９９９年１２月３１日）より大きいPerson型のインスタンス全部−に関するクエリを起動する。ステップ（２）において、WinFS API ３２２が「FindALL」オペレーションをＳＱＬクエリに変換して基礎を成すデータベースエンジン、例えば、SQL SERVERにそれを提出する。ステップ（３）において、データベースエンジンが、対応するPerson UDTのインスタンスに対してクエリを実行し、一致するPerson UDTのインスタンスそれぞれに関して格納されている値を返す。この例においては、ステップ（４）において、データベースストアから返されるビットをADO.NETがCLRオブジェクトに変換し（すなわち、上述のオブジェクトハイドレーションの処理）、それをWinFS API ３２２に返す。ADO.NETは、Microsoft .NET Frameworkの要素で、SQL SERVERなどのデータソースに対するマネージドコードアクセスをCLR経由で設ける。次に、WinFS APIは、Person UDTオブジェクトをラップして、それらをアプリケーションにPerson型として返す。
【発明の開示】
【発明が解決しようとする課題】
【００３３】
データベースストア内にユーザ定義型（UDT）を作成する能力は、強力な能力であるが、この能力をいっそう充実して、デジタル画像、ビデオ、オーディオなどを含む膨大なデータ型などある種のデータ型を、ＵＤＴの定義フィールドとして格納するためのサポートを提供することが望ましい。さらに、UDTの膨大なデータフィールドに対して「帯域外」アクセスを設け、基礎となるデータベースストアのクエリ言語を用いることなく、従来のファイルシステム呼び出し（open、closeなど）を通じて、アクセスすることができるようにすることが望ましい。これらの能力が、上述のWinFSストレージプラットホームのコンテキストの中に備えられることは特に望ましい。これまで、これらの能力は備えられていなかった。
【００３４】
Microsoft SQL SERVER製品は、リレーショナルデータベーステーブルの列全体をFILESTREAMという名の型に指定して、その列のセルの中にあるデータをリレーショナルデータベーステーブルとは別のファイルに格納する能力を備えているが、ユーザ定義型ファイルの個別フィールドを指定して、その方法で格納する能力はない。
【００３５】
IBMのDB２データベース製品には「データリンク（datalinks）」機能があって、これは、ファイルに対する参照を格納することにより、テーブルの中の列をファイルシステムの中のファイルにリンクする能力をサポートする。しかし、これは上述のように、列のセルと参照ファイルとの間のＮ対１の参照モデルを与えるだけなので、セルとファイルとの間の上述のような１対１のモデルに関する必要は依然として存在する。この「データリンク」機能にはまた、次の別途の理由による欠点がある。すなわち、（ｉ）プログラム作成モデルでは、別のファイルのストレージとクエリを、ユーザ定義型内部の正規リレーショナルデータと同一にすることができず、また、（ｉｉ）DB２の「データリンク」機能では、ファイルシステムを通じて参照されるファイルの中に格納される列データの更新をおこなうことができない。
【００３６】
オラクル社の「IFS」製品は、中間層ソフトウエアを用いて、SBM、HTTP、FTP、SMTPなど多数のプロトコルに渡るデータに対するアクセスを提供する。データは、結局データベースに格納される。オラクルIFSは、膨大なデータ型を含む様々な種類のデータの「統合した」表示を提供するけれども、この解決策は、リレーショナルデータベースエンジンと反対に、中間層ソフトウエアの中で実行されるので、上述の必要性を満たすものではない。
【００３７】
最後に、ISO／IEC ９０７５−９：２００３（別名SQL２００３MED）は「データリンク（datalinks）」を新規データ型として提案する。提案された規格によると、データリンクはDATALINKデータ型の値である。データリンクは、SQL環境の一部ではない何かのファイルを参照する。このファイルは、何かの外部ファイルマネージャにより管理されると想定する。データリンクは概念的に、外部ファイルの参照を形成する文字列によって表され、参照は、ISO／IEC ９０７５のこのセクションに定義するオペレータを呼び出すことによりアクセスすることができる。データリンク文字セットと言われる参照の文字セットは、実装時定義である。この提案された規格は、上述の望ましい機能を目指していない。
【００３８】
このように、例えば、デジタル画像、ビデオ、オーディオなどを含む膨大なデータ型など、ユーザ定義型（UDT）の定義フィールドとして格納するためのサポートを提供すると同時に、これら膨大なデータ型に対する「帯域外」アクセスを、在来のファイルシステム呼び出し（open、closeなど）を通じて提供するシステムと方法に関する必要は依然として存在する。本発明は、これらの必要性を満たすものである。
【課題を解決するための手段】
【００３９】
本発明は、例えば、イメージ、ビデオ、オーディオなどを含む膨大なデータ型などある種のデータ型を、データベースストアの中にユーザ定義型のフィールドとして格納するためのシステムおよび方法を指向する。本発明によると、データベースストアに持続することのできるオブジェクトのタイプを、ユーザが定義する。このタイプ定義にはフィールドと挙動が含まれ、各フィールドはそれぞれのデータ型を有する。１または複数のタイプ定義のフィールドは、データベースストア外側のファイルとして、タイプ定義の別のフィールドとは別個に格納するべき型の収容データとして、指定される。ユーザ定義型のインスタンスであるオブジェクトを格納する要求を受け取るとき、オブジェクトのそのように指定されているフィールドのいずれかにあるデータは、データベースストア外側のファイルに格納する。特に、データベースストアを実装するコンピュータのファイルシステムの中に格納するのが好適である。オブジェクトの別のフィールドのそれぞれの中のデータは、通常の方法でデータベースストアの中に格納される。データベースストアは、永続性オブジェクトとデータベースストア外側のファイルとして格納されるフィールドのデータとの間のリンク、または参照を維持する。
【００４０】
本発明のもう１つの態様によれば、アプリケーションには、コンピュータのファイルシステムを通じて、所与のフィールドのデータがデータベースストアの外に格納されているファイルに対して、アクセスが与えられる。さらに詳細に説明すると、アプリケーションが、コンピュータのファイルシステムに対するアプリケーションプログラミングインタフェースを通じて、ファイルを開く呼び出しを生成する。このとき呼び出しは、データベースストアの中のその同一性によりオブジェクトのフィールドを識別する。データベースストアの中のオブジェクトのフィールドの同一性に基づいて、そのフィールドのデータを含むファイルに対するシステムパスを判定する。次に、ファイルを開く呼び出しを、判定したパスを用いて実行する。
【００４１】
こうして、本発明はデータベースストアに持続することのできるオブジェクトのユーザ定義型のフィールドを、データベースストアの外に、すなわち、データベースストアが実施されるコンピュータのファイルシステムの中にあるファイルとして指定して、格納することを可能にする。さらに、ユーザ定義型のそのフィールドのデータを含むファイルに対するアクセスを、コンピュータのファイルシステムを通じて設ける。
【００４２】
本発明のその他の機能および利点は、以下の本発明の詳細な説明および添付図面から明らかになるであろう。
【００４３】
前述の要約は、本発明の詳細な説明と同様に、添付図面との関連で読むとき、更に良く理解されるであろう。本発明の例証の目的で、本発明の各種側面の模範実施例を図面に示すが、本発明は開示する特定の方法と手段に限定されるものではない。
【発明を実施するための最良の形態】
【００４４】
本発明の対象を特異性とともに記述して、法令の要件に対処する。しかし、記述自体は本特許の範囲を限定する意図のものではない。正確には、発明者らは、この請求内容が別の方法でもまた実現され、本文書に記述するものに類似の異なるステップまたは要素を、現在または将来の別の技術と結合して含むことを考慮に入れている。さらに、ここで使用される用語「ステップ」は、採用される方法の異なる側面を意味するけれども、この用語は、個別ステップの順序を明確に記述しているのでない限りおよびその場合を除いて、ここに開示する各種ステップのうちまたはその間の何らかの特別の順序を意味するものと、解釈されないものとする。
【００４５】
上述のように、本発明は、例えば、デジタル画像、ビデオ、オーディオなどを含む膨大なデータ型などある種のデータ型を、データベースストアの中にユーザ定義型のフィールドとして格納するための方法を指向する。本発明によると、データベースストアに持続することのできるオブジェクトのタイプを、ユーザが定義する。タイプ定義にはフィールドと挙動が含まれ、各フィールドはそれぞれのデータ型を有する。１または複数のタイプ定義のフィールドを、データベースストア外側のファイルとして、タイプ定義の別のフィールドとは別個に格納するべき型の収容データとして、指定する。ユーザ定義型のインスタンスであるオブジェクトを格納する要求を受け取り、オブジェクトのそのように指定されているフィールドのいずれかにあるデータをデータベースストアの外側のファイルに格納する。特に、データベースストアを実装するコンピュータのファイルシステムの中に格納するのが好適である。オブジェクトの別のフィールドのそれぞれの中のデータは、通常の方法でデータベースストアの中に格納される。データベースストアは、永続性オブジェクトとデータベースストア外側のファイルとして格納されるフィールドのデータとの間のリンク、または参照を維持する。
【００４６】
図６は、ユーザ定義型の定義の模範的部分コードリストで、本発明の一実施例によって、タイプのインスタンスがデータベースストアの中に持続するとき、その外に格納されるフィールドとするタイプのフィールドの指定を示す。具体的に説明すると、「Person」と言う名のユーザ定義型のためのCLRクラスを示す。構文は、上記発明の背景で記述したように、SQL SERVERデータベースエンジンが使用するものである。しかし、本発明は、決してSQLサーバデータベースエンジンとの使用に限定されるものでなく、正確には、ユーザ定義型をサポートする任意のデータベース管理システムのコンテキストの中で採用することができると理解できる。
【００４７】
図６に示すCLRクラスは、Person型のため２つのフィールドを定義する。一つは「FirstName」と言う名で、データ型SqlStringを有すると定義されており、一つは「PhotoFS」と言う名で、データ型SqlBytesを有すると定義されている。SQL SERVERの中のユーザ定義型のための完全なCLRクラス定義には、上記発明の背景で説明した要件によって（および図１の模範コードリストに示すように）、補足的なフィールドとメソッドがあることを理解できる。例えば、PhotoFSデータフィールドは、この型のインスタンスを表すPersonの写真を含むイメージデータを保持する。このようなデータは、本発明を有利に適用することのできる膨大なデータ型の種類の例である。
【００４８】
本発明によって、この例においては、Person型のPhotoFSフィールドは、型のインスタンスがストアの中に持続するとき、データベースストアの外に格納されるフィールドとして指定される。具体的に説明すると、本実施例において、これは、UDTのCLRクラス定義のフィールドに、指定を与えるカスタム属性の注記を付けることにより果たされる。特に、上記発明の背景で記述したSqlUdtField()カスタム属性の新しいプロパティを作成する。新しいプロパティを「IsFilestream」と呼ぶ。そのプロパティの「true」の値（例えば、IsFilestream＝true）は、Personタイプのこのフィールドが、本発明によって、データベースストアの外にファイルとして格納されるべきであることを示す。しかし、フィールドがそのように指定される特定のメソッドは、この模範的構造に限定されるものではないことが理解される。正確には、基礎を成すデータベースシステムが認識することのできるものであれば、ユーザ定義型の定義に対する任意の型の注記を採用することができる。ユーザ定義型のフィールドに対する注記は、SqlUDTField()カスタム属性のIsFilestreamプロパティを含めて、定義型に結び付くメタデータ一式を定義する。
【００４９】
本実施例においては、IsFilestreamプロパティは、タイプSqlBytesのフィールドに対してのみ適用される。しかし別の実施例のおいては、このプロパティは、望みに応じて、別のデータ型のフィールドに適用される。
【００５０】
さらに本発明によると、ＵＤＴに関するＣＬＲクラスがコンパイルされ、次に、上述のように、例えば、T-SQLスクリプトコマンドCREATE TABLEを用いて、データベースサーバに登録されるとき、データベースエンジンは、UDTのインスタンスのフィールドの構造的配置の認識をデータベースストア内に維持するため、タイプ定義に対する注記から導かれるメタデータをシステムカタログに格納する。詳細に説明すると、このメタデータは、IsFilestream＝trueプロパティの注記の付いているフィールドのいずれをも反映する。
【００５１】
図７を参照すると、データベースストアの中のテーブルの模範的な行６００が示されている。このテーブルは、例えば、図６に示すCLRクラスによって定義されるPerson UDTのインスタンスを格納するために使用される。このテーブルは、テーブルの中の特定行のための独特の識別子（すなわち「row_guid」）を収容する列６０４、UDTのインスタンスに結合する識別子（WinFS Item対応のインスタンスに結合する、例えば、Item_ID）を収容する列６０５、およびUDTのインスタンスのフィールドの実際にシリアル化した値を収容する列６０２を含む。別の列に加えて、このテーブルは、在来のSQL SERVER FILESTREAMデータを保持すると定義される列６０６を含んで差し支えない。
【００５２】
UDTのインスタンスのシリアル化したデータ（すなわち、フィールドの値）で、テーブルのこの行のUDT列６０２を占めるものは、一連のフラグメント６０８に配列される。本実施例においては、これらフラグメントの配置はSqlUdtField() およびSqlUdtProperty() 属性が制御する。上述のように、UDTのフィールドと挙動に、この属性を注記している。
【００５３】
本実施例において、UDTの各フィールドのうち、UDTのシリアル化したデータの残りとは別に、データベースストアの外に格納するものとして指定されるものは、格納されるUDTの配置の中で別個のフラグメントを割当られる。例えば、２つのUDTのフィールドをそのように指定するときは、これらのフィールドはそれぞれフラグメント６１２および６１４として割当られる。更に、本実施例においては、これらのフラグメントにはそれぞれ独特の識別子、例えば、フラグメントID ６１０が与えられる。例えば、フラグメント６１２には「ｘｘ」のフラグメントIDが与えられ、フラグメント６１４には「yy」のフラグメントIDが与えられる。説明の便宜上、UDTのフィールドで本発明により別のUDTのフィールドとは別個にデータベースストアの外に格納すべきものと指定されるものを、これ以降UDTの「ファイルストリームフィールド（Filestream field）」と呼ぶ。このような参照は、決して限定されるものではない。
【００５４】
本発明によればさらに、UDTのインスタンスのこれら各フィールドのデータをデータベースストアのテーブルの中の割当フラグメントに格納する代わりに、当該フィールドのデータをデータベースストアの外側で、データベースストアを実行するコンピュータのファイルシステムの中のファイルに格納する。本実施例において、フラグメントはファイルに対する参照のみを格納し、この参照がファイルに対するリンクを定義する。例えば、フラグメント６１２に割当られているフィールドに関するデータが、代わりにファイル６１６に格納される。このフラグメントは、矢印６２０で示すように、ファイルシステムの中のファイル６１６の位置に対する参照を収容する。同様に、フラグメント６１４に割当られているフィールドに関するデータは、代わりにファイル６１８に格納される。この場合も、フラグメント６１４は、矢印６２２で示すように、ファイル６１8に対する参照を収容する。任意の数のフィールドがこのメソッドで指定されるので、当該フィールド各々に関するデータが、ファイルシステム内のそれぞれのファイルに、直接、この方法で格納される。
【００５５】
本実施例においては、コンピュータファイルシステムの中で各UDTに異なる列レベルディレクトリが指示される。所与のUDTのインスタンスのファイルストリームフィールドのデータを収容するファイルに関する命名規則は、［row_guid］.［fragment_ID］である。例で示すように、Person UDTのインスタンスのシリアル化したデータは、テーブルの「AABB」のrow_guidに指定されている行に格納される。フラグメント６１２は「xx」のフラグメントIDを与えられ、フラグメント６１４は「yy」のフラグメントIDを与えられている。したがって、フラグメント６１２が参照するファイルのファイル名は「AABB . xx」で、フラグメント６１４が参照するファイルのファイル名は「AABB . yy」である。
【００５６】
対応するUDTのインスタンスのファイルストリームフィールドのデータがデータベースストアの外にファイルとして格納されていても、それらのデータがデータベーステーブルの中に格納されているかのように、データベースエンジンの操作を受けやすいということに注意するのが重要である。SQL SERVERデータベースエンジンに実現されるように、T-SQLコマンドINSERT及びUPDATEは、UDTのインスタンスのファイルストリームフィールドのデータを格納するファイルの中に、新規データの挿入または既存データの更新を行うために、そのデータフィールドがデータベーステーブルの中に格納されているかのように、使用することができる。同様に、T-SQL DELETEコマンドは、別個のファイルに格納されている一つまたは複数のファイルストリームフィールドを有するUDTを収容する行の削除のため使用することができる。行を削除すると、参照されるファイルも同様に削除される。別個のファイルに格納されているUDTの中のファイルストリームフィールドもまた、任意の別の列と同様にクエリを行うことができる。
【００５７】
図７にもまた示すように、上述の本発明のメソッドは、SQL SERVERが提供する在来のFILESTREAM列型と共存することができる。図７に示すように、テーブルの列６０６は、タイプ「FILESTREAM」（FS）として定義することができる。列が「FILESTREAM」として定義されると、その列の所与のセルにあるデータは、テーブルのその列に結合する列レベルディレクトリにある別個のファイルに格納される。本発明が、UDTオブジェクトの個別フィールドのデータをデータベースストアの外側の別個のファイルに格納する能力を提供することにより、この能力を改良することは理解されるであろう。
【００５８】
UDTオブジェクトのファイルストリームフィールドのデータで、本発明により別個のファイルに格納されているものは、２つの方法により取得することができる。第１に、上述のように、在来のT-SQLクエリを用いてデータにアクセスすることができる。例えば、（図６に定義するような）Person型のインスタンスが格納されているテーブルが「Person_sql」と命名されており、Person UDTのインスタンスのシリアル化されたデータを収容する列６０２が、「Person_col」と命名されているとする。以下のクエリが、インスタンスのPhotoFSと言う名のフィールドのデータを返す。これは本発明により別個のファイルとして格納されているものである。
SELECT Person_col.PhotoFS FROM Person_SQL WHERE FirstName=”Steve”
【００５９】
データベースエンジンがこのようなクエリを受取ると、Person型のインスタンスのPhotoFSフィールドが格納されているファイルに対するファイルシステムのパス名を入手する。このパス名は、クエリを満足するPerson UDTオブジェクトの対応するフラグメントから得られる。もちろん、Person UDTの複数のオブジェクトが当該クエリを満たすことがある。クエリを満たすオブジェクト各々について、次に、データベースエンジンが、PhotoFSフィールドのデータを収容するファイルのパス名を用いて、ファイルシステムのアプリケーションプログラミングインタフェース（例えば、Win３２ APIの中のCreateFile）に対する適切な呼び出しをおこなう。次に、データベースエンジンがファイルを読取り、データをアプリケーションに返して、ファイルを閉じる。
【００６０】
本発明の別の側面によって、アプリケーションはまた、コンピュータのファイルシステムを通じて当該ファイルに直接アクセスすることができる。具体的に説明すると、アプリケーションは、ファイルシステムに対するアプリケーションプログラミングインタフェースを通じて、呼び出しを生成し、当該ファイルを直接開くことができる。この呼び出しが、データベースストアの中の同一性により対応するオブジェクトのファイルストリームフィールドを識別する。データベースストアの中のオブジェクトのフィールドの同一性に基づいて、そのフィールドのデータを収容するファイルに対するファイルシステムパスを判定する。次にその判定したパスを用いて、ファイルを開く呼び出しを実行する。
【００６１】
本発明のこの側面の実施例を図８に示す。この例では、本発明のこの態様が、上の発明の背景の部分で記述したWinFSストレージプラットホームのコンテキストの中で実施される。当該能力は、WinFSプラットホームにおいて、特に好都合である。しかし、本発明のこの態様は、ユーザ定義型のインスタンスのフィールドのデータを収容するファイルに対する直接アクセスが必要な任意の環境で、実行することができることが理解される。
【００６２】
図８を参照すると、本発明によって、クライアントアプリケーション８００が、ユーザ定義型のインスタンスのファイルストリームフィールドのデータを収容するファイルに対する直接アクセスを要求し、そのフィールドはWinFSストレージプラットホーム８０８を実施するコンピュータシステムのファイルシステム８０４の中のファイルの中に格納されている。上述のように、WinFSストレージプラットホームは、SQL SERVERなどのデータベースエンジンなどのデータベースエンジン８１０上実施される。
【００６３】
本発明のさらに別の態様によると、WinFS APIを用いてデータベースストア（図示せず）の中にUDTオブジェクトとして永続しているWinFS Itemのフィールドに、別にアクセスすることができるクライアントアプリケーションが、その代わりに、ファイルシステム８０４のアプリケーションプログラムミングインタフェース８０２を通じて、ファイルシステム８０４に別個に格納されているアイテム（すなわちＵＤＴ）のファイルストリームフィールドに対し直接アクセスを要求してもよい。図８に示す模範実施例においては、クライアントアプリケーションが、Win３２ APIのCreateFileインタフェースを呼び出して、永続されたItem（UDT）のインスタンス中の対応するフィールドの同一性に基づいた要求データを識別するWin３２ APIにパス名を渡すことにより、ステップ（１）におけるこのステップを起動する。例えば、WinFS命名規則により、データベースストアの中にあるアイテムのフィールド（上述の方法によって、ファイルシステム内で別個に格納されているものを含む）を識別するパス名は、以下の形式を有する。
\\？\UNC\machinename\sharename\Item_IdValue\[typename].field
name.(locator)[typename].fieldname
【００６４】
しかし、このフォーマットは単なる見本であって、実際のデリミタとフォーマットは、本発明の範囲を逸脱することなく、別の実施例においては異なることがあることを理解できる。
【００６５】
上の模範フーマットを参照すると、パス名の最初の部分は、
\\？\unc\machinename\defaultstore\ ...
で始まる。ここで「machinename」は、ＷｉｎＦＳを動かすマシンの名称で、「defaultstore」は、Itemのインスタンスを格納するデータベースのルートに使われる共有名である。WinFSは複数のデータベースストアをサポートするので、「defaultstore」は特定のデータベースに関連する共用、またはデータベースの一部に関連する共用と置換される。パスの…\？\unc\…の部分は、パスを保持する文字列の長さを、正常のパス名が受ける２５６バイト（またはその程度）の限度に限られるのでなく、３２KBまでにするため使用される。このフォーマットで働かせるには、パス名はユニコードでなければならない。こうして、パス名のこの部分は、特定のマシン上で、あるデータベース／共有に指示を与える。
【００６６】
パス名の次の部分（...\Item_IdValue...）は、オブジェクトの型を、「Item」として識別され、次に関連オブジェクト（単数または複数）のItem_ID value(s) と続く。本発明は、WinFSにあるItem Extensions およびRelationshipsにも適用することができることを注意する。Item Extensions およびRelationshipsもまた、WinFSデータベースストアにおいて複数のUDTにマップされるからである。Item Extensionの場合、パス名のこの部分は（...\Extension_IdValue...）で置き換えられる。Relationshipの場合、パス名のこの部分は（...\Relationship_IdValue...）で置き換えられる。
【００６７】
パス名の最後の部分
... \[typename].fieldname.(locator)[typename].fieldname,
は、呼び出しのサブジェクトであるItem、Item Extension、またはRelationship UDTを識別する。これは、「typename-fieldname-locator」を三回繰り返したものを含む。「typename」は角括弧［］で囲み、「locator」があるときはそれを丸括弧で囲む。「typename」はフィールドの型の名称またはオブジェクトルートの型の名称である。「fieldname」はフィールドの名称である。また、フィールドに複数のインスタンスがあるときは、配列またはコレクションのように、「locator」がそのフィールドの中にあるアイテムを確認する。UDTがオブジェクトのネストされたレベルを含むときは、追加の「typename-fieldname-locator」を三回繰り返したものが存在して、フィールドの中のフィールドを指定し、結局IsFilestream＝trueプロパティを有するフィールドに行き着く。
【００６８】
図６および７の例を続ける。Person UDTのインスタンスのPhotoFSフィールドに対するパス名は、次のように指定する。
\\？\UNC\localhost\defaultstore\ItemID\Person.PhotoFS.
ここでItemIDは、Person型の特定インスタンスに割当られる世界的に独特の識別子（guid）である。
【００６９】
データベースストアの外に別個のファイルとして永続しているアイテムのファイルストリームフィールドのためのWinFSパス名は、コンピュータファイルシステムにより正しく分解することができないので、本発明によると、等価のファイルシステムパス名に翻訳される。本実施例において、このプロセスは、「FS Agent」と言う名のソフトウエア成分により起動される。もちろん、別の実施例においては、別のソフトウエア成分を採用してこの機能を実行することがある。ステップ（２）に示すように、ファイルシステムAPI８０２が、WinFSパス名を含むクライアントアプリケーションから、CreateFileコマンドを受取ると、それをWinFSパス名の「machinename／defaultstore」部分からのもののように認識する。このパス名を付けて受け取るファイル要求はすべてFS Agentに送られる。
【００７０】
ステップ（３）において、このFS Agentは、WinFS API ８０８に対して「OPEN」呼び出しを出して、それからItemフィールドのWinFSパス名を渡す。ステップ（４）において、WinFSプラットホームが、WinFSパス名からアイテムとフィールドを確認し、次にこの情報を、「GetPathName()」要求の中で、データベースエンジンに渡す。「GetPathName()」はデータベースエンジンファンクションであって、上述の方法でデータベース記録とは別個に格納されているUDTオブジェクトのファイルストリームフィールドのためのWin３２ファイルシステムパス名を返すものである。WinFSプラットホームはまた、アイテムのフィールドに対するアクセスに際し、いずれのセキュリテイ制約をも実行する。
【００７１】
ステップ（５）において、データベースエンジンは、要求のサブジェクトであるUDTオブジェクトが格納されているテーブル索引を実行することにより、「GetPathName()」要求に対し応答する。データベースエンジンはテーブルの正しい行の位置、次に、行の中のUDTオブジェクトのシリアル化したフラグメントの位置を決定する。問題のファイルストリームフィールドに関し、データベースエンジンは、対応するフラグメントから、そのフィールドに関するデータを格納するファイルに対する実際のファイルシステムパスを抽出する。データベースエンジンは、その実際のパスをWinFS API ８０８に返す。ステップ（６）において、WinFSはそのファイルシステムパスをFS Agentに返し、ステップ（７）において、FS Agentはファイルを開くためにFile System API ８０２を呼び出して、要求の中の実際のファイルシステムパスを渡す。ステップ（８）において、File System API ８０２がファイルに対するハンドルを取得し、File System API ８０２に対し普通にCreateFile呼び出しが行われるときのように、それをクライアントに返す（ステップ９）。
【００７２】
この時点で、クライアントアプリケーション８０８は、通常のFile System APIを呼び出し（例えば、Win３２ API File I／O 呼び出し）を通じて、ファイルに対する読み取りおよび書き込みを行うことができる。クライアントアプリケーション８０８は、そのファイルを終了するときは、File System APIに対しCLOSE呼び出しを出す。この呼び出しは、再度FS Agent ８０６により途中で抑えられる。FS Agent ８０６は、WinFS API ８０８に対し「CLOSE」呼び出しを発行して、そのファイルを閉じることを要求する。WinFSプラットホーム８０８は、このオペレーションを永続性アイテムに対する更新として模擬し、更新に関するあらゆる関連変更履歴、及びその他の機能を実行する。次に、データベースエンジンは、永続性UDTオフジェクト上で自分自体の更新処理をおこなう。この処理を完了すると、制御がFS Agent ８０６に返されて、File System API ８０２を呼び出し、クライアントアプリケーション８０８の代わりに通常のファイルクローズ操作を実行する。
【００７３】
上述した方法によって、クライアントアプリケーションに、永続したＵＤＴのファイルストリーム（Filestream）フィールドへの「帯域外（out of band）」のアクセスを提供する。このファイルストリームフィールドは、データベース管理システムを実装したコンピュータのファイルシステム内で、離れたファイルとしてフィールドを格納したものである。
【００７４】
上記より明らかなように、本発明の各種のシステム、方法および態様の全部または一部を、ハードウエア、ソフトウエア、または両方の組合せで実施することができる。ソフトウエアで実施する場合、本発明の方法および装置、または、その方法および装置のある態様かある部分をプログラムコード（すなわち命令）の形で実施することができる。このプログラムコードを磁気ストレージ媒体や電気ストレージ媒体、光学ストレージ媒体といったコンピュータ読取り可能媒体に格納することができる。このコンピュータ読取り可能媒体には、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、磁気テープ、フラッシュメモリ、ハードディスクドライブ、またはマシンで読み取り可能な他のストレージ媒体が制限なしに含まれる。そして、このプログラムコードをコンピュータまたはサーバ等のマシンにロードして実行すると、そのマシンが本発明を実施する装置となる。このプログラムコードを実行するコンピュータは、プロセッサ、そのプロセッサによる読み取りが可能なストレージ媒体（揮発性および不揮発性メモリ、および／またはストレージ要素を含む）、少なくとも１つの入力装置、および少なくとも１つの出力装置を典型的に含む。高水準の手続き言語やオブジェクト指向プログラム言語でこのプログラムコードを実行してもよいが、代わりに、アセンブリ言語やマシン語で実行することもできる。いずれの場合でも、コンパイラ型言語またはインタプリタ型言語であればよい。
【００７５】
本発明は、プログラムコードの形で実施してもよい。電気配線またはケーブルといった何らかの伝送媒体を介するか、ローカルエリアネットワーク、広域ネットワーク、インターネットまたはイントラネットを含む光ファイバによるネットワークを介して、または伝送の他の形を介してこのプログラムコードを伝送する。ここで、コンピュータなどのマシンがこのプログラムコードを受け取ってロードすると、そのマシンが本発明を実行する装置となる。
【００７６】
汎用プロセッサにこのプログラムコードを実装すると、その汎用プロセッサと組み合わさり、特定の論理回路と同様に動作する固有の装置を提供することができる。
【００７７】
さらに、コンピュータネットワークの一部として配置するか、分散コンピューティング環境に配置することができるどのようなコンピュータやクライアント装置もしくはサーバ装置に関しても本発明を実装することができる。この点で、本発明は、いかなるコンピュータシステムや環境にも関する。このコンピュータシステムや環境は、あらゆるメモリまたはストレージユニットを有する。また、あらゆるアプリケーションと、様々なストレージユニットやストレージボリュームで生じるプロセスを有し、本発明に係るデータベースストア中に持続するオブジェクトの処理に関して用いることができる。本発明は、ネットワーク環境か分散コンピューティング環境にサーバコンピュータおよびクライアントコンピュータを配置した環境で、リモートストレージ域またはローカルストレージ域を有する環境に適用されてもよい。本発明は、スタンドアローンのコンピュータ装置に適用されてもよく、その装置は、プログラム言語の機能性を有し、リモートサービスまたはローカルサービスと関連して情報を生成し、受け取り、伝送するための解釈能力および実行能力を有する。
【００７８】
分散コンピューティングは、コンピュータ装置とシステムとの間の交換によって、コンピュータ資源およびサービスの共有を容易にする。このコンピュータ資源およびサービスは、これに限定されないが、ファイルに関する情報、キャッシュ記憶、およびディスクストアの交換を含む。分散コンピューティングは、ネットワークの接続性を活用して、クライアントがその総合力を利用して業務全体に利益を与えることを可能とする。この点で、様々な装置が、オブジェクトを永続させる本発明の方法に関して行う処理と何らかの関係があるアプリケーションやオブジェクト、資源を有することができる。
【００７９】
図９は、ネットワークまたは分散コンピューティング環境の典型的な概略図を示す。この分散コンピューティング環境は、計算オブジェクト１０ａ、１０ｂ等、および計算オブジェクトまたはコンピューティングデバイス１１０ａ、１１０ｂ、１１０ｃ等を含む。これらのオブジェクトは、プログラム、メソッド、データストア、プログラム可能ロジック等である。オブジェクトには、ＰＤＡ、テレビ、ＭＰ３プレーヤ、個人用コンピュータ等の同じ装置の一部または別の装置の一部を含んでもよい。各オブジェクトは、通信ネットワーク１４を介して、別の計算オブジェクトと通信することができる。このネットワークはそれ自体に、図９のシステムに対するサービスを提供する別の計算オブジェクトおよびコンピューティングデバイスを含んでおり、それ自体が複数の相互接続ネットワークをあらわしている。本発明の一側面により、各オブジェクト１０ａ、１０ｂ等、または１１０ａ、１１０ｂ、１１０ｃ等は、本発明のオブジェクト永続化方法を実施するのに使用されるプロセスの使用を要求するための、ＡＰＬ、またはその他のオブジェクト、ソフトウエア、ファームウエア、および／またはハードウエアを使用するアプリケーションを含む。
【００８０】
１１０ｃ等のオブジェクトは、別のコンピューティングデバイス１０ａ、１０ｂ等、または１１０ａ、１１０ｂ、１１０ｃ等をホストにしてもよいことが理解できる。したがって、記述された物理的環境はコンピュータとして接続さる装置を示すが、これらの説明図は単に典型的なものであって、物理的環境はこの代わりに、ＰＤＡ、テレビ、ＭＰ３プレーヤなど各種のデジタル装置、インタフェース，ＣＯＭオブジェクト等の様々なフトウエアオブジェクトを含むものとして図示または記述してもよい。
【００８１】
分散コンピューティング環境をサポートするシステム、成分、およびネットワーク構成は、様々である。例えば、コンピューティングシステムは有線または無線システムを用いて、ローカルネットワークまたは広域分散ネットワークにより互いに接続してもよい。現在のところ、多くのネットワークがインターネットに接続されており、これが広域分散コンピューティングのためのインフラストラクチャを提供しており、多数の異なるネットワークを包含している。いずれのインフラストラクチャも本発明に付髄する典型的な通信として使用してもよい。
【００８２】
インターネットは典型的に、コンピュータネットワークの技術においては周知の、一連のプロトコル一式ＴＣＰ／ＩＰを用いたネットワークとゲートウエイの集合を指す。ＴＣＰ／ＩＰは「トランスミッション・コントロール・プロトコル(Transmission Control Protocol)／インターネット・プロトコル(Internet Protocol)」の頭文字である。インターネットは、地理的に分散しているリモートコンピュータのネットワークであってネットワークプロトコルを実行するコンピュータにより相互接続され、ユーザが（単数または複数の）ネットワークを通じて相互に交信し情報を共有することのできるものであると説明できる。このよう広範な情報が共有できるため、インターネットなどのリモートネットワークは、これまで典型的にオープンシステムへと発展してきたので、開発者はこのネットワークに対して専門的オペレーション、またはサービスを実行するためのソフトウエアアプリケーションを、実質的に制約を受けずに設計することができる。
【００８３】
こうして、ネットワークインフラストラクチャは、クライアント／サーバ、ピアツーピア、またはハイブリッドアーキテクチャ等、ネットワークトポロジーのホストを可能にした。「クライアント」とは、自分に関連のない別のクラスまたはグループのサービスを利用するクラスまたはグループのメンバーである。したがって、コンピューティングにおいては、クライアントとは、別のプログラムが提供するサービスを要求するプロセス、つまり大まかに言うと一式の命令またはタスクである。クライアントプロセスは、他のプログラムまたはサービス自体について作動の詳細を何ら「知る」必要なしに、要求されるサービスを利用する。クライアント／サーバアーキテクチャ、特にネットワークになっているシステムにおいて、クライアントは通常、他のコンピュータ、例えばサーバが提供する共有ネットワークリソースにアクセスするコンピュータである。環境によっていずれのコンピュータもクライアント、サーバ、または両者と見なせるが、図９の例において、コンピュータ１１０ａ、１１０ｂ等はクライアントとして、コンピュータ１０ａ、１０ｂなどはサーバとして捉えることができる。これらコンピューティングデバイスのいずれも、本発明のオブジェクト永続化技術に関わる方法でデータを処理する。
【００８４】
サーバは、典型的にはインターネットなどリモートまたはローカルネットワークを介してアクセスすることのできるリモートコンピュータシステムである。通信媒体を介して互いに通信し合いながら、クライアントプロセスは第１コンピュータシステムで、サーバプロセスは第２コンピュータシステムでそれぞれアクティブになり、これにより分散機能を提供しながら、複数のクライアントがサーバの情報収集能力を駆使することを可能にする。本発明の永続化機構に従って利用されるソフトウエアオブジェクトはいずれも、複数のコンピューティングデバイス全体に亘って分散される。
【００８５】
クライアント（単数または複数）およびサーバ（単数または複数）は、プロトコル層が提供する機能性を利用して互いに通信する。例えば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）は、ワールドワイドウェブ（ＷＷＷ）または「ウエブ（Web）」との関連で使用される共通プロトコルである。典型的には、インターネット・プロトコル（ＩＰ）アドレスなどのコンピュータアドレス、またはユニバーサルリソースロケータ（ＵＲＬ）など他のリファレンスを使用して、サーバまたはクライアントコンピュータを互いに識別することができる。ネットワークアドレスは、ＵＲＬアドレスと呼ぶことができる。通信は利用することのできる任意の通信媒体を通じて提供することができる。
【００８６】
このように、図９は、ネットワーク／バス経由でクライアントコンピュータと通信するサーバを伴った、本発明を採用できる典型的ネットワークまたは分散環境を示す。ネットワーク／バス１４は、ＬＡＮ、ＷＡＮ、イントラネット、インターネット、または他のネットワーク媒体で、本発明による携帯用コンピュータ、ハンドヘルドコンピュータ、シンクライアント、ネットワーク電気器具、またはＶＣＲ、ＴＶ、電子レンジ、電灯、電熱器等の多数のクライアントまたはリモートコンピューティングデバイス１１０ａ、１１０ｂ、１００ｄ、１１０ｅ等を備えたものでよい。したがって、本発明は、永続性オブジェクトを維持するのが望ましいものと接続した任意のコンピューティングデバイスに適用することを意図している。
【００８７】
通信ネットワーク／バス１４がインターネット等であるネットワーク環境においては、サーバ１０ａ、１０ｂ等は、ＨＴＴＰなど多数の公知のプロトコルのうち、任意のものを経由してそれと通信するクライアント１１０ａ、１１０ｂ、１００ｄ、１１０ｅ等のサーバとなることができる。サーバ１０ａ、１０ｂ等はまた、分散コンピューティング環境の特徴でもあるように、クライアント１１０ａ、１１０ｂ、１００ｄ、１１０ｅなどの役割を果たすこともできる。
【００８８】
通信は、必要に応じて、有線または無線で行なわれる。クライアント装置１１０ａ、１１０ｂ、１００ｄ、１１０ｅ等は、通信ネットワーク／バス１４を経由して通信しても、しなくてもよく、それらに関連する独立した通信をしてもよい。例えば、ＴＶまたはＶＣＲの場合は、それらの制御にネットワークの側面があってもなくてもよい。各クライアントコンピュータ１１０ａ、１１０ｂ、１００ｄ、１１０ｅ等と、サーバコンピュータ１０ａ、１０ｂ等には、各種アプリケーションプログラムモジュールまたはオブジェクト１３５および各種の型のストレージ要素またはオブジェクトに対する接続、またはアクセスを装備し、それらの全域に亘ってファイルまたはデータストリームを格納するか、またはそれらに対してファイルまたはデータストリームの一部（単数または複数）をダウンロード、送信または移動する。いずれのコンピュータ１０ａ、１０ｂ、１１０ａ、１１０ｂ等が、本発明によって処理されるデータを格納するためのデータベース、メモリ、またはその他のストレージ要素の維持および更新を担当してもよい。このように、本発明は、コンピュータネットワーク／バス１４にアクセスして交信することのできるクライアントコンピュータ１１０ａ、１１０ｂ等および、クライアントコンピュータ１１０ａ、１１０ｂ等およびデータベース２０と交信するサーバコンピュータ１０ａ、１０ｂ等を有するコンピュータネットワーク環境において利用することができる。
【００８９】
図１０および以下の説明は、それらと接続して本発明を実施できる適切なコンピューティングデバイスの簡潔な典型的コンテキストを提供することを目的とする。例えば、図９に示すクライアントおよびサーバコンピュータ、またはデバイスはいずれもこの形を取り得る。しかし、あらゆる種類のハンドヘルド、携帯用およびその他のコンピューティングオブジェクト、または計算オブジェクトは本発明に接続して、すなわちコンピューティング環境の中でデータの生成、処理、送受信ができるあらゆる場所から使用するものと意図されていることは明らかである。汎用コンピュータについて以下に記述するが、これは一例に過ぎず、本発明はネットワーク／バスのインターオペラビリティと交信機能を有するシンクライアントを用いて実施してもよい。このように、本発明は、極めて少数または最小限のクライアントリソースが関係するネットワークされたホストサービスの環境、例えばクライアントデバイスが電気器具におかれるオブジェクト等、単にネットワーク／バスに対するインタフェースの機能を果たすだけのネットワーク環境において実施してもよい。基本的に、データが格納され、またはそこからデータを回収し、または別のコンピュータに移動する場所がどこであれ、本発明のオブジェクト永続化方法の操作のために望ましい、または適した環境である。
【００９０】
必須ではないが、本発明は、サービスの開発者によりデバイスまたはオブジェクトのための使用に供された、および／または本発明に従って作動するアプリケーション、またはサーバソフトウエアに含まれるオペレーティングシステムを介して実施することができる。ソフトウエアは、プログラムモジュール等、コンピュータ実行可能命令の一般的状況として説明してもよいが、それはクライアントワークステーション、サーバ、またはその他のデバイス等の１または複数のコンピュータにより実行される。典型的に、プログラムモジュールには、特定のタスクを実行するかまたは特定の抽象データ型を実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等が含まれる。典型的に、プログラムモジュールの機能性は、各種実施例で記述するように必要に応じて、結合または分散される。さらに、本発明は、別のコンピュータシステム構成およびプロトコルを用いて実行してもよい。本発明との使用に適する他の公知のコンピューティングシステム、環境および／または構成には、個人用コンピュータ（ＰＣ）、現金自動預払い機、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサに基づくシステム、プログラム可能家庭用電化製品、ネットワークＰＣ、電気器具、電灯、環境制御要素、ミニコンピュータ、メインフレームコンピュータ等が含まれるが、これらに限定されるものではない。
【００９１】
図１０はこのように、本発明を実施するのに適するコンピューティングシステム環境１００の例を示しており、上述で明確ではあるが、コンピューティングシステム環境１００は適切なコンピューティング環境の一例に過ぎず、本発明の使用範囲または機能性に関し、何らの制限を加える意図はない。コンピューティング環境１００は、典型的オペレーティング環境１００に示すコンポーネントのどの１つまたはその組合せに関係しても、依存性または必要性を有するものと解釈すべきではない。
【００９２】
図１０を参照すると、本発明を実施するための典型的システムは、コンピュータ１１０の形の汎用コンピューティングデバイスを含むことがわかる。コンピュータ１１０のコンポーネントには、処理ユニット１２０、システムメモリ１３０、およびシステムメモリを含む各種システムコンポーネントを処理ユニット１２０に結合するシステムバス１２１が含まれるが、これらには限定されない。システムバス１２１は、各種のバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含む、いくつかあるバス構造の型のうちいずれでもよい。一例として、このようなアーキテクチャには業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ電子規格協会（ＶＥＳＡ）ローカルバス、および周辺部品相互接続（ＰＣＩ）バス（メザニンバスとも言う）が含まれるが、これらに限定はされない。
【００９３】
コンピュータ１１０は典型的に、各種のコンピュータ読取り可能媒体を含む。コンピュータ読取り可能媒体は、コンピュータ１００がアクセスできる利用可能な媒体であればいずれでも良く、揮発性および不揮発性媒体、リムーバブルおよび非リムーバブル媒体の両者を含む。例として、コンピュータ読取り可能媒体には、コンピュータストレージ媒体と通信媒体が含まれるが、これらに限定されない。コンピュータストレージ媒体には、コンピュータ読取り可能命令、データ構造、プログラムモジュールまたはその他のデータ等、情報を格納するための任意の方法または技術により実施される揮発性および不揮発性媒体、リムーバブルおよび非リムーバブル媒体の両者が含まれる。コンピュータストレージ媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤＲＯＭ、デジタル汎用ディスク（ＤＶＤ）またはその他の光ディスク記憶、磁気カセット、磁気テープ、磁気ディスクまたはその他の磁気記憶装置、またはその他の媒体で、所望の情報の格納に使用可能で、コンピュータ１１０がアクセスすることのできるものが含まれるが、これらには限られない。通信媒体は典型的に、コンピュータ読取り可能命令、データ構造、プログラムモジュールまたはその他のデータを、搬送波またはその他のトランスポート機構等の変調されたデータ信号の中に実現するもので、任意の情報配信媒体が含まれる。用語「変調されたデータ信号」は、その特徴の１つ以上の情報が信号の中に符号化する方法で設定または変更されている信号を意味する。一例として、通信媒体には、有線ネットワークまたは直接有線接続などの有線媒体、および音響，ＲＦ、赤外線およびその他の無線媒体などの無線媒体が含まれるが、これらに限定はされない。上述のいかなる組合せも、コンピュータ読取り可能媒体の範囲に含まれる。
【００９４】
システムメモリ１３０は、コンピュータストレージ媒体を、読取専用メモリ（ＲＯＭ）１３１、ランダムアクセスメモリ（ＲＡＭ）１３２など揮発性および／または不揮発性メモリの形で含む。起動中等にコンピュータ１１０の中の要素の間の情報転送を助ける基本ルーチンを含む基本入出力システム１３３（ＢＩＯＳ）は、典型的にＲＯＭ１３１の中に格納される。直ちにアクセス可能なおよび／または処理ユニット１２０上で現在演算中のデータおよび／またはプログラムモジュールは、典型的にＲＡＭ１３２に収容される。例として、図１０はオペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７を示すが、これらに限定はされない。
【００９５】
コンピュータ１１０はまた、他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピュータストレージ媒体をも含む。ほんの一例として、図８に、非リムーバブル、不揮発性磁気媒体に読取または書込を行うハードディスク１４１、リムーバブル、不揮発性磁気ディスク１５２に読取または書込をおこなう磁気ディスクドライブ１５１、およびＣＤ−ＲＷ、ＤＶＤ−ＲＷまたはその他の光媒体など、リムーバブル、不揮発性光ディスクに読取または書込をおこなう光ディスクドライブ１５５を示す。他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピュータストレージ媒体で典型オペレーティング環境に使用することができるものには、磁気テープカセット、フラッシュメモリカード、デジタル揮発性ディスク、デジタルビデオテープ、半導体ＲＡＭ、半導体ＲＯＭ等が含まれるが、これらに限定されるものではない。ハードディスクドライブ１４１は、典型的にインタフェース１４０など非リムーバブルメモリインタフェースを通じてシステムバス１２１に接続され、磁気ディスクドライブ１５１と光ディスクドライブ１５１は、典型的にインタフェース１５０などリムーバブルメモリインタフェースを介してシステムバス１２１に接続される。
【００９６】
上に説明し図１０に示すデバイスおよびそれらに関連するコンピュータストレージ媒体は、コンピュータ読取り可能命令、データ構造、プログラムモジュール、およびその他のデータをコンピュータ１１０のために格納する。図１０では、例えば、ハードディスク１４１が、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６およびプログラムデータ１４７を格納していることを図示している。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６およびプログラムデータ１３７と同一であることも異なることあり得ることに注意すべきである。オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６およびプログラムデータ１４７には、異なる番号を与えて、少なくとも、それらは異なるものであることを示している。ユーザは、キーボード１６２などの入力装置及およびマウス、トラックボールまたはタッチパッドなどのポインティングデバイス１６１を通じてコンピュータ１１０にコマンドおよび情報を入力する。その他の入力装置（示さず）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナ等が含まれる。これらおよびその他の入力装置は、処理ユニット１２０に対し、システムバス１２１に結合されたユーザ入力インタフェース１６０を介して接続されることが多いが、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）など、別のインタフェースおよびバス構造により接続してもよい。グラフィックスインタフェース１８２もまたシステムバス１２１に接続される。１または複数のグラフィック処理装置（ＧＰＵ）１８４がグラフィックスインタフェース１８２と連絡する。モニタ１９１または別の型の表示装置も、ビデオインタフェース１９０などのインタフェース経由でシステムバス１２１と通信し、その次にビデオメモリ１８６と通信する。モニタ１９１に加えて、コンピュータはまた、スピーカ１９７およびプリンタ１９６など別の周辺出力装置をも含む。これらは出力周辺インタフェース１９５を通じて接続される。
【００９７】
コンピュータ１１０は、ネットワークまたは分散環境の中で、リモートコンピュータ１８０等、１または複数のリモートコンピュータに対する論理接続を用いて作動する。リモートコンピュータ１８０は、メモリストレージデバイス１８１のみを図１０に示すように、個人用コンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたはその他の共通ネットワークモードであって、典型的にコンピュータ１１０との関係で上述した要素の多数または全部を含む。図１０に描写する論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１と広域ネットワーク（ＷＡＮ）１７３を含むが、他のネットワーク／バスを含んでもよい。このようなネットワーク環境は、家庭、事務所、企業規模コンピュータネットワーク、イントラネットおよびインターネットにおいてはよくあることである。
【００９８】
ＬＡＮネットワーク環境で使用するとき、コンピュータ１１０はネットワークインタフェースまたはアダプタ１７０を用いてＬＡＮ１７１に接続される。ＷＡＮネットワーク環境で使用するとき、コンピュータ１１０は典型的に、インターネットなどのＷＡＮ７３を通じる通信を設定するためモデム１７２またはその他の手段を含む。内蔵または外付けのモデム１７２は、ユーザ入力インタフェース１６０またはその他の適切な機構を介して、システムバス１２１に接続される。ネットワーク環境においては、コンピュータ１１０またはその一部に関連して記述されたプログラムモジュールは、リモートメモリストレージデバイスに格納される。例として、図１０にリモートアプリケーションプログラム１８５を、メモリ装置１８１に常駐するものとして示すが、これに限定するものではない。示すネットワーク接続は見本であってコンピュータの間に通信リンクを確立する他の手段を使用してもよいことは理解できる。
【００９９】
既に例証したとおり、本発明は、データベースを格納するコンピュータのファイルシステム内の独立したファイルとしてデータベースストアに持続する、あるいは、データベースストアの外側のユーザ定義型のインスタンスのフィールドを格納／取得するシステムおよび方法を導く。本発明は、特に大きいテータ型をユーザ定義型のフィールドとしてデータベース管理システム内に格納するのに有利である。上述の実施例に対して、その広範な革新的概念から逸脱することなく、変更を加えることが可能なことは理解できる。例えば、本発明の実施例は、マイクロソフトのＳＱＬサーバデータベース管理システムで実施されているように上述されているが、本発明はユーザ定義型の作成をサポートするいかなるデータベース管理システムでも実現できることは理解できる。加えて、本発明のある側面は、上述のＷｉｎＦＳプラットホームのコンテキストで実現されると記述されているが、本発明のこれらの側面は決してその環境での実施に限定されないことも理解できる。むしろ、本発明のシステムと方法は、ユーザ定義型のインスタンスのフィールドの格納と取得に好適な任意のシステムにおいて実現される。したがって、本発明は開示された特定の実施例に限定されるものでなく、添付請求項で規定する本発明の精神と範囲内に属するすべての変更を含む意図であることが理解できる。
【図面の簡単な説明】
【０１００】
【図１】ユーザ定義型に関するマネージドコードクラス定義を示す模範コードのセグメントを示す図である。
【図２】マネージドコードでインスタンスが作成されているタイプのインスタンスのシリアライゼイションとシリアライゼイション解除を示すブロック図である。
【図３】ユーザ定義型のオブジェクトが永続しているデータベーステーブルを示すブロック図である。
【図４】本発明の機能を利用する模範ストレージプラットホームを示すブロック図である。
【図５】図４に示すストレージプラットホームコンテキストの中に、持続するユーザ定義型のオブジェクトに対しクエリを実行するためのプロセスを示すブロック図である。
【図６】「Person」と言う名のユーザ定義型のためのマネージドコードクラス定義を示す模範的コードのセグメントである。
【図７】本発明のシステムと方法の一実施例を示すブロック図である。
【図８】本発明の別の態様の実施例による、ユーザ定義型のインスタンスのフィールドのデータを含むファイルに対する「帯域外」アクセスのシステムおよび方法を示すブロック図である。
【図９】本発明が実施される各種計算装置を有する模範ネットワーク環境を示すブロック図である。
【図１０】本発明が実施される模範計算装置を示すブロック図である。
【特許請求の範囲】
【請求項１】
ユーザ定義型のインスタンスであるオブジェクトを、データベースストアに持続することができるシステムにおいて、ユーザ定義型の定義は、１または複数のフィールドおよび挙動を備え、各フィールドは、１つの代表的なデータ型を有し、前記フィールドの少なくとも１つは、前記データベースストアの外に、型定義の他のフィールドとは別のファイルとして格納される型のデータを含むものとして指定される方法であって、
要求を受け取ってユーザ定義型のインスタンスであるオブジェクトを格納すること、
オブジェクトのインスタンスの前記少なくとも１つの指定フィールド内の前記データを、データベースストアの外側のファイルとして格納すること、および、
オブジェクトのインスタンスの別の各フィールド内の前記データをデータベースストア内に格納すること
を備えたことを特徴とする方法。
【請求項２】
データベースストア内に格納するオブジェクトのフィールドのデータと、データベースストアの外にファイルとして格納するフィールドのデータとの間に、リンクを設けることをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項３】
データベースストア内に格納するオブジェクトのフィールドのデータを、データベースのテーブルの列内にフラグメントとして格納し、前記列はユーザ定義型として指定されることを特徴とする請求項１に記載の方法。
【請求項４】
オブジェクトと関連した固有の識別子を、テーブルの別の列の中で、オブジェクトのフィールドのデータと同一行に格納することを特徴とする請求項３に記載の方法。
【請求項５】
前記少なくとも１つのオブジェクトの指定フィールド内のデータを、データベースサーバが実行するコンピュータファイルシステムの所定のディレクトリ内のファイルとして格納することを特徴とする請求項１に記載の方法。
【請求項６】
前記少なくとも１つのフィールドのデータをデータベースストアの外に格納するファイルに対するアクセスを、コンピュータのファイルシステムを通して、アプリケーションにより設けることをさらに備えたことを特徴とする方法。
【請求項７】
前記少なくとも１つのフィールドのデータを格納するファイルに対するアクセスをアプリケーションにより設ける前記ステップは、
コンピュータのファイルシステムへのアプリケーションプログラミングインタフェースを介し、アプリケーションからの呼出を受け取り、ファイルを開くことであって、前記呼出は、データベースストア内で、オブジェクトのフィールドをオブジェクトの同一性によって識別すること、
データベースストア内のオブジェクトのフィールドの同一性から、コンピュータのファイルシステム内の、そのオブジェクトのフィールドのデータを含むファイルへのパスを判定すること、および、
判定したパスを用いてファイルを開く呼出を実行すること
を備えたことを特徴とする請求項６に記載の方法。
【請求項８】
コンピュータのファイルシステムは、マイクロソフトＮＴＦＳファイルシステムを備え、ファイルシステムに対するアプリケーションプログラミングインタフェースは、Ｗｉｎ３２アプリケーションプログラミングインタフェースを備えることを特徴とする請求項７に記載の方法。
【請求項９】
オブジェクトの型を、マネージドコードでクラスとして定義することを特徴とする請求項１に記載の方法。
【請求項１０】
コンピュータのデータベースストア内にデータを格納する方法において、
データベースストア内に永続できるオブジェクトの型を定義することであって、型の定義は、フィールドおよび挙動を備え、各フィールドはそれぞれのデータ型を有すること、および、
型の定義の少なくとも１つのフィールドを、データベースストアの外に、型の定義の他のフィールドから離してではあるが、定義型の１部として前記他のフィールドへの関連を失うことなくファイルとして格納すべき型のデータを含むものとして指定すること
を備えたことを特徴とする方法。
【請求項１１】
オブジェクトの型をマネージドコードでクラスとして定義することを特徴とする請求項１０に記載の方法。
【請求項１２】
要求を受け取り、ユーザ定義型のインスタンスであるオブジェクトを格納すること、
オブジェクトのインスタンスの前記少なくとも１つの指定フィールド内のデータを、データベースストアの外にファイルとして格納すること、および、
オブジェクトのインスタンスの別の各フィールド内のデータをデータベースストア内に格納すること
をさらに備えたことを特徴とする請求項１０に記載の方法。
【請求項１３】
データベースストア内に格納するオブジェクトのフィールドのデータと、データベースストアの外にファイルとして格納するフィールドのデータとの間に、リンクを設けることをさらに備えたことを特徴とする請求項１２に記載の方法。
【請求項１４】
データベースストア内に格納するオブジェクトのフィールドのデータを、データベースの列内に、フラグメントとして格納し、前記列はテーブルのユーザ定義型と指定されることを特徴とする請求項１２に記載の方法。
【請求項１５】
オブジェクトに関連した固有の識別子を、テーブルの別の列内に、オブジェクトのフィールドのデータと同一行で格納することを特徴とする請求項１４に記載の方法。
【請求項１６】
オブジェクトの前記少なくとも１つの指定されたフィールド内のデータを、システムを実行するコンピュータのファイルシステムの所定のディレクトリ内にファイルとして格納することを特徴とする請求項１２に記載の方法。
【請求項１７】
ユーザ定義型のインスタンスであるオブジェクトを持続できるデータベースストアであって、ユーザ定義型の定義が１または複数のフィールドおよび挙動を備え、各フィールドは、それぞれのデータ型を有し、少なくとも１つの定義のフィールドを、データベースストアの外に、型の定義の他のフィールドから離してファイルとして記録する型のデータを含むものとして指定するデータベースストアと、
要求を受けて、ユーザ定義型のインスタンスであるオブジェクトを格納し、その要求に応じ、オブジェクトのインスタンスの前記少なくとも１つの指定フィールド内のデータを、データベースストアの外のファイルとして格納し、データベースストア内に、オブジェクトのインスタンスの他の各フィールド内のデータを格納するデータベースエンジンと
を備えたことを特徴とするシステム。
【請求項１８】
前記データベースエンジンは、データベースストア内に格納するオブジェクトのフィールドのデータと、データベースストアの外にファイルとして格納するフィールドのデータとの間に、リンクを設けることを特徴とする請求項１７に記載のシステム。
【請求項１９】
データベースストア内に格納するオブジェクトのフィールドのデータを、データベースのテーブルの列内に、フラグメントとして格納し、前記列はユーザ定義型と指定されていることを特徴とする請求項１７に記載のシステム。
【請求項２０】
オブジェクトに関連した固有の識別子を、テーブルの別の列内に、オブジェクトのフィールドのデータと同一行で格納することを特徴とする請求項１９に記載のシステム。
【請求項２１】
オブジェクトの前記少なくとも１つの指定フィールドにあるデータを、データベースサーバが実行するコンピュータファイルシステムの所定のディレクトリのファイルとして格納することを特徴とする請求項１７に記載のシステム。
【請求項２２】
前記システムは、前記少なくとも１つのフィールドのデータをデータベースストアの外に格納したファイルへのアクセスを、コンピュータのファイルシステムを介して、アプリケーションにより設けることを特徴とする請求項２１に記載のシステム。
【請求項２３】
前記アクセスを、
アプリケーションからの呼出を、コンピュータのファイルシステムへのアプリケーションプログラミングインタフェースを介して受け取って、ファイルを開くことであって、前記呼出は、データベースストア内での同一性によって、オブジェクトのフィールドを識別すること、
データベースストア内での、オブジェクトのフィールドの同一性から、オブジェクトのそのフィールドのデータを含むファイルへの、コンピュータのファイルシステム内のパスを判定すること、および、
呼出を実行し、判定したパスを用いてファイルを開くこと
により提供することを特徴とする請求項２２に記載のシステム。
【請求項２４】
前記コンピュータのファイルシステムは、マイクロソフトＮＴＦＳファイルシステムを備え、ファイルシステムへのアプリケーションプログラミングインタフェースは、Ｗｉｎ３２アプリケーションプログラミングインタフェースを備えることを特徴とする請求項２３に記載のシステム。
【請求項２５】
ユーザ定義型のインスタンスであるオブジェクトを、データベースストア内に持続できるシステムで用いるためのプログラムコードを格納しているコンピュータ読取り可能媒体であって、ユーザ定義型の定義は、１または複数のフィールドおよび挙動を備え、各フィールドは、それぞれのデータ型を有し、定義の前記フィールドの少なくとも１つを、データベースストアの外に、型の定義の他のフィールドから離して、ファイルとして格納される型のデータを含むものとして指定し、前記プログラムコードをコンピュータシステム上で実行すると、前記コンピュータシステムに、
要求を受け取り、ユーザ定義型のインスタンスであるオブジェクトを格納すること、
前記少なくとも１つの指定した、オブジェクトのインスタンスのフィールドに、データベースストアの外にファイルとして前記データを格納すること、および、
データベースストア内で、オブジェクトのインスタンスの他のフィールドの各々の中に、前記データを格納すること
を実行させる前記プログラムコードを備えたことを特徴とするコンピュータ読取り可能媒体。
【請求項２６】
前記プログラムコードは、コンピュータに、データベースストア内に格納するオブジェクトのフィールドのデータと、データベースストアの外にファイルとして格納するフィールドのデータとの間のリンクを設けさせることを特徴とする請求項２５に記載のコンピュータ読取り可能媒体。
【請求項２７】
前記プログラムコードは、データベースストア内に格納するオブジェクトのフィールドのデータを、データベースのテーブルの列内に、フラグメントとしてさらに格納させ、前記列はユーザ定義型として指定されることを特徴とする請求項２５に記載のコンピュータ読取り可能媒体。
【請求項２８】
前記プログラムコードは、コンピュータに、オブジェクトに関連した固有の識別子を、テーブルの別の列内に、オブジェクトのフィールドのデータと同一行で、さらに格納させることを特徴とする請求項２７に記載のコンピュータ読取り可能媒体。
【請求項２９】
前記プログラムコードは、コンピュータに、オブジェクトの前記少なくとも１つの指定されたフィールドにあるデータを、システムを実行するコンピュータのファイルシステムの所定のディレクトリ内にファイルとして、格納させることを特徴とする請求項２５に記載のコンピュータ読取り可能媒体。
【請求項３０】
前記プログラムコードは、コンピュータに、前記少なくとも１つのフィールドのデータを格納するデータベースストアの外のファイルへのアクセスを、コンピュータのファイルシステムを介して、アプリケーションにより設けさせる請求項２９に記載のコンピュータ読取り可能媒体。
【請求項３１】
前記プログラムコードは、コンピュータに、アプリケーションによって、前記少なくとも１つのフィールドのデータを格納したファイルへのアクセスを、
コンピュータのファイルシステムへのアプリケーションプログラミングインタフェースを介して、アプリケーションからの呼出を受け取り、ファイルを開くことであって、前記呼出は、オブジェクトのフィールドをデータベースストア内での同一性により識別すること、
データベースストア内で、オブジェクトのフィールドの同一性から、コンピュータのファイルシステム内の、そのオブジェクトのフィールドのデータを含むファイルへのパスを判定すること、および、
判定したパスを用いてファイルを開く呼出を実行すること
によって提供することを特徴とする請求項３０に記載のコンピュータ読取り可能媒体。
【請求項３２】
コンピュータのファイルシステムは、マイクロソフトＮＴＦＳファイルシステムを備え、ファイルシステムに対するアプリケーションプログラミングインタフェースは、Ｗｉｎ３２アプリケーションプログラミングインタフェースを備えたことを特徴とする請求項３１に記載のコンピュータ読取り可能媒体。
【請求項３３】
オブジェクトの型を、マネージドコードでクラスとして定義する請求項２５に記載のコンピュータ読取り可能媒体。
【請求項１】
ユーザ定義型のインスタンスであるオブジェクトを、データベースストアに持続することができるシステムにおいて、ユーザ定義型の定義は、１または複数のフィールドおよび挙動を備え、各フィールドは、１つの代表的なデータ型を有し、前記フィールドの少なくとも１つは、前記データベースストアの外に、型定義の他のフィールドとは別のファイルとして格納される型のデータを含むものとして指定される方法であって、
要求を受け取ってユーザ定義型のインスタンスであるオブジェクトを格納すること、
オブジェクトのインスタンスの前記少なくとも１つの指定フィールド内の前記データを、データベースストアの外側のファイルとして格納すること、および、
オブジェクトのインスタンスの別の各フィールド内の前記データをデータベースストア内に格納すること
を備えたことを特徴とする方法。
【請求項２】
データベースストア内に格納するオブジェクトのフィールドのデータと、データベースストアの外にファイルとして格納するフィールドのデータとの間に、リンクを設けることをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項３】
データベースストア内に格納するオブジェクトのフィールドのデータを、データベースのテーブルの列内にフラグメントとして格納し、前記列はユーザ定義型として指定されることを特徴とする請求項１に記載の方法。
【請求項４】
オブジェクトと関連した固有の識別子を、テーブルの別の列の中で、オブジェクトのフィールドのデータと同一行に格納することを特徴とする請求項３に記載の方法。
【請求項５】
前記少なくとも１つのオブジェクトの指定フィールド内のデータを、データベースサーバが実行するコンピュータファイルシステムの所定のディレクトリ内のファイルとして格納することを特徴とする請求項１に記載の方法。
【請求項６】
前記少なくとも１つのフィールドのデータをデータベースストアの外に格納するファイルに対するアクセスを、コンピュータのファイルシステムを通して、アプリケーションにより設けることをさらに備えたことを特徴とする方法。
【請求項７】
前記少なくとも１つのフィールドのデータを格納するファイルに対するアクセスをアプリケーションにより設ける前記ステップは、
コンピュータのファイルシステムへのアプリケーションプログラミングインタフェースを介し、アプリケーションからの呼出を受け取り、ファイルを開くことであって、前記呼出は、データベースストア内で、オブジェクトのフィールドをオブジェクトの同一性によって識別すること、
データベースストア内のオブジェクトのフィールドの同一性から、コンピュータのファイルシステム内の、そのオブジェクトのフィールドのデータを含むファイルへのパスを判定すること、および、
判定したパスを用いてファイルを開く呼出を実行すること
を備えたことを特徴とする請求項６に記載の方法。
【請求項８】
コンピュータのファイルシステムは、マイクロソフトＮＴＦＳファイルシステムを備え、ファイルシステムに対するアプリケーションプログラミングインタフェースは、Ｗｉｎ３２アプリケーションプログラミングインタフェースを備えることを特徴とする請求項７に記載の方法。
【請求項９】
オブジェクトの型を、マネージドコードでクラスとして定義することを特徴とする請求項１に記載の方法。
【請求項１０】
コンピュータのデータベースストア内にデータを格納する方法において、
データベースストア内に永続できるオブジェクトの型を定義することであって、型の定義は、フィールドおよび挙動を備え、各フィールドはそれぞれのデータ型を有すること、および、
型の定義の少なくとも１つのフィールドを、データベースストアの外に、型の定義の他のフィールドから離してではあるが、定義型の１部として前記他のフィールドへの関連を失うことなくファイルとして格納すべき型のデータを含むものとして指定すること
を備えたことを特徴とする方法。
【請求項１１】
オブジェクトの型をマネージドコードでクラスとして定義することを特徴とする請求項１０に記載の方法。
【請求項１２】
要求を受け取り、ユーザ定義型のインスタンスであるオブジェクトを格納すること、
オブジェクトのインスタンスの前記少なくとも１つの指定フィールド内のデータを、データベースストアの外にファイルとして格納すること、および、
オブジェクトのインスタンスの別の各フィールド内のデータをデータベースストア内に格納すること
をさらに備えたことを特徴とする請求項１０に記載の方法。
【請求項１３】
データベースストア内に格納するオブジェクトのフィールドのデータと、データベースストアの外にファイルとして格納するフィールドのデータとの間に、リンクを設けることをさらに備えたことを特徴とする請求項１２に記載の方法。
【請求項１４】
データベースストア内に格納するオブジェクトのフィールドのデータを、データベースの列内に、フラグメントとして格納し、前記列はテーブルのユーザ定義型と指定されることを特徴とする請求項１２に記載の方法。
【請求項１５】
オブジェクトに関連した固有の識別子を、テーブルの別の列内に、オブジェクトのフィールドのデータと同一行で格納することを特徴とする請求項１４に記載の方法。
【請求項１６】
オブジェクトの前記少なくとも１つの指定されたフィールド内のデータを、システムを実行するコンピュータのファイルシステムの所定のディレクトリ内にファイルとして格納することを特徴とする請求項１２に記載の方法。
【請求項１７】
ユーザ定義型のインスタンスであるオブジェクトを持続できるデータベースストアであって、ユーザ定義型の定義が１または複数のフィールドおよび挙動を備え、各フィールドは、それぞれのデータ型を有し、少なくとも１つの定義のフィールドを、データベースストアの外に、型の定義の他のフィールドから離してファイルとして記録する型のデータを含むものとして指定するデータベースストアと、
要求を受けて、ユーザ定義型のインスタンスであるオブジェクトを格納し、その要求に応じ、オブジェクトのインスタンスの前記少なくとも１つの指定フィールド内のデータを、データベースストアの外のファイルとして格納し、データベースストア内に、オブジェクトのインスタンスの他の各フィールド内のデータを格納するデータベースエンジンと
を備えたことを特徴とするシステム。
【請求項１８】
前記データベースエンジンは、データベースストア内に格納するオブジェクトのフィールドのデータと、データベースストアの外にファイルとして格納するフィールドのデータとの間に、リンクを設けることを特徴とする請求項１７に記載のシステム。
【請求項１９】
データベースストア内に格納するオブジェクトのフィールドのデータを、データベースのテーブルの列内に、フラグメントとして格納し、前記列はユーザ定義型と指定されていることを特徴とする請求項１７に記載のシステム。
【請求項２０】
オブジェクトに関連した固有の識別子を、テーブルの別の列内に、オブジェクトのフィールドのデータと同一行で格納することを特徴とする請求項１９に記載のシステム。
【請求項２１】
オブジェクトの前記少なくとも１つの指定フィールドにあるデータを、データベースサーバが実行するコンピュータファイルシステムの所定のディレクトリのファイルとして格納することを特徴とする請求項１７に記載のシステム。
【請求項２２】
前記システムは、前記少なくとも１つのフィールドのデータをデータベースストアの外に格納したファイルへのアクセスを、コンピュータのファイルシステムを介して、アプリケーションにより設けることを特徴とする請求項２１に記載のシステム。
【請求項２３】
前記アクセスを、
アプリケーションからの呼出を、コンピュータのファイルシステムへのアプリケーションプログラミングインタフェースを介して受け取って、ファイルを開くことであって、前記呼出は、データベースストア内での同一性によって、オブジェクトのフィールドを識別すること、
データベースストア内での、オブジェクトのフィールドの同一性から、オブジェクトのそのフィールドのデータを含むファイルへの、コンピュータのファイルシステム内のパスを判定すること、および、
呼出を実行し、判定したパスを用いてファイルを開くこと
により提供することを特徴とする請求項２２に記載のシステム。
【請求項２４】
前記コンピュータのファイルシステムは、マイクロソフトＮＴＦＳファイルシステムを備え、ファイルシステムへのアプリケーションプログラミングインタフェースは、Ｗｉｎ３２アプリケーションプログラミングインタフェースを備えることを特徴とする請求項２３に記載のシステム。
【請求項２５】
ユーザ定義型のインスタンスであるオブジェクトを、データベースストア内に持続できるシステムで用いるためのプログラムコードを格納しているコンピュータ読取り可能媒体であって、ユーザ定義型の定義は、１または複数のフィールドおよび挙動を備え、各フィールドは、それぞれのデータ型を有し、定義の前記フィールドの少なくとも１つを、データベースストアの外に、型の定義の他のフィールドから離して、ファイルとして格納される型のデータを含むものとして指定し、前記プログラムコードをコンピュータシステム上で実行すると、前記コンピュータシステムに、
要求を受け取り、ユーザ定義型のインスタンスであるオブジェクトを格納すること、
前記少なくとも１つの指定した、オブジェクトのインスタンスのフィールドに、データベースストアの外にファイルとして前記データを格納すること、および、
データベースストア内で、オブジェクトのインスタンスの他のフィールドの各々の中に、前記データを格納すること
を実行させる前記プログラムコードを備えたことを特徴とするコンピュータ読取り可能媒体。
【請求項２６】
前記プログラムコードは、コンピュータに、データベースストア内に格納するオブジェクトのフィールドのデータと、データベースストアの外にファイルとして格納するフィールドのデータとの間のリンクを設けさせることを特徴とする請求項２５に記載のコンピュータ読取り可能媒体。
【請求項２７】
前記プログラムコードは、データベースストア内に格納するオブジェクトのフィールドのデータを、データベースのテーブルの列内に、フラグメントとしてさらに格納させ、前記列はユーザ定義型として指定されることを特徴とする請求項２５に記載のコンピュータ読取り可能媒体。
【請求項２８】
前記プログラムコードは、コンピュータに、オブジェクトに関連した固有の識別子を、テーブルの別の列内に、オブジェクトのフィールドのデータと同一行で、さらに格納させることを特徴とする請求項２７に記載のコンピュータ読取り可能媒体。
【請求項２９】
前記プログラムコードは、コンピュータに、オブジェクトの前記少なくとも１つの指定されたフィールドにあるデータを、システムを実行するコンピュータのファイルシステムの所定のディレクトリ内にファイルとして、格納させることを特徴とする請求項２５に記載のコンピュータ読取り可能媒体。
【請求項３０】
前記プログラムコードは、コンピュータに、前記少なくとも１つのフィールドのデータを格納するデータベースストアの外のファイルへのアクセスを、コンピュータのファイルシステムを介して、アプリケーションにより設けさせる請求項２９に記載のコンピュータ読取り可能媒体。
【請求項３１】
前記プログラムコードは、コンピュータに、アプリケーションによって、前記少なくとも１つのフィールドのデータを格納したファイルへのアクセスを、
コンピュータのファイルシステムへのアプリケーションプログラミングインタフェースを介して、アプリケーションからの呼出を受け取り、ファイルを開くことであって、前記呼出は、オブジェクトのフィールドをデータベースストア内での同一性により識別すること、
データベースストア内で、オブジェクトのフィールドの同一性から、コンピュータのファイルシステム内の、そのオブジェクトのフィールドのデータを含むファイルへのパスを判定すること、および、
判定したパスを用いてファイルを開く呼出を実行すること
によって提供することを特徴とする請求項３０に記載のコンピュータ読取り可能媒体。
【請求項３２】
コンピュータのファイルシステムは、マイクロソフトＮＴＦＳファイルシステムを備え、ファイルシステムに対するアプリケーションプログラミングインタフェースは、Ｗｉｎ３２アプリケーションプログラミングインタフェースを備えたことを特徴とする請求項３１に記載のコンピュータ読取り可能媒体。
【請求項３３】
オブジェクトの型を、マネージドコードでクラスとして定義する請求項２５に記載のコンピュータ読取り可能媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公表番号】特表２００７−５０９４２３（Ｐ２００７−５０９４２３Ａ）
【公表日】平成１９年４月１２日（２００７．４．１２）
【国際特許分類】
【出願番号】特願２００６−５３６５９１（Ｐ２００６−５３６５９１）
【出願日】平成１６年７月２９日（２００４．７．２９）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０２４５２６
【国際公開番号】ＷＯ２００５／０４５７０６
【国際公開日】平成１７年５月１９日（２００５．５．１９）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公表日】平成１９年４月１２日（２００７．４．１２）
【国際特許分類】
【出願日】平成１６年７月２９日（２００４．７．２９）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０２４５２６
【国際公開番号】ＷＯ２００５／０４５７０６
【国際公開日】平成１７年５月１９日（２００５．５．１９）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]