JPWO2006046669A1

JPWO2006046669A1 - データベース管理装置、方法、プログラム

Info

Publication number: JPWO2006046669A1
Application number: JP2006543268A
Authority: JP
Inventors: 達夫都司
Original assignee: University of Fukui
Current assignee: University of Fukui
Priority date: 2004-10-28
Filing date: 2005-10-27
Publication date: 2008-05-22
Also published as: EP1845453A4; EP1845453A1; US20080091691A1; WO2006046669A1

Abstract

レコード挿入部は、新たなカラム値を持つレコードを挿入するとき、ＣＶＴにそのカラム値を登録して、拡張可能配列を拡張し、経歴値テーブルおよび係数テーブルに配列拡張の時間的順序である経歴値およびサブ配列内の要素のオフセットを計算する１次関数の係数をそれぞれ登録し、レコード数テーブルに初期値を登録するとともに、当該拡張可能配列の要素の経歴値およびオフセットの２項組表現をキー値としてＲＤＴへ挿入する。これにより、実行時に動的に新たなカラム値を持つレコードを追加することができ、かつ、存在するレコードのみを登録することができるとともに、高速にレコード検索ができる関係データベースを実現する。

Description

本発明は、関係データベースを用いるデータベースに関するものであり、詳細には、データベース装置、データベースの管理方法、データベースのデータ構造、データベースの管理プログラムおよびそれを記録したコンピュータ読み取り可能な記録媒体に関するものである。

現在、広く使われているデータベースは関係データベースである。関係データベースは、図４３に示すような関係テーブルの集合であり、関係テーブルはその中のレコードの集合である。その検索はカラム名や検索の条件を指定することにより、行われる。

このような、関係テーブルは通常２次記憶に置かれ、各レコードは入力された順に逐次、配置される。したがって、次のような欠点がある。
（１）例えば、年齢が２３のレコードを検索する場合、テーブル中のすべてのレコードをメモリ上にロードして年齢カラムをチェックする必要がある。従って、検索時間が大きくなる。
（２）例えば、出身地が福井のレコードは数多く現れ、文字列「福井」を重複して多く格納する必要がある。したがって、ディスク使用量が大きくなる。

このような欠点を回避するための方法として、図４４に示すような多次元配列を使用することが考えられる。配列の各次元はテーブルのカラムに対応し、配列の要素は対応するレコードを表す。

このとき、図４４の例では、年齢が２３のレコード集合は「年齢」次元の値が２３の平面上に空でない配列要素として、存在する。配列要素［＊，＊，２３］（＊は平面上の任意の添字）の番地はアドレス関数により高速に求めることができる。したがって、（１）の欠点は回避される。また、各次元の値は値順にソートされて並べられ、１度しか現れないので、（２）の欠点も回避される。

なお、本願発明に関連する先行技術文献としては、次の非特許文献１〜４がある。

〔非特許文献１〕
Ａ．Ｌ．Ｒｏｓｅｎｂｅｒｇ、“ＡｌｌｏｃａｔｉｎｇＳｔｏｒａｇｅｆｏｒＥｘｔｅｎｄｉｂｌｅＡｒｒａｙｓ”、ＪＡＣＭ、Ｖｏｌ．２１、ｐｐ．６５２−６７０（１９７４）
〔非特許文献２〕
Ｅ．Ｊ．Ｏｔｏｏ、Ｔ．Ｈ．Ｍｅｒｒｅｔｔ、“ＡＳｔｏｒａｇｅＳｃｈｅｍｅｆｏｒＥｘｔｅｎｄｉｂｌｅＡｒｒａｙｓ”、Ｃｏｍｐｕｔｉｎｇ、Ｖｏｌ．３１、ｐｐ．１−９（１９８３）
〔非特許文献３〕
Ｄ．ＲｏｔｅｍａｎｄＪ．Ｌ．Ｚｈａｏ，“ＥｘｔｅｎｄｉｂｌｅＡｒｒａｙｓｆｏｒＳｔａｔｉｓｔｉｃａｌＤａｔａｂａｓｅｓａｎｄＯＬＡＰＡｐｐｌｉｃａｔｉｏｎｓ”，Ｐｒｏｃｃｅｅｄｉｎｇｓｏｆ７−ｔｈＩｎｔｅｒｎａｔｉｏｎａｌＷｏｒｋｉｎｇＣｏｎｆｅｒｅｎｃｅｏｎＳｃｉｅｎｔｉｆｉｃａｎｄＳｔａｔｉｓｔｉｃａｌＤａｔａｂａｓｅＭａｎａｇｅｍｅｎｔ，ｐｐ．１０８−１１７（１９９６）
〔非特許文献４〕
都司達夫、水野剛、宝珍輝尚、樋口健、“拡張可能配列の遅延割付け方式”、電子情報通信学会論文誌Ｄ−Ｉ、Ｖｏｌ．Ｊ８６−Ｄ−Ｉ、Ｎｏ．５、ｐｐ．３５１−３５６（２００３）
しかしながら、従来の固定サイズの多次元配列によるテーブルの表現には次のような欠点がある。
（ａ）各次元のサイズは固定である。固定であるから、アドレス関数が作成できる。したがって、新たなカラム値を持つレコードの追加は不可能である。
（ｂ）各次元の値の組み合わせがすべて存在するような密なテーブルは稀であるので、配列内の有効要素は少ない（疎配列）。有効要素の割合は通常数％以下、場合によっては０．１％以下であることが多い。このような疎配列に対しても、アドレス関数によって配列要素にアクセスできるためには空の要素（存在しないレコード）についても記憶領域を確保する必要があり、途方もないディスクスペースの無駄になる。

本発明は、上記の問題点に鑑みてなされたものであり、その目的は、実行時に動的に新たなカラム値を持つレコードを追加することができる、かつ、存在するレコードのみを登録することができるとともに、高速にレコード検索ができるデータベース装置、データベースの管理方法、データベースのデータ構造、データベースの管理プログラムおよびそれを記録したコンピュータ読み取り可能な記録媒体を提供することにある。

上記の課題を解決するために、本発明に係るデータベース装置は、関係テーブルを用いたデータベース装置であって、関係テーブルの各レコードに対応する拡張可能配列の要素の位置を示す位置情報をキー値として登録した要素位置Ｂ＋木データを格納したデータベース記憶部を具備するとともに、上記位置情報が、要素が属する拡張可能配列の区画の先頭要素の位置を示す区画位置情報と区画内における要素の位置を示す区画内オフセットとを含む情報であることを特徴としている。

ここで、本発明では、拡張可能配列の区画を様々に選択可能である。そして、上記要素位置Ｂ＋木データとして、区画に応じた要素位置データを登録する。

例えば、（１）区画を拡張可能配列のサブ配列とすれば、上記要素位置Ｂ＋木データとして、上記区画位置情報を、関係テーブルの各レコードに対応する拡張可能配列の要素が属するサブ配列の経歴値とし、上記区画内オフセットを、このサブ配列内の該要素のサブ配列内オフセットとした、２項組表現をキー値として登録した２項組Ｂ＋木データを利用できる。（２）また、区画をチャンク化拡張可能配列のチャンクとすれば、上記要素位置Ｂ＋木データとして、上記区画位置情報を、関係テーブルの各レコードに対応するチャンク化拡張可能配列の要素が属するチャンクのチャンク番号とし、上記区画内オフセットを該要素のチャンク内オフセットとした、２項組表現をキー値として登録した２項組Ｂ＋木データを利用できる。

具体的には、拡張可能配列の区画の先頭要素の位置を示す区画位置情報と区画内における要素の位置を示す区画内オフセットとの２項組表現は、（１）の場合、＜経歴値，サブ配列内オフセット＞であり、（２）の場合、＜チャンク番号，チャンク内オフセット＞となる。なお、チャンク番号は、要素の添字＜ｉ１，ｉ２，．．．，ｉｎ＞より、チャンク拡張可能配列の要素（チャンク）の位置決定機構により決定される。

よって、上記データベース装置では、２項組Ｂ＋木データ（要素位置Ｂ＋木データ）を参照することにより、区画位置情報と区画内オフセットとの２項組表現に基づいて、拡張可能配列の要素の位置を特定することが可能となる。

なお、「区画位置情報」および「区画内オフセット」は以下のように記述・定義できる。

拡張可能配列の全要素集合Ｅを互いに共通な要素を持たない部分集合の集合に類別（ｐａｒｔｉｔｉｏｎ）したとき、その任意の部分集合Ｓを拡張可能配列の「区画」と定義する。そして、部分集合Ｓに対応する記憶表現の先頭要素の要素集合Ｅ内での位置を特定するために必要な情報を「区画位置情報」と定義する。また、部分集合Ｓ内における要素の位置を特定するための部分集合Ｓの先頭要素の位置からの変位を「区画内オフセット」と定義する。

以上の定義による「区画位置情報」および「区画内オフセット」の両者により、拡張可能配列の任意の要素について、その位置が一意的に決定される。このような定義の下で、（１）では区画である部分集合Ｓをサブ配列としており、（２）では区画である部分集合Ｓをチャンクとしている。

さらに、（１）（２）では、「（これら２つの）２項組表現をキー値として登録した２項組Ｂ＋木データ」と記述しているが、必ずしも２項組として、キー値の記憶表現において位置的に連接している必要はない。すなわち、要素位置Ｂ＋木データには、キー値の記憶表現にこれら２つの情報（「区画位置情報」および「区画内オフセット」）が含まれていればよい。そして、本発明に係るデータベース装置には、これらの２つの情報を使って要素に迅速にアクセスするための手段を具備していればよい。

（１）２項組Ｂ＋木データに、関係テーブルの各レコードに対応する拡張可能配列の要素の経歴値とサブ配列内オフセットとの２項組表現をキー値として登録する場合のデータベースの構成と、データを検索、挿入、削除する機能は以下のとおりである。

本発明に係るデータベース装置は、上記データベース記憶部に、上記区画位置情報である、関係テーブルの各レコードに対応する拡張可能配列の要素の経歴値と、上記区画内オフセットであるサブ配列内オフセットとの２項組表現をキー値として登録した、上記要素位置Ｂ＋木データである第２のＢ＋木データとともに、関係テーブルのカラム値ごとに設けられ、該カラム値から拡張可能配列の添字に変換するための第１のＢ＋木データと、配列拡張の時間的順序を登録した経歴値テーブルと、サブ配列内の要素のサブ配列内オフセットを計算する１次関数の係数からなる係数ベクトルをサブ配列ごとに登録した係数テーブルと、拡張可能配列の添字ごとにその添字に対応するカラム値を持つすべてのレコード数を登録したレコード数テーブルと、を格納したことを特徴としている。

また、本発明に係るデータベース装置は、検索要求に対して、上記第２のＢ＋木データより検索要求に対応する経歴値とサブ配列内オフセットの２項組を検索するレコード検索部を具備することを特徴としている。

また、本発明に係るデータベース装置は、新たなカラム値を持つレコードを挿入するとき、上記第１のＢ＋木データにそのカラム値を登録して、拡張可能配列を拡張し、上記経歴値テーブルおよび上記係数テーブルに経歴値および係数をそれぞれ登録し、上記レコード数テーブルに初期値を登録するとともに、当該拡張可能配列の要素の経歴値およびサブ配列内オフセットの２項組表現をキー値として上記第２のＢ＋木データへ挿入するレコード挿入部を具備することを特徴としている。

また、本発明に係るデータベース装置は、１つのレコードを削除するとき、経歴値とサブ配列内オフセットの２項組を上記第２のＢ＋木データから削除するとともに、上記レコード数テーブルのレコード数を１だけ減算するレコード削除部を具備することを特徴としている。

そして、上記の構成により、本発明のデータベースは、関係テーブルのカラム値ごとに設けられ、該カラム値から拡張可能配列の添字に変換するための第１のＢ＋木データと、関係テーブルの各レコードに対応する拡張可能配列の要素の経歴値およびサブ配列内オフセットの２項組表現をキー値として登録した第２のＢ＋木データと、配列拡張の時間的順序を登録した経歴値テーブルと、サブ配列内の要素のサブ配列内オフセットを計算する１次関数の係数からなる係数ベクトルをサブ配列ごとに登録した係数テーブルと、拡張可能配列の添字ごとにその添字に対応するカラム値を持つすべてのレコード数を登録したレコード数テーブルとよりなるデータ構造を有している。

ｎ個のカラムからなる関係テーブルのレコードは、ｎ次元拡張可能配列のｎ個の添字の組で表される。

本発明では、この添字の組は新たなカラム値を持つレコードの追加により拡張付加されるｎ−１次元のサブ配列の付加順を表す拡張経歴値とサブ配列内のサブ配列内オフセットの２項組で表される。すなわち、ｎが大きくなれば関係テーブルのレコード長は大きくなるが、ｎにかかわらず、経歴値およびサブ配列内オフセットの２項組でレコードを表している。したがって、特にカラム数の多い関係テーブルの場合でも、極めて記憶効率がよいという効果を奏する。また、存在しているレコードについてのみ、対応する２項組をキー値としてＢ＋木に登録しており、この点からも記憶効率が向上するという効果を奏する。さらに、Ｂ＋木の利用により、高速検索処理が可能であるという効果を奏する。

（２）２項組Ｂ＋木データに、関係テーブルの各レコードに対応するチャンク化拡張可能配列の要素が属するチャンクのチャンク番号とチャンク内オフセットとの２項組表現をキー値として登録する場合のデータベースの構成と、データを検索、挿入、削除する機能は以下のとおりである。

本発明に係るデータベース装置は、上記拡張可能配列がチャンク化拡張可能配列であって、上記データベース記憶部に、上記区画位置情報である、関係テーブルの各レコードに対応するチャンク化拡張可能配列の要素が属するチャンクのチャンク番号と、上記区画内オフセットであるチャンク内オフセットとの２項組表現をキー値として登録した、上記要素位置Ｂ＋木データである第２のＢ＋木データとともに、関係テーブルのカラム値ごとに設けられ、該カラム値からチャンク化拡張可能配列のチャンクサブ配列情報の位置を表す添字とチャンク内での添字の２項組表現に変換するための第１のＢ＋木データと、チャンクサブ配列情報としてチャンク配列拡張の時間的順序を登録した経歴値テーブルと、チャンクサブ配列内のチャンクの番号を計算する１次関数の係数からなる係数ベクトルをチャンクサブ配列ごとに登録した係数テーブルと、カラム値の情報として、拡張可能配列の添字ごとに対応する該カラム値またはカラム値が格納されている記憶領域へのポインタからなるカラム値テーブルと、該カラム値を持つすべてのレコード数を登録したレコード数テーブルと、を格納したことを特徴としている。

また、本発明に係るデータベース装置は、検索要求に対して、上記第２のＢ＋木データより検索要求に対応するチャンク番号とチャンク内オフセットとの２項組を検索するレコード検索部を具備することを特徴としている。

また、本発明に係るデータベース装置は、新たなカラム値を持つレコードを挿入するとき、上記第１のＢ＋木データにそのカラム値を登録して、チャンク化拡張可能配列を拡張し、上記経歴値テーブルおよび上記係数テーブルに経歴値および係数をそれぞれ登録し、上記レコード数テーブルに初期値を登録するとともに、当該拡張可能配列の要素が所属するチャンクのチャンク番号とチャンク内オフセットとの２項組表現をキー値として上記第２のＢ＋木データへ挿入するレコード挿入部を具備することを特徴としている。

また、本発明に係るデータベース装置は、１つのレコードを削除するとき、チャンク番号とチャンク内オフセットの２項組を上記第２のＢ＋木データから削除するとともに、上記レコード数テーブルのレコード数を１だけ減算するレコード削除部を具備することを特徴としている。

そして、上記の構成により、本発明のデータベースは、関係テーブルのカラム値ごとに設けられ、該カラム値からチャンク化拡張可能配列のチャンクサブ配列情報の位置を表す添字とチャンク内での添字の２項組表現に変換するための第１のＢ＋木データと、関係テーブルの各レコードに対応するチャンク化拡張可能配列の要素が属するチャンクのチャンク番号とチャンク内オフセットの２項組表現をキー値として登録した第２のＢ＋木データと、チャンクサブ配列情報としてチャンク配列拡張の時間的順序を登録した経歴値テーブルと、チャンクサブ配列内のチャンクの番号を計算する１次関数の係数からなる係数ベクトルをチャンクサブ配列ごとに登録した係数テーブルと、カラム値の情報として、拡張可能配列の添字ごとに対応するカラム値またはカラム値が格納されている記憶領域へのポインタからなるカラム値テーブルと、該カラム値を持つすべてのレコード数を登録したレコード数テーブルとよりなるデータ構造を有している。

本発明では、この添字の組は新たなカラム値を持つレコードの追加により拡張付加されるｎ次元のチャンクサブ配列の付加順を表す拡張経歴値とチャンクサブ配列内のオフセットの２項組で表される。すなわち、ｎが大きくなれば関係テーブルのレコード長は大きくなるが、ｎにかかわらず、チャンク番号およびチャンク内オフセットの２項組でレコードを表している。したがって、特にカラム数の多い関係テーブルの場合でも、極めて記憶効率がよいという効果を奏する。また、存在しているレコードについてのみ、対応する２項組をキー値としてＢ＋木に登録しており、この点からも記憶効率が向上するという効果を奏する。さらに、Ｂ＋木の利用により、高速検索処理が可能であるという効果を奏する。

上述の（１）（２）のデータベース構成のいずれにおいても、拡張可能配列を使用するとき、存在しないレコードは実際に記憶域として確保する必要はないものの、膨大な論理記憶空間を必要とする。この記憶空間は、使用するコンピュータのアドレス長をａとすると２^ａとなり、このサイズを超えるアドレス（オフセット値）を扱うことができない。従来の研究では、この点に関する指摘はなく、したがって、その解決策も示されていない。このことに関する本発明の重要なポイントの１つは、この解決策を関係テーブルの垂直分割技法として提示している点である（〔発明を実施するための最良の形態〕の２．２節参照）。また、本技法は、一意キーテーブルに基づいている（同２．１節参照）。この垂直分割技法を使えば、大規模関係テーブルを効率よく取り扱うことが可能であり、検索速度がさらに向上するという効果を奏する。

