JP2007532998A - フラグメントベースのシリアライゼーションのシステムおよび方法 - Google Patents

Abstract

フラグメントベースのシリアライゼーションの方法およびシステムが、１つまたは複数のオブジェクトメンバをフラグメント内に置く。フラグメントに、ヘッダおよびペイロードを含めることができる。ヘッダは、フラグメントタイプの表示およびフラグメント長の表示など、フラグメントに関する有用な情報を提供することができる。ペイロードに、オブジェクトの１つまたは複数のメンバを含めることができる。プリミティブメンバは、レコードフォーマットペイロードを用いてバイナリフラグメントにストアすることができる。ＬＯＢメンバおよびＦＳメンバは、フラグメントの追加プロパティを示す値タイプフィールドを有するフラグメントにストアすることができる。コレクションは、第１フラグメントがコレクションの先頭を示し、１つまたは複数の第２フラグメントがコレクション要素をシリアライズし、ターミネータ（ｔｅｒｍｉｎａｔｏｒ）フラグメントがコレクションの終りを示す、一連のフラグメントにストアすることができる。フラグメントシリアライズされたオブジェクトは、ストレージオーバーヘッドを最小にすると同時に、高速なインスタント化ならびに低コストの突き止めおよび更新を提供する。

Description

本願は、その開示が参照により本明細書に組み込まれている、２００４年４月９日出願の米国特許仮出願第１０／８２１６８７号明細書の優先権を主張するものである。

この特許文書の開示の一部に、著作権保護の対象になる材料が含まれる可能性がある。著作権所有者は、米国特許商標局の書類または記録に現れる特許文書または特許開示の何人による写真複製にも異議を唱えないが、それ以外の全著作権を留保する。次の表示が、この文書に適用される：Ｃｏｐｙｒｉｇｈｔ（コピーライト）２００３、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐ．

本発明は、コンピューティングに関し、具体的には、データオブジェクトのストレージおよび伝送に関する。

シリアライゼーションは、オブジェクトインスタンスの状態をストレージ媒体にストアする処理として定義することができる。この処理中に、オブジェクトのパブリックフィールドおよびプライベートフィールドならびにクラスの名前が、バイトのストリームに変換され、次いでこのバイトのストリームが、データストリームに書き込まれる。オブジェクトが、その後にデシリアライズされる時に、オリジナルオブジェクトの正確なクローンを作成することができる。

アクティブなコンピュータメモリ内のオブジェクト、例えば、ある人を記述するデータを有するオブジェクトを検討されたい。この人オブジェクトは、名前、住所、社会保険番号、電話番号、配偶者、身長、および体重など、複数のサブコンポーネントメンバを有する。人の名前は、特定のアプリケーションに重要である場合があるが、身長および体重は、そうでない可能性がある。したがって、名前は、アクティブメモリ内に残され、そこで変更される可能性があるが、身長および体重などの他のフィールドは、他のデータの余地を作るためにアクティブメモリから追い出される。最終的に、人オブジェクトは、もはやアプリケーションに必要でなくなり、永続するか別のコンピュータに伝送される可能性がある。オブジェクトを永続させるか伝送するために、オブジェクトをシリアライズしなければならないが、これは、オブジェクトを有用な取り出し可能な形でフォーマットすることを指す。

上の例では、人オブジェクトなどのオブジェクトのメンバが、一般に、同一クラスのすべてのオブジェクトについて均一である。例えば、各人オブジェクトは、名前、住所、社会保険番号、電話番号、配偶者、身長、および体重の各メンバを有する。情報は、人ごとに変化し、一部の人について、情報が入手不能である（「ヌル」）場合があるが、同一のメンバフィールドの存在が、一般に、人クラスのすべての人オブジェクトについて存在する。したがって、人クラスは、包括的な人オブジェクトと考えることができる。人オブジェクトは、人クラスの１つのインスタンスである。クラスおよびクラスのインスタンスというこの概念は、多数のプログラミング言語に存在する。使用されるプログラミング言語にかかわりなく、シリアライゼーションは、通常、クラスのインスタンスに対して実行され、シリアライズされたオブジェクトが生成される。

オブジェクトに、様々な型のデータを有するメンバを含めることができる。メンバは、プリミティブメンバまたは複合メンバとすることができる。プリミティブメンバの例が、文字のストリングである、人オブジェクトの名前メンバなどの「ｓｔｒｉｎｇ」と、整数である、人オブジェクトの社会保険番号などの「ｉｎｔｅｇｅｒ」である。複合メンバの例が、複数のプリミティブ、例えば複数の整数を含む、電話番号メンバなどの「ｃｏｌｌｅｃｔｉｏｎ」と、例えば電話番号のコレクションまたは別の人オブジェクトを参照する配偶者メンバなど、単一のプリミティブメンバを超える構造を有するメンバである「ｎｅｓｔｅｄ」と、住所型のサブタイプであり、したがっておそらくは米国の地域または私書箱などの追加メンバを宣言する仮定の「Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ａｄｄｒｅｓｓ」型などの「ｓｕｂｔｙｐｅ」である。メンバは、多数の異なる形で記述することができ、複数のパターンで互いに関係する。したがって、人オブジェクトなどのオブジェクトのシリアライズは、オブジェクトに含まれる可能性がある、様々なメンバおよびこれらのメンバの間の関係を効果的に処理することが含まれる。

オブジェクトのシリアライゼーションは、産業界における複数の課題を提示する。シリアライズされたオブジェクトは、できる限り少ないストレージスペースを消費しなければならない。オブジェクトのサイズが、シリアライズされる時に非常に増える場合に、オブジェクトのストレージコストが、高すぎる可能性がある。したがって、コンパクトな表現が、シリアライゼーションフォーマットの重要な態様である。

また、シリアライズされたオブジェクトは、アクティブメモリに効率的にインスタンス化されなければならない。シリアライズされたオブジェクトの様々なメンバを見つけ、アシミレート（ａｓｓｉｍｉｌａｔｅ）することの処理コストが高い場合に、これによって、貴重なプロセッサリソースが奪い去られる。同様に、シリアライゼーションは、オブジェクト全体のインスタンス化を必要としない、オブジェクトのメンバのインスタンス化および更新を可能にしなければならない。例えば、ある人の社会保険番号を読み取るか更新するためだけの人オブジェクト全体のインスタンス化は、名前、電話番号、住所などがその動作に含まれない時に、これらのメンバをストアするのに必要なアクティブメモリリソースの浪費である。

また、シリアライゼーションフォーマットは、オブジェクトに含まれる可能性があるすべてのデータ型をサポートしなければならない。非常に基本的なシリアライゼーションフォーマットは、プリミティブだけをサポートする可能性があるが、より洗練されたフォーマットは、上で説明したｎｅｓｔｅｄメンバ、ｃｏｌｌｅｃｔｉｏｎメンバ、およびｓｕｂｔｙｐｅメンバなどの複合メンバをサポートしなければならない。ほとんどのオブジェクトが、少数のレベルのネスティングおよび継承を有するという特性を有するので、シリアライゼーションフォーマットは、これらのオブジェクトに最適でなければならないが、シリアライゼーションが広範囲のクラスに柔軟に使用できることを保証するために、多数のレベルのネスティングおよび継承もサポートしなければならない。また、シリアライゼーションフォーマットは、非常に多数のメンバを処理する上で柔軟でなければならない。一部のメンバが、例えば音楽ファイル、写真、またはムービーである場合があり、このような大きいメンバは、下で詳細に説明するシリアライゼーションでの課題を提示する。

以前のシリアライゼーションフォーマットは、複数の顕著な欠陥を有する。そのようなフォーマットの１つを、ＸＭＬシリアライゼーションと称する。ＸＭＬシリアライゼーションは、メンバごとに１つのトークンを提供する。このトークンに、メンバを識別するメタデータ、通常はトークンの直後のメンバが含まれる。したがって、ＸＭＬシリアライゼーションは、次のように視覚化することができる。

（トークン１）メンバ１；（トークン２）メンバ２；（トークン３）メンバ３；など
そのようなシリアライゼーションフォーマットに関する問題は、第１に、言葉数の多さである。各すべてのメンバのメタデータトークンのストレージが、大量のディスクスペースを消費する。第２に、そのようなフォーマットでは、取出が損なわれる。というのは、所望のメンバを見つけるために、トークンを検索しなければならないからである。これは、高いアクティブメモリコストを伴う可能性がある。というのは、この形でシリアライズされたオブジェクトを読み取るか更新するかの最も効果的な形が、オブジェクト全体をインスタンス化することになる可能性があるからである。

もう１つのシリアライゼーションフォーマットが、「ＳＥレコード」または単に「レコード」フォーマットとも称する「ストレージエンジン（Ｓｔｏｒａｇｅ Ｅｎｇｉｎｅ）レコード」フォーマットにある。これは、通常のデータベースシステムレコードフォーマットである。このシリアライゼーションフォーマットでは、所与のクラスのオブジェクトのメンバが、均一にフォーマットされたレコードにストアされる。各すべてのメンバを記述するメタデータを提供するのではなく、特定のクラスのオブジェクトのすべてのレコードの内容を記述するメタデータがある。これは、図１０のように視覚化することができる。

ＳＥレコードシリアライゼーションフォーマットは、各個々のメンバのメタデータを必要とせず、したがって、よりコンパクトなシリアライゼーション技法である。その代わりに、このフォーマットは、図１０のＭｅｔａｄａｔａ ｆｏｒ Ｐｅｒｓｏｎ Ｏｂｊｅｃｔｓテーブルなど、ディスク上のメンバのレイアウトを記述したメタデータへのアクセスを必要とする。ＳＥレコードフォーマットの弱点は、現在オブジェクトと共にストアされる音楽ファイル、ムービー、およびイメージの多くなど、可変長のメンバの処理において柔軟でないことである。より正確にいえば、ＳＥレコードシリアライゼーションの柔軟性は、高い処理コストで得られる。レコード内の可変長データの位置を識別するのにオフセットテーブルが使用される場合に、可変長のメンバをそのようなフォーマットでストアすることができる。オフセットテーブルをストアすることの結果は、可変長データメンバが更新される時に、必ず、それに続くすべての可変長データの位置を調整しなければならないことである。これは、配列の途中にバイトを挿入することになぞらえることができる。すなわち、挿入点の右側にあるすべてのものを右にシフトして、挿入される新しいバイトのスペースを作らなければならない。

さらに、データベースのユーザがデータベースに効率的にオブジェクトをストアできるようにするために、様々なストレージフォーマットが設計されてきた。これらのストレージフォーマットは、より柔軟なシリアライゼーションフォーマットを用いてより良くサポートされることができる。例えば、本明細書で提供するシリアライゼーションフォーマットから区別されなければならない。例えば、ユーザがＣ＃などのオブジェクト指向言語で記述されたクラスおよびメソッドをデータベースに「インポート」できるようにする技術がある（特許文献１（弁理士整理番号−ＭＳＦＴ２８５２／３０６８１９．０１、「system and method for object persistence in a database store」）参照）。この技術は、さらに、ユーザが、Ｃ＃オブジェクトをデータベースにストアし、そのオブジェクトに対してメソッドを呼び出すことができる。この技術は、永続性の複数のフレイバをユーザに提供する。ユーザは、彼自身のシリアライゼーションフォーマットを定義し、ＣＬＲ（Ｃｏｍｍｏｎ Ｌａｎｇｕａｇｅ Ｒｕｎｔｉｍｅ）シリアライゼーション（Ｃ＃言語自体によって提供される）を使用し、またはＳＱＬサーバにそれ自体のフォーマットでオブジェクトをストアさせることができる。これらのオプション、特に後者は、性能の利益をもたらす。というのは、ＭＩＣＲＯＳＯＦＴ ＳＱＬ ＳＥＲＶＥＲ（登録商標）が、Ｃ＃オブジェクトを実際にシリアライズせずに、オブジェクトの一部のフィールドを取り出すか更新することができるからである。もちろん、メソッド呼出しなど、いくつかの動作は、Ｃ＃オブジェクトのインスタンス化を必要とする。

類似する背景および関連技術の記述がある（特許文献２（弁理士整理番号−ＭＳＦＴ２８５０／３０６８２０．１、「System and Method for Storing and Retrieving a Field of a User Defined Type Outside of a Database Store」）参照）。この特許では、ＵＤＴ内のファイルストリームが論じられ、このファイルストリームは、本明細書に記載の技法に従ってシリアライズすることができる。そのような高度なデータベース技術は、より柔軟で高性能のシリアライゼーションフォーマットから利益を得ることができる。同様に、シリアライズされたオブジェクトに対して動作を実行する改善された技法は、そのような高度なデータベース技術をより良くサポートする。

