data-warehouse - II 型 SCD，实体随着时间的推移而合并

Question

假设我们有一个代表销售办事处的维度。办公室可能会搬迁，这将是第二类变化。我们希望跟踪旧办公地点发生的操作以及现在新办公地点发生的操作，并了解更改何时发生。到目前为止，只是标准的II型设计。现在假设一个办公室与另一个办公室合并。也就是说，两个原本不同的办事处(“母办事处”)的业务事件现在在一个办事处(“合并办事处”)中进行，该办事处可能是任一办事处的延续(物理上或人员方面)原来的办公室，或者它可能是一个完全新的办公室，从业务角度来看，是前两个办公室的延续。

报告/分析要求如下:

• 我们希望能够查看合并后的新办事处当前的所有事件。
• 我们希望能够查看合并后的办事处或母公司办事处曾经完成的所有事件。
• 我们希望能够了解其中一个母公司在合并前后发生的随时间变化的事件，而无需查看另一个母公司的事件(至少在合并之前)。

我不确定如何使用任何 SCD 类型对此进行建模。如果我们简单地用一个新条目替换两个父办公室条目，并相应地更新所有事实表，我们就会得到类型 I 的更改。这使我们能够很好地看到当前的事件，但我们会失去历史。如果我们分开保存记录，我们就不会知道合并的情况。如果我们添加第三条记录来代表合并的办事处，我们也会丢失历史记录(它会具有哪个自然键？父办事处的自然键都不合适)。

我需要使用桥/多对多表吗？这带来了我想避免的复杂性。但是，如果这是最好的方法，那就这样吧。然而，我仍然不确定它的结构如何。也许事实表将指向一个办公室条目，并且办公室将以多对多的方式分组。报告将根据组进行，而不是直接根据办公室维度进行。

ElectricLlama 问题的解答

• 大多数用户交互都是通过预设报告进行的，因此底层结构的任何复杂性都将被隐藏。
• 一些用户确实使用 SQL 或 SAS 来获取数据。目前，他们不太可能关心这个具体问题，但随着我们让更多用户使用这些工具，情况可能会发生变化。
• 目前我们还没有查询编写器。
• 我认为不会出现多级合并，但我也不能明确拒绝。不过，如果有的话我会感到惊讶。
• 我不知道如何让最终用户轻松完成此类操作，这可能足以放宽某些要求。

Answer 1

我更喜欢客户可以接受的最简单的解决方案，因此我会执行以下操作。我会在办公室维度提供两个办公室字段:

1. 今天的办公室
2. Office_原始

(当然，您必须选择对您的客户有利的名称)一开始这两个字段将被设置为相等。当两个办公室合并时，我将返回两个原始办公室并使用合并办公室的名称更新 Office_as_today 字段。

新事实(从合并开始)将注册到新行中，两个字段再次相等。

解决方案非常简单，几乎可以满足所有要求，只是合并后无法继续原来的办事处(这里我强调了您的“至少”)。