JP2002202904A

JP2002202904A - データ管理方法およびコンピュータ読み取り可能な記録媒体

Info

Publication number: JP2002202904A
Application number: JP2001335175A
Authority: JP
Inventors: Mutsumi Fujiwara; 原睦藤; Etsuo Saito; 藤悦生斉
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2000-10-31
Filing date: 2001-10-31
Publication date: 2002-07-19
Anticipated expiration: 2021-10-31
Also published as: JP3980326B2

Abstract

(57)【要約】【課題】種々の形式のデータを柔軟かつ動的に扱うこ
とができ、しかも効率的な検索・更新を可能にする。【解決手段】アドレスで識別される複数の記憶領域に
それぞれ別々のインデクスを対応付け、記憶領域へのア
ドレス値を含むレコードに対応するエントリを、含まれ
るアドレス値毎に対応付けて作成し、そのアドレス値で
識別される記憶領域に対応付けられたインデクスに登録
する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データ管理方法お
よびデータを管理するプログラムを格納したコンピュー
タ可能な記録媒体に関し、さらに詳細には、計算機など
の主記憶上に構成され、あるいは計算機などにおいて実
行可能な各種アプリケーションシステムにおいて用いる
のに好適なデータ管理方法およびコンピュータ読みとり
可能な記録媒体に関する。

【０００２】

【従来の技術】計算機を用いて実行されるアプリケーシ
ョンシステムにおいて、データベースは通信と並んで中
核技術に位置づけられ、特に性能や拡張可能性を決定す
る重要な要因となっている。現在、「データベース」と
いえば、ＯＯＤＢ（Object Oriented DataBase）なども
一部では利用されているが、通常はＲＤＢ（Relational
DataBase）をさすことが多い。

【０００３】ＲＤＢを始めとする従来のＤＢＭＳ（Data
Base Management System）は、「スキーマ」と呼ばれる
データ管理の枠組みを使っている。スキーマを用いた管
理とは、予めデータを組織化するための枠組み（スキー
マ）を決めておき、データを、スキーマを構成する「デ
ータ項目(attribute)」と呼ばれる単位データの集合に
基づいて、登録、更新、削除、検索を行うものである。
ＲＤＢにおいては、データを登録する枠組みは「テーブ
ル」、登録されるデータレコードは「タプル」と呼ばれ
る。

【０００４】スキーマは、１つのテーブルに登録される
複数のタプルの構成を１つに規定するものである。ユー
ザは予めスキーマを定めたいくつかのテーブルに、スキ
ーマによって定められた構成のタプルを登録したり、ス
キーマに規定された範囲内でタプルの内容を変更するこ
とによって、データの保存及び処理（更新）を行う。こ
のような方式においては、少数のテーブルのそれぞれに
同じ構成の多数のタプルを登録すれば事足りる場合以外
は、次に述べるような点でデータの保存及び処理が効率
的に行えないという問題がある。このため、効率低下が
著しく、実用に耐えないということも希ではなかった。

【０００５】まず、本来可変長であるデータを扱う必要
がある場合でも、データベース上ではそれを固定長のデ
ータとして扱わざるをえない。このため、データ保存の
ための記憶領域が増加したり、余計な処理手順が必要に
なったりする。例えば、一個人が複数の自動車を所有す
ることは珍しくないが、長大な個人情報のレコードの一
部にこのような同種のデータが不定個数含まれる場合、
従来のデータベースでこれを扱うには次のような方法が
一般的である。

【０００６】（１）不定個数の最大値を想定してその
数だけデータ項目を備えたスキーマを使用する。

【０００７】（２）そのデータ項目を１個としたスキ
ーマを使用し、そのデータ項目の値を複数含むようなデ
ータを扱う場合は、そのデータ項目の値のみが異なり、
他のデータ項目の値は同一のタプルを複数登録する。

【０００８】（１）の方法は空値を含むタプルを登録す
るという点で効率を低下させるおそれがある。（２）の
方法もまた、１つのデータ項目を除いて他が全て同じタ
プルを重複して登録するという点で効率を低下させるお
それがある。これらの効率の低下を防ぐには、空値や重
複を効率良く圧縮する特別な手段を追加する必要があ
る。

【０００９】特に、そのようなデータ項目が複数種類
（例えば自動車だけでなく、保険契約も）１つのデータ
（個人情報）に含まれる場合、（２）の方法による効率
低下は顕著になる。これを避けるために、不定（可変）
個数のデータ項目は別のテーブルとし、そのテーブルの
タプルと元のタプルとの関連を、両者に共通のユニーク
な識別子データを含ませることによって実現する。この
ような場合に、本来のデータには無かった余分な識別子
データ項目が導入されることがある。

【００１０】

【発明が解決しようとする課題】このような扱いの問題
点は、本来ひとまとまりとして扱うべきデータが複数の
テーブルに分散してしまう上に、それらを相互にアクセ
スするためには識別子をキーとする検索というコストが
かかる操作を要することである。

【００１１】（１）の方法に関しても、効率低下だけで
なく想定した最大値をさらに越えた数の同種データを含
むデータを扱う必要が生じた際に、スキーマを変更して
データベースを再生成しなければならないという別の問
題点がある。このような場合に限らず、スキーマを用い
る従来のデータベースではスキーマの変更を伴うような
アプリケーションの拡張・変更に際しては、アプリケー
ションへのサービスを停止してデータベースを再生成す
る必要があるので、連続稼働を要求されるアプリケーシ
ョンシステムの随時拡張は困難であった。

【００１２】以上説明したように、これらの問題は全て
スキーマに起因して生じるものである。

【００１３】本発明は、以上詳述した課題の認識に基づ
いてなされたものであり、その目的は、データベースを
作成してアプリケーションへのサービスを開始した後
に、当初の想定と異なる形式のデータを扱う必要が生じ
た場合でも、アプリケーションへのサービスを中断する
こと無く柔軟かつ効率的にデータベースの拡張を行うこ
とができるデータ管理方法を提供することにある。

【００１４】

【課題を解決するための手段】上記目的を達成するため
に、本発明の一態様のデータ管理方法は、アドレスで識
別される複数の記憶領域にそれぞれ別々のインデクスを
対応付け、記憶領域へのアドレス値を含むレコードに対
応するエントリを、含まれるアドレス値毎に対応付けて
作成し、そのポインタで識別される記憶領域に対応付け
られたインデクスに登録することを特徴とする。

