JPWO2005086003A1 - データベース・システム - Google Patents

Abstract

【目的】データベースを無停止で運用したまま、列の追加等を可能とし、古いデータベース定義体を使用しているプログラムの稼動が保証でき、データベース定義体の作成・変更を自動的に行うことを目的とする。【構成】データを格納し、検索するデータベース・システムにおいて、或るバージョンのデータベース定義体により定義されたレコードを、別のバージョンのデータベース定義体により定義されたレコードに変換する論理構造変換部と、或る１種類のテーブルのレコードに対して複数のバージョンのデータベース定義体と、そのデータベース定義体により定義された複数のバージョンのレコードを格納するデータ格納部と、を備えたデータベース・システム。

Description

本発明は、コンピューターにおけるデータを格納し、検索するデータベース・システムに関するものである。

従来のコンピューターによるデータベース格納検索方式は、「Jeffrey D.Ullman著、国井他１名訳、"データベース・システムの原理" ，第1版，日本コンピューター協会，1985年5月25日」、「Samuel Leffler他著/中村明他訳，”UNIX4.3BSDの設計と実装”,丸善株式会社，1991年6月30日」など多数の書籍に記載されている。
このような従来のデータベース格納検索方式によれば、（１）インデックスの創生や維持に負荷がかかること、（２）最終的に使用されると想定される最大のブロックを予め生成しておかなければならないこと、（３）インデックスが階層構造をとっているため、データの挿入や削除によってインデックスの更新が行われる場合に、上位インデックスまで変更される場合が発生するために排他範囲が広くなり、デッドロックを引き起こしやすいこと、などの不都合があった。

このような従来のデータベース格納検索方式の不都合を解消するため、本発明者は、従来の階層型インデックスに代えてロケーション・テーブルと代替キー・テーブルという概念を導入し、インデックスの処理に伴う複雑な処理を簡素化し、テーブル自体の検索をバイナリー・サーチなどの手法を用いることにより、高速化と、メンテナンスの容易性を確保できるようにしたデータ格納検索方式を提案した（日本国特許第３３４５６２８、米国特許第６６５４８６８号参照）」。

このデータベース・システムには、次のような問題があった。実際にデータベース・システムを運用していく場合に、データ項目の変更や追加・削除・変更が発生することがある。このデータベースでは、データ項目を追加する場合に、データベース・システムの運用を止めて、データベースの定義変更を行い、データの変更を行った後、データベース・システムを稼動させることになる。このような作業は、数時間と言った長時間を必要とするものであり、その間、データベースを停止させることは、連続稼動を要求されるシステムにおいては、大きな制約となっていた。

また、それ以上に、データベースを使用しているアプリケーション・プログラムを調査し、矛盾が発生しないように修正する手間は、膨大な時間を必要とするものであった。このように、アプリケーション・プログラムの変更を行わなければならないということは、列の追加・変更・削除が必要になっても、これらを決断するには大きな理由が必要であった。

本発明に関連する既存の発明として、「データベースの再編成システム、並びに、データベース（以下、「データベース再編成システム」と呼ぶ。特許出願ＰＣＴ／ＪＰ０３／１１５９２）」、「データベースのアクセラレーター機能（以下、「アクセラレーター機能」と呼ぶ。ＰＣＴ／ＪＰ0３／１３４４３）」、「データ格納検索システム（特願２００４−０２０００６）」が挙げられる。

従来のデータベース・システムでは、データベースに列の追加・削除・変更を行うことは、長時間、データベースの稼動を止める方法しか存在していなかった。また、データベースの列を追加・削除・変更することは、データベースの定義を変更することであるが、定義を変更した場合、古い定義で稼動していたアプリケーション・プログラムを新しいデータベース定義で稼動させることは不可能で、必要なアプリケーション・プログラムを修正したり、再コンパイルする必要があった。このため、列の追加・削除・変更を簡単に実行することは不可能であった。

本発明の実施の形態は、次の課題を解決することができるものである。
１．データベース・システムの性能を向上することにある。
２．データベース・システムの列の追加、削除、又は変更を容易に行えるようにすることにある。
３．列の追加、削除、又は変更を行う場合にデータベースの稼動を止めることなく、運用しながら実行できるようにする。
４．列の追加、削除、又は変更を行った場合でも、アプリケーション・プログラムを変更することなく稼動することにある。
５．同一のテーブルのレコードに関して、列の追加、削除、変更が行われると、新たなレコード形式となるが、従来のデータベースでは最新のレコード形式のものしか扱えなかった。それらの複数の形式のレコードを格納し、それらのレコードに対して、検索、追加、更新、削除が行えるので、これまでに無かった履歴型のデータ格納管理を行うことにある。

課題を解決する為の手段

本発明は、データを格納し、検索するデータベース・システムにおいて、或るバージョンのデータベース定義体により定義されたレコードを、別のバージョンのデータベース定義体により定義されたレコードに変換する構造変換部と、或る１種類のテーブルのレコードに対して複数のバージョンのデータベース定義体と、そのデータベース定義体により定義された複数のバージョンのレコードを格納するデータ格納部と、を備えたデータベース・システムにある。

本発明は、データを格納し、検索するデータベース・システムにおいて、或るバージョンのデータベース定義体により定義されたレコードを、別のバージョンのデータベース定義体により定義されたレコードに変換する構造変換部と、或る１種類のテーブルのレコードに対して単一のバージョンのデータベース定義体と、そのデータベース定義体により定義された単一のバージョンのレコードを格納するデータ格納部と、を備えたデータベース・システムにある。

は、明細書で説明するデータベースの形式である。 は、プライマリー・ブロックとオーバーフロー・ブロックに対する再編成を図示したものである。 は、列追加を行うとするデータベースである。ここでは、代替キーについては省略している。 は、図３のデータベースのデータベース定義体である。 は、列追加：過去遡及型・子データベース方式で、列ｂを追加する場合の途中まで進行した図である。この図では、ｒｅｃｏｒｄ２までの列追加が終了していることを示している。 は、列追加：過去遡及型・子データベース方式で、列ｂを追加する場合の、データベース定義体と定義体クロス・リファレンス・テーブルの図である。データベース定義体はＶ１とＶ２を示している。Ｖ１は、列追加前のデータベース定義体、Ｖ２は列追加後のデータベース定義体である。 は、列追加：過去遡及型・子データベース方式で、列ｂの追加が完了した状態のデータベースを示している。 は、列追加：過去遡及型・子データベース方式で、列ｂの追加が完了した後に、レコードの追加が行われた状態を示している。 は、列追加：過去遡及型・直接追加方式で列ｂを追加する場合の途中まで進行した図である。この図では、ｒｅｃｏｒｄ３まで再編成が終了している状態を示している。 は、列追加：過去遡及型・直接追加方式で列を追加する場合の、データベース定義体と定義体クロス・リファレンス・テーブルの図である。この場合は、図３のデータベースおよび図４のデータベース定義体に示されたデータベースをＶ１とし、列を追加後のデータベース定義体をＶ２としている。 は、列追加：過去遡及型・直接追加方式によって列を追加する場合、列の追加が完了した状態を示している。 は、列追加：過去遡及型・直接追加方式によって列を追加する場合、列の追加が完了した状態での、データベース定義体を示している。 は、列追加：過去非遡及型・子データベース方式による列追加を行うとするデータベースの図である。 は、列追加：過去非遡及型・子データベース方式による列追加を行う際の、準備作業が終了した時点の図である。 は、列追加：過去非遡及型・子データベース方式により、列追加がされたレコードがデータベース上に格納された時点の図である。 は、列追加：過去非遡及型・子データベース方式による列追加を行う際の、データベース定義体と定義体クロス・リファレンス・テーブルの図である。 は、レコード中にそのレコードを作製したデータベース定義体のバージョンを保持する場合の図である。 は、ブロック中に、そのブロック中のレコードを作成したデータベース定義体のバージョンを保持する場合の図である。 は、列追加：過去非遡及型・直接追加方式のデータベース定義体と定義体クロス・リファレンス・テーブルの図である。 は、列追加：過去非遡及型・直接追加方式で列追加を行ったレコードが、データベース上に格納された図である。 は、列追加：子データベース方式で作成された子データベースを親データベースにまとめる際の、データベース定義体と定義体クロス・リファレンス・テーブルの図である。 は、列追加：子データベース方式で作成された子データベースを親データベースにまとめる際、ｒｅｃｏｒｄ３までのまとめが終了した図である。 は、列追加：子データベース方式で作成された子データベースを親データベースにまとめる際、まとめが完了した図である。 は、列追加：子データベース方式で作成された子データベースを親データベースにまとめる際、まとめが完了した時点のデータベース定義体と論理構造変換テーブルの図である。 は、列削除：定義削除方式の図である。 は、列削除：定義削除方式を行った場合のデータベース定義体と論理構造変換テーブルの図である。 は、列削除：過去保持・子データベース方式を適用するデータベースの図である。 は、列削除：過去保持・子データベース方式を適用し、準備作業が終了した時点のデータベースの図である。 は、列削除：過去保持・子データベース方式を適用し、準備作業が終了した時点のデータベース定義体と論理構造変換テーブルの図である。 は、列削除：過去保持・子データベース方式を適用し、ｒｅｃｏｒｄ３までの処理が終了した時点のデータベースの図である。 は、列削除：過去保持・子データベース方式を適用し、処理が完了した時点のデータベースの図である。 は、列削除：過去非保持型・直接列削除方式を適用し、ｒｅｃｏｒｄ３までの処理が終了した時点の図である。 は、列削除：過去非保持型・直接列削除方式を適用した場合の、データベース定義体と論理構造変換テーブルの図である。 は、列削除：過去非保持型・直接列削除方式を適用した場合の、列削除後のデータベース定義体と論理構造変換テーブルの図である。 は、列削除：過去非保持型・直接列削除方式を適用した場合の、列削除が完了した時点のデータベースの図である。 は、オーバーフロー・ブロック管理テーブルを示した図である。 は、列追加：子データベース方式に、オーバーフロー・ブロック管理テーブルを用いたデータベースを適用した場合の図である。 は、列追加：直接追加方式に、オーバーフロー・ブロック管理テーブルを用いたデータベースを適用した場合の図である。 は、再編成時に、新規ロケーション・テーブルの初期容量を小さくする手法を応用して、一部の再編成を高速に行う場合の例である。 は、アクセラレーター・システムの原理を示した図である。 は、アクセラレーター・システムに、オーバーフロー・ブロック管理テーブルを用いたデータベースを適用した場合の図である。 は、ＸＭＬの例である は、ＸＭＬの例である は、ＸＭＬに適用した場合に、複数の列を１つの代替キーにする方法の図である。 は、複数の列を１つの代替キーにする方法の場合の、代替キーエントリーの図である。 は、過去非遡及型の場合の、レコード読み取り要求を処理する図である。 は、過去非遡及型の場合の、レコード更新要求を処理する図である。 は、過去非遡及型の場合の、レコード削除要求を処理する図である。 は、過去非遡及型の場合の、レコード追加要求を処理する図である。 は、過去遡及型の場合の、レコード読み取り要求を処理する図である。 は、過去遡及型の場合の、レコード更新要求を処理する図である。 は、過去遡及型の場合の、レコード削除要求を処理する図である。 は、過去遡及型の場合の、レコード追加要求を処理する図である。 は、論理構造変換テーブルの例である。 は、論理構造変換をロジックで行う場合の例である。 は、任意のデータベース定義体から、新たなデータベース定義体を作成する場合の例である。 は、親データベースと子データベースの例である。

本明細書では、方法の説明が多くなるが、ここで述べる方法を用いてシステムを構築することが可能である。

［レコード］
レコードとは、必ず１つのユニークな主キーとゼロ個若しくは１個以上のノンユニークなキー（代替キー。結果的にユニークであっても問題はない）を持つ。この他に、キーとはならない項目（列）を持つことができる。主キーは、例えば従業員データベースの場合、従業員コードなど従業員を識別できるコードであり、代替キーは、氏名や生年月日などであり、データベースによっては、無くても良いし、複数あっても構わない。また、意味を持った主キーとなるべき項目存在しないレコードに関しては、格納順の連番などを付与して、それを主キーとしても良い。項目（列）は、情報の単位であり、キーとなるものとキーとならないものがある。レコード中に１つ以上存在する。列は、固定長形式でも良いが、可変長形式とすることも可能である。可変長形式の場合は、列毎に可変長とすることが可能であり、列情報が存在しない列も、列として認識することが可能である。レコードは論理的な集合体として捉えることができる。主キーに従属する項目の集合を広義の論理レコードと定義できる。しかしながら、常に主キーに従属する項目すべてを１つの論理レコードとするわけではない。例えば、従業員コードに従属する項目を考えた場合に、氏名や生年月日、所属入社年月日、電子メールアドレス、内線電話番号などの情報がある。更に、住所や出身学校、家族といった情報もある。その他に、給与や賞与の情報もある。また、更に評価結果情報もある。

これらの情報は、扱うことが多い単位毎にまとめたり、セキュリティの関係から、一部を別のレコードにしたりする。例えば、上記の場合であれば、従業員マスターには、氏名、生年月日、入社年月日、所属、電子メールアドレス、内線電話番号を入れる。従業員個人ファイルには、住所、出身学校、家族を入れる。従業員給与ファイルには、給与や賞与の情報を入れる。従業員評価ファイルには、評価結果を入れる。このようにして、従業員コードに従属する論理レコードが４つ作成される。また、それらの論理レコードは、複数の物理レコードから構成することが可能である。例えば、従業員評価ファイルを例に取る。評価項目として、従来は評価項目を挙げて、上司がスコアリングする方式を採用していたとする。それに対して、部下の評価を付け加えることになったとする。そのような場合、上司の評価と部下の評価をまとめて、新たに１つの物理レコード＝論理レコードとすることが可能である。一方、それまでの上司の評価を格納してあるレコードはそのままとして、新たに部下の評価を入れた物理レコードを作製し、両者を併せて新たな論理レコードとすることが可能である。また、この場合、上司の評価ファイルと部下の評価ファイルを、各々、独立した論理レコードとして扱うことも可能である。これを、更に細分化すると、項目毎に主キーと組み合わせて、別々の物理レコードとすることも可能である。本明細書では、特に断りの無い限り、論理的なレコードを対象とした説明を行う。

この広義のレコードは、実体として存在させる１つ目の方法として、主キーに従属する項目をすべて並べて、１つの連なりとすることができる。これが、一般的なレコードの概念である。実体として存在させる二つ目の方法として、主キーとその主キーに従属する項目の２つからなるレコード、つまり、狭義のレコードとして格納することが可能である。主キーに従属する項目毎に狭義のレコードを作製するという方法である。この狭義のレコードの集合体が広義のレコードとなる。実体として存在させる３つ目の方法としては、１つ目の方法と二つ目の方法の折衷案的な方法で、主キーに従属する１つ以上の項目からなる狭義のレコードを複数作製し、その狭義のレコードの集合を広義のレコードとするものである。本明細書では、特に断りの無い限り、広義のレコードを使用するが、子データベース方式は、第３の方法を用いたものである。

データベース定義体とは、一般的なデータベース・システムでデータベースを定義するために用いられている。データベース定義体は、データベースに関する物理構造、論理構造、格納構造、インデックス構成情報、属性など幅広い情報を保有しているが、少なくともレードの構成情報を持つものとする。レコードの構成情報とは、物理構造、論理構造、属性情報を含む情報のことである。本明細書では、データベース定義体という用語を用いて説明を行うが、その内容は、レコード構成情報に関するものである。つまり、データベース定義体におけるレコード構成情報を、データベース定義体と呼ぶということである。データベース定義体のバージョンとは、同一のテーブルに対して、列の追加や削除、変更を行うことにより、レコードの論理構造や物理構造が変更されるが、その変更に伴って新たに作成するデータベース定義体を新しいバージョンのデータベース定義体とする。ここで、テーブルとは、データベースで一般的に用いられる、行と列からなる或るファイル（例えば従業員マスター、得意先マスター、商品マスター、売掛金ファイルなど）のことを意味し、後述する、ロケーション・テーブルや代替キー・ロケーション・テーブル、論理構造変換テーブルなどとは異なるものである。本明細書で使用している、各種のテーブルは、ロケーション・テーブルや代替キー・ロケーション・テーブル、論理構造変換テーブルなどとの名称で呼び、単にテーブルと呼ぶことは無い。

まず、列の追加・変更・削除を行う際に、アプリケーション・プログラムの変更を要しないことについて述べる。従来の方法は、データベースを一旦停止し、その後に列の追加・削除・変更を行い、データベースの再稼動を行っていた。このため、データベースに格納されているレコードの形式は最新の一世代のみに限られていた。この情報はデータベース定義体に格納されている。アプリケーション・プログラムも、データベースの最新の世代に合致するように修正されたものを用いていた。

本発明では、データベースに格納されているテーブル内のレコードに対して、そのレコードが作成されたデータベース定義体のバージョン情報を保持すること、複数世代のデータベース定義体を保有すること、各バージョンの論理構造を変換すること、アプリケーション・プログラムがどのバージョンのデータベース定義体を使用しているかの情報（アプリケーション・プログラムのバージョン情報）を保有すること、および、複数のバージョンの振り分けを行うことにより、実現するものである。図４６は、複数のバージョンのアプリケーション・プログラムから、データベースにアクセスする場合の図である。この図では、ＲＥＡＤ処理（読み出し処理は、ＳＱＬでは、多くの場合ＳＥＬＥＣＴである。）を図示している。アプリケーション・プログラムなどの要求元３０からＲＥＡＤ命令をデータベース・システムに指示する。データベース・システムでは、リクエスト受付処理３１を行い、その後、インデックス検索処理３２を行う。ここまでは、従来のデータベース・システムと同様である。データが格納されているデータ格納部３３から目的のレコードを見つける。そのレコード内またはレコード外の特定の場所に、そのレコードが作成された時のデータベース定義体のバージョン情報（レコード・バージョン情報）を予め格納しておくものとする。このレコード・バージョン情報は、そのレコードを作製・変更する都度、格納するものとする。

読み出したレコード・バージョン情報に合致するバージョンのデータベース定義体に、レコードを送る。ここで物理構造に基づいて、レコードが格納されているブロック等（データベース・システムによって名称が異なる）から、レコードを読み出す。そして、読み出したレコードを、そのバージョンの論理構造に変換する。その後、論理構造変換部を用いて、アプリケーション・プログラムのデータベース定義体のバージョンに変換を行う。論路構造変換部は、或るバージョンのデータベース定義体により定義されたレコードを、別のバージョンのデータベース定義体により定義されたレコードに変換するものであり、例えば、論理構造変換テーブルや論理構造変換プログラム・ロジックなどが使用できる。変換されたレコードをアプリケーション・プログラムに渡す。このように、格納されているレコードが作成されたデータベース定義体のバージョンと、読み出す側のアプリケーション・プログラムが使用しているデータベース定義体のバージョン情報に関係なく、レコードを読むことが可能となる。ＲＥＡＤ処理と同様に、レコードの更新、追加、削除も可能である。

列の追加は、大別すると過去遡及型と過去非遡及型の２つの方法となる。各々の型は更に、子データベース追加方式と、直接追加方式の２つに分かれるため、全体として４つの実現方式が存在する。
過去遡及型は、列の追加を行う際に、それまでに作成されたレコードに対して、追加する列の値を予め用意し、それらの値を既存のレコードに追加していくものである。このようにすることによって、既存のレコードも追加列の値を保有することになる方式である。過去非遡及型は、列の追加を行う際に、それまで作成されたレコードに対して、追加する列の値を用意せず、新たに作成されるレコードに関しては追加列の値を持つが、列追加を行う以前に作成されたレコードに関しては、追加列に値を持たない方式である。追加列に値が無いレコードの追加列の値は、初期値やヌル値、または情報を持たない列としてアプリケーション・プログラムに渡す。また、特定のリターンコードを渡すことも可能である。これは、以下の説明でも同様である。

子データベース方式とは、既存の列追加が行われるデータベースとは別に、追加する列を格納するデータベースを別の新規データベース（子データベース）として定義し、既存のデータベースの主キーと追加する列（項目）を組としてレコードの形式にし（子レコード）、新規データベースの主キーは、既存のデータベースの主キーを設定し、新規データベースに子レコードを作成する方法である。

直接列追加方式とは、既存のデータベースに対して、直接的に列を追加する方法である。これは、「データベース再編成システム」で示された方法を応用して実施する。列の追加はレコード毎に行うが、処理の単位はブロックである。現用のロケーション・テーブルに対して、新規のロケーション・テーブルを用意し、列の追加が行われたブロックは新規のロケーション・テーブルによって管理されるようにする。既存のデータベースに対して、順次、レコードを読み出し、列の追加を行った後、そのレコードを再度ブロックに格納する。そのブロックのアドレスを新規ロケーション・テーブルに書く。この方法の場合、既存のデータベース上で、新たな列が追加されたレコードが格納されているブロックと、追加されていないレコードが格納されているブロックが混在することになるため、それらを分離するために、列操作ポインターを使用する。更に、列操作完了ポインターを用いて、列追加の完了点を定める。また、列操作ポインターは、各ロケーション・テーブルの列追加が終了している最終ブロックを指しているエントリーの次のアドレスを指すようにする。列操作ポインターは、既存と新規の各ロケーション・テーブルに対して、一つづつ保持する。

上記の子データベース方式を使用した場合には、「データベース再編成システム」を使用して再編成を行うときに、別々に分かれている２つのデータベースを一つにまとめることが可能である。データベースが２つに分かれている場合は、作成時の負荷が軽いと言う利点があるが、データベースが２つに分かれているため、追加されたデータベースにも、ロケーション・テーブルや主キーを持たなければならず、その分だけデータベースが大きくなる。また、一つのレコードを検索するために２つのデータベースをアクセスする必要があり、その分だけ、システムの負荷が増加する。しかしながら、レコード全体を対象にするアクセスが少なく、項目を指定したアクセスが多くて、尚且つ、追加した項目を使用するアプリケーションが少ない場合には、効率的な場合もあるので、使用状況に応じた使い分けが必要である。

列の削除も、列の追加と同様に、大きく分けると、過去保持型と過去非保持型の２つになる。過去保持型は、更に、定義削除方式と子データベース方式に分かれる。過去非保持型は直接列削除方式のみである。定義削除方式は、削除する列を定義上で削除し、実際の削除は行わずにおく方法である。この方法を用いると、削除はデータベースの定義変更だけで済むので、極短時間で作業が完了する。レコードの読み出しは、実際にデータベース上に書かれているレコード長で行うが、アプリケーション・プログラムにレコードを渡す際に、削除されている列をレコードから削除して渡すことになる。一方、古いデータベース定義体を使用しているアプリケーション・プログラムにレコードを渡す場合には、削除された列を含んだレコードとすることが可能となる。

列の追加・削除以外に、列の変更がある。列変更は列追加と同様に、過去遡及型と過去非遡及型となる。

子データベース方式は、「データベース再編成システム」を使用して再編成を行う方法と同様の方法を用いて実施するが、レコードから列を削除して、列削除後のレコードを書き戻す。更に、削除項目と元のデータベースの主キーとを組み合わせて、新しいレコードを作製し、そのレコードを子データベースに書き込む方法である。この方法は、列削除時に新たなデータベースを作成するため、列削除の時間が余分に掛かるというデメリットがあるが、万一、削除項目を使用しているアプリケーション・プログラムが存在した場合に、そのプログラムの稼動ができなくなる、という事態を回避することができる。子データベース方式の場合も定義削除方式と同様に、古いデータベース定義体を使用しているアプリケーション・プログラムにレコードを渡す場合には、削除された列を含んだレコードとすることが可能となる。

