我正在建立一个维度数据仓库，并学习如何从我的仓库中的源系统中为各种业务流程建模。
我目前正在将数据仓库中源系统中的“出价”（工作出价）建模为事实表，其中包含以下信息：
问题在于出价（或我尝试建模的大多数其他过程）可能会经历各种状态，并且在源系统中的任何给定时刻都会更新其信息。根据Ralph Kimball的说法，只有在事实表被视为“累积快照”的情况下，才应更新事实表，而且我敢肯定，以下定义将并非所有这些过程都被视为“累积快照”。
根据Kimball组的建议，应如何在数据仓库中对这些类型的过程进行建模？此外，哪种类型的事实表适用于出价（考虑到我上面概述的事实）？
来自http://www.kimballgroup.com/2008/11/fact- tables/的证书
交易量对应于在单个瞬间进行的测量。杂货店的哔哔声是一笔交易。测得的事实仅对那个瞬间和那个事件有效。下一次测量事件可能会在毫秒后或下个月发生，甚至永远不会发生。因此，事务粒度事实表稀疏或密集。我们不能保证所有可能的外键都会被表示。交易粒度事实表可能非常庞大，最大的事实表包含数十亿条记录。 定期快照粒度对应于预定义的时间跨度，通常是财务报告期。图1说明了每月帐户定期快照。测得的事实总结了在该时间段内或该时间段结束时的活动。定期快照粒度可以强有力地保证所有报告实体（例如图1中的银行帐户）将出现在每个快照中，即使没有活动也是如此。定期快照是可以预见的，并且应用程序可以依赖始终存在的密钥组合。定期快照事实表也可能很大。一家拥有2000万个帐户且具有10年历史的银行，在月度帐户定期快照中将有24亿条记录！ 累积快照事实表对应于具有明确定义的开始和结束的可预测过程。订单处理，索赔处理，服务电话解决和大学录取是典型的候选人。例如，用于订单处理的累积快照的粒度通常是订单上的行项目。请注意，在图1中，有多个日期代表订单经历的标准情况。随着过程从头到尾逐步进行，将重新访问和覆盖累积的快照记录。由于这种覆盖策略，累积快照事实表通常比其他两种类型小得多。
交易量对应于在单个瞬间进行的测量。杂货店的哔哔声是一笔交易。测得的事实仅对那个瞬间和那个事件有效。下一次测量事件可能会在毫秒后或下个月发生，甚至永远不会发生。因此，事务粒度事实表稀疏或密集。我们不能保证所有可能的外键都会被表示。交易粒度事实表可能非常庞大，最大的事实表包含数十亿条记录。
定期快照粒度对应于预定义的时间跨度，通常是财务报告期。图1说明了每月帐户定期快照。测得的事实总结了在该时间段内或该时间段结束时的活动。定期快照粒度可以强有力地保证所有报告实体（例如图1中的银行帐户）将出现在每个快照中，即使没有活动也是如此。定期快照是可以预见的，并且应用程序可以依赖始终存在的密钥组合。定期快照事实表也可能很大。一家拥有2000万个帐户且具有10年历史的银行，在月度帐户定期快照中将有24亿条记录！
累积快照事实表对应于具有明确定义的开始和结束的可预测过程。订单处理，索赔处理，服务电话解决和大学录取是典型的候选人。例如，用于订单处理的累积快照的粒度通常是订单上的行项目。请注意，在图1中，有多个日期代表订单经历的标准情况。随着过程从头到尾逐步进行，将重新访问和覆盖累积的快照记录。由于这种覆盖策略，累积快照事实表通常比其他两种类型小得多。
就像其中提到的一条评论一样，“更改数据捕获”是一个相当通用的术语，表示“我如何处理随着时间的推移对数据实体所做的更改”，并且整本书都在上面（以及大量的文章和文章）。
不管似乎有明确的黑白或总是这样做的陈述，此答案的真实答案通常是“取决于”-在您的情况下，取决于您需要的谷物您的特定事实表。
如果你的数据在不可预知的方式改变或很多时候，它 可 成为具有挑战性实施的Kimball的版本 积累的快照 （图片多少个“里程碑”日期栏等，你可能最终需要）。
因此，如果您愿意，可以决定将事实表设为 事务性事实表， 而不是快照，事实键应为（出价键，时间戳），然后在 应用程序 层（无论是视图，mview，实际的应用程序或其他应用程序），您可以确保给定的查询仅获取每个Bid的最新 版本 （请注意，这可以视为一种虚拟的 累积快照 ）。如果您发现不需要以前的版本（每个出价的 历史记录 ），则可以使用一个例程来修剪它们（例如，将它们删除或移动到其他位置）。
或者，您只能在事实（Bid）处于最终状态时才添加事实（Bid），但是在新的（可更新的）出价一段时间内未将其添加到事实表中的情况下，您可能会遇到很大的滞后。
无论哪种方式，都有几种可靠的可靠技术可以解决此问题-您只需要清楚地确定业务需求并进行相应的设计即可。
祝你好运！
