事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和与业务过程有关的度量。
事实表概述：三种类型：++事务事实表++ 、++周期快照事实表++ 、++累计快照事实表++
++事务事实表++：
也称原子事实表，描述业务过程，跟踪控件或时间上某点的度量事件，保存的是最原子的数据；
++周期快照事实表++：
以一个周期为时间间隔，来记录事实，一般周期可以是每天、每周、每月、每年等；
++累计快照事实表++：
用来描述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点；当过程随着生命周期不断变化时，记录也会随着过程的变化而被修改；例如，要看整个生命周期的多个业务过程，比如：创建订单->买家付款->卖家发货->买家确认收货。粒度是一个订单一行数据，创建订单时间，付款时间，发货时间，收货时间分别作为一个字段，便于计算不同业务过程的时间间隔。
三种事实表对比：|-------|-------------|----------------|---------------------|
| | 事实事务表 | 周期快照事实表 | 累计快照事实表 |
| 时间/日期 | 离散事务时间点 | 以有规律的、可预测的 | 用于时间跨度不确定的、不断变化的工作流 |
| 日期维度 | 事务日期 | 快照日期 | 相关业务过程涉及的多个日期 |
| 粒度 | 每行代表实体的一个事务 | 每行代表某时间周期的一个实体 | 每行代表一个实体的生命周期 |
| 事实 | 事务事实 | 累计事实 | 相关业务过程事实和时间间隔事实 |
| 事实表加载 | 插入 | 插入 | 插入与更新 |
| 事实表更新 | 不更新 | 不更新 | 业务过程变更时更新 |
事实表设计八大原则：
++原则一：尽可能包含与业务过程相关的事实++
分析哪些事实与业务过程相关，是设计过程中非常重要的关注点；
在事实表中，尽量包含所有与业务过程相关的事实，即使存在冗余，由于事实通常是数字型，存储开销不会太大；
++原则二：只选择与业务过程相关的事实++
如，订单的下单这个业务过程，事实表中不应该存在支付金额这个表示支付业务过程的事实；
++原则三：分解不可加事实为可加的组件++
如，订单的优惠率，应分解为订单原价金额和订单优惠金额两个事实存储在事实表中；
++原则四：在选择维度和事实之前必须先声明粒度++
因为原子粒度提供了最大限度的灵活性，可以支持无法预期的各种细节层次的用户需求；
粒度用于确定事实表中一行所表示业务的细节层次，决定了维度模型的扩展性；
每个维度和事实必须与所定义的粒度保持一致；
设计事实表时，粒度定义越细越好，一般从最低级别的原子粒度开始；
++原则五：在同一个事实表中，不能有多种不同粒度的事实++
粒度为票一级；（实际业务中，一个订单可以指支付多张票）
票支付金额和票折扣金额，两个事实的粒度为"票级"，与定义的粒度一致；
订单支付金额和订单票数，两个事实的粒度为"订单级"，属于上一层订单级数据，与"票级"事实表的粒度不一致，且不仅能进行汇总；
如果以订单金额和订单票数这两个维度汇总总金额和总票数，会造成大量的重复计算；
++原则六：事实的单位要保持一致++
如订单金额、订单优惠金额、订单运费这三个事实应该采用统一的计量单位，统一为元或分，以方便使用；
++原则七：对事实的NULL值要处理++
在数据库中，NULL值对常用数字型字段的SQL过滤条件都不生效；如大于、小于、等于等；应用0代替NULL；
++原则八：使用退化维度提高事实表的易用性++
易用性是指对事实表较少关联操作、过滤查询、控制聚合层次、排序数据、定义主从关系等；
事实表中存储各种类型的常用维度信息，较少下游用户使用时关联多个表的操作；
通过退化维度，可以实现对事实表的过滤查询、控制聚合层次、排序数据、定义主从关系等；
事实表设计方法（暂未完善...）第一步：选择业务过程及确定事实表类型
第二步：声明粒度
第三步：确定维度
第四步：确定事实