JP2006085717A - ．ｎｅｔデータ型およびインスタンスの持続性ストレージ - Google Patents

Abstract

【課題】 基礎になるデータストアに対する基本的な依存なしでデータオブジェクトをデータベースに永続させる包括的な機構を提供すること。
【解決手段】 データベースの構造がどのように見えるべきかを知るためにプログラマの専門知識に頼るのではなく、データ型が、プログラマがデータの保存に使用されるデータベースの構造を定義することなく、プログラマによって定義され、対応するデータが何に使用されるかを提案する属性によってアドーンメントを付される。その後、データベースを動的に作成して、アドーンメントを付されされた属性によって提案される必要を満足する。具体的に言うと、複数の異なるテーブルを、データにアクセスする所期の必要に従って作成する。これを行うことによって、最適化されたデータベースを作成して、プログラマがデータベースおよび対応するデータベーススキーマに関する特定の知識を有することを必要とせずに、所望の結果をもたらすことができる。
【選択図】 図３

Description

本発明は、コンピューティングシステムの分野に関し、具体的には、データ型、特に．ＮＥＴデータ型に関連するアドーンメント（ａｄｏｒｎｍｅｎｔ）に応答して、データベース構造を作成し、データベースにデータを保存する方法、システム、およびコンピュータプログラム製品に関する。

データを保存するのに使用できる多数のさまざまなシステムおよびツールがある。データの保存には、例えば、知覚に基づき必要に応じてデータを保存するためにプログラマが異なる種類のデータベース構造を選択することができるように構成されたデータベースツールの使用を含めることができる。そのようなツールの１つとして、存在するものの中でもＡｃｃｅｓｓ（登録商標）があり、このＡｃｃｅｓｓ（登録商標）は、Ｊｅｔ ＳＱＬデータベースに従ってデータを保存する。しかし、この例にかかわらずに、さまざまな他の種類のデータ保存ツールが、多数の異なる種類のリレーショナルデータベース用に存在することを理解されたい。

しかし、既存のデータベースツールに関する問題の１つは、プログラマが、作成している特定の実装に最適の既知の性能を提供するために、データベース、およびいかにデータベースを作成し編成するかに関する比較的洗練された知識を有することが必要であることである。例えば、プログラマは、データベース用に提供される異なる種類のテーブル、割り当てられたメモリ、および他の保存構造を識別する必要がある。

しかし、保存されたデータに対する要求が変化する限り、データ構造を作成する既存のパラダイムは、多少制限される。具体的に言うと、データを保存する既知の要求およびこの要求を最もよく満たす方法に関するプログラマの限られた知識に基づいてデータベースが作成されることにより、データベースの使用が不当に制限され、将来の異なる要求を満たすためにデータベースを簡単にカスタマイズするのが妨げられる可能性がある。

具体的に言うと、データベースは、以前に既知でなかったまたはデータベースが作成された時に確立されていたデータベースと互換ではない異なるシステムからの異なる型のデータを保存する必要がある場合がある。確立されたデータベース構造は、ＳＱＬだけではなく、異なる種類のリレーショナルデータベースを柔軟に使用する必要がある場合もある。しかし、既存の技法は、データベースを定義するモノリシックなコードを書きなおすことなく柔軟に対応することはできない。

リレーショナルデータベースにオブジェクトを保存する際に遭遇するもう１つの問題は、データオブジェクトが後にアクセスされる時に保存の性能に悪影響しない形で、オブジェクトをリレーショナルデータベースに保存する間にプログラマがクラス階層を変換することが困難であるということである。例えば、多数の異なる型のクラスが、同一の基本クラスに対応する場合に、別々のクラスの各々を単一のモノリシックデータベース構造に保存しても意味がない場合がある。同様に、別々のクラスの各々を完全に別々に異なる構造に保存しても意味がない場合がある。この例の両方が、データを引き続きの照会している間に非効率になるという問題を引き起こす可能性がある。

したがって、オンデマンドで、データストアの基礎になる構造に対し基本的に依存することなく、任意のデータ構造を保存し、それらを取り出す包括的な形が必要である。

本発明は、全般的に、基礎になるデータストアまたはそのルールまたは特徴に対する基本的に依存することなく、データオブジェクトをデータベースに永続させる包括的な機構を提供する方法、システム、およびコンピュータプログラム製品に関連する。その代わりに、本発明は、データ保存技法のパラダイムシフトを提供する。具体的に言うと、所望の結果を得るために、データベースの構造がどのように見えなければならないかを知るのにプログラマの専門知識に頼るのではなく、本発明は、データが何に使用されるかに焦点を合わせ、その後、所望の結果を提供するために最適化されたデータベースを作成する。

一実施態様によれば、プログラマがデータの保存に使用されるデータベースの構造を定義することなく、データ型が、プログラマによって定義され、対応するデータが何に使用されるかを提案する属性によってアドーンメントを付される（ａｄｏｒｎｅｄ）。その後、アドーンメントを付された属性によって提案される要求を満足するために、データベースが動的に作成される。具体的に言うと、複数の異なるテーブルが、データにアクセスする所期の必要に従って作成される。いくつかの実施態様によれば、データベース構造およびデータベーステーブルは、データ保存の複製を最小にし、データベースの性能を高めて、データにアクセスする所期の要求を満足する形で作成される。このデータベーステーブルの作成は、プログラマに透過的であり、プログラマは、異なる型のデータ構造またはデータベースに関する特殊な知識を有する必要がない。その代わりに、プログラマは、対応するデータにアクセスする既知の要求に基づくデータ型を単に識別するコードを開発することができる。

後に、データにアクセスする必要が変化した場合に、データ型を変更するか、削除し、新しいデータ型を作成することができ、これによって、データベースの基礎になる構造を、それ相応に、変更されるデータベースに対応するモノリシックなコードを必要とせずに、動的に更新できるようになる。言い換えると、本発明は、データベース構造のモジュラ作成を可能にする手段を提供する。

本発明の追加の特徴および利益は、次の説明で示され、部分的にその説明から明白になり、あるいは、本発明の実践から習得することができる。本発明の特徴および利益は、請求項で特に指摘される道具および組合せによって実現し、得ることができる。本発明の上記および他の特徴は、次の説明および請求項からより完全に明白になり、あるいは、下に記載の本発明の実践によって習得することができる。

本発明の上記および他の利益および特徴を得ることができる形を説明するために、上記
で簡単に説明した本発明のより特定の説明を、添付図面に示された特定の実施形態を参照して行う。これらの図面が、本発明の１つの通常の実施形態を示すのみであり、したがって、その範囲の限定と考えてはならないことを理解して、本発明を、添付図面の使用を介してさらに具体的に、詳細に説明する。

本発明は、データを保存する方法およびシステムと、対応するデータベース構造を作成する方法およびシステムの両方に広がっている。本発明の実施形態に、下で詳細に述べるように、さまざまなコンピュータハードウェアを含む、専用のまたは汎用のコンピュータを備えることができる。

本明細書で説明するように、本発明の実施形態には、データを保存するためにデータベース構造を作成する方法に関する特殊な知識を必要とせずに、データの所期の使用に基づく属性によってデータ型にアドーンメントが付される（ａｄｏｒｎｅｄ）方法が含まれる。次に、適当なデータベース保存テーブルに、アドーンメントが付されたデータ型によって決定される要求に従って作成される。次に、このテーブルに、適当なアプリケーションによって、対応するデータを取り込み、照会することができる。データベース構造の作成は、データベースの知識要件を除いて、データの所期の使用に基づくので、プログラマがデータベースおよびデータベース構造に関して知識が欠如しているにかかわらず、データベースの性能を最適化するように作成される。これが、データベース構造の作成に関する従来技術のシステムに対するパラダイムシフトおよび改善を表すことも理解されたい。

本発明の実施形態は、コンピュータ実行可能命令またはデータ構造を担持するか保存されたコンピュータ読取可能な媒体も含む。そのようなコンピュータ読取可能な媒体は、汎用コンピュータまたは専用のコンピュータによってアクセスできるすべての使用可能な媒体とすることができる。制限ではなく例として、そのようなコンピュータ読取可能な媒体に、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光学ディスク保存、磁気ディスク保存または他の磁気保存装置、あるいは、コンピュータ実行可能命令またはデータ構造の形で所望のプログラムコード手段を担持または保存するのに使用でき、汎用コンピュータまたは専用のコンピュータによってアクセスできるすべての他の媒体を含めることができる。情報が、ネットワークまたは別の通信接続（ハードワイヤード、無線、またはハードワイヤードもしくは無線の組合せのいずれか）を介してコンピュータに転送または供給されると、そのコンピュータは、その接続を正しくコンピュータ読取可能な媒体と見なす。したがって、そのような接続のすべてを、正しくコンピュータ読取可能な媒体と呼ぶ。上記の組み合わせも、コンピュータ読取可能な媒体の範囲に含まれなければならない。コンピュータ実行可能命令に、例えば、汎用コンピュータ、専用のコンピュータ、または専用の処理装置にある機能または機能のグループを実行させる命令およびデータが含まれる。

