JP2002501256A - データベース装置 - Google Patents

Abstract

(57)【要約】 【課題】 本発明は、データベースを提供する。 【解決手段】データレコードにアクセスするためのデータベースファイル管理システムは、データ処理システム上で実行されており、データレコードはブロック（４０２，４０５，４０６及び４０７）の中で配列されるトリーインデックスにリンクされ、記憶媒体に記憶されている。トリーインデックス（Ａ、Ｂ、Ｉ及び要素４０２）は、キーによってデータレコードへのアクセス又は更新を可能にし、ブロックの不均衡な構造に敏感である。トリーインデックスを提供し、代表的なインデックスをトリーインデックスの代表的なキーに構築するステップを含み、ブロックに配列された階層インデックスを構築する方法が提供される。階層インデックスは、キーまたは複数のキーによるデータレコードへのアクセス又はデータレコードを更新でき、ブロックの均衡構造を構成する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】

本発明は、データベースおよびデータベース管理システムに関する。

【０００２】

【従来の技術】

よく知られているように、データベースシステムとは、相互関連しているデー
タファイル、インデックス、および一人または複数のユーザがデータを追加、こ
れらのファイルに記憶されているデータを検索、修正することができるようにす
るプログラムセットの集合体である。データベースシステムの基本概念とは、デ
ータが物理的にどのように編成され、アクセスされるのかなどの詳細の処理から
従来のユーザを免除するいわゆる「抽象的な」簡略化されたデータのビュー（デ
ータモデルまたは概念構造と呼ばれることもある）をユーザに与えることである
。

【０００３】 ここではよく知られているデータモデルのいくつか（つまり、「階層モデル」
、「ネットワークモデル」、「リレーショナルモデル」、および「オブジェクト
リレーショナルモデル」）が簡略に検討されるだろう。さらに詳細な説明は、例
えば、マグローヒルインターナショナルエディションズ（McGRAW-Hill Internat
ional Editions）のHenry F.Korth、Abraham Silberschatzの「データベースシス
テム概念（Detabase System Concepts）」、１９８６年（または（１９９７）年
第３版）の第３章から第５章、４５頁から１７２頁に記載されている。

【０００４】 一般的には、以下で説明されるすべてのモデルは、それらが、それぞれエンテ
ィティの指定されている属性を示している１つまたは複数の「フィールド」を有
する「レコード」としてそれぞれ「エンティティ」を表すという点で１つの共通
のプロパティを有している（例えば、指定されている書籍のレコードには、以下
のフィールド「本ＩＤ（ＢＯＯＫ ＩＤ）」、「書籍名（ＢＯＯＫ ＮＡＭＥ）
」、「題名（ＴＩＴＬＥ）」があってよい）。通常、１つまたは複数の属性は「
キー」を構成する。つまり、それはレコードを識別する。後者の例では、「書籍
ＩＤ（ＢＯＯＫ−ＩＤ）」がキーとしての役割を果す。多様なモデルは、とりわ
け、これらのレコードがより複雑な構造に編成されるように、他方から一方が区
別されている。

【０００５】 リレーショナルモデル−Ｃｏｄｄによって紹介されたリレーショナルモデルは
、データベース開発の歴史の中の画期的な事件である。リレーショナルデータベ
ースでは、それに従って列がフィールドを表し、行がレコードを表すテーブル（
「リレーション」と呼ばれる）によりデータが表される抽象的な概念が導入され
てきた。

【０００６】 テーブル間の結合は概念的にすぎない。それはデータベース定義の一部ではな
い。２つのテーブルは、それらが、その値が（「ドメイン」と呼ばれる）同じ値
のセットから採取される１つまたは複数の列を有するという事実により暗示的に
関連付けることができる。

【０００７】 リレーショナルモデルにより導入されるその他の概念とは、テーブルに作用す
るハイレベル演算子（つまり、そのパラメータと結果の両方ともテーブルである
）および人がこれらの結果がどのようにして作り出されなければならないのかよ
りむしろ、何が必要とされている結果なのかを指定する（現在では第４世代言語
と呼ばれている）包括的なデータ言語である。このような非手続き的言語（ＳＱ
Ｌ−構造化検索言語）は、業界規格となった。さらに、リレーショナルモデルは
、非常にハイレベルのデータ独立性を示唆している。これらの言語で作成された
プログラムには、データを編成し、記憶し、索引付けし、および並べる方法の変
更を原因としたいかなる影響も及ぼされてはならない。リレーショナルモデルは
、データアナリストのデファクトスタンダードとなったのである。

【０００８】 ネットワークモデル−リレーショナルモデルでは、データ（およびデータ間の
関係性）はテーブルの集合体と見なされる。ネットワークモデルではそれと区別
して、データはレコードの集合体として表されているが、レコード（データ）間
の関係性はリンクとして表される。

【０００９】 ネットワークモデルの中のレコードは、それが、それぞれが１つの種類のデー
タを保持しているフィールドの集合体であるという意味で、「エンティティ」に
類似している。リンクは、実際には、好ましくは（であるが必ずしもではない）
ポインタとして見られる。レコードの集合体およびその間の関係は、グラフの集
合体を構成する。

【００１０】 階層モデル−階層モデルは、データとデータ間の関係を、つまりレコードとリ
ンクとして取扱う方法においてネットワークモデルに似ている。ただし、ネット
ワークモデルと区別して、レコードとそれらの間の関係は任意のグラフの集合体
よりむしろ、ツリーの集合体を構成する。階層モデルの構造は、特に、データベ
ースで編成される必要のあるデータが固有の階層性質を帯びているケースでは、
簡略かつ率直である。階層モデルには、いくつかの固有の欠点がある。例えば、
多くの実生活のシナリオでは、データを容易に階層のように配列できない。さら
に、データが階層のように編成できるにしても、データは他のデータベースモデ
ルに比較してより大きな量を必要とする。

【００１１】 例えば、以下の下位（subordinated）属性「Employee_Salary」と「Employee_
Attendance」がある基本的なエンティティ「Employee（従業員）」を考えてみる
。後者も、「Employee_Entries」と「Employee_Exits」などの下位属性を有して
よい。このシナリオでは、データは固有の階層性質を持っているため、好ましく
は階層モデルで編成される必要がある。例えば、「Employee」が複数の「Projec
ts（プロジェクト）」に割り当てられ、彼／彼女が各プロジェクトで費やす時間
（「Time_Spent」）が「Employee」エンティティと「Projects」エンティティに
含まれる１つの属性であるシナリオを考えてみる。データのこのような配列は、
階層モデルでは容易に編成できず、考えられる１つの解決策は、アイテム「Time
_Spent」を複製し、それを「Employee」と「Project」の階層の中に別個に保持 することである。このアプローチは、現在では、「Time_Spent」の２つのインス
タンスがつねに同一に保たれることを保証することが必要とされているという意
味で扱いにくく、エラーを受けやすい。

【００１２】 オブジェクト指向モデル−包括的な説明は、James Rumbaugh、Michael Blaha、W
illiam Premerlani、 Frederick EddiおよびWilliam Lorenseの「オブジェクト指
向型モデリング（Object Oriented Modeling and Design)」に記載されている。

【００１３】 オブジェクト指向アプローチは、すべてのエンティティをオブジェクトと見な
す。各オブジェクトはクラスに属し、各クラスでは関連するメソッドとフィール
ドがある。カプセル化を可能にするために、フィールドはそのクラスのメソッド
だけがアクセス可能な非公開であるが、他はすべてがアクセスできる公開である
。したがって「Joe Smith」はpersons（人物）のクラスに属する。そのクラスに
は、非公開フィールド年齢が定義できる。クラスメソット゛update_age（）をオ ブジェクトＪｏｅに適用すると、彼の年齢が変更されるだろう。この方法論によ
り、スーパークラスのすべてのメソッドとフィールドを継承するサブクラスを定
義することができる。したがって、例えば、employeeクラスはpersonクラスのサ
ブクラスとして定義できる。加えて、人はサブクラスに追加のフィールドとメソ
ッドを定義してよい。このようにして、employeeクラスはsalaryフィールド、お
よびget_raise（）メソッドをサポートできるだろう。

【００１４】 オブジェクトリレーショナルモデルは、リレーショナル編成データ状でのオブ
ジェクトビューを可能にする。このようにして、人は、まるでそれがオブジェク
トとして編成されているかのようにデータに作用するのと同時にリレーショナル
アプローチをサポートすることができる。

【００１５】 前記に言及されたように、データモデルはデータ表記の概念的または論理レベ
ルを処理し、データが物理的にどのように配列され、アクセスされるのかなどの
詳細は「非表示」にする。後者の特性は通常、いわゆるデータベースファイル管
理システムにより処理される。

【００１６】 データベースファイル管理システムは、（データベースモデルという点で）論
理構造をデータ構造、関連動作およびおそらく他のデータにマッピングする。デ
ータ構造は、インデックスとデータレコードを含む。インデックスは、キーによ
るデータレコードのアクセスまたは更新を可能にする。検索というコンテキスト
では、検索キーという用語が使用される。データベースファイル管理システムは
、時間という点で（つまり、ユーザの観点からデータベースの高速応答時間）お
よび空間という点で（データベースファイルに割り当てられている記憶領域の量
を最小限に抑えるために）性能の拡張を達成するために、好ましくは、データレ
コードに作用しなければならない。技術では周知であるように、通常、時間と空
間の要件の間には交換条件がある。データベースの性能は、データを表すために
使用されるデータ構造の効率、およびシステムがこれらのデータにどの程度効率
的に作用できるのかに依存する。従来のファイルシステムおよび管理システムに
関する詳細な説明は、例えば同書「データベースシステム概念（Database Syste
m Concepts）」の第７章（ファイルシステム構造）と第８章（索引付け）に示さ
れている。

【００１７】 既知のデータベースファイル管理システムは、典型的には、多元ツリーインデ
ックスおよびその他を含む以下の主要なカテゴリに該当する以下の索引付けスキ
ームを活用する。

【００１８】 多元ツリーインデックス−これらの技法は、同じデータレコードへの１つまた
は複数のアクセスパス（検索パスとも呼ばれる）を作成するために使用できる。
検索パスは、多元ツリーを形成する。その主要な不利な点とは、それが空間（通
常、レコードに対するすべてのキーにいくつかのポインタを加えたもの）と保守
（更新トランザクション（以下の定義を参照のこと）が発生する、つまりレコー
ドが追加および／または削除されるたびのキーの追加および／または削除）を必
要とするという点である。通常、ファイル内に保持されるデータの量だけではな
く、索引付けスキームの性質が、指定されているデータレコードを発見または更
新（更新は、挿入、削除または修正を含む）するために必要とされるアクセスの
数を決定する。検討されている記憶媒体が外部メモリであるケースでは、アクセ
スの数は、実際にはＩ／Ｏアクセスの数である。以下に説明されるように、記憶
媒体へのアクセスのたびに、データのブロックがメモリの中にロードされる。

【００１９】 多様な種類のツリー索引付けスキームが開発されてきたが、通常、索引付けの
インプリメンテーションは、指定されている直接アクセス索引付け技法よりはる
かに高価である。他方、ツリー索引付けは、逐次処理および部分範囲処理を可能
にする。最も幅広く使用されている索引付けスキームの１つが、キーが均衡した
ツリー構造の中に保たれ、最低レベルがデータ自体を指す（Ｂ^＋ツリーなどの多
様な商用製品名およびインプリメンテーション可変要素が付けられている）Ｂツ
リーである。Ｂ−ツリー索引付けスキームの詳細な説明は、同書「データベース
システム概念」２７５頁から２８２頁に記載されている。Ｉ／Ｏアクセスの数は
アルゴリズム表記ＬｏｇＫＮ÷１に従い、この場合、Ｋはインプリメンテーショ
ンに依存する定数であり、Ｎはレコードの総数である。つまり、性能は、レコー
ドの数が増加するのに従って対数的に低下する。

【００２０】 言うまでもなく、前記または前記の２つまたは３つ以上に従って実現される索
引付けスキームなどのその他の技法を使用することも可能である。

【００２１】 前記の人気のあるＢツリー索引付けスキームの重要な欠点の１つとは、キーが
データレコードの一部として保持されるだけではなく、インデックスの一部であ
るという点である。

【００２２】 言うまでもなく、これは、インデックスサイズの望ましくない膨張を生じさせ
、後者の欠点は、大きなサイズのインデックスが活用されるときに（つまり、相
対的に大きい数のビットがキーを表すために必要とされるときに）さらに悪化す
る。

【００２３】 この問題に対処するための考えられる１つのアプローチとは、トリー索引付け
スキームを利用することである。後者の例は、マグローヒル（Mcgraw-Hill）１ ９８７年、G.Wiederholdの「データベース設計のためのファイル編成（File org
anization for Database design）」２７２頁、２７３頁、またはアディソンウ ェズレイ出版社（Addison-Wesley Publishing Company）１９７３年、Ｄ．Ｅ． Ｋ_ｎｕｔｈの「コンピュータプログラミングの技術（The Art of Computer Prog
ramming）」４８１頁から５０５頁、６８１頁から６８７頁に説明されている。

【００２４】 一般的には、トリー（trie）索引付けスキームは、例えばＢツリー技法によっ
て明らかになったキーの複製を回避する一方で、高速検索を可能にする。トリー
索引付けスキームは、検索が検索キー部分（例えば、検索キー数字またはビット
）に従って検索を区分化することに基づいているツリーの一般的な構造を有する
。したがって、例えば、トリー検索付けファイル内の各ノードは検索キーのオフ
セットを表し、その子の内の任意の１つに対するリンクは前記オフセットでの文
字の値を表す。前述されたように、検索キーは全体として内部モードで保持され
ず、したがって例えばＢツリー索引付け技法で示される複製は回避されるため、
トリー構造は、そのために割り当てられているメモリスペースという点で効率的
なデータ構造を提供する。

【００２５】 同書「データベース設計用ファイル編成（File organization for Database d
esign）」に説明されているトリーなどのトリーの特定の可変要素において、応 答時間という点で性能の改善を達成するためには、検索空間の考えられる最良の
分割が得られるように、つまり言い替えると可能な限り均衡であるツリーを達成
するために、トリー索引付けファイルが、数字（またはビット）を検索キーから
選択することにより構築されなければならない。しかしながら、これには、トリ
ー（trie）のデータ構造の演繹的な知識を必要とし、並べ替えられていないデー
タを得るという不利益を被って達成されることになり、それは多くの実生活のシ
ナリオでは不適当である。並べ替えられたデータが必須である場合に、トリーの
データレコードの十分な演繹的な（prioiri）知識があったとしても均衡した構 造を保証できないことは注目に値する。指定されたトリーが逐次部分範囲処理を
サポートしていないことに注意する必要がある。

【００２６】 大量のデータを考えるとき、ルートノードから求められるデータレコードと関
連したリーフノードへの指定されたデータレコードにアクセスするための長いパ
スを回避するために、ツリーインデックスのいわゆる均衡構造を維持することは
特に重要である。指定されたＢツリー索引付けスキームは、ツリーが更新トラン
ザクションを受けた後も、固有の均衡ツリー構造を構成する。しかしながら、固
有の均衡した（あるいは本質的に均衡の）構造は、特に、多数のデータレコード
を保持する大きなツリーに関する限り、前述されたように、ツリー内のブロック
の内容を膨張させ、その結果インデックスを保持するファイルサイズを不当に拡
大するという不利益を被って達成される。大量のファイルは求められているデー
タに達するために、記憶媒体へのアクセスの数という点で（その結果アクセス時
間という点で）データ管理システムの性能に悪影響を及ぼし、これは明らかに望
まれていない。

【００２７】 ここではインデックススキームの「その他」のカテゴリに目を向けると、それ
は例えば、いわゆる「スキップリストインデックス」を含む。スキップリストと
は、無作為化したデータ構造である。それは複数のレベル、最低レベル、レベル
０から成り立っており、減少しない順序で並べられているすべてのレコードのリ
ストから成り立っている。レベルｉ（ｉ＝０，．．．ｈ）の各ノードは、確率ｐ
で、レベルｉ＋１を表すかどうかを選択する。レベルｉの代表はレベルｉ＋１の
ノードを構成する。これらの代表も、並べられたリストとして編成されている．
レベルｈ＋１は第１空レベルである。

【００２８】

【発明が解決しようとする課題】

これまで既知のインデックススキームの主要な欠点、つまり膨張したデータ量
（例えば、Ｂツリーとその可変要素）および不均衡な構造（例えば、ツリー）に
影響を受けやすいことを説明してきたが、データレコードの従属および多次元特
徴を含む、多様な特徴に関する別の態様での説明が後に続く。

【００２９】 したがって、例えば、借り手がBorrower_Idによって識別され、書籍がBook_Id
によって識別される、それぞれが各一意キーに関連している２つのエンティティ
（テーブル）、つまりBooksとborrowers（借り手）として表されている２種類の
データレコードを考えてみる。実生活のシナリオでは、例えば公共の図書館では
、人は、例えば指定されている借り手によって借りられているすべての書式を見
ることに関心がある。後者のトランザクションはデータレコードの従属を例示し
、「書籍」は「借り手」に従属している。この問い合わせを解決するために、人
は、２つの問い合わせを適用しなければならない―１つは借り手情報に関して、
もう１つはその人によって借りられている書籍に関してである。

【００３０】 Ｂツリー索引付けスキームに関する限り、指定された方法でのデータの従属を
サポートするために、以下のように、複数の別個のインデックスファイルが必要
とされる。

【００３１】 ・book-Idキーを介してアクセス可能な書籍インデックスファイル ・borrower-id−キーを介してアクセス可能な借り手インデックスファイル ・複合キー（borrower-Id book-Id）を介して、アクセス可能な借り手を介し たトランザクション したがって、インデックススキームはここでは３つのインデックスファイルを
含む。これは、データ量と追加完全性保持とチェックに関する限り、明らかに望
ましくないオーバヘッドを提議する。したがって、例えば、指定されている書籍
を書籍ファイルから削除するには、それがborrower-bookインデックスファイル に存在するかどうかを問い合わせるための予備試験が必要となる。

【００３２】 ここまで既知の技法の欠点を説明してきたが、データレコードの従属に関する
限り、扱いにくい表記およびその動作方法は、いわゆる多次元データコードのイ
ンプリメンテーションを考慮するのに値するようにもなる。

【００３３】 ここでは後者の例に立ち返ると、テーブルBooksとborrowersは、いま、複数の
ビューから到達できる多次元テーブルと見なされている。したがって、前述され
た借り手−＞書籍ビュー（borrower-book複合キー上でインデックスによって実 現される借り手（複数の場合がある）により借りられる書籍）に加えて、データ
ベースは、指定された書籍（複数の場合がある）を借りた借り手の代替ビューを
サポートする必要があり、それは言うまでもなく、代替複合キー（book-borrowe
r）を活用することを必要とする。

【００３４】 Ｂツリー表記においては、したがって複合キー（book-Id borrower-Id）を介 してアクセス可能な別のインデックスファイルを追加することが必要とされ、合
計で４つのインデックスファイルを生じさせる。

【００３５】 関連する欠点は自明であり、ｎ次元テーブルにとっても価値があるようになる
（ｎ＞２）。

【００３６】 したがって、技術では、これまで既知のデータベースファイル管理システムを
利用するデータ処理システムの欠点を削減する必要性がある。特に、技術では、
効率的なデータベースファイル管理システムを活用することによってデータベー
ス性能を示すデータ処理システムに備える必要性がある。

【００３７】 しかも、技術では、本質的に、前述されたように不均衡な構造に影響を受けや
すくないインデックスを活用するデータベースファイル管理システムに備える必
要性もある。

【００３８】 さらに、技術では、複数の種類のデータ、データレコードの従属、および／ま
たは多次元の表記を本質的にサポートするインデックスに備える必要性もある。

【００３９】

【課題を解決するための手段】

用語の解説 説明の明快さのために、説明および添付クレームを通して頻繁に使用される追
加の用語の解説が続く。用語のいくつかは従来のものであり、それ以外は造り出
された。

【００４０】 ブロック−ただ１回のＩ／Ｏ動作でアクセスできる記憶装置。ブロックは任意
の所望の方法で配列されているデータ、例えばツリーとして配列されているノー
ドおよびおそらく実際のデータレコードへのリンクも格納してよい。ブロックは
主要記憶域（内部とも呼ばれる）または二次（外部とも呼ばれる）記憶域内に常
駐してよい。

【００４１】 ツリー−空であるか、ｄ（ｄ≧０）ポインタ（またはリンク）によってルート
のサブツリーと呼ばれる独立ツリーにリンクされるルートノードから成り立って
いるデータ構造。サブツリーのルートは、ツリーのルートノードの子ツリーと呼
ばれ、サブツリーのノードはルートの子孫ノードである。そのすべてのサブツリ
ーが空であるノードはリーフノードと呼ばれる。リーフではないツリー内のノー
ドが、内部ノードとして示される。

【００４２】 本発明のコンテキストでは、リーフノードは、データレコードに関連するノー
ドでもある。

【００４３】 ノードとツリーは、広義に解釈される必要がある。したがって、ツリーの定義
は、各ノードがブロックを構成するブロックのツリーも含む。同じようにして、
前記ブロックの子孫ブロックは、ブロックからアクセスできるすべてのブロック
である。「ツリー」の詳細な定義については、Cormen、LeisersonおよびRivestま
たはLewisとDenebergの「データ構造とそのアルゴリズム（Data structures and
their algorithms）」も参照すること。

【００４４】 リーフノードとデータレコードの間の結合（例えば、リンク）は、リーフノー
ドからデータレコードにアクセスすることを可能にするあらゆる実現を含む。し
たがって、例証として、データレコードはリーフノードから直接的に（つまり、
ポインタを通して）アクセスしてよい。別の非制限例により、リーフノードは、
代わりにデータレコードにアクセスすることを可能にするデータ構造（例えば、
テーブル）を指す。言うまでもなく、その他の可変要素も実行可能である。

【００４５】 インデックスの深さ−ルートブロックからデータレコードに関連するブロック
までの最大ブロック数として定義される。

【００４６】 均衡インデックス−ｎが構造の中でのレコード数である場合に、任意のデータ
レコードに達するために必要とされるアクセスの数が、多くともclognであるよ うに、定数ｃが存在する場合に、インデックスは均衡である。

【００４７】 均衡ツリーを得ることは、事後に（不均衡構造上で）均衡技術を適用すること
、均衡構造を生じさせること、あるいは所望される場合、均衡構造を維持するた
めに進行中に均衡技術を適用することを含む。

【００４８】 インデックスにアクセスすることは、通常であり、必ずしもではないが、求め
られているデータレコードに達するために、あるノードからブロック内の別のノ
ードに、あるいは別のブロックに移動するプロセスと見なされるだろう。

【００４９】 ナビゲーションは、（必ずしもではないが）通常、それらをそのキーごとに並
べて収集するためにデータレコードにアクセスすることと見なされる。

【００５０】 検索スキーム：キーにより指定されたデータレコードにアクセスするために使
用されるインデックスに関連するアルゴリズムを意味する。ブロック内検索スキ
ームは、指定されたデータレコードまたは別のブロックにアクセスするためにブ
ロックの内側で使用されるアルゴリズムを意味する。データレコードは必ずしも
前記ブロックの中に収容されない。

【００５１】 ブロックの共通キー−ブロックの共通キーは、関連する検索スキームによって
ブロックからアクセスできるデータレコードのすべてのキーの最も長いプレフィ
ックスである。所望される場合、共通キーの一部またはすべては、ブロック内で
明示的に保持されてよい。

【００５２】 更新トランザクション−新規データレコードを挿入するか、あるいは既存のデ
ータレコードを削除したり、既存のデータレコードまたはその部分を修正するこ
とから成り立つトランザクション。

【００５３】 垂直指向トリー構造−ルートからリーフまでのデジタルツリーの従来の向き。
以下に例証されるように、垂直トリー内でノードおよび／またはブロックの間の
すべてのリンクを維持することは必ずしも必須ではない。さらに詳細に後述され
るように、本発明のインデックスの中では、不均衡構造の影響を受けやすいトリ
ーは、垂直ツリーを構成する。後述されるように、いくつかの特定の実施形態に
おいては、トリーのデータレコードのキーの上でのインデックスの構築が、垂直
指向トリーを構成する。

【００５４】 水平指向トリー構造−垂直トリー構造のｈレベルを持つことであって、第１レ
ベルは最上レベルを表し、ｈ番目のレベルは、通常データレコードと関連し、ブ
ロックの共通キー値に従って、ｉ番目のレベルのブロックからｉ＋１番目のレベ
ルのレコードへえ移動することを許す（不均衡構造の影響を受けやすいトリーを
構成する）最低レベルを表す。本発明の多様な実施形態においては、および以下
にさらに詳細に説明されるように、ｈ上部レベルは最低レベルツリーのブロック
の共通キーの上の代表インデックスを構成する。

【００５５】 記憶媒体−内部メモリと外部メモリのどちらか、あるいは両方を含む、データ
を記憶するために使用してよい任意の媒体。外部メモリは、以下の１つまたは複
数であってよい。つまり、磁気テープ、磁気ディスク、光ディスク、またはデー
タを記憶するために使用されるそれ以外の任意の物理的な媒体。内部メモリは、
内部メモリとしての役割を果すそれ以外の任意の物理的な記憶媒体だけではなく
、キャッシュメモリを含む既知のメインメモリを含む。

【００５６】 短リンク−（近リンクとも呼ばれる）そのアクセスパスにノードｂを含むデー
タレコードのキーが、キー位置ｒで値ｋを持つように、値ｒを持つノードａと同
じブロック内のノードｂの間でｋとラベルが付けられているリンク。

【００５７】 長リンク−（遠リンクとも呼ばれる）レベルｉ−１のブロックＢの中のノード
ｖとレベルｉのブロックＢ’またはデータレコードとの間のリンク。ｖが値ｒを
有し、リンクのラベルがｋである場合には、ブロックＢ’の共通キーまたはデー
タレコードのキーは、位置ｒでｋである。

【００５８】 短リンクまたは遠リンクのラベルは、リンクの値または方向とも呼ばれる 分割リンク−ブロックがオーバフローし、ノードａがノードｂにリンクされる
場合に、および分割ノードｂとその子孫ノードが別のブロック―ブロックＢ―に
収容された後、ノードａとノードｂの間のリンクが分割リンクであるように、分
割プロセスが実行される。分割後、分割リンクは、ノードａと（ノードｂを収容
している）ノードＢの間のリンクである。分割リンクはラベルが付けられたリン
クである。

【００５９】 ＰＡＩＦなどの複数のインプリメンテーションにおいては、人は階層インデッ
クスを通してブロックＢにアクセスできるので、ノードａから、ノードｂが常駐
するブロックＢへの分割リンクを維持することはオプションである。

【００６０】 直接リンク−ノードｖとｖ’が同じ値を持つようにノードｖ’を含む、レベル
ｉのブロックＢ内のノードｖとレベルｉ−１のブロックＢ’の間のリンク。キー
ｋがあるデータレコードへの検索パスがノードｖを含むが、その近リンクと遠リ
ンクのどれも含まない場合には、それはブロックＢ’への直接リンクを含む必要
がある。直接リンクにはラベルは付かない。

【００６１】 ブロック分割手順で活用される用語、複製ノードおよびコピーノードに関する
説明が続く。

