JP2005182835A

JP2005182835A - 異種のデータソースのためのデータサーバを生成する方法

Info

Publication number: JP2005182835A
Application number: JP2004374615A
Authority: JP
Inventors: Sammy Chan; チャンサミー; Nicole Lam; ラムニコル; Alison Joan Lennon; ジョアンレノンアリソン; U Jin; ウジン
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2003-12-23
Filing date: 2004-12-24
Publication date: 2005-07-07
Also published as: US7660805B2; US20050149552A1

Abstract

【課題】
異種のデータソースへとアクセスする際の、既存技術に存在する一以上の不利な点を実質的に克服するか、少なくとも改善する。
【解決手段】データソース（１６１５）のデータをクライアントアプリケーション（１６３０）に提供するためにデプロイされるデータサーバ（１６１０）は、ウィザード（１６０５）により形成される。ネイティブデータ型のデータソースは、データ構造化されたデータを有する。代表スキーマおよびサーバアプリケーションはウィザードによって生成されるデータサーバを形成する。一旦形成されると、データサーバはクライアントアプリケーションからクエリを受信して応答してもよい。ネイティブデータ型についての知識を有しなくても、データサーバを介することで、クライアントアプリケーションはデータソースへとアクセスできるようになる。
【選択図】図１６

Description

本発明は、異種のデータソースにおいて保持されている情報の統合に関するものである。特に、データソースのネイティブデータモデルを共通データモデルへとマッピングする技術、および、共通データモデルに基づいたデータソースへのアクセスを提供するサーバアプリケーションの生成に関するものである。

統合化手法における異種のデータソースへとアクセスする際の問題については、一般に、関与している異種のデータソースのデータを共通データモデルのデータにより表現する解決手法が採用されている。これには、各々のデータソースのネイティブスキーマを共通データモデルのスキーマにマップすることが含まれる。本明細書において、”ネイティブ”という用語は、特定のデータソースに特有の言語またはスキーマを意味する。相互に関与している異種のデータソースの統合処理は、データソースの問合せ（クエリ）のための共通の方法を用意し、かつ、単一のクエリにより多数のデータソースから統合した結果を抽出することを可能ならしめることにより実現される。

異種のデータソースへの統合アクセスを可能にするためのプロセスは、一般に以下の２つのステップを必要とする：
１.セットアップ時において、データソースのネイティブスキーマが、共通データモデルのスキーマにマップするステップ（一般に、このステップは、ソフトウェアツールを使用して、データソースについて専門知識をもつ人により手動で実行される）
２.実行時において、データマッパープロセスにより、データソースのデータはそのネイティブスキーマから共通データモデルでマップされたスキーマまでマップするステップ（このプロセスには、しばしば共通データモデルのクエリを、ネイティブデータソースにより処理される一つ以上のクエリまたはアプリケーションプログラムインタフェース（API）コールに変換することが含まれる）

この種の処理に役立つデータマッパーは、以下の構成を採用しうる：
(i) ラッパー（データソースをカプセル化してデータにアクセスするための共通APIを公開するソフトウェア層）
または、
(ii) データサーバ（クライアントアプリケーションから要求を受信し、要求に従ってデータを読み出して処理する、ネットワークアドレスによって指定可能なサーバアプリケーション）

一般的に、データマッパーはソフトウェア技術者によってプログラムされ、システム管理者によりデプロイされる。データマッパーを構築しデプロイするタスクは、多大なる努力と専門知識が必要であり、この専門知識は、一般に、データを実際に利用する者の能力をはるかに超えている。また、以下の問題によりデータマッパーの構築は更に困難に成り得る。

第１に、しばしば共通データモデルにおける同一データに関しては、多数の異なる表現方法によりそれぞれ表現できるようにすることが望ましい。これは、２つのスキーマのデータモデルが異なる（例えば、リレーショナルで階層的な）際にしばしば必要となる。第２に、共通データモデルにおけるデータソース用に使用されるスキーマは特定可能であることがしばしば望ましい。統合アクセスを可能とするデータソースのスキーマに所定の構造が必要であるという利用者から要求がある場合に、このことは、ときとして必要となる（例えば、既存のスキーマに従って他のデータにアクセスしているクライアントを有するシステムにレガシーデータソースからデータを統合する場合など）。

異種のデータソースに格納されるデータへのクエリを可能にするための共通データモデルを提供する多くの既存技術が存在する。2001年7月17日のChang氏らによる米国特許第6,263,342号、2001年5月15日のChang氏らによる米国特許第6,233,586号および2001年8月7日のChang氏らによる米国特許第6,272,488号は、異種のデータソースの連合された仮想ビューをオブジェクト指向のモデルを使用して提供する方法を開示している。具体的には、Java（登録商標）オブジェクトを用いて、連合されたクエリオブジェクトは個々のデータソースのための適切なクエリに変換される。しかし、クエリ変換のためのJava（登録商標）オブジェクトを構築する方法は開示されていない。

1997年1月21日のDao氏らによる米国特許第5,596,744号と、1997年5月27日のNoble氏らによる米国特許第5,634,053号は類似した連合アーキテクチャを提供する発明である。これらの特許において、（ネイティブデータソースの）スキーマ、データ配布、ドメインの知識およびサイト間関係などの情報を含むデータ辞書が用いられている。データ辞書は、個々のデータソースへのクエリを適切に変換するために用いられる。しかしながら、新規のデータソースの情報をデータ辞書に追加する方法は記載されていない。

2001年8月28日のMadnick氏らによる米国特許第6,282,537号は、構造化または半構造化されたデータを含んでいる異種のデータソースにクエリする方法を開示している。この発明では、個々のデータソースのデータおよびそのフォーマットを定めるためにエクスポートスキーマが用いられている。しかしながら、上述した特許のように、エクスポートスキーマを生成する方法は記載されていない。上記の各々のケースにおいては、開示されている発明の目的が異種のデータソースの問合せを可能にした共通データモデルであると記載されている。新規データソースを共通データモデルに組み込む方法は対象とされていない。

2002年9月19日に公開されたVlahos氏らによる特許出願公開番号20020133504号は、仮想テーブルとしてデータソースのデータを公開するためにデータラッパーを使用する方法を開示している。仮想テーブルを単一の汎用データ表現（共通データモデル）に集計するために情報サーバが用いられる。共通データモデルに対するクエリは適切に変換され、個々のデータラッパーにリダイレクトされる。情報サーバは、いくらかの統合機能（蓄積、重複の除去など）を実行するが、データラッパーの仮想テーブルがデータソースのためにどのように構築されるかについては特許文献には記述されていない。つまり、個々のデータソースから共通データモデルへのデータのマッピングは、完全には記載されていない。

2001年10月25日に公開されたPrompt氏らによる特許出願公開番号20010034733号は、データにアクセスするためのプロトコルとして共通階層データモデルおよびライトウェイト・ディレクトリ・アクセス・プロトコル（LDAP）を使用する方法を開示している。これは、リレーションシップ・ドリブン・アプローチやアドホック・アプローチに基づいた（共通データモデルの）階層的なスキーマに、関係スキーマをマッピングする発明について記述されている。しかしながら、関係スキーマが階層的なスキーマにマップされる際にしばしば発生する多数の可能なマッピングの問題には、このリレーションシップ・ドリブンは対処できない欠点がある。さらに、他の非リレーショナルデータソースを共通階層データモデルにマッピングする技術については言及されていない。

近年、拡張可能なマークアップ言語（XML）が、XMLデータをクエリが可能なXMLクエリ言語とともに（異種のデータソースのための）共通データモデルとして使用されるようになってきている。IBMのJava（登録商標）ベースのツール"XML for Tables"により、アプリケーションプログラマは、提供された一組のJava（登録商標）クラスを用いて関係テーブルのXMLビューを得ることができる。具体的には、XML for Tablesは、IBMのDB2（登録商標）データベース技術によって動作するように設計されている。XML for TablesはXMLデータのための利用者定義ビュー（スキーマ）を可能にするが、これはプログラマ用のツールにすぎない。複数の異なるデータビューは、データソースに関する知識に基づいて個々にプログラムされる必要がある。さらに、このツールは、リレーショナルデータベースによって用いられるように設計されており、異種のデータソースへの適用は制限されている。

上記の技術で開示される装置は習熟の必要が無いツールであり、必ずしもデータベース管理の技術に熟練していない利用者が選択されたデータソースのためのデータマッパーを作成しデプロイすることを可能にし得る。
米国特許第6,263,342号米国特許第6,233,586号米国特許第6,272,488号米国特許第5,596,744号米国特許第5,634,053号米国特許第6,282,537号米国特許出願公開第20020133504号米国特許出願公開第20010034733号

本発明の目的は、既存技術に存在する一以上の不利な点を実質的に克服するか、少なくとも改善することである。

本明細書において開示される装置は、ネイティブスキーマから共通データモデルのスキーマへの多数の可能なマッピングを可能にするとともに、共通データモデルの所定のスキーマを使用することを可能ならしめるものである。

