かなり長い間、私はHabrの住民でしたが、多次元キューブ、OLAP、MDXのテーマに関する記事を読むことができませんでしたが、このトピックは非常に興味深いものであり、毎日ますます重要になっています。
データベース、電子会計、オンラインシステムの短い開発期間中に、大量のデータが蓄積されたことは周知の事実です。 現在、興味深いのは、アーカイブの本格的な分析であり、おそらく、将来そのようなモデルの状況を予測する試みです。
一方、大企業は、数年、数か月、さらには数週間でさえ、そのような大量のデータを蓄積する可能性があるため、基本分析でさえ並外れたアプローチと厳しいハードウェア要件を必要とします。 これには、銀行取引処理システム、両替エージェント、電話オペレーターなどがあります。
データベース設計を構築するための2つの異なるアプローチ、OLTPとOLAPを誰もが知っていると思います。 最初のアプローチ（オンライントランザクション処理-リアルタイムトランザクション処理）は、リアルタイムで効率的なデータ収集を行うように設計されていますが、2番目（オンライン分析処理-リアルタイム分析処理）は、特に最も効率的な方法でデータをサンプリングおよび処理することを目的としています。
最新のOLAPキューブの主な機能と、それらが解決するタスクを分析してみましょう（Analysis Services 2005/2008が基礎として採用されています）。
- データへの迅速なアクセス
- 事前集計
- 階層
- 時間とともに働く
- 多次元データアクセス言語
- KPI（主要業績評価指標）
- 採掘日
- 階層キャッシュ
- 多言語サポート
それでは、OLAPキューブの機能をもう少し詳しく見てみましょう。
機能についてもう少し
データへの迅速なアクセス
OLAPシステムの基本は、配列のサイズに関係なく、データへの実際の高速アクセスです。 これが主な焦点であるため、データウェアハウスは通常、リレーショナルデータベースの原則とは異なる原則に基づいて構築されます。
ここでは、単純なデータをサンプリングするのにかかる時間はほんの一瞬で測定され、数秒を超えるクエリでは最適化が必要になる可能性が高いです。
事前集計
既存のデータをすばやく取得することに加えて、「最も使用頻度の高い」値を事前に集計することもできます。 たとえば、特定の製品の日次売上記録がある場合、システムは月次および四半期ごとの売上を集計することもできます 。つまり、月次または四半期ごとにデータをリクエストすると、結果がすぐに表示されます。 なぜ事前集計が必ずしも行われないのか-理論的に可能な商品/時間/などの組み合わせ 膨大な量が存在する可能性があります。つまり、集約を構築する要素と構築しない要素について明確なルールを設定する必要があります。 一般に、これらのルールと集計の実際の直接設計の説明のトピックは非常に広範囲であり、それ自体が別の記事に値します。
階層
データを分析して最終レポートを作成する際には、月が日で構成され、それ自体が四半期を形成し、都市が地域または国の一部である地域にあることを考慮する必要があるのは論理的です。 幸いなことに、OLAPキューブは最初にデータを階層および同じエンティティの他のパラメーターとの関係で表示するため、キューブ内の階層の構築と使用は非常に簡単です。
時間を扱う
データの分析は主に時間セクションで実行されるため、特に重要なのはOLAPシステムの時間です。つまり、ここで時間があるシステムを定義するだけで、年初日、月初日（年/月の初めから現在の日付までの期間）、並行期間（同じ日または月であるが昨年）
多次元データアクセス言語
MDX （多次元式）は、多次元データ構造に簡単かつ効率的にアクセスするためのクエリ言語です。 そして、それはそれをすべて言っています-以下にいくつかの例があります。
主要業績評価指標（KPI）
主要業績評価指標 -組織が戦略的目標の達成を判断するのに役立つ財務および非財務評価システム。 主要業績評価指標は、OLAPシステムで非常に簡単に定義し、レポートで使用できます。
採掘日
データマイニング （データマイニング）-実際には、大きなデータセットの隠れたパターンまたは変数間の関係の識別。
英語の「データマイニング」という用語には、ロシア語への明確な翻訳（データマイニング、データマイニング、情報の浸透、データ/情報の抽出）がないため、ほとんどの場合、オリジナルで使用されます。 最も成功した間接翻訳は、「データマイニング」（IAD）という用語と見なされます。 ただし、これは別のトピックであり、考慮すべき興味深いトピックです。
階層キャッシュ
実際、トリッキーなデータ構造と事前集計に加えて、最高のデータアクセス速度を確保するために、OLAPシステムはマルチレベルキャッシングをサポートしています。 単純なクエリのキャッシュに加えて、データウェアハウスから差し引かれたデータの一部、集計値、計算値もキャッシュされます。 したがって、OLAPキューブでの作業時間が長くなればなるほど、実際には動作が速くなります。 また、「キャッシュウォームアップ」の概念もあります。これは、特定のレポート、クエリ、またはすべてを一緒に処理するためにOLAPシステムを準備する操作です。
多言語サポート
はい、はい、はい。 少なくとも、Analysis Services 2005/2008（true、Enterprise Edition）は多言語をネイティブでサポートしています。 データの文字列パラメーターの翻訳を持っていれば十分です。言語を指定したクライアントはローカライズされたデータを受け取ります。
多次元キューブ
それでは、これらの多次元キューブは何ですか？
軸がTime、Goods、Buyerである3次元空間を想像してください。
そのようなスペースのポイントは、特定の月のバイヤーの1人が特定の製品を購入したという事実を決定します。
実際、平面（またはそのようなすべてのポイントのセット）は立方体であり、それに応じて、時間、商品、およびバイヤー-その寸法になります。
4次元以上のキューブを想像（および描画）することはもう少し難しくなりますが、本質は変わらず、最も重要なことは、OLAPシステムの場合、作業するディメンションの数は（当然の制限内で）問題ではありません。
少しのMDX
それで、MDXの魅力は何ですか-データを選択する方法ではなく、必要なものを記述する必要がある可能性が最も高いです。
例えば
SELECT
{ [Measures].[Units] } ON COLUMNS,
{ [ Time ].[June, 2009], [ Time ].[July, 2009] } ON ROWS
FROM [Sales]
WHERE ([Product].[iPhone], [Country].[Mozambik])
* This source code was highlighted with Source Code Highlighter .
SELECT
{ [Measures].[Units] } ON COLUMNS,
{ [ Time ].[June, 2009], [ Time ].[July, 2009] } ON ROWS
FROM [Sales]
WHERE ([Product].[iPhone], [Country].[Mozambik])
* This source code was highlighted with Source Code Highlighter .
SELECT
{ [Measures].[Units] } ON COLUMNS,
{ [ Time ].[June, 2009], [ Time ].[July, 2009] } ON ROWS
FROM [Sales]
WHERE ([Product].[iPhone], [Country].[Mozambik])
* This source code was highlighted with Source Code Highlighter .
つまり、6月と7月にモザンビークで販売されるiPhoneの数が欲しいです。
同時に、必要なデータの種類と、レポートでそれらをどのように表示したいかを説明します。
いいですね。
しかし、もう少し複雑です：
WITH MEMBER AverageSpend AS
[Measures].[Amount] / [Measures].[ Transaction Count ]
SELECT
{ AverageSpend } ON COLUMNS,
{ [Customer].[Sex].[Female], [Customer].[Sex].[Male] } ON ROWS
FROM [Sales]
WHERE ([Shop].[Apple])
* This source code was highlighted with Source Code Highlighter .
WITH MEMBER AverageSpend AS
[Measures].[Amount] / [Measures].[ Transaction Count ]
SELECT
{ AverageSpend } ON COLUMNS,
{ [Customer].[Sex].[Female], [Customer].[Sex].[Male] } ON ROWS
FROM [Sales]
WHERE ([Shop].[Apple])
* This source code was highlighted with Source Code Highlighter .
実際、最初に「平均購入サイズ」の計算式を決定し、Appleストアへの1回の訪問で誰（どの性別）がより多くのお金を費やしているかを比較します。
言語自体は研究と使用にとって非常に興味深いものであり、おそらく多くの議論に値するでしょう。
おわりに
実際、この記事では基本的な概念さえほとんど取り上げていません。これを「前菜」と呼びます。これは、このトピックでhabrコミュニティに興味を持ち、さらに発展させる機会です。 開発に関しては、耕作されていない広大な分野があります。私はあなたのすべての質問にお答えさせていただきます。
PSこれはOLAPに関する最初の投稿であり、Habréに関する最初の出版物です。建設的なフィードバックに非常に感謝します。
更新： SQLに転送され、新しいブログの作成が許可されるとすぐにOLAPに転送されます。