JP2007526564A

JP2007526564A - タイムアドレスされたデータベース管理システム

Info

Publication number: JP2007526564A
Application number: JP2006554168A
Authority: JP
Inventors: イエニー，クラーク
Original assignee: イエニー，クラーク
Priority date: 2004-02-18
Filing date: 2005-02-16
Publication date: 2007-09-13
Also published as: US8874562B2; US20080091704A1; AU2005214911A1; CA2557406A1; EP1740597A4; WO2005079404A3; US20050182776A1; WO2005079404A2; EP1740597A2

Abstract

データベースアプリケーションのためのデータベースを構築する方法であって、この方法は、複数のトランザクション各々について、データベースアプリケーションを介してユーザから入力を受け取る工程、そのトランザクションについて受け取った入力を組み込む対応レコードを構築する工程、その対応するトランザクションが終了した時を同定するタイムアドレスを付加する工程、およびそのトランザクションの対応レコードを不揮発性データ記憶装置に記憶する工程であって、その対応するレコードのタイムアドレスはその記憶された対応レコードに永続的に関連付けられ、データベースアプリケーションは通常動作時にその記憶された対応レコードが他のレコードで上書きされることを防ぐ、工程を伴う、方法。
【選択図】図１

Description

本発明は、データベースプログラムおよびデータ構造に関する。

本出願は、２００４年２月１８日に出願された米国仮出願番号第６０／５４５，４５２号の利益を主張するものである。

現代データベース理論の基本的設計原則は、データベーステーブルへの更新には日付を入れず、過去のデータを上書きし、過去のエントリーを消去することである。

リレーショナルデータベース設計理論は、データをその最も基本的な部分に分解し、それらを多数のテーブルに記憶するという原則に基づいている。よって、例えば、オーダーエントリーシステムで用いられるデータは、多数のテーブル上に割り振られる可能性があり、そのようなシステムにおいて新たなオーダーの処理により生じ得るトランザクションでは、典型的には、多数のテーブル内の多数の行を更新することが必要となる。オンライントランザクション処理（ＯＬＴＰ）システムは、それらの複数のレコードの更新を「トランザクション」としてカプセル化しようと試みるが、それは必ずしも可能ではない。マルチユーザ環境では、同じテーブル内の同じ行に対して、複数のユーザまたはプロセスからのアクセスが競合し、結果的に、データベースが適時に素早い反応で全ての更新を処理することを妨げるデッドロックおよびロールバックを生じる可能性がある。

全てのトランザクション処理システムにおける問題は、それらが複数のレコードを伴うということである。異なるアプリケーションが異なるトランザクション結果に対処するため、複数のレコードが必要であることが一般に認められた考えであった。例えば、売掛金勘定明細書は、トランザクションの請求局面のみに関係しており、在庫量の局面には関係しない。それゆえ、請求情報は、典型的には、１つのファイル内に記憶され、在庫量情報は別のファイルに記憶される。実際、典型的なトランザクションでは、それぞれが異なる組の出力関数をサポートするように企図された多数の異なるファイルが更新される。

また、伝統的なシステムは、深刻なスペースの制約という暗黙の想定の下で設計されるため、各レコードのバージョンを１つだけ保持するように設計される。現代のデータベースの全てが可変長レコードをサポートしており、これは、レコードが更新されると、同じ場所に納まらなくなる場合があることを意味する。レコードを並べ替えたり、残りのスペースのテーブルを維持しなければならず、スペースまたはパフォーマンスを過度に浪費することなく、効率的なスペースの再利用を試みるように検索アルゴリズムを設計しなければならない。

本明細書中に記載のデータベースシステムは、今日データベース設計者の間で主流であるパラダイム（一時代の支配的考え方を規定している科学的認識体系または方法論）とは異なるパラダイムに基づいている。結果として、現在ＯＬＴＰシステムに必要とされるこの複雑なソフトウェアのいずれも必要としない。

本明細書中に記載のデータベースシステムは、現在のデータベース設計に存在する多岐に渡る問題を共同して解決する少なくとも３つの協働的な特徴を有する。これらの３つの特徴は、タイムアドレスされたデータベース、ドリルダウンインデックスおよび自動化された集計バケットである。一般に、タイムアドレスされたデータベースは、データウェアハウジングおよび大規模な読取り専用トランザクションの問題を解消する。しかしながら、これ自体は更新トランザクションに対処しないため、トランザクション処理の完全な解決策ではない。実際、これは更新トランザクション処理を幾分より複雑なものにする。ドキュメント処理システムにドリルダウンインデックスを付与することにより、トランザクション更新の問題が解決する。しかしながら、集計バケットの問題は完全には解消されないままである。第３の局面、すなわち、自動化された集計バケットがこの問題に取り組む。これら３つの特徴は統合データベースシステムにおいて協働するように設計されるが、これらの特徴のいずれもが既存のデータベースに個別に適用することができ、有用である。

一般に、１つの局面において、本発明は、データベースアプリケーションのためのデータベースを構築する方法であって、この方法は、複数のトランザクション各々について、データベースアプリケーションを介してユーザから入力を受け取る工程、そのトランザクションについて受け取った入力を組み込む対応レコードを構築する工程、そのトランザクションの対応レコードにタイムアドレスを付加する工程であって、タイムアドレスは対応するトランザクションが終了した時を同定する、工程、およびそのトランザクションの対応レコードのコピーを不揮発性データ記憶装置に記憶する工程であって、その対応するトランザクションのタイムアドレスはその記憶された対応レコードのバージョンに永続的に関連付けられ、データベースアプリケーションは通常動作時にその記憶された対応レコードのバージョンが上書きされることを防ぐ、工程を伴う方法を特徴とする。

他の実施形態は以下の特徴のうち１つ以上を含む。この方法はまた、複数のトランザクション各々について、対応レコードに主キーを付与する工程を含む。データベースアプリケーションによって処理される全てのトランザクションについて、レコードがデータベースから取り出されて更新されるか、または新たなレコードが作成されてもよい。新たな対応レコードを記憶する工程は、その対応レコードのバージョンを不揮発性データ記憶装置内のファイルに付与する工程を伴う。より詳細には、その対応レコードのバージョンを対応するファイルの末尾に付加する工程を伴う。この方法はまた、記憶されたレコードのうち特定の１つを削除するコマンドに対して、記憶されたレコードの新たなバージョンを生成すること、記憶されたレコードの新たなバージョンに削除済のフラグを設定すること、記憶されたレコードの新たなバージョンにタイムアドレスを付与すること、および記憶されたレコードの新たなバージョンを不揮発性データ記憶装置内に記憶する一方で、その不揮発性データ記憶装置内に上記特定のレコードの前のバージョンを残したままにしておくことによって応答する工程を伴う。また、この方法は、記憶されたレコード内の情報に対して複数のインデックスを生成し、維持する工程を含む。

