JP2005534119A - データを統一する方法およびシステム - Google Patents

Abstract

産業ディメンション毎にノードを備えるデータベース（ＵｎｉＤｉｍＮｅｔ）が作成される。このシステムからアクセス可能な各データソースのために、データソースの特定ディメンションのセットが作成され、対応する産業ビジネスコンテクストのディメンションにマッピングされる。テンプレートのセットが作成されてデータソースにクエリーをかける。各ＵｎｉＶｉｅｗは、特定データソースに設計された特定ディメンションのための特定質問を含む。ＵｎｉＶｉｅｗは関連するデータベースに、そのデータアクセスメカニズムを用いてクエリーをかける。中央サーバがシステムを調製し、インターフェース（ＵｎｉＶｉｅｗｅｒ）によってシステムの使用を容易にする。ＵｎｉＶｉｅｗｅｒにより、ユーザは、産業ビジネスコンテクストのディメンション、ディメンション事例、および少なくとも１つのＵｎｉｖｉｅｗを特定してデータソースにクエリーをかける。

Description

（関連出願へのクロスレファレンス）
本出願は、２００２年７月２６日出願の米国仮特許出願第６０／３９８，８４１号の利益をクレームする。

（本発明の技術分野）
本発明は、データベース管理技術に関する。特に、複数のデータベースの不均一データにアクセスする方法とシステムとに関する出願である。

近代ビジネスの多くは、大量のデータを収集し記憶する異なるソフトウェアアプリケーションを複数用いる。これらアプリケーションは、複数の異なる方法（たとえば、カード型データベース、関係型データベース、またはオブジェクトデータベース）で、かつ当該のアプリケーションに特定の形式（たとえば、２進法ファイル形式）でデータを記憶する。このデータへのアクセスは、多様な異なるメカニズムから達成され、（たとえば、直接データベースクエリー、様々な報告ツール、またはアプリケーションプログラムインターフェース（「ＡＰＩ」）を介してアクセスでき）それぞれは異なるレベルの柔軟性、使い易さ、データに内在するビジネスコンセプトへの一貫性を提供する。このデータは一般的に不均一であるが、概してデータベースを推進し追加する、内在するビジネスコンセプトという点では関連性がある。

そのようなビジネスにとって、このデータ全てをまとめあげ、中央でそれにアクセスすることが一般的に所望されており、異なるアプリケーションからのデータが一つにまとまることにより、複数でかつ異なるアプリケーションをスパン（ｓｐａｎ）し、さらに内在するビジネスコンセプトに関連する全体像を提供するビューが与えられる。しかしながら、このように集めることは困難である。なぜならば、各データソースは固有かつ個別の方法で記憶されたデータを有し得、他のデータソースの方法とハードウェアとは互換性があるとは限らない持続性ハードウェアのある形式で記憶され得るからである。さらに、このデータの実際の形式は、通常、非常に複雑であり、かつ直接ビジネス関連のものではなく、複数のデータソースのデータを集める、つまり統一する困難さを増幅する。

これら困難さを軽減しようと試みるためには、各データソースはデータアクセスメカニズムのある形式（たとえば、予め設計されたクエリーセットやＡＰＩセット）を提供することによりそれ自身へのアクセスを容易にすることが所望される。これらメカニズムにより、各データソースに記憶された未加工データよりもビジネスセンスにおいてより抽象的で意味のある情報のセットまたはサブセットへのアクセスが提供される。たとえば、予め設定されたクエリーはデータベースにクエリーをかけることにより、特定の個人に関する全ての情報を検索し、その個人に該当する情報のみを返す。このようなデータアクセスメカニズムは１つのデータベース（もしくは、少なくとも共通タイプのデータベース）からビジネス関連情報を取得することには有益であるが、このようなデータアクセスメカニズムは、このデータベースに関するアプリケーションに限定される。特定のデータアクセスメカニズムの設計と技術仕様とは一般的に、他の特定のデータアクセスメカニズムの設計と技術仕様とから顕著に異なる。したがって、特定のデータベースのデータアクセスメカニズムは、近代ビジネスの情報格納を作り上げる多くのバラバラなデータベースはおろか、異なるデータベースにとっても有効ではないと思われる。このようなアクセスメカニズムは、複数のデータベースをスパンし、さらに内在するビジネスコンセプトに関する全体像を促進するビューを円滑にすることに容易には適応いない。

したがって、複数の不均一データベースからデータを統一する方法とシステムとを提供する必要があり、ここで、各データベースはビジネスコンテクストに関連するデータとデータアクセスメカニズムとを有する。

本発明の一実施形態に従って、複数の産業ビジネスコンテクストディメンションを有する産業に関するデータを統一するシステムが提供される。このシステムは、複数のデータソースを含み、各データソースは少なくとも１つのデータソース特定ディメンションにグルーピングすることができるデータと、少なくとも他の１つから異なる物理的かつロジック的構造を有する少なくとも１つのデータソースを有する。このシステムはさらに、第１の複数のノードと第２の複数のノードとを有するデータベースを含み、第１の複数のノードのそれぞれは産業ビジネスコンテクストディメンションを表し、第２の複数のノードのそれぞれはデータソース特定ディメンションを表す。このシステムはまたさらに、複数のデータソースクエリー機能呼出しを含み、各呼出しは１つのデータソース特定ディメンションに関する１つのデータソースにクエリーをかける。

本発明の別の実施形態に従って、複数のデータソースのデータを管理するシステムが提供される。このシステムは、ＵｎｉＤｉｍＮｅｔと複数のＵｎｉＶｉｅｗとを備える。ＵｎｉＤｉｍＮｅｔは、産業ビジネスコンテクストディメンションを表す複数のＵｎｉＤｉｍと、各データソースのデータソース特定ディメンションを表す複数のＤａｔａＳｏｕｒｃｅＤｉｍとを備える。各ＵｎｉＤｉｍは、少なくとも１つの他のＵｎｉＤｉｍに関連しており、各ＤａｔａＳｏｕｒｃｅＤｉｍは、少なくとも１つのＵｎｉＤｉｍに関連する。ＵｎｉＶｉｅｗは組み合わさることにより複雑なクエリーになり得る。複雑なクエリーは入力パラメーターセットを有し得、このパラメーターには特定のデータソースの識別は含まれない。

本発明のさらに別の実施形態に従って、複数のデータソースのデータを管理する方法が提供される。この方法は、複数の産業ビジネスコンテクストディメンションを識別し、データソース毎に少なくとも１つのデータソース特定ディメンションを識別し、ＵｎｉＤｉｍＮｅｔを提供し、複数のＵｎｉＶｉｅｗを提供し、複雑なクエリーを立て（ｆｏｒｍｕｌａｔｅ）、そしてそのクエリーの結果を提供するステップを含む。

本発明のまた別の実施形態に従って、複数のデータソースのデータにクエリーをかける方法が提供される。この方法は、クエリーをかけられるディメンションを受け取り、複数のデータソースクエリー機能呼出しを提供してそこから選択し、その選択された機能呼出しから定義されるカラムを含む結果セットを作成し、少なくとも１つのディメンション事例の識別を受け取ってクエリーをかけ、そしてカラムにクエリーの結果を追加するステップを含む。

本発明の利点は、不均一データを含む複数のデータソースが統一されクエリーをかけられ得るということである。本発明のさらなる利点は、異なるロジック的または物理的構造を有する複数のデータソースが、データソース毎に提供されるデータアクセスメカニズムを用いて、１つのシステムによってクエリーをかけられ得るということである。本発明のさらに別の利点は、データソースのための複雑なクエリーが作成され、修正され、およびデータソース完全セットに亘って実行され得ることである。さらに別の利点とし、複数のデータソース内の関連したデータは、クエリーの各特定のデータソースを識別せずにクエリーをかけられ得るということである。

本発明のこれら局面および利点と、これ以外の局面および利点とは、以下の好ましい実施形態の説明と、添付の図面を参照することから当業者にとって明白である。

（発明の詳細な説明）
明細書に取り込まれており、その一部を構成する添付の図面において、本発明の実施形態は図示されており、これは前記の本発明の一般的な記載と以下の詳細な記載と共に、本発明の原理を例示する。

以下で、開示を通して使用される例示的な用語の定義をする。提示する目的のためのみであって、ここで記載する本発明の開示を制限するためではなく、例示的な産業および例示的なデータベースのグループがここで使用されることにより、本発明のある実施形態の例を解説する。例示的な産業は製薬産業であり、特に、臨床試験およびある患者に対するある薬に関する臨床試験の評価に関連するような製薬産業である。

製薬産業において、スポンサーは、特にＦＤＡ（食品医薬品局認定）を受けるために、試験される薬（または他の医療用具）を有することを所望する事業体（たとえば、薬または医療用具会社）である。そのような試験は、１つ以上の臨床試験または研究として行われる。各研究は一般的に、１人以上の患者が試験的に薬を使用する１つ以上の場所（たとえば、特定の病院や医者の演習グループ）を取り込む。患者に関する記録と、患者の症状を含めた薬の使用に関する記録とがつけられる。そのような記録は、しばしば、ソフトウェアアプリケーションの電子データ収集（「ＥＤＣ」）のパッケージソフトを介して電気的に収集され、関連するデータベースに記憶される。この例は臨床試験と製薬産業という点から説明されるが、当業者は容易に、本発明はここで述べられるような複数の不均一データベースを用いる任意の産業に適用されるということを理解する。

以下の例示的な用語の定義において、全ての用語の単数形と複数形との両方はそれぞれの意味に含まれる。全ての用語の大文字と小文字とは、別に記載されている場合を除き、それぞれの意味に含まれる。

ここで使用される「データ」は総称的に使用されており、これは、この限りではないが、コンピュータで処理するのに適した形式の情報を含む。別に記載されている場合を除き、「データ」は、データソースに含まれる、もしくは含まれることが可能である（以下で規定されるように）情報（操作上のものとレガシー（ｌｅｇａｃｙ）とを含む）である。製薬産業の例において、「データ」は、この限りではないが、身長、体重、性別、および年齢といった個々の患者情報、特定のＥＤＣ応答といった研究情報、および薬の同一性（ｉｄｅｎｔｉｔｙ）といった研究情報を含む。

ここで使用される「データソース」は総称的に使用されており、これは、この限りではないが、データベースおよび／または、データを提供および／または記憶するソフトウェアアプリケーションを含む。製薬産業の例においては、「データソース」は、スポンサー、場所、研究、患者、もしくは製薬産業に関連するその他の事業体に関する情報を含むデータベースである。

ここで使用される「データソース事例」は、データソースの特定のインストレーション（ｉｎｓｔａｌｌａｔｉｏｎ）である。製薬産業の例においては、「データソース事例」は、本発明のシステムからアクセスされるデータソースの実際のインストレーションである。たとえば、本発明のシステムから以前にアクセスされなかった研究情報を含むデータベースは、このシステムに対する新しい「データベース事例」とみなされる。

ここで使用される「データアクセスメカニズム」は、「データ検索メカニズム」と互換性を有して使用されており、かつ総称的に使用されており、これは、この限りではないが、ソフトウェアアプリケーションまたは、データソースからデータにアクセスし、かつデータを検索することを容易にするソフトウェアアプリケーションのモジュールを含む。一般的に、データアクセスメカニズムは、それが関連するデータベースおよび／またはソフトウェアアプリケーション（または、データベースタイプやソフトウェアアプリケーションタイプ）に限定されており、これはカスタマイズされることによりクエリーに応答して同様にアクセスする。例示的なデータアクセスメカニズムは、この限りではないが、予め設計されたデータベースクエリー、予め設計されたデータベースビュー、およびアプリケーションプログラムインターフェース（ＡＰＩ）のセットを含む。

ここで使用される「ディメンション」は、産業内の特定のロジックコンセプトである。製薬産業の例においては、「ディメンション」は、この限りではないが、「スポンサー」、「研究」、「場所」、および「患者」を含み、これらはそれぞれ、製薬産業内の特定のロジックコンセプトを定義する。この例においては、「ディメンション」は特定の相互関係のある産業コンセプト（たとえば、臨床試験のスポンサー、特定薬の研究、薬が試験される場所、および研究に参加する患者）に対応する相互関係のある実体（たとえば、スポンサー、研究、場所、および患者）のセットに概念化して説明され得る。

ここで使用される「産業ビジネスコンテクスト」は、産業に関するデータを定義するディメンションのセットである。製薬産業の例においては、「産業ビジネスコンテクスト」は、製薬産業に関する全てのデータを定義し、かつ本発明のシステムまたは方法からアクセスすることができるディメンションセットである。一般的に言って、製薬産業によって定義され、かつ本発明の方法またはシステムからアクセスできるデータ完全セットは、ロジックコンセプト（ディメンション）にグルーピングもしくは分類され、このデータ完全セットは製薬産業の産業ビジネスコンテクストを定義する。

ここで使用される「産業ビジネスコンテクストディメンション」は、「ディメンション」と互換性を有して使用される。

ここで使用される「ディメンション事例」は、ディメンションの特定の実施形態（または記録）である。製薬産業の例において、「患者」がディメンションである場合、患者（たとえば、Ｊｏｅ Ｓｍｉｔｈ）である特定人物が、そのディメンションの「ディメンション事例」である。

ここで使用される「データソース特定ディメンション」は、データソース内の特定のロジック的コンセプトである。実施形態において、「データソース特定ディメンション」は、データソースに記憶される未加工データよりも、ビジネスの観点からより抽象的で意味のあるデータソース内に含まれるデータセットまたはサブセットである。製薬産業の例においては、特定のデータベースは特定の研究からのデータを含み、これは、研究場所、研究される患者、および研究からのＥＤＣ応答に関するデータを含む。この例において、「データソース特定ディメンション」は、データソースのデータに対応し、かつ特定のデータソースのために定義される相互関係のある実体（たとえば、「研究」、「場所」、「患者」、および「ＥＤＣ応答」）のセットに概念化して説明され得る。実施形態においては、「データソース特定ディメンション」は、データソースもしくは複数のデータソースから検索され得る概念的に関連するデータのセットである。

ここで使用される「データソースビジネスコンテクスト」は、特定のデータソースのデータを定義するデータソース特定ディメンションのセットである。一般的に言って、データソースに含まれるデータ完全セットは、ロジック的コンセプト（データソース特定ディメンション）にグルーピングもしくは分類され、このデータ完全セットは、データソースの「データソースビジネスコンテクスト」を定義する。

ここで使用される「ロジック」は総称的に使用されており、この限りではないが、機能するためのハードウェア、ソフトウェアおよび／または両者の組み合わせを含む。

