2

スター スキーマを使用してデータ ウェアハウスを作成しています。すべてのディメンション テーブルを正常に構築できましたが、ファクト テーブルで行き詰まっています。Sales テーブルを Fact テーブルとして作成する必要があります。SalesKey、OrderKey、ProductKey などがあります。すべての注文は販売であるため、各注文には一意の SalesKey がありますが、各販売には複数の製品があります。

このテーブルを作成するのに最適なものは何ですか?

みたいなの作ればいいのかな

SalesKey OrderKey ProductKey
-------- -------- ----------
s1         o1        p1
s1         o1        p2
s2         o2        p1
4

2 に答える 2

2

一般に、スタースキーマを設計するときは、ファクト レコードごとに各ディメンションを単一の値にすることをお勧めします (つまり、ファクトとディメンションの間に 1:M の関係があります)。

コツは、1 つの注文 (= 1 販売) に多くの注文行を含めることができるように、ORDER-LINE ディメンションを含めることです。各注文行には 1 つの製品が含まれます。

したがって、基本的には、ファクトテーブルが 1:M の関係で ORDER-LINE ディメンションにリンクされているスノーフレーク スキーマを使用します。ORDER-LINE ディメンションは、M:1 の関係で PRODUCT ディメンションにリンクされます。

これにより、Salesfact ディメンションと PRODUCT ディメンションの間に M:M 関係があるという元の問題が、ORDER-LINE ディメンションをブリッジ テーブルとして使用することで解決されました。

于 2011-11-23T12:56:08.627 に答える
2

注文アイテム/ラインは扱いにくい場合があることを付け加えておきます。それを処理する方法は複数あります。

ファクト テーブルに列「注文明細」または「取引管理 ID」を追加します。

これにより、ファクトに SalesKey、OrderKey、ProductKey のすべてを含めることができ、"OrderLineItem" 縮退ディメンション キー (多くの場合、ソース システムからのトランザクション管理番号または注文明細番号) を使用できます。

この方法を使用する際に発生する可能性のある問題の 1 つは、注文行に存在しない注文レベルのメジャー (税金、レジ ID など) がある場合です。Kimball 氏が推奨するアプローチは、可能であれば、これらの測定値をオーダー ラインに分配することです。

縮退次元に関する Kimball による優れた記事は次のとおりです 。

于 2011-11-28T11:54:37.347 に答える