JP2003323443A

JP2003323443A - 問い合せ最適化を利用した統合検索方法、統合検索装置、プログラム、および記録媒体

Info

Publication number: JP2003323443A
Application number: JP2002130563A
Authority: JP
Inventors: Takashi Hayashi; 孝志林; Gengo Suzuki; 源吾鈴木; Kazuya Konishi; 一也小西; Nobuyuki Kobayashi; 伸幸小林
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2002-05-02
Filing date: 2002-05-02
Publication date: 2003-11-14

Abstract

(57)【要約】【課題】検索実行結果の転送量を軽減し、異種情報源
の高速な統合検索を行う。【解決手段】入力された問い合せを、その要求する情
報が情報源側で欠損しないような検索命令文に変換する
ために、仮検索命令文間にまたがる検索条件節を結合し
ている論理記号（ＡＮＤ／ＯＲ）や、情報源側で評価が
可能な要素と問い合せが要求している検索条件節の評価
の要素、検索条件節中で指定されている要素との包含関
係を判定することで、個々の仮検索命令文の情報源側で
の実行可否、統合検索装置側での再評価要／不要、限量
子の切り替えを判定する。該判定を一時的に保持し、該
判定に基づいて、個々の情報源での検索実行結果のう
ち、問い合せが要求していない情報を削除し、問い合せ
が要求している情報へと統合する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、情報源の統合検索
方法および装置に関する。

【０００２】

【従来の技術】近年、コンピュータの高機能化や低価格
化、オープンなネットワークであるインターネット、イ
ントラネット、エクストラネット等の普及によって、エ
ンドユーザが大量の情報を容易に閲覧、加工できる環境
が急速に整いつつある。これと並行して、大量の情報を
効率的に蓄積・管理するための研究・開発が活発となっ
てきている。そして、情報はその種別に応じて、より効
率的な情報源管理システムが研究・開発されてきてい
る。ここで情報源管理システムとは、検索命令文を受け
付け、格納している情報の中から検索結果を返却するシ
ステムであり、データベース管理システムやファイルシ
ステム等を指す。また、情報源管理システムに管理され
ているデータベースやファイル群を情報源と呼ぶ。

【０００３】例えば、ビジネス分野のアプリケーション
では、蓄積・管理する文字・数値情報が複雑な論理構造
を有することはそれほど多くないので、論理構造をテー
ブル形式で表現した関係データベースが有効である。ま
た、求められる操作も定型的であり、標準化されている
関係データベースの諸操作（関係代数）で十分簡明に記
述することができる。

【０００４】一方、データの特性によっては、テーブル
形式にして正規化すると複雑な論理構造になってしまう
こともある。データの単位毎に、その中の項目が異なっ
たり、欠損する場合である。このようなデータを総称し
て半構造化情報と呼ぶ。そして、半構造化情報を扱うた
めにはこのようなデータの場合、階層構造でデータを表
現するＸＭＬ（Extensible Markup Language）が有効で
ある。ＸＭＬは文書管理や電子商取引への応用が期待さ
れており、大量のＸＭＬ文書を蓄積・検索したいという
ニーズが高まっている。実際、関係データベース管理シ
ステムに対し、ＸＭＬを容易に扱えるライブラリをカー
トリッジとして提供しているベンダや、ＸＭＬを変換し
たＤＯＭ（Document Object Model）を格納できるデー
タベース管理システムを製造しているベンダが増えてい
る。また、ＸＭＬを操作するための様々な言語も提案さ
れている。例えば、ＸＭＬ文書中の特定の部分を指定す
る言語としてＸＰａｔｈがＷ３Ｃ勧告として、公開され
ている（参考文献［１］：http://www.w3.org/TR/xpath
20/）。このＸＰａｔｈを問い合せ言語として利用して
いるデータベース管理システムは既に製造されている。
さらに、より複雑な操作も記述できる問い合せ言語ＸＱ
ｕｅｒｙもＷ３Ｃによって開発がすすめられている（参
考文献［２］：http://www.w3.org/TR/xquery/）。

【０００５】このように、情報の種別・特性に特化し
た、より効率的な情報源管理システムが研究・開発され
ている一方で、各情報源管理システムを個別に利用する
だけでなく、それらを統合するシステムの研究・開発も
すすんでいる。

【０００６】本出願人は、特開平１０−１４３５３９号
公報で、ネットワークに接続された、異なる複数の情報
源に対する情報検索を容易に行えるようにした情報検索
方式、情報検索システムを提案している。提案した情報
検索方法、情報検索システムは、複数の情報源に対して
アクセスするための参照情報を予め登録しておき、問い
合せを取得すると、その問い合せを解析し、参照情報を
参照して問い合せに対応する情報がどの情報源に格納さ
れているかを特定するとともに、どのような取得方法で
情報が取得可能であるかの情報を取得し、問い合せに対
応する情報の格納位置および取得方法を示す情報に基づ
いて検索命令文を生成し、問い合せに対応する情報源管
理システムから検索結果を取得し、ユーザに提供する。
したがって、提案した情報検索方法、情報検索システム
を利用すれば、情報源管理システムの参照情報を登録す
るだけでよく、それらを統合するためのプログラムを新
たにコーディングする必要はない。

【０００７】このようなシステムはメディエータと呼ば
れている。現在、内部のデータモデルとしてリレーショ
ナルモデルよりも柔軟な半構造モデル（ＸＭＬ）を採用
したシステム（以下、ＸＭＬメディエータ）が研究され
ている（参考文献［３］：V.Christophides 他："On Wr
apping Query Languages and Efficient XML Integrati
on", Proc. of ACM SIGMOD/PODS 2000, Research Sessi
ons、参考文献［４］：C. Baru 他："XML-Based Inform
ation Mediation with MIX", Proc. of ACM SIGMOD/POD
S 99, Demonstrations）。

【０００８】

【発明が解決しようとする課題】しかし、ＸＭＬメディ
エータを用いて、様々な情報を統合する場合、次の問題
が生じる。

【０００９】ＸＭＬメディエータを用いて、高速な異種
情報源の統合検索を実現する場合、問い合せ最適化が重
要となる。メディエータでは、利用者からの問い合せ
は、情報源の格納位置や問い合せ実行の手順などを意識
しない非手続き言語で指定される。この場合、メディエ
ータは、同一の結果を導出する複数の検索手続き候補か
ら最も効率の良い検索手続きを選択する。これを問い合
せの最適化と呼ぶ。特に、検索条件処理を情報源側に行
わせ、検索結果の転送量を軽減することによる問い合せ
の最適化は有効である。しかし、半構造化情報（ＸＭ
Ｌ）に対する問い合せは再構成・変換を含むことが一般
的である。再構成・変換に伴い、以下の問題が生じる。

【００１０】（１）問い合せの最適化において、検索条
件処理により評価される要素が変化するため、単純に情
報源側に検索条件処理を行わせると、利用者が求める情
報を取得できない場合がある。ここで、利用者が求める
情報とは（１−１）問い合せで要求した必要な情報が欠損してい
ない（１−２）問い合せで要求していない不必要な情報が含
まれていない検索結果を指す。

【００１１】スキーマとしてリレーショナルモデルを採
用したメディエータの場合、関係代数演算の間の可換規
則や結合規則を利用して、各検索手続き候補が同一の結
果を導出するのを示すことが容易である。これに対し、
従来のＸＭＬメディエータでは、柔軟なスキーマ構造を
扱える反面、問い合せに含まれる再構成・変換を考慮せ
ず、単純に情報源側に検索条件処理を行わせると、利用
者が求める情報を取得できない場合がある。

【００１２】また、異種情報源に検索処理を行わせる
と、以下の問題が生じる。

【００１３】（２）異種情報源管理システムで採用され
ている各問い合せ言語の能力・制約を考慮した上での、
問い合せの最適化が困難である。

【００１４】メディエータは、異なる複数の情報源に対
する検索を行う。そして、各情報源は独自の問い合せ言
語を採用している。利用者からメディエータに対して入
力された問い合せは、各情報源独自の問い合せ言語にマ
ッピングされる。この時、従来のＸＭＬメディエータ
は、各問い合せ言語の能力・制約を考慮しておらず、問
い合せの最適化が困難であるという問題がある。