【００６２】 このようにして、ノードｖ’が値ｋを有する場合には、ｖ’およびそのラベル
が付けられたリンクからアクセス可能なデータレコードのすべてのキーが、位置
０，．．．ｋ−１で一致する。

【００６３】 ノードｖが、それがノードｖ’の値に等しい値を持ち、ｖとそのラベルが付け
られたリンクからアクセス可能なすべてのデータレコードがノードｖ’とそのラ
ベルが付けられたリンクからアクセス可能であるように作成される場合、ｖはｖ
’の複製ノードと見なされる。複製ノードはノードｖ’を含むブロックに対する
直接リンクを維持する（複製ノードはコピーノードとも呼ばれる）。

【００６４】 （発明の一般的な説明） 本発明のコンテキストで説明およびクレームの中で使用される多様な追加の用
語と手順での説明が続く。

【００６５】 データレコードは、通常、複数のフィールドから成り立っており、素の内のい
くつかがキーとして示される。レコードが、一次キーと呼ばれる、キーの内の１
つにより並べられることもある。データレコードの上、または代表キーの上（後
者の定義に関しては、以下を参照のこと）でのインデックス（またはインデック
ススキーム）は、１つまたは複数のキーによる検索を容易にするデータ構造であ
る。インデックスの例は、指定されている多元ツリーインデックススキームのど
れかである。本発明に従ったインデックスは、複数のインデックススキームを使
用することにより構成されてよい。

【００６６】 インデックスは、１つのファイル、あるいは内部メモリまたは外部メモリ内に
部分的にあるいは全体的に常駐する複数のファイルに記憶されてよい。

【００６７】 本発明に従って、キーによる検索を可能にし、そのそれぞれが代表キーを含む
ブロックに区分される区分インデックス動的データ構造―を含むインデックスが
提供される。代表キーは、そのキーが（存在する場合には）検索キーに等しいレ
コードに関連するブロックを見つけるのに十分である必要がある。ブロックの位
置を発見すると、データレコードは容易に検索できる。代表キーは、必ずしもブ
ロックの中に物理的に記憶されない。

【００６８】 区分インデックスの例は以下の通りである。

【００６９】 １．一次キーのキー値を増加することにより並べられるファイルのブロックの
シーケンス。インデックスは、キーを含むブロックまで検索を引率する。一次キ
ーではないキーによる検索を可能にするために、区分インデックスは、レコード
ごとに区分インデックスがそのキーとそのリンクを含むように構築される。これ
らの組は、キーの減少しない値によって並べられる。インデックスは、所望のレ
コードのアドレスを含むブロックにつながる。

【００７０】 ２．ブロック内に配列されているトリー ３．区分インデックスの規定を満たすそれ以外の種類のインデックススキーム データレコードのキー上の区分インデックスは、基本区分インデックスと呼ば
れ、インデックス層Ｉ_０で示される。

【００７１】 この区分インデックスは不均衡になり、このようにしていくつかの長い検索パ
スを生じさせる可能性がある。

【００７２】 区分インデックスを効率的に検索するために、追加インデックス層（インデッ
クス層は、省略してインデックスと示される）Ｉ_１がＩ_０の代表キーの上に構築
される。Ｉ_１も区分インデックスである場合には、追加インデックスＩ２がＩ_１ のブロックの代表キーの上に構築されてよい。このプロセスは、好ましくは単一
ブロック内に完全に含まれるインデックスＩ_ｈ（これ以降、ルートインデックス
）を作成するまで繰り返されてよい。ルートインデックスＩ_ｈは必ずしも区分イ
ンデックスではない。（１つのインデックスも構成する）階層インデックスは、
Ｉ_０．．．Ｉ_ｈの集合体である。Ｉ_１．．．Ｉ_ｈはいわゆる代表インデックスを
構成する。

【００７３】 キーｋによりレコードを検索する場合、後者は、ｋにつながるＩ_ｈ−１のブロ
ックＢを見つけるためにＩ_ｈ（および場合によってはＩ_ｈ−１からＩ_１およびデ
ータレコード（複数の場合がある））で検索される。このプロセスは、（存在す
る場合には）キーｋのあるレコードに関連するＩ_０のブロックに達するまで繰り
返される。

【００７４】 キーｋのある新規レコードｒを挿入する場合、ブロックＢを見つけるために、
検索が上記のように実行される。Ｉ_０でＢを発見したら、ｒがＢに追加される。

【００７５】 （Ｉ_０の中の）Ｂがオーバフローすると、それは２つ（または３つ以上の）ブ
ロックに分割され、Ｉ_１内のＢの代表が新規ブロックの代表により置換される。
Ｉ_１内のブロックＢ１のオーバフローには、Ｂ１の分割が伴い、Ｉ２内のＢ１の
代表は新規ブロック等の代表により置換される。Ｉ_ｈのブロックがオーバフロー
すると、追加層Ｉ_ｈ＋１が作成され、階層インデックスに追加される。「オーバ
フロー」状態が、特定のアプリケーションに従って決定されてよく、ブロックが
いぱいにされると、必ずしもトリガされるのではないことに注意する必要がある
。したがって、例えば、ある実施形態によって、オーバフローは、ブロックが少
なくとも半分のサイズでいっぱいのときに発生する。

【００７６】 削除は挿入に類似しており、マージ―分割の反対のプロセスを伴う可能性があ
る。更新または分割は必ずしも進行中に実行される必要はないが、遅延されてよ
い（つまり、事後に（post factum）実行されてよい）。

【００７７】 階層インデックスの構造が好ましくは均衡インデックスを保持することに注意
する必要がある。

【００７８】 いくつかの実施形態においては、均衡インデックスで十分であり、（Ｉ_０がな
い）階層インデックスが相対的に小さい量である（例えば、内部メモリの中に大
部分または完全に収容されてよい）いくつかのケースでは「均衡構造」要件が免
除されてよいことに注意する必要がある。

【００７９】 本発明の第１の態様に従って、不均衡構造の影響を受けやすい基本区分インデ
ックス（例えば、トリー）の固有の制限には、インデックス、およびさらに特定
すると階層インデックスを指定された方法で提供することにより対処してよいこ
とが判明した。

【００８０】 例えば、基本区分インデックス（例えば、トリー）に比較して階層インデック
スに集中すると、すぐに、選択されたデータレコードに階層インデックスを介し
てアクセスすることが、前記トリーを通して同じデータレコードにアクセスする
より、実質的にはさらに効率的であることが判明する。

【００８１】 本発明のコンテキストでは、「さらに効率的」とは、データレコードで更新ト
ランザクション（例えば、挿入、削除または修正）を実行したり、データレコー
ドにアクセスするために階層インデックスを通って記憶媒体へアクセスする回数
が、基本区分インデックスを通って記憶媒体にアクセスする回数に比べて少ない
という意味である。アクセスの回数は、各アクセスで、ブロックが記憶媒体から
取り扱われる（つまり、ロードされるか、処理される）ように解釈されるべきで
ある。

【００８２】 例えば、数ブロックしかなく、基本区分インデックスを通してデータレコード
にアクセスするには、前記階層インデックスを通すのと同じまたはより少ない動
作が必要になる可能性のある非常に小さいファイルのケースなどの後者の「さら
に効率的」な規定が適用しない例外的なシナリオがある場合がある。

【００８３】 区分インデックスをトリーとして実現するためには、トリーである基本区分イ
ンデックスからの階層化インデックスの構築は、なんらかの追加の考慮が必要と
なる。

【００８４】 このようにして、各キーは、文字またはビット文字列と見なされる。さらに、
トリーが単一ブロックに収容できない場合、それはブロックに区分され、その結
果各ブロックが、ｔリエの単一サブツリーを含む。ブロックの代表キーは、ブロ
ック内にトリーのルートノードに関連する文字列、つまりＩ_ｉのトリーのルート
からブロックのトリーのルートへのパスのラベルのシーケンスである。汎用階層
インデックススキームでのように、Ｉ_ｉの代表キーはＩ_ｉ＋１のキーである。Ｉ _ｉ＋１ の中のキーｋを検索するために、人はブロックＩ_ｉ＋１のブロック内での
最長プレフィックスｋを検索し、そこからＩ_ｉの適切なブロックに移動する。

【００８５】 レコードの挿入は、そのキーをＩ_０に追加する、つまり任意の値をＩ_０のトリ
ーに追加することを伴う。その結果、ブロックがオーバフローすると、ブロック
は分割される―それは、典型的には２つ（インプリメンテーションによってはそ
れ以上）のブロックに区分化され、その結果、各ブロックは（接続されている）
トリーを含む。これを達成するために、ノードｕとその子ｖの間のリンクが切断
され、ｖにルートがあるサブツリーが別のブロックに移動される。新規ブロック
の代表キーは、Ｉ_ｉに追加される。汎用階層インデックススキームでのように、
このプロセスはＩ_ｉ．．．Ｉ_ｈまで続行する。

【００８６】 基本区分インデックスが、Patricia（パトリシア）またはＰＡＩＦのような圧
縮されたトリーである場合、キーの部分だけが保存され、これでインデックス空
間が節約される。しかしながら、これらの節約は、検索が実行される方法に影響
を及ぼす。このような圧縮されたトリー（tries）では、通常２より大きいまた は２に等しい度数のノードだけが維持される。検索キーｋが圧縮済みトリーにぞ
越していない場合、検索はレコードｒで終了する可能性があり、わたしたちはｋ
がｒのキーに等しいかどうかを調べなければならない。キーが異なっている場合
には、トリーはキーｋのついたレコードを含んでいない。

【００８７】 この戦略の階層インデックススキームに対する影響は、ｋのプレフィックスが
インデックス内で表されない可能性があるという点である。このようなケースで
検索を可能にするために、ブロックＩ_ｉからブロックＩ_ｉ−１のノードからの直
接リンクが導入される。これらのリンクには方向はなく、検索キーの適切な位置
が、ノードの方向のどれか１つに一致しない場合ときに取られる。

【００８８】 検索が、その代表キーｋ_ｉ−１がｋのプレフィックスではないＩ_ｉ−１のブロ
ックＢ_ｉ−１に達すると仮定する（ｋｉ−１がＢ_ｉ−１で明示的に記録されてい
ない場合、私立ちは、Ｂ_ｉ−１からアクセス可能な任意のデータレコードｒに達
し、ｒのキーからｋｉ−１を決定することができる。）検索を続行するために、
私達はｋとｋ_ｉ−１を比較し、それらが異なる最初の文字の位置ｊを見つけ、直
接リンクとｊより少ないか、それに等しい値のあるノードｖをみつけるまでブロ
ックＢ_ｉのトリーを検索する。検索は、その直接リンクによって指されたＩ_{ｉ− １} のブロックから続行した。（このようなノードが存在しない場合には、私達は
インデックスＩ_ｉ−１の第１ブロックに移動する。）このようにして、さらに悪
い場合には、各層は１つ過剰なアクセスを必要とする可能性がある。これにも関
わらず、および後述されるように、３つの層は、数十億のレコードを処理するの
に十分であり、通常２つの層がコンピュータの内部メモリ内で維持することがで
きる。したがって、任意のデータレコードに関連するブロックにアクセスするた
めに、外部記憶媒体へのわずか２回のＩ／Ｏアクセスを持つことが可能である。

【００８９】 また、分割プロセスは、直接リンクも収容しなければならない。Ｉ_ｉ−１のブ
ロックＢ_ｉ−１へのアクセスパスは、層Ｉ_ｉのブロックＢ_ｉから成り立っており
、Ｂ_ｉ−１がオーバフローし、ブロックＢ_ｉ−１とＢ_ｉ−１’に分割される。ブ
ロックＢ_ｉは、いまＩ_ｉ−１内のすべてのその子孫ブロックへのリンクを含まな
ければならない。これは、以下の非制限技法により達成することができる。

【００９０】 ｋｉ−１をＢ_ｉ−１の代表キーとし、このキーは、Ｂ_ｉ−１の子孫のキーへの
検索がＢ_ｉ−１に達し、Ｂ_ｉ−１の子孫の検索がＢ_ｉ−１に達するように、Ｔｉ
―Ｂ_ｉの圧縮済みトリー―に挿入される。

【００９１】 分割プロセスを達成するための非制限方法は、以下の通りです。

【００９２】 １．少なくとも２つのトリーがブロック内に存在するように、ノード（この事
実に基づいて、分割ノード）の短リンクの間の少なくとも１つの短リンクが削除
される（この事実に基づいて、分割リンク）。

【００９３】 ２．サブツリーのそれぞれは別個のブロックに移動される。

【００９４】 ３．Ｂ_ｉのブロックが存在しない場合、Ｂ_ｉが作成され、分割ノードのコピー
済みノードがＢ_ｉ内で作成される。

【００９５】 ４．Ｂ１のブロックが存在し、分割ノードのコピー済みノードがＢ_ｉの中に存
在しない場合には、分割ノードのコピー済みノードはＢ_ｉの中で作成され、（分
割プロセスの最後にある）Ｂ_ｉ−１’が、Ｂ_ｉ−１の代表キーに従って、Ｂ_ｉの
ルートノードとコピー済みノード、およびそのラベル付きリンクを含む検索パス
でアクセス可能となるように、Ｂ_ｉのトリーに接続される。

【００９６】 ５．コピー済みノードに直接リンクがない場合、直接リンクをコピー済みノー
ドからブロックＢ_ｉ−１に追加する。

【００９７】 ６．コピー済みノードからブロックＢ_ｉ−１’に遠リンクを追加するか、ある
いはコピー済みノードが遠リンクの方向で子ノードの短リンクを持つ場合には、
遠リンクは子ノードからブロックＢ_ｉ−１’への直接リンクによって置換できる
。

【００９８】 前記インプリメンテーションにおいては、ｉｋ内のブロックの分割、ｋ＞０は
、（Ｉｋの）分割リンクが、異なるブロック内に常駐する分割ノードのコピー済
みノード間のリンクであるように実行される。

【００９９】 したがって、１つの態様に従って、本発明は、データ処理システム上で実行さ
れるデータベースファイル管理システムによって使用される記憶媒体の中で、 ブロックの中に配列されている階層インデックス。階層インデックスは、デー
タレコードと関連する基本区分インデックスを含む。基本区分インデックスは、
キーまたは複数のキーによるデータレコードのアクセスまたは更新を可能にし、
ブロックの不均衡な構造に影響を受けやすい。

【０１００】 キーまたは複数のキーによるデータレコードのアクセスまたは更新を可能にし
、ブロックの均衡した構造を構成する前記階層インデックス。 を含むデータ構造に備える。

【０１０１】 本発明は、さらに、データ処理システム上で実行されるデータベースファイル
管理システムによって使用される記憶媒体の中で、 ブロックの中に配列され、データレコードのキーの上に構築されているインデ
ックス。インデックスは、データレコードと関連する基本区分インデックスを含
む。基本区分インデックスは、キーまたは複数のキーによるデータレコードのア
クセスまたは更新を可能にし、ブロックの不均衡な構造に影響を受けやすい。

【０１０２】 前記インデックスは、キーまたは複数のキーによるデータレコードのアクセス
または更新を可能にし、ブロックの均衡した構造を構成する。 を含むデータ構造に備える。

【０１０３】 まださらに、本発明は、データ処理システム上で実行されるデータベースファ
イル管理システムによる使用される記憶媒体の中で、 ブロックの中に配列され、データレコードのキーの上に構築されているインデ
ックス。インデックスはデータレコードに関連するトリーを含む。トリーは、キ
ーまたは複数のキーによるデータレコードのアクセスまたは更新を可能にし、ブ
ロックの不均衡な構造に影響を受けやすい。

【０１０４】 前記インデックスは、キーまたは複数のキーによるデータレコードのアクセス
または更新を可能にし、ブロックの均衡した構造を構成する。 を含むデータ構造に備える。

【０１０５】 まださらに、本発明は、データレコードにアクセスし、データ処理システム上
で実行されているデータベースファイル管理システムの中で以下に備える。つま
り、データレコードは、ブロックの中に配列され、記憶媒体の中で記憶されてい
る基本区分インデックスと関連している。基本区分インデックスは、キーまたは
複数のキーによるデータレコードのアクセスまたは更新を可能にし、ブロックの
不均衡な構造に影響を受けやすい。

【０１０６】 ブロックの中に配列される階層インデックスを構築するための方法は、 （ａ）前記基本区分インデックスを提供するステップと、 （ｂ）前記基本区分インデックスの代表キーの上で代表インデックスを構築す
るステップであって、前記階層インデックスは、キーまたは複数のキーによるデ
ータレコードのアクセスまたは更新を可能にし、ブロックの均衡した構造を構成
する、代表インデックスを構築するステップと、を備える。

【０１０７】 本発明は、さらに、データレコードにアクセスし、データ処理システム上で実
行されるためのデータベースファイル管理システムの中で以下に備える。つまり
、データレコードは、ブロックの中に配列され、記憶媒体内に記憶されている基
本区分インデックスに関連する。基本区分インデックスは、キーまたは複数のキ
ーによるデータレコードのアクセスまたは更新を可能にし、ブロックの不均衡な
構造に影響を受けやすい。

【０１０８】 データレコードのキーの上でインデックスを構築するための方法であって、イ
ンデックスはブロックの中に配列され、 （ａ）前記基本区分インデックスを提供するステップと、 （ｂ）前記基本区分インデックスの代表キーの上でインデックスを構築するス
テップであって、前記インデックスがキーまたは複数のキーによるデータレコー
ドのアクセスまたは更新を可能にし、ブロックの均衡した構造を構成するステッ
プと、を備える。

【０１０９】 本発明に従って、データレコードにアクセスし、データ処理システム上で実行
されるためのデータベースファイル管理システムの中で以下がさらに提供されて
いる。つまり、データレコードは、ブロックの中に配列されているトリーに関連
する。トリーはキーまたは複数のキーによるデータレコードのアクセスまたは更
新を可能にし、ブロックの不均衡な構造の影響を受けやすい。

【０１１０】 データレコードのキーの上でインデックスを構築するための方法は、インデッ
クスはブロックの中に配列されており、 （ａ）トリーを提供するステップと、 （ｂ）前記トリーの代表キーの上にインデックスを構築するステップであって
、前記インデックスが、キーまたは複数のキーによるデータレコードのアクセス
または更新を可能にし、ブロックの均衡した構造を構成するステップと、を備え
る。

【０１１１】 本発明に従ったインデックスは、必ずしもではないが、好ましくは、指定され
たインデックススキームから選択された索引付けスキームの１つまたは複数によ
り構築される。典型的であるが、排他的ではない多元ツリーインデックスの例は
、Ｂツリー索引付けスキームである。

【０１１２】 １つの実施形態により、前記基本区分化検索スキームは、米国特許番号第５，
４９５，６０９号に開示されている種類のデジタルツリーによって構成されてい
るトリーである。

【０１１３】 別の実施形態により、前記トリーは、いわゆる確率的アクセス索引付けファイ
ル（ＰＡＩＦ）によって構成される。

【０１１４】 このようにして、特定の実施形態によって、データ処理システム上で実行され
るデータベースファイル管理システムによって使用される記憶媒体の中では、複
数のノードおよびリンクを有する少なくとも１つの確率的アクセス索引付けファ
イル（ＰＡＩＦ）を含むデータ構造と以下が提供される。

【０１１５】 前記ＰＡＩＦのリーフノードは、前記ユーザアプリケーションプログラムがア
クセスかできる、それぞれ少なくとも１つのデータレコードと関連し、そこでは
前記データレコードの少なくとも部分が、少なくとも１つの検索キーを構成する
。

【０１１６】 前記ＰＩＡＦ内の選択されたノードは、それぞれ、前記挿入検索キー内の検索
キー部分の指定されたオフセットを表す。前記選択されたノードの間からの各指
定ノードから発するリンク（複数の場合がある）は、それぞれ前記検索キー部分
の一意の値を表す。

【０１１７】 ブロック内でそれぞれ配列されている、少なくとも２つのサブＰＩＡＦを有す
るＰＡＩＦ 前記データベースファイル管理システムは、さらに、前記ブロックをブロック
の均衡した構造として配列することができる。

【０１１８】 ＰＡＩＦというコンテキストでは、前記選択されたノードが、好ましくは指定
されたオフセットだけを含む一方で、これが必ずしもつねに当てはまらないこと
に注意する必要がある。したがって、前記ノードの１つまたは複数は、すべて必
要に応じて、適宜に、キーおよび／またはその他の情報の部分などのそれ以外の
情報を含んでよい。

【０１１９】 修正された実施形態に従って、トリーはＰＡＩＦ型であるため、索引付けスキ
ームは、ＰＡＩＦトリーの検索スキームに実質的には同一の検索スキームによっ
て構成される。

【０１２０】 さらに先に進む前に、説明の便利さのためだけに、本発明はおもに基本区分イ
ンデックスとしてのトリーに関しておもに説明されることに注意する必要がある
。技術に長けた者は、本発明が決してトリーによって拘束されず、したがって基
本区分インデックスが適用可能であることを容易に理解するだろう。

【０１２１】 したがって、本発明の階層インデックスを利用するデータベースファイル管理
システムは、とりわけ、以下の特徴のために、これまで既知である技法と比較し
て性能の拡張という点で有利である。

【０１２２】 ・データは、本質的に検索キーに従って並べ替えられた形式で保持される。す
なわち、人は、データレコードのキーの順でツリー内でナビゲーションすること
ができる。階層インデックスは、本質的には、「次を入手」および「前を入手」
などの逐次動作をサポートする。この点では、提案されている階層インデックス
は、例えば、ハッシュ（hashing）スキームおよびデジタルツリーのいくつかの インプリメンテーションに優る優位点を構成する。

【０１２３】 ・均衡したインデックスを維持するために、データベースのコンテンツに関す
る事前の知識に対する要件はない。

【０１２４】 ・均衡した階層インデックスが保持され、階層インデックスの深さは相対的に
小さく、それによって更新トランザクションを実行したり、データレコードにア
クセスするために必要とされるアクセスの数（通常は、低速Ｉ／Ｏ動作）を最小
限に抑える。１つの実施形態に従って、実際的には１つのＩ／Ｏ（およびせいぜ
い２つのＩ／Ｏ）（１つまたは２つのアクセスを構成する）動作が、数十億のデ
ータレコードの中から１つの指定されたデータレコードにアクセスするために必
要とされる。

【０１２５】 本発明は、さらに、１０Ｍｂｙｔｅから２０Ｍｂｙｔｅまたはそれ以上の範囲
となる少なくとも１つの内部メモリ、および外部メモリの記憶媒体を有するコン
ピュータシステム内で以下に備える。

【０１２６】 データレコードのキーの上でインデックスを含むデータ構造。インデックスは
ブロックの中に配列される。その結果、１０億のデータレコードの場合、前記外
部メモリに対する実質的にはせいぜい２回のアクセスが、前記データレコードの
キーのサイズに関係なく、前記１０億のデータレコードの任意の１つに関連する
ブロックにアクセスするために必要とされる。

【０１２７】 まださらに、本発明は、少なくとも１つの、１０Ｍｂｙｔｅから２０Ｍｂｙｔ
ｅまたはそれ以上の範囲となる内部メモリおよび外部メモリの記憶媒体を有する
コンピュータシステムの中で、以下に備える。

【０１２８】 データレコードのキーの上でインデックスを含むデータ構造。インデックスは
ブロックの中に配列される。その結果、１００万のデータレコードの場合、実質
的にはインデックスのすべてのブロックが、前記データレコードのキーのサイズ
に関係なく前記内部メモリの中に収容される。

【０１２９】 本発明は、さらに、記憶媒体を有するコンピュータシステム内で以下に備える
。

【０１３０】 データレコードのキーの上でインデックスを含むデータ構造。インデックスは
ブロックの均衡した構造で配列され、前記データレコードに対する逐次動作の実
行を可能にする．インデックスサイズは、本質的には前記キーのサイズから影響
を受けない。

【０１３１】 データレコードが階層インデックスのブロック内に常駐してよいか、あるいは
別個のデータファイル（１つまたは複数）の中に常駐してよいことに注意する必
要がある。後者の実施形態においては、データレコードは、言うまでもなく対応
する階層インデックスに関連する必要がある。以下の特定の実施形態の説明に関
してさらに明らかにされるように、指定データレコードは、複数の検索キーを処
理してよい。

【０１３２】 本発明に従ったインデックスは、必ずしもではないが、好ましくは特定のイン
デックススキームから選択される索引付けスキームの１つまたは複数によって構
築される。典型的であるが、排他的ではない多元ツリーインデックスの例は、Ｂ
ツリー索引付けスキームである。

【０１３３】 ここでは、本発明の第２の態様に関する説明が続く。

【０１３４】 したがって、通常、データは複数の種類のレコード（例えば、前記例では書籍
と借り手）から成り立っている。例えば、Ｂツリーインデックスを利用する種類
の従来のシステムにおいては、各キーのタイプはレコードとともに保持されず、
キーの一部と見なされない。プログラムは、レコードの種類、およびそれからデ
ータレコードのフィールドとその構造を「知っている」。

【０１３５】 本発明の第２態様に従って、別のアプローチが提案されている。各種のキーに
は、指名子―例えば、必ずしもではないが、通常、この種のすべてのキーに対す
るプレフィックスとして追加される１つまたは複数の文字の系列であるビットの
文字列が割り当てられている。指定されたキーは、その指名子が指定されたキー
のことである。指名子は、（検索または更新の目的のために）キーの一部として
取り扱われるため、インデックススキームの一部である。

【０１３６】 指名子は、種類の関数としてデータレコードの特性を得ることを可能にする。
したがって、キーの指名子を見ることによって、人は指名子を入手し、このため
レコードの種類を演繹することができ、レコードタイプを演繹的に知っている必
要はない。キーが指定されているデータレコードは、指定データレコードと呼ば
れる。指定インデックスとは、指定データレコードでの検索を可能にするインデ
ックスである。

【０１３７】 本発明に従って指名子の使用を例証した説明が続く。したがって、クラスＣを
考えてみる。その結果、このクラスのすべてのデータレコードにはキーフィール
ド（またはフィールド）ｋ_１、およびおそらく複数のそれ他のキー以外のフィー
ルドを有する。ＲをクラスＣのデータレコードとする。この場合、Ｒ．ｋ_１＝Ｆ
ＩＡＴである。ｋ_１の指定子をＡとしよう。指名子を追加することによって、人
は、キーＡＦＩＡＴを入手する。Ｒ．ｋ_１＝ＦＩＡＴが指定されるレコードにア
クセスするために、指定インデックスが、キーＡＦＩＡＴに関して検索される。

【０１３８】 指名子の特徴を説明してきたが、第２の態様に従った別の特徴―データレコー
ドの従属に関する説明が続く。キーＫ_１が指定されるレコードＲ１と、キーＫ_１ 、Ｋ２の並べられた組から成り立つ複合キーが指定されるレコードＲ２を考えて
みる。（このケースでは、Ｒ２の指定されたキーは複合キーＫ_１’、Ｋ２’であ
り、この場合Ｋ２’は指定子Ｄ２によってプレフィックスが付けられたキーＫ２
から成り立つ（Ｄ２はＲ２の指名子と見なされる）。指定インデックスでは、人
は、キーＫ_１’―その指名子Ｄ１が指定されるキーＫ_１を検索することによって
Ｒ１を選択し、キーＫ_１’Ｋ２’―Ｋ_１’とＫ２’の連結で同じインデックスを
検索することによってＲ２を選択することができ、この場合、Ｋ２’はその指名
子Ｄ２が指定されるキーＫ２である。このケースでは、Ｋ２はＫ_１に従属する。

