JP2008176771A - 検索プログラム、方法及び装置 - Google Patents

Abstract

【課題】問い合わせ型データベース統合を行う際に異なる値域又は形式のデータ項目間を関連付けできるようにする。
【解決手段】問い合わせ結果の出力構造を規定する構造データ、当該構造データ中の要素とDBの要素との対応関係、DB間の要素の関連付け、及びDB間の要素の関連付け又はDBの特定の要素に適用する双方向変換関数が規定された統合用メタデータを新たに採用する。そして本検索方法は、複数のDBに対する統合的なデータ参照の問い合わせを受け付ける工程と、統合用メタデータから特定される構造体を問い合わせに基づき上方に探索して、構造体中の最上位要素に対応するDBの要素の値を抽出する工程と、上記構造体を構造体中の最上位要素に対応するDBの要素の値に基づき下方に探索して、各DBの各要素の値を抽出する工程と、抽出された各DBの各要素の値を統合用メタデータに従って出力する工程とを含む。
【選択図】図９

Description

本発明は、複数のデータベースに分散して保持されるデータを統合した形で検索するための技術に関する。

従来は、異なるマシン、異なる環境に置かれた複数の既存データベースに跨って関連するデータが分散している場合に、それらを統合された１つのデータとして参照する為には、新たにデータウェアハウスを構築し、そこに全てのデータを移してくるという方法が採られてきた。しかし、この方法では元のデータベースからデータウェアハウスへデータをコピーする為にタイムラグが生じ、元のデータベースのデータをリアルタイムに参照することはできなかった。また、データウェアハウスは構築にコストと時間がかかるので簡単には作り直せず、ビジネスが短周期で変化してデータベース統合の要求が変わった場合に迅速に対応できないという欠点もあった。

一方、これとは別の方法として、データは元のデータベースに格納したままにしておいて、ユーザから統合されたデータの要求があった時点で、リアルタイムに各データベースに問い合わせて必要なデータを獲得してきて、それを組み立てて返すという方法（以下、問い合わせ型データベース統合と呼ぶ）がある。この方法は、ネットワークを経由してデータを獲得してくるのでレスポンス時間は悪くなるが、近年のネットワークの高速化によって実用性が増してきた。この方法の場合、複数のデータベースに跨っていたデータは、性能問題を除けばあたかも全て１つのデータベース上にあるかのように利用できるようになる。この方法は、データウェアハウスにおけるデータのリアルタイム性の問題も解決するし、データベース自体には手を入れる必要が無いので、ビジネスの変化によるデータベース統合の要求変更にも迅速に対応できるようになる。

例えば図１に示すように、ホストＡに注文伝票テーブル及び商品テーブルを含む受注ＤＢが設けられ、ホストＢに取扱商品テーブルを含む商品ＤＢが設けられ、ホストＣに在庫テーブル１を含む在庫ＤＢ１が設けられ、ホストＤに在庫テーブル２を含む在庫ＤＢ２が設けられる例について検討する。なお、図１では、全てのデータベースがリレーショナルデータベース（ＲＤＢ）であるものとする。また、図１の例では、ｏｒｄｅｒ＿ｉｄというデータ項目（カラムとも呼ぶ）が、注文伝票テーブルと商品テーブルとに登録されており、商品テーブルにおけるｉｔｅｍ＿ｃｏｄｅというデータ項目が在庫ＤＢ２の在庫テーブル２に登録されており、さらに商品テーブルのｉｔｅｍ＿ｃｏｄｅというデータ項目に関連するｃｏｄｅというデータ項目が商品ＤＢの取扱商品テーブル及び在庫ＤＢ１の在庫テーブル１に登録されている。

このように複数のデータベースに跨って登録された関連データを問い合わせ型データベース統合によって参照する技術は、様々なものがあるが、例えば特開２００５−２０８７５７号公報に開示されている。この公報では、複数のデータベースに跨って一体に統合されたタグ付き文書形式のデータビューを提供し、その上で問い合わせ言語を利用した自由な問い合わせを可能とする技術が開示されている。本公報では、複数のデータベースを統合する際の生成ルールとして「ＤＢ統合用メタデータ」というものを用意する。

図２に図１に対応するＤＢ統合用メタデータを模式的に示す。図２の例では、ｏｒｄｅｒというノードの子ノードとして受注ＤＢにおける注文伝票テーブルの各データ項目に対応するノードが配置されている。さらに、ｏｒｄｅｒというノードの子ノードにはｉｔｅｍｓという中間的なノードも設けられている。そして、ｉｔｅｍｓというノードの子ノードには、ｉｔｅｍというノードが設けられており、ｉｔｅｍというノードの子ノードとしては、受注ＤＢの商品テーブルの各データ項目に対応するノードが配置されている。さらに、ｉｔｅｍというノードの子ノードとして、商品ＤＢの取扱商品テーブルの各データ項目に対応するノードの親ノードと、在庫ＤＢ１及び在庫ＤＢ２における在庫テーブル１及び在庫テーブル２の各データ項目に対応するノードの親ノードとが設けられている。なお、在庫テーブル１及び２については、ノードを共用している。また、上で述べたデータベース間の関連付けについても、ＤＢ統合用メタデータにおいて設定されている。図２に示したＤＢ統合用メタデータは、図３乃至図６のように例えばＸＭＬで記述される。

ＤＢ統合用メタデータには、「タグ付き文書形式のビューの構造定義」（図３参照）、「ビューの構造の各要素と、データベース項目との対応関係」（図４及び図５参照）、及び「データベース項目間の関連付け」（図６参照）の３つの内容が記述されている。この生成ルールに定義されているタグ付き文書があたかも実際に存在するかのように見せるために、このシステムがそのビューに対する問い合わせを受け付けると、その問い合わせ内容を解釈し、ビュー生成ルールに合うように各データベースに対する副問い合わせを発行し、そしてデータベースからの問い合わせ結果を合成して、あたかも実際のタグ付き文書が存在してそれに対して問い合わせが行われたかのような問い合わせ結果を返却する。具体的には、図７に示すように、ＤＢ統合用メタデータを用いてユーザには仮想的なビュー３があたかも存在するかのように意識させ、その仮想的なビュー３に対する問い合わせ１がシステムに入力される。問い合わせ１は、例えばＸＱｕｅｒｙ（http://www.w3.org/XML/Queryを参照のこと）にて記述される。図７の例では、「ＦＭＶ−６０００ＣＬを２個以上発注している注文」を参照する場合を示している。そして、システムでは、ＤＢ統合用メタデータに従って問い合わせ結果５を合成して出力する。

従来、複数のデータベースに分散したデータを利用するアプリケーションを作成する際に、各データベースからデータを取得するコードを記述するのに多量の時間を要していたのが、本公報記載の技術によれば、非常に簡単に、そして迅速に行えるようになり、アプリケーション全体を作成するのに要する時間が短縮される。
特開２００５−２０８７５７号公報

しかし、上記公報開示の技術では、「データベース項目間の関連付け」を値の完全一致を条件としていたために、関連付けしたい各項目の値域又は形式が一致しない場合には関連付けを取ることができず、タグ付き文書形式のデータビューを提供することが出来なかった。例えば、図８に示すように、受注ＤＢの商品テーブルのｉｔｅｍ＿ｃｏｄｅというデータ項目の値が数字６桁のみの形式（例えば「０３４５６４」）で格納されているが、商品ＤＢの取扱商品テーブルのｃｏｄｅというデータ項目の値が数字６桁の先頭にｆｍｖという３文字追加された形式（例えば「ｆｍｖ０３４５６４」）で格納されているとすると、両者は関連付けを取ることができなかった。

また、上記公報開示の技術では、データの構造は仮想化することができるが、データの値域は仮想化できない。すなわち、仮想ビューの上のデータの値は、データベース内のデータの値がそのまま見える。これではアプリケーション開発者が想定しているデータの値域又は形式に合わせたビューを提供することができず、アプリケーション側でビューに合わせる必要が生じ、アプリケーションの開発が不自由になる。

従って、本発明の目的は、問い合わせ型データベース統合を行う際に異なる値域又は形式のデータ項目間を関連付けできるようにするための技術を提供することである。

また、本発明の他の目的は、問い合わせ型データベース統合を行う際にデータベースのデータの値域を仮想化できるようにするための技術を提供することである。

さらに、本発明の他の目的は、問い合わせ型データベース統合を行う際にデータベースのデータ項目間の関連付け又はデータ参照を柔軟に行えるようにするための技術を提供することである。

本発明の第１の態様に係る検索方法では、問い合わせ結果の出力構造を規定する構造データ（例えば実施の形態における仮想ＸＭＬスキーマ情報）、当該構造データ中の要素とデータベースの要素との対応関係、データベース間の要素の関連付け、及びデータベース間の要素の関連付け又はデータベースの特定の要素に適用する双方向変換関数が規定された統合用メタデータを新たに採用する。このような双方向変換関数によって値域又は形式が異なるデータ項目間を関連付けることが可能となる。さらに、データベースの値域を仮想化することも可能である。

なお、双方向変換関数は、変換の対称性を有する関数である。すなわち、最初にその双方向変換関数を用いて片方向に変換した値を、次に同じ双方向変換関数で逆方向に変換すると、元の値に完全に戻るものである。

そして、本発明の第１の態様に係る検索方法は、複数のデータベースに対する統合的なデータ参照の問い合わせを受け付けるステップと、統合用メタデータ格納部における統合用メタデータから特定される構造体を問い合わせに基づき上方に探索して、構造体中の最上位要素に対応するデータベースの要素の値を抽出する上方探索ステップと、上記構造体を構造体中の最上位要素に対応するデータベースの要素の値に基づき下方に探索して、各データベースの各要素の値を抽出する下方探索ステップと、抽出された各データベースの各要素の値を、統合用メタデータ格納部に格納されているデータに従って出力するステップとを含む。

また、上で述べた上方探索ステップは、上方探索経路上該当するデータベースに、問い合わせの条件と直前の処理結果との少なくともいずれかに基づく個別問い合わせを出力し、検索の処理結果を取得する上方検索ステップと、上方探索経路上該当する双方向変換関数を、問い合わせの条件と直前の処理結果との少なくともいずれかに対して上向きに適用し、変換の処理結果を取得するステップとを含む。また、上で述べた下方探索ステップは、下方探索経路上該当するデータベースに、上位の処理結果に基づく個別問い合わせを出力し、検索の処理結果を取得する下方検索ステップと、下方探索経路上該当する双方向変換関数を、上位の処理結果に対して下向きに適用し、変換の処理結果を取得するステップとを含む。

このように、データベースに対する個別問い合わせと双方向変換関数の適切な向きの適用とを、統合用メタデータから特定される構造体の上方探索処理及び下方探索処理において適宜実施することによって、ユーザは、問い合わせに対する問い合わせ結果を、複数のデータベースを意識することなく得ることができるようになる。

また、上で述べた統合用メタデータにおいて、双方向変換関数が、データベースの要素と同列の要素として規定される場合もある。そして、データベース間の要素の関連付けが、第１のデータベースの要素と双方向変換関数の下向き要素との関連付けと、第２のデータベースの要素と双方向変換関数の上向き要素との関連付けとを含むようにしてもよい。双方向変換関数もデータベースの要素と同様に、統合用メタデータから特定される構造体（例えば木構造）におけるノードに相当し、データベースの要素を双方向で関連付けている。

さらに、上で述べた統合用メタデータにおいて、双方向変換関数が、データベースの要素と同列の要素として規定される場合もある。そして、データベースの特定の要素の値を変換する双方向変換関数の場合には、データベース間の要素の関連付けが、データベースの特定の要素と当該双方向変換関数の要素との関連付けを含むようにしてもよい。データベースのデータの値域を仮想化するような場合にはこのような構成を採用することによって実現される。

また、上で述べた統合用メタデータにおいて、上記構造データにおける、双方向変換関数に対応する要素に、データ参照の問い合わせにおける使用の可否に関する属性が含まれるようにしてもよい。ユーザに対する仮想的なビューを崩すこと無く、必要な構造を構造データ上規定できるようになる。

さらに、上で述べた統合用メタデータにおいて、双方向変換関数が、データベースの要素と同列の要素として規定される場合もある。そして、データベース間の要素の関連付けが、第１のデータベースのｍ個の要素と双方向変換関数のｍ個の下向き要素との関連付けと、第２のデータベースのｎ個の要素と双方向変換関数のｎ個の上向き要素との関連付けとを含むようにしてもよい。このようにすれば、双方向変換関数の変換方式を柔軟に決定することができる。

また、上で述べた統合用メタデータにおいて、双方向変換関数が、データベースの要素と同列の要素として規定される場合もある。そして、データベースの特定の要素に適用される双方向変換関数の場合には、データベース間の要素の関連付けが、データベースのｍ個の特定の要素と当該双方向変換関数のｍ個の要素との関連付けを含むようにしてもよい。データベースのデータの値域を仮想化する場合にも、柔軟な仮想化が可能となる。

また、上で述べた双方向変換関数として、関連付けされたデータベースの要素の値を制限する関数が規定されている場合、関連付けされたデータベースへの個別問い合わせが、双方向変換関数によって制限される値に関する条件を含むようにしてもよい。例えば、下位のデータベースの特定のデータ項目が特定の値でなければ上方探索時に変換を行わないような双方向変換関数が規定されている場合には、特定のデータ項目が特定の値のデータでなければ、双方向変換関数に対応する要素を上方に通過できない。すなわちデータが制限される。このような双方向変換関数の性質を考慮しない場合には、無駄な探索が行われることになるため、上で述べたような個別問い合わせとなるように変形することによって、データベースから返されるデータの量を少なくし、データ転送の負荷や、返されたデータを処理する負荷を軽減することが可能となる。

本発明の第１の態様は双方向変換関数を定義できる場合には有効に機能するが、必ず双方向変換関数が定義できるわけではない。例えば２つのデータベースに格納されているデータを商品コードで関連付けようとする場合、片方がアルファベット大文字小文字の混合形式で登録されていて（例えば”ＳｙｍｆｏＷＡＲＥ”）、もう片方がアルファベット大文字のみの形式で登録されていると（例えば”ＳＹＭＦＯＷＡＲＥ”）、前者から後者への変換は一意に定義可能であるが、その逆は定義できず、両者を関連付けることはできない。しかし、このような関連付けを行うことが有用な場合もある。従って、本発明の第２の態様においては、双方向変換関数も片方向変換関数も両方取り扱えるようにする。

但し、片方向変換関数が存在する場合には、統合用メタデータから特定される構造体を単純に上方探索及び下方探索できるわけではない。従って、以下のような処理を実施する必要がある。なお、統合用メタデータには、問い合わせ結果の出力構造を規定する構造データ、当該構造データ中の要素とデータベースの要素との対応関係、データベース間の要素の関連付け、及びデータベース間の要素の関連付け又はデータベースの特定の要素に適用する片方向又は双方向の変換関数が規定されている。

本発明の第２の態様に係る検索方法は、複数のデータベースに対する統合的なデータ参照の問い合わせを受け付けるステップと、上記統合用メタデータを格納する統合用メタデータ格納部における統合用メタデータから特定される構造体において片方向の変換関数に対応する要素及び当該要素より下位の要素に係る条件である下方探索条件を上記問い合わせの条件から除外した条件又は上記問い合わせの条件が下方探索条件のみの場合には上記構造体において片方向の変換関数に対応する要素の直上の要素について全件値を抽出するための条件である上方探索条件を特定するステップと、統合用メタデータから特定される構造体を上方検索条件に基づき上方に探索して、上記構造体中の最上位要素に対応するデータベースの要素の値を抽出する上方探索ステップと、上記構造体を上記構造体中の最上位要素に対応するデータベースの要素の値及び下方探索条件に基づき下方に探索して、各データベースの各要素の値を抽出する下方探索ステップと、抽出された各データベースの各要素の値を、統合用メタデータ格納部に格納されているデータに従って出力するステップとを含む。

