JP3730556B2

JP3730556B2 - データベース管理システム

Info

Publication number: JP3730556B2
Application number: JP2001320213A
Authority: JP
Inventors: ゴーンケインアダム
Original assignee: ゴーンケインリサーチリミティド
Priority date: 2000-11-21
Filing date: 2001-10-18
Publication date: 2006-01-05
Anticipated expiration: 2021-10-18
Also published as: GB2369208B; GB2369208A; GB0028311D0; US20020062305A1; JP2002229821A

Description

【０００１】
【発明の属する技術分野】
本発明はデータベース管理システムに関連するものである。特に、データベースの状態の修正処理の前後両方におけるデータベースの状態を示すデータの塊を維持管理するためのデータベース管理システムに関連するものである。
【０００２】
【従来の技術】
一般に、コンピュータデータベースを維持管理するために従来のデータベース管理システム（以下、DBMSという）で使われる方法は、データレコードの追加、修正、削除である。データレコードは修正、削除されるので、完成したデータベースの前の状態を直接明示することはできない。
【０００３】
既知のシステムのなかには、あるチェックポイントにおけるデータベースファイルのコピーとともに付随のログファイルに全ての処理指示を記録することにより、リレーショナルデータベースの以前のバージョンへアクセスできるものある。しかしながら、以前のチェックポイントにおけるコピーに対しログファイルを再実行しなければならないことや、それぞれのチェックポイントのコピーとログファイルには論理的に冗長なデータが大量に含まれるので多くのスペースが必要となることから、この方法は満足なものとはいえない。
【０００４】
【発明が解決しようとする課題】
本発明の目的は、多数の、データベースの以前の状態を極めて簡潔に直接明示させるさせることができるデータベースの維持管理を可能にする構造をDBMSに提供することである。
【０００５】
【課題を解決するための手段】
本発明に基づき、データベースの状態の修正処理の前後両方におけるデータベースの状態を示すデータの塊を維持管理するためのデータベース管理システム（DBMS）が提供される。このデータベース管理システムは、データベース修正処理前およびデータベース修正処理後におけるデータベースの状態のレコードを永久的に保持するメモリ手段と、データベースの各状態のレコード内にある１つ以上の親データ項目と、データベースの同一の状態のレコード内にある１つ以上の従属データ項目を関連付ける関連定義手段と、データベースの各状態のレコード内にある、他のデータ項目と関連付けられているルートデータ項目の位置を定義するルート定義手段と、データベースの状態に該当するルートデータ項目と、そのデータベースの状態のレコード内にある１つ以上のデータ項目、および以前の状態の位置により定義された修正処理前のデータベースの状態のレコード内にある１つ以上のデータ項目を関連付けることにより、データベース修正処理後のデータベースの状態を定義する状態定義手段を備えている。
【０００６】
このDBMSにより、大量の冗長なデータの格納を要することなく、データベースの前の状態の全てへ直接アクセスできる方法で、コンピュータデータベースの維持管理を行うことができる。
【０００７】
又、このDBMSの構造は、様々な種類の樹木が、毎年新しい年輪ができることで生育していく過程にたとえることができる。この構造では、木の外輪を剥ぎ取っていくことにより、木の前の状態を全て直接明示することができる。類推すれば、本発明は、既存データ項目の修正あるいは削除を要することなく、データ項目をデータベースに追加することのみにより、コンピュータデータベースを柔軟に維持管理することができるDBMSに関連している。
【０００８】
各データベース修正処理中に、新規データ項目の塊がデータベースファイルの末尾に追加される。ファイル内の前の塊の中にある前のデータ項目は、修正される必要はない。このように、一定数のはじめの塊のみを考慮し、残りの追加された塊は無視することで、DBMSによりある時点以前のデータベースの状態の全てを直接明示することができる。例えば、データベースファイルが、７つの処理に該当する７つの塊から成る場合、DBMSは第１から第３までの塊をチェックし、第４から第７までの塊を一時的に無視することにより、第３処理後のデータベースの状態を明示できる。
【０００９】
塊の中にあるレコードは、以下の原理に基づいて構造化される。
・データ項目の塊は、処理が行われる際、データベースファイルに追加される。
・データベースファイルに追加された塊は、絶対に編集されない。
・概して、塊は、前のデータベースファイルの全体のサイズより小さい。
・前の塊の中にあるデータ項目が処理により論理的に削除あるいは修正されなかった場合、塊は、前の塊の中にあるデータ項目を参照する。
・前の塊の中にあるデータ項目が処理により論理的に削除あるいは修正された場合、塊は、前の塊の中にあるデータ項目をマスクし参照しない。
・塊は、後に生成された塊の中にあるデータ項目は参照しない。
【００１０】
これらの原理は、以下の方法で利用される。
・各データ項目は、ファイル内の塊の中に位置する。
・データ項目は、親データ項目になる場合もある。
・各親データ項目には、その従属データ項目の位置を示すデータが含まれる。
・各処理の塊には、ルートデータ項目の位置が含まれる。
・DBMSは、ルートデータ項目から従属データ項目を追跡したのち、さらに追跡済みデータ項目から従属データ項目を追跡することにより、データ項目のネットワークを辿ることができる。
・DBMSは、このデータ項目ネットワークを横断しながら、各追跡済み従属データ項目の位置を記録するための手段をうまく含めることができる。
【００１１】
・従って、データベースファイル内の塊の中にある従属データ項目には、それらの親データ項目の位置は格納されない。
・追跡開始に使われるルートデータ項目によっては、DBMSにより異なるネットワークのデータ項目が表示される場合もある。
【００１２】
一般に、コンピュータサイエンスでは、データベースは「物理的な」状態と「論理的な」状態を持っていると言える。物理状態とは、例えば磁気ディスクやCD-ROMといった相応のコンピュータデータ記憶装置に格納されているデータの配列のことをいう。論理状態とは、これらのデータによって具体化された情報の概念的な構成（ビュー）のことをいう。一般に、DBMSとは、他のコンピュータプログラムに対し異なる論理状態を提示しながら、物理状態を操作することができるコンピュータプログラムのことをいう。
【００１３】
本発明に基づくDBMSは、データ項目が追加、編集、削除された場合に、物理状態の既存データ項目を編集あるいは削除することなく、データ項目をデータベースの物理状態に追加することにより、修正後のデータベースの論理状態を提示することができる。
【００１４】
データベース修正処理中、DBMSは、データベースファイルに追加されるデータ項目の塊を以下の方法で作成する。
・新規の従属データ項目は、新規の塊に挿入することができる。
・前の塊の中にある論理的に編集されたデータ項目は、コピーされなければならない。
・論理的に編集あるいは削除されたデータ項目の親データ項目の全てはコピーされなければならない。
【００１５】
・編集された親データ項目の従属データ項目のうち、既存で未編集のものはコピーされなくてもよい。新規の親データ項目コピーは、前の塊の中にある未編集
の従属データ項目の位置データを使用することができる。
・塊には、新規ルートデータ項目の位置を示すデータが含まれる。
・塊には、前の塊の位置を示すデータが含まれる。
【００１６】
従って、各データベース処理はデータの塊の中で実施され、また、DBMSは、該当処理のデータの塊の中に示されているルートデータ項目から始まっているデータ項目ネットワークを辿ることにより、対象となる処理の直後の、データベース全体の状態を直接明示することができる。このように、DBMSは、データベース履歴内の処理間のどの時点においても、データベースのその時点の状態を直接明示することができる。
【００１７】
本発明の実装例において、データベースの論理状態において頻繁に発生するか、あるいは頻繁に発生する可能性のあるデータ値は、多数の他データ項目の従属データ項目として再度使用することができるように、データ項目ネットワークの一部のデータ項目に格納してもよい。例えば、「London」というテキスト値は、英国の住所データベースに頻繁に出現する可能性がある。
【００１８】
さらに、本発明の実装例において、データ項目ネットワークは従来のネットワークデータベースの形式であってもよい。一般に、ネットワークデータベースでは、アプリケーションプログラムに適した方法で、データレコードどうしをリンクすることができる。従来のネットワークデータベースでは、通常、以前のバージョンのデータベースを直接明示することはできないが、本実装例のDBMSでは、以前のバージョンのネットワークデータベースの全てを直接明示することができる。
【００１９】
例えば、データ項目のネットワークが、テーブル、ビュー、行、列、フィールドなどが組み込まれている従来のリレーショナルデータベースを構成する場合がある。DBMSには、ユーザーによるデータベースの機能関連ビューへのアクセス、修正を可能にするSQL用の解釈プログラムを含めることもできる。さらに、ユーザーは、データベース履歴内の処理間のどの時点におけるデータベースの関連ビューに直接アクセスすることができる。
【００２０】
また、データ項目のネットワークがオブジェクトデータベースを構成する場合もある。一般に、オブジェクトデータベースには、カプセル収納データとプログラムの動作から成るオブジェクトが含まれる。この場合、ネットワークには、オブジェクトクラスとオブジェクトインスタンスに該当するデータ項目が含まれる。オブジェクト間の論理参照は、参照先オブジェクトに該当するデータ項目の位置データを含んだ参照元オブジェクトに該当するデータ項目によりモデル化される。
【００２１】
本発明の別の実装例において、データ項目ネットワークがバーチャルディスクドライブ（VDD）を構成する場合がある。そのVDDには、過去のVDDの論理状態にいつでも直接アクセルすることができるという追加的機能が備わっている。一般に、バーチャルディスクドライバは、他のコンピュータプログラムが、そのインターフェースのソフトウェアをあたかもコンピュータディスクのように扱うことができるコンピュータソフトウェアインターフェースである。そのようなインターフェースは、通常、一定の有効な位置範囲内でのランダムな位置において、例えばデータの読み込み、書き出し、修正などの機能をサポートする。データ項目ネットワーク内のデータ項目のなかには、バーチャルディスク（例えば、ディスクセクターなど）内の位置範囲に該当するものもある。これらのデータ項目には、該当するバーチャルディスク範囲内に論理的に格納されたデータが含まれる。コンピュータアプリケーションがVDD内のある範囲の内容を修正しようとする場合、DBMSはその論理的なディスクの修正に該当する処理の塊を新規に作成する。DMBSは、データ項目あるいはVDD内のその範囲に該当する複数のデータ項目を用意することにより、それらのデータ項目の新バージョンを作成する。場合によっては、DBMSは、該当する論理データを表わす際の物理データの効率を上げるために、物理レコードに該当する論理範囲を分割あるいは併合する。従って、異なるレコード内で具体的に使用されるバーチャルディスクの容量には差がある。データ項目ネットワーク内のデータ項目の親／従属階層は、バーチャルディスク上の該当範囲およびサブ範囲の場所と関連する。
【００２２】
本発明の更なる実装例においては、DBMSにバージョンコントロールシステム（VCS）が組み込まれる。当該VCSにより、データベースがどのように構築されたかを示すために、データベースのバージョンを整理することができる。また、VCSは、データベースの論理状態の代替バージョンを並行して構築できる分岐点を含めることもできる。
【００２３】
各新規データの塊には、前のデータの塊の位置データが含まれる。前のデータの塊は、必ずしもファイル内にある新規の塊の直前の塊であるとは限らない。前の塊は、さらにその前の塊である場合もある。このように、VCSは、複数の塊を複数バージョンから成る論理階層に配列することができる。また、各新規の塊には、作成日時、変更を行ったユーザーの名前、変更理由、変更に関連するプロジェクト、ジョブ、業務などのメタデータが含まれる。
【００２４】
バージョンデータ項目と呼ばれるデータ項目のネットワークのなかには、それらの従属データ項目とともに、論理データベースのあるバージョンを具体化するものもある。バージョンデータ項目は、それ自体がバージョンコントロールデータ項目の従属データ項目である場合もある。VCSは、バージョンコントロールデータ項目を介して、ルートデータ項目からバージョンデータ項目、論理データベースのデータ項目までのデータ項目のネットワークを案内することができる。
【００２５】
一般に、マルチユーザーの処理データベースでは、複数ユーザー（複数の人間あるいはコンピュータプログラム）が同時にデータベースにアクセスすることができる。単一ユーザーがデータベースを修正する場合、処理を開始し、必要な修正を行ったのち、その処理を実行に移す。複数ユーザーがデータベースを同時に修正する場合、１人あるいは複数のユーザーは、（処理の開始段階あるいは実行段階で）DMBSにより修正要求が拒否される場合がある。
【００２６】
本発明の開発においては、前述のVCS機能を開始＋実行処理論理に組み込むことにより、複数ユーザーの同時修正要求が原因で生じる修正拒否を避けるマルチユーザー対応のDBMSが提供される。ユーザーが処理を開始すると、DBMSは、そのユーザーのデータベースの論理ビューに関連する塊と、開始処理を関連付ける。その後、ユーザーが処理を実行すると、DBMSは、VCSを介して表示した際、処理に関連する塊から論理的に派生して作成される新規の塊を追加する。複数ユーザーが同時に処理を開始し、その後処理を実行した場合、DBMSは、異なる分岐に新規バージョンを格納しておく必要がある。これらの分岐は、おそらくアプリケーション固有のアルゴリズムを使って、後でまとめることができる。
【００２７】
一般に、アプリケーションプログラムには、元に戻す／繰り返すコマンドが提供されていることが多く、そのためユーザーは、行った変更を取り消し、気が変わった場合は再実行できるという確信を持ってデータベース（例えば、文書処理ファイルなど）に変更を行うことができる。これにより、ユーザーは、操作ミスによる不本意な結果から解放される。
【００２８】
本発明の更なる開発において、元に戻す／繰り返す機構をユーザーに提供するアプリケーションのデータ管理をサポートするために、VCS機能がDBMSに組み込まれる。ユーザーが変更を行うと、DBMSは処理の塊をデータベースに追加する。ユーザーが元に戻すコマンドを使用すると、DBMS 内にあるVCSが前のバージョンのデータベースに戻すので、行った修正は取り消され、元の状態に戻る。その後ユーザーが別の変更を行うと、DMBSは別の処理の塊を追加し、VCSはその変更用の分岐を新規に作成する。このように、ユーザーが引き起こすデータベースの状態の全て、およびそれらの順序が記録される。従って、DBMSは、ユーザーの操作や作業効率、操作のミスを分析するために必要な生データを自動的に収集する。この生データは、ユーザーの作業処理能力を監視し、ユーザーの訓練を助け、アプリケーションソフトウェアのユーザーインターフェースを改善することができる。
【００２９】
本発明のアプリケーションにおいて、DBMSは、追加のみ可能で修正不可能な媒体を使ってデータベースを物理的に格納し、さらに、修正可能なデータベースの論理ビューを提供する。例えば、コンパクトディスクのなかには、データを追加することはできるが、既に書き込まれているデータを修正することはできないタイプもある。こういった追加専用の媒体は、追記形（WORM：Write-Once-Read-Many）装置とも呼ばれる。
【００３０】
【発明の実施の形態】
本発明をより十分に理解してもらうために、一例として、添付図面とともに説明する。
図１は、本発明に基づくDBMSのデータベースファイル内における塊の物理構造を表わしたものである。図２は、処理中における当該データベースの論理状態と物理状態を表わしたものである。図３は、本発明に基づくDBMSがどのようにしてレコードを論理的に構造化しているかを、一般的なリレーショナルデータベースの形式で表わしたものである。図４は、本発明に基づくVCSが、どのようにしてDBMSのデータベースファイル内の塊を配列するかを表わしたものである。図５は、VCSが、本発明に基づくDBMS のバージョンコントロールを使ってどのようにしてレコードを論理的に構造化しているかを、一般的なリレーショナルデータベースの形式で表わしたものである。
【００３１】
これらの図は、当該システムの基本原理の例証として、本発明に基づくDBMS のうち、シンプルで代表的なものの構造を表わそうとしたものであり、また、本発明に基づき作成されると思われる実際のシステムには、技術面で熟練したユーザーに十分理解されるような追加機能を含め、更に高度なレベルの構造的な複雑さが組み込まれることを表わそうとしたものである。
【００３２】
図１は、毎日の新たな処理により新規の塊がファイルに追加される場合に、当該DBMSの基本構造が、どのようにしてデータベースファイルを一連の塊としてフォーマットしているかを表わしたものである。day1、day2、day3と記されたボックスは、毎日ファイルに追加される塊を表わす。
【００３３】
図２は、当該データベースがシンプルなネットワークデータベースである場合、データベース修正処理中に、データベースの論理状態と物理状態がどのように関連し合っているかを代表的な例で表わしたものである。図の上部は論理状態を表わし、図の下部は該当する物理状態を表わす。図の左側は処理前のday1のデータベース状態、図の右側は処理後のday2のデータベース状態を表わす。各処理の塊には、ルートレコードの位置が含まれる。各物理状態図の中の各塊のルートレコードは、黒の半円で示される。
【００３４】
データベース修正処理前、データベースには、世界６ヶ国（America、Spain、Africa、Canada、 France）の国名が入った６つのデータ項目が含まれている。論理状態では、データ項目は２分木で表わされる。この例では、２分木は分類されているので、どの親データ項目も左側の従属データ項目よりもアルファベット順で後に置かれ、右側の従属データ項目よりもアルファベット順で前に置かれる。物理状態では、データ項目は単一の塊の中に格納される。物理状態では、親データ項目（England、America、Spain）には、従属データ項目（America、Span、Africa、Canada、France）の位置データも含まれる。
【００３５】
この例では、ユーザーは新規の「Turkey」のデータ項目をデータベースに追加しようとしている。従って、新規の「Turkey」のデータ項目は新規の塊に挿入される。この例では、DBMSは２分木をソートされたままで処理するので、新規の「Turkey」のデータ項目は、「Spain」のデータ項目の右側の従属データ項目として論理状態に挿入される。つまり、古い「Spain」のデータ項目は必ずコピーされ、コピーされたデータ項目は図ではS*というラベルが付けられている。同様に、古い「England」のデータ項目はE*としてコピーされる。従って、新規の塊には物理的に３つのデータ項目（E*、S*、Turkey）が含まれる。新規の「E*」データ項目は、「America」と「S*」という従属データ項目を持つ。新規の「S*」データ項目は、「France」と「Turkey」という従属データ項目を持つ。図は、ネットワークデータベースの２つの異なる論理状態（すなわち、処理前と処理後）が、２つの塊のうち１つのルートデータ項目からネットワークを辿ることにより、どのようにして直接表示されるかを表わしている。
【００３６】
図３は、本発明に基づくDBMSとともに使用するためのデータ項目ネットワークを、汎用リレーショナルデータベースの形式で表わしたものである。この例では、例えば、ストリング、テーブル、列、フィールド、カラム定義、データ値など、従来からあるリレーショナルデータベースの要素に該当する様々なタイプのレコードがある。リレーショナルデータベースの各テーブルは、該当するテーブルレコードを持つ。テーブルレコードは、分類された２分木に配列される。この代表的な図では、各テーブルレコードは、２つまでの従属テーブルレコードを持つ。各テーブルレコードには、リレーショナルデータベース内のテーブルの名称を示すデータも含まれる。従来のリレーショナルデータベースの理論には、このテーブルレコードの２分木構造に類似した構造がない。従来のリレーショナルデータベースの理論では、テーブルは、必要な限り結合演算を使って推論され、テーブルどうしの連関を持つ、より独立したものとして考えられている。DBMSがテーブル名からテーブルを見つけ出すことができるように、ここでは２分木構造を使っている。
【００３７】
各テーブルレコードは、列レコードのサブネットワークのローカルルートを形成する従属レコードも持つ。各列レコードには、当該テーブルレコードに該当するリレーショナルデータベーステーブルの列に表示されるデータが含まれる。図は、単にテーブルレコードの１つに対する列サブネットワークを表わしたものであるが、各テーブルレコードには、それ自体の列サブネットワークが含まれる。同様に、図は、各テーブルレコードにそれ自体のカラム定義サブネットワークがどのように含まれているか、各列レコードにそれ自体のフィールドサブネットワークがどのように含まれているか、各フィールドレコードにフィールド値を示すデータがどのように含まれているかも表わしている。
【００３８】
図３の例では、ストリング用の独立したサブネットワークがある。このサブネットワークには、一般にテキスト値を発生させるための標準レコードが含まれる。従って、多数のリレーショナルデータベースフィールドが「London」という値を持っている場合、該当するフィールドレコードの全てに、「London」を表示する単一で標準のストリングレコードの位置を格納することができる。
【００３９】
従来の方法では、リレーショナルデータベースは、テーブルの集合体として表わされる。このテーブル構造は、ネットワーク構造に変換することができる。この変換を行うにはいくつかの方法あるが、そのうちの１つを図３に表わしている。どの変換方法を使用したとしても、リレーショナルデータベース、ネットワークデータベース、オブジェクトデータベース、バーチャルディスクドライブ、あるいはその他の適用可能なデータベースがいったんネットワーク構造に変換されると、本発明の基本原理により、従来型の追跡機能やバージョンコントロール機能を追加することができる。
【００４０】
図４は、データベースがシンプルなネットワークデータベースである場合、本発明に基づくDBMS内での同時データベース修正処理中に、データベースの論理状態と物理状態がどのように関連し合っているかの例を表わしたものである。図の上部は論理状態を表わし、図の下部は該当する物理状態を表わす。図の左側は同時修正処理前のday1のデータベースの状態、図の右側は同時修正処理後のday2の予想されるデータベースの状態を表わす。さらに、各処理の塊には、ルートレコードの位置が含まれる。各物理状態を表す図の中の各塊のルートレコードは、半円で示される。
【００４１】
この例では、データベースには、世界２ヶ国（England、America）の国名が入ったday 1の２つのレコードが含まれている。さらに、A、Bという異なる２人のユーザーがデータベースに同時に追加を行おうとしている。ユーザーAは、レコード「France」を追加しようとしており、ユーザーBはレコード「Germany」を追加しようとしている。この例では、追加しようとしている「France」と「Germany」は、論理状態内部では互いに排他的なオプションと想定される。
【００４２】
図４の右上は、これらを追加した結果day 2になる２つの論理データベースを表わしたものである。図４の右下は、データベース内で両者の追加が物理的にどのように記録されるかを表わしたものである。これは、２つの異なる処理に該当するもう２つの塊を追加することにより行われる。各処理は、第１の塊を基準にする。本発明の基本原理に基づき、各塊には、前の塊の位置データが含まれる。図に表わされているように、両方の新規の塊には、前の塊が第１の塊であることを示すデータが含まれる。
【００４３】
図５は、本発明に基づくDBMSとともに使用するために、図３のリレーショナルデータベースのスキーマを詳しく表わしたものである。この例では、ネットワークスキーマは、バージョンコントロールレコードとバージョンレコードの新規レコードタイプを持つ。これらの新規レコードタイプがあることにより、VCSが、線状の発展過程において前後に行き来できるだけでなく、異なる発展分岐上においてリレーショナルデータベースのバージョン履歴を追跡することもできる。
【００４４】
【発明の効果】
データベース修正処理の前後両方におけるデータベースの状態のレコードを永久的に保持し、データベース修正処理の前後の両方におけるデータベースを簡単に得ることができる。
【図面の簡単な説明】
【図１】本発明に基づくDBMS（データベース管理システム）のデータベースファイル内における塊の物理構造を表わしたものである。
【図２】処理中における当該データベースの論理状態と物理状態を表わしたものである。
【図３】本発明に基づくDBMSがどのようにしてレコードを論理的に構造化しているかを、一般的なリレーショナルデータベースの形式で表わしたものである。
【図４】本発明に基づくVCS（バージョンコントロールシステム）が、どのようにしてDBMSのデータベースファイル内の塊を配列するかを表わしたものである。
【図５】 VCSが、本発明に基づくDBMS のバージョンコントロールを使ってどのようにしてレコードを論理的に構造化しているかを、一般的なリレーショナルデータベースの形式で表わしたものである。

