JP2007522559A - データベースシステムにおけるラージオブジェクトインフラストラクチャのためのシステムおよび方法 - Google Patents

Abstract

ラージオブジェクトを取り扱いやすくする。大きな値の内部表現であるＢｌｏｂハンドル（大規模なデータへの不変のステートレス参照、ＢＨ）を利用する。ＢＨの構造は、対応する大きなデータブロックへのアクセスを提供するためのＩＬｏｃｋＢｙｔｅｓインターフェースを返すのに十分な情報を含み、また、ＢＨは、それ自体の存続時間記述に関する情報も返す。

Description

本発明は、一般に、データベースシステムの分野に関し、より詳細には、大規模なユーザ定義型、ならびにＸＭＬなど他の新しいデータ型をサポートするために、ラージオブジェクトデータ型（ｔｅｘｔ、ｎｔｅｘｔ、およびｉｍａｇｅ）の再実装に使用され得るラージオブジェクトインフラストラクチャを提供するシステムおよび方法に関する。

ＭｉｃｒｏｓｏｆｔのＳＱＬ Ｓｅｒｖｅｒ（ＳＱＬサーバ登録商標）の以前にリリースされたバージョンを含む、データベース格納プラットフォームでは、小さな値のオブジェクトは、関与するオーバーヘッドをあまり気にせずにコピーされる。というのは、そのようなオーバーヘッドコストが比較的わずかだからである。しかしながら、大きな値のオブジェクトでは、そのオーバーヘッドコストははるかに大きく、全体の性能にマイナスの影響を及ぼし得る。

これまでは、小規模なデータオブジェクトに最適なｖａｒｃｈａｒ型、ｎｖａｒｃｈａｒ型、およびｖａｒｂｉｎａｒｙ型には大きすぎる値での、これらのデータ型のサイズ限界を克服するために、大規模オブジェクトは、ラージオブジェクト（ＬＯＢ）データ型、すなわち、ｔｅｘｔ型、ｎｔｅｘｔ型およびｉｍａｇｅ型を用いて格納されている。

しかしながら、ラージオブジェクトを用いたプログラミングモデルで許容されているものには多くの制限があり、そのインフラストラクチャは、誤りを犯しやすいラージオブジェクトの実装をもたらした。例えば、大部分のストリング関数および演算子は、ＬＯＢには許容されず、特に、挿入および削除に関するテキストポインタ関数に伴う不備もある。（テキストポインタは、ＳＱＬ Ｓｅｒｖｅｒの初期リリースで行ロケータとして使用される物理参照である）。さらに、一度にＬＯＢの１つまたは複数の行を変更する効率的な手段がなく、いかなる種類のＬＯＢ変数のサポートも、ＬＯＢのためのコピー関数もない。上記その他の制限の結果として、ＬＯＢは、他のデータ型とはかなり異なり、したがって、より使いにくいものになっている。

求められているのは、ユーザ／プログラマが、より小さな値が処理されるのと同様に大きな値（データブロック）を処理することができ、それによって、小さな値と大きな値の処理でのユーザに知覚される差異を除去して、単一の包括的プログラミングモデルを提供するラージオブジェクトインフラストラクチャである。

本発明の様々な実施形態は、ｔｅｘｔデータ型、ｎｔｅｘｔデータ型、およびｉｍａｇｅデータ型の、新規のｖａｒｃｈａｒ（ＭＡＸ）、ｎｖａｒｃｈａｒ（ＭＡＸ）、ｖａｒｂｉｎａｒｙ（ＭＡＸ）、およびＸＭＬデータ型としての再実装に使用されると共に、大規模なユーザ定義型（ＵＤＴ）をサポートすることもでき、さらに、その他の新規のデータ型およびプログラミングモデル構造のサポートも可能にするインフラストラクチャを提供するシステムおよび方法を対象とする。また、本発明のいくつかの実施形態は、ユーザ／プログラマが、より小さな値が処理されるのと同様に大きな値（データオブジェクト）を処理することができ、それによって、小さな値と大きな値の間の差異を除去して、単一の包括的プログラミングモデルを提供するデータ処理インフラストラクチャを提供することも対象とする。

これら様々な実施形態は、大きな値の内部表現であるＢｌｏｂハンドル（ＢＨ）を利用する。ＢＨは、大規模なデータへの不変のステートレス参照である。ＢＨの構造は、対応する大きなデータブロックへのアクセスを提供するためのＩＬｏｃｋＢｙｔｅｓインターフェースを返すのに十分な情報を含み、また、ＢＨは、それ自体の存続時間記述に関する情報も返すことができる。これらの概念および要素について、以下でより詳細に説明する。

前述の要約、ならびに以下の好ましい実施形態の詳細な説明は、添付の図面と併せて読めばよりよく理解される。本発明を説明するために、図面には、本発明の例示的構成が示されている。しかしながら、本発明は、開示の特定の方法および手段に限定されるものではない。

本発明の内容を、法定要件を満たすために具体性をもたせて説明する。しかしながら、説明自体は、本特許の範囲を限定するためのものではない。そうではなく、発明者は、特許請求される内容が、現在または将来の技術と併せて、異なるステップまたは本明細書で説明するステップと類似のステップの組み合わせを含む、他のやり方でも実施され得ることを企図している。さらに、本明細書では、用いられる方法の異なる諸要素を意味するのに「ステップ」という用語が使用され得るが、この用語は、個々のステップの順序が明示的に記述されない限り、本明細書で開示する様々なステップの間のどんな特定の順序を示唆するものとも解釈すべきではない。

コンピュータ環境
本発明の多数の実施形態は、コンピュータ上で実行され得る。図１および以下の説明は、本発明が実施され得る適当なコンピューティング環境の簡単な一般的説明を提供するためのものである。必要ではないが、本発明を、クライアントワークステーションやサーバなどのコンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的状況で説明する。一般に、プログラムモジュールには、個々のタスクを実行し、または個々の抽象データ型を実施する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などのプログラムモジュールが含まれる。さらに、本発明が、ハンドヘルド機器、マルチプロセッサシステム、マイクロプロセッサベースの、またはプログラム可能な家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなど、他のコンピュータシステム構成を用いても実施され得ることを、当分野の技術者は理解するであろう。本発明は、タスクが、通信ネットワークを介してリンクされたリモート処理装置によって実行される、分散コンピューティング環境でも実施され得る。分散コンピューティング環境では、プログラムモジュールは、ローカルとリモート両方の記憶装置に位置し得る。

