我正在构建一个维度数据仓库，并学习如何从我仓库中的源系统建模各种业务流程。
我目前正在为＆＃34; Bid＆＃34; （从工作中竞标）从我们的数据仓库中的源系统作为事实表，其中包含以下信息：
问题在于，出价（或我尝试建模的大多数其他过程）可以通过各种状态，并在源系统中的任何给定时刻更新其信息。根据Ralph Kimball的说法，事实表只有在被认为是＆＃34;积累快照时才会更新。并且我确信并非所有这些过程都被视为＆＃34;累积快照＆＃34;按照下面的定义。
根据Kimball小组的建议，如何在数据仓库中建模这些类型的流程？此外，什么类型的事实表可以用于投标（鉴于我上面概述的事实）？
http://www.kimballgroup.com/2008/11/fact-tables/
的异常交易谷物对应于单个测量 瞬间。杂货店的嘟嘟声是一种交易谷物。测量 事实仅对该瞬间和该事件有效。下一个 测量事件可能发生在一个毫秒之后或下个月或 决不。因此，事务谷物事实表是不可预测的稀疏或 稠密。我们无法保证所有可能的外键都是 表示。交易谷物事实表可能是巨大的，随着 最大的包含数十亿条记录。
定期快照颗粒对应于预定义的时间跨度， 通常是财务报告期。图1说明了每月一次 帐户定期快照。测量的事实总结了活动 在时间跨度期间或结束时。定期快照粒 为所有报告实体提供强有力的保证（例如 因为图1中的银行帐户将出现在每个快照中，即使 没有活动。定期快照可预测密集，并且 应用程序可以依赖始终存在的密钥组合。 定期快照事实表也可能变大。一家20岁的银行 百万个帐户和10年历史将有24亿条记录 在月度帐户定期快照！
累积快照事实表对应于可预测的 具有明确定义的开始和结束的过程。订单处理， 索赔处理，服务电话解决和大学录取 典型的候选人订单累积快照的粒度 例如，处理通常是订单上的订单项。注意 在图1中，有多个日期代表标准 订单经历的情景。累积快照记录是 随着流程的进展，重新审视和覆盖 从开始到结束。通常累积快照事实表 由于这种覆盖，比其他两种类型小得多 策略。
答案 0 :(得分：1)
正如其中一条评论所提到的，变更数据捕获是一个相当通用的术语，如何随着时间的推移处理数据实体的变化＆＃34;并且有完整的书籍（以及无数的帖子和文章）。
无论任何声明似乎暗示着明确的黑白或总是喜欢这样的答案，真正的答案，就像往常一样，它取决于＆＃34; - 在你的情况下，你的特定事实表需要什么颗粒。
如果您的数据以不可预测的方式或经常发生变化， 可能难以实施Kimball的累积快照版本（图片中有多少＆＃） 34;里程碑＆＃34;日期列等，你可能最终需要）。
因此，如果您愿意，您可以决定将您的事实表设为事务性事实表而不是快照，其中事实键将是（Bid Key，Timestamp），然后是您的应用程序层（无论是视图，mview，实际应用程序还是其他），您可以确保给定查询仅获取每个Bid的最新版本（请注意，可以被认为是一种虚拟的累积快照）。如果您发现自己不需要以前的版本（每个出价的历史），您可以使用例程来修剪它们（即删除或移动它们在其他地方）。
或者，您只能允许在其处于最终状态时添加事实（Bid），但是如果新的（可更新的）出价没有显着延迟，您可能会有很大的延迟把它带到事实表一段时间。
无论哪种方式，都有几种可靠且经过验证的技术可以解决这个问题 - 您只需要明确地确定业务需求并进行相应的设计。
祝你好运！