．ＮＥＴデータ型およびインスタンス用の持続性保存
本発明の一実施形態によれば、．ＮＥＴデータ型およびインスタンス用の持続性保存は、プログラミング中に定義されたデータ型に置かれるアドーンメントに応答する、データベーステーブルを含むがこれに制限されないデータベース構造の作成を可能にする対応するモジュールと共に提供される。

データ型に置かれるアドーンメントは、いかなる要求または希望に従っても変更することができる。いくつかの例により、プログラマが後に作成されるデータベース構造に関する特殊な知識を一切有しない場合であっても、アドーンメントをプログラマによって記述されたコードセグメント内のデータ型に添付する方法と、後にそれらを使用して、データベース構造の作成を制御する方法を示す。

第１の例で、タイトル、アルバムアート、アーティストのリスト、および曲のリストを含むクラス型としてアルバムを説明する。曲の各々は、タイトル、持続時間、およびアルバムを有するクラス型としても識別される。最後に、アーティストは、名前、写真、およびファンページＵＲＩを含むクラス型として識別される。

前の例によってさらに反映されているように、クラス型に対応するデータオブジェクトの一部は、特殊な属性を用いてアドーンメントを付される。例えば［ＣＬＳＩＢａｃｋＰｏｉｎｔｅｒ（ａｌｂｕｍ）］属性は、アルバムフィールドまたはオブジェクトが、同一のアルバムに関連付けることができる多数の異なる曲へのバックポインタを含むことを示す。これを、下で図１を参照して詳細に説明する。

例示されているもう１つのアドーンメントに、ａｒｔｉｓｔクラスに関連する［ＣＬＳＩＩｎｄｅｘ］属性が含まれ、このことにより、これを照会できなければならないことが示される。このアドーンメントの理由の１つは、データベースの性能を高めることである。具体的に言うと、データベースがある項目の照会を許容することがわかっている場合に、その項目が照会を意図されていることを示すほうが有用な場合がある。この形で、データ構造が作成されると、下で詳細に説明するように、照会されることがわかっている項目の検索を最適化する形でそのデータ構造を作成することができる。

ここで図１Ａ〜１Ｄを参照すると、これらの図には、本発明の方法に従って、持続性保存モジュールに供給されるコードで定義されたデータ型およびアドーンメントに基づいて作成できるデータベーステーブルを含むデータベース構造が示されている。

図からわかるように、４つのテーブルが作成されている。第１のテーブル、Ａｌｂｕｍ（アルバム）テーブル１００ａは、上の例で識別されたアルバム型に対応し、これには、下で参照される、ｔｉｔｌｅ（タイトル）フィールド１１０ａおよびａｒｔ（アート）フィールド１２０ａが、ｒｅｃｏｒｄ ｎｕｍｂｅｒ（レコード番号）列１３０ａおよびａｒｔｉｓｔ（アーティスト）列１４０ａと共に含まれる。これらの異なるフィールドは、上で説明したコードで提供されるオブジェクトに対応する。

別々のＳｏｎｇ（曲）テーブル１００ｂにも、コードによって定義されているように、それぞれタイトル、演奏時間、およびアルバムの対応するフィールド（１１０ｂ、１２０ｂ、１３０ｂ）が含まれる。ｄｕｒａｔｉｏｎフィールド１２０ｂに、それが属する曲に対応する演奏時間データを含めることができる。

Ａｒｔｉｓｔ（アーティスト）テーブル１００ｃに、上で示した例のａｒｔｉｓｔクラス型の説明に対応するｎａｍｅ（名前）フィールド１１０ｃ、ｐｉｃｔｕｒｅ（写真）フィールド１２０ｃ、およびＵＲＩフィールド１３０ｃが含まれる。ｐｉｃｔｕｒｅフィールド１２０ｃは、例えばアーティストに対応するグラフィックイメージへのポインタを含むことができ、ＵＲＩフィールド１３０ｃは、ファンページなど、アーティストに対応する文書またはウェブページへのリンクを含むことができる。

最後に、ｃｏｌｌｅｃｔｉｏｎｓ（コレクション）テーブル１００ｄが設けられ、これには、両方とも一意の識別子を保持する型が与えられた２つの列が含まれる。第１列１１０ｄは、コレクションの識別を表し、それを参照するインスタンス、この例ではａｌｂｕｍテーブル１００ａのアルバムのフィールドによって指示される。第２列１２０ｄは、コレクションの一部であるインスタンス、この例ではアーティストの識別を表す。したがって、単一のコレクションが、それに含まれるインスタンスの個数と同一の行数をコレクション内に有するが、そのような行のすべてが、所与のコレクションを識別する同一の一意の識別を有する。したがって、コレクションへのポインタフィールドは、コレクションインスタンスを表す行に一意の識別を置くことによって表すことができる。これは、アルバムオブジェクトによって指示される各別個のアーティストコレクションが、コレクションテーブル内で、１つまたは複数の行として表され、各行の第２列が、アーティストテーブル内の行を指示することを暗示する。例えば、現在の例では、コレクションＩＤ １（アルバム１に関連する）が、アーティスト要素２１およびアーティスト要素２２にリンクされている。コレクションＩＤは、相互参照のためにＡｌｂｕｍテーブル１００ａでも識別されている。

ａｒｔｉｓｔ型のｎａｍｅフィールドが、上で説明したように、適当なアドーンメントを用いて一意の識別子として属性を与えられると、アーティスト名は、ａｒｔｉｓｔテーブルの行を指示できる、ｃｏｌｌｅｃｔｉｏｎｓテーブル内の一意の識別を表すことができる。しかし、ａｒｔｉｓｔ型のｎａｍｅフィールドが、一意の識別子として属性を与えられない場合に、ポインタは、その代わりに、アーティスト名ではなく、対応するａｒｔｉｓｔテーブルの識別子をポイントバックする。現在の例では、これが、ｒｅｃｏｒｄ ｎｕｍｂｅｒを使用して行われる。

ｓｏｎｇクラスのｔｉｔｌｅフィールドおよびａｒｔｉｓｔクラス型のｎａｍｅフィールドが、［ＣＬＳＩＩｎｄｅｘ］属性を用いてアドーンメントが付されているので、ｓｏｎｇクラスおよびａｒｔｉｓｔクラスに対応するデータベース構造（例えば、テーブル）は、データベースが対応するデータベーステーブルに保存される行のすべてを必ずしも照会することなく、ソートでき、それぞれタイトル列および名前列について素早く照会できる形で作成されることを理解されたい。

所与のクラスに関連するデータベーステーブルは、例えば、テーブル内の各行に一意の識別子を与える隠しレコード番号１３０ａ、１４０ｂ、１４０ｃを含むことができる。

項目またはオブジェクトの検索中に、データベースは、ｒｅｃｏｒｄ ｎｕｍｂｅｒ １３０ａに基づいてすべてのレコードをシーケンシャルに検索することができる。しかし、クラスフィールドが、以前に識別され、［ＣＬＳＩＩｎｄｅｘ］属性などの属性によってアドーンメントが付され、それが照会されることを意図されていることが示されている場合に、ｓｏｎｇテーブルのｔｉｔｌｅ列およびａｒｔｉｓｔテーブルのＮａｍｅ列など、対応するインデックスデータ構造を、属性付きのフィールドに対応する列に対して作成することができ、その結果、これらをソート（アルファベット順または他の任意の形で）して、検索を最適化することができるようになる。したがって、照会を最適化することができ、プログラマがデータベースに関する特殊な知識を介してデータ構造を作成する必要がない。

同様に、ａｌｂｕｍクラスのｓｏｎｇｓフィールドに関連するバックポインタアドーンメントは、そのｓｏｎｇコレクションがａｌｂｕｍインスタンスによって所有される（ｏｗｎｅｄ）こと、およびｓｏｎｇ型のａｌｂｕｍフィールドが、所有するアルバムへのバックポインタとして機能することを示す。したがって、所与のａｌｂｕｍに属するｓｏｎｇは、指定されたアルバムを識別するａｌｂｕｍ列を有するｓｏｎｇテーブルを照会することによって識別することができる。逆に、ａｌｂｕｍ列は、所与のｓｏｎｇが属するアルバムを識別するのに使用することができる。その後、識別されたアルバムを使用して、他のテーブル（例えば１００ｃ）を使用してアルバムのアーティストに対応する他の情報を識別することができる。

