JP5242875B2 - 多次元データベースおよび統合集約サーバ - Google Patents

Description

現況技術の簡単な説明
ますます競争的になりつつある今日の市場で迅速に決然と行動できることは、組織の成功にとってクリティカルである。会社に入手可能な情報の量は急速に増加しており、圧倒されることがたびたびである。このおびただしい量のデータを効果的かつ効率的に管理し、この情報を用いてビジネスの決定を下そうとする組織は、市場における大きな競争的利点を認識するであろう。

データ・ウェアハウジング、すなわち企業全体のデータ・ストアを生み出すことは、この多量のデータを管理することに向けた第１のステップである。データ・ウェアハウスは、多様なオペレーショナル・システムから抽出したデータをまとめたバージョンを記憶する単一の中心位置を提供するので、多くの情報送達システムに不可欠な部分になりつつある。この数年にわたり、オープン・コンピューティング・システムの価格、スケーラビリティ、および頑強性は、データ・ウェアハウジングを情報技術ＣＩＴ戦略の中心コンポーネントにした。データ統合およびデータ・ウェアハウス構築の方法についての詳細は、ｈｔｔｐ：／／ｗｗｗ．ａｃｘｉｏｍ．ｃｏｍ／ｗｈｉｔｅｐａｐｅｒｓ／ｗｐ−１１．ａｓｐで発行されている、Ｌｏｕｉｓ ＲｏｌｌｌｅｉｇｈおよびＪｏｅ Ｔｈｏｍａｓによる「Ｄａｔａ Ｉｎｔｅｇｒａｔｉｏｎ：Ｔｈｅ Ｗａｒｅｈｏｕｓｅ Ｆｏｕｎｄａｔｉｏｎ」という題名の白書にみることができる。

データ・ウェアハウスの構築は、それ自体で特別な困難があり（例えば共通データ・モデルや共通ビジネス辞書などの使用）、複雑な試みである。しかし、単にデータ・ウェアハウスを有するだけでは、しばしば先触れされるデータ・ウェアハウジングのビジネス利益が組織にもたらされることはない。トランザクショナル・システムから意思決定者までのサプライ・チェーンを完全なものにするには、組織は、知識労働者がこれらのウェアハウスに記憶された情報に基づいて戦略的かつ戦術的な決定を下すことのできるシステムを供給する必要がある。これらの決定サポート・システムは、オンライン分析処理（ＯＬＡＰ）システムと呼ばれる。ＯＬＡＰシステムでは、知識労働者が、特定の問題または特定の種類の照会への分析的洞察を提供するために、なじみのあるビジネス用語を使用して直感的かつ迅速かつフレキシブルにオペレーショナル・データを操作することができる。例えば、ＯＬＡＰシステムを使用することにより、意思決定者は、顧客（またはビジネス）次元に沿って情報を「スライシングおよびダイシング」し、ビジネス・メトリックスを製品ごとに、また時間を通して見ることができる。ビジネスの任意の面の性能に関する高レベルまたは詳細な視野を提供する報告を、複数の次元から定義することができる。意思決定者は、報告を掘り下げてより高い詳細レベルで要素を見ることによって、または向きを変えて異なる視点から報告を見ることによって、自分のデータベース全体をナビゲートすることができる。このような完全に機能するビジネス分析を可能にするには、ＯＬＡＰシステムは、（１）複雑な分析をサポートすること、（２）多数の次元にスケールすること、および（３）多くの原子データ・セットに対する分析をサポートすることが必要である。この３つのキー要件について、以下にさらに論じる。

意思決定者は、キー性能メトリックスを用いて自分の領域内の事業を評価するが、ＯＬＡＰシステムは、ユーザによるカスタマイズが可能な形式でこれらのメトリックスを供給できる必要がある。これらのメトリックスは、事前計算されたトランザクショナル・データベースから入手してデータベースに記憶するか、照会プロセス中にオンデマンドで生成することができる。一般的に使用されるメトリックスには以下のものが含まれる。

（１）多次元比率（例えば総計に対するパーセント）−「７月１日から７月１４日までの間の北西ストアで販売されたすべての商品によってなされた、週間販売および部門利益に対する寄与を見せよ。」
（２）比較（例えば実際と計画、今期と前期）−「今期の販売と計画のパーセンテージ差を見せ、前年のそれと比較して計画不一致を識別せよ。」
（３）ランキングおよび統計プロファイル（例えばトップＮ／ボトムＮ、７０／３０、四分位数）−「世界中の販売の上位３０％にいる最も収益の高い自分の販売員２０人について、１日あたりの販売、利益、および平均コール量を表示せよ。」
（４）カスタム統合−「自分の西領域の事業について過去２期に関する期ごとの概略収入申告を見せよ。」
知識労働者は、いくつかの異なるビジネス視点または次元からデータを分析する。以下において次元とは、データ・モデル中の要素の他の組合せに対して直交に表示することのできる、データ・モデル中の任意の要素、または要素の階層的な組合せについて用いる。例えば、報告が販売を、週、販売促進、店、および部門によってリストしている場合、この報告は、四次元データ・モデルから取られた１つのデータとなる。

ターゲット・マーケティングおよび市場セグメント化の適用例では、十分な条件を有する結果セットを多量のデータから抽出することが必要である。例えば、直接マーケティング組織は、購入頻度、最後の購入のサイズ、過去の購買傾向、顧客の場所、顧客の年齢、および顧客の性別を含めた多くの特徴に基づく、ターゲットを絞った発送先名簿を作成したい場合がある。これらの適用例は、分析のための次元性要件を急速に増大させている。

ＯＬＡＰシステム中の次元の数は、わずかな直交次元から何百もの直交次元にまで及ぶ。例示的なＯＬＡＰアプリケーション中の直交次元は、地理、時間、および製品を含む。

原子データとは、効果的な意思決定に必要な最低レベルのデータ細分性を指す。小売りマーチャンダイジング管理者の場合、「原子データ」は、店ごと、日ごと、および商品ごとの情報を指す場合がある。銀行家の場合、原子データは、口座ごと、取引ごと、および支店ごとの情報である場合がある。ＯＬＡＰシステムを実装するほとんどの組織は、何十、何百、さらには何千ギガバイトもの原子情報にスケールできるシステムを必要としている。

ＯＬＡＰシステムがより普及して大多数の企業によって使用されるようになるにつれて、より長い時間枠にわたるより多くのデータがデータ・ストア（データ・ウェアハウス）に含まれることになり、データベースのサイズは少なくとも一桁は増加することになる。したがって、ＯＬＡＰシステムは、現在のデータ量から近い将来のデータ量にスケールできる必要がある。

一般にＯＬＡＰシステムは、（１）意思決定者の複雑な分析要件をサポートすること、（２）いくつかの異なる視点（すなわちビジネス次元）からデータを分析すること、および（３）組織によって維持されるデータ・ウェアハウスからの多くの入力（原子レベル）データ・セットに対してリレーショナル・データベース管理システム（ＲＤＢＭＳ）を使用した複雑な分析を行うのをサポートすることが必要である。

ＯＬＡＰジステムのベンダは、基底をなすアーキテクチャに基づいて、ＯＬＡＰシステムをリレーショナルＯＬＡＰ（ＲＯＬＡＰ）と多次元ＯＬＡＰ（ＭＯＬＡＰ）のいずれかに分類している。したがってオンライン分析処理システムには、２つの基本アーキテクチャ、すなわちＲＯＬＡＰアーキテクチャおよびＭＯＬＡＰアーキテクチャがある。

リレーショナルＯＬＡＰ（ＲＯＬＡＰ）システムは、データ・ウェアハウスに記憶されたデータにアクセスしてＯＬＡＰ分析を提供する。ＲＯＬＡＰの前提は、ＯＬＡＰ能力が直接にリレーショナル・データベースすなわちデータ・ウェアハウスに対して最適に提供されることである。

ＲＯＬＡＰアーキテクチャは、データ・ウェアハウスからのデータの直接アクセスを可能にするために発明されたものであり、したがって、バッチ・ウィンドウ要件を満たし高速な応答時間を実現するための最適化技法をサポートする。通常、これらの最適化技法には、アプリケーションレベルのテーブル区分化、事前集約推論、非正規化サポート、および複数のファクト・テーブルの結合が含まれる。

典型的な従来技術のＲＯＬＡＰシステムは、３段または３層のクライアント／サーバ・アーキテクチャを有する。「データベース層」は、データ記憶、アクセス、および検索のプロセスにリレーショナル・データベースを利用する。「アプリケーション・ロジック層」は、複数のユーザからの多次元報告を実行するＲＯＬＡＰエンジンである。ＲＯＬＡＰエンジンは、ユーザがＯＬＡＰ分析を行うのに用いる様々な「プレゼンテーション層」と統合する。

データ・ウェアハウスに関するデータ・モデルが定義された後、オンライン・トランザクション処理（ＯＬＴＰ）システムからのデータがリレーショナル・データベース管理システム（ＲＤＢＭＳ）にロードされる。データ・モデルによって必要とされる場合は、データベース・ルーチンが実行されて、ＲＤＢＭＳ内のデータが事前集約される。次いで、照会アクセス時間を最適化するための索引が生み出される。エンド・ユーザが多次元分析をＲＯＬＡＰエンジンにサブミットし、次いでＲＯＬＡＰエンジンは、要求をＳＱＬ実行計画に動的に変換する。ＳＱＬ実行計画は、リレーショナル・データベースにサブミットされて処理され、リレーショナル照会結果が相互作表され、多次元結果データ・セットがエンド・ユーザに返される。ＲＯＬＡＰは、事前計算された結果が利用可能なときはそれらを利用するか、または必要なときは原子情報から動的に結果を生成することのできる、完全に動的なアーキテクチャである。

多次元ＯＬＡＰ（ＭＯＬＡＰ）システムは、専有の多次元データベース（ＭＤＤＢ）を利用してＯＬＡＰ分析を提供する。ＭＤＤＢは、多次元配列（通常は多次元キューブまたはハイパーキューブまたはキューブと呼ばれる）として論理的に構成され、この行／列はそれぞれ異なる次元（すなわち関係）を表す。次元の各組合せ（通常は「座標」と呼ばれる）にデータ値が関連付けられる。このアーキテクチャの主な前提は、データが多次元でアクセスされ閲覧されるように、データを多次元で記憶しなければならないことである。

図１Ｂに示すように、従来技術のＭＯＬＡＰシステムは、集約アクセス検索モジュールを有し、このモジュールは、ＭＤＤＢ中のデータ集約（すなわち事前集約）を含めて、データ記憶、アクセス、および検索のプロセスすべてを担う。図１Ｂに示すように、データ・ウェアハウスから多次元データベース（ＭＤＤＢ）へのベース・データが、最も詳細なレベルでベース・データ・ローダに供給される。ベース・データの最上部には、集約アクセス検索モジュールの一部である集約プログラムによって、集約されたデータの層が構築される。この図に示すように、アプリケーション・ロジック・モジュールが、ＭＤＤＢ内のデータのＯＬＡＰ要求／参照（例えば比率、ランク、予測、例外走査、スライシングおよびダイシング）すべてを担う。プレゼンテーション・モジュールが、アプリケーション・ロジック・モジュールと統合してインタフェースを形成し、エンド・ユーザはこのインタフェースを介して、おそらくインターネットのインフラストラクチャによってウェブに対応している自分のクライアント・マシン上で、ＯＬＡＰ分析を閲覧および要求する。ＭＯＬＡＰシステムのクライアント／サーバ・アーキテクチャでは、複数のユーザが同じ多次元データベース（ＭＤＤＢ）にアクセスすることができる。

データ・ウェアハウスを備える企業内の様々なオペレーショナル・システムからの情報（すなわち基本データ）が、一連のバッチ・ルーチンを通して従来技術の多次元データベース（ＭＤＤＢ）にロードされる。従来技術のＭＯＬＡＰシステムでデータ・ローディング・プロセスを実施するのに使用できる一般的なサーバの一例は、Ｏｒａｃｌｅ ＣｏｒｐｏｒａｔｉｏｎによるＥｘｐｒｅｓｓ（商標）サーバである。図２Ｂに示すように、例示的な３Ｄ ＭＤＤＢが概略的に描いてあり、データベースの「次元」として、地理、時間、および製品が示してある。ＭＤＤＢの多次元データは、図２Ｃに示すように配列構造に論理的に構成される。物理的には、Ｅｘｐｒｅｓｓ（商標）サーバは、情報ファイルのページ（またはレコード）にデータを記憶する。ページは、Ｅｘｐｒｅｓｓ（商標）サーバのプラットフォームおよびリリースに応じて、５１２バイト、または２０４８バイト、または４０９６バイトのデータを含む。ディスクまたはその他の大容量記憶デバイスに記録されたデータベース・ファイルから物理レコード・アドレスを探すために、Ｅｘｐｒｅｓｓ（商標）サーバは、「ページ割振りテーブル（ＰＡＴ）」と呼ばれるデータ構造を生成する。図２Ｄに示すように、ＰＡＴは、データのページを含む物理レコード番号をＥｘｐｒｅｓｓ（商標）サーバに知らせる。通常、ＰＡＴはページに構成される。ＭＤＤＢ中のデータ要素にアクセスする最も単純な方式は、以下の単純な公式で表される加算および乗算を用いて「オフセット」を計算することによる方式である。

Ｏｆｆｓｅｔ＝Ｍｏｎｔｈｓ＋Ｐｒｏｄｕｃｔ＊（＃ｏｆ＿Ｍｏｎｔｈｓ）＋Ｃｉｔｙ＊（＃ｏｆ＿Ｍｏｎｔｈｓ＊＃ｏｆ＿Ｐｒｏｄｕｃｔｓ）
ＯＬＡＰセッション中、従来技術のＭＤＤＢ上での多次元照会の応答時間は、ＭＤＤＢ中のセルを「実行中に」いくつ追加しなければならないかによって決まる。ＭＤＤＢ中の次元の数が直線的に増加するにつれて、ＭＤＤＢ中のセルの数は指数関数的に増加する。しかし、大多数の多次元照会は、要約された高レベル・データを扱うことが知られている。したがって、図３Ａおよび３Ｂに示すように、原子データ（すなわち「基本データ」）がＭＤＤＢにロードされると、ＭＤＤＢの直交次元に沿ってデータ要素を集約（すなわち事前集約）してその配列構造を埋めるために一連の計算を一括して行うのが一般的な手法である。例えば、特定の州（すなわちニューヨーク州）内の小売店についての収入額を共に加えて、ＭＤＤＢ中の州レベルのセルを埋める。データベース中の配列構造が埋められた後、整数ベースの索引が生み出され、ハッシング・アルゴリズムを使用して照会アクセス時間が改善される。Ｄ（）次元に沿ったＭＤＤＢの断面に沿って、次元Ｄ（）の事前集約が常に実施される。

図３Ｃ１および３Ｃ２に示すように、ＭＤＤＢにロードされた生データが最初にその最低の次元階層で構成され、事前集約の結果がＭＤＤＢの隣接部分に記憶される。

図３Ｃ２に示すように、時間次元に沿って、週が日の集約結果であり、月が週の集約結果であり、期が月の集約結果である。図には示していないが、地理次元に沿って、州が市の集約結果であり、国が州の集約結果であり、大陸が国の集約結果である。ＭＤＤＢのすべての次元に沿ってすべての論理的小計および総計を事前集約する（すなわち統合またはコンパイルする）ことにより、基本（すなわち原子）データと事前集約済みデータの両方を含む多次元データベース（ＭＤＤＢ）を使用してリアルタイムのＭＯＬＡＰ操作を実施することが可能である。このコンパイル・プロセスが完了すると、ＭＤＤＢは使用できる状態になる。ユーザは、ＯＬＡＰアプリケーション・インタフェースを介して（例えばウェブ対応クライアント・マシンを使用して）照会をサブミットすることによってＯＬＡＰ報告を要求し、アプリケーション・ロジック層が、サブミットされた照会に応答して、記憶されているデータをＭＤＤＢから検索してクライアント・マシン上に表示する。

通常、ＭＤＤＢシステムでは、集約されたデータは非常にまばらであり、次元数が増加するにつれて爆発的に増加する傾向があり、検索プロセスを劇的に遅くする（「Ｄａｔａｂａｓｅ Ｅｘｐｌｏｓｉｏｎ：Ｔｈｅ ＯＬＡＰ Ｒｅｐｏｒｔ」という題名の報告書（ｈｔｔｐ：／／ｗｗｗ．ｏｌａｐｒｅｐｏｒｔ．ｃｏｍ／ＤａｔａｂａｓｅＥｘｐｌｏｓｉｏｎ．ｈｔｍ）に記述されており、これを参照により本明細書に組み込む）。照会されたデータを高速かつオンラインで検索することは、ＯＬＡＰ照会に対するオンライン応答を送達する上でクリティカルである。したがって、ＭＤＤＢのデータ構造と、その記憶、索引付け、および処理の方法は、大量のデータおよびまばらなデータを高速検索する必要性によって主に決定される。

この問題に対する様々な解決法が、以下の米国特許に開示されており、それぞれの全体を参照により本明細書に組み込む。
・５８２２７５１「Ｅｆｆｉｃｉｅｎｔ Ｍｕｌｔｉｄｉｍｅｎｓｉｏｎａｌ Ｄａｔａ Ａｇｇｒｅｇａｔｉｏｎ Ｏｐｅｒａｔｏｒ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ」
・５８０５８８５「Ｍｅｔｈｏｄ Ａｎｄ Ｓｙｓｔｅｍ Ｆｏｒ Ａｇｇｒｅｇａｔｉｏｎ Ｏｂｊｅｃｔｓ」
・５７８１８９６「Ｍｅｔｈｏｄ Ａｎｄ Ｓｙｓｔｅｍ Ｆｏｒ Ｅｆｆｉｃｉｅｎｔｌｙ Ｐｅｒｆｏｒｍｉｎｇ Ｄａｔａｂａｓｅ Ｔａｂｌｅ Ａｇｇｒｅｇａｔｉｏｎ Ｕｓｉｎｇ Ａｎ Ａｇｇｒｅｇａｔｉｏｎ Ｉｎｄｅｘ」
・５７４５７６４「Ｍｅｔｈｏｄ Ａｎｄ Ｓｙｓｔｅｍ Ｆｏｒ Ａｇｇｒｅｇａｔｉｏｎ Ｏｂｊｅｃｔｓ」
従来技術のすべてのＯＬＡＰサーバでは、ＭＤＤＢを記憶、索引付け、および処理するプロセスは、記憶および集約を遅くする犠牲を払って、照会プロセスの一部として複雑なデータ構造を利用して検索速度を大きく向上させている。照会によって制限される構造は、非常にまばらで多階層である制約環境では高速な照会検索をサポートするはずだが、高速な集約のためには最適な構造ではない。

集約アクセス検索モジュールは、集約プロセスに加えて、データ記憶、検索、およびアクセスのプロセスすべても担う。ロジック・モジュールは、ＯＬＡＰ照会の実行を担う。プレゼンテーション・モジュールは、ユーザとロジック・モジュールとの間を媒介し、エンド・ユーザがＯＬＡＰ分析を閲覧および要求するのに用いるインタフェースを提供する。このクライアント／サーバ・アーキテクチャでは、複数のユーザが同時に多次元データベースにアクセスすることができる。

要約すると、ＯＬＡＰシステムの一般的なシステム要件は、（１）複雑な分析をサポートすること、（２）多数の次元にスケールすること、および（３）多くの原子データ・セットに対する分析をサポートすることを含む。

ＭＯＬＡＰシステム・アーキテクチャは、分析的に複雑である報告／分析能力を提供することができる。しかし、効果的となりエンド・ユーザの要件を満たすためには、ＭＯＬＡＰデータベースは高度の集約を必要とするので、要件（２）および（３）は根本的にＭＯＬＡＰの機能を制限する。

