JP2005521953A - リレーショナルデータベースをクエリーする方法および装置 - Google Patents

Abstract

本発明は、クエリーがリレーショナルデータベースの少なくとも１つのテーブルに関係する、リレーショナルデータベース管理システム（ＲＤＢＭＳ）を備えるリレーショナルデータベースに関係するクエリーを評価する方法を提供し、この方法は、前記クエリーを評価するためのゲートウェイテーブルとしてテーブルを決定することと、クエリーされるべきテーブル内の１つまたは複数のエントリに関係している前記ゲートウェイテーブルの１つまたは複数の一意識別子を検索することと、前記ゲートウェイテーブルの前記検索された一意識別子に関係しているクエリーされるべきテーブルから情報を検索することと、前記検索された情報に関係して前記ゲートウェイテーブルの検索されたプライマリキーを含む結果セットを提供することとを含む。本発明は、さらに、関係するデータ処理システムおよびプログラムを提供する。

Description

本発明は、リレーショナルデータベースに関するクエリーを評価する方法と、これに関係した装置およびプログラムとに関する。

バイオインフォマティックス(bioinfomatics)における主要な目標は、生物学的情報が迅速に、効果的に、かつ、完全に検索されることを可能にする探索ツールを提供することである。現在は、生物学的データを記憶する巨大なデータベースが存在する。しかし、これとは別に、幾つかのより小さいデータベースと、例えば、科学刊行物における発表のような、データベースのようには構造化されておらずに単層ファイルとしてある電子データとが存在する。したがって、バイオインフォマティックスにおける探索ツールは、様々なソースからのデータを組み合わせなければならないことが多い。ユーザがほぼ即時的に画面上で結果を得ることを望むので、この点で時間が極めて重要である。

ＳＲＳクエリー言語およびパッケージが、こうした探索ツールの構築における強力なツールであることが証明されている。ＳＲＳは、様々なソースからの情報を組み合わせることを可能にする。ＳＲＳの原理がＷＯ ００／４１０９４に開示されている。基本的には、ＳＲＳは２段階のプロセスとして働く。第１の段階ではデータソース中のエントリが識別され、第２の段階ではパーサ(parser)によって抽出される。この着想は単層ファイルに関しては十分に有効であるが、リレーショナルデータベースに対する適用は、大きなデータベースにおいては、例えばテーブルのキーのような識別子に関係する情報の抽出に比較的長い時間を要することがあるので、問題を生じさせる。これは、一般的に、要求されている情報が、互いに直接的にリンクしていない可能性がある複数の異なるテーブルから収集されなければならないということを原因とする。現行のリレーショナルデータベース管理システムは、クエリーに関係しているすべてのテーブルに関して結合テーブル(joined table)を形成するように動作する。結合テーブルのサイズが基本的に個別のテーブルのロー(row)のサイズの積なので、このことは直ちに大きな結果セット(result set)を生じさせ、および、したがって、これらの結果セットを評価するための長時間の処理時間をもたらす。

本発明の目的は、クエリーがより容易に取り扱われることが可能であると共に理解がより容易であり、および、単層ファイルのような他のデータソースから情報を抽出するプロセスに適合している方法を提供するようにクエリーがより迅速かつ特別に処理されることが可能である、リレーショナルデータベースにおいてクエリーを行うための方法と装置とプログラムとを提供することである。

本発明では、この目的は、少なくとも１つのリレーショナルデータベース管理システム（ＲＤＢＭＳ）を備えるリレーショナルデータベースに関係するクエリーを評価する方法によって実現され、前記クエリーは、前記リレーショナルデータベースの少なくとも１つのテーブルに関係し、前記方法は、前記クエリーを評価するためのゲートウェイテーブルとして前記リレーショナルデータベースのテーブルを決定することと、クエリーされるべきテーブル内の１つまたは複数のエントリに関係している前記ゲートウェイテーブルの１つまたは複数の一意識別子(unique identifiers)を前記ＲＤＢＭＳによって検索することと、前記ＲＤＢＭＳを使用することと、前記ゲートウェイテーブルの前記検索された一意識別子に関係しているクエリーされるべき１つまたは複数のテーブルから情報を検索することと、結果を前記クエリーに提供することとを含む。この結果は、前記検索された情報に対する関係においてゲートウェイテーブルの検索されたプライマリキーを含む、結果テーブルの従来の意味での結果セット、すなわち、こうした従来の結果テーブルから得られることが可能なクエリーの結果を含むオブジェクトとすることができる。

本発明では、クエリーの評価に対して開始点を形成する「ゲートウェイテーブル」が選択される。ある意味では、ゲートウェイテーブルは、クエリーの評価に対するエントリポイントすなわち「ゲートウェイ」としての役割を果たす。本発明では、前記クエリーの実行依頼の前に、または、前記クエリーの評価の最中に、ある１つのテーブルがゲートウェイテーブルとして指定され、このことは、当然のことながら、このテーブルがクエリーにおいて参照されるテーブルに関係しているならば、１つまたは複数の一意識別子を検索する段階がこのテーブルに関して行われるということを意味する。テーブルをゲートウェイテーブルとして指定することは、例えば、システムまたはデータベースの設定の一部として、または、クエリーの実行依頼前のユーザ設定によって、前もって行われてもよい。しかし、本発明は、さらに、クエリーの評価プロセスの最中に、適切な判定基準にしたがってテーブルがゲートウェイテーブルとして決定されるということと、上述の段階がこのテーブルに関してはその後で行われるということを可能にする。この好ましい実施形態では、上述の一意識別子はゲートウェイテーブルのプライマリキーすなわち一意的なインデックスである。しかし、本発明は、さらに、前記一意識別子が、異なるカラムのインデックスの組合せであり、および、特定の例では、リレーショナルデータベース管理システムにおける（定義による）一意識別子であるテーブルのローのインデックスのすべての組合せであるということを可能にすることができる。

本発明は、前記ゲートウェイテーブルの前記１つまたは複数の一意識別子を検索する時に、第１の段階で、１つまたは複数の予め決められたインデックスが検索されるということを可能にすることができる。この１つまたは複数のインデックスが一意的な仕方でテーブルのロー(row)を指定しないということが判明する場合には、一意識別子が適切な手順によってこうしたインデックスから生成される。１つの手順が、前記インデックスの組合せが、クエリーされるべきテーブル内のエントリに関係しているローに関する一意識別子であるまで、前記初期段階で検索されたインデックスに対してインデックスを追加することであってもよい。場合によっては、これは、ローの全インデックスがその組合せに含まれるまで継続されてもよい。このようにして一意識別子が生成された後に、関係しているローがクエリーされるべきテーブル内の前記エントリに依然として関係するということが確認される。そうでない場合は、それぞれの識別子が廃棄される。この代わりに、例えば、前記初期段階で検索されたインデックスが実際にはゲートウェイテーブルの複数のローを指定する場合には、第１のローを続行するだけであり、それによって情報の潜在的な損失を許容するということが可能にされるだろう。

本発明は、前記リレーショナルデータベースが１つまたは複数の予め決められたハブテーブル(hub table)を含み、および、前記クエリーが前記リレーショナルデータベースの少なくとも１つのテーブルに関係し、前記方法は、クエリーされるべきテーブル内の１つまたは複数のエントリに関係しているハブテーブルの１つまたは複数の一意識別子を前記ＲＤＢＭＳによって検索することと、前記ＲＤＢＭＳを使用することと、前記ハブテーブルの前記検索された一意識別子に関係しているクエリーされるべきテーブルから情報を検索することと、例えば、前記検索された情報に関係して前記ハブの検索されたプライマリキーを含む結果セット（オブジェクトまたは結果テーブル）として、クエリーに対して結果を提供することとを含むということを可能にすることができる。

本発明は、１つまたは複数のライブラリが１つまたは複数のデータベース上で定義されるということを可能にすることができる。本明細書で使用されている通りの意味では、ライブラリは、互いにリンクし合っておりかつ必ずしも同一のデータベース内にある必要はないテーブルの集まりとして定義され、ハブテーブルとして定義されている１つのテーブルが確かに存在する。ライブラリ内の全テーブルはハブに直接的または間接的にリンクしている。したがって、ライブラリ内のあらゆるエントリがハブ内のエントリとそのハブに対する（直接的または間接的な）関係とを経由してアクセスされることが可能である。したがって、ハブテーブルはライブラリを表現するものと見なされることが可能である。すなわち、本発明の意味でのライブラリは、クエリーの評価のための１つの一意的なエントリポイントすなわちゲートウェイ、すなわち、前記単一のハブを常に有する。ライブラリが排他的に１つのデータベース上で定義される場合には、そのライブラリは限定されたデータベースと見なされてもよい。一方、第２のデータベースのテーブルがライブラリ内に含まれている場合には、このライブラリは、ある点で、データベースの拡張である。異なるライブラリが同一のテーブルを共有することもあり得る。本発明によるライブラリの着想を使用することによって、データベースの基礎的構造に影響を与えることなしにアプリケーション上の必要またはユーザの希望に適合させられることが可能な基礎的データベースよりも高いレベルで着想を定義することが可能である。

ライブラリの着想を使用することによって、ライブラリが複数のデータベース全体に及ぶ場合には、複数のデータベースにおけるクエリーが、各データベース内にハブを有することなしに行われることが可能だということが明らかである。この場合には、１つのデータベース内には１つのハブだけしか存在せず、すなわち、（定義によって前記データベースの１つの中に含まれている）ライブラリのハブだけしか存在しない。

したがって、データベースのハブまたはゲートウェイテーブルに対する参照が行われる時はいつも、このハブまたはゲートウェイテーブルが、前記データベース上または前記データベースを含む複数のデータベース上で定義されているライブラリのハブまたはゲートウェイテーブルであってよいということが理解されなければならない。ライブラリが基本的に基礎データベース上に重ねられているデータベース構造であるので、データベースにおけるクエリーまたはデータベースにおけるクエリーの評価に対して参照が行われる時にはいつも、反対に対する表示が与えられない限り、これが、必要に応じて変更を加えて、ライブラリにおけるクエリーに読み出す。

