営業所を表すディメンションがあるとします。オフィスが移動する可能性がありますが、これはタイプ II の変更になります。古いオフィスの場所で行われた操作と、現在新しい場所で行われている操作を追跡し、変更がいつ発生したかを知りたいと考えています。これまでのところ、標準的なタイプ II のデザインだけです。ここで、オフィスが別のオフィスと合併するとしましょう。つまり、元々は別個の 2 つのオフィス (「親オフィス」) の運用活動が、現在は 1 つのオフィス (「合併オフィス」) で行われています。または、ビジネスの観点から、前の 2 つのオフィスの継続である完全に新しいオフィスである可能性があります。
レポート/分析要件は次のとおりです。
- 新しい統合されたオフィスの現在の活動をすべて確認できるようにしたいと考えています。
- 合併したオフィスまたは親オフィスがこれまでに行ったすべての活動を確認できるようにしたいと考えています。
- 合併前と合併後の両方で親オフィスの 1 つで発生したアクティビティを、他の親オフィスのアクティビティ (少なくとも合併前) を表示せずに経時的に表示できるようにしたいと考えています。
これを SCD タイプでモデル化する方法がわかりません。単純に 2 つの親オフィス エントリを 1 つの新しいエントリに置き換え、それに応じてすべてのファクト テーブルを更新すると、タイプ I が変更されます。これにより、現在のアクティビティを問題なく確認できますが、履歴は失われます。記録を別々に保管すると、合併についてはわかりません。合併したオフィスを表す 3 番目のレコードを追加すると、履歴も失われます (親オフィスのどちらの自然キーも適切ではないでしょう)。
ブリッジ/多対多テーブルを使用する必要がありますか? それは私が避けたい複雑さをもたらします。ただし、それが最善の方法である場合は、そうしてください。ただし、それがどのように構造化されるかはまだわかりません。おそらく、ファクト テーブルはオフィス エントリを指し、オフィスは多対多の方法でグループ化されます。レポートは、オフィス ディメンションに直接ではなく、グループに基づいて行われます。
ElectricLlama の質問への回答
- ほとんどのユーザー インタラクションは既定のレポートを介して行われるため、基礎となる構造の複雑さはレポートから隠されます。
- 一部のユーザーは、SQL または SAS を使用してデータを取得します。現時点では、彼らがこの特定の問題を気にする可能性はほとんどありませんが、これらのツールを使用するユーザーが増えるにつれて、状況が変わる可能性があります.
- 現時点では、クエリ ライターはありません。
- 複数レベルの合併があるとは思いませんが、絶対にノーとは言えません。あったとしても、私は驚くだろう。
- この種のことをエンドユーザーにとって簡単にする方法がわかりません。これは、いくつかの要件を緩和するのに十分な議論かもしれません。