対照的に、ＲＯＬＡＰシステム・アーキテクチャでは、低度の集約で済むシステムの構築が可能だが、このようなシステムは、ＭＯＬＡＰシステム・アーキテクチャの原理に基づくシステムよりも著しく遅い。結果としてＲＯＬＡＰシステムの集約時間が長いことにより、その量および次元的能力が厳しい制限を受ける。

図５に示すグラフは、ＯＬＡＰセッション中にＭＤＤＢを探索するときに生み出される計算需要をはっきりと示しており、このセッションでは、照会に対する回答がＭＯＬＡＰシステムに提示され、それへの回答がしばしばリアルタイム制約の元で求められる。しかし、従来技術のＭＯＬＡＰシステムは、データ集約を動的に生み出す能力が限られているか、または、事前計算されてからＭＤＤＢに記憶されたのではないビジネス・メトリックスを計算する能力が限られている。

ある種の市場セグメント化の適用例における多量のデータおよび高次元性は、現在の多次元データベースの限度を超えて甚だしいものである。
ＲＯＬＡＰは、より多くのデータ量に対応することができる。しかしＲＯＬＡＰアーキテクチャは、その量の多さおよび優れた次元性にもかかわらず、ＭＯＬＡＰと比較して、以下のようないくつかの大きな欠点をこうむる。

・多量のデータを完全に集約するのに非常に時間がかかり、そうでない場合、部分的な集約は照会応答を激しく劣化させる。
・照会応答がより遅い。

・開発者およびユーザがＳＱＬを知っている必要がある。
・ＳＱＬは、ＯＬＡＰに必要な複雑な分析能力がより低い。
・ＲＯＬＡＰは、限られたアプリケーション機能しか提供しない。

したがって、ＭＯＬＡＰシステム内でデータを集約するための改良型の技法が、ＭＤＤＢ中の次元数および原子（すなわち基本）データ・セットのサイズを大きく増やすことができ、それによりＭＯＬＡＰシステム・アーキテクチャの使用を増大させると思われる。

また、ＲＯＬＡＰシステム内でデータを集約するための改良型の技法も、多量のデータに対する照会性能を最大限にすることができ、照会応答を劣化させる部分的集約の時間を短縮し、したがってＲＯＬＡＰシステム・アーキテクチャにとって概して有益になると思われる。

したがって、従来技術のシステムおよび方法の短所および障害を回避しながら多次元データベース（ＭＤＤＢ）内のデータ要素を集約するための改良型の方式および手段が、当技術分野で強く必要とされている。

前述のように、今日のオペレーショナル・データベース・システムおよび情報データベース・システムは通常、データベース管理システム（ＤＢＭＳ）（ＲＤＢＭＳシステム、オブジェクト・データベース・システム、オブジェクト／リレーショナル・データベース・システムなど）を、データ記憶およびデータ照会のためのリポジトリとして使用する。図１４に、前述の従来技術の手法を利用したデータ・ウェアハウス−ＯＬＡＰ領域を示す。データ・ウェアハウスは企業全体のデータ・ストアである。データ・ウェアハウスは、多様なオペレーショナル・ジステムから抽出したデータをまとめたバージョンを記憶する単一の中心位置を提供するので、多くの情報送達システムに不可欠な部分になりつつある。データ統合およびデータ・ウェアハウス構築の方法についての詳細は、ｈｔｔｐ：／／ｗｗｗ．ａｃｘｉｏｍ．ｃｏｍ／ｗｈｉｔｅｐａｐｅｒｓ／ｗｐ−１１．ａｓｐで発行されている、Ｌｏｕｉｓ ＲｏｌｌｌｅｉｇｈおよびＪｏｅ Ｔｈｏｍａｓによる「Ｄａｔａ Ｉｎｔｅｇｒａｔｉｏｎ：Ｔｈｅ Ｗａｒｅｈｏｕｓｅ Ｆｏｕｎｄａｔｉｏｎ」という題名の白書にみることができる。

データ・ウェアハウスの構築は、それ自体で特別な困難があり（例えば共通データ・モデルや共通ビジネス辞書などの使用）、複雑な試みである。しかし、単にデータ・ウェアハウスを有するだけでは、しばしば先触れされるデータ・ウェアハウジングのビジネス利益が組織にもたらされることはない。トランザクショナル・システムから意思決定者までのサプライ・チェーンを完全なものにするに は、組織は、知識労働者がこれらのウェアハウスに記憶された情報に基づいて戦略的かつ戦術的な決定を下すことのできるシステムを供給する必要がある。これらの決定サポート・システムは、オンライン分析処理（ＯＬＡＰ）システムと呼ばれる。このようなＯＬＡＰシステムは一般に、前述のようにリレーショナルＯＬＡＰ（ＲＯＬＡＰ）または多次元ＯＬＡＰ（ＭＯＬＡＰ）として分類される。

リレーショナルＯＬＡＰ（ＲＯＬＡＰ）システムは、リレーショナル・データベース（データ・ウェアハウスの一部）に記憶されたデータにアクセスしてＯＬＡＰ分析を提供する。ＲＯＬＡＰの前提は、ＯＬＡＰ能力が直接にリレーショナル・データベースに対して最適に提供されることである。ＲＯＬＡＰアーキテクチャは、データ・ウェアハウスからのデータの直接アクセスを可能にするために発明されたものであり、したがって、バッチ・ウィンドウ要件を満たし高速な応答時間を実現するための最適化技法をサポートする。通常、これらの最適化技法には、アプリケーションレベルのテーブル区分化、事前集約推論、非正規化サポート、および複数のファクト・テーブルの結合が含まれる。

前述のように、典型的な従来技術のＲＯＬＡＰシステムは、３段または３層のクライアント／サーバ・アーキテクチャを有する。「データベース層」は、データ記憶、アクセス、および検索のプロセスにリレーショナル・データベースを利用する。「アプリケーション・ロジック層」は、複数のユーザからの多次元報告を実行するＲＯＬＡＰエンジンである。ＲＯＬＡＰエンジンは、ユーザがＯＬＡＰ分析を行うのに用いる様々な「プレゼンテーション層」と統合する。データ・ウェアハウスに関するデータ・モデルが定義された後、オンライン・トランザクション処理（ＯＬＴＰ）システムからのデータがリレーショナル・データベース管理システム（ＲＤＢＮＳ）にロードされる。データ・モデルによって必要とされる場合は、データベース・ルーチンが実行されて、ＲＤＢＭＳ内のデータが事前集約される。次いで、照会アクセス時間を最適化するための索引が生み出される。エンド・ユーザが多次元分析をＲＯＬＡＰエンジンにサブミットし、次いでＲＯＬＡＰエンジンは、要求をＳＱＬ実行計画に動的に変換する。ＳＱＬ実行計画は、リレーショナル・データベースにサブミットされて処理され、リレーショナル照会結果が相互作表され、多次元結果データ・セットがエンド・ユーザに返される。ＲＯＬＡＰは、事前計算された結果が莉用可能なときはそれらを利用するか、または必要なときは原子情報から動的に結果を生成することのできる、完全に動的なアーキテクチャである。

多次元ＯＬＡＰ（ＭＯＬＡＰ）システムは、専有の多次元データベース（ＭＤＤＢ）（または「キューブ」）を利用してＯＬＡＰ分析を提供する。このアーキテクチャの主な前提は、データが多次元でアクセスされ閲覧されるように、データを多次元で記憶しなければならないことである。このようなＭＯＬＡＰシステムは、ユーザが集約済みデータを「スライシングおよびダイシング」できるようにＭＤＤＢデータ構造を照会することを可能にするインタフェースを提供する。図１５に示すように、このようなＭＯＬＡＰシステムは、ＭＤＤＢ中のデータ集約（すなわち事前集約）を含めたデータ記憶、アクセス、および検索のプロセスすべてを担う集約エンジンと、ユーザとインタフェースして分析的分析、照会入力、およびユーザへの照会結果報告を提供することを担う分析処理／ＧＵＩモジュールとを備える。リレーショナル・データベースでは、データはテーブルに記憶される。対照的に、ＭＤＤＢは非リレーショナル・データ構造である。すなわち、テーブルの代わりにまたはテーブルに加えて他のデータ構造を用いてデータが記憶される。

データ集約操作を実施するための改良型の方法および装置が強く必要とされる適用領域は他にもある。例えば、今日のオペレーショナル・データベースおよび情報データベースは、このような領域の代表である。前述のように、今日のオペレーショナル・データベースおよび情報データベースは通常、リレーショナル・データベース・システム（ＲＤＢＭＳ）を、データ記憶およびデータ照会のためのリポジトリとして使用する。図１６Ａに、ＲＤＢＭＳ中の例示的なテーブルを示す。図１６Ｂおよび１６Ｃに、図１６Ａのテーブルに対する演算子（照会）およびこのような照会の結果をそれぞれ示す。図１６Ｂおよび１６Ｃに示す演算子は、当技術分野における慣例どおりＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）ステートメントとして表現したものである。

ＳＱＬ標準化の実状、ＲＤＢＭＳに関するツールの豊富さ、およびＲＤＢＭＳシステムにおける専門知識が容易に入手可能であることから、必然的に、情報データベース・システム中でＲＤＢＭＳをデータ・リポジトリとして使用する選択が生じる。しかし、ＲＤＢＭＳ技術の照会コンポーネントは、リレーショナル・データ・モデルの性質そのものから生じる性能の問題および最適化の問題をこうむる。より具体的には、照会処理の間、リレーショナル・データ・モデルは、照会にマッチする生データ要素を突き止める機構を必要とする。さらに、集約操作を含む照会をサポートするには、このような集約操作を、照会にマッチする生データ要素全体に対して行わなければならない。大規模な多次元データベースの場合、これらの操作を単純に実施するとすれば計算集約型のテーブル走査が必要になり、これは許容できない照会応答時間につながる。

従来技術がこの問題にどのように取り組んできたかをよりよく理解するには、リレーショナル・データベース・モデルについて簡単に述べることが役立つであろう。リレーショナル・データベース・モデルによれば、リレーショナル・データベースは、論理スキーマとこのスキーマを実装するテーブルとで表される。論理スキーマは、１つまたは複数の次元（エンティティ）と所与の次元に関連する属性とを定義するテンプレートのセットで表される。所与の次元に関連する属性は、それをデータベース中の他のあらゆる次元と区別する１つまたは複数の属性（次元識別子）を含む。次元間の関係は、属性を結合することによって形成される。テンプレートのセットと論理スキーマの関係とを表すデータ構造は、通常、カタログまたは辞書と呼ばれる。論理スキーマはデータベースの関係構成を表すが、それ自体ではどんなファクト・データも保持しないことに留意されたい。このファクト・データは、論理スキーマを実装するテーブルに記憶される。

リレーショナル・データベースの論理構造を表すために、スター・スキーマが頻繁に用いられる。スター・スキーマの基本的な前提は、情報をファクトと次元の２つのグループに分類できることである。ファクトは、分析されるコア・データ要素である。例えば、販売される個々の商品の単位がファクトであり、ファクトに関する属性が次元である。例えば次元は、購入される製品タイプおよびデータ購入である。このスキーマに対するビジネスの質問は、次元のセット（市場、製品、期間）を通して具体的なファクト（単位）を探すことで行われる。中央ファクト・テーブルは、通常、その次元テーブルよりもずっと大きい。

図１７Ａに、時間枠（「時間枠」次元）にわたる供給元（「供給元」次元）および部品（「部品」次元）についての例示的なスター・スキーマを示す。これは、複数の次元すなわち「供給元」、「部品」、「時間枠」の次元を関係付ける中央ファクト・テーブル「供給部品」を含む。図１７Ｂに、図１７Ａのスター・スキーマを実装するのに用いられるテーブルを示す。より具体的には、これらのテーブルは、中央ファクト・テーブルおよび図１７Ａの論理スキーマ中の各次元についての次元テーブルを含む。所与の次元テーブルは、論理スキーマ中で定義される次元の行（インスタンス）を記憶する。記述のために、図１７Ｂには「時間枠」次元のみに関する次元テーブルを示す。「供給元」および「部品」次元に関する同様の次元テーブル（図示せず）も、このような実装形態に含まれる。中央ファクト・テーブル内の各行は、一組のファクトに関連するマルチパート・キー（この例では量を表す数字）を含む。所与の行のマルチパート・キー（図示のようにＳ＃、Ｐ＃、ＴＰ＃フィールドに記憶された値）は、前述の次元テーブルに記憶された行（インスタンス）をポイントする。スター・スキーマとスター・スキーマの実装に用いられるテーブルとに関するより詳細な記述は、Ｃ．Ｊ．Ｄａｔｏ「Ａｎ Ｉｎｔｒｏｄｕｃｔｉｏｎ ｔｏ Ｄａｔａｂａｓｅ Ｓｙｓｔｅｍｓ」第７版、Ａｄｄｉｏｎ−Ｗｅｓｌｅｙ、２０００、ｐｐ．７１１〜７１５にみることができ、この全体を参照により本明細書に組み込む。

照会を処理するとき、スキーマを実施するテーブルがアクセスされて、照会に合致するファクトが検索される。たとえば、上述のようなスター・スキーマ実施では、ファクトが中央ファクト・テーブルおよび／または次元テーブルから検索される。所与の照会に合致するファクトを位置付けることは、１つまたは複数の結合オペレーションを含む。さらに、集約オペレーションを含む照会をサポートするため、このような集約オペレーションは、照会に合致するファクト上で実行されなければならない。大規模多次元データベースでは、これらのオペレーションの単純な実施は計算集中的なテーブル走査を含み、これは通常受け入れ不可能な照会応答時間に通じる。さらに、ファクト・テーブルがビジネス次元に沿って事前要約かつ集約されるので、これらのテーブルは非常に大きくなる傾向がある。この点は、スター・スキーマに関連する性能上の問題点の重要な考慮すべき事項となる。スター・スキーマの結合および集約に関係する性能上の問題点（およびこのような問題点に対処する手法の提案）のより詳細な考察を以下に述べる。

第１の性能上の問題点は、データ結合の単純な実施によって実行される計算集中的なテーブル走査から生じる。スキーマの索引付けを使用して、結合オペレーションを実行するときにこれらの走査を回避することができる。このような方法には、Ｂツリー案引付け、逆リスト索引付けおよび集約索引付けが含まれる。このような索引付け方法のより詳細な説明は、ｈｔｔｐ：／／ｗｗｗ．ｄｉｓｃ．ｃｏｍ／ａｒｔｉｎｄｅｘ．ｐｄｆで入手可能な「Ｔｈｅ Ａｒｔ ｏｆ Ｉｎｄｅｘｉｎｇ」、Ｄｙｎａｍｉｃ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍｓ Ｃｏｒｐｏｒａｔｉｏｎ、１９９９年１０月で見ることができる。これらの索引付け方法のすべては、テーブル走査オペレーション（照会に合致するデータ要素の位置付けに含まれる）を１つまたは複数の索引ルックアップ・オペレーションで置き換える。逆リスト索引付けは索引をデータ要素のグループに関連付け、（索引によって識別された場所に）関連付けられたデータ要素へのポインタのグループを格納する。照会処理中に、照会が索引に合致した場合、索引に格納されたポインタが使用されて、そこからポイントされた対応するデータ要素が検索される。集約索引付けは集約索引を逆リスト索引と統合して、集約を必要とする生データ要素へのポインタを提供し、それにより、ユーザが提出した照会に合致する生データ要素の動的な要約に備える。

これらの索引付け方法は、照会に合致するデータ要素を位置付けるために、テーブル走査オペレーションを１つまたは複数の索引ルックアップ・オペレーションで置き換えることによって、結合オペレーションを改善するように意図される。しかし、これらの索引付け方法は以下のような様々な性能上の問題点を欠点として持つ。

・スター・スキーマ・デザインにおけるテーブルは通常、属性の階層全体を含む（たとえば、「期間」次元では、この階層が日＞週＞月＞四半期＞年となる可能性がある）ので、日、週、月、四半期、年のマルチパート・キーを作成しなければならず、したがって、多数のメタデータ定義（各キー・コンポーネントの１つ）が単一の関係を定義することが必要となり、これによりデザインの複雑性が増し、性能が不調になる。

・階層におけるレベルの追加または削除にはファクト・テーブルの物理的な修正が必要となり、これは時間を要する処理であり、柔軟性が制限される。
・ファクト・テーブルにおいて複合次元キーのすべてのセグメントを持つことにより索引のサイズが増大し、よって性能およびスケーラビリティに影響を及ぼす。

もう１つの性能上の問題点は、多数の階層を含む次元テーブルから生じる。このような場合、次元テーブルがしばしばレコード毎に１レベルの階層標識を含む。詳細を格納し、かつ集約するファクト・テーブルからのあらゆる検索は、この標識を使用して正しい結果を得なければならず、これは性能に影響を及ぼす。レベル標識の使用に代わる最適なものは、スノーフレーク・スキーマである。このスキーマでは、集約テーブルが詳細テーブルとは別々に作成される。メインのファクト・テーブルに加えて、スノーフレーク・スキーマは集約の各レベル毎に別々のファクト・テーブルを含む。スノーフレーク・スキーマはスター・スキーマより複雑でさえあり、しばしば、必要とされる結果を得るために多数のＳＱＬステートメントを必要とすることに留意されたい。

もう１つの性能上の問題点は、ペアワイズ結合の問題から生じる。従来のＲＤＢＭＳエンジンは、スター・スキーマに対して発行される複雑な照会の豊富なセットのためのデザインではない。関係付けられた情報をいくつかのテーブルから単一の照会において検索する、すなわち「結合処理」の必要性は、非常に制限される。多数のＲＤＢＭＳは一度に２つのテーブルしか結合することができない。複雑な結合が２つ以上のテーブルを含む場合、ＲＤＢＭＳは照会を一連のペアワイズ結合に分割する必要がある。これらの結合の順序の選択は、性能に劇的な影響を及ぼす。多くのＣＰＵサイクルを消費して、これらの結合を実行する最適な順序を発見するオプティマイザがある。残念ながら、評価される組み合わせの数が、結合されるテーブルの数と共に指数関数的に増加するので、ペアワイズ結合の最適な順序を選択する問題を、妥当な時間量において解決することはめったにできない。

しかも、組み合わせの数がしばしば大きすぎるので、オプティマイザはこの選択を、直接関係付けられるテーブルの作成に基づいて制限する。スター・スキーマでは、ファクト・テーブルが、大抵の他のテーブルに直接関係付けられた唯一のテーブルであり、これはファクト・テーブルが第１のペアワイズ結合のための当然の候補であることを意味する。残念ながら、ファクト・テーブルは照会においてまさに最大のテーブルであり、そのためこのストラテジは、非常に大きい中間結果セットを生成するペアワイズ結合順序を選択することにつながり、照会の性能に重大な影響を及ぼす。

通常はカルテシアン結合と呼ばれる最適化ストラテジがり、これはペアワイズ結合の問題の性能上の影響を、無関係なテーブルの結合を可能にすることによって軽減するものである。最大のテーブルであるファクト・テーブルへの結合は、まさに最後まで遅延され、よって中間結果セットのサイズが低減される。２つの無関係のテーブルの結合において、２つのテーブルの行のあらゆる組み合わせ、カルテシアン積が生成される。このようなカルテシアン積は照会の性能を向上させる。しかし、このストラテジは、選択された次元行のカルテシアン積がファクト・テーブルにおける行の数よりはるかに小さい場合にのみ実行可能である。カルテシアン結合の乗算型の性質により、最適化が、相対的に小規模のデータベースにのみ有用となる。

