JP4965088B2 - データ抽象化モデルにおける関係管理 - Google Patents

Description

本発明は、一般に、データ抽象化モデルを管理することに関し、より具体的には、データベースのデータを抽象的に記述するデータ抽象化モデルにおける関係を管理することに関する。

データベースは、電子化された情報の保管・検索システムである。最も一般的な形式のデータベースは、関係データベース、すなわち、多くの異なる方法で再構成し、アクセスできるようにデータを定めた表データベースである。分散データベースは、ネットワーク内の異なる箇所の間で分散又は複製することができるデータベースである。オブジェクト指向プログラミング・データベースは、オブジェクト・クラス及びサブクラスで定義されたデータと一致するデータベースである。

特定のアーキテクチャにかかわらず、ＤＢＭＳは、要求エンティティ（例えば、アプリケーション、オペレーティング・システム、又はエンドユーザー）についての様々な異なるタイプの動作をサポートするように構成することができる。こうした動作は、ＤＢＭＳによって保管され、管理されている情報を検索し、追加し、修正し、削除するように設定することができる。標準的なデータベース・アクセス方法は、構造化照会言語（ＳＱＬ）のような高水準の照会言語を用いて、こうした動作をサポートするものである。「照会」という用語は、保管されたデータベースのデータを処理するための動作を実行させるコマンドの組を指す。例えば、ＳＱＬは、４つのタイプの照会動作、すなわち、ＳＥＬＥＣＴ、ＩＮＳＥＲＴ、ＵＰＤＡＴＥ、及びＤＥＬＥＴＥをサポートする。ＳＥＬＥＣＴ動作はデータベースからデータを検索し、ＩＮＳＥＲＴ動作は新たなデータをデータベースに追加し、ＵＰＤＡＴＥ動作はデータベースのデータを修正し、ＤＥＬＥＴＥ動作はデータベースからデータを除去する。

２００２年２月２６日に出願され、発明の名称を「ＡＰＰＬＩＣＡＴＩＯＮ ＰＯＲＴＡＢＩＬＩＴＹ ＡＮＤ ＥＸＴＥＮＳＩＢＩＬＩＴＹ ＴＨＲＯＵＧＨ ＤＡＴＡＢＡＳＥ ＳＣＨＥＭＡ ＡＮＤ ＱＵＥＲＹ ＡＢＳＴＲＡＣＴＩＯＮ」とする特許文献１（‘０７５出願）において、物理データを抽象的に閲覧するためのフレームワークが開示された。‘０７５出願のフレームワークは、物理データの論理表現を要求エンティティ（すなわち、エンドユーザー又はアプリケーション）に与えるものであった。換言すれば、‘０７５出願のフレームワークは、基礎物理データ構造を論理的に記述するデータ抽象化モデルを要求エンティティに与えるものであった。このようにして、要求エンティティは、アクセスされることになる基礎物理データから分離される。したがって、物理データを変更しても、その物理データにアクセスするアプリケーションを変更する必要はない。さらに、このフレームワークに基づく抽象照会は、物理データの構造を考慮せずに構築することができる。

米国特許出願第１０／０８３，０７５号明細書

‘０７５出願のフレームワークによるデータ抽象化モデルを用いると、抽象照会を、データベース内の物理データに対して実行することが可能な実行可能照会に変換することができる。しかしながら、特定の場合においては、所与の抽象照会が、データ抽象化モデルによって決まる２つ以上の実行可能照会に変換されることがある。例えば、病院内のユーザが、所与の血液検査を受けた患者のうち２００より大きな対応する結果値を有する者の氏名を決定しようとする場合を想定する。この目的のために、ユーザは、以下の抽象照会を指定することができる。
ＦＩＮＤ ＮＡＭＥ
ＷＨＥＲＥ ＲＥＳＵＬＴ＞２００
しかしながら、データ抽象化モデルを扱うときには、ＮＡＭＥという用語は、基礎データベース内の２つ以上の物理パラメータ（例えば、医療環境においては患者又は医師の氏名、製造環境においては従業員又は顧客の氏名、など）を指すことがある。

結果として、さらなる情報がなければ、上記の抽象照会は、（ユーザが意図したように）検査を受けた患者ではなく、特定の結果を有する検査を管理する医師の氏名を戻す実行可能照会に変換されることがある。さらに、対応するデータ抽象化モデルによって、２００より大きな対応する結果値を伴う所与の血液検査を指示した病院の医師の氏名を検索する抽象照会について、別の実行可能照会を生成することも可能になると想定する。しかしながら、両方の実行可能照会に対して戻される結果の組は異なる。換言すれば、抽象照会を、ユーザが期待する照会結果をもたらす実行可能照会に変換するためには、その抽象照会の生成時におけるユーザの意図が考慮されなければならない。

この問題に対応するための１つの手法は、所与の抽象照会について生成することができるすべての実行可能照会を生成し、そこから対応する必要な実行可能照会を選択するようにユーザを促すことを可能にすることである。しかしながら、このことは、全ての実行可能照会が基礎物理データ構造に関して表現されるため、基礎物理データからの分離を損なうことになるであろう。さらに、この手法は、ユーザを混乱させる可能性があり、ユーザが、基礎物理データ構造をより深く理解することが必要な場合がある。

したがって、抽象照会の少なくとも２つの異なる解釈が可能であるときに、該抽象照会を実行可能照会に変換するための効率的な技術についての必要性が存在する。

本発明は、一般に、データ抽象化モデルを管理するための方法、システム、及び製品に向けられ、より具体的には、データベース内のデータを抽象的に記述するデータ抽象化モデルにおける関係を管理するための方法、システム、及び製品に向けられる。

１つの実施形態は、データベース内のデータの論理分岐をリンクする方法を提供する。この方法は、一般に、幾つかが共通名を共有する論理フィールドを含むデータ抽象化モデルの論理分岐間にリンクを持つ構造を構成することを含み、該リンクは、多数の論理フィールドによって共有される共通名に対する参照を含む抽象照会を実行するときに、物理フィールドを含むデータ構造の適切な連結を可能にする。

別の実施形態は、データ抽象化モデルによって論理的に表現された物理データについて問い合わせを行う照会を生成する方法を提供する。この方法は、１つ又は複数の結果フィールドを有する、データベース内の物理データに対する抽象照会を受け取ることを含む。各々の結果フィールドは、データ抽象化モデルの論理フィールド仕様に対応する。次いで、データ抽象化モデルが抽象照会と関連付けられた論理リンクを含むかどうかが判断される。データ抽象化モデルが関連論理リンクを含む場合には、該関連論理リンクが取得され、抽象照会が実行可能照会に変換される。変換は、データ抽象化モデルと、取得した関連論理リンクとを用いて行われる。実行可能照会は、物理データに対して実行することが可能である。

さらに別の実施形態は、データベース内のデータを抽象的に記述するデータ抽象化モデルの論理フィールドをリンクする方法を提供する。各々の論理フィールドは、データの特定のセットの論理表現を定める。本方法は、データ抽象化モデルについて、複数の論理分岐を有する論理ツリー構造を生成することを含む。各々の論理分岐は、１つ又は複数の論理フィールドを含む。次いで、異なる論理分岐間の関係が特定され、論理リンクが生成される。論理リンクは、特定された関係を抽象的に記述し、データ抽象化モデルと関連付けられる。

さらに別の実施形態は、プロセッサによって実行されるとき、データ抽象化モデルによって論理的に表現された物理データについて問い合わせを行う照会を生成するプロセスを実施するプログラムを含むコンピュータ可読媒体を提供する。このプロセスは、データベース内の物理データに対する抽象照会を受け取ることを含む。抽象照会は、各々がデータ抽象化モデルの論理フィールド仕様に対応する１つ又は複数の結果フィールドを有する。次いで、データ抽象化モデルが、抽象照会と関連付けられた論理リンクを含むかどうかが判断される。データ抽象化モデルが関連論理リンクを含む場合には、該関連論理リンクが取得される。次いで、抽象照会は、物理データに対して実行することが可能な実行可能照会に変換される。変換は、データ抽象化モデルと、取得した関連論理リンクとを用いて行われる。

さらに別の実施形態は、プロセッサによって実行されるとき、データ抽象化モデルによって論理的に表現された物理データについて問い合わせを行う照会を生成するプロセスを実施するプログラムを含むコンピュータ可読媒体を提供する。このプロセスは、データ抽象化モデルを表現する論理ツリー構造内をユーザがナビゲートすることを可能にするグラフィカル・ユーザー・インターフェースを表示することを含む。論理ツリー構造は、複数の論理分岐を有する。少なくとも２つの論理分岐が、論理リンクによってリンクされる。各々の論理分岐は、データ抽象化モデルの１つ又は複数の論理フィールドを含む。各々の論理フィールドは、物理データの特定のセットの論理表現を定める。

本発明の上述した特徴、利点、及び目的が達成され、詳細に理解することができるように、上記に簡潔に要約した本発明を、添付図面に示す本発明の実施形態を参照して、より具体的に説明する。
しかしながら、添付図面は、本発明の典型的な実施形態のみを示すものであり、したがって、本発明は他の等しく有効な実施形態を許容するものであり、その範囲を限定するものと考えるべきではない。

本発明の実施形態は、一般に、データの論理分岐を他のデータの論理分岐と関連付ける方法を提供する。その際、表を相互にどのように結合するかに関する情報を、（例えば、そうした情報を得るようにユーザを直接促すことなく）自動的に収集することができる。幾つかの実施形態については、特定された関係に基づいて、関連論理分岐間に論理リンクを生成することができる。次いで、これらの論理リンクを用いて、異なって解釈されることがある論理フィールド名を伴う抽象照会を解釈することができる。換言すれば、論理リンクを用いて、その照会を生成するユーザの意図を自動的に判断することができる。

１つの態様によれば、データ抽象化モデルは、データベース内のデータを抽象的に記述する。データ抽象化モデルは、複数の論理分岐を有する論理ツリー構造で表現することができる。各々の論理分岐は、１つ又は複数の論理フィールドを含む。各々の論理フィールドは、データベースにおけるデータの特定のセットの論理表現を定める。データ抽象化モデルは、各々の論理フィールドに、データの特定のセットの論理表現を定める論理フィールド仕様を与える。

１つの実施形態においては、データベース内のデータの論理分岐はリンクされる。この目的のために、複数の論理分岐を有する対応する論理ツリー構造を定めるデータ抽象化モデルにアクセスする。次いで、複数の論理分岐のうちの異なる論理分岐の論理フィールド間の関係が特定される。１つの態様によれば、対応する論理ツリー構造の図形表現を生成し、グラフィカル・ユーザー・インターフェースを用いてユーザに対して表示することができる。このように、ユーザは、論理フィールド間の関係を特定するために、グラフィカル・ユーザー・インターフェースを介して論理ツリー構造にアクセスすることができる。特定された関係に基づいて、論理リンクが生成される。論理リンクは、特定された関係を抽象的に記述する。生成された論理リンクは、データ抽象化モデルと関連付けられる。