本発明のさらに他の目的、特徴、および優れた点は、以下に示す記載によって十分わかるであろう。また、本発明の利益は、添付図面を参照した次の説明で明白になるであろう。

本発明の一実施の形態に係るデータベース装置の構成の概略を示す機能ブロック図である。関係テーブルのＨＯＲＴによる表現例を示す説明図である。複数のカラム値が指定されない場合の検索アルゴリズムを示す擬似コードリストである。レコード挿入のアルゴリズムを示す擬似コードリストである。レコード削除のアルゴリズムを示す擬似コードリストである。５次元のＨＯＲＴに挿入可能なレコード数を示すグラフである。一意キーテーブルを用いたＨＯＲＴの例を示す説明図である。ＨＯＲＴに挿入可能なレコード数を示す説明図である。一意キーテーブルを持つレコードの挿入のアルゴリズムを示す擬似コードリストである。一意キーを持つレコードの削除のアルゴリズムを示す擬似コードリストである。一意キーを持つレコードの検索のアルゴリズムを示す擬似コードリストである。一意キーが複数ある場合の一意キーテーブルの構成の例を示す説明図である。関係テーブルの垂直分割とそのＨＯＲＴ表現を使った実装例を示す説明図である。関係テーブルの垂直分割のアルゴリズムを示す擬似コードリストである。ＨＯＲＴのカラム数と各カラムのカラム値の最大数との関係を示すグラフである。垂直分割後のレコードの挿入のアルゴリズムを示す擬似コードリストである。垂直分割後のレコードの削除のアルゴリズムを示す擬似コードリストである。垂直分割後のレコードの検索のアルゴリズムを示す擬似コードリストである。ｎ次元拡張可能配列における有効なアドレスの割合である。ＨＯＲＴのチャンク化を示す説明図である。チャンク化したｎ次元拡張可能配列における有効なアドレスの割合である。１カラムあたりのカラム値の種類である。チャンク化ＨＯＲＴデータ構造における一意キーの説明図である。チャンク化ＨＯＲＴデータ構造におけるテーブルの垂直分割の説明図である。複合オブジェクトの定義例である。図２５の定義例による、複合オブジェクトインスタンス例の関係テーブル表現を示す。図２６のテーブルｂｏｏｋのＨＯＲＴ表現の一例を示す説明図である。図２６のテーブルｂｏｏｋのＨＯＲＴ表現の他の例を示す説明図である。ＤＴＤ付きのＸＭＬ文書例である。図２９の関係テーブルによる表現例である。ＸＭＬ文書例である。ＸＭＬ文書例である。ＸＭＬ文書例である。ＸＭＬ文書例である。図２９に示したＸＭＬ文書の木グラフ表現を示す。図３５に示した木グラフのノードのメタ情報をカラムとする関係テーブル表現を示す。カラム数６、カラムの型が文字列型の場合のＨＯＲＴシステムの計測結果である。カラム数６、カラムの型が文字列型の場合のＰｏｓｔｇｒｅｓシステムの計測結果である。カラム数６、整数型（４バイト長）の場合のＨＯＲＴシステムの計測結果である。カラム数６、整数型（４バイト長）の場合のＰｏｓｔｇｒｅｓシステムの計測結果である。９つのカラムのデータ型が文字列型（２０バイト長）の場合の計測結果である。９つのカラムのデータ型が整数型（４バイト長）の場合の計測結果である。従来の技術に係る関係テーブルを示す説明図である。従来の技術に係る配列による関係テーブルの表現を示す説明図である。従来の技術に係るインデックス配列モデルを示す説明図である。

本発明は、拡張可能配列の考え方に基づき、経歴・オフセット法と呼ぶ関係データベーステーブル（関係テーブル）の新しい実装方式を示している。ｎ個のカラムからなる関係テーブルのレコードはｎ次元拡張可能配列のｎ個の添字の組で表される。本発明では、この添字の組は、新たなカラム値を持つレコードの追加により拡張付加されるｎ−１次元のサブ配列の付加順を表す拡張経歴値とサブ配列内のオフセットとの２項組で表される。本発明の実装方式は、２項組をキー値とするＢ＋木を主データ構造として、従来の実装方式より高速処理可能であり、かつ、記憶コストも低い。また、本発明の実装方式では、関係テーブルのカラム数が多く、カラム値の数が増加する場合にはオフセットの空間がオーバーフローする可能性があるが、この点についても、後述のとおり経歴・オフセット法の利点を劣化させずに克服できる。

上記のように、本発明は、関係テーブルのレコード集合を拡張可能な多次元配列で実装することにより、新たなカラム値を持つレコード挿入に対処できるとともに、アドレス関数を使ってレコードの格納位置を高速に検索可能とするものである。それゆえ、本発明によれば、大規模なテーブルを従来技術より効率よく扱うことが可能であり、産業上の多くの分野に適用できる。

以下、本発明の実施の形態について詳細に説明する。

〔前提となる技術〕
まず、本発明の前提となる技術である「拡張可能配列」について説明する。なお、本発明のテーブル実装方式を、「経歴・オフセット法」（Ｈｉｓｔｏｒｙ−ｏｆｆｓｅｔｉｍｐｌｅｍｅｎｔａｔｉｏｎｏｆＲｅｌａｔｉｏｎａｌＴａｂｌｅ：ＨＯＲＴ）と呼ぶこととする。ＨＯＲＴは以下に説明する拡張可能配列の考え方に基づいている。

拡張可能配列（ｅｘｔｅｎｄｉｂｌｅａｒｒａｙ）は、実行時に動的に任意の次元方向にそのサイズを拡張できる配列である。拡張可能配列では拡張部分のみが動的に割付けられ、拡張前の配列要素のデータは再配置することなくそのまま利用される。配列サイズがあらかじめ予測不能な場合や、必要サイズが実行環境の変化に応じて動的に変化し得るような種々のアプリケーション分野において使用することができる。拡張可能配列のモデルとしてＥ．Ｊ．Ｏｔｏｏ等により提案されたインデックス配列モデル（非特許文献２）はインデックス配列用の記憶域を付加することにより高速に配列要素を参照することができ、例えばハッシュを使った他の方式（非特許文献１）より優れていることが示されている。また、非特許文献３は、このインデックス配列の構造化について述べているが、このことは本発明とは視点が全く異なる。また、非特許文献２〜４はいずれも、〔発明が解決しようとする課題〕の問題点（ｂ）は取り上げておらず、拡張可能配列のサブ配列のための連続記憶領域を必要としており、実用的には使用できない。なお、本発明のベースは、このインデックス配列モデルの考え方に基づいており、ここでは、このモデルについてその概略を述べる。

ある次元方向の配列拡張はその次元を除くｎ−１次元の配列断面に相当するサイズの連続するメモリ領域（サブ配列という）を確保し、Ａに追加することによって行われる。非特許文献２では、拡張時に確保されるサブ配列はメモリ領域の０番地から拡張の順に、順次、連続領域に割り付けられることを前提としている。通常行われるメモリの動的割付けにおいては、必ずしもメモリの連続領域を割り付けるとは限らない。このことをはじめ、現実の使用に即したいくつかの改良を施したモデルが非特許文献４で提案されている。以下では、非特許文献４のモデルについて述べる。

ｎ次元拡張可能配列Ａは１つの経歴値カウンタと次元ごとに３種類の補助テーブルを有している。これらの補助テーブルは経歴値テーブル、アドレステーブル、および係数テーブルと呼ばれる。経歴値テーブルは、配列拡張の時間的順序を表す１次元配列であり、配列拡張が行われるたびに、固定配列のｎ−１次元のサブ配列が動的に割り付けられ、アドレス番地テーブルにその先頭番地が記録される。また、現在の経歴値カウンタが１インクリメントされ、その値が経歴値テーブルに順次記録される。拡張可能配列およびサブ配列の各次元の添字はいずれも０から始まり、次元は１から数えるものとし、配列の１要素のサイズは１とする。

例えば、各次元のサイズが［ｓ１，ｓ２，ｓ３，ｓ４］の通常の固定サイズの４次元配列要素をメモリ上に次元１〜４の順に優先して割り付ける場合、要素＜ｉ１，ｉ２，ｉ３，ｉ４＞のアドレスはよく知られているように、
ｓ２ｓ３ｓ４ｉ１＋ｓ３ｓ４ｉ２＋ｓ４ｉ３＋ｉ４（１）
なるｉ１，ｉ２，ｉ３，ｉ４に関する１次関数を計算して得られる。

これに対して、例えば現在のサイズが［ｓ１，ｓ２，ｓ３，ｓ４］の４次元拡張可能配列の場合には、次元２の方向に一つ拡張するとき、サイズ［ｓ２，ｓ３，ｓ４］の３次元サブ配列Ｓが動的に確保される。アドレステーブルは各サブ配列の先頭アドレスを保持する１次元配列である。要素＜ｉ１，ｉ２，ｉ３，ｉ４＞が格納されているアドレスはＳの先頭番地に数式（１）で計算されるオフセットを加えればよい。

Ａが３次元以上の拡張可能配列の場合には、サブ配列内の要素のオフセットを計算する１次関数のｎ−２個の係数からなる係数ベクトルをサブ配列ごとに記録する係数テーブルを各次元について必要とする。例えば、上記サブ配列Ｓの要素＜ｉ１，ｉ２，ｉ３＞のオフセットは数式（１）と同様、１次関数ｓ３ｓ４ｉ１＋ｓ４ｉ２＋ｉ３となる。このとき、（ｓ３ｓ４，ｓ４）がＳの係数ベクトルである。係数ベクトルの値は拡張時のＡの各次元のサイズに依存しているので、拡張時に係数ベクトルを計算し、それを拡張次元の係数テーブルのスロットに書き込む。

配列要素へのアクセスは次のように行われる。図４５において、次元１方向および次元２方向の経歴値テーブルをそれぞれＨ１，Ｈ２とし、またアドレステーブルをそれぞれＡ１，Ａ２とする。例えば配列要素＜３，４＞のアドレス計算は次のように行われる。Ｈ１［３］＜Ｈ２［４］であるから、要素＜３，４＞を含むサブ配列Ｓは経歴値Ｈ２［４］＝７のときに割付けられ、その先頭アドレスはＡ２［４］＝６０である。また、要素［３，４］はＳでは要素＜３＞であるので、求めるアドレスは６３となる。

〔実施の形態〕
本発明の一実施の形態について図１から図４２に基づいて説明すれば、以下のとおりである。まず、本発明に係る関係テーブルの記憶、操作方式とその実現ソフトウェアについて説明する。

１．ＨＯＲＴの基本データ構造とその操作
１．１ＨＯＲＴの基本データ構造
図２は、本実施の形態に係る関係テーブルのＨＯＲＴによる表現例を示す説明図である。ｎ個のカラムからなる関係テーブルＴはｎ次元ＨＯＲＴにより実装される。ｎ次元ＨＯＲＴは次のデータ構造からなる。
（１）ｎ個のＣＶＴ（ｋｅｙ−ｓｕｂｓｃｒｉｐｔＣｏｎＶｅｒｓｉｏｎＴｒｅｅ）とＲＤＴ（ＲｅａｌＤａｔａＴｒｅｅ）のｎ＋１個のＢ＋木。
（２）〔前提となる技術〕において説明した「拡張可能配列」の３種類の補助テーブルの内、経歴値テーブル、および係数テーブル。
（３）添字ごとにその添字に対応するカラム値を持つすべてのレコード数を記録するレコード数テーブル。

（２）と（３）は拡張可能配列の各次元サイズと同一要素数を持つ一次元配列であることから、次元ごとに確保されるこれら３種類の補助テーブルを以降において、まとめて“ＨＯＲＴテーブル”と呼ぶ。したがって、ＨＯＲＴテーブルは一次元配列でありその添字ｉのスロット（要素）はこれら３種類の補助テーブルの添字ｉのスロットをまとめたものである。さらに、上記（１）（２）（３）のデータ構造からなるＨＯＲＴは以降でＨＯＲＴデータ構造とも言う。

Ｔの各カラムに対して１つのＣＶＴが作成される。ＣＶＴはカラム値から〔前提となる技術〕において説明した拡張可能配列の添字に変換するＢ＋木である。テーブルレコードのカラム値のｎ項組をｒ＝＜ｃ１，ｃ２，・・・，ｃｎ＞とすれば、これらｎ個のＣＶＴを使って、ｒは配列添字のｎ項組Ｉ＝＜ｉ１，ｉ２，・・・，ｉｎ＞に変換される。上述した拡張可能配列が記憶領域上にｒとＩの対応を保って実現されているならば、要素１について、拡張可能配列の要素のアドレス計算手順にしたがって、そのアドレスを求めることができる。

本発明では、経歴値とサブ配列が１対１に対応していることに注目して、添字の組Ｉで表される配列要素をそれが属するサブ配列の経歴値ｈとサブ配列内でのオフセット（サブ配列内オフセット、以下単に「オフセットと表記することがある）ｏの２項組＜ｈ，ｏ＞で表す。次元数ｎが大きくても２項組で表現できることに注意されたい。ＨＯＲＴデータ構造により表現される関係テーブルのレコード集合をＲ＝｛ｒ１，ｒ２，・・・，ｒｍ｝とする。このとき、レコードｒｉ∈Ｒ（ｉ＝１，・・・，ｍ）について、それに対応する拡張可能配列要素の経歴値とオフセットの２項組表現＜ｈｉ，ｏｉ＞がキー値としてＲＤＴに格納される。なお、上述した拡張可能配列のサブ配列のための連続記憶領域は確保されない。この意味で、キー値が置かれる論理空間である拡張可能配列を以後、論理拡張可能配列という。キー値は関係テーブルのレコードそのものを表現しており、Ｒに存在しているレコードについてのみ、そのキー値がＲＤＴに登録される。従って、発明が解決しようとする課題で述べた問題点（ｂ）は解決される。なお、キー値である２項組＜ｈ，ｏ＞においてｈの記憶バイトはｏの記憶バイトよりも上位に配置される。したがって、同一経歴値を持つキー値集合はＲＤＴのシーケンスセット上でｏの昇順に連続的に配置されている。

存在しているレコードのみ登録されることから、各次元のＣＶＴへの挿入、削除に伴って、ＣＶＴの保守をする必要がある。すなわち、新たなカラム値ｖを持つレコードがＨＯＲＴデータ構造に登録されるときには、ＣＶＴにそのカラム値を登録後、論理拡張可能配列が拡張される。このとき、経歴値テーブル、および係数テーブルに値を記入後、上記（３）のレコード数を記録する補助テーブルに初期値として１を記入する。以後、同じカラム値ｖを持つレコードの挿入、削除が行われるたびに、ＲＤＴへの挿入、削除が行われると共に、この補助テーブルの当該レコード数の値が増減される。削除により、カラム値ｖを有するレコードが無くなった場合には、ＣＶＴからもカラム値ｖは削除される。なお、このレコード数の情報は、Ｔに対する検索処理の最適化等において、参照できる。

ＣＶＴに登録されていたカラム値が削除される場合、ＨＯＲＴテーブルに使用しない空きスロットができてしまう。ここではこのような空きスロットがリストで繋がれて、再利用される。リストの連結には、上記ＨＯＲＴの基本データ構造の（３）のレコード数のフィールドが使われ、経歴値をはじめ他の情報はすべてそのまま、再利用時に使用される。ＣＶＴに新たなカラム値が登録される場合には、まず、この空きスロットリストが調べられ、リストが空でない場合には、その先頭空きスロットをそのまま使用し、その添字をＣＶＴに登録する。論理拡張配列の拡張は行われない。リストが空の場合に、はじめてその次元の論理拡張配列の拡張を行う。

１．２関係テーブル操作に対するＨＯＲＴ基本データ構造の操作
関係テーブルＴのカラムの組をＣ＝＜Ｃ１，Ｃ２，・・・，Ｃｎ＞として、Ｔのレコード集合をＲとする。重複を排したＣｉのカラム値の集合をＶｉ＝｛ｖｉ｜ｒ＝＜ｖ１，・・・，ｖｉ，・・・，ｖｎ＞∈Ｒ，１≦ｉ≦ｎ｝とする。また、Ｖｉの各カラム値を経歴値テーブルの添字の値にマッピングする次元ｉのＣＶＴをＣＶＴｉと表記する。さらに次元ｉのＨＯＲＴテーブルをＨＴｉと表記し、その空きスロットリストをＳＬｉと表記する。

（１）レコードｒ＝＜ｖ１，ｖ２，・・・，ｖｎ＞の検索
まず、関係テーブルＴのレコードｒ＝＜ｖ１，ｖ２，・・・，ｖｎ＞のすべてのカラム値が指定された場合のレコードの存在判定について述べる。ｎ個のＣＶＴを検索して添字のｎ項組Ｉ＝＜ＣＶＴ１（ｖ１），ＣＶＴ２（ｖ２），・・・，ＣＶＴｎ（ｖｎ）＞を求める。すべてのカラム値Ｖｉ（１≦ｉ≦ｎ）がＣＶＴｉに登録されていれば、上述した拡張可能配列の要素のアドレス計算手順にしたがって、経歴値とオフセットの組＜ｈ，ｏ＞を求める。この＜ｈ，ｏ＞をキー値としてＲＤＴを検索し、存在していれば、ｒがＴに存在する。対応するＣＶＴに登録されていないカラム値が存在するときには、ｒはＴに存在しない。

