事实表是统一数仓层建设的主要产出物，统一数仓层绝大部分表都是事实表。一般来说事实表由两部分组成：一部分是由主键和外键组成的键值部分，另一部分是用来描述业务过程的事实度量。事实表的键值部分确定了事实表的粒度，事实表通过粒度和事实度量来描述业务过程。事实表的外键总是对应某个维度表的主键，实际建设和试用过程中，为了提升事实表的易用性和性能，不仅会存储维度主键，还会把关键的维度属性存储在实施表中。这样事实表就包含表达粒度的键值部分、事实度量及退化的维度属性。一切数据应用和分析都是围绕事实表来展开的，稳定的数据模型能大幅提高数据复用性。
在Kimball的维度建模理论中主要定义了事务事实表、周期快照事实表、累积快照事实表三种类型的事实表。
- 事务事实表：事务事实表描述业务过程事务层面的事实，每条记录代表一个事务事件，保留事务事件活动的原始内容。事务事实表中的数据在事务事件发生后记录，一般记录后数据就不再进行更改，其更新方式为增量更新。事务事实表相对其他事实表保存的数据粒度更细，可以通过事务事实表对事务行为进行详细分析。
- 周期快照事实表：周期快照事实表以具有规律性、可预见的时间间隔产生快照来记录事实，每行代表某个时间周期的一条记录，记录的事实是时间周期内的聚集事实值或状态度量。周期快照事实表的内容一般在所表达的时间周期结束后才会产生，一般记录后数据就不再更改，其更新方式为增量更新。周期快照事实表一般是建立在事务事实表之上的聚集，维度比事务事实表少，粒度比事务事实表粗，但是由于对事实进行了多种形式的加工从而产生了新的事实，故一般事实会比事务事实表多。
- 累计快照事实表：累积快照事实表覆盖一个事务从开始到结束之间所有的关键事件，覆盖事务的整个生命周期，通常具有多个日期字段来记录关键事件时间点。周期快速事实表涉及的多个事件中任意一个的产生都要做记录，由于周期快照事实表涉及的多个事件的首次加载和后续更新时间是不确定的，因此在首次加载后允许对记录进行更新，一般采用全量刷新的方式更新。
累计快照事实表一般用于追踪某个业务的全生命周期及状态转换，比如交易业务，涉及下单、支付、发货、确认收货，这些相关事件在不同的事务事实表中，通过事务事实表很难看到不同事件之间的转化及状态变化，通过累计快照事实表可把相关事件串起来放在一条记录中，这样就很容易解决了。 不管哪种类型的事实表，设计方法都类似，事实表设计可以遵循以下步骤：
第一步：确定业务过程。
企业业务是由一个个业务过程组成的，事实表就是为了记录这些业务过程产生的事实，以便还原任意时刻的业务运转状态。所以设计事实表，第一步就是确定实施所要表达的是哪一个或者几个业务过程。笔者理解业务过程是企业活动事件，比如注册、登录、下单、投诉等都是业务过程，最基本的是每一个业务过程对应一张事实表，这样最容易理解。但是实际开发过程中，业务过程和事实表会存在多对多的关系。
第二步：定义粒度。
不管事实表对应一个还是多个业务过程，粒度必须是确定的，每个事实表都有且只能有唯一的粒度，粒度是事实表的每一行所表示的业务含义，是事实的细节级别。在实际设计过程中，粒度与主键等价，粒度更偏向业务，而主键是站在技术角度说的。虽然粒度在最终的事实表中很难被体现，但是定义粒度是必不可少的步骤，这样可避免整个事实表的业务含义模糊。
第三步：确定维度。
定义粒度之后，事实表每一行的业务含义就确定了。那么业务人员会站在哪些角度来描述事实度量？这就要确定维度了，常见的维度有时间、区域、客户、产品、员工等。维度依附于粒度，是粒度的环境描述。
第四步：确定事实。
事实就是事实表度量的内容，也就是业务过程产生的事实度量的计算结果，比如注册量、登录次数、交易金额、退款量等。事实表的所有事实度量都与事实表所表达的业务过程相关，所有事实必须满足第二步所定义的粒度。
第五步：冗余维度属性。
事实表的设计要综合考虑数据来源和使用需求，在满足业务事实记录的同时也要满足使用的便利性和性能要求。大数据时代，事实表记录数动辄亿级，甚至数十亿、数百亿，维表也有可能达到亿级甚至更多。利用标准维度模型会经常出现维表与事实表关联的情况，这种对亿级表的关联计算，在性能上是灾难性的。为了满足业务需求，降低资源消耗，建议适当冗余维度属性数据到事实表，直接利用事实表就可以完成绝大部分业务的使用需求，这样下游使用时可减少大表关联，提升效率。所以大数据时代，适当进行维度冗余是可取的。