１つの実施形態においては、１つ又は複数のデータベース内のデータに対して抽象照会が生成される。抽象照会についての１つ又は複数の結果フィールドとして、対応するデータ抽象化モデルの複数の論理フィールドから少なくとも１つの論理フィールドが選択される。１つ又は複数の結果フィールドは、グラフィカル・ユーザー・インターフェースを用いて選択することができる。１つの態様によれば、グラフィカル・ユーザー・インターフェースは、ユーザがデータ抽象化モデルを表現する論理ツリー構造内をナビゲートすることが可能になるように構成することができる。論理ツリー構造は、少なくとも２つが論理リンクによってリンクされる複数の論理分岐を有することができる。１つ又は複数の結果フィールドの選択に際して、対応するデータ抽象化モデルが、抽象照会と関連付けられた論理リンクを含むかどうかが判断される。データ抽象化モデルが関連論理リンクを含む場合には、その関連論理リンクが取得される。このように、抽象照会が実行可能照会に変換されるときは、データ抽象化モデルと取得した関連論理リンクとを用いて、変換を行うことができる。実行可能照会は、１つ又は複数のデータベース内のデータに対して実行することができる。１つ又は複数のデータベースに対して実行可能照会を実行すると、各々の結果フィールドについてデータが戻される。

以下では、本発明の実施形態が参照される。しかしながら、本発明は説明された特定の実施形態に限定されないものと理解されるべきである。それどころか、異なる実施形態に関連するか否かにかかわらず、本発明を実装し、実施するために、以下の特徴及び要素のいずれの組み合わせも考えられる。さらに、種々の実施形態において、本発明は、従来技術に勝る多くの利点を提供する。しかしながら、本発明の実施形態は他の可能性ある解決方法及び／又は従来技術に勝る利点を達成することができるが、所与の実施形態によって特定の利点が達成されるか否かは、本発明を限定するものではない。したがって、以下の態様、特徴、実施形態、及び利点は、単なる例示であって、明示されない限り添付の特許請求の範囲の要素又は限定とはみなされない。

本発明の１つの実施形態は、例えば図１に示され、以下に説明されるコンピュータ・システム１１０のようなコンピュータ・システムで用いるためのプログラム製品として実装される。プログラム製品の１つ又は複数のプログラムは、（本明細書で説明される方法を含む）実施形態の機能を定め、様々な信号伝達媒体に収容することができる。例示的な信号伝達媒体は、（ｉ）書き込み不可能なストレージ媒体（例えば、ＣＤ−ＲＯＭドライブによって読み出し可能なＣＤ−ＲＯＭディスクといった、コンピュータ内部の読み取り専用メモリ・デバイス）上に永久的に保管された情報、（ｉｉ）書き込み可能なストレージ媒体（例えば、ディスケット・ドライブ又はハードディスク・ドライブ内部のフロッピー（商標）ディスク）に保管された可変情報、又は（ｉｉｉ）コンピュータ・ネットワーク又は電話ネットワークなどを介して、無線通信を含む通信媒体によってコンピュータに伝達される情報を含むが、これらに限定されるものではない。最後の実施形態は、特に、インターネット及び他のネットワークからダウンロードされる情報を含む。こうした信号伝達媒体は、本発明の機能を指示するコンピュータ可読命令を運ぶときは、本発明の実施形態を表す。

一般に、本発明の実施形態を実施するために実行されるルーチンは、オペレーティング・システム又は特定のアプリケーションの一部、コンポーネント、プログラム、モジュール、オブジェクト、又は命令のシーケンスとすることができる。本発明のソフトウェアは、典型的には、ネイティブ・コンピュータによって、機械読み出し可能なフォーマット、すなわち実行可能な命令に翻訳される多数の命令から構成される。また、プログラムは、プログラムにローカルに常駐するか又はメモリ内若しくはストレージ・デバイス上に見出される変数及びデータ構造から構成される。さらに、以下に説明される種々のプログラムは、本発明の特定の実施形態においてプログラムが実装されるアプリケーションに基づいて、特定することができる。しかしながら、以下の特別な用語のいずれも単に便宜的に用いられるものであることが認識されるべきであり、したがって、本発明は、こうした用語によって特定される及び／又は示唆される特定のアプリケーションのいずれかにのみ使用されるものと限定されるべきではない。

例示的なコンピューティング環境
ここで図１を参照すると、コンピューティング環境１００が示される。一般に、分散環境１００は、コンピュータ・システム１１０と、複数のネットワーク装置１４６とを含む。コンピュータ・システム１１０は、クライアント・コンピュータ、サーバ・コンピュータ、ポータブル・コンピュータ、組み込みコントローラ、ＰＣベースのサーバ、ミニコンピュータ、ミッドレンジ・コンピュータ、メインフレーム・コンピュータ、並びに、本発明の方法、装置、及び製品をサポートするのに適した他のコンピュータを含むいずれかのタイプのコンピュータ、コンピュータ・システム、又は他のプログラム可能な電子装置を表すことができる。１つの実施形態においては、コンピュータ・システム１１０は、ニューヨーク州アーモンク所在のＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓから入手可能なｅＳｅｒｖｅｒコンピュータである。

例として、コンピュータ・システム１１０はネットワーク・システムを構成する。しかしながら、コンピュータ・システム１１０は、独立型の装置とすることもできる。いずれにしても、図１はコンピュータ・システムについての単なる一構成であることが理解される。本発明の実施形態は、コンピュータ・システム１１０が複雑なマルチユーザー装置であるか、シングルユーザー・ワークステーションであるか、又は、専用の不揮発性ストレージを持たないネットワーク機器であるかにかかわらず、同等の構成のいずれにも適用することができる。

本発明の実施形態は、通信ネットワークを通じてリンクされる遠隔処理装置によってタスクが行われる分散コンピューティング環境において実施することもできる。分散コンピューティング環境においては、プログラム・モジュールは、ローカル・メモリ・ストレージ・デバイスと遠隔メモリ・ストレージ・デバイスの両方に配置することができる。この観点から、コンピュータ・システム１１０、及び／又は、１つ又は複数のネットワーク装置１４６は、処理をほとんど又はまったく行わないシン・クライアントとすることができる。

コンピュータ・システム１１０は、例えば、直接アクセス・ストレージ・デバイス１３８に作動状態で接続される大容量ストレージ・インターフェース１３７、ディスプレイ１４２に作動状態で接続されるビデオ・インターフェース１４０、及び複数のネットワーク装置１４６に作動状態で接続されるネットワーク・インターフェース１４４によって示されるような、多数のオペレータ又は周辺システムを含むことができる。ディスプレイ１４２は、可視情報を出力するためのビデオ出力装置のいずれかとすることができる。

コンピュータ・システム１１０は、メイン・メモリ１１６からバス１１４を介して命令及びデータを取得する少なくとも１つのプロセッサ１１２を備えるものとして示される。プロセッサ１１２は、本発明の方法をサポートするのに適したいずれかのプロセッサとすることができる。メイン・メモリ１１６は、必要なプログラム及びデータ構造を保持するのに十分な大きさを持ついずれかのメモリである。メイン・メモリ１１６は、ランダム・アクセス・メモリ、不揮発性メモリ、又はバックアップ・メモリ（例えば、プログラムマブル・メモリ、フラッシュ・メモリ、読み出し専用メモリなど）を含むメモリ・デバイスの１つ、又はそれらの組み合わせとすることができる。さらに、メモリ１１６は、例えば、仮想メモリとして用いられるか、大容量ストレージ・デバイス（例えば直接アクセス・ストレージ・デバイス１３８）上に保管されるか、又は、バス１１４を介してコンピュータ・システム１１０に連結される別のコンピュータ上に保管される、いずれかのストレージ容量といった、コンピュータ・システム１１０の他の場所に物理的に配置されたメモリを含むものと考えることができる。

メモリ１１６は、オペレーティング・システム１１８を伴って構成されるものとして示される。オペレーティング・システム１１８は、コンピュータ・システム１１０の動作を管理するために用いられるソフトウェアである。オペレーティング・システム１１８の例には、ＩＢＭ ＯＳ／４００（商標）、ＵＮＩＸ（商標）、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（商標）、及び同種のものが含まれる。

メモリ１１６は、１つ又は複数のアプリケーション１２０と、抽象化モデル・インターフェース１３０とをさら含む。アプリケーション１２０及び抽象化モデル・インターフェース１３０は、様々な時点でコンピュータ・システム１１０の様々なメモリ及びストレージ・デバイスに常駐する複数の命令を有するソフトウェアである。アプリケーション１２０及び抽象化モデル・インターフェース１３０は、コンピュータ・システム１１０の１つ又は複数のプロセッサ１１２によって読み出されて実行されたときは、本発明の様々な態様を具体化するステップ又は要素を実行するのに必要なステップをコンピュータ・システム１１０に行わせる。アプリケーション１２０（より一般的には、オペレーティング・システム１１８を含むいずれかの要求エンティティ）は、（ストレージ１３８内に示される）データベース１３９に対して照会を発行するように設定される。データベース１３９は、データの特定の物理表現にかかわらず、データのいずれかのセットを代表するものである。データの物理表現は、データの構成スキーマを定める。例として、データベース１３９は、（ＳＱＬ照会によってアクセス可能な）関係スキーマに従って、又は（ＸＭＬ照会によってアクセス可能な）ＸＭＬスキーマに従って、構成することができる。しかしながら、本発明は、特定のスキーマに限定されるものではなく、現在は知られていないスキーマへの拡張も考えられる。ここで用いられるとき、「スキーマ」という用語は、一般に、データの特定の配列を指す。

アプリケーション１２０によって発行される照会は、各々のアプリケーションに含まれるアプリケーション照会仕様１２２に従って定められる。アプリケーション１２０によって発行される照会は、あらかじめ定める（すなわち、アプリケーション１２０の一部としてハードコーディングする）か、又は、入力（例えば、ユーザー入力）に応答して生成することができる。どちらの場合においても、照会（ここでは「抽象照会」と呼ぶ）は、抽象化モデル・インターフェース１３０によって定められた論理フィールドを用いて合成される。論理フィールドは、個々のデータ項目として、又は、例えばデータベース表の形態のデータ構造として、データの抽象ビューを定める。具体的には、抽象照会に用いられる論理フィールドは、抽象化モデル・インターフェース１３０のデータ抽象化モデル・コンポーネント１３２によって定められる。１つの実施形態においては、データ抽象化モデル・コンポーネント１３２は、関係マネージャ１５０によって生成され、管理される論理リンクを含む。論理リンクは、データベース１３９におけるデータの論理分岐間の関係を記述する。データ抽象化モデル・コンポーネント１３２及び関係マネージャ１５０の動作及び対話は、図２及び図３を参照して、以下にさらに説明される。

