我正在建立一个维度数据仓库,并学习如何从我的仓库中的源系统中为各种业务流程建模。
我目前正在将数据仓库中源系统中的“出价”(工作出价)建模为事实表,其中包含以下信息:
问题在于出价(或我尝试建模的大多数其他过程)可能会经历各种状态,并且在源系统中的任何给定时刻都会更新其信息。根据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),但是在新的(可更新的)出价一段时间内未将其添加到事实表中的情况下,您可能会遇到很大的滞后。
无论哪种方式,都有几种可靠的可靠技术可以解决此问题-您只需要清楚地确定业务需求并进行相应的设计即可。
祝你好运!