ありがとう：ここでの両方の答えは非常に役に立ちますが、私は1つしか選ぶことができませんでした。アドバイスありがとうございます！
当社のデータウェアハウスは、従来の分析レポートよりもワークフローレポートに多く使用されます。私たちのユーザーは、歴史よりもはるかに「現在の写真」に関心を持っています。（歴史も重要ですが。）私たちは、費用や関連する計算を持たない政府機関です。ほとんどの場合、特定の場所にあり、関連する履歴を持つ人の数だけです。
私たちはOracleを使用していますが、可能な限りスター結合を使用することには明確な利点があり、ビジネスでの使用に適したスタースキーマにできるだけ類似するようにすべてを再設計したいと思います。このDWの速度は非常に重要であり、多くのテストでスタースキーマアプローチがすでに証明されています。
私たちの「人」テーブルが重要です。これには400万を超えるレコードが含まれており、クエリで最も頻繁に使用されるソースになります。 それは、複数の次元（年齢、性別、所属、場所など）を持つ星の中心に見ることができます。これは非常に長いテーブルであり、特にアドレスと連絡先情報に結合すると非常に長くなります。
ただし、履歴を見始めると、ディメンションテーブルのようなものになります。たとえば、人物テーブルを指す人物キーを持つ2つの異なる履歴テーブルがあります。1つは2000万を超えるレコードを持ち、もう1つはほぼ5000万を持ち、毎日成長しています。
このテーブルはファクトテーブルですか、それともディメンションテーブルですか。1つは両方として機能できますか？もしそうなら、それは大きなパフォーマンスの問題になるのでしょうか？ファクトよりもディメンションから多くのクエリを実行するのが一般的ですか？個人テーブルをディメンションとして使用するDIFFERENTファクトテーブルが実際には60,000レコード（はるかに小さい）しかない場合はどうなりますか。
私の問題は、私たちのデータとその使用が、スタースキーマの一般的に使用される例に適合しないことだと思います。
明確化： いくつかの良い考えが以下に追加されていますが、おそらく私はあまりにも多くを省略して、本当にうまく説明することができませんでした。ここにいくつかのより多くの情報があります：
有権者データベースを取り扱っています。さまざまなグループによる投票者数以外の測定値はありません。党別、年齢別、場所別の投票者数。投票者は、投票の種類と選挙、投票のステータスと選挙などによってカウントされます。「投票履歴」ログと活動監査ログ（住所、政党などの変更）があります。どの有権者が選挙労働者であるかに関する情報と、それに関連するすべての情報があります。後で周辺機器にたどり着くと思います。
今のところ、私は2つの主要な「ビジネスプロセス」に焦点を当てています。それは、投票者登録（投票者です）と投票率です。第一に、有権者は事実です。第二に、有権者は、党、選挙、投票用紙の種類とともに、次元です。（そして誰かが心配している場合に備えて-いいえ、私たちは人々がどのように投票するかわかりません。彼らが投票するだけです。LOL）
それが少し明確になることを願っています。