例として、関係マネージャ１５０は、ランタイム・コンポーネント１３４の一部として示される。ランタイム・コンポーネント１３４は、抽象照会を、データベース１３９に含まれるデータの物理表現と一致する形式を有する具象照会に変換する。具体的には、ランタイム・コンポーネント１３４は、抽象照会を具象照会に変換する際に、データ抽象化モデル・コンポーネント１３２に含まれる論理リンクを用いることができる。具象照会は、ランタイム・コンポーネント１３４がデータベース１３９に対して実行することができる。ランタイム・コンポーネント１３４の動作は、図２を参照して以下にさらに説明される。

例示的な照会実行ランタイム環境
ここで図２を参照すると、照会実行ランタイムにおける、ランタイム・コンポーネント１３４と、アプリケーション１２０と、データ抽象化モデル１３２と、関係マネージャ１５０との対話を説明する関係図が示される。データ抽象化モデル１３２が、データベース（例えばデータベース１３９）内のデータ構造に対応する論理フィールドを定め、それによりデータベース１３９内のデータの抽象ビューすなわち論理ビューを提供することから、データ抽象化モデル１３２は、ここでは「論理表現」とも呼ばれる。データ構造は、データベース表の形式又はデータベース表の列の形式をとった配列のような、データの物理配列である。より具体的には、各々の論理フィールドは、データベース１３９内のデータの特定のセットの論理表現を定める。多数のデータベース表を有する関係データベース環境においては、特定の論理フィールドを有する特定の論理表現を各々のデータベース表に与えることができる。この場合は、全ての特定の論理表現が一体となって、データ抽象化モデル１３２を構成する。データの物理エンティティが、データの物理表現に従ってデータベース１３９内に配列される。データの物理エンティティ（同じ意味で、物理データ・エンティティとも呼ばれる）は、基礎物理表現におけるデータ項目である。したがって、物理データ・エンティティは、データベース表又はデータベース表の列に含まれるデータ、すなわちデータそのものである。例として、２つの物理表現、すなわち、ＸＭＬデータ表現２１４_１及び関係データ表現２１４_２が示される。しかしながら、物理表現２１４_Ｎは、既知であるか未知であるかにかかわらず、他のいずれかの物理表現が考えられることを示す。１つの実施形態においては、関係データベース環境の場合について上述したように、異なる単一のデータ抽象化モデル１３２が、別個の物理表現２１４の各々について与えられる。代替的な実施形態においては、単一のデータ抽象化モデル１３２は、２つ又はそれ以上の物理表現２１４についての（関連アクセス方式を持つ）フィールド仕様を含む。フィールド仕様は、論理フィールドの記述であり、一般に、論理フィールドを特定の物理表現の１つ又は複数のデータ構造にマップするマッピング規則を有する。

データの論理表現を用いて、アプリケーション照会仕様１２２は、１つ又は複数の論理フィールドを指定し、結果として得られる照会２０２を作成する。要求エンティティ（例えばアプリケーション１２０）は、要求エンティティのアプリケーション照会仕様によって定められる通りに、結果として得られる照会２０２を発行する。１つの実施形態においては、抽象照会２０２は、データ選択に用いられる基準と、データ選択基準に基づいて戻されることになる結果フィールドの明示的な仕様との両方を含むことができる。選択基準、及び、抽象照会２０２の結果フィールド仕様の例が、図３に示される。したがって、抽象照会２０２は、例として、選択基準３０４及び結果フィールド仕様３０６を含む。

結果として得られる照会２０２は、データベース１３９内の基礎データ構造を直接参照することによってではなく、抽象（すなわち、論理）フィールドに従って合成されることから、ここでは一般に「抽象照会」と呼ばれる。結果として、抽象照会は、用いられる特定の基礎物理データ表現とは独立に定めることができる。実行するために、抽象照会は、データ抽象化モデル１３２を用いて、データの基礎物理表現と整合する具象照会に変換される。具象照会は、データベース１３９に対して実行可能である。抽象照会を具象照会に変換する例示的な方法は、図５及び図６を参照して以下に説明される。

一般に、データ抽象化モデル１３２は、情報を論理フィールドの組として公開する。１つの態様によれば、データ抽象化モデル１３２は、複数の論理分岐を有する論理ツリー構造として表現することができる。各々の論理分岐は、１つ又は複数の論理フィールドを含むことができる。例としての論理ツリー構造の２つの例示的な論理分岐が図９に示される。１つの実施形態においては、データ選択のための基準と、照会動作から戻される結果データの形式とを指定するために、抽象照会の内部で論理フィールドを用いることができる。論理フィールドは、データベース１３９において用いられている基礎物理表現とは独立に定められ、そのことにより、基礎物理表現に緩やかに結合される抽象照会を形成することが可能になる。

例として、データ抽象化モデル１３２は、論理リンク２０４を含む。論理リンク２０４は、データ抽象化モデル１３２を表現する論理ツリー構造の異なる論理分岐間の関係を抽象的に記述する。２つ以上のデータ抽象化モデルが与えられる場合には、論理リンク２０４は、異なるデータ抽象化モデルの論理分岐間の関係を記述することができる。抽象照会２０２を具象照会に変換する際には、関係マネージャ１５０を用いて、関係を決定するために論理リンク２０４にアクセスすることができる。決定された関係を用いて、データベース１３９におけるデータの物理表現の異なるデータ構造間のパスを、具象照会について特定することができる。例えば、具象照会はＳＱＬ照会であり、データベースの物理表現は関係スキーマであり、データ構造はデータベース表であると仮定する。この例においては、論理リンク２０４に基づいて、ＳＱＬ照会についてＪＯＩＮステートメントを生成し、ＳＱＬ照会の中の対応するデータベース表間のリンクを指定することができる。このリンクは、対応する照会結果を決定するためにＳＱＬ照会に従ってデータベース１３９内のデータを照会するときに利用される。

例示的なデータ抽象化モデル
ここで図３を参照すると、抽象照会２０２とデータ抽象化モデル１３２との対話を説明する関係図が示される。１つの実施形態においては、データ抽象化モデル１３２は、複数のフィールド（ｆｉｅｌｄ）仕様３０８_１、３０８_２、３０８_３、３０８_４、３０８_５、及び３０８_６（一例として、６つが示される）を備え、これらはまとめてフィールド仕様３０８と呼ばれる。具体的には、フィールド仕様は、抽象照会の合成に利用可能な各々の論理フィールドについて与えられる。各々のフィールド仕様は、１つ又は複数の属性を含むことができる。例として、フィールド仕様３０８は、論理フィールド名（ｎａｍｅ）属性３２０_１、３２０_２、３２０_３、３２０_４、３２０_５、及び３２０_６（まとめて、フィールド名３２０）と、関連アクセス方法（ａｃｃｅｓｓ ｍｅｔｈｏｄ）属性３２２_１、３２２_２、３２２_３、３２２_４、３２２_５、及び３２２_６（まとめて、アクセス方法３２２）とを含む。各々の属性は値を持つことができる。例えば、論理フィールド名属性３２０_１は「Ｐａｔｉｅｎｔ ＩＤ」という値を有し、アクセス方法属性３２２_１は「Ｓｉｍｐｌｅ」という値を有する。さらに、各々の属性は、１つ又は複数の関連抽象特性を含むことができる。各々の抽象特性は、データ構造の特徴を記述し、関連値を有する。上述のように、データ構造は、論理フィールドに対応するデータの１つ又は複数の物理エンティティによって定められる基礎物理表現の一部を指す。具体的には、抽象特性は、データベース表（ｔａｂｌｅ）の名前又はデータベース表の列（ｃｏｌｕｍｎ）の名前などのように、データ構造に対応する物理データ・エンティティの位置を抽象的に記述するデータ位置メタデータを表すことになる。例として、アクセス方法属性３２２_１は、データ位置メタデータ「Ｔａｂｌｅ」及び「Ｃｏｌｕｍｎ」を含む。さらに、データ位置メタデータ「Ｔａｂｌｅ」は、値「Ｐａｔｉｅｎｔｉｎｆｏ」を有し、データ位置メタデータ「Ｃｏｌｕｍｎ」は、値「ｐａｔｉｅｎｔ＿ＩＤ」を有する。したがって、本例における基礎関係データベース・スキーマを想定する場合、データ位置メタデータ「Ｔａｂｌｅ」及び「Ｃｏｌｕｍｎ」の値は、列「ｐａｔｉｅｎｔ＿ＩＤ」を有する表「Ｐａｔｉｅｎｔｉｎｆｏ」を指す。

１つの実施形態においては、論理フィールドのグループ（すなわち、２つ又はそれ以上）は、カテゴリー（ｃａｔｅｇｏｒｙ）の一部とすることができる。したがって、データ抽象化モデル１３２は、複数のカテゴリー仕様３１０_１及び３１０_２（一例として、２つが示される）を含み、これらはまとめてカテゴリー仕様と呼ばれる。１つの実施形態においては、２つ又はそれ以上の論理フィールドの論理グループの各々について、カテゴリー仕様が与えられる。例えば、論理フィールド３０８_１〜３０８_３及び３０８_４〜３０８_６は、それぞれ、カテゴリー仕様３１０_１及び３１０_２の一部である。カテゴリー仕様は、ここでは単に「カテゴリー」とも呼ばれる。カテゴリーは、例えばカテゴリー名３３０_１及び３３０_２（まとめて１つ又は複数のカテゴリー名３３０）といったカテゴリー名に従って区別される。本例においては、論理フィールド３０８_１〜３０８_３は「Ｐａｔｉｅｎｔ」カテゴリーの一部であり、論理フィールド３０８_４〜３０８_６は「Ｔｅｓｔｓ」カテゴリーの一部である。