過去非保持型は、削除前のレコードから、削除対象列を削除して、短くなった削除後のレコードを、データベースに書き戻す方法である。この方法は、「データベース再編成システム」を使用して再編成を行う方法と同様の方法を用いることにより、実現可能となる。現用のロケーション・テーブルに対して新規ロケーション・テーブルを使用し、列削除後のレコードが格納されているブロックのアドレスは、新規ロケーション・テーブルによって保持される。どのレコードまで、列削除を行ったかを区分するために、現用と新規のロケーション・テーブルに対して、１つづつ、列操作ポインターを使用する。この方式の場合は、削除された項目を使用しているアプリケーション・プログラムがあると、そのアプリケーション・プログラムに問題が発生する可能性があるため、注意が必要である。

次に、列の変更の場合に関して述べる。列の変更は、属性と長さに関するものである。これを分類すると、その列の属性の変更で長さの変更が無い場合、列の属性の変更が無く長さが変更になる場合、列の属性と長さの両方が変更になる場合の３つになる。属性とは、その列に格納されている情報の型のことで、数値であるとか、文字、日付などといった属性がある。

まず、列の属性の変更に関して説明する。何れも、列追加：直接追加方式と同様の方法を用いる。また、列の属性変更を既存のレコードにまで適用するのか否かで方法が分かれる。既存のレコードの変更列の属性を変更する場合には、列追加の過去遡及型と同じように、既存のレコードの変更列の属性を変更する。これを、列変更：過去遡及型と呼ぶ。これに対して既存のレコードの変更列の属性は以前のままとし、新たなデータベース定義体を用いて作成するレコードの変更列の属性を変更する方法を、列変更：過去非遡及型と呼ぶ。

列変更：過去遡及型の場合は、現用ロケーション・テーブルに対して、新規ロケーション・テーブルを設け、再編成を実施しながら、既存のレコードの変更列を変更していく。列変更：過去遡及型の場合は、列追加：過去遡及型と同様に、レコードの形式は最新のデータベース定義体バージョンのみとすることが好ましい。この場合は、データベース定義体は最新のバージョンのみを保有することになる。一方で、古いデータベース定義体を使用したアプリケーション・プログラムにレコードを渡すために、論理構造変換テーブルを使用する。

列変更：過去非遡及型の場合は、既存のレコードに対する変更を行わないので、既存のレコードに対する操作は不要である。新たに作成されるレコードは、最新バージョンのデータベース定義体を用いたものだけでなく、既存の古いデータベース定義体バージョンを用いたレコードも追加される。また、既存のレコードは、作成された時点の形式のままであるので、データベース定義体は各バージョンを保有することになる。この場合も、論理構造変換テーブルを使用する。

次に列の長さの変更に関して説明する。列の長さを変更する方法も、過去遡及型と過去非遡及型を選択する事が可能である。過去遡及型とは、既存のレコードの変更列の長さを新しいデータベース定義体の長さに合わせるように変更する方法である。この場合の、既存のレコードに対する変更は、列追加：過去遡及型で述べた方法と同様である。過去非遡及型の場合には、既存のレコードに対しては変更を行わず、新たに作成されるレコードで、最新のデータベース定義体を用いて作成されるレコードの変更列の長さが変更されることになる。

この場合も、論理構造変換テーブルを用いることで、レコードのバージョンとアプリケーション・プログラムのバージョンが異なっても、レコードの受け渡しが可能であるが、列の長さを変更した場合、情報の桁あふれや切り捨ての可能性があるため、適用する場合には、運用上の問題が発生しないことを確認することが必要である。

データベース定義体に関しては、次の様になる。最初のデータベース定義体は、システム管理者が人手で作成する。これをバージョン１（Ｖ１）とする。これに対して、例えば、列の追加を行う場合に、追加後のデータベース定義体をＶ２とする。このＶ２は、Ｖ１に対して、どの列をどの位置に追加するか、また、追加の方法は、子データベース方式か、直接追加方式か、といったことを、システム管理者が、データベース・システムに対して指定する。この指定に基づき、データベース・システムでは、Ｖ１の情報と合成することにより、Ｖ２を作成する。各バージョンのデータベース定義体とは、そのバージョンの物理情報と論理情報を組み合わせたものである。

その後、Ｖ２の定義を元に、必要があれば新Ｖ１の定義を作成する。必要になる場合は、例えば、Ｖ１で子データベース方式の形式であったものが、Ｖ２で再編成により一つのデータベースになった場合など、物理構造が変化したが、論理構造は変わらない場合である。

次に、Ｖ１とＶ２の論理構造変換テーブルを作成する。これは、Ｖ１の各列とＶ２の各列がどのように対応しているかを示すものである。論理構造変換テーブルは、各バージョンのデータベース定義体の論理構造を抜き出し、列が横に並ぶようにしたものである。この論理構造変換テーブルによって、各バージョン間の論理構造の変換が行える。図５４が論理構造変換テーブルの例である。

列の追加・削除・変更により、データベースの或るテーブルのレコードの物理構造や論理構造が変更された場合に、旧来のバージョンのデータベース定義体を用いて稼動していたアプリケーション・プログラムを、変更することなく利用することが可能であることに関して説明を行う。ここでは、データベース定義体のバージョンが、Ｖ１、Ｖ２、Ｖ３、Ｖ４の４つの場合を例にとって説明するが、バージョンの数が幾つであっても実施可能である。本明細書では、方法についての説明が多くなるが、この方法を用いてシステムを構築することにより、データベース・システムとすることができる。本明細書と図面では、多くの個所で、列の属性に関しての説明を省略している。これは、列の属性変更以外ではあまり意味を持たないからである。

［複数バージョンのアプリケーション・プログラムからのアクセス］
図４６は、過去非遡及型のＲＥＡＤ処理に関する図である。また、図５０は過去遡及型のＲＥＡＤ処理に関する図である。ここでは、列追加の場合を例にとって、過去遡及型と過去非遡及型の説明を行う。過去非遡及型とは、既に作成されたレコードに対して、新たに追加する列を反映させない（遡及させない）ものである。つまり、過去のレコードは、そのレコードが作成された形式のままである。新たに作成されるレコードは、列の追加を行ったデータベース定義体を使用しているアプリケーション・プログラムからは、追加列を含んだ形式のレコードが追加され、以前のバージョンのアプリケーション・プログラムからは、追加列を含まない形式のレコードが追加されることになる。つまり、異なる形式のレコードが混在することになる。

これに対して、過去遡及型とは、既に作成されたレコードに対して、新たに追加する列の値を用意し、それを既存のレコードに適用して、データベース上のすべてのレコードが追加列を含んだ形式のレコードとする。また、新たに作成されるレコードは、追加列が含まれた形式のレコードのみとする。過去遡及型の場合には、以前のバージョンのデータベース定義体を使用しているアプリケーション・プログラムの内、レコードを追加するものは、追加列に関する情報を持っていないため、その列の値に関しては初期値かヌル値、または情報を持たない列をセットすることが好ましい。または、最新以外のデータベース定義体を使用しているアプリケーション・プログラムの内、レコードを追加するものを稼動させないようにするとしてもよい。

本発明では、データベースに格納されているレコードに、そのレコードが作成されたデータベース定義体のバージョン情報を保持すること、複数バージョンのデータベース定義体を保有すること、各バージョンの論理構造を変換すること、アプリケーション・プログラムにどのバージョンのデータベース定義体を使用しているかの情報（アプリケーション・プログラムのバージョン情報）を保有すること、および、複数のバージョンの振分けを行うことにより、実現できるものである。

データベース・システムでは、一般的にサブスキーマとスキーマという表現が用いられるが、本明細書では、特にそのような用語を用いずにデータベースという用語を用いて説明を行う。本明細書の説明で「データベースに対する列追加」や「データベースに対するアクセス」というような表現は、特定の種類のデータベース・ファイル（例えば、従業員ファイル）に対する操作を表しており、データベース・システムに格納されているデータベース・ファイル全体に対するものでは無い。また、特定の種類のデータベース・ファイルが、複数のデータベース・ファイルから構成されている場合、例えば、従業員マスターで、新たに追加された列の出身地が別のデータベース・ファイルに格納されているが、レコードとしては一つのセットとして扱われる場合、には、各々のデータベース・ファイルに対してもデータベースという表現を使用している。

［過去非遡及型］
［過去非遡及型：ＲＥＡＤ］
図４６では、過去非遡及型のＲＥＡＤ処理（読み出し処理：ＳＱＬでは、多くの場合ＳＥＬＥＣＴ）を図示している。アプリケーション・プログラム３０からＲＥＡＤ命令をデータベース・システムに指示する。データベース・システムでは、リクエスト受け処理３１を行う。ＳＱＬの解析、データベースの種別（どのデータベース・ファイルに対するアクセスか）、アプリケーション・プログラムのデータベース定義体とそのバージョンの確認、アクセス種別（この場合はＲＥＡＤ処理）、キー種別（主キーか代替キーか、代替キーの場合はどの代替キーか）、そのキー値（ターゲット・キー値）、キー条件（ターゲット・キー値と等しい、大きい、小さいなど）が間違いないかの確認である。その後、インデックス検索処理３２を行い、目的のレコードが格納されている位置を検出する。ここまでは、従来のデータベース・システムと同様である。データ（レコード）が格納されている部分（データ格納部）３３から目的のレコードを見つける。そのレコード内またはレコード外の特定の場所には、そのレコードが作成された時のデータベース定義体のバージョン情報（レコード・バージョン情報）を予め格納しておくものとする。このレコード・バージョン情報は、データベースを作成する時点で行い、その後、アプリケーション・プログラムからレコードを追加・変更する都度、格納するものとする。図１７が、レコード形式の例である。ここでは、レコード長、データベース定義体バージョン情報の他に、列の値が並んでいる。図１８は、レコード外の特定の場所にデータベース定義体バージョン情報を持つ場合の例である。

読み出したレコードのデータベース定義体のバージョン情報に合致するバージョンのデータベース定義体の物理構造に基づいて、レコードが格納されているブロック等（データベース・システムによって名称が異なる）から、レコードを読み出す。物理構造によっては、複数のデータベースに１つの論理レコードが分散している場合もあるが、その場合は、必要な複数のデータベースを読む。そして、読み出したレコードを、そのバージョンの論理構造に変換する。その後、論理構造変換テーブルを用いて、アプリケーション・プログラムのデータベース定義体のバージョンに変換を行う。変換されたレコードをアプリケーション・プログラムに渡す。このように、格納されているレコードが作成されたデータベース定義体のバージョンと、読み出す側のアプリケーション・プログラムが使用しているデータベース定義体のバージョン情報に関係なく、レコードを読むことが可能となる。図４６では、データベース定義体と論理構造変換テーブルを分離して表現しているが、各データベース定義体に論理構造変換テーブルを持たせるような形式を採っても、同様に実現可能である。これは、以下の説明でも同様である。図４６のデータベース定義体は、レコードの物理構造と論理構造の変換を行うロジックを含むように図示してある。このようにデータベース定義体の内部に、論理構造変換用のロジックを含むような構成とすることも可能であるし、データベース定義体は純粋な定義のみを記述し、論理構造変換を行うロジックはデータベース定義体とは別な物として構成することも可能である。この説明は、図４６から図５３までに関する説明においても同様である。

［過去非遡及型：ＲＥＷＲＩＴＥ］
次に図４７に関して説明する。これは、過去非遡及型のＲＥＷＲＩＴＥ（更新処理。多くのＳＱＬでは、ＵＰＤＡＴＥ）に関して図示したものである。ＲＥＷＩＴＥとは、一旦読込んだレコードに対し、更新を加えて書き戻す処理である。この図では、既にレコードの読込みと更新処理が終了しているものとする。アプリケーション・プログラム３０からＲＥＷＩＴＥの要求をデータベース・システム２に対して行う。データベース・システムでは、リクエスト受付処理３１を実行する。ここでは、ＳＱＬ解析、データベースの種別、アプリケーション・プログラムのデータベース定義体バージョンの確認、アクセス種別（ここではＲＥＷＲＩＴＥ）、レコード情報が間違いないかの確認を行う。次に、アプリケーション・プログラムのデータベース定義体バージョンによる振分け処理３７を行う。アプリケーション・プログラムのデータベース定義体がＶ１であれば、Ｖ１のデータベース定義体にレコード情報を割振る。データベース定義体では、レコードから、物理構造に変換する。次に、格納位置設定を行う。このレコードはＲＥＡＤ処理によって読込まれており、その時点から排他が行われていれば格納位置に変化が無いので、ＲＥＡＤ時の格納位置を設定する。ＲＥＡＤが排他されていない場合には、ＲＥＷＲＩＴＥを行うまでの間に、格納位置が変化している可能性があるため、格納位置の検索を行う。次に、そのレコードを格納するブロック内で、格納するレコードが以前に占めていたスペースと新たに必要となるスペースが異なる場合に、ブロック内で後続のレコードを移動する。更に、格納するレコードにバージョン情報設定を行う（３８）。その後、レコードの格納を行う。次に、代替キーに関して変更が生じた場合は、当該代替キーに関する変更を行う。

［過去非遡及型：ＤＥＬＥＴＥ］
図４８は、過去非遡及型のＤＥＬＥＴＥ処理を示したものである。ＲＥＷＲＩＴＥと似ている。ＤＥＬＥＴＥ処理の場合も、一旦、レコードを読込んだ上でＤＥＬＥＴＥすることが一般的であるが、いきなりキー値を与えてＤＥＬＥＴＥすることも可能である。リクエスト処理受付３１、データベースの種別、アプリケーション・プログラムのデータベース定義体バージョンによる振分け３７、各バージョンのデータベース定義体による物理構造変換は、ＲＥＷＲＩＴＥ処理と同様である。次に、格納位置設定または格納位置検索を行う。これも、ＲＥＷＲＩＴＥ処理と同様である。レコード削除の場合は、そのレコードが占めていたスペースが空くため、当該レコード以降のレコードの移動が必要となる。そして、レコードの削除を実施する。次に、代替キーがあれば、そのレコードに関する代替キー・エントリーの削除を行う。

［過去非遡及型：ＩＮＳＥＲＴ］
図４９は、過去非遡及型のＩＮＳＥＲＴ（レコードの追加）処理である。上記例と同様に、リクエスト受付処理を行う。ＩＮＳＥＲＴの場合は、レコード情報が必要となる。キーに関する情報はレコードに含まれるので、必要ない。データベース定義体バージョンによる振分けを行う。その後、データベース定義体により、論理構造と物理構造の変換を行う。次に格納位置を検索した上、当該レコードが格納されるブロックで、そのレコード以降のレコードを移動し、レコードの格納を行う。更に、代替キー・エントリーを追加する。

［論理構造変換部］
次に、論理構造を変換することに関して説明を行う。まず、論理構造変換部の一例として論理構造変換テーブルに関して説明を行う。図５４は、論理構造変換テーブルの例である。この論理構造変換テーブルでは、データベース定義のＶ１からＶ４までに関して、論理構造の変換を行えるように設定されている。一番左側にあるのが列名称である。その右に、データベース定義Ｖ１の論理構造が記述されている。列ａは、レコードのオフセット０バイトから８バイト、列ｂは存在せず、列ｃは、レコードのオフセット８バイトから１２バイト、列ｄはレコードのオフセット２０バイトから１４バイト、列ｅは、レコードのオフセット３４バイトから１６バイト、列ｆは、レコードのオフセット５０バイトから１８バイト、となっている。同様に、Ｖ２、Ｖ３、Ｖ４の論理構造が記述されている。Ｖ４の列ｅは列履歴が削除となっているが、これは、列削除がこのバージョンで行われたことを示している。また、オフセットと長さが括弧付きで表現されているが、これは、Ｖ４の論理レコード中には存在しないが、列ｅの値が過去データとして保存されていることを表している。レコードがＶ４で作成され、アプリケーション・プログラムがＶ４以外である場合に、アプリケーション・プログラムに列ｅの値を渡すために使用される。Ｖ４のアプリケーション・プログラムが要求元である場合には列ｅを含まないレコードを渡すことは当然のことである。列履歴は、その列が、そのデータベース定義体バージョンで作成されたり、削除されたりしたかの履歴情報となっている。この論理構造変換テーブルの一番左にある列は、そのデータベースに対する複数のデータベース定義体の各々が保有している列を「ＯＲ」条件で抜き出したものとなる。

この論理構造変換テーブルを用いて、論理構造の変換を行う例を説明する。まず、ＲＥＡＤ処理の場合に関して説明する。読込んだレコードのデータベース定義体バージョンがＶ１であったとする。また、アプリケーション・プログラム（要求元）のデータベース定義体バージョンがＶ３であったとする。この場合には、論理構造変換テーブルのＶ１からＶ３に列を渡していくことになる。列ａは、読込んだレコードのオフセット０バイトから８バイトであり、それを、Ｖ３用のレコードの、オフセット０バイトから８バイトにセットする。列ｂは、読込んだレコードには存在しないことが分かるので、Ｖ３用のレコードの列ｂ（オフセット８バイトから１０バイト）には、列ｂの初期値かヌル値、または情報を持たない列をセットする。列ｃは、読込んだレコードのオフセット８バイトから１２バイトであり、それを、Ｖ３用のレコードの、オフセット１８バイトから１２バイトにセットする。列ｄは、読込んだレコードのオフセット２０バイトから１４バイトであり、それを、Ｖ３用のレコードの、オフセット３０バイトから１４バイトにセットする。以下、列ｅ，ｆのセットを行う。これで、Ｖ３用のレコードが完成するので、アプリケーション・プログラムにそのレコードを渡す。

次に、読込んだレコードのデータベース定義体バージョンがＶ４であったとする。また、アプリケーション・プログラムのデータベース定義体バージョンがＶ２であったとする。この場合には、論理構造変換テーブルのＶ４からＶ２に列を渡していくことになる。列ａは、読込んだレコードのオフセット０バイトから８バイトであり、それを、Ｖ２用のレコードの、オフセット０バイトから８バイトにセットする。列ｂは、読込んだレコードのオフセット８から１０バイトを、Ｖ２用のレコードの、オフセット８バイトから１０バイトにセットする。列ｃは、読込んだレコードのオフセット１８バイトから１２バイトであり、それを、Ｖ２用のレコードの、オフセット１８バイトから１２バイトにセットする。列ｄは、読込んだレコードのオフセット３０バイトから１４バイトであり、それを、Ｖ２用のレコードの、オフセット３０バイトから１４バイトにセットする。列ｅは、Ｖ４の論理レコード上のオフセット６４バイトから１６バイトを、Ｖ２用のレコードの、オフセット４４バイトから１６バイトにセットする。列ｆは、読込んだレコードのオフセット４４バイトから２０バイトを、Ｖ２用のレコードの、オフセット６０バイトから２０バイトにセットする。これで、Ｖ２用のレコードが完成するので、アプリケーション・プログラムにそのレコードを渡す。

次に、ＲＥＷＲＩＴＥ、ＤＥＬＥＴＥ、ＩＮＳＥＲＴの場合は、論理構造変換テーブルを使用していないので、データベース定義体間の論理変換は行わない。単一のバージョン内で、論理構造と物理構造の変換を行うのみである。この論理構造変換テーブルは、新しいバージョンのデータベース定義体を作成する時に更新する。更新は、データベース・システムが自動的に行うことが可能である。

ここで、レコード、物理構造、論理構造に関して定義を行っておく。レコードとは、データベースに格納するデータの単位で、１つ以上の項目（列）の連なりである。本明細書では、それに加えて、そのレコードが作成・変更された時のデータベース定義体のバージョン情報を含むものとする。論理構造とは、１つ以上の列の連なりからなるレコードの構造である。列の順序、列の先頭位置、長さ、列の属性、列の履歴などの情報を含むが、最低限、列の先頭位置と長さ情報を含むものとする。物理構造とは、そのレコードがどのように格納されているかを示すものである。また、レコードに格納されている情報の内、データベース定義体のバージョン情報は、アプリケーション・プログラムに渡す必要の無いものであり、データベース・システムによって管理される。

［論理構造変換部：別の方式］
上記では、論理構造変換テーブルを用いて論理構造の変換を行うことについて説明を行った。しかしながら、論理構造を変換するには、このような論理構造変換テーブルを用いずに行うことも可能である。一つ目の方法は、バージョン間の論理変換を、プログラム・ロジックとして保持する方法である。図５５にその事例を図示する。この場合には、各バージョン間の論理構造変換をすべて１対１で記述すると、バージョンが多くなった場合には、その論理構造変換式の数が幾何級数的に多くなるので問題がある。中間的な形式に一旦変換して、その後、目的の形式に変換する方式とすることで、論理構造返還式の数を少なくすることが可能となる。二つ目の方法は、各バージョンのデータベース定義体にある論理構造同士を比較して、同じ列同士を移動する方法である。列の属性や長さが変更されている可能性もあるため、単純に列を移動するだけでなく、属性変更や長さの変更を行うことも必要な場合がある。この説明は、以降の論理構造変換テーブルに関する説明全体に適用するものである。

［過去遡及型］
次に過去遡及型に関して説明する。過去遡及型は、既に作成されたレコードに対して、新たに追加する列の値を用意し、それを既存のレコードに適用して、追加列が含まれたレコードとする。また、新たに作成されるレコードは、追加列が含まれたレコードのみとする。

［過去遡及型：ＲＥＡＤ］
図５０は、過去遡及型のＲＥＡＤ処理を図示している。アプリケーション・プログラム３０からＲＥＡＤ命令をデータベース・システムに指示する。データベース・システムでは、リクエスト受け処理３１を行う。その後、インデックス検索処理３２を行い、目的のレコードが格納されている位置を検出する。ここまでは、従来のデータベース・システムや過去非遡及型のＲＥＡＤと同様である。データ（レコード）が格納されている部分３３から目的のレコードを見つける。過去遡及型では、レコードのデータベース定義体のバージョン情報は最新のもの（この場合はＶ４）のみしか存在しないので、レコード内にデータベース定義体のバージョン情報を格納しておく必要は無い。

読み出したレコード・バージョン情報はＶ４なので、Ｖ４のデータベース定義体に、レコードを送る。ここで物理構造に基づいて、レコードが格納されているブロック等（データベース・システムによって名称が異なる）から、レコードを読み出す。物理構造によっては、複数のデータベースに１つのレコードが分散している場合もあるが、その場合は、必要な複数のデータベースを読む。そして、読み出したレコードを、そのバージョンの論理構造に変換する。その後、論理構造変換テーブルを用いて、アプリケーション・プログラムのデータベース定義体のバージョンに変換を行う。変換されたレコードをアプリケーション・プログラムに渡す。このように、格納されているレコードが作成されたデータベース定義体のバージョンと、読み出す側のアプリケーション・プログラムが使用しているデータベース定義体のバージョン情報に関係なく、レコードを読むことが可能となる。

新たに追加された列が、他のテーブルとジョインしている場合、従来のデータベースでは、必ずジョインが行われるが、上記で説明したデータベースでは、列追加が行われる前のアプリケーション・プログラムからアクセスした場合、その列をアプリケーション・プログラムには渡さないので、その追加された列に対応する値が存在しない場合であっても、アプリケーション・プログラムに悪影響が無い。

