スタースキーマとキューブ(12)
キューブとデータウェアハウス
で紹介した3つのデータウェアハウスアーキテクチャにおいてキューブを利用することができます。 図を再掲しておきます。
1. 多次元データウェアハウスにおける全社レベルでの多次元モデル（スタースキーマ）の代替として
この場合、キューブの採用についてはデータウェアハウスがスケーラビリティの制約を受けることなります。キューブは値を事前計算して保持するという使われ方をするため、キューブの項目数（粒度）は現実的に多く保持することはできません。また、データをETLにより取り込む段階で集約が行われるため、詳細データはここでロストすることになります。利点としてはもちろん高速な分析が可能になるというものです。
2. 目的別レベルデータのスタースキーマの補完するものとして利用
目的別レベルデータのデータモデルはパッケージ製品を利用して個別の要素に特化したキューブを作成する場合もあります。そのため製品ベンダーはキューブを利用した分析データを事前作成しています。 RDBデータを代替するという考えではなく、キューブはRDBを補完するという考え方もあります。この場合、データウェアハウスアーキテクチャの「分析層」で利用されています。典型的な実装方法としては全てのデータ（アトミックデータ）を保持するストレージとしてスタースキーマを利用し、一方パフォーマンスについてはキューブを利用するという形で対応を行っています。
このスタースキーマとキューブの共存について２つの考え方があります。
- スタースキーマをアトミックデータを格納するために利用し、キューブをデータマートとして利用する（スタースキーマとキューブの分業）
- スタースキーマをデータウェアハウスとデータマートを保持するために利用し、より高速な分析のためにキューブを利用（スタースキーマが中心、キューブは補完）
どちらの構成においてもキューブはスキーマ間の整合性や、集約粒度といった問題は考慮する必要があります（これは後で説明します）
これからのデータウェアハウス
今までの15年を見てきて、これからの15年というものは大きな変動があるはずです。データウェアハウス市場において、多次元デーモデルのデータ保持方法(RDB/Cube)の区別をつかない方向に向かっています。どのデータベースアーキテクチャにおいてリレーショナルテーブル、キューブ、その他、何か別のものであっても最終的には多次元データモデルに収束すると考えます。ユーザーとアプリケーションはSQL、MDXなどを自由に選択してアクセス出来るようになります。クエリーはストレージ技術（RDB/Cube)に応じて自動で変換されることになるでしょう。未来がそのようになるまで、スタースキーマとしての設計をし、SQLを利用してアクセスし、キューブを利用してOLAPとしての性能を達成するという進め方は続くはずです。
（「スタースキーマとキューブ」終わり）