図１に示すように、例示的汎用コンピューティングシステムは、処理装置２１、システムメモリ２２、およびシステムメモリを含む様々なシステムコンポーネントを処理装置２１に結合するシステムバス２３を含む、従来型のパーソナルコンピュータ２０などを含む。システムバス２３は、様々なバスアーキテクチャのいずれかを使用した、メモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含むいくつかの種類のバス構造のいずれかとすることができる。システムメモリは、読取り専用メモリ（ＲＯＭ）２４およびランダムアクセスメモリ（ＲＡＭ）２５を含む。基本入出力システム２６（ＢＩＯＳ）は、始動時などに、パーソナルコンピュータ２０内の諸要素間での情報転送を支援する基本ルーチンを含み、ＲＯＭ２４に格納される。パーソナルコンピュータ２０は、さらに、ハードディスク（図示せず）との間で読取りおよび書込みを行うハードディスクドライブ２７、取り外し可能磁気ディスク２９との間で読取りおよび書込みを行う磁気ディスクドライブ２８、ＣＤ−ＲＯＭなどの光媒体といった取り外し可能光ディスク３１との間で読取りおよび書込みを行う光ディスクドライブ３０を含み得る。ハードディスクドライブ２７、磁気ディスクドライブ２８、および光ディスクドライブ３０は、それぞれ、ハードディスクドライブインターフェース３２、磁気ディスクドライブインターフェース３３、および光ドライブインターフェース３４によってシステムバス２３に接続される。これらのドライブおよびそれに関連するコンピュータ可読媒体は、パーソナルコンピュータ２０に、コンピュータ可読命令、データ構造、プログラムモジュールおよびその他のデータの不揮発性記憶を提供する。本明細書で説明する例示的環境では、ハードディスク、取り外し可能磁気ディスク２９および取り外し可能光ディスク３１を用いるが、この例示的動作環境では、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイカートリッジ、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）といった、コンピュータによりアクセス可能なデータを格納し得る他の種類のコンピュータ可読媒体も使用され得ることが、当分野の技術者には理解されるはずである。

ハードディスク、磁気ディスク２９、光ディスク３１、ＲＯＭ２４またはＲＡＭ２５上には、オペレーティングシステム３５、１つまたは複数のアプリケーションプログラム３６、その他のプログラムモジュール３７およびプログラムデータ３８を含むいくつかのプログラムモジュールが格納され得る。ユーザは、キーボード４０やポインティングデバイス４２などの入力装置を介してパーソナルコンピュータ２０にコマンドおよび情報を入力することができる。他の入力装置（図示せず）には、マイクロホン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどが含まれ得る。上記その他の入力装置は、しばしば、システムバスに結合されたシリアルポートインターフェース４６を介して処理装置２１に接続されるが、パラレルポート、ゲームポート、あるいはユニバーサルシリアルバス（ＵＳＢ）といった他のインターフェースによっても接続され得る。モニタ４７または他の種類の表示装置も、ビデオアダプタ４８などのインターフェースを介してシステムバス２３に接続され得る。モニタ４７以外に、パーソナルコンピュータは、通常、スピーカやプリンタなど、他の周辺出力装置（図示せず）も含む。図１の例示的システムは、ホストアダプタ５５、小型コンピュータシステムインターフェイス（ＳＣＳＩ）バス５６、およびＳＣＳＩバス５６に接続された外部記憶装置６２も含む。

パーソナルコンピュータ２０は、リモートコンピュータ４９など、１つまたは複数のリモートコンピュータへの論理接続を使用してネットワークで接続された環境で動作し得る。リモートコンピュータ４９は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスなど一般のネットワークノードとすることができ、図１には記憶装置５０だけしか示していないが、通常は、パーソナルコンピュータ２０に関連して前述した諸要素の多くまたはすべてを含む。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）５１および広域ネットワーク（ＷＡＮ）５２を含む。そのようなネットワーク環境は、オフィス、企業規模のコンピュータネットワーク、イントラネットおよびインターネットでよく見られる。

ＬＡＮネットワーク環境で使用される場合、パーソナルコンピュータ２０はネットワークインターフェースまたはアダプタ５３を介してＬＡＮ５１に接続される。ＷＡＮネットワーク環境で使用される場合、パーソナルコンピュータ２０は、通常、モデム５４、またはインターネットなどの広域ネットワーク５２を介して通信を確立する他の手段を含む。モデム５４は、内蔵でも外付けでもよく、シリアルポートインターフェース４６を介してシステムバス２３に接続される。ネットワーク化環境では、パーソナルコンピュータ２０に関連して示すプログラムモジュール、またはその一部は、リモート記憶装置にも格納され得る。図示のネットワーク接続は例示的なものであり、コンピュータ間で通信リンクを確立する他の手段も使用され得ることが理解されるであろう。さらに、本発明の多数の実施形態は、特に、コンピュータ化されたシステムに適すると想定されるが、本明細書中のどんな記述も、本発明をそのような実施形態に限定することを意図するものではない。

ネットワーク環境
図２に、本発明が用いられ得る例示的ネットワーク環境を示す。当然ながら、実際のネットワークおよびデータベース環境は、様々な構成として配置され得る。しかしながら、図示の例示的環境は、本発明が動作する環境の種類を理解するための枠組みを提供するものである。

ネットワークは、クライアントコンピュータ２０ａ、サーバコンピュータ２０ｂ、データソースコンピュータ２０ｃ、およびデータベース７０、７２ａ、７２ｂを含み得る。クライアントコンピュータ２０ａおよびデータソースコンピュータ２０ｃは、イントラネットなどの通信ネットワーク８０を介してサーバコンピュータ２０ｂと電子通信を行う。クライアントコンピュータ２０ａおよびデータソースコンピュータ２０ｃは、通信インターフェース８２によって通信ネットワークに接続される。通信インターフェース８２は、イーサネット（登録商標）接続、モデム接続など公知の通信インターフェースのいずれか１つとすることができる。

サーバコンピュータ２０ｂは、以下でより詳細に説明する、データベースサーバシステムソフトウェアによってデータベース７０の管理を実現する。したがって、サーバ２０ｂは、様々なデータソースからのデータの貯蔵庫として働き、そのデータを様々なデータ消費者に提供する。

図２の例では、データソースは、データソースコンピュータ２０ｃによって提供される。データソースコンピュータ２０ｃは、ＬＡＮ、ＷＡＮ、イントラネット、インターネットなどとすることのできる通信ネットワーク８０を介して、サーバコンピュータ２０ｂにデータを伝える。データソースコンピュータ２０ｃは、リレーショナルデータベースサーバ、エクセルスプレッドシート、ファイルなどとすることのできるデータベース７２ａ、７２ｂに、ローカルでデータを格納する。例えば、データベース７２ａには、表１５０、１５２、１５４に格納されたデータが示されている。データソース２０ｃによって提供されるデータは、結合され、サーバ２０ｂによって維持されるデータウェアハウスなどの大規模データベースに格納される。