そして、上方探索ステップが、上方探索経路上該当するデータベースに、上方探索条件と直前の処理結果との少なくともいずれかに基づく個別問い合わせを出力し、検索の処理結果を取得するステップと、上方探索経路上該当する双方向の変換関数を、上方探索条件又は直前の処理結果に対して上向きに適用し、変換の処理結果を取得するステップとを含む。さらに、下方探索ステップが、下方探索経路上該当するデータベースに、上位の処理結果と下方探索条件との少なくともいずれかに基づく個別問い合わせを出力し、検索の処理結果を取得するステップと、下方探索経路上該当する片方向又は双方向の変換関数を、上位の処理結果に対して下向きに適用し、変換の処理結果を取得するステップとを含む。

構造体において片方向の変換関数が規定されている場合当該片方向の変換関数より下位から上方に探索することはできないため、上方探索条件と下方探索条件とに分けて適用するものである。

なお、統合用メタデータにおける規定の仕方については、双方向変換関数も片方向変換関数もほぼ同じである。

なお、本方法をコンピュータに実行させるためのプログラムを作成することができ、このプログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークなどを介してデジタル信号として配信される場合もある。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。

本発明によれば、問い合わせ型データベース統合を行う際に異なる値域又は形式のデータ項目間を関連付けできるようになる。

また、本発明の他の側面によれば、問い合わせ型データベース統合を行う際にデータベースのデータの値域を仮想化できるようになる。

さらに、本発明の他の側面によれば、問い合わせ型データベース統合を行う際にデータベースのデータ項目間の関連付け又はデータ参照を柔軟に行えるようになる。

［実施の形態１］
図９に、本発明の第１の実施の形態に係るシステム概要を示す。ユーザ端末１１は、図示しないネットワークなどを介してデータベース統合参照システム１３に接続されている。なお、ユーザ端末１１ではなくデータベース統合参照システム１３を利用する他のコンピュータであってもよい。また、データベース統合参照システム１３は、図示しないネットワークを介して統合対象のデータベースを管理するホストＡ乃至Ｃなどに接続されている。図９の例では、ホストＡはＲＤＢのＤＢ１を管理しており、ホストＢはＲＤＢのＤＢ２を管理しており、ＤＢ３はＸＭＬ−ＤＢのＤＢ３を管理している。なお、ＲＤＢのみを統合対象データベースとしてもよいし、ＸＭＬ−ＤＢをも含めて統合対象データベースとしてもよい。

データベース統合参照システム１３は、ＸＱｕｅｒｙ問い合わせ処理部１３１と、グリッドツール１３２と、ＤＢ統合用メタデータ格納部１３３とを含む。ＸＱｕｅｒｙ問い合わせ処理部１３１は、問い合わせパーザ部１３１１と、問い合わせ処理エンジン部１３１２と、データベースアクセス処理部１３１３とを含む。

ＤＢ統合用メタデータ格納部１３３に格納されているＤＢ統合用メタデータは、ビュー生成のためのルールである。これは問い合わせ実行に先立って、予め作成してＤＢ統合用メタデータ格納部１３３に格納しておく。ＤＢ統合用メタデータは、データベースの統合の仕方や見せたいビューの構造に応じて複数用意することができる。また、本実施の形態ではＤＢ統合用メタデータの記述には、ＸＭＬを採用している。但し、ＳＧＭＬなど他の言語を採用するようにしても良い。

ＸＱｕｅｒｙ問い合わせ処理部１３１の問い合わせパーザ部１３１１は、例えばＷ３Ｃで標準化作業を行っている問い合わせ言語であるＸＱｕｅｒｙによる問い合わせを受け付け、構文解析を行い、構文チェックを行った後に、問題がなければ問い合わせを内部形式（構文木）に変換する。ここでは、ＸＱｕｅｒｙを用いるとしているが、ＸＰａｔｈ（http://www.w3.org/TR/xpath参照のこと）を採用するようにしても良い。ユーザは、ユーザ端末１１から、統合された仮想データビューにアクセスするため、ＸＱｕｅｒｙを用いた、仮想ＸＭＬデータに対する問い合わせをデータベース統合参照システム１３に出力する。

問い合わせ処理エンジン部１３１２は、問い合わせパーザ部１３１１が構文解析したＸＱｕｅｒｙ問い合わせを実際に処理し、各データベースへどのような順番でどのような問い合わせを行ってデータを獲得するか判断し、各データベースに対する個別の問い合わせ（副問い合わせとも呼ぶ）を実施する。また、問い合わせに応答して各データベースから獲得したデータを、最終的にユーザ端末１１に返信するために、ＸＭＬデータへと組み立てる処理も行う。

データベースアクセス処理部１３１３は、問い合わせ処理エンジン部１３１２からデータベースへの問い合わせ要求が行われると、グリッドツール１３２を介してデータベースへアクセスを実施する。複数の異種のデータベースに対する問い合わせは、従来の技術をそのまま用いることができ、例えば、オープンソースのグリッドミドルウェアであるGlobus Toolkit 4 + OGSA-DAI WSRF 2.1の組み合わせを利用することができる。結果として、データベースアクセス処理部１３１３は、ＲＤＢに対してＳＱＬに従った問い合わせを出力し、ＸＭＬ−ＤＢに対しては例えばＸＰａｔｈに従った問い合わせを出力する。

また、図１における商品ＤＢの取扱商品テーブルが図１０における商品ＤＢの取扱商品テーブルに置き換えられた場合に作成される統合用メタデータは、図１１のように模式的に表すことができる。基本的な構造は図２と同じであるが、双方向変換関数としてフィルタ１が追加されている。すなわち、ｆｉｌｔｅｒという名前のノードと、ｕｐｐｅｒ０というラベルの子ノードと、ｌｏｗｅｒ０というラベルの子ノードとが追加されている。そして、ｕｐｐｅｒ０というラベルのノードは、受注ＤＢの商品テーブルにおけるｃｏｄｅという名前のノードと関連付けがなされており、ｌｏｗｅｒ０とラベルのノードは、商品ＤＢの取扱商品テーブルにおけるｃｏｄｅという名前のノードとが関連付けられている。図１１に示されたデータは、具体的には図１２乃至図１５に示すようなＸＭＬデータとして記述される。

このＤＢ統合用メタデータには、３つのデータ部分を含む。
（１）仮想ＸＭＬスキーマ情報（図１２）
複数のデータベースに跨る関連データを、どのような構造のＸＭＬデータとしてユーザに見せるかという情報である。
（２）データベース項目との対応関係（図１３及び図１４）
ＸＭＬの中の各ノードに、どのデータベースのどの項目が対応するのかという情報である。
（３）要素間の関連付け情報（図１５）
異なるデータベースのＸＭＬデータやタプルを関連付けて１つのエレメントとする場合に、各データベースのどの項目で対応付けするのかという情報である。

以下、それぞれについて詳細を説明する。
（１）仮想ＸＭＬスキーマ情報（図１２）
仮想ＸＭＬスキーマ情報では、ＸＭＬ Ｓｃｈｅｍａに似たフォーマットを使用して、統合データビューのＸＭＬ構造を定義する。スキーマを構築するノードには以下の３種類がある。
（１−１）ComplexElement
配下に他のノードを持つ中間ノードである。図１１の例では、ｏｒｄｅｒという名前のノード（四角で囲った番号１）、ｉｔｅｍという名前のノード（四角で囲った番号２及び３）、ｉｔｅｍ＿ｓｔｏｃｋという名前のノード（四角で囲った番号４）、及びｆｉｌｔｅｒという名前のノード（四角で囲った番号５）である。四角で囲った番号はＩＤを示す。
対応するデータベースがＲＤＢの場合は、これと配下のSimpleElementの組み合わせでデータベースの１タプルに対応する。対応するデータベースがＸＭＬ−ＤＢの場合は、配下に他のノードを持つ中間ノードであって、これ自体は値を持たないことを意味する。このノードの配下には３種類いずれのノードも出現し得る。以下の属性を保有する。
名前（ｎａｍｅ）：仮想データビュー上での、このノードのタグ名。
可視化の可否（ｖｉｓｉｂｌｅ）：仮想データビュー上で表示するか否か。ｔｒｕｅの場合には表示し、ｆａｌｓｅの場合には表示しない。表示しない場合には、問い合わせにも含ませることはできない。
最大出現数：このノードの反復して出現する回数の上限。
最小出現数：このノードの反復して出現する回数の下限。

（１−２）SimpleElement
配下に値を持つ末端ノード。図１１の例では、受注ＤＢの注文伝票テーブルに含まれるｏｒｄｅｒ＿ｉｄという名前のノード、ｐｕｒｃｈａｓｅｒという名前のノード及びｏｒｄｅｒ＿ｄａｔｅという名前のノード、受注ＤＢの商品テーブルに含まれるｏｒｄｅｒ＿ｉｄ２という名前のノード、ｃｏｄｅという名前のノード、及びｑｕａｎｔｉｔｙという名前のノード、フィルタ１に含まれるｕｐｐｅｒ０というラベルのノード及びｌｏｗｅｒ０というラベルのノード、商品ＤＢの取扱商品テーブルに含まれるｃｏｄｅという名前のノード及びｎａｍｅという名前のノード、在庫ＤＢ１の在庫テーブル１に含まれるｉｔｅｍ＿ｃｏｄｅという名前のノード及びｓｔｏｃｋ＿ｑｕａｎｔｉｔｙという名前のノードが該当する。それぞれ丸に含まれる番号がＩＤを示す。

対応するデータベースがＲＤＢの場合は、タプル内の１カラムに対応し、その値だけを保持する。対応するデータベースがＸＭＬ−ＤＢの場合は、値を持つ末端ノードに対応する。このノードは末端ノードなので、この下には他のノードは出現できない。また、以下の属性を保有する。
名前（ｎａｍｅ）：仮想データビュー上での、このノードのタグ名。
可視化の可否（ｖｉｓｉｂｌｅ）：仮想データビュー上で表示するか否か。ComplexElementと同じである。例えば、ｆｉｌｔｅｒという名前のComplexElementと、ｕｐｐｅｒ０というラベルのSimpleElementと、ｌｏｗｅｒ０というラベルのSimpleElementとのｖｉｓｉｂｌｅ属性をｆａｌｓｅに設定すれば、図１６で二重線で消されているようにノードは、ユーザから見えなくなる。同様に、問い合わせでも指定できなくなる。
スキーマレス指定：該当するデータベースがＸＭＬ−ＤＢの場合に、このノードの配下に出現する全てのタグを単なる文字列として扱うことによって、配下に自由なスキーマの出現を許すか否か。

（１−３）TagElement
タグを挿入するためのダミーのノード。図１１では、ｉｔｅｍｓという名前のノードが該当する。対応するデータベース要素を持たない。このノードの配下には３種類いずれのノードも出現し得る。また、以下の属性を保有する。
名前（ｎａｍｅ）：仮想データビュー上での、このノードのタグ名。

また、ComplexElementとTagElementには、そのノードに対応するデータベース項目との対応関係を取るために、固有のＩＤが与えられる。それぞれをComplexElement-ID、SimpleElement-IDと呼ばれる。

対応するデータベースがＲＤＢの場合は、１つのComplexElementと１つ以上のSimpleElementの組でＲＤＢの１タプルに対応し、その組み合わせ同士を相互に連結して木構造を組み立てる。連結する際には、双方の間で関連付け（値のマッチング）を取ることができる項目が必要である。それらとは無関係に、ダミーのタグを加えたい場所にTagElementを挿入することができる。

対応するデータベースがＸＭＬ−ＤＢの場合は、ＸＭＬ−ＤＢに格納されているＸＭＬデータのスキーマに合わせて仮想ＸＭＬスキーマを構築する必要がある。元のＸＭＬデータのスキーマに存在しないタグを加えたい場合はTagElementを使用し、元のＸＭＬデータのスキーマに存在するタグを削りたいときは、そのタグの「可視化の可否」という属性をＦａｌｓｅに設定することで対応することができる。

（２）データベース項目との対応関係（図１３及び図１４）
データベース項目との対応関係では、仮想ＸＭＬスキーマ内の各要素（ComplexElement, SimpleElement）に、実際はどのデータベースのどの項目が対応するのかを記述する。対応するデータベースがＲＤＢかＸＭＬ−ＤＢかによって、記述する内容は大きく異なる。

対応するデータベースがＲＤＢの場合は、それぞれのComplexElementがどのＲＤＢのどのテーブルに対応するかを記述し、そのComplexElementの配下の各SimpleElementがそれぞれそのテーブルの中のどのカラムに対応するのかを記述する。図１３及び図１４の例では、受注ＤＢ（ＩＤ＝０）の注文伝票テーブル（ＩＤ＝０）についてのデータと、受注ＤＢの商品テーブル（ＩＤ＝１）についてのデータと、商品ＤＢ（ＩＤ＝１）の取扱商品テーブル（ＩＤ＝０）についてのデータと、在庫ＤＢ１（ＩＤ＝２）の在庫テーブル１（ＩＤ＝０）についてのデータと、在庫ＤＢ２（ＩＤ＝３）の在庫テーブル２（ＩＤ＝０）についてのデータとを含む。在庫ＤＢ１の在庫テーブル１と在庫ＤＢ２の在庫テーブル２では、同じSimpleElementを使用していることもこの部分で記述される。

また、対応するデータベースがＸＭＬ−ＤＢの場合は、どのCompelxElementからなる部分木がどのＸＭＬ−ＤＢのデータに対応するかを記述する。さらには、ビュー上のタグ名とＸＭＬ−ＤＢ上のタグ名が異なる場合は、その対応を記述する（記述が無かったCompelxElement, SimpleElementについては、ビュー上のタグ名とＸＭＬ−ＤＢ上のタグ名が同じであるとみなす）。

本実施の形態では、双方向フィルタ（双方向変換関数）もデータベースと同列に取り扱われ、仮想ＸＭＬスキーマ内の要素（ComplexElement, SimpleElement）と双方向フィルタとの対応付けも記述される。ＲＤＢの場合と同様に、１つのComplexElementが双方向フィルタと対応することが記述され、以下の情報も記述される。
呼び出すべき双方向フィルタの名前（図１４の例ではcodeConverter）
上位側の入出力に用いられるSimpleElementの一覧（図１４の例ではＩＤ＝１２のSimpleElement）
下位側の入出力に用いられるSimpleElementの一覧（図１４の例ではＩＤ＝１３のSimpleElement）

（３）要素間の関連付け情報（図１５）
要素間の関連付け情報では、ＲＤＢに対応する「ComplexElement, SimpleElementの組み合わせ」同士や、それとＸＭＬ−ＤＢに対応するＸＭＬ部分木を結びつけるための情報を記述する。具体的には、どのSimpleElementとどのSimpleElementで値のマッチングを取るかを記述する。基本は１つの項目と１つの項目同士の「値の完全一致」であるが、複数個同士の「値の完全一致」でも構わない。

図１５の例では、受注ＤＢの注文伝票テーブルと商品テーブルの関連付け、受注ＤＢとフィルタ１の関連付け、フィルタ１と商品ＤＢの関連付け、受注ＤＢと在庫ＤＢ１及び在庫ＤＢ２の関連付けとが規定されている。フィルタ１は、受注ＤＢと商品ＤＢをブリッジするように関連付けている。

本実施の形態において導入された双方向フィルタは、図１１乃至図１５で示した例のように、データベース間の要素の関連付けに基本的には用いられる。図１１の例では、値が完全一致しないため、受注ＤＢの商品テーブルのｃｏｄｅという名前のノードと商品ＤＢの取扱商品テーブルのｃｏｄｅという名前のノードとを直接関連付けられないので双方向フィルタを導入しているが、データベースにおけるデータの値域又は形式の仮想化にも使用することができる。すなわち、図１７に示すように、あるデータベースの要素と、他のデータベースの要素とを連結するためにフィルタを導入するのではなく、あるデータベースの要素の配下にのみ双方向フィルタを導入する。例えば、ＲＤＢのｏｆｆｉｃｅテーブルにはハイフンなしの電話番号（例えば「０３１２３４５６７８」）が格納されているが、双方向フィルタによって、ハイフン付きの電話番号（「例えば「０３−１２３４−５６７８」）をデータビューとして見せることができるようになる。電話番号のｖｉｓｉｂｌｅ属性をｆａｌｓｅにすれば、ユーザにはハイフン付きの電話番号のみが見えるようになる。また、問い合わせの条件でハイフン付きの電話番号が指定された場合には、双方向フィルタでハイフンを除去する処理を行って、ＲＤＢのｏｆｆｉｃｅテーブルをハイフンなしの電話番号で検索する。このような場合には、実際の統合用メタデータでは、データベース間をブリッジすることなく、データベースとフィルタとの関連付けのみとなる。