Claims

データベースの状態に対する修正処理の前後両方における、データベースの状態を示すデータの塊を維持管理するためのデータベース管理システムであって、
データベース修正処理前およびデータベース修正処理後におけるデータベースの状態のレコードを永久的に保持するためのメモリ手段と、
データベースの各状態のレコード内にある１つ以上の親データ項目と、データベースの同一の状態のレコード内にある１つ以上の従属データ項目を関連付ける関連定義手段と、
データベースの各状態のレコード内にある、他のデータ項目と関連付けられているルートデータ項目の位置を定義するルート定義手段と、
そのデータベースの状態に該当するルートデータ項目と、そのデータベース状態のレコード内にある１つ以上のデータ項目、および以前の状態の位置により定義された修正処理前のデータベースの状態のレコード内にある１つ以上のデータ項目を関連付けることにより、データベース修正処理後のデータベースの状態を定義する状態定義手段と、
を有することを特徴とするデータベース管理システム。
前記状態定義手段は、１つ以上の親データ項目を介し、その親データ項目に関連する関連定義手段を使って、ルートデータ項目と１つ以上の従属データ項目を関連付ける請求項１記載のデータベース管理システム。
状態定義手段は、データ項目の追跡中、各従属データ項目に対する親データ項目の位置を記録する請求項２記載のデータベース管理システム。
データベース修正処理後のデータベースの状態を示す追加データの塊をコンパイルし、処理により修正されなかった前のレコードからはそれらのデータ項目をコピーせず、処理により修正された前のレコードからそれらのデータ項目をコピーする新規レコードコンパイル手段を備える請求項１，請求項２又は請求項３記載のデータベース管理システム。
前記新規レコードコンパイル手段は、前記関連定義手段によりそれらの従属データ項目と関連付けられている親データ項目をコピーするだけでなく、処理により修正された前のレコードから従属データ項目をコピーする請求項３記載のデータベース管理システム。
異なる論理構造内の各レコードのデータ項目を表示する表示手段を有する請求項１乃至５の内いずれか１項に記載のデータベース管理システム。
前記表示手段は、データ項目をリレーショナルデータベースの形式で表示する請求項６記載のデータベース管理システム。
前記表示手段は、データ項目をオブジェクトデータベースの形式で表示する請求項６記載のデータベース管理システム。
前記表示手段は、データ項目をバーチャルディスクドライブの形式で表示する請求項６記載のデータベース管理システム。
データベース修正処理後のデータベースの状態のレコードと、データベース処理前のデータベースの状態のレコードの位置を関連付ける前状態位置手段を有する請求項１乃至９の内いずれか１項記載のデータベース管理システム。
データベースの論理状態の内部に異なるバージョンどうしが同時に発展することができる分岐点を定義するバージョンコントロールシステム（VCS）が組み込まれている請求項１乃至１０の内いずれか１項記載のデータベース管理システム。
複数のユーザーが同時にデータベースを修正することができ、修正後にデータベースの状態において異なるバージョンを生成し、前記メモリ手段は、修正前のデータベースのユーザーの論理ビューの表示とともに、各ユーザーにより生成された修正後のデータベースの状態のレコードを永久的に保持するマルチユーザーシステムを備える請求項１１に記載のデータベース管理システム。
元に戻す／繰り返すの機構を有し、前記メモリ手段は、第１と第２のデータベース修正処理により生成された修正後のデータベースのレコードを永久的に保持し、ユーザーによる第１のデータベース修正処理後、当該データベース修正処理前のデータベースの状態はユーザーからの元に戻すコマンドに応じて定義され、続いて、第１のデータベース修正処理とは異なる第２のデータベース修正処理後のデータベースの状態は、第１のデータベース修理処理後のデータベースの状態の定義に代わるものとして、ユーザーによる繰り返すコマンドによって定義される請求項１１に記載のデータベース管理システム。
ユーザーにより行われたデータベース修正処理を分析する分析手段を備える請求項１３に記載のデータベース管理システム。
データベース修正処理の際のユーザーによる間違いを識別する誤り識別手段を備える請求項１３又は請求項１４に記載のデータベース管理システム。
各レコードにはレコード作成に関連した情報を提供するメタデータが含まれる請求項１乃至１５のうちいずれか１項に記載のデータベース管理システム。