本発明の実施形態に従って、ネットワークを通じてデータソースのデータをクライアントアプリケーションに提供するためのデータサーバを形成する方法が開示される。前記データソースはネイティブデータ型およびデータ構造に配置されたデータを含み、前記方法は次のステップを含んでおり：
(i) 前記ネットワーク上の前記データソースを識別するステップ
(ii) データ構造と前記識別されたデータソースのうちの少なくとも１つをトラバースするアプリケーションプログラムを提供し、前記アプリケーションプログラムは前記ネイティブデータ型から共通データモデルの所定のデータ型へ変換するマッピングデータを含む代表スキーマを生成するように操作可能である
(iii) 前記ネイティブデータ型から所定のデータ型まで前記データを変換し、前記ネットワークを通じて前記共通データモデルに従って前記クライアントアプリケーションに前記データに提供するために、前記代表スキーマを使用するのに適しているサーバアプリケーションを生成するステップ
以上のステップにより生成された、前記代表スキーマおよび前記サーバアプリケーションにより前記データサーバを形成する方法。

また、他の実施形態についても開示される。

本発明によれば、ネイティブスキーマから、共通データモデルのスキーマおよび共通データモデルの所定のスキーマまで多数の可能なマッピングを可能とすることのできる技術を提供することができる。

（第１実施形態）
以下に、異種のデータソースのためのデータサーバを生成する方法および装置などについて説明する。この方法では、データサーバを構築する際にユーザを補助するアプリケーションプログラム（通常ウィザードと呼ばれる。）が使用される。ウィザードは、利用者による共通データモデルのクエリを異種のデータソースのネイティブスキーマにマップするものである。実施形態では、共通データモデルとしてXMLを使用することにする。共通データモデルのためのクエリは、XML Query（XQueryと称す。）を使用して表現されことが望ましい。各々のデータソースのデータは、XMLスキーマを使用している共通データモデルにより表現される。拡張可能なマークアップ言語、XMLスキーマおよびXQueryは、ネットワークやアプリケーションを通じてデータの相互接続性を可能にするため、ワールドワイドウェブコンソーシアム（W３C）により開発されている。

図１は、実施形態に係る例示的なシステムアーキテクチャ１００を示す図である。データサーバウィザードアプリケーション１０５は、選択された（リレーショナルデータベース）データソース１１５のためのデータサーバ１１０を生成してデプロイするために用いてもよい。なお、“デプロイ”とは、ネットワークアプリケーションやＷｅｂサービスなどを利用可能なように準備することをいう。データサーバ１１０は、一以上のクライアントアプリケーション１３０からXQuery要求を受け付けるネットワークアドレス指定可能なサーバである。データサーバ１１０は、ネイティブクエリ要求に従って、データソース１１５からネイティブ結果データを検索して、XML要求の結果をクライアントアプリケーション１３０に返信する。クライアントアプリケーション１３０は、例えば、ワールドワイドウェブ（WWW）のようなコンピュータネットワーク上のサーバにXQueryを送信するためにハイパーテキストトランスファープロトコル（HTTP）を使用可能なものであれば、いかなるクライアントプログラムでもあってもよい。この種のアプリケーションの例としては、Microsoft社のInternet Explorer（登録商標）、Netscape Communications社のNetscape（登録商標）、またはその他のウェブブラウザアプリケーションなどがある。他のブラウザアプリケーションは、”Methods for Interactively Defining Transforms and for Generating Queries by Manipulating Existing Query Data”という名称の米国特許出願番号第１０/４６５２２２号に対応するオーストラリアの特許出願番号第２００３２０４８２４号に記載されたものであってもよい。

データサーバウィザード１０５は、利用者の操作１３５によってロードされたコンピュータ上で動作する。ウィザード１０５は、ネットワークから提供されるか、またはディスクのような媒体により提供されうる。利用者のコンピュータとデータソース１１５および１２５を接続するコンピュータネットワークを通じて、ウィザード１０５を操作することにより、データサーバ１１０および１２０が結果として生成される。サーバ１１０はソース１１５に対応するものであるが、これらは、必ずしも、同一の場所に配置されている必要はない。サーバ１２０とソース１２５についても同様である。サーバ１１０,１２０は、クライアントアプリケーション１３０からアクセスできるような状態で動作しているが、これは、コンピュータネットワーク内に存在するいかなるクライアントアプリケーション１３０（例えば、利用者の操作１３５がなされるコンピュータまたは他のいかなるコンピュータ）からもデータソース１１５、１２５へとアクセスできるようにするためである。

実施形態において記載されている装置および方法によれば、複数のデータソースのそれぞれに対応してデータサーバを設けることも可能である。また、これらのデータサーバは同時並行的に動作可能である。図１において、リレーショナルデータベース１１５およびファイルディレクトリ１２５の２つのデータソースと、それらに対応する生成されたデータサーバ１１０および１２０が示される。サーバ１１０および１２０は、クライアントアプリケーション１３０と相互に作用して動作しうる。他の実施形態として、単一のデータソースに対し複数のデータサーバを生成してもよい。各々の生成されたデータサーバは、異なるスキーマを使用してデータを提供してもよい。

ウィザード１０５による異種のデータソースのためのデータサーバの生成は、図１５に示されるように、利用者の操作１３５に汎用コンピュータシステム１５００を使用してもよい。図１〜１４のウィザードプロセスは、例えば、アプリケーションプログラムをコンピュータシステム１５００の中で実行するソフトウェアとして実装されていてもよい。特に、異種のデータソースにおけるデータサーバ生成方法のステップは、コンピュータにより実行されるソフトウェアの命令により実行される。命令は、一以上のコードモジュール（各々は一以上の特定のタスクを実行する）として形成されてもよい。また、ソフトウェアは、以下の２つの別々の部分に分けられることも可能である。第１の部分はウィザードの処理を実行し、第２の部分は第１の部分と利用者の間のユーザインターフェースを管理する。例えば、ソフトウェアは、後述する記憶装置を含むコンピュータ可読記憶媒体に記憶されていてもよい。ソフトウェアは、コンピュータ可読記憶媒体からコンピュータにロードされ、コンピュータにより実行される。この種のソフトウェアを有しているコンピュータ可読記憶媒体やそれに記録されるコンピュータプログラムは、コンピュータプログラム製品と呼べるであろう。コンピュータにおいて当該コンピュータプログラムを使用することにより、異種のデータソースに係るデータサーバを生成するための進歩した装置を実現しうる。

コンピュータシステム１５００は、コンピュータモジュール１５０１、キーボード１５０２およびマウス１５０３のような入力装置、プリンタ１５１５を含む出力装置、ディスプレイ装置１５１４およびスピーカ１５１７により形成される。通信ネットワーク１５２０を通じて通信する（例えば電話線路１５２１または他の媒体を経て接続）ために、変復調（モデム）トランシーバデバイス１５１６がコンピュータモジュール１５０１によって使用される。モデム１５１６は、例えば、インターネット、ローカルエリアネットワーク（LAN）またはワイドエリアネットワーク（WAN）のような他のネットワークシステムにアクセスするために用いられ、コンピュータモジュール１５０１に組み込まれていてもよい。

一般に、コンピュータモジュール１５０１は、例えば、少なくとも一つのプロセッサユニット１５０５と、ランダムアクセスメモリ（RAM）および読取り専用メモリ（ROM）を含む半導体記憶装置１５０６とを含んでいる。また、モジュール１５０１は、多数の入出力（I/O）インタフェースを具備している。例えば、ビデオディスプレイ１５１４およびスピーカ１５１７に取り付けられたオーディオ・ビデオ・インタフェース１５０７、キーボード１５０２、マウス１５０３や任意のジョイスティック（不図示）のための入出力インタフェース１５１３、モデム１５１６およびプリンタ１５１５のためのインタフェース１５０８などである。実施形態において、例えばインタフェース１５０８に搭載される等、モデム１５１６がコンピュータモジュール１５０１に組み込まれていてもよい。記憶装置１５０９には、一般に、ハードディスクドライブ（HDD）１５１０およびフロッピー（登録商標）ディスクドライブ（FDD）１５１１などが含まれてもよい。また、磁気テープドライブ（不図示）が使用されてもよい。CD−ROMドライブ１５１２は、一般的にデータの不揮発的なソースとして提供される。コンピュータモジュール１５０１の構成要素１５０５〜１５１３は、一般的に、関連した技術における公知のコンピュータシステム１５００の従来の動作モードに従って相互接続されたバス１５０４を経由して通信する。記載されている装置を実現できるコンピュータの例としては、IBM−PCとその互換機、Sun Sparcstationまたは類似したコンピュータシステムを含む。