加えて、ハードウェアおよびソフトウェアの並列性を活用するシステムが開発されており、これは上述の性能上の問題点を軽減するものである。並列性は単一の照会の実行時間を短縮する（スピード・アップ）か、あるいは、実行時間を低下させることなく追加の作業を扱う（スケール・アップ）助けとなる可能性がある。たとえば、Ｒｅｄ Ｂｒｉｃｋ（商標）がＳＴＡＲｊｏｉｎ（商標）技術を開発しており、これは高速の並列化可能マルチテーブル結合を単一のパスにおいて提供し、したがって２つ以上のテーブルを単一のオペレーションで結合することができるものである。中心の技術は、多数の結合を加速させる索引付けへの革新的な手法である。残念ながら、並列性は、スター・スキーマに関係する性能劣化の問題点を低減することしかできず、取り除くことはできない。

多次元データベースのもっとも基本的な原理の１つは、集約の考えである。もっとも一般的な集約は、ロール・アップ集約と呼ばれる。このタイプは相対的に計算しやすく、これはたとえば、毎日の売上合計を取り、これらを月間販売テーブルにロール・アップすることである。もっとも困難なものは、分析的計算、ブール演算子および比較演算子の集約である。しかし、これらは集約のサブセットとしても見なされる。

スター・スキーマでは、集約の結果がサマリ・テーブルである。通常、サマリ・テーブルは、ユーザがリクエストするであろうデータ集約を予想し、次いでこのようなテーブルを事前構築しようと試みるデータベース管理者によって生成される。このようなシステムでは、集約オペレーションを含む、ユーザが生成した照会を処理するとき、照会に合致する事前構築された集約データがサマリ・テーブルから検索される（このようなデータが存在する場合）。図１８Ａおよび１８Ｂは、スター・スキーマおよびサマリ・テーブルを使用する多次元リレーショナル・データベースを例示する。この実施例では、サマリ・テーブルが、図１８Ｂに示すように、「月」、「四半期」および「年」の期間に渡って集約データを格納する「時間」次元上に生成される。サマリ・テーブルは本質において、より高いレベルの追加のファクト・テーブルである。これらが基本ファクト・テーブルに付加され、スター・スキーマのスノーフレーク拡張が作成される。サマリ・テーブルの中には階層があり、これは異なる管理レベルのユーザが異なる要約レベルを必要とするからである。集約レベルの選択は、「ドリル・ダウン」機能を介して実施される。

事前集約結果を含むサマリ・テーブルは通常、オンザフライ集約に関して改善された照会応答時間に備える。しかし、サマリ・テーブルはいくつかの欠点を有する。

・サマリ・テーブルで、データベース管理者が、ユーザが必要とするであろうデータ集約オペレーションを予想することが必要となる。これは大規模な多次元データベースでは（たとえば、データ・ウェアハウスおよびデータ・マイニング・システムでは）困難なタスクであり、ユーザは常に新しい情報およびパターンを求めて新しい方法で照会する必要がある。

・サマリ・テーブルは、サマリ・テーブルを構成する生データを閲覧するための効率的なドリル・ダウンを可能にするメカニズムを提供せず、通常は１つまたは複数の大きいテーブルのテーブル走査が必要とされる。

・照会が、事前集約が完了するまで遅延される。
・重大な時間のオーバーヘッドがあり、これは、生成された情報の非常に大部分が訪れられることなく残るからである。

・サマリ・テーブルを使用する前に同期化する必要がある。
・実行可能な並列性の度合いが制限され、これは、サマリ・テーブルの後続のレベルを、それらの階層によりパイプラインで実行しなければならないからである。

・非常に大規模なデータベースでは、このオプションは時間および記憶空間のために有効ではない。
事前集約結果およびオンザフライ集約を集約のサポートにおいて利用することが一般的であることに留意されたい。これらのシステムでは、ファクトの部分的な事前集約が結果として、小さいセットのサマリ・テーブルとなる。オンザフライ集約は、必要とされた集約データがサマリ・テーブルに存在しない場合に使用される。

集約データがサマリ・テーブルに存在しない場合、テーブル結合オペレーションおよび集約オペレーションが、このような集約データを生成するために、生ファクト上で実行されることに留意されたい。これは通常、オンザフライ集約と呼ばれる。このような場合では、集約索引付けが使用されて、生データの動的集約に関連付けられた多数のデータ結合の性能が弱められる。したがって、大規模な多次元データベースでは、このような動的集約が、受け入れ不可能な照会応答時間に通じる可能性がある。

ＲＤＢＭＳ内の結合および集約に関連付けられた問題に鑑みて、従来技術のＲＯＬＡＰシステムは、その下にあるＲＤＢＭＳの本質的に同じ短所および欠点を有している。

従来技術のＭＯＬＡＰシステムは、それらの下にあるＭＤＤ構造内で集約データに対する改善されたアクセス時間に備え、結合および集約オペレーションを実行するときに性能上の利点を有するが、従来技術のＭＯＬＡＰアーキテクチャは、いくつかの短所および欠点を有している。具体的には、アトミック（生）データが単一の転送でＭＯＬＡＰシステムに、集約、分析および照会のために移動される。重要なことに、集約結果はＤＢＭＳの外部にある。したがって、ＤＢＭＳのユーザは直接これらの結果を閲覧することができない。このような結果は、ＭＯＬＡＰシステムからしかアクセス可能でない。従来技術のＭＯＬＡＰシステムにおけるＭＤＤ照会処理ロジックはＤＢＭＳのロジックから分離しているので、ユーザはＭＯＬＡＰシステムへのアクセス権を獲得しなければならず、ＭＤＤ（またはＤＢＭＳ）にある条件下でアクセスするように命じられなければならない（かつこのような命令に従うように注意しなければならない）。このような要件はセキュリティ上の問題点を提示する可能性があり、これはシステム管理にとって非常に望ましくないものである。このような要件を満たすことは、コストを要し、かつロジスティック的にもわずらわしい処理である。結果として、ＭＯＬＡＰシステムの幅広い適用可能性が制限されている。

したがって、当技術分野では、データ要素をデータベース管理システム（たとえば、ＲＤＢＭＳ）内で結合かつ集約するため、かつ、改善されたデータベース管理システム（たとえば、ＲＤＢＭＳ）を情報データベース・システム（データ・ウェアハウスおよびＯＬＡＰドメインを含む）に統合すると同時に従来技術のシステムおよび方法の短所および欠点を回避するための、改善されたメカニズムについての大きな必要性がある。

発明の概要および目的
したがって、本発明のさらなる目的は、データ要素を多次元データベース（ＭＤＤＢ）内で、新しいスタンドアロン（すなわち、外部）のデータ集約サーバを使用して管理するための、改善された方法およびシステムを提供し、システム性能（たとえば、アクセス／探索時間の短縮）の著しい向上を、スタンドアロンのスケーラブルなデータ集約サーバを使用して達成することである。

本発明のもう１つの目的は、スタンドアロンの集約サーバが、ＭＤＤＢと共に統合される集約エンジンを含んで、カートリッジ・スタイルのプラグイン・アクセラレータを提供し、これが実質的にいかなる従来のＯＬＡＰサーバとも通信することができるシステムを提供することである。

本発明のもう１つの目的は、その計算的タスクがデータ集約に制限され、他のすべてのＯＬＡＰ機能をＭＯＬＡＰサーバに残し、したがってＯＬＡＰサーバの機能性を補足する、スタンドアロンのデータ集約サーバを提供することである。

本発明のもう１つの目的は、スタンドアロンの集約サーバが、改善されたデータ集約方法をＭＤＤＢ内で実行し、これによりＭＤＤＢの次元を多数にスケール・アップすることができ、かつ大きいアトミック（すなわち、ベース）データ・セットをＭＤＤＢ内でハンドリングすることができるシステムを提供することである。

本発明のもう１つの目的は、集約エンジンが高性能の集約（すなわち、データ・ロール・アップ）処理をサポートして、大量データの照会性能を最大限にし、かつ照会応答を劣化させる部分的集約の時間を短縮する、スタンドアロンの集約サーバを提供することである。

本発明のもう１つの目的は、その統合されたデータ集約（すなわち、ロール・アップ）エンジンが集約処理を数桁分スピード・アップさせ、集約時間を低下させることによってより大規模なデータベース分析を可能にする、スタンドアロンの外部のスケーラブルな集約サーバを提供することである。

本発明のもう１つの目的は、集約サーバのスケーラビリティにより（ｉ）その内部で実行された集約処理のスピードを、データ集約に関連付けられた計算集中的なタスクを多数のプロセッサの間で分散させることによって実質的に上げることができ、かつ（ｉｉ）集約サーバのＭＤＤＢ内に含まれタ大きいデータ・セットを多数のプロセッサの間で細分させることができ、したがってＭＤＤＢ内のアトミック（すなわち、ベース）データ・セットのサイズを実質的に増大させることができる、ＯＬＡＰオペレーションにおいて使用するための新しいスタンドアロンのスケーラブルな集約サーバを提供することである。

本発明のもう１つの目的は、高い効率および最適な性能のためのプロセッサの間の一様のロード・バランシング、およびプロセッサを追加することによって制限を拡張するためのリニア・スケーラビリティに備える、新しいスタンドアロンのスケーラブルな集約サーバを提供することである。

本発明のもう１つの目的は、ＭＯＬＡＰならびにＲＯＬＡＰシステム・アーキテクチャに適切である、スタンドアロンの外部のスケーラブルな集約サーバを提供することである。

本発明のもう１つの目的は、ＭＤＤＢおよび集約エンジンが統合され、集約エンジンが高性能の集約アルゴリズムおよび新しい格納および探索方法をＭＤＤＢ内で実行する、新しいスタンドアロンのスケーラブルな集約サーバを提供することである。

本発明のもう１つの目的は、シングル・プロセッサ（すなわち、順次または直列）コンピューティング・プラットフォーム、ならびにマルチ・プロセッサ（すなわち、並列）コンピューティング・プラットフォーム上でサポートすることができる、新しいスタンドアロンのスケーラブルな集約サーバを提供することである。

本発明のもう１つの目的は、既存のＭＯＬＡＰおよびＲＯＬＡＰデータベースへの相補的集約プラグインとして使用することができる、新しいスタンドアロンのスケーラブルな集約サーバを提供することである。

本発明のもう１つの目的は、新しいロール・アップ（すなわち、下から上への）および下方に広がる（すなわち、上から下への）集約アルゴリズムを実行する、新しいスタンドアロンのスケーラブルな集約サーバを提供することである。

本発明のもう１つの目的は、完全事前集約および／または「オンザフライ」集約処理をＭＤＤＢ内で実行する、統合されたＭＤＤＢおよび集約エンジンを含む、新しいスタンドアロンのスケーラブルな集約サーバを提供することである。

本発明のもう１つの目的は、多階層の次元を有するＭＤＤＢをサポートすることができる、新しいスタンドアロンのスケーラブルな集約サーバを提供することである。

本発明のもう１つの目的は、ＲＤＢＭＳデータ・ウェアハウスから生じるアトミック・データ・セットの多次元データを集約する、新しい方法を提供することである。

本発明のもう１つの目的は、外部ＡＳＣＩＩファイル、ＭＯＬＡＰサーバまたは他のエンド・ユーザ・アプリケーションなど、他のソースから生じるアトミック・データ・セットの多次元データを集約する、新しい方法を提供することである。

本発明のもう１つの目的は、いかなるＭＯＬＡＰサーバとも、標準のＯＤＢＣ、ＯＬＥ ＤＢまたはＤＬＬインターフェイスを介して、（クライアント）ユーザに関して完全に透過的な方法で、照会におけるいかなる時間遅延もなく、ＭＯＬＡＰサーバのキャッシュにおけるストレージに等しく通信することができる、新しいスタンドアロンのスケーラブルなデータ集約サーバを提供することである。

本発明のもう１つの目的は、ＭＯＬＡＰの境界を、銀行、保険、小売およびプロモーション分析を含む大規模アプリケーションに劇的に拡張する、新しい「カートリッジ・スタイル」（スタンドアロン）のスケーラブルなデータ集約エンジンを提供することである。

本発明のもう１つの目的は、たとえば、照会性能を最大限にするためのデータの事前計算など、変動性の高いタイプのＲＯＬＡＰアプリケーションの境界を劇的に拡張する、新しい「カートリッジ・スタイル」（スタンドアロン）のスケーラブルなデータ集約エンジンを提供することである。

本発明のもう１つの目的は、異なるベンダのすべてのＭＯＬＡＰシステムに適切な、汎用プラグイン・カートリッジ・タイプのデータ集約コンポーネントを提供し、それらの集約負荷を劇的に低減することである。

本発明のもう１つの目的は、標準化されたインターフェイスを有し、実質的にいかなるユーザまたはベンダのＯＬＡＰシステムにもプラグインすることができる、新しい高性能のカートリッジ・タイプのデータ集約サーバを提供することである。

本発明のもう１つの目的は、長いバッチ・タイプのデータ集約をインタラクティブなセッションに変換する能力を有する、新しい「カートリッジ・スタイル」（スタンドアロン）のスケーラブルなデータ集約エンジンを提供することである。

もう１つの態様では、本発明の目的は、非リレーショナルの多次元データ構造（ＭＤＤＢ）を使用して、データベース管理システム（ＤＢＭＳ）内で統合されたデータ要素を結合かつ集約するための改善された方法およびシステムを提供し、システム性能（たとえば、アクセス／探索時間の短縮）、ユーザの柔軟性および使いやすさにおいて著しい向上を達成することである。

本発明のもう１つの目的は、その統合されたデータ集約モジュールが高性能の集約（すなわち、データのロール・アップ）処理をサポートして大量データの照会性能を最大限にするＤＢＭＳを提供することである。

本発明のもう１つの目的は、その統合されたデータ集約（すなわち、ロール・アップ）モジュールが集約処理を数桁分スピード・アップさせ、集約時間を低下させることによってより大規模なデータベース分析を可能にする、ＤＢＭＳシステムを提供することである。

本発明のもう１つの目的は、ＯＬＡＰオペレーションにおいて使用するための新しいＤＢＭＳシステムを提供することである。
本発明のもう１つの目的は、新しいロール・アップ（すなわち、下から上への）および下方に広がる（すなわち、上から下への）の集約アルゴリズムを実行する、統合された集約モジュールを有する、新しいＤＢＭＳシステムを提供することである。

本発明のもう１つの目的は、完全事前集約および／または「オンザフライ」集約処理を実行する、統合された集約モジュールを有する、新しいＤＢＭＳシステムを提供することである。

本発明のもう１つの目的は、多階層の次元を有するＭＤＤＢをサポートすることができる、統合された集約モジュールを有する、新しいＤＢＭＳシステムを提供することである。

本発明のこれらおよび他の目的は、以下および本明細書で述べる特許請求の範囲において明らかになるであろう。
本発明の目的をより十分に理解するため、以下の例示的実施形態の詳細な説明を、添付の図面と共に読むべきである。

発明の好ましい実施形態の詳細な説明
次に図６Ａないし１３を参照して、本発明の方法およびシステムの好ましい実施形態を以下に詳細に記載し、図面において類似の要素は類似の参照番号によって指示されるものとする。

本発明の開示を通じて、「集約」および「事前集約」という語は、数値の合計の処理、ならびに、乗算、減算、除算など、他の数学的演算を意味するように理解されるものとする。

一般に、スタンドアロンの集約サーバ、および本発明のデータ集約のための方法および装置を幅広い範囲の応用例において使用することができ、これにはＭＯＬＡＰシステム、ＲＯＬＡＰシステム、インターネットＵＲＬディレクトリ・システム、パーソナライズされたオンラインｅコマース・ショッピング・システム、パケット経路指定および／または交換のリアルタイム制御を必要とするインターネットベースのシステムなどが含まれる。

例示のため、最初にＭＯＬＡＰシステムにおける改良に焦点を合わせる。このシステムでは、知識労働者が直観的、高速かつ柔軟的にＭＤＤＢ内のオペレーショナル・データを、よく知られているビジネス条件を使用して、分析的な洞察を関心のあるビジネス領域に提供するために、操作することが可能とされる。

図６Ａは、本発明の多次元オンライン分析処理（ＭＯＬＡＰ）システムの汎用化された実施形態を例示し、これはリレーショナル・データベースとして実現されたデータ・ウェアハウス、統合集約エンジンおよびＭＤＤＢを有する本発明のスタンドアロンのカートリッジ・スタイルの集約サーバ、および、集約サーバと通信し、かつ複数のＯＬＡＰクライアントをサポートするＯＬＡＰサーバを含む。本発明の原理によれば、スタンドアロンの集約サーバが集約機能（たとえば、数値の合計、ならびに乗算、減算、除算など、他の数学的演算）および多次元データ格納機能を実行する。

従来の実施から逸脱して、本発明の原理は、集約エンジンおよびＭＤＤＢを、標準化されたインターフェイスを有する分離した集約サーバに移動させ、これを実質的にいかなるユーザまたはベンダのＯＬＡＰサーバにもプラグインできるようにすることを教示する。この劇的な移動により、集約の制限依存性がＯＬＡＰの分析機能から、新しい独立したアルゴリズムを適用することによって中止される。スタンドアロンのデータ集約サーバにより、効率的なデータの編成およびハンドリング、高速集約処理、およびＭＤＤＢにおけるいかなるデータ要素の高速アクセスおよび検索も可能となる。

以下でより詳細に記載するように、本発明の集約サーバはＯＬＡＰシステム以外の他のタイプのシステムのデータ集約要件も処理することができ、これはたとえば、ＵＲＬディレクトリ管理データ・マート、ＲＤＢＭＳまたはＲＯＬＡＰシステムなどである。

本発明の集約サーバは２つの異なる機能の実行において他よりすぐれており、これはすなわち、ＭＤＤＢにおけるデータの集約、および、ＭＤＤＢにおいて結果として生じるデータベースを「オンデマンド」のクライアント使用のためにハンドリングすることである。ＯＬＡＰサーバを処理する場合、本発明の集約サーバは、これらの２つの機能を高性能の方法（すなわち、データ・ウェアハウスで生じたベース・データを、多次元ストレージ（ＭＤＤＢ）において集約および格納すること）で実行すること、および、このデータ集約処理の結果を「オンデマンド」で、ＯＬＡＰサーバ、表計算アプリケーション、エンド・ユーザ・アプリケーションなどのクライアントに提供することに焦点を置く。このように、本発明の集約サーバは、それがインターフェイスをとる従来の各ＯＬＡＰサーバを、データ集約を行う必要性から解放し、したがって、従来のＯＬＡＰサーバがＯＬＡＰサーバの主要機能、すなわちデータ分析およびユーザ・クライアントとのグラフィカル・インターフェイスのサポートに集中できるようにする。

図６Ｂは、例示的実施形態のスタンドアロンの集約サーバの主要コンポーネントを示し、これはすなわち、ＲＤＢＭＳフラット・ファイル・リストおよび他のファイルをデータ・ウェアハウス（ＲＤＢＭＳ）から受信するためのベース・データ・インターフェイス（たとえば、ＯＬＤＢ、ＯＬＥ−ＤＢ、ＯＤＢＣ、ＳＱＬ、ＪＤＢＣ、ＡＰＩなど）、ベース・データをベース・データ・インターフェイスから受信するためのベース・データ・ローダ、ベース・データ・インターフェイスおよびベース・データ・ローダのオペレーションを管理するための構成マネージャ、ベース・データをベース・ローダから受信するための集約エンジン、多次元データベース（ＭＤＤＢ）、ＭＤＤＢハンドラ、入力アナライザ、集約クライアント・インターフェイス（たとえば、ＯＬＤＢ、ＯＬＥ−ＤＢ、ＯＤＢＣ、ＳＱＬ、ＡＰＩ、ＪＤＢＣなど）、および、入力アナライザおよび集約クライアント・インターフェイスのオペレーションを管理するための構成マネージャである。