【０１３９】 従属関係は、レコードにも広がる。Ｋ２がＫ_１に従属する場合、Ｋ２’の指名
子はＤ２であり、Ｒ２の指名子もＤ２（またはＤ１、Ｄ２）である。Ｒ２がＲ１
に従属する場合、Ｒ２のキーはＫ２’をＫ_１に連結することにより構成される。
Ｋ２’内では、Ｄ２がＫ２の前に置かれる。

【０１４０】 ＥＲＤモデルにおいては、レコードＲ１のタイプとレコードＲ２のタイプは、
１対多の関係で有効であり、Ｒ２タイプの複数のレコードがＲ１タイプの単一の
レコードに関係してよいことを意味する。このような関係は、従属関係で実現で
きる。つまり、Ｒ２タイプの複数のレコードは、タイプの単一レコードに従属す
るだろう（例えば、複数の書籍は同じ借り手によって借りられる）。特に、この
関係が１対１である場合（例えば、１対１が、１冊の本だけが各借り手によって
借りられる関係である）には、キーＫ_１’Ｄ２である。この場合、Ｄ２はＲ２の
指名子であり、Ｒ２の位置を見つけ出すのに十分である。指名インデックスでは
、Ｋ_１’Ｋ２’への検索パスは、Ｋ_１’への検索パスを含む（これは、別のパス
を介してレコードＲ２に到達する可能性を排除していない）。後者の特徴は、第
２の態様に従った別の重要な特徴、つまりデータ完全性の固有の保守を示してい
る。このようにして、そのキーがＫ_１’Ｋ２’（またはＫ_１’Ｄ２）であるレコ
ードの挿入は、そのキーがＫ_１’であるレコードが存在する場合にだけ実行でき
る。前記例では、本（book_Id＝２２２２）を借りた借り手のトランザクション （Borrower_Id＝１１１１１１）の挿入は、指定された借り手（Ｋ_１＝１１１１ １１が指定されるデータレコードＲ１）が存在する場合に（前記例では、借り手
の指名子はＡであり、従属借り手−書籍データレコードの指名子はＢである）、
その指定キーがＡ１１１１１１Ｂ２２２２（この事実に基づいて、借り手−書籍
レコード）_onlyであるレコードＲ２の挿入を生じさせる。借り手−書籍レコー ドへのインデックス内のパスデータは、借り手が存在するかどうかを判断するた
めの十分な情報を含むので、完全性は、わずかなオーバヘッドだけで達成される
。借り手が存在しない場合、複合キーへのパスは借り手を通過しないだろう。こ
れは、挿入プロセスで自動的に検出されるだろう。対称的に、従来の技術に従っ
て、さまざまな種類のレコードはさまざまなインデックスファイルと関連してい
た。借り手−書籍インデックスファイルに（複合キーが指定される）新規データ
を挿入する前に、指定された借り手（レコードＲ１、キーＫ２）が素材するかど
うかを確定するために借り手インデックスファイル内で別個のチェックが実行さ
れ、このようにして、不当なオーバヘッドを提起しなければならない。

【０１４１】 従属関係が２つのレベルだけに制限されておらず、従属レコードはそれ自体、
それに従属するレコードを有することができ、したがってｎレベルの従属が達成
できることに注意する。例えば、口座レコードが支店レコードに従属し、預金レ
コードが口座に従属する銀行業務データベースを考えてみる。

【０１４２】 ここでは、本発明の第２の態様に従った多次元特徴に目を向けると、Ｒを２つ
のキーＫ_１とＫ２のどちらかにより識別されるレコードとする。その場合、指定
インデックスは、指定キーＫ_１による検索パスと指定キーＫ２’による指定キー
の、Ｒへの２つの検索パスを含む必要がある。したがって、Ｒは多次元レコード
を構成する。多次元インデックスは、指定インデックスと多次元データレコード
（複数の場合がある）を含む。

【０１４３】 多次元インデックスが従属データレコードに適用しない第１実施形態を考えて
みる。このようにして、例えば、このクラスのすべてのデータレコードが２つの
キーフィールドｋ_１―車型―とｋ_２―そのライセンスプレート番号―およびおそ
らくいくつかの非キーフィールドを有するように、クラスＣを考えてみる。Ｒは
、クラスＣのデータレコードとし、この場合Ｒ．ｋ_１＝ＦＩＡＴおよびＲ．ｋ_２ ＝１２７とする。ｋ_１の指名子をＡであるとし、ｋ_２の指名子をＢであるとする
。指名子を追加することによって、人はキーＡＦＩＡＴおよびＢ１２７を入手す
る。これらの拡張されたキーは、単一の指定インデックスの中に挿入される。Ｒ
．ｋ_１＝ＦＩＡＴが指定されるレコードにアクセスするには、指定インデックス
はキーＡＦＩＡＴに関して検索され、Ｒ．ｋ_２＝１２７が指定されるレコードを
選択するには、同じ指定インデックスがＢ１２７に関して検索される。

【０１４４】 前記説明および例は、データレコードが必ずしも従属関係を示さない多次元イ
ンデックスを考慮した。多次元インデックスは、要すれば従属データレコードに
も適用されてよい。例えば、銀預金が口座と預金者の両方に従属している行業務
データベースを考えてみる。単一指定インデックスは、（指定されたキーｋ_１’
口座番号により）口座への、（指定キーｋ_２’預金者名により）預金者への、お
よびｋ_１’ｋ_２’とｋ_２’ｋ_１’の両方により預金へのアクセスを提供する。（
言うまでもなく、ｋ_１にとって、それがｋ_２に従属しているときにｋ_１にとって
、およびそれがｋ_１に従属しているときにｋ_２に対し異なる指名子を使用するこ
とも可能である。） 多次元レコードの指名子は、レコードを検索または更新するために使用されて
いるキーの指名子に依存する。このようにして、車レコード（ＦＩＡＴ、１２７
）の指名子は、キーＡＦＩＡＴによってレコードを検索または更新しているとき
はＡであり、ライセンスプレート番号Ｂ１２７を介してそれにアクセスしている
ときにはＢである。

【０１４５】 データレコードに加えて、メタデータを維持することが必要とされる。メタデ
ータは、その種類の関数として異なるレコードに関する情報を含む。したがって
、それは指名子を識別するために必要とされ、その結果、例えば、多様なフィー
ルド、キー、従属、レコードサイズ等の説明など、レコードに関する情報が入手
できる。指定インデックスでの検索スキームは、メタデータに気付かれない。そ
れはレコードの位置を発見し、指名子を識別し（例えば、指名子はレコードの前
に置くことができる）、（複合）指定キーを構築する。

【０１４６】 このようにして、本発明の第２態様に従って、データ処理システム上で実行さ
れているデータベースファイル管理システムにより使用される記憶媒体内では、
以下を含むデータレコードが提供される。つまり、データレコードのキーの上の
インデックス、第２型のデータレコードが第１型のデータレコードに従属する少
なくとも２つの型であるデータレコード。

【０１４７】 依然として第２態様に従って、データ処理システム上で実行されるデータベー
スファイル管理システムにより使用される記憶媒体には、以下を含むデータ構造
が提供される。

【０１４８】 つまり、指定データレコードを構成し、データレコードの指定キー上の指定イ
ンデックス、第２型の指定データレコードが第１型の指定データレコードに従属
する、少なくとも２つの型であるデータレコード。

【０１４９】 第２値用に従って、以下を含む多様な優位点が達成される。 □指定インデックスと指定データを含むデータ構造は、さまざまなデータ項目間
の関係を維持することができる。 □指定インデックスと指定データを含むデータ構造は、論理的に関連する項目を
リンクすることができる。 □指定インデックスと指定データを含むデータ構造は、複数のデータモデルを同
じにかつ効率的にサポートすることができる。 □指定インデックスと指定データを含むデータ構造は、データ完全性を維持する
上での高い効率を可能にする。 □指定インデックスと指定データを含むデータ構造は、関連データを検索する上
で高い効率を可能にする。

【０１５０】 本発明のデータベースファイル管理システムにより提供される多様な優位点に
関する詳細な説明は、特定の実施形態に関して以下に示される。

【０１５１】 データレコードが、ＰＡＩＦの一部を構成してよい、あるいは１つまたは複数
の別々のデータファイルの中に常駐してよいことに注意する必要がある。後者の
実施形態においては、データレコードは、言うまでもなく対応するＰＡＩＦｎｉ
リンクされなければならない。さらに、以下の特殊な実施形態の説明に関して明
確化されるように、指定されるデータレコードは、複数の検索キーを収容してよ
い。

【０１５２】 また、複雑なデータ構造とデータ関係が、新規の統一された簡略な技術によっ
てどのようにしてサポートできるのかも呈示されるだろう。

【０１５３】 また、インデックス構造が、どのようにすればキーのサイズによらずに、最小
のサイズであることができるのかも呈示されるだろう。

【０１５４】 前述された優位点のすべてが、データに関する予備的な考慮事項なしに本発明
によって本質的に支持される（つまり、キー範囲は未知であり、レコード数は未
知であり、データの無作為物理ロケーションが仮定される等）。

【０１５５】 依然として別の態様によって、本発明は、データ処理システムで実行されるデ
ータベースファイル管理システムにより使用される記憶媒体の中で、以下を含む
データ構造を提供する。

【０１５６】 記憶媒体に記憶され、ブロックに記憶されている前記データレコードのキーの
上で構築されているインデックス。インデックスはブロックの中に配列され、リ
ーフブロックがリンクによりデータレコードにリンクされている。

【０１５７】 前記インデックスは、前記リンクの少なくとも１つが、同じブロックに記憶さ
れている少なくとも２つのデータレコードによって共用されるという点で特徴付
けられている。

【０１５８】 １つの実施形態により、インデックスはトリーにより構成される。

【０１５９】 さらに、本発明は、データ処理システム上で実行されるデータベースファイル
管理システムにより使用される記憶媒体の中で、以下を含むデータ構造に備える
。

【０１６０】 記憶媒体の中に記憶され、ブロックに記憶される前記データレコードのキーの
上で構築されているインデックス。インデックスはブロックの中に配列され、リ
ーフブロックは、リンクによりデータレコードにリンクされている。

【０１６１】 前記インデックスは、前記リンクの少なくとも１つが、同じブロックに記憶さ
れている少なくとも２つのデータレコードにより共用されるという点で特徴付け
られている。

【０１６２】 請求項１に従って階層インデックスを構成する前記インデックス、および前記
基本区分インデックスのブロックが、前記データレコードにリンクされている。

【０１６３】

【発明の実施の形態】

本発明のデータベースファイル管理システムを使用するシステムの一般的ブロ
ック図を示している図１に最初に注目する。図示されているとおり、ペンティア
ムマイクロプロセッサ３を使用している、米国インテル社から購入できる汎用コ
ンピュータ、例えばパーソナルコンピューター（以下Ｐ．Ｃ．）は、米国マイク
ロソフト社から購入できる、プロセッサ３と連結されており、またコンピュータ
１全般を制御するオペレーティングシステムモジュール５、例えばウインドウス
ンＮＴを有している。

【０１６４】 Ｐ．Ｃ．１は、それぞれ７、９および１１のみしか図示されていない複数のユ
ーザーアプリケーションプログラムを内蔵することができる。ユーザーアプリケ
ーションプログラムは、オペレーションシステム５の制御の下でプロセッサ２に
より、本質的に公知の方法で、実行され、また出入力ポート１５とオペレーティ
ングシステム５を経由してキーボード１３により供給されるユーザーの入力に反
応する。ユーザーアプリケーションプログラムは、出入力ポート１７とオペレー
ティングシステム５を経由して、データを表示するために、更にモニター１６に
連結されている。ユーザーアプリケーションプログラムで、データベース管理シ
ステムモジュール２０によってデータベースの中に保存されているデータにアク
セスできる。一般に、図１の中で示されている、汎用データ管理システムは、ハ
イレベル管理システムとら成り、システムは、一般的に「論理的」方法で、存在
するデータを検索し、例えばＳＱＬデータ定義とデータ操作言語（ＤＤＬとＤＭ
Ｌ）のような本質的に公知のステップで、ステップによりユーザーアプリケーシ
ョンプログラムに反応する。データベース管理システムは、一般的に、本質的に
公知の方法で、存在するデータ上の情報を保持するメタデータを含むデータ辞書
２４を利用する。

【０１６５】 存在するデータの構造は、データベースファイル管理システム２６により管理
され、管理システムは、インデックススキームと実際のデータレコード２８と関
連している。ハイレベル管理システム２２により受信され処理された「ハイレベ
ル」論理命令（例えばＳＱＬコマンド）は、データベースファイル（複数を含む
）の中に保存されてるデータレコードにアクセスしたり、それを更新する「ロー
レベル」コマンドに転換され、このために、データベースファイル管理システム
は、データレコードの実際の構造と組織を考慮に入れている。データベースファ
イル管理システムの「ハイレベル」と「ローレベル」の部分は、本質的に公知の
アプリケーションプログラマーインターフェース（ＡＰＩ）例えばマイクロソフ
ト社から購入できるマイクロソフトのオープンデータベース互換性（ＯＤＢＣ）
インターフェースを経由して交信することができる。ＯＤＢＣを利用することで
、データベースファイル管理システムあるいはアプリケーションの「ハイレベル
」モジュールを、ＯＤＢＣ規格をサポートしている他の「データベース管理シス
テム」と透過的に交信させることができる。本明細書の中の用語アクセスあるい
はデータレコードの更新の範囲は、データレコード（複数を含む）の「find（検
索）」、「insert（挿入）」、「delete（削除）」および「modify（修正）」お
よび、データベースの構築と、変更とまた削除を行うことができるようにする適
切なＤＤＬ（データ記述言語）コマンドを含む全ての種類のデータ操作まで及ぶ
ものとする。図１は、また概略的に、内部メモリーモジュール２９（例えば１６
メガバイドと場合によってはキャッシュメモリーサブモジュールを使用する）と
、外部メモリー２９’（例えば１ギガバイト）の形式で記憶媒体を示している。
一般的に、外部メモリー２９は、外部の、比較的遅い通信バス（図示されていな
い）を経由してアクセスされるのに対して、内部メモリーは、より早い通信バス
（図示されていない）を経由してアクセスされる。通常、内部メモリーのサイズ
が小さいので、現在実行中のアプリケーション（あるいはアプリケーションの一
部）は、外部メモリーから、内部メモリーにロードされる。同様に、内部メモリ
ーに全部納まりきれない大きなデータベースに対しては、データベースの大部分
は、外部メモリーに保存される。従って、データベースの中の一個あるいはそれ
以上のデータを求めるアプリケーションにより生成された問い合わせに答えて、
データベース管理システムは、オペレーティングシステムサービス（即ちＩ／Ｏ
オペレーション）を使用して、外部の通信バスを経由して、一個あるいはそれ以
上のデータのブロックを、外部から内部メモリーに対してロードする。求められ
ているデータレコードが、ロードされたブロックの中に発見できない場合は、求
められているデータレコードを探し当てるまで、追加のＩ／Ｏオペレーションが
、必要である。

【０１６６】 表示を簡素化するために、内部と外部のモジュール２９、２９’が、他の種々
のモジュール５、７、９、１１および２０から分離されていることに留意しなけ
ればならない。言うまでもなく、図示されていなが、種々のモジュール（オペレ
ーティングシステム、ＤＢＭＳおよびユーザーアプリケーションプログラム）は
、外部メモリーに記憶され、あおれらの現在実行されている部分は内部メモリー
にロードされる。

【０１６７】 コンピュータ１は、また必ず図１と同じ構造を有するサーバを利用するＬＡＮ
（図示されていない）の一部を形成しているワークステーションとしての役割を
果たすことができる。ワークステーションとサーバが、プロトコルに基づくクラ
イアントサーバを利用する限り、（データベースレコード２８それ自体を含む）
諸モジュールの大部分は、サーバの中に常駐する。

【０１６８】 当業者であれば、図１を参照して前記で説明された実施形態が、可能な多数の
変形のたった二つであること分かるはずでである。従って、これに限定されない
例として、データベースを、インターネットのウェブサイトに常駐するオンライ
ンのデータベースとすることができる。本発明は、言うまでもなく、小型の内部
メモリーと大型の外部メモリーの特定の区分に限定されるわけではない。従って
、例えば、修正された実施形態として、大型の内部と外部メモリーが、使用され
、更にもう一つの改造された実施形態として、たった一個の内部メモリーが使用
される。

【０１６９】 また更に、説明を明確にするために、システム１が、簡素化され一般的な方法
で図示されていることに留意しなければならない。データベースファイル管理シ
ステムと、特に通常データベースファイル管理システムの中に収容されている様
々のコンポーネントの更に詳しい解説については、例えば「データベースシステ
ムのコンセプト」の７章を参照することができる。

【０１７０】 本発明の一般的な構造を説明したので、ここで、エンティティ関係図（ＥＲＤ
）として、また図示を目的とするサンプルデータベース構造を示している図２に
注目する。従って、図２のＥＲＤ３０は、所定のクライアントが１口以上を口座
を有していることを示しており、また同様に所定の預金が、一人以上のクライア
ントにより所有されていることとの関係を示すエンティティである、「CLIENT」
３２と「ACCOUNT」３４とまた同時に「ｎからｍ」「DEPOSIT」３６の関係から成
る。

【０１７１】 図示されているとおり、エンティティ「CLIENT」は、次の属性（フィールド）
を有している：即ち、 各クライアントを識別する重要な属性である「Client_Id」３８と、 クライアントの名前を表す「Name」３９と、 クライアントの住所を表す「Address」４０である。

【０１７２】 エンティティ「口座「は、次の属性（フィールド）を有している：即ち、 各クライアントを一意に識別するキー属性である「Acc_No」４２と、また口座
の残高を維持する「Balance」４３である。関係を保つ「DEPOSIT」は、「CLIENT
」と「ACCOUNT」のキーの複数の一対から成り、各対は、特定のクライアントが 所有する特定の預金の標識になるようになっている。

【０１７３】 ここで図３を説明する。ここには、関連データモデル３２と、３４および３６
にそれぞれに対応する３個のテーブル５０と、５ｌと、および５２でテーブル示
されている図２のデータベースが示されておりテーブルの各々には、図示を目的
として、幾つかのデータの出現が記載されている。「CLIENT」テーブルの（「Cl
ient_ID）のキーフィールドの長さが、５桁であるのに対して、「ACCOUNT」テー
ブルの（「Acc_ID）のキーフィールドの長さが、６桁であることに留意しなけれ
ばならない。クライアントテーブルには、５個のデータ出現５５−５９が、記載
され、口座テーブルには、２個のデータ出現６５と６６と、また預金テーブルに
は３個のデータの出現７０−７２が、記載されている。

【０１７４】 従来の技術に従って、各テーブルに対して、一般的に、一次キーによる異なる
インデックスファイルがある。従って、図４は、従来のＢツリー構造のインデッ
クススキームを使用するファイル管理システムによる図３の「CLIENT」テーブル
の索引ファイルを示している。図示されているとおり、索引付けファイル８０は
、ルートブロックと、また２個のリーフブロックをそれぞれ表している３個のブ
ロック８０ａ−ｃから成る。データレコードは、無作為に、５個のデータレコー
ド８３−８７を保持している別個のファイル８１に、今、ランダムに組織化され
ている。各々のブロックは、一組のフィールド連続（例えばブロック８０ａの中
の８２ａ−ｂと８３ａ−ｂ）から成る。各対の中で、第１フィールドは、検索キ
ー値を表しており、第２フィールドは、次の検索すべきブロックを識別する数字
のようなリンクを、あるいはリーフブロックの場合は、データレコードを識別す
る数字のようなデータレコードに対するリンクを表している。後者の実現は、デ
ータレコードをブロックに結び付ける限定されない実施形態を形成する。図４の
特定の実施形態の中で、１２３５５に等しいかあるいはそれ以下の数値のキーに
よるレコードの検索は、ルートブロック８０ａからブロック８０ｂに向けられる
。

【０１７５】 従って、誰のキーが１２３５５（８２ａ）であるかのレコードに対する検索は
、ルートブロック８０ａの中で開始されてから、リンク８２ａによりブロック８
０ｂに向けられる。ブロック８０ｂの中で、検索キー１２３５５（８６ａ）は、
データファイル８１の中の検索キーにより識別された各データレコードのアドレ
スを示しているリンク８６ｂと関連する。言い替えれば、検索キー「１２３２２
」（図３の中の５７）により識別されたデータレコードは、データファイル８１
の中の４番目の順序である。

【０１７６】 テーブル「ACCOUNT」と「DEPOSIT」は、同様に２個の別個のＢツリーのツリー
索引ファイルの中にそれぞれ配置される。

【０１７７】 図４のＢツリー索引ファイルは、キー（即ち検索キー）が、二重である、即ち
キーが、内部のブロック（即ちインデックススキーム）の中と、またＢツリー索
引と関連するデータレコードの中の双方で維持されると言うアプローチの重要な
欠点の一つを示している。従って、例えば、データレコード５７の検索キー（図
３の中）は、ファイル８１の中のデータレコード８６の一体化された部分として
保持されるばかりでなく、またブロック８０ｂ（検索キー８６ａ）と、場合によ
っては８０ａ（検索キー８２）のような親ブロックの中に保持される。

【０１７８】 上記の場合であると仮定して、より大きなファイル（実際生活上の多数のシナ
リオの場合である）に対して、検索キーのコピー（と特に長いキーに対する）が
、大きな保存容積を必要とし、性能に悪影響を与える膨張したインデックスとな
ることが容易に分かる。

【０１７９】 図５は、既知のトリー索引付けスキームを使用するファイル管理システムに基
づく、図３の「ＣＬＩＥＮＴ」テーブルの異なる索引付けススキームを示してい
る。従って、トリー索引付けファイル９０は、複数のノードとリンクから成り、
各ノードは、オフセット一を表しており、またリンクは、オフセットの数値を表
している。テーブル９１は４つの列を有している。第１列は、どの桁の位置が使
用されるかを示しており、第２列は、桁の数値を示している。桁数値は、キーを
２個のサブセットに分ける、列３と４は、検索手続きを次のステップに向ける。

【０１８０】 所定の検索キー、例えば１２３５５を探すために、ルートにより示されている
位置の桁（ノード９０ａにより示されている位置「５」が、またテーブル９１の
第１行目の第１列であったとして）は、同じ行の第２列で指定された数値と比較
される（数値「５」は、またトリー索引の中のリンク９０ｂにより示される）。
求められている検索キー１２３５５の位置５の桁が、実際５であるので、制御は
、行２に転送される（テーブル９１の１行目の第３列により示されているとおり
）。次に、求められている検索キーの位置３の桁は（トリーの中の９０ｃは、ま
たテーブル９１の中の２行目の第１列の数値であるとして）、数値３と比較され
る（リンクａ９０が、またテーブル９１の２行目の第２列であるとして）。整合
が起こるので、制御は、テーブルの中の３行目に転送される。ステップの中で、
求められている検索キーの位置４の桁は、ツリーの３行目の第２欄で指定された
数値と整合せず（即ち、「５」対「４」）、従って、テーブル９１の中の第４欄
の中で示されているとおり（「等しくない」）、求められているデータレコード
５７に対するリンクが、得られる。

【０１８１】 テーブル「ACCOUNT」および「DEPOSIT」は、同様に２個の別々のトリー索引付
けファイルにそれぞれ分けられる。図４のＢツリー索引付けファイルとは反対に
、図５のものは、検索キーのコピーを必要としない。言い替えれば、オフセット
とリンク値のみで、キー全体がトリー（９０）の中に保持されるわけではない。
この意味で、技術は、Ｂテクニックより優れている。

【０１８２】 しかし、すでに指摘したとおり、前記のトリーには、次の欠点を伴う、即ち、
トリーは、均整の取れた構造とするように、データベースの内容を推論で知り、
その結果キーを区分することに努力を傾注したために、均等に配分されたデータ
を保持している。図２の中で説明されている種類のデータベースが、例えば図２
の特定のデータベースに対してのような、新規のクライアントが、口座を開設し
たり、従来の得意先が、口座を解約したり、新規のクライアントが、現存の口座
の共同所有者として登録されたりするような動的な性格を有しているので、デー
タベースの内容を推論で知ることは、必要以上の束縛を生ずるので、明らかサポ
ート支援しないことである。ツリーの中を巡り回る結果、８３、８６、８７、８
４、８５（図４）の順序でアクセスすることになり、キーの順序とならない。

【０１８３】 公知のトリーインデックススキーム（図５を参照して）を示したので、次に、
基本区分インデックスから成り、前記に説明されたこれまでの公知の技術に関連
する問題点を解決する本発明の索引の種々の実施形態を下記のとおり説明する。
より具体的には、階層形態索引の索引の好ましい実施形態と、またツリー形態の
基本区分インデックスの好ましい実施形態が、示されている。これ等の例は、こ
れに拘束されるわけではない。

【０１８４】 種々の実施形態の説明に入る前に、図６Ａ−Ｃを参照して、ＰＡＩＦと呼ばれ
る新しいトリーインデックススキームを説明する。下記に示されているとおり、
ＰＡＩＦは、ツリー構造に限定されるわけではない。ＰＡＩＦに基づいて、図７
−９を参照して、ＰＡＩＦの代表キーの上の構成された代表インデックスから成
る種々の階層インデックスの実施形態が、説明される。図７から９の実施形態で
は、代表インデックスのインデックススキームと基本的に区分された索引の代表
的なインデックススキームが、ほぼ同じＰＡＩＦとなっている。

【０１８５】 図１０の中で、異なるトリーによる階層索引の更にもう一つの実施形態が説明
されている。図示されているとおり、図１０の実施形態の中で、代表インデック
スとトリーはまたほぼ同じであるが、構造は、必ずしもこのとおりでなければな
らないわけではなく、例示されているとおり、例えば図１１を参照して、トリー
と代表インデックスが異なる。

【０１８６】 ここで、図６Ａ−Ｃに戻って、ＰＡＩＦを使用するファイル管理システムに基
づく、図３の「CLIENT」テーブルの概略図の続きが示されている。「トランザク
ション」と「オペレーション」は、互換性を持たせて使用されている。

【０１８７】 下記の説明の中で、ＰＡＩＦの中でデータを操作できる、即ち新しいデータレ
コードをＰＡＩＦに挿入し、ＰＡＩＦの中でデータレコードを検索し、また現存
するデータレコードを削除する基本コマンド、を解説する。当業者であれば、こ
れ等の基本的な原始要素に基づいてより複雑なデータの操作（例えば「結合」）
を行うことができることが分かるはずである。

【０１８８】 初めに図６Ａに戻って、検索キー「１２３４５」（即ち５バイトの長さの検索
キー）を有するクライアントのデータレコード１０３（図３のクライアントテー
ブルの中の５６）が、示されている。図６ＡのＰＡＩＦは、言うまでもなく、平
凡なものであり、長リンク１０２によってデータ１０３にリンクされている単独
のノード１０１（ルートノードとリーフノードを表している）から成る。

【０１８９】 ノード１００は、検索キーの中のオフセット０を示しており、またリンク１０
２は、特定のオフセットの検索キー部分（特定の実施形態により１バイトの長さ
）の数値「１」を示している。

