データ ウェアハウスの特定のシナリオをモデル化する最善の方法を理解するのに苦労しています。
Person ディメンションと Tenancy ディメンションがあります。人は、一度に 0、1、または (まれに) 複数のテナントにいる可能性があり、多くの場合、時間の経過とともに一連のテナントを持っています。テナンシーには、1 人以上の人が関連付けられている可能性があります。テナントに関連する人々は時間の経過とともに変化する可能性があり、テナントは一般的に何年も続きます。
1 つのオプションは、テナント参照、開始日および終了日をタイプ 2 SCD 列として Person ディメンションに追加することです。これは、1 人の人が複数の同時テナントの可能性を無視する限り、うまく機能します。ただし、同様の設計上の問題に直面しているデータ ウェアハウスの他の領域があり、複数の関係を無視することはできません。
もう 1 つのオプションは、関係を累積スナップショット ファクト テーブルとしてモデル化することです。これが実際にどれだけうまく機能するかはわかりませんが、これを Person と Tenancy の 1 つのバージョン (どちらもタイプ 2 の SCD 列を持つ) にしかリンクできず、現在または人とテナントを結び付ける履歴レポート。
このタイプの関係をモデル化するための推奨される方法はありますか?
SQL.Injection によって与えられた患者の回答とコメントに基づいて編集します
SQL.Injection で記述されたモデルを示す基本モデルを作成しました。
テナントの開始日/終了日を「ジャンク」ディメンション (Dim.Tenancy) に移動し、個人のテナントの開始日/終了日をファクト テーブルに追加しました。これが関係をより正確に説明する方法だと感じたからです。
ただし、視覚的に見ると、ファクト テーブルが累積スナップショットではなく定期的なスナップショットであることを除けば、これは最初に使用したモデルと根本的に異なるとは思いません。確かに、いずれかのディメンションでタイプ 2 のゆっくりと変化する属性を更新するたびに、それが事実に反映されないという同じ欠陥に苦しんでいるようです。
これを機能させて現在の変更を反映させ、履歴レポートを作成できるようにするには、いずれかのディメンションで SCD2 の変更が発生するたびに、ファクト テーブルに行を追加する必要があるようです。次に、同じエンティティの複数のバージョンに参加することによる過大評価を防ぐために、他の関連ディメンションの新しいバージョンを追加して、参加する新しいキーを用意する必要があります。
これについては、もう少し考える必要があります。私は、データベース モデルが正しく、モデルがどのように使用されるかについての私の理解が間違っていると考え始めています。
それまでの間、コメントや提案は大歓迎です！