ここで使用される「ソフトウェア」は総称的に使用されており、この限りではないが、１つ以上のコンピュータによる実行可能なインストラクション、ルーチン、アルゴリズム、モジュール、または別々のアプリケーションを含むプログラムもしくはここで記載されるように機能するためのダイナミックにリンクされたライブラリからのプログラムを含む。ソフトウェアはまた、サブレット、アプレット、スタンドアロン、プラグイン、または他タイプのアプリケーションといった様々な形式で実行され得る。ソフトウェアは、この技術分野で周知の通り、多様なコンピュータによる読み取り可能な媒体に維持され得る。

ここで使用される「ネットワーク」は総称的に使用されており、この限りではないが、インターネット、イントラネット、広域ネットワーク、ローカルエリアネットワーク、および変調器−復調器（モデム）を用いる変換器リンクを含む。

一実施形態において、本発明は、複数の不均一データベースからのデータを統一するシステム、方法、およびデータベース設計に関し、これら複数の不均一データベースは、ビジネスコンテクスト関連のデータとデータアクセスメカニズムとを有する。産業ディメンション毎にノードを備えるデータベース（ＵｎｉＤｉｍＮｅｔ）が作成される。このシステムからアクセス可能な各データソースのために、データソース特定ディメンションのセットが作成され、対応する産業ビジネスコンテクストのディメンションにマッピングされる。テンプレートのセット（たとえば、ＵｎｉＶｉｅｗ）が作成されてこのデータソースにクエリーをかける。各ＵｎｉＶｉｅｗは、特定のデータソースのために設計された特定のディメンションのための特定の質問を含む。ＵｎｉＶｉｅｗは、Ｕｎｉｖｉｅｗが関連するデータベースに、その関連したデータベースのデータアクセスメカニズムを用いることによって、クエリーをかける。中央サーバ（ＵｎｉＳｅｒｖｅｒ）はこのシステムを調製し、インターフェース（ＵｎｉＶｉｅｗｅｒ）によってこのシステムの使用を容易にする。ＵｎｉＶｉｅｗｅｒにより、ユーザは産業ビジネスコンテクストディメンション、ディメンション事例、および少なくとも１つのＵｎｉｖｉｅｗを特定することによってデータソースにクエリーをかけることができる。複数のＵｎｉＶｉｅｗが組み合わさり、キャッシュされ、そして保存されることにより複雑なクエリーを容易にすることができる。本発明は、製薬産業の臨床試験に関連する例示的なデータベースセットを参照して説明されるが、当業者は容易に、本発明は、たとえば、給料支払簿または企業の人材アプリケーションを含む不均一データベースの管理における、複数の不均一データベースの管理を含む任意のタイプのデータベース管理設定において適用されるということを理解する。

図１を参照して、本発明のデータを統一するシステム１００の概略が図示される。この実施形態においては、システム１００はＵｎｉＢａｓｅ１１０、ＵｎｉＳｅｒｖｅｒ１２０、および少なくとも１つのデータソース１３０を含み、さらに、Ｎｏｔｉｆｉｅｒ１４０、ＵｎｉＢｕｉｌｄｅｒ１５０、およびＵｎｉＶｉｅｗｅｒ１６０のいずれか、もしくは全てを含み得る。システム１００は、本技術分野において周知の任意の適切なコンピュータ、コンピュータシステム、もしくはコンピュータシステムの関連グループ上に存在する。一実施形態において、ＵｎｉＢａｓｅ１１０とＵｎｉＳｅｒｖｅｒ１２０とは、中央サーバ上にある。Ｎｏｔｉｆｉｅｒ１４０、ＵｎｉＢｕｉｌｄｅｒ１５０、およびＵｎｉＶｉｅｗｅｒ１６０もまた、任意で中央サーバ上にある。データソース１３０は、任意で、中央サーバ上、リモートコンピュータ上、もしくはリモートコンピュータシステム（図示せず）に位置づけされる。ここで開示される任意のエレメントがこのシステムの他のエレメントから隔離したコンピュータもしくはコンピュータシステム上に位置づけされる一実施形態において、適切な電子接続は、この限りではないが、ネットワーク接続を含み、リモートエレメント間に構築されることにより、リモートエレメント間の通信を容易にする。任意の適切なネットワークまたは他の通信方法が使用され得る。システム１００は、データベース管理とＳＱＬとを含む、任意の適切なプログラミング言語もしくはプログラミング言語を組み合わせたもので具体化される。

図２を参照して、本発明のシステム１００はＵｎｉＢａｓｅ１１０を含む。ＵｎｉＢａｓｅ１１０は、ＵｎｉＤｉｍＮｅｔ２１０および、任意で、ＵｎｉＶｉｅｗ表２２０とキャッシュしたＵｎｉＶｉｅｗの結果２３０を記憶し、それらへのアクセスを容易にする。ＵｎｉＢａｓｅ１１０は、データを記憶するのに任意の適切なデータベースであり、この限りではないが、オラクルから提供されるデータベースソフトウェアを含む、任意の適切なデータベースプログラムにおいて具体化される。

図３を参照すると、ＵｎｉＤｉｍＮｅｔ２１０は全ての産業ビジネスコンテクストディメンションの表象を含むデータベースであり、これは、システム１００とこれら産業ビジネスコンテクストディメンションの相互連結とに関する。ＵｎｉＤｉｍＮｅｔ２１０はさらに、システム１００からアクセスできる全てのデータソースの全データソースディメンションと、それらの相互連結との表象を含む。ＵｎｉＤｉｍＮｅｔ２１０はまたさらに、表象される産業ビジネスコンテクストディメンションと表象されるデータソースディメンションとの間の連結（または関係）を含む。

システム１００で用いられる各産業ビジネスコンテクストディメンションは、ＵｎｉＤｉｍによって表されており、システム１００のＵｎｉＤｉｍ完全セットは３１０で表される。ＵｎｉＤｉｍは、システム１００内の固有の産業ビジネスコンテクストディメンションを表し定義するＵｎｉＤｉｍＮｅｔ２１０のデータベースの項目（ｅｎｔｒｙ）および定義である。

ＵｎｉＤｉｍ完全セット３１０は、任意の適切なメカニズムによってＵｎｉＤｉｍＮｅｔ２１０に表され得る。一実施形態において、各ＵｎｉＤｉｍ３８０は、ＵｎｉＤｉｍＮｅｔ２１０を定義し、このＵｎｉＤｉｍによって表象される特定の産業ビジネスコンテクストディメンションに関する全ての情報を参照するシングルポイントとして作動する、ネットワークにおけるノードである。システム１００の産業のためのディメンション完全セットは、任意の適切なメカニズムによって定義される。一実施形態において、ディメンションの完全セットは、産業と産業が用いるデータソースとを分析することによって、どのビジネスコンセプトが自然にグルーピングされるか、もしくは、どのビジネスコンセプトが関連性に基づいてもっとも有効にグルーピングされるかを決定する。他の実施形態においては、ディメンション完全セットは、所定の産業のデータを分析することによりそのデータ内のどのコンセプトが最も頻繁に参照、引用、および／またはクエリーされるかを判断することによって定義される。さらに別の実施形態においては、ディメンション完全セットは、生来のデータソースからの物理的および／またはロジックグルーピングとは関係なく、システム１００にアクセスできる全てのデータソースを見直しして、産業のビジネスコンテクストに基づいてデータのロジック的なグルーピングを決定することによって定義される。

図４を参照して、例示的な製薬産業のための例示的なディメンション完全セットが図示される。この例においては、ＵｎｉＤｉｍ完全セット３１０は、製薬産業のビジネスコンテクストを定義する複数のＵｎｉＤｉｍ４１０〜４７０を含む。この例では７つのＵｎｉＤｉｍのみが表されているが、適切なＵｎｉＤｉｍはいかなる数でも定義され得ることが理解され、さらに、本発明の多くのシステムは産業のビジネスコンテクストを定義するのに要求されるため極めてより多くの数のＵｎｉＤｉｍを含み得ることが理解される。この例においては、ＵｎｉＤｉｍ４１０はディメンション「スポンサー」を表し、ＵｎｉＤｉｍ４２０はディメンション「研究」を表し、ＵｎｉＤｉｍ４３０はディメンション「場所」を表し、ＵｎｉＤｉｍ４４０はディメンション「患者」を表し、ＵｎｉＤｉｍ４５０はディメンション「現場の患者」、ＵｎｉＤｉｍ４６０はディメンション「訪問」を表し、およびＵｎｉＤｉｍ４７０はディメンション「症状項目」を表す。

各ＵｎｉＤｉｍは少なくとも１つの他のＵｎｉＤｉｍに関連する。図４に示されるように、この製薬産業の例のＵｎｉＤｉｍは全て、おおよそ階層的に関連している。ＵｎｉＤｉｍ４１０（スポンサー）は、１つ〜多数の研究（ＵｎｉＤｉｍ４２０〜複数のＵｎｉＤｉｍ４２０（図示せず）によって表象される）に関連し得、各研究は１つ〜多数の場所（ＵｎｉＤｉｍ４３０〜複数のＵｎｉＤｉｍ４３０（図示せず）によって表象される）に関連し得、および各場所は１つ〜多数の患者（ＵｎｉＤｉｍ４５０〜複数のＵｎｉＤｉｍ４５０（図示せず）によって表象される）に関連し得る。各ＵｎｉＤｉｍ４５０（つまりその場所にいる各患者）は、１つ〜多数の「患者」ＵｎｉＤｉｍ４４０（身長や体重等といった患者に関する情報を表す）、１つ〜多数の「症状項目」ＵｎｉＤｉｍ４７０（患者の症状項目を表す）、および１つ〜多数の「訪問」ＵｎｉＤｉｍ４６０（患者の訪問を表す）に関連し得る。図４に図式的に示すように、あるＵｎｉＤｉｍは他のＵｎｉＤｉｍよりも階層的に「より高い」ものであるとみなされる。たとえば、ＵｎｉＤｉｍ４１０は、ＵｎｉＤｉｍ４３０よりもＵｎｉＤｉｍネットワークにおいて「より高い」ものである。一実施形態においては、ネットワークにおける各ＵｎｉＤｉｍは、一次元とみなされており、その一方で、ノード間の階層的な関係に関する情報はネットワークを二次元に広げる。

図３におけるＵｎｉＤｉｍＮｅｔ２１０を再度参照すると、ＵｎｉＤｉｍ完全セット３１０の各ＵｎｉＤｉｍ３８０は、データソース特定ディメンション完全セット（たとえば、３２０、３３０、および３４０）に含まれる少なくとも１つのデータソース特定ディメンション３９０に、システム１００にアクセスできる特定のデータソース（たとえば、図１のデータソース１７２、１７４、１７６。）に対応してマッピングされ、もしくは関係付けられる。図１に図示されるように、システム１００はデータソース１７２、１７４、および１７６によって例示されるような複数のデータソース１３０にアクセスする。３つのデータソースが図示されているが、いかなる数のデータソースが本発明のシステム１００によってアクセスされ得ることと理解される。

図１と図３とを参照すると、データソース１７２、１７４および１７６は、システム１００にアクセスしたおよび／またはアクセスできる産業に関する情報を含む任意の適切なデータソースであり得る。図３を参照すると、システム１００がアクセスできる各データソースのために、データソース特定ディメンションの完全セット（たとえば、データソース１７２のための完全セット３２０）が作成される。任意のデータソースのためのデータソース特定ディメンション完全セットは、任意の適切なメカニズムによって決定され得る。一実施形態においては、データソースの内部データ構造とデータによって表されるビジネス情報とが分析されることにより、ロジック的な「グループ」または各個別のデータソース特定ディメンションを定義するデータのつながりを判断する。他の実施形態においては、データソース内の情報の各セットのビジネスコンテクストが、分析されることにより、データソースへのデータソース特定ディメンションをさらに定義する。さらに別の実施形態においては、システム１００に含まれる産業ビジネスコンテクストディメンションが、調べられることにより、データソース内のデータは産業ビジネスコンテクストと一貫して概念的にグルーピングされ得る。またさらに別の実施形態（たとえば、以下で示すように、関係型データベース）においては、データソースの内部構造がデータソースのために各ビジネスソース特定ディメンションを定義する。

例示的なデータソースと対応するデータソース特定ディメンションは、図５Ａ、図５Ｂ、および図５Ｃに図示される。この例示的な実施形態においては、データソース１７２（図５Ａ）は、ＤＡＴＡＴＲＡＫ Ｃｅｎｔｒａｌ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ（「ＤＡＴＡＴＲＡＫ ＣＡ」）といったデータソースを含み、例示的なデータベースはＤＡＴＡＴＲＡＫ Ｉｎｔｅｒｎａｔｉｏｎａｌ，Ｉｎｃ．より提供される。ＤＡＴＡＴＲＡＫ ＣＡにおいて、オリジナルデータは専用の表、表のセット、もしくは一般的な表のどれかに記憶される。データソース特定ディメンション完全セットは、これら表に記憶される情報の性質、およびシステム１００からアクセスされる情報のタイプによって決定される。システム１００からアクセスされるものとされる情報が、ＤＡＴＡＴＲＡＫ ＣＡ内の専用の表に含まれる一実施形態においては、専用の表に関連する予め規定されるクラスは、データソース特定ディメンションを定義する。これらクラスは、対応するデータソース特定ディメンションと同様に、表一式をスパンすることにより、それぞれからデータを選択し、ビジネスコンテクストのグルーピングを容易にし、これにより、ビジネスコンテクストからオリジナルデータ（およびオリジナルデータ表）を切り離すことができる。システム１００からアクセスされるものとされる情報が、ＤＡＴＡＴＲＡＫ ＣＡ内の一般的な表に含まれる一実施形態においては、データソース特定ディメンションはオリジナルデータ内の特定分野の内容から得られる。特定分野は、その分野のビジネスコンテクストに基づいてグルーピングされる。データソース特定ディメンション完全セットがデータソース１７２および、その作成された特定のデータソース特定ディメンションのために定義され、完全セット３２０はＵｎｉＤｉｍＮｅｔ２１０に記憶される。

