(57)【要約】【課題】ユーザにおいてデータの分散を意識することなく問い合わせを行うことを課題とする。【解決手段】データベース統合参照装置２０は、問い合わせ結果の出力に用いるＸＭＬファイルの構造、当該ＸＭＬファイル中の各要素と各データベースの各要素との対応関係、並びに、各データベース間の各要素の対応関係が規定された統合用メタデータを記憶する。そして、かかる統合用メタデータを利用し、複数のデータベースに分散しているデータを統合して１つの仮想的なＸＭＬファイルとしてユーザに意識させ、そのデータに対してＸＱｕｅｒｙというＸＭＬ問い合わせ言語で記述された問い合わせを受け付け、統合されたデータをＸＭＬ形式で取り出してユーザ端末１０に出力する。【選択図】        図３
2005208757.tif 000002
【特許請求の範囲】
【請求項１】
複数のデータベースに対するデータ参照の問い合わせを受け付け、各データベースから問い合わせに係るデータを取得するデータベース統合参照装置であって、
問い合わせ結果の出力に用いるタグ付き文書の構造、当該タグ付き文書中の各要素と各データベースの各要素との対応関係、並びに、各データベース間の各要素の対応関係が規定された統合用メタデータを記憶する統合用メタデータ記憶手段と、
前記タグ付き文書に対する問い合わせ形式でデータ参照の問い合わせを受け付け、前記統合用メタデータを参照し、各データベースに対して必要な問い合わせを行ってデータを取得して、前記タグ付き文書の構造で問い合わせ結果を生成する問い合わせ処理手段と、
を備えたことを特徴とするデータベース統合参照装置。
【請求項２】
前記問い合わせ処理手段は、前記データ参照の問い合わせ内容および前記データベースに係るメタデータを用いて、各データベースに対する問い合わせの結果として最もデータが絞り込めそうなデータベースを決定し、当該データベースに対して最初の問い合わせを行うことを特徴とする請求項１に記載のデータベース統合参照装置。
【請求項３】
前記問い合わせ処理手段は、前記統合用メタデータで規定されたタグ付き文書の木構造に基づいて、前記最初の問い合わせを行った要素から上位の要素を順に辿りながら対応するデータを取得するように問い合わせを行い、さらに、最上位の要素を取得した後は、当該最上位の要素から下位の要素を全て辿りながら対応するデータを取得するように問い合わせを行うことを特徴とする請求項２に記載のデータベース統合参照装置。
【請求項４】
複数のデータベースに対するデータ参照の問い合わせを受け付け、各データベースから問い合わせに係るデータを取得するデータベース統合参照方法であって、
問い合わせ結果の出力に用いるタグ付き文書の構造、当該タグ付き文書中の各要素と各データベースの各要素との対応関係、並びに、各データベース間の各要素の対応関係が規定された統合用メタデータを統合用メタデータ記憶手段に格納する統合用メタデータ格納工程と、
前記タグ付き文書に対する問い合わせ形式でデータ参照の問い合わせを受け付け、前記統合用メタデータを参照し、各データベースに対して必要な問い合わせを行ってデータを取得して、前記タグ付き文書の構造で問い合わせ結果を生成する問い合わせ処理工程と、
を含んだことを特徴とするデータベース統合参照方法。
【請求項５】
複数のデータベースに対するデータ参照の問い合わせを受け付け、各データベースから問い合わせに係るデータを取得する方法をコンピュータに実行させるデータベース統合参照プログラムであって、
問い合わせ結果の出力に用いるタグ付き文書の構造、当該タグ付き文書中の各要素と各データベースの各要素との対応関係、並びに、各データベース間の各要素の対応関係が規定された統合用メタデータを統合用メタデータ記憶手段に格納する統合用メタデータ格納手順と、
前記タグ付き文書に対する問い合わせ形式でデータ参照の問い合わせを受け付け、前記統合用メタデータを参照し、各データベースに対して必要な問い合わせを行ってデータを取得して、前記タグ付き文書の構造で問い合わせ結果を生成する問い合わせ処理手順と、
をコンピュータに実行させることを特徴とするデータベース統合参照プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、複数のデータベースに対するデータ参照の問い合わせを受け付け、各データベースから問い合わせに係るデータを取得するデータベース統合参照装置、データベース統合参照方法およびデータベース統合参照プログラムに関する。
【背景技術】
【０００２】
従来より、異なるマシンや異なる環境に複数の既存データベースがあり、それらに跨って関連するデータが分散している場合に、それらを統合された１つのデータベースとして参照できるようにするための技術として、新たにデータウェアハウスを構築し、そこに全てのデータを移してくるという手法があった。
【０００３】
ところが、この手法では、元のデータベースからデータウェアハウスへデータをコピーすることによるタイムラグが生じるので、元のデータベースのデータをリアルタイムに参照することができないという問題点があった。また、データウェアハウスは構築にコストと時間を要するところ、簡単には作り直すことができないので、ビジネスが短周期で変化してデータベース統合の要求が変わってしまうような場合に、それに迅速に対応することができないという問題点もあった。
【０００４】
このようなことから、複数のＤＢ（データベース）に分散しているデータを物理的に集めるのではなく、データグリッド技術を利用し、データは各ＤＢに配置したまま、ユーザから統合されたデータの参照要求があった時点でリアルタイムに各ＤＢに問い合わせて必要なデータを取得し、それを組み立ててユーザに返すという手法も検討されている。すなわち、問い合わせ型データベース統合と呼ばれる手法であるが、例えば、非特許文献１や２には、複数の異種のＤＢ（製造元やデータ構築手法が異なるＤＢ）に対して、同一のアクセス手段でアクセスする問い合わせ型データベース統合が開示されている。
【０００５】
かかる問い合わせ型データベース統合では、ネットワークを経由してデータを獲得してくるので、レスポンス時間は遅くなるが、近年のネットワークの高速化によって実用性が増してきている。また、複数のＤＢに跨っていたデータは、性能問題を除けばあたかも全て１つのＤＢ上にあるかのように利用できるようになる。すわわち、問い合わせ型データベース統合によれば、データウェアハウスにおけるデータのリアルタイム性の問題点も解決し、データベース自体に手を入れる必要が無いので、ビジネスの変化によるデータベース統合の要求変更にも迅速に対応できるようになる。
【０００６】
【非特許文献１】“IBM  DB2 Information Integrator V8.1”、［online］、［平成１６年１月１６日検索］、インターネット＜http://www-6.ibm.com/jp/Products/news/030522/gaiyo.html＞
【０００７】
【非特許文献２】“OGSA-DAI”、［online］、［平成１６年１月１６日検索］、インターネット＜http://www.ogsadai.org/＞
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、上記した従来の問い合わせ型データベース統合技術は、データベースへのアクセス手段を統合しただけであり、データの格納構造自体は変わっていないので、ユーザは元のデータ格納構造を意識してデータにアクセスする必要があった。つまり、データ自体は既存のデータベースに格納されたものをそのまま取り出して表示しているだけであり、実際にはアクセスしたデータごとにビューがユーザに提供されてしまい、ユーザからは、図２６に例示するように、各データベースに分散していたテーブルがあたかも１つのデータベース上にあるように見えるに過ぎないので、ユーザは実際のデータ分散を意識して問い合わせを行う必要があった。このため、多数のデータベースに跨って関連するデータを集めてくるのは容易ではなく、以下に列挙するような具体的な問題点があった。
【０００９】
すなわち、多数に分割されているデータを集めて組み立てることが容易でないのは単一データベース内の場合も同様であるが、単一データベース内の場合は、一定のポリシーに基づいてデータが格納されて統一性があるのに対し、複数のデータベースに跨る場合は、そのような統一性が無くなるので、問い合わせが一層困難であるという問題点があった。
【００１０】
また、複数のデータベースに跨る場合には、データベースのメタ情報の所在も別々になり、その形式も様々に異なるので、全てのデータベースに関して格納構造を把握することが難しくなり、問い合わせが極めて一層困難になるという問題点があった。
【００１１】
さらに、同種のデータが複数のデータベースに分かれて格納され、かつ、ある１つの値を持つデータに関してはそれらのいずれか一方に格納されているような場合があるが、この場合において参照したいデータを取得するためには、それら全てのデータベースにアクセスして（問い合わせて）データを探す必要があるので、データベース数が多くなるに従って問い合わせが困難になるという問題点があった。
【００１２】
このようなことから、アクセスしたデータごとに提供される個々のビューを１つに纏め上げる（データビューの統合）機能を上位アプリケーションにおいて個別に作り込む必要もあったが、上位アプリケーションの開発には工数が掛かるので、近年の企業再編や事業再編といった頻繁なビジネス変化に対応して、迅速に上位アプリケーションを変更することが依然として困難であるという問題点もあった。
【００１３】
そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、ユーザにおいてデータの分散を意識することなく問い合わせを行うことが可能なデータベース統合参照装置、データベース統合参照方法およびデータベース統合参照プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１４】
上述した課題を解決し、目的を達成するため、請求項１に係る発明は、複数のデータベースに対するデータ参照の問い合わせを受け付け、各データベースから問い合わせに係るデータを取得するデータベース統合参照装置であって、問い合わせ結果の出力に用いるタグ付き文書の構造、当該タグ付き文書中の各要素と各データベースの各要素との対応関係、並びに、各データベース間の各要素の対応関係が規定された統合用メタデータを記憶する統合用メタデータ記憶手段と、前記タグ付き文書に対する問い合わせ形式でデータ参照の問い合わせを受け付け、前記統合用メタデータを参照し、各データベースに対して必要な問い合わせを行ってデータを取得して、前記タグ付き文書の構造で問い合わせ結果を生成する問い合わせ処理手段と、を備えたことを特徴とする。
【００１５】
また、請求項２に係る発明は、上記の発明において、前記問い合わせ処理手段は、前記データ参照の問い合わせ内容および前記データベースに係るメタデータを用いて、各データベースに対する問い合わせの結果として最もデータが絞り込めそうなデータベースを決定し、当該データベースに対して最初の問い合わせを行うことを特徴とする。
【００１６】
また、請求項３に係る発明は、上記の発明において、前記問い合わせ処理手段は、前記統合用メタデータで規定されたタグ付き文書の木構造に基づいて、前記最初の問い合わせを行った要素から上位の要素を順に辿りながら対応するデータを取得するように問い合わせを行い、さらに、最上位の要素を取得した後は、当該最上位の要素から下位の要素を全て辿りながら対応するデータを取得するように問い合わせを行うことを特徴とする。
【００１７】
また、請求項４に係る発明は、複数のデータベースに対するデータ参照の問い合わせを受け付け、各データベースから問い合わせに係るデータを取得するデータベース統合参照方法であって、問い合わせ結果の出力に用いるタグ付き文書の構造、当該タグ付き文書中の各要素と各データベースの各要素との対応関係、並びに、各データベース間の各要素の対応関係が規定された統合用メタデータを統合用メタデータ記憶手段に格納する統合用メタデータ格納工程と、前記タグ付き文書に対する問い合わせ形式でデータ参照の問い合わせを受け付け、前記統合用メタデータを参照し、各データベースに対して必要な問い合わせを行ってデータを取得して、前記タグ付き文書の構造で問い合わせ結果を生成する問い合わせ処理工程と、を含んだことを特徴とする。
【００１８】
また、請求項５に係る発明は、複数のデータベースに対するデータ参照の問い合わせを受け付け、各データベースから問い合わせに係るデータを取得する方法をコンピュータに実行させるデータベース統合参照プログラムであって、問い合わせ結果の出力に用いるタグ付き文書の構造、当該タグ付き文書中の各要素と各データベースの各要素との対応関係、並びに、各データベース間の各要素の対応関係が規定された統合用メタデータを統合用メタデータ記憶手段に格納する統合用メタデータ格納手順と、前記タグ付き文書に対する問い合わせ形式でデータ参照の問い合わせを受け付け、前記統合用メタデータを参照し、各データベースに対して必要な問い合わせを行ってデータを取得して、前記タグ付き文書の構造で問い合わせ結果を生成する問い合わせ処理手順と、をコンピュータに実行させることを特徴とする。
【発明の効果】
【００１９】
請求項１、４または５の発明によれば、ユーザはタグ付き文書というビューのみを意識すればよく、その各データがどのデータベースに格納されているかを知る必要がなくなる。つまり、ユーザにおいてデータの分散を意識することなく問い合わせを行うことが可能になる。
【００２０】
また、請求項２の発明によれば、問い合わせ順番を操作して結果データを絞り込んでいくことによって、データ転送量を減らして、問い合わせにかかる時間を短縮するとともに、ネットワークにかかる負担も軽減することが可能になる。
【００２１】
また、請求項３の発明によれば、タグ付き文書の構造定義や問い合わせの内容に関わらず、問い合わせ結果としてのタグ付き文書全体を洩れなく求めることが可能になるとともに、データベースへの問い合わせの回数を少なく抑えることが可能になる。
【発明を実施するための最良の形態】
【００２２】
以下に添付図面を参照して、この発明に係るデータベース統合参照装置、データベース統合参照方法およびデータベース統合参照プログラムの実施例を詳細に説明する。なお、以下では、本発明に係るデータベース統合参照装置を備えて形成されるデータベース統合参照システムを実施例として、かかる実施例に係るシステムの概要および特徴を説明した後に、種々の実施例（実施例１および２）を説明する。
【００２３】
［システムの概要および特徴］
最初に、図１および図２を用いて、実施例に係るデータベース統合参照システムの概要および特徴を説明する。図１および図２は、実施例に係るデータベース統合参照システムの概要および特徴を説明するための図である。
【００２４】
図１に示すように、実施例に係るデータベース統合参照システムは、複数のデータベースとユーザ端末との間にデータベース統合参照装置が介在して形成され、概略的には、このデータベース統合参照装置が、複数のデータベースに対するデータ参照の問い合わせをユーザ端末から受け付け、各データベースから問い合わせに係るデータを取得し、問い合わせ結果をユーザ端末に返すというものである。
【００２５】
そして、かかるシステムのデータベース統合参照装置では、図１および図２に示すように、統合用メタデータの利用によって、複数のデータベースに分散しているデータを統合して１つの仮想的なタグ付き文書（例えば、ＸＭＬファイル）としてユーザに意識させ、そのデータに対してタグ付き文書に対する問い合わせ形式でデータ参照の問い合わせ（例えば、ＸＱｕｅｒｙというＸＭＬ問い合わせ言語で記述された問い合わせ）を受け付け、統合されたデータをＸＭＬ形式で取り出すことを特徴とする。
【００２６】
より具体的には、データベース統合参照装置では、データグリッドのインフラとして業界標準である「Globus Toolkit 3＋OGSA-DAI」を使用し、その上に、統合したリレーショナルＤＢのデータをＸＭＬというモデルで提供するための統合問い合わせエンジンを構築し、分散しているデータをＸＭＬファイルのようにハンドルすることで、データベース統合参照装置側でのデータビュー統合を実現する。
【００２７】
このようなことから、実施例に係るデータベース統合参照システムによれば、以下に列挙するように、リアルタイムなデータアクセス、上位アプリケーションの開発工数の大幅削減、自由度および拡張性が高いＤＢ統合、段階的なメタデータ構築などが可能になる。
【００２８】
すなわち、本実施例では、分散しているデータをＤＷＨ（データウェアハウス）のように物理的に一箇所に集めるのではなく、既存のＤＢに分散して配置された状態のまま、問い合わせ時に必要なデータだけを獲得し、結果として統合的なデータビューを作り上げる。これによって、リアルタイムなデータアクセスが可能になる。
【００２９】
また、本実施例では、分散しているデータをＸＭＬ形式のファイルに統合するので、そのＸＭＬファイルに対してＸＱｕｅｒｙで問い合わせを行い、問い合わせ結果もＸＭＬ形式で取り出すことができる。つまり、上位アプリケーション側に対して、ＸＭＬファイルによって統合されたデータビューを提供することができるので、上位アプリケーション側でデータビュー統合のための機能を作りこむ必要がなくなり、これによって、上位アプリケーションの開発工数の大幅削減が可能になる。
【００３０】
また、本実施例では、複数のリレーショナルＤＢのデータをリレーショナルモデルのまま統合するのではなく、モデル変換を行ってＸＭＬファイルというビューで統合する。かかるＸＭＬファイルの形式はリレーショナルモデルよりも自由度および拡張性が高いので、この統合されたＸＭＬファイルに対して柔軟な使い方が可能になる。つまり、本実施例によるデータビューはＸＭＬによって統合されているため、検索システムだけではなく、ＸＭＬに対応した様々なアプリケーションシステムを本実施例に係るシステム上に容易に構築することができるなど、自由度および拡張性が高いＤＢ統合が可能になる。
【００３１】
また、本実施例では、複数の分散しているデータからどのような仮想ＸＭＬを構成するかを、統合用メタデータで自由に定義するが、その際、問い合わせに必要な情報のみで定義することができる。これによって、初めから全ての情報を定義しておく必要がなくなり、段階的に統合用メタデータを構築することが可能になる。
【実施例１】
【００３２】
以下に、実施例１に係るデータベース統合参照システムとして、システムの全体構成を最初に説明した後に、システム内のデータベース統合参照装置の構成、データベース統合参照装置による問い合わせ処理の手順、問い合わせ順序の最適化手法を順に説明し、最後に実施例１の効果等を説明する。
【００３３】
［システムの全体構成］
最初に、図３を用いて、実施例１に係るデータベース統合参照システムの全体構成を説明する。図３は、実施例１に係るデータベース統合参照システムの全体構成を示すシステム構成図である。
【００３４】
同図に示すように、実施例１に係るデータベース統合参照システムは、ユーザ端末１０と、複数のデータベース（受注ＤＢ１１、商品ＤＢ１２、在庫ＤＢI１３および在庫ＤＢ
II１４）と、データベース統合参照装置２０とを、ＬＡＮやインターネットなどのネット
ワークを介して相互に通信可能に接続して構成される。
【００３５】
このうち、各データベースは、実施例１によって統合されるデータベースであり、リレーショナルデータベースなどの既知のデータベース装置でそれぞれ構成される。この実施例１では、図３に例示するように、受注ＤＢ１１、商品ＤＢ１２、在庫ＤＢI１３および
在庫ＤＢII１４の４つのデータベースにデータが分散されている例を挙げている。
【００３６】
ここで、受注ＤＢ１１は、ある会社が受注した注文に係る情報を記憶するＤＢであり、ＤＢ内の注文伝票テーブル１１ａは、図４に例示するように、注文伝票本体ごとに「order_id（注文ＩＤ）、customer（顧客名）、supplier（供給業者名）、order_date（受注年月日）」の各要素のデータを相互に対応付けて構成される。同様に、受注ＤＢ１１内の商品テーブル１１ｂは、注文伝票内の商品ごとに「order_id（注文ＩＤ）、item_code（商品コード）、quantity（注文数量）」の各要素のデータを相互に対応付けて構成される。なお、１枚の注文伝票には複数の注文商品が記述されているので、注文伝票テーブル１１ａの１レコードに対応する商品テーブル１１ｂのレコードは複数ある。
【００３７】
商品ＤＢ１２は、上記の会社が取り扱っている商品に係る情報を記憶するＤＢであり、ＤＢ内の取扱商品テーブル１２ａは、図４に例示するように、取扱商品ごとに「code（商品コード）、name（商品名）」の各要素のデータを相互に対応付けて構成される。
【００３８】
在庫ＤＢI１３は、上記の取扱商品の在庫に係る情報を記憶するＤＢであり、ＤＢ内の
在庫テーブルI１３ａは、図４に例示するように、取扱商品ごとに「code（商品コード）
、quantity（在庫数量）」の各要素のデータを相互に対応付けて構成される。同様に、在庫ＤＢII１４も、上記の取扱商品の在庫に係る情報を記憶するＤＢであるが、ＤＢ内の在
庫テーブルII１４ａは、図４に例示するように、取扱商品ごとに「item_code（商品コー
ド）、item_quantity（在庫数量）」の各要素のデータを相互に対応付けて構成される。
【００３９】
ここで、上記の注文伝票上では、商品の種類は商品コードでしか記述されていないが、人間が注文伝票を見るときには商品名で表示された方が見やすい。そこで、商品ＤＢ１２の取扱商品テーブル１２ａを用いて注文伝票の商品コードを商品名に変換したいとユーザが考えたような場合に、本実施例１によるデータベース統合参照システムを利用するメリットがある。
【００４０】
また、注文伝票を見ながらその注文を処理するときに、同時に在庫数も表示させて在庫を確認したいとユーザが考えたような場合にも、本実施例１によるデータベース統合参照システムを利用するメリットがある（なお、この場合には、各商品の在庫数を在庫ＤＢから取ってくることになるが、各商品の在庫数は商品によって在庫ＤＢI若しくは在庫ＤＢ
IIのどちらかに分かれて格納されているので両者に在庫数を問い合わせることになる）。
このように、ユーザは、上記した４つのデータベースに分散している１つの注文に関連するデータを、１つに纏めて参照したいような場合に、本実施例１によるデータベース統合参照システムを利用するメリットがある。
【００４１】
図３に戻って、ユーザ端末１０は、データベース統合参照装置２０を介して複数のデータベースに対するデータ参照の問い合わせを行うユーザの端末であり、既知のパーソナルコンピュータやワークステーション、ＰＤＡ、あるいは携帯電話やＰＨＳの如き移動体通信端末などで構成される。
【００４２】
そして、ユーザ端末１０は、主として、図１や図２に例示したように、ＸＱｕｅｒｙというＸＭＬ問い合わせ言語で記述された問い合わせ（ＸＱｕｅｒｙ問い合わせ）をキーボードやマウス等を介してユーザに入力させる役割、入力されたＸＱｕｅｒｙ問い合わせをデータベース統合参照装置２０に送信する役割、データベース統合参照装置２０からＸＭＬ形式の問い合わせ結果を受信する役割、受信した問い合わせ結果をモニタ等に出力する役割などを有する。
【００４３】
なお、図２に例示したように、実施例１に係るデータベース統合参照システムによって、ユーザには、各注文に関する情報が１つに纏められて、それがｏｒｄｅｒタグで囲まれて、１枚の大きなＸＭＬファイルの中に全ての注文が並んで格納されているように見える。ただし、これはあくまでも論理的なビューであって、データの実体は各データベースの中にしかない。そのような論理的なビューが存在すると思って、ユーザがデータベース統合参照装置２０に問い合わせを行うと、該当する注文の分のＸＭＬデータが返ってくる。
【００４４】
図３に戻って、データベース統合参照装置２０は、ユーザ端末１０から受け付けたデータ参照の問い合わせを処理する既知のサーバコンピュータであり、主として、ユーザ端末１０からＸＱｕｅｒｙ問い合わせを受信する役割、各データベースから問い合わせに係るデータを取得してＸＭＬの問い合わせ結果を生成する役割、生成したＸＭＬの問い合わせ結果をユーザ端末１０に送信する役割などを有する。以下に、本実施例１の主たる特徴を担うデータベース統合参照装置２０の構成を詳細に説明する。
【００４５】
［データベース統合参照装置の構成］
データベース統合参照装置２０は、図３に例示するように、記憶部２１と、制御部２２とを備えて構成される。このうち、記憶部２１は、制御部２２による各種処理に必要なデータおよびプログラムを記憶する手段であり、特に本発明に密接に関連するものとしては、同図に例示するように、統合用メタデータ２１ａをリポジトリに記憶する。
【００４６】
かかる統合用メタデータ２１ａは、各データベースを統合するために必要な情報が規定されたものであるが、具体的には、図６〜図１１に例示するように、仮想ＸＭＬスキーマ情報、データベース情報、並びに、要素間の関連付け情報が記載されて構成される。
【００４７】
より詳細には、仮想ＸＭＬスキーマ情報としては、図６に例示するように、複数のデータベースに跨る関連データを、どのようなフォーマットのＸＭＬデータとしてユーザに見せるかという情報が規定される。また、データベース情報としては、図７〜図１０に例示するように、ＸＭＬの中の各要素（図６参照）に、どのデータベースのどの要素が対応するのかという情報が規定される。さらに、要素間の関連付け情報としては、図１１に例示するように、異なるテーブルの異なるレコード同士を関連付けて１つのＸＭＬとする場合に、各テーブルのどのカラムでそれぞれ対応をとるか（関連付けるか）という情報が規定される。なお、図６〜図１１に分けて例示した統合用メタデータは、１つの統合用メタデータであり、１つのＸＭＬ形式のファイルである。
【００４８】
このような統合用メタデータ２１ａを記憶部２１は予め記憶するが、かかる統合用メタデータは、システムの管理者等によるマッピング作業（図５参照）を通じて作成される。すなわち、図５に例示するマッピング例は、図４に例示した４つのデータベースのデータを、ＸＭＬの木構造にマッピングした例であるが、このようなマッピング作業をシステム管理者等が行うことで、統合用メタデータ２１ａには、図５に例示する内容と同内容の情報がＸＭＬ形式で記述され、そして、ユーザには、統合されたデータが図５に例示するフォーマットのＸＭＬデータとして見えることになる。
【００４９】
なお、データベースのデータをＸＭＬの木構造にマッピングする手法（ルール）は以下の通りである。（１）ユーザには、データベースを跨って１つに組み合わされたデータが、１つのＸＭＬの中にデータ数だけ反復して入っているように見える。（２）統合したいデータベースのデータを、テーブル単位でＸＭＬのエレメントにマッピングする。（３）テーブルに対応するＸＭＬのエレメントは、階層的に配置することができる。（４）テーブルに対応するＸＭＬのエレメントのうち、階層構造上で上下に隣接するエレメント同士は、対応するテーブル同士でデータが関連付けできる必要がある。つまり、お互いのテーブル同士で、ある1つのカラム同士が同じ値を取らなければならない。（５）１つのＸＭＬエレメントに対応するテーブルは、別個のデータベースの別個のテーブルを複数指定しても構わない。（６）データベースのカラムに対応するＸＭＬのタグ名は、カラム名とは別の名前にしても構わない。
【００５０】
図３に戻って、データベース統合参照装置２０の制御部２２は、ＯＳ（Operating System）などの制御プログラム、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有し、これらによって種々の処理を実行する処理部であり、特に本発明に密接に関連するものとしては、同図に例示するように、問い合わせパーザ部２２ａと、問い合わせ処理部２２ｂと、アクセス処理部２２ｃとを備える。
【００５１】
このうち、問い合わせパーザ部２２ａは、ユーザ端末１０から受け付けたＸＱｕｅｒｙ問い合わせを構文解析し、構文チェックを行った後に、問い合わせ内容を内部形式へ変換する処理部である。なお、構文規則に反する問い合わせについては、その旨のエラーメッセージをユーザ端末１０に返信する。
【００５２】
問い合わせ処理部２２ｂは、問い合わせパーザ部２２ａで変換されたＸＱｕｅｒｙ問い合わせを実際に処理し、各データベースに対して必要な問い合わせを行ってデータを取得するとともに、ＸＭＬで問い合わせ結果を生成してユーザ端末１０に返信する処理部である。すなわち、各データベースへどのような順番でどのような問い合わせを行ってデータを獲得するかを計画し（各データベースに対して問い合わせをするＳＱＬを生成し）、それを実行する（生成したＳＱＬをデータベースに投げて結果を得る）。そして、問い合わせた結果として各データベースから取得したデータを、最終的にユーザ端末１０に返信するＸＭＬデータへと組み立てる。なお、問い合わせ処理部２２ｂによる具体的な処理内容については、図１３等を用いて後に詳述する。
【００５３】
アクセス処理部２２ｃは、問い合わせ処理部２２ｂからデータベースへの問い合わせ要求が行われると、実際にデータベースへアクセスする処理部である。具体的には、実施例１では、複数の異種のデータベースにアクセスするために、図１２に例示するような、従来型の問い合わせ型データベース統合である「Globus Toolkit 3 + OGSA-DAI」を利用してアクセス処理を実行する。
【００５４】
［問い合わせ処理の手順］
次に、図１３〜図２３を用いて、データベース統合参照装置２０による問い合わせ処理の手順を説明する。図１３は、実施例１による問い合わせ処理の手順を示すフローチャートであり、図１４〜図２３は、かかる問い合わせ処理手順の具体例を示す図である。
【００５５】
図１３に例示するように、データベース統合参照装置２０は、ユーザ端末１０から図２に例示したようなＸＱｕｅｒｙ問い合わせの入力があると（ステップＳ１３０１肯定）、ＸＱｕｅｒｙ問い合わせを構文解析し、構文チェックを行った後に、問い合わせ内容を内部形式へ変換する（ステップＳ１３０２）。なお、構文規則に反する場合には、その旨のエラーメッセージをユーザ端末１０に返信する。
【００５６】
続いて、データベース統合参照装置２０は、問い合わせに関係する統合用メタデータを記憶部２１から読み込んで、問い合わせ対象となっているＸＭＬの構造と、その各エレメントに対応するデータがどのデータベースに格納されているかを求める（ステップＳ１３０３）。
【００５７】
具体的には、図１４に例示するように、図２に例示したようなＸＱｕｅｒｙ問い合わせについては、「order-list.xml」に対応する統合用メタデータを記憶部２１から読み出し、かかるＸＭＬの構造と、その各エレメントに対応するデータが格納されているデータベースとを求めることで、図１４に例示するような木構造で表現可能な情報を得る。
【００５８】
そして、データベース統合参照装置２０は、問い合わせ順序の最適化として、ステップＳ１３０３で得たＸＭＬ構造の各エレメントを、そのデータが格納されているデータベースごとに分けて、それぞれに対してユーザがＸＱｕｅｒｙ問い合わせの中で指定した条件文を検討し、最もデータが絞り込めそうなデータベースを決定する（ステップＳ１３０４）。
【００５９】
具体的には、図１５に例示するように、ＸＱｕｅｒｙ問い合わせに含まれる「nama="FMV-6000CL"」という条件と「quantity>=2」という条件について、商品テーブルと商品取扱テーブルのどちらに最初に問い合わせを行った方が問い合わせ結果としてのデータ量が少なくなるかを予測し、データ量が少なくなると予測されたテーブルに対する問い合わせを最初に行うことを決定する。なお、同図では、取扱商品テーブルに対して最初に問い合わせることを決定した例を示しているが、かかる問い合わせ順序の最適化手法については、後に詳述する。
【００６０】
その後、データベース統合参照装置２０は、ステップＳ１３０４で決定された最初のデータベースに対して条件に合致するデータを問い合わせるためのＳＱＬ問い合わせを作成し（ステップＳ１３０５）、かかるＳＱＬ問い合わせを当該データベースに投げて、問い合わせ結果を得る（ステップＳ１３０６）。ただし、この時点でデータベースから求める値は、上位のエレメントと関連付けられているカラムだけでよい。
【００６１】
具体的には、図１６に例示するように、「nama="FMV-6000CL"」という条件に合致するデータを商品ＤＢの取扱商品テーブルに問い合わせるためのＳＱＬ問い合わせを生成して、これを商品ＤＢに投げることで、商品ＤＢの取扱商品テーブルから条件に合致するデータとして「code=034564」を含んだ問い合わせ結果を得る。
【００６２】
続いて、データベース統合参照装置２０は、前のデータベースへの問い合わせ結果を使って、順番にＸＭＬの木構造の中で上位のエレメントを求めるＳＱＬ問い合わせを生成し、かかるＳＱＬ問い合わせを該当のデータベースに投げて問い合わせ結果を得るという処理（ステップＳ１３０７およびＳ１３０８）を、ＸＭＬの木構造の最上位のエレメントが求まるまで行って、データベースへの問い合わせを開始したエレメントから、次々と上位のエレメントに対応するデータの値を求めていく（ステップＳ１３０９）。
【００６３】
かかる処理においては、前の問い合わせ結果との関連付けを、データ絞り込みの条件として用いるとともに、ＸＱｕｅｒｙ問い合わせでユーザが指定した条件があれば、それもデータ絞込みの条件に加える。また、上下で隣接するエレメント同士について、それに対応するテーブルが同じデータベースのものであれば、ＲＤＢＭＳ（リレーショナル・データベース・マネージメント・システム）にジョイン処理を任せるために、１つのＳＱＬ問い合わせで纏めて問い合わせを行う。さらに、データベースから求める値は上位のエレメントと関連付けられているカラムだけでよいが、最上位のエレメントに達した場合は、その最上位のエレメントに対応する全てのカラムを求める。
【００６４】
具体的には、図１７に例示するように、前の問い合わせ結果として得た「code=034564」の関連付けから、受注ＤＢに対する問い合わせを次に行うことを決定した後、かかる「code=034564」という条件と、ＸＱｕｅｒｙ問い合わせでユーザが指定した条件で未だ反映されていない「quantity>=2」という条件に合致するデータを問い合わせるためのＳＱＬ問い合わせを生成する。
【００６５】
ただし、このＳＱＬ問い合わせの生成に際しては、同図に例示するように、関連付けに係る２つのエレメント「order_id」の両方が受注ＤＢ上のテーブルであるので、１つのＳＱＬで同時に問い合わせるためのＳＱＬ問い合わせを生成する。そして、生成したＳＱＬ問い合わせを受注ＤＢに投げることで、注文伝票テーブルから条件に合致するデータとして「（order_id、customer、supplier、order_date）=（121、AsianTraders、Fujitsu、2003-07-25）」を含んだ問い合わせ結果を得る。なお、同図に示す例では、最上位のエレメントに達しているので、ここでは、その最上位のエレメントに対応する全てのカラムを求めている。
【００６６】
続いて、データベース統合参照装置２０は、ＸＭＬの最上位のエレメントが求まれば（ステップＳ１３０９肯定）、そこから下位のエレメントを順に全て求めるＳＱＬ問い合わせを生成し、かかるＳＱＬ問い合わせを該当のデータベースに投げて問い合わせ結果を得るという処理（ステップＳ１３１０およびＳ１３１１）を、ＸＭＬの木構造の最上位から下位の全てのエレメントが求まるまで行って、次々と下位のエレメントに対応するデータの値を求めていく（ステップＳ１３１２）。かかる処理に際しては、上位のエレメントの問い合わせ結果との関連付けを、データ絞込みの条件として指定する。また、データベースから求める値としては、エレメントに対応付けられている全てのカラムを求める。
【００６７】
具体的には、図１８に例示するように、「order_id=121」という条件に合致するデータを受注ＤＢの商品テーブルに問い合わせるためのＳＱＬ問い合わせを生成し、これを商品テーブルに投げることで、「（order_id、item_code、quantity）=（121、034564、2）、（121、087245、5）、（121、063200、10）」という問い合わせ結果を得る。続いて、図１９に例示するように、上記の問い合わせ結果から「（code=034564）or（code=087245）or（code=063200）」という条件に合致するデータを商品ＤＢの取扱商品テーブルに問い合わせるためのＳＱＬ問い合わせを生成し、これを取扱商品テーブルに投げることで、「（code、name）=（034564、FMV-6000CL）、（087245、FMV-6000CL2）、（063200、FMV6667CX5）」という問い合わせ結果を得る。
【００６８】
さらに、図２０に例示するように、上記の問い合わせ結果から「（code=034564）or（code=087245）or（code=063200）」という条件に合致するデータを在庫ＤＢIの在庫テ
ーブルIに問い合わせるためのＳＱＬ問い合わせを生成し、これを在庫テーブルIに投げ
ることで、「（code、quantity）=（034564、38）、（063200、22）」という問い合わせ結果を得る。また、これと同様に、図２１に例示するように、「（item_code=034564）or（item_code=087245）or（item_code=063200）」という条件に合致するデータを在庫ＤＢIIの在庫テーブルIIに問い合わせるためのＳＱＬ問い合わせを生成し、これを在庫テーブ
ルIIに投げることで、「（item_code、item_quantity）=（087245、3）」という問い合わせ結果を得る。
【００６９】
そして、データベース統合参照装置２０は、上記してきた処理によって全てのエレメントのデータ値が求まれば（ステップＳ１３１２肯定）、図１５に例示するように、ＸＭＬの木構造を上から辿りながら、得られたデータ値から問い合わせ結果のＸＭＬを組み立てる（ステップＳ１３１３）。ここで、この時点で、未だユーザからのＸＱｕｅｒｙ問い合わせで指定した問い合わせ条件の一部が反映されていない可能性もあるので、データベース統合参照装置２０は、問い合わせ条件を満たさない解をチェックして最終結果のＸＭＬから除外してＸＭＬを組み立てる（ステップＳ１３１４）。その後、データベース統合参照装置２０は、図２３に例示するように、問い合わせ結果のＸＭＬを生成して出力する（ステップＳ１３１５）。
【００７０】
上記した一連の処理を経ることによって、ＸＱｕｅｒｙ問い合わせを行ったユーザ端末１０に対して、ＸＭＬ形式のデータが問い合わせ結果として返信される。なお、上記したステップＳ１３０７〜Ｓ１３１２で、一度最上位のエレメントまで上がってから、再び下位のエレメントを問い合わせし直しており、同じデータベースに二度問い合わせを行っている点で一見すると無駄なように思えるが、これは、そうしなければＸＭＬデータの一部が欠けてしまう可能性があるからである。すなわち、例を挙げれば、図１６では「FMV-6000CL」に対する「code」だけを求めているが、最終的な結果で必要なのは、図２２に例示するように、「order_id」が「121」の注文伝票で注文された３つの商品の「code」と「name」である。そして、これは、一旦最上位のエレメントを求めて「order_id」が確定するまでは求めることができないからである。
【００７１】
［問い合わせ順序の最適化手法］
続いて、上記の問い合わせ処理手順で説明した問い合わせ順序の最適化手法（図１３のステップＳ１３０４に係る処理）を詳細に説明する。問い合わせ型データベース統合が抱える潜在的な問題点として、データベースのデータをネットワーク経由で取得するので、ローカルにデータを保持している場合に比べて、データへのアクセス速度が遅くなり、ネットワーク負荷も大きくなる点が挙げられる。
【００７２】
そして、実施例１におけるデータベース統合参照装置２０では、複数のデータベースから関連するデータを順番に取得していく場合に、最初に取得するデータはユーザの問い合わせで指定された条件によって絞り込み、以降に取得するデータは前に取得したデータとの関連付けとユーザの指定した条件の両方を用いて絞り込むことにしている。このため、データの絞込みが足りないと、データベースに問い合わせをした結果として大量のデータが返ってきてしまい、データ転送に時間を要するばかりか、ネットワーク負荷を増大させてしまう。
【００７３】
これを具体的に説明すると、図１４に例示したように、ユーザからの問い合わせにはデータを絞り込むための条件が２つ書かれている。１つ目は「商品名がFMV-6000CLであること」であり、２つ目は「その商品の発注数が２つ以上であること」というものである。その一方で、商品名の情報は商品ＤＢの取扱商品テーブルに格納されており、発注個数の情報は受注ＤＢの商品テーブルに格納されている。このため、データベース統合参照装置２０は、最初にどちらのデータベースに対してＳＱＬ問い合わせを発行するかを決定する必要がある。
【００７４】
ここで、最初の問い合わせの結果データが多いと、その結果データを用いて行う次の問い合わせの結果データも多くなり、ユーザに返される最終的な問い合わせ結果は同じでも、途中でデータベース統合参照装置２０に集められるデータの量が増えてしまい、データ転送に時間がかかってユーザへの応答に時間がかかるばかりが、ネットワークの負荷も増大させてしまう。そこで、データベース統合参照装置２０は、最初にどちらのデータベースに対してＳＱＬ問い合わせを発行すれば、その問い合わせの結果データを少なくすることができるかを検討した上で、最初に問い合わせを開始するデータベースを決定する。そして、これについては、各データベースからデータベース自身のメタデータ（統合用メタデータとは異なる。）を取得した後に、以下の（１）〜（４）の事項を考慮して行われる。
【００７５】
（１）データの冗長性に関する制約条件
データベースのメタデータを参照し、ＸＱｕｅｒｙ問い合わせで条件付けが行われているカラムが、そのテーブルの主キーになっていないか、またはユニーク制約が設定されていないかを確認する。そのいずれかであれば、そのカラムはデータの重複が無いので、データを絞り込める可能性が高くなるからである。
【００７６】
（２）データ数
データベースのメタデータを参照し、テーブル内のレコード数が多いか確認する。テーブル内のレコード数が多いと、問い合わせの結果として返ってくるレコードの数も多くなる可能性が高いからである。
【００７７】
（３）データの型と桁数
データベースのメタデータを参照し、カラムのデータ型が数字や真偽値などの種類の少ないものであったり、桁数が少なかったりしていないかを確認する。この場合には、そのカラムは重複するデータが多くなる可能性が高いので、問い合わせの結果として多くのレコードが返ってくる可能性が高いからである。
【００７８】
（４）ユーザの指定した条件式の条件指定の種類
ＸＱｕｅｒｙ問い合わせ内の条件式が等号で指定されているか、不等号で指定されいるかを確認する。等号で指定されている場合は、不等号で指定されている場合よりもデータを絞り込める可能性が高いからである。
【００７９】
データベース統合参照装置２０は、上記した４つの条件をそれぞれ満たしているかどうかを調べ、その結果によって各問い合わせの条件について点数付けを行い、最も点数の高い条件に係るデータベースから問い合わせを開始する。なお、図１５に示した例は、「nama="FMV-6000CL"」という条件を取扱商品テーブルに対して最初に問い合わせる方が、データを絞り込める可能性が高いと判定された場合の例である。
【００８０】
上記したような最適化手法によって問い合わせを開始するデータベースを決定した後は、上記の問い合わせ処理手順で説明したように、関連付け情報を利用して、一旦ＸＭＬの最上位のエレメントへ向けて次々と上隣のエレメントを求めてゆく。ここで、ＸＱｕｅｒｙ問い合わせ内の他の問い合わせ条件に対応するデータベースに対しても同時にＳＱＬ問い合わせを行って、それらの結果をジョインするという手法も考えられるが、その場合には、各データベースから返ってくる結果データが非常に多くなる可能性があるので、本実施例ではかかる手法を採用していない。
【００８１】
［実施例１による効果等］
上述してきたように、実施例１によれば、データベースへの共通アクセス手段を提供するだけでなく、そのさらに上位にタグ付き文書という形のビューを用意する。すなわち、ユーザには複数のデータベースに跨っている関連データ全体をタグ付き文書と仮想させ、そのタグ付き文書の一部を切り出す問い合わせを行った結果として、タグ付き文書が返るという形でデータの参照を行う。また、ユーザから問い合わせが行われると、予め用意されている統合用メタデータに基づいて、どのような順番でどのデータベースからどのような問い合わせでデータを獲得していけばよいかを判断し、それに基づいて必要なデータを獲得して、獲得されたデータをタグ付き文書として組み立ててユーザに返す。これによって、ユーザはデータの格納構造を気にする必要がなくなり、各データがどのデータベースに格納されているのかを全く意識せずに済むので、複数のデータベースがあたかも１つであるかのように扱うことが可能になる。
【００８２】
また、実施例１によれば、同種のデータが複数のデータベースに分かれて格納されていて、ある１つの値を持つデータに関していずれのデータベースに格納されているか分からないような場合においても、ユーザがタグ付き文書の問い合わせを行うと、データベース統合参照装置２０が統合用メタデータに基づいてデータが格納されている可能性のあるデータベース全てに問い合わせを行い、データを自動的に見つけてくる。これによって、ユーザは複数のデータベースからデータを探す作業をする必要がなくなるので、複数のデータベースがあたかも１つであるかのように扱うことが可能になる。
【００８３】
また、実施例１によれば、データベースからデータを獲得する際に、データベースのメタ情報や問い合わせ内容を利用して、問い合わせ結果がなるべく少なくなる問い合わせ計画を作成し、その計画に基づいて各データベースから順番にデータを獲得してくる。このように、問い合わせ順番を操作して結果データを絞り込んでいくことによって、データ転送量を減らして、問い合わせにかかる時間を短縮するとともに、ネットワークにかかる負担も軽減することが可能になる。
【００８４】
また、実施例１によれば、問い合わせを開始するデータベースを決定した後に、タグ付き文書の木構造の中で、最初にデータ値を求めたエレメントから次々と上位のエレメントに対応するデータ値を求めていき、最上位のエレメントのデータ値が求まったら、次にそこから順番に下位のエレメントを辿りながら全て求めていく。そして、この手順は、タグ付き文書の構造の定義や問い合わせの内容に関わらず、常に同じである。これによって、タグ付き文書の構造定義や問い合わせの内容に関わらず、問い合わせ結果としてのタグ付き文書全体を洩れなく求めることが可能になるとともに、データベースへの問い合わせの回数を少なく抑えることが可能になる。
【実施例２】
【００８５】
さて、これまで本発明の実施例１について説明したが、本発明は上述した実施例１以外にも、特許請求の範囲に記載した技術的思想の範囲内において種々の異なる形態にて実施されてよいものである。そこで、以下では実施例２として、（１）タグ付き文書、（２）データベース、（３）統合用メタデータ、（４）アクセス処理、（５）システム構成等、（６）プログラム、にそれぞれ区分けして種々の異なる実施例を説明する。
【００８６】
（１）タグ付き文書
例えば、実施例１では、タグ付き文書としてＸＭＬを利用する場合を説明したが、本発明はこれに限定されるものではなく、例えば、ＳＧＭＬなど、他のタグ付き文書を利用するようにしてもよい。
【００８７】
また、実施例１では、ＸＭＬに対する問い合わせに、現在Ｗ３Ｃで標準化作業が進行中の問い合わせ言語「ＸＱｕｅｒｙ」を利用する場合を説明したが、本発明はこれに限定されるものではなく、例えば、ＸＰａｔｈなど、他の問い合わせ言語を利用するようにしてもよい。
【００８８】
（２）データベース
また、実施例１では、リレーショナル型のデータベースを統合する場合を説明したが、本発明はこれに限定されるものではなく、他の型のデータベースを統合する場合にも本発明を同様に適用することができる。
【００８９】
（３）統合用メタデータ
また、実施例１では、一つの統合用メタデータを用意する場合を説明したが、本発明はこれに限定されるものではなく、データベースの統合の仕方に応じて複数の統合用メタデータを用意するようにしてもよい。例えば、問い合わせ結果の出力態様に応じて複数用意することなどが考えられる。
【００９０】
（４）アクセス処理
また、実施例１では、複数の異種のデータベースにアクセスするために、Globus Toolkit 3 + OGSA-DAIを利用する場合を説明したが、本発明はこれに限定されるものではなく、複数の異種のデータベースへどのようにして問い合わせを行うかは問わず、如何なる手法でアクセスしてもよい。
【００９１】
（５）システム構成等
また、図示した各装置（特に、データベース統合参照装置２０）の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【００９２】
また、実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【００９３】
（６）プログラム
ところで、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、上記の実施例と同様の機能を有するプログラムを実行するコンピュータシステムを他の実施例として説明する。
【００９４】
図２４は、他の実施例に係るコンピュータシステムの構成を示すシステム構成図であり、図２５は、このコンピュータシステムにおける本体部の構成を示すブロック図である。図２４に示すように、このコンピュータシステム１００は、本体部１０１と、本体部１０１からの指示によって表示画面１０２ａに画像などの情報を表示するためのディスプレイ１０２と、このコンピュータシステム１００に種々の情報を入力するためのキーボード１０３と、ディスプレイ１０２の表示画面１０２ａ上の任意の位置を指定するためのマウス１０４とを備える。
【００９５】
また、このコンピュータシステム１００における本体部１０１は、図２５に示すように、ＣＰＵ１２１と、ＲＡＭ１２２と、ＲＯＭ１２３と、ハードディスクドライブ（ＨＤＤ）１２４と、ＣＤ−ＲＯＭ１０９を受け入れるＣＤ−ＲＯＭドライブ１２５と、フレキシブルディスク（ＦＤ）１０８を受け入れるＦＤドライブ１２６と、ディスプレイ１０２、キーボード１０３並びにマウス１０４を接続するＩ／Ｏインターフェース１２７と、ローカルエリアネットワークまたは広域エリアネットワーク（ＬＡＮ／ＷＡＮ）１０６に接続するＬＡＮインターフェース１２８とを備える。
【００９６】
さらに、このコンピュータシステム１００には、インターネットなどの公衆回線１０７に接続するためのモデム１０５が接続されるとともに、ＬＡＮインターフェース１２８およびＬＡＮ／ＷＡＮ１０６を介して、他のコンピュータシステム（ＰＣ）１１１、サーバ１１２並びにプリンタ１１３などが接続される。
【００９７】
そして、このコンピュータシステム１００は、所定の記録媒体に記録されたプログラムを読み出して実行することで上記した実施例と同様の機能を実現する。ここで、所定の記録媒体とは、フレキシブルディスク（ＦＤ）１０８、ＣＤ−ＲＯＭ１０９、ＭＯディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」の他に、コンピュータシステム１００の内外に備えられるハードディスクドライブ（ＨＤＤ）１２４や、ＲＡＭ１２２、ＲＯＭ１２３などの「固定用の物理媒体」、さらに、モデム１０５を介して接続される公衆回線１０７や、他のコンピュータシステム１１１並びにサーバ１１２が接続されるＬＡＮ／ＷＡＮ１０６などのように、プログラムの送信に際して短期にプログラムを保持する「通信媒体」など、コンピュータシステム１００によって読み取り可能なプログラムを記録する、あらゆる記録媒体を含むものである。
【００９８】
すなわち、この他の実施例でいうプログラムは、上記した「可搬用の物理媒体」、「固定用の物理媒体」、「通信媒体」などの記録媒体に、コンピュータ読み取り可能に記録されるものであり、コンピュータシステム１００は、このような記録媒体からプログラムを読み出して実行することで上記した実施例と同様の機能を実現する。なお、この他の実施例でいうプログラムは、コンピュータシステム１００によって実行されることに限定されるものではなく、他のコンピュータシステム１１１またはサーバ１１２がプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。
【産業上の利用可能性】
【００９９】
以上のように、本発明に係るデータベース統合参照装置、データベース統合参照方法およびデータベース統合参照プログラムは、複数のデータベースに対するデータ参照の問い合わせを受け付け、各データベースから問い合わせに係るデータを取得する場合に有用であり、特に、ユーザにデータの分散を意識させないようにすることに適する。
【図面の簡単な説明】
【０１００】
【図１】実施例に係るデータベース統合参照システムの概要および特徴を説明するための図である。
【図２】実施例に係るデータベース統合参照システムの概要および特徴を説明するための図である。
【図３】実施例１に係るデータベース統合参照システムの全体構成を示すシステム構成図である。
【図４】各ＤＢに記憶される情報の構成例を示す図である。
【図５】ＸＭＬへのマッピング例を示す図である。
【図６】統合用メタデータ（特に、仮想ＸＭＬスキーム情報）の構成例を示す図である。
【図７】統合用メタデータ（特に、データベース情報）の構成例を示す図である。
【図８】統合用メタデータ（特に、データベース情報）の構成例を示す図である。
【図９】統合用メタデータ（特に、データベース情報）の構成例を示す図である。
【図１０】統合用メタデータ（特に、データベース情報）の構成例を示す図である。
【図１１】統合用メタデータ（特に、要素間の関係付け情報）の構成例を示す図である。
【図１２】アクセス処理の手法を示す図である。
【図１３】実施例１による問い合わせ処理の手順を示すフローチャートである。
【図１４】問い合わせ処理手順の具体例を示す図である。
【図１５】問い合わせ処理手順の具体例を示す図である。
【図１６】問い合わせ処理手順の具体例を示す図である。
【図１７】問い合わせ処理手順の具体例を示す図である。
【図１８】問い合わせ処理手順の具体例を示す図である。
【図１９】問い合わせ処理手順の具体例を示す図である。
【図２０】問い合わせ処理手順の具体例を示す図である。
【図２１】問い合わせ処理手順の具体例を示す図である。
【図２２】問い合わせ処理手順の具体例を示す図である。
【図２３】問い合わせ処理手順の具体例を示す図である。
【図２４】他の実施例に係るコンピュータシステムの構成を示すシステム構成図である。
【図２５】図２４に示したコンピュータシステムにおける本体部の構成を示すブロック図である。
【図２６】従来技術を説明するための図である。
【符号の説明】
【０１０１】
１０  ユーザ端末
１１  受注ＤＢ
１１ａ  注文伝票テーブル
１１ｂ  商品テーブル
１２  商品ＤＢ
１２ａ  取扱商品テーブル
１３  在庫ＤＢI
１３ａ  在庫ＤＢI
１４  在庫ＤＢII
１４ａ  在庫テーブルII
２０  データベース統合参照装置
２１  記憶部
２１ａ  統合用メタデータ
２２  制御部
２２ａ  問い合わせパーザ部
２２ｂ  問い合わせ処理部
２２ｃ  アクセス処理部
１００  コンピュータシステム
１０１  本体部
１０２  ディスプレイ
１０２ａ  表示画面
１０３  キーボード
１０４  マウス
１０５  モデム
１０６  ＬＡＮ／ＷＡＮ
１０７  公衆回線
１０８  ＦＤ
１０９  ＣＤ−ＲＯＭ
１１１  ＰＣ
１１２  サーバ
１１３  プリンタ
１２１  ＣＰＵ
１２２  ＲＡＭ
１２３  ＲＯＭ
１２４  ＨＤＤ
１２５  ＣＤ−ＲＯＭドライブ
１２６  ＦＤドライブ
１２７  Ｉ／Ｏインターフェース
１２８  ＬＡＮインターフェース
【図１】
2005208757.tif 000003
【図２】
2005208757.tif 000004
【図３】
2005208757.tif 000005
【図４】
2005208757.tif 000006
【図５】
2005208757.tif 000007
【図６】
2005208757.tif 000008
【図７】
2005208757.tif 000009
【図８】
2005208757.tif 000010
【図９】
2005208757.tif 000011
【図１０】
2005208757.tif 000012
【図１１】
2005208757.tif 000013
【図１２】
2005208757.tif 000014
【図１３】
2005208757.tif 000015
【図１４】
2005208757.tif 000016
【図１５】
2005208757.tif 000017
【図１６】
2005208757.tif 000018
【図１７】
2005208757.tif 000019
【図１８】
2005208757.tif 000020
【図１９】
2005208757.tif 000021
【図２０】
2005208757.tif 000022
【図２１】
2005208757.tif 000023
【図２２】
2005208757.tif 000024
【図２３】
2005208757.tif 000025
【図２４】
2005208757.tif 000026
【図２５】
2005208757.tif 000027
【図２６】
2005208757.tif 000028