2017-04-23 11 views
0

開始するには、スタースキーマとスノーフレークスキーマとを区別して説明します。しかし、スノーフレークスキーマを作成するためにテーブルを正規化しようとするのに問題があります。 添付された画像は、スター・スキーマ enter image description hereデータウェアハウス - スノーフレークスキーマの正規化

である私はdimcustomerのために別の薄暗いテーブルを作成しようとしたが、私は、テーブルに名前を付けることができるものを確認していません。どうか助けていただければ幸いです。

スノーフレークスキーマ enter image description here

+0

あなたは何を求めているのですか? DimCustomerの別名についてなぜあなたは別の名前をしたいですか?それとも、顧客を正規化されたテーブルに分割して、それらをスノーフレークにすることを探していることでしょうか?後者の場合は、お互いにリンクしてからDimCustomerにリンクする別々のDimCityテーブルとDimCountryRegionテーブルを作成できます。それはもっとスノーフレークだけど、私はそれをお勧めしません。 – Rich

+0

私はdimCityでダイアグラムを追加し、それをdimCustomerに接続しました。しかし、私は正規化することができる他のテーブルを確認していません – AdrianAndrews

+0

今日は日付が現在の日付であるため、確かに1か月のテーブルと1年のテーブルを作ることができます。しかし、なぜ? – Rich

答えて

1

あなたのスタースキーマは良いですが、スノーフレーク・スキーマにそれをnormilizeません。

これは、リレーショナルデータベースに強いバックグラウンドを持つ人が主張している典型的なミスです。彼らはしばしば非正規化された次元を「非効率的」として認識し、正規化によってそれらを「修正」しようとします。彼らが間違っているのは、ディメンションモデルとOLTPデータベースの効率基準(クエリ速度とストレージ効率)が異なることです。

通常、スノーフレークスキーマは不要で反生産的です。設計が複雑になり、モデルのパフォーマンスに悪影響を与えます。具体的には、ファクトテーブル間のディメンションを異なる粒度で共有する必要がある場合にのみ、スノーフレーク構造を使用します。