JP5043175B2 - 型が定義されているデータベースストアの外側でのユーザ定義型フィールドの格納および取得のためのシステムと方法 - Google Patents

Description

（関連特許）
本発明は、その全体を参照として組込む２００３年１０月２３日提出、米国特許出願１０／６９２，２２７号に対する優先権を主張する。

（著作権表示と承認）
本特許文書の開示の一部には、著作権保護を受ける資料が含まれる。著作権所有者は、特許商標事務所のファイルまたは記録に現れるときは、本特許文書または特許開示を何人が複製することにも異議を申し立てないが、別途の場合はいかなるものであれ著作権権利を留保する。以下の記載は本文書に適用される、「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」と言う名のユーザ定義型のためのマネージドコードクラス定義を示す模範的コードのセグメントである。 本発明のシステムと方法の一実施例を示すブロック図である。 本発明の別の態様の実施例による、ユーザ定義型のインスタンスのフィールドのデータを含むファイルに対する「帯域外」アクセスのシステムおよび方法を示すブロック図である。 本発明が実施される各種計算装置を有する模範ネットワーク環境を示すブロック図である。 本発明が実施される模範計算装置を示すブロック図である。

本発明の対象を特異性とともに記述して、法令の要件に対処する。しかし、記述自体は本特許の範囲を限定する意図のものではない。正確には、発明者らは、この請求内容が別の方法でもまた実現され、本文書に記述するものに類似の異なるステップまたは要素を、現在または将来の別の技術と結合して含むことを考慮に入れている。さらに、ここで使用される用語「ステップ」は、採用される方法の異なる側面を意味するけれども、この用語は、個別ステップの順序を明確に記述しているのでない限りおよびその場合を除いて、ここに開示する各種ステップのうちまたはその間の何らかの特別の順序を意味するものと、解釈されないものとする。

上述のように、本発明は、例えば、デジタル画像、ビデオ、オーディオなどを含む膨大なデータ型などある種のデータ型を、データベースストアの中にユーザ定義型のフィールドとして格納するための方法を指向する。本発明によると、データベースストアに持続することのできるオブジェクトのタイプを、ユーザが定義する。タイプ定義にはフィールドと挙動が含まれ、各フィールドはそれぞれのデータ型を有する。１または複数のタイプ定義のフィールドを、データベースストア外側のファイルとして、タイプ定義の別のフィールドとは別個に格納するべき型の収容データとして、指定する。ユーザ定義型のインスタンスであるオブジェクトを格納する要求を受け取り、オブジェクトのそのように指定されているフィールドのいずれかにあるデータをデータベースストアの外側のファイルに格納する。特に、データベースストアを実装するコンピュータのファイルシステムの中に格納するのが好適である。オブジェクトの別のフィールドのそれぞれの中のデータは、通常の方法でデータベースストアの中に格納される。データベースストアは、永続性オブジェクトとデータベースストア外側のファイルとして格納されるフィールドのデータとの間のリンク、または参照を維持する。

図６は、ユーザ定義型の定義の模範的部分コードリストで、本発明の一実施例によって、タイプのインスタンスがデータベースストアの中に持続するとき、その外に格納されるフィールドとするタイプのフィールドの指定を示す。具体的に説明すると、「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）」との関連で使用される共通プロトコルである。典型的には、インターネット・プロトコル（ＩＰ）アドレスなどのコンピュータアドレス、またはユニバーサルリソースロケータ（ＵＲＬ）など他のリファレンスを使用して、サーバまたはクライアントコンピュータを互いに識別することができる。ネットワークアドレスは、ＵＲＬアドレスと呼ぶことができる。通信は利用することのできる任意の通信媒体を通じて提供することができる。

このように、図９は、ネットワーク／バス経由でクライアントコンピュータと通信するサーバを伴った、本発明を採用できる典型的ネットワークまたは分散環境を示す。ネットワーク／バス１４は、ＬＡＮ、ＷＡＮ、イントラネット、インターネット、または他のネットワーク媒体で、本発明による携帯用コンピュータ、ハンドヘルドコンピュータ、シンクライアント、ネットワーク電気器具、またはＶＣＲ、ＴＶ、電子レンジ、電灯、電熱器等の多数のクライアントまたはリモートコンピューティングデバイス１１０ａ、１１０ｂ、１００ｄ、１１０ｅ等を備えたものでよい。したがって、本発明は、永続性オブジェクトを維持するのが望ましいものと接続した任意のコンピューティングデバイスに適用することを意図している。