サーバコンピュータ２０ｂによって格納されたデータを使おうとするクライアントコンピュータ２０ａは、通信ネットワーク８０を介してデータベース７０にアクセスすることができる。クライアントコンピュータ２０ａは、データベース７０に格納されたデータ上でのＳＱＬ問い合わせ（更新、挿入、削除など）によってデータを要求する。

ＢＬＯＢハンドル
本発明の様々な実施形態は、ＢＬＯＢハンドル（ＢＨ）を対象とする。ＢＨ（およびそのインターフェース、ＩＢｌｏｂＨａｎｄｌｅ）は、ラージオブジェクト（ＬＯＢ）（以後「データブロック」という）への不変のステートレス参照の内部表現である。ＢＨを使用すれば、（バイナリラージオブジェクトである、ＢＬＯＢを含む）システム中のＬＯＢのすべてのインスタンスが単一の表現に統合され得る。本質的には、ＢＨは、データブロックを位置指定する参照であり、その場合ＢＨはそのデータブロックを完全に記述する。ＢＨ自体は、（ａ）ＢＨデータの先頭を指し示すポインタおよび（ｂ）そのＢＨのバイト長を用いて記述され得る。

例えばＣ＋＋では、ＢＨは、通常のＣ＋＋オブジェクトのように、バッファの先頭を指し示すポインタを使用してメソッド呼び出しをサポートする。ＢＨの構造は、対応するデータブロックへのアクセスを提供するためのＩＬｏｃｋＢｙｔｅｓインターフェースを返すのに十分な情報を含み、いくつかのＢＨは、関連する記憶を破棄する「削除」メソッドをサポートし得る。ＢＨは、それら自体の存続時間記述に関する情報を返すこともできる。さらに、小さな値では、ＢＨは、それ自体の内にその値を含むことができ、そのため、ＩＬｏｃｋＢｙｔｅｓインターフェースの検索および別のデータブロックから読み取るための仮想メソッド呼び出しをバイパスすることができる。

図３Ａは、本発明の様々な実施形態におけるＢＨの一般的なコンポーネントを示すブロック図である。ＢＨ３００は、（ａ）メモリまたはディスク記憶（「記憶」）３１０のどこかに格納された対応するデータブロック３１２の開始位置を指し示すポインタ３０４でのオフセット、および（ｂ）記憶３１０中のデータブロック３１２のサイズに対応する長さ３０６を備える。ＢＨは、さらに、単一ビットの存続時間記述（図示せず）も備える。

図３Ｂは、図３Ａと同じであるが、前記ＢＨ３００のオフセット３０２が、外部で参照されるＬＯＢを指し示すのではなく、前記ＢＨ３１０内に完全に含まれるより小さな値３２０を指し示す（３０４）ＢＨを示すブロック図である。

ＢＨインフラストラクチャ
ＢＨインフラストラクチャでは、大きな値のパラメータは、（データブロックのコピーではなく）ＢＨのコピーを使用して、要求に応じてコピーを入力パラメータとして提供することによって処理される。このコピーされたＢＨは、ＢＨインフラストラクチャによって提供されるＢＨ別名割り当て機構を使用することにより、ポインタ参照として渡される。しかしながら、そのＢＨの１つのコピーのためにデータブロックへの変更が必要とされる場合、その大きな値はコピーされ、書き込み側ＢＨはこの新しいコピーだけを指し示す。ゆえに、このコピーの機能は、必然的に、出力パラメータで一般に行われるはずである。

図４Ａは、データブロック４１２を指し示す（４０４）元のＢＨ４０２、およびデータブロック４１２の仮想コピー４１２’を表すが、実際には、同じデータブロック４１２を指し示す（４０４’）第２のＢＨ４０２’の作成を示すブロック図である。しかしながら、図４Ｂに示すように、第２のＢＨ４０２’によって表される「コピー」中のデータ（または、反対に、ＢＨ４０２によって表されるデータ）が書込み操作によって変更される場合、データブロック４１２は、実際に新しいデータブロック４１２”にコピーされ、第２のＢＨ４０２’は、この第２のデータブロック４１２”を指し示す（４０４）ことになる。

しかしながら、様々な実施形態では、ＢＨインフラストラクチャは、そのデータブロック全部をコピーする必要の一部を除外するために、データブロックへの「部分更新」、すなわち、全データ値の完全コピーを招くことなく大きな値の一部だけを変更する能力もサポートすることができる。動作に際して、部分更新は、（ａ）データブロックの「チャンク」（前記データブロックの下位区分であるチャンク）に対応する置換値、（ｂ）データブロック中のチャンクの先頭での「オフセット」、および（ｃ）置換されるチャンクのバイト長（置換値のバイト長にも対応する）を確認する。論理的には、この手法は、単に、（対象となるチャンクの境界を本質的に定義する）データブロックのオフセット位置におけるバイト長バイト数を、同一のバイト長を有する前述の置換値で置き換えるだけである。代替の実施形態では、置換値は、置換されるチャンクと同じバイト長である必要はなく、当分野の技術者に知られ、理解されている様々な方法（ポインタベースの方法など）を用いて、より小さな、またはより大きな値がチャンクに入れられ得る。さらに、それらの技法のいずれも、前述の、図４Ａおよび図４Ｂに示す仮想コピー概念と共に使用され得る。

内部では、部分更新は、（他の部分更新または通常更新と一緒にすることのできる）列更新の特殊な形として表され、可能な場合、その変更は、ディスク記憶にプッシュされて、必要とされるＢツリーの特定の部分だけを変更する。しかしながら、場合によっては、システムが、効率性または堅固性のために部分更新を完全コピーとして実施しようとすることもあり、更新が部分的に実行されず、完全置換が実行されることもある。システムは、例えば、パーティションキーやクラスタリングキーへの更新など、データ列の異なる物理的場所への移動を必要とする更新が存在する場合には、部分更新を完全コピーとして実施する（すなわち、古い値を新しい値で置換する）。この理由は、列の異なる場所への移動が完全コピーを必要とし、その操作を１段階で完了する方がより効率的だからである。また、前述の場合、システムは、部分更新を含むステートメントを実行不能な更新として拒絶せず、完全コピーを実施しようとすることにも留意すべきである。

部分更新インフラストラクチャは、「ハロウィーン保護」も考慮に入れる（すなわち、ＵＰＤＡＴＥで引数として使用される値自体も更新される場合）。

この部分更新インフラストラクチャは、以前のテキストポインタベースの技術に優る大きな前進を表すものである。部分更新が問い合わせプロセッサ（ＱＰ）にとって既知の操作であると仮定すると、それだけに限らないが、索引および索引付きビュー保守、パーティション、レプリケーション、制約条件検証を含む、テキストポインタ実装では制限されていたいくつかの機能が使用可能になる。

