JP2012128858A - クエリシステム及びコンピュータプログラム - Google Patents

Abstract

【課題】データベースシステム及び／又は検索エンジンシステムにおいて受信したクエリ要素に対応するクエリ処理を実行するクエリシステムを提供する。
【解決手段】クエリシステムは、データベースシステムの非テキスト中心のデータ入力をその非テキスト中心のデータ入力を表す対応するテキスト中心のデータ入力に変換し、それを検索エンジンシステムのインデックスに入力して、非テキスト中心のデータ入力が検索エンジンシステム及びデータベースシステムの両方で利用可能であるようにするよう、非テキスト中心の同期化処理として動作する同期化手段を有する。
【選択図】図６

Description

本発明は、クエリシステムに係る。

特に、本発明は、様々なタイプのデータ処理システム、例えば、データベースシステム及び検索エンジンシステムを使用するクエリシステムに係る。本発明は、もっぱらデータベース環境及び検索エンジン環境のいずれかの部分であることなしに、それらの環境の側面に係る。

データベースは、通常はデジタルの形で、一以上の目的のために体系化されたデータの集合から成ると考えられてよい。データベースは、例えば、図書目録、文書、統計といった、それらのコンテンツのタイプによって分類されてよい。デジタルデータベースは、通常は、データベース管理システム（ＤＢＭＳ）を用いて管理される。ＤＢＭＳは、データベース・コンテンツを記憶しており、データの生成及びメンテナンス、並びに検索及び他のアクセスを可能にする。

ＤＢＭＳは、一般的に、データベースを操作するソフトウェアから成り、記憶、アクセス、セキュリティ、バックアップ及び他の機能を提供する。ＤＢＭＳは、それらがサポートするデータベースモデル（例えば、相関又はＸＭＬ（Extensible Markup Language））、それらがサポートするコンピュータのタイプ（例えば、サーバクラスタ又は携帯電話機）、データベースにアクセスするクエリ言語（ＳＱＬ（Structured Query Language）又はＸＱｕｅｒｙ）、又は性能トレードオフ（例えば、最大スケール又は最大速度）等に従って分類可能である。一部のＤＢＭＳは、それらの分類において１よりも多い項目に及ぶ（例えば、複数のクエリ言語をサポートする。）。

ＳＱＬは、相関データベース管理システム（RＤＢＭＳ）においてデータを管理するために設計されたデータベースコンピュータ言語である。ＸＱｕｅｒｙは、ＸＭＬデータの集合にクエリを行うよう設計されたクエリ及び機能プログラミング言語である。

ＲＤＢＭＳは、通常は、テーブル列ごとに一以上のデータ分類に従ってデータを含むテーブルの組（「関係（relations）」とも呼ばれる。）に基づく。テーブルの各行はデータのインスタンスを含む。とり得る値のデータ範囲は、データベースの生成の間に、各列ごとの制約とともに、指定され得る。メタデータのテーブルは、データベーステーブル、テーブル列、データ範囲及びデータ制約の公式の定義を格納してよい。

ＲＤＢＭＳの典型例は、ＩＢＭ ＤＢ２、ＭｙＳＱＬ、Ｓｙｓｂａｓｅ Ｄａｔａｂａｓｅ又はＯｒａｃｌｅ Ｄａｔａｂａｓｅである。ＳＱＬは、データ操作のために、すなわち、ＤＭＬ（Data Manipulation Language）としてＲＤＢＭＳにおいて使用される典型的な言語である。一部のデータベースは専用の検索エンジンアスペクトにより強化されるが、機能は通常制限されている。

オブジェクト指向のプログラミングパラダイムに関して、オブジェクト指向のデータベースが考えられてきた。オブジェクト指向のデータベース管理システム（ＯＯＤＢＭＳ）又はオブジェクトデータベース管理システム（ＯＤＢＭＳ）は、オブジェクトとしてのデータのモデリング及び生成に基づくＤＢＭＳであると考えられてよい。このようなシステムは、オブジェクトクラス、オブジェクトインヘリタンス（多様性）及びオブジェクト間の関連性をサポートする。オブジェクトクラスは、データ範囲に従って属性の組を定義する。

ＯＯＤＢＭＳの例として、Ｆｕｊｉｔｓｕ Ｅｎａｂｌａｒ、ＯｂｊｅｃｔＤＢ及びＯｂｊｅｃｔＳｔｏｒｅがある。一般的に、ＯＤＱＬ（Object Database Query Language）又はＯＱＬ（Object Query Language）は、そのようなシステムにおいてクエリ言語として用いられるが、ＸＱｕｅｒｙ及びＯＣＬ（Object Constraint Language）は他の選択肢である。

上記の言語自体はよく知られており、従って、それらに関する更に詳細な情報（構文、文法、等）はここでは省略される。

典型的なデータベースクエリ言語は、様々な側面、例えば、データ選択（フィルタリング）、データ投影、データ横断、データ結合、クロス乗積、等に分けられ得る。特定のクエリ言語は、そのような側面を全くカバーしないことがある。例えば、データ横断（traversal）は、ＯＯＤＢＭＳにおける特徴でありうるが、ＲＤＢＭＳにおいて存在しないことがある。

本発明は、上記のタイプのデータベースに適用されてよく、また、他のデータベースタイプに適用されてもよい。

一般的に、検索エンジンは、ユーザが関心のある項目に関する基準を指定して、一致する項目をエンジンに見つけさせることを可能にする、項目のグループに対するインターフェースを提供する。検索基準は、通常、クエリ、例えば検索クエリと称される。テキスト検索エンジンの場合において、検索クエリは、通常、一以上の文書が含みうる所望の概念を識別する語の組として表現される。

正確性の点で異なる幾つかのスタイルの検索クエリ構文が存在する。一部のテキスト検索エンジンは、余白によって分けられた２語又は３語を入力するようユーザに求め、一方、他の検索エンジンは、ユーザが文書全体、画像、音、及び様々な形態の自然言語を特定することを可能にしてよい。一部の検索エンジンは、クエリ拡張として知られている処理を通じて高品位の項目の組を提供する可能性を高めるよう検索クエリに改善を適用する。

他のタイプの検索エンジンは、インデックスに基づく検索エンジンである。このような検索エンジンは、文書インデックスに基づくキーワードにクエリを行うシステム又はコンポーネントであると考えられてよい。文書インデックスは、文書又は他のテキストソースをパースし、そのキー情報をインデックス記憶部に記憶することによって、生成される。中でもより一般的な検索エンジンは、Ａｐａｃｈｅ Ｌｕｃｅｎｅ（Ｃｏｍｐａｓｓ）、Ｈｔ：／／ｄｉｇ又はＩＳｅａｒｃｈである。

クエリによって指定される基準を満たす項目のリストは、通常はソート又はランク付けされる。関連性によって項目を（最高から最低まで）ランク付けすることは、所望の情報を見つけるために必要とされる時間を減らす。確率的な検索エンジンは、（通常、最も類似している１から０までの段階における、各項目とクエリとの間の）類似性の程度と、時々、大衆性若しくは権限、又は使用関連性フィードバックとに基づき、項目をランク付けする。ブール（boolean）検索エンジンは、通常、順序に関係なく厳密に一致する項目のみを返すが、語「ブール検索エンジン」は、単に、確率論的な意味においてブールスタイル構文の使用（演算子ＡＮＤ、ＯＲ、ＮＯＴ及びＸＯＲの使用）に言及してよい。

瞬時に幾つかの基準に従って記憶されている一致項目の組を提供するよう、検索エンジンは、通常、「インデキシング」又は「テキストインデキシング」と称される処理を通じて、予め考慮される項目のグループに関してメタデータを収集する（文書インデックスを生成する。）。インデックスは、しばしば（従前考えられている検索エンジンの場合において）、少量のコンピュータ記憶を必要とする。これは、一部の検索エンジンが、インデックス付きの情報のみを記憶し、各項目の全コンテンツを記憶せず、代わりに、検索エンジン結果ページにおける項目へのナビゲーション方法を提供するためである。

検索エンジンは、ユーザがインデックスを付された時点での項目の状態を見ることができるように、又はアーカイブ目的のために、又はより効率的且つ瞬時に繰り返し処理を働かせるよう、各項目のコピーをキャッシュに格納してよい。

他のタイプの検索エンジンは、インデックスを記憶しない。所謂「クローラ（crawler）」又は「スパイダタイプ（spider type）」検索エンジン（しばしば、実時間検索エンジンと称される。）は、検索クエリを実行する時点で項目の収集及びアクセスを行うとともに、開始項目（シード（seed）又は、インターネット・クローラの場合においてはシードＵＲＬとしても知られる。）のコンテンツに基づき更なる項目を動的に考慮してよい。メタ検索エンジンは、インデックスもキャッシュも記憶せず、代わりに、単に、１又はそれ以上の他の検索エンジンのインデックス又は結果を再利用して、統合された最終的な結果の組を提供する。

語「データ処理システム（data handling system）」（ＤＨＳ）は、検索エンジン（検索エンジンシステム）及びデータベース（データベースシステム）の両方に関する包括的な用語であると考えられてよい。

そのような検討中のデータベースシステム及び検索エンジンシステムにおいては、問題が存在する。

従前考えられたデータベースは、標準化されたクエリ言語（例えば、ＳＱＬ又はＸＱｕｅｒｙ）に基づく固定のデータ範囲に従って、データ属性を扱う。これは、列又はオブジェクトクラスに対して高性能且つタイプセーフ（type-safe）のクエリを実行するができるために、行われる。しかし、そのようなデータベースは、検索エンジンと比較して、テキスト属性に対して、ほんの小さな組の機能しか提供しない。更に、オブジェクト指向のデータベースは、テーブル中心のデータ結果に関して、比較的低い性能を有する。

第１の例として、ＰＤＦ文書がデータ入力（データエンティティ）に関連づけられてよい。そのような文書は、ＢＬＯＢ（binary large object）属性に格納されてよい。しかし、ＢＬＯＢ属性に対するテキスト中心のクエリ機能の性能が問題となりうる。例えば、記憶されているＰＤＦ文書のリスト内の語の存在を探している場合には、データベースサーバからクライアントマシンに全てのＰＤＦ文書をロードして、テキスト情報を取り出し、目的の語の検索を行う必要がある。このような動作は、ＰＤＦ文書の全てを転送するために必要な膨大なネットワークトラフィック及びオンザフライでデータを解釈する余分の労力のために、（リソースに関して）費用がかかる。

