JP2011222045A - データベース統合参照プログラム - Google Patents

Abstract

【課題】分散する各データベースの種別の差異を吸収して、統合データビューを使用した問い合わせ処理を可能とする。
【解決手段】本発明のデータベース統合参照プログラムが実行されるデータベース統合参照装置２０は、問い合わせ結果の出力に用いるＸＭＬファイルの構造、当該ＸＭＬファイル中の各要素と各データベースの各要素との対応関係、並びに、各データベース間の各要素の対応関係が規定された統合用メタデータを記憶する。そして、かかる統合用メタデータを利用し、ＸＭＬ−ＤＢ及びＲＤＢを含む複数のデータベースに分散しているデータを統合して１つの仮想的なＸＭＬファイルとしてユーザに意識させ、そのデータに対してＸＱｕｅｒｙというＸＭＬ問い合わせ言語で記述された問い合わせを受け付け、統合されたデータをＸＭＬ形式で取り出してユーザ端末１０に出力する。
【選択図】図３

Description

本発明は、階層構造で一意に特定されるデータ、特に、予め構造が定められているタグ付き文書で問い合わせ結果を返却するタグ付き文書データベースを含む種別の異なる複数のデータベースに分散するデータを、各データベースに対する問い合わせ形式で問い合わせを行って取得した問い合わせ結果をビューに統合して出力することにより参照可能とするデータベース統合参照プログラム等に関する。

近年、負荷分散及び危険分散の観点から、複数のデータベースにデータを分散して配置する分散型データベースが運用の主流となりつつある。複数のデータベースにデータを分散することにより、問い合わせの集中による負荷の分散を図り、障害発生時には、当該データベースに障害の影響範囲を限定して、システム全体の信頼性の向上を図るものである。

かかる分散型データベースは、データは各データベースに分散して配置されるが、データ参照の際には、あたかも一つのデータベースであるかの様に利用可能である機能を有することを特徴とする。このような機能を実現する手法として、例えば、特許文献１に開示されるように、複数のＲＤＢ（Relational Data Base）に配置されるデータを、タグ付き文書形式の統合データビューに統合して、該統合データビューに対する問い合わせを実行させることにより、該複数のＲＤＢへの統合参照に基づく問い合わせを可能とする技術がある。

特開２００５−２０８７５７号公報

しかしながら、最近では、データベースの種別が多様化し、従来のＲＤＢとは異なるデータベースが登場してきている。例えば、ＸＭＬ（eXtensible Markup Language）形式でデータを保持するＸＭＬ−ＤＢ（eXtensible Markup Language-Data Base）などである。よって、分散型データベースが、ＸＭＬ−ＤＢ等のＲＤＢとは異なるデータベースを含んで構成され得ることとなってきている。

前述のＸＭＬ−ＤＢは、スキーマが不定又は半固定であるために、このスキーマに基づいて定義した統合データビューのスキーマが不定になる。一方で、ＲＤＢは、スキーマが厳格に定められる。このために、上記特許文献１に代表される従来技術を利用したとしても、統合データビューのスキーマが不定となり得るという性質上、ＸＭＬ−ＤＢ及びＲＤＢを含む複数のＤＢに対して該統合データビューを使用した問い合わせ処理が不可能となるという問題があった。

このように、データベースの種別の多様化によって、分散する各データベースの種別の差異のために、統合データビューを使用した問い合わせ処理が不可能となるという問題が発生することとなる。

また、ＸＭＬ−ＤＢに格納されているデータのスキーマと、ユーザが望む統合データビュー上のスキーマとは一致するとは限らない。ＸＭＬ−ＤＢから取得したＸＭＬ文書データをそのまま統合データビューの中に当てはめるのでは、ユーザが望む統合データビューを提供できない場合が発生する。

一つの側面では、分散する各データベースの種別の差異を吸収して、ユーザが望む統合データビューを使用した問い合わせ処理を可能とするデータベース統合参照プログラム等を提供することを目的とする。

上述した問題を解決し、目的を達成するため、開示の技術は、入力する問い合わせに基づいて、それぞれデータ形式が異なる複数のデータベースに分散されたデータを取得し、取得したデータを第一の形式のビューに統合して出力する機能をコンピュータに実行させる、データベース統合参照プログラムにおいて、第１の形式による問い合わせの入力を受け付け、前記受け付けた問い合わせを内部形式に変換し、複数のデータベースにまたがる関連データの出力形式を示す情報と、第一の形式による文書の要素と前記複数のデータベースそれぞれの要素との対応関係を示す情報と、前記複数のデータベース間の要素の対応関係を示す情報とを参照して、問い合わせ対象の第一の形式による文書の構造と、前記第一の形式による文書の各要素に対応するデータベースを判別し、判別したデータベースに、問い合わせ条件に合致するデータを問い合わせ、前記問い合わせの結果得られたデータを、第一の形式の文書に組み立て、組み立てた文書を問い合わせ結果として返信することを特徴とする。

開示の技術によれば、階層構造で一意に特定されるデータで問い合わせ結果を返却するデータベースを含む種別の異なる複数のデータベースに分散するデータを、各データベースに対する問い合わせ形式で問い合わせを行って取得した問い合わせ結果をビューに統合して出力することにより参照可能となり、データの分散を意識することなく問い合わせを行うことが可能になり、データベース開発作業の自由度が高くなるという効果を奏する。

また、開示の技術によれば、予め構造が定められているタグ付き文書で問い合わせ結果を返却するタグ付き文書データベースを含む種別の異なる複数のデータベースに分散するデータを、各データベースに対する問い合わせ形式で問い合わせを行って取得した問い合わせ結果をビューに統合して出力することにより参照可能となり、データの分散を意識することなく問い合わせを行うことが可能になり、データベース開発作業の自由度が高くなるという効果を奏する。

また、開示の技術によれば、タグ付き文書データベース内のタグ付き文書データに含まれる一定の繰り返し構造を記憶し、該記憶されている繰り返し構造に基づいて問い合わせ結果としてデータを取得することが可能となり、統合の対象となるタグ付き文書データベースの範囲が広がるという効果を奏する。

また、開示の技術によれば、タグ付き文書データベースから返るタグ付き文書データのスキーマの中で、他のデータベースとの関連付けに使用できるノードを限定せず、関連付けに使用できるノードの選択肢が増え、統合データビューの設計の自由度が向上し、上位アプリケーション開発の自由度も向上するという効果を奏する。

また、開示の技術によれば、統合データビューのスキーマに規定される要素の名称を、タグ付き文書データベースから返るタグ付き文書データのスキーマに規定される要素の名称に依存することなく定めることが可能となり、統合データビューのスキーマに規定される要素の名称を人が見やすい形式に定めることが可能となるという効果を奏する。

また、開示の技術によれば、タグ付き文書データベースから返るタグ付き文書データのスキーマに存在しない要素を、統合データビューのスキーマに含めることが可能となり、統合データビューのスキーマを自由に決めることが可能となる。これによって、上位アプリケーション開発の自由度を大幅に向上させるという効果を奏する。

また、開示の技術によれば、タグ付き文書データベースから返るタグ付き文書データのスキーマに存在する要素を、統合データビューのスキーマに含めないようにすることが可能となり、統合データビューのスキーマを自由に決めることが可能となる。これによって、上位アプリケーション開発の自由度を大幅に向上させるという効果を奏する。

また、開示の技術によれば、タグ付き文書データベースから返るタグ付き文書データが不定である又は半構造性を持つ場合にも統合可能となるので、統合の対象となるタグ付き文書データベースの範囲が広がるという効果を奏する。

実施例１に係るデータベース統合参照システムの概要および特徴を説明するための図である。 実施例１に係るデータベース統合参照システムの概要および特徴を説明するための図である。 実施例１に係るデータベース統合参照システムの全体構成を示すシステム構成図である。 各ＤＢに記憶される情報の構成例を示す図である。 ＤＢデータのＸＭＬへのマッピング例を示す図である。 統合用メタデータ（特に、仮想ＸＭＬスキーマ情報）の例を示す図である。 統合用メタデータ（特に、データベース情報（１））の例を示す図である。 統合用メタデータ（特に、データベース情報（２））の例を示す図である。 統合用メタデータ（特に、要素間の関連付け情報）の例を示す図である。 問い合わせ処理手順を示すフローチャートである。 問い合わせ処理手順の具体例を示す図である。 問い合わせ処理手順の具体例を示す図である。 問い合わせ処理手順の具体例を示す図である。 問い合わせ処理手順の具体例を示す図である。 問い合わせ処理手順の具体例を示す図である。 問い合わせ処理手順の具体例を示す図である。 問い合わせ処理手順の具体例を示す図である。 問い合わせ処理手順の具体例を示す図である。 実施例１の特徴を説明するための図である。 実施例２の第１の特徴を説明するための図である。 実施例２の第２の特徴を説明するための図である。 実施例２の第３の特徴を説明するための図である。 実施例２の第４の特徴を説明するための図である。 実施例２の第５の特徴を説明するための図である。 実施例２の第６の特徴を説明するための図である。

以下に添付図面を参照して、開示の技術に係るデータベース統合参照プログラム等の実施例を詳細に説明する。なお、以下に示す実施例では、開示の技術を、ＸＭＬ−ＤＢ（eXtensible Markup Language-Data Base）とＲＤＢ（Relational Data Base）とを統合して参照可能とするデータベース統合参照プログラム、データベース統合参照方法及びデータベース統合参照装置に適用し、タグ付き文書をＸＭＬ文書とした場合を示すこととする。なお、以下に、データベースをＤＢ（Data Base）と略記する場合がある。

先ず、図１及び図２を用いて、実施例１に係るデータベース統合参照システムの概要および特徴を説明する。図１及び図２は、実施例１に係るデータベース統合参照システムの概要および特徴を説明するための図である。

図１に示すように、実施例１に係るデータベース統合参照システムは、ＸＭＬ−ＤＢ及びＲＤＢを含む複数のデータベース（ＲＤＢ（１）、ＲＤＢ（２）及びＸＭＬ−ＤＢ）とユーザ端末との間にデータベース統合参照装置が介在して形成され、概略的には、このデータベース統合参照装置が、複数のデータベースに対するデータ参照の問い合わせをユーザ端末から受け付け、各データベースから問い合わせに係るデータを取得し、問い合わせ結果をユーザ端末に返すというものである。