一般的にアプリケーションプログラムはハードディスクドライブ１５１０に記憶されており、プロセッサ１５０５によって読み込まれ実行を制御される。プログラムおよびネットワーク１５２０から取得されるいかなるデータも、例えば、ハードディスクドライブ１５１０と協働して動作する半導体メモリ１５０６が使用されることで、中間記憶されてもよい。たとえば、アプリケーションプログラムはCD−ROMまたはフロッピー（登録商標）ディスク上にコード化されて記憶され、利用者に提供され、対応するドライブ１５１２または１５１１を経て読み込まれてもよいし、あるいは、利用者によって、モデムデバイス１５１６を経由してネットワーク１５２０から読み込まれてもよい。さらに、ソフトウェアは他のコンピュータ可読記憶媒体からコンピュータシステム１５００へロードされてもよい。ここで、”コンピュータ可読記憶媒体”という用語は、コンピュータシステム１５００において実行したり処理したりするための命令やデータを提供する際に関与するいかなる記憶媒体や伝送媒体も指すものとする。記憶媒体には、フロッピー（登録商標）ディスク、磁気テープ、CD−ROM、ハードディスクドライブ、ROMや集積回路、光磁気ディスクまたはPCMCIAカードなどのコンピュータ可読のカードが含まれ、この種のデバイスは、コンピュータモジュール１５０１に内蔵されてもよいし、外付されてもよい。伝送媒体の例としては、ネットワークによる他のコンピュータやネットワークデバイスへの接続と同様に無線通信、赤外線通信だけでなく、電子メールによる送受信やウェブサイトその他に記録された情報と同様にインターネットやイントラネットなども含まれよう。

一例としてのコンピュータシステム１５００によって、このようにデータソース１１５、１２５各々のためのハードウェア基盤が形成されてもよい。また、対応するデータサーバ１１０、１２０をホストするためのプラットフォームを提供してもよい。あるいは、データサーバ１１０および１２０は、データソース１１５および１２５を提供しているのとは別のコンピュータシステム１５００によってホストされていてもよい。さらに他の例示的なコンピュータシステム１５００は、クライアントアプリケーション１３０をサポートしてもよいし、データサーバウィザード１０５をサポートしてもよい。この方法によらば、図１に示される通信および接続を、ネットワーク１５２０を通じたコンピュータ装置間で実行または構築されてもよい。

図２は、データサーバを生成する好適な方法２００を表しているフローチャートである。方法２００は、データサーバウィザード１０５と呼ばれるコンピュータプログラムで実装されている。コンピュータ１５００を経由して入力された利用者の指示に応じた要求と命令に対して、データサーバウィザード１０５は、対話的に動作する。初期ステップ２０５で、データサーバウィザード１０５は利用者によるデータソースの選択を受信する。これは、図１７に示すようなデータサーバウィザード１０５のウインドウリストから、利用者がサポートされるデータソースの型を１つ選択することを含む。図１７のスクリーン左側のパネル１７９０は、データサーバウィザード１０５がデータサーバ１１０を構築しデプロイするために実行しなければならないステップを示している。現在のステップ１７９５が反転太字で示されている。

選択されたデータソースの型に従い、データサーバウィザード１０５は利用者に詳細情報の入力を促す。図１８は、リレーショナルデータソースの型が選択されたあと、利用者にリレーショナルデータベースの詳細な入力を促しているデータサーバウィザード１０５のウインドウを示す。この例では、利用者は、入力フィールド１８０５においてリストからリレーショナルデータベースの型を選択し、入力フィールド１８１０においてこのデータベースをホストしているコンピュータの名前を選択し、入力フィールド１８２０においてデータベースの名称を選択する。あるリレーショナルデータベースタイプ（例えばOracle（登録商標）9i）の場合には、入力フィールド１８３０において、所望のデータベースのスキーマ名を指定することが必要である。データサーバ１１０を構築する目的でデータソースにアクセスするために、利用者はさらに、入力フィールド１８４０および１８５０において利用者名およびパスワードを指定する。その場合、ウィザードはこの利用者が利用できるデータソースのデータにのみアクセス可能となる。

データサーバウィザード１０５は、異なるデータソースの型が入力された場合、異なる情報を必要とする。例えば、あるデータソースの型は利用者名およびパスワードを必要とするが他は必要としない。好ましい実施形態でサポートされるデータソースの型、および、データサーバウィザード１０５によって収集が必要となる詳細情報を下記にリストアップする。

(i) リレーショナルデータベースでは、データベースサーバホスト名およびデータベース名が必要である。ある場合には、例えばODBCデータソース名のように単にデータベースを識別するデータソース名のみであってもよい。加えて、データベースが保護されている場合には、データベースのアクセスに関する利用者認証の詳細がさらに必要になり得る。
(ii) メッセージサーバ（例えばMicrosoft社のExchange Server）では、サーバホスト名およびExchange Serverのアクセスに関する利用者認証の詳細が必要となる。
(iii) メールクライアントのローカルメールボックスでは、（例えばMicrosoft社のOutlook ExpressまたはNetscape Communications社のNetscape）メールクライアントの型が必要となる。
(iv) 半構造化データソース（例えばファイルのディレクトリ階層）では、ディレクトリパス名のリストが必要となる。
(v) テキストファイル（例えば区切り付きテキストファイル）では、ファイルのパス名および区切り文字の詳細が必要となる。
(vi) XML:DB APIをサポートするネイティブXMLデータベース（例えばXindice）では、データベースコレクションのURIが必要となる。
(vii) Lotus Domino（登録商標）では、Dominoサーバ名、Lotusデータベース名およびデータベースのアクセスに関する利用者認証の詳細が必要となる。本発明の範囲内において、他のデータソースタイプもまたサポートされうることは明らかである。

ステップ２１０では、ネイティブスキーマ情報が利用可能であれば使用し、あるいはデータソースのデータを使用する。そして、データサーバウィザード１０５は、共通データモデルの選択されたデータソースを表現するデフォルトXMLスキーマを生成する。ステップ２１０は、図３を用いて更に詳細に記載されている。また、ネイティブスキーマからデフォルトXMLスキーマへのマッピングは多数存在しうるが、そのマッピング処理の一例については図３を用いて後述する。

ステップ２１５では、データサーバウィザード１０５はディスプレイ１５１４を用いて生成されたデフォルトXMLスキーマのグラフィック表示を利用者に提示する。この表示の例は図１９に示されている。スキーマ１９００は、要素（１９０５、１９１０、１９１５、１９２０、１９２５、１９２６、１９２７、１９２８および１９２９）および属性（図１９において不図示）のツリーとして示される。前述したように、デフォルトスキーマはXMLスキーマ言語を使用して表現される。XMLスキーマソースは、図１９のタブ１９５０を選択することによって見ることが可能である。XMLスキーマにおいては、ベースとなる要素の型を定義することが可能である。複雑型は、他の要素および属性を含むことができる型である。単純型は、要素の内容が単純なデータ型を使用して表現されるものである。例えば、要素１９０５、１９１０、１９１５および１９２０は、これらの内容に他の要素（および、図１９において不図示の属性）を含むため複雑型要素である。しかしながら、要素１９２５、１９２６、１９２７、１９２８および１９２９は、これらの内容が単純なデータ型（例えば、図１９のxs:intやxs:string）により記載されているので単純型要素である。なお、接頭辞”xs”は、XMLスキーマ名前空間から名前を特定するために用いられる。

また、利用者は、生成されたXMLスキーマを使用して示されるデータソースから読み出される、ある例示的なデータのビューを選択することができる。これは、データサーバウィザード１０５の図１９のタブ１９６０を利用者が選択することによりなされる。利用者によるチェックのため、データはツリーフォーマットにより表示される。

利用者は、生成されたデフォルトXMLスキーマを対話的に修正できる。デフォルトXMLスキーマを修正するための命令を含むコンテキストメニューが提供され、図１９に示すようなデータサーバウィザード１０５のウインドウにおけるデフォルトXMLスキーマのグラフィック表示がアクセス可能となっていることが望ましいだろう。変更形態は、以下を含むが、これに限定されるものではない。

(i) 要素または属性の名前の変更
(ii) 要素から属性への変更およびその逆
(iii) 要素または要素のサブツリーの除外
(iv) 新規な複雑型要素の作成（既存の要素はこの新規要素の子となる別の場所に移されうる）
(v) 新規な単純型要素の作成（この種の要素の値は、既存の要素の値に由来されうる）

ステップ２２０では、データサーバウィザード１０５は生成されたデフォルトXMLスキーマに対する変更が利用者により必要か否かを決定する。必要であれば、データサーバウィザード１０５はディスプレイ１５１４に表示されるGUIを経由し、ステップ２２５で利用者によるデフォルトXMLスキーマへの有効な変更を許可する。変更が不要かまたは変更が完了すると、データサーバウィザード１０５の動作はステップ２３０へ進む。

ステップ２３０において、データサーバウィザード１０５は利用者の操作１３５によって入力されたデプロイに関する詳細な情報を受信する。このステップは、図２０に示されるウインドウに対応する。この種の詳細は、デプロイしたデータサーバ２０１０があることになっている目標ホストコンピュータ（例えば１５０１）の名前、および、デプロイされたデータサーバ２０２０の識別子を含んでもよい。一旦これらの構築の詳細が図２１で示されるデータサーバウィザード１０５のウインドウにおいて確認されると、ステップ２３５において、データサーバウィザード１０５はデータサーバ１１０を生成しデプロイするために動作を開始する。望ましくは、データサーバはApache Jakarta Tomcatサーブレットコンテナのサーブレットとしてデプロイされる。デプロイプロセスは、この説明の後詳細に説明する。こうして、選択されたデータソースは、デプロイされたデータサーバ１１０を経由してクライアントアプリケーション１３０によってアクセス可能となる。