【０１９０】 図６Ａの中で明らかに示されているとおり、データレコード１０３は、ノード
１０１とリンク１０２から成る装置としての検索パスと関連しており、オフセッ
トと、また指定されたデータレコードの検索キーの範囲内の特定のオフセットで
対応する検索キー部分の数値と一致する関連する検索キー部分の数値を定義する
。より具体的には、検索キー「１２３４５」の範囲内のオフセット０の１バイト
の検索キー部分の数値は、本当に「１」である。

【０１９１】 ここで。図６Ｂ−１に戻って、図の中に、Client_Id_No「１２４４５」１０７
を有するデータレコードが挿入された（図３のクライアントテーブルの中のデー
タの出現５８）、連続的なトランザクションの後のＰＡＩＦ１０８が示されてい
る。データレコード１０３と１０７の検索キーは、第３バイト（オフセット２）
、即ちそれぞれ「３」と「４」の中でのみ区別される。

【０１９２】 ルートノード１０１とリンク１０２により画されている装置は、データ１０３
と１０７の双方に対するオフセット０の１バイトの検索キー部分の数値が、「１
」であるので、データレコード１０３と１０７の間を区別するのに不十分である
。それ故に、ノード１０４は、２個のレコードの間を区別する最も低いオフセッ
トを示し、またリンク１０５と１０６は、関連する１バイトキー部分はオフセッ
ト２で、「３」と「４」上で示す。ＰＡＩＦの実現が、図の中に示されている特
定の例によって拘束されず、特定の応用に応じて種々の実施方法を適用させるこ
とができることに留意しなければならない。従って、例えば、図６Ｂ−２と６Ｂ
−３は、図６Ｂ−１のＰＡＩＦを実現している他の二つのオプションを示してお
り、場合、図６Ｂ−２の中で、完全なキーが、ＰＡＩＦの中に示されている（例
えば、レコード１２４４５の全桁が、ルートノードから始まりデータレコードで
終るリンクの中に指定されている）。後者の実施形態は、より明確であるが、絶
対に必要なノードのみが示されいる図６Ｂ−３の貧弱な実施形態と比較してスペ
ースの意味で効率が低い。言うまでもなく他の変形も応用可能である。

【０１９３】 新しいデータレコードを現存するデータベースに挿入する手続きの説明に移る
前に、ことに留意しなければならない。トリーＰＡＩＦの中のノードが、高けれ
ば高いほど、ＰＡＩＦにより示されるオフセットは小さくなる（例えば、図６Ｂ
のＰＡＩＦの中で、ノード１０１はモード１０４より高く、従ってノードにはよ
り小さいオフセット−「０」対「２」）が割り当てられる。

【０１９４】 一般的には、新しいデータレコードを現存するＰＡＩＦに挿入するための好ま
しい手続きは、下記のステップの実行から成る： ｉ． ルートノードからから始りデータレコードで終るリーフノード（「参照デ
ータレコード」として参照される）に関連する参照パスに沿って進める、 参照パスの中の各ノードの中で、リンクにより示されてる数値が、ノードによ
り指定されているオフセットの１ビットの長さのキー部分の数値と等しい場合は
、ノードから発するリンクに沿って進める、 ノードの中で指定されているオフセットが、キーの中の対応するキーの部分の
何れかを超えている場合か、数値のリンクがない場合は、任意のパスに沿って何
れかの参照データレコードに進める、 ｉｉ．参照データレコードの検索キーを、新しいデータレコードの検索キーと比
較して、二つを識別する検索キー部分の最も小さいオフセットを決定する（以下
識別オフセットと称す）。 ｉｉｉ．識別オフセットの数値に従って、下記のステップの何れか一つを進める
（ｉｉｉ．０−ｉｉｉ．３）。

【０１９５】 ｉｉｉ．０ データレコードが、等しい場合は、終了するか、あるいは ｉｉｉ．１ 識別オフセットが、参照パスの中のノードの何れか一つにより示
されたオフセットと整合する場合は、一つのノードから発するもう一つのリンク
を加えて、リンクに、新しいデータレコードの検索キーから取り出された識別オ
フセットの検索キー部分の数値を割り当てるか、あるいは ｉｉｉ．２ 識別オフセットが、リンクによって参照データレコードにリンク
されているリーフノードにより示されたものより大きい場合は： ｉｉｉ．２．１ リンクを、参照データレコードから切り放して（即ち、一時
的に「開放」のままになる）、リンクを、新しいノードに移動する。新しいノー
ドには、識別オフセットの数値が割り当てられる、 ｉｉｉ．２．２ 参照データレコードと新しいノード（ここでリーフノードと
なる）を接続して、リンク（長リンク）に、参照データレコードの検索キーから
取り出された識別オフセットの検索キー部分の数値を割り当てる、 ｉｉｉ．２．３ リンクによって新しいデータレコードと新しいノードを接続
して、、リンク（長リンク）に、新しいデータレコードの検索キーから取り出さ
れた識別オフセットの検索キー部分の数値を割り当てるか、あるいは ｉｉｉ．３ ｉｉｉ．０と、ｉｉｉ．１およびｉｉｉ．２の条件が満たされな
い場合は、識別オフセットが、同時に、親ノードに割り当てられたオフセットよ
り大きく、また子ノードに割り当てられたオフセットより小さいか（ケースＡと
見なされる）、あるいは検索パスの中の全てのノードが、識別オフセットより大
きな数値を有しているような（ケースＢと見なされる）、参照検索パスの中に、
パスの親ノードと子ノードが存在する。従って下記の二次ステップを応用する： ｉｉｉ．３．１ ケースＡとＢに対して、新しいノードを生成して、ノードに
識別オフセットを割り当てる、 ケースＡのみに対しては、親ノードから子ノードへのリンクを、切り放して、
リンクを新しい内部ノードに向けて切り換える（即ち子ノードは、一時的に「開
放」のままになる）、 ＩＩＩ．３．２ ケースＡとＢに対して、リンク（長リンク）によって新しい
データレコードと新しい内部ノードに接続する。リンクに割り当てられた数値は
、新しいデータレコードの検索キーから取り出されたとおりの識別オフセットの
検索キー部分の数値である。

【０１９６】 ｉｉｉ．３．３ ケースＡとＢの場合に対して、新しいリンクによって、新し
いノードに接続し、ケースＡに対しては、子ノードに接続し、ケースＢに対して
は、ルートノードに接続し（即ち、新しいノードは、ケースＡに対しては、新し
い親ノードとなり、ケースＢに対しては、新しいノードとなる）、またリンクに
割り当てられた数値は、参照データレコードの検索キーから取り出された、新し
いノードにより示されたオフセットの検索キー部分である。ＵＵＨ 異なる参照パスに対しては、異なるＰＡＩＦを得ることができることに留意し
なければならない。

【０１９７】 より良く理解するために、前記の「データレコードを挿入する」操作は、連続
的に図６Ｂの特定のＰＡＩＦに、その都度、ステップｉｉｉ．１−ｉｉｉ．３で
規定されている３個の全く異なるシナリオを例示して、図６Ｃ−１から６Ｃ−３
の中の３個のＰＡＩＦになるように、異なるデータレコードで適用される。

【０１９８】 第１の例の中で、Ｃｌｉｅｎｔ＿Ｉｄ（あるいは検索キー）「１２５４６」（
図３のクライアントテーブル５９）を有するＣＬＩＥＮＴデータレコードは、図
６ＢのＰＡＩＦの中に挿入される。ステップ（ｉ）の中で規定されているとおり
、移動が、ルート１０１から始まり、例えば、「参照データレコード」をを表し
ているデータレコード１０３で終る参照パスに沿って行われる。操作は、ノード
１０１からリンク１０２（挿入されたデータレコードオフセット‘０’のなかで
、ｌの長さの桁の数値が‘１’である場合）に沿って進むことで実行され、それ
以降は、オフセット‘２’（ノード１０４により指定された）で、リンク１０５
と１０６（それぞれ４と３）の何れの数値も、オフセット２（‘５’）で挿入さ
れたキーと整合しないので、任意のパスで、参照データレコード１０３に向かっ
て進行が行われる（リンク１０６を経由する特定の実施形態により）。

【０１９９】 ステップ（ｉｉ）の比較操作は、オフセット２（“５”対“３”）と４（“６
”対“５”）での参照データレコードの検索とは区別される新しいデータレコー
ドの検索を生じる。最も小さいオフセット（「識別オフセット」）はそれゆえに
２である。

【０２００】 ここでステップ（ｉｉｉ）に入って、識別オフセットが、ノード１０４に割り
当てられたオフセットと等しいので、ステップｉｉｉ１の条件は、満たされる。
従って、また図６Ｃ−１の中で示されているとおり、新しいリンク１１１はノー
ド１０４を新しいデータレコード１１２に接続する。リンク１１１に割り当てら
れた数値は、新しいデータレコード１１２の検索キーの位置２のバイト値である
５である。図６Ｃ−１のＰＡＩＦ１１０は、従って、データレコード１１２を図
６Ｂ−１のＰＡＩＦ１０８へ挿入した結果である。

【０２０１】 ここで、第２例に移動して、Client_Id（あるいは検索キー）「１２３５５」 （図３のクライアントテーブルの中の５７）を有するＣＬＩＥＮＴデータレコー
ドは、図６Ｂ−１のＰＡＩＦに挿入される。ステップｉとｉｉは、前記で規定さ
れている、ノード１０１から始まりデータレコード１０３で終る参照パスとなる
。

【０２０２】 ここで、ステップ（ｉｉｉ）に入って、識別オフセット３が、参照検索パスの
中のリーフノード１０４のオフセット２より大きいので、段ｉｉｉ２の条件は、
満たされる。従って、ステップｉｉｉ．２．１とまた結果としてできた図６Ｃ−
２のＰＡＩＦ１２０に従って、リンク１０６は、参照データレコード１０３から
切り離されてから、新しいノード１２０に接続される。新しいノードには、識別
オフセット３が割り当てられる。次に、ステップｉｉｉ．２．２に従って、参照
データレコード１０３と新しいノード１２１が、新しいリンク１２２のステップ
により接続される。新しいリンクには、数値４（参照データレコード１０３の検
索キー「１２３４５」から取り出された識別オフセット３の桁数値として）が割
り当てられ、また最終的に、ステップｉｉｉ．２．３の中で規定されているとお
り、新しいデータレコード１２３が、数値「５」（新しいデータレコード１２３
の検索キー「１２３５５」から取り出された識別オフセット３の桁として）が割
り当てられたリンク１２４のステップによりノード１２１に接続される。図６Ｃ
−２のＰＡＩＦ１２０は、従って、データレコード１２３を図６Ｂ−１のＰＡＩ
Ｆ１０８に挿入した結果である。

【０２０３】 第３の最後の例は、Client_Id（あるいは検索キー）「１２３４６」（図３の クライアントテーブルの中の５５）を有するＣＬＩＥＮＴデータレコードを図６
Ｂ−１のＰＡＩＦに挿入することに関する。前記のステップｉとｉｉを適用して
、ノード１０１からデータレコード１０３（図６Ｂの中の）に進めて、識別オフ
セットが、１となるように設定する。

【０２０４】 このようにして、ステップｉｉｉの中で、ステップｉｉｉ．３の条件が満たさ
れる。それに従って、ステップｉｉｉ．３，１のとおりに、また結果として生じ
た図６Ｃ−３のＰＡＩＦ１３０の中に示されているとおり、リンク１０２は、新
しい内部ノード１３１にシフトされる。新しい内部ノード１３１には、数値１（
識別オフセットとして）が割り当てられる。ステップｉｉｉ．３．２の中で規定
されているとおり、新しいデータレコード１３２とノード１３１は、新しいリン
ク１３３によって直接接続される。リンク１３３に割り当てられる数値は、１（
新しいデータレコード１３２の検索キー「１１３４６」から取り出された識別オ
フセット１の桁として）であり、最終的に、ステップｉｉｉ．３．３に従って、
新しい内部ノード１３１は、数値２（参照データレコード１０３の検索キー「１
２３４５」から取り出された識別オフセット（１）の桁として）が割り当てられ
たリンク１３４によってノード１０４にリンクされる。

【０２０５】 図６Ａ−６Ｃを参照して上記で説明されたＰＡＩＦは、一個のブロックの中に
納めようとすればそれができないこともないが、あくまでも、データレコードが
、明確に分けられた単一のあるいは複数のファイルの中にグループ化されるよう
に、「ノード」と「データレコード」を分離することが好ましい。図６Ｃ−３の
ＰＡＩＦへのアプローチを適用することで、レコード１３２、１０３、１０７を
保持するデータレコードファイルの生成を行うことになり、リンク１３３と、１
０６および０５は、無論長リンクとなる。

【０２０６】 言うまでもなく、挿入手続きが、挿入されるべきデータレコードが、既にＰＡ
ＩＦの中に存在してることを検索することになり、適切なエラーメッセージが、
挿入コマンドを発した手続きに帰って来る。

【０２０７】 後者の例の中で、全ＰＡＩＦが、単独のブロックの中に常駐していることを前
提条件とすることに留意しなければならない。言うまでもなく、追加のデータレ
コードが、前記の「挿入手続き」に続いてつ挿入されたときは、ブロックからオ
ーバーフローする可能性があり、このオーバーフローに対応するために、「ブロ
ック分割」手続きに訴える必要が生じ、その後で、探すブロックに進めてから、
上記で説明されている方法で挿入手続きを実行すことが必要である（下記で詳し
く解説される）。

【０２０８】 一般的な「挿入」トランザクションを説明したので、「データレコードのＦｉ
ｎｄ（あるは検索）」トランザクションをここで説明する。従って、所定の検索
キーで、現存するＰＡＩＦの中でデータレコードを検索するために（以下記レコ
ードを探すと称す）、下記のステップを実行しなければならない： ｉ． ルートノードから始まってデータレコードで終る検索パスに沿ってリー
フノードに進め、また検索パスの中の各ノード（以下「現在ノード」と称す）に
対して、下記の二次ステップを実行する： ｉ．１ 現在ノードをルート元とする各リンクに対して、 現在ノードの数値により定義されているオフセットの所にある求められているデ
ータレコードの検索キー部分を、リンクに割り当てられた数値と比較する、 整合した場合は、リンクに沿って進めてから、ステップｉ．１に戻る。

【０２０９】 ｉ．２ 現在ノードをルート元とする何れのリンクも、求められているデータ
レコードの検索キー部分と整合しない場合は、「見あたらない」に戻って、検索
手続きを打ち切る。

【０２１０】 ｉ．３ データレコードに到達した場合は（以下「参照データレコード」と称
す）、求められているデータレコードの検索キーを全般的に参照データレコード
のキーと比較する、 ｉ．３．１ 「発見された」に戻った場合は（「検索」の場合は、またデータ
レコード全体を戻す）、検索手続きを打ち切るか、あるいは ｉ．３．２ 整合せず「見あたらない」に戻った場合は、検索手続きを打ち切
る。

【０２１１】 より良く理解するために、「find」の手続きを、それぞれ「発見した」あるは「見 あたらない」が起こるように図６Ｃ−３の特定のＰＡＩＦに対して2回行う。

【０２１２】 従って、検索キー「１２４４５」によるデータレコード（以下求められている
データレコードと称す）の発見を考察する。ステップｉ．１に従って、求められ
ているデータレコードのルートノード（オフセット０）に割り当てられたオフセ
ットの桁「１」の数値が、リンク１０２（ノード１０１をルート元とする唯一の
リンクである）に割り当てられたものと比較される。整合が、発見されれば、制
御は、ノード１３１にシフトされる。再び、ステップｉ．１に従って、求められ
ているデータレコードのノード１３１に割り当てられたオフセット（オフセット
１）の桁の数値（「２」）が、リンク１３４に割り当てられたものと比較される
。ここで、また整合があれば、制御はノード１０４にシフトされる。次にステッ
プｉ．１に従って、求められているデータレコードのノード１０４（オフセット
２）に割り当てられたオフセットの桁「４」の数値が、ノード１０４をルートと
する各リンクに対して比較される。比較の結果、リンク１０５に整合したため、
制御はデータレコード１０７にシフトされる。

【０２１３】 ステップｉ．３に従って、求められているデータレコードの検索キーとデータ
レコード１０７の検索キーが、比較され、整合すれば、「発見」の結果が戻る（
ステップｉ．３．１） ここで第２例に入って、求められているデータレコードが、検索キー「１２４
６３」を有している場合を考察する。前記の例を参照して説明された手続きが、
反復されるが、ステップｉ．３で、求められているデータレコードとデータレコ
ード１０７の間を比較することで、不整合が生じて、ステップｉ．３．２に従っ
て、「見あたらない」結果に戻る。

【０２１４】 一般的な「データレコード削除」トランザクションを、ここで説明する。従っ
て、第１段として、「データレコード検索」トランザクションを、ＰＡＩＦに対
して行う。「見あたらない」の場合は、適切なエラーメッセージが、「削除」コ
マンドを発した手続きに帰って来る。そうでない場合は、求められているデータ
レコードが、発見される。「削除」手続きの説明を明確にするために、下記の名
称の一覧表が、導入される： 求められているデータレコードにリンクされているリーフノードは、「ターゲ
ットノード」と称す、 ターゲットノードの親ノードは、「先輩ターゲットノード」と称す。

【０２１５】 先輩ターゲットノードをターゲットノードと結び付けるリンクは、「先輩リン
ク」と称す、またターゲットノードを親の子ノードに（あるは求められいるデー
タレコード以外のデータレコードに）結び付けるリンクは、「ターゲットリンク
」と称す。名称を念頭に置いて、下記のステップが、実行される。

【０２１６】 ｉ． 求められているデータレコードとターゲットノードをリンクに結び付け
ているリンクを削除する、 ｉｉ．ターゲットノードの中に残っているリンクの数が、２と等しいかそれ以
上である場合は、削除手続きを打ち切る、 ｉｉｉ．他方、ターゲットノードの中に残っているリンクの数が、丁度１であ
る場合は（即ち１個のターゲットリンク）、 ｉｉｉ．１ 先輩ノードからの先輩リンクを子ノード（あるいはデータレコー
ド）に結び付けることでターゲットノードを「バイパス」する、また ｉｉｉ．２ ターゲットノードとターゲットリンクをを削除して、削除手続き
を打ち切る。

【０２１７】 ブロックの中の他のノードとリンクにターゲットノードを割当ることができる
ように、ターゲットノードとリンクに占有されるスペースを空けておくために、
使用中のステップが、より「控え目なメモリー管理」ステップであることに留意
しなければならない。更に、ステップ（ｉｉｉ）が、オプションであることに留
意しなければならない。

【０２１８】 より良く理解するために、前記の「データレコード削除」手続きを図６Ｃ−３
の特定のＰＡＩＦに対して行う。

【０２１９】 従って、コマンド「検索キー＝「１１３４６」を有するレコード削除」に対応
して、後者のレコードは、前記で説明されている手続きに従ってＰＡＩＦの中で
検索される。レコード１３２が、発見され、前記のステップｉに従って、データ
レコードとまたデータレコードに導くリンク１３３の双方は、削除される。後者
の削除ステップの後で、ターゲットノード１３１は唯一のターゲットリンク１３
４のみと共に残り、ステップｉｉｉとｉｉｉ．１を行い、従って、先輩リンク１
０２は、ターゲットノード１３１をバイパスして、直接先輩リンクの子ノード１
０４にリンクされる。

【０２２０】 次に、ステップｉｉ．２に従って、ターゲットノード１３１とターゲットノー
ド１３４が、削除され、削除により、図６Ｂ−１のＰＡＩＦを得る。 もう一つ
の例が、図６Ｃ−１のＰＡＩＦを参照して示される。従って、コマンド「検索キ
ー＝「１２５４６」を有するレコード削除」に対応して、後者のレコードが、前
記の手続きに従ってＰＡＩＦの中で検索される。データレコード１１２が発見さ
れ、前記のステップｉに従って、データレコードとまたデータレコードに導くリ
ンク（１１１）の双方が削除される。それ以降、ステップｉｉの中で規定されて
いるとおり、ターゲットノード１０４の中に残っているリンクの数は、２であり
（即ち１０５と１０６）、それから削除手続きが打ち切られる。結果として生ず
るＰＡＩＦは、また図６Ｂ−１の中に示されている。

【０２２１】 もう一つの共通の原始要素は、「現存データレコードの訂正」、例えば現存す
るクライアントの自宅住所の変更である。「訂正」原始要素は、通常選択的に前
記の原始要素を使用することで実行される。「訂正」コマンドを実行するために
、下記の場合を区別しなければならない： １．「訂正」は、検索キー（例えばClient_Id=「xxxxx」を有するクライアント
の住所変更）以外のフィールドに適用される。この場合、訂正手続きは、単に「
Find」操作を必要とするだけである（Client_Id=「xxxxx」を有するデータレコー ド）。求められているデータレコードが発見されたら、住所は、新しいものと交
換される。

【０２２２】 ２． 「訂正」は、（例えば、口座番号のｘｘｘｘｘ」から「ｙｙｙｙｙ」に
変更する）検索キーに適用される。このコマンドは、２個の原始要素の連続とし
て実行される、即ち、口座番号のｘｘｘｘｘを有する」データレコードの削除し
てから、「口座番号」「ｙｙｙｙｙ」を有するデータレコードを挿入したり、そ
の反対を行う。言うまでもなく訂正トランザクションが、双方の場合から成るこ
ともある。

【０２２３】 前記の例の中で、各々の検索キーは、直列バイトとして示されるので、検索手
続きは、各々が少なくとも１バイトから成る検索キー部分を区分することで実行
される。

【０２２４】 当業者であれば、バイトのみが可能な検索キーの表現ではないことが分かるは
ずである。従って、例えば、検索キーを、２進形式で表現させることができる、
即ち１と０の直列であり、従って、検索手続きの各々は、１ビット（即ち１＝１
）あるいはそれ以上の、例えば１バイト（即ち１＝８ビット）とその他から成る
。場合によっては、ｌ数値が、ＰＡＩＦの中の全てのノードに対して同じでない
ことがしばしばある。

【０２２５】 更に、関連する検索キー部分が、対応するノードにより知られている限り、所
定のＰＡＩＦの中の種々のリンクが、種々の長さの検索キー部分に割り当てられ
ることがあることに留意しなければならない。

【０２２６】 図６Ａ−６Ｃの種々のＰＡＩＦから明かであるように、データレコードは、検
索キーに従って仕分け（昇順あるいは降順）された形態で記憶および保持される
。例えば図６３−ＣのＰＡＩＦの中を巡ることで（右から左へ）、順序立った数
字順の「１１３４６」、「１２３４５」と「１２４４５」となる。特性は、デー
タレコードが、仕分けされていない図５のツリーと比較してデータ操作を容易に
するもう一つの利点を構成する。前記で指摘されているとおり、ＰＡＩＦの中の
ノードは、必ずしも独特な方法で分類する必要はない。従って、例えば図６Ｃ−
２のＰＡＩＦ１０２の中で、ノード１０４は、同時にリーフノード（データレコ
ード１０７への長リンク１０５ステップによりリンクされた）とまた内部ノード
（ノード１２１への短リンク１０６によってリンクされた）である。

【０２２７】 当業者であれば、本明細書の中で説明されている「挿入」、「削除」、「検索
」と「訂正」手続きが、手続きを実行するための多くの可能な変形の中の一つに
過ぎず、また特定の実行に合わせて必要に応じて適切に変更できることがすぐに
分かるはずである。

【０２２８】 特定の挿入、削除と検索トランザクションは、ブロック間トランザクションと
呼ばれるものに応用される。下記に詳しく説明されいるとおり、ブロック間の意
味でのブロック間トランザクションには、ブロック間オペレーションに無関係の
シナリオへの取り組みを殆ど必要としない。

【０２２９】 ＰＡＩＦトリーの構造を説明したので、本発明に従った種々の実施形態の説明
は、ＰＡＩＦツリー（基礎的区分された索引としての）から成る階層インデック
スを基礎とするＰＡＩＦインデックススキームが示されている下記のとおりであ
る。

【０２３０】 ここで図７Ａ−Ｈに入り、そこには、本発明の一つの実施形態に従って分割
されたブロックオペレーションの連続に答えて構築された階層インデックス略図
が示されている。例えば、メモリーのスペースの意味でオーバーフローした図７
Ａの中のブロック１４０（基本区分インデックスの中で）を考察する。これは、
ルートブロック１４４と、また直接リンク１４５によってリーフブロック１４６
にリンクされ、また長リンク１４７によってリーフブロック１４８にリンクされ
たコピー済みノードＡ’（か５５）ら成る図７Ｂの階層インデックス１４２とな
る「分割ブロック」手続きが開始される場合である。

【０２３１】 特定の例により、分割ポイントが、リンク１４９（図７Ａ）（以下「分割リン
ク」と称する）であるように選択されており、分割により、ノードＡ、Ｂ、Ｅ、
ＤとＦを新しいブロック１４６と、またノードＣ、Ｇ、Ｉ、Ｊ、Ｋ、ＬとＨとま
た新しいブロック１４８に切り換える。分割リンクは、できれば新しいブロック
の間でノードとリンクのほぼ均等な配分を達成するように選択されることが好ま
しい（例えば、ブロック１４８と１４６の中に常駐する副ＰＡＩＦのサイズが、
ほぼ同じになるように）。親ブロックが存在しない場合は、親ブロック−１４４
（Ｉ１を形成する）が、分割ノードＡ’（１５６）のコピー済みノードＡ’（１
５５）で生成される。分割リンクをルートとするコピー済みノードが、未だ親ブ
ロック１４４の中に常駐していない場合は、ノードが、後者のブロック（Ａ’と
マークされた）にコピーされ、Ａ’（１５５）ノードとＡが中に常駐しているブ
ロックの間の結合が、直接リンク１４５によって実行される。分割リンク１４９
（ＡとＣの間の元々短いリングである）は、長リンク１４７また中にＣが常駐す
るブロックに交換される。オプションとして、ノードＡとＣ（それぞれ１５６と
１５３）を、破線１５０でマークされている分割リンクによってリンクさせるこ
とができる。

【０２３２】 正味の効果は、図７Ｂの中で、ブロック１４４により構成されている階層イン
デックスが、設けられており、トリーのブロックが１４６と１４８であるること
である。当業者であれば、ここで、トリーを経由しないで（即ちノードＡ１５６
から始まる）、むしろ階層インデックスを経由して（即ちノードＡ’１５５から
始まる）、データレコードをアクセスあるいは更新することが可能であることが
容易に分かるはずである。オペレーションに関連して、リンク１４７が、今度は
図７Ａの元のリンク１４９の数値を有するリンク１５０と同じ数値を有している
ことに留意しなければならない。

【０２３３】 ここでブロック１４８が、オーバーフローし、ブロックが、図７Ｃの中の階層
インデックス１５１を生み出す同様の分割手続きを受けることを考察する。この
例により、分割リンクは、図７Ｂの短リンク１５２であり、従って、ノードＣと
Ｈは、図７Ｃのブロック１４８Ａの中に中に常駐する一方で、ノードＧ、Ｌ、Ｋ
、ＬとＪはブロック１４８Ｂの中に常駐する。分割リンクをルートとするノード
（図７ＢのノードＣ−１５３）は、コピーされ（図７Ｃのコピー済みノード１５
３ａを作りだしながら）、またＣとマークされたブロック１４０の中に置かれる
。前記と同様に、直接リンク１５４は、コピー済みノードＣ’１５３ａをルート
の分割ノード１５３のブロック１４８Ａに接続する一方で、リンク１５５は、分
割ブロック１４８Ｂから遠リンクであり、リンクの数値は、分割前の（と後の）
ノードＣとＧの間のリンク１５２の元の数値と同じである。

