sql-update - 数据仓库事实表中的更新

阅读有关事实表（事务、累积、定期）等的许多 Kimball 设计技巧。我仍然不清楚我应该如何处理我认为并不少见的更新事实表的情况。到案子。

我们正在处理来自客户的投诉，我们希望能够在数据仓库中反映投诉的当前状态。我们的投诉有一个他们经历的状态工作流程，不同的受让人按时处理他们，但对于我们的分析来说，这与现在无关。我们想回顾一下投诉的现状。

据我了解，事实表的粒度将是单一的投诉，带有列（与这个问题无关，它是否应该是垃圾维度、退化等），例如：

据我了解，由于我们不想查看流程历史记录，而是查看流程的当前状态，因此为每个表示其状态的投诉存储多行是一种矫枉过正的做法，因此我们只存储一行每个投诉并更新它。

现在，我的推理正确吗？在上述情况下，投诉数量和投诉类型存储值不会更改，而“当前”列会更改，我们需要更新行，因此我们可以实现更改数据捕获机制（就像我们现在对维度所做的那样）将来自该事实的源系统的传入行与当前存储的事实行进行比较，以提高此类操作的时间成本。

老实说，对我来说，它看起来像一个混合 SCD 类型 0 和 1 的维度表，但它存储了接收投诉的事实。

编辑

我知道我可以使用带有时间戳的累积事实表，这有点类似于 SCD 类型 2，但最终用户并不真正关心该过程的历史。稍后在分析中涉及更多事实，因此在这种情况下，将这种需求与数据仓库分开并不起作用。

标签： sql-updatedata-warehousefact

我过去遇到过类似的用例，其中累积快照将是默认解决方案。

但是，累积快照不允许具有不同长度的进程。我设计了一种不同的模式，为每个事件添加 2 行：如果一个对象从状态 A 转到状态 B，您首先插入状态 A 和数量 -1 的行，然后插入状态 B 和数量 + 的新行1.

最终结果允许： - 无需更新，仅插入；- 地图减少友好；- 任意长度的进程；- 在任何时间点计算每个状态中每个状态的数量（出于性能原因，借助定期快照）；- 在任何时间点有多少人进入或离开任何状态。- 计算每个州的时间和总体年龄。

此处 5 篇博文中的详细信息（在 Pentaho 数据集成中实现）：