すべてのレコードについて、1つの主キーがアプリケーションによって与えられる。主インデックスはこのキーに基づいている。主インデックス内の主キー各々について、 2つの対応するリストが存在する。第１のリストは、不揮発性記憶装置内に記憶されたそのレコードのバージョン全てのタイムアドレスを含む。第２のリストは、不揮発性記憶装置内に記憶されたそのレコードのバージョン全ての記憶アドレスを含む。そのレコードの新たなバージョンが不揮発性記憶装置に付与されるごとに、そのバージョンのタイムアドレスが第１のリストの末尾に付加され、そのバージョンの記憶位置が第２のリストの末尾に付加される。複数の付加的なインデックスの各々のキーが抽出され、レコード内に含まれるデータおよび主キーで構成される。こられのキーの各々は2つの部分を基にしており、その１つ目はレコード内に記憶された情報に基づく代替キーであり、第２の部分は記憶されたレコードの主キーである。この２つの部分からなるキーの各インスタンスごとに、主キーに対応するレコードのどのバージョンが代替キーを含むバージョンであるのかを示すブール（真または偽)値のリストが存在する。二次インデックスは同じ代替キーを有する１つ以上のインデックス含んでもよいが、代替キーおよび主キーの２つの部分が同じインデックスは１つだけである。

一般に、他の局面では、本発明は、データ記憶装置内に複数のレコードを記憶する工程であって、複数のレコードの各レコードは、その最上位において、各キー：値ペアごとに、値がスカラー、値のリストまたはキー：値ペアマップであり、各リストまたはキー：値ペアマップ内の各値も同様にスカラー、値のリストまたはキー：値ペアマップであり、その他同様にして無制限に階層が続き得るキー：値ペアマップを特徴とする共通構造を有し、キー：値ペアマップがそのレコード内の１つ以上のサブレコードを表すために用いられ得る、工程、複数のドリルダウンインデックスを生成し、維持する工程であって、複数のドリルダウンインデックスの各々は対応するマルチパートキーに基づいており、複数のレコード内のレコードに含まれる対応するサブレコードから情報を抽出するためのものである、工程を伴うデータベース方法を特徴とする。

他の実施形態は以下の特徴のうち１つ以上を含む。複数のレコードの記憶は記憶された複数のレコード各々の各バージョンにタイムアドレスを付与することを伴い、タイムアドレスは対応レコードの対応するバージョンが作成された時を同定し、上記記憶されたレコードの主インデックスは上記記憶されたレコードのタイムアドレスを含み、各インデックスにおいて、複数の代替インデックスが、主キーおよび対応レコードのどのバージョンが対応する代替キーを含むのかを示すブール（真または偽）値のリストを含む。

一般に、さらに他の局面では、本発明は、レコードのデータベースを管理するデータベースアプリケーションの集計情報を維持する方法を特徴とし、この方法は、データベースレコード内で見つかった１つ以上の数量関連属性に関連付けられたキーのインデックスを構築する工程であって、このインデックスは、キーの異なるインスタンスごとに、そのキーのインスタンスに関連付けられた１つ以上の数量関連属性の値全ての合計である累積値を含む集計バケットを維持する、工程、およびデータベースに新たなレコードが付加されるごとに、インデックス内の集計バケットを自動的に更新する工程を含む。

他の実施形態は以下の特徴のうち１つ以上を含む。自動更新は、新たなレコードが追加されるたびに、その新たなレコードを走査し、そのファイルについての集計バケットの定義と一致する属性のインスタンスを探すこと、それらのインスタンスに関連付けられた値を抽出すること、および抽出された値をインデックスに記憶された適切な集計バケットに付加することを伴う。

他の実施形態は以下の特徴のうち１つ以上を含む。１つ以上のインデックスが揮発性メモリ内に記憶されてもよい。メモリが消去されると、それらのインデックスは、データベース内の複数のレコードを走査し、上記インデックスを再構築することにより再構築される。

本発明の１つ以上の実施形態の詳細を添付の図面および下記の説明において示す。本発明の他の特徴、目的および利点は、下記の説明および図面ならびに請求の範囲により明らかとなる。

（タイムアドレスされたデータベース）

一般に認められた会計実務の最も基本的な原則の１つは、一組の帳簿またはレコードへの全ての記帳には日付が入れられ、発生順に付加されることである。エントリーが消去または変更されることは決してない。コンピュータデータベース管理システムの第１の用途は会計帳簿およびレコードの維持であるが、現代データベース理論の基本的な設計原則は、データベーステーブルへの更新には日付を入れず、過去のデータを上書きし、過去のエントリーを消去することである。

本明細書中に記載の実施形態は、会計モデルとより良い整合性を有する方法でデータを管理する。テーブル（すなわち、ファイル）内の各行（すなわち、レコード）は多数のバージョンを有する可能性があり、それらのバージョンの全てがデータベースの一部となる。データベース内の行は、キーだけではなく、キーおよびタイムアドレスによりアクセスされる。換言すれば、各レコードの各バージョンは、そのレコードのそのバージョンが作成された時を表す時間によって同定される。

図１を参照して、記載される実施形態は、ツリーおよびリスト構造を用いてデータベースへの主インデックスを実現している。インデックスの最上位はキーで分類される。このツリーの各節点１２（１）．．．１２（ｎ）は、一対のリスト１４を含む。第１のリスト１５は、不揮発性記憶装置内のレコードのバージョン全てのタイムアドレスを二次記憶装置に付与された順に含む。第２のリスト１６は、対応する各バージョンが記憶される不揮発性記憶装置内の記憶アドレスを含む。

アプリケーションがレコードをその主キーに基づいて探すとき、第１のツリーを検索してキーの一致を見つける。キーの一致が見つかった場合、見つかった葉節点は、キーの一致を満足するレコードのバージョン全てのタイムアドレスおよび記憶アドレスを含む。

