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

前回に引き続きファクトテーブルについて解説してきます。

ファクトテーブルの粒度(Grain)

ファクトテーブルの行が表わすデータの精度はデータ粒度(grain)と呼ばれます。多次元データモデル設計においてファクトテーブルの粒度を定義することは非常に重要なポイントになります。ファクトテーブルの表すデータ粒度がそろうことで、データ分析精度の保証が可能になり、さらにデータ分析に関する誤解がなくなります。

粒度について多くのデータモデル設計者は関連するディメンションを並べることで表現します。たとえば、以下の図においては「日、販売員、商品、顧客ごとの受注ファクト」という言い方をします。

この例においては、粒度については次のことが言えます。「ある日において、顧客が同一商品を同一販売員に注文した場合、この受注データは1行にまとめられる」このデータの粒度により何が切り捨てられるかというのも重要な設計上の定義となります。データの粒度はよりまとめることで変更することが可能です。この変更は集約(aggregate)と呼ばれます。

多くの場合、データモデル設計者はファクトテーブルにデータロードする前にデータを集約することは避けます。データ生成された時のデータの粒度を出来るだけ保つことでより多くの分析に利用することがでるからです。初期のデータ分析に関する要件がそこまで細かい粒度を求めていなかったとしても、データ分析要件は変化する可能性があります。もしデータ集約を行ったデータモデルを採用した場合、将来の要件の変更で再設計が求められることになります。

このことは、以前紹介したデータウェアハウスアーキテクチャのどの場合においても「真理」ともいえるものですが、キンボールの多次元データウェアハウスアーキテクチャにおいては全社レベルのデータを多次元データモデルで保持するため粒度の定義は特に重要なものとなります。データ粒度が細かくなるほどファクトテーブルのデータは増加するため、データ集約を行う必要性が出てきます。この対応についてはまた別のトピックで解説していきます。

インモンのコーポレートインフォメーションファクトリアーキテクチャにおいては、データソースと同じ粒度のデータを全社レベルのデータとして保持しているため、制約はやや緩くなります。この場合においてデータマート（多次元データモデル）を作成する際にデータの集約が行われても情報の欠落することはありません。しかしながら、将来の要件変更が発生した場合はデータマートの再設計が必要になります。

データ粒度は実際の業務プロセスに結びついているので、データモデルとは独立したものです。たとえば、受注業務においては「受注明細レベル」というのが業務上定義される最小粒度となります。以下の図においてはこの最小粒度とは一致していませんが、変更する場合はすぐに対応可能です。

データの密度(sparsity)

ファクトテーブルのレコードは業務活動の「発生」を示しています。言い換えると、ファクトテーブルの行は全てのディメンションの値の組み合わせを保持していません。ファクトテーブルに存在する値の組み合わせは、ディメンションの組み合わせよりも通常は少なくなります。この特徴をデータの密度(sparsity)と呼びます。

受注プロセスを考えたとき、受注ファクトテーブルには受注が発生した時にレコードが生成されます。ある顧客からの注文がなければ、その顧客に関するレコードは存在しないことになりますが、これは正常なものです。ディメンションのすべての組み合わせに関するレコードがファクトテーブルに存在するとしたらそのレコード数は膨大なものになります。

この原則の例外となるファクトテーブルも存在します。これにつては別トピックで紹介します。

（ファクトテーブルの解説まだ続きます）