このように、ｓｏｎｇテーブル１００ｂを、ａｌｂｕｍテーブル１００ａと独立して照会することができ、ａｌｂｕｍテーブル１００ａ、ｓｏｎｇテーブル１００ｂに保存された曲の各々に関する演奏時間情報を保存する必要がなくなる。これによって、ａｌｂｕｍテーブル１００ａを照会する時の性能を改善できることを理解されたい。同様に、ｓｏｎｇテーブル１００ｂの照会も、それに属するアルバムに関連するアート情報およびアーティスト名情報のすべてを保存する必要がなくなるため、最適化される。これは、テーブルの相互参照により、必要な情報のすべてが簡単に提供されるからである。

さらに追加のアドーンメントを示すために、購入注文のカスタマに関するもう１つの例を示す。それでも、この例ならびに前述の例が、単なる例示であり、したがって、作成できるデータベース構造の種類または使用できるアドーンメントされる属性の種類に関して本発明を制限するものと解釈してはならないことを理解されたい。

次の例では、カスタマクラスおよび購入注文クラスが作成される。

前述の例で、いくつかの新しいアドーンメントが提示されている。例えば、ｃｕｓｔｏｍｅｒクラスの電話番号フィールドにアドーンメントを付して、［ＣＬＳＩＩｄｅｎｔｉｔｙ］属性が、電話番号がｃｕｓｔｏｍｅｒ型の一意のキーを表さなければならないことを示すために提供されている。

［ＣＬＳＩＳｉｎｇｌｅＲｅｆ］属性も、ｃｕｓｔｏｍｅｒクラスのａｄｄｒｅｓｓフィールドに提供されて、カスタマとカスタマの住所の間に１対１関係が存在することが意図されていることを示している。

［ＣＬＳＩＢａｃｋＰｏｉｎｔｅｒ（ｃｕｓｔｏｍｅｒ）］を含むもう１つの属性は、ｃｕｓｔｏｍｅｒクラスの購入注文フィールドに対してアドーンメントが付されている。この属性は、購入注文が注文を行ったカスタマへのバックポインタとして働くことが意図されていることを示す。これは、図２で示す例に鑑みてより明瞭に理解することができる。

図２Ａおよび２Ｂからわかるように、ｃｕｓｔｏｍｅｒテーブル２００ａおよびｐｕｒｃｈａｓｅ ｏｒｄｅｒテーブル２００ｂが、それぞれ対応するフィールド（２１０ａ、２２０ａ、２３０ａ）および（２２０ａ、２２０ｂ、２３０ｂ）と共に作成され、これらは、上述で例示的なコードセグメントで定義されたものである。このテーブル２００ａおよび２００ｂは、テーブル１００ａ、１００ｂ、および１００ｃのように、データベース構造がどのように作られるかに関する特殊な知識がなくても、コードセグメントで提供された定義およびアドーンメントに従って作成されたものでもある。言いかえるとこの定義およびアドーンメントは、保存されるデータが何に使用されるか、またはそれにどのようにアクセスまたは照会する必要があるかに関するヒントを提供するためにのみ必要とされる。

前述の例では、［ＣＬＳＩＩｄｅｎｔｉｔｙ］属性のアドーンメントは、対応するフィールドである電話番号がｃｕｓｔｏｍｅｒ型の一意のキーを表さなければならないことを示すために提供されている。これは、例えば、テーブルに、行ごとに特殊なｒｅｃｏｒｄ ｎｕｍｂｅｒ １３０ａ（図１）を保存するという要件を最小にするのに有用である可能性がある。具体的に言うと、［ＣＬＳＩＩｄｅｎｔｉｔｙ］属性を用いてアドーンメントを付されるフィールドを、各対応する行の一意の識別子として使用することができる。これは、図２に示されており、図２では、電話番号２２０ａが、ｐｕｒｃｈａｓｅ ｏｒｄｅｒテーブル２００ｂでカスタマを表すのに使用されている。

他の実施形態で、［ＣＬＳＩＩｄｅｎｔｉｔｙ］属性を用いてアドーンメントを付されるフィールドの組合せをすることもでき、このフィールドの組合せが、行の一意の識別子を表すようにすることができる。

上で識別された［ＣＬＳＩＳｉｎｇｌｅＲｅｆ］属性は、ｃｕｓｔｏｍｅクラスのａｄｄｒｅｓｓフィールドにも設けられて、カスタマとカスタマの住所の間に１対１関係が存在することが意図されていることを示している。これに関して、カスタマのａｄｄｒｅｓｓフィールド２３０ａは、カスタマに対応する実際の住所ストリングを取り込むことができ、あるいは、その代わりに、別のテーブルに保存された住所データを指示することができる。

上記で全般的に説明したバックポインタ属性［ＣＬＳＩＢａｃｋＰｏｉｎｔｅｒ（ｃｕｓｔｏｍｅｒ）］も、最後の例のｃｕｓｔｏｍｅｒクラス型の購入注文フィールドに対してアドーンメントを付された。したがって、図１を参照して説明したように、バックポインタは、ｐｕｒｃｈａｓｅ ｏｒｄｅｒテーブルにリストされたカスタマがｃｕｓｔｏｍｅｒテーブル２００ａを参照できるようにする。したがって、単一のテーブルが、カスタマおよびカスタマの購入注文に対応するデータアイテムの各々を維持する必要はない。その代わりに、購入されるアイテムおよび対応するＳＫＵコードの詳細な記述を、ｃｕｓｔｏｍｅｒテーブル２００ａと別々に維持し、必要な時に、購入注文に対応するカスタマをルックアップすることによってアクセスすることができる。これによって、上記で説明したように、データベースの所期の要求に従ってデータベースの性能を改善できることを理解されたい。より重要なことに、プログラマは、データベーステーブルがどのように作成されるかを知ることも、理解することも必要ではなかった。その代わりに、プログラマは、単に、データの所期の使用が何であるかを知る必要があるだけである。

前述の例では、クラス型を異なる階層にどのように配置できるかも示されている。具体的に言うと、前述の例では、ａｄｄｒｅｓｓ基底クラスと、ａｄｄｒｅｓｓ基底クラスに対応するＵＳ ａｄｄｒｅｓｓクラスが識別されている。これは、例えば、異なる階層分類に対応する関連データを保存できる別々のテーブルまたは他のデータベース構造を作成するのに有用な可能性がある。

テーブルは、現在、ａｄｄｒｅｓｓクラスについて図示されていないが、州、通りの名前、番地など、多数の異なる種類の住所に共通する包括的な住所情報を保存する異なる列を含む包括的な住所について基底クラステーブルをどのように作成できるかを推測することができる。次に、サブクラスを、すべての住所には関係しない可能性があるより具体的な住所データを含む特殊化されたテーブルまたは他の構造に保存することができる。例えば、全世界のディレクトリアプリケーションにおいて、すべての国に郵便番号が含まれるわけではない。同様に、米国の住所に、外国の住所に関連する住所コードまたは他の情報が含まれない可能性がある。そのような状況では、異なる地域住所テーブルの各々に、すべての住所オブジェクトに関連しない特殊化された情報を含めることができ、なおかつ基底クラステーブルからの包括的な住所情報への素早いアクセスが可能になる。

相互参照に関する前の例と同様に、基底クラステーブル（例えば、基底住所クラステーブル）が、サブクラステーブル（例えば、地域クラステーブル）を相互参照できることも理解されたい。この技法を使用して、クラステーブルとサブクラステーブルの間のさまざまな深さの階層レベルを作成することができる。

これから図３に示された流れ図３００に注意するが、この図には、本発明を実施する１つの方法が示されている。図からわかるように、この方法には、保存されるデータを識別することが含まれる（３１０）。これに関して、用語データは、保存されるデータ型を指す。この識別は、データ型を識別するコードが、コンピュータ読取可能な媒体で維持される持続性保存モジュール（図示せず）に提示された時に行うことができる。