データベースの性能は、データインデキシング又は「キーインデキシング（key-indexing）」に大いに依存する。このようなインデキシング（キーインデキシング）は、単純なデータタイプ又は単純なデータタイプの組み合わせには合っているが、ＢＬＯＢタイプは、通常、データベース内でインデックス付けされない。たとえそのようなデータタイプに対するテキストクエリが（例えば、専用のデータベース拡張子を手段として）存在したとしても、それはデータベース性能を劣化させうる全テーブルスキャンをもたらす。

第２の例として、エンティティ（データ入力）は、「ａｂｃｄ」のような連続を含む文字列属性を含んでよい。この文字列は「（ａ（ｂ）ｃ）ｄ」のような正規表現に一致するかどうかを知ることが望ましい。同様の考慮は、データ（例えば、０１／０５／２００［４］６）又は数値に関する正規表現の実行に関連する。ＳＱＬ又はＸＱｕｅｒｙのような大部分の標準的なクエリ言語は、そのような動作をサポートしない。クエリ言語に対する幾つかのデータベース拡張が考えられており（これは、クエリ言語を介して、又は記憶されたプロシージャとして、動作する。）、特定のデータタイプに制限された使用を有する。

第３の例として、ＯＤＢＭＳは、通常は、特に、テーブル状の結果の組を有してクエリを実行している場合に、比較的低いクエリ性能を有する。この使用状況はＲＤＢＭＳに基づいて実施されるべきであり、一方、そのような選択はしばしば利用可能でなく、すなわち、ＯＤＢＭＳの他の機能を支持して提供されないことがある。

第４の例として、制約を伴わない環境を仮定すると、エンドユーザは、データベースのアプローチとは異なる、データクエリへのアプローチを有してよい。エンドユーザは、構造化されていない方法でクエリにアプローチする傾向がある。例えば、エンドユーザは、通常、インターネット検索エンジンの操作が直感的に理解できることが分かり、一方、少数派は、同程度の容易さでＲＤＢＭＳのようなデータベースからのデータをフィルタリングすることができる。

第５の例として、多数の従前考えられたデータベースは、それらの生来の適用範囲への専用の拡張子を特徴とする。それらは、例えば、ＣＬＯＢ（Character Large Objects）に対して検索エンジン機能を用いることができる。しかし、それらは、それらの生来のデータベーススキームを他のデータタイプに関して用いる。

検索エンジンに関して、かかるシステムは、通常はデータ範囲によって制限されず、通常はテキスト中心の動作に対して高い柔軟性を有する。しかし、検索エンジンは、通常はデータベースとして機能するよう意図されず、一般的に完全なソースコンテンツを記憶していない。また、通常は、データインスタンス間の関係を設計することは可能でない。また、検索エンジンは、一般的に特定のドメインモデルを参照せず、代わりに、全てのデータは、データベースが普通にあるようにタイプセーフでなくそれらをレンダリングするテキストとして扱われる。しかし、それらの特定の適用範囲（テキストに基づく又はテキスト中心の検索）内で、検索エンジンは高速且つ柔軟であると考えられる。

本発明は、上記のシステムで見られる一以上の問題を解消することを目的とする。具体的に、本発明は、従来のシステムに対して利点を提供するクエリシステム、並びに関連する方法及びコンピュータプログラムを提供することを目的とする。

具体的に、本発明は、クエリ要素によって対象とされる属性タイプ（属性範囲）に関して厳密な憶測を立てることなく、クエリ要素に対応するクエリ動作を実行する際に使用されるクエリシステム及びコンピュータプログラムを提供することを目的とする。

本願では、クエリ要素に対応するクエリ処理を実行する際に使用される該クエリ要素を分析するよう動作する分析手段と、第１のデータ処理システム及び／又は該第１のデータ処理システムとはタイプが異なる第２のデータ処理システムにおいて前記クエリ処理を実行すべきかどうかを前記分析に依存して決定するよう動作する決定手段とを有するクエリシステムが開示される。

本発明の第１の側面の実施形態に従って、クエリ要素に対応するクエリ処理を実行する際に使用される該クエリ要素を分析するよう動作する分析手段と、データベースシステム及び／又は検索エンジンシステムにおいて前記クエリ処理を実行すべきかどうかを前記分析に依存して決定するよう動作する決定手段とを有するクエリシステムが提供される。

かかるクエリシステムは、コンピュータにより実施されるクエリシステムであってよい。例えば、それは、コンピュータ装置で実行されるソフトウェアを手段として実施されてよい。コンピュータ装置は、単一のデバイスの形態をとっても、又は複数のデバイスにわたって分配されてもよい。

かかるクエリシステムは、ハードウェアにおいて、又は部分的にコンピュータ装置において実行されるソフトウェアを手段として及び部分的にハードウェアにおいてにおいて、実施されてよい。

かかるクエリシステムによれば、データベースシステム及び検索エンジンシステムの両方の機能を利用すること及び、特に、それらのどちらが環境により適しているのかを決定するよう受信したクエリを分析することが可能である。

このように、クエリシステムは、データベースシステムにおいて、若しくは検索エンジンシステムにおいて、又はデータベースシステム及び検索エンジンシステムの両方において、クエリ処理を実行すべきかどうかを決定してよい。例えば、どちらが最良を尽くすかどうかが前もって分かっていない場合には、両方のシステムが使用されてよい。

クエリシステムは、前記クエリ処理が前記データベースシステムにおいて実行されるべきと決定される場合には該データベースシステムにおいて、及び／又は前記クエリ処理が前記検索エンジンシステムにおいて実行されるべきと決定される場合には該検索エンジンシステムにおいて前記クエリ処理を実行するよう動作する実行手段を有してよい。

クエリシステムは、前記データベースシステムの非テキスト中心のデータ入力を該非テキスト中心のデータ入力を表す対応するテキスト中心のデータ入力に変換し、該テキスト中心のデータ入力を前記検索エンジンシステムのインデックスに、望ましくは、該テキスト中心のデータ入力から生じる前記インデックスにおける各インデックス入力を前記データベースシステムの対応する非テキスト中心のデータ入力と関連づける対応情報とともに入力するよう、非テキスト中心の同期化処理として動作する同期化手段を有してよい。

前記非テキスト中心のデータ入力は、そのようなものとしてテキストを表すために使用される又は基礎とされないフォーマットで記録されるデータ入力であってよい。前記非テキスト中心のデータ入力は、例えば、整数、ダブル、データ、ブール等であってよい。

前記テキスト中心のデータ入力は、テキストの文字列、例えば、データタイプ「文字列（string）」のデータであってよい。文字列は、一般的に、データ値の連続を保持するデータタイプとして理解され、そのようなデータ値の連続において、要素は、通例、文字符号化に従って文字を表す。

例えば、データとの関連で、非テキスト中心のデータ入力は、時間における基準点からの秒又はミリ秒数としてデータを表す整数であってよい。対応するテキスト中心のデータ入力は、同じ日時を表す、「２０１０／０１／０５ ＰＤＴ １０：５０：５０」といったテキストの文字列であってよい。

前記同期化手段は、前記データベースシステムの全ての非テキスト中心のデータ入力に関して前記非テキスト中心の同期化処理を実行するよう動作してよい。このように、データベースの全ての非テキスト中心の入力は、検索エンジンのインデックスにおいて対応する入力を有してよく、それにより、クエリシステムは、データベースシステム若しくは検索エンジンシステム又はそれら両方を手段として全ての非テキスト中心のデータ入力にアクセスするよう動作する。

クエリシステムは、前記データベースシステムのテキスト中心のデータ入力を、該テキスト中心のデータ入力から生じる前記インデックスにおける各インデックス入力を前記データベースシステムの対応するテキスト中心のデータ入力と関連づける対応情報とともに、前記検索エンジンシステムの前記インデックスに入力するよう、テキスト中心の同期化処理として動作する同期化手段を有してよい。

前記同期化手段は、前記データベースシステムの全てのテキスト中心のデータ入力に関して前記テキスト中心の同期化処理を実行するよう動作してよい。このように、データベースの全てのテキスト中心の入力は、検索エンジンのインデックスにおいて対応する入力を有してよく、それにより、クエリシステムは、データベースシステム若しくは検索エンジンシステム又はそれら両方を手段として全てのテキスト中心のデータ入力にアクセスするよう動作する。

実際に、当然のことながら、クエリシステムは、このようにして、データベースシステム若しくは検索エンジンシステム又はそれら両方を手段として全てのデータ入力にアクセスするよう動作してよい。

前記同期化手段は、前記データベースシステムの全ての非テキスト中心のデータ入力に関して前記非テキスト中心の同期化処理を実行するよう動作してよいが、それは、前記データベースシステムの複数の非テキスト中心の入力、若しくは前記データベースシステムの非テキスト中心の入力の組に関して、又は特定のタイプのデータベースシステムの全ての非テキスト中心の入力に関して、前記非テキスト中心の同期化処理を実行するよう動作してよい。

前記同期化手段は、前記データベースシステムの全てのテキスト中心のデータ入力に関して前記テキスト中心の同期化処理を実行するよう動作してよいが、それは、前記データベースシステムの複数のテキスト中心の入力、若しくは前記データベースシステムのテキスト中心の入力の組に関して、又は特定のタイプのデータベースシステムの全てのテキスト中心の入力に関して、前記テキスト中心の同期化処理を実行するよう動作してよい。

検索エンジンシステムのインデックスへのそのような入力は、例えば、データベースシステムにおいて変更が起こる時又は場合といった、トランザクションごとに、あるいは、例えば、時々実行される同期化処理の部分として、スケジューリングに基づき、あるいは、例えば、クエリが受信された時又は場合といった、ジャスト・イン・タイムで又はオンデマンドで、実行されてよい。

前記同期化手段は、当該クエリシステムによって検索可能な情報が変更される場合に、該変更が前記データベースシステム及び前記検索エンジンシステムの両方において表されるよう動作してよい。かかる変更は、新しいデータ入力の生成、既存のデータ入力の更新、又は既存のデータ入力の削除であってよい。

前記決定手段は、前記クエリ要素が前記データベースシステムによってサポートされる検索式に関すると前記分析が示す場合に、前記クエリ処理が前記データベースシステムにおいて実行されるべきと決定するよう動作してよい。

前記決定手段は、前記クエリ要素が前記データベースシステムによってはサポートされないが前記検索エンジンシステムによってはサポートされる検索式に関すると前記分析が示す場合に、前記クエリ処理が前記検索エンジンシステムにおいて実行されるべきと決定するよう動作してよい。

前記決定手段は、前記クエリ要素が検索エンジン中心の選択動作に関すると前記分析が示す場合に、前記クエリ処理が前記検索エンジンシステムにおいて実行されるべきと決定するよう動作してよい。