また、双方向フィルタの具体例は、以下のようなものである。但し、これに限定するものではない。双方向フィルタは、変換の対称性さえあれば、どのようなフィルタ関数でもよい。

（１）データ変換を行う双方向フィルタ
１対１又は複数対複数でデータ値の変換を行う。以下のような例が考えられる。
（ａ）大文字と小文字を双方向に変換
（ｂ）全角と半角を双方向に変換
（ｃ）ハイフン付き電話番号とハイフン無し電話番号を双方向に変換（例えば図１７）
（ｄ）日本人名のふりがなとローマ字表記を双方向に変換
（ｅ）固有名詞をその別名に双方向に変換

（２）データ結合又は分解を行う双方向フィルタ
ｍ対ｎの入出力を有する双方向フィルタを用いると、データの結合又は分解を行うことができる。具体的には、以下のような例が考えられる。
・日付データが「年」「月」「日」に分かれてデータベースに格納されている場合に、それらを１つに結合してハイフン結合された日付データに変換する。
・住所データが「都道府県名」「区・市/町・村（郡）」「町名・丁目・番地」「ビル＊・マンション名」に分かれてデータベースに格納されている場合に、それらを１つに結合して１つの文字列データに変換する。但し、この変換は結合する方向は簡単であるが、逆向きの分解する方には工夫を要する。都道府県名の一覧やそれらの中の市町村名の一覧などのデータを用いて、分解する。
・図１８に示すように、ＲＤＢのｏｆｆｉｃｅテーブルにおいて電話番号の市外局番、市内局番１、市内局番２に分けて格納している場合、双方向フィルタによって、ハイフン結合された電話番号に変換する。また、ハイフン結合された電話番号を、市外局番、市内局番１、市内局番２に分割するように変換する。

（３）データ制限又は選択を行う双方向フィルタ
ｍ対ｎの入出力を有する双方向フィルタで、片方の入出力の１つ以上が定数になっているものを用いると、そのフィルタを流れるデータを制限（又は選択）することができる。このタイプの双方向フィルタを用いると、データベースに入っているデータの内の特定のデータのみを仮想データビューに取り込むことが可能となる。このタイプの双方向フィルタについては後に詳述する。

なお、双方向フィルタの変換処理についての定義データは、ＤＢ統合用メタデータ格納部１３３に格納される。

次に、図９に示したシステムの処理フローについて図１９乃至図３２を用いて説明する。まず、ＸＱｕｅｒｙ問い合わせ処理部１３１の問い合わせパーザ部１３１１は、ユーザ端末１１からＸＱｕｅｒｙの問い合わせの入力を待ち受け（ステップＳ１）、ＸＱｕｅｒｙの入力があった場合には、受信したＸＱｕｅｒｙの問い合わせに対して、構文解析、構文チェック及び内部形式変換を実施する（ステップＳ３）。この処理は従来と同じであり、詳細な説明は省略する。

なお、ＸＱｕｅｒｙの問い合わせの構文が正しくない場合（ステップＳ５：Ｎｏルート）、ＸＱｕｅｒｙ問い合わせ処理部１３１は、エラー・メッセージをユーザ端末１１に出力する（ステップＳ７）。そしてステップＳ１に戻る。一方、ＸＱｕｅｒｙの問い合わせの構文が正しい場合には（ステップＳ５：Ｙｅｓルート）、問い合わせパーザ部１３１１は、構文木のデータを問い合わせ処理エンジン部１３１２に出力する。そして、問い合わせ処理エンジン部１３１２は、該当ＤＢ統合用メタデータをＤＢ統合用メタデータ格納部１３３から読み込み、ＸＭＬ構造及び各ノードに対応するデータが格納されているデータベースを特定する（ステップＳ９）。

例えば、ｎａｍｅ＝ＦＭＶ−６０００ＣＬ且つ数量（ｑｕａｎｔｉｔｙ）が２以上の注文を抽出するＸＱｕｅｒｙの問い合わせは、図２０の右上のように記述される。ここで、該当ＤＢ統合用メタデータは、ｏｒｄｅｒ−ｌｉｓｔ．ｘｍｌとして指定される。そうすると、図２０に示すようなデータ構造が特定されるものとする。基本的に図１１と同じである。

次に、問い合わせ処理エンジン部１３１２は、ＡＮＤ結合された条件式を同時に問い合わせできる条件群にまとめる（ステップＳ１１）。例えば、同じテーブルやデータベースに含まれるデータ項目についての条件群をひとまとめにする。図２０の右上の例における２つの条件式は、異なるデータベースについての条件式なので、別々に取り扱われる。

その後、問い合わせ処理エンジン部１３１２は、最もデータが絞り込める可能性が高い条件式群を特定する（ステップＳ１３）。数値よりは文字列、文字列もより長い文字列を優先する。図２１に示すように、ｑｕａｎｔｉｔｙについての「２」より、ｎａｍｅについての「ＦＭＶ−６０００ＣＬ」の方が絞り込める可能性が高い条件として特定される。

そして、問い合わせ処理エンジン部１３１２は、ＤＢ統合用メタデータから特定されるデータ構造においてステップＳ１３で特定された条件群に対応するエレメントが双方向フィルタか判断する（ステップＳ１５）。例えば図１７のように、データベースのデータの値域又は形式を仮想化している場合もあるため、条件式群に対応するエレメントが最初から双方向フィルタである場合もある。ステップＳ１３で特定された条件群に対応するエレメントが双方向フィルタである場合には、条件として指定されている値に対して、双方向フィルタの上向きの変換を適用する（ステップＳ２１）。図１７の例のような場合には、「０３−１２３４−５６７８」が条件の値として指定されており、双方向フィルタの上向きの変換によって「０３１２３４５６７８」が得られる。そして処理は端子Ａを介して図２３の処理に移行する。

一方、ステップＳ１３で特定された条件式群に対応するエレメントが双方向フィルタでない場合には、問い合わせ処理エンジン部１３１２は、特定された条件式群の各条件を利用して、最初のデータベースに問い合わせをするための問い合わせ文を生成して、データベースアクセス処理部１３１３に出力する（ステップＳ１７）。例えば、図２２の右上（Ａ）に示すような商品ＤＢに対するＳＱＬ問い合わせを生成する。なお、基本的には、条件式群に合致するレコードを特定するが、値を求めるのは、上位のエレメントと関連づけられているカラムの値のみでよい。図２２に示すように、商品ＤＢの取扱商品テーブルにおけるｎａｍｅカラムに対してＦＭＶ−６０００ＣＬという条件で検索する場合、商品ＤＢの取扱商品テーブルにおけるｃｏｄｅカラムのみが上位のエレメントに関連付けられているので、ｃｏｄｅカラムの値を特定すればよい。

そして、データベースアクセス処理部１３１３は、グリッドツール１３２を介して最初のデータベース（商品ＤＢの取扱商品テーブル）を管理するホストに問い合わせ文を出力し、問い合わせ結果を取得する（ステップＳ１９）。図２２の右上（Ｂ）に示すように、ｃｏｄｅカラムの値（ｆｍｖ０３４５６４）が得られる。データベースアクセス処理部１３１３は、問い合わせ結果を問い合わせ処理エンジン部１３１２に出力する。処理は、端子Ａを介して図２３の処理に移行する。

図２３の処理の説明に移行して、問い合わせ処理エンジン部１３１２は、最上位のエレメントに到達したか判断する（ステップＳ２３）。最上位のエレメントに到達した場合にはステップＳ３５に移行する。一方、最上位のエレメントに到達したわけではない場合には、問い合わせ処理エンジン部１３１２は、ＸＭＬ木構造上１つ上位のエレメントがフィルタであるか判断する（ステップＳ２５）。ＸＭＬ木構造上１つ上位のエレメントがフィルタである場合には、問い合わせ処理エンジン部１３１２は、直前の問い合わせ結果又はフィルタの適用結果に対して、フィルタの上向きの変換を適用する（ステップＳ２７）。

図２４に示されているように、商品ＤＢの取扱商品テーブルのｃｏｄｅカラムの値がｆｍｖ０３４５６４であるから、ｌｏｗｅｒ０＝”ｆｍｖ０３４５６４”として双方向フィルタに入力され、図２４の右上（Ａ）に示すように双方向フィルタの上向きの変換ｆｉｌｔｅｒ１．ｕｐ（”ｆｍｖ０３４５６４”）を実施し、右上（Ｂ）に示すように（ｕｐｐｅｒ０）＝（（０３４５６４））を得る。すなわち、さらに上位の受注ＤＢの商品テーブルにおけるｉｔｅｍ＿ｃｏｄｅカラムの値が得られる。その後、問い合わせ処理エンジン部１３１２は、最上位のエレメントに到達したか判断する（ステップＳ３３）。最上位のエレメントに到達していない場合にはステップＳ２５に戻る。

一方、ＸＭＬ木構造上１つ上位のエレメントがフィルタではない場合には、問い合わせ処理エンジン部１３１２は、直前の問い合わせ結果又はフィルタの適用結果、並びに存在する場合には未使用の条件式群を用いて、上位のデータベースに対する問い合わせ文を生成し、データベースアクセス処理部１３１３に出力する（ステップＳ２９）。図２５に示すように、直前のフィルタの適用結果である受注ＤＢの商品テーブルにおけるｉｔｅｍ＿ｃｏｄｅカラムの値（０３４５６４）と、未使用の条件式群（ｑｕａｎｔｉｔｙカラムの値が２以上）とを用いて、図２５の右上（Ａ）に示すような受注ＤＢに対するＳＱＬ問い合わせを生成する。なお、受注ＤＢには商品テーブル以外にも注文伝票テーブルが含まれており、商品テーブルと注文伝票テーブルとは関連付けがなされているので、ｏｒｄｅｒ＿ｉｄカラムでテーブルをジョインして検索を行う。このように可能であれば、ジョイン処理を併せて行うように指定して、データベースへの問い合わせの回数を減らす。

そして、データベースアクセス処理部１３１３は、グリッドツール１３２を介してデータベース（受注ＤＢ）を管理するホストに問い合わせ文を出力し、問い合わせ結果を取得する（ステップＳ３１）。図２５の右上（Ｂ）に示すように、受注ＤＢの注文伝票テーブルにおけるｏｒｄｅｒ＿ｉｄカラムの値（１２１）、ｐｕｒｃｈａｓｅｒカラムの値（ＡｓｉａｎＴｒａｄｅｒｓ）及びｏｒｄｅｒ＿ｄａｔｅカラムの値（２００３−０７−２５）が得られる。データベースアクセス処理部１３１３は、問い合わせ結果を問い合わせ処理エンジン部１３１２に出力する。処理は、ステップＳ３３に移行する。

その後、問い合わせ処理エンジン部１３１２は、ＸＭＬ木構造上の最上位のエレメントまで到達したか判断する（ステップＳ３３）。ＸＭＬ木構造上の最上位のエレメントまで到達していない場合には、ステップＳ２５に移行する。このように繰り返し処理を実施してＸＭＬ木構造上の最上位のエレメントの値を取得する。最上位のエレメントの値については、記憶装置に格納しておく。図２５の例では、最上位のエレメントの値が取得できたことになる。上方探索はこれで終了となる。

ステップＳ３３で最上位のエレメントに到達したと判断された場合には、問い合わせ処理エンジン部１３１２は、ＸＭＬ木構造上１つ下位のエレメントがフィルタであるか判断する（ステップＳ３５）。ＸＭＬ木構造上１つ下位のエレメントがフィルタではない場合、問い合わせ処理エンジン部１３１２は、上位の問い合わせ結果又はフィルタの適用結果を用いて、下位のデータベースに対する問い合わせ文を生成し、データベースアクセス処理部１３１３に出力する（ステップＳ３９）。図２６に示すように、直前の問い合わせ結果である受注ＤＢの注文伝票テーブルにおけるｏｒｄｅｒ＿ｉｄカラムの値（１２１）を用いて、図２６の右上（Ａ）に示すような受注ＤＢの商品テーブルに対するＳＱＬ問い合わせを生成する。

そして、データベースアクセス処理部１３１３は、グリッドツール１３２を介して、データベース（受注ＤＢの商品テーブル）を管理するホストに問い合わせ文を出力し、問い合わせ結果を取得する（ステップＳ４１）。図２６の右上（Ｂ）に示すように、受注ＤＢの商品テーブルにおけるｏｒｄｅｒ＿ｉｄカラムの値（１２１，１２１）、ｉｔｅｍ＿ｃｏｄｅカラムの値（０３４５６４，０８７２４５）及びｑｕａｎｔｉｔｙカラムの値（２，５）が得られる。データベースアクセス処理部１３１３は、取得した問い合わせ結果を問い合わせ処理エンジン部１３１２に出力する。そして、問い合わせ処理エンジン部１３１２は、最下位のエレメントに到達したか判断する（ステップＳ４３）。最下位のエレメントに到達していなければ、ステップＳ３５に戻る。一方、最下位のエレメントに到達した場合には、端子Ｂを介して図３１の処理に移行する。

ＸＭＬ木構造上１つ下位のエレメントがフィルタである場合には、問い合わせ処理エンジン部１３１２は、上位の問い合わせ結果又はフィルタの適用結果に対して、双方向フィルタの下向きの変換を実施する（ステップＳ３７）。図２７に示したように、受注ＤＢの商品テーブルにおけるｉｔｅｍ＿ｃｏｄｅカラムには、フィルタ１が関連付けられているので、上位の問い合わせ結果であるｉｔｅｍ＿ｃｏｄｅカラムの値（０３４５６４，０８７２４５）を入力として下向きに変換を実施する。すなわち、図２７の右上（Ａ）に示したように、双方向フィルタの下向きの変換ｆｉｌｔｅｒ１．ｄｏｗｎ（”０３４５６４”）及びｆｉｌｔｅｒ．ｄｏｗｎ（”０８７２４５”）を実施し、右上（Ｂ）に示すように（ｌｏｗｅｒ０）＝（（ｆｍｖ０３４５６４），（ｆｍｖ０８７４２５））を得る。すなわち、さらに下位の商品ＤＢの取扱商品テーブルにおけるｃｏｄｅカラムの値が得られる。その後、ステップＳ４３に移行する。

図２７の例ではまだ最下位のエレメントに到達していないので、ステップＳ３５に戻って、ＸＭＬ木構造上１つ下位のエレメントがフィルタであるか判断し、フィルタでないのでステップＳ３９に移行する。そして、上位の問い合わせ結果又はフィルタの適用結果を用いて、下位のデータベースに対する問い合わせ文を生成し、データベースアクセス処理部１３１３に出力する。図２８に示すように、フィルタの適用結果である商品ＤＢの取扱商品テーブルのｃｏｄｅカラムの値（ｆｍｖ０３４５６４，ｆｍｖ０８７２４５）を用いて、図２８の右上（Ａ）に示すような商品ＤＢの取扱商品テーブルに対するＳＱＬ問い合わせを生成する。２つの値があるので、条件はＯＲで結合される。

そして、データベースアクセス処理部１３１３は、グリッドツール１３２を介して、データベース（商品ＤＢの取扱商品テーブル）を管理するホストに問い合わせ文を出力し、問い合わせ結果を取得する。図２８の右上（Ｂ）に示すように、商品ＤＢの取扱商品テーブルにおけるｎａｍｅカラムの値（ＦＭＶ−６０００ＣＬ，ＦＭＶ−６６６７ＣＸ５）が得られる。データベースアクセス処理部１３１３は、取得した問い合わせ結果を問い合わせ処理エンジン部１３１２に出力する。