本発明のいくつかの実施形態でのＢＨインフラストラクチャの一部として、その基礎となる格納インフラストラクチャは、列行内限界の概念も持つことになる。この限界は、そこで、所与の値が、主ページ中に保持されるのではなく、行外にプッシュされるよう選択されるサイズ境界を決定する。行内限界が小さいほど、列がより早く行外にプッシュされ、より大きい限界は逆の影響を有する。当分野の技術者には知られ、理解されているように、これは、限界が小さければ、１ページ当たりにより多数の行を入れることが可能になり、さらには行密度が増大し、走査性能が向上するが、大きな値の列はその走査の一部とはならないというトレードオフを反映するものである。これに関して、ＢＨインフラストラクチャは、型ごとの内部で構成可能な行内限界を可能にする。ゆえに、ＭＡＸ Ｖ型は、特定の行内限界に基づいて所与の挙動を公開することができ、他方ＵＤＴ型またはＸＭＬ型は、異なる限界を選択し、そのサイズおよび構造により適した異なる密度および走査性能特性を達成することができる。

ＢＨメソッドおよびＡＰＩ
本発明の様々な実施形態では、ＢＨは、後段でより詳細に説明する以下のメソッドの１つまたは複数をサポートすることができる。

ＢＨ構造の典型的な実装は、いくつかのインスタンスで付加される任意選択のデータと共にＩＢｌｏｂＨａｎｄｌｅインターフェースから継承される。ＢＨは自己完結型であり、それ自体への組み込みポインタを持たないため、それが存在するメモリに関する仮定は必要とされない。したがって、ＢＨをコピーするには、単なるシャローコピーだけしか必要とされない。これは、システムが、通常の列が扱われるのと同様にＢＨを扱うことを可能にする。

ＢＨは、対応するデータブロックを位置指定するのに使用され得るが、そのデータブロックのＬＯＢを操作するためのインターフェースは提供しない。その代わり、いくつかの実施形態では、ＰｉｌｂＧｅｔＩＬｏｃｋＢｙｔｅｓメソッドを用いて、データ操作のためにＩＬｏｃｋＢｙｔｅｓＳＳが検索される。サポートされる正確なＩＬｏｃｋＢｙｔｅｓＳＳメソッドのセットは、ＢＨ実装で異なるが、通常は、次の２つのカテゴリに分類される。すなわち（ｉ）ユーザ表からのデータを表し、（部分更新での場合を除いて）通常は読取り専用であるＢＨなど、読取り操作だけをサポートする読取り専用ＬＯＢ、および（ｉｉ）一時ＬＯＢ値を格納するのに使用される一時ＢＨなど、データブロックの読取りとその更新の両方をサポートする読取り／書込みＬＯＢである。

いくつかの実施形態では、そのＢＨに関連付けられたＬＯＢ値を削除するためにＢＨでの削除メソッドが呼び出され得る。しかしながら、いくつかのＢＨだけ（一時ＢＨなど）はこの操作をサポートするが、他のＢＨ（ユーザ表からのＢＨなど）はサポートしない。いずれにしても、削除操作は失敗しないはずであり、それは、処理クリーンアップが、自動デストラクタが失敗しないことを保証するのに役立つ。

いくつかの実施形態でのＢＨは、ＩＬｏｃｋＢｙｔｅｓＳＳの代替として、ＬＯＢデータブロックを指し示すポインタおよびその長さを返すのに使用され得るＦＧｅｔＰｏｉｎｔｅｒメソッドもサポートし、それによって小さな読取り専用データにアクセスするより高速な手段を提供する。しかしながら、データブロックが小さな読取り専用データから構成されない場合、このメソッドは、代わりにＰｉｌｂＧｅｔＩＬｏｃｋＢｙｔｅｓメソッドを使用してデータにアクセスすべきことを示すＦＡＬＳＥを返すことができる。

様々な実施形態で、Ｄｅｌｅｔｅを除くＢＨ ＡＰＩメソッドは、例外をスローすることができる。

ＢＨ特性
いくつかの実施形態では、ｐｂｈｐＧｅｔメソッドは、ＢＨ特性のカプセル化であるＣＢｌｏｂＨａｎｄｌｅＰｒｏｐｅｒｔｉｅｓを返す。通常、多くのＢＨは、共通の特性を共用し、ポインタ（ＣＢｌｏｂＨａｎｄｌｅＰｒｏｐｅｒｔｉｅｓ＊）による特性の比較を使用して、ＢＨの「フレーバ」（例えばＢＨがユーザ表中のデータを指し示すか、それとも「カスタム」データブロックを指し示すかなど、ＢＨフレーバについては後段でより詳細に論じる）が区別される。

いくつかの実施形態では、ＢＨ参照が有効である時間の長さに「存続時間」特性を利用する。例えば、ＢＨは、ある種のイベントの後では、既存のＬＯＢ値と関連付けられなくなることがある。いくつかの実施形態では、この特性には、単に、２つの値のうちの１つ、すなわち「問い合わせ存続時間」または「行存続時間」（あるいは他の２値等価の指定）が割り当てられ得る。「行存続時間」は、問い合わせ実行（ＱＥ）反復子が現在の行を処理している間だけ関連するＬＯＢ値にアクセスすることができ、反復子が次の行に進むと、そのＢＨはそのＬＯＢ値に関連付けられなくなる（ゆえに、そのＢＨによるそれ以上のアクセスは禁止される）ことを示す。他方、「問い合わせ存続時間」は、その問い合わせの終わりまで（あるいは、他の問い合わせ以外の場合には、「ＢＨファクトリ」がパージまたはシャットダウンされるまで、ＢＨファクトリについては本明細書の他の箇所でより詳細に論じる）ＬＯＢ値が有効であることを示すはずである。

ＢＨフレーバ
本発明のいくつかの実施形態は、ＢＨの１つまたは複数の「フレーバ」を備え、前記フレーバは、以下のＢＨ実装バリエーションを備える。
ユーザ表中のデータブロックを指し示す（通常は「問い合わせ存続時間」を持つはずの）「表」ＢＨ。
一時利用のためにＢＨファクトリ（本明細書の別の箇所で論じる）を用いて作成される「一時」ＢＨ。
十分に小さなデータブロックでの、そのデータブロック全体をそのＢＨ本体内に含む「インライン化」ＢＨ。このフレーバでは、ＩＬｏｃｋＢｙｔｅｓＳＳインターフェースもそのＢＨ本体内にあり、そのため、ＰｉｌｂＧｅｔＩＬｏｃｋＢｙｔｅｓメソッドが非常に高速で、効率的になる。
別のＢＨへのメソッド呼び出しを宛先変更する「別名」ＢＨ、ＴＥＭＰＢＬＯＢΗＡＮＤＬＥ＿ＳＩＺＥ（事前定義されたサイズ限界）より大きいＢＨをＴＥＭＰＢＬＯＢΗＡＮＤＬＥ＿ＳＩＺＥ以下のＢＨに変換する（以下でより詳細に説明する）など、特定の操作に特に有用である。
既存のＩＬｏｃｋＢｙｔｅｓＳＳオブジェクトへのアクセスを宛先変更する「ラッパ」ＢＨ。これは、既存のＩＬｏｃｋＢｙｔｅｓオブジェクトを別のソースから（例えばＯＬＥＤＢから）ＢＨに「キャスト」するのに使用される場合、特に有用である。
指定されたファイルグループに属し、後でユーザ表にリンクされ得る「オーファン」ＢＨ。動作に際して、大きな値がシステムに流される場合、その大きな値をオーファンＢＨに直接コピーすることができ、データが完全に流された後、そのＢＨは、それ以上のコピーを必要とせずに、そこに挿入される（「利用される」）表の一部とされる。ゆえに、この種のＢＨは、コピー回数を最小にすると共に、ＢＵＬＫ ＩＮＳＥＲＴステートメントなどの高性能バルク操作の性能を向上させるのに使用される。

