3

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

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

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

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

根据 Kimball 小组的建议，这些类型的流程应该如何在数据仓库中建模？此外，哪种类型的事实表适用于投标（鉴于我上面概述的事实）？

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

交易粒度对应于在单个瞬间进行的测量。杂货店哔哔声是一种交易谷物。测量的事实仅对那个瞬间和那个事件有效。下一个测量事件可能会晚一毫秒或下个月发生，或者永远不会发生。因此，事务粒度事实表是不可预测的稀疏或密集。我们不能保证所有可能的外键都会被表示。事务粒度事实表可能非常庞大，其中最大的包含数十亿条记录。

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

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

4

1 回答 1

1

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

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

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

因此，如果您愿意，您可以决定让事实表成为事务事实表而不是快照，事实键将是（Bid Key、Timestamp），然后在您的应用程序层（无论是视图、mview、实际应用程序或其他任何东西），您可以确保给定查询仅获取每个投标的最新版本（请注意，这可以被认为是一种虚拟累积快照）。如果你发现你不需要以前的版本（每个投标的历史），你可以有一个修剪它们的例程（即删除或移动它们到其他地方）。

或者，您只能允许在其处于最终状态时添加事实 (Bid)，但随后您可能会有明显的滞后，即新的（可更新的）Bid 在一段时间内无法进入事实表.

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

祝你好运！

于 2015-12-28T15:59:05.297 回答