そして、かかるシステムのデータベース統合参照装置では、図１及び図２に示すように、統合用メタデータの利用によって、複数のデータベースに分散しているデータを統合して１つの仮想的なＸＭＬ文書（例えば、ＸＭＬファイル）としてユーザに意識させ、そのデータに対してＸＭＬ文書に対する問い合わせ形式でデータ参照の問い合わせ（例えば、ＸＱｕｅｒｙというＸＭＬ問い合わせ言語で記述された問い合わせ）を受け付け、統合されたデータをＸＭＬ形式で取り出すことを特徴とする。

より具体的には、データベース統合参照装置では、統合したＤＢのデータをＸＭＬというモデルで提供するための統合問い合わせエンジンを構築し、分散しているデータをＸＭＬファイルのようにハンドルすることで、データベース統合参照装置側でのデータビュー統合を実現する。

このようなことから、実施例１に係るデータベース統合参照システムによれば、以下に列挙するように、リアルタイムなデータアクセス、上位アプリケーションの開発工数の大幅削減、自由度および拡張性が高いＤＢ統合、段階的なメタデータ構築などが可能になる。

すなわち、本実施例１では、分散しているデータをＤＷＨ（データウェアハウス）のように物理的に一箇所に集めるのではなく、既存のＤＢに分散して配置された状態のまま、問い合わせ時に必要なデータだけを獲得し、結果として統合的なデータビューを作り上げる。これによって、リアルタイムなデータアクセスが可能になる。

また、本実施例１では、分散しているデータをＸＭＬ形式のファイルに統合するので、そのＸＭＬファイルに対してＸＱｕｅｒｙで問い合わせを行い、問い合わせ結果もＸＭＬ形式で取り出すことができる。つまり、上位アプリケーション側に対して、ＸＭＬファイルによって統合されたデータビューを提供することができるので、上位アプリケーション側でデータビュー統合のための機能を作りこむ必要がなくなり、これによって、上位アプリケーションの開発工数の大幅削減が可能になる。

また、本実施例１では、ＸＭＬ−ＤＢ及びＲＤＢを含む複数のデータベースのデータをモデル変換を経て、最終的にＸＭＬファイルのデータビューに統合する。かかるＸＭＬファイル形式は自由度および拡張性が高いので、この統合されたＸＭＬファイルに対して柔軟な使い方が可能になる。即ち、本実施例１によるデータビューはＸＭＬによって統合されているため、検索システムだけではなく、ＸＭＬに対応した様々なアプリケーションシステムを本実施例１に係るシステム上に容易に構築することができるなど、自由度および拡張性が高いＤＢ統合が可能になる。

また、本実施例１では、複数の分散しているデータからどのようなデータビューを構成するかを、統合用メタデータで自由に定義するが、その際、問い合わせに必要な情報のみで定義することができる。これによって、初めから全ての情報を定義しておく必要がなくなり、段階的に統合用メタデータを構築することが可能になる。

次に、実施例１に係るデータベース統合参照システムの全体構成を説明する。図３は、実施例１に係るデータベース統合参照システムの全体構成を示すシステム構成図である。同図に示すように、実施例１に係るデータベース統合参照システムは、ユーザ端末１０と、複数のデータベース（ＸＭＬ−ＤＢ（受注ＤＢ１１）、ＲＤＢ（１）（商品ＤＢ１２）、ＲＤＢ（２）（在庫ＤＢ１３））と、データベース統合参照装置２０とを、ＬＡＮやインターネットなどのネットワークを介して相互に通信可能に接続して構成される。

このうち、各データベースは、実施例１によって統合されるデータベースである。実施例１では、受注ＤＢ１１をＸＭＬ−ＤＢとし、商品ＤＢ１２及び在庫ＤＢ１３をＲＤＢとする。実施例１では、図３に例示するように、受注ＤＢ１１、商品ＤＢ１２及び在庫ＤＢ１３の３つのＤＢにデータが分散されている例を挙げている。

ここで、受注ＤＢ１１は、ある企業が受注した注文に係る情報を記憶するＤＢであり、ＤＢ内の注文伝票ＸＭＬ１１ａは、図４に例示するように、“order（注文）”に、“id（注文ＩＤ）”、“purchaser（購入者）”、“item（商品名）”、“date（受注年月日）”の各要素のデータを配下に持つ木構造となるように構成される。さらに、注文伝票ＸＭＬ１１ａは、“order”内の“item”に、“item_code（商品コード）”、“quantity（受注数量）”の各要素のデータを配下に持つ木構造となるように構成される。このようにして“order”配下に構成される木構造が、１件分の注文伝票に相当する受注レコードに相当する。なお、１件の注文には複数の注文商品が含まれ得るので、注文伝票ＸＭＬ１１ａの１レコードには、“item”とその配下の“item_code”及び“quantity”とで構成される部分木が繰り返して出現し得るものである。

商品ＤＢ１２は、上記の企業が取り扱う取扱商品に係る情報を記憶するＤＢであり、ＤＢ内の取扱商品テーブル１２ａは、図４に例示するように、取扱商品ごとに“code（商品コード）”、“name（商品名）”の各要素のデータを相互に対応付けて構成される。

在庫ＤＢ１３は、上記の取扱商品の在庫に係る情報を記憶するＤＢであり、ＤＢ内の在庫テーブル１３ａは、図４に例示するように、取扱商品ごとに“code（商品コード）”、“quantity（在庫数量）”の各要素のデータを相互に対応付けて構成される。

ここで、上記の注文伝票上では、商品の種類は商品コードでしか記述されていないが、人が注文伝票を見るときには商品名で表示された方が見やすい。そこで、商品ＤＢ１２の取扱商品テーブル１２ａを用いて注文伝票の商品コードを商品名に変換したいとユーザが考えたような場合に、本実施例１によるデータベース統合参照システムを利用するメリットがある。

また、注文伝票を見ながらその注文を処理するときに、同時に在庫数も表示させて在庫を確認したいとユーザが考えたような場合にも、本実施例１によるデータベース統合参照システムを利用するメリットがある（なお、この場合には、各商品の在庫数を在庫ＤＢから取ってくることになるが、各商品の在庫数は商品によって在庫ＤＢ１３に格納されているので両者に在庫数を問い合わせることになる）。

このように、ユーザは、上記した３つのデータベースに分散している１つの注文に関連するデータを、１つに纏めて参照したいような場合に、本実施例１によるデータベース統合参照システムを利用するメリットがある。

図３に戻って、ユーザ端末１０は、データベース統合参照装置２０を介して複数のデータベースに対するデータ参照の問い合わせを行うユーザの端末であり、既知のパーソナルコンピュータやワークステーション、ＰＤＡ、あるいは携帯電話やＰＨＳの如き移動体通信端末などで構成される。

そして、ユーザ端末１０は、主として、図１や図２に例示したように、ＸＱｕｅｒｙというＸＭＬ問い合わせ言語で記述された問い合わせ（ＸＱｕｅｒｙ問い合わせ）をキーボードやマウス等を介してユーザに入力させる機能、入力されたＸＱｕｅｒｙ問い合わせをデータベース統合参照装置２０に送信する機能、データベース統合参照装置２０からＸＭＬ形式の問い合わせ結果を受信する機能、及び受信した問い合わせ結果をモニタ等に出力する機能などを有する。

なお、図２に例示したように、実施例１に係るデータベース統合参照システムによって、ユーザには、各注文に関する情報が１つに纏められて、それが“order”タグで囲まれて、１枚の大きなＸＭＬファイルの中に全ての注文が並んで格納されているように見える。ただし、これはあくまでも論理的なビューであって、データの実体は各データベースの中にしかない。そのような論理的なビューが存在すると思って、ユーザがデータベース統合参照装置２０に問い合わせを行うと、該当する注文の分のＸＭＬ文書データが返ってくる。

図３に戻って、データベース統合参照装置２０は、ユーザ端末１０から受け付けたデータ参照の問い合わせを処理する既知のサーバコンピュータであり、主として、ユーザ端末１０からＸＱｕｅｒｙ問い合わせを受信する機能、各データベースから問い合わせに係るデータを取得してＸＭＬの問い合わせ結果を生成する機能、生成したＸＭＬの問い合わせ結果をユーザ端末１０に送信する機能などを有する。以下に、本実施例１の主たる特徴を担うデータベース統合参照装置２０の構成を詳細に説明する。

データベース統合参照装置２０は、図３に例示するように、記憶部２１と、制御部２２とを備えて構成される。このうち、記憶部２１は、制御部２２による各種処理に必要なデータおよびプログラムを記憶する手段であり、特に本発明に密接に関連するものとしては、同図に例示するように、統合用メタデータ２１ａをリポジトリに記憶する。

かかる統合用メタデータ２１ａは、各データベースを統合するために必要な情報が規定されたものであるが、具体的には、図６〜図９に例示するように、仮想ＸＭＬスキーマ情報、データベース情報（１）及び（２）、並びに、要素間の関連付け情報が記載されて構成される。

より詳細には、仮想ＸＭＬスキーマ情報としては、図６に例示するように、複数のデータベースに跨る関連データを、どのようなフォーマットのＸＭＬ文書データとしてユーザに見せるかという情報が規定される。

図６を参照して、仮想ＸＭＬスキーマ情報について具体的に説明する。仮想ＸＭＬスキーマ情報ＸＭＬスキーマに似たフォーマットを使用して、統合データビューのＸＭＬ構造を定義する。スキーマを構築するノードには次の（Ａ１）〜（Ａ３）の３種類がある。

（Ａ１）ComplexElement
これは、配下に他のノードを持つ中間ノードである。対応するデータベースがＲＤＢの場合は、これと配下のSimpleElementの組み合わせでデータベースの１レコードに対応する。対応するデータベースがＸＭＬ−ＤＢの場合は、配下に他のノードを持つ中間ノードであって、これ自体は値を持たないことを意味する。ComplexElementは、以下の属性を保有する。なお、このComplexElementノードの配下にはComplexElement 、SimpleElement及びTagElementの３種類いずれのノードも出現し得る。