【０２３４】 図７Ｃの中で、階層インデックスは、ブロック１４１、１４８ＡおよびＩ_０ を形成している１４８Ｂと、またトリーの共通キーにわたって代表インデックス
を形成しているブロック１６から成るトリーにより構成されいる。

【０２３５】 図７Ｃの中で、ブロック１４１の中のノードＡと、またブロック１４８Ａの中
のノードＣが、オプションとして切り放されており、同様に１４８ＡのノードＣ
と、また１４８ＢのノードＧが、オプションとして切り放されれいることに留意
しなければならない。明らかに示されているとおり、ノードＡ’とＣ’は、ブロ
ック１４０の中で接続され、（結合されている）トリーを形成しており、また、
従ってノードＡ’と直接リンク１５６を経由してブロック１４１を、またノード
Ａ’、Ｃ’と直接リンク１５５を経由してブロック１４８Ｂを、またノードＡ’
、Ｃ’と直接リンク１５５を経由してブロック１４８Ｂにアクセスすることが可
能である。ノードＡ’とＣ’の間（ブロック１４０の中の）のリンクの数値が、
ノードＡとＣの間の元の数値と同じであることに注目する必要がある（図７Ａの
中のリンク１４９参照）。

【０２３６】 図７Ｃの中で明らかに分かるように、結果として作り出された階層インデック
スは、ブロックの均衡が取れた構造を構成しており、構造により、インデックス
の深さを最低限度に抑えており、その結果、所定のデータレコードを検索し、挿
入しあるは削除するのに必要とするアクセスの数を最小限度に抑えている（通常
、必ずしも必要としない出入力オペレーション）。ここで、データレコードにア
クセスするために、階層インデックスが、レコードの数に応じてほぼ対数機能を
維持しており、階層インデックスが、所定のデータレコードのアクセスに要する
出入力オペレーションの数の意味で、トリーを経由するデータレコードのアクセ
スに要する出入力オペレーションの数と比較して、より効率的であるることを考
察する。従って、例えば、階層インデックスを経由してノードＪと関連するデー
タレコードにアクセスするために、最初にブロック１４０とその後にブロック１
４８Ｂを、またその後で求められているデータレコードにアクセスすることが必
要である（即ち、３個の出入力オペレーション）。反対に、トリーを経由して同
じデータレコードにアクセスすることで、４回の出入力アクセスが起こる、つま
りブロック１４１、ブロック１４８Ａとブロック１４８Ｂとデータレコード１５
９である。図示されているとおり、トリーがより効率的であるという特定の例が
ほとんどないが（例えば、ノードＡに関連するデータレコードにアクセスする）
、トリーが大きくなればなるほど（即ちより多数のブロックで構成されている）
、階層インデックスの索引を経由するアクセスが、より効率的である。

【０２３７】 図７の特定の実施形態により、代表インデックスとトリー（基本区分インデッ
クスの実施形態の一つとしての）は、同じインデックススキーム、即ちＰＡＩＦ
とほぼ一致する。下記に図９Ｇを参照して説明されるとおり、「ほぼ」同じスキ
ームにより、一部の差があることを意味する。

【０２３８】 ノードをより高い階層索引Ｉｊにコピーすることに関する考察は、更に、図７
Ｄから７Ｈの中の追加の図示を参照して説明される。中でブロックの分割が実行
される図７Ｄの階層インデックスを考察する。結果として生まれた階層インデッ
クスは、図７Ｅの中で示されており、図の中で、ブロック４０２が、作り出され
、、ノード４０１がより高いレベルのブロック４０２（階層インデックススキー
ムの一部を形成する）にコピーされ、ノードＢとＥの間の元のリンクは、オプシ
ョンとして維持される（破線リンク４０３を経由して）。ノードＢを経由して、
ここで、それぞれリンク４０７と４０８によって、トリーの２個のブロック（４
０５と４０６）にアクセスすることができる。

【０２３９】 つぎに、ここでブロック４０５を、例えばリンク４０９で分割しなければなら
ず、結果として生まれた構造は、ここでブロック４０２の中で、ブロック４０５
のノードＡとＩが、ブロック４０２のＡ’Ｉ’（４１０と４１１）にコピーされ
る図７Ｆのブロック４０２の中に現れる。ノードＩ’は、明らかにブロック４０
５の中の分割されたノードＩのコピー済みノードであるが、ノードＡは、ノード
Ｂ（対象となるＢ’が推論的にブロック４０２の中に常駐している）とまたＩ（
そのＩ’が、ここでブロック４０２にコピーされている）が、Ａの子孫のノード
であること考えると、またコピーされる。ノードＡが、ノードＢとＩの最も低い
祖先ノードであるとして、（結合されている）トリーが、ブロック４０２の中で
形成される。短リンク１４１に関連する数値（ブロック４０２の中のブロックＡ
’とＢ’の間の）は、リンク４１２（ブロック４０５の中のＡとＢの間の）と同
じ数値である。リンク４１５の数値（ノードＡ’とＩ’の間）は、ノードＢにア
クセスするのに必要な方向にあるノードＡををルートとするリンク４１３の数値
と同じである。ブロック４０２の内部の構造は、ブロック４０５、４０６と４０
７の代表を検索できるようになっている。

【０２４０】 ノード４１０が、アクセスパスの中に維持されていることからして、直接リン
ク４１８に沿ってブロック４０５に移動できるので、ノード４２２と４１１の直
接リンク４１６、４１７は、オプションとして、保持されている。

【０２４１】 図７Ｇは、図７Ｆのブロック４０７（リンク４２０の中の）を分割した結果と
した生じた階層インデックスを示しており、図７Ｈは、ブロック４０２を（ノー
ドＩ’とＮ’の間のリンクの中で）分割した結果として生じた階層インデックス
を示している。図７Ｈの中の結果として生じた階層インデックスは、図示されて
いるように３個の階層を有しており、第１のものは、ブロック４３０から成り、
第２のものは、ブロック４０２と４０８から成り、トリーは、ブロック４０５、
４０７、４２６と４０６から成る。

【０２４２】 当業者であれば、分割ブロックを実現する方法が、無論図７Ｄから７Ｈの例に
限定されないことが容易に分かるはずである。

【０２４３】 （図７を参照して）挿入トランザクションの連続の結果生まれた分割プロセス
により階層インデックスを構築する実施形態を説明したので、反対の手続き、す
なわち、データレコードが、ノードに関連するデータレコードを有さないたった
一個のノードをブロックの中に残して削除されたとき、即ち「ブロック削除」が
、作動させられることが分かる。

【０２４４】 当業者であれば、図７を参照して説明された階層インデックスが、代表インデ
ックスと基本区分インデックスが、ほぼ同じである階層インデックスを実現する
ための多数の可能な変形の唯一のものであることが容易に分かるはずである。

【０２４５】 特定の方法の中のＰＡＩＦの使用は、このようにして達成された階層インデッ
クスが、トリーが本質的に均衡を失う可能性があるという事実にもかかわらずブ
ロックの均整の取れた構造を有しているという意味で今までの公知のトリーより
優れた利点を構成する。

【０２４６】 ここで、本発明の技術の本発明の他の実施形態に対する応用を例示している関
連する２個の図を示している図８Ａ−ＢＢに注目する。

【０２４７】 従って、図８Ａは、図示されているとおり、均衡が失われている、即ち、３個
のブロックの深さ（２６０、２６１と２６２）対２個のブロックの深さ（２６０
と２６４）の均衡が失われている、垂直の方向（即ち垂直ツリーを構成する）を
有する所定にトリー構造を示している。下記の説明の目的は、特定の垂直ツリー
の検索スキームを説明することではなく、均整の取れた階層インデックスを得る
のに必要な面のみを強調することである。しかし、トリー構造２６０の中のノー
ドが、図８Ａの中で示されているデータレコード（ａ−ｋ）の半バイトサイズの
中ののオフセットを意味していることに留意しなければならない（ノード数値は
、１６進法で示されている）。

【０２４８】 図８Ａの中で図示されているデータレコードｂにアクセスするための１個のブ
ロック（あるいは３個の入出力オペレーション）と比較して、データレコードｋ
にアクセスするための、追加の一個の出入力オペレーション（あるいは３個の出
入力オペレーション）、即ち、３ブロックにアクセスすることが、均衡が取られ
ていると見なされていることに留意しなければならない。一部の実生活のシナリ
オの中で、全く同じ数の出入力オペレーションを必ずしも本発明を応用すること
を必要としない。言うまでもなく、本発明の技術で処理されないと、これ以上の
データレコードの挿入が、より高い「均衡が失われた」程度を生み出す恐れがあ
り、前記で詳しく説明されたとおり（従来の技術を参照して）、劣化した性能を
招く（不均衡構造のために）。図８は、本発明の一つの可能な実施形態を示して
いる。図示されているとおり、１個のブロック２７０（Ｉ１を形成している）か
ら成る代表インデックスは、ルートブロック２７０から全てのより低いレベルの
垂直ツリー（後者は不均衡なツリーを構成している）が、出入力オペレーション
を経由してアクセスされるルートブロック２７０を有する水平的に均衡が取れて
いるツリーが得られるという結果で構成されている。

【０２４９】 図示されているとおり、最初の垂直ツリー（トリーとしての）の中の諸ブロッ
クに対する実際のアクセスは、各々のブロックの共通キー数値によって達成され
る。これ以上進む前に、共通項キーは、図８を参照して例示されている。

【０２５０】 ブロック２６０の共通キー（半バイト単位の１６進表示）は、Ｏｘ４が、文字
Ａのバイトの最も有意なビットとし、Ｏｘ１が、文字Ａのバイトの最も無意味な
ビットであり、またＯｘ３が、データレコードのオフセット２の中に常駐する文
字の最も有意なビットを表すものとして、Ｏｘ４、Ｏｘ１とＯｘ３である。

【０２５１】 ブロック２６６を経由してアクセスできる全てのデータレコードが、前記で規
定されている共通キーのプレフィックスを共有していることに留意しなければな
らない。

【０２５２】 同じ方法で、下記のテーブルは、各ブロックの共通キーの概略を記載している
：

【表１】

【０２５３】 ブロック２６１が、数値８のルートノードを受け入れることができ、従って、
ブロックの共通キー、以下ｋが、Ｏｘ４、Ｏｘ１、Ｏｘ３、Ｏｘ３、Ｏｘ３、Ｏ
ｘ３、Ｏｘ３、Ｏｘ３に変わるること、即ち、８単位になること留意しなければ
ならない。この場合、Ｉｌの中のブロック２６１の代表を、そのとおりに変えな
ければならない。異なる実施方法の中で、８の数値を有するルートノードが存在
しなくても。２６１の代表は、ｋである。

【０２５４】 共通キーを横断する索引は、キーが、最初の垂直ツリーの共通キーをアドレス
するトリーを構築するように、代表インデックス（ブロック２７０から成る）の
中で達成される。ここで、例として、データレコードｇを見つけ出すために、ノ
ード２９０、リンク２９１からノード２９２を追う。それから、直接リンク２９
３で、データレコードｇに関連するブロック２６１に進める。結果として生ずる
階層インデックスは、均衡である。

【０２５５】 前記で規定されているとおり、トリー特定の場合に対して、ブロックの代表的
キーは、共通キーである。一般的に言って、ブロックの共通キーは、関連するイ
ンデックススキームによりブロックからアクセスできるデータレコードのすべて
のキーの内で最も長いプレフィックスである。ＰＡＩＦに対して、特定のプレフ
ィックスサイズ（ビットの長さ単位で計算された）は、ブロックの中のルートノ
ード（呼び出されたホールドオフセット値としての）の数値と等しい。プレフィ
ックスサイズが、ビットの数で表現されてる場合は、プレフィックスサイズは、
１ビットの長さの数値を掛け合わせたオフセット値として計算される。

【０２５６】 ここで図９Ａ−９Ｇを参照して、本発明の階層インデックスの構築するもう一
つの実施形態の説明が続く。

【０２５７】 従って、ここで、ＰＡＩＦ（不均衡構造となり易い）トリーを構成している）
上の変更（挿入）トランザクションの連続と、またそのようにして得られた階層
インデックスを示している図９Ａから９Ｇに注目する。説明を容易にするために
、データレコードは、トリーの一部を形成して示されている。前記で規定されて
いるとおり、中でデータレコードが、トリーに関連している実際の方法は、特定
の適用次第で変わることがある。

【０２５８】 下記の数字の中で、階層インデックスは、連続的に下記の仕分けされていない
データレコードＡ−Ｆ（説明を簡素にするために、ブロックの一部を構成してい
る）を挿入することで構成されている。データのストリングは、１ビットの部分
が１を表しているビットの連続で示されている： Ａ＝００１００００１１ Ｂ＝１１００１１１００ Ｃ＝０１１０１１１１１ Ｄ＝０１１０１１０１１ Ｅ＝１０１０１０１０１ Ｆ＝１１１１１１１１１ 第１ステップの中で（図９Ａ）、レコードＡが、後でブロック３００である挿
入され、数値０を有するリンク３０２を経由して第１レコードＡと関連するオフ
セット０を有するノード３０１から成る。この段階で、ツリーは、たった一個の
ノードを有するブロック１００から成る。インデックススキームは、それぞれリ
ンク３０２とノード３０１上で図示されているとおり、データレコードＡへの検
索が、オフセット０の数値０に従って決定されるように支配する。

【０２５９】 その後（図９Ｂ）、データレコードＢが、挿入され、データレコードＡから明
らかに見ることができ、区別できるとおり、挿入の中で、ゼロオフセットの中で
、キー値が１であり、従ってリンク３０２は、データレコードＢに導き、数値１
を割り当てる。

【０２６０】 その後（図９Ｃ）、データレコードＣが、挿入され、オフセット１の中のレコ
ードの数値は、レコードＡから区別する役割を果たす。リンク３０３と３０４は
、ノード３０５（オフセット１を表す）を特定のデータレコードＣとＡにそれぞ
れ結合する。ブロック３００が、ノード３０１と３０５を受け入れるので、ブロ
ックを分割する必要はまだない。

【０２６１】 次に、データレコードＤが、挿入され、挿入オペレーションの後のブロックの
構造は、図９Ｄの中に示されている。しかし、データブロックが、２個以上のノ
ードを受け入れることができないので（オーバーフローが起こる）、ここでは、
ブロックを分割する必要がある。図９Ｅは、分割後のツリー構造を示している。
従って、リンク３０６は、半ブロックの内容が、ブロック３００の中に保持され
、また残りの半ブロックの内容が、他のブロック３１０に移される誘因を有する
分割リンクである。言うまでもなく、他のリンクを、分割リンクとするように同
様に選択することができる。

【０２６２】 第１段階として、Ｉ_０のブロック３００が、２個のブロック３００と３１０に
交換される。ノード０，１（３１１と３１３の符号が付けられた）とデータレコ
ードＡとＢは、分割ブロック３００の中に保持される一方で、ノード６、データ
レコードＤとＣ（この特定の実施形態の中では、残りのノードを表す）は、ブロ
ック３１０に移動させられる。従って、図９Ｅの基本区分インデックスは、ここ
で、２個のブロック３００と３１０（事実、不均衡なトリーを形成する）から成
る。

【０２６３】 その後、ブロックＢ_１が、存在しないので、ブロックが生成され、従って、ブ
ロック３１２が設けられる。分割ノード（３１３）は、ブロック（３１２）にコ
ピーされ、コピーにより、コピー済みノード（３１４）を構成する。次に、コピ
ー済みノード（３１４）は、直接リンク３１６によってブロック３００に接続さ
れ、コピー済みノード３１４は、遠リンク３１８によって、ブロック３１０にリ
ンクされる。遠リンクは、図９Ｅの中に破線でマークされている元の分割リンク
３１６に取って代わる。遠リンク３１８の数値は、分割リンクの数値と同じであ
る。。従って、代表インデックス（ブロック３１２で構成されている）で、基本
区分インデックスの共通キーに従って検索することができる。

【０２６４】 分割リンクを削除すべきか残すべきかどうかに関して制約が全くないことに留
意しなければならない。図示されているとおり、階層インデックス（ここではブ
ロック３１２、３００と３１０上で、代表インデックスに所属する３１２から成
るもの）を構成する、方法で得られた水平ツリーは、均衡する。

【０２６５】 次に、データレコードＥが、挿入される。場合は、ブロック３１２の第１ノー
ド（数値１を有する）からの３１４水平ツリー（階層インデックスの形態の一つ
としての）の中の遠リンク３１８のステップによる前進は、前進が、ノード３１
４（１を有する）数値からの方向１に相当し、方向０のリンクが必要であるので
、不可能である。従って、直接リンク３１６のステップによりブロック３００に
前進する。従って、新しいデータレコードと関連するブロックが、発見される。
同じ方法で、データレコードＦは、挿入されて、図９Ｆの中で示されているツリ
ー構造となる。

【０２６６】 次に、ブロック３００のノード３２０とノード３１２の間の分割が、実行され
た場合は、ノード３２０は、ブロック３１２のノード３１２にコピーされる（図
９の中で３２３の符号が与えられている）またノードが、ブロック３１２のノー
ド３１４にリンクすることができないので（リンクが、ノードの正しい相互間の
リンクを保持しないので）、ブロック３００のノード３１１が、またブロックの
共通キーに従って検索スキームでブロック３００、３２６、３１０に対して検索
を行うことができるうようにするトリー（接続された）を生成するために、ブロ
ック３１２（図９の中で３２２の符号が与えられている）にコピーされる。

【０２６７】 また、図９Ｇの中のブロック３１２の全てのコピー済みノード３１４、３２２
、３２３からの直接リンクを有する代わりに、ノード（３２２）からブロック３
００にコピーされた一個の直接リンクを有することで充分であることに留意しな
ければならない。ノード３２３からの遠リンク３２４が、分割前のリンクの方向
（図９Ｆのリンク３１５の方向）にブロック１２６に設定される。言うまでもな
く、もしもう一つの分割が、ブロック３２６の中で実行された場合は、分割は、
Ｂ_ｉ−１とブロックＢ_ｉ−１への遠リンクへの直接リンクを有する方向１のリン
クによりノード３２３から結合されているノードによりブロック３１２の中で示
される。

【０２６８】 図９Ａ−Ｇと８Ａ−Ｂは、階層インデックスを構築することによる本発明の均
衡している機構を維持する分割ブロック機構を実現する多数の可能な方法の中の
２個を示している。もう一つの限定されない変形を採用するのに当たっての柔軟
性は、例えば図８Ｂの中に示されており、図の中で、近リンク２７１と直接リン
ク２７２は、リンク２７１の方向で遠リンク２７３により示されていおり（破線
でマークされている）、従ってノード２７６を余分のものにしている。

【０２６９】 多数の実施形態に関する限り、本発明の均衡技術は、そのようにして得られた
、「確率的アクセス」と呼ばれる特性の、水平の均衡指向のデジタルツリー（階
層インデックス構造の形態の一つとして）に与えられれいる。このことは、入力
データレコードに関する検索（例えばデータレコードＡに対する検索）が、異な
るデータレコードあるいは、検索スキームにより規定されている方向に対するリ
ンクがなく、また究極的に求められているデータレコードにアクセスするために
「訂正」を行う必要があることもあるノードに導く可能性があることを意味する
。

【０２７０】 前記をより良く理解するために、例えば、図９Ｅを考察する。例えば、検索ト
ランザクションが、求められているデータレコードＬ＝１１１０１１１０で図９
Ｅの階層インデックスに応用されることを考察する。検索パスが、ノード３１４
とリンク３１８（それぞれオフセット１数値１）に続き、それからオフセット‘
６’で（ブロック３１０のルートノード）、リンク３１９（数値‘１’）を経由
してデータレコードＣに続く。後者の例は、このようにして得られた階層インデ
ックスの確率的検索特性を例示している。

【０２７１】 特定の故障を解決するために、求められているデータレコードのキーの共通プ
レフィックスのサイズとデータレコードのキーが、計算される、ブロック（３１
０）の共通キーは、実際のデータレコードＣのキーのプレフィックス部分である
。従って、共通プレフィックスのサイズはゼロである。次にツリーを、直接リン
クを有する共通プレフィックスのサイズに等しいかそれ以下の数値を有するアク
セスパスの中でノードまで遡る。後者の必要条件が、満たされない場合は、即ち
、全てのノードが、計算されたプレフィックスのサイズより大きい数値を有して
いる場合は、直接リンクを有しているアクセスパスの中の第１ノードから（イン
デックスＩ_ｉ−ｌの第１ブロックを指していなければならない）。ここで、ノー
ド３１１から直接リンク３１６によってより低いレベルの垂直に向いているツリ
ーに（即ち、層Ｉ_ｉ−ｌに）に移動し、ここから、検索スキームで指定されてい
る検索パスに続く。

【０２７２】 もう一つのシナリオに従って、インデックススキームが、所定の方向に行くこ
とを指定しており、希望する方向にリンクがない場合は、検索パスは、検索パス
（直接リンクを維持する）上で最も大きな数値を有するノードから直接リンクに
続く。ブロックからブロックへ進むとき、共通キー（入手できる場合）あるいは
ノード（入手できる場合）に関連するデータレコードに対する比較で、インデッ
クススキームで進めるかあるいは直接リンクを有するノードに戻るかどうかの判
定にもたらすことができる。共通キーが、必ずしも物理的にデータレコードに取
り付けられていないことに留意しなければならない。

【０２７３】 前記の例（求められているデータレコードＬ）と図９ＥのデータレコードＣに
戻って、ブロック３１０の共通キー（０１１０１１として）が、ブロックの中に
維持されている場合は、データレコードＣにアクセスする必要はない。従って、
Ｌのキーの共通プレフィックスとブロックの共通キーが、０であるので、レコー
ドＣにアクセスしないでノード３１４とリンク３１６に戻ることができる。規定
された方法でデータレコードにアクセスしないで済むことは、言うまでもなく、
性能を向上させる利点である。求められているレコードがツリーの中に存在しな
いことを知る基準は、求められているデータレコードの共通キープレフィックス
のサイズとブロックの共通キーが、分割ノードの数値より大きいことである。

【０２７４】 後者の例の中で、分割ノードの数値（ノード３１３の）が１であれば、従って
、ブロック３１０は、レコードＬを受け入れることができるブロックでない（該
レコードが存在する場合）。従って、レコードＬに対する検索は、ノード３１４
とリンク３１６から継続される。該手続きは、全ての修正トランザクションに適
用される。

【０２７５】 挿入トランザクションに関する限り、ブロック３００が特定の方法で見つけら
れ、新しいデータレコードと関連している。

【０２７６】 後者の例は、階層インデックスの特定の例が参照される。当業者であれば、確
率的アクセス特性が、他の階層インデックスが、他の必要な変更を加えて、基本
区分インデックスを使用する他の階層インデックスに適用されることが分かるは
ずである。

【０２７７】 「エラー」がもたらされる確率的検索索特性は、必ずしも階層Ｉ_ｈ−１の中の
ロックの中の完全な共通キ−が、Ｉ_ｈ−１の中のブロックまでの検索パスの中に
常駐しているノ−ドの数値から知られていない事実に由来する。従って、求めら
れているデ−タレコードのキ−に従って特定のブロックへの検索パスが、検索パ
スと整合しているかどうか検証するために、Ｉ_ｈ−１の中のブロックの共通キー
を知ることが必要である。共通キ−が、ブロックの中に維持されていない場合は
、共通キー値を知るために索引の中でデータレコードに進める必要がある。

【０２７８】 階層インデックスの内在するエラーしやすい特性とその取り扱い方法は、前記
の図９を参照して例示されており、下記に更に一般的に説明される：レコードを
キ−ｋで検索するために、後者が、Ｉｈの中（および場合によっては、Ｉ_ｈ−１ からＩへのあるはデータレコードへの中で）ｋにもたらすＩ_ｈ−１のブロックＢ
を探すために検索される。このプロセスは、キーｋを有する（もし存在すれば）
デ−タレコードに関連するブロックＩ_０に到達するまで反復される。

【０２７９】 図７から９の説明は、基本区分インデックスとまた代表インデックスとしての
索引付けスキームを基礎とするＰＡＩＦを使用する階層インデックスを例示して
いる。当業者は、本発明の階層インデックスが、ＰＡＩＦのみに拘束されないこ
とが容易に分かるはずである。従って、例えば米国特許５，４９５，６９は、異
なるトリーを示している。例えば、特定の６０９特許に従って、図１０Ａのトリ
ーを考察して、またトリーが、ノード１１、１２、１３および１４を受け入れる
ブロックから成ると仮定する。新しいノードのツリーへの挿入に続いてブロック
を分割することが必要である場合は、従来の技術に従ったブロックを分割する可
能なアプローチは、例えば、ノード１２と１４の間でリンクを切断して、該操作
で、２個のブロック、すなわち一方はノ−ド１１、１２および１３を受け入れ、
他方はノード１４（以下新しいブロック）を受け入れるブロックを得ることであ
ろう。第１ブロックが、内部メモリーの中に常駐するものと仮定して、ここでレ
コード２６に到達する必要がある場合は、１個のみの出入力オペレーションが必
要である。他方、レコード２０が、関係がある場合は、新しいブロック（即ち１
方の受け入れノード１４）にアクセスするために、第１出入力オペレーションが
、必要であり、その後は、レコード２０にアクセスするためにもう一個の出入力
オペレーションが、必要である。従って、分割ブロックが、不均衡なツリ−とな
ったことを理解しなければならない。それに続く挿入トランザクションが、ツリ
ーの不均衡特性に悪影響を与える可能性がある、即ち当然好ましくない多重の出
入力アクセスを必要とする。

【０２８０】 本発明の技術を適用して、不均衡なツリーの欠点に対応して、結果として生じ
た階層インデックスは、図１０Ｂの中に示されており、該図の中で、代表インデ
ックスが、トリー（ブロック１５９ｂと１５９ｃにより構成されている）の代表
的キーの上にブロック１５９Ａにより構成されている。ここで、また、ノ−ド１
２と１４の間のリンクが、分割リンクと見なされ、新しいノード１５９Ｄ（ノー
ド１２の複製として）は、１５９Ａとして符合が付けられた新しいブロックにコ
ピーされる。ここで、レコード２０と２６にアクセスするために、同じ回数の、
該特定の場合は、２回の出入力オペレ−ションが必要である。トリーのサイズが
、大きくなればなるほど、階層インデックスを使用するアクセスは、効率的にな
る。

【０２８１】 図１０Ｂの階層インデックスは、従って、同じ回数の出入力オペレ−ションが
、ツリ−の中の各々および全てのデ−タに到達するために、必ず必要のなること
を確実にするブロックの均整が取れたツリーとなる。当業者であれば、できれば
、出入力オペレ−ションが、デ−タレコードの数とブロックを根源とするリンク
の数次第で、対数関数であることが好ましいことが分かるはずである。従って、
例えば、１０００の遠リンクが、ブロックから始まっている場合は、３レベルを
有する階層インデックスで、１，０００，０００，０００のデ−タレコードにア
クセスすることができる。

【０２８２】 前記の説明をより良く理解するために、数字による例が続く。各のブロックが
、１０００の遠リンクを有しているものと仮定して、遠リンクのサイズが、４バ
イトと仮定して、遠リンクを示すのに必要なサイズが、４０００バイトであるこ
とが容易に起こる。更に、ブロックの中のノードと近リンクが、他の４０００バ
イトを占領するものと仮定して、結果として生ずるブロックのサイズは、１０，
０００バイト以下である。解説のために、各ブロックのサイズを２０，０００バ
イトとする。