【００１５】なお、前記インデクスは前記エントリをソ
ートして管理し、前記エントリのソート順を決定するキ
ーとして、前記エントリを対応付けたアドレス値を含む
レコードの内容を使用しても良い。

【００１６】なお、前記エントリのソート順を決定する
キーは、エントリ毎に指定しても良い。

【００１７】なお、前記エントリのソート順を決定する
キーとして、前記エントリを対応付けたアドレス値を含
むレコードに含まれる他のアドレス値で指示される記憶
領域の内容を使用しても良い。

【００１８】なお、前記エントリのソート順を決定する
キーとして、前記エントリを対応付けたアドレス値を含
むレコードに含まれる他のアドレス値そのものを使用し
ても良い。

【００１９】なお、前記アドレス値を含むレコードの更
新に伴って、前記インデクス中のエントリの各キーがソ
ート順に矛盾しないように必要に応じてエントリの順序
を修正しても良い。

【００２０】なお、前記アドレス値の参照先記憶領域の
内容の更新に伴って、前記インデクス中のエントリの各
キーがソート順に矛盾しないように必要に応じてエント
リの順序を修正しても良い。

【００２１】なお、指定されたキーでインデクスを検索
するようにしても良い。

【００２２】なお、指定した内容を持つ前記記憶領域を
決定し、その記憶領域に対応付けられた前記インデクス
を検索しても良い。

【００２３】なお、前記インデクスを検索した結果得ら
れたエントリを対応付けたアドレス値を含むレコードに
含まれる他のアドレス値の参照先記憶領域に対応付けら
れたインデクスを更に検索しても良い。

【００２４】さらに、これらのデータ管理方法を実行可
能な各種の形態のソフトウエアも、本発明に含まれる。
さらに、これらのデータ管理方法を応用した各種のアプ
リケーションも、本発明に含まれるものである。

【００２５】ここで、「記録媒体」とは、例えば、ハー
ドディスク（ＨＤ）、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＯ
Ｍ、フレキシブル・ディスク（ＦＤ）やＣＤ−ＲＯＭな
どの他に、ＲＡＭやＲＯＭなどの各種メモリも含む。

【００２６】また、これらの媒体に記録されるべきプロ
グラムを暗号化したり、変調をかけたり、圧縮したよう
な状態で、イントラネットやインターネットなどの有線
回線や無線回線を介してあるいは記録媒体に格納して頒
布しても良い。

【００２７】以上説明したように、本発明は単位データ
を指示するアドレス値に対応するエントリを、単位デー
タに対応づけられたインデクスに登録することによっ
て、スキーマを用いることなく検索可能な形にデータを
組織化するものである。この方法を採用することによっ
て、固定的なスキーマを使用する従来のデータベースで
は扱うことが困難であった可変長のデータが容易に扱え
るようになるだけでなく、従来のデータベースではスキ
ーマの変更を伴うので非常に効率が悪かったデータ形式
の変更が、通常のデータ更新と同様の操作によって行う
ことができる。

【００２８】それ故、本発明によれば、データベースを
作成してアプリケーションへのサービスを開始した後
に、当初の想定と異なる形式のデータを扱う必要が生じ
た場合でも、データベースの再生成等によって、アプリ
ケーションへのサービスを中断すること無く柔軟かつ効
率的にデータベースの拡張を行うことができる。

【００２９】

【発明の実施の形態】以下、図面を参照しつつ本発明の
実施の形態について説明する。

【００３０】本発明は、データの構築単位（以下、イン
スタンスとも云う）として、その記号表現（コード）を
格納するための領域（セル）に、それに関連した複数の
インスタンスの間の関係をポインタの列で表すデータ
（ロウ）を格納する領域（ファサード）を付随させたデ
ータ構造を採用することによって、データの効率的な操
作（登録、更新、削除、検索）を実現するものである。

【００３１】図１は、セルの構造を表す概念図である。
セルは、同図に表したように、Ｃ、Ｃ^＋＋、Ｊａｖａ
（登録商標）などのプログラム言語における１次元配列
に相当する。セルに格納するコードには種々のデータの
「データ型」を用いることができる。

【００３２】データ型には、文字、ｂｙｔｅストリーム
データ、符号なし整数値（ビット長：８／１６／３２／
６４）、符号付き整数値（ビット長：８／１６／３２／
６４）、浮動小数点実数値、倍精度浮動小数点実数値、
などがある。以下の説明では、図１に例示したように、
セルの図表現を矩形により表し、セルに格納するコード
を矩形の中に記すことにする。セルはデータ管理技術一
般における「単位データ」すなわちデータ項目の個々の
値を格納する機能に相当する概念である。

【００３３】図２は、インスタンスの構成を表す概念図
である。セルとファサードは１つのインスタンスの構成
要素として同時に生成される。インスタンス（セルとフ
ァサード）はその領域を識別するアドレスで同定する。
セルに格納されたコードは単独でインスタンスを同定す
るものではないが、後述するようにレキシコンの中での
インスタンスの検索や、ファサードの中のロウの検索の
ように限定された文脈での識別に使用される。

【００３４】ファサードには後述するコンテクストを検
索するためのロウが登録される。ファサードはデータ管
理技術一般における「インデクス」に類する概念であ
り、ロウはそのインデクスに登録される「エントリ」に
対応する概念である。インスタンスは、データをコード
として格納する手段であるセルと、データ（インスタン
ス）間の関係をロウとして格納する手段であるファサー
ドを一体化したものである。本発明では、データの格納
手段（セル）とデータの管理手段（ファサード）とが一
つの構造（インスタンス）で扱われているので、ＲＤＢ
のようにデータ管理のための特別なデータ（テーブル）
のようなものがなくても、データを構造化することがで
きる。

【００３５】セルとファサードの図表現は、図２のよう
に、セルとファサードそれぞれを上下に連続した２つの
矩形により表現する。上部がセルで、下部がファサード
である。なお、セルにはファサードが必ず付随するが、
ファサードには必ずしもロウが登録されているとは限ら
ない。すなわち、空のファサードもありうる。ファサー
ドにロウが登録されているかどうかを区別するため、図
面においては、空のファサードと、ロウが登録されてい
るファサードとを適宜区別して表す。また、セル及びフ
ァサードはインスタンス作成時に予め固定の大きさの領
域を割り付ける必要がなく、格納されるコードの量やロ
ウの数に応じて記憶領域を割り付けるような実現方法を
とることも可能である。

【００３６】インスタンスは「レキシコン」により管理
される。すなわち、「レキシコン」とは、「データ集団
名」に相当する概念である。

