应用错误收集

根据DW众神，有3种类型的FACT表

交易：您使用暗淡参考的基本测量。没有汇总或总结的测量结果，大量的DIM关系
定期：在规定的时间段内汇总交易事实表的摘要。
累积快照：与2个以上定义的时间段相关的测量值

从这些中我们至少有两个选项可以产生与缓慢变化的事实表非常相似的东西。这一切都取决于您的源系统的设置方式。

选项1：基于交易的源系统

如果您的源系统通过一系列事务跟踪对测量的更改（即初始值+值的变化+更改值等），那么这些事务中的每一个都会在事务事实中结束。然后，周期性事实表使用它来反映“截至期间”的度量。

例如，如果您的源系统跟踪进出帐户的资金，您可能会有一个事务事实表，它几乎反映了源钱/进出表。您还会有一个周期性事实表，每个期间（在本例中为月份）都会更新，以反映该期间帐户的总价值

周期性事实表是您的慢速变化事实表。

Source               DW_Tansaction_Fact       DW_Periodic_Fact
---------------  ->  -------------------  ->  --------------------
Acnt1 Jan +10$       Acnt1 Jan +10$           Acnt1 Jan 10$
Acnt1 Feb -1 $       Acnt1 Feb -1 $           Acnt1 Feb  9$
Acnt1 Apr +2 $       Acnt1 Apr +2 $           Acnt1 Mar  9$
                                              Acnt1 Apr 11$

选项2：CRUD /覆盖源系统

您更有可能拥有一个允许用户直接更新/替换业务度量的源系统。在任何时间点，根据源系统，每个度量只有一个值。您可以在ETL过程中通过一些聪明的诡计来进行此交易，但您唯一可能会获得受ETL计划限制的交易窗口。

在这种情况下，您可以使用Periodic Fact表或累积事实表。

让我们坚持使用我们的帐户示例，但表格只是存储每个帐户的金额值，而不是交易。这根据源系统的要求进行了更新，因此对于Acnt1，1月份是10美元，2月9日和4月11日美元

坚持交易和期间事实表，我们最终得到这些数据（截至4月底）。同样，周期性事实表是您的慢速变化事实表。

DW_Tansaction_Fact       DW_Periodic_Fact
 -------------------  ->  --------------------
Acnt1 11$                 Acnt1-Jan-10$
                          Acnt1-Feb-09$
                          Acnt1-Mar-09$
                          Acnt1-Apr-11$

但我们也可以使用累积事实表，其中可以包含给定年份的所有月份值。

DW_Accumlative_Fact_CrossTab
Year Acnt  Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
2001 Acnt1 10  9   9   11  -   -   -   -   -   -   -   -

或更多type3-ish版本

DW_Accumlative_Fact_CrossTab
Acnt    Year   YearStartVal   CurrentVal
Acnt1   2001   10             9

有点相关

根据我的经验，当这种常见的业务场景出现时会出现这类问题：

有一个带有数据库的核心业务系统。
业务定期发布报告，按核心业务系统
核心业务系统允许追溯更新数据 - 这是通过覆盖值来处理的。
业务需要知道为什么6月份同一报告中的1月份数据不再与2月份报告中的1月数据相符。

请注意，您现在正在处理四组时间（报告的初始阶段，初始阶段的测量，当前报告期间，当前时间段的测量），这对您来说很难解释，更不用说您的最终用户了了解。

尝试退后一步，向最终用户解释哪些业务指标随时间变化，聆听他们想要的结果并相应地构建您的事实。请注意，对于相同的度量，您最终可能会得到多个事实表，这样就可以了。

参考：

是否存在数据仓库中缓慢更改FACT的概念

1 个答案: