数据仓库——事实表

事实表

事务事实表

• 事务事实表用于跟踪事件，通过存储事实和与之关联的维度细节，允许单独或聚集地研究行为。
• 粒度
• 稀疏性
• 包含可加事实

无事实的事实表

不包含事实的事实表被称作无事实的事实表。虽然没有明确地记录事实，但是却能够支持度量。

• 为事件而设的无事实的事实表，记录活动的发生，虽然没有事实被明确地存储，但是这些事件能够被计算出来，产生有意义的过程度量
• 为条件而设的无事实的事实表，用来捕获有意义的信息，这些信息并不是商业活动的一部分，条件在事件点上的不同维度关联，当与活动进行比较时，可以提供有价值的见解
  没有相关事实的活动能够放在无事实的事实表中进行跟踪，每一行是描述事件维度的外键集合。行的存在构成了度量。

无事实的事实表的使用

无事实的事实表中的事件能够通过计算行数来聚集，事实表中的任何列也都可以作为计数的基准

添加事实

当无事实的事实表在追踪事件时，可以通过增加特殊事实使类似于标准事实表。该事实表总是包含值。即使是多余的，增加的列将会使读写用于分析的sql更加容易。
无事实的设计通常会成为对持续时间和开销的度量。

条件、范围或资格

无事实的事实表也可以用在不清楚对应事件活动的情况下，这些例子都描述了条件、范围或资格。它们通常不被认为是事务或者活动。它们可以按照对活动处理的方法进行建模，使用事实表。描述条件的事实通常是无事实的。

对条件建模的原因

事实表获取维度之间的关系。事实表是海量的交叉表，在特定的环境下每行关联多个维度表的实例。处于时间点的条件也关联特定环境下的维度。条件表示没有被业务活动获取的维度之间的关系。对活动研究可以通过列出条件来着色。

用于条件的无事实的事实表

可以使用无事实的事实表对条件建模。星型模式与维度关联起来，共同表示特定时间点的条件或者针对一段时间。条件、覆盖和资格应该被建模为无事实的事实表。
比较行为和条件

缓慢变化维度和条件

当使用星型模式度量条件时，维度中的类型2缓慢变化将需要添加新的事实表行。
性能是维度设计的指导性原则。通过加载过程中而不是在查询中重构数据，对油管业务过程的分析问题回答将更加便捷。然而，有时更快捷仍然不够充分。尽管设计良好的模式能够以更合理的方式处理过程的复杂查询。随着数据集的不断增大，即时简单的查询，也可能呈现出性能低下的问题。导出模式用来存储对已有已存在的维度数据重构后的数据副本。重构后的数据结构可以改善查询性能并降低报表开发的复杂度。同样，性能的改善是以额外地加载和管理数据的工作为代价。

导出模式的开销

导出模式是要付出代价的，这种好处的获得是通过将查询和报表阶段的工作负担转嫁到ETL阶段实现的。这与数据仓库的总体目标是一致的。但必须将其作为设计决策加以考虑。导出模式也会对可用性产生影响。任何打算开发查询或者报表的人员都必须为完成任务选择适当的星型模式。

• 事务事实表跟踪定义业务过程的个体行为，并且支持几种描述这种行为事实。可以提供丰富的分析型能力，时常充当原子数据的粒度化仓库
• 快照事实表周期性地采样状态度量，这些度量与一系列事务的累积效果相当，但是这些事务的格式不易进行研
• 累积快照事实表用来跟踪通过一系列处理步骤的个体项的进展情况，用于研究多数过程中里程碑或者事件的经过时间。这种事实表在单一行中关联多个不同的行为。

事实表快照

状态度量： 度量一系列事务的效果称为状态度量，当状态度量很重要时，事务事实表是无效率的。
状态度量，通常可以从事务历史中构造出来，然而如果事务历史延伸到很远的过去，或者必须计算许多事务的状态，监控状态将是低效的办法。
无法使用事务事实表分析的原因：

