我刚刚发现了 DW 的累积快照设计。
我需要记录来自我的错误跟踪器的错误信息。错误有一些信息（错误编号、句子...）。它也有状态： 创建， 取消， 做作的， 解决了
一个错误不必经历所有的状态（它可以从创建到取消，或者从创建到受影响到解决......）
这是我的中心事实表
FT_Bug_Track
idBug 整数
BugSentence varhchar(100)
创建日期日期
解决日期日期
受影响日期日期
取消日期日期
FKStatus int
状态外键只是链接到一个维度，告诉我我当前处于哪个状态（创建，取消......）
（当然我还有其他维度，比如项目、客户、typeOfBug ...）
每当我的错误状态发生变化时，我都会在需要的地方添加一个新日期并将 FKStatus 更新为当前日期
我的设计是否适合 DW 和我的系统？
【问题讨论】：
标签： database-design data-warehouse snapshot
我不知道这是否适合您的情况，这取决于您的要求，即您需要能够在报告中显示的内容。因此，如果您不清楚数据将如何被使用以及用户希望从中发现什么，您应该在做出任何重大设计决策之前先这样做。
话虽如此，如果某件事经历了（相对）明确、稳定的一系列步骤，例如制造流程或贷款审批，那么累积快照的效果最好。不幸的是，错误跟踪器很少出现这种情况：工单可以重新分配给其他人，而不会改变其状态；它们可以重新打开并再次完成整个解决过程；他们可以在“开发中”和“测试中”等之间来回“反弹”。这意味着您无法提前知道在一张票的整个生命周期内需要多少个日期和状态（除非您的流程异常简单）。
我最近处理了一些帮助台报告，并提出了一个使用两个事实表的解决方案。第一个每张工单有一行，仅显示当前状态（新、已分配、已关闭等），仅带有“创建”和“最后修改”的时间戳。第二个事实表每次修改工单都有一行，因此您可以深入了解工单的详细历史记录。值得注意的是，工单的许多常见更改实际上并不会更改状态（例如添加评论），因此您需要确定您的情况是什么“修改”：任何更改，还是仅更改状态？
ETL 流程计算并维护第一个事实表上的工单级 KPI，例如工单已经（或曾经）打开了多长时间，从提交工单到首次分配工单之间的时间等。报告用户（例如经理) 通常对两个特定事件之间的持续时间感兴趣，并且处理重复或循环过程并不是特别容易。出于这个原因，我会尝试使用主（聚合）事实表生成大多数报告，而将第二个主要用于交互式分析，但一切都取决于您想从数据中得到什么。
即使这不能回答你的问题，我希望它能给你一些想法。
【讨论】：