図２を参照して、記載される実施形態は、ブール（真または偽)値のツリーおよびリスト構造を用いてデータベースへの代替インデックスを実現する。このインデックスの最上位は、代替キーおよび主キーによって分類される。このツリーの各節点２０（１）．．．２０（ｎ）は、対応する主キー葉節点１４における一対のリストに対応するブール値のリスト２２（１）．．．２２（ｎ）を含む。このリスト内の真の値は、この代替インデックスが対応レコードの対応するバージョンにおいて少なくとも一度は発生することを示す。偽の値は、この代替インデックスが対応レコードの対応するバージョンでは発生しないことを示す。主キー葉節点１４における一対のリストが対応する代替キー葉節点におけるブールのリストよりも長い場合、代替キー葉節点において見当たらないブール値は偽とみなされる。

インデックス内のツリーの代わりに他の構造を用いることも可能である。しかしながら、ツリーおよびリスト構造は、タイムアドレスを可能にするインデックスマッピング概念のアーキテクチャを厳密に反映する。単一レベルのツリーならびにキーおよびタイムアドレスから構成されるマルチパートキーを用いても同じ結果を得ることが可能である。

アプリケーションがレコードを探す場合、ツリーを検索してキーの一致を見つける。検索が主キーにより行なわれ、キーの一致が見つかった場合、見つかった葉節点は、キーの一致を満足するレコードのバージョン全てのタイムアドレスおよび記憶アドレスを含む。検索が代替キーにより行なわれ、第１の部分と求めていた代替キーが一致するキーが見つかった場合、見つかったキーの第２の部分から主キーが抽出され、これが主キーインデックスからリストペアを抽出するために用いられる。代替キーインデックスの葉節点におけるブールリストが、主キーインデックスからのリストペアと比較され、見つかった代替キーをレコードのどのバージョンが含むのかを判定する。

データベース内のデータまたは情報を検索するために、検索要求でタイムアドレスを特定することができる。タイムアドレスが特定されれば（例えば、ｔ_{ｄｅｓｉｒｅｄ}）、アプリケーションは、≦ｔ_{ｄｅｓｉｒｅｄ}であり、かつ代替インデックスの場合にはその所望のキーが対応するバージョンに存在する直近のタイムアドレスを探す。この場合、アプリケーションおよびユーザには、データベースがその特定の瞬間の状態で現れる。しかしながら、タイムアドレスが特定されない場合、アプリケーションは最新のバージョンにアクセスし、データベースは、従来のデータベース同様、「現在の」状態を絶え間なく変化させながら動作する。このように、本明細書中に記載のデータベースは、データベースおよび継続的にタイムアドレス可能なデータウェアハウスの２つの役割を果たす。

上述の実施形態では、タイムアドレスの粒度は１秒であるが、これは、所望の性能に応じて他の値に設定することができるパラメータである。１秒の粒度を考慮すると、所与のタイムスタンプについて１つより多くのバージョンが存在する可能性がある。１つのレコードに複数のバージョンが存在する場合、アプリケーションはその期間における最新のバージョンを選ぶ。

このデータベースシステムでは、レコードの削除が実際には「削除済」というフラグが設定されたレコードの新たなバージョンである。削除されたバージョンのキーおよびタイムアドレスを用いてデータベースがアクセスされると、レコードが存在しなかったかのような結果になるが、過去のタイムアドレスにはレコードが存在する。そのレコードのより新しいバージョンも未削除の状態で存在する可能性がある。換言すれば、「削除」という概念は単に状態の問題であり、レコードがデータベースから取り除かれたことを意味するわけではない。

データベースは、時々、不要になったレコードのバージョンを取り除くために「パージ」されてもよい。これは、単純に、１つの物理ファイルから別のファイルへとレコードをコピーし、切捨てを設定した日付以前の最新ではないバージョンを省くことにより行なうことができるが、所与のファイル内のレコードを「インプレース」でシャッフルすることを始めとする他の方法を採用することもできる。最も単純な手法が好ましい。

データベースタイムアドレシングは、レコードバージョニングとは区別されるべきである。異なる請求書は異なるタイムアドレスを有し、それゆえ、データベースは、各請求書が１つのバージョンしか有さなかったとしても多数のバージョンを有する。タイムアドレシングは、主に、データベース全体の過去のバージョンにアクセスするためのものであり、個々のレコードの過去のバージョンにアクセスするためのものではないが、そのようにも動作する。

バージョニングにより恩恵を受ける個々のレコードは顧客レコードである。例えば、顧客は異なる課税管轄区域に移動する可能性があるが、その顧客の履歴内の各請求書に適用可能な課税管轄区域は、その時点に居住していた課税管轄区域によって決まる。税務当局が監査を求めた場合、各請求書の日付における各顧客の正確な発送先および請求先住所へのアクセスを有することが非常に役立つ。この概念はまた結婚状況、氏名、および他の顧客属性にも適用されるが、これらは所得税、従業員手当等に適用されるためである。

タイムアドレシングはあらゆる問題を自動的に解決するものではないが、多数の問題を解決することができる十分な情報を維持する。データベースは、「静的」データでさえも時間とともに変化するという事実を反映するべきである。この手法は、アプリケーションソフトに履歴レコードを維持させるよりもはるかに単純である。
（単一トランザクションレコード）

現代のリレーショナルデータベースシステムの重要な特徴は、レコードのリスト的な属性が個別のテーブルに記憶されることである。例えば、各顧客が単一の基本レコードにより表されるが、各顧客が複数の発送先住所、電話番号、および同様のデータを有する可能性がある場合、これらの属性の複数の値が、対応する顧客行への主キーおよび個別のテーブル各々の各行に固有キーを与えるために十分な他の部分から構成されるマルチパートキーとともに、個別のテーブル内の個別の行として記憶される。この手法は、複数のテーブルを同期させて維持する必要があるという明白な不利点を有する。しかしながら、リレーショナルデータベース理論では、詳細レコードが他のレコード内に階層的に記憶されることを防ぐという要件が存在せず、個別のテーブルを使用するという慣行は、リレーショナルデータベース理論の反映というより、むしろ以前のデータベース制約によるアーチファクトである。上述の実施形態は、個別のテーブルを用いずに、またはトランザクションを整合的、アトミック（atomically）に、そして複数のテーブルが関係する場合には他のトランザクションと分けて更新することに関連する問題を生じずに相関的整合性および機能性を維持する。ドリルダウンインデックスが、個別のテーブルの個別のインデックスと置き換わり、１つのファイルのレコード内に含まれるサブレコードを繋ぎ合わせることで、それらが１つの個別テーブル内に存在するかのようにアクセスすることができる。それらを個々に更新することはできないが、含まれるレコードの一部としてのみ更新できるという事実は、不利点ではなく利点であり、これは、この要件がトランザクションおよび参照整合性の両方を強化するからである。

