我的累积快照设计是不是适合我的 DW 和我的需要

Posted 2023-03-29

【中文标题】我的累积快照设计是不是适合我的 DW 和我的需要

【英文标题】：Is my accumulating snapshot design correct for my DW and my need我的累积快照设计是否适合我的 DW 和我的需要

【发布时间】：2013-04-05 09:46:43

【问题描述】：

我刚刚发现了 DW 的累积快照设计。

我需要记录来自我的错误跟踪器的错误信息。错误有一些信息（错误编号、句子...）。它也有状态： 创建， 取消， 做作的， 解决了

一个错误不必经历所有的状态（它可以从创建到取消，或者从创建到受影响到解决......）

这是我的中心事实表

FT_Bug_Track

---

idBug 整数

BugSentence varhchar(100)

创建日期日期

解决日期日期

受影响日期日期

取消日期日期

FKStatus int

状态外键只是链接到一个维度，告诉我我当前处于哪个状态（创建，取消......）

（当然我还有其他维度，比如项目、客户、typeOfBug ...）

每当我的错误状态发生变化时，我都会在需要的地方添加一个新日期并将 FKStatus 更新为当前日期

我的设计是否适合 DW 和我的系统？

【参考方案1】：

我不知道这是否适合您的情况，这取决于您的要求，即您需要能够在报告中显示的内容。因此，如果您不清楚数据将如何被使用以及用户希望从中发现什么，您应该在做出任何重大设计决策之前先这样做。

话虽如此，如果某件事经历了（相对）明确、稳定的一系列步骤，例如制造流程或贷款审批，那么累积快照的效果最好。不幸的是，错误跟踪器很少出现这种情况：工单可以重新分配给其他人，而不会改变其状态；它们可以重新打开并再次完成整个解决过程；他们可以在“开发中”和“测试中”等之间来回“反弹”。这意味着您无法提前知道在一张票的整个生命周期内需要多少个日期和状态（除非您的流程异常简单）。

我最近处理了一些帮助台报告，并提出了一个使用两个事实表的解决方案。第一个每张工单有一行，仅显示当前状态（新、已分配、已关闭等），仅带有“创建”和“最后修改”的时间戳。第二个事实表每次修改工单都有一行，因此您可以深入了解工单的详细历史记录。值得注意的是，工单的许多常见更改实际上并不会更改状态（例如添加评论），因此您需要确定您的情况是什么“修改”：任何更改，还是仅更改状态？

ETL 流程计算并维护第一个事实表上的工单级 KPI，例如工单已经（或曾经）打开了多长时间，从提交工单到首次分配工单之间的时间等。报告用户（例如经理) 通常对两个特定事件之间的持续时间感兴趣，并且处理重复或循环过程并不是特别容易。出于这个原因，我会尝试使用主（聚合）事实表生成大多数报告，而将第二个主要用于交互式分析，但一切都取决于您想从数据中得到什么。

即使这不能回答你的问题，我希望它能给你一些想法。

【讨论】：

感谢这个完整的答案。我承认我不知道用户到底想要什么，所以我必须稍后再找他们确定。我所知道的是，主要用途是检查每月创建、解决、取消了多少错误......

我正在考虑我的问题，我认为 SCD 也可能是一个很好的解决方案，因为我没有经历所有的状态。所以有了这个解决方案，我总是知道我当前的状态和以前的状态。我的基本需求是知道创建了多少错误，并且使用此解决方案我仍然很容易。

是的，如果您的基本需求是对每个提交者或每个问题区域或其他任何问题的错误数量进行高级概述，那么实现起来非常简单。准确跟踪每张工单的整个生命周期并非易事，所以如果您不需要它，那么您当然可以寻求简单的解决方案，避免很多复杂的问题。