開発中のスター スキーマの特定のディメンションに何を入れるべきか、ファクト テーブルに何を入れるべきかを判断するのに苦労しています。
例として、プロジェクトが不動産管理会社の住宅を追跡しているとしましょう。さまざまな日付、賃借人、契約などのディメンションはすべてかなり簡単です。家の場合、データがどこにあるかに関係なく、現在の所有者、現在の賃借人、現在の賃貸契約、および近隣、住所、現在の賃貸価格、現在の市場価値などを追跡する必要があります。 . 所有者、賃借人、および契約自体が次元であることに注意してください (また、近隣と住所も次元である可能性がありますが、私はそれらをあまり気にしません)。
家について保持されている多くのデータは、クエリのフィルター処理や、キューブの行ヘッダーと列ヘッダーに使用されます。その一部は、補助的な情報としてのみ必要であり、家ごとに見られますが、全体としては必要ありません.
データとそれをどうする必要があるかを考えると、(少なくとも) 3 つのオプションがあります。
- DimHouse: house テーブルはディメンションであり、ファクト テーブルの方が見栄えがするかもしれない多くの属性がありますが、それらは参照とフィルター処理に使用されるため、ここにある必要があります。現在の賃借人のような属性には、スノーフレーク/アウトリガーが必要になります。
- FactHouse: 他のファクト テーブルに結合されたハウス情報の累積スナップショットを持ちます。おそらく、トリミングされた DimHouse をブリッジとして使用します。これは私には奇妙に思えますが、事実のように見えるものを事実テーブルに入れます。
- 現在の所有者、現在の賃借人などを関連するファクト テーブルに入れ、それらの事実を所有者/賃借人/その他として最新の状態に保ちます。変更します (これも奇妙ですが、私たちをスター スキーマの土地にとどめます)。
ということで、次元ルートを下ってきました。胸焼けしますが、目標を達成します。データを整理するためのより良い方法があるかどうかを知りたいだけです。冗長性 (類似したデータを持つファクト テーブルとディメンション テーブルを使用するなど) やスノーフレークは、それらが意味を成し、物事を行うための最良の方法 (「最善」の値の場合) であれば気にしません。