ハブテーブル（以下では「ハブ」とも呼ばれる）は、基本的に、前記データベースまたはライブラリにおけるクエリーを評価するための予め決められたゲートウェイテーブルである。規則として、クエリーは、探索可能なエンティティ内の関係エントリの完全セット、すなわち、テーブル内の一意的に識別されるエントリに関係しているあらゆるテーブル内の全情報、または、こうしたセットの一部分に関するものである。探索可能なエンティティがリレーショナルデータベースである場合には、前記関係エントリの完全セットは、前記データベース内の前記エントリに直接的または間接的にリンクしている全エントリを含む。（上述の意味で理解されるべき）ライブラリのようなデータベース上またはデータベース全体にわたってより高レベルのエンティティを定義することによって、関係エントリの完全セットは、前記ライブラリに含まれているテーブル内の一意的に識別されるエントリに直接的または間接的に関係している前記ライブラリ内の全エントリのセットである。多くの例では、テーブル内の特定のエントリに関係している全情報を提供することは望まれてもおらず必要とされてもいない。このような例では、クエリーがテーブルの特定のカラムまたは特定のテーブルに制限されるだろう。ＳＱＬ言語では、こうした選択は標準シンタックス(syntax)を使用して行われることが可能である。好ましい実施形態では、テーブルおよび／またはテーブルカラムの選択は、特定のクエリーをタイプ入力する前にユーザインタフェースの設定の一部として、ユーザまたは管理者によって予め決定されるであろう。ライブラリが単一のデータベース上で排他的に定義される場合には、ライブラリ内の関係エントリの完全セットがデータベース全体の関係エントリの完全セットの一部分であるであろう。このことは、データベース上のライブラリを定義することによって、クエリーされるべきテーブルおよびテーブルカラムとに関する限定が、このライブラリを参照するクエリーが実行依頼される時にデータベースの他のテーブルがクエリーされないように、すでに行われているということを意味する。しかし、ライブラリが２つ以上の異なるデータベースのテーブルを含むことがあるので、ライブラリ内の関係エントリの完全セットがデータベースの関連エントリの完全セットの中に完全には含まれていない可能性があるということが留意されなければならない。

大半の例では、ユーザによってタイプ入力されるクエリーは、そのクエリーの結果に含まれるべきデータを指定するクエリー条件から成るであろう。この説明のために、クエリー条件は、特定の要素が特定の指定されたデータフィールド内に存在しなければならないというクエリーの条件と見なされるであろう。リレーショナルデータベースに関しては、これは、特定のテーブル内の特定のエントリが指定された値を有するということを意味するであろう。単層ファイルの場合には、これは、例えば文字シーケンスのような特定のデータシーケンスが特定のデータフィールド内で発見されるということを意味するであろう。これはユーザが考えることであるが、クエリー条件は、このシステムによって処理されるクエリー全体を形成しない。結果を戻すために、このシステムは、例えば他のテーブル内の関連情報のような、前記クエリー条件に関係している情報が戻される追加の情報を必要とする。この追加の情報は、ユーザによって部分的または全体的に決定されることが可能な設定の中に含まれている。このシステムは、これらのクエリー条件とクエリーされるべきテーブルおよびカラムに関する予め決められた設定とに基づいて、ＲＤＢＭＳに実行依頼されるべき１つまたは複数のクエリーコマンドを生成するであろう。クエリー条件は、一般的に、選択されるべきカラムのローに対して条件を課す。こうした例では、本発明による方法は、クエリー条件に表現されている条件を満たすエントリを最初に捜索し、その次に、１つまたは複数のハブインデックスを戻すか、または、この好ましい実施形態では、ハブテーブルの一意識別子を戻すであろう。

本発明は、さらに、カラム内の全エントリがクエリーにおいて検索され、この場合にクエリーが特定のカラムに関係しているハブテーブルの一意識別子すべてを検索するということを可能にすることができる。

本発明は、前記クエリーが、１つまたは複数のデータベースまたはライブラリの関係エントリの完全セット、または、前記リレーショナルデータベースのこうした完全セットの予め決められた一部分に関するものであり、および、前記データベースまたはライブラリに関係している１つまたは複数のクエリー条件を含み、前記方法は、
− クエリー条件において指定されたエントリに関係しているゲートウェイテーブルを識別することと、
− クエリー条件に適合する前記エントリに関係している前記ゲートウェイテーブルの１つまたは複数の一意識別子を識別することと、
− 前記ゲートウェイテーブルの前記一意識別子に関係している関係エントリの完全セットまたはその完全セットの一部分を検索すること
とを含むということを可能にすることができる。

多くの例では、クエリーは異なるエンティティに関係し、例えば、２つのデータベースまたは２つのライブラリ、データベースまたはライブラリ、および、単層ファイル、または複数のデータベース、ライブラリおよび／または単層ファイルに関係する。同様に、クエリーが、同一のデータベースの異なるハブに関係している１つのデータベース内のテーブルに関係するということも可能である。こうした例のすべてでは、本発明は、その好ましい実施形態では、ハブに関係しているクエリーの部分、または、ライブラリまたはリレーショナルデータベース以外のエンティティの場合には、第２のエンティティの１つまたは複数のサブエンティティに関係しているクエリーの部分が別個に処理され、および、部分探索の結果が、例えばハブのプライマリキーのようなハブの一意識別子と他のエンティティの識別子との間の関係、および、場合によっては、複数のこうした識別子の間の関係を使用することによって組み合わされるということを可能にすることができる。単純な例では、ハブのどの一意識別子が別のハブのどの他の一意識別子またはどの識別子に関係するのかが決定され、および、関係する２つの部分クエリーの結果が組み合わされる。

本発明は、前記クエリーが、前記データベースの外側または前記クエリーに関係しているライブラリの外側の第２の探索可能なエンティティに少なくとも関係し、前記第２のエンティティは、そのサブエンティティを一意的に識別する少なくとも１つの識別子を各々が有するサブエンティティを含み、前記方法は、
− 前記クエリー、特に前記クエリーのクエリー条件に関係している、前記第２の探索可能なエンティティのサブエンティティの１つまたは複数の識別子を検索することと、
− 前記サブエンティティの前記検索された識別子に関係している前記リレーショナルデータベースまたはライブラリのハブの、例えばプライマリキーのような１つまたは複数の一意識別子を検索することと、
− 前記ハブの前記検索された一意識別子に関係している、関係エントリのセット、特に関係エントリの完全セットを検索することと、
− 前記第２のエンティティ内の検索された識別子によって識別されたサブエンティティから情報を検索することと、
− 前記第２の探索可能なエンティティと前記データベースまたはライブラリからの検索された情報を結果セットの形に組み合わせること
とを含むということを可能にすることができる。

これに加えて、または、代案として、本発明は、前記クエリーが、前記データベースの外側の、または、前記クエリーに関係しているライブラリの外側の、サブエンティティを含む少なくとも第２の探索可能なエンティティを含み、各サブエンティティは前記サブエンティティを一意的に指定する少なくとも１つの識別子を有し、前記方法は、
− 前記クエリー、特に前記クエリーのクエリー条件に関係している、エントリに関係している前記データベースまたはライブラリのハブの１つまたは複数の一意識別子を検索することと、
− 前記ハブの前記検索された一意識別子に関係している前記第２の探索可能なエンティティのサブエンティティの識別子を検索することと、
− 前記ハブの前記検索された一意識別子に関係している関係エントリのセットまたはこのセットの一部分を検索することと、
− 前記第２の探索可能なエンティティ内の検索された識別子によって識別された前記サブエンティティから情報を検索することと、
− 前記第２のエンティティと前記データベースまたはライブラリとから検索された情報を結果の形に組み合わせること
とを含むということを可能にすることができる。

この用途の意味における探索可能なエンティティは、データベース、ライブラリであってよく、および、その識別子が、ハブテーブルのプライマリキーまたは他の一意識別子であってよい。

本発明は、前記第２の探索可能なエンティティが第２のリレーショナルデータベースまたはライブラリであり、および、前記識別子は、前記第２のリレーショナルデータベースまたは第２のライブラリ内のハブテーブルのプライマリキーまたは別の一意識別子であり、前記サブエンティティがテーブル、リンクされたテーブルの組合せ、または、その一部分であるということを可能にすることができる。

本発明は、前記第２の探索可能なエンティティが単層ファイルの集まりであり、および、サブエンティティがこの集まりの中の単層ファイルであるということを可能にすることができる。

第２のエンティティの検索された識別子および／またはハブの検索された一意識別子に関係している情報を検索する段階は、第２のエンティティの識別子と１つまたは複数のハブの１つまたは複数の一意識別子との間の関係を検索する段階の前または後に行われてよい。しかし、本発明の好ましい実施形態では、クエリー条件に関係している１つのエンティティの識別子を最初に評価することによって進行し、その次に、その他のエンティティの関係した識別子を検索し、前記他の探索可能なエンティティ中の関連情報を検索するための開始点としてその他のエンティティのこれらの識別子を使用する。クエリー条件がデータベースまたはライブラリと第２の探索可能なエンティティとの両方に関係する場合には、最初に、第２のエンティティの識別子とクエリー条件に関係している１つまたは複数のハブの一意識別子とを検索することと、その次に、前記第２のエンティティの識別子と、すべてのクエリー条件（すなわち、データベースまたはライブラリに関係している条件と、第２の探索可能なエンティティに関係している条件の両方）に関係している前記ハブの識別子との組合せを設定することと、さらにその次に、クエリー条件のすべてに一致しているその組合せに関してだけ追加の情報を検索することとによって優先的に進行する。

本発明は、前記第２の探索可能エンティティの識別子と前記データベースまたはライブラリのハブの一意識別子との間の関係を検索する前記段階が、クエリー条件と合致しないハブの一意識別子と前記第２の探索可能エンティティの識別子との組合せを排除し、および、選択パラメータに合致する識別子の組合せに含まれている識別子に関係しているこうした追加の情報だけを検索する段階を含むということを可能にすることができる。

