包含可在源系统中定期更新的信息的事实表

我正在构建一个维度数据仓库，并学习如何从仓库中的源系统对各种业务流程进行建模。

我目前正在将数据仓库中源系统的“投标”（工作投标）建模为事实表，其中包含以下信息：

• 投标金额
• 预计收入
• 销售人员
• 出价状态（有效、待定、拒绝等）
• etc.

问题在于，出价（或我尝试建模的大多数其他流程）可以经历各种状态，并在源系统中的任何给定时刻更新其信息。根据 Ralph Kimball 的说法，事实表只有在被视为“累积快照”时才应更新，并且我确信并非所有这些进程都会根据下面的定义被视为“累积快照”。

根据 Kimball 小组的建议，应如何在数据仓库中对这些类型的流程进行建模？此外，什么类型的事实表适用于出价（考虑到我上面概述的事实）？

摘自http://www.kimballgroup.com/2008/11/fact-tables/ http://www.kimballgroup.com/2008/11/fact-tables/

交易粒度对应于在单个交易中进行的测量 立即的。杂货店的蜂鸣声是一种交易谷物。测得的 事实仅对该时刻和该事件有效。下一个 测量事件可能会在一毫秒后或下个月发生，或者 绝不。因此，事务粒度事实表是不可预测的稀疏或 稠密。我们不能保证所有可能的外键都会被 代表。事务粒度事实表可能非常庞大， 最大的包含数十亿条记录。

周期性快照粒度对应于预定义的时间跨度， 通常是一个财务报告期。图 1 说明了每月 账户定期快照。测量的事实总结了活动 在时间跨度期间或结束时。周期性快照粒度 为所有报告实体（例如 （如图 1 中的银行帐户）将出现在每个快照中，即使 没有活动。周期性快照的密度是可以预见的，并且 应用程序可以依赖始终存在的按键组合。 定期快照事实表也可能变得很大。一家银行有20 万个账户和 10 年历史将有 24 亿条记录 在每月帐户定期快照中！

累积快照事实表对应于可预测的 具有明确定义的开始和结束的过程。订单处理， 索赔处理、服务呼叫解决和大学招生 典型的候选人。订单累积快照的粒度 例如，处理通常是订单上的行项目。注意 图1中有多个代表标准的日期 订单所经历的场景。累积快照记录为 随着流程的逐步进展而重新访问和覆盖 从开始到结束。累积快照事实表一般是 由于这种覆盖，比其他两种类型小得多 战略。

就像其中一条评论提到的那样，更改数据捕获是一个相当通用的术语，表示“随着时间的推移，我如何处理数据实体的更改”，并且有关于它的整本书（以及无数的帖子和文章）。

不管任何似乎暗示一个明确的黑白或总是这样做的答案的陈述，真正的答案，像往常一样，是“这取决于” - 在你的情况下，取决于你需要什么谷物您的特定事实表。

如果您的数据以不可预测的方式或非常频繁地发生变化，can实施 Kimball 的版本变得具有挑战性累积快照（想象一下您最终可能需要多少个“里程碑”日期列等）。

因此，如果您愿意，您可以决定将事实表设为事务事实表而不是快照，其中事实键为（出价键、时间戳），然后在您的应用层（无论是视图、mview、实际应用程序还是其他），您可以确保给定的查询仅获取最新的version每个出价（请注意，这可以被认为是一种虚拟的累积快照）。如果您发现不需要以前的版本（history每个出价的），您可以有一个例程来修剪它们（即删除或将它们移动到其他地方）。

或者，您只能允许在事实（出价）处于最终状态时添加事实（出价），但是这样您可能会出现明显的滞后，新的（可更新的）出价在一段时间内无法进入事实表。

无论哪种方式，都有几种可靠且经过验证的技术来处理此问题 - 您只需清楚地识别业务需求并进行相应的设计即可。

祝你好运！