ファクトテーブルのメジャーと非メジャーコードを混在させることはできますか？

Question

複雑なデータの蓄積を行っています。お客様から、2つのディメンション（時間とビジネスユニット）を含むものが送られてきます。時間は主に年月です。ビジネスユニットディメンションには、名前、およびレポートと分析の目的でBUが属することができるいくつかのカテゴリなど、いくつかの属性があります。

送信するものには、現在の状態情報（日付とコード）が含まれています。これらは事実に似ています。また、ビジネスユニットとの関係を特徴付ける情報（主に追加のコード）を送信します。繰り返しますが、これらは事業単位と期間に固有のものです。

最後に、彼らは明らかに相加的な事実を私たちに送ります。適切な単位を持つ通貨とカウントが含まれます。

この定性的な情報を単一のファクトテーブルに追加ファクトと混ぜる必要がありますか？または、定性的なもの（カウントでのみ使用可能）と定量的なもの（合計で使用可能）を分離する必要がありますか？

Answer 1

それらが縮退している場合にのみ、ファクトテーブルに配置します（ディメンションがファクトテーブルとの1-1の関係になる場合、ディメンションで高カーディナリティ/一意性の問題が発生します）。 Kimballは、事実（たとえば、一意の注文番号）と共に縮退したディメンション以外のものを配置する誘惑を避けることをお勧めします。

これらは、Kimballが「ジャンク」と呼ぶものにいつでも入れることができます。寸法。これらのコードはすべて、単純にジャンクディメンションにまとめることができます。ほとんどの日付は、特定のロールの日付ディメンションへのキーとしてファクトテーブルに格納されます（通常、YYYYMMDD形式の自然なintキーを使用します。これは、ID以外の無意味な代理キーを使用しない唯一の場合です） p>

私は、星をすべての事実として単純に表示し、その後、どの列にどの列が入るかを単純に便宜上判断するのが好きです。特定のビジネスエンティティに対応するものとして必ずしも表示する必要はありません。スターはERDスタイルの正規化されたOLTPデータベースではないことに注意してください。

Answer 2

データが付加的なファクトに直接関連しており、グループ化/ソート/検索したいものではない場合、ファクトテーブルに入れても問題ありません。

ただし、ファクトテーブルの非加算データはロールアップを防ぐか、損失の多い操作になることに注意してください。

Answer 3

Brad Wilsonは、ファクトテーブルに追加するリスクを正確に説明しています。過去には、ファクトテーブルにジャンク属性を追加して、後でリファクタリングが必要になるようにしました。

  

彼らが私たちに送るものには、   現在の状態情報（日付と   コード）。これらは事実に似ています。彼ら   また、いくつかの情報を送信します   との関係を特徴付ける   ビジネスユニット（主に追加   コード）。繰り返しますが、これらは   事業単位と期間。

日付はどのようなビジネス目的に役立ちますか？ちなみに、これらを独自の寸法にして正確に記述することをお勧めします。

追加のコードはどの程度揮発しますか？ファクトテーブルの粒度が日付とBUである場合、BUディメンションに含めて、ゆっくり変化する属性として扱うことができないのはなぜですか？

詳細な説明はありませんが、確固たる推奨はできませんが、これらは最初に自問する質問です。