クエリシステムは、受信したクエリを複数のコンポーネントクエリ要素に分割するよう動作するクエリ分割手段を有してよい。クエリシステムは、クエリ要素ごとに前記クエリ処理を実行するよう動作してよい。

クエリシステムは、前記受信したクエリに依存した順序で前記複数のクエリ要素をキューイングするよう動作するキューイング手段を有してよい。クエリシステムは、前記順序でクエリ要素ごとに前記クエリ処理を実行するよう動作してよい。

クエリシステムは、前記データベースシステム及び前記検索エンジンシステムを有してよく、又は前記データベースシステム及び前記検索エンジンシステムを設けられず、それらと相互に作用するよう構成されてよい。

本発明の第２の側面の実施形態に従って、クエリ要素に対応するクエリ処理を実行する際に使用される該クエリ要素を分析するステップと、該分析に依存して、データベースシステム及び／又は検索エンジンシステムにおいて前記クエリ処理を実行するべきかどうかを決定するステップとを有するクエリ方法が提供される。

本発明の第３の側面の実施形態に従って、データベースシステム及び／又は検索エンジンシステムにおいて受信したクエリ要素に対応するクエリ処理を実行するクエリシステムのコンピュータ装置で実行される場合に、該装置にクエリ方法を実行させるコンピュータプログラムであって、前記方法は、クエリ要素に対応するクエリ処理を実行する際に使用される該クエリ要素を分析するステップと、該分析に依存して、データベースシステム及び／又は検索エンジンシステムにおいて前記クエリ処理を実行するべきかどうかを決定するステップとを有するコンピュータプログラムが提供される。

当該コンピュータプログラムは、単一のプログラムとして又は一組のプログラムとして提供されてよい。当該コンピュータプログラムは、単一のコンピュータデバイスにおいて又は１よりも多いコンピュータデバイスにわたって実行されてよい。すなわち、コンピュータ装置は、ネットワーク等にわたって分配されてよい。

本発明の第４の側面の実施形態に従って、データシステム及び／又は検索エンジンシステムにおいて（選択的に）受信したクエリ要素に対応するクエリ処理を実行するクエリシステムであって、前記データベースシステムの非テキスト中心のデータ入力を該非テキスト中心のデータ入力を表す対応するテキスト中心のデータ入力に変換し、（前記データベースシステムの前記非テキスト中心のデータ入力が前記検索エンジンシステム及び前記データベースシステムの両方で利用可能であるように）該テキスト中心のデータ入力を前記検索エンジンシステムのインデックスに入力するよう、非テキスト中心の同期化処理として動作する同期化手段を有するクエリシステムが提供される。

当該クエリシステムは、クエリ（１又はそれ以上のクエリ要素から形成されてよい。）の性能及び／又は柔軟性が高められることを可能にすることができる。

当該クエリシステムは、コンピュータにより実施されるクエリシステムであってよい。例えば、それは、コンピュータ装置で実行されるソフトウェアを手段として実施されてよい。コンピュータ装置は、単一のデバイスの形態をとっても、又は複数のデバイスにわたって分配されてもよい。

かかるクエリシステムは、ハードウェアにおいて、又は部分的にコンピュータ装置において実行されるソフトウェアを手段として及び部分的にハードウェアにおいてにおいて、実施されてよい。

当該クエリシステムによれば、データベースシステム及び検索エンジンシステムの両方の機能を利用すること及び、特に、データベースシステムを手段としてのみ検索可能であるデータ入力を検索するために検索エンジンシステムを用いることが可能である。

前記非テキスト中心のデータ入力は、そのようなものとしてテキストを表すために使用される又は基礎とされないフォーマットで記録されるデータ入力であってよい。前記非テキスト中心のデータ入力は、例えば、整数又はアレイであってよい。

前記テキスト中心のデータ入力は、テキストの文字列、例えば、データタイプ「文字列（string）」のデータであってよい。文字列は、一般的に、データ値の連続を保持するデータタイプとして理解され、そのようなデータ値の連続において、要素は、通例、文字符号化に従って文字を表す。

例えば、データとの関連で、非テキスト中心のデータ入力は、時間における基準点からの秒又はミリ秒数としてデータを表す整数であってよい。対応するテキスト中心のデータ入力は、同じ日時を表す、「２０１０／０１／０５ ＰＤＴ １０：５０：５０」といったテキストの文字列であってよい。

前記同期化手段は、前記テキスト中心のデータ入力を、該テキスト中心のデータ入力から生じる前記インデックスにおける各インデックス入力を前記データベースシステムの対応する非テキスト中心のデータ入力と関連づける対応情報とともに、前記検索エンジンシステムの前記インデックスに入力するよう、前記非テキスト中心の同期化処理において動作してよい。前記対応情報は、前記データベースシステム及び前記検索エンジンシステムの入力が、互いに関連づけられ、又は互いに相互参照され、又は互いに結び付けられることを可能にすることができる。

前記同期化手段は、前記データベースシステムの全ての非テキスト中心のデータ入力に関して前記非テキスト中心の同期化処理を実行するよう動作してよい。このように、データベースの全ての非テキスト中心の入力は、検索エンジンのインデックスにおいて対応する入力を有してよく、それにより、クエリシステムは、データベースシステム若しくは検索エンジンシステム又はそれら両方を手段として全ての非テキスト中心のデータ入力にアクセスするよう動作する。

クエリシステムは、前記データベースシステムのテキスト中心のデータ入力を、該テキスト中心のデータ入力から生じる前記インデックスにおける各インデックス入力を前記データベースシステムの対応するテキスト中心のデータ入力と関連づける対応情報とともに、前記検索エンジンシステムの前記インデックスに入力するよう、テキスト中心の同期化処理として動作する同期化手段を有してよい。

前記同期化手段は、前記データベースシステムの全てのテキスト中心のデータ入力に関して前記テキスト中心の同期化処理を実行するよう動作してよい。このように、データベースの全てのテキスト中心の入力は、検索エンジンのインデックスにおいて対応する入力を有してよく、それにより、クエリシステムは、データベースシステム若しくは検索エンジンシステム又はそれら両方を手段として全てのテキスト中心のデータ入力にアクセスするよう動作する。

実際に、当然のことながら、クエリシステムは、このようにして、データベースシステム若しくは検索エンジンシステム又はそれら両方を手段として全てのデータ入力にアクセスするよう動作してよい。

前記同期化手段は、前記データベースシステムの全ての非テキスト中心のデータ入力に関して前記非テキスト中心の同期化処理を実行するよう動作してよいが、それは、前記データベースシステムの複数の非テキスト中心の入力、若しくは前記データベースシステムの非テキスト中心の入力の組に関して、又は特定のタイプのデータベースシステムの全ての非テキスト中心の入力に関して、前記非テキスト中心の同期化処理を実行するよう動作してよい。

前記同期化手段は、前記データベースシステムの全てのテキスト中心のデータ入力に関して前記テキスト中心の同期化処理を実行するよう動作してよいが、それは、前記データベースシステムの複数のテキスト中心の入力、若しくは前記データベースシステムのテキスト中心の入力の組に関して、又は特定のタイプのデータベースシステムの全てのテキスト中心の入力に関して、前記テキスト中心の同期化処理を実行するよう動作してよい。

検索エンジンシステムのインデックスへのそのような入力は、例えば、データベースシステムにおいて変更が起こる時又は場合といった、トランザクションごとに、あるいは、例えば、時々実行される同期化処理の部分として、スケジューリングに基づき、あるいは、例えば、クエリが受信された時又は場合といった、ジャスト・イン・タイムで又はオンデマンドで、実行されてよい。

前記同期化手段は、当該クエリシステムによって検索可能な情報が変更される場合に、該変更が前記データベースシステム及び前記検索エンジンシステムの両方において表されるよう動作してよい。かかる変更は、新しいデータ入力の生成、既存のデータ入力の更新、又は既存のデータ入力の削除であってよい。

クエリシステムは、前記クエリ要素に対応する前記クエリ処理を実行する際に使用される該クエリ要素を分析するよう動作する分析手段と、前記データベースシステム及び／又は前記検索エンジンシステムにおいて前記クエリ処理を実行すべきかどうかを前記分析に依存して決定するよう動作する決定手段とを更に有してよい。

クエリシステムは、このようにして、前記クエリ処理を前記データベースシステムにおいて、若しくは前記検索エンジンシステムにおいて、又は前記データベースシステム及び前記検索エンジンシステムの両方において実行すべきかどうかを決定してよい。例えば、どちらが最良を尽くすかどうかが前もって分かっていない場合には、両方のシステムが使用されてよい。

前記決定手段は、前記クエリ要素が前記データベースシステムによってサポートされる検索式に関すると前記分析が示す場合に、前記クエリ処理が前記データベースシステムにおいて実行されるべきと決定するよう動作してよい。

前記決定手段は、前記クエリ要素が前記データベースシステムによってはサポートされないが前記検索エンジンシステムによってはサポートされる検索式に関すると前記分析が示す場合に、前記クエリ処理が前記検索エンジンシステムにおいて実行されるべきと決定するよう動作してよい。

前記決定手段は、前記クエリ要素が検索エンジン中心の選択動作に関すると前記分析が示す場合に、前記クエリ処理が前記検索エンジンシステムにおいて実行されるべきと決定するよう動作してよい。

クエリシステムは、前記クエリ処理が前記データベースシステムにおいて実行されるべきと決定される場合には該データベースシステムにおいて、及び／又は前記クエリ処理が前記検索エンジンシステムにおいて実行されるべきと決定される場合には該検索エンジンシステムにおいて前記クエリ処理を実行するよう動作する実行手段を更に有してよい。

クエリシステムは、受信したクエリを複数のコンポーネントクエリ要素に分割するよう動作するクエリ分割手段を有してよい。クエリシステムは、クエリ要素ごとに前記クエリ処理を実行するよう動作してよい。

クエリシステムは、前記受信したクエリに依存した順序で前記複数のクエリ要素をキューイングするよう動作するキューイング手段を有してよい。クエリシステムは、前記順序でクエリ要素ごとに前記クエリ処理を実行するよう動作してよい。

クエリシステムは、前記データベースシステム及び前記検索エンジンシステムを有してよく、又は前記データベースシステム及び前記検索エンジンシステムを設けられず、それらと相互に作用するよう構成されてよい。

本発明の第５の側面の実施形態に従って、データベースシステム及び／又は検索エンジンシステムにおいて受信したクエリ要素に対応するクエリ処理を実行するクエリシステムにおいて使用されるクエリシステム（例えば、コンピュータにより実施される）方法であって、非テキスト中心の同期化処理として、前記データベースシステムの非テキスト中心のデータ入力を該非テキスト中心のデータ入力を表す対応するテキスト中心のデータ入力に変換するステップと、（前記データベースシステムの前記非テキスト中心のデータ入力が前記検索エンジンシステム及び前記データベースシステムの両方で利用可能であるように）該テキスト中心のデータ入力を前記検索エンジンシステムのインデックスに入力するステップとを有するクエリシステム方法が提供される。