【００１５】本発明の目的は、異種情報源を統合検索す
る際に、必要な情報の欠損、不要な情報の取得が生じ
ず、各問い合せ言語の能力・制約を考慮して容易に問い
合せの最適化ができつつ、検索実行結果の転送量を低減
し、異種情報源の高速な統合検索を行う統合検索方法お
よび装置を提供することにある。

【００１６】

【課題を解決するための手段】本発明は、入力された問
い合せを、該問い合せが要求する情報を情報源側で欠損
しない検索命令文へと変換し、変換された検索命令文を
情報源に送信し、検索を実行させ、情報源での検索実行
結果を、問い合せが要求している情報へと統合する。

【００１７】そして、入力された問い合せを、その要求
する情報が情報源側で欠損しないような検索命令文に変
換するために、仮検索命令文間にまたがる検索条件節を
結合している論理記号（ＡＮＤ／ＯＲ）や、情報源側で
評価が可能な要素と問い合せが要求している検索条件節
の評価の要素、検索条件節中で指定されている要素との
包含関係を判定することで、個々の仮検索命令文の情報
源側での実行可否、統合検索装置側での再評価要／不
要、限量子の切り替えを判定し、該判定を一時的に保持
し、該判定に基づいて、個々の情報源での検索実行結果
のうち、問い合せが要求していない情報を削除し、問い
合せが要求している情報へと統合する。

【００１８】

【発明の実施の形態】次に、本発明の実施の形態につい
て図面を参照して説明する。

【００１９】図１は本発明の一実施形態である統合検索
装置の構成を示すブロック図である。

【００２０】統合検索装置１はユーザインタフェース部
１１と構文解析部１２と統合検索処理部１３と情報源ア
クセス部１４とメタデータ記憶部１５とメタデータ管理
部１６とを有する。

【００２１】ユーザインタフェース部１１は、アプリケ
ーションプログラム３を介して入力される問い合せ７を
受け付ける。問い合せ７は複数の検索結果構造指定語
（ｃ＝１〜Ｃ）を含む検索結果構造指定部分７ａと、複
数の検索条件指定語（ｗ＝１〜Ｗ）からなる検索条件指
定部分７ｂから構成される。検索結果構造指定語および
検索条件指定語を総称して問い合せ指定語と呼ぶ。

【００２２】構文解釈部１２は、ユーザインタフェース
部１１が受け付けた問い合せ７の構文を解析する。

【００２３】統合検索処理部１３は、各情報源管理シス
テム５₁，５₂で採用されている問い合せ言語によって記
述された検索命令文８を生成し、各情報源６_1a，６_1b，
６_2a，６_2bに格納されている情報を一括して検索する。
統合検索処理部１３中で、ビュー所在探索部２１は、問
い合せ７中（検索結果構造指定部分７ａ、検索条件指定
部分７ｂ）で指定されたビューの所在を探索する。ここ
で、ビューとは、ある視点からとらえた仮想的な情報で
ある。本実施形態では、ビューには（ａ）情報源６_1a，
６_1b，６_2a，６_2bの情報をそのまま登録したビュー（以
下、情報源ビュー）、（ｂ）問い合せ７により新しく生
成し、登録したビュー（以下、問い合せ生成ビュー）の
２種類がある。検索命令文生成計画部２２は、（１）ア
プリケーションプログラム３を介して入力された問い合
せ７、（２）探索されたビューのスキーマ構造、（３）
各情報源管理システム５₁，５₂で採用されている問い合
せ言語の能力・制約を考慮して、情報源６_1a，６_1b，６
_2a，６_2bにどのような検索命令文８を送信すればよいか
を計画し、さらに、各検索命令文８の検索結果を統合す
るための処理を計画する。検索命令文生成実行部２３
は、検索命令文生成計画部２２が計画した情報源に送信
する検索命令文８に関する情報を受けて、問い合せ指定
語を構成して、情報源アクセス部１４が送出する検索命
令文８を生成する。処理一時記憶部２４は、検索命令文
生成計画部２２が計画した各検索命令文８の検索結果の
処理に関する情報を一時的に記憶する領域である。検索
結果処理部２５は、情報源アクセス部１４が取得した情
報源検索結果９に対し、それらを統合するために、検索
命令文生成計画部２２が計画し、処理一時記憶部２４が
記憶していた処理（複数の情報源に跨ったジョインや、
検索条件によるフィルタリング、検索結果構造の再構成
等）を行う。

【００２４】情報源アクセス部１４は、生成された検索
命令文８を各情報源管理システム５ ₁，５₂に送信し、情
報を取得する。この情報源アクセス部１４には、通信網
４を介して情報源管理システム５₁，５₂が接続されてい
る。

【００２５】メタデータ記憶部１５は、各情報源管理シ
ステム５₁，５₂の所在、アクセス情報、各情報源６_1a，
６_1b，６_2a，６_2bに格納されているビューのスキーマ構
造・構成要素などに関する情報を記憶し管理する。

【００２６】メタデータ管理部１６は、メタデータ記憶
部１５に対する各種情報の入力／削除／変更を行う。シ
ステム管理者は、メタデータ管理部１６を介してメタデ
ータを登録・管理する。

【００２７】図２はメタデータ記憶部１５が保有する情
報の詳細を示す。メタデータ記憶部１５は、各情報源管
理システム５₁，５₂にアクセスする手段等の情報源管理
システムに関する情報を管理する情報源管理システムメ
タデータと、情報源ビューのスキーマ構造・要素および
所在やユーザ名などのアクセス情報あるいは問い合せ生
成ビューを生成するための問い合せ（ビュー生成用問い
合せ）と生成されたビューのスキーマ構造・要素を管理
するビューメタデータと、ビューとビューとの間の関連
および関連を結びつけるための要素を管理する関連メタ
データとを保有する。

【００２８】次に、統合検索装置１の処理手順の概要に
ついて説明する。図３は本実施形態の全体の概略動作を
示すフローチャートであり、準備フェーズ（ステップ１
００）と検索フェーズ（ステップ２００）の順で処理が
行われる。準備フェーズでは、検索を実行する前に、シ
ステム管理者がメタデータの準備を行う。検索フェーズ
は検索を実行するフェーズである。

【００２９】図４は準備フェーズを具体的に示すフロー
チャートである。まず、各情報源管理システム５₁，５₂
に関する情報を情報源管理システムメタデータに定義し
（ステップ１０１）、各ビューのアクセス情報とスキー
マ構造・要素あるいはビューを生成するための問い合せ
と登録されたビューのスキーマ構造・要素をビューメタ
データに定義し（ステップ１０２）、ビューとビューと
の間の関連および関連を結びつけるための要素に関する
情報を関連メタデータに定義する（ステップ１０３）。
上記処理は、メタデータ管理部１６を介してシステム管
理者が定義してもよいし、各情報源６_1a，６_1b，６_2a，
６_2bがそれぞれのメタ情報を返却する機構を有していれ
ば、該機構を利用し、自動的に定義してもよい。

