JP5047806B2 - データ・ウェアハウジングのための装置および方法 - Google Patents

Description

本発明は、コンピュータ・システムに関し、より詳細には、データ・ウェアハウジング・システムの実装に関する。

ある企業内のビジネス機能のますます多くが自動化されるにつれて、その企業によって生み出されるデータの量も、それに応じて増大する。このようなデータは、企業のいたるところに、たとえば、さまざまな部署や地理的な単位によって実現されているデータベース・システムや他のタイプのシステム内に分散されている。場合によっては、システムどうしの間または位置の間に存在する固有の境界を越えて、企業データの有用な分析を行うことができる。このような分析を容易にするために、データ・ウェアハウジング・システムを採用して、複数の異なるシステムまたは位置からのデータを、単一のデータベースなどの単一のシステム内に集約するようにしている。そして分析ツールは、さまざまな分散されたデータ・ソースではなく、単一の集約されたシステムを対象とすることになり、それによって、分析ツールの設計を単純化し、分析パフォーマンスを改善することができる。

データ・ウェアハウジング・システムは、必要とされる分析パフォーマンスを提供するように構成されているハイエンドのコンピュータ・システムを使用して、非常に大量のデータの保存や問合せをサポートする場合が多い。しかし、特定のデータ・ウェアハウジング・アプリケーション向けに高度に調整されたハイエンドのシステムは、入手して維持する上で高くつくことがあり、企業のデータ・ウェアハウジングのニーズの増大に合わせて拡張することはできない。たとえば費用の理由から、単一のデータ・ウェアハウジング・システムしか用意されない場合には、その単一のウェアハウスに障害が発生すると、データの可用性が脅かされるおそれがある。その一方で、複数のデータ・ウェアハウジング・システムが用意される場合には、分析アプリケーションは、単一の集約されたデータ・ソースを前提とするシンプルさを失うおそれがある。たとえば分析アプリケーションは、複数のデータ・ウェアハウス内における所望のデータの位置を追跡把握するように構成する必要がある。

データ・ウェアハウジング・システムを実装するための装置および方法のさまざまな実施態様を開示する。一実施態様によれば、あるシステムは、複数のデータ・ウェアハウスと、それらのデータ・ウェアハウスのうちの１つまたは複数の中に保存するために、１つまたは複数のデータ・ソースからデータ・セットを抽出するように構成されているデータ・ウェアハウス・マネージャーとを含む。複数のデータ・ウェアハウスのそれぞれは、データ・ウェアハウス・マネージャーによって抽出されたデータ・セットのそれぞれのレプリカを保存するように構成されている。さらにデータ・ウェアハウス・マネージャーは、データ・セットのそれぞれの各レプリカがデータ・ウェアハウスのうちの対応するさらなる１つへ保存される前に、そのデータ・セットに依存する問合せがデータ・ウェアハウスのうちの１つによって評価されるように構成させることができる。同様にデータ・ウェアハウス・マネージャーは、データ・セットに対する修正が、対応するさらなるデータ・ウェアハウスへ複製される前に、そのデータ・セットに依存する問合せがデータ・ウェアハウスのうちの１つによって評価されるようにさらに構成されている。

一実施態様によれば、１つまたは複数のデータ・ウェアハウスの中に保存するために１つまたは複数のデータ・ソースからデータ・セットを抽出するステップと、複数のデータ・ウェアハウスを含む第１のサブセットのそれぞれの中に第１のデータ・セットのそれぞれのレプリカを保存するステップと、第１のデータ・セットのそれぞれの各レプリカが第１のサブセットの対応するデータ・ウェアハウスへ保存される前に、その第１のデータ・セットに依存する問合せがデータ・ウェアハウスの第１のサブセットのうちの１つによって評価されるステップとを含む方法がさらに考えられる。

第２の実施態様によれば、あるシステムは、１つまたは複数のデータ・ソースから抽出されたデータ・セットを保存するように構成されているデータ・ウェアハウスと、それらのデータ・ウェアハウスを単一のデータ・ウェアハウスとしてクライアントに提示するように構成されているデータ・ウェアハウス・マネージャーとを含む。それらのデータ・ウェアハウス内におけるデータ・セットの位置は、クライアントにとってトランスペアレントである。また、問合せを行うためにクライアントにとって特定の時点において利用可能な、第１のデータ・ウェアハウスによって保存されている第１のデータ・セットは、問合せを行うためにクライアントにとってその特定の時点において利用可能な、第２のデータ・ウェアハウスによって保存されている第２のデータ・セットとは、その特定の時点において異なるものとすることができる。それらのデータ・ウェアハウスのうちの１つまたは複数によって保存されているデータ・セットを対象とする問合せをクライアントから受信したことに応答して、データ・ウェアハウス・マネージャーは、その問合せを評価することができるデータ・ウェアハウスのうちの特定の１つを識別するように、かつ評価のためにその問合せをその特定のデータ・ウェアハウスへ伝達するようにさらに構成されている。

一実施態様によれば、１つまたは複数のデータ・ウェアハウスの中に保存するために１つまたは複数のデータ・ソースからデータ・セットを抽出するステップと、それらのデータ・ウェアハウスを単一のデータ・ウェアハウスとしてクライアントに提示するステップとを含む方法がさらに考えられる。それらのデータ・ウェアハウス内におけるデータ・セットの位置は、クライアントにとってトランスペアレントである。それらのデータ・ウェアハウスのうちの１つまたは複数によって保存されているデータ・セットを対象とする問合せをクライアントから受信したことに応答して、この方法は、その問合せを評価できるデータ・ウェアハウスのうちの特定の１つを識別し、評価のためにその問合せをその特定のデータ・ウェアハウスへ伝達するステップを含む。問合せを行うためにクライアントにとって特定の時点において利用可能な、第１のデータ・ウェアハウスによって保存されている第１のデータ・セットは、問合せを行うためにクライアントにとってその特定の時点において利用可能な、第２のデータ・ウェアハウスによって保存されている第２のデータ・セットとは、その特定の時点において異なるものとすることができる。

本発明は、さまざまな修正および代替形態を受け入れることができるが、その特定の実施形態を例示として図面に示し、ここで詳細に説明する。しかし、図面やそれに対する詳細な説明は、開示されている特定の形態に本発明を限定することを意図するものではなく、それどころか、添付の特許請求の範囲によって定義される本発明の趣旨と範囲内に収まるすべての修正、均等物、および代替物をカバーすることを意図しているということを理解されたい。

データ・ウェアハウジング・システムの概要
いくつかの複雑な企業コンピューティング環境においては、データのさまざまなソースは、企業のいたるところに分散されている。たとえば企業は、経理、財務、ｅコマース、人事、購買、製造、販売など、さまざまなビジネス機能ごとに、別々のコンピュータ・システムおよび／またはアプリケーションを実現している。さらに、そのようなシステムおよび／またはアプリケーションは、たとえば、それぞれの販売サイトに販売管理システムを提供することによって、地理的に分散され、複製されている。このようないくつかの企業においては、データベースや他のデータ・ストア、さらには分析ツールや他のアプリケーションを、サイトまたは機能に固有のものとすることができ、また他の機能またはサイトのためのシステムと周辺的に対話することができる。

特定のビジネス機能またはサイトに、その業務の大部分を実行するのにちょうど必要なだけのデータとリソースを提供することによって、企業内で過剰なリソースすなわち余分なリソースを割り当てることを回避することができる。しかし場合によっては、その企業全体からのデータをまとめて分析する必要が生じるかもしれない。たとえば、企業規模の財務トレンドや生産トレンドの分析は、複数の異なるサイトにおいて、あるいはさまざまな部署にわたって生成され保持されるデータに依存する可能性がある。場合によっては、データ分析ツールを、単独のビジネス機能を個別に分析しても直接は認識できない複数のビジネス機能にわたる複雑な相互関係を検知するように構成することができる。たとえば、（人事によって追跡把握される）人事上の経験と研修との間に、また販売面での生産性と財務面でのパフォーマンスとの間に（たとえば、販売面でのエラーに起因する返品数の減少などの）関係が存在するかもしれない。このような関係は、相関関係を探してこれらの機能のそれぞれからのデータをまとめて調べることによって、識別することができる。

いくつかの実施形態においては、企業は、企業規模のデータの処理と分析を容易にするために、集中されたデータ・ウェアハウジング・システムを設けることができる。一般的に言えば、データ・ウェアハウスは、１つまたは複数のデータ・ソースに保存されているデータを集約するように構成されているデータベースや他のデータ・リポジトリを含む。それらのデータ・ソース自体は、データを保存したり生成したりする企業内の他のデータベースや他のアプリケーションであるかもしれない。データ・ウェアハウス内に保存されるデータは、企業内の他の位置に保存されているデータの派生物であることが多い。しかし場合によっては、データ・ウェアハウスは、企業規模の分析データ、あるいは企業の機能またはサイトのデータなど、いくつかのデータのためのプライマリー・ストレージとしての役割を果たすように構成させることもできる。

データ・ウェアハウス・システムの一実施形態が、図１に示されている。図示されている実施形態においては、データ・ウェアハウス・システム１００は、データ・ウェアハウス・マネージャー１１０を含む。このデータ・ウェアハウス・マネージャー１１０は、図１のデータ・ウェアハウス１２０ａ〜ｄによって表されている複数のデータ・ウェアハウスと対話するように構成されている。図１に示されているデータ・ウェアハウス１２０ａ〜ｄの数は、例示的なものにすぎず、他の実施形態においては、異なる数とすることができる。データ・ウェアハウス・マネージャー１１０は、オペレーション・データベース１３０と対話するように構成させることもできる。データ・ウェアハウス・マネージャー１１０はまた、データ・ウェアハウス・システム１００の外部に存在する（たとえば、１つの企業のいたるところに、あるいは複数の企業にわたって、さまざまな論理上のサイトや物理的なサイトに分散されている）可能性のある１つまたは複数のクライアント１４０やデータ・ソース１６０と対話するように構成される。いくつかの実施形態においては、いくつかのクライアント１４０を、ウェブ・サービス・インターフェース１５０を通じてデータ・ウェアハウス・マネージャー１１０と対話するように構成することができる。いくつかの実施形態においては、データ・ウェアハウス・マネージャー１１０は、ウェブ・サービス・インターフェース（図示せず）を通じていくつかのデータ・ソース１６０と対話するように構成される。

一実施形態においては、データ・ウェアハウス１２０ａ〜ｄは、それぞれのリレーショナル・データベースを含む。たとえば特定のデータ・ウェアハウス１２０は、Ｏｒａｃｌｅ、ＤＢ２、Ｓｙｂａｓｅ、Ｉｎｆｏｒｍｉｘ、Ａｄａｂａｓ、あるいは他の任意の独自仕様のデータベースやオープンソースのデータベースなどのデータベースを含む。いくつかの実施形態においては、さまざまなデータ・ウェアハウス１２０は、さまざまなベンダからのさまざまなタイプのデータベース・ソフトウェアを実装することができる。一般的に言えば、リレーショナル・データベースは、データ項目のセットを、行と列とを含むテーブルなど、１つまたは複数の規則正しい構造へ編成する（ただし、多次元のリレーショナル・データベース構造も考えられる）。さらに、多くの実施形態においては、リレーショナル・データベースを、特定の問合せを満たすデータのサブセットを選択するために、データベース内に保存されているデータに照らして問合せを評価するように構成することができる。たとえばデータベースは、顧客注文情報を保存するように構成される。この顧客注文情報を、顧客識別子、注文識別子、発送状況情報、注文コストなどのデータを含む１つまたは複数のテーブルとして編成することができる。未処理の発送を待っているすべての顧客を識別したいと望むユーザは、特定の日付および／または時刻において未発送の注文を有するすべての顧客識別子の選択を指定して、データベースに問合せを送信することができる。これに応答して、データベースは、その中身を調べて、その問合せの制約を満たすデータ・レコードを返すことができる。いくつかの実施形態においては、さまざまなデータ・ウェアハウス１２０を、さまざまな物理的な位置すなわちサイトに配置することができ、これは、後述のようなデータ・セットの複製とあいまって、単一のサイトにおける障害によってすべてのデータ・ウェアハウス１２０が脅かされる可能性を減らすことによって、データ・セットの信頼性および可用性を高めることができるという点に留意されたい。