次に、データの保存にどのデータベーススキーマ（例えば、データベース構造）を使用すべきかに関する決定を行う（３２０）。この判定は、上で説明したように、データ型に関連するアドーンメントの識別に応答して自動的に行われる。具体的に言うと、プログラマは、作成すべきデータ構造またはデータベース保存ツールを使用してそれを選択もしくは作成する方法に関する特殊な理解を有する必要はない。従って、本発明は、コードで定義されたデータ型に関連するアドーンメントに基づくデータ構造の自動作成を可能とし、アドーンメントは、データの所期の使用またはアクセスを反映したものである。

次に、適当なデータベース構造が存在するかどうかを判定する（３３０）。存在しない場合には、作成する（３４０）。例えば、図１および２に、作成できるテーブルのある実施形態を示す。しかし、これらのテーブルが、本発明の範囲を制限するものと解釈してはならない。データベース構造の作成（３４０）に、図１および２に関して上記で説明し、示したように、データベーステーブルを作成することと、コード内の対応するフィールドによって識別される少なくともいくつかの列をテーブルに取り込むことを含めることができる。

データベース構造の作成（３４０）に、データ型に対応する複数のテーブルの作成も含めることができる。作成できるテーブルに、例えば、コードで識別された型を定義し、対応するデータベーステーブルの各々を識別する型テーブルを含むことができる。このテーブルおよび他の類似するテーブルを、下で詳細に説明する。任意の個数の基底クラステーブルおよびサブクラステーブルを、データ型を保存するために適当なデータベース構造が存在しないと判定した時に作成することもできる。

図３に示された方法に、適当なデータベース構造（例えば、テーブル）を作成した後に、保存されるデータオブジェクトを入手すること（３５０）が含まれる。これは、例えば、単一のインスタンス中にまたはある時間期間にわたって、任意の個数の接続したまたは別個のデータベースおよびアプリケーションから達成することができる。データオブジェクトを入手した（３５０）場合、そのデータオブジェクトが既に保存されているかどうかを判定する（３６０）。これは、例えば、特に対応するフィールドの１つが［ＣＬＳＩＩｄｅｎｔｉｔｙ］属性を用いてアドーンメントを付されている（その属性を有するフィールドについて同一の値を有しない限り、２つの項目が同一になることがないことを示す）時に、適当なテーブルを検査することによって達成することができる。したがって、別のエントリが、対応するアドーンメントを付されたフィールドに同一の値を有する場合に、そのエントリが既に受信されており、新しいデータが、重複または既に受信されたデータに対する更新のいずれかであると判定することができる。データオブジェクトの重複したエントリを減らすことによって、保存容量および照会処理要件を最小にすることができる。

一実施形態で、識別属性が、フィールドが主キーの一部であるかどうかを示すために、フィールドに適用される。この実施形態によれば、識別属性は、持続性クラスの階層のルートを形成するクラスの少なくとも１つのフィールドに適用され、その結果、少なくとも１つのフィールドが、上で説明したように重複した保存を防ぐのに使用できる主キーを識別するのに使用される。

図示する方法の次の要素は、まだ書き込まれていない場合にデータオブジェクトを書き込むこと（３７０）が含まれる。これには、データオブジェクトのすべての部分を、上で示したようにまたは他の形で１つまたは複数のデータベーステーブルに書き込むことを含めることができる。これに、そのデータオブジェクトの派生物をデータベーステーブルに書き込むことも含めることができる。これに、別の位置に保存された実際のデータを指示するポインタをデータベーステーブルに書き込むことを含めることもできる。

他の実施形態で、本発明の方法に、データベース構造に既に保存されていることがわかったデータを変更すること（３８０）も含めることができる。例えば、最後に保存された時以降に更新が行われている場合に、データを更新することが有用である可能性がある。更新されたデータが、古いデータと別々に独立に保存され、これによって貴重な保存スペースを使用しないようにするために、主キーを使用して、データが同一であり、変更または上書きが必要であることを判定することができる。そうしなければ、その保存により、オブジェクトが後に取り出される時に古い情報を生じる。重複保存を防ぐための一意のキーの使用は、データに関する要求に応答して同一エンティティの情報の異なるセットを作るのを防ぐのにも有益である。

前述の例は、データベーステーブルを含むデータベース構造に関して提供されたが、本発明の範囲が、データベース構造にＸＭＬファイルまたは他の保存構造が含まれる実施形態など、他の実施形態にも及ぶことを理解されたい。

本発明の範囲は、データストアが配列またはディクショナリである実施形態にも及んでいる。例えば、２つの追加のデータ要素または配列の次元の数および次元のランクに対応する異なる列のセットを提供することによって、配列を、上述の、および本明細書で説明するコレクションに似た形で構成することができる。

要約すると、上記で説明した方法を実施するコンピュータ実行可能命令を有する１つまたは複数のコンピュータ読取可能な媒体に保存でき、これから実施できる本発明を、時々、本明細書で、．ＮＥＴデータ型およびインスタンス用の持続性保存と称する。説明したように、この持続性保存は、データ構造をデータベースにシリアライズする包括的な機構を提供し、これによって、オンデマンドで任意のデータ構造を保存し、取り出す包括的な形を必要とする複数のサービスに関する解決策を提供する。

この持続性保存は、ＣＬＲ（Ｃｏｍｍｏｎ Ｌａｎｇｕａｇｅ Ｒｕｎｔｉｍｅ）によって提供される機能に基づくが、ストアの下にある異なるデータソースにプラグインすることが可能である。また．ＮＥＴデータ型に基づいて本発明によって使用されるデータモデルを、本発明の範囲を制限するものと見なしてはならない。というのは、Ｊａｖａ（登録商標）に基づくものなどの代替データモデルもサポートできるからである。

本発明のいくつかの興味深い変形形態および追加の詳細を、これから下の説明で提供する。

まず、持続性保存フレームワークを、次の要素からなるものとして記述することができる：データ構造をデータソースにシリアライズするかデシリアライズする基本的な機能を提供するＯｂｊｅｃｔＳｔｏｒｅ。ＯｂｊｅｃｔＳｔｏｒｅは、動作するコンテキストを受け入れることができる。ＯｂｊｅｃｔＳｔｏｒｅの派生形は、ＯｂｊｅｃｔＳｔｏｒｅに関連するデータソースがＳＱＬデータベースまたはＸＭＬファイルである特定の実装を提供する。レコードｉｄ、ストアコンテンツなどに関する特定のＯｂｊｅｃｔＳｔｏｒｅ実装に関連するクラスも、定義される。シリアライゼーション属性も適用される。本明細書で説明するように、少数のカスタム属性が定義され、その結果、サービス開発者が、フィールドに対する追加情報を指定できるようになる。ＳｔｏｒｅＳｅｒｖｉｃｅは、基礎になるデータベース内のオブジェクトを永続させるためのクライアントへの単一の連絡点を提供するＳｅｒｖｉｃｅＢｕｓサービスである。

このフレームワークは、グラフまたはコレクション内の同一のオブジェクトへの複数の参照が１回だけストアされることを保証する。複数のグラフにまたがる同一オブジェクトへの参照は、ストア内の同一レコードに解決されなければならない。これを保証するために、クラスは、その一意のｉｄを構成するフィールドを指定する必要がある。

デシリアライゼーションが発生し、オブジェクトグラフまたはオブジェクトコレクションが、保存されたレコードから作成される時に、すべてのオブジェクトが、１回だけ作成されなければならない。しかし、オブジェクト参照は、同一コンテキストに属すると指定されない限り、複数のデシリアライゼーション呼出まで含め同一のオブジェクトに解決される必要がない。

ここで具体的にＯｂｊｅｃｔＳｔｏｒｅに注意するが、このＯｂｊｅｃｔＳｔｏｒｅは、要求の保存および取り出しを処理するコンポーネントである。これから、ＯｂｊｅｃｔＳｔｏｒｅに対応する例示的なメソッドおよびコードを示す。

コンストラクタ：ＯｂｊｅｃｔＳｔｏｒｅは、保存機構の開始点である。オプションのＳｔｏｒｅＣｏｎｔｅｘｔパラメータは、取り出しおよび保存のステージをセットするのに使用される。コンテキストが供給されない場合、ＳｔｏｒｅＣｏｎｔｅｘｔは、デフォルト値を用いて初期化される。

Ｗｒｉｔｅ：このメソッドは、呼出し側がオブジェクトｏを保存することを可能にする。オブジェクトｏは、プリミティブ型、構造体、クラス、またはコレクションとすることができる。

ｗｒｉｔｅメソッドは、オブジェクトが保存された場合に一意のＲｅｃｏｒｄＩＤを返す。そうでない場合に、このメソッドは、ｎｕｌｌを返すか、ＳｔｏｒｅＥｘｃｅｐｔｉｏｎ例外を送出する。