ＢＨ最大サイズ
いくつかの実施形態では、ＢＨを含むために最大バッファサイズに関する仮定が必要とされる。これらの実施形態では、ＱＥは、通常、問い合わせオプティマイザ（ＱＯ）によって導出される最大サイズを使用するはずであるが、最大ＢＨサイズそのものも、例えばｃｏｎｓｔ ＢＬＯＢＨＡＮＤＬＥ＿ＳＩＺＥ＝８０００などの定数として定義され得る。しかしながら、「一時」ＢＨは、プロセッサアーキテクチャに基づく限界を持つことがあり、例えば３２ビットアーキテクチャでは、ｃｏｎｓｔ ＴＥＭＰＢＬＯＢΗＡＮＤＬＥ＿ＳＩＺＥ＝０×４０などと定義される。この手法の背後にある主な考え方は、大部分のコンポーネントは、参照によって（それ自体のバッファを割り振らずに）ＢＨにアクセスし、または一時ＢＨを使用してデータブロックの大きな値をスプールするはずであるというものである。したがって、ＢＨが持続されることになる場合には、小さなバッファ（すなわち、サイズがＴＥＭＰＢＬＯＢΗＡＮＤＬＥ＿ＳＩＺＥの）を割り振ることが望ましいと考えられる。他方、ＱＥは、通常、はるかに大規模なＢＨを使用する。しかしながら、ここで重要な考慮事項は、ほとんどどんなコンポーネントもＴＥＭＰＢＬＯＢＨＡＮＤＬＥ＿ＳＩＺＥサイズのＢＨを処理することができるが、ＢＨがこの値より大きく、問い合わせ実行の外部のコンポーネントから見える場合、それは、それに関連付けられたポインタによってのみアクセスされなければならないということである。例えば、ＱＥが言語処理実行コンポーネント（ＬＰＥ）に大規模なＢＨを公開する場合、このＬＰＥは、通常、その大規模ＢＨをそれ自体のバッファにコピーすることができず、ゆえに、ＱＥバッファを指し示すポインタを使用しなければならない。

ＢＨファクトリ
ＢＨファクトリ（ＢＨＦ）は新しいＢＨを作成するオブジェクトである。一般に、すべてのＢＦファクトリによってサポートされる共通インターフェースはないことがあるが、一時データブロックを用いて１つまたは多数のコンポーネントによる処理での大規模データを格納するための「一時ＢＨファクトリ」（ＴＢＨＦ）によってサポートされる共通インターフェースはある。後者の場合、連続処理のために１つのコンポーネントから別のコンポーネントにＩＢｌｏｂＨａｎｄｌｅＦａｃｔｏｒｙポインタが渡され、ＴＢＨＦは、より小さい値（８Ｋ未満など）を表すデータブロックの処理を（前述のように）より効率よくする最適化を備える。また、（以下でより詳細に説明する）複数のスレッドからの並列アクセスをサポートする特殊なＢＨＦもある。

以下のメソッドは、ＴＢＨＦを用いてＢＨを作成する。

いくつかの実施形態では、このメソッドは、「空の」ＬＯＢ値に関連付けられた新しいＢＨを作成する。その場合、ＩＬｏｃｋＢｙｔｅｓＳＳを用いてこのＢＨにデータを書き込むことができ、このＢＨを閉じ、解放する他のメソッド（ＩＬｏｃｋＢｙｔｅｓＳＳ：：ＣｌｏｓｅおよびＩＬｏｃｋＢｙｔｅｓＳＳ：：Ｒｅｌｅａｓｅ）も使用され得る。

一般に、ＢＨＦは複数のスレッドにサービスすることができるが、そのＢＨＦを作成する特定のスレッドは、その個々のＢＨＦを所有し、その時刻に達した場合にそのＢＨＦをクリーンアップすることのできる唯一のスレッドである。ＢＨＦは、グループとして作成されるメンバＢＨに所与のグループ識別番号をタグ付けすることによって、ＢＨをグループとして作成することもできる。これは、そのＢＨＦが、単一の操作で、所与のグループに関連付けられたすべてのＢＨを解放するサービスを提供することを可能にする。

そのＢＨＦに応じて、ＢＨによって作成されるＢＨは、ディスクによって補助されることも、メモリによって補助されることもある。最初は（好ましくは）、ＢＨＦは、それに関連付けられた特定のディスク記憶を持たないが、一般に、記憶は、最初の使用時に要求に応じて、または明示的な要求によって作成される。これに関して、本発明の様々な実施形態は、それだけに限らないが、以下を含む１つまたは複数の種類のＢＨＦを利用する。
高速ＢＨＦ：これらのＢＨＦは、永続的ディスク記憶ではなくメモリバッキングを使用して小さい値をサポートするインメモリのみのＢＨを作成する。一般に、ＢＨインフラストラクチャは、可能な場合には高速ＢＨＦを使おうとするが、必要に応じて、より低速なディスク補助記憶に後退するはずである。
ディスク補助ＢＨＦ：これらのＢＨＦは、ディスク記憶によって補助されるＢＨを作成し、値を（ディスクスペースが許容する）随意の大きさに保つことができるＢＨを作成する。