データ・ウェアハウス１２０は、一般にリレーショナル・データベースを含むが、いくつかの実施形態においては、特定のデータ・ウェアハウス１２０は、非リレーショナル・データベースを含むという点に留意されたい。通常、リレーショナル・データベースにおいては、特定のデータ項目の意味は、テーブルや他のリレーショナル・データ構造内におけるそのデータ項目の位置によって暗に示される。たとえば、特定の２次元のリレーショナル・データベース・テーブルにおいては、ある列は、顧客識別子を保存し、別の列は、発送状況情報を保存するようにすることができ、第３の列は、注文コストを保存するように決めることができる。そしてテーブルの個々の行は、特定の注文レコードに対応することができ、行の１列目に保存されるいかなるデータ項目も、その位置によって顧客識別子と解釈される。これとは対照的に、一実施形態においては、非リレーショナル・データベースが、決められたデータ構造内におけるデータ項目の位置によってではなく、特定のデータ項目に関連付けられた明示的なメタデータによって解釈が統制されるデータ項目を保存することができる。たとえば一実施形態においては、データ・ウェアハウス１２０は、データ項目を、あるバージョンのＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）によって区切られたレコードとして保存するように構成される。このような一実施形態においては、顧客識別子などの特定のデータ項目は、そのタイプのデータ項目を識別するメタデータのフィールドまたはタグによって区切ることができる。たとえば顧客識別子「smith」は、「<cust_id>smith</cust_id>」として保存することができ、この場合、メタデータのタグcust_idは、このタグによって区切られているデータが顧客識別子として解釈できることを示している。一般に、非リレーショナル・データベース内のレコードのデータ項目は、そのレコード内で任意の順序で保存することができる。というのも、特定のデータ項目の意味は、そのデータ項目の位置を介して暗示的にではなく、そのデータ項目と共に明示的に保存されるためである。

前述のように、いくつかの実施形態においては、データ・ウェアハウス１２０は、データ・ソース１６０によってなど、企業内の他の位置に保存されているデータを集約するように構成される。いくつかの実施形態においては、以降でさらに詳しく説明するように、データ・ウェアハウス１２０によって保存されるデータの量は、たとえば数ＴＢ（ｔｅｒａｂｙｔｅ）規模など、非常に多くなることがある。図示されている実施形態においては、データ・ウェアハウス・マネージャー１１０は、データ・ウェアハウス１２０どうしの間でデータがどのように検索され保存されるかを調整するように、ならびにクライアント１４０などのクライアントによるデータ・ウェアハウス１２０へのアクセスを調整するように構成される。具体的には、一実施形態においては、データ・ウェアハウス・マネージャー１１０（あるいは、単にマネージャー１１０）は、１つまたは複数のデータ・ソース１６０からデータを抽出するように、およびデータ・ウェアハウス１２０のうちの１つまたは複数における抽出されたデータの保存を調整するように構成される。

場合によっては、マネージャー１１０は、抽出されたデータを、保存前にさらに変換することができる。たとえば一実施形態においては、特定のデータ・ウェアハウス１２０は、いくつかの異なるデータ・ソース１６０から得られたデータを含むテーブルを保存する。このような一実施形態においては、マネージャー１１０は、さまざまなデータ・ソース１６０から引き出された個々のデータ項目を、特定のデータ・ウェアハウス１２０によって必要とされるフォーマットへと変換するように構成される。いくつかの実施形態においては、データの変換は、データをアレンジし直したり、フォーマット設定し直したりすることとは対照的に、データそのものの修正を含む。たとえば、いくつかの実施形態においては、マネージャー１１０を、特定のデータ項目を、データ・ウェアハウス１２０内に保存する前に増減または四捨五入するように構成させ、あるいは他の任意の適切な変換を施すこともある。いくつかの実施形態においては、マネージャー１１０を抽出／変換／ロード（ＥＴＬ）マネージャーと呼ぶこともできる。

図示されている実施形態においては、オペレーション・データベース１３０を、データ・ウェアハウス・システム１００の動作状態に関する情報を保存して追跡把握するように構成し、それらの情報としては、データ・ウェアハウス１２０内における（たとえば、テーブルや個々のレコードなどの）データ項目やデータのセットの位置、ならびにデータ・ウェアハウス１２０内のデータを修正するための未処理のオペレーションに関するデータ項目やデータ・セットの状態に関する情報を含む。いくつかの実施形態においては、オペレーション・データベース１３０は、その中身にアクセスして修正を行うための問合せインターフェースを含む上述のものと同様のリレーショナル・データベースまたは非リレーショナル・データベースを含み、その一方で、他の実施形態においては、オペレーション・データベース１３０は、たとえばカスタムＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）内で規定されるプロシージャーの呼び出しを通じてマネージャー１１０と対話するように構成されているカスタム・ソフトウェア・アプリケーションを含む。データ・ウェアハウス１２０をロードするための、およびクライアント１４０へのデータ・ウェアハウス１２０の提示を仮想化するための、さまざまな実施形態における、オペレーション・データベース１３０と併せたマネージャー１１０のオペレーションについて、図３〜図６の説明と併せて、以降でさらに詳しく説明する。

いくつかの実施形態においては、マネージャー１１０および／またはオペレーション・データベース１３０は、堅固なフォルト・トレラントなシステムを介して実装される。たとえば、マネージャー１１０および／またはオペレーション・データベース１３０の全体的な信頼性と可用性は、予備の（たとえば、ホット・スタンバイの）コンピュータ・システムやクラスタ化されたコンピュータ・システムの使用を通じて高めることができ、それによって、マネージャーやデータベースのオペレーションは、１つまたは複数のシステムの障害の場合でも継続することができる。マネージャー１１０やオペレーション・データベース１３０の障害に対するデータ・ウェアハウス・システム１００の影響度を少なくするために、任意の適切なタイプのフェイルオーバ・メカニズムを採用することができる。

また、いくつかの実施形態においては、マネージャー１１０および／またはオペレーション・データベース１３０の実装をデータ・ウェアハウス１２０の実装から分離することによって、データ・ウェアハウス・システム１００に関連するコストや複雑さを低減させることができる。たとえば、このような分離は、日用的なコンピュータ・システムおよび／またはデータベース・ソフトウェアを使用してマネージャー１１０とオペレーション・データベース１３０のコントロール機能を実現させることが容易になる。このような分離は、コントロール・ハードウェアをデータ・ウェアハウス・ハードウェアから切り離してアップグレードできるようにすることによって、データ・ウェアハウス・システム１００の拡張を容易にすることもできる。いくつかの実施形態においては、このような分離は、データ・ウェアハウス・システム１００の全体的な可用性を高めて、障害修復時間を短縮することもできる。たとえば、あるデータ・ウェアハウス１２０に障害が発生した場合には、オペレーション・データベース１３０とマネージャー１１０は、障害の発生したウェアハウスが修復されている間、他のデータ・ウェアハウス１２０をロードし続けることができる。同様に、オペレーション・データベース１３０に障害が発生した場合には、データ・ウェアハウス１２０のいずれを修復する必要もなく、したがって全体的な障害修復時間を短縮することができる。

クライアント１４０は一般に、データ・ウェアハウス・システム１００にアクセスするように構成されている任意のソフトウェア・アプリケーションや他のエンティティーを含む。たとえば一実施形態においては、クライアント１４０は、（たとえば問合せを介して）データを検索するように構成されているアプリケーションを含む。このようなアプリケーションは、データ分析アプリケーション、意思決定支援システム、データ表示アプリケーション、あるいは他の任意の適切なアプリケーションを含む。クライアント１４０は、データ・ウェアハウス・システム１００のオペレーションを設定する管理アプリケーションまたはユーティリティーを含むこともできる。たとえばデータ・アナリストや管理者は、特定の一組のデータ・ソース１６０からのデータ項目の組合せが、その後の分析のためにデータ・ウェアハウス・システム１００によって集約されるべきであると判断する可能性がある。アナリストや管理者は、クライアント１４０を使用して、関連するデータ・セットをデータ・ソース１６０から、たとえば１回だけ、あるいは繰り返し抽出するようマネージャー１１０に指示することができる。さまざまな実施形態においては、クライアント１４０は、たとえば汎用コンピュータ・システム、ハンドヘルド・システム、あるいは埋め込みシステムなど、任意の適切なタイプのシステム上で機能するように構成される。いくつかの実施形態においては、クライアント１４０は、介在するシステムを介してデータ・ウェアハウス・システム１００と対話するように構成される。たとえばクライアント１４０は、クライアントサーバ・システム（図示せず）を介して実装され、このサーバ・システムは、クライアント１４０とデータ・ウェアハウス・システム１００との間で通信を仲介するように構成される。

マネージャー１１０によって提供されるＡＰＩと直接通信する代わりに、いくつかの実施形態においては、クライアント１４０のうちのいくつかまたはすべてを、ウェブ・サービス・インターフェース１５０を介してマネージャー１１０と通信するように構成させることができる。一般的に言えば、ウェブ・サービス・インターフェースは、何らかのサービスを実行するよう要求するクライアントとサービス・プロバイダとの間における通信のために標準的なクロスプラットフォームのＡＰＩを提供するように構成される。いくつかの実施形態においては、ウェブ・サービス・インターフェース１５０は、サービス要求とその要求への応答について記述する情報を含むドキュメントのやり取りをサポートするように構成される。このようなドキュメントは、たとえばＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）などの標準化されたウェブ・プロトコルを使用してやり取りすることができ、たとえばＸＭＬなど、プラットフォームに依存しないデータ・フォーマットでフォーマット設定することができる。標準的なウェブ・プロトコルやプラットフォームに依存しないドキュメント・フォーマット設定を使用することを含むウェブ・サービス・モデルを採用することによって、マネージャー１１０がサポートする必要のあるインターフェースのタイプの数を少なくすることができ、クライアント１４０とマネージャー１１０とのクロスプラットフォームの相互運用性を改善することができる。

いくつかの実施形態においては、データ・ソース１６０そのものは、リレーショナル・データベースや非リレーショナル・データベースを含み、企業のいたるところに分散させることができる。このようなデータベースは、データ・ウェアハウス１２０と同じタイプ（たとえば、ベンダやフォーマット）のものとしてもよいし、しなくてもよい。他の実施形態においては、データ・ソース１６０は、データをドキュメントの形式で、あるいは別の形式で保存するように構成されているカスタム・アプリケーションや独自仕様のアプリケーションなど、データベース以外のアプリケーションとすることができる。このような実施形態においては、マネージャー１１０は、データを入手するための必要なプロトコル（たとえば、データ・ソースのＡＰＩによって規定される特定のフォーマットのプロシージャーの呼び出し）を使用してデータ・ソース１６０と通信するように構成される。データ・ソース１６０は、トランザクション・ログ、Ｅメール通信、ワード・プロセッサ／オフィス・アプリケーション・ドキュメント、イメージやマルチメディア・ファイル、ウェブ・ページ・ドキュメント、ＸＭＬドキュメント、ｅコマース・サイトのオペレーション上の指標、あるいは他の任意の適切なタイプのドキュメントやデータの集合やアーカイブなど、ドキュメントのリポジトリを含むこともできる。たとえば一実施形態においては、データ・ソース１６０は、スタンドアロンのディスク・アレイや、ＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）を通じて結合されているストレージ・デバイスなど、ネットワークに接続された大容量のメディア・ストレージ・デバイスを含む。

データ・ソース１６０の特定の（１つまたは複数の）タイプを問わずに、マネージャー１１０は、そこから所望の（１つまたは複数の）データ・セットを抽出するための適切なオペレーションを実行し、データを、データ・ウェアハウス１２０内に保存するのに適したフォーマットへと変換するための必要なすべての変換を施し、抽出されたデータをデータ・ウェアハウス１２０のうちの１つまたは複数へロードするように構成される。特定のデータ・ソース１６０のデータ・コンテンツが、フォーマットの点で、データ・ウェアハウス１２０によって保存されるデータと非常に異なる場合には、マネージャー１１０は、データ・ソース１６０を分析して、そのデータ・コンテンツの関連する指標や表示を得るように、あるいは別のアプリケーションを呼び出して、そのような分析を実行するように構成される。