アクセス方法３２２は、一般に、論理フィールド名をデータベース（例えば図１のデータベース１３９）内のデータに関連付ける（すなわち、マップする）。対応することになる異なるタイプの論理フィールド数に応じて、あらゆる数のアクセス方法が考えられる。１つの実施形態においては、単純（ｓｉｍｐｌｅ）フィールド、フィルタ（ｆｉｌｔｅｒｅｄ）フィールド、及び合成（ｃｏｍｐｏｓｅｄ）フィールドのためのアクセス方法が与えられる。フィールド仕様３０８_１、３０８_２、３０８_５、及び３０８_６には、それぞれ、単純フィールド・アクセス方法３２２_１、３２２_２、３２２_５、及び３２２_６が例示される。単純フィールドは、基礎物理表現内の特定のデータ構造に直接マップされる（例えば、所与のデータベース表及び列にマップされたフィールド）。例として、上述のように、単純フィールド・アクセス方法３２２_１は、論理フィールド名３２０_１（「Ｐａｔｉｅｎｔ ＩＤ」）を、「Ｐａｔｉｅｎｔｉｎｆｏ」と名前を付けた表の中の「ｐａｔｉｅｎｔ＿ＩＤ」と名前を付けた列にマップする。フィールド仕様３０８_３には、フィルタ・フィールド・アクセス方法３２２_３が例示される。フィルタ・フィールドは、関連データ構造を特定し、物理表現内部の項目の特定のサブセットを定めるのに用いられるフィルタを与える。図３に例が設けられており、ここでは、フィルタ・フィールド・アクセス方法３２２_３は、論理フィールド名３２０_３（「Ｓｔｒｅｅｔ」）を、「Ｐａｔｉｅｎｔｉｎｆｏ」と名前を付けた表の中の「ｓｔｒｅｅｔ」と名前を付けた列のデータにマップし、「ＮＹ」市内の個人についてのフィルタ（ｆｉｌｔｅｒ）を定める。フィルタ・フィールドの別の実施例は、郵便番号の物理表現にマップし、データをニューヨーク州について定められた郵便番号のデータのみに制限する、ニューヨーク郵便番号フィールドである。フィールド仕様３０８_４には、合成フィールド・アクセス方法３２２_４が例示される。合成フィールド・アクセス方法は、アクセス方法定義の一部として与えられる式（ｅｘｐｒｅｓｓｉｏｎ）を用いて、１つ又は複数のデータ構造から論理フィールドを計算する。このようにして、基礎物理データ表現には存在しない情報を計算することができる。図３に示される例においては、合成フィールド・アクセス方法３２２_４は、論理フィールド名３２０_４（「Ｎｏｒｍａｌｉｚｅｄ Ｒｅｓｕｌｔｓ」）を「Ｒｅｓｕｌｔｓ／１０」にマップする。別の例は、販売価格フィールドに消費税率を乗ずることによって合成される消費税フィールドである。

基礎データの所与のいずれかのデータ・タイプ（例えば、日付、十進数など）についてのフォーマットは、様々であると考えられる。したがって、１つの実施形態においては、フィールド仕様３０８は、基礎データのフォーマットを反映するタイプ属性を含む。しかしながら、別の実施形態においては、フィールド仕様３０８のデータ・フォーマットは関連基礎物理データとは異なり、この場合には、基礎物理データを論理フィールドのフォーマットに換算することが必要である。

例として、図３に示されるデータ抽象化モデル１３２のフィールド仕様３０８は、図２に示される関係データ表現２１４_２で表現されたデータにマップされる論理フィールドを代表するものである。しかしながら、データ抽象化モデル１３２の他の事例では、論理フィールドは、ＸＭＬなどの他の物理表現にマップされる。

図３に示される抽象照会２０２に対応する例示的な抽象照会が、以下の表１に示される。例として、例示的な抽象照会は、ＸＭＬを用いて定められる。しかしながら、他のあらゆる言語を用いることができるという利点を有する。

例として、表１に示される抽象照会は、選択基準を含む選択仕様（行００４〜００８）と結果仕様（行００９〜０１１）とを含む。１つの実施形態においては、選択基準（これ以降、「検索基準」とも呼ばれる）は、（論理フィールドについての）フィールド名、比較演算子（＝、＞、＜など）、及び値式（そのフィールドが何と比較されているか）で構成される。１つの実施形態においては、結果仕様は、照会実行の結果として戻されることになる抽象フィールドのリストである。抽象照会における結果仕様は、フィールド名及びソート基準で構成することができる。

図３に示されるデータ抽象化モデル１３２に対応する例示的なデータ抽象化モデル（ＤＡＭ）が以下の表２に示される。例として、例示的なデータ抽象化モデルは、ＸＭＬを用いて定められる。しかしながら、他のあらゆる言語を用いることができるという利点を有する。

例として、行００４〜００８は、図３に示されるＤＡＭ１３２の第１のフィールド仕様３０８_１に対応し、行００９〜０１３は、第２のフィールド仕様３０８_２に対応する点に留意されたい。

１つの態様によれば、データ抽象化モデル１３２は、論理リンク（例えば、図２の論理リンク２０４）を含むことができる。より具体的には、データ抽象化モデル１３２のフィールド仕様３０８の各々は、関連論理リンクを含むことができる。さらに、データ抽象化モデル１３２の各々のカテゴリーは、関連論理リンクを含むことができる。論理リンクを含む例示的なデータ抽象化モデルは、図４を参照して、以下に説明される。

論理リンクを有する例示的なデータ抽象化モデル
前述のように、論理フィールド間の関係に基づいて生成された論理リンクを、抽象照会における曖昧なフィールド名参照を解決するのに用いることができる。ここで図４を参照すると、例示的な論理リンクを含むデータ抽象化モデル３５０の１つの実施形態が示される。データ抽象化モデル３５０は、図３のデータ抽象化モデル１３２に例示的な論理リンクが追加されたものに対応する。簡略化のために、データ抽象化モデル３５０においては、図３のデータ抽象化モデル１３２におけるカテゴリー（ｃａｔｅｇｏｒｙ）３１０_１及び３１０_２のフィールド（ｆｉｅｌｄ）仕様３０８_１及び３０８_４のみが示される。さらに、データ抽象化モデル３５０は、図３のデータ抽象化モデル１３２に追加された例示的な関係（ｒｅｌａｔｉｏｎｓ）選択３６０を含む。例として、論理リンクは、リンク仕様３８０_１及びリンク定義３７０_１から構成される。例として、リンク仕様３０８_１は、図３のデータ抽象化モデル１３２のカテゴリー３１０_１に追加された。リンク定義３７０_１は、関係選択３６０に含まれる。より一般には、関係選択は、１つ又は複数のリンク定義を含むことができる。

１つの実施形態においては、リンク仕様は、データの異なる論理分岐間の関係を特定し、複数の属性を含むことができる。各々の属性は値を持つことができる。１つの実施形態においては、各々のリンク仕様は、リンク分岐属性、リンク・タイプ属性、及びリンク名属性を含む。リンク分岐属性は、リンク仕様を含む論理分岐にリンクされる論理分岐を特定する値を有する。例えば、カテゴリー「Ｐａｔｉｅｎｔ」３１０_１のリンク仕様３８０_１は、値「／Ｔｅｓｔｓ」を有するリンク分岐属性「ｔｏ」３８０_２を含む。値「／Ｔｅｓｔｓ」は、カテゴリー「Ｐａｔｉｅｎｔ」３１０_１が、カテゴリー「Ｔｅｓｔｓ」３１０_２によって表現される論理分岐に関連することを示す。リンク・タイプ属性は、関係のタイプを示す値を有する。例えば、リンク仕様３８０_１は、「ｈａｓ」という値を有するリンクタイプ属性「ｔｙｐｅ」３８０_３を含む。より具体的には、値「ｈａｓ」は、カテゴリー「Ｐａｔｉｅｎｔ」３１０_１の論理フィールドによって抽象的に記述される各々の患者が、カテゴリー「Ｔｅｓｔｓ」３１０_２の論理フィールドによって抽象的に記述される１つ又は複数の関連検査を有することを示す。換言すれば、所与の実施例においては、両方のカテゴリー３１０_１及び３１０_２のいずれかの各論理フィールドは、所与の患者に関する情報を含む。しかしながら、値「ｈａｓ」は単なる例示の目的で示されたものであり、リンク・タイプ属性の他の様々な値が考えられることに留意すべきである。例えば、対応するリンクされた論理分岐の他の論理フィールドの情報を用いて所与の論理フィールドを記述できることを示すために、値「ｉｓ＿ａ」を実装することができる。リンク名属性は、論理リンクを特定する値を有する。例えば、リンク仕様３８０_１は、値「Ｐａｔｉｅｎｔ＿Ｔｏ＿Ｔｅｓｔｓ」を有するリンク名属性「ｒｅｌａｔｉｏｎ」３８０_４を含む。換言すれば、リンク仕様３８０_１を有する論理リンクは、「Ｐａｔｉｅｎｔ＿Ｔｏ＿Ｔｅｓｔｓ」という名を持つ。

１つの実施形態においては、リンク定義３７０_１は、リンク仕様３８０_１によって特定される関係を抽象的に記述する。したがって、リンク定義３７０_１は、複数の属性を含むことができる。各々の属性は値を持つことができる。さらに、各々の属性は、１つ又は複数の抽象特性を持つことができる。１つの態様によれば、各々のリンク定義は、名前（ｎａｍｅ）属性と、少なくとも１つのリンクＩＤ（ｌｉｎｋＩＤ）属性と、少なくとも１つのリンク・ポイント（ｌｉｎｋ ｐｏｉｎｔ）属性とを含む。名前属性は、論理リンクを特徴付ける値を有する。名前属性値は、一般に、対応するリンク仕様のリンク名属性の値に対応する。例として、リンク定義３７０_１は、リンク仕様３８０_１のリンク名属性「ｒｅｌａｔｉｏｎ」３８０_４の値に対応する値「Ｐａｔｉｅｎｔ＿Ｔｏ＿Ｔｅｓｔｓ」を有する名前属性「Ｎａｍｅ」３７０_２を含む。各々のリンクＩＤ属性は、論理リンクの少なくとも１つのセグメントを一意的に特定する値を有する。例えば、論理リンクは、データベース表２を経由するデータベース表１とデータベース表３との間のパスを記述することができる。この場合においては、論理リンクは、（１）データベース表１とデータベース表２の間の関係を抽象的に記述する第１のセグメントと、（２）データベース表２とデータベース表３の間の関係を抽象的に記述する第２のセグメント、の２つのセグメントを含むことになる。したがって、第１のセグメントは第１のリンクＩＤ属性によって一意的に特定することができ、第２のセグメント第２のリンクＩＤ属性によって一意的に特定することができる。図４に示される例においては、リンク定義３７０_１は、値「Ｐａｔｉｅｎｔｓ＿Ｔｏ＿Ｔｅｓｔｓ１」を有する単一のリンクＩＤ属性「Ｌｉｎｋ ＩＤ」３７０_３を含む。例として、リンクＩＤ属性「Ｌｉｎｋ ＩＤ」３７０_３は、図１のデータベース１３９のようなリンクされた物理データ構造を特定する２つの抽象特性を含む。例として、リンクＩＤ属性「Ｌｉｎｋ ＩＤ」３７０_３は、抽象特性「ｓｏｕｒｃｅ」３７０_４及び「ｔａｒｇｅｔ」３７０_５を含む。抽象特性「ｓｏｕｒｃｅ」３７０_４は値「Ｐａｔｉｅｎｔｉｎｆｏ」を持ち、抽象特性「ｔａｒｇｅｔ」３７０_５は値「Ｂｌｏｏｄｔｅｓｔ」を持つ。換言すれば、論理リンク「Ｐａｔｉｅｎｔ＿Ｔｏ＿Ｔｅｓｔｓ」は、データベース表「Ｐａｔｉｅｎｔｉｎｆｏ」及び「Ｂｌｏｏｄｔｅｓｔ」の間の関係を抽象的に記述する。各々のリンク・ポイント属性は、データベース表の列のようなリンクされた物理データ構造のリンク・ポイントを特定する２つの抽象特性を含む。例として、リンク・ポイント属性「Ｌｉｎｋ ｐｏｉｎｔ」３７０_６は、抽象特性「ｓｏｕｒｃｅ」３７０_７及び「ｔａｒｇｅｔ」３７０_８を含む。抽象特性「ｓｏｕｒｃｅ」３７０_７は値「ｐａｔｉｅｎｔ＿ＩＤ」を持ち、抽象特性「ｔａｒｇｅｔ」３７０_８もまた、値「ｐａｔｉｅｎｔ＿ＩＤ」を持つ。換言すれば、データベース表「Ｐａｔｉｅｎｔｉｎｆｏ」及び「Ｂｌｏｏｄｔｅｓｔ」は、両方の表に含まれるそれぞれの「ｐａｔｉｅｎｔ＿ＩＤ」列を介してリンクされる。