オペレーション中に、ベース・データがデータ・ウェアハウス、または、外部ＡＳＣＩＩファイル、ＭＯＬＡＰサーバまたは他のものなど、他のソースで生じる。構成マネージャは、すべての可能なソースおよびデータ構造との適切な通信を可能にするために、２つのブロックであるベース・データ・インターフェイスおよびデータ・ローダを構成する。これらの構成は、ＯＬＤＢ、ＯＬＥ−ＤＢ、ＯＤＢＣ、ＳＱＬ、ＡＰＩ、ＪＤＢＣなど、異なる規格に合致される。

図６Ｂに示すように、本発明のデータ集約サーバの中心は、データ集約エンジン、多次元データ・ハンドラ（ＭＤＤＢハンドラ）、および多次元データ・ストレージ（ＭＤＤＢ）から構成される。データ集約の結果は、ＭＤＤＢハンドラによってＭＤＤＢに効率的に記憶される。

図６Ａおよび６Ｂに示すように、本発明のスタンドアロン集約サーバは、ＯＬＤＢ、ＯＬＥ−ＤＢ、ＯＤＢＣ、ＳＱＬ、ＪＤＢＣおよびＡＰＩなどの標準インタフェース・プロトコルに好適に準拠する集約クライアント・インタフェースを介してＯＬＡＰサーバ（または他の要求しているコンピューティング・システム）の要求に応える。ＯＬＡＰが要求する集約結果はオンデマンドで供給される。通常、ＯＬＡＰサーバは構文解析法によって照会を一連の要求に分解する。ｎ次元の座標を指定するそのような要求のそれぞれが、集約サーバに対して提示される。構成マネージャは、クライアント・ユーザに従い、集約クライアント・インタフェースと入力アナライザとを適切な通信プロトコルにセットする。入力アナライザは、入力フォーマットがＭＤＤＢハンドラに対して適切になるように変換する。

本発明の目的は、データの転送を、ＭＯＬＡＰサーバのキャッシュに入っているデータの記憶方法と同じ方法で、しかも照会の遅延はまったくなしに、ＯＬＡＰユーザに対して完全に透過的にすることである。このためには、スタンドアロン集約サーバが抜群の高速応答性を有することが必要である。この目的は、本発明独自のデータ構造と集約機構とを提供することによって可能になる。

図６Ｃに、例示的実施形態のスタンドアロン集約サーバの集約エンジンとＭＤＤＢハンドラ構成要素とを備えるソフトウェア・モジュールを示す。ベース・データ・リストは、ＲＤＢＭＳまたはテキスト・ファイルから到着すると、図１１Ａおよび１１Ｂを参照しながら後述する本発明独自の方法に従って、階層処理を最適化するために解析と再順番付けとを行う必要がある。

集約管理モジュールの機能は、図９Ａおよび９Ｂに示す方法に従って集約処理を管理することである。
本発明の原理に従って、スタンドアロン集約サーバ内におけるデータ集約は、照会を開始する前にベース・データが完全に集約されている完全な事前集約処理として遂行することも、または、本発明の「実行中」データ集約処理を使用して集約のどの段階でも照会が可能になる照会有向ロールアップ（ＱＤＲ）処理として遂行することもできる。ＱＤＲ処理を、本明細書では図９Ｃを参照しながらより詳細に記述する。要求への応答（すなわち、クライアント照会の基本構成要素）は、「実行中」データ集約のため、またはストレージ管理モジュールを介した事前集約結果データへのアクセスのために集約管理モジュールを呼び出すことによって行われる。ＱＤＲ集約管理モジュール内の本発明の照会／要求サービング機構を、図６Ｄの流れ図に示す。

ストレージ管理モジュールの機能は、本明細書で図１０Ａおよび１０Ｂを参照して詳述する本発明の新しい方法によって、非常に効率的な方法で１つまたは複数のストレージのモジュールの多次元データを処理することである。

図６Ｄに示す要求サービング機構は、ＱＤＲ集約管理モジュールによって制御される。要求は待ち行列に入れられ、１つずつその要求が満たされる。要求されたデータが既に事前演算されている場合、それはストレージ管理モジュールによって取り出され、クライアントに戻される。そうでない場合、要求されたデータは集約管理モジュールによって「実行中」に演算され、その結果はクライアントに移動されるが、同時に図６Ｃに示すストレージ管理モジュールによって記憶される。

図７Ａおよび７Ｂに、本発明のスタンドアロン（カートリッジ・スタイル）集約サーバの２つの異なる実施態様を概説する。どちらの実施態様でも、集約サーバは集約した結果をクライアントに供給する。

図７Ａに、図６Ａに示す例示的実施形態のＭＯＬＡＰシステムの別プラットフォーム・タイプの実施態様を示すが、ここで、本発明の集約サーバは、ＯＬＡＰサーバを実行するために使用されるものとは別個のハードウェア・プラットフォームおよびＯＳシステムに常駐する。このタイプの実施態様では、様々なタイプのオペレーティング・システム（例えば、ＮＴ、Ｕｎｉｘ、ＭＡＣ ＯＳ）上で集約サーバとＯＬＡＰサーバとを実行することさえ可能である。

図７Ｂに、図６Ｂに示す例示的実施形態のＭＯＬＡＰシステムの共通プラットフォーム・タイプの実施態様を示すが、ここでは、本発明の集約サーバとＯＬＡＰサーバとは同じハードウェア・プラットフォームおよびオペレーティング・システム（ＯＳ）を共有する。

図８Ａに、本発明の原理に従って共有／共通ハードウェア・プラットフォームおよびＯＳ上で実施される集約エンジンのベンチマーク結果を記述する表を示す。この共通プラットフォームおよびＯＳは、Ｐｅｎｔｉｕｍ ＩＩ ４５０ＭＨｚ、１ＧＢ ＲＡＭ、１８ＧＢ Ｄｉｓｋを使用することによって実現され、Ｍｉｃｒｏｓｏｆｔ ＮＴオペレーティング・システムを実行する。この表に示す６個のデータ・セットは次元数、階層数、密度とデータ・サイズの測定単位が異なっている。一流のＯＬＡＰサーバであるＯＲＡＣＬＥ Ｅｘｐｒｅｓｓとの比較がなされる。本発明の集約エンジンは、現行の主要な集約技術と比べて一桁勝っていることが明らかである。

本発明のセグメント化されたデータ集約方法を図９Ａから９Ｃ２に示す。これらの図面は、三次元の簡略化された設定のみの概観を示すが、次に続く解析はこれと同様に何次元にでも適用する。

データは、同時に処理されるデータ量を最小限に抑えるために複数の自律セグメントに分割される。初期集約は単一次元上でのみ実行されるが、その後、この集約処理は他のすべての次元を必要とする。

集約方法の第１の段階で、集約は一次元に沿って実行される。第１の段階は、一次元以上で実行することができる。図９Ａに示すように、ベース・データの空間はこの集約処理によって拡張される。

図９Ｂに示す次の段階では、図示したスライスなどの、一次元に沿ったいかなるセグメントでも、残りの二次元、三次元に沿って別個に集約することができる。一般に、Ｎ次元システムの場合、第２の段階はＮ−一次元における集約を必要とする。

データのセグメント化の原理は、第１の段階にも同様に適用することができる。しかし、十分に大きなデータ・セットだけが、第１の次元におけるそのようにスライスされた手順を正当化する。実際に、各セグメントを、Ｎ−１キューブと想定することができ、それによって再帰的な計算が可能になる。

集約全体が完了する前に特定スライスの集約結果を得ること、あるいは、特定の順番でロールアップを完了させることが必要である。本発明の集約方法のこの新しい特徴は、通常の集約処理が達成される前でも照会を開始することを可能にしながら、高速応答を維持することである。さらに、部分的な集約のみを必要とするリレーショナルＯＬＡＰおよび他のシステムでは、ＱＤＲ処理は照会の応答を劇的に高速化する。

このＱＤＲ処理は、本発明のスライス指向ロールアップ方法によって実現可能になる。第１の１つまたは複数次元の集約後、多次元空間は独立した多次元キューブ（スライス）から構成される。このキューブは、任意の順番で処理することができる。

この結果、本発明の集約処理は、ファイル、共有メモリ・ソケット、またはロールアップの順番を静的または動的にセットする待ち行列の手段によって監視することができる。

要求された集約結果の準備が完了する前にクライアントから来た単一照会の要求に応えるために、本発明のＱＤＲ処理は、多次元データの薄いスライスのみを必要とする高速の実行中集約（ロールアップ）を必要とする。

図９Ｃ１は、第２の次元のロールアップ結果を構築するために必要とされるスライスを示す。図示するように、ケース１では、集約は、基本の、または第１の次元で既に集約されている既存データから開始される。このデータは、第２の次元に沿ってＱＤＲ集約の基礎として使用される。ケース２では、以前のデータがないので、ＱＤＲは、三次元に沿った初期スライス集約を必要とし、その後第２の次元に沿った集約を必要とする。

図９Ｃ２は、第３の次元の結果を得るための２つの対応するＱＤＲケースを示す。ケース１および２は、第２の次元で必要とされる初期集約の量が異なっている。

図１０Ａは、まばらなデータを記憶ディスク上に記憶する「スライス・ストレージ」方法を示す。一般に、このデータ記憶方法は、集約の方向に沿った昇順インデックスの原理に基づいており、データの高速取り出しを可能にする。図１０Ａは、多次元キューブのデータの１ユニット幅のスライスを示す。このデータはまばらなので、少量の非ＮＡデータ部分しか存在しない。これらの部分は次のように指し示される。データ・ファイルは、各ｎ−一次元スライスが別個のレコードに記憶されているデータ・レコードから構成される。これらのレコードは、非ＮＡの記憶されているポイントの量に従って様々な長さを有する。レコード内の各登録されているポイントごとに、ＩＮＤ_kはｎ次元のキューブ内のインデックスを意味し、また、Ｄａｔａはそのキューブの所与のポイントの値を意味する。

図１０Ｂは、本発明の集約サーバ内で単一の二分探索法を使用することができるように、ＭＤＤＢのストレージ内で使用されるデータ・ファイルとディレクトリ・ファイルとを構成する新しい技術を使用して図６ＢのＭＤＤＢ内の照会されたデータ・ポイントをランダムに探索する新しい方法を示す。この方法によれば、ＤＩＲファイルと称するメタファイルはデータ・ファイルへのポインタ、並びに、データ・レコードの開始アドレスおよび終了アドレス（ＩＮＤ₀、ＩＮＤ_n）、データ・ファイル内におけるその位置、レコードのサイズ（ｎ）、ディスク上のファイルの物理的アドレス（Ｄ＿Ｐａｔｈ）、およびそのレコードに関する補助情報（フラグ）などの追加パラメータを保存する。

照会されたデータ・ポイントの探索が、次いでＤＩＲファイルへのアクセスによって実行される。ファイルに沿った探索は、ファイルの昇順による単一二分探索法を使用して実行することができる。レコードが発見されると、そのレコードは、そのインデックスＩＮＤ_kによって特徴付けられる要求されたポイントを探索するために主メモリにロードされる。付属のＤａｔａフィールドは照会された値を表している。正確なインデックスが発見されない場合、それはポイントがＮＡであることを示している。

本発明の別の態様では、多階層構造において複数の階層を最適にマージするために新しい方法が提供される。図１１Ａ、１１Ｂおよび１１Ｃに示されるこの方法は、テーブル・データ（ベース・データ）がＲＤＢＭＳから到着したときに、このテーブル・データ（ベース・データ）を処理する際に本発明の集約サーバによって好適に使用される。

考案された方法によれば、加算および他の数式に対して効率よいデータ処理を達成するために、１つの次元内における階層の内部の順番が最適化される（一般に「集約」と称される）。階層の順番は外部的に定義される。これは、データ自体よりも前にデータの記述子としてデータ・ソースからスタンドアロン集約エンジンに移動される。例示の実施形態では、この方法は、図１１Ａに示すように、データの階層による相関関係を想定している。データ項目が、階層に関して、集約サーバのメモリ空間内で順番付けされる方法は、そのデータ処理の効率に大きな影響力を有している。

特に、従来技術の技法を使用するときは、いかにまばらなデータを効率よく処理するかが主要な関心事である場合、集約処理中にデータ要素が複数回アクセスされる際にデータ要素の複数の処理が行われることは避けられなかった。従来技術のデータ処理方法で使用されるデータ構造は、非ＮＡデータへの高速アクセスのために設計されてきた。従来技術の技法によれば、各アクセスは、データ構造におけるタイムリーな探索と取り出しに関連付けられる。ＯＬＡＰアプリケーションにおいてデータ・ウェアハウスから通常アクセスされる大量のデータに対して、データ要素のそのような複数の処理は、従来技術のデータ集約処理の効率を大幅に低下させてきた。従来技術のデータ処理技法を使用する場合、図１１Ａに示すデータ要素Ｄは３回アクセスされる必要があるが、これは低品質の集約性能をもたらす原因となる。

本発明のデータ処理方法によれば、従来技術の方法によって教示される複数処理とは対照的に、データは単一処理のために事前に順番付けされる。本発明によれば、ベース・データの要素とその集約結果は、各要素が１回だけアクセスされるような方法で隣接して記憶される。この特別な順番付けによって、後方処理のない、順方向限定処理が可能になる。ベース・データ要素が一旦記憶されるか、または集約結果が生成され記憶されると、それはさらなる集約のために再度取り出されることはない。この結果、ストレージへのアクセスは最小限に抑えられる。この単一処理方法は、大規模なデータベースの集約効率を大幅に高める。本発明で使用されるような効率的な処理方法を図７Ａに示す。データ要素Ｄは他のどのような要素とも同様に、１回だけアクセスされ、処理される。

図１１Ａに、３つの階層を有する多階層データベース構造の一例を示す。図で示すように、ベース・データは項目Ａ、Ｂ、ＦおよびＧを含む１つの次元を有する。第２のレベルは項目Ｃ、Ｅ、ＨおよびＩから構成される。第３のレベルは単一項目Ｄを有するが、この項目Ｄはすべての３つの階層構造に共通である。本発明の方法によれば、常に最小限の演算経路がとられる。例えば、本発明の方法によれば、項目Ｄは、４つの数値演算を必要とする構造３ではなく、２つの数値演算しか必要としない構造１の一部として演算される。図１１Ｂに、３つすべての階層からマージされた１つの最適化された構造を示す。

図１１Ｃ（ｉ）から１１Ｃ（ｉｘ）は、複数の階層を、複数の階層と機能上は同等である単一の階層に最適にマージする本発明の例示的階層変換機構の動作の流れ図による説明（および付属のデータ構造）を示す。説明のため、データ構造は、図１１（Ａ）および１１（Ｂ）に関して上記に説明した例示的階層構造に対応する。図１１Ｃ（ｉ）に示すように、ステップ１１０１では、カタログがＤＢＭＳシステムからロードされる。従来のように、このカタログには、ＤＢＭＳに記憶されている少なくとも１つの次元に関する複数の階層を記述するデータ（「階層記述子データ」）を含む。ステップ１１０３で、この階層記述子データがカタログから抽出される。階層記述子データによって記述される複数の階層内の項目全体に対してループ（ステップ１１０５〜１１１９）が実行される。

ループ１１０５〜１１１９では、複数の階層における所与の項目が選択され（ステップ１１０７）、ステップ１１０９では、所与の項目の１つまたは複数のペアレント（存在する場合は）が、グランドペアレント、グレート・グランドペアレントなどを含めて、識別され、図１１Ｃ（ｖ）に示すペアレント・リスト・データ構造のエントリ（所与の項目に対して）に追加される。ペアレント・リスト内の各エントリは特定あ項目に対応しており、その特定の項目のペアレント（またはグランドペアレント、またはグレート・グランドペアレント）である項目に対する０またはそれよりも大きな識別子を含む。さらに、階層記述子データによって記述された複数の階層の階層全体に対して内部ループ（ステップ１１１１〜１１１７）が実行されるが、ステップ１１１３では複数の階層が選択される。ステップ１１１５では、選択された階層の所与の項目のチャイルド（存在する場合は）が識別され、（必要のある場合は）図１１Ｃ（ｖｉ）に示すチャイルド・リスト・データ構造内のエントリ内の（所与の項目に対する）識別子の１グループに追加される。チャイルド・リスト内の各エントリは特定の項目に対応しており、それぞれが特定の項目の１つのチャイルドを識別する０またはそれよりも大きな識別子のグループを含む。各グループは、階層記述子データによって記述される１つまたは複数の階層に対応する。

この動作は、次いで図１１Ｃ（ｉｉ）に示されるステップ１１２１および１１３１に進み、階層記述子データによって記述された複数の階層の保全性を検証し（ステップ１１２１）、その中に１つでもエラーが発見された場合は修復される（またはユーザに報告される）（ステップ１１２３）。好適には、複数の階層の保全性はステップ１１２１において、グループ内に列挙された任意の項目の複数のチャイルド、複数のグランドチャイルド、等々を含むように、チャイルド・リストの識別子の各グループを反復的に拡張することによって検証される。特定の項目に対する各グループの（１つまたは複数の）チャイルドが一致しない場合、検証エラーが発生し、このようなエラーは修復される（またはユーザに報告される）（ステップ１１２３）。動作は、次いで、チャイルド・リスト内の項目全体に対するループ（ステップ１１２５〜１１３３）に進む。

ループ（ステップ１１２５〜１１３３）では、チャイルド・リスト内の所与の項目がステップ１１２７で識別される。ステップ１１２９では、所与の項目がチャイルドを有しないかどうか（例えば、対応するエントリがヌルかどうか）を判定するために、所与の項目に対するチャイルド・リスト内のエントリが検査される。チャイルドがある場合、動作はステップ１１３１に進み、図１１Ｃ（ｖｉｉ）に示す順番付けされたリストのデータ構造のレベル０内の項目に１つのエントリを追加する。チャイルドがない場合、動作は、そのループ内のチャイルド・リストの次の項目の処理に進む。順番リストの所与のレベル内の各エントリは特定の項目に対応し、特定の項目の１つのチャイルドをそれぞれが識別する０またはそれよりも大きな識別子を含む。変換された階層として記述される順番リストのレベルは、以下の点で容易に明らかになろう。基本的に、ループ１１２５〜１３３３は、変換された階層の最低レベル（レベル０）を構築する。

ループ１１２５〜１１３３の後、動作は、次に高いレベルを導くための最低レベルの処理に進み、変換された階層全体を構築するためにこの処理を反復する。より具体的には、ステップ１１３５で、最低レベルを識別するために「現在レベル」変数がセットされる。ステップ１１３７では、順番付けされたリストの「現在レベル」の項目が作業リストにコピーされる。ステップ１１３９では、その作業リストは空かどうかが判定される。空の場合、動作は終了し、空でない場合、動作はステップ１１４１に進み、そこで作業リスト内の項目全体に対してループ（ステップ１１４１〜１１５９）が実行される。

ステップ１１４３では、作業リストの所与の項目が識別され、動作は、所与の項目（所与の項目に対するペアレント・リスト・エントリで指定されている）の１つまたは複数のペアレント全体に対する内部ループ（ステップ１１４５〜１１５５）に進む。内部ループのステップ１１４７で、所与の項目の所与のペアレントが識別される。ステップ１１４９では、所与の項目の他のペアレントのどれか（例えば所与のパテントの他のペアレント）が（所与のペアレントに対するチャイルド・リスト・エントリで指定されるように）所与のペアレントのチャイルドであるかどうかが判定される。チャイルドであった場合、動作はステップ１１５５に進み、内部ループで所与の項目の次のペアレントを処理するが、チャイルドでなかった場合、動作はステップ１１５１および１１５３に進む。ステップ１１５１では、所与のペアレントに対するエントリが順番付けされたリストにまだ存在していない場合、それはそのリストの次のレベル（現在レベル＋１）に追加される。ステップ１１５３では、順番付けされたリストの次のレベルの所与のペアレントに対するエントリ内の１つまたは複数の項目のチャイルド（またはグランドチャイルド、またはグレート・グランドチャイルド）のどれにも所与の項目のチャイルド（順番付けされたリストの現在レベルの所与の項目に対するエントリで指定されるように）が一致しない場合、順番付けされたリストの次のレベルの所与のペアレントに対するエントリに所与の項目が追加される。上記の例の順番付けされたリストのレベル１および２を、それぞれ図１１Ｃ（ｖｉｉｉ）および１１Ｃ（ｉｘ）に示す。順番付けされたリストの次のレベルの所与のペアレントに対するエントリ内の項目の複数のチャイルド（グランドチャイルド、グレート・グランドチャイルド、等々を含めて）は、順番付けされたリストのより低いレベルで符号化された情報によって識別することができる。ステップ１１５３の後、動作はステップ１１５５に進み、内部ループ（ステップ１１４５〜１１５５）の所与の項目の次のペアレントを処理する。