タイムアドレスされたデータベースは、マルチレコードトランザクションの更新をより困難なものにする。更新の全てが同じタイムスタンプを有さない限り、データベースは、１つのトランザクションを２つの部分に分けるタイムアドレスでアクセスされる可能性がある。１つのトランザクションにおけるレコードの全てに同じタイムスタンプを持たせることによりこの問題は解決するが、別の問題が生じる。２つ以上のトランザクションが時間的に重なる場合、すなわち、一方が終了する前に他方が開始される場合、同じレコードを両方のトランザクションによって更新することができるが、時間的により後のタイムスタンプを有するトランザクションが最初にレコードを更新する可能性がある。結果的に、これにより、タイムスタンプシーケンス外のバージョンが生じる。

これは、従来のデータベースでも同様に発生し得るが、それらでは、瞬間的な異常に過ぎない。これは、タイムアドレスされたデータベースについては、全てのレコードの全てのバージョンが原則としてタイムアドレスによってアドレス可能なため、永続的なアーチファクトとなる。タイムアドレスされたデータベース内のトランザクションデータを整合させるためには、全てのトランザクションを完全に連続して並べなければならず、これは、システムおよびプログラマーに大きな負担を課す。上述の実施形態は、マルチレコードトランザクションをなくすことでこの付加的な問題を解決する。

本明細書中に記載のデータベースシステムの根底をなす考えは、原則として、特定のデータベースアプリケーションの機能性をサポートするために必要な全ての情報がそのデータベースアプリケーションについて定義されるまたは定義可能なドキュメント（または限られた数のドキュメントタイプの群）と関連付けられるかまたはそれらを基にするという認識である。これは、請求書トランザクションドキュメントを一例とするビジネスアプリケーションに関して特に明白である。請求書トランザクションドキュメント内では、そのようなドキュメントに典型的に関連付けられたデータを、請求情報を含むいくつかの部分と、在庫量情報を含む他の部分からなる「サブレコード」にまとめることができる。よって、アプリケーションにおいてデータまたは情報を最も効率的に扱う方法は、データベースアプリケーションにおいて現在行なわれているように多数の異なるテーブル間への割り振りではなく、１つのレコードに入れることである。そうすることで、その特定のトランザクションについての必要な情報全てを単一のレコードから抽出することができる。

請求書以外にビジネスデータベースを背景として関連性を有し得る他のドキュメントの例として、購入注文、給与支払用文書および会計文書がある。実際、１つのデータベースアプリケーションにおいて、各々が独自のサブレコードの階層構造を有するレコードタイプにより表される複数のドキュメントタイプを、異なるドキュメントが同様のサブレコードを共通して有するように用いることは有用であり得る。これらのサブレコードは、共通のインデックスによりインデックス付けされることで、複数のドキュメントの同様のデータを報告または解析等の目的のために組み合わせることができる。よって、単一のファイル内に異なるレコードタイプが存在する。１つのレコードタイプを他のタイプと区別するために、そのレコードの主キーに接頭部を付加することができる。

上述の実施形態は多数テーブル設計と最小数のテーブルの組に基づく設計とを置き換える。特に、所与のデータベースアプリケーションについて、最小数のトランザクションファイルが存在し、そのアプリケーションについて定義されるような所与の更新トランザクションの詳細の全てが、その更新トランザクションのインターフェースまたはメカニズムである「ドキュメント」を表す単一のレコードに組み入れられる。そのドキュメントの規格は、特定のデータベースアプリケーションおよびそのデータベースアプリケーションが提供する必要がある特定の機能性に依存する。そのため、理論的には、データベースアプリケーションの詳細に応じて、ドキュメントが非常に大きく、非常に複雑になる可能性がある。よって、潜在的なドキュメントの内容を組み入れるレコードは、任意のサイズおよび複雑さを有することを可能にする構造を有する必要がある。

ここで説明するレコード構造は上記の要件を満たす。これは、レコード内に階層的にレコードを記憶することができ、レコードを掘り下げてサブレコードを抽出できるインデックスを定義することができるものである。それゆえ、例えば、上述した請求書の例を用いると、レコードは請求サブレコードおよび在庫量サブレコードを含むように設計できる。その場合、請求サブレコードを顧客キーおよび日付によって抽出するために用いられるドリルダウンインデックスならびに在庫量サブレコードを製品キーおよび日付によって抽出するために用いられる別のドリルダウンインデックスが存在し得る。それゆえ、レコード構造は、関連づけられたドリルダウンインデックスとともに、複数の機能を果たすが、トランザクションは、単一のレコードのデータベースへの１回の書き込みで更新される。この手法により、ＯＬＴＰに関する深刻な問題の全てがなくなるが、これは、それらの全てがマルチレコード更新に付随するためである。

レコードは、最上位では、キー：値ペアマップから構成される。これらのキー：値ペアは、属性としても知られるリレーショナルデータベースの列と類似しており、キーが列の見出しを表し、値が各列の行の値を表す。レコードの階層構造を実現するために、上位キー：値ペアマップの値は、スカラーまたはプリミティブタイプに限定されない。それら自体がマップ、アレイ（リスト）または他の構造であってもよい。上述した実施形態は、所望するいかなるレベルの複雑さにも組み合わせることができるアレイおよびマップをサポートする。

