在上一篇文章中我们简单介绍了什么是维度建模以及维度建模的基本要素，这篇文章中我们依然学习了解维度建模中的基本要素事实表和维度表的类型以及维度设计方法。首先里了解维度建模中的事实表类型，在依次介绍维度类型，一致性维度和一致性事实，维度设计方法。接下来进入正题。

      一、事实表 

       事实表存储了从业务活动或事件提炼出来的性能度量，它主要包含维度表的外键和连续变化的可加性数值或半可加事实。事实表产生于业务过程中而不是业务过程的描述性信息。它一般是行多列少，占据数据仓库大约90%的空间。在维度模型中也有表示多对多关系的事实表，其他都是维度表。 

      1、事实表粒度

        事实表的粒度是产生事实行数据的度量事件的业务定义。粒度确定了事实表的业务主键， 事实表的所有度量值必须具有相同的粒度。 

       2、事实表类型

           2.1、事务事实表

           它是面向事务的，其粒度是每一行对应一个事务，它是最细粒度的事实表也称“原子事实表”。事务事实表中的数据在事务事件发生后产生，数据的粒度通常是每个事务一条记录。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。

          2.2、周期快照事实表

          它是按照良好的时间周期间隔(每天，每周，每月)来捕捉业务活动的执行情况，一旦装入事实表就不会再去更新，它是事务事实表的补充，而非替代。典型的例子如销售日快照表、库存日快照表等。周期快照事实表的粒度是每个时间段一条记录，通常比事务事实表的粒度要粗，是在事务事实表之上建立的聚集表。周期快照事实表的维度个数比事务事实表要少，但是记录的事实要比事务事实表多。周期快照事实表的日期维度通常是记录时间段的终止日，记录的事实是这个时间段内一些聚集事实值。事实表的数据一旦插入即不能更改，其更新方式为增量更新。

         2.3、累积快照事实表

         它用于描述业务过程中某个不确定时间跨度里的活动，它随着业务活动的发生会不断的更新。累积快照事实表和周期快照事实表有些相似之处，它们存储的都是事务数据的快照信息。但是它们之间也有着很大的不同，周期快照事实表记录的确定的周期的数据，而累积快照事实表记录的不确定的周期的数据。

         累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点。另外，它还会有一个用于指示最后更新日期的附加日期字段。由于事实表中许多日期在首次加载时是不知道的，所以必须使用代理关键字来处理未定义的日期，而且这类事实表在数据加载完后，是可以对它进行更新的，来补充随后知道的日期信息。

        举例来说客户购买商品的整个过程记录:订货日期 预定交货日期 实际发货日期 实际交货日期 数量 金额 运费

        在这个累积快照事实表中，记录的是购买货物的整个生命周期的数据，记录第一次产生时，实际发货日期和实际交货日期是不确定的，需要用表示未知的代理关键字来代替。等实际发货后，需要对数据仓库中的这条记录进行更新操作，将实际发货日期补上。

        3、事实表区别： 

           二、维度表 

          维度表是对业务过程的上下文描述，主要包含代理键、文本信息和离散的数字。它是进入事实表的入口，丰富的维度属性给出了对事实表的分析切割能力，它一般是行少列多。如果属性值是离散的，用于过滤和标记的，就放到维度表里，如果是属性值是连续取值，可用于计算的，就放到事实表中。

         1、维度表类型

           1.1、缓慢变化维

             1）、类型1

                字段值发生变化时覆盖原来的值。 

              2）.类型2

              字段值发生变化时会新增一行，重新分配代理键，每一行添加开始日期，结束日期，版本号，是否当前值。 

              3）.类型3

             每条记录会新增一列来标识变化前的值，发生变化时，把旧值放到新增的列中，把新值覆盖旧值。

                4）.混合类型

                把上面的三种类型混合来使用。

         1.2日期维

            它是数据仓库必须有的维度，包含日期，日期所属的周，月，季度，年等信息。 

         1.3角色维

           相同的维度表在维度模型中扮演不中的逻辑角色，一般通过创建视图来表示。

         1.4杂项维

          如果每个属性值都很少，可以把这些维度的组合起来生成一个维度表。 

         1.5支架维

         如果维度之间是一对多的关系或区别于原维度的多个描述性维度属性，可以建雪花型支架维度。

              1.6多值维度桥接维

              如果二个维度表是多对多的关系，可以使用多值维度设计。

              1.7微型维

              一个大型维有些属性变化比较频繁，把这些属性单独生成一个微型维度表。

            1.8缩小维

它是维度表的一个子集或部分属性。

1.9查找维

系统里代码表里维度信息。

1.10层次维

有些维度表是有层次结构的，可以通过视图生成树形结构的维度表。

             还需要注意，手工维护的维表，有些数据不在业务系统里，需要业务用户手工维护的维度表。

           三、维度建模核心：一致性维度和事实

          企业数据仓库应该建立一致性维度和事实，而不是为每个部门建立维度和事实。 

          3.1、一致性维度

          维度一直是大家所熟知的，但是前面加上了“一致性”之后便成了数据仓库特有的一类维度表，其实一致性维度在表结构和属性都没有本质的区别，有一点的差异是数据仓库的星型模型会使得维度表有一定的冗余。那么一致性体现在哪里呢： 维度共享性。共享性体现在整个平台或整个部门共用维度，而不仅仅只是单纯某个业务单独使用。 一般的维度并没有把共享性作为一个共性的标准。然而在维度建模中，一致性维度将作为重心来做。数据仓库70%的工作量和复杂度是用在构建一致性维度。一致性维度将作用于数据仓库和数据集市甚至是OLAP。

          3.2、一致性事实

          指每个度量在整个数据仓库中都是唯一的统计口径，为了避免歧义，一个度量只有唯一的业务术语。一致性事实在建立多个数据集市时，完成一致性维度的工作就已经完成了一致性的80%－90%的工作量。余下的工作就是建立一致性事实。 一致性事实和一致性维度有些不同，一致性维度是由专人维护在后台，发生修改时同步复制到每个数据集市，而事实表一般不会在多个数据集市间复制。需要查询多个数据集市中的事实时，一般通过交叉探查来实现。 为了能在多个数据集市间进行交叉探查，一致性事实主要需要保证两点。第一个是KPI的定义及计算方法要一致，第二个是事实的单位要一致性。如果业务要求或事实上就不能保持一致的话，建议不同单位的事实分开建立字段保存。

        四、维度模型设计方法 

        维度建模方法就讲解到这里。下一篇我们开始来数据仓库的ETL过程。本文中如有错误或误导的地方欢迎大家指出纠正。 希望这篇文章能够给大家带来帮助，最后感谢大家的阅读。欢迎大家一起加入高效数据处理ETL交流群，一起讨论数据分析前ETL过程的问题，一起学习一起成长。 

 扫码加群：