米国特許仮出願第１０／６９２２２５号明細書 米国特許仮出願第１０／６９２２２７号明細書

したがって、シリアライゼーションフォーマットに伴うトレードオフは、フォーマットのメタデータオンディスクメモリオーバーヘッドと、メンバ突き止めのアクティブメモリオーバーヘッドと、メンバを突き止める処理コストと、更新を行うコストと、大きいファイルを処理する際の柔軟性との間にある。これらのトレードオフに鑑みて、産業界に、シリアライゼーション技法に関する水準を引き上げる、進行中の、したがって対処されてない必要がある。

フラグメントベースのシリアライゼーションの方法およびシステムが、１つまたは複数のメンバをフラグメント内に置く。フラグメントに、ヘッダおよびペイロードを含めることができる。ヘッダは、フラグメントタイプの表示およびフラグメント長の表示など、フラグメントに関する有用な情報を提供することができる。ペイロードに、オブジェクトの１つまたは複数のメンバを含めることができる。オブジェクトメンバをストアし、取り出す際の効率および柔軟性のために、様々なフラグメントタイプを提供する。プリミティブメンバは、レコードフォーマットペイロードを用いてフラグメントにストアすることができる。この構成は、プリミティブの高速な突き止めおよび更新を可能にする。ラージオブジェクト（「ＬＯＢ」）メンバは、ＬＯＢメンバおよびＦＳメンバの位置の位置タイプを示すフィールドを有するフラグメントにストアすることができる。コレクションは、第１フラグメントがコレクションの先頭を示し、１つまたは複数の第２フラグメントがコレクション要素をシリアライズし、ターミネータ（ｔｅｒｍｉｎａｔｏｒ）フラグメントがコレクションの終りを示す、一連のフラグメントにストアすることができる。これらおよび他のフラグメントタイプを、シリアライゼーションフォーマットに追加の機能性を提供する形で、フラグメントの生成、フラグメント内のメンバの配置、およびフラグメントのシーケンシングを支配するルールに従って編成することができる。

本発明の様々な実施形態の完全な理解を提供するために、ある特定の詳細を、次の説明および図面に示す。しかし、コンピューティング技術にしばしば関連する、ある周知の詳細は、本発明の様々な実施形態を不必要に不明瞭にすることを避けるために、次の開示では示さない。さらに、当業者は、下で説明する詳細の１つまたは複数なしで、本発明の他の実施形態を実践できることを理解するであろう。最後に、次の開示で、ステップおよびシーケンスに関して様々な方法を説明するが、この説明が、本発明の実施形態の明瞭な実施態様を提供するためのものであり、ステップおよびステップのシーケンスを、本発明の実践に必要なものとして解釈してはならない。

本発明の目的は、改善されたオブジェクトシリアライゼーションの方法およびシステムを提供すること、ならびに、シリアライズされたオブジェクトに対する動作の技法を提供することである。これに関して、コンパクトな表現を提供するシリアライゼーションを提供する。提供されるフォーマットでシリアライズされたオブジェクトは、アクティブメモリに効率的にインスタンス化することができ、これによって、シリアライズされたオブジェクトの様々なメンバを見つけ、アシミレートする処理コストを減らすことができる。同様に、オブジェクトのメンバを、オブジェクト全体をインスタンス化する必要なしにインスタンス化し、更新することができる。さらに、ユーザ定義データ型（「ＵＤＴ」）を含む広範囲のデータ型のサポートが提供される。このシリアライゼーションフォーマットは、少数のレベルのネスティングおよび継承を有するオブジェクトのために最適化することができるが、多数のレベルのネスティングおよび継承もサポートすることができる。このシリアライゼーションフォーマットは、非常に多数のメンバを扱う際に柔軟である。本発明は、単一の列での様々な型のストレージに適するシリアライゼーションフォーマットを提供することができ、例えば、「ｐｅｒｓｏｎ（人）」オブジェクトのサブタイプである「ｅｍｐｌｏｙｅｅ（従業員）」オブジェクトを、「ｐｅｒｓｏｎ」オブジェクトだけをストアするために設けられた列にストアすることができる。最後に、このシリアライゼーションフォーマットは、効率的な型エボリューション（ｔｙｐｅ ｅｖｏｌｕｔｉｏｎ）とも呼ばれる、型への新しいメンバの効率的な追加を可能にする。

本発明の様々な実施形態によるフラグメントベースのシリアライゼーションは、フラグメントベースのシリアライゼーション自体に独特の多数の態様および長所に加えて、背景で説明したＸＭＬスタイルシリアライゼーションの要素の一部と、やはり背景で説明したＳＥレコードシリアライゼーションの要素の一部とを使用するハイブリッドフォーマットとして概念化することができる。これに関して、オブジェクトのメンバを、フラグメントに置くことができる。フラグメントを、図１に示す。

図１を参照すると、フラグメントに、ヘッダと、いくつかの場合にペイロードを含めることができる。ヘッダは、フラグメントタイプの表示およびフラグメント長の表示など、フラグメントに関する有用な情報を提供することができる。このヘッダは、ＸＭＬシリアライゼーションによって提供されるトークンに多少似ている。というのは、ＸＭＬシリアライゼーションコンテキストのメンバごとにトークンが提供されるのと同様に、新しいヘッダが、フラグメントごとに与えられるからである。しかし、ＸＭＬトークンは、ヘッダごとに設けられるが、図１のフラグメントには、複数のメンバを含めることができる。これが、フラグメント１に示されており、フラグメント１は、複数のデータメンバを含むペイロードを有するフラグメントを示す。フラグメントベースの方法は、単純なプリミティブフィールド（整数、ストリングなど）を有するオブジェクト、接続されたオブジェクトのグラフ全体、およびコレクションを含むがこれに制限されない、様々なデータ構造をシリアライズし、デシリアライズすることができる。

フラグメントペイロードに、シリアライズされたオブジェクトの１つまたは複数のメンバ、ならびに任意の他のデータを含めることができる。このペイロードは、その中のメンバにＳＥレコードフォーマットスタイルのシリアライゼーションを使用することができ、これによって、ペイロード内のメンバの素早い取出が可能になる。そのようなレコードフォーマットペイロードは、図１のフラグメント１の特性である。これに関して、フラグメントベースのシリアライゼーションは、ＳＥレコードシリアライゼーションの特徴を有する。メタデータを、ヘッダで、またはペイロードに含まれるフィールドを記述する他の場所で提供することができる。したがって、コンパクトな表現およびオブジェクト全体をインスタンス化せずに個々のメンバを取り出すことの対応する利点を達成することができる。ペイロードを、レコードフォーマットとすることができるが、フラグメント２および３に示されているように、そうする必要がないことに留意されたい。

フラグメントのヘッダ部分に、図２に示されているように、様々なフィールドを含めることができる。図２に、様々な可能なフィールドを示すことができるように、拡張ヘッダセクションを有するフラグメントを示す。図２で提供される様々なフィールドを、すべてのフラグメントに含める必要がないことに留意されたい。その代わりに、フラグメントのペイロードに関する有用な情報を提供するフィールドを、ヘッダに含めることができる。図２の様々なフィールドを、フラグメントの様々な提案されるタイプの説明と共に、下でより詳細に説明する。

本発明の様々な実施形態では、オブジェクトをシリアライズする際の追加の多用途性のために、複数のタイプのフラグメントを使用する。様々な提案されるフラグメントタイプを、下で示す。しかし、フラグメントタイプを説明する前に、異なるフラグメントタイプを使用する動機づけを検討されたい。１つの動機づけ要因は、オブジェクトを構成することができる様々なタイプのメンバのより良いシリアライゼーションを可能にすることである。背景セクションから、オブジェクトに、頻繁に、異なる型の複数のメンバが含まれることを想起されたい。このメンバに、例えば、次を含めることができる。

・ 小さいプリミティブメンバ。これは、整数（「ｉｎｔ」）、ｆｌｏａｔ、およびｓｔｒｉｎｇなどの基本型のメンバである。

・ ラージオブジェクト（「ＬＯＢ」）およびファイルストリーム（「ＦＳ」）などの大きいプリミティブメンバ。

・ ＣｏｌｌｅｃｔｉｏｎおよびＮｅｓｔｅｄなどの複合メンバ。

・ サブタイプメンバ。継承をサポートするすべてのクラスが、継承されたメンバを含むクラスのインスタンスを有することができ、この継承されたメンバを、サブタイプのデータとすることができる。

上記は、潜在的なメンバタイプの網羅的ではないリストであり、すべてのメンバタイプが、本明細書で説明するフラグメントベースのシリアライゼーション技法と共に使用することに関する候補と考えられる。

フラグメントタイプ
シリアライズされる１つのオブジェクトに存在する可能性がある様々なタイプのメンバに対処するために、本発明を、複数のフラグメントタイプと共に使用することができる。１つまたは複数のフラグメントタイプが、メンバの１つのタイプだけに有用である場合があり、他のフラグメントタイプが、複数のメンバタイプに有用である場合がある。

様々なフラグメントタイプが、そのフラグメントの内容に合わせて調整された異なるフォーマットを有することができる。次の議論では、まずフラグメントタイプを示し、そのタイプの提案されるフラグメントフォーマットの視覚的描写を続ける。斜体のフラグメント属性は、任意選択であり、タイプ列の値に依存する。本発明は、下で示すフラグメントタイプに制限されない。本明細書で提供するフラグメントの他に、本明細書で提供するフラグメントベースのシリアライゼーションの一般定原理に従う使用のために新しいフラグメントタイプを開発することができる。

バイナリフラグメント−図１１（Ａ）に、バイナリフラグメントの様々な潜在的実施形態を示す。このフラグメントに、タイプフィールド、長さフィールド、およびペイロードフィールドが含まれる。タイプフィールドは、単に１つのバイトとすることができ、あるいは、任意の個数のバイトとすることができる。タイプフィールドの追加バイトは、そのシリアライゼーションフォーマットを使用する時に追加のメモリオーバーヘッドを必要とする。したがって、ヘッダフィールド内のバイトは、倹約して使用されなければならない。これに関して、１バイトのタイプフィールドに、フラグメントの様々なプロパティを示すのに使用される複数のビットを含めることができる。１つのビットを、フラグメントがバイナリフォーマットであることを示すのに使用することができる。もう１つのビットを、フラグメントに含まれる１つまたは複数のメンバのタイプを示すのに使用することができる。例えば、すべてのメンバがプリミティブである場合に、あるビットをセットして、そのような情報を示すことができる。メンバがサブタイプメンバである場合に、あるビットをセットして、それを示すことができる。バイナリフォーマットが、シリアライズされたオブジェクトの最初のまたは唯一のフラグメントである場合に、タイプフィールドの１つのビットが、それを示すことができる。タイプフィールドは、１つまたは複数のフラグメントに含まれるオブジェクトタイプならびに、オブジェクト全体のフラグメントの個数およびタイプなどの追加の有用な情報を示すこともできる。

単一のバイナリフラグメント内で表現されるオブジェクトに、タイプフィールドで「自己終端」フラグメントとしてフラグを立て、シリアライズされたオブジェクトの終りにターミネータフラグメントを含める必要をなくすことができる。この「自己ターミネータ」フラグは、フラグメントのタイプフィールドの自己ターミネータビットの形とすることができる。そのような自己ターミネータビットは、フラグメントヘッダの他のフィールドに、またはフラグメントペイロード内に置くこともできる。複数のフラグメントによって表されるオブジェクトは、自己ターミネータビットをセットする必要がない。というのは、ターミネータフラグメントを生成して、シリアライズされたオブジェクトの終りをマークすることができるからである。

長さフィールドは、最適には２バイトであるが、この長さは、上で説明したように変更することができる。長さフィールドは、ペイロードの長さを示すのに使用することができる。バイナリフラグメントのペイロードに、どのデータでも含めることができる。好ましい実施形態では、ペイロードに、オブジェクトのすべてのプリミティブメンバが含まれる。そのようなフラグメントのペイロードは、ＳＥレコードとして、そこにストアされたプリミティブまたは他のメンバの効率的なクラッキングおよび更新を可能にすることができる。