本発明の第６の側面の実施形態に従って、データベースシステム及び／又は検索エンジンシステムにおいて受信したクエリ要素に対応するクエリ処理を実行するクエリシステムのコンピュータ装置で実行される場合に、該装置にクエリシステム方法を実行させるコンピュータプログラムであって、前記方法は、非テキスト中心の同期化処理として、前記データベースシステムの非テキスト中心のデータ入力を該非テキスト中心のデータ入力を表す対応するテキスト中心のデータ入力に変換するステップと、（前記データベースシステムの前記非テキスト中心のデータ入力が前記検索エンジンシステム及び前記データベースシステムの両方で利用可能であるように）該テキスト中心のデータ入力を前記検索エンジンシステムのインデックスに入力するステップとを有するコンピュータプログラムが提供される。

当該コンピュータプログラムは、単一のプログラムとして又は一組のプログラムとして提供されてよい。当該コンピュータプログラムは、単一のコンピュータデバイスにおいて又は１よりも多いコンピュータデバイスにわたって実行されてよい。すなわち、コンピュータ装置は、ネットワーク等にわたって分配されてよい。

語「テキスト中心の（text-centric）」は、「構造化されていない（unstructured）」又は「テキストに基づく（text-based）」又は「テキスト状の（text-like）」又は「テキストの（textual）」又は「ユーザに焦点を当てた（user-focused）」又は「文字列タイプの（string-type）」を意味すると解釈されてよい。例えば、テキスト中心のデータ入力は、人間ユーザによって容易に読まれる又は理解可能なフォーマット、例えば、ユーザへの表示に適したフォーマットにおけるものであってよい。

語「非テキスト中心の（non-text-centric）」は、「構造化された（structured）」又は「テキストに基づかない（non-text-based）」又は「非テキスト状の（non-text-like）」又は「マシンに焦点を当てた（machine-focused）」又は「非文字列タイプの（non-string-type）」を意味すると解釈されてよい。例えば、非テキスト中心のデータ入力は、人間ユーザによって容易に読まれない又は理科不可能なフォーマット、例えば、データベースシステム等のコンピュータシステムが有効に動作することを可能にすることを目的とし且つユーザへの表示に適するように（すなわち、ユーザフレンドリであるように）変換を必要とするフォーマットにおけるものであってよい。

テキスト中心のデータ入力は、大部分は又は完全に非構造化／情報データを含む入力として記述されてよい。この「未構造化（構造化されていない）」データは、高い意味的品質を有してよい（それはユーザ関心と揃えられてよく、その結果として、テキスト中心のデータ入力自体が、おそらくは部分的に、ユーザクエリの部分を形成する可能性は高くなりうる。）。対照的に、非テキスト中心のデータ入力は、大部分は又は完全に「構造化（された）」データ（例えば、データベースによって課される表現及びフォーマットの厳密な規則に適合する（例えば、そのデータモデルにおいて定義される）データ）を含む入力として記述されてよい。簡単に言えば、語「テキスト中心」は、「テキストを軸として展開する」又は「テキストに焦点を当てた」という意味を有し、語「非テキスト中心」は、それとは反対の、すなわち相補的な意味を有すると解される。

データベースシステム又は検索エンジンシステムのデータ入力は、関連システムシステムにおいて予め記憶されているもの、又は関連するシステムにおいてまさに記憶されようとしている（又は記憶されると期待される若しくは記憶されるべき）ものであると解釈されてよい。

検索エンジンシステムは、テキスト又はテキストに基づく検索エンジンシステムであってよく、インデックスに基づく検索エンジンシステムであってよい。

検索エンジンシステムにおける「インデックス（index）」は、幅広く解釈されてよく、簡素なリストに制限される必要はない。所謂「Ｔツリー（T-tree）」は、データベースシステムによって、従って、他のシステムによっても使用されうる「平衡インデックスツリーデータ構造（balanced index tree data structure）」である。これに関連して、検索エンジンシステムは、望ましくは、（オンザフライと併置される）バッチジョブ処理を介してデータベースシステムにおいて（データベースシステムと同期して）更新されてよい。

システム側面の特徴は、方法及びコンピュータプログラムの側面に適用され、また、その逆もありうる。

本発明の実施形態によれば、従来のシステムにおける問題を解消するとともに、従来のシステムに対して幾つかの利点を提供することが可能である。具体的に、本発明の実施形態によれば、クエリ要素によって対象とされる属性タイプ（属性範囲）に関して厳密な憶測を立てることなく、クエリ要素に対応するクエリ動作を実行する際に使用されるクエリシステム及びコンピュータプログラムを提供することが可能である。

クエリシステムの概略図である。 他のクエリシステムの概略図である。 図１及び図２のシステムに適用されるシステムアーキテクチャを表す概略図である。 相関データベースにおいて実現される（電話番号と題された）簡単なテーブルの一例である。 図４のテーブルに対応する逆索引を表す。 他のクエリシステムの概略図である。 ＣＵＤ（生成／更新／削除）動作を実行する場合に図３における様々な要素がどのように用いられるのかを示す概念図である。 図７に対応するアクティビティ図である。 データベースシステム又は検索エンジンシステムにおいて特定のクエリ処理を実行すべきかどうかを決定するために用いられる方法を表すフロー図である。 例となる複雑なクエリを表す。 クエリを構成クエリ要素に分けることに関与するプロシージャを抽象的に表すフロー図である。

以下、単なる一例として、図面が参照される。

前置きとして、本発明の実施形態は、特定のシナリオにおいて性能上の問題及び／又は制限されたクエリ機能を解消するために、データベースシステム（例えば、ＤＢＭＳ）の構造上の利点を（二次的な）検索エンジンシステムのテキストクエリ機能と組み合わせる複合クエリアプローチを用いる。

アプローチは、数字中心の、すなわち一般的なアプリケーションとは対照的に、テキスト中心の又はテキストに基づくアプリケーションを対象としていると考えられてよい。数字中心のアプリケーションは、通例、従前考えられているデータベースシステムによってのみ利用されており、一方、データベーステキスト中心アプリケーションは、通例、データベースクエリ言語によっては十分にサポートされない。

テキスト中心のアプリケーションの典型例は、チーム協調（team-collaboration）システム、ソーシャルネットワーク、要求管理（requirement-management）システム又は文書システムである。

本発明の幾つかの実施形態は、（ネットワークに基づく実施形態との関連で）クライアントマシンにおいて高度化された又は専用のクエリ言語又はＡＰＩ（Application Programming Interface）を用いる。（クライアントマシンにおいて実装される）クエリインタプリタ（interpreter）は、クエリ動作のどの部分が２つの対象クエリエンジン（検索エンジン及びデータベース）のいずれか一方によってより良く処理され得るのかを決定することができる。それらのエンジンは、例えば、クライアントマシンから遠く離れて対応する別個のサーバにおいて実装されてよい。

図１は、クエリシステム１の概略図である。

クエリシステム１はローカルデバイス２を有する。ローカルデバイス２はコンピュータデバイスであってよい。ローカルデバイス２は、分析及び決定手段４と、検索エンジンシステム６と、データベースシステム８とを有する。

分析手段は、クエリ要素に対応するクエリ処理を実行する際に使用される該クエリ要素を分析するよう動作可能である。決定手段は、そのような分析に依存して、クエリ処理をデータベースシステム８又は検索エンジンシステム６のいずれにおいて実行すべきかを決定するよう動作可能である。

図２は、クエリシステム１と同様のクエリシステム１０の概略図である。しかし、本質的にローカルデバイス２のようなローカルデバイスではなく、クエリシステム１０はネットワーク１１にわたって分配される。

クエリシステム１０は、ネットワーク１１にわたって分配されている分析及び決定手段１４と、検索エンジンシステム１６と、データベースシステム１８とを有する。ネットワーク１１は、ＬＡＮ（Local Area Network）若しくはインターネットのようなＷＡＮ（Wide Area Network）、又はその他の通信ネットワーク（有線又は無線）、あるいは、それらネットワークのいずれかの組み合わせであると考えられてよい。

分析及び決定手段１４、検索エンジンシステム１６及びデータベースシステム１８は、夫々、分析及び決定手段４、検索エンジンシステム６及びデータベースシステム８と同じであると考えられてよい。

図１及び図２から明らかなように、ここで考えられているクエリシステム（並びに関連する方法及びコンピュータプログラム）は、局在的な形態及び分散型の形態において構成されてよい。

図３は、システムアーキテクチャ２０（簡略化された「複合クエリアーキテクチャ（hybrid-query architecture）」）を表す概略図である。システムアーキテクチャ２０は、ここでは、クエリシステムによって導入されてよい。例えば、かかるシステムがソフトウェアの形態において（例えば、コンピュータプログラム又はコンピュータプログラムの組として）提供される場合に、システムアーキテクチャ２０は、そのソフトウェアのとり得る構成を表してよい。

システムアーキテクチャ２０は、アプリケーション２２と、持続ＡＰＩ（Application Programming interface）２４と、検索エンジン２６と、データベース２８とを有する。

アプリケーション２２は、ユーザアプリケーションであると考えられてよく、ユーザから入力を受け取って結果をユーザに提示してよい。持続ＡＰＩ２４は、アプリケーション２２と検索エンジン２６及びデータベース２８との間に位置付けられ、検索エンジン２６、データベース２８及びアプリケーション２２と相互作用する。

持続ＡＰＩ２４は、クエリ機能３０と、ＣＵＤ（生成／更新／削除）機能３２とを有する。

明らかなように、クエリ機能３０は、アプリケーション２２を介してユーザによって提起されるクエリに基づいて検索要求を行うことを支援する。すなわち、受け取ったクエリに基づき、クエリ機能３０は、クエリ処理をデータベース２８又は検索エンジン２６のいずれにおいて行うべきかを決定し、クエリ処理を実行するようデータベース２８及び／又は検索エンジン２６にアクセスするよう動作可能であってよい。

たとえクエリ処理が検索エンジン２６において実行されるとしても、データベース２８（検索エンジン２６と並置される。）がソースデータの信頼できる又はマスタ記憶部であるよう構成される場合に、検索結果に対応するデータは、データベース２８から取り出されてよい。受け取ったクエリが複数のクエリ要素から成る場合に、要素ごとのクエリ処理が実行されてよく、各処理は、クエリ機能３０によって決定されるようにデータベース２８又は検索エンジン２６において実行される。