図５Ａを参照して、例示的なデータソース１７２（ＤＡＴＡＴＲＡＫ ＣＡ）のための例示的なデータソース特定ディメンションは、「ＣＡスポンサー」、「ＣＡ研究」、「ＣＡ場所」を含む。これらデータソース特定ディメンションは、ＤＡＴＡＴＲＡＫ ＣＡ内のデータを概念的にグルーピングしたものに関連し、それぞれ、データソースのスポンサー、データソースの研究、データソースの場所に関連する。システム１００で用いられる各データソース特定ディメンションは、ＵｎｉＤｉｍＮｅｔ２１０において、ＤａｔａＳｏｕｒｃｅＤｉｍと表されており、データソース１７２のＤａｔａＳｏｕｒｃｅＤｉｍ完全セットは３２０で表される。ＤａｔａＳｏｕｒｃｅＤｉｍは、システム１００内の固有のデータソース特定ディメンションを表象するＵｎｉＤｉｍＮｅｔ２１０のデータベースの項目である。データソース特定ディメンション「ＣＡスポンサー」は、ＤａｔａＳｏｕｒｃｅＤｉｍ５１０により表され、データソース特定ディメンション「ＣＡ研究」は、ＤａｔａＳｏｕｒｃｅＤｉｍ５１２により表され、およびデータソース特定ディメンション「ＣＡ場所」はＤａｔａＳｏｕｒｃｅＤｉｍ５１４により表される。追加のＤａｔａＳｏｕｒｃｅＤｉｍ「中央管理（Ｃｅｎｔｒａｌ Ａｄｍｉｎ）」５１６は、データソース自体（ＤＡＴＡＴＲＡＫ ＣＡ）を参照する特別なＤａｔａＳｏｕｒｃｅＤｉｍと定義される。特定のデータソースの各ＤａｔａＳｏｕｒｃｅＤｉｍ完全セットは、そのデータソースの特別なＤａｔａＳｏｕｒｃｅＤｉｍに接続される。

さらに、この例示的な実施形態において、データソース１７４がまとめられることにより、一般的なＳＱＬデータクエリーが容易になる。このようなＳＱＬデータベース（概して、関係型データベース）において、データベースのオリジナルデータは、特定のビジネスコンテクストのグルーピングしたものを直接表す表に記憶される。この点に関して、そのようなデータベースのデータソース特定ディメンションは、データが記憶される表から直接導き出される。たとえば、データベースは、患者情報を含む「患者」表を含み得る。この表は、「患者」のデータソース特定ディメンションと一致し得る。もしくは、データソース特定ディメンションは、各表から選択されるデータがビジネスコンテクストに関連する限り、複数表をスパンすると定義され得る。データソース特定ディメンション完全セットはデータソース１７４と、その作成された特定のデータソース特定ディメンションと、に定義されると、完全セットはＵｎｉＤｉｍＮｅｔ２１０に、代表のＤａｔａＳｏｕｒｃｅＤｉｍとして記憶される。図５Ｂを参照すると、例示的なＤａｔａＳｏｕｒｃｅＤｉｍ５２０、５２２、および５２４は、それぞれデータソース特定ディメンション「ＰＤ患者」、「ＰＤ現場の患者」、および「ＰＤ症状項目」を定義する。データソース１７２の完全セット３１０と同様に、データソース１７４に関する特別なＤａｔａＳｏｕｒｃｅＤｉｍ５２６は、データソース１７４の完全セット３３０に作成される。

さらにこの例示的な実施形態について、データソース１７６は完全に一般的なデータソースであって、任意の特別な表を任意の特別なコンセプトのために含むようには（たとえば、ＤＡＴＡＴＲＡＫ Ｉｎｔｅｒｎａｔｉｏｎａｌ，Ｉｎｃ．より提供される例示的なＤＡＴＡＴＲＡＫ ＥＤＣ Ｄａｔａｂａｓｅ（ＤＡＴＡＴＲＡＫ ＥＤＣ）ようには）設計されていないデータソースを備える。そのようなデータベースはＡＰＩ（たとえば、ＤＡＴＡＴＲＡＫ ＱＵＥＳＴＩＯＮＶＩＥＷ（登録商標））からアクセスされ、データソース特定ディメンションを作成する際に助けとなるいかなる内部構造も含めない。そのような場合、データソース特定ディメンションは、任意の適切なメカニズムによって作成される。一実施形態において、そのようなデータベースのデータソース特定ディメンションは、そのデータベースに記憶されるデータに関する全てのデータにアクセスすることによって、かつ、産業ビジネスコンテクストの観点からそのデータベースに含まれるデータを分析することによって作成される。データソース特定ディメンション完全セットがデータソース１７４と、その作成された特定のデータソース特定ディメンションと、に定義されると、完全セット３４０はＵｎｉＤｉｍＮｅｔ２１０に、代表のＤａｔａＳｏｕｒｃｅＤｉｍとして記憶される。図５Ｃを参照すると、例示的なＤａｔａＳｏｕｒｃｅＤｉｍ５３０、５３２、および５３４は、それぞれデータソース特定ディメンション「ＥＤＣ場所」、「ＥＤＣ現場の患者」、および「ＥＤＣ訪問」を定義する。データソース１７２の完全セット３１０と同様に、データソース１７６に関する特別なＤａｔａＳｏｕｒｃｅＤｉｍ５３６は、データソース１７４の完全セット３４０に作成される。

図３を再び参照して、ＤａｔａＳｏｕｒｃｅＤｉｍ完全セット（例示的な完全セット３２０、３３０、３４０と図示されるように）は、ＵｎｉＤｉｍＮｅｔ２１０において作成され記憶されており、そこでの各ＤａｔａＳｏｕｒｃｅＤｉｍは、ＵｎｉＤｉｍ３１０の完全セットの対応するＵｎｉＤｉｍにマッピングされ、もしくはリンクされる。図６Ａを参照して、ＤａｔａＳｏｕｒｃｅＤｉｍ完全セット３５０をＵｎｉＤｉｍ完全セット３１０の一部にマッピングすることが図示される。データソース特定ディメンション「ＣＡスポンサー」に関連しており、それ自体がデータソースＤＡＴＡＴＲＡＫ ＣＡに一緒に含まれるＣＡスポンサーの情報に関連するＤａｔａＳｏｕｒｃｅＤｉｍ５１０は、ＵｎｉＤｉｍ４１０の「スポンサー」に関連しており、これは、産業ビジネスコンテクストディメンションの「スポンサー」に関連する。この点に関して、データソースに関する特別なＤａｔａＳｏｕｒｃｅＤｉｍを除く各ＤａｔａＳｏｕｒｃｅＤｉｍは、対応するＵｎｉＤｉｍに関連する。ＵｎｉＤｉｍは、それがデータソース特定ディメンションと同じもしくは類似するディメンションに関連する場合、「対応する」ものである。同様に、ＤａｔａＳｏｕｒｃｅＤｉｍ５１２の「ＣＡ研究」は、ＵｎｉＤｉｍ４２０の「研究」に関連しており、ＤａｔａＳｏｕｒｃｅＤｉｍ５１４の「ＣＡ場所」はＵｎｉＤｉｍ４３０の「場所」に関連する。

図６Ｂと図６Ｃとを参照して、ＤａｔａＳｏｕｒｃｅＤｉｍ完全セット３６０と３７０とＵｎｉＤｉｍ完全セット３１０との間に同様のマッピングが生じ、そこでのＤａｔａＳｏｕｒｃｅＤｉｍのそれぞれは、対応するＵｎｉＤｉｍにリンクされる。図７において、図６Ａ、図６Ｂ、および図６Ｃにおいて図示された、マッピングされた関係が結合される。そこで図示されるように、あるＵｎｉＤｉｍ（たとえば、現場の患者４５０）は、１つ以上のＤａｔａＳｏｕｒｃｅＤｉｍにマッピングされる。これは、１つ以上のデータソースが特定の産業ビジネスコンテクストディメンション（ＵｎｉＤｉｍと表象される）に関連する情報を含むときに起きる。

一実施形態において、各ＤａｔａＳｏｕｒｃｅＤｉｍはＵｎｉＤｉｍＮｅｔ２１０を定義するネットワークにおけるノードであり、各ＵｎｉＤｉｍによって定義される各ノードに類似する。各ＤａｔａＳｏｕｒｃｅＤｉｍのノードを、ＵｎｉＤｉｍおよびＵｎｉＤｉｍ同士の関係によって定義される二次元のＵｎｉＤｉｍＮｅｔのネットワークにマッピングすることにより、ＵｎｉＤｉｍＮｅｔのネットワークは三次元に広げられる。この本文中は、ＵｎｉＤｉｍＮｅｔ２１０はＵｎｉＢａｓｅ１１０の関連したデータとして記憶されるノード三次元ネットワークである。

他の実施形態において、ＵｎｉＤｉｍＮｅｔ２１０は相互に関係がある表を一組にしたものであり、ＵｎｉＤｉｍＮｅｔ２１０内の各ノードは表によって表される。したがって、各ＵｎｉＤｉｍとＵｎｉＤｉｍＮｅｔ２１０における各ＤａｔａＳｏｕｒｃｅＤｉｍとは表によって表される。システム１００からアクセスできるデータソースの各ディメンション事例は、ＵｎｉＤｉｍＮｅｔ２１０の少なくとも１つのＵｎｉｄｉｍと、ＵｎｉＤｉｍＮｅｔ２１０の少なくとも１つのＤａｔａＳｏｕｒｃｅＤｉｍとにおい行で表される。図８を参照して、たとえば、データソース１７６におけるディメンション事例８００（ＤＡＴＡＴＲＡＫ ＥＤＣ）は、研究における特定の場所であり、ここからデータがＤＡＴＡＴＲＡＫ ＥＤＣによって得られる（つまり、ディメンション事例８００は産業ビジネスコンテクストディメンション４３０の「場所」である）。ディメンション事例８００は、ＤａｔａＳｏｕｒｃｅＤｉｍ５３０（「ＥＤＣ場所」）のための表８６０において行８６２で表されており、ＵｎｉＤｉｍ４３０（「場所」）のための表８５０において行８５２で表される。

各ＵｎｉＤｉｍ表は各ディメンション事例のための項目（たとえば、表の行）を備えており、このディメンション事例のディメンションはシステム１００からアクセスできるデータソースに含まれるＵｎｉＤｉｍによって表される。ＵｎｉＤｉｍ表の各項目（たとえば、行８５２）は、その項目によって表されるディメンション事例を固有に識別するグローバルに固有な識別番号８５３を含む。各項目はまた、作成タイムスタンプ８５４と更新タイムスタンプ８５５とを項目毎に備えており、それぞれは、ディメンション事例がシステム１００に入力された時間とディメンション事例が更新された最後の時間とを表す。各入力事項はさらに、表における各ディメンション事例に関する追加の情報（つまり、追加の記録フィールド）を備え得る。適切な情報はいずれも追加され得る。たとえば、ディメンション事例に関連するＤａｔａＳｏｕｒｃｅＤｉｍを識別するフィールド８５６が追加され得る。各ＵｎｉＤｉｍ項目に含まれる情報量は、システム１００に所望される応答時間と、ＵｎｉＢａｓｅが利用できるデータストレージ空間とによって決定される。一般的に、各ＵｎｉＤｉｍ項目に含まれる情報が多ければ多いほど、システム１００によって検索されることを必要とするデータソースは少ない（なぜならば、ディメンション事例に関する情報の大部分がＵｎｉＤｉｍ項目にすでに記憶されるため）、したがって、一般的にシステムパフォーマンスのスピードは上がる。しかしながら、そのような追加の情報は追加のストレージ空間を使用し、これはシステムのコストに追加され得て、ＵｎｉＤｉｍＮｅｔを維持するために使用されるデータベース管理ソフトウェアによっては、ＵｎｉＤｉｍ表の大きさが大きくなり過ぎる場合にはシステムのスピードを下げ得る。

ＵｎｉＤｉｍ表と類似して、各ＤａｔａＳｏｕｒｃｅＤｉｍ表は、ディメンションの各ディメンション事例のための項目を備えており、このディメンションはＤａｔａＳｏｕｒｃｅＤｉｍに関連するデータソースに含まれるＤａｔａＳｏｕｒｃｅＤｉｍによって表される。ＤａｔａＳｏｕｒｃｅＤｉｍ表における各項目（たとえば、行８６２）は、ディメンション事例が含まれるデータソースへの参照８６４、データソースからディメンション事例（およびそこで関連するデータ）を検索するのに要求されるキー情報８６３（たとえば、データソース固有の識別子）、およびディメンション事例に関連するＵｎｉＤｉｍ項目に含まれるディメンション事例のための固有の識別番号８５３を含む。各項目はまた、関連するＵｎｉＤｉｍ項目と同様に、作成タイムスタンプ８５４と更新タイムスタンプ８５５とを含み得る。さらに、ＵｎｉＤｉｍ項目と同様に、ＤａｔａＳｏｕｒｃｅＤｉｍ表の項目は、特定のディメンション事例に関連する追加の情報を含み得、さらに、ＤａｔａＳｏｕｒｃｅＤｉｍが関連するデータソースとＵｎｉＤｉｍとに関する追加の情報を含み得る。ＵｎｉＤｉｍ入力事項に含まれる情報量を決定付けるスピードと大きさとに関連する同様の要因はまた、ＤａｔａＳｏｕｒｃｅＤｉｍ項目に含まれる情報量を測定するためにも適用できることが理解される。

ディメンション事例８００を再び参照して、ディメンション事例８００に関連する入力事項は、ＤａｔａＳｏｕｒｃｅＤｉｍ表８６０（入力事項８６２）とＵｎｉＤｉｍ表８５０（入力事項８５２）とに含まれる。これら入力事項は任意の適切なメカニズムによって互いに関連する。一実施形態においては、この関係は、ＵｎｉＤｉｍ記録のフィールド８５６を識別するＤａｔａＳｏｕｒｃｅＤｉｍに含まれる。他の実施形態においては、この関係はさらに同一のＵｎｉＤｉｍ固有の識別番号８５３を含む。

