一、概述

事实表作为数据仓库维度建模的核心，紧紧围绕着业务工程来设计，通过获取描述业务过程的度量来表达业务工程，包含了引用的维度和与业务工程有关的度量。而我们在数据建模中也经常将事实表分为三种类型：事务事实表、周期快照事实表和累计快照事实表
**事务事实表：**用来描述业务过程,跟踪空间和时间上某点的度量事件，保存的是最原子的数据，也称指为原子事实表
周期快照事实表：是以具有规律性的、可预见的事件间隔记录事实，时间间隔如每天、每月、每年等，
累计快照事实表：用来表述过程开始和结束之间的关键步骤时间，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点，当过程随着生命周期不断变化时，记录也会随着过程的变化而被修改。

事实表粒度：事实表中一条记录所表达的业务细节程度称为粒度。通常粒度可以通过两种方式来表述：一种是维度属性组合所表示的细节程度：一种是所表示的具体业务含义。
事实表特点：
（1）、度量值一般为整型或浮点型的十进制数值，有可加性、半可加性和不可加性三种类型。其中可加性是可以按照事实表的任意维度汇总，半可加性指只能按照特定部分维度汇总（有些维度汇总叠加无意义。）不可加性指的是不能通过维度聚合相加，比如说有的事实表中度量值为比率性（这个情况我们可以将其转换称可加性值来方便统计）
（2）、对比维度表，事实表要细长得多，行的增加速度也比维表快很多。
（3）、在设计宽表过程中，经常将维度表中维度退化到事实表中，形成逻辑宽表。，这种存储到事实表中的维度列被称为“退化维度”。

二、事实表的设计原则

1、尽可能包含所有与业务过程相关的事实
事实表的设计的目的是为了度量业务过程，所以分析哪些事实与业务过程有关是设计中非常重要的关注点。在事实表 中应该尽量包含所有与业务过程相关的事实，即使存在冗余，但是因为事实通常为数字型，带来的存储开销也不会很大。
2、只选择与业务过程相关的事实
在选择事实表，应该注意只选择与业务过程有关的事实。比如在订单的下单这个业务过程事实表设计中，不应该存在支付金额这个表示支付业务过程的事实。
3、分解不可加性事实为可加的组件
对于不具备可加性条件的事实，需要分解为可加的组件。比如订单的优惠率，应该分解为订单原价金额与订单的优惠金额两个事实存储在事实表中。
4、在选择维度和事实之前必须先声明粒度
粒度的声明是事实表设计中不可忽视的重要一步，粒度用于确定实表中一行所表示业务的细节层次，且每个维度和事实必须与所定义的粒度保持一致。并且在事实表的设计过程中，粒度定义越细越好。，建议从最低级别的原子粒度开始，因为原子粒度提供了最大限度的灵活性，可以支持无法预期的各种细节层次的用户需求。
5、在同一个事实表中不能有多种不同粒度的事实
事实表中的所有事实需要与表定义的粒度保持一致，在同一个事表中不能有多种不同粒度的事实。
6：事实的单位要保持一致
7、对事实的 null 值要处理
对于事实表中事实度量为null值的处理，因为在数据库中null值对常用数字型字段的SQL过滤条件都不生效，比如大于、小于、等于、大于或等于、小于或等于，建议用零值填充。
8、使用退化维度提高事实表的易用性
在大数据领域的事实表设计中，则大量采用退化维度的方式，在事实表中存储各种类型的常用维度信息。这样设计的目的主要是为了减少下游用户使用时关联多个表的操作，直接通过退化维度实现对事实表的过滤查询、控制聚合层次、排序数据以及定于主从关系等。通过增加冗余存储的方式减少计算开销，提高使用效率。

三、事实表设计方法

互联网大数据环境下，面对复杂的业务场景，为了更有效、准确地进行维度模型建设，基于 Kimball 的四步维度建模方法，我们进行了更进一步的改进。
1、选择业务过程及确定 实表类型。
在明确了业务需求以后，，接下来需要进行详细的需求分析，对业务的整个生命周期进行分析，明确关键的业务步骤，从而选择与需求有关的业务过程。
下面以某宝订单流转为例：

业务过程通常使用行为动词来表示业务执行的活动。比如上图订单的流转业务过程有四个：创建订单、买家付款、卖家发货、买家确认收货。在明确了流程所包含的业务过程后，需要根据具体的业务需求来选择与维度建模有关业务过程，比如是选择买家付款这个业务过程还是选择创建订单和买家付款这两个业务过程，具体根据业务情况来确定。
在选择了业务过程之后，相应的实时表类型也随之确定了。比如选择了买家付款这个业务过程，那么事实表应为只是包换买家付款这一个业务过程的单事务事实表；如果选择的是所有四个业务过程，并且需要分析各个业务过程之间的时间间隔，那么所建立的事实表应为包含了所有四个业务过程累积快照事实表。
2、声明粒度
粒度的声明是事实表建模非常重要的一步，意味着精确定义事实表的每一行所表示的业务含义，而我们在声明粒度的时候我们应该选择最细级别的原子粒度，以保证事实表具有最大的灵活性。例如在订单过程而言，存在父子订单情况，我们应该选择子订单级别
3、确定维度
完成粒度声明以后，也就意味着确定了主键，对应的维度组合以及相关的维度字段就可以确定了，应该选择能够描述清楚业务过程所处的环境的维度信息。比如订单付款事实表中，粒度为子订单，那相关的维度有买家、卖家、商品、收获人信息、业务类型、订单时间等维度。
4、确认事实
事实可以通过业务过程度量来确定，且度量粒度必须和事实表的粒度保持一致。如果度量的类型为不可加类型，此时需要处理，将不可加性事实表分解为可加事实度量。（例如付款订单事实表中，同粒度的事实度量一般有子订单支付金额、邮费、优惠金额等）
5、冗余维度
传统的维度建模，维度需要单独存储维度表中。而在大数据事实表模型设计中，为了易用性，我们经常将事实表中常用的维度冗余到事实表中（例如付款事务事实表中，通常会冗余大量常用维度字段，以及商品类目、卖家店铺等维度信息）