ＭＡＸ指定子およびＭＡＸ Ｖ型
ＢＨを使用して、本発明の様々な実施形態は、ｖａｒｃｈａｒ、ｎｖａｒｃｈａｒ、ｖａｒｂｉｎａｒｙデータ型（以後まとめて「Ｖ型」という）でのＭＡＸ指定子の使用も対象とする。例えば、表列およびＴＳＱＬ変数は、定義／宣言時にｖａｒｃｈａｒ（ＭＡＸ）、ｎｖａｒｃｈａｒ（ＭＡＸ）、またはｖａｒｂｉｎａｒｙ（ＭＡＸ）（以後まとめて「ＭＡＸ Ｖ型」という）を指定することができる。動作に際して、ＭＡＸ Ｖ型列および変数は、「ＭＡＸ」キーワードをその型のサイズの指定子として使用し、そのような値は、システムによりサポート可能なサイズ（例えば、ｖａｒｃｈａｒ（ΜＡΧ）！＝ｖａｒｃｈａｒ（＜有効な数＞））に基づいて定義されるはずであるが、宣言時にｖａｒｃｈａｒまたはｖａｒｂｉｎａｒｙの最大サイズを指定するのに使用され得る最大リテラルは引き続き８０００であり、ｎｖａｒｃｈａｒでは４０００である。（通常、ｖａｒｃｈａｒまたはｖａｒｂｉｎａｒｙ列は８０００の最大サイズを持つが、ＭＡＸキーワードは、ＢＨインフラストラクチャを用いて、その最大サイズがシステムによりサポート可能な最高と同等である列を適させる。）

その場合、様々な代替実施形態において、以下の操作および機能の１つまたは複数がＭＡＸ Ｖ型のためにサポートされるはずである。比較；ＴＳＱＬ変数；連結；いくつかのストリング関数；ＤＩＳＴＩＮＣＴ、ＯＲＤＥＲ ＢＹ、ＧＲＯＵＰ ＢＹ、集約、結合、副照会などを含む全ＳＥＬＥＣＴステートメントサポート；ＣＨＥＣＫ制約、ＲＵＬＥおよびＤＥＦＡＵＬＴ（その場合、８Ｋより大きいデフォルトは、今日、ＬＯＢと共に発生する際に非表示で打ち切られなくなった）；索引付きビュー定義の一部であること；ＡＦＴＥＲトリガ時の挿入／削除された表での可視性；および、特に、ＦＦＯカーソル、ＦＥＴＣＨ．．．ＩＮＴＯ．．．＠ｖａｒｉａｂｌｅ、ＳＥＴ ＡＮＳＩ＿ＰＡＤＤＩＮＧ、ＳＥＴ ＣＯＮＣＡＴ＿ＮＵＬＬ＿ＹＩＥＬＤＳ＿ＮＵＬＬ、全文検索、および（ｓｐ＿ａｄｄｔｙｐｅを置換する）ＣＲＥＡＴＥ ＴＹＰＥで許容されるデータ型変換。しかしながら、現実の実質的なサイズの違いのために、本発明のいくつかの実施形態では、それだけに限らないが、ｓｑｌ＿ｖａｒｉａｎｔが依然としてＭＡＸ Ｖ型を含み得ないこと、ＭＡＸ Ｖ型列が（それらを索引サブキーとして使用することは許されるが）索引中でキー列として指定され得ないこと、ＭＡＸ Ｖ型列がパーティションキー列として使用され得ないことを含め、ＭＡＸ Ｖ型とＶ型の間の微妙な違いが存在し続けるはずである。ただし、列の接頭部を索引または索引付きビューのキーとして指定することは許される。これにより、システムに、ＭＡＸ Ｖ型列が関与する特定の種類の述部を修飾する行を迅速に検索するためにその索引を自動的に考慮させることができる。例えば、［Ｖａｒｃｈａｒ（ＭＡＸ）ｃｏｌｕｍｎ］＝Ｖａｌｕｅという形の述部は、システムによって自動的にＰｒｅｆｉｘ（［Ｖａｒｃｈａｒ（ＭＡＸ）ｃｏｌｕｍｎ］）＝Ｐｒｅｆｉｘ（Ｖａｌｕｅ）ＡＮＤ［Ｖａｒｃｈａｒ（ＭＡＸ）ｃｏｌｕｍｎ］＝Ｖａｌｕｅに分割され得る。その列の接頭部上の示唆される述部は、その索引の利用を可能にする。

後方互換性を保証するために、ＭＡＸ Ｖ型をサポートしないクライアントにダウンレベルでデータを送る場合には、ｖａｒｃｈａｒ（ＭＡΧ）データ型、ｎｖａｒｃｈａｒ（ＭＡＸ）データ型、ｖａｒｂｉｎａｒｙ（ＭＡＸ）データ型は、それぞれ、ＬＯＢ型のｔｅｘｔ型、ｎｔｅｘｔ型、ｉｍａｇｅ型として送られるはずである。それとは逆に、ＬＯＢ型のｔｅｘｔデータ、ｎｔｅｘｔデータ、ｉｍａｇｅデータの形でクライアントからアップレベルで受け取るデータの移行サポートは、それぞれ、ｖａｒｃｈａｒ（ＭＡΧ）データ型、ｎｖａｒｃｈａｒ（ＭＡＸ）データ型、ｖａｒｂｉｎａｒｙ（ＭＡＸ）データ型に変換されるはずである。

結論
本明細書で説明した様々なシステム、方法および技法は、ハードウェアまたはソフトウェア、あるいは、適切な場合には、両者の組み合わせを用いて実施され得る。ゆえに、本発明の方法および装置、あるいはその特定の態様または部分は、フロッピー（登録商標）ディスケット、ＣＤ−ＲＯＭ、ハードドライブ、または他の任意の機械可読記憶媒体などの有形の媒体として実施されたプログラムコード（すなわち命令）の形をとることができ、そのプログラムコードが、コンピュータなどのマシンによってロードされ、実行されると、そのマシンは、本発明を実施する装置になる。プログラム可能コンピュータ上でのプログラムコード実行の場合、そのコンピュータは、一般に、プロセッサ、（揮発性および不揮発性のメモリおよび／または記憶素子を含む）プロセッサにより読取り可能な記憶媒体、少なくとも１つの入力装置、および少なくとも１つの出力装置を含む。コンピュータシステムとやりとりするために、１つまたは複数のプログラムが、好ましくは、高水準手続き型プログラミング言語またはオブジェクト指向プログラミング言語で実施される。しかしながら、プログラムは、必要に応じて、アセンブリ言語または機械語でも実施され得る。いずれの場合も、言語は、コンパイル済み言語または解釈済み言語とし、ハードウェア実装形態と組み合わせることができる。

本発明の方法および装置は、電気的配線またはケーブル、光ファイバ、あるいは他の任意の形の伝送によるものなど、何らかの伝送媒体を介して伝送されるプログラムコードの形としても実施することができ、プログラムコードが、ＥＰＲＯＭ、ゲートアレイ、プログラマブル論理回路（ＰＬＤ）、クライアントコンピュータ、ビデオレコーダなどといったマシンによって受け取られ、ロードされ、実行されると、そのマシンは、本発明を実施する装置になる。汎用プロセッサ上で実施されると、プログラムコードは、プロセッサと組み合わさって、本発明の索引付け機能を実行するように動作する独自の装置を提供する。