【００３７】図３は、レキシコンにより管理されたイン
スタンス群を例示する概念図である。同図に例示したよ
うに、インスタンスは、必ずどこかのレキシコンに登録
される。レキシコンは、複数存在し、それらは「レキシ
コン・セット」により管理される。それぞれのレキシコ
ンには固有の名前が与えられており、この名前によって
レキシコン・セットから特定のレキシコンを検索でき
る。アプリケーションはその処理に必要なレキシコンを
その名前によってレキシコン・セットから検索し、次
に、そのレキシコンの下に管理されているセルをその内
容によって検索することにより、欲しいセルを得ること
ができる。

【００３８】図３は、レキシコン・セットから“従業
員”レキシコンを検索し、次に、"佐藤"インスタンスを
検索するプロセスを例示している。

【００３９】セルに格納するコードはそのセルのインス
タンスが所属するレキシコンの下には基本的には１つし
か存在しないものとすることができる。つまり、同じコ
ードを持つ別のインスタンスは存在せず、重複を許さな
いことを基本とすることができる。この場合には、レキ
シコン中という限定された範囲でセルのコードは、イン
スタンスを識別・検索するキーとして機能する。

【００４０】これに対して、セルの変数的な使い方もで
きる。この場合には、同じコードを異なるインスタンス
のセルに格納することも可能である。これは、アプリケ
ーションでどのようなデータを扱いたいかで決めれば良
い。例えば、人名には「同姓同名」が存在する（つまり
同姓同名で別人がある）が、それらを別物として管理し
たければ、同じコードではあるが別々のインスタンスの
セルに格納すれば良い。

【００４１】インスタンスがレキシコンに登録されただ
けでは、単に単位データがバラバラに存在するだけであ
り、セルの内容によりレキシコンから検索できるだけで
ある。

【００４２】図４は、ある従業員データを構成する個々
の要素をインスタンスとし、"従業員"レキシコンに登録
した状態を例示する概念図である。この状態では、イン
スタンスがバラバラにレキシコンに連なっているだけ
で、インスタンス同士の関連を扱うことはできない。デ
ータベースが通常扱うデータは、これら単位データを組
み合わせたり関連づけたりしたものである。ＲＤＢにお
けるタプルやファイルのレコードがこれに当たる。この
ようなデータの例として図２２に示すデータを使用し
て、インスタンス間の関連を扱う方法を説明する。

【００４３】すなわち、この図２２に示す例において
は、姓、入社年度、所属部門、役職、内線により区分さ
れた従業員の情報が与えられている。

【００４４】本発明によれば、このような管理すべきデ
ータが、図４に例示したようにバラバラにインスタンス
のセルに格納される。ここで、本発明の特徴のひとつ
は、重複したデータをひとつのセルで管理できる点にあ
る。例えば、図２２において、「入社年度」を見ると、
６名の従業員のうちの３名の入社年度は「１９８１」で
ある。このような場合に、本発明においては、「１９８
１」に対応する３つのデータを格納する必要がなく、図
４に例示したように、「１９８１」が格納されたセルを
有するインスタンスをひとつ管理すれば良い。後に詳述
するように、必要に応じて、このインスタンスを何回で
も指定できるからである。これは、「所属部門」や「役
職」に関する重複データについても同様である。本発明
によれば、このように重複するデータがある場合に、デ
ータ格納領域を大幅に節約できるという効果が得られ
る。

【００４５】次に、図４に表したように、"従業員"レキ
シコンに登録されているバラバラのデータを、図２２の
１行のデータ列、例えば「斎藤・１９８１・工場・課長
・３６９１」のような１つの意味のあるデータ群として
扱う方法手段として、本発明においては図５に示すよう
な「コンテクスト」という構造を用いる。コンテクスト
はデータ管理技術一般における「レコード」に類する概
念である。

【００４６】すなわち、「コンテクスト」は、インスタ
ンスを参照するポインタデータの１次元配列である。つ
まり、コンテクストにはデータの実体（コード）は格納
されず、コードを管理するインスタンスを指し示すポイ
ンタが格納される。この実施形態においては、インスタ
ンスが格納される各領域のアドレスが、インスタンスに
対するポインタとして用いられる。コンテクストは、関
連させたい複数個のセルのインスタンスを指定するよう
に形成される。そして、コンテクストに格納されている
ポインタデータから、セルを参照することができる。

【００４７】本発明において、リンクを図表現する際
は、セル同様矩形で表し、ポインタの指し示すセル
を（）で囲ってポインタ表現とする。例えば、（斎藤）
は、斎藤という内容を持つセルのインスタンスを参照す
るポインタを表す。

【００４８】コンテクストによって、インスタンスに格
納された要素データ間の関係を表すが、データの関連性
は、図２２のような設計データの静的な関連だけでな
く、アプリケーションが必要とする検索方式にも依存す
る。従って、コンテクストは、アプリケーションにおけ
る設計データを基にアプリケーションが必要とする検索
方式を加味して構成することになる。

【００４９】図６は、設計データとコンテクストとの関
係を表す概念図である。

【００５０】また、図７は、コンテクストを構成する処
理手順を表すフローチャートである。

【００５１】図６に表した例では、図６（ａ）の表の設
計データを２種類の検索パターンで検索するアプリケー
ションを開発したいとする。これをデータ管理装置で実
装するには、まず２種類の検索パターンを表現するデー
タを設計データに追加する必要がある。このデータは、
後で説明するように、「ファサード」として機能するこ
とになる。このために、まず、図７にステップＳ１及び
Ｓ２として表したように、検索パターンのそれぞれにフ
ァサード名を割り当てる。例えば、２つの検索パターン
にそれぞれ”分類１”と、”分類２”という名前を付け
る。さらに、図４に表したように、これら検索パターン
のデータ（「分類１」と「分類２」）をレキシコンにも
追加しておく。

【００５２】次に、ステップＳ３において、元の設計デ
ータの１行のデータを取り出す。そして、ステップＳ４
において、検索パターンのファサード名を各行のデータ
列に追加する。この段階では、１行のデータは実体コー
ドのデータ列である。この実体コードのデータ列を、コ
ードを管理するインスタンスを指し示すポインタ列に置
き換えるとコンテクストができあがる。これらの処理は
ステップＳ５により、検索パターンの数だけ繰り返し、
さらにステップＳ６により、設計データの行数だけ繰り
返す。

【００５３】この例では、図６（ｂ）に表したように、
設計データに対応した６種類のコンテクストができる。

