web-dev-qa-db-ja.com

スタースキーマで、ディメンションに日付属性がある場合はどうすればよいですか？

私は次元モデルとスタースキーマについて学ぼうとしています。たとえば、日付、顧客、店舗、およびプロモーション（クーポンのような販売促進の場合など）の4つのディメンションを持つ小売店での総売上を記録するSalesファクトテーブルがあるとします。 （以下の疑似スキーマ）。

「過去10年間の第2四半期の土曜日」のように見える複雑な条件によってファクトを簡単にフィルターできるように、日付ディメンションに曜日などの属性を事前入力するアイデアが本当に気に入っています。

ここで、プロモーションディメンションに、プロモーションの開始と終了を示すStart_Date属性とEnd_Date属性を設定するとします。どうすればよいですか？私はそれについて考えました、そして、理想より少ない3つの解決策を思い付くことができます：

1）Start_DateおよびEnd_Dateを通常のアトミック属性（ISO8601文字列またはDBのdatetimeオブジェクト）にして、制限されたフィルタリングのみを許可します。

2）Start_DateおよびEnd_Dateの外部キーをDateテーブルに作成し、スタースキーマを壊しますが、完全なDateディメンションと同じフィルタリング機能を許可します。

3）Start_Date_Day_of_Week、Start_Date_Quarterなどの属性を含め、スタースキーマを維持しながら、ディメンションサイズを増やし、基本的にプロモーションディメンションの日付ディメンションの構造を複製します。

Sales Table
-----------
Date key      (FK to Dates table)
Promotion key (FK to Promotions)
Customer key  (FK to Customers table)
Store key     (FK to Stores)
Sales Amount  

Date Table
----------
Date Key (PK)
Month
Day of week
Day of month
Day of Quarter
Day of year
Holiday?
Quarter
Day since Epoch
Month since Epoch
etc...

Promotion Table
---------------
Promotion Key (PK)
Type (Coupon code, 2-for-1 sale, 50% off, etc)
Start_Date
End_Date

Customer Table
--------------
Customer Key (PK)
Name 
Age
Sex
etc...

Stores Table
------------
Store Key (PK)
Address
City State
Zip
etc...
data-warehousedimension
4
user1481

元の質問と元のポスターが非アクティブであることはわかっていますが、Googleの検索で見つかったので、自分の考えを追加したいと思いました。

1）Start_DateおよびEnd_Dateを通常のアトミック属性（ISO8601文字列またはDBのdatetimeオブジェクト）にして、制限されたフィルタリングのみを許可します。

日付属性を既存のディメンションに入れることは、主な目的が情報提供である場合（つまり、プロモーションの開始日/終了日をレポートに含めることを望む場合）に意味があります。ただし、意図がフィルタリングである場合、アトミック日付属性でのフィルタリングは比較的困難になります。

2）Start_DateおよびEnd_Dateの外部キーをDateテーブルに作成し、スタースキーマを壊しますが、完全なDateディメンションと同じフィルタリング機能を許可します。

このタイプのスノーフレークはアウトリガーディメンションと呼ばれ、スタースキーマでは許容できます。 （ http://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/outrigger-dimension/ ）。これはあなたがしたことだと思います。

3）Start_Date_Day_of_Week、Start_Date_Quarterなどの属性を含め、スタースキーマを維持しながら、ディメンションサイズを増やし、基本的にプロモーションディメンションの日付ディメンションの構造を複製します。

複製は煩雑になります（特に、同じディメンションに複数の日付があるため、複数の日付フィールドを維持します）。また、将来のメンテナンスがより複雑になります。日付ディメンションを変更する場合は、その変更を数十か所で繰り返す必要があります（またはユーザーエクスペリエンスに一貫性がありません）。

反対に、これは、たとえば、人々がプロモーションをフィルターにかけたいと思っている方法が1つまたは2つしかない場合に有効なオプションになる可能性があります。たとえば、エンドユーザーがアクティブなプロモーションまたは「過去30日間でクローズされたプロモーション」にすばやくフィルターをかけたいことがわかっている場合、完全な日付ディメンションにリンクするのではなく、それを計算してプロモーションディメンションの特定の属性として追加できます。プロモーションの開始日と終了日。 （ただし、1つまたは2つの属性として開始されるものは、エンドユーザーがフィルターしたい期間をますます見つけるにつれて、急速に拡大する可能性があります。）

プロモーションの開始日/終了日でフィルターする予定の詳細に応じて、4番目と5番目のオプションがあります。

4）販売表のキーとしてプロモーションの開始日/終了日フィールドを追加します。

プロモーションが使用されるたびに同じ情報を保存するので、一見すると、多くの重複のように感じられます。しかし、非正規化はスタースキーマにおけるゲームの名前です。プロモーションの開始日または終了日（つまり、プロモーションの開始日が先月であった販売）に基づいて販売にフィルターをかけることが目標である場合は、アウトリガーディメンションよりもこれをお勧めします。

5）プロモーション用の新しいファクトレスファクトテーブルを作成します

売上高をフィルタリングすることを目的としない場合は、事実のないファクトテーブルがより良いソリューションになる可能性があります。これにより、たとえば、（関連付けられた販売の有無に関係なく）特定の日に有効だったプロモーションの数がわかります。詳細： http://www.kimballgroup.com/2011/04/design-tip-133-factless-fact-tables-for-simplification/

私の次元モデリングの経験では、最良のソリューションは、エンドユーザーが何を達成しようとしているかに依存していることがよくあります。あなた（または彼ら）が彼らが何を達成しようとしているのかまだわからない場合（つまり、プロモーションに開始日と終了日があることを知っている場合）、オプション1から始めます。これにより、あまり作業をせずに情報をモデルに配置できます。

後でエンドユーザーが売上を開始日と終了日でフィルタリングしようとしている場合は、そのときに＃2または＃4を検討します。エンドユーザーが販売とは関係なくプロモーションを分析しようとしている場合は、＃5を検討します。

2
Leonard

オプション＃2を使用することをお勧めします。日付はスタースキーマの世界では特別なケースです。その次元に参加することで得られるメリットは、スノーフレーキングをはるかに上回り、やりたいことになります。

オプション＃1は、最初にデータウェアハウスを使用することによる分析上の利点の多くを失うことを意味します。たとえば、顧客が年齢に基づいてパターンがどのように異なるかを探すようなことを簡単に行うことはできません。

オプション＃3は、ディメンションテーブルの巨大な爆発を伴います。理由もなく、多くの追加の属性を持ち運びます。通常、これは悪いことではありません。スタースキーマの目的は、次元構造を非正規化して単純化することですが、これは、非常に多くの属性で頻繁に実行するまれなケースです。ディメンションの行を更新するたびに、それらの属性もすべて更新する必要がある場合があります。これは、ビジネスユーザーがモデルを理解しやすくなることなく、増分次元の負荷に悪影響を及ぼします。さらに悪いことに、ディメンションの各日付に70以上の日付関連の属性（標準の年、さまざまな種類の会計年度など）がある場合、目が眩むことがあります。 140以上の日付関連の列の真ん中に実際のディメンション属性を見つけるのは、はるかに難しくなります。

夜の睡眠を助けるために、2つのグラフィカルモデルを作成することもできます。1つは実際のデータモデルで、もう1つは「日付のない」データモデルです。 「データレス」モデルは、他のディメンションと日付の間の接続を取り除き、より自然なスタースキーマのように見えます。

1
Kevin Feasel