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