【００５４】次に、複数のコンテクストを纏めたり、そ
れらを検索したりできるように、コンテクストの複数の
要素（ポインタ）を選択して並べ替えたもの（コンテク
ストの要素の順列）を、「ロウ」としてその先頭の要素
が参照するインスタンスのファサードに登録する。

【００５５】なお、コンテクストもロウも、それぞれ個
別にアドレスを持っており、インスタンス同様にアドレ
スで（ポインタとして）アクセスすることができる。そ
して、データ管理装置による検索などの処理結果の戻り
値にこれらのアドレスを用いる。

【００５６】ロウとその元になったコンテクストとは、
ポインタで関連付けておき、ロウの各要素とコンテクス
トの各要素との対応関係が相互に決定できるようにす
る。ファサードにロウを登録する際には、先頭から何番
目の要素までを連結キーとしてファサード内のロウの順
序付け（ソーティング）に使用するかを指定する。

【００５７】「連結キー」とは、優先順位付きのキー
（この場合はロウ（コンテクスト）の要素）の集まりで
ある。連結キー同士の比較においては、上位のキーが全
て同一の場合に限り、下位のキーの比較順序を連結キー
としての比較順序とする。それらが一致しない場合は、
一致しない上位のキー間の関係（順序）がそれらの間の
比較結果として取られる。各要素がキーとして比較され
る場合には、それらが参照するインスタンスのセルのコ
ードが比較される。

【００５８】図８は、ファサードに登録されたロウの一
例を表す概念図である。ポインタ（分類１）を格納した
要素を先頭とするロウがインスタンス”分類１”のファ
サードに登録されている。

【００５９】また、コンテクストをロウとしてファサー
ドに登録する際には、コンテクストのすべてのデータを
登録する必要はない。例えば、図８の例では”分類１”
ファサードに登録したロウには、他の検索で使用する”
分類２”は使う必要が無いので、”分類２”はロウには
含まれていない。さらにロウの全ての要素が連結キーと
して使用されるわけではなく、先頭から指定した個数だ
けが使用される。例えば、図８の例では、”分類１”フ
ァサード内の４番目のロウは、このロウに対応するコン
テクスト内に含まれる（１９８１）、（本社）をそれぞ
れ第１キー、第２キーとして用い、ロウの残りの要素は
ファサード内のロウのソート順には関係しない。

【００６０】以上の説明から分かるように、ロウはコン
テクストを元にしてファサードに登録されるが、その内
容はロウとして登録する際に指定した順序で以下の如く
並びかえられたものである。

【００６１】コンテクスト：(分類1)(分類2)(佐藤)(1981)(本社)(課長)(6354) ↓ ロウ：(分類1)(1981)(本社)(佐藤)(課長)(6354) ロウの（分類１）は登録ファサードを、(１９８１)は第
１キーを、(本社)は第２キーを、それぞれ示し、(佐藤)
(課長)(6354)はキーとして使用されない以上で説明した
データ管理方式の実現方法であるが、例えばこの構造、
特にファサード−ロウの部分を、スプレイ・ツリー・ア
ルゴリズムで実装することが考えられる。なお、スプレ
イ・ツリー・アルゴリズムについて開示した文献として
は、例えば、Robert E. Tarjan, "Data Structure and
Network Algorithms", the Society for Industrial an
d Applied Mathematics,1983 を挙げることができる。
スプレイ・ツリー・アルゴリズムは、動的に変化する２
分木で、データアクセスが発生する毎にスプレイ操作を
実行する。

【００６２】図９は、スプレイ・ツリー・アルゴリズム
におけるスプレイ操作を例示する概念図である。図９に
おいて、スプレイ操作は、次のようなステップで行う。
例えば、検索処理を行うとルートからノードを検索キー
と比較しながら降りてきて、最終的に検索対象に到達す
る。そのノードを（ｘ）とすると、（ｘ）の前後のツリ
ーの構造が図９に表した３種類のパターンのいずれかに
該当するので、それを選んでツリーの構造を変える。こ
の処理で、（ｘ）はツリーの構造を１段上がることにな
るが、今度は新しい位置で、再度（ｘ）の前後のツリー
構造を見て図９のいずれかの構造を選び、同様に処理す
る。この処理を続けると、最終的にはツリーのルート
（頂点）に到達する。

【００６３】このようなスプレイ操作を通じて、偏りの
あるデータアクセス適応して効率的に検索・更新を処理
する２分木ができる。これをファサードにおけるロウの
管理に用いることでデータを、効率的にソートして管理
することができる。

【００６４】スプレイ・ツリー・アルゴリズム以外にも
ソートされたデータの管理法は各種知られているが、こ
れらのデータ管理方式を用いても同様の効果を得ること
ができる。本発明においては、図１乃至図８に関して前
述したデータ管理構造の方式が本質的な部分であり、物
理的な実装方式には依らずに上記効果を発揮することが
できる。

【００６５】（具体例）以下、具体的なデータに即し
て、データの登録及び検索の方法を具体的に説明する。

【００６６】まず、本実施例における問題設定を説明す
る。扱いたいデータは、図２２に表した従業員データで
ある。

【００６７】データ項目は、「姓」、「入社年度」、
「所属部門」、「役職」、「内線」の５種類であり、全
部で６件のデータからなる。本実施例では、このような
データを２種類の検索パターンで分類する。第１の検索
パターンは、入社年度を第１キーに、所属部門を第２キ
ーにするもので、第２の検索パターンは内線を第１キー
にするものである。

【００６８】以下、各データに関してコンテクストから
どのようにロウが形成され、どのようにファサードに登
録されるかを説明する。

【００６９】図１０は、本実施例におけるデータ管理方
法の手順を表すフローチャートである。

【００７０】まず、最初に、ステップＳ１１において、
設計データを構成するインスタンスをレキシコンに登録
する。図１１は、インスタンスがレキシコンに登録され
た状態を表す概念図である。図示した如く、レキシコン
とインスタンスのツリーができあがる。

【００７１】次に、ステップＳ１２においてコンテクス
トを形成する。本実施例におけるコンテクストは、例え
ば、図１１の右下に表したようになる。

【００７２】次に、ステップＳ１３において、これらの
コンテクストからロウを形成し、これを所定のファサー
ドに登録する。本実施例においては、コンテクスト
は、”分類１”と”分類２”のそれぞれのインスタンス
のファサードに、図１２及び図１４に表された検索パタ
ーンで登録される。

【００７３】具体的には、まず、最初に、図１２に表し
たように、”分類１”ファサードに、同図に表した検索
パターンに従ったロウを登録する。

