1

時間ディメンション用に 2 つのテーブルがあります

日付 (日ごとに一意の行)
時刻 (1 日の分ごとに一意の行)

このスキーマを考えると、過去 X 時間 (X は 0 より大きい任意の数) のファクトを取得したい場合、クエリはどのようになるでしょうか。

開始時刻と終了時刻が 1 年の 2 つの異なる日になると、事態はややこしくなり始めます。

編集: ファクト テーブルにタイム スタンプ列がありません

4

3 に答える 3

2

ファクト テーブルには、1 日の境界を越えて発生する奇妙な by-time クエリを回避するために、元のタイムスタンプがあります (そして持つべきです)。奇妙なのは、WHERE 句にある種の複雑な日時関数があることを意味します。

ほとんどの DW では、このようなタイプのクエリは非常にまれですが、データを DW にストリーミングし、同時にレポートに使用しているようです。

だから私は提案します：

  1. ファクト テーブルに完全なタイムスタンプを導入します。

  2. 古いレコードについては、日付と時刻のキーからタイムスタンプを再作成します。

DW クエリは、WHERE 句に関数を持たないことがすべてです。関数を使用する必要がある場合は、それがSARGABLEであることを確認してください。

于 2011-08-17T12:26:44.040 に答える
0

Start DateとのEnd Date列を変換して入力することで、おそらくより良いサービスが得られるでしょうTIMESTAMP。

テーブルをスライスするには、適切なinterval BETWEEN Start Date AND End Date. オラクルでは、またはintervalの行に沿ったものになりますSYSDATE - (4/24)SYSDATE - NUMTODSINTERVAL(4, 'HOUR')

これは次のように書き換えることもできます。

Start Date <= (SYSDATE - (4/24)) AND End Date >= (SYSDATE - (4/24))
于 2011-08-18T19:48:20.540 に答える
0

あなたが持っている現在のスキーマを考えると、検索基準を満たす時間ディメンション テーブルから適切な時間 ID を取得し、ファクト テーブルで一致する行を検索する必要があるように思えます。時間ディメンションの粒度に応じて、次のいずれかを実行した場合のパフォーマンスを確認する必要がある場合があります (SQL Server の例)。

  1. サブセレクト:

    SELECT X FROM FOO WHERE TIMEID IN (SELECT ID FROM DIMTIME WHERE HOUR >= DATEPART(HOUR, CURRENT_TIMESTAMP()) AND DATEID IN (SELECT ID FROM DIMDATE WHERE DATE = GETDATE())

  2. 内部結合:

    SELECT X FROM FOO INNER JOIN DIMTIME ON TIMEID = DIMTIME.ID WHERE HOUR >= DATEPART(HOUR, CURRENT_TIMESTAMP()) INNER JOIN DIMDATE ON DATEID = DIMDATE.ID WHERE DATE = GETDATE()

これらはどちらも本当に魅力的なオプションではありません。

ロールアップ分析を目的としていて、必ずしも "最後の X" 分析を目的としていないキューブに対してクエリを実行している可能性があると考えたことはありますか?

これが「ロールアップ」キューブでない場合は、ファクト テーブルをより適切なキーで再スタンプする必要があるという点で、他の投稿者に同意します。実際に時間外に頻繁に検索する場合は、おそらくこれをファクト テーブルにも含めてください。他の試みを行うと、おそらくクエリがサージ可能ではなくなります (「SQL ステートメントがサージ可能になる理由」を参照してください)。

Microsoft は、 http : //msdn.microsoft.com/en-us/library/aa902672%28v=sql.80%29.aspxで次のことを推奨しています。

他のディメンション テーブルで使用される代理キーとは対照的に、日付と時刻のディメンション キーは「スマート」である必要があります。日付ディメンションの推奨されるキーは、"yyyymmdd" の形式です。この形式は、ユーザーが覚えやすく、クエリに組み込むのが簡単です。これは、日付によって複数のテーブルに分割されたファクト テーブルの代理キー形式としても推奨されます。

幸運！

于 2012-04-02T10:46:04.053 に答える