【００３０】図５は検索フェーズを具体的に示すフロー
チャートである。検索フェーズでは、まず、ユーザイン
タフェース部１１が、アプリケーションプログラム３を
介して入力されたユーザからの問い合せ７を受理する
（ステップ２０１）。構文解析部１２は問い合せ７を解
析し（ステップ２０２）、ビュー所在探索部２１は、問
い合せ７中で指定されたビューをビューメタデータから
探索する（ステップ２０３）。ステップ２０４で、指定
されたビューがビューメタデータに無ければエラー出力
して検索フェーズを終了する。ステップ２０５で、探索
されたビューが問い合せ生成ビューの場合、ビュー生成
用問い合せ中で指定されたビューをさらにビューメタデ
ータから探索する。これを情報源ビューに行き着くまで
繰り返す。つづいて、該情報源ビューを管理する情報源
管理システム５₁，５₂をビューメタデータから探索し
（ステップ２０６）、該情報源ビューへのアクセス情報
の項目が情報源管理システムメタデータに設定されてい
る項目と等しいかを判断し（ステップ２０７）、等しく
なければエラー出力して検索フェーズを終了する。次
に、検索命令文生成計画部２２は、ビューメタデータ、
関連メタデータを参照して、仮検索命令文（ｃａｎｄ＝
１〜ＣＡＮＤ）の組み合わせを生成し（ステップ２０
８）、処理一時記憶部２４を初期化する（ステップ２０
９）。初期化では、全ての検索条件指定語について、
「限量子」を問い合せそのままに、「情報源側での評価
が可能」であり、「統合検索装置側での評価は不要」と
設定する。次に、仮検索命令文が１つ（ｃａｎｄ＝１）
（ステップ２１０）か、または仮検索命令文が複数の場
合、仮検索命令文間にまたがる検索条件指定部分が全て
ＡＮＤ条件で連結され（ステップ２１１）、かつ等結合
の場合（ステップ２１２）のみ、検索条件処理を情報源
側に行わせられる可能性がある。その他の場合、検索条
件処理を情報源側に行わせることはできず、全て統合検
索装置１側で行う。したがって、処理一時記憶部２４を
「情報源側での評価が不可能」、「統合検索装置側での
評価が必要」と更新する（ステップ２１３）。検索条件
処理を情報源に行わせられる可能性がある場合、個々の
仮検索命令文の各検索条件指定語Ｗｃａｎｄ（ｉ）（ｉ
＝１〜Ｎ）についてビューメタデータを参照して、情報
源側で評価が可能な要素とアプリケーションプログラム
３を介して入力された問い合せ７が要求している評価の
要素との包含関係が（１）１：１、（２）Ｎ：１、
（３）１：Ｎのいずれかを判定する（ステップ２１
４）。なお、以下で１とは要素数が高々１であることを
指す。（１）１：１の場合、検索条件指定部分７ｂの限
量子がＡＬＬでもＡＮＹでも、検索条件指定語Ｗｃａｎ
ｄ（ｉ）に関しては検索条件処理を情報源側に行わせら
れるため、処理一時記憶部２４の更新は行わない。
（２）Ｎ：１の場合、検索条件指定部分７ｂの限量子が
ＡＬＬでもＡＮＹでも、Ｗｃａｎｄ（ｉ）に関しては検
索条件処理を情報源側に行わせることはできない。つま
り、統合検索装置１側で評価を行う必要がある。処理一
時記憶部２４を「情報源側での評価が不可能」、「統合
検索装置側での評価が必要」と更新する（ステップ２１
５）。（３）１：Ｎの場合、さらに、情報源側で評価が
可能な要素と検索条件指定語Ｗｃａｎｄ（ｉ）との包含
関係が（３−１）１：１、（３−２）１：Ｎのいずれか
を判定する（ステップ２１６）。（３−１）１：１の場
合、検索条件指定部分７ｂの限量子がＡＬＬでもＡＮＹ
でも、Ｗｃａｎｄ（ｉ）に関しては検索条件処理を情報
源側に行わせられる。したがって、処理一時記憶部２４
は更新を行わない。（３−２）１：Ｎの場合、検索条件
指定部分７ｂの限量子がＡＬＬの場合、ＡＮＹにして、
ＡＮＹの場合、そのままで、Ｗｃａｎｄ（ｉ）に関して
は検索条件処理を情報源側に行わせられる。ただし、統
合検索装置側で再評価が必要となる。したがって、「統
合検索装置１側での評価が必要」、「限量子について
は、ＡＬＬをＡＮＹに変更」するように処理一時記憶部
２４を更新する（ステップ２１７）。上記の処理を検索
条件指定語の数Ｎ回分繰り返す。そして、各検索条件指
定語Ｗｃａｎｄ（ｉ）間のＡＮＤ／ＯＲにより、最終的
に条件処理を情報源側に行わせられるかを判定し、これ
で処理一時記憶部２４の情報を更新する（ステップ２１
８）。上記の処理を、仮検索命令文の数（ＣＡＮＤ）分
繰り返す。検索命令文生成実行部２３は、探索されたビ
ューの所在および上記処理に関する情報を参照し、検索
命令文８を生成する（ステップ２１９）。情報源アクセ
ス部１４は、生成された検索命令文８をアクセス情報と
ともに各情報源管理システム５₁，５₂に送信し（ステッ
プ２２０）、情報源検索結果９を取得する（ステップ２
２１）。検索結果処理部２５は、情報源アクセス部１４
が取得した情報源検索結果９に対し、処理一時記憶部２
４を参照し、問い合せ７に応じた処理（複数の情報源に
跨ったジョインや、検索条件によるフィルタリング、検
索結果構造の再構成等）を行い（ステップ２２２）、ユ
ーザインタフェース部１１を介して検索結果１０を出力
する（ステップ２２３）。

【００３１】次に、本実施形態における処理手順の詳細
を、図７から図４３を用いて具体的に説明する。（Ａ）ＸＰａｔｈを問い合せとして受付可能な情報源管
理システム図７は、検索対象となるＸＭＬ文書群を管理する情報源
管理システムおよび情報源の例を示すイメージ図であ
る。ＸＭＬ文書群を格納しているデータベース名はｉｔ
ｅｍ＿ｉｎｆｏｒｍａｔｉｏｎであり、ＸＭＬ文書管理
システムｅＸｏｂｊｅｃｔにより管理されている。接続
するためのユーザ名はａｄｍｉｎであり、パスワードは
ｈｏｇｅｈｏｇｅである。ｅＸｏｂｊｅｃｔは、ＸＰａ
ｔｈを問い合せとして受け付け可能な情報源管理システ
ムである。ＸＰａｔｈ規格では、木構造をどのような経
路でたどって所望のデータを特定するかという記述法を
決めている（詳細は、参考文献［１］：http://www.w3.
org/TR/xpath20/ 参照）。

【００３２】図８、図９は、ｉｔｅｍ＿ｉｎｆｏｒｍａ
ｔｉｏｎに格納されているＸＭＬ文書ｂｒａｎｄ−ｌｉ
ｓｔ．ｘｍｌの内容を示す図である。図８（ａ）は、文
書要素およびその階層構造を規定するＤＴＤ（Document
Type Definition）のグラフィック表現、図８（ｂ）は
実際のＸＭＬ文書、図９は実際のＸＭＬ文書（インスタ
ンス）のグラフィック表現をそれぞれ示す図である（グ
ラフィック表現については、参考文献［５］：改定版標
準ＸＭＬ完全解説参照）。（Ｂ）ＳＱＬを問い合せとして受付可能な情報源管理シ
ステム図１０は、検索対象となる文字・数値情報を格納してい
る関係データベース管理システムおよび関係データベー
スの例を示すイメージ図である。関係データベース名は
ｏｒｄｅｒ＿ｄａｔａであり、関係データベース管理シ
ステムＤａｔａＳＱＬにより管理されている。接続する
ためのユーザ名はｔｉｇｅｒであり、パスワードはｇｅ
ｈｏｇｅｈｏである。ＤａｔａＳＱＬは、標準的なＳＱ
Ｌを受け付ける関係データベース管理システムである。

【００３３】図１１に示す通り、データベースｏｒｄｅ
ｒ＿ｄａｔａには、注文ＩＤと発注者とを管理するｏｒ
ｄｅｒテーブル、商品名と価格を管理するｉｔｅｍテー
ブルなどが格納されている。

【００３４】次に、上記具体例に基づいて、図３に示す
各フェーズの動作を具体的に説明する。

【００３５】まず、準備フェーズについて説明する。図
１２は情報源管理システム名とライブラリ名と該システ
ムにアクセスするのに必要な情報の種別とを示す情報源
管理システムメタデータの内容を示す図である。各情報
源管理システムにアクセスする手段に関する情報とし
て、図１２に示すように、情報源管理システム名と接続
手段のライブラリ名と該システムにアクセスするのに必
要な情報の種別とを情報源管理システムメタデータに設
定する（図４のステップ１０１）。