本発明は、クエリーが少なくとも２つのハブテーブルに関係しているテーブルに関係し、前記方法は、
− それぞれのハブに関係しているテーブルにおけるクエリー条件を満たすエントリに関係している１つまたは複数のハブテーブルの１つまたは複数の一意識別子を検索することと、
− 前記クエリー条件を満たすエントリに関係している前記検索された一意識別子に関係している１つまたは複数の他のハブそれぞれの一意識別子を検索することと、
− クエリーにしたがって前記ハブの前記検索された前記一意識別子に関係している関係エントリのセットまたはそのセットの予め決められた部分を検索することと、
− 前記ハブに関係している検索された情報を結果の形に組み合わせること
とを含むということを可能にすることができる。

１つまたは複数の他のハブそれぞれの一意識別子を検索することは、クエリー条件に関係している一意識別子を検索するという第１の段階ですでに発見されている一意識別子に関係してもよい。この場合には、一意識別子の組合せがクエリー条件に合致するかどうか、一貫性検査が行われる。

本発明は、前記ハブテーブルの一意識別子の間の関係を検索する前記段階が、クエリー条件に合致していないハブテーブルの一意識別子の組合せを排除し、および、探索パラメータに一致している一意識別子の組合せに含まれている少なくとも１つのハブの少なくとも１つの一意識別子に関係しているそうした追加の情報だけを検索する段階を含むということを可能にすることができる。

上述の２つのハブの少なくとも一方がライブラリのハブであってもよく、または、この２つのハブの両方がライブラリのハブであってもよい。さらに、前記２つのハブが同一のリレーショナルデータベース内のハブであるということが可能にされてもよい。これらは、このデータベース上で定義されている２つのライブラリのハブであることが可能であるが、必ずしもそうである必要はない。これらのハブの一方または両方がライブラリに関係していないハブであってもよい。

本発明は、さらに、関係エントリの前記セットまたはその一部分に関する各ハブに関する部分クエリーを行った後に、それぞれの結果が結合され、その後にクエリー条件との一致と場合によっては冗長性とに関して検査されるということを可能にすることができる。本発明は、さらに、オブジェクトが各々の部分結果に関して生成され、および、これらのオブジェクトが、クエリーの結果を得るためにさらに処理されるということを可能にすることができる。

本発明は、探索可能エンティティの別の識別子に関係している探索可能エンティティの識別子を検索する段階が、前記エンティティの識別子の間の事前設定された関係に基づいて行われるということを可能にすることができる。

本発明は、さらに、探索可能エンティティの別の識別子に関係している探索可能エンティティの識別子を検索する段階が、クエリーの実行中に動的に行われるということを可能にすることができる。本発明は、さらに、前記段階が、事前設定された関係に部分的に基づいて，および、部分的には動的に行われるということを可能にすることができる。

特に、データベースのハブと別の探索可能エンティティの識別子との間の関係は、静的リンクに基づいて、または、「実行中に(on the fly)」生成される動的リンクに基づいて確定されることが可能である。

クエリーで参照されかつハブの一意識別子に関係しているテーブルから情報を検索することが、大きなデータベースの場合には比較的緩慢なプロセスである可能性があり、これは現行のリレーショナルデータベースが動作する仕方を原因とする。複数のテーブルに関係するクエリーが例えばＳＱＬのような標準的な言語に基づいて入力される場合には、ＲＤＢＭＳは、基本的には全テーブルのデカルト積である関係する全テーブルの結合テーブルを形成する。結合テーブル内のデータセットの数は基本的に関係する個々のテーブルのローの数の積であり、このことは、結合テーブルのサイズが、クエリーに関係したさらに別のテーブルが増える毎に指数的に増大するということを意味する。このことは、関係したテーブルの数に応じてコンピュータの速度が急速に低下することを結果的にもたらす。

本発明の一側面では、このことは、どのテーブルが関係しているかをより正確に制御することによって減殺される。さらに詳しく説明するためには、ノード図としてのデータベースの表現を使用することが役立つ。ノード図は、データベースのグラフ的表現として理解されるべきであり、この図では、テーブルがノードとして表現され、および、テーブル間のリンクがノード間のラインとして表現されている。テーブル間のリンクは特に外来キーを介したリンクであってもよいが、これに限定されるものではない。ノード図の着想を使用することによって、データベースの２つのテーブルの間のあらゆる関係が、直接的である（この場合には２つのテーブルの間に直接的なリンクが存在する）か、または、間接的でありかつ１つまたは複数の中間ノードを通過する、２つのノードの間のパス(path)として視覚化されることが可能である。この着想を使用することによって、クエリーに関係するノードの数を制御することと、定義された数の中間テーブルが関係しているようにクエリーを公式化(formulate)することとが可能である。

本発明は、前記ゲートウェイテーブルの一意識別子に関係する情報を検索する前記段階を行う際に、テーブルがノードとして表現されかつテーブル間のリンクがノード間のラインとして表現されているデータベースのグラフ的表現において初期クエリーで参照されるテーブルにゲートウェイテーブルを連結する連結されたグラフを形成する、選択されたテーブルがクエリーされるということを可能にすることができる。

この着想のさらに別の改善点は、大きなクエリーが幾つかの中間的なクエリーに分割されることが可能であり、および、こうした中間的なクエリーは、それが関係している結合テーブルが著しくより小さいので、より容易に評価されることが可能であるということである。基本的に、前記グラフにおける２つのテーブルの間のリンクはジャンクション(junction)によって置き換えられる。２つのテーブルの間のジャンクションは、その２つのテーブルが同一のクエリーに関係していないが、一方のテーブルに関する先行のクエリーにおいて発見されたリンクに対するリンクキー(link key)すなわち別の入力の値が、第２のテーブルに関係するクエリーにおけるリンクキーのための入力として使用されるということを意味する。

本発明は、前記グラフ上でテーブルをクエリーする前記段階が連続した部分照会を行うことを含み、先行のクエリーの結果が後続のクエリー（優先的には前記グラフに沿ったその次のクエリー）のための入力として使用され、前記部分クエリーの第１のものがゲートウェイテーブルに関係し、および、この第１のクエリー以外のクエリーが初期クエリーで参照されるテーブルに関係するということを可能にすることができる。

本発明では、部分クエリーは、前記クエリーにおいて別のテーブルに直接リンクしているテーブルだけが部分クエリーに関係しているように、および、前記グラフ中の全テーブルが少なくとも１つのクエリーに関係しているように、部分クエリーが構造化される。

こうして、ハブテーブルからクエリーで参照されるテーブルへ至るクエリーの完全な連鎖が存在する。

テーブル間の関係が外来キー関係である時には、本発明は、先行クエリーの結果が後続のクエリーに関係しているテーブルの外来キーの値を含み、および、前記外来キーの前記値が後続のクエリーのための入力として使用されるということを可能にする。

部分クエリーの各々に関して、結果が、様々な部分クエリーの結果を初期クエリーの結果または部分結果に組み合わせるために後で検索されるように記憶される。説明を分かりやすくするために、本発明による方法が始まるクエリーを以下では「初期クエリー(initial query)」と呼ぶ。

好ましい実施形態では、先行のクエリーの入力は別として、別の部分クエリーでクエリーされていないテーブルだけがクエリーされるという意味で、クエリーは重複していない。

大きなクエリーを、後で結果が組み合わされる複数のより小さなクエリーに分割することは、より小さなクエリーがより小さな結果セットを戻すという利点を有する。グラフに沿った連続したテーブルが直接的にリンクされるので、連続したテーブルの間に直接的な結合箇所が存在し、このことは、一般的に単一の部分クエリーの結合テーブルが過剰に大きくはないということを意味する。どれだけ多くの連続したテーブルが部分クエリーに含まれるかは、テーブル間の関係に依存している。一般的には、結果セットが取り扱い易くかつその冗長性の排除が容易であるように、様々な部分クエリーが決定される。

本発明は、各々の部分クエリーの後に冗長性検査が結果テーブルに対して行われるということを可能にすることができる。本発明の一実施形態では、冗長性のないオブジェクトが、部分クエリーの結果セットに基づいて生成される。

記憶された結果は、さらに、さらに別の部分クエリーの結果に応じてフィルタリングされるか取り除かれることが可能である。例えば、第１の部分クエリーが、初期クエリーで参照されるテーブルに関係していないことが後で判明するキーの値を戻す場合には、前記結果に関係しておりかつ前記キーを含むオブジェクト中のデータが結果セットから取り除かれることが可能である。

本発明は、各部分クエリーが、互いにリンクし合っている１つまたは複数のテーブルに関係し、各部分クエリーが、以前に確定されたテーブルのキー（特にリンクキー）の値を入力として有するということを可能にすることができる。前記リンクキーは、前記複数のテーブルの中の１つまたは複数のテーブルを、前記部分クエリーに関係していない別のテーブルにリンクさせる。

前記リンクキー値は、先行の部分クエリーの結果としてすでに発見されていることがあり得る。さらに、入力として使用されるキー値は、先行段階ですでに求められているゲートウェイテーブルのキーの値であってもよい。このゲートウェイテーブルはクエリーの一部であり、そのキーの値が入力として使用されるという点で、その第１の部分クエリーは異なる。

本発明は、前記グラフが、少なくとも２つの他のノードに対するリンクを有する少なくとも１つのブランチノードを含み、初期クエリーで参照されるテーブルが前記ブランチノードから得られる別のブランチに関係しており、前記ブランチノード（ブランチテーブル）に対応するテーブルに関係する部分クエリーが行われ、および、入力としてブランチテーブルに関係する部分クエリーの結果を有する各ブランチ内に含まれる１つまたは複数のテーブルに関して、少なくとも１つの部分クエリーが行われるということを可能にすることができる。

