阅读了许多有关事实表（交易、累积、定期）等的 Kimball 设计技巧。我仍然不清楚我应该如何处理更新事实表的情况，我认为这并不罕见。到案例。
我们正在处理客户的投诉，我们希望能够在数据仓库中反映投诉的当前状态。我们的投诉有一个处理状态的工作流程，不同的受让人按时处理它们，但对于我们的分析来说，到目前为止这与我们无关。我们想回顾一下目前的投诉情况。
据我了解，事实表的粒度将是单一投诉，列（与这个问题无关，是否应该是垃圾维度、退化等），例如：
据我了解，由于我们不想查看流程历史记录，而是想查看流程的当前状态，因此为每个投诉存储代表其状态的多行是一种矫枉过正，因此我们只存储一个每个投诉行并更新它。
现在，我这样做的推理正确吗？在上面的情况下，投诉数量和投诉类型存储的值不会改变，而“当前”列会改变，我们需要更新行，因此我们可以实现更改数据捕获机制（就像我们现在对维度所做的那样）将来自源系统的传入行与当前存储的事实行进行比较，以提高此类操作的时间成本。
老实说，对我来说它看起来像是一个混合了 SCD 类型 0 和 1 的 Dimension 表，但它存储了收到投诉的事实。
SO 帖子供参考：包含在源系统中定期更新的信息的事实表
编辑
我知道我可以使用带有时间戳的累积事实表，这有点类似于 SCD 类型 2，但最终用户并不真正关心该过程的历史记录。稍后的分析涉及更多事实，因此将这种需求与数据仓库分开在这种情况下并没有真正起作用。
我过去遇到过类似的用例，其中累积快照将是默认解决方案。
但是，累积快照不允许进程具有不同的长度。我设计了一种不同的模式，为每个事件添加 2 行：如果一个对象从状态 A 转到状态 B，您首先插入状态 A 和数量 -1 的行，然后插入状态 B 和数量 + 的新行1.
最终结果允许： - 无需更新，只需插入； - 地图缩减友好； - 任意长度的过程； - 计算任意时间点每种状态的数量（出于性能原因，借助定期快照）； - 在任何时间点有多少人进入或离开任何州； - 计算每个州的时间和总体年龄。
此处有 5 篇博客文章详细信息（在 Pentaho 数据集成中实现）：
http://ubiquis.co.uk/dwh/status-change-fact-table-part-1-the-problem/
基本上，您只需将行插入表中，并有一个时间戳列。这样您就可以记录所有更改。当您想要当前状态时，您只需获取最新行。