3

ウィキペディアのスノーフレーク スキーマ イメージを使用します。

http://en.wikipedia.org/wiki/File:Snowflake-schema-example.png

Dim_Product で行うように、Fact_Sales で "Brand_Id" 外部キーを使用することは理にかなっていますか? 販売/製品または製品/ブランドと同様に、販売/ブランドには多対 1 の関係がありますが、そうしない論理的な理由はありますか? Dim_Brand テーブルに直接参加することもできます。

私はおそらく何か明らかなものを見ていません。

4

3 に答える 3

2

次元モデルで作業している場合 (質問のスター/スノーフレーク スキーマ ノートは、あなたがそうであると思わせます)、BRAND_ID を販売ファクトに追加することは、パフォーマンスの観点から意味があります。 「この期間におけるブランド X の全製品の売上高」です。

また、製品ディメンションがタイプ 1 SCD で、製品のブランドが変更された場合にも役立ちます。以前の販売を「古い」ブランドのものとして保存したい場合があります。

スター/スノーフレーク レポート スキーマを構築するときは、エンティティ - リレーションシップ モデリングを行っていないことに注意してください。is-a または has-a の質問は、次元モデルには関係ありません。

于 2012-07-31T15:19:37.980 に答える
2

あなたが見ている関係のタイプは、has-a関係です。

商品にはブランドがあります。販売には製品があります。売っていた物です。しかし、セールにはブランドがありません。というか、もっといい言い方をすれば、ブランドは売れません。(あまり深く読まないでください...)

だから、いいえ、ブランドを販売に追加したくないでしょう.

于 2012-07-30T20:02:17.343 に答える
0

データをキャッシュする方法としてはいいと思いますが、正直なところ、リンクをそのまま信頼する方がよいでしょう。

その理由は、そのテーブルが何をするか、つまり店舗販売の定義が既にあるからです。店舗が販売した製品がどのブランドであるかを追加すると、そのテーブルの「トピック」または「テーマ」が曖昧になり、店舗の売上が記録されます。

何らかの方法で、さまざまなブランドで販売できる製品があった場合 (パッケージがどのように異なる個性を持つことができるかを知っていれば...)、ある程度は理にかなっていますが、より合理的な解決策は次に、各製品に独自の SKU コードを付けます。

于 2012-07-30T19:54:59.077 に答える