【０２８３】 ここで、インデックス層１としての１個のブロック（例えば、図７Ｂのブロッ
ク１４４）から成る階層インデックスを考察して、インデックスが、層Ｉ０の中
の１，０００のブロック（内２個のブロック１４６と１４８のみが、図７Ｂの中
に示されている）にリンクされていると仮定して、階層インデックスの総計は、
各々が２０，０００バイトを有する１００１ブロックとなる。従って、階層イン
デックスのブロックを維持するために割り当てられるべき全スペースは、約２０
メガバイトである。このくらいのサイズは、容易に、例えばパソコンのような内
部メモリーに収容できる。ここで、Ｉ_０の中の各ブロックは、他の千のデータレ
コードと関連し、正味の効果は、完全に内部メモリーの中に収容されている本発
明の階層インデックス（後者の実施例に従って）を使用することで、百万のデー
タレコードを、出入力インデックスなしでアクセスできる。

【０２８４】 同様の理由で、１０億のレコードにアクセスするには、実際的に、追加の１個
の出入力オペレーションを必要とするもう一つのインデックス層が必要である。

【０２８５】 前記をより良く理解するために、例えば、図６Ｂ−１あるいは６Ｂ−３の中の
階層インデックス（ＰＡＩＦインデックススキ−ム）のインプリメンテーション
を考察する。デ−タレコード１０３と１０７のキ−のサイズ（例えば１００バイ
トの長さ）が、より長かったとすれば、キーは、ＰＡＩＦのサイズを変えなかっ
たはずである。もう一つの非制限的例を図８Ｂの中に示すことができる、インデ
ックスによりアドレスされたデ−タレコードａからｋのキーのサイズーが、２０
０バイトの長さである場合は、階層インデックスのサイズと構造が、変更されな
いはずである。自明の理であるが、キーの順序に従ってインデックスの中を名日
ゲートし、デ−タａからｋを検索することも可能である。これは、連続オペレー
ションの一つの形態を例示したものである。

【０２８６】 図示されているとおり、図１０Ｂの結果として生じた階層インデックスは、垂
直の方向を有する、２個のツリーから成る、即ち、第１構造が、ブロック１５９
ｂと１５９Ｃ（基本区分インデックスＩ_０の形態の一つとして）とまた１個のブ
ロック１５９Ａ（基本区分インデックスＩ_１の形態の一つとして）を有する第２
ツリ−から成る。

【０２８７】 このようにして達成されたブロックの水平ツリー（階層インデックスの形態の
一つとして）は、均衡が取られる、即ち、出入力を経由して、ルートブロック１
５９Ａで、全てのリンクが、デ−タレコードにアクセスできる。Ｉ_０のブロック
の中で追加の分割をもたらすデ−タレコードのこれ以上の挿入には、無論、階層
インデックスＩ_１の更新が必要である。Ｉ_１のブロック１５９Ａの中のノードの
数が、所定の数を超えた時は、ブロック１５９Ａは、分割機構に従って分割され
る。

【０２８８】 本発明の技術が関連するツリー索引は、特許６０９の中で開示されている検索
ツリーに限定されなず、前記で説明された多数の他のタイプのツリーを包含する
ことができる。

【０２８９】 ブロック間構造が、必ずしも均衡していない、即ち、ブロック内のノードが、
必ずしも均衡の取れた構造で配置されていないことに留意しなければならない。
この事実は、欠点のように見えるが、当業者であれば、全体のデ−タベースの性
能上の実行が、実際には重要でないことが容易に分かるはずである。これが、ブ
ロック間検索スキームが、通常早い内部メモリーの中で実行される事実に由来す
る。ブロック間検索スキームに対して、階層インデックスの中のブロックの配置
は、均衡が取れた構造の中で保持されるので、検索パスの中のブロックの数は、
デ−タレコードの数によって対数関数であり、希望するブロックを内部メモリ−
にロードするために、外部メモリーに対する出入力アクセス（本質的に遅いオペ
レーション）する数を反映する。

【０２９０】 これに関連して、当業者は、本発明が、理由の如何を問わず与えらえた物理的
実現に限定されないことが容易に分かるはずである。従って、例えば、本発明の
技術を適用して、ブロック間で、検索スキームを保持する一方で、検索スキーム
に関する限り、これは、例えば、オフセットとオフセットの数値に従って階層イ
ンデックスの中に進める論理的コンセプトに適用される。後者の一般的コンセプ
トは、本発明の技術によって達成されるすべての方法で実現される。従って、例
えば、各ノードの中に収容するオフセットのサイズ（ビットの数の意味で）を、
変更でき、空のポインタ（即ち、ヌルを指す、子を有していないポインタ）と他
のものを実現する方法である。後者の物理的実現の弾力性が、またブロック間部
分に適用される。

【０２９１】 図７から１０の全てを参照して説明された階層インデックスは、必ずトリーと
代表インデックススキームの双方に対して同じインデックススキームを保持する
（上記の図１０Ｇを参照して説明されたとおり、インデックスを経由してデ−タ
レコードにアクセスするときに遭遇する可能性があるエラー処理に対するものを
除く）。

【０２９２】 トリーと代表インデックスの双方に対するインデックススキームの保持は、図
１１を参照して例示されたとおり必ずしも必要ではない。

【０２９３】 図１１は、均衡が失われたトリーの代表的キー上の代表インデックスとしての
従来のＢツリーを使用する、図８Ａ（即ち階層インデックスを構築している）の
均衡が失われたツリーを均衡させるもう一つのアプローチを示している。このよ
うにして得られた水平指向の均整が取れたツリー（階層インデックス）は、上位
レベル（インデックス層Ｉ_２）のブロック２７２，と下位のレベル（インデック
ス層Ｉ_２）の２７０と２７１とまた均衡が失われた垂直指向の図８Ａの最も低い
所の（ブロック２６０、２６１、２６２、２６４）インデックス層Ｉ_０のツリー
の元のブロックから成る。図４は、代表インデックスのインデックススキームが
、元の均衡が失われているトリーのスキ−ムと必ずしも同じでないことを実証し
ている。所望なら、全体的にＢツリー（代表インデックスを形成してる）を、イ
ンデックス層Ｉ_１として見なすことができる。

【０２９４】 本発明のデータベース管理システムは、従来のツリーインデックスファイルの
欠点に対応するだけでなく、またユーザーアプリケ−ションプログラムを使用す
ることでデ−タのアクセスを容易にしまた改善する他の利点を提供する。

【０２９５】 従って、ブロックの均整が取れた構造が、保持されるという事実により、平均
して、遅い出入力オペレーションで、必ず確実に最適に保たれること、即ち、特
に多数のブロックが関わる大きなファイルのとき、より効率的な結果が確実に得
られる。

【０２９６】 当業者であれば、階層インデックスの構造が、例えば、遅い外部の記憶媒体に
対するアクセスの回数を最小限度に抑えるために、遅い出入力オペレーションに
適用されることが好ましい一方で、本発明が、理由の如何を問わず特定の記憶媒
体に制約されないことが容易に分かるはずである。従って、例えば、本発明が適
用できる記憶媒体が、また内部メモリーとなることができる。このことは、本発
明に従って実現される効率的なアクセス制御を必要とする、外部メモリーより早
い常に増大する内部メモリーの容量に対処するために特に必要不可欠である。

【０２９７】 本発明の第２の態様が続く。

【０２９８】 説明を容易にするために、本発明の第２の態様は、ＰＡＩＦインデックス（指
定されたインデックスを構成する）を参照して説明される。本発明は、理由の如
何を問わず、特定の例に拘束されないものとする。

【０２９９】 前記で述べられているとおり、本発明のデ−タベ−スファイル管理システムで
、単独のインデックスを使用して、デ−タレコードの種々のタイプをアドレスで
きる。

【０３００】 同じＰＡＩＦインデックスによりアドレスされる種々のタイプのデ−タレコー
ドの間をより良く区別するために、所定のタイプに属する各デ−タレコードは、
所定の指定子と関連している。後者は、指定子を形成しているデ−タレコードの
キーの一部を形成している。該指定子は、デ−タレコードに対して一意のもので
ある。従って、例えば、エンティティ「Ｂｏｒｒｏｗｅｒ」に所属するデ−タレ
コードのキーには、指定子Ａのプレフィックスが付くのに対して、エンテッィテ
ィ「Ｂｏｏｋ」に所属するデ−タレコードの全てのキーには、指定子Ｂのプレフ
ィックスが付く。Ｂｏｒｒｏｗｅｒに所属するデ−タレコードの新しいキーは、
ここで‘Ａ’の連鎖と元の借入人から成る指定されたキーとなり、同様の理由で
、デ−タレコードの新しい指定されたキーは、書籍に所属し、ここで、’Ｂ’と
Ｂｏｏｋの元のキーの連鎖から成る。

【０３０１】 本発明の第２の態様の「指定子」と呼ばれる特徴を解説したので、ここで、メ
タデ−タと呼ばれる説明が続く。

【０３０２】 本発明の一面に従って、デ−タ辞書は、レコードタイプの機能に応じてデ−タ
レコードに関する情報を提供するメタデ−タ情報を保持する。従って、デ−タレ
コードの他に、指定子を識別することができ、またメタデ−タ情報を使用するこ
とで、識別するか指定されたキーとまたレコードのサイズのような他の情報を構
築するための指定子を保存する必要がある。インデックスの検索スキムは、メタ
デ−タを忘れている。該メタデータは、メタデ−タを使用しないでレコードを指
定子（あるいは合成）キーから探しだす。メタデ−タには、（複合）指定子キー
を構築する必要があり、一度レコードが検索されたら、レコードの特性を決定す
る。従って、例えば、書籍のデ−タレコードを検索し、レコード上の定されたＢ
情報を、メタデ−タから入手できる。例えば、書籍のレコードのサイズ、そのフ
ィールイドとキーフィールドであるフィ−ルドである。

【０３０３】 指定されたデ−タレコードの使用は、一つのタイプに拘束されることなく、む
しろ、（できれば）１個以上のタイプを、指定されたインデックスより処理する
ことができ、関係と従属関係と共に下記で説明される。

【０３０４】 従って、これまでの解決のとおり、本発明の指定されたインデックスを使用し
て、デ−タベース管理システムに従って異なるタイプのデ−タは、一般的に複数
のファイルの中に保持され（それから、複数のインデックスファイルによりアド
レスされる）、種々のタイプのデ−タレコードを、同じインデックスからアドレ
スすることができる。異なるタイプに所属する（同じ指定された索引によりアド
レスされた）デ−タレコードのキーが、必ずしも同じ長さを有する必要がないこ
とに留意しなければならない。従って、例えば、また図８Ａの中で示されている
基本区分階層インデックスのようなトリーに基づく指定されたインデックスであ
る階層インデックスを考察する。「Borrower」エンティティに属するレコードの
キーのサイズは、６バイトの長さであるのに対して、「Ｂｏｏｋ」エンティティ
に所属するレコードのキーのサイズは、５バイトの長さである。書籍を、指定子
キーＢ１１１１１とＢ２２２２２を付けて図８Ａの指定された索引に挿入するこ
とで、２個のタイプのデ−タレコードである、すなわち指定子Ａが割り当てられ
たデ−タレコードａからｋと指定子Ｂが割り当てられたデ−タレコードｗからｘ
をアドレスする指定されたインデックスから成る図１２のデ−タ構造が生ずる。
下記の説明の中で、用語タイプＸのレコードあるいは、Ｘと指定されてるレコー
ドが、指定されたキーと指定子Ｘを有するレコードを説明するために使用される
。

【０３０５】 後者の例は、指定されたデ−タ（即ち、前に垂れ下がっているプレフィックス
、文字列あるいは全ての数のビット）を実現している一つの方法を示している。
当業者であれば、これが、多数の可能な変形の中で、唯一のものであることが容
易に分かるはずである。事実、指定子が、キーの一部として扱われ、検索の一部
を形成する異なるデ−タレコードの間で識別することを条件として、提案された
指定子を公知の方法で実現できる。

【０３０６】 後者の説明は、指定子が、下記の何れかを問わず適用される： （ｉ）デ−タレコード（あるいはキー部分の一部）を形成する、 （ｉｉ）別の所に保存される、（例えば異なるデ−タ構造）、または （ｉｉｉ）別の所で定義されるか、他の方法で定義される、 後者の例は、全て同じタイプのデ−タレコード（例えば、全てが、文字Ａで指
定されている）と関連するトリー構造である。言うまでもなく、この例で、指定
子が、全てのレコードに共通であるので、物理的に指定子をデ−タレコードのイ
ンスタンスに付ける必要はない。しかし、デ−タレコードが、アクセスされる場
合は、指定子を識別して、それにキーを加える必要がある。

【０３０７】 もう一つの可能な解決は、デ−タレコードがアクセスされたとき、指定子が、
入手できるように指定子をデータレコードにプレフィックスすることである。例
えば、図１２を考察する。デ−タレコードは、リンク２７０によりノ−ド２６６
からアクセスされる。デ−タレコードの最初の文字は、Ａの指定子である。

【０３０８】 従属関係をより良く理解すために、図１３から１３Ｅに注目する。図１３Ａは
、４個のデ−タレコード８０２、８０４、８０６および８０８（指定子キーのみ
が示されている）を有している指定されているインデックス８００（ＰＡＩＦの
形態で）を示している。各デ−タレコードに予め用意されている指定子’Ａ’か
らたやすく生ずるデ−タレコードは、全て同じタイプである。

【０３０９】 ここで、図１３Ｂに戻って、ＰＡＩＦ８００が、複合キーＡ１２３５５Ｂ９４
０２０１３３３３３３（レコード８１の指定子がＢ）が付いた新しいデ−タレコ
ード（８１２）が付いて示されている。新しいデ−タレコードは、Ａ１２３５５
のキーを有するデ−タレコード８６に従属する。ＰＡＩＦインデックスに従って
、ノード８１４は、識別オフセットが６であることと、またこ数値Ｂが、デ−タ
レコード８１２にリンクさているとを示した（オフセット６で数値Ｂを有する）
。レコード８０６が、オフセット６で数値を有さないので、該レコードには、識
別オフセットを他のレコードとを突き合わせて判定するために該オフセットの所
で仮想の数値（ヌル）が、割り当てられ、リンク８１８が、ヌルとマークされた
方向に設定される。

【０３１０】 図１３Ｃは、ＰＡＩＦ８００を示しており、該ＰＡＩＦの中で、他のデ−タレ
コード８２０が、挿入される。Ｂタイプのデ−タレコードのもう一つのインスタ
ンスを示す、タイプＡのデ−タレコード（８０６）に従属するデ−タレコード２
０が、ＰＡＩＦに挿入される。識別オフセットは、１１であり（新しいノード８
２２の数値）、デ−タレコード８１２と８２０に対するリンク値は、それぞれ‘
０’と‘１’である。

【０３１１】 図１３Ｄは、ＰＡＩＦ８００を示しており、該ＰＡＩＦの中で、レコードの異
なるタイプが、レコード８０６に従属する。タイプ‘Ａ’のデ−タレコードに従
属させられるタイプ‘Ｄ’（８２４）のデ−タレコードは、数値Ｄを有するリン
ク８２３によりノード８１４からリンクされる。前記のとおり、ＰＡＩＦは、既
にＢと指定されているデ−タレコードを示しており、該場合、後者は、Ａと指定
されているデ−タレコードに従属する。‘Ａ’タイプに従属した‘Ｂ’は、サプ
ライヤー（‘Ａ’）により保存された項目（‘Ｂ’）であり、また（‘Ａ’）に
従属した（‘Ｄ’）タイプは、サプライヤ−（‘Ａ’）のサ−ビスを受けるクラ
イアント（‘Ｄ’）である。

【０３１２】 ここで図１３Ｅに戻って、やや異なって実行される図１３Ｄのもう一つの実施
形態が、示されている。特に従属デ−タレコード８１２、８２０及び８２４が、
示されており、レコード８０６の指定子キーであるキープレフィックスなしでデ
−タファイルに維持されている（即ち、プレフィックスキーＡ１２３５５が、欠
落している）。例えば、デ−タレコード８１２にアクセスするときは、指定子Ｂ
に従ってメタデ−タから入手できる情報で、下記の情報を引き出すことができる
。 （ｉ）キーの一部が欠落していることを調べる （ｉｉ）該レコード８１２は、６の数値（８１４）を有するノードからおよび、
ヌル数値（８１８）を有するリンクによりアクセスすることができるＡと指定さ
れているレコードに従属させられる。

【０３１３】 従って、デ−タレコード８０６にアクセスして、レコード８１２の完全なキー
を構築することができる。ＰＡＩＦ８００が、階層インデックスである場合は、
ノード８１４と８２２が、異なるブロックの中に常駐している可能性があり、レ
コード８１２と関連するブロックへのアクセスパスは、ノード８１４を含んでい
ない。この場合、従属させられているレコードからレコード８０６へのリンク（
リンク８２６、８２８および８３０）で、デ−タレコード８０６にアクセスして
、キーを構築することができる。上記に説明されているインプリメンテーション
は、各従属させられたデ−タレコードに関してデ−タレコード８０６の指定され
たキーの表示のコピーの必要性を無くす（図１３Ｄの特定の例により、特定のプ
レフィックスＡ１２３５５が、レコード８１２、８２０および８２４に対して３
回コピーされる）。キープレフィックスを、リンクと取り替えることで、スペ−
スを節約でき（プレフィックスのサイズが、リンクの表示より大きい場合に）、
従属が、別個の検索を必要としないものに関連しているレコードにアクセスでき
る 図１３Ｄと１３Ｅは、本発明の従属関係特性が、全ての実現に対して制約され
ないことを示している。

【０３１４】 本発明の従属関係で、一個のインデックスを、種々のデ−タのタイプとまた従
来の技術に従った別個のインデックスファイルと比較して従属関係に関連させる
ことができると言う意味で、デ−タの低いレベルのインプリメンテーションを、
これまでの公知の技術と比較してより効率的にすることができる。これに限らず
、言うまでもなく１個以上のインデックスファイルが使用される本発明に従った
適用がある。

【０３１５】 言うまでもなく、従属されらているレコード８１２、８２０、８２４の各々に
、諸レコードを従属させることができる。

【０３１６】 更に、本発明の提案されている技術を利用して、例えば、データの完全性の維
持のような生ずる幾つかの利点がある。例えば、データレコード８０６（指定さ
れているキーＡ１２３５５を有している）に従属している複合キーＡ１２３５５
Ｂ９３０１０１１２３４５６を有するデータレコードで指定されているＢの図１
３ＥのＰＡＩＦ８００に適用される挿入トランザクションを考察する。検索は、
ノード８２２に導かれる。挿入されたデータレコードキーオフセット１１の数値
は０であるので、レコード８１２が、アクセスされる。レコード８１２の検索キ
ーを、構築する必要があり（リンク８２６を経由してレコード８０６にアクセス
することで）、また、新しいデータレコードの挿入を達成させることができる。
レコード８０６へのリンクにより、レコードの存在を確認するために、検索キー
によりレコード８０６に対する別個の検索作業を省くことができることに留意し
なければならない。従って、データの完全性の維持がより効率的になる。

【０３１７】 特定のＢツリーインデックスを使用して同じデータの完全性のチェックを実施
することは、２段階の操作を必要とするので、大幅な間接経費の増大を招く。最
初に、キー１２３５５を有するデータレコードを発見するために、タイプ「Ａ」
のデータレコードのインデックスに対して検索を行う。レコードを発見した後で
なければ、タイプＢのレコードを挿入することができない（それから、別個のイ
ンデックスファイルが、通常更新される）。

【０３１８】 データを検索するとき、図２０Ｅのデータの構造は、従属させられているデー
タレコードが、「親」レコードにリンクされていると言う事実からから生ずるこ
れ以外の利点を例示している。タイプＡからのレコードが、クライアントであり
、タイプＢからのレコードが、インボイスである場合、通常、クライアントの詳
細と共にインボイの明細にアクセスすることが必要である。インボイスからクラ
イアントへのリンクにより、クライアントの詳細の検索を省くことができる。

【０３１９】 連続操作を完了するためのインデックスの閲覧に当たって、この方法で得られ
た本発明の指定されたインデックスから、重要な利点を引き出すことができる。

【０３２０】 例えば、図１３ＥのＰＡＩＦを考察する。この場合では、昇順で、全てのデー
タレコードを「検索」する必要がある。従って、ＰＡＩＦ（逐次作業として知ら
れる）の閲覧を行うことができ、データレコード８０２、８０４、８０６、８１
２、８２０、８２４および８０８が、指定子キーの順序で検索される。例えばタ
イプＡのレコードのようなあるタイプのレコードのみ必要な場合、インデックス
の中で、無関係なノードとレコードにアクセスすることなく、同じ方法で閲覧で
きる。従って、ノード８１４から、レコード８０６にアクセスされ、またノード
８１４からリンクと孫ノードによりアクセスできるデータレコードが、レコード
８０６に従属させられていることを予見できるので、リンク８３３、８３２を省
くことできる。この例の中で、レコード８０２、８０４、８０６および８０８だ
けが、検索される。タイプＡとＢのレコードのみ必要な場合は、レコード８０６
をアドレスする数値６を有するノードからの数値Ｄを有するリンクが、Ｄと指定
されているデータレコードに従属させられているリンクであることを予見できる
ので、同じ方法で、リンク８２３に沿って移動しなくて済む。

【０３２１】 ＰＡＩＦインデックスが、階層インデックスである場合で、ノード８１４が、
ノード８２２以外のブロックに常駐していると仮定して、ノード８１４からノー
ド８１２の移動を、分割リンクにより行うことができる。図７Ｆの中で例示され
ているように、分割リンクが、存在しない場合は、リンク４００によりノードＢ
（４２３）からノードＥ（４２４）に進む必要があるときに、ノードＢ’（４２
２）のリンク４２１を使用する必要がある。

【０３２２】 図１３の特定の実施形態を引用して、従属関係を例示したので、本発明の第２
の態様に従った多次元特性に関連する説明を続ける。

【０３２３】 図１４に戻って、図の中には、本発明に従った指定されたインデックスが概略
的に示されている。インデックスは、キーフィールド口座番号、日付およびクラ
イアント番号から成る指定されたキーと、またキーフィールドクライアント番号
、日付および口座番号から成る指定されたキーである２個の複合キーの各々によ
り預金にアクセスできるような、一個の指定されたデータレコード（「ＤＥＰＯ
ＳＩＴ」データレコード）への２本の検索パスから成る。上記の例に戻って、口
座データレコードは、指定されているキー「Ａ１３３３３３（１２０１）」を有
しており、口座に対する預金（口座に従属している預金）の更新は、指定された
レコード２０１に従属している指定されたレコード２０３によって実行できる。
ＰＡＩＦで、リンク２０６でノード２０７からレコード２０１、２０３にアクセ
スできる。同じ理由で、データレコード２０４は、クライアントの預金を示して
いる。レコード２０２のキーは、Ｂ１３３３３３である。データレコード２０４
にリンク（２０８）されているインデックス２００とノード２０９により、クラ
イアント２０２に対する預金２０４の更新を実施することができる。データレコ
ード２０３のキーは、「Ａ１３３３３３Ｃ０１０１９８１１３４６１」（ｋ_１）
である。レコード２０４のきーは、Ｂ１１３４６Ｄ０１０１９８１３３３３３（
Ｋ_２）である。

【０３２４】 図示されているとおり、ＣｌｉｅｎｔとＡｃｃｏｕｎｔのフィールドは、レコ
ード２０３、２０４の中にコピーされる（日付と金額のような追加の情報も同時
に）が、この作業は、言うまでもなく不必要にファイルを膨らませると言う欠点
を有している。

【０３２５】 欠点を、単独のＤＥＰＯＳＩＴレコードを多次元レコード２１０として示すこ
とで克服できる。

【０３２６】 データレコード２１０（図１４）は、指定子キーｋ_１（指定子Ｃ）に従って、
また指定子ｋ_２（指定子Ｄ）に従って指定されたインデックス２００により更新
されアクセスされた多次元レコードである。（データレコードが、多次元レコー
ドであるとき、レコードの指定子は、使用されるキーに左右されることに留意し
なければならない。）ｋ_１によるインデックスの中のパスは、ノード２０７に導
かれ、ノードからレコード２１０の指定子Ｃに導かれる。指定子Ｃに従ったメタ
データの中の情報で、必要な構造を構築できる。例えば、リンク２１３、２１４
によりキーｋ_１から成るデータ構造を構築して、レコード２０１と２０２がアク
セスされ、そこでレコード２１０の日付フィールドで、全てのフィールドが構築
される。ｋ_２によるインデックスの中のパスは、ノード２０９に導かれ、ノード
からレコード２１０の指定子Ｄに導かれる。指定子Ｄに従ったメタデータの中の
情報で、例えばキーｋ_２から成るデータ構造を構築するような、必要な構造を構
築できる。図示されているように、レコード２０３の検索キーにより画されてい
る検索パスは、数値「Ｃ」（検索キーｋ_１に従った指定子である）を有する第１
フィールド２１２に導かれる。第３フィールドは、データレコード２０１を指し
ている。同じデータ構造２１０の第２フィールド２１５（キーｋ_２に従った指定
子である数値「Ｄ」を有する）は、レコード２０４の検索キーにより画されてい
る検索パスによりアクセス可能である。第４フィールドは、実際のデータレコー
ド２０２に対するリンクを有している。この方法で、口座、クライアント、日付
と金額のフィールドをコピーすることを省いており、レコード「ＤＥＰＯＳＩＴ
」は、口座とクライアントの双方の従属を示している。データのエレメントであ
る口座とクライアントが、元のデータレコード（２０１と２０２）に向かってい
るリンクによってアクセスされ、またデータの残り（日付と金額）が、データの
エレメント２１０の中に一度だけ存在するることに留意しなければならない。言
うまでもなく、データレコード２１０に、他のフィールドを含めることができる
。本発明は、理由の如何を問わず、所与の実現に拘束されず、従って、図１４の
中で図示されているデータレコード２１０を実現する方法は、多数の可能な変形
の内の一つである。検索パスの数は、制限されない。図１３Ｅを引用して前記で
説明されているとおり、求められているデータレコードが、Ａｘｘｘｘである場
合は（即ち本質的に口座レコード２０１）、検索キー「Ａｘｘｘｘ」のインデッ
クスの中で、単に該当する従属させられているレコードの何れかに向かって移動
するだけで、従属させられているレコードからタイプＡのレコードに向かってい
るリンクによりＡタイプのレコードにアクセスする。例えば図１４のリンク２１
３に対するものと同様に、他のインプリメンテーションは、言うまでもなく、全
ての要求に応じて適切に実現可能である（例えば、インデックスの中にレコード
Ａに対するリンクを維持する）。物理的出現に対する２つの検索パスを設ける具
体的な説明は、１個のデータレコード（多次元レコードと呼ばれる）に向かう少
なくとも２つの検索パスから成る指定されたインデックスである多次元データ構
造を構成する。

【０３２７】 データエレメント間の関係に就いて、図１５は、本発明のもう一つの特徴、即
ち、データ関係の特徴を示している。従って、データレコード（書籍レコード）
は、それに従属させられたＣ、Ｆ、Ｊ、ＫおよびＬのデータレコードを有してい
る。階層の実現は、前記で示された。本関係の特徴に従って、一対一および一対
多数の関係を、容易に実現できる。例えば、書籍が多数のカテゴリー（Ｌ）即ち
一対多数を有していが、カテゴリーがたった一個の要約（Ｋ）、即ち一対一を有
していることを考察する。