内部ループ（ステップ１１４５〜１１５５）の処理の後、動作はステップ１１５７に進んで作業リストから所与の項目を削除し、処理はステップ１１５９に進んでループ（ステップ１１４１〜１１５９）の作業リストの次の項目を処理する。

ループ（ステップ１１４１〜１１５９）の処理の後、順番付けされたリスト（例えば変換された階層）は次に高いレベルに対して既に構築されている。動作はステップ１１６１に進んで現在レベルを次に高いレベルに増分し、動作はステップ１１３８に戻り（ステップ１１６３で）、最高レベルに達するまで（ステップ１１３９で判定される）、次に高いレベルを構築し、動作は終了する。

図１２は、上記階層変換技術を利用する１つの例示的集約モジュールの構成要素の概要を示す。より具体的には、この集約モジュールは、複数の階層を、機能上はその複数の階層と同等の単一の階層に最適にマージする階層変換モジュールを含む。第２のモジュールは、階層変換モジュールによって生成された最適な階層を使用して、ＤＢＭＳから供給されるベース・データをロードして指し示す。集約エンジンは、そのベース・データ上で集約操作を実行する。最適な階層によって指定された次元に沿った集約操作中、レベル０の項目の集約操作の結果はレベル１の項目の集約操作で使用することができ、レベル１の項目の集約操作の結果はレベル２の項目の集約操作で使用することができる、というような具合である。これらの操作によって、ベース・データをロードして指し示す動作は集約と共に非常に効率化され、メモリおよびストレージへのアクセスを最小限に抑え、記憶および取り出しの動作を高速化する。

図１３は、同様にＵＲＬディレクトリ・システム、データ・マート、ＲＤＢＭＳ、ＲＯＬＡＰシステムおよびＯＬＡＰシステムのデータ集約への要求に応じる中央データ・ウェアハウスの構成要素として、本発明のスタンドアロン集約サーバを示す。

中央多次元データベースを会社が必要とする理由は、中央多次元データベースが、複雑で相互に関連した大量のデータに対する柔軟かつ高性能なアクセスと解析とを容易にすることである。

同時に多くの異なる種類のクライアント（例えば、データ・マート、ＯＬＡＰ、ＵＲＬ、ＲＤＢＭＳ）の要求に応じるスタンドアロン専用集約サーバは、コスト効率のよい方法で企業規模の集約を実現する能力を有する。この種類のサーバは、クライアントのグループに対するロールアップの重複を解消して、スケーラビリティと柔軟性を実現する。

中央データ・ウェアハウスに関連する性能は、全体の手法において重要な考慮事項である。性能には、集約の時間と照会応答とが含まれる。
効率的な対話式照会アプリケーションは、秒単位で測定される略リアルタイムの動作を必要とする。これらのアプリケーションの性能は、直ちに、集約の要件と換言される。

従来技術では、ＭＯＬＡＰの場合、照会を開始する前に完全な事前集約を行う必要がある。本発明では、従来技術とは対照的に、照会有向ロールアップ（ＱＤＲ）は、バックグラウンドで完全な事前集約を実行しながら、瞬時の照会を可能にする。完全な事前集約が好ましいとされる場合には、本発明の集約はいかなる従来技術にも勝っている。ＲＯＬＡＰおよびＲＤＢＭＳクライアントの場合、部分的な集約は照会の性能を最大限にする。どちらの場合にも、高速な集約処理が不可欠である。本発明の集約性能は、従来技術の集約処理と比べて一桁勝っている。

本発明のスタンドアロン・スケーラブル集約サーバは、所定の次元階層に従って構成可能な異なるタイプまたはカテゴリの情報がある種のＲＤＢＭＳ内で収集され記憶される、特定市場、経済動向、消費者行動、気象条件、人口趨勢、またはいかなる物理的、社会的、生物学的またはその他の体系や現象の状態によって、企業業績に関する質問に回答するためのどのようなＭＯＬＡＰシステム環境でも使用することができる。選択された特定のアプリケーションとは関係なく、本発明のアドレス・データ・マッピング処理は、多岐にわたるアプリケーション環境で同じものを使用してＭＤＤＢを管理し、また意思決定支援の機能をも可能にする迅速で効率的な方法を実現する。

本発明のデータ集約サーバのスタンドアロン「カートリッジ・スタイル」プラグインの機能は、集約のための最適化された多次元データ構造と処理方法とを設計する際に自由を提供し、すべてのＯＬＡＰベンダに適合する汎用集約サーバを設計する際に自由を提供し、また、企業規模の集中型の集約を可能にする。

本発明の集約サーバで使用されるセグメント化された集約の方法は、柔軟性と、照会有向集約に関する条件であるスケーラビリティと、高速化とを実現する。
本発明の集約サーバで使用される多次元データ構成および指示の方法は、セグメント化された集約に関する条件である高速の記憶および取り出しを実現し、高速な方法によるデータの記憶、処理、取り出しを向上させ、スライスされた集約とＱＤＲを可能にする構造上の柔軟性に貢献する。この方法は、さらに、速度性能を改善しながら、データの転送と単一処理とを可能にする。

本発明の集約サーバで使用される照会有向集約（ＱＤＲ）の方法は、多階層データ構造によるデータ処理操作を最小限に抑える。
本発明の集約サーバで使用される照会有向集約（ＱＤＲ）の方法は、完了されるべき完全な集約を待機する必要性を解消し、完全な集約に要求される増強された集約データを提供する。

本発明の別の態様では、２つの異なる機能、すなわち、データの集約と「オンデマンド」のクライアントの使用のための結果データの処理とを実行する上で秀でた、改善されたＤＢＭＳシステム（例えばＲＤＢＭＳシステム、オブジェクト指向データベース・システム、またはオブジェクト／リレーショナル・データベース・システム）が提供される。さらに、改善されたデータ集約機能があるという理由から、本発明のＤＢＭＳは、ＯＬＡＰシステムなどをサポートするデータ・ウェアハウスを含めて広範なアプリケーションにおいて使用することができる。説明のために、最初の焦点は、本発明のＤＢＭＳに合わせることにする。次に図１９から２１を参照して、本発明の方法およびシステムの好ましい実施形態を以下で詳述する。

本明細書を通して、「集約」および「事前集約」という用語は、数値の加算処理、並びに乗算、減算、除算など、その他の数値演算を意味するものと理解されたい。事前集約演算は従来の照会処理操作に関して非同期的に行われるということを理解されたい。さらに、「アトミック・データ」という用語は、効率的な意思決定に要する最低レベルのデータ粒度を意味するものと理解されたい。小売商の経営者の場合、アトミック・データは、店舗ごと、日ごと、および品目ごとの情報を意味する場合がある。銀行業者の場合、アトミック・データは、口座ごと、取引ごと、および支店ごとの情報である場合がある。

図１９Ａは、本発明のＤＢＭＳの例示的実施形態の主要な構成要素、すなわち、照会インタフェースおよび照会ハンドラを含む支援機構、少なくともアトミック・データを記憶している１つまたは複数のテーブル（および可能ならばサマリ・テーブル）および辞書を記憶するためのメタデータ・ストア（カタログまたはディレクトリと称される場合もある）を含むリレーショナル・データ・ストア、およびＭＤＤＢにアトミック・データおよび集約されたデータを記憶するＭＤＤ集約モジュールを示す。ＭＤＤＢは、データを記憶するための非リレーショナル・データ構造である。これは、テーブルの代わりに、またはテーブルに加えて他のデータ構造を使用する。説明のため、図１９Ａに、リレーショナル・データ・ストアがファクト・テーブルと辞書とを含むＲＤＢＭＳを示す。

ＤＢＭＳは、通常、本発明とは関係しない追加の構成要素（図示せず）を含むことに留意されたい。照会インタフェースおよび照会ハンドラは、例えば図面のネットワークを介してクライアント・マシンから転送された、ユーザの提出した照会（好ましい実施形態では、ＳＱＬ照会ステートメント）の要求に応える。照会ハンドラとリレーショナル・データ・ストア（テーブルおよびメタデータ・ストア）はＭＤＤ集約モジュールに動作可能に結合されている。重要なことは、照会ハンドラと統合ＭＤＤ集約モジュールが、データ集約演算とドリルダウンのための照会応答時間を劇的に向上させるように動作することである。さらに、集約またはドリルダウン演算を必要とする照会に関連する遅延を最小限に抑えるような方法で、非リレーショナルＭＤＤＢのユーザの照会を、ＤＢＭＳのリレーショナル・テーブルの照会と何ら異ならないようにするということが、本発明の目的である。この目的は、本発明のＤＢＭＳシステムと、統合集約機構を提供することによって可能になる。

図１９Ｂは、図１９ＡのＭＤＤ集約モジュールの例示的実施形態の主要な構成要素、すなわち、ＤＢＭＳのリレーショナル・データ・ストアのディレクトリおよび１つまたは複数のテーブルをロードするためのベース・データ・ローダ、ベース・ローダから次元データとアトミック・データとを受け取るための集約エンジン、多次元データベース（ＭＤＤＢ）、ユーザにＭＤＤ集約モジュールへの照会アクセスを提供するためにＤＢＭＳの照会ハンドラと共同で動作するＭＤＤＢハンドラおよびＳＱＬハンドラ、およびＭＤＤ集約モジュールの構成要素の動作を管理する制御モジュールを示す。ベース・データ・ローダは、標準インタフェース（ＯＬＤＢ、ＯＬＥ−ＤＢ、ＯＤＢＣ、ＳＱＬ、ＡＰＩ、ＪＤＢＣなど）を介してリレーショナル・データ・ストアのディレクトリおよび１つまたは複数のテーブルをロードすることができる。この場合、ＤＢＭＳおよびベース・データ・ローダは、これらの標準インタフェースを介するそのようなデータの伝達を実現する構成要素を含む。このようなインタフェースは当技術分野では周知である。例えば、このようなインタフェース構成要素は、Ａｔｔｕｎｉｔｙ Ｃｏｒｐｏｒａｔｉｏｎ、ｈｔｔｐ：／／ｗｗｗ．ａｔｔｕｎｉｔｙ．ｃｏｍ．から容易に入手可能である。

動作中、ベース・データは、ＤＢＭＳの１つまたは複数のテーブルから作り出される。コア・データ集約演算は、集約エンジン、多次元データ（ＭＤＤＢ）ハンドラ、および多次元データ・ストレージ（ＭＤＤＢ）によって実行される。データ集約の結果は、ＭＤＤＢハンドラによってＭＤＤＢに効率的に記憶される。ＭＤＤ集約モジュールのＳＱＬハンドラは、ＤＢＭＳの照会ハンドラから転送された、ユーザの提出した照会（好ましい実施形態ではＳＱＬ照会ステートメント）の要求に応える。ＭＤＤ集約モジュールのＳＱＬハンドラは、標準インタフェース（ＯＬＤＢ、ＯＬＥ−ＤＢ、ＯＤＢＣ、ＳＱＬ、ＡＰＩ、ＪＤＢＣなど）を介してＤＢＭＳの照会ハンドラと通信することができる。この場合、ＲＤＢＭＳおよびＳＱＬハンドラの支援機構は、それらの標準インタフェースを介してそのようなデータの伝達を実現する構成要素を含む。このようなインタフェース構成要素は当技術分野では周知である。集約（またはドリルダウンの結果）はオンデマンドで取り出され、ユーザに戻される。

通常、ユーザは自然言語照会を生成するためにクライアント・マシンと（例えばウェブ使用可能なブラウザを使用して）対話し、この自然言語照会は、例えば図面のネットワークを介してＤＢＭＳの照会インタフェースに伝達される。照会インタフェースは、構文解析によって、照会を、ＤＢＭＳの照会ハンドラに伝達される一連の要求（好ましい実施形態ではＳＱＬステートメント）に分解する。照会インタフェースの機能は、ＤＢＭＳの一部ではない（例えばクライアント・マシン内の）モジュールで実施することができる。ＤＢＭＳの照会ハンドラは、ＭＤＤ集約モジュール内のＭＤＤに記憶されているデータを必要とする要求を、その要求に応えるために、ＭＤＤ集約モジュールのＳＱＬハンドラに転送する。各要求は、一組のｎ次元を指定する。ＭＤＤ集約モジュールのＳＱＬハンドラはこの一組の次元を抽出し、この一組の次元を使用してＭＤＤＢをアドレス指定するためにＭＤＤハンドラと共同して動作し、アドレス指定されたデータをＭＤＤＢから取り出し、ＤＢＭＳを介してその結果をユーザに戻す。

図１９Ｃ（ｉ）および１９Ｃ（ｉｉ）は、本発明の例示的ＤＢＭＳの動作を示す流れ図である。ステップ６０１では、ＭＤＤ集約モジュールのベース・データ・ローダは、ＤＢＭＳのメタデータ・ストアから辞書（またはカタログ）をロードする。この機能を実行する際、ベース・データ・ローダは、ＤＢＭＳの辞書のデータ・タイプ（またはＤＢＭＳの辞書を表すために使用される標準データ・タイプ）を、ＭＤＤ集約モジュールで使用されるデータ・タイプにマッピングするアダプタ（インタフェース）を利用することができる。さらに、ベース・データ・ローダは辞書から次元を抽出し、その次元をＭＤＤ集約モジュールの集約エンジンに転送する。

ステップ６０３では、ベース・データ・ローダはＤＢＭＳから１つまたは複数のテーブルをロードする。この機能を実行する際、ベース・データ・ローダは、ＤＢＭＳの１つまたは複数のテーブルのデータ・タイプ（またはＤＢＭＳの１つまたは複数のファクト・テーブルを表すために使用される標準データ・タイプ）を、ＭＤＤ集約モジュールで使用されるデータ・タイプにマッピングするアダプタ（インタフェース）を利用することができる。さらに、ベース・データ・ローダはその１つまたは複数のテーブルからアトミック・データを抽出し、そのアトミック・データを集約エンジンに転送する。

ステップ６０５では、集約エンジンは、（ステップ６０１でＤＢＭＳの辞書から抽出された）少なくとも１つの次元に沿って、（ステップ６０３でベース・データ・ローダによって提供された）アトミック・データ上で集約演算（すなわち、ロールアップ演算）を実行し、その結果である集約されたデータをＭＤＤＢに記憶するためにＭＤＤハンドラと共同で動作する。本発明の好ましい実施形態による例示的集約演算のより詳細な記述を、図９Ａ〜９ＣのＱＤＲ処理に関して後述する。

ステップ６０７では、ＭＤＤ集約モジュールによって生成され、かつ／またはＭＤＤ集約モジュールのＭＤＤＢに記憶されていているデータを、ユーザが照会することができるようにするリファレンスが定義される。このリファレンスは、Ｃｒｅａｔｅ Ｖｉｅｗ ＳＱＬステートメントを使用して好適に定義されるが、これによってユーザは、ｉ）ＭＤＤ集約モジュールに記憶されているＭＤＤＢに関連するテーブル名（ＴＮ）を定義し、ｉｉ）テーブルＴＮ上のＳＱＬステートメントをＭＤＤ集約モジュールにルーティングするために使用されるリンクを定義できるようになる。この実施形態では、ＤＢＭＳのビュー機構は、図６（Ｅ）に示すようにＭＤＤ集約エンジンのＭＤＤＢに記憶されているデータに対する参照とリンク付けとを可能にする。ビュー機構およびＣｒｅａｔｅ Ｖｉｅｗ ＳＱＬステートメントのより詳細な説明は、参照によりその全体を本明細書に組み込んだ、Ｃ．Ｊ．Ｄａｔｅ著、「Ａｎ Ｉｎｔｒｏｄｕｃｔｉｏｎ ｔｏ Ｄａｔａｂａｓｅ Ｓｙｓｔｅｍｓ」、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ、第７版、２０００年、２８９頁〜３２６頁に記載されている。したがって、このビュー機構は、ＤＢＭＳシステムの照会ハンドラが、テーブルＴＮ上の任意のＳＱＬ照会を、関連するリンクを介してＭＤＤ集約モジュールに転送することを可能にする。代替実施形態では、図６Ｆに示すような、ＭＤＤ集約モジュールによって生成され、かつ／またはＭＤＤ集約エンジンのＭＤＤＢに記憶されているデータを、ＤＢＭＳシステムが参照し、リンク付けすることができるようにするためにダイレクト機構（例えばＮＡトリガ機構）を使用することができる。トリガ機構および方法のより詳細な説明は、参照によりその全体を本明細書に組み込んだ、Ｃ．Ｊ．Ｄａｔｅ著、「Ａｎ Ｉｎｔｒｏｄｕｃｔｉｏｎ ｔｏ Ｄａｔａｂａｓｅ Ｓｙｓｔｅｍｓ」、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ、第７版、２０００年、２５０頁〜２６６頁に記載されている。

ステップ６０９では、ユーザは照会を生成するためにクライアント・マシンと対話し、その照会は照会インタフェースに伝達される。照会インタフェースは１つまたは複数のＳＱＬステートメントを生成する。これらのＳＱＬステートメントは、リレーショナル・データストアのテーブルに記憶されているデータを参照する場合があるが、ステップ６０７で定義されたリファレンスを参照する場合もある（このリファレンスは、ＭＤＤ集約モジュールのＭＤＤＢに記憶されたデータを参照する）。これらの１つまたは複数のＳＱＬステートメントはＤＢＭＳの照会ハンドラに転送される。

ステップ６１１では、照会ハンドラは１つまたは複数のＳＱＬステートメントを受け取り、その１つまたは複数のＳＱＬステートメントをより効率的な照会ハンドリングに対して最適化するために任意選択でそれを変換する。このような変換は当技術分野では周知である。例えば、Ｋｉｍｂａｌｌ著、「Ａｇｇｒｅｇａｔｉｏｎ Ｎａｖｉｇａｔｉｏｎ Ｗｉｔｈ （Ａｌｍｏｓｔ） Ｎｏ ＭｅｔａＤａｔａ」、ＤＢＭＳ Ｄａｔａ Ｗａｒｅｈｏｕｓｅ補遺、１９９６年８月、ｈｔｔｐ：／／ｗｗｗ．ｄｂｍｓｍａｇ．ｃｏｍ／９６０８ｄ５４．ｈｔｍｌ．から入手可能、を参照されたい。

ステップ６１３では、照会ハンドラは、受け取った１つまたは複数のＳＱＬステートメント（または１つまたは複数の変換されたＳＱＬステートメント）がステップ６０７で生成されたリファレンス上にあるかどうかを判定する。リファレンス上にある場合、演算はステップ６１５に進むが、ない場合はステップ６２５で通常の照会ハンドリング演算が続行する。ここで、リレーショナル・データストアは、その中に記憶されているデータを抽出し、記憶し、かつ／または操作するために照会によってアクセスされ、必要に応じて、結果がクライアント・マシンを介してユーザに戻される。

ステップ６１５では、受け取った１つまたは複数のＳＱＬステートメント（または１つまたは複数の変換されたＳＱＬステートメント）が、ステップ６０７に関して上述した参照のためのリンクを使用して、ステップ６１７で処理するためのＭＤＤ集約エンジンにルーティングされる。