通信ネットワーク／バス１４がインターネット等であるネットワーク環境においては、サーバ１０ａ、１０ｂ等は、ＨＴＴＰなど多数の公知のプロトコルのうち、任意のものを経由してそれと通信するクライアント１１０ａ、１１０ｂ、１００ｄ、１１０ｅ等のサーバとなることができる。サーバ１０ａ、１０ｂ等はまた、分散コンピューティング環境の特徴でもあるように、クライアント１１０ａ、１１０ｂ、１００ｄ、１１０ｅなどの役割を果たすこともできる。

通信は、必要に応じて、有線または無線で行なわれる。クライアント装置１１０ａ、１１０ｂ、１００ｄ、１１０ｅ等は、通信ネットワーク／バス１４を経由して通信しても、しなくてもよく、それらに関連する独立した通信をしてもよい。例えば、ＴＶまたはＶＣＲの場合は、それらの制御にネットワークの側面があってもなくてもよい。各クライアントコンピュータ１１０ａ、１１０ｂ、１００ｄ、１１０ｅ等と、サーバコンピュータ１０ａ、１０ｂ等には、各種アプリケーションプログラムモジュールまたはオブジェクト１３５および各種の型のストレージ要素またはオブジェクトに対する接続、またはアクセスを装備し、それらの全域に亘ってファイルまたはデータストリームを格納するか、またはそれらに対してファイルまたはデータストリームの一部（単数または複数）をダウンロード、送信または移動する。いずれのコンピュータ１０ａ、１０ｂ、１１０ａ、１１０ｂ等が、本発明によって処理されるデータを格納するためのデータベース、メモリ、またはその他のストレージ要素の維持および更新を担当してもよい。このように、本発明は、コンピュータネットワーク／バス１４にアクセスして交信することのできるクライアントコンピュータ１１０ａ、１１０ｂ等および、クライアントコンピュータ１１０ａ、１１０ｂ等およびデータベース２０と交信するサーバコンピュータ１０ａ、１０ｂ等を有するコンピュータネットワーク環境において利用することができる。

図１０および以下の説明は、それらと接続して本発明を実施できる適切なコンピューティングデバイスの簡潔な典型的コンテキストを提供することを目的とする。例えば、図９に示すクライアントおよびサーバコンピュータ、またはデバイスはいずれもこの形を取り得る。しかし、あらゆる種類のハンドヘルド、携帯用およびその他のコンピューティングオブジェクト、または計算オブジェクトは本発明に接続して、すなわちコンピューティング環境の中でデータの生成、処理、送受信ができるあらゆる場所から使用するものと意図されていることは明らかである。汎用コンピュータについて以下に記述するが、これは一例に過ぎず、本発明はネットワーク／バスのインターオペラビリティと交信機能を有するシンクライアントを用いて実施してもよい。このように、本発明は、極めて少数または最小限のクライアントリソースが関係するネットワークされたホストサービスの環境、例えばクライアントデバイスが電気器具におかれるオブジェクト等、単にネットワーク／バスに対するインタフェースの機能を果たすだけのネットワーク環境において実施してもよい。基本的に、データが格納され、またはそこからデータを回収し、または別のコンピュータに移動する場所がどこであれ、本発明のオブジェクト永続化方法の操作のために望ましい、または適した環境である。

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

図１０はこのように、本発明を実施するのに適するコンピューティングシステム環境１００の例を示しており、上述で明確ではあるが、コンピューティングシステム環境１００は適切なコンピューティング環境の一例に過ぎず、本発明の使用範囲または機能性に関し、何らの制限を加える意図はない。コンピューティング環境１００は、典型的オペレーティング環境１００に示すコンポーネントのどの１つまたはその組合せに関係しても、依存性または必要性を有するものと解釈すべきではない。

