複雑なデータの蓄積を行っています。私たちの顧客は、2 つの次元 (時間とビジネス ユニット) を含むいくつかのデータを私たちに送信します。時間は主に年月です。ビジネス ユニット ディメンションには、名前と、レポートおよび分析の目的で BU が属することができるいくつかのカテゴリなど、いくつかの属性しかありません。
彼らが私たちに送るものには、いくつかの現在の状態情報 (日付とコード) が含まれています。これらは事実のようです。また、ビジネス ユニットとの関係を特徴付ける情報も送信します (ほとんどが追加コード)。繰り返しますが、これらはビジネス ユニットと期間に固有のものです。
最後に、彼らは明らかに付加的な事実である情報を送ってきます。適切な単位を持つ通貨とカウントが含まれます。
この定性的な情報を 1 つのファクト テーブルに付加的なファクトと混ぜ合わせるべきですか? それとも、定性的なもの (カウントでのみ使用できます) を定量的なもの (合計で使用できます) から分離する必要がありますか?
要素が縮退している場合にのみ、要素をファクト テーブルに配置します (ディメンションがファクト テーブルと 1 対 1 の関係になると、ディメンションで高カーディナリティ/一意性の問題が発生します)。Kimball は、事実に退化した次元以外のもの (たとえば、一意の注文番号) を含めないようにすることを推奨しています。
これらは、Kimball が「がらくた」次元と呼ぶものにいつでも入れることができます。これらのコードはすべて、ジャンク ディメンションにひとまとめにすることができます。ほとんどの日付は、特定の役割の日付ディメンションへのキーとしてファクト テーブルに入れられます (通常は、YYYYMMDD 形式の自然な int キーを使用します。これは、ID 以外の意味のない代理キーを使用しない唯一の例の 1 つです)。
私は単純に星をすべての事実と見なし、どの列がどの次元に入るかは単純に都合によって決まると考えるのが好きです。それらを必ずしも特定のビジネス エンティティに対応するものと見なすべきではありません。スターは ERD スタイルの正規化された OLTP データベースではないことに注意してください。
データが加法ファクトに直接関連していて、グループ化/ソート/検索したくないものである場合は、ファクト テーブルに入れても問題ありません。
ただし、ファクト テーブル内の非追加データは、ロールアップを妨げるか、損失の多い操作になることに注意してください。
Brad Wilsonは、それらをファクトテーブルに追加するリスクを正確に説明しています。以前は、後でリファクタリングする必要がある場合にのみ、ファクトテーブルにジャンク属性を追加していました。
彼らが私たちに送るものには、いくつかの現在の状態情報（日付とコード）が含まれています。これらは事実のようです。また、ビジネスユニットとの関係を特徴付ける情報（主に追加のコード）も送信します。繰り返しますが、これらはビジネスユニットと期間に固有のものです。
日付はどのようなビジネス目的に役立ちますか？オフハンドでは、これらを独自の寸法にして正確に説明することをお勧めします。
入ってくる余分なコードはどれくらい不安定ですか？ファクトテーブルの粒度が日付とBUである場合、それらをBUディメンションに含めて、ゆっくりと変化する属性として扱うことができないのはなぜですか？
これ以上の詳細がなければ、私は確固たる推薦をすることはできませんが、これらは私が自分自身に尋ねる最初の質問になるでしょう。