ＵｎｉＤｉｍ表は１つ以上のＤａｔａＳｏｕｒｃｅＤｉｍ表に関連し得る。図８をさらに参照すると、ＵｎｉＤｉｍ表８５０はまた、ＤａｔａＳｏｕｒｃｅＤｉｍ５１４（「ＣＡ場所」）を表わすＤａｔａＳｏｕｒｃｅＤｉｍ表８７０に関連し、これは、データソース１７２（ＤＡＴＡＴＲＡＫ ＣＡ）に関連する。たとえば、データソース１７２（ＤＡＴＡＴＲＡＫ ＣＡ）におけるディメンション事例８８０は、研究における特定の場所であり、ここからのデータはＤＡＴＡＴＲＡＫ ＣＡに記憶される（つまり、ディメンション事例８００は、産業ビジネスコンテクストディメンション４３０「場所」の事例である）。ディメンション事例８００は、ＤａｔａＳｏｕｒｃｅＤｉｍ５１４（「ＣＡ場所」）の表８７０に行８７２によって、かつＵｎｉＤｉｍ４３０（「場所」）の表８５０に行８５８によって表される。この例において、ＵｎｉＤｉｍ表８５０は、２つの異なるＤａｔａＳｏｕｒｃｅＤｉｍ表（そしてその後２つの異なるデータソース）に関連する項目を備えるということが理解される。ＵｎｉＤｉｍ表８５０は、ディメンション事例（ＤａｔａＳｏｕｒｃｅＤｉｍが関連するディメンション事例）がＵｎｉＤｉｍ（ＵｎｉＤｉｍ表が関連するＵｎｉＤｉｍ）に関連する限り、いかなる数のＤａｔａＳｏｕｒｃｅＤｉｍ表に関連する入力事項を含むことができる。さらに、ＵｎｉＤｉｍ表は、１つのＤａｔａＳｏｕｒｃｅＤｉｍ表における複数の項目に関連する複数の項目を含むことができる。この場合、各ディメンション事例の項目は、ディメンション事例に関連するＤａｔａＳｏｕｒｃｅＤｉｍ表とＵｎｉＤｉｍ表との両方に記憶される。

さらに図８を参照して、各ＤａｔａＳｏｕｒｃｅＤｉｍ表はまた、データソース自身を参照する項目（たとえば、表８６０の項目８９０および表８７０の項目８９２）を含み得る。そのような項目は、特定のデータソースに関連する情報を含む特別なＤａｔａＳｏｕｒｃｅＤｉｍ（たとえば、図５のＤａｔａＳｏｕｒｃｅＤｉｍ５１６（「ＤＡＴＡＴＲＡＫ ＣＡ」）を参照。）に関連する。そのような項目は、データベースの他の項目に類似する情報を含み得、そして任意にデータソース（たとえば、データソースのアクセスメカニズムに関連する情報や、一般的に、データソースに関連する連結情報）に関連する追加の情報を含み得る。ＤａｔａＳｏｕｒｃｅＤｉｍに関連する各データソースは、それ自身に関連するＤａｔａＳｏｕｒｃｅＤｉｍに特別な項目を有する。各ＤａｔａＳｏｕｒｃｅＤｉｍノードは、したがって、対応するタイプの全ての実際のデータソースの情報を含む。

一実施形態においては、システム１００にアクセスできる全てのデータソース内に含まれる各ディメンション事例は、少なくとも１つのＵｎｉＤｉｍ表と少なくとも１つのＤａｔａＳｏｕｒｃｅＤｉｍ表に対応する項目を有する。ＵｎｉＤｉｍＮｅｔ２１０は、このように、各データソースの物理的かつロジック的構造と関係なく、全てのデータソースをスパンするディメンションとディメンション事例とにクエリーをかけることを容易にする。そのようなクエリー（ディメンションやディメンション事例に関連し、特定のデータソースや各データソースの特定の記録に関連しない）はテンプレート、つまりＵｎｉＶｉｅｗによって実行され得る。

ＵｎｉＶｉｅｗはシステム１００内のデータソースに実際のデータ要求をするロジック（たとえば、ソフトウェアの構成成分、ルーチン、またはオブジェクト）である。ＵｎｉＶｉｅｗは、特定のデータソースのために設計された特定のディメンションへの特定の質問である。図９を参照して、例示的なＵｎｉＶｉｅｗ９００は、データアクセスメカニズム９１０と通信することにより、データソース（ここでは、例示的なデータソース１７２）にアクセスしたりクエリーをかけたりすることを容易にする。一実施形態においては、ＵｎｉＶｉｅｗは機能呼出しの形式をとる：
ｒｅｓｕｌｔ＝ｅｘａｃｔ＿ｒｅｑｕｅｓｔ＿ｆｏｒ＿ｉｎｆｏｒｍａｔｉｏｎ（ｉｎｓｔａｎｃｅ＿ｐａｒａｍｅｔｅｒ）
ここでは、「ｒｅｓｕｌｔ」がクエリーへの応答でデータソースから返される要求された情報であり、「ｅｘａｃｔ＿ｒｅｑｕｅｓｔ＿ｆｏｒ＿ｉｎｆｏｒｍａｔｉｏｎ」は特定情報のデータソースに対する特定要求（クエリー）で、「ｉｎｓｔａｎｃｅ＿ｐａｒａｍｅｔｅｒ」はその要求に関連する特定のディメンション事例である。たとえば、患者「Ｊｏｅ Ｓｍｉｔｈ」の身長を求めてクエリーをかけるＵｎｉＶｉｅｗは、「ｒｅｓｕｌｔ」をＪｏｅ Ｓｍｉｔｈの身長の値を含むフィールドであると定義し、以下の形式をとることができる：
ｒｅｓｕｌｔ＝ｗｈａｔ ｉｓ ｔｈｅ ｈｅｉｇｈｔ ｏｆ ｔｈｅ ｐａｔｉｅｎｔ（ｐａｔｉｅｎｔ＝「Ｊｏｅ Ｓｍｉｔｈ」）
適切なデータソースにうまくクエリーをかけられると、例示的なＵｎｉＶｉｅｗはデータソースに記録されたＪｏｅ Ｓｍｉｔｈの身長の値を返す。

一実施形態において、ＵｎｉＶｉｅｗの「ｒｅｓｕｌｔ」と「特定要求」とは作成されて記録される一方で、「ｉｎｓｔａｎｃｅ ｐａｒａｍｅｔｅｒ」は変数として残されるので、これにより、ＵｎｉＶｉｅｗは同じデータソースの同じディメンションに同じ質問がされる度に使用され再使用されることが可能である（「ｉｎｓｔａｎｃｅ ｐａｒａｍｅｔｅｒ」の値はＵｎｉＶｉｅｗを完成させるためにＵｎｉＶｉｅｗに渡され得る）。この方法で、単一のＵｎｉＶｉｅｗが選択され渡される複数の事例パラメーターであり得、複数のディメンション事例の同一のデータソースに複数のクエリーを果たす。

各ＵｎｉＶｉｅｗは特定のデータソースのために作成される。一実施形態において、データソースをシステム１００に取り込むと、複数のＵｎｉＶｉｅｗは新しいデータソースにクエリーをかけるためにシステム１００に作成される。各ＵｎｉＶｉｅｗは必要な情報と指示を含むことにより、その特定のデータソースのためにデータアクセスメカニズムを介してデータソースにアクセスすることを容易にする。たとえば、例示的なデータソースＤＡＴＡＴＲＡＫ ＥＤＣとＤＡＴＡＴＲＡＫ ＣＡとはＤＡＴＡＴＲＡＫ ＱＵＥＳＴＩＯＮＶＩＷ ＡＰＩを介してアクセスすることができる。これらデータソースのどちから一方のためのＵｎｉＶｉｅｗは、各データベースにクエリーかけるためにＤＡＴＡＴＲＡＫ ＱＵＥＳＴＩＯＮＶＩＥＷ ＡＰＩをアクセスかつ使用する能力をもって生成される。ＵｎｉＶｉｅｗは、ＡＰＩを指示することによりデータベースにクエリーをかけて、ある結果（「ｒｅｓｕｌｔ」の形式で）を返すために必要な要求されたパラメーター、指示、および情報を含む。この点に関して、ＵｎｉＤｉｍＮｅｔ２１０は、各データソースの構造や物理的要求の特定の詳細から除かれる。ＵｎｉＤｉｍＶｉｅｗは、ディメンション特定クエリーを受け取り、データソースへのアクセスを容易にすることによりクエリーに応える。前記の例はデータソースに対するデータアクセスメカニズムとしてＡＰＩの使用を図示してきたが、データソースにクエリーをかけることができるデータアクセスメカニズムはいずれも使用され得ることが理解される。

任意の特定データソースのために作成されるＵｎｉＶｉｅｗの数と程度とは、データソース内のディメンション事例の数とタイプ、およびデータソースにクエリーをかけるためのユーザの所望によって決定する。適切な数のＵｎｉＶｉｅｗが特定のデータソースに対して、システム１００に作成され使用され得る。データソースは多数の事例を表す量のあるデータを有する限り、多数のＵｎｉＶｉｅｗが作成されることと理解される。ＵｎｉＶｉｅｗはシステム１００の任意の適切な要素（またはデータベース）に記憶され得、たとえば、ＵｎｉＢａｓｅ１１０内に記憶され得る。一実施形態においては、ＵｎｉＶｉｅｗ（つまりＵｎｉＶｉｅｗの「定義」）はＵｎｉＢａｓｅ１１０のＵｎｉＶｉｅｗデータベース２２０の定義に記憶される（図２参照）。他の実施形態においては、図１と図１２とを参照して、複数のＵｎｉＶｉｅｗはＵｎｉＢｕｉｌｄｅｒ１６０のＵｎｉＶｉｅｗツリー１２１０に記憶される。ＵｎｉＶｉｅｗツリー１２１０は、システム１００のために作成された全てのＵｎｉＶｉｅｗのリストを含み得る。リストは任意の適切な方法で整理され得、このシステムのＵｎｉＶｉｅｗを検索し、かつこれにアクセスすることを容易にする。一実施形態において、ＵｎｉＶｉｅｗツリー１２１０のＵｎｉＶｉｅｗは、ディメンションによってトピック毎に整理される。他の実施形態において、ＵｎｉＶｉｅｗははじめにデータソースによって整理されて、そのあとディメンションによって整理される。さらに別の実施形態において、ＵｎｉＶｉｅｗは階層的に整理される。ＵｎｉＢｕｉｌｄｅｒ１６０は、ｍａｎａｇｅ ＵｎｉＶｉｅｗツリーロジック１２２０を用いて、ＵｎｉＶｉｅｗツリーの管理を容易にし得る。ｍａｎａｇｅ ＵｎｉＶｉｅｗツリーロジック１２２０は、ＵｎｉＶｉｅｗツリー１２１０の管理を容易にするよう任意の適切なステップ、方法、および／またはプロセスを含み、この限りではないが、ＵｎｉＶｉｅｗをツリーに加えるためのロジック、ＵｎｉＶｉｅｗをツリーから削除するためのロジック、ツリーを認識するためのロジック、ツリーを検索するためのロジック、ツリーを構成するためのロジックを含み、さもなければツリーに対する変更を容易にする。以下でもさらに説明するように、ＵｎｉＶｉｅｗツリー１２１０はまた、ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅとＣｏｍｐｏｕｎｄＵｎｉＶｉｅｗとを含み得る。ＵｎｉＶｉｅｗツリー１２１０はシステム１００のＵｎｉＶｉｅｗの構成を容易にするとして説明されてきたが、ＵｎｉＶｉｅｗはそれ自体がＵｎｉＶｉｅｗツリー１２１０内に記憶され得、もしくはその代わりに異なる場所（またはデータベース）内に、各ＵｎｉＶｉｅｗに関連する識別キーのみがＵｎｉＶｉｅｗツリー１２１０に整理されて、記憶され得る。

システム１００は任意で追加の機能を含み、ＵｎｉＶｉｅｗの管理、使用および作成の際に援助し、ここでの機能は、ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅを使用する機能、ＣｏｕｍｐｏｕｎｄＵｎｉＶｉｅｗを使用する機能、たとえばＵｎｉＢｏｔといった自動化したプロセスを介してＵｎｉＶｉｅｗのキャッシュ機能およびＵｎｉＶｉｅｗの作成機能を含むがこの限りではない。ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅは図１０の参照で図示される。

ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅは、複数のＵｎｉＶｉｅｗを結合して、複数のＵｎｉＶｉｅｗの使用を要求するクエリーを容易にするメカニズムである。ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅは一般的に、ＵｎｉＶｉｅｗと同じ形式（つまり機能コール）をとっており、複数のＵｎｉＶｉｅｗは単一のＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅと呼ばれる。しかしながら、一般的にＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅの「ｒｅｓｕｌｔ」は、結果セットであり、この内容は、ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅと呼ばれる複数のＵｎｉＶｉｅｗによって検索される複数のディメンション事例に対応する検索されたデータの収集（またはアレイや表）である。さらに、ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅにおける「ｅｘａｃｔ＿ｒｅｑｕｅｓｔ＿ｆｏｒ＿ｉｎｆｏｒｍａｔｉｏｎ」はＵｎｉＶｉｅｗにおけるときのように、データソース限定ではない。その代わりに、「ｅｘａｃｔ＿ｒｅｑｕｅｓｔ＿ｆｏｒ＿ｉｎｆｏｒｍａｔｉｏｎ」はデータソースとは関係なく、要求された情報（たとえば、ディメンションから）のみに関連する。またさらに、「ｉｎｓｔａｎｃｅ＿ｐａｒａｍｅｔｅｒ」は、単一のディメンション事例というよりはむしろディメンション事例のアレイである。ディメンション事例のアレイは、クエリーをかけられることを所望するディメンション事例のセットによって定義される。