各ブランチに関する連続した部分クエリーの各々は、初期クエリーにおいて参照されるテーブルに最終的に関係するさらに別の連続した部分クエリーを有することができる。各ブランチに関するクエリーの連鎖が、互いに連続しているか並行していると評価されることが可能である。

ブランチの１つが、例えばＳＯＬにおいてＷＨＥＲＥ文節で指定されるクエリー条件のような必要クエリー条件に関係しているテーブルに関係する場合には、このブランチが最初に優先的に評価され、それによって前記必要条件を満たすエントリに実際に関係しているブランチノードのキーが検索される。一般的に、これらのキーは、最初にそのブランチノードが「合格(pass)」した（すなわち、部分クエリーに関係した）時に検索されたキーよりも少ない。したがって、そのブランチノードに関係する第１の部分クエリーの結果は、そのブランチノードのこうしたキーだけを含むように縮小される。その次に、この縮小されたキー値セットが、その他のブランチに関係している１つまたは複数の部分クエリーのための入力として使用される。

２つ以上のブランチが必要クエリー条件に関係している場合には、さらに、以前に評価された前記ブランチノードのキーに基づいて各ブランチを別個に評価することによって進行することもできる。各ブランチの評価は、必要条件を満たすエントリに各々に関係しているブランチノードのキーを結果として戻す。関係している結果の結果的な処理では、どちらかの条件を満たすエントリに関係しているブランチノードのキーを含むエントリだけが保持される。

ある意味においては、ブランチテーブルは、多重クエリー(multiple queries)がハブテーブルに由来するので、ハブテーブルに類似している。実際に、大半の例では、ハブテーブルはブランチテーブルでもあるであろう。典型的な例が、データベースの図式的表現がスター(star)の中心にあるハブを有するスター形であるデータベースであろう。したがって、ブランチノードに由来するブランチを評価する方法が、同一のハブに由来する明瞭なグラフを評価する方法に類似していることが可能である。しかし、ハブテーブルとブランチテーブルとが異なる形で定義されているということが留意されなければならない。ハブテーブルとブランチテーブルの定義上の相違は、ハブテーブルは基本クエリーを評価するための予め決められたエントリポイントであり、必ずしもブランチを表すわけではないが、一方、ブランチテーブルは、初期クエリーの評価中に決定されるテーブルであってもよいということである。

本発明による方法は、
− 初期クエリーで参照されるテーブルに関係している１つまたは複数のハブを識別する段階と、
− 前記データベースの前記グラフ的表現において、少なくとも１つのハブに関して、好ましくはすべてのハブに関して、前記ハブに関係しておりかつ初期クエリーで参照される全テーブルに前記ハブを連結する最適のグラフを決定する段階と、
− 前記最適のグラフ上でクエリーを行う段階
とを含むことができる。

前記グラフ上で前記クエリーを評価することによって、前記最適のグラフに関して互いに連続しているテーブルに関係する連続した部分クエリーが行われるということが実現されることが可能である。

上述の最適のグラフは、最適化アルゴリズムによって決定されるグラフである。例えばＤｉｊｋｓｔｒａアルゴリズムのような、特定の点を連結する最適グラフを発見するための最適化アルゴリズムが、当分野で公知である。このグラフは、部分クエリーのシーケンスが解決されることが可能な速度に関して優先的に最適化される。１つの処理方法が、グラフ中のノードの間の各リンクに重みを割り当てることと、累積された重みに関して初期グラフが最適化されるまでその初期グラフを変化させることとである。この重みは距離関数(metric)として具体化されてもよく、したがって、この探索は、この距離関数による「最短」パスに関するものである。

クエリープロセスをカストマイズするためにノード図を使用するという着想と、大きなクエリーを幾つかのより小さい連続したクエリーに分割するという着想、特にジャンクションの着想は、予め決められたハブテーブルと前記ハブに関連したテーブルとに関係するクエリーの評価に限定されない。実際に、例えば、リレーショナルデータベースに関係するクエリーの場合に、上述したように、クエリーの評価のために開始点を形成し、および、そのクエリーに関係したテーブルに対するパスすなわちグラフがそれから形成されて評価されるゲートウェイテーブルが定義されることが可能なので、この着想は、ハブの概念とは無関係に使用されることが可能である。このゲートウェイテーブルは、ハブのように、静的であること、すなわち、予め決められていることは必ずしも必要ではないが、このゲートウェイテーブルとクエリーで参照されるテーブルとを連結するグラフが、例えば上述したアルゴリズムによって、評価プロセスの速度に関して最適化される仕方でクエリーを評価するプロセスにおいてさえ、このゲートウェイテーブルが特定のクエリーに関して選択されることも可能である。

例えば、この着想のさらに別の応用が、２つのデータベースの間のリンクの評価であってもよい。本発明の実施形態では、２つのデータベースの間の関係は、常に、その２つのデータベースのハブを通して確定される。こうした関係を確定するために、２つのデータベースの２つのテーブル（以下では、「リンキングテーブル(linking table)」と呼ばれる）の間の既存のリンクが、その２つのデータベースの２つのハブの間の動的リンクを与えるために使用されることが可能である。第１のデータベース中のハブテーブルとこのハブの特定の一意識別子とから開始して、第１のデータベース中のリンキングテーブルが発見され、および、前記ハブテーブルの前記リンキングテーブルに対する関係が、例えばそのデータベースのノード図を使用することによって確定される。ハブテーブルの前記一意識別子に関係付けられている前記リンキングテーブル中のエントリと、第２のデータベース中のリンキングテーブル内の関連したエントリとが決定される。その次に、前記第２のリンキングテーブルのエントリに関係した第２のデータベースのハブの一意識別子が決定される。この手順は、例えば関係したハブのすべてのプライマリキーに関して、前もって行われることも可能であり、この場合に、こうして発見されたハブのプライマリキーの間の関係が前もって静的に記憶されることが可能であるが、現時点では、クエリーの評価の最中にこれらの段階を動的に行うことが好ましい。ノード図の形のグラフとジャンクションという着想は、こうしたリンクを動的に実行するために適用されることが可能である。上述したように、リンキングテーブルを経由して２つのハブを連結するグラフが確定されることが可能であり（この場合に、異なるデータベースの２つのリンキングテーブルの間のリンクがデータベース中の通常のリンクのように扱われる）、および、第１のハブのプライマリキーまたは別の一意識別子の特定の値から開始して最終的に第２のハブに至る幾つかの連続したクエリーが行われて評価される。完全性の実現のために、混合タイプのリンクが使用されることも可能であり、この場合には、これらの段階の一部分が前もって行われ、および、これらの段階の一部分が動的に行われるということが指摘されなければならない。

本発明は、前記ゲートウェイテーブルの一意識別子を検索する前記段階が、
− 初期クエリーで参照されるテーブルを決定することと、
− テーブルがノードとして表現されかつテーブル間のリンクがノード間のラインとして表現されている前記データベースのグラフ的表現において、前記テーブルに連結されているゲートウェイテーブルを決定することと、
− 前記テーブルに関係付けられているゲートウェイテーブルの１つまたは複数のインデックス（特にプライマリキー）に関して前記データベースをクエリーすること
とを含むということを可能にすることができる。

本発明は、前記テーブルの１つまたは複数の特定のエントリがクエリー条件によって含意され、および、前記データベースが、前記エントリに関係している前記ゲートウェイテーブルの１つまたは複数のインデックスに関してクエリーされるということを可能にすることができる。

本発明は、前記グラフ的表現において、前記テーブルから前記ゲートウェイテーブルへのパスが確定され、および、前記インデックスに関する前記クエリーが、クエリーにおいて参照されるテーブルと（特定の場合には）そのテーブルの特定のエントリとから開始して、前記グラフにおけるテーブル間のリンクキーの値に関して前記グラフ内のノードに対応する全テーブルをクエリーすることによって行われるということを可能にすることができる。

本発明は、前記パスが予め決められた距離関数にしたがって前記テーブルと前記ゲートウェイテーブルとの間の最短パスとして選択されるということを可能にすることができる。

本発明は、前記パスが、前記ゲートウェイテーブルに関係しているテーブルから追加の情報を検索するための部分クエリーを決定するためのグラフの一部分であるかまたはこのグラフと同一であるということを可能にすることができる。

本発明は、ゲートウェイテーブルの同一のローに関係しておりかつデータベースをクエリーする前記段階によって決定されるインデックスまたはインデックスグループが、前記ゲートウェイテーブルのローを一意的に識別しない場合に、ゲートウェイテーブルの１つまたは複数のローに関する、前記インデックスに関係している一意識別子が決定されるということを可能にすることができる。

本発明は、初期クエリーを評価するために使用される部分クエリーが、前記評価のプロセス中に動的に、少なくとも部分的に、および、好ましくは完全に生成されるということを可能にすることができる。

本発明は、前記結果セットがオブジェクト指向表現の形で表現されるということを可能にすることができる。

本発明は、前記初期クエリーの結果がオブジェクトリレーショナルマッピング(object relational mapping)によって得られたオブジェクトとして表現されるということを可能にすることができる。この好ましい実施形態では、初期クエリーの評価プロセス中に行われる各部分クエリーの後に、オブジェクトリレーショナルマッピングによってオブジェクトが生成され、および、前記初期クエリーの結果を表現するオブジェクトが、部分クエリーに関係しているこれらのオブジェクトから得られる。一実施形態では、部分クエリーの結果から生成されるこの１つまたは複数のオブジェクトはＸＭＬで表現される。

本発明は、前記クエリーの前記評価がオブジェクトマネージャの制御下で行われ、および、前記オブジェクトマネージャはコンピュータシステムによって実行されるべきコマンドのシーケンスを含むということを可能にすることができる。

本発明は、前記オブジェクトマネージャが、クエリーされるべき１つまたは複数のデータベースのスキーマまたはそのスキーマの一部分を表現するオブジェクトを取り扱うということを可能にすることができる。

本発明は、前記オブジェクトマネージャが、動的に生成されて開始されるクラスを定義するということを可能にすることができる。