そして、問い合わせ処理エンジン部１３１２は、最下位のエレメントに到達したか再度判断する。受注ＤＢの商品テーブルにおけるｉｔｅｍ＿ｃｏｄｅカラムは、在庫ＤＢ１及び在庫ＤＢ２におけるカラムについても関連付けされているため、最下位のエレメントには到達していないと判断される。そしてステップＳ３５に戻り、ステップＳ３９に移行する。

そして、問い合わせ処理エンジン部１３１２は、上位の問い合わせ結果を用いて、下位のデータベースに対する問い合わせ文を生成し、データベースアクセス処理部１３１３に出力する。図２９に示すように、受注ＤＢの商品テーブルのｉｔｅｍ＿ｃｏｄｅカラムの値（０３４５６４，０８７２４５）を用いて、図２９の右上（Ａ）に示すような在庫ＤＢ１の在庫テーブル１に対するＳＱＬ問い合わせを生成する。２つの値があるので、条件はＯＲで結合される。

その後、データベースアクセス処理部１３１３は、グリッドツール１３２を介して、データベース（在庫ＤＢ１の在庫テーブル１）を管理するホストに問い合わせ文を出力し、問い合わせ結果を取得する。図２９の右上（Ｂ）に示すように、在庫ＤＢ１の在庫テーブル１におけるｃｏｄｅカラムの値（０３４５６４）及びｑｕａｎｔｉｔｙカラムの値（３８）が得られる。データベースアクセス処理部１３１３は、取得した問い合わせ結果を問い合わせ処理エンジン部１３１２に出力する。

そして、問い合わせ処理エンジン部１３１２は、最下位のエレメントに到達したか再度判断する。在庫ＤＢ２の在庫テーブル２については未処理であるから、最下位のエレメントには到達していないと判断される。そしてステップＳ３５に戻り、ステップＳ３９に移行する。

そして、問い合わせ処理エンジン部１３１２は、上位の問い合わせ結果を用いて、下位のデータベースに対する問い合わせ文を生成し、データベースアクセス処理部１３１３に出力する。図３０に示すように、受注ＤＢの商品テーブルのｉｔｅｍ＿ｃｏｄｅカラムの値（０３４５６４，０８７２４５）を用いて、図３０の右上（Ａ）に示すような在庫ＤＢ２の在庫テーブル２に対するＳＱＬ問い合わせを生成する。２つの値があるので、条件はＯＲで結合される。

その後、データベースアクセス処理部１３１３は、グリッドツール１３２を介して、データベース（在庫ＤＢ２の在庫テーブル２）を管理するホストに問い合わせ文を出力し、問い合わせ結果を取得する。図３０の右上（Ｂ）に示すように、在庫ＤＢ２の在庫テーブル２におけるｉｔｅｍ＿ｃｏｄｅカラムの値（０８７２４５）及びｉｔｅｍ＿ｑｕａｎｔｉｔｙカラムの値（３）が得られる。データベースアクセス処理部１３１３は、取得した問い合わせ結果を問い合わせ処理エンジン部１３１２に出力する。

そして、問い合わせ処理エンジン部１３１２は、最下位のエレメントに到達したか再度判断する。ここで最下位のエレメントに達したと判断し、端子Ｂを介して図３１の処理に移行する。

問い合わせ処理エンジン部１３１２は、ＤＢ統合用メタデータに従って、得られたデータ値から問い合わせ結果のＸＭＬデータを構築する（ステップＳ４５）。例えば図３２に模式的に示したようなＸＭＬデータが構築される。ｖｉｓｉｂｌｅ＝ｔｒｕｅとされるSimpleElementのノードに対応して、得られたデータ値が埋め込まれる。

その後、問い合わせ処理エンジン部１３１２は、問い合わせ結果のチェックを実施する（ステップＳ４７）。まだＸＱｕｅｒｙの問い合わせで指定した問い合わせ条件の一部が反映されていない可能性が残っているので、問い合わせ条件を満たさない解はチェックして最終結果のＸＭＬデータから除外する。最後に、問い合わせ処理エンジン部１３１２は、問い合わせ結果をユーザ端末１１に出力する（ステップＳ４９）。

このような処理を実施することによって、複数のデータベースに跨る関連データを一括して参照することができるようになる。

次に、データ制限又は選択を行う双方向フィルタについて説明する。このような双方向フィルタの一例を図３３に示す。図３３の例では、受注ＤＢの商品テーブルのｉｔｅｍ＿ｃｏｄｅカラムは、フィルタ２のｕｐｐｅｒ０というラベルのノードに関連付けられている。また、商品ＤＢの取扱商品テーブルのｙｅａｒカラムは、フィルタ２のｌｏｗｅｒ０というラベルのノードに関連付けられている。さらに、商品ＤＢの取扱商品テーブルのｃｏｄｅカラムは、フィルタ２のｌｏｗｅｒ１というラベルのノードに関連付けられている。そしてフィルタ２の変換関数は、図３３の右上（Ａ）に示すように、下から上への変換関数についてはｌｏｗｅｒ０の値が２００６であればｕｐｐｅｒ０の値をｌｏｗｅｒ１の値に設定し、ｌｏｗｅｒ０の値が２００６以外であればｕｐｐｅｒ０の値をｎｕｌｌとする。一方、上から下への変換関数については、ｌｏｗｅｒ０には２００６を設定し、ｌｏｗｅｒ１にはｕｐｐｅｒ０の値を設定する。このような場合、商品ＤＢの取扱商品テーブルで得られたデータは、このフィルタ２を通過する際に、ｙｅａｒカラムの値が２００６であるデータだけに制限される。同様に、下から上の変換関数によって、商品ＤＢの取扱商品テーブルのｙｅａｒカラムの値が２００６以外であればｕｐｐｅｒ０の値がｎｕｌｌとなってしまうので、上側に遡ることができない。

そこで、商品ＤＢの取扱商品テーブルへ問い合わせを行う際に、関連付け先が双方向フィルタであるかを予め確認し、もし双方向フィルタでそれがデータ制限又は選択を行うものであった場合は、その制限又は選択の条件を商品ＤＢの取扱商品テーブルへの問い合わせに加える。図３３の右上（Ｂ）に示すように、ｎａｍｅカラムの値をＦＭＶ−６０００ＣＬとする条件に加え、ｙｅａｒカラムの値を制限又は選択の条件「２００６」をＡＮＤで組み合わせる。こうすることによって、データベースから返るデータの量を少なくし、データ転送の負荷や、返って来たデータを処理する負荷を軽減することが可能となる。

このようなデータ制限又は選択を行う双方向フィルタが用いられている場合には、図３４乃至図３７の処理を実施する。まず、ＸＱｕｅｒｙ問い合わせ処理部１３１の問い合わせパーザ部１３１１は、ユーザ端末１１からＸＱｕｅｒｙの問い合わせの入力を待ち受け（ステップＳ５１）、ＸＱｕｅｒｙの入力があった場合には、受信したＸＱｕｅｒｙの問い合わせに対して、構文解析、構文チェック及び内部形式変換を実施する（ステップＳ５３）。

なお、ＸＱｕｅｒｙの問い合わせの構文が正しくない場合（ステップＳ５５：Ｎｏルート）、エラー・メッセージをユーザ端末１１に出力する（ステップＳ５７）。そしてステップＳ５１に戻る。一方、ＸＱｕｅｒｙの問い合わせの構文が正しい場合には（ステップＳ５５：Ｙｅｓルート）、問い合わせパーザ部１３１１は、構文木のデータを問い合わせ処理エンジン部１３１２に出力する。そして、問い合わせ処理エンジン部１３１２は、該当ＤＢ統合用メタデータをＤＢ統合用メタデータ格納部１３３から読み込み、ＸＭＬ構造及び各ノードに対応するデータが格納されているデータベースを特定する（ステップＳ５９）。

次に、問い合わせ処理エンジン部１３１２は、ＡＮＤ結合された条件式を同時に問い合わせできる条件群にまとめる（ステップＳ６１）。例えば、同じテーブルやデータベースに含まれるデータ項目についての条件群をひとまとめにする。

その後、問い合わせ処理エンジン部１３１２は、最もデータが絞り込める可能性が高い条件式群を特定する（ステップＳ６３）。

そして、問い合わせ処理エンジン部１３１２は、ステップＳ６３で特定された条件群に対応するエレメントが双方向フィルタか判断する（ステップＳ６５）。例えば図１７のように、データベースのデータの値域又は形式を仮想化している場合もあるため、条件式群に対応するエレメントが最初から双方向フィルタである場合もある。ステップＳ６３で特定された条件群に対応するエレメントが双方向フィルタである場合には、条件として指定されている値に対して、双方向フィルタの上向きの変換を適用する（ステップＳ６７）。そして処理は端子Ｃを介して図３６の処理に移行する。

一方、ステップＳ６３で特定された条件式群に対応するエレメントが双方向フィルタでない場合には、問い合わせ処理エンジン部１３１２は、第１検索処理を実施する（ステップＳ６９）。そして端子Ｃを介して図３６の処理に移行する。

第１検索処理については図３５を用いて説明する。まず、問い合わせ処理エンジン部１３１２は、ＸＭＬ木構造上で、ステップＳ６３で特定された条件式群に対応するエレメントの１つ上位に位置するのがフィルタであり且つ当該フィルタの関数が値を制限又は選択するタイプか判断する（ステップＳ７１）。このような条件が満たされていない場合には、通常どおり、問い合わせ処理エンジン部１３１２は、特定された条件式群の各条件を利用して、最初のデータベースに問い合わせをするための問い合わせ文を生成して、データベースアクセス処理部１３１３に出力する（ステップＳ７３）。

そして、データベースアクセス処理部１３１３は、グリッドツール１３２を介して最初のデータベースを管理するホストに問い合わせ文を出力し、問い合わせ結果を取得する（ステップＳ７７）。データベースアクセス処理部１３１３は、問い合わせ結果を問い合わせ処理エンジン部１３１２に出力する。そして元の処理に戻る。

一方、ステップＳ７１の条件が満たされた場合には、問い合わせ処理エンジン部１３１２は、ステップＳ６３で特定された条件式群の各条件と、１つ上位に位置するフィルタの関数の制限条件（図３３の例では、ｙｅａｒ＝２００６）とを用いて、最初のデータベースに問い合わせをするための問い合わせ文を生成し、データベースアクセス処理部１３１３に出力する（ステップＳ７５）。図３３の右上（Ｂ）に示すようなＳＱＬ問い合わせを生成する。そしてステップＳ７７に移行する。

図３６の処理の説明に移行して、問い合わせ処理エンジン部１３１２は、最上位のエレメントに到達したか判断する（ステップＳ８１）。最上位のエレメントに到達した場合にはステップＳ９１に移行する。一方、最上位のエレメントに到達したわけではない場合には、問い合わせ処理エンジン部１３１２は、ＸＭＬ木構造上１つ上位のエレメントがフィルタであるか判断する（ステップＳ８３）。ＸＭＬ木構造上１つ上位のエレメントがフィルタである場合には、問い合わせ処理エンジン部１３１２は、直前の問い合わせ結果又はフィルタの適用結果に対して、フィルタの上向きの変換を適用する（ステップＳ８７）。その後、問い合わせ処理エンジン部１３１２は、最上位のエレメントに到達したか判断する（ステップＳ８９）。最上位のエレメントに到達していない場合にはステップＳ８３に戻る。

一方、ＸＭＬ木構造上１つ上位のエレメントがフィルタではない場合には、問い合わせ処理エンジン部１３１２は、第２検索処理を実施する（ステップＳ８５）。その後ステップＳ８９に移行する。

第２検索処理については図３７を用いて説明する。まず、問い合わせ処理エンジン部１３１２は、ＸＭＬ木構造上で、さらに１つ上位に位置するのがフィルタであり且つ当該フィルタの関数が値を制限又は選択するタイプか判断する（ステップＳ１０１）。このような条件が満たされていない場合には、通常どおり、問い合わせ処理エンジン部１３１２は、直前の問い合わせ結果又はフィルタの適用結果と、該当する条件群とを利用して、上位のデータベースに問い合わせをするための問い合わせ文を生成して、データベースアクセス処理部１３１３に出力する（ステップＳ１０３）。

そして、データベースアクセス処理部１３１３は、グリッドツール１３２を介して上位のデータベースを管理するホストに問い合わせ文を出力し、問い合わせ結果を取得する（ステップＳ１０７）。データベースアクセス処理部１３１３は、問い合わせ結果を問い合わせ処理エンジン部１３１２に出力する。そして元の処理に戻る。

一方、ステップＳ１０１の条件が満たされた場合には、問い合わせ処理エンジン部１３１２は、直前の問い合わせ結果又はフィルタの適用結果と、該当する条件群と、１つ上位に位置するフィルタの関数の制限条件とを用いて、上位のデータベースに問い合わせをするための問い合わせ文を生成し、データベースアクセス処理部１３１３に出力する（ステップＳ１０５）。そしてステップＳ１０７に移行する。

このように繰り返し処理を実施してＸＭＬ木構造上の最上位のエレメントの値を取得する。最上位のエレメントの値については、記憶装置に格納しておく。

図３６の処理の説明に戻って、ステップＳ８９で最上位のエレメントに到達したと判断された場合には、問い合わせ処理エンジン部１３１２は、ＸＭＬ木構造上１つ下位のエレメントがフィルタであるか判断する（ステップＳ９１）。ＸＭＬ木構造上１つ下位のエレメントがフィルタではない場合、問い合わせ処理エンジン部１３１２は、上位の問い合わせ結果又はフィルタの適用結果を用いて、下位のデータベースに対する問い合わせ文を生成し、データベースアクセス処理部１３１３に出力する（ステップＳ９３）。

そして、データベースアクセス処理部１３１３は、グリッドツール１３２を介して、データベースを管理するホストに問い合わせ文を出力し、問い合わせ結果を取得する（ステップＳ９５）。データベースアクセス処理部１３１３は、取得した問い合わせ結果を問い合わせ処理エンジン部１３１２に出力する。そして、問い合わせ処理エンジン部１３１２は、最下位のエレメントに到達したか判断する（ステップＳ９９）。最下位のエレメントに到達していなければ、ステップＳ９１に戻る。一方、最下位のエレメントに到達した場合には、端子Ｂを介して図３１の処理に移行する。図３１の処理は同じであるから説明は省略する。

ＸＭＬ木構造上１つ下位のエレメントがフィルタである場合には、問い合わせ処理エンジン部１３１２は、上位の問い合わせ結果又はフィルタの適用結果に対して、双方向フィルタの下向きの変換を実施する（ステップＳ９７）。そしてステップＳ９９に移行する。

このように上方探索の場合には、データの値を制限又は選択するタイプの双方向フィルタを考慮して問い合わせ文を生成するが、下方探索の場合にはＸＭＬ木構造を探索する上で考慮する必要はない。

以上のような処理を実施することによって、双方向フィルタがデータの値を制限又は選択するタイプの双方向フィルタを用いる場合でも適切に対処することができるようになる。

以上本発明の第１の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、図１２乃至図１５に示した例では、フィルタはデータベースの要素と同列に記述されていた。しかし、必ずしもデータベースの要素と同列に記述する必要はない。例えば図３８乃至図４１のようなＤＢ統合用メタデータを用いるようにしてもよい。図１２と図３８とを比較すれば、図３８ではフィルタのノードが削除されている。また、図１３及び図１４と図３９及び図４０とを比較すれば、図３９及び図４０ではフィルタについての記述が削除されている。そして、図１５と図４１を比較すれば、ノードが削除されているので、図４１では、双方向フィルタを導入すべき関連付け部分にフィルタが導入されている。このような記述法を用いても、値域又は形式が異なるデータベースの要素間を関連付けることができる。但し、データの値域又は形式の仮想化には使用することができなくなる。また、複数対複数の関連付けも難しくなる。

さらに、上でも述べたが、図４２に示すようなＸＭＬ−ＤＢ（受注ＤＢの注文伝票ＸＭＬ）が混在するような環境に対しても本発明を適用することができる。ＤＢ統合用メタデータが作成されていれば、ユーザに対して好ましい仮想データビューを提示して、それに応じた問い合わせを処理して複数のデータベースに跨るデータを適切に抽出できる。