図１０は、ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅの使用を示す。図１０の例において、３つの別々のデータソース（研究ＤＢ１０４０、ＥＤＣ研究Ｉ ＤＢ１０４２、およびＥＤＣ研究II ＤＢ１０４４）は、それぞれ異なる物理的かつロジック的構造を有しており、そして異なるアクセスメカニズムを用いているが、これらはそれぞれディメンション「患者の特徴」（たとえば、各研究にいる参加者の年齢、身長、体重等）に関連する情報を含む。ＵｎｉＶｉｅｗは、１つのディメンション事例を個別に各データベースにクエリーをかけるよう使用される。各データソース内に複数のディメンション事例が起きる場合、複数のＵｎｉＶｉｅｗを各事例にアクセスするのに使用することが必要である。３つ全てのデータソースに完全にクエリーをかけるために要求されるＵｎｉＶｉｅｗの数は、ユーザが実行するのに時間を要する。ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅ１０１０は一人の人がクエリーをかけるＵｎｉＶｉｅｗで複数個クエリーをかけることを容易にする。

ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅ１０１０は、複数の患者に対する患者の特徴の情報を含む収集としての「ｒｅｓｕｌｔ」とともに作成される。ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅ１０１０クエリーの「ｒｅｓｕｌｔ」は、患者の特徴データの収集であり、各患者は、「ｒｅｓｕｌｔ」項目である。「ｅｘａｃｔ＿ｒｅｑｕｅｓｔ＿ｆｏｒ＿ｉｎｆｏｒｍａｔｉｏｎ」は、患者の特徴（特定のデータソースを限定しない）のディメンション「患者」４４０（図４参照）のクエリーである。「ｉｎｓｔａｎｃｅ ｐａｒａｍｅｔｅｒ」は、患者の名前もしくは他の適切な患者識別子のアレイである。患者１２３ １０００（研究から）、患者ａｂｃ １００２（ＥＤＣ Ｉから）および患者ｘｙｚ １００４（ＥＤＣIIから）の患者の特徴を受け取ることを所望するユーザは、アレイ「ｉｎｓｔａｎｃｅ ｐａｒａｍｅｔｅｒ」の値として、患者１２３、患者ａｂｃ、患者ｘｙｚの識別子（たとえば、名前）をＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅ１０１０に渡す（つまり、クエリーをかけられる患者がＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅに渡される）。ユーザは、各患者のデータソースの識別をＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅに渡す必要はないということは注目すべきである。アレイ「ｉｎｓｔａｎｃｅ ｐａｒａｍｅｔｅｒ」の値を受け取ると、ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅ１０１０はＵｎｉＤｉｍＮｅｔ２１０にあるＵｎｉＤｉｍにクエリーをかけ、これは、そのアレイにある各ディメンション事例の固有の識別番号に基づいた、もしくはこの識別番号のためのディメンション「患者」（ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅは、ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅ１０１０が「患者の特徴」に対するものなので、このディメンションを検索するようコード化されている）に対応する。ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅ１０１０が各ディメンション事例のためのこの情報を受け取ると、ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅ１０１０は、各ディメンション事例に関連するＤａｔａＳｏｕｒｃｅＤｉｍにクエリーをかけ（注意：事例がＵｎｉＤｉｍにあることが分かると、それぞれのＤａｔａＳｏｕｒｃｅＤｉｍへの関連性は既に存在する）、各ディメンション事例に関連する適当なデータソースを決定する。この情報を用いて、ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅ１０１０は複数のＵｎｉＶｉｅｗを呼び出す。呼び出されたＵｎｉＶｉｅｗのそれぞれは、ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅ１０１０の「ｉｎｓｔａｎｃｅ＿ｐａｒａｍｅｔｅｒ」アレイから１つの事例として１つの「ｉｎｓｔａｎｃｅ＿ｐａｒａｍｅｔｅｒ」にパスされ、１つの事例がパスされるＵｎｉＶｉｅｗは、ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅの性質（つまり、ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅとちょうど同じように「患者特徴」のＵｎｉＶｉｅｗである）と関連するデータソースの識別によって選択される。例において、ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅ１０１０は、したがって、患者１２３、患者ａｂｃ、患者ｘｙｚのそれぞれに対してＵｎｉＶｉｅｗ１０２０、ＵｎｉＶｉｅｗ１０２２、ＵｎｉＶｉｅｗ１０２４を呼び出す。ＵｎｉＶｉｅｗ１０２０は、アクセスメカニズム１０３０を介してデータソース１０４０にアクセスし、ＵｎｉＶｉｅｗ１０２２は、アクセスメカニズム１０３２を介してデータソース１０４２にアクセスし（たとえば、ＤＡＴＡＴＲＡＫ ＱＵＥＳＴＩＯＮＶＩＥＷ ＡＰＩ）、およびＵｎｉＶｉｅｗ１０２４は、アクセスメカニズム１０３４を介してデータソース１０４４にアクセスする。患者特徴データの結果収集は、ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅクエリーに応答してユーザに返される。一実施形態において、システム１００の認定されたＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅは、ＵｎｉＶｉｅｗツリー１２１０に記憶および／または書き込まれる。ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅは複雑なクエリーの例である。

図１１を参照して、ＣｏｕｍｐｏｕｎｄＵｎｉＶｉｅｗは、一連の（組み合わせの）ＵｎｉＶｉｅｗを将来使用するために記憶するメカニズムである。ユーザは、複数のディメンションと複数のデータソースをスパンする複数のＵｎｉＶｉｅｗが用いられる状況においては、複雑なクエリーを作成することが所望される。一度作成されると、そのような複雑なクエリー（複数のＵｎｉＶｉｅｗを含む）は、ＣｏｕｍｐｏｕｎｄＵｎｉＶｉｅｗとして記憶されることができ、そしてその後、異なる入力された事例パラメーター（ｉｎｓｔａｎｃｅ ｐａｒａｍｅｔｅｒ）とともに使用されることができる。図１１の例において、ユーザは特定患者の全てのデータソースに亘って「生活の質」クエリーを所望する。このユーザは、「生活の質」クエリーを、データソース患者日記１１４０から「患者の胃の日記」と「患者の痛みレベル日記」とを、データソース１１４２から「ＥＤＣ投薬」、およびデータソース１１４４から「患者の管理履歴」を含むものとして定義する。このユーザはしたがって、４つのＵｎｉＶｉｅｗを組み合わせてこの複雑なクエリーを作成する。このユーザはＵｎｉＶｉｅｗ１１２０とＵｎｉＶｉｅｗ１１２２とを選択して、クエリーデータソース１１４０へのアクセスメカニズム１１３０を使用し、ＵｎｉＶｉｅｗ１１２４を選択して、クエリーデータソース１１４２へのアクセスメカニズム１１３２を使用して、そして、ＵｎｉＶｉｅｗ１１２６を選択して、クエリーデータソース１１４４へのアクセスメカニズム１１３４を使用する。この複雑なクエリーは、ＣｏｍｐｏｕｎｄＵｎｉＶｉｅｗ「生活の質」１１１０として保存される。この後に続くユーザが特定患者の「生活の質」を求めてシステム１００にクエリーをかけたい場合、このユーザは、ただ単にＣｏｍｐｏｕｎｄＵｎｉＶｉｅｗ「生活の質」１１１０を選択して、それにｉｎｓｔａｎｃｅ＿ｐａｒａｍｅｔｅｒ（たとえば、「患者１２３」１１１０）の所望値をパスすることのみを必要とされる。ＣｏｕｍｐｏｕｎｄＵｎｉＶｉｅｗ１１１０は、ＵｎｉＶｉｅｗ１１２０、ＵｎｉＶｉｅｗ１１２２、ＵｎｉＶｉｅｗ１１２４、およびＵｎｉＶｉｅｗ１１２６を集めて、それぞれにｉｎｓｔａｎｃｅ＿ｐａｒａｍｅｔｅｒをパスし、それぞれから「ｒｅｓｕｌｔ」を受け取り、そして各ＵｎｉＶｉｅｗから返された組み合わさった情報を「ｒｅｓｕｌｔ」として返す。その意味では、ＣｏｕｍｐｏｕｎｄＵｎｉＶｉｅｗに対してユーザが要求した入力パラメーター（つまり、クエリーもしくはクエリーの範囲を定義するためにユーザが提供するデータ）のみが、ＣｏｍｐｕｎｄＵｎｉＶｉｅｗの識別（つまり、クエリーをかけられるデータの記述であり、たとえば、「患者の体重」）およびクエリーをかけられるディメンション事例の識別である。ユーザはまた、所望の結果に関するパラメーターを入力し得る（つまり、返されるデータの形式）。一実施形態において、システム１００の認定されたＣｏｍｐｕｎｄＵｎｉＶｉｅｗは、ＵｎｉＶｉｅｗツリー１２１０に記憶および／または整理される。ＣｏｍｐｕｎｄＵｎｉＶｉｅｗは複雑なクエリーの例である。

ＵｎｉＶｉｅｗキャッシュは、実行されたＵｎｉＶｉｅｗの結果をキャッシュすることによってシステム１００の応答時間を早くするメカニズムである。このようなＵｎｉＶｉｅｗの後に続く実行において、キャッシュされた結果を分析することによって、対応するデータソースへの更新がキャッシュした時間から起きたか否かを判断する。一般的に言って、更新がなかった場合、キャッシュされた結果がＵｎｉＶｉｅｗを実行するために返されることができ、これにより、ＵｎｉＶｉｅｗに対応して直接データソースにアクセスするのに要求される時間とシステム資源とを節約する。更新があった場合、キャッシュは無視され、ＵｎｉＶｉｅｗはデータソースにクエリーをかけ、そのクエリーに対する応答はキャッシュされることにより古いキャッシュされたデータ更新する。

一実施形態において、そのようなキャッシュを容易にするために、システム１００はシステム１００の各ＵｎｉＶｉｅｗのためにキャッシュ結果表を作成する。キャッシュされた結果の表は、システム１００内の任意の適切な場所に記憶され得る。一実施形態において（図２参照）、ＵｎｉＢａｓｅ１１０は、キャッシュされたＵｎｉＶｉｅｗ結果のデータベース２３０を有する。キャッシュされたＵｎｉＶｉｅｗ結果データベース２３０は、任意の適切なデータベースであり、任意の適切な構成を有しており、ＵｎｉＶｉｅｗクエリーからのキャッシュされた結果を記憶するのに適している。一実施形態において、キャッシュされたＵｎｉＶｉｅｗ結果データベース２３０は、複数の表を含み、各表はシステム１００の特定のＵｎｉＶｉｅｗに関連する。各表は、その表に関連するＵｎｉＶｉｅｗによって実行された最も新しいクエリーからの「ｒｅｓｕｌｔ」データを含む。一実施形態において、表のキャッシュされる事例はそれぞれ、タイムスタンプを添えられており、これはデータがキャッシュされた日付と時間を示す。ＵｎｉＶｉｅｗキャッシュシステムの例示的な使用はさらに以下で説明される。一実施形態において、キャッシュ結果表は、ＵｎｉＢｕｉｌｄｅｒ１６０のＵｎｉＶｉｅｗ表ロジック１２５０によって容易に作成される（図１２参照）（ＵｎｉＶｉｅｗ作成に関して、以下でより詳細に説明される）。ＵｎｉＶｉｅｗ表ロジック１２５０は、任意の適切なステップ、プロセス、方法および／またはソフトウェアコードを含むことにより、キャッシュ結果表の作成、キャッシュ結果表へのアクセス、およびキャッシュ結果表の管理を容易にする。

ＵｎｉＶｉｅｗは、任意の適切なメカニズムによって作成されることが可能であり、これには手動（つまり、１つのＵｎｉＶｉｅｗはユーザによってコード化される）が含まれる。一実施形態において、システム１００はツールを提供することによりＵｎｉＶｉｅｗの作成を支援する。図１２を参照して、ＵｎｉＢｕｉｌｄｅｒ１６０は、データソースクラスロジック１２３０とＵｎｉＢｏｔ１２４０とを含む。

一実施形態において、データソースクラスロジック１２３０はＵｎｉＶｉｅｗを作成することを支援する。システム１００にアクセスできるようになると、データソースクラスは定義され、これにより、そのクラスのデータソースにクエリーをかけるのに必要な情報、ステップ、プロセスおよびアクセスメカニズムが示される。データソースクラスは、ＵｎｉＶｉｅｗの「ｅｘａｃｔ＿ｒｅｑｕｅｓｔ＿ｆｏｒ＿ｉｎｆｏｒｍａｔｉｏｎ」要素を作成するためにＵｎｉＶｉｅｗから要求される情報を含む（つまり、適切なデータアクセスメカニズムを介してデータソースにクエリーをかけることを容易にするようＵｎｉＶｉｅｗから要求される特定情報）この情報はフォーマットされることにより、このクラスのデータソースにクエリーをかけるよう指示されたＵｎｉＶｉｅｗにおいて使用されることを容易にする。この方法では、このクラスのデータソースにクエリーをかけるＵｎｉＶｉｅｗを作成すること望む場合、ＵｎｉＶｉｅｗの作成者は、そのフォーマットされたデータクラス情報をＵｎｉＶｉｅｗに「移動する」もしくは「コピーする」ことができ、これによって、そのようなＵｎｉＶｉｅｗのそれぞれに同一のコードを再び作成する際の時間を節約する。データソースクラスの作成を容易にするために（図１参照）、ＵｎｉＢｕｉｌｄｅｒ１６０はデータソース１３０からのデータソースに関する情報を受け取る。データソースクラスロジック１２３０は、任意の適切なステップ、方法、プロセスおよび／またはコードを含むことにより、データソースクラスの作成、データソースクラスのフォーマット、データソースクラスの保存、データソースクラスへのアクセス、およびデータソースクラスのＵｎｉＶｉｅｗへの移動を容易にする。データベースクラス情報は、システム１００の任意の適切な場所に記憶され得る。

一実施形態において、ＵｎｉＢｏｔ１２４０はデータソースの「標準」ＵｎｉＶｉｅｗセットの作成を容易にする。ＵｎｉＢｏｔ１２４０は、任意の適切なステップ、方法、プロセス、および／またはコードを含むことにより、そのような作成を容易にする。ＵｎｉＢｏｔ１２４０は、任意で自動化され得る。ＵｎｉＶｉｅｗの「標準」セットが含むもの（たとえば、そのクラスのデータソースのためのＵｎｉＶｉｅｗはいくつあるか、どのディメンションがクエリーをかけられるものである、どのデータがそのクラスのデータソースからルーチンでクエリーをかけられるか）に関するユーザの入力に基づいて、ＵｎｉＢｏｔ１２４０は関連したデータソースにアクセスし、ＵｎｉＶｉｅｗの標準セットを作成するのに必要な情報を判断する。一実施形態において、ＵｎｉＢｏｔ１２４０は、関連したデータソースにアクセスし、ＵｎｉＤｉｍＮｅｔに取り込まれるデータソースにＤａｔａＳｏｕｒｃｅＤｉｍを作成するのに必要な情報を判断する。一実施形態において、ＵｎｉＢｏｔ１２４０は、そのような情報を検索し、ユーザが定義した仕様に従ってＵｎｉＶｉｅｗのセットを作成する。

図１を参照して、ＵｎｉＢａｓｅ１１０、ＵｎｉＢｕｉｌｄｅｒ１６０、データソース１３０およびシステム１００の他の要素（以下で説明される）の間の連携は、ＵｎｉＳｅｒｖｅｒ１２０によって容易に行われる。図１３を参照して、ＵｎｉＳｅｒｖｅｒ１２０は任意で、ｍａｎａｇｅ ＵｎｉＤｉｍＮｅｔロジック１３００、ｍａｎａｇｅデータソースロジック１３０５、ルート接続ロジック１３１０、複合ＵｎｉＶｉｅｗロジック１３２０、スナップショットとバージョニングロジック１３２５、および外部データアクセスを容易にするロジック１３３０を含む。ＵｎｉＳｅｒｖｅｒ１２０は任意で、システム１００の動作を容易にするのに必要なとき追加の要素を含むことができる。