データ・ウェアハウスの複製、大まかな同期化、仮想化
データ・ウェアハウス１２０によって保存されるデータは、場合によっては、企業の経営にとって決定的に重要となる可能性がある。たとえば、いくつかの実施形態においては、分析ソフトウェアは、ウェアハウスに保存されているデータ上で機能して、レポートを作成するか、および／またはトレンドを識別するように構成され、これは、ひいては、注文／購買に関する意思決定、人材配置に関する意思決定など、経営上の意思決定に影響を与える。たとえば、ある日の生産指標を企業規模で分析することは、企業内のリソースをシフトさせること、翌日の生産のスケジュールを変更すること、原料供給を早めること、あるいは購買品を棚卸しすることなどを行うための意思決定に影響を与えるであう。万一、関連する分析を行う対象となるデータが、データ・ウェアハウス１２０内で失われたり駄目になったりすると、経営上や戦略上の意思決定プロセスが、著しく損なわれたり、あるいは場合によっては、まったく機能できなくなったりするおそれがある。

ウェアハウスに保存されるいくつかのデータは、上述のように、データ・ソース１６０によって保存されているデータの派生物であり、原則として、それらのデータ・ソース１６０からデータ・ウェアハウス１２０へ関連するデータを再びロードすることによって復元させることができる。しかし、このように再びロードすることは、たとえば、失われたデータや駄目になったデータの量が多い場合や、データ・ソース１６０が、要求されたデータを検索するために（テープやオフライン・メディアなどの）より低速のアーカイバル・メディアにアクセスしなければならない場合には、完了するのにかなりの時間を要するおそれがある。ウェアハウスに保存されるデータに依存するプロセスに対する混乱を最小限に抑えるタイムフレームで、必要とされているデータを再びロードすることは不可能かもしれない。さらに、場合によっては、データ・ウェアハウス１２０上に保存されるデータは、データ・ウェアハウス・システム１００を利用するアプリケーション（たとえば、分析アプリケーション）の最初の出力となる可能性があり、したがって、単にそれをデータ・ソース１６０から再びロードすることによって復元することはできない。

データの損失と、その結果としての混乱とが生じる可能性を少なくするために、一実施形態においては、データ・ウェアハウス１２０のサブセットが特定のデータ・セットを複製するように構成される。すなわち、データ・ウェアハウス１２０のうちの複数が、レコードのテーブルやセットなど、データ・セットのそれぞれのレプリカを保存するように構成される。このような複製を示す一実施形態が、図２に示されている。図示されている実施形態においては、データ・ウェアハウス１２０ａ〜ｂは、顧客注文データと顧客発送データとを含むテーブルのレプリカを保存するようにそれぞれ構成されている。いくつかの実施形態においては、特定のデータ・セットは、２つから、データ・ウェアハウス・システム１００内のデータ・ウェアハウス１２０の数まで、任意の数のデータ・ウェアハウス１２０によって複製することができるという点に留意されたい。その一方で、いくつかの実施形態においては、特定のデータ・セットは、まったく複製することができないか、あるいは他のデータ・ウェアハウス上で複製することができる。図示されている実施形態においては、データ・ウェアハウス１２０ａ〜ｂはそれぞれ、他方のデータ・ウェアハウスによって複製されていないテーブル（それぞれ、財務報告データやセッション・トラッキング・データ）を含む。いくつかの実施形態においては、さまざまなデータベース・スキーマを使用して（たとえば、さまざまなデータ・フィールド定義および／または構造を使用して）データ・ウェアハウス１２０によってさまざまなデータ・セットを保存することができるという点に留意されたい。

いくつかの実施形態においては、データ・ウェアハウス１２０によって保存されるデータ・セットは、多くの異なるタイプの企業に共通のものとすることができる。たとえば顧客の注文や発送のデータは、電子商取引を行っていない企業、および仮想の顧客インターフェース（たとえば、ウェブベースの電子商取引インターフェース、すなわちｅコマース・インターフェース）を提供する企業の双方の中で一般に利用可能なデータ・セットとすることができる。しかし、いくつかの実施形態においては、ｅコマース・インターフェースをサポートする企業は、販売が行われる前でさえ、顧客とその企業との対話に関するかなりの量の情報を収集して保存するように構成される。一実施形態においては、図２に示されているセッション・トラッキング・データ・セットは、顧客とｅコマース・インターフェースとの対話のいかなる側面に関するデータも保存するように構成される。たとえばセッション・トラッキング・データ・セットは、企業のウェブ・サイトへの訪問（たとえばセッション）中に顧客が見た特定のアイテムだけでなく、見ていた時間、セッション中に顧客がナビゲートしたリンク、顧客によって実行されたあらゆる検索などを示すデータを保存するように構成される。分析アプリケーションは、顧客の好みを認識すること、顧客がさまざまなアイテムを注文する可能性を予測すること、顧客に提示されるｅコマース・インターフェースをカスタマイズすることなどを行うために、これらおよび他のタイプのトラッキング・データを分析するように構成される。

しかし、データ・ウェアハウジングや後述のさまざまな技術は、多大なｅコマース・コンポーネントを伴わずに企業に等しく適用することができるという点に留意されたい。たとえば、いくつかの企業は、多くの機能的な部署や地理的な部署にわたる高度に複雑な内部プロセスを有する可能性があり、外部の顧客のアクティビティーは別にしても、ウェアハウジングに利用できる膨大な量のデータを社内で生成することもある。さらに、いくつかの実施形態においては、企業は、十分に複雑であり、そのために、企業の内部のアクティビティーやトランザクションに関して、上述したｅコマース指向のアクティビティーと同様の情報収集戦略を採用することがある。たとえば、企業内のさまざまな事業単位は、外部の顧客と同様の顧客として他の事業単位と対話することができ、同様の方法で顧客データを生成することができる。

いくつかの実施形態においては、データ・ウェアハウス１２０のサブセットは、さまざまな度合いの複製を用いてさまざまなタイプのデータを保存するように構成される。たとえば図２の実施形態においては、データ・ウェアハウス１２０ａ〜ｂは、図示されているように、複製された様式で顧客の注文や発送のデータを保存するように構成される。同様の実施形態においては、データ・ウェアハウス１２０ｃ〜ｄは、複製された様式（図示せず）で時系列のセッション・トラッキング・データ（たとえば、過去１５カ月分に相当するトラッキング・データ）を保存するように構成される。データ・ウェアハウス１２０のこのような構成においては、ウェアハウス１２０ａ〜ｂは、顧客の注文や発送のデータを含む分析に特に適した機能的にクラスタ化またはグループ化された一式のウェアハウスを形成することができ、その一方で、ウェアハウス１２０ｃ〜ｄは、セッション・トラッキング・データを含む分析に特に適した同様に機能的にクラスタ化された一式のウェアハウスを形成することができる。それぞれの場合、データの損失を防止する上で役立つように、相対的に重要度の高いデータを複製することができる。ウェアハウス１２０ａ〜ｄのこのような構成においては、顧客データへの分析駆動型の問合せが、最近のセッション・トラッキング・データを頻繁に対象とすることもできる。たとえば顧客の注文や発送のパターンの分析は、このようなパターンを最近のセッション・トラッキング・データ（たとえば、過去９０日分に相当するトラッキング・データ）に相関付けるよう試みることができる。したがって図２の実施形態においては、データ・ウェアハウス１２０ｂは、セッション・トラッキング・データのセットを保存するように構成される。しかし、データ・ウェアハウス１２０ｃ〜ｄが、セッション・トラッキング・データのより大きなセットを余分に保存するように構成されているという点（必要な場合には、データ・ウェアハウス１２０ｂによって保存されたセットをそこから再構築することができるという点）を考慮すると、データ・ウェアハウス１２０ｂによって保存されたセッション・トラッキング・データは、複製しなくてもよい。

特定のデータ・セットに関してデータ・ウェアハウス１２０をクラスタ化またはグループ化し、それによって、さまざまなタイプの問合せに関してデータ・ウェアハウス１２０のさまざまなグループを最適化できるようにすることによって、予想される使用パターンに沿ってデータ・ウェアハウス・システム１００をより最適に調整できるようにすることができる。たとえば、図７の説明と併せて以降でさらに詳しく説明するように、データ・ウェアハウス１２０の特定のクラスタリングが処理されると予想されるアクティビティーの度合いに応じて、データ・ウェアハウス１２０の基礎をなすハードウェア・システムに、より多くのコンピューティング・リソースを、またはより少ないコンピューティング・リソースを提供することができる。しかし他の実施形態においては、データ・セットは、複数のデータ・ウェアハウス１２０にわたって、より均一な様式で分散させることができる。たとえば一実施形態においては、それぞれのデータ・ウェアハウス１２０は、ほぼ同じセットの計算リソースを含むことができ、データ・セットは、複数のほぼ同等のデータ・ウェアハウス１２０にわたって、さまざまな度合いの複製で分散させることができる。このような実施形態においては、ハードウェア・リソースは、データの保存と検索のアクティビティーに関して、あまり最適に調整されないかもしれないが、データ・ウェアハウス１２０の相対的に均一な実装は、たとえば、増大するデータ分析の要求を処理する上で必要となるにつれて、同様に構成されたさらなるデータ・ウェアハウス１２０を追加することによって、より容易に拡張することができる。

上述のように、複数のデータ・ウェアハウス１２０にわたるデータ・セットの複製は、特定のデータ・ウェアハウス１２０の障害が結果としてデータの損失につながる可能性を少なくすることによって、データの全体的な信頼性を高めることができる。このような複製は、たとえば問合せに応答して、複製されたデータ・セットをクライアントに提供できるデータ・ウェアハウス１２０の数を増やすことによって、データ・セットの可用性を高めることもできる。図１に示されているデータ・ウェアハウス・システム１００の実施形態においては、マネージャー１１０は、複数のウェアハウス１２０の間におけるデータ・セットのあらゆる複製を含めて、データ・ウェアハウス１２０へのデータの保存を調整するように構成される。したがって、図示されている実施形態においては、特定のデータ・セットが複製されるか否かは、特定のデータ・ウェアハウス１２０にとって明白かもしれない。しかし、いくつかの実施形態においては、マネージャー１１０の機能として本明細書に記載されている複数のデータ・ウェアハウス１２０にわたるデータ・セットの管理と複製は、代わりに、複数のデータ・ウェアハウス１２０の間で協調的に分担することもでき、あるいはデータ・ウェアハウスとマネージャーの双方として機能するように構成されている特定のデータ・ウェアハウス１２０によって実行することもできるということが考えられる。

データ・ウェアハウス１２０によって保存される個々のデータ・セットは、場合によっては、たとえば約数百ＭＢ（ｍｅｇａｂｙｔｅ）あるいはＧＢ（ｇｉｇａｂｙｔｅ）など、非常に大きくなる可能性がある。さらに、マネージャー１１０による特定のデータ・セットに対する部分的な更新でさえ、たとえば新たな経営関連のデータをデータ・ソース１６０から定期的に抽出することに応じて、特定のデータ・ウェアハウス１２０に伝達すべきかなりの量のデータを含む可能性がある。１つのデータ・セットが、複数のデータ・ウェアハウス１２０にわたって複製される場合には、最終的に、そのデータ・セットを含むデータ、ならびにそのデータに対する継続的な更新は、それらの複数のデータ・ウェアハウス１２０の間で保存される。しかし、このような保存を瞬時に行うことはできない。たとえばマネージャー１１０が、データ・ウェアハウス１２０ａ〜ｂへの同一のデータの保存を同時に開始した場合でさえ、そのデータの保存をデータ・ウェアハウス１２０ａ〜ｂの双方において同時に完了することはできない。異なる計算負荷（たとえば問合せのサービス）、ならびに基礎をなすリソースの構成などの要因によって、一方のデータ・ウェアハウス１２０が、別のデータ・ウェアハウス１２０よりも速く保存オペレーションを完了する可能性がある。したがって、保存オペレーションがデータ・ウェアハウス１２０ａ〜ｂの双方において完了する前の任意の特定の時点で、保存されている最中のデータ・セットの状態は、データ・ウェアハウス１２０ａ〜ｂごとに異なる可能性がある。データ・セットは、この状態にある間は、非同期である、または同期化されていないと言うこともできる。

同期化されていないデータは、それらのデータを検索しようと試みるクライアント１４０にとって問題を提示する可能性がある。たとえば、特定の複製されたデータ・セットを対象とする問合せがマネージャー１１０によって受信されたときに、それらの特定のデータ・セットが、データ・ウェアハウス１２０ａ〜ｂ上で２つの異なる状態にある場合には、その問合せは、評価のために、その問合せが対象とする特定のデータ・ウェアハウス１２０内のそれらの特定のデータ・セットの状態に応じて、２つの異なる結果を返す可能性がある。このような一貫性のなさは、とりわけ、複数のデータ・ウェアハウス１２０の間におけるデータ・セットの複製（あるいはより広くは、データ・ウェアハウス・システム１００の一般的な構成）がクライアント１４０にとって明白である場合には、一貫性のないクライアント・オペレーションにつながる可能性がある。