本発明は、さらに、リレーショナルデータベース管理システム（ＲＤＢＭＳ）を備えるリレーショナルデータベースに関係するクエリーの評価を制御するためのデータ処理システムを提供することができ、前記クエリーは前記リレーショナルデータベースの少なくとも１つのテーブルに関係し、
− 前記クエリーを評価するためのゲートウェイテーブルとしてテーブルを決定する手段と、
− クエリーされるべき１つまたは複数のテーブルとゲートウェイテーブルとの間の関係を確定する手段と、
− クエリーされるべきテーブル内の１つまたは複数のエントリに関係している前記ゲートウェイテーブルの１つまたは複数の一意識別子をＲＤＢＭＳが検索することを引き起こす手段と、
− 前記エントリの前記一意識別子に関係しているクエリーされるべきテーブルからＲＤＢＭＳが情報を検索することを引き起こす手段と、
− 前記検索された情報に対する関係においてゲートウェイテーブルの検索されたプライマリキーを含む結果セットすなわち結果オブジェクトであることが可能である結果を前記クエリーに対して提供するかまたは前記クエリーが提供されることを引き起こす手段
とを含む。

前記データ処理システムは、評価されるべきクエリーに関する予め決められたゲートウェイテーブルとして前記リレーショナルデータベース中の特定のテーブルを設定する手段を含んでもよい。

本発明によるデータ処理システムは、さらに別の実施形態では、１つまたは複数のデータ処理システムによって上述の通りの方法の実行を制御する手段を含んでよい。

本発明は、さらに、コンピュータまたはコンピュータシステム上でそのコンピュータプログラムが実行される時に、そのコンピュータまたはコンピュータシステムが、上述の通りの方法の諸段階を行うことを引き起こす、コンピュータプログラムとこのプログラムを含むコンピュータ可読記憶媒体とを提供する。

本発明の重要な側面では、本発明による方法は標準的なリレーショナルデータベース管理システムを使用し、および、このリレーショナルデータベース管理システムの外側でのクエリーの操作すべてを定義する。このことが高度の融通性を実現し、および、実際には、基礎となるシステムとは無関係に使用されることが可能なプラットホームを生じさせる。驚くべきことに、本発明の方法によって、特にグラフと結合点の着想にしたがってクエリーを評価することが、組合せ爆発(combinatorial explosion)が始まるように複数の１：Ｎ関係を有するテーブルが関係している場合に、約５０％の高さ、さらにはそれ以上の高さであることが可能な速度の著しい増加を結果的に生じさせることが可能である。

他の発明のさらに別の特徴と利点とが、図面に関連付けて説明される下記の本発明の実施形態の説明から明らかになるだろう。

本発明の一実施形態では、最初に、本発明が具体化されるデータベースの分析が行われる。基本的に、データベースのテーブル、カラム、カラムのタイプ、カラムのサイズ、カラムのインデックスと、キーとに関する情報が収集される。こうした情報を収集するための分析ツールが、当分野ですでに容易に入手可能である。例えば、ＪＤＢＣ(Java Database Connectivity)またはいずれかの他のＲＤＢＭＳ ＡＰＩが、こうした情報を収集するために使用できる。この情報から、データベースのノード図が、テーブル間のキー関係を使用する最小全域木の形で構成される。基本的に、任意のテーブルに関して、このテーブルを別のテーブルにリンクさせるキー（リンクキー）が探し求められ、および、こうしたリンクキーが存在する場合には、その２つのテーブルを表現する２つのノードの間にエッジが導入される。当然のことながら、実際のグラフが描かれるのではなく、こうしたグラフにマップするオブジェクト構造が構築されるということが理解されなければならない。説明を分かりやすくするために、本明細書ではグラフまたはグラフの要素が言及されるが、こうした言及が対応するデータ構造上のそれぞれの要素、関係、または、演算に関係することが意図されているということが理解される。

一般的には、ノードとエッジの両方が幾つかの属性を割り当てられる。幾つかの例を挙げると、例えば、最適のグラフを決定するために後で使用される各エッジに重みが割り当てられてもよく、または、エッジが１：１、１：Ｎ、Ｎ：Ｎ、もしくは、Ｎ：１の関係を表現するということを表示する属性が割り当てられてもよく、または、２つのテーブルの間の特定の関係におけるインデックスの存在を表現する属性が割り当てられてもよい。ノード（テーブル）に割り当てられる属性は、例えば、カラムの名称、カラムのサイズ、または、他の関連情報であってよい。

この点で、テーブル間の関係が必要とされる場合には、テーブル間の関係を手作業で追加または変更することができる。例えば、科学出版物の著者をリストするテーブルと、この著者テーブルに関係していないかまたは直接的には関係していない（電子メールアドレスのような）連絡詳細に関するテーブルとが存在する場合に、一方のテーブル内の著者の名前と、他方のテーブル内のこの著者の電子メールアドレスとの間の関係を手作業で挿入することが可能である。この関係は、データベースの変更として実施されてもよい。しかし、この関係は、この２つのテーブルの間の外部リンクとしてデータベースの外部で実行されることも可能である。

この段階の結果が、テーブルのスキーマを表現するオブジェクトである。このスキーマオブジェクトは、さらに別の使用のために記憶される。本明細書で説明されているこの例示的な実施形態はＳＲＳ環境を使用し、および、この環境下では、このスキーマオブジェクトは、例えばＳＲＳ Ｊａｖａ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）によって、ＳＲＳオブジェクトマネージャオブジェクトとして記憶されるだろう。オブジェクトマネージャは、ＳＲＳ下でクエリーの評価を制御するツールである。ＳＲＳクエリー言語の詳細については、例えばｈｔｔｐ：／／ｓｒｓ．ｅｂｉ．ａｃ．ｕｋを参照することができる。

さらに別の段階として、クエリーの評価においてテーブルに対するエントリポイントまたはゲートウェイとしての役割を果たすことになるハブテーブルが定義される。ハブに関する要件が、ハブが一意識別子を含むということ、すなわち、テーブル内のすべてのデータセットが識別子によって一意的に識別されることが可能であるということである。好ましくは、一意的なインデックスすなわちプライマリキーが一意識別子として使用されるが、例えばインデックスの一意的な組合せが使用されてもよい。基本的には、ハブとしてテーブルを定義することを結果的に生じさせることが可能な２つの考慮事項が存在する。一方の考慮事項は、ユーザ球(user sphere)から得られ、および、ユーザに対して有益であるクエリーにおけるフォーカスポイント(focus point)を提供することを求める。他方の考慮事項は、よりテクニカルであり、クエリーが最も効率的に行われることが可能な仕方でテーブルを定義することを求める。こうして、ハブテーブルは、関心の中心点である情報を表現するテーブルであることが可能である。テクニカルな視点から見ると、このハブテーブルは、クエリーされる可能性が高いテーブルであり、かつ、そのハブに関係するクエリーとこのテーブルとがＲＤＢＭＳによって最も迅速に評価されることが可能である仕方でそのテーブルに対してクエリーされるかまたは関係している可能性が高い他のテーブルに対して優先的に直接的にリンクさせられるテーブルであるはずである。例えば、どのテーブルがリレーショナルデータベースにおいて最も頻繁にクエリーされるか、および、テーブルのどの組合せが最も頻繁にクエリーされるかに関する統計量を確定することと、それにしたがってハブテーブルを選択することが考慮されてもよい。これら２つの考慮事項は、頻繁にクエリーされるテーブルが一般的にユーザにとって最重要な関心の対象であるテーブルでもあるので、互いに一致している可能性がある場合が多い。

関心の焦点がユーザに応じて変化することがある。１人のユーザが主として科学アプリケーションの著者に対して関心をもつことがある一方で、別のユーザは主として科学出版物における特定のキーワードに関心をもつが、その著者には関心がないか僅かしか関心がないという場合がある。したがって、本発明は、ユーザまたはデータベースマネージャが、ユーザ設定の一部分として、または、クエリーをタイプ入力する時にさえ、１つまたは複数のハブを定義することが可能であるということを可能にすることができる。２つ以上のハブが単一のデータベース内で定義可能であるということが留意されなければならない。このことは、大きなデータセットを含む特に大きなスキーマの場合に、性能を向上させるために使用されることが可能な例えばライブラリのようなより小さいサブストラクチャが形成されることを可能にするので、大きなデータベースにおいて有用であろう。データベース内の複数のハブを定義することを結果的にもたらす可能性がある別の理由が、結合してクエリーされることが知られているデータベース中のテーブルのクラスタ、または、異なるクラスタのテーブルに関する限り頻繁に互いに結合してクエリーされることがないことが知られているデータベース中のテーブルのクラスタが、このようにして定義されることが可能であるということである。このことは、後になって、多くの例においてクエリーされるべきハブとテーブルとの間に発生する可能性があるパスの数を制限し、および、こうしてアプリケーションの速度に寄与するであろう。ハブの定義は、ＳＲＳの下で、さらに別の目的を有する。ハブテーブルと一意識別子（例えば、プライマリキー）とをデータベースに対するエントリポイントに関する識別子として選択することによって、「ハブカラム(hub column)」を中心とすると見なされることが可能なデータ構造が実現され、このことは、データに対するアクセスが適切に定義された識別子を経由するということを意味する。このことは単層ファイルに対する類似性を成立させ、および、したがって、単層ファイルのために開発されたリレーショナルデータベースのためのＳＲＳ手順を使用することを可能にする。

ユーザがクエリーを入力する時には、そのユーザは、一般的に、自分が関心を持つキーワードを指定し、前記キーワードに関係した全情報を得るだけである。これらは完全なデータベースエントリであってよい。本発明の実施形態は、データベースのどのテーブルまたはどのカラムにユーザが関心を持っているかをそのユーザがグラフィカルユーザインタフェースにおいて指定することが可能であるということを実現することができる。これは、例えば、関心の対象である情報を表示するためにユーザが使用するティックボックス(tick box)を提供することによって実現することが可能である。要求された情報の範囲に関する追加の情報を、ユーザによって変更可能とすることができ、又は変更不可能とすることができないシステム設定の形で実行することも可能である。

