JP3959027B2 - 情報システムのためのデータ構造 - Google Patents

Description

【０００１】
本発明は、データシステムなど情報記憶システムのためのデータ構造に関する。コンピュータをベースとするデータ記憶システムの場合、メモリやハードディスクドライブなど何らかの媒体にデータが記憶され、そこからデータが取り出される。公知のシステムの場合、データはたとえばリレーショナルモデルをベースとした構造をもつようなデータ構造に格納される。公知のデータ記憶システムを使用して格納されているデータは、記憶させて探索し取り出すことができるけれども、取り出しに要する時間がかなりかかる可能性があり、複合的なクエリの倍には殊に相当な時間がかかる可能性がある。さらに効率的なデータモデルを構成するのは手間がかかり、したがってコストが嵩む。データベースレイアウトまたはデータモデルが定義されてしまうと、あとから改変するのは実装が困難であり、それによってたいていはパフォーマンスの損失が引き起こされてしまう。
【０００２】
データベースに対するクエリにかかるレスポンスタイムをスピードアップするためにクエリオプティマイザが使用されることが多く、これはたとえばルールベースのオプティマイザであるかまたはコストベースのオプティマイザである。ルールベースのオプティマイザはまえもって定義されたルールセットを使用する。コストベースのオプティマイザはクエリを構成するデータに関する統計的な情報を使用し、これは各クエリコンポーネントのセレクティビティ（selectivity）を推定し、最もセレクティブなコンポーネントに沿ったサーチパスを最初に導くことによって行われる。公知のオプティマイザを使用すると平均レスポンスタイムを短くすることができるけれども、どのような特定のクエリでも最適化するオプティマイザに対するニーズが存在する。
【０００３】
本発明の１つの課題は、セットアップならびにメンテナンスの簡単なデータ記憶システムを提供することにある。本発明の別の課題は、データの高速な検索を可能にするデータ記憶システムを提供することにある。さらに本発明の別の課題は、クエリを決定論的に最適化できるデータ記憶システムを提供することにある。
【０００４】
これらの課題は、請求項１記載のデータベースシステムを提供することによって解決される。
【０００５】
請求項に記載されている構造を利用すればデータベースを簡単に構築することができる一方、変更が簡単に実施される。
【０００６】
さらに本発明によれば請求項６記載のクエリオプティマイザが提供される。１つのクエリセクション内で見つけられた目下のデータ要素の決定により、特定のクエリに対する目下のクエリパスの決定論的分析を行うことができる。したがって各クエリのための最良のパスを決定することができ、その結果、各クエリのためのクエリタイムが最適化される。
【０００７】
その他の特徴ならびに利点は、本発明の実施形態に関する以下の説明を通して明らかにさせるつもりである。従属請求項には有利な実施形態が示されている。
【０００８】
図面の簡単な説明
図１は、本発明によるシステムの階層構造を概略的に示す図である。
【０００９】
図２は、本発明によるデータ形式を示す図である。
【００１０】
図３は、アンカおよびインフォセルInfoCellをもつインフォタイプInfoType構造を示す図である。
【００１１】
図４は、本発明による２つのInfoCellを示す図である。
【００１２】
図５は、バイナリツリーコンフィグレーションにおける３つのInfoTypeを備えたインフォクラスタInfoClusterを示す図である。
【００１３】
図６は、InfoType識別番号により記憶されたバイナリツリーとしてInfoCourseを示す図である。
【００１４】
図７は、４次元でリンクされたInfoCell要素のサブ構造を表された内容のテーブルとともに示す図である。
【００１５】
図８は、ダブルリンクセルフリングdouble link Self Ringをリングの要素カウンタの番号とともに示す図である。
【００１６】
図９は、多次元構造の要素カウンタに対する番号を示す図である。
【００１７】
図１０は、テーブルを６次元構造として示す図である。
【００１８】
図１１は、インフォブリッジInfoBridgeをカスケードした様子を示す図である。
【００１９】
図１２は、８つのフラグをもつインフォブリッジInfoBridgeを示す図である。
【００２０】
図１３は、ツリー構造の一例を示す図である。
【００２１】
図１４は、図１３を簡単にした図である。
【００２２】
図１５は、第１の例を示す図である。
【００２３】
図１６は、第２の例を示す図である。
【００２４】
図１７は、第３の例を示す図である。
【００２５】
図１８は、図１７による例を示す図である。
【００２６】
図１９は、図１７による例を示す図である。
【００２７】
図２０は、図１７による例を示す図である。
【００２８】
図２１は、第４の例を示す図である。
【００２９】
図２２は、第５の例を示す図である。
【００３０】
図２３は、第６の例を示す図である。
【００３１】
詳細な説明
次に、本発明によるデータ記憶システムの実施形態の一例について説明する。本発明による実施形態の以下の説明はリレーショナルデータベースモデルに従いインプリメントされているが、本発明によるシステムは公知のリレーショナルデータベースアーキテクチャの枠内での利用に制限されるものではない。とはいうものの本発明は、主としてリレーショナルデータベースのルールに従ってインプリメントされる可能性がある。本発明の要素を公知のリレーショナルデータベース理論の用語に大雑把に当てはめると、以下のとおりとなる（本発明による定義を左側に示す）。
【００３２】
インフォシステム InfoSystem ← マネージメントシステム
インフォエリア InfoArea ← データベース
インフォクラスタ InfoCluster ← テーブル
インフォタイプ InfoType ← 属性
インフォコース InfoCourse ← データレコード
インフォセル InfoCell ← フィールド
インフォブリッジ ← 利用不可能
なお、本発明によるインフォブリッジInfoBridge（これについてはあとで説明する）に該当する用語は、リレーショナルデータベースフィールド中には存在しない。
【００３３】
図１には、本発明によるデータベースシステムのスタティックな階層が示されている。このデータベースシステムの最上位レベルはインフォシステムInfoSystemのレベルである。この最上位レベルにから下に降りると、１つまたは複数のインフォエリアがインフォシステムInfoSystemにリンクされている。InfoSystemによりシステムに対し、そのオペレーティングに必要とされるアルゴリズムがランタイムに提供される。InfoSystemはリンク要素を介して何らかの個数のInfoAreaとリンクされており、このリンク要素を以下ではアンカanchorと称する。これらのInfoAreaはたとえばInfoSystemの論理ユニットを参照することができる。
【００３４】
各InfoAreaはリンク要素（これも以下ではアンカと称する）を介してインフォクラスタInfoClusterとリンクされている。他方、各InfoClusterはアンカのような個々のリンク要素を介して、少なくとも１つのインフォコースInfoCourseおよび少なくとも１つのインフォタイプInfoTypeとリンクされている。InfoTypeをテーブルの属性とみなすことができる。InfoCourseは常にInfoClusterにおいてスタートする。InfoCouserが、アドレッシングされたそのインフォセルInfoCell要素（これはテーブルのフィールドに相応する）とともにInfoCluster内でとどまっているならば、これはテーブルのレコードと同様である。
【００３５】
InfoCourseとInfoTypeの下にはInfoCellが示されている。これはこの階層構造において最下位レベルの要素である。InfoTypeのインスタンスに生成に応じてアンカが生成され、これはInfoCellタイプのインスタンスでもある。このアンカは後続のInfoCell要素の構造を表す機能をもっている（図２参照）。アンカはInfoCell情報キャリアとして７つのポインタを有しており、これについてはあとで説明する。
【００３６】
InfoAreaよりも下位のレベルすなわちInfoCluster, InfoCourse, InfoType, InfoCellをインプリメントするために、図２に示されている本発明のデータ要素が用いられる。データ要素は概略的にアンカとして示されており、これには複数のポインタが設けられている。この例ではデータ要素は３つのポインタペアと１つの単独のポインタを有している。図２に示されている初期状態ではすべてのポインタはアンカを指している。この初期状態は考えられる得るリング構造のうち最も単純なものである。この構造中のすべてのポインタは有効なアドレスをもっており、未定義のポインタ（ヌルポインタ）が生じる状況が回避される。
【００３７】
第１のポインタペアには参照符号LVRとRVR（それぞれLeft Vertical Ring, Right Vertical Ring）が付されており、第２のポインタペアには参照符号LHR, RHR（それぞれLeft Horizontal Ring, Right Horizontal Ring）が、第３のポインタペアには参照符号LSR, RSR（それぞれLeft Self Ring, Right Self Ring）が、さらに単独のポインタにはＩＦ（InFormation bridge）が付されている。ポインタLSR, RSR, IFは基本的にオプションである。
【００３８】
図７にはテーブルＡが示されており、このテーブルには名前と年齢と体重に関するデータが含まれている。このテーブルに対しInfoClusterが生成される。さらに３つのInfoTypeが生成され、これらはそれぞれ名前と年齢と体重を表す。
【００３９】
図３には、InfoTypeのインプリメントのために使用されるデータ要素が示されている。Infotypeのセマンティックな情報はデータ型（この例では"INTEGER"）、指標（この例では「年齢」）等から成る。InfoTypeはInfoTypeに対応づけられたアンカである。このアンカはそのＲＶＲポインタによって、目下の情報キャリアすなわちInfoCellを指している。InfoCellは上述のようにデータシステム内で最下位レベルのエンティティである。InfoCellは図３に示されているような情報を保持しており、この例では「年齢」を３０としてINTEGER型で保持している。
【００４０】
InfoCellには上述のようにLVR/RVRポインタペアが設けられている。図３に示されているようにInfoCellのRVRポインタはアンカを指しており、LVRポインタもアンカを指している。したがってアンカのリングコンフィギュレーションが維持されている。
【００４１】
図４には、別のInfoCellをデータ構造に加える様子が示されている。ここでは（値「２５」をもつ）InfoCellが最初のInfoCellの後ろでLVRリング中に挿入される。InfoCellのLVRとRVRポインタは、閉じたリングが維持されるようアンカを参照している。
【００４２】
InfoCellの編成順序はそれらの値に左右される。値が小さければそのInfoCellはLVR側におかれ、さもなければRVR側におかれる。このやり方は従来技術においてバイナリツリーの構築として知られている。有利にはバイナリツリーは、周知のバランスツリーまたはAVLツリーの手法として組織される。この種のツリーによりツリー構造内のレベル数が最小化され、アクセスタイムが最短になる。有利にはデータシステム内のすべてのツリー構造は使用中ダイナミックにバランスがとられ、それにより最適なアクセスタイムが保証される。
【００４３】
図５には、テーブルＡのすべてのInfoTypeがデータ構造に入れられた場合に得られる構造が示されている。全体として、年齢と名前と体重という３つのInfoTypeが存在している。なお、個々のツリーにおける最後の要素各々の最終ポインタは示されていない。InfoTypeのアンカ各々の下にはInfoCellがバイナリツリーとして組織されている。InfoClusterはアンカを指しており、このアンカ自体は最初のInfoTypeを指している。さらにこのInfoTypeは他の２つのInfoTypeを指している。各InfoTypeはアンカを指している。アンカはマーカの付加的な機能を有しており、これをブレークサインまたはリターンサインとしてアクセスやクエリのプロセスにより用いることができる。
【００４４】
テーブルのインプリメンテーションを完成させるためには、各InfoType間の関係を作成しなければならない。この目的でInfoCourseが導入される。図６にはInfoCourseが示されており、これにはテーブルにおける４番目の行に関するデータが含まれている。ここではLHRポインタとRHRポインタが用いられる。最終ポインタは再びInfoCourseのアンカに戻り、これによってリング構造が維持される。なお、InfoCourseは、InfoTypeのＩＤ番号によりソートされたバイナリツリーも形成する。InfoTypeのＩＤ番号はユニークであり、整数値が用いられる。
【００４５】
図７には、テーブルＡに関してInfoCourseのパスがすべて示されている（たとえばポインタを使用してインプリメントされる）。この場合、すべてのInfoCellはトップセクションにおかれ、これには個々のInfoTypeが設けられ、それによってLHR/RHRポインタを介したInfoCourseのバイナリツリーコンフィギュレーションが組織される。
【００４６】
１つのInfoTypeのためのツリー構築中、InfoCellのインスタンスが複数のオカレンス（occurrence）をもつときには以下のメカニズムが使用されて、ツリー構造中に同様のインスタンスが２つ以上出現するのが回避される。図９には、名前Bobが３つのオカレンスをもち名前Alexが２つのオカレンスをもつ事例が示されている。LSR/RSRのポインタペアを用いて後続の複数のエントリがリング状に加えられ、これはリングがデータ構造の要素レベル内にとどまることからここではセルフリングself ringと呼ばれる。最後に加えられた要素はリングのマスタ要素となる。この場合、マスタ要素はツリー構造の一部分である。各要素の下方のセクションに示されているように、リング内における目下の全体要素数はマスタ要素内に格納される。他のもっと古い要素はヒストリックな値（すなわちもっと少ない値）をもつ。なぜならばこれらの値はリングの新しい要素の挿入によっても更新されないからである。このことは実際的見地からみて利点をもち、それによれば数字によってその要素がリング内で古い方なのか新しい方なのかが表される。このことが役立つのは、殊に実践においてリング中をナビゲートするときにいっそう新しいデータがいっそう頻繁にアクセスされるときである。ある要素がその周囲にセルフリングが形成されないことを表すリング値０をもつときは、図８も参照されたい。この情報はサーチクエリの高速化に利用できる。
【００４７】
他の特徴は、InfoCell各々に属性として要素カウンタが与えられていることである。要素カウンタは図９中、要素の隣りに示されたボックス内で表されている。要素カウンタは、ポインタLVR/RVRおよびLSR/RSRを介して到達可能な要素の総数として定義されており、これはセルフリング内の要素数＋（もしあれば）個々の要素の下のツリー中の要素数である。セルフリング内の要素数はマスタ要素自体において既知であり、ツリー下方の要素は単純に、LVRポインタとRVRポインタにより指示された要素の要素カウンタから得られる。基本的に、関連する要素の個数を求めるためにツリー全体を実際に通り抜ける必要がない。要素カウンタとセルフリングカウンタは最初にデータ構造のマウント中に求められ、要素が追加または削除されたときにも求められる。この種の要素カウンタは、その要素について可能性のあるサーチが行われるときにサーチされるべき潜在的な要素数あるいはそのようなサーチに必要とされるリソースを表している。基本的に片方向のポインタセルフリングだけを使用すれば十分であるけれども、双方向のポインタリングを使用すると付加的な利点が得られる。
【００４８】
図１０にはテーブルＢが６次元構造として示されている。すべてのカウンタおよび識別番号が各ノードごとに示されている。ここではアンカ要素やアンカに対応づけられたポインタ（たとえば閉ループ構造を成すポインタ）は示されていない。
【００４９】
InfoTypeの構造はまえもって定義されたセットの機能をもつことができるので、いかなるInfoCourseにも含まれていないInfoTypeツリー中に要素が現れる可能性がある。１つのInfoType中の１つの要素が２つ以上のInfoCourseにより必要とされているならば、各InfoCourseごとに付加的なInfoTypeを生成して構造が有限にとどまるようにするのが有利である。本発明によるデータ要素のポインタＩＦを、どのようなオブジェクトタイプのインスタンス各々のためにも使うことができる。ポインタＩＦはどのようなタイプのインスタンスでも指すことができる。それが指し示すインスタンスのタイプはコンテキストまたは指標によって決定できる。これはたとえば（図１２に示されているような）フラグのリストであってもよいし、（理論から知られているような）各ノードごとの条件グラフであってもよい。ポインタはあまり多くのビットを要求しないのでいっそう効率的であるのに対し、条件グラフの利点はデータ構造向上のためのセマンティックな情報を含めることができる点にある。
【００５０】
ＩＦポインタを利用してどのようなインスタンスに対してもリンクを確立することができる。これはたとえばInfoBridgeを介して行うことができる。本発明によるInfoBridgeは、Ｙアダプタのように見えるリンク要素であり、これはカスケードすることができる（図１１）。オプションとしてInfoBridgeを双方向にすることができ、それにより基本構造を介してどのようなネットワークでも表現することができる。
【００５１】
ポインタＩＦはさらに別の用途をもつ。データ構造内のオペレーションによって非常に多くのデータ要素に対し同時に変更が行われる。しかしミクロレベルでは、すべての変更はシーケンシャルに行われる。たとえばオペレーションはコミット作業またはロールバックによって実行される（これらのオペレーションはSAP R/3 systemによって知られている）。つまりこの場合、トランザクションが完全に完了してしまうまでは（変更されていない）元の値と目的となる（変更された）値の双方が一時的に記憶装置内に保持されていなければならない。InfoBridgeは双方の値を互いに結びつけるために用いられる。図１２にはその例が示されている。上方のInfoBridgeは２つのInfoCellを相互にリンクしている。１つのInfoBridgeを加えたときにすべての機能が維持され、図１２に破線で示されているようにカスケードにより増やすことができる。ここではＹコンフィギュレーションをもつ１つのコネクタだけしか示されていないが他のコンフィギュレーションを使用してもよく、たとえば３つよりも多くのコネクションをもつコンフィギュレーションを使用してもよい。
【００５２】
また、図示されている例によればInfoCourseはテーブルに表されているデータレコード定義に係わるものであるが、InfoCourseの使用がこれに限定されるわけではない。InfoCourseはたとえば、様々なInfoClusterそれどころかInfoAreaにおける制約のないInfoTypeにわたって拡張することができる。このようにして参照一貫性を保証することもできる。たとえばテストテーブルの値をアプリケーションテーブルにコピーする必要がない（これは公知のデータベースにとっては一般的である）。その代わりに個々のInfoCellに対し、テストテーブルとして使用されるInfoClusterのInfoCellへのポインタが値として与えられることになる。
【００５３】
最短推定ランタイムをもつクエリルートを求めるためにクエリオプティマイザが使用される。
【００５４】
上述のシステムのインプリメンテーションは、公知のどのような適切な方式やプログラミング言語を使用しても行える。ここで有用であるのは、インプリメンテーションの言語がポインタをサポートすることである。プログラミング言語がオブジェクト指向であればさらに役に立つけれども、それは本質的なことではない。たいていのインプリメンテーションでは一時的な要素をもつ付加コントロール構造が必要とされるが、そのようなインプリメンテーションの詳細は知られており、当業者の能力範囲の及ぶところである。本発明の実験的なインプリメンテーションはＣ＋＋でプログラミングしたが、この言語はポインタおよびオブジェクトならびにオブジェクトクラスを使えるという付加的な利点をもっている。
【００５５】
本発明をたとえばランダムアクセスメモリ（ＲＡＭ）にインプリメントすることができ、そこではアドレスをランダムにアクセスできる。ランダムアクセスメモリの使用により得られる利点はさらに、データ構造に対する変更によってもどのようなかたちにせよ効率に作用が及ぼされないことでもある。本発明は有利にはランダムアクセスメモリにインプリメントされるけれども、インプリメンテーションがこの形態に限定されるわけではなく、記憶装置における別のインプリメンテーションも可能である。
【００５６】
例
以下の例では、InfoCellに対しどのようなアクセスが行われるかが示されている。例示のためだけに、１つのInfotypeに属するInfoCellwが使用される。図１３には、もっと大きいデータセットのうちの一部分を成す構造が示されている。
【００５７】
この構造中のデータ要素をアクセスするためにリングポインタ構造が使用され、これにはリング（LVR/RVR）に戻るポインタとセルフリングとが含まれている。図１３ではポインタは小さいアンカシンボルによって表されている。図１４には、図１３の構造がその基礎を成すバイナリツリー構造の関係によって示されており、これは複数の同一の要素がないとした事例である。以下ではサーチクエリのいくつかの例について示すことにする。
【００５８】
例１：クエリ（key = 54）
目的はキー５４をもつデータ要素を見つけることである。サーチはポジション１からスタートし（図１５に矢印１で示す）、そこは図１３に示されているアンカのすぐ後である。その後はバイナリツリーにおけるサーチと同様であり、InfoCellを順々に巡り、つまりツリーを下に降りていく。ここでは連続するInfoCellが矢印１〜５で表されている。矢印５によって個々の要素が見つけられる。
【００５９】
InfoCellには他のInfoCellと同様、ポインタペアLHR, RHRが設けられている。InfoCellに隣接するセマンティック情報からInfoCourseを得ることができる。InfoCourseポインタもリングツリーとして組織されているので、InfoCourseの開始アンカに必ず到達できる。この開始アンカからInfoCourse構造内のすべての要素に到達できる。パフォーマンスをさらに高めるため、このInfoCourseアンカをダイレクトに指示する付加的なポインタを各InfoCellに加えることができる。このポインタを用いれば、このアンカに到達するためにInfoCourseツリーをくまなく通って降りていく必要がない。
【００６０】
ある値（たとえば図１５の矢印６のところに示す５３）を挿入する目的で、ポイント６に到達するために上述のものと同じ方法が用いられ、このポイント６のところに新たなInfoCellが加えられる。InfoCellの付加後、必要であればバイナリツリーのバランスをとるためにソートしなおすことができる。このようなリソート手法は従来技術でよく知られている。
【００６１】
例２：クエリ（key ＜ 20）
この例ではクエリは、ツリーのうちハッチングされた部分集合をみつけるということであり（図１６）、その部分集合は条件キー＜２０を満たすものである。やはりサーチはポジション１から始められ、（前述のとおり公知の技術を使用して）ポジション３の末端までツリーが下に向かって辿られる。なお、ここではツリーの構造上、ツリーのこの末端より下のすべての要素は上述の条件を満たすものである。ツリーにおけるこのセクションの要素数は（ツリーの下位のセクションを通ってサーチする必要なく）既知である。それというのもInfoCell 10には要素カウンタ（x1）指標が設けられているからであり、これによっていくつの要素がツリーのこのセクションに続くかが精確に伝えられる。
【００６２】
例３：クエリ（key ＜ 28）
この例（図１７）では、データベース構造のサーチのためどのようにしてヒット数を求めることができるかを示す。ツリーにおけるサーチはポジション１からスタートし、クエリ規準を満たすポジション２へ向かう。しかし要素カウンタx1をそのまま使うことはできない。それというのもそこには規準を満たさないセルも含まれているからである（つまり３０と３５）。パスはポジション２からポジション３へと続き（図１８）、このポジションで要素カウンタｙ１がみつけられる。このポジションからパスはさらにポジション４へと続き、そこにおいて要素カウンタｘ２がみつけられる（図１９）。ここでサーチは完了し、みつかった要素カウンタx1, y1, x2をそれぞれ加算および減算することにより、クエリキー（＜２８）に対する正確なヒット数を計算することができる。これによってセルのターゲットグループを表すハッチングエリア内のセル数が得られる。このようにかなり僅かな回数のステップでツリー構造を１つのパスを降りていきながら、クエリにより生じるヒット数が決定論的に求められ、これによりセルの精確な個数が得られる。
【００６３】
与えられたクエリに対するヒット数の情報をベースとして、サーチオプティマイザは実状に基づきサーチプランをたてることができる。
【００６４】
例４：クエリ（key ＞ 10）
図２１には例３で行ったのと同じ論理分析が別の例に関して示されており、ここではクエリはキー＞１０である。ポジション１からサーチがスタートし、このポジションでただちにハッチングエリアとして示す第１の結果が生じる。ついでサーチはポジション２に進み、ここでは第２のハッチングエリアが求められる。その後、サーチはポジション３で終わる。ここでは右側のパス中のすべてのセルを（ポジション３自体のセル１０を除いて）考慮に入れる必要がある。クエリキーが＞＝であったならば、このセルも考慮されたはずである。前述の例と同じやり方でヒット数が計算され、つまり考慮すべきか否かに応じて要素カウンタを加算および減算することによって計算が行われる。
【００６５】
例５：クエリ（key between 24 and 54）
図２２に示されているクエリによれば、ヒット数を求めるためツリー構造を通り抜けて２つのサーチが必要とされる。ツリーは４０で始まるので、左右の分岐両方をサーチしなければならず、つまり詳しくいうと、２４という小さい方の値をもつ左側の分岐と、５４という大きい方の値をもつ右側の分岐の両方である。その結果、クエリの規準を満たすセルから成る円で囲まれた集合が識別される。択一的にクエリを２つの基本クエリ（key ＞= 24 and key ＜= 54）に分けてもよいが、結果は同じである。
【００６６】
例６：アクセスパスの最適化
この例ではいっそう複雑なサーチが示されており、さらにここではある特定のクエリに対するヒット数を求める上述の方法を利用した最適化方法も示す。
【００６７】
この例では、
key＿1 ＜ 28 and key＿2 ＞= value＿2 and key＿3 ＜ value＿3
という複合クエリ規準を使う。このような複合ステートメントを実行するため本発明によるオプティマイザは、クエリの各セクションにおいてどれだけ多くのヒットが得られるかを求める。このヒット数に基づきオプティマイザは、最小ヒット数のクエリセクションをまずはじめに処理するようにし、それよりも多いヒット数のクエリセクションはそのあとで処理しようとする。
【００６８】
クエリの各セクションごとのヒット数を求めるため、上述の例で示したようにセクションごとに１回ツリーをサーチする必要がある。
【００６９】
代案として、すでにみつけられたツリー中のノードの開始アドレスを記憶することができる。（要素カウンタのような）それらの開始アドレスのもつ情報に基づき、クエリのサブセクションのためにツリーの一部分をサーチする必要がない。なぜならばすでに記憶されている情報からそれを導き出せるからである。
【００７０】
クエリの最初のセクションは図１７に示されている例にマッチする。この例ではポジション２に到達すると、ガイド型のオブジェクトの一時的なインスタンスが生成され、これによりポジション２のアドレスが記憶される。さらに反復値Itが生成され（これは図２３と同様）、これはサブツリー内の目下の有効なセルの個数を記憶する。この値Itを、サブツリーを辿るアルゴリズムに対する最終基準としてあとで用いることができる。これはセルの値に対しサーチ規準を比較する役割を果たす。それというのもこのツリーセクション内のすべての有効なセルを辿った後、この最終基準に達するからである。Itは整数型であるので、ロングキャラクタチェーンとなるであろうセルの目下の値の比較よりも高速である。
【００７１】
図１９によればポジション４（２５）において明確であるのは、規準（key＿１ ＜ 28）がオプティマイザにより最初の規準としてあとで使われるのであれば、まだ辿らなければならないさらに別のツリーが存在することである。この目的でさらに別のガイドが導入され、これによりセル２５の開始アドレスと反復値Itが記憶され、この事例ではこの値はx2と同様である。
【００７２】
非常に大規模なツリー構造を用いて、有効なヒットを含む多くのサブツリーを１回辿る間に識別することができる。この種のサブツリーのトップ要素各々について、開始アドレスと要素のIt値を含むガイドが生成される。すべてのガイドはリンクされた１つの線形リストを成しており、これが個々の規準に加えられる。
【００７３】
ＡＮＤチェーンのすべてのパートがそれらヒット数（Ｍ）についてサーチされ、オプティマイザが最小ヒット数の選択基準部分を選んだ後、オプティマイザは有効なセルをもつツリーをダイレクトにアクセスするためにガイドの線形リストを使うことができる。規準の他の部分に対する線形リストは廃棄されるが、それによっても処理時間が増すわけではない。
【００７４】
本発明のオプティマイザによれば、サーチ規準の個々の部分によって得られるヒット数の正確な決定に基づきサーチパスが求められる。このようにサーチパスを求めることで最も最適な選択が常に得られる。
【図面の簡単な説明】
【図１】 本発明によるシステムの階層構造を概略的に示す図である。
【図２】 本発明によるデータ形式を示す図である。
【図３】 アンカおよびインフォセルInfoCellをもつインフォタイプInfoType構造を示す図である。
【図４】 本発明による２つのInfoCellを示す図である。
【図５】 バイナリツリーコンフィグレーションにおける３つのInfoTypeを備えたインフォクラスタInfoClusterを示す図である。
【図６】 InfoType識別番号により記憶されたバイナリツリーとしてInfoCourseを示す図である。
【図７】 ４次元でリンクされたInfoCell要素のサブ構造を表された内容のテーブルとともに示す図である。
【図８】 ダブルリンクセルフリングdouble link Self Ringをリングの要素カウンタの番号とともに示す図である。
【図９】 多次元構造の要素カウンタに対する番号を示す図である。
【図１０】 テーブルを６次元構造として示す図である。
【図１１】 インフォブリッジInfoBridgeをカスケードした様子を示す図である。
【図１２】 ８つのフラグをもつインフォブリッジInfoBridgeを示す図である。
【図１３】 ツリー構造の一例を示す図である。
【図１４】 図１３を簡単にした図である。
【図１５】 第１の例を示す図である。
【図１６】 第２の例を示す図である。
【図１７】 第３の例を示す図である。
【図１８】 図１７による例を示す図である。
【図１９】 図１７による例を示す図である。
【図２０】 図１７による例を示す図である。
【図２１】 第４の例を示す図である。
【図２２】 第５の例を示す図である。
【図２３】 第６の例を示す図である。