【００７４】その結果、図１３に表したように、”分類
１”ファサードには１件のロウが登録される。すなわ
ち、コンテクストから、登録ファサード、第１キー、第
２キー、その他の順に要素を選択して並べたロウを作成
して登録する。

【００７５】コンテクスト：(分類1)(分類2)(佐藤)(1981)(本社)(課長)(6354) ↓ ロウ：(分類1)(1981)(本社)(佐藤)(課長)(6354) なお、ここで、(分類２)がこのロウには含まれないこ
と、及び、先頭の(分類１)がロウの登録ファサードのイ
ンスタンスを参照していることに注意されたい。この登
録の結果として、”分類１”ファサードには１件のロウ
が登録されるが、その他のインスタンスのファサードは
相変わらず空のままである。

【００７６】次に、ステップＳ１４において上述のロウ
登録操作を検索パターンの数だけ繰り返す。

【００７７】具体的には、図１４に表したように、”分
類２”ファサードにロウを登録する。この際には、同図
に表したキー順位で登録する。その結果、”分類２”フ
ァサードには１件のロウが図１５のように登録される。
すなわち、コンテクストから、登録ファサード、第１キ
ー、第２キー、その他の順に要素を選択して並べたロウ
を作成して登録する。

【００７８】コンテクスト：(分類1)(分類2)(佐藤)(1981)(本社)(課長)(6354) ↓ ロウ：(分類2)(6354)(佐藤)(本社)(課長) ここでも、”分類１”ファサードへの登録と同様に、
(分類１)および(1981)がこのロウには含まれないこと、
及び、先頭の(分類２)がロウの登録先ファサードのイン
スタンスを参照していることに注意されたい。この登録
の結果として、”分類１”ファサードと”分類２”ファ
サードにはそれぞれ１件のロウが登録されるが、その他
のインスタンスに付随するファサードは空のままであ
る。

【００７９】以下、ステップＳ１５において、上述のコ
ンテクスト形式（ステップＳ１２）以降の処理をコンテ
クストの件数、すなわちデータの件数だけ繰り返す。

【００８０】まず、２番目のコンテクストを、前と同様
に”分類１”ファサードと”分類２”ファサードに登録
する。図１６は、このようにしてそれぞれのファサード
に２件のロウが登録された状態を表す概念図である。ロ
ウはそれぞれのファサードで連結キー順にソートされて
いる。

【００８１】以下、このようにして６件すべてのデータ
のコンテクストを形成し、それぞれを検索するためのロ
ウをファサードに登録する。図１７は、６件のコンテク
ストと１２件のロウが登録された状態を表す概念図であ
る。これですべてのデータが登録され、検索の準備がで
きたことになる。

【００８２】次に、本発明のデータ管理方法における検
索手順について説明する。

【００８３】図１８は、本検索手順を表すフローチャー
トである。

【００８４】また、図１９は、本検索手順を説明するた
めの概念図である。

【００８５】本発明においては、検索のために、まずス
テップＳ２１において、検索したいパターンに対応する
ファサードを検索する。具体的には、まず最初に、与え
られたレキシコン・セットから、アプリケーションの処
理に必要となるレキシコンをその名前により検索する。
例えば、本実施例の場合は、"従業員"レキシコンを検索
する。

【００８６】次に、必要とするデータをそのレキシコン
において検索する。最初にファサードを探してこなくて
はならないが、これは上記ファサードを含むインスタン
スをレキシコンから探せば良い。本実施例では、”分類
１”インスタンスを、コード”分類１”をキーとしてレ
キシコンから検索してくる。

【００８７】次に、ステップＳ２２において、ファサー
ド内に登録されているロウを所望のキーで検索する。本
実施例の場合は、第１キー＝”１９８１”、第２キー
＝”本社”により検索して所望のロウを獲得する。

【００８８】次に、ステップＳ２３において、ロウの中
の要素から所望のインスタンスを、ポインタを参照する
ことにより求める。すなわち、得られたロウの中からア
プリケーションで必要なデータを見つけ出す。例えば、
本具体例においては、検索されたデータの「姓」の項が
欲しいので、ロウ内の４番目の要素であるポインタが指
し示すインスタンスのセルから、所望のデータである”
佐藤”を得る。

【００８９】以上説明した具体例の場合は、ロウから直
接セルを参照しているが、もっと複雑な検索の場合は、
コンテクストに溯って別なデータへアクセスしたりする
ことも可能である。いずれにしても、基本となる検索手
順はファサードからロウを確定することであり、これを
中心に検索処理を組み立てればよい。

【００９０】なお、上記説明では、”分類１”インスタ
ンスをレキシコンから検索して得たが、”分類１”イン
スタンスを得る方法は、これに限られるものではない。
例えば、”分類２”インスタンスのファサードからそこ
に登録されたエントリに対応するコンテクストを得、そ
のコンテクストの先頭要素を参照先として”分類１”イ
ンスタンスを得ることができる。すなわち、ファサード
は通常のデータ検索の手段によって決定することができ
るのであり、この点が、スキーマやメタデータの管理手
段が通常のデータ管理手段と別になっている従来のデー
タベースと根本的に異なっている。

【００９１】次に、本発明のデータ管理方法を実行可能
なデータ管理装置について説明する。

【００９２】図２０は、上述したデータ管理方法をハー
ドウェア上に実現したデータ管理装置の概観を例示する
鳥瞰図である。

【００９３】また、図２１は、その要部構成を例示した
ブロック図である。

【００９４】このデータ管理装置８０の本体は、データ
入力部８０Ａと、データ処理制御部８０Ｂと、データ記
憶部８０Ｃと、データ出力部８０Ｄと、を有する。

【００９５】データ入力部８０Ａは、管理すべきデータ
を外部から入力する役割を有し、その入力手段として
は、例えば、フレキシブルディスク装置（フレキシブル
ディスクドライブ）８１、光ディスク装置（光ディスク
ドライブ）８２などを具備している。フレキシブルディ
スクドライブ８１に対してはフレキシブルディスク８３
を、また光ディスクドライブ８２に対してはＣＤ−ＲＯ
ＭあるいはＤＶＤディスクなどの光ディスク８４をその
挿入口から挿入し、所定の読み出し操作を行うことによ
り、これらの記録媒体に格納されたデータをシステム内
に入力することができる。また、所定のドライブ装置を
接続することにより、例えば半導体メモリ装置としての
ＲＯＭ８５や、磁気テープ装置としてのカセットテープ
８６を用いることもできる。さらに、キーボード８７に
よりデータを入力したり、ネットワーク回線８８を介し
て、他のコンピュータあるいはデータ出力装置からデー
タを入力することもできる。

