假设我们有一个代表销售办事处的维度。办公室可能会搬迁，这将是第二类变化。我们希望跟踪在旧办公地点发生的操作，以及现在在新办公地点发生的操作，并了解更改发生的时间。到目前为止，只是标准的 II 型设计。现在假设一个办公室与另一个办公室合并。也就是说，两个原本不同的办公室（“上级办公室”）的业务活动现在在一个办公室（“合并的办公室”）中进行，这可能是其中任何一个办公室的延续（物理上或人员方面）原来的办公室，或者它可能是一个新的办公室，从商业的角度来看，它是前两个办公室的延续。
报告/分析要求如下：
- 我们希望能够看到新合并办公室的所有当前活动。
- 我们希望能够看到合并后的办公室或上级办公室曾经做过的所有活动。
- 我们希望能够看到随着时间的推移在合并之前和之后在一个母公司中发生的活动，而不会看到另一个母公司的活动（至少在合并之前）。
我不确定如何使用任何 SCD 类型对此进行建模。如果我们简单地将两个父办公室条目替换为一个新条目，并相应地更新所有事实表，我们就有了一个类型 I 更改。这使我们可以很好地查看当前活动，但我们会丢失历史记录。如果我们将记录分开，我们就不会知道合并。如果我们添加第三条记录来表示合并后的办公室，我们也会丢失历史记录（它会有哪个自然键？父办公室的自然键都不合适）。
我需要使用桥接/多对多表吗？这引入了我想避免的复杂性。但是，如果这是最好的方法，那就这样吧。但是，我仍然不确定这将如何构建。也许事实表将指向一个办公室条目，并且办公室将以多对多的方式分组。报告将基于组进行，而不是直接在办公室维度上进行。
ElectricLlama 问题的答案
- 大多数用户交互是通过预制报告进行的，因此底层结构的任何复杂性都将被隐藏起来。
- 一些用户确实使用 SQL 或 SAS 来获取数据。目前，他们不太可能关心这个特定问题，但随着我们让更多用户使用这些工具，这种情况可能会发生变化。
- 目前我们没有查询作者。
- 我不认为会有多层次的合并，但我不能肯定地说不。不过，如果有的话，我会感到惊讶。
- 我不知道如何让最终用户轻松完成这种事情，这可能足以放松一些要求。