如何为传入的事实记录获取精确的代理键

How to get the precise surrogate key for the incomming fact records

我正在为我的公司构建数据仓库。最近,我刚刚意识到我的 SCD 类型 2 维度实现中存在一些漏洞(可能非常危险),所以我必须重新审查它。

SCD 类型 2 维度 table 的当前 "fromdate" 是它到达数据仓库的日期,或者它替换旧记录的日期,"todate"通常为 null,或者具有相同自然键的新记录取代旧记录的日期。

目前,在加载事实时,我通过使用自然键和条件 iscurrent = true 或 todate = null 获取该事实的代理键。

我只是意识到这并不能保证代理键的正确性,例如:

  1. 如果更改发生在 11:00AM 会怎样?这意味着:当天发生的交易有一半与旧维度记录相关,但有一半与新维度记录相关。但是当数据来到数据仓库时,当天的所有交易都会被视为与新维度相关,这是不正确的。

  2. 如果我们使用事务的日期时间来更精确地获取代理键,那么在将事实记录加载到数据仓库时,所有在该维度到达数据仓库之前发生的事务都会无法找到与其相关的任何维度代理键。例如:我昨天创建了维度 table,因此该 SCD 2 维度 table 中的所有开始日期都将具有昨天的最小值,而几乎所有旧交易(尚未加载到数据仓库)发生在那天之前。所以他们将没有代理键。这样的悖论。

  3. 我什至尝试通过合并行的开始日期、尝试在 OLTP 系统中传递该维度行的创建日期来使其更精确。但我仍然找不到最正确的方法。首先Data Warehouse和OLTP系统的datetime不一样(因为它们可能属于不同的GMT+X)...

  4. 还有很多其他问题.....

我了解到,如果我们想要非常精确地跟踪历史记录,唯一的方法就是我们必须在OLTP系统中实现,直接将相关实体写入交易记录。数据仓库做不到。但是我还是觉得SCD 2的概念漏洞太多,或者说我没有正确实现SCD Typ2 2系统。所以请教我以上问题是否正常,或者指出我理解中的错误。

  1. 如果时间很重要,请使用 datetime 而不是 date。但首先要考虑时间是否重要

  2. 再次使用datetime

  3. 解决
  4. 确定您的数据仓库所在的时区。

    • UTC
    • 源系统
    • 本地系统
    • 时区感知数据类型

请注意:我建议您使用 2099-01-01 而不是 NULL 作为当前记录的结束日期。然后,您可以在搜索匹配的维度成员时轻松使用 between

  1. 你需要更具体

编辑:

目前根据评论的一个观察:不要使用Is_Current查找代理键,使用交易中的业务键和交易日期时间之间[=55] =] 维度开始和结束日期。

这意味着您可以重新加载三个月前的数据,它会选择正确的维度成员(而不是当前维度成员)

这强化了我的其他评论,即不对活动记录结束日期使用 NULL。而是使用未来的日期时间方式。所以你总是可以这些日期之间得到一个结果