つづいて、ｒのカラム値の内、｛Ｖｉ１，・・・，Ｖｉｋ｝の値が検索条件として指定された場合、該当レコードの検索について述べる。ｋ個のＣＶＴを検索して添字ＣＶＴｉ１（ｖｉ１），ＣＶＴｉ２（ｖｉ２），・・・，ＣＶＴｉｋ（ｖｉｋ）を求める。指定されたカラム値が登録されていないＣＶＴが存在すれば、当該レコードは存在しない。すべて登録されているときには、求めた添字に対応するサブ配列の拡張経歴値を得て、最小と最大の拡張経歴値ｈｍｉｎおよびｈｍａｘを選び出す。さらに、ｈｍｉｎ≦ｈ≦ｈｍａｘなる拡張経歴値ｈを持つサブ配列全てにおいて各指定添字を持つレコードを検索する。同一経歴値を持つキー値集合はＲＤＴのシーケンスセット上でオフセットｏの昇順に連続的に配置されている。ｈを経歴値として持つＲＤＴのキー値＜ｈ，ｏ＞を逐次シーケンスセット上でアクセスし、下記〔１．３経歴値、オフセットからカラム値への逆変換〕に述べる手順にしたがって、＜ｈ，ｏ＞から、添字のｎ項組Ｉ＝＜ｉ１，ｉ２，・・・，ｉｎ＞を求める。検索条件で指定されたｋ個の次元について、先に求めたｋ個の添字ＣＶＴｉ１（ｖｉ１），ＣＶＴｉ２（ｖｉ２），・・・，ＣＶＴｉｋ（ｖｉｋ）にすべて、一致しているならば、＜ｈ，ｏ＞を検索結果に含める。

図３に、後者、すなわち、複数のカラム値が指定されない場合の検索アルゴリズムの擬似コードリストを示す。

（２）レコードｒ＝＜ｖ１，ｖ２，・・・，ｖｎ＞の挿入
ｎ個のＣＶＴを検索して添字のｎ項組Ｉ＝＜ＣＶＴ１（ｖ１），ＣＶＴ２（ｖ２），・・・，ＣＶＴｎ（ｖｎ）＞を求める。すべてのカラム値ｖｉ（１≦ｉ≦ｎ）がＣＶＴｉに登録されていれば、（１）と同様にして＜ｈ，ｏ＞をキー値としてＲＤＴを検索する。存在していなければ、＜ｈ，ｏ＞をキー値としてＲＤＴに登録する。ｒのｎ個のカラム値の内、対応するＣＶＴに登録されていないカラム値が存在する場合、それらの拡張可能配列での対応次元を次元の昇順にｄ１，ｄ２，・・・，ｄｋ（１≦ｋ≦ｎ）とする。この次元順で各次元ｄｉ（１≦ｉ≦ｋ）について、順次、以下の（ａ）（ｂ）を行う。

（ａ）次元ｄｉの空きスロットリストＳＬｉが空でなければ、ＳＬｉの先頭が指示するＨＴｉの空きスロットを得て、そのレコード数のフィールドを０に初期化する。ＳＬｉが空の時には論理拡張可能配列の次元ｄｉを１つ拡張して、拡張したＨＴｉの空きスロットに、経歴値カウンタの値を１増加させて、拡張経歴値として書き込むと同時に係数ベクトルを計算して書き込む。

（ｂ）ＣＶＴｉに（Ｖｄｉ、（ａ）で確保した空きスロット番号）を挿入するとともに、（ａ）で確保した空きスロットのレコード数のフィールドを１インクリメントする。

なお、図４は、以上のレコード挿入のアルゴリズムを示す擬似コードリストである。

（３）レコードｒ＝＜ｖ１，ｖ２，・・・，ｖｎ＞の削除
（１）に従って、ｒを検索する。存在するならば、ｒに対応するのキー値を削除してから、ＣＶＴおよびＨＴのメンテナンスを行う。

なお、図５は、以上のレコード削除のアルゴリズムを示す擬似コードリストである。

１．３経歴値、オフセットからカラム値への逆変換
関係テーブルＴのレコードはＨＯＲＴデータ構造においては、論理拡張可能配列の経歴値とオフセットの組で表され、キー値としてＲＤＴに格納される。そのため、検索結果をユーザに返す際には該当するレコードのキー値の集合が返されることになる。検索要求を発行したユーザに対して検索結果を返すには、キー値からカラム値の組としてのレコードに逆変換する必要がある。ここではこの逆変換の方法を示す。

まずＨＯＲＴから得られた経歴値とオフセットの組を経歴・オフセット法の逆変換により論理多次元配列の各次元の添字に変換する。この変換を高速に行うために、経歴値を添字とする一次元配列ＳＨを用意する。レコード挿入時には経歴値とオフセットの組＜ｈ，ｏ＞に対して、ＳＨ［ｈ］にｈが記されるＨＯＲＴテーブルの次元ｄとその添字の値ｋを記入する。変換後の添字の値の組の内、次元ｄの添字の値はｋである。他の次元の添字の値を次元順に＜ｉ１，ｉ２，・・・，ｉｎ−１＞とする。これらの添字の値はＨＴｄ［ｋ］に記されている係数ベクトルを使って、オフセットｏから一意的に求めることができる。上述した拡張可能配列のアドレスを求める一次関数の係数が係数ベクトルに記されているので、係数ベクトルの第１項の係数でオフセットｏを割算した商をｉ１として、余りを順次、第２項から、第ｎ−２項までの係数で割り、商と余りを求めることを繰り返す。ｉ１，ｉ２，・・・，ｉｎ−２はこの割算の過程で得られる商であり、ｉｎ−１は最後の割算の余りである。

続いて次元ごとにその添字値をカラム値に変換する。ＣＶＴはＢ＋木であるためカラム値から配列添字値の変換はできるが、配列添字値からカラム値への変換はできない。そこで、各次元のＨＯＲＴテーブルの各スロットにそれぞれ対応するカラム値を格納する領域を増設し、新たなレコードを挿入する時にその領域にカラム値を格納することにする。ただし、カラム値の型が文字列型やＬＯＮＧ型のサイズを超える場合、カラム値を格納する領域にはカラム値そのものではなくカラム値が格納されている記憶領域へのポインタを格納する。これによりカラム値と配列添字値の双方向変換が可能になり、次元ごとに得た配列添字値からカラム値を得、それらを次元順に並べてレコードとして得ることができる。

２．経歴値、オフセット空間のオーバーフローとその対策
ＲＤＴに格納するキー値である＜経歴値，オフセット＞の型は最大サイズの単純型であるｌｏｎｇ型とすれば、実装上、効率がよい。例えば、ｌｏｎｇ型が６４ｂｉｔの計算機上では上位２４ｂｉｔに拡張経歴値、下位４０ｂｉｔにオフセットというように分割する。この場合、特にオフセットの空間の制限が厳しく、ＨＯＲＴが表現する関係テーブルのカラム数やそのカラム値の種類が多くなった時、経歴値、オフセットのどちらかがオーバーフローしてしまつ危険性がある。そこでここでは、キー値空間を拡張するために変数を２つ持つことの出来るＢ＋木を作成し、１つ目のキー値に拡張経歴値（ｉｎｔ型：３２ｂｉｔ）、２つ目のキー値にはオフセット（ｌｏｎｇ型：６４ｂｉｔ）をＲＤＴのＢ＋木に格納することとする。ただし、上記の方法を用いたとしてもオーバーフローの発生を遅らせる効果しかなく、根本的な解決にはならない。以下では、このオーバーフローに対する対策を説明する。なお、２．３節では「チャンク化経歴・オフセット法」として、異なる発想による、経歴値・オフセット空間のオーバーフローの遅延対策を提案している。

２．１一意キーテーブル
経歴値−オフセット空間のオーバーフローの原因の一つとして、一意キーの存在がある。一意キーとは、例えば「学生番号」、「運転免許証の登録番号」、「社員番号」のように、カラム値の重複が起こり得ないカラムのことである。このようなカラムが、ＨＯＲＴで表現しようとする関係テーブルに存在していた場合、レコードが１つ挿入されるたびに必ず論理拡張可能配列の拡張が起こるため、経歴値やサブ配列のサイズが大きくなり、経歴値−オフセット空間のオーバーフローが早まる。

例として５次元のＨＯＲＴにおいて、一意キーが１つ存在する場合と、一意キーが存在しない場合それぞれの挿入可能レコード数を、カラム値の重複度（レコード数／カラム値の種類）の関係とともに図６に示す。ここで、あるカラムの“カラム値の重複度”とはあるカラム値を持つレコード数の平均であり、テーブルのレコード総数をカラム値の種類の数で割った値である。図６では全てのカラムについて、カラム値の重複度は同一である。

図６からわかるように、関係テーブルに一意キーが存在する場合、それを表現するＨＯＲＴに挿入することができるレコード数が極端に減少している。そこで、経歴値−オフセット空間のオーバーフローを加速させる一意キーを、他のカラムとは別に管理し、一意キー以外のカラムのみによって論理拡張可能配列を構成することによって、一意キーの存在による経歴値−オフセット空間のオーバーフローを遅らせることができる。

一意キー「学生番号」をもつ関係テーブル「学生名簿」を想定し、この例を用いたＨＯＲＴの構成について説明する。図７にその構成を示す。

一意キーではないカラム「氏名」、「性別」によって２次元の論理拡張可能配列を持つＨＯＲＴデータ構造を構成し、そのＲＤＴには、ＨＯＲＴの２次元論理拡張可能配列上でのレコードの位置を示す、経歴値とオフセットの組を得る。

次に、一意キーである「学生番号」についてはこれまでのＨＯＲＴデータ構造とは別に、従来の手法で実現される関係テーブルとして一意キーテーブルを二次記憶上に構成する。その１レコードには一意キーのカラム値と、他のカラム値によってＨＯＲＴデータ構造から得られる経歴値とオフセットの組を格納する。さらにＲＤＴには、キー値として、経歴値とオフセットの組を、また、データ値として、一意キーのカラム値に対する一意キーテーブルのスロットの添字を挿入しておく。

上記のような構成にすることにより、一意キーの値が指定された場合には、一意キーテーブルの該当スロットに格納されている経歴値とオフセットの組から、経歴、オフセット法の逆変換により一意キーではない他のカラムの値を得ることができ、逆に一意キー以外のカラム値が指定された場合には、ＨＯＲＴデータ構造であるＲＤＴから経歴値とオフセットの組をキー値として、そのデータ値、つまり対象のレコードが格納されている一意キーテーブルのスロット番号を得ることができるので、対応する一意キーの値を得ることができる。

図８は、図６のグラフに一意キーを上記の方法で別に管理した場合を追加したグラフである。図８からわかるように、一意キーを別管理した場合のＨＯＲＴに挿入することができるレコード数が、格段に増大している。これは、一意キーを別に管理することによって、ＨＯＲＴが管理する論理拡張可能配列の次元が５次元から４次元に減り、さらに一意キーであるカラムが論理拡張可能配列内に存在しない状態になるため、ＨＯＲＴテーブルや論理サブ配列のサイズを抑えられているためである。

一意キーに対してはＨＯＲＴテーブルが不要になる。ＨＯＲＴテーブルは拡張経歴値や係数ベクトル、レコード数のカウンタ、などを持っているため一意キーブルよりも大きな領域を要するテーブルであった。そのため、上記の一意キーの別管理方式を用いることで、空間的コストを減少させることができる。以下では、一意キーを別管理した場合のＨＯＲＴにおけるレコードの挿入、削除、検索の各アルゴリズムについて説明する。

２．１．１レコードの挿入
一意キーテーブルを用いたＨＯＲＴにレコードを挿入する場合、まず、一意キーに対応するＣＶＴに一意キーの値がすでに挿入されているかどうかを調べる。もし、すでにその値がＣＶＴ内に挿入されていた場合、一意キーの重複が発生してしまうため例外処理としてレコードの挿入を中止する。存在しなかった場合、一意キーテーブルの空きスロットの添字（空きスロットが無ければ最後尾に追加する）を得、挿入するレコードの一意キーの値をキー値、得た空きスロットの添字をデータ値としてＣＶＴに格納する。

次に、一意キー以外の各カラム値を従来と同じように論理拡張可能配列に挿入する。これにはまず、カラム値の集合に対応する経歴値とオフセットの組を得る。そして、経歴値とオフセットの組をキー値、一意キーテーブルの空きスロットの添字をデータ値としてＲＤＴに挿入し、一意キーテーブルの空きスロットには、一意キーの値と経歴値とオフセットの組を格納する。

なお、図９は、以上の一意キーを持つレコードの挿入のアルゴリズムを示す擬似コードリストである。

２．１．２レコードの削除
一意キーテーブルを用いたＨＯＲＴからレコードを削除する場合は、まず、削除したいレコードについて、一意キーカラムの値が格納されている一意キーテーブルのスロットを調べ、該当するスロットが無い場合は、エラーを返す。存在した場合には、一意キーテーブルのスロットから得られた経歴値とオフセットの組が、削除対象のレコードに対する経歴値とオフセットの組と等しいかを調べる。一致した場合には、一意キーテーブルの空きスロットを管理するリストに削除対象のレコードの情報が格納されているスロットの添字を追加し、一意キーカラム値に対応するＣＶＴから、削除したいレコードの一意キーカラム値を削除する。

次に、ＲＤＴから削除したいレコードの経歴値とオフセットの組を削除する。このとき、同じ経歴値とオフセットの組を持つレコードが複数存在した場合には、先ほど削除した一意キーテーブルのスロットの添字をデータ値として持つエントリのみを削除する。

さらに、従来のＨＯＲＴからのレコードの削除と同様に、各ＣＶＴおよびＨＯＲＴテーブルについて、削除に必要なメンテナンス行う。

なお、図１０は、以上の一意キーを持つレコードの削除のアルゴリズムを示す擬似コードリストである。

２．１．３レコードの検索
検索において、一意キーの値が指定された場合には、まず一意キーに対応するＣＶＴを検索し、一意キーテーブルの添字を得る。一意キーテーブルには、一意キー以外のカラムで構成された論理拡張可能配列の経歴値とオフセットの組が格納されているので、従来どおり経歴値・オフセットの逆変換により、他の指定カラムが指定された値であるかどうかを調べればよい。このように、一意キーが指定された場合には、ＲＤＴの検索を行う必要がないため、高速に検索を行うことができる。

また、一意キーが検索条件として指定されなかった場合には、従来どおり、論理拡張可能配列内でレコードが存在し得る範囲の経歴値とオフセットの組を求めて、ＲＤＴの検索を行えばよい。さらに、ＲＤＴには経歴値とオフセットの組とともに一意キーテーブルの添字が格納されているので、この添字を用いて一意キーテーブルにアクセスし、一意キーの値を得ることができる。

なお、図１１は、以上の一意キーを持つレコードの検索のアルゴリズムを示す擬似コードリストである。

２．１．４一意キーが複数存在する場合のＨＯＲＴの構成
関係テーブルに一意キー値を持つカラムが複数存在する場合は、一意キーテーブルに全ての一意キーカラムの値を格納し、各一意キーのカラム値を管理するＣＶＴそれぞれにその一意キーテーブルのスロットの添字を格納しておく。

図１２に、図７の例に、一意キーとしてメールアドレスが追加されたときの一意キーテーブルの様子を示す。一意キーテーブルには、各レコードの一意キーカラムの値である、学生番号とメールアドレス、ＲＤＴに格納されている経歴値とオフセットの組を格納する。そして、各一意キーに対応するＣＶＴには、一意キーのカラム値と一意キーテーブルの添字の組を格納する。一意キーテーブルを共有することで、さらに空間的コストの減少が可能である。また、レコードの挿入や削除、検索のアルゴリズムは、一意キーテーブルに複数の一意キーのカラム値が格納されていること以外、一意キーが１つの場合とほぼ同じである。

２．２関係テーブルの垂直分割管理
ＨＯＲＴが扱っている関係テーブルに新たなレコードが挿入され、その際に論理拡張可能配列の拡張が行われて経歴値−オフセット空間のオーバーフローがおきる場合、現在扱っている関係テーブルを２つのカラム集合の組に分割する。そして、分割したそれぞれの関係テーブルについて、従来どおり論理拡張可能配列を構成し、経歴値とオフセットの組をそれぞれのＲＤＴに格納する。この時、２つに分割された関係テーブル間の関係を保つために、上述した一意キーテーブルを利用する。一意キーテーブルには、１個もしくは複数個の一意キーカラムの値と、経歴値とオフセットの組を格納していた。この一意キーテーブルには、元の関係テーブルが持つ１個もしくは複数個の一意キーの値と、分割された関係テーブル全てがそれぞれに持つＲＤＴに格納されている経歴値とオフセットの組を格納する。これにより、一意キーの値が１つわかれば、各分割テーブルに対応するＲＤＴの経歴値とオフセットの組と、すべての一意キーの値が得られる。また、一つのＲＤＴに格納されている経歴値とオフセットの組がわかれば、他のＲＤＴに格納されている経歴値とオフセットの組とすべての一意キーの値を知ることができる。

図１３に、関係テーブルの垂直分割とそのＨＯＲＴ表現を使った実装例を示す。

元の関係テーブルに一意キーが存在せず、一意キーテーブルが存在しない場合には、経歴値−オフセット空間のオーバーフローが起こった時点で、関係テーブルの各レコードに一意的に付した番号をカラム値とする一意キーカラムを増設する。この一意キーカラムにより、一意キーテーブルを作成し、分割された各論理拡張可能配列のＲＤＴに格納されている経歴値とオフセットの組を格納する。このように、対象とする関係テーブルを２つのカラム集合の組に分割する方式を垂直分割と呼ぶこととする。

垂直分割では分割する時に、ＲＤＴ、ＣＶＴ、ＨＯＲＴテーブル及び一意キーテーブル、これら全てを再構成するため、分割時に大きな時間的コストがかかる。さらに、ＲＤＴの分割により、分割前と同じ大きさのＢ＋木が２つ出来るので空間的なコストもかかる。

垂直分割時には、ただ単に２つに分割しただけでは２つの分割テーブルにおける次の分割タイミングに大きな差ができてしまう可能性がある。この差を出来るだけ等しくすることにより、時間的コストの大きい分割タイミングを遅らせることが出来る。２つの分割テーブルにおける次の分割タイミングを出来るだけ等しくするためには、現在の各カラムのカラム値の種類数を調べ、その数がほぼ平等になるように振り分ける。

図１４は、以上の関係テーブルの垂直分割のアルゴリズムを示す擬似コードリストである。

また、図１５に、ＨＯＲＴのカラム数と各カラムが持つことのできるカラム値の数の関係を示す（各カラムがもつカラム値の数は、全て等しいものとする）。ＨＯＲＴが扱う関係テーブルを垂直に２つに分割すると、前述の通り、分割数分だけのＲＤＴの作成を必要とするため、空間的コストがかかる上、テーブルの分割を行う際に、論理拡張可能配列の再編成と、ＲＤＴ及び一意キーテーブルの再構築が必要であるので、分割時に大きな時間的コストがかかってしまう。しかし、図１５からわかるように、各カラムが持つことのできるカラム値の数は２倍ではなく、２乗のオーダーで増加することになるため、経歴値−オフセット空間のオーバーフローを大きく遅らせることが出来る。

