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

Question

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

报告/分析要求如下:

• 我们希望能够看到新合并办公室的所有当前活动.
• 我们希望能够看到合并后的办公室或母公司所做的所有活动.
• 我们希望能够在合并之前和之后看到在一个母公司中发生的一段时间内的活动,而没有看到来自其他母公司的活动(至少在合并之前).

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

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

ElectricLlama的问题解答

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

Answer 1

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

1. 今天的办公室
2. 办公室_原件

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

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

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