ファクトテーブル

前回までにディメンションテーブルについて解説してきました。今回からはファクトテーブルについて解説していきます。

ファクトテーブルの特徴

ファクトテーブルはビジネスプロセスそのものを示すもので、適切な単位でデータを保持している必要があります。ファクトテーブルの持つ情報のレベル（つまりファクトテーブルの情報単位）を「粒度(grain)」と呼びます。重要なポイントは、それぞれのファクトテーブルの粒度はそろえる必要があって、混在させない必要があります。ファクトテーブルはディメンションテーブルのすべての組み合わせを持ってはいません。この特徴をデータの密度(sparsity)と呼ぶことにします。ファクトテーブルに本来ディメンションとして扱うべきデータを保持すること(degenerate dimensions)もあります。これら全てはファクトテーブルの粒度によって決まります。

ファクトテーブルと業務プロセス

ファクトテーブルは業務プロセスの記録のようなもので業務プロセス分析のエンジンともいえるものです。ファクトテーブルはディメンションテーブルの外部参照キーを含んでいます。ディメンションテーブルを「幅広い」（列数が多い）とするなら、ファクトテーブルは「深い」（レコード数が多い）ということができます。通常、ファクトテーブルはディメンションテーブルのよりはるかに多くのレコード数が格納されます。しかし、幸いなことにファクトテーブルのレコードはコンパクトなものであるという特徴があります。ファクトテーブルのもつ外部参照キー列は数値型であり、ファクト列そのものも数値型となります。このコンパクトという特徴は極端なストレージ要件がなくても扱うことができるという特徴があります。ディメンションテーブルは列数が非常に多く、ほとんどの列は文字列型ですが、レコード数は比較的少ないという特徴があります。

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

ファクトの記録

業務プロセスの記録という点で、ファクトテーブルは他から導出できるデータであっても、関連するすべての出来事を保持するべきです。また、ファクトテーブルの情報からはデータをまとめる（集約）することが可能です。この集約可能な特徴のことを加算性(additivity)と言います。

全ての記録

多次元データモデル設計において、すべてのファクトテーブルは業務プロセスの記録を表すものになります。分析のためのデータを全て包含するものである必要があり、データは冗長性を含むこともあります。冗長性はありますが明示的にデータを保持することで、ツールやクエリーに依存することのない分析を可能にすることができることになります。ファクトテーブルの項目は数値型のため、追加の列を保持すること自体は低コストで対応可能です。以下の図に示す例において、ファクトとしては以下の項目を含んでいます。

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

注文数(quantitiy_ordered)
注文金額(order_dollars)
注文原価(cost_dollars)
注文利益(margin_dollars)

ここで、「注文利益＝注文金額ー注文原価」で求められることができるのがポイントです。設計時にこの項目については計算可能であることから、BIツールの論理レイヤで保持する設計方針として、ファクトテーブルに保持しないというようにする場合があります。この方針は次の理由で適切ではありません。

データの整合性管理データを利用するBIツールにおいて値を計算する場合、データの計算（生成）を一か所で行うという明確なポリシーを持つことが出来なくなります。ETLプロセスにおいて、値を計算してデータを保持することでデータの整合性を保つことができます。
BIツールからの独立性データをBIツールで保持する場合、データとツールが依存することになります。どのツールを用いてもデータが同じということになるためツールへの依存性がありません。同様に、DBMSのviewを都度作成することも好ましくありません。

もう一つの、よくあるミスとしては、ファクトテールに合計数量ではなく単位数量(unit amounts)を持つという例があります。単位数量はディメンションテーブルに保持すべきもので、ファクトに必要なものは合計数量です

非加算性のファクト

ファクトテーブルはある一定粒度のデータを保持することになりますが、そのことはその粒度までデータが集約（サマリ）されることを意味します。それぞれのファクトを集約してサマリを行うことを加算性(additivity)と呼びます。たとえば先ほどの図にいおいては[quantity_ordered][order_dollars][cost_dollars][margin_dollars]がそれに相当します。これらの項目はディメンションに定義される全ての分析軸にて集約可能となることを意味します。

全ての値(列)において加算性が備わっているわけではありません。業務上、多く利用される「割合（パーセンテージ）」は加算性を持ちません。当然ですが、利益率のパーセントを足してもその値は利益率を表すものではありません。

このことについては次のように考えます。利益率は利益金額と注文金額の割合を示すものです。また利益金額、注文金額は完全に加算性を持つことからファクトテーブル内に保持されるべきものです。加算性を持たない利益率はファクトテーブルに存在する利益金額と注文金額の合計から求めるます。この金額はBIツールにおいて計算されることになります。

上記のように、この非加算性のファクトはファクトテーブルに保持するべきではないと言えますが、業務上の重要性を考えると算出の仕方は他から見えるようにしておくのが望ましいと言えます。つまりスキーマ設計時に定義（ドキュメント化）しておく必要があります。

（次回につづく）