また、さらにレコードの追加により、分割した関係テーブルの経歴値−オフセット空間のオーバーフローが起きた場合には、オーバーフローが起きた関係テーブルについて同様に分割を行うことにより、ほぼ制限なくレコードを挿入することが可能になる。

２．２．１垂直分割後のレコードの挿入
垂直分割後のＨＯＲＴへのレコードの挿入は、まず、レコード中の一意キーではないカラムの値を、それぞれの分割テーブルごとに分割する。分割された各カラム値集合をレコードとして対応するＨＯＲＴに挿入する。各ＲＤＴにキー値として挿入した経歴値とオフセットの組を一意キーテーブルに格納する。続いて、一意キーの値をキー値、一意キーテーブルの添字をデータ値として、対応するＣＶＴに挿入し、さらに一意キーテーブルに挿入する。また、各ＲＤＴに経歴値とオフセットの組を挿入する際には、一意キーテーブルのスロットの添字をデータ値として一緒に格納しておく。挿入時に経歴一オフセット空間のオーバーフローが起こった場合にはオーバーフローを起こした分割テーブルをさらに垂直に分割する。

なお、図１６は、以上の垂直分割後のレコードの挿入のアルゴリズムを示す擬似コードリストである。

２．２．２垂直分割後のレコードの削除
分割後のＨＯＲＴからのレコードの削除は、レコードに一意キーが存在する場合、まず、一意キーに対応するＣＶＴを検索し、削除したいレコードの一意キーカラム値が格納されている一意キーテーブルの添字を得る。そして、その一意キーテーブルのスロットに格納されている、各論理拡張可能配列の経歴値とオフセットの組から各カラム値を求め、削除したいレコードであるかどうかを確認する。その上で、一意キーテーブルのスロットおよび各論理拡張可能配列からレコードの削除を行う。

また、レコードに一意キーが存在しない場合は、まず、分割した関係テーブルのうち、１つの関係テーブルについて削除したいレコードに対応する経歴値とオフセットの組を求める。次に、その経歴値とオフセットの組を用いてＲＤＴを検索し、一意キーテーブルの添字を求める。そして、その一意キーテーブルのスロットに格納されている他の論理拡張可能配列の経歴値とオフセットの組から各カラム値を求め、削除したいレコードであるかどうかを確認する。その上で、一意キーテーブルのスロット、各論理拡張可能配列からレコードの削除を行う。

なお、図１７は、以上の垂直分割後のレコードの削除のアルゴリズムを示す擬似コードリストである。

２．２．３垂直分割後のレコードの検索
分割後のレコードの検索は、一意キーカラムの値が指定された場合、まず、その値に対応するＣＶＴを検索し、一意キーテーブルの添字を得る。一意キーテーブルには各論理拡張可能配列の経歴値とオフセットの組が格納されているので、それらを基に各カラムの値が指定された値と一致するかどうかを調べればよい。

また、一意キーの値が指定されなかった場合には、分割された関係テーブルのうち、指定されたカラムが属している分割テーブル１つについて、従来どおり論理拡張可能配列内でレコードが存在し得る範囲の経歴値とオフセットの組を求めて、ＲＤＴの検索を行う。ＲＤＴには、経歴値とオフセットの組とともに、一意キーテーブルの添字が格納されているので、この添字を用いて一意キーテーブルにアクセスし、一意キーの値と他の論理拡張可能配列に格納されている経歴値とオフセットの組を得て、それらを基に各カラムの値が指定された値と一致するかどうかを調べればよい。

このように、関係テーブルの垂直分割を行った場合の検索では、一意キーテーブルに対応するＣＶＴ、もしくは１つのＲＤＴのみの検索で全てのカラム値を求めることができるため、時間的コストの増大を抑えることができる。

なお、図１８は、以上の垂直分割後のレコードの検索のアルゴリズムを示す擬似コードリストである。

２．３チャンク化経歴・オフセット法
２．３．１経歴・オフセット空間の問題
上述した経歴・オフセット法では、経歴値が若い部分配列ではオフセット空間のほとんどが使われない。例えば、経歴値が０や１の部分配列のサイズは１である。例として経歴値を３２ｂｉｔ、部分配列内での先頭からのオフセットを６４ｂｉｔとする。図１９は、ｎ次元の拡張可能配列を、なるべく各次元のサイズが同じになるように拡張していったとき、経歴・オフセット空間がオーバーフローする直前の状態において、有効なアドレスの割合すなわち（拡張可能配列サイズ／２^９６）を示したものである。

図１９によれば、最もアドレス空間を有効に利用している３次元のときでもアドレス空間の３（％）程度しか使用できないことがわかる。

ここで、図２０に示すように、当該拡張可能配列の次元数と同じ次元数で各次元サイズが等しい部分多次元配列をチャンクとして、このチャンクの集合として当該拡張可能配列を管理する。すなわち、これまで、拡張単位は配列要素の集合からなるサブ配列であったが、ここではチャンクの集合からなるチャンクサブ配列単位の拡張とする。拡張可能配列の要素の位置はそれが属するチャンクの番号（チャンク番号）とチャンク内オフセットの対で表す。チャンク番号は、拡張の順に０，１，２，・・・の番号が昇順で付与される。なお、拡張可能配列要素位置の上記指定法をチャンク化経歴・オフセット法と呼ぶ。

チャンク番号の決定にはこれまでの拡張可能配列の要素アドレス決定の手法を用いることとする。すなわち、ＨＯＲＴテーブルは経歴・オフセット法と同じように、チャンク番号を３２ｂｉｔ、チャンク内オフセットを６４ｂｉｔとしたとき、チャンクのサイズは２６４を超えない最大のサイズにすることができる。そのため、有効なアドレスの割合が格段に増加する。

図２１は、チャンク単位で拡張を行うｎ次元の拡張可能配列を、なるべく各次元のサイズが同じになるように拡張していったとき、経歴・オフセット空間がオーバーフローする直前の状態において、有効なアドレスの割合である（拡張可能配列サイズ／２９６）を示したものである。

図２１によれば、チャンク化を行うことで９６ｂｉｔのアドレス空間をより有効に利用可能であることがわかる。アドレス空間をより有効に利用することで、前述の経歴・オフセット法を用いたときよりも、１カラムあたりのカラム値の種類を増やすことができる。

図２２に、従来の経歴・オフセット法を用いた場合とチャンク化経歴・オフセット法を用いた場合の１カラムあたりのカラム値の種類を示す。

２．３．２チャンク化ＨＯＲＴの構造
チャンク化したＨＯＲＴでは、図２０に示すように経歴値テーブル等、前述のＨＯＲＴテーブル（１．１節ＨＯＲＴの基本データ構造参照）に相当するデータ構造は２段構造となり、これをチャンク化ＨＯＲＴテーブルという。チャンク化ＨＯＲＴテーブルの上段（上位）にはチャンクサブ配列の情報を、下段（下位）にはカラム値の情報を格納する。チャンクサブ配列の情報として、チャンクサブ配列の経歴値、チャンクサブ配列内の先頭チャンク番号、チャンクサブ配列の係数ベクトルを格納する。また、カラム値の情報として、カラム値またはカラム値が格納されている記憶領域へのポインタ、ならびにそのカラム値を持つレコード数のカウンタを保持する。

なお、チャンクの各次元サイズは同一で固定であるので、唯一保持すればよい。

ＣＶＴに格納するキー値は前述のＣＶＴと同様、その次元のカラム値またはカラム値が格納されている記憶領域へのポインタであり、データ値は、チャンク化ＨＯＲＴテーブルの上段の添字（例えば３２ｂｉｔ）とチャンク内での添字（例えば３２ｂｉｔ）の２つの値の連接（例えば６４ｂｉｔ）である。また、チャンク番号を、（そのチャンクが含まれるチャンクサブ配列が属している次元、その添字）の組に対応付けるための一次元配列が必要になるが、これは前述のＨＯＲＴの経歴値−次元・添字変換テーブル（１．３節経歴値、オフセットからカラム値への逆変換参照）よりも小さくなる。

ＲＤＴには関係テーブルのレコードに対応する論理拡張可能配列の有効要素が属するチャンクのチャンク番号と配列要素のチャンク内オフセットの対がキー値として格納される。

２．３．３関係テーブル操作に対するチャンク化ＨＯＲＴ基本データ構造の操作
（１）レコードｒ＝＜ｖ１，ｖ２，・・・，ｖｎ＞の検索
ｎ個のＣＶＴを検索してデータ値のｎ項組＜ＣＶＴ１（ｖ１），ＣＶＴ２（ｖ２），・・・，ＣＶＴｎ（ｖｎ）＞を求める。すべてのカラム値ｖｉ（１≦ｉ≦ｎ）がＣＶＴｉに登録されているとする。レコードｒを含む拡張可能チャンク配列のチャンクの添字の組は各ＣＶＴｉ（ｖｉ）の上位３２ビットに格納されており、各データ値を右に３２ビットシフトすることにより求まる。拡張可能チャンク配列のチャンク番号をチャンク番号の計算手順にしたがって求める。なお、〔前提となる技術〕では、図４５を参照しながら、チャンク化しない通常の拡張可能配列要素の添字の組に対して、要素のアドレス計算手順が示されている。各チャンク化ＨＯＲＴテーブルＨＴｉ（１≦ｉ≦ｎ）上段のチャンクサブ配列の情報を使用して、まったく同様の手順により、レコードｒが属するチャンクの番号ｃを求めることができる。すなわち、各次元の拡張経歴値のうち、最大経歴値に対応する次元のチャンクサブ配列の先頭チャンク番号を求め、チャンクサブ配列の係数ベクトルによりチャンク番号ｃが求まる。

チャンクｃにおける配列要素の添字は各ＣＶＴ（ｖｉ）の下位３２ビットに格納されており、これらの添字の組に対して配列要素のオフセットｏを計算する。＜ｃ，ｏ＞をキー値としてＲＤＴを検索し、存在しておれば、ｒが関係テーブルにに存在し、存在していなければ、ｒは関係テーブルに存在しない。

対応するＣＶＴに登録されていないカラム値が存在するときには、ｒは関係テーブルに存在しない。

（２）レコードｒ＝＜ｖ１，ｖ２，・・・，ｖｎ＞の挿入
ｎ個のＣＶＴを検索してデータ値のｎ項組＜ＣＶＴ１（ｖ１），ＣＶＴ２（ｖ２），・・・，ＣＶＴｎ（ｖｎ）＞を求める。すべてのカラム値ｖｉ（１≦ｉ≦ｎ）がＣＶＴｉに登録されていれば、（１）と同様にして＜ｃ，ｏ＞を求め、キー値としてＲＤＴを検索する。存在していなければ、＜ｃ，ｏ＞をキー値としてＲＤＴに登録する。ｒのｎ個のカラム値の内、対応するＣＶＴに登録されていないカラム値が存在する場合、それらの拡張可能配列での対応次元を次元の昇順にｄ１，ｄ２，…，ｄｋ（１≦ｋ≦ｎ）とする。この次元順で各次元ｄｉ（１≦ｉ≦ｋ）について、順次、以下を行う。なお、論理拡張可能配列の現在の次元ｄｉのサイズをｓｄｉ、チャンクの各次元サイズをＳとする。

ここで、ＨＴｄｉの下段の空きスロットリストが空でなければ、次の空きスロットの（対応する上段の添字，チャンク内添字）をＣＶＴｄｉに登録し、下段のカラム値の情報のうちレコード数のフィールドを０に初期化する。以下、下段の空きスロットリストが空であるとする。ｓｄｉがチャンク境界に達している時、次元ｄｉの方向に１チャンク分論理拡張可能配列を拡張する。この時，ＨＴｄｉの上段が１個、下段がＳ個一度に拡張され、ＣＶＴｄｉ（ｖｄｉ）には対（拡張したチャンクの添字、０）が格納される。拡張したＨＴｄｉのスロットの上段には、チャンクサブ配列の拡張経歴値など、チャンクサブ配列の情報が格納される。また、下段にはカラム値の情報が格納される。ｓｄｉがチャンク境界に達していない時には、ＣＶＴｄｉ（ｖｄｉ）にはデータ値（ｓｄｉ／Ｓ、ｓｄｉ％Ｓ）（／，％はそれぞれ、商と剰余を表す）を格納し、ＨＴｄｉの当該下段にはカラム値ｖｄｉの情報を格納する。

全てのｄｉについて上記が終了すれば、（１）と同様にして＜ｃ，ｏ＞を求め、キー値としてＲＤＴに登録する。

（３）レコードｒ＝＜ｖ１，ｖ２，・・・，ｖｎ＞の削除
（１）に従って、ｒを検索する。存在するならば、ｒに対応するキー値をＲＤＴより削除してから、ＣＶＴおよびＨＴのメンテナンスを行う。

２．３．４キー値−カラム値逆変換
レコードの検索結果としてＲＤＴの該当するレコードのキー値、すなわち、チャンク番号とチャンク内オフセットの組の集合が返される。検索要求を発行したユーザに対して検索結果を返すには、キー値からカラム値の組としてのレコードに逆変換する必要があり、以下にその方法を示す。

まずチャンク番号から拡張可能チャンク配列Ａのチャンク化ＨＯＲＴテーブルの次元とチャンクの添字に変換する。この変換を高速に行うために、２．３．２節で述べたチャンク番号を添字として、（そのチャンクが含まれるチャンクサブ配列が属している次元、その添字）の組に対応付けるための一次元配列ＳＨを用意する。レコード挿入時にはチャンク番号とオフセットの組＜ｃ，ｏ＞に対して、ＳＨ［ｃ］にチャンクｃが含まれるチャンクサブ配列の先頭チャンク番号が記されるＨＯＲＴテーブルの次元ｄとＡにおけるチャンクｃの添字の値ｋを記入する。

チャンクｃのＡにおける添字の値の組の内、次元ｄの添字の値はｋである。他の次元の添字の値はＨＴｄ［ｋ］に記されているチャンクサブ配列の係数ベクトルを使って、１．３節と同様にしてオフセット（ｃ−ＨＴｄ［ｋ］）から割算の繰り返しにより一意的に求めることができる。このようにして求めたチャンクｃのＡにおける添字の値の組を＜ｉ１，ｉ２，・・・，ｉｎ＞とする。

つづいてチャンク内オフセットｏから、チャンクｃにおける当該レコードに対応する要素の添字の組＜ｊ１，ｊ２，・・・，ｊｎ＞を求める。どのチャンクも同じ一辺サイズの超立方体であることから、このための係数ベクトルはＡについて１組グローバルに所持している。最後に、＜ｉ１，ｉ２，・・・，ｉｎ＞と＜ｊ１，ｊ２，・・・，ｊｎ＞より当該レコードの各カラム値を求める。すなわち、各ｉｋ（ｋ＝１，・・・，ｎ）よりＨＴｋの上段のスロットを決定し、それに対応する下段のｊｋ番目のスロットを決定する。そのスロットの中にはｋ番目のカラム値が格納されている。

２．３．５アドレス空間のオーバフローに対する対策
上記で示したとおり、ＨＯＲＴをチャンク化することでチャンク化拡張可能配列内での要素の位置を示すアドレス空間を有効に利用することができる。これによって、アドレス空間のオーバーフローを大幅に遅らせることができる。しかし、図２２によれば、次元数が大きい場合、カラム値の種類が少なくなり、アドレス空間のオーバーフローは回避できない。

これに対しては、「一意キーテーブル」や「テーブルの垂直分割の手法」の採用により、前述の経歴・オフセット法と同様、新たなカラム値の追加に対しても無制限に対応することが可能である。また、アドレス空間のオーバーフローそのものを大幅に遅らせることができるために、従来の経歴・オフセット法より、テーブル分割数は少ない。

図２３，図２４に、チャンク化ＨＯＲＴデータ構造における一意キーとテーブルの垂直分割の方式をそれぞれ示す。

一意キーについて、図２３のような構成にすることにより、一意キーの値が指定された場合には、一意キーテーブルの該当スロットに格納されているチャンク番号とオフセットの組から、２．３．４節で述べた逆変換により一意キーではない他のカラムの値を得ることができ、逆に一意キー以外のカラム値が指定された場合には、ＲＤＴからチャンク番号とオフセットの組をキー値として、そのデータ値、つまり対象のレコードが格納されている一意キーテーブルのスロット番号を得ることができるので、該当スロットから同様に対象レコードの全てのカラム値を得ることができる。

また、関係テーブルの垂直分割を図２４の構成とすることにより、一意キーテーブルに格納されているチャンク番号とオフセットの組が複数存在するが、上記と同様の手順で対象レコードの全てのカラム値を得ることができる。このとき、一意キー以外のカラム値が指定された場合には、前述の経歴・オフセット法の場合と同様、当該ＲＤＴのみを検索するのみで、他のＲＤＴを検索する必要はない。

２．３．６チャンク化のメリットとデメリット
２．３．５はチャンク化の大きなメリットである。さらに、ファイルサイズやメモリの使用量が減少することもメリットである。ＣＶＴのデータ値としてチャンク配列の添字とチャンク内添字の二つを必要とするため、ＣＶＴのサイズは大きくなるが、経歴値等のチャンクサブ配列の情報のサイズは配列要素単位ではなく、チャンク単位に確保されるために（１／チャンクの一辺サイズ）と大幅に小さくなる。配列の次元数をｎとすれば係数テーブルのスロットサイズはｎ−２を必要とするために、特に、係数テーブルは前述の経歴・オフセット法に比べて有利である。また、前述の経歴値−次元・添字変換テーブルに相当するチャンク番号−次元・添字変換テーブルのサイズも同様に減少できる。さらに分割数が少ないため、一意キーテーブルのサイズも減少できる（図１３参照）。以上より、チャンク化ＨＯＲＴデータ構造全体のサイズは前述の経歴・オフセット法の場合に比べて小さくなる。