この実施形態では、ユーザがクエリーをタイプ入力すると、システムが、情報を検索するためのＳＲＳによる標準的な手順と同様に、２段階のプロセスで動作する。第１の段階では、クエリー条件に関係するテーブル、例えばユーザによって要求されたキーワードを含むテーブルに関係するハブ（または、複数のハブ）の一意識別子が識別される。第２の段階では、システム設定またはユーザ入力によってそうした情報が指定されている程度に、クエリー条件に関係する全情報が検索される。

さらに明確に述べると、第１の段階では、クエリーの分析が、例えばＩＣＡＲＵＳパーサのようなパーサによって行われる。この分析の結果は、クエリーの階層的分析を表現し、かつ、高レベルにおいてデータベースを指定し、低レベルにおいて識別子フィールド（例えば、「著者」）を指定し、および、さらに低いレベルでは必要とされるキーワード（例えば、「Ｓｍｉｔｈ」）を指定する、バイナリツリーであることが可能である。その次に、このシステムは、このクエリーを、このシステム内に記憶されているデータベースのノードグラフにマップする。上述の例に関してさらに述べると、このシステムは、著者とその著者の名前が中に存在するはずであるカラムとを一意的に識別する特定のデータベース内のテーブルが存在するかどうかを検証する。こうしたテーブルが発見される場合には、このシステムは、ハブが前記ノード図中のこのテーブルに関係しているかどうか、および、どのハブが前記ノード図中のこのテーブルに関係しているかを検証する。その次に、このシステムは、クエリー条件に合致する前記テーブル内のエントリに関係しているハブテーブルの一意識別子（例えば、プライマリキー）に関するクエリーを生成する。ハブが少なくとも１つのパスによって入力クエリー中のテーブルに関係しているということが以前に確定されているので、そのエントリに関係しているハブの少なくとも１つの一意識別子が存在するはずである。

特定の実施形態では、このシステムは、クエリーされるべきテーブルからハブテーブルへの前記ノード図におけるパスを確定し、および、さらに、ハブの一意識別子をクエリーする際に、クエリー条件によって特定されたエントリに関係しているパス内の中間テーブル（ノード）のキーをクエリーする。このようにして、ハブの一意識別子を含むクエリー条件に合致するエントリに対する完全な関係セットが確定される。

クエリーに関係している１つのハブと１つのデータベースが存在すると仮定すると、このシステムは、その次に、クエリーで参照される全テーブルがノードとして現れるハブテーブルをその起源として有する前記ノード図の形のグラフすなわちツリーを確定する。このグラフがループのないグラフであることが好ましく、すなわち、ハブテーブルからクエリーにおいて参照されるあらゆるテーブルへのグラフに沿ったパスが１つだけしか存在しない。このグラフはハブから発する幾つかのブランチを有し、および、各ブランチはさらに別のブランチを含むことができる。理想的には、クエリーにおいて参照されるテーブル間のグラフの部分が最小でなければならない。しかし、これはグラフィカルな意味で理解されるべきではなく、むしろ、グラフ上で定義されかつ最適化アルゴリズムのために使用される距離関数の意味で理解されるべきである。例えば、互いに１：１の関係を有する複数の中間テーブルを含むグラフに対応するクエリーの評価が、グラフに沿った隣接するテーブルに対して１：Ｎの関係を有する単一の中間テーブルを有するグラフに対応するクエリーの評価よりも高速であることが可能であり、したがって関係した距離関数の意味で「より短い」ことが可能である。

最適グラフを確定した後に、第１の段階で識別された一意識別子の値に関係している初期クエリーにおいて参照されるテーブル内の全エントリに関してクエリーが行われるという点で、そのグラフが評価される。より明確に述べると、このシステムは、動的に生成されるクラスと部分ＳＱＬクエリーとから成るクエリーのためのオブジェクトプラン(object plan)を生成する。クラスと部分クエリーとを生成して具体化するために必要な情報が、異なる初期入力、すなわち、ハブ識別子に関する異なる値によってクエリーを実行するために必要とされる全情報を含む「ターナブル(turnable)」と呼ばれるデータ構造の形で保持される。このオブジェクトプランは、このクエリーのためのグラフに関して送られたスキーマと情報にしたがって生成され、および、最適化段階に関係することが可能である。このオブジェクトプランが生成され終わると、このオブジェクトプランに、初期情報、すなわち、ハブの一意識別子の値が与えられ、この後に実行される。クエリーの評価においては、このシステムは、ハブのプライマリキーに関係しているブランチ上のノードによって表現されたテーブルの全エントリの値に関してクエリーする。上記において指摘したように、ブランチに沿った多数のテーブルに関して、このことは、通常の仕方で行われる場合に、多数の偽りのエントリを含む大きな結果セットをもたらす可能性がある。本発明によって、ブランチに沿った部分グラフのテーブルに関係するクエリーは、グラフに沿ったテーブルの複数の連続したクエリーに分割され、この場合に、部分クエリーに関係しているテーブルのそれぞれの数は、ブランチ全体に関係するクエリーにおけるテーブルの数よりも少ない。先行のクエリーの結果が記憶されており、および、少なくとも１つの後続のクエリーのための入力として少なくとも部分的に使用されるので、これらの複数のクエリーは互いに連続している。

第１のクエリーの結果またはこの結果の一部分が結果的なクエリーに対する入力として使用されるという点でグラフに沿った２つの結果的なクエリーを連結するという方法は、本明細書で「ジャンクション(junction)」と呼ばれる。ジャンクションは、互いに直接連結されているグラフ中のノードに対応する２つのテーブルが、同一のクエリーには関係していないということを意味する。グラフに沿って直接的に連結されたノードに対応する各テーブル対に関して、その２つのテーブルの間の関係を確定するリンク（一般的にはリンクキー）が存在する。ジャンクションを使用することによって、リンクに対する入力、すなわち、一般的には、テーブルの１つに関係する先行のクエリーの評価において確定されたリンクキーの値が、その他のテーブルに関係する後続のクエリーのための入力として使用することができる。このことは、これら２つのテーブルに関係する結合点が存在せず、および、したがって、各部分クエリーの結果セットがより小さいということを意味する。

各部分クエリーの後に、先行段階で決定されたキーがグラフに沿った後続のテーブルに関係しているかどうかが決定される。関係していない場合には、それぞれのキー値が部分クエリーの結果から取り除かれる。これに加えて、冗長性および／または一貫性に関するフィルタリングおよび検査が、記憶の前に各部分クエリーの結果に関して行われることが可能である。冗長性検査は、一実施形態では、ハブから最も離れている現時点でクエリーされているグラフの部分に沿ったテーブルに関係しているカラムから開始する。同一のキー組合せがこのレベルで判明し、かつ、グラフのこの部分に沿ってＮ：１またはＮ：Ｎの関係が存在しない場合には、このことは冗長性が存在することを意味し、それぞれのエントリが取り除かれる。当然のことながら、冗長性検査の他の方法が適用されてもよい。小さな結果セットだけが各段階において生成されフィルタリングされるので、こうしたフィルタリングと冗長性検査等は、初期クエリーにおいて参照される全テーブルが一度にクエリーされる場合に結果的に得られる大きな結果セットの冗長性検査とフィルタリングに比べて、より迅速かつ効率的に行われることが可能である。冗長性および／または不一致が取り除かれた各部分クエリーの結果はオブジェクトとして記憶され、および、前記オブジェクトを検索するために必要とされる情報が記憶される。

グラフのブランチの評価において、さらに別のブランチが識別されると、各ブランチに沿った後続のクエリーが、互いに並行してまたは結果的な、別々に行われることが可能である。しかし、後続のブランチが比較的短い場合には、単一の部分クエリーにおいて、場合によってはブランチノードに対応するテーブルと共に、これらの後続のブランチに沿ってテーブルに関係することを選択してもよい。

この仕方でブランチを全体的に評価し終わった後に、部分クエリーの結果が組み合わされ、および、この場合も同様に、冗長性と一貫性に関して検査される。ハブを起点とする各ブランチを評価し終わった後では、ハブの一意識別子の値によって各々が識別された各ブランチに関する結果セットが得られている。その次に、異なるブランチに関する結果が組み合わされ、および、最終結果を得るために再び一貫性と冗長性とに関して検査される。

この結果は、オブジェクト構造、例えば、ＳＲＳのフレームワークで実現されるようなオブジェクト構造として表現される。部分クエリーの結果を表現するオブジェクト構造すなわちオブジェクトを定義することによって、動的クラス、すなわち、処理中に定義された後にオブジェクトを生成するために具体化されるクラスが使用されることが可能である。動的クラス自体は新しいものではなく、Ｓｍａｌｌｔａｌｋ言語において公知であるが、静的クラスまたはコンパイル時間クラス(compile time class)だけしか持たないＣ⁺⁺またはＪａｖａのような現在の言語では使用不可能である。以前のアプリケーションは動的クラスを使用しなかったが、ＳＲＳは動的クラスをサポートする。

本発明の重要な側面では、初期クエリーの評価中に生成されるすべてのクエリーは処理中に動的に生成される。他の実施形態では、頻繁に求められるハブとテーブルとの間の特定の部分グラフに沿った部分クエリーが前もって決定されて最適化されてもよい。テーブルの「クラスタ」を結果的に生じさせる特定の部分ルートを前もって決定することを予想することが可能であり、この場合には、要求されたテーブルへのルートの最終部分が（「オンザフライ(on the fly)で」）動的に決定される。さらに別の最適化方法が、データベースのグラフにおける幾つかの連結を無視することであってもよい。

上述の２段階のプロセスは、第１の段階においてクエリー条件を分解することと、第２の段階においてその結果に関係した情報を検索することと見なすことが可能である。本発明の一実施形態では、例えば、テーブルから抽出されるべき情報がクエリー条件に関係するエントリの値に制限されている場合には、クエリー条件の要件に合致するエントリを含むテーブルは、必ずしも前記第２の段階で行われる部分クエリーの一部分であるとは限らない。さらに、すでに第１の段階において、同一のテーブル内のクエリー条件によって指定されたエントリに関係している情報すべてを、関係したテーブルを後で「再訪問(revisit)」する必要がないように、抽出し記憶するということを可能にしてもよい。