また、図９に示した機能ブロック図は一例であって実際のプログラムのモジュール構成とは異なる場合もある。

［実施の形態２］
本発明の第１の実施の形態において導入された双方向フィルタではなく片方向フィルタを導入することも可能である。図１２乃至図１５に、双方向フィルタを導入した際のＤＢ統合用メタデータを例示しているが、片方向フィルタを導入する場合においても、同様の記述を行えばよい。すなわち、片方向フィルタ（片方向変換関数）もデータベースと同列に取り扱われ、仮想ＸＭＬスキーマ内の要素（ComplexElement, SimpleElement）と片方向フィルタとの対応付けも記述される。１つのComplexElementが片方向フィルタと対応することが記述され、以下の情報も記述される。
呼び出すべき片方向フィルタの名前（例えばcodeConverter）
上位側の入出力に用いられるSimpleElementの一覧
下位側の入出力に用いられるSimpleElementの一覧

片方向フィルタを導入する場合でも、双方向フィルタを導入した場合におけるＤＢ統合用メタデータと同様に表されるので、ＤＢ統合用メタデータの模式図も、図１１と同様に表される。但し、双方向フィルタの場合には、関連付けを表す太点線を矢印にしていなかったが、図４３に示すように、片方向フィルタ（図４３の場合にはフィルタ２）の場合には、フィルタの方向を表すために、関連付けを表す太点線を矢印で表すものとする。図４３の例では、片方向フィルタであるフィルタ２のｕｐｐｅｒ０という名前のノードは、上位ノードである、受注ＤＢの商品テーブルにおけるｉｔｅｍ＿ｃｏｄｅという名前のノードと関連付けられており、フィルタ２のｌｏｗｅｒ０という名前のノードは、下位ノードである、商品ＤＢの取扱商品テーブルにおけるｃｏｄｅという名前のノードと関連付けられている。

なお、片方向フィルタであるか双方向フィルタであるかは、ＤＢ統合用メタデータではなくフィルタの実体によって特定される。すなわち、例えば起動時に、システムが、フィルタの定義を読み込み、当該フィルタが、双方向フィルタのクラスを継承しているか、又は片方向フィルタのクラスを継承しているかを特定することによって、判別する。

片方向フィルタは、例えば、以下のような変換関数である。
（ａ）大文字小文字混在の文字列を、大文字に変換する
（ｂ）大文字小文字混在の文字列を、小文字に変換する
（ｃ）全角文字半角文字混在の文字列を、半角文字列に変換する
（ｄ）ハイフン又は括弧で区分された電話番号を、ハイフン又は括弧無しの電話番号に変換する
（ｅ）誕生日を、年齢に変換する
（ｆ）過去の住所表記を、最新の住所表記に変換する
（ｇ）住所を、郵便番号に変換する（例えば図４４）
その他、必要な片方向変換関数であれば、何でも良い。

（ａ）乃至（ｇ）については、１対１の変換であるが、例えばデータベースのｍ個の要素からｎ個の出力を得るようなｍ対ｎ変換も可能である。図４５に一例を示す。図４５の例では、住所が、県名、市名、県名及び市名以外という形で分けてＲＤＢのｏｆｆｉｃｅテーブルに登録されており、片方向フィルタによって郵便番号に変換する。

図４５に示されているように、あるデータベースの要素と、他のデータベースの要素とを関連付けるために片方向フィルタを導入するのではなく、あるデータベースの要素の配下に片方向フィルタを導入するようにしても良い。すなわち、双方向フィルタの場合において説明した値域又は形式の仮想化と同様である。ｖｉｓｉｂｌｅ属性で、ｆａｌｓｅを指定して、データビューで郵便番号のみを見せるようにしても良い。

次に、図４６乃至図６４を用いて、片方向フィルタを導入した場合における処理フローを説明する。以下では、図４６のようなＤＢ統合用メタデータが定義されているものとする。図４６において、ＲＤＢ３のｏｒｄｅｒ＿ｉｔｅｍテーブルのｃｏｄｅという名前のノードと、片方向フィルタのｕｐｐｅｒ０という名前のノードとが関連付けられており、片方向フィルタのｌｏｗｅｒ０という名前のノードとＲＤＢ１のｉｔｅｍテーブルにおけるｃｏｄｅという名前のノードとが関連付けられている。なお、処理フロー自体は、双方向フィルタと片方向フィルタが混在する場合をも想定したものとなっている。

また、図９に示した第１の実施の形態におけるシステム構成は、本実施の形態でも同様である。但し、問い合わせ処理エンジン部１３１２の処理内容は、以下のように変更されている。

まず、ＸＱｕｅｒｙ問い合わせ処理部１３１の問い合わせパーザ部１３１１は、ユーザ端末１１からＸＱｕｅｒｙの問い合わせの入力を待ち受け（図４７：ステップＳ２０１）、ＸＱｕｅｒｙの入力があった場合には、受信したＸＱｕｅｒｙの問い合わせに対して、構文解析、構文チェック及び内部形式変換を実施する（ステップＳ２０３）。この処理は従来と同じであり、詳細な説明は省略する。

なお、ＸＱｕｅｒｙの問い合わせの構文が正しくない場合（ステップＳ２０５：Ｎｏルート）、ＸＱｕｅｒｙ問い合わせ処理部１３１は、エラー・メッセージをユーザ端末１１に出力する（ステップＳ２０７）。そしてステップＳ２０１に戻る。一方、ＸＱｕｅｒｙの問い合わせの構文が正しい場合には（ステップＳ２０５：Ｙｅｓルート）、問い合わせパーザ部１３１１は、構文木のデータを問い合わせ処理エンジン部１３１２に出力する。そして、問い合わせ処理エンジン部１３１２は、該当ＤＢ統合用メタデータをＤＢ統合用メタデータ格納部１３３から読み込み、ＸＭＬ構造及び各ノードに対応するデータが格納されているデータベースを特定する（ステップＳ２０９）。上でも述べたが、システム起動時などに、フィルタの定義を読み込み、当該フィルタが、双方向フィルタのクラスを継承しているか、又は片方向フィルタのクラスを継承しているかを特定しておく。

例えば、ｃｏｄｅ＝ＦＭＶ−６０００ＣＬ且つ数量（ｑｕａｎｔｉｔｙ）が２以上の注文を抽出するＸＱｕｅｒｙの問い合わせは、図４６の右上のように記述される。ここで、該当ＤＢ統合用メタデータは、ｏｒｄｅｒ−ｌｉｓｔ．ｘｍｌとして指定される。そうすると、図４６に示すようなデータ構造が特定されるものとする。

次に、問い合わせ処理エンジン部１３１２は、ＡＮＤ結合された条件式を同時に問い合わせできる条件群にまとめる（ステップＳ２１１）。例えば、同じテーブルやデータベースに含まれるデータ項目についての条件群をひとまとめにする。図４６の右上の例における２つの条件式は、異なるデータベースについての条件式なので、別々に取り扱われる。

その後、問い合わせ処理エンジン部１３１２は、上向き条件式群生成処理を実施する（ステップＳ２１３）。この上向き条件式群生成処理は、ＸＭＬ木構造において片方向フィルタが規定されており、且つ本片方向フィルタ以下の部分に問い合わせの条件式が規定されている場合に対処するために設けられている。片方向フィルタが存在していると、木構造の上向き探索を単純には行うことができないためである。上向き条件式群生成処理については、図４８を用いて説明する。

まず、問い合わせ処理エンジン部１３１２は、問い合わせの各条件式について、当該条件式に対応する、ＤＢ統合用メタデータの木構造上のエレメント又は当該エレメントより上位のエレメントに片方向フィルタが定義されているか確認する（ステップＳ３０１）。条件式毎に上記条件に該当するか否かを確認し、例えば、問い合わせの構文木のデータに、該当するか否かを表すフラグのデータを追加する。

そして、問い合わせ処理エンジン部１３１２は、片方向フィルタに関係する（すなわち、上記条件に該当する）条件式が１つでも存在するか判断する（ステップＳ３０３）。片方向フィルタに関係する条件式が存在しない場合（すなわち、フィルタが１つもない場合、双方向フィルタしかＤＢ統合用メタデータに定義されていない場合、片方向フィルタ及び片方向フィルタより下位のエレメントに対して１つも条件式が入力されていない場合）には、ステップＳ２１１で特定された条件式群を上向き条件式群に設定する（ステップＳ３０５）。

一方、片方向フィルタに関係する条件式が存在する場合には、問い合わせ処理エンジン部１３１２は、片方向フィルタに関係する条件式を、ステップＳ２１１で特定された条件式群から除外して、仮の条件式群を生成する（ステップＳ３０７）。図４６の右上の例における２つの条件式のうち「ｃｏｄｅ＝ＦＭＶ−６０００ＣＬ」という条件式は、図４６に示すように片方向フィルタより下位のエレメントに関係する条件式であるから、ステップＳ３０７で条件式群から除外され、仮の条件式群は、「ｑｕａｎｔｉｔｙ≧２」という条件群のみとなる。

そして、問い合わせ処理エンジン部１３１２は、１以上の仮の条件式群が生成できたか判断する（ステップＳ３０９）。後に具体的に述べるが、「ｃｏｄｅ＝ＦＭＶ−６０００ＣＬ」という条件式しか問い合わせに含まれない場合には、「ｃｏｄｅ＝ＦＭＶ−６０００ＣＬ」という条件式がステップＳ３０７で除外されると、仮の条件式群は、空になってしまう。本ステップでは、このような状態であるかを確認する。

１以上の仮の条件式群が生成された場合には、問い合わせ処理エンジン部１３１２は、仮の条件式群を、上向き条件式群に設定する（ステップＳ３１１）。一方、１つも仮の条件式群が生成されない場合には、問い合わせ処理エンジン部１３１２は、条件式に対応するエレメント又は当該エレメントより上位のエレメントに定義されている片方向フィルタの直上のエレメントの値を全件抽出するための条件式を生成する（ステップＳ３１３）。図４６のようなＸＭＬ木構造において「ｃｏｄｅ＝ＦＭＶ−６０００ＣＬ」という条件式のみを含む問い合わせを実行する場合には、片方向フィルタの直上のエレメントはＲＤＢ３のｏｒｄｅｒ＿ｉｔｅｍテーブルにおける注文商品というエレメントであり、このエレメント（すなわち、ＲＤＢならばカラム）の値（具体的には、ｏｒｄｅｒＩＤ、ｃｏｄｅ及びｑｕａｎｔｉｔｙカラムの値）全件を抽出するような条件式を生成する。なお、片方向フィルタの直上のエレメントが最上位のエレメントでない場合には、さらに上位のエレメントに関連付けられているエレメント（この例ではｏｒｄｅｒＩＤカラム）の値のみを全件抽出するような条件式であってもよい。

そして、問い合わせ処理エンジン部１３１２は、生成された条件式を可能であればまとめて、上向き条件式群を生成する（ステップＳ３１５）。例えば、条件式に関係する片方向フィルタがＤＢ統合用メタデータに複数存在しており且つ各片方向フィルタの直上のエレメントが同じであれば、抽出すべき値は同じであり同じ条件式が生成されるので、まとめることができる。

このように、ＸＭＬ木構造の上方探索を行うための準備がなされる。なお、ステップＳ３０７で除外された条件式（下方探索条件式又は下向き条件式とも呼ぶ）は、ＤＢ統合用メタデータの木構造の下方探索において用いられる。

図４６の処理の説明に戻って、問い合わせ処理エンジン部１３１２は、最もデータが絞り込める可能性が高い上向き条件式群を特定する（ステップＳ２１５）。数値よりは文字列、文字列もより長い文字列を優先する。ステップＳ１３と同様である。

そして、問い合わせ処理エンジン部１３１２は、ＸＭＬ木構造においてステップＳ２１５で特定された上向き条件群に対応するエレメントが双方向フィルタ（この場合には図４８の処理を実施したので必ず双方向フィルタ）か否かを判断する（ステップＳ２１７）。上でも述べたが、データベースのデータの値域又は形式を仮想化している場合もあるため、条件式群に対応するエレメントが最初から双方向フィルタである場合もある。ステップＳ２１５で特定された上向き条件群に対応するエレメントが双方向フィルタである場合には、条件として指定されている値に対して、双方向フィルタの上向きの変換を適用する（ステップＳ２２３）。そして端子Ｄを介して図５０の処理に移行する。

一方、ステップＳ２１５で特定された上向き条件式群に対応するエレメントが双方向フィルタでない場合には、問い合わせ処理エンジン部１３１２は、特定された上向き条件式群の各条件を利用して、最初のデータベースに問い合わせをするための問い合わせ文を生成して、データベースアクセス処理部１３１３に出力する（ステップＳ２１９）。例えば、図４９の右上（Ａ）に示すようなＲＤＢ２のｓｔｏｃｋテーブルに対するＳＱＬ問い合わせを生成する。なお、基本的には、条件式群に合致するレコードを特定するが、値を求めるのは、上位のエレメントと関連づけられているエレメント（カラム）の値のみでよい。図４９に示すように、ＲＤＢ２のｓｔｏｃｋテーブルにおけるｑｕａｎｔｉｔｙカラムに対して２以上という条件で検索する場合、ＲＤＢ２のｓｔｏｃｋテーブルにおけるｃｏｄｅカラムのみが上位のエレメントに関連付けられているので、ｃｏｄｅカラムの値を特定すればよい。

そして、データベースアクセス処理部１３１３は、グリッドツール１３２を介して最初のデータベース（ＲＤＢ２のｓｔｏｃｋテーブル）を管理するホストに問い合わせ文を出力し、問い合わせ結果を取得する（ステップＳ２２１）。図４９の右上（Ｂ）に示すように、ｃｏｄｅカラムの値（ＦＭＶ０３４５６４，．．．，ｆｍｖ６０００Ｃｌ，．．．）が得られる。データベースアクセス処理部１３１３は、問い合わせ結果を問い合わせ処理エンジン部１３１２に出力する。処理は、端子Ｄを介して図５０の処理に移行する。

図５０の処理の説明に移行して、問い合わせ処理エンジン部１３１２は、最上位のエレメントに到達したか判断する（ステップＳ２２５）。最上位のエレメントに到達した場合にはステップＳ２３７に移行する。一方、最上位のエレメントに到達したわけではない場合には、問い合わせ処理エンジン部１３１２は、ＸＭＬ木構造上１つ上位のエレメントがフィルタ（ここでは双方向フィルタ）であるか判断する（ステップＳ２２７）。ＸＭＬ木構造上１つ上位のエレメントがフィルタである場合には、問い合わせ処理エンジン部１３１２は、直前の問い合わせ結果又はフィルタの適用結果に対して、フィルタの上向きの変換を適用する（ステップＳ２２９）。そして、ステップＳ２３５に移行する。

一方、ＸＭＬ木構造上１つ上位のエレメントがフィルタではない場合には、問い合わせ処理エンジン部１３１２は、直前の問い合わせ結果又はフィルタの適用結果、並びに存在する場合には未使用の上向き条件式群を用いて、上位のデータベースに対する問い合わせ文を生成し、データベースアクセス処理部１３１３に出力する（ステップＳ２３１）。図５１に示すように、直前の問い合わせ結果（ｃｏｄｅ＝（ＦＭＶ０３４５６４，．．．，ｆｍｖ６０００Ｃｌ，．．．））とを用いて、図５１の右上（Ａ）に示すようなＲＤＢ３のｏｒｄｅｒ＿ｉｔｅｍテーブルに対するＳＱＬ問い合わせを生成する。この場合も、値を求めるのは、上位のエレメントと関連づけられているエレメント（カラム）の値のみでよい。

そして、データベースアクセス処理部１３１３は、グリッドツール１３２を介してデータベース（ここではＲＤＢ３）を管理するホストに問い合わせ文を出力し、問い合わせ結果を取得する（ステップＳ２３３）。図５１の右上（Ｂ）に示すように、ＲＤＢ３のｏｒｄｅｒ＿ｉｔｅｍテーブルにおけるｏｒｄｅｒＩＤカラムの値（０７０３０４０２９，．．．，０７０３０６０７１，．．．）が得られる。データベースアクセス処理部１３１３は、問い合わせ結果を問い合わせ処理エンジン部１３１２に出力する。処理は、ステップＳ２３５に移行する。