ステップ６１７では、１つまたは複数のＳＱＬステートメントがＭＤＤ集約モジュールのＳＱＬハンドラによって受け取られるが、ここで、一組の１つまたは複数のＮ次元座標がそのＳＱＬステートメントから抽出される。この機能を実行する際、ＳＱＬハンドラは、ＤＢＭＳの照会ハンドラによって発行されるＳＱＬステートメントのデータ・タイプ（またはＤＢＭＳの照会ハンドラによって発行されるＳＱＬステートメントを表すために使用される標準データ・タイプ）を、ＭＤＤ集約モジュールで使用されるデータ・タイプにマッピングするアダプタ（インタフェース）を利用することができる。

ステップ６１９では、ＭＤＤＢをアドレス指定して、ＭＤＤＢから対応するデータを取り出すために、ステップ６１７で抽出された一組のＮ次元座標がＭＤＤハンドラによって使用される。

最後に、ステップ６２１では、取り出されたデータがＤＢＭＳを介してユーザに戻され（例えば、取り出されたデータをＳＱＬハンドラに転送し、ＳＱＬハンドラは取り出されたデータをＤＢＭＳシステムの照会ハンドラに戻し、照会ハンドラはユーザの提出した照会の結果をクライアント・マシンを介してユーザに戻す）、動作は終了する。

テーブル・データ（ベース・データ）は、ＤＢＭＳから到着すると、図１１Ａ、１１Ｂおよび１１Ｃを参照して上述したように、本発明独自の方法によって階層ハンドリングを最適化するために、解析され、再順番付けすることができる。

さらに、ＭＤＤ集約モジュールのＭＤＤ制御モジュールは、図９Ａおよび９Ｂに示す方法に従って集約処理を好適に管理する。したがって、本発明の原理に従って、ＤＢＭＳ内のデータ集約は、照会を開始する前にベース・データが完全に集約される完全な事前集約処理として、または、本発明の「実行中」データ集約処理を使用して集約のどの段階でも照会が可能となる照会有向ロールアップ（ＱＤＲ）処理として遂行することができる。ＱＤＲ処理は、本明細書では図９Ｃを参照しながらより詳細に説明する。「実行中」データ集約を必要とするかまたはＭＤＤハンドラを介して事前集約された結果データへのアクセスを必要とする要求への応答（すなわち、クライアント照会の基本構成要素）は、ＭＤＤ制御モジュール内の本発明の照会／要求サービング機構によって提供されるが、この主要な動作は、図６Ｄの流れ図に示されている。ＭＤＤハンドラの機能は、本発明の新しい方法に従って非常に効率的な方式で１つまたは複数のストレージのモジュールの多次元データを処理することであるが、これは本明細書では図１０Ａおよび１０Ｂを参照して詳述する。

図６Ｄに示すＳＱＬハンドリング機構はＭＤＤ制御モジュールによって制御されている。要求は待ち行列に入れられ、１つずつその要求が満たされる。要求されたデータが既に事前演算されている場合、それはＭＤＤハンドラによって取り出され、クライアントに戻される。事前演算されていない場合、要求されたデータは集約エンジンによって「実行中」に演算され、その結果はクライアントに移動されるが、同時に図６Ｃに示すＭＤＤハンドラによって記憶される。

図１９Ｇに示すように、本発明のＤＢＭＳは、上述のように、リレーショナル部分と非リレーショナル部分とに論理的に分割することができる。リレーショナル部分には、リレーショナル・データストア（例えば、１つまたは複数のテーブルおよび辞書）および支援機構（例えば、照会ハンドリング・サービス）が含まれる。非リレーショナル部分にはＭＤＤ集約モジュールが含まれる。上述のように、図面のようなリレーショナル部分と非リレーショナル部分との間には双方向データ・フローが発生する。より具体的には、データのロード動作中、データはリレーショナル部分（すなわち、リレーショナル・データ・ストア）から非リレーショナル部分にロードされ、そこでデータは集約されてＭＤＤＢに記憶される。照会サービス動作中、所与の照会がＭＤＤＢに記憶されているデータを参照する場合、その照会に関係するデータは非リレーショナル部分によって生成され（例えば、生成され、かつ／またはＭＤＤＢから取り出され）、ユーザに伝達して戻すためにリレーショナル部分（例えば、照会サービス機構）に供給される。このような双方向データ・フローは、従来技術に対して重要な際だった特徴を表す。例えば、図１Ｂに示される従来技術のＭＯＬＡＰアーキテクチャでは、データのロード動作中にリレーショナル・データベース（例えば、データ・ウェアハウスＲＤＢＭＳシステム）からＭＤＤＢに単一方向のデータ・フローが発生する。

図２０Ａおよび２０Ｂは、本発明のＤＢＭＳの２つの異なる実施態様の概要を示す。どちらの実施態様でも、ＤＢＭＳシステムの照会ハンドラはＭＤＤから取り出された集約結果をクライアントに供給する。

図２０Ａは、図１９Ａに示す例示的実施形態のＤＢＭＳシステムの別プラットフォーム型の実施態様を示すが、ここで、ＤＢＭＳのリレーショナル部分は別個のハードウェア・プラットフォームおよび／またはＯＳシステム上に常駐し、そこから非リレーショナル部分（ＭＤＤ集約モジュール）を実行するために使用される。このタイプの実施態様では、ＤＢＭＳシステムの一部とＭＤＤ集約モジュールの一部とを異なるタイプのオペレーティング・システム（例えばＮＴ、ＵｎｉＸ、ＭＡＣ ＯＳ）上で実行することも可能である。

図２０Ｂは、図２０Ａに示す例示的実施形態のＤＢＭＳシステムの共通プラットフォームの実施態様を示すが、ここで、ＤＢＭＳのリレーショナル部分は、非リレーショナル部分（ＭＤＤ集約モジュール）を実行するために使用される同じハードウェア・プラットフォームとオペレーティング・システム（ＯＳ）とを共有する。

図２１は、本発明の改善されたＤＢＭＳ（例えばＲＤＢＭＳ）を、ＲＯＬＡＰシステム（または他のＯＬＡＰシステム）のデータの記憶と集約の要求に応えるデータ・ウェアハウスの一構成要素として示す。重要なことは、本発明の改善されたＤＢＭＳは、複雑かつ相互に関連した大量のデータに対する柔軟で高性能のアクセスと解析を提供することである。さらに、本発明の改善されたデータ・ウェアハウスＤＢＭＳは、多くの様々な種類のクライアント（例えば、データ・マート、ＯＬＡＰ、ＵＲＬ）の要求に同時に応えることができ、コスト効率のよい方法で企業規模のデータの記憶と集約とを実現する能力を有する。この種類のシステムは、クライアントのグループに対する重複を解消して、スケーラビリティと柔軟性とを実現する。さらに、本発明の改善されたＤＢＭＳは、スプレッドシート・モデリング・プログラムなどのデータ解析プログラムを含めて、上述のどのような情報データベース・システムのデータ・ストア構成要素としても使用することができ、そのようなシステムのデータの記憶と集約の要求に応える。

図２２は、本発明の一実施形態を示すが、ここで、本発明のＤＢＭＳ（例えばＲＤＢＭＳ）はデータ・ウェアハウスの一構成要素、すなわちＯＬＡＰシステムである。このＤＢＭＳは従来のデータ・ウェアハウスとして動作し、企業のデータの記憶と集約との要求に応える。さらに、ＤＢＭＳには、ＤＢＭＳシステムの照会ハンドリングと共同して動作する統合ＯＬＡＰ解析論理（および好適には、図示しないが統合プレゼンテーション・モジュール）と、ＤＢＭＳシステムのユーザに対して多次元リポート（例えば、比率、ランク、変換、動的連結、複合フィルタリング、予測、照会管理、スケジューリング、フロー制御、事前集約推論、非正規化サポート、および／またはテーブルの分割および結合）を実行することを可能にし、従来のＯＬＡＰ解析（グリッド、グラフ、マップ、アラート、ドリルダウン、データ・ピボット、データ・サーフ、スライスおよびダイス、印刷）を好適に実行するＭＤＤ集約モジュールが含まれる。重要なことは、本発明の改善されたＤＢＭＳは複雑かつ相互に関連した大量のデータに対する柔軟で高性能のアクセスと解析とを提供する。さらに、本発明の改善されたＤＢＭＳは、多くの様々な種類のクライアント（例えば、データ・マート、他のＯＬＡＰシステム、ＵＲＬディレクトリ・システム）の要求に同時に応えることができ、コスト効率のよい方法で企業規模のデータの記憶および集約を実現する能力を有する。この種類のシステムは、クライアントのグループに対する重複を解消して、スケーラビリティと柔軟性とを実現する。さらに、本発明の改善されたＤＢＭＳは、上述のどのような情報データベース・システムのデータ・ストア構成要素としても使用することができ、そのようなシステムのデータの記憶および集約の要求に応える。

本発明の改善されたＤＢＭＳによって得られる機能上の利点
本発明のＤＢＭＳの特徴は、集約を必要とするＤＢＭＳに発行された照会を処理する際の応答時間を劇的に改善し、したがって企業規模の集中型の集約を可能にする。さらに、本発明の好ましい実施形態では、ユーザは、ＤＢＭＳ上における従来の照会と何ら異なることのない方法で、集約されたデータを照会することができる。

本発明の新しいＤＢＭＳによって使用されるセグメント化された集約の方法は、柔軟性、スケーラビリティ、照会有向集約の機能、および高速化を実現する。
さらに、本発明の新しいＤＢＭＳによって使用される照会有向集約（ＱＤＲ）の方法は、多階層データ構造におけるデータ・ハンドリング動作を最小限に抑え、完全な集約が完了するまで待機する必要性を解消し、完全な集約に必要とされる集約されたデータの構築を提供する。

本明細書の上記で説明した例示的実施形態のシステムおよび方法は、本明細書で開示された新しい教示の恩恵にあずかる当業者に容易に明らかになる様々な方法によって修正することができることを理解されたい。その例示的実施形態のこのようなすべての修正形態および変形形態は、頭記の特許請求の範囲で定義される本発明の範囲および趣旨の範囲内にあるものとみなされる。

図１Ａは、３層またはレイヤのクライアント／サーバ・アーキテクチャを含む、例示的な従来技術のリレーショナル・オンライン分析処理（ＲＯＬＡＰ）システムの概略図であり、第１の層が、データ格納、アクセスおよび検索処理のためにＲＤＢＭＳを利用するデータベース・レイヤ、第２の層が、多数のユーザからの多次元レポートを実行するためのアプリケーション・ロジック・レイヤ（すなわち、ＲＯＬＡＰエンジン）を有し、第３の層が、ＲＯＬＡＰエンジンを様々なプレゼンテーション・レイヤと統合し、それを通じてユーザがＯＬＡＰ分析を実行する図である。図１Ｂは、従来技術の多次元オンライン分析処理（ＭＯＬＡＰ）システムの、汎用化された実施形態の概略図であり、アトミック（すなわち、ベース）データを、ＲＤＢＭＳによって実現されたデータ・ウェアハウスから受信するためのベース・データ・ローダ、ＯＬＡＰ多次元データベース（ＭＤＤＢ）、集約、アクセスおよび検索モジュール、アプリケーション・ロジック・モジュール、および、オンライン・トランザクション処理（ＯＬＴＰ）オペレーションをＭＤＤＢ上でサポートして、通常はシステムに情報ネットワーク（たとえば、インターネット）からアクセスする複数のＯＬＡＰクライアント・マシンからのデータベース照会およびリクエストにサービスするための、従来のＯＬＡＰサーバ（たとえば、ＯｒａｃｌｅのＥｘｐｒｅｓｓ Ｓｅｒｖｅｒ）に関連付けられたプレゼンテーション・モジュールを含む図である。 図２Ａは、図１Ｂの従来技術のシステムにおいて示した、多数のデータ・テーブル（たとえば、Ｔ１、Ｔ２、．．．．．．．．．．Ｔｎ）およびデータ・フィールド・リンクを含むデータ・ウェアハウス、および、図１Ｂにおいて示した、情報記憶装置における変数の物理記憶域をポイントするポインタを有する従来のページ・アロケーション・テーブル（ＰＡＴ）を含む、ＯＬＡＰ多次元データベースの概略図である。図２Ｂは、三次元カルテシアン・キューブとして編成され、かつ図２Ａの従来技術のシステムにおいて使用される、例示的三次元ＭＤＤＢの概略図であり、ＭＤＤＢの第１の次元が地理（たとえば、市、州、国、大陸）を表し、ＭＤＤＢの第２の次元が時間（たとえば、日、週、月、年）を表し、ＭＤＤＢの第３の次元が製品（たとえば、メーカ毎のすべての製品）を表し、基本データ要素が三次元座標値によってアドレス指定される変数のセットである図である。図２Ｃは、次元階層に従って配列された、例示的三次元ＭＤＤＢに関連付けられた従来技術のアレイ構造の概略図である。図２Ｄは、データ要素アドレスのページに従って配列された、例示的三次元ＭＤＤＢのための従来技術のページ・アロケーション・テーブルの概略図である。 図３Ａは、従来技術のＭＯＬＡＰシステムの概略図であり、生データをそのＲＤＢＭＳデータ・ウェアハウスに定期的に格納し、基本データをデータ・ウェアハウスからＭＤＤＢに直列にロードする処理、および、ＭＤＤＢにおけるデータを直列に、その次元階層全体に沿って事前集約（または事前コンパイル）する処理を例示する図である。図３Ｂは、従来技術のページ・アロケーション・テーブル（ＰＡＴ）においてリストされたカルテシアン・アドレスが、データ要素の物理記憶域（すなわち、変数）がＭＤＤＢに関連付けられた情報記録媒体（たとえば、記憶ボリューム）において生じるところを、基本データをＭＤＤＢにローディングする間ならびにデータ事前集約処理がその内部で実行される間に、ポイントすることを例示する概略図である。図３Ｃ１は、従来技術の従来のＭＯＬＡＰシステムにおいて使用された例示的三次元データベースの概略図であり、その中に含まれた各データ要素が物理的に、システムの記録媒体において、ＭＤＤＢにおいて整数ベースの座標を割り当てられる、データ変数の次元（および次元階層内の副次元）によって指定される場所に格納されること、およびまた、ＭＤＤＢにロードされた基本データに関連付けられたデータ要素が、ＭＤＤＢ空間において、その内部に含まれた事前集約されたデータ要素より低い整数座標を割り当てられることを示す図である。図３Ｃ２は、「時間」の次元の従来の階層が通常、従来技術の副次元「日、週、月、四半期など」を含むことを例示する概略図である。図３Ｃ３は、従来技術のＭＤＤＢにおける時間のより高い副次元を有するデータ要素が通常、その時間次元に沿って、増大された整数アドレスを割り当てられる様子を示す概略図である。 超大規模の従来技術のＭＤＤＢでは、超大規模ページ・アロケーション・テーブル（ＰＡＴ）が、その中に含まれたデータ要素のアドレス位置を表すことが必要とされ、したがって、アドレス・データ・ページング技術を、このような従来技術のＭＯＬＡＰシステムを実施するために使用された直列コンピューティング・プラットフォーム上で使用可能なＤＲＡＭ（たとえば、プログラム・メモリ）と大容量記憶装置（たとえば、記録ディスクまたはＲＡＩＤ）の間で使用する必要があることを例示する概略図である。 従来の（すなわち、従来技術の）ＭＤＤＢにおける探索時間が、その内部のデータの事前集約の量に比例して増大する様子を示す、グラフィカル表現の図である。 図６Ａは、本発明の多次元オンライン分析処理（ＭＯＬＡＰ）システムの、汎用化された実施形態の概略図であり、これはリレーショナル・データベースとして実現されたデータ・ウェアハウス、統合集約エンジンおよびＭＤＤＢを有する本発明のスタンドアロンの集約サーバ、および複数のＯＬＡＰクライアントをサポートするＯＬＡＰサーバを含み、スタンドアロンの集約サーバが集約機能（たとえば、数値の合計、ならびに乗算、減算、除算など、他の数学的演算）および多次元データ格納機能を実行する図である。図６Ｂは、図６Ａに示した例示的実施形態のスタンドアロンの集約サーバの概略的ブロック図であり、その主要コンポーネント、すなわち、ＲＤＢＭＳフラット・ファイル・リストおよび他のファイルをデータ・ウェアハウス（ＲＤＢＭＳ）から受信するためのベース・データ・インターフェイス（たとえば、ＯＬＤＢ、ＯＬＥ−ＤＢ、ＯＤＢＣ、ＳＱＬ、ＪＤＢＣ、ＡＰＩなど）、ベース・データをベース・データ・インターフェイスから受信するためのベース・データ・ローダ、ベース・データ・インターフェイスおよびベース・データ・ローダのオペレーションを管理するための構成マネージャ、ベース・データをベース・ローダから受信し、集約オペレーションをベース・データにおいて実行し、かつベース・データおよび集約されたデータをＭＤＤＢに格納するための集約エンジンおよびＭＤＤＢハンドラ、リクエストをＯＬＡＰクライアント・マシンから受信し、集約エンジンおよびＭＤＤＢハンドラと共に協調して、集約されたデータを生成かつ／あるいは受信されたリクエストに関係する集約されたデータをＭＤＤＢから検索し、かつこの集約されたものをリクエスト側のＯＬＡＰクライアントに戻すための集約クライアント・インターフェイス（たとえば、ＯＬＤＢ、ＯＬＥ−ＤＢ、ＯＤＢＣ、ＳＱＬ、ＪＤＢＣ、ＡＰＩなど）および入力アナライザ、および、入力アナライザおよび集約クライアント・インターフェイスのオペレーションを管理するための構成マネージャを示す図である。図６Ｃは、本発明の例示的実施形態のスタンドアロンの集約サーバの集約エンジンおよびＭＤＤＢハンドラを含むソフトウェア・モジュールの概略図であり、ベース・データ・リスト構造が階層分析および再順序付けモジュールに供給され、その出力が集約管理モジュールに転送され、その出力が格納モジュールへ、格納管理モジュールを介して転送され、照会指示ロール・アップ（ＱＤＲ）集約管理モジュールが、受信側データベース（ＤＢ）リクエストをＯＬＡＰクライアント・マシンから（集約クライアント・インターフェイスを介して）受信するため、かつ、本発明の集約および格納管理モジュールのオペレーションを管理するために提供される図である。図６Ｄは、（ＤＢ）リクエスト処理メカニズムによって、図６Ｃに示したＱＤＲ集約管理モジュール内で実行される主要オペレーションの流れ図である。 図７Ａは、図６Ｂの例示的実施形態のスタンドアロンの集約サーバ、および、複数のクライアント・マシンをサポートする従来のＯＬＡＰサーバの分離プラットフォーム・タイプの実施の概略図であり、データ・ウェアハウスからのベース・データが、第１のハードウェア／ソフトウェア・プラットフォーム（すなわち、プラットフォームＡ）上で実現された集約サーバによって受信されるように示し、スタンドアロンの集約サーバが、第２のハードウェア／ソフトウェア・プラットフォーム（すなわち、プラットフォームＢ）上で実現された従来のＯＬＡＰサーバを処理するように、ならびに、表計算、ＧＵＩフロント・エンドおよびアプリケーションなど、他のクライアントがサポートする別種のアプリケーションのデータ集約要件を処理するように示す図である。図７Ｂは、図６Ｂの例示的実施形態のスタンドアロンの集約サーバ、および、複数のクライアント・マシンをサポートする従来のＯＬＡＰサーバの共有プラットフォーム・タイプの実施の概略図であり、データ・ウェアハウスからのベース・データが、共通のハードウェア／ソフトウェア・プラットフォーム上で実現されたスタンドアロンの集約サーバによって受信されるように示し、集約サーバが、同じ共通のハードウェア／ソフトウェア・プラットフォーム上で実現された従来のＯＬＡＰサーバを処理するように、ならびに、表計算、ＧＵＩフロント・エンドおよびアプリケーションなど、他のクライアントがサポートする別種のアプリケーションのデータ集約要件を処理するように示す図である。 図８Ａは、共通のハードウェア／ソフトウェア・プラットフォームが、Ｐｅｎｔｉｕｍ ＩＩ ４５０Ｍｈｚ、１ＧＢのＲＡＭ、１８ＧＢのディスクを使用し、Ｍｉｃｒｏｓｏｆｔ ＮＴオペレーティング・システム（ＯＳ）を実行して実現される、図７Ｂに示した従来のＯＬＡＰサーバ（すなわち、Ｏｒａｃｌｅ ＥＸＰＲＥＳＳ Ｓｅｒｖｅｒ）を処理する例示的実施形態のスタンドアロンの集約サーバの共有プラットフォーム・タイプの実施によって得られた性能ベンチマークを表す情報を示すデータ表である。 図９Ａは、本発明の原理による、セグメント化集約の方法における第１の段階の概略図であり、一次元に沿った最初の集約を示す図である。図９Ｂは、本発明の原理によるセグメント化集約の方法における次の段階の概略図であり、図示のスライスなど、次元１に沿ったいかなるセグメントも残りの次元２および３に沿って別々に集約することができること、および一般に、Ｎ次元のシステムでは、第２の段階がＮ−一次元における集約を含むことを示し、セグメンテーションの原理を第１の段階にも適用することができるが、十分に大きいデータのみが第１の次元におけるこのようなスライス化手順を正しいものとし、実際には各セグメントをＮ−１キューブとしてみなし、再帰的計算を可能にすることが可能である図である。図９Ｃ１は、本発明の照会指示ロール・アップ（ＱＤＲ）集約方法／手順の概略図であり、データ集約が第１の次元（Ｄ１）における既存の基本データまたは先に集約されたデータから開始し、このような集約されたデータが、第２の次元（Ｄ２）に沿ったＱＤＲ集約のための基礎として利用されることを示す図である。図９Ｃ２は、本発明の照会指示ロール・アップ（ＱＤＲ）集約方法／手順の概略図であり、最初のデータ集約が第２第３（Ｄ３）における既存の先に集約されたデータから開始し、第３の次元（Ｄ３）に沿って継続し、その後、集約を第２の次元（Ｄ２）に沿って継続することを示す図である。 図１０Ａは、集約方向に沿った昇順索引に基づいて、データの高速検索を可能にする、本発明の原理による図６ＢのＭＤＤＢのディスク記憶装置においてスパース・データを格納する「スライス−ストレージ」方法の概略図である。図１０Ｂは、図６ＢのＭＤＤＢのストレージにおいて使用されたデータ・ファイルおよびディレクトリ・ファイルのデータ編成、および、データ・ファイルの昇順による単純な２分探索技術を使用した、その中で照会されたデータ・ポイントを探索する方法の概略図である。 図１１Ａは、図６ＢのＭＤＤＢ内のデータの格納のための、３レベルの階層を有する３つの例示的多階層データ構造の概略図であり、ベース・データを表す第１のレベルが項目Ａ、Ｂ、ＦおよびＧから構成され、第２のレベルが項目Ｃ、Ｅ、ＨおよびＩから構成され、第３のレベルが、すべての３つの階層構造に共通である単一の項目Ｄから構成される図である。図１１Ｂは、本発明の原理による、図１１Ａのすべての３つの階層から併合された、最適化された多階層データ構造の概略図である。図１１Ｃ（ｉ）ないし１１Ｃ（ｉｘ）は、多数の階層を、機能的に多数の階層に相当する単一の階層に最適に併合する、本発明の例示的階層変換メカニズムのオペレーションの流れ図（および付属のデータ構造）を表す図である。 図６Ｂのスタンドアロンの集約サーバによって実行されるオペレーションのレベルを示し、本発明の原理によってセグメント化集約の方法を実行するための異なる使用可能コンポーネントを要約する概略図である。 ＵＲＬディレクトリ・システム、データ・マート、ＲＤＢＭＳ、ＲＯＬＡＰシステムおよびＯＬＡＰシステムのデータ集約ニーズを一様に処理する、中央データ・ウェアハウスのコンポーネントとして示す、本発明のスタンドアロンの集約サーバの概略図である。 本発明を実施することができる、従来技術の情報データベース・システムの概略図である。 本発明を実施することができる、従来技術のデータ・ウェアハウスおよびＯＬＡＰシステムの概略図である。 図１６Ａ〜１６Ｃは、従来技術のリレーショナル・データベース管理システム（ＲＤＢＭＳ）において使用された例示的テーブルの概略図である。図１６Ｂおよび１６Ｃは、図１６Ａのテーブルにおけるオペレータ（照会）およびこのような照会の結果をそれぞれ例示する図である。 図１７Ａは、リレーショナル・データベースの例示的次元スキーマ（スター・スキーマ）の概略図である。図１７Ｂは、図１７Ａに示したスキーマを実施するために使用されたテーブルの概略図である。 図１８Ａは、例示的多次元スキーマ（スター・スキーマ）の概略図である。図１８Ｂは、従来の教示による、期間次元に沿って、中央ファクト・テーブルのファクトにおいて実行された集約オペレーションの結果を格納するサマリ・テーブルを含む、図１８Ａのスキーマを実施するために使用されたテーブルの概略図である。 図１９Ａは、複数のクライアントからの照会をサポートするリレーショナル・データベースおよび統合多次元（ＭＤＤ）集約モジュールを含む、本発明のＤＢＭＳ（たとえば、図示のＲＤＢＭＳ）の例示的実施形態の概略図であり、集約エンジンが集約機能（たとえば、数値の合計、ならびに乗算、減算、除算など、他の数学的演算）および非リレーショナルの多次元データ格納機能を実行する図である。図１９Ｂは、図６Ａに示した本発明の例示的実施形態のＭＤＤ集約モジュールの概略的ブロック図である。図１９Ｃ（ｉ）および１９Ｃ（ｉｉ）は共に、本発明のＤＢＭＳ内で、データ集約および関連するサポート・オペレーションを実行するときに実行される、本発明のこのような集約データベース上で行われたユーザ提出の（たとえば、自然言語）照会のサービスを含む主要オペレーションの流れ図である。図１９Ｄは、（ＤＢ）リクエスト処理メカニズムによって、図６Ｂに示したＭＤＤ制御モジュール内で実行される主要オペレーションの流れ図である。図１９Ｅは、ユーザが、本発明によるＭＤＤ集約モジュールにおいて生成かつ／または格納された集約データにおいて照会できるようにする、ＤＢＭＳのビュー・メカニズムの概略図である。図１９Ｆは、ユーザが、本発明によるＭＤＤ集約モジュールにおいて生成かつ／または格納された集約データにおいて照会できるようにする、ＤＢＭＳのトリガ・メカニズムの概略図である。図１９Ｇは、リレーショナル部分および非リレーショナル部分に論理的に区分することを例示する、本発明のＤＢＭＳの概略図であり、リレーショナル部分はリレーショナル・データ・ストア（たとえば、テーブルおよびディクショナリ）およびサポート・メカニズム（たとえば、照会ハンドリング・サービス）を含み、非リレーショナル部分はＭＤＤ集約モジュールを含み、データが図のようにリレーショナル部分と非リレーショナル部分の間で双方向的に流れる図である。 図２０Ａは、図１９Ａに示した例示的実施形態のＤＢＭＳシステムの分離プラットフォーム・タイプの実施を示す図であり、リレーショナル・データストアおよびサポート・メカニズム（たとえば、ＤＢＭＳの照会ハンドリング、ファクト・テーブルおよびディクショナリ）が、本発明のＭＤＤ集約モジュールを実行するために使用される元の分離ハードウェア・プラットフォームおよび／またはＯＳシステム上に存在する図である。図２０Ｂは、図１９Ａに示した例示的実施形態のＤＢＭＳシステムの共通プラットフォーム・タイプの実施を示し、リレーショナル・データストアおよびサポート・メカニズム（たとえば、ＤＢＭＳの照会ハンドリング、ファクト・テーブルおよびディクショナリ）が、本発明のＭＤＤ集約モジュールを実行するために使用される同じハードウェア・プラットフォームおよびオペレーティング・システム（ＯＳ）を共有する図である。 ＲＯＬＡＰシステム（または他のＯＬＡＰシステム）のデータ格納および集約のニーズを処理する、中央データ・ウェアハウスのコンポーネントとして示す、本発明のＤＢＭＳの概略図である。 中央データ・ウェアハウスのコンポーネントとして示す、本発明のＤＢＭＳの概略図であり、ＤＢＭＳは統合ＯＬＡＰ分析ロジック（および好ましくは統合プレゼンテーション・モジュール）を含み、これらがＤＢＭＳシステムモジュールの照会ハンドリングおよびＭＤＤ集約モジュールと協調して動作して、ＤＢＭＳシステムのユーザが多次元レポート（たとえば、レシオ、ランク、変換、動的連結、複雑なフィルタリング、予測、照会規定、スケジューリング、フロー制御、事前集約推論、非正規化サポートおよび／またはテーブル区分および結合）を実行できるように、かつ好ましくは従来のＯＬＡＰ分析（グリッド、グラフ、マップ、アラート、ドリル・ダウン、データ・ピボット、データ・サーフ、スライスおよびダイス、プリント）を実行できるようにする図である。

