漫谈事实表如何设计（二）

一：事实表的设计过程

1：选择业务过程
如果是单事务事实表，那么业务过程就一个，如果是多事务事实表，那么会存在多个事务。事务描述的是一个业务过程。单个事务的事实表，比较好理解，易用，多事务事实表，存在有一定的限制条件，比如说粒度一致等。
2：确定粒度
确定完业务过程以后，需要确定粒度，就拿电商中的订单粒度和订单商品粒度来说，两种粒度的事实表是不能够放在一张多事务事实表当中的，比如说放在一起以后，订单粒度的事实会出现被放大的现象，这明显是不合理的。
3：确定维度
维度是描述事实表事实的一个环境，事实表当中的维度信息大多加工于维度表。多事务事实表会公用一个维度信息，单事务事实表独享维度信息。
4：确定事实
事实其实就是事实表的度量值，一般来说，围绕着业务过程，将能带上的事实都加上，尽量丰富，因为这样可以提供更多分析的可能性。
5：冗余维度
降维操作主要是为了，在做多维度分析时，去除关联维度表这一个过程带来的开销，所以一般会将经常使用的属性信息直接添加到事实表上。

二：单事务事实表与多事务事实表的区别

1.业务过程

对于单事务事实表，一个业务过程建立一个事实表，只反映一个业务过程的事实，对于多事务事实表，在同一个事实表中反映多个业务过程。多个业务过程是否放到同一个事实表中，首先需要分析不同业务过程之间的相似性和业务源系统。比如淘宝交易的下单、支付和成功完结这三个业务过程是存在相似性的，都属于订单处理中的一环，并且都来自于交易系统，因此适合放到同一个事务事实表中 。

2.粒度和维度

在考虑是采用单事务事实表还是多事务事实表时，另一个关键点就是粒度和维度，在确定好业务过程后，需要基于不同的业务过程确定粒度和维度，当不同业务过程的粒度相同，同时拥有相似的维度时，此时就可以考虑采用多事务事实表。如果粒度不同，则必定是不同的事实表。 比如交易中支付和发货有不同的粒度，则无法将发货业务过程放到淘宝交易事务事实表中。

3.事实

对于不同的业务过程，事实往往是不同的，单事务事实表在处理事实上比较方便和灵活，仅仅体现同一个业务过程的事实即可；而多事务事实表由于有多个业务过程，所以有更多的事实需要处理。如果单一业务过程的事实较多，同时不同业务过程的事实又不相同，则可以考虑使用单事务事实表，处理更加清晰；若使用多事务事实表，则会导致事实表零值或空值字段较多。

4.下游业务使用

单事务事实表对于下游用户而言更容易理解，关注哪个业务过程就使用相应的事务事实表；而多事务事实表包含多个业务过程，用户使用时往往较为困惑。

5.计算成本

针对多个业务过程设计事务事实表，是采用单事务事实表还是多事务事实表，对于数据仓库的计算存储成本也是参考点之一，当业务过程数据来源于同一个业务系统，具有相同的粒度和维度，且维度较多而事实相对不多时，此时可以考虑使用多事务事实表，不仅其加工计算成本较低，同时在存储上也相对节省，是一种较优的处理方式。

三：订单拆单与父子事实表

1.什么是订单拆单

目前电商行业普遍存在一种问题，一个订单中的商品在不同仓库，或者是不同的商家，那么就需要分开配送，就会导致到货时间不一样，这样一个订单就会涉及到多个到货合约时间纠纷等问题。所以出现拆单，拆单的准则可能根据不同仓库发货，或者是不同商家等。

2.父子事实表

之前介绍过说多事务事实表需要保证粒度一致，并且遵循最小粒度优先原则，那么就存在将一个订单粒度的事实表拆解成订单商品粒度，这当中涉及到一个问题，那就是订单粒度的事实怎么分摊到订单商品粒度的事实表当中，这其中涉及到一些优惠券等影响，比如说按照以下规则进行分摊：

分摊规则.png

四：事实表的设计准则

1.事实完整性

事实表包含与其描述的过程有关的所有事实，即尽可能多的获取所有的度量。

2.事实的一致性

事实表会存在多种事实，有些度量值可以根据已有的度量进行计算，这样做的目的是统一计算口径，保证事实的一致性。

3.事实的可加性

尽量保证事实表的可加性，如果出现非可加性的度量值，比如说比率，利润率等，看看能不能进行转换。