ＬＯＢフラグメント−図１１（Ｂ）に、ＬＯＢフラグメントの様々な潜在的な実施形態を示す。このフラグメントは、ヘッダ内のタイプフィールド、値タイプフィールド、および長さフィールドと、ＬＯＢまたはＬＯＢの位置情報を含むペイロードとを有することができる。タイプフィールドは、フラグメントのそれぞれと同様に、この場合にフラグメントがＬＯＢフラグメントであることを示す１バイトであることだけが必要である。値タイプフィールドは、ＬＯＢフラグメントの内容を記述する追加の手段を提供することができる。そのような値タイプフィールドは、ＬＯＢ属性のためにタイプフィールドのビットを使い切ることが望ましくない実施形態で、ＬＯＢ属性に関する情報を含めるために追加することができる。この形では、ＬＯＢフラグメントだけがオーバーヘッド（ここでは、フラグメントごとに１つの追加のバイト）を有する。

値タイプフィールドにストアされる情報は、ＬＯＢがストアされる位置のタイプを記述することができる。ＬＯＢメンバの位置の追加記述を可能にすることによって、大きい値の処理における柔軟性が提供される。ＬＯＢデータ（ＬＯＢ参照ではなく）がＬＯＢフラグメントにストアされる場合に、アプリケーション（またはコンピュータのユーザ）が、ＬＯＢ Ｉｎｌｉｎｅｄタイプフラグメントの生成を開始し、８バイトの長さを使用し、ＬＯＢをインラインに置くことができる。言い換えると、ＬＯＢを、ＬＯＢフラグメントのペイロードに置くことができる。値タイプフィールドが、ＬＯＢ Ｉｎｌｉｎｅｄタイプを示す場合に、長さフィールドを、例えば８バイトとすることができ、ペイロードに、ＬＯＢ値を含めることができる。

ＬＯＢをシリアライズされたオブジェクトとインラインで含めることは、必ずしも望ましくない場合がある。これは、ＬＯＢが、大量のスペースを占める可能性があるからである。したがって、値タイプフィールドは、ＬＯＢ Ｐｏｉｎｔｅｒタイプを示すことができ、このタイプは、フラグメントのペイロードに、ＬＯＢ位置へのポインタが含まれることを意味する。このシナリオでは、長さフィールドを、例えば２バイトとすることができ、ペイロードに、ＬＯＢ参照を含めることができる。値タイプフィールドは、ＬＯＢ Ｄｅｌａｙｅｄタイプを示すこともでき、このタイプは、フラグメントペイロードに、おそらくはＬＯＢを含むデータベース内のセルへのＬＯＢ参照が含まれることを意味することができる。この代替シナリオでは、フラグメント長を、例えば２バイトとすることができ、ペイロードに、セル参照を含めることができる。「セル参照」は、テーブル識別子、行識別子、および列識別子の組み合わせである。ＬＯＢフラグメントの「パス」（下で説明する）と組み合わされた時に、セル参照は、実際のＬＯＢデータを突き止めるのに十分な情報を与える。他の位置タイプ情報を、ＬＯＢフラグメントまたはＦＳフラグメントの値タイプフィールドに含めることができる。ＬＯＢフラグメントおよびＦＳフラグメントのそのような追加の位置タイプフィールドを提供することによって、シリアライゼーションフォーマットに追加の柔軟性が与えられると同時に、オーバーヘッドが低く保たれる。

本明細書で論ずるフラグメントのどれであっても、特定のオブジェクトが特定のクラスのシリアライゼーションで提供されるメンバを有しない場合に、ヌルにすることができることに留意されたい。フラグメントがヌルである場合に、この情報を、フラグメントのタイプフィールドの１ビットにセットすることができる。これに関して、長さフィールドおよびペイロードを、図１１（Ｂ）のＬＯＢフラグメントから除去して、位置が値タイプフィールドで指定されるヌルＬＯＢフラグメントを形成することができる。

ＦＳ（ファイルストリーム）フラグメント−図１１（Ｃ）に、ＦＳフラグメントの様々な可能な実施形態を示す。すべてのフラグメント同様に、ＦＳフラグメントは、フラグメントタイプ（この場合にはＦＳフラグメント）を示すタイプフィールドを有することができる。ＬＯＢフラグメントと同様に、ＦＳフラグメントに、値タイプフィールドを含めることができる。やはり、このフィールドは、ＦＳの様々な位置タイプを示すことができる。ＦＳは、オブジェクトの残りと共にシリアライズするすなわち、インラインタイプとすることができる（やはり、これは、より大きい長さフィールド、例えば８バイトと相関することができる）。値タイプフィールドは、フラグメントペイロード内でポイントされる位置すなわちＦＳポインタタイプとすることができ、これは、ＦＳに関して、例えば２バイトの長さフィールドと、適当なＦＳファイルのグローバル一意識別子（「ＧＵＩＤ」）を含むペイロードを示すことができる。値タイプフィールドは、ＦＳ Ｄｅｌａｙｅｄ位置タイプを示すこともでき、これは、例えば２バイトの長さと、セル参照を含むペイロードに相関することができる。

ターミネータフラグメント−図１１（Ｄ）に、ターミネータフラグメントの様々な可能な実施形態を示す。フラグメントベースシリアライゼーションの好ましい実施形態では、タイプバイトだけが、ターミネータフラグメントに関係する。これは、ターミネータフラグメントの機能が、シリアライズされたオブジェクトの終りをマークすること、またはシリアライズされたオブジェクト内の関連するフラグメントのコレクションまたは他のセットの終りをマークすることであるからである。ターミネータフラグメントは、それがターミネータフラグメントであることを示すタイプフィールドによってこの機能を実行することができ、追加情報を含める必要はない。しかし、ターミネータフラグメントに追加情報を含めることが有用である場合があり、そのような実施形態は、確かに本明細書に記載の発明の範囲に含まれる。

コレクション開始フラグメント−図１１（Ｅ）に、コレクション開始フラグメントの様々な可能な実施形態を示す。このフラグメントには、タイプフィールドと、例えば２バイトの、ビットフィールドを含めることができる。タイプフィールドは、このフラグメントがコレクション開始フラグメントであることを示すことができる。ビットフィールドは、コレクションのプロパティを示すことができる。例えば、ビットフィールドは、「順序付けされない」コレクションを示すことができ、これは、特定の順序ではないコレクションに対応することができる。ビットフィールドは、「順序付けされた」コレクションを示すこともでき、これは、コレクションが特定の順序であることを示す。このフラグメントは、コレクションを記述する目的だけに使用される場合に、長さフィールドを省略することができる。というのは、コレクション開始フィールドが、コレクションの始まりをマークするからであり、したがって、ペイロードを含む必要がないからである。コレクション開始フラグメントに含まれるペイロードがある場合には、そのペイロードを記述する長さフィールドを有することができる。しかし、本明細書に記載の好ましい実施形態では、コレクション開始フラグメントが、コレクションのマークおよび記述に使用され、それ自体のペイロードを持たず、したがって、長さフィールドを有する必要がない。したがって、ヌルコレクション開始フラグメントは、図１１（Ｅ）のコレクション開始フラグメントに非常に似て見える。コレクション開始フラグメントがヌルである状況での唯一の相違は、上でヌルＬＯＢフラグメントに関して説明したように、タイプフィールド内でセットされるビットである。

コレクション要素フラグメント−図１１（Ｆ）に、コレクション要素フラグメントの様々な可能な実施形態を示す。そのようなフラグメントのタイプフィールドは、それがコレクション要素フラグメントであることを示すことができる。長さフィールドは、コレクション要素フラグメントのペイロードの長さを示すことができる。図１１（Ｆ）に、２バイトの例示的な長さフィールドサイズを示すが、これは、コレクション要素を含むペイロードの長さを示すのに十分であろう。

ロケータフィールドも、コレクション要素フラグメントに含めることができる。ロケータフィールドは、ＬＯＢフラグメントおよびＦＳフラグメントの値タイプフィールドと同様に、コレクション要素フラグメントの追加プロパティを示すのに使用することができる。例えば、コレクション要素フラグメントは、バイナリフラグメントのペイロードのように、ＳＥレコードフォーマットのペイロードを有することができる。タイプフィールドは、フラグメントがそれ自体を終端するかどうかを示すビットを使用することによって、コレクション要素フラグメントが自己ターミネータであるかどうかを示すことができる。自己ターミネータビットがセットされていない場合には、システムは、フラグメントのターミネータフラグメントを予期することができる。ロケータフィールドは、ＦＳフラグメントのＧＵＩＤに非常によく似て、コレクションの特定の要素をアドレッシングするのに使用することができる。しかし、コレクション要素フラグメントの場合に、ロケータフィールドは、必ずしもグローバルに一意の位置ではなく、コレクション内の一意の位置を示す。

ロケータフィールドに関して、コレクション要素内のロケータフィールドのある予期を可能にすることも好ましい場合がある。コレクション開始フラグメントのビットフィールドのビットをセットして、やがて来るロケータフィールドを有するコレクション要素フラグメントを示すことができる。そのような構成では、ロケータフィールドがコレクション要素フラグメントに存在することを演繹するようにシステムを構成することができる。

ヌルコレクション要素フラグメント−図１１（Ｈ）に、ヌルコレクション要素フラグメントの様々な可能な実施形態を示す。コレクション要素フラグメントのヌル表現に、そのフラグメントがヌルコレクション要素フラグメントであることを示すタイプフィールドを含めることができる。ヌルコレクション要素フラグメントに、ロケータフィールドを含めることもできるが、長さフィールドまたはペイロードフィールドを含める必要はない。というのは、特定のシリアライズされたオブジェクトが、そうでなければそのようなデータを含むように設計されたクラスの特定の態様に対応するデータを有しないことが、ヌルコレクション要素フラグメントの存在によって示されるからである。やはり、メンバまたは他のメンバ情報がペイロードに含まれない場合に、ペイロードの長さを記述する長さフィールドの必要がないものとすることができる。

ヌルフラグメント−図１１（Ｇ）に、ヌルフラグメントの様々な可能な実施形態を示す。ヌルフラグメントは、ターミネータフラグメントと同様に、単一のタイプフィールドによって表すことができる。やはり、これは、非コレクション要素ヌルフラグメントの表現に制限することができる実践である。コレクション要素ヌルフラグメントの説明については、下を参照されたい。

注釈フラグメントおよびメタデータフラグメント−上で説明した他のフラグメントの他に、メタデータフラグメントおよび注釈フラグメントを使用して、シリアライズされたオブジェクトの受取り側に１つまたは複数のフラグメントを説明することができる。そのようなフラグメントは、それらがオブジェクトのデシリアライズに必要でない可能性がある場合であっても、様々な状況で有用である。例えば、注釈フラグメントは、クライアントが特定のメンバまたはオブジェクトに関する情報を検査すること、またはシリアライズされたオブジェクトに関するメモまたは情報を挿入することを可能にすることができる。

結論として、上で示した様々なフラグメントの説明を参照すると、効果的なシリアライゼーションフォーマットによって達成される利点の１つは、表現オーバーヘッドの削減である。表現オーバーヘッドは、オブジェクトを効果的に取り出せるようにするためにオブジェクトと共にストアされる追加情報の量を指す。フラグメントベースのシリアライゼーション技法には、表現オーバーヘッドが含まれるが、そのオーバーヘッドは、このフォーマットの対応する柔軟性および機能性について最小化されている。

フラグメントヘッダの最初のフィールドは、タイプフィールドである。好ましい実施形態では、タイプフィールドが、１バイトを消費する。これによって、関連するオーバーヘッドが最小になる。さらに、コレクション要素フラグメントに関連するロケータフィールドが、オーバーヘッドになる。ほとんどの小さい順序付けられないコレクションは、４バイトしか消費しないロケータフィールドで適当に表現することができる。しかし、より大きい順序付けられたコレクションは、５バイト以上を消費する可能性があり、この場合に、ロケータフィールドを、より大きい表現オーバーヘッドを必要とする可能性がある可変バイナリ（「ｖａｒｂｉｎａｒｙ」）フィールドに置換することができる。ロケータフィールドによって使用されるオーバーヘッドの正確な量は、実装詳細と考えられ、当業者の判断に委ねられるが、当業者は、表現オーバーヘッドを減らすがコレクションの柔軟なシリアライズも可能にすることの動機づけを諒解するであろう。最後に、複数の他のフラグメントタイプ（上を参照されたい）に関連する長さフィールドが、表現オーバーヘッドである。上で説明したように、好ましい実施形態の長さフィールドは、フラグメントタイプに応じて、２バイトまたは８バイトのいずれかの長さとすることができる。本発明は、そのようなフィールドの正確なバイト数に制限されず、本明細書で示したパラメータは、経験を積んだ実務家からの有用なヒントと考えられるべきであり、本発明自体の厳重な要件ではない。