同期化されていないデータへのコントロールされていないアクセスに起因する一貫性のないクライアントの動作を防止することへの１つのアプローチは、複製されたデータ・セットが複数のデータ・ウェアハウス１２０にわたって同期化されていない間は、そのデータ・セットへのあらゆるアクセスをマネージャー１１０が防止するということを含む。たとえば一実施形態においては、マネージャー１１０は、複製されたデータ・セットに対する更新をアトミック・オペレーションまたはトランザクショナル・オペレーションとして実行するように構成される。一般的に言えば、複数のエンティティーにわたる同期化を含むアトミック・オペレーションまたはトランザクショナル・オペレーションは、他のオペレーションに対して分割できないものとして扱われる。すなわち、関与するエンティティーのすべてがそのようなオペレーションを完了した状態、または関与するエンティティーのすべてがそのようなオペレーションを完了していない状態のいずれかでなければ、それらのエンティティーを対象とする別のオペレーションが進行することは認められない。したがって一実施形態においては、マネージャー１１０は、すべての関連するデータ・ウェアハウス１２０上に保存されているデータ・セットのすべてのレプリカが完了するまで、保存されている最中または修正されている最中の複製されたデータ・セットにアクセスしようとする試みを却下することができ、それによってクライアントは、複製されたデータ・セットへのアクセスを試みた際に一貫性のない結果を受け取ることがなくなる。

しかし、すべてのデータ・セット・レプリカにわたってアトミックまたはトランザクショナルな同期化を実施すると、データ・ウェアハウス・システム１００のパフォーマンスが著しく低下するおそれがある。たとえば、特定の複製されたデータ・セットが大きい場合には、そのデータ・セットにアクセスできるようになるまでに、すべてのデータ・セット・レプリカに対する更新が完了するのを待つ際に多大な待ち時間を招くおそれがある。したがって一実施形態においては、マネージャー１１０は、複数のデータ・ウェアハウス１２０にわたって複製されたデータ・セットを大まかに同期化するように構成される。一実施形態においては、データ・セットの大まかな同期化は、特定のデータ・ウェアハウス１２０内の複製されたデータ・セットに対する更新をアトミックに同期化する一方で、他のデータ・ウェアハウス１２０によって保存されているそのデータ・セットの他のレプリカにアクセスできるようにすることを含む。すなわち一実施形態においては、マネージャー１１０は、（図２に示されているデータ・ウェアハウス１２０ａの顧客注文データ・テーブルなど）特定のデータ・ウェアハウス１２０の特定のテーブルを、その特定のテーブルの更新中には、他の読み取りアクセスや書き込みアクセスに対してアトミックにロックすることができる。その間に、マネージャー１１０は、別のデータ・ウェアハウス１２０上でその特定のロックされたテーブルのレプリカに（たとえば、データ・ウェアハウス１２０ｂの複製された顧客注文データ・テーブルに）アクセスすることを条件付きで可能にすることができる。ある代替実施形態においては、マネージャー１１０は、データ・ウェアハウス１２０全体を、その中に保存されているデータ・セットの更新中にアトミックにロックすることもでき、あるいはテーブル内の１つの行など、更新されているデータ・セットの一部のみをロックすることもでき、マネージャー１１０によって任意の適切なロッキング精度を採用することができるということが考えられる。いくつかの実施形態においては、マネージャー１１０は、特定のデータ・ウェアハウス１２０上の更新されているデータ・セットの一部をロックする一方で、その特定のデータ・ウェアハウス１２０上の同じデータ・セットのロックされていない部分に読み取りや更新のために別途アクセスすることを可能にするように構成されるということがさらに考えられる。

一実施形態においては、マネージャー１１０は、あるデータ・セット・レプリカへのアクセスを、別のデータ・セット・レプリカの更新中に、そのアクセスがそのデータ更新に依存していないならば、条件付きで可能にすることができる。たとえばクライアント１４０は、（たとえば現在の暦四半期を除いた）前の完全な暦四半期に関するすべての顧客発送データを要求する問合せを送信することができる。その間に、マネージャー１１０は、多くの顧客満足サイトから前日の顧客発送データを抽出している最中であり、それらの顧客満足サイトのそれぞれは、データ・ソース１６０を含む。マネージャー１１０は、データ・ウェアハウス１２０ａ内の同期化を確実にするために任意の適切なロッキング・スキームを使用して、データ・ウェアハウス１２０ａによって保存されている顧客発送データ・テーブルを更新するように構成される。ウェアハウス１２０ａに対する更新が進行している間は、顧客発送データのそのレプリカに対する問合せ（あるいは、いくつかの実施形態においては、ウェアハウス１２０ａ内の任意のデータに対する問合せ）を却下することができる。しかしマネージャー１１０は、前の暦四半期に関する顧客発送データを求める送信された問合せが、現在データ・ウェアハウス１２０ａに対して進行中の更新に依存していないことを検知するように構成される。すなわち、その問合せを満たすのに必要なすべてのデータは、たとえデータ・ウェアハウス１２０ｂ内の顧客発送データがデータ・ウェアハウス１２０ａ内のレプリカと完全には同期化されていなくても、データ・ウェアハウス１２０ｂ内に提示することができる。したがってマネージャー１１０は、顧客発送データの更新がデータ・ウェアハウス１２０ｂへ保存される前に、その問合せがデータ・ウェアハウス１２０ｂによって評価されることを可能にすることができる。この例においては、当該データ・セットは、データ・ウェアハウス１２０ａと１２０ｂにわたって完全には同期化されず、むしろ大まかに同期化され、この場合、問合せを評価するための十分なデータを有するデータ・ウェアハウス１２０は、当該データ・セットの最新のバージョンを有していない場合でさえ、問合せを評価することができる。

図１に示されているデータ・ウェアハウス・システム１００の実施形態においては、マネージャー１１０は、特定のデータ・セットが保存されている（１つまたは複数の）位置（たとえば、特定のデータ・セットの単独のコピーやレプリカを有する特定のデータ・ウェアハウス１２０）を識別する情報、ならびに進行中の任意の更新アクティビティーに関してデータ・セットのそれぞれのコピーの状態を識別する情報など、データ・ウェアハウス１２０によって保存されているデータ・セットに関する情報を保持するためにオペレーション・データベース１３０を利用するように構成される。たとえば一実施形態においては、オペレーション・データベース１３０は、データ・ウェアハウス１２０によって保存されている顧客発送データ・テーブルのそれぞれのコピーに対応するそれぞれのレコードを含む。図２に示されている実施形態に関しては、オペレーション・データベース１３０は、このようなレコードを２つ保存することができ、そのそれぞれは、それぞれのデータ・ウェアハウス１２０ａ、ｂを、顧客発送データ・テーブルのそれぞれのレプリカを保存するものとして識別する。さらに、それぞれのレコードは、対応するデータ・ウェアハウス１２０ａ、ｂ内のテーブルの状態を示すフィールドを含む。前のパラグラフで与えられた例を参照すると、マネージャー１１０がデータ・ウェアハウス１２０ａ内の顧客発送データ・テーブルの更新を調整している間、オペレーション・データベース１３０内の対応するレコードは、そのレプリカが更新中であり、利用できないということや、他の適切な状態を表示することができる。対照的に、データ・ウェアハウス１２０ｂによって保存されている顧客発送データ・レプリカに関するレコードは、そのレプリカが更新中ではないということや、その更新が既に完了したということを表示することができる。

さまざまな実施形態においては、オペレーション・データベース１３０は、データ・セットの位置と状態を識別する異なるタイプのデータを保存するように構成される。たとえば位置を識別するデータは、システム名、ＩＰ（ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ）アドレス、あるいは他の適切な識別子など、データ・ウェアハウス１２０のための一意の識別子を含む。状態情報は、特定のデータ・セットが更新されている最中か否かを示すシンプルなセマフォーから、特定のデータ・セットの状態を特徴付けるさらに複雑なフィールドまで、多岐にわたることができる。たとえば、いくつかの実施形態においては、あるデータ・セットに対応する状態情報は、そのデータ・セットが最後に更新された時刻、その更新を実行するために使用されたデータ・ソース１６０、更新の理由（たとえば、スケジュールされたオペレーションや手動のオペレーションのため）、あるいは他の任意の適切な状態情報を示すことができる。いくつかの実施形態においては（たとえばマネージャー１１０が、データ・ウェアハウス１２０に対する複数の並行した読み取りオペレーションや書き込みオペレーションをサポートするように構成されている実施形態においては）、マネージャー１１０は、動作状態の同期化を確実にするために、オペレーション・データベース１３０の読み取りおよび／または修正を行うのにトランザクショナル・オペレーションを使用するように構成される。

オペレーション・データベース１３０によって保存されている位置と状態の情報は、一実施形態においては、データ・ウェアハウス１２０によって保存されているデータの大まかな同期化を実施するためにマネージャー１１０によって使用することができる。すなわちマネージャー１１０は、データを抽出してデータ・ウェアハウス１２０内に保存する際に、また保存されているデータを検索するためのオペレーション（たとえば問合せ）を受信した際に、オペレーション・データベース１３０を調べるように構成されている。大まかな同期化を使用して、抽出されたデータをデータ・ウェアハウス１２０内に保存する方法の一実施形態が、図３に示されている。図１から図３をまとめて参照すると、オペレーションは、ブロック３００において開始し、このブロック３００では、１つまたは複数のデータ・ソースからデータ・セットを抽出するためのオペレーションが開始する。たとえば一実施形態においては、マネージャー１１０は、企業のいたるところに分散されている顧客満足サイトなど、１つまたは複数のデータ・ソース１６０から、顧客発送データなどのデータ・セットを、繰り返し（たとえば毎時間、毎晩、毎週）抽出するように構成される。あるいはユーザやアプリケーションは、データ・セットが抽出され保存されるよう、クライアント１４０を介して要求することができる。いくつかの実施形態においては、複数のデータ・セットをデータ・ソース１６０から同時に抽出して、１つまたは複数のデータ・ウェアハウス１２０内で更新することができるということが考えられる。たとえば、複数のデータ・セットを同時に抽出して、スケジュールされたバッチ・ジョブなどのバッチ・ジョブやバッチ・プロセスとして保存することもでき、あるいはデータ・セットをデータ・ソース１６０から動的にストリームして、データ・ウェアハウス１２０内で更新することもできる。

その後、マネージャー１１０は、たとえばデータを引き出すための問合せや他のコマンドをデータ・ソース１６０へ発行することによって、抽出されたデータを検索する（ブロック３０２）。抽出されたデータを、必要な場合には変換する（ブロック３０４）。たとえば、抽出されたデータのフォーマットを設定し直すことが必要になることもあり、あるいは、上述のようにデータ・ウェアハウス１２０のデータ保存要件に従ってデータそのものを修正することが必要になることもある。

そしてマネージャー１１０は、どのデータ・ウェアハウス１２０が、抽出されたデータ・セットをホストしているかを割り出す（ブロック３０６）。たとえば一実施形態においては、マネージャー１１０は、オペレーション・データベース１３０を調べて、抽出されたデータ・セットが存在する位置を、その中に保存されているレコードに従って割り出すことができる。次いでマネージャー１１０は、抽出されたデータ・セットを用いて更新する特定のデータ・ウェアハウス１２０を選択し、そのデータ・セットに関連付けられている状態情報を更新して、更新が行われている最中であることを表示する（ブロック３０８）。いくつかの実施形態においては、抽出されたデータ・セットをホストしているそれぞれのデータ・ウェアハウス１２０の更新は、別々の時点において開始したり終了したりする可能性があるが、マネージャー１１０は、これらの更新を、並行したやり方または重なるやり方で行うように構成される。このような並行処理が、ブロック３０８〜３１２の繰り返されるブロックに関して図３に示されており、これらは、いくつかの異なるデータ・セットやデータ・セット・レプリカのそれぞれに関して並行して実行することができる。たとえばマネージャー１１０は、抽出されたデータ・セットの更新をいくつかの異なるデータ・ウェアハウス１２０上で同時に開始するか、あるいは、それらの更新をずらし、それによってそれらの更新が時間の点で部分的に重なるようにすることもできる。また、いくつかの実施形態においては、複数の異なるデータ・ウェアハウス１２０内で複数の異なるデータ・セットを同時に更新することができるという点に留意されたい。