レコード内のデータは、プレーンテキスト、すなわち、中括弧、角括弧、一重引用符および等号文字（＝）で区切られた文字列の形式で記憶される。ドキュメント全体を現す高位マップを始めとする各マップは中括弧に入れられる。このマップ内では、キーは、下線文字以外のいずれのスペースまたは句読記号も含まない文字列として表される。キーの後には等号文字が続く。このキー：値ペアの値がスカラーである場合、一重引用符で閉じられたスカラーを表す文字列が後に続く（スカラー内に現れる一重引用符は、そのいずれもがバックスラッシュ文字をその前に置くことによって区切られ、現れるバックスラッシュ文字は、そのいずれもが２つのバックスラッシュ文字と置き換えることにより区切られる）。よって、単一のキー：値ペアのレコードはこのようになる：
{name='John Doe'}

さらなるキー：値ペアが連続して続く。（値とキー間でのコンマおよびスペースの選択は自由であり、ここでは、単に明瞭にするために付加して示している。）本実施形態はキー：値ペアを分類しているため、３つのキー：値ペアを含むレコードはこのようになる：
{address='123 Main Street', city='Boston, MA', name='John Doe'}

値はマップまたはアレイであってもよい。アレイは角括弧で閉じられ、マップは中括弧で閉じられる。共通した有用な構造は、マップのアレイである：
{details=[{detail map}, {detail map2}, {detail map3},...]}

請求書レコードは、例えば、各行項目につき１つのマップからなるマップのアレイを含む「details」と呼ばれるキー：値ペアを含んでいる可能性があり、これらのマップの各々は単一の行項目（部品番号、数量、価格等）の詳細の全てを表す。

レコード内のマップおよび（上記したような）レコード内のアレイ内のマップは、インデックス付けすることができる。この種のインデックスは、ドリルダウンインデックスと呼ばれる。このように、「請求書」テーブル内のサブレコード「詳細」はインデックス付けすることができ、製品番号によりインデックス付けされた個別のテーブルとして見えるようにすることができる。外部、例えばＳＱＬ文に対しては、テーブル名はピリオドによって各パートが区切られた複数のパートからなる。
例：
SELECT quantity, price FROM invoice. details WHERE product_number...

上述の実施形態では、レコード内のキー：値ペアのシーケンスがキーによって順番付けされる。しかしながら、これは必要条件ではない。これは、２つのレコードの同等性をより効率的に比較するための単なる便宜である。また、手動によるレコードの編集をより容易にもする。なお、レコードの中にはいくつかのキーが省略されるものもあるため、所与のキーの順序位置は、異なるレコード間では異なり得ることに留意されたい。

典型的なＳＱＬリレーショナルデータベースは、列が明確に定義されており変化しない固定直線構造である。すべてのレコードがすべての列のインスタンスを有しており、それ以外は何も有さない。このように情報をまとめることは好都合であることが多い。それゆえ、所望であれば、上述したレコード構造は、アプリケーションに、用いられたキーに関する行ごとの整合性を維持させることが可能である。しかし、これは厳密な要件ではない。

現実の世界では、アプリケーションは進化しており、寿命が非常に長い。Ｅメールアドレスおよび携帯番号が広く用いられるようになったのは多数のレガシーアプリケーションが書き込まれてからかなり後になってからである。アプリケーションを適合させるためには、既存のアプリケーションおよびデータについて大きな混乱を生じることなく、テーブルに対する「列」（属性）の追加または削除をかなり自由に行なうことができるようにする必要がある。それゆえ、アプリケーションが進化するにつれ、新たなドキュメントレコードには現れるが、古いドキュメントレコードには現れない新たな属性を導入してもよい。同様に、古い属性は新しいレコードから省略されてもよい。この柔軟性を可能にするアプリケーションは、既存のデータの変更を必要とすることなく、データベースを時間とともに進化させることを可能にする。上述したレコード構造は、アプリケーションがレコードをマップとして扱うことを可能にし、新たなキー：値ペアをそれらのマップに自由に追加することを可能にする。
（付加専用記憶モデル）

上述の実施形態では、各論理トランザクションは単一のレコード内にカプセル化されるが、これは厳密な要件ではない。このようにトランザクションをカプセル化した場合、トランザクションの処理はレコードの更新と同義である。図４を参照して、上述の実施形態では、プロセス４２により、所与のファイルへの更新の全て（すなわち、レコードの新たなまたは修正されたバージョンの全て）がオペレーティングシステムの基礎となるファイルシステム内の対応するファイル４０の末尾に付加される。これにより、図３を参照すると、全てのレコードバージョン（および上述の実施形態については、全てのトランザクション）３０（１）．．．３０（ｎ）が対応するファイル３２内で順次発生順に配列されるが、これは潜在的に非常に長くなり得る。

典型的には、ユーザがトランザクションを終了し、その旨を入力したいことを示すユーザが開始したコマンドまたはユーザ入力に応答して、クライアント５６はトランザクションレコード、トランザクションレコードの主キーおよび削除に関する真／偽フラグをサーバー４４に投入し、プロセス４２により、この情報にタイムスタンプ３４を付与し、この情報をレコード３０（ｎ）としてファイル３２の末尾に書き出す。アプリケーションは、レコードが完成し、ユーザが特定のトランザクションに必要な全ての情報を適切に付与するまでクライアント５６からサーバ４４へのレコードの投入を妨げる、ある種の抑制均衡機能を有していてもよい。プロセス４２によりレコードをファイルに書き込む場合、トランザクションが記憶された時間を同定するタイムスタンプ３４がレコードの先頭に付与される。上述の実施形態では、タイムスタンプは、世界時間座標における現在時刻のＡＳＣＩＩ表現である数字列である。この後に、レコードの主キー３５、レコードが削除された場合には文字「１」として符号化され、そうでない場合には文字「０」として符号化される削除フラグ３６、およびトランザクションレコード自体のテキスト表現が続く。組み合わされたレコード３０は改行文字で終了する。レコード内に改行文字が存在する場合、それらは、データベースへの出力時には、Ｃ言語エスケープシーケンス「＼ｎ」に置き換えられ、データベースからの入力時には、元の改行文字へと変換される。ヌルおよび復帰改行文字（「＼０」および「＼ｒ」）等の他のいくつかの文字に同じ手順が適用され、基礎ファイルシステムおよび言語プロセッサがそれらを誤訳することを防ぐ。

更新をファイルの末尾に付加することは、最も単純で最も移植性の高い手法である。しかしながら、代替的なより複雑なスペースの割当を代わりに用いてもよい。しかし、これらの代替的な手法は、いずれのレコードの過去のバージョンも上書きまたは変更されることなく、新たなバージョンの全てをデータベースに追加し、レコードの入力順を維持しなければならないという要件に従う必要がある。代替的な手法の一例としては、所与のレコードのバージョンのシーケンスが維持されると仮定した場合、クラスタリングを用いてパフォーマンスを改善することができる。