その後、問い合わせ処理エンジン部１３１２は、ＸＭＬ木構造上の最上位のエレメントまで到達したか判断する（ステップＳ２３５）。ＸＭＬ木構造上の最上位のエレメントまで到達していない場合には、ステップＳ２２７に移行する。このように繰り返し処理を実施してＸＭＬ木構造上の最上位のエレメントの値を取得する。最上位のエレメントの値については、記憶装置に格納しておく。

図５１の段階ではまだＸＭＬ木構造上の最上位のエレメントまで到達していないので、ステップＳ２２７に戻って、問い合わせ処理エンジン部１３１２は、ＸＭＬ木構造上１つ上位のエレメントがフィルタか判断する。図５１の場合、フィルタではないので、直前の問い合わせ結果を用いて、上位のデータベースに対する問い合わせ文を生成する。図５２の右上（Ａ）に示すように、直前の問い合わせ結果（ｏｒｄｅｒＩＤ＝（０７０３０４０２９，．．．，０７０３０６０７１，．．．））を用いて、ＲＤＢ３のｏｒｄｅｒテーブルに対するＳＱＬ問い合わせを生成する。そして、グリッドツール１３２を介してデータベース（ここではＲＤＢ３）を管理するホストに問い合わせ文を出力し、問い合わせ結果を取得する。図５２の右上（Ｂ）に示すように、ＲＤＢ３のｏｒｄｅｒテーブルにおける各カラムの値（ｏｒｄｅｒＩＤカラム、ｐｕｒｃｈａｓｅｒカラム、ｄａｔｅカラムの値。なお、多数の値が得られるので、図５２の右上（Ｂ）では省略表示されている。）が得られる。データベースアクセス処理部１３１３は、問い合わせ結果を問い合わせ処理エンジン部１３１２に出力する。図５２の例では、最上位のエレメントの値が取得できたことになる。上方探索はこれで終了となる。

ステップＳ２３５で最上位のエレメントに到達したと判断された場合には、問い合わせ処理エンジン部１３１２は、ＸＭＬ木構造上１つ下位のエレメントがフィルタであるか判断する（ステップＳ２３７）。ＸＭＬ木構造上１つ下位のエレメントがフィルタではない場合、問い合わせ処理エンジン部１３１２は、上位の問い合わせ結果又はフィルタの適用結果、並びに未使用の条件式（すなわち下方探索条件式）を用いて、下位のデータベースに対する問い合わせ文を生成し、データベースアクセス処理部１３１３に出力する（ステップＳ２４１）。図５３に示すように、直前の問い合わせ結果のうち関連付けされているｏｄｅｒＩＤカラムの値を用いて、図５３の右上（Ａ）に示すようなＲＤＢ３のｏｒｄｅｒ＿ｉｔｅｍテーブルに対するＳＱＬ問い合わせを生成する。

そして、データベースアクセス処理部１３１３は、グリッドツール１３２を介して、データベース（ＲＤＢ３のｏｒｄｅｒ＿ｉｔｅｍテーブル）を管理するホストに問い合わせ文を出力し、問い合わせ結果を取得する（ステップＳ２４３）。図５３の右上（Ｂ）に示すように、ＲＤＢ３のｏｒｄｅｒ＿ｉｔｅｍテーブルにおけるｏｒｄｅｒＩＤカラムの値、ｃｏｄｅカラムの値及びｑｕａｎｔｉｔｙカラムの値が得られる。データベースアクセス処理部１３１３は、取得した問い合わせ結果を問い合わせ処理エンジン部１３１２に出力する。そして、問い合わせ処理エンジン部１３１２は、ＸＭＬ木構造における最下位のエレメントに到達したか判断する（ステップＳ２４５）。ＸＭＬ木構造における最下位のエレメントに到達していない場合には、ステップＳ２３７に戻る。一方、最下位のエレメントに到達した場合には、端子Ｅを介して図５５の処理に移行する。

図５３の例では、ＸＭＬ木構造上最下位のエレメントに到達したとは言えないのでステップＳ２３７に戻る。この場合、ＸＭＬ木構造は２方向に分岐しているので、全ての末端エレメントに到達するまでステップＳ２３７に戻って処理を繰り返す。そして、ＲＤＢ２のｓｔｏｃｋテーブルの方に遷移して、問い合わせ処理エンジン部１３１２は、ＸＭＬ木構造上１つ下位のエレメントがフィルタであるか判断し、ＸＭＬ木構造上１つ下位のエレメントがフィルタではない場合、上位の問い合わせ結果を用いて、下位のデータベースに対する問い合わせ文を生成し、データベースアクセス処理部１３１３に出力する。図５４に示すように、直前の問い合わせ結果のうち関連付けされているｃｏｄｅカラムの値を用いて、図５４の右上（Ａ）に示すようなＲＤＢ２のｓｔｏｃｋテーブルに対するＳＱＬ問い合わせを生成する。そして、データベースアクセス処理部１３１３は、グリッドツール１３２を介して、データベース（ＲＤＢ２のｓｔｏｃｋテーブル）を管理するホストに問い合わせ文を出力し、問い合わせ結果を取得する。図５４の右上（Ｂ）に示すように、ＲＤＢ２のｓｔｏｃｋテーブルにおけるｃｏｄｅカラムの値及びｑｕａｎｔｉｔｙカラムの値が得られる。データベースアクセス処理部１３１３は、取得した問い合わせ結果を問い合わせ処理エンジン部１３１２に出力する。

そして、問い合わせ処理エンジン部１３１２は、ＸＭＬ木構造における最下位のエレメントに到達したか判断する。ＸＭＬ木構造における最下位のエレメントに到達していないので、ステップＳ２３７に戻る。

ＸＭＬ木構造上１つ下位のエレメントがフィルタである場合には、問い合わせ処理エンジン部１３１２は、上位の問い合わせ結果又はフィルタの適用結果に対して、双方向フィルタ又は片方向フィルタの下向きの変換を実施する（ステップＳ２３９）。図５５に示したように、ＲＤＢ３のｏｒｄｅｒ＿ｉｔｅｍテーブルにおけるｃｏｄｅカラムには、フィルタが関連付けられているので、上位の問い合わせ結果であるｃｏｄｅカラムの値（例えばＦＭＶ０３４５６４，．．．，ｆｍｖ６０００Ｃｌ，．．．）を入力として下向きに変換を実施する。すなわち、図５５の右上（Ａ）に示したように、片方向フィルタの下向きの変換Ｆｉｌｔｅｒ＿１（ＦＭＶ０３４５６４，．．．，ｆｍｖ６０００Ｃｌ，．．．）を実施し、右上（Ｂ）に示すように（ｌｏｗｅｒ０）＝（ＦＭＶ−０３４５６４，．．．，ＦＭＶ−６０００ＣＬ，．．．）を得る。すなわち、さらに下位のＲＤＢ１のｉｔｅｍテーブルにおけるｃｏｄｅカラムの値が得られる。その後、ステップＳ２４５に移行する。

図５５の例ではまだ最下位のエレメントに到達していないので、ステップＳ２３７に戻って、ＸＭＬ木構造上１つ下位のエレメントがフィルタであるか判断し、フィルタでないのでステップＳ２４１に移行する。そして、フィルタの適用結果及び未使用の条件式（ｃｏｄｅ＝ＦＭＶ−６０００ＣＬ）を用いて、下位のデータベースに対する問い合わせ文を生成し、データベースアクセス処理部１３１３に出力する。図５６に示すように、フィルタの適用結果であるＲＤＢ１のｉｔｅｍテーブルのｃｏｄｅカラムの値（ＦＭＶ−０３４５６４，．．．，ＦＭＶ−６０００ＣＬ，．．．）及び未使用の条件式（ｃｏｄｅ＝ＦＭＶ−６０００ＣＬ）を用いて、図５６の右上（Ａ）に示すようなＲＤＢ１のｉｔｅｍテーブルに対するＳＱＬ問い合わせを生成する。条件はＡＮＤで結合される。

そして、データベースアクセス処理部１３１３は、グリッドツール１３２を介して、データベース（ＲＤＢ１のｉｔｅｍテーブル）を管理するホストに問い合わせ文を出力し、問い合わせ結果を取得する。図５６の右上（Ｂ）に示すように、ＲＤＢ１のｉｔｅｍテーブルにおけるｃｏｄｅカラムの値及びｎａｍｅカラムの値が得られる。データベースアクセス処理部１３１３は、取得した問い合わせ結果を問い合わせ処理エンジン部１３１２に出力する。

そして、問い合わせ処理エンジン部１３１２は、最下位のエレメントに到達したか再度判断する。図５６の例では、ＸＭＬ木構造上の２つの末端まで到達したので、最下位のエレメントに到達したと判断される。処理は、端子Ｅを介して図５７の処理に移行する。

問い合わせ処理エンジン部１３１２は、ＤＢ統合用メタデータに従って、得られたデータ値から問い合わせ結果のＸＭＬデータを構築する（ステップＳ２４７）。ｖｉｓｉｂｌｅ＝ｔｒｕｅとされるSimpleElementのノードに対応して、得られたデータ値が埋め込まれる。

その後、問い合わせ処理エンジン部１３１２は、問い合わせ結果のチェックを実施する（ステップＳ２４９）。まだＸＱｕｅｒｙの問い合わせで指定した問い合わせ条件の一部が反映されていない可能性が残っているので、問い合わせ条件を満たさない解はチェックして最終結果のＸＭＬデータから除外する。

片方向フィルタがＸＭＬ木構造中に用いられていると、問い合わせに含まれる一部の条件式（下方探索条件式）については上方探索において用いられないので、フィルタより上側の下方探索において問い合わせ条件を満たさないにもかかわらず抽出される値が多くなる。上で述べた例では、最後にフィルタによる変換結果及び条件式（ｃｏｄｅ＝ＦＭＶ−６０００ＣＬ）を適用した際に、値が抽出されないケースが頻出する。よって本ステップにおいて、問い合わせ条件を満たさないケースとして、ＲＤＢ１のｉｔｅｍテーブルにおけるｃｏｄｅカラム及びｎａｍｅカラムについて値が抽出されないケースのデータを削除する。ｃｏｄｅカラムの値が「ＦＭＶ−０３４５６４」であれば、条件を満たさないので、結果としてＲＤＢ１のｉｔｅｍテーブルにおけるｃｏｄｅカラム及びｎａｍｅカラムの値が空となるので、ＲＤＢ３のｏｒｄｅｒ＿ｉｔｅｍテーブルのｃｏｄｅカラムの値が「ＦＭＶ０３４５６４」となるケースを削除する。

最後に、問い合わせ処理エンジン部１３１２は、問い合わせ結果をユーザ端末１１に出力する（ステップＳ２５１）。

このような処理を実施することによって、複数のデータベースに跨る関連データを一括して参照することができるようになる。

次に、図５８乃至図６４を用いて、ＸＭＬ木構造中片方向フィルタが存在する場合の他の検索処理例を説明する。図５８に示すように、上で述べたＸＭＬ木構造と同じ構造を有する場合を想定する。また、図５８の右上に示した問い合わせが行われるものとする。すなわち、コードがＦＭＶ−６０００ＣＬとなるデータを抽出するための問い合わせを実施する。なお、図５８のＸＭＬ木構造においては、片方向フィルタより下のノードに対応する条件式のみの問い合わせになっている。

このような場合には、上向き条件式群生成処理のステップＳ３１３で片方向フィルタの直上のエレメントの値を全件抽出するための条件式を生成する。これは、図５９の右上（Ａ）に示すように、ＲＤＢ３（ｔ３）のｏｒｄｅｒ＿ｉｔｅｍテーブルから、ｏｒｄｅｒＩＤカラムの値及びｃｏｄｅカラムの値を抽出するような検索式を生成する。但し、ＸＭＬ木構造上より上位のノードに関連するｏｒｄｅｒＩＤカラムの値のみを抽出するようにしても良い。そうすると、図５９の右上（Ｂ）では省略しているが、ｏｒｄｅｒＩＤカラムの値及びｃｏｄｅカラムの値が全て抽出される。

そして、１つ上位のエレメントに遷移して、図６０の右上（Ａ）に示すように、ＲＤＢ３のｏｒｄｅｒテーブルから、ＲＤＢ３のｏｒｄｅｒ＿ｉｔｅｍテーブルから抽出されたｏｒｄｅｒＩＤカラムの値に対応するレコードを抽出するような検索式を生成して、出力する。この結果、図６０の右上（Ｂ）では、省略しているが、ｏｒｄｅｒＩＤカラムの値、ｐｕｒｃｈａｓｅｒカラムの値及びｄａｔｅカラムの値のセットが、条件式に含まれるｏｒｄｅｒＩＤカラムの値の件数分抽出される。

これで最上位のエレメントまで到達したので、下方探索に移行する。まず、図６１の右上（Ａ）に示すように、ＲＤＢ３のｏｒｄｅｒ＿ｉｔｅｍテーブルから、ＲＤＢ３のｏｒｄｅｒテーブルから抽出されたｏｒｄｅｒＩＤカラムの値を条件に、該当するレコードを抽出するような検索式を生成して、出力する。この結果、図６１の右上（Ｂ）では省略しているが、ｏｒｄｅｒＩＤカラムの値、ｃｏｄｅカラムの値及びｑｕａｎｔｉｔｙカラムの値のセットが、条件式に含まれるｏｒｄｅｒＩＤカラムの値の件数分抽出される。

さらに、下位のエレメントとしてＲＤＢ２のｓｔｏｃｋテーブルに対応するエレメントに遷移する。そうすると、図６２の右上（Ａ）に示すように、ＲＤＢ２のｓｔｏｃｋテーブルから、ＲＤＢ３のｏｒｄｅｒ＿ｉｔｅｍテーブルにおけるｃｏｄｅカラムの値を条件に、該当するレコードを抽出するような検索式を生成して、出力する。この結果、図６２の右上（Ｂ）では省略しているが、ｃｏｄｅカラムの値及びｑｕａｎｔｉｔｙカラムの値が、条件式に含まれるｃｏｄｅカラムの値の件数分抽出される。

次に、片方向フィルタに遷移する。そうすると、図６３の右上（Ａ）に示すように、ＲＤＢ３のｏｒｄｅｒ＿ｉｔｅｍテーブルから抽出されたｃｏｄｅカラムの値（ＦＭＶ０３４５６４，．．．，ｆｍｖ６０００Ｃｌ，．．．）を入力として、大文字化及びハイフン付与の変換を実行する。この結果、図６３の右上（Ｂ）に示されるように、大文字化及びハイフン付与後のｃｏｄｅカラムの値（ＦＭＶ−０３４５６４，．．．，ＦＭＶ−６０００ＣＬ，．．．）が得られる。

さらに下位のエレメントとしてＲＤＢ１のｉｔｅｍテーブルに対応するエレメントに遷移する。そうすると、図６４の右上（Ａ）に示すように、片方向フィルタからの出力であるｃｏｄｅカラムの値及び未使用の下方探索条件式（ｃｏｄｅ＝ＦＭＶ−６０００ＣＬ）を条件に、ＲＤＢ１のｉｔｅｍテーブルから、該当するレコードを抽出するための検索式を生成して、出力する。この結果、図６４の右上（Ｂ）では省略されているが、ｃｏｄｅ＝ＦＭＶ−６０００ＣＬの条件を満たすｎａｍｅカラムの値が抽出される。

上でも述べたが、本例の場合には、最後に、問い合わせの条件で絞り込むことになるので、ＲＤＢ２及びＲＤＢ３から抽出されたレコードには、問い合わせの条件を満たさないデータが含まれる。最後に、ｃｏｄｅ＝ＦＭＶ−６０００ＣＬの条件を満たさず、ＲＤＢ１のｉｔｅｍテーブルからｎａｍｅカラムの値が抽出されなかった既抽出データ・セットが削除される。

これによって、片方向フィルタであっても双方向フィルタであっても、上で述べたように上方探索及び下方探索によって、複数のデータベースから必要なデータを抽出して、予めＤＢ統合用メタデータに定義されたデータビューにてユーザに提供することができるようになる。

