如何在缓慢变化的维度和事实中跟踪合并答案

【问题标题】：How to track merging in Slowly Changing Dimension and Facts如何在缓慢变化的维度和事实中跟踪合并
【发布时间】：2018-03-13 18:14:19
【问题描述】：

在 2 个或 3 个或更多维度合并形成新维度的数据集市中。如何管理 scd 以跟踪历史上的所有合并并呈现与这些维度相关的趋势事实？

一个具体的例子是三个商店（业务 ID 8897、8965、9135）合并以创建一个新的商店业务 ID 9700。如何从事实表中获取历史销售数据以显示直到给定日期 8897， 8965 和 9135 是分开的商店，现在都是新的商店 9700。

此外，如果新商店的营业编号不是 9700，但新商店采用以前的商店营业 ID 之一，该怎么办。因此，新合并的商店业务 ID 不是 9700，而是 8897。

SurrogateKey -------- StoreBusinessID---------- StoreName
=================================================== ==

          1                8897   Alpha Electronic  
          2                8965   Beta Electronics  
          3                9135   Gamma Electronic  
          4                9700   Mega Electornics

=============================================== =====

【问题讨论】：

标签： sql data-warehouse scd datamart scd2

【解决方案1】：

你需要使用“Type 6”渐变维度。本质上，它是类型 2 和类型 1 变化的组合。

它的工作方式：要捕获“类型 2”更改，您需要为“存储”表中的每条记录设置“开始日期”和“结束日期”。对于当前记录，结束日期通常是某个遥远的未来日期，例如 2999-12-31。当您将此类表连接到事实表时，您需要在自然键 (StoreBusinessID) 和开始日期和结束日期之间的事实日期上连接维度和事实。

要捕获“类型 1”更改，您必须在“商店”表中添加一个字段来跟踪“最新商家 ID”。此字段将包含最新版本的业务密钥。如果没有更改，Store Business ID 和 Latest Business ID 将包含相同的密钥。如果商店合并，则记录 8897、8965、9135 和 9700 都将包含“Latest Business ID”9700。

因此，您既可以“及时旅行”（重现任何时期的准确历史），也可以按商店的最新版本进行分组。

【讨论】：

第 3 类是当您添加一个新列以一次跟踪多个替代现实时 - 它们与第 2 类和第 1 类的组合不同 - 根据kimballgroup.com/2008/09/slowly-changing-dimensions-part-2。这更类似于 Type 6。
我看到类型 6 的值。一次迭代存储连接的场景正在工作，我不确定第二次迭代会发生什么以及如何跟踪它。因此，以“最新业务 ID”9700 为例，标记为 8897、8965、9135 和 9700。当 9700 与 6 个月后的 9900 合并时会发生什么情况。在这种情况下，商店 8897、8965、9135 和 9700 的最新业务 ID 为 9900。如何知道 6 个月内 8897、8695、9135 和 9700 是 9700？而不是 9900？
如果您需要浏览商店合并的完整历史记录，您将不得不使用“不平衡层次结构”。这是一个涉及递归的非常先进和复杂的解决方案；在您决定这样做之前，请确保它真的值得。如果是，这些文章可以为您指明正确的方向：blog.chrisadamson.com/2012/05/…，或brazenly.blogspot.com/2015/02/…
@RADO 谢谢，我相信您最近提出的使用不平衡层次结构的建议符合要求，但肯定是以增加复杂性为代价的。我相信，有了这些知识，我现在可以重新审视业务的需求，并清楚地说明他们所要求的功能的复杂性，并从逻辑上说明为什么它必须如此复杂。我认为如果我们在时间点要求上妥协并坚持基于生效日期的 AS-Was 和 AS-Is 报告，类型 6 就足够了。虽然我可能会从使用最新业务 ID 更改为持久密钥参考

【解决方案2】：

事实表已经包含与具有 SK 1、2 和 3（ID 8897、8965 和 9135）的商店相关的数据，因此您可以保留事实表，并且您将始终拥有关于这些商店，直到它们停产的日期。

当新商店 (ID 9700) 出现时，您可以将其添加为商店维度中的新行 (SK 4)，将其设置为活动行并将“停止”的商店行设置为非活动（您可以使用布尔列，例如“isActive”或“version”）。从这个时间点开始，加载到事实表中的所有数据都将指向具有 SK 4 (ID 9700) 的存储。

在该时间点之前，它只有 SK 1、2 和 3（ID 8897、8965 和 9135）的数据。因此，当您将其与事实表连接时（使用 SK），您将始终能够通过使用 Store 维度中的 isActive 字段来查看过去商店和/或当前商店的数据。

这被称为Slowly Changing Dimension Type 2：

此方法通过使用单独的代理键和/或不同的版本号为维度表中的给定自然键创建多条记录来跟踪历史数据。每次插入都会保留无限的历史记录。

编辑：关于您问题的第二部分，“所需的灵活性是，我可以通过合并 SK 1、2 和 3 在历史上存在 9700 之前将其拉到 9700 em>"

一个简单的选择是将层次结构（父商店 -> 商店）引入到商店维度中，并且对于其他每个商店，将“父商店 ID”字段设置为 9700。这样您就可以浏览销售数据专门针对每个过去的商店，通过使用他们的 ID，或者只是探索父商店（父 ID = 9700）的数据，这将提供父 9700 下所有商店的所有数据的聚合视图。

这还有一个额外的好处，就是让 Store 维度中的数据准确地描述了发生的事情：商店被合并到一个实体中，并且没有任何历史数据丢失（如果我们覆盖它们的 ID，可能会发生这种情况）。

【讨论】：

将其视为简单 SCD 2 的问题在于，它没有显示任何地方三家商店合并形成一个商店 9700。当我拉销售报告时，所需的灵活性是我可以拉它通过合并SK 1、2和3（ID 8897、8965和9135）在历史上存在于9700之前的9700。由于 SCD 类型 2 未捕获合并信息。我将无法显示拼接的数据历史记录。
那为什么不 1) 将维度更新为 SCD 并添加一行来表示商店 "9700+8897+8965+9135" ； 2）创建一个新的事实表，例如FactSalesMerged，包含销售指标的副本，但指向维度的新成员。这样，当您需要销售数据的历史和合并视图时，您可以参考这个特定的事实表。
另一种选择是将层次结构（父商店 -> 商店）引入商店维度，并且对于其他每个商店，将“父商店 ID”字段设置为 9700。这样您可以专门探索每个过去商店的销售数据，或者只探索父商店（这将提供数据的聚合视图）。添加为答案的编辑。
我不确定您建议的 FactSalesMerged 表。我更倾向于您的“父存储密钥”的第二个选项。这就像在维度表中引入一个持久键，并在事实表中为父存储键添加另一列。这样我认为可以为当前商店或父商店检索数据。实质上，将 SK4 密钥涓涓细流，使其成为合并存储的父存储密钥。但是，当稍后 Sk4 拆分为两个存储区时会发生什么，Sk5 和 Sk6 sk5 和 sk6 的父存储键是什么，还有 sk4 我们是否全部更新？和什么？
实际上，提议的业务/域概念似乎存在于您的案例中：一些商店将合并到“父”商店中，有些则不会。对于 SK5 和 SK6，您可以有无父商店的商店概念，这些商店的父商店 ID 可能等于子商店 ID。