同じエンティティのディメンションとファクト？

私はDW設計にかなり慣れておらず、ITインフラストラクチャをモデル化するためにDWに取り組んでいます。

この時点での主要な問題/質問は、ドライブ情報をモデル化する方法です。

ファイルとフォルダの集計データと物理ドライブの個別データを収集します。ドライブ情報には、最低でも合計と空き容量が含まれ、週に数回更新されます。

答える必要があるビジネス上の質問の1つは、ドライブの使用状況が時間とともにどのように傾向にあるかです。ドライブ情報は、ファイル/フォルダーレベルまでの階層でも使用されます。

私が今見ることができるオプションは：

1. DRIVEディメンションとして 実装

   • 階層設計を簡素化
   • これによりレポートに問題が発生しますか？ディメンションのみの時間制限データを報告することは私には直観に反するようです
   • また、データを更新するたびに変化することがわかっているディメンションがあることも問題のようです。

2. DRIVEファクトテーブルとして実装

   • レポートを簡素化
   • 複雑な階層（？）- Driveデータを特定のサーバーまたはコンピューターにマップするためにも使用します。ファクトテーブルを階層の中間レベルとして使用することはできますか？そうは思いません。

3. DRIVEファクトとディメンションの両方として実装

   • ファクトには、キー、日付、およびスペースに関するファクトのみが含まれます
   • Dimensionには、使用しているコンピューターなど、その他の非追加データが含まれます。
   • 両方の問題を解決しているようですが、これはアンチパターンですか？

スナップショット時間ディメンション、ドライブディメンション、コンピューターディメンション、およびその瞬間のドライブに関するさまざまな数値ファクトへのリンクを備えたdrive_usageファクトテーブルがあると思います。

おそらく、ドライブの次元で定期的に変化するものは何もないはずです-それはドライブの定義に依存していると思います-それは物理ドライブか論理ユニットか、それとも何ですか。おそらく、「C」ドライブにはシリアル番号があり、それが交換されます。その後、寸法が期限切れになり、新しい寸法が追加されます。ディメンションに関するこれらのことは、実際には「事実」ではなく、属性です。コンピューターX、ドライブCのデータには連続性があるため、これはレポートには影響しません。同様に、コンピューターXがデュアルコアからクアッドコアにアップグレードされ、寸法が変更された場合（マザーボードのリビジョンなど、コアの数を超えるものがファクトテーブルで追跡されないと想定）。ドライブの容量はファクトテーブルにあるため、時間の経過に伴う変更は、新しい日付の新しいファクトにすぎません。メンバーシップの変更をファクトとしてモデル化することもできます。つまり、物理ドライブ1〜5が論理ドライブCにあり、物理ドライブ1〜6が論理ドライブCにある場合は、物理ドライブメンバーシップファクトテーブルのファクトが変更されている可能性があります。これらは、事実のないファクトテーブルと呼ばれるものです。唯一の事実は、行の存在がメンバーシップを示しているためです。合計またはカウントする以外に、行うべきことは多くありません。

フォルダに入るとき、階層をモデル化することは、ロールアップで何を達成しようとしているのかに応じて、はるかにトリッキーになることがあります。

ありふれたシナリオではないドメインでのDWモデリングには多くの芸術があります。