DB Stories

DBに関する過去、現在、未来の話題をプロフェッショナルの視点で紹介

スタースキーマとキューブ(11)

キューブ

多次元データモデルはリレーショナルデータベースだけに適用されるものでありません。多次元データベース(MDB [Multidimensional database])においてはキューブ(cube)と呼ばれるフォーマットでデータを保持します。キューブ自体の基本的な考え方は、「インタラクティブな分析を行うために、ディメンションとファクトの組み合わせを事前に集計しておく」というものです。

多次元データベースとリレーショナルデータベース

多次元データベースの一番の特徴はレスポンスの良さです。キューブを利用することで、分析軸の変更(追加や削除)、見せ方の変更といったことが即座に(画面上でインタラクティブに)行うことができます。このインタラクティブなデータ分析をオンラインデータ分析(OLAP [Online Analytical Processing])と呼ばれます。キューブを利用することでレスポンス良く「スライス」「ダイス」「ドリルアップ」「ドリルダウン」といった分析操作を行うことができます。一方、スタースキーマはRDBに対しするクエリーの実行とそのレスポンスを待つという方法になります。つまり、分析軸の変更や見せ方の変更については全て新しいクエリーが実行されることになります。

もう一つの多次元データベースの利点としてはSQLに依存しないという点にあります。多次元データベースはファクトとディメンションのデータ格納に特化していることからSQLで実行することのできないデータ分析操作が可能になります。MDBはSQLで取り入れられる以前から、データ分析に必要な合計値、ランキング値、その他の統計学的操作が可能でした。さらに、スタースキーマではブリッジテーブルという特殊なデータ設計をしないとできない高度な階層問い合わせも利用可能です。

もちろん、これらの能力というのはコスト見合いで考える必要があります。ティメンション(分析軸)とそこに含まれるデータ種の増加と共に事前計算しなくては行けない値の組み合わせは増加することになります。このことはキューブを設計するうえでのスケーラビリティの制約になることになります。

多次元データベースのデータはMDX(多次元データベースクエリ言語)という標準的なインターフェースを使ってアクセスしますが、多くは製品固有の機能を利用することになります。さらにMDXを利用自体がそれほどスタンダードな方法にはなっていません。一方、SQLを理解して利用する技術者は多く存在しツールも多く存在しいるという事実はMDXにとっては不利な点ともいえます。次の図はこれらの違いをまとめたものです。

f:id:good-value:20170328000007p:plain

【筆者コメント】 MDX自体は以下が参考になります。ただ実はMDX自体の利用シーンは減少してきています。キューブを利用したOLAPアーキテクチャ(MOLAP[Multi-dimensional OLAP]と呼びます)の採用が減ってきているのがその理由です。その背景としてHW技術の進歩によりRDB上のスタースキーマをある程度高速に利用できるようになったというものがあげられます。RDBを利用するOLAPはROLAP[Relational ORAP]と呼ばれます。

codezine.jp

MDB構成のバリエーション

キューブを用いた多次元データベース(MDB)のアーキテクチャ上は多くの種類が存在しています。例えば、

  • キューブが多次元データベースサーバで稼働するもの(MDBがキューブを元に作成されている)
  • OLAPツールという位置づけのBIアプリケーションが独自のキューブを保持するもの
  • RDB上にキューブを保持して、ある程度の「スライス」「ダイス」といった操作を可能にするもの(このタイプはROLAPと呼ばれます)

MDBととRDBの区分けは徐々になくなってきています。RDBであっても多次元データを扱うための技術を取り入れているものもあります。もう一つの技術としてはSQLを拡張することでキューブの自動作成、SQLとMDX相互の自動言語変換というように、RDB上で多次元データベースを利用可能とするものがあります。(具体的にはアプリケーションはRDBにSQLでクエリー発行をしているが、内部でキューブを作成しMDXにクエリー変換している)これらのハイブリッドモデルによりデータベース管理者がキューブ作成を管理しやすくなりスケーラビリティの向上が図られています。

【筆者コメント】