JP2002229821A - データベース管理システム - Google Patents

Abstract

(57)【要約】 【課題】 データベースの以前の状態を簡潔に明示させ
るさせることができるデータベース管理システムを提供
する。 【解決手段】 各データベースの状態のレコード内にあ
る親データ項目（America、Spain; S*など）と、従属デ
ータ項目（Africa、Canada、France; France、Turkeyな
ど）とを関連付ける。レコード内のルートデータ項目
（England; E*など）と、そのレコード内にある他のデ
ータ項目とを関連付ける。当該連関を使えば、そのデー
タベースの状態に該当するルートデータ項目（E*）と、
データ項目（S*、Turkey）、および、データ修正処理前
のデータベースの状態のレコード内にあるデータ項目
（America、Africa、Canada、France）の両方を関連付
けることができる。これによりデータベース修正処理後
のデータベースの状態を定義でき、かつ修正処理前後の
データを保持でき修正前データを簡単に得られる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はデータベース管理シ
ステムに関連するものである。特に、データベースの状
態の修正処理の前後両方におけるデータベースの状態を
示すデータの塊を維持管理するためのデータベース管理
システムに関連するものである。

【０００２】

【従来の技術】一般に、コンピュータデータベースを維
持管理するために従来のデータベース管理システム（以
下、DBMSという）で使われる方法は、データレコードの
追加、修正、削除である。データレコードは修正、削除
されるので、完成したデータベースの前の状態を直接明
示することはできない。

【０００３】既知のシステムのなかには、あるチェック
ポイントにおけるデータベースファイルのコピーととも
に付随のログファイルに全ての処理指示を記録すること
により、リレーショナルデータベースの以前のバージョ
ンへアクセスできるものある。しかしながら、以前のチ
ェックポイントにおけるコピーに対しログファイルを再
実行しなければならないことや、それぞれのチェックポ
イントのコピーとログファイルには論理的に冗長なデー
タが大量に含まれるので多くのスペースが必要となるこ
とから、この方法は満足なものとはいえない。

【０００４】

【発明が解決しようとする課題】本発明の目的は、多数
の、データベースの以前の状態を極めて簡潔に直接明示
させるさせることができるデータベースの維持管理を可
能にする構造をDBMSに提供することである。

【０００５】

【課題を解決するための手段】本発明に基づき、データ
ベースの状態の修正処理の前後両方におけるデータベー
スの状態を示すデータの塊を維持管理するためのデータ
ベース管理システム（DBMS）が提供される。このデータ
ベース管理システムは、データベース修正処理前および
データベース修正処理後におけるデータベースの状態の
レコードを永久的に保持するメモリ手段と、データベー
スの各状態のレコード内にある１つ以上の親データ項目
と、データベースの同一の状態のレコード内にある１つ
以上の従属データ項目を関連付ける関連定義手段と、デ
ータベースの各状態のレコード内にある、他のデータ項
目と関連付けられているルートデータ項目の位置を定義
するルート定義手段と、データベースの状態に該当する
ルートデータ項目と、そのデータベースの状態のレコー
ド内にある１つ以上のデータ項目、および以前の状態の
位置により定義された修正処理前のデータベースの状態
のレコード内にある１つ以上のデータ項目を関連付ける
ことにより、データベース修正処理後のデータベースの
状態を定義する状態定義手段を備えている。

【０００６】このDBMSにより、大量の冗長なデータの格
納を要することなく、データベースの前の状態の全てへ
直接アクセスできる方法で、コンピュータデータベース
の維持管理を行うことができる。

【０００７】又、このDBMSの構造は、様々な種類の樹木
が、毎年新しい年輪ができることで生育していく過程に
たとえることができる。この構造では、木の外輪を剥ぎ
取っていくことにより、木の前の状態を全て直接明示す
ることができる。類推すれば、本発明は、既存データ項
目の修正あるいは削除を要することなく、データ項目を
データベースに追加することのみにより、コンピュータ
データベースを柔軟に維持管理することができるDBMSに
関連している。

【０００８】各データベース修正処理中に、新規データ
項目の塊がデータベースファイルの末尾に追加される。
ファイル内の前の塊の中にある前のデータ項目は、修正
される必要はない。このように、一定数のはじめの塊の
みを考慮し、残りの追加された塊は無視することで、DB
MSによりある時点以前のデータベースの状態の全てを直
接明示することができる。例えば、データベースファイ
ルが、７つの処理に該当する７つの塊から成る場合、DB
MSは第１から第３までの塊をチェックし、第４から第７
までの塊を一時的に無視することにより、第３処理後の
データベースの状態を明示できる。

