初心者の次元モデリングに関する質問:
正式な「ビジネス プロセス」の外で、ディメンション間の関係をどのようにモデル化しますか? たとえば、ファンタジー ベースボール リーグをモデル化しているとします。いくつかの明白な次元はチームとプレーヤーであり、例の事実はプレーヤーが打席に来た結果です。私が混乱しているのは、どのプレイヤーがどのチームに所属しているかを簡単に追跡する方法です。
第 3 正規形では、チームとプレーヤーの FK のクロス リファレンス テーブル、および 2 つの組み合わせに特に関連する追加フィールド (募集日、ベンチ プレーヤー インジケーターなど) を作成します。これは、スター スキーマと何か違いがありますか? そうでない場合、このテーブルは数値属性のないファクト テーブルと見なされますか?
私を混乱させているのは、この相互参照表が単独ではあまり役に立たないということです。他のファクト テーブルに結合して、別のファクト/プロセスに関連付けられたチームのプレーヤーのリストを取得する場合にのみ意味があります。これにより、事実というよりも次元のように感じられます。
次元モデリングでは、モデル化するプロセスを選択する必要があります。チーム プレーヤーの関係がモデルの二次的なものである場合は、それを無視して、プレーヤーがチームのためにバットに行くときに、プレーヤーがチームに属していることを知ることができます。
もちろん、これは決して打たないプレーヤーを除外します。
多対多のこの関係を検討したい場合、明らかな解決策は別のファクト テーブルです。ファクト テーブルはファクトレスである可能性もあります (追加情報がない場合ですが、この場合、プレーヤーの給与は明らかで重要な事実です)。
もう 1 つのオプションは、プレーヤーにタイプ 2 SCD を使用することです。これは、プレイヤーに対する属性の変化を経時的に保存する方法です。
したがって、1 人のプレーヤーの場合、そのプレーヤーは 4 つのチーム間を移動するため、4 次元の記録を持つ可能性があります。ディメンション レコードには開始日と終了日があるため、プレーヤーが 1 月にチームを移動し、2 月までプレーを開始しなかった場合でも、その情報は保存されます。
この方法で、プレーヤーの属性、つまり怪我などを追跡します。
これは、特別な事実を必要とせずに「遅い」変更を追跡する方法です。
なんらかの履歴ステータス レポートが必要な場合は、プレイヤー ディメンションを日付ディメンションに結合するだけです。
この記事でタイプ II を見てみましょう。