【００９６】このようにして入力されたデータは、デー
タ記憶部８０Ｃに格納される。この際に、図１乃至図１
９に関して前述したように、レキシコン・セット、レキ
シコン、セル、ファサード、コンテクスト、ロウなどが
適宜形成される。これら一連の処理は、データ処理制御
部８０Ｂにより実行される。また、ロウのソーティング
や、ファサードに格納されたデータのスプレイングも、
データ処理制御部８０Ｂにより実行される。

【００９７】このようにして管理され、ソートされたデ
ータは、必要に応じてデータ出力部８０Ｄにより出力さ
れる。データ出力部８０Ｄは、例えば、ディスプレイ８
９や、フレキシブルディスク８３などの各種の媒体、あ
るいはネットワーク回線８８を介して所望のデータを外
部に出力する。

【００９８】後に詳述するように、本発明においては、
データを格納するデータ記憶部８０Ｃとして、ＲＡＭな
どの半導体メモリを用いることができる。その結果とし
て、高速にデータを展開、管理することが可能となり、
データ管理の性能を従来よりも大幅に改善することがで
きる。

【００９９】なお、本発明は、図１乃至図１９に関して
前述したようなデータ管理方法が実行可能なソフトウエ
アも包含する。このようなソフトウエアは、データ読み
取り部８０Ａに関して前述したものと同様に、光ディス
ク８４などの記録媒体に格納して、管理装置８０のデー
タ処理制御部８０Ｂにダウンロードすることが可能であ
る。または、このようなソフトウエアは、ネットワーク
回線８８を介してダウンロードすることもできる。

【０１００】以上説明した本発明のデータ処理方法及び
データ処理装置の作用および効果を、引き続き実例デー
タに即して説明する。

【０１０１】まず、図２２において、扱うべきデータの
うち、”斉藤”について、電話番号”２４０６”が”３
６９１”に加えて割り付けられることになった場合につ
いて説明する。この状況は、例えば、図２３のように示
される。

【０１０２】本発明では、このように、データによって
要素の個数が異なる場合でも、全てのコンテクストの要
素数を最大個数に揃えたり、一部の要素だけが異なって
他は同一のコンテクストを複数作成したりしなくても良
い。また、１件のデータを複数のコンテクストに分割す
る必要もなく、それに伴う余分な識別データを追加する
必要もない。すなわち、”斉藤”のデータに対応するコ
ンテクストは、例えば図２４のように生成すれば良い。

【０１０３】本実施例では、ロウをコンテクストから作
成してファサードに登録する場合、ロウの登録ファサー
ドを決定するロウの先頭要素とコンテクストの要素は１
対１に対応するという制約がある。つまり、１つのコン
テクストから作成できるロウの数の上限はその要素数に
等しく、また、登録できるファサードは各要素が参照す
るインスタンスのファサードに限られる。そこで、同一
のファサードに複数のロウを登録したい場合には、同一
のインスタンスを参照する複数の要素を含ませる必要が
ある。この実例の問題設定では電話番号を第１キーとし
てデータが検索できなければならないから、電話番号を
２つ備えたデータについては、”分類２”ファサードで
２つの電話番号をそれぞれキーとするロウを登録する必
要がある。すなわち、”斉藤”のデータに対応するコン
テクストからは”分類２”ファサードに登録する２つの
ロウを作成する必要があるので、電話番号を”2406”を
参照する要素だけでなく、”分類２”インスタンスを参
照する要素がもう１つ追加されている。

【０１０４】この末尾に追加された（分類２）の要素を
先頭とするロウは、アプリケーションが必要とする図２
５に示す検索パターンに従って、図２６に示すように作
成する。この検索パターンは姓が単なる属性ではなく第
２キーに指定されている点で図１４に示す検索パターン
と異なっている。これは、”2406”を第１キーとするロ
ウが既にファサード中にあるので、これとの一意な識別
を可能にするために連結キーを追加したのである。これ
に対応して、既にファサード中に存在した”2406”を第
１キーとするロウについても、上記の新たに追加するロ
ウとの一意な識別を可能にするために、図３１に示す姓
を第２キーとする検索パターンに合致するようにロウの
連結キーの個数を変更する。

【０１０５】一方、同じく”分類２”ファサードに登録
するロウでも、”3691”を第１キーとするロウは、登録
前のファサードに”3691”を第１キーとするロウは含ま
れていないので、”3691”を第１キーとし他は単なる属
性とする図３０の検索パターンで生成したロウを登録す
れば一意に識別できる。これらのロウを登録及び修正し
た結果、”分類２”でファサードは図２７に示すように
なる。

【０１０６】また、”分類１”ファサードの各ロウに
は、対応するコンテクストに含まれる内線番号が要素と
して含まれている必要があるので、（分類１）を先頭と
するロウの検索パターンとしては、他のロウより要素が
１つ多い図３２の検索パターンからロウを生成する。

【０１０７】図２７には、”分類１”、”分類２”ファ
サード及びコンテクスト、レキシコンを含めて、実例デ
ータから本実施例のデータ管理方法で作成・登録された
データ構造が全て示してある。これをみると、”斉藤”
のデータのみ形式が異なる６件の入力データそれぞれに
対応して６つのコンテクストが作成されているので、元
のデータとデータベースに登録されたデータ（コンテク
スト）との対応関係は、良く保たれており、分割や複製
によって、対応付けに余分な手間がかかることはない。
更に、データの形式を一様にするために、空値の要素を
追加する必要もなく、元のデータの形式が不揃いならそ
れを保ったままデータベースに登録ができる。また、コ
ンテクスト毎にアプリケーションが必要とする検索パタ
ーンを自由に設定してロウをファサードに登録すること
ができるので、データ（コンテクスト）の形式・内容が
まちまちであっても、アプリケーションに必要な内容を
過不足無く検索できるようにデータベースにロウを登録
できる。上記の例に即して云えば、電話番号を２つ含む
データ（コンテクスト）はそれぞれの番号をキーとし
て、１つのファサードから検索できるようになってい
る。