【０００９】塊の中にあるレコードは、以下の原理に基
づいて構造化される。 ・データ項目の塊は、処理が行われる際、データベース
ファイルに追加される。 ・データベースファイルに追加された塊は、絶対に編集
されない。 ・概して、塊は、前のデータベースファイルの全体のサ
イズより小さい。 ・前の塊の中にあるデータ項目が処理により論理的に削
除あるいは修正されなかった場合、塊は、前の塊の中に
あるデータ項目を参照する。 ・前の塊の中にあるデータ項目が処理により論理的に削
除あるいは修正された場合、塊は、前の塊の中にあるデ
ータ項目をマスクし参照しない。 ・塊は、後に生成された塊の中にあるデータ項目は参照
しない。

【００１０】これらの原理は、以下の方法で利用され
る。 ・各データ項目は、ファイル内の塊の中に位置する。 ・データ項目は、親データ項目になる場合もある。 ・各親データ項目には、その従属データ項目の位置を示
すデータが含まれる。 ・各処理の塊には、ルートデータ項目の位置が含まれ
る。 ・DBMSは、ルートデータ項目から従属データ項目を追跡
したのち、さらに追跡済みデータ項目から従属データ項
目を追跡することにより、データ項目のネットワークを
辿ることができる。 ・DBMSは、このデータ項目ネットワークを横断しなが
ら、各追跡済み従属データ項目の位置を記録するための
手段をうまく含めることができる。

【００１１】・従って、データベースファイル内の塊の
中にある従属データ項目には、それらの親データ項目の
位置は格納されない。 ・追跡開始に使われるルートデータ項目によっては、DB
MSにより異なるネットワークのデータ項目が表示される
場合もある。

【００１２】一般に、コンピュータサイエンスでは、デ
ータベースは「物理的な」状態と「論理的な」状態を持
っていると言える。物理状態とは、例えば磁気ディスク
やCD-ROMといった相応のコンピュータデータ記憶装置に
格納されているデータの配列のことをいう。 論理状態
とは、これらのデータによって具体化された情報の概念
的な構成（ビュー）のことをいう。一般に、DBMSとは、
他のコンピュータプログラムに対し異なる論理状態を提
示しながら、物理状態を操作することができるコンピュ
ータプログラムのことをいう。

【００１３】本発明に基づくDBMSは、データ項目が追
加、編集、削除された場合に、物理状態の既存データ項
目を編集あるいは削除することなく、データ項目をデー
タベースの物理状態に追加することにより、修正後のデ
ータベースの論理状態を提示することができる。

【００１４】データベース修正処理中、DBMSは、データ
ベースファイルに追加されるデータ項目の塊を以下の方
法で作成する。 ・新規の従属データ項目は、新規の塊に挿入することが
できる。 ・前の塊の中にある論理的に編集されたデータ項目は、
コピーされなければならない。 ・論理的に編集あるいは削除されたデータ項目の親デー
タ項目の全てはコピーされなければならない。

【００１５】・編集された親データ項目の従属データ項
目のうち、既存で未編集のものはコピーされなくてもよ
い。新規の親データ項目コピーは、前の塊の中にある未
編集の従属データ項目の位置データを使用することがで
きる。 ・塊には、新規ルートデータ項目の位置を示すデータが
含まれる。 ・塊には、前の塊の位置を示すデータが含まれる。

【００１６】従って、各データベース処理はデータの塊
の中で実施され、また、DBMSは、該当処理のデータの塊
の中に示されているルートデータ項目から始まっている
データ項目ネットワークを辿ることにより、対象となる
処理の直後の、データベース全体の状態を直接明示する
ことができる。このように、DBMSは、データベース履歴
内の処理間のどの時点においても、データベースのその
時点の状態を直接明示することができる。

【００１７】本発明の実装例において、データベースの
論理状態において頻繁に発生するか、あるいは頻繁に発
生する可能性のあるデータ値は、多数の他データ項目の
従属データ項目として再度使用することができるよう
に、データ項目ネットワークの一部のデータ項目に格納
してもよい。例えば、「London」というテキスト値は、
英国の住所データベースに頻繁に出現する可能性があ
る。

【００１８】さらに、本発明の実装例において、データ
項目ネットワークは従来のネットワークデータベースの
形式であってもよい。一般に、ネットワークデータベー
スでは、アプリケーションプログラムに適した方法で、
データレコードどうしをリンクすることができる。従来
のネットワークデータベースでは、通常、以前のバージ
ョンのデータベースを直接明示することはできないが、
本実装例のDBMSでは、以前のバージョンのネットワーク
データベースの全てを直接明示することができる。

【００１９】例えば、データ項目のネットワークが、テ
ーブル、ビュー、行、列、フィールドなどが組み込まれ
ている従来のリレーショナルデータベースを構成する場
合がある。DBMSには、ユーザーによるデータベースの機
能関連ビューへのアクセス、修正を可能にするSQL用の
解釈プログラムを含めることもできる。さらに、ユーザ
ーは、データベース履歴内の処理間のどの時点における
データベースの関連ビューに直接アクセスすることがで
きる。