一実施形態において、ｍａｎａｇｅ ＵｎｉＤｉｍＮｅｔロジック１３００は、ＵｎｉＤｉｍＮｅｔの管理を容易にする。ｍａｎａｇｅ ＵｎｉＤｉｍＮｅｔロジック１３００は、任意のステップ、プロセス、方法および／またはソフトウェアコードを含むことにより、ＵｎｉＤｉｍＮｅｔからのＵｎｉＤｉｍとＤａｔａＳｏｕｒｃｅＤｉｍとを追加、更新、削除すること、ＵｎｉＤｉｍＮｅｔ構造をＵｎｉＢａｓｅに分布させること、およびＵｎｉＤｉｍＮｅｔに関する他のアクションであって、別の方法ではシステム１００の他のエレメントによって容易に実行されないアクションを容易にする。一実施形態において、ｍａｎａｇｅデータソースロジック１３０５は、システム１００にアクセスできるデータソースの管理を容易にする。ｍａｎａｇｅデータソースロジック１３０５は、任意のステップ、プロセス、方法および／またはソフトウェアコードを含み、データソースの管理と、ディメンションとの関係（インタラクションを含む）の管理を容易にする。他の実施形態において、ルート接続ロジック１３１０は、システム１００の要素間の接続を管理する。ルート接続ロジック１３１０は、任意のステップ、プロセス、方法および／またはソフトウェアコードを含み、システム１００のエレメント、この限りではないが、ＵｎｉＢａｓｅ、データソース、および任意のユーザを含むエレメント間の接続（通信を含む）の経路指定を容易にする。

さらに別の実施形態において、ＵｎｉＳｅｒｖｅｒ１２０は任意でＵｎｉＶｉｅｗクエリーロジック１３１５を含み、これは、ＵｎｉＶｉｅｗの実行中システム１００のアクションとインタラクションとを調整するためのものである。ＵｎｉＶｉｅｗクエリーロジック１３１５は、任意のステップ、プロセス、方法および／またはソフトウェアコードを含み、ＵｎｉＶｉｅｗの実行中システム１００の資源を調整することを容易にする。一実施形態において、ＵｎｉＶｉｅｗクエリーロジック１３１５が設定されることにより、１つ以上の以下のＵｎｉＶｉｅｗ実行設定を容易にする：（１）ＳｈｏｗＳｏｕｒｃｅＢａｓｅｄＤａｔａＯｎｌｙ。この設定下では（図１４に例示される）、ＵｎｉＶｉｅｗは、はじめにそれと関連する表をチェックすることにより、データが既に表にキャッシュされているか否かを判断する（ステップ１４００）。データがキャッシュされていない場合、ＵｎｉＶｉｅｗは適切なデータソースにクエリーをかけ、そこから結果を返す（ステップ１４１０）。結果データは、キャッシュされ（ステップ１４２０）、そのキャッシュされたものにタイムスタンプが設定される（ステップ１４３０）。データがキャッシュされている場合、キャッシュされたデータのタイムスタンプは、対応するＤａｔａＳｏｕｒｃｅＤｉｍのタイムスタンプと比較される（ステップ１４４０）。ＤａｔａＳｏｕｒｃｅＤｉｍのタイムスタンプがキャッシュされたタイムスタンプよりも若い場合、キャッシュは無視され（ステップ１４５０）、ＵｎｉＶｉｅｗはそのデータソースにクエリーをかける（ステップ１４１０）。別の方法では、キャッシュされたデータは回復され（ステップ１４６０）、データソースへのクエリーは必要ではない。（２）ＲｅｃｅｉｖｅＡｌｗａｙｓＦｒｏｍＤａｔａＳｏｕｒｃｅ。この設定下では、ＵｎｉＶｉｅｗは常にデータソースにクエリーをかけて結果を得て、それと関連する表をチェックしてキャッシュされたデータを得るということをしない。（３）ＳｈｏｗＵｎｉＢａｓｅＤａｔａＯｎｌｙ。これは、ＲｅｃｅｉｖｅＡｌｗａｙｓＦｒｏｍＤａｔａＳｏｕｒｃｅとは反対の設定である。この設定下では、ＵｎｉＶｉｅｗは常に、表のキャッシュされたデータを使用し、期限切れのときでさえ使用する。この設定下では、ＵｎｉＶｉｅｗはデータソースにクエリーをかけない。（４）ＳｈｏｗＵｎｓｔａｂｌｅＤａｔａ。この設定下では、ＵｎｉＶｉｅｗははじめに関連する表をチェックしてキャッシュされたデータを得る。キャッシュされたデータがある場合は、期限が切れていても、それを結果として返す。ＵｎｉＶｉｅｗは、ＳｈｏｗＳｏｕｒｃｅＢａｓｅｄＤａｔａＯｎｌｙで示されたプロセスと同様にバックグラウンドでプロセスを継続し、キャッシュされたデータが期限切れの場合、データソースからのデータで返された結果を更新する。はじめに表をチェックするときキャッシュされたデータがその中に存在しない場合、ＵｎｉＶｉｅｗはそのバックグラウンドプロセスを継続する（つまり、データソースにクエリーをかける）。（５）ＤｅｆａｕｌｔＢｅｈａｖｉｏｒ。この設定下では、ＵｎｉＶｉｅｗ自身が、クエリーの実行の仕方を指示するコードを備える。この場合、ＵｎｉＶｉｅｗクエリーロジック１３１５がＵｎｉＶｉｅｗに含まれたステップに従う。ここでは、ある代替的な設定が、ＵｎｉＶｉｅｗクエリーロジック１３１５のために示されているが、ＵｎｉＶｉｅｗクエリーロジック１３１５への適切な設定はいずれも使用され得ることが理解される。

一実施形態において、複合ＵｎｉＶｉｅｗロジック１３２０はＣｏｕｍｐｏｕｎｄＵｎｉＶｉｅｗのプロセスを容易にする。複合ＵｎｉＶｉｅｗロジック１３２０は、任意のステップ、プロセス、方法および／またはソフトウェアコードを含むことにより、ＣｏｍｐｏｕｎｄＵｎｉＶｉｅｗのプロセス（実行）を容易にする。特に、複合ＵｎｉＶｉｅｗロジック１３２０は、ＣｏｍｐｏｕｎｄＵｎｉＶｉｅｗの実行を管理し、さらにその結果、仮想データソースとして作動する。ＣｏｍｐｏｕｎｄＵｎｉＶｉｅｗから呼び出される各ＵｎｉＶｉｅｗのために、複合ＵｎｉＶｉｅｗロジック１３２０は、表のキャッシュチェックと、（キャッシュされたデータがある場合、そのキャッシュされたデータの性質次第では、）データソースのクエリーとを行い、これは、ＳｈｏｗＳｏｕｒｃｅＢａｓｅｄＤａｔａＯｎｌｙで前述したステップに類似する。複合ＵｎｉＶｉｅｗロジック１３２０を、ここではＳｈｏｗＳｏｕｒｃｅＢａｓｅｄＤａｔａＯｎｌｙ設定と関連して説明してきたが、複合ＵｎｉＶｉｅｗロジック１３２０は任意の適切な設定に従うよう設定され得ることが理解される。

一実施形態において、スナップショットとバージョニングロジック１３２５は、ＵｎｉＶｉｅｗクエリー結果の「スナップショット」を保持することを容易にし、さらにそのスナップショットをバージョン識別子でラベリングすることを容易にする。スナップショットとバージョニングロジック１３２５は、任意のステップ、プロセス、方法および／またはソフトウェアコードを含むことにより、ＵｎｉＶｉｅｗクエリー結果のスナップショットとバージョンとを作成することを容易にする。ＵｎｉＶｉｅｗクエリー結果が返されるとき、これは任意で、ＵｎｉＢａｓｅ内のＵｎｉＶｉｅｗに対応する表に記憶される。ＵｎｉＳｅｒｖｅｒの１つの任意的設定下では、このキャッシュされたデータは、この次同じＵｎｉＶｉｅｗがクエリーから更新された結果を返すときに上書きされる。スナップショットとバージョニングロジック１３２５は任意でキャッシュされたデータが表に残ることを可能にする。一実施形態において、特定のキャッシュされた結果はキャッシュ表に項目（たとえば、行）として記憶される。スナップショットとバージョニングロジック１３２５は、その後の返された結果がキャッシュ表の次の行として記憶されることを容易にする。さらに、そのようなキャッシュされた結果を、バージョニング識別子でラベリングすることにより、バージョン比較を容易にする。この点に関して、複数の「スナップショット」（つまり、ＵｎｉＶｉｅｗの以前の実行から返された前の結果）は、キャッシュ表に保持され、そして互いに比較され得る（たとえば、バージョン比較）。

一実施形態において、外部データアクセスを容易にするロジック１３３０は、外部アプリケーション（たとえば、ＯＬＥデータベースデータプロバイダやＯＤＢＣソース）によってシステム１００にアクセスすることを容易にする。外部データアクセスを容易にするロジック１３３０は、任意のステップ、プロセス、方法および／またはソフトウェアコードを含むことにより、外部アプリケーションによるそのようなアクセスを容易にする。この点に関して、システム１００は、直接的なデータ供給者として機能することにより第三者のシステムからクエリーをかけるよう用いられ得る。一実施形態において、そのようなシステムは、システム１００のデータソースとシステム１００のクエリーをかけるパワー（ｑｕｅｒｙｉｎｇ ｐｏｗｅｒ）とにアクセスすることができるよう、いずれかの特定方法（たとえば、ＯＤＢＣ接続を可能にする方法以外）で構成される必要がある。

データソースにあるディメンション事例が固定することはめったにない。データソースのディメンション事例への変更を取り込むために、システム１００は任意でｎｏｔｉｆｉｅｒ１４０を含み（図１参照）、これは、データソース１３０のディメンション事例に起きる変更に関して、ＵｎｉＳｅｒｖｅｒ１４２と通信する。図１５を参照して、ｎｏｔｉｆｉｅｒ１４０は任意で、ルールブック１５００と変更ワークフローロジック１５１０とを含む。ルールブック１５００は、システム１００からアクセスできる各データソースに関連するルールを含むデータベースである。各データソースに対して、その関連するルールは、ディメンション事例における変更（たとえば、追加、削除、または修正）をシステム（たとえば、ＵｎｉＤｉｍＮｅｔ）に取り込むためにこのシステムがとるべき必要なステップを定義する。任意のデータソースのためのルールは、ディメンション事例の変更をシステム１００に統合することを容易にするのに適したルールである。一実施形態において、このルールは、最小限の要求された情報を定義しており、この情報はディメンション事例から検索されて、システム１００にパスされて統合されねばならない。一般的に言うと、そのような情報は、データソース１３０からｎｏｔｉｆｉｅｒ１４０によって検索されて、ＵｎｉＳｅｒｖｅｒ１２０にパスされてシステム１００に統合する。データソースのルールは任意で複雑であり得、最小限のもの（たとえば、ディメンション事例の固有の識別を選択するもの）から入り組んだ複雑なもの（たとえば、カスケーディングセットのクエリーを用いて、データソースのための完全なディメンションの階層を自動的に埋める）まで多岐にわたる。さらに、ルールは、ディメンション事例へのシステム１００のタイムスタンプが修正に基づいて更新されることを指示し得る。

変更ワークフローロジック１５１０は任意で、ｎｏｔｉｆｅｒ１４０のトリガとルールブック１５００の参照を容易にする。変更ワークフローロジック１５１０は、任意ステップ、プロセス、方法および／またはソフトウェアコードを含むことにより、ｎｏｔｉｆｅｒ１４０のトリガとルールブック１５００の参照を容易にする。ディメンション事例への変更は「トリガイベント」と考慮され得、これはｎｏｔｉｆｉｅｒ１４０と、特に変更ワークフローロジック１５１０とをトリガする。トリガイベントは、この限りではないが、ディメンション事例の作成、ディメンション事例の削除、またはディメンション事例の性質への任意の変更（そこにある任意のデータの値の変更も含む）を含み得る。トリガイベントが生じると、変更ワークフローロジック１５１０はトリガされる。変更ワークフローロジック１５１０はルールブック１５００にアクセスすることにより、修正されたディメンション事例をシステム１００に統合するためにどのワークフローステップが実行されるべきかを判断する。変更ワークフローロジック１５１０は、ルールブックに示された全てのステップを行うおよび／または容易にすることにより、修正された事例をシステム１００に取り込む。変更ワークフローロジック１５１０は、ＵｎｉＳｅｒｖｅｒ１２０の外でシステム１００の要素として図示されてきたが、変更ワークフローロジック１５１０（および全てのｎｏｔｉｆｉｅｒ１４０）は任意でＵｎｉＳｅｒｖｅｒ１２０に含まれ得ることが理解される。

ユーザによるシステム１００へのアクセスと使用は、任意の適切なユーザインターフェースによって達成され得る。一実施形態において、図１を参照して、システム１００はさらにＵｎｉＶｉｅｗｅｒ１５０を含む。ＵｎｉＶｉｅｗｅｒ１５０は、ユーザのシステム１００へのアクセスを容易にする。特に、ＵｎｉＶｉｅｗｅｒ１５０により、ユーザは、ＵｎｉＶｉｅｗ、ディメンション、およびディメンション事例を組み合わせることによってシステム１００へのクエリーを設計し、単純なクエリーまたは複雑なクエリーを形成することができる。一般的に言うと、ＵｎｉＶｉｅｗｅｒ１５０は、グラフィカルな環境であり、ここでクエリーはクエリーの構成成分（ディメンションおよびＵｎｉＶｉｅｗ）を「ｒｅｓｕｌｔ」の領域にドラッグすることによって設計され、結果は、特定のディメンション事例を選択することによって結果領域において閲覧される。

図１６と図１９とは例示的なＵｎｉＶｉｅｗｅｒ１５０を示す。ユーザがＵｎｉＶｉｅｗｅｒ１５０を開始すると、ユーザははじめに既存のクエリーと作業するか否か、もしくは新しいクエリーを開始するか否かを決定する。既存のクエリーが選択される場合、そのクエリー（および、ある場合は結果）はグラフィカルユーザインターフェース（ＧＵＩ）によって検索され表示される。新しいクエリーが所望される場合、ユーザは、クエリーを開始するために少なくとも１つの産業ビジネスコンテクストディメンションを選択する。