図１０を参照すると、本発明を実施するための典型的システムは、コンピュータ１１０の形の汎用コンピューティングデバイスを含むことがわかる。コンピュータ１１０のコンポーネントには、処理ユニット１２０、システムメモリ１３０、およびシステムメモリを含む各種システムコンポーネントを処理ユニット１２０に結合するシステムバス１２１が含まれるが、これらには限定されない。システムバス１２１は、各種のバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含む、いくつかあるバス構造の型のうちいずれでもよい。一例として、このようなアーキテクチャには業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ電子規格協会（ＶＥＳＡ）ローカルバス、および周辺部品相互接続（ＰＣＩ）バス（メザニンバスとも言う）が含まれるが、これらに限定はされない。

コンピュータ１１０は典型的に、各種のコンピュータ読取り可能媒体を含む。コンピュータ読取り可能媒体は、コンピュータ１００がアクセスできる利用可能な媒体であればいずれでも良く、揮発性および不揮発性媒体、リムーバブルおよび非リムーバブル媒体の両者を含む。例として、コンピュータ読取り可能媒体には、コンピュータストレージ媒体と通信媒体が含まれるが、これらに限定されない。コンピュータストレージ媒体には、コンピュータ読取り可能命令、データ構造、プログラムモジュールまたはその他のデータ等、情報を格納するための任意の方法または技術により実施される揮発性および不揮発性媒体、リムーバブルおよび非リムーバブル媒体の両者が含まれる。コンピュータストレージ媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤＲＯＭ、デジタル汎用ディスク（ＤＶＤ）またはその他の光ディスク記憶、磁気カセット、磁気テープ、磁気ディスクまたはその他の磁気記憶装置、またはその他の媒体で、所望の情報の格納に使用可能で、コンピュータ１１０がアクセスすることのできるものが含まれるが、これらには限られない。通信媒体は典型的に、コンピュータ読取り可能命令、データ構造、プログラムモジュールまたはその他のデータを、搬送波またはその他のトランスポート機構等の変調されたデータ信号の中に実現するもので、任意の情報配信媒体が含まれる。用語「変調されたデータ信号」は、その特徴の１つ以上の情報が信号の中に符号化する方法で設定または変更されている信号を意味する。一例として、通信媒体には、有線ネットワークまたは直接有線接続などの有線媒体、および音響，ＲＦ、赤外線およびその他の無線媒体などの無線媒体が含まれるが、これらに限定はされない。上述のいかなる組合せも、コンピュータ読取り可能媒体の範囲に含まれる。

システムメモリ１３０は、コンピュータストレージ媒体を、読取専用メモリ（ＲＯＭ）１３１、ランダムアクセスメモリ（ＲＡＭ）１３２など揮発性および／または不揮発性メモリの形で含む。起動中等にコンピュータ１１０の中の要素の間の情報転送を助ける基本ルーチンを含む基本入出力システム１３３（ＢＩＯＳ）は、典型的にＲＯＭ１３１の中に格納される。直ちにアクセス可能なおよび／または処理ユニット１２０上で現在演算中のデータおよび／またはプログラムモジュールは、典型的にＲＡＭ１３２に収容される。例として、図１０はオペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７を示すが、これらに限定はされない。

コンピュータ１１０はまた、他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピュータストレージ媒体をも含む。ほんの一例として、図８に、非リムーバブル、不揮発性磁気媒体に読取または書込を行うハードディスク１４１、リムーバブル、不揮発性磁気ディスク１５２に読取または書込をおこなう磁気ディスクドライブ１５１、およびＣＤ−ＲＷ、ＤＶＤ−ＲＷまたはその他の光媒体など、リムーバブル、不揮発性光ディスクに読取または書込をおこなう光ディスクドライブ１５５を示す。他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピュータストレージ媒体で典型オペレーティング環境に使用することができるものには、磁気テープカセット、フラッシュメモリカード、デジタル揮発性ディスク、デジタルビデオテープ、半導体ＲＡＭ、半導体ＲＯＭ等が含まれるが、これらに限定されるものではない。ハードディスクドライブ１４１は、典型的にインタフェース１４０など非リムーバブルメモリインタフェースを通じてシステムバス１２１に接続され、磁気ディスクドライブ１５１と光ディスクドライブ１５１は、典型的にインタフェース１５０などリムーバブルメモリインタフェースを介してシステムバス１２１に接続される。

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