【００２０】また、データ項目のネットワークがオブジ
ェクトデータベースを構成する場合もある。一般に、オ
ブジェクトデータベースには、カプセル収納データとプ
ログラムの動作から成るオブジェクトが含まれる。この
場合、ネットワークには、オブジェクトクラスとオブジ
ェクトインスタンスに該当するデータ項目が含まれる。
オブジェクト間の論理参照は、参照先オブジェクトに該
当するデータ項目の位置データを含んだ参照元オブジェ
クトに該当するデータ項目によりモデル化される。

【００２１】本発明の別の実装例において、データ項目
ネットワークがバーチャルディスクドライブ（VDD）を
構成する場合がある。そのVDDには、過去のVDDの論理状
態にいつでも直接アクセルすることができるという追加
的機能が備わっている。一般に、バーチャルディスクド
ライバは、他のコンピュータプログラムが、そのインタ
ーフェースのソフトウェアをあたかもコンピュータディ
スクのように扱うことができるコンピュータソフトウェ
アインターフェースである。そのようなインターフェー
スは、通常、一定の有効な位置範囲内でのランダムな位
置において、例えばデータの読み込み、書き出し、修正
などの機能をサポートする。データ項目ネットワーク内
のデータ項目のなかには、バーチャルディスク（例え
ば、ディスクセクターなど）内の位置範囲に該当するも
のもある。これらのデータ項目には、該当するバーチャ
ルディスク範囲内に論理的に格納されたデータが含まれ
る。コンピュータアプリケーションがVDD内のある範囲
の内容を修正しようとする場合、DBMSはその論理的なデ
ィスクの修正に該当する処理の塊を新規に作成する。DM
BSは、データ項目あるいはVDD内のその範囲に該当する
複数のデータ項目を用意することにより、それらのデー
タ項目の新バージョンを作成する。場合によっては、DB
MSは、該当する論理データを表わす際の物理データの効
率を上げるために、物理レコードに該当する論理範囲を
分割あるいは併合する。従って、異なるレコード内で具
体的に使用されるバーチャルディスクの容量には差があ
る。データ項目ネットワーク内のデータ項目の親／従属
階層は、バーチャルディスク上の該当範囲およびサブ範
囲の場所と関連する。

【００２２】本発明の更なる実装例においては、DBMSに
バージョンコントロールシステム（VCS）が組み込まれ
る。当該VCSにより、データベースがどのように構築さ
れたかを示すために、データベースのバージョンを整理
することができる。また、VCSは、データベースの論理
状態の代替バージョンを並行して構築できる分岐点を含
めることもできる。

【００２３】各新規データの塊には、前のデータの塊の
位置データが含まれる。前のデータの塊は、必ずしもフ
ァイル内にある新規の塊の直前の塊であるとは限らな
い。前の塊は、さらにその前の塊である場合もある。こ
のように、VCSは、複数の塊を複数バージョンから成る
論理階層に配列することができる。また、各新規の塊に
は、作成日時、変更を行ったユーザーの名前、変更理
由、変更に関連するプロジェクト、ジョブ、業務などの
メタデータが含まれる。

【００２４】バージョンデータ項目と呼ばれるデータ項
目のネットワークのなかには、それらの従属データ項目
とともに、論理データベースのあるバージョンを具体化
するものもある。バージョンデータ項目は、それ自体が
バージョンコントロールデータ項目の従属データ項目で
ある場合もある。VCSは、バージョンコントロールデー
タ項目を介して、ルートデータ項目からバージョンデー
タ項目、論理データベースのデータ項目までのデータ項
目のネットワークを案内することができる。

【００２５】一般に、マルチユーザーの処理データベー
スでは、複数ユーザー（複数の人間あるいはコンピュー
タプログラム）が同時にデータベースにアクセスするこ
とができる。単一ユーザーがデータベースを修正する場
合、処理を開始し、必要な修正を行ったのち、その処理
を実行に移す。複数ユーザーがデータベースを同時に修
正する場合、１人あるいは複数のユーザーは、（処理の
開始段階あるいは実行段階で）DMBSにより修正要求が拒
否される場合がある。

【００２６】本発明の開発においては、前述のVCS機能
を開始＋実行処理論理に組み込むことにより、複数ユー
ザーの同時修正要求が原因で生じる修正拒否を避けるマ
ルチユーザー対応のDBMSが提供される。ユーザーが処理
を開始すると、DBMSは、そのユーザーのデータベースの
論理ビューに関連する塊と、開始処理を関連付ける。そ
の後、ユーザーが処理を実行すると、DBMSは、VCSを介
して表示した際、処理に関連する塊から論理的に派生し
て作成される新規の塊を追加する。複数ユーザーが同時
に処理を開始し、その後処理を実行した場合、DBMSは、
異なる分岐に新規バージョンを格納しておく必要があ
る。これらの分岐は、おそらくアプリケーション固有の
アルゴリズムを使って、後でまとめることができる。