この方法におけるいかなるステップにおいても、利用者はボタン１７０５を使用して前のステップに戻るか、ボタン１７１０を使用して次のステップへ進むか、ボタン１７１５を使用してデータサーバ１１０を構築しデプロイしたり、キャンセルしたりすることが可能である。望ましくは、データサーバウィザード１０５は、構築されるデータサーバ１１０の仕様の情報を保存できる。もし、必要になった際に、利用者のコンピュータは利用者の指示に応じて、データサーバウィザード１０５を再開し、保存したデータサーバの仕様の情報を再ロードすることにより、特定のデータサーバをデプロイ可能となる。データサーバ１１０を構築しデプロイすることに関係するステップが、ソフトウェアエンジニアリングに慣れていない利用者により操作され得ることは明らかである。利用者は、コンピュータプログラムやいかなるスクリプトも書くことなく、データサーバを構築しデプロイすることができる。また、利用者はデータベースクエリ言語についての知識を有する必要もない。さらにまた、データサーバウィザード１０５のステップ（図２参照）を完了するのにはごくわずかな時間しかかからない。このように、データサーバウィザード１０５は、未経験の利用者であっても、多数の異種のデータソースに対してアクセスできるように補助する。すなわち、共通データモデルとしてXMLを使用する統合されたアクセスをユーザに提供できるようになる。

データソースのデフォルトXMLスキーマはステップ２１０において生成される。データソースのデータの要素および属性のマッピングを特定するために、注釈要素がXMLスキーマに加えられる。

付録Aは、簡略化されたデフォルトXMLスキーマを示す。１０−１７行、４１−４８行および５５−６２行からそれぞれ分かるように、XMLスキーマの生成されたマッピング情報はXML注釈要素により保存される。xs:schema要素の１０−１７行のxs:annotation子要素は、mdbas:Settings要素およびmdbas：MappingInfo要素を含んでいる。（接頭辞”mdbas”は、データサーバウィザード１０５のために定義される名前空間から名前を特定する）このxs:annotation要素は、グローバルマッピング情報注釈要素と呼ばれる。mdbas:Settings要素は、データソースの詳細を保持するデータソース固有の子要素（例えばデータベース名）を含む。mdbas:MappingInfo要素も、マッピングのためにネイティブスキーマ情報を保持するデータソース固有の子要素を含む。

データサーバウィザード１０５によって生成される全てのXMLスキーマは、１８−３９行で見ることのできる、グローバル要素であるDataSourceを有する。この要素は、データソースのルート要素を定義する。DataSource要素は、データソースからマップされるデータを含む子孫要素を有する。これらの子孫要素はグローバルな複雑型の中の１つであり、付録ＡのXMLスキーマの４０−５３行または５４−６７行で定義されていることが確認できる。これら各々のグローバルな複雑型は、それぞれ４１−４８行または５５−６２行で見られるxs:annotation子要素を有し、複雑型で定義される要素のマッピング情報を含む。

次にデフォルトXMLスキーマを生成する方法の一例を記述する。この例では、リレーショナルデータソースであるCompanyデータベース７００（図７参照）が使用される。データベース７００は、４つのテーブル（すなわち、Department７１０、Project ７１５、ProjMember ７２０およびEmployee ７２５）を有する。各々のテーブルの主キーは、鍵記号７３０により示される。Departmentは、０以上のプロジェクトを有する。この関係はProjectテーブル７１５の外部キー７３５によって定義され、この場合の主キーはDepartmentテーブルを参照するDeptIDである。Projectはそのメンバとして０以上のEmployeeを有し、Employeeは０以上のProjectのメンバであってもよい。これらの関係は、ProjectテーブルおよびEmployeeテーブルに対する外部キーであるProjIDおよびEmpIDを有するProjMemberテーブルを使用することによって定義されている。

以下、デフォルトXMLスキーマを生成するステップ２１０を、図３および付録Bを参照してCompanyデータベース７００を用い詳細に説明する。ステップ３０５では、データサーバウィザード１０５は、ステップ２０５において取得したデータソースの詳細を使用し、選択されたデータベース（すなわち図７において示されるCompanyデータベース７００）に接続する。ステップ３１０では、データサーバウィザード１０５はデータベースのネイティブスキーマ情報を読み出す。リレーショナルデータベースにおいては、これはテーブル、各々のテーブルのカラムおよび主キーおよび外部キーの定義を含む。ステップ３１５で、データサーバウィザード１０５は、xs:schema要素および適切な名前空間定義を有するスケルトンXMLスキーマを生成する。それから、ステップ３１５は、xs:schema要素の子要素として、付録Bの１０−６４行で見られるグローバルマッピング情報注釈要素を付加する。グローバルマッピング情報注釈要素の中の１２−１９行で見られるmdbas:Settings要素は、選択されたデータベースの詳細を保持する子要素を含む。２０−６２行で見られるmdbas:MappingInfo要素は、データソースのデータからデフォルトXMLスキーマの要素へのマッピングに必要なネイティブスキーマ情報を保持する子要素を含む。リレーショナルデータベースでは、例えば図７示されるように、この情報はテーブルおよびテーブルの関係を含む。

ステップ３２０では、データサーバウィザード１０５はデータベース（７００）内の各々のテーブル（７１０−７２５）のためのグローバルな複雑型を生成する。各々の複雑型は、以下を含む：
(i) 対応するテーブルの各々のカラムのための単純型を有する要素
(ii) 対応するテーブルの外部キーにより参照される各々のテーブルのための複雑型を有する要素、
(iii) 対応するテーブルを参照している各々のテーブルのための複雑型を有する要素
例えば、付録Bの２２２−２９２行で見られるProject複雑型は、以下の子要素を含む：
(i) Projectテーブル７１５のフィールドのための、ProjID（２６７−２７３行）、ProjName（２７４−２８０行）およびDeptID（２８１−２８７行）
(ii) Projectテーブル７１５が外部キーDeptID ７３５を使用して参照するDepartmentテーブル７１０のためのDepartment（２８８行）
(iii) Projectテーブル７１５を参照するProjMemberテーブル７２０のためのProjMember（２８９行）

ステップ３２０において作成される各々の複雑型に対して、データサーバウィザード１０５は複雑型に対するxs:annotation子要素を付加する。このxs:annotation要素は、データソースから複雑型の各々の子要素へのマッピングを特定するためのmdbas:MappingInfo要素を含む。例えば、xs：Project複雑型（２２２−２９２行）のxs:annotation要素は、Project複雑型の各々の子要素のためのマッピング情報を含む。付録Bの１０−６４行で見られるグローバルマッピング情報注釈要素のマッピング情報と連携して、このマッピング情報を用いることにより、データサーバ１１０はXQueryを処理するために必要なデータソース１１５からデータを検索することが可能となる。データサーバ１１０によるデータ検索の方法は後で詳細に述べる。

最後に、ステップ３３０では、データソースの文書要素またはルート要素のためのグローバル要素が生成される。ここで、データサーバウィザード１０５は、６９−１２７行で見られるグローバル要素DataSourceを生成する。ステップ３３５では、７２−８４行などに見られる子要素、および、７５−８１行などに見られる孫要素が、データベース７００の各々のテーブル７１０−７２５について生成される。孫要素は、テーブルの対応する複雑型を有している。これは、テーブルの各々のレコードを要素インスタンスにマップする。子要素は、同じテーブルからマップされる要素のコンテナとして作用する。

図３のステップ２１０に従った方法を用いて生成されるデフォルトXMLスキーマは、複数のマッピングが可能であるデータソースの構造の複数の表現を提供することが可能である。図８は、Companyデータベース７００のために生成されたデフォルトXMLスキーマ８００を視覚的に示した図である。リーフノードである単純型要素は、説明の簡単化のために省略した。明確にツリー構造として示され、DepartmentItems、ProjectItems、ProjMemberItemsおよびEmployeeItemsから始まる各々のサブツリーは、要素間の親子関係を変化させることによりデータソースの異なるビューを提供する。XQueryは、データを特定するビューのため、これらのサブツリーのうちのいずれかのデータを読み出すために定式化されうる。例えば、XQueryにおける /DataSource/ProjectItems という表現は、プロジェクトデータおよびデータソースの各々のプロジェクトに関連する他のデータのビューを提供するProjectItemsサブツリーを選択する。

データサーバウィザード１０５によって、生成されるXMLスキーマは以下の２つの用途に使用される。第１に、データサーバ１１０によってクエリ処理の実行時に使用される。第２に、クライアントアプリケーション１３０によって、クエリを定式化する際にデータソース１１５の構造を決定するために使用される。後者の場合、好ましくは、マッピング情報注釈のないXMLスキーマは全てのクライアントアプリケーション１３０が利用できるように生成される。クライアントアプリケーション１３０によって使用されるXMLスキーマはマッピング情報を必要としないことが望ましい。他の実施形態において、XMLスキーマで注釈が付されているマッピング情報を、生成されたXMLスキーマとは別に蓄積してもよい。

