レポート/データ ウェアハウス タイプのデータベースの再構築に取り組んでいます。現在、ホテル単位のデータを含むテーブルがあります (つまり、HotelID と、Last7DaysGross、Last28DaysXXX などのメジャーを含む多くのメジャー)。
Hotel/StayDate 粒度にあるファクト テーブルに移動するのが最善だと考えています。ただし、HotelID でグループ化し、Last7DaysGross などの日付関連のメジャーを含めると、非常にうまく機能する必要があります。
ここではどのような構造が機能しますか? インデックス付きビューには複数の制限 (サブクエリがないなど) があるため、期待どおりに使用できないと思います。適切なパフォーマンスを得るには、新しいテーブルを作成する必要がありますか?ホテル レベル (HotelStayDate レベルから集計?) これは、ユーザーが最も頻繁にクエリを実行するレベルです。Last7DaysGross などのフィールドを実際に作成する必要がありますか? それは良いデザインのようには思えませんが、別のデザインを思いつくのに苦労しています.
申し訳ありませんが、この質問は少しあいまいです。私がここで見逃しているものは他にありますか?これらの種類の日付関連の測定は、ほとんどの場合、フロントエンド レベル (つまり、Business Objects などのツール) で行われることを私は知っています。ただし、このプロジェクトでは、データベースにそれが必要です。
ありがとう、シルビア
編集:
思慮深いコメントをありがとう!日付の次元を拡張するという彼の考えのために、私は David Marwick の回答を受け入れました。その考えは頭に浮かびませんでした。試してみる価値は十分にありそうです。
David Marwick の考えを少し拡張して、このアイデアを思いつきました。私はそれが実際にどのように機能するかを試してみるかもしれません:
DateDimension
DateKey
DateKeyBeginLast28Days
DateKeyEndLast28Days
Fact
DateKey
GrossTransactions
次に、クエリを実行する場合:
Select
DateKey
,SumLast28Day = sum(GrossTransaction)
from Fact
join DateDimension
on Fact.DateKey >= DateDimension.DateKeyBeginLast28Days
and Fact.DateKey <= DateDimension.DateKeyEndLast28Days
group by DateKey