事实表的基本概念

什么是事实表

事实表的结构

事实数据表是包含描述业务内特定事件的数据。是发生在现实世界中的操作型事件所产生的可度量数据，通常包含大量的行。日常查询请求的主要目标就是基于事实表展开计算和聚合操作。
从最低粒度级别来看，事实表行对应一个度量事件，也可以说，一个度量事件必然对应一个最低粒度的事实行为。因此，事实表的设计完全依赖物理活动，不受可能产生的最终报表的影响。
事实表一般会包含数字度量，也总会包含外键，用来与相关的维表做关联。
常用的事实表经常会包含日期/时间戳，退化维度键（退化维度键的解释不再展开，想了解具体定义可Baidu或者看我下期博客）。

数据度量分类

数据度量可分为：可加，半可加，不可加三类。
可加类：最灵活，最有用的事实。可加类度量可以按照与事实表关联的任意维度汇总。
半可加类：可以对某些维度汇总，但不能对所有维度汇总。例如，订单差额的计算，除了时间维度外，它们可以跨所有维度进行加法操作。
不可加类：完全不可加类。例如 ，比率。对非可加事实，一种好的方法时，尽可能存储非可加度量的完全可加的分量，并在计算出最终的非可加事实前，将这些分量汇总到最终的结果集合中。

事实表中的空值

事实表中可以存在空值。所有的聚合函数（sum,count,min,max ，avg等）均可针对空值计算。但是外键和用来关联维度表的id不能存放空值，否则会导致违反参照完整性的情况发生，可以采用使用默认行（代理键）的形式来表示未知的或者无法应用的条件。

一致性原则

1.如果某些度量出现在不同的事实表中，应该保证针对事实的技术定义是相同的。
2.如果不同的事实表定义是一致的，则这些一致性事实应该具有相同的命名。
3.如果不同的事实表定义不一致，则应该有不同的命名用来告诫业务用户和BI应用。

简单举例

1.银行对存款记账，A表中存放实际数据，包括账号、所属机构号、存款金额等，B表存放机构号和机构名称的对应关系。则A是事实表，B是维表。
2.用户注册网站。A表中存放实际数据，包括用户的姓名，年龄，邮箱，国家id，省份id等，B表存放国家id与国家名字的对应关系。则A是事实表，B是维表。

事实表分类

• 可加，半可加，不可加事实

• 一致性事实表：

• 事务事实表：一行对应空间或时间上某点的度量事件。
  优劣：事务事实表可以是稠密的，也可以是稀疏的，因为仅当存在度量时才会建立行
  应用场景：
  业务场景举例：

• 周期快照事实表：每行汇总了发生在某一标准周期，如某一天，某周，某月的多个度量事件。
  优劣：
  应用场景：
  业务场景举例：

• 积累快照事实表：汇总了发生在过程开始和结束之间可预测步骤内的度量事件。管道或工作流过程具有定义的开始点，标准中间过程，定义的结束点，它们在此类事实表中都可以被建模。
  优劣：
  应用场景：缓慢变化维事实表的设计
  业务场景举例：以履行订单表举例。累计快照事实表中的一行，对应某一具体的订单，当订单产生时会插入一行，修改订单行为发生时，表内订单数据被访问并修改。

• 无事实的事实表：存在某些事件仅仅记录一系列某一时刻发生的多维实体。
  优劣：
  应用场景：
  业务场景举例：在给定的某一天中发生的学生参加课程的事件。用户注册网站事件

• 聚集事实表或OLAP多维数据库：聚合事实表是对原子粒度事实表数据进行简单的数字化上卷操作，目的是为了提高查询性能。聚合事实表包含外键以缩小一致性维度，聚集事实的构建是通过对来自多个原子事实表的度量的汇总而获得的。
  优劣：适当设计的聚集集合类似数据库索引，能够提高查询性能，但不需要直接面对BI应用和商业用户
  应用场景：数据仓库中集市层的建设（IDL）
  业务场景举例： 未想到

• 合并事实表：通常将来自多个过程的，以相同粒度表示的事实合并为一个单一的合并事实表，这样做能够带来方便。
  优劣：合并事实表会增加ETL处理过程的负担，但降低了BI应用的分析代价。
  应用场景：特别适合那些经常需要共同分析的多过程度量。
  业务场景举例：现货销售可以与销售预测合并为一张事实表，与针对多个不同的事实表采用下钻应用比较，这样做可使对现货及预测任务的分析工作变得简单快捷。