図１６は例示的なＧＵＩを示す。ユーザが選択したディメンション「場所」１６１０が表示され、ディメンション「場所」にクエリーをかけることができる全てのＵｎｉＶｉｅｗ１６２０が表示される。この例では、ＵｎｉＶｉｅｗ１６２０「ＥＤＣ Ｎａｍｅｓｐａｃｅ」、「Ｓｔｕｄｙ（研究）」および「ＣＲＦ Ｄｅｆｉｎｉｔｉｏｎ（定義）」はＵｎｉＶｉｅｗのグループ（各識別子の左に「＋」で示されている）であり、残りの識別子は個々のＵｎｉＶｉｅｗに関する。ユーザが少なくとも１つのディメンションをこのユーザセッションのはじめに選択すると、ＵｎｉＶｉｅｗｅｒ１５０は１６３０の各ディメンション事例を表示し、このディメンション事例は選択されたディメンションに関連するＵｎｉＤｉｍに含まれる。そのような事例を検索する任意の適切なプロセスが使用され得る。一実施形態において、ＵｎｉＳｅｒｖｅｒは、選択されたディメンションのＵｎｉＤｉｍにリストされる各事例のための固有の識別にアクセスする。固有の識別を検索すると、ＵｎｉＳｅｒｖｅｒはディメンション事例を検索し、１６３０にそれらを表示することができる。結果領域１６４０（現在は空の状態）もまた表示される。

図１７を参照して、ユーザはＵｎｉＶｉｅｗの任意の数を選択し、これを用いてデータソースにクエリーをかける。図１７では、ユーザは、ＵｎｉＶｉｅｗ「定義」、「ＡｄｍｉｎＩＤ」および「ＮａＳｐＩＤ」を選択しており、これらは結果領域１６４０にドラッグされている。各ドラッグされたＵｎｉＶｉｅｗを受け取ると、結果領域１６４０はＵｎｉＶｉｅｗの予期される「ｒｅｓｕｌｔ」のための行を作成する。図１７では、結果領域１６４０は、「定義」ＵｎｉＶｉｅｗの結果のために定義列１７１０を、「ＡｄｍｉｎＩＤ」ＵｎｉＶｉｅｗの結果のためにＡｄｍｉｎＩｄ列１７２０を、および「ＮａＳｐＩＤ」ＵｎｉＶｉｅｗの結果のために「ＮａＳｐＩＤ」列１７３０を表示する。注目すべきは、複数のＵｎｉＶｉｅｗを結果領域１６４０にドラッグすることは複雑なクエリーを例示することである。

クエリーがユーザがＵｎｉＶｉｅｗを選択することによって定義されると、図１８を参照して、ユーザは１つ以上のディメンション事例１６３０を選択して、結果領域１６４０のクエリーにパスし得る（注目すべきは、１つ以上のディメンション事例をパスすることは複雑なクエリーを例示することである）。図１８では、ユーザは「Ｓｔａｄｔ Ｋｌｉｎｉｋ Ｂｏｎｎ」事例を選択した。この事例を選択すると、ＵｎｉＶｉｅｗｅｒ１５０はこの事例をＵｎｉＳｅｒｖｅｒにパスする。ＵｎｉＳｅｒｖｅｒはクエリーの実行を容易にする。各ＵｎｉＶｉｅｗクエリーの結果は、結果を返されると、結果領域１６４０の１８１０に表示される（つまり、「定義」ＵｎｉＶｉｅｗの結果は「Ｋｒｈｓ．」で、「ＡｄｍｉｎＩＤ」ＵｎｉＶｉｅｗの結果は「１１」で、そして「ＮａＳｐＩＤ」ＵｎｉＶｉｅｗの結果は「５」である。）
前記の例が選択されたディメンションの性質を表すＵｎｉＶｉｅｗを用いて図示されているが（たとえば、３つの選択されたＵｎｉＶｉｅｗのそれぞれは、選択されたディメンションの性質―「場所」を返した）、選択可能なＵｎｉＶｉｅｗ（１６１０）は選択されたディメンションと関連する複数の方法を有し得ることが理解される。たとえば、図１９を参照すると、研究限定ＵｎｉＶｉｅｗ（場所限定ＵｎｉＶｉｅｗと比較して）が選択される。選択された研究限定ＵｎｉＶｉｅｗ１９２０「訪問日」は、ＵｎｉＤｉｍＮｅｔにおいて階層的に「場所」よりも低いディメンションに連結される。したがって、選択されたＵｎｉＶｉｅｗは異なる方法でそのデータを検索するよう設定され得る（なぜならば、階層的なＵｎｉＤｉｍＮｅｔでは、「より高い」ＵｎｉＤｉｍ「場所」は１つ〜多数の「より低い」ＵｎｉＤｉｍ「訪問日」に関連することが可能だからである）。たとえば、ユーザは特定の訪問（たとえば、「訪問２」）について、もしくは、結果領域１６４０の列または行に示される複数訪問を用いて複数訪問について訪問日にクエリーをかけることができる。一実施形態において、そのような異なる方法はユーザが選択されたＵｎｉＶｉｅｗ上で右クリックして、可能な「方法」のメニューから所望の「方法」を選択することによって選択され得る。

図１９を参照して、この例では、ユーザは特定の訪問（「訪問２」）について訪問日にクエリーをかけることを選択した。結果領域１６４０は延びることによりカラム「ｖｉｓｉｔ＿ｄａｔａ＿ｖｉｓｉｔ＿２」１９１０を備え、このｖｉｓｉｔ＿ｄａｔａ＿ｖｉｓｉｔ＿２」１９１０は前記のＵｎｉＶｉｅｗから返される結果を含む。異なる複雑なクエリーを用いてデータソースにインタラクティブにクエリーをかけるために、ＵｎｉＶｉｅｗｅｒの追加的なＵｎｉＶｉｅｗが追加、削除、または修正され得ることが理解される。

ＵｎｉＶｉｅｗｅｒ１５０はシステム１００によって作成されるＧＵＩに関して説明されてきたが、任意の適切なステップ、方法、またはロジックがシステム１００によって実行されることによりＵｎｉＶｉｅｗｅｒ１５０のＧＵＩとそれを用いて作成される任意のユーザクエリーの結果とを容易にする。一実施形態において、システム１００が作動中、ＵｎｉＤｉｍＮｅｔはメモリ（たとえば、ＲＡＭ）にロードされる。ユーザがはじめに新しいクエリーのために参照（スタート）ディメンションを選択するとき、「結果セット」オブジェクトが作成されて、ＵｎｉＤｉｍＮｅｔにある選択されたディメンションに付けられる。「結果セット」オブジェクトは、任意の適切なオブジェクトであり得、このオブジェクトには収集、表、またはアレイを含み、そして、作成時「ゼロになる」（つまり空の状態）であり得る。ＵｎｉＶｉｅｗを結果領域にドラッグすると、結果セットオブジェクトはそれに応じて修正され得る。たとえば、ＵｎｉＶｉｅｗのディメンションコンテクスト次第では、結果セットオブジェクトはＵｎｉＤｉｍＮｅｔ内に再び位置付けられ得る。この例では、ＵｎｉＶｉｅｗが「訪問情報」を返し、「患者」ディメンション（ユーザから選択される）にドラッグされる場合、結果セットオブジェクトは「より低い」レベルに移動される（ＵｎｉＤｉｍＮｅｔはＵｎｉＤｉｍ「患者」を「訪問」よりも高いものであると定義する（これは、「患者」が１つ〜多数の「訪問」を有するもとの定義される場合に起きる）と仮定している）。ＵｎｉＶｉｅｗが結果領域にドラッグされると、カラム（たとえば、図１７の１７１０、１７２０、および１７３０を参照）は結果セットオブジェクトに追加される（複雑なクエリーを例示している）。カラムは結果領域にドラッグされた各ＵｎｉＶｉｅｗから返された「ｒｅｓｕｌｔ」によって定義される。ＵｎｉＶｉｅｗクエリー（ディメンション事例がその後にユーザによって選択される後）から返された情報を結果セットオブジェクト（そしてこのようにＧＵＩによってユーザに表示される）に提供するために、結果セットオブジェクトのカラムはＵｎｉＶｉｅｗクエリーの結果を含む表のカラムに直接マッピングされる。結果セットオブジェクト内の結果データはＧＵＩの結果領域内に表示される。

システム１００の使用中、追加で１つのデータソースまたは複数のデータソースをシステム１００に追加することが所望され得る。この場合、システム１００は、任意の適切な方法で修正されることにより、そのような新しいデータソースの追加に応じる。一実施形態において、図２０Ａと図２０Ｂとは、例示的な追加のデータソースを取り込む手順を示す。２００５において、ＵｎｉＳｅｒｖｅｒは停止される。２０１０において、新しいデータソースの追加が、新しい産業ビジネスコンテクストディメンションをＵｎｉＤｉｍＮｅｔに追加することを必要とするかどうかについて決定される。追加のディメンションが必要な場合、もしくは、さもなくとも望ましいとみなされる場合、ＵｎｉＤｉｍＮｅｔは２０１５において各新しいディメンションのための新しいＵｎｉＤｉｍを含むために広げられる。新しいＵｎｉＤｉｍを追加した後（もしくは、新しいＵｎｉＤｉｍが１つも追加されない場合）、２０２０においてＤａｔａＳｏｕｒｃｅＤｉｍが追加のデータソース内の各データソースディメンションのために作成され、全ての新しいＤａｔａＳｏｕｒｃｅＤｉｍはＵｎｉＤｉｍＮｅｔにそれに応じてリンクされる。２０２５において、新しいデータソースクラスは任意で作成され、特にＵｎｉＶｉｅｗを作成する際にＵｎｉＢｕｉｌｄｅｒからの支援（たとえば、ＵｎｉＢｏｔの支援）が所望される場合、作成される。２０３０において、ルールブックと更新ワークフローはシステム１００に作成され記憶される。２０３５において、新しいデータソースがデータアクセスメカニズムの新しいクラスを要求するか否かが任意で決定される。要求する場合、新しいＵｎｉＶｉｅｗクラスが作成されることにより、データソースにクエリーをかけるのに要求されるアクセスメカニズムを要約する、特に、ＵｎｉＶｉｅｗを作成する際にＵｎｉＢｕｉｌｄｅｒからの支援が所望される場合、２０２５で作成されたデータソースクラスは新しいＵｎｉＶｉｅｗクラスに従って修正される。

新しいＵｎｉＶｉｅｗクラスの作成後（またはそのようなクラスが作成されなかった場合）、２０４５においてＵｎｉＳｅｒｖｅｒが再び始められる。２０５０において、新しいデータソースのためのＵｎｉＶｉｅｗが任意の適切な方法によって作成され、この方法には手動もしくはＵｎｉＢｕｉｌｄｅｒ（とくに、新しいＵｎｉＶｉｅｗクラスが作成されていた場合はＵｎｉＢｏｔ）からの支援による方法が含まれる。２０５０において、新しいＵｎｉＶｉｅｗはＵｎｉＶｉｅｗツリーに含まれる。２０６０において、新しいデータソース事例は、システム１００に登録され、ＵｎｉＤｉｍＮｅｔ内の各事例に関連する全ての要求される情報を登録することと記憶することとを含む。ｎｏｔｉｆｉｅｒは新しい事例（図示せず）に反応することにより、新しい事例をシステム１００にさらに統合させる。

システム１００へのアクセスとその使用に関連するセキュリティは任意の適切なメカニズムによって果たされることが理解される。一実施形態において、ユーザに利用可能なＵｎｉＶｉｅｗの完全セットは、ユーザのアクセス権によって定義される。各ユーザは、そのユーザが閲覧および／またはアクセスすることができるＵｎｉＶｉｅｗの厳密に定義されたセットを有する。この点に関して、データソース（およびそこの中にあるデータ）へのアクセスは制御され得る（たとえば、１つの特定データに対するＵｎｉＶｉｅｗが存在しない場合、そのデータはユーザに返されず、さらに、１つの特定データソースに対するＵｎｉＶｉｅｗにユーザがアクセスできるものがない場合、そのユーザはそのデータソースにアクセスすることができない）。さらに、ディメンション事例へのアクセスはまた、ユーザ限定アクセス権を介して制限され得る（つまり、ユーザは特定事例へのアクセス権を与えられない場合、そのユーザはその事例に関するデータを受け取ることを禁止され得る）。

図２１は、本発明のデータを統一する方法の実施形態を示す。この実施形態において、ステップ２１１０において複数の産業ビジネスコンテクストディメンションが定義される。任意の適切なディメンションは産業のために定義され得、この限りでないが、前記のようなものを含む。ステップ２１２０において、複数のデータソース特定ディメンションがクエリーをかけられ得るデータソース毎に定義される。適切なデータソース特定ディメンションは定義され得、この限りでないが、前記のようなものを含む。ステップ２１３０において、定義されたディメンションとデータソース特定ディメンションの表象を含むデータベース（たとえば、ＵｎｉＤｉｍＮｅｔ）が提供される。任意の適切なデータベースが提供され得、この限りではないが、前述のようなＵｎｉＤｉｍＮｅｔを含む。ステップ２１４０において、データソース毎に適応された複数のクエリー（たとえば、ＵｎｉＶｉｅｗ）が提供される。任意の適切なクエリーが提供され得、この限りではないが、前述のようなＵｎｉＶｉｅｗ、ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅおよびＣｏｍｐｏｕｎｄＵｎｉＶｉｅｗを含む。各クエリーが提供されることにより、データソースへのアクセスを容易にするデータアクセスメカニズムを用いてデータソースをアクセスする。ステップ２１５０において、少なくとも１つのデータソースが、少なくとも１つの提供されたクエリーを用いてクエリーをかけられる。たとえば、前述したように、ＵｎｉＶｉｅｗが使用されることにより、ＵｎｉＶｉｅｗに関連するデータソースにクエリーをかける。ステップ２１６０において、クエリーの結果は、ユーザに提供される。そのような結果をユーザに提供する任意の適切なステップが使用され得、この限りではないが、前述のようにＵｎｉＶｉｅｗｅｒから提供されるＧＵＩの使用を含む。

前記の方法は、追加の適切なステップを含み得、前記の各ステップは追加のサブステップを備え得ることが理解される。たとえば、図２２の参照において、ステップ２１２０は任意でステップ２２１０〜ステップ２２５０を含む。ステップ２２１０において、データベース内のオブジェクトが作成されることにより、各産業ビジネスコンテクストディメンションを表す。任意の適切なオブジェクトが使用され得、前述のように表形式のＵｎｉＤｉｍを含む。ステップ２２２０において、各オブジェクトは少なくとも１つの他のオブジェクトに関連する。オブジェクトは任意の適切な方法で関連し得、前述のようにＵｎｉＤｉｍの階層的な関係を含む。ステップ２２３０において、データベースのオブジェクトが作成されることにより、各データソース特定ディメンションを表す。任意の適切なオブジェクトが作成され得、前述のように表形式のＤａｔａＳｏｕｒｃｅＤｉｍを含む。ステップ２２４０において、各データソース特定ディメンションオブジェクトは、少なくとも１つの産業ビジネスコンテクストディメンションオブジェクトに関連する。データソース特定ディメンションオブジェクトは任意の適切な方法で産業ビジネスコンテクストディメンションオブジェクトに関連し得、前述のようなものを含む。ステップ２２５０において、データベースのオブジェクトが関連する情報とともに追加される。任意の関連情報は任意の適切な方法でオブジェクトに記憶され得る。たとえば、ここで前述したように、ＵｎｉＤｉｍとＤａｔａＳｏｕｒｃｅＤｉｍとはディメンション事例毎に固有の識別とＰＯＰＵＬＡＴＥされる。