コンピュータ１１０は、ネットワークまたは分散環境の中で、リモートコンピュータ１８０等、１または複数のリモートコンピュータに対する論理接続を用いて作動する。リモートコンピュータ１８０は、メモリストレージデバイス１８１のみを図１０に示すように、個人用コンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたはその他の共通ネットワークモードであって、典型的にコンピュータ１１０との関係で上述した要素の多数または全部を含む。図１０に描写する論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１と広域ネットワーク（ＷＡＮ）１７３を含むが、他のネットワーク／バスを含んでもよい。このようなネットワーク環境は、家庭、事務所、企業規模コンピュータネットワーク、イントラネットおよびインターネットにおいてはよくあることである。

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

既に例証したとおり、本発明は、データベースを格納するコンピュータのファイルシステム内の独立したファイルとしてデータベースストアに持続する、あるいは、データベースストアの外側のユーザ定義型のインスタンスのフィールドを格納／取得するシステムおよび方法を導く。本発明は、特に大きいテータ型をユーザ定義型のフィールドとしてデータベース管理システム内に格納するのに有利である。上述の実施例に対して、その広範な革新的概念から逸脱することなく、変更を加えることが可能なことは理解できる。例えば、本発明の実施例は、マイクロソフトのＳＱＬサーバデータベース管理システムで実施されているように上述されているが、本発明はユーザ定義型の作成をサポートするいかなるデータベース管理システムでも実現できることは理解できる。加えて、本発明のある側面は、上述のＷｉｎＦＳプラットホームのコンテキストで実現されると記述されているが、本発明のこれらの側面は決してその環境での実施に限定されないことも理解できる。むしろ、本発明のシステムと方法は、ユーザ定義型のインスタンスのフィールドの格納と取得に好適な任意のシステムにおいて実現される。したがって、本発明は開示された特定の実施例に限定されるものでなく、添付請求項で規定する本発明の精神と範囲内に属するすべての変更を含む意図であることが理解できる。

Claims (19)

1. 処理ユニットおよびメモリを備えるコンピュータシステムにおいて複数のフィールドを含むユーザ定義型のインスタンスであるオブジェクトを前記メモリに格納されたデータベースに持続して、前記オブジェクトの少なくとも１つのフィールドのデータを前記データベースの外のメモリに前記コンピュータシステムのファイルシステム内のファイルとして格納し前記オブジェクトの他のフィールドを前記データベース内に格納して、前記少なくとも１つのフィールドのデータを含むファイルは前記データベースか前記ファイルシステムのアプリケーションプログラミングインタフェースかによってアクセス可能である、コンピュータに実装される方法であって、
   前記処理ユニット上に実行中のコンポーネントによって、アプリケーションから前記ファイルシステムのアプリケーションプログラミングインタフェースへの呼び出しを受信して、前記ファイルを開くことであって、前記ファイルにおける前記オブジェクトの少なくとも１つのフィールドのデータを前記メモリに格納して、前記呼び出しは前記データベース内のオブジェクトのフィールドの同一性により前記オブジェクトのフィールドを識別する、開くこと、
   前記処理ユニット上に実行中のコンポーネントによって、前記データベースから前記アプリケーションが前記呼び出しにより識別されるオブジェクトのフィールドのデータにアクセスする許可を有するかどうかを判定すること、および、
   前記処理ユニット上に実行中のコンポーネントによって、前記アプリケーションが前記呼び出しにより識別されるオブジェクトのフィールドのデータにアクセスする許可を有する場合のみ前記ファイルシステムのアプリケーションプログラミングインタフェースを呼び出して前記ファイルを開くこと
   を備えたことを特徴とする方法。