検索時間においても向上が期待できる。前述の経歴・オフセット法では、カラム値指定のレコード検索において、検索カラム値に依存して検索対象となる部分配列の数が変化し、検索時間が一定ではないという検索カラム値依存性が存在する。しかし、チャンク化を行うことで検索対象となるチャンク数は次元ごとに一定で、部分配列の数の平均よりも少なくなり、検索時間も一定で平均的に短くなり、検索カラム値依存性が解消される。

最後に、チャンク化経歴・オフセット法のデメリットして、チャンクの次元数が固定であるために、スキーマ進化に対応できないことが挙げられる。前述の経歴・オフセット法では次元の追加（関係テーブルのカラムの増設）に対しては、拡張可能配列の特性を生かして、ＨＯＲＴデータ構造の再編成なしに対応することができる。すなわち、増設カラムに対応して、論理拡張可能配列の次元を１増やすことによって対処できる。これについては、増やした次元のＨＯＲＴテーブルの増設のみで対処可能であるが、チャンク化経歴・オフセット法ではデータ実体であるＲＤＴの再編をはじめチャンク化ＨＯＲＴデータ構造全体の再編成を必要とし、処理コストが大きくなる。

３．ＨＯＲＴの拡張と応用
ＨＯＲＴは関係テーブルという極めて単純で抽象度の高いデータ表現に対する実装方式である。データベース応用のみならず、一般に関係テーブルで表現できるか、関係テーブルにマッピングできるようなアプリケーションデータは広範に存在する。したがって、ＨＯＲＴはこれらのアプリケーションデータの極めて時間・空間効率の良い実装方式として、広く使用できる。ここでは、関係テーブルにマッピングするための付加的なデータ構造を必要とするＨＯＲＴの拡張と応用として、オブジェクト指向データベースにおいて使用される複合オブジェクトの実装および近年広く使用されているＸＭＬ文書の実装について提案する。さらにＨＯＲＴデータ構造の並列処理の方式について提案する。

３．１複合オブジェクトのＨＯＲＴデータ構造による実現
オブジェクト指向データベースにおける複合オブジェクトはスキーマ（データ定義）に従って表現される。複合オブジェクトはその属性として他のインスタンスオブジェクトへの参照をオブジェクトＩＤ（ｏｉｄ）として持つオブジェクトである。複合オブジェクトの集合はＨＯＲＴデータ構造を使って表現できる。

クラスＣの属性集合を｛ａ１，ａ２，…，ａｎ｝としたとき、カラムをａ１，ａ２，…，ａｎ、および、Ｃのレコード（インスタンス）を一意的に識別するための整数型のＩＤとする関係テーブルＴによりＣを表す。このＩＤは、レコードが挿入されたとき、システムによって与えられる。このとき、カラムａｉの名前はａｉの属性名となる。Ｃの属性ａｉのデータ型が整数型や文字列型などの単純型であるときには、カラムａｉのカラム値はＣの属性ａｉの属性値となる。ａｉが他のインスタンスオブジェクトを参照するオブジェクトＩＤ型の属性のときには、新たな関係テーブルＴｉが上記手順を再帰的に適用して構成される。この場合もカラム名はａｉの属性名となり、また、そのカラム値はＴｉをＨＯＲＴデータ構造で表現したときの当該レコードのオブジェクトＩＤとなる。このオブジェクトＩＤは当該レコードが属するＴｉを識別するためのテーブルＩＤとＴｉにおける当該レコードＩＤの対（テーブルＩＤ，レコードＩＤ）である。このようにレコードＩＤを定めることにより、被参照レコードのカラムａ１，ａ２，…，ａｎが更新されても、参照する側のオブジェクトＩＤを変更する必要はない。ａｉが単純型の値の集合または他のオブジェクトへの参照の集合型の時には、対応する集合型のカラムを下記に示すようにＨＯＲＴデータ構造に付加されるデータ構造として他のカラムとは別に管理する。

複合オブジェクトの実体は、上述のように、複数のクラスを上記の定義によりそれぞれ複数の関係テーブルとしたときに、個々の関係テーブルに対応する複数のＨＯＲＴで表現される。

図２５に複合オブジェクトの定義例を示す。図２５において、クラスｂｏｏｋの属性ａｕｔｈｏｒはクラスｃｈｏｓｈａのインスタンスへの参照の集合であり、クラスｃｈｏｓｈａの属性ａｆｆｉｌｉａｔｅはクラスｓｈｏｚｏｋｕのインスタンスへの参照である。

図２６に、図２５の定義例による、複合オブジェクトインスタンス例の関係テーブル表現を示す。テーブルｂｏｏｋのａｕｔｈｏｒカラムは共著者の場合にはテーブルｃｈｏｓｈａのレコードへの参照の集合であり、したがって、ｂｏｏｋは非正規型の関係テーブルとなり、このままでは、ＨＯＲＴデータ構造でｂｏｏｋを実装できない。

この問題を解決するために、集合型のカラムを他のカラムとは別に管理する方法を提案する。集合型以外のカラム集合はＨＯＲＴにより実装される。この方法によれば、テーブルｂｏｏｋは、図２７のように実装される。参照されるテーブルｃｈｏｓｈａのｏｉｄカラム値をキーとするとデータ値として、そのｏｉｄを参照しているテーブルｂｏｏｋ内の全てのレコードのｏｉｄの集合を返すＢ＋木を設ける。このＢ＋木により、どの著者がどの本を書いているかの情報が得られる。

各テーブルのレコードに付与されるｏｉｄはそのテーブルの一意キーであり、２．１節に示したＨＯＲＴにおける実装方式に従えば、一意キーテーブルが構成される。テーブルｂｏｏｋのレコードのｏｉｄはこの一意キーのテーブルのレコードを参照する。また、参照先の一意キーテーブルのレコードにはａｕｔｈｏｒカラムのｏｉｄ集合が保持される。すなわち、上述のｏｉｄの集合を返すＢ＋木と一意キーテーブルｏｉｄ集合は互いに逆参照の関係にある。一意キーに対するＣＶＴが存在しないのはキー値が当該一意キーテーブルのレコードの所在を表す整数値であるからＣＶＴによるキー−添字変換機構を必要としないからである。

経歴・オフセット空間の大きさの制限が厳しくない時には一意キーを別扱いとせずに、一意キーであるｏｉｄカラムも含めて、ＨＯＲＴデータ構造を構成することも可能である（図２８）。このときには、一意キーテーブルは存在しない。

３．２ＸＭＬ文書への応用
３．２．１ＤＴＤを持つＸＭＬ文書への応用
図２９は、ＤＴＤ（ＤｏｃｕｍｅｎｔＴｙｐｅＤｅｆｉｎｉｔｉｏｎ）付きのＸＭＬ文書例である。図３０は、図２９の関係テーブルによる表現である。

ＤＴＤを有するＸＭＬ文書について要素ｅの直下のタグまたはＰＣＤＡＴＡの順序集合をＴ＝｛ｅ１，ｅ２，…，ｅｎ｝として、カラムをｅ１，ｅ２，…，ｅｎおよびＴのレコード（インスタンス）を一意的に識別するためのＩＤとする関係テーブルでＴを表す。このＩＤはレコードが挿入されたとき、システムによって与えられる。ｅｉがタグ要素であり、その要素が唯一のＰＣＤＡＴＡからなるときには、ｅｉがＴのカラムとなり、そのカラム名はｅｉのタグ名となる。また、カラム値はそのＰＣＤＡＴＡとなる。ｅｉがｉ番目のＰＣＤＡＴＡのときには、ｅｉがＴのカラムとなり、そのカラム名はＰＣＤＡＴＡｉとなる。また、カラム値はそのＰＣＤＡＴＡとなる。ｅｉがタグ要素であり、その要素が複数の要素を含むときには、ｅｉに対して、新たな関係テーブルＴｉが上記手順を再帰的に適用して構成される。この場合、カラム名はｅｉのタグ名となり、そのカラム値はＴｉをＨＯＲＴデータ構造で表現したときの当該レコードのオブジェクトＩＤ（ｏｉｄ）となる。このオブジェクトＩＤは当該レコードが属するＴｉを識別するためのテーブルＩＤとＴｉにおける当該レコードＩＤの対（テーブルＩＤ，レコードＩＤ）であり、レコードＩＤのデータ型は浮動小数点数とする。図３０を参照されたい。

このようにレコードＩＤを定めることにより、被参照レコードのカラムａ１，ａ２，…，ａｎが更新されても、参照する側のオブジェクトＩＤを変更する必要はない。また、レコードＩＤを浮動小数点数としたのは、ＸＭＬ文書の特性によっている。すなわち、ＸＭＬ文書では、タグの表れる文書中の行の順番には意味があり、例えば、図３１と図３２とは、ＸＭＬ文書としては異なる。

したがって、レコードに固有のＩＤを付加することと、文書上に表れる行の順序を表現することが、簡潔な情報により、同時に表現できることが望ましい。例えば、図２９において、図３３のＸＭＬ文書のすぐ下に、図３４のＸＭＬ文書を追加したならば、図３０の関係テーブル表現では、テーブルｂｏｏｋｓに
レコード（１．５４．０）
が追加され、さらに、テーブルｂｏｏｋ、ａｕｔｈｏｒ、ａｆｆｉｌｉａｔｅには、それぞれ、
レコード（４．０ハードウエア入門１．０サイエンス社）
レコード（５．０柴山一郎５．０）
レコード（５．０京都大学京都）
が追加される。

関係テーブルとのこのような対応付けを行うと、ＸＭＬ文書は３．１．１節で述べた複合オブジェクトで表される。ＨＯＲＴをベースとしているために、記憶領域サイズおよびアクセス速度の両面で高いパフォーマンスを発揮する。一般に、ＸＭＬ文書はタグの記憶に多くの記憶領域を消費するので、適切な圧縮方式が望まれている。ＨＯＲＴのＣＶＴの利用とＲＤＴによる圧縮により、高い記憶領域の利用率を保証することができる。

また、要素のタグにおいて定義されている属性および属性値は文書全体に対して、唯一のテーブルで表現する（図３０の「属性テーブル」を参照）。ここでは、要素のタグをグローバルに識別する必要があるため、テーブルＩＤとレコードＩＤの双方をカラムとして与えている。

３．３．２ＸＭＬ木のノードメタ情報に注目した実装
図２９のＸＭＬ文書の木グラフ表現を図３５に示す。ここでは、図３５の木グラフのノードのメタ情報をカラムとする関係テーブル表現を図３６に示す。

このテーブルは６つのカラムを有する。“ノードＩＤ”は３．２．１における場合と同様、ノードの文書上の位置を表すＩＤである。“種類”は要素、アトリビュート、ＰＣＤＡＴＡの種類区別であり、“つづり”はノードが要素の時には要素名、アトリビュートの時にはアトリビュート名、ＰＣＤＡＴＡのときには、文字列値である。“親ノードＩＤ”は親ノードのＩＤ、子ノードは文書上の出現順にリストにつながれ、“第１子ノードＩＤ”は第１子ノードのＩＤ、“弟ノードＩＤ”は次順の兄弟ノードのＩＤである。“属性ノードＩＤ”は要素に付随する属性ノードのＩＤであり、同じ要素の属性集合は文書に出現順にリストにつながれている。

なお、３．２．１節における手法とは異なり、ＸＭＬ文書を関係テーブルに変換する上記手法は、元のＸＭＬ文書にＤＴＤが付与されていることを必ずしも必要としない。すなわち、対象とするＸＭＬ文書は要素の入れ子関係が整合している（ｗｅｌｌｆｏｒｍｅｄ）ことのみを条件とする半構造データであってもよい。

以上のようなＸＭＬ文書の木グラフ表現におけるノードのメタ情報を格納する関係テーブルをＨＯＲＴにより実装する。メタ情報にはノードの種類やグラフの接続情報等が含まれる。メタ情報を記録する分、記憶域は増大するが、単一のテーブルとして実装することが可能である。また、ＸＭＬ文書に対する構造検索を必要とする種々の操作要求をメタ情報を利用して簡便に表現することが可能である。ＨＯＲＴを使用してこの関係テーブルを実装することにより、高速な構造検索が可能である。また、文書内容や構造の更新に対するＨＯＲＴデータ構造の更新は容易に行うことができる。

３．３ＨＯＲＴの並列化
図４５より分かるように、インデックス配列による拡張可能配列モデルでは拡張可能配列のサブ配列集合は次元により類別される。すなわち、各サブ配列は経歴値で識別され、その経歴値が付されているＨＯＲＴテーブルの次元に所属するとみなすことができる。ＲＤＴは関係テーブルのすべてのレコードについて、そのキー値である経歴値とオフセットの組を単一のＢ＋木に格納するものであったが、これらのキー値を次元ごとに類別し、個別のＢ＋木で管理する。これにより、ＣＶＴ同様、ＲＤＴについても関係テーブルのカラムの数だけ必要となる。単一のＲＤＴの場合には、マルチトランザクション時にはＲＤＴ全体に対して排他制御（ロッキング）する必要があるため、並列性が阻害される。しかし、この方式では、例えば、次元ごとにプロセッサを割り当て、その次元のＲＤＴの制御を専用に行わせた場合、その次元のＲＤＴのみの排他制御で済み、並列性の阻害は抑制される。なお、ＣＶＴやＨＯＲＴテーブルなど他のＨＯＲＴデータ構造はそのまま変更せずに使用できる。

４．データベース装置
つづいて、図１を参照しながら、上述した関係テーブルの記憶、操作方式を実現するデータベース装置の一構成例について説明する。図１は、本発明の一実施の形態に係るデータベース装置１の構成の概略を示す機能ブロック図である。

図１に示すように、データベース装置１は、データ格納部（データベース記憶部）１０、補助テーブル部（データベース記憶部）２０、テーブル管理部３０、入出力部４０を備えて構成されている。

データ格納部１０は、ディスク装置２上に、ＣＶＴ（第１のＢ＋木データ）１１、ＲＤＴ（第２のＢ＋木データ、要素位置Ｂ＋木データ）１２、一意キーテーブル１３、および各種補助テーブル（経歴値テーブル２１、係数テーブル２２、レコード数テーブル２３）を格納している。ＣＶＴ１１は、関係テーブルのカラムごとに設けられ、該カラム値から拡張可能配列の添字に変換するＢ＋木である。ＲＤＴ１２は、関係テーブルの各レコードに対応する拡張可能配列要素の経歴値（区画位置情報）とオフセット（サブ配列内オフセット、区画内オフセット）の２項組表現がキー値として格納されているＢ＋木である。すなわち、関係テーブルがｎ個のカラムからなる場合、データ格納部１０には、ｎ個のＣＶＴ（ｋｅｙ−ｓｕｂｓｃｒｉｐｔＣｏｎＶｅｒｓｉｏｎＴｒｅｅ）とＲＤＴ（ＲｅａｌＤａｔａＴｒｅｅ）とからなるｎ＋１個のＢ＋木のデータが格納されている。データベースは、複数の関係テーブルから構成されるため、このｎ＋１個のＢ＋木のセットが複数存在する。

補助テーブル部２０は、経歴値テーブル２１、係数テーブル２２、レコード数テーブル２３を、主メモリ３上に保持している。

なお、ＣＶＴ１１、ＲＤＴ１２、一意キーテーブル１３、および補助テーブル群（経歴値テーブル２１、係数テーブル２２、レコード数テーブル２３）は、データ格納部１０に格納されている。データ格納部１０は、ハードディスク等のディスク装置２上に配置されている。経歴値テーブル２１、係数テーブル２２、レコード数テーブル２３の補助テーブル群は、データベース装置１の処理開始時にディスク装置２から読み出されて主メモリ３上の補助テーブル部２０に保持され、データベース処理中に変更が加えられた場合に、ディスク装置２上のデータ格納部１０の対応部分に書き戻される。

経歴値テーブル２１は、配列拡張の時間的順序を表す１次元配列である。係数テーブル２２は、サブ配列内の要素のオフセットを計算する１次関数の係数からなる係数ベクトルをサブ配列ごとに記録したものである。レコード数テーブル２３は、添字ごとにその添字に対応するカラム値を持つすべてのレコード数を記録している。一意キーテーブル１３は、カラム値の重複が起こり得ないカラムである一意キーのカラム値と、ＨＯＲＴデータ構造から得られる経歴値およびオフセットの組とを格納した関係テーブルである。なお、ＲＤＴ１２には、キー値として、経歴値とオフセットの組を、また、データ値として、一意キーのカラム値に対する一意キーテーブルのスロットの添字を挿入しておく。

テーブル管理部３０は、レコード検索部（レコード検索手段）３１、レコード挿入部（レコード挿入手段）３２、レコード削除部（レコード削除手段）３３、キー値−カラム値逆変換部（キー値−カラム値逆変換手段）３４、一意キー管理部（一意キー管理手段）３５、垂直分割管理部（垂直分割管理手段）３６を備えている。

レコード検索部３１は、レコードの検索の処理を行う。レコード挿入部３２は、レコードの挿入の処理を行う。垂直分割管理部３６は、経歴値・オフセット空間が新たなカラム値の挿入によりオーバーフローした場合、当該テーブルを２つのテーブルに分割して、経歴値・オフセット空間の縮小を行う。レコード削除部３３は、レコードの削除の処理を行う。特に、レコード挿入部３２、レコード削除部３３、垂直分割管理部３６は、ＣＶＴ１１、ＲＤＴ１２、経歴値テーブル２１、係数テーブル２２、レコード数テーブル２３、一意キーテーブル１３に対して、必要な保守を行う。なお、レコード検索部３１、レコード挿入部３２、レコード削除部３３は、一意キーを持つレコードおよび垂直分割後のレコードに対する処理も行う。

ここで、レコード挿入部３２は、新たなカラム値を持つレコードを挿入するとき、ＣＶＴ１１にそのカラム値を登録して、論理拡張可能配列を拡張し、経歴値テーブル２１および係数テーブル２２に配列拡張の時間的順序である経歴値およびサブ配列内の要素のオフセットを計算する１次関数の係数をそれぞれ登録し、レコード数テーブル２３に初期値として“１”を登録するとともに、当該論理拡張可能配列の要素の経歴値およびオフセットの２項組表現をキー値としてＲＤＴ１２へ挿入する。