フラグメントにメンバを置くルール
上で説明したように、様々なフラグメントタイプが、様々なフラグメントメンバを処理することができる。オブジェクトをシリアライズするために、特定のメンバにどのフラグメントタイプを使用するかに関する判断を行わなければならない。例えば、プリミティブメンバ、ネストされたメンバ、コレクションメンバ、およびサブタイプメンバを含むオブジェクトを、ルールのセットに従ってフラグメントに分解することができる。本発明は、フラグメントタイプとメンバタイプの特定の相関に制限されないが、有用なルールのセットが開発されており、これをこのセクションで説明する。このルールが、説明を明瞭にするためのものであって、これらを特定の順序で実行しなければならないことを示すためのものでないことに留意されたい。実際には、下のルールに対応する動作を、オブジェクトのメンバを介するプロセッサステップとして行われるフラグメントの生成、取り込み、およびシーケンシングと同時に実行することができる。オブジェクトのシリアライゼーションに対するこれらのルールの例示的な適用について、図３と下の対応するテキストを参照されたい。ルールは、次の通りである。

フラグメントを生成する。本発明の実施形態は、タイプベースコンテナ相対フラグメント生成にかかわると言うことができる。言い換えると、次のそれぞれについて１つのフラグメントを設けることができる。

・ レベルがヌルである場合であっても、クラス内のネスティングのレベルごとに
・ コレクションがヌルである場合であっても、コレクションごとに
・ コレクションの要素ごとに
・ サブタイプごとに
・ ＬＯＢ属性ごとおよびＦＳ属性ごとに。ヌルの場合であっても。ＬＯＢ値は、インラインにストアすることができるが、ＦＳ値は、アウトオブラインでストアしなければならない。

特定のクラスの必要に合わせて、追加のフラグメントを生成することができる。同様に、上のフラグメントが、あるクラスのシリアライズに必要でない場合がある。

一般に、オブジェクトは、トップダウン技法を使用して、フラグメントベースのシリアライゼーションフラグメントに変換することができる。まず、オブジェクトのすべての基本型メンバをシリアライズし、それに続いてサブタイプをシリアライズすることができる。すべてのネスティングレベルで、ネストされた型、サブタイプ、またはＬＯＢ／ＦＳタイプメンバがあるかどうかを判定するために、含まれるメンバについてスキャンを行うことができる。

プリミティブメンバのフラグメントの生成。プリミティブメンバの一部またはすべてを、１つまたは複数のバイナリフラグメントに置くことができる。好ましい実施形態では、ネストされたメンバを有しないオブジェクトを、ネストされたメンバを有するオブジェクトと異なる形で扱う。この２つのシナリオを、図４および図５に示す。両方の状況で、ネストされていないプリミティブを、単一のバイナリフラグメントの中に置き、ＳＥレコードフォーマットを使用してその中でシリアライズすることができる。ネストされたメンバがないオブジェクトについて、バイナリフラグメントを生成することができ、ネストされたメンバがないことの表示を、そのフラグメントのタイプフィールドに置くことができる。様々な実施形態で、ネストされたメンバを含むオブジェクトとネストされたメンバを含まないオブジェクトの間の実際的な差は、ネストされたメンバを有するオブジェクトを複数のフラグメントにシリアライズすることができるが、ネストされたメンバがないオブジェクトを単一のバイナリフラグメントにシリアライズすることができることである。したがって、ネストされたメンバがない場合に、バイナリフラグメントのフィールドで、自己ターミネータビットをセットすることができる。バイナリフラグメントの長さフィールドは、組み合わされたプリミティブメンバの長さに対応するようにセットすることができる。次に、フラグメントを発することができる。

図５を参照すると、ネストされたフラグメントがある場合に、バイナリフラグメントに関するネストされたメンバなしの処理を多少変更して、ネストされたメンバを再帰的にシリアライズすることを可能にすることができる。この状況では、自己ターミネータビットをセットする必要はない。バイナリフラグメントを発した後に、ｎｅｓｔｅｄタイプのメンバを、それ自体のフラグメントに再帰的に処理することができる。そのような再帰からリターンする時に、ターミネータフラグメントを生成することができる。その後、ターミネータフラグメントも発することができる。

コレクションのフラグメントの生成。コレクションフラグメントを生成する処理の流れ図を、図６に示す。コレクションメンバに出会った時に、コレクション開始フラグメントを生成することができる。コレクションが順序付けられていない場合には、ビットフィールドのビットを、「順序付けられない」にセットすることができる。次に、下で説明するように、コレクション要素フラグメントを生成することによって、コレクションの各要素を再帰的にシリアライズすることができる。すべての要素をシリアライズした後に、ターミネータフラグメントを生成して、コレクションの終りを示すことができる。

コレクション要素は、１つまたは複数のフラグメントにシリアライズすることができる。コレクション要素が、複数のフラグメントを使用して表される場合に、その表現は、それ自体のターミネータフラグメントを有することができる。コレクション要素の最初のフラグメントに、ロケータフィールドを含めることができる。そのようなフィールドの目的の１つを、コレクションをシリアライズする時に処理される要素の数を記憶することとすることができる。シリアライゼーションに関する現在の要素を正しく示すようにロケータフィールドのカウンタを増分することによって、シリアライゼーションプロセスが、コレクションの次の要素をシリアライズするために正しい位置に戻れるようになる。

ＬＯＢフラグメントおよびＦＳフラグメントの生成。ＬＯＢメンバおよびＦＳメンバのフラグメントの生成を示す流れ図を、図７に示す。様々なフラグメントタイプの説明で示したように、ＬＯＢフラグメントおよびＦＳフラグメントの両方を、対応するペイロードの複数の位置タイプを示すように構成することができる。この表示は、値タイプフィールドで行うことができる。例えば、値タイプフィールドによって、ポインタタイプ、ｉｎｌｉｎｅｄタイプ、またはｄｅｌａｙｅｄ ｌｏｃａｔｉｏｎタイプを含むものとしてペイロードを記述することができる。ＬＯＢフラグメントおよびＦＳフラグメントを生成する際に、適当な値タイプを、メンバから判定することができる。例えば、ＬＯＢがオブジェクトと共にシリアライズされる、すなわち、フラグメントとインラインでストアされる場合に、ＬＯＢ Ｉｎｌｉｎｅの値タイプを選択することができ、ＬＯＢをそれ相応にシリアライズすることができる。その代わりに、ＬＯＢが、シリアライズされたオブジェクトと共にではなくデータベースのセルにストアされる場合に、ＬＯＢ参照をオブジェクトと共にシリアライズすることができ、適当な位置タイプを値タイプフィールドにストアすることができる。その後、フラグメントを発することができる。

サブタイプフラグメントの生成。サブタイプフラグメントは、他の非プリミティブメンバのフラグメントと同一の形で生成することができる。言い換えると、サブタイプが、コレクションメンバを含む場合に、コレクション要素フラグメントおよびターミネータフラグメントと共にコレクション開始フラグメントを生成して、サブタイプメンバのシリアライゼーションの終りをマークすることができる。サブタイプメンバがネストされたＬＯＢメンバである場合には、ＬＯＢフラグメントを生成して、サブタイプメンバを含めることができる。バイナリフラグメントが、サブタイプのために生成され、これには、基本型についてバイナリフラグメントが生成されるのに似た形で、ｉｎｔ、ｆｌｏａｔなどのサブタイプ内のすべての小さいプリミティブメンバが含まれる。

他のフラグメントの生成。本明細書で説明する技法を、特定のオブジェクトまたはオブジェクトのクラスのシリアライゼーションに望まれるか要求される可能性がある他のすべてのフラグメントの生成に外挿することができる。

フラグメントへの取り込み。フラグメントを実際に生成し、それと同時にフラグメントに取り込むことができるが、本発明のこの態様の説明のために、フラグメントにどのように取り込むかの全体的なプランを含めることが有用である。この全体的なプランを、図８に示す。メンバを様々なフラグメントタイプに置く際に、次の提案を観察することができる。

・ ＬＯＢメンバを除くすべてのプリミティブメンバを、バイナリフラグメントにストアすることができる。このフラグメントのヘッダに、オブジェクト全体の型識別子を含めることができる。このフラグメントのペイロードに、ストレージエンジンレコードを含めることができる。フラグメントは、プリミティブ属性だけを含む場合に、それ自体を終端すると言われる。

・ 各ＬＯＢメンバは、ＬＯＢフラグメントにストアすることができる。

・ コレクション開始フラグメントを、コレクションメンバごとに生成することができる。コレクションメンバが空でない場合に、コレクション開始フラグメントは、１つまたは複数のコレクション要素フラグメントを参照することができる。

・ コレクション要素フラグメントは、コレクションメンバの様々な要素について提供される。このフラグメントは、ロケータを伴うバイナリフラグメントとすることができる。ロケータは、コレクション要素をアドレッシングするのに用いることができるラベルである。

・ ターミネータフラグメントを、複数のフラグメントに分解されたコレクションメンバごとに生成することができる。ターミネータフラグメントは、コレクションメンバの終りをマークする。

・ ネストされたフラグメントを有するフラグメントは、それ自体を終端しない。その代わりに、このフラグメントは、このフラグメント内でネストされたすべてのフラグメントの後に現れるターミネータフラグメントを有する。

・ ターミネータフラグメントを、複数のフラグメントに分解されたオブジェクトごとに生成することができる。ターミネータフラグメントは、シリアライズされたオブジェクトの終りをマークすることができる。

・ ネストされたオブジェクトは、上と同一のルールに再帰的に従うことができる。

・ シリアライゼーションにおいて、サブタイプは、ネストされたオブジェクトとして扱われる。

フラグメントのシーケンス。フラグメントは、特定のクラスのシリアライゼーションを構成するシーケンスでストアされる。オブジェクトのクラスに、プリミティブメンバだけが含まれる場合に、そのオブジェクトを、自己終端型の単一のフラグメントにシリアライズすることができる。複合メンバまたは他の非プリミティブメンバを有するクラスは、複数のフラグメントにシリアライズすることができる。あるクラスのシリアライゼーションに複数のフラグメントが含まれる場合に、１つまたは複数のターミネータフラグメントも生成することができる。開始フラグメントから最後のターミネータフラグメントまでのフラグメントのセットに、この説明で使用される意味でのフラグメントのシーケンスが含まれる。

あるインスタンスのサブタイプに対応するフラグメントは、基本型のフラグメントの下でネストすることができる。図３のｔＰｅｒｓｏｎ、ｔＥｍｐｌｏｙｅｅ、およびｔＰａｒｔＴｉｍｅＥｍｐｌｏｙｅｅの例を使用し、当面、各レベルにバイナリフラグメントによって記述されるプリミティブ属性だけがあると仮定すると、ｔＰａｒｔＴｉｍｅＥｍｐｌｏｙｅｅのインスタンスを、図１２によって提供される図で視覚的に示すことができる。図１２のｔＥｍｐｌｏｙｅｅおよびｔＰａｒｔＴｉｍｅＥｍｐｌｏｙｅｅのフラグメントを、ネスティングの同一のレベルに置くことができることに留意されたい。

シリアライゼーションの例
複数の潜在的なメンバ型、複数のフラグメントタイプ、およびフラグメントにメンバを置く例示的なルールのセットを示したので、本明細書で説明するシリアライゼーションフォーマットの実施形態を使用するシリアライズの例が有益になる。これに関して、図３に、複数の例のスキーマを示す。各スキーマは、オブジェクトのクラスを表し、それぞれが、様々な型の１つまたは複数のメンバを有する。この議論において、図３は、それぞれが名前ストリング（プリミティブメンバ）、年齢整数（やはりプリミティブメンバ）、および位置コレクション（これはネストされた複合メンバ）を有する、「ｐｅｒｓｏｎ」オブジェクトのクラスを提供する。図３は、それぞれが３つのプリミティブメンバ、ｓｔｒｅｅｔ（通り）、ｃｉｔｙ（都市）、およびｚｉｐ（郵便番号）を有する「ａｄｄｒｅｓｓ」オブジェクトを定義するクラスも提供する。図３は、ｐｅｒｓｏｎクラスを継承し、したがってｐｅｒｓｏｎクラスのメンバを含み、３つのプリミティブメンバ、すなわちｅｍｐｌｏｙｅｅ ｎｕｍｂｅｒ（従業員番号）、ｄｅｐａｒｔｍｅｎｔ（部署）、およびｐｈｏｔｏ（写真）（イメージはＬＯＢメンバである）も含むｅｍｐｌｏｙｅｅ（従業員）オブジェクトのクラスを提供する。ｐａｒｔ−ｔｉｍｅ ｅｍｐｌｏｙｅｅ（パートタイム従業員）クラスは、ｅｍｐｌｏｙｅｅクラスを継承し、したがって、ｅｍｐｌｏｙｅｅクラスのすべてのメンバ（ｐｅｒｓｏｎクラスから継承したメンバを含む）と、１つのプリミティブ、ｈｏｕｒｓ ｐｅｒ ｗｅｅｋ（週ごとの労働時間）を含む。

