DB Stories

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

ファクトテーブル(3)

間が空いてしまいましたが、前回の続きになります。

別々にファクトテーブルを保持する設計

「ゆでガエル」となるもう一つの設計方法としてそれぞれのプロセスを個別にファクトテーブルを作成するというものがあります。受注と出荷の例における例を示します。

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

この例において、それぞれのファクトテーブルは「日付」「商品」「顧客」ディメンションを共有しています。ファクトテーブルは適切なイベントが格納されているため混乱の原因となるゼロは含まれていません。

この構成においてようやく混乱することなくそれぞれのプロセスを分析することがで来ます。受注に関する情報は受注(order_facts)、出荷に関する情報は出荷(shipment_facts)を検索することになります。もしこの2つのプロセスに別のファクトが存在する場合、適切なファクトテーブルを追加することで対応可能です。

もう一つ別の考慮すべき点が存在しています。今回ファクトはそれぞれ別のテーブルに格納されています。同時に分析を行いたい場合どうすればよいのでしょうか。この回答を検討する前に、異なるプロセスを示す二つのファクトについての問題を検討してみることにします。

(次回に続く。次回は「異なる粒度を持つファクトテーブル」です)