類型II SCD與實體合併隨着時間的推移

Question

比方說，我們有一個代表銷售辦事處的維度。辦事處可能會移動，這將是第二類改變。我們希望跟蹤在舊辦公地點發生的操作，以及現在發生在新的辦公室的操作，並知道發生了什麼變化。到目前爲止，只是標準的II型設計。現在讓我們說一個辦公室與另一個辦公室合併。也就是說，兩個原本不同的辦事處（「主管辦公室」）的業務活動現在正在一個單一的辦公室（「合併辦公室」）進行，這可能是任一辦公室（實際或工作人員）的延續原來的辦公室，或者它可能是一個新的辦公室，從商業的角度來看，這是前兩個辦公室的延續。

報告/分析要求如下：

• 我們希望能夠看到所有的當前活動爲新的合併辦公。
• 我們希望能夠看到合併辦公室或總部辦公室所做的所有活動。
• 我們希望能夠看到合併前後在其中一家總部辦公室發生的一段時間的活動，而沒有看到其他總部辦公室的活動（至少在合併之前）。

我不知道如何使用任何SCD類型對此進行建模。如果我們只用一個新辦公室條目替換兩個父辦公室條目，並相應地更新所有事實表，我們就有一個類型I變更。這讓我們看到目前的活動很好，但我們失去了歷史。如果我們保持記錄分開，我們將不知道合併。如果我們添加第三條記錄來代表合併後的辦公室，我們也會失去歷史記錄（它具有哪個自然鑰匙？兩個母公司的自然鑰匙都不適合）。

我需要使用橋/多對多表嗎？這引入了我想避免的複雜性。但是，如果這是做到這一點的最佳方式，那就這樣做吧。然而，我仍然不確定這將如何構建。也許事實表將指向一個辦公室入口，並且辦公室將以多對多的方式分組。報告將根據小組進行，而不是直接在辦公室進行。

答案ElectricLlama的問題

• 大多數用戶的交互是通過罐裝報告，所以任何來自底層結構的複雜性將它們隱藏。
• 有些用戶確實使用SQL或SAS來獲取數據。目前，他們不太可能關心這個具體問題，但是隨着我們爲這些工具帶來更多用戶，這可能會發生變化。
• 在這個時刻我們沒有查詢作家。
• 我不認爲會有多層次的兼併，但我不能確定地說不。如果有的話，我會很驚訝。
• 我不知道如何使這種事情容易爲最終用戶，這可能是足以放鬆一些要求的論據。

Answer 1

我寧願客戶可以接受的最簡單的解決方案，所以我會做以下工作。 我將提供在辦公室維度兩個辦公領域：

1. Office_as_today
2. Office_original

（當然你要挑選適合您的客戶的名字） 在開始兩字段將被設置成相等的。當兩個辦公室合併時，我會回到兩個原來的辦公室，並更新Office_as_today字段和合並辦公室的名稱。

新事實（來自合併）將用新行註冊，兩個字段再次相等。

解決方案非常簡單，幾乎可以滿足所有要求，除了在合併後無法關注原來的辦公室（這裏我強調您的「至少」）。