上述の２段階プロセスは必要ではない。クエリー条件において参照されるテーブルから開始してハブの一意識別子を検索する時に、システムが追加の情報を検索する実施形態を想定することが可能である。例えば、ハブのプライマリキーに関するクエリーにおいて、このシステムが、関係したハブに対するクエリー条件によって指定されたエントリから開始するパスの中の中間テーブルのキーに関してもクエリーし、および、後続のクエリーにおいて、これらのキーに関係した情報を検索するということを可能にすることができる。

以前には、１つだけのハブまたは１つだけのデータベースまたはライブラリが関係している場合に関して説明を行った。

関係する複数のハブが存在する場合、例えば、複数のデータベースの場合に、単一のデータベース中の複数のライブラリまたは複数のハブが、初期クエリーが幾つかの部分クエリーに分割され、その部分クエリーの一部分がエンドポイントとしてハブを有するグラフに相当し、および、その部分クエリーの残り部分が１つだけのハブを含む形で取り扱われる。

２つのハブの場合には、第１の段階において、上述したように、クエリー条件に合致するエントリを有するテーブルに関係しているハブテーブルの一意識別子の値を検索することが可能であり、前記テーブルに対する前記関係はそれぞれの他のハブに関係しない。その次に、第２の段階において、単一のハブに排他的に関係しておりかつ他のどのハブにも関係していない（部分クエリーに対応する）部分グラフと、ハブを互いに連結する（１つまたは複数のさらに別の部分クエリーに対応する）１つまたは複数の部分グラフとから成る最適グラフを決定することができる。その次に、各ハブに排他的に関係している部分グラフが各ハブ毎に評価され、そのそれぞれの結果が記憶される。その次に、ハブの間の１つまたは複数の部分グラフに対応する１つまたは複数のクエリーが評価される。その次に、これらの部分グラフの結果がクエリー全体に関する結果を得るために組み合わされる。

これに対する代案として、２つのハブの間のリンクを評価するためにジャンクションの着想が適用され、および、２つのジャンクションをつなぐ部分グラフ内の各々のハブの後に、および、場合によってはこれらのグラフ内のさらに別の位置に、ジャンクションが導入されることが可能である。ハブをリンクさせるこれらの部分グラフを評価する時に、１つのハブの一意識別子の値から開始され、および、その他のハブの一意識別子の関係した値に関するクエリーが評価され、このことは、ハブとその関連のテーブルとに関係するクエリーの評価の場合に関して上述した仕方と同じ仕方で、特にジャンクションを使用して、行われることが可能である。この結果として、その他のハブの一意識別子の値のセットが得られ、この値のセットは、クエリー条件との一致に関して検査される。この処理方法は、クエリー条件が１つのハブに関係しているテーブルにだけ関係する場合に、特に有利である。この場合には、第１の段階においてこのハブのプライマリキーだけが検索されるであろうし、および、その他のハブは、第２のハブにつながるグラフ上の最終リンクの代わりに導入されたジャンクションを有するグラフ中のブランチポイントのように効果的に取り扱われる。

ハブの種類に応じて、および、ハブがシステム設定で予め定義されているか、または、ユーザによって選択されるかに応じて、単一のデータベース内の複数のハブのプライマリキーの間の予め決められた関係を記憶することが予想されてもよい。概念的には、このことは、上述の動的リンクの代わりに使用される２つのハブの間の直接リンクがノード図に導入されることを意味するであろう。

予想できる別の可能性が、この手順の第１の段階において、すべてのクエリー条件に関係する１つのクエリーにおけるすべてのハブのプライマリキーを検索し、それによってプライマリキーの適切な組合せを得ることである。これは、特にハブ間に直接リンク（特に１：１リンク）が存在する場合に実用的な処理方法であり得る。

２つ以上のデータベースが関係している場合が、複数のハブの場合と同様の仕方で処理されることが可能である。説明を分かりやすくするために、各データベースが１つだけのハブを含み、かつ、各データベースにおいて１つずつ、データベースがリンキングテーブルを経由して互いにリンクしていると仮定すると、２つのリンクテーブルを経由した２つのデータベースの間のリンクがノード図における通常のエッジと見なされることが可能である。この形で２つのデータベースを表現する場合には、概念的に、および、本発明によるクエリーを評価する方法に関する限り、単一のデータベース内の２つのハブの場合との相違は僅かであるにすぎない。すなわち、上述したとおりにクエリー条件に基づいてハブの関係した一意識別子を検索した後に、その２つのデータベースのハブとクエリーで参照される他のあらゆるテーブルとに関係する２つのデータベースによってグラフが決定される。このグラフは、一方のデータベース内のハブに排他的に関係する部分グラフと、他方のデータベースのハブに排他的に関係している第２のグラフと、前記第１のデータベースのハブを前記第２のデータベースに連結しかつ前記２つのリンキングテーブルを経由して延びる部分グラフとを含む。リンキングテーブルが必ずしもハブテーブルであるとは限らないということが指摘されなければならない。

この場合も同様に、クエリーの評価は上述したクエリーの評価に類似している。第１および第２のハブに関係している部分クエリーが評価され、および、３つの部分グラフの間のジャンクションが配置され、上述の仕方でその２つのハブの間の経路が評価される。その２つのハブの間のグラフを評価する際に、その２つのハブの間に直接リンクがない場合にはジャンクションの着想が再び使用されることが可能だということが指摘されなければならない。２つのハブの場合に、一方のハブから他方のハブにノード図を通る最適パスを決定し、特定のノードの間にジャンクションを配置し、別々に評価される部分クエリーをこのように定義し、この結果が、その２つのハブを連結するこの部分グラフに関する部分結果を与えるために最終的に互いに組み合わされ、その次に、この部分結果が、それぞれのハブに関係する残りの２つの部分グラフの結果と組み合わされる。

クエリー条件が一方のデータベースだけに関係し、かつ、第２のデータベースだけが、前記クエリー条件に合致するエントリに関係している情報を得るために必要とされる場合には、単一のデータベース内の２つのハブの場合に関して上述したように、クエリー条件のエントリに関係している第１のデータベースのハブのプライマリキーを検索し、その次に、他方のデータベース内のハブに対する直接リンクを評価し、および、このリンクの評価によって検索された第２のデータベースのハブのプライマリキーの値に応じて、前記第２のデータベースのハブから得られる部分グラフを評価することができる。

ハブに各々が関係する幾つかの部分クエリーにクエリーを分割するという上述の着想は、さらに、リレーショナルデータベースと、サブエンティティを識別することと前記サブエンティティからのデータ抽出とを可能にする識別子を含む別の探索可能なエンティティ（特に、単層ファイル）とに関係するクエリーを評価するために使用されることが可能である。リレーショナルデータベースと単層ファイルとが同一のクエリーに関係している場合には、初期クエリーが、３つの部分、すなわち、リレーショナルデータベース中でそれに関係しているハブとテーブルとに関係する部分と、単層ファイルから情報を抽出することに関係する部分と、単層ファイルとリレーショナルデータベースとの間のリンクに関係する部分とに分割されることが可能である。ある意味で、本発明の着想の範囲内では、単層ファイルが、そのハブに関係しているさらに別のテーブルを有しないハブのようにノード図において取り扱われることが可能である。

本発明の原理のさらに別の例示のために、幾分か単純な具体例を、図１に図式的に示されている構成を参照しながら説明する。図１は、テーブル「研究員（ＲＥＳＥＡＲＣＨＥＲＳ）」と、テーブル「部門（ＤＥＰＡＲＴＭＥＮＴＳ）」と、テーブル「論文（ＡＲＴＩＣＬＥＳ）」と、テーブル「著者（ＡＵＴＨＯＲＳ）」と、テーブル「表題／要約（ＴＩＴＬＥ／ＡＢＳＴＲＡＣＴ）」とを含むリレーショナルデータベースを示す。図１に点線で示されているさらに別のテーブルが存在してもよい。テーブル「研究員」はカラムＲＮＡＭＥとカラムＲＩ（＝ｒｅｓｅａｒｃｈｅｒｓ ｉｄｅｎｔｉｆｉｅｒ）とを有し、このＲＩカラムはこのテーブルに関するプライマリキーを定義する。ＲＩはテーブル「部門」に対するリンクキーを形成し、ＲＮＡＭＥはテーブル「著者」のカラムＲＮＡＭＥに対するリンクを形成し、このテーブル「著者」はさらにカラムＡＮＡＭＥとカラムＡＲＴＩＤとを含む。一方、ＡＲＴＩＤはテーブル「論文」に対するリンクを形成する。テーブル「論文」は、カラムＡＲＴＩＤと、カラム「刊行物（ＪＯＵＲＮＡＬ）」と、カラム「年（ＹＥＡＲ）」と、カラム「ページ（ＰＡＧＥ）」とを含む。ＡＲＴＩＤは、さらに、テーブル「論文」から、カラム「表題」とカラム「要約」とを有するテーブル「表題／要約」へのリンクを形成する。この例では、例えば、そのデータベースのユーザが従業員による調査研究を監視することを望むＲ＆Ｄ研究所であるので、テーブル「研究員」はハブテーブルとして事前定義されている。

さて、要約中で「インシュリン」に言及すると同時にそれぞれの著者の論文と表題と名前と部門とに関する著書目録データを検索することを要求するクエリーがすべての論文に関して実行依頼されているとしよう。このシステムは、最初に、テーブル「要約／表題」内の「要約」カラムで「インシュリン」という語を含むエントリを探索する。その次に、このシステムは、テーブル「要約／表題」とハブテーブル「研究員」との間に関係が存在するかどうかを調べる。この関係が存在する場合には、テーブル「要約／表題」−「論文」−ＡＮＡＭＥ−「研究員」の連鎖を通して、このシステムは、語「インシュリン」を含むテーブル「要約／表題」内のカラム「要約」内のエントリに関係しているキーＲＩを検索することに取りかかる。この条件に合致する２つのＲＩ値、すなわち、（研究者Ｓｍｉｔｈと研究者Ｊｏｎｅｓとに対応する）値１と値２とが存在するということが明らかになる。