以下の表３及び表４に、例示的なデータベース表「Ｐａｔｉｅｎｔｉｎｆｏ」及び「Ｂｌｏｏｄｔｅｓｔ」が示される。分かりやすく簡略化するために、表３及び表４に示される例示的なデータベース表について、列の名前とデータ・タイプのみが示される。しかしながら、対応するデータベース表には多数の照会可能なデータが存在すると考えるべきである。

表３から分かるように、表「Ｐａｔｉｅｎｔｉｎｆｏ」は、例として、各々の患者に関する名前（「ｎａｍｅ」）及び住所（「ｓｔｒｅｅｔ」）情報を含む。さらに、表「Ｐａｔｉｅｎｔｉｎｆｏ」の各々の患者は、識別子「ｐａｔｉｅｎｔ＿ＩＤ」によって一意的に特定される。表「Ｂｌｏｏｄｔｅｓｔ」は、例として、病院内の所与の医師（「ｒｅｑｕｅｓｔｅｒ」）によって要求され、患者（「ｐａｔｉｅｎｔ＿ＩＤ」）に対して行われた血液検査の結果（「ｒｅｓｕｌｔｓ」）に関する情報を含む。各々の血液検査結果は、識別子「ｔｅｓｔ＿ｎｕｍ」によって一意的に特定される。

表２のデータ抽象化モデルの全フィールド仕様を含む、図４に示されるデータ抽象化モデル３５０に対応する例示的なデータ抽象化モデル（ＤＡＭ）が、以下の表５に示される。例として、例示的なデータ抽象化モデルは、ＸＭＬを用いて定められる。しかしながら、他のあらゆる言語を用いることができるという利点を有する。

行０４２〜０５９は、図４に示される関係セクション３６０に対応することに留意すべきである。例として、行０２０は図４に示されるリンク仕様３８０_１に対応し、行０４３〜０４８はリンク仕様３７０_１に対応することに留意されたい。さらに、行０４９〜０５８は、行０３８〜０３９のリンク仕様によって指定される論理リンクについての別のリンク定義を含む。具体的には、行０４９〜０５８のリンク定義は、データベース表「Ｂｌｏｏｄｔｅｓｔ」が、表「Ｂｌｏｏｄｔｅｓｔ」に含まれる列「ｒｅｑｕｅｓｔｅｒ」と、表「Ｅｍｐｌｏｙｅｅｉｎｆｏ」に含まれる列「ｅｍｐｌｏｙｅｅｎｕｍ」とを介して、別のデータベース表「Ｅｍｐｌｏｙｅｅｉｎｆｏ」にリンクされる（行０５１〜０５２）ことを示す。行０４９〜０５８のリンク定義は、さらに、データベース表「Ｅｍｐｌｏｙｅｅｉｎｆｏ」が、両方の表に含まれるそれぞれの列「ｐａｔｉｅｎｔ＿ＩＤ」を介して、データベース表「Ｐａｔｉｅｎｔｉｎｆｏ」にリンクされる（行０５５〜０５６）ことを示す。以下の表６に、対応する例示的なデータベース表「Ｅｍｐｌｏｙｅｅｉｎｆｏ」が示される。分かりやすく簡略化するために、表６に示される例示的なデータベース表について、列の名前とデータ・タイプのみが示される。しかしながら、対応するデータベース表には多数の照会可能なデータが存在すると考えるべきである。

上述のように、表１の抽象照会は、照会を実行するために具象照会に変換することができる。抽象照会を具象照会に変換するための例示的な方法が、図５及び図６を参照して以下に説明される。

抽象照会の具象照会への変換
ここで図５を参照すると、図１のランタイム・コンポーネント１３４の動作に関する１つの実施形態を具体化する例示的なランタイム方法４００が示される。ランタイム・コンポーネント１３４が（表１に示される抽象照会のような）抽象照会を入力として受け取ると、ステップ４０２において方法４００に入る。ステップ４０４において、ランタイム・コンポーネント１３４は抽象照会を読み込んで解析し、個々の選択基準及び所望の結果フィールドを探し出す。ステップ４０６において、ランタイム・コンポーネント１３４は、抽象照会に存在する各々の照会選択基準ステートメントを処理し、それによって具象照会のデータ選択部分を構築するために、（ステップ４０６、４０８、４１０、及び４１２を含む）ループに入る。１つの実施形態においては、選択基準は、（論理フィールドについての）フィールド名、比較演算子（＝、＞、＜など）、及び値式（そのフィールドが何と比較されているか）で構成される。ステップ４０８において、ランタイム・コンポーネント１３４は、抽象照会の選択基準からのフィールド名を用いて、データ抽象化モデル１３２のフィールドの定義を検索する。上述のように、フィールド定義は、そのフィールドと関連付けられたデータ構造にアクセスするのに用いられるアクセス方法の定義を含む。次いで、ランタイム・コンポーネント１３４は、処理されている論理フィールドについて具象照会コントリビューションを構築する（ステップ４１０）。ここで定義されるとき、具象照会コントリビューションは、現在の論理フィールドに基づいてデータ選択を実施するのに用いられる具象照会の一部である。具象照会は、ＳＱＬ及びＸＭＬ Ｑｕｅｒｙといった言語で表現された照会であり、所与の物理データ・リポジトリ（例えば、関係データベース又はＸＭＬリポジトリ）のデータと整合する。したがって、具象照会は、図１に示されるデータベース１３９によって表現される物理データ・リポジトリからデータを探し出して取得するために用いられる。次いで、現在のフィールドについて生成された具象照会コントリビューションは、具象照会ステートメントに追加される。次いで、方法４００は、ステップ４０６に戻り、抽象照会の次のフィールドについて処理を開始する。したがって、ステップ４０６から入った処理は抽象照会の各々のデータ選択フィールドについて繰り返され、そのことにより、実施されることになる最終的な照会に付加的内容を与える。

具象照会のデータ選択部分を構築した後で、ランタイム・コンポーネント１３４は、照会実行の結果として戻されることになる情報を特定する。上述のように、１つの実施形態においては、抽象照会は、ここでは結果仕様と呼ばれる結果フィールドのリスト、すなわち照会実行の結果として戻されることになる論理フィールドのリストを定める。抽象照会の結果仕様は、フィールド名及びソート基準から構成することができる。したがって、方法４００は、ステップ４１４においてループ（ステップ４１４、４１６、４１８、及び４２０によって定められる）に入り、生成されている具象照会に結果フィールド定義を追加する。ステップ４１６において、ランタイム・コンポーネント１３４は、データ抽象化モデル１３２内で（抽象照会の結果仕様から）結果フィールド名を検索し、次いで、データ抽象化モデル１３２から結果フィールド定義を取得して、現在の論理結果フィールドについて戻されることになるデータの物理位置を特定する。次いで、ランタイム・コンポーネント１３４は、論理結果フィールドについて、（戻されることになるデータの物理位置を特定する具象照会の）具象照会コントリビューションを（ステップ４１８において）構築する。次いで、ステップ４２０において、具象照会コントリビューションは具象照会ステートメントに追加される。抽象照会の結果仕様の各々が処理されると、ステップ４２２において具象照会が実行される。

ステップ４１０及び４１８に従って論理フィールドについて具象照会コントリビューションを構築するための方法５００の１つの実施形態が、図６を参照して説明される。ステップ５０２において、方法５００は、現在の論理フィールドと関連付けられたアクセス方法が単純（ｓｉｍｐｌｅ）アクセス方法であるかどうかを照会する。そうである場合には、物理データ位置情報に基づいて具象照会コントリビューションが構築され（ステップ５０４）、次いで上述の方法４００に従って処理が続行する。そうでない場合には、処理はステップ５０６に続き、現在の論理フィールドと関連付けられたアクセス方法がフィルタ（ｆｉｌｔｅｒｅｄ）アクセス方法であるかどうかを照会する。そうである場合には、１つ又は複数の所与のデータ構造について、物理データ位置情報に基づいて具象照会コントリビューションが構築される（ステップ５０８）。ステップ５１０において、具象照会コントリビューションは、１つ又は複数の所与のデータ構造と関連付けられたサブセット・データに対して使用される付加的な論理（フィルタ選択）を用いて拡張される。次いで上述の方法４００に従って処理が続行する。

アクセス方法がフィルタ・アクセス方法でない場合には、処理はステップ５０６からステップ５１２に進み、そこで方法５００は、アクセス方法が合成（ｃｏｍｐｏｓｅｄ）アクセス方法であるかどうかを照会する。アクセス方法が合成アクセス方法である場合には、ステップ５１４において、合成されたフィールド式における各々のサブフィールド参照についての物理データ位置を探し出して取得する。ステップ５１６において、合成されたフィールド式の物理フィールド位置情報は、合成されたフィールド式の論理フィールド参照と置き換えられ、そのことにより、具象照会コントリビューションが生成される。次いで上述の方法４００に従って処理が続行する。

アクセス方法が合成アクセス方法でない場合には、処理はステップ５１２からステップ５１８に進む。ステップ５１８は、本発明の実施形態として考えられる他の種類のアクセス方法のいずれかを代表するものである。しかしながら、すべてではない利用可能なアクセス方法を実装する実施形態が考えられることを理解すべきである。例えば、特定の実施形態においては、単純アクセス方法のみが用いられる。別の実施形態においては、単純アクセス方法とフィルタ・アクセス方法のみが用いられる。