【０３２８】 提案されている特徴に従って、一対一の関係は、２個の構成要素の指定された
（複合）キーにより実行される。即ち、第１は、その従属されられたレコードの
指定されたキーであり、第２は、従属させられたレコードの指定子である（構成
要素が、一対一の関係であるので、従属させられているレコードのキーフィール
ドを使用する必要がないので）。一対多数の関係は、指定子の第１構成要素が、
従属させられているレコードの指定子キーである指定子（複合キー）で実施され
るのに対して、第２構成要素は、指定子と従属指せられているレコードのキーか
ら成っている。

【０３２９】 この例の中で、書籍とその要約の間の一対一関係は、Ａｘｘｘを、Ｌの指定さ
れたキーとし、Ｌを、レコードＬの指定子として、ＬのキーをＡｘｘｘＬとなる
ように定義することで維持される。書籍とカテゴリーの間の一対多数の関係は、
Ａｘｘｘを、Ａの指定されたキーとし、Ｌをキーの指定子とし、またｙｙｙをレ
コードＬのキーフィールド（複数を含む）として、ＬのキーをＡｘｘｘＬｙｙｙ
となるように定義することで維持される。

【０３３０】 続けて、多重モデル表現に関する本発明の第２の態様に従ったもう一つの特徴
に関するものを説明する。この特徴に従って、また下記に更に詳しく説明して、
一個あるいはそれ以上の下記の（あるいは他のものに及ぶことがある）モデルが
、特定の指定されたインデックスにより示される。

【０３３１】 多重モデルの指定されたインデックスにより相関関係テーブルを示す。

【０３３２】 相関関係モデルは、全てのデータをテーブルで構成されているものと見なす。
各テーブルは、タブル（tuples）と呼ばれる、同じ構造のレコードから成る。タ
ブルが、フィールドＦ１，Ｆ２およびＦ３から成るものと仮定する。フィールド
の各々はキーである。キーＦ２が、キーＦ１に従属し、またキーＦ３が、キーＦ
２に従属している場合は、テーブルを容易に構築することができる。タブルを検
索するには、キーＦ１の指定子に従い、そこからＦ１の数値に向かう、指定子Ｆ
２に従い、次に同じ方法でＦ３に更に向かう。タブルの各々は、テーブルのｔｕ
ｐｌｅを定義する。一部の立案は、これより容易でさえある。数値Ｆ３が存在す
る数値Ｆ１とＦ２の一対の全てを発見するために、処理の後で（Ｆ１，Ｆ２）検
索を打ち切る。（Ｆ２，Ｆ３ｓ）の立案を実施するには、初めにＦ１の数値の全
てを検索する必要なあるので、費用がかかる。しかし、このオペレーションが、
共通であれば、指定されたインデックスも、また検索パス（Ｆ２，Ｆ３，Ｆ１）
を維持する。即ち、新しい指定子が付いた新しい指定子複合キーＦ２’Ｆ３’Ｆ
１’を構築して、追加のパスを、指定されたインデックスに挿入することである
。このようにして、各レコードを、双方のパスを経由して到達させて、多次元レ
コードを構成することができる。

【０３３３】 多重モデルの指定されたインデックスに関する追加のモデル： 指定されたインデックスで、相関関係データベース、オブジェクト指向システ
ムと階層データベースから成り、ほとんどデータのコピーがない、追加のデータ
モデルを示すことができる。

【０３３４】 多重モデルの指定されたインデックスによるオブジェクト指向（持続性データ
構造）の実行： オブジェクト指向のアプローチは、全てのデータをオブジェクトと見なす。各
オブジェクトは、構造を決め、方法（機能）を適用できるクラスに属する。クラ
スは、階層別に組織されており、階層から、構造と方法を、継がせることができ
る。オブジェクト指向のアプローチは短命であり、オブジェクトは、作られたプ
ログラムが作動している間のみ存在する。長期間サポートされることを必要とす
るオブジェクトは持続的であると定義される。これらのオブジェクトは、ディス
クに記憶され、他の（許可された）プログラムに使用することができる。多重モ
デルの指定されたインデックスで、オブジェクトを簡単にサポートできる。構造
が、指定子の助けを借りて統一されて符号化されているので、事後に復活された
プログラムまた同時に他のプログラムは、持続的オブジェクトをアクセスできる
。同時に持続的オブジェクトを、相関関係テーブルの一部とすることができ、デ
ータをコピーする必要がないことに留意しなければならない。

【０３３５】 例えば、図１６のデータ構造２２０を考察する。データレコード２２３、２２
４、２２５および２２６は、データレコード２２１に従属しており、レコード２
２１と共に、オブジェクトと見なされる。検索の中で、レコード２２１の指定さ
れたキーと等しいキープレフィックスで効率的に全てのデータレコードを検索し
て（部分的キー検索）、オブジェクト全体を検索することができる。Ａタイプレ
コードと従属させられているＢタイプレコードのようなオブジェクトのデータの
一部のに必要な場合は、ここでも、レコードタイプＡ（例えば２２１）の指定さ
れたキーと、また次のキーフィールドとしての指定子Ｂと等しいキープレフィッ
クスで、データレコードに対して、部分的キー検索が行われる。

【０３３６】 多重モデルの指定されたインデックスによるオブジェクト相関関係の実行： オブジェクト指向のアプローチとは反対に、相関関係のアプローチは、全ての
データをテーブルと見なす。従って、ＳＱＬ照会を、オブジェクト指向のプログ
ラム言語に統合することが困難である（Ｃ＋＋あるいはＪａｖａ）。オブジェク
ト相関関係の取り組みで、テーブルをオブジェクトに転換するインターフェース
を設けることができる。ユーザーは、インターフェースにオブジェクトとテーブ
ルの属性の間の関係を指定する必要がある。一部の属性自身がテーブルである場
合は、テーブル上で、相関関係代数計算をできるようにする必要がある。これら
の換算は、アプリケーションプログラムにより実行される。従って、データベー
スは照会を最適化できない。指定されたインデックスは、データを統一された方
法で処理するので、オブジェクト指向アプリケーションプログラムとデータ構造
の間で理想的なインターフェースを提供する。アプリケーションプログラムの照
会は、指定されたキーの意味で公式化されているので、データベースは照会戦略
を最適化することができる。データベースは、オブジェクト指向アプリケーショ
ンプログラムが、オブジェクト指向方法論で何時でも処理できる、指定されたキ
ーとなる。オブジェクトに向かう検索パスの指定子のシーケンスは、そのクラス
を決定し、種々のフィールドに対する指定子で、オブジェクトプログラムが、要
求されている方法の多様性を解決できるようにする。

【０３３７】 指定されたキーは、全ての関連するデータをアドレスする。例えば、図１６が
、タイプＡのレコードが、カスタマであり、タイプＢのレコードが、カスタマの
保険金請求で、またタイプＣのレコードがクライアントの支払であるとする保険
会社のデータ構造を説明しているものと仮定して、明確に図示されているとおり
、全てのレコードは、単独のインデックス構造でアドレスされる。

【０３３８】 ここで、インデックスで、カスタマから関連するデータ、即ち保険金の請求と
支払を閲覧できるので、全てのオブジェクトインスタンスを効率的にアクセスす
ることができる。同時に、インデックス構造を、効率的に閲覧して、カスタマの
テーブル（タイプＡのレコードの集合体）とクライアントの支払テーブル（Ａと
Ｃタイプのレコードの集合体）を完成できる。データ構造が、データの物理的ク
ラスタを招かないので、データが個となるオブジェクトの間で共有されれば、異
なるオブジェクト閲覧により効率的にアクセスでき、従って、データレコードは
、多次元レコードである。この例において、保険金支払請求を、カスタマのオブ
ジェクトと証券オブジェクトと図１６の中の例としてのタイプの構造（構造２１
０）になっているものから効率的にアクセスできる。

【０３３９】 オブジェクト指向のアプローチで、ユーザーは、ユーザーが定義したタイプ（
ＵＤＦ）とユーザーが定義した機能（ＵＤＦ）を追加することができる。例の中
で、事故の写真を、保険会社のデータベースに加えることができる。この例の中
で、タイプＡデータレコードに従属させられている新しい指定されたデータレコ
ードが定義される。保険金請求の詳細が検索されるとき、事故の写真がアクセス
され、写真プリントアウトアプリケーションに送られる。指定されたインデック
スで、保険金請求に対する写真データの関係は、内蔵されているクラスとの関係
と同じ方法で取り扱われる。新しいＵＤＴが全ての他のデータタイプに基づきあ
るいは関連（従属により）するもとすることができる。ここで、指定されたイン
デックスで、アプリケーションが、ＵＤＴが特有の方法と他の特性を持たすこと
ができる定義されたクラスからの新しいＵＤＴを閲覧できる。例えば、インデッ
クスの中で閲覧を行うとき、通常我々は、中から写真と他の保険請求のデータの
一部に到達することができる保険請求を閲覧する。 ネットワークと階層モデル 多重モデルの指定されたインデックスによるネットワークと階層モデル ネットワークと階層モデルは、相関関係モデルに取って代わられたが、これら
のモデルはたとえ陳腐化しても、テーブル指向のインプリメンテーションより優
れた、ある程度の利点を（また同時に多くの欠点）を持っている。レコードが、
一旦検索されると、関連するレコードのアドレスは、何時でも入手できる。

【０３４０】 例えば、カスタマとローンを有する銀行を考察する。各カスタマは、一個のア
ドレスと複数のローンを有している一方で、貸出は、一人あるいはそれ以上のカ
スタマにより引受られている。ネットワークのモデルの中では、各カスタマは、
カスタマへのリンクから成るノードで示され、ノードへのリンクは、カスタマに
より取り上げられているローンを示している。ローンを示しているノードは、同
様にローンを引き受けているカスタマのノードにリンクされている。従って、ロ
ーンが与えられれば、ローンを引き受けているカスタマを容易にアクセスして、
自宅の住所を取り入れることができる。

【０３４１】 Ｂツリーインプリメンテーションでは、２つのツリーが、必要である、即ちそ
の一つは、カスタマの自宅の住所であり、二つ目はローンとカスタマである。従
って、ローンのデータを検索したら、ローンを引き受けたカスタマの名前を入手
できる。彼らの住所を発見するためには、別個の独立した各カスタマに対するＢ
ツリー検索が必要である。

【０３４２】 提案されている多重モデルの指定されたインデックスの中で（例えば図１６）
、一旦ローンを示すノードに到達すれば、ローンを引き受けているカスタマを識
別する指定子まで継続することができる（例えば、Ｂタイプレコード）。通常、
各クライアントのために少なくとも１個のディスクが必要である。提案されれい
る多次元の指定されたインデックスは、欠点が無いネットワークモデルの利点を
有している。ネットワークモデルが、各ノードを別々に処理し、検索パスが長く
なる傾向があるのに対して、多重モデルの指定されているインデックスは、全て
のデータを均一に処理し、検索パスの長さは、対数の基礎が、ブロックのサイズ
になるようＮなっている多分対数式である。従って、実際には、検索には単一の
ディスクアクセスを要する。

【０３４３】 指定されたインデックスによるオブジェクト指向によるサーバ／クライアント
モデルの実施 クライアント／サーバモデルで、相関関係モデルの効率的なインプリメンテー
ションができる。このモデルに従って、全てのデータは、中央コンピュータの中
に常駐し（サーバと呼ばれる）、またアプリケーションプログラムは、コンピュ
ータ以外の所で実行される（クライアントと呼ばれる）。アプリケーションがデ
ータを必要とするときは、アプリケーションは、クライアントによりサーバに送
信されるＳＱＬ照会を形成する。サーバは、照会を査定して、結果として生じた
テーブルをクライアントに戻す。

【０３４４】 従って、クライアントとサーバの間のインターフェースは、ＳＱＬ照会を経由
し、サーバは、内部のデータ構造とアプリケーションのコードを知っている。ク
ライアントとサーバは、テーブルの名前とテーブルの属性に合意するだけである
。

【０３４５】 オブジェクト指向のアプローチの中で、モデルは破壊される。各データ項目が
、オブジェクトであるので、サーバは、内部の構造を知らなければならない。こ
の問題は、多様性方法の存在で深刻化する。サーバは、全てのクラスの階層の構
造と詳細を知らなければならない。

【０３４６】 指定されているインデックスで、クライアント／サーバアプローチにオブジェ
クト指向とオブジェクト相関関係モデルを適用できる。例えば、各属性に対して
、アプリケーションプログラムは、キーのパスを送り、リンク指定子は、サーバ
へ向けた希望するノードに導く。データに基づいて、サーバは、アプリケーショ
ンプログラムのデータ構造の如何なる知識も持たないで要求を満たすことができ
る。

【０３４７】 クライアントとサーバは、フィールドの名前とフィールドの指定子に合意しな
ければならない。サーバは、各フィールドのデータのタイプとデータの語義の内
容を知る必要がない。

【０３４８】 本発明のもう一つ態様に従って、更にインデックスの表現を圧縮することが提
案されており、圧縮により、より効率的になっている。以後、スペースの必要条
件を削減するためのトリーと方法に必要なスペースの評価が解説される。

【０３４９】 トリーが、階層インデックスである場合、トリーインデックス構造を分析は、
最後の層（Ｉ_０）に集中される、即ち： トリーの一時キーインデックスのための記憶必要条件。

【０３５０】 トリーベースのデータ構造の最も重要な特徴の一つは、その表現の丁度良いサ
イズである。例えば、圧縮された表現であるので、ＰＡＩＦは、従来のトリーよ
り小さいサイズを維持する。 ＰＡＩＦの最後のレベルのインデックスは、同じブロックの中で他のトリーノー
ドを指しているリンクと、またレコードを指しているリンクを有するトリーから
成る。Ｎをデータベースの中のレコードの数とする。インデックスは、丁度Ｎだ
けの各レコードに向いているポインタから成る。各ポインタに、４バイトが必要
である場合は、ポインタに要するサイズは、４Ｎバイトである。更に、各ポイン
タ（１バイト）が、方向を有しているので、合計は５Ｎバイトである。

【０３５１】 ここで、ＰＡＩＦトリーに必要なスペースを考察する。Ｎポインタは、インデ
ックスから生じ、また各トリーノードは、２個の子を有しているので、ここには
、最大ｎ≦のトリーノードがある。ｄが、トリーのノードの子供平均数を表すも
のとして、ｎ≦Ｎ／（ｄ−１）となる。実際には、ｄ＞＞２、ｎ＜＜Ｎである。
各トリーノードは、レベル番号（１バイト）を有している。各トリーのノードが
、最大１本の流入トリーリンクを有しているので、最大ｎ−１のトリーリンクが
あり、各リンクは、ラベルを有しており、ラベルは、単一文字であり、またブロ
ック間の１つのポインタ（１バイト）であるので、合計は、３ｎバイトとなる。
従って、最悪の場合で、３ｎ＋４Ｎ≦７Ｎバイトが最悪の場合に必要である。４
Ｎと６Ｎバイトの間が、実際に使用される。

【０３５２】 同じ分析を実行するが、他の角度からである、即ち、レベルｋのノードｖから
生ずる２本のポインタｐ_１とｐ_２を考察する。ｘ_１を、ｐ_１がら到達可能なキー
とし、ｘ_２を、ｐ_２から到達可能なキーとする。ｘ_１とｘ_２が、最初のｋ−１文
字を共有する。ＰＡＩＦ構造の中で、これらの文字のなかの一つは、最大一回示
される。Ｂツリー表現の中で、各キーの最初のｋ文字を明確に表示することが必
要である。

【０３５３】 ＰＡＩＦの中の節約は、２倍となる、即ち、最初の初めの文字は、最大一回各
レベルに記憶され、二番目は、全ての文字を表示させる必要はない。

【０３５４】 インデックスの更なる圧縮 前記の解説の中で、スペースの大部分は、レコードに向けたポインタに割かれ
る。ここで、ポインタのスペースを節約することができる方法が、示される。方
法は、レコードに向けられた複数のリンクを同じポインタに共有させることがで
きることを基礎とする。初めに、レコードが、固定しているサイズを有している
ものと仮定する。最初の２個のレコードが同じブロックの中に常駐している場合
は、ブロックに向いている最初のポインタに対して、ポインタを完全なサイズに
維持することができ、各残りの外向けのリンクの各々にポインタを、ブロックに
向けたままにする代わりに、その変位を計算する、即ち、最初の２個のレコード
が、ブロック番号２０００の中に常駐し、ブロック７０００の中に第３レコード
が常駐している場合は、構造２０００（Ｅ、ｆ）７０００（ｈ）を維持すること
ができる。より大きな数の外向きリンクが、同じブロックの全てを指している場
合は、節約はより大きい。ｋリンクが、ブロックを指している場合は、ポインタ
の４Ｂは、全てのｋレコードの間で分割されるので、各レコードをアドレスする
ためのスペースは、４ｋバイトに方向（１バイト）のためのスペースが加えられ
て削減される。ｋ≧４に対して、インデックスの中で各レコードが２バイトを必
要とすることを意味する。

【０３５５】 可変サイズのレコードに対して、ブロックの中で変位を維持することができる
、例えば、２０００（ｅ：ｄ_ｅ，ｆ：ｄ_ｆ）７０００（ｈ：ｄ_ｈ）である。完全
なポインタを維持する代わりに、単独のバイトに納めることができる変位は維持
される。従って、各レコードに対して、共有のためにポインタの中に、方向のた
めの１バイトが、変位のために１バイトが必要であり、レコード毎に合計３バイ
トが必要である。

【０３５６】 図１７の例に注目して、図１７は、それぞれアドレス３００、５０００、７０
００で、３つのデータレコード２００２、２００４、２００６をアドレスする、
リンク２０１０、２０１１、２０１２（数値が、そいれぞれ５、９、Ａ）を有す
るトリーのノード２０００を示している。リンク値（各リンクに対して１バイト
）と、またデータを指すポインタ（４バイト）の示すのに必要なサイズは、１５
バイトである。

【０３５７】 ここで、ノード２０００は、データレコード（２００２、２００４、２００６
）に向かっている共有されているリンク（２０１０）を維持する図１７Ｂに目を
向ける。リンクを示す情報は、ブロック２０２０（４バイト）に向かうアドレス
と、ブロックの中に常駐するデータレコード２００２、２００４、２００６に向
かうリンク値（各リンク値に対して１バイト）である。データブロックを指して
いるポインタとリンクの数値を示すのに必要なサイズは、たった７バイトである
−（３０００：５、９、Ａ）。

【０３５８】 ここで、データレコード２００４をアクセスするために、データブロック＋デ
ータブロックの中のレコードのサイズが全て等しいと仮定してレコードのサイズ
に左右される変位としてアドレスとしてアドレスを計算することができる。

【０３５９】 前記で説明されているとおり、ノード２０００に、データレコードあるはデー
タブロックに向かうリンクを含めることができる（データレコード２００８を受
け入れるデータブロック２００２に向かうリンク２０２４のような）。

【０３６０】 できれば、複数のユーザーが、ほぼ同時にデータベースにアクセスできるよう
に、本発明のデータベースのファイル管理システムが、公知の並行性および／ま
たは配分されている性能と関連することが好ましい。データベースの場所を、中
央の場所に集中させるか、あるいは２個あるいはそれ以上の遠隔の場所に分散さ
せることができる。

【０３６１】 ここで、図１８Ａ−Ｄに注目して、この図の中で、市販のＣツリーベースデー
タベースと対比した、本発明のシステムを利用するファイル管理システムを使用
したレスポンス時間とデータベースのファイルのサイズの意味で、向上されてい
る性能を実証する４個のベンチマークのグラフが示されている。挿入は、ウイン
ドウスで実行されるＵｎｉｆａｃｅ（作業グループのための）オペレーションシ
ステムを経由して実現されている。

【０３６２】 図１８Ａのベンチマークは、常に増大する予めソートされたデータレコードの
数をファイル（０−１，０００，０００）に挿入するために要した分単位の時間
の計測に関する。図１８Ａの中に示されてるとおり、挿入の数が大きくなればな
るほど、本発明のデータベースファイル管理システムのレスポンスについて改善
されている。従って、百万のレコードを挿入するのに、Ｃツリーベースデータベ
ースでは約６６９分を要するのと比較して、本発明のシステムでは、たったの６
５分で済む。更に、本発明のファイル管理システムによるレスポンス時間は、レ
コードの数が増えるにつれて、従来の技術に従った対比されるシステムによるレ
スポンス時間が大幅に増えるのとは反対に、僅かに増えるだけである。

【０３６３】 図１８Ｂのベンチマークは、ファイルの中のデータレコード（０−１，０００
，０００）に比例するメガバイトでのファイルサイズを示している。図１８Ｂの
中で示されているとおり、レコードの数が大きくなればなるほど、本発明のファ
イル管理システムの中のファイルサイズについて改善が大きくなる。従って、百
万のレコードに対して、Ｃツリーベースファイルのサイズは、約１５１メガバイ
トであるのと対比して、本発明のデータベースファイル管理システムでは、たっ
た２２メガバイトである。

【０３６４】 グラフ１８Ｃと１８Ｄは、前者（１８Ｃと１８Ｄ）中で、データレコードが、
無作為に挿入されるのに対して、後者（１８Ａと１８Ｂ）の中では、データレコ
ードが、検索キーに従って予めソートされていると言う事実を除いて、図１８Ａ
と１２Ｂの中で示されているものとほぼ同じである。

【０３６５】 図１９Ａ−Ｄは、本発明のシステム（ＤＯＳオペレーティングシステムの下で
操作される）対市販のＢツリーベースデータベースシステムのベンチマークグラ
フを示している。結果は、前記と同じである、即ち、本発明のシステムが、レス
ポンス時間とファイルのサイズについてより効率的である。

【０３６６】 当業者であれば、アルファベット順とローマ字で指定されている保険請求段階
が、説明の便宜上使用されたものであり、その理由の如何を問わず、段階の順序
を押し付けたり、方法の他の段階に対して逐次実行された段階の回数と解釈され
ないものであることが分かるはずである。

【０３６７】 本発明は、ある程度の特殊性で説明されたが、当業者であれば、別添の請求項
の本発明の範囲と精神から乖離することなく種々の改造と変更を実行することが
できることが分かるはずである。

【図面の簡単な説明】

本発明を理解するために、およびそれが実践でどのように実施されてよいのか
を理解するために、好ましい実施形態は、添付図面に関して、ここでは非制限例
だけによって説明されるだろう。

【図1】 データベースファイル管理システムを利用するシステムの汎用ブロック図を示
す。

【図２】 エンティティ関係図（ＥＲＤ）として表され、説明の目的に役立つサンプルデ
ータベース構造を示す。

【図３】 それぞれのテーブルがほとんどデータ発生を保持しないリレーショナルデータ
モデルに従ってテーブルとしてあらわされている図２のデータベースを示す。

【図４】 従来のＢ＋ツリーインデックススキームを利用するファイル管理システムに従
った図３の「ＣＬＩＥＮＴ（クライアント）」テーブルを示す。

【図５】 従来のトリーインデックススキームを利用するファイル管理システムに従った
図３の「ＣＬＩＥＮＴ」テーブルを示す。

【図６Ａ〜６Ｃ】 ＰＡＩＦインデックススキームを利用するファイル管理システムに従った図３
の「ＣＬＩＥＮＴ」テーブルを示す。

【図７Ａ〜７Ｈ】 本発明の１つの実施形態に従った階層インデックスの構築を例証する概略図を
示す。

【図８Ａ〜８Ｂ】 本発明の別の実施形態に従った階層インデックスの構築を例証する概略図を示
す。

【図９Ａ〜９Ｇ】 本発明の別の実施形態に従った階層インデックスの構築を例証する概略図を示
す。

【図1０Ａ〜１０Ｂ】 本発明の別の実施形態に従った階層インデックスの構築を例証する概略図を示
す。

【図1１】 本発明のまだ別の実施形態に従った階層インデックスの構築を例証する概略図
を示す。

【図1２】 本発明の１つの実施形態に従った指定インデックス内での指名子の使用を例証
するための概略図を示す。

【図1３Ａ〜１３Ｅ】 本発明の１つの実施形態に従って、指定インデックス内のデータレコードの従
属の特徴を例証する５つの概略図を示す。

【図1４】 本発明のある実施形態に従った多次元レコードを例証する指定インデックスの
概略図を示す。

【図1５】 本発明の別の実施形態に従った指定インデックスの概略図を示す。

【図1６】 本発明の１つの実施形態に従って提供されるデータレコード間の関係の特徴を
例証するための概略図を示す。

【図1７Ａ〜１７Ｂ】 本発明の１つの実施形態にしたがったデータレコードへのリンクの圧縮された
表記の概略図を示す。

【図1８Ａ〜１８Ｄ】 市販されているＣｔｒｅｅをベースにしたデータベースに対する、本発明のフ
ァイル管理システムを活用するデータベースの、応答時間とファイルサイズとい
う点での性能の拡張を証明する４つのベンチマークグラフを示す。

【図1９Ａ〜１９Ｄ】 市販されているＢｔｒｅｅをベースにしたデータベースに対する、本発明のフ
ァイル管理システムを活用するデータベースの、応答時間とファイルサイズとい
う点での性能の拡張を証明する４つのベンチマークグラフを示す。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ) ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ， ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，Ｄ Ｋ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ， ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，Ｌ Ｔ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ， ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，Ｕ Ａ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＷ

Claims (98)

【特許請求の範囲】
1. 【請求項1】 データ処理システム上で実行されるデータベースファイル管 理システムにより使用される記憶媒体において、 ブロックに配列され、データレコードと関連しており、キーまたは複数のキー
   によりデータレコードのアクセスまたは更新を可能にし、ブロックの不均衡の構
   造の影響を受けやすい基本区分インデックスを含む階層インデックスを含み、 前記階層インデックスはキーまたは複数のキーによるデータレコードのアクセ
   スまたは更新を可能にし、ブロックの均衡構造を構成する、データ構造。
2. 【請求項２】 前記基本区分インデックスがトリー（trie）である、請求項
   １に記載の階層インデックス。
3. 【請求項３】 データ処理システム上で実行されるデータベースファイル管
   理システムにより使用される記憶媒体において、 データレコードに関連し、キーまたは複数のキーによる前記データレコードの
   アクセスまたは更新を可能にし、ブロックの不均衡の構造の影響を受けやすい基
   本区分インデックスを有し、ブロックに配列され、前記データレコードのキーの
   上に構築されるインデックスを含み、 前記インデックスはキーまたは複数のキーによるデータレコードのアクセスま
   たは更新を可能にし、ブロックの均衡した構造を構成する、データ構造。
4. 【請求項４】 データ処理システムで実行されるデータベースファイル管理
   システムにより使用される記憶媒体において、 データレコードに関連し、キーまたは複数のキーによるデータレコードのアク
   セスまたは更新を可能にし、ブロックの不均衡な構造に影響を受けやすいトリー
   を含み、ブロックに配列され、データレコードのキーの上で構築されているイン
   デックスを含み、 前記インデックスはキーまたは複数のキーによるデータレコードのアクセスま
   たは更新を可能にし、ブロックの均衡した構造を構成する、データ構造。
5. 【請求項５】 前記記憶媒体が外部メモリである、請求項１に記載の階層イ
   ンデックス。
