要求されたレポートで同じディメンション(同じ細分性)に関する要約情報が必要な場合は、基礎データは別のファクト表に格納されます。間にディメンションを持つ複数のファクト表を結合する
たとえば、給与と経費が異なるファクト表に記録されている場合、給与総額と各従業員ごとに報告された総経費を示すレポート。または、1つのファクトテーブルからの売上と別のファクトテーブルからの受取が発生した場合に、1社が販売した各SKUの1か月あたりの総販売数と1か月あたりの在庫数を示すレポート。
単純にこの問題を解決するのは簡単です。単純に両方のファクトテーブルを並列にクエリして集計し、集計結果をデータウェアハウスまたはクライアントアプリケーションで結合します。
しかし、私はこの問題について他の考え方にも興味があります。どのように他の人がそれを解決したのですか?私は、データウェアハウスのスキーマとデザインの両方について疑問に思っています。また、上記の例のようなレポートを作成するためのクライアントツールのデザインを親しみやすくしています。
また、この「ディメンション・サンドイッチ」ユースケースは、標準的なデータウェアハウジング用語で名前を持っていますか?はいの場合は、Googleを介して簡単に調査することができます。
私たちはSQL Serverを使用していますが、私が今質問している質問は、プラットフォームに中立なところがうまくいきます。
[統合ファクトテーブル](http://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/consolidated-fact-table/)を検討することもできます。 )。 –
連結ファクトテーブルは、有用なアクセサリデータまたは派生データを導入する手段です。たとえば、在庫と販売データを使用して在庫ターンを計算する方法は数多くありますが、ETLフェーズで使用する列を準備して、ビジネスユーザーに同じ計算を使用させることが賢明です(必ずしもそうとは限りません)。 – momobo
統合されたファクトテーブルはいくつかのユースケースでは正常に機能しますが、DWのビジネスユースケースの多くは単純なディメンション(専門家による計算が重要な上のインベントリケースと異なります)を持ち、アドホックなフィルタリングと集約をサポートする必要があります結果が定義される前に –