ディメンショナル・モデリング
VOYAGE GROUP Techlog Advent Calendar 2020 13日目
ディメンショナル・モデリングとは
ディメンショナル・モデリング
Wikipediaには以下のような説明がある。
Dimensional Modeling (DM) is a data structure technique optimized for data storage in a Data warehouse.
データウェアハウスにデータを格納するために、最適化されたデータ構造の手法。
背景
情報システムは2つの大きなカテゴリに分類される。1つはビジネスプロセスの実行支援する業務システム、もう1つはビジネスプロセスを分析支援する分析システム。それぞれ根本的に異なる目的があるため、異なる原則に基づき設計が進化してきた。
業務システムの目的は、ビジネスプロセスで発生した重要な事実や行動を記録する。一般的にはトランザクションシステムと呼ばれている。
例えば、販売システムでは、受注や出荷、返品に関する情報などを記録する。特徴として、プロセスの実行に焦点を当てているため、状況によってデータを更新したり、業務上の有用性が終了するとデータを削除する。例えば、会員のメールアドレスを変えたいとする。業務システムでは履歴を残さず、単純な上書きをされる（色んなシステムがあると思うが）。
このようなシステムをリレーショナル・データベースで実装する時に、業務システムに最適なスキーマ設計として、第3正規化が広く活用されている。
一方で、分析システムは、実行されたビジネスプロセスの評価をする。このビジネスプロセスの評価に、ディメンショナル・モデリングが非常に有効な手法である。
業務システムを運用しているとする。販売システムであれば、「12月の商品カテゴリ別の売上を見たい」、「12月に1度も売れてない商品のリスト」といった数値を見たいと言われることがあるはずである。質問者のやりたいことは、業務システムの実行しているビジネスプロセスの妥当性を評価のはずである。そして、評価の興味範囲はポジションによって違ってくることが一般的である。
業務システムは、その性質上、特定のトランザクションに焦点を当てることに重きを置いているが、分析システムは単一トランザクションから、大量のトランザクションにアクセス出来ることに重きを置いている。ディメンショナル・モデリングはそのための設計として進化してきた。
ビジネスプロセス測定のモデル化
ディメンショナル・モデリングは、ビジネスプロセスがどのように測定されるかをモデル化することにより、分析可能にする。
測定方法は周りの人に聞いてみると良い。例えば、「1月の商品カテゴリ別の粗利率は？」などである。または、表計算ソフトで作られたレポートを見るのも良い。まずは現場の測定方法を見てみよう。
測定(Measurement)と文脈(Context)
ビジネスプロセスの分析には、必ず測定と文脈がセットになっている。
「1月の売上を見たい」と聞かれたとする。文脈は1月で、測定は売上である。
「売上を見たい」人は居ない。そこには必ず何らかの文脈とセットになっている。売上という数値自体には分析価値はない。この文脈と測定がディメンショナル・モデリングの基礎となる。
ファクト(Fact) & ディメンション(Dimension)
ディメンショナル・モデリングでは、測定はファクト。文脈はディメンションと呼ばれる。
ファクトとディメンションは、先に説明した通り、身の回りですぐに見つかるはずである。例えば業務に使っているレポートなどを引っ張り出してくるのがおすすめ。
ディメンションとファクトは会話の中で出てくる
ほとんどの場合、ディメンションは、by や for の後ろに登場する。
※残念ながら、この記事を読んでいるのは日本人だと思うが、この考えはわかりやすいので紹介する。
「What are order by product category for January ?」
by や for の後ろにある単語はディメンションである傾向を加味すると January と product category はディメンションの可能性が高い。ちなみにこの例では、この2つがディメンションである。
一方でファクトは、数値化される傾向があり、様々なレベルでその数値が見られることが一般的である。この例では、 order がファクトの可能性が高い。（後で補足するが、数値であるからファクトとは断定できない
質問を整理すると ファクトの order を、 January ディメンションに絞った上で、product category ディメンションごとに巻き上げ（Roll up）したいとなる。
注意してほしいのが、数値が必ずファクトになるわけではなく、時にはディメンションになることもある。大事なのはその数値がどのように使われているかである。
例えば、「会員番号ごとの課金額を見たい」とする。会員番号も課金額も数値である。課金額は恐らく様々なレベルで指定可能だろう。月単位、年単位、アプリ単位など。そして、この質問者は課金額を会員番号ごとにまとめてほしいと言っている。つまり、課金額はファクトである。
会員番号は数値であるが、課金額と一緒に巻き上げろと言ってるわけではない。ここでは課金額の文脈を指定するために、会員番号が使われている。つまり、会員番号はディメンションである。
小難しく考えなくても、SQLに登場するWHEREなどを使ったフィルタに出てくるものが、ディメンションと判断も可能。（そこまで具体的な掘り下げが出来ていれば・・・）
グルーピング
ディメンショナル・モデリングを活用すると、実際にデータベースに格納するためのファクトとディメンションを整理が簡単になる。
ディメンションの集合は、ファクトとは独立させ、共有されることが一般的である。これらは、ある程度のグルーピングを行い1つのテーブルにまとめる。
ファクトも同様に同じレベルで利用可能な場合は、一緒にグルーピングする。
ディメンショナル・モデリングのテーブル例 は、インターネットにたくさんある。ここまで読んだ方なら、これらの例を見るだけで、言わんとしていることが分かるだろう。
まとめ
リンク先の画像を見ればわかる通り、中央にファクトを置いて、その周りにディメンションが配置された形になる。ここまでスキーマを完成させると、多くの様々な質問に答えられるデータ構造になるだろう。
ちなみに、これをリレーショナル・データベースで構築すると、スタースキーマと呼ばれ、多次元データベースで構築すると、キューブと呼ばれるものになる。
※現在では、ほとんどリレーショナル・データベースでの構築が主流になっている様に見える
ポイント
- ディメンショナル・モデリングはビジネスプロセス測定のモデル化
- ファクトとディメンションは必ずセットで登場する
- 会話の中に出てくる
スタースキーマについて
スタースキーマ Star Schema(基礎) を書きました。
Discussion