Claims (148)

1. 複数の異なるＯＬＡＰサーバのうちいずれか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. ＲＤＢＭＳの前記照会処理機構が標準的なインタフェースを介して前記集約モジュールと通信する、請求項２４に記載のＲＤＢＭＳ。
    
30. 標準的なインタフェースが、ＯＬＤＢ、ＯＬＥ−ＤＢ、ＯＤＢＣ、ＳＱＬ、ＪＤＢＣのうちの１つを含む、請求項２９に記載のＲＤＢＭＳ。
    
31. ファクト・データを記憶するリレーショナル・データストアと、 リレーショナル・データストアに動作可能に結合された統合集約モジュールであって、照会有向ロールアップ（ＱＤＲ）処理によってファクト・データを集約し、得られた集約済みデータを、テーブルの代わりに又はテーブルに加えて他のデータ構造を用いてデータが記録される非リレーショナルの多次元データストアに記憶するための統合集約モジュールとを備える、リレーショナル・データベース管理システム（ＲＤＢＭＳ）。
    
32. 非リレーショナルの多次元データストアに照会する際のユーザ操作が、リレーショナル・ストア中のデータを照会するのと変わらない、請求項３１に記載のＲＤＢＭＳ。
    
33. 前記集約モジュールが、少なくともファクト・データをリレーショナル・データストアからロードするためのデータ・ローディング機構と、ファクト・データを集約するための集約エンジンと、ファクト・データおよび得られた集約済みファクト・データを非リレーショナルの多次元データストアに記憶するための記憶ハンドラとを備える、請求項３１に記載のＲＤＢＭＳ。
    
34. 前記集約モジュールが制御ロジックを備え、前記制御ロジックが、所与の照会ステートメントに応えるのに必要なデータを非リレーショナルの多次元データストアが含まないと決定すると、集約エンジンを制御して、少なくとも所与の照会ステートメントに応えるのに必要なファクト・データを集約するようにし、集約モジュールを制御して、ユーザに通信するために集約済みデータを返すようにする、請求項３３に記載のＲＤＢＭＳ。
    
35. ＲＤＢＭＳと一体のＯＬＡＰ分析ロジックをさらに備える、請求項３１に記載のＲＤＢＭＳ。
    
36. 複数の情報技術システムにインタフェースする企業全体データ・ウェアハウスとして使用するための、請求項３１に記載のＲＤＢＭＳ。
    
37. 情報データベース・システム中のデータベース・ストアとして使用するための、請求項３１に記載のＲＤＢＭＳ。
    
38. 情報データベース・システムが基本詳細データに対する集約および計算を必要とする、請求項３７に記載のＲＤＢＭＳ。
    
39. オペレーショナル・データベース・システム中のデータベース・ストアとして使用するための、請求項３１に記載のＲＤＢＭＳ。
    
40. オペレーショナル・データベース・システムが、顧客リレーション管理システム、企業リソース・プランニング・システム、顧客データ・レコード・データベース・システムのうちの１つのシステムの一部である、請求項３９に記載のＲＤＢＭＳ。
    
41. リレーショナル・データストアおよび非リレーショナルの多次元データストアに照会する際のユーザ操作が、クライアント・マシンから通信される自然言語照会を生成する、請求項３１に記載のＲＤＢＭＳ。
    
42. 前記クライアント・マシンが、前記自然言語照会を生成するためのウェブ対応ブラウザを備える、請求項４１に記載のＲＤＢＭＳ。
    
43. ユーザによって生成された照会に応えるための照会処理機構をさらに備え、前記照会処理機構が標準的なインタフェースを介して前記集約モジュールと通信する、請求項４１に記載のＲＤＢＭＳ。
    
44. 標準的なインタフェースが、ＯＬＤＢ、ＯＬＥ−ＤＢ、ＯＤＢＣ、ＳＱＬ、ＪＤＢＣのうちの１つを含む、請求項４３に記載のＲＤＢＭＳ。
    
45. ファクト・データを記憶するリレーショナル・データストアを備えるリレーショナル・データベース管理システム（ＲＤＢＭＳ）において、照会有向ロールアップ（ＱＤＲ）処理によってファクト・データを集約し、集約済みデータへの照会アクセスを提供する方法であって、（ａ）リレーショナル・データストアに動作可能に結合された統合集約モジュールであって、照会有向ロールアップ（ＱＤＲ）処理によってファクト・データを集約し、得られた集約済みデータを、テーブルの代わりに又はテーブルに加えて他のデータ構造を用いてデータが記録される非リレーショナルの多次元データストアに記憶するための統合集約モジュールを提供するステップと、（ｂ）ユーザ入力に応答して、集約モジュールによって生成された集約済みファクト・データへの参照を生成するステップと、（ｃ）ユーザ入力に応答して生成された所与の照会ステートメントを処理するステップであって、所与の照会ステートメントが前記参照に関するものであると識別されると、前記参照によってポイントされる、前記所与の照会ステートメントに関連する集約済みファクト・データの部分を、統合集約モジュールから検索するステップとを含む方法。
    
46. ステップ（ｃ）がさらに、所与の照会ステートメントから次元を抽出し、抽出された次元に基づいて非リレーショナルの多次元データストアの位置にアクセスし、検索されたデータをユーザに返すステップを含む、請求項４５に記載の方法。
    
47. ステップ（ａ）がさらに、少なくともファクト・データをリレーショナル・データストアからロードし、ファクト・データを集約し、ファクト・データおよび得られた集約済みファクト・データを非リレーショナルの多次元データストアに記憶するステップを含む、請求項４５に記載の方法。
    
48. 前記集約モジュールが、所与の照会ステートメントに応えるのに必要なデータを非リレーショナルの多次元データストアが含まないと決定すると、集約エンジンを制御して、少なくとも所与の照会ステートメントに応えるのに必要なファクト・データを集約するようにし、集約済みデータをユーザに返す、請求項４７に記載の方法。
    
49. 検索されたデータに対してＯＬＡＰデータ分析操作を実施するステップをさらに含む、請求項４５に記載の方法。
    
50. 前記ＲＤＢＭＳが、複数の情報技術システムにインタフェースする企業全体データ・ウェアハウスとして使用される、請求項４５に記載の方法。
    
51. 前記ＲＤＢＭＳが、情報データベース・システム中のデータベース・ストアとして使用される、請求項４５に記載の方法。
    
52. 情報データベース・システムが基本詳細データに対する集約および計算を必要とする、請求項５１に記載の方法。
    
53. 前記ＲＤＢＭＳがオペレーショナル・データベース・システム中のデータベース・ストアとして使用される、請求項４５に記載の方法。
    
54. オペレーショナル・データベース・システムが、顧客リレーション管理システム、企業リソース・プランニング・システム、顧客データ・レコード・データベース・システムのうちの１つのシステムの一部である、請求項５３に記載の方法。
    
55. リレーショナル・データストアおよび非リレーショナルの多次元データストアに照会する際のユーザ操作が、クライアント・マシンから通信される自然言語照会を生成する、請求項４５に記載の方法。
    
56. 前記クライアント・マシンが、前記自然言語照会を生成するためのウェブ対応ブラウザを備える、請求項５５に記載の方法。
    
57. 前記ＲＤＢＭＳが照会サービス機構を備え、前記照会サービス機構が、照会ステートメントを処理し、所与の照会ステートメントが非リレーショナルの多次元データストア中に記憶されたデータを参照する場合に前記集約モジュールと通信する、請求項４５に記載の方法。
    
58. 前記照会サービス機構が標準的なインタフェースを介して前記集約モジュールと通信する、請求項５７に記載の方法。
    
59. 標準的なインタフェースが、ＯＬＤＢ、ＯＬＥ−ＤＢ、ＯＤＢＣ、ＳＱＬ、ＪＤＢＣのうちの１つを含む、請求項５８に記載の方法。
    
60. データをテーブルに記憶するリレーショナル・データストアと、 リレーショナル・データストアに動作可能に結合された集約モジュールであって、リレーショナル・データストアのテーブルに記憶されたデータを照会有向ロールアップ（ＱＤＲ）処理によって集約し、得られた集約済みデータを、テーブルの代わりに又はテーブルに加えて他のデータ構造を用いてデータが記録される非リレーショナル・データストアに記憶するための集約モジュールと、 リレーショナル・データストアに記憶されたデータへの第１の参照、および集約モジュールによって生成されて非リレーショナル・データストアに記憶された集約済みデータへの第２の参照を生成するための参照生成機構と、 照会ステートメントを処理するための照会処理機構であって、所与の照会ステートメントが前記第２の参照に関するものであると識別されると、前記集約モジュールと通信して、前記参照によって識別される、前記所与の照会ステートメントに関連する集約済みデータの部分を検索する照会処理機構とを備える、データベース管理システム（ＤＢＭＳ）。
    
61. リレーショナル・データストアがファクト・データを記憶することを特徴とするリレーショナル・データベース管理システム（ＲＤＢＭＳ）として使用される、請求項６０に記載のＤＢＭＳ。
    
62. 参照生成機構が閲覧機構を備える、請求項６１に記載のＤＢＭＳ。
    
63. 参照生成機構がネイティブ・トリガ機構を備える、請求項６０に記載のＤＢＭＳ。
    
64. 非リレーショナル・データストアが多次元データベースを含む、請求項６０に記載のＤＢＭＳ。
    
65. 参照生成機構が、ユーザからサブミットされた照会ステートメントに応えるための照会サービス機構の一部である、請求項６０に記載のＤＢＭＳ。
    
66. 前記集約モジュールが、照会ステートメントを受け取るための照会ハンドリング機構を備え、前記照会処理機構と前記照会ハンドリング機構の間の通信が、集約モジュールの照会ハンドリング機構に所与の照会ステートメントを転送することによって達成される、請求項６５に記載のＤＢＭＳ。
    
67. 前記照会ハンドリング機構が、受け取った照会ステートメントから少なくとも１つの次元を抽出し、少なくとも１つの次元を記憶ハンドラに転送し、記憶ハンドラが、転送された少なくとも１つの次元に基づいて非リレーショナル・データストアの位置にアクセスし、検索されたデータを、ユーザに通信するために照会サービス機構に返す、請求項６６に記載のＤＢＭＳ。
    
68. 前記集約モジュールが、リレーショナル・データストアからデータをロードするためのデータ・ローディング機構と、リレーショナル・データストアからロードされたデータを集約するための集約エンジンと、リレーショナル・データストアからロードされたデータおよび集約エンジンによって生成された集約済みデータを非リレーショナル・データストアに記憶するための記憶ハンドラとを備える、請求項６７に記載のＤＢＭＳ。
    
