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