入出力部４０を介してユーザから得た検索要求は、レコード挿入部３２により、（経歴値、オフセット値）対であるキー値の集合として検索されるが、キー値は本データベースにおけるレコードの内部表現であり、ユーザには理解できない。そこで、キー値−カラム値逆変換部３４は、この検索結果をユーザが理解できる表現として返すために、キー値からカラム値の組としてのレコードに逆変換する。具体的には、キー値−カラム値逆変換部３４は、入出力部４０を介して取得した検索要求に対して、ＲＤＴ１２より検索要求に対応する経歴値とオフセットの２項組を検索し、経歴値とオフセットの２項組を拡張可能配列の各次元の添字に変換し、該変換した添字に従って各次元の経歴値テーブル２１、係数テーブル２２、レコード数テーブル２３の各スロットにあらかじめ格納されているカラム値あるいはカラム値が格納されている記憶領域へのポインタを取得する。そして、次元ごとに得た配列添字値から得たカラム値を、次元順に並べてレコードを得る。

一意キー管理部３５は、一意キーテーブル１３の管理を行う。特に、一意キー管理部３５は、一意キーを持つレコードの挿入、削除に伴う、一意キーテーブル１３およびＲＤＴ１２の保守を行う。また、一意キー管理部３５は、一意キーテーブル１３に基づいて、一意キーと一意キー以外のカラム値との対応関係を管理する。

垂直分割管理部３６は、レコードを挿入すると経歴値・オフセット空間がオーバーフローしてしまう関係テーブルを２つのカラム集合の組に分割する。そして、分割したそれぞれの関係テーブルについて、論理拡張可能配列を構成し、経歴値とオフセットの組をそれぞれのＲＤＴ１２に格納する。このとき、２つに分割された関係テーブル間の関係を保つための一意キーテーブル１３を生成し利用する。具体的には、この一意キーテーブル１３には、元の関係テーブルが持つ１個もしくは複数個の一意キーの値と、分割された関係テーブル全てがそれぞれに持つＲＤＴ１２に格納されている経歴値とオフセットの組を格納する。なお、２つの分割テーブルにおける分割タイミングをできるだけ等しくするために、各カラムのカラム値の種類数を調べ、その数がほぼ平等になるようにカラム集合を振り分けることが望ましい。

なお、テーブル管理部３０は、データベースの管理全般を行うものである。よって、レコード検索部３１などのように機能ブロックとして記載しないが、データベースの管理に付随する処理（例えば、範疇属性を持つカラムに関わる処理）なども行うことは言うまでもない。ここで、範疇属性を持つカラムとは、「性別」、「血液型」、「会社の所属部署名」等のようにカラム値の種類数の最大値が限定されるようなカラムのことである。これらは、あらかじめ予測できるサイズ以上に拡張されることはない。通常の拡張次元とは異なり、範疇属性値の数が少ない場合には、ユーザの指定に従って、ＣＶＴを構成せずにＨＯＲＴテーブルのみ主メモリ上に実装し、これを順次検索してもよい。あらかじめ確定しているサイズ以上に当該次元サイズが拡張されることはないからである。

入出力部４０は、データベース装置１を操作するためのインターフェイスである。すなわち、入出力部４０は、データベース装置１に対して、ユーザが直接、処理要求を入力して、データベース装置１からその結果を出力するためのユーザインターフェイス、および、それらの送受信をネットワーク経由で制御するための通信インターフェイスである。

なお、２．３節で説明したチャンク化経歴・オフセット法の場合には、上記データ記録システム１を以下のように変更すればよい。

ＣＶＴ（第１のＢ＋木データ）１１は、関係テーブルのカラム値ごとに設けられ、該カラム値からチャンク化拡張可能配列のチャンクサブ配列情報の位置を表す添字とチャンク内での添字の２項組み表現に変換するためのＢ＋木である。

ＲＤＴ（第２のＢ＋木データ、要素位置Ｂ＋木データ）１２は、関係テーブルの各レコードに対応するチャンク化拡張可能配列の要素が属するチャンクのチャンク番号（区画位置情報）とチャンク内オフセット（区画内オフセット）の２項組表現をキー値として登録したＢ＋木である。

経歴値テーブル２１は、チャンクサブ配列情報としてチャンク配列拡張の時間的順序が登録される。

係数テーブル２２は、チャンクサブ配列内のチャンクの番号を計算する１次関数の係数からなる係数ベクトルがチャンクサブ配列ごとに登録される。

レコード数テーブル２３は、カラム値を持つすべてのレコード数が登録される。

加えて、カラム値の情報として、拡張可能配列の添字ごとに対応するカラム値またはカラム値が格納されている記憶領域へのポインタが登録されるカラム値テーブル（図示せず）が、データ格納部１０に格納されている。このカラム値テーブルは、ＣＶＴ１１、ＲＤＴ１２、一意キーテーブル１３、および補助テーブル群（経歴値テーブル２１、係数テーブル２２、レコード数テーブル２３）と同様に、データベース装置１の処理開始時にディスク装置２から読み出されて主メモリ３上の補助テーブル部２０に保持され、データベース処理中に変更が加えられた場合に、ディスク装置２上のデータ格納部１０の対応部分に書き戻される。なお、カラム値テーブルも、上記補助テーブル群に含まれる。

また、レコード検索部（レコード検索手段）３２は、検索要求に対して、上記ＲＤＴ１２より検索要求に対応するチャンク番号とチャンク内オフセットの２項組を検索する。

また、レコード挿入部（レコード挿入手段）３２は、新たなカラム値を持つレコードを挿入するとき、上記ＣＶＴ１１にそのカラム値を登録して、チャンク化拡張可能配列を拡張し、上記経歴値テーブル２１および上記係数テーブル２２に経歴値および係数をそれぞれ登録し、上記レコード数テーブル２３に初期値を登録するとともに、当該拡張可能配列の要素が所属するチャンクの番号とオフセットの２項組表現をキー値として上記ＲＤＴ１２へ挿入する。

また、レコード削除部（レコード削除手段）３３は、上記レコード検索部３１が検索したチャンク番号とチャンク内オフセットの２項組を上記ＲＤＴ１２から削除するとともに、上記レコード数テーブル２３のレコード数を１だけ減算する。そして、この減算の結果、レコード数が０となった時、経歴値および係数を上記経歴値テーブル２１および上記係数テーブル２２からそれぞれ削除する。

また、キー値−カラム値逆変換部（キー値−カラム値逆変換手段）３４は、上記レコード検索部３１が検索したチャンク番号とチャンク内オフセットの２項組を拡張可能配列の各次元の添字に変換し、該変換した添字に従ってあらかじめ上記カラム値テーブルに格納されているカラム値あるいはカラム値が格納されている記憶領域へのポインタを取得する。

また、一意キーテーブル１３は、カラム値の重複が起こり得ないカラムである一意キーと、チャンク化拡張可能配列の要素の属するチャンク番号およびチャンク内オフセットの２項組表現とが登録される。

そして、一意キー管理部（一意キー管理手段）３５は、上記一意キーテーブル１３に基づいて、一意キーと一意キー以外のカラム値との対応関係を管理する。

また、垂直分割管理部（垂直分割管理手段）３６は、関係テーブルを２つのカラム集合の組に分割し、分割したそれぞれの関係テーブルについて、チャンク化拡張可能配列を構成し、チャンク番号およびチャンク内オフセットの２項組表現をそれぞれ登録したＲＤＴ１２を生成するとともに、元の関係テーブルが持つ１個もしくは複数個の一意キーの値と、分割したそれぞれの関係テーブルに対応する上記ＲＤＴ１２に格納されているチャンク番号およびチャンク内オフセットの２項組表現とを登録した一意キーテーブル１３を生成する。

最後に、データベース装置１は、ワークステーションやパーソナルコンピュータ等の汎用のコンピュータをベースに構成できる。よって、データベース装置１の各ブロック、特にテーブル管理部３０は、次のようにＣＰＵを用いてソフトウェアによって実現することができる。なお、データベース装置１は、その機能を複数の装置に分散させたシステムとして構成することもできる。

すなわち、データベース装置１は、各機能を実現する制御プログラムの命令を実行するＣＰＵ（ｃｅｎｔｒａｌｐｒｏｃｅｓｓｉｎｇｕｎｉｔ）、上記プログラムおよびデータベースデータを格納した二次記憶装置（磁気ディスク装置）、上記プログラムおよびデータベースデータを展開するＲＡＭ（ｒａｎｄｏｍａｃｃｅｓｓｍｅｍｏｒｙ）などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアであるテーブル管理部３０の制御プログラム（データベースの管理プログラム）のプログラムコード（実行形式プログラム、中間コードプログラム、ソースプログラム）をコンピュータで読み取り可能に記録した記録媒体を、上記データベース装置１に供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に記録されているプログラムコードを読み出し実行することによって、達成可能である。

上記記録媒体としては、例えば、磁気テープやカセットテープ等のテープ系、フロッピー（登録商標）ディスク／ハードディスク等の磁気ディスクやＣＤ−ＲＯＭ／ＭＯ／ＭＤ／ＤＶＤ／ＣＤ−Ｒ等の光ディスクを含むディスク系、ＩＣカード（メモリカードを含む）／光カード等のカード系、あるいはマスクＲＯＭ／ＥＰＲＯＭ／ＥＥＰＲＯＭ／フラッシュＲＯＭ等の半導体メモリ系などを用いることができる。

また、データベース装置１を通信ネットワークと接続可能に構成し、上記プログラムコードを通信ネットワークを介して供給してもよい。この通信ネットワークとしては、特に限定されず、例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ、ＩＳＤＮ、ＶＡＮ、ＣＡＴＶ通信網、仮想専用網（ｖｉｒｔｕａｌｐｒｉｖａｔｅｎｅｔｗｏｒｋ）、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、通信ネットワークを構成する伝送媒体としては、特に限定されず、例えば、ＩＥＥＥ１３９４、ＵＳＢ、電力線搬送、ケーブルＴＶ回線、電話線、ＡＤＳＬ回線等の有線でも、ＩｒＤＡやリモコンのような赤外線、Ｂｌｕｅｔｏｏｔｈ（登録商標）、８０２．１１無線、ＨＤＲ、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。

本実施の形態は本発明の範囲を限定するものではなく、本発明の範囲内で種々の変更が可能である。

５．本発明の有効性
（１）従来技術との違いについて
本発明は、先行技術である「拡張可能配列」の考え方を基盤としている。この考え方は、〔発明を実施するための最良の形態〕の〔前提となる技術〕において説明したとおりである。

従来、拡張可能配列は通常の固定サイズ配列と同様、主メモリ上に展開して操作されるデータ構造として扱われることを前提としていた。すなわち、拡張可能配列の各サブ配列中の各要素はすべて有効要素であり、それぞれの要素はすべて、主メモリにそのサイズを占めている。サブ配列の各次元のサイズが［ｓ１，ｓ２，・・・，ｓｎ］として、１要素のサイズをｅとするとき、必ずｓ１ｓ２・・・ｓｎｅのサイズの連続記憶領域を占める。本発明では、この拡張可能配列の考え方を関係テーブルを表現するのに用いている。

関係テーブルＴがｎ個のカラムｃ１，ｃ２，・・・，ｃｎからなり、かつカラムｃｉの値の数（種類）がｋｉであり、配列要素サイズがｅであるとすると、関係テーブルをそのまま拡張可能配列で表そうとすると少なくともｋ１ｋ２・・・ｋｎｅのサイズを必要とする。例えば、ｎ＝１０、ｃｉ＝１０（ｉ＝１，・・・，１０）、ｅ＝４（バイト）であるとき、１０^１０レコード、すなわち、１０^１０×４＝４０Ｇバイトの記憶空間に相当する記憶領域が必要となる。

しかし、実際にはＴのレコード数が１０^１０個存在することはごくまれであり（カラムｃｉ（ｉ＝１，・・・，１０）のすべての組み合わせがレコードとして存在する場合）、ｎが大きいときにはほとんどの場合、１０^１０に比べて無視できる程度のレコード数であるといえる。〔前提となる技術〕における数式（１）のアドレス関数を計算して、要素のアドレスが決定できるためには、４０Ｇバイトの記憶領域を確保して、実際には存在しないレコードのための場所を割り当てる必要がある。以上のような状況では、主メモリ上はおろか、二次記憶上において、データベースとして物理的に格納不可能か格納できても極めて効率が悪くなり、実用的に使用できない。

本発明は、以上の状況に注目して、存在するレコードのみを効率よく格納し、従来の関係テーブルの実装より、はるかに高速にレコードを検索するデータ構造とそれを基盤とするデータベース装置を提案している。経歴値とサブ配列が１対１に対応していることに注目して、添字の組Ｉで表される配列要素をそれが属するサブ配列の経歴値ｈとサブ配列内でのオフセットｏの２項組＜ｈ，ｏ＞で表すことを提案している。これは、従来、提案されていない配列要素に対する番地付けの方法である。この方法により、次元数ｎが大きくても（カラム数が多くても）常に２項組として、簡潔に表現でき、記憶域の消費をｎに関わらず最小限に抑制できる。

ＨＯＲＴデータ構造により表現される関係テーブルのレコード集合をＲ＝｛ｒ１，ｒ２，・・・，ｒｍ｝とする。このとき、レコードｒｉ∈Ｒ（ｉ＝１，・・・，ｍ）について、それに対応する拡張可能配列要素の経歴値とオフセットの２項組表現＜ｈｉ，ｏｉ＞がキー値としてＲＤＴに格納される。キー値は関係テーブルのレコードそのものを表現しており、Ｒに存在しているレコードについてのみ、そのキー値がＲＤＴに登録される。このＲＤＴはＢ＋木で実装されるので、キー値の検索は高速であり、Ｂ＋木のシーケンスセットをたどることにより、キー値の範囲検索も従来の関係テーブルの実装より、はるかに高速化できる。

なお、上で述べた、拡張可能配列のサブ配列のための連続記憶領域は実際には確保されない。この意味で、キー値が置かれる拡張可能配列はあくまでも論理的に存在するのみであり、従来の拡張可能配列のように実体を持つ連続記憶領域を実際に必要としない。この意味で、以後、本願発明における拡張可能配列を論理拡張可能配列という。

実用化における、ここでの重要な問題は、上述の論理拡張可能配列を使用するとき、実際に記憶域として確保する必要はないものの、先に述べたように膨大な論理記憶空間を必要とすることである。この記憶空間は、使用するコンピュータのアドレス長をａとすると２^ａとなり、このサイズを超えるアドレス（オフセット値）を扱うことができなくなる。従来の研究では、この点に関する指摘はなく、従って、その解決策も示されていない。本願発明の重要なポイントの１つとして、この点の解決策を関係テーブルの垂直分割技法として提示している点であり、〔発明を実施するための最良の形態〕の２．２節において述べている。また、本技法は同２．１節で提案されている一意キーテーブルに基づいている。この垂直分割技法を使えば、大規模関係テーブルのＨＯＲＴデータ構造表現が可能であり、この表現法の採用により、検索速度が劣化することはない。

（２）本発明のデータベース装置のパフォーマンスについて
本発明のデータベース装置のパフォーマンスを調べるために、プロトタイプとしてチャンク化ＨＯＲＴではない通常のＨＯＲＴによって、実際に構築したシステムについて計測した。比較にはフリーソフトウェアとして広く流通しているＰｏｓｔｇｒｅｓデータベース管理システム（バージョン７．２．１）を用いた。関係テーブルのレコード数は、下記（ａ）（ｂ）（ｃ）のいずれにおいても、１００万レコードとした。「カラム値の重複度」を「レコード総数１００万／カラム値の種類の数」、すなわち同じカラム値を持つレコード数とする。このカラム値の重複度は一意キーカラムを除くすべてのカラムにおいて同一であるとする。以下のＩ，ＩＩの計測結果より、関係テーブルの垂直分割があり、かつカラム長が短い場合の、二次記憶サイズを除いて、どの場合でも二次記憶サイズおよび検索速度共にＰｏｓｔｇｒｅｓシステムより、大幅に優れていることが分かる。

Ｉ．一意キーなし、垂直分割なしの場合
カラム値の重複度を変化させて、カラムのデータ型がすべて文字列（２０バイト長）の場合、および整数値（４バイト長）の場合について計測した。計測はカラム集合の中から、１つのカラムの値を固定して、その値をカラム値として持つ全レコードを検索する時間、関係テーブルを格納するのに必要な二次記憶全サイズ、およびこの内ＲＤＴの占めるサイズについて計測した。なお、検索時間をカラムごとに計測しているが、これは次元依存性を調べるためである。

（ａ）カラム数６、カラムの型が文字列型の場合
図３７は、カラム数６、カラムの型が文字列型の場合のＨＯＲＴシステムの計測結果である。図３８は、カラム数６、カラムの型が文字列型の場合のＰｏｓｔｇｒｅｓシステムの計測結果である。

図３７、図３８の計測結果より、ＨＯＲＴシステムとＰｏｓｔｇｒｅｓシステムでは、関係テーブルの記憶に必要な二次記憶全サイズはＨＯＲＴシステムではＰｏｓｔｇｒｅｓシステムでの２１〜２３％程度、検索時間はＨＯＲＴシステムではＰｏｓｔｇｒｅｓシステムでの１０〜１４％程度であることが分かる。ＨＯＲＴシステムでは、重複度が増加するほど二次記憶全サイズ、検索時間とも有利になっている。

（ｂ）カラム数６、整数型（４バイト長）の場合
図３９は、カラム数６、整数型（４バイト長）の場合のＨＯＲＴシステムの計測結果である。図４０は、カラム数６、整数型（４バイト長）の場合のＰｏｓｔｇｒｅｓシステムの計測結果である。

図３９、図４０の計測結果より、ＨＯＲＴシステムとＰｏｓｔｇｒｅｓシステムでは、関係テーブルの記憶に必要な二次記憶全サイズはＨＯＲＴシステムではＰｏｓｔｇｒｅｓシステムでの５０〜５５％程度、検索時間はＨＯＲＴシステムではＰｏｓｔｇｒｅｓシステムでの１４〜２０％程度であることが分かる。ＨＯＲＴシステムでは、重複度が増加するほど二次記憶全サイズ、検索時間とも有利になっている。カラムのサイズが大きいほど、また、二次記憶全サイズ、検索時間ともＨＯＲＴシステムの方がＰｏｓｔｇｒｅｓシステムより有利になっている。したがって、（ａ）の場合の方が、（ｂ）の場合より、優れている。

