web-dev-qa-db-ja.com

DWファクトテーブルがすべてのディメンションで一意に識別されない場合、どのような問題がありますか?

これは私が取り組んできたちょっとした考えの問題です。ファクトテーブル内のディメンション値の重複した組み合わせの概念に対して、内臓の反感があります。ファクトテーブルのディメンションの組み合わせが一意のキーを形成しない場合の問題の存在について多くのことを読みました。ただし、発生する可能性のある分析の失敗の正確なタイプを理解したいと思います。

仮定された醜いファクトテーブルには、すべて同じ粒度のデータが含まれていることを事前に規定することに注意してください。すべての売上高が一意に報告されますが、販売時の最も細かい粒度は1日です。明らかに、ディメンション値の同じ組み合わせを共有するトランザクションがあります。したがって、このアプローチでは、毎日のトランザクションを要約しません。これは、グッドプラクティスが通常指示する方法です。

標準の集計を使用した単純なDWクエリは引き続き正しいと思います。 「単純」とは、クエリで参照されるファクトテーブルが1つだけであることを意味します。メジャーの集計/分析の通常の形式では、クエリは正しい結果を生成すると思います。

すべてのディメンションを組み合わせて一意のファクト行を選択しようとすると、1つの失敗ケースが発生します。この種のクエリは実際には不明であると思います。ユーザーがすべての次元で最高のレベルに実際にドリルダウンしたい場合を除いて、それらの使用はほとんど見られません。私はこれを考えるのは正しいですか?

私が見ることができる唯一の予測可能で一般的な失敗のケースは、クロスファクトクエリから発生します。ここで、余分なカーディナリティは、ファクトテーブルで使用されるメジャーをおそらく乗算します。

学生(そして会社の仕事)では、「このルールに従わないとどうなるのか」とよく聞かれます。今、私はすべての答えを持っていないのではないかと心配しています。

あなたの考えとあなたの答えを前もって感謝します。

5
Andrew Wolfe

データウェアハウスをクエリするときに、すでに述べたもの(クロスファクトクエリ)を除いて、多くの問題が発生することはないと思います。あなたはあなたのデザインがどのように行われるかを知っていて、ディメンション全体でのみ集計します。それでもクエリを実行できるはずです。ファクトテーブルのディメンションキーに参加することはできませんでしたが、集計することはできました。

毎日の粒度での集計のみを気にする場合、私の意見では、より細かい粒度のディメンションを用意する必要はありません。

問題が発生する可能性があるのは、完全な読み込みを行う代わりに、ETLで増分読み込みを実行したり、ファクトレコードを更新したりしようとした場合ですが、それを回避する方法があります。

  • ファクトテーブルの代理キーを Kimballの説明 として使用できます。
  • あなたはテクニックを使うことができます Vincent Rainardiによって説明されています
  • ファクトテーブルに、レポートすることはないがETL戦略をサポートする「サポート」列を含めることができます(場合はタイムスタンプ)。