［過去遡及型：ＲＥＷＲＩＴＥ］
次に図５１に関して説明する。これは、過去遡及型のＲＥＷＲＩＴＥに関して図示したものである。アプリケーション・プログラム３０からＲＥＷＩＴＥの要求をデータベース・システム２に対して行う。データベース・システムでは、リクエスト受付処理３１を実行する。次に、論理構造変換テーブル３６を用いて、アプリケーション・プログラムのデータベース定義体バージョンの論理構造変換を行う。この場合、変換先の論理構造は最新のＶ４のみである。次に、Ｖ４のデータベース定義体３５により、論理構造から物理構造への変換を行う。次に、格納位置設定を行う。このレコードはＲＥＡＤ処理によって読込まれており、その時点から排他が行われていれば格納位置に変化が無いので、ＲＥＡＤ時の格納位置を設定する。ＲＥＡＤが排他されていない場合には、ＲＥＷＲＩＴＥを行うまでの間に、格納位置が変化している可能性があるため、格納位置の検索を行う。次に、そのレコードを格納するブロック内で、格納するレコードが以前に占めていたスペースと新たに必要となるスペースが異なる場合に、ブロック内で後続のレコードを移動する。更に、格納するレコードにバージョン情報設定３８を行う。その後、レコードの格納を行う。次に、代替キーに関して変更が生じた場合は、当該代替キーに関する変更３９を行う。

［過去遡及型：ＤＥＬＥＴＥ］
図５２は、過去遡及型のＤＥＬＥＴＥ処理を示したものである。ＲＥＷＲＩＴＥと似ている。ＤＥＬＥＴＥ処理の場合も、一旦、レコードを読込んだ上でＤＥＬＥＴＥすることが一般的であるが、いきなりキー値を与えてＤＥＬＥＴＥすることも可能である。リクエスト処理受付３１、論理構造変換テーブル３６による、各バージョンからＶ４への論理構造の変換を行い、Ｖ４のデータベース定義体による物理構造変換を行う。これらは、ＲＥＷＲＩＴＥ処理と同様である。次に、格納位置設定または格納位置検索を行う。これも、ＲＥＷＲＩＴＥ処理と同様である。レコード削除の場合は、そのレコードが占めていたスペースが空くため、当該レコード以降のレコードの移動が必要となる。そして、レコードの削除を実施する。次に、代替キーがあれば、そのレコードに関する代替キー・エントリーの削除を行う。

［過去遡及型：ＩＮＳＥＲＴ］
図５３は、過去遡及型のＩＮＳＥＲＴ（レコードの追加）処理である。上記例と同様に、リクエスト受付処理を行う。ＩＮＳＥＲＴの場合は、レコード情報が必要となる。キーに関する情報はレコードに含まれるので、必要ない。データベース定義体バージョンによる振分けを行う。その後、データベース定義体により、論理構造と物理構造の変換を行う。次に格納位置を検索した上、当該レコードが格納されるブロックで、そのレコード以降のレコードを移動し、レコードの格納を行う。更に、代替キー・エントリーを追加する。構造変換に関する方式は、過去非遡及型と同様である。

［特別なデータベース構造］
ところで、殆どのデータベース・システムでは、既存のレコードに列を追加するには、一旦、データベースを停止させないと実施できない。本発明者が発明した、「データベース検索格納方式（日本国特許第３３４５６２８、米国特許第６６５４８６８号参照）」、または、「データベース格納検索システム」にて発明されたデータベースを用いることで、データベースを停止させることなく稼動させたままで、既存のレコードに対して列の追加を行うことが可能である。

本発明者は、従来の階層型インデックスに代えてロケーション・テーブルと代替キー・テーブルという概念を導入し、インデックスの処理に伴う複雑な処理を簡素化し、テーブル自体の検索をバイナリー・サーチなどの手法を用いることにより、高速化と、メンテナンスの容易性を確保できるようにした「データ格納検索方式」を発明した。更に、「データベースの再編成システム、並びに、データベース（以下、「データベース再編成システム」と呼ぶ）特許出願ＰＣＴ／ＪＰ０３／１１５９２」では、「データ検索格納方式」で提案したデータベースに対して、データベースを稼動させながら再編成が行える仕組を提案した。更に、代替キー・テーブルに対して代替キー・ロケーション・テーブルを付加することにより、効率的な再編成が可能となることを発明している。
また、「データベースのアクセラレーター機能（以下、「アクセラレーター機能」と呼ぶ。特許出願ＰＣＴ／ＪＰ０３／１３４４３）」では、ロケーション・テーブルや代替キー・ロケーション・テーブルのコピーをアクセラレーター・システムが保持し、レコードを検索する際に、アクセラレーター・システムのロケーション・テーブルや代替キー・ロケーション・テーブルを使用することで、アクセスが並行処理できることを発明している。
また、「データ格納検索システム」では、プライマリー・ブロックからオーバーフロー・ブロック、オーバーフロー・ブロックからオーバーフロー・ブロックへの連結を、オーバーフロー・ブロック管理テーブルを用いて行う方式を発明している。「オーバーフロー・ブロック管理テーブル」では、代替キー・ブロックと代替キー・オーバーフロー・ブロックの連結、代替キー・オーバーフロー・ブロックと代替キー・オーバーフロー・ブロックの連結も同様に、代替キー・オーバーフロー・ブロック管理テーブルを用いて行う方式である。

［データ格納検索方式］
ここで、本発明者が提案した「データ格納検索方式」の内容について、図１を用いて簡単に説明しておくことにする。プライマリー・システム１は、「データ格納検索方式」を適用するシステムのうち、主となるものである。データ・レコードは、ブロック１１に主キーの順に格納する。ブロック１１は、プライマリー・ブロックとオーバーフロー・ブロックとからなるが、図１では、プライマリー・ブロックのみを図示してある。そのプライマリー・ブロックにデータ・レコードを追加する場合に、プライマリー・ブロックが満杯である場合に、オーバーフロー・ブロックを、そのプライマリー・ブロックに連結して、データ・レコードを格納する。オーバーフロー・ブロックに、更にオーバーフロー・ブロックを連結することが可能である。各プライマリー・ブロックのアドレスが記載されたロケーション・テーブル・レコード（または、ロケーション・テーブル・エントリー）を連続領域に有するロケーション・テーブルＬＣを有する。ロケーション・テーブルＬＣは連続した領域に予め確保する。ここで連続した領域とは、論理的な順序であり、物理的な領域では、離れていても良い。このような場合には、アドレス変換テーブルを用いて、論理的に連続していると扱うことができる。これは、以下の説明でも同様である。ロケーション・テーブルの使用領域の最後を示すために、最終ポインター１０１を用いる。

最後のプライマリー・ブロックにレコードが追加できない場合は、その後にプライマリー・ブロックを追加して、レコードの格納を行う。その追加したプライマリー・ブロックのアドレスを、ロケーション・テーブルＬＣに書き、最終ポインターの位置を１つ後方に動かす。

ここで、連結とは、物理的に連結されていることを意味するのではなく、プライマリー・ブロックが一番目のオーバーフロー・ブロックのアドレスを保持し、１番目のオーバーフロー・ブロックが２番目のオーバーフロー・ブロックのアドレスを保持している状態が、あたかも物理的にブロックが繋がれているように扱えることから、そのような表現を使用している（以下、同様である）。このように格納するので、ロケーション・テーブル・エントリーは、主キーの順番に並んでいる。主キーによる検索は、ロケーション・テーブルＬＣの最初のアドレスと最終ポインター１０１が指しているロケーション・テーブル・エントリーの間に対して、バイナリー・サーチを行うことにより、ブロックを見つけ、そのブロック内で目的のレコードを見つける。当該ブロックにオーバーフロー・ブロックが連結されている場合は、オーバーフロー・ブロックも検索の対象となる。ここでは、検索に関して述べているが、レコードの更新、追加、削除も同様のロジックで実現できる。

代替キーは、データベースにおけるノンユニークなキーのことで、例えば、従業員データベースにおける、氏名や生年月日などのことである。代替キーは、或る種類のデータベースに対して、無くても良いし、複数あっても構わない。図１では、代替キーが３つ存在する場合の例を図示している。代替キー値と主キー値からなる代替キー・レコード（または代替キー・エントリー）は、代替キー・ブロック（２２Ａ、２２Ｂ、２２Ｃ）に代替キー値の順番に格納する。その代替キー・ブロックに代替キー・エントリーを追加する場合に、その代替キー・ブロックが満杯である場合に、代替キー・オーバーフロー・ブロックを代替キー・ブロックに連結して、代替キー・エントリーを格納する。代替キー・オーバーフロー・ブロックに、更に代替キー・オーバーフロー・ブロックを連結することが可能である。図１では、代替キー・オーバーフロー・ブロックは省略してある。

各代替キー・ブロックのアドレスが記載された代替キー・ロケーション・テーブル・レコード（または、代替キー・ロケーション・テーブル・エントリー）を連続領域に有する代替キー・ロケーション・テーブル（ＡＡＬＣ、ＡＢＬＣ、ＡＣＬＣ）を有する。代替キー・ロケーション・テーブルは連続した領域に予め確保する。代替キー・ロケーション・テーブルの使用領域の最後を示すために、代替キー最終ポインター（２９Ａ、２９Ｂ、２９Ｃ）を用いる。代替キー・エントリーの追加で、既存の代替キー・エントリーの代替キー値より大きい代替キー値を持つ代替キー・エントリーは、最後の代替キー・ブロックに格納し、その代替キー・ブロックに格納できない場合には新たに代替キー・ブロックを作成し、その代替キー・ブロックに当該レコードを格納する。

代替キー・ロケーション・テーブルと代替キー・ブロックを組にして、代替キー・テーブル（２０Ａ、２０Ｂ、２０Ｃ）と呼ぶ。或る代替キーを持ったレコードを検索する方法は、代替キー・ロケーション・テーブルの最初のエントリーと、代替キー最終ポインター（２９Ａ、２９Ｂ、２９Ｃ）が指している代替キー・ロケーション・テーブル・エントリーの間をバイナリー・サーチし、目的の代替キー・ブロックを見つけ、その代替キー・ブロックの中を検索して、目的の代替キーを持つ代替キー・エントリーを見つける。その代替キー・ブロックに代替キー・オーバーフロー・ブロックが連結されている場合には、代替キー・オーバーフロー・ブロックも検索の対象となる。次に、その代替キー・エントリーの主キーによって、ロケーション・テーブルＬＣをバイナリー・サーチし、目的のブロックを見つけ、そのブロック内から目的のレコードを見つけ出す。当該ブロックにオーバーフロー・ブロックが連結されている場合は、オーバーフロー・ブロックも検索の対象となる。

尚、代替キーはノンユニークであるので、同一の代替キー値を持ったレコードが複数存在する可能性がある。この場合は、代替キー・ブロック中の次の代替キー・レコードが同一の代替キー値である場合には、上記と同様な動作を繰り返す。ここでは、検索に関して述べているが、レコードの更新、追加、削除も同様のロジックで実現できる。また、複数種類の代替キーが存在する場合には、代替キーの種類と同じ数の代替キー・テーブルを作成し、使用することになる。

［データベース再編成システム］
次に、「データベース再編成システム」に関して、図２を用いて説明する。「データベース再編成システム」は、「データ格納検索方式」で提案された、構造がシンプルな点を利用して、データベースを停止することなく、再編成を行う仕組を提案している。この「データベース再編成システム」について簡単に説明をする。再編成とは、オーバーフロー・ブロックの解消、適正な初期格納率の確保、フラグメンテーションの解消の３つを行うことである。オーバーフロー・ブロックの解消とは、次のようなことである。プライマリー・ブロックにオーバーフロー・ブロックが多数連結されると、それらのブロックに対してレコードを挿入しようとしたときに、プライマリー・ブロックとオーバーフロー・ブロックにまたがってレコードが主キー値の順に並んでいなければならないので、移動すべきレコードの数が多くなってしまう。レコードの検索をする場合でも、複数のブロックにまたがって検索を行わなければならないので、効率が低下してしまう。このようなことを避けるために、オーバーフロー・ブロックを無くして、プライマリー・ブロックにする。

適正な初期格納率の確保とは次のようなことである。ブロック内に予め適当な割合の空き空間を設けておくと、レコードの挿入が発生した場合でも、直ちにオーバーフロー・ブロックを追加することなくレコードの挿入が行える。ところがレコードの挿入が幾度も繰り返されると適正な初期格納率から外れた空き空間になってしまう。これを初期の状態に戻すものである。フラグメンテーションの解消は、適正な初期格納率の確保と似ているが、不要になったプライマリー・ブロックやオーバーフロー・ブロックを削ったり、格納率が少ないブロックは、統合するなどして、ブロックが均一に使用された状態にすることである。ここでは、プライマリー・ブロックとオーバーフロー・ブロックに関して述べたが、代替キー・ブロックと代替キー・オーバーフロー・ブロックに関しても全く同様である。

ロケーション・テーブルとブロックの再編成においては、ロケーション・テーブルを現用ＬＣと新規ＬＮの２つ用意する。更に、各々のロケーション・テーブルに対して、再編成がどこまで終了しているかを示すための再編成ポインターを、現用ロケーション・テーブルに対して１つＲＰＬＣと、新規ロケーション・テーブルに対して１つＲＰＬＮを設ける。図２では、オーバーフロー・ブロックの解消に関して図示している。現用ロケーション・テーブルＬＣが指しているブロック１１は、プライマリー・ブロック１２と、オーバーフロー・ブロック１３、１４からなる。現用ロケーション・テーブルＬＣの最初のブロックは、プライマリー・ブロック０のみからなるので、新規ロケーション・テーブルの最初のロケーション・テーブル・エントリーに書き移す。次に、プライマリー・ブロック１を見ると、オーバーフロー・ブロック１−２、１−３が連結されている。プライマリー・ブロック１を、新規ロケーション・テーブルＬＮのロケーション・テーブル・エントリー１に書き移す。次に、オーバーフロー・ブロック１−２の連結を切り離し、新規ロケーション・テーブルＬＮのエントリー２にオーバーフロー・ブロック１−２のアドレスを書き、プライマリー・ブロックとする。同様に、オーバーフロー・ブロック１−３も、新規ロケーション・テーブルＬＮのエントリー３にオーバーフロー・ブロック１−３のアドレスを書き、プライマリー・ブロックとする。

同様に、次々とオーバーフロー・ブロックの切り離しを行い、現用ロケーション・テーブルＬＣのエントリー３が管理していたブロック３までのオーバーフロー・ブロック解消が終了した時点を、図２は示している。現用ロケーション・テーブルの再編成ポインターＲＰＬＣは、現用ロケーション・テーブルＬＣのエントリー３の次のアドレスを指している。また、新規ロケーション・テーブルの再編成ポインターＲＰＬＮは、新規ロケーション・テーブルのエントリー６の次のアドレスを指している。

次に適正な初期格納率の確保と、フラグメンテーションの解消は、一時点で複数のブロックを対象にし、それらのプライマリー・ブロック、オーバーフロー・ブロック間で、適正な初期格納率になっていないブロック間でレコードの移動を行い、ブロック内に適正にレコードが格納されるようにするもので、状況によって、ブロックを削除したり、追加したりする。ここでは、プライマリー・ブロックとオーバーフロー・ブロックに関して述べたが、代替キー・ブロックと代替キー・オーバーフロー・ブロックに関しても全く同様である。

再編成中にデータベースをアクセスすることか可能である。まず検索に関して述べる。検索は、再編成ポインターＲＰＬＣが指しているエントリーが指しているブロックに格納されているレコードの主キー値が、目的の主キー値より大きいか小さいかの判定を行う。小さい場合には、新規のロケーション・テーブルＬＮを用いて、先頭と再編成ポインターＲＰＬＮが指している間に対してバイナリー・サーチを行うことにより、目的のレコードの検索を行う。大きいか等しい場合は、現用のロケーション・テーブルＬＣを用いて、再編成ポインターＲＰＬＣと最終ポインターＦＰが指している間に対してバイナリー・サーチを行うことにより、目的のレコードの検索を行う。ここでは検索の場合を説明したが、更新、追加、削除も同様に行える。

代替キー・テーブルにおける再編成やアクセスも、ロケーション・テーブルとブロックの場合と、ほぼ同様な方式で実行可能である。また、代替キー・テーブルに関して、代替キー・ロケーション・テーブルを保持する形式を新たに発明している。以上で、「データベース再編成システム」の説明を終了する。

［オーバーフロー・ブロック管理テーブルを用いた形式］
上記では、プライマリー・ブロックとオーバーフロー・ブロック、オーバーフロー・ブロックとオーバーフロー・ブロックの連結は、当該ブロックの直前のブロックが、当該ブロックのアドレスを保持するという形式であった。これに対して、「データ格納検索システム」では、プライマリー・ブロックとオーバーフロー・ブロック、オーバーフロー・ブロックとオーバーフロー・ブロックの連結に関して、図３６にあるように、オーバーフロー・ブロック管理テーブルを用いて行うものである。図３６の場合、ロケーション・テーブル・エントリー４が指しているプライマリー・ブロックには、３つのオーバーフロー・ブロックが連結されている。これらのアドレスをオーバーフロー・ブロック管理テーブルのエントリー１，２，４が保持している。このような形式を採った場合、ブロックやオーバーフロー・ブロックがロケーション・テーブルに比較して低速な記憶装置に格納されている場合に、オーバーフロー・ブロックを次々に読んでいく必要が無いため高速なアクセスが可能となる。

以上が、本発明に関連する、本発明者による既存の発明の概要である。「データ格納検索方式」または、「データ格納検索システム」を用いたデータベースに対して、列の追加・削除・変更をデータベースを停止せずに適用する場合の事例を説明する。特に、列追加：過去遡及型、列削除：過去非保持型を使用する場合に、データベースの稼動を継続したままで、既存のレコードに対する列追加、削除が可能であること、また、子データベース方式を用いた列追加を行った場合に、その後の再編成で、データベースを稼動させながら、複数のデータベースに分かれているレコードを一つにまとめることが可能であること、列削除でも削除列を子データベースとすることが可能であることなどを説明する。

図３は、本実施例で使用するデータベースの原型である。ここでは、プライマリー・ブロックとオーバーフロー・ブロック、オーバーフロー・ブロックとオーバーフロー・ブロックの連結、及び、代替キー・ブロックと代替キー・オーバーフロー・ブロック、代替キー・オーバーフロー・ブロックと代替キー・オーバーフロー・ブロックの連結に関しては、「データ格納検索方式」で示された方法によっている場合の説明とする。ここでは、ロケーション・テーブル１０とブロック１１を示している。ブロック中には、レコードがｒｅｃｏｒｄ０からｒｅｃｏｒｄ６までの７つのレコードが格納されている。各レコードは、ａ，ｃ，ｄ，ｅ，ｆの５つの項目（列）を持っている。このレコードを格納・検索する方法としては、「データ格納検索方式」で述べている方式によるものである。ここでは代替キー・テーブルは省略してある。図４は、図３に示した原型データベースのデータベース定義体である。データベース定義体には、データベースの物理的な構成情報、ブロックの大きさ、適正な初期格納率、データの型などの様々な情報が付属することになるが、本図では、本発明に必要な情報に絞って記載している。データベース定義体とは、データベース定義情報をデータ化したものである。

列の追加に関して説明を行う。列の追加は、大別すると過去遡及型と過去非遡及型の２つの方法となる。また、各々の型は、子データベース追加方式と直接追加方式の２つに分かれるため、全体として４つの実現方式が存在する。

［列の追加］
［過去遡及型］
過去遡及型は、列の追加を行う際に、既に作成されたレコードに対して、追加する列の値を予め用意し、それらの値を既存のレコードに追加していくものである。このようにすることによって、既存のレコードも追加列の値を保有することになる方式である。

［列の追加：過去遡及型・子（Ｓｕｂｓｉｄａｒｙ）データベース方式］
図５、図６を用いて、図３のデータベースに、新たに列（項目）ｂを追加する場合を説明する。ここで説明する方式は、追加する列を子データベースとして作成する方法である。この方式を、過去遡及型・子データベース方式と呼ぶ。まず、過去遡及型・子データベース方式で列ｂを、列ａの直後に追加することを、システム管理者がデータベース・システムに指令する。指令する方法は、画面を用いて対話型に行う方法が好ましい。データベース・システムでは、列ｂが追加された後のデータベースの定義体Ｖ２（図６のＤ２とＤ２１）を作成する。図６では、定義体クロス・リファレンス・テーブルＸ６が、併せて記述してある。データベース定義体Ｖ２と定義体クロス・リファレンス・テーブルの作成方法に関しては後ほど説明する。図６のＤ２１ではＤＢ＿Ａに対して、ＤＢ＿Ａ１が別のデータベースとして追加されている。ＤＢ＿Ａを親データベース、ＤＢ＿Ａ１を子データベースとする。図６では、Ｖ１も併せて記載してあるが、過去遡及型では基本的に最新のデータベース定義体のみがあれば、それより前のバージョンのデータベース定義体は不要である。次に、ＤＢ＿Ａ１用の子ロケーション・テーブル１５を作成する。最終ポインター１５１を用意し、子ロケーション・テーブル１５の先頭を指すようにする。ＤＢ＿Ａ１用の子ブロック１６は、レコードを格納する都度確保していってもよいが、予め必要な数のブロックを確保しても良い。以上が準備作業となる。ＤＢ＿Ａ１では、列ｂが実際の意味を持っているが、列ｂだけでは検索や更新が出来ないので、ＤＢ＿Ａの主キーの列ａと組み合わせてレコードとし、ブロック中１６に格納する。

次に、列ｂの追加を行う。これは過去遡及型であるので、列ｂの内容に関するデータは予め用意し、これらのデータベースの外部にあるとする。まず、ｒｅｃｏｒｄ０の列ｂを追加する場合について説明する。ｒｅｃｏｒｄ０を読み、レコードが存在することを確認したら、ＤＢ＿Ａ１の最初の子ロケーション・テーブル１５のエントリー（子ロケーション・テーブル・エントリー）を排他し、ｒｅｃｏｒｄ０の主キーとｒｅｃｏｒｄ０用の列ｂ（実際にはデータベースの外にあるデータ）とを組み合わせて、子レコードｒｅｃｏｒｄ０１を作成し、子ブロック０（１６０）にｒｅｃｏｒｄ０１を書き込む。次に、ｒｅｃｏｒｄ１の列ｂを追加する場合について説明する。この場合は、ｒｅｃｏｒｄ０１と同じブロックに格納するとする。同様に、ｒｅｃｏｒｄ１を読み込み、ｒｅｃｏｒｄ１の主キーとｒｅｃｏｒｄ１の列ｂとを組み合わせて、子レコードｒｅｃｏｒｄ１１を作成し、ＤＢ＿Ａ１の子ブロック０（１６０）に格納する。同様にｒｅｃｏｒｄ２１をＤＢ＿Ａ１の子ブロック０（１６０）に格納する。ここで、ブロック０の適正な初期格納率になったので、ロケーション・テーブルのエントリー０の排他を解除する。上記の説明ではＤＢ＿Ａのレコードを読み込むことになっているが、これは列追加時に、ＤＢ＿Ａ上で、当該レコードが既に削除されていないかを確認するためである。

ＤＢ＿ＡとＤＢ＿Ａ１の双方のロケーション・テーブルにＦＰと記した矢印が１つずつあるが、これは、各々のロケーション・テーブルがどこまで使用されているかを示す、最終ポインター（１０１と１５１）である。最終ポインターの他に、どのレコードまで列ｂの追加がされているかを示すために、列操作ポインター１０２を用いて、列ｂが追加されているレコードが格納されているブロックを指し示すようにすると、データ・アクセスの効率化に対して有効である。列操作ポインターを用いる場合には、ＤＢ＿Ａのブロック単位に列追加を行うことが好ましい。図５では、ｒｅｃｏｒｄ２までの列追加が完了しているが、ブロック単位では、ブロック０（１１０）までなので、列操作ポインター１０２はブロック０の直後を指している。
しかしながら、列操作ポインターを使用しなくとも、ＤＢ＿Ａ１にレコードが存在していない場合は、列ｂの追加が未完であると判断することも可能である。