他の実施形態においては、マネージャー１１０は、連続したやり方または条件付きのやり方でデータ・ウェアハウス１２０を更新するように構成される。たとえば、抽出されたデータ・セットがデータ・ウェアハウス１２０のサブセットによって複製されている場合には、マネージャー１１０は、特定のデータ・ウェアハウス１２０をランダムに選択して、更新を開始することができる。あるいはマネージャー１１０は、そのサブセットのうちで最も余裕があるデータ・ウェアハウス１２０を選択することもでき、または他の何らかの選択基準を使用することもできる。オペレーション・データベース１３０が未処理のデータ・セット読み取りオペレーションを追跡把握するいくつかの実施形態においては、あるデータ・セットが（たとえば問合せによって）現在読み取られている最中である場合には、データ・ウェアハウス１２０をそのデータ・セットの更新に関しては選択しないでおくことができる。データ・ウェアハウス１２０が選択されると、一実施形態においては、マネージャー１１０は、そのデータ・セットと、選択されたデータ・ウェアハウス１２０とに関連付けられているオペレーション・データベース１３０内に保存されているレコード内の状態情報を更新して、そのデータ・セットがその選択されたデータ・ウェアハウス上で修正されている最中であることを表示することができる。上述のように、いくつかの実施形態においては、マネージャー１１０は、たとえば複数の並行したオペレーションの正しい順序付けを確実にするために、オペレーション・データベース１３０と対話するのにトランザクショナル・オペレーションを使用することができる。

そして抽出されたデータ・セットは、選択されたデータ・ウェアハウス１２０へ保存される（ブロック３１０）。選択されたデータ・ウェアハウス１２０に対する更新が進行している間は、他のデータ・ウェアハウス１２０を介して、そのデータ・セットの他のレプリカに対するアクセスおよび／または更新を行うことができるという点に留意されたい。更新が完了すると、マネージャー１１０は、そのデータ・セットに関連付けられている状態情報を更新して、更新の完了を表示する（ブロック３１２）。

いくつかの実施形態においては、マネージャー１１０は、抽出されたデータ・セットをバッファに保存する必要はなく、その一方で、この抽出されたデータ・セットは、その対応するデータ・ウェアハウス１２０へ順に保存されるということもある。ある代替実施形態においては、マネージャー１１０は、データ・ソース１６０からのデータの抽出を開始する前に、更新するデータ・ウェアハウス１２０を選択することができる。そしてマネージャー１１０は、抽出されたデータを（適切な変換を施して）、選択されたデータ・ウェアハウス１２０へとストリームすることや、ストリームさせることができ、その後、更新されたデータ・ウェアハウス１２０を、他のデータ・ウェアハウス１２０を更新するためのデータ・ソースとして使用することができる。いくつかの実施形態においては、複数のデータ・ウェアハウス１２０を、順にではなく、同時に更新するようにしてもよい。たとえば、特定のデータ・セットが３つのデータ・ウェアハウス１２０内で複製されている場合には、それらのうちの２つを同時に更新する一方で、３つ目のデータ・ウェアハウス１２０を、その特定のデータ・セットに対する問合せのために利用できるように残しておくことができる。最後に、いくつかの実施形態においては、データ・ウェアハウス１２０のすべて（または選択されたサブセット）を同時に更新して、状態をオペレーション・データベース１３０内に適切に表示することによって、（大まかな同期化とは対照的な）完全な同期化を実現することができる。

大まかな同期化を使用して、データ・ウェアハウス１２０によって保存されているデータに関して問合せを行う方法の一実施形態が、図４に示されている。図１から図４をまとめて参照すると、オペレーションは、ブロック４００において開始し、このブロック４００では、データ・ウェアハウス１２０によって保存されている１つまたは複数のデータ・セットに依存する問合せオペレーションが受信される。たとえば一実施形態においては、マネージャー１１０は、このような問合せをクライアント１４０から、直接またはウェブ・サービス・インターフェース１５０を介して受信するように構成される。

その後、マネージャー１１０は、受信した問合せを分析して、その問合せのデータ・セット依存度を割り出す（ブロック４０２）。いくつかの実施形態においては、データ・セット依存度を割り出すステップは、その問合せによって参照される特定のデータ・セットや、依存されているデータ・セットに関する任意のさらなる状態情報を割り出すステップを含む。たとえば一実施形態においては、マネージャー１１０は、特定の問合せが、図２に示されている顧客発送データ・テーブルに依存しているということを、そしてさらには、依存されているデータは、前の暦四半期に関するデータであるということを割り出すことができる。

そしてマネージャー１１０は、依存されているデータ・セットのデータ・ウェアハウス１２０内における位置や、保存されているデータ・セットに関連付けられている現在の状態情報を割り出す（ブロック４０４）。たとえばマネージャー１１０は、依存されているそれぞれのデータ・セットごとに、どのデータ・ウェアハウス１２０がそのデータ・セットのコピーをホストしているか、ならびにそのコピーに関連付けられている状態情報（たとえば、現在更新中、特定の日付現在で、メンテナンスのためにオフライン中など）を割り出すために、オペレーション・データベース１３０を調べる。

受信した問合せのデータ・セット依存度、ならびにデータ・ウェアハウス１２０内におけるデータ・セットの位置と状態に関する情報の分析に基づいて、マネージャー１１０は、いずれかのデータ・ウェアハウス１２０が、その受信した問合せを評価するための十分なデータを有しているかどうかを判定する（ブロック４０６）。たとえば一実施形態においては、マネージャー１１０は、あるデータ・ウェアハウス１２０が、特定の問合せによって依存されているそれぞれのデータ・セットのコピーを有している場合、依存されているそれぞれのデータ・セットが、その他の形で（たとえば、図３に示されているような抽出と保存のオペレーションによって）更新されている最中でない場合、および依存されているそれぞれのデータ・セットが、その問合せの状態要件（たとえば、それぞれのデータ・セットが、少なくとも、その問合せによって指定されているいずれの日付範囲とも同じぐらい新しいものであること）を満たす場合には、そのデータ・ウェアハウス１２０が、その問合せを評価するための十分なデータを有していると判定する。他の実施形態においては、マネージャー１１０は、特定の問合せに関して特定のデータ・ウェアハウス１２０がデータを十分に有しているかどうかを判定するために、別の基準やさらなる基準を使用することができる。たとえば、このような基準は、特定のタイプの照会言語を評価するための機能や、複雑な問合せを処理するための利用可能な計算リソースなど、データ・ウェアハウス１２０の機能やリソースに関する情報を含む。

いくつかの実施形態においては、１つまたは複数のデータ・ウェアハウス１２０は、特定のデータ・ウェアハウス１２０によって同時に評価できる問合せの数を制限することなどによって問合せ評価リソースを管理するように構成される。たとえばデータ・ウェアハウス１２０は、問合せを実行するための特定の数の「ジョブ・スロット」を提供するように構成され、すべてのスロットが占有されている場合には、さらなる問合せを受け入れることができないようにすることができる。いくつかの実施形態においては、特定の問合せは、その問合せの複雑さを問わずに、１つの利用可能なジョブ・スロットに対応することががる。他の実施形態においては、より複雑な問合せが、複数のジョブ・スロットを占有することもあり、あるいは、データ・ウェアハウス１２０によって他のタイプのロード・バランシング戦略を採用することもできる。いくつかの実施形態においては、特定の問合せを評価するための十分なデータを特定のデータ・ウェアハウス１２０が有しているかどうかを判定するマネージャー１１０は、特定のデータ・ウェアハウス１２０の利用可能な問合せ評価リソースを考慮に入れることもできる。たとえば一実施形態においては、問合せを評価するための十分なデータを有しているが、問合せを評価するための利用可能なリソースをまったく有していないデータ・ウェアハウス１２０は、マネージャー１１０によって選択しないでおくことができる。

受信した問合せを評価するための十分なデータを有するデータ・ウェアハウス１２０がまったくない場合（あるいは、いくつかの実施形態においては、受信した問合せを評価するための利用可能なリソースを十分に有するデータ・ウェアハウス１２０がまったくない場合）には、マネージャー１１０は、十分なデータ・ウェアハウス１２０を識別できるようになるときまで、その問合せを待ち行列に入れておく（ブロック４０８）。たとえば一実施形態においては、マネージャー１１０は、受信した問合せが、特定のデータ・ウェアハウス１２０に対して現在更新されている最中であるデータ・セットに依存しているということを識別し、その問合せが、その更新の完了後にその特定のデータ・ウェアハウス１２０上で評価されるようにスケジュールすることができる。あるいはマネージャー１１０は、待ち行列に入っている問合せをときおり再評価して、データ・ウェアハウス１２０が、問合せを評価するのに利用できるようになったかどうかを判定するようにしてもよい。いくつかの実施形態においては、クライアントのデッドロックを回避するために、マネージャー１１０は、問合せが待ち行列に入っていられる時間の長さに関して制限を課すことができ、その問合せが、待ち行列に入っていられる制限時間を超えた場合には、クライアントにエラー状態を返すことができる。

受信した問合せを評価するのに十分なデータ・ウェアハウス１２０が識別された場合には、マネージャー１１０は、その受信した問合せを、評価のためにそのデータ・ウェアハウス１２０に伝達する（ブロック４１０）。大まかな同期化のもとでは、特定のデータ・セットを対象とする問合せは、その特定のデータ・セットのレプリカが１つのデータ・ウェアハウス１２０上で更新されている間に、別のデータ・ウェアハウス１２０によって評価されるという点に留意されたい。

大まかな同期化のもとでのデータ・セットの更新とデータ・セットの問合せとの間における関係の一実施形態を示すタイミング図が、図５Ａに示されている。示されているタイミング図においては、マネージャー１１０は、時刻Ｔ１に特定のデータ・セットの更新を開始し、ここでは、このデータ・セットは、データ・ウェアハウス１２０ａ〜ｂによって複製されている。その後、更新されている最中のデータ・セットを対象とする問合せが、時刻Ｔ２にマネージャー１１０によって受信される。データ・セットの更新は、Ｔ２よりも後の時刻Ｔ３にデータ・ウェアハウス１２０ａにおいて完了し、Ｔ３よりも後の時刻Ｔ４にデータ・ウェアハウス１２０ｂにおいて完了する。

図示されている実施形態においては、受信した問合せを評価するための３つの可能なタイムフレームが示されている。第１のケースにおいては、更新されている最中のデータ・セットの更新前の内容によって問合せを満たすことができるようにする。たとえばマネージャー１１０は、オペレーション・データベース１３０と共に、問合せを評価するのに必要なデータが現在の更新に依存していないということを判定する。このケースにおいては、時刻Ｔ２の後に、当該データ・セットをホストしている任意の利用可能なデータ・ウェアハウス１２０によって問合せを評価する。すなわち問合せは、受信された後のできるだけ早い時点で評価され、これは、場合によっては、遅延を招くおそれがある。たとえば、いくつかの実施形態においては、上述のように、現在更新されている最中のデータ・ウェアハウス１２０上では問合せを評価することが認められないかもしれない。さらに場合によっては、データ・ウェアハウス１２０は、あまりに余裕がないために、問合せをすぐに受け入れることができないかもしれない。しかし、いくつかの実施形態においては、更新前のデータに依存する問合せの場合、時刻Ｔ２の後のどの時点でその問合せを実行できるかに関して、いかなる更新関連の時間的な制約も必要ではない。

第２、第３のケースにおいては、問合せは、更新されている最中のデータ・セットの更新後の内容に依存する。すなわち問合せは、その正しい評価のために、時刻Ｔ１に開始されたデータ・セットの更新において反映されたデータを要求する。図示されている実施形態においては、この更新は、時刻Ｔ３にデータ・ウェアハウス１２０ａにおいて、時刻Ｔ４にデータ・ウェアハウス１２０ｂにおいて完了する。これに対応して、問合せは、時刻Ｔ３より後の任意の時点でデータ・ウェアハウス１２０ａによって、また時刻Ｔ４より後の任意の時点でデータ・ウェアハウス１２０ｂによって評価される。前述のように、および図５Ａに示されているように、大まかな同期化のもとでは、問合せは、その問合せによって対象とされているデータ・セットのすべてのレプリカが更新される前に、また場合によっては（たとえば、その問合せが更新前のデータに依存している場合には）、そのデータ・セットのレプリカが特定のデータ・ウェアハウス１２０上で更新される前に、その特定のデータ・ウェアハウス１２０によって評価される。上述のように、いくつかの実施形態においては、特定のデータ・セットを対象とする問合せは、その特定のデータ・セットが１つのデータ・ウェアハウス１２０へ保存されている間に、別のデータ・ウェアハウス１２０によって評価され。さらに、いくつかの実施形態においては、特定のデータ・セットが任意の特定のデータ・ウェアハウス１２０へ保存された後に、その特定のデータ・ウェアハウス１２０が、その特定のデータ・セットを対象とする問合せを評価する。たとえば、複製されたデータ・セットが、いくつかのまたはすべての対応するデータ・ウェアハウス１２０へ更新された後には、それらの更新されたデータ・ウェアハウス１２０のいずれかが、その複製されたデータ・セットへの問合せを満たす。

