类型II SCD与实体合并随着时间的推移

Question

比方说，我们有一个代表销售办事处的维度。办事处可能会移动，这将是第二类改变。我们希望跟踪在旧办公地点发生的操作，以及现在发生在新的办公室的操作，并知道发生了什么变化。到目前为止，只是标准的II型设计。现在让我们说一个办公室与另一个办公室合并。也就是说，两个原本不同的办事处（“主管办公室”）的业务活动现在正在一个单一的办公室（“合并办公室”）进行，这可能是任一办公室（实际或工作人员）的延续原来的办公室，或者它可能是一个新的办公室，从商业的角度来看，这是前两个办公室的延续。

报告/分析要求如下：

• 我们希望能够看到所有的当前活动为新的合并办公。
• 我们希望能够看到合并办公室或总部办公室所做的所有活动。
• 我们希望能够看到合并前后在其中一家总部办公室发生的一段时间的活动，而没有看到其他总部办公室的活动（至少在合并之前）。

我不知道如何使用任何SCD类型对此进行建模。如果我们只用一个新办公室条目替换两个父办公室条目，并相应地更新所有事实表，我们就有一个类型I变更。这让我们看到目前的活动很好，但我们失去了历史。如果我们保持记录分开，我们将不知道合并。如果我们添加第三条记录来代表合并后的办公室，我们也会失去历史记录（它具有哪个自然钥匙？两个母公司的自然钥匙都不适合）。

我需要使用桥/多对多表吗？这引入了我想避免的复杂性。但是，如果这是做到这一点的最佳方式，那就这样做吧。然而，我仍然不确定这将如何构建。也许事实表将指向一个办公室入口，并且办公室将以多对多的方式分组。报告将根据小组进行，而不是直接在办公室进行。

答案ElectricLlama的问题

• 大多数用户的交互是通过罐装报告，所以任何来自底层结构的复杂性将它们隐藏。
• 有些用户确实使用SQL或SAS来获取数据。目前，他们不太可能关心这个具体问题，但是随着我们为这些工具带来更多用户，这可能会发生变化。
• 在这个时刻我们没有查询作家。
• 我不认为会有多层次的兼并，但我不能确定地说不。如果有的话，我会很惊讶。
• 我不知道如何使这种事情容易为最终用户，这可能是足以放松一些要求的论据。

Answer 1

我宁愿客户可以接受的最简单的解决方案，所以我会做以下工作。 我将提供在办公室维度两个办公领域：

1. Office_as_today
2. Office_original

（当然你要挑选适合您的客户的名字） 在开始两字段将被设置成相等的。当两个办公室合并时，我会回到两个原来的办公室，并更新Office_as_today字段和合并办公室的名称。

新事实（来自合并）将用新行注册，两个字段再次相等。

解决方案非常简单，几乎可以满足所有要求，除了在合并后无法关注原来的办公室（这里我强调您的“至少”）。