図７は、このようにしてｒｅｃｏｒｄ６まで、列ｂの追加が行われ、列追加が完了した状態を示している。列追加の完了は、追加列用のデータのエンドを検出した時点とすることが、最も単純である。列追加が完了すると、列操作ポインターは最終ポインター１０１と同じ位置を指すことになるので不要となる。よって、図７では図示していない。

以上では、代替キーに関する説明を省略しているが、代替キーに関しては、次のようになる。まず、列ｂを追加する以前から存在した代替キーに関しては、ＤＢ＿Ａに付帯するものとして扱う。また、列ｂを追加することによって影響を受けないので、操作をする必要が無い。次に、列ｂが代替キーの対象となる場合は、最初の準備段階で、ＤＢ＿Ａ１に対して列ｂが代替キーであることを通知する。次にＤＢ＿Ａ１で、空の列ｂ用の代替キー・テーブルを作成する。次に、ｒｅｃｏｒｄ０１，ｒｅｃｏｒｄ１１等を作成するのと並行して、列ｂと列ａからなる代替キー・エントリーを作成し、代替キー・ブロックに格納する。この場合は、列ｂ用の代替キー・テーブルを、ＤＢ＿Ａの中に作成することも可能であるし、ＤＢ＿Ａ１の中に作成することも可能である。

［列追加完了後のレコード追加］
次に、列追加が完了した後で、レコードの追加を行う場合に関して、図８を用いて説明する。過去遡及型で新たに作成されるレコードは、追加列が含まれたレコードのみとすることが好ましい。過去遡及型の場合には、以前のバージョンのデータベース定義体を使用しているアプリケーション・プログラムの内、レコードを追加するものは、追加列に関する情報を持っていないため、その列の値に関しては初期値かヌル値、または情報を持たない列をセットすることが好ましい。または、最新以外のデータベース定義体を使用しているアプリケーション・プログラムの内、レコードを追加するものを稼動させないようにするとしてもよい。

図８と図５３を用いて説明する。アプリケーション・プログラムから、レコードを追加する場合は、次のようになる。ｒｅｃｏｒｄ７を追加する。図８は、ｒｅｃｏｒｄ７の追加が終了した時点の図である。過去遡及型の場合、最新バージョンのデータベース定義体を使用していないアプリケーション・プログラムは稼動させない、という方法があるが、この方法は、従来から存在する方法なので目新しいことはない。ここでは、特に最新以外のバージョンのデータベース定義体を使用しているアプリケーション・プログラムからのレコード追加の場合に関して説明する。

図５３は、データベース定義体がＶ４まである図であるが、この図の、論理構造変換テーブル３６が、Ｖ１とＶ２の２つであり、最新のデータベース定義体３５がＶ２用であるとする。アプリケーション・プログラムがＶ２のデータベース定義体を使用したものである場合には、論理構造の変換は不要であるので、通常のレコード追加と同じである。アプリケーション・プログラムがＶ１のデータベース定義体を使用している場合に関して説明する。まず、アプリケーション・プログラムからの処理要求を、リクエスト受付処理を行う。次に、論理構造変換テーブル３６を使用して、Ｖ１の論理構造をＶ２の論理構造に変換する。論理構造変換テーブル３５の具体的な形式は、図６のＸ６に示してある。Ｖ１の列ａ（オフセット０バイトから８バイト）は、Ｖ２のオフセット０バイトから８バイトにセットする。列ｂは、Ｖ１では保持していないので、Ｖ２の列ｂ（ＤＢ＿Ａ１のオフセット８バイトから１０バイト）には、列ｂの初期値かヌル値、または情報を持たない列をセットする。Ｖ１の列ｃ（オフセット８バイトから１２バイト）は、Ｖ２のオフセット８バイトから１２バイトにセットする。以下、列ｄ，ｅ，ｆも同様にセットする。この後、Ｖ２のデータベース定義体（図５３の３５）を用いて論理構造を物理構造に変換する。Ｖ２のデータベース定義体の詳細は、図６のＤ２、Ｄ２１に図示してある。Ｖ２では、子データベース方式を用いて列ｂの追加を行ったため、ＤＢ＿ＡとＤＢ＿Ａ１を連結している。親データベースは論理構造変換テーブルでセットされたレコードをＤＢ＿Ａに格納すればよいが、ＤＢ＿Ａ１は、ＤＢ＿Ａの主キー値をオフセット０バイトから８バイトにセットしてから格納する。

上記では、データベース定義体のバージョンが２つの場合に関して説明したが、図５３に図示したように、データベース定義体の各バージョン間の論理構造変換を行うことにより、バージョンが幾つ存在しても、実施可能である。また、論理構造変換テーブルを用いずに論理構造の変換を行う方法が別途存在することは、前述したとおりである。

［過去遡及型・子データベース方式で列を追加中のデータベースへのアクセス］
次に、このような列追加を行っている最中に、レコードに対するアクセスが可能であることを説明する。基本的な仕組は、図５０から図５３を用いて複数バージョンのデータベース定義体を使用している別々のアプリケーション・プログラムからのアクセスが可能である、という説明にあるとおりである。図５が、列追加の途中の状態を示しているので、この図を用いて説明を行う。併せて、図６も使用する。最新のデータベース定義体Ｖ２を使用するアプリケーション・プログラムが、データベースに対してアクセス可能であることは勿論、それに加えて、データベース定義体の各バージョンと論理構造変換テーブルを保持することにより、データベース定義体Ｖ１を使用していたアプリケーション・プログラムと、データベース定義体Ｖ２を使用するアプリケーション・プログラムの双方が、同じデータベースに対して、アクセス可能であることも説明する。

アプリケーション・プログラムが、どのバージョンのデータベース定義体を使用しているかについては、アプリケーション・プログラムで指定する必要がある。これは、アプリケーション・プログラム内にコーディングしておくのが、最も単純な方法である。この場合には、使用するデータベース定義体のバージョンを変える場合に、アプリケーション・プログラムの変更が必要になる。他の方法としては、データベース定義体のバージョンをアプリケーション・プログラムに対して外部情報（例えば、パラメーターなど）として与えるようにすることで、バージョンの変更に伴うアプリケーション・プログラムの変更を少なくすることも可能である。これは、他の列追加や列削除、列更新に関する説明に共通である。この他に、アプリケーション・プログラムの作成日を見て、データベース・システムが自動的に、どのバージョンのデータベース定義体を使用しているか判定する方法も可能である。この場合は、各バージョンのデータベース定義体の作成日とアプリケーション・プログラム作成日を比較すれば、簡単に判別することが可能である。

レコードのアクセスに関する説明を行う前に、データベース定義体の列状況欄に関しての説明を、図６のデータベース定義体のＶ２（Ｄ２とＤ２１）を使用して行う。列状況欄とは、その列の履歴と、その時点の状況を示すためのものである。列ｂの列状況欄は、「ＤＢ＿Ａ１と連結」という説明になっている。これは、列ｂが、論理的にはＤＢ＿Ａの中の列となっているが、物理的には列ａの直後に列ｂが存在せず、論理的に連結されていることを示している。また、同様にＶ２のＤＢ＿Ａ１のデータベース定義体Ｄ２１の列ｂの列状況欄は、「ＤＢ＿Ａ」から連結」となっている。これは、列ｂの実体は、ＤＢ＿Ａ１に存在するが、論理的には、ＤＢ＿Ａの一部として存在していることを示している。列状況欄の使用方法は、これ以下の明細書の別項中で、多様な使用ができることを、更に詳細に説明する。

ここから、列を追加中のデータベースに対して、図５を用いてアクセスが可能であることを説明する。要求元がアプリケーション・プログラムであるとする。また、アクセスが主キーに対してであり、その主キー値がａ１である場合であるとする。まず、リクエスト受付処理を行う。その間で要求元がデータベース定義のＶ１を使用しているかＶ２を使用しているかの判定を行う。次に、インデックス検索処理を行う。ＤＢ＿Ａのロケーション・テーブル１０に対して、バイナリー・サーチを行い、ブロック０の中のｒｅｃｏｒｄ１を見つけ出す。データベース定義体のＶ２を用いて、ｒｅｃｏｒｄ１の物理構造をＶ２の論理レコードに変換する。次に、アプリケーション・プログラムがデータベース定義体Ｖ１を使用している場合は、論理構造変換テーブルを用いてＶ２の論理形式からＶ１の論理形式に変換する。構造変換の方法に関しては、図５４を用いて説明したとおりである。変換後のレコードを要求元に渡す。要求元がデータベース定義体Ｖ２を使用している場合は、論理構造の変換が不要であるので、データベース定義体によって作成されたレコードを要求元に渡す。

次に、アクセスが主キーであり、主キー値がａ３である場合に関して述べる。前記例と同様に、要求元がどのデータベース定義体を使用しているかを判定する。次に、ＤＢ＿Ａのロケーション・テーブルに対して、バイナリー・サーチを行い、ブロック１１１の中のｒｅｃｏｒｄ３を見つけ出す。列操作ポインター１０２を使用している場合は、列操作ポインターが指しているブロックよりも、目的の主キー値が大きいので、列追加が終了していないブロックに対するアクセスであることが分かるので、ＤＢ＿Ａ１に対するアクセスを行う必要がない。列操作ポインターを使用していない場合は、ＤＢ＿Ａ１の子ロケーション・テーブルに対してバイナリー・サーチを行い、ｒｅｃｏｒｄ３１が無いので、まだ、列ｂが追加されていないレコードであると判断できる。このように、列操作ポインターを用いると列追加中のアクセスが効率的に実行できる。

要求元がデータベース定義のＶ１を使用している場合には、主キー値がａ１の場合と同様に、論理構造変換テーブルを使用してＶ２からＶ１に論理形式の変換を行い、変換後のレコードを要求元に渡す。要求元がデータベース定義体Ｖ２を使用している場合は、論理構造の変換が不要であるので、データベース定義体によって作成されたレコードを要求元に渡す。

代替キーでのアクセスは、目的の代替キー値により、代替キー・ロケーション・テーブルのバイナリー・サーチを行い、代替キー・ブロックまたは代替キー・オーバーフロー・ブロックから、目的の代替キー値を持つ代替キー・エントリーを捜し、その代替キー・エントリーの主キー値により、ロケーション・テーブルに対して主キーによるバイナリー・サーチを行い、目的のレコードを検索すればよい。代替キーは、同一のキー値を持つレコードが複数存在する場合があり、その場合には、上記の動作を繰り返す。

上記では、ＲＥＡＤ処理（検索）の場合を説明したが、図５１、６６、６７を用いて説明したように、レコードの更新、削除、追加が可能である。以下の説明でも、アクセスが可能であるという説明は、検索の場合を用いて説明してあるが、この場合と全く同様に、レコードの更新、削除、追加が可能である。レコードの更新は、検索で見つかったレコードを更新すればよいし、削除は検索で見つかったレコードを削除すればよい。追加の場合は、まず、検索でレコードを格納する場所を見つけて、そこにレコードの格納を行う。必要に応じて、論理構造変換テーブルを用いてレコード形式の変換を行う。

レコードの追加を、データベース定義体Ｖ１を使用したアプリケーション・プログラムから実行することは、過去遡及型を用いている場合には好ましくない。何故ならば、列追加が完了した後に、列ｂを持たないレコードが発生してしまうからである。しかしながら、データベース定義体Ｖ１を使用しているアプリケーション・プログラムでレコードの追加を行いたい場合には、アプリケーション・プログラムからは列ｂの無いレコードを書く形になるため、データベース・システムでは、列ｂに関しては、初期値かヌル値、または情報を持たない列として実体データベースを作成することが好ましい。

［子データベース方式で列を追加完了後のデータベースへのアクセス］
上記では、列を追加中のデータベースへのアクセスに関して説明を行ったが、前記の方法を応用すれば、列追加を完了した時点での、データベースへのアクセスが問題なく行える。列追加中との相違は、列追加完了後のアクセスでは、データベース定義体Ｖ２からの検索で列ｂの追加が完了していない、という状態が発生しないことである。

以上で、列追加・子データベース方式における、列の追加と、追加途中および追加後のレコードの検索に関して述べた。ここでは、既存のデータベースに１つの列を追加する場合に関して説明を行ったが、上記の方法を用いれば、同時に２つ以上の列を追加することや、既存のデータベースに１つの列を追加した状態で、更に別の列を１つ以上追加することが可能である。また、本説明では、列ａの直後に列ｂを追加する場合について説明したが、レコードの最後を含んで、レコードの任意の場所に列の追加が可能である。これによって、関連性の高い項目を、お互いに近接したレコード内の個所に配置することが可能となる。また、論理的な位置は挿入として、物理的な位置はレコードの最後に付け加える、というような方法も可能である。これは、データベース定義体の物理構造と論理構造に記述しておけば良い。

［オーバーフロー・ブロック管理テーブルを用いた場合］
以上の説明では、プライマリー・ブロックとオーバーフロー・ブロック、オーバーフロー・ブロックとオーバーフロー・ブロックの連結、及び、代替キー・ブロックと代替キー・オーバーフロー・ブロック、代替キー・オーバーフロー・ブロックと代替キー・オーバーフロー・ブロックの連結に関しては、「データ格納検索方式」で示された方法によっていた。これを、「データ格納検索システム」で示された、オーバーフロー・ブロック管理テーブルを用いたデータベースに適用する場合には、次のようになる。

図３７を用いて説明する。親データベース（２：ＤＢ＿Ａ）に、オーバーフロー・ブロック管理テーブル１４を設ける。更に、そのオーバーフロー・ブロック管理テーブル１４に対してオーバーフロー・ブロック管理テーブル・ポインター１４１を設ける。同様に、子データベース（３：ＤＢ＿Ａ１）にも、オーバーフロー・ブロック管理テーブル１９を設ける。更に、そのオーバーフロー・ブロック管理テーブル１９に対してオーバーフロー・ブロック管理テーブル・ポインター１９１を設ける。図３７の場合は、オーバーフロー・ブロックが発生していないので、オーバーフロー・ブロックは図上で省略してある。また、双方のオーバーフロー・ブロック管理テーブルは未使用の状態となっている。これらのオーバーフロー・ブロック管理テーブルの使用法や、それらを用いた場合のアクセスは、「オーバーフロー・ブロック管理テーブル」に記述した方法を用いる。

［列追加：過去遡及型・直接追加方式］
次に、列追加を現用のデータベースに対して、直接的に行う方法に関して述べる。ここでは、プライマリー・ブロックとオーバーフロー・ブロック、オーバーフロー・ブロックとオーバーフロー・ブロックの連結、及び、代替キー・ブロックと代替キー・オーバーフロー・ブロック、代替キー・オーバーフロー・ブロックと代替キー・オーバーフロー・ブロックの連結に関しては、「データ格納検索方式」で示された方法に関して述べる。これも、「データベース再編成システム」の機能を用いて実現する。図９、図１０を用いて、図３のデータベースに、新たに列（項目）ｂを追加する場合を説明する。ここで説明する方式は、追加する列を直接、現用のデータベースに追加する方法である。この方式を、直接追加方式と呼ぶ。まず、子データベース方式と同様に、直接追加方式で列ｂを追加することを、データベース・システムに指令する。データベース・システムでは、列ｂが追加された新たなデータベースの定義体Ｖ２（図１０のＤ２１０）を作成する。データベース定義体Ｖ２（図１０のＤ２１０）では、ＤＢ＿Ａに対して、列ｂが追加されてレコードの列数が５から６になっている。Ｖ２（図１０のＤ２１０）の列ｂの「列状況欄」は、「追加中」となっているが、これは、列を追加している最中であることを示すもので、列追加が完了すればブランク状態になる。過去遡及型・子データベース方式と同様に論理構造変換テーブルＸ６を作成する。次に、ＤＢ＿Ａ用の列追加ロケーション・テーブル８を作成する。更に、現用のロケーション・テーブル１０と列追加ロケーション・テーブル８に対して、列操作ポインター（１０３と８３）を１つずつ設ける。更に、列追加を開始する直前の最終ポインター（図９の１０１）と同じ値を持つ、列操作完了ポインター（図９の１０４）を設ける。列操作完了ポインターの目的は、直接追加方式による列追加を行っている間に、新しいレコードの追加が行われると、最終ポインター（図９の１０１）の指す位置が後方にずれてしまい、どこまでのレコードに対して列追加を行う必要があるか判別できなくなることを避けるためである。列操作完了ポインターは、列追加が完了するまで、その指している位置は変更されない。また、列追加が完了した場合には不要となる。直接列追加を行う場合には、列追加を開始した後のレコード追加は、列操作完了ポインターが指しているロケーション・テーブル・エントリーの直前のエントリーが指しているブロックには格納せず、列操作完了ポインターが指しているブロック以降に格納することが好ましい。以上が準備作業となる。

次に、列ｂの追加を行う。列ｂの内容に関するデータは、これらのデータベースの外部にあるとする。まず、現用ロケーション・テーブル・エントリー０、新規ロケーション・テーブル・エントリー０、ブロック０の排他を行う。次にｒｅｃｏｒｄ０を読み取り、ｒｅｃｏｒｄ０に列ｂを追加する。その後、ブロック０に列ｂを追加したｒｅｃｏｒｄ０を書き込む。同様に、ｒｅｃｏｒｄ１を読み込み、ｒｅｃｏｒｄ１に列ｂを追加する。その後、ブロック１に列ｂを追加したｒｅｃｏｒｄ１を書き込む。ここで、ブロック０の適正な初期格納率になったので、現用ロケーション・テーブル・エントリー０、新規ロケーション・テーブル・エントリー０、ブロック０の排他を解除する。列操作ポインターは、現用列操作ポインター（１０３）、新規ロケーション・テーブル列操作ポインター（８３）ともに、２番目のロケーション・テーブル・エントリーを指している状態にする。

図９は、このようにしてｒｅｃｏｒｄ３まで、列ｂの追加が行われた状態を示している。この説明では、分かりやすくするためにレコードを１つづつ書き戻すように記述したが、実際には、ｒｅｃｏｒｄ０を書き戻す場合に、レコード長が長くなっているので、ｒｅｃｏｒｄ１をその分だけ右側に移動する必要がある。このような、後方のレコードの移動を幾度も行うことを避けるためには、ブロック内のレコードの長さを計算して、一括して書き戻すなどの方法を採ることが好ましい。本説明では、オーバーフロー・ブロックに関して説明から除いているが、オーバーフロー・ブロックが存在する場合には、オーバーフロー・ブロックの解消を同時に行うことが好ましい。

上記の説明では、従前のブロックに長くなったレコードが収まることとして説明しているが、レコードが従前のブロックに収まらない場合には、次のようになる。１つまたは複数のブロックを対象とし、そのブロック中のレコード数とレコード長を調べ、それらのレコードに対して列追加して長くなったレコードを、適正な初期格納率で収めるために必要なブロック数Ｎを計算する。対象となったブロックの数をＭとする。幾つのブロックを対象とするかは、各々のブロックのレコードの状況による。Ｍ＝Ｎである場合は、ブロック数の増減は無い。Ｍ＜Ｎの場合は、その差の数だけブロックを追加する。当然、新規ロケーション・テーブル８のエントリーも、その分、増加する。Ｍ＞Ｎである場合は、その差の数だけブロックが未使用状態となる。それらのブロック間でレコードの移動を行い、各々のブロックが、適正な初期格納率となるように調整する。このように、列追加と再編成を同時に行うことが可能であり、同時に行うことで再編成の回数を削減することが可能である。これは、過去非遡及型・直接追加方式や、列削除・直接削除方式にも適用される。

ここでは、既存のデータベースに１つの列を追加する場合に関して説明を行ったが、上記の方法を用いれば、同時に２つ以上の列を追加することや、既存のデータベースに１つの列を追加した状態で、更に別の列を１つ以上追加することが可能であることがわかる。
上記のようにして、列の追加を行うが、列追加の完了は、列操作完了ポインターが指している現用ロケーション・テーブル・エントリーの直前のブロックに対する列追加が終了した時点とする。

以上では、代替キーに関する説明を省略しているが、代替キーに関しては、次のようになる。まず、列ｂを追加する以前から存在した代替キーに関しては、再編成により、代替キー・エントリーが指しているレコードの格納されているブロックのアドレスやブロック番号が変更になる可能性がある。このため、代替キー・エントリーに、ブロック番号やブロックのアドレスを保持している場合には、「データベース再編成システム」で述べたように、代替キー・テーブルの書換えを同時並行して実施する必要がある。一方、代替キー・エントリーにブロック番号やブロックのアドレスを保持していない場合には、代替キー・エントリーに変更が発生しないので、代替キー・テーブルに対する操作は不要である。

以上の実施例では、既存のレコードの途中に列が追加される例を記述したが、レコードの最後に列が追加される場合も、全く同様な方法で実施できることは自明である。

［過去遡及型・直接追加方式での列追加中のアクセス］
次に、このような列追加を行っている最中に、レコードに対するアクセスが可能であることを説明する。また、過去遡及型・子データベース方式で述べたように、複数のバージョンのデータベース定義体と論理構造変換テーブルを使用することにより、旧バージョンの定義体を使用しているアプリケーション・プログラムからのアクセスが問題なく行えることも同時に説明する。図９が、列追加の途中の状態を示しているので、この図を用いて説明を行う。過去遡及型・子データベース方式で説明したように、図５０から図５３までに記載してある論理は、本方式でも同様である。

アクセスが主キーであって、その主キー値（ターゲット・キー値）がａ１である場合に付いて説明する。まず、リクエスト受け処理を行い、その中で要求元がデータベース定義体のどのバージョンを使用しているかを調べる。次に、ターゲット・キー値が、列操作ポインター１０３が指しているエントリーが管理しているブロックのレコードの主キー値より小さいか否かを調べる。この場合は小さいことが分かる。小さい場合は、新規ロケーション・テーブル８に対してバイナリー・サーチを行う。バイナリー・サーチは、新規ロケーション・テーブルの先頭と、列操作ポインター８３が指している間にあるロケーション・テーブル・エントリーに対して実行する。それにより、ブロック０（１１０）を探し、その中からｒｅｃｏｒｄ１を見つける。データベース定義体のＶ２を用いて、ｒｅｃｏｒｄ１の物理構造をＶ２の論理レコードに変換する。次に、アプリケーション・プログラムがデータベース定義体Ｖ１を使用している場合は、論理構造変換テーブルを用いてＶ２の論理形式からＶ１の論理形式に変換する。構造変換の方法に関しては、図５４を用いて説明したとおりである。変換後のレコードを要求元に渡す。要求元がデータベース定義体Ｖ２を使用している場合は、論理構造の変換が不要であるので、データベース定義体によって作成されたレコードを要求元に渡す。