2. 前記ファイルシステムのアプリケーションプログラミングインタフェースを呼び出して前記ファイルを開くより前に、前記データベース内のオブジェクトのフィールドの同一性から前記オブジェクトのフィールドのデータを含むファイルに対する前記コンピュータシステムのファイルシステム内のパスを判定することをさらに備えたことを特徴とする請求項１に記載の方法。
3. 前記アプリケーションから前記ファイルシステムのアプリケーションプログラミングインタフェースへの呼び出しを受信して、前記ファイルを閉じることであって、前記ファイルにおいて前記オブジェクトの少なくとも１つのフィールドのデータを格納する、閉じること、
   前記データベースに前記ファイルを閉じる呼び出しが受信されたことを知らせること、および、
   前記ファイルシステムのアプリケーションプログラミングインタフェースを呼び出して前記ファイルを閉じること
   をさらに備えたことを特徴とする請求項１に記載の方法。
4. 前記コンピュータシステムのファイルシステムはＮＴＦＳファイルシステムを含み、前記ファイルシステムのアプリケーションプログラミングインタフェースはＷｉｎ３２アプリケーションプログラミングインタフェースを含むことを特徴とする請求項１に記載の方法。
5. 前記オブジェクトのユーザ定義型は、マネージドコードにおけるクラスとして定義されることを特徴とする請求項１に記載の方法。
6. 前記データベースの外のファイルとして格納されたオブジェクトの少なくとも１つのフィールドのデータについてデータベースの動作を行うことであって、前記データベースの動作は前記データが前記データベース内に格納されたかのように少なくとも１つの指定されたフィールドのデータについて行われる、行うことをさらに備えた請求項１に記載の方法。
7. 前記データベースの動作は、挿入、更新、または削除の動作のうち１つを含むことを特徴とする請求項１に記載の方法。
8. コンピュータシステムにおいて複数のフィールドを含むユーザ定義型のインスタンスであるオブジェクトをデータベースに持続して、前記オブジェクトの少なくとも１つのフィールドのデータを前記データベースの外に前記コンピュータシステムのファイルシステム内のファイルとして格納し前記オブジェクトの他のフィールドを前記データベース内に格納して、前記少なくとも１つのフィールドのデータを含むファイルは前記データベースか前記ファイルシステムのアプリケーションプログラミングインタフェースかによってアクセス可能である、コンピュータシステムにおける使用のために格納された命令を有するコンピュータ読み取り可能な記録媒体であって、前記命令は、前記コンピュータシステムにより実行されると、前記コンピュータシステムに、
   アプリケーションから前記ファイルシステムのアプリケーションプログラミングインタフェースへの呼び出しを受信して、前記ファイルを開くことであって、前記ファイルにおいて前記オブジェクトの少なくとも１つのフィールドのデータを格納して、前記呼び出しは前記データベース内のオブジェクトのフィールドの同一性により前記オブジェクトのフィールドを識別する、開くこと、
   前記データベースから前記アプリケーションが前記呼び出しにより識別されるオブジェクトのフィールドのデータにアクセスする許可を有するかどうかを判定すること、および、
   前記アプリケーションが前記呼び出しにより識別されるオブジェクトのフィールドのデータにアクセスする許可を有する場合のみ前記ファイルシステムのアプリケーションプログラミングインタフェースを呼び出して前記ファイルを開くこと
   を実行させることを特徴とするコンピュータ読み取り可能な記録媒体。
9. 前記ファイルシステムのアプリケーションプログラミングインタフェースを呼び出して前記ファイルを開くより前に、前記命令は、前記コンピュータシステムに、前記データベース内のオブジェクトのフィールドの同一性から前記オブジェクトのフィールドのデータを含むファイルに対する前記コンピュータシステムのファイルシステム内のパスを判定することをさらに実行させることを特徴とする請求項８に記載のコンピュータ読み取り可能な記録媒体。
10. 前記命令は、前記コンピュータシステムに、
    前記アプリケーションから前記ファイルシステムのアプリケーションプログラミングインタフェースへの呼び出しを受信して、前記ファイルを閉じることであって、前記ファイルにおいて前記オブジェクトの少なくとも１つのフィールドのデータを格納する、閉じること、
    前記データベースに前記ファイルを閉じる呼び出しが受信されたことを知らせること、および、
    前記ファイルシステムのアプリケーションプログラミングインタフェースを呼び出して前記ファイルを閉じること
    をさらに実行させることを特徴とする請求項８に記載のコンピュータ読み取り可能な記録媒体。