以上、本発明を、様々な図の好ましい実施形態との関連で説明したが、他の類似の実施形態を使用することもでき、本発明から逸脱することなく、本発明の同じ機能を実行するために、説明した実施形態に変更および追加を行うこともできることを理解すべきである。例えば、本発明の例示的実施形態は、パーソナルコンピュータの機能をエミュレートするデジタル装置の状況で説明されるが、本発明は、本出願で説明するようなデジタル装置だけに限定されるものではなく、有線であれ無線であれ、ゲームコンソール、ハンドヘルドコンピュータ、携帯用コンピュータなど、いくつもの既存の、または新規のコンピューティングデバイスまたは環境に適用可能であり、通信ネットワークを介して接続され、ネットワークを介して対話するいくつものそのようなコンピューティングデバイスに適用され得ることを、当分野の技術者は理解するであろう。さらに、特に、無線ネットワークで接続された機器の数が増大し続けているために、本明細書では、ハンドヘルド機器用オペレーティングシステムおよび他のアプリケーション固有のハードウェア／ソフトウェアインターフェースシステムを含む、様々なコンピュータプラットフォームが企図されていることを強調すべきである。したがって、本発明は、どんな単一の実施形態にも限定すべきではなく、添付の特許請求の範囲による広さと範囲で解釈すべきである。

最後に、本明細書で説明した開示の実施形態は、他のプロセッサアーキテクチャ、コンピュータベースシステム、あるいはシステム仮想化での使用のために適合させることができ、そのような実施形態が、本明細書で行われる開示によって明確に予期されており、ゆえに、本発明は、本明細書で説明した特定の実施形態に限定すべきではなく、最も広範に解釈すべきものである。

本発明の諸態様が組み込まれ得るコンピュータシステムを表すブロック図である。 本発明の諸態様が組み込まれ得るネットワークを表す概略図である。 本発明の様々な実施形態におけるＢＬＯＢハンドル（ＢＨ）の一般的なコンポーネントを示すブロック図である。 本発明の様々な実施形態による、値がそのＢＨ内に完全に含まれるＢＨを示すブロック図である。 読取り型操作での、両方が同じデータブロックを指し示す、元のＢＨと仮想コピーを表す第２のＢＨとを示すブロック図である。 どちらかのＢＨによって書込み操作が呼び出され、第２のＢＨがそのデータブロックの新しく作成されたコピーを指示させられる、図４ＡのＢＨを示すブロック図である。

Claims (30)