Claims (8)

1. データの記憶およびアクセスのためにデータベースインデックスツリー構造を形成するコンピュータシステムにおいて、
   第１のタイプ（InfoCluster）の少なくとも１つのデータ要素が設けられており、
   該データ要素には、データベースの属性エントリを表す第２のタイプ（InfoType）のデータ要素（ InfoCell ）と、該第２のタイプ（InfoType）のデータ要素に対応づけられておりデータレコードを表す第３のタイプ（InfoCourse）のデータ要素が対応づけられており、
   前記第２のタイプ（InfoType）のデータ要素は、複数の属性ツリー構造内に配置されており、各属性ツリー構造には、前記第２のタイプ（ InfoType ）である１つのデータベース属性のデータ要素がソートされた順序で含まれており、各属性ツリー構造には、前記第２のタイプ（ InfoType ）のデータ要素をリンクするポインタのセット（ LVR, RVR, LSR, RSR, IF ）が含まれており、
   前記第３のタイプ（InfoCourse）のデータ要素は１つのデータレコードツリー構造内に配置されており、
   前記第３のタイプ（ InfoCourse ）のデータ要素ごとに、該第３のタイプ（ InfoCourse ）の対応するデータ要素により表されるデータレコードに属する前記第２のタイプ（ InfoType ）のデータ要素（ InfoCell ）が、該第２のタイプ（ InfoType ）のデータ要素の識別番号（ ID ）によりソートされて前記１つのデータレコードツリー構造内に配置されており、
   １つの属性ツリー構造内に存在する前記第２のタイプ（ InfoType ）のすべてのデータ要素は同一の識別番号（ ID ）を有しており、
   前記データレコードツリー構造は、別のポインタセット（ＬＨＲ，ＲＨＲ）を有しており、該別のポインタセットにより、前記第３のタイプ（ InfoCourse ）の対応するデータ要素により表されるデータレコードに属する第２のタイプ（ InfoType ）のデータ要素がリンクされることを特徴とする、
   データの記憶およびアクセスのためにデータベースインデックスツリー構造を形成するコンピュータシステム。