【００２７】一般に、アプリケーションプログラムに
は、元に戻す／繰り返すコマンドが提供されていること
が多く、そのためユーザーは、行った変更を取り消し、
気が変わった場合は再実行できるという確信を持ってデ
ータベース（例えば、文書処理ファイルなど）に変更を
行うことができる。これにより、ユーザーは、操作ミス
による不本意な結果から解放される。

【００２８】本発明の更なる開発において、元に戻す／
繰り返す機構をユーザーに提供するアプリケーションの
データ管理をサポートするために、VCS機能がDBMSに組
み込まれる。ユーザーが変更を行うと、DBMSは処理の塊
をデータベースに追加する。ユーザーが元に戻すコマン
ドを使用すると、DBMS 内にあるVCSが前のバージョンの
データベースに戻すので、行った修正は取り消され、元
の状態に戻る。その後ユーザーが別の変更を行うと、DM
BSは別の処理の塊を追加し、VCSはその変更用の分岐を
新規に作成する。このように、ユーザーが引き起こすデ
ータベースの状態の全て、およびそれらの順序が記録さ
れる。従って、DBMSは、ユーザーの操作や作業効率、操
作のミスを分析するために必要な生データを自動的に収
集する。この生データは、ユーザーの作業処理能力を監
視し、ユーザーの訓練を助け、アプリケーションソフト
ウェアのユーザーインターフェースを改善することがで
きる。

【００２９】本発明のアプリケーションにおいて、DBMS
は、追加のみ可能で修正不可能な媒体を使ってデータベ
ースを物理的に格納し、さらに、修正可能なデータベー
スの論理ビューを提供する。例えば、コンパクトディス
クのなかには、データを追加することはできるが、既に
書き込まれているデータを修正することはできないタイ
プもある。こういった追加専用の媒体は、追記形（WOR
M：Write-Once-Read-Many）装置とも呼ばれる。

【００３０】

【発明の実施の形態】本発明をより十分に理解してもら
うために、一例として、添付図面とともに説明する。図
１は、本発明に基づくDBMSのデータベースファイル内に
おける塊の物理構造を表わしたものである。図２は、処
理中における当該データベースの論理状態と物理状態を
表わしたものである。図３は、本発明に基づくDBMSがど
のようにしてレコードを論理的に構造化しているかを、
一般的なリレーショナルデータベースの形式で表わした
ものである。図４は、本発明に基づくVCSが、どのよう
にしてDBMSのデータベースファイル内の塊を配列するか
を表わしたものである。図５は、VCSが、本発明に基づ
くDBMS のバージョンコントロールを使ってどのように
してレコードを論理的に構造化しているかを、一般的な
リレーショナルデータベースの形式で表わしたものであ
る。

【００３１】これらの図は、当該システムの基本原理の
例証として、本発明に基づくDBMSのうち、シンプルで代
表的なものの構造を表わそうとしたものであり、また、
本発明に基づき作成されると思われる実際のシステムに
は、技術面で熟練したユーザーに十分理解されるような
追加機能を含め、更に高度なレベルの構造的な複雑さが
組み込まれることを表わそうとしたものである。

【００３２】図１は、毎日の新たな処理により新規の塊
がファイルに追加される場合に、当該DBMSの基本構造
が、どのようにしてデータベースファイルを一連の塊と
してフォーマットしているかを表わしたものである。da
y1、day2、day3と記されたボックスは、毎日ファイルに
追加される塊を表わす。

【００３３】図２は、当該データベースがシンプルなネ
ットワークデータベースである場合、データベース修正
処理中に、データベースの論理状態と物理状態がどのよ
うに関連し合っているかを代表的な例で表わしたもので
ある。図の上部は論理状態を表わし、図の下部は該当す
る物理状態を表わす。図の左側は処理前のday1のデータ
ベース状態、図の右側は処理後のday2のデータベース状
態を表わす。各処理の塊には、ルートレコードの位置が
含まれる。各物理状態図の中の各塊のルートレコード
は、黒の半円で示される。

【００３４】データベース修正処理前、データベースに
は、世界６ヶ国（America、Spain、Africa、Canada、 F
rance）の国名が入った６つのデータ項目が含まれてい
る。論理状態では、データ項目は２分木で表わされる。
この例では、２分木は分類されているので、どの親デー
タ項目も左側の従属データ項目よりもアルファベット順
で後に置かれ、右側の従属データ項目よりもアルファベ
ット順で前に置かれる。物理状態では、データ項目は単
一の塊の中に格納される。物理状態では、親データ項目
（England、America、Spain）には、従属データ項目（A
merica、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 (16)

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