図３を参照して、この図のスキーマのインスタンスが、上で提供したフラグメントおよびルールを使用してどのようにシリアライズされるかを検討されたい。例えば、空でない住所のコレクションを有するｔＰｅｒｓｏｎのインスタンスは、次のフラグメントを次の順序で有することができる。

住所の空でないコレクションを有するｔＥｍｐｌｏｙｅｅのインスタンスは、次のフラグメントを次の順序で有することができる。

上の例示的なフラグメントシーケンスに関して、１つまたは複数のフラグメントでレコードフォーマットを利用する実施形態で望まれる可能性があるように、ストレージエンジンレコード作成／クラッキングコードの再利用をサポートするために、本明細書に記載のフラグメントベースシリアライゼーション技法と共に使用されるクラスのレベルが、サイズにおいて７キロバイト（７ｋ）を超えないことを要求することが好ましいことに留意されたい。上に示した例では、ｔＰｅｒｓｏｎ（関連する住所のコレクションを除く）が、サイズにおいて７キロバイト未満でなければならない。同様に、各ｔＡｄｄｒｅｓｓは、７ｋ未満でなければならない。この制限は、本発明を実践する最良の態様を示す法的要件に従うために開示されるが、本発明の実施にはより望ましくないものの、７ｋを超えるレベルを許容することが実現可能であることに留意されたい。この制限は、シリアライゼーションライブラリ（「ＳＬ」）によって、実行時に実施することができる。理解されるように、シリアライゼーションは、様々なフラグメントを認識し、解析する責任を負う。

上の例から、１つまたは複数のフラグメントにメンバを置くことによって、メンバを突き止める作業に、そのメンバが置かれた１つまたは複数のフラグメントを突き止めることが含まれることに留意されたい。そのようなフラグメントが複数ある場合に、最初のフラグメントを、最初に突き止めることができる。これに関して、シリアライゼーションの最初のフラグメントに対するフラグメントの位置を、メタデータから判定することができる。この技法は、フラグメントの直接のアドレッサビリティを提供しないが、関連するメンバが表すクラスの態様を識別するために各メンバのトークンを比較するという作業が、除去される。その代わりに、スキャンされる時に、シリアライゼーションメタデータは、適当なフラグメントをプロセッサに素早く指示することができる。

上の例示的なシリアライゼーションに示された本発明のもう１つの長所は、オブジェクトのシリアライゼーションを、１パスで達成できることである。シリアライザプロセスは、基本型からサブタイプおよび含むタイプへ、さらにネストされたタイプへと、トップダウンの形で進行することができる。ネスティングの各レベルで、シリアライザプロセスは、１つまたは複数のフラグメントを作ることができる。そのようなシリアライザは、前に生成されたフラグメントを更新する必要が絶対にないが、望まれる場合にはそうするように構成することができる。

固定長、可変長、およびビットタイプのプリミティブメンバ；他のオブジェクト内にネストされたオブジェクト；継承；インラインＬＯＢおよびアウトオブラインＬＯＢ（ファイルストリームを含む）；順序付けられたコレクション（ロケータ機能を介して適当な順序でのコレクション要素のシリアライゼーションを提供する）；順序付けられないコレクション；およびヌル値をサポートするように、本明細書に示されたシリアライゼーションフォーマットを構成できることを承認されたい。このシリアライゼーションフォーマットは、コンポーズ可能なシリアライゼーションもサポートすることができる。これに関して、ネストされたオブジェクトを、オブジェクトがシリアライズされたフラグメントコンテナのトレースなしですなわち、そのコンテナに対応する状態なしで、既存のシリアライゼーションから抽出することができる。本発明の実施形態のこのプロパティは、ネストされたオブジェクト全体の挿入または更新を可能にする。

また、上のシリアライゼーションの例から、提案されるシリアライゼーションフォーマットが、他の既存データの更新なしでのクラスへのメンバの追加をサポートすることに留意されたい。クラスへのフィールドの追加は、ＸＭＬスキーマの使用で非常に一般的であり、この場合に、スキーマは、しばしば、フィールドを追加することによって更新される。これに関して、新しいメンバが、ＮＵＬＬのデフォルト値を有し、既存の型の終りに追加される限り、すべてのタイプのフラグメントを変更して、新しいメンバ（プリミティブオブジェクト、コレクションオブジェクト、またはネストされたオブジェクト）を追加することができる。オブジェクトへの大きいメンバの追加は、レコードフォーマットシリアライゼーションのように心配する必要がない。というのは、提案されるフラグメントベースフォーマットでストアされるオブジェクトを、データベースの単一の列に「バイトのバッグ」としてストアすることができ、任意の大きさにすることができるからである。

上の例のシリアライゼーションで実施されるシリアライゼーションフォーマットのもう１つの利点は、フラグメントの識別を、フラグメントと共にストアする必要がないことである。その代わりに、フラグメントへのパスを使用して、フラグメントの識別を示すことができる。パスは、操作される所与のオブジェクトの型メタデータから判定することができる。パスは、シリアライゼーション内の特定のフラグメントを識別する。パスは、例えば、各ネスティングレベルおよび各サブタイプレベルでフラグメントを識別する、各フラグメントにある数のセットとすることができる。オブジェクトのフィールドが、事前に決定されたフラグメント内にあるので、これらを、パスを使用して突き止めることができる。ある意味で、パスは、フラグメントのアドレスのようなものである。パスは、フラグメントと一緒にストアすることができ、あるいは、最初にシリアライズされたフラグメントからナビゲートすることによって計算することができる。型の埋め込みおよびネスティングをサポートするために、パスは、ネスティングレベルおよびサブタイプレベルを考慮に入れたものとすることができる。

フラグメントベースのシリアライゼーションフォーマットは、オブジェクトをインスタンス化しない、メンバへのアクセスのサポートも可能にする。上で説明したように、パスをフラグメント識別子として使用することによって、メンバ突き止めプロセスまたはナビゲータが、任意の所望のフラグメントにナビゲートすることができる。フラグメントに位置決めされたならば、そのようなプロセスは、そのフラグメント自体へ、または突き止められたフラグメントをルートとするフラグメントのシーケンス全体へのアクセスを可能にすることができる。各フラグメントへのマップの形でシリアライゼーションへのディレクトリを提供することによって、フラグメントの突き止めを、さらに高速に達成することができる。そのようなディレクトリは、Ｂツリーとして編成されたテーブルにフラグメントをストアすることができる。そのような実施形態で、行ごとに１つのフラグメントをストアすることができ、各行のキーの一部としてフラグメントへのパスを使用できるようになる。

ナビゲータは、特定の動作に関して重要でないフラグメントを効率的にスキップすることもできる。本発明に従ってシリアライズされたフラグメントのナビゲーションに、オープンされたネスティングレベルの個数またはサブタイプ番号のいずれかの追跡を含めることができる。ナビゲータが、所望のネスティングレベルまたはサブタイプに達したならば、そのナビゲータは、そのレベルまたはサブタイプでフラグメントの個数をカウントすることができる。そのようなフラグメント自体が、ネスティングの新しいレベルを開始することができる。

さらに、フラグメントベースのフォーマットでシリアライズされたオブジェクトのメンバを突き止めることの利点を引き立たせて、プリミティブメンバへのアクセスに、次の単純な動作を含めることができる。まず、ナビゲータが、バイナリフラグメントを突き止めることができる。上で説明したように、プリミティブメンバは、有利なことに、そのようなフラグメントにストアされる。次に、要求されたメンバを、標準的な最適化されたレコードクラッキングコードを使用して抽出することができる。そのメンバを、標準的な最適化されたレコード作成コードを使用して更新することもできる。この単純な動作は、単一のデータベース列に便利にストアできるシリアライズされたオブジェクトのプリミティブメンバの高性能の突き止めを提供する。この形でメンバ突き止めを可能にすることの利点は、上で述べたように、ホストオブジェクト全体をインスタンス化する必要なしにメンバを更新できることである。これによって、オブジェクト全体をインスタンス化せずに、フラグメントまたはフラグメントのシーケンスを置換できるようになる。各フラグメントは、自己完結型とすることができ、フラグメントシーケンスの識別子が、ネスティングを開始するフラグメントおよびターミネータフラグメントの存在になるように、本発明を構成することができる。これによって、他の場所で長さをフィックスアップせずに更新を実行することが可能になり、標準的なレコードフォーマットシリアライゼーションのオフセットテーブルが回避される。

本明細書に示された技法に従って生成されるフラグメントのストリームのストレージは、ＬＯＢとしてフラグメントのストリームをストアすることによって行うことができる。そのようなＬＯＢは、そのキーがオフセット位置である、ツリー構造のストレージフォーマットを有することができる。フラグメントのストリームをストアするこの技法は、ＬＯＢのサイズに依存する、予測可能な挿入時間および削除時間を提供する。この技法は、ＬＯＢの一部だけの更新も可能にする。フラグメントにシリアライズされたオブジェクトのオンワイヤフォーマットは、フラグメントヘッダの形状に関してオンディスクフォーマットと同一である。ＬＯＢフラグメントおよびＦＳフラグメント以外のフラグメントの場合に、オンワイヤであるフラグメントとオンディスクであるフラグメントについて、変更はまったく不要である。本発明のこの態様によって、オブジェクトをワイヤに素早くコピーすることが可能になり、ある位置から別の位置にオブジェクトを転送する速度の大幅な向上がもたらされる。しかし、追加の柔軟性を提供するために、ＬＯＢフラグメントおよびＦＳフラグメントについて、フラグメント内容を変更できることに留意されたい。本発明のこの態様は、潜在的なフラグメントタイプの要約に関して上で説明した。

フラグメントシリアライズされたオブジェクトに対する動作
所与のフォーマットでシリアライズされたオブジェクトに対する動作実行の単純さ、効率、および柔軟性は、シリアライゼーションフォーマットの性能を評価する際の効果的な判断基準である。本明細書で説明する本発明の実施形態は、これに関する大きい利益の特徴がある。これは、このセクションで提供する技法を使用して動作が実行される時に、特にそうである可能性がある。しかし、次の動作のリストは、本発明の技法に従ってシリアライズされたオブジェクトに対する可能な動作の網羅的リストと考えてはならず、そのような動作を実行する網羅的な形での動作技法の説明でもないことに留意されたい。次の動作は、参照を簡単にするために番号を付けられているが、これは、動作の実行の順序またはシーケンスを示すものではない。そうではなく、これらの動作のそれぞれを、独立にまたは他の動作と共に実行することができる。

本発明の利点の１つが、図９のように、データベースのテーブルの単一の列にオブジェクトをストアすることができると同時に、オブジェクト内のメンバに関する高性能の検索機能および更新機能を可能にすることである。これに関して、図９に、データベースの単一の列にあるオブジェクトの類別を示す。本明細書に記載の本発明の様々な実施形態によれば、オブジェクトは、レコードフォーマットのプリミティブデータを含む第１フラグメント（これは、副分割されたペイロードの灰色のフラグメントである）と、この説明で示すフラグメントのいずれかとすることができる後続フラグメントを用いてシリアライズされる。シリアライズされたオブジェクトに対する動作の次の説明では、本発明の実施形態がデータベースの列にストアされるシナリオについて、図９を参照されたい。

次の例示的な動作を、一般的なユーザ定義型（「ＵＤＴ」）オブジェクトと、そのようなオブジェクトをシリアライズするように設計された本発明の特定の実施形態に関して説明する。フラグメントストリームとしてストアされたＵＤＴオブジェクトに対して実行できる動作の基本的なアルゴリズムを提供する。

