本文主要是介绍数据仓库——事务、快照和累积快照事实表，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
事务、快照和累积快照
- 事务事实表跟踪定义业务过程的个体行为，并且支持几种描述这种行为事实。可以提供丰富的分析型能力，时常充当原子数据的粒度化仓库
- 快照事实表周期性地采样状态度量，这些度量与一系列事务的累积效果相当，但是这些事务的格式不易进行研
- 累积快照事实表用来跟踪通过一系列处理步骤的个体项的进展情况，用于研究多数过程中里程碑或者事件的经过时间。这种事实表在单一行中关联多个不同的行为。
事务事实表
- 事务事实表用于跟踪事件，通过存储事实和与之关联的维度细节，允许单独或聚集地研究行为。
- 粒度
- 稀疏性
- 包含可加事实
事实表快照
状态度量： 度量一系列事务的效果称为状态度量，当状态度量很重要时，事务事实表是无效率的。
状态度量，通常可以从事务历史中构造出来，然而如果事务历史延伸到很远的过去，或者必须计算许多事务的状态，监控状态将是低效的办法。
无法使用事务事实表分析的原因：
- 事务设计不符合标准
- 有时不存储事务数据
- 不要为挨个事务存储状态度量
快照模型
周期性事表快照简称事实表快照。事实表快照在确定的时间间隔中对问题的度量进行抽样，这样就可以容易地研究问题的度量值，而不需要聚集长期的事务历史。
| 事务事实表 | 快照事实表 |
|---|---|
| 粒度可以以多种方式表达 | 粒度通常以维度形式声明 |
| 事务事实表是稀疏的 | 快照事实表是稠密的 |
| 事实是完全可加的 | 事实包含至少一个用来展示半可加性质的事实 |
- 用快照采用状态，快照事实表以预定的采用间隔采样状态度量。这种间隔联合一个或者多个维度，将被用来定义快照事实表的粒度。每行将包含记录所涉及状态的事实
- 快照粒度，快照的粒度必须包括采样状态的周期以及将被采样的定义，通常在维度关系中指明
- 稠密的，在快照中，不论是否存在活动，行都被记录，如果不这样做，确定状态将变得非常困难。快照事实表是稠密的，每个周期的信息被记录并与粒度声明一致，而不论是否发生任何行为
- 半可加性。快照事实表中手机的状态度量通常是半可加的，半可加事实能够用其他方法按照周期来汇总，包括计算最小值、最大值和平均值等
- 事务和快照模型能够很好的相互补充，如果都被建立起来，可以使用事务星型模式作为快照的数据源
- 周期性快照不限制存储度量状态的事实。
- 周期到日期度量，周期到日期度量通常不是存储在事务事实表中，快照事实表是周期到日期独恋在逻辑上存储的地方。
- 指定周期维度，对于周期快照，考虑表示被汇总周期的时间维度，而不是使用表示周期结束日的日维度。
- 快照与缓慢变化。周期快照仅仅为定义粒度的维度的每个自然键组合记录一行
累积快照事实表
累积快照事实表用来跟踪通过一系列处理步骤的个体项的进展情况，用于研究多数过程中里程碑或者事件的经过时间。这种事实表在单一行中关联多个不同的行为。
许多业务流程可以描述成一系列必经的阶段、步骤或状态。过程的效率往往是通过完成一个或者多个步骤所花费的时间来度量的。
间隔时间的研究要求关联多个状态，在事务模型中，每个状态变化都将记录在事实表的不同行中。但是事件彼此存在关联时就不起作用了。
事务模型存在的问题：
- 过程有效性的关键度量之一，是花费在过程中的每个步骤上的总的时间。事务模型查询编写困难，并且性能低下
- 开始与结束日期不是答案，当研究不同阶段或者不同里程碑花费时间时，描述处理步骤的事务模型是存在问题的。
累积快照设计的粒度是依照在业务流程中可识别的实体来构造的。 - 粒度，为了设计累积快照，必须可以区分被处理或者跟踪实体的唯一实例，对于考虑的实体的每个实例，都将定义一行粒度。累积快照的行在被插入后将定期更新。
- 里程碑的完成日期，快照记录了每个被监视的处理阶段的完成日期。
- 每个阶段间隔时间的事实，累积快照中的每一行都包含一组事实，从来度量每个阶段花费的天数。
- 行的生命周期，累积快照事实表将会定期更新行，处理间隔时间的事实将随着日期增长，每当实现一个新状态时，将会涉及里程碑日期。
- 使用累积快照，对研究花费在任何过程或者任何阶段的组合来讲，累积快照都是一种有效且强大的工具。
- 累积快照不能替代事务模型，许多情况下，两者能够互为补充。
- 关注关键状态里程碑，累积快照不必跟踪操作型系统中每个记录的状态变化，可以设计成通过业务来追踪关键里程碑或汇总级别的状态。
- 多源过程信息，某些情况下，有关业务过程信息不可能在一个地方获得。可能给架构设计者和ETL开发人员带来额外挑战。
- 非线性过程，许多业务过程是非线性或不可预见的，与采用标准严格的里程碑集合过程不同，这种过程可以包含可选的、交替的或者重复的步骤。这些情况不会妨碍累积快照的使用，但是在使用时需要在架构设计过程中附加严格的评估方法。不按照固定的可预见的里程碑处理过程仍然可以使用累积快照进行跟踪。需要谨慎定义在任何给定时间增长的事实的规则。如果一个特定状态完成了多次，那就需要确定使用哪个日期，这些选择应该由商业用户决定，而不是由设计者或开发人员确定。
- 缓慢变化，当由累积快照定义维度表示的事务发生类型2变化时，在维度表中关于该事务有两行，最近运行的代理键应该用于事实表中，不要使用自然键，因为这将导致双重计算。
这篇关于数据仓库——事务、快照和累积快照事实表的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