ＣＵＤ機能３２は、データ変更がデータベース２８において起こる場合に、同等の変更が検索エンジン２６においても起こることを確かにするのを支援する。例えば、データベース２８においてデータが生成、更新又は削除される場合に、ＣＵＤ機能３２は、同等の変更が検索エンジン２６において、例えば、検索エンジン２６のインデックスにおいて行われるよう配置する。このように、ＣＵＤ機能３２は、データベース２８及び検索エンジン２６を互いと整合性が取れたままとする働きをする。検索エンジン２６において行われるそのような変更は、例えば、対応する変更がデータベース２８において行われると直ぐといったように積極的に、又はクエリが提起された時といった後の時点のようにのらくらと、行われてよい。

検索エンジン（検索エンジンシステム）が１よりも多いインデックスを有する場合に、ここで使用される語「インデックス（index）」は、それらのインデックスのいずれか１つ又はそれ以上を個別的に又は集合的に参照すると考えられてよい。

まとめて、クエリ機能３０及びＣＵＤ機能３２は、例えば、所望のデータベース動作をカバーする所謂ＣＲＵＤ（生成／読出／更新／削除）機能を有すると考えられてよい。

当然のことながら、検索エンジン２６及びデータベース２８は、夫々、検索エンジンシステム６及び１６並びにデータベースシステム８及び１８に対応する。更に、当然のことながら、分析及び決定手段４及び１４は、ＡＰＩ２４を手段として、特に、幾つかの事例においてはアプリケーション２２とともに、クエリ機能２０を用いて、実施されてよい。

従って、当然のことながら、システムアーキテクチャ２０は、コンピュータデバイス２（図１参照）のようなコンピュータデバイスで実施されてよい。代替的に、システムアーキテクチャ２０は、クライアントマシンのような１つのマシンで実施されるアプリケーション２２及び持続ＡＰＩ２４により、並びに別個のネットワークサーバ（図２参照）で実施される検索エンジン２６及びデータベース２８により実施されてよい。

このようなクエリシステムは、ここで開示される機能に従って複合クエリをサポートするよう特定の変更を必要とすることなしに、従前考えられているデータベースシステムをそのままで用いてよい。しかし、ここで開示されるクエリシステムは、望ましくは、データベースシステム及び検索エンジンシステムを互いと整合性がとれた、望ましくは完全に（例えば、１００％）整合がとれたままとする働きをし、従って、データベースシステムと検索エンジンシステムとの間の関係を考慮する（保つことを目指す）。

このとき、データ入力自体について考える。

データ入力は、属性を有するエンティティ（オブジェクト指向のシステムとの関連で、オブジェクトはエンティティの一種であると考えられてよい。）として表されてよい。例えば、文書エンティティは、作成日を表す属性としてデータ属性（例えば、２５／１２／２０１０）を有してよく、あるいは、従業員エンティティは、従業員の社内ＩＤ番号を表す番号属性（例えば、１２３４５）を有してよい。

ここで開示されるクエリシステムは、全ての属性をテキストとして、すなわち、テキスト形態で、又はテキスト中心の属性として、表すよう構成されてよい。例えば、整数１００は、テキスト形態において０００００１００と表現されてよい。他の例として、日時は、その共通の数字表現に代えて、例えば「２０１０／０１／０５ ＰＤＴ １０：５０：５０」といったテキスト形態で記憶されてよい。

次いで、個々の属性は、キー値対として検索エンジンのインデックスに入れられてよい。キーは、エンティティの表示であり、値は、その属性の１つの表示である（例えば、値＝“ｍｙＤａｔｅ＝１２／２４／２００９”）。

従って、このようなクエリシステムは、全てのデータがテキスト形態で表されてよいので、データタイプに対して限られた制限を課さない。理論上、それは、何らかのビットシーケンス（従って、何らかのデータ）を文字列に変換することができる。従って、全てのデータは、テキスト中心の形態において表されてよい。

データベースの全エンティティは、必要に応じてテキスト形態への変換により、検索エンジンのインデックスに入力されてよい。このようにして、データベースの全エンティティは、また、検索エンジンによって検索可能となり、例えば、それにより、選択クエリはエンティティごとに実行されてよい。

より柔軟なクエリを可能にするために、記憶されているエンティティデータは、目標のシナリオに従って、外部エンティティデータにより強化されてよい。相関データベースにおける外部キー関係と同様に、そのような外部キーを検索エンジンのインデックスに導入して、通常は従前考えられている検索エンジンのインデックスにおいて使用されない関係が模倣されてよい。

クエリは、検索エンジンの能力を用いて、２つのエンティティの間の関係を対象としてよい。このアプローチは、理論上、データベースのクエリアスペクトの大部分を置換しうる。しかし、幾つかの段階において、性能は、純粋にテキスト中心の動作が検索エンジンにとって（リソースに関して）高価であるために、データベースにクエリする性能に対して悪くなる。

そのような柔軟性は無料でないと認識されている。複数のクエリエンジン（検索エンジン及びデータベース）にクエリすることができるために、データは、それらの夫々において複製される。このデータ冗長性は、当然ながら、記憶空間に関して高価である。しかし、中型のデータベースは数ギガバイトのデータを保持してよく、一方、現在利用可能なＨＤＤ（Hard Disc Drives）は数テラバイトを記憶することができる。このように、コスト高は、得られる検索の柔軟性を考慮しながら、比較的低い、又は許容可能であると考えられてよい。

本クエリシステムをより良く理解するために、以下の例が考えられる。

図４は、相関データベースにおいて実現される単純なテーブル（「電話番号（PhoneNumbers）」と題される。）の例である。

テーブルの左端の列は一次キー（ＰｒｉｍａｒｙＫｅｙ）用であり、データ行を一意に識別する。各行は、然るべく、データ入力である。中央の列は、各データ入力に対応する電話番号の所有者の名称（Ｏｗｎｅｒ）用であり、名称はタイプ「文字列（string）」によって表されている。右端の列は、各データ入力に対応する電話番号（ＰｈｏｎｅＮｕｍｂｅｒ）を識別するためのものであり、番号はタイプ「整数（integer）」によって表されている。

図４から分かるように、Ｈａｒｒｙ及び彼の妻（Ｈａｒｒｙ Ｈｉｒｓｃｈ’ｓ Ｗｉｆｅ）は各自２つの電話番号を有し、彼らはそのうちの１つを共有している。

引き続き、データベース内の行は、次のようなクエリを用いて識別され得る（理解を容易にするために、ＳＱＬのようなシンタックスが用いられる。）：
・select PrimaryKey from PhoneNumber
・where Owner=”Harry Hirsch” and PhoneNumber=”2402333333”
（所有者がＨａｒｒｙ Ｈｉｒｓｃｈであり且つ電話番号が２４０２３３３３３３である場合について、ＰｈｏｎｅＮｕｍｂｅｒからＰｒｉｍａｒｙＫｅｙを選択せよ。）
このようなクエリは、“PrimaryKey=4873328390”を返す。

両方の環境（データベース及び検索エンジン）にわたってこのようなクエリを使用することができるために、同様のスキームが検索エンジンに対して用いられてよい。先に述べられたように、検索エンジンは、通常は、複雑なデータを記憶せず、２タプル（すなわち、対）のデータ（通常、「文書（document）」（ＩＤ）及び値又は語と呼ばれる。）のみを扱う。

図４のテーブルのデータを検索エンジンにおける使用のためのデータの対に変換する種々の方法が存在する。本例においては、所謂「逆索引（inverted index）」が、図５に示される逆索引を生成するために使用される。

図５において、「文書（Ｄｏｃｕｍｅｎｔ）」は、データベースにおける「一次キー（ＰｒｉｍａｒｙＫｅｙ）」と等価である。逆索引において、「語（Ｗｏｒｄ）」は、1以上のＤｏｃｕｍｅｎｔと関連づけられる。図５から明らかなように、単一のデータベース行は、インデックスにおいて複数の入力に分けられる。しかし、データの量は、データベースに記憶されているデータの量とおおよそ等しく、一方、記憶空間の必要とされる量は、インデックスに関して僅かに大きい。

図5に図示されるように、Ｗｏｒｄ部は、データベースに記憶されているテーブル（図４参照）のテーブル名を含む。これは、属性名が単一のテーブル内でのみ一意であり、全てのテーブルにわたっては一意でないので、重要でありうる。

上記の例におけるＳＱＬ記述の結果は、このようにして、共通集合を介して検索エンジンにおいて達成され得る：
・documentsA=documents(“PhoneNumbers/Owner=Harry Hirsch”)=4873328390, 4873328393
・documentsB=documents(“PhoneNumbers/PhoneNumber=2402748345”)=4873328390, 4873328391
・result=documentsA∩documentsB=4873328390
当然に、上記の例は、データベースに記憶されているデータが如何にして検索エンジンに利用可能にされ得るかに係る単なる一例である。大まかに言って、実施形態は、検索エンジンシステム及びデータベースシステムの両方で利用可能であるようにデータの記憶を扱うよう動作可能な同期化手段を有すると考えられてよい。

図６は、クエリシステム４０の概略図である。クエリシステム４０は、クエリシステム１と同じであり、コンピュータデバイス４２を有する。コンピュータデバイス４２は、分析及び決定手段４と、検索エンジンシステム６と、データベースシステム８とを有する。更に、クエリシステム４０は同期化手段４４を有する。当然のことながら、クエリシステム４０は、クエリシステム１０と同じく、分散された形態において提供されてもよい。

同期化手段４４は、非テキスト中心の同期化処理として、データベースシステム８の非テキスト中心のエンティティ（データ入力）を（それがデータベースシステム８に記憶された後、それがデータベースシステム８に記憶される前、又は記憶処理の間に）その非テキスト中心のエンティティを表す対応するテキスト中心のエンティティ（データ入力）に変換し、該テキスト中心のエンティティを検索エンジンシステム６のインデックスに入力するよう動作可能である。入力（インデックス入力）は、そのテキスト中心のエンティティから生じるインデックスにおける各入力をデータベースシステム８の対応する非テキスト中心のエンティティに関連づける対応情報とともに、インデックスに対して行われてよく、それにより、２つのシステム６及び８は、互いに対して参照される。

同期化手段４４は、データベースシステム８の全ての非テキスト中心の入力に対して非テキスト中心の同期化処理を実行するよう動作可能であってよい。

同様に、同期化手段４４は、テキスト中心の同期化処理として、データベースシステム８のテキスト中心のエンティティを（それがデータベースシステム８に記憶された後、それがデータベースシステム８に記憶される前、又は記憶処理の間に）検索エンジンシステム６のインデックスに入力するよう動作可能である。入力は、そのテキスト中心のエンティティから生じるインデックスにおける各入力をデータベースシステム８の対応するテキスト中心のエンティティに関連づける対応情報とともに、インデックスに対して行われてよく、それにより、２つのシステム６及び８は、互いに対して参照される。