クラスタリングは、１つのディスク入出力動作により、高速に順次アクセスされる可能性があるいくつかのレコードが取り出されるように、なんらかのキーによって物理的にレコードを順番に記憶することで機能する。従来のシステムの多くは、葉節がキーシーケンス内に挿入されるレコードを含むツリー構造にレコードを記憶することでそれらを動的にクラスタリングする。これには、レコードの挿入時にパフォーマンスを損なう多くのレコードシャッフリング、節点分割等が必要である。しかしながら、読取り数が挿入数をはるかに上回る場合、全体のパフォーマンスにはゲインが生じる。この場合、レコードの挿入は、単に特殊なスペースの管理にすぎない。

しかしながら、クラスタリングが用いられた場合、それを動的に行う必要はない。その代わり、ファイルは、キーシーケンス内のレコードを読み出し、それらをそのシーケンス内のそのファイルの新たなコピーに書き込むことにより、オフラインでクラスタリングすることができる。実際には、オフラインでのクラスタリングは、読取り性能が改善される点で、動的なクラスタリングとほぼ同様に作用するが、書込み性能に関しては、クラスタリングによる悪影響は一切ない。

しかしながら、クラスタリングの重要性は、バッファリングに利用可能なＲＡＭ量が増加するにつれて減少する。今日ではＲＡＭは安価であるため、クラスタリングに関して憂慮するよりも、より多くのＲＡＭを購入することが賢明である。
（ドリルダウンインデックス）

上述したファイルシステムでは、所与のキー（例えば、製品）についての情報はテーブル内に整然とまとめられることはない。むしろ、非常に大きくなりがちなファイル全体に散乱する。その情報にアクセスするために、ドリルダウンインデックスが用いられる。ドリルダウンインデックスは、そのファイル内のキー：値ペア（例えば、製品属性）に基づいている。Ｃ＋＋プログラムでは、全てのキーの順序を維持するツリーによって容易かつ単純に実現することができる。

ドリルダウンインデックス内のレコードポインタは、特定のインデックス付けされたキーについての情報を含むサブレコードを物理的に抽出するためにどこを見るべきかを示すファイルの先頭からの正確なオフセットである。インデックスは、サブレコードが含まれる親レコードのオフセットを識別しない。このため、サブレコードの抽出は親レコードの構造および内容に対してトランスペアレントである。ドリルダウンインデックスキーはマルチパートであるが、１つのパートは常に親レコードの主キーである。この主キーは、アプリケーションが容易に当該主キーを見つけ出して抽出し、親レコードを取り出すことができるように区切られている。

ドリルダウンインデックスを始めとする全ての代替インデックスはマルチパートであり、それらの部分はサブレコードのいずれの部分からも抽出することができる。そのため、例えば、トランザクションファイル内に記憶された在庫量トランザクションサブレコードのドリルダウンインデックスは、製品主キー、発送日および請求書番号から構成され得る。これらのキーを順次処理し、所与の製品および所与の日付範囲に関する情報を全て抽出することができる。

このインデックスを用いれば、特定の１つの製品または特定の複数の製品に関連付けられた全てのトランザクションを時系列または所望のいずれのか方法で見つけ出すことができる。例えば、ファイル全体に散乱する多数のトランザクションが影響した可能性があるある製品の履歴を問い合わせることができる。ドリルダウンインデックスは、データベースアプリケーションでそれらを順番に提示することを可能にする。データベースアプリケーションは、関連するレコードを、それらがまるで長い分類されたリスト内にあるかのようにユーザが一度で閲覧することを可能にする関数呼び出しを提供する。このようにして、ユーザは、整然と順序づけて提示されたこれらの製品全てのリストである一覧を作成することができる。

図４を参照して、各データベースファイル４０は、サーバ４４上で動作する独自のサーバプロセス４２により供給される。このプロセスが開始されると、ユーザにより維持されるインデックス制御ファイル４６を不揮発性記憶装置（例えば、ディスク記憶装置４８）から読み出す。インデックス制御ファイルは、そのアプリケーションのために構築および維持される必要があるドリルダウンインデックスを含む全てのインデックスを同定する。ファイル内のレコードを同定する主キー（例えば、請求書＃、トランザクション＃またはドキュメント＃）は常にインデックス付けされる。例えば、顧客ファイルの場合、主キーは、典型的には、各顧客に割り当てられた外的意味を有さない固有の番号である。顧客検索を効率的にするために、名称、ｅメールまたはその他の周知の情報に基づく少なくとも１つの代替インデックスが維持され得る。インデックス制御ファイルはこれらを同定し、典型的には、その特定のデータベースアプリケーションのレコードから関連情報を抽出するために必要となる他の多くの代替インデックスおよびドリルダウンインデックスを同定する。

インデックス制御ファイル内で見つかった情報を用いて、サーバプロセスは、揮発性メモリ５０内に、インデックスのテーブル５２を構築する。これは、ディスク記憶装置４８内に記憶された関連データベースファイル４０内の全てのレコードを順次走査することにより行なわれ、レコード内で見つかった情報から必要なインデックス５２の全てを構築する。

それ以降、レコードが作成または修正されるごとに、サーバプロセスによりレコードを走査して、インデックス付けされるべき情報に固有の属性（例えば、請求システムの行項目）を探す。サブレコードが見つかるごとに、アプリケーションは、そのサブレコード内から、インデックス付けされるべき属性を探す（例えば、行項目内から製品番号および日付をそれら属性に割り当てられたキーに基づいて探す）。このプロセスは、区切文字およびレコードの主キーと代替キーを連結し、マルチパートキーを形成する。プログラムは単純にそれらのキーを揮発性メモリ内に維持されている内部インデックスに付与するか、または必要なインデックスがすでに存在する場合は、現在新たなバージョンのどれが代替キーを含むかを示すブール指標のリストを更新する。

全てのインデックスが揮発性メモリ内にあるため、システムがシャットダウンした場合または再起動する必要がある場合、それらのインデックスは再構築される必要がある。しかしながら、それらを構築するプロセスは簡単であり、単純にデータベース内の各データファイルを順次読み出すことを伴うだけであるため、このプロセスは比較的に迅速に行なうことができる。
（ロック）

