(57)【要約】【課題】統合検索装置において、検索実行結果の転送量を軽減異種情報源の高速な統合検索を行う。【解決手段】構文解析部１２はユーザインタフェース部１１が受け付けた問い合せ１０１の構文を解析し、問い合わせ内部モデル１０２に変換する。ビュー所在部１３aは、問い合せ１０１中で指定されたビューが、情報源に格納されている情報を登録したビューか、または問い合せ１０１を用いて定義したビューかを判定する。前記のビューの定義に用いられた問い合せを解析し内部モデルへ変換する。内部モデル合成部１３bは得られた内部モデルが複数であれば、それらを合成する。内部モデル分割部１３cは合成された内部モデルを最適化し、最適化された内部モデルを検索命令文へと変換するための内部モデル１０８と個々の情報源の検索結果を統合するための内部モデル１１２とに分割する。ラッパー１４1、１４2は検索内部モデル１０８を検索命令文１０９1、１０９2へと変換する。【選択図】      図１
2004206640.tif 000002
【特許請求の範囲】
【請求項１】
入力された問い合せを、該問い合せが要求する情報を情報源から得るための検索命令文へと変換するステップと、変換された検索命令文を前記情報源に送信し、検索を実行させるステップと、前記情報源での検索実行結果を、前記問い合せが要求している情報へと統合するステップとを有する、木構造代数モデルを利用した統合検索方法。
【請求項２】
入力された問い合せを、該問い合わせが要求する情報を情報源から得るための検索命令文へと変換するステップは、該問い合わせを解析し内部モデルへ変換するステップと、該内部モデル中で指定されているビューが、前記情報源に格納されている情報を登録したビューか、または問い合せを用いて定義されたビューかを判定するステップと、前記のビューの定義に用いられた問い合せを解析し内部モデルへ変換するステップと、前記の得られた内部モデルが複数あれば、それらを合成するステップと、該合成された内部モデルを最適化するステップと、最適化された内部モデルあるいは得られた内部モデルが１つの場合、該内部モデルを検索命令文へと変換するための内部モデルと個々の情報源の検索結果を統合するための内部モデルとに分割するステップと、検索命令文へと変換するための内部モデルを検索命令文へと変換するステップとを有する、請求項１に記載の木構造代数モデルを利用した統合検索方法。
【請求項３】
問い合せを解析し内部モデルへ変換するステップは、内部モデルの構成要素である演算子の出現順序によって問い合せを表現する内部モデルへと変換するステップである、請求項２に記載の木構造代数モデルを利用した統合検索方法。
【請求項４】
得られた内部モデルが複数あれば、それらを合成するステップは、内部モデルの構成要素である演算子同士の合成規則に基づいて内部モデルを合成するステップである、請求項２または３に記載の木構造代数モデルを利用した統合検索方法。
【請求項５】
合成された内部モデルを最適化するステップは、内部モデルの構成要素である演算子同士の交換規則に基づいて、演算子の出現順序を変更し、効率のよい演算子出現順序を選択するステップである、請求項２から４のいずれかに記載の木構造代数モデルを利用した統合検索方法。
【請求項６】
最適化された内部モデルあるいは得られた内部モデルが１つの場合、該内部モデルを検索命令文へと変換するための内部モデルと個々の情報源の検索結果を統合するための内部モデルとに分割するステップは、各情報源が受理可能な検索命令文のパターンを、内部モデルの構成要素である演算子の出現順序によって管理しておくステップと、前記、管理しているパターンに基づき最適化された内部モデルから検索命令文へと変換するための内部モデルを抽出するステップとを有する、請求項２から５のいずれかに記載の木構造代数モデルを利用した統合検索方法。
【請求項７】
前記情報源での検索実行結果を、前記問い合せが要求している情報へと統合するステップは、前記個々の情報源の検索結果を統合するための内部モデルに基づいて検索実行結果を統合するステップである、請求項１から６のいずれかに記載の木構造代数モデルを利用した統合検索方法。
【請求項８】
入力された問い合せを、該問い合わせが要求する情報を情報源から得るための検索命令文へと変換する手段と、変換された検索命令文を前記情報源に送信し、検索を実行させる手段と、前記情報源での検索実行結果を、前記問い合せが要求している情報へと統合する手段とを有する、木構造代数モデルを利用した統合検索装置。
【請求項９】
請求項１から７のいずれか１項に記載の統合検索方法をコンピュータに実行させるための統合検索プログラム。
【請求項１０】
請求項９に記載の統合検索プログラムを記録した、コンピュータで読取り可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、木構造代数モデルを利用した情報源の統合検索方法、装置、プログラム、および記録媒体に関する。
【０００２】
【従来の技術】
近年、コンピュータの高機能化や低価格化、オープンなネットワークであるインターネット、イントラネット、エクストラネット等の普及によって、エンドユーザが大量の情報を容易に閲覧、加工できる環境が急速に整いつつある。これと並行して、大量の情報を効率的に蓄積・管理するための研究・開発が活発となってきている。そして、情報の種別に応じて、より効率的な情報源管理システムが研究・開発されてきている。ここで、情報源管理システムとは、検索命令文を受け付け、格納している情報の中から、検索結果を返却するシステムであり、データベース管理システム、ファイルシステム等を指す。また、情報源管理システムに管理されているデータベース、ファイル群を情報源と呼ぶ。
【０００３】
例えば、ビジネス分野のアプリケーションでは、蓄積・管理する文字・数値情報が複雑な論理構造を有することは、それほど多くないので、論理構造をテーブル形式で表現した関係データベースが有効である。また、求められる操作も定型的であり、標準化されている関係データベースの諸操作（関係代数）で十分簡明に記述することができる。
【０００４】
一方、データの特性によっては、テーブル形式にして正規化すると複雑な論理構造になってしまうこともある。データの単位毎に、その中の項目が異なる場合は欠損する場合である。このようなデータを総称して半構造情報と呼ぶ。そして、半構造化情報を扱うためには、木構造でデータを表現するXML (Extensible Markup Language)が有効である。
【０００５】
XMLは文書管理や電子商取引への応用が期待されており、大量のXML文書を蓄積・検索したいというニーズが高まっている。実際、関係データベース管理システムに対し、XMLを容易に扱えるライブラリをカートリッジとして提供しているベンダや、XMLを変換したDOM ( Document Object Model)を格納できるデータベース管理システムを製造しているベンダが増えている。また、XMLを操作するための様々な言語も提案されている。例えば、XML文書中の特定の部分を指定する言語としてXPathがW3C勧告として、公開されている（非特許文献１）。このXPathを問い合せ言語として利用しているデータベース管理システムは既に製造されている。さらに、より複雑な操作も記述できるXQueryを問い合せ言語・ビュー指定言語として利用しているXMLパブリッシング技術も研究されている（非特許文献２）。XMLパブリッシング技術とは、関係データベースに格納されている情報をXMLとして取り出す技術である。
【０００６】
このように、情報の種別・特性を特化した、より効率的な情報源管理システムが研究・開発されている一方で、各情報源管理システムを個別に利用するだけでなく、それらを統合するシステムの研究・開発も進んでいる。
【０００７】
本出願人は、特許文献１で、ネットワークに接続された、異なる複数の情報源に対する情報検索を容易に行えるようにした情報検索方法、情報検索システムを提案している。この情報検索方法、情報検索システムでは、複数の情報源に対してアクセスするための参照情報を予め登録しておき、問い合せを取得すると、その問い合せを解析し、参照情報を参照して問い合せに対応する情報がどの情報源に格納されているかを特定するとともに、どのような取得方法で情報が取得可能であるかの情報を取得し、問い合せに対応する情報の格納位置および取得方法を示す情報に基づいて検索命令文を生成し、問い合せに対応する情報源管理システムから検索結果を取得し、ユーザに提供する。したがって、提案した情報検索方法、情報検索システムを利用すれば、情報源管理システムの参照情報を登録するだけでよく、それらを統合するためのプログラムを新たにコーディングする必要はない。
【０００８】
このようなシステムはメディエータと呼ばれている。現在、内部のデータモデルとしてリレーショナルモデルよりも柔軟な木構造モデル（XML）を採用したシステム（以下、XMLメディエータ）が研究されている（非特許文献３、非特許文献４）。
【０００９】
本出願人も、特許文献２で異種半構造化情報源統合検索装置としてXMLメディエータを提案している。
【００１０】
【非特許文献１】
http://www.w3.org/TR/xpath20/)
【非特許文献２】
J.Shanmugasundaram他：“Querying XML Views of Relational Data”, 27th VLDB Conf., Roma, Italy, 2001).
【非特許文献３】
V. Christophides他：“On Wrapping Query Languages and Efficient XML Integration”, Proc. of ACM SIGMOD/PODS 2000, Research Sessions.
【非特許文献４】
C. Baru他：“XML−Based Information Mediation with MIX”, Proc. of ACM SIGMOD/PODS 99, Demonstrations.
【非特許文献５】
http:/www. W3.org/TR/xquery/
【非特許文献６】
改訂版標準XML完全解説
【特許文献１】
特開平１０−１４３５３９号公報
【特許文献２】
特願２００２−１２２３４５号
【００１１】
【発明が解決しようとする課題】
XMLメディエータを用いて、異種情報源の高速な統合検索を実現する場合、問い合せの最適化が重要となる。メディエータでは、利用者からの問い合せは、情報源の格納位置や問い合せ実行の手順などを意識しない非手続き言語で指定される。この場合、メディエータは、同一の結果を導出する複数の検索手続き候補から最も効率のよい検索手続きを選択する。これを問い合せの最適化と呼ぶ。特に、検索条件処理を情報源側に行わせ、検索結果の転送量を軽減することによる問い合せの最適化は有効である。しかし、半構造化情報（XML)に対する問い合せは再構成・変換を含むことが一般的である。再構成・変換に伴い、以下の問題が生じる。
【００１２】
１）再構成・変換を含む問い合せの最適化が困難である。
【００１３】
スキーマとしてリレーショナルモデルを採用したメディエータの場合、関係代数演算の間の可換規則や結合規則を利用して、各検索手続き候補が同一の結果を導出するのを示すことが容易である。これに対し、従来のXMLメディエータでは、代数に基づく内部モデルを採用していないため、問い合せ最適化が困難である。
また、異種情報源に検索条件処理を行わせるためには、以下の問題が生じる。
【００１４】
２）情報源管理システム毎に異なる問い合せ言語の能力・制約を考慮して、利用者からの問い合せを各問い合せ言語に変換するのが困難である。
【００１５】
メディエータは、異なる複数の情報源に対する検索を行う。そして、各情報管理システム（例、関係データベース管理システム）はそれぞれの問い合せ言語（例、関係代数に基づくSQL）を採用している。利用者からメディエータに対して入力された問い合せは、内部モデルを経て、情報源毎の問い合せ言語に変換される。
【００１６】
これに対し、従来のXMLメディエータは、代数に基づく内部モデルを採用していないため、異なる問い合せ言語の能力・制約を考慮して、利用者からの問い合せを最適化して、各問い合せ言語に変換するのが困難である。
【００１７】
３）問い合せの最適化を利用した検索の高速化が困難であるという問題がある。
【００１８】
上記、１）、２）の問題が解決されていないため、情報源側の能力を十分に利用した問い合せの最適化が困難であり、システム全体として検索を高速化するのが困難である。
【００１９】
本発明の目的は、検索実行結果の転送量を軽減し、異種情報源の高速な統合検索を行う、木構造代数モデルを利用した統合検索方法、装置、プログラム、および記録媒体を提供することにある。
【００２０】
【課題を解決するための手段】
本発明の木構造代数モデルを利用した統合検索方法は、入力された問い合せを、該問い合せが要求する情報を情報源から得るための検索命令文へと変換するステップと、変換された検索命令文を前記情報源に送信し、検索を実行させるステップと、前記情報源での検索実行結果を、前記問い合せが要求している情報へと統合するステップとを有する。
【００２１】
特に、本発明は、入力された問い合せを解析し、内部モデルへ変換し、該問い合わせ中で指定されたビューが、情報源に格納されている情報を登録したビューか、または問い合せを用いて定義したビューかを判定し、前記のビューの定義に用いられた問い合せを解析し、内部モデルへ変換し、の得られた内部モデルが複数あれば、それらを合成、最適化し、最適化された内部モデルあるいは得られた内部モデルが１つの場合、該内部モデルを個々の情報源が受理可能な検索命令文へと変換するための内部モデルと個々の情報源の検索結果を統合するための内部モデルとに分割し、個々の情報源の検索命令文を生成し、個々の情報源から得られた情報を問い合せが求める情報へと統合するものである。
【００２２】
入力された問い合せを個々の異種情報源管理システムで受理可能な検索命令文に変換し、検索条件処理を情報源側で行わせることで、検索実行結果の転送量を軽減することができ、検索実行結果の転送量軽減による問い合せ最適化を利用した、高速な異種情報源の統合検索を行うことができる。
【００２３】
【発明の実施の形態】
次に、本発明の実施の形態について図面を参照して説明する。
【００２４】
図１は本発明の一実施形態の統合検索装置を含むシステムの構成図である。
【００２５】
統合検索装置１は、ユーザインタフェース部１１と構文解析部１２と統合検索処理部１３と情報源システム４1、４2毎のラッパー１４1、１４2とメタデータ記憶部１５とメタデータ管理部１６とを有する。
【００２６】
ユーザインタフェース部１１は、アプリケーションプログラム２と通信網３を介してユーザから入力された問い合せ１０１を受け付ける。問い合せ１０１は変数バインド部分、検索条件指定部分、検索結果構造指定部分から構成される。また、問い合せ１０１は入れ子にすることが可能である。
【００２７】
構文解釈部１２は、ユーザインタフェース部１１が受け付けた問い合せ１０１の構文を解析し、これを問い合せ内部モデル１０２に変換する。
【００２８】
統合検索処理部１３は、各情報源管理システム４1、４2で採用されている問い合せ言語によって記述された検索命令文１０９1、１０９2を問い合せ内部モデル１０２から生成し、各情報源４1a、４1b、４2a、４2bに格納されている情報を一括して検索するもので、ビュー所在探索部１３aと内部モデル合成部１３bと内部モデル分割部１３cと検索結果処理部１３dを含む。ビュー所在探索部１３aは、問い合せ内部モデル１０２中で指定されたビューの所在を探索する。ここで、ビューとは、ある視点から捉えた仮想的な情報である。本実施形態では、ビューには（a）情報源システム４1、４2毎のラッパー１３1、１３2が情報源に格納されている情報をXMLとして自動的に登録したビュー（以下、情報源ビュー）、（b）システム管理者が問い合せ１０１を用いて、情報源ビューから定義し、登録したビュー（以下、定義ビュー）の２種類がある。内部モデル合成部１３bは、XML関数合成規則１０４とXML関数交換規則１０５を用いて、探索されたビューのビュー内部モデル１０３と問い合せ内部モデル１０２を合成し、合成内部モデル１０６を生成する。内部モデル分割部１３cは、クエリテンプレート１０７を用い、各情報源管理システム４1、４2で採用されている問い合せ言語の能力・制約を考慮して最適化し、最適化された合成内部モデル１０６（得られた内部モデルが１つの場合、該内部モデル）を検索命令文用内部モデル１０８と統合用内部モデル１１２に分割する。検索結果処理部１３dは、情報源管理システム４1、４2毎のラッパー１３1、１３2が変換した情報源検索結果（XML）１１１1、１１１2に対し、それらを統合するために、統合用内部モデル１１２に基づいた処理（複数の情報源に跨ったジョインや、情報源側では処理不可能な検索条件によるフィルタリング、検索結果構造の再構成等）を行う。
【００２９】
情報源管理システム４1、４2毎のラッパー１４1、１４2は、検索命令文用内部モデル１０８から検索命令文１０９1、１０９2を生成し、通信網５を介して、情報源管理システム４1、４2に送信し、そして、情報源検索結果１１０1、１１０2を情報源管理システム４1、４2から取得し、これをXML１１１1、１１１2に変換する。情報源管理システム４1には情報源４1a、４1bが、情報源管理システム４2には情報源４2a、４2bが接続されている。
【００３０】
メタデータ記憶部１５は、各情報源管理システム４1、４2の所在、アクセス情報、情報源ビューのスキーマ構造・構成要素などに関する情報を記憶し、管理している。
【００３１】
メタデータ管理部１６は、メタデータ記憶部１５に対する各種情報の入力／削除／変更を行う。システム管理者は、メタデータ管理部１６を介してメタデータをメタデータ記憶部１５に登録・管理する。
【００３２】
図２は本実施形態において、メタデータ記憶部１５が保有する情報の詳細を示している。メタデータ記憶部１５は各情報源を管理する情報源管理システムやアクセスする手段等の情報を管理する情報源管理システムメタデータ１２１と、情報源ビュースのキーマ構造・要素および所在やユーザ名などのアクセス情報あるいは定義ビューを定義するための問い合せ（ビュー定義用問い合せ）と定義されたビューのスキーマ構造・要素を管理するビューメタデータ１２２とを記憶している。
【００３３】
次に、本統合検索装置１の処理手順の概要について説明する。
【００３４】
図３は本実施形態の全体の概略動作を示すフローチャートであり、準備フェーズ（ステップ１０００）と検索フェーズ（ステップ２０００）の順で処理が行われる。準備フェーズでは、検索を実行する前に、システム管理者がメタデータの準備を行う。検索フェーズは検索を実行する。
【００３５】
図４は準備フェーズを具体的に示すフローチャートである。まず、各情報源管理システムに関する情報を、情報源管理システムメタデータ１２１に登録し（ステップ１０１０）、各情報源ビューのアクセス情報とスキーマ構造・要素あるいは定義ビューを定義するための問い合せ（ビュー定義用問い合せ）と定義されたビューのスキーマ構造・要素をビューメタデータ１２２に登録する（ステップ１０２０）。ビュー定義用問い合せを用いて、複数のビューを統合したビューを定義することもできる。上記処理は、メタデータ管理部１６を介して、システム管理者が登録してもよいし、各情報源がそれぞれのメタ情報を返却する機構を有していれば、該機構を利用し、自動的に登録してもよい。
【００３６】
図５は検索フェーズを具体的に示すフローチャートである。検索フェーズでは、まず、ユーザインタフェース部１１が、アプリケーションプログラム２を介して入力されたユーザからの問い合せ１０１を受理する（ステップ２０１０）。構文解析部１２は、問い合せ１０１を解析し、問い合せ内部モデル１０２に変換する（ステップ２０２０）。ビュー所在探索部１３は、問い合せ１０１中の変数バインド部分で指定されたビューをメタデータから探索する（ステップ２０３０）。このとき、指定されたビューがビューメタデータ１２２になければエラー出力して検索フェーズを終了する（ステップ２０３１、２０４０）。探索されたビューが定義ビューの場合、構文解析部１２は、ビュー定義用問い合せを解析し、問い合わせ１０１をビュー内部モデル１０３に変換する（ステップ２０２０、２０３２）。ビュー定義問い合せ中の変数バインド部分で指定されたビューをさらに、ビューメタデータ１２２から探索する。これを情報源ビューに行き着くまで繰り返す。つづいて、該情報源ビューを管理する情報源管理システム４1、４2をビューメタデータ１２２から探索し（ステップ２０３３）、該情報源ビューへのアクセス情報の項目が情報源管理システムメタデータ１２１に設定されている項目と等しいかを判断し、等しくなければエラー出力して検索フェーズを終了する（ステップ２０３４、２０９０）。次に、問い合せ１０１で指定されたビューが定義ビューであれば、内部モデル合成部１３ｂは、図１８に示すXML関数の合成規則１０４と、XML関数交換規則１０５に基づいて、探索されたビューのビュー内部モデル１０３と問い合せ内部モデル１０２を合成し、合成内部モデル１０６を生成する（ステップ２０３５、２０４０）。つづいて、合成内部モデル１０６の検索条件を交換規則に基づいて情報源側へプッシュダウンする（ステップ２０４１）。内部モデル分割部１３cは、各情報源管理システム４1、４2で採用されている問い合せ言語の能力・制約を考慮したクエソテンプレート１０７に基づいて、合成内部モデル１０６を検索命令文用内部モデル１０８と統合用内部モデル１１２に分割する（ステップ２０５０）。つづいて、情報源システム毎のラッパー１４1、１４2は、検索命令文用内部モデル１０８から検索命令文１０９1、１０９2を生成し（ステップ２０６０）、該検索命令文１０９1、１０９2をアクセス情報とともに各情報源管理システム４1、４2に送信し（ステップ２０６１）、情報源検索結果１１０1、１１０2を取得し、これをXML１１１1、１１１2に変換する（ステップ２０６２）。検索結果処理部１３dは、情報源システム毎のラッパー１４1、１４2が変換した情報源検索結果(XML）１１１1、１１１2に対し、それらを統合するために、統合用内部モデル１１２に基づいた処理（複数の情報源に跨ったジョインや、情報源側では処理不可能な検索条件によるフィルタリング、検索結果構造の再構成等）を行い（ステップ２０７０）、ユーザインタフェース部１１を介して検索結果を出力する（ステップ２０８０）。
【００３７】
上記の内部モデルと交換規則を総称して木構造代数モデルと呼ぶ。
【００３８】
次に、本実施形態における処理手順の詳細を、図６から図３３を用いて具体的に説明する。
【００３９】
（A)  SQLを問い合せとして受け付け可能な情報源管理システム
図６は、検索対象となる文字・数値情報を格納している関係データベース管理システムおよび関係データベースの例を示すイメージ図である。上記関係データベース名はOrder#dataであり、関係データベース管理システムData SQLにより管理されている。接続するためのユーザ名はtigerであり、パスワードはgehogehoである。Data SQLは、標準的なSQLを受け付ける関係データベース管理システムである。
【００４０】
図７に示すとおり、データベースOrder#dataには、注文IDと発注者と管理するorderテーブル、商品名と価格を管理するitemテーブルなどが格納されている。
【００４１】
（B）  XPath を問い合せとして受け付け可能な情報源管理システム
図８は、検索対象となるXML文書群を管理する情報源管理システムおよび情報源の例を示すイメージ図である。上記XML文書群を格納しているデータベースのデータベース名はitem#informationであり、XML文書管理システムeXobjectにより管理されている。接続するためのユーザ名はadminであり、パスワードはhogehogeである。eXobjectは、XPathを問い合せとして受け付け可能な情報源管理システムである。 XPath規格では、木構造をどのような経路でたどって所望のデータを特定するかという記述法を決めている（詳細は、非特許文献１を参照）。
【００４２】
図９、図１０は、item#informationに格納されているXML文書brand#list.xmlの内容を示す図である。図９（a）は、文書要素およびその階層構造を規定するDTD (Document Type Definition)のグラフィック表現、図９（b）は、 実際のXML文書、図１０は実際のXML文書（インスタンス）のグラフィック表現をそれぞれ示す図である（グラフィック表現については、非特許文献６を参照）。
【００４３】
次に、上記具体例に基づいて、図３に示す各フェーズの動作を具体的に説明する。
【００４４】
まず、準備フェーズについて説明する。図１１は情報源管理システム名とライブラリ名と該システムにアクセスするのに必要な情報の種別とを示す情報源管理システムメタデータ１２１の内容を示す図である。各情報源管理システムにアクセスする手段に関する情報として、図１１に示すように、情報源管理システム名と接続手段のライブラリ名と該システムにアクセスするのに必要な情報の種別とを、情報源管理システムメタデータ１２１に設定する（図４のステップ１０１０）。
【００４５】
図１２は、情報源ビューのスキーマ構造・要素および所在やユーザ名などのアクセス情報あるいは定義ビューを生成するための問い合せ（ビュー定義用問い合せ）と生成されたビューのスキーマ構造・要素を管理するビューメタデータ１２２の内容を示す図である。図１２（a）,（b）が、それぞれeXobjectに管理されているデータベースitem#informationとData SQLに管理されているデータベースorder#dataのアクセス情報、スキーマ構造、要素を表している情報源ビューのビューメタデータ１２２である。minOccurおよびmaxOccurは各要素の出現階数の最小値および最大値である。unboundedは無限大を示す。
【００４６】
ビューを生成するための言語は、アプリケーションプログラム２を介して入力される問い合せ１０１と同じ言語を採用する。本実施形態では、XQueryのFLWR式を用いて説明する。FLWR式には、▲１▼指定されたノードシーケンスを変数にバインドするFOR節またはLET節、▲２▼指定された条件にしたがってノードシーケンスをフィルタリングするWHERE節、▲３▼照会結果ツリーを生成するRETURN節からなる（非特許文献５参照）。図１２（c）がデータベースorder#dataに対して定義したビューorder-listのビュー定義用問い合せである。
【００４７】
各情報のアクセス情報とスキーマ構造・要素あるいはビューを生成用問い合せと登録されたビューのスキーマ構造・要素を、ビューメタデータ１２２に設定する（図４のステップ１０２０）。
【００４８】
次に、検索フェーズについて説明する。
【００４９】
（a）SQL情報源に対する問い合せ−その１
図１３に示す問い合せがアプリケーションプログラム２から発行された場合を例に具体的に説明する。図１３は「顧客Harrodsによる注文（order）を検索する」問い合せである。
【００５０】
まず、問い合せ１０１を受理し（図５のステップ２０１０）、構文解析部１２は問い合せ１０１を解析し、これを問い合せ内部モデル１０２に変換する（図５のステップ２０２０）。変換された問い合せ内部モデル１０２を図１４に示す。図１５に内部モデルで使われる演算子（図１４中の各boxの：左側）を示す。また、これらの演算子中では、図１６のXML関数群（図１４中の各boxの：右側）を利用して演算処理を行う。ビュー所在探索部１３aは問い合せ１０１中の変数バインド部分（FOR節、図１３の１行目）で指定されたビュー（order-list）をビューメタデータ１２２から探索する（ステップ２０３０）。探索されたビューが定義ビューなので（ステップ２０３２）、構文解析部１２は、ビュー定義用問い合せ（図１２（c）７３行目〜８７行目）を解析し、ビュー内部モデル１０３に変換する（ステップ２０２０）。変換されたビュー内部モデル１０３を図１７に示す。つづいて、該情報源ビューを管理する情報源管理システムをビューメタデータ１２２から探索する（ステップ２０３３）。図１２（b）の３４行目から該情報源ビューを管理しているのはData SQLである。また、アクセス情報の項目も図１１と図１２（b）３６行目から３８行目との比較から、db-name, user-name,
password と等しい（ステップ２０３４）。
【００５１】
次に、内部モデル合成部１３bは図１８に示すXML関数の合成規則に基づき、探索されたビューのビュー内部モデル１０３（図１７）と問い合せ内部モデル１０２（図１４）を合成し、合成内部モデル１０６を生成する（ステップ２０４０）。合成内部モデル１０６を図１９に示す。つづいて、各演算子間の交換規則に基づいて、検索条件（演算子はselect）を情報源側、つまり内部モデルでは下側へプッシュダウンする（ステップ２０４１）。図１９では、select (box 8)とproject (box 7), select (box 8)とright outer join (box 6) の交換規則が成り立つので、図１９に示すようにselect (box 8) は、table(box 1)の上までプッシュダウンされる。図２０は図１７のビュー内部モデルと図１４の問い合せ内部モデルが合成され、図１９（出力）になる流れを示している。より詳細には、図１７のbox７をXML関数群（図１６）で示した部分の１行目、cr8Elem(order, Atts,Clist)と図１４のbox３を図１８に示す合成規則３に基づいて合成すると、Clistの部分が残る。合成規則を順次適用している様子を示したのが図２０である。
【００５２】
次に、内部モデル分割部１３０cは、各情報源管理システム４1、４2で採用されている問い合せ言語 (SQL) の能力・制約を考慮して、図１９の合成内部モデル１０６を検索命令文用内部モデル１０８と統合用内部モデル１１２に分割する（ステップ２０５０）。Box 1, 2, 3, 8はそのままSQLに変換できる。また、Box4, 5, 6, 7, 9は検索結果をXMLに変換するための関数なので、ラッパー１４1、１４2で処理される。したがって、図１９の合成内部モデル１０６は、そのまま検索命令文用内部モデル１０８としてラッパー１４1、１４2に送信される。ラッパー１４1、１４2は、図１９の検索命令文用内部モデル１０８から検索命令文１０９1、１０９2を生成する（ステップ２０６０）。生成された検索命令文（SQL）を図２０に示す。検索命令文（図２０）をアクセス情報（db-name: order#data, user-name: tiger, password: gehogeho）とともに情報源管理システムData SQLに送信し（ステップ２０６１）、情報源検索結果１１０1、１１０2を取得し、これをXML１１１1、１１１2に変換する（ステップ２０６２）。XML１１１1、１１１2に変換された検索結果を図２２に示す。検索結果処理部１３dは統合用内部モデル１１２がないので、何も行わず（ステップ２０７０）、ユーザインタフェース部１１を介して検索結果（図２２）を出力する（ステップ２０８０）。
【００５３】
（b）SQL情報源に対する問い合せ−その２
図２３に示す問い合せ１０１がアプリケーションプログラム２から発行された場合を例に説明する。
【００５４】
図２３は「（一つでも）５０００円より高い商品（item)を含む注文（order）を検索する）問い合せである。
【００５５】
まず、問い合せ１０１を受理し（図５のステップ２０１０）、構文解析部１２は問い合せ１０１を解析し、問い合せ内部モデル１０２に変換する（図５のステップ２０２０）。変換された問い合せ内部モデル１０２を図２４に示す。ビュー所在探索部１３aは、問い合せ１０１中の変数バインド部分（FOR節、図２３の１行目）で指定されたビュー（order-list）をビューメタデータ１２２から探索する（ステップ２０３０）。以降、ステップ２０３４までは、（a）と同じなので省略する。指定されたビュー（oder-list) が同じなので、ビュー内部モデル１０３は図１７と同じである。
【００５６】
内部モデル合成部１３bは、探索されたビューのビュー内部モデル１０３（図１７）と問い合せ内部モデル１０２（図２４）を合成し、合成内部モデル１０６を生成する（ステップ２０４０）、合成内部モデル１０４中を図２５に示す。つづいて、検索条件を情報源側へプッシュダウンする（ステップ２０４１）。図２５では、select (box 8)とproject (box 7), select (box 8)とright outer join (box 6) の交換規則が成り立つが、select (box 8)とgroupby (box 5)の交換規則は成り立たないため、図２５に示すようにselect (box 8)は、groupby (box5)の上までプッシュダウンされる。select (box 8)とgroupby (box 5)の交換規則が成り立たない理由は、select (box 8)は、（一つでも）５０００円より高い商品(item)を含む注文(order)を検索するための条件なので、商品（item)を注文(order)毎に集約するgroupby (box 5)より前に評価することはできないためである。
【００５７】
次に、内部モデル分割部１３cは、各情報源管理システム４1、４2で採用されている問い合せ言語(SQL)の能力・制約を考慮して、図２５の合成内部モデル１０４を検索命令文用内部モデル１０８と統合用内部モデル１１２に分割する（ステップ２０５０）。box 1, 2, 3, 8はSQLの副問い合せに変換できる。また、box4, 5, 6, 7, 9は検索結果をXMLに変換するための関数なので、ラッパー１４1、１４2で処理される。したがって、図２５の合成内部モデル１０６は、そのまま検索命令文用内部モデル１０８としてラッパー１４1、１４2に送信される。ラッパー１４1、１４2は、図２５の検索命令文用内部モデル１０８から検索命令文１０９1、１０９2を生成する（ステップ２０６０）。生成された検索命令文（SQL）１０９1、１０９2を図２６に示す。検索命令文１０９1、１０９2（図２６）をアクセス情報(db-name: order#data, user-name: tiger, password: gehogeho)とともに情報源管理システムData SQLに送信し（ステップ２０６１）、情報源検索結果１１０1、１１０2を取得し、これをXML１１１1、１１１2に変換する（ステップ２０６２）。XML１１１1、１１１2に変換された検索結果を図２７に示す。
【００５８】
検索結果処理部１３dは、統合用内部モデル１２がないので、何も行わず（ステップ２０７０）、ユーザインタフェース部１１を介して検索結果（図２７）を出力する（ステップ２０８０）。
【００５９】
（ｃ）XPath情報源に対する問い合せ
図２８に示す問い合せ１０１がアプリケーションプログラム２から発行された場合を例に説明する。図２７は「赤い色（を含む）製品の情報を検索する」問い合せである。
【００６０】
まず、問い合せ１０１を受理し（図５のステップ２０１０）、構文解析部１２は問い合せ１０１を解析し、これを問い合せ内部モデル１０２に変換する（図５のステップ２０２０）。変換された問い合せ内部モデル１０２を図２９に示す。次に、ビュー所在探索部１３aは問い合せ１０１中の変数バインド部分（FOR節、図２８の１行目）で指定されたビュー（brand-list）をビューメタデータ１２２から探索する（ステップ２０３０）。探索されたビューが情報源ビューなので（ステップ２０３２）、該情報源ビューを管理する情報源管理システムをビューメタデータ１２２から探索する（ステップ２０３３）。図１２（a）の６行目から該情報源ビューを管理しているのはeXobjectである。また、アクセス情報の項目も図１１と図１２（a)８行目から１０行目との比較から、db-name, user-name, passwordと等しい（ステップ２０３４）。
【００６１】
問い合せ１０１で指定されたビューが情報源ビューなので（ステップ２０３５）、図２９が内部モデルとなる。次に、内部モデル分割部１３cは、各情報源管理システムで４1、４2で採用されている問い合せ言語（XPath）の能力・制約を考慮して、図２９の合成内部モデル１０６を検索命令文用内部モデル１０８と統合用内部モデル１１２に分割する（ステップ２０５０）。Right outer join (box 21) は、通常、XPathでは処理できないが、where節とreturn節のjoinは可能、つまりbox 1からbox 21まではXPathに変換できる。また、project (box 22)は検索結果をXMLとして再構成するための関数なので、ラッパー１４1、１４2で処理される。したがって、図２９は、そのまま検索命令文用内部モデル１０８としてラッパー１４1、１４2に送信される。ラッパー１４1、１４2は、図２９の検索命令文用内部モデル１０８から検索命令文１０９1、１０９2を生成する（ステップ２０６０）。生成された検索命令文１０９1、１０９2（XPath）を図３１に示す。検索命令文１０９1、１０９2（図３０）をアクセス情報（db-name: item-information, user-name: admin, password: hogehoge）とともに情報源管理システムeXobjectに送信し（ステップ２０６１）、情報源検索結果１１０1、１０2を取得し、これをXML１１１1、１１１2に変換する（ステップ２０６２）。検索結果１１１1、１１１2を図３１に示す。
【００６２】
検索結果処理部１３dは、統合用内部モデル１１２がないので、何も行わず（ステップ２０７０）、ユーザインタフェース部１１を介して検索結果１１１1、１１１2（図３１）を出力する（ステップ２０８０）。
【００６３】
（d）  統合検索
図３２に示す問い合せ１０１がアプリケーションプログラム２から発行された場合を例に具体的に説明する。図３２は「顧客Harrodsによる赤い商品を含む注文（order）を検索する」問い合せである。ステップ２０１０から２０４０までは、（a）SQL情報源に対する問い合せ―その１、（b）XPath情報源に対する問い合せと同じなので説明を省略する。次に、内部モデル分割部１３cは、各情報源管理システム４1、４2で採用されている問い合せ言語（SQLおよびXPath）の能力・制約を考慮して、合成内部モデル１０６を検索命令文内部モデル１０８と統合用内部モデル１１２に分割する（ステップ２０５０）。このとき、図３２の問い合せのうち、５行目のジョイン条件は複数の情報源に跨るジョインなので情報源にプッシュダウンすることができない。このジョイン条件に対応する演算子が統合用内部モデル１１２となる。つづいて、各情報源毎のラッパー１４1、１４2は、検索命令文用内部モデル１０８から検索命令文１０９1、１０９2を生成する（ステップ２０６０）。生成された検索命令文１０９1、１０９2はそれぞれ図２１（SQL）、図３０（Xpath）と同じである。それぞれのアクセス情報とともに情報源管理システムData SQL, eXobjecty に送信し（ステップ２０６１）、情報源検索結果１１０1、１１０2を取得し、これをXML１１１1、１１１2に変換する（ステップ２０６２）。それぞれの検索結果は、図２２、図３１と同じである。検索結果処理部１３dは、統合用内部モデル１１２に基づいて２つのXML１１１1、１１１2の統合を行い （ステップ２０７０）、ユーザインタフェース部１１を介して検索結果１１３を出力する（ステップ２０８０）。検索結果１１３を図３３に示す。
【００６４】
なお、統合検索装置１の処理は専用のハードウェアにより実現されるもの以外に、その機能を実現するためのプログラムを、コンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行するものであってもよい。コンピュータ読み取り可能な記録媒体とは、フロッピーディスク、光磁気ディスク、CD―ROM等の記録媒体、コンピュータシステムに内蔵されるハードディスク装置等の記憶装置を指す。さらに、コンピュータ読み取り可能な記録媒体は、インターネットを介してプログラムを送信する場合のように、短時間の間、動的にプログラムを保持するもの（伝送媒体もしくは伝送波）、その場合のサーバとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含む。
【００６５】
【発明の効果】
以上説明したように本発明によれば、XMLメディエータを用いた異種情報源の統合検索において、入力された問い合せを個々の異種情報源管理システムで受理可能な検索命令文に変換し、検索条件処理を情報源側で行わせることで、検索実行結果の転送量を軽減することができ、検索実行結果の転送量軽減による問い合せ最適化を利用した、異種情報源の高速な統合検索を行うことができる。
【図面の簡単な説明】
【図１】本発明の一実施形態の統合検索装置の構成を示すブロック図である。
【図２】メタデータ記憶部が保有する情報の詳細を示す図である。
【図３】図１の実施形態の全体の概略動作を示すフローチャートである。
【図４】図１の実施形態における準備フェーズを具体的に示すフローチャートである。
【図５】図１の実施形態における検索フェーズを具体的に示すフローチャートである。
【図６】図１の実施形態において、検索対象となるXML文書群を管理する情報源管理システムおよび情報源の例を示すイメージ図である。
【図７】図１の実施形態において、データベースitem#informationに格納されているXML文書brand-list.xmlの内容を示す図である。
【図８】図１の実施形態において、検索対象となる文字・数値情報を格納している関係データベース管理システムおよび関係データベースの例を示すイメージ図である。
【図９】図１の実施形態において、データベースorder#dataに格納されているテーブルorderとitemの内容を示す図である。
【図１０】図１の実施形態において、データベースorder#dataに格納されているテーブルorderとitemの内容を示す図である。
【図１１】図１の実施形態において、情報源管理システム名とライブラリ名と該システムにアクセスするのに必要な情報の種別とを示す情報源管理システムメタデータの内容を示す図である。
【図１２】図１の実施形態におけるビューメタデータの内容を示す図である。
【図１３】図１の実施形態の説明（a）において、使用する問い合せを示す図である。
【図１４】図１３の問い合せを変換した問い合せ内部モデルを示す図である。
【図１５】内部モデルで使われる演算子を示す図である。
【図１６】XML関数群および交換規則を示す図である。
【図１７】探索されたビュー（order-list）のビュー内部モデルを示す図である。
【図１８】XML関数の合成規則を示す図である。
【図１９】図１４と図１７の合成内部モデル（同図（a））とクエリテンプレート（単問い合せSQLの場合）（同図（b））を示す図である。
【図２０】図１７のビュー内部モデルと図１４の問い合わせ内部モデルを合成して図１９の合成内部モデルが得られる流れを示す図である。
【図２１】図１９の合成内部モデルから生成された検索命令文（SQL）を示す図である。
【図２２】図１３の検索命令文に対する検索結果をXML化したものを示す図である。
【図２３】図１の実施形態の説明（b）において、使用する問い合せを示す図である。
【図２４】図２３の問い合せを変換した問い合せ内部モデルを示す図である。
【図２５】図１７のビュー内部モデルと図２４の合成内部モデル（同図（a））とクエリテンプレート（副問い合せSQLの場合）（同図（b））を示す図である。
【図２６】図２５の合成内部モデルから生成された検索命令文（SQL）を示す図である。
【図２７】図２３の検索命令文に対する検索結果をXML化したものを示す図である。
【図２８】図１の実施形態の説明（c）において、使用する問い合せを示す図である。
【図２９】図２８の問い合せを変換した問い合せ内部モデルを示す図である。
【図３０】図２９の問い合せ内部モデルから生成された検索命令文（XPath）を示す図である。
【図３１】図２８の検索命令文に対する検索結果をXML化したものを示す図である。
【図３２】図１の実施形態の説明（d）において、使用する問い合せを示す図である。
【図３３】図３２の検索命令文に対する検索結果をXML化したものを示す図である。
【符号の説明】
１    統合検索装置
２    アプリケーションプログラム
３、５    通信網
４1、４2    情報管理システム
４1a, ４1b,  ４2a, ４2b    情報源
１１    ユーザインタフェース部
１２    構文解析部
１３    統合検索処理部
１３a    ビュー所在探索部
１３b    内部モデル合成部
１３c    内部モデル分割部
１３d    検索結果処理部
１４1、１４2    ラッパー
１０１    問い合せ
１０２    問い合せ内部モデル
１０３    ビュー内部モデル
１０４    XML関数合成規則
１０５    XML関数交換規則
１０６    合成内部モデル
１０７    クエリテンプレート
１０８    検索命令文用内部モデル
１０９1、１０９2    検索命令文
１１０1、１１０2    情報源検索結果
１１１1、１１１2    情報源検索結果（XML)
１１２    統合用内部モデル
１１３    統合検索結果（XML）
１２１    情報源管理システムメタデータ
１２２    ビューメタデータ
１０００    準備フェース
２０００    検索フェース
１０１０、１０２０    ステップ
２０１０〜２０９０    ステップ
【図１】
2004206640.tif 000003
【図２】
2004206640.tif 000004
【図３】
2004206640.tif 000005
【図４】
2004206640.tif 000006
【図５】
2004206640.tif 000007
【図６】
2004206640.tif 000008
【図７】
2004206640.tif 000009
【図８】
2004206640.tif 000010
【図９】
2004206640.tif 000011
【図１０】
2004206640.tif 000012
【図１１】
2004206640.tif 000013
【図１２】
2004206640.tif 000014
【図１３】
2004206640.tif 000015
【図１４】
2004206640.tif 000016
【図１５】
2004206640.tif 000017
【図１６】
2004206640.tif 000018
【図１７】
2004206640.tif 000019
【図１８】
2004206640.tif 000020
【図１９】
2004206640.tif 000021
【図２０】
2004206640.tif 000022
【図２１】
2004206640.tif 000023
【図２２】
2004206640.tif 000024
【図２３】
2004206640.tif 000025
【図２４】
2004206640.tif 000026
【図２５】
2004206640.tif 000027
【図２６】
2004206640.tif 000028
【図２７】
2004206640.tif 000029
【図２８】
2004206640.tif 000030
【図２９】
2004206640.tif 000031
【図３０】
2004206640.tif 000032
【図３１】
2004206640.tif 000033
【図３２】
2004206640.tif 000034
【図３３】
2004206640.tif 000035