次の方法で共有


集計と集計のデザイン

AggregationDesign オブジェクトは、複数のパーティション間で共有できる一連の集計定義を定義します。

Aggregation オブジェクトは、ディメンションの特定の粒度でのメジャー グループ データの集計を表します。

単純な Aggregation オブジェクトは、基本情報とディメンションで構成されます。 基本情報には、集計の名前、ID、注釈、および説明が含まれます。 ディメンションは、ディメンションの粒度属性の一覧を含む AggregationDimension オブジェクトのコレクションです。

集計は、リーフ セルからのデータの事前計算済みの概要です。 集計では、質問の前に回答を準備することで、クエリの応答時間が向上します。 たとえば、データ ウェアハウスのファクト テーブルに数十万行が含まれている場合、特定の製品ラインの週次売上合計を要求するクエリでは、ファクト テーブル内のすべての行をスキャンしてクエリ時に合計して回答を計算する必要がある場合、回答に時間がかかる場合があります。 ただし、このクエリに回答する集計データが事前に計算されている場合、応答はほぼ即時になる可能性があります。 この概要データの事前計算は処理中に発生し、OLAP テクノロジの迅速な応答時間の基礎となります。

キューブは、OLAP テクノロジが概要データを多次元構造に整理する方法です。 ディメンションとその属性の階層には、キューブに対して要求できるクエリが反映されます。 集計は、ディメンションで指定された座標のセル内の多次元構造に格納されます。 たとえば、「1998 年のノースウエスト地域の製品 X の売上は何でしたか」という質問には、3 つのディメンション (Product、Time、Geography) と 1 つのメジャー (Sales) が含まれます。 指定した座標 (積 X、1998、ノースウェスト) のキューブ内のセルの値は、1 つの数値である回答です。

その他の質問では、複数の値が返される場合があります。 たとえば、"1998 年の地域別のハードウェア製品の売上は、どの程度でしたか?このようなクエリは、指定された条件を満たす座標からセルのセットを返します。 クエリによって返されるセルの数は、Product ディメンションのハードウェア レベルの項目数、1998 年の 4 四半期、および Geography ディメンション内の領域の数によって異なります。 すべての集計データが集計に事前に計算されている場合、クエリの応答時間は、指定されたセルを抽出するために必要な時間にのみ依存します。 ファクト テーブルからのデータの計算や読み取りは必要ありません。

キューブ内で考えられるすべての集計を事前計算すると、すべてのクエリで可能な限り最速の応答時間が得られますが、Analysis Services では、他の事前計算済み集計からいくつかの集計値を簡単に計算できます。 さらに、可能なすべての集計を計算するには、かなりの処理時間とストレージが必要です。 そのため、ストレージ要件と、事前計算される集計の割合との間にはトレードオフがあります。 集計が事前に計算されていない場合 (0%)、キューブに必要な処理時間とストレージ領域は最小限に抑えられますが、各クエリに応答するために必要なデータをリーフ セルから取得し、各クエリに応答するためにクエリ時に集計する必要があるため、クエリの応答時間が遅くなる可能性があります。 たとえば、前に質問した質問 ("1998 年の北西地域の製品 X の売上は何でしたか") に答える 1 つの数値を返すには、何千行ものデータを読み取り、各行から Sales メジャーを提供するために使用される列の値を抽出し、合計を計算する必要があります。 さらに、そのデータを取得するために必要な時間の長さは、data-MOLAP、HOLAP、または ROLAP に対して選択されたストレージ モードによって大きく異なります。

集計の設計

Microsoft SQL Server Analysis Services には、事前計算用の集計を選択する高度なアルゴリズムが組み込まれているため、事前計算された値から他の集計をすばやく計算できます。 たとえば、集計が時間階層の月レベルに対して事前計算される場合、四半期レベルの計算では、必要に応じて迅速に計算できる 3 つの数値の集計のみが必要です。 この手法は、処理時間を節約し、クエリの応答時間への影響を最小限に抑えながら、ストレージ要件を削減します。

集計デザイン ウィザードには、クエリ応答時間とストレージ要件の間で十分なトレードオフを実現するために、アルゴリズムに対するストレージ制約とパーセンテージ制約を指定するためのオプションが用意されています。 ただし、集計デザイン ウィザードのアルゴリズムでは、考えられるすべてのクエリが等しい可能性があることを前提としています。 Usage-Based 最適化ウィザードでは、クライアント アプリケーションによって送信されたクエリを分析することで、メジャー グループの集計設計を調整できます。 ウィザードを使用してキューブの集計を調整することで、キューブに必要なストレージに大きな影響を与えることなく、頻繁なクエリに対する応答性を高め、使用頻度の低いクエリに対する応答性を低下させることができます。

集計はウィザードを使用して設計されますが、集計が設計されたパーティションが処理されるまで、実際には計算されません。 集計が作成された後、キューブの構造が変更された場合、またはキューブのソース テーブルでデータが追加または変更された場合は、通常、キューブの集計を確認し、キューブをもう一度処理する必要があります。

こちらもご覧ください

パーティションストレージモードと処理