上述の実施形態では、各レコードは、単純な単一レコード排除ロック（錠）を用いて分離されており、アトミック（atomically）に書込みおよび更新がなされる。記録されたトランザクションによって生成されたデータに依存する全てのアプリケーションは、ドリルダウンインデックスを介して、そのデータをドキュメントから導き出すことができる。よって、「トランザクション処理」ソフトウェアを必要とすることなく、全てのトランザクションが分離され、アトミック（atomic）になる。

上記したように、レコードロッキングは、相互排除ロック（ミューテックス）を用いて実施される。アプリケーションプログラムが更新しようとするレコードの読出しを試みる場合、他のユーザがすでにそのレコードをロックしていないかどうかを確認する呼び出しを用いる。もしロックされていれば、アプリケーションプログラムは、この条件を検出し、再度試行する前にしばらく待機するようにユーザに示唆する等の代替的なアクションを取る。もしロックされてなければ、ミューテックスが設定され、アプリケーションは処理を続行する。アプリケーションプログラムがレコードを更新する際にロックを保持する更新呼び出しを用いない限り、または明らかにロックを解除する際にロックが解除される。ロックにはまた、タイムアウトが割り当てられてもよく、それを経過した後に自動的にロックが解かれる。また、データベースがタイムアドレスされているため、読取り専用ロックの必要はないが、これは、高感度読取り動作が、タイムアドレシングの使用により一貫するためである。

なお、ロックはレコードレベルで動作し、サブレコードレベルには適用されない。ロックされたレコード内のサブレコードを修正することはできない。

図４を再度参照して、上述の実施形態では、データベースサーバはＣ＋＋で記述されたコンピュータプログラムとして組み入れられている。このプログラムのインスタンスは、公知のＴＣＰ／ＩＰポート５４上のクライアント接続を聞き分ける。クライアント５６は、このポートを介してデータベース要求を行なう。プログラムは、子プロセス４２を作成して、個々のファイルに対処し、これらのプロセスのクライアント５６を参照してさらなるファイル固有のデータベースサービスを探す。これにより、各ファイルは、個別のプロセスにより供給され、所与のファイルに対する全ての操作がアトミック（atomically）に自動的に実行される。そのファイルを供給するプロセスは、そのテーブル用のインデックス全てを維持する。各ファイルごとに単一のサーバプロセスを有し、ファイルに対する全ての操作をアトミック（atomically）に実行することにより、プロセスは、２人のユーザが同時にファイルを読取り中または更新中でないことを保証することができ、ミューテックスロックを用いることにより、プロセスは、２人以上のユーザがそのファイル内の同じレコードへの更新を重複して行なわないことを保証することができる。

関心がある特定のレコードを同定するために、クライアントは所望のタイムアドレスを用いてグローバル変数を設定し、データベースから何らかの要求が行なわれるたびに、このグローバル変数をパラメータとして特定することができる。クライアントおよびサーバプロセスが異なる装置で動作している場合、タイムクロックに誤差が生じる可能性がある。それゆえ、２つのクロックを同期させるために何らかの手順を用いる必要があり得る。例えば、一方のプロセスが他方のプロセスの時間を問い合わせることが可能である。
（自動集計バケット）

最も実践的なデータベースアプリケーションは、「集計バケット」に大きく依存する。集計バケットの一例は、所与の場所の所与の製品の手持ち数量である。いかにしてその数量に達っしたかに関する詳細は、ある時点でのアイテムの「期首在庫量」の数に始まり、そのアイテムに関する全ての製品移動トランザクション（発送、受領等）に続くトランザクションに埋もれている。これらのトランザクションの合計は、そのアイテムの現在の手持ち数量、すなわち、ある数量の製品が保管場所へ／から移動するたびに変化する値を有する「集計バケット」である。製品の移動に影響するトランザクションの数は非常に大きい可能性があるため、特定の製品の現在の手持ち数量を知る必要が生じるたびに、全てのトランザクションを取り出し、それら全てを合計することは実際的ではない。

この要件に対する伝統的な解決策は、製品に対するトランザクションを処理する各アプリケーションプログラムに、データベース内に記憶される集計バケットを読み取らせ、更新させることである。これにより、各製品および場所について、その場所での製品の手持ち数量を表す数的属性を含むレコードがデータベース内に生じる。アプリケーションは、排他的更新ロックを有するレコードを読み取り、属性を変更し、そのレコードを更新する。５つの行項目を有する請求書については、読出し、ロックおよび更新が５回行なわれる。

単一ドキュメント内のトランザクションの詳細全てをカプセル化することは可能であるが、同じドキュメント内の集計バケットをカプセル化することはできない。

データベースは、次のようにして仮想的な集計バケットを自動的に維持する。レコードがデータベースに追加されるかまたは更新されるたびに、サーバは、過去のバージョンを有さない新たなレコードであり得る新たなバージョンを走査し、そのファイルについての集計バケット定義と一致する属性のインスタンスを探し、関連する数量を抽出し、それらを集計バケットインデックス内に記憶されるバケットに付与する。次いで、アプリケーションは、そのレコードについて過去のバージョンが存在するかどうかを確認し、もし存在すれば、そのバージョンを読み取り、そのバージョンで見つかった数量を逆転する（例えば、集計バケットから差し引く）。

上述の実施形態は、自動的に仮想集計バケットを維持することにより、データベース内においてアプリケーションレベルで集計バケットを維持する必要性を取り除く。仮想集計バケットの集まりは、１つのドリルダウンインデックスに等しい。ユーザは、集計情報が維持されるべきマルチパートキーを定義する。例えば、マルチパートキーは、製品主キーおよび日付から構成され、これは、トランザクションファイルへのドリルダウン集計バケットインデックス６０として用いられる（図５参照）。そして、アプリケーションは、製品主キーおよび日付の組み合わせごとに、１つの内部集計バケット６２を自動的に維持する。