• 事务设计不符合标准
• 有时不存储事务数据
• 不要为挨个事务存储状态度量

快照模型

周期性事表快照简称事实表快照。事实表快照在确定的时间间隔中对问题的度量进行抽样，这样就可以容易地研究问题的度量值，而不需要聚集长期的事务历史。

• 用快照采用状态，快照事实表以预定的采用间隔采样状态度量。这种间隔联合一个或者多个维度，将被用来定义快照事实表的粒度。每行将包含记录所涉及状态的事实
• 快照粒度，快照的粒度必须包括采样状态的周期以及将被采样的定义，通常在维度关系中指明
• 稠密的，在快照中，不论是否存在活动，行都被记录，如果不这样做，确定状态将变得非常困难。快照事实表是稠密的，每个周期的信息被记录并与粒度声明一致，而不论是否发生任何行为
• 半可加性。快照事实表中手机的状态度量通常是半可加的，半可加事实能够用其他方法按照周期来汇总，包括计算最小值、最大值和平均值等
• 事务和快照模型能够很好的相互补充，如果都被建立起来，可以使用事务星型模式作为快照的数据源
• 周期性快照不限制存储度量状态的事实。
• 周期到日期度量，周期到日期度量通常不是存储在事务事实表中，快照事实表是周期到日期独恋在逻辑上存储的地方。
• 指定周期维度，对于周期快照，考虑表示被汇总周期的时间维度，而不是使用表示周期结束日的日维度。
• 快照与缓慢变化。周期快照仅仅为定义粒度的维度的每个自然键组合记录一行

累积快照事实表

累积快照事实表用来跟踪通过一系列处理步骤的个体项的进展情况，用于研究多数过程中里程碑或者事件的经过时间。这种事实表在单一行中关联多个不同的行为。
许多业务流程可以描述成一系列必经的阶段、步骤或状态。过程的效率往往是通过完成一个或者多个步骤所花费的时间来度量的。
间隔时间的研究要求关联多个状态，在事务模型中，每个状态变化都将记录在事实表的不同行中。但是事件彼此存在关联时就不起作用了。
事务模型存在的问题：

• 过程有效性的关键度量之一，是花费在过程中的每个步骤上的总的时间。事务模型查询编写困难，并且性能低下
• 开始与结束日期不是答案，当研究不同阶段或者不同里程碑花费时间时，描述处理步骤的事务模型是存在问题的。
  累积快照设计的粒度是依照在业务流程中可识别的实体来构造的。
• 粒度，为了设计累积快照，必须可以区分被处理或者跟踪实体的唯一实例，对于考虑的实体的每个实例，都将定义一行粒度。累积快照的行在被插入后将定期更新。
• 里程碑的完成日期，快照记录了每个被监视的处理阶段的完成日期。
• 每个阶段间隔时间的事实，累积快照中的每一行都包含一组事实，从来度量每个阶段花费的天数。
• 行的生命周期，累积快照事实表将会定期更新行，处理间隔时间的事实将随着日期增长，每当实现一个新状态时，将会涉及里程碑日期。
• 使用累积快照，对研究花费在任何过程或者任何阶段的组合来讲，累积快照都是一种有效且强大的工具。
• 累积快照不能替代事务模型，许多情况下，两者能够互为补充。
• 关注关键状态里程碑，累积快照不必跟踪操作型系统中每个记录的状态变化，可以设计成通过业务来追踪关键里程碑或汇总级别的状态。
• 多源过程信息，某些情况下，有关业务过程信息不可能在一个地方获得。可能给架构设计者和ETL开发人员带来额外挑战。
• 非线性过程，许多业务过程是非线性或不可预见的，与采用标准严格的里程碑集合过程不同，这种过程可以包含可选的、交替的或者重复的步骤。这些情况不会妨碍累积快照的使用，但是在使用时需要在架构设计过程中附加严格的评估方法。不按照固定的可预见的里程碑处理过程仍然可以使用累积快照进行跟踪。需要谨慎定义在任何给定时间增长的事实的规则。如果一个特定状态完成了多次，那就需要确定使用哪个日期，这些选择应该由商业用户决定，而不是由设计者或开发人员确定。
• 缓慢变化，当由累积快照定义维度表示的事务发生类型2变化时，在维度表中关于该事务有两行，最近运行的代理键应该用于事实表中，不要使用自然键，因为这将导致双重计算。