このシステムは、次に、情報がどのテーブルから求められているかを調べる。このテーブルは、「研究員」と、「部門」と、「論文」と、「要約／表題」である。したがって、このシステムは、次に、図１に実線で示されているように、これらのテーブルをハブテーブル「研究員」に連結するグラフを決定する。その次に、このシステムは、第１の段階では、名前Ｓｍｉｔｈと名前Ｊｏｎｅｓ（ＲＩ １とＲＩ ２とに対応する。説明を分かりやすくするために、これらの名前が研究者に関する一意識別子であることが仮定されている）を有するテーブル「著者」内の全エントリを評価し、および、関係するＡＲＴＩＤ値を検索する。この結果が第１の部分結果セットとして記憶される。後続のテーブル「論文」とテーブル「要約／表題」はこの段階ではクエリーされなかったが、このことがテーブル「著者」とテーブル「論文」との間に結合点が生成されたということを意味するということに留意されたい。次に、この第１の段階で検索されたキーＡＲＴＩＤが、著書目録データと表題と要約とを検索するために後続のクエリーで入力として使用される。このクエリーの結果を再検討することによって、ＳｍｉｔｈとＪｏｎｅｓとが論文３と論文４の著者としてリストされているので、この結果が論文３と論文４とを含むということに留意されたい。しかし、これらの論文はクエリー条件に合致しない。したがって、このシステムは、この第２の部分クエリーの部分結果を一貫性に関して検査し、クエリー条件（要約が語「インシュリン」を含む）に一致しない結果セットの一部分を取り除く。これによって、論文ＩＤ １と論文ＩＤ ２とに関して下記の結果セットが残される。

ＳｍｉｔｈとＪｏｎｅｓとが論文１の共著者なので、論文ＩＤ １が２回出現するということに留意されたい。

グラフの第１のブランチを評価し終わり、その結果が上記の結果セットの形で示されると、このシステムは、その次に、ハブ「研究員」とテーブル「部門」とを含む第２のブランチを評価することに向かう。このブランチに関係しているテーブルは２つしかないので、このシステムは、さらに別のジャンクションを必要とせずに、ＲＩ １とＲＩ ２とがＳｍｉｔｈとＪｏｎｅｓとに対応するという情報と、Ｓｍｉｔｈが部門Ａで働いており、Ｊｏｎｅｓが部門Ｂで働いているという情報とを検索する。その次に、この結果が先行の結果セットと組み合わされ、その結果として、結果セット全体が次に示される通りに得られる。

この時点で、クエリーが基本的に完了される。説明を分かりやすくするために、この結果が結果テーブルとして表現された。好ましい実施形態では、３つの部分クエリーの結果がオブジェクトの形に変換されており、その次に、このオブジェクトはクエリー全体に対する結果を得るために組み合わされている。

異なるデータベース設定では、テーブル「研究員」とテーブル「論文」の両方がハブとして選択されていると仮定しよう。この場合には、同一のクエリーを評価するために、このシステムは、第１の段階において、ＡＲＴＩＤ １とＡＲＴＩＤ ２とがクエリー条件（要約が語「インシュリン」を含む）に合致するということを確定するであろう。その次に、このシステムは、第１の段階において、テーブル「論文」とテーブル「要約／表題」とを含む部分グラフを評価し、および、論文１と論文２とに対応する著書目録データと表題と要約とを検索するであろう。第２の段階では、このシステムは、ＡＲＴＩＤの値１と値２とから開始して、テーブル「論文」−「著者」−「研究員」の連鎖によってテーブル「研究員」の関係ＲＩを決定するであろう。これは単一のクエリーで行われることが可能である。「著者」と「研究員」との間に結合を導入することが予想可能であり、すなわち、最初に「著者」のキーに関する部分クエリーを評価し、その次に、この部分クエリーがＲＩの値に関するさらに別のクエリーのための入力として使用されることが予想可能である。その結果として、ＲＩに関する値１と値２とが検索される。ハブテーブル「研究員」とテーブル「部門」とに関係する第３の部分クエリーでは、検索される。部分クエリーの結果セットが組み合わされ、このことは、上記で示された通りに、初期クエリーに関する同一の結果セットを結果的に生じさせる。

テーブル「論文」−「著者」−「研究員」の連鎖がその２つのハブの間のリンクと見なされる場合には、テーブル「研究員」とテーブル「論文」とが異なるデータベースまたは異なるライブラリに属し、かつ、テーブル「著者」とテーブル「研究員」との間のリンクによって連結されているならば、同一の手順が適用可能であるということが理解される。データベース間のリンクが一方のデータベースまたはライブラリのハブテーブルに対してであることは必ずしも必要ではないということが理解されなければならない。

さらに、１つのデータベース内の２つのハブという上記の具体例に対する変更例として、第１の段階において、クエリー条件に合致する両方のハブのプライマリキーの値が決定されることが可能である。このことは、ＲＩ １と、ＲＩ ２と、ＡＲＴＩＤ １と、ＡＲＴＩＤ ２とを戻すであろうし、その次に、これらは、それぞれのハブテーブルとそれらに応じるテーブルとに関係するグラフの２つのブランチを評価するために使用されることが可能である。さらに別の代案として、「論文」と「研究員」との間の直接的な静的リンクを実行することが選択されることも可能である。

さらに別の具体例では、ジャンクションに関係するということの利点が、図３に示されているデータベースを参照して示されている。このデータベースは下記の３つのテーブルを含み、テーブル「論文テーブル」がハブテーブルとして定義され、および、論文ＩＤが前記ハブテーブルの一意識別子として定義されている。

論文番号８８に関係している全ての情報に関する探索を考察すると、２つの場合、すなわち、ジャンクションが全くない場合と、ハブテーブル（「論文」）とその関係するテーブル（「参考文献」と「著者」）の各々との間のジャンクションがある場合とが示される。

ケース１：ジャンクションなし
単一のクエリーが構築されて実行依頼される。結果セットは３×２＝６つのローを有するであろう。

冗長データがフィルタリング処理中に無視され、オブジェクトがその一意的なデータから構築されるであろう。この場合には、例えば、データ「８８」および「表題８８」が、６回出現するにも係わらず、１回だけしか読み出されない。同じことがＲｅｆＰ１の冗長性と、ＲｅｆＰ２の冗長性と、ＲｅｆＰ３の冗長性と、ＳｍｉｔｈおよびＪｏｎｅｓの冗長性とに当てはまる。フィルタリングおよびオブジェクト生成アルゴリズムを原因として、各々の一意的なフィールドが１回だけ読み出される。探索結果をオブジェクトまたはオブジェクト構造として表現することによって、結果における冗長性を回避することが可能である。したがって、当然のことながら、まず第１に冗長性を回避することが好ましいであろう。これは結合点の着想を用いて行われることが可能である。

ケース２：両方のリンクがジャンクションである。
２つのクエリーが構築され、順次にまたは並行して実行依頼される。次に示されている２つの結果セットが戻される。

冗長データが無視される（この場合には「８８」と「表題８８」だけである）。オブジェクトがこれらの２つの結果セットから構築される。このオブジェクトは場合１で構築されたオブジェクトと等価である。

単一のクエリーでは、結果セットがより大きく、および、より冗長な情報を含むということに留意されたい。戻されるローの数は、（１−１関係以外の関係を有する）テーブルの数が増加するにつれて劇的に増大するであろう。複雑な関係が、ほとんどの実世界のデータベースにおいて一般的な状況である。

上記の具体例が単に例示のためのものであるにすぎないということと、本発明がこれらの具体例に限定されないということとが理解されなければならない。

本明細書と特許請求項と添付図面とに開示されている本発明の特徴は、単独の場合とあらゆる任意の組合せの場合との両方において、本発明の様々な実施形態の形での本発明の実現のために不可欠であり得る。

特定の具体例の説明で参照される単純なデータベースのノード図を示す。 図１によるデータベースのテーブルを示す。 図１によるデータベースのテーブルを示す。 図１によるデータベースのテーブルを示す。 図１によるデータベースのテーブルを示す。 図１によるデータベースのテーブルを示す。 第２の具体例に関するノード図を示す。

Claims (42)

1. リレーショナルデータベース管理システム（ＲＤＢＭＳ）を備える少なくとも１つのリレーショナルデータベースに関係するクエリーを評価する方法であって、前記クエリーは、前記リレーショナルデータベースの少なくとも１つのテーブルに関係し、および、前記方法は、
   前記クエリーを評価するためのゲートウェイテーブルとして前記リレーショナルデータベースのテーブルを決定することと、
   クエリーされるべきテーブル内の１つまたは複数のエントリに関係している前記ゲートウェイテーブルの１つまたは複数の一意識別子を検索することと、
   前記ゲートウェイテーブルの前記検索された一意識別子に関係している、クエリーされるべき１つまたは複数のテーブルから情報を検索することと、
   結果を前記クエリーに提供すること
   とを含む方法。
2. 前記リレーショナルデータベースは１つまたは複数の予め決められたハブテーブルを含み、および、前記クエリーは、前記リレーショナルデータベースの少なくとも１つのテーブルに関係し、および、前記方法は、
   クエリーされるべきテーブル内の１つまたは複数のエントリに関係しているハブテーブルの１つまた複数の一意識別子を検索することと、
   前記ハブテーブルの前記検索された一意識別子に関係しているクエリーされるべきテーブルから情報を検索することと、
   前記クエリーに結果を提供すること
   とを含む、請求項１に記載の方法。
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. 請求項４１に記載のプログラムを含むコンピュータ可読記憶媒体。

Images