例えば、請求書トランザクション内の在庫量サブレコードが、「数量変更」属性内に「−１０」（マイナス１０）という数量を含む場合、これは、当該アイテムが１０個分在庫量から削除され、関連する日付に当該顧客に配達されたことを意味する。サーバは、次の工程を実行する。このサブレコードが集計バケットとしてインデックス付けされるていることを発見し、レコードの製品ＩＤおよび日付属性を抽出し、メモリ内の集計バケットにアクセスし、その集計バケットの現在値に−１０を加える（すなわち、１０を差し引く)。サーバは、そのレコードに前のバージョンが存在するかどうかを確認する。前のバージョンが存在する場合、サーバは、その前のバージョンから数量を抽出し、集計バケットから差し引くことにより集計バケットを「最新」に保つ。

集計バケットの本質は、ファイル内の情報を分類し、数字の列の合計または小計を印刷するレポート上に現れる合計または小計と類似していることである。データベースサーバは、これらの集計バケットに影響するすべての変化をその発生時に適用することで集計バケットを維持する。集計バケットは数的属性のみに適用されるが、ドル金額および他の数量（例えば、Ｇ／Ｌ勘定残高、Ａ／Ｒ勘定残高等）にも用いられ得ることは明らかである。よって、各Ｇ／Ｌ勘定のＧ／Ｌ額を含む物理的なファイルを維持する代わりに、システムは単に勘定科目一覧表および一組のトランザクション詳細を記憶する。サーバは、勘定ごとにトランザクション詳細を合計して現在の残高を求め、勘定および日付ごとに日々の集計を求める。

他の実施形態は添付の請求項の範囲内である。

図１は、データベースの主インデックスを実現するために用いられるツリーおよびリスト構造を示す。図２は、データベースの代替インデックスを実現するために用いられるツリーおよびブール（真または偽)値のリスト構造を示す。図３は、タイムスタンプおよび主キーにより同定されるレコードバージョンが記憶されるタイムアドレスされたデータベースアプリケーションファイルを示す。図４は、データベースファイル内のレコードおよびサブレコードにアクセスするためのドリルダウンインデックスを用いるタイムアドレスされたデータベースシステムを示す。図５は仮想集計バケットインデックスを示す。

Claims

複数のトランザクション各々について、データベースアプリケーションを介してユーザから入力を受け取る工程と、
前記トランザクションについて受け取った入力を組み込む対応レコードを構築する工程と、
前記トランザクションの対応レコードにタイムアドレスを付加する工程であって、該タイムアドレスは対応するトランザクションが終了した時を同定する、工程と、
前記トランザクションの対応レコードを不揮発性データ記憶装置に記憶する工程であって、該対応レコードのタイムアドレスは記憶された対応レコードに永続的に関連付けられ、前記データベースアプリケーションは通常動作時に該記憶された対応レコードが他のデータで上書きされることを防ぐ、工程と、を包含する、データベースアプリケーションのためのデータベースを構築する方法。
前記複数のトランザクション各々について、前記対応レコードに主キーを付与する工程をさらに包含する、請求項１に記載の方法。
前記データベースアプリケーションによって処理される全てのトランザクションについて、前記対応レコードを記憶する工程は、該対応レコードを前記不揮発性データ記憶装置内の単一の共通会計トランザクションファイルに付与する工程を包含する、請求項１に記載の方法。
前記データベースアプリケーションによって処理される全てのトランザクションについて、前記対応レコードを記憶する工程は、該対応レコードを前記不揮発性データ記憶装置内の単一の共通ファイルの末尾に付加する工程を包含する、請求項１に記載の方法。
前記記憶されたレコードのうち特定の１つを削除するコマンドに対して、
前記記憶されたレコードの新たなバージョンを生成すること、
前記記憶されたレコードの新たなバージョンに削除済のフラグを設定すること、
前記記憶されたレコードの新たなバージョンに前記記憶された特定のレコードのタイムアドレスとは異なるタイムアドレスを付与すること、
前記記憶されたレコードの新たなバージョンを前記不揮発性データ記憶装置内に記憶する一方で、該不揮発性データ記憶装置内に前記特定のレコードを残したままにしておくこと、によって応答する工程をさらに包含する、請求項１に記載の方法。
前記記憶されたレコード内の情報に対して複数のインデックスを生成する工程をさらに包含する、請求項１に記載の方法。
前記記憶されたレコード内の情報に対して複数のインデックスを生成し、揮発性メモリ内に維持する工程をさらに包含する、請求項１に記載の方法。
前記複数のインデックスの各々は２つの階層を含み、その第２の階層は前記記憶されたレコード内のタイムアドレスを含む、請求項７に記載の方法。
データ記憶装置内に複数のレコードを記憶する工程であって、該複数のレコードの各レコードは、その最上位において、値がスカラーでもプリミティブでもなく構造であるキー：値ペアマップを特徴とする共通構造を有し、該構造が該レコード内に１つ以上のサブレコードを含む、工程と、
複数のドリルダウンインデックスを生成し、揮発性メモリ内に維持する工程であって、該複数のドリルダウンインデックスの各々は対応するマルチパートキーに基づいており、該複数のレコード内のレコードに含まれるサブレコードから異なる情報を抽出するためのものである、工程と、を包含する、データベース方法。
前記複数のレコードを記憶する工程は前記記憶された複数のレコードの各々にタイムアドレスを付与することを伴い、該タイムアドレスは該対応レコードが作成された時を同定し、各対応するインデックスは、その最下位において、該タイムアドレスにインデックス付けし、該タイムアドレスのインデックスは該記憶されたレコード内のタイムアドレスを同定する、請求項９に記載の方法。
データベースレコード内で見つかった１つ以上の数量関連属性に関連付けられたキーのインデックスを揮発性メモリ内に構築する工程であって、該インデックスは、該キーの異なるインスタンスごとに、該キーのインスタンスに関連付けられた１つ以上の数量関連属性の値全ての合計である累積値を含む集計バケットを維持する、工程と、
データベースに新たなレコードが付加されるごとに、前記揮発性メモリ内のインデックスの集計バケットを自動的に更新する工程と、を包含する、レコードのデータベースを管理するデータベースアプリケーションの集計情報を維持する方法。
前記自動更新は、
新たなレコードが追加されるたびに、該新たなレコードを走査し、そのファイルについての集計バケットの定義と一致する属性のインスタンスを探すことと、
前記インスタンスに関連付けられた値を抽出することと、
前記抽出された値を前記インデックスに記憶された適切な集計バケットに付加することと、
を伴う、請求項１１に記載の方法。