ＩＩ．一意キーカラムがある場合の、垂直分割がない場合と垂直分割がある場合との比較
１０カラムからなる関係テーブルについて計測する。最初のカラムのみ整数型の一意キーカラムであり、残りの９つのカラムは重複度１００００である。この最初のカラムは一意キーであるので、一意キーテーブルが二次記憶上に形成され、論理拡張可能配列は残りの９つのカラムについて構成される。重複度を１００００としているのは、６４ビットマシンのアドレス空間が２^６４であり、ｘ^９≦２^６４を満足する最大のｘに近い数として１００を各カラム値の種類の数としている。したがって、この場合、各カラムの重複度は１００００としている。

（ｉ）ＨＯＲＴシステムにおいて、垂直分割しない場合（ＨＯＲＴ）
（ｉｉ）ＨＯＲＴシステムにおいて、垂直分割した場合（ＨＯＲＴ＿分割）
（ｉｉｉ）Ｐｏｓｔｇｒｅｓシステムの場合（ＰＯＳＴ）
の３つの場合について計測した。

（ａ）９つのカラムのデータ型が文字列型（２０バイト長）の場合
図４１は、９つのカラムのデータ型が文字列型（２０バイト長）の場合の計測結果である。

図４１の計測結果より、ＨＯＲＴおよびＨＯＲＴ＿分割のＰＯＳＴに対する全二次記憶サイズの割合を求めると、それぞれ２４．８％および４０．２％となっており、また、平均検索時間を求めると、それぞれ１２．６％および１１．１％となっている。１カラム目の値を固定したときの検索時間がいずれの場合も極端に速いのは１カラム目は一意キーカラムであり、検索件数が１件であるからである。このとき、ＰＯＳＴの場合には索引が付与される。

テーブルの垂直分割がある場合（ＨＯＲＴ＿分割の場合）、二次記憶全サイズは一意キーテーブルを必要とすることとＲＤＴの増加により、垂直分割がない場合（ＨＯＲＴの場合）に比べて大きくなっているが、これらのデータ構造の導入により検索速度は速くなっている。

（ｂ）９つのカラムのデータ型が整数型（４バイト長）の場合
図４２は、９つのカラムのデータ型が整数型（４バイト長）の場合の計測結果である。

図４２の計測結果より、ＨＯＲＴおよびＨＯＲＴ＿分割のＰＯＳＴに対する全二次記憶サイズの割合を求めると、それぞれ６７．４％および１０８％となっており、また、平均検索時間を求めると、それぞれ１９．８％および１６．７％となっている。１カラム目の値を固定したときの検索時間がいずれの場合も極端に速いのは１カラム目は一意キーカラムであり、検索件数が１件であるからである。このとき、ＰＯＳＴの場合には索引が付与される。

最後に、本発明に係るデータベース装置は、関係テーブルを用いたデータベース装置であって、関係テーブルのカラム値ごとに設けられ、該カラム値から拡張可能配列の添字に変換するための第１のＢ＋木データと、関係テーブルの各レコードに対応する拡張可能配列の要素の経歴値およびオフセットの２項組表現をキー値として登録した第２のＢ＋木データと、配列拡張の時間的順序を登録した経歴値テーブルと、サブ配列内の要素のオフセットを計算する１次関数の係数からなる係数ベクトルをサブ配列ごとに登録した係数テーブルと、拡張可能配列の添字ごとにその添字に対応するカラム値を持つすべてのレコード数を登録したレコード数テーブルとを格納したデータベース記憶部と、新たなカラム値を持つレコードを挿入するとき、上記第１のＢ＋木データにそのカラム値を登録して、拡張可能配列を拡張し、上記経歴値テーブルおよび上記係数テーブルに経歴値および係数をそれぞれ登録し、上記レコード数テーブルに初期値を登録するとともに、当該拡張可能配列の要素の経歴値およびオフセットの２項組表現をキー値として上記第２のＢ＋木データへ挿入するレコード挿入手段と、を具備することを特徴としている。

また、本発明に係るデータベースの管理方法は、関係テーブルを用いたデータベース装置におけるデータベースの管理方法であって、上記データベース装置は、データベース記憶部に、関係テーブルのカラム値ごとに設けられ、該カラム値から拡張可能配列の添字に変換するための第１のＢ＋木データと、関係テーブルの各レコードに対応する拡張可能配列の要素の経歴値およびオフセットの２項組表現をキー値として登録した第２のＢ＋木データと、配列拡張の時間的順序を登録した経歴値テーブルと、サブ配列内の要素のオフセットを計算する１次関数の係数からなる係数ベクトルをサブ配列ごとに登録した係数テーブルと、拡張可能配列の添字ごとにその添字に対応するカラム値を持つすべてのレコード数を登録したレコード数テーブルと、を格納しており、新たなカラム値を持つレコードを挿入するとき、上記第１のＢ＋木データにそのカラム値を登録して、拡張可能配列を拡張し、上記経歴値テーブルおよび上記係数テーブルに経歴値および係数をそれぞれ登録し、上記レコード数テーブルに初期値を登録するとともに、当該拡張可能配列の要素の経歴値およびオフセットの２項組表現をキー値として上記第２のＢ＋木データへ挿入することを特徴としている。

上記の構成によれば、新たなカラム値を持つレコードを挿入するとき、第１のＢ＋木データにそのカラム値を登録して、拡張可能配列を拡張し、経歴値テーブルおよび係数テーブルに経歴値および係数をそれぞれ登録し、レコード数テーブルに初期値（例えば、１）を登録するとともに、当該拡張可能配列の要素の経歴値およびオフセットの２項組表現をキー値として第２のＢ＋木データへ挿入する。そして、以後、同じカラム値を持つレコードの挿入するたびに、第２のＢ＋木データへの挿入を行うとともに、レコード数テーブルの当該レコード数の値を増加させればよい。

よって、上記のようなデータ構造を有するデータベースに対して、上記のようにレコードを挿入することにより、実行時に動的に新たなカラム値を持つレコードを追加することができる。また、存在するレコードのみを登録することができる。換言すれば、存在しないレコードについては記憶領域を確保する必要がないため、ディスクスペースを効率よく利用できる。よって、配列内の有効要素は少ない、いわゆる疎配列が存在してもディスクスペースが無駄にならない。加えて、アドレス関数を使って高速にレコードの格納位置を検索することが可能である。

また、本発明に係るデータベース装置は、関係テーブルを用いたデータベース装置であって、関係テーブルのカラム値ごとに設けられ、該カラム値から拡張可能配列の添字に変換するための第１のＢ＋木データと、関係テーブルの各レコードに対応する拡張可能配列の要素の経歴値およびオフセットの２項組表現をキー値として登録した第２のＢ＋木データと、配列拡張の時間的順序を登録した経歴値テーブルと、サブ配列内の要素のオフセットを計算する１次関数の係数からなる係数ベクトルをサブ配列ごとに登録した係数テーブルと、拡張可能配列の添字ごとにその添字に対応するカラム値を持つすべてのレコード数を登録したレコード数テーブルとを格納したデータベース記憶部と、検索要求に対して、上記第２のＢ＋木データより検索要求に対応する経歴値とオフセットの２項組を検索するレコード検索手段と、を具備することを特徴としている。

また、本発明に係るデータベースの管理方法は、関係テーブルを用いたデータベース装置におけるデータベースの管理方法であって、上記データベース装置は、データベース記憶部に、関係テーブルのカラム値ごとに設けられ、該カラム値から拡張可能配列の添字に変換するための第１のＢ＋木データと、関係テーブルの各レコードに対応する拡張可能配列の要素の経歴値およびオフセットの２項組表現をキー値として登録した第２のＢ＋木データと、配列拡張の時間的順序を登録した経歴値テーブルと、サブ配列内の要素のオフセットを計算する１次関数の係数からなる係数ベクトルをサブ配列ごとに登録した係数テーブルと、拡張可能配列の添字ごとにその添字に対応するカラム値を持つすべてのレコード数を登録したレコード数テーブルと、を格納しており、検索要求に対して、上記第２のＢ＋木データより検索要求に対応する経歴値とオフセットの２項組を検索することを特徴としている。

上記の構成によれば、アドレス関数を使って高速にレコードの格納位置を検索することが可能である。加えて、データベースが上記のようなデータ構造を有することにより、実行時に動的に新たなカラム値を持つレコードを追加することができる。また、存在するレコードのみを登録することができる。換言すれば、存在しないレコードについては記憶領域を確保する必要がないため、ディスクスペースを効率よく利用できる。よって、配列内の有効要素は少ない、いわゆる疎配列であってもディスクスペースが無駄にならない。

さらに、本発明に係るデータベース装置は、上記レコード検索手段が検索した経歴値とオフセットの２項組を拡張可能配列の各次元の添字に変換し、該変換した添字に従って各次元の経歴値テーブル、係数テーブル、レコード数テーブルの各スロットにあらかじめ格納されているカラム値あるいはカラム値が格納されている記憶領域へのポインタを取得するキー値−カラム値逆変換手段をさらに具備することを特徴としている。

上記の構成によれば、さらに、カラム値と配列添字値の双方向変換が可能になり、次元ごとに得た配列添字値からカラム値を得て、それらを次元順に並べることによって、検索結果のレコードを得ることができる。

さらに、本発明に係るデータベース装置は、上記レコード検索手段が検索した経歴値とオフセットの２項組を上記第２のＢ＋木データから削除するとともに、上記レコード数テーブルのレコード数を１だけ減算するレコード削除手段をさらに具備することを特徴としている。そして、レコード削除手段は、この減算の結果、レコード数が０となった時、経歴値および係数を経歴値テーブルおよび係数テーブルからそれぞれ削除する。

上記の構成によれば、さらに、同じカラム値を持つレコードの削除を行うたびに、第２のＢ＋木データから削除するとともに、レコード数テーブルの当該レコード数の値を減少させる。そして、レコードの削除により、当該カラム値を有するレコードが無くなった場合には、第１のＢ＋木データからもカラム値を削除すればよい。

よって、上記のようなデータ構造を有するデータベースからレコードを削除することが可能となる。したがって、また、存在するレコードのみが登録されているようにデータベースを管理することができる。それゆえ、存在しないレコードについては記憶領域を確保する必要がないため、ディスクスペースを効率よく利用できる。

さらに、本発明に係るデータベース装置においては、上記データベース記憶部は、さらに、カラム値の重複が起こり得ないカラムである一意キーと、拡張可能配列の要素の経歴値およびオフセットの２項組表現とを登録した一意キーテーブルを格納しており、かつ、上記一意キーテーブルに基づいて、一意キーと一意キー以外のカラム値との対応関係を管理する一意キー管理手段を具備することを特徴としている。

また、本発明に係るデータベースの管理方法は、上記データベース装置は、データベース記憶部に、さらに、カラム値の重複が起こり得ないカラムである一意キーと、拡張可能配列の要素の経歴値およびオフセットの２項組表現とを登録した一意キーテーブルを格納しており、上記一意キーテーブルに基づいて、一意キーと一意キー以外のカラム値との対応関係を管理することを特徴としている。

上記の構成によれば、さらに、一意キーの値が指定された場合には、一意キーテーブルの該当スロットに格納されている経歴値とオフセットの組から、一意キーではない他のカラムの値を得ることができる。また逆に、一意キー以外のカラム値が指定された場合には、第２のＢ＋木データから経歴値とオフセットの組をキー値として、そのデータ値、つまり対象のレコードが格納されている一意キーテーブルのスロット番号を得ることができるので、対応する一意キーの値を得ることができる。

よって、一意キーを、他のカラムとは別に管理し、一意キー以外のカラムのみによって拡張可能配列を構成することが可能となる。したがって、経歴値−オフセット空間のオーバーフローを遅らせることが可能となる。

さらに、本発明に係るデータベース装置は、関係テーブルを２つのカラム集合の組に分割し、分割したそれぞれの関係テーブルについて、拡張可能配列を構成し、経歴値とオフセットの組をそれぞれ登録した第２のＢ＋木データを生成するとともに、元の関係テーブルが持つ１個もしくは複数個の一意キーの値と、分割したそれぞれの関係テーブルに対応する上記第２のＢ＋木データに格納されている経歴値とオフセットの組とを登録した一意キーテーブルを生成する垂直分割管理手段をさらに具備することを特徴としている。

上記の構成によれば、さらに、関係テーブルを２つのカラム集合に分割して（テーブルの垂直分割）、２つのテーブルとすることにより、経歴値−オフセット空間を縮小することができる。よって、経歴値−オフセット空間がオーバーフローした時点で関係テーブルを垂直分割することにより、新たなカラム値の追加に対しても無制限に対応することが可能となる。なお、経歴値−オフセット空間は使用するコンピュータのアドレス長をａとすると２^ａとなり、このサイズを超えるオフセット値はソフトウェアにより計算されるので、実行効率が極端に低下する。

また、本発明に係るデータベースのデータ構造は、関係テーブルを用いたデータベースのデータ構造であって、関係テーブルのカラム値ごとに設けられ、該カラム値から拡張可能配列の添字に変換するための第１のＢ＋木データと、関係テーブルの各レコードに対応する拡張可能配列の要素の経歴値およびオフセットの２項組表現をキー値として登録した第２のＢ＋木データと、配列拡張の時間的順序を登録した経歴値テーブルと、サブ配列内の要素のオフセットを計算する１次関数の係数からなる係数ベクトルをサブ配列ごとに登録した係数テーブルと、拡張可能配列の添字ごとにその添字に対応するカラム値を持つすべてのレコード数を登録したレコード数テーブルと、よりなることを特徴としている。

上記の構成によれば、この添字の組は新たなカラム値を持つレコードの追加により拡張付加されるｎ−１次元のサブ配列の付加順を表す拡張経歴値とサブ配列内のオフセットの２項組で表される。すなわち、ｎが大きくなれば関係テーブルのレコード長は大きくなるが、ｎにかかわらず、経歴値およびオフセットの２項組でレコードを表している。したがって、特にカラム数の多い関係テーブルの場合でも、極めて記憶効率がよい。また、存在しているレコードについてのみ、対応する２項組をキー値としてＢ＋木に登録しており、この点からも記憶効率が向上する。さらに、Ｂ＋木の利用により、高速検索処理が可能である。

さらに、本発明に係るデータベースのデータ構造は、上記第２のＢ＋木データは、拡張可能配列の次元ごとに設けられ、キー値である経歴値およびオフセットの２項組表現を次元ごとに管理することを特徴としている。

上記の構成によれば、さらに、第２のＢ＋木データに対する処理を次元ごとに並列化することができる。例えば、次元ごとにプロセッサを割り当て、その次元の第２のＢ＋木データの制御を専用に行わせた場合、その次元の第２のＢ＋木データのみの排他制御で済み、並列性の阻害が抑制される。なお、第１のＢ＋木データや他のテーブル（経歴値テーブル、係数テーブル、レコード数テーブル等）はそのまま変更せずに使用できる。また、第２のＢ＋木データが単一の場合には、マルチトランザクション時に第２のＢ＋木データ全体に対して排他制御（ロッキング）する必要があるため、並列化できない。

さらに、本発明に係るデータベースのデータ構造は、複合オブジェクトを用いたオブジェクト指向データベースのデータ構造であって、上記複合オブジェクトは、その属性として他のインスタンスオブジェクトへの参照をオブジェクトＩＤとして持つオブジェクトであり、クラスの各属性が上記関係テーブルの各カラムにそれぞれ割り当てられ、カラムが他のインスタンスオブジェクトを参照するオブジェクトＩＤ型の属性であるとき、カラム値が、参照する関係テーブルのレコードのオブジェクトＩＤであることを特徴としている。

上記の構成によれば、さらに、関係テーブルとオブジェクトとを上記のように対応づけることによって、複合オブジェクトを用いたオブジェクト指向データベースが実現できる。そして、上述したデータ構造に従ってデータが管理されるため、記憶領域サイズおよびアクセス速度の両面で高いパフォーマンスを発揮できる。

また、本発明に係る文書データのデータ構造は、上述のデータベースのデータ構造を利用した文書データのデータ構造であって、文書データに含まれるタグ要素が上記関係テーブルのカラムに割り当てられ、タグ要素が複数のタグ要素を含むとき、カラム値が、参照する関係テーブルのレコードのオブジェクトＩＤであることを特徴としている。

上記の構成によれば、さらに、関係テーブルとタグとを上記のように対応づけることによって、ＸＭＬ文書等の文書データを管理できる。そして、上述したデータ構造に従ってデータが管理されるため、記憶領域サイズおよびアクセス速度の両面で高いパフォーマンスを発揮できる。

なお、上記データベース装置は、コンピュータによって実現してもよく、この場合には、コンピュータを上記各手段として動作させることにより上記データベース装置をコンピュータにて実現させるデータベース管理プログラム、およびそれを記録したコンピュータ読み取り可能な記録媒体も、本発明の範疇に入る。

発明の詳細な説明の項においてなされた具体的な実施態様または実施例は、あくまでも、本発明の技術内容を明らかにするものであって、そのような具体例にのみ限定して狭義に解釈されるべきものではなく、本発明の精神と特許請求事項との範囲内で、いろいろと変更して実施することができるものである。

本発明は関係データベースに広く適用できるのものであり、特に、大規模関係テーブルの高速検索処理が必要な産業上の多くの分野に好適である。記憶効率も優れている。また、本発明は、関係テーブルのみではなく、オブジェクト指向データベースにおけるクラスの実装にも適用でき、オブジェクトＩＤの導入により、複合オブジェクトの効率よい実装方式も提供できる。さらに、大規模なＸＭＬ（ＥＸｔｅｎｓｉｂｌｅＭａｒｋｕｐＬａｎｇｕａｇｅ）文書の効率よい記憶構造としての使用の他、多次元データ一般の実装にも応用できる。

Claims