上述したように、データ抽象化モデルは、関係マネージャ（例えば、図１の関係マネージャ１５０）を用いて生成し、管理することが可能な論理リンクを含むことができる。論理リンクは、データ抽象化モデルを表現する論理ツリー構造の異なる論理分岐間の関係を抽象的に記述する。１つの実施形態において、論理リンクを生成するための関係マネージャの動作が、図７を参照して以下に説明される。

関係に基づく論理リンクの生成
ここで図７を参照すると、論理リンク（例えば、図２の論理リンク２０４）を生成するための例示的な方法６００が示される。１つの実施形態においては、方法６００は、関係マネージャ（例えば、図１の関係マネージャ１５０）によって実施される。方法６００はステップ６１０において開始する。

ステップ６２９において、データ抽象化モデル（例えば、図１のデータ抽象化モデル１３２）が準備される。例として、データ抽象化モデルを準備することには、メモリ（例えば、図１のメインメモリ１１６）からデータ抽象化モデルを取得することが含まれる。データ抽象化モデルを準備することには、さらに、実行時にデータ抽象化モデルを生成することが含まれる。ステップ６３０において、準備されたデータ抽象化モデルについて、論理ツリー構造が生成される。論理ツリー構造は、複数の論理分岐を含み、データ抽象化モデルを表現する。各々の論理分岐は、データ抽象化モデルからの１つ又は複数の論理フィールドを含むことができる。２つの例示的な論理分岐を有する例示的な論理ツリー構造が、図９を参照して後述される。

ステップ６４０において、複数の論理分岐のうちの異なる論理分岐間の関係が特定される。１つの実施形態においては、異なる論理分岐間の関係は、ユーザによって特定される。例えば、ユーザは、基礎物理データ構造間の関係に関するユーザの知識に基づいて、関係を特定することができる。１つの態様によれば、ユーザのこの知識は、ステップ６２０又はステップ６３０に先立って基礎物理データ構造に関して行われる分析に基づくものとすることが可能である。

異なる論理分岐の論理フィールド間の関係に対して参照が行われることに留意すべきである。しかしながら、他の関係を特定して、論理リンクを生成することができる。例えば、親カテゴリーと子フィールドとの関係、例えば同一の論理分岐内の論理フィールド間の関係を、論理リンクの生成に用いることもできる。したがって、異なる論理分岐間の関係に基づいて論理リンクを生成することは、単に一例として説明されるに過ぎないことが理解される。しかしながら、いずれかの適切な関係に基づいて論理リンクを生成することが、広く考えられる。

ステップ６５０において、１つ又は複数の論理リンクが、特定された関係に基づいて生成される。１つの実施形態においては、１つ又は複数の論理リンクを生成することには、実行時に１つ又は複数の論理リンクを生成することが含まれる。例えば、ユーザは、適切なユーザー・インターフェースを用いて、各々の論理リンクについてリンク仕様（例えば、図４のリンク仕様３８０_１）及びリンク定義（例えば、図４のリンク定義３７０_１）を編集することができる。しかしながら、完全に自動化された生成プロセスを含めて、１つ又は複数の論理リンクの生成に適したいかなる技術も考えられることに留意すべきである。

ステップ６６０において、生成された論理リンクは、データ抽象化モデルと関連付けられる。例えば、生成された論理フィールドをデータ抽象化モデルに含ませて、こうした関連付けを生成することができる。より具体的には、表５を参照して上述したように、ユーザが適切なユーザー・インターフェースを用いてデータ抽象化モデルを編集し、そこに１つ又は複数の論理リンクを挿入することができる。しかしながら、代替的に、生成された論理リンクに対する１つ又は複数の参照をデータ抽象化モデルに含ませることができることに留意すべきである。したがって、生成された論理リンクは、データ抽象化モデルとは別に、１つ又は複数の永続的データ・オブジェクトとして保管することができる。換言すれば、生成された論理リンクは、すべてにわたって広く考えられる様々な異なる方法で、データ抽象化モデルと関連付けることができる。次いで方法６００はステップ６７０において終了する。

上述したように、論理リンクを用いて抽象照会を具象照会に変換することができる。論理リンクを用いた抽象照会の変換は、図８を参照して以下により詳細に説明される。

照会変換における論理リンクの使用
ここで図８を参照すると、論理リンク（例えば、図２の論理リンク２０４）を用いて、抽象照会（例えば、図２の抽象照会２０２）を具象照会に変換するための例示的な方法７００が示される。１つの実施形態においては、方法７００は、関係マネージャ（例えば、図１の関係マネージャ１５０）によって実施される。方法７００はステップ７１０において開始する。

ステップ７２０において、抽象照会が準備される。準備された抽象照会は、１つ又は複数の結果フィールドと、１つ又は複数の選択基準とを含むことができる。１つの実施形態においては、抽象照会を準備することには、メモリ（例えば、図１のメイン・メモリ１１６又はデータベース１３９）から抽象照会を取得することが含まれる。別の実施形態においては、抽象照会を準備することには、実行時に抽象照会を生成することが含まれる。例えば、ユーザは、適切なユーザ・インターフェースを用いて、抽象照会についての結果フィールド仕様（例えば、図３の結果フィールド仕様３０６）として、対応するデータ抽象化モデル（例えば、図１のデータ抽象化モデル１３２）から論理フィールドを選択することができる。ユーザは、さらに、適切なユーザー・インターフェースを用いて、抽象照会についての所望の選択基準（例えば、図３の選択基準３０４）を指定することができる。ユーザが所望の選択基準を指定することを可能にする例示的なユーザー・インターフェースが、図１２及び図１３を参照して後述される。

準備された抽象照会の例として、例示的な抽象照会が以下の表７に示される。分かりやすく簡略化するために、例示的な抽象照会は、２００より大きな結果値を持つ所与の血液検査を指示した病院の医師（要求者）の名前を取得するために、言葉で表現した要求として定められる。

ステップ７３０において、準備された抽象照会に対応するデータ抽象化モデルが取得される。所与の例においては、表５のデータ抽象化モデルが取得される。ステップ７４０において、取得されたデータ抽象化モデルが抽象照会に関する論理リンクを含むかどうかを判断するために、確認が行われる。より具体的には、上述したように、抽象照会は論理フィールドに従って合成される。換言すれば、結果フィールド仕様及び選択基準は、論理フィールド及び対応する値から合成される。このように、ステップ７４０において、抽象照会を合成する論理フィールドに対応するそれぞれの論理フィールド仕様が１つ又は複数の論理リンクを含むかどうかを判断することができる。さらに、それぞれの論理フィールド仕様が、１つ又は複数の関連論理リンクを有するカテゴリー仕様に含まれるかどうかを判断することができる。

所与の例において、表７の抽象照会は、表５のデータ抽象化モデルの行０２８〜０３２に記述される論理条件フィールド「Ｒｅｓｕｌｔｓ」（行００４）を含む検索基準（行００３〜００４）を有する。より具体的には、条件フィールド「Ｒｅｓｕｌｔｓ」は、表５のデータ抽象化モデルに対応する論理ツリー構造を通るパス、すなわち「／Ｐａｔｉｅｎｔ／Ｔｅｓｔｓ／Ｒｅｓｕｌｔｓ」に関して定められる。このパスを含む例示的な論理ツリー構造が、図１１を参照して後述される。１つの実施形態においては、このパスは、ステップ７４０において表５のデータ抽象化モデルを用いて再構成される。

より具体的には、所与の例において、パスは、論理ツリー構造すなわち表５のデータ抽象化モデルを、「Ｐａｔｉｅｎｔ」カテゴリー（表５の行００３〜０２１）から「Ｔｅｓｔｓ」カテゴリー（表５の行０２９〜０４１）まで探索する。「Ｔｅｓｔｓ」カテゴリーは、抽象照会の条件フィールド「Ｒｅｓｕｌｔｓ」に対応する論理フィールド仕様（表５の行０２９〜０３３）を含む。「Ｒｅｓｕｌｔｓ」フィールドに到達するために、表５のデータ抽象化モデルの「Ｐａｔｉｅｎｔ」カテゴリーから「Ｔｅｓｔｓ」カテゴリーまでの探索が、論理リンク「Ｐａｔｉｅｎｔ＿Ｔｏ＿Ｔｅｓｔｓ」に基づいて実施される。対応するリンク仕様（例えば、図４のリンク仕様３８０_１）は、表５の行０２０に示される。関連リンク定義（例えば、図４のリンク定義３７０_１）は、表５の行０４３〜０４８に示される。さらに、表７の抽象照会は、表５のデータ抽象化モデルの行００９〜０１３に記述される論理フィールド「Ｎａｍｅ」を、結果フィールド（表７の行００２）として含む。「Ｎａｍｅ」フィールドについて、表５の行０３８〜０３９に示されるリンク仕様と、表５の行０４９〜０５８に示される対応するリンク定義とを、上述した条件フィールドの特定と同様の処理で特定することができる。

ステップ７４０において、取得されたデータ抽象化モデルが抽象照会に関する論理リンクを含まないと判断された場合には、抽象照会は、ステップ７５０において、図５及び図６にそれぞれ示される方法４００及び５００に従って具象照会に変換される。次いで方法７００はステップ７８０において終了する。

しかしながら、取得されたデータ抽象化モデルが関連論理リンクを含む場合には、該関連論理リンクは取得されたデータ抽象化モデルから特定される。次いで、ステップ７７０において、特定された論理リンクを用いて、抽象照会が具象照会に変換される。１つの実施形態においては、抽象照会は、図５及び図６にそれぞれ示される方法４００及び５００に従って具象照会に変換される。例えば、抽象照会はＳＱＬ照会に変換される。次いで、特定された論理リンクは、表８に関して以下に示されるように、ＳＱＬ照会についてのＪＯＩＮステートメントに変換される。次いで方法７００はステップ７８０において終了する。

より具体的には、所与の例において、表７の抽象照会は、上述の特定された論理リンクを用いて、以下の表８に示される具象照会に変換することができる。例として、例示的な具象照会は、ＳＱＬを用いて定められる。しかしながら、他のあらゆる言語を用いることができるという利点を有する。

例として、具象ＳＱＬ照会は、行００５〜０１０にＪＯＩＮステートメントを含む。ＪＯＩＮステートメントは、行００６において、表５のデータ抽象化モデルの行０４３〜０４８のリンク定義に従ってデータベース表「Ｐａｔｉｅｎｔｉｎｆｏ」（表３）とデータベース表「Ｂｌｏｏｄｔｅｓｔ」（表４）との間の関係を定める。表５のデータ抽象化モデルの行０４９〜０５８におけるリンク定義に従って、行００８におけるＪＯＩＮステートメントは、データベース表「Ｂｌｏｏｄｔｅｓｔ」（表４）とデータベース表「Ｅｍｐｌｏｙｅｅｉｎｆｏ」（表６）との間の関係を定め、行０１０におけるＪＯＩＮステートメントは、データベース表「Ｅｍｐｌｏｙｅｅｉｎｆｏ」（表６）とデータベース表「Ｐａｔｉｅｎｔｉｎｆｏ」（表３）との間の関係を定める。

