親子のEDWファクトテーブル

Question

私はKimballsアプローチに基づいてEDWを構築しています。私はソースシステム（注文/明細）の親子関係を持っています。私が持っているファクトテーブルは、ラインアイテムグレインで定義されています。ビジネスは、追加の注文レベル属性（すなわち、船便、注文タイプなど）によってこのデータをスライスしてダイスすることができるようにしたいと考えています。ファクト表にこれらの属性を直接追加するのではなく、Order Dimensionを作成する予定です。私はファクトテーブルにこれらを追加したくない場合、すべての可能な属性を追加すると、このファクトテーブルが非常に広くなります。

質問は...注文を説明する属性を持つ注文ディメンションを持つことは大丈夫ですか？このディメンションは、すべてのメジャーがファクト表に残るため、メジャーはありません。これは事実を説明する追加データです。

ありがとうございます！

Answer 1

これは非常に一般的な寸法モデリングの欠点です。

これらは、注文ラインレベルのファクトテーブルに直接追加しないでください。これらは、クエリ時にファクトテーブルをフィルタリングするために使用されるという点で、ディメンション属性です。しかし、Orderディメンションでそれらをすべてまとめると、非常に大きなディメンションになる可能性が高くなります。特に、Order＃を含める必要があり、オーダータイプや出荷方法などの分析が必要な場合。注文レベルのファクトをモデリングしていた場合、注文タイプ/船積み方法はディメンションに保持されます（おそらく、「ジャンク」ディメンションとして作成された注文詳細ディメンション内にあるかもしれませんが）。

キンボールグループの推奨アプローチは、注文レベルのファクトで、それ以外の方法で使用したディメンションを「継承」することで、「オーダー」ディメンションではなく、直接分析できるようにすることです。この例では、注文に関する興味深い情報が他の次元でも取り込まれているため、注文番号はファクト表の「縮退ディメンション」になります。オーダーの寸法アイデアの欠陥が強調表示され、推奨されるアプローチが説明されている

http://www.kimballgroup.com/2007/10/design-tip-95-patterns-to-avoid-when-modeling-headerline-item-transactions/

れる：

キンボールグループは、ここにこのについての有用な記事を持っています。