事实表

事实表是用来度量的，基本上都以数量值表示，事实表中的每行对应一个度量，每行中的数据是一个特定级别的细节数据，称为粒度。维度建模的核心原则之一是同一事实表中的所有度量必须具有相同的粒度。这样能确保不会出现重复计算度量的问题。有时候往往不能确定该列数据是事实属性还是维度属性。记住最实用的事实就是数值类型和可加类事实。所以可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量，这种情况下该列往往是事实。 明显属于不同粒度的事实必须放在不同的事实表中。典型事实是可加性数值，例如订货数量是以美元计的成本总额等。

维度表

维度表是维度建模的灵魂所在，在维度表设计中碰到的问题（比如维度变化、维度层次、维度一致性、维度整合和拆分等）都会直接关系到维度建模的好坏，因此良好的维表设计就显得至关重要。

聚合表

数据是按照最详细的格式存储在事实表中，各种报表可以充分利用这些数据。一般的查询语句在查询事实表时，一次操作经常涉及成千上万条记录，但是通过使用汇总、平均、极值等聚合技术可以大大降低数据的查询数量。因此，来自事实表中的底层数据应该事先经过聚合存储在中间表中。中间表存储了聚合信息，所以被称为聚合表，这种处理过程被称为聚合过程。

事实表的分类

事实表有三种类型 : 事务事实表、周期快照事实表和累积快照事实表。

事务事实表

也称原子事实表，描述业务过程，跟踪控件或时间上某点的度量事件，保存的是最原子的数据； 个人理解：类似于流水的日志数据一样，每一次相关的 change 都记录下来，生成一行新的数据

周期快照事实表

以一个周期为时间间隔，来记录事实，一般周期可以是每天、每周、每月、每年等； 个人理解：只看某个业务过程，比如订单表，数据按订单结束时间来切分，周期可以为每天、每周、每月等。

累积快照事实

用来描述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点；当过程随着生命周期不断变化时，记录也会随着过程的变化而被修改； 个人理解：要看整个生命周期的多个业务过程，比如：创建订单 → 买家付款 → 卖家发货 → 买家确认收货。粒度是一个订单一行数据，创建订单时间，付款时间，发货时间，收货时间，多个分别作为一个字段，便于计算不同业务过程的时间间隔。

事务事实表 周期快照事实表 累积快照事实表
时期/时间 离散事务时间点 以有规律的、可预测的 用于时间跨度下不确定的不断变化的工作流
日期维度 事务日期 快照日期 相关业务过程设计的多个日期
粒度 每行代表实体的一个事务 每行代表某时间周期的一个实体 每行代表一个实体的一个生命周期
事实 事务事实 累积事实 相关业务过程事实和时间间隔事实
事实表加载 插入 插入 插入与更新
事实表变更 不更新 不更新 业务过程变更时更新

如何设计事实表

确定数据域

可以将数据域理解为一个数据主题，比如门店、订单、客户等等，每一个主题下包含属于该主题的业务过程，比如订单主题下包含订单的创建、无效等等业务过程。

选择业务过程

业务过程通常用行为动词表示 业务过程通常由某个操作系统支撑，如账单系统或者购买系统。一系列业务过程产生一系列事实表 在设计事实表的时候，首先得知道这张事实表要记录什么事实，也就是说，对应的业务过程是什么，是关于下单这个业务过程，还是支付或者购买之类的业务过程。

确定粒度

业务过程选定以后，就要针对每个业务过程确定一个粒度，即确定事务事实表每一行所表达的细节层次。（以“组织结构”为例，比如一个层级结构式：总公司，分公司，部门，科室。这就是不同的粒度。） 确定粒度也可以理解为你想设计的事实表中，每一行应该代表什么。 如果选择的业务过程是下单，并且我想观察每个订单的详细情况，那么粒度可以选择为订单粒度，在下单业务过程中，最细的粒度应该就是订单粒度。 对于事务表，一般都是从最细粒度构建。同时，上卷汇总粒度对性能调整来说非常重要。不同的事实表粒度，需要建立不同的事实表，比如订单粒度和店铺粒度的数据，不要在一张事实表中，在同一事实表中不要混用多种不同的粒度。

确定维度

维度一般用来解决如何描述事实表中每一行数据的问题。 维度信息一般是时间，地区，客户等等，具体还要看对应的使用场景，当度量和维度进行关联的时候，一条事实表的纪录只能和对应的维度进行关联，应该是1：1的关系。

确定事实

事实，也叫做度量或者指标，作为事实表的核心，事实表应该包含与其描述过程有关的所有事实。 不同的业务过程拥有不同的事实，一个业务过程中，可能也有不同的度量，比如在下单业务过程中， 需要包含下单金额、下单数量、下单分摊金额等等; 属于不同粒度的事实应该放在不同的事实表中。

总结

事实表一直都是建模过程中很重要的存在，所以一定要做好区分。我写的有什么不全面的或者不对的欢迎大家的指正。