1. コンピュータシステムにおいて大規模データオブジェクトを処理する方法であって、前記大規模データオブジェクトがそれを用いて処理され得ないはずの小規模データオブジェクトに利用可能な関数、操作などを介して前記コンピュータシステムによって処理され得る、前記大規模データオブジェクトを表す処理構造を作成することを備えることを特徴とする方法。
2. 第１の大規模データオブジェクトを指し示す第１の処理構造は、前記同じ第１の大規模データオブジェクトを指し示す第２の処理構造の作成によって仮想的にコピーされ、ただし、前記第１の処理構造および前記第２の処理構造が前記第１の大規模データオブジェクトに変更を書き込まないことを条件とすることを特徴とする請求項１に記載の方法。
3. 前記第１の処理構造が前記第１の大規模データオブジェクトに変更を書き込まなければならない場合、前記第１の処理構造が前記第１の大規模データオブジェクトに前記変更を書き込むのに先立って、前記第１の大規模データオブジェクトは第２の大規模データオブジェクトにコピーされ、前記第２の処理構造は前記第２の大規模データオブジェクトを指示させられることを特徴とする請求項２に記載の方法。
4. 前記第２の処理構造が前記第１の大規模データオブジェクトに変更を書き込まなければならない場合、前記第１の大規模データオブジェクトは第２の大規模データオブジェクトにコピーされ、前記第２の処理構造は前記第２の大規模データオブジェクトを指示させられ、次いで、前記第２の処理構造は前記第２の大規模データオブジェクトに前記変更を書き込むことを特徴とする請求項２に記載の方法。
5. ｔｅｘｔデータ型、ｎｔｅｘｔデータ型、およびｉｍａｇｅデータ型（またはそれらの同等物）を備える型のグループの中からの１つの型を持つデータオブジェクトは、対応する処理構造を有する大規模データオブジェクトに変換されることを特徴とする請求項１に記載の方法。
6. ｔｅｘｔ型、ｎｔｅｘｔ型、またはｉｍａｇｅデータ型（または同等のデータ型）のデータオブジェクトは、それぞれ、ｖａｒｃｈａｒ（ＭＡＸ）型、ｎｖａｒｃｈａｒ（ＭＡＸ）型、またはｖａｒｂｉｎａｒｙ（ＭＡＸ）型（あるいは同等のデータ型）に変換され、ｖａｒｃｈａｒ（ＭＡＸ）型、ｎｖａｒｃｈａｒ（ＭＡＸ）型、およびｖａｒｂｉｎａｒｙ（ＭＡＸ）型は処理構造を備え、前記ＭＡＸは所定の最大サイズ値に対応することを特徴とする請求項５に記載の方法。
7. 前記処理構造は小さな値のデータオブジェクトに対応し、前記小さな値のデータオブジェクトは前記処理構造内に完全に格納されることを特徴とする請求項１に記載の方法。
8. 前記処理構造での削除操作をさらに備え、前記処理構造が第１の型のものである場合、前記処理構造と対応する大規模データオブジェクトは両方とも削除され、前記処理構造が第２の型ものである場合、前記処理構造だけが削除され、前記対応する大規模データオブジェクトは削除されないことを特徴とする請求項１に記載の方法。
9. 前記処理構造は存続時間を持ち、前記処理構造は、前記存続時間に対応する値を持つフィールドを備えることを特徴とする請求項１に記載の方法。
10. 前記処理構造は、処理構造の必要に応答して処理構造ファクトリによって作成されることを特徴とする請求項１に記載の方法。
11. コンピュータシステムにおいて大規模データオブジェクトを処理するシステムであって、前記大規模データオブジェクトがそれを用いて処理され得ないはずの小規模データオブジェクトに利用可能な関数、操作などを介して前記コンピュータシステムによって処理され得る、前記大規模データオブジェクトを表す処理構造を作成するサブシステムを備えることを特徴とするシステム。
12. 第１の大規模データオブジェクトを指し示す第１の処理構造は、前記同じ第１の大規模データオブジェクトを指し示す第２の処理構造の作成によって仮想的にコピーされ、ただし、前記第１の処理構造および前記第２の処理構造が前記第１の大規模データオブジェクトに変更を書き込まないことを条件とすることを特徴とする請求項１１に記載のシステム。
13. 前記第１の処理構造が前記第１の大規模データオブジェクトに変更を書き込まなければならない場合、前記第１の処理構造が前記第１の大規模データオブジェクトに前記変更を書き込むのに先立って、前記第１の大規模データオブジェクトは第２の大規模データオブジェクトにコピーされ、前記第２の処理構造は前記第２の大規模データオブジェクトを指示させられることを特徴とする請求項１２に記載のシステム。
14. 前記第２の処理構造が前記第１の大規模データオブジェクトに変更を書き込まなければならない場合、前記第１の大規模データオブジェクトは第２の大規模データオブジェクトにコピーされ、前記第２の処理構造は前記第２の大規模データオブジェクトを指示させられ、次いで、前記第２の処理構造は前記第２の大規模データオブジェクトに前記変更を書き込むことを特徴とする請求項１２に記載のシステム。
15. ｔｅｘｔデータ型、ｎｔｅｘｔデータ型、およびｉｍａｇｅデータ型（またはそれらの同等物）を備える型のグループの中からの１つの型を持つデータオブジェクトは、対応する処理構造を有する大規模データオブジェクトに変換されることを特徴とする請求項１１に記載のシステム。
16. ｔｅｘｔ型、ｎｔｅｘｔ型、またはｉｍａｇｅデータ型（または同等のデータ型）のデータオブジェクトは、それぞれ、ｖａｒｃｈａｒ（ＭＡＸ）型、ｎｖａｒｃｈａｒ（ＭＡＸ）型、またはｖａｒｂｉｎａｒｙ（ＭＡＸ）型（あるいは同等のデータ型）に変換され、ｖａｒｃｈａｒ（ＭＡＸ）型、ｎｖａｒｃｈａｒ（ＭＡＸ）型、およびｖａｒｂｉｎａｒｙ（ＭＡＸ）型は処理構造を備え、前記ＭＡＸは所定の最大サイズ値に対応することを特徴とする請求項１５に記載のシステム。
17. 前記処理構造は小さな値のデータオブジェクトに対応し、前記小さな値のデータオブジェクトは前記処理構造内に完全に格納されることを特徴とする請求項１１に記載のシステム。
18. 前記処理構造での削除操作をさらに備え、前記処理構造が第１の型のものである場合、前記処理構造と対応する大規模データオブジェクトは両方とも削除され、前記処理構造が第２の型ものである場合、前記処理構造だけが削除され、前記対応する大規模データオブジェクトは削除されないことを特徴とする請求項１１に記載のシステム。
19. 前記処理構造は存続時間を持ち、前記処理構造は、前記存続時間に対応する値を持つフィールドを備えることを特徴とする請求項１１に記載のシステム。
20. 前記処理構造は、処理構造の必要に応答して処理構造ファクトリによって作成されることを特徴とする請求項１１に記載のシステム。
21. コンピュータシステムにおいて大規模データオブジェクトを処理するコンピュータ可読命令を備えるコンピュータ可読媒体であって、前記コンピュータ可読命令は、前記大規模データオブジェクトを表す処理構造を作成する命令、および前記大規模データオブジェクトがそれを用いて処理され得ないはずの小規模データオブジェクトに利用可能な関数、操作およびそのような他の操作を用いて前記処理構造を処理する命令を備えることを特徴とするコンピュータ可読媒体。
22. 第１の大規模データオブジェクトを指し示す第１の処理構造を、前記同じ第１の大規模データオブジェクトを指し示す第２の処理構造の作成によって仮想的にコピーするための命令であって、前記第１の処理構造および前記第２の処理構造が前記第１の大規模データオブジェクトに変更を書き込まないことを条件とする命令をさらに備えることを特徴とする請求項１に記載のコンピュータ可読命令。
23. 前記第１の処理構造が前記第１の大規模データオブジェクトに変更を書き込まなければならない場合、前記第１の処理構造が前記第１の大規模データオブジェクトに前記変更を書き込むのに先立って、前記第１の大規模データオブジェクトを第２の大規模データオブジェクトにコピーし、前記第２の処理構造に前記第２の大規模データオブジェクトを指示させるための命令をさらに備えることを特徴とする請求項２に記載のコンピュータ可読命令。
24. 前記第２の処理構造が前記第１の大規模データオブジェクトに変更を書き込まなければならない場合、前記第１の大規模データオブジェクトを第２の大規模データオブジェクトにコピーし、前記第２の処理構造に前記第２の大規模データオブジェクトを指示させ、次いで、前記第２の処理構造が前記第２の大規模データオブジェクトに前記変更を書き込むための命令をさらに備えることを特徴とする請求項２に記載のコンピュータ可読命令。
25. ｔｅｘｔデータ型、ｎｔｅｘｔデータ型、およびｉｍａｇｅデータ型（またはそれらの同等物）を備える型のグループの中からの１つの型を持つデータオブジェクトを、対応する処理構造を有する大規模データオブジェクトに変換するための命令をさらに備えることを特徴とする請求項１に記載のコンピュータ可読命令。
26. ｔｅｘｔ型、ｎｔｅｘｔ型、またはｉｍａｇｅデータ型（または同等のデータ型）のデータオブジェクトを、それぞれ、ｖａｒｃｈａｒ（ＭＡＸ）型、ｎｖａｒｃｈａｒ（ＭＡＸ）型、またはｖａｒｂｉｎａｒｙ（ＭＡＸ）型（あるいは同等のデータ型）に変換するために命令であって、前記ｖａｒｃｈａｒ（ＭＡＸ）型、ｎｖａｒｃｈａｒ（ＭＡＸ）型、およびｖａｒｂｉｎａｒｙ（ＭＡＸ）型は処理構造を備え、ＭＡＸ値は所定の最大サイズ値に対応する命令をさらに備えることを特徴とする請求項５に記載のコンピュータ可読命令。
27. 前記処理構造が小さな値のデータオブジェクトに対応する場合、前記小さな値のデータオブジェクトを前記処理構造内に完全に格納するために命令をさらに備えることを特徴とする請求項１に記載のコンピュータ可読命令。
28. 前記処理構造での削除操作の命令をさらに備え、前記削除操作は、前記処理構造が第１の型のものである場合、前記処理構造と対応する大規模データオブジェクトを両方とも削除するための命令を備え、前記処理構造が第２の型ものである場合、前記処理構造だけを削除し、前記対応する大規模データオブジェクトは削除しないための命令をさらに備えることを特徴とする請求項１に記載のコンピュータ可読命令。
29. 前記処理構造が存続時間を持ち、前記処理構造が、前記存続時間に対応する値を持つフィールドを備えるための命令をさらに備えることを特徴とする請求項１に記載のコンピュータ可読命令。
30. 前記処理構造を、処理構造の必要に応答して処理構造ファクトリによって作成するための命令をさらに備えることを特徴とする請求項１に記載のコンピュータ可読命令。
    

Images