(57)【要約】【課題】複数データ・リポジトリーの環境にあるデータにアクセスする方法、コンピュータ・プログラム、およびコンピュータを提供すること。【解決手段】本発明は、一般に、データが物理的に表される特定の方法と関係なく、データにアクセスするためのシステム、方法、および製品を対象とする。一実施形態では、データ・リポジトリー抽象化層は、データ表現の特定の方法とは無関係の、基礎データ・リポジトリーの論理図を提供する。一実施形態では、データ・リポジトリ抽象化層は、リポジトリーのデータの位置およびデータにアクセスする方法を指定する。照会抽象化層も提供されるが、これはデータ・リポジトリー抽象化層に基づいている。ランタイム・コンポーネントは、抽象照会の、特定の物理データ表現に対して使用することのできる形式への翻訳を実行する。
2005524138.tif 000002
【特許請求の範囲】
【請求項１】
複数のデータ・リポジトリーの環境にあるデータにアクセスする方法において、
要求側エンティティの照会指定に従う抽象照会であって、前記照会指定によりその有する複数の論理フィールドに関する定義が提供される前記抽象照会を、前記要求側エンティティからを受信するステップと、
物理エンティティのそれぞれにアクセスする方法および前記物理エンティティのそれぞれの位置を定義することにより、前記論理フィールドを前記データの前記物理エンティティにマッピングするアクセス方法に従い、前記抽象照会を、前記データの特定の物理データ表現に整合する照会に変形するステップと
を含む方法。
【請求項２】
前記抽象照会を、前記特定の物理データ表現に整合する前記照会に変形するステップが、前記抽象照会を、アクセス方法のタイプに従いグループ化された副照会に分割するステップを含む請求項１に記載の方法。
【請求項３】
前記アクセス方法のタイプが、ＳＱＬ照会タイプ、ＸＭＬ照会タイプ、および手順要求タイプを含む一群から選択される請求項１または２に記載の方法。
【請求項４】
前記複数の論理フィールドの特定の論理フィールドに対して前記データの物理エンティティに対する前記位置により指定された、データ・リポジトリーにアクセスするステップをさらに含む請求項１ないし３のいずれかに記載の方法。
【請求項５】
前記抽象照会が、少なくとも１つの選択基準および結果指定を含む請求項１ないし４のいずれかに記載の方法。
【請求項６】
前記複数の論理フィールドの特定の論理フィールドに対する前記データの物理エンティティに対して、前記データの前記物理エンティティがローカル・キャッシュに配置されているか否かを判定するステップと、
配置されていない場合、前記データの前記物理エンティティのためのアクセス方法で、前記位置により指定されたデータ・リポジトリーにアクセスするステップと
をさらに含む請求項１ないし５のいずれかに記載の方法。
【請求項７】
コンピュータで実行された場合に、請求項１ないし６のいずれかに記載の方法を実行するよう構成されたプログラム・コード手段を含むコンピュータ・プログラム。
【請求項８】
コンピュータにおいて、
少なくとも（ｉ）複数の論理フィールドを含む抽象照会のための定義を提供する照会指定と、（ｉｉ）前記論理フィールドをデータの物理エンティティにマッピングするマッピング規則を含む、データ・リポジトリー抽象化コンポーネントであって、前記マッピング規則が、前記抽象照会の前記論理フィールドの少なくとも一部のそれぞれに対する位置指定を含み、前記位置指定のそれぞれが、アクセスされるべき物理エンティティを含むデータ・ソースの位置を指定する、データ・リポジトリー抽象化コンポーネントと、（ｉｉｉ）前記抽象照会を、前記マッピング規則に従いデータの前記物理エンティティに整合する照会に変形するためのランタイム・コンポーネントとを含むメモリと、
前記メモリの内容を実行するよう構成されたプロセッサと
を含むコンピュータ。
【請求項９】
前記それぞれの位置指定により指定された前記データ・ソースの第１の部分はローカルであり、第２の部分は遠隔である請求項８に記載のコンピュータ。
【請求項１０】
前記抽象照会を、前記特定の物理データ表現に整合する前記照会に変形するステップが、前記抽象照会を、アクセス方法のタイプに従いグループ化された副照会に分割するステップを含む請求項８または９に記載のコンピュータ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数データ・リポジトリーの環境にあるデータにアクセスする方法、コンピュータ・プログラム、およびコンピュータに関する。
【背景技術】
【０００２】
データベースは、電算化した情報記憶および取り出しシステムである。リレーショナル・データベース管理システムは、データを記憶し、取り出すためにリレーショナル技術を使用する、コンピュータのデータベース管理システム（ＤＢＭＳ）である。最も普及しているタイプのデータベースは、リレーショナル・データベース、すなわち、様々な異なる方法で認識し、アクセスできるようにデータが定義される、表形式データベースである。
【０００３】
特定のアーキテクチャに関係なく、ＤＢＭＳでは、要求側エンティティ（例えば、アプリケーション、オペレーティング・システム、またはユーザ）は、データベース・アクセス要求を発行することにより、指定したデータベースへのアクセスを求める。このような要求は、例えば、単純なカタログ・ルックアップ要求またはトランザクション、およびデータベースで指定した記録を読み取り、変更し、追加するよう動作するトランザクションの組合せを含むことができる。これらの要求は、構造化照会言語（ＳＱＬ）のような高度な照会言語を使用して成される。例示として、ＳＱＬは、International Business Machine（ＩＢＭ）社のＤＢ２、Microsoft社のＳＱＬ Server、およびOracles、Sybase、およびCompterAssociates社のデータベース製品のようなデータベースから情報を取得し、これを更新する目的で、対話式の照会を行うために使用される。「照会」という用語は、記憶されたデータベースからデータを取り出すための一組のコマンドのことである。照会は、プログラマーおよびプログラムに、データの位置を選択、挿入、更新、検索などさせるコマンド言語の形式を取る。
【０００４】
データ・マイニングおよびデータベース照会アプリケーションが直面する問題の１つは、一般に、所与のデータベース・スキーマ（例えば、リレーショナル・データベース・スキーマ）との、それらの緊密な関係である。この関係により、対応する基礎データベース・スキーマに変更が成される際に、アプリケーションをサポートすることが困難になる。さらに、代替の基礎データ表現へのアプリケーションのマイグレーションは禁止される。今日の環境では、上記の欠点は、照会中の情報を表すためにリレーショナル・モデルが使用されることを想定する、ＳＱＬを依存アプリケーションが使用することに大きく起因する。さらに、具体的なデータベース・テーブル、欄、および関係がＳＱＬ照会表現内で参照されるので、所与のＳＱＬ照会は特定のリレーショナル・スキーマに依存する。これらの制限の結果、いくつかの問題が発生する。
【０００５】
１つの問題は、基礎リレーショナル・データ・モデル内の変更が、対応するアプリケーションが構築されるＳＱＬファウンデーションへの変更を要求することである。したがって、アプリケーション設計者は、アプリケーションの維持を避けるために基礎データ・モデルの変更に先行するか、または基礎リレーショナル・モデル内の変更を反映するようアプリケーションを変更する必要がある。別の問題は、複数のリレーショナル・データ・モデルで作業するようアプリケーションを拡張することにより、それぞれの固有のリレーショナル・スキーマが促進する固有のＳＱＬ要件を反映することが、別々のバージョンのアプリケーションに要求されることである。さらに別の問題は、ＳＱＬがリレーショナル・システムと共に使用するよう設計されているので、交互のデータ表現で作業するための、アプリケーションの発展である。ＸＭＬのような代替のデータ表現をサポートするようアプリケーションを拡張することにより、非ＳＱＬアクセス方法を使用するためにアプリケーションのデータ管理層を書き直すことが必要になる。
【０００６】
上記問題に対処するために使用される典型的な方法は、ソフトウェアのカプセル化である。ソフトウェアのカプセル化は、特定の基礎データ表現にアクセス方法をカプセル化するための、ソフトウェア・インターフェースまたはコンポーネントの使用を伴う。一例は、Java（Ｒ）（商標）2 Enterprise Edition（Ｊ２ＥＥ）スイート技術の一コンポーネントである、EnterpriseJava（Ｒ）Bean（商標）（ＥＪＢ）仕様にある。ＥＪＢの例では、エンティティ・ビーンズは、当該情報にアクセスするために使用することのできる一組のアプリケーション・プログラム・インターフェース（ＡＰＩ）を公開して、所与の一組のデータをカプセル化するよう機能する。これは、新しい一組のデータがアクセスされるべき時は何時でも、または新しいパターンのデータ・アクセスが望まれる場合は、（新しいエンティティＥＪＢの形式で）ソフトウェアが書き込まれることを要求する、高度に特化された方法である。ＥＪＢモデルはまた、基礎物理データ・モデルの再構成に反応するか、または代替のデータ表現をサポートするために、コード更新、アプリケーション構築、および展開周期も必要とする。ＥＪＢプログラミングはまた、さらに高度なJava（Ｒ）プログラミング技術を必要とするので、特化されたスキルも必要とする。したがって、ＥＪＢ方法、および他の類似の方法は、進化する物理データ・モデルにアクセスする汎用照会アプリケーションの場合は、維持するのにかなり柔軟性に欠け、費用が掛かる。（Java（Ｒ）およびすべてのJava（Ｒ）ベースの商標は、米国または他の国の、あるいはその両方のSunMicrosystems社の商標である。）
【０００７】
異種のデータ表現にアクセスする問題に加え、今日の環境は、データがしばしば高度に分散されていることにより複雑化する。インターネットのような普及したインフラストラクチャは、価値あるものとなるべく、ユーザにとってアクセス可能になる必要のある多数のデータ・ソースを含む。ローカライズされ、均質化したデータを扱う従来の解決策は最早実用的でなく、分散された異種のデータを扱うよう開発途上にある解決策は、各データ・ソースの位置の知識を有する必要があり、それぞれの異なる種類のデータ表現を取り扱うために独自の論理（ソフトウェア）を提供する必要があるので、問題が多い。したがって、（ウェアハウスを使用してアプリケーションにより要求される情報のすべてを含んでいる、データ・ウェアハウスの提供のような）典型的な解決策は、消費中のデータの位置または表現を変更するために容易に構成されることはなく、異なるデータ・トポロジーで作業するために容易に再配置することはできない。ウェアハウスの内容を追加の、公に使用可能な情報で拡張する必要がある場合も、データ・ウェアハウスは問題を生じる。場合によっては、外部データ・ソースは非常に大きく、変更を受ける可能性がある。所与のデータ・ウェアハウス内のそのようなデータのローカル・コピーを維持するには、非常に費用が掛かる場合がある。
【特許文献１】整理番号ＲＯＣ９２００２００８８（対応日本特許出願  特開２００３−３２３３２４）
【発明の開示】
【発明が解決しようとする課題】
【０００８】
したがって、基礎物理データが表現される特定の方法に限定されない、データにアクセスするための、改善された、より柔軟な方法が求められている。
【課題を解決するための手段】
【０００９】
一態様によれば、本発明は、複数のデータ・リポジトリーの環境にあるデータにアクセスする方法において、要求側エンティティの照会指定に従う抽象照会（abstract query）であって、照会指定によりその有する複数の論理フィールドに関する定義が提供される抽象照会を受信するステップと、物理エンティティのそれぞれにアクセスする方法および当該物理エンティティのそれぞれの位置を定義することにより、前記論理フィールドを前記データの前記物理エンティティにマッピングするアクセス方法に従い、前記抽象照会を、前記データの特定の物理データ表現に整合する照会に変形するステップとを含む方法を提供する。
【００１０】
当然ながら、この方法は、コンピュータ・ソフトウェアを使用して実行することができる。
【００１１】
好ましくは、データ・スキームおよび照会抽象化（query abstraction）による、分散したデータ・ソースの遠隔データ・アクセスおよび統合のための方法、コンピュータ・プログラム、およびコンピュータが提供される。
【００１２】
本発明は、データが物理的に表現される特定の方法とは関係なく、データにアクセスするための方法、コンピュータ、およびコンピュータ・プログラムを好適に対象とする。好ましくは、アプリケーションが使用するために使用可能な様々な分散したデータ・ソースを表し、これらデータ・ソースに含まれる情報にアクセスすること、または更新すること、あるいはその両方のことを行うために、アプリケーションが使用する照会を記述するために、抽象化層が提供される。ランタイム・コンポーネント（runtime component）は、データ・リポジトリー抽象化コンポーネント（抽象化層の１つ）に含まれる情報を使用して、抽象照会を、１つまたは複数のデータ・リポジトリーを求める具体的なデータ・アクセス要求に分解する役割を好適に担う。
【００１３】
一実施形態は、特定の物理データ表現を有するデータへのアクセスを提供する方法を提供する。この方法は、要求側エンティティに対して、抽象照会を定義するための複数の論理フィールドを含む照会指定を提供するステップと、前記複数の論理フィールドを前記データの物理エンティティにマッピングするデータ・リポジトリー抽象化を提供するステップとを含む。一実施形態では、データ・リポジトリー抽象化は、各論理フィールドに対して、前記データの物理エンティティの位置を定義する少なくとも１つのロケーターと、前記データの前記物理エンティティにアクセスするための機構を定義するアクセス方法とを含む。
【００１４】
一実施形態は、プロセッサと、少なくとも（ｉ）複数の論理フィールドを含む抽象照会に関する定義を提供する照会指定を含む要求側エンティティと、（ｉｉ）前記論理フィールドをデータの物理エンティティにマッピングするマッピング規則を含むデータ・リポジトリー抽象化コンポーネントであって、前記マッピング規則が、前記抽象照会の前記論理フィールドの少なくとも一部のそれぞれに対する位置指定を含み、前記位置指定のそれぞれが、アクセスされるべき物理エンティティを含むデータ・ソースの位置を指定する、データ・リポジトリー抽象化コンポーネントと、（ｉｉｉ）前記抽象照会を、前記マッピング規則に従いデータの前記物理エンティティに整合する照会に変形するためのランタイム・コンポーネントとを含むメモリとを含むコンピュータを提供する。
【００１５】
別の態様によれば、少なくとも（ｉ）複数の論理フィールドを含む抽象照会のための定義を提供する照会指定と、（ｉｉ）前記論理フィールドをデータの物理エンティティにマッピングするマッピング規則を含む、データ・リポジトリー抽象化コンポーネントであって、前記マッピング規則が、前記抽象照会の前記論理フィールドの少なくとも一部のそれぞれに対する位置指定を含み、前記位置指定のそれぞれが、アクセスされるべき物理エンティティを含むデータ・ソースの位置を指定する、データ・リポジトリー抽象化コンポーネントと、（ｉｉｉ）前記抽象照会を、前記マッピング規則に従いデータの前記物理エンティティに整合する照会に変形するためのランタイム・コンポーネントとを含むメモリと、前記メモリの内容を実行するよう構成されたプロセッサとを含むコンピュータが提供される。
【００１６】
一実施形態によれば、複数のデータ・リポジトリーの環境にあるデータへのアクセスを提供する方法において、要求側エンティティに対して、抽象照会を定義するための複数の論理フィールドを含む照会指定を提供するステップと、前記複数の論理フィールドのそれぞれに対して、少なくとも前記データにアクセスする方法および前記データの位置を指定するアクセス方法を提供するステップとを含む方法が提供される。
【００１７】
好ましくは、この方法は、前記照会指定に従い前記要求側エンティティにより前記抽象照会を発行するステップと、前記抽象照会を、前記データの特定の物理データ表現に整合する照会に変形するステップと、前記複数の論理フィールドの特定の論理フィールドに対する前記データの前記物理エンティティのためのアクセス方法で、前記位置により指定されるデータ・リポジトリーにアクセスするステップとをさらに含む。
【００１８】
好ましくは、前記特定の物理データ表現に整合する前記照会は、ＳＱＬ照会、ＸＭＬ照会、および手順要求の１つである。
【００１９】
好ましくは、前記抽象照会を、前記特定の物理データ表現に整合する前記照会に変形するステップは、前記抽象照会を、アクセス方法のタイプに従いグループ化された副照会（sub-query）に分割するステップを含む。
【００２０】
好ましくは、このアクセス方法のタイプは、ＳＱＬ照会タイプ、ＸＭＬ照会タイプ、および手順要求タイプを含む一群から選択される。
【００２１】
好ましい実施形態によれば、複数のデータ・リポジトリーの環境にあるデータにアクセスする方法において、要求側エンティティの照会指定に従う抽象照会であって、照会指定によりその有する複数の論理フィールドに関する定義が提供される抽象照会を、要求側エンティティにより発行するステップと、物理エンティティのそれぞれにアクセスする方法と前記物理エンティティのそれぞれに対する位置とを定義することにより、前記論理フィールドを前記データの前記物理エンティティにマッピングするアクセス方法に従い、前記抽象照会を、前記データの特定の物理データ表現に整合する照会に変形するステップとを含む方法が提供される。
【００２２】
好ましくは、前記複数の論理フィールドの特定の論理フィールドに対する前記データの物理エンティティに対して前記位置により指定された、データ・リポジトリーにアクセスすることができる。
【００２３】
好ましくは、前記抽象照会は、少なくとも１つの選択基準および結果指定を含む。
【００２４】
好ましくは、この方法は、前記複数の論理フィールドの特定の論理フィールドに対する前記データの物理エンティティに対して、前記データの前記物理エンティティがローカル・キャッシュに配置されているか否かを判定するステップと、配置されていない場合、前記データの前記物理エンティティのためのアクセス方法で、前記位置により指定されたデータ・リポジトリーにアクセスするステップとを含む。
【００２５】
好ましくは、前記抽象照会の、前記特定の物理データ表現に整合する前記照会への変形が、前記抽象照会を、アクセス方法のタイプに従いグループ化された副照会に分割するステップを含む。
【００２６】
好ましくは、このアクセス方法のタイプは、ＳＱＬ照会タイプ、ＸＭＬ照会タイプ、および手順要求タイプを含む一群から選択される。
【００２７】
好ましい一実施形態によれば、プロセッサによって実行された場合に、複数のデータ・リポジトリーの環境にあるデータへのアクセスを提供する動作を実行するプログラムであって、抽象照会を定義するための複数の論理フィールドを含む、要求側エンティティに対する照会指定と、前記データの物理エンティティにアクセスする方法と前記物理エンティティにアクセスするために前記方法に渡されるべき複数のパラメータとをそれぞれが定義する、論理フィールドごとのアクセス方法であって、少なくとも１つのパラメータが、前記物理エンティティを含むデータ・ソースの位置を指定する位置パラメータであるアクセス方法とを含むプログラムを含むコンピュータ可読媒体が提供される。
【００２８】
前記要求側エンティティは、例えばアプリケーションであってよい。
【００２９】
好ましくは、前記複数のアクセス方法のそれぞれは、前記データの前記それぞれの物理エンティティの特定の物理表現と位置とを定義する。
【００３０】
好ましくは、前記動作は、前記照会指定に従い前記要求側エンティティにより前記抽象照会を発行するステップと、前記抽象照会を、前記特定の物理データ表現に整合する照会に変形するステップと、前記複数の論理フィールドの特定の論理フィールドに対して前記データの前記物理エンティティに対する前記位置により指定されたデータ・リポジトリーにアクセスするステップとを含む。
【００３１】
好ましい一実施形態によれば、プロセッサによって実行された場合に、特定の物理データ表現を有するデータにアクセスする動作を実行するプログラムであって、要求側エンティティにより、前記要求側エンティティの照会指定に従い抽象照会を発行するステップであって、前記照会指定が、前記抽象照会の論理フィールドに関する定義を提供するステップと、前記物理エンティティのそれぞれに対して、少なくとも前記物理エンティティにアクセスするための方法と当該物理エンティティの位置とを定義することにより、前記論理フィールドを前記データの物理エンティティにマッピングするアクセス方法に従い、前記抽象照会を、前記データの特定の物理データ表現に整合する照会に変形するステップとを前記動作が含む、プログラムを含むコンピュータ可読媒体が提供される。
【００３２】
好ましい一実施形態により、少なくとも（ｉ）複数の論理フィールドを含む抽象照会に関する定義を提供する照会指定を含む要求側エンティティと、（ｉｉ）前記論理フィールドをデータの物理エンティティにマッピングするマッピング規則を含むデータ・リポジトリー抽象化コンポーネントであって、前記マッピング規則が、前記抽象照会の前記論理フィールドの少なくとも一部のそれぞれに対する位置指定を含み、前記位置指定のそれぞれが、アクセスされるべき物理エンティティを含むデータ・ソースの位置を指定する、データ・リポジトリー抽象化コンポーネントと、（ｉｉｉ）前記抽象照会を、前記マッピング規則に従い、データの前記物理エンティティに整合する照会に変形するためのランタイム・コンポーネントとを含むメモリと、前記メモリの内容を実行するよう構成されたプロセッサとを含むコンピュータが提供される。
【００３３】
好ましくは、前記それぞれの位置指定により指定された前記データ・ソースの第１の部分はローカルであり、第２の部分は遠隔である。
【００３４】
次に、本発明の好ましい実施形態を、以下の図面を参照して、一例としてのみ説明する。
【発明を実施するための最良の形態】
【００３５】
序
本発明は、一般に、データが物理的に表される特定の方法と関係なく、データにアクセスするためのシステム、方法、および製品を対象とする。データは、複数の異なるデータ・ソースを含むことができる。
【００３６】
一実施形態では、データ・リポジトリー抽象化層は、データ表現の特定の方法とは無関係の、１つまたは複数の基礎データ・リポジトリーの論理図を提供する。複数のデータ・ソースが提供される場合、データ・リポジトリー抽象化層のインスタンスは、アクセスされるべきデータの位置を示す位置指定により構成される。照会抽象化層も提供されるが、これはデータ・リポジトリー抽象化層に基づいている。ランタイム・コンポーネントは、（照会抽象化層に従い構成された）抽象照会の、特定の物理データ表現に対して使用することのできる形式への翻訳を実行する。
【００３７】
本発明の一実施形態は、例えば図１に示し、後述するコンピュータ・システム１００のような、コンピュータ・システムと共に使用するためのプログラム製品として実施される。プログラム製品の１つ以上のプログラムは、実施形態の機能（本明細書に記載の方法を含めて）を定義し、様々な信号支持媒体に含めることができる。例示の信号支持媒体は、限定はしないが、（ｉ）非書き込み可能な記憶媒体に永続的に記憶された情報（例えば、ＣＤ−ＲＯＭドライブによるＣＤ−ＲＯＭディスク可読のような、コンピュータ内の読み取り専用装置）と、（ｉｉ）書き込み可能な記憶媒体に記憶された変更可能な情報（例えば、ディスケット・ドライブまたはハードディスク・ドライブ内のフロッピー（Ｒ）・ディスク）、または（ｉｉｉ）コンピュータまたは電話網を介するなど、無線通信を含めた通信媒体によりコンピュータに伝達される情報を含む。後者の実施形態は、インターネットおよび他のネットワークからダウンロードした情報を含む。
【００３８】
一般に、本発明の実施形態を実施するために実行されるルーチンは、オペレーティング・システムまたは特定のアプリケーション、コンポーネント、プログラム、モジュール、オブジェクト、または命令シーケンスの一部であってよい。好ましい実施形態のソフトウェアは、一般に、ネイティブ・コンピュータによりマシン可読形式に翻訳され、したがって実行可能な命令である、多数の命令から構成される。また、プログラムは、当該プログラムにローカルに常駐するか、メモリまたは記憶装置にある変数およびデータ構造から構成される。しかし、便宜的にのみ後続のいかなる特定のノーメンクレチャーでも使用され、したがって本発明は、そのようなノーメンクレチャーにより特定されるかまたは暗示され、あるいはその両方が行われるいかなる特定のアプリケーションにおいても単独で使用することに限定されるべきでないことを理解されたい。
【００３９】
環境の物理図
図１は、本発明の実施形態を実施することのできる、ネットワーク接続されたシステム１００のブロック図を示す。一般に、ネットワーク接続されたシステム１００は、クライアント（例えば、ユーザの）・コンピュータ１０２（このようなクライアント・コンピュータ１０２を３つ示す）と、少なくとも１つのサーバ１０４（このような１つのサーバ１０４）を含む。クライアント・コンピュータ１０２およびサーバ・コンピュータ１０４は、ネットワーク１２６を介して接続される。一般に、ネットワーク１２６は、ローカル・エリア・ネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）あるいはその両方であってよい。特定の実施形態では、ネットワーク１２６はインターネットである。
【００４０】
クライアント・コンピュータ１０２は、バス１２６を介してメモリ１１２、ストレージ１１４、入力装置１１６、出力装置１１９、およびネットワーク・インターフェース装置１１８に接続された中央処理装置（ＣＰＵ）１１０を含む。入力装置１１６は、クライアント・コンピュータ１０２に入力を提供するいかなる装置であってもよい。例えば、キーボード、キーパッド、ライトペン、タッチスクリーン、トラックボール、または音声認識装置、オーディオ／ビデオ・プレーヤなどを使用することができる。出力装置１１９は、例えばいかなる従来型表示画面など、ユーザに出力を提供するいかなる装置であってもよい。入力装置１１６と別個に示したが、出力装置１１９および入力装置１１６を組み合わせることができる。例えば、タッチスクリーン内蔵表示画面、キーボード内蔵ディスプレイ、またはテキスト・スピーチ・コンバータと組み合わせた音声認識装置を使用することができる。
【００４１】
ネットワーク・インターフェース装置１１８は、ネットワーク１２６を介してクライアント・コンピュータ１０２とサーバ・コンピュータ１０４の間のネットワーク通信を可能にするよう構成された、いかなるエントリ／エグジット装置であってもよい。例えば、ネットワーク・インターフェース１１８は、ネットワーク・アダプタまたは他のネットワーク・インターフェース・カード（ＮＩＦ）であってよい。
【００４２】
ストレージ１１４は、直接アクセス記憶装置（ＤＡＳＤ）であることが好ましい。ストレージは、単一の装置として示しているが、固定ディスク・ドライブ、フロッピー（Ｒ）・ディスク・ドライブ、テープ・ドライブ、取り外し可能なメモリ・カード、または光ストレージのような、固定した、または取り外し可能な、あるいはその両方の記憶装置の組合せであってよい。メモリ１１２およびストレージ１１４は、複数の１次および２次記憶装置にまたがる１つの仮想アドレス空間の一部であってよい。
【００４３】
メモリ１１２は、本発明の好ましい実施形態のプログラミングおよびデータ構造を保持するには十分大きなランダム・アクセス・メモリであることが好ましい。メモリ１１２は、単一のエンティティとして示されているが、実際には複数のモジュールを含むことができ、高速レジスタおよびキャッシュから低速だがより大きなＤＲＡＭチップまで複数のレベルで存在することができるということを理解されたい。
【００４４】
一例として、メモリ１１２はオペレーティング・システム１２４を含む。便宜上使用することのできる例示のオペレーティング・システムは、LinuxおよびMicrosoft製Windows（Ｒ）を含む。さらに一般的には、本明細書で開示した機能をサポートするいかなるオペレーティング・システムでも使用することができる。
【００４５】
メモリ１１２はまた、ＣＰＵ１１０で実行された場合に、様々なサーバ１０４間をナビゲートし、１つまたは複数のサーバ１０４でネットワーク・アドレスを見つけることをサポートする、ブラウザ・プログラム１２２を含むようにも示される。一実施形態では、ブラウザ・プログラム１２２は、ユーザがハイパーテキスト・マークアップ言語（ＨＴＭＬ）情報を表示することを可能にする、ウェブベースのグラフィカル・ユーザ・インターフェース（ＧＵＩ）を含む。しかし、さらに一般的には、ブラウザ・プログラム１２２は、サーバ・コンピュータ１０４から送信された情報をレンダリングすることのできる、いかなるＧＵＩベースのプログラムであってもよい。
【００４６】
サーバ・コンピュータ１０４は、物理的にはクライアント・コンピュータ１０２と同様の方法で構成される。したがって、サーバ・コンピュータ１０４は、バス１３６により相互に結合されるＣＰＵ１３０、メモリ１３２、および記憶装置１３４を全体的に含むように示される。メモリ１３２は、サーバ・コンピュータ１０４に配置された、本発明の好ましい実施形態の、プログラミングおよびデータ構造を保持するには十分に大きなランダム・アクセス・メモリであってよい。
【００４７】
サーバ・コンピュータ１０４は、一般に、メモリ１３２に常駐するように示されたオペレーティング・システム１３８の制御下にある。オペレーティング・システム１３８の例は、ＩＢＭ（Ｒ）ＯＳ／４００（Ｒ）、ＵＮＩＸ（Ｒ）、Microsoft（Ｒ）Windows（Ｒ）などを含む。さらに一般的には、本明細書に記載の機能をサポートすることのできるいかなるオペレーティング・システムでも使用することができる。（ＩＢＭおよびＯＳ／４００は、米国または他の国の、あるいはその両方のInternationalBusiness Machines社の商標である。ＵＮＩＸ（Ｒ）は、米国および他の国のOpenGroupの登録商標である。MicrosoftおよびWindows（Ｒ）は、米国または他の国の、あるいはその両方のMicrosoft社の商標である。）
【００４８】
メモリ１３２は、１つまたは複数のアプリケーション１４０および抽象照会インターフェース１４６をさらに含む。アプリケーション１４０および抽象照会インターフェース１４６は、コンピュータ・システム１００の様々なメモリおよび記憶装置に様々な時点で常駐する複数の命令を含む、ソフトウェア製品である。サーバ１０４の１つまたは複数のプロセッサ１３０により読み取られ、実行された場合、アプリケーション１４０および抽象照会インターフェース１４６は、コンピュータ・システム１００に、本発明の好ましい実施形態の様々な態様を実施するステップまたは要素を実行するために必須のステップを実行させる。アプリケーション１４０（さらに一般的には、オペレーティング・システム１３８と、さらに高度なレベルではユーザを含めて、任意の要求側エンティティ）は、データベースに対して照会を発行する。例えば、発行することのできる照会は、１つ以上のデータベース１５６〜１５７と総称する、ローカル・データベース１５６１．．．１５６Ｎおよび遠隔データベース１５７１．．．１５７Ｎを含む。一例として、データベース１５６は、ストレージ１３４のデータベース管理システム（ＤＢＭＳ）１５４の一部として示される。さらに一般的には、本明細書で使用するように、「データベース」という用語は、特定の物理的表現にかかわらず、データのいかなる集合体をも表す。一例として、データベース１５６〜１５７は、（ＳＱＬ照会によりアクセス可能な）リレーショナル・スキーマに従い、または（ＸＭＬ照会によりアクセス可能な）ＸＭＬスキーマに従い構成することができる。しかし、本発明は、特定のスキーマに限定されず、現在知られていないスキーマへの拡張も考慮する。本明細書で使用するように、「スキーマ」という用語は、一般に、データの特定の構成を意味する。
【００４９】
一実施形態では、アプリケーション１４０により発行された照会は、各アプリケーション１４０と共に含まれるアプリケーション照会指定１４２に従って定義される。アプリケーション１４０により発行された照会は、事前定義されていても（すなわち、アプリケーション１４０の一部としてハードコードされて（hard code）いても）、入力（例えば、ユーザ入力）に応じて生成されてもよい。いずれにせよ、照会（本明細書では「抽象照会」と称する）は、抽象照会インターフェース１４６により定義された論理フィールドを使用して構成される。具体的には、抽象照会に使用される論理フィールドは、抽象照会インターフェース１４６のデータ・リポジトリー抽象化コンポーネント１４８により定義される。抽象照会は、抽象照会を、データベース１５６〜１５７の１つまたは複数に含まれるデータの物理表現に整合する形式に変形するランタイム・コンポーネント１５０により実行される。アプリケーション照会指定１４２および抽象照会インターフェース１４６を、図２〜３を参照してさらに説明する。
【００５０】
一実施形態では、照会の要素は、グラフィカル・ユーザ・インターフェース（ＧＵＩ）を介してユーザにより指定される。ＧＵＩの内容は、１つ以上のアプリケーション１４０により生成される。特定の実施形態では、ＧＵＩの内容は、ブラウザ・プログラム１２２によりクライアント・コンピュータ・システム１０２でレンダリングすることのできる、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）の内容である。したがって、メモリ１３２は、クライアント・コンピュータ１０２からの要求に応えるよう構成された、ハイパーテキスト転送プロトコル（ｈｔｔｐ）サーバ・プロセス１３８（例えば、ウェブ・サーバ）を含む。例えば、プロセス１３８は、一例としてサーバ１０４に常駐している１つ以上のデータベース１５６にアクセスすることを求める要求に応答することができる。データベース１５６〜１５７からのデータに対する着信クライアント要求は、アプリケーション１４０を呼び起こす。プロセッサ１３０により実行された場合、アプリケーション１４０は、サーバ・コンピュータ１０４に、１つ以上のデータベース１５６〜１５７にアクセスすることを含めて、本発明の好ましい実施形態の様々な態様を実施するステップまたは要素を実行させる。一実施形態では、アプリケーション１４０は、次にブラウザ・プログラム１２２によりレンダリングされる、ＧＵＩ要素を構築するよう構成された複数のサーブレットを含む。遠隔データベース１５７がアプリケーション１４０を介してアクセスされる場合、データ・リポジトリー抽象化コンポーネント１４８は、取り出されるべきデータを含むデータベースを示す配置指定により構成される。この後者の実施形態を、以下で詳述する。
【００５１】
図１は、ネットワーク接続されたクライアント・コンピュータ１０２およびサーバ・コンピュータ１０４のための、単なる１つのハードウェア／ソフトウェア構成である。本発明の実施形態は、コンピュータ・システムが複雑な、マルチユーザ・コンピューティング装置か、単一ユーザのワークステーションか、または独自の不揮発性ストレージのないネットワーク機器かにかかわらず、いかなる匹敵するハードウェア構成にでも適用することができる。さらに、ＨＴＭＬを含めて特定のマークアップ言語を参照したが、本発明は、特定の言語、標準、またはバージョンに限定するものではないことが理解される。したがって、当業者には、本発明は、他のマークアップ言語ならびに非マークアップ言語に適用可能であり、特定のマークアップ言語の将来における変更ならびに現在知られていない他の言語にも適用可能であることが理解されよう。同様に、図１に示すｈｔｔｐサーバ・プロセス１３８は、単なる例示であり、いかなる知られているプロトコルおよび知られていないプロトコルをサポートするよう構成された他の実施形態でも考慮される。
【００５２】
環境の論理／ランタイムの図
図２〜３は、好ましい実施形態による、本発明の相互関係した複数のコンポーネントを示す。要求側エンティティ（例えば、複数のアプリケーション１４０のうちの１つ）は、要求側エンティティのそれぞれのアプリケーション照会指定１４２により定義される照会２０２を発行する。要求は、データベース１５６〜１５７の基礎物理データ・エンティティを直接参照せずに、抽象（すなわち、論理）フィールドに従って構成されるので、要求側照会２０２は、一般に、本明細書では「抽象照会」と称される。その結果、抽象照会は、使用される特定の基礎データ表現とは無関係であると定義することができる。一実施形態では、アプリケーション照会指定１４２は、データ選択に使用される基準（選択基準２０４）と、選択基準２０４に基づいて戻されるべきフィールドの明示的指定（戻りデータ指定２０６）の両方を含む。
【００５３】
アプリケーション照会指定１４２により指定され、抽象照会２０２を構成するために使用される論理フィールドは、データ・リポジトリー抽象化コンポーネント１４８により定義される。一般に、データ・リポジトリー抽象化コンポーネント１４８は、データ選択のための基準を指定し、照会動作から戻された結果データの形式を指定するために、アプリケーション１４０により発行された照会（例えば、抽象照会２０２）内で使用することのできる、一組の論理フィールドとして情報を公開する。論理フィールドは、データベース１５６〜１５７で使用中の基礎データ表現とは無関係に定義され、これにより、基礎データ表現にゆるやかに結合された照会を形成することが可能になる。
【００５４】
一般に、データ・リポジトリー抽象化コンポーネント１４８は、フィールド指定２０８と総称される、複数のフィールド指定２０８１、２０８２、２０８３、２０８４、および２０８５（一例として５つを示す）を含む。具体的には、フィールド指定は、抽象照会の構成のために使用可能な各論理フィールドに提供される。各フィールド指定は、論理フィールド名２１０１、２０１２、２０１３、２０１４、および２０１５（フィールド名２１０と総称される）および関連付けられたアクセス方法２１２１、２１２２、２１２３、２１２４、および２１２５（アクセス方法２１２と総称される）を含む。アクセス方法は、論理フィールド名を、データベース（例えば、複数のデータベース１５６のうちの１つ）の特定の物理データ表現２１４１、２１４２．．．２１４Ｎに関連付ける（すなわち、マッピングする）。一例として、ＸＭＬデータ表現２１４１とリレーショナル・データ表現２１４２の２つのデータ表現を示す。しかし、物理データ表現２１４Ｎは、知られているデータ表現でも知られていないデータ表現でも、いかなる他のデータ表現でも考慮されることを示す。
【００５５】
サポートされるべき論理フィールドの異なるタイプの数に基づいて、アクセス方法はいくつでも考慮される。一実施形態では、単一フィールド、フィルタリングされたフィールド、および構成されるフィールドのためのアクセス方法が提供される。フィールド指定２０８１、２０８２、および２０８５は、それぞれに単純なフィールド・アクセス方法２１２１、２１２２、および２１２５を例示する。単純なフィールドは、基礎物理データ表現（例えば、所与のデータベース・テーブルおよび欄にマッピングされたフィールド）の特定のエンティティに直接マッピングされる。一例として、図３に示す単純なフィールド・アクセス方法２１２１は、論理フィールド名２１０１（「FirstName」）を、「contact」と命名されたテーブルの欄名「f_name」にマッピングする。フィールド指定２０８３は、フィルタリングされたフィールド・アクセス方法２１２３を例示する。フィルタリングされたフィールドは、関連付けられた物理エンティティを示し、物理データ表現内の項目の特定の部分集合を定義するために使用される規則を提供する。図３に、フィルタリングされたフィールド・アクセス方法２１２３が論理フィールド名２１０３（「AnytownLastName」）を、「contact」と命名されたテーブルの「1_name」と命名された欄の物理エンティティにマッピングし、Anytownという街の個人に対するフィルタを定義する一例が示される。フィルタリングされたフィールドの別の例は、ＺＩＰコードの物理表現にマッピングし、データをNewYork州に定義されたＺＩＰコードだけに限定する、New York ＺＩＰコード・フィールドである。フィールド指定２０８４は、複合フィールド（composedfield）・アクセス方法２１２４を例示する。複合アクセス方法は、アクセス方法定義の一部として提供された式を使用して、１つまたは複数の物理フィールドから論理フィールドを演算する。この方法で、基礎データ表現に存在しない情報を演算することができる。図３に示す例では、複合フィールド・アクセス方法２１２３は、論理フィールド名２１０３「AgeInDecades」を「AgeInYears/10」にマッピングする。別の例は、販売価格フィールドに消費税率を乗じることによる複合消費税フィールドである。
【００５６】
基礎データの任意の所与のデータ・タイプ（例えば、日付、１０進数など）に対する形式は異なり得ることが考慮される。したがって、一実施形態では、フィールド指定２０８は、基礎データの形式を反映するタイプ属性を含む。しかし、別の実施形態では、フィールド指定２０８のデータ形式は、関連付けられた基礎物理データと異なる。この場合、アクセス方法は、要求側エンティティが前提とする適切な形式でデータを戻すことを担当する。すなわち、アクセス方法は、好ましくは、どのデータ形式が前提となっているか（すなわち、論理フィールドに従い）、また基礎物理データの実際の形式を知るべきである。この場合、アクセス方法は、基礎物理データを論理フィールドの形式に変換することができる。
【００５７】
一例として、図２に示すデータ・リポジトリー抽象化コンポーネント１４８のフィールド指定２０８は、リレーショナル・データ表現２１４２で表現されるデータにマッピングされる論理フィールドを表す。しかし、データ・リポジトリー抽象化コンポーネント１４８の他のインスタンスは、論理フィールドを、ＸＭＬのような他の物理データ表現にマッピングする。さらに、一実施形態では、データ・リポジトリー抽象化コンポーネント１４８は、手順データ表現のためのアクセス方法により構成される。このようなデータ・リポジトリー抽象化コンポーネント１４８の一実施形態を、図９を参照して以下で説明する。
【００５８】
図２に示す抽象照会２０２に対応する例示の抽象照会を、以下のテーブル１に示す。一例として、データ・リポジトリー抽象化１４８はＸＭＬを使用して定義される。しかし、便宜的にいかなる他の言語でも使用してよい。
【００５９】
テーブル１  照会の例
001 <?xmlversion="1.0"?>
002 <!--Query stringrepresentation: (FirstName = "Mary" AND LastName = 
003 "McGoon") OR State = "NC"-->
004 <QueryAbstraction>
005  <Selection>
006  <Condition internalID="4">
007  <Conditionfield="FirstName" operator="EQ"value="Mary" 
008 internalID="1"/>
009  <Conditionfield="LastName" operator="EQ"value="McGoon" 
010 internalID="3"relOperator="AND"></Condition>
011  </Condition>
012  <Conditionfield="State" operator="EQ" value="NC" internalID="2" 
013 relOperator="OR"></Condition>
014  </Selection>
015  <Results>
016 <Field name="FirstName"/>
017 <Field name="LastName"/>
018 <Field name="State"/>
019  </Results> 
020 </QueryAbstraction>
【００６０】
一例として、テーブル１に示す抽象照会は、選択基準を含む選択指定（行００５〜０１４）と、結果指定（行０１５〜０１９）を含む。一実施形態では、選択基準は、フィールド名（論理フィールドの場合）、比較演算子（＝、＞、＜など）、および値の式（比較対照フィールド）から構成される。一実施形態では、結果指定は、照会の実行結果として戻されるべき、抽象フィールドのリストである。抽象照会の結果指定は、フィールド名と分類基準（sort criteria）から構成することができる。
【００６１】
テーブル１の抽象照会に対応するデータ・リポジトリー抽象化コンポーネント１４８のインスタンス例を、以下のテーブル２に示す。一例として、データ・リポジトリー抽象化コンポーネント１４８は、ＸＭＬを使用して定義される。しかし、便宜上いかなる他の言語でも使用することができる。
【００６２】
テーブル２  データ・リポジトリー抽象化の例
001 <?xmlversion="1.0"?>
002 <DataRepository>
003  <Categoryname="Demographic">
004  <Field queryable="Yes" name="FirstName"displayable="Yes">
005 <AccessMethod>
006 <Simple columnName="f_name" tableName="contact"></Simple>
007 </AccessMethod>
008 <Type baseType="char"></Type>
009  </Field>
010  <Field queryable="Yes" name="LastName"displayable="Yes">
011 <AccessMethod>
012 <SimplecolumnName="l_name"tableName="contact"></Simple>
013 </AccessMethod>
014 <Type baseType="char"></Type>
015  </Field>
016  <Field queryable="Yes" name="State"displayable="Yes">
017 <AccessMethod>
018 <Simple columnName="state" tableName="contact"></Simple>
019 </AccessMethod>
020 <Type baseType="char"></Type>
021  </Field>
022  </Category>
023</DataRepository>
【００６３】
図４は、ランタイム・コンポーネント１５０の動作の一実施形態を例示する、ランタイム方法３００の例を示す。方法３００は、ランタイム・コンポーネント１５０が抽象照会のインスタンス（図２に示す抽象照会２０２のような）を入力として受信する、ステップ３０２から開始する。ステップ３０４で、ランタイム・コンポーネント１５０は、抽象照会のインスタンスを読み取り、構文解析し、個別の選択基準と所望の結果フィールドを見つける。ステップ３０６で、ランタイム・コンポーネント１５０は、抽象照会に存在する各照会選択基準ステートメントを処理し、それによってConcrete Queryのデータ選択部分を構築するために、ループ（ステップ３０６、３０８、３１０、および３１２を含む）を開始する。一実施形態では、選択基準は、フィールド名（論理フィールドの場合）、比較演算子（＝、＞、＜など）、および値の式（比較対照フィールド）から構成される。ステップ３０８で、ランタイム・コンポーネント１５０は、データ・リポジトリー抽象化１４８のフィールドの定義を検索するために、抽象照会の選択基準からのフィールド名を使用する。上記のように、フィールド定義は、フィールドに関連付けられた物理データにアクセスするために使用される、アクセス方法の定義を含む。この場合、ランタイム・コンポーネント１５０は、処理中の論理フィールドに対するConcreteQuery Contributuionを構築する（ステップ３１０）。本明細書で定義するように、ConcreteQuery Contributionは、現在の論理フィールドに基づいてデータ選択を実行するために使用される、具体的照会（concretequery）の一部である。具体的照会は、ＳＱＬおよびＸＭＬ照会のような言語で表現される照会であり、所与の物理データ・リポジトリーのデータに整合する（例えば、リレーショナル・データベースまたはＸＭＬリポジトリー）。したがって、具体的照会は、図１のデータベース１５６〜１５７によって表される物理データ・リポジトリーからデータを見つけ出し、取り出すために使用される。この場合、現在のフィールドに対して生成されたConcreteQuery ContributionがConcrete Query Statementに追加される。次いで方法３００は、抽象照会の次のフィールド用の処理を開始するためにステップ３０６に戻る。したがって、ステップ３０６で開始されたプロセスは、抽象照会のデータ選択フィールドごとに反復され、それにより、追加の内容は実行されるべき最終照会に与えられる。
【００６４】
具体的照会のデータ選択部分を構築した後、ランタイム・コンポーネント１５０は、照会の実行結果として戻されるべき情報を示す。上記のように、一実施形態では、抽象照会は、本明細書で結果指定と称する、照会の実行結果として戻されるべき抽象フィールドのリストを定義する。抽象照会の結果指定は、フィールド名および分類基準から構成することができる。したがって、方法３００は、結果フィールド定義を、生成中の具体的照会に追加するために、ステップ３１４でループを開始する（ステップ３１４、３１６、３１８、および３２０により定義される）。ステップ３１６で、ランタイム・コンポーネント１５０は、現在の論理結果フィールドに対して戻されるべきデータの物理位置を特定するために、データ・リポジトリー抽象化１４８の（抽象照会の結果指定から）結果フィールド名を検索し、次いでデータ・リポジトリー抽象化１４８から結果フィールド定義（Result Field Definition）を取り出す。ランタイム・コンポーネント１５０は次いで、論理結果フィールドに対して（ステップ３１８で）（戻されるべきデータの物理位置を示す具体的照会の）ConcreteQuery Contributuionを構築する。ステップ３２０で、ConcreteQuery Contributionが次いで、ConcreteQuery Statementに追加される。抽象照会の結果指定のそれぞれの処理が済むと、ステップ３２２で照会が実行される。
【００６５】
ステップ３１０および３１８に従い、論理フィールドに対するConcrete QueryContributionを構築するための方法４００の一実施形態を、図５を参照して説明する。ステップ４０２で、方法４００は、現在の論理フィールドに関連付けられたアクセス方法が単純なアクセス方法か否かを照会する。単純なアクセス方法である場合、物理データ位置情報に基づいてConcreteQuery Contributionが構築され（ステップ４０４）、処理は次いで、上記の方法３００に従い続行する。単純なアクセス方法でない場合、処理はステップ４０６に進み、そこで現在の論理フィールドに関連付けられたアクセス方法がフィルタリングされたアクセス方法か否かが照会される。フィルタリングされたアクセス方法である場合、ある種の物理データ・エンティティに対する物理データ位置情報に基づいて、ConcreteQuery Contributuionが構築される（ステップ４０８）。ステップ４１０で、ConcreteQuery Contributionは、物理データ・エンティティに関連付けられた部分集合データに使用される追加論理（フィルタ選択）により拡張される。処理は次いで、上記の方法３００に従い続行する。
【００６６】
アクセス方法がフィルタリングされないアクセス方法である場合、処理はステップ４０６からステップ４１２に進み、そこで方法４００は、アクセス方法が複合アクセス方法か否かを照会する。アクセス方法が複合アクセス方法である場合、ステップ４１４で、複合フィールドの式のサブフィールド参照ごとの物理データ位置が見つけ出され、取り出される。ステップ４１６で、複合フィールドの式の物理フィールド位置情報が、複合フィールドの式の論理フィールド参照に代入され、これにより、Concrete Query Contributionが生成される。処理は次いで、上記の方法３００に従い続行する。
【００６７】
アクセス方法が複合アクセス方法でない場合、処理はステップ４１２からステップ４１８に進む。ステップ４１８は、本発明の実施形態と考えられる、いかなる他のアクセス方法のタイプでも表す。しかし、実施形態ではすべての使用可能なアクセス方法が実施されるわけでないと想定することを理解されたい。例えば、特定の実施形態では、単純なアクセス方法しか使用されない。別の実施形態では、単純なアクセス方法およびフィルタリングされたアクセス方法しか使用されない。
【００６８】
上記のように、論理フィールドが、基礎物理データと異なるデータ形式を指定する場合、データ変換を実行する必要がある場合がある。一実施形態では、方法４００に従い論理フィールドに対してConcrete Query Contributionを構築する際に、それぞれのアクセス方法ごとに初期変換が実行される。例えば、この変換は、ステップ４０４、４０８、および４１６の一部として、または直後に続けて実行することができる。物理データの形式から論理フィールドの形式へのその後の変換は、ステップ３２２で照会後に実行される。当然ながら、論理フィールド定義の形式が基礎物理データと同じ場合、変換は必要ない。
【００６９】
データ・リポジトリー抽象化コンポーネントの他の実施形態
一実施形態では、異なる単一のデータ・リポジトリー抽象化コンポーネント１４８が、別個の物理データ表現２１４のそれぞれに提供される（図３に示すように）。代替形態では、単一のデータ・リポジトリー抽象化コンポーネント１４８は、（関連付けられたアクセス方法による）複数の物理データ表現２１４に対するフィールド指定を含む。さらに別の代替形態では、複数のデータ・リポジトリー抽象化コンポーネント１４８が提供される。この場合、各データ・リポジトリー抽象化コンポーネント１４８は、同じ基礎物理データの異なる部分（１つまたは複数の物理データ表現２１４を含むことのできる）を公開する。この方法で、複数のユーザが同じ基礎データにアクセスするために、単一アプリケーション１４０を同時に使用することができる。この場合、アプリケーションに公開された基礎データの特定部分は、それぞれのデータ・リポジトリー抽象化コンポーネント１４８により決定される。この後者の実施形態は、International Business Machines社に譲渡された「DYNAMIC END USERSPECIFICCUSTOMIZATION OF AN APPLICATION'S PHYSICAL DATA LAYER THROUGH A DATAREPOSITORYABSTRACTION LAYER」という名称の、同時係属の米国特許出願（整理番号ＲＯＣ９２００２００８８）に記載されている。
【００７０】
いずれにせよ、データ・リポジトリー抽象化コンポーネント１４８は、論理フィールドを物理データにマッピングする、少なくとも１つのアクセス方法を含む（または、これを参照する）。この目的のために、上記の実施形態で例示したように、アクセス方法は、論理フィールドに対応するデータの物理表現を見つけ出し、操作する手段を記載する。
【００７１】
一実施形態では、データ・リポジトリー抽象化コンポーネント１４８は、ネットワーク環境にローカルであるか、ネットワーク環境全体に分散されているか、あるいはこの両方であってよい、多数のデータ・ソースの記述を含むよう拡張される。データ・ソースは、多数の異なるデータ表現およびデータ・アクセス技術を使用することができる。一実施形態では、これは、データにアクセスするために使用される方法に加えて、論理フィールドに関連付けられたデータの位置を定義する位置指定でデータ・リポジトリー抽象化コンポーネント１４８のアクセス方法を構成することにより達成される。
【００７２】
次に図６を参照すると、複数のデータ・ソース（リポジトリー）５０２を有する環境５００の論理／ランタイムの図面が示されているが、これは、このような環境におけるデータ・リポジトリー抽象化コンポーネント１４８の動作の一実施形態を例示する。データ・リポジトリー抽象化コンポーネント１４８を介してアクセスされるべきデータ・ソース５０２は、ローカルであっても、遠隔であっても、またはその両方であってもよい。一実施形態では、データ・ソース５０２は、図１に示すデータベース１５６〜１５７を表す。一般に、データ・リポジトリー抽象化コンポーネント１４８は、上記の実施形態と同様に構成される。したがって、データ・リポジトリー抽象化コンポーネント１４８は、論理フィールド定義と、論理フィールド定義ごとの関連付けられたアクセス方法とを有する。しかし、単一データ・ソースだけがアクセスされる他の実施形態とは対照的に、このアクセス方法は、物理表現指定に加えて位置指定により構成される。位置指定は、アクセスされるべきデータ(すなわち、論理フィールド定義に関連付けられたデータ)が見つかる位置（すなわち、データ・ソース）を表す。しかし、一実施形態では、ある種のアクセス方法は、ローカル・データ・ソースをディフォルトに示して、位置指定なしに構成することができることを意図する。
【００７３】
一般に、図６は、アプリケーション１４０、抽象照会指定１４２（本明細書ではアプリケーション照会指定とも称する）、データ・リポジトリー抽象化コンポーネント１４８（論理フィールドをアクセス方法にマッピングするために使用される）、および抽象照会を、照会中の物理情報を含むデータ・リポジトリー５０２がサポートする１つまたは複数のデータ・アクセス要求に変換する役割を担うランタイム・コンポーネント１５０を示す。上記のいくつかの実施形態とは対照的に、図６のデータ・リポジトリー抽象化コンポーネント１４８およびランタイム・コンポーネント１５０は、複数のローカルまたは遠隔、あるいはその両方の物理データ・リポジトリー５０２（本明細書ではローカル／遠隔のデータ・ソース５０２とも称する）全体に分散することができ、多数の照会ベース、また手順ベースのインターフェースを介してアクセスすることのできる、関連付けられたデータを有する、論理フィールドの定義および照会をサポートするよう構成される。
【００７４】
この目的のために、アプリケーション１４０は、関与する実際のデータの物理位置または表現ではなく、論理フィールドに基づく照会選択または更新、あるいはその両方の論理を含む、抽象照会指定１４２に関するデータ要件を定義する。データ・リポジトリー抽象化コンポーネント１４８は、論理フィールド定義５０４と、論理フィールドごとのアクセス方法５０６を含む。論理フィールド定義５０４は、アプリケーション１４０が使用するために使用可能な論理フィールドを記述する。一態様では、データ・リポジトリー抽象化コンポーネント１４８は、アプリケーション１４０が使用するために使用可能な情報を管理する。新しい論理フィールドの追加は、新しいローカルまたは遠隔のデータ・ソースに示され、これにより、アプリケーションが使用するために使用可能となる。アクセス方法５０６のそれぞれは、ローカル／遠隔データ・ソース５０２における論理フィールドとその物理表現の間のマッピングを定義する。この関係は、図７を参照すれば理解することができる。
【００７５】
図７は、（論理フィールド６０４と総称される）複数の論理フィールド６０４１．．．６０４Ｎを含む、例示の抽象照会６０２を示す。論理フィールド６０４のそれぞれは、特定のデータ・リポジトリー抽象化コンポーネント１４８の定義により、（アクセス方法６０８と総称される）アクセス方法６０８１．．．６０８Ｎに関する。アクセス方法６０８の物理表現情報は、使用されるべきアクセス方法の名称（本明細書では、「Ｆ１用アクセス方法」、「Ｆ２用アクセス方法」などと表す）、および命名されたアクセス方法に渡されるべき、論理フィールドに関連付けられた物理データにアクセスする方法を記述する複数のパラメータを含む。一般に、このようなパラメータは、（ロケーター・パラメータ６１０と総称され、本明細書では位置指定とも称される）ロケーター・パラメータ６１０１．．．６１０Ｎと、データにアクセスするために必要とされる他のアクセス・パラメータを含む。所与のデータ・リポジトリー抽象化コンポーネント・インスタンスは、複数のローカルおよび遠隔物理データ・リポジトリーが管理する情報を表すことができる。
【００７６】
データ・リポジトリー抽象化コンポーネント・インスタンスを、位置指定およびデータにアクセスするために必要となる他のアクセス・パラメータにより構成することのできる、例示の実施形態を、図８〜９に示す。まず図８を参照すると、リレーショナル・アクセス方法により構成されるデータ・リポジトリー抽象化コンポーネントのフィールド指定７００が示される。フィールド指定７００は、フィールド名（Field Name７０２）「CreditRatingDescription」により示され、関連付けられたアクセス方法を有する、特定の論理フィールドに特有である。関連付けられたアクセス方法名（AccessMethod７０４）は「Simple−Remote」である。これは、アクセス方法が、論理フィールドが基礎物理データ表現の特定エンティティに直接マッピングされる、単純なフィールド・アクセス方法であること、およびデータが遠隔に配置されることを示す。この場合、論理フィールドは、所与のデータベース・テーブル「credit_t」および欄「desc」にマッピングされる。「ＵＲＬ」は、物理データの位置を指定する、位置指定（ロケーター・パラメータ）である。この場合、「ＵＲＬ」は、使用するＪＤＢＣドライバーの識別子、データを保持する遠隔システム名（remotesystem.abc.com）、およびデータを含むデータベース・スキーマ（creditschema）を含む。「ＪＤＢＣDriver」は、このタイプの遠隔データベースへのＳＱＬアクセスを実施するJava（Ｒ）クラスの名称である。
【００７７】
次に図９を参照すると、手順アクセス方法により構成されたデータ・リポジトリー抽象化コンポーネントのフィールド指定８００が示されている。フィールド指定８００は、フィールド名（Field Name８０２）「CreditRating」により示され、関連付けられたアクセス方法を有する、特定の論理フィールドに特有である。関連付けられたアクセス方法名（AccessMethod８０４）は、アクセス方法が手順アクセス方法であることを示す「Procedural」である。「Service Spec」は、アクセスすべきウェブ・サービスに関するウェブ・サービス記述言語（ＷＳＤＬ）の定義を示す。ＷＳＤＬは、ウェブ・サービス用の標準インターフェース定義言語である。ウェブ・サービスは、通信のための確立されたウェブ・インフラストラクチャを使用し、呼び出しアプリケーションと呼び出されるべきウェブ・サービスの間を渡される情報を表すために、ＸＭＬのような標準データ表現技術を使用して、ソフトウェア・アプリケーションを呼び出すために使用される標準的な方法である。「ServiceName」は、「Service Spec」内で定義される、可能なサービスのセットからアクセスされるべきウェブ・サービスの名称を示す。「Port Name」は、「ServiceName」内で定義される可能なポート名のセットからアクセスされるべき、サービスに対するポート名を示す。命名されたポートは、サービスに対するネットワーク・アドレスを定義する。「Operation」は、呼び出すべき動作の名称である。ウェブ・サービスは、「Operation」と称される１つ以上の機能をサポートすることができる。「Input」は、ウェブ・サービスを呼び出す際に要求される入力を示す。この場合、最後の名称値が、サービスに対する入力として提供される。「Output」は、この論理フィールドに関連付けられた出力データ項目を示す。サービスは、呼び出された際にいくつかの出力を戻すことができる。したがって、「Output」識別は、現在の論理フィールドに関連付けられた複数の出力データを定義する。
【００７８】
手順アクセス方法の場合に、ローカル・データに対するデータ・リポジトリー抽象化コンポーネントのフィールド指定は、遠隔データにアクセスするための、図９に示すフィールド指定８００と事実上同一に見えることに留意されたい。唯一の違いは、ローカルの場合には、参照されたＷＳＤＬ文書が、サービスを実行中のローカル・サーバを指し示すＵＲＬを有することである。
【００７９】
再び図６を参照して、ランタイム・コンポーネント１５０の動作の一実施形態を次に説明する。一般に、ランタイム・コンポーネントは、抽象照会に基づいて実行可能な照会を構築し、実行する役割を担う。この目的のために、ブロック５１０で、ランタイム・コンポーネント１５０は、１つまたは複数の論理フィールドへの参照を、それらの対応する物理位置およびアクセス方法（本明細書ではアクセス方法５０６と総称される）にマッピングするために、抽象照会を構文解析し、データ・リポジトリー抽象化コンポーネント１４８を使用する。一実施形態では、ランタイム・コンポーネント１５０は、物理データ照会要件全体を、同じアクセス方法を使用して同じ物理資源にアクセスすることを表すグループ（「サブグループ」５１４と称される）に分割する（ブロック５１２）。次いで「副照会」が実行される（ブロック５１６）。副照会５１４のそれぞれの結果は、全体的な照会結果５２０がアプリケーション１４０に戻される前に、組み合わされ、正規化される（ブロック５１８）。一態様では、この照会分割方式により、複数のＣＰＵハードウェア・アーキテクチャを利用して、ランタイム・コンポーネント１５０が複数の副照会を並列に実行することが可能になる。
【００８０】
一実施形態では、ランタイム・コンポーネント１５０はまた、ローカル・データ・キャッシュ５２２も管理する。ローカル・データ・キャッシュ５２２は、特定の論理フィールドに対して取り出されたデータを含み、データ・リポジトリー抽象化コンポーネントでイネーブルされたキャッシュとして示された論理フィールドの参照のための、第１の選択として後続の照会中に使用される。キャッシュ方式で有利に管理される論理フィールドは、その値が比較的静的か、またはアクセスするために大きなオーバーヘッドを受けるか、あるいはその両方の論理フィールドである（ある種の情報がペイ・パー・ユーズ・モデルで管理されるとすると、オーバーヘッドが、データをフェッチするために必要な時間またはデータにアクセスするための費用で測定される場合）。
【００８１】
様々な実施形態では、従来技術に勝る多数の利点が、好適に提供される。一態様では、利点は、アプリケーション照会指定と基礎データ表現の間の緩やかな結合を定義することにより好適に達成される。ＳＱＬが使用される場合のように、アプリケーションを特定のテーブル、欄、および関連情報で符号化するのではなく、アプリケーションは、ランタイムの特定の物理データ表現に次に結び付けられるさらに抽象的な方式で、データ照会要件を定義する。緩やかな照会データ結合は、基礎データ表現が修正される場合、または要求側エンティティが、要求側エンティティが開発された際に使用されていたよりも、完全に新しい物理データ表現を使用する場合でさえ、要求側エンティティ（例えば、アプリケーション）が機能することを好適に可能にする。所与の物理データ表現が修正または再構成される場合、対応するデータ・リポジトリー抽象化が、基礎物理データ・モデルに成された変更を反映するために、好適に更新される。論理フィールドの同じセットは、照会が使用するために使用可能であり、物理データ・モデルの異なるエンティティまたは位置に単に結び付けられているだけである。その結果、抽象照会インターフェースに書き込まれた要求側エンティティは、対応する物理データ・モデルが大きな変更を受けた場合でさえ、変更せずに機能を続ける。要求側エンティティが、要求側エンティティが開発された際に使用されていたよりも、完全に新しい物理データ表現を使用する場合、新しい物理データ・モデルは、同じ技術（例えば、リレーショナル・データベース）を使用するが、命名および構成情報（例えば、異なるスキーマ）のための異なる戦略に従って実施することができる。新しいスキーマは、単純な、フィルタリングされ、組み立てられたフィールド・アクセス方法技術を使用して、アプリケーションが要求する論理フィールドのセットにマッピングすることのできる情報を含むことになる。あるいは、新しい物理表現は、同様の情報を表現するための代わりの技術（例えば、ＸＭＬベースのデータ・リポジトリー対リレーショナル・データベース・システムの使用）を使用することができる。いずれにせよ、抽象照会インターフェースを使用するために書き込まれた既存の要求側エンティティは、照会で参照されるフィールドを新しい物理データ・モデルの位置および物理表現でマッピングする、代わりのデータ・リポジトリー抽象化を提供することにより、新しい物理データ表現を使用するために容易にマイグレーションすることができる。
【００８２】
別の態様では、アプリケーション・ビルダーおよびエンド・ユーザの簡易使用が容易になる。基礎データ・リポジトリーで論理フィールドを表すための抽象化層の使用により、アプリケーション開発者は、基礎データ表現の詳細を考慮せずに、キー・アプリケーションのデータ要件に焦点を絞ることができる。したがって、アプリケーション開発中に、生産性は向上し、エラーは低減される。エンド・ユーザに関して、データ・リポジトリー抽象化は、関連データを公開し、所与の照会を開発中の特定クラスのエンド・ユーザには必要ない不要不急の内容を隠して、データ・フィルタリング機構を好適に提供する。
【００８３】
さらに、複数のデータ・ソースの存在を有利に使用することができる。データ・ソースがローカルであっても遠隔であっても、位置指定によりデータ・リポジトリー抽象化コンポーネントを構成することにより、複数のデータ・ソースに好適にアクセスすることができる。この方法で、現在普及している分散された環境を利用することのできる、インフラストラクチャが提供される。
【００８４】
このモデルを実施する解決策は、関与するデータの位置または表現に関係なく、その情報要件を記述するために、提供された抽象照会指定を使用する。照会は、照会で表現された情報の各論理部分にアクセスするために使用される位置および方法を決定するために、データ・リポジトリー抽象化コンポーネントを使用する、ランタイム・コンポーネントに提供される。一実施形態では、ランタイム・コンポーネントは、データ・キャッシュにアクセスするための上記のデータ・キャッシング機能も含む。
【００８５】
このモデルは、解決策を複数の異なるデータ・トポロジーに容易に配置することを可能にし、時間を経てデータが再配置または再構成される場合に解決策が機能することを可能にして、解決策が使用するデータの物理位置または表現とは無関係に、解決策の開発を好適に可能にする。この方式はまた、追加情報を利用するために解決策を拡張するタスクを簡略化する。拡張は抽象照会レベルで行われ、アクセス中の新しいデータの位置または表現に対する唯一のソフトウェアの追加は要求しない。この方法は、データにアクセスするために使用される特定の方法、および参照されるデータの各項目の位置とは無関係の、ソフトウェア・アプリケーションに対する共通データ・アクセス方法を好適に提供する。抽象照会を介してアクセスされる物理データは、関連付けて（既存のリレーショナル・データベース・システムで）、または階層形式で（ＸＭＬのように）、またはある種の他の物理データ表現モデルで表現することができる。ＳＱＬおよびXQueryのような既存のデータ照会方法、Web Service呼び出し（例えば、ＳＯＡＰを使用して）またはＨＴＴＰ要求によるデータの取り出しのような、情報への方針に基づいたアクセスを伴う方法に基づく方法を含めて、多数のデータ・アクセス方法もサポートされる。
【００８６】
特定値、定義、プログラミング言語、および例に対する本明細書のいかなる参照でも、例示を目的としたものに過ぎないことに留意されたい。したがって、本発明は、いかなる特定の例示および実施例によっても限定されるものではない。さらに、本発明の態様はＳＥＬＥＣＴＩＯＮ動作を参照して説明されるが、ＡＤＤ、ＭＯＤＩＦＹ、ＩＮＳＥＲＴ、ＤＥＬＥＴＥなどのような良く知られた動作を含めて、他の入出力動作も好適に想定される。当然ながら、特定のアクセス方法は、その特定のアクセス方法を利用するフィールドを使用して定義することのできる抽象照会機能のタイプに制限を課す場合がある。例えば、組み合わされたアクセス方法に関与するフィールドは、ＭＯＤＩＦＹ、ＩＮＳＥＲＴ、およびＤＥＬＥＴＥの実行可能なターゲットではない。
【図面の簡単な説明】
【００８７】
【図１】本発明の好ましい実施形態により例示に利用されるコンピュータ・システムである。
【図２】ソフトウェア・コンポーネントの関連図である。
【図３】リレーショナル・データ・アクセス用の抽象照会およびデータ・リポジトリー抽象化の一実施形態を示す図である。
【図４】本発明の一実施形態による、ランタイム・コンポーネントの動作を示す流れ図である。
【図５】本発明の一実施形態による、ランタイム・コンポーネントの動作を示す流れ図である。
【図６】データの複数のソースがアクセス可能な、ソフトウェア・コンポーネントの関連図である。
【図７】複数の論理フィールドを含む抽象照会６０２を示す図である。
【図８】リレーショナル・アクセス方法により構成されたデータ・リポジトリー抽象化コンポーネントのフィールド指定を示す図である。
【図９】手順アクセス方法により構成されたデータ・リポジトリー抽象化コンポーネントのフィールド指定を示す図である。
【図１】
2005524138.tif 000003
【図２】
2005524138.tif 000004
【図３】
2005524138.tif 000005
【図４】
2005524138.tif 000006
【図５】
2005524138.tif 000007
【図６】
2005524138.tif 000008
【図７】
2005524138.tif 000009
【図８】
2005524138.tif 000010
【図９】
2005524138.tif 000011
【手続補正書】
【提出日】平成16年4月14日(2004.4.14)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
@u少なくとも１つのデータ・リポジトリーが、他の分散されたデータ・リポジトリーのいずれとも異なる物理データ表現を使用する、複数の分散されたデータ・リポジトリーのデータにアクセスする方法において、@t
要求側エンティティの照会指定に従う抽象照会であって、@uアクセスされるべきいかなるデータ・リポジトリーの基礎物理データ表現とも無関係に定義されるように、@t前記照会指定によりその有する複数の論理フィールドに関する定義が提供される前記抽象照会を、前記要求側エンティティから受信するステップと、
@u前記抽象照会を、アクセス方法のタイプに従いグループ化された複数の副照会に分割するステップと、@t
@u各副照会を、特定の副照会に関連付けられたアクセス方法に従い、@t前記データの特定の物理データ表現に整合する照会に変形するステップ@uとを含み、
前記各アクセス方法は、前記データの@t物理エンティティのそれぞれにアクセスする方法および物理エンティティのそれぞれ@uに対する位置指定@tを定義することにより、前記論理フィールドを前記データの前記物理エンティティにマッピングする@uよう動作可能であり、前記位置指定は、データ・リポジトリーを識別し、および前記識別されたリポジトリー内の前記データの前記位置を識別する@t
方法。
【請求項２】
前記アクセス方法のタイプが、ＳＱＬ照会タイプ、ＸＭＬ照会タイプ、および手順要求タイプを含む一群から選択される請求項１に記載の方法。
【請求項３】
前記抽象照会が、少なくとも１つの選択基準および結果指定を含む請求項１@uまたは２@tのいずれかに記載の方法。
【請求項４】
前記複数の論理フィールドの特定の論理フィールドに対する前記データの物理エンティティに対して、前記データの前記物理エンティティがローカル・キャッシュに配置されているか否かを判定するステップと、
配置されていない場合、前記データの前記物理エンティティのためのアクセス方法で、前記位置により指定されたデータ・リポジトリーにアクセスするステップと
をさらに含む請求項１ないし@u３@tのいずれかに記載の方法。
【請求項５】
コンピュータで実行された場合に、請求項１ないし@u４@tのいずれかに記載の方法を実行するよう構成されたプログラム・コード手段を含むコンピュータ・プログラム。
【請求項６】
@u少なくとも１つのデータ・リポジトリーが、他の分散されたデータ・リポジトリーのいずれとも異なる物理データ表現を使用する、複数の分散されたデータ・リポジトリーのデータにアクセスするコンピュータにおいて、@t
@u照会指定と、@t
@u前記照会指定に従う抽象照会であって、アクセスされるべきいかなるデータ・リポジトリーの基礎物理データ表現とも無関係に定義されるように、前記照会指定によりその有する複数の論理フィールドに関する定義が提供される抽象照会を、前記要求側エンティティから受信する手段と、@t
@u前記抽象照会を、アクセス方法のタイプに従いグループ化された複数の副照会に分割するための手段と、@t
@u前記物理エンティティのそれぞれにアクセスする方法を定義することにより、論理フィールドを前記データの物理エンティティにマッピングするアクセス方法と、データ・リポジトリーを識別しおよび当該識別されたリポジトリー内の前記データの前記位置を識別する、前記物理エンティティのそれぞれに対する位置指定とを含むデータ・リポジトリー抽象化コンポーネントと、@t
@u各副照会を、前記特定の副照会に関連付けられた前記アクセス方法に従い、前記データの特定の物理データ表現に整合する照会に変形する、ランタイム・コンポーネントと@t
@uを含むコンピュータ。@t
【国際調査報告】
2005524138.tif 000012
2005524138.tif 000013
2005524138.tif 000014