上述したように、データ抽象化モデル（例えば、図３のデータ抽象化モデル１３２）は、複数の論理分岐を有する論理ツリー構造によって表現することができる。複数のデータ抽象化モデルが与えられる１つの実施形態においては、各々のデータ抽象化モデルは、対応する論理分岐によって表現することができる。複数のカテゴリー仕様（例えば、図３のカテゴリー仕様３１０_１及び３０１_２）を持つ単一のデータ抽象化モデルのみが与えられる別の実施形態においては、各々のカテゴリーは、対応する論理分岐として表現することができる。換言すれば、様々な手法が、１つ又は複数のデータ抽象化モデルを論理ツリー構造として表現するのに適していることに留意すべきである。こうした手法の全てが広く考えられる。データ抽象化モデルを表現する例示的な論理ツリー構造が、図９に示される。

ここで図９を参照すると、図３（表２）のデータ抽象化モデル１３２を表現する例示的な論理ツリー構造が示される。例示的な論理ツリー構造は、例として、抽象化モデル１３２のカテゴリー「Ｐａｔｉｅｎｔ」３１０_１を表す第１の論理分岐８００、及び、カテゴリー「Ｔｅｓｔｓ」３１０_２を表す第２の論理分岐８５０を含む。したがって、第１の論理分岐８００は、カテゴリー名「Ｐａｔｉｅｎｔ」（すなわち、カテゴリー名３３０_１）を示す親ノード８１０を含む。さらに、親ノード８１０は、「Ｐａｔｉｅｎｔ」カテゴリーに含まれる論理フィールドの各々について１つずつ、関連子ノード８１２、８１４、及び８１６を有する。より具体的には、ノード８１２は論理フィールド「Ｐａｔｉｅｎｔ ＩＤ」３０８_１に対応し、ノード８１４は論理フィールド「Ｎａｍｅ」３０８_２に対応し、ノード８１６は論理フィールド「Ｓｔｒｅｅｔ」３０８_３に対応する。同様に、第２の論理分岐８５０は、カテゴリー名「Ｔｅｓｔｓ」（すなわち、カテゴリー名３３０_２）を示す親ノード８２０を含む。親ノード８２０は、「Ｔｅｓｔｓ」カテゴリーに含まれる論理フィールドの各々について１つずつ、関連子ノード８２２、８２４、及び８２６を有する。より具体的には、ノード８２２は論理フィールド「Ｎｏｒｍａｌｉｚｅｄ Ｒｅｓｕｌｔｓ」３０８_４に対応し、ノード８２４は論理フィールド「Ｒｅｓｕｌｔｓ」３０８_５に対応し、ノード８２６は論理フィールド「Ｒｅｑｕｅｓｔｅｒ」３０８_６に対応する。

表５に関して上述したように、第１の論理分岐８００と第２の論理分岐８５０との間に、２つの関係が特定された。特定された関係は、図１０に示される。したがって、第１の関係「Ｐａｔｉｅｎｔ＿ｈａｓ＿Ｔｅｓｔｓ」８３０が、親ノード８１０及び８２０の間に特定された。例として、関係８３０は、「ｈａｓ」タイプの関係である。第２の関係「Ｒｅｑｕｅｓｔｅｒ＿ｉｓ＿ａ＿Ｐａｔｉｅｎｔ」８４０が、子ノード８２６と親ノード８１０との間に特定された。例として、関係８４０は、「ｉｓ＿ａ」タイプの関係である。特定された関係８３０及び８４０を用いて論理分岐８００及び８５０を接続し、図１１に示されるように、リンクされた論理ツリー構造を形成することができる。

ここで図１１を参照すると、例示的なリンクされた論理ツリー構造８６０が示される。例示的なリンクされた論理ツリー構造８６０は、図１０の特定された関係８３０及び８４０を用いて、図９の論理分岐８００及び８５０から生成された。具体的には、図１１のリンクされた論理ツリー構造８６０は、図４（表５）のデータ抽象化モデル３５０を表現する。

例として、リンク論理ツリー構造８６０においては、特定された関係８３０に従って、論理分岐８５０が論理分岐８００に追加された。さらに、特定された関係８４０に従って、子ノード８６２、８６４、及び８６６が「Ｒｅｑｕｅｓｔｅｒ」ノード８２６に追加された。追加された子ノード８６２、８６４、及び８６６は、それぞれ子ノード８１２、８１４、及び８１６によって与えられる情報に対応する、「Ｒｅｑｕｅｓｔｅｒ」ノード８２６に関する情報を与える。しかしながら、論理分岐８００及び８５０は、依然として互いに独立にアクセス可能であることに留意すべきである。例えば、ユーザは、依然として、論理分岐８５０を通ってノード８２０からノード８２６にナビゲートすることができる。換言すれば、リンク論理ツリー構造８６０は、論理分岐８００及び８５０を置き換えない。その代わり、リンク論理ツリー構造は、これらの論理分岐とは別に生成される。

上述したように、ユーザは、抽象照会についての結果フィールドとしてデータ抽象化モデルから論理フィールドを選択するために、適切なユーザー・インターフェースを用いることができる。ユーザは、さらに、抽象照会について所望の選択基準を指定するために、適切なユーザー・インターフェースを用いることができる。ユーザが所望の選択基準を指定することを可能にする例示的なユーザー・インターフェースが、図１２及び図１３を参照して以下に説明される。

ここで図１２を参照すると、例示的なユーザー・インターフェース９００が示される。例示的なユーザー・インターフェース９００は、抽象照会（例えば、図３の抽象照会２０２）の指定が可能になるように設定される。例として、ユーザー・インターフェース９００は、カテゴリー名（例えば、図３のカテゴリー名３３０_１及び３３０_２）のリスト９１２を示す検索基準選択領域９１０を表示する。各々のカテゴリー名は、図形選択要素と関連付けられる。例として、図形選択要素はチェックボックスとして示される。例えば、カテゴリー名「Ｐａｔｉｅｎｔ」はチェックボックス９１４と関連付けられ、カテゴリー名「Ｔｅｓｔｓ」はチェックボックス９１６と関連付けられる。１つの実施形態においては、コンピュータ・マウス、ライトペン、又はタッチスクリーンの場合には人間の指も含む、ポインティング・デバイスなどの適切な入力装置のいずれかを用いて、対応するチェックボックスを選択することができる。

１つの態様によれば、チェックボックス９１４及び９１６の１つを選択して、関連カテゴリーに含まれる論理フィールドを、検索基準を定める条件フィールドとして指定することができる。この目的のために、リスト９１２における各々のカテゴリー名は、対応するカテゴリーに含まれる論理フィールドを示す図形要素と関連付けられる。例として、「Ｐａｔｉｅｎｔ」カテゴリーはドロップダウン・リスト９２２と関連付けられ、「Ｔｅｓｔｓ」カテゴリーはドロップダウン・リスト９２４と関連付けられる。しかしながら、ドロップダウン・リストのような図形要素を実装することは、単なる一例として示されるものであり、従って本発明を限定するためのものではないことに留意すべきである。代わりに、ポップアップ・ウィンドウなどといったいずれかの図形要素も考えられる。さらに、各々のカテゴリーの論理フィールドは、対応する論理ツリー構造の論理分岐表現（例えば、図９の論理分岐８００及び８５０）を用いて表示することができる。

例として、チェックボックス９１４を選択し、「Ｐａｔｉｅｎｔ」カテゴリー（例えば、図３のカテゴリー３１０_１）から条件フィールドを選択した。１つの実施形態においては、次いで、ドロップダウン・リスト９２２をドロップダウンし、選択可能な論理フィールド９３２のリストを表示することができる。例として、選択可能な論理フィールド９３２のリストは、図１１のリンクされた論理ツリー構造８６０のノード８１２、８１４、８１６、及び８２０に対応するすべての論理フィールドを含む。選択可能な論理フィールドの１つを選択すると、リンクされた論理ツリー構造８６０の探索に用いられた対応するパスが追跡される。例として、ユーザが、論理フィールド「Ｔｅｓｔｓ」を条件フィールドとして選択したと仮定する。その結果、ユーザが「Ｐａｔｉｅｎｔ」カテゴリーの選択後に「Ｔｅｓｔｓ」フィールドを選択したときは、パス「／Ｐａｔｉｅｎｔ／Ｔｅｓｔｓ」が生成されることになる。次いで、ユーザは、プッシュボタン「次へ」９５２をクリックして検索基準の選択を続行するか、又はプッシュボタン「取消」９５４をクリックして選択を中止することができる。ここでユーザが、「Ｔｅｓｔｓ」フィールドの選択後にプッシュボタン「次へ」９５２をクリックしたと仮定する。その結果、図１３に示されるように、別の選択領域がユーザー・インターフェース９００に表示され、検索基準の選択を続行することができる。

検索基準選択領域９１０は、ドロップダウン・リスト９２２及び９２４がリンクされた論理分岐に基づいて論理フィールドを表示すべきかどうかを指定するようにユーザに促す表示９４４をさらに含む。表示９４４はチェックボックス９４２と関連付けられる。より具体的には、チェックボックス９４２が選択された場合には、ドロップダウン・リスト９２２及び９２４は、論理リンクを用いてデータ抽象化モデルについて生成された基礎論理ツリー構造に基づく論理フィールドを表示する。しかしながら、チェックボックス９４２が選択されない場合には、ドロップダウン・リスト９２２及び９２４は、論理リンクを用いずにデータ抽象化モデルについて生成された基礎論理ツリー構造に基づく論理フィールドを表示する。

ここで図１３を参照すると、ユーザー・インターフェース９００は、例示的な条件フィールド選択領域９６０を表示する。例として、条件フィールドを選択することができる例示的な条件フィールド選択領域９６０は、カテゴリーの表示９８２を含む。選択することができる条件フィールドが、指定されたカテゴリーにリンクされる論理分岐に含まれる場合には、条件フィールド選択領域９６０は、論理リンクの表示９８４をさらに含む。例として、表示９８４は、図１０の特定された関係８３０に対応する論理リンク「Ｐａｔｉｅｎｔ＿ｈａｓ＿Ｔｅｓｔｓ」９８６を記述する。換言すれば、特定された関係８３０を用いてリンクされた論理ツリー構造８６０を探索することによって、「Ｐａｔｉｅｎｔ」カテゴリーから、ドロップダウン・リスト９６２に表示されるユーザ選択可能フィールドのすべてに到達する。