次に、アクセスが主キーであって、その主キー値がａ５である場合について説明する。この場合は、ターゲット・キー値が、列操作ポインターが指しているブロックの主キー値より大きいか等しい場合に該当する。この場合は、現用ロケーション・テーブル１０を使用して、列操作ポインター１０３が指しているロケーション・テーブル・エントリーと、最終ポインター１０１が指している間に存在するロケーション・テーブル・エントリーに対して、バイナリー・サーチを実行する。ブロック２（図９の１１２）の中のｒｅｃｏｒｄ５を見つけ出す。ｒｅｃｏｒｄ５は、列操作ポインターの情報から、列ｂが未追加であることが分かる。よって、レコードの形式はデータベース定義体Ｖ１（図１０のＤ１０）によって作成されたものである。また、レコード内またはレコード外の特定の場所に、そのレコードが作成されたデータベース定義体のバージョン情報を格納しておき、それを参照することで確実に、そのレコードの形式を判定することが可能である。データベース定義体Ｖ１を使用して物理構造を論理構造に変換する。要求元がデータベース定義のＶ１を使用している場合には、そのままのレコードを要求元に渡す。要求元がデータベース定義体Ｖ２を使用している場合は、論理構造変換テーブル（図１０のＸ６）を使用して、Ｖ２からＶ１への論理構造変換を行う。その後、作成されたレコードを要求元に渡す。

列追加が完了した後に、古いバージョンのデータベース定義体を使用したアプリケーション・プログラムが、新たにレコードを作製する可能性もあるので、そのようなアプリケーション・プログラムを稼動させないようにすることが好ましいが、稼動させる場合には、データベース・システムで、列ｂの値として、初期値かヌル値、または情報を持たない列としてセットする。

［過去遡及型・直接追加方式での列追加完了後のアクセス］
列追加が完了した後で、データベース定義体の異なるバージョンを使用しているアプリケーション・プログラムから、データベースに対するアクセスが可能であることを説明する。図１１は、列追加が完了した状態を示している。また、データベース定義体は図１２に示すようになる。図１２のデータベース定義体は、基本的には図１０と同じものであるが、列追加が完了しているので、Ｖ２（Ｄ２１０）の列ｂの列状況欄が空欄となっている。図１１では、以前の現用ロケーション・テーブル１０が点線で図示されているが、実際に不要となっているためである。新規ロケーション・テーブル８が現用ロケーション・テーブルであることになる。しかしながら、直接追加方式での列追加が完了した状態であることを強調するために、ここでは新規ロケーション・テーブルの名称を用いて説明する。アクセスが主キーに対するものであり、ターゲット・キー値がａ１である場合、まず、リクエスト受付処理を行う。次に、新規ロケーション・テーブル８に対して、バイナリー・サーチを行い、ブロック０の中のｒｅｃｏｒｄ１を見つけ出す。このレコードは過去遡及型・直接追加方式により列追加がされているので、レコードの形式はＶ２であることが分かる。また、子データベース方式のところで記述したように、レコード中にそのレコードが作成されたデータベース定義体のバージョンを入れておけば、より確実に容易に判別が行える。

次に、Ｖ２のデータベース定義体を用いて、物理構造と論理構造の変換を行う。次に、要求元がデータベース定義体のＶ１を使用しているかＶ２を使用しているかの判別を行う。要求元がＶ２を使用している場合には、変換されたレコードを要求元に渡す。要求元がＶ１を使用している場合には、論理構造変換テーブルを使用して論理構造の変換を行い、そのレコードを要求元に渡す。

ここでは、検索に関して述べたが、図５１から図５３の説明で述べたように、レコードの追加や削除、更新も全く同様に可能である。これらは、子データベース方式で述べたのと同様の方法を用いればよい。

代替キーからのアクセスは、代替キー・テーブルのアクセスを行った後に、ロケーション・テーブルから主キーによる検索を行い目的のレコードを検索すればよい。

以上で、列追加・直接列追加方式における、列の追加と、追加途中および追加後の列の検索に関して述べた。ここでは、既存のデータベースに１つの列を追加する場合に関して説明を行ったが、上記の方法を応用することで、同時に２つ以上の列を追加することや、既存のデータベースに１つの列を追加した後、更に別の列を１つ以上追加することが可能である。直接列追加方式の場合は、現用のデータベースに直接的に列を追加するので、列追加・子データベース方式のように、再編成の際に、２つのデータベースを１つにする必要は無い。この２つのデータベースを１つにする方法は後述する。

［オーバーフロー・ブロック管理テーブルを用いた場合］
以上の説明では、プライマリー・ブロックとオーバーフロー・ブロック、オーバーフロー・ブロックとオーバーフロー・ブロックの連結、及び、代替キー・ブロックと代替キー・オーバーフロー・ブロック、代替キー・オーバーフロー・ブロックと代替キー・オーバーフロー・ブロックの連結に関しては、「データ格納検索方式」で示された方法によっていた。これを、「データ格納検索システム」で示された、オーバーフロー・ブロック管理テーブルを用いたデータベースに適用する場合には、次のようになる。

図３８を用いて説明する。現用ロケーション・テーブル１０に対してオーバーフロー・ブロック管理テーブル１４が設けてある。また、オーバーフロー・ブロック管理テーブルの最終エントリーを識別するために、オーバーフロー・ブロック最終ポインターを１４１を設けてある。ここまでは、列追加に関係なく必要になる。直接列追加を行うためには、新規ロケーション・テーブル８を作成する。また、新規ロケーション・テーブル８に対する、新規オーバーフロー・ブロック管理テーブル８４と新規オーバーフロー・ブロック最終ポインター８４１を作成する。図３８では、オーバーフロー・ブロックが発生していないので、オーバーフロー・ブロックは図上で省略してある。また、双方のオーバーフロー・ブロック管理テーブルは未使用の状態となっている。これらのオーバーフロー・ブロック管理テーブルの使用法や、それらを用いた場合のアクセスは、「オーバーフロー・ブロック管理テーブル」に記述した方法を用いる。

［列追加：過去非遡及型・子データベース方式］
次に、過去非遡及型・子データベース方式による列追加に関して、図１３から図１６を用いて説明する。過去非遡及型・子データベース方式とは、過去遡及型・子データベース方式と基本的には似ているが、新たに追加する列に関して、過去に作成されたレコードに対して値を追加することをせず、データベース定義体の変更後に作成されるレコードから、追加列を追加する方式である。また、データベース定義体の変更後に作成されるレコードは、列追加されたもののみとすることも可能であるが、以前のバージョンのデータベース定義体で作成されたレコードを混在させることも可能である。単一のバージョンのレコードのみを追加するのは、複数のバージョンのレコードを追加することに包含されるので、ここでは、複数のバージョンのレコードが追加される場合に関して主に説明を行う。

図１３は、過去非遡及型・子データベース方式による列ｂの列追加を行おうとしているデータベースである。ここでは、既にｒｅｃｏｒｄ０からｒｅｃｏｒｄ６までの７つのレコードが作成されている。この時点で、列ｂを追加することを決め、データベース・システムに指令する。データベース・システムでは指令を受けると、列ｂが追加された後のデータベースの定義体Ｖ２（図１６のＤ２とＤ２１）を作成する。図１６では、論理構造変換テーブルＸ６が、併せて記述してある。データベース定義体Ｖ２と論理構造変換テーブルの作成方法に関しては後ほど説明する。図１６のＤ２１ではＤＢ＿Ａに対して、ＤＢ＿Ａ１が別のデータベースとして追加されている。ＤＢ＿Ａを親データベース、ＤＢ＿Ａ１を子データベースとする。

次に、ＤＢ＿Ａ１用の子ロケーション・テーブル（図１４の１５）を作成する。最終ポインター１５１を用意し、子ロケーション・テーブル１５の先頭を指すようにする。ＤＢ＿Ａ１用の子ブロック１６は、レコードを格納する都度確保していってもよいが、予め必要な数のブロックを確保しても良い。以上が準備作業となる。ＤＢ＿Ａ１では、列ｂが実際の意味を持っているが、列ｂだけでは検索や更新が出来ないので、ＤＢ＿Ａの主キーの列ａと組み合わせてレコードとし、ブロック中１６に格納することになる。この状態を示したのが、図１４である。レコードの追加がない場合は、この状態のままである。このデータベースに対するアクセスは、ＤＢ＿Ａのみに対してアクセスすればよいので、特段の問題は無い。

次に、レコードの追加を行う場合に関して説明する。ここでは、図４６から図４９までの説明が参考となる。アプリケーション・プログラムから、レコードを追加する場合は、次のようになる。まず、データベース定義体Ｖ２を使用しているアプリケーション・プログラムからｒｅｃｏｒｄ７を追加する。図４９にあるように、データベース・システムでは、リクエスト受付処理を行う。次に、アプリケーション・プログラムのデータベース定義体のバージョンの判別を行う。ここでは、Ｖ２であるので、データベース定義体（図４９の３５）のＶ２を使用して、論理構造と物理構造の変換を行う。ここでは、列ｂを除いた列を１つのレコードとして、ＤＢ＿Ａ上に格納する。列ａを主キーとし、列ａと列ｂからなる子レコードを子データベース（ＤＢ＿Ａ１）上に格納することになる。ＤＢ＿Ａ用のレコード（ｒｅｃｏｒｄ７）を、最終ポインターとの比較により、最後の位置に格納することになる。この場合は、ブロック３（１１３）となる。次に、ＤＢ＿Ａ１用のレコード（ｒｅｃｒｄ７１）を、ＤＢ＿Ａ１のブロック０（図１５の１６０）に格納する。

次に、データベース定義体Ｖ１を使用したアプリケーション・プログラムからｒｅｃｏｒｄ８を書き込むことに関して説明する。リクエスト受付処理と、データベース定義体バージョンによる振分けはｒｅｃｏｒｄ７の場合と同様である。Ｖ１のデータベース定義体により、論理構造と物理構造の変換を行う。変換後のレコードを格納することになる。この場合には、列ｂが含まれないレコードをＤＢ＿Ａに格納するのみで、ＤＢ＿Ａ１に対しては何も行わない。

図１５では、更に、Ｖ２を使用しているアプリケーション・プログラムから、ｒｅｃｏｒｄ９１が書き込まれた状態を示している。以上が、複数のバージョンのデータベース定義体を使用したアプリケーション・プログラムからのレコード書き出しの説明である。ここでは、２つのバージョンに関して説明したが、図４６から図４９までの説明で記述したように、複数のバージョンが存在する状態で稼動する。

このように、複数のバージョンのデータベース定義体を使用したアプリケーション・プログラムからレコードが書き出されると、そのレコードの形式を判別することが困難になってしまう。このような状態を避けるためには、過去遡及型の説明中でも述べたが、レコードの中またはレコード外の特定の場所に、そのレコードが作成されたデータベース定義体のバージョン情報を入れておくことにより、確実にレコード形式を判別することが可能である。このレコード中の、データベース定義体のバージョン情報は、例えば図１７のように、レコードの特定の位置に、そのレコードを作成した時に使用したデータベース定義体のバージョン情報を格納しておくというものである。図１７での、レコード長は、可変長レコードの場合にそのレコードの長さを示すものであるが、ＶＳＡＭで用いられたように、レコード内では無いブロック中の特定の場所にレコードの位置などと併せて格納することにより、外出しにすることが可能である。そこに、そのレコードが作成されたデータベース定義体のバージョンを格納するようにすることも可能である。これを示したのが図１８である。

［過去非遡及型・子データベース方式でのデータベースへのアクセス］
次に、この方式を用いた場合のレコードに対するアクセスに関して説明する。図１５が、データベース定義体Ｖ１を用いたアプリケーション・プログラムと、Ｖ２を用いたアプリケーション・プログラムから書き出されたレコードが混在しているので、この図１５と図１６を用いて説明する。また、図４６から図４９が理解の参考となる。要求元がアプリケーション・プログラムであるとする。また、アクセスが主キーに対してであり、その主キー値がａ１である場合とする。まず、リクエスト受付処理を行い、その中で要求元がデータベース定義のＶ１を使用しているかＶ２を使用しているかの判別を行う。次に、ＤＢ＿Ａのロケーション・テーブル１０に対して、バイナリー・サーチを行い、ブロック０の中のｒｅｃｏｒｄ１を見つけ出す。次に、このレコードがどのデータベース定義体を使用して作成されたかを、レコード中のデータベース定義体のバージョン情報により判別する。この場合はＶ１を使用して作成されているとする。そのバージョンのデータベース定義体を使用して、物理構造から論理構造に変換を行う。

要求元がデータベース定義体Ｖ１を使用している場合は、作成したデータベース定義体のバージョンと、要求元のバージョンが同じであるので、読み込んだレコードをそのまま要求元に渡す。要求元がデータベース定義体Ｖ２を使用している場合は、論理構造変換テーブル（図１６のＸ６）のＶ１とＶ２を参照する。Ｖ２では、レコードの列は、列ａ，ｂ，ｃ，ｄ，ｅ，ｆからなっている。列ｂはＶ２のソース欄で「ＤＢ＿Ａ１」となっており、列状況欄で「ＤＢ＿Ａから連結」となっている。このため、列ｂはＤＢ＿Ａ１に存在することになるが、実際のレコードはデータベース定義体Ｖ１で作成されているため、列ｂを持っていない。論理構造変換テーブルＸ６のＶ１の情報を送り側、Ｖ２論理位置の情報を受け側として、要求元に渡すレコードを作成する。読み込んだレコードのオフセット０バイトから８バイトを渡すレコードのオフセット０バイトから８バイトに、読み込んだレコードのオフセット８バイトから１２バイトを、渡すレコードのオフセット１８バイトから１２バイトに、読み込んだレコードのオフセット２０バイトから１４バイトを、渡すレコードのオフセット３０バイトから１４バイトに、以下、列ｅ，ｆをセットする。列ｂに関しては、読み込んだレコード中に値が存在しないので、列ｂの初期値またはヌル値、または情報を持たない列をセットすることが好ましい。レコードが完成したら要求元に渡す。

次に、要求元からのアクセスが、データベース定義体Ｖ２を使用して作成されたレコードに対するものである場合に関して説明する。アクセスがｒｅｃｏｒｄ７に対するものである場合、上記と同様に、ロケーション・テーブル１０にバイナリー・サーチを行い、ブロック３（図１５の１１３）の中のｒｅｃｏｒｄ７を見つけ出す。このレコードが作成されたデータベース定義体のバージョンの判別を行うが、この場合はＶ２であることが分かる。よってデータベース定義体Ｖ２（図１６のＤ２）を参照すると、列ｂはＤＢ＿Ａ１に存在することがわかる。よって、ＤＢ＿Ａ１に対するアクセスを行い、ｒｅｃｏｒｄ７１を読んでおく。そして、データベース定義体Ｖ２を用いて、物理構造と論理構造の変換を行う。この場合は、列ｂが子データベースに存在しているが、要求元に渡すレコードとしては、列ａ，ｂ，ｃ，ｄ，ｅ，ｆの並びとする。次に、要求元がデータベース定義体のどのバージョンを使用しているかを判別する。まず、Ｖ１を使用している場合に関して説明する。図１６の論理構造変換テーブルＸ６を使用して、Ｖ２からＶ１への論理構造の変換を行う。Ｖ２の情報を送り側、Ｖ１の情報を受け側として、列のセットを行う。ここではＤＢ＿Ａから読み込んだレコードが、そのまま受け側の形式となっている。この場合には、実際には、ＤＢ＿Ａ１へのアクセスは不要であること分かる。余分なアクセスを軽減するために、要求元のバージョンの判定により子データベースへのアクセスの要否を定めるようにすると効果的である。

次に、要求元がＶ２を使用している場合は、データベース定義体Ｖ２の情報により、ＤＢ＿ＡとＤＢ＿Ａ１へのアクセスを行い、物理構造と論理構造の変換を行う。この場合は、列ｂを、レコードの２番目の位置にセットし、列ｃ以降をその分だけ後方にずらすことである。レコードが作成されたバージョンと、要求元のバージョンが同じなので、論理構造変換テーブルによる論理構造変換は不要である。ここでは、読込み処理について述べたが、図４７から図４９の方法を用いることで、レコードの更新、削除、追加が可能である。

代替キーでのアクセスは、目的の代替キー値により、代替キー・ロケーション・テーブルのバイナリー・サーチを行い、代替キー・ブロックまたは代替キー・オーバーフロー・ブロックから、目的の代替キー値を持つ代替キー・エントリーを捜し、その代替キー・エントリーの主キー値により、ロケーション・テーブルに対して主キーによるバイナリー・サーチを行い、目的のレコードを検索すればよい。目的のレコードに対する処理は前述したとおりである。代替キーは、同一のキー値を持つレコードが複数存在する場合があり、その場合には、上記の動作を繰り返す。

［オーバーフロー・ブロック管理テーブルを用いた場合］
オーバーフロー・ブロック管理テーブルを用いた格納やアクセスは、過去遡及型・子データベース方式で述べた方法と同様であるので、ここでは詳しい説明を省略する。

［列追加：過去非遡及型・直接追加方式］
次に、過去非遡及型・直接追加方式に関して説明する。この方式は、過去遡及型・直接追加方式と似ているが、データベース定義体を変更する以前に作成されたレコードに対して、追加する列の値を持たないことである。つまり、過去に作成されたレコードは、作成された時点の形式のままであり、新たに作成されるレコードは、列の追加が行われた形式と列の追加がされる以前の形式と混在することになる。この方式の場合も、新たなデータベース定義体を作成した後に追加するレコードは、新しい形式のみとすることは可能であるが、それは、形式が混合する場合に含まれるので、ここでは、形式が混合する場合を説明する。

新しい形式のレコードのみを追加する場合には、次の２つの場合がある。１つは、古いバージョンを使用したアプリケーション・プログラムからレコードの追加を行う場合に、論理構造変換テーブルを使用して、最新バージョンの論理構造に変換する方法である。この場合、古いバージョンを使用したアプリケーション・プログラムは、追加された列に関して値を持っていないため、追加された列に対してはヌル値、または情報を持たない列か初期値をセットする。もう一つは、古いバージョンのデータベース定義体を使用しているアプリケーション・プログラムの稼動を停止することである。

図１３と、図１９、図２０を用いて説明を行う。図１３は、過去非遡及型・子データベース方式でも用いたが、列を追加する直前の状態を示している。また、この状態に対応するデータベース定義体のバージョンはＶ１であるとする。ここでは、ｒｅｃｏｒｄ０からｒｅｃｏｒｄ６までの７つのレコードが既に作成されている。この時点で、過去非遡及型で列ｂの列追加を行うことを決定し、データベース・システムに指令する。データベース・システムでは、それに対応したデータベース定義体Ｖ２（図１９のＤ２１０）と論理構造変換テーブル（図１９のＸ６）を作成する。これで、過去非遡及型・直接追加方式の列追加は完了である。なぜならば、過去のデータの変更を行わないからである。

データベース定義体Ｖ２（図１９のＤ２１０）の作成を完了した後の、レコードの追加方法を、図１９と図２０を用いて説明する。図２０は、図１３の状態から、ｒｅｃｏｒｄ７，８，９の３つのレコードが追加された状態を示している。まず、データベース定義体Ｖ２（図１９のＤ２１０）を使用したアプリケーション・プログラム（要求元）からのレコード追加に関して説明する。図４９が参考となる。アプリケーション・プログラムでは、列ａ，ｂ，ｃ，ｄ，ｅ，ｆからなるレコードを作成し、データベース・システムに渡す。データベース・システムでは、リクエスト受付処理を行う。データベース定義体Ｖ２にレコードを割振り、論理構造と物理構造の変換を行う。その後、必要に応じてレコードの格納位置を検索し、ブロック内のレコードを移動した上で、レコードの格納を行う。その後、代替キー・エントリーの追加を行う。

次に、アプリケーション・プログラムが、データベース定義体Ｖ１を使用している場合は、これも同様に、アプリケーション・プログラムから渡されたレコードを、データベース定義体Ｖ１を使用して、論理構造と物理構造の変換を行い、それを格納する。

このように、レコードの形式が複数存在するようになる場合は、過去非遡及型・子データベース方式のところで説明したように、レコード中またはブロック中にそのレコードを作製したデータベース定義体のバージョンを入れておくことにより、確実にそのレコードの形式を判別することが可能である。

［過去非遡及型・直接追加方式でのアクセス］
次に、このような状態で、レコードの読み出しや更新に関して説明する。まず、データベース定義体Ｖ１を使用した要求元からの検索の場合を説明する。図４６が参考となる。まず、リクエスト受付処理を行う。その後、ロケーション・テーブルのバイナリー・サーチを行い、目的のレコードを見つける。レコードが作成されたデータベース定義体のバージョンにより、各バージョンのデータベース定義体に割振る。各データベース定義体では、物理構造と論理構造の変換を行う。更に、変換されたレコードを、要求元のデータベース定義体のバージョンに、論理構造変換テーブルを使用して変換する。

アクセスの対象となるレコードが、データベース定義体Ｖ１で作成されており、要求元がデータベース定義体Ｖ１を使用している場合は、論理構造変換テーブルによる変換は不要である。要求元がＶ２を使用している場合には、論理構造変換テーブルを使用してＶ１からＶ２への変換を行う。この場合、Ｖ１のレコードには列ｂが存在していないため、ヌル値、または情報を持たない列か初期値をセットすることが好ましい。

次に、アクセスの対象となるレコードが、データベース定義体Ｖ２で作成されている場合に、要求元がデータベース定義体Ｖ２を使用している場合は、論理構造変換テーブルによる構造変換は不要である。要求元がＶ１を使用している場合には、論理構造変換テーブルを使用してＶ２からＶ１への変換を行う。この場合、Ｖ１のレコードには列ｂが存在していないため、列ｂを削除する。実際には、列ａの直後に列ｃ以下がセットされることになる。

この説明でも検索に関して説明を行ったが、他の方式の場合と同様に、図４７から図４９の説明で示された方法を用いることで、レコードの更新、追加、削除が行える。また、代替キーによるアクセスも、他の説明と同様で、まず、代替キーによるアクセスを行い、その代替キー・エントリーにより、主キーによる検索を行う。

［オーバーフロー・ブロック管理テーブルを用いた場合］
オーバーフロー・ブロック管理テーブルを用いた格納やアクセスは、過去遡及型・直接列追加方式で述べた方法と同様であるので、ここでは詳しい説明を省略する。

［再編成：列追加・子データベース方式の２つのデータベースを１つにする］
次に、列追加・過去遡及型・子データベース方式または過去非遡及型・子データベース方式によって作成された子データベースを、「データベース再編成システム」の手法を応用することによって親データベースに統合することが可能である。この方法に関して過去遡及型を例にとって説明を行う。図７が、再編成を行う直前のデータベースを示した図である。このデータベースは、過去遡及型・子データベース方式によって作成されたものである。図７の他に、図２１、２３、２４を用いて説明する。ここでは、親データベースに子データベースを統合することにするが、逆に子データベースに親データベースを統合することも可能である。

まず、再編成を開始すること、また再編成で２つのデータベースを１つにすることをデータベース・システムに指示する。この指令は、「データベース再編成システム」に組み込んだプログラムによって、自動的に判断することが可能である他、システム管理者によって起動する方法も可能である。この指令によって、まず、再編成を行うための準備作業を行う。この場合の再編成は、データベースを２つから１つにすることになるので、データベース定義体の新規作成が必要となる。図２１で、再編成直前のデータベース定義体をＶ２（Ｄ２とＤ２１）として、再編成途中または再編成後のデータベース定義体をＶ３（Ｄ３）として示している。データベース定義体Ｖ２はＤＢ＿Ａ（２）とＤＢ＿Ａ１（３）の２つのデータベースから構成されており、この２つをあたかも１つのデータベースであるように見せていた。これに対して、Ｖ３では、ＤＢ＿Ａが１つだけになっており、列ｂもレコード中に含まれるようになっている。更に、再編成完了後のデータベース定義体も作成する。これが図２４である。図２４には、論理構造変換テーブルＸ２５も記載してある。