同期化手段４４は、データベースシステム８の全てのテキスト中心の入力に対してテキスト中心の同期化処理を実行するよう動作可能であってよい。

このような同期化手段４４は、クエリシステム４０によって検索可能なデータが変更される場合に、その変更がデータベースシステム８及び検索エンジンシステム６の両方において表されるよう動作可能であってよい。かかる変更は、新しいデータ入力の生成、既存のデータ入力の更新、又は既存のデータ入力の削除であってよく、例えば、そのようなデータはデータベースのデータである。

従って、当然のことながら、同期化手段４４は、図３におけるＣＵＤ機能３２に対応してよい。

上記の例のクエリ（ＳＱＬにおいて表される。）は、単なる例としてのクエリであり、当然に、データベースシステム又は検索エンジンシステムにおいて実行され得る他のタイプのクエリが存在してよい。速度及び／又は品質は、どのシステムにおいてクエリが実行されるのかに依存して異なりうる。例えば、図４及び図５に関連して与えられた上記の例は、検索エンジンシステムにおいてよりも（相関）データベースシステム（ＲＤＢＭＳ）においてより良く動作してよい。

クエリがいずれか一方のシステムにおいて実行される場合に、本クエリシステムは、データ操作システムのうち特定の環境において最良の性能を提供する方を用いて、両方の世界（データベース及び検索エンジン）のうち最良のものを利用しようとする。

以下、２つのシステム、すなわち、検索エンジンシステム及びデータベースシステムの同期化について更に検討する。

検索エンジン及びデータベースは、ジャスト・イン・タイムのクエリを実行することができるために、同期化されてよい。この同期化は、ＣＵＤ機能３２又は同期化手段４４を用いて、生成／更新／削除（ＣＵＤ）動作を制御することによって行われてよい。

望ましくは、このＣＵＤ動作は、一方のデータ操作システム（検索エンジンシステム又はデータベースシステム）において動作を実行できなかったことが他方における動作をロールバックするように、トランザクション・スコープ（transaction scope）によって保護される。従って、ＣＵＤ動作のアトミック性は、動作が両方のデータ操作システムにおいて実行される場合にのみ、達成される。

これに関連して、図７及び図８が参照される。

図７は、図３の考慮されるシステムアーキテクチャ２０に関連する概略図であり、システムアーキテクチャ２０の様々な要素がＣＵＤ動作の実行時に如何にして用いられ得るのかを示す。

アーキテクチャ２０の様々な要素は、図７において、一番上の箱によって表されており、対比を容易にするために図３で用いられたのと同じ参照符号を付されている。例えば、図７において「client:Client」とラベルを付されている箱は、図３のアプリケーション２２に対応する。図７において表されている様々な動作は、１、１．１．１、１．１．２、１．１．３、１．１．４及び２とラベルを付されて、以下で参照される。

図８は、図７に対応するアクティビティ図であり、ＣＵＤ動作のトランザクション・コンテクスト（transaction context）を表す。図８において表されている様々なステップは、Ｓ２乃至Ｓ２０の偶数ステップとして表され、以下で参照される。

図示されるように、ＣＵＤ動作は、例えば、クライアントマシンで出されたユーザ要求に応答して、アプリケーション２２によって起動されてよい。これは、図８のステップＳ２によって表されている。

次いで、アプリケーション２２は、ＣＵＤトランザクションを開始してよく（図８のステップＳ４）、一例として、全体的な「記憶（store）」トランザクション／動作（生成動作）を考えると、このステップは、動作１としての図７の記憶動作（store(data)）の開始として続けられる。

次いで、ＡＰＩ２４は、ステップＳ６において新しいデータを記憶するようデータベース２８と相互に作用し、図７の対応する動作１．１．１及び１．１．２により、この記憶動作が成功したかどうかが、ステップＳ８において判断される。

データベース２８における記憶動作が成功した場合に（ステップＳ８における‘真’）、方法はステップＳ１０に進む。

ステップＳ１０において、ＡＰＩ２４は、（例えば、検索エンジン２６のインデックスに入力することによって）新しいデータを記憶するよう検索エンジン２６と相互に作用し、図７の対応する動作１．１．３及び１．１．４により、この記憶動作が成功したかどうかが、ステップＳ１２において判断される。

検索エンジン２６における記憶動作が成功した場合に（ステップＳ１２における‘真’）、方法はステップＳ１４に進む。ステップＳ１４で、全体的な記憶トランザクションがコミットされる、すなわち、成功とみなされる。次いで、（成功を示す）結果が、図７の対応する動作２により、ステップＳ１６でユーザに返される。

当然に、ステップＳ６又はＳ１０は不成功であることもある。その場合に（ステップＳ８又はＳ１２における‘偽’）、トランザクションはステップＳ１８においてロールバックされる。トランザクションは、（アトミック性のために）データベース及び検索エンジンに及ぶべきであり、従って、「分散トランザクション（distributed transaction）」と呼ばれることがある。すなわち、トランザクションがデータベース及び検索エンジンに成功裏に及ばない場合には、行われた如何なる変更も、検索エンジン２６及びデータベース２８が、あたかもトランザクションが開始されなかった化のような状態にあるように、元に戻され又は巻き戻される。次いで、方法はステップＳ２０に進む。ステップＳ２０で、（失敗を示す）結果がユーザに返される。

以下、クエリ又はクエリ要求の処理について更に検討する。

先に述べられたように、クエリが検索エンジンシステム又はデータベースシステムにおいて実行される場合に、本クエリシステムは、データ操作システムのうち特定の環境において最良の性能を提供する方を用いて、両方の世界（データベース及び検索エンジン）のうち最良のものを利用しようとする。

本実施形態においては、クエリ要求（人又は他のアプリケーション若しくはシステムであってよいユーザによって提起される。）は、分析及び決定手段（図１、２及び６における分析及び決定手段４及び１４、並びに図３におけるＡＰＩ２４の対応するクエリ機能３０を参照）によって実施されるシステムの複合クエリエンジンによって解釈される。

クエリは単純であってよく、例えば、事実上ただ１つのクエリ処理のみが実行されることを求め、あるいは、クエリは複雑であってよく、例えば、複数のクエリ処理が実行され、それらの処理の結果が集められ又は何らかの方法で結合されることを求める。

複雑なクエリの場合に、クエリは、例えば、抽象構文木（abstract syntax tree）（ＡＳＴ）ストラテジを用いて分割されてよい。簡単に言えば、複雑なクエリは、次いで実行され得るアトミック動作の組に分けられてよい。このアプローチ（又は、例えばＬＲ若しくはＬＬ文法を用いる同様のもの）は、クエリを分ける従前考えられている方法により実施されてよい。しかし、当然のことながら、本クエリシステムは、単なる単一データ操作システムに代えて、複数のデータ操作システム（例えば、データベースシステム及び検索エンジンシステム）におけるヘテロジニアス実行（heterogeneous execution）の能力がある。

このようなアトミック動作は、それらが選択又は非選択動作を構成するかどうかに関して考えられてよい。１つの目的は、検索エンジンの適用範囲内にある「条件付け（qualifying）」選択動作を識別することであってよい。例えば、検索エンジンは、通常、基本的には、キーワード又はボキャブラリ技術に基づき、このような技術に依る動作が識別されてよい。

条件付け選択は、クエリ又はクエリの関連要素によって特定されるフィルタリング基準のタイプによって、識別され得る。例えば：
１．データベースの適用範囲内で簡単に利用可能でない検索エンジン中心の表現。該表現には、例えば、次のものがある：
・音声類似度（ファジー検索）
・語幹処理（stemming）（複数形、過去形等を含めるための共通末尾を有する語の拡張）
・近接検索（例えば、「information system~3」は、語「information」及び「system」が互いから３語の距離内にある記録を取り出す。）
２．非テキスト属性に対して実行される正規表現。例えば：
・date=”19[5|6][0..9]/01/01”
３．バイナリ文書（例えば、ＭＳワード文書）のような（データベースから見た）ＢＬＯＢ属性に対する動作。

タイプ１）及び３）の幾つかの動作は、幾つかのデータベースにおいてサポートされてよいが、タイプ２）の動作は、通常はサポートされない。

ここで、図９を参照する。図９は、データベースシステム又は検索エンジンシステムにおいて特定のクエリ処理（クエリのクエリ要素に対応する。）を実行すべきかどうかを決定するために用いられる方法を表すフロー図である。すなわち、図９のフロー図は、データベースと検索エンジンとの間の適用範囲の分割に関連する。

要約すると、動作（クエリ要素）は、そのデータタイプ及びオペランドに従って分析されてよい。データタイプおよびオペランドが一致する場合に、その動作は、（動作がデータベースの文法によりコンパイルする場合に、）データベースによって処理されるべきであると推測される。そうではない場合に、動作は、検索エンジン機能に対してチェックされ、可能ならば検索エンジンによって処理されてよい。

図９のフロー図は、偶数ステップＳ３０乃至Ｓ４８を有する。

ステップＳ３０で、動作（クエリ要素）が分析される。動作において特定されるデータタイプが動作において特定される右オペランド（right-operand）と一致すると判断される場合には（ステップＳ３２における‘一致’）、方法はステップＳ３４に進む。そうではない場合には（ステップＳ３２における‘不一致’）、方法はステップＳ４４に進む。

ステップＳ３４で、動作のシンタックスがデータベースの文法に対してチェックされる。動作のシンタックスがデータベースの文法に従うと判断される場合には（ステップＳ３６における‘はい’）、方法はステップＳ３８に進む。そうではない場合には（ステップＳ３６における‘いいえ’）、方法はステップＳ４０に進む。

ステップＳ３８で、動作は、データベースの適用範囲内にあるとマークされる。すなわち、動作はデータベースで実行されるべきであると決定され、方法は成功裏に終了する。

ステップＳ４０で、動作の右オペランドがＳｔｒｉｎｇ（すなわち、タイプ「文字列」）であるかどうかが確認される。動作の右オペランドがＳｔｒｉｎｇであると判断される場合には（ステップＳ４０における‘はい’）、方法はステップＳ４２に進む。そうではない場合には（ステップＳ４０における‘いいえ’）、方法は不成功に終わり、エラーが記録／出力される。

ステップＳ４２で、動作のシンタックスが検索エンジンの文法に対してチェックされる。動作のシンタックスが検索エンジンの文法に従うと判断される場合には（ステップＳ４６における‘はい’）、方法はステップＳ４８に進む。そうではない場合には（ステップＳ４６における‘いいえ’）、方法は不成功に終わり、エラーが記録／出力される。