6. 【請求項６】 前記記憶媒体が、さらに内部メモリである、請求項５に記載
   の階層インデックス。
7. 【請求項７】 前記記憶媒体が、内部メモリである、請求項１に記載の階層
   インデックス。
8. 【請求項８】 前記トリーがＰＡＩＦトリーである、請求項２に記載の階層
   インデックス。
9. 【請求項９】 前記階層インデックスの基本区分インデックスおよび代表イ
   ンデックスが、実質的には同じインデックススキームである、請求項１に記載の
   階層インデックス。
10. 【請求項１０】 前記階層インデックスの基本区分インデックスおよび代表
    インデックスが、異なるインデックススキームである、請求項１に記載の階層イ
    ンデックス。
11. 【請求項１１】 前記階層インデックスの代表インデックスが、Ｂｔｒｅｅ
    インデックススキームである、請求項８に記載の階層インデックス。
12. 【請求項１２】 代表インデックスがＢｔｒｅｅインデックススキームであ
    る、請求項１０に記載の階層インデックス。
13. 【請求項１３】 前記階層インデックスの代表インデックスが、実質的には
    ＰＡＩＦインデックススキームである、請求項８に記載の階層インデックス。
14. 【請求項１４】 代表インデックスが、実質的にはＰＡＩＦインデックスス
    キームである、請求項９に記載の階層インデックス。
15. 【請求項１５】 ＯＤＢＣ規格をサポートできる、請求項１に記載の階層イ
    ンデックス。
16. 【請求項１６】 任意のＩｊが、Ｉ_ｊ−１の代表キーの上で構築されるよう
    に構築されている代表インデックスＩ_１．．．Ｉ_ｈと、 を備える、請求項１に記載の階層インデックスＩ_０．．．Ｉ_ｈ。
17. 【請求項１７】 Ｉ_ｈが完全に１つのブロックの中に含まれている、請求項
    １６に記載の階層インデックスＩ_０．．．Ｉ_ｈ。
18. 【請求項１８】 前記記憶媒体が外部メモリである、請求項３に記載の階層
    インデックス。
19. 【請求項１９】 前記記憶媒体が内部メモリである、請求項１８に記載の階
    層インデックス。
20. 【請求項２０】 前記記憶媒体が内部メモリである、請求項３に記載の階層
    インデックス。
21. 【請求項２１】 ＯＤＢＣ規格をサポートできる、請求項３に記載の階層イ
    ンデックス。
22. 【請求項２２】 前記記憶媒体が外部メモリである、請求項４に記載の階層
    インデックス。
23. 【請求項２３】 前記記憶媒体がさらに内部メモリである、請求項２２に記
    載の階層インデックス。
24. 【請求項２４】 前記記憶媒体が内部メモリである、請求項４に記載の階層
    インデックス。
25. 【請求項２５】 ＯＤＢＣ規格をサポートすることができる、請求項４に記
    載の階層インデックス。
26. 【請求項２６】 データレコードをアクセスし、データ処理システムで実行
    されるためのデータファイル管理システムにおいて、データレコードは、ブロッ
    クに配列される基本区分インデックスと関連し、記憶媒体の中に記憶され、基本
    区分インデックスはキーまたは複数のキーによるデータレコードのアクセスまた
    は更新を可能にし、ブロックの不均衡な構造に影響を受けやすく、 （ａ）前記基本区分インデックスを提供するステップと、 （ｂ）前記基本区分インデックスの代表キーの上で代表インデックスを構築し
    、前記階層インデックスがキーまたは複数のキーによるデータレコードのアクセ
    スまたは更新を可能にし、ブロックの平行した構造を構成するステップとでなる
    、ブロックの中に配列される階層インデックスを構築するための方法。
27. 【請求項２７】 前記基本区分インデックスがトリーである、請求項２６に
    記載の階層インデックス。
28. 【請求項２８】 データレコードにアクセスし、データ処理システムで実行
    されるためのデータベースファイル管理システムにおいて、データレコードは、
    ブロックの中に配列されている基本区分インデックスと関連し、記憶媒体の中で
    記憶され、基本区分インデックスはキーまたは複数のキーによるデータレコード
    のアクセスまたは更新を可能にし、ブロックの不均衡な構造に影響をうけやすく
    、 （ａ）前記基本区分インデックスを提供するステップと、 （ｂ）キーまたは複数のキーによるデータレコードのアクセスまたは更新を可
    能にし、ブロックの均衡した構造を構成するインデックスを前記基本区分インデ
    ックスの代表キーの上に構築ステップとでなる、ブロックに配列されるインデッ
    クスをデータレコードのキーの上に構築するための方法。
29. 【請求項２９】 データレコードにアクセスし、データ処理システムで実行
    されるためのデータファイル管理システムにおいて、データレコードがブロック
    の中に配列されているトリーに関連し、記憶媒体の中に記憶され、トリーがキー
    または複数のキーによるデータレコードのアクセスまたは更新を可能にし、ブロ
    ックの不均衡な構造に影響を受けやすく、 （ａ）トリーを提供するステップと、 （ｂ）キーまたは複数のキーによるデータレコードのアクセスまたは構築を可
    能にし、ブロックの均衡した構造を構成するインデックスを前記トリーの代表キ
    ーの上に構築するステップと、 でなる、ブロックに配列されるインデックスを前記データレコードのキー嬢に
    構成する方法。
30. 【請求項３０】 前記記憶媒体が外部メモリである、請求項２６に記載の方
    法。
31. 【請求項３１】 前記記憶媒体が、さらに内部メモリである、請求項３０に
    記載の方法。
32. 【請求項３２】 前記記憶媒体が内部メモリである、請求項２６に記載の方
    法。
33. 【請求項３３】 前記トリーがＰＡＩＦトリーである、請求項２７に記載の
    方法。
34. 【請求項３４】 基本区分インデックスおよび代表インデックスが、実質的
    に同じインデックススキームである、請求項２６に記載の方法。
35. 【請求項３５】 基本区分インデックスおよび代表インデックスが、異なっ
    たインデックススキームである、請求項２６に記載の方法。
36. 【請求項３６】 代表インデックスがＢｔｒｅｅインデックススキームであ
    る、請求項３３に記載の方法。
37. 【請求項３７】 代表インデックスがＢｔｒｅｅインデックススキームであ
    る、請求項３５に記載の方法。
38. 【請求項３８】 代表インデックスがＰＡＩＦインデックススキームである
    、請求項３３に記載の階層インデックス。
39. 【請求項３９】 代表インデックスがＰＡＩＦインデックススキームである
    、請求項３４に記載の階層インデックス。
40. 【請求項４０】 ＯＤＢＣ規格をサポートできる、請求項２６に記載の方法
    。
41. 【請求項４１】 前記記憶媒体が外部メモリである、請求項２８に記載の方
    法。
42. 【請求項４２】 前記記憶媒体が、さらに内部メモリである、請求項４１に
    記載の方法。
43. 【請求項４３】 前記記憶媒体が内部メモリである、請求項２８に記載の方
    法。
44. 【請求項４４】 ＯＤＢＣ規格をサポートできる、請求項２８に記載の方法
    。
45. 【請求項４５】 前記インデックスが逐次動作をサポートする、請求項２６
    に記載の方法。
46. 【請求項４６】 前記インデックスが逐次動作をサポートする、請求項２８
    に記載の方法。
47. 【請求項４７】 前記インデックスが逐次動作をサポートする、請求項２９
    に記載の方法。
48. 【請求項４８】 （ａ）ｈ≧ｋ≧０の場合に、およびｋにつながるＩ_ｈ−１ のブロックを見つけるためにデータレコードのキーの中でそれが見つからないケ
    ースで、Ｉ_ｈからＩ_ｋの中でｋを検索することと、 （ｂ）存在する場合は、キーｋが指定されるデータレコードに関連するＩ_０の
    ブロックに達するまでステップ（ａ）を繰り返すこととでなる、請求項１に記載
    の階層インデックス内でキーｋにより求められているデータレコードｒにアクセ
    スするための方法。
49. 【請求項４９】 （ａ）ｈ≧ｋ≧０の場合、およびｋにつながるＩ_ｈ−１の
    ブロックを見つけるためにデータレコードのキーの中でそれが見つからないケー
    スで、Ｉ_ｈからＩ_ｋの中でｋを検索することと、 （ｂ）存在する場合は、キーｋが指定されるデータレコードに関連するＩ_０の
    ブロックＢｎｉ達するまでステップ（ａ）を繰り返すことと、 （ｃ）ｒをＢに結合することとでなる、請求項１に記載の階層インデックスで
    キーｋによりデータレコードｒを挿入するための方法。
50. 【請求項５０】 （ａ）ｈ≧ｋ≧０の場合に、およびｋにつながるＩ_ｈ−１ のブロックを見つけるために、データレコードのキーの中でそれが見つからない
    ケースで、Ｉ_ｈからＩ_ｋの中でｋを検索することと、 （ｂ）存在する場合は、キーｋが指定されるデータレコードに関連するＩ_０の
    ブロックＢに達するまでステップ（ａ）を繰り返すことと、 （ｃ）Ｂからｒを切断することとでなる、請求項１に記載の階層インデックス
    でキーｋによりデータレコードｒを削除するための方法。
51. 【請求項５１】 （ａ）ｈ≧ｋ≧０の場合、およびｋにつながるＩ_ｈ−１の
    ブロックを見つけるためにデータレコードのキーの中でそれが見つからないケー
    スで、Ｉ_ｈからＩ_ｋの中でｋを検索することと、 （ｂ）存在する場合は、キーｋが指定されるデータレコードに関連するＩ_０の
    ブロックに達するまでステップ（ａ）を繰り返すこととでなる、請求項３に記載
    の階層インデックスでキーｋにより求められているデータレコードｒにアクセス
    するための方法。
52. 【請求項５２】 （ａ）ｈ≧ｋ≧０の場合、およびｋにつながるＩ_ｈ−１の
    ブロックを見つけるために、データレコードのキーの中でそれが見つからないケ
    ースで、Ｉ_ｈからＩ_ｋの中でｋを検索することと、 （ｂ）存在する場合は、キーｋが指定されるデータレコードに関連するＩ_０の
    ブロックＢに達するまでステップ（ａ）を繰り返すことと、 （ｃ）ｒをＢに結合することとでなる、請求項３に記載の階層インデックスで
    キーｋによりデータレコードｒを挿入するための方法。
53. 【請求項５３】 （ａ）ｈ≧ｋ≧０の場合、およびｋにつながるＩ_ｈ−１の
    ブロックを見つけるためにデータレコードのキーの中でそれが見つからないケー
    スで、Ｉ_ｈからＩ_ｋの中でｋを検索することと、 （ｂ）存在する場合、キーｋが指定されるデータレコードに関連するＩ_０のブ
    ロックＢに達するまでステップ（ａ）を繰り返すことと、 （ｃ）ｒをＢから切り離すこととでなる、請求項３に記載の階層インデックス
    でキーｋによりデータレコードｄを削除するための方法。
54. 【請求項５４】 前記構築ステップ（ｂ）が、 （Ｉ_ｈ−１の中の）Ｂがオーバフローする場合、それは２つ（または３つ以上
    ）のブロックに分割され、Ｉ_ｈでのＢの代表は、新規ブロックの代表によって置
    換される。 （ｂ）Ｉ_ｈのブロックがオーバフローすると、追加層Ｉ_ｈ＋１が作成され、階
    層インデックスに加えられる。を含む、請求項２６に記載の方法。
55. 【請求項５５】 進行中に実行される、請求項５４に記載の方法。
56. 【請求項５６】 事後に実行される、請求項５４に記載の方法。
57. 【請求項５７】 前記構築ステップ（ｂ）が、 （ａ）（Ｉ_ｈ−１内の）Ｂは、オーバフローする場合、それは２つ（または３
    つ以上）のブロックに分割され、Ｉ_ｈ内のＢの代表は新規ブロックの代表によっ
    て置換される。 （ｂ）Ｉ_ｈのブロックがオーバフローすると、追加層Ｉ_ｈ＋１が作成され、階
    層インデックスに追加される。
58. 【請求項５８】 進行中に実行される、請求項５７に記載の方法。
59. 【請求項５９】 事後に実行される、請求項５７に記載の方法。
60. 【請求項６０】 構築ステップ（ｂ）が、 （ａ）（Ｂ_ｉ−１の）ブロック内のノード（この事実に基づいて分割ノード）
    の短リンクの間の少なくとも１つの短リンクは、少なくとも２つのトリーがブロ
    ック内に存在するように、削除され（この事実に基づいて分割ノード）、 （ｂ）サブツリーのそれぞれが別個のブロックに移動され、 （ｃ）Ｂ_ｉのブロックが存在しない場合、Ｂ_ｉが作成され、分割ノードのコピ
    ー済みノードはＢ_ｉの中で作成され、 （ｄ）Ｂ_ｉのブロックが存在し、分割ノードのコピー済みノードがＢ_ｉの中に
    存在しない場合には、分割ノードのコピー済みノードは、（分割プロセスの最後
    で）Ｂ_ｉ−１が、Ｂ_ｉの中にルートノードを含む検索パス内でアクセス可能であ
    るように、Ｂ_ｉの中で作成され、Ｂ_ｉのトリーに接続され、 （ｅ）コピー済みノードに直接リンクがない場合、直接リンクはコピー済みノ
    ードからブロックＢ_ｉ−１に追加され、 （ｆ）コピー済みノードからブロックＢ_ｉ−１’ｎｉ追加される遠リンク、ま
    たはＫピー済みノードが遠リンクの方向で子ノードに対する短リンクを有する場
    合、遠リンクは子ノードからブロックＢ_ｉ−１への直接リンクにより置換される
    ことを含む、請求項２６に記載の方法。
61. 【請求項６１】 データ処理システムで実行されるデータベースファイル管
    理システムによって使用される記憶媒体において、複数のノードとリンクを有す
    る少なくとも１つの確率的アクセス索引付けファイル（ＰＡＩＦ）を含むデータ
    構造であって、 前記ＰＡＩＦのリーフノードは、それぞれ前記ユーザアプリケーションプログ
    ラムがアクセス可能な少なくとも１つのデータレコードに関連し、そこでは前記
    データレコードの少なくとも一部が少なくとも１つの検索キーを構成し、 前記ＰＩＡＦ内の選択されたノードは、それぞれ、前記挿入検索キー内の検索
    キー部分の指定オフセットを表し、前記選択ノードの中からの各指定ノードから
    生じるリンク（複数の場合がある）は、それぞれ前記検索キー部分の一意の値を
    表し、 ＰＩＡＦは、それぞれブロックの中に配列されている少なくとも２つのサブＰ
    ＩＡＦを有するＰＩＡＦと、 前記データベースファイル管理システムが、均衡したブロックの構造としてさ
    らに前記ブロックを配列できる、データ処理システム。
62. 【請求項６２】 前記リーフノードに関連する少なくともいくつかのデータ
    レコードが、少なくとも１つの別個のファイルに保持される、請求項６１に記載
    のデータ処理システム。
63. 【請求項６３】 少なくとも１つのリーフが複数のデータレコードと関連す
    る、請求項６１に記載のデータ処理システム。
64. 【請求項６４】 以下のステップの実行を含む、請求項６１に記載の既存の
    ＰＡＩＦの中に新規データレコードを挿入するための方法。 ｉ．ルートノードから始まり、リーフノードに関連するデータレコード（「参
    照データレコード」と呼ばれる）で終わる基準パスに沿って進むステップであっ
    て、基準パス内の各ノードで、リンクにより表される値が前記ノードにより指定
    されるオフセットでのＩビット長のキー部分の値に等しい場合に、前記ノードか
    ら生じるリンクに沿って進むステップであって、ノードに指定されるオフセット
    がキーの中の対応するキー部分を超える場合、あるいは前記値とのリンクがない
    場合、任意の基準データレコードへの任意のパスに沿って進むステップと、 ｉｉ．（これ以降識別オフセット）２つを識別する検索キー部分の最小オフセ
    ットを決定するための新規データレコードの検索キーに、基準データレコードの
    検索キーを比較するステップと、 ｉｉｉ．識別オフセットの値に応じて以下のステップ（ｉｉｉ．０からｉｉｉ
    ．３）の１つに進み、 ｉｉｉ．０ データレコードが等しい場合には、終了する、あるいは ｉｉｉ．１ 識別オフセットが基準パス内のノードの１つにより示されるオフ
    セットに一致する場合には、前記１つのノードから別のリンクを追加し、新規デ
    ータレコードの検索キーから取られる識別オフセットで検索キー部分の値を前記
    リンクに割り当て、 ｉｉｉ．２ 識別オフセットが、リンクにより基準データレコードにリンクさ
    れているリーフノードによって示されるものより大きい場合、 ｉｉｉ．２．１ 基準データレコードからリンクを切断し（つまり、それは一
    時的に「緩んだ（loose）」のままとなる）、該リンクを新規ノードに移動する 。該新規ノードには、識別オフセットの値が割り当てられ、 ｉｉｉ．２．２ 基準データレコードと（現在リーフノードになる）新規ノー
    ドを接続し、該リンク（長リンク）に、基準データレコードの検索キーから取ら
    れる識別オフセットでの検索キー部分の値を割り当て、 ｉｉｉ．２．３ リンクにより新規データレコードと新規ノードを接続し、リ
    ンク（長リンク）に新規データレコードの検索キーから取られる識別オフセット
    での検索キー部分の値を割り当て、 ｉｉｉ．３ 条件ｉｉｉ．０、ｉｉｉ．１およびｉｉｉ．２が満たされると、
    識別オフセットが同時に親ノードに割り当てられているオフセットより大きく、
    子ノードに割り当てられているオフセットより小さくなる（―ケースＡと考えら
    れる）、あるいは基準検索パス内のすべてのノードが識別オフセットより大きい
    値を有する（―ケースＢと考えラ得る）ように、基準検索パス内には親ノードと
    その子ノードが存在する。したがって、以下のサブステップを適用し、 ｉｉｉ．３．１ケースＡおよびＢの場合、新規ノードを作成し、ノードに、前
    記識別オフセットの値を割り当て、 ケースＡだけの場合−親ノードから子ノードへのリンクを切断し、リンクを新
    規内部ノードに移す（つまり、子ノードは一時的に「緩んだ」のままとなる）、
    ｉｉｉ．３．２ ケースＡおよびＢの場合、リンク（長リンク）によって、新規
    データレコードおよび新規内部ノードを接続する。リンクに割り当てられる値は
    、新規データレコードの検索キーから取られるように、識別オフセットでの検索
    キー部分の値であり、 ｉｉｉ．３．３ ケースＡおよびＢの場合、新規リンクによって、新規ノード
    を接続し、ケースＡの場合―子ノード、ケースＢの場合―ルートノードを接続し
    （つまり、新規ノードは、ケースＡの場合―新規親ノードとなり、ケースＢの場
    合―新規ルートノードになる）、前記リンクに割り当てられた値が、基準データ
    レコードの検索キーから取られる、新規ノードによって示されているオフセット
    での検索キー部分である。
65. 【請求項６５】 均衡したＰＡＩＦインデックスを得るための方法であって
    、ＰＡＩＦは、それぞれが前記ノードから発する複数のノードとリンクを収容す
    るブロックを含み、前記ノードの中からのリーフノードがデータレコードと関連
    し、 （ｉ）前記分割ブロックのノードの中からほとんどが前記分割ブロックの内の
    １つの中に収容されず、前記分割ブロックのノードの中から残りのノードがそれ
    以外の分割ブロックの中に収容されるように、ブロックを置換し、置換されたブ
    ロックを、少なくとも２つの分割ブロックで構成するステップと、 （ｉｉ）前記置換されたブロックのノードの中から少なくとも１つのノードを
    、前記少なくとも２つの分割ブロックがその子ブロックであるように１つのブロ
    ックの中にコピーするステップと、を必要な同数だけ実行することを備える方法
    。
66. 【請求項６６】 １０Ｍｂｙｔｅから２０Ｍｂｙｔｅの間、またはそれ以上
    の範囲となる 少なくとも１つの内部メモリ、および外部メモリという記憶媒体
    を有するコンピュータシステムにおいて、 データレコードのキーの上にインデックスを含むデータ構造であって、該イン
    デックスがブロック内に配列され、その結果、１０億データレコードの場合、前
    記データレコードのキーのサイズには関係なく、前記１０億のデータレコードの
    内の任意の１つに関連するブロックにアクセスするためには、前記外部メモリへ
    の実質的にはせいぜい２回のアクセスが必要とされるデータ構造。
67. 【請求項６７】 １０Ｍｂｙｔｅから２０Ｍｂｙｔｅの間、またはそれ以上
    の範囲となる少なくとも１つの内部メモリ、および外部メモリという記憶媒体を
    有するコンピュータシステムにおいて、 データレコードのキー上にインデックスを含むデータ構造であって、該インデ
    ックスがブロック内に配列され、その結果１００万データレコードの場合、前記
    データレコードのキーのサイズに関係なく、インデックスの実質的にはすべての
    ブロックが前記内部メモリに収容される、データ構造。
68. 【請求項６８】 記憶媒体を有するコンピュータシステムにおいて、 データレコードのキーの上にインデックスを含むデータ構造であって、該イン
    デックスはブロックの均衡した構造の中で配列され、前記データレコードに対す
    る逐次動作を実行することを可能にし、インデックスサイズは本質的に前記キー
    のサイズから影響を受けないデータ構造。
69. 【請求項６９】 データ処理システム上で実行されるデータベースファイル
    管理システムにより使用される記憶媒体内で、データレコードのキーの上でのイ
    ンデックスを含むデータ構造であって、前記データレコードが、第２型のデータ
    レコードが第１型ので−アレコードに従属する少なくとも２種類である、データ
    構造。
70. 【請求項７０】 データ処理システム上で実行されるデータベースファイル
    管理システムにより使用される記憶媒体において、 データレコードの指定キー上の指定インデックス、指定データレコードを構成
    し、第２型の指定データレコードが第１型の指定データレコードに従属している
    少なくとも２種類であるデータレコードとを含むデータ構造。
71. 【請求項７１】 前記インデックスが階層インデックスを構成する、請求項
    ６９に記載の記憶媒体。
72. 【請求項７２】 前記指定インデックスが階層インデックスを構成する、請
    求項７０に記載の記憶媒体。
73. 【請求項７３】 前記指定インデックスが多次元インデックスを構成する、
    請求項７０に記載の記憶媒体。
74. 【請求項７４】 前記指定インデックスが多次元インデックスを構成する、
    請求項７２に記載の記憶媒体。
75. 【請求項７５】 前記指定インデックスが、マルチモデルインデックスを構
    成する、請求項７０に記載の記憶媒体。
76. 【請求項７６】 前記指定インデックスがマルチモデルインデックスを構成
    する、請求項７２に記載の記憶媒体。
77. 【請求項７７】 前記指定インデックスがマルチモデルインデックスを構成
    する、請求項７４に記載の記憶媒体。
78. 【請求項７８】 第１型のデータレコードおよび第２型の従属データレコー
    ドが、１対１の関係性を構成する、請求項６９に記載の記憶媒体。
79. 【請求項７９】 第１型のデータレコードと第２型の従属データレコードが
    、１対多の関係性を構成する、請求項７０に記載の記憶媒体。
80. 【請求項８０】 第１型のデータレコードおよび第２型の従属データレコー
    ドが、１対１の関係性を構築する、請求項７１に記載の記憶媒体。
81. 【請求項８１】 第１型のデータレコードと第２型のデータレコードが、１
    対多の関係性を構築する、請求項７３に記載の記憶媒体。
82. 【請求項８２】 前記インデックスがトリーを含む、請求項６９に記載の記
    憶媒体。
83. 【請求項８３】 前記インデックスがトリーを含む、請求項７０に記載の記
    憶媒体。
84. 【請求項８４】 前記階層インデックスの基本区分インデックスがトリーで
    ある、請求項７１に記載の記憶媒体。
85. 【請求項８５】 複合キーＫ_１．．．Ｋ_ｎを有する従属データレコードとい
    う点でのアクセストランザクションまたは更新トランザクションのために、複合
    キーＫ_１．．．Ｋ_ｎに従った従属データレコードにつながる従属検索パスがイン
    デックス内に存在し、従属検索パスが、キーＫ_１．．．ｋ_ｎ−１を有するデータ
    レコードへの検索パスを含む、請求項６９に記載の記憶媒体。
86. 【請求項８６】 複合キーＫ_１．．．Ｋ_ｎを有する従属データレコードとい
    う点でのアクセストランザクションまたは更新トランザクションのために、複合
    キーＫ_１．．．Ｋ_ｎに従った従属データレコードにつながる従属検索パスがイン
    デックス内に存在し、従属検索パスが、キーＫ_１．．．ｋ_ｎ−１を有するデータ
    レコードへの検索パスを含む、請求項７０に記載の記憶媒体。
87. 【請求項８７】 前記マルチモデルがリレーショナルモデルを含む、請求項
    ７５に記載の記憶媒体。
88. 【請求項８８】 前記マルチモデルがオブジェクト指向型モデルを含む、請
    求項７５に記載の記憶媒体。
89. 【請求項８９】 前記マルチモデルがオブジェクトリレーショナルモデルを
    含む、請求項７５に記載の記憶媒体。
90. 【請求項９０】 前記マルチモデルがクライアントサーバモデルに適合する
    、請求項７５に記載の記憶媒体。
91. 【請求項９１】 前記マルチモデルがリレーショナルモデルを含む、請求項
    ７６に記載の記憶媒体。
92. 【請求項９２】 前記マルチモデルがオブジェクト指向モデルを含む、請求
    項７６に記載の記憶媒体。
93. 【請求項９３】 前記マルチモデルがオブジェクトリレーショナルモデルを
    含む、請求項７６に記載の記憶媒体。
94. 【請求項９４】 前記マルチモデルがクライアントサーバモデルと適合する
    、請求項７６に記載の記憶媒体。
95. 【請求項９５】 データ処理システム上で実行されるデータベースファイル
    管理システムにより使用される記憶媒体において、 記憶媒体に記憶され、ブロックに記憶される前記データレコードのキー上で構
    築されているインデックスであって、該インデックスはブロック内に配列され、
    リーフブロックがリンクによってデータリンクにリンクされているインデックス
    と、 前記リンクの少なくとも１つが、同じブロック内に記憶されている少なくとも
    ２つのデータレコードによって共用されるという点で特徴付けられている前記イ
    ンデックスと、を含むデータ構造。
96. 【請求項９６】 前記インデックスがトリーによって構成されている、請求
    項９５に記載の記憶媒体。
97. 【請求項９７】 データ処理システム上で実行されるデータベースファイル
    管理システムにより使用される記憶媒体において、 記憶媒体の中に記憶され、ブロック内に記憶される前記データレコードのキー
    上で構築されているインデックスであって、該インデックスがブロック内に配列
    され、リーフブロックが、リンクによりデータレコードにリンクされるインデッ
    クスと、 前記リンクの少なくとも１つが、同じブロック内に記憶されている少なくとも
    ２つの出たレコードによって共用されるという点で特徴付けられている前記イン
    デックスと、 請求項１に記載の階層インデックスを構成する前記インデックスであって、前
    記基本区分インデックスのブロックが前記データレコードにリンクされている前
    記インデックスと、を含む、データ構造。
98. 【請求項９８】 前記基本区分インデックスがトリーにより構成されている
    、請求項９７に記載の記憶媒体。