共通データモデルのデータソースの構造を表現するためのデフォルトXMLスキーマ（任意でそのスキーマを修正）を生成することに加えて、好ましい実施例のさらなる特徴によって、所定のXMLスキーマをデータサーバとして用いることができる。XMLスキーマの勧告が情報の交換のための構文を定めるために用いられるようになるにつれ、所定のXMLスキーマにより定義される構文に従ってレガシーデータソースからの情報の取り込みが可能となることが望まれている。これは、データソースに格納されたデータ構造を変える必要が無いことを意味している。

所定のスキーマを有するデータサーバ１１０を生成する方法４００を図４に示す。方法４００はデータサーバウィザード１０５により実装され、ステップ４０５および４１０はそれぞれ前述したステップ２０５および２１０と同様である。ステップ４１５では、データサーバウィザード１０５は、生成されたデフォルトXMLスキーマから所定のXMLスキーマまで、利用者がインタラクティブに要素をマップすることができる。このステップは、図５を参照して以下で更に詳細に説明する。ステップ４２０では、ステップ２３５に記載されているように実質的にデータサーバウィザード１０５はデータサーバ１１０を生成しデプロイするが、この場合は、データサーバ１１０は生成されたデフォルトスキーマではなく所定のXMLスキーマを使用する。

生成されたデフォルトXMLスキーマを所定のスキーマにマップするステップ４１５の方法を、図５を参照して説明する。ステップ５０５では、利用者はデータサーバウィザード１０５の所定のXMLスキーマを特定する。これは、利用者１３０によって、キーボード１５０２を用いて所定のXMLスキーマファイルのパスを入力するか、または、GUIを用いてファイルダイアログを使用することによりなされてもよい。ステップ５１０では、サーバウィザード１０５は生成されたデフォルトXMLスキーマ１４０５および所定のXMLスキーマ１４１０の両方をGUIを用いて利用者に提示する。これは図１４に示されているように、グラフィカルに並べて表示される。

ステップ５１５では、デフォルトXMLスキーマの一以上の要素または属性を所定のXMLスキーマの要素または属性へのマッピングを、利用者は対話的に指定できる。これを実行する１つの方法として、例えば図１４に示されるようなグラフィカルユーザインタフェース（GUI）における利用者によるドラッグアンドアンドドロップ動作による実行とデータサーバウィザード１０５により操作がある。この操作において、デフォルトXMLスキーマのソース要素１４１５を表現している一以上のグラフィカルオブジェクトがマウス１５０３のクリック−ホールドにより選択され、ドラッグされ、ターゲット要素１４２０を表現しているグラフィカルオブジェクトまたはGUIの所定のXMLスキーマの属性にドロップ（マウス１５０３のクリックを解放）される。この、要素のマッピングはデータサーバウィザード１０５によって記録される。

マッピングを特定した後、ステップ５２０において、利用者はマップされるデータの変換を定義してもよい。この変換は、一以上の特定の変換関数に従い、書式つきの値または結合される複数の値であり得る。関数のタイプは以下を含んでいるが、以下に限定されない。
(i) フォーマット関数（数字の書式、通貨フォーマットなど）
(ii) 文字列関数（連結、部分文字列、大文字化など）
(iii) 算術演算
(iv) 統計関数（合計、カウント値、最大値、最小値および平均など）

ステップ５２５では、利用者はさらにマッピングを特定し続けることができる。データサーバウィザード１０５の一部分であるステップ４１５が終わると、ステップ５３０において、グローバルマッピング情報注釈要素である１０−６４行がデフォルトXMLスキーマから所定のXMLスキーマまでコピーが実行される。

ステップ５３５では、データサーバウィザード１０５は、ステップ５１５において記録された各々のマップされた要素の注釈付マッピング情報をデフォルトXMLスキーマから所定のXMLスキーマまでコピーする。ステップ５３５を、図６を参照して説明する。ステップ６０５では、データサーバウィザード１０５は所定のXMLスキーマのグローバルな要素の子注釈要素を生成する。

それからステップ６１０で所定のXMLスキーマツリーの事前のトラバースが開始される。なお、“トラバース”とは、ツリー内のノード間を移動する動作のことをいう。ステップ６１５では、デフォルトXMLスキーマからマッピングされた各々のトラバースした先のNp（要素または属性）のノードについて、データサーバウィザード１０５は、以下の情報を対応する所定のXMLスキーマにおけるNpのmdbas:MappingInfoノードへコピーする。

(i) マッピング定義（デフォルトXMLスキーマからマップされた要素Edのmdbas:Mapping要素）
(ii) Edの上位グループがNpの上位グループにすでにマップされるまでか、または、Edの上位グループがルート要素となるまでの、Edの各々の上位グループ要素のマッピング定義

所定のスキーマツリーにおける各ノードがトラバースされ、必要なマッピング定義がコピーされたとき、デフォルトXMLスキーマから所定のスキーマに対するマッピングは完了する。ステップ４１５の（図５および６に詳細に例示）デフォルトXMLスキーマを所定のXMLスキーマにマップする方法について例を用いながら説明する。付録Cは、利用者がCompanyデータベースからデータサーバを生成する所定のXMLスキーマを示す。付録Bは、CompanyデータベースのデフォルトXMLスキーマを示す。図９は、実質的に図８のスキーマツリー８００の分岐８０２であるデフォルトXMLスキーマ９０２と、所定のXMLスキーマ９０４の間に必要なマッピング９０６を示す。ただし、デフォルトXMLスキーマ９０２に関連した部分だけが図９に示される。図８とは異なり、図９は単純型要素も示している。

付録Dは、ステップ４１５のマッピングを実行した後の、マッピング情報の注釈が付与された所定のXMLスキーマ９０４を示す。ただし、付録Dにおいて以下の部分のセクションに注意する。

(i)５−５９行は、ステップ５３０に従いデフォルトXMLスキーマ９０２からコピーされ、グローバルマッピング情報注釈要素を定義する。
(ii) ６５−１１６行は、ステップ６０５−６１５に従いデフォルトXMLスキーマ９０２からコピーされた要素マッピング情報を表現する。
(iii) ６９−７１行は、デフォルトXMLスキーマ９０２の付録Bにおける１３３−１３５行に記述されているDepartment要素のマッピング定義から、ステップ６１５に従ってコピーされるDepartment要素のマッピング定義を提供する。
(iv) ７４−７７行は、デフォルトXMLスキーマ９０２の付録Bにおける１４５−１４８行に記述されているDeptName要素のマッピング定義から、ステップ６１５に従ってコピーされるName要素のマッピング定義を提供する。
(v) ８１−８３行は、デフォルトXMLスキーマ９０２の付録Bにおける１８３−１８５行に記述されているEmployee要素のマッピング定義から、ステップ６１５に従ってコピーされるEmployee要素のマッピング定義を提供する。
(vi) ８４−９８行は、デフォルトXMLスキーマ９０２の付録Bにおける２０２−２０４行、２９８−３００行、３２３−３２５行、２２７−２２９行および２２３−２２５行に記述されているEmployee要素の上位グループ要素のマッピング定義から、ステップ６１５に従ってコピーされるEmployee要素のマッピング定義である。ステップ６１５に従って所定のXMLスキーマ９０４のEmployee要素の親へすでにコピーされているため、上位グループ要素であるDepartmentのマッピング定義はコピーされない。
(vii) １０１−１０４行は、デフォルトXMLスキーマ９０２の付録Bにおける１８８−１９１行に記述されているEmpID要素のマッピング定義から、ステップ６１５に従ってコピーされるID要素のマッピング定義である。
(viii) １０８−１１１行は、デフォルトXMLスキーマ９０２の付録Bにおける１９５−１９８行に記述されているEmpName要素のマッピング定義から、ステップ６１５に従ってコピーされるName要素のマッピング定義である。

上記の例は、データサーバウィザード１０５が生成したデフォルトXMLスキーマ９０２から所定のXMLスキーマ９０４へのマッピング９０６を示す。マッピング情報９０６を有するこの所定のXMLスキーマ９０４は、Companyデータベースが所定のXMLスキーマ９０４に基づいてアクセス可能となるように、データサーバ１１０とともにデプロイされ得る。

（第２実施形態）
デフォルトXMLスキーマ９０２と所定のXMLスキーマ９０４の間のマッピング９０６を指定する代わりに、他の形態を使用してもよい。他の実施形態では、データサーバ１１０（デフォルトXMLスキーマによる指定されている）のデフォルトビューを、所定の（所望の）XMLスキーマにより指定されるデータのビューに変換するために変換XQueryが使用される。従って、上記の所定のXMLスキーマにおける格納マッピング９０６の代わりに、利用者は適切な変換XQueryを提供できる。変換XQueryは、利用者によってキーボード１５０２を使用し入力されるか、または、データサーバウィザード１０５によってアクセスされるテキストファイルとして提供され得る。

図９と同じ例を用いた場合、以下の変換XQueryは、所定のXMLスキーマと整合したデータのビューを提供する。

＜DepartmentInfo＞
{
for $i in /DataSource/DepartmentItems/Department
return
＜Department＞
{
＜Name＞
{
$i/DeptName/text()
}
＜/Name＞
}
{
for $j in $i/Project/ProjMember/Employee
return
＜Employee＞
{
＜ID＞
{
$j/EmpID/text()
}
＜/ID＞
}
{
＜Name＞
{
$j/EmpName/text()
}
＜/Name＞
}
＜/Employee＞
}
＜/Department＞
}
＜/DepartmentInfo＞