動作１：オブジェクトを、そのパスを使用して一意に識別する。ＵＤＴが、フラグメントのシーケンスとしてストアされている時に、シーケンス内の各フラグメントを、「パス」によって一意に識別することができる。パスは、ステップのシーケンスであり、各ステップは、正確に次のうちの１つとすることができる。

１．非プリミティブフィールドを示すフラグメントＩＤを指定する、ネスティングステップ：ＵＤＴの各非プリミティブフィールドに、一意のフラグメントＩＤを割り当てる。フラグメントＩＤは、１から始まる。これには、次が含まれる。

・ ラージオブジェクト（ＬＯＢ）（無制限の長さまたは非常に大きい長さを有する文字／バイナリデータなど）である、その中のフィールド。これらのフィールドのそれぞれは、別々のフラグメントとしてストアされる。

・ ファイルストリームすなわちファイルへのポインタである、その中のフィールド。このファイルに、実際のデータが含まれ、このファイルは、データベースの外にある。これらのフィールドのそれぞれが、別々のフラグメントとしてストアされる。

・ 別のＵＤＴ（別のＵＤＴ内でのＵＴＤのネスティングを、ＵＤＴのコンポジションとも称する）または別のＵＤＴのコレクションとすることができる、その中のフィールド。例えば、ＵＤＴ Ａが、型ＵＤＴ Ｂのフィールドｂを有することができる。この場合に、ｂを、単一の自己終端フラグメントとしてストアすることができ、あるいは、Ｂが非プリミティブフィールドであるか別のＵＤＴのサブタイプである場合に、フラグメントのシーケンスとしてストアすることができる。

フラグメントＩＤを割り当てる時に、スーパータイプから継承した非プリミティブフィールドを考慮する必要がないことに留意されたい。したがって、ＵＤＴ ＱがＵＤＴ Ｐのサブタイプである場合に、ＵＤＴ Ｑの非プリミティブフィールドにフラグメントＩＤを割り当てる時に、ＱがＰのすべてのフィールドを継承してはいるが、Ｐのフィールドは考慮しない。

また、ＵＤＴの非プリミティブフィールドが、そのフラグメントＩＤの昇順でレイアウトされることに留意されたい。

２．深さを指定する継承ステップ：これは、フラグメントがどのサブタイプセクションに置かれるかを告げる。基本型のプリミティブフィールドおよび非プリミティブフィールドが、そのサブタイプの前にレイアウトされることを想起されたい。ＵＤＴ Ｒが、ＵＤＴ Ｑのサブタイプであり、ＵＤＴ Ｑが、ＵＤＴ Ｐのサブタイプであると仮定する。型Ｒのオブジェクトのレイアウトは、次のようになる。

２の深さを指定する継承ステップは、Ｑのセクションを示し、３の深さを示す継承ステップは、Ｒのセクションを示す。Ｐのセクションを示すために、継承ステップは必要でない。

３．ロケータを指定するコレクションメンバステップ：（ロケータは、コレクションのメンバを一意に識別する。コレクションのメンバは、１から始まるロケータを割り当てられる。コレクションメンバが削除される時に、ロケータに「ギャップ」が生じ、挿入される後続のメンバが、そのロケータを再利用する。したがって、メンバが削除されていない場合に、Ｎ個のメンバを有するコレクションのメンバは、ロケータ１からＮを有する）。ＵＤＴ ＡがＵＤＴ Ｃのコレクションである場合に、２つのメンバを含む型Ａのオブジェクトが、次のようになることを想起されたい。

メンバ１のロケータを指定するコレクションメンバステップは、メンバ１のセクションを示し、メンバ２のロケータを指定するコレクションメンバステップは、メンバ２のセクションを示す。

複合ＵＤＴ内のフラグメントは、ネスティングステップ、ロケータステップ、および継承ステップの適当な順列を用いて一意に突き止めることができる。

Ｓ１、Ｓ１、Ｓ２、．．．、Ｓｎの順番のｎ個のステップからなるパスを、Ｓ１．Ｓ２．．．Ｓｎと表す。また、Ｐがパスである場合に、Ｐのステップ数に表記ｓｉｚｅ（Ｐ）、Ｐのｉ番目のステップに表記Ｐ［ｉ］を使用し、ｉ＞０である。

動作２。バイトストリーム上でのフラグメントストリームの実施。データベースは、長年にわたって、制限付きの長さおよび無制限の長さの文字／バイナリデータをサポートしてきた。文字／バイナリデータの上でバイトストリームインターフェースを提供することは、既知の技術である。バイトストリームインターフェースに、次のような方法が含まれる。

１．ある指定されたオフセット「ｓ」から始めて「ｎ」バイトを読み取る。

２．ある指定されたオフセット「ｓ」から始めて「ｎ」バイトを挿入する。概念上、オフセット「ｓ」から始まる既存データが、「ｎ」バイトだけシフトされ、作成された「ギャップ」が、供給される「ｎ」バイトで満たされる。しかし、バイトストリームが大きい時に、実装は、膨大な量のデータを実際にシフトしないのに十分にスマートである。実装は、バイトストリームの上で作られるインデックス構造を使用してこれを達成する。

３．読み取られるデータが、バイトストリームインターフェースをサポートするオブジェクトの形で要求される、１の変形形態。

４．挿入される新しいデータが、バイトストリームインターフェースをサポートする別のオブジェクトの形で提供される、２の変形形態。

５．指定されたオフセット「ｓ」から始まる「ｎ」バイトを、供給されるデータに置換する。供給されるデータを「空」にすることができ、その場合に、その効果が、オフセット「ｓ」から始まる「ｎ」バイトを除去することであることに留意されたい。

６．新しいデータが、バイトストリームインターフェースをサポートするオブジェクトの形で提供される、５の変形形態。

上のリストが、網羅的であるのではなく代表的であることを意図されていることに留意されたい。前に述べたように、ＵＤＴは、フラグメントストリームとしてストアされる。フラグメントストリームは、バイトストリームの上で実施することができる。

動作３：パス情報からのフラグメントの突き止め。ＵＤＴを表すフラグメントストリームを検討されたい。このセクションでは、その所与のパス内でフラグメントをどのように突き止めるかを説明する。

パスが有効である場合に、途中でヌルＵＤＴに出会う時を除いて、パスに対応するフラグメントが見つからなければならず、ヌルＵＤＴに出会った場合には、さらにトラバースすることができず、フラグメントが見つからなかったと考えることができる。例えば、「ｄｅｐａｒｔｍｅｎｔ」ＵＤＴ内で「ｍａｎａｇｅｒ」フィールドを探す時に、「ｄｅｐａｒｔｍｅｎｔ」オブジェクト自体のフラグメントがヌルフラグメントである場合に、この方法は、「ｍａｎａｇｅｒ」のフラグメントが見つからなかったことを示すためにＦＡＬＳＥを返す。

スキーマエボリューションが、パスが有効である場合であってもパスに対応するフラグメントがない可能性があるもう１つの状況を導入することに留意されたい。次は、ＬｏｃａｔｅＦｒａｇｍｅｎｔの基本的なアルゴリズムである。当初に、ＦｒａｇｍｅｎｔＳｔｒｅａｍオブジェクトのｃｕｒｒｅｎｔＰａｔｈが、空のパスであり、現在のフラグメントが、最初のフラグメントである。

ＦｒａｇｍｅｎｔＳｔｒｅａｍ：：ＡｄｖａｎｃｅＴｉｌｌＳｔｅｐ（）。フラグメントをさらに突き止めるために、「ａｄｖａｎｃｅ ｔｉｌｌ ｓｔｅｐ（ステップまで前進）」動作も使用することができる。このメソッドでは、次のルールに従って２つのステップを比較する。第１に、「ネスティングステップ」が別の「ネスティングステップ」より小さいのは、前者のフラグメントＩＤが後者のフラグメントＩＤより小さい場合である。第２に、「継承ステップ」が別の「継承ステップ」より小さいのは、前者の深さが後者の深さより小さい場合である。第３に、「ロケータステップ」が別の「ロケータステップ」より小さいのは、前者のロケータが後者のロケータより小さい場合である。第４に、「ネスティングステップ」は、必ず「継承ステップ」より小さい（サブタイプからのフィールドの前にすべてのネストされたフィールドをストアするので）。最後に、「ロケータステップ」は、「ネスティングステップ」または「継承ステップ」と比較できず、そのような比較を試みることは、エラーである。例えば、次のアルゴリズムを参照されたい。

ＦｒａｇｍｅｎｔＳｔｒｅａｍ：：ＧｅｔＮｅｘｔＦｒａｇｍｅｎｔ（）。さらに、次のフラグメントを得る動作を、次のように実装することができる。

動作４：プリミティブフィールドの選択。プリミティブフィールドの選択には、まずパスを使用してプリミティブフィールドを含むフラグメントを突き止めることが含まれる。このフラグメントのペイロードは、レコードフォーマットであり、プリミティブフィールドを有する。次に、標準的な最適化されたレコード操作コードを使用して、ペイロードからプリミティブフィールドを抽出することができる。

動作５：プリミティブフィールドの更新。プリミティブフィールドの更新は、３つのステップで達成することができる。まず、プリミティブフィールドを選択するのと同一の形で、プリミティブフィールドを含むフラグメントを、そのパスを使用して突き止める。次に、フラグメントのペイロードのコピーを作り、標準的な最適化されたレコード操作コードを使用して、更新が必要なプリミティブフィールドの古い値を新しい値に置換する。これによって、新しいペイロードが与えられ、これは、オリジナルのペイロードより長いまたはより短いものとすることができる。第３に、古いペイロードを新しいペイロードに置換することによって、フラグメントを更新する。これによって、フラグメントの長さが増えるか減る場合があり、その長さを、それ相応に調整しなければならないことに留意されたい。

動作６：埋め込まれたＵＤＴ全体のコピー。埋め込まれたＵＤＴ全体のコピーには、まず、上で示したｌｏｃａｔｅＦｒａｇｍｅｎｔ（）を使用して、埋め込まれたＵＤＴのパスから埋め込まれたＵＤＴの先頭をマークするフラグメントを見つけることが含まれる。第２に、下で説明するＣｏｐｙＯｕｔＦｒａｇｍｅｎｔＳｅｑｕｅｎｃｅ（）関数を使用して、埋め込まれたＵＤＴに属するフラグメントをコピーすることができる。

さらに、ＵＤＴをコピーするために、次の基本的なアルゴリズムを使用して、ＦｒａｇｍｅｎｔＳｔｒｅａｍ：：ＣｏｐｙＯｕｔＦｒａｇｍｅｎｔＳｅｑｕｅｎｃｅ（）関数を使用することができる。

さらに、ナビゲーション継続関数「ＦｒａｇｍｅｎｔＳｔｒｅａｍ：：ＣａｎＣｏｎｔｉｎｕｅＮａｖｉｇａｔｉｏｎ（）」は、次の基本的なアルゴリズムに従うものとすることができる。

動作７：埋め込まれたＵＤＴのすべてのフラグメントの除去。ＣｏｐｙＯｕｔＦｒａｇｍｅｎｔＳｅｑｕｅｎｃｅ（）に似たメソッドＤｅｌｅｔｅＦｒａｇｍｅｎｔＳｅｑｕｅｎｃｅ（）が、埋め込まれたＵＤＴに属するすべてのフラグメントを除去するために設けられている。フラグメントごとに、基礎になるＢｙｔｅＳｔｒｅａｍクラスを使用して、そのフラグメントのバイトを除去することができる。フラグメントがファイルストリームフラグメントである場合には、基礎になるファイルを実際に削除するために、特殊な処理が必要である。

動作８：新しいＵＤＴによる埋め込まれたＵＤＴの更新。本発明人が「ＦｒａｇｍｅｎｔＳｔｒｅａｍ：：ＲｅｐｌａｃｅＦｒａｇｍｅｎｔＳｅｑｕｅｎｃｅ（）」と呼ぶアルゴリズムは、まず、埋め込まれたＵＤＴを、そのパスを使用して突き止め、次に、ＤｅｌｅｔｅＦｒａｇｍｅｎｔＳｅｑｕｅｎｃｅ（）を使用して、埋め込まれたＵＤＴに属するすべてのフラグメントを削除し、最後に、新しいＵＤＴのフラグメントを読み取り、現在位置に挿入することができる。やはり、基礎になるＢｙｔｅＳｔｒｅａｍクラスを使用して、新しいフラグメントのバイトを置くことができる。ファイルストリームフラグメントを挿入するためには、適当なデータを用いてファイルを作成する必要があり、そのファイルへのポインタをフラグメントに置く必要があるので、特殊な処理が必要である。