2. ツリー構造の終端データ要素はリンク要素を介して少なくとも個々のツリー構造の始端データ要素とリンクされている、請求項１記載のコンピュータシステム。
3. 前記第２のタイプ（InfoType）の同様のデータ要素が複数出現した場合、該データ要素は、リンク要素を介して相互にリンクされたデータ要素の集合をもつ１つのセルフリング内に配置されており、該集合における１つのデータ要素はそのまま個々のツリー構造の一部分である、請求項１または２記載のコンピュータシステム。
4. １つのツリーのデータ要素には、ツリー構造中で個々の要素の下に配置されたデータ要素数を表す数が設けられている、請求項１から３のいずれか１項記載のコンピュータシステム。
5. 第１のタイプのデータ要素と第２のタイプのデータ要素との間のノードは第３のタイプ（InfoCourse）の要素により形成される、請求項１から４のいずれか１項記載のコンピュータシステム。
6. 第１のポインタペア（LSR, RSR）と第２のポインタペア（LHR, RHR）と第３のポインタペア（LVR, RVR）が設けられており、
   前記第１のポインタペア（ LSR, RSR ）は、同様の要素を１つのリング構造に含めるために用いられ、
   前記第２のポインタペア（ LHR, RHR ）は、ある要素を隣接ツリーとリンクするために用いられ、
   前記第３のポインタペア（ LVR, RVR ）は、同じタイプの要素を包含する１つのツリー構造内で各要素をリンクするために用いられる、
   請求項１から５のいずれか１項記載のコンピュータシステム。