再編成を行う方法は以下のようになる。まず、ＤＢ＿Ａ（２）の現用ロケーション・テーブル１０に対し、新規ロケーション・テーブル９を用意する。ＤＢ＿Ａ１の現用ロケーション・テーブルに対して、新規ロケーション・テーブルは不要である。現用ロケーション・テーブル１０用の再編成ポインター（１０２）と、新規ロケーション・テーブル９用の再編成ポインター（９２）を設ける。新規ロケーション・テーブル用の再編成ポインターは、最終ポインターで代用しても良い。ここまでが、準備作業となる。ここでは、ＤＢ＿Ａ（２）の現用ロケーション・テーブル１０に対して、新規ロケーション・テーブル９を設けるとしたが、ＤＢ＿Ａ１（３）の現用ロケーション・テーブル１５に対して新規ロケーション・テーブルを設け、ＤＢ＿Ａの現用ロケーション・テーブル１０に対して、新規ロケーション・テーブルを設けないという方法も採れる。これが、子データベースに親データベースを統合するということである。新規ロケーション・テーブルを割り当てたデータベースの方に、もう一方のデータベースを統合する形となる。この場合は、データベースに対するアクセスは、ＤＢ＿Ａ１のロケーション・テーブルを使用して行うことになる。

次に、ＤＢ＿Ａで現用ロケーション・テーブル１０の最初のエントリーと最初のブロックを排他する。ｒｅｃｏｒｄ０を読み込み、次にＤＢ＿Ａ１（３）のｒｅｃｏｒｄ１０を読み込む。ｒｅｃｏｒｄ０に対してｒｅｃｏｒｄ１０の列ｂを追加して、新たなｒｅｃｏｒｄ０として、ブロック０中に書込む。この際に、ｒｅｃｏｒｄ０のデータベース定義体のバージョン情報をＶ３に変更する。これは、このレコード以降のレコードに関しても同様である。この場合、新たなｒｅｃｏｒｄ０を格納するために、必要があればｒｅｃｏｒｄ１を図中の右側に移動する。

次に、上記と同様にｒｅｃｏｒｄ１とｒｅｃｏｒｄ１１を読み込んで、新たなｒｅｃｏｒｄ１を作成し、ブロック０に書込む。次に、ブロック０のアドレスを新規ロケーション・テーブル９に登録する。これで、ブロック０に対する再編成が終了したので、ブロック０の排他を解除する。次にｒｅｃｏｒｄ２とｒｅｃｏｒｄ３について、同様に、ブロック１の排他を行い、ＤＢ＿ＡのレコードにＤＢ＿Ａ１の列ｂを追加して、新レコードとしてブロック１中に格納する。ブロック１のアドレスを新規ロケーション・テーブルに登録する。ブロック１の排他を解除する。図２２は、ブロック１まで、再編成が完了した状態を示している。

この例では、ブロック０に空きがあって、列ｂを追加した場合でも、新たなレコードを格納できるとしているが、列ｂを追加することにより、ブロック０に格納できない場合は、新たなブロックを追加して、それを新ブロック１とする。これは、「データベース再編成システム」で述べた方法である。このような場合、ブロックを１つ追加するのみでは、追加されたブロックの格納率が適正な初期格納率を下回る可能性があるため、「データベース再編成システム」で述べたように、一時点で複数のブロックを対象にして、上記の再編成を行うことが好ましい。ここでは、説明を簡単にするため、複数ブロックを対象にした場合とせず、単独のブロックを対象にした説明に止める。再編成に関しては、「データベース再編成システム」で詳しく説明されている。また、この方法は、過去遡及型・直接追加方式でも述べた方法である。更に、レコードを統合することにより、レコード長が長くなるため、ＤＢ＿Ａのブロックの先頭から順次、レコードの書き換えを行っていくと、後方のレコードの位置をその都度ずらす必要があるが、これも、過去遡及型・直接追加方式で述べたように、ブロック単位に更新を行うことにより、オーバーヘッドを最小限にすることが可能となる。

現用ロケーション・テーブル用の再編成ポインター１０２は、現用ロケーション・テーブルの３番目のエントリーと、新規ロケーション・テーブル９の３番目のエントリーを指している。また、ＤＢ＿Ａ１に関しては、ＤＢ＿Ａに統合されるため、再編成の直接的な対象とならないので、再編成ポインターを設けなくてよい。

図２３は、以上の再編成を最後のレコードまで実行し、再編成が完了した状態を示している。ここでは現用ロケーション・テーブル１０が点線で表示してあるが、現用ロケーション・テーブルは実際には必要なく削除するのが好ましい。また、新規ロケーション・テーブル９が実際には現用ロケーション・テーブルとなる。図２４は、再編成が完了した状態でのデータベース定義体Ｖ１（Ｄ１），Ｖ２（Ｄ２２５）とＶ３（Ｄ３２５）を示している。ＤＢ＿Ａ１は再編成による統合により不要となっている。データベース定義体Ｖ２（Ｄ２２５）は、Ｖ３とイコールとなっているが、これは、Ｖ２の論理形式にＶ３が一致するように変更されたため、Ｖ３と同じになったことを示している。勿論、データベース定義体Ｖ３（Ｄ３２５）と同じ定義体を作成しておいても良い。

上記の説明では、ブロックを１つづつ対象にして再編成を行う場合を説明したが、実際には、一時点で複数のブロックを対象にして再編成することが現実的である。また、オーバーフロー・ブロックが存在し、それが再編成の対象になることもある。このような場合、オーバーフロー・ブロックをプライマリー・ブロックにして、そのアドレスをロケーション・テーブルに登録する。この方式の詳細は、「データベース再編成システム」で述べた方法を使用する。以上の実施例では、再編成によって既存のレコードの途中に列が追加される例を記述したが、レコードの最後に列が追加される場合や、同時に２つ以上の子データベースを統合する場合も、全く同様な方法で実施できる。

以上では、代替キーに関する説明を省略しているが、代替キーに関しては、次のようになる。再編成により、代替キー・エントリーが指しているレコードの格納されているブロックのアドレスやブロック番号が変更になる可能性がある。このため、代替キー・エントリーに、ブロック番号やブロックのアドレスを保持している場合には、「データベース再編成システム」で述べたように、代替キー・テーブルの書換えを同時平行して実施する必要がある。一方、代替キー・エントリーにブロック番号やブロックのアドレスを保持していない場合には、代替キー・エントリーに変更が発生しないので、代替キー・テーブルに対する操作は不要である。

［再編成中のデータベースに対するアクセス］
再編成中のデータベースに対するアクセスは、列追加中と同様に可能である。ＤＢ＿Ａの現用ロケーション・テーブル１０と新規ロケーション・テーブル９の何れを使用するかは、目的レコードの主キー値が、再編成ポインターが指しているロケーション・テーブル・エントリーの主キー値より大きいか、それ以下であるかによって使い分ける。これは「データベース再編成システム」で述べた方法である。目的レコードの主キー値が、再編成ポインターが指しているロケーション・テーブル・エントリーの主キー値より大きい場合は、現用ロケーション・テーブル１０を使用し、以下である場合は新規ロケーション・テーブル９を使用する。

ＤＢ＿Ａの新規ロケーション・テーブル９を使用する場合は、新規ロケーション・テーブル９の先頭アドレスと、再編成ポインター９２で指している、ロケーション・テーブル・エントリーの間のロケーション・テーブル・エントリーに対してバイナリー・サーチを行い、ブロックを探しレコードを見つける。新規ロケーション・テーブルが管理しているブロックにあるレコードは、再編成が終了しているので、レコードが統合されて、列ｂがレコードに追加されている。つまり、レコードはデータベース定義体のＶ３によって作成されている。よって、データベース定義体は、図２４の再編成完了後のものを使用する。Ｖ３のデータベース定義体により物理構造と論理構造の変換を行う。次に、要求元がどのバージョンのデータベース定義体を使用しているかを判別し、論理構造変換テーブルＸ２５により論理構造の変換を行う。レコードと要求元のデータベース定義体のバージョンが同一である場合は論理構造変換テーブルによる変換は不要である。

ＤＢ＿Ａの現用ロケーション・テーブル１０を使用する場合も上記と同様に、現用ロケーション・テーブル１０の、再編成ポインター１０２で指しているロケーション・テーブル・エントリーと最終ポインター１０１が指している間のロケーション・テーブル・エントリーに対してバイナリー・サーチを行い、ブロックを探しレコードを見つける。現用ロケーション・テーブル１０を使用している場合は、レコードに対する統合が未了であり、レコードはデータベース定義体Ｖ２を使用して作成されたものであることになる。Ｖ２であるので、子データベースからも子レコードを読取る。データベース定義体としては、図２１の再編成中のもの（図２１のＤ２とＤ２１）を使用する。Ｖ２のデータベース定義体を使用して物理構造と論理構造の変換を行う。次に、要求元がどのバージョンのデータベース定義体を使用しているかを判別し、論理構造変換テーブルにより論理構造の変換を行う。要求元がＶ２であるときは論理構造の変換は不要である。

代替キーからのアクセスは、代替キー・テーブルのアクセスを行った後に、ロケーション・テーブルまたは新規ロケーション・テーブルから主キーによる検索を行い目的のレコードを検索すればよい。以上では、検索の場合に関して説明を行ったが、他の方式の場合と同様、レコードの更新は、検索で見つかったレコードを更新すればよいし、削除は検索で見つかったレコードを削除すればよい。レコードの追加を、Ｖ１を使用したアプリケーション・プログラムから実行する場合には、アプリケーション・プログラムからは列ｂの無いレコードを書く形になるため稼動させないか、列ｂに関しては、初期値またはヌル値、または情報を持たない列を埋めて実体データベースを作成することが好ましい。レコードの更新、削除、追加に関しては図４７から図４９で説明したとおりである。

［再編成完了後のアクセス］
再編成が完了した状態を、図２３に示している。ここでは、現用ロケーション・テーブル１０を点線で表示してあるが、再編成が完了しているため不要となったものである。新規ロケーション・テーブル９は、実際には現用ロケーション・テーブルとして機能しているが、ここでは、新規ロケーション・テーブル９として説明を行う。また、データベース定義体と論理構造変換テーブルは、図２４に示してある。これは、再編成中のアクセスで説明したとおりである。再編成完了後のアクセスは、再編成中のアクセスで説明を行った、新規ロケーション・テーブルに対するアクセスと同じである。若干の相違は、再編成が完了しているので、再編成ポインターを用いて、現用ロケーション・テーブルを使用するのか、新規ロケーション・テーブルを使用するかの判別を行わないこと、バイナリー・サーチの対象が、新規ロケーション・テーブルの先頭から、最終ポインターが指している間にある、ロケーション・テーブル・エントリーに対するものであることである。

代替キーからのアクセスは、代替キー・テーブルのアクセスを行った後に、ロケーション・テーブルまたは新規ロケーション・テーブルから主キーによる検索を行い目的のレコードを検索すればよい。

以上では、２つのデータベースを１つに統合する場合に関して述べたが、３つ以上のデータベースを統合することも、上記の方法を用いることで実現できる。例えば、子データベースが２つある場合に、３つのデータベースを２つにした上で、更に１つにすることも可能であるし、同時に３つを１つにすることも可能である。

また、何らかの事情により、再編成時にＤＢ＿ＡとＤＢ＿Ａ１を統合せずに、各々を個別に再編成することも可能である。この場合は、単なる「データベース再編成システム」の適用であるので、詳細な説明は省略するが、再編成中のアクセスが可能であることは、「データベース再編成システム」で述べてあるとおりである。

［オーバーフロー・ブロック管理テーブルを用いた場合］
オーバーフロー・ブロック管理テーブルを用いた場合の再編成に関しては、「データ格納検索システム」に記載されている再編成の方法を適用すればよい。再編成中のレコード追加やアクセスは、再編成前のレコードに対する場合は、子データベース方式で述べた方法を使用し、再編成後のレコードに対する場合は、直接列追加方式で述べた方法を使用すればよいので、ここでは詳しい説明を省略する。何れの方式の場合でも、再編成中のデータベースへのアクセスは可能である。

以上で、子データベースを用いた再編成に関して説明を行った。この再編成を応用すると、次のような子データベースを採用することが可能となる。一つのレコード中の項目は、何れもが同程度に参照されたり更新されることはなく、各項目によって頻度が異なることが通常である。このような場合に、参照や更新の頻度が高い項目を集めて、親データベースとし、参照や更新の頻度が低い項目を集めて子データベースとするのである。頻度が高い、低い、というのは相対的な問題であり、閾値を任意に設定できるようにすることが好ましい。

このようにして、親データベースと子データベースを作成し、親データベースは高速な装置に格納し、子データベースは低速な装置に格納するのである。但し、子データベースのロケーション・テーブルは、高速な装置に格納することが好ましい。一般的に、高速な装置は高価であり、低速な装置は安価である。このように選択的に格納が行えると、全体を高価で高速な装置に格納することに比較して、高速性をあまり損なわずに安価な装置を使用して、データベースを構築することが可能となる。このようなデータベースを図示したのが図５７である。この図では、ＤＢ＿Ａが親データベースであり、ＤＢ＿Ａ１が子データベースである。

このようにして、子データベースを作成しても、アプリケーション・システムの追加や、利用状況の変化により、各項目毎の参照や更新の頻度が変化することが起こり得る。このような状況になった場合には、上記で説明した再編成の仕組みを使って、項目を入れ替えることが可能である。例えば、図５７において、項目ｃの参照、更新の頻度が低下した場合には、ＤＢ＿Ａから列ｃを削除し、ＤＢ＿Ａ１に列ｃを追加する、という作業を行うことにより、参照、更新の頻度が高い項目（列）を、常に親データベースが保持するようにすることが可能である。同様に、子データベース中の項目（列）ｄの参照、更新頻度が増加した場合には、ＤＢ＿Ａ１から列ｄを削除し、ＤＢ＿Ａに列ｄを追加する。これらの列の追加削除は、本データベースの機能によって自動的に実施可能であることは、言うまでも無い。

また、本データベースの子データベースを使用すると効果がある場合の例として、汎用パッケージ・システムへの応用がある。汎用パッケージ・システムを使用する場合に、どうしても適用が難しい部分に対して、カスタマイズを行う。その際にデータベースの項目を追加したい場合、従来の方法であると、パッケージ・システムのバージョンアップがあっても、実質的に適用できなくなってしまう。これは、パッケージ・システムでデータベース項目の追加などがあると、整合性がとれなくなるからである。ところが、本データベースを使用して、親データベースは汎用パッケージ・システムが使用し、子データベースをカスタマイズ部分が使用するようにし、両者を物理的に統合しない環境で使用することにより、パッケージ・システムがデータベース構造を変更しても、カスタマイズ部分は影響を受けない。

［新規ロケーション・テーブルの大きさ］
「データベース再編成システム」では、新規ロケーション・テーブルの大きさに関して、再編成後のプライマリー・ブロックの数よりも大きいロケーション・テーブル・エントリーを格納できるものとしている。しかしながら、この方法では、再編成のために現用ロケーション・テーブルとほぼ同じ大きさの新規ロケーション・テーブル用のスペースが常に必要となることになる。

このような問題に対して、ロケーション・テーブルを物理的には分割して取得し、各々をアドレス変換テーブルなどを用いて連続した領域として扱うことが可能である。この方法を応用すると、次のように新規ロケーション・テーブルに必要な領域を少なくすることが可能である。まず、新規ロケーション・テーブルを必要な容量の数分の１から数十分の１の容量で作成する。再編成を行っていくに従って現用ロケーション・テーブルの上位部分は不要となってくる。このため、新規ロケーション・テーブルのエントリーが満杯になったら、そこで一旦、再編成を中断し、現用ロケーション・テーブルの上位部分を開放し、そこを改めて新規ロケーション・テーブルとして取得し、再編成を再開する。これを、数回から数十回繰り返すことにより、新規ロケーション・テーブルに割り当てる領域を、一時点で小さくすることが可能である。

上記で示した、新規ロケーション・テーブルを小さな領域に分割し、現用ロケーション・テーブルの空いた領域を、新規ロケーション・テーブル用に使用する、という方法は、本発明で述べた、直接追加方式や、子データベースを親データベースに統合する再編成に適用できる他、「データベース再編成システム」にも適用可能である。

上記で示した、新規ロケーション・テーブルを小さな領域に分割し、現用ロケーション・テーブルの空いた領域を、新規ロケーション・テーブル用に使用する、という方法を応用すると、次のようなことが可能となる。図３９を用いて説明を行う。図３９では、現要ロケーション・テーブルＬＣと新規ロケーション・テーブルＬＮが示されている。この図のデータベースのように、部分的にレコードの挿入が発生して、オーバーフロー・ブロックが発生する場合がある。図３９では、プライマリー・ブロック５と６に集中的にオーバーフロー・ブロックが発生している。このような場合に、他の部分の再編成を行わずに、オーバーフロー・ブロックが集中的に発生している部分のみの再編成を行うことである。図３９では、プライマリー・ブロック０，１，２，３，４に対しては再編成を行わず、プライマリー・ブロック５と６の再編成を行い、プライマリー・ブロック７，８の再編成を行わずに、再編成を完了した時点の図である。

プライマリー・ブロック０から４までは、再編成を行わないので、現用ロケーション・テーブルがそのまま新規ロケーション・テーブルとなる。次に、プライマリー・ブロック５の再編成（ここでは主にオーバーフロー・ブロックの解消）を行う。新規ロケーション・テーブルの最初のエントリーは５となり、プライマリー・ブロック５を指す。新規ロケーション・テーブルの２番目のエントリーは６となり、オーバーフロー・ブロック５−１を指す。新規ロケーション・テーブルで管理されるということは、オーバーフロー・ブロックがプライマリー・ブロックになったということである。このようにして、オーバーフロー・ブロック５−３までの再編成を行い、更に、プライマリー・ブロック６からオーバーフロー・ブロック６−５までの再編成を行う。新規ロケーション・テーブルのエントリーは１４まで使用することになる。その後、プライマリー・ブロック７、８の再編成は行わず、現用ロケーション・テーブル・エントリーの旧７を新たにエントリーの１５に付け替える。同様に現用ロケーション・テーブル・エントリーの旧８をエントリー１６に付け替える。これで再編成が完了することになる。Ｓ１は、現用ロケーション・テーブル（＝新規ロケーション・テーブル）のエントリー４に論理的に接続するのは、新規ロケーション・テーブルのエントリー５であることを示している。

図３９では、説明を明らかにするために、新規ロケーション・テーブルという名称を使用したが、正確には、再編成が完了しているので、現用ロケーション・テーブルの一部である。このように、データベースの一部分に対して高速に再編成を実施することが可能である。

［列の削除］
次に、列の削除に関して述べる。列の削除も３つの方法がある。過去保持型と過去非保持型の２つになる。過去保持型は、更に、定義削除方式と子データベース方式に分かれる。過去非保持型は直接列削除方式のみである。過去保持型・定義削除方式は、データベースの実体からは列の削除を行わず、データベース定義上でのみ列の削除を行う方法である。この方式は、削除に伴う時間が瞬間的であるという利点があるが、実体としては列の削除を行わないため、データベースの領域が大きいままである、レコードの読み込みに、レコードが長い分と、列の削除をして要求元に転送する分、処理時間が長く掛かる、という欠点がある。この方式では、再編成の際に、削除対象の列を実際に削除することが可能である。

列削除：過去非保持型は、列追加：過去遡及型と似ており、過去に遡って既存のレコードから削除列を削除する。この型に対するアクセスは、図５０から図５３までの説明と同じになる。データベース定義体は最新のもののみを保持する。これに対し、列削除：過去保持型は列追加：過去非遡及型と似ている。既存のレコードに関しては、作成された状態のままとなる。この方に対するアクセスは、図４６から図４９まで説明と同じになる。データベース定義体は、各バージョンのものを保持する。

子データベース方式は、列削除に当って子データベースを新たに作成し、親データベースには、元のレコードから削除する列を除いたレコードを格納し、子データベースには、削除した列と主キーとを組にした子レコードを作成し、それを格納する。

直接列削除方式は、ブロック中に格納されているレコードに対して、削除するレコードを直接削除し、削除列のないレコードを新レコードとして格納するものである。

過去保持型・定義削除方式のデータベースでは、定義削除方式による列削除を行った後で、再編成の仕組を適用することにより実際に列を削除することが可能である。再編成の際に列を削除する場合、列を削除したレコードのみを新規データベースとして書き戻す方法と、削除した列と主キーとを組み合わせたレコードを新しく子データベースとして作成しておく方法がある。再編成で、列を削除したレコードのみを新規データベースとして書き戻す方法を採用した場合、再編成に要する時間は短くなるが、列を削除する前のデータベース定義体を使用しているプログラムからの要求では、削除した列の値を返すことができなくなるので、場合によってはプログラムが異常終了する可能性がある。この点は、直接列削除方式でも同様である。よって、この方式を使用する場合は、慎重に実施する必要がある。再編成で、削除した列を新しく別なデータベースとして作成しておく方法を採用した場合、再編成に要する時間は長くなる他、データベースを新たに作成する領域も必要となる。一方で、列を削除する前のデータベース定義体を使用しているプログラムからの要求でも、問題なく処理できるし、新しいバージョンのデータベース定義体を使用したプログラムからの要求は、再編成前に比較すると早くなる。

［列削除：過去保持型・定義削除方式］
図２５は、過去保持型・定義削除方式により列ｅを削除する場合の図である。図２５では、列ｅに網掛けを施しているが、この意味は以下の説明で詳述する。データベース定義体と論理構造変換テーブルＸ２７は図２６に記述してある。列ｅを削除する直前の状態に対するデータベース定義体をＶ３とし、列ｅを削除した後のデータベース定義体をＶ４としている。データベース定義体Ｖ１、Ｖ２、Ｖ３は、図２４に記載したものと同じである。また、図４６から図４９が参考となる。

まず、列ｅを定義削除方式により削除することをデータベースに指令する。これにより、データベース・システムでは準備作業を行う。この場合は、Ｖ４のデータベース定義体（Ｄ４）と、論理構造変換テーブルＸ２７の作成である。データベース定義体Ｖ１（Ｄ１）、Ｖ２（Ｄ２２５）、Ｖ３（Ｄ３２５）に関しては変更が無いので、そのまま使用する。データベース定義体Ｖ４（Ｘ２７）では、列ａから列ｆまでの６つの列からなるレコードから、列ｅが削除されることになる。しかしながら、実体データベースとしては、列ｅを保持したままであるので、Ｖ４の列ｅの列状況欄に「定義削除」というステータスを立てる。データベース定義体Ｖ４（Ｘ２７）の論理位置の列ｅと、論理構造変換テーブル（Ｘ２７）のＶ４論理位置の列ｅのオフセットには「（６４）」、長さは「（１６）」としてある。この表現は、列ｅは実体としては削除されていないが、定義上は削除されているということを識別可能とし、更に、データベース定義体Ｖ４で作成されたレコードを他のバージョンの論理構造に変換する場合に、列ｅの値が渡されるようにする為である。Ｖ４のレコード自体には、列ｅは保持していない。他のバージョンに変換するための仮の列として必要になる。以上で準備作業は終了する。図２５で列ｅを網掛けしたのは、定義上の削除であることを示したものである。実体としてのデータベースには、何らの変更をする必要が無いので、削除に伴う作業は以上で完了する。

