分析システムにおける多次元データモデル(3)

多次元データモデルとスタースキーマ

多次元データモデルをRDBMSで実装した形態をスタースキーマと呼びます。分析（集計）を行う軸（分析軸:dimension）はディメンションテーブルのカラムとしてまとめられていて、分析対象の数値はファクトテーブルのカラムにまとめられています。ER図で表した時その見た目が星形であることからスタースキーマと呼ばれています。

f:id:good-value:20161130225740j:plain

図ではディメンションの主キー(PK)をファクトで保持していて、ファクトテーブルとディメンションテーブルはリレーションが存在しています。業務システムに携わってきた人にとって、ディメンションテーブルは第三正規形になっていないことに気付くと思います。例えば、商品テーブルとは別にブランドは「ブランド」という別テーブルに分けて考えるかもしれません。この考えが多次元データモデル設計において多くの混乱がでるポイントでもあります。もちろん、理屈では別テーブルにしてもよいのですが、このようなデータモデルを「スノーフレーク(snow flake)と呼び分析をより複雑なものにします（この点は別トピックで解説します）。業務システムとは異なり、データの整合性を目的とはする必要がありません。あくまでもファクトテーブルの項目を集計するためのデータモデルであることから集計をしたい単位にまとまっているスタースキーマの形が基本形となります。（基本であって絶対ではないので注意）

スタースキーマにおけるクエリー

スタースキーマにおけるクエリー構文はパターン化することができます。分析システム(OLAP)は検索パターンは非定型的と説明しましたが、あくまでも「クエリーの構文（構造）」が定型化されているということなので注意してください。

分析用クエリー

以下が典型的な分析用クエリーの例となります。

f:id:good-value:20161130225812j:plain

重要なポイントは2つあります。

ファクトとディメンションの組み合わせで分析を行う。分析結果をあらかじめ作成しておくのではなく、ファクトとディメンションを組み合わせて分析結果を得ることができるということを意味します。図の例では「受注状況」というように分析対象は決めてスタースキーマを用意する必要がありますが、スタースキーマの分析は任意にできることになります。
分析の粒度はファクトデータの粒度に依存する。クエリーによってデータを集約することは任意にできますが、そもそも保持していないデータについての分析はできません。例えば、ファクトに日ごとの受注合計件数を保持している場合、品目ごとの受注の分析はできません。つまり、ファクトには出来る限り細かいデータを保持していたほうが良いことになります。（実際は物理的な制約やコストなどとの兼ね合いになります）