動作９：コレクションメンバの挿入。オブジェクトＢを表すＦｒａｇｍｅｎｔＳｔｒｅａｍオブジェクト内のコレクションのメンバとして、ＦｒａｇｍｅｎｔＳｔｒｅａｍオブジェクトの形で提供されるＵＤＴオブジェクトＡを挿入することを検討されたい。次のアルゴリズムを、本発明人はＦｒａｇｍｅｎｔＳｔｒｅａｍ：：ＩｎｓｅｒｔＣｏｌｌｅｃｔｉｏｎＥｌｅｍｅｎｔ（）と呼び、これは、まず、コレクションへのパスを使用して、Ｂ内のコレクションを突き止める。次に、ロケータおよび挿入の位置を見つける。前に述べたように、コレクションメンバが以前に削除された場合に、これによって、ロケータ内の「ギャップ」がもたらされる。そのようなギャップが存在する場合に、未使用ロケータが、新しいメンバに割り当てられ、新しいメンバは、すべてのメンバがロケータの昇順でレイアウトされるように挿入される。そうでない場合には、新しいメンバは、最後のメンバより１つ大きいロケータが割り当てられ、最後のメンバの後に挿入される。Ａの最初のフラグメントを、ロケータを置くために変更しなければならないことに留意されたい。

動作１０：コレクションメンバの削除。本発明人が「ＦｒａｇｍｅｎｔＳｔｒｅａｍ：：ＤｅｌｅｔｅＣｏｌｌｅｃｔｉｏｎＥｌｅｍｅｎｔ（）」と呼ぶアルゴリズムは、メンバのロケータを使用して、削除されるメンバを指定することができる。削除には、まず、パスを使用してコレクションを突き止めることと、次に、コレクション内で削除されるメンバを突き止めることが含まれる。ここで、ロケータステップを扱っているだけなので、パスを与えられてフラグメントを突き止めるというより単純な問題であることに留意されたい。したがって、ＬｏｃａｔｅＦｒａｇｍｅｎｔメソッドに類似するロジックを、これに使用することができる。次に、削除されるメンバに属する最初のフラグメントに位置したならば、ＤｅｌｅｔｅＦｒａｇｍｅｎｔＳｅｑｕｅｎｃｅを呼び出す。

動作１１：コレクション全体または単一のコレクションメンバの更新。異なるコレクションによるコレクション全体の置換は、別のＵＤＴによる埋め込まれたＵＤＴの置換と同一の形で行われる。同様に、コレクションメンバを突き止めたならば、そのメンバの更新は、埋め込まれたＵＤＴの更新と同一の形で行うことができる。

動作１２：ＵＤＴの複数のフィールドの選択または更新。複数のフィールドを選択または更新する時に、次の最適化が実行される。まず、選択／更新を順序付ける。２つのステップの比較および順序付けは、上で説明した。パスを、ステップのストリングと考えることができ、「辞書編集」順序付けを、パスに対して定義することができる。次のアルゴリズムを参照されたい。

フィールドは、それを含むフラグメントへのパスの昇順で選択または更新される。この順序付けが、フラグメントがフラグメントストリームに現れるのと同一の順序であることに留意されたい。複数のプリミティブフィールドが、同一のフラグメント内で突き止められる可能性がある。その場合に、それらを含むフラグメントを訪問したならば、標準的なレコード操作コードを使用して、そのフラグメントをもう一度訪れる必要なしに、すべての所望のフィールドを効率的に選択または更新する。これを行うことによって、複雑なＵＤＴ内であっても、そのＵＤＴのすべての所望のフィールドを選択または更新するために、そのフラグメントストリーム上で多くとも１つのパスが必要である。

動作１３：現在位置を使用するためのＬｏｃａｔｅＦｒａｇｍｅｎｔの機能強化：ＬｏｃａｔｅＦｒａｇｍｅｎｔアルゴリズムの前の説明は、必ずフラグメントストリームに先頭で開始された。しかし、選択または更新が必要な最初のフィールドを含むフラグメントを突き止める場合に限って、ＬｏｃａｔｅＦｒａｇｍｅｎｔを先頭から開始する必要がある。選択または更新が必要な後続フィールドを含むフラグメントを突き止めるために、ｌｏｃａｔｅＦｒａｇｍｅｎｔは、現在位置から開始することができる。ＬｏｃａｔｅＦｒａｇｍｅｎｔに必要な機能強化を、下で短く述べる。２つの基本的な事例がある。

１．ｃｕｒｒｅｎｔＰａｔｈ＝＝ｐｒｅｆｉｘ（ｔａｒｇｅｔＰａｔｈ）すなわちｃｕｒｒｅｎｔＰａｔｈのすべてのステップが、ｔａｒｇｅｔＰａｔｈのステップと一致するが、ターゲットパスが、追加のステップを有する。この場合に、ｌｏｃａｔｅＦｒａｇｍｅｎｔは、ｉ＝０の反復から開始するのではなく、Ｉ＝ｓｉｚｅ（ｃｕｒｒｅｎｔＰａｔｈ）＋１の反復から開始することができる。

２．あるｋ＜ｓｉｚｅｏｆ（ｃｕｒｒｅｎｔＰａｔｈ）に関して、ｃｕｒｒｅｎｔＰａｔｈの最初のｋ個のステップが、ｔａｒｇｅｔＰａｔｈと一致するが、ｋ＋１番目のステップが一致しない。この場合に、パスが既に昇順でソートされているので、ｃｕｒｒｅｎｔＰａｔｈ［ｋ＋１］＜ｔａｒｇｅｔＰａｔｈ［ｋ＋１］でなければならないことに留意されたい。この場合にも、ｌｏｃａｔｅＦｒａｇｍｅｎｔは、ｉ＝ｋ＋１の反復のＡｄｖａｎｃｅＴｉｌｌＳｔｅｐから開始することができる。

動作１４：レイジイマテリアライゼーション（ｌａｚｙ ｍａｔｅｒｉａｌｉｚａｔｉｏｎ）。ＵＤＴのシリアライゼーションをサーバからクライアントに送る時に、ＬＯＢデータおよびファイルストリームフィールドからのファイルデータを送ることが、最も時間のかかる要因になる傾向がある。したがって、フラグメントストリームマネージャは、「レイジイマテリアライゼーション」オプションを提供することができる。

ＵＤＴのシリアライゼーションが、レイジイマテリアライゼーションオプション付きで要求される時に、「クッキー」が、ＬＯＢ／ファイルストリームデータの代わりに返される。呼出し側は、その後、ＬＯＢ／ファイルストリームフラグメントのパスおよび「クッキー」を渡すことによって、完全なＬＯＢ／ファイルストリームデータを要求することができる。パスおよびクッキーは、フラグメントストリームマネージャがＬＯＢ／ファイルストリームデータを取り出すのに十分な情報を与える。

動作１５：スキーマエボリューション（ｓｃｈｅｍａ ｅｖｏｌｕｔｉｏｎ）。スキーマエボリューションは、ＵＤＴのフィールドの追加、除去、または変更（フィールドのデータ型の変更など）によるＵＤＴの変更または新しいＵＤＴなどを定義することによる継承階層の変更を指す。そのような変更は、既に永続しているＵＤＴのインスタンスに影響する可能性がある。単純な解決策は、既存フィールドに割り当てられたフィールドＩＤおよびフラグメントＩＤのすべてが、新しいフィールドが追加された時に同一のままになるようにすることである。その後、すべての事前に存在する永続したＵＤＴのインスタンスを変更せずに、ＵＤＴへの新しいフィールドの追加をサポートすることができる。

最後に、本明細書で説明した様々な技法を、ハードウェアまたはソフトウェアに関して、あるいは適当な場合にこの両方の組み合わせに関して実施できることを理解されたい。したがって、本発明の方法および装置、またはそのある態様または部分が、フロッピディスク、ＣＤ−ＲＯＭ、ハードドライブ、または他の機械可読記憶媒体などの有形の媒体で実施されるプログラムコード（すなわち命令）の形をとることができ、このプログラムコードが、コンピュータなどの機械にロードされ、これによって実行される時に、その機械が、本発明を実践するための装置になる。プログラマブルコンピュータでのプログラムコード実行の場合に、コンピューティングデバイスに、一般に、プロセッサ、プロセッサによって可読の記憶媒体（揮発性および不揮発性のメモリおよび／または記憶要素を含む）、少なくとも１つの入力デバイス、および少なくとも１つの出力デバイスが含まれる。例えばデータ処理ＡＰＩ、再利用可能なコントロール、または類似物の使用を介するなど、本発明のユーザインターフェース技法を実施または使用することができる１つまたは複数のプログラムは、コンピュータシステムと通信するために、高水準手続き指向プログラミング言語または高水準オブジェクト指向プログラミング言語で実施されることが好ましい。しかし、望まれる場合に、プログラムをアセンブリ言語または機械語で実施することができる。どの場合でも、言語は、コンパイルされる言語または解釈される言語とすることができ、ハードウェア実施形態と組み合わせることができる。

例示的な実施形態で、１つまたは複数の独立型コンピュータシステムの文脈で本発明を使用することに言及したが、本発明は、それに制限されるのではなく、ネットワーク環境または分散コンピューティング環境などの任意のコンピューティング環境に関して実施することができる。さらに、本発明を、複数の処理チップまたは処理デバイス内あるいはこれらにまたがって実施することができ、ストレージを、同様に、複数のデバイスにまたがってもたらすことができる。そのようなデバイスに、パーソナルコンピュータ、ネットワークサーバ、ハンドヘルドデバイス、スーパーコンピュータ、または自動車もしくは航空機などの他のシステムに統合されたコンピュータを含めることができる。したがって、本発明は、単一の実施形態に制限されるのではなく、付属の特許請求の範囲による広がりおよび範囲で解釈されなければならない。

付録Ａ：フラグメント検証プロセス
次のアルゴリズムは、フラグメントを検証するのに使用できるトップレベルコンピュータプロセスコマンドを表す。

フラグメント検証コードの代替レイアウトを、下に示すが、ここでは、シリアライゼーションの文法が、バッカスナウア表記（「ＢＮＦ」）で示されている。

引用符“”の中のシンボルは、ターミナルである。例えば、“ｓｅｌｆ−ｔｅｒｍｉｎａｔｉｎｇ ｂｉｎ ｆｒａｇ”は、ターミナルを表す。様々なターミナルシンボルは、前のセクションで定義されている。

かぎ括弧＜＞の中のシンボルは、非ターミナルである。例えば、＜ｃｏｎｔａｉｎｍｅｎｔ ｆｒａｇ＞は、非ターミナルである。

大括弧｛｝の中のシンボルは、そのシンボルが０回以上繰り返される可能性があることを示す。例えば、｛＜ｃｏｎｔａｉｎｍｅｎｔ ｆｒａｇ＞｝は、＜ｃｏｎｔａｉｎｍｅｎｔ ｆｒａｇ＞の０個以上のインスタンスがある可能性があることを示す。

注釈フラグメントは、ストリーム内のどこにでも存在することができる。

オブジェクトメンバをシリアライズするのに使用できる様々なフラグメントを示す概念図である。レコードフォーマットでプリミティブメンバを含むペイロードを有するバイナリフラグメント、非レコードフォーマットペイロードを有するフラグメント、およびペイロードを有しないフラグメントを示す。 フラグメントヘッダの詳細な表示を有するフラグメントを示す図である。ヘッダに、フラグメントヘッダでの使用に関する潜在的なフィールドの選択が示され、多数のフラグメントヘッダで、図示のフィールドの一部を省略することができる。 本発明の様々な実施形態による、そのためにこの説明でフラグメントシーケンスが提供される複数の例示的なオブジェクトクラスを示す図である。 オブジェクトにネストされたメンバがない時の、オブジェクトのプリミティブメンバのフラグメントを生成するステップを示す流れ図である。 オブジェクトにネストされたメンバがある時の、オブジェクトのプリミティブメンバのフラグメントを生成するステップを示す流れ図である。 オブジェクトのコレクションメンバのフラグメントを生成するステップを示す流れ図である。 オブジェクトのＬＯＢメンバおよびＦＳメンバのフラグメントを生成するステップを示す流れ図である。 様々な型のメンバを有するオブジェクト全体をフラグメントに置く処理のステップを示す流れ図である。 データベースの単一の列にストアできる時の、本発明の様々な実施形態に従ってシリアライズされたオブジェクトを示す図である。 メタデータが、すべてのレコードについて提供され、対応するデータがメタデータで指定されるフォーマットに従う、従来技術のレコードシリアライゼーションフォーマットを示す図である。 本発明の好ましい実施形態による、データをシリアライズする際に使用される様々なフラグメントタイプを示す図である。 本発明の好ましい実施形態による、データをシリアライズする際に使用される様々なフラグメントタイプを示す図である。 本発明の好ましい実施形態による、データをシリアライズする際に使用される様々なフラグメントタイプを示す図である。 本発明の好ましい実施形態による、データをシリアライズする際に使用される様々なフラグメントタイプを示す図である。 本発明の好ましい実施形態による、データをシリアライズする際に使用される様々なフラグメントタイプを示す図である。 本発明の好ましい実施形態による、データをシリアライズする際に使用される様々なフラグメントタイプを示す図である。 本発明の好ましい実施形態による、データをシリアライズする際に使用される様々なフラグメントタイプを示す図である。 本発明の好ましい実施形態による、データをシリアライズする際に使用される様々なフラグメントタイプを示す図である。 図３に示されたｔＰａｒｔＴｉｍｅＥｍｐｌｏｙｅｅオブジェクトのフラグメントシーケンスを示すトップレベルの図である。このフラグメントシーケンスに、ネスティングのレベルごとに追加のフラグメントを含めることができる。

