(57)【特許請求の範囲】
【請求項１】
データ処理装置であって、
（ａ）複数のレコードを記憶する手段であって、該レコードの各々が、
（ｉ）少なくとも１つの属性、
（ｉｉ）前記属性が有効な時間の範囲を示すタイムスパン、
（ｉｉｉ）前記レコードがいつ作成されたかを示す挿入時間、及び
（ｉｖ）前記レコードがコンクリートレコードであるのか、あるいは、直前のレコードの属性値を修正する可能性のあるデルタレコードであるのかを示すタイプフィールドを含む、
記憶する手段、並びに、
（ｂ）既存の属性値及び既存のタイムスパンを有する既存レコードを新たな属性値及び新たなタイムスパンに更新する手段であって、該更新が、前記新たなタイムスパンを前記既存のタイムスパンと比較し、該比較の結果に応じて、多数の異なる所定の動作のうちの１つを実行することからなり、前記所定の動作が、
（ｉ）前記新たなタイムスパンが前記既存のタイムスパンよりも前にある場合には、前記新たなタイムスパンにデルタレコードを付加すること、
（ｉｉ）前記新たなタイムスパンが前記既存のタイムスパンの終了時を包含する場合には、前記新たなタイムスパンにコンクリートレコードを付加し、該既存レコードのタイムスパンを該新たなタイムスパンの開始時に終わるように修正すること、
（ｉｉｉ）前記新たなタイムスパンが前記既存のタイムスパンに完全に包含される場合には、前記新たなタイムスパンに第１のコンクリートレコードを付加し、前記新たなタイムスパンの終了時に続く該既存のタイムスパンの部分に第２のコンクリートレコードを付加し、該既存レコードのタイムスパンを該新たなタイムスパンの開始時に終わらせること、
（ｉｖ）前記新たなタイムスパンが前記既存のタイムスパンを完全に包含する場合には、該既存のタイムスパンの開始時に続く新たなタイムスパンの部分にコンクリートレコードを付加し、該既存のタイムスパンに先行する該新たなタイムスパンの部分にデルタレコードを付加し、該既存レコードのタイムスパンを削除すること、及び
（ｖ）前記新たなタイムスパンが前記既存のタイムスパンの開始時を包含する場合には、該新たなタイムスパンの終了時に続く該既存のタイムスパンの部分にコンクリートレコードを付加し、該新たなタイムスパンにデルタレコードを付加し、該既存レコードのタイムスパンを該新たなタイムスパンの終了時に終わるように修正することからなる、
更新する手段
からなるデータ処理装置。
【請求項２】
挿入時間が視点時間よりも遅くないレコードのみを検索し、検索されたレコードから属性値を構成することにより、指定された視点時間の視点から属性値を検出する手段を含む請求項１記載のデータ処理装置。
【請求項３】
データ処理方法であって、
（ａ）データベースが複数のレコードを記憶するステップであって、該レコードの各々が、
（ｉ）少なくとも１つの属性、
（ｉｉ）前記属性が有効な時間の範囲を示すタイムスパン、
（ｉｉｉ）前記レコードがいつ作成されたかを示す挿入時間、及び
（ｉｖ）前記レコードがコンクリートレコードであるのか、あるいは、直前のレコードの属性値を修正する可能性のあるデルタレコードであるのかを示すタイプフィールドを含む、
記憶するステップ、並びに、
（ｂ）更新機能部が、既存の属性値及び既存のタイムスパンを有する既存レコードを新たな属性値及び新たなタイムスパンに更新するステップであって、該更新するステップが、前記新たなタイムスパンを前記既存のタイムスパンと比較するステップ、及び該比較の結果に応じて、多数の異なる所定の動作のうちの１つを実行するステップからなり、前記所定の動作が、
（ｉ）前記新たなタイムスパンが前記既存のタイムスパンよりも前に場合には、前記新たなタイムスパンにデルタレコードを付加すること、
（ｉｉ）前記新たなタイムスパンが前記既存のタイムスパンの終了時を包含する場合には、前記新たなタイムスパンにコンクリートレコードを付加し、該既存レコードのタイムスパンを該新たなタイムスパンの開始時に終わるように修正すること、
（ｉｉｉ）前記新たなタイムスパンが前記既存のタイムスパンに完全に包含される場合には、前記新たなタイムスパンに第１のコンクリートレコードを付加し、前記新たなタイムスパンの終了時に続く該既存のタイムスパンの部分に第２のコンクリートレコードを付加し、該既存レコードのタイムスパンを該新たなタイムスパンの開始時に終わらせること、
（ｉｖ）前記新たなタイムスパンが前記既存のタイムスパンを完全に包含する場合には、該既存のタイムスパンの開始時に続く新たなタイムスパンの部分にコンクリートレコードを付加し、該既存のタイムスパンに先行する該新たなタイムスパンの部分にデルタレコードを付加し、該既存レコードのタイムスパンを削除すること、及び
（ｖ）前記新たなタイムスパンが前記既存のタイムスパンの開始時を包含する場合には、該新たなタイムスパンの終了時に続く該既存のタイムスパンの部分にコンクリートレコードを付加し、該新たなタイムスパンにデルタレコードを付加し、該既存レコードのタイムスパンを該新たなタイムスパンの終了時に終わるように修正することからなる、
更新するステップ
からなるデータ処理方法。
【請求項４】
挿入時間が視点時間よりも遅くないレコードのみを検索し、検索されたレコードから属性値を構成することにより、指定された視点時間の視点から属性値を検出するステップを含む請求項３に記載のデータ処理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、タイムバージョンデータ記憶装置に関するものである。
【０００２】
【従来の技術】
（例えば、関係データベースなどの）従来のデータ記憶装置では、データ記憶装置への問合せが行なわれると、最後の更新日に、データの現行状態を反映した結果が返却される。また、既存バージョンシステムは、変更は必ず現行状態に対して行なわれるものであり、過去や将来の変更はサポートされていないという前提のうえに成り立っている。
【０００３】
【発明が解決しようとする課題】
しかしながら、将来のある選択された地点からデータの状態を見ることができる方が好ましい。さらに、現行状態だけでなく、過去または将来のシステム状態を変更できることが好ましい。ところが、従来のデータ記憶装置は、そのような機能を有していない。
【０００４】
そこで本発明は、将来の任意の選択された地点からデータの状態を見る機能をサポートする新規データ記憶装置を提供することを目的とする。
【０００５】
【課題を解決するための手段】
本発明によれば、複数のレコードを記憶する手段からなるデータ処理装置において、各レコードが、
(a)少なくとも１の属性と、
(b)前記属性が有効なタイムスパンを示すタイムスパンと、
(c)レコードがいつ作成されたかを示す挿入時間と、
(d)そのレコードが、コンクリートレコードか、あるいは、直前のコンクリートレコードまたはデルタレコードの属性値を修正する可能性のあるデルタレコードであるかを示すタイプフィールドとを具備するデータ処理装置。
【０００６】
【発明の実施の形態】
本発明によるタイムバージョンデータ記憶装置を具備する１データ処理装置について、添付図面を参照し、例を示しながら以下に説明する。
【０００７】
このデータ記憶装置では、オブジェクトのタイムバージョンビューをサポートしている。その中心にあるのは、将来のある特定の地点からオブジェクト状態を見ることができる能力であり、「１９６０年に行なわれていれば、どのような評価結果が得られたか」などの問合せをサポートする能力である。そこには、次の２つの主要な概念がある。
1)視点時間ＴV。これは、状態が観測されている時間的な地点である。
2)目標タイムスパン［ＴS、ＴE］。これは、データが必要とされるタイムスパンである。
【０００８】
例えば、［ＴS、ＴE］とＴVが、いずれも「１９６０年１月１日」であれば、ちょうど１９６０年現在のシステム状態を表していることになる。 ＴVが１９９５年１月１日であり、［ＴS、ＴE］が共に１９６０年１月１日であれば、１９６０年現在のシステム状態ではあるものの、１９９５年までに１９６０年の状態に対して（例えば、１９６０年の状態に見られるエラーを修正するなどの）何らかの変更が加えられることを示している。また、さらに、例えば、「１９９９年１月１日から、XはYに居住している予定である」という事実を通知された場合など、オブジェクトの将来の状態について検討するうえで適している。
【０００９】
前述したような行為をサポートするためには、オブジェクト状態への修正はすべて、修正が行なわれた時間と修正が適用される時間に必ず対応づけられていなければならず、また、どの情報も必ず修正過程で失われてはならない。
【００１０】
さらに実際に重要になる点は、タイムバージョン状態（オンラインとアーカイブのいずれも）を維持するうえで必要な記憶量と、記憶データからオブジェクト状態に関する特定のビューを構成する際に伴う処理コストのいずれに換算した場合も、アプローチに関するコストである。以下の説明は、次の各事項を仮定して行なわれている。
【００１１】
1)オブジェクト状態の通常の使用パターンは、過去または将来の状態ではなく、「現行状態」である。現行状態は、通常、「現在からXまで」ではなく、「今後」の状態である。
【００１２】
2)通常の更新パターンは、過去または将来の状態への変更ではなく、現行状態への変更である。ここで、変更は、通常、「現在からXまで」ではなく、「今後」適用される。
【００１３】
3)一定の時期よりも古いデータに対しては、アーカイビング法を使用しなければならない。
【００１４】
［システム概要］
図１について説明すると、本装置は、コンピュータシステム１０からなり、データベース１１と、データベースのデータにアクセスするクライアントアプリケーション１２を具備している。クライアントは、更新機能１３と読取り機能１４により、データベースにアクセスする。さらに、本装置は、アーカイブ記憶装置１５を具備している。
【００１５】
［データベース］
データベースは、多数のレコード（または行）からなり、各レコードは、以下のフィールド（または列）から構成されている。
【００１６】
ＵｎｉｑｕｅＩＤ：  この一意名によって、レコードに対応するオブジェクトが識別される。例えば、顧客や従業員などの特定の人を識別するのに用いられる。
【００１７】
Ａｔｔｒｉｂｕｔｅｓ：  レコードに対応するオブジェクトの１つ以上の属性。例えば、レコードに、人の名前、給料、誕生日等を表す属性が含まれていてもよい。さらに、「なし」（値がないことが明らかな場合を示している）や「不明」（値があるか否か明らかでないことを示している）を表す特殊な値が含まれていてもよい。
【００１８】
ＳｔａｒｔＴｉｍｅ：  このレコードに含まれているデータが定義されるタイムスパンの開始時点。
【００１９】
ＥｎｄＴｉｍｅ：  このレコードに含まれているデータが定義されるタイムスパンの終了時点。
【００２０】
ＩｎｓｅｒｔＴｉｍｅ：  このレコードが作成された日付け。
【００２１】
Ｔｙｐｅ：  レコード型。この値には、「ｃｏｎｃｒｅｔｅ」、「ｄｅｌｔａ」、「ａｒｃｈｉｖｅ」の３つの値のうちのいずれか一つを使用できる。
【００２２】
本例では、 ＳｔａｒｔＴｉｍｅ、 ＥｎｄＴｉｍｅ、 ＩｎｓｅｒｔＴｉｍｅが、単純データ形式（ｄｄ／ｍｍ／ｙｙｙｙ）で定義されている。特殊なデータ値である「ｔｏｐ」と「ｂｏｔｔｏｍ」は、仮定された最大および最小限度の日付けを示すためのものである。
【００２３】
「 ｃｏｎｃｒｅｔｅ」レコードは、指定されたタイムスパンにわたるオブジェクトの属性値を示すレコードである。 コンクリートレコードのＳｔａｒｔＴｉｍｅ値は、非包含的な値である。すなわち、その値は、タイムスパンが実際に開始する１日前に相当する。 これに対し、ＥｎｄＴｉｍｅフィールドは、包含的な値であり、タイムスパンの実際の終了時に等しい。その効果は、隣接する実際のレコードがある場合、あるレコードのＥｎｄＴｉｍｅが次のレコードのＳｔａｒｔＴｉｍｅに等しくなることにある。
【００２４】
「ｄｅｌｔａ」レコードは、通常、既存のコンクリートレコードや可能性として考えられる他のデルタレコードに関して、（適正でない）属性値のサブセットを捕獲するレコードである。また、その影響を受けない属性のフィールドエントリに、「ｕｎｕｓｅｄ」という値がある。「ｃｏｎｃｒｅｔｅ」レコードと異なり、 「ｄｅｌｔａ」レコードのＳｔａｒｔＴｉｍｅは、包含的な値である。
【００２５】
「ａｒｃｈｉｖｅ」レコードは、指定されたアーカイブポイント時間ＴAを含むそれまでの挿入時間を持つ値がアーカイブされたことを示している。これらの値にアクセスする必要があるときは、アーカイブ記憶装置に問い合わせなければならない。
【００２６】
以下の説明と図では、明快さを考慮して、ＵｎｉｑｕｅＩＤフィールドが省略されており、各オブジェクトには単一の属性値しか含まれていないものと仮定している。
【００２７】
［データベースの更新］
更新機能に関する以下の説明において、引用されているすべてのコンクリートレコードの開始時間は、実際の開始時間であり、（実際の開始時間よりも１少ない）記録された開始時間ではない。このことから、論理アルゴリズムが影響を受けないことがさらに理解しやすくなる。
【００２８】
図２に、データベース更新機能について示されている。ここでは、目標タイムスパン［ＴS、ＴE］の新規の値Ｙで特定の属性を更新しなければならない状態が仮定されている。
【００２９】
（ステップ２１）  更新機能は、まず初めに、「ｃｕｒｒｅｎｔ  ｔｉｍｅ」にＴVを設定し、設定タイムスパン［ＴS、ＴE］にわたって、下記のデータベース読取り機能（ステップ４１、４２、４４、および４５のみ）を使用する。これによって、０またはそれ以上のコンクリートレコードが返却される。興味深い値として、最新のコンクリートレコードＣIがある。この値は、属性値Ｘとタイムスパン［ＴSTART、ＴEND］を有していると仮定されている。このような既存のコンクリートレコードが検出されない場合は、その更新が属性を作成する前の時点に適用されていることが暗に示されている。
【００３０】
（ステップ２２）  既存のコンクリートレコードが検出されない場合や、このような既存レコードのタイムスパンが「トップ」まで達していない場合は、属性値Ｙとタイムスパン［ＴS、ＴE］を有する単一のデルタレコードを作成して、更新が行なわれる。
【００３１】
そうでない場合は、状況はさらに複雑なものとなり、以下に説明する通り、目標タイムスパン［ＴS、ＴE］とクリティカルポイントＴSTARTとの関係によって異なっている。
【００３２】
図３Ａ、３Ｂ、３Ｃ、３Ｄ、３Ｅ及び３Ｆを参照しながら、以下の説明を行なう。これらの図では、コンクリートレコードの開始時間として記憶される値は、実際の開始時間を１下回る値である。
【００３３】
図３Ａは、値Ｘとタイムスパン［０６／０６／１９９６、ｔｏｐ］を有する既存のコンクリートレコードを示している。（ここで、前述した通り、コンクリートレコードのＳｔａｒｔＴｉｍｅは、非包含的な値であり、各コンクリートレコードのタイムスパンの実際の開始は、コンクリートレコードのＳｔａｒｔＴｉｍｅ値よりも実際には１日後である。）したがって、この例において、クリティカルポイントＴSTARTは、０６／０６／１９９６である。図３Ｂ乃至３Ｆでは、各種目標タイムスパン［ＴS、ＴE］に対して、この既存レコードを新規の値で更新した結果を示している。
【００３４】
（ステップ２３）  目標タイムスパン［ＴS、ＴE］が、クリティカルポイントＴSTARTよりも完全に前にある場合、属性値Ｙとタイムスパン［ＴS、ＴE］を有する単一のデルタレコードを作成することによって、更新が行なわれる。例えば、図３Ｂは、目標タイムスパンが［０４／０４／１９９４、０５／０５／１９９５］の場合を示している。
【００３５】
（ステップ２４）  目標タイムスパン［ＴS、ＴE］が、クリティカルポイントＴSTARTよりも後にあり、「トップ」まで達している場合、属性値Ｙとタイムスパン［ＴS、ｔｏｐ］を有する単一のコンクリートレコードを作成することによって、更新が行なわれる。既存コンクリートレコードのＥｎｄＴｉｍｅ値は、 ＴS −１に変更される。例えば、図３Ｃは、目標タイムスパンが［０７／０７／１９９７、 ｔｏｐ ］の場合を示している。
【００３６】
（ステップ２５）  目標タイムスパン［ＴS、ＴE］が、クリティカルポイントＴSTARTよりも後にあるが、「トップ」まで達していない場合、属性値Ｙとタイムスパン［ＴS、ＴE］を有する第１のコンクリートレコードと、属性値Ｘとタイムスパン［ ＴE＋１ 、ｔｏｐ ］を有する第２のコンクリートレコードを作成することによって、更新が行なわれる。既存コンクリートレコードのＥｎｄＴｉｍｅ値は、 ＴS−１に変更される。図３Ｄは、目標タイムスパンが［０７／０７／１９９７、 ０８／０８／１９９８］の場合を示している。
【００３７】
（ステップ２６）  目標タイムスパン［ＴS、ＴE］が、クリティカルポイントＴSTARTよりも後にあり、「トップ」まで達している場合、属性値Ｙとタイムスパン［ＴSTART＋１、ｔｏｐ］を有するコンクリートレコードと、属性値Ｙとタイムスパン［ＴS、ＴSTART］を有するデルタレコードを作成することによって、更新が行なわれる。既存コンクリートレコードのＥｎｄＴｉｍｅ値は、 ＴSTARTに変更される。例えば、図３Ｅは、目標タイムスパンが［０５／０５／１９９５、 ｔｏｐ ］の場合を示している。
【００３８】
（ステップ２７）  上記以外の場合で、目標タイムスパン［ＴS、ＴE］がクリティカルポイントＴSTARTに及んでいるものの、「トップ」まで達していない場合は、属性値Ｘとタイムスパン［ ＴE＋１、ｔｏｐ ］を有するコンクリートレコードと、属性値Ｙとタイムスパン［ＴS、ＴE］を有するデルタレコードを作成することによって、更新が行なわれる。既存コンクリートレコードのＥｎｄＴｉｍｅ値は、 ＴEに変更される。例えば、図３Ｆは、目標タイムスパンが［０５／０５／１９９５、０７／０７／１９９７］の場合を示している。
【００３９】
ただし、既存レコードが更新されるいずれの場合も、更新が、当該レコードのＥｎｄＴｉｍｅ値の変更に限定されている。このような変更は、コンクリートレコードに対してのみ発生し、その場合、必ず「ｔｏｐ」からそれを下回る値ＴXへの変更である。さらにまた、新規コンクリートレコードは、必ずタイムスパン［ ＴX＋１、ｔｏｐ ］にわたって作成される。
【００４０】
また、すでに説明した通り、レコードの更新、すなわち、適正なフィールドに特殊な「ｎｏｎｅ」値を挿入することによって値を削除できる。
【００４１】
このような更新プロセスを用いれば、データベースへの更新中に情報が失われることはないということが明らかである。新規データは、新規データが旧データと入れ代わっていることが推測できるような方法で記録される。
【００４２】
［作成］
目標タイムスパン［ＴS、ＴE］に対して属性を値Ｙで作成することは、上記の更新機能で説明したＸ［ＴSTART、ＴEND］（すなわち、 ＣI）の代わりに、「ｕｎｋｎｏｗｎ（不明）」［ｂｏｔｔｏｍ−１、ｔｏｐ ］な仮定上のコンクリートレコードを更新することに等しい。その結果、ステップ２４またはステップ２５のどちらかを実行することになり、１または２個のコンクリートレコードを作成することになる。ただし、仮定レコードのＴENDへの変更は、無視される。
【００４３】
［データベースへのアクセス］
図４ではデータベース読取り機能が示されている。この機能により、時間ＴVの視点から、指定されたタイムスパン［ＴS、ＴE］の属性値を知ることができる。
【００４４】
（ステップ４１）  読取り機能によって、データベースへのアクセスが行なわれ、以下の条件を満足するレコードをすべて検索する。
ＩｎｓｅｒｔＴｉｍｅ  ＜＝   ＴVであり、
ＥｎｄＴｉｍｅ  ＞＝   ＴSであり、
ＳｔａｒｔＴｉｍｅ  ＜＝   ＴEである。
【００４５】
この検索によって、０またはそれ以上のコンクリートレコードまたはアーカイブレコードと、０またはそれ以上のデルタレコードが返却される。検索されたレコードは、次のように処理される。（ステップ４２乃至４７について以下に説明する処理は、検索されたレコードのコピー上で実行され、元の記憶レコードは変更されないことは理解できるであろう。）
【００４６】
（ステップ４２）  アーカイブレコードが検出された場合、アーカイブ記憶装置１５に問合せが行なわれ、そのレコードは、アーカイブ記憶装置からの対応するレコードで置き換えられる。このプロセスは、アンパッキングを必要とするアーカイブレコードがなくなるまで、再帰的に繰り返される。
【００４７】
（ステップ４３）  最終コンクリートレコードの終了時間ＴEが「ｔｏｐ」でない場合は、「ｔｏｐ」に設定される。（このレコードの終了時間を「ｔｏｐ」以外のものに変更する更新であれば、その更新は、ＴVよりも後に行なわれたはずであり、したがって、その場合を考慮する必要はない。）
【００４８】
（ステップ４４）  最終コンクリートレコードの開始時間がＴEであれば、そのレコードは廃棄される。
【００４９】
（ステップ４５）  残存しているすべてのコンクリートレコードの開始時間が１だけ増分され、包含的な開始時間が示される。
【００５０】
（ステップ４６）  検索されたデルタレコードは、挿入時間の降順に分類される。
【００５１】
（ステップ４７）  次にレコードは、時間順に時間範囲を走査し、時間の各ポイントに対して、最終ＩｎｓｅｒｔＴｉｍｅを有するレコードを取り出し、その値を読み取って処理される。
【００５２】
このようなプロセスは、基本的な連続するコンクリートレコードの最上部にデルタレコードが積み重ねられ、次に、上から下へ値を見ながら各値を読み取って、最初に出会った値を取り出す形にヴィジュアル化することが可能である。（ただし、同一期間中に、デルタレコードの挿入時間に等しいかそれよりも遅い挿入時間を有するコンクリートレコードは一切存在しない。）コンクリートレコードとデルタレコードのどちらも使用されない期間があれば、この期間中の値は、「ｕｎｋｎｏｗｎ」となる。
【００５３】
例えば、図５では、一連のコンクリートレコードＣ１、Ｃ２とデルタレコードＤ１、Ｄ２、Ｄ３が示されている。各タイムスパンは、水平軸に沿って表されており、挿入時間は、垂直軸に沿って表されている。この例では、読取り機能によって、次のような一連の値が返却される。
Ｃ１  ［ｔ１、ｔ２−１］
Ｄ１  ［ｔ２、ｔ３−１］
Ｄ２  ［ｔ３、ｔ５−１］
Ｄ３  ［ｔ５、ｔ７］
Ｃ２  ［ｔ７＋１、ｔ８］
【００５４】
［アーカイビング］
アーカイビングにより、オブジェクト状態の旧部分をニアラインまたはオフライン記憶装置に格納することにより、主オブジェクト記憶装置の必要記憶量を最小限度に抑えられる。
【００５５】
アーカイビングは、定期的に行なわれるアーカイビングプロセスによって実行される。アーカイビングプロセスでは、データベースをすべて走査し、指定されたアーカイブポイント時間ＴAに等しいかそれよりも早期の挿入時間と終了時間を持つレコードを検出する。これらの各レコードは、アーカイブ記憶装置１５に書き込まれ、データベース１１内の単一のアーカイブレコードで置き換えられる。
【００５６】
このアーカイブレコードには、次のようなフィールドがある。
ＩｎｓｅｒｔＴｉｍｅ  ＝   “ｂｏｔｔｏｍ”
ＳｔａｒｔＴｉｍｅ   ＝   “ｂｏｔｔｏｍ”
ＥｎｄＴｉｍｅ ＝   ＴA
属性  ＝  アーカイブ記憶装置内のアーカイブ済みレコードの位置を示すアーカイブ参照。
【００５７】
このプロセスは、アーカイブレコード自体をアーカイブしながら、繰り返し使用できる。
【００５８】
ただし、アーカイブ期間に使用されるもののアーカイブポイント後に書き込まれたデルタレコードが、アーカイビングプロセスによって取り除かれることはない。
【００５９】
（幾つかの可能性ある変更態様）
前述のシステムに多くの変更を行なっても、本発明の範囲を逸脱しないことは、明らかである。
【００６０】
例えば、データの読取り時に、最も最近の値から、時間を増分させながら値を返却できる。この方法の最大の利点は、アーカイブデータのアンパッキングを、絶対的に必要な状態になるまで延期できる点にある。データのクライアントが、［ＴS、ＴE］のサブセットだけが必要であると判断した場合、この利点によって大幅な節約が可能になる。
【００６１】
記録された開始時間が実際の開始時間よりも１だけ下回る場合、コンクリートレコードを使用する方法を変更して、実際の開始時間を使用することができる。この変更によって生じる影響は、レコードの読取り時に、時間の余分な１単位を考慮しなければならないことであり、余分なコンクリートレコードだけでなく不要なデルタレコードも検出される可能性がある。（このような事態は、問合せ論理を用いることによって回避できるが、すべての読込みにおいて、そのためのコストが増大することになる。）
【００６２】
コンクリートレコードをすべて取り除き、デルタレコードだけを使用することも可能である。ただし、この方法は、システムが必要とする記憶量を削減する一方で、オブジェクト状態と複雑なアーカイビングのアセンブルにかかる処理コストが増大する。
【図面の簡単な説明】
【図１】本発明を具体的に示したデータ処理装置のブロック図である。
【図２】データベース更新機能を示すフローチャートである。
【図３Ａ】データベース更新機能の各動作例を示す図である。
【図３Ｂ】データベース更新機能の各動作例を示す図である。
【図３Ｃ】データベース更新機能の各動作例を示す図である。
【図３Ｄ】データベース更新機能の各動作例を示す図である。
【図３Ｅ】データベース更新機能の各動作例を示す図である。
【図３Ｆ】データベース更新機能の各動作例を示す図である。
【図４】データベース読取り機能を示すフローチャートである。
【図５】  データベース読取り機能の動作を示す図である。
【符号の説明】
１０    コンピュータシステム
１１    データベース
１２    クライアント
１３    更新
１４    読取り
１５    アーカイブ
【図１】
0004101410.tif 000002
【図２】
0004101410.tif 000003
【図３Ａ】
0004101410.tif 000004
【図３Ｂ】
0004101410.tif 000005
【図３Ｃ】
0004101410.tif 000006
【図３Ｄ】
0004101410.tif 000007
【図３Ｅ】
0004101410.tif 000008
【図３Ｆ】
0004101410.tif 000009
【図４】
0004101410.tif 000010
【図５】
0004101410.tif 000011