この実施形態において、データサーバ１１０はデータソース１１５のデータを利用者が指定した変換XQueryを使用して変換し、結果をデフォルトビューとして使用する。

（第３実施形態）
データソース１１５のデータを表現するためにデータサーバ１１０により使用可能となる所定のXMLスキーマのさらなる実施形態について説明する。第３の実施形態は、先に記載した２つの実施形態の組合せに関するものである。デフォルトXMLスキーマから所定のXMLスキーマへの要素および属性のマッピングは、第１実施形態のステップ５０５〜５２５で説明したように、本実施形態においてもウィザード１０５を使用している利用者によって実行される。対応するマッピング情報をデフォルトXMLスキーマから所定のXMLスキーマまでコピーする代わりに、記録されたマッピングが、データ（デフォルトXMLスキーマにより指定）のデフォルトビューから、データ（所定のXMLスキーマにより指定）の所望のビューにデータを変換するための変換XQueryを生成するために用いられる。それから、第２実施形態に記載されている変換XQueryが使用される。

データサーバウィザード１０５は、データソースがネットワークを通じてアクセスされ得るようにネットワークアドレス指定可能なデータサーバを生成しデプロイする。好適な実施形態において、このデータサーバ１１０はサーバ側ウェブアプリケーションであり、好ましくはJava（登録商標）サーブレットとして実装される。データサーバ１１０は、アプリケーションサーバ（例えばApache Software Foundationにより製造されるTomcat）によって、ホストされるサーバ側プログラムである。クライアントは、通信プロトコル（例えばHTTP）を使用してサーブレットに要求を送信し応答を受信できる。このサーバアプリケーションは、Uniform Resource Identifier（URI）によりアドレス指定が可能である。データサーバ１１０がデータソースを使用しているXMLスキーマを表現するため、クライアントアプリケーション１３０の複数のデータサーバへの統合したアクセスを提供することが可能となる。例えば、クライアントアプリケーション１３０は、データサーバ１１０を経由して複数のデータソースからデータを得る個々のクエリを処理できる。

クライアントアプリケーション１３０はデプロイされたデータサーバにアクセスするためにHTTPのgetやpostプロトコルを使用できる。getプロトコルを使用する場合、XQueryはURI内のパラメータとして含まれる。例として、URIである、 http://www.abc.com/DeptDS?xquery=/DepartmentInfo/Department は、提供されたXQuery表現式を使用して http://www.abc.com として識別されるネットワーク上のホストのDeptDSという名のデータサーバのデータにアクセスするために使用される。望ましくは、XQuery表現式はURI文字列として転送可能となるよう適切にコード化される。postプロトコルを使用する場合、XQuery表現式はHTTP要求の本体内で転送され得る。

重要なデータソースのデータサーバは、Secure Socket Layer（SSL）をHTTPの上の使用して（HTTPSと一般に呼称する）アクセスされることが望ましい。また、データサーバに対する要求は、利用者名およびパスワードなどの認証トークンを含むことが好ましい。そして、データサーバはデータソースにアクセスするために提供された認証トークンを使用する。認証トークンのタイプはデータソースの型に依存する。例えば、リレーショナルデータベースは一般的にデータベースとの接続前に利用者名およびパスワードを必要とする。認証トークンは、URIにコード化されるか本体またはHTTPS要求のヘッダにおいて付加的なパラメータとして転送されデータサーバに提供される。

好適な実施形態においても、利用者がデフォルト認証トークンを使用しているデータソース１１５のデータサーバ１１０を生成しデプロイできる。このことは、クライアントアプリケーション１３０は認証トークンを含むことなく、HTTP上のデータサーバにアクセス可能であることを意味する。デフォルト認証トークンは、デフォルトXMLスキーマのmdbas:Settings要素により格納されている。付録Bは、rm:DefaultUserName要素およびrm:DefaultPassword要素（それぞれ１７行および１８行）を含むデフォルトXMLスキーマの例を示しており、データサーバに向けられる全てのクエリに使用される。

図１０はデータサーバ１１０の構造を示しており、一般的にHTTPサーバ１０００にホストされる。データサーバウィザード１０５によって生成されたXMLスキーマ１００５の情報は、クライアントアプリケーションから入力されるクエリを処理する際に、実行時にデータサーバ１１０の各種コンポーネントによって使用される。コンポーネントは以下を含む：
(i) クエリパーサ１０１０（入力されるクエリ文字列を、処理のための適切な構造としてパースする）
(ii) クエリプロセッサ１０１５（入力されるクエリを分析し処理する）
(iii) クエリマッパー１０２０（XMLスキーマのマッピング情報を使用して、入力されるクエリを１以上のネイティブクエリまたはAPIコールにマッピングする）
(iv) データアクセス機構１０２５（ODBCその他のAPIなどの適切なデータアクセスミドルウェアを使用しているマップされたネイティブクエリを発行することにより、データソースからデータを読み出す）
(v) データシリアライザ１０３０（読み出されたデータをXMLに変換する）

望ましくは、上記のコンポーネントは、Java（登録商標）クラスとして実装され、データサーバの機能を構成する。クエリパーサ１０１０、クエリプロセッサ１０１５およびデータシリアライザ１０３０は、全てのデータサーバ１１０に共通である。クエリマッパー１０２０およびデータアクセス機構１０２５は、各々の型のデータソースに適用可能なように個別化される。データサーバウィザード１０５がデータサーバ１１０を生成する際に、データソースの型に対応する共通および個別化されたコンポーネントはXMLスキーマ１００５と共にウェブアーカイブファイル（.war）にパッケージ化される。望ましくは、データサーバウィザード１０５は、データサーバ１１０を、Tomcatマネージャのデプロイ機能によりウェブアーカイブファイルをアップロードおよびインストールすることにより、Tomcat（Apache Software Foundation）サーブレットコンテナのサーブレットとしてデプロイする。このようにデプロイすることにより、データサーバはクエリ要求を処理する準備が整う。明らかに、データサーバは他のウェブサーバ環境を使用してHTTPを通じてアクセス可能なサービスとしてデプロイされることが可能である。

クライアントアプリケーション１３０によりデータサーバ１１０に送信される、クエリ要求を処理する方法１１００を図１１に示す。この方法１１００は、図１０に示されるデータサーバ１１０の様々なコンポーネントにより実装される。

ステップ１１０５は、データサーバ１１０が動作開始する際に実行される初期化ステップである。ステップ１１０５で、クエリを処理する際に、データサーバ１１０は生成されたXMLスキーマおよび付随するマッピング情報を使用するスキーマツリーへロードする。このスキーマツリーは、対応するノードにマッピング情報（リーフノード）を有することを除くと、図８に示されるツリー８００に類似したスキーマのツリー構造である。入力されるクエリをデータソース１１５のネイティブクエリにマップする際に、このスキーマツリーは必要なマッピング情報を取得するためにトラバースされる。

それから、データサーバ１１０は、次々に入力されるクエリを処理するために、ステップ１１１０でループに入る。ステップ１１１５で、データサーバ１１０のクエリパーサコンポーネント１０１０は、入力されるクエリを処理のためのクエリ構造にパースする。なお、“パース”とは、文書構造を解析する処理のことをいう。そして、クエリを分析し、クエリプロセッサ１０１５によって実行計画を考慮することを含むステップ１１２０の処理が開始される。ステップ１１２０の詳細は、XQuery処理に関連した従来技術において周知である。

ステップ１１２５では、クエリマッパー１０２０は、入力されるクエリを処理するために必要なデータを読み出すために使用される１以上のネイティブクエリに入力されるクエリをマップする。他のデータソースの型は、必要なデータを読み出すために、入力されるクエリが一組のAPIコールにマップされる必要があり得る。このステップは、図１２を参照してさらに詳細に説明する。

ステップ１１３０では、データアクセス機構１０２５は、データソース１１５から必要なデータを読み出すために、マップされたネイティブクエリまたはAPIコールを使用する。それから、入力されるクエリはステップ１１３５のこのデータに評価される。ステップ１１４０で、データシリアライザ１０３０は、XMLとして結果をシリアライズし、クライアントアプリケーション１３０に結果を返す。

リレーショナルデータソースおよび図７において図示されるCompanyデータベースをデータソースとして参照し、ステップ１１２５について説明する。図１２のフローチャートは、ステップ１１２５において実行されるマッピング方式のステップを示す。XQueryは、読み出され処理されるデータを選択するためにXPath表現式を利用する。ステップ１２０５で、クエリマッパー１０２０は、XQueryのFOR句およびLET句の独立XPath表現式を識別する。XQueryによるCompanyリレーショナルデータベースデータソースへのクエリの例は下記のようになる。

＜RDProjects＞
for $i in /DataSource/DepartmentItems/Department
let $j := $i/Project
where $i/DeptName = "Research"
or $i/DeptName = "Development"
return { $j/ProjName }
＜/RDProjects＞

FOR句およびLET句の独立XPath表現式は、 /DataSource/DepartmentItems/Department である。従属表現式は独立表現式に由来するため、ネイティブクエリへのマッピングのために識別には独立XPath表現式のみ必要とされる。