【０１０８】さて、本発明においては、形式の異なるコ
ンテクストを、ロウを登録するという操作によって、フ
ァサード単位に組織するとともに、連結キーによる検索
の対象とすることができる。ファサードは、比較可能な
（比較してソートすることに意義がある）ほどに類似し
たデータをまとめることができるという点で、従来のＲ
ＤＢのテーブルやビューに相当する機能を保持する。し
かしながら、各ファサードにおいては、そこに登録され
るロウに関して、その先頭の要素がそのファサードのイ
ンスタンスを参照するコンテクストの要素であるという
こと以外は、何ら制約を設けない。したがって、従来の
データベースにおいて、データをまとめる機構に付随し
て必要であった、まとめられるデータの形式や内容に関
する制約情報（いわゆるスキーマ情報）を保存・管理す
る必要がない。このため、従来のデータベースでは、ス
キーマの変更として扱わざるを得ないような変更も、単
なるデータの変更として扱うことができるので、通常の
アプリケーションへのサービスを一旦停止して、データ
ベースを再生成するという特別な操作（アプリケーショ
ン）を行う必要がない。

【０１０９】上記の実例データに即して説明する。図２
８に示すような形式のデータのみが扱えればよいという
前提でデータベースを設計し、実際にデータベース（レ
キシコン、インスタンス、コンテクスト、及びロウ）を
生成してアプリケーションの用に供した後で、図２９に
示すように、内線番号が２つある別の形式のデータを扱
う必要が生じた場合を考える。

【０１１０】本発明のデータ管理方法では、この形式の
データから上記のコンテクストを生成してロウをファサ
ードに登録する手続を新たに用意する必要はあるもの
の、図２８のデータから生成された既存のデータベース
に、ほとんど変更を加える必要がない。もちろん、再生
成の必要もない。

【０１１１】以上説明したように、本発明のデータ管理
方法は、スキーマを用いる従来のデータベースでは、困
難であった不揃いな形式のデータの扱いや、データの形
式・内容の動的変更にも容易に対応できるデータ管理シ
ステムを提供することができる。更に、本発明のデータ
管理方法によれば、既に登録されているデータが更新さ
れている場合も、効率良くこれを処理することができ
る。単にデータを追加する場合については、データ登録
処理として既に述べた。ここでは、登録されているコン
テクストの一要素が変更される場合について説明する。

【０１１２】引き続き、上記の実例データに関して、コ
ンテクスト（分類１)(分類2)(斉藤)(1981)(工場)(課長)(3691)(240
6)(分類2) の（2406)が、インスタンス”2406”ではなく、インス
タンス”2409”を参照するように変更された場合を考え
る。この結果、コンテクストは、（分類１)(分類2)(斉藤)(1981)(工場)(課長)(3691)(240
9)(分類2) に変更される。これに伴って、ロウ (分類2)(2406)(斉藤)(工場)(課長) は、 (分類2)(2409)(斉藤)(工場)(課長) に変更されるので、”分類２”ファサード内でソート順
を維持するために、このロウを (分類2)(2409)(小林)(研究所)(部長) の直後に移動する。これに対して、第１キーが（2409）
のロウが２つになるが、このロウの一意な識別を可能に
するためには、（小林）を第２キーとするように連結キ
ーの個数を変更するだけでよい。同じコンテクストか
ら、作成された他の２つのロウ (分類2)(3691)(斉藤)(1981)(工場)(課長) (分類1)(1981)(工場)(斉藤)(課長)(3691)(2406) は、キーに変更が及ばないので、ファサード内の順序を
移動する必要がない。これらの判断及び操作は、コンテ
クストの各要素とそれを含むロウとの対応が管理されて
いるので効率よく行うことができる。

【０１１３】なお、コンテクスト（ロウ）の要素の参照
先を変更するのではなく、インスタンス”2406”のセル
の内容を”2406 ”から”2409”に変更した場合は、同
一のインスタンスを参照していた２つのロウ (分類2)(2406)(斉藤)(工場)(課長) (分類2)(2406)(藤原)(研究所)(主任) を同時に (分類2)(2409)(斉藤)(工場)(課長) (分類2)(2409)(藤原)(研究所)(主任) に変更することができ、”分類２”ファサードのロウの
順序はこれに応じて図３３に示すように変更される。こ
れらのロウの（2409）の参照先インスタンスは、 (分類2)(2409)(小林)(研究所)(部長) の（2409）の参照先インスタンスとセルの内容は同一で
も依然として異なるインスタンスである。”斉藤”と”
藤原”が１つの内線番号を共有している。これは、イン
スタンスがセルの内容ではなく、アドレスで識別される
ことによる効果である。

【０１１４】このように、既に登録されたデータの変更
を行う場合でもデータの部分的な修正で全て済ますこと
ができるので、多量のデータ登録のやり直しが必要にな
ることはない。

【０１１５】

【発明の効果】以上説明したように、本発明のデータ管
理方法によれば、種々の形式のデータを柔軟かつ動的に
扱うことができ、しかも効率的な検索・更新が可能であ
る。

【図面の簡単な説明】

【図１】本発明におけるセルの構造を表す概念図であ
る。

【図２】本発明におけるインスタンスの構造を表す概念
図である。

【図３】レキシコンにより管理されたインスタンス群を
例示する概念図である。

【図４】ある従業員データを構成する個々の要素をイン
スタンスとし、"従業員"レキシコンに登録した状態を例
示する概念図である。

【図５】コンテクストを説明するための概念図である。

【図６】設計データとコンテクストとの関係を表す概念
図である。

【図７】コンテクストを構成する処理手順を表すフロー
チャートである。

【図８】ファサードに登録されたロウの一例を表す概念
図である。

【図９】スプレイ・ツリー・アルゴリズムにおけるスプ
レイ操作を例示する概念図である。

【図１０】本発明の実施例におけるデータ管理方法の手
順を表すフローチャートである。

【図１１】インスタンスがレキシコンに登録された状態
を表す概念図である。

【図１２】”分類１”ファサードに、同図に表した構成
でロウを登録する様子を表す概念図である。

【図１３】”分類１”ファサードに１件のロウが登録さ
れた様子を表す概念図である。

【図１４】”分類２”ファサードにロウを登録する様子
を表す概念図である。

【図１５】”分類２”ファサードに１件のロウが登録さ
れた状態を表す概念図である。

【図１６】それぞれのファサードに２件のロウが登録さ
れた状態を表す概念図である。

【図１７】６件のコンテクストの各ロウが登録された状
態を表す概念図である。

【図１８】本発明における検索手順を表すフローチャー
トである。

【図１９】本発明における検索手順を説明するための概
念図である。

【図２０】本発明のデータ管理方法をハードウェア上に
実現したデータ管理装置の概観を例示する鳥瞰図であ
る。

【図２１】本発明のデータ管理装置の要部構成を例示し
たブロック図である。