Ｒｅａｄ：このメソッドは、ＲｅｃｏｒｄＩＤおよびオブジェクトの型を与えられてオブジェクトを作成する。オーバーロードバージョンは、指定された判断基準に基づくオブジェクトのコレクションを返す。

Ｄｅｌｅｔｅ：このメソッドは、ＲｅｃｏｒｄＩＤおよびオブジェクトの型を与えられてオブジェクトを削除する。オーバーロードバージョンは、指定された判断基準に基づいてオブジェクトを削除する。パラメータは、他のオブジェクトへの参照を再帰的に追跡しなければならないかどうかを示す。削除動作のカスケードは、外部オブジェクトの削除の結果として内部オブジェクトのｒｅｆカウントが０になる場合に発生する可能性がある。

次に、シリアライゼーション属性および参照アクション属性を含むカスタム属性の例に注意する。この属性の一部に対応する例示的なコードを提供する。

シリアライゼーション属性
ＳｅｒｉａｌｉｚａｂｌｅＡｔｔｒｉｂｕｔｅおよびＮｏｎＳｅｒｉａｌｉｚａｂｌｅＡｔｔｒｉｂｕｔｅは、ある型のインスタンスをシリアライズできるか否かを示す。ストア可能性（ｓｔｏｒｅａｂｉｌｉｔｙ）とシリアライズ可能性（ｓｅｒｉａｌｉｚａｂｉｌｉｔｙ）は、関連する概念として扱われる。ストア可能性は、ファイルまたはデータストアへのシリアライズとして扱われる。

ＣＬＳＩＩｄｅｎｔｉｔｙＡｔｔｒｉｂｕｔｅ
上で述べたように、ＣＬＳＩＩｄｅｎｔｉｔｙＡｔｔｒｉｂｕｔｅは、フィールドが主キーの一部であるかどうかを示すためにフィールドに適用されるカスタム属性である。ＣＬＳＩＩｄｅｎｔｉｔｙＡｔｔｒｉｂｕｔｅは、持続性クラスの階層のルートを形成するクラスの少なくとも１つのフィールドに適用されなければならない。

ＲｅｆｅｒｅｎｔｉａｌＡｃｔｉｏｎＡｔｔｒｉｂｕｔｅ
ＲｅｆｅｒｅｎｔｉａｌＡｃｔｉｏｎＡｔｔｒｉｂｕｔｅは、参照されているオブジェクトが削除された場合に行わなければならないアクションを示すために参照フィールドに適用されるカスタム属性である。

他の属性は、上で図１および図２ならびに対応する例に関して説明した。

次に、ＳｑｌＳｔｏｒｅに注意するが、これは、ＳＱＬデータベースに対する保存要求および取り出し要求を処理するコンポーネントである。ＳｑｌＳｔｏｒｅは、データベース接続を確立し、Ｒｅａｄ呼出およびＷｒｉｔｅ呼出しを、ＤａｔａＡｄａｐｔｅｒなどによって処理可能な形に変換する。例示的なメソッドおよびＳｑｌＳｔｏｒｅに対応するコードを、これから提供する。

コンストラクタ：ＳｑｌＳｔｏｒｅは、ＳＱＬ保存機構の開始点である。オプションのＳｔｏｒｅＣｏｎｔｅｘｔパラメータは、取り出しおよび保存のステージをセットするのに使用される。コンテキストが供給されない場合に、ＳｔｏｒｅＣｏｎｔｅｘｔは、次のデフォルト値を用いて初期化される。

ａ） ＿ｄａｔａｂａｓｅ ｎａｍｅ：「ＳｅｒｖｉｃｅＢｕｓ」がセットされる
ｂ） ＿ｖａｒＭａｘＬｅｎｇｔｈ：１０２４がセットされる
Ｗｒｉｔｅ：このメソッドは、呼出し側がオブジェクトｏを保存することを可能にする。オブジェクトｏは、プリミティブ型、構造体、クラス、またはコレクションとすることができる。

ｗｒｉｔｅメソッドは、オブジェクトが保存されたか既に存在する場合に一意のｓｑｌＲｅｃｏｒｄＩＤを返す。そうでない場合に、このメソッドは、ｎｕｌｌを返すか、ＳｔｏｒｅＥｘｃｅｐｔｉｏｎ例外を送出する。

Ｒｅａｄ：このメソッドは、ＲｅｃｏｒｄＩＤを与えられてオブジェクトを作成する。

ＶａｒＭａｘＬｅｎｇｔｈ：このプロパティは、ｖａｒｃｈａｒ ＳＱＬ型およびｖａｒｂｉｎａｒｙ ＳＱＬ型を定義する間に使用される最大長を与える。デフォルト値は１０２４である。

本発明は、多数の異なる環境で、さまざまなリレーショナルデータベースと共に実施することができるが、次の例では、ＳＱＬデータベースへのオブジェクトの保存に用いられる動作の一部を示す。具体的には、オブジェクトの保存に、ＳＱＬデータベース内のリストのアクションが含まれる。

ａ）テーブルの作成：必要な場合に、オブジェクト型と同等のＳＱＬテーブルが作成される。そうでない場合に、オブジェクトが保存されるＳＱＬテーブルが識別される。

ｂ）オブジェクトに対応するＳＱＬテーブルが使用可能になったならば、主キーを構成するフィールドを使用して、オブジェクトがそのテーブルに既に保存されているかどうかを調べる。行が既に存在する場合には、現在のオブジェクトを用いて更新し、そうでない場合には新しいレコードを作成する。

ｃ）シリアライズ可能なオブジェクトインスタンスのフィールドを保存する。オブジェクトの要素および再帰的なその要素の型に基づいて、必要な場合にさらなるＳＱＬテーブルを作成する。

作成される可能性があるさまざまなテーブルの例を、これから提示する。

ＯｂｊｅｃｔＴｙｐｅＴａｂｌｅ
ＯｂｊｅｃｔＴｙｐｅＴａｂｌｅは、ＣＬＲクラス／構造のＸｍｌＴｙｐｅＮａｍｅをデータソーステーブルの名前にマッピングするＳＱＬテーブルである。保存処理中に作成されるすべてのＳＱＬテーブルについて、１つのエントリがＯｂｊｅｃｔＴｙｐｅＴａｂｌｅに作成される。

ＯｂｊｅｃｔＢａｓｅＴｙｐｅＴａｂｌｅ
ＯｂｊｅｃｔＢａｓｅＴｙｐｅＴａｂｌｅは、クラスの基底クラス関係を維持するＳＱＬテーブルである。保存処理中に作成されるすべてのＳＱＬテーブルについて、１つまたは複数のエントリが、ＯｂｊｅｃｔＢａｓｅＴｙｐｅＴａｂｌｅ内に作成される。型ＡがＢの基底クラスである場合に、エントリに、ソースとしてＡを有する行が含まれる。

このテーブルは、照会中に有用である。

ＯｂｊｅｃｔＡｒｒａｙＴａｂｌｅ
ＯｂｊｅｃｔＡｒｒａｙＴａｂｌｅは、配列を構成する要素を含むＳＱＬテーブルである。すべての配列インスタンスの要素が、これに保存される。

ＯｂｊｅｃｔＤｉｃｔｉｏｎａｒｙＴａｂｌｅ
ＯｂｊｅｃｔＤｉｃｔｉｏｎａｒｙＴａｂｌｅは、ディクショナリを構成する要素を含むＳＱＬテーブルである。すべてのディクショナリインスタンスの要素が、これに保存される。実際のキーおよび要素オブジェクトが、そのＣＬＲ型に対応するＳＱＬテーブルに保存されることに留意されたい。

次に、ＣＬＲ型のマッピングに注意する。具体的に言うと、各クラス型は、別々のＳＱＬテーブルとして保存される。クラスのインスタンスの各フィールドの値は、そのＳＱＬテーブルの列値として保存される。

オブジェクトテーブルは、クラス型または構造体型と同等であり、その型の最初のオブジェクトに出会った時にオンザフライで作成される。使用可能な時には必ず、オブジェクトのインスタンス型が使用され、そうでない時には、オブジェクトの宣言された型が使用される。例えば、オブジェクトがｎｕｌｌである場合に、宣言された型が使用される。

クラスサブタイプは、派生クラスのフィールドを含むＳＱＬテーブルに変換され、そのＳＱＬレコードを参照する余分なＳｑｌＲｅｃｏｒｄＩｄ列が、ルートクラスインスタンス値に対応する。持続性クラスチェーンは、ＯｂｊｅｃｔＴｙｐｅＴａｂｌｅに保存される。