ステップＳ４８で、動作は、検索エンジンの適用範囲内にあるとマークされる。すなわち、動作は検索エンジンで実行されるべきであると決定され、方法は成功裏に終了する。

本機能を更に理解するために、図１０に関連した例が考えられる。図１０は、複雑なクエリの例を表し、（理解を容易にするために、ＳＱＬのような構文を用いて表されている。）ＡＮＳＩ標準に準拠した相関データベース及び従前考えられている検索エンジンを仮定する。

この例は２つのエンティティを仮定する。具体的に、一方は、従業員に関する基本データを含み、他方は、技能情報を含む。

また、この例は、「Ｊａｃｋ」というファーストネームを有し、１９５０年代から６０年代に生まれ、化学、電気科学又はある種の地質研究分野における何らかの技術背景を有する全ての人の経歴を有したいという望みを仮定するとともに、結果が雇用会社に従ってグループ化されるべきであると仮定する。

図１０に図示されるように、クエリの幾つかの部分は、データベースにおける実行により適すると判断され、他は、検索エンジンにおける実行により適すると判断される。

以下の分割が考えられる：
・people.birthDate=’19[5|6][0..9]/??/??’
データベース（ＤＢ）は、通常、その生来のフォーマット、通例は数字（例えば、一般的に、１９７０年１月１以降のミリ秒又は秒）でデータオブジェクトを記憶する。クエリパーサー（parser）は、クエリの条件を分析し、正規表現がその条件と相容れないデータタイプに関連するためにデータベースによってはクエリが処理され得ないと認める。しかし、検索エンジンはこれを処理してよい。

・people.firstName=”Jack~”
これは、ごく典型的な検索エンジン要求である。「~」は、全ての「Ｊａｃｋ」のみならず、例えば「Ｊａｃｑｌｉｎｅ」といった音声学的に同じ名前を持った人々も返す意図を伝える。

・skill.summary=’*enginner*[chemistry|electrical|geo]’
技能概要が例えばワード文書（ＢＬＯＢ）において記憶されているとすると、それは典型的なデータベースによってはクエリされ得ないので、この要素は、検索エンジンクエリの他の候補であると考えられてよい。

従って、これら３つの条件は検索エンジンによって実行され得る。結果は、２つの組の「skill」及び「people」ＩＤである。

これらの結果は、以下：
・people.id=skill.peopleId
において使用され得る。これは、共有される属性に基づく２つのエンティティの典型的な結合又は共通集合であり、これは、データベースにおいて実行されてよい（なお、たとえ低速であっても、検索エンジンにおいて実行されてもよい。）。

・group by people.employer
これは、結果が従業員の雇用者によってグループ化されるべきことを述べる。典型的な検索エンジンはグループ化することができず、一方、相関データベースはできる。

最終的に、本例の目的は、従業員の名前、雇用者及び従業員の経歴を出力することである。典型的な検索エンジンは、データ整合性（integrity）を補償せず（例えば、それは、通常、マイクロソフト（登録商標）ワード版の経歴を記憶しない。）、一方、典型的なデータベースは補償する。すなわち、（典型的な、従前考えられている）検索エンジンに入れられる文書は、普通は、再度取り出され得ない。このように、データベースは、本例のこの部分において有効でありうる。

従って、当然のことながら、データベース及び検索エンジンの機能に依存して、規則セットは、クエリの一部が特定の目的の環境（検索エンジン又はデータベース）によって実行されることを可能にするよう定義されてよい。

図１１は、クエリをその構成クエリ要素（動作）に分割し、様々な動作を検索エンジン又はデータベースにおいて順次に実行し、結果を何らかの方法で結合することに関与する抽象プロシージャを表すことを目的とするフロー図である。

図１１のクエリプロシージャは、複合クエリ動作フローであると考えられてよく、且つ、次の抽象ステップを有すると考えられてよい：
１．クエリの分析
２．抽象構文木（ＡＳＴ）の生成
３．個々の動作ごとの対象エンジン（データベースシステム又は検索エンジンシステム）の識別
４．個々の動作のキューイング（queuing）
５．キューイングされた動作をループし、対象エンジンにおいて動作を実行し、結果をインターセクトする
６．応答の組み立て。

多数のカプセル化されるアトミック動作は、目的のデータ操作システム又は対象エンジン（すなわち、データベースシステム又は検索エンジンシステム）によって１度に実行されるために、サブクエリにまとめられてよい。次いで、異なるサブクエリは、専用の動作キューに入れられ、それらの分類（すなわち、データベースに適するか、それとも、検索エンジンに適するか）に従って処理されてよい。

次いで、最終の結果オブジェクトは、データベースのみがデータの整合性及び完全性を確保することができる可能性があるので、データベースから供給されてよい。

図１１のプロシージャは、偶数ステップＳ５０乃至Ｓ７０を有する。

ステップＳ５０で、クエリ（例えば、複雑なクエリ）が受け取られる。

ステップＳ５２で、クエリは、そのクエリが複雑であり、複数のクエリ要素（すなわち、例えば図１０に図示されるように別々に操作するのに適したクエリの部分）から構成されるかどうかを決定するよう分析される。ＡＳＴ（抽象構文木）アプローチがステップＳ５２において導入されてよい。クエリのクエリ要素は、このようにして、このステップにおいて識別される。

ステップＳ５４で、各クエリ要素は、適切な対象エンジンを割り当てられる。すなわち、各クエリ要素ごとに、その対応するクエリ処理／動作がデータベースシステム又は検索エンジンシステムのいずれにおいて実行されるべきかが決定される。図１０に関連して先に述べられた事項は、例えば、そのような決定を行う際に考慮されてよい。

また、ステップＳ５４で、クエリ要素に対応するクエリ動作又は処理は、順次にキューイングされる。その順序は、クエリ動作間のあらゆる依存及び原のクエリにおける順序付けを考慮しながら、短い時間期間に所望の最終結果を得るのに適したものである。付随的に、クエリ処理は図１１のプロシージャにおいては順次的に、すなわち、１つずつで、行われるが、２つの別個のエンジン（検索エンジン及びデータベース）の使用は、クエリ動作の幾つかが並行して行われることを可能にする。

ステップＳ５６で、順序における最初のクエリ動作がキューからデキューイングされ、ステップＳ５８で、それは、必要に応じて、何らかの予め選択されたデータを（例えば、後のクエリ動作のために、前のクエリ動作に基づき得られる情報を）準備される。

ステップＳ６０で、現在のクエリ動作について、それがデータベース又は検索エンジンのいずれにおいて実行されるべきかが決定される。動作がデータベースにおいて実行されるべきであると決定される場合には（ステップＳ６０における‘ＤＢ中心’）、方法はステップＳ６２に進む。ステップＳ６２で、対応するデータベースクエリが実行される。動作が検索エンジンにおいて実行されるべきと決定される場合には（ステップＳ６０においける‘検索中心’）、方法はステップＳ６４に進む。ステップＳ６４で、対応する検索エンジンクエリが実行される。

ステップＳ６２及びＳ６４のいずれか一方の後、方法はステップＳ６６に進む。ステップＳ６６で、得られた結果は、あらゆる既に得られた結果、及び必要に応じて、あらゆる予め選択されたデータとインターセクトされる。

方法はステップＳ６８に進み、ステップＳ６８で、キューが空であるかどうか、すなわち、キューイングされた動作の全てが実行されたかどうかが判断される。キューが空ではないと判断される場合には（ステップＳ６８における‘いいえ’）、方法はステップＳ５６に戻り、ステップＳ５６で、順序において次のクエリ動作がキューからデキューイングされる。キューが空である場合には（ステップＳ６８における‘はい’）、方法はステップＳ７０に進み、ステップＳ７０で、最終の応答が組み立てられる。

明確な／周知の環境の中で、更なるシナリオを特定することも可能である。例えば、ＯＯＤＢＭＳを考えた場合、データベースは一般的にテキスト中心の動作にとっては遅すぎることがあるので、単に検索エンジンによってテーブル状の結果を有して全ての選択を実行することが、実現性がある。

特に、ネットワークに基づく実施形態においては、トレードオフは、複数のデータ操作システムからの結果を結合するために必要とされるネットワークトラフィックの増大とクエリ出力の増大との間で考慮される必要があると分かる。従って、実施形態は、一般原則においてクエリ能力を用いるのではなく、主として、大いに柔軟な入力要件を有するテキスト中心のアプリケーションのためにそれらを用いてよい。

ここで提示される複合クエリエンジンアプローチは、次の利点を有すると考えられる：
ａ）かかるクエリシステムは、データ属性に対して比較的緩いタイプ制約を有しうる。根拠として、全てのデータは、文字列として（すなわち、テキスト形態で）扱われ、必要に応じて然るべく処理されてよい。
ｂ）検索エンジンのクエリ機能は、データベースのクエリ機能と結合される。この柔軟性は、例えば、エンドユーザの観点から検索フォームフィールドの能力を高めるために使用されてよい。
ｃ）かかるクエリシステムは、データタイプと組み合わせて右作用の特性に従って適切な目的のシステム（データベース又は検索エンジン）を検出してよい。
ｄ）複合クエリエンジンをデータベース及び検索エンジンの上に置くことによって、根底で標準化された又は認定されたデータベースクエリ言語の使用を仮定して、データベース及び／又は検索エンジンがプラグ着脱可能である（製造者に依存しない）と考えることが可能である。

以上の開示は、一般的なデータベースシステム及び検索エンジンに基づく複雑なデータクエリの性能及び能力を高めるために、複数のアトミック動作を処理して、対応する結果セットをインターセクトする最も適切なクエリエンジンの選択のための前提条件及び方法を検討している。

簡単に言えば、本発明の実施形態は、有利に、クエリ要素によって対象とされる属性タイプ（属性範囲）に関して厳密な憶測を立てる必要がないと認められる。例えば、データクエリ要素が、（データベースシステムによって処理されるべき）従来のデータオブジェクトのように、又は（検索エンジンシステムによって処理されるべき）特定の文字列表現において、入力されているかどうかは、比較的重要でない。属性は、これを可能にするよう、データベースシステム及び検索エンジンシステムの両方に記憶され（幾つかの場合においては、常に記憶され）てよい。当然に、クエリ全体は、所定のシンタックスと一致する必要があるが、クエリの自由／出力の程度は、従前考えられているシステムの程度と比較して拡大され得る。本発明の実施形態は、クエリオペランドの範囲に関して厳密な憶測を立てることなく、クエリ要素に対応するクエリ動作を実行する際に使用されると記載されてよい。