7. IFポインタ（IF）が設けられており、該ＩＦポインタ（ＩＦ）はツリー構造内の他の何らかのインスタンスとリンクするために用いられる、請求項６記載のコンピュータシステム。
8. コンピュータシステムを用いてデータベースクエリを最適化する方法において、
   前記コンピュータシステムにより、１つのサーチ規準を複数のクエリセクションに分解するステップが設けられており、
   １つのクエリセクションは、属性を表すデータタイプ（InfoType）のデータ要素（InfoCell）の集合を表し、
   該データ要素（InfoCell）は、前記データタイプ（InfoType）のデータ要素が配置されている属性ツリー構造内でポインタを介してリンクされており、
   別のデータタイプ（InfoCourse）のデータ要素は、前記データタイプ（InfoType）のデータ要素と対応づけられたデータレコードを表し、
   該別のデータタイプ（InfoCourse）のデータ要素は別のデータレコードツリー構造内に配置されており、
   該別のデータタイプ（InfoCourse）のデータ要素ごとに、前記別のデータタイプ（InfoCourse）の対応するデータ要素により表されるデータレコードに属する前記属性を表すデータタイプ（InfoType）のデータ要素（InfoCell）は、前記属性を表すデータタイプ（InfoType）のデータ要素の識別番号（ＩＤ）によりソートされて前記別のデータレコードツリー構造内に配置されており、
   １つの属性ツリー構造におけるデータタイプ（InfoType）のすべてのデータ要素は同じ識別番号（ＩＤ）を有しており、
   前記別のデータレコードツリー構造は別のポインタセット（LHR, RHR）を有しており、該別のポインタセット（LHR, RHR）により、前記別のデータタイプ（InfoCourse）の対応するデータ要素により表されるデータレコードに属する前記属性を表す前記タイプ（InfoType）のデータ要素（InfoCell）がリンクされ、
   前記コンピュータシステムの計算手段により、分解された各クエリセクションごとに目下のデータベース構造において前記サーチ規準を満たす要素数を表すヒット数を求めるステップと、
   該コンピュータシステムの計算手段により、各クエリセクションごとに求められた前記ヒット数に従い、最短ランタイムをもつサーチパスを選択するステップとを有することを特徴とする、
   データベースクエリの最適化方法。

Images