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