1

レポート/データ ウェアハウス タイプのデータベースの再構築に取り組んでいます。現在、ホテル単位のデータを含むテーブルがあります (つまり、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
4

4 に答える 4

1

[Hotel, Date] に 1 つのテーブルを配置してから、Hotel にロールアップするという設計は素晴らしいと思います。Damir が指摘しているように、読み取りクエリをシンプルに保ち、今後の集計メジャーの追加/削除を容易にします (一般的に、将来必要になる可能性のある要件を回避するように設計することはお勧めできません)。

ポンドライフも良い点です。質的要件によって、集計テーブルを維持することがどれだけ実現可能かが決まる場合があります。たとえば、システムを更新する必要がある頻度 (毎日、毎時、15 分、リアルタイムなど)、測定値の正確性 (ユーザーが必要としているのは各ホテルの業績の概観)、ソース トランザクション データの読み取りにかかるコスト、ソース トランザクション データの長期的な利用可能性 (アーカイブされているか) など。

[Hotel, StayDate] 粒度ファクト テーブルを追加し、集計を維持しない場合は、時間を節約するためにディメンションでいくつかのトリックを調べることができます。[date, date_in_last_7_days] (日付ごとに 7 つのレコード) を含む 7 日間の日付ディメンションのようなもので、過去 7 日間の直接結合と範囲のクエリで時間を節約できる場合があります。これはばかげた例かもしれませんが、それに沿ったものです。日付の次元は小さいです。

最後に、パフォーマンスを向上させる必要がある場合は、テーブルをメモリ (特にディメンションまたは非巨大なファクト テーブル) に移動するなどのハードウェアの最適化を検討してください。

于 2012-05-03T21:15:07.113 に答える
1

David が言うように、重要なクエリをより高速に実行するために、(ETL プロセス中に) いくつかの合計を事前に集計することには何の問題もありません。これは運用データベースでも一般的な手法であり、特定の集計が頻繁に使用されることがわかっている場合、データ ウェアハウスでは非常に有効です。

FactHotelRevenueSummaryしたがって、 (または既存の命名規則に一致するものであれば) という名前のテーブルHotelID, Last7DaysGross, Last28DaysGrossを、必要な数の他の集計で確実に作成できます。

私の意見では、最初に考慮すべき主なポイントは次のとおりです。

  • 観察可能なパフォーマンスの問題のため、事前集計が本当に必要です。つまり、実際の問題を解決するためにデータベースに複雑さを加えているのであって、役立つかもしれないという漠然とした感覚があるからではありません。
  • ETL プロセスには、集計されたデータが「生」データと正確に一致することを確認するためのチェックがあります。そうしないと、照会するファクト テーブルに応じて異なる数値が得られ、ユーザーの信頼に非常に悪影響を及ぼします。
于 2012-05-02T14:30:05.770 に答える
1

集計ファクト テーブルは、データ ウェアハウス内で完全に受け入れられます。

まだお持ちでない場合は、以下の本をお勧めします

DW ツールキット

ここで、Kimball は、ファクト テーブルを集計ファクト テーブルに事前に集計することは問題ないと述べていますが、ロールアップ レベルでは「ベース」ファクト テーブルと同様にする必要があると述べています。

レポート フィールドの導入は、フロント エンドのレポート ツールまたはキューブ ビューアにあるはずです。

于 2012-05-02T12:55:23.500 に答える
0

状況によりますが、通常のクエリ (過去 7 日間) は次のようになります。

select
    HotelName
  , sum(SaleAmount) as Sales
from factSale as s
join dimDate  as d on d.DateKey  = s.DateKey
join dimHotel as h on h.HotelKey = s.HotelKey 
where DaysAgo between 1 and 7
group by HotelName 
;

ただし、累計 (期間にわたる) とその変化を含むレポートがあるとします。レポートのレイアウトは次のようになります。

| Date | 1-Day | Change-1-Day % | 7-Day | Change-7-Day % | 28-Day | Change-28-Day | 90-Day | Change-90-day % |

もはやそれほど単純ではありません。そのため、標準期間の事前計算フィールドを使用して集計 (ファクト) テーブルを作成し、そのテーブルに対してクエリを実行する方がはるかに簡単です。

したがって、集計（ファクト）テーブルは次のようになります

factRunningSum
----------------------------
DateKey     integer  (PK)
HotelKey    integer  (PK)
Sale_1_Day  decimal(19,2)
Sale_7_Day  decimal(19,2)
Sale_28_Day decimal(19,2)
Sale_90_Day decimal(19,2)
于 2012-05-03T17:08:33.260 に答える