また、いくつかの実施形態においては、上述のように、データ・セットの部分をロックするためのきめの細かいメカニズムを採用して、更新されている最中のデータ・セットをホストしている特定のデータ・ウェアハウス１２０を、その更新が完了する前にそのデータ・セットに対する問合せを評価する上で利用できるようにすることができるという点に留意されたい。たとえば、いくつかの実施形態においては、マネージャー１１０とオペレーション・データベース１３０は、データ・セットの部分（たとえば、テーブルの個々の行や、行のセット）の状態を追跡把握するように構成される。特定のデータ・セットのある部分が、特定のデータ・ウェアハウス１２０上で更新されている間に、マネージャー１１０は、特定の問合せが、その特定のデータ・セットのうちの現在更新されている最中ではないある部分に依存していることを判断し、したがって、その問合せをその特定のデータ・ウェアハウス１２０によって評価できるようにすることができる。このような実施形態においては、データ・セットのうちの更新中ではない部分に対する問合せを、まるでその問合せが、更新されている最中のデータ・セットとは無関係のデータ・セットに依存しているかのように機能的に取り扱うことができ、その更新とは無関係に評価できるようにすることができる。図５Ａの状況においては、このような問合せは、時刻Ｔ３とＴ４の更新完了ポイントと同期化することなく、時刻Ｔ２に受信された後の任意の時点で評価される。

図５Ｂ〜図５Ｄは、図５Ａに示されているさまざまな時点に関連して、大まかな同期化を使用して複製されたデータ・セットの一実施形態の特定の例を示している。図５Ｂ〜図５Ｄに示されている実施形態においては、顧客注文データ・セットは、データ・ウェアハウス１２０ａ〜ｂによって複製されるように構成されている。図５Ｂは、更新の開始よりも前の時点（たとえば、図５Ａに示されている時刻Ｔ１よりも前の時点）での顧客注文データ・セットのレプリカを示している。図５Ｂにおいては、顧客注文データ・セットの双方のレプリカが、更新前の状態で示されている。

図５Ｃは、データ・ウェアハウス１２０ａのレプリカが更新された後の、ただしデータ・ウェアハウス１２０ｂのレプリカが更新される前の時点（たとえば、図５Ａに示されている時刻Ｔ３とＴ４の間の時点）での顧客注文データ・セットのレプリカを示している。図５Ｃに示されているように、顧客注文データ・セットの２つのレプリカは、異なる状態にある。最後に、図５Ｄは、双方のレプリカが更新された後の時点（たとえば、図５Ａに示されている時刻Ｔ４よりも後の時点）での顧客注文データ・セットのレプリカを示している。上述のように、顧客注文データ・セットに対する問合せは、そのデータ・セットに対する更新が開始した後の任意の時点で着信する。そのデータ・セットの要件に応じて、（たとえば図５Ｃに示されているように）双方のデータ・セット・レプリカが別々の内容を有している時点を含めて、双方のデータ・ウェアハウス１２０ａ〜ｂに対して更新が完了する前に、データ・ウェアハウス１２０ａ〜ｂのいずれかの上で特定の問合せを実行できるようにすることができる。

いくつかの実施形態においては、データ・ウェアハウス・システム１００の編成は、システム１００と対話するように構成されているクライアント１４０にとって完全にトランスペアレントであるという点に留意されたい。すなわち、いくつかの実施形態においては、クライアント１４０は、データ・ウェアハウス１２０内における特定のデータ・セットの位置または状態に関する直接の知識をまったく持たないようにすることができる。このようないくつかの実施形態においては、マネージャー１１０は、複数のデータ・ウェアハウス１２０を、クライアント１４０の視点から見た際に単一の仮想データ・ウェアハウスとして提示するように構成される（たとえばマネージャー１１０は、データ・ウェアハウス１２０を仮想化するように構成される）。したがって、このようないくつかの実施形態においては、マネージャー１１０は、（問合せインターフェースなどの）単一の安定したインターフェースをクライアント１４０に提示している間に、データ・セットを複数のデータ・ウェアハウス１２０の間で移動させるために、あるいはシステム１００内に保存されているデータの編成をその他の形で変更するために、データ・セットを任意の度合いで自由に複製できるようにすることができる。

一実施形態においては、任意の特定の時点で、複数のデータ・ウェアハウス１２０によって保存されている複数のデータ・セットを、特定のクライアント１４０によって問合せを行う上で利用できる可能性があり、また任意の特定の時点で、保存されているデータ・セットのうちの１つが、その保存されているデータ・セットのうちの別の１つとは異なることもある。たとえば、保存されている２つのデータ・セットは、別々のタイプのデータを保存するように決められているために異なる可能性がある。あるいは、保存されている２つのデータ・セットは、同じデータを複製するように構成されているかもしれないが、特定の時点においては、上述のような大まかな同期化のオペレーションのために異なっている可能性がある。いくつかの実施形態においては、これらのシナリオのいずれかのもとでの複数のデータ・セットが、クライアント１４０によって問合せを行う上で利用できる可能性があり、マネージャー１１０は、このようなデータ・セットがデータ・ウェアハウス・システム１００内でどのように配置され操作されるかの詳細を、クライアント１４０にとって明白な方法で管理するように構成される。

クライアント１４０に関するデータ・ウェアハウス１２０の仮想化は、データ・ウェアハウス１２０内に保存されているデータ・セットが複製されているかどうかを問わずに行うことができる。クライアント１４０に対して複数のデータ・ウェアハウス１２０を単一のデータ・ウェアハウスとして仮想化する方法の一実施形態が、図６に示されている。図１から図６をまとめて参照すると、オペレーションは、ブロック６００において開始し、このブロック６００では、マネージャー１１０が、データ・ウェアハウス１２０に投入されているデータ・セットに関する位置情報を保存する。たとえば一実施形態においては、マネージャー１１０は、それぞれのデータ・セットごとの位置情報を、そのデータ・セットが複製されているかどうかなど、そのデータ・セットの状態を識別する他の情報と共に、オペレーション・データベース１３０内に保存することができる。

その後、マネージャー１１０は、データ・ウェアハウス・システム１００内に保存されている特定のデータ・セットを対象とする問合せを受信する（ブロック６０２）。これに応答して、マネージャー１１０は、その受信した問合せを評価できる特定のデータ・ウェアハウス１２０を識別する（ブロック６０４）。たとえばマネージャー１１０は、上述のようにデータ・セットや状態の依存度を検知するために問合せを分析するように、およびその問合せを評価できる１つの（あるいは、そのデータ・セットが複製されている場合には、複数の）データ・ウェアハウス１２０を識別するためにオペレーション・データベース１３０を調べるように構成される。進行中のデータ・セットの更新や、データ・ウェアハウスの作業負荷など、他の要因が、問合せを評価するための適切なデータ・ウェアハウス１２０の識別に影響を与える可能性もある。

受信した問合せを評価するためにデータ・ウェアハウス１２０が識別されると、マネージャー１１０は、評価のために、その問合せをその選択されたデータ・ウェアハウス１２０に伝達する（ブロック６０６）。そして、その問合せが評価され（ブロック６０８）、マネージャー１１０を介して要求側のクライアント１４０に結果が返される（ブロック６１０）。いくつかの実施形態においては、問合せの送信と、問合せの結果の受信との間のすべてのステップは、クライアント１４０にとってトランスペアレントであるという点に留意されたい。場合によっては、マネージャー１１０は、評価のための適切なデータ・ウェアハウス１２０をすぐに識別できない場合には、問合せを待ち行列に入れることができるという点にさらに留意されたい。さらにマネージャー１１０は、場合によっては、たとえば問合せが不正な形式である場合や、データ・ウェアハウス１２０を待つ時間が切れた場合には、要求側のクライアント１４０にエラー状態を返すことができる。

データ・ウェアハウスの計算インフラストラクチャー
データ・ウェアハウス１２０は、計算ハードウェアのそれぞれのセットを含み、さらにデータ・ウェアハウジング機能を実装するように構成されているオペレーティング・システム・ソフトウェアやデータ・ウェアハウジング・ソフトウェア（たとえばデータベース・ソフトウェア）を含む。いくつかの実施形態においては、使用される計算ハードウェアは、カスタマイズされたバージョンのオペレーティング・システムと、特定のインストールに固有のデータ・ウェアハウジング・ソフトウェアとに入念に一体化された独自仕様のハイエンドのマルチプロセッサ・コンピュータ・システムを含む。しかしこのような構成は、購入し、管理し、維持する上で高くつくおそれがある。したがって、いくつかの実施形態においては、データ・ウェアハウス１２０のいずれかまたはすべては、広く流通しているまたはオープンソースのオペレーティング・システムおよび／またはデータ・ウェアハウジング・ソフトウェアを実行するより安価な（たとえば日用的な）コンピュータ・システムから作成されたそれぞれのコンピューティング・クラスタをそれぞれ含む。

データ・ウェアハウス１２０を実装することができるコンピューティング・クラスタの一実施形態が、図７に示されている。図示されている実施形態においては、データ・ウェアハウス・クラスタ７００（あるいは、単にクラスタ７００）は、複数のコンピューティング・ノード７１０（あるいは、単にノード７１０）を含む。ノード７１０のそれぞれは、複数のスイッチ７２０のそれぞれに結合されており、それぞれのスイッチ７２０は、それぞれの数のストレージ・アレイ７３０に結合されている。したがって、図示されている実施形態においては、それぞれのノード７１０は、適切なスイッチ７２０を通じてストレージ・アレイ７３０のいずれかにアクセスすることができる。一実施形態においては、クラスタ７００は、１６個のノード７１０、８個のスイッチ７２０、６４個のストレージ・アレイ７３０を含む。しかし、さまざまな実施形態においては、任意の数のノード７１０、スイッチ７２０、ストレージ・アレイ７３０、さらにはこれらの要素を相互接続するためのさまざまなトポロジーを採用することができるという点に留意されたい。

一実施形態においては、ノード７１０のそれぞれは、図８の説明と併せて以降でさらに詳しく説明するように、ユニプロセッサまたはマルチプロセッサのコンピュータ・システムを含む。いくつかの実施形態においては、ノード７１０は、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ、Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄ、ＩＢＭ、Ｄｅｌｌ、あるいは任意の適切なシステム製造業者を含む複数のベンダのうちの任意のベンダから市販されている汎用サーバ、パーソナル・コンピュータ、あるいはワークステーション・システムを含む。さらにノード７１０は、あるバージョンのＬｉｎｕｘ、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ｓｏｌａｒｉｓ、ＨＰ−ＵＸ、ＡＩＸに準拠したオペレーティング・システムや、他の任意の適切な一般に入手可能なまたは独自仕様のオペレーティング・システムなど、１つまたは複数の適切なオペレーティング・システムを実行するように構成される。

一般的に言えば、ノード７１０のそれぞれは、マネージャー１１０を介して受信した問合せや、他のデータ・ウェアハウス・オペレーションを、ストレージ・アレイ７３０を介して保存できるデータ・セットに照らして評価するように機能し、その一方でスイッチ７３０は、ノード７１０とストレージ・アレイ７３０との間における相互接続を提供する。したがって、図示されている実施形態においては、特定のノード７１０上で評価されている問合せは、ストレージ・アレイ７３０のうちのいずれかに保存されているデータ・セットに均一にアクセスすることができる。他の実施形態においては、データ・セットは、複数のノード７１０に不均一に利用可能にすることができる。たとえば特定のノード７１０は、一部のデータ・セットを含むが他のデータ・セットは含まないストレージ・アレイ７３０のうちの特定の１つまたは複数に対応付けるられる。このような実施形態においては、複数のノード７１０は、特定の問合せによって依存されているデータ・セットが複数のストレージ・アレイ７３０にわたってどのように分散されているかに応じて、その問合せの評価に参加する必要があるであろう。