関係テーブルを用いたデータベース装置であって、
関係テーブルの各レコードに対応する拡張可能配列の要素の位置を示す位置情報をキー値として登録した要素位置Ｂ＋木データを格納したデータベース記憶部を具備するとともに、
上記位置情報が、要素が属する拡張可能配列の区画の先頭要素の位置を示す区画位置情報と区画内における要素の位置を示す区画内オフセットとを含む情報であることを特徴とするデータベース装置。
上記区画が拡張可能配列のサブ配列であって、
上記データベース記憶部に、
上記区画位置情報である、関係テーブルの各レコードに対応する拡張可能配列の要素が属する区画の経歴値と、上記区画内オフセットであるサブ配列内オフセットとの２項組表現をキー値として登録した、上記要素位置Ｂ＋木データである第２のＢ＋木データとともに、
関係テーブルのカラム値ごとに設けられ、該カラム値から拡張可能配列の添字に変換するための第１のＢ＋木データと、
配列拡張の時間的順序を登録した経歴値テーブルと、
サブ配列内の要素のサブ配列内オフセットを計算する１次関数の係数からなる係数ベクトルをサブ配列ごとに登録した係数テーブルと、
拡張可能配列の添字ごとにその添字に対応するカラム値を持つすべてのレコード数を登録したレコード数テーブルと、を格納したことを特徴とする請求項１に記載のデータベース装置。
検索要求に対して、上記第２のＢ＋木データより検索要求に対応する経歴値とサブ配列内オフセットの２項組を検索するレコード検索手段を具備することを特徴とする請求項２に記載のデータベース装置。
新たなカラム値を持つレコードを挿入するとき、上記第１のＢ＋木データにそのカラム値を登録して、拡張可能配列を拡張し、上記経歴値テーブルおよび上記係数テーブルに経歴値および係数をそれぞれ登録し、上記レコード数テーブルに初期値を登録するとともに、当該拡張可能配列の要素の経歴値およびサブ配列内オフセットの２項組表現をキー値として上記第２のＢ＋木データへ挿入するレコード挿入手段を具備することを特徴とする請求項２に記載のデータベース装置。
１つのレコードを削除するとき、経歴値とサブ配列内オフセットの２項組を上記第２のＢ＋木データから削除するとともに、上記レコード数テーブルのレコード数を１だけ減算するレコード削除手段を具備することを特徴とする請求項２に記載のデータベース装置。
上記レコード検索手段が検索した経歴値とオフセットの２項組を拡張可能配列の各次元の添字に変換し、該変換した添字に従って各次元の経歴値テーブル、係数テーブル、レコード数テーブルの各スロットにあらかじめ格納されているカラム値あるいはカラム値が格納されている記憶領域へのポインタを取得するキー値−カラム値逆変換手段をさらに具備することを特徴とする請求項３に記載のデータベース装置。
上記データベース記憶部は、さらに、カラム値の重複が起こり得ないカラムである一意キーと、拡張可能配列の要素の経歴値およびサブ配列内オフセットの２項組表現とを登録した一意キーテーブルを格納しており、かつ、
上記一意キーテーブルに基づいて、一意キーと一意キー以外のカラム値との対応関係を管理する一意キー管理手段を具備することを特徴とする請求項２に記載のデータベース装置。
関係テーブルを２つのカラム集合の組に分割し、分割したそれぞれの関係テーブルについて、拡張可能配列を構成し、経歴値とオフセットの組をそれぞれ登録した第２のＢ＋木データを生成するとともに、元の関係テーブルが持つ１個もしくは複数個の一意キーの値と、分割したそれぞれの関係テーブルに対応する上記第２のＢ＋木データに格納されている経歴値とオフセットの組とを登録した一意キーテーブルを生成する垂直分割管理手段をさらに具備することを特徴とする請求項７に記載のデータベース装置。
関係テーブルを用いたデータベース装置におけるデータベースの管理方法であって、
上記データベース装置は、
データベース記憶部に、
関係テーブルのカラム値ごとに設けられ、該カラム値から拡張可能配列の添字に変換するための第１のＢ＋木データと、
関係テーブルの各レコードに対応する拡張可能配列の要素の経歴値およびサブ配列内オフセットの２項組表現をキー値として登録した第２のＢ＋木データと、
配列拡張の時間的順序を登録した経歴値テーブルと、
サブ配列内の要素のサブ配列内オフセットを計算する１次関数の係数からなる係数ベクトルをサブ配列ごとに登録した係数テーブルと、
拡張可能配列の添字ごとにその添字に対応するカラム値を持つすべてのレコード数を登録したレコード数テーブルと、を格納しており、
検索要求に対して、上記第２のＢ＋木データより検索要求に対応する経歴値とサブ配列内オフセットの２項組を検索することを特徴とするデータベースの管理方法。
関係テーブルを用いたデータベース装置におけるデータベースの管理方法であって、
上記データベース装置は、
データベース記憶部に、
関係テーブルのカラム値ごとに設けられ、該カラム値から拡張可能配列の添字に変換するための第１のＢ＋木データと、
関係テーブルの各レコードに対応する拡張可能配列の要素の経歴値およびサブ配列内オフセットの２項組表現をキー値として登録した第２のＢ＋木データと、
配列拡張の時間的順序を登録した経歴値テーブルと、
サブ配列内の要素のサブ配列内オフセットを計算する１次関数の係数からなる係数ベクトルをサブ配列ごとに登録した係数テーブルと、
拡張可能配列の添字ごとにその添字に対応するカラム値を持つすべてのレコード数を登録したレコード数テーブルと、を格納しており、
新たなカラム値を持つレコードを挿入するとき、上記第１のＢ＋木データにそのカラム値を登録して、拡張可能配列を拡張し、上記経歴値テーブルおよび上記係数テーブルに経歴値および係数をそれぞれ登録し、上記レコード数テーブルに初期値を登録するとともに、当該拡張可能配列の要素の経歴値およびサブ配列内オフセットの２項組表現をキー値として上記第２のＢ＋木データへ挿入することを特徴とするデータベースの管理方法。
関係テーブルを用いたデータベース装置におけるデータベースの管理方法であって、
上記データベース装置は、
データベース記憶部に、
関係テーブルのカラム値ごとに設けられ、該カラム値から拡張可能配列の添字に変換するための第１のＢ＋木データと、
関係テーブルの各レコードに対応する拡張可能配列の要素の経歴値およびサブ配列内オフセットの２項組表現をキー値として登録した第２のＢ＋木データと、
配列拡張の時間的順序を登録した経歴値テーブルと、
サブ配列内の要素のサブ配列内オフセットを計算する１次関数の係数からなる係数ベクトルをサブ配列ごとに登録した係数テーブルと、
拡張可能配列の添字ごとにその添字に対応するカラム値を持つすべてのレコード数を登録したレコード数テーブルと、を格納しており、
１つのレコードを削除するとき、経歴値とオフセットの２項組を上記第２のＢ＋木データから削除するとともに、上記レコード数テーブルのレコード数を１だけ減算することを特徴とするデータベースの管理方法。
関係テーブルを用いたデータベースのデータ構造であって、
関係テーブルのカラム値ごとに設けられ、該カラム値から拡張可能配列の添字に変換するための第１のＢ＋木データと、
関係テーブルの各レコードに対応する拡張可能配列の要素の経歴値およびサブ配列内オフセットの２項組表現をキー値として登録した第２のＢ＋木データと、
配列拡張の時間的順序を登録した経歴値テーブルと、
サブ配列内の要素のサブ配列内オフセットを計算する１次関数の係数からなる係数ベクトルをサブ配列ごとに登録した係数テーブルと、
拡張可能配列の添字ごとにその添字に対応するカラム値を持つすべてのレコード数を登録したレコード数テーブルと、よりなることを特徴とするデータベースのデータ構造。
上記第２のＢ＋木データは、拡張可能配列の次元ごとに設けられ、キー値である経歴値およびサブ配列内オフセットの２項組表現を次元ごとに管理することを特徴とする請求項１２に記載のデータベースのデータ構造。
複合オブジェクトを用いたオブジェクト指向データベースのデータ構造であって、
上記複合オブジェクトは、その属性として他のインスタンスオブジェクトへの参照をオブジェクトＩＤとして持つオブジェクトであり、
クラスの各属性が上記関係テーブルの各カラムにそれぞれ割り当てられ、
カラムが他のインスタンスオブジェクトを参照するオブジェクトＩＤ型の属性であるとき、カラム値が、参照する関係テーブルのレコードのオブジェクトＩＤであり、かつ、クラスの集合型属性に対応する集合型カラムを他の単純型カラムとは別に管理できるように付加されることを特徴とする請求項１２に記載のデータベースのデータ構造。
請求項１４に記載のデータベースのデータ構造を利用した文書データのデータ構造であって、
文書データに含まれるタグ要素が上記関係テーブルのカラムに割り当てられ、
タグ要素が複数のタグ要素を含むとき、カラム値が、参照する関係テーブルのレコードのオブジェクトＩＤであるとともに、
文書の木グラフ表現におけるノードのメタ情報が上記関係テーブルのカラムに割り当てられることを特徴とする文書データのデータ構造。
上記拡張可能配列がチャンク化拡張可能配列であり、かつ、上記区画がチャンク化拡張可能配列のチャンクであって、
上記データベース記憶部に、
上記区画位置情報である、関係テーブルの各レコードに対応するチャンク化拡張可能配列の要素が属するチャンクのチャンク番号と、上記区画内オフセットであるチャンク内オフセットとの２項組表現をキー値として登録した、上記要素位置Ｂ＋木データである第２のＢ＋木データとともに、
関係テーブルのカラム値ごとに設けられ、該カラム値からチャンク化拡張可能配列のチャンクサブ配列情報の位置を表す添字とチャンク内での添字の２項組表現に変換するための第１のＢ＋木データと、
チャンクサブ配列情報としてチャンク配列拡張の時間的順序を登録した経歴値テーブルと、
チャンクサブ配列内のチャンクの番号を計算する１次関数の係数からなる係数ベクトルをチャンクサブ配列ごとに登録した係数テーブルと、
カラム値の情報として、拡張可能配列の添字ごとに対応する該カラム値またはカラム値が格納されている記憶領域へのポインタからなるカラム値テーブルと、
該カラム値を持つすべてのレコード数を登録したレコード数テーブルと、を格納したことを特徴とする請求項１に記載のデータベース装置。
検索要求に対して、上記第２のＢ＋木データより検索要求に対応するチャンク番号とチャンク内オフセットとの２項組を検索するレコード検索手段を具備することを特徴とする請求項１６に記載のデータベース装置。
新たなカラム値を持つレコードを挿入するとき、上記第１のＢ＋木データにそのカラム値を登録して、チャンク化拡張可能配列を拡張し、上記経歴値テーブルおよび上記係数テーブルに経歴値および係数をそれぞれ登録し、上記レコード数テーブルに初期値を登録するとともに、当該拡張可能配列の要素が所属するチャンクのチャンク番号とチャンク内オフセットとの２項組表現をキー値として上記第２のＢ＋木データへ挿入するレコード挿入手段を具備することを特徴とする請求項１６に記載のデータベース装置。
１つのレコードを削除するとき、チャンク番号とチャンク内オフセットの２項組を上記第２のＢ＋木データから削除するとともに、上記レコード数テーブルのレコード数を１だけ減算するレコード削除手段を具備することを特徴とする請求項１６に記載のデータベース装置。
上記レコード検索手段が検索したチャンク番号とチャンク内オフセットの２項組をチャンク化拡張可能配列の各次元の添字に変換し、該変換した添字に従ってあらかじめカラム値テーブル格納されているカラム値あるいはカラム値が格納されている記憶領域へのポインタを取得するキー値−カラム値逆変換手段をさらに具備することを特徴とする請求項１７に記載のデータベース装置。
上記データベース記憶部は、さらに、カラム値の重複が起こり得ないカラムである一意キーと、チャンク化拡張可能配列の要素の属するチャンク番号およびチャンク内オフセットの２項組表現とを登録した一意キーテーブルを格納しており、かつ、
上記一意キーテーブルに基づいて、一意キーと一意キー以外のカラム値との対応関係を管理する一意キー管理手段を具備することを特徴とする請求項１６に記載のデータベース装置。
関係テーブルを２つのカラム集合の組に分割し、分割したそれぞれの関係テーブルについて、チャンク化拡張可能配列を構成し、チャンク番号およびチャンク内オフセットの２項組表現をそれぞれ登録した第２のＢ＋木データを生成するとともに、元の関係テーブルが持つ１個もしくは複数個の一意キーの値と、分割したそれぞれの関係テーブルに対応する上記第２のＢ＋木データに格納されているチャンク番号およびチャンク内オフセットの２項組表現とを登録した一意キーテーブルを生成する垂直分割管理手段をさらに具備することを特徴とする請求項２１に記載のデータベース装置。
関係テーブルを用いたデータベース装置におけるデータベースの管理方法であって、
上記データベース装置は、
データベース記憶部に、
関係テーブルのカラム値ごとに設けられ、該カラム値からチャンク化拡張可能配列のチャンクサブ配列情報の位置を表す添字とチャンク内での添字の２項組表現に変換するための第１のＢ＋木データと、
関係テーブルの各レコードに対応するチャンク化拡張可能配列の要素が属するチャンクのチャンク番号とチャンク内オフセットの２項組表現をキー値として登録した第２のＢ＋木データと、
チャンクサブ配列情報としてチャンク配列拡張の時間的順序を登録した経歴値テーブルと、
チャンクサブ配列内のチャンクの番号を計算する１次関数の係数からなる係数ベクトルをチャンクサブ配列ごとに登録した係数テーブルと、
カラム値の情報として、拡張可能配列の添字ごとに対応する該カラム値またはカラム値が格納されている記憶領域へのポインタからなるカラム値テーブルと、
該カラム値を持つすべてのレコード数を登録したレコード数テーブルと、を格納しており、
検索要求に対して、上記第２のＢ＋木データより検索要求に対応するチャンク番号とチャンク内オフセットとの２項組を検索することを特徴とするデータベースの管理方法。
関係テーブルを用いたデータベース装置におけるデータベースの管理方法であって、
上記データベース装置は、
データベース記憶部に、
関係テーブルのカラム値ごとに設けられ、該カラム値からチャンク化拡張可能配列のチャンクサブ配列情報の位置を表す添字とチャンク内での添字の２項組表現に変換するための第１のＢ＋木データと、
関係テーブルの各レコードに対応するチャンク化拡張可能配列の要素が属するチャンクのチャンク番号とチャンク内オフセットの２項組表現をキー値として登録した第２のＢ＋木データと、
チャンクサブ配列情報としてチャンク配列拡張の時間的順序を登録した経歴値テーブルと、
チャンクサブ配列内のチャンクの番号を計算する１次関数の係数からなる係数ベクトルをチャンクサブ配列ごとに登録した係数テーブルと、
カラム値の情報として、拡張可能配列の添字ごとに対応する該カラム値またはカラム値が格納されている記憶領域へのポインタからなるカラム値テーブルと、
該カラム値を持つすべてのレコード数を登録したレコード数テーブルと、を格納しており、
新たなカラム値を持つレコードを挿入するとき、上記第１のＢ＋木データにそのカラム値を登録して、チャンク化拡張可能配列を拡張し、上記経歴値テーブルおよび上記係数テーブルに経歴値および係数をそれぞれ登録し、上記レコード数テーブルに初期値を登録するとともに、当該拡張可能配列の要素が所属するチャンクのチャンク番号とチャンク内オフセットとの２項組表現をキー値として上記第２のＢ＋木データへ挿入することを特徴とするデータベースの管理方法。
関係テーブルを用いたデータベース装置におけるデータベースの管理方法であって、
上記データベース装置は、
データベース記憶部に、
関係テーブルのカラム値ごとに設けられ、該カラム値からチャンク化拡張可能配列のチャンクサブ配列情報の位置を表す添字とチャンク内での添字の２項組表現に変換するための第１のＢ＋木データと、
関係テーブルの各レコードに対応するチャンク化拡張可能配列の要素が属するチャンクのチャンク番号とチャンク内オフセットの２項組表現をキー値として登録した第２のＢ＋木データと、
チャンクサブ配列情報としてチャンク配列拡張の時間的順序を登録した経歴値テーブルと、
チャンクサブ配列内のチャンクの番号を計算する１次関数の係数からなる係数ベクトルをチャンクサブ配列ごとに登録した係数テーブルと、
カラム値の情報として、拡張可能配列の添字ごとに対応する該カラム値またはカラム値が格納されている記憶領域へのポインタからなるカラム値テーブルと、
該カラム値を持つすべてのレコード数を登録したレコード数テーブルと、を格納しており、
１つのレコードを削除するとき、チャンク番号とチャンク内オフセットの２項組を上記第２のＢ＋木データから削除するとともに、上記レコード数テーブルのレコード数を１だけ減算することを特徴とするデータベースの管理方法。
関係テーブルを用いたデータベースのデータ構造であって、
関係テーブルのカラム値ごとに設けられ、該カラム値からチャンク化拡張可能配列のチャンクサブ配列情報の位置を表す添字とチャンク内での添字の２項組表現に変換するための第１のＢ＋木データと、
関係テーブルの各レコードに対応するチャンク化拡張可能配列の要素が属するチャンクのチャンク番号とチャンク内オフセットの２項組表現をキー値として登録した第２のＢ＋木データと、
チャンクサブ配列情報としてチャンク配列拡張の時間的順序を登録した経歴値テーブルと、
チャンクサブ配列内のチャンクの番号を計算する１次関数の係数からなる係数ベクトルをチャンクサブ配列ごとに登録した係数テーブルと、
カラム値の情報として、拡張可能配列の添字ごとに対応するカラム値またはカラム値が格納されている記憶領域へのポインタからなるカラム値テーブルと、
該カラム値を持つすべてのレコード数を登録したレコード数テーブルと、よりなることを特徴とするデータベースのデータ構造。
請求項３から８、１７から２２のいずれか１項に記載のデータベース装置を動作させるデータベース管理プログラムであって、コンピュータを上記の各手段として機能させるためのデータベース管理プログラム。
請求項２７に記載のデータベース管理プログラムを記録したコンピュータ読み取り可能な記録媒体。