スタースキーマファクトまたはディメンションテーブルへのデータ？
会社のプリセールスプロセスのレポートに使用したいインターンシップのスタースキーマの作成に取り組んでいます。私が報告したいプリセールスプロセスの側面は次のとおりです。
- 販売提案;
- タスク管理。
私が困っているのは、自分のスタースキーマで提案とタスクを互いに分離するかどうかです。このため、2つの異なるものを作成しましたが、それらのいずれかが「正しい」方法であるかどうか疑問に思います。
スタースキーマ1。プロポーザルデータがファクトテーブルから分離され、ディメンションテーブルに配置されています。 
スタースキーマ2。ファクトテーブルで提案データとタスクデータが結合されています。 
これらは私が最終的に報告できるようにしたいメトリックです：
- 時間内に完了したタスクの割合
- 時間の経過に伴うワークロード
- 期限付きおよび完了した提案
- アクティブな送信の数
- 潜在的な総売上高
- 潜在的な総粗利益
- セールスチームあたりの潜在的な平均粗利益％
- 注文に変換された送信の割合
これらのスキーマのどれが良いと思いますか？私はしばらくの間、これに頭を回そうとしていますが、それを理解することができません。スタースキーマ1は冗長性が低くなりますが、次元テーブルで使用したい値があります。一方、スタースキーマ2は、プロポーザルが複数のタスク（場合によっては最大20）を持つことができるため、多くの冗長性があります。
また、私のスキーマに関するより一般的な質問：-すべての関係をスタースキーマ図で視覚化する必要がありますか？たとえば、すべてのテーブルのすべての日付が日付テーブルにリンクされている必要があります。 And：従業員へのすべての参照は、従業員テーブルにリンクする必要があります。
追伸アプリケーションとそのデータベースはまだ開発中のため、テストに使用できるデータがありません。
これは非常に興味深いですが、質問としては少々一般的すぎるかもしれません。
私の一般的な意見では、ディメンションのカーディナリティがファクトテーブルのカーディナリティに近づき始めたら、別のディメンションを維持する意味はありません。キンボールを注意深く読むと、多くの場合、ファクトテーブルと比較すると次元が小さい（少なくとも数桁）と暗黙的に想定されていることがわかります。
あなたのケースでは、提案には最大20のタスクが含まれる可能性があると述べています。次元が大きくなりすぎて効率的に処理できなくなる寸前です。
しかし、あなたが見逃しているかもしれない別のものがあります。あなたが達成しようとしていることは、ライフサイクルの特定の状態で提案を数えることです。ここでも、キンボールに行くと、解決策は累積スナップショットファクトテーブルになります。ただし、これにはコストが伴います。これは、オブジェクトのライフサイクルのいくつのマイルストーンを追跡する価値があるかを事前に定義する必要があることを意味します。
しかし、私がしばらく前に開発し、先週についてブログに書いた代替案があります。これは、ステータス変更ファクトテーブルと呼ばれるもので、イベント（この場合はタスク）を追跡し、行を追加して、プロポーザルのライフサイクル（ブログ投稿 here ）。基本的な考え方は、プロポーザルにDとD2日に実行された2つのタスクAとBがある場合、ファクトテーブルに3つの行を挿入するということです。
日付;タスク;カウントD1; A; +1 D2; A; -1 D2; B; +1
このモデルを定期的なスナップショットと組み合わせて、特定の時点でどれが各状態にあるかを数えると、単純なクエリを実行しながら、質問に対する有意義な回答を得ることができます。
このアプローチを最近いくつかのプロジェクトに実装しました。ステータス変更テーブルの負のカウントが何を意味するのかを顧客に知らせる必要があったとしても、オブジェクトはシステムを通じて追跡され、かなりの顧客満足度が得られます。