いくつかの実施形態においては、スイッチ７２０とストレージ・アレイ７３０は、ＳＡＮ（ｓｔｏｒａｇｅ ａｒｅａ ｎｅｔｗｏｒｋ）を含む。たとえばスイッチ７２０は、ファイバー・チャネル相互接続や、他の適切なＳＡＮ相互接続と管理テクノロジーを使用して、ノード７１０およびストレージ・アレイ７３０に結合されている。しかし、クラスタ７００のデバイスどうしを相互接続するために任意の適切なタイプのネットワークを使用することもできる。たとえば一実施形態においては、相互接続テクノロジーとして、ギガビット・イーサネット（登録商標）や１０ギガビット・イーサネットを使用することができる。

ストレージ・アレイ７３０のそれぞれは、固定式の磁気ディスク・ドライブなど、１つまたは複数のマス・ストレージ・デバイスを含む。たとえば一実施形態においては、それぞれのストレージ・アレイ７３０は、ＲＡＩＤア（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙ ｏｆ Ｉｎｄｅｐｅｎｄｅｎｔ Ｄｉｓｋｓ）アレイとして構成されているまったく同じ数のＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｆａｃｅ）ハード・ドライブを含む。たとえばディスク・ストライピング、ミラーリング、データ・パリティーなど、ストレージ・アレイ７３０によってサポートされるさまざまなストレージ機能は、ストレージ・アレイ７３０自体によって管理することができる。たとえばストレージ・アレイ７３０は、マス・ストレージ・デバイスに加えて、それらのデバイスを管理するように構成されているさらなるハードウェアを含む。あるいは、ストレージ・アレイ７３０を比較的受け身にすることもでき、そのストレージ機能をインテリジェントなスイッチ７２０によって管理することもできる。特定のストレージ・アレイ７３０は、磁気ディスクに加えて、あるいは磁気ディスクの代わりに、たとえば光メディアや磁気テープなど、他のタイプのストレージ・デバイスを含むということもある。さらに、いくつかの実施形態においては、ストレージ・アレイ７３０のそれぞれをまったく同様に構成することができ、その一方で、他の実施形態においては、ストレージ・アレイ７３０をその構成および／または機能セットの面で異種混成なものにすることができるということもある。

いくつかの実施形態においては、クラスタ７００は、特定のデータ・ウェアハウス１２０の予想される作業負荷にマッチするように、容易に拡張できるようにすることができる。たとえばデータ・ウェアハウス１２０が、まれな問合せや比較的簡単な問合せを受信する大量のデータを格納すると予想される場合には、（上述のような任意の所望のデータ・セットの複製を含む）予想される量のデータを保存するストレージ・アレイ７３０を用意することができ、その一方で、予想される作業負荷に基づいてノード７１０を別個に設けることができる。問合せの作業負荷やストレージの要件が増加した場合には、さらなるノード７１０、スイッチ７２０、および／またはストレージ・アレイ７３０を後から追加することができる。

いくつかの実施形態においては、上述の方法や技術のいずれか、たとえばマネージャー１１０またはデータ・ウェアハウス１２０の機能、あるいは図３、４、６に示されている方法を、コンピュータがアクセス可能なメディアを介して保存し、伝達できるプログラム命令とデータとして実現させることができる。このようなプログラム命令を実行して、データ・ウェアハウジングと仮想化、ストレージ管理、問合せとデータ・セットの分析、問合せの評価、オペレーティング・システムの機能、アプリケーション、ならびに／あるいは他の任意の適切な機能など、特定の計算機能を実施することができる。一実施形態においては、ノード７１０は、コンピュータがアクセス可能なメディアを含む。特定のノード７１０を例示することができるコンピュータ・システムの一実施形態が、図８に示されている。図示されている実施形態においては、コンピュータ・システム８００は、入力／出力（Ｉ／Ｏ）インターフェース８３０を介してシステム・メモリ８２０に結合されている１つまたは複数のプロセッサ８１０を含む。ノード７１０は、ネットワーク・インターフェース８４０やＳＡＮインターフェース８５０をさらに含み、これらは、それぞれＩ／Ｏインターフェース８３０に結合されている。

いくつかの実施形態においては、コンピュータ・システム８００のインスタンスは、クラスタ７００から切り離して構成させることができ、データ・ウェアハウス・システム１００内の他のアプリケーションや機能を実行するように構成されるという点に留意されたい。たとえば一実施形態においては、コンピュータ・システム８００の１つまたは複数のインスタンスは、クラスタ７００の外に提供することができ、コンピュータがアクセス可能なメディアを介して保存や伝達ができるプログラム命令とデータを実行するように構成され、マネージャー１１０を実現するように構成される。このようないくつかの実施形態においては、マネージャー１１０を実現するように構成されているコンピュータ・システム８００のインスタンスの構成は、図８に示されている構成とは異なるものにすることができる。たとえば、いくつかの実施形態においては、コンピュータ・システム８００のこのようなインスタンスは、より多くのプロセッサ８１０、あるいはより少ないプロセッサ８１０を含む。さらに、いくつかの実施形態においては、このようなインスタンスは、ＳＡＮインターフェース８５０を保持することができるが、このインターフェースは、省略することもできる。

上述のように、さまざまな実施形態においては、コンピュータ・システム８００は、１つのプロセッサ８１０を含むユニプロセッサ・システムとすることもでき、あるいは複数の（たとえば２つ、４つ、８つ、または別の適切な数の）プロセッサ８１０を含むマルチプロセッサ・システムとすることもできる。プロセッサ８１０は、命令を実行することができる任意の適切なプロセッサとすることができる。たとえば、さまざまな実施形態においては、プロセッサ８１０は、ｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣ、またはＭＩＰＳ ＩＳＡ、あるいは他の任意の適切なＩＳＡなど、さまざまなＩＳＡ（ｉｎｓｔｒｕｃｔｉｏｎ ｓｅｔ ａｒｃｈｉｔｅｃｔｕｒｅ）のいずれかを実装する汎用プロセッサや内蔵プロセッサとすることができる。マルチプロセッサ・システムにおいては、プロセッサ８１０のそれぞれは一般に、同じＩＳＡを実装することができるが、これは必須ではない。

システム・メモリ８２０は、プロセス８１０によってアクセス可能な命令とデータを保存するように構成される。さまざまな実施形態においては、システム・メモリ８２０を、ＳＲＡＭ、ＳＤＲＡＭ、不揮発性／フラッシュタイプのメモリ、あるいは他の任意のタイプのメモリなど、任意の適切なメモリ・テクノロジーを使用して実装することができる。図示されている実施形態においては、上述のような、所望の機能を実行するプログラム命令とデータは、コード８２５としてシステム・メモリ８２０内に保存されるものとして示されている。

一実施形態においては、Ｉ／Ｏインターフェース８３０は、プロセッサ８１０と、システム・メモリ８２０と、デバイス内のすべての周辺デバイスとの間におけるＩ／Ｏトラフィックを調整するように構成される。周辺デバイスには、ネットワーク・インターフェース８４０、ＳＡＮインターフェース８５０、あるいは他の周辺インターフェースが含まれる。いくつかの実施形態においては、Ｉ／Ｏインターフェース８３０は、すべての必要なプロトコル、タイミング、あるいは他のデータの変換を実行して、あるコンポーネント（たとえばシステム・メモリ８２０）からのデータ信号を別のコンポーネント（たとえばプロセッサ８１０）による使用に適したフォーマットへと変換することができる。いくつかの実施形態においては、Ｉ／Ｏインターフェース８３０は、たとえばＰＣＩバス標準やＵＳＢ標準の変形形態など、さまざまなタイプの周辺バスを通じて接続されているデバイスのためのサポートを含む。いくつかの実施形態においては、Ｉ／Ｏインターフェース８３０の機能は、たとえばノース・ブリッジとサウス・ブリッジなど、複数の別々のコンポーネントへと分割することができる。また、いくつかの実施形態においては、システム・メモリ８２０へのインターフェースなど、Ｉ／Ｏインターフェース８３０の機能のいくつかまたはすべては、プロセッサ８１０内に直接組み込むことができる。

ネットワーク・インターフェース８４０は、コンピュータ・システム８００と、ネットワークに接続されている他のデバイスとの間でデータをやり取りすることを可能にするように構成されている。たとえばマネージャー１１０は、クラスタ７００の外部のコンピュータ・システム８００上で実行するように構成させることができ、クラスタ７００内でノード７１０として構成されている特定のコンピュータ・システム８００は、ネットワーク・インターフェース８４０を介して外部のシステム上のマネージャー１１０と通信することができる。さまざまな実施形態においては、ネットワーク・インターフェース８４０は、任意の適切なタイプのイーサネット・ネットワークなどの有線または無線の一般的なデータ・ネットワークを介して、たとえばアナログ音声ネットワークやデジタル・ファイバー通信ネットワークなどの電気通信／電話ネットワークを介して、ファイバー・チャネルＳＡＮなどのストレージ・エリア・ネットワークを介して、あるいは他の任意の適切なタイプのネットワークおよび／またはプロトコルを介して、通信をサポートすることができる。

一実施形態においては、ＳＡＮインターフェース８５０は、スイッチ７２０を介してコンピュータ・システム８００とストレージ・アレイ７３０との間でデータをやり取りすることを可能にするように構成される。いくつかの実施形態においては、上述のように、ＳＡＮインターフェース８５０は、ファイバー・チャネル・インターフェースや別の適切なインターフェースを含む。しかし、いくつかの実施形態においては、標準的なネットワーク・インターフェースを介してＳＡＮの接続を実装することができるということもある。このような実施形態においては、コンピュータ・システム８００は、ストレージ・デバイスや他のコンピュータ・システムの双方と通信するための単一のネットワーク・インターフェース（たとえば、ネットワーク・インターフェース８４０）を提供することもでき、あるいはコンピュータ・システム８００は、ストレージ・デバイスおよび一般的なネットワーク通信を、いくつかの同様に構成されたネットワーク・インターフェースにわたって均一に分散させることもできる。

いくつかの実施形態においては、システム・メモリ８２０は、上述のようなプログラム命令とデータを保存するように構成されているコンピュータがアクセス可能なメディアの一実施形態とすることができる。しかし他の実施形態においては、プログラム命令および／またはデータは、受信したり、送信したり、あるいは異なるタイプのコンピュータがアクセス可能なメディア上に保存したりすることができる。一般的に言えば、コンピュータがアクセス可能なメディアは、Ｉ／Ｏインターフェース８３０を介してコンピュータ・システム８００に結合されている磁気メディアまたは光メディア、たとえばディスク、ＣＤ−ＲＯＭ、あるいはＤＶＤ−ＲＯＭなどのストレージ・メディアやメモリ・メディア、またはＳＡＮインターフェース８５０を介してコンピュータ・システム８００に結合されているストレージ・アレイ７３０を含む。コンピュータがアクセス可能なメディアは、ＲＡＭ（たとえばＳＤＲＡＭ、ＤＤＲ ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭなど）やＲＯＭなどの任意の揮発性メディアや不揮発性メディアを含むこともでき、これらは、コンピュータ・システム８００のいくつかの実施形態においては、システム・メモリ８２０や別のタイプのメモリとして含む。さらに、コンピュータがアクセス可能なメディアは、ネットワーク・インターフェース８４０やＳＡＮインターフェース８５０を介して実装できるようなネットワークおよび／または無線リンクなどの通信メディアを介して伝達される電気信号、電磁信号、あるいはデジタル信号などの伝送メディアや伝送信号を含む。

上述の実施形態について詳細に説明したが、当業者が上述の開示を十分に理解すれば、多くの変形形態および修正形態が明らかになるであろう。添付の特許請求の範囲は、このような変形形態および修正形態をすべて包含するものと解釈されることを意図している。

データ・ウェアハウジング・システムの一実施形態を示すブロック図である。 複数のデータ・ウェアハウスにわたるデータ・セットの複製の一実施形態を示すブロック図である。 大まかな同期化を使用して、抽出されたデータをデータ・ウェアハウス内に保存する方法の一実施形態を示す流れ図である。 大まかな同期化を使用して、データ・ウェアハウスによって保存されているデータに関して問合せを行う方法の一実施形態を示す流れ図である。 大まかな同期化のもとでのデータ・セットの更新と問合せとの間における関係の一実施形態を示すタイミング図である。 大まかな同期化を使用して複製されたデータ・セットの例示的な一実施形態を示すブロック図である。 大まかな同期化を使用して複製されたデータ・セットの例示的な一実施形態を示すブロック図である。 大まかな同期化を使用して複製されたデータ・セットの例示的な一実施形態を示すブロック図である。 クライアントに対してデータ・ウェアハウスを仮想化する方法の一実施形態を示す流れ図である。 データ・ウェアハウス・コンピューティング・クラスタの一実施形態を示すブロック図である。 コンピュータ・システムの例示的な一実施形態を示すブロック図である。

