(57)【特許請求の範囲】
【請求項１】
照会の対象となるデータベースと、
抽象照会を作成するのに使用する論理フィールド及び選択された論理フィールド用の相関属性を含む抽象化コンポーネントと、前記抽象化コンポーネントにより定義された少なくとも２つの論理フィールドを含む抽象照会を前記データベースのための照会に変換する実行時コンポーネントとを記憶するメモリと、
前記実行時コンポーネントを実行するプロセッサとを含み、
前記相関属性は、名前と、当該相関属性の値を指定する参照フィールドとを備えており、
前記実行時コンポーネントは、前記抽象照会の２つの条件を示す論理フィールドに範囲相関基準が適用されるか否かを判断し、適用される場合は、前記論理フィールドについて定義された相関属性の値の差を計算する式を構築し、該式を前記データベースのための照会に述語として付加するよう、前記プロセッサにより実行される、
コンピュータ・システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般にデータ処理に関し、特に相関（correlation)基準（または相関基準群）を用いてデータにアクセスすることに関する。
【背景技術】
【０００２】
データベースとは情報を記憶するとともに検索・取得する、コンピュータ化されたシステムのことである。リレーショナル・データベース管理システムとはデータを格納するとともに検索・取得するのにリレーショナル（関係型の）手法を使用する、コンピュータによるデータベース管理システム（database management sytem:ＤＢＭＳ) のことである。最も一般的な種類のデータベースはリレーショナル・データベース、すなわち多数の異なる方法で再構成しうるとともにアクセスしうるようにデータを定義する表形式のデータベースである。
【０００３】
特定のアーキテクチャとは無関係に、ＤＢＭＳにおいては、要求元のエンティティ（実体）（たとえばアプリケーションやオペレーティング・システムなど）がデータベース・アクセス要求を発行することにより特定のデータベースに対してアクセス権を要求する。そのような要求としては、たとえば単純なカタログ・ルックアップ（catalog lookup: カタログ探索）要求、または、データベース中の特定のレコードの読み取り、変更、もしくは付加を行うオペレーションを実行するトランザクション、および、それらトランザクション群の組み合わせが挙げられる。これらの要求は高レベルの照会言語（たとえばＳＱＬ（Structured Query Language)）を用いて行う。例を用いて説明すると、ＳＱＬはたとえば次に示すようなデータベースから情報を取得したり、それを更新したりする対話型の照会を作成するために使用する。すなわち、インターナショナル・ビジネス・マシーンズ・コーポレーション（International Business Machines Corporation)（ＩＢＭ(R))製のＤＢ２(R) 、マイクロソフト（Microsoft(R)）製のＳＱＬ  Ｓｅｒｖｅｒ、ならびに、オラクル（Oracle(R))、サイベース（Sybase(R))、およびコンピュータ・アソシエーツ（Computer Associates)製のデータベース製品などである。用語「照会（query)」は格納済みのデータベースからデータを検索・取得するためのコマンドから成る組を指している。照会はプログラマおよびプログラムにデータの選択、挿入、更新、所在の探索などを行わせるコマンド言語の形態をとる。
【０００４】
データベースまたはデータウェアハウスに格納されている情報に対して複雑な照会を構築する場合、照会する対象をなすデータ・エンティティ（データの実体）群を共通の属性に基づいて相関させるのか望ましい場合が多い。たとえば、次に示すすべてのエンティティまたはイベントに基づいてデータ・エンティティ群を相関させる。すなわち、（ｉ）所定の時点または所定の時間範囲内において発生したイベント、（ｉｉ）同時に、または相互の所定の時間間隔内において発生したイベント、（ｉｉｉ）異なる多数の方法で見渡される同一の場所（たとえば同一の通り番地、同一の市、同一の郡、同一の州、同一の郵便番号、同一の国など）において発生したイベント、（ｉｖ）問題の個人または事項が所定の年齢または所定の年齢範囲内にあるときに発生したイベント、および、（ｖ）問題のデータ・エンティティのすべてに付随する年齢が同一であるときに発生したイベントである。
【０００５】
このような複雑な照会を構築する典型的な方法には、照会する対象をなす各データ・エンティティごとに共通の相関属性用の論理を考慮に入れるために、述語を追加して当該照会を補強するステップが含まれている。あいにく、この方法には、複雑なデータ・エンティティの物理的な関係と、照会する対象をなす特定のデータ・エンティティ（たとえば当該データ・エンティティが時や年齢、場所の概念をサポートしているか否か）とについてのより深い理解が必要とされる。たとえば、肝酵素値がある閾値（いきち：しきい値）を超えることが見つかり、肝臓の異常を治すために外科手術（surgery)を受けた現在６０歳以上の男性を特定することに関心のあるユーザを考える。これに対応する照会は、ＳＱＬでは照会１の形をとる。
【０００６】
〔ＳＱＬ照会１〕
SELECT ASTValue, Diagnostics, SurgeryType 
From Demographics, TestResults, SurgeryRecord 
WHERE Gender="M" AND YEAR (CURRENT＿DATE - BirthDate) >=60
AND ASTValue > 30 AND SurgeryType="Liver" 
【０００７】
次いで、上記ユーザが、戻されるデータを当該人物が検査を受けた結果、３０日以内に手術を受けた場合だけを含むように狭めることを望ものと仮定する。
これは、検査と、同一の時間範囲内に発生した手術なるイベントとを選択する述語を追加してＳＱＬ照会１を拡張することにより行うことができる。これを照会２によって示す。
【０００８】
〔ＳＱＬ照会２〕
SELECT ASTValue, Diagnostics, SurgeryType 
FROM Demographics, TestResults, SurgeryRecord 
WHERE Gender="M" AND YEAR (CURRENT＿DATE - BirthDate) >= 60 
AND ASTValue > 30 AND SurgeryType="Liver" AND 
DAYS (SurgeryDate - TestDate) <= 30 
【０００９】
別の場合に、上記ユーザは同一の基準の組み合わせを用いて個人を特定するが、その結果を、検査と手術を受けたときに４０歳〜５０歳の間であった人々に限定することを望む可能性がある。これには、基本の照会に異なる組の述語を付加する必要がある。これを照会３によって示す。
【００１０】
〔ＳＱＬ照会３〕
SELECT ASTValue, Diagnostics, SurgeryType 
FROM Demographics, TestResults, SurgeryRecord 
WHERE Gender="M" AND YEAR (CURRENT＿DATE - BirthDate) >= 60 
AND ASTValue > 30 AND SurgeryType="Liver" AND 
YEAR (SurgeryDate - BirthDate) >= 40 AND YEAR (SurgeryDate -
BirthDate) <= 50 AND YEAR (TestDate - BirthDate) >= 40 AND YEAR 
(TestDate - BirthDate) <= 50
【００１１】
上述した諸例が示すところによれば、各場合において基本の照会を同一に保ちながら、追加の述語を付加することにより、当該照会が検査するエンティティ間において所望の相関を構築している。この結果、所望のデータにアクセスするエンド・ユーザにかかる負担は相当に大きなものになっている。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
したがって、照会内に相関論理を実装する方法が求められている。
【課題を解決するための手段】
【００１３】
本発明は一般に相関基準（または相関基準群）を用いてデータにアクセスするための方法、システム、および製品に関する。
【００１４】
一実例は次に示す方法を提供するものである。
少なくとも１つの論理フィールドによって定義された抽象照会から生成された照会に照会論理を付加するように構成された属性を実現する方法であって、
複数の相関属性のうち、特定の論理フィールド用にサポートされているものを指定するステップと、
前記特定の論理フィールド用にサポートされている前記相関属性の値を算出する定義を指定するステップと
を備えた
方法。
【００１５】
別の実例は次に示す方法を提供するものである。
少なくとも１つの論理フィールドによって定義された抽象照会から生成された照会に照会論理を付加するように構成された属性を実現する方法であって、
複数の論理フィールドの各々ごとに、複数の相関属性のうち、特定の論理フィールド用にサポートされているものを指定するステップと、
複数の論理フィールドの各々ごとに、前記特定の論理フィールド用にサポートされている前記相関属性の値を算出する定義を指定するステップであって、２つの異なる論理フィールド用に指定された、特定の相関属性の値を算出するための少なくとも２つの定義が異なる、ステップと
を備えた
方法。
【００１６】
別の実例は次に示す方法を提供するものである。
少なくとも１つの論理フィールドによって定義された抽象照会から生成された照会に照会論理を付加する方法であって、
前記抽象照会の各条件ごとに、
実行可能照会寄与部を構築するステップと
前記抽象照会が、前記条件の論理フィールドに適用される複数の相関基準のうちの少なくとも１つを含んでいるか否かを判断するステップであって、
前記複数の相関基準の各々が、値を算出するための対応する相関属性を有し、
所定の相関基準用に、少なくとも２つの異なる対応する相関属性定義が定義されている、
ステップと
を備えた、
方法。
【００１７】
さらに別の実例は次に示すコンピュータ読み取り可能な媒体を提供するものである。
実行されたときに、少なくとも１つの論理フィールドによって定義された抽象照会から生成された照会に照会論理を付加するオペレーションを実行するプログラムを含むコンピュータ読み取り可能な媒体であって、
前記オペレーションが、
前記抽象照会の各条件ごとに、
実行可能照会寄与部を構築するステップと
前記抽象照会が、前記条件の論理フィールドに適用される複数の相関基準のうちの少なくとも１つを含んでいるか否かを判断するステップであって、
前記複数の相関基準の各々が、値を算出するための対応する相関属性を有し、
所定の相関基準用に、少なくとも２つの異なる対応する相関属性定義が定義されている、
ステップと
を備えた、
コンピュータ読み取り可能な媒体。
【００１８】
さらに別の実例は次に示すコンピュータ読み取り可能な媒体を提供するものである。
その上に格納された情報を備えたコンピュータ読み取り可能な媒体であって、
前記情報が、
抽象照会を定義する複数の論理フィールドを備えた照会仕様と、
前記複数の論理フィールドうちの少なくとも１つ用に指定された少なくとも１つの相関属性定義であって、
前記相関属性定義が、当該相関属性定義の値を算出するための名前および定義を備えている、
少なくとも１つの相関属性定義と
データに対して発行された抽象照会を受領するのに対応して、オペレーションを実行する実行時コンポーネントであって、
前記抽象照会が、
前記照会仕様に基づいて定義されているとともに、
前記少なくとも１つの相関属性定義が指定された前記少なくとも１つの論理フィールドによって構成されており、
前記オペレーションが、
前記少なくとも１つの論理フィールド用の前記相関属性の値を算出するステップ
を備えている、
実行時コンポーネントと
を備えている
コンピュータ読み取り可能な媒体。
【００１９】
さらに別の実例は次に示すコンピュータ読み取り可能な媒体を提供するものである。
その上に格納された情報を備えたコンピュータ読み取り可能な媒体であって、
前記情報が、
抽象照会を定義する複数の論理フィールドを備えた照会仕様と、
前記複数の論理フィールドうちの少なくとも１つ用に指定された複数の相関属性定義であって、
各相関属性定義が、当該相関属性定義の値を算出するための名前および定義を備えている、
複数の相関属性定義と
データに対して発行された抽象照会を受領するのに対応して、オペレーションを実行する実行時コンポーネントであって、
前記抽象照会が、
前記照会仕様に基づいて定義されているとともに、
前記少なくとも１つの相関属性定義が指定された前記少なくとも１つの論理フィールドによって構成されており、
前記オペレーションが、
前記少なくとも１つの論理フィールド用の前記相関属性の値を算出するステップ
を備えている、
実行時コンポーネントと
を備えている
コンピュータ読み取り可能な媒体。
【発明を実施するための最良の形態】
【００２０】
〔概要〕
本発明は一般にデータにアクセスするためのシステム、方法、および製品に関する。一般に、相関基準（または相関基準群）を用いて構成した照会によると、データ・アクセスが容易になる。相関基準群が存在すると、照会の条件に適用すべき追加の相関論理を導入するのが容易になる。一般に、時、物理的な場所、および年齢に基づいた、エンティティの相関をサポートする相関基準群が考えられる。
【００２１】
一実施形態では、相関基準はデータの論理モデルの一部として実装する。ここでは、この論理モデルをデータ・リポジトリ抽象化層と呼ぶ。データ・リポジトリ抽象化層は基をなすデータ・リポジトリの論理的な面（見え方）を提示している。このように、データは当該データを物理的に表す特定の方法とは無関係に作成することができる。また、照会抽象化層も設ける。これはデータ・リポジトリ抽象化層に基づいている。抽象照会を、特定の物理データ表現に対して使用しうる形態に変換することは実行時コンポーネントが行う。
【００２２】
ここでは便宜上、用語「相関」は照会基準とデータ・リポジトリ抽象化層の一部として定義された属性とを指すように使用する。用語「相関」は、共通のエンティティについて少なくとも２つの照会条件に照会論理を適用する、本発明の一側面を示している。しかし、別の側面では、１つの照会条件だけに照会論理を適用することもある。以下の開示から明らかになるように、エンド・ユーザにはエンティティをどのように評価すべきかを見極める煩わしさがない、という点において、エンド・ユーザはさらなる利点を実感することになる。したがって、（単純な相関が少なくとも２つの照会条件の間に生じるの対して、）「相関」は照会条件と、たとえば特定の時属性、場所属性、または年齢属性との間に生じる。特に、相関属性は、照会に全体として適用するから、特定の種類の相関属性をサポートするすべての条件フィールドに付随するデータ選択論理に影響を与えることになる。
【００２３】
本発明の一実施形態はコンピュータ・システム（たとえば図１に示すとともに後述するコンピュータ・システム）で使用するプログラム製品として実現する。このプログラム製品のプログラムは実施形態の機能（たとえば、ここで説明する方法）を定義するものであるが、様々な信号担持媒体に格納することができる。信号担持媒体の例は次に示す情報を含んでいるが、それらに限定されない。すなわち、（ｉ）書き込み不能型記憶媒体（たとえばコンピュータに内蔵された読み取り専用記憶装置〔たとえばＣＤ−ＲＯＭ駆動装置によって読み取り可能なＣＤ−ＲＯＭディスクなど〕など）に永続的に格納された情報、（ii）書き込み可能記憶媒体（たとえばディスケット駆動装置内のフロッピー(R) ディスクやハード・ディスク駆動装置など）に格納された変更可能な情報、または（iii)無線通信を含む通信媒体（たとえばコンピュータ・ネットワークまたは電話ネットワークなど）によってコンピュータに伝達される情報である。最後の実施形態には特に、インターネットおよび他のネットワークからダウンロードする情報が含まれる。このような信号担持媒体は、本発明の機能に指令するコンピュータ読み取り可能な命令群を担持しているときには、本発明の実施形態を表している。
【００２４】
一般に、本発明の実施形態を実現するために実行するルーチンはオペレーティング・システムもしくは特定のアプリケーションの一部、コンポーネント、プログラム、モジュール、オブジェクト、または、命令群から成る手順である。本発明のソフトウェアは通常、ネイティブ・コンピュータ（native computer)が機械読み取り可能なフォーマットの、したがって実行可能な命令群に変換することになる複数の命令群から構成されている。また、プログラムは当該プログラムに限定的に存在する、またはメモリもしくは記憶装置に存在する変数およびデータ構造から構成されている。さらに、後述する様々なプログラムは本発明の特定の実施形態において当該プログラムを実装する際に対象とする用途に基づいて特定する。しかし、認識すべき点を挙げると、以下に示す特定の専門用語は単に便宜的に使用するだけである。したがって、本発明をそのような専門用語によって特定される、および／または示唆される特定の用途だけにおける使用に限定すべきではない。（「Ａおよび／またはＢ」は「ＡおよびＢ、Ａ、またはＢ」を表わす。）
【００２５】
〔環境の物理的な概観〕
図１は本発明の実施形態を実現しうるネットワーク接続されたシステム１００のブロック図である。一般に、ネットワーク接続されたシステム１００はクライアント（たとえばユーザの）コンピュータ１０２（このようなクライアント・コンピュータ１０２が３台示されている）および少なくとも１台のサーバ１０４（このようなサーバ１０４が１台示されている）を備えている。クライアント・コンピュータ１０２とサーバ・コンピュータ１０４とはネットワーク１２６を介して接続されている。一般に、ネットワーク１２６としてはＬＡＮ（local area network) および／またはＷＡＮ（wide area network)を用いることができる。特定の実施形態では、ネットワーク１２６はインターネットである。
【００２６】
クライアント・コンピュータ１０２は中央処理装置（Central Processing Unit:ＣＰＵ）１１０を備えている。ＣＰＵ１１０はバス１３０を介してメモリ１１２、記憶装置１１４、入力装置１１６、出力装置１１９、およびネットワーク・インタフェース装置１１８に接続されている。入力装置１１６としてはクライアント・コンピュータ１０２に入力を供給する任意の装置を用いることができる。たとえばキーボード、キーパッド、ライトペン、タッチ・スクリーン、トラック・ボール、または、音声認識装置、音声／画像再生装置などを使用することができる。出力装置１１９としてはユーザに出力を供給する任意の装置（たとえば既存のディスプレイ画面など）を用いることができる。入力装置１１６から分離して示されているが、出力装置１１９と入力装置１１６とは組み合わせることができる。たとえばディスプレイ画面とタッチ・スクリーンとを統合したもの、ディスプレイとキーボードとを統合したもの、音声認識装置とテキスト読み上げ変換装置とを統合したものなどを使用することができる。
【００２７】
ネットワーク・インタフェース装置１１８としてはクライアント・コンピュータ１０２とサーバ・コンピュータ１０４との間の、ネットワーク１２６を介したネットワーク通信を実現する任意の入口／出口（entry/exit）装置を用いることができる。たとえば、ネットワーク・インタフェース装置１１８としてはネットワーク・アダプタまたは他のネットワーク・インタフェース・カード（network interface card: ＮＩＣ）を用いることができる。
【００２８】
記憶装置１１４としては直接アクセス記憶装置（Direct Access Storage Device: ＤＡＳＤ）を用いるのが望ましい。それは単一の装置として示されているが、固定記憶装置および／または着脱可能な記憶装置を組み合わせたもの（たとえば固定ディスク駆動装置、フロッピー(R) ディスク駆動装置、テープ駆動装置、着脱可能メモリ・カード、光記憶装置など）を使用することができる。メモリ１１２と記憶装置１１４は複数の主記憶装置と二次記憶装置とにわたる１つの仮想アドレス空間の一部を構成していてもよい。
【００２９】
メモリ１１２としては本発明のプログラムとデータ構造を保持するのに十分な大きさを有するランダム・アクセス・メモリを用いるのが望ましい。メモリ１１２は単一の構成要素として示されているが、実際には複数のモジュールから成る、という点を理解すべきである。そして、メモリ１１２は高速のレジスタおよびキャッシュからより低速だがより大きなＤＲＡＭチップに至る複数の階層に存在する。
【００３０】
たとえば、メモリ１１２はオペレーティング・システム１２４を格納している。使用しうるオペレーティング・システムの例としてはＬｉｎｕｘ(TM)やマイクロソフト（Microsoft(R)）製のＷｉｎｄｏｗｓ(R) が挙げられる。より一般的には、ここに開示する機能をサポートする任意のオペレーティング・システムを使用することができる。
【００３１】
また、メモリ１１２はブラウザ・プログラム１２２を格納しているようにも示されている。ブラウザ・プログラム１２２はＣＰＵ１１０で実行されると、様々なサーバ１０４の間をナビゲートすること、および、サーバ１０４のうちの少なくとも１つのもののネットワーク・アドレスを特定することを支援する。一実施形態では、ブラウザ・プログラム１２２はウェブを基にしたグラフィカル・ユーザ・インタフェース（ＧＵＩ）を備えている。これにより、ユーザはＨＴＭＬ（Hyper Text Markup Language) で記述された情報を表示することが可能になる。しかし、より一般的には、ブラウザ・プログラム１２２としてはサーバ・コンピュータ１０４から伝送されて来る情報を表示することのできる任意のプログラム（ＧＵＩを使用しているのが望ましい）を用いることができる。
【００３２】
サーバ・コンピュータ１０４はクライアント・コンピュータ１０２と同様の態様で物理的に構成されている。したがって一般に、サーバ・コンピュータ１０４はバス１３６によって相互に接続されたＣＰＵ１３０、メモリ１３２、および記憶装置１３４を備えているように示されている。メモリ１３２としてはサーバ・コンピュータ１０４に配置されたプログラムとデータ構造を保持するのに十分な大きさを有するランダム・アクセス・メモリを用いることができる。
【００３３】
一般に、サーバ・コンピュータ１０４はメモリ１３２に常駐しているように示されているオペレーティング・システム１３８の制御下にある。オペレーティング・システム１３８の例としてはＩＢＭ(R) ＯＳ／４００(R) 、ＵＮＩＸ(R) 、Ｍｉｃｒｏｓｏｆｔ(R) Ｗｉｎｄｏｗｓ(R) などが挙げられる。より一般的には、ここで説明する機能をサポートしうる任意のオペレーティング・システムを使用することができる。
【００３４】
メモリ１３２はさらに少なくとも１つのアプリケーション１４０と抽象照会インタフェース１４６とを備えている。アプリケーション１４０と抽象照会インタフェース１４６はコンピュータ・システム１００中の様々なメモリと記憶装置に様々な時に存在する複数の命令群を備えたソフトウェア製品である。アプリケーション１４０と抽象照会インタフェース１４６はサーバ１０４中の少なくとも１つプロセッサ１３０が読み込んで実行（execute)すると、本発明の様々な側面を具体化したステップ群すなわち構成要素群を実行（execute)するのに必要なステップ群をコンピュータ・システム１００に実行（perform)させる。アプリケーション１４０（ならびに、より一般的に任意の要求元エンティティ〔たとえばオペレーティング・システム１３８〕および〔最高のレベルに存在する〕ユーザ）はデータベース（たとえばデータベース１５６1 、・・・、１５６N 〔集合的にデータベース１５６と呼ぶ〕）に対して照会を発行する。たとえば、データベース１５６は記憶装置１３４中に存在するデータベース管理システム（ＤＢＭＳ）の一部として示されている。データベース１５６はデータから成る任意の集合体を代表するものであり、特定の物理的な表現とは無関係である。たとえば、データベース１５６は（ＳＱＬによる照会によってアクセス可能な）リレーショナル・スキーマに従って、または、（ＸＭＬによる照会によってアクセス可能な）ＸＭＬスキーマに従って構成することができる。しかし、本発明は特定のスキーマに限定されず、現在は未知のスキーマへ拡張することが考えられる。ここで使用しているように、用語「スキーマ」は一般にデータの特定の配列を指す。
【００３５】
一実施形態では、アプリケーション１４０が発行する照会は各アプリケーション１４０に含まれているアプリケーション照会仕様１４２に従って定義する。アプリケーション１４０が発行する照会は事前に定義（すなわちアプリケーション１４０の一部としてハード・コード（hard code)化）しておいてもよいし、あるいは、入力（たとえばユーザ入力）に応答して作成してもよい。いずれの場合においても、照会（ここでは「抽象照会」と呼ぶ）は抽象照会インタフェース１４６によって定義されている論理フィールドを用いて作成／実行する。特に、抽象照会で使用する論理フィールドは抽象照会インタフェース１４６のデータ・リポジトリ抽象化コンポーネント１４８によって定義されている。抽象照会は実行時コンポーネント１５０が実行する。実行時コンポーネント１５０はまず、抽象照会を、ＤＢＭＳ１５４に含まれているデータの物理的な表現と一致する形態に変換する。
【００３６】
一実施形態では、データ・リポジトリ抽象化コンポーネント１４８は相関属性１６２を用いて構成する。相関属性１６２はたとえば、照会の条件群の間の関係を定義するのに使用する論理フィールドに配置する空間制約と時制約を指定する。実行時コンポーネント１５０の相関アルゴリズム１５１は相関属性１６２によって指定された規則を執行するオペレーションを実行する。この目的のために、実行時コンポーネント１５０は範囲基準リスト１７０、個別基準リスト１７２、および範囲フィールド・リスト１７４を備えた一時的なデータ構造を保持している。
【００３７】
一実施形態では、照会の構成要素はユーザがグラフィカル・ユーザ・インタフェース（ＧＵＩ）を用いて指定する。このＧＵＩのコンテンツはアプリケーション１４０が生成する。特定の実施形態では、このＧＵＩのコンテンツはＨＴＭＬ（hypertext markup language)で記述されたコンテンツであり、クライアントのコンピュータ・システム上に表示される。したがって、メモリ１３２にはクライアント・コンピュータ１０２が出す要求を処理するｈｔｔｐ（Hypertext Transfer Protocol)サーバ・プロセス１５２（たとえばウェブ・サーバ）が格納されている。たとえば、サーバ・プロセス１５２はデータベース１５６へのアクセスを求める要求に応答するものであり、たとえばサーバ１０４に常駐している。データベース１５６に存在するデータを求めて入来するクライアントの要求はアプリケーション１４０を呼び出す。アプリケーション１４０はプロセッサ１３０によって実行されると、サーバ・コンピュータ１０４に本発明の様々な側面（たとえばデータベース１５６にアクセスすることなど）を具体化したステップ群すなわち構成要素群を実行させる。一実施形態では、アプリケーション１４０は後刻、ブラウザ・プログラム１２２によって表示されることになるＧＵＩの構成要素を構築するように構成された複数のサーブレットを備えている。
【００３８】
図１はネットワーク接続されたクライアント・コンピュータ１０２とサーバ・コンピュータ１０４用のハードウェア／ソフトウェアの単なる一構成例にすぎない。本発明の実施形態群は、コンピュータ・システムが複雑かつマルチユーザ型のコンピューティング機器、単一ユーザ型のワークステーション、あるいは自分自身の不揮発性記憶装置を備えていないネットワーク機器であるか否かとは無関係に、同等の任意のハードウェア構成に適用することができる。また、理解すべき点を挙げると、ＨＴＭＬを含む特定のマークアップ言語を参照ているけれども、本発明は特定の言語、標準、またはバージョンに限定されない。したがって、当業者が理解しうるように、本発明は他のマークアップ言語および非マークアップ型の言語に適用可能であるし、また、本発明は特定のマークアップ言語の将来の変更および現在未知の他の言語にも適用可能である。同様に、図１に示すｈｔｔｐサーバ・プロセス１５２は単なる例示にすぎず、既知のプロトコルおよび未知のプロトコルをサポートする他の実施形態が考えられる。
【００３９】
〔環境の論理的な概観／実行時の概観〕
図２および図３は本発明のコンポーネント群の模式的な関係図２００を示す図である。要求元エンティティ（たとえばアプリケーション１４０の１つ）は当該要求元エンティティの個別のアプリケーション照会仕様１４２によって定義した照会２０２を発行（issue)する。結果として得られる照会をここでは「抽象照会」と呼ぶ。というのは、ＤＢＭＳ１５４中に存在する、基となる物理的なエンティティを直接に参照するのではなく、抽象（すなわち論理）フィールドによって当該照会を合成しているからである。この結果、基となるデータに使用されている特定の表現とは無関係である抽象照会を定義することができる。一実施形態では、アプリケーション照会仕様１４２はデータを選択するために使用する基準（選択基準２１４）、照会のうちの少なくとも１つ（より典型的には少なくとも２つ）の条件を相関させるのに使用する基準（相関基準２０３）、および選択基準２１４に基づいて戻すべきフィールドの明示的な仕様（戻りデータ仕様２０６）を含んでいる。
【００４０】
図３に示す抽象照会２０２の詳細を下のテーブルＩに示す。実例として、抽象照会２０２はＸＭＬを用いて定義されている。しかし、任意の他の言語を使用してもよい。
【００４１】
〔テーブルＩ−照会の例〕
001 <QueryAbstraction>
002  <Selection>
003    <Condition field="Diagnosis" operator="EQ" value="Anemia"/>
004    <Condition field="Hemoglobin" operator="LT" value="20" 
005      relOperator="AND"/>
006    <Correlation attribute="Age" operator="GT" value="40"/>
007    <Correlation attribute="Span(Time)" operator="LT" value="5"
008 relOperator="AND"?> 
009  </Selection> 
010  <Results>
011   <Field name="FirstName"/> 
012   <Field name="LastName"/>
013  </Results> 
014 </QueryAbstraction> 
【００４２】
例示したように、テーブルＩに示す抽象照会は選択基準を含む選択（selection)仕様（第００５〜０１４行）および結果（result）仕様（第０１５〜０１９行）を含んでいる。一実施形態では、選択基準（ここでは「条件」とも呼ぶ）は（論理フィールド用の）フィールド名、比較演算子（＝、＞、＜、など）、および（当該フィールドの比較対象である）値式から成る。一実施形態では、結果仕様は照会を実行した結果として戻すことになる抽象フィールド群から成るリストである。抽象照会に存在する結果仕様はフィールド名と分類基準から成る。たとえば、相関基準は「Age(年齢）」相関基準と「Span(Time)（時間範囲）」相関基準である。これらの相関基準は各々、当該照会の少なくとも１つの条件に適用する。この例では、「Age(年齢）」相関基準は特定の診断と検査結果の値を選択するのに使用する個別の述語に追加の論理を付加している。「Span(Time)（時間範囲）」相関基準は当該照会に追加の論理を全体として付加している。この例の場合には、互いの間が５日以内であった診断と検査結果の値を有する患者だけを選択することにより、これを行っている。
【００４３】
比較例を挙げると、次に示すものはテーブルＩの抽象照会に対応するＳＱＬ照会を表している。
【００４４】
〔ＳＱＬ照会４〕
SELECT f＿name, l ＿name FROM patient WHERE 
(diag ='Anemia' AND YEAR(diagdate - birthdate) > 40) AND 
(testval < 20 AND YEAR(testdate - birthdate) > 40 AND
(ABS(DAYS(diagdate - testdate)) < 5 ) 
【００４５】
留意点を挙げると、所望の条件の各々に相関論理を適用している点がユーザの負担になっている。これに対して、本発明では、データ・リポジトリ抽象化コンポーネント１４８中に存在する事前に定義した相関属性の対象である各条件に相関基準を適用している。この点におけるデータ・リポジトリ抽象化コンポーネント１４８の諸側面については、下でより詳細に説明する。
【００４６】
一実施形態では、相関基準２０３、選択基準２０４、および戻りデータ仕様２０６は各々、ユーザがユーザ・インタフェース（たとえばブラウザ・プログラム１２２）を介して指定する。この目的のために、上記ユーザ・インタフェースは相関基準２０３、選択基準２０４、および戻りデータ仕様２０６の各々ごとに、抽象照会２０２を合成する際に依拠する個別の入力フィールドを備えている。
【００４７】
アプリケーション照会仕様１４２が指示しているとともに、抽象照会２０２を作成するのに使用する論理フィールドは、データ・リポジトリ抽象化コンポーネント１４８が定義している。一般に、データ・リポジトリ抽象化コンポーネント１４８は、データを選択するための基準を指定するため、および、照会オペレーションが戻す結果データのフォーマットを指定するために、アプリケーション１４０が（ユーザが入力する照会の条件に応答して）発行する照会（たとえば抽象照会２０２）中で使用しうる情報を１組の論理フィールドとして公表している。これらの論理フィールド群はＤＢＭＳ１５４中で使用されている、基をなすデータ表現とは無関係に定義されているから、この基をなすデータ表現と緩やかに結合された照会を形成することが可能になる。
【００４８】
一般に、データ・リポジトリ抽象化コンポーネント１４８は複数のフィールド（field)仕様２０８1 、２０８2 、２０８3 、・・・（例として６つ示されている）（集合的にフィールド仕様２０８と呼ぶ）を備えている。特に、抽象照会を作成するのに利用可能な各論理フィールドは１つのフィールド仕様を備えている。一実施形態では、フィールド仕様２０８は論理フィールド名（name）２１０1 、２１０2 、２１０3 （集合的にフィールド名２１０）および関連するアクセス方式（access method)２１２1 、２１２2 、２１２3 （集合的にアクセス方式２１２）から成る。説明中の実施形態では、フィールド仕様２０８は少なくとも１つのカテゴリ名２１６1 、２１６2 、２１６3 （集合的にカテゴリ名２１６）も備えている。カテゴリ名は一群の論理フィールド名を関連付けている。たとえば、図３において、フィールド仕様２０８1 、２０８2 は「Demographic(人口統計）」カテゴリ２１６1 の一部であり、フィールド仕様２０８3 、２０８4 、２０８5 「Diagnostis (診断）」カテゴリ２１６2 の一部であり、フィールド仕様２０８6 、２０８7 、２０８8 は「Tests(検査）」カテゴリ２１６2 の一部である。しかし、カテゴリを使用することは特定の実施形態の単なる典型例にすぎず、他の実施形態ではカテゴリを使用していない。
【００４９】
アクセス方式２１２は論理フィールド名を、データベース（たとえばデータベース１５６のうちの１つ）における特定の物理データ表現２１４1 、２１４2 、・・・、２１４N に関連付けている（すなわちマップしている）。たとえば、図２には２つのデータ表現が示されている。すなわち、ＸＭＬデータ表現２１４1 とリレーショナル・データ表現２１４2 とである。しかし、物理データ表現２１４N は既知あるいは未知の他のすべてのデータ表現が考えられることを表している。
【００５０】
一実施形態では、単一のデータ・リポジトリ抽象化コンポーネント１４８が少なくとも２つの物理データ表現用のフィールド仕様（および付随するアクセス方式）を含んでいる。別の実施形態では、個別の物理データ表現２１４ごとに異なる単一のデータ・リポジトリ抽象化コンポーネント１４８を備えている。さらに別の実施形態では、複数のデータ・リポジトリ抽象化コンポーネント１４８を備えている。その場合、各データ・リポジトリ抽象化コンポーネント１４８は（少なくとも１つの物理データ表現を有する、）基をなす同一の物理データの様々な部分を公表している。このように、複数のユーザが単一のアプリケーション１４０を同時に用いて、基をなす同一の物理データにアクセスすることができる。その場合、アプリケーションに公表する、基をなすデータの特定の部分は個別のデータ・リポジトリ抽象化コンポーネント１４８が決める。
【００５１】
サポートすべき様々な種類の論理フィールドの個数に応じて、任意の個数のアクセス方式が考えられる。一実施形態では、単純フィールド用のアクセス方式、フィルタリング済みフィールド用のアクセス方式、および合成フィールド用のアクセス方式を備えている。フィールド仕様２０８1 、２０８2 、２０８3 はそれぞれ、単純フィールド用のアクセス方式２１２1 、２１２2 、２１２3 を示している。単純フィールドは基をなす物理データ表現中の特定のエンティティに直接にマップされている（たとえば所定のデータベースの表と列にマップされた１つのフィールド）。たとえば、図３に示す単純フィールド用のアクセス方式２１２1 は論理フィールド名２１０1 （「FirstName 」）を「patient(患者）」なる名前の表(table) 中の「f ＿name」なる名前の列（column）にマップしている。フィルタリング済みフィールド（図２と図３には例示せず）は関連する物理エンティティを特定するとともに、物理データ表現中の項目から成る特定のサブセットを定義するのに使用する規則を規定している。フィルタリング済みフィールドの一例としてニューヨーク州の郵便番号（ZIP code）フィールドが挙げられる。ニューヨーク州の郵便番号のフィールドは郵便番号の物理表現にマップされているとともに、データを、ニューヨーク州用に定義されたそれらの郵便番号だけに限定する。合成アクセス方式（たとえば２１３1 、２１３2)はアクセス方式の定義の一部として供給される式を用いて、少なくとも１つの物理フィールドから論理フィールドを算出する。このように、基をなすデータ表現中には存在しない情報を算出することができる。一例として、販売価格フィールドに売上税率を乗算して合成する売上税フィールドが挙げられる。
【００５２】
基をなすデータの任意の所定のデータ型（たとえば日付、１０進数、など）用のフォーマットは変化するものと考えられる。したがって、一実施形態では、フィールド仕様２０８は基をなすデータのフォーマットを反映させた型属性を含んでいる。しかし、別の実施形態では、フィールド仕様２０８のデータ・フォーマットは関連する、基をなすデータとは異なっている。その場合、アクセス方式が、要求元エンティティが想定する適切なフォーマットでデータを戻す任に当たる。したがって、アクセス方式は基をなす物理データの実際のフォーマットに加え想定される（すなわち論理フィールドに従う）フォーマットを知っている必要がある。そうすれば、アクセス方式は基をなす物理データを論理フィールドのフォーマットに変換することができる。
【００５３】
たとえば、図２および図３に示すデータ・リポジトリ抽象化コンポーネント１４８のフィールド仕様２０８はリレーショナル・データ表現２１４2 で表したデータにマップされた論理フィールドを代表している。しかし、データ・リポジトリ抽象化コンポーネント１４８の他の例では、論理フィールドを他の物理データ表現（たとえばＸＭＬ）にマップしている。
【００５４】
フィールド仕様２０８のうちの少なくとも１つは相関属性（図１に相関属性１６２として集合的に示されている）も用いて構成する。たとえば、「Diagnosis(診断）」フィールド仕様２０８3 は「Age(年齢）」相関属性２１８1 と「Time（時）」相関属性２１８2 を備えており、「Test Result(検査結果）」フィールド仕様２０８6 も「Age(年齢）」相関属性２１８1 と「Time（時）」相関属性２１８2 を備えている。すべてのフィールド仕様が相関属性を備える必要がある訳ではない、という点に留意すべきである。
【００５５】
一般に、相関属性によって、論理フィールドの相関相手であるエンティティ／イベントを特定する。一実施形態では、論理フィールドを時（特定の時点または時間範囲）、物理的な場所、および年齢と相関させている。したがって一実施形態では、相関属性によって、論理フィールドに付随するデータのインスタンスを制約するのに使用する空間または時間の大きさを特定している。しかし、より一般的には、照会オペレーションに関係する様々なエンティティの他の特性を考慮する相関属性（たとえば色、重さ、体積、長さ、幅など）を定義することができる。図３から分かるように、各フィールド定義に付随する相関属性は一般に、「Name（名前）」と「Fieldref（参照フィールド）」を備えている。「Name（名前）」は（相関属性が定義されている）対応するフィールドの相関相手になりうるものに基づいて当該相関属性を特定するためのハンドル（識別情報）を実現している。たとえば、相関属性２１８1 には、対応する論理フィールドを年齢に相関させうることを示す「Age(年齢）」なる名前が付与されている。現在の例では、「Age(年齢）」なる相関属性２１８1 と「Time (時) 」なる相関属性２１８2 は「Diagnosis(診断）」なる論理フィールド２１０3 と「Test Result(検査結果）」なる論理フィールド２１０6 用のフィールド仕様の一部である。「Fieldref（参照フィールド）」は特定の論理フィールド用の相関属性の定義を提供している。たとえば、「Diagnosis(診断）」なる論理フィールド２１０3 の「Age(年齢）」なる相関属性２１８1 用の「Fieldref（参照フィールド）」は、「AgeAtDiagnosis (診断時の年齢) 」と呼ばれる定義を指している。現在の実施形態では、「AgeAtDiagnosis (診断時の年齢) 」は別の論理フィールド２１０5 であり、それは「Diagnostics(診断）」なるカテゴリ２１６2 の一部でもある。特に、「AgeAtDiagnosis (診断時の年齢) 」なる論理フィールド２１０5 は上で定義した合成フィールドである。現在の例では、合成論理フィールド２１０5 は「Diagnosis Date（診断日）」と「Birth Date（誕生日）」とを入力として受領し、それらのパラメータ値の間の差をとる。このように、「Age(年齢）」なる相関属性は様々な定義をもつ。たとえば、「Test Result(検査結果）」なる論理フィールド２１０6 用に指定されている「Age(年齢）」なる相関属性２１８1 は検査時の年齢（Fieldref="AgeAtTest") に基づいて定義されている。「AgeAtDiagnosis (診断時の年齢) 」なる論理フィールド２１０8 は「Test Date(検査日）」と「Birth Date（誕生日）」とを入力として受領し、その差をとって検査時の年齢を算出する合成フィールドである。
【００５６】
動作中、相関属性（たとえばテーブルＩおよび図３の抽象照会２０２に示したもの）を用いて構成した抽象照会を発行して実行の用に供すると、相関アルゴリズム１５１は数ステップを実行して、当該相関属性の適用先である各条件が当該相関属性をサポートしているか否かを判断する。これは必要なメタデータを定義している、データ・リポジトリ抽象化コンポーネント１４８中の情報と、抽象照会２０２が参照している論理フィールド用のアクセス方式の情報とを用いて行う。特に、データ・リポジトリ抽象化コンポーネント１４８の相関属性１６２を検査して、当該抽象照会の特定の論理フィールド用にサポートされている相関属性を見つける。そして、当該相関属性をサポートしている各論理フィールドごとに、当該抽象照会を表すために作成した実行可能な照会文に追加の述語を付加する。
【００５７】
図３に示したものに対応するデータ・リポジトリ抽象化コンポーネント１４８の例をテーブルＩＩを参照してさらに説明する。この例では、「データ・リポジトリ抽象化」コンポーネントはＸＭＬを用いて定義している。しかし、任意の他の言語を使用してもよい。
【００５８】
〔テーブルＩＩ−データ・リポジトリ抽象化の例〕
001 <DataRepository>
002  <Category name="Demographic">
003   <Field queryable="Yes" Displayable="Yes" name="FirstName">
004    <AccessMethod> 
005     <Simple columnName="f ＿name" tableName="patient"/> 
006    </AccessMethod>
007    <Type baseType="char"/>
008   </Field>
009   <Field queryable="Yes" displayable="Yes" name="LasrName"> 
010    <AccessMethod> 
011     <Simple columnName="l ＿name" tableName="patient"/> 
012    </AccessMethod>  
013    <Type baseType="char"/>
014   </Field>
015   <Field queryable="Yes" displayable="Yes" name="BirthDate">
016    <AccessMethod> 
017     <Simple columnName="b ＿name" tableName="patient"/> 
018    </AccessMethod>  
019    <Type baseType="date"/>
020   </Field>
021  </Category>
022  <Category name="Diagnotics"> 
023   <Field queryable="Yes" Displayable="Yes" name="Diagnosis">
024    <AccessMethod> 
025     <Simple columnName="diag" tableName="patient"/> 
026    </AccessMethod>
027    <Correlation name="Age" fieldRef="AgeAtDiagnosis"/>
028    <Correlation name="Time" fieldRef="DiagnosisDate"/>
029    <Type baseType="char"/>
030   </Field>
031   <Field queryable="Yes" displayable="Yes" name="DiagnosisDate">
032    <AccessMethod> 
033     <Simple columnName="diagdate" tableName="patient"/> 
034    </AccessMethod>
035    <Type baseType="date"/>
036   </Field>
037   <Field queryable="Yes" displayable="Yes" name="AgeAtDiagnosis"> 
038    <AccessMethod> 
039     <Composed>
040      <Composition>YEAR(Field(DiagnosisDate) - Field(BirthDate)) 
041      </Composition> 
042     </Composed> 
043    </AccessMethod>
044    <Type baseType="int"/> 
045   </Field>
046  </Category>
047  <Category name="Tests">
048   <Field queryable="Yes" Displayable="Yes" name="Hemoglobin"> 
049    <AccessMethod> 
050     <Simple columnName="testval" tableName="patient"/>
051    </AccessMethod>
052    <Correlation name="Age" fieldRef="AgeAtTest"/> 
053    <Correlation name="Time" fieldRef="TestDate"/> 
054    <Type baseType="int"/> 
055   </Field>
056   <Field queryable="Yes" displayable="Yes" name="TestDate"> 
057    <AccessMethod> 
058     <Simple columnName="testdate" tableName="patient"/> 
059    </AccessMethod>
060    <Type baseType="date"/>  
061   </Field>
062   <Field queryable="Yes" displayable="Yes" name="AgeAtTest">
063    <AccessMethod> 
064     <Composed>
065      <Composition>YEAR(Field(TestDate) - Field(BirthDate))
066 </Composition>
067     </Composed> 
068    </AccessMethod>  
069    <Type baseType="int"/> 
071   </Field>
072  </Category>
073  </DataRepository>
【００５９】
実行時コンポーネント１５０が抽象照会を処理する一実施形態を図５〜図７を参照して説明する。照会を処理する方法３００はステップ３０２において開始する。ステップ３０２において、実行時コンポーネント１５０が抽象照会を受領して処理の用に供する。また、実行時コンポーネント１５０は当該抽象照会のインスタンスを読み込んで解析し、個別の選択基準、相関基準、および適切な結果フィールドを確認する。ステップ３０４において、当該抽象照会に存在する各相関基準ごとにループに入り、それを実行する。ステップ３０６において、実行時コンポーネント１５０は当該相関が範囲型の相関（すなわち各データ・エンティティ間の時間間隔に基づいてデータ・エンティティ群を相関させる相関）であるか否かを判断する。たとえば、図３に示す抽象照会は「Span(Time)<5 (時間範囲＜５）」なる相関基準を含んでいる。「Span(Time)<5 (時間範囲＜５）」は（当該相関基準の適用先である）当該抽象照会のデータ・エンティティが互いに５単位時間（たとえば５日）以内になければならない、ということを示している。（ステップ３０６において）当該基準が範囲型の基準である場合、当該基準を範囲基準リスト１７０（図１も参照）に付加する（ステップ３０８）。次いで、方法３００はステップ３０４に戻り、次の相関基準用の処理を開始する。（ステップ３０６において）当該基準が範囲型の基準ではない場合、当該基準を個別基準リスト１７２（図１も参照）に付加する（ステップ３１０）。次いで、方法３００はステップ３０４に戻り、次の相関基準用の処理を開始する。
【００６０】
当該抽象照会に存在する相関基準の各々を処理したら、方法３００はステップ３１２に進む。ステップ３１２において、選択基準を有する条件ごとループに入る。次に示す点を想起されたい。すなわち、一実施形態では、条件は（論理フィールド用の）フィールド名、比較演算子（＝、＞、＜など）、および（当該フィールドの比較対象である）値式から成る。ステップ３１４において、実行時コンポーネント１５０は抽象照会に存在する条件中のフィールド名を用いてデータ・リポジトリ抽象化１４８中に存在する当該フィールドの定義を探索する。次いで、実行時コンポーネント１５０は処理中の論理フィールド用の「実行可能照会寄与部（Executable Query Contribution)」を構築する。ここで定義しているように、「実行可能照会寄与部」は現在の論理フィールドに基づいてデータの選択を行うために使用する実行可能照会の一部分である。実行可能照会とはＳＱＬや「ＸＭＬ  Ｑｕｅｒｙ」のような言語で表した照会のことであり、所定の物理データ・リポジトリ（たとえばリレーショナル・データベースやＸＭＬリポジトリなど）のデータと整合している。したがって、実行可能照会は図１に示すＤＢＭＳ１５４によって代表される物理データ・リポジトリ中のデータの所在を特定し、当該データを検索・取得するために使用する。次いで、現在のフィールド用に生成した「実行可能照会寄与部」を「実行可能照会文（Executable Query Statement) 」に付加する（ステップ３１８）。
【００６１】
ステップ３２０において、実行時コンポーネント１５０は処理中の条件のフィールドが、範囲基準リスト１７０中の相関基準に対応する相関属性を（すなわち（i.e.）データ・リポジトリ抽象化コンポーネント１４８中に）有するか否かを判断する。ＹＥＳなら、当該フィールドを範囲フィールド・リスト１７４に付加する（すなわち３２２）。一実施形態では、各型の範囲相関属性（すなわち（i.e.）「Span(Time)（時間範囲）」用のあるリスト、「Span(Location)（場所範囲）」用の別のリスト、など）ごとに範囲フィールド・リスト１７４を設けている。しかし、別の実施形態では、このステップにおいて単一の範囲フィールド・リストを作成し、個別の範囲相関基準を処理する（この処理については後述する）ときに、このリストからフィールドのサブセットを選択する。次いで、方法３００はステップ３１２に戻り、次の選択基準条件の処理を開始する。しかし、ステップ３２０の結果がＮＯの場合には、プロセスはステップ３２４に進む。ステップ３２４において、実行時コンポーネント１５０は処理中のフィールドが、個別基準リスト１７２中の相関基準に対応する相関属性を（すなわち（i.e.）データ・リポジトリ抽象化コンポーネント１４８中に）有するか否かを判断する。ＮＯなら、プロセスはステップ３１２に戻る。ＹＥＳなら、処理中のフィールド用の相関属性をデータ・リポジトリ抽象化コンポーネント１４８から検索・取得する（ステップ３２６）。次いで、ステップ３２８において、実行時コンポーネント１５０は上記相関基準と上記フィールドの相関属性の定義から照会述語を構築する。次いで、当該述語を上記実行可能照会に付加する（ステップ３３０）。次いで、プロセスはステップ３１２に戻る。
【００６２】
ステップ３１２において入ったループによる選択基準の条件の各々の処理が完了したら、方法３００はステップ３３２に進む。ステップ３３２において、範囲フィールド・リスト１７４中のフィールドから成る対（すなわち同一の相関属性を定義する根拠をなすフィールド群から成る順番に依存しない順列）の各々ごとにループに入る。次いで、ステップ３３４において、実行時コンポーネント１５０は上記対中の各フィールドごとに相関属性のフィールド定義を（すなわち（i.e.）データ・リポジトリ・ディストラクション（distraction)コンポーネント１４８から）検索・取得する。次いで、ステップ３３６において、実行時コンポーネント１５０は各フィールド属性定義の間の絶対差（たとえばABS(DAYS(testdate - diagdate))）を算出する値式を構築する。この式は範囲基準と組み合わせて、フィールド対を含む範囲照会述語（たとえばABS(DAYS(testdate - diagdate))>5）を形成している。次いで、この述語を上記実行可能照会に付加する（ステップ３４０）。次いで、プロセスはステップ３３２に戻り、範囲フィールド・リスト１７４中のフィールド群から成る次の対に備える。フィールド群から成る各対の処理が完了したら、方法３００は終了する。このとき、上記照会は実行の準備ができている。
【００６３】
ステップ３１６とステップ３２８に従って論理フィールド用の「実行可能照会寄与部」を構築する方法４００の一実施形態を図８を参照して説明する。ステップ４０２において、方法４００は現在の論理フィールドに付随するアクセス方式が単純アクセス方式であるか否かを調べる。ＹＥＳなら、物理データの所在情報に基づいて「実行可能照会寄与部」を構築した後（ステップ４０４）、上述した方法３００に従って処理を継続する。ＮＯなら、プロセスはステップ４０６に進み、現在の論理フィールドに付随するアクセス方式がフィルタリング済みアクセス方式であるか否かを調べる。ＹＥＳなら、何らかの物理的なデータ・エンティティ用に、物理データの所在情報基づいて「実行可能照会寄与部」を構築する（ステップ４０８）。次いで、ステップ４１０において、上記物理的なデータ・エンティティに付随するデータをサブセット化するのに使用する追加の論理（フィルタの選択）を用いて当該「実行可能照会寄与部」を拡張する。次いで、プロセスは上述した方法３００に従って継続する。
【００６４】
当該アクセス方式がフィルタリング済みアクセス方式ではない場合、プロセスはステップ４０６からステップ４１２に進む。ステップ４１２において、方法４００は当該アクセス方式が合成アクセス方式であるか否かを判断する。当該アクセス方式が合成アクセス方式である場合、合成フィールド式中の各サブフィールド参照用の物理データの所在を確認し、それらを検索・取得する（ステップ４１４）。次いで、ステップ４１６において、当該合成フィールド式の論理フィールド参照に、当該合成フィールド式の物理フィールドの所在情報を代入する。この結果、「実行可能照会寄与部」が作成される。次いで、プロセスは上述した方法３００に従って継続する。
【００６５】
当該アクセス方式が合成アクセス方式ではない場合、プロセスはステップ４１２からステップ４１８に進む。ステップ４１８は本発明の実施形態として考えられるすべての他のアクセス方式を代表している。しかし、利用可能なアクセス方式のすべては実装しない実施形態が考えられる、という点を理解すべきである。たとえば、ある特定の実施形態では、単純アクセス方式だけを使用する。別の実施形態では、単純アクセス方式とフィルタリング済みアクセス方式だけを使用する。
【００６６】
上述したように、照会条件中の論理フィールド参照は相関属性と、照会条件フィールド用の所定の相関属性の解釈の仕方を定義する別の論理フィールドを特定する「FieldRef（フィールド参照）」とを定義することになる。図８の方法４００は「参照済み」の論理フィールドと相関属性に付随する論理とを用いて実行する。たとえば、相関基準が「Age>50（年齢が５０歳を超えている）」であり、「Test（検査）」なるフィールドが「AgeAtTest(検査時の年齢）」の「FieldRef（フィールド参照）」を備えた「Age(年齢）」用の定義を含んでいる場合、方法４００は「AgeAtTest>50（検査時の年齢が５０歳を超えている）」なる条件に基づいて照会述語を構築する。
【００６７】
上述したように、論理フィールドが基をなす物理データとは異なるデータ・フォーマットを指定している場合には、データの変換を行う必要がある。一実施形態では、論理フィールド用の「実行可能照会寄与部」を方法４００に従って構築するときに、個別のアクセス方式ごとに始めの変換を行う。たとえば、この変換はステップ４０４、４０８、４１６の一部として、あるいはそれらの直後に行う。次いで、ステップ３２２において照会を実行した後に、物理データのフォーマットから論理フィールドのフォーマットへの次の変換を行う。無論、論理フィールドの定義のフォーマットが基をなす物理データと同一である場合には、変換は必要ない。
【００６８】
上述した例は医療分野に関するものである。そして、相関属性は時、場所、および年齢について説明している。しかし、本発明はそのように限定されず、あらゆるデータベース環境、あらゆる種類のデータへの拡張が考えられる。たとえば、上述したように、照会オペレーションに関連す様々なエンティティの他の諸特性（たとえば色、重さ、体積、長さ、幅など）を考慮した相関属性を定義することができる。いま、対応するデータ抽象化コンポーネントが定義された次に示す抽象照会（テーブルＩＩＩ）を考える。
【００６９】
〔テーブルＩＩＩ−  抽象照会の例〕
001 <QueryAbstraction>
002  <Selection>
003   <Condition field="CarpetType="EQ" vale="berber"/> 
004   <Condition field="WallpaperPattern" operator="EQ" value="floral"
005 reOperator="AND"/>
006   <Condition field="PaintFinish" operator="EQ" value="satin"reOperator="AND"007   />
008   <Correlation attribute="Span(Color)" operator="LT" value="10"/> 
009  </Selection> 
010  <Results>
011   <Field name="CarpetNumber"/>
012   <Field name="WallpaperNumber"/> 
013   <Field name="PaintNumber"/> 
014  </Results>   
015 </QueryAbstraction> 
【００７０】
この抽象照会は絨毯（じゅうたん）、壁紙、およびペンキの組み合わせから成る１つの組を絨毯の種別、壁紙の模様、およびペンキ仕上げの種別用に指定した基準に基づいて選択するように設計されている。ここに示した各エンティティ（絨毯、壁紙、ペンキ）が「color(色）」の相関属性を定義しているものと仮定すると、「Span(Color)<10 (色範囲が１０未満) 」なる相関条件は選択された組み合わせを色が類似のものに限定することになる。したがって、「Span(Color)(色範囲）」用の定義として可能なものは「Red(赤) 」、「Green(緑) 」、および「Blue (青) 」の含有量が各々「ｎ」単位以内である色におけるＲＧＢ（赤、緑、青）値になる。
【００７１】
したがって、データ・リポジトリ抽象化コンポーネント１４８によって様々な利点が得られる。一側面では、アプリケーションによる照会の指定と基をなすデータの表現との間の結合を緩やかに定義していることにより、利点が得られる。つまり、ＳＱＬを使用する場合のように特定の表、列、および関係の情報を用いてアプリケーションをエンコードするのではなく、アプリケーションはデータを照会する要件を、後ほど実行する時に特定の物理データ表現に結び付けるという、より抽象的な態様で定義する。本発明では照会−データ間の結合が緩やかであるから、要求元エンティティ（たとえばアプリケーション）は、たとえ基をなすデータの表現が変更されても、あるいは、要求元エンティティを開発した時に使用した物理データ表現を完全に新しくした物理データ表現によって当該要求元エンティティを使用すべき場合であっても機能することが可能になる。所定の物理データ表現を変更または再構成する場合には、対応するデータ・リポジトリ抽象化を更新して、基をなす物理データ・モデルになされた変更を反映させる。以前と同じ組の論理フィールドが照会による使用の際に利用可能である。それらは物理データ・モデル中の異なるエンティティまたは場所に結び付けられているにすぎない。この結果、抽象照会インタフェースに書き込まれた要求元エンティティは、たとえ対応する物理データ・モデルが大幅に変更されても、不変のまま機能し続ける。要求元エンティティを開発した時に使用した物理データ表現を完全に新しくした物理データ表現によって当該要求元エンティティを使用すべき場合には、同じ技術（たとえばリレーショナル・データベース）を使用するが、異なる命名と情報の構成の戦略（たとえば異なるスキーマ）に従って新たな物理データ・モデルを実装する。新たなスキーマは単純アクセス方式、フィルタリング済みアクセス方式、および合成フィールド・アクセス方式の手法を使用するアプリケーションが必要とする論理フィールドの組にマップする情報を含むことになる。あるいは、新たな物理表記では、類似の情報を表記する別の技術を使用する（たとえば、リレーショナル・データベース・システムに対してＸＭＬに基づいたデータ・リポジトリを使用する）。いずれにしても、照会中で参照されるフィールドを新たな物理データ・モデル中の場所と物理表現にマップする別のデータ・リポジトリを備えることにより、抽象照会インタフェースを使用するように書かれている既存の要求元エンティティは新たな物理データ表現を使用することに容易に移行することができる。
【００７２】
また、抽象照会および基をなすデータの抽象化モデルとともにグローバル（大域的）な相関属性を使用すると、高度なデータの相関付けと分析を含む、複雑なデータの照会論理を記述するのがきわめて簡単になる。さらに、基本データを選択する論理を相関付けを行う論理から分離すると、基本的には同一であるが相関条件が様々である照会を迅速に再利用することが可能になる。
【００７３】
エンド・ユーザについては、データ・リポジトリを抽象化することにより、相関付けされているデータの照会を表現することに付随する複雑性の大部分を無くすことができる。特に、エンド・ユーザは所定の相関付け法をサポートしている照会選択条件はどれなのか、ということについてもはや心配する必要はない。そして、エンド・ユーザは照会に含まれている新たなエンティティごとにイベントに基づいた論理、および／または、エンティティに基づいた論理（たとえば時間に基づいた論理、場所指向の論理など）を表現する方法を理解しなければならない、ということについてもはや重荷を担う必要はない。
【００７４】
データ・リポジトリ抽象化モデルを使用すると、これらの利点および他の利点が得られるけれども、強調すべき点を挙げると、当業者が容易に認識しうるように、相関属性の目的と機能はデータ・リポジトリ抽象化コンポーネント１４８とは切り離して実装することができる。たとえば、ＳＱＬに基づいた照会の実装が使用する表と列に関する情報を補う追加のメタデータを備えた実施形態である。この場合、所定の列用のメタデータによって、相関属性（たとえば「Age(年齢) 」と当該列中に示されているエンティティ用の年齢を算出する方法を特定する、関連付けられたＳＱＬによる照会式とを特定する。次いで、ＳＱＬ照会のプリプロセッサが始めのＳＱＬ照会と少なくとも１つの相関条件とを入力として取り込み、取り込んだ相関条件の根拠をなす追加の述語を用いて当該ＳＱＬ照会を補強する。これを行うには、相関条件群から成る組に属す相関属性（群）をサポートしている列に対する参照を詳しく調べ、特定の相関属性の所定の列の定義用に定義された照会式に基づいて、追加の「ＳＱＬ  ＷＨＥＲＥ」文節の述語を作成する。
【００７５】
留意点を挙げると、ここでは特定の値、定義、プログラミング言語、および例を参照しているが、それらはすべて単に説明を目的としたものにすぎない。したがって、本発明は特定の説明および例によって限定されない。また、ＳＥＬＥＣＴＩＯＮ（選択）なるオペレーションを参照して本発明の諸側面を説明しているが、他の入出力オペレーション（たとえばＡＤＤ（追加）、ＭＯＤＩＦＹ（変更）、ＩＮＳＥＲＴ（挿入）、ＤＥＬＥＴＥ（削除）などの周知のオペレーション）も考えられる。無論、アクセス方式によっては、当該特定のアクセス方式を利用するフィールドを用いて定義しうる抽象照会の機能の種別に制限が課される。たとえば、合成アクセス方式に関連するフィールドはＭＯＤＩＦＹ（変更）、ＩＮＳＥＲＴ（挿入）、およびＤＥＬＥＴＥ（削除）の実行可能なターゲット（目標）ではない。
【００７６】
上述した事項は本発明の実施形態に関するが、本発明の基本的な範囲の内で本発明の他の実施形態とさらなる実施形態とを案出することができる。したがって、本発明の範囲は特許請求の範囲によって確定される。
【図面の簡単な説明】
【００７７】
【図１】コンピュータ・システムの一実施形態を示す図である。
【図２】本発明の一実施形態のソフトウェア・コンポーネントの論理的／物理的な概観を示す図である。
【図３】抽象照会とデータ・リポジトリ抽象化の論理的な概観を示す図である。
【図４】抽象照会とデータ・リポジトリ抽象化の論理的な概観を示す図である。
【図５】実行時コンポーネントのオペレーションを示すフローチャートを示す図である。
【図６】実行時コンポーネントのオペレーションを示すフローチャートを示す図である。
【図７】実行時コンポーネントのオペレーションを示すフローチャートを示す図である。
【図８】実行時コンポーネントのオペレーションを示すフローチャートを示す図である。
【符号の説明】
【００７８】
１００  システム
１１０  ＣＰＵ
１１２  メモリ
１１４  記憶装置
１１６  入力装置
１１８  ネットワークＩ／Ｆ
１１９  出力装置
１２２  ブラウザ・プログラム
１２４  オペレーティング・システム
１３０  ＣＰＵ
１３２  メイン・メモリ
１３８  オペレーティング・システム
１４０  アプリケーション
１４２  アプリケーション照会仕様
１４６  抽象照会Ｉ／Ｆ
１４８  データ・リポジトリ抽象化コンポーネント
１５０  実行時コンポーネント
１５１  相関アルゴリズム
１５２  ＨＴＴＰサーバ
１５４  ＤＢＭＳ
１６２  相関属性
１７０  範囲基準リスト
１７２  個別基準リスト
１７４  範囲フィールド・リスト
２００  コンポーネント群の模式的な関係
２０２  抽象照会
２０３  相関基準
【図１】
0004410681.tif 000002
【図２】
0004410681.tif 000003
【図３】
0004410681.tif 000004
【図４】
0004410681.tif 000005
【図５】
0004410681.tif 000006
【図６】
0004410681.tif 000007
【図７】
0004410681.tif 000008
【図８】
0004410681.tif 000009