DB Stories

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

ファクトテーブル(5)

個別のファクトテーブルを利用した設計

二つのファクトが異なる粒度を持つとき、これらは別々のプロセスであると言えます。これまで見てきたように、このような場合に一つのファクトテーブルを利用した設計を行った場合、どちらか一つに着目した分析を行う際にトラブルのもととなることを見てきました。ここではファクトをそれぞれ別のテーブルとして保持した場合について検討します。以下の図がその例です。

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

今まで説明してきたことを踏まえて説明を行いたいためファクト表にはさらなる属性(列)を追加しています。ファクトに追加されている項目は冗長なものとなっています。受注プロセエスは受注金額(order dollars)、出荷プロセスは原価(cost)と利益(revenue)が含まれています。このファクトに追加した項目がもたらす混乱について考えていきます。

受注の最も粒度の細かい分析を行うために「受注番号(order_id)」「受注明細行(order_line)」という非正規化ディメンション(degenerate dimension)が追加されています。(非正規化ディメンションについてはこちらを参照してください)この例において、出荷は受注と紐づいているため、出荷に対しても同じことが言えます。出荷ファクトは「出荷番号(shipment_id)」「出荷明細行(shipment_line)という非正規化ディメンションをもっています。出荷ファクトは日付に関する二つの項目を持っていることに注意が必要です。1つが受注日(date_key_order)、2つ目が(day_key_shipment)です。この設計手法については後程取り上げます。

ここまでに説明してきたように、一つのファクトテーブルが二つの異なるプロセスを保持している場合の特徴を2つ備えています。

  • 二つの事象は同時に発生しない。
  • これらの事象はまったく別の粒度で分析利用される。

これらの違いは、通常は最小粒度の分析をする業務要件を確認することではっきりとします。いくつかの場合において、ファクトは同時に発生するが、異なる粒度を持つことがあります。今回の例において、集計を注文ヘッダについてのみ行い、注文明細については行わないというような場合、別々のファクトテーブルに保持するほうが望ましくなります。

(続く) 次回は、「複数のファクトテーブルを持つ場合における分析方法」についてです。