名前：統合データビュー上での、当該ノードのタグ名。
可視化の可否：統合データビュー上で表示するか否か。
最大出現数：当該ノードが反復して出現する回数の上限。
最小出現数：当該ノードが反復して出現する回数の下限。
ダミー指定：該当するデータベースがＸＭＬ−ＤＢ場合に、このノードがそのＸＭＬデータにおいて実在しないノードであるか否か。

（Ａ２）SimpleElement
配下に値を持つ末端ノードである。対応するデータベースがＲＤＢの場合は、レコード内の１カラムに対応し、その値だけを保持する。対応するデータベースがＸＭＬ−ＤＢの場合は、値を持つ末端ノードに対応する。SimpleElementは、以下の属性を保有する。なお、このSimpleElementノードは末端ノードなので、この下にはいずれのノードも出現できない。

名前：統合データビュー上での、このノードのタグ名。
可視化の可否：統合データビュー上で表示するか否か。
スキーマレス指定：該当するデータベースがＸＭＬ−ＤＢの場合に、このノードの配下に出現する全てのタグを単なる文字列として扱うことによって、配下に自由なスキーマの出現を許すか否か。

（Ａ３）TagElement
タグを挿入するためのダミーのノードである。対応するデータベース要素を持たない。このTagElementは、名前：統合データビュー上での、このノードのタグ名、という属性を保有する。なお、このComplexElementノードの配下にはComplexElement 、SimpleElement及びTagElementの３種類いずれのノードも出現し得る。

また、ComplexElementとTagElementには、そのノードに対応するデータベース要素との対応関係を取る為に、固有のＩＤが与えられる。それぞれをComplexElement-IDとSimpleElement-IDという。対応するデータベースがＲＤＢの場合は、１つのComplexElementと１つ以上のSimpleElementの組でＲＤＢの１レコードに対応し、その組み合わせ同士を相互に連結して木構造を組み立てる。連結する際には、双方の間で関連付け（値のマッチング）を取ることができる項目が必要である。

また、それとは無関係に、ダミーのタグを加えたい場所にTagElementを挿入することができる。対応するデータベースがＸＭＬ−ＤＢの場合は、ＸＭＬＤＢに格納されているＸＭＬデータのスキーマに合わせて仮想ＸＭＬスキーマを構築する必要がある。元のＸＭＬデータのスキーマに存在しないタグを加えたい場合はTagElementを使用し、元のＸＭＬデータのスキーマに存在するタグを削りたいときは、そのタグの「可視化の可否」という属性を“FALSE”に設定することで対応することが出来る。

また、データベース情報としては、図７及び図８に例示するように、ＸＭＬの中の各要素（図６参照）に、どのデータベースのどの要素が対応するのかという情報が規定される。データベース情報では、仮想ＸＭＬスキーマ内の各要素(ComplexElement、 SimpleElement)に、実際はどのデータベースのどの項目が対応するのかを記述する。対応するデータベースがＲＤＢかＸＭＬ−ＤＢかによって、記述する内容は大きく異なる。なお、データベース名は、タグ「databaseID」によってＩＤで示されている。このＩＤと実際のＤＢ名の対応表は、別に管理されている。また、テーブル名はタグ「tableID」により、カラム名はタグ「columnID」によって、ＩＤで示されている。これらのＩＤと実際のテーブル名、カラム名との対応表は、別に管理されている。

対応するデータベースがＲＤＢの場合は、それぞれのComplexElementがどのＲＤＢのどのテーブルに対応するかを記述し、そのComplexElementの配下の各SimpleElementがそれぞれそのテーブルの中のどのカラムに対応するのかを記述する。

対応するデータベースがＸＭＬ−ＤＢの場合は、どのCompelxElementから成る部分木がどのＸＭＬ−ＤＢのデータに対応するかを記述する。さらには、データビュー上のタグ名とＸＭＬ−ＤＢ上のタグ名が異なる場合は、その対応を記述する（記述が無かったCompelxElement、 SimpleElementについては、データビュー上のタグ名とＸＭＬ−ＤＢ上のタグ名が同じであると見なす）。また、ＸＭＬ−ＤＢに格納されている大きなＸＭＬデータの中の一部の反復構造のみを処理対象としたい場合には、ルートからその反復構造までのパスをここに記述する。

さらに、要素間の関連付け情報としては、図９に例示するように、異なるテーブルの異なるレコード同士を関連付けて１つのＸＭＬとする場合に、各テーブルのどのカラムでそれぞれ対応をとるか（関連付けるか）という情報が規定される。

要素間の関連付け情報では、ＲＤＢに対応する「ComplexElement、SimpleElementの組み合わせ」同士や、それとＸＭＬ−ＤＢに対応するＸＭＬ部分木を結びつける為の情報を記述する。具体的には、どのSimpleElementとどのSimpleElementとで値のマッチングを取るかを記述する。実施例１では、関連付けは「値の完全一致」という一種類しか用意していない。

ＲＤＢに対応する「ComplexElement、SimpleElementの組み合わせ」の場合は、その中のSimpleElementがどれでも関連付けに使用できる。一方、ＸＭＬ−ＤＢに対応するＸＭＬ部分木の場合は、関連付けに使用できるSimpleElementは１対１の対応関係を保障する為に制約される。他のデータベースが下位に接続される場合は、仮想ＸＭＬスキーマ情報において接続箇所となっている（接続相手のデータベースに対応するノードがその下位に出現する）ComplexElementについて、その子ノードであるSimpleElementだけが関連付けに使用できる。他のデータベースが上位に接続される場合は、このＸＭＬ部分木の最上位のComplexElementの子ノードであるSimpleElementだけが関連付けに使用できる。

ところで、関連付けに使用できるSimpleElementが制約されると生成できる仮想ＸＭＬビューが制限されて不便である。そこで、ComplexElementに設定されている最大出現数を利用して、その制約を緩くすることが可能である。もし接続箇所となっているComplexElementの最大出現数が１ならば、ＸＭＬ部分木において上位に隣接するComplexElementの子ノードのSimpleElementにまで関連付けの範囲を拡大することが可能である。再帰的に、ComplexElementの最大出現数が１である限り、さらに１つ上位のComplexElementの子ノードのSimpleElementにまで関連付けの範囲を拡大することが可能である。逆に、もし接続箇所となっているComplexElementについて、その配下のComplexElementの最大出現数が１ならば、関連付けの範囲をそのComplexElementの子ノードのSimpleElementにまで拡大することが出来る。さらに下位のComplexElementに関しても、再帰的に関連付けの範囲を拡大していくことが可能である。

図６〜図９に分けて例示した統合用メタデータは、１つの統合用メタデータであり、１つのＸＭＬ形式のファイルに含まれる。このような統合用メタデータ２１ａを記憶部２１は予め記憶しているが、かかる統合用メタデータは、システムの管理者等によるマッピング作業（図５参照）を通じて作成される。すなわち、図５に例示するマッピング例は、図４に例示した３つのデータベースのデータを、ＸＭＬの木構造にマッピングした例であるが、このようなマッピング作業をシステム管理者等が行うことで、統合用メタデータ２１ａには、図５に例示する内容と同内容の情報がＸＭＬ形式で記述され、そして、ユーザには、統合されたデータが図５に例示するフォーマットのＸＭＬ文書データとして見えることになる。

なお、データベースのデータをＸＭＬの木構造にマッピングする手法（ルール）は以下の通りである。（１）ユーザには、データベースを跨って１つに組み合わされたデータが、１つのＸＭＬの中にデータ数だけ反復して入っているように見える。（２）統合したいデータベースのデータを、テーブル単位でＸＭＬのエレメントにマッピングする。（３）テーブルに対応するＸＭＬのエレメントは、階層的に配置することができる。（４）テーブルに対応するＸＭＬのエレメントのうち、階層構造上で上下に隣接するエレメント同士は、対応するテーブル同士でデータが関連付けできる必要がある。つまり、お互いのテーブル同士で、ある1つのカラム同士が同じ値を取らなければならない。（５）１つのＸＭＬエレメントに対応するテーブルは、別個のデータベースの別個のテーブルを複数指定しても構わない。（６）データベースのカラムに対応するＸＭＬのタグ名は、カラム名とは別の名前にしても構わない。

図３に戻って、データベース統合参照装置２０の制御部２２は、ＯＳ（Operating System）などの制御プログラム、各種の処理手順などを規定したプログラム及び所要データを格納するための内部メモリを有し、これらによって種々の処理を実行する処理部である。特に本発明に密接に関連するものとしては、同図に例示するように、問い合わせパーザ部２２ａと、問い合わせ処理エンジン部２２ｂと、アクセス処理部２２ｃとを備える。

このうち、問い合わせパーザ部２２ａは、ユーザ端末１０から受け付けたＸＱｕｅｒｙ問い合わせを構文解析し、構文チェックを行った後に、問い合わせ内容を内部形式へ変換する処理部である。なお、構文規則に反する問い合わせについては、その旨のエラーメッセージをユーザ端末１０に返信する。

問い合わせ処理エンジン部２２ｂは、問い合わせパーザ部２２ａで変換されたＸＱｕｅｒｙ問い合わせを実際に処理し、各データベースに対してそれぞれに応じた必要な問い合わせを行ってデータを取得するとともに、ＸＭＬで問い合わせ結果を生成してユーザ端末１０に返信する処理部である。すなわち、各データベースへどのような順番でどのような問い合わせを行ってデータを獲得するかを計画し（各データベースに対して問い合わせをするＳＱＬを生成し）、それを実行する（生成したＳＱＬをデータベースに投げて結果を得る）。そして、問い合わせた結果として各データベースから取得したデータを、最終的にユーザ端末１０に返信するＸＭＬ文書データへと組み立てる。なお、問い合わせ処理エンジン部２２ｂによる具体的な処理内容については、図１０等を用いて後に詳述する。