【００３６】図１３は、情報源ビューのスキーマ構造・
要素および所在やユーザ名などのアクセス情報あるいは
問い合せ生成ビューを生成するための問い合せ（ビュー
生成用問い合せ）と生成されたビューのスキーマ構造・
要素を管理するビューメタデータの内容を示す図であ
る。図１３（ａ），（ｂ）が、それぞれｅＸｏｂｊｅｃ
ｔに管理されているデータベースｉｔｅｍ−ｉｎｆｏｒ
ｍａｔｉｏｎとＤａｔａＳＱＬに管理されているデータ
ベースｏｒｄｅｒ＿ｄａｔａのアクセス情報、スキーマ
構造、要素を表している情報源ビューのビューメタデー
タである。ｍｉｎＯｃｃｕｒおよびｍａｘＯｃｃｕｒは
各要素の出現回数の最小値および最大値である。ｕｎｂ
ｏｕｎｄｅｄは無限大を示す。

【００３７】ビューを生成するための言語は、アプリケ
ーションプログラム３を介して入力される問い合せ７と
同じ言語を採用するとし、複数の検索結果構造指定語
（ｃ＝１〜Ｃ）からなる検索結果構造指定部分７ａと、
複数の検索条件指定語（ｗ＝１〜Ｗ）からなる検索条件
指定部分７ｂから構成されるとする。本実施形態では、
ＸＱｕｅｒｙのＦＬＷＲ式を用いて説明する。ＦＬＷＲ
式には、指定されたノードシーケンスを変数にバイン
ドするＦＯＲ節またはＬＥＴ節、指定された条件に従
ってノードシーケンスをフィルタリングするＷＨＥＲＥ
節、照会結果ツリーを生成するＲＥＴＵＲＮ節からな
る（詳細は参考文献［２］：http://www.w3.org/TR/xqu
ery/ 参照）。図１３（ｃ）が、データベースｏｒｄｅ
ｒ＿ｄａｔａに対して生成したビューｏｒｄｅｒ−ｌｉ
ｓｔの生成用問い合せ、スキーマ構造、要素を表してい
る問い合せ生成ビューのビューメタデータである。

【００３８】各情報のアクセス情報とスキーマ構造・要
素あるいはビューを生成用問い合せと登録されたビュー
のスキーマ構造・要素を、ビューメタデータに設定する
（図４のステップ１０２）。

【００３９】図１４は、ビューとビューとの間の関連お
よび関連を結びつけるための要素に関する情報である関
連メタデータの内容を示す図である。図１４は２つのビ
ューを商品名（ｉｔｅｍ−ｎａｍｅとｄｅｓｃｒｉｐｔ
ｉｏｎ）で等結合することを示す。関連に関する情報を
関連メタデータに設定する（図４のステップ１０３）。

【００４０】次に、検索フェーズについて説明する。（ａ）ＸＰａｔｈ情報源に対する問い合せ−その１図１５に示す問い合せがアプリケーションプログラム３
から発行された場合を例に具体的に説明する。図１５は
「ブランド名がＡｎｄｒｅｗＳｏｃｃｅｒである製品
のブランド名と製品名を検索する」問い合せである。

【００４１】まず、問い合せ７を受理し（図５のステッ
プ２０１）、構文解析部１２は問い合せ７を解析する
（図５のステップ２０２）。

【００４２】・検索結果構造指定語ｂｒａｎｄ−ｎａ
ｍｅ，ｉｔｅｍ−ｎａｍｅ・検索条件指定語ｂｒａｎｄ−ｎａｍｅビュー所在探索部２１は、問い合せ７中で指定されたビ
ューをビューメタデータから探索する（図５のステップ
２０３）。図１５の問い合せでは、２行目のｂｒａｎｄ
−ｌｉｓｔから図１３（ａ）の３行目ｂｒａｎｄ−ｌｉ
ｓｔが探索される。問い合せ７で指定されたビューが存
在し（図５のステップ２０４）、かつ情報源ビューなの
で（図５のステップ２０５）、ビューｂｒａｎｄ−ｌｉ
ｓｔを管理する情報源管理システムをビューメタデータ
から探索する（図５のステップ２０６）。図１３（ａ）
の６行目から該情報源ビューを管理しているのはｅＸｏ
ｂｊｅｃｔである。また、アクセス情報の項目も図１２
と図１３（ａ）８行目から１０行目との比較から、ｄｂ
−ｎａｍｅ、ｕｓｅｒ−ｎａｍｅ、ｐａｓｓｗｏｒｄと
等しい（図５のステップ２０７）。

【００４３】次に、検索命令文生成計画部２２は仮検索
命令文の組み合わせを生成し（図５のステップ２０
８）、図１６に示すように処理一時記憶部２４を初期化
する（図５のステップ２０９）。図１６の５行目が検索
条件指定語ｂｒａｎｄ−ｎａｍｅの検索条件処理を情報
源側に行わせられ（ｐｕｓｈ＿ｄｏｗｎ＝“ＯＫ”）、
統合検索装置１側での（再）評価が不要であり（ｅｖａ
ｌｕａｔｅ＝“ＮｏＮｅｅｄ”）、限量子はＡＮＹで
評価すること（ｑｕａｎｔｉｆｉｅｒ＝“ＡＮＹ”）を
示している（ＸＱｕｅｒｙのＷＨＥＲＥ節はデフォルト
ＡＮＹのため初期化ではＡＮＹとする）。

【００４４】図１５の問い合せ７は単一の情報源ビュー
に対する問い合せなので、仮検索命令文の数ｃａｎｄ＝
１であり、検索条件処理を情報源側に行わせられる可能
性がある（図５のステップ２１０）。また、検索条件指
定語は１語（ｂｒａｎｄ−ｎａｍｅ）なので、ｉ＝１で
ある。

【００４５】次に、検索条件指定語ｂｒａｎｄ−ｎａｍ
ｅについてビューメタデータを参照して、情報源側で評
価が可能な要素とアプリケーションプログラム３を介し
て入力された問い合せ７が要求している評価の要素との
包含関係を判定する（図６のステップ２１４）。情報源
側で評価が可能な要素は、ＸＰａｔｈの持つ制約により
「全ての検索結果構造指定語および検索条件指定語に共
通する親要素」となる。図１３（ａ）の１４行目から２
４行目のスキーマを参照すると、ｂｒａｎｄ−ｎａｍｅ
とｉｔｅｍ−ｎａｍｅに共通する親要素はｂｒａｎｄな
ので、これが情報源側での評価可能な要素となる。一
方、図１５に示す問い合せ７が要求している評価の要素
はｆｏｒ節で変数に結びつけた要素となるため、ｉｔｅ
ｍとなる。以上と図１３（ａ）のスキーマより、ｂｒａ
ｎｄ１個に対し、ｉｔｅｍはＮ個と判定される（図６の
ステップ２１４）。

【００４６】さらに、情報源側での評価要素ｂｒａｎｄ
１個に対し、検索条件指定語ｂｒａｎｄ−ｎａｍｅは１
個なので（図６のステップ２１６）、処理一時記憶部２
４の更新は行わない。また、検索条件指定語は１語なの
で、ＡＮＤ／ＯＲによる更新（図６のステップ２１８）
も行われない。

【００４７】検索命令文生成実行部２３は検索命令文８
を生成する（図６のステップ２１９）。生成された検索
命令文８（ＸＰａｔｈ）を図１７に示す。

【００４８】情報源アクセス部１４は、生成された検索
命令文８（図１７）をアクセス情報（ｄｂ−ｎａｍｅ：
ｉｔｅｍ−ｉｎｆｏｒｍａｔｉｏｎ，ｕｓｅｒ−ｎａ
ｍｅ：ａｄｍｉｎ，ｐａｓｓｗｏｒｄ：ｈｏｇｅｈｏ
ｇｅ）とともに情報源管理システムｅＸｏｂｊｅｃｔに
送信し（図６のステップ２２０）、情報源検索結果９を
取得する（図６のステップ２２１）。情報源アクセス部
１４は図１８に示す。

【００４９】検索結果処理部２５は、情報源アクセス部
１４が取得した情報源検索結果９に対し、処理一時記憶
部２４を参照し、検索結果構造の再構成を行い（図６の
ステップ２２２）、ユーザインタフェース部１１を介し
て検索結果１０を出力する（図６のステップ２２３）。
最終的な検索結果を図１９に示す。（ｂ）ＸＰａｔｈ情報源に対する問い合せ−その２続いて、図２０に示す問い合せ７がアプリケーションプ
ログラム３から発行された場合を例に具体的に説明す
る。図２０は「色が赤（一色）の製品のブランド名と製
品名を検索する」問い合せである（色は１つの製品につ
いて複数色指定可能。図９のＡＳ−ｔｉｅ０１参照）。

