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