融合事实表

消除了使用多步横向钻取过程的需要。

融合事实表将一个或者多个星型模式中的事实合并为单一的事实表，产生的星型模式可以用于横向钻取。开展过程比较工作。采用融合事实表表时，不再需要进行横向钻取。除了简化查询，融合事实表还可以极大地改善性能。

通过预先计算横向钻取活动，融合事实表从多个事实表中合并事实，这使得跨过程分析的查询更容易编写并且能提高心性能。如果使用的报表工具不支持横向钻取，可以采用融合事实表取代报表工具进行比较工作。

融合星型模式并不总是能够包含最细粒度的数据，融合事实表包含来自多个过程的信息，因此会记录0值事实。

当需要比较两个或者多个星型模式时，通常需要使用一个不可共享的维度来对某个星型模式进行行过滤，在设计融合事实表以支持这类比较时，需要确定如何将维度合并起来。它可能被融合的星型模式忽略，这会使分析能力受限。这需要将每个查询限制在涉及问题的维度上。消除这列问题的方法是，在融合事实表中包含不可共享的维度。针对融合事实表的查询必须始终限定维度设计于单一值，从而避免发生双重计算。

旋转事实表

消除了建立报表时所需要的行列转换。

来自原始事实表中的数据将从行的方式转换为列的方式，或者以列的方式转换为行方式。可以简化某些形式的报表。性能可以得到一定的改善。因此旋转事实表通常能够包含大量宝博鳌的应用使用，这将会显著减少报表的开发时间。

通过旋转模式可以将行数据转换为列数据，或者打到相反的效果。这么做能够减少查询和报表过程的复杂性。如果需要转换的类型非常多，转换模式将具有非常显著的价值。

切片事实表

切片事实表与原始的星型模式几乎一样，只是他包含的行仅仅为原始星型模式的一致子集。切片事实表在不牺牲细节的情况下限制了数据集合的范围，因此可以将他们方便地分布到不同的物理区域中，这可以确保对移动应用的部署，有助于增强对安全性方面的需求，并能够以方便管理的容量建立多维数据集。

切片事实表为强化安全性方面的需求提供了一种方便的机制，对切片的访问将按照用户的需求授权给他们，确保个人仅仅能因访问工作而需要适当的数据子集，表级别的访问通常比用于原始模式的基于行的安全模式更容易配置和管理。

切片事实表步骤

切片事实表不一定总是从整体导出，也可能通过合并所有的切片来构建。

1. 处理公共维度表
2. 处理事实表切片
3. 从切片中导出合并事实表

集合操作事实表

消除了使用子查询或者使用SQL集合操作的需要

将连个星型模式作为输入，产生的输出将基于集合操作的应用，建立的星型模式能提供比原始模式更好的性能，同时避免在查询时使用集合操作。

集合操作事实表利用集合操作或子查询预先计算出两个数据集的比较结果，将结果存储在新事实表中，极大地简化了对查询或报表需要做的处理工作。

集合操作的应用并不是能够获得有用的结果，如果不能用业务术语清楚地定义，集合就不能支持相关分析，因此从业务角度来看是没有用的。预先计算集合操作的结果主要用于交际和减操作，并且几乎总是涉及覆盖表，使用导出表来获得集合操作的结果，需要从报表开发或执行时间与对ETL的负担中权衡利弊，如果并不经常使用，可能在建立报表时加算他们会更有意义。另一方面，如果20%的报表关注子集合，可能采用预先计算的方法更为有利，要么使用导出星型模式，要么使用多维数据集。