69. 前記集約モジュールが制御ロジックを備え、前記制御ロジックが、所与の照会ステートメントに応えるのに必要なデータを非リレーショナル・データストアが含まないと決定すると、集約エンジンを制御して、所与の照会ステートメントに応えるのに必要な集約済みデータを生成するようにし、集約モジュールを制御して、ユーザに通信するために集約済みデータを照会サービス機構に返すようにする、請求項６８に記載のＤＢＭＳ。
    
70. ＤＢＭＳに統合されたＯＬＡＰ分析ロジックをさらに備える、請求項６０に記載のＤＢＭＳ。
    
71. ＤＢＭＳに統合されたＯＬＡＰプレゼンテーション・ロジックをさらに備える、請求項６０に記載のＤＢＭＳ。
    
72. 複数の情報技術システムにインタフェースする企業全体データ・ウェアハウスとして使用するための、請求項６０に記載のＤＢＭＳ。
    
73. 情報データベース・システム中のデータベース・ストアとして使用するための、請求項６０に記載のＤＢＭＳ。
    
74. 情報データベース・システムが基本詳細データに対する集約および計算を必要とする、請求項７３に記載のＤＢＭＳ。
    
75. オペレーショナル・データベース・システム中のデータベース・ストアとして使用するための、請求項７０に記載のＤＢＭＳ。
    
76. オペレーショナル・データベース・システムが、顧客リレーション管理システム、企業リソース・プランニング・システム、顧客データ・レコード・データベース・システムのうちの１つのシステムの一部である、請求項７５に記載のＤＢＭＳ。
    
77. 前記照会ステートメントが、クライアント・マシンから通信される自然言語照会の通信に応答して照会インタフェースによって生成される、請求項６０に記載のＤＢＭＳ。
    
78. 前記クライアント・マシンが、前記自然言語照会を照会インタフェースに通信するためのウェブ対応ブラウザを備える、請求項７７に記載のＤＢＭＳ。
    
79. ＤＢＭＳの照会処理機構と集約モジュールの照会ハンドリング機構とが標準的なインタフェースを介して通信する、請求項６６に記載のＤＢＭＳ。
    
80. 標準的なインタフェースが、ＯＬＤＢ、ＯＬＥ−ＤＢ、ＯＤＢＣ、ＳＱＬ、ＪＤＢＣのうちの１つを含む、請求項７９に記載のＤＢＭＳ。
    
81. オブジェクト・データベース管理システム（ＯＤＢＭＳ）として使用するための、請求項６０に記載のＤＢＭＳ。
    
82. オブジェクト・リレーショナル・データベース管理システム（ＯＲＤＢＭＳ）として使用するための、請求項６０に記載のＤＢＭＳ。
    
83. データをテーブルに記憶するリレーショナル・データストアと、 リレーショナル・データストアに動作可能に結合された統合集約モジュールであって、リレーショナル・データストアのテーブルに記憶されたデータを照会有向ロールアップ（ＱＤＲ）処理によって集約し、得られた集約済みデータを、テーブルの代わりに又はテーブルに加えて他のデータ構造を用いてデータが記録される非リレーショナル・データストアに記憶するための統合集約モジュールとを備えるデータベース管理システム（ＤＢＭＳ）。
    
84. リレーショナル・データストアとサポート機構とを含むリレーショナル部分をさらに備える、請求項８３に記載のＤＢＭＳ。
    
85. リレーショナル部分と統合集約モジュールの間で双方向データ・フローが生じ、それにより、リレーショナル・データストアに記憶されたデータが集約モジュールにロードされ、集約モジュールの非リレーショナル・データストアに記憶された集約済みデータがリレーショナル部分に通信される、請求項８４に記載のＤＢＭＳ。
    
86. リレーショナル・データベース管理システム（ＲＤＢＭＳ）として使用され、リレーショナル・データストアがファクト・データを記憶する、請求項８３に記載のＤＢＭＳ。
    
87. 非リレーショナル・データストアが多次元データベースを含む、請求項８３に記載のＤＢＭＳ。
    
88. 非リレーショナル・データストアに照会する際のユーザ操作が、リレーショナル・データストアに照会するのと変わらない、請求項８３に記載のＤＢＭＳ。
    
89. 前記集約モジュールが、リレーショナル・データストアからデータをロードするためのデータ・ローディング機構と、リレーショナル・データストアからロードされたデータを集約するための集約エンジンと、リレーショナル・データストアからロードされたデータおよび集約エンジンによって生成された集約済みデータを非リレーショナル・データストアに記憶するための記憶ハンドラとを備える、請求項８３に記載のＤＢＭＳ。
    
90. 前記集約モジュールが制御ロジックを備え、前記制御ロジックが、所与の照会に応えるのに必要なデータを非リレーショナル・データストアが含まないと決定すると、集約エンジンを制御して、所与の照会に応えるのに必要な集約済みデータを生成するようにし、集約モジュールを制御して、要求側に通信するために集約済みデータを返すようにする、請求項８９に記載のＤＢＭＳ。
    
91. ＤＢＭＳと一体のＯＬＡＰ分析ロジックをさらに備える、請求項８３に記載のＤＢＭＳ。
    
92. ＤＢＭＳと一体のＯＬＡＰプレゼンテーション・ロジックをさらに備える、請求項９１に記載のＤＢＭＳ。
    
93. 複数の情報技術システムにインタフェースする企業全体データ・ウェアハウスとして使用するための、請求項８３に記載のＤＢＭＳ。
    
94. 情報データベース・システム中のデータベース・ストアとして使用するための、請求項８３に記載のＤＢＭＳ。
    
95. 情報データベース・システムが基本詳細データに対する集約および計算を必要とする、請求項９４に記載のＤＢＭＳ。
    
96. オペレーショナル・データベース・システム中のデータベース・ストアとして使用するための、請求項８３に記載のＤＢＭＳ。
    
97. オペレーショナル・データベース・システムが、顧客リレーション管理システム、企業リソース・プランニング・システム、顧客データ・レコード・データベース・システムのうちの１つのシステムの一部である、請求項９６に記載のＤＢＭＳ。
    
98. リレーショナル・データストアおよび非リレーショナル・データストアに照会する際のユーザ操作が、クライアント・マシンから通信される自然言語照会を生成する、請求項２８に記載のＤＢＭＳ。
    
99. 前記クライアント・マシンが、前記自然言語照会を生成するためのウェブ対応ブラウザを備える、請求項９８に記載のＤＢＭＳ。
    
100. ＤＢＭＳのリレーショナル部分と集約モジュールとが標準的なインタフェースを介して通信する、請求項８５に記載のＤＢＭＳ。
     
101. 標準的なインタフェースが、ＯＬＤＢ、ＯＬＥ−ＤＢ、ＯＤＢＣ、ＳＱＬ、ＪＤＢＣのうちの１つを含む、請求項１００に記載のＤＢＭＳ。
     
102. オブジェクト・データベース管理システム（ＯＤＢＭＳ）として使用するための、請求項８３に記載のＤＢＭＳ。
     
103. オブジェクト・リレーショナル・データベース管理システム（ＯＲＤＢＭＳ）として使用するための、請求項８３に記載のＤＢＭＳ。
     
104. データをテーブルに記憶するリレーショナル・データストアを備えるデータベース管理システム（ＤＢＭＳ）において、リレーショナル・データストアのテーブルに記憶されたデータを照会有向ロールアップ（ＱＤＲ）処理によって集約し、集約済みデータへの照会アクセスを提供する方法であって、 （ａ）リレーショナル・データストアに動作可能に結合された統合集約モジュールであって、リレーショナル・データストアに記憶されたデータを照会有向ロールアップ（ＱＤＲ）処理によって集約し、得られた集約済みデータを、テーブルの代わりに又はテーブルに加えて他のデータ構造を用いてデータが記録される非リレーショナル・データストアに記憶するための統合集約モジュールを提供するステップと、 （ｂ）ユーザ入力に応答して、集約モジュールによって生成された集約済みデータへの参照を生成するステップと、 （ｃ）ユーザ入力に応答して生成された所与の照会ステートメントを処理するステップであって、所与の照会ステートメントが前記参照に関するものであると識別されると、前記参照によって識別される、前記所与の照会ステートメントに関連する集約済みデータの部分を、統合集約モジュールから検索するステップとを含む方法。
     
105. ステップ（ｃ）がさらに、所与の照会ステートメントから少なくとも１つの次元を抽出し、抽出された少なくとも１つの次元に基づいて非リレーショナル・データストアの位置にアクセスし、検索されたデータをユーザに返すステップを含む、請求項１０４に記載の方法。
     
106. ステップ（ａ）がさらに、リレーショナル・データストアからデータをロードし、リレーショナル・データストアからロードされたデータを集約し、リレーショナル・データストアからロードされたデータおよび得られた集約済みデータを非リレーショナル・データストアに記憶するステップを含む、請求項１０４に記載の方法。
     
107. 前記集約モジュールが、所与の照会ステートメントに応えるのに必要なデータを非リレーショナル・データストアが含まないと決定すると、集約エンジンを制御して、所与の照会ステートメントに応えるのに必要な集約済みデータを生成するようにし、集約済みデータをユーザに返す、請求項１０６に記載の方法。
     
108. ＤＢＭＳが、リレーショナル・データストアにファクト・データを記憶するリレーショナル・データベース管理システム（ＲＤＢＭＳ）を含む、請求項１０４に記載の方法。
     
109. 非リレーショナル・データストアが多次元データベースを含む、請求項１０４に記載の方法。
     
110. ＤＢＭＳが、ＤＢＭＳに統合されたＯＬＡＰ分析ロジックを備える、請求項１０４に記載の方法。
     
111. ＤＢＭＳが、ＤＢＭＳに統合されたＯＬＡＰプレゼンテーション・ロジックを備える、請求項１１０に記載の方法。
     
112. ＤＢＭＳが、複数の情報技術システムにインタフェースする企業全体データ・ウェアハウスとして使用される、請求項１０４に記載の方法。
     
113. ＤＢＭＳが、情報データベース・システム中のデータベース・ストアとして使用される、請求項１０４に記載の方法。
     
114. 情報データベース・システムが基本詳細データに対する集約および計算を必要とする、請求項１１３に記載の方法。
     
115. ＤＢＭＳがオペレーショナル・データベース・システム中のデータベース・ストアとして使用される、請求項１０４に記載の方法。
     
116. オペレーショナル・データベース・システムが、顧客リレーション管理システム、企業リソース・プランニング・システム、顧客データ・レコード・データベース・システムのうちの１つのシステムの一部である、請求項１１５に記載の方法。
     
117. リレーショナル・データストアおよび非リレーショナル・データストアに照会する際のユーザ操作が、クライアント・マシンから通信される自然言語照会を生成する、請求項１０４に記載の方法。
     
118. 前記クライアント・マシンが、前記自然言語照会を生成するためのウェブ対応ブラウザを備える、請求項１１７に記載の方法。
     
119. 集約モジュールとの通信が標準的なインタフェースを介して行われる、請求項１０４に記載の方法。
     
120. 標準的なインタフェースが、ＯＬＤＢ、ＯＬＥ−ＤＢ、ＯＤＢＣ、ＳＱＬ、ＪＤＢＣのうちの１つを含む、請求項１１９に記載の方法。
     
121. ＤＢＭＳがオブジェクト・データベース管理システム（ＯＤＢＭＳ）を含む、請求項１０４に記載の方法。
     
122. ＤＢＭＳがオブジェクト・リレーショナル・データベース管理システム（ＯＲＤＢＭＳ）を含む、請求項１０４に記載の方法。
     
123. ネットワークを介してＯＬＡＰサーバと通信する複数のクライアント・マシンと、ユーザによって指示されるＯＬＡＰ分析をデータに対して行うことを可能にするためのＯＬＡＰ分析ロジックおよびプレゼンテーション・ロジックを備えるＯＬＡＰサーバと、ＯＬＡＰサーバと動作可能に通信して、データに対してデータ集約操作を行い、そのようなデータをＯＬＡＰサーバからアクセスされるように記憶および管理する請求項１に記載のスタンドアロン集約サーバとを備える、オンライン分析処理（ＯＬＡＰ）システム。
     
124. ネットワークがインターネットのインフラストラクチャを含む、請求項１２３に記載のＯＬＡＰシステム。
     
125. 前記クライアント・マシンが、前記ユーザによって指示されるＯＬＡＰ分析を可能にするウェブ・ブラウザ・ベースのユーザ・インタフェースを備える、請求項１２４に記載のＯＬＡＰシステム。
     
126. ネットワークを介してＯＬＡＰサーバと通信する複数のクライアント・マシンと、 ユーザによって指示されるＯＬＡＰ分析をデータに対して行うことを可能にするためのＯＬＡＰ分析ロジックおよびプレゼンテーション・ロジックを備えるＯＬＡＰサーバと、 ＯＬＡＰサーバと動作可能に通信して、データに対してデータ集約操作を行い、そのようなデータをＯＬＡＰサーバからアクセスされるように記憶および管理する請求項１５、３１、６０、８３のうちのいずれか一項に記載のＤＢＭＳとを備える、オンライン分析処理（ＯＬＡＰ）システム。
     
127. ＯＬＡＰサーバがＤＢＭＳと一体である、請求項１２６に記載のＯＬＡＰシステム。
     
128. ネットワークがインターネットのインフラストラクチャを含む、請求項１２６に記載のＯＬＡＰシステム。
     
129. 前記クライアント・マシンが、前記ユーザによって指示されるＯＬＡＰ分析を可能にするウェブ・ブラウザ・ベースのユーザ・インタフェースを備える、請求項１２８に記載のＯＬＡＰシステム。
     
130. ネットワークを介してＤＢＭＳと通信する複数のクライアント・マシンと、 クライアント・マシンと動作可能に通信して、データに対してデータ集約操作を行い、そのようなデータをクライアント・マシンからアクセスされるように記憶および管理する、請求項１５、３１、６０、８３のうちのいずれか一項に記載のＤＢＭＳとを備える、データ・ウェアハウス・システム。
     
131. ネットワークがインターネットのインフラストラクチャを含む、請求項１３０に記載のデータ・ウェアハウス。
     
132. 前記クライアント・マシンが、ＤＢＭＳへのユーザ・アクセスを可能にするウェブ・ブラウザ・ベースのユーザ・インタフェースを備える、請求項１３０に記載のデータ・ウェアハウス。
     
133. 複数の異なるＯＬＡＰサーバのうちいずれか１つと共に使用して、データを集約する方法であって、各ＯＬＡＰサーバは、複数のユーザが該サーバに動作可能に結合されたクライアント・マシンとの対話を通してＯＬＡＰ分析を実施するアプリケーション層及びプレゼンテーション層を提供し、（ａ）データ・ソースから多次元データストアにデータをロードするステップであって、データがＮ個の次元に論理的に区分化される、ステップと、（ｂ）多次元データストア中の第１の次元に沿ってデータ集約操作の第１段階を実施するステップと、（ｃ）第１の次元中の所与のスライスについて、多次元データストア中の第１の次元以外のＮ−１個の次元に沿って集約操作の第２段階を実施するステップとを含み、データ集約操作として照会有向ロールアップ（ＱＤＲ）処理を実施する段階を含む方法。
     
134. 項目の複数の階層として論理的に構成された少なくとも１つの次元を有するデータを含むデータベース・システムにおいて、項目の複数の階層を、複数の階層と機能的に同等である単一の階層に変換する方法であって、親項目にリンクされた、所与の子項目以外の子項目はどれも、前記所与の子項目と共通の子項目を有しないとき、前記所与の子項目を単一の階層中で前記親項目とリンクするステップを含む、請求項１０４に記載の方法。
     
135. 親項目にリンクされた他の子項目のうちの少なくとも１つが、所与の子項目と共通の子項目を有する場合は、前記所与の子項目は単一の階層中で前記親項目とリンクされない、請求項１３４に記載の方法。
     
136. 複数の異なるＯＬＡＰサーバのうちいずれか１つと共に使用するためのデータ集約エンジンであり、各ＯＬＡＰサーバは、複数のユーザが該サーバに動作可能に結合されたクライアント・マシンとの対話を通してＯＬＡＰ分析を実施するアプリケーション層及びプレゼンテーション層を提供し、項目の複数の階層として論理的に構成された少なくとも１つの次元のデータを識別し、親項目にリンクされた所与の子項目以外の子項目がどれも前記所与の子項目と共通の子項目を有しないとき、前記所与の子項目を単一の階層中で前記親項目とリンクすることによって、項目の複数の階層を単一の階層（複数の階層と機能的に同等）に変換する階層変換モジュールと、 単一の階層に基づいてデータを照会有向ロールアップ（ＱＤＲ）処理によって集約する集約モジュールと、を備えた、データ集約エンジン。
     
137. 親項目にリンクされた他の子項目のうちの少なくとも１つが所与の子項目と共通の子項目を有する場合は、階層変換モジュールは前記所与の子項目を単一の階層中で前記親項目とリンクしない、請求項１３６に記載のデータ集約エンジン。
     
138. ＯＬＡＰサーバ（ＯＬＡＰ分析ロジックおよびプレゼンテーション・ロジックを含む）と、ＯＬＡＰサーバに動作可能に結合されてユーザによって指示されるＯＬＡＰ分析を提供するクライアント・マシンとに統合され、それにより、データに対してデータ集約操作を行ってそのようなデータを記憶および管理することのできるＯＬＡＰシステムを実現する、請求項１３６に記載のデータ集約エンジン。
     
139. 前記クライアント・マシンが、ＯＬＡＰサーバへのユーザ・アクセスを可能にするウェブ・ブラウザ・ベースのユーザ・インタフェースを備える、請求項１３８に記載のデータ集約エンジン。
     
140. ＤＢＭＳと統合され、それにより、データに対してデータ集約操作を行ってそのようなデータを記憶および管理することのできる改良型のＤＢＭＳを実現する、請求項１３６に記載のデータ集約エンジン。
     
141. ネットワークを介して複数のクライアント・マシンに動作可能に結合されたＤＢＭＳと統合され、それにより、データに対してデータ集約操作を行ってそのようなデータを記憶および管理することのできるデータ・ウェアハウスを実現する、請求項１３６に記載のデータ集約エンジン。
     
142. ネットワークがインターネットのインフラストラクチャを含む、請求項１４１に記載のデータ集約エンジン。
     
143. 前記クライアント・マシンが、ＤＢＭＳへのユーザ・アクセスを可能にするウェブ・ブラウザ・ベースのユーザ・インタフェースを備える、請求項１４１に記載のデータ集約エンジン。
     
144. サーバ（分析ロジックを含む）と、サーバに動作可能に結合されてユーザによって指示される分析を提供する前記クライアント・マシンとに統合され、それにより、データに対してデータ集約操作を行ってそのようなデータを記憶および管理することのできる決定サポート・システムを実現する、請求項１４２に記載のデータ集約エンジン。
     
145. 前記クライアント・マシンが、サーバへのユーザ・アクセスを可能にするウェブ・ブラウザ・ベースのユーザ・インタフェースを備える、請求項１４３に記載のデータ集約エンジン。
     
146. 企業と共に動作可能な決定サポート・システムであって、ネットワークを介してサーバと通信する複数のクライアント・マシンと、ユーザによって指示される分析をデータに対して行うことを可能にするための分析ロジックを備えるサーバと、サーバと動作可能に通信して、データに対してデータ集約操作を行い、そのようなデータをサーバからアクセスされるように記憶および管理する請求項１に記載のスタンドアロン集約サーバとを備える、決定サポート・システム。
     
147. ネットワークがインターネットのインフラストラクチャを含む、請求項１４６に記載の決定サポート・システム。
     
148. 前記クライアント・マシンが、前記ユーザによって指示される分析を可能にするウェブ・ブラウザ・ベースのユーザ・インタフェースを備える、請求項１４７に記載の決定サポート・システム。

Images