［定義削除方式におけるデータベース・アクセス］
以上のように、定義削除方式による列削除は瞬時に完了するので、列追加の場合のように、列削除中のアクセスに関する問題は無い。列削除後のアクセスに関して説明を行う。列削除後の要求元が、どのバージョンのデータベース定義体を使用しているかの識別を行う。リクエスト受付処理、インデックス検索を行い、レコードを検出するまでは、他の場合と同様である。読み取ったレコードのバージョンの判別を行う。そのバージョンのデータベース定義体３５により、物理構造と論理構造の変換を行う。更に、要求元のデータベース定義体のバージョンに対して、論理構造変換テーブルを使用して論理構造の変換を行い、作成されたレコードを要求元に渡す。他の方式の場合と同様に、この方法に従って、レコードの更新、追加、削除が行える。代替キーによるアクセスも他の方式と同様に実行できる。

ここで、データベース定義体Ｖ４から、他のバージョンへの論理構造変換に関して、より詳細に説明する。レコードがデータベース定義体Ｖ４で作成されているとする。Ｖ４では、列ｅが削除されているため、データベース定義体Ｖ４を用いて物理構造と論理構造の変換を行うと、列ｅが存在しないレコードが作成されてしまい、それを他のバージョンに変換しても、列ｅの値がなくなってしまう。このような状態を避けるための方法が、図２６のデータベース定義体Ｖ４（Ｄ４）と、論理構造変換テーブルＸ２７に示されている。データベース定義体Ｖ４（Ｄ４）の列ｅは、オフセットが「（６４）」、長さが「（１６）」として示してある。この括弧は、本来の論理レコードには含まれないが、論理変換のために必要なフィールドである、という意味として使用している。これは、論理構造変換テーブルのＶ４の列ｅにおいても同じ表現を用いている。Ｖ４の論理レコードのオフセット６４バイトからの１６バイトは列ｅの値が格納されている。つまり、Ｖ４の論理構造変換の際に、他のバージョンに変換する場合には、列ｅの値をセットしておき、他のバージョンへその値を渡すことを意味している。これは過去保持型を採用しているから行えることである。

［オーバーフロー・ブロック管理テーブルを用いた形式への適用］
オーバーフロー・ブロック管理テーブルを用いた場合の格納やアクセスに関しては、データベースの物理構造が変更されていないので、定義削除を行う前と同様に実施可能である。

［列削除：過去保持型・子データベース方式］
図２７、２９、３０、３１、３２を用いて、過去保持型・子データベース方式の列削除に関して説明する。図２７は、列削除を行うとするデータベースである。ここには、ｒｅｃｏｒｄ０からｒｅｃｏｒｄ６までの７つのレコードが格納されている。各レコードは、列ａ，ｂ，ｃ，ｄ，ｅ，ｆからなっている。このレコードに対して列ｅの削除を行う。列削除を過去保持型・子データベース方式で行うことを、データベース・システムに対して指令する。データベース・システムでは、この指令により準備作業を行う。新規ロケーション・テーブル（図２８の９）と、新規ロケーション・テーブル用の最終ポインター（図２８の１０１）を作成する。更に、子データベースＤＢ＿Ａ１（図２８の３）を作成し、子ロケーション・テーブル（図２８の１５）と子ロケーション・テーブル用の最終ポインター（図２８の１５１）を作成する。現用ロケーション・テーブル用に列操作ポインター（図３０の１０２）を作成し、その中身は現用ロケーション・テーブルの先頭アドレスとする。新規ロケーション・テーブル用にも列操作ポインター（図３０の９２）を作成し、その中身は新規ロケーション・テーブルの先頭アドレスとする。新規ロケーション・テーブルの列操作ポインターは最終ポインターでも代用可能である。現用ロケーション・テーブルの最終ポインター１０１が指しているエントリーと同じエントリーを指す列操作完了ポインター１０４を作成する。¹更に、データベース定義体Ｖ４（図２９のＤ４３０とＤ４１３０）、論理構造変換テーブル（図２９のＸ３０）を作成する。データベース定義体Ｖ１（図２９のＤ１）、Ｖ２（図２９のＤ２２５）、Ｖ３（図２９のＤ３２５）は、図２４のものと同じである。つまり、図２７のデータベースは、図２３のデータベースと同じものである。

図３０は、過去保持型・子データベース方式による列削除が途中まで進行した時点の図である。最初から順を追って説明する。まず、ＤＢ＿Ａ（図３０の２）の現用ロケーション・テーブル（図３０の１０）のエントリー０とブロック０（図２９の１１０）、新規ロケーション・テーブル（図３０の９）のエントリー０、更に子ロケーション・テーブル（図３０の１５）のエントリー０と子ブロック０（図３０の１６０）を排他し、ｒｅｃｏｒｄ０を読む。ｒｅｃｏｒｄ０から列ｅを削除した後、列ａ，ｂ，ｃ，ｄ，ｆからなるレコードをブロック０（図３０の１１０）に書き戻す。次に、主キーである列ａと削除した列ｅを組み合わせて子レコードｒｅｃｏｒｄ０１とし、ＤＢ＿Ａ１（図３０の３）のブロック０（図３０の１６０）に格納する。ＤＢ＿Ａ１の子ロケーション・テーブルの最初のエントリーを排他し、子ブロック０（図３０の１６０）を作成し、その中に格納する。次にｒｅｃｏｒｄ１を読み、列ａ，ｂ，ｃ，ｄ，ｆからなるレコードをブロック０（図３０の１１０）に書き戻す。次に、主キーである列ａと削除した列ｅを組み合わせて子レコードｒｅｃｏｒｄ１１とし、ＤＢ＿Ａ１（図３０の３）のブロック０（図３０の１６０）に格納する。

ここで、ＤＢ＿Ａのブロック０（図３０の１１０）が満杯になったので、現用ロケーション・テーブル１０（図３０の１０）のエントリー０と、ブロック０（図３０の１１０）、新規ロケーション・テーブル（図３０の９）のエントリー０、子ロケーション・テーブル・エントリー０と子ブロック０の排他を解除する。現用ロケーション・テーブル（図３０の１０）の列操作ポインターは、現用ロケーション・テーブル・エントリー１の先頭を指すようにする。新規ロケーション・テーブルの列操作ポインター）図３０の９１）は、新規ロケーション・テーブル・エントリー１の先頭を指すようにする。子ロケーション・テーブルの最終ポインター（図３０の１５１）は、子ロケーション・テーブル・エントリー１の先頭を指すようにする。

以下、同様に、ｒｅｃｏｒｄ２を読み列ｅを削除した後、列ａ，ｂ，ｃ，ｄ，ｆからなるレコードをブロック１（図３０の１１１）に書き戻す。次に、主キーである列ａと削除した列ｅを組み合わせてｒｅｃｏｒｄ２１とし、ＤＢ＿Ａ１（図３０の３）のブロック０（図３０の１６０）に格納する。ｒｅｃｏｒｄ３も同様に処理する。

上記の例では、説明を単純化するために、ＤＢ＿Ａのブロックに格納するレコード数が変わらないとしたが、実際にレコード数が変化する場合には、一時点で、複数のブロックを対象として排他を行い、それらのブロックのレコードに対して列削除の操作を行い、各ブロックに適正な初期格納率でレコードが格納されるようにする。この際に、オーバーフロー・ブロックがあれば、それをプライマリー・ブロックとし、適正な初期格納率とする場合に、余分なブロックが生じた場合には、それを未使用ブロックとする。図３１は、このようにして列削除を行い、ｒｅｃｏｒｄ６まで完了した状態を示している。

［列削除を行っている際のデータベースに対するアクセス］
この状態は、列追加・子データベース方式の逆の動作を行っているので、図３０に示した状態は、図５の列追加：過去遡及型・子データベース方式と図９の列追加：過去遡及型・直接追加方式を組み合わせたものになっており、列削除を行っている状態であっても、アクセスは問題なく実行できる。図式としては図４６から図４９が適用される。また、論理構造変換テーブルによる論理構造変換で、Ｖ４から他のバージョンへの変換は、過去保持型・定義削除方式で説明したと同様に、列ｅの論理位置と長さに特別の意味を持たせて、論理構造変換を可能としている。

［オーバーフロー・ブロック管理テーブルを用いた形式への適用］
オーバーフロー・ブロック管理テーブルを用いたデータベース形式に対して本方式を適用する場合の、データの格納やアクセスは、列追加・子データベース方式と同様であるので、ここでは詳しい説明を省略する。

［列削除：過去非保持型・直接列削除方式］
過去非保持型・直接列削除方式に関して説明する。この方式は、既存のレコードから削除列を削除したレコードのみを、新たなレコードとして、ブロックに書き戻す方法である。この方式は、列追加における直接列追加方式と類似点が多い。この方法を図３２を使用して説明する。まず、現用ロケーション・テーブル１０に対して、新規ロケーション・テーブル９を用意する。次に、現用ロケーション・テーブルと新規ロケーション・テーブルに対して、列操作ポインターを１つづつ用意する。列操作ポインターは、最初は各々のロケーション・テーブルの最初のエントリーを指している。更に、現用ロケーション・テーブルの最終ポインター１０１が指しているロケーション・テーブル・エントリーと同一の場所を指す列操作完了ポインター１０４を設ける。列操作完了ポインターの値は、列削除が完了するまで変更されない。

次に、現用ロケーション・テーブル・エントリー０、ブロック０、新規ロケーション・テーブル・エントリー０を排他する。次に、ｒｅｃｏｒｄ０を読み込み、列ｅを削除し、ブロック０に書き戻す。次に、ｒｅｃｏｒｄ２の処理を同様に行う。ここでブロック０が適正な初期格納率となったので、現用ロケーション・テーブル・エントリー０、ブロック０、新規ロケーション・テーブル・エントリー０の排他を解除する。

実際には、オーバーフロー・ブロックが存在したり、ブロック内のレコードが占めるスペースが、適正な初期格納率を下回るなどの可能性があるため、一時点で複数のブロックを対象にして、上記の列削除を行うことが好ましい。ここでは、説明を簡単にするため、複数ブロックを対象にした場合とせず、単独のブロックを対象にした説明に止める。図３５は列ｅの削除が完了した時点の図である。ロケーション・テーブル１０は、列削除を行っていた時点では、新規ロケーション・テーブルとして用意したものである。

過去非保持型では、既に作成されているレコードに存在している削除列の削除を行う型であり、レコード形式は最新の１世代のみとなる。ところが、Ｖ１を見ると、列ｂが存在していない形式となっている。このため、単純に最新のＶ４のデータベース定義体のみを保持する方法では矛盾が発生してしまう。この矛盾を回避する方法としては、以下の２通りの方法がある。１つ目は、過去のバージョンのデータベース定義体を残しておく方法である。この場合、過去の状態のままで残すとレコード形式と矛盾してしまうので、列ｅを取り除いた形式として、新たにデータベース定義体を作成しなおす。また、この方法を採用する場合には、列削除を行う前と後とでレコード形式が異なるため、列削除を行っている間は、旧形式のデータベース定義体と新形式のデータベース定義体の双方を保持する。この場合のデータベース定義体と論理構造変換テーブルを示したのが、図３３である。

２つ目の方法は、Ｖ１で作成されたレコードの列ｂに、ヌル値、または情報を持たない列または初期値を与えて、同一のレコード形式にしてしまう方法である。この場合、データベース定義体はＶ４のみが存在することになる。この場合の、データベース定義体と論理構造変換テーブルを示したのが、図３４である。ここでは、論理構造変換テーブルのＶ１の列ｂの列履歴には「ＤＵＭＭＹ」という表現を入れて、正規の情報では無いことを表現している。

列削除を行っている間の、データベースに対するアクセスは、列追加・直接列追加方式と同様であり、検索、追加、削除、更新が行える。

［オーバーフロー・ブロック管理テーブルを用いた形式への適用］
オーバーフロー・ブロック管理テーブルを用いた形式のデータベースに対して本方式を適用する場合は、列追加：過去遡及型で述べた方法を適用すればよいので、ここでは詳細な説明は省略する。データの追加や変更・削除がいつでも可能なのは言うまでも無い。

［定義削除方式後の再編成］
次に、列削除を定義削除方式によって実行した場合に、その後の再編成時に列ｅをどう扱うかで、再編成は３通りの方法をとることができる。

［定義削除方式後の再編成：定義削除列を保持］
一つ目は、列ｅをそのまま保持し続ける方式である。この方式のメリットは、再編成に必要な時間を短縮できる、列ｅを使用しているプログラムの稼動を保証できる、という点にある。一方で、列ｅを実体データベースから削除した場合に比較して、レコードのアクセスに時間が掛かる、データベースの格納容量が列ｅの分だけ余分に必要となる、というデメリットがある。

［定義削除方式後の再編成：定義削除列を子データベースとして追加］
２つ目の方法は、実体データベースから列ｅを削除するが、列ｅを子データベースとして作成しておく、という方式である。子データベースは、列追加で子データベース方式に関して説明を行ったが、その説明と同じとなる。新規データベースは列ｅと主キーである列ａからなる子レコードとして格納される。この方式のメリットは、列ｅを使用していたプログラムの稼動を保証できる、という点と、データベース定義体Ｖ４を使用しているプログラムからのアクセスが早くなる、という点である。一方で、再編成時に新たにデータベースを作成するので、再編成にかかる時間が増加する、という点と、新規データベースのための領域が余分に必要である、というデメリットがある。実施方法は過去保持型・子データベース方式で説明した方法を適用する。

［定義削除方式後の再編成：定義削除列を実体削除］
３つ目の方法は、実体データベースから列ｅを削除してしまう方法である。この方法は、列削除・直接削除方式と方式的には全く同じである。データベース領域が最も少なくて済むことである。一方で、列ｅを使用しているプログラムの稼動が保証できない、というデメリットがある。実施方法は過去非保持型・直接削除方式で説明した方法を適用する。

以上のように、それぞれの方式にはメリット、デメリットが存在するので、その意味を理解した上で選択することが必要である。また、再編成中や再編成後のデータベースへのアクセスは、列追加や列追加後の再編成時のアクセスと同様であるので、説明は省略するが、何の問題も無くアクセスが可能である。

［オーバーフロー・ブロック管理テーブルを用いた形式への適用］
オーバーフロー・ブロック管理テーブルを用いた形式のデータベースに本方式を適用する場合は、これまで説明してきた方法と変わる所が無いので詳細な説明は省略する。再編成を行っている間の、データの追加や変更・削除が可能であるのは言うまでも無い。

次に、列の変更の場合に関して述べる。列の変更は、属性と長さに関するものである。これを分類すると、その列の属性の変更で長さの変更が無い場合、列の属性の変更が無く長さが変更になる場合、列の属性と長さの両方が変更になる場合の３つになる。属性とは、その列に格納されている情報の型のことで、数値であるとか、文字、日付などといった属性がある。

列変更：過去遡及型の場合に関して説明を行う。現用ロケーション・テーブルに対して、新規ロケーション・テーブルを設け、再編成を実施しながら、既存のレコードの変更列を変更していく。列操作ポインターを現用ロケーション・テーブルと新規ロケーション・テーブル用に各々１つづつ設けるのは、列追加の場合と同様である。列変更：過去遡及型の場合は、列追加：過去遡及型と同様に、レコードの形式は最新のデータベース定義体バージョンのみとすることが好ましい。この場合は、データベース定義体は最新のバージョンのみを保有することになる。一方で、古いデータベース定義体を使用したアプリケーション・プログラムにレコードを渡すために、論理構造変換テーブルを使用する。

列変更：過去非遡及型の場合は、既存のレコードに対する変更を行わないので、既存のレコードに対する操作は不要である。新たに作成されるレコードは、最新バージョンのデータベース定義体を用いたものだけでなく、既存の古いデータベース定義体バージョンを用いたレコードも追加される。また、既存のレコードは、作成された時点の形式のままであるので、データベース定義体は各バージョンを保有することになる。この場合も、論理構造変換テーブルを使用する。

次に列の長さの変更に関して説明する。列の長さを変更する方法も、過去遡及型と過去非遡及型を選択する事が可能である。過去遡及型とは、既存のレコードの変更列の長さを新しいデータベース定義体の長さに合わせるように変更する方法である。この場合の、既存のレコードに対する変更は、列追加：過去遡及型で述べた方法と同様である。過去非遡及型の場合には、既存のレコードに対しては変更を行わず、新たに作成されるレコードで、最新のデータベース定義体を用いて作成されるレコードの変更列の長さが変更されることになる。

この場合も、論理構造変換テーブルを用いることで、レコードのバージョンとアプリケーション・プログラムのバージョンが異なっても、レコードの受け渡しが可能であるが、列の長さを変更した場合、情報の桁あふれや切り捨ての可能性があるため、適用する場合には、運用上の問題が発生しないことを確認することが必要である。

［アクセラレーター・システムへの適用］
図４０を用いて、アクセラレーター・システムの説明を行う。アクセラレーター・システムの原理は次のようなものである。ロケーション・テーブルや代替キー・ロケーション・テーブルに対して、バイナリー・サーチを行って目的のレコードを見つける。ロケーション・テーブルに対してバイナリー・サーチを行う際には、二分割点を幾度も探すことになり、この回数は、ブロック内でレコードを探すための回数よりも多くなることが一般的である。また、同時に複数のプロセスから、同じブロック内のレコードを要求する可能性は相当に低いものである。よって、ロケーション・テーブルと代替キー・ロケーション・テーブルのコピーを複数保有し、各々に対して並行してバイナリー・サーチが行えるようにすれば、レコードに対するアクセス要求を数多く実行することが可能となる。

図４０では、アクセラレーター・システムが１つの場合を示している。アクセラレーター・システムでは、ロケーション・テーブル（フランド・ロケーション・テーブル）、代替キー・ロケーション・テーブル（フランド・代替キー・ロケーション・テーブル）を保有しているが、プライマリー・ブロック、オーバーフロー・ブロック、代替キー・ブロック、代替キー・オーバーフロー・ブロックは保有していない。アクセラレーター・システムのフランド・ロケーション・テーブルは、プライマリー・システムのロケーション・テーブルと機能的に同等のものである。同様にアクセラレーター・システムのフランド・代替キー・ロケーション・テーブルは、プライマリー・システムの代替キー・ロケーション・テーブルと機能的に同等なものである。アクセラレーター・システムのフランド・ロケーション・テーブルの各レコードは、プライマリー・システムの各ロケーション・テーブル・レコードと同じブロックを指している。

アクセラレーター・システムでは、アクセス要求があると、主キーの場合はフランド・ロケーション・テーブルに対してバイナリー・サーチを行い、目的のブロックを探し、そのブロック内のレコード検索をプライマリー・システムに依頼する。代替キーの場合は、フランド・代替キー・ロケーション・テーブルのバイナリー・サーチを行い、目的のブロックを見つけ、プライマリー・システムが保持している代替キー・ブロックから目的の代替キー・レコードを見つけ、その代替キー・レコードによって、フランド・ロケーション・テーブルのバイナリー・サーチを行って目的のレコードを見つける。ここでは検索の方法を述べたが、この方法を適用することで、レコードの更新、追加、削除が行える。また、代替キーの場合に、代替キー・レコードに基づいてフランド・ロケーション・テーブルのバイナリー・サーチを行う、としたが、代替キー・レコードに、ブロックのアドレスやブロック番号を保持している場合には不要である。このようにして、複数のアクセラレーター・システムで並行してレコードの検索や更新を行うことにより、処理量を増加させることが可能となる。

図４０では、アクセラレーター・システムはロケーション・テーブル１つと代替キー・ロケーション・テーブル３種を保持しており、プライマリー・システムと同じ数となっている。これを、「アクセラレーター」では対称システムと呼んでいる。これに対して、例えば、ロケーション・テーブルと代替キー・ロケーション・テーブルを２種類のみ保持しているようなアクセラレーター・システムを想定しており、ロケーション・テーブルのみ、代替キー・ロケーション・テーブルのみ、といったアクセラレーター・システムを作成することが可能である。これを非対称システムと呼んでいる。アクセラレーター・システムに関しても、プライマリー・ブロックとオーバーフロー・ブロック、代替キー・ブロックと代替キー・オーバーフロー・ブロックに関して、ほぼ同様に扱うことができる。

［アクセラレーター・システムへの適用］
次に、「アクセラレーター機能」を用いたシステムで、プライマリー・システムとアクセラレーター・システムの同期に関して適用に関して図４１を用いて説明する。プライマリー・システムでは、ロケーション・テーブル１０、代替キー・ロケーション・テーブルＡＬＡＯ、代替キー・ロケーション・テーブルＡＬＢ０、代替キー・ロケーション・テーブルＡＬＣ０、を持っている。更に、最終ポインター（１０１、１０Ａ１、１０Ｂ１、１０Ｃ１）を持っている。データベースがオーバーフロー・ブロック管理テーブルを用いた形式である場合には、オーバーフロー・ブロック管理テーブル２０、代替キー・オーバーフロー・ブロック管理テーブル２０Ａ、代替キー・オーバーフロー・ブロック管理テーブル２０Ｂ、代替キー・オーバーフロー・ブロック管理テーブル２０Ｃ、を持つ。また、オーバーフロー・ブロック管理テーブルには、オーバーフロー・ブロック管理テーブル・ポインター２０１を設け、代替キー・オーバーフロー・ブロック管理テーブル２０Ａに対して、代替キー・オーバーフロー・ブロック管理テーブル・ポインター２０Ａ１を設け、同様に、代替キー・オーバーフロー・ブロック管理テーブル・ポインター２０Ｂ、２０Ｃを設けている。

アクセラレーター・システム３では、フランド・ロケーション・テーブル１６、ＡＬＡ１とＡＬＢ１とＡＬＣ１の各フランド代替キー・ロケーション・テーブル、更に、最終ポインター（１６１、１６Ａ１、１６Ｂ１、１６Ｃ１）を持っている。データベースが、オーバーフロー・ブロック管理テーブルを用いたデータベース形式である場合には、フランド・オーバーフロー・ブロック管理テーブル２１、フランド代替キー・オーバーフロー・ブロック管理テーブル２１Ａ、２１Ｂ、２１Ｃを設ける。２１Ａ、２１Ｂ、２１Ｃの各フランド代替キー・オーバーフロー・ブロック管理テーブルに対して、それぞれフランド代替キー・オーバーフロー・ブロック管理テーブル・ポインター２１Ａ１、２１Ｂ１、２１Ｃ１を設ける。

アクセラレーター・システムでは、プライマリー・システムで、ロケーション・テーブルまたは代替キー・ロケーション・テーブルに変更が発生した場合に、アクセラレーター・システムに対して、その変更を通知し、アクセラレーター・システムでは、当該フランド・ロケーション・テーブルまたはフランド代替キー・ロケーション・テーブルの変更を行うことになっている。プライマリー・システムで、ロケーション・テーブル１０、最終ポインター１０１、代替キー・ロケーション・テーブル、代替キー・ロケーション・テーブルの最終ポインター（１０Ａ１、１０Ｂ１、１０Ｃ１）、の何れかに変更が発生した場合に、その変更部分をアクセラレーター・システムに通知する。アクセラレーター・システムでは、その通知に基づいて、当該フランド・ロケーション・テーブル１６、フランド代替キー・ロケーション・テーブル、フランド代替キー・ロケーション・テーブルの最終ポインター（２１Ａ１、２１Ｂ１、２１Ｃ１）、の何れかに対して、当該変更部分の変更を行う。

また、データベースがオーバーフロー・ブロック管理テーブルを用いている場合には、上記に加えて、プライマリー・システムで、オーバーフロー・ブロック管理テーブル２０、オーバーフロー・ブロック管理テーブル・ポインター２０１、代替キー・オーバーフロー・ブロック管理テーブル（２０Ａ、２０Ｂ，２０Ｃ）、代替キー・オーバーフロー・ブロック管理テーブル・ポインター（２０Ａ１、２０Ｂ１、２０Ｃ１）に変更が発生した場合には、アクセラレーター・システムにその変更を通知し、アクセラレーター・システムでは、当該フランド・オーバーフロー・ブロック管理テーブル２１、フランド最終ポインター１６１、フランド・オーバーフロー・ブロック管理テーブル・ポインター２１１、フランド代替キー・オーバーフロー・ブロック管理テーブル（２１Ａ、２１Ｂ、２１Ｃ）、フランド代替キー・オーバーフロー・ブロック管理テーブル・ポインター（２１Ａ１，２１Ｂ１，２１Ｃ１）の何れかに対して、当該部分の変更を行う。

