DB Stories

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

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

データ分析と多次元データモデル

業務システムがトランザクションの一つ一つを扱うのに対して、分析システムはそれをまとまった単位で扱うことになります。そのまとまったデータをある目的に応じて集計を行います。この目的というのが重要で、単に集計するだけでは全くの意味を持たないことになります。たとえば「販売金額は10,000円であった」というだけでは、一つの商品なのか複数の商品なのか、一つの取引なのかある期間における取引なのかということが分からないことには意味がありません。つまり「集計」と「目的」は常にセットに考える必要があります。分析システムにおけるある目的に基づく集計を行うためのデータモデルが多次元データモデルでとなります。 業務システムにおけるデータモデルとして第三正規形(3NF)が利用されるのと同じく、分析システムにおいて集計を行うためのデータモデルとなります。

ファクトとディメンション

多次元データモデルの構成要素はファクトとディメンションの2つ存在しています。集計の元データとなるの「ファクト」と、集計の目的を示す「ディメンション」です。

  • 集計をしたいとい要件において「~ごとに」という形であらわされるのがディメンションになります。例えば、「1月の商品カテゴリごとの注文額をみたい」といおう要望においては、商品カテゴリごとに数値を分割して表したいと言えます。すなわちこれが分析の目的と言え、ディメンションに相当することになります。
  • 集計の元データになるのファクトになります。集計を行うのが前提となるため数値としてあらわされるのがほとんどとなります。顧客年齢、商品番号、商品単価といった数値データについては集計する目的が存在していないためこれはディメンションと言えます。

ファクトとディメンションのつくり方

ファクトとディメンションの関係を具体的に見ていきたいと思います。分析を行うためのデータモデル(多次元データモデル)の構成要素であるファクトとディメンションなので、具体的にどう分析したいのかというのをイメージを起点に考えていくことになります。業務システムにおける第三正規形のデータモデルを起点に実現したいことを考えるのとは全く逆のアプローチになります。 例として下図のような2015年1月における受注レポートを利用します。

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

ファクトとディメンションの関係は以下のようになります。ファクトは元データであり、ファクトを「抽出する条件」と「集約する項目」がディメンションになります。

  • ディメンション
  • 抽出条件:データを抽出(絞り込む)ために利用
  • 「西地区」「2015年1月」
  • 集計項目:ファクトデータを集約する単位として利用。レポートのタイトルにもなる。
  • 「Category」「Product」「SKU」
  • ファクト
  • 集計値:個々の数値データを集計したもの
  • 「Quantitiy Sold」「Cost」「Order Dollars」

さらに、受注業務全体におけるディメンションを全て抜き出してみることにします。

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

全てのファクトの項目はディメンション項目によって集計(集約)する可能性があると言えます。このディメンション項目はいくつかに分類することができます。たとえば、商品(名)と商品説明は、SKUに関連しています。販売担当者名は販売担当者IDに関連していて、商品はブランドに関連します。このように関連するものを一つにまとめると以下のようになります。

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

この図において、ファクトのデータを「~ごとに」集計を行うであろうことが推測できます。この図の関係性を多次元データモデル(Multi Dimensional Data Modelと言います(集計項目であるディメンションから多次元という訳語になっています)。この多次元データモデルにおける関係性は直観的な形をしていて専門家でない人にとっても理解しやすい形になっています。この専門家でない人にとっても理解しやすいというのは非常に重要です。多くの場合、何で分析(つまり集計)したいかというのは業務的には決まっているので、多次元データモデルを一度作るとあとはディメンションを組み合わせるだけの利用が可能となることから多くの利用者がそれを自由に分析できることにつながります。