Claims (37)

1. 複数のシーケンシャルにストアされたバイトと、
   前記複数のシーケンシャルにストアされたバイト内で表される少なくとも１つのデータメンバであって、データ型に関連する、少なくとも１つのデータメンバと、
   前記少なくとも１つのデータメンバの前記データ型を識別するのに使用される、前記複数のシーケンシャルにストアされたバイト内の少なくとも１つのタイプバイトであって、前記少なくとも１つのデータメンバに実質的に隣接して配置される、少なくとも１つのタイプバイトと
   を含むことを特徴とする、データオブジェクトとして一緒にストアされる１つまたは複数のデータメンバ。
2. 前記少なくとも１つのデータメンバは、レコードフォーマットでストアされ、前記レコードフォーマットは、前記少なくとも１つのタイプバイトに関する前記少なくとも１つのデータメンバの予測可能な位置を定義することを特徴とする請求項１に記載の１つまたは複数のデータメンバ。
3. 前記少なくとも１つのデータメンバの長さを識別するのに使用される、前記シーケンシャルにストアされた複数のバイトの少なくとも１つの長さバイトをさらに含むことを特徴とする請求項１に記載の１つまたは複数のデータメンバ。
4. 前記少なくとも１つのデータメンバは、前記データオブジェクトに関連するデータの位置を示し、前記位置は、位置タイプに関連し、前記複数のシーケンシャルにストアされたバイトの少なくとも１つの位置バイトは、前記位置タイプを識別するのに使用されることを特徴とする請求項１に記載の１つまたは複数のデータメンバ。
5. 前記少なくとも１つのタイプバイトは、前記複数のシーケンシャルにストアされたバイトの第１バイトであり、前記データオブジェクトの始めを示すことを特徴とする請求項１に記載の１つまたは複数のデータメンバ。
6. 前記少なくとも１つのタイプバイトは、データオブジェクトの型を示すことを特徴とする請求項５に記載の１つまたは複数のデータメンバ。
7. 前記データ型は、ラージオブジェクト（「ＬＯＢ」）を除外したプリミティブデータ型、ラージオブジェクト（「ＬＯＢ」）データ型、ファイルストリーム（「ＦＳ」）データ型、およびコレクション要素データ型を含む群から選択されることを特徴とする請求項１に記載の１つまたは複数のデータメンバ。
8. 前記少なくとも１つのデータメンバは、ＬＯＢを除外したプリミティブデータ型に関連する場合に、前記少なくとも１つのデータメンバは、レコードフォーマットでストアされ、前記レコードフォーマットは、前記少なくとも１つのタイプバイトに関する前記少なくとも１つのデータメンバの予測可能な位置を定義することを特徴とする請求項７に記載の１つまたは複数のデータメンバ。
9. 前記少なくとも１つのタイプバイトは、前記少なくとも１つのデータメンバが前記データオブジェクトの唯一の１つまたは複数のメンバであることを示すことを特徴とする請求項１に記載の１つまたは複数のデータメンバ。
10. 前記複数のシーケンシャルにストアされたバイト内の少なくとも１つのコレクション開始バイトをさらに含み、前記少なくとも１つのコレクション開始バイトは、前記少なくとも１つのコレクション開始バイトに実質的に隣接してストアされた関連する一連のデータメンバの先頭を示すのに使用されることを特徴とする請求項１に記載の１つまたは複数のデータメンバ。
11. 前記複数のシーケンシャルにストアされたバイト内の少なくとも１つのターミネータバイトをさらに含み、前記少なくとも１つのターミネータバイトは、シリーズデータメンバの終りを示すのに使用されることを特徴とする請求項１に記載の１つまたは複数のデータメンバ。
12. データメンバのコレクションの一部である第１データメンバに関連する、前記複数のシーケンシャルにストアされたバイト内の少なくとも１つのバイトをさらに含み、前記少なくとも１つのバイトは、データメンバの前記コレクションの一部である第２データメンバに関する情報を提供することを特徴とする請求項１に記載の１つまたは複数のデータメンバ。
13. 前記少なくとも１つのデータメンバに実質的に隣接してストアされた少なくとも１つのバイナリツリー（「ｂツリー」）番号をさらに含むことを特徴とする請求項１に記載の１つまたは複数のデータメンバ。
14. 少なくとも１つのデータメンバからなるデータオブジェクトをストアするか伝送する方法であって、
    複数のシーケンシャルにストアされたバイト内で少なくとも１つのデータメンバを表すことであって、前記少なくとも１つのデータメンバは、データ型に関連することと、
    前記複数のシーケンシャルにストアされたバイト内の少なくとも１つのバイトを、前記少なくとも１つのデータメンバの型情報を識別すること専用にすることであって、前記少なくとも１つのバイトは、前記少なくとも１つのデータメンバに実質的に隣接して配置されることと
    を含むことを特徴とする方法。
15. 前記少なくとも１つのデータメンバを表すことは、レコードフォーマットで行われ、前記レコードフォーマットは、前記少なくとも１つのタイプバイトに関する前記少なくとも１つのデータメンバの予測可能な位置を定義することを特徴とする請求項１４に記載の方法。
16. 前記複数のシーケンシャルにストアされたバイトの少なくとも１つのバイトを、前記少なくとも１つのデータメンバの長さを識別すること専用にすることをさらに含むことを特徴とする請求項１４に記載の方法。
17. 前記少なくとも１つのデータメンバは、前記データオブジェクトに関連するデータの位置を示し、前記位置は、位置タイプに関連し、前記複数のシーケンシャルにストアされたバイトの少なくとも１つの位置バイトは、前記位置タイプを識別するのに使用されることを特徴とする請求項１４に記載の方法。
18. 前記少なくとも１つのバイトは、前記複数のシーケンシャルにストアされたバイトの第１バイトであり、前記データオブジェクトの始めを示すことを特徴とする請求項１４に記載の方法。
19. 前記少なくとも１つのタイプバイトは、データオブジェクトの型を示すことを特徴とする請求項１４に記載の方法。
20. 前記データ型は、ラージオブジェクト（「ＬＯＢ」）を除外したプリミティブデータ型、ラージオブジェクト（「ＬＯＢ」）データ型、ファイルストリーム（「ＦＳ」）データ型、およびコレクション要素データ型を含む群から選択されることを特徴とする請求項１４に記載の方法。
21. 前記少なくとも１つのデータメンバは、ＬＯＢを除外したプリミティブデータ型に関連する場合に、前記少なくとも１つのデータメンバは、レコードフォーマットでストアされ、前記レコードフォーマットは、前記少なくとも１つのタイプバイトに関する前記少なくとも１つのデータメンバの予測可能な位置を定義することを特徴とする請求項２０に記載の方法。
22. 前記少なくとも１つのタイプバイトは、前記少なくとも１つのデータメンバが前記データオブジェクトの唯一の１つまたは複数のメンバであることを示すことを特徴とする請求項１４に記載の方法。
23. 前記複数のシーケンシャルにストアされたバイト内の少なくとも１つのバイトを、前記少なくとも１つのコレクション開始バイトに実質的に隣接してストアされる一連の関連するデータメンバの始めをマークすること専用にすることをさらに含むことを特徴とする請求項１４に記載の方法。
24. 前記複数のシーケンシャルにストアされたバイト内の少なくとも１つのターミネータバイトをさらに含み、前記少なくとも１つのターミネータバイトは、シリーズデータメンバの終りを示すのに使用されることを特徴とする請求項１４に記載の方法。
25. 前記複数のシーケンシャルにストアされたバイト内の少なくとも１つのバイトを、データメンバの前記コレクションの一部である第２データメンバに関する情報を提供すること専用にすることをさらに含み、前記少なくとも１つのバイトは、データメンバのコレクションの一部である第１データメンバに関連することを特徴とする請求項１４に記載の方法。
26. 請求項１４に記載の方法を実行する命令を含むことを特徴とするコンピュータ可読媒体。
27. 請求項１４に記載の方法を実行する命令を含むことを特徴とする変調されたデータ信号。
28. １つまたは複数のデータメンバからなるデータオブジェクトをストアまたは伝送する方法であって、
    複数のシーケンシャルに置かれたバイトを少なくとも１つのヘッダセクションおよび少なくとも１つのペイロードセクションに分割することであって、前記少なくとも１つのヘッダセクションおよび前記少なくとも１つのペイロードセクションは、互いに隣接して置かれることと、
    前記ペイロードセクション内で少なくとも１つのデータメンバを表すことであって、前記少なくとも１つのデータメンバは、データ型に関連することと、
    前記ヘッダセクション内で前記データ型を表すことと、
    前記少なくとも１つのデータメンバをレコードフォーマットで前記ペイロードセクションに置くことであって、前記レコードフォーマットは、前記ペイロードセクション内の他のメンバに関する前記少なくとも１つのデータメンバの予測可能な位置を定義することと
    を含むことを特徴とする方法。
29. 前記少なくとも１つのデータメンバは、プリミティブデータ型に関連することを特徴とする請求項２８に記載の方法。
30. 前記ヘッダセクション内でペイロード長さを表すことをさらに含むことを特徴とする請求項２８に記載の方法。
31. 前記複数のシーケンシャルに置かれたバイトを、さらに、少なくとも１つの第２ヘッダセクションおよび少なくとも１つの第２ペイロードセクションに分割することであって、前記少なくとも１つの第２ヘッダセクションおよび前記少なくとも１つの第２ペイロードセクションは、互いに隣接して置かれることと、
    前記少なくとも１つの第２ペイロードセクション内で少なくとも１つの第２データメンバの位置情報を表すことであって、前記位置情報は、位置タイプの位置を指定することと、
    前記第２ヘッダセクション内で前記位置タイプを識別することと
    をさらに含むことを特徴とする請求項２８に記載の方法。
32. 前記少なくとも１つの第２ペイロードセクション内にＬＯＢタイプデータメンバを置くことをさらに含むことを特徴とする請求項３１に記載の方法。
33. 前記少なくとも１つの第２ペイロードセクション内にＦＳタイプデータメンバを置くことをさらに含むことを特徴とする請求項３１に記載の方法。
34. 前記少なくとも１つの第２ヘッダセクション内でペイロード長さを表すことをさらに含むことを特徴とする請求項３１に記載の方法。
35. 前記複数のシーケンシャルに置かれたバイトを、少なくとも１つの第２ヘッダセクションにさらに分割することと、
    前記少なくとも１つの第２ヘッダセクションを用いて、前記少なくとも１つの第２ヘッダセクションに実質的に隣接して置かれる関連するデータメンバのコレクションの始めをマークすることと
    をさらに含むことを特徴とする請求項２８に記載の方法。
36. 前記少なくとも１つの第２ヘッダセクション内で、関連するデータメンバの前記コレクションが順序付けられるか順序付けられないかを示すことをさらに含むことを特徴とする請求項３５に記載の方法。
37. 前記複数のシーケンシャルに置かれたバイトを、少なくとも１つの第２ヘッダセクションにさらに分割することと、
    前記少なくとも１つの第２ヘッダセクションを用いて前記データオブジェクトの終りをマークすることと
    をさらに含むことを特徴とする請求項２８に記載の方法。
    

Images