このように、プライマリー・システムから変更部分をアクセラレーター・システムに通知し、アクセラレーター・システムで直ちにその変更を適用することにより、アクセラレーター・システムの、フランド・ロケーション・テーブル１６、フランド・オーバーフロー・ブロック管理テーブル２１、フランド最終ポインター１６１、フランド・オーバーフロー・ブロック管理テーブル・ポインター２１１、フランド代替キー・ロケーション・テーブル（２１Ａ、２１Ｂ、２１Ｃ）、フランド代替キー・ロケーション・テーブルの最終ポインター（２１Ａ１、２１Ｂ１、２１Ｃ１）、フランド代替キー・オーバーフロー・ブロック管理テーブル（２１Ａ、２１Ｂ、２１Ｃ）、フランド代替キー・オーバーフロー・ブロック管理テーブル・ポインター（２１Ａ１，２１Ｂ１，２１Ｃ１）は、プライマリー・システムと同等に保たれる。アクセラレーター・システムでは、当該個所の変更が完了すると、変更完了通知をプライマリー・システムに対して送信する。プライマリー・システムでは、すべてのアクセラレーター・システムからの変更完了通知が到着するまで、当該部分の排他待ちを行う。

以上で、基本的な場合のアクセラレーター・システムへの適用に関して説明を行ったが、直接列追加や直接列削除、直接列変更の場合には、それらの操作を行っている場合には、次の条件が加わる。プライマリー・システムでは、上記の条件の他に、現用ロケーション・テーブル用の列操作ポインター、列操作完了ポインターと、新規ロケーション・テーブル、新規列操作ポインターが増加する。これに対応するために、アクセラレーター・システムでは、フランド現用ロケーション・テーブル用の列操作ポインター（フランド列操作ポインター）、フランド列操作完了ポインター、フランド新規ロケーション・テーブル、フランド新規列操作ポインターを追加する。データベースが、オーバーフロー・ブロック管理テーブルを使用した形式である場合には、新規ロケーション・テーブルに新規オーバーフロー・ブロック管理テーブルと、新規オーバーフロー・ブロック管理テーブル・ポインターが追加される。プライマリー・システムで上記要素に変更があった場合には、アクセラレーター・システムにその変更を通知し、アクセラレーター・システムでは、当該個所の変更を行う。

アクセラレーター・システムでのアクセスは、ブロックへのアクセスがプライマリー・システムに変わるだけで、その他は、前述の列追加・削除・変更での説明と、アクセラレーター・システムで説明した方法を組み合わせることで実現できる。

上記では、アクセラレーター・システムの対称システムを想定した説明を行ったが、非対称システムの場合には、プライマリー・システムで変更があった部分を保持するアクセラレーター・システムのみが、その変更を受け取り更新することになる。

これまで、データベースにおける列の追加・削除・変更に関して説明を行った。この列の追加・削除・変更は、一般的なデータベースに適用できるだけでなく、ＸＭＬを用いた情報管理にも適用が可能である。ＸＭＬとは、タグによって囲まれた情報の集まりであるが、タグは自由に作成できるため、列の追加・削除・変更に対して柔軟性がある一方で、そのような柔軟性があるデータをキチンと整理して格納しておく方法が無いことが欠点となっていた。

特に問題となるのは、図４２のＸＭＬサンプルの「原料」のように、同一で属性を持ったタグや、図４３のＸＭＬサンプルの「著者」のように、属性を持たずに同一のタグが出現することである。特に、図４２の「原料」や、図４３の、「著者」のように同列のタグが複数個存在する場合を扱うには、ＲＤＢの正規化の問題も絡み、従来型のデータベースでは困難であった。図４２の原料の場合には、「ＮＯ」の数によって、別々の項目ととらえることも可能であるが、ある原料が使用されているか否かを調べる場合には、従来型では困難な作業であった。

本明細書で述べた方法を用いたデータベース・システムを作成すると、ＸＭＬ情報の格納が容易に実現できる。ＸＭＬのタグを列の名称としてデータベースを構築する。タグが増加したときには列の追加とし、タグが減少した場合には列の削除として、データベースの定義を変更していけばよい。同一のタグの場合の解決法を、図４４を用いて説明する。列ｃは、「繰り返し」として１、２、３の３つが登録されている。これは、図４３の著者名に当る列である。同じタグであるので同一の列名とするが、それを区分するために「繰り返し」欄を使用している。この場合は、著者名が３名までの場合に適用できるが、もっと著者が多い場合には、列ｃに対して列追加を行えばよい。

列ｃ１と列ｃ２、列ｃ３は各々別々の列であるので、従来型の代替キーである場合には、３つの代替キーを作成していたが、ここでは、１つの代替キー（代替キーＣ）として登録している。「データ格納検索方式」で示した代替キーは、代替キー値と主キー値を組み合わせたレコードを代替キー・エントリーとして、代替キー・テーブルに登録している。このため、別々の列であっても、情報の内容や属性が同じであれば、同一のキーとして使用することが可能である。この方法を用いることにより、特定の著者が書いた本がどれであるかを検索する場合などには、大きな効果を発揮する。図９９は、図４３のＸＭＬの著者が代替キーＣであるとする場合に、代替キー・エントリーがどのように作成されるかを示したものである。これらの代替キー・エントリーは、同一の代替キー・テーブル（代替キーＣ）に格納される。

図４２の「原料」も同様に、一つのキーとすることが可能である。勿論、原料の属性に従って個別の列として扱うこともできる。図４２の「製品」や、図４３の「書籍」は、「製品」や「書籍」ごとにレコードとして分割して格納することが効果的である。この場合には、主キーにサフィックスを負荷して、同一の主キーを持っており、レコードが分割されていることを表すのが好ましい。属性情報は、データベース定義体の列の論理構造中に格納しておくことにより、データベースのレコードをＸＭＬに変換することが可能となる。

ＸＭＬでは、情報がネスティングされて、上位の情報と下位の情報というように階層構造を持つことが可能であるが、このような構造に対応するには、ＣＯＢＯＬのＤＡＴＡ ＤＩＶＩＳＩＯＮのように、レベル番号をデータベース定義体の列の論理構造中に記述しておくことにより対応が可能となる。

このようにＸＭＬを、「データ格納検索方式」および「データ格納検索システム」で示したデータベースに格納することが可能である。また、ＸＭＬ形式とレコード形式の変換は、アクセラレーター・システムを採用している場合には、アクセラレーター・システムで実行することにより、プライマリー・システムの負荷を低減することが可能となる。

［データベース定義の作成変更システム］
列を追加する場合や再編成中のデータベースに対するアクセスの説明で、データベース定義体を変更したり、作成したりすることを説明した。このようなデータベース定義体を人手によって作成したり、変更したりすることは、手間が掛かり、間違いを発生させる可能性も大きくなるため、好ましくない。本システムによって自動的に作成、変更されることが好ましいのは当然である。以下では、データベース定義体の作成、変更を自動的に行う方法について説明する。図４で示した、Ｖ１に付いては人手で作成する以外に方法はない。自動的に作成、変更を行うのは、Ｖ２以降を作成する場合や、新しいバージョンのデータベース定義体を作成する際に、それよりも前のバージョンのデータベース定義体を変更する場合である。まず、列の追加の場合の図６を例にとってみる。ここでは、Ｖ１に対してＶ２では、列ｆが追加されている。また、その追加方法は列追加・子データベース方式によるものである。これらの、列を追加すること、および列を追加する方式の決定は、システム管理者が行うべき事項である。列を追加すること、および列を追加する方式がシステム管理者によって決定されて、データベース・システムに通知されると、データベース・システムでは次のようにして、Ｖ２のデータベース定義体の作成と、必要あればＶ１の変更を行う。図６の場合は、Ｖ１の変更は無い。

Ｖ２では、ＤＢ＿Ａに格納されているレコードに対して、列ｆを追加する。また、列追加・子データベース方式で行うことが、システム管理者から通知されている。これに基づき、新たにデータベースを作成する必要があることが判定できる。また、追加する列ｆは主キー項目ではないため、列ｆのみではデータベースを構成し得ないことも判定できる。ここから、新たなデータベースＤＢ＿Ａ１は、ＤＢ＿Ａの列ａと列ｆを組み合わせたレコードによって構成されることが判定できる。また、従来からあるＤＢ＿Ａ自体は、何らの変更を受けないことが判定できる。このようにして、Ｖ２のデータベース定義体を作成することができる。

次に、上記のＶ２のデータベースを、再編成して一つのデータベースにまとめる場合の定義体の作成方法に関して説明する。これは、図３９、図４１、図４２、図４３が対応する。再編成を行うことは、条件を予め設定しておくことにより自動的に開始することも可能であるし、システム管理者の指示によって開始することも可能である。
再編成が開始する前に必要なデータベース定義体を作成する必要がある。この場合の論理を次に説明する。Ｖ２のデータベース２つを、再編成を行って１つにするのであるから、データベース定義体の変更が必要であることはすぐに判定できる。これをＶ３とする。Ｖ３では、２つであったデータベースが１つになるが、論理的にはＶ２と変わらない。論理構造は、Ｖ２をそのまま引き継ぐ。物理的には、列ｂが外出しになっていたのが、新規レコードには含まれることになる。子データベースは不要となり、物理レコードも一つとなる。

以上のように、データベース定義体の各バージョンは、論理的に作成することが可能である。新たなバージョンの作成は、その直前のバージョンのデータベース定義体と、新たなバージョンを作成するためにシステム管理者によって与えられる情報、つまり変更情報（差分情報）を適用する。新たなバージョンが作成された後で、それ以前のバージョンを修正する方法は、新たなバージョンと以前のバージョンとの差分を、以前の各データベース定義体に反映させていくことで実行できる。また、これまでに説明してきたように、列状況欄を設けて、バージョン毎の履歴と、構成変更の情報を持ち、以前のデータベース定義体を修正して保有しておく事により、最新のバージョンの形で作成されているデータベースを、以前のデータベース定義体で検索・更新・追加・削除が可能である。

論理構造変換テーブルの作成方法は、まず、変換対象となる列を定める。最新の論理構造変換テーブルがデータベース定義体Ｖ４までを対称としたものであり、データベース定義体Ｖ５を新たに作成する場合を例にとって説明する。論理構造変換テーブルは１つの世代のみを保有すればよいが、説明の都合上、データベース定義体Ｖ４までを対称とした論理構造変換テーブルをＶ４、データベース定義体Ｖ５までを対称とした論理構造変換テーブルをＶ５とする。この場合には論理構造変換テーブルＶ４に対して、データベース定義体Ｖ５で列追加される場合には、その追加列を、論理構造変換テーブルの列に加える。列が過去非保持型によって削除される場合は、論理構造変換テーブルの列から削除する。その上で、データベース定義体Ｖ５の論理構造部分を、論理構造変換テーブルＶ５の右側（図面上）に加える。

上記では、最新のバージョンのデータベース定義体から新たなデータベース定義体を作成する方法に関して述べたが、この他に任意のバージョンのデータベース定義体から新たなデータベース定義体を作成することが可能である。図５６は、Ｖ３を元にしてＶ５とＶ６が作成された状態を示している。これは、例えばＥＤＩ（電子商取引）などにおいて、基本的な項目を定めて運用している場合に、特定の取引先に関して特定の情報を追加することが必要になった場合などに有効である。総てのレコードやプログラムを、それらの特定の情報に対応するように変更することは、格納領域の無駄やアプリケーション・プログラムの変更の手間を必要とする。しかしながら、例えば列追加を過去非遡及型で実施し、取引先に合わせて、Ｖ３の形式（基本的な取引先）、Ｖ４の形式（特定の取引先Ｘ）、Ｖ５の形式（特定の取引先Ｙ）、Ｖ６の形式（特定の取引先Ｚ）などとすることにより、格納領域を最小限とし、アプリケーション・プログラムの変更も最小限とすることが可能となる。

以上では、変更する部分の指示をシステム管理者が行う方法に関して説明した。しかしながら、ＸＭＬのような形式の文書では、システム管理者が、その文書が新しい形式であるか否かを判定し、新しいバージョンを定めることが困難となる場合も想定される。このような場合には、データベースへの書き込み時に、リクエスト処理要求受付を行うが、そのステップ内に、タグ情報の検査を行うステップを挿入し、既存のデータベース定義体に合致しているか、それとも新しいデータベース定義体を必要とするか、を判定する。この判定に基づき、列が追加されている場合には、新しいデータベース定義体を作成する。追加列の挿入場所に関しては、そのタグが順序を持っている場合はそれに従う。

以上のように、列の追加・変更を動的に行うことができることを説明した。これを応用することにより、次のような使用法が可能となる。ロボットのように、所与条件によって学習を行い、結果をデータとして保存し、次回以降の動作を円滑にするような仕組において、所与条件が増加するとか、学習の結果、項目が増加する、といったことが頻繁に起こり得る。このような場合に、プログラム自身が、列の追加・削除を自動的に実施し、データベースを自動的に新しくしていき、データベースの内容を更新していくようにすることが可能となる。

データベース定義体は、各々の使用状況を統計的に見ることが出来るように、各々に使用回数、作成日、最終変更日、最終使用日などの情報を格納できるようなエリアを設け、データベース・システムによって、それらの項目がメンテナンスされることが好ましい。更には、個々のデータベース定義体を使用しているプログラム名や使用日時などを保持することは更に好ましい。この機能により、古いバージョンのデータベース定義体が使用されているのかいないのか、といった判定をすることが可能になり、一定期間以上使用されていないバージョンのデータベース定義体および、そのデータベース定義体によって保持されているデータを削除することが可能となる。（発明の効果）

データベースにおいて、列の追加、削除、変更を行う場合に、データベースを稼動したままでそれらの作業を行うことが可能となる。また、列の追加、削除、変更を行っても、アプリケーション・プログラムを変更せずに稼動することが可能となる。

Claims (19)

1. データを格納し、検索するデータベース・システムにおいて、
   或るバージョンのデータベース定義体により定義されたレコードを、別のバージョンのデータベース定義体により定義されたレコードに変換する構造変換部と、
   或る１種類のテーブルのレコードに対して複数のバージョンのデータベース定義体と、
   そのデータベース定義体により定義された複数のバージョンのレコードを格納するデータ格納部と、を備えたデータベース・システム。
2. 請求項１に記載のデータベース・システムにおいて、
   データベース定義体により定義されたレコードを、そのデータベース定義体に振り分ける手段、を備えたデータベース・システム。
3. 請求項１に記載のデータベース・システムにおいて、
   或るデータベース定義体によって定義されたレコードに対応した要求元からのアクセス要求に対して、その要求元が要求しているデータベース定義体によって定義されたレコードに変換する手段、を備えたデータベース・システム。
4. データを格納し、検索するデータベース・システムにおいて、
   或るバージョンのデータベース定義体により定義されたレコードを、別のバージョンのデータベース定義体により定義されたレコードに変換する構造変換部と、
   或る１種類のテーブルのレコードに対して単一のバージョンのデータベース定義体と、
   そのデータベース定義体により定義された単一のバージョンのレコードを格納するデータ格納部と、を備えたデータベース・システム。
5. 請求項１に記載のデータベース・システムにおいて、
   前記レコードは、主キー項目を含むデータ項目を持ち、
   データレコードを主キーの順に格納するプライマリー・ブロックとオーバーフロー・ブロックと、
   プライマリー・ブロックのアドレスを格納するロケーション・テーブル・レコードと、
   ロケーション・テーブル・レコードを主キーの順に格納するロケーション・テーブルと、
   ロケーション・テーブルの使用領域の最後を示す最終ポインターと、
   追加列と主キーとからなる子レコードを格納する、子プライマリー・ブロックと子オーバーフロー・ブロックと、
   子プライマリー・ブロックのアドレスを格納する子ロケーション・テーブル・レコードと、
   子ロケーション・テーブル・レコードを主キーの順に格納する子ロケーション・テーブルと、
   子ロケーション・テーブルの使用領域の最後を示す最終ポインターと、を備えたデータベース・システム。
6. 請求項４に記載のデータベース・システムにおいて、
   前記レコードは、主キー項目を含むデータ項目を持ち、
   データレコードを主キーの順に格納するプライマリー・ブロックとオーバーフロー・ブロックと、
   プライマリー・ブロックのアドレスを格納するロケーション・テーブル・レコードと、
   ロケーション・テーブル・レコードを主キーの順に格納するロケーション・テーブルと、
   ロケーション・テーブルの使用領域の最後を示す最終ポインターと、
   追加列と主キーとからなる子レコードを格納する、子プライマリー・ブロックと子オーバーフロー・ブロックと、
   子プライマリー・ブロックのアドレスを格納する子ロケーション・テーブル・レコードと、
   子ロケーション・テーブル・レコードを主キーの順に格納する子ロケーション・テーブルと、
   子ロケーション・テーブルの使用領域の最後を示す最終ポインターと、
   列操作ポインターと、を備えたデータベース・システム。
7. 請求項５又は請求項６に記載のデータベース・システムにおいて、
   オーバーフロー・ブロック管理テーブルと、
   オーバーフロー・ブロック管理テーブル・ポインターと、を備えたデータベース・システム。
8. 請求項１又は請求項４に記載のデータベース・システムにおいて、
   主キー項目を含むデータ項目を持つデータレコードと、
   データレコードを主キーの順に格納するプライマリー・ブロックとオーバーフロー・ブロックと、
   プライマリー・ブロックのアドレスを格納するロケーション・テーブル・レコードと、
   ロケーション・テーブル・レコードを主キーの順に格納するロケーション・テーブルと、
   ロケーション・テーブルの使用領域の最後を示す最終ポインターと、
   列追加後のレコードが格納されたプライマリー・ブロックのアドレスを格納する新規ロケーション・テーブル・レコードと、
   新規ロケーション・テーブル・レコードを主キーの順に格納する新規ロケーション・テーブルと、
   新規ロケーション・テーブルの使用領域の最後を示す最終ポインターと、を備えたデータベース・システム。
9. 請求項８に記載のデータベース・システムにおいて、
   現用ロケーション・テーブル用列操作ポインターと、
   新規ロケーション・テーブル用列操作ポインターと、
   列操作完了ポインターと、を備えたデータベース・システム。
10. 請求項８に記載のデータベース・システムにおいて、
    現用オーバーフロー・ブロック管理テーブルと、
    現用オーバーフロー・ブロック管理テーブル・ポインターと、
    新規オーバーフロー・ブロック管理テーブルと、
    新規オーバーフロー・ブロック管理テーブル・ポインターと、を備えたデータベース・システム。
11. 請求項５又は請求項６に記載のデータベース・システムにおいて、
    新規ロケーション・テーブルと、
    新規ロケーション・テーブルの使用領域の最後を示す新規最終ポインターと、
    現用ロケーション・テーブル用の列操作ポインターと、
    新規ロケーション・テーブル用の列操作ポインターと、を備えたデータベース・システム。
12. 請求項１に記載のデータベース・システムにおいて、
    主キー項目を含むデータ項目を持つデータレコードと、
    データレコードを主キーの順に格納するプライマリー・ブロックとオーバーフロー・ブロックと、
    プライマリー・ブロックのアドレスを格納するロケーション・テーブル・レコードと、
    ロケーション・テーブル・レコードを主キーの順に格納するロケーション・テーブルと、
    ロケーション・テーブルの使用領域の最後を示す最終ポインターと、
    削除列と主キーとからなる子レコードを格納する、子プライマリー・ブロックと子オーバーフロー・ブロックと、
    子プライマリー・ブロックのアドレスを格納する子ロケーション・テーブル・レコードと、
    子ロケーション・テーブル・レコードを主キーの順に格納する子ロケーション・テーブルと、
    子ロケーション・テーブルの使用領域の最後を示す最終ポインターと、を備えたデータベース・システム。
13. 請求項１２に記載のデータベース・システムにおいて、
    オーバーフロー・ブロック管理テーブルと、
    オーバーフロー・ブロック管理テーブル・ポインターと、を備えたデータベース・システム。
14. 請求項１又は請求項４に記載のデータベース・システムにおいて、
    主キー項目を含むデータ項目を持つデータレコードと、
    データレコードを主キーの順に格納するプライマリー・ブロックとオーバーフロー・ブロックと、
    プライマリー・ブロックのアドレスを格納するロケーション・テーブル・レコードと、
    ロケーション・テーブル・レコードを主キーの順に格納するロケーション・テーブルと、
    ロケーション・テーブルの使用領域の最後を示す最終ポインターと、
    列削除後のレコードが格納されたプライマリー・ブロックのアドレスを格納する新規ロケーション・テーブル・レコードと、
    新規ロケーション・テーブル・レコードを主キーの順に格納する新規ロケーション・テーブルと、
    新規ロケーション・テーブルの使用領域の最後を示す最終ポインターと、を備えたデータベース・システム。
15. 請求項１４に記載のデータベース・システムにおいて、
    現用オーバーフロー・ブロック管理テーブルと、
    現用オーバーフロー・ブロック管理テーブル・ポインターと、
    新規オーバーフロー・ブロック管理テーブルと、
    新規オーバーフロー・ブロック管理テーブル・ポインターと、を備えたデータベース・システム。
16. 請求項１又は請求項４に記載のデータベース・システムにおいて、
    主キー項目を含むデータ項目を持つデータレコードと、
    データレコードを主キーの順に格納するプライマリー・ブロックとオーバーフロー・ブロックと、
    プライマリー・ブロックのアドレスを格納するロケーション・テーブル・レコードと、
    ロケーション・テーブル・レコードを主キーの順に格納するロケーション・テーブルと、
    ロケーション・テーブルの使用領域の最後を示す最終ポインターと、
    フランド・ロケーション・テーブルと、
    フランド・ロケーション・テーブルの使用領域の最後を示すフランド最終ポインターと、
    フランド列操作ポインターと、
    フランド列操作完了ポインターと、を備えたデータベース・システム。
17. 請求項１又は請求項４に記載のデータベース・システムにおいて、
    代替キー値と主キー値からなる代替キー・レコードと、
    代替キー・レコードを代替キーの順に格納する代替キー・ブロックと代替キー・オーバーフロー・ブロックと、
    代替キー・ブロックのアドレスを格納する代替キー・ロケーション・テーブル・レコードと、
    代替キー・ロケーション・テーブル・レコードを代替キーの順に格納する代替キー・ロケーション・テーブルと、
    代替キー・ロケーション・テーブルの使用領域の最後を示す最終ポインターと、
    フランド代替キー・ロケーション・テーブルと
    フランド代替キー・ロケーション・テーブルの使用領域の最後を示すフランド代替キー最終ポインターと、
    フランド列操作ポインターと、
    フ ランド列操作完了ポインターと、を備えたデータベース・システム。
18. 請求項１又は請求項４に記載のデータベース・システムにおいて、
    レコードの一部またはレコード外に、そのレコードが作成されたデータベース定義体のバージョン情報を保持するデータベース・システム。
19. 請求項１又は請求項４に記載のデータベース・システムにおいて、
    任意のバージョンのデータベース定義体に対して変更を加えることにより、新たなバージョンのデータベース定義体を作成するデータベース・システム。
    
    

Images