ステップ１２１０において、これらのXPath表現式によって選択されたスキーマツリー内のノードのNiが特定され、対応するマッピング情報が読み出される。上記の例において、スキーマツリー内のDepartmentノードは特定され、そのノードのための付録Bの１３３−１３５行で示されるマッピング情報が読み出される。ステップ１２１５で、マッピング情報はNiにマップされるデータを読み出すためのＳＱＬ文を構築するために用いられる。WHERE句がXQueryの中に存在する場合、等価なWHERE句がＳＱＬ文に追加される。XQuery内のWHERE句の条件式の参照値が異なるテーブルからマップされる場合、このＳＱＬ文を構築する際に、等価なWHERE句が追加されるように１以上のJOIN句が追加される。上記のXQueryの例の場合、以下のＳＱＬ文は、Departmentノードのために構築される。

SELECT d.*
FROM Department d
WHERE d.DeptName = "Research"
OR d.DepartName = "Development"

ステップ１２２０では、クエリマッパー１０２０は、XQueryのRETURN句のXPath表現式を識別する。これらの表現式が通常用いられるが、必然的ではなく、FOR句またはLET句で識別されるXPath表現式に依存する。この例において、XPath表現式は、 $j/ProjName である。ステップ１２２５では、XPath表現式によって識別され選択されたスキーマツリーに特定される位置にノードRiは存在し、対応するマッピング情報が読み出される。例では、スキーマツリーのProjNameノードが存在している。ステップ１２３０で、ＳＱＬ文が同じテーブルからマップされるRiノードのために構築され、Riのデータが異なるテーブルからマップされる場合、多数のSQL文が必要であった。RiがFOR句またはLET句のXPath表現式に依存しているRETURN句のXPath表現式によって選択される場合、ＳＱＬ文を構築する際に、ノードNiおよびスキーマツリーのNiおよびRiの間のノードにマップされるテーブルを含まれなければならない。必要となる主キーおよび外部キーの情報は、これらのノードのマッピング情報にあり、適切なJOIN句を構築するために用いられる。例では、RETURN句のXPath表現式は、 $j/ProjName が $i/Project に依存するため、最終的にFOR句およびLET句の中では /DataSource/DepartmentItems/Department となる。Department、ProjectおよびProjNameのノードから読み出されるマッピング情報を用いて、ProjNameにマップするデータを選択しDepartmentおよびProjectにマップするテーブルに接合するために、以下のＳＱＬ文が構築される。

SELECT d.DeptID, p.ProjName
FROM Department d JOIN Project p
ON d.DeptID = p.DeptID
WHERE d.DeptName = "Research"
OR d.DeptName = "Development"

XQueryを評価する際に、クエリプロセッサ１０１５は、データが繰り返して処理されるよう、また、処理しそれぞれの結果を出力するため、FOR句およびRETURN句のXPath表現式からマップされるＳＱＬ文により返される結果セットを使用する。

リレーショナルデータソース１１５を参照して説明されているデータサーバ１１０を生成する方法は、また、他の型のデータソースのためのデータサーバを生成するために用いてもよい。データソースタイプに特有のマッピング情報は、ステップ２１０または４１０において、生成されなければならない。生成されたXMLスキーマ１００５の適切なマッピング情報については、クエリマッパー１０２０がXQueryを必要となるネイティブクエリまたはAPIコールにマップすることが可能である。そして、これらのネイティブクエリまたはAPIコールは、クエリを処理するために必要なデータを読み出すために、データアクセス機構１０２５によって使用される。都合のよいことに、データサーバ１１０は、適切なデータソースタイプ特有のクエリマッパー１０２０およびデータアクセス機構１０２５のようなステップ２３５または４２０のコンポーネントとともにデプロイされる。

データサーバを生成する方法を、階層的データソース（例えば、Microsoft Exchange Serverのようなメッセージ送信サーバ、または、Microsoft社により製造されるOutlookフォルダのようなメールクライアント）を参照して説明する。この方法は、実質的にリレーショナルデータソースの場合と同じであり、説明が主に階層的データソースに特有のマッピング情報の生成および使用の部分を強調する。

図１３は、典型的なメールクライアントのメールフォルダセットの階層１３００である。最上位フォルダであるPersonalFolders １３０２には、２つのメールフォルダInbox １３０４およびProjectMail １３０６が存在する。ProjectMailフォルダ１３０６はサブフォルダ、Research １３０８およびDevelopment １３１０を含み、それらはそれぞれのプロジェクトのメールを含む。典型的なメッセージ送信サーバの利用者のフォルダ階層は、通常、他の情報（例えばコンタクトおよびタスクなど）を保持するより多くのフォルダを含む。しかしながら、ここでは、階層的アプリケーションの説明のためには単純化されたサブセットで充分である。

方法２００および４００は、付録Eにて図示されるデフォルトXMLスキーマを生成するステップ２１０および４１０を有するメールクライアントデータソースと実質的に同じである。Companyリレーショナルデータベースのために生成される付録Bに示されるデフォルトXMLスキーマと同様に、グローバルマッピング情報注釈要素の中の１２−１５行にある付録Eのmdbas:Settings要素はデータソースの詳細（すなわち、データソースの型はOutlookおよびOutlook利用者の利用者名）を含んでもよい。

グローバルなxs:complexTypeが、各々の型のフォルダに保持されるデータを特定している。付録Eの１８０−１９２行のメールフォルダxs:complexTypeのみがXMLスキーマとして示される。

スキーマのグローバル要素DataSourceは、メールクライアントフォルダ階層の始まりである。付録BのCompanyデータベースのために生成されるXMLスキーマの６９−１２７行のグローバル要素とは異なり、グローバル要素DataSourceはデータソースの複数のビューを提供するための複数のサブツリーを含まず、階層的データソースからXMLスキーマへ基本的に１対１のマッピングとなっている。DataSource要素は、付録Eの、１６０行の子要素Inboxおよび１６１−１７３行の子要素ProjectMailを含む、１５７−１７６行に示される子要素PersonalFoldersを含む。ProjectMail要素は、さらに１６６行の子要素Researchおよび１６７行の子要素Developmentを含む。

グローバル要素DataSourceは、付録Eの２４−１５４行に子要素xs:annotationを有し、メールクライアントデータのマッピング情報を含む。このマッピング情報は、付録Eの９９−１０１行、９４−９６行、６５−６７行および３０−３２行などに示される、mdbas:Mapping要素のマッピング定義を含んでいる。それらのマッピング要素は、パスに関するメールクライアントデータソースから要素のマッピングを特定する。マッピング定義は、メールクライアントから必要データを読み出すために、XQueryを必要なAPIコールにマップするためにクエリマッパー１０２０によって使用される。

メールクライアントデータソースのために生成されるデータサーバ１１０によってXQueryを処理する方法１１００は、ステップ１１２５および１１３０における若干の差異を除いて、実質的にリレーショナルデータソースの方法と同様である。ステップ１１２５では、クエリマッパー１０２０は、表現式により選択される要素のマッピング定義を最初に調べることによって、XQueryの各々の独立XPath表現式をマップする。次に、クエリマッパー１０２０は、メールクライアントに必要なデータを特定するパスを形成するためにマッピング定義を使用する。例えば、XPath表現式 //Research/Message は以下の要素を選択する：
/DataSource/PersonalFolders/ProjectMail/Research/Message
この要素に対してマップしているメールクライアントのデータのパスは以下のようにして決定することができる。まず、ステップ１１０５において、初期化されたスキーマツリーのこの要素の位置を決め、そして、この要素およびその上位グループ（付録Eの９９−１０１行、９４−９６行、６５−６７行および３０−３２行など）のマッピング定義を読み出す。これらのマッピング定義は、データにメールフォルダをデータへナビゲートするのに必要な一連のAPIコールに対応するパス PersonalFolders/ProjectMail/Research/Message を形成するために用いられる。ステップ１１３０で、データアクセス機構１０２５は、XQueryの処理に必要なデータを読み出すために、適切なAPIコールを呼び出す。

所定のXMLスキーマを使用し、それが図５を参照して説明されたデフォルトXMLスキーマからコピーされる必要なマッピング情報を含む場合、クエリ処理は実質的に図１１を参照して上記で説明されたものと同様である。

所定のXMLスキーマが変換XQueryと連動して使われる場合、所定のスキーマを含んでいる他の実施形態にて説明したように、所定のXMLスキーマに関して表現される入力されるXQueryを、デフォルトXMLスキーマに関して表現される等価なXQueryに書き換えるための追加のステップが必要である。この追加のステップは、リレーショナルデータソースを使用した例のものと同様の入力されるXQueryを使用して説明される。

絶対パス表現がデフォルトXMLスキーマに関してのXQuery式と置き換えられるように、追加ステップは入力されるXQueryを書き換えることを含んでいる。

これは以下のように書き換えられてもよい。