11. 前記コンピュータシステムのファイルシステムはＮＴＦＳファイルシステムを含み、前記ファイルシステムのアプリケーションプログラミングインタフェースはＷｉｎ３２アプリケーションプログラミングインタフェースを含むことを特徴とする請求項８に記載のコンピュータ読み取り可能な記録媒体。
12. 前記オブジェクトのユーザ定義型は、マネージドコードにおけるクラスとして定義されることを特徴とする請求項８に記載のコンピュータ読み取り可能な記録媒体。
13. 前記命令は、前記コンピュータシステムに、前記データベースの外のファイルとして格納されたオブジェクトの少なくとも１つのフィールドのデータについてデータベースの動作を行うことをさらに実行させて、前記データベースの動作は前記データが前記データベース内に格納されたかのように少なくとも１つの指定されたフィールドのデータについて行われることを特徴とする請求項８に記載のコンピュータ読み取り可能な記録媒体。
14. 前記データベースの動作は、挿入、更新、または削除の動作のうち１つを含むことを特徴とする請求項８に記載のコンピュータ読み取り可能な記録媒体。
15. プロセッサと、
    アプリケーションプログラミングインタフェースを有するファイルシステムと、
    複数のフィールドを含むユーザ定義型のインスタンスであるオブジェクトを格納する、前記プロセッサ上実行するデータベースであって、前記オブジェクトの少なくとも１つのフィールドのデータを前記データベースの外に前記コンピュータシステムのファイルシステム内のファイルとして格納し前記オブジェクトの他のフィールドを前記データベース内に格納して、前記少なくとも１つのフィールドのデータを含むファイルは前記データベースか前記ファイルシステムのアプリケーションプログラミングインタフェースかによってアクセス可能である、データベースと、
    前記プロセッサ上実行する、前記データベースおよび前記ファイルシステムの両方にプログラムに基づいてインタフェースにより連結されるコンポーネントであって、
    アプリケーションから前記ファイルシステムのアプリケーションプログラミングインタフェースへの呼び出しを受信して、前記ファイルを開くことであって、前記ファイルにおいて前記オブジェクトの少なくとも１つのフィールドのデータを格納して、前記呼び出しは前記データベース内のオブジェクトのフィールドの同一性により前記オブジェクトのフィールドを識別する、開くこと、
    前記データベースから前記アプリケーションが前記呼び出しにより識別されるオブジェクトのフィールドのデータにアクセスする許可を有するかどうかを判定すること、および、
    前記アプリケーションが前記呼び出しにより識別されるオブジェクトのフィールドのデータにアクセスする許可を有する場合のみ前記ファイルシステムのアプリケーションプログラミングインタフェースを呼び出して前記ファイルを開くこと
    を処理する、コンポーネントと
    を備えたことを特徴とするコンピュータシステム。
16. 前記ファイルシステムのアプリケーションプログラミングインタフェースを呼び出して前記ファイルを開くより前に、前記コンポーネントは、前記データベース内のオブジェクトのフィールドの同一性に基づいて、前記オブジェクトのフィールドのデータを含むファイルに対する前記コンピュータシステムのファイルシステム内のパスを取得することを特徴とする請求項１５に記載のコンピュータシステム。
17. 前記コンポーネントは、
    前記アプリケーションから前記ファイルシステムのアプリケーションプログラミングインタフェースへの呼び出しを受信して、前記ファイルを閉じることであって、前記ファイルにおいて前記オブジェクトの少なくとも１つのフィールドのデータを格納する、閉じること、
    前記データベースに前記ファイルを閉じる呼び出しが受信されたことを知らせること、および、
    前記ファイルシステムのアプリケーションプログラミングインタフェースを呼び出して前記ファイルを閉じること
    をさらに処理することを特徴とする請求項１５に記載のコンピュータシステム。
18. 前記コンピュータシステムのファイルシステムはＮＴＦＳファイルシステムを含み、前記ファイルシステムのアプリケーションプログラミングインタフェースはＷｉｎ３２アプリケーションプログラミングインタフェースを含むことを特徴とする請求項１５に記載のコンピュータシステム。
19. 前記オブジェクトのユーザ定義型は、マネージドコードにおけるクラスとして定義されることを特徴とする請求項１５に記載のコンピュータシステム。

Images