ルートテーブルには、実際のインスタンス型を与える余分な列が含まれる。ルートオブジェクトテーブルは、ｒｅｆカウントの２つの列も含む。これらは、削除中に有用であり、循環グラフも処理する。一方のｒｅｆカウント（このカウントは、２つの値０または１だけを有する）は、オブジェクトがオブジェクトグラフのルートとして渡されたかどうかを記録し、もう１つのｒｅｆカウントは、このオブジェクトを参照するオブジェクトの総数を維持する。行は、両方のｒｅｆカウントが０になる場合に限って削除される。

テーブルの主キー型は、オブジェクト型のカスタム属性から判定される。主キーを指定するカスタム属性を、型の１つまたは複数のフィールドについてセットすることができる。ルート持続性クラスに、この属性を有する少なくとも１つのフィールドが含まれなければならない。ＳｑｌＳｔｏｒｅは、自動的に生成される一意のｉｄを含むＳｑｌＲｅｃｏｒｄＩｄ列も、テーブル定義に追加する。このｉｄは、６４ビット数であり、ＳＱＬテーブル内で一意であり、代替キーとして定義される。ＳｑｌＲｅｃｏｒｄＩｄは、必ず、主キーが明示的に指定されている場合であっても、このオブジェクトを参照する内部オブジェクトで外部キーとして使用される。

主キーを構成するすべてのフィールドが、ルート持続性クラスのシリアライズ可能メンバでなければならない。そうでなければ、オブジェクトが既に保存されているかどうかを検査するために、主キーの参照フィールドのＳｑｌＲｅｃｏｒｄＩｄをまず入手しなければならない。参照フィールド自体が、その主キーに参照フィールドを含む可能性があるので、これが再帰的処理になることに留意されたい。次の段落に、この例を示す。

ここで、オブジェクト「ａ」が既に永続しているかどうかを知るために、ａ．ｉｄに対応するＳｑｌＲｅｃｏｒｄＩｄのＭｅｄｉａＩｄテーブルを照会する必要がある。これを取得すると、ＳｑｌＲｅｃｏｒｄＩｄ値およびｌｏｃａｔｉｏｎ値によって与えられる主キーについてＭｅｄｉａテーブルを照会することができる。

フィールドを有しないクラスは、ＳｑｌＲｅｃｏｒｄＩｄである単一の列を有するＳＱＬテーブルに変換される。その例を示す。

ここで、ｂのｏｂｊＩＤが１であり、ｃのｏｂｊＩＤが２であると仮定する。この場合に、ｉｄ １を有する行は、ＢＴＡＢＬＥに現れ、ｉｄ ２を有する行は、ＢＴＡＢＬＥおよびＣＴＡＢＬＥに現れる。

クラス型として型を与えられたクラスメンバは、それを含むクラスについて作成されたＳＱＬテーブルのＳｑｌＲｅｃｏｒｄＩｄ列に変換される。外部キー制約は、この列に課せられる。これは、内部クラス型のサブタイプのインスタンスが、それが含むクラスインスタンスにも存在できる場合であっても可能である。というのは、すべてのｉｄが、ルートクラスレベルで一意だからである。参照される行のｒｅｆＣｏｕｎｔ列およびｒｏｏｔＲｅｆＣｏｕｎｔ列は、適当に維持される。

クラスメンバは、それがクラス型であり、主キーの一部でない場合にはヌル可能である。プリミティブ型および構造体であるメンバは、ヌル可能でない。ＳＱＬテーブル定義で、ヌル可能フィールドは、ヌル可能と指定される。

あるオブジェクトグラフ内のクラスインスタンスＡおよびＢに、お互いへの参照が含まれる時に、ＡおよびＢは、１回だけ保存される。ＡおよびＢに、お互いのＳｑｌＲｅｃｏｒｄＩｄが含まれる。例は次の通りである。

一実施形態で、構造体型は、フィールドを有する別々のテーブルとして変換される。ＣＬＲ構造体は、値型であるが、ｂｏｘｅｄ構造体への複数の参照の場合を最適化するために、独立のテーブルが作成される。構造体は、継承チェーンを有しないクラスと正確に同一に扱われる。

構造インスタンスの各フィールドの値は、テーブル内の列値として保存される。構造体型を有するクラスまたは構造体メンバは、そのクラス用に作成されたＳＱＬテーブル内のＳｑｌＲｅｃｏｒｄＩｄ列に変換される。

第２の実施形態で、構造体型として型を付けられたクラスメンバのメンバは、囲むクラスで構造体型として型を付けられたクラスメンバ名をプリフィックスとする、構造体型のメンバに対応する列名を有する囲むクラスについて作成された同一のテーブルに保存される。

第３の実施形態で、構造体型として型を付けられたクラスメンバのメンバは、囲むクラスのために作成されたテーブルにユーザ定義型（ＵＤＴ）として保存される。

プリミティブ型を有するオブジェクトは、プリミティブ型テーブルとして変換される。プリミティブ型テーブルに、２つの列すなわち、ＳｑｌＲｅｃｏｒｄＩｄ列とプリミティブ型の列が含まれる。一実施形態によれば、プリミティブ型のオブジェクトの選択的な取出および削除が、サポートされない。

プリミティブ型を有するクラスまたは構造体メンバは、次のようにＳＱＬテーブル内の列として変換される。列の値は、プリミティブ型の値である。

配列は、一意のＳｑｌＲｅｃｏｒｄＩｄを発行され、ＯｂｊｅｃｔＡｒｒａｙＴａｂｌｅに、その要素に対応する複数の行として保存される。このテーブルの各行に、配列インスタンスのＳｑｌＲｅｃｏｒｄＩｄおよび要素インデックスが含まれる。実際の要素は、そのインスタンス型に対応するテーブルにス保存される。配列が、クラスのメンバである場合に、配列のＳｑｌＲｅｃｏｒｄＩｄが、囲むクラスに保存される。

ＡｒｒａｙＬｉｓｔ、Ｑｕｅｕｅ：これらは、配列と同一の形で扱われ、ＯｂｊｅｃｔＡｒｒａｙＴａｂｌｅに保存される。

ＨａｓｈＴａｂｌｅ：これは、配列に似た形で扱われるが、ＯｂｊｅｃｔＤｉｃｔｉｏｎａｒｙＴａｂｌｅには保存される。このテーブルの各行に、要素インスタンスのＳｑｌＲｅｃｏｒｄＩｄおよび要素キーが含まれる。

オブジェクトの取り出しおよび照会
オブジェクトは、（１）そのＳｑｌＲｅｃｏｒｄＩＤおよび型を使用して、または（２）選択判断基準および型を使用してという２つの形で取り出すことができる。この型は、永続クラス階層内の、ルートからオブジェクトの実際の型までの任意の型とすることができる。ＳｑｌＲｅｃｏｒｄＩＤが指定され、型がコレクションでない場合には、取り出すために次のステップを実行することができる。

ａ）ＯｂｊｅｃｔＴｙｐｅＴａｂｌｅをルックアップし、その型のルートテーブル名を入手する。

ｂ）オブジェクトの実際の型を入手する。

ｃ）ＯｂｊｅｃｔＴｙｐｅＴａｂｌｅからインスタンスのテーブル名を入手する。

ｄ）ＳＱＬテーブルから行を入手する。

ｅ）テーブル名からＣＬＲ型の完全修飾名を入手する。

ｆ）デフォルトコンストラクタ（永続オブジェクトはデフォルトコンストラクタを有すると期待される）を使用して、入手したＣＬＲ型のオブジェクトを作成する。

ｇ）ＣＬＲ型がプリミティブ型である場合に、値を直接に割り当てる。

ｈ）ＣＬＲ型がクラスまたは構造体である場合に、オブジェクトのフィールドに、行のフィールドを割り当てる。プリミティブフィールドについて、直接に割り当て、他のフィールドについて、再帰的に、レコードｉｄに従い、参照されたオブジェクトを取り出す。参照されたオブジェクト自体が、クラス、構造体、またはコレクションである場合があることに留意されたい。

ｉ）オブジェクトグラフをデシリアライズする間にオブジェクトが１回だけ作成されることを覚えておくこと。

ＳｑｌＲｅｃｏｒｄＩＤが指定され、型がコレクションである場合に、取り出すために次のステップを実施することができる。