アクセス処理部２２ｃは、問い合わせ処理部２２ｂからデータベースへの問い合わせ要求が行われると、実際にデータベースへアクセスする処理部である。問い合わせパーザ部２２ａで変換されたＸＱｕｅｒｙ問い合わせから生成された各データベースに対応する問い合わせを、対応する各データベースへ送信する処理を行うものである。

次に、図１０〜図１８を参照して、データベース統合参照装置２０による問い合わせ処理手順を説明する。図１０は、実施例１による問い合わせ処理手順を示すフローチャートであり、図１１〜図１８は、かかる問い合わせ処理手順の具体例を示す図である。

図１０に例示するように、データベース統合参照装置２０は、ユーザ端末１０から図２に例示したようなＸＱｕｅｒｙ問い合わせの入力があると（ステップＳ１３０１肯定）、ＸＱｕｅｒｙ問い合わせを構文解析し、構文チェックを行った後に、問い合わせ内容を内部形式へ変換する（ステップＳ１３０２）。なお、構文規則に反する場合には、その旨のエラーメッセージをユーザ端末１０に返信する。

続いて、データベース統合参照装置２０は、問い合わせに関係する統合用メタデータを記憶部２１から読み込んで、問い合わせ対象となっているＸＭＬの構造と、その各エレメントに対応するデータがどのデータベースに格納されているかを求める（ステップＳ１３０３）。

具体的には、図１１に例示するように、図２に例示したようなＸＱｕｅｒｙ問い合わせについては、“order-list.xml”に対応する統合用メタデータを記憶部２１から読み出し、かかるＸＭＬの構造と、その各エレメントに対応するデータが格納されているデータベースとを求めることで、図１１に例示するような木構造で表現可能な情報を得る。

そして、データベース統合参照装置２０は、問い合わせ順序の最適化として、ステップＳ１３０３で得たＸＭＬ構造の各エレメントを、そのデータが格納されているデータベースごとに分けて、それぞれに対してユーザがＸＱｕｅｒｙ問い合わせの中で指定した条件文を検討し、最もデータが絞り込めそうなデータベースを決定する（ステップＳ１３０４）。

具体的には、図１２に例示するように、ＸＱｕｅｒｙ問い合わせに含まれる「name=“FMV-6000CL”」という条件と「quantity>=2」という条件について、商品テーブルと商品取扱テーブルのどちらに最初に問い合わせを行った方が問い合わせ結果としてのデータ量が少なくなるかを予測し、データ量が少なくなると予測されたテーブルに対する問い合わせを最初に行うことを決定する。なお、同図では、取扱商品テーブルに対して最初に問い合わせることを決定した例を示しているが、かかる問い合わせ順序の最適化手法については、後に詳述する。

その後、データベース統合参照装置２０は、ステップＳ１３０４で決定された最初のデータベースに対して条件に合致するデータを問い合わせるためのクエリを作成する（ステップＳ１３０５）。ここで作成されるクエリは、問い合わせ対象のＤＢの種別に応じた形式で作成されるものである。具体的には、問い合わせ対象のＤＢがＸＭＬ−ＤＢである場合には、クエリはＸＰａｔｈ（またはＸＰａｔｈ準拠クエリ言語）で記述され、問い合わせ対象のＤＢがＲＤＢである場合には、クエリはＳＱＬで記述される。続いて、かかるクエリを当該データベースに投げて、問い合わせ結果を得る（ステップＳ１３０６）。ただし、この時点でデータベースから求める値は、上位のエレメントと関連付けられているカラムだけでよい。

具体的には、図１３に例示するように、「name=“FMV-6000CL”」という条件に合致するデータをＲＤＢ（１）（商品ＤＢ１２）の取扱商品テーブルに問い合わせるためのＳＱＬを生成して、これを商品ＤＢに投げることで、商品ＤＢの取扱商品テーブルから条件に合致するデータとして「code=0345」を含んだ問い合わせ結果を得る。

なお、ＸＭＬ−ＤＢに対するＸＰａｔｈ（又はＸＰａｔｈ準拠クエリ言語）による副問い合わせ文の生成では、まず統合データビューに対して実行されたＸＱｕｅｒｙの中で与えられた条件式のうち、対象となっているＸＭＬ−ＤＢが対応するＸＭＬ部分木の範囲内のノードに対して条件付けしているものを選び出す。次に、それらの条件式からＸＭＬ部分木のパスに合わせてＸＰａｔｈを生成する。この作業は、ルートの位置が変わることによるパスの置き換えが発生することを除けば、ＸＱｕｅｒｙからＸＰａｔｈへの変換を行うだけである。

また、ＸＱｕｅｒｙにおいて条件式が複数存在して、条件式内のパスで使われている変数が対象としているＸＭＬ部分木の範囲外のノードにバインドされていると、複数の条件式を１つのＸＰａｔｈで纏めることが出来ない場合が発生する。この場合は、いずれかの条件式を使用しないで、どちらかデータを絞り込めそうな条件式のみを使用してＸＰａｔｈを組み立てることになる。

続いて、データベース統合参照装置２０は、前のデータベースへの問い合わせ結果を使って、順番にＸＭＬの木構造の中で上位のエレメントを求めるクエリを生成する（ステップＳ１３０７）。ここでのクエリ種別の選択方法も、ステップＳ１３０５と同様である。そして、かかるクエリを該当のデータベースに投げて問い合わせ結果を得る（ステップＳ１３０８）。このステップＳ１３０７及びステップＳ１３０８の処理を、ＸＭＬの木構造の最上位のエレメントが求まるまで繰り返し行って、データベースへの問い合わせを開始したエレメントから、次々と上位のエレメントに対応するデータの値を求めていく（ステップＳ１３０９）。

かかる処理においては、前の問い合わせ結果との関連付けを、データ絞り込みの条件として用いるとともに、ＸＱｕｅｒｙ問い合わせでユーザが指定した条件があれば、それもデータ絞込みの条件に加える。また、データベースから求める値は上位のエレメントと関連付けられているカラムだけでよいが、最上位のエレメントに達した場合は、その最上位のエレメントに対応する全てのカラムを求める。