ドロップダウン・リスト９６２から選択可能な論理フィールドの１つを選択すると、リンクされた論理ツリー構造８６０の探索に用いられた対応するパスが追跡される。例として、ユーザが、論理フィールド「Ｒｅｓｕｌｔｓ」を条件フィールドとして選択したと仮定する。その結果、ユーザが「Ｐａｔｉｅｎｔ」カテゴリーから「Ｔｅｓｔｓ」フィールドを選択した後で「Ｒｅｓｕｌｔｓ」フィールドを選択したときは、パス「／Ｐａｔｉｅｎｔ／Ｔｅｓｔｓ／Ｒｅｓｕｌｔｓ」を生成することができる。次いで、ユーザは、プッシュボタン「次へ」９７２をクリックして検索基準の選択を続行するか、又はプッシュボタン「取消」９７４をクリックして選択を中止することができる。ここでユーザが、「Ｒｅｓｕｌｔｓ」フィールドの選択後にプッシュボタン「次へ」９７２をクリックしたと仮定する。その結果、ユーザが検索基準について対応する値及び演算子を指定することが可能になるように、別の選択領域を表示することができる。ここで、ユーザが、演算子として「＞」を指定し、対応する値として「２００」を指定したと仮定する。その結果、ユーザは、表７（行００４）の抽象照会の選択基準「／Ｐａｔｉｅｎｔ／Ｔｅｓｔｓ／Ｒｅｓｕｌｔｓ＞２００」を生成した。

関連論理分岐間に論理リンクを生成することによって、異なって解釈される場合がある論理フィールドを持つ照会を生成するときのユーザの意図に関する情報を、自動的に収集することができる。この情報を用いると、こうした照会を適切に解釈することができ、実行時に適切に表を結合することができる。

ここでは、特定の値、定義、プログラミング言語、及び例に対するいかなる参照も、単なる説明目的に過ぎないことに留意すべきである。したがって、本発明は、いかなる特定の説明図又は例によっても限定されるものではない。さらに、上記は本発明の実施形態に向けられるものであるが、本発明の他の実施形態及びさらなる実施形態は、その基本的な範囲から逸脱することなく考案することができ、その範囲は、添付の特許請求の範囲によって決定される。

本発明によって例として用いられるコンピュータ・システムである。 抽象照会管理のためのソフトウェア・コンポーネントの関係図である。 抽象照会管理のためのソフトウェア・コンポーネントの関係図である。 抽象照会管理のためのソフトウェア・コンポーネントの関係図である。 ランタイム・コンポーネントの動作を示すフロー・チャートである。 ランタイム・コンポーネントの動作を示すフロー・チャートである。 １つの実施形態におけるデータ抽象化モデルの関係管理を示すフロー・チャートである。 １つの実施形態における抽象照会を生成するためのデータ抽象化モデルにおいて、関係管理の適用を示すフロー・チャートである。 １つの実施形態におけるリンクされた論理分岐を示すツリー構造である。 １つの実施形態におけるリンクされた論理分岐を示すツリー構造である。 １つの実施形態におけるリンクされた論理分岐を示すツリー構造である。 １つの実施形態における抽象照会を指定するために構成されたユーザー・インターフェースを示すスクリーン・ショットである。 １つの実施形態における抽象照会を指定するために構成されたユーザー・インターフェースを示すスクリーン・ショットである。

Claims (16)

1. データ抽象化モデルにおいて、データベース内の物理フィールドに対応する論理フィールドの間の関係を管理する方法であって、コンピュータが、
   論理フィールドを定める前記データ抽象化モデルの論理分岐間のリンクを備える構造を用意するステップであって、前記論理フィールドの幾つかが共通名を共有し、多数の論理フィールドによって共有される共通名に対する参照を含む抽象照会を実行するときに、前記リンクが前記物理フィールドを含むデータ構造を連結する、前記用意するステップと、
   前記用意された構造を使用して、前記抽象照会を、実行可能な照会（以下、具象照会）に変換するステップと
   を実行することを含み、
   前記抽象照会を前記具象照会に変換するステップが、
   前記抽象照会を読み込んで解析し、選択基準及び結果フィールドを探し出すステップであって、前記選択基準は、論理フィールドについてのフィールド名、比較演算子及び当該フィールドが何と比較されているかの値式を含む、前記探し出すステップと、
   前記選択基準の前記フィールド名を用いて、データ抽象化モデルのフィールドの定義を検索するステップであって、前記フィールドの定義は当該フィールドに関連付けられたデータ構造にアクセスするために用いられるアクセス方法の定義を含む、前記検索するステップと、
   前記論理フィールドについて、前記論理フィールドに基づいてデータ選択を実施するために用いられる具象照会の一部である具象照会コントリビューション（以下、第１の具象照会コントリビューション）を構築するステップと、
   前記第１の具象照会コントリビューションを具象照会ステートメントに追加するステップと、
   前記データ抽象化モデル内で前記抽象照会の結果フィールドの名前を検索し、当該データ抽象化モデルから結果フィールドの定義を取得して、結果フィールドについて戻されることになるデータの物理位置を特定するステップと、
   前記結果フィールドについて、戻されることになるデータの物理位置を特定する具象照会の一部である具象照会コントリビューション（以下、第２の具象照会コントリビューション）を構築するステップと、
   前記第２の具象照会コントリビューションを前記具象照会ステートメントに追加するステップと
   を含む、前記方法。
2. 各論理分岐が前記データ抽象化モデルのカテゴリーによって定められる、請求項１に記載の方法。
3. 前記コンピュータが、対応するカテゴリーを持つ少なくとも１つの生成された論理リンクを含むステップを実行することをさらに含む、請求項２に記載の方法。
4. 前記データ抽象化モデルが複数の論理フィールドを含み、前記論理フィールドの各々が特定の論理フィールドを定めており、
   前記方法は、前記コンピュータが、前記複数の論理フィールドのうちの対応する論理フィールドを持つ少なくとも１つの生成された論理リンクを含むステップを実行することをさらに含む、請求項２に記載の方法。
5. 各リンクが、前記データベースにおける前記データの物理表現の種々のデータ構造間のパスを定める、請求項１に記載の方法。
6. 前記物理表現が関係（リレーショナル）表現である、請求項５に記載の方法。
7. 各データ構造が前記関係表現の表である、請求項６に記載の方法。
8. 各データ構造が前記関係表現の表における列である、請求項６に記載の方法。
9. 前記コンピュータが、
   前記複数の論理分岐の各々について、前記データベースにおけるデータの物理表現の、対応するデータ構造を特定するステップと、
   前記特定されたデータ構造が互いに関連するかどうかを判断するステップと
   を実行することをさらに含む、請求項１に記載の方法。
10. データ抽象化モデルによって論理的に表現される物理データについて問い合わせを行う照会を生成する方法であって、コンピュータが、
    メイン・メモリ又はストレージ・デバイスに記憶されたデータベースから、データベース内の物理データに対する抽象照会を受け取るステップであって、前記抽象照会は１又は複数の結果フィールドを有し、各結果フィールドは前記データ抽象化モデルによって定義される論理フィールドに対応する、前記受け取るステップと、
    データ抽象化モデルが前記受け取られた抽象照会に含まれる結果フィールド間の関係を定める論理リンクを含むかどうかを判断するステップであって、当該判断は、前記抽象照会の各結果フィールドについて、対応する論理フィールドが論理リンクを含むかどうかを判断によって行われる、前記判断するステップと、
    前記データ抽象化モデルが前記論理リンクを含む場合に、
    前記論理リンクを当該データ抽象化モデルから取得するステップと、
    前記取得した論理リンクを使用して、前記受け取られた抽象照会を、前記物理データに対して実行することが可能な実行可能な照会（以下、具象照会）に変換するステップと
    を実行することを含み、
    前記受け取られた抽象照会を前記具象照会に変換するステップが、
    前記抽象照会を読み込んで解析し、選択基準及び結果フィールドを探し出すステップであって、前記選択基準は、論理フィールドについてのフィールド名、比較演算子及び当該フィールドが何と比較されているかの値式を含む、前記探し出すステップと、
    前記選択基準の前記フィールド名を用いて、データ抽象化モデルのフィールドの定義を検索するステップであって、前記フィールドの定義は当該フィールドに関連付けられたデータ構造にアクセスするために用いられるアクセス方法の定義を含む、前記検索するステップと、
    前記論理フィールドについて、前記論理フィールドに基づいてデータ選択を実施するために用いられる具象照会の一部である具象照会コントリビューション（以下、第１の具象照会コントリビューション）を構築するステップと、
    前記第１の具象照会コントリビューションを具象照会ステートメントに追加するステップと、
    前記データ抽象化モデル内で前記抽象照会の結果フィールドの名前を検索し、当該データ抽象化モデルから結果フィールドの定義を取得して、結果フィールドについて戻されることになるデータの物理位置を特定するステップと、
    前記結果フィールドについて、戻されることになるデータの物理位置を特定する具象照会の一部である具象照会コントリビューション（以下、第２の具象照会コントリビューション）を構築するステップと、
    前記第２の具象照会コントリビューションを前記具象照会ステートメントに追加するステップと
    を含む、前記方法。
11. 前記データ抽象化モデルが前記論理リンクを含むかどうかを判断するステップが、前記抽象照会の前記結果フィールドの１つ又は複数が、前記データ抽象化モデルのカテゴリーに含まれるかどうかを判断するステップをさらに含み、前記データ抽象化モデルは複数のカテゴリーを含み、前記論理フィールドのグループはカテゴリーの一部であり、当該グループの各々に対してカテゴリーが与えられ、当該カテゴリーは論理リンクを含む、請求項１０に記載の方法。
12. 各論理リンクが、前記データベースにおける前記物理データの関係表現の種々のデータ構造間のパスを定める、請求項１０又は１１に記載の方法。
13. 前記実行可能照会がＳＱＬ照会である、請求項１０〜１２のいずれか一項に記載の方法。
14. 前記取得した論理リンクが、前記ＳＱＬ照会において、前記種々のデータ構造をリンクするＪＯＩＮステートメントとして表現される、請求項１３に記載の方法。
15. データ抽象化モデルにおいて、データベース内の物理フィールドに対応する論理フィールドの間の関係を管理するコンピュータ・プログラムであって、コンピュータに、請求項１〜９のいずれか一項に記載の方法の各ステップを実行させるコンピュータ・プログラム。
16. データ抽象化モデルによって論理的に表現される物理データについて問い合わせを行う照会を生成するコンピュータ・プログラムであって、コンピュータに、請求項１０〜１４のいずれか一項に記載の方法の各ステップを実行させるコンピュータ・プログラム。

Images