＜RDProjects＞
let $dept :=
for $d in /DataSource/DepartmentItems/Department
return
＜Department＞
{
＜Name＞
{
$d/DeptName/text()
}
＜/Name＞
}
{
for $e in $d/Project/ProjMember/Employee
return
＜Employee＞
{
＜ID＞
{
$e/EmpID/text()
}
＜/ID＞
}
{
＜Name＞
{
$e/EmpName/text()
}
＜/Name＞
}
＜/Employee＞
}
＜/Department＞
for $i in $dept
let $j := $i/Project
where $i/DeptName = "Research"
or $i/DeptName = "Development"
return { $j/ProjName }
＜/RDProjects＞

入力されるXQueryの絶対パス表現”/DataSource/DepartmentItems/Department”は、変数 $dept に置き換えられる。この変数はLET句で定められ、その変数の値はXQueryに密接に結びつく。このXQueryは、オリジナルのパス表現により特定される要素を返すためのデフォルトXMLスキーマに関して表現されるものである。書き換えられたXQueryは、デフォルトXMLスキーマに関して表現される。このXQueryは図１１を参照して説明したように処理されてもよい。

データサーバを生成する方法２００および４００および生成されたデータサーバによってXQueryを処理する方法１１００の説明を、リレーショナルデータソースおよび階層的データソースの両方を参照して説明したように、この方法も、リレーショナルデータソースおよび階層的データソースに使用することが可能である。従来技術を知っている人々であれば理解できるように、記載されている方法は他のいろいろな形で実施されることができるか、またはそれの基本的特徴から逸脱することなく、データソースの他の型をカバーするために拡張することができる。

図１６は図１に類似した表現を示しているが、クエリシステム１６００は、データソース１６１５のデータをクライアントアプリケーション１６３０に提供するためのデータサーバ１６１０を形成するために動作しているウィザード１６０５により形成され、各々のウィザード１６０５、クライアントアプリケーション１６３０、データサーバ１６１０およびデータソース１６１５は通信ネットワーク１６５０によって接続されており、より一般的な形として示されている。データソース１６１５は、ネイティブデータ型およびデータ構造に配置されたデータを有する。ウィザード１６０５は、最初にネットワーク１６５０の上のデータソース１６１５を識別する。さらにウィザード１６０５は、データ構造と識別されたデータソース１６１５のうちの少なくとも１つをトラバースするためのアプリケーションプログラムを提供する。アプリケーションプログラムは、ネイティブデータ型を共通データモデルの所定のデータ型に変換するためのマッピングデータを含む代表スキーマ１６１４を生成するように動作可能である。さらにウィザード１６０５は、ネイティブデータ型から所定のデータ型へとデータの型を変換し、代表スキーマ１６１４を使用するのに適しているサーバアプリケーション１６１２を作成する。この作成されたサーバアプリケーション１６１２を用いることで、ネットワーク１６５０を通じ、クライアントアプリケーション１６３０に対しデータを共通データモデルに従って提供可能となる。こうして、代表スキーマ１６１４およびサーバアプリケーション１６１２は、ウィザード１６０５により生成されるデータサーバ１６１０を形成する。データサーバ１６１０が一旦形成されると、クライアントアプリケーション１６３０からクエリを受信し応答してもよく、ネイティブデータ型についての知識を有すること無くデータソース１６１５に誘導することを可能とする。

付録Aは、簡略化されたデフォルトXMLスキーマを示す。

付録Bは、CompanyデータベースのデフォルトXMLスキーマを示す。

付録Cは、利用者がデータサーバを生成するCompanyデータベースの所定のXMLスキーマを示す。

付録Dは、マッピング情報の注釈が付与された所定のXMLスキーマを示す。

付録Eは、OutlookデータソースのデフォルトXMLスキーマである。

記載されている実施形態は、コンピュータ産業界およびデータ処理産業界において利用でき、特に異種のデータソースからデータを取り出す技術に関連する。

本実施形態は、本発明の一例のみを記載しており、本発明の範囲内で修正や変更等が可能である。また、実施形態は例示的であって限定的なものではない。

異種のデータソースにアクセスするためのシステムアーキテクチャを示す図である。デフォルトスキーマを有するデータサーバを生成する方法のフローチャートである。リレーショナルデータソースのためのデフォルトスキーマを生成するための、図２のステップの詳細を示すフローチャートである。所定のスキーマを有するデータサーバを生成する方法のフローチャートである。デフォルトスキーマを所定のスキーマにマップするための、図４のステップの詳細を示すフローチャートである。マップされた要素のために、マッピング情報をデフォルトスキーマから所定のスキーマにコピーする方法のフローチャートである。さまざまな方法を例示するために使用するCompanyデータベースのスキーマ図である。 Companyデータベースのために生成されたデフォルトXMLスキーマを示す図である。 Companyデータベースにおける、デフォルトXMLスキーマから所定のXMLスキーマに必要なマッピングを示す。データサーバの構造である。クライアントから入力されたクエリをデータサーバが処理する方法を示すフローチャートである。 XQueryをＳＱＬ文にマップするために、XQueryを処理するために必要データを読み出すための図１１のステップの詳細を示すフローチャートである。一組のOutlookメールフォルダの階層を示している図である。デフォルトXMLスキーマを所定のXMLスキーマにマップするためのグラフィックユーザインターフェースである。記載された実施形態が実現可能な汎用コンピュータの概略ブロック図である。異種のデータソースにアクセスするためのより一般的なシステムアーキテクチャである。データサーバが生成されるデータソースのデータソースタイプを選択するためのデータサーバウィザードウインドウの図である。データサーバが生成されるリレーショナルデータソースの詳細を入力するためのデータサーバウィザードウインドウの図である。生成されたデフォルトXMLスキーマを表示し修正するためのデータサーバウィザードウインドウの図である。生成されたデータサーバのデプロイ詳細を入力するためのデータサーバウィザードウインドウの図である。生成されデプロイされるデータサーバの詳細を表示し確認するためのデータサーバウィザードウインドウの図である。

Claims

ネイティブデータ型のデータソースからクライアントアプリケーションにデータを提供するためのデータサーバを形成するためのアプリケーションプログラムを提供する工程を含むデータサーバの形成方法であって、
前記アプリケーションプログラムに基づいて、プロセッサが、
前記データソースを識別する工程と、
前記識別されたデータソースについてデータ構造を含む検査を行う工程と、
前記ネイティブデータ型から共通データモデルの所定のデータ型へと変換するためのマッピングデータを含む代表スキーマを使用し、かつ、前記共通データモデルに従って前記クライアントアプリケーションに前記データを提供するよう構成されたサーバアプリケーションを生成する工程と
を実行することで、前記代表スキーマおよび前記サーバアプリケーションにより前記データサーバが形成されることを特徴とするデータサーバの形成方法。
前記データソースは、リレーショナルデータソースおよび階層的データソースから選択されることを特徴とする請求項１に記載のデータサーバの形成方法。
前記データソースにはデータベースが含まれることを特徴とする請求項１または２のいずれかに記載のデータサーバの形成方法。
前記アプリケーションプログラムが、更に、ネットワークを通じて前記データソースのデータへのアクセスを可能にするために、前記生成されたサーバアプリケーションをデプロイする工程を含むことを特徴とする請求項１に記載のデータサーバの形成方法。
更に、URIを使用して、前記デプロイされたサーバアプリケーションにより形成される前記データサーバにアクセスする工程を含むことを特徴とする請求項４に記載のデータサーバの形成方法。
ネイティブデータ型データソースとクライアントアプリケーションの間でデータを提供するためのデータサーバをコンピュータに形成させるコンピュータプログラムであって、
前記コンピュータプログラムが、
前記データソースを識別するコードと、
前記識別されたデータソースについてデータ構造を含む検査を行うコードと、
前記ネイティブデータ型から共通データモデルの所定のデータ型へと変換するためのマッピングデータを含む代表スキーマを使用し、かつ、前記共通データモデルに従って前記クライアントアプリケーションに前記データを提供するよう構成されたサーバアプリケーションを生成するコードと
を含むことで、前記代表スキーマおよび前記サーバアプリケーションにより前記データサーバを形成させることを特徴とするコンピュータプログラム。
前記コンピュータプログラムが、第１のコンピュータに供給可能であり、かつ、前記データサーバを第２のコンピュータにおいて形成するために前記第１のコンピュータにおいて実行可能であり、
前記第１のコンピュータと前記第２のコンピュータはネットワークの一部を形成していること
を特徴とする請求項６に記載のコンピュータプログラム。
前記クライアントアプリケーションは、常駐アプリケーションであり、かつ、第３のコンピュータから操作可能であり、
前記データソースは、第４のコンピュータと前記第２のコンピュータのいずれかに基づいて生成されること
を特徴とする請求項７に記載のコンピュータプログラム。
ネイティブデータ型データソースからクライアントアプリケーションにデータを提供するためのデータサーバを形成するコンピュータ装置であって、
前記コンピュータ装置が、
前記データソースを識別する手段と、
前記識別されたデータソースについてデータ構造を含む検査を行う手段と、
前記ネイティブデータ型から共通データモデルの所定のデータ型へと変換するためのマッピングデータを含む代表スキーマを使用し、かつ、前記共通データモデルに従って前記クライアントアプリケーションに前記データを提供するよう構成されたサーバアプリケーションを生成する手段と
を含むことで、前記代表スキーマおよび前記サーバアプリケーションにより前記データサーバを形成するコンピュータ装置。