なお、図９に示したデータベース統合参照システム１３及びユーザ端末１１は、コンピュータ装置であって、図６５に示すように当該コンピュータ装置においては、メモリ２５０１（記憶部）とＣＰＵ２５０３（処理部）とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ）及びＷｅｂブラウザを含むアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。このようなコンピュータは、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

（付記１）
複数のデータベースに対する統合的なデータ参照の問い合わせを受け付けるステップと、
問い合わせ結果の出力構造を規定する構造データ、当該構造データ中の要素と前記データベースの要素との対応関係、前記データベース間の要素の関連付け、及び前記データベース間の要素の関連付け又は前記データベースの特定の要素に適用する双方向変換関数が規定された統合用メタデータを格納する統合用メタデータ格納部における前記統合用メタデータから特定される構造体を前記問い合わせに基づき上方に探索して、前記構造体中の最上位要素に対応する前記データベースの要素の値を抽出する上方探索ステップと、
前記構造体を前記構造体中の最上位要素に対応する前記データベースの要素の値に基づき下方に探索して、各前記データベースの各要素の値を抽出する下方探索ステップと、
抽出された各前記データベースの各要素の値を、前記統合用メタデータ格納部に格納されているデータに従って出力するステップと、
をコンピュータに実行させ、
前記上方探索ステップが、
上方探索経路上該当する前記データベースに、前記問い合わせの条件と直前の処理結果との少なくともいずれかに基づく個別問い合わせを出力し、検索の処理結果を取得する上方検索ステップと、
前記上方探索経路上該当する前記双方向変換関数を、前記問い合わせの条件と直前の処理結果との少なくともいずれかに対して上向きに適用し、変換の処理結果を取得するステップと、
を含み、
前記下方探索ステップが、
下方探索経路上該当する前記データベースに、上位の処理結果に基づく個別問い合わせを出力し、検索の処理結果を取得する下方検索ステップと、
前記下方探索経路上該当する前記双方向変換関数を、上位の処理結果に対して下向きに適用し、変換の処理結果を取得するステップと、
を含む
検索プログラム。

（付記２）
前記統合用メタデータにおいて、
前記双方向変換関数が、前記データベースの要素と同列の要素として規定され、
前記データベース間の要素の関連付けが、第１のデータベースの要素と前記双方向変換関数の下向き要素との関連付けと、第２のデータベースの要素と前記双方向変換関数の上向き要素との関連付けとを含む
付記１記載の検索プログラム。

（付記３）
前記統合用メタデータにおいて、
前記双方向変換関数が、前記データベースの要素と同列の要素として規定され、
前記データベースの特定の要素の値を変換する双方向変換関数の場合には、前記データベース間の要素の関連付けが、前記データベースの特定の要素と当該双方向変換関数の要素との関連付けを含む
付記１記載の検索プログラム。

（付記４）
前記統合用メタデータにおいて、
前記構造データにおける、前記双方向変換関数に対応する要素に、前記データ参照の問い合わせにおける使用の可否に関する属性が含まれる
付記２記載の検索プログラム。

（付記５）
前記統合用メタデータにおいて、
前記双方向変換関数が、前記データベースの要素と同列の要素として規定され、
前記データベース間の要素の関連付けが、第１のデータベースのｍ個の要素と前記双方向変換関数のｍ個の下向き要素との関連付けと、第２のデータベースのｎ個の要素と前記双方向変換関数のｎ個の上向き要素との関連付けとを含む
付記１記載の検索プログラム。

（付記６）
前記統合用メタデータにおいて、
前記双方向変換関数が、前記データベースの要素と同列の要素として規定され、
前記データベースの特定の要素に適用される双方向変換関数の場合には、前記データベース間の要素の関連付けが、前記データベースのｍ個の特定の要素と当該双方向変換関数のｍ個の要素との関連付けを含む
付記１記載の検索プログラム。

（付記７）
前記双方向変換関数として、関連付けされたデータベースの要素の値を制限する関数が規定されている場合、
前記関連付けされたデータベースへの個別問い合わせが、前記双方向変換関数によって制限される値に関する条件を含むようにする
付記５記載の検索プログラム。

（付記８）
複数のデータベースに対する統合的なデータ参照の問い合わせを受け付けるステップと、
問い合わせ結果の出力構造を規定する構造データ、当該構造データ中の要素と前記データベースの要素との対応関係、前記データベース間の要素の関連付け、及び前記データベース間の要素の関連付け又は前記データベースの特定の要素に適用する双方向変換関数が規定された統合用メタデータを格納する統合用メタデータ格納部における前記統合用メタデータから特定される構造体を前記問い合わせに基づき上方に探索して、前記構造体中の最上位要素に対応する前記データベースの要素の値を抽出する上方探索ステップと、
前記構造体を前記構造体中の最上位要素に対応する前記データベースの要素の値に基づき下方に探索して、各前記データベースの各要素の値を抽出する下方探索ステップと、
抽出された各前記データベースの各要素の値を、前記統合用メタデータ格納部に格納されているデータに従って出力するステップと、
を含み、
前記上方探索ステップが、
上方探索経路上該当する前記データベースに、前記問い合わせの条件と直前の処理結果との少なくともいずれかに基づく個別問い合わせを出力し、検索の処理結果を取得する上方検索ステップと、
前記上方探索経路上該当する前記双方向変換関数を、前記問い合わせの条件と直前の処理結果との少なくともいずれかに対して上向きに適用し、変換の処理結果を取得するステップと、
を含み、
前記下方探索ステップが、
下方探索経路上該当する前記データベースに、上位の処理結果に基づく個別問い合わせを出力し、検索の処理結果を取得する下方検索ステップと、
前記下方探索経路上該当する前記双方向変換関数を、上位の処理結果に対して下向きに適用し、変換の処理結果を取得するステップと、
を含む
検索方法。

（付記９）
複数のデータベースに対する統合的なデータ参照の問い合わせを受け付ける手段と、
問い合わせ結果の出力構造を規定する構造データ、当該構造データ中の要素と前記データベースの要素との対応関係、前記データベース間の要素の関連付け、及び前記データベース間の要素の関連付け又は前記データベースの特定の要素に適用する双方向変換関数が規定された統合用メタデータを格納する統合用メタデータ格納部と、
前記統合用メタデータ格納部に格納された前記統合用メタデータから特定される構造体を前記問い合わせに基づき上方に探索して、前記構造体中の最上位要素に対応する前記データベースの要素の値を抽出する上方探索手段と、
前記構造体を前記構造体中の最上位要素に対応する前記データベースの要素の値に基づき下方に探索して、各前記データベースの各要素の値を抽出する下方探索手段と、
抽出された各前記データベースの各要素の値を、前記統合用メタデータ格納部に格納されているデータに従って出力する手段と、
を有し、
前記上方探索手段が、
上方探索経路上該当する前記データベースに、前記問い合わせの条件と直前の処理結果との少なくともいずれかに基づく個別問い合わせを出力し、検索の処理結果を取得し、
前記上方探索経路上該当する前記双方向変換関数を、前記問い合わせの条件と直前の処理結果との少なくともいずれかに対して上向きに適用し、変換の処理結果を取得し、
前記下方探索手段が、
下方探索経路上該当する前記データベースに、上位の処理結果に基づく個別問い合わせを出力し、検索の処理結果を取得し、
前記下方探索経路上該当する前記双方向変換関数を、上位の処理結果に対して下向きに適用し、変換の処理結果を取得する、
検索装置。

（付記１０）
問い合わせ結果の出力構造を規定する構造データと、
前記構造データ中の要素と前記データベースの要素との対応関係と、
前記データベース間の要素の関連付けと、
前記データベース間の要素の関連付け又は前記データベースの特定の要素に適用する双方向変換関数又は片方向変換関数と、
が規定されており、コンピュータ読み取り可能な統合用メタデータ。

（付記１１）
複数のデータベースに対する統合的なデータ参照の問い合わせを受け付けるステップと、
問い合わせ結果の出力構造を規定する構造データ、当該構造データ中の要素と前記データベースの要素との対応関係、前記データベース間の要素の関連付け、及び前記データベース間の要素の関連付け又は前記データベースの特定の要素に適用する片方向又は双方向の変換関数が規定された統合用メタデータを格納する統合用メタデータ格納部における前記統合用メタデータから特定される構造体において前記片方向の変換関数に対応する要素及び当該要素より下位の要素に係る条件である下方探索条件を前記問い合わせの条件から除外した条件又は前記問い合わせの条件が前記下方探索条件のみの場合には前記構造体において前記片方向の変換関数に対応する要素の直上の要素について全件値を抽出するための条件である上方探索条件を特定するステップと、
前記統合用メタデータから特定される構造体を前記上方検索条件に基づき上方に探索して、前記構造体中の最上位要素に対応する前記データベースの要素の値を抽出する上方探索ステップと、
前記構造体を前記構造体中の最上位要素に対応する前記データベースの要素の値及び前記下方探索条件に基づき下方に探索して、各前記データベースの各要素の値を抽出する下方探索ステップと、
抽出された各前記データベースの各要素の値を、前記統合用メタデータ格納部に格納されているデータに従って出力するステップと、
をコンピュータに実行させ、
前記上方探索ステップが、
上方探索経路上該当する前記データベースに、前記上方探索条件と直前の処理結果との少なくともいずれかに基づく個別問い合わせを出力し、検索の処理結果を取得する上方検索ステップと、
前記上方探索経路上該当する前記双方向の変換関数を、前記上方探索条件又は直前の処理結果に対して上向きに適用し、変換の処理結果を取得するステップと、
を含み、
前記下方探索ステップが、
下方探索経路上該当する前記データベースに、上位の処理結果と前記下方探索条件との少なくともいずれかに基づく個別問い合わせを出力し、検索の処理結果を取得する下方検索ステップと、
前記下方探索経路上該当する前記片方向又は双方向の変換関数を、上位の処理結果に対して下向きに適用し、変換の処理結果を取得するステップと、
を含む
検索プログラム。

（付記１２）
前記統合用メタデータにおいて、
前記片方向又は双方向の変換関数が、前記データベースの要素と同列の要素として規定され、
前記データベース間の要素の関連付けが、第１のデータベースの要素と前記片方向又は双方向の変換関数の第１の要素との関連付けと、第２のデータベースの要素と前記片方向又は双方向の変換関数の第２の要素との関連付けとを含む
付記１１記載の検索プログラム。

（付記１３）
前記統合用メタデータにおいて、
前記片方向又は双方向の変換関数が、前記データベースの要素と同列の要素として規定され、
前記データベースの特定の要素の値を変換する片方向又は双方向の変換関数の場合には、前記データベース間の要素の関連付けが、前記データベースの特定の要素と前記片方向又は双方向の変換関数の要素との関連付けを含む
付記１１記載の検索プログラム。

（付記１４）
前記統合用メタデータにおいて、
前記構造データにおける、前記片方向又は双方向の変換関数に対応する要素に、前記データ参照の問い合わせにおける使用の可否に関する属性が含まれる
付記２記載の検索プログラム。

（付記１５）
前記統合用メタデータにおいて、
前記片方向又は双方向の変換関数が、前記データベースの要素と同列の要素として規定され、
前記データベース間の要素の関連付けが、第１のデータベースのｍ個の要素と前記片方向又は双方向の変換関数のｍ個の要素との関連付けと、第２のデータベースのｎ個の要素と前記片方向又は双方向の変換関数のｎ個の要素との関連付けとを含む
付記１記載の検索プログラム。

（付記１６）
前記統合用メタデータにおいて、
前記片方向又は双方向の変換関数が、前記データベースの要素と同列の要素として規定され、
前記データベースの特定の要素に適用される片方向又は双方向の変換関数の場合には、前記データベース間の要素の関連付けが、前記データベースのｍ個の特定の要素と前記片方向又は双方向の変換関数のｍ個の要素との関連付けを含む
付記１１記載の検索プログラム。

（付記１７）
複数のデータベースに対する統合的なデータ参照の問い合わせを受け付けるステップと、
問い合わせ結果の出力構造を規定する構造データ、当該構造データ中の要素と前記データベースの要素との対応関係、前記データベース間の要素の関連付け、及び前記データベース間の要素の関連付け又は前記データベースの特定の要素に適用する片方向又は双方向の変換関数が規定された統合用メタデータを格納する統合用メタデータ格納部における前記統合用メタデータから特定される構造体において前記片方向の変換関数に対応する要素及び当該要素より下位の要素に係る条件である下方探索条件を前記問い合わせの条件から除外した条件又は前記問い合わせの条件が前記下方探索条件のみの場合には前記構造体において前記片方向の変換関数に対応する要素の直上の要素について全件値を抽出するための条件である上方探索条件を特定するステップと、
前記統合用メタデータから特定される構造体を前記上方検索条件に基づき上方に探索して、前記構造体中の最上位要素に対応する前記データベースの要素の値を抽出する上方探索ステップと、
前記構造体を前記構造体中の最上位要素に対応する前記データベースの要素の値及び前記下方探索条件に基づき下方に探索して、各前記データベースの各要素の値を抽出する下方探索ステップと、
抽出された各前記データベースの各要素の値を、前記統合用メタデータ格納部に格納されているデータに従って出力するステップと、
を含み、
前記上方探索ステップが、
上方探索経路上該当する前記データベースに、前記上方探索条件と直前の処理結果との少なくともいずれかに基づく個別問い合わせを出力し、検索の処理結果を取得する上方検索ステップと、
前記上方探索経路上該当する前記双方向の変換関数を、前記上方探索条件又は直前の処理結果に対して上向きに適用し、変換の処理結果を取得するステップと、
を含み、
前記下方探索ステップが、
下方探索経路上該当する前記データベースに、上位の処理結果と前記下方探索条件との少なくともいずれかに基づく個別問い合わせを出力し、検索の処理結果を取得する下方検索ステップと、
前記下方探索経路上該当する前記片方向又は双方向の変換関数を、上位の処理結果に対して下向きに適用し、変換の処理結果を取得するステップと、
を含み、
コンピュータにより実行される検索方法。

（付記１８）
複数のデータベースに対する統合的なデータ参照の問い合わせを受け付ける手段と、
問い合わせ結果の出力構造を規定する構造データ、当該構造データ中の要素と前記データベースの要素との対応関係、前記データベース間の要素の関連付け、及び前記データベース間の要素の関連付け又は前記データベースの特定の要素に適用する片方向又は双方向の変換関数が規定された統合用メタデータを格納する統合用メタデータ格納部と、
前記統合用メタデータ格納部における前記統合用メタデータから特定される構造体において前記片方向の変換関数に対応する要素及び当該要素より下位の要素に係る条件である下方探索条件を前記問い合わせの条件から除外した条件又は前記問い合わせの条件が前記下方探索条件のみの場合には前記構造体において前記片方向の変換関数に対応する要素の直上の要素について全件値を抽出するための条件である上方探索条件を特定する手段と、
前記統合用メタデータから特定される構造体を前記上方検索条件に基づき上方に探索して、前記構造体中の最上位要素に対応する前記データベースの要素の値を抽出する上方探索手段と、
前記構造体を前記構造体中の最上位要素に対応する前記データベースの要素の値及び前記下方探索条件に基づき下方に探索して、各前記データベースの各要素の値を抽出する下方探索手段と、
抽出された各前記データベースの各要素の値を、前記統合用メタデータ格納部に格納されているデータに従って出力する手段と、
を有し、
前記上方探索手段が、
上方探索経路上該当する前記データベースに、前記上方探索条件と直前の処理結果との少なくともいずれかに基づく個別問い合わせを出力し、検索の処理結果を取得する手段と、
前記上方探索経路上該当する前記双方向の変換関数を、前記上方探索条件又は直前の処理結果に対して上向きに適用し、変換の処理結果を取得する手段と、
を有し、
前記下方探索手段が、
下方探索経路上該当する前記データベースに、上位の処理結果と前記下方探索条件との少なくともいずれかに基づく個別問い合わせを出力し、検索の処理結果を取得する手段と、
前記下方探索経路上該当する前記片方向又は双方向の変換関数を、上位の処理結果に対して下向きに適用し、変換の処理結果を取得する手段と、
を有する
検索装置。

