入力する問い合わせに基づいて、それぞれデータ形式が異なる複数のデータベースに分散されたデータを取得し、取得したデータを第一の形式のビューに統合して出力する機能をコンピュータに実行させる、データベース統合参照プログラムにおいて、第1の形式による問い合わせの入力を受け付け、前記受け付けた問い合わせを内部形式に変換し、複数のデータベースにまたがる関連データの出力形式を示す情報と、第一の形式による文書の要素と前記複数のデータベースそれぞれの要素との対応関係を示す情報と、前記複数のデータベース間の要素の対応関係を示す情報とを参照して、問い合わせ対象の第一の形式による文書の構造と、前記第一の形式による文書の各要素に対応するデータベースを判別し、判別したデータベースに、問い合わせ条件に合致するデータを問い合わせ、前記問い合わせの結果得られたデータを、第一の形式の文書に組み立て、組み立てた文書を問い合わせ結果として返信することを特徴とする、データベース統合参照プログラム。しかしながら、最近では、データベースの種別が多様化し、従来のRDBとは異なるデータベースが登場してきている。例えば、XMLeXtensibleMarkupLanguage形式でデータを保持するXML-DBeXtensibleMarkupLanguageDataBaseなどである。よって、分散型データベースが、XML-DB等のRDBとは異なるデータベースを含んで構成され得ることとなってきている。前述のXML-DBは、スキーマが不定又は半固定であるために、このスキーマに基づいて定義した統合データビューのスキーマが不定になる。一方で、RDBは、スキーマが厳格に定められる。このために、上記特許文献1に代表される従来技術を利用したとしても、統合データビューのスキーマが不定となり得るという性質上、XML-DB及びRDBを含む複数のDBに対して該統合データビューを使用した問い合わせ処理が不可能となるという問題があった。このように、データベースの種別の多様化によって、分散する各データベースの種別の差異のために、統合データビューを使用した問い合わせ処理が不可能となるという問題が発生することとなる。また、XML-DBに格納されているデータのスキーマと、ユーザが望む統合データビュー上のスキーマとは一致するとは限らない。XML-DBから取得したXML文書データをそのまま統合データビューの中に当てはめるのでは、ユーザが望む統合データビューを提供できない場合が発生する。一つの側面では、分散する各データベースの種別の差異を吸収して、ユーザが望む統合データビューを使用した問い合わせ処理を可能とするデータベース統合参照プログラム等を提供することを目的とする。上述した問題を解決し、目的を達成するため、開示の技術は、入力する問い合わせに基づいて、それぞれデータ形式が異なる複数のデータベースに分散されたデータを取得し、取得したデータを第一の形式のビューに統合して出力する機能をコンピュータに実行させる、データベース統合参照プログラムにおいて、第1の形式による問い合わせの入力を受け付け、前記受け付けた問い合わせを内部形式に変換し、複数のデータベースにまたがる関連データの出力形式を示す情報と、第一の形式による文書の要素と前記複数のデータベースそれぞれの要素との対応関係を示す情報と、前記複数のデータベース間の要素の対応関係を示す情報とを参照して、問い合わせ対象の第一の形式による文書の構造と、前記第一の形式による文書の各要素に対応するデータベースを判別し、判別したデータベースに、問い合わせ条件に合致するデータを問い合わせ、前記問い合わせの結果得られたデータを、第一の形式の文書に組み立て、組み立てた文書を問い合わせ結果として返信することを特徴とする。開示の技術によれば、階層構造で一意に特定されるデータで問い合わせ結果を返却するデータベースを含む種別の異なる複数のデータベースに分散するデータを、各データベースに対する問い合わせ形式で問い合わせを行って取得した問い合わせ結果をビューに統合して出力することにより参照可能となり、データの分散を意識することなく問い合わせを行うことが可能になり、データベース開発作業の自由度が高くなるという効果を奏する。また、開示の技術によれば、予め構造が定められているタグ付き文書で問い合わせ結果を返却するタグ付き文書データベースを含む種別の異なる複数のデータベースに分散するデータを、各データベースに対する問い合わせ形式で問い合わせを行って取得した問い合わせ結果をビューに統合して出力することにより参照可能となり、データの分散を意識することなく問い合わせを行うことが可能になり、データベース開発作業の自由度が高くなるという効果を奏する。また、開示の技術によれば、タグ付き文書データベース内のタグ付き文書データに含まれる一定の繰り返し構造を記憶し、該記憶されている繰り返し構造に基づいて問い合わせ結果としてデータを取得することが可能となり、統合の対象となるタグ付き文書データベースの範囲が広がるという効果を奏する。また、開示の技術によれば、タグ付き文書データベースから返るタグ付き文書データのスキーマの中で、他のデータベースとの関連付けに使用できるノードを限定せず、関連付けに使用できるノードの選択肢が増え、統合データビューの設計の自由度が向上し、上位アプリケーション開発の自由度も向上するという効果を奏する。また、開示の技術によれば、統合データビューのスキーマに規定される要素の名称を、タグ付き文書データベースから返るタグ付き文書データのスキーマに規定される要素の名称に依存することなく定めることが可能となり、統合データビューのスキーマに規定される要素の名称を人が見やすい形式に定めることが可能となるという効果を奏する。また、開示の技術によれば、タグ付き文書データベースから返るタグ付き文書データのスキーマに存在しない要素を、統合データビューのスキーマに含めることが可能となり、統合データビューのスキーマを自由に決めることが可能となる。これによって、上位アプリケーション開発の自由度を大幅に向上させるという効果を奏する。また、開示の技術によれば、タグ付き文書データベースから返るタグ付き文書データのスキーマに存在する要素を、統合データビューのスキーマに含めないようにすることが可能となり、統合データビューのスキーマを自由に決めることが可能となる。これによって、上位アプリケーション開発の自由度を大幅に向上させるという効果を奏する。また、開示の技術によれば、タグ付き文書データベースから返るタグ付き文書データが不定である又は半構造性を持つ場合にも統合可能となるので、統合の対象となるタグ付き文書データベースの範囲が広がるという効果を奏する。以下に添付図面を参照して、開示の技術に係るデータベース統合参照プログラム等の実施例を詳細に説明する。なお、以下に示す実施例では、開示の技術を、XML-DBeXtensibleMarkupLanguageDataBaseとRDBRelationalDataBaseとを統合して参照可能とするデータベース統合参照プログラム、データベース統合参照方法及びデータベース統合参照装置に適用し、タグ付き文書をXML文書とした場合を示すこととする。なお、以下に、データベースをDBDataBaseと略記する場合がある。先ず、図1及び図2を用いて、実施例1に係るデータベース統合参照システムの概要および特徴を説明する。図1及び図2は、実施例1に係るデータベース統合参照システムの概要および特徴を説明するための図である。図1に示すように、実施例1に係るデータベース統合参照システムは、XML-DB及びRDBを含む複数のデータベースRDB1、RDB2及びXML-DBとユーザ端末との間にデータベース統合参照装置が介在して形成され、概略的には、このデータベース統合参照装置が、複数のデータベースに対するデータ参照の問い合わせをユーザ端末から受け付け、各データベースから問い合わせに係るデータを取得し、問い合わせ結果をユーザ端末に返すというものである。そして、かかるシステムのデータベース統合参照装置では、図1及び図2に示すように、統合用メタデータの利用によって、複数のデータベースに分散しているデータを統合して1つの仮想的なXML文書例えば、XMLファイルとしてユーザに意識させ、そのデータに対してXML文書に対する問い合わせ形式でデータ参照の問い合わせ例えば、XQueryというXML問い合わせ言語で記述された問い合わせを受け付け、統合されたデータをXML形式で取り出すことを特徴とする。より具体的には、データベース統合参照装置では、統合したDBのデータをXMLというモデルで提供するための統合問い合わせエンジンを構築し、分散しているデータをXMLファイルのようにハンドルすることで、データベース統合参照装置側でのデータビュー統合を実現する。このようなことから、実施例1に係るデータベース統合参照システムによれば、以下に列挙するように、リアルタイムなデータアクセス、上位アプリケーションの開発工数の大幅削減、自由度および拡張性が高いDB統合、段階的なメタデータ構築などが可能になる。すなわち、本実施例1では、分散しているデータをDWHデータウェアハウスのように物理的に一箇所に集めるのではなく、既存のDBに分散して配置された状態のまま、問い合わせ時に必要なデータだけを獲得し、結果として統合的なデータビューを作り上げる。これによって、リアルタイムなデータアクセスが可能になる。また、本実施例1では、分散しているデータをXML形式のファイルに統合するので、そのXMLファイルに対してXQueryで問い合わせを行い、問い合わせ結果もXML形式で取り出すことができる。つまり、上位アプリケーション側に対して、XMLファイルによって統合されたデータビューを提供することができるので、上位アプリケーション側でデータビュー統合のための機能を作りこむ必要がなくなり、これによって、上位アプリケーションの開発工数の大幅削減が可能になる。また、本実施例1では、XML-DB及びRDBを含む複数のデータベースのデータをモデル変換を経て、最終的にXMLファイルのデータビューに統合する。かかるXMLファイル形式は自由度および拡張性が高いので、この統合されたXMLファイルに対して柔軟な使い方が可能になる。即ち、本実施例1によるデータビューはXMLによって統合されているため、検索システムだけではなく、XMLに対応した様々なアプリケーションシステムを本実施例1に係るシステム上に容易に構築することができるなど、自由度および拡張性が高いDB統合が可能になる。また、本実施例1では、複数の分散しているデータからどのようなデータビューを構成するかを、統合用メタデータで自由に定義するが、その際、問い合わせに必要な情報のみで定義することができる。これによって、初めから全ての情報を定義しておく必要がなくなり、段階的に統合用メタデータを構築することが可能になる。次に、実施例1に係るデータベース統合参照システムの全体構成を説明する。図3は、実施例1に係るデータベース統合参照システムの全体構成を示すシステム構成図である。同図に示すように、実施例1に係るデータベース統合参照システムは、ユーザ端末10と、複数のデータベースXML-DB受注DB11、RDB1商品DB12、RDB2在庫DB13と、データベース統合参照装置20とを、LANやインターネットなどのネットワークを介して相互に通信可能に接続して構成される。このうち、各データベースは、実施例1によって統合されるデータベースである。実施例1では、受注DB11をXML-DBとし、商品DB12及び在庫DB13をRDBとする。実施例1では、図3に例示するように、受注DB11、商品DB12及び在庫DB13の3つのDBにデータが分散されている例を挙げている。ここで、受注DB11は、ある企業が受注した注文に係る情報を記憶するDBであり、DB内の注文伝票XML11aは、図4に例示するように、order注文に、id注文ID、purchaser購入者、item商品名、date受注年月日の各要素のデータを配下に持つ木構造となるように構成される。さらに、注文伝票XML11aは、order内のitemに、itemcode商品コード、quantity受注数量の各要素のデータを配下に持つ木構造となるように構成される。このようにしてorder配下に構成される木構造が、1件分の注文伝票に相当する受注レコードに相当する。なお、1件の注文には複数の注文商品が含まれ得るので、注文伝票XML11aの1レコードには、itemとその配下のitemcode及びquantityとで構成される部分木が繰り返して出現し得るものである。商品DB12は、上記の企業が取り扱う取扱商品に係る情報を記憶するDBであり、DB内の取扱商品テーブル12aは、図4に例示するように、取扱商品ごとにcode商品コード、name商品名の各要素のデータを相互に対応付けて構成される。在庫DB13は、上記の取扱商品の在庫に係る情報を記憶するDBであり、DB内の在庫テーブル13aは、図4に例示するように、取扱商品ごとにcode商品コード、quantity在庫数量の各要素のデータを相互に対応付けて構成される。ここで、上記の注文伝票上では、商品の種類は商品コードでしか記述されていないが、人が注文伝票を見るときには商品名で表示された方が見やすい。そこで、商品DB12の取扱商品テーブル12aを用いて注文伝票の商品コードを商品名に変換したいとユーザが考えたような場合に、本実施例1によるデータベース統合参照システムを利用するメリットがある。また、注文伝票を見ながらその注文を処理するときに、同時に在庫数も表示させて在庫を確認したいとユーザが考えたような場合にも、本実施例1によるデータベース統合参照システムを利用するメリットがあるなお、この場合には、各商品の在庫数を在庫DBから取ってくることになるが、各商品の在庫数は商品によって在庫DB13に格納されているので両者に在庫数を問い合わせることになる。このように、ユーザは、上記した3つのデータベースに分散している1つの注文に関連するデータを、1つに纏めて参照したいような場合に、本実施例1によるデータベース統合参照システムを利用するメリットがある。図3に戻って、ユーザ端末10は、データベース統合参照装置20を介して複数のデータベースに対するデータ参照の問い合わせを行うユーザの端末であり、既知のパーソナルコンピュータやワークステーション、PDA、あるいは携帯電話やPHSの如き移動体通信端末などで構成される。そして、ユーザ端末10は、主として、図1や図2に例示したように、XQueryというXML問い合わせ言語で記述された問い合わせXQuery問い合わせをキーボードやマウス等を介してユーザに入力させる機能、入力されたXQuery問い合わせをデータベース統合参照装置20に送信する機能、データベース統合参照装置20からXML形式の問い合わせ結果を受信する機能、及び受信した問い合わせ結果をモニタ等に出力する機能などを有する。なお、図2に例示したように、実施例1に係るデータベース統合参照システムによって、ユーザには、各注文に関する情報が1つに纏められて、それがorderタグで囲まれて、1枚の大きなXMLファイルの中に全ての注文が並んで格納されているように見える。ただし、これはあくまでも論理的なビューであって、データの実体は各データベースの中にしかない。そのような論理的なビューが存在すると思って、ユーザがデータベース統合参照装置20に問い合わせを行うと、該当する注文の分のXML文書データが返ってくる。図3に戻って、データベース統合参照装置20は、ユーザ端末10から受け付けたデータ参照の問い合わせを処理する既知のサーバコンピュータであり、主として、ユーザ端末10からXQuery問い合わせを受信する機能、各データベースから問い合わせに係るデータを取得してXMLの問い合わせ結果を生成する機能、生成したXMLの問い合わせ結果をユーザ端末10に送信する機能などを有する。以下に、本実施例1の主たる特徴を担うデータベース統合参照装置20の構成を詳細に説明する。データベース統合参照装置20は、図3に例示するように、記憶部21と、制御部22とを備えて構成される。このうち、記憶部21は、制御部22による各種処理に必要なデータおよびプログラムを記憶する手段であり、特に本発明に密接に関連するものとしては、同図に例示するように、統合用メタデータ21aをリポジトリに記憶する。かかる統合用メタデータ21aは、各データベースを統合するために必要な情報が規定されたものであるが、具体的には、図6~図9に例示するように、仮想XMLスキーマ情報、データベース情報1及び2、並びに、要素間の関連付け情報が記載されて構成される。より詳細には、仮想XMLスキーマ情報としては、図6に例示するように、複数のデータベースに跨る関連データを、どのようなフォーマットのXML文書データとしてユーザに見せるかという情報が規定される。図6を参照して、仮想XMLスキーマ情報について具体的に説明する。仮想XMLスキーマ情報XMLスキーマに似たフォーマットを使用して、統合データビューのXML構造を定義する。スキーマを構築するノードには次のA1~A3の3種類がある。A1ComplexElementこれは、配下に他のノードを持つ中間ノードである。対応するデータベースがRDBの場合は、これと配下のSimpleElementの組み合わせでデータベースの1レコードに対応する。対応するデータベースがXML-DBの場合は、配下に他のノードを持つ中間ノードであって、これ自体は値を持たないことを意味する。ComplexElementは、以下の属性を保有する。なお、このComplexElementノードの配下にはComplexElement、SimpleElement及びTagElementの3種類いずれのノードも出現し得る。名前:統合データビュー上での、当該ノードのタグ名。可視化の可否:統合データビュー上で表示するか否か。最大出現数:当該ノードが反復して出現する回数の上限。最小出現数:当該ノードが反復して出現する回数の下限。ダミー指定:該当するデータベースがXML-DB場合に、このノードがそのXMLデータにおいて実在しないノードであるか否か。A2SimpleElement配下に値を持つ末端ノードである。対応するデータベースがRDBの場合は、レコード内の1カラムに対応し、その値だけを保持する。対応するデータベースがXML-DBの場合は、値を持つ末端ノードに対応する。SimpleElementは、以下の属性を保有する。なお、このSimpleElementノードは末端ノードなので、この下にはいずれのノードも出現できない。名前:統合データビュー上での、このノードのタグ名。可視化の可否:統合データビュー上で表示するか否か。スキーマレス指定:該当するデータベースがXML-DBの場合に、このノードの配下に出現する全てのタグを単なる文字列として扱うことによって、配下に自由なスキーマの出現を許すか否か。A3TagElementタグを挿入するためのダミーのノードである。対応するデータベース要素を持たない。このTagElementは、名前:統合データビュー上での、このノードのタグ名、という属性を保有する。なお、このComplexElementノードの配下にはComplexElement、SimpleElement及びTagElementの3種類いずれのノードも出現し得る。また、ComplexElementとTagElementには、そのノードに対応するデータベース要素との対応関係を取る為に、固有のIDが与えられる。それぞれをComplexElementIDとSimpleElementIDという。対応するデータベースがRDBの場合は、1つのComplexElementと1つ以上のSimpleElementの組でRDBの1レコードに対応し、その組み合わせ同士を相互に連結して木構造を組み立てる。連結する際には、双方の間で関連付け値のマッチングを取ることができる項目が必要である。また、それとは無関係に、ダミーのタグを加えたい場所にTagElementを挿入することができる。対応するデータベースがXML-DBの場合は、XMLDBに格納されているXMLデータのスキーマに合わせて仮想XMLスキーマを構築する必要がある。元のXMLデータのスキーマに存在しないタグを加えたい場合はTagElementを使用し、元のXMLデータのスキーマに存在するタグを削りたいときは、そのタグの可視化の可否という属性をFALSEに設定することで対応することが出来る。また、データベース情報としては、図7及び図8に例示するように、XMLの中の各要素図6参照に、どのデータベースのどの要素が対応するのかという情報が規定される。データベース情報では、仮想XMLスキーマ内の各要素に、実際はどのデータベースのどの項目が対応するのかを記述する。対応するデータベースがRDBかXML-DBかによって、記述する内容は大きく異なる。なお、データベース名は、タグdatabaseIDによってIDで示されている。このIDと実際のDB名の対応表は、別に管理されている。また、テーブル名はタグtableIDにより、カラム名はタグcolumnIDによって、IDで示されている。これらのIDと実際のテーブル名、カラム名との対応表は、別に管理されている。対応するデータベースがRDBの場合は、それぞれのComplexElementがどのRDBのどのテーブルに対応するかを記述し、そのComplexElementの配下の各SimpleElementがそれぞれそのテーブルの中のどのカラムに対応するのかを記述する。対応するデータベースがXML-DBの場合は、どのCompelxElementから成る部分木がどのXML-DBのデータに対応するかを記述する。さらには、データビュー上のタグ名とXML-DB上のタグ名が異なる場合は、その対応を記述する記述が無かったCompelxElement、SimpleElementについては、データビュー上のタグ名とXML-DB上のタグ名が同じであると見なす。また、XML-DBに格納されている大きなXMLデータの中の一部の反復構造のみを処理対象としたい場合には、ルートからその反復構造までのパスをここに記述する。さらに、要素間の関連付け情報としては、図9に例示するように、異なるテーブルの異なるレコード同士を関連付けて1つのXMLとする場合に、各テーブルのどのカラムでそれぞれ対応をとるか関連付けるかという情報が規定される。要素間の関連付け情報では、RDBに対応するComplexElement、SimpleElementの組み合わせ同士や、それとXML-DBに対応するXML部分木を結びつける為の情報を記述する。具体的には、どのSimpleElementとどのSimpleElementとで値のマッチングを取るかを記述する。実施例1では、関連付けは値の完全一致という一種類しか用意していない。RDBに対応するComplexElement、SimpleElementの組み合わせの場合は、その中のSimpleElementがどれでも関連付けに使用できる。一方、XML-DBに対応するXML部分木の場合は、関連付けに使用できるSimpleElementは1対1の対応関係を保障する為に制約される。他のデータベースが下位に接続される場合は、仮想XMLスキーマ情報において接続箇所となっている接続相手のデータベースに対応するノードがその下位に出現するComplexElementについて、その子ノードであるSimpleElementだけが関連付けに使用できる。他のデータベースが上位に接続される場合は、このXML部分木の最上位のComplexElementの子ノードであるSimpleElementだけが関連付けに使用できる。ところで、関連付けに使用できるSimpleElementが制約されると生成できる仮想XMLビューが制限されて不便である。そこで、ComplexElementに設定されている最大出現数を利用して、その制約を緩くすることが可能である。もし接続箇所となっているComplexElementの最大出現数が1ならば、XML部分木において上位に隣接するComplexElementの子ノードのSimpleElementにまで関連付けの範囲を拡大することが可能である。再帰的に、ComplexElementの最大出現数が1である限り、さらに1つ上位のComplexElementの子ノードのSimpleElementにまで関連付けの範囲を拡大することが可能である。逆に、もし接続箇所となっているComplexElementについて、その配下のComplexElementの最大出現数が1ならば、関連付けの範囲をそのComplexElementの子ノードのSimpleElementにまで拡大することが出来る。さらに下位のComplexElementに関しても、再帰的に関連付けの範囲を拡大していくことが可能である。図6~図9に分けて例示した統合用メタデータは、1つの統合用メタデータであり、1つのXML形式のファイルに含まれる。このような統合用メタデータ21aを記憶部21は予め記憶しているが、かかる統合用メタデータは、システムの管理者等によるマッピング作業図5参照を通じて作成される。すなわち、図5に例示するマッピング例は、図4に例示した3つのデータベースのデータを、XMLの木構造にマッピングした例であるが、このようなマッピング作業をシステム管理者等が行うことで、統合用メタデータ21aには、図5に例示する内容と同内容の情報がXML形式で記述され、そして、ユーザには、統合されたデータが図5に例示するフォーマットのXML文書データとして見えることになる。なお、データベースのデータをXMLの木構造にマッピングする手法ルールは以下の通りである。1ユーザには、データベースを跨って1つに組み合わされたデータが、1つのXMLの中にデータ数だけ反復して入っているように見える。2統合したいデータベースのデータを、テーブル単位でXMLのエレメントにマッピングする。3テーブルに対応するXMLのエレメントは、階層的に配置することができる。4テーブルに対応するXMLのエレメントのうち、階層構造上で上下に隣接するエレメント同士は、対応するテーブル同士でデータが関連付けできる必要がある。つまり、お互いのテーブル同士で、ある1つのカラム同士が同じ値を取らなければならない。51つのXMLエレメントに対応するテーブルは、別個のデータベースの別個のテーブルを複数指定しても構わない。6データベースのカラムに対応するXMLのタグ名は、カラム名とは別の名前にしても構わない。図3に戻って、データベース統合参照装置20の制御部22は、OSOperatingSystemなどの制御プログラム、各種の処理手順などを規定したプログラム及び所要データを格納するための内部メモリを有し、これらによって種々の処理を実行する処理部である。特に本発明に密接に関連するものとしては、同図に例示するように、問い合わせパーザ部22aと、問い合わせ処理エンジン部22bと、アクセス処理部22cとを備える。このうち、問い合わせパーザ部22aは、ユーザ端末10から受け付けたXQuery問い合わせを構文解析し、構文チェックを行った後に、問い合わせ内容を内部形式へ変換する処理部である。なお、構文規則に反する問い合わせについては、その旨のエラーメッセージをユーザ端末10に返信する。問い合わせ処理エンジン部22bは、問い合わせパーザ部22aで変換されたXQuery問い合わせを実際に処理し、各データベースに対してそれぞれに応じた必要な問い合わせを行ってデータを取得するとともに、XMLで問い合わせ結果を生成してユーザ端末10に返信する処理部である。すなわち、各データベースへどのような順番でどのような問い合わせを行ってデータを獲得するかを計画し各データベースに対して問い合わせをするSQLを生成し、それを実行する生成したSQLをデータベースに投げて結果を得る。そして、問い合わせた結果として各データベースから取得したデータを、最終的にユーザ端末10に返信するXML文書データへと組み立てる。なお、問い合わせ処理エンジン部22bによる具体的な処理内容については、図10等を用いて後に詳述する。アクセス処理部22cは、問い合わせ処理部22bからデータベースへの問い合わせ要求が行われると、実際にデータベースへアクセスする処理部である。問い合わせパーザ部22aで変換されたXQuery問い合わせから生成された各データベースに対応する問い合わせを、対応する各データベースへ送信する処理を行うものである。次に、図10~図18を参照して、データベース統合参照装置20による問い合わせ処理手順を説明する。図10は、実施例1による問い合わせ処理手順を示すフローチャートであり、図11~図18は、かかる問い合わせ処理手順の具体例を示す図である。図10に例示するように、データベース統合参照装置20は、ユーザ端末10から図2に例示したようなXQuery問い合わせの入力があるとステップS1301肯定、XQuery問い合わせを構文解析し、構文チェックを行った後に、問い合わせ内容を内部形式へ変換するステップS1302。なお、構文規則に反する場合には、その旨のエラーメッセージをユーザ端末10に返信する。続いて、データベース統合参照装置20は、問い合わせに関係する統合用メタデータを記憶部21から読み込んで、問い合わせ対象となっているXMLの構造と、その各エレメントに対応するデータがどのデータベースに格納されているかを求めるステップS1303。具体的には、図11に例示するように、図2に例示したようなXQuery問い合わせについては、orderlistxmlに対応する統合用メタデータを記憶部21から読み出し、かかるXMLの構造と、その各エレメントに対応するデータが格納されているデータベースとを求めることで、図11に例示するような木構造で表現可能な情報を得る。そして、データベース統合参照装置20は、問い合わせ順序の最適化として、ステップS1303で得たXML構造の各エレメントを、そのデータが格納されているデータベースごとに分けて、それぞれに対してユーザがXQuery問い合わせの中で指定した条件文を検討し、最もデータが絞り込めそうなデータベースを決定するステップS1304。具体的には、図12に例示するように、XQuery問い合わせに含まれるnameFMV6000CLという条件とquantity2という条件について、商品テーブルと商品取扱テーブルのどちらに最初に問い合わせを行った方が問い合わせ結果としてのデータ量が少なくなるかを予測し、データ量が少なくなると予測されたテーブルに対する問い合わせを最初に行うことを決定する。なお、同図では、取扱商品テーブルに対して最初に問い合わせることを決定した例を示しているが、かかる問い合わせ順序の最適化手法については、後に詳述する。その後、データベース統合参照装置20は、ステップS1304で決定された最初のデータベースに対して条件に合致するデータを問い合わせるためのクエリを作成するステップS1305。ここで作成されるクエリは、問い合わせ対象のDBの種別に応じた形式で作成されるものである。具体的には、問い合わせ対象のDBがXML-DBである場合には、クエリはXPathまたはXPath準拠クエリ言語で記述され、問い合わせ対象のDBがRDBである場合には、クエリはSQLで記述される。続いて、かかるクエリを当該データベースに投げて、問い合わせ結果を得るステップS1306。ただし、この時点でデータベースから求める値は、上位のエレメントと関連付けられているカラムだけでよい。具体的には、図13に例示するように、nameFMV6000CLという条件に合致するデータをRDB1商品DB12の取扱商品テーブルに問い合わせるためのSQLを生成して、これを商品DBに投げることで、商品DBの取扱商品テーブルから条件に合致するデータとしてcode0345を含んだ問い合わせ結果を得る。なお、XML-DBに対するXPath又はXPath準拠クエリ言語による副問い合わせ文の生成では、まず統合データビューに対して実行されたXQueryの中で与えられた条件式のうち、対象となっているXML-DBが対応するXML部分木の範囲内のノードに対して条件付けしているものを選び出す。次に、それらの条件式からXML部分木のパスに合わせてXPathを生成する。この作業は、ルートの位置が変わることによるパスの置き換えが発生することを除けば、XQueryからXPathへの変換を行うだけである。また、XQueryにおいて条件式が複数存在して、条件式内のパスで使われている変数が対象としているXML部分木の範囲外のノードにバインドされていると、複数の条件式を1つのXPathで纏めることが出来ない場合が発生する。この場合は、いずれかの条件式を使用しないで、どちらかデータを絞り込めそうな条件式のみを使用してXPathを組み立てることになる。続いて、データベース統合参照装置20は、前のデータベースへの問い合わせ結果を使って、順番にXMLの木構造の中で上位のエレメントを求めるクエリを生成するステップS1307。ここでのクエリ種別の選択方法も、ステップS1305と同様である。そして、かかるクエリを該当のデータベースに投げて問い合わせ結果を得るステップS1308。このステップS1307及びステップS1308の処理を、XMLの木構造の最上位のエレメントが求まるまで繰り返し行って、データベースへの問い合わせを開始したエレメントから、次々と上位のエレメントに対応するデータの値を求めていくステップS1309。かかる処理においては、前の問い合わせ結果との関連付けを、データ絞り込みの条件として用いるとともに、XQuery問い合わせでユーザが指定した条件があれば、それもデータ絞込みの条件に加える。また、データベースから求める値は上位のエレメントと関連付けられているカラムだけでよいが、最上位のエレメントに達した場合は、その最上位のエレメントに対応する全てのカラムを求める。具体的には、図14に例示するように、前の問い合わせ結果として得たcode0345の関連付けから、受注DB11に対する問い合わせを次に行うことを決定した後、かかるcode0345という条件と、XQuery問い合わせでユーザが指定した条件で未だ反映されていないquantity2という条件に合致するデータを問い合わせるためのクエリを生成する。このクエリは、XPathで記述される場合は、orderitemとなる。そして、生成したクエリを受注DB11XML-DBに投げることで、注文伝票XMLから条件に合致するデータとして121AsianTraders034520872520050725なる問い合わせ結果を得る。なお、同図に示す例では、最上位のエレメントに達しているので、ここでは、その最上位のエレメントに対応する全てのカラムを求めている。続いて、データベース統合参照装置20は、XMLの最上位のエレメントが求まればステップS1309肯定、そこから下位のエレメントを順に全て求めるクエリを生成し、かかるSQL問い合わせを該当のデータベースに投げて問い合わせ結果を得るという処理ステップS1310およびS1311を、XMLの木構造の最上位から下位の全てのエレメントが求まるまで行って、次々と下位のエレメントに対応するデータの値を求めていくステップS1312。なお、ステップS1310におけるクエリ種別の選択方法も、ステップS1305及びステップS1307と同様である。かかる処理に際しては、上位のエレメントの問い合わせ結果との関連付けを、データ絞込みの条件として指定する。また、データベースから求める値としては、エレメントに対応付けられている全てのカラムを求める。具体的には、図15に例示するように、code‘0345ORcode‘0872という条件に合致するデータを受注DBの商品テーブルに問い合わせるためのSQL問い合わせを生成し、これを商品テーブルに投げることで、code、name0345、FMV6000CL、0872、PRIMERGYRX300という問い合わせ結果を得る。さらに、図16に例示するように、上記の問い合わせ結果からcode‘0345ORcode‘0872という条件に合致するデータを在庫DB13の在庫テーブルに問い合わせるためのSQL問い合わせを生成し、これを在庫テーブルに投げることで、code、quantity0345、38、0872、3という問い合わせ結果を得る。そして、データベース統合参照装置20は、上記してきた処理によって全てのエレメントのデータ値が求まればステップS1312肯定、図17に例示するように、XMLの木構造を上から辿りながら、得られたデータ値から問い合わせ結果のXMLを組み立てるステップS1313。ここで、この時点で、未だユーザからのXQuery問い合わせで指定した問い合わせ条件の一部が反映されていない可能性もあるので、データベース統合参照装置20は、問い合わせ条件を満たさない解をチェックして最終結果のXMLから除外してXMLを組み立てるステップS1314。その後、データベース統合参照装置20は、図18に例示するように、問い合わせ結果のXMLを生成して出力するステップS1315。上記した一連の処理を経ることによって、XQuery問い合わせを行ったユーザ端末10に対して、XML形式のデータが問い合わせ結果として返信される。なお、上記したステップS1307~S1312で、一度最上位のエレメントまで上がってから、再び下位のエレメントを問い合わせし直しており、同じデータベースに二度問い合わせを行っている点で一見すると無駄なように思えるが、これは、そうしなければXML文書データの一部が欠けてしまう可能性があるからである。すなわち、例を挙げれば、図13ではFMV6000CLに対するcodeだけを求めているが、最終的な結果で必要なのは、図17に例示するように、orderidが121の注文伝票で注文された2つの商品のcodeとnameである。そして、これは、一旦最上位のエレメントを求めてorderidが確定するまでは求めることができないからである。なお、XML-DBへの副問い合わせの結果として返ってきたXMLデータは、問い合わせ処理エンジン部22bに含まれるXMLパーザを利用して解析を行う。これは、関連付けで使用するノードの値を取り出さないと次のデータベースでの問い合わせができないからである。また、DB統合用メタデータで定義してあるXMLのスキーマに合致しているか確認することで不正なデータの混入を防ぐことも目的である。解析を終えたXMLデータは中間データ形式DOMDocumentObjectModelに準拠した形式でメモリ上に保管しておく。DB統合用メタデータの仮想XMLスキーマ情報において同一のComplexElementの直下に出現するSimpleElementが、返ってきたXMLデータにおいて順番違いで出現したときの処理は、二通りが考えられる。一つはそれをスキーマ違反の不正なXMLデータとしてエラーにしてしまうそのデータを破棄するorエラーを返して終了するという方法で、もう一つは仮想XMLスキーマ情報に合わせて並び直すという方法である。本実施例1では後者を採用する。このことによって、本実施例1では仮想データビューにおいてタグの出現順を任意に変更することを可能となる。XQueryの問い合わせ結果となるXMLデータの生成は、中間データ形式でメモリ上に保持しておいた各データベースへの副問い合わせ結果を、DB統合用メタデータの仮想XMLスキーマに合わせてXMLデータとして出力することで行う。次に、上記の問い合わせ処理手順で説明した問い合わせ順序の最適化手法図10のステップS1304に係る処理を詳細に説明する。問い合わせ型データベース統合が抱える潜在的な問題点として、データベースのデータをネットワーク経由で取得するので、ローカルにデータを保持している場合に比べて、データへのアクセス速度が遅くなり、ネットワーク負荷も大きくなる点が挙げられる。そして、実施例1におけるデータベース統合参照装置20では、複数のデータベースから関連するデータを順番に取得していく場合に、最初に取得するデータはユーザの問い合わせで指定された条件によって絞り込み、以降に取得するデータは前に取得したデータとの関連付けとユーザの指定した条件の両方を用いて絞り込むことにしている。このため、データの絞込みが足りないと、データベースに問い合わせをした結果として大量のデータが返ってきてしまい、データ転送に時間を要するばかりか、ネットワーク負荷を増大させてしまう。これを具体的に説明すると、図11に例示したように、ユーザからの問い合わせにはデータを絞り込むための条件が2つ書かれている。1つ目は商品名がFMV6000CLであることであり、2つ目はその商品の発注数が2つ以上であることというものである。その一方で、商品名の情報は商品DB12の取扱商品テーブルに格納されており、発注個数の情報は受注DB11の受注伝票XMLに格納されている。このため、データベース統合参照装置20は、最初にどちらのデータベースに対してSQL問い合わせを発行するかを決定する必要がある。ここで、最初の問い合わせの結果データが多いと、その結果データを用いて行う次の問い合わせの結果データも多くなり、ユーザに返される最終的な問い合わせ結果は同じでも、途中でデータベース統合参照装置20に集められるデータの量が増えてしまい、データ転送に時間がかかってユーザへの応答に時間がかかるばかりが、ネットワークの負荷も増大させてしまう。そこで、データベース統合参照装置20は、最初にどちらのデータベースに対してSQL問い合わせを発行すれば、その問い合わせの結果データを少なくすることができるかを検討した上で、最初に問い合わせを開始するデータベースを決定する。そして、これについては、各データベースからデータベース自身のメタデータ統合用メタデータとは異なる。を取得した後に、以下の1~4の事項を考慮して行われる。1データの冗長性に関する制約条件データベースのメタデータを参照し、XQuery問い合わせで条件付けが行われているカラムが、そのテーブルの主キーになっていないか、またはユニーク制約が設定されていないかを確認する。そのいずれかであれば、そのカラムはデータの重複が無いので、データを絞り込める可能性が高くなるからである。2データ数データベースのメタデータを参照し、テーブル内のレコード数が多いか確認する。テーブル内のレコード数が多いと、問い合わせの結果として返ってくるレコードの数も多くなる可能性が高いからである。3データの型と桁数データベースのメタデータを参照し、カラムのデータ型が数字や真偽値などの種類の少ないものであったり、桁数が少なかったりしていないかを確認する。この場合には、そのカラムは重複するデータが多くなる可能性が高いので、問い合わせの結果として多くのレコードが返ってくる可能性が高いからである。4ユーザの指定した条件式の条件指定の種類XQuery問い合わせ内の条件式が等号で指定されているか、不等号で指定されているかを確認する。等号で指定されている場合は、不等号で指定されている場合よりもデータを絞り込める可能性が高いからである。データベース統合参照装置20は、上記した4つの条件をそれぞれ満たしているかどうかを調べ、その結果によって各問い合わせの条件について点数付けを行い、最も点数の高い条件に係るデータベースから問い合わせを開始する。なお、図12に示した例は、name‘FMV6000CLという条件を取扱商品テーブルに対して最初に問い合わせる方が、データを絞り込める可能性が高いと判定された場合の例である。上記したような最適化手法によって問い合わせを開始するデータベースを決定した後は、上記の問い合わせ処理手順で説明したように、関連付け情報を利用して、一旦XMLの最上位のエレメントへ向けて次々と上隣のエレメントを求めてゆく。上述してきたように、実施例1によれば、データベースへの共通アクセス手段を提供するだけでなく、そのさらに上位にXMLのデータビューを用意する。すなわち、ユーザには複数のデータベースに跨っている関連データ全体をXML文書と仮想させ、そのXML文書の一部を切り出す問い合わせを行った結果として、XML文書が返るという形でデータの参照を行う。また、ユーザから問い合わせが行われると、予め用意されている統合用メタデータに基づいて、どのような順番でどのデータベースからどのような問い合わせでデータを獲得していけばよいかを判断し、それに基づいて必要なデータを獲得して、獲得されたデータをXML文書として組み立ててユーザに返す。これによって、ユーザはデータの格納構造を気にする必要がなくなり、各データがどのデータベースに格納されているのかを全く意識せずに済むので、複数のデータベースがあたかも1つであるかのように扱うことが可能になる。また、実施例1によれば、同種のデータが複数のデータベースに分かれて格納されていて、ある1つの値を持つデータに関していずれのデータベースに格納されているか分からないような場合においても、ユーザがXML文書の問い合わせを行うと、データベース統合参照装置20が統合用メタデータに基づいてデータが格納されている可能性のあるデータベース全てに問い合わせを行い、データを自動的に見つけてくる。これによって、ユーザは複数のデータベースからデータを探す作業をする必要がなくなるので、複数のデータベースがあたかも1つであるかのように扱うことが可能になる。また、実施例1によれば、データベースからデータを取得する際に、データベースのメタ情報や問い合わせ内容を利用して、問い合わせ結果がなるべく少なくなる問い合わせ計画を作成し、その計画に基づいて各データベースから順番にデータを獲得してくる。このように、問い合わせ順番を操作して結果データを絞り込んでいくことによって、データ転送量を減らして、問い合わせにかかる時間を短縮するとともに、ネットワークにかかる負担も軽減することが可能になる。また、実施例1によれば、問い合わせを開始するデータベースを決定した後に、XML文書の木構造の中で、最初にデータ値を求めたエレメントから次々と上位のエレメントに対応するデータ値を求めていき、最上位のエレメントのデータ値が求まったら、次にそこから順番に下位のエレメントを辿りながら全て求めていく。そして、この手順は、XML文書の構造の定義や問い合わせの内容に関わらず、常に同じである。これによって、XML文書の構造定義や問い合わせの内容に関わらず、問い合わせ結果としてのXML文書全体を洩れなく求めることが可能になるとともに、データベースへの問い合わせの回数を少なく抑えることが可能になる。なお、上記した実施例1は、次の特徴を有する。図19は、実施例1の特徴を説明するための図である。同図に示すように、実施例1は、RDBをXML-DBと同様に取り扱い可能とする機能を有する。まず、XML-DBは、一定の固定スキーマのXML文書データを多数格納しており、問い合わせを受けるとその条件に該当するXML文書データをその形のまま返すというインタフェースを保有していると見なす。XML文書データは条件に該当した分だけ複数個返される。このようなインタフェースを持っていると見なすことによって、XML-DBから返ってくるXML文書データのスキーマが固定であると考えることが出来るので、それをユーザに見せるXML形式のデータビューのスキーマの一部として埋め込むことが出来る。XML-DBから返ってくるXML文書データのスキーマをXML形式のデータビューのスキーマに埋め込む為に、ビュー生成ルールの中で、XML-DBから返ってくるXMLの木構造と、他のRDBのデータ構造から生成し得るXMLの木構造との間で、相互の木構造をどのように結合してどのような木構造のビューにするのかというスキーマの定義と、両者の間で関連付けを取る項目の定義を行う。問い合わせの処理においては、XML-DBから返ってくるXML文書データは、そのまま無加工で問い合わせ結果のXML文書データの一部として埋め込まれる。すなわち、複数のRDBから構築されるXMLの部分木と同様に扱われる。XML文書データビューのスキーマを定義する木構造が、実施例1ではXML-DBから返って来るXML文書データのスキーマ定義を兼ねていると言える。しかし、この方法によれば、前述の如く仮定したインタフェースを有しているXML-DBにしか適用できないし、またXML-DBから返るXML文書データに半構造性がある場合も適用できない。さらに、ユーザに与えられる統合データビューのスキーマもXML-DBから返るXML文書データのスキーマによって制限を受けることにもなる。上記した実施例1によってもなお存在する問題点を解決するため、また、実施例1にさらに各種機能を付加するために実施してもよい他の実施例を、以下に実施例2として示す。先ず、実施例2の第1の特徴を説明する。図20は、実施例2の第1の特徴を説明するための図である。実施例1では、XML-DBは、一定の固定スキーマのXML文書データを多数格納しており、問い合わせを受けるとその条件に該当するXML文書データをその形のまま返すというインタフェースを保有していると見なした。故に、それ以外のインタフェースしか持たないXML-DBには対応できない。しかし、一般的には、XML-DBのインタフェースは、一つの巨大なXML文書データを格納しており、問い合わせ言語によってその一部を切り出す指示を行い、格納されていたXML文書データの部分データが返るというものが多い。また、DB統合用メタデータのデータベース情報において、XMLデータ中の反復構造までのパスが指定されている場合は、先頭にそのパスを加えるようにXPathを修正して発行する必要がある。そこで、図20に示すように、実施例2のデータベース統合参照システムは、XML-DBがそのようなインタフェースしか持たない場合に対応する為に、もしそのXML-DB内のXML文書データの木構造の中に一定の繰り返し構造がある場合に、その木構造のルートノードからその繰り返し構造までのパスをビュー生成ルール内に記録しておき、本システムが発行する副問い合わせをそのパスに応じて自動的に加工して発行することによって、そのXML-DBが本発明のデータベース統合参照システムの仮定しているインタフェースを保有するかのように取り扱う機能を備える。こうすることによって、実施例2のデータベース統合参照システムでは多くのXML-DBに対応することが可能となる。なお、本システムが発行する副問い合わせを、ビュー生成ルール内に記録されるルートノードから繰り返し構造までのパスに応じて自動的に加工して発行する処理は、問い合わせ処理エンジン部22bにより実行される。また、該ルートノードから繰り返し構造までのパスは、統合用メタデータ21aに記憶されている。次に、実施例2の第2の特徴を説明する。図21は、実施例2の第2の特徴を説明するための図である。実施例1のデータベース統合参照システムでは、ビュー生成ルールにおいて、XML-DBのXML文書データの木構造とRDBとを組み合わせた木構造の間で両者を連結するための定義を行う。その定義は二種類あり、一つが相互の木構造をどのように結合してどのような木構造のデータビューにするのかというスキーマの定義であり、もう一つが両者の間でどのノードにおいて関連付けを取るのかという関連付けの定義である。これらの間には相互に関係があり、無秩序に定義することはできない。関連付けを取るノード同士は相互に1対1で対応しなければならないので、XML-DBについては、関連付けの定義で使用するノードは、スキーマの定義において接続箇所となっている中間ノードの子となる末端ノードでなければならないという制約がある。これでは、ビューのスキーマ定義の自由度が少なく、自由なビューを定義できないという問題があった図21a参照。そこで、図21bに示すように、実施例2のデータベース統合参照システムでは、ビュー生成ルールのビュースキーマ定義において、XML-DBに対応する部分木の各中間ノードについて最大出現回数を指定することができるようになっており、ユーザがビュー生成ルールを作成する際にそれを適切に定義することによって、各中間ノード間の出現回数又は出現比率を求めることができる。これによって、関連付けの定義に使用するノードをスキーマの定義において接続箇所となっている中間ノードの子ノードに限る必要はなく、1対1対応する範囲において、より上位や下位のノードを関連付け先として指定することが可能となる。こうすることによって、実施例2のデータベース統合参照システムではデータビュー定義の自由度を高めている。なお、指定されたXML-DBに対応する部分木の各中間ノードの最大出現回数に基づいて各中間ノード間の出現回数又は出現比率を求め、1対1対応する範囲において、より上位や下位のノードを関連付け先として指定することが可能か否かを判定する処理は、問い合わせ処理エンジン部22bにより実行される。また、指定されたXML-DBに対応する部分木の各中間ノードの最大出現回数は、統合用メタデータ21aに記憶されている。次に、実施例2の第3の特徴を説明する。図22は、実施例2の第3の特徴を説明するための図である。実施例1では、XML-DBから返るXML文書データのスキーマをそのまま統合データビューの木構造の一部として見せている。これでは、統合データビューのスキーマ定義に制限が生じてしまい、ユーザの望む自由なビュースキーマを定義することができない場合がある。特に、ビューにおいては元のXML文書データとはタグの名前を変更したいという要求が発生することが考えられる。また、DB統合用メタデータのデータベース情報において、ノードのXML-DBにおける別名が定義されている場合は、XPathを生成する際にパス中のタグ名をその別名に置き換える必要がある。そこで、図22に示すように、実施例2のデータベース統合参照システムでは、ビュー生成ルールのビュースキーマ定義において、各ノードにデータベース上の別名を指定できるようになっている。XML-DBへの副問い合わせ時や返ってきたXML文書データの解析時にはこの別名を使用し、XML文書データを解析し終わったら各タグの名前をビュー表示用の本来の名前に置き換えることによって、XML-DB上のXML文書データについてもタグ名を置き換えることを可能としている。即ち、DB統合用メタデータのデータベース情報において、ノードのXML-DBにおける別名が定義されている場合は、XML-DBから返ってきたXMLデータをパーズする際に、その別名を用いてパーズする。こうすることによって、実施例2のデータベース統合参照システムではビュー定義の自由度を高めている。なお、ビュー生成ルールのビュースキーマ定義において各ノードの名称を各データベース上の名称とは異なる別名に変換する処理は、問い合わせ処理エンジン部22bにより実行される。また、各ノードの名称及びこれに対応する各データベース上の名称とこの両者の関係は、統合用メタデータ21aに記憶されている。次に、実施例2の第4の特徴を説明する。図23は、実施例2の第4の特徴を説明するための図である。実施例1では、XML-DBから返るXML文書データのスキーマをそのまま統合データビューの木構造の一部として見せている。これでは、統合データビューのスキーマ定義に制限が生じてしまい、ユーザの望む自由なビュースキーマを定義することができない場合がある。特に、データビューにおいてはXML-DBのXML文書データには存在しないタグを途中に挿入したいという要求が発生することが考えられる。また、XML部分木の中にTagElementが存在するならば、それは無視してXPathを生成する必要がある。そこで、図23に示すように、実施例2のデータベース統合参照システムでは、ビュー生成ルールのビュースキーマ定義において、架空のノードを指定することが可能となっている。この架空ノードについては、XML-DBへの副問い合わせ時や返ってきたXML文書データの解析時には使用せず、XML文書データを解析し終わったらその架空ノードのタグを挿入することによって、XML-DB上のXML文書データについてもデータビュー上の木構造を変形することが可能となっている。即ち、DB統合用メタデータの仮想XMLスキーマ情報において、XML部分木の中にTagElementが存在するならば、XQueryの問い合わせ結果を組み立てる際にそのタグを加える。こうすることによって、本発明のデータベース統合参照システムではビュー定義の自由度を高めている。なお、問い合わせ結果であるXML文書データを解析し終わった後に、指定された架空ノードのタグを挿入する処理は、問い合わせ処理エンジン部22bにより実行される。また、指定された架空ノードのタグ情報は、統合用メタデータ21aに記憶されている。次に、実施例2の第5の特徴を説明する。図24は、実施例2の第5の特徴を説明するための図である。実施例1では、XML-DBから返るXML文書データのスキーマをそのまま統合データビューの木構造の一部として見せている。これでは、統合データビューのスキーマ定義に制限が生じてしまい、ユーザの望む自由なビュースキーマを定義することができない場合がある。特に、ビューにおいては元のXML文書データに存在するノードを見せたくないという要求が発生することが考えられる。そこで、図24に示すように、実施例2のデータベース統合参照システムでは、ビュー生成ルールのビュースキーマ定義において、各ノードに非表示の設定をすることが可能となっている。このノードについては、XML-DBへの副問い合わせ時や返ってきたXML文書データの解析時には通常通り使用するが、XML文書データを解析し終わったらそのノードのタグを取り除くことによって、XML-DB上のXML文書データについてもビュー上の木構造を変形することが可能となっている。即ち、DB統合用メタデータの仮想XMLスキーマ情報において、ComplexElementかSimpleElementに可視化の可否属性がFALSEと設定されていたならば、XQueryの問い合わせ結果を組み立てる際にそのノードのタグは削除する。こうすることによって、本発明のデータベース統合参照システムではビュー定義の自由度を高めている。なお、問い合わせ結果であるXML文書データを解析し終わった後に、非表示が指定されたノードのタグを取り除く処理は、問い合わせ処理エンジン部22bにより実行される。また、指定された非表示ノードのタグ情報は、統合用メタデータ21aに記憶されている。次に、実施例2の第6の特徴を説明する。図25は、実施例2の第6の特徴を説明するための図である。実施例1では、XML-DBから返るXML文書データのスキーマをそのまま統合データビューの木構造の一部として見せている。これでは、XML-DBから返って来るXML文書データに半構造性がある場合に対応できない。そこで、図25に示すように、本発明のデータベース統合参照システムでは、ビュー生成ルールのビュースキーマ定義において指定した特定のノードについては、その配下のスキーマをチェックしないという指定を出来るようにした。XML-DBから返ってきたXML文書データの解析を行う際に、そのノードの配下に出現したものは全て単純に文字列として取り扱い、その部分のスキーマをチェックしない。即ち、DB統合用メタデータの仮想XMLスキーマ情報において、SimpleElementのスキーマレス指定オプションがTRUEと設定されていたら、そのタグの中身はパーズ及び処理を一切行わず、単なる文字列として取り扱う。SimpleElementのスキーマレス指定オプションがTRUEと設定されていてタグ配下をパーズしなかった場合は、その文字列をそのままそのタグの値としてXQueryの問い合わせ結果に出力することとなる。これによって、XML-DBに格納されているデータについて、そのスキーマの一部に半構造性があっても対応することが可能となる。こうすることによって、本発明のデータベース統合参照システムでは格納データが半構造性を持つXML-DBにも柔軟に対応することを可能としている。なお、問い合わせ結果であるXML文書データを解析し終わった後に、スキーマチェックのキャンセルが指定されたノードの情報を単純文字列として表示させる処理は、問い合わせ処理エンジン部22bにより実行される。また、スキーマチェックのキャンセルが指定されたノードのタグ情報は、統合用メタデータ21aに記憶されている。上記した実施例1及び2によれば、XML-DB及びRDBを含む複数のDBに分散して配置されるデータを参照する場合に、DBの物理的な分散を意識することなく、単に、XQueryの基本的な使用法に基づくだけで、データが参照可能となる。また、統合データビューのスキーマ定義の自由度が高いので、あたかも一つのDBにアクセスするかのような感覚で、XQueryによる自由な問い合わせが可能となる。さて、これまで本発明の実施例1及び2について説明したが、本発明は上述した実施例1及び2以外にも、特許請求の範囲に記載した技術的思想の範囲内において種々の異なる形態にて実施されてよいものである。そこで、以下では他の実施例として、1タグ付き文書、2データベース、3統合用メタデータ、4アクセス処理、5システム構成等、6プログラム、にそれぞれ区分けして種々の異なる実施例を説明する。1タグ付き文書例えば、実施例1及び2では、タグ付き文書としてXMLを利用する場合を説明したが、本発明はこれに限定されるものではなく、例えば、HTMLやSGMLなど、他のタグ付き文書を利用するようにしてもよい。また、実施例1及び2では、XMLデータビューに対する問い合わせに、現在W3Cで標準化作業が進行中の問い合わせ言語XQueryを利用し、XML-DBに対する問い合わせにXPathまたはXPath準拠のクエリ言語を使用する場合を想定しているが、本発明はこれに限定されるものではなく、いずれにおいても、XQuery又はXPathまたはXPath準拠のクエリ言語など、他の問い合わせ言語を利用するようにしてもよい。2データベースまた、実施例1及び2では、XML-DB及びRDBを統合する場合を説明したが、本発明はこれに限定されるものではなく、他の型のデータベースを統合する場合にも本発明を同様に適用することができる。例えば、オブジェクト指向データベース、オブジェクトリレーショナルデータベースなどである。オブジェクト指向データベースは、データを階層構造のパスでデータを特定することから、この階層構造をタグ付き文書の階層構造に変換する処理及び機能を備えることによって、あたかもオブジェクト指向データベースをXML-DBであるかのように取り扱うことが可能となる。また、オブジェクトリレーショナルデータベースは、データ管理方法がRDBに準拠するため、RDBと略同一に取り扱うことが可能となる。3統合用メタデータまた、実施例1及び2では、一つの統合用メタデータを用意する場合を説明したが、本発明はこれに限定されるものではなく、データベースの統合の仕方に応じて複数の統合用メタデータを用意するようにしてもよい。例えば、問い合わせ結果の出力態様に応じて複数用意することなどが考えられる。4アクセス処理また、実施例1では、複数の異種のデータベースにアクセスするために、RDBに対してはGlobusToolkit4OGSADAIWSRF21を、XML-DBに対してはXPath準拠のAPIApplicationProgrammingInterfaceを利用する場合を想定しているが、本発明はこれに限定されるものではなく、複数の異種のデータベースへどのようにして問い合わせを行うかは問わず、如何なる手法でアクセスしてもよい。特に、前述のXPath準拠のAPIは、XML検索言語であるXPathのサブセットであるので、XPathを使用して問い合わせ処理を行うように移行可能である。5システム構成等また、図示した各装置特に、データベース統合参照装置20の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。また、実施例1及び2において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。6プログラムところで、上記の実施例1及び2で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータ、サーバ又はワークステーションなどのコンピュータシステムで実行することによって実現することができる。さらに、その他の実施例では、コンピュータシステムにおいて、所定の記録媒体に記録されたプログラムを読み出して実行することで上記した実施例1及び2と同様の機能を実現する。ここで、所定の記録媒体とは、フレキシブルディスクFD、CD-ROM、MOディスク、DVDディスク、光磁気ディスク、ICカードなどの可搬用の物理媒体の他に、コンピュータシステムの内外に備えられるハードディスクドライブHDDや、RAM、ROMなどの固定用の物理媒体、さらに、モデムを介して接続される公衆回線や、他のコンピュータシステム並びにサーバが接続されるLAN/WANなどのように、プログラムの送信に際して短期にプログラムを保持する通信媒体など、コンピュータシステムによって読み取り可能なプログラムを記録する、あらゆる記録媒体を含むものである。すなわち、このその他の実施例でいうプログラムは、上記した可搬用の物理媒体、固定用の物理媒体、通信媒体などの記録媒体に、コンピュータ読み取り可能に記録されるものであり、コンピュータシステムは、このような記録媒体からプログラムを読み出して実行することで上記した実施例と同様の機能を実現する。なお、この他の実施例でいうプログラムは、コンピュータシステムによって実行されることに限定されるものではなく、他のコンピュータシステムまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。付記1コンピュータに、階層構造で一意に特定されるデータで問い合わせ結果を返却するデータベースを含む種別の異なる複数のデータベースに分散するデータを、各データベースに対する問い合わせ形式で問い合わせを行って取得した問い合わせ結果をビューに統合して出力することにより参照させるデータベース統合参照プログラムであって、前記コンピュータに、前記階層構造で一意に特定されるデータの要素と各データベースの要素との対応関係、及び各データベース間の要素の対応関係により定義される前記ビューの生成ルールを記憶するビュー生成ルール記憶手順と、前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を、前記前記ビュー生成ルールに基づいて構成する問い合わせ処理手順とを実行させることを特徴とするデータベース統合参照プログラム。付記2コンピュータに、予め構造が定められているタグ付き文書で問い合わせ結果を返却するタグ付き文書データベースを含む種別の異なる複数のデータベースに分散するデータを、各データベースに対する問い合わせ形式で問い合わせを行って取得した問い合わせ結果をビューに統合して出力することにより参照させるデータベース統合参照プログラムであって、前記コンピュータに、前記タグ付き文書の要素と各データベースの要素との対応関係、及び各データベース間の要素の対応関係により定義される前記ビューの生成ルールを記憶するビュー生成ルール記憶手順と、前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を、前記前記ビュー生成ルールに基づいて構成する問い合わせ処理手順とを実行させることを特徴とするデータベース統合参照プログラム。付記3前記ビュー生成ルール記憶手順では、前記タグ付き文書が含む同一構造を繰り返す繰り返し構造をさらに記憶し、前記問い合わせ処理手順では、前記タグ付き文書で問い合わせ結果を返却するデータベースに対する問い合わせに際し、前記ビュー生成ルール記憶手順により記憶されている前記繰り返し構造を使用して該繰り返し構造に含まれるデータを取得することを特徴とする付記1又は2に記載のデータベース統合参照プログラム。付記4前記ビュー生成ルール記憶手順では、前記ビュー生成ルールにおける各要素の最大出現回数をさらに記憶し、前記問い合わせ処理手順では、前記タグ付き文書内において要素の出現回数を判定する要素出現回数判定手順と、前記ビュー生成ルール記憶手順により記憶されている前記ビュー生成ルールにおける各要素の最大出現回数及び前記要素出現回数判定手順により判定された要素の出現回数に基づいて各データベース間で対応付けることができる要素か否かを判定する要素対応付け判定手順とをコンピュータにさらに実行させることを特徴とする付記1又は2に記載のデータベース統合参照プログラム。付記5前記ビュー生成ルール記憶手順では、前記ビューの生成ルールで対応付けられている前記タグ付き文書の要素及び前記各データベースの要素それぞれの名称をさらに記憶し、前記問い合わせ処理手順では、前記タグ付き文書の要素の名称で前記ビューに対する問い合わせを受け付け、該タグ付き文書の要素の名称を前記各データベースの要素の名称へ変換し、前記各データベースの要素の名称で各データベースに対する問い合わせを行って問い合わせ結果取得することを特徴とする付記1又は2に記載のデータベース統合参照プログラム。付記6前記ビュー生成ルール記憶手順では、前記タグ付き文書には存在しない要素をさらに記憶し、前記問い合わせ処理手順では、前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を、前記タグ付き文書には存在しない要素を含んで構成することを特徴とする付記1又は2に記載のデータベース統合参照プログラム。付記7前記ビュー生成ルール記憶手順では、前記ビューの生成ルールにおける前記タグ付き文書の要素の隠蔽の指示をさらに記憶し、前記問い合わせ処理手順では、前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を前記前記ビュー生成ルールに基づいて構成する際に、前記タグ付き文書の要素の隠蔽の指示に基づき該要素を隠蔽することを特徴とする付記1又は2に記載のデータベース統合参照プログラム。付記8前記問い合わせ処理手順では、前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を前記前記ビュー生成ルールに基づいて構成する際に、前記ビュー生成ルールに含まれない要素が存在した場合、該要素を文字列として取り扱うことを特徴とする付記1又は2に記載のデータベース統合参照プログラム。付記9予め構造が定められているタグ付き文書で問い合わせ結果を返却するタグ付き文書データベースを含む種別の異なる複数のデータベースに分散するデータを、各データベースに対する問い合わせ形式で問い合わせを行って取得した問い合わせ結果をビューに統合して出力することにより参照可能とするデータベース統合参照方法であって、前記タグ付き文書の要素と各データベースの要素との対応関係、及び各データベース間の要素の対応関係により定義される前記ビューの生成ルールを記憶するビュー生成ルール記憶工程と、前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を、前記前記ビュー生成ルールに基づいて構成する問い合わせ処理工程とを含んだことを特徴とするデータベース統合参照方法。付記10前記ビュー生成ルール記憶工程は、前記タグ付き文書が含む同一構造を繰り返す繰り返し構造をさらに記憶し、前記問い合わせ処理工程は、前記タグ付き文書で問い合わせ結果を返却するデータベースに対する問い合わせに際し、前記ビュー生成ルール記憶工程により記憶される前記繰り返し構造を使用して該繰り返し構造に含まれるデータを取得することを特徴とする付記9に記載のデータベース統合参照方法。付記11前記ビュー生成ルール記憶工程は、前記ビュー生成ルールにおける各要素の最大出現回数をさらに記憶し、前記問い合わせ処理工程は、前記タグ付き文書内において要素の出現回数を判定する要素出現回数判定工程と、前記ビュー生成ルール記憶手段に記憶される前記ビュー生成ルールにおける各要素の最大出現回数及び前記要素出現回数判定工程により判定された要素の出現回数に基づいて各データベース間で対応付けることができる要素か否かを判定する要素対応付け判定工程とをさらに含んだことを特徴とする付記9に記載のデータベース統合参照方法。付記12前記ビュー生成ルール記憶工程は、前記ビューの生成ルールで対応付けられる前記タグ付き文書の要素及び前記各データベースの要素それぞれの名称をさらに記憶し、前記問い合わせ処理工程は、前記タグ付き文書の要素の名称で前記ビューに対する問い合わせを受け付け、該タグ付き文書の要素の名称を前記各データベースの要素の名称へ変換し、前記各データベースの要素の名称で各データベースに対する問い合わせを行って問い合わせ結果取得することを特徴とする付記9に記載のデータベース統合参照方法。付記13前記ビュー生成ルール記憶工程は、前記タグ付き文書には存在しない要素をさらに記憶し、前記問い合わせ処理工程は、前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を、前記タグ付き文書には存在しない要素を含んで構成することを特徴とする付記9に記載のデータベース統合参照方法。付記14前記ビュー生成ルール記憶工程は、前記ビューの生成ルールにおける前記タグ付き文書の要素の隠蔽の指示をさらに記憶し、前記問い合わせ処理工程は、前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を前記前記ビュー生成ルールに基づいて構成する際に、前記タグ付き文書の要素の隠蔽の指示に基づき該要素を隠蔽することを特徴とする付記9に記載のデータベース統合参照方法。付記15前記問い合わせ処理工程は、前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を前記前記ビュー生成ルールに基づいて構成する際に、前記ビュー生成ルールに含まれない要素が存在した場合、該要素を文字列として取り扱うことを特徴とする付記9に記載のデータベース統合参照方法。付記16予め構造が定められているタグ付き文書で問い合わせ結果を返却するタグ付き文書データベースを含む種別の異なる複数のデータベースに分散するデータを、各データベースに対する問い合わせ形式で問い合わせを行って取得した問い合わせ結果をビューに統合して出力することにより参照可能とするデータベース統合参照装置であって、前記タグ付き文書の要素と各データベースの要素との対応関係、及び各データベース間の要素の対応関係により定義される前記ビューの生成ルールを記憶するビュー生成ルール記憶手段と、前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を、前記前記ビュー生成ルールに基づいて構成する問い合わせ処理手段とを備えたことを特徴とするデータベース統合参照装置。付記17前記ビュー生成ルール記憶手段は、前記タグ付き文書が含む同一構造を繰り返す繰り返し構造をさらに記憶し、前記問い合わせ処理手段は、前記タグ付き文書で問い合わせ結果を返却するデータベースに対する問い合わせに際し、前記ビュー生成ルール記憶手段により記憶される前記繰り返し構造を使用して該繰り返し構造に含まれるデータを取得することを特徴とする付記16に記載のデータベース統合参照装置。付記18前記ビュー生成ルール記憶手段は、前記ビュー生成ルールにおける各要素の最大出現回数をさらに記憶し、前記問い合わせ処理手段は、前記タグ付き文書内において要素の出現回数を判定する要素出現回数判定手段と、前記ビュー生成ルール記憶手段に記憶される前記ビュー生成ルールにおける各要素の最大出現回数及び前記要素出現回数判定手段により判定された要素の出現回数に基づいて各データベース間で対応付けることができる要素か否かを判定する要素対応付け判定手段とをさらに含んだことを特徴とする付記16に記載のデータベース統合参照装置。付記19前記ビュー生成ルール記憶手段は、前記ビューの生成ルールで対応付けられる前記タグ付き文書の要素及び前記各データベースの要素それぞれの名称をさらに記憶し、前記問い合わせ処理手段は、前記タグ付き文書の要素の名称で前記ビューに対する問い合わせを受け付け、該タグ付き文書の要素の名称を前記各データベースの要素の名称へ変換し、前記各データベースの要素の名称で各データベースに対する問い合わせを行って問い合わせ結果取得することを特徴とする付記16に記載のデータベース統合参照装置。付記20前記ビュー生成ルール記憶手段は、前記タグ付き文書には存在しない要素をさらに記憶し、前記問い合わせ処理手段は、前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を、前記タグ付き文書には存在しない要素を含んで構成することを特徴とする付記16に記載のデータベース統合参照装置。付記21前記ビュー生成ルール記憶手段は、前記ビューの生成ルールにおける前記タグ付き文書の要素の隠蔽の指示をさらに記憶し、前記問い合わせ処理手段は、前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を前記前記ビュー生成ルールに基づいて構成する際に、前記タグ付き文書の要素の隠蔽の指示に基づき該要素を隠蔽することを特徴とする付記16に記載のデータベース統合参照装置。付記22前記問い合わせ処理手段は、前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を前記前記ビュー生成ルールに基づいて構成する際に、前記ビュー生成ルールに含まれない要素が存在した場合、該要素を文字列として取り扱うことを特徴とする付記16に記載のデータベース統合参照装置。