【００５０】図５のステップ２０１から２０７までは先
ほどの（ａ）ＸＰａｔｈ情報源に対する問い合せ−その
１と同じなので、説明を省略する。

【００５１】・検索結果構造指定語ｂｒａｎｄ−ｎａ
ｍｅ，ｉｔｅｍ−ｎａｍｅ・検索条件指定語ｃｏｌｏｒ次に、検索命令文生成計画部２２は仮検索命令文の組み
合わせを生成し（図５のステップ２０８）、図２１に示
すように処理一時記憶部２４を初期化する（図５のステ
ップ２０９）。図２１の５行目が検索条件指定語ｃｏｌ
ｏｒの検索条件処理を情報源側に行わせられ（ｐｕｓｈ
＿ｄｏｗｎ＝“ＯＫ”）、統合検索装置１側での（再）
評価が不要であり（ｅｖａｌｕａｔｅ＝“ＮｏＮｅｅ
ｄ”）、限量子はＡＬＬで評価すること（ｑｕａｎｔｉ
ｆｉｅｒ＝“ＡＬＬ”）を示している（図２０に示す問
い合せの３行目が限量子ＡＬＬを示しているため）。

【００５２】図２０の問い合せ７は単一の情報源ビュー
に対する問い合せなので、仮検索命令文の数ｃａｎｄ＝
１であり、検索条件処理を情報源側に行わせられる可能
性がある（図５のステップ２１０）。また、検索条件指
定語は１語（ｃｏｌｏｒ）なので、ｉ＝１である。

【００５３】次に、検索条件指定語＄ｉｔｅｍ／ｃｏｌ
ｏｒについてビューメタデータを参照して、情報源側で
評価が可能な要素と、「アプリケーションプログラム３
を介して入力された問い合せ７が要求している評価の要
素との包含関係を判定する（図６のステップ２１４）。
先ほどの例同様、情報源側での評価可能な要素はｂｒａ
ｎｄ、図２０に示す問い合せ７が要求している評価の要
素はｉｔｅｍとなるため、ｂｒａｎｄ１個に対し、ｉｔ
ｅｍはＮ個と判定される（図６のステップ２１４）。

【００５４】さらに、情報源側での評価可能な要素ｂｒ
ａｎｄ１個に対し、検索条件指定語ｃｏｌｏｒはＮ個な
ので（図６のステップ２１６）、処理一時記憶部２４を
更新する（図６のステップ２１７）。具体的には、図２
１の５行目ｅｖａｌｕａｔｅ＝“ＮｏＮｅｅｄ”をｅ
ｖａｌｕａｔｅ＝“Ｎｅｅｄ”、ｑｕａｎｔｉｆｉｅｒ
＝“ＡＬＬ”をｑｕａｎｔｉｆｉｅｒ＝“ＡＮＹ”とす
る。ＡＬＬのままでは、「色が赤のみの製品ばかり扱っ
ているブランド」が取得され、製品ＣＫ−ｔｉｅ０１が
情報源側で落とされてしまう。また、検索条件指定語は
１語なので、ＡＮＤ／ＯＲによる更新（図６のステップ
２１８）は行われない。

【００５５】検索命令文生成実行部２３は検索命令文８
を生成する（図６のステップ２１９）。生成された検索
命令文８（ＸＰａｔｈ）を図２２、取得された検索結果
１０を図２３に示す。「色が（ＡＮＹ＝１つでも）赤い
製品を含むブランド」が取得されている。

【００５６】検索結果処理部２５は、再評価および検索
結果構造の再構成を行い（図６のステップ２２２）、ユ
ーザインタフェース部１１を介して検索結果１０を出力
する（図６のステップ２２３）。最終的な検索結果を図
２４に示す。再評価により、ＡＳ−ｔｉｅ０１、ＣＫ−
ｓｈｉｒｔ０１、ＣＫ−ｔｉｅ０１が落ち、ＡＳ−ｓｈ
ｉｒｔ０１、ＡＳ−ｓｕｉｔ０１、ＣＫ−ｔｉｅ０２が
残る。（ｃ）ＸＰａｔｈ情報源に対する問い合せ−その３続いて、図２５に示す問い合せ７がアプリケーションプ
ログラム３から発行された場合を例に具体的に説明す
る。図２５は「ブランド名がＡｎｄｒｅｗＳｏｃｃｅ
ｒかまたは、色が赤（一色）の製品のブランド名と製品
名を検索する」問い合せである。

【００５７】図５のステップ２０１から２０７までは先
ほどの（ａ）、（ｂ）と同じなので、説明を省略する。

【００５８】・検索結果構造指定語ｂｒａｎｄ−ｎａ
ｍｅ，ｉｔｅｍ−ｎａｍｅ・検索条件指定語ｂｒａｎｄ−ｎａｍｅ，ｃｏ
ｌｏｒ初期化された処理一時記憶部２４を図２６に示す（図５
のステップ２０９）。図２５の問い合せ７は単一の情報
源ビューに対する問い合せなので、仮検索命令文の数ｃ
ａｎｄ＝１であり、検索条件処理を情報源側に行わせら
れる可能性がある（図５のステップ２１０）。

【００５９】図６のステップ２１４，２１６，２１７は
先ほどの（ａ）、（ｂ）と同じなので、説明を省略す
る。次に、検索条件指定語は２語（ｂｒａｎｄ−ｎａｍ
ｅ，ｃｏｌｏｒ）なので、ＡＮＤ／ＯＲによる更新（図
６のステップ２１８）は行う。表１にＡＮＤ／ＯＲによ
る更新マトリックスを示す。

【００６０】

【表１】

【００６１】問い合せ７に示すように、検索条件指定語
はＯＲで連結されており（図５の３行目）、一方が統合
検索装置１での再評価を必要としている場合（ｅｖａｌ
ｕａｔｅ＝“Ｎｅｅｄ”）、統合検索装置１側では、両
方の条件で再評価する必要がある。更新された処理一時
記憶部２４を図２７に示す。

【００６２】検索命令文生成実行部２３は、検索命令文
８を生成する（図６のステップ２１８）。生成された検
索命令文８（ＸＰａｔｈ）を図２８、取得された検索結
果１０を図２９に示す。「ブランド名がＡｎｄｒｅｗ
Ｓｏｃｃｅｒかまたは、色が（ＡＮＹ＝１つでも）、赤
い製品を含むブランド」が取得されている。検索結果処
理部２５は、再評価および検索結果構造の再構成を行い
（図６のステップ２２２）、ユーザインタフェース部１
１を介して検索結果１０を出力する（図６のステップ２
２３）。最終的な検索結果を図３０に示す。ｂｒａｎｄ
−ｎａｍｅにより再評価を行うことで、ＡＳ−ｔｉｅ０
１が残る。（ｄ）ＳＱＬ情報源に対する問い合せ−その１図３１に示す問い合せ７がアプリケーションプログラム
３から発行された場合を例に具体的に説明する。図３１
は「顧客Ｙｏｔｓｕｋｏｓｈｉによる注文（ｏｒｄｅ
ｒ）を検索する」問い合せである。

【００６３】まず、問い合せ７を受理し（図５のステッ
プ２０１）、構文解析部１２は問い合せ７を解析する
（図５のステップ２０２）。