具体的には、図１４に例示するように、前の問い合わせ結果として得た「code=0345」の関連付けから、受注ＤＢ１１に対する問い合わせを次に行うことを決定した後、かかる「code=0345」という条件と、ＸＱｕｅｒｙ問い合わせでユーザが指定した条件で未だ反映されていない「quantity>=2」という条件に合致するデータを問い合わせるためのクエリを生成する。このクエリは、ＸＰａｔｈで記述される場合は、“/order[item/(item_code=‘0345' and number>=2)]となる。

そして、生成したクエリを受注ＤＢ１１（ＸＭＬ−ＤＢ）に投げることで、注文伝票ＸＭＬから条件に合致するデータとして「<order><id>121</id><purchaser>AsianTraders</purchaser><item><item_code>0345</item_code><number>2</number></item><item><item_code>0872</item_code><number>5</number></item><date>2005-07-25</date></order>」なる問い合わせ結果を得る。なお、同図に示す例では、最上位のエレメントに達しているので、ここでは、その最上位のエレメントに対応する全てのカラムを求めている。

続いて、データベース統合参照装置２０は、ＸＭＬの最上位のエレメントが求まれば（ステップＳ１３０９肯定）、そこから下位のエレメントを順に全て求めるクエリを生成し、かかるＳＱＬ問い合わせを該当のデータベースに投げて問い合わせ結果を得るという処理（ステップＳ１３１０およびＳ１３１１）を、ＸＭＬの木構造の最上位から下位の全てのエレメントが求まるまで行って、次々と下位のエレメントに対応するデータの値を求めていく（ステップＳ１３１２）。なお、ステップＳ１３１０におけるクエリ種別の選択方法も、ステップＳ１３０５及びステップＳ１３０７と同様である。かかる処理に際しては、上位のエレメントの問い合わせ結果との関連付けを、データ絞込みの条件として指定する。また、データベースから求める値としては、エレメントに対応付けられている全てのカラムを求める。

具体的には、図１５に例示するように、「code=‘0345' OR code=‘0872'」という条件に合致するデータを受注ＤＢの商品テーブルに問い合わせるためのＳＱＬ問い合わせを生成し、これを商品テーブルに投げることで、「（code、name）=（0345、FMV-6000CL）、（0872、PRIMERGY RX300）」という問い合わせ結果を得る。

さらに、図１６に例示するように、上記の問い合わせ結果から「code=‘0345' OR code=‘0872'」という条件に合致するデータを在庫ＤＢ１３の在庫テーブルに問い合わせるためのＳＱＬ問い合わせを生成し、これを在庫テーブルに投げることで、「（code、quantity）=（0345、38）、（0872、3）」という問い合わせ結果を得る。

そして、データベース統合参照装置２０は、上記してきた処理によって全てのエレメントのデータ値が求まれば（ステップＳ１３１２肯定）、図１７に例示するように、ＸＭＬの木構造を上から辿りながら、得られたデータ値から問い合わせ結果のＸＭＬを組み立てる（ステップＳ１３１３）。ここで、この時点で、未だユーザからのＸＱｕｅｒｙ問い合わせで指定した問い合わせ条件の一部が反映されていない可能性もあるので、データベース統合参照装置２０は、問い合わせ条件を満たさない解をチェックして最終結果のＸＭＬから除外してＸＭＬを組み立てる（ステップＳ１３１４）。その後、データベース統合参照装置２０は、図１８に例示するように、問い合わせ結果のＸＭＬを生成して出力する（ステップＳ１３１５）。

上記した一連の処理を経ることによって、ＸＱｕｅｒｙ問い合わせを行ったユーザ端末１０に対して、ＸＭＬ形式のデータが問い合わせ結果として返信される。なお、上記したステップＳ１３０７〜Ｓ１３１２で、一度最上位のエレメントまで上がってから、再び下位のエレメントを問い合わせし直しており、同じデータベースに二度問い合わせを行っている点で一見すると無駄なように思えるが、これは、そうしなければＸＭＬ文書データの一部が欠けてしまう可能性があるからである。すなわち、例を挙げれば、図１３では「FMV-6000CL」に対する「code」だけを求めているが、最終的な結果で必要なのは、図１７に例示するように、「order_id」が「121」の注文伝票で注文された２つの商品の「code」と「name」である。そして、これは、一旦最上位のエレメントを求めて「order_id」が確定するまでは求めることができないからである。

なお、ＸＭＬ−ＤＢへの副問い合わせの結果として返ってきたＸＭＬデータは、問い合わせ処理エンジン部２２ｂに含まれるＸＭＬパーザを利用して解析を行う。これは、関連付けで使用するノードの値を取り出さないと次のデータベースでの問い合わせができないからである。また、ＤＢ統合用メタデータで定義してあるＸＭＬのスキーマに合致しているか確認することで不正なデータの混入を防ぐことも目的である。解析を終えたＸＭＬデータは中間データ形式（ＤＯＭ（Document Object Model）に準拠した形式）でメモリ上に保管しておく。

ＤＢ統合用メタデータの仮想ＸＭＬスキーマ情報において同一のComplexElementの直下に出現するSimpleElementが、返ってきたＸＭＬデータにおいて順番違いで出現したときの処理は、二通りが考えられる。一つはそれをスキーマ違反の不正なＸＭＬデータとしてエラーにしてしまう（そのデータを破棄するorエラーを返して終了する）という方法で、もう一つは仮想ＸＭＬスキーマ情報に合わせて並び直すという方法である。本実施例１では後者を採用する。このことによって、本実施例１では仮想データビューにおいてタグの出現順を任意に変更することを可能となる。

ＸＱｕｅｒｙの問い合わせ結果となるＸＭＬデータの生成は、中間データ形式でメモリ上に保持しておいた各データベースへの副問い合わせ結果を、ＤＢ統合用メタデータの仮想ＸＭＬスキーマに合わせてＸＭＬデータとして出力することで行う。

次に、上記の問い合わせ処理手順で説明した問い合わせ順序の最適化手法（図１０のステップＳ１３０４に係る処理）を詳細に説明する。問い合わせ型データベース統合が抱える潜在的な問題点として、データベースのデータをネットワーク経由で取得するので、ローカルにデータを保持している場合に比べて、データへのアクセス速度が遅くなり、ネットワーク負荷も大きくなる点が挙げられる。

そして、実施例１におけるデータベース統合参照装置２０では、複数のデータベースから関連するデータを順番に取得していく場合に、最初に取得するデータはユーザの問い合わせで指定された条件によって絞り込み、以降に取得するデータは前に取得したデータとの関連付けとユーザの指定した条件の両方を用いて絞り込むことにしている。このため、データの絞込みが足りないと、データベースに問い合わせをした結果として大量のデータが返ってきてしまい、データ転送に時間を要するばかりか、ネットワーク負荷を増大させてしまう。

これを具体的に説明すると、図１１に例示したように、ユーザからの問い合わせにはデータを絞り込むための条件が２つ書かれている。１つ目は「商品名がFMV-6000CLであること」であり、２つ目は「その商品の発注数が２つ以上であること」というものである。その一方で、商品名の情報は商品ＤＢ１２の取扱商品テーブルに格納されており、発注個数の情報は受注ＤＢ１１の受注伝票ＸＭＬに格納されている。このため、データベース統合参照装置２０は、最初にどちらのデータベースに対してＳＱＬ問い合わせを発行するかを決定する必要がある。

ここで、最初の問い合わせの結果データが多いと、その結果データを用いて行う次の問い合わせの結果データも多くなり、ユーザに返される最終的な問い合わせ結果は同じでも、途中でデータベース統合参照装置２０に集められるデータの量が増えてしまい、データ転送に時間がかかってユーザへの応答に時間がかかるばかりが、ネットワークの負荷も増大させてしまう。そこで、データベース統合参照装置２０は、最初にどちらのデータベースに対してＳＱＬ問い合わせを発行すれば、その問い合わせの結果データを少なくすることができるかを検討した上で、最初に問い合わせを開始するデータベースを決定する。そして、これについては、各データベースからデータベース自身のメタデータ（統合用メタデータとは異なる。）を取得した後に、以下の（１）〜（４）の事項を考慮して行われる。

（１）データの冗長性に関する制約条件
データベースのメタデータを参照し、ＸＱｕｅｒｙ問い合わせで条件付けが行われているカラムが、そのテーブルの主キーになっていないか、またはユニーク制約が設定されていないかを確認する。そのいずれかであれば、そのカラムはデータの重複が無いので、データを絞り込める可能性が高くなるからである。

（２）データ数
データベースのメタデータを参照し、テーブル内のレコード数が多いか確認する。テーブル内のレコード数が多いと、問い合わせの結果として返ってくるレコードの数も多くなる可能性が高いからである。

（３）データの型と桁数
データベースのメタデータを参照し、カラムのデータ型が数字や真偽値などの種類の少ないものであったり、桁数が少なかったりしていないかを確認する。この場合には、そのカラムは重複するデータが多くなる可能性が高いので、問い合わせの結果として多くのレコードが返ってくる可能性が高いからである。

（４）ユーザの指定した条件式の条件指定の種類
ＸＱｕｅｒｙ問い合わせ内の条件式が等号で指定されているか、不等号で指定されているかを確認する。等号で指定されている場合は、不等号で指定されている場合よりもデータを絞り込める可能性が高いからである。

データベース統合参照装置２０は、上記した４つの条件をそれぞれ満たしているかどうかを調べ、その結果によって各問い合わせの条件について点数付けを行い、最も点数の高い条件に係るデータベースから問い合わせを開始する。なお、図１２に示した例は、「name=‘FMV-6000CL'」という条件を取扱商品テーブルに対して最初に問い合わせる方が、データを絞り込める可能性が高いと判定された場合の例である。

上記したような最適化手法によって問い合わせを開始するデータベースを決定した後は、上記の問い合わせ処理手順で説明したように、関連付け情報を利用して、一旦ＸＭＬの最上位のエレメントへ向けて次々と上隣のエレメントを求めてゆく。

上述してきたように、実施例１によれば、データベースへの共通アクセス手段を提供するだけでなく、そのさらに上位にＸＭＬのデータビューを用意する。すなわち、ユーザには複数のデータベースに跨っている関連データ全体をＸＭＬ文書と仮想させ、そのＸＭＬ文書の一部を切り出す問い合わせを行った結果として、ＸＭＬ文書が返るという形でデータの参照を行う。また、ユーザから問い合わせが行われると、予め用意されている統合用メタデータに基づいて、どのような順番でどのデータベースからどのような問い合わせでデータを獲得していけばよいかを判断し、それに基づいて必要なデータを獲得して、獲得されたデータをＸＭＬ文書として組み立ててユーザに返す。これによって、ユーザはデータの格納構造を気にする必要がなくなり、各データがどのデータベースに格納されているのかを全く意識せずに済むので、複数のデータベースがあたかも１つであるかのように扱うことが可能になる。

また、実施例１によれば、同種のデータが複数のデータベースに分かれて格納されていて、ある１つの値を持つデータに関していずれのデータベースに格納されているか分からないような場合においても、ユーザがＸＭＬ文書の問い合わせを行うと、データベース統合参照装置２０が統合用メタデータに基づいてデータが格納されている可能性のあるデータベース全てに問い合わせを行い、データを自動的に見つけてくる。これによって、ユーザは複数のデータベースからデータを探す作業をする必要がなくなるので、複数のデータベースがあたかも１つであるかのように扱うことが可能になる。

また、実施例１によれば、データベースからデータを取得する際に、データベースのメタ情報や問い合わせ内容を利用して、問い合わせ結果がなるべく少なくなる問い合わせ計画を作成し、その計画に基づいて各データベースから順番にデータを獲得してくる。このように、問い合わせ順番を操作して結果データを絞り込んでいくことによって、データ転送量を減らして、問い合わせにかかる時間を短縮するとともに、ネットワークにかかる負担も軽減することが可能になる。

また、実施例１によれば、問い合わせを開始するデータベースを決定した後に、ＸＭＬ文書の木構造の中で、最初にデータ値を求めたエレメントから次々と上位のエレメントに対応するデータ値を求めていき、最上位のエレメントのデータ値が求まったら、次にそこから順番に下位のエレメントを辿りながら全て求めていく。そして、この手順は、ＸＭＬ文書の構造の定義や問い合わせの内容に関わらず、常に同じである。これによって、ＸＭＬ文書の構造定義や問い合わせの内容に関わらず、問い合わせ結果としてのＸＭＬ文書全体を洩れなく求めることが可能になるとともに、データベースへの問い合わせの回数を少なく抑えることが可能になる。

なお、上記した実施例１は、次の特徴を有する。図１９は、実施例１の特徴を説明するための図である。同図に示すように、実施例１は、ＲＤＢをＸＭＬ−ＤＢと同様に取り扱い可能とする機能を有する。

まず、ＸＭＬ−ＤＢは、一定の固定スキーマのＸＭＬ文書データを多数格納しており、問い合わせを受けるとその条件に該当するＸＭＬ文書データをその形のまま返すというインタフェースを保有していると見なす。ＸＭＬ文書データは条件に該当した分だけ複数個返される。このようなインタフェースを持っていると見なすことによって、ＸＭＬ−ＤＢから返ってくるＸＭＬ文書データのスキーマが固定であると考えることが出来るので、それをユーザに見せるＸＭＬ形式のデータビューのスキーマの一部として埋め込むことが出来る。

ＸＭＬ−ＤＢから返ってくるＸＭＬ文書データのスキーマをＸＭＬ形式のデータビューのスキーマに埋め込む為に、ビュー生成ルールの中で、ＸＭＬ−ＤＢから返ってくるＸＭＬの木構造と、他のＲＤＢのデータ構造から生成し得るＸＭＬの木構造との間で、相互の木構造をどのように結合してどのような木構造のビューにするのかというスキーマの定義と、両者の間で関連付けを取る項目の定義を行う。

問い合わせの処理においては、ＸＭＬ−ＤＢから返ってくるＸＭＬ文書データは、そのまま無加工で問い合わせ結果のＸＭＬ文書データの一部として埋め込まれる。すなわち、複数のＲＤＢから構築されるＸＭＬの部分木と同様に扱われる。ＸＭＬ文書データビューのスキーマを定義する木構造が、実施例１ではＸＭＬ−ＤＢから返って来るＸＭＬ文書データのスキーマ定義を兼ねていると言える。

しかし、この方法によれば、前述の如く仮定したインタフェースを有しているＸＭＬ−ＤＢにしか適用できないし、またＸＭＬ−ＤＢから返るＸＭＬ文書データに半構造性がある場合も適用できない。さらに、ユーザに与えられる統合データビューのスキーマもＸＭＬ−ＤＢから返るＸＭＬ文書データのスキーマによって制限を受けることにもなる。

上記した実施例１によってもなお存在する問題点を解決するため、また、実施例１にさらに各種機能を付加するために実施してもよい他の実施例を、以下に実施例２として示す。先ず、実施例２の第１の特徴を説明する。図２０は、実施例２の第１の特徴を説明するための図である。

実施例１では、ＸＭＬ−ＤＢは、一定の固定スキーマのＸＭＬ文書データを多数格納しており、問い合わせを受けるとその条件に該当するＸＭＬ文書データをその形のまま返すというインタフェースを保有していると見なした。故に、それ以外のインタフェースしか持たないＸＭＬ−ＤＢには対応できない。しかし、一般的には、ＸＭＬ−ＤＢのインタフェースは、一つ(若しくは複数)の巨大なＸＭＬ文書データを格納しており、問い合わせ言語によってその一部を切り出す指示を行い、格納されていたＸＭＬ文書データの部分データが返るというものが多い。また、ＤＢ統合用メタデータのデータベース情報において、ＸＭＬデータ中の反復構造までのパスが指定されている場合は、先頭にそのパスを加えるようにＸＰａｔｈを修正して発行する必要がある。

そこで、図２０に示すように、実施例２のデータベース統合参照システムは、ＸＭＬ−ＤＢがそのようなインタフェースしか持たない場合に対応する為に、もしそのＸＭＬ−ＤＢ内のＸＭＬ文書データの木構造の中に一定の繰り返し構造がある場合に、その木構造のルートノードからその繰り返し構造までのパスをビュー生成ルール内に記録しておき、本システムが発行する副問い合わせをそのパスに応じて自動的に加工して発行することによって、そのＸＭＬ−ＤＢが本発明のデータベース統合参照システムの仮定しているインタフェースを保有するかのように取り扱う機能を備える。こうすることによって、実施例２のデータベース統合参照システムでは多くのＸＭＬ−ＤＢに対応することが可能となる。

なお、本システムが発行する副問い合わせを、ビュー生成ルール内に記録されるルートノードから繰り返し構造までのパスに応じて自動的に加工して発行する処理は、問い合わせ処理エンジン部２２ｂにより実行される。また、該ルートノードから繰り返し構造までのパスは、統合用メタデータ２１ａに記憶されている。

次に、実施例２の第２の特徴を説明する。図２１は、実施例２の第２の特徴を説明するための図である。実施例１のデータベース統合参照システムでは、ビュー生成ルールにおいて、ＸＭＬ−ＤＢのＸＭＬ文書データの木構造とＲＤＢとを組み合わせた木構造の間で両者を連結するための定義を行う。その定義は二種類あり、一つが相互の木構造をどのように結合してどのような木構造のデータビューにするのかというスキーマの定義であり、もう一つが両者の間でどのノードにおいて関連付けを取るのかという関連付けの定義である。

これらの間には相互に関係があり、無秩序に定義することはできない。関連付けを取るノード同士は相互に１対１で対応しなければならないので、ＸＭＬ−ＤＢについては、関連付けの定義で使用するノードは、スキーマの定義において接続箇所となっている中間ノードの子となる末端ノードでなければならないという制約がある。これでは、ビューのスキーマ定義の自由度が少なく、自由なビューを定義できないという問題があった（図２１（ａ）参照）。

そこで、図２１（ｂ）に示すように、実施例２のデータベース統合参照システムでは、ビュー生成ルールのビュースキーマ定義において、ＸＭＬ−ＤＢに対応する部分木の各中間ノードについて最大出現回数を指定することができるようになっており、ユーザがビュー生成ルールを作成する際にそれを適切に定義することによって、各中間ノード間の出現回数又は出現比率を求めることができる。これによって、関連付けの定義に使用するノードをスキーマの定義において接続箇所となっている中間ノードの子ノードに限る必要はなく、１対１対応する範囲において、より上位や下位のノードを関連付け先として指定することが可能となる。こうすることによって、実施例２のデータベース統合参照システムではデータビュー定義の自由度を高めている。

なお、指定されたＸＭＬ−ＤＢに対応する部分木の各中間ノードの最大出現回数に基づいて各中間ノード間の出現回数又は出現比率を求め、１対１対応する範囲において、より上位や下位のノードを関連付け先として指定することが可能か否かを判定する処理は、問い合わせ処理エンジン部２２ｂにより実行される。また、指定されたＸＭＬ−ＤＢに対応する部分木の各中間ノードの最大出現回数は、統合用メタデータ２１ａに記憶されている。

次に、実施例２の第３の特徴を説明する。図２２は、実施例２の第３の特徴を説明するための図である。実施例１では、ＸＭＬ−ＤＢから返るＸＭＬ文書データのスキーマをそのまま統合データビューの木構造の一部として見せている。これでは、統合データビューのスキーマ定義に制限が生じてしまい、ユーザの望む自由なビュースキーマを定義することができない場合がある。特に、ビューにおいては元のＸＭＬ文書データとはタグの名前を変更したいという要求が発生することが考えられる。また、ＤＢ統合用メタデータのデータベース情報において、ノードのＸＭＬ−ＤＢにおける別名が定義されている場合は、ＸＰａｔｈを生成する際にパス中のタグ名をその別名に置き換える必要がある。

そこで、図２２に示すように、実施例２のデータベース統合参照システムでは、ビュー生成ルールのビュースキーマ定義において、各ノードにデータベース上の別名を指定できるようになっている。ＸＭＬ−ＤＢへの副問い合わせ時や返ってきたＸＭＬ文書データの解析時にはこの別名を使用し、ＸＭＬ文書データを解析し終わったら各タグの名前をビュー表示用の本来の名前に置き換えることによって、ＸＭＬ−ＤＢ上のＸＭＬ文書データについてもタグ名を置き換えることを可能としている。即ち、ＤＢ統合用メタデータのデータベース情報において、ノードのＸＭＬ−ＤＢにおける別名が定義されている場合は、ＸＭＬ−ＤＢから返ってきたＸＭＬデータをパーズする際に、その別名を用いてパーズする。こうすることによって、実施例２のデータベース統合参照システムではビュー定義の自由度を高めている。

なお、ビュー生成ルールのビュースキーマ定義において各ノードの名称を各データベース上の名称とは異なる別名に変換する処理は、問い合わせ処理エンジン部２２ｂにより実行される。また、各ノードの名称及びこれに対応する各データベース上の名称とこの両者の関係は、統合用メタデータ２１ａに記憶されている。

次に、実施例２の第４の特徴を説明する。図２３は、実施例２の第４の特徴を説明するための図である。実施例１では、ＸＭＬ−ＤＢから返るＸＭＬ文書データのスキーマをそのまま統合データビューの木構造の一部として見せている。これでは、統合データビューのスキーマ定義に制限が生じてしまい、ユーザの望む自由なビュースキーマを定義することができない場合がある。特に、データビューにおいてはＸＭＬ−ＤＢのＸＭＬ文書データには存在しないタグを途中に挿入したいという要求が発生することが考えられる。また、ＸＭＬ部分木の中にTagElementが存在するならば、それは無視してＸＰａｔｈを生成する必要がある。

そこで、図２３に示すように、実施例２のデータベース統合参照システムでは、ビュー生成ルールのビュースキーマ定義において、架空のノードを指定することが可能となっている。この架空ノードについては、ＸＭＬ−ＤＢへの副問い合わせ時や返ってきたＸＭＬ文書データの解析時には使用せず、ＸＭＬ文書データを解析し終わったらその架空ノードのタグを挿入することによって、ＸＭＬ−ＤＢ上のＸＭＬ文書データについてもデータビュー上の木構造を変形することが可能となっている。即ち、ＤＢ統合用メタデータの仮想ＸＭＬスキーマ情報において、ＸＭＬ部分木の中にTagElementが存在するならば、ＸＱｕｅｒｙの問い合わせ結果を組み立てる際にそのタグを加える。こうすることによって、本発明のデータベース統合参照システムではビュー定義の自由度を高めている。

なお、問い合わせ結果であるＸＭＬ文書データを解析し終わった後に、指定された架空ノードのタグを挿入する処理は、問い合わせ処理エンジン部２２ｂにより実行される。また、指定された架空ノードのタグ情報は、統合用メタデータ２１ａに記憶されている。

次に、実施例２の第５の特徴を説明する。図２４は、実施例２の第５の特徴を説明するための図である。実施例１では、ＸＭＬ−ＤＢから返るＸＭＬ文書データのスキーマをそのまま統合データビューの木構造の一部として見せている。これでは、統合データビューのスキーマ定義に制限が生じてしまい、ユーザの望む自由なビュースキーマを定義することができない場合がある。特に、ビューにおいては元のＸＭＬ文書データに存在するノードを見せたくないという要求が発生することが考えられる。

そこで、図２４に示すように、実施例２のデータベース統合参照システムでは、ビュー生成ルールのビュースキーマ定義において、各ノードに非表示の設定をすることが可能となっている。このノードについては、ＸＭＬ−ＤＢへの副問い合わせ時や返ってきたＸＭＬ文書データの解析時には通常通り使用するが、ＸＭＬ文書データを解析し終わったらそのノードのタグを取り除くことによって、ＸＭＬ−ＤＢ上のＸＭＬ文書データについてもビュー上の木構造を変形することが可能となっている。即ち、ＤＢ統合用メタデータの仮想ＸＭＬスキーマ情報において、ComplexElementかSimpleElementに「可視化の可否」属性が“FALSE”と設定されていたならば、ＸＱｕｅｒｙの問い合わせ結果を組み立てる際にそのノードのタグは削除する。こうすることによって、本発明のデータベース統合参照システムではビュー定義の自由度を高めている。

なお、問い合わせ結果であるＸＭＬ文書データを解析し終わった後に、非表示が指定されたノードのタグを取り除く処理は、問い合わせ処理エンジン部２２ｂにより実行される。また、指定された非表示ノードのタグ情報は、統合用メタデータ２１ａに記憶されている。

次に、実施例２の第６の特徴を説明する。図２５は、実施例２の第６の特徴を説明するための図である。実施例１では、ＸＭＬ−ＤＢから返るＸＭＬ文書データのスキーマをそのまま統合データビューの木構造の一部として見せている。これでは、ＸＭＬ−ＤＢから返って来るＸＭＬ文書データに半構造性がある場合に対応できない。

そこで、図２５に示すように、本発明のデータベース統合参照システムでは、ビュー生成ルールのビュースキーマ定義において指定した特定のノードについては、その配下のスキーマをチェックしないという指定を出来るようにした。ＸＭＬ−ＤＢから返ってきたＸＭＬ文書データの解析を行う際に、そのノードの配下に出現したものは全て単純に文字列として取り扱い、その部分のスキーマをチェックしない。即ち、ＤＢ統合用メタデータの仮想ＸＭＬスキーマ情報において、SimpleElementの「スキーマレス指定」オプションが“TRUE”と設定されていたら、そのタグの中身はパーズ及び処理を一切行わず、単なる文字列として取り扱う。SimpleElementの「スキーマレス指定」オプションが“TRUE”と設定されていてタグ配下をパーズしなかった場合は、その文字列をそのままそのタグの値としてＸＱｕｅｒｙの問い合わせ結果に出力することとなる。これによって、ＸＭＬ−ＤＢに格納されているデータについて、そのスキーマの一部に半構造性があっても対応することが可能となる。こうすることによって、本発明のデータベース統合参照システムでは格納データが半構造性を持つＸＭＬ−ＤＢにも柔軟に対応することを可能としている。

なお、問い合わせ結果であるＸＭＬ文書データを解析し終わった後に、スキーマチェックのキャンセルが指定されたノードの情報を単純文字列として表示させる処理は、問い合わせ処理エンジン部２２ｂにより実行される。また、スキーマチェックのキャンセルが指定されたノードのタグ情報は、統合用メタデータ２１ａに記憶されている。

上記した実施例１及び２によれば、ＸＭＬ−ＤＢ及びＲＤＢを含む複数のＤＢに分散して配置されるデータを参照する場合に、ＤＢの物理的な分散を意識することなく、単に、ＸＱｕｅｒｙの基本的な使用法に基づくだけで、データが参照可能となる。また、統合データビューのスキーマ定義の自由度が高いので、あたかも一つのＤＢにアクセスするかのような感覚で、ＸＱｕｅｒｙによる自由な問い合わせが可能となる。

さて、これまで本発明の実施例１及び２について説明したが、本発明は上述した実施例１及び２以外にも、特許請求の範囲に記載した技術的思想の範囲内において種々の異なる形態にて実施されてよいものである。そこで、以下では他の実施例として、（１）タグ付き文書、（２）データベース、（３）統合用メタデータ、（４）アクセス処理、（５）システム構成等、（６）プログラム、にそれぞれ区分けして種々の異なる実施例を説明する。

（１）タグ付き文書
例えば、実施例１及び２では、タグ付き文書としてＸＭＬを利用する場合を説明したが、本発明はこれに限定されるものではなく、例えば、ＨＴＭＬやＳＧＭＬなど、他のタグ付き文書を利用するようにしてもよい。

また、実施例１及び２では、ＸＭＬデータビューに対する問い合わせに、現在Ｗ３Ｃで標準化作業が進行中の問い合わせ言語「ＸＱｕｅｒｙ」を利用し、ＸＭＬ−ＤＢに対する問い合わせに「ＸＰａｔｈ（またはＸＰａｔｈ準拠のクエリ言語）」を使用する場合を想定しているが、本発明はこれに限定されるものではなく、いずれにおいても、「ＸＱｕｅｒｙ」又は「ＸＰａｔｈ（またはＸＰａｔｈ準拠のクエリ言語）」など、他の問い合わせ言語を利用するようにしてもよい。

（２）データベース
また、実施例１及び２では、ＸＭＬ−ＤＢ及びＲＤＢを統合する場合を説明したが、本発明はこれに限定されるものではなく、他の型のデータベースを統合する場合にも本発明を同様に適用することができる。例えば、オブジェクト指向データベース、オブジェクト・リレーショナルデータベースなどである。オブジェクト指向データベースは、データを階層構造のパスでデータを特定することから、この階層構造をタグ付き文書の階層構造に変換する処理及び機能を備えることによって、あたかもオブジェクト指向データベースをＸＭＬ−ＤＢであるかのように取り扱うことが可能となる。また、オブジェクト・リレーショナルデータベースは、データ管理方法がＲＤＢに準拠するため、ＲＤＢと略同一に取り扱うことが可能となる。

（３）統合用メタデータ
また、実施例１及び２では、一つの統合用メタデータを用意する場合を説明したが、本発明はこれに限定されるものではなく、データベースの統合の仕方に応じて複数の統合用メタデータを用意するようにしてもよい。例えば、問い合わせ結果の出力態様に応じて複数用意することなどが考えられる。

（４）アクセス処理
また、実施例１では、複数の異種のデータベースにアクセスするために、ＲＤＢに対してはGlobus Toolkit 4 + OGSA-DAI WSRF 2.1を、ＸＭＬ−ＤＢに対してはＸＰａｔｈ準拠のＡＰＩ（Application Programming Interface）を利用する場合を想定しているが、本発明はこれに限定されるものではなく、複数の異種のデータベースへどのようにして問い合わせを行うかは問わず、如何なる手法でアクセスしてもよい。特に、前述のＸＰａｔｈ準拠のＡＰＩは、ＸＭＬ検索言語であるＸＰａｔｈのサブセットであるので、ＸＰａｔｈを使用して問い合わせ処理を行うように移行可能である。

（５）システム構成等
また、図示した各装置（特に、データベース統合参照装置２０）の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、実施例１及び２において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

（６）プログラム
ところで、上記の実施例１及び２で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータ、サーバ又はワークステーションなどのコンピュータシステムで実行することによって実現することができる。

さらに、その他の実施例では、コンピュータシステムにおいて、所定の記録媒体に記録されたプログラムを読み出して実行することで上記した実施例１及び２と同様の機能を実現する。ここで、所定の記録媒体とは、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」の他に、コンピュータシステムの内外に備えられるハードディスクドライブ（ＨＤＤ）や、ＲＡＭ、ＲＯＭなどの「固定用の物理媒体」、さらに、モデムを介して接続される公衆回線や、他のコンピュータシステム並びにサーバが接続されるＬＡＮ／ＷＡＮなどのように、プログラムの送信に際して短期にプログラムを保持する「通信媒体」など、コンピュータシステムによって読み取り可能なプログラムを記録する、あらゆる記録媒体を含むものである。

すなわち、このその他の実施例でいうプログラムは、上記した「可搬用の物理媒体」、「固定用の物理媒体」、「通信媒体」などの記録媒体に、コンピュータ読み取り可能に記録されるものであり、コンピュータシステムは、このような記録媒体からプログラムを読み出して実行することで上記した実施例と同様の機能を実現する。なお、この他の実施例でいうプログラムは、コンピュータシステムによって実行されることに限定されるものではなく、他のコンピュータシステムまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。

（付記１）コンピュータに、階層構造で一意に特定されるデータで問い合わせ結果を返却するデータベースを含む種別の異なる複数のデータベースに分散するデータを、各データベースに対する問い合わせ形式で問い合わせを行って取得した問い合わせ結果をビューに統合して出力することにより参照させるデータベース統合参照プログラムであって、
前記コンピュータに、
前記階層構造で一意に特定されるデータの要素と各データベースの要素との対応関係、及び各データベース間の要素の対応関係により定義される前記ビューの生成ルールを記憶するビュー生成ルール記憶手順と、
前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を、前記前記ビュー生成ルールに基づいて構成する問い合わせ処理手順と
を実行させることを特徴とするデータベース統合参照プログラム。

（付記２）コンピュータに、予め構造が定められているタグ付き文書で問い合わせ結果を返却するタグ付き文書データベースを含む種別の異なる複数のデータベースに分散するデータを、各データベースに対する問い合わせ形式で問い合わせを行って取得した問い合わせ結果をビューに統合して出力することにより参照させるデータベース統合参照プログラムであって、
前記コンピュータに、
前記タグ付き文書の要素と各データベースの要素との対応関係、及び各データベース間の要素の対応関係により定義される前記ビューの生成ルールを記憶するビュー生成ルール記憶手順と、
前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を、前記前記ビュー生成ルールに基づいて構成する問い合わせ処理手順と
を実行させることを特徴とするデータベース統合参照プログラム。

（付記３）前記ビュー生成ルール記憶手順では、前記タグ付き文書が含む同一構造を繰り返す繰り返し構造をさらに記憶し、
前記問い合わせ処理手順では、前記タグ付き文書で問い合わせ結果を返却するデータベースに対する問い合わせに際し、前記ビュー生成ルール記憶手順により記憶されている前記繰り返し構造を使用して該繰り返し構造に含まれるデータを取得することを特徴とする付記１又は２に記載のデータベース統合参照プログラム。

（付記４）前記ビュー生成ルール記憶手順では、前記ビュー生成ルールにおける各要素の最大出現回数をさらに記憶し、
前記問い合わせ処理手順では、前記タグ付き文書内において要素の出現回数を判定する要素出現回数判定手順と、前記ビュー生成ルール記憶手順により記憶されている前記ビュー生成ルールにおける各要素の最大出現回数及び前記要素出現回数判定手順により判定された要素の出現回数に基づいて各データベース間で対応付けることができる要素か否かを判定する要素対応付け判定手順とをコンピュータにさらに実行させることを特徴とする付記１又は２に記載のデータベース統合参照プログラム。

（付記５）前記ビュー生成ルール記憶手順では、前記ビューの生成ルールで対応付けられている前記タグ付き文書の要素及び前記各データベースの要素それぞれの名称をさらに記憶し、
前記問い合わせ処理手順では、前記タグ付き文書の要素の名称で前記ビューに対する問い合わせを受け付け、該タグ付き文書の要素の名称を前記各データベースの要素の名称へ変換し、前記各データベースの要素の名称で各データベースに対する問い合わせを行って問い合わせ結果取得することを特徴とする付記１又は２に記載のデータベース統合参照プログラム。

（付記６）前記ビュー生成ルール記憶手順では、前記タグ付き文書には存在しない要素をさらに記憶し、
前記問い合わせ処理手順では、前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を、前記タグ付き文書には存在しない要素を含んで構成することを特徴とする付記１又は２に記載のデータベース統合参照プログラム。

（付記７）前記ビュー生成ルール記憶手順では、前記ビューの生成ルールにおける前記タグ付き文書の要素の隠蔽の指示をさらに記憶し、
前記問い合わせ処理手順では、前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を前記前記ビュー生成ルールに基づいて構成する際に、前記タグ付き文書の要素の隠蔽の指示に基づき該要素を隠蔽することを特徴とする付記１又は２に記載のデータベース統合参照プログラム。

（付記８）前記問い合わせ処理手順では、前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を前記前記ビュー生成ルールに基づいて構成する際に、前記ビュー生成ルールに含まれない要素が存在した場合、該要素を文字列として取り扱うことを特徴とする付記１又は２に記載のデータベース統合参照プログラム。

（付記９）予め構造が定められているタグ付き文書で問い合わせ結果を返却するタグ付き文書データベースを含む種別の異なる複数のデータベースに分散するデータを、各データベースに対する問い合わせ形式で問い合わせを行って取得した問い合わせ結果をビューに統合して出力することにより参照可能とするデータベース統合参照方法であって、
前記タグ付き文書の要素と各データベースの要素との対応関係、及び各データベース間の要素の対応関係により定義される前記ビューの生成ルールを記憶するビュー生成ルール記憶工程と、
前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を、前記前記ビュー生成ルールに基づいて構成する問い合わせ処理工程と
を含んだことを特徴とするデータベース統合参照方法。

（付記１０）前記ビュー生成ルール記憶工程は、前記タグ付き文書が含む同一構造を繰り返す繰り返し構造をさらに記憶し、
前記問い合わせ処理工程は、前記タグ付き文書で問い合わせ結果を返却するデータベースに対する問い合わせに際し、前記ビュー生成ルール記憶工程により記憶される前記繰り返し構造を使用して該繰り返し構造に含まれるデータを取得することを特徴とする付記９に記載のデータベース統合参照方法。

（付記１１）前記ビュー生成ルール記憶工程は、前記ビュー生成ルールにおける各要素の最大出現回数をさらに記憶し、
前記問い合わせ処理工程は、前記タグ付き文書内において要素の出現回数を判定する要素出現回数判定工程と、前記ビュー生成ルール記憶手段に記憶される前記ビュー生成ルールにおける各要素の最大出現回数及び前記要素出現回数判定工程により判定された要素の出現回数に基づいて各データベース間で対応付けることができる要素か否かを判定する要素対応付け判定工程とをさらに含んだことを特徴とする付記９に記載のデータベース統合参照方法。

（付記１２）前記ビュー生成ルール記憶工程は、前記ビューの生成ルールで対応付けられる前記タグ付き文書の要素及び前記各データベースの要素それぞれの名称をさらに記憶し、
前記問い合わせ処理工程は、前記タグ付き文書の要素の名称で前記ビューに対する問い合わせを受け付け、該タグ付き文書の要素の名称を前記各データベースの要素の名称へ変換し、前記各データベースの要素の名称で各データベースに対する問い合わせを行って問い合わせ結果取得することを特徴とする付記９に記載のデータベース統合参照方法。

（付記１３）前記ビュー生成ルール記憶工程は、前記タグ付き文書には存在しない要素をさらに記憶し、
前記問い合わせ処理工程は、前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を、前記タグ付き文書には存在しない要素を含んで構成することを特徴とする付記９に記載のデータベース統合参照方法。

（付記１４）前記ビュー生成ルール記憶工程は、前記ビューの生成ルールにおける前記タグ付き文書の要素の隠蔽の指示をさらに記憶し、
前記問い合わせ処理工程は、前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を前記前記ビュー生成ルールに基づいて構成する際に、前記タグ付き文書の要素の隠蔽の指示に基づき該要素を隠蔽することを特徴とする付記９に記載のデータベース統合参照方法。

（付記１５）前記問い合わせ処理工程は、前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を前記前記ビュー生成ルールに基づいて構成する際に、前記ビュー生成ルールに含まれない要素が存在した場合、該要素を文字列として取り扱うことを特徴とする付記９に記載のデータベース統合参照方法。

（付記１６）予め構造が定められているタグ付き文書で問い合わせ結果を返却するタグ付き文書データベースを含む種別の異なる複数のデータベースに分散するデータを、各データベースに対する問い合わせ形式で問い合わせを行って取得した問い合わせ結果をビューに統合して出力することにより参照可能とするデータベース統合参照装置であって、
前記タグ付き文書の要素と各データベースの要素との対応関係、及び各データベース間の要素の対応関係により定義される前記ビューの生成ルールを記憶するビュー生成ルール記憶手段と、
前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を、前記前記ビュー生成ルールに基づいて構成する問い合わせ処理手段と
を備えたことを特徴とするデータベース統合参照装置。

（付記１７）前記ビュー生成ルール記憶手段は、前記タグ付き文書が含む同一構造を繰り返す繰り返し構造をさらに記憶し、
前記問い合わせ処理手段は、前記タグ付き文書で問い合わせ結果を返却するデータベースに対する問い合わせに際し、前記ビュー生成ルール記憶手段により記憶される前記繰り返し構造を使用して該繰り返し構造に含まれるデータを取得することを特徴とする付記１６に記載のデータベース統合参照装置。

（付記１８）前記ビュー生成ルール記憶手段は、前記ビュー生成ルールにおける各要素の最大出現回数をさらに記憶し、
前記問い合わせ処理手段は、前記タグ付き文書内において要素の出現回数を判定する要素出現回数判定手段と、前記ビュー生成ルール記憶手段に記憶される前記ビュー生成ルールにおける各要素の最大出現回数及び前記要素出現回数判定手段により判定された要素の出現回数に基づいて各データベース間で対応付けることができる要素か否かを判定する要素対応付け判定手段とをさらに含んだことを特徴とする付記１６に記載のデータベース統合参照装置。

（付記１９）前記ビュー生成ルール記憶手段は、前記ビューの生成ルールで対応付けられる前記タグ付き文書の要素及び前記各データベースの要素それぞれの名称をさらに記憶し、
前記問い合わせ処理手段は、前記タグ付き文書の要素の名称で前記ビューに対する問い合わせを受け付け、該タグ付き文書の要素の名称を前記各データベースの要素の名称へ変換し、前記各データベースの要素の名称で各データベースに対する問い合わせを行って問い合わせ結果取得することを特徴とする付記１６に記載のデータベース統合参照装置。

（付記２０）前記ビュー生成ルール記憶手段は、前記タグ付き文書には存在しない要素をさらに記憶し、
前記問い合わせ処理手段は、前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を、前記タグ付き文書には存在しない要素を含んで構成することを特徴とする付記１６に記載のデータベース統合参照装置。

（付記２１）前記ビュー生成ルール記憶手段は、前記ビューの生成ルールにおける前記タグ付き文書の要素の隠蔽の指示をさらに記憶し、
前記問い合わせ処理手段は、前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を前記前記ビュー生成ルールに基づいて構成する際に、前記タグ付き文書の要素の隠蔽の指示に基づき該要素を隠蔽することを特徴とする付記１６に記載のデータベース統合参照装置。

（付記２２）前記問い合わせ処理手段は、前記ビューに対する問い合わせ形式の問い合わせに応じて各データベースに対する問い合わせ形式の問い合わせを行って取得した問い合わせ結果を前記前記ビュー生成ルールに基づいて構成する際に、前記ビュー生成ルールに含まれない要素が存在した場合、該要素を文字列として取り扱うことを特徴とする付記１６に記載のデータベース統合参照装置。

開示の技術は、階層構造で一意に特定されるデータ、特に、予め構造が定められているＸＭＬ文書で問い合わせ結果を返却するデータベースを含む種別の異なる複数のデータベースに分散するデータを、各データベースに対する問い合わせ形式で問い合わせを行って取得した問い合わせ結果をビューに統合して出力することにより参照したい場合に有用であり、特に、データのリアルタイム性が必要な場合に有効である。

１０ ユーザ端末
１１ 受注ＤＢ
１１ａ 注文伝票ＸＭＬ
１２ 商品ＤＢ
１２ａ 取扱商品テーブル
１３ 在庫ＤＢ
１３ａ 在庫テーブル
２０ データベース統合参照装置
２１ 記憶部
２１ａ 統合用メタデータ
２２ｃ アクセス処理部
２２ａ パーザ部
２２ｂ 処理エンジン部
２２ｂ 処理部
２２ 制御部

Claims (1)

1. 入力する問い合わせに基づいて、それぞれデータ形式が異なる複数のデータベースに分散されたデータを取得し、取得したデータを第一の形式のビューに統合して出力する機能をコンピュータに実行させる、データベース統合参照プログラムにおいて、
   第１の形式による問い合わせの入力を受け付け、
   前記受け付けた問い合わせを内部形式に変換し、
   複数のデータベースにまたがる関連データの出力形式を示す情報と、第一の形式による文書の要素と前記複数のデータベースそれぞれの要素との対応関係を示す情報と、前記複数のデータベース間の要素の対応関係を示す情報とを参照して、問い合わせ対象の第一の形式による文書の構造と、前記第一の形式による文書の各要素に対応するデータベースを判別し、
   判別したデータベースに、問い合わせ条件に合致するデータを問い合わせ、
   前記問い合わせの結果得られたデータを、第一の形式の文書に組み立て、
   組み立てた文書を問い合わせ結果として返信する
   ことを特徴とする、データベース統合参照プログラム。

Images