複数のデータベースの一例を示す図である。 従来のＤＢ統合用メタデータの模式図である。 従来のＤＢ統合用メタデータの第１の部分を示す図である。 従来のＤＢ統合用メタデータの第２の部分を示す図である。 従来のＤＢ統合用メタデータの第３の部分を示す図である。 従来のＤＢ統合用メタデータの第４の部分を示す図である。 仮想データビューを説明するための図である。 従来技術の問題点を示す図である。 本発明の第１の実施の形態におけるシステム概要図である。 本発明の第１の実施の形態におけるホストＢを示す図である。 本発明の第１の実施の形態におけるＤＢ統合用メタデータの模式図である。 本発明の第１の実施の形態におけるＤＢ統合用メタデータの第１の部分を示す図である。 本発明の第１の実施の形態におけるＤＢ統合用メタデータの第２の部分を示す図である。 本発明の第１の実施の形態におけるＤＢ統合用メタデータの第３の部分を示す図である。 本発明の第１の実施の形態におけるＤＢ統合用メタデータの第４の部分を示す図である。 エレメントのｖｉｓｉｂｌｅ属性を説明するための図である。 データベースのデータの値域又は形式を仮想化する場合のＤＢ統合用メタデータの模式図である。 データ結合又は分解を行う双方向フィルタの一例を示す図である。 本発明の第１の実施の形態における処理フローの第１の部分を示す図である。 本発明の第１の実施の形態における処理フローを説明するための具体例（第１段階）を示す図である。 本発明の第１の実施の形態における処理フローを説明するための具体例（第２段階）を示す図である。 本発明の第１の実施の形態における処理フローを説明するための具体例（第３段階）を示す図である。 本発明の第１の実施の形態における処理フローの第２の部分を示す図である。 本発明の第１の実施の形態における処理フローを説明するための具体例（第４段階）を示す図である。 本発明の第１の実施の形態における処理フローを説明するための具体例（第５段階）を示す図である。 本発明の第１の実施の形態における処理フローを説明するための具体例（第６段階）を示す図である。 本発明の第１の実施の形態における処理フローを説明するための具体例（第７段階）を示す図である。 本発明の第１の実施の形態における処理フローを説明するための具体例（第８段階）を示す図である。 本発明の第１の実施の形態における処理フローを説明するための具体例（第９段階）を示す図である。 本発明の第１の実施の形態における処理フローを説明するための具体例（第１０段階）を示す図である。 本発明の第１の実施の形態における処理フローの第３の部分を示す図である。 問い合わせ結果の模式図を示す図である。 データの値を制限又は選択するための双方向フィルタの一例を示す図である。 データの値を制限又は選択するための双方向フィルタが記述された場合の処理フローの第１の部分を示す図である。 第１検索処理の処理フローを示す図である。 データの値を制限又は選択するための双方向フィルタが記述された場合の処理フローの第２の部分を示す図である。 第２検索処理の処理フローを示す図である。 ＤＢ統合用メタデータの第２の例を示す図である。 ＤＢ統合用メタデータの第２の例を示す図である。 ＤＢ統合用メタデータの第２の例を示す図である。 ＤＢ統合用メタデータの第２の例を示す図である。 ＸＭＬ−ＤＢが混在するデータベースを示す図である。 片方向フィルタを説明するための図である。 片方向フィルタの一例を示す図である。 ｍ対ｎの片方向フィルタの一例を示す図である。 本発明の第２の実施の形態における処理フローを説明するための具体例（第１段階）を示す図である。 本発明の第２の実施の形態における処理フローの第１の部分を示す図である。 上向き条件式群生成処理の処理フローを示す図である。 本発明の第２の実施の形態における処理フローを説明するための具体例（第２段階）を示す図である。 本発明の第２の実施の形態における処理フローの第２の部分を示す図である。 本発明の第２の実施の形態における処理フローを説明するための具体例（第３段階）を示す図である。 本発明の第２の実施の形態における処理フローを説明するための具体例（第４段階）を示す図である。 本発明の第２の実施の形態における処理フローを説明するための具体例（第５段階）を示す図である。 本発明の第２の実施の形態における処理フローを説明するための具体例（第６段階）を示す図である。 本発明の第２の実施の形態における処理フローを説明するための具体例（第７段階）を示す図である。 本発明の第２の実施の形態における処理フローを説明するための具体例（第８段階）を示す図である。 本発明の第２の実施の形態における処理フローの第３の部分を示す図である。 本発明の第２の実施の形態における処理フローを説明するための具体例（第１段階）を示す図である。 本発明の第２の実施の形態における処理フローを説明するための具体例（第２段階）を示す図である。 本発明の第２の実施の形態における処理フローを説明するための具体例（第３段階）を示す図である。 本発明の第２の実施の形態における処理フローを説明するための具体例（第４段階）を示す図である。 本発明の第２の実施の形態における処理フローを説明するための具体例（第５段階）を示す図である。 本発明の第２の実施の形態における処理フローを説明するための具体例（第６段階）を示す図である。 本発明の第２の実施の形態における処理フローを説明するための具体例（第７段階）を示す図である。 コンピュータの機能ブロック図である。

符号の説明

１１ ユーザ端末 １３ データベース統合参照システム
１３１ ＸＱｕｅｒｙ問い合わせ処理部
１３２ グリッドツール
１３３ ＤＢ統合用メタデータ格納部
１３１１ 問い合わせパーザ部
１３１２ 問い合わせ処理エンジン部
１３１３ データベースアクセス処理部

Claims (10)

1. 複数のデータベースに対する統合的なデータ参照の問い合わせを受け付けるステップと、
   問い合わせ結果の出力構造を規定する構造データ、当該構造データ中の要素と前記データベースの要素との対応関係、前記データベース間の要素の関連付け、及び前記データベース間の要素の関連付け又は前記データベースの特定の要素に適用する双方向変換関数が規定された統合用メタデータを格納する統合用メタデータ格納部における前記統合用メタデータから特定される構造体を前記問い合わせに基づき上方に探索して、前記構造体中の最上位要素に対応する前記データベースの要素の値を抽出する上方探索ステップと、
   前記構造体を前記構造体中の最上位要素に対応する前記データベースの要素の値に基づき下方に探索して、各前記データベースの各要素の値を抽出する下方探索ステップと、
   抽出された各前記データベースの各要素の値を、前記統合用メタデータ格納部に格納されているデータに従って出力するステップと、
   をコンピュータに実行させ、
   前記上方探索ステップが、
   上方探索経路上該当する前記データベースに、前記問い合わせの条件と直前の処理結果との少なくともいずれかに基づく個別問い合わせを出力し、検索の処理結果を取得するステップと、
   前記上方探索経路上該当する前記双方向変換関数を、前記問い合わせの条件と直前の処理結果との少なくともいずれかに対して上向きに適用し、変換の処理結果を取得するステップと、
   を含み、
   前記下方探索ステップが、
   下方探索経路上該当する前記データベースに、上位の処理結果に基づく個別問い合わせを出力し、検索の処理結果を取得するステップと、
   前記下方探索経路上該当する前記双方向変換関数を、上位の処理結果に対して下向きに適用し、変換の処理結果を取得するステップと、
   を含む
   検索プログラム。
2. 前記統合用メタデータにおいて、
   前記双方向変換関数が、前記データベースの要素と同列の要素として規定され、
   前記データベース間の要素の関連付けが、第１のデータベースの要素と前記双方向変換関数の下向き要素との関連付けと、第２のデータベースの要素と前記双方向変換関数の上向き要素との関連付けとを含む
   請求項１記載の検索プログラム。
3. 前記統合用メタデータにおいて、
   前記双方向変換関数が、前記データベースの要素と同列の要素として規定され、
   前記データベース間の要素の関連付けが、第１のデータベースのｍ個の要素と前記双方向変換関数のｍ個の下向き要素との関連付けと、第２のデータベースのｎ個の要素と前記双方向変換関数のｎ個の上向き要素との関連付けとを含む
   請求項１記載の検索プログラム。
4. 複数のデータベースに対する統合的なデータ参照の問い合わせを受け付けるステップと、
   問い合わせ結果の出力構造を規定する構造データ、当該構造データ中の要素と前記データベースの要素との対応関係、前記データベース間の要素の関連付け、及び前記データベース間の要素の関連付け又は前記データベースの特定の要素に適用する片方向又は双方向の変換関数が規定された統合用メタデータを格納する統合用メタデータ格納部における前記統合用メタデータから特定される構造体において前記片方向の変換関数に対応する要素及び当該要素より下位の要素に係る条件である下方探索条件を前記問い合わせの条件から除外した条件又は前記問い合わせの条件が前記下方探索条件のみの場合には前記構造体において前記片方向の変換関数に対応する要素の直上の要素について全件値を抽出するための条件である上方探索条件を特定するステップと、
   前記統合用メタデータから特定される構造体を前記上方検索条件に基づき上方に探索して、前記構造体中の最上位要素に対応する前記データベースの要素の値を抽出する上方探索ステップと、
   前記構造体を前記構造体中の最上位要素に対応する前記データベースの要素の値及び前記下方探索条件に基づき下方に探索して、各前記データベースの各要素の値を抽出する下方探索ステップと、
   抽出された各前記データベースの各要素の値を、前記統合用メタデータ格納部に格納されているデータに従って出力するステップと、
   をコンピュータに実行させ、
   前記上方探索ステップが、
   上方探索経路上該当する前記データベースに、前記上方探索条件と直前の処理結果との少なくともいずれかに基づく個別問い合わせを出力し、検索の処理結果を取得するステップと、
   前記上方探索経路上該当する前記双方向の変換関数を、前記上方探索条件又は直前の処理結果に対して上向きに適用し、変換の処理結果を取得するステップと、
   を含み、
   前記下方探索ステップが、
   下方探索経路上該当する前記データベースに、上位の処理結果と前記下方探索条件との少なくともいずれかに基づく個別問い合わせを出力し、検索の処理結果を取得するステップと、
   前記下方探索経路上該当する前記片方向又は双方向の変換関数を、上位の処理結果に対して下向きに適用し、変換の処理結果を取得するステップと、
   を含む
   検索プログラム。
5. 前記統合用メタデータにおいて、
   前記片方向又は双方向の変換関数が、前記データベースの要素と同列の要素として規定され、
   前記データベース間の要素の関連付けが、第１のデータベースの要素と前記片方向又は双方向の変換関数の第１の要素との関連付けと、第２のデータベースの要素と前記片方向又は双方向の変換関数の第２の要素との関連付けとを含む
   請求項４記載の検索プログラム。
6. 前記統合用メタデータにおいて、
   前記片方向又は双方向の変換関数が、前記データベースの要素と同列の要素として規定され、
   前記データベースの特定の要素の値を変換する片方向又は双方向の変換関数の場合には、前記データベース間の要素の関連付けが、前記データベースの特定の要素と前記片方向又は双方向の変換関数の要素との関連付けを含む
   請求項４記載の検索プログラム。
7. 前記統合用メタデータにおいて、
   前記構造データにおける、前記片方向又は双方向の変換関数に対応する要素に、前記データ参照の問い合わせにおける使用の可否に関する属性が含まれる
   請求項５記載の検索プログラム。
8. 前記統合用メタデータにおいて、
   前記片方向又は双方向の変換関数が、前記データベースの要素と同列の要素として規定され、
   前記データベース間の要素の関連付けが、第１のデータベースのｍ個の要素と前記片方向又は双方向の変換関数のｍ個の要素との関連付けと、第２のデータベースのｎ個の要素と前記片方向又は双方向の変換関数のｎ個の要素との関連付けとを含む
   請求項４記載の検索プログラム。
9. 複数のデータベースに対する統合的なデータ参照の問い合わせを受け付けるステップと、
   問い合わせ結果の出力構造を規定する構造データ、当該構造データ中の要素と前記データベースの要素との対応関係、前記データベース間の要素の関連付け、及び前記データベース間の要素の関連付け又は前記データベースの特定の要素に適用する片方向又は双方向の変換関数が規定された統合用メタデータを格納する統合用メタデータ格納部における前記統合用メタデータから特定される構造体において前記片方向の変換関数に対応する要素及び当該要素より下位の要素に係る条件である下方探索条件を前記問い合わせの条件から除外した条件又は前記問い合わせの条件が前記下方探索条件のみの場合には前記構造体において前記片方向の変換関数に対応する要素の直上の要素について全件値を抽出するための条件である上方探索条件を特定するステップと、
   前記統合用メタデータから特定される構造体を前記上方検索条件に基づき上方に探索して、前記構造体中の最上位要素に対応する前記データベースの要素の値を抽出する上方探索ステップと、
   前記構造体を前記構造体中の最上位要素に対応する前記データベースの要素の値及び前記下方探索条件に基づき下方に探索して、各前記データベースの各要素の値を抽出する下方探索ステップと、
   抽出された各前記データベースの各要素の値を、前記統合用メタデータ格納部に格納されているデータに従って出力するステップと、
   を含み、
   前記上方探索ステップが、
   上方探索経路上該当する前記データベースに、前記上方探索条件と直前の処理結果との少なくともいずれかに基づく個別問い合わせを出力し、検索の処理結果を取得する上方検索ステップと、
   前記上方探索経路上該当する前記双方向の変換関数を、前記上方探索条件又は直前の処理結果に対して上向きに適用し、変換の処理結果を取得するステップと、
   を含み、
   前記下方探索ステップが、
   下方探索経路上該当する前記データベースに、上位の処理結果と前記下方探索条件との少なくともいずれかに基づく個別問い合わせを出力し、検索の処理結果を取得する下方検索ステップと、
   前記下方探索経路上該当する前記片方向又は双方向の変換関数を、上位の処理結果に対して下向きに適用し、変換の処理結果を取得するステップと、
   を含み、
   コンピュータにより実行される検索方法。
10. 複数のデータベースに対する統合的なデータ参照の問い合わせを受け付ける手段と、
    問い合わせ結果の出力構造を規定する構造データ、当該構造データ中の要素と前記データベースの要素との対応関係、前記データベース間の要素の関連付け、及び前記データベース間の要素の関連付け又は前記データベースの特定の要素に適用する片方向又は双方向の変換関数が規定された統合用メタデータを格納する統合用メタデータ格納部と、
    前記統合用メタデータ格納部における前記統合用メタデータから特定される構造体において前記片方向の変換関数に対応する要素及び当該要素より下位の要素に係る条件である下方探索条件を前記問い合わせの条件から除外した条件又は前記問い合わせの条件が前記下方探索条件のみの場合には前記構造体において前記片方向の変換関数に対応する要素の直上の要素について全件値を抽出するための条件である上方探索条件を特定する手段と、
    前記統合用メタデータから特定される構造体を前記上方検索条件に基づき上方に探索して、前記構造体中の最上位要素に対応する前記データベースの要素の値を抽出する上方探索手段と、
    前記構造体を前記構造体中の最上位要素に対応する前記データベースの要素の値及び前記下方探索条件に基づき下方に探索して、各前記データベースの各要素の値を抽出する下方探索手段と、
    抽出された各前記データベースの各要素の値を、前記統合用メタデータ格納部に格納されているデータに従って出力する手段と、
    を有し、
    前記上方探索手段が、
    上方探索経路上該当する前記データベースに、前記上方探索条件と直前の処理結果との少なくともいずれかに基づく個別問い合わせを出力し、検索の処理結果を取得する手段と、
    前記上方探索経路上該当する前記双方向の変換関数を、前記上方探索条件又は直前の処理結果に対して上向きに適用し、変換の処理結果を取得する手段と、
    を有し、
    前記下方探索手段が、
    下方探索経路上該当する前記データベースに、上位の処理結果と前記下方探索条件との少なくともいずれかに基づく個別問い合わせを出力し、検索の処理結果を取得する手段と、
    前記下方探索経路上該当する前記片方向又は双方向の変換関数を、上位の処理結果に対して下向きに適用し、変換の処理結果を取得する手段と、
    を有する
    検索装置。

Images