当業者は、本発明は例示的な実施形態の前記ステップを全て利用せずとも、もしくは、そのステップが前記の順番で実行されなくとも、現実化され得ることを理解する。

本発明は、好ましい実施形態を参照して説明された。この明細を読んで理解することを踏まえて、修正および改変が起こる。そのような修正と改変とが添付の請求項もしくはこれに対応するものの範囲内である限り、それらが含まれることが意図される。

図１は、本発明の一実施形態に従った、データを統一するシステムの例示的な全体のシステム図である。 図２は、本発明の一実施形態に従った、データベースの例図である。 図３は、本発明の一実施形態に従った、データ構造の例図である。 図４は、本発明の一実施形態に従った、ディメンションのデータ構造の例図である。 図５Ａ、５Ｂ、５Ｃは、本発明の一実施形態に従った、データソースデータ構造の例図である。 図６Ａは、本発明の一実施形態に従った、データ構造の関係の例図である。 図６Ｂは、本発明の一実施形態に従った、データ構造の関係の例図である。 図６Ｃは、本発明の一実施形態に従った、データ構造の関係の例図である。 図７は、本発明の一実施形態に従った、複数のデータソース間のデータ構造の関係の例図である。 図８は、本発明の一実施形態に従った、表と表の関係との例図である。 図９は、本発明の一実施形態に従った、ＵｎｉＶｉｅｗの関係の例図である。 図１０は、本発明の一実施形態に従った、ＵｎｉＶｉｅｗＩｎｔｅｒｆａｃｅの例図である。 図１１は、本発明の一実施形態に従った、ＣｏｍｐｏｕｎｄＵｎｉＶｉｅｗの例図である。 図１２は、本発明の一実施形態に従った、ＵｎｉＢｕｉｌｄｅｒの例図である。 図１３は、本発明の一実施形態に従った、ＵｎｉＳｅｒｖｅｒの例図である。 図１４は、本発明の一実施形態に従った、データ検索方法の例示的なフローチャートである。 図１５は、本発明の一実施形態に従った、Ｎｏｔｉｆｅｒの例図である。 図１６は、本発明の一実施形態に従った、ＵｎｉＶｉｅｗｅｒインターフェースの例示的な画面ショットである。 図１７は、同じくＵｎｉＶｉｅｗｅｒインターフェースの例示的な画面ショットである。 図１８は、同じくＵｎｉＶｉｅｗｅｒインターフェースの例示的な画面ショットである。 図１９は、同じくＵｎｉＶｉｅｗｅｒインターフェースの例示的な画面ショットである。 図２０Ａは、本発明の一実施形態に従った、データソースを追加する方法の例示的なフローチャートである。 図２０Ｂは、本発明の一実施形態に従った、データソースを追加する方法の例示的なフローチャートである。 図２１は、本発明の一実施形態に従った、データを統一する方法の例示的なフローチャートである。 図２２は、本発明の一実施形態に従った、データを統一する方法のステップの例示的なフローチャートである。

Claims (23)

1. 産業に関連するデータのロジック的グルーピングを定義する複数の産業-ビジネスコンテクストディメンションを有する該産業に関するデータを統一するシステムであって、
   少なくとも１つのデータソースは、少なくとも１つの他のデータソースから異なる物理的またはロジック的構造を有しており、各データソースは、少なくとも１つの産業ビジネスコンテクストディメンションに関連するデータを含む、少なくとも１つのデータソース特定ディメンションにロジック的概念的にグルーピングすることが可能であるデータを有しており、および各データソースは、そこへのクエリーを容易にするデータアクセスメカニズムを有する、複数のデータソースと、
   第１の複数のノードと第２の複数のノードとを有するデータベースであって、
   該第１の複数のノードのそれぞれは、産業ビジネスコンテクストディメンションを表しており、該第２の複数のノードのそれぞれは、少なくとも１つの該データソースのデータソース特定ディメンションを表しており、該第１の複数のノードのそれぞれは、少なくとも１つの他の該第１の複数のノードに関連しており、および該第２の複数のノードのそれぞれは、少なくとも１つの該第１の複数のノードに関連する、データベースと、
   複数のデータソースクエリー機能呼出しであって、各クエリー機能呼出しは、１つのデータソース特定ディメンションに関する１つのデータソースにクエリーをかけ、各クエリー機能呼出しは、該１つのデータソースの該データアクセスメカニズムを使用することにより該１つのデータソースへのアクセスを容易にする、複数のデータソースクエリー機能呼出しと
   を備えた、システム。
2. 各ディメンションは、少なくとも１つのディメンション事例を有しており、少なくとも２つの前記データソースのそれぞれは、他方から異なる物理的またはロジック的構造を有しており、かつ該少なくとも２つのデータソースのそれぞれは、ディメンション事例に関連するデータを有しており、
   前記システムは、
   少なくとも１つの複雑なクエリーであって、該複雑なクエリーは複数のデータソースクエリー機能呼出しを備え、該複雑なクエリーは、該ディメンション事例に関連するデータを求めて、該少なくとも２つのデータソースにクエリーをかけ、該複数のデータソースクエリー機能呼出しを呼び出すことにより、該ディメンション事例に関連する該データを求めて、該少なくとも２つのデータソースに該クエリーをかけることを行う、少なくとも１つの複雑なクエリー
   をさらに備え、
   該ディメンション事例に関連する該データは、該少なくとも２つのデータソースのそれぞれから検索される、請求項１に記載のシステム。
3. 各ディメンションは、少なくとも１つのディメンション事例を有しており、
   該システムは、
   ユーザからのクエリーから返されたデータによって加えられた少なくとも１つの結果セットオブジェクトをさらに備え、
   該ユーザからの該クエリーは、どのデータソースにクエリーをかけるのかについてユーザによる識別なしに少なくとも１つのディメンション事例と、少なくとも１つのクエリー機能呼出しとの選択を含む、請求項１に記載のシステム。
4. 複数のクエリー機能呼出しを呼び出すことにより、該複数のデータソースにクエリーをかける、少なくとも１つの複雑なクエリーをさらに備え、
   該１つの複雑なクエリーは、クエリーをかけるためにいずれかのデータソースを識別しない、請求項１に記載のシステム。
5. 複数のデータソースに位置付けられたデータのための少なくとも１つの複雑なクエリーであって、該複雑なクエリーは、複数のクエリー機能呼出しを呼び出すことにより、該データを求めて該複数のデータソースにクエリーをかけ、該複雑なクエリーは、クエリーをかけられるための該データを定義する入力パラメーターセットを有する、少なくとも１つの複雑なクエリー、をさらに備え、
   該入力パラメーターセットは、少なくとも、１つのディメンション事例と、クエリー結果と、クエリーをかけられる該データの定義とからなる、請求項１に記載のシステム。
6. 前記クエリーをかけられるデータの前記定義は、ｅｘａｃｔ＿ｒｅｑｕｅｓｔ＿ｆｏｒ＿ｉｎｆｏｒｍａｔｉｏｎである、請求項５に記載のシステム。
7. 産業に関連するデータのロジック的グルーピングを定義する、複数の産業ビジネスコンテクストディメンションを有する該産業に関連するデータを管理するシステムであって、
   該データは、複数のデータソースに含まれており、少なくとも１つのデータソースは、少なくとも１つの他のデータソースから異なる物理的またはロジック的構造を有しており、各データソースは、少なくとも１つの産業ビジネスコンテクストディメンションに関連するデータを含む、少なくとも１つのデータソース特定ディメンションにロジック的概念的なグループピングが可能であるデータを有しており、各データソースは、データソースへのクエリーを容易にするデータアクセスメカニズムを有しており、
   該システムは、
   ＵｎｉＤｉｍＮｅｔと複数のＵｎｉＶｉｅｗとを備えた、システム。
8. 前記ＵｎｉＤｉｍＮｅｔは、
   複数のＵｎｉＤｉｍであって、各ＵｎｉＤｉｍは、産業ビジネスコンテクストディメンションを表しており、各ＵｎｉＤｉｍは、少なくとも１つの他のＵｎｉＤｉｍに関連する、複数のＵｎｉＤｉｍと、
   複数のＤａｔａＳｏｕｒｃｅＤｉｍであって、各ＤａｔａＳｏｕｒｃｅＤｉｍは、データソースのデータソース特定ディメンションを表しており、かつ各ＤａｔａＳｏｕｒｃｅＤｉｍは、少なくとも１つのＵｎｉＤｉｍに関連する、複数のＤａｔａＳｏｕｒｃｅＤｉｍと
   をさらに備えた、請求項７に記載のシステム。
9. 各ＵｎｉＤｉｍと各ＤａｔａＳｏｕｒｃｅＤｉｍとは、データベースに含まれるネットワークのノードである、請求項８に記載のシステム。
10. 各ノードは表である、請求項９に記載のシステム。
11. 各ディメンションは、少なくとも１つディメンション事例を有しており、各ディメンション事例は、固有の識別を有しており、
    各ＵｎｉＤｉｍ表は、該ＵｎｉＤｉｍが関連する該ディメンションの各ディメンション事例の該固有の識別を含む、請求項９に記載のシステム。
12. 各ＵｎｉＶｉｅｗは、前記データソースの前記データアクセスメカニズムを用いることによって、１つのデータソース特定ディメンションに関する１つのデータソースにクエリーをかけるクエリー機能呼出しである、請求項７に記載のシステム。
13. 少なくとも１つの複雑なクエリーをさらに備えた、請求項１２に記載のシステム。
14. 前記複雑なクエリーは入力パラメーターのセットを有しており、
    該入力パラメーターのセットはデータソースを識別しない、請求項１３に記載のシステム。
15. ＵｎｉＶｉｅｗｅｒをさらに備えた、請求項７のシステム。
16. 産業に関連するデータのロジック的グルーピングを定義する、複数の産業ビジネスコンテクストディメンションを有する該産業に関連するデータを管理する方法であって、
    該データは、複数のデータソースに含まれており、少なくとも１つのデータソースは、少なくとも１つの他のデータソースから異なる物理的またはロジック的構造を有しており、各データソースは、少なくとも１つの産業ビジネスコンテクストディメンションに関連するデータを含む、少なくとも１つのデータソース特定ディメンションにロジック的概念的なグループピングが可能であるデータを有しており、各データソースは、データソースへのクエリーを容易にするデータアクセスメカニズムを有しており、
    該方法は、
    複数の産業ビジネスコンテクストディメンションを識別するステップと、
    少なくとも１つのデータソース特定ディメンションをデータソース毎に識別するステップと、
    ＵｎｉＤｉｍＮｅｔを提供するステップと、
    複数のＵｎｉＶｉｅｗを提供するステップと、
    複雑なクエリーを立てるステップであって、該複雑なクエリーは、該ＵｎｉＤｉｍＮｅｔを用いることにより、少なくとも１つのＵｎｉＶｉｅｗを呼び出して少なくとも１つのデータソースにクエリーかける際に支援する、ステップと、
    該クエリーの結果をユーザに提供するステップと
    を包含する、方法。
17. 前記ＵｎｉＤｉｍＮｅｔステップを提供することは、
    ＵｎｉＤｉｍを産業ビジネスコンテクストディメンション毎に作成するステップと、
    各ＵｎｉＤｉｍを少なくとも１つの他のＵｎｉＤｉｍに関連付けるステップと
    をさらに包含する、請求項１６に記載の方法。
18. 前記ＵｎｉＤｉｍＮｅｔステップを提供することは、
    ＤａｔａＳｏｕｒｃｅＤｉｍを各データソースのデータソース特定ディメンション毎に作成するステップと、
    各ＤａｔａＳｏｕｒｃｅＤｉｍを少なくとも１つのＵｎｉＤｉｍに関連付けるステップと
    をさらに包含する、請求項１７に記載の方法。
19. 各ディメンションは、少なくとも１つのディメンション事例を有し、前記ＵｎｉＤｉｍＮｅｔステップを提供することは、
    該ＵｎｉＤｉｍＮｅｔにおける各ＵｎｉＤｉｍと各ＵｎｉＳｏｕｒｃｅＤｉｍとを各ディメンション事例に関連するデータに加えるステップをさらに包含する、請求項１８に記載の方法。
20. 産業に関連するデータのロジック的グルーピングを定義する、複数の産業ビジネスコンテクストディメンションを有する該産業に関連するデータをクエリーするシステムであって、該データは、複数のデータソースに含まれており、少なくとも１つのデータソースは、少なくとも１つの他のデータソースから異なる物理的またはロジック的構造を有しており、各データソースは、少なくとも１つの産業ビジネスコンテクストディメンションに関連するデータを含む、少なくとも１つのデータソース特定ディメンションにロジック的概念的なグループピングが可能であるデータを有しており、各データソースは、データソースへのクエリーを容易にするデータアクセスメカニズムを有しており、該データソースはデータを統一するシステムの一部であり、該システムは複数のデータソースクエリー機能呼出しを有しており、各クエリー機能呼出しは、１つのデータソース特定ディメンションに関する１つのデータソースにクエリーをかけ、各ディメンションは少なくとも１つのディメンション事例を有しており、
    該方法は、
    ユーザからクエリーをかけられるディメンションの前記識別を受け取るステップと、
    該ユーザに複数のデータソースクエリー機能呼出しを提供し、該ユーザは、そこから少なくとも１つのデータソースクエリー機能呼出しを選択し得るステップと、
    該ユーザから選択された該データソースクエリー機能によって定義されるカラムを有する結果セットを作成するステップと、
    該ユーザから少なくとも１つのディメンション事例の該識別を受け取ることにより、関連するクエリーを行うステップと、
    該結果セットの該カラムに該クエリーから検索されるデータを加えるステップと
    を包含する、方法。
21. 前記ユーザに前記選択されたディメンションに利用可能なディメンション事例のリストを提供するステップをさらに包含する、請求項２０に記載の方法。
22. 選択されたデータソースクエリー機能への前記ユーザによる変化に基づいて、前記結果フィールドを修正するステップをさらに包含する、請求項２０に記載の方法。
23. 選択された前記ディメンション事例への前記ユーザによる変化に基づいて、前記結果フィールドを修正するステップをさらに包含する、請求項２０に記載の方法。

Images