根据 DW 大神的说法，FACT 表有 3 种类型
-
交易：你的基本测量与暗参考。测量值未汇总或汇总，大量 DIM 关系
-
定期：在定义的时间段内汇总事务事实表的摘要。
-
累积快照：与 2 个以上定义的时间段相关的测量
从这些我们至少有 2 个选项将导致非常类似于缓慢变化的事实表。这完全取决于您的源系统是如何设置的。
选项 1：基于事务的源系统
如果您的源系统通过一系列事务（即初始值 + 值变化 + 变化值等）跟踪测量值的变化，那么这些事务中的每一个都以事务事实结束。然后，周期事实表使用它来反映“截至周期”的度量。
例如，如果您的源系统跟踪账户的资金进出，您可能会有一个交易事实表，该表几乎反映了源资金进/出表。您还将有一个周期事实表，该表将在每个周期（在本例中为月份）更新，以反映该周期的帐户总值
周期事实表是您的缓慢变化事实表。
源 DW_Tansaction_Fact DW_Periodic_Fact
--------------- -> ------- -> ------------ --------
账户 1 月 +10$ 账户 1 月 +10$ 账户 1 月 10$
账户 1 月 -1 美元 账户 1 月 -1 美元 账户 1 月 9 美元
Acnt1 Apr +2 $ Acnt1 Apr +2 $ Acnt1 Mar 9$
帐户 1 月 11 日$
选项 2：CRUD/覆盖源系统
您更有可能拥有一个可以让用户直接更新/替换业务度量的源系统。在任何时间点，根据源系统，每个度量都有并且只有一个值。您可以通过 ETL 流程中的一些巧妙技巧来进行此交易，但您只会获得一个受 ETL 时间表限制的交易窗口。
在这种情况下，您可以使用周期性事实表或累积事实表。
让我们继续使用我们的帐户示例，但该表仅存储每个帐户的金额值，而不是交易。这在源系统中根据需要进行了更新，因此对于 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
年份 账户 1 月 2 月 3 月 4 月 5 月 6 月 7 月 8 月 9 月 10 月 11 月 12 月
2001 年 1 月 10 9 9 11 - - - - - - - -
或者更类似于 type3 的版本
DW_Accumlative_Fact_CrossTab
帐户 年份 YearStartVal CurrentVal
帐户 1 2001 10 9
种类相关
根据我的经验，当这种常见的业务场景出现时会出现此类问题：
- 有一个带有数据库的核心业务系统。
- 业务定期发布报告，按时间段汇总来自核心业务系统的值
- 核心业务系统允许追溯更新数据 - 这通过覆盖值来处理。
- 企业需要了解为什么 6 月份运行的同一报告中的 1 月份数据与 2 月份运行的报告中的 1 月份数据不再匹配。
请注意，您现在正在处理四组时间（报告的初始期间、初始期间日期的测量、当前报告期间、当前期间的测量），这对您来说很难解释，更不用说您的最终用户了理解。
尝试退后一步，向您的最终用户解释哪些业务衡量指标会随着时间而变化，听取他们想要的结果并据此构建您的事实。请注意，您最终可能会针对同一度量获得多个事实表，这很好。
参考：