【００６４】・検索結果構造指定語ｏｒｄｅｒ・検索条件指定語ｃｕｓｔｏｍｅｒビュー所在探索部２１は、問い合せ７中で指定されたビ
ューをビューメタデータから探索する（図５のステップ
２０３）。図３１の問い合せ７では、１行目のｏｒｄｅ
ｒ−ｌｉｓｔから図１３（ｃ）の７１行目ｏｒｄｅｒ−
ｌｉｓｔが探索される。問い合せ７で指定されたビュー
は存在したが（図５のステップ２０４）、情報源ビュー
ではないので（図５のステップ２０５）、ビュー生成問
い合せ内で指定されているビューを、再びビューメタデ
ータから探索する（図５のステップ２０３）。ビュー生
成問い合せでは、図１３（ｃ）７４行目のｏｒｄｅｒ−
ｄａｔａから図１３（ｂ）の３１行目ｏｒｄｅｒ−ｄａ
ｔａが問い合せで指定されたビューが存在し（図５のス
テップ２０４）、かつ情報源ビューなので（図５のステ
ップ２０５）、ｏｒｄｅｒ−ｄａｔａを管理する情報源
管理システムをビューメタデータから探索する（図５の
ステップ２０６）。図１３（ｂ）の３４行目から該情報
源ビューを管理しているのはＤａｔａＳＱＬである。ま
た、アクセス情報の項目も図１２と図１３（ｂ）３６行
目から３８行目との比較から、ｄｂ−ｎａｍｅ、ｕｓｅ
ｒ−ｎａｍｅ、ｐａｓｓｗｏｒｄと等しい（図５のステ
ップ２０７）。

【００６５】・検索結果構造指定語ｉｄ，ｃｕｓｔ−
ｎａｍｅ，ｄｅｓｃｒｉｐｔｉｏｎ，ｃｏｓｔ・検索条件指定語ｃｕｓｔ−ｎａｍｅ，ｉｄ（ジ
ョイン条件），ｏｉｄ（ジョイン条件）次に、検索命令文生成計画部２２は仮検索命令文の組み
合わせを生成し（図５のステップ２０８）、図３２に示
すように処理一時記憶部２４を初期化する（図５のステ
ップ２０９）。図３２の５行目が検索条件指定語ｃｕｓ
ｔ−ｎａｍｅの検索条件処理を情報源側に行わせられ
（ｐｕｓｈ＿ｄｏｗｎ＝“ＯＫ”）、統合検索装置１側
での（再）評価が不要であり（ｅｖａｌｕａｔｅ＝“Ｎ
ｏＮｅｅｄ”）、限量子はＡＮＹで評価すること（ｑ
ｕａｎｔｉｆｉｅｒ＝“ＡＮＹ”）を示している（ＳＱ
ＬのＷＨＥＲＥ節はデフォルトＡＮＹのため初期化では
ＡＮＹとする）。

【００６６】図３１の問い合せ７は単一の情報源ビュー
に対する問い合せなので、仮検索命令文の数ｃａｎｄ＝
１であり、検索条件処理を情報源側に行わせられる可能
性がある（図５のステップ２１０）。また、検索条件指
定語は１語（ｃｕｓｔ−ｎａｍｅ）なので、ｉ＝１であ
る。

【００６７】次に、ビューメタデータを参照して、情報
源側で評価が可能な要素とアプリケーションプログラム
３を介して入力された問い合せ７が要求している評価の
要素との包含関係を判定する（図６のステップ２１
４）。情報源側での評価可能な要素は、ＳＱＬの持つ制
約により「ｒｏｗ要素毎」となる。判定のため、図１３
（ｃ）のビュー生成問い合せによって生成されるビュー
の内容を図３３、３４に示す。図３３は、ビューの要素
および階層構造を規定するＤＴＤのグラフィック表現、
図３４はインスタンスのグラフィック表現をそれぞれ示
す図である。図３１に示す問い合せ７が要求している評
価の要素はｆｏｒ節で変数に結びつけた要素となるた
め、ｏｒｄｅｒとなる。以上より、ｒｏｗ（＝ｄｂ／ｏ
ｒｄｅｒ／ｒｏｗ）１個に対し、ｏｒｄｅｒは１個なの
で、更新は行わない。また、検索条件指定語は１語なの
で、ＡＮＤ／ＯＲによる更新（図６のステップ２１８）
も行われない。検索命令文生成実行部２３は検索命令文
８を生成する（図６のステップ２１９）。生成された検
索命令文８（ＳＱＬ）を図３５に示す。

【００６８】情報源アクセス部１４は、生成された検索
命令文８（図３５）をアクセス情報（ｄｂ−ｎａｍｅ：
ｏｒｄｅｒ＿ｄａｔａ，ｕｓｅｒ−ｎａｍｅ：ｔｉｇ
ｅｒ，ｐａｓｓｗｏｒｄ：ｇｅｈｏｇｅｈｏ）ととも
に情報源管理システムＤａｔａＳＱＬに送信し（図６の
ステップ２２０）、情報源検索結果９を取得する（図６
のステップ２２１）。取得された検索結果を図３６に示
す。

【００６９】検索結果処理部２５は、情報源アクセス部
１４が取得した情報源検索結果９に対し、処理一時記憶
部２４を参照し、検索結果構造の再構成を行い（図６の
ステップ２２２）、ユーザインタフェース部１１を介し
て検索結果１０を出力する（図６のステップ２２３）。
最終的な検索結果１０を図３７に示す。（ｅ）ＳＱＬ情報源に対する問い合せ−その２図３８に示す問い合せ７がアプリケーションプログラム
３から発行された場合を例に具体的に説明する。図３８
は「（一つでも）５０００円より高い商品（ｉｔｅｍ）
を含む注文（ｏｒｄｅｒ）を検索する」問い合せであ
る。

【００７０】図５のステップ２０１から２０７までは先
ほどの（ｄ）ＳＱＬ情報源に対する問い合せ−その１と
ほぼ同じなので、説明を省略する。問い合せ７中の検索
結果構造指定語と検索条件指定語を以下に示す。

【００７１】・検索結果構造指定語ｏｒｄｅｒ・検索条件指定語ｃｏｓｔビューｏｒｄｅｒ−ｄａｔａに対する検索結果構造指定
語と検索条件指定語を以下に示す。

【００７２】・検索結果構造指定語ｉｄ，ｃｕｓｔ−
ｎａｍｅ，ｄｅｓｃｒｉｐｔｉｏｎ，ｃｏｓｔ・検索条件指定語ｃｏｓｔ，ｉｄ（結合条件），
ｏｉｄ（結合条件）次に、検索命令文生成計画部２２は仮検索命令文の組み
合わせを生成し（図５のステップ２０８）、図３９に示
すように処理一時記憶部２４を初期化する（図５のステ
ップ２０９）。

【００７３】図３８の問い合せ７は単一の情報源ビュー
に対する問い合せなので、仮検索命令文の数ｃａｎｄ＝
１であり、検索条件処理を情報源側に行わせられる可能
性がある（図５のステップ２１０）。また、検索条件指
定語は１語（ｃｕｓｔ−ｎａｍｅ）なので、ｉ＝１であ
る。次に、情報源側で評価が可能な要素と問い合せが要
求している評価の要素との包含関係を判定する（図６の
ステップ２１４）。情報源側での評価可能な要素は、
（ｄ）同様、ｒｏｗ要素毎、問い合せ７が要求している
評価の要素はｏｒｄｅｒとなる。以上より、ｒｏｗ（＝
ｄｂ／ｉｔｅｍ／ｒｏｗ）Ｎ個に対しｏｒｄｅｒは１個
なので（１ｏｒｄｅｒ（注文）に対し、ｉｔｅｍ（商
品）がＮ）、処理一時記憶部２４を更新する（図６のス
テップ２１５）。具体的には、図３９の５行目ｐｕｓｈ
＿ｄｏｗｎ＝“ＯＫ”をｐｕｓｈ＿ｄｏｗｎ＝“Ｎ
Ｇ”、ｅｖａｌｕａｔｅ＝“ＮｏＮｅｅｄ”をｅｖａ
ｌｕａｔｅ＝“Ｎｅｅｄ”とする。更新せずに、検索条
件を情報源に処理させると、ＡＳ−ｔｉｅ０１が４８０
０円なので、情報源側で落とされてしまう。また、検索
条件指定語は１語なので、ＡＮＤ／ＯＲによる更新（図
６のステップ２１８）は行われない。

【００７４】検索命令文生成実行部２３は検索命令文８
を生成する（図６のステップ２１９）。生成された検索
命令文８（ＳＱＬ）を図４０に示す。検索条件処理は行
わない。

【００７５】検索結果処理部２５は、再評価および検索
結果構造の再構成を行い（図６のステップ２２２）、ユ
ーザインタフェース部１１を介して検索結果１０を出力
する（図６のステップ２２３）。最終的な検索結果を図
４１に示す。（ｆ）統合検索図４２に示す問い合せ７がアプリケーションプログラム
３から発行された場合を例に具体的に説明する。図４２
は「顧客Ｙｏｔｓｕｋｏｓｈｉによる注文のうち、赤い
商品の商品名、価格を検索する」問い合せである。