上記の側面のいずれにおいても、種々の特徴は、ハードウェアで、又は１以上のプロセッサで実行されるソフトウェアとして、実施されてよい。１つの側面に係る特徴は、他の側面のいずれに適用されてもよい。

また、本発明は、ここで記載される方法のいずれかを実行するコンピュータプログラム又はコンピュータプログラムプロダクト、及びここで記載される方法のいずれか実行するプログラムを記憶したコンピュータ可読媒体を提供する。本発明を具現するコンピュータプログラムは、コンピュータ可読媒体に記憶されてよく、あるいは、それは、インターネットのウェブサイトから提供されるダウンロード可能なデータ信号等の信号の形をとってよく、あるいは、それは他の何らかの形態を取ってよい。

以上の実施形態に関し、更に以下の付記を開示する。

（付記１）
データベースシステム及び／又は検索エンジンシステムにおいて受信したクエリ要素に対応するクエリ処理を実行するクエリシステムであって、
前記データベースシステムの非テキスト中心のデータ入力を該非テキスト中心のデータ入力を表す対応するテキスト中心のデータ入力に変換し、該テキスト中心のデータ入力を前記検索エンジンシステムのインデックスに入力して、前記データベースシステムの前記非テキスト中心のデータ入力が前記検索エンジンシステム及び前記データベースシステムの両方で利用可能であるようにするよう、非テキスト中心の同期化処理として動作する同期化手段
を有するクエリシステム。
（付記２）
前記同期化手段は、前記テキスト中心のデータ入力を、該テキスト中心のデータ入力から生じる前記インデックスにおける各インデックス入力を前記データベースシステムの対応する非テキスト中心のデータ入力と関連づける対応情報とともに、前記検索エンジンシステムの前記インデックスに入力するよう、前記非テキスト中心の同期化処理において動作する、
付記１に記載のクエリシステム。
（付記３）
前記同期化手段は、前記データベースシステムの全ての非テキスト中心のデータ入力に関して前記非テキスト中心の同期化処理を実行するよう動作する、
付記１又は２に記載のクエリシステム。
（付記４）
前記同期化手段は、前記データベースシステムのテキスト中心のデータ入力を、該テキスト中心のデータ入力から生じる前記インデックスにおける各インデックス入力を前記データベースシステムの対応するテキスト中心のデータ入力と関連づける対応情報とともに、前記検索エンジンシステムの前記インデックスに入力するよう、テキスト中心の同期化処理として動作する、
付記１乃至３のうちいずれか一項に記載のクエリシステム。
（付記５）
前記同期化手段は、前記データベースシステムの全てのテキスト中心のデータ入力に関して前記テキスト中心の同期化処理を実行するよう動作する、
付記４に記載のクエリシステム。
（付記６）
前記同期化手段は、当該クエリシステムによって検索可能な情報が変更される場合に、該変更が前記データベースシステム及び前記検索エンジンシステムの両方において表されるよう動作する、
付記１乃至５のうちいずれか一項に記載のクエリシステム。
（付記７）
前記変更は、新しいデータ入力の生成、既存のデータ入力の更新、又は既存のデータ入力の削除である、
付記６に記載のクエリシステム。
（付記８）
前記クエリ要素に対応する前記クエリ処理を実行する際に使用される該クエリ要素を分析するよう動作する分析手段と、
前記データベースシステム及び／又は前記検索エンジンシステムにおいて前記クエリ処理を実行すべきかどうかを前記分析に依存して決定するよう動作する決定手段と
を更に有する付記１乃至７のうちいずれか一項に記載のクエリシステム。
（付記９）
前記決定手段は、前記クエリ要素が前記データベースシステムによってサポートされる検索式に関すると前記分析が示す場合に、前記クエリ処理が前記データベースシステムにおいて実行されるべきと決定するよう動作する、
付記８に記載のクエリシステム。
（付記１０）
前記決定手段は、前記クエリ要素が前記データベースシステムによってはサポートされないが前記検索エンジンシステムによってはサポートされる検索式に関すると前記分析が示す場合に、前記クエリ処理が前記検索エンジンシステムにおいて実行されるべきと決定するよう動作する、
付記８又は９に記載のクエリシステム。
（付記１１）
前記決定手段は、前記クエリ要素が検索エンジン中心の選択動作に関すると前記分析が示す場合に、前記クエリ処理が前記検索エンジンシステムにおいて実行されるべきと決定するよう動作する、
付記８乃至１０のうちいずれか一項に記載のクエリシステム。
（付記１２）
前記クエリ処理が前記データベースシステムにおいて実行されるべきと決定される場合には該データベースシステムにおいて、及び／又は前記クエリ処理が前記検索エンジンシステムにおいて実行されるべきと決定される場合には該検索エンジンシステムにおいて前記クエリ処理を実行するよう動作する実行手段
を更に有する付記１乃至１１のうちいずれか一項に記載のクエリシステム。
（付記１３）
受信したクエリを複数のコンポーネントクエリ要素に分割するよう動作するクエリ分割手段を更に有し、
当該クエリシステムは、クエリ要素ごとに前記クエリ処理を実行するよう動作する、
付記１乃至１２のうちいずれか一項に記載のクエリシステム。
（付記１４）
前記受信したクエリに依存した順序で前記複数のクエリ要素をキューイングするよう動作するキューイング手段を更に有し、
当該クエリシステムは、前記順序でクエリ要素ごとに前記クエリ処理を実行するよう動作する、
付記１３に記載のクエリシステム。
（付記１５）
データベースシステム及び／又は検索エンジンシステムにおいて受信したクエリ要素に対応するクエリ処理を実行するクエリシステムのコンピュータ装置で実行される場合に、該装置にクエリシステム方法を実行させるコンピュータプログラムであって、
前記方法は、
非テキスト中心の同期化処理として、前記データベースシステムの非テキスト中心のデータ入力を該非テキスト中心のデータ入力を表す対応するテキスト中心のデータ入力に変換し、該テキスト中心のデータ入力を前記検索エンジンシステムのインデックスに入力して、前記データベースシステムの前記非テキスト中心のデータ入力が前記検索エンジンシステム及び前記データベースシステムの両方で利用可能であるようにする、
コンピュータプログラム。

１，１０，４０ クエリシステム
２，４２ ローカルデバイス（コンピュータデバイス）
４，１４ 分析及び決定手段
６，１６ 検索エンジンシステム
８，１８ データベースシステム
１１ ネットワーク
２０ システムアーキテクチャ
２２ アプリケーション
２４ 持続ＡＰＩ
２６ 検索エンジン
２８ データベース
３０ クエリ機能
３２ ＣＵＤ（生成／更新／削除）機能
４４ 同期化手段

Claims (10)

1. データベースシステム及び／又は検索エンジンシステムにおいて受信したクエリ要素に対応するクエリ処理を実行するクエリシステムであって、
   前記データベースシステムの非テキスト中心のデータ入力を該非テキスト中心のデータ入力を表す対応するテキスト中心のデータ入力に変換し、該テキスト中心のデータ入力を前記検索エンジンシステムのインデックスに入力して、前記データベースシステムの前記非テキスト中心のデータ入力が前記検索エンジンシステム及び前記データベースシステムの両方で利用可能であるようにするよう、非テキスト中心の同期化処理として動作する同期化手段
   を有するクエリシステム。
2. 前記同期化手段は、前記テキスト中心のデータ入力を、該テキスト中心のデータ入力から生じる前記インデックスにおける各インデックス入力を前記データベースシステムの対応する非テキスト中心のデータ入力と関連づける対応情報とともに、前記検索エンジンシステムの前記インデックスに入力するよう、前記非テキスト中心の同期化処理において動作する、
   請求項１に記載のクエリシステム。
3. 前記同期化手段は、前記データベースシステムの全ての非テキスト中心のデータ入力に関して前記非テキスト中心の同期化処理を実行するよう動作する、
   請求項１又は２に記載のクエリシステム。
4. 前記同期化手段は、前記データベースシステムのテキスト中心のデータ入力を、該テキスト中心のデータ入力から生じる前記インデックスにおける各インデックス入力を前記データベースシステムの対応するテキスト中心のデータ入力と関連づける対応情報とともに、前記検索エンジンシステムの前記インデックスに入力するよう、テキスト中心の同期化処理として動作する、
   請求項１乃至３のうちいずれか一項に記載のクエリシステム。
5. 前記同期化手段は、当該クエリシステムによって検索可能な情報が変更される場合に、該変更が前記データベースシステム及び前記検索エンジンシステムの両方において表されるよう動作する、
   請求項１乃至４のうちいずれか一項に記載のクエリシステム。
6. 前記クエリ要素に対応する前記クエリ処理を実行する際に使用される該クエリ要素を分析するよう動作する分析手段と、
   前記データベースシステム及び／又は前記検索エンジンシステムにおいて前記クエリ処理を実行すべきかどうかを前記分析に依存して決定するよう動作する決定手段と
   を更に有する請求項１乃至５のうちいずれか一項に記載のクエリシステム。
7. 前記決定手段は、前記クエリ要素が前記データベースシステムによってサポートされる検索式に関すると前記分析が示す場合に、前記クエリ処理が前記データベースシステムにおいて実行されるべきと決定するよう動作する、
   請求項６に記載のクエリシステム。
8. 前記クエリ処理が前記データベースシステムにおいて実行されるべきと決定される場合には該データベースシステムにおいて、及び／又は前記クエリ処理が前記検索エンジンシステムにおいて実行されるべきと決定される場合には該検索エンジンシステムにおいて前記クエリ処理を実行するよう動作する実行手段
   を更に有する請求項１乃至７のうちいずれか一項に記載のクエリシステム。
9. 受信したクエリを複数のコンポーネントクエリ要素に分割するよう動作するクエリ分割手段を更に有し、
   当該クエリシステムは、クエリ要素ごとに前記クエリ処理を実行するよう動作する、
   請求項１乃至８のうちいずれか一項に記載のクエリシステム。
10. データベースシステム及び／又は検索エンジンシステムにおいて受信したクエリ要素に対応するクエリ処理を実行するクエリシステムのコンピュータ装置で実行される場合に、該装置にクエリシステム方法を実行させるコンピュータプログラムであって、
    前記方法は、
    非テキスト中心の同期化処理として、前記データベースシステムの非テキスト中心のデータ入力を該非テキスト中心のデータ入力を表す対応するテキスト中心のデータ入力に変換し、該テキスト中心のデータ入力を前記検索エンジンシステムのインデックスに入力して、前記データベースシステムの前記非テキスト中心のデータ入力が前記検索エンジンシステム及び前記データベースシステムの両方で利用可能であるようにする、
    コンピュータプログラム。

Images