Claims (29)

1. 複数のデータ・ウェアハウスと、
   前記複数のデータ・ウェアハウスのうちの１つまたは複数の中に保存するために、１つまたは複数のデータ・ソースからデータ・セットを抽出するように構成されているデータ・ウェアハウス・マネージャーと、
   を具備するシステムであって、
   前記複数のデータ・ウェアハウスのうちの２つまたはそれ以上のデータ・ウェアハウスから構成されるサブセットのそれぞれは、前記データ・ウェアハウス・マネージャーによって抽出されたデータ・セットのそれぞれのレプリカを保存するように構成され、
   前記複数のデータ・ウェアハウスのうち１つのデータ・ウェアハウスによって保存され、かつ、ある特定の時点において、問合せを行うためにクライアントにとって利用可能な特定のデータ・セットのレプリカと、前記複数のデータ・ウェアハウスの別の１つによって保存され、かつ、ある特定の時点において、問合せを行うためにクライアントにとって利用可能な前記特定のデータセットの別のレプリカとは、ある特定の時点において異なっており、
   前記複数のデータ・ウェアハウスのうちの１つまたはそれ以上のデータ・ウェアハウスによって保存されている前記特定のデータ・セットを対象とする問合せをクライアントから受信したことに応答して、前記データ・ウェアハウス・マネージャーは、さらに、前記データ・セットの位置と前記データ・セットに関連した現在の状態情報を用いて、その問合せを評価できる前記複数のデータ・ウェアハウスのうちの特定の１つを識別し、その問合せを評価のために前記特定のデータ・ウェアハウスへ伝達するように構成され、
   前記データ・ウェアハウス・マネージャーは、前記特定のデータセットの複数のレプリカが異なる場合であっても、その問合せを評価できると判断する
   ことを特徴とするシステム。
2. 前記データ・セットが前記サブセットの別のデータ・ウェアハウスへ保存されている最中に、前記問合せが前記第１のサブセットの第１のデータ・ウェアハウスによって評価されることを特徴とする請求項１に記載のシステム。
3. 前記データ・ウェアハウス・マネージャーは、前記データ・セットが前記特定のデータ・ウェアハウスへ保存された後に、前記問合せを前記サブセットの任意の特定のデータ・ウェアハウスによって評価可能にするようにさらに構成されていることを特徴とする請求項１または２に記載のシステム。
4. 前記データ・セットをデータ・ウェアハウスの前記サブセットのそれぞれに保存することは、少なくとも部分的に並行して行われることを特徴とする請求項１乃至３のいずれかに記載のシステム。
5. 前記複数のデータ・ウェアハウスのうちの特定の１つは、前記データ・ウェアハウス・マネージャーによって抽出された別のデータ・セットを保存するように構成されており、前記複数のデータ・ウェアハウスのうちの少なくとも別の１つは、前記別のデータ・セットのいかなるレプリカも保存しないことを特徴とする請求項１乃至４のいずれかに記載のシステム。
6. 前記複数のデータ・ウェアハウスのそれぞれは、それぞれのリレーショナル・データベースを有することを特徴とする請求項１乃至５のいずれかに記載のシステム。
7. 前記データ・ウェアハウス・マネージャーは、前記複数のデータ・ウェアハウス内に保存されるそれぞれのデータ・セットに対応する識別情報をオペレーション・データベース内に保存するようにさらに構成されていることを特徴とする請求項１乃至６のいずれかに記載のシステム。
8. 前記データ・セットに関して、前記識別情報は、データ・ウェアハウスの前記サブセットのうちのそれぞれの各ＩＤと、データ・ウェアハウスの前記サブセットのうちの対応する１つへ前記第１のデータ・セットが保存されたかどうかを示すそれぞれの状態情報とを有することを特徴とする請求項７に記載のシステム。
9. 前記データ・ウェアハウス・マネージャーは、データ・ウェアハウスの前記サブセットのうちの特定の１つが、前記それぞれの状態情報に従って前記問合せを評価するための十分なデータを有していることを判断するように、そしてそれに応じて、評価のために前記問合せを前記サブセットのうちの前記特定の１つへ伝達するようにさらに構成されていることを特徴とする請求項８に記載のシステム。
10. 前記複数のデータ・ウェアハウスのうちの少なくとも２つは、別々の物理的な位置に配置されていることを特徴とする請求項１乃至９のいずれかに記載のシステム。
11. 前記複数のデータ・ウェアハウスのそれぞれは、それぞれのコンピューティング・クラスタを有し、特定のそれぞれのコンピューティング・クラスタは、ＳＡＮを介して複数のストレージ・デバイスに結合されている少なくとも１つのコンピューティング・ノードを有することを特徴とする請求項１乃至１０のいずれかに記載のシステム。
12. 前記少なくとも１つのコンピューティング・ノードは、あるバージョンのＬｉｎｕｘに準拠しているオペレーティング・システムを実行するように構成されていることを特徴とする請求項１１に記載のシステム。
13. 前記データ・ウェアハウス・マネージャーは、要求側のアプリケーションからウェブ・サービス・インターフェースを介して前記問合せを受信するように構成されていることを特徴とする請求項１乃至１２のいずれかに記載のシステム。
14. 前記データ・ウェアハウス・マネージャーは、クライアントに、単一のデータ・ウェアハウスとして前記複数のデータ・ウェアハウスを提示し、前記複数のデータ・ウェアハウス内の前記データセットの位置はクライアントにとってトランスペアレントであることを特徴とする請求項１乃至１３のいずれかに記載のシステム。
15. コンピュータ・システムのデータ・ウェアハウス・マネージャーによって実行可能なデータ・ウェアハウジングのための方法であって、当該方法は、
    複数のデータ・ウェアハウスのうちの１つまたは複数の中に保存するために１つまたは複数のデータ・ソースからデータ・セットを抽出するステップと、
    前記複数のデータ・ウェアハウスのうちの複数を含む第１のサブセットのそれぞれのデータ・ウェアハウス内のデータ・セットのそれぞれのレプリカを保存するステップと、
    前記複数のデータ・ウェアハウスのうちの１つまたはそれ以上のデータ・ウェアハウスによって保存されている前記特定のデータ・セットを対象とする問合せをクライアントから受信したことに応答して、前記データ・セットの位置と前記データ・セットに関連した現在の状態情報を用いて、その問合せを評価できる前記複数のデータ・ウェアハウスのうちの特定の１つを識別するステップと、その問合せを評価のために前記特定のデータ・ウェアハウスへ伝達するステップと、
    を含み、
    前記複数のデータ・ウェアハウスのうち１つのデータ・ウェアハウスによって保存され、かつ、ある特定の時点において、問合せを行うためにクライアントにとって利用可能な特定のデータ・セットのレプリカと、前記複数のデータ・ウェアハウスの別の１つによって保存され、かつある特定の時点において、問合せを行うためにクライアントにとって利用可能な前記特定のデータセットの別のレプリカとは、ある特定の時点において異なっており、
    前記特定のデータセットの複数のレプリカが異なる場合であっても、その問合せは評価できると判断されることを特徴とする方法。
16. 前記サブセットの別のデータ・ウェアハウスが前記データ・セットを保存している最中に、前記第１のサブセットのデータ・ウェアハウスが前記問合せを評価するステップをさらに有することを特徴とする請求項１５に記載の方法。
17. 前記データ・セットが前記特定のデータ・ウェアハウスへ保存された後に、前記問合せを、前記サブセットの任意の特定のデータ・ウェアハウスによって評価可能にするステップをさらに有することを特徴とする請求項１５または１６に記載の方法。
18. 前記データ・セットをデータ・ウェアハウスの前記サブセットのそれぞれへ保存するステップは、少なくとも部分的に並行して行われることを特徴とする請求項１５乃至１７のいずれかに記載の方法。
19. 前記複数のデータ・ウェアハウスのうちの特定の１つは、前記データ・ウェアハウス・マネージャーによって抽出された別のデータ・セットを保存するように構成されており、前記複数のデータ・ウェアハウスのうちの少なくとも別の１つは、前記別のデータ・セットのいかなるレプリカも保存しないことを特徴とする請求項１５乃至１８のいずれかに記載の方法。
20. 前記複数のデータ・ウェアハウスのそれぞれは、それぞれのリレーショナル・データベースを有することを特徴とする請求項１５乃至１９のいずれかに記載の方法。
21. 前記複数のデータ・ウェアハウス内に保存されるそれぞれのデータ・セットに対応する識別情報をオペレーション・データベース内に保存するステップをさらに有することを特徴とする請求項１５乃至２０のいずれかに記載の方法。
22. 前記データ・セットに関して、前記識別情報は、データ・ウェアハウスの前記サブセットのうちのそれぞれの各ＩＤと、データ・ウェアハウスの前記サブセットのうちの対応する１つへ前記データ・セットが保存されたかどうかを示すそれぞれの状態情報とを含むことを特徴とする請求項２１に記載の方法。
23. データ・ウェアハウスの前記サブセットのうちの特定の１つが前記それぞれの状態情報に従って前記問合せを評価するための十分なデータを有していることを判断するステップと、
    前記判断するステップに応じて、評価のために前記問合せを前記サブセットのうちの前記特定の１つへ伝達するステップとをさらに有することを特徴とする請求項２２に記載の方法。
24. 前記複数のデータ・ウェアハウスのうちの少なくとも２つは、別々の物理的な位置に配置されていることを特徴とする請求項１５乃至２３のいずれかに記載の方法。
25. 前記複数のデータ・ウェアハウスのそれぞれは、それぞれのコンピューティング・クラスタを含み、特定のそれぞれのコンピューティング・クラスタは、ＳＡＮを介して複数のストレージ・デバイスに結合されている少なくとも１つのコンピューティング・ノードを含むことを特徴とする請求項１５乃至２４のいずれかに記載の方法。
26. 前記少なくとも１つのコンピューティング・ノードは、あるバージョンのＬｉｎｕｘに準拠しているオペレーティング・システムを実行するように構成されていることを特徴とする請求項２５に記載の方法。
27. 要求側のアプリケーションからウェブ・サービス・インターフェースを介して前記問合せを受信するステップをさらに有することを特徴とする請求項１５乃至２６のいずれかに記載の方法。
28. クライアントに、単一のデータ・ウェアハウスとして前記複数のデータ・ウェアハウスを提示するステップであって、前記複数のデータ・ウェアハウス内の前記データセットの位置はクライアントにとってトランスペアレントであるステップと、
    からさらに構成されることを特徴とする請求項１５乃至２７のいずれかに記載の方法。
29. コンピュータ・システムによって実行可能であるプログラム命令を含む、コンピュータ読み取り可能な記録媒体であって、前記プログラム命令は、
    複数のデータ・ウェアハウスのうちの１つまたは複数の中に保存するために、１つまたは複数のデータ・ソースからデータ・セットを抽出するステップと、
    前記複数のデータ・ウェアハウスのうちの２つまたはそれ以上のデータ・ウェアハウスから構成される第１のサブセットのそれぞれの中に第１のデータ・セットのそれぞれのレプリカを保存するステップと、
    前記複数のデータ・ウェアハウスのうちの１つまたはそれ以上のデータ・ウェアハウスによって保存されている前記特定のデータ・セットを対象とする問合せをクライアントから受信したことに応答して、前記データ・セットの位置と前記データ・セットに関連した現在の状態情報を用いて、その問合せを評価できる前記複数のデータ・ウェアハウスのうちの特定の１つを識別するステップと、その問合せを評価のために前記特定のデータ・ウェアハウスへ伝達するステップと、
    を含み、
    前記複数のデータ・ウェアハウスのうち１つのデータ・ウェアハウスによって保存され、かつ、ある特定の時点において、問合せを行うためにクライアントにとって利用可能な特定のデータ・セットのレプリカと、前記複数のデータ・ウェアハウスの別の１つによって保存され、かつ、ある特定の時点において、問合せを行うためにクライアントにとって利用可能な前記特定のデータセットの別のレプリカは、ある特定の時点において異なっており、
    前記特定のデータセットの複数のレプリカが異なる場合であっても、その問合せは評価できると判断されることを特徴とするコンピュータ読み取り可能な記録媒体。

Images