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