ａ）コレクションｉｄとして、指定されたｉｄを用いて、関連するコレクションテーブルの行数を入手する。行と同数の要素をコレクション内で作成する。

ｂ）要素ごとに、再帰的に、オブジェクト取り出しルールに従う。

照会を与えられてオブジェクトを取り出すことは、より複雑であり、次を含む可能性がある。

ａ）照会変換ルールに従い、照会をＳＱＬに変換する。

ｂ）照会を実行し、型のＳＱＬテーブルに一致する行を入手する。

ｃ）行ごとにオブジェクト取り出しルールに従う。

オブジェクトは、（１）そのＳｑｌＲｅｃｏｒｄＩＤおよび型を使用して、または（２）選択判断基準および型を使用してという２つの形で削除することができる。型は、永続クラス階層内の、ルートからオブジェクトの実際の型までの任意の型とすることができる。ＳｑｌＲｅｃｏｒｄＩＤが指定され、型がコレクションでない場合には、削除のために次のステップを実行することができる。

ａ）オブジェクトテーブルからルートテーブルｉｄを入手する。

ｂ）ルートテーブルの行を入手する。ルートｒｅｆカウントを減分する。

ｃ）実際のオブジェクト型を入手する。階層チェーンに従い、オブジェクトに対応する各行のフィールドをたどり、非プリミティブフィールドのレコードｉｄを入手する。

ｄ）非プリミティブフィールドごとに、参照されたテーブルｉｄを入手する。参照された行の到達可能ｒｅｆカウントを減分する。再帰的に、内部非プリミティブフィールドをトラバースし、同一のルールを適用する。両方のｒｅｆカウントが０になる場合に、参照された行を削除する。

ｅ）ルートｒｅｆカウントおよび到達可能ｒｅｆカウントの両方が０である場合に、オリジナル行を削除する。

ステップｃ、ｄは、ｒｅｃｕｒｓｅパラメータに真がセットされている場合に限って行われなければならない。ＳｑｌＲｅｃｏｒｄＩＤが指定され、型がコレクションである場合に、削除のために次のステップを実施することができる。

ａ）コレクションｉｄとして指定されたｉｄを有する関連するコレクションテーブルの行を入手する。

ｂ）要素ごとに、再帰的にオブジェクト削除ルールに従う。

照会を与えられてオブジェクトを削除することは、より複雑であり、次を含む可能性がある。

ａ）照会変換ルールに従い、照会をＳＱＬに変換する。

ｂ）照会を実行し、型のＳＱＬテーブル内の一致する行を入手する。

ｃ）行ごとにオブジェクト削除ルールに従う。

前述に基づいて、さまざまな種類の照会を、上で説明したデータベース構造およびテーブルに保存されたデータに対して実行することもできることをも諒解されたい。図１および２に関して説明した例に対して実行できる照会の非制限的な例を、これから提供する。例えば、郵便番号９８０７４に住んでいる顧客（ｃｕｓｔｏｍｅｒ）の購入注文を取り出すために、ＸＰＡＴＨ照会は、次のようなものになる：／Ｃｕｓｔｏｍｅｒｓ［ｔｙｐｅｏｆ（ａｄｄｒｅｓｓ） ＝＝ ＵＳＡｄｄｒｅｓｓ ＆＆ ａｄｄｒｅｓｓ．ｚｉｐ ＝＝ ９８０７４］／ｏｒｄｅｒｓ。同様に、少なくとも１つの購入注文が未解決である顧客（ｃｕｓｔｏｍｅｒ）の住所を取り出すために、ＸＰＡＴＨ照会は、次のようなものになる：／Ｃｕｓｔｏｍｅｒｓ［Ｃｏｕｎｔ（ｏｒｄｅｒｓ） ＞ ０］／ａｄｄｒｅｓｓ。同様に、少なくとも１つの曲を有する「Ｓｔｉｎｇ」のアルバムを取り出すために、ＸＰＡＴＨ照会は、次のようなものになる：／Ａｌｂｕｍｓ［Ｅｘｉｓｔｓ（ａｒｔｉｓｔｓ， ｎａｍｅ ＝＝ ”Ｓｔｉｎｇ”） ＆＆ ｃｏｕｎｔ（ｓｏｎｇｓ） ＞ ０］。Ｇｒｏｏｖｙという題名のアルバムの曲を取り出すために、ＸＰＡＴＨ照会は、次のようなものになる：／Ａｌｂｕｍｓ［ｔｉｔｌｅ ＝＝ ”Ｇｒｏｏｖｙ”］／ｓｏｎｇｓ。最後に、「Ｗｈｅｎｅｖｅｒ」という題名の曲を含まるアルバムを取り出すために、ＸＰＡＴＨ照会は、次のようなものになる：／Ｓｏｎｇｓ［ｔｉｔｌｅ ＝＝ ”Ｗｈｅｎｅｖｅｒ”］／ａｌｂｕｍ。

前述の実装詳細および本明細書で提供した例にかかわらず、本発明の範囲が、テーブルまたは他のデータ構造が、保存されるクラスのオブジェクトおよびフィールドとデータ型とに関連する属性および他のアドーンメントに応答して作成される、すべての方法、システム、またはコンピュータプログラム製品に広く及んでいることを理解されたい。データを保存するデータベース機構を作成するそのような方法は、データベースに関するプログラマの専門知識に依存するのではなく、データに関する所期の使用の知識だけに依存する。これは、プログラマがデータベースを構成する方法を理解することを必要とするＡｃｃｅｓｓ（登録商標）および他のデータベースツールなどの従来技術システムに対して改善されたことを表す。

本発明は、データベース機構をスケーラブルなものとし、さまざまな異なるデータフォーマットおよびリレーショナルデータベースシステムと相互動作可能とすることも可能にする。したがって、本発明をさまざまなコンピューティング環境で実施できることを理解されたい。本発明を実施できる適切なコンピューティング環境の一例を続けて説明する。

コンピューティング環境 上で説明した方法は、パーソナルコンピュータ、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラマブルなコンシューマエレクトロニクス、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、および類似物を含む、さまざまな構成を有する任意の個数のコンピューティングモジュール、システム、およびネットワークコンピューティング環境の使用を用いて実行することができる。本発明は、通信ネットワークを介してリンクされた（ハードワイヤードリンク、無線リンク、またはハードワイヤードリンクもしくは無線リンクの組合せのいずれかによって）ローカル処理装置およびリモート処理装置によってタスクが実行される分散コンピューティング環境でも実践することができる。分散コンピューティング環境では、プログラムモジュールを、ローカルとリモートの両方のメモリ保存装置に置くことができる。

図４を参照すると、本発明を実施する例示的なシステムに、通常のコンピュータ４２０の形の汎用コンピューティング装置が含まれ、コンピュータ４２０には、処理ユニット４２１、システムメモリ４２２、およびシステムメモリ４２２を含むさまざまなシステムコンポーネントを処理ユニット４２１に結合するシステムバス４２３が含まれる。システムバス４２３は、さまざまなバスアーキテクチャのいずれかを使用する、メモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含む複数の種類のバス構造のいずれかとすることができる。システムメモリに、読取専用メモリ（ＲＯＭ）４２４およびランダムアクセスメモリ（ＲＡＭ）４２５が含まれる。スタートアップ中などにコンピュータ４２０内の要素の間で情報を転送する基本ルーチンを含む基本入出力システム（ＢＩＯＳ）４２６を、ＲＯＭ ４２４に保存することができる。

コンピュータ４２０は、磁気ハードディスク４３９から読み取り、これに書き込む磁気ハードディスクドライブ４２７、リムーバブル磁気ディスク４２９から読み取り、これに書き込む磁気ディスクドライブ４２８、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、または他の光学ディスクなどのリムーバブル光学ディスク４３１から読み取り、これに書き込む光学ディスクドライブ４３０も備えることができる。磁気ハードディスクドライブ４２７、磁気ディスクドライブ４２８、および光学ディスクドライブ４３０は、それぞれハードディスクドライブインターフェース４３２、磁気ディスクドライブインターフェース４３３、および光学ドライブインターフェース４３４によってシステムバス４２３に接続される。ドライブおよびそれに関連するコンピュータ読取可能な媒体は、コンピュータ実行可能命令、データ構造、プログラムモジュール、および他のデータの不揮発性保存をコンピュータ４２０に与える。本明細書で説明する例示的な環境では、磁気ハードディスク４３９、リムーバブル磁気ディスク４２９、およびリムーバブル光学ディスク４３１が使用されるが、磁気カセット、フラッシュメモリカード、ディジタル多用途ディスク、ベルヌーイカートリッジ、ＲＡＭ、ＲＯＭ、および類似物を含む、データを保存するための他の種類のコンピュータ読取可能な媒体を使用することができる。