【図２２】インスタンス間を関連づけたデータの例を示
す図である。

【図２３】図２２のデータに新たに電話番号が割り付け
た場合の例を示す図である。

【図２４】”斉藤”のデータに対応するコンテクストの
例を示す図である。

【図２５】検索パターンの例を示す図である。

【図２６】”分類２”の要素を先頭とするロウの例を示
す図である。

【図２７】図２６に示すロウを登録した場合の、”分類
２”ファサードの例を示す図である。

【図２８】本発明の作用を説明するのに用いられる図で
ある。

【図２９】本発明の作用を説明するのに用いられる図で
ある。

【図３０】本発明の作用を説明するのに用いられる図で
ある。

【図３１】本発明の作用を説明するのに用いられる図で
ある。

【図３２】本発明の作用を説明するのに用いられる図で
ある。

【図３３】本発明の作用を説明するのに用いられる図で
ある。

【符号の説明】

８０データ管理装置８０Ａデータ入力部８０Ｂデータ処理制御部８０Ｃデータ記憶部８０Ｄデータ出力部８１フレキシブルディスク装置（フレキシブルディス
クドライブ）８２光ディスク装置（光ディスクドライブ）８３フレキシブルディスク８４光ディスク８５ＲＯＭ８６カセットテープ８７キーボード８８ネットワーク回線８９ディスプレイ

Claims

【特許請求の範囲】

【請求項１】アドレスで識別される複数の記憶領域にそ
れぞれ別々のインデクスを対応付け、記憶領域へのアド
レス値を含むレコードに対応するエントリを、含まれる
アドレス値毎に対応付けて作成し、前記エントリに対応
するアドレス値で指示される記憶領域に対応付けられた
インデクスに前記エントリを登録することを特徴とする
データ管理方法。
【請求項２】前記インデクスは、前記エントリをソート
して管理し、前記エントリのソート順を決定するキーと
して、前記エントリを対応付けたアドレス値を含むレコ
ードの内容を使用することを特徴とする請求項１記載の
データ管理方法。
【請求項３】前記エントリのソート順を決定するキー
は、エントリ毎に指定することを特徴とする請求項２記
載の管理方法。
【請求項４】前記エントリのソート順を決定するキーと
して、前記エントリを対応付けたアドレス値を含むレコ
ードに含まれる他のアドレス値で指示される記憶領域の
内容を使用することを特徴とする請求項２記載のデータ
管理方法。
【請求項５】前記エントリのソート順を決定するキーと
して、前記エントリを対応付けたアドレス値を含むレコ
ードに含まれる他のアドレス値そのものを使用すること
を特徴とする請求項２記載のデータ管理方法。
【請求項６】前記アドレス値を含むレコードの更新に伴
って、前記インデクス中のエントリの各キーがソート順
に矛盾しないように必要に応じてエントリの順序を修正
することを特徴とする請求項２記載のデータ管理方法。
【請求項７】前記アドレス値の参照先記憶領域の内容の
更新に伴って、前記インデクス中のエントリの各キーが
ソート順に矛盾しないように必要に応じてエントリの順
序を修正することを特徴とする請求項４記載のデータ管
理方法。
【請求項８】指定されたキーでインデクスを検索するこ
とを更に備えたことを特徴とする請求項２記載のデータ
管理方法。
【請求項９】指定した内容を持つ前記記憶領域を決定
し、その記憶領域に対応付けられた前記インデクスを検
索することを特徴とする請求項８記載のデータ管理方
法。
【請求項１０】前記インデクスを検索した結果得られた
エントリに対応付けたアドレス値を含むレコードに含ま
れる他のアドレス値で指示される記憶領域に対応付けら
れたインデクスを更に検索することを特徴とする請求項
８記載のデータ管理方法。
【請求項１１】データを管理するプログラムを格納した
コンピュータ読み取りとり可能な記録媒体であって、前
記プログラムは、アドレスで識別される複数の記憶領域
にそれぞれ別々のインデクスを対応付け、記憶領域への
アドレス値を含むレコードに対応するエントリを、含ま
れるアドレス値毎に対応付けて作成し、前記エントリに
対応する前記アドレス値で識別される記憶領域に対応付
けられたインデクスに前記エントリを登録することを特
徴とするコンピュータ読み取り可能な記録媒体。
【請求項１２】前記インデクスは、前記エントリをソー
トして管理し、前記エントリのソート順を決定するキー
として、前記エントリを対応付けたアドレス値を含むレ
コードの内容を使用することを特徴とする請求項１１記
載のコンピュータ読み取り可能な記録媒体。
【請求項１３】前記エントリのソート順を決定するキー
は、エントリ毎に指定することを特徴とする請求項１２
記載のコンピュータ読み取り可能な記録媒体。
【請求項１４】前記エントリのソート順を決定するキー
として、前記エントリを対応付けたアドレス値を含むレ
コードに含まれる他のアドレス値で指示される記憶領域
の内容を使用することを特徴とする請求項１２記載のコ
ンピュータ読み取り可能な記録媒体。
【請求項１５】前記エントリのソート順を決定するキー
として、前記エントリを対応付けたアドレス値を含むレ
コードに含まれる他のアドレスそのものを使用すること
を特徴とする請求項１２記載のコンピュータ読み取り可
能な記録媒体。
【請求項１６】前記アドレス値を含むレコードの更新に
伴って、前記インデクス中のエントリの各キーがソート
順に矛盾しないように必要に応じてエントリの順序を修
正することを特徴とする請求項１２記載のコンピュータ
読み取り可能な記録媒体。
【請求項１７】前記アドレス値の参照先記憶領域の内容
の更新に伴って、前記インデクス中のエントリの各キー
がソート順に矛盾しないように必要に応じてエントリの
順序を修正することを特徴とする請求項１４記載のコン
ピュータ読み取り可能な記録媒体。
【請求項１８】指定したキーでインデクスを検索するこ
とを更に備えたことを特徴とする請求項１２記載のコン
ピュータ読み取り可能な記録媒体。
【請求項１９】指定した内容を持つ前記記憶領域を決定
し、その記憶領域に対応付けられた前記インデクスを検
索することを特徴とする請求項１８記載のコンピュータ
読み取り可能な記録媒体。
【請求項２０】前記インデクスを検索した結果得られた
エントリを対応付けたアドレス値を含むレコードに含ま
れる他のアドレス値で指示される記憶領域に対応付けら
れたインデクスを更に検索することを特徴とする請求項
１８記載のコンピュータ読み取り可能な記録媒体。