Type II SCD，包含随时间合并的实体

Question

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

报告/分析要求如下：

• 我们希望能够看到新合并办公室的所有当前活动。
• 我们希望能够看到合并后的办公室或家长办公室所做的所有活动。
• 我们希望能够在合并前后的一个母公司中看到一段时间内发生的活动，而不会看到来自其他母公司的活动（至少在合并之前）。

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

我是否需要使用网桥/多对多桌面？这引入了我想避免的复杂性。但是，如果这是最好的方法，那就这样吧。但是，我仍然不确定如何构建它。事实表可能指向办公室入口，办公室将以多对多的方式分组。报告将基于小组进行，而不是直接在办公室维度上进行。

对ElectricLlama问题的回答

• 大多数用户交互都是通过预设报告进行的，因此底层结构的任何复杂性都将被隐藏起来。
• 有些用户确实使用SQL或SAS来获取数据。目前，他们不太可能关心这个具体问题，但随着我们带来更多用户使用这些工具，这可能会改变。
• 此时此刻我们没有查询作者。
• 我认为不会有多层次的合并，但我无法明确拒绝。不过，如果有的话，我会感到惊讶。
• 我不知道如何让最终用户轻松做到这一点，这可能足以让他们放松一些要求。

Answer 1

我更喜欢客户可以接受的最简单的解决方案，所以我会做以下事情。 我会在办公室提供两个办公室领域：

1. Office_as_today
2. Office_original

（当然，您必须选择对您的客户有利的名称） 在开始时，两个字段将被设置为相等。当两个办公室合并时，我将返回两个原始办公室并更新Office_as_today字段，其中包含合并办公室的名称。

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

解决方案非常简单，几乎满足了所有要求，但合并后无法跟踪原始办公室（此处我强调您的“至少”）。