オペレーティングシステム４３５、１つまたは複数のアプリケーションプログラム４３６、他のプログラムモジュール４３７、およびプログラムデータ４３８を含む、１つまたは複数のプログラムモジュールを含むプログラムコード部を、ハードディスク４３９、磁気ディスク４２９、光学ディスク４３１、ＲＯＭ ４２４、またはＲＡＭ ４２５に保存することができる。ユーザは、キーボード４４０、ポインティング装置４４２、または、マイクロホン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナ、もしくは類似物などの他の入力装置（図示せず）を介してコンピュータ４２０にコマンドおよび情報を入力することができる。上記および他の入力装置は、しばしば、システムバス４２３に結合されたシリアルポートインターフェース４４６を介して処理ユニット４２１に接続される。代替案では、入力装置を、パラレルポート、ゲームポート、またはｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ（ＵＳＢ）などの他のインターフェースによって接続することができる。モニタ４４７または他のディスプレイ装置も、ビデオアダプタ４４８などのインターフェースを介してシステムバス４２３に接続される。モニタのほかに、パーソナルコンピュータに、通常、スピーカおよびプリンタなどの他の周辺出力装置（図示せず）が含まれる。

コンピュータ４２０は、リモートコンピュータ４４９ａおよび４４９ｂなどの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク化された環境で動作することができる。リモートコンピュータ４４９ａおよび４４９ｂのそれぞれは、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の一般的なネットワークノードとすることができ、通常は、コンピュータ４２０に関して上で説明した要素の多くまたはすべてが含まれるが、図４には、メモリ保存装置４５０ａおよび４５０ｂと、それに関連するアプリケーションプログラム４３６ａおよび４３６ｂだけを示した。図４に示された論理接続に、制限ではなく例として提示された、ローカルエリアネットワーク（ＬＡＮ）４５１および広域ネットワーク（ＷＡＮ）４５２が含まれる。そのようなネットワーキング環境は、オフィス全体または会社全体のコンピュータネットワーク、イントラネット、およびインターネットでありふれたものである。

ＬＡＮネットワーキング環境で使用される時に、コンピュータ４２０は、ネットワークインターフェースまたはネットワークアダプタ４５３を介してローカルネットワーク４５１に接続される。ＷＡＮネットワーキング環境で使用される時に、コンピュータ４２０に、インターネットなどの広域ネットワーク４５２を介する通信を確立する、モデム４５４、無線リンク、または他の手段が含まれる。モデム４５４は、内蔵または外付けとすることができるが、シリアルポートインターフェース４４６を介してシステムバス４２３に接続される。ネットワーク化された環境では、コンピュータ４２０に関して示したプログラムモジュールまたはその一部を、リモートメモリ保存装置に保存することができる。図示のネットワーク接続が例示的であり、広域ネットワーク４５２を介する通信を確立する他の手段を使用できることを諒解されたい。

本発明は、その趣旨または本質的な特性から逸脱せずに、他の特定の形で実施することができる。説明した実施形態は、すべての点で例示的であり、制限的でないと考えられなければならない。したがって、本発明の範囲は、前述の説明ではなく請求項によって示される。請求項の意味および同等性の範囲に含まれるすべての変更が、その範囲に含まれる。

対応するデータ型にアタッチされたアドーンメントによる、１特定の実施形態で作成できる型テーブルのセットを示す図である。 対応するデータ型にアタッチされたアドーンメントによる、１特定の実施形態で作成できる型テーブルのセットを示す図である。 対応するデータ型にアタッチされたアドーンメントによる、１特定の実施形態で作成できる型テーブルのセットを示す図である。 対応するデータ型にアタッチされたアドーンメントによる、１特定の実施形態で作成できる型テーブルのセットを示す図である。 対応するデータ型にアタッチされたアドーンメントによる、１特定の実施形態で作成できるもう１セットの型テーブルを示す図である。 対応するデータ型にアタッチされたアドーンメントによる、１特定の実施形態で作成できるもう１セットの型テーブルを示す図である。 本発明の一実施形態による、データを保存する方法に対応する流れ図である。 本発明の方法を実践できる適切なコンピューティング環境の一実施形態を示す図である。

符号の説明

１００ａ Ａｌｂｕｍテーブル
１００ｂ Ｓｏｎｇテーブル
１００ｃ Ａｒｔｉｓｔテーブル
１００ｄ Ｃｏｌｌｅｃｔｉｏｎｓテーブル
２００ａ Ｃｕｓｔｏｍｅｒテーブル
２００ｂ Ｐｕｒｃｈａｓｅ Ｏｒｄｅｒテーブル
４２１ 処理ユニット
４２２ システムメモリ
４２３ システムバス
４２４ （ＲＯＭ）
４２５ （ＲＡＭ）
４２６ ＢＩＯＳ
４３２ ハードディスクドライブインターフェース
４３３ 磁気ディスクドライブインターフェース
４３４ 光学ドライブインターフェース
４３５ オペレーティングシステム
４３６ アプリケーションプログラム
４３６ａ アプリケーションプログラム
４３６ｂ アプリケーションプログラム
４３７ 他のプログラムモジュール
４３８ プログラムデータ
４４０ キーボード
４４６ シリアルポートインターフェース
４４７ モニタ
４４８ ビデオアダプタ
４４９ａ リモートコンピュータ
４４９ｂ リモートコンピュータ

４５１ ローカルエリアネットワーク
４５２ 広域ネットワーク
４５３ ネットワークインターフェース
４５４ モデム

Claims (44)

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. 前記データストアは、ディクショナリ、コレクション、および配列のうちの１つを含むことを特徴とする請求項２３に記載のコンピュータプログラム製品。
38. １つまたは複数のデータ型のオブジェクトを保存し、前記オブジェクトに対応するデータを保存する持続性データストアを作成する方法を実施するコンピュータ実行可能命令を有する１つまたは複数のコンピュータ読取可能な媒体を含むコンピュータプログラム製品であって、前記方法は、
    コードのセグメントで識別された１つまたは複数のデータ型を含むコードの前記セグメントを受信するステップと、
    前記データ型の少なくとも１つに関連する少なくとも１つのアドーンメントを識別するステップと、
    前記少なくとも１つのアドーンメントに基づいて、前記データを保存するのに使用されるスキーマおよび１つまたは複数のデータ構造を判定するステップと、
    前記１つまたは複数のデータ構造が存在するかどうかを判定するステップと、
    前記１つまたは複数のデータ構造が存在しないと判定されると、前記１つまたは複数のデータ構造を作成するステップと、
    前記１つまたは複数のデータ構造に保存されるデータを受信するステップと、
    前記データが既に保存されているかどうかを判定するステップと、
    前記データが既に保存されていないと判定されると、前記アドーンメントおよび前記コードで提供される記述に従って前記１つまたは複数のデータ構造に前記データを保存するステップと
    を備えたことを特徴とするコンピュータプログラム製品。
39. 前記１つまたは複数のデータ構造は、前記１つまたは複数のデータ型の前記アドーンメントおよび定義以外の前記１つまたは複数のデータ構造を定義する特定の入力を受信することなしに作成されることを特徴とする請求項３８に記載のコンピュータプログラム製品。
40. 前記データが既に保存されていないと判定するステップは、前記データ内の前記アドーンメントによって定義された一意の識別フィールドを検査するステップと、前記データ内の前記一意の識別フィールドが前記１つまたは複数のデータ構造内に既に存在しないことを確かめるステップとを含むことを特徴とする請求項３８に記載のコンピュータプログラム製品。
41. 前記１つまたは複数のデータ構造が存在するかどうかを判定するステップは、保存される前記データ型およびデータの照会を最適化するデータ構造を判定するステップを含むことを特徴とする請求項３８に記載のコンピュータプログラム製品。
42. 前記データ構造は、１つまたは複数のデータベーステーブルを含むことを特徴とする請求項３８に記載のコンピュータプログラム製品。
43. 前記１つまたは複数のデータベーステーブルへ前記データを保存するステップは、後の前記データの照会を最適化する形で、前記データの少なくとも一部を前記１つまたは複数のテーブルに取り込むステップを含むことを特徴とする請求項４２に記載のコンピュータプログラム製品。
44. 前記データは既に保存されていると判定されると、前記データを変更するステップをさらに備えたことを特徴とする請求項３８に記載のコンピュータプログラム製品。
    

Images