【００７６】図５のステップ２０１から２０７までは、
（ｂ）ＸＰａｔｈ情報源に対する問い合せ−その２、
（ｄ）ＳＱＬ情報源に対する問い合せ−その１とほぼ同
じなので、説明を省略する。

【００７７】・検索結果構造指定語ｄｅｓｃｒｉｐｔ
ｉｏｎ，ｃｏｓｔ・検索条件指定語ｃｕｓｔｏｍｅｒ，ｃｏｌｏｒ次に、検索命令文生成計画部２２は仮検索命令文の組み
合わせを生成する（図５のステップ２０８）。図１４に
示す関連メタデータはビューｏｒｄｅｒ＿ｄａｔａの要
素ｄｅｓｃｒｉｐｔｉｏｎとビューｂｒａｎｄ−ｌｉｓ
ｔの要素ｉｔｅｍ−ｎａｍｅを等結合することを示して
いる。異種情報源にまたがる結合条件で指定されている
要素を検索結果構造指定語として加えると、それぞれの
ビューに対する検索結果構造指定語と検索条件指定語は
以下のようになり、これが仮検索命令文の組み合せとな
る。

【００７８】ビューｏｒｄｅｒ−ｄａｔａに対する検索
結果構造指定語と検索条件指定語・検索結果構造指定語ｉｄ，ｃｕｓｔ−ｎａｍｅ，ｄ
ｅｓｃｒｉｐｔｉｏｎ，ｃｏｓｔ・検索条件指定語ｃｕｓｔ−ｎａｍｅビューｂｒａｎｄ−ｌｉｓｔに対する検索結果構造指定
語と検索条件指定語・検索結果構造指定語ｉｔｅｍ，ｉｔｅｍ−ｎａｍｅ・検索条件指定語ｃｏｌｏｒ処理一時記憶部２４の初期化も（ｂ）、（ｄ）とほぼ同
じなので説明を省略する。

【００７９】このように情報源ビューに対する問い合せ
が複数であり（ｃａｎｄ＝２）（図５のステップ２１
０）、仮検索命令文間にまたがる検索条件指定部分が全
てＡＮＤ条件で連結され（図５のステップ２１１）、か
つ等結合の場合（図５のステップ２１２）なので、その
処理を続けられる。

【００８０】これ以降の処理は（ｂ）、（ｄ）とほぼ同
じなので説明を省略する。最終的な検索結果を図４３に
示す。

【００８１】なお、統合検索装置１は専用のハードウェ
アにより実現されるもの以外に、その機能を実現するた
めのプログラムを、コンピュータ読み取り可能な記録媒
体に記録して、この記録媒体に記録されたプログラムを
コンピュータシステムに読み込ませ、実行するものであ
ってもよい。コンピュータ読み取り可能な記録媒体と
は、フロッピーディスク、光磁気ディスク、ＣＤ−ＲＯ
Ｍ等の記録媒体、コンピュータシステムに内蔵されるハ
ードディスク装置等の記憶装置を指す。さらに、コンピ
ュータ読み取り可能な記録媒体は、インターネットを介
してプログラムを送信する場合のように、短時間の間、
動的にプログラムを保持するもの（伝送媒体もしくは伝
送波）、その場合のサーバとなるコンピュータシステム
内部の揮発性メモリのように、一定時間プログラムを保
持しているものも含む。

【００８２】

【発明の効果】以上説明したように、本発明によれば、
ＸＭＬメディエータを用いた異種情報源の統合検索にお
いて、入力された問い合せを個々の異種情報源管理シス
テムで受理可能な検索命令文に変換し、検索条件処理を
情報源側で行わせることで、検索実行結果の転送量を軽
減することができ、また、検索実行結果の転送量軽減に
よる問い合せ最適化を利用した、異種情報源の高速な統
合検索を行うことができる。

【図面の簡単な説明】

【図１】本発明の一実施形態である独自処理を記述可能
な情報源の統合検索装置の構成を示すブロック図であ
る。

【図２】メタデータ記憶部１５が保有するテーブルの詳
細を示す図である。

【図３】全体の概略動作を示すフローチャートである。

【図４】準備フェーズを具体的に示すフローチャートで
ある。

【図５】検索フェーズを具体的に示すフローチャート
（その１）である。

【図６】検索フェーズを具体的に示すフローチャート
（その２）である。

【図７】検索対象となるＸＭＬ文書群を管理する情報源
管理システムおよび情報源の例を示すイメージ図であ
る。

【図８】データベースｉｔｅｍ＿ｉｎｆｏｒｍａｔｉｏ
ｎに格納されているＸＭＬ文書ｂｒａｎｄ−ｌｉｓｔ．
ｘｍｌの内容を示す図である。

【図９】データベースｉｔｅｍ＿ｉｎｆｏｒｍａｔｉｏ
ｎに格納されているＸＭＬ文書ｂｒａｎｄ−ｌｉｓｔ．
ｘｍｌの内容を示す図である。

【図１０】検索対象となる文字・数値情報を格納してい
る関係データベース管理システムおよび関係データベー
スの例を示すイメージ図である。

【図１１】データベースｏｒｄｅｒ＿ｄａｔａに格納さ
れているテーブルｏｒｄｅｒとｉｔｅｍの内容を示す図
である。

【図１２】情報源管理システム名とライブラリ名と該シ
ステムにアクセスするのに必要な情報の種別とを示す情
報源管理システムメタデータの内容を示す図である。

【図１３】ビューメタデータの内容を示す図である。

【図１４】ビューとビューとの間の関連および関連を結
びつけるための要素に関する情報である関連メタデータ
の内容を示す図である。

【図１５】説明（ａ）において、使用する問い合せを示
す図である。

【図１６】説明（ａ）において、初期化された処理一時
記憶部２４を示す図である。

【図１７】説明（ａ）において、生成された検索命令文
（ＸＰａｔｈ）を示す図である。

【図１８】説明（ａ）において、情報源アクセス部１４
が取得した情報源検索結果を示す図である。

【図１９】説明（ａ）において、最終的な検索結果を示
す図である。

【図２０】説明（ｂ）において、使用する問い合せを示
す図である。

【図２１】説明（ｂ）において、初期化された処理一時
記憶部２４を示す図である。

【図２２】説明（ｂ）において、生成された検索命令文
（ＸＰａｔｈ）を示す図である。

【図２３】説明（ｂ）において、情報源アクセス部１４
が取得した情報源検索結果を示す図である。

【図２４】説明（ｂ）において、最終的な検索結果を示
す図である。

【図２５】説明（ｃ）において、使用する問い合せを示
す図である。

【図２６】説明（ｃ）において、初期化された処理一時
記憶部２４を示す図である。

【図２７】説明（ｃ）において、更新された処理一時記
憶部２４を示す図である。

【図２８】説明（ｃ）において、生成された検索命令文
（ＸＰａｔｈ）を示す図である。

【図２９】説明（ｃ）において、情報源アクセス部１４
が取得した情報源検索結果を示す図である。

【図３０】説明（ｃ）において、最終的な検索結果を示
す図である。

【図３１】説明（ｄ）において、使用する問い合せを示
す図である。

【図３２】説明（ｄ）において、初期化された処理一時
記憶部２４を示す図である。

【図３３】図１３（ｃ）のビュー生成問い合せによって
生成されるビューの要素および階層構造を規定するＤＴ
Ｄのグラフィック表現を示す図である。

【図３４】図１３（ｃ）のビュー生成問い合せによって
生成されるビューのインスタンスのグラフィック表現を
示す図である。

【図３５】説明（ｄ）において、生成された検索命令文
（ＳＱＬ）を示す図である。

【図３６】説明（ｄ）において、情報源アクセス部１４
が取得した情報源検索結果を示す図である。

【図３７】説明（ｄ）において、最終的な検索結果を示
す図である。

【図３８】説明（ｅ）において、使用する問い合せを示
す図である。

【図３９】説明（ｅ）において、初期化された処理一時
記憶部２４を示す図である。

【図４０】説明（ｅ）において、生成された検索命令文
（ＳＱＬ）を示す図である。

【図４１】説明（ｅ）において、最終的な検索結果を示
す図である。

【図４２】説明（ｆ）において、使用する問い合せを示
す図である。

【図４３】説明（ｆ）において、最終的な検索結果を示
す図である。

【符号の説明】

１統合検索装置２通信網３アプリケーションプログラム４通信網５₁，５₂ 情報源管理システム６_1a，６_1b，６_2a，６_2b 情報源７問い合せ７ａ検索結果構造指定部分７ｂ検索条件指定部分８検索命令文９情報源検索結果１０検索結果１１ユーザインタフェース部１２構文解析部１３統合検索処理部１４情報源アクセス部１５メタデータ記憶部１６メタデータ管理部２１ビュー所在探索部２２検索命令文生成計画部２３検索命令文生成実行部２４処理一時記憶部２５検索結果処理部１００〜１０３，２００〜２２３ステップ

───────────────────────────────────────────────────── フロントページの続き (72)発明者小西一也東京都千代田区大手町二丁目３番１号日本電信電話株式会社内 (72)発明者小林伸幸東京都千代田区大手町二丁目３番１号日本電信電話株式会社内Ｆターム(参考） 5B075 PP24 PP26 5B082 GA08 GC04

Claims

【特許請求の範囲】

【請求項１】入力された問い合せを、該問い合せが要
求する情報を情報源側で欠損しない検索命令文へと変換
するステップと、変換された検索命令文を前記情報源に
送信し、検索を実行させるステップと、情報源での検索
実行結果を、問い合せが要求している情報へと統合する
ステップとを有する、問い合せ最適化を利用した統合検
索方法。
【請求項２】入力された問い合せを、該問い合せが要
求する情報を前記情報源側で欠損しない検索命令文へと
変換するステップは、１つあるいは複数の仮検索命令文
を生成するステップと、該仮検索命令文間にまたがる検
索条件節の情報源側での実行可否を判定するステップ
と、前記情報源のスキーマ構造を保持するステップと、
保持されたスキーマを参照して、前記仮検索命令文中の
検索条件節の情報源側での実行可否、統合検索装置側で
の再評価要／不要、限量子の切り替えを判定するステッ
プと、前記判定に基づいて個々の情報源に受付可能な形
式の検索命令文を生成するステップと、前記判定を一時
的に保持するステップとを含む、請求項１に記載の問い
合せ最適化を利用した統合検索方法。
【請求項３】前記仮検索命令文間にまたがる検索条件
節の情報源側での実行可否を判定するステップは、仮検
索命令文間にまたがる検索条件節を結合している論理記
号を判定するステップである、請求項２に記載の問い合
せ最適化を利用した統合検索方法。
【請求項４】前記情報源のスキーマ構造を保持するス
テップは、異種情報源を半構造化情報という視点でとら
え、該情報源のスキーマ構造および要素の関係を保持す
るステップである、請求項２に記載の問い合せ最適化を
利用した統合検索方法。
【請求項５】異種情報源を半構造化情報という視点で
とらえ、該情報源のスキーマ構造および要素の関係を保
持するステップは、異種情報源のスキーマ構造そのもの
を半構造化情報という視点でとらえ、該情報源のスキー
マ構造および要素の関係を保持するステップと、異種情
報源に対する問い合せにより生成された検索結果を半構
造化情報という視点でとらえ、該検索結果のスキーマ構
造および要素の関係を保持するステップを含む、請求項
４に記載の問い合せ最適化を利用した統合検索方法。
【請求項６】保持されたスキーマを参照して、仮検索
命令文中の検索条件節の情報源側での実行可否、統合検
索装置側での再評価要／不要、限量子の切り替えを判定
するステップは、個々の仮検索命令文の検索条件節につ
いて、前記情報源側で評価が可能な要素と問い合せが要
求している検索条件節の要素との包含関係を判定するス
テップと、前記情報源側で評価が可能な要素と検索条件
節中で指定されている要素との包含関係を判定するステ
ップと、検索命令文中の検索条件節を結合している論理
記号を判定するステップとを含む、請求項２に記載の問
い合せ最適化を利用した統合検索方法。
【請求項７】情報源での検索実行結果を問い合せが要
求している情報へと統合するステップは、前記一時的に
保持された検索条件節の統合検索装置側での再評価要・
不要に関する情報を参照するステップと、個々の情報源
での検索実行結果のうち、問い合せが要求していない情
報を再評価により削除し、問い合せが要求している情報
のスキーマへと構成するステップとを含む、請求項１に
記載の問い合せ最適化を利用した統合検索方法。
【請求項８】入力された問い合せを、該問い合せが要
求する情報を情報源側で欠損しない検索命令文へと変換
する手段と、変換された検索命令文を前記情報源に送信
し、検索を実行させる手段と、前記情報源での検索実行
結果を、前記問い合せが要求している情報へと統合する
手段とを有する、問い合せ最適化を利用した統合検索装
置。
【請求項９】入力された問い合せを、該問い合せが要
求する情報を情報源側で欠損しない検索命令文へと変換
する手段は、１つあるいは複数の仮検索命令文を生成す
る手段と、該仮検索命令文間にまたがる検索条件節の前
記情報源側での実行可否を判定する手段と、前記情報源
のスキーマ構造を保持する手段と、保持されたスキーマ
を参照して、前記仮検索命令文中の検索条件節の情報源
側での実行可否、統合検索装置側での再評価要／不要、
限量子の切り替えを判定する手段と、前記判定に基づい
て個々の情報源に受付可能な形式の検索命令文を生成す
る手段と、前記の判定を一時的に保持する手段を含む、
請求項８に記載の、問い合せ最適化を利用した統合検索
装置。
【請求項１０】前記仮検索命令文間にまたがる検索条
件節の情報源側での実行可否を判定する手段は、前記仮
検索命令文間にまたがる検索条件節を結合している論理
記号を判定する手段である、請求項９に記載の問い合せ
最適化を利用した統合検索装置。
【請求項１１】前記情報源のスキーマ構造を保持する
手段は、異種情報源を半構造化情報という視点でとら
え、該情報源のスキーマ構造および要素の関係を保持す
る手段である、請求項９に記載の問い合せ最適化を利用
した統合検索装置。
【請求項１２】異種情報源を半構造化情報という視点
でとらえ、該情報源のスキーマ構造および要素の関係を
保持する手段は、異種情報源のスキーマ構造そのものを
半構造化情報という視点でとらえ、該情報源のスキーマ
構造および要素の関係を保持する手段と、異種情報源に
対する問い合せにより生成された検索結果を半構造化情
報という視点でとらえ、該検索結果のスキーマ構造およ
び要素の関係を保持する手段を含む、請求項１１に記載
の問い合せ最適化を利用した統合検索装置。
【請求項１３】保持されたスキーマを参照して、仮検
索命令文中の検索条件節の情報源側での実行可否、統合
検索装置側での再評価要／不要、限量子の切り替えを判
定する手段は、個々の仮検索命令文の検索条件節につい
て、前記情報源側で評価が可能な要素と問い合せが要求
している検索条件節の要素との包含関係を判定する手段
と、前記情報源側で評価が可能な要素と検索条件節中で
指定されている要素との包含関係を判定する手段と、検
索命令文中の検索条件節を結合している論理記号を判定
する手段とを含む、請求項９に記載の問い合せ最適化を
利用した統合検索装置。
【請求項１４】情報源での検索実行結果を問い合せが
要求している情報へと統合する手段は、前記の一時的に
保持された検索条件節の統合検索装置側での再評価要／
不要に関する情報を参照する手段と、個々の情報源での
検索実行結果のうち、問い合せが要求していない情報を
再評価により削除し、問い合せが要求している情報のス
キーマへと構成する手段とを含む、請求項８に記載の問
い合せ最適化を利用した統合検索装置。
【請求項１５】請求項１から７のいずれか１項に記載
の統合検索方法をコンピュータに実行させるための統合
検索プログラム。
【請求項１６】請求項１から７のいずれか１項に記載
の統合検索方法をコンピュータに実行させるための統合
検索プログラムを記録した記録媒体。