事实表和维度表是怎么造数据_kimball维度模型技术与指导

数据建设，解决的目标就是从数据源头到数据价值实现的全链路工作，我们把这个链路比作有机蔬菜的商业化实现。那么，数据仓库建设就好比是这个商业化餐厅的厨师了。企业需求千万万，厨师的技能却是有章可循的。

本篇文章是基于kimball的代表作《数据仓库工具箱》，如果你是分析师、架构师或者是业务，对维度建模感兴趣，那么不妨看上一看。对你来说，了解别人在干嘛，对沟通成功率也能多一分提升。如果想更深一步了解相关知识或者案例，建议您抽时间来看看这本书。

事实与维度

事实表

事实，表示某个业务度量。比如你制造、消费、存储等，与之对应的都有一个可度量的事实。造了多少，花了多少，多少存货等。事实表往往保留着维度表的键，以进行关联分析不同维度下的事务发展与变化。

事务事实表

 对应一个细化的业务过程，对应的是时间或空间上某点的度量事件，比如购物时的下单过程。围绕着此过程，考虑的指标可能有：下单数，下单金额，下单商品数等。

周期快照事实表

 汇总发生在某一个特定周期，如某一天、某周、某月的多个度量事件。一般包含多个事实，因为符合同一个粒度的事实都被汇总。

累积快照事实表

 汇总发生在过程开始与结束之间可预测步骤内的度量事件（如入库、分拣、出库）。管道或工作流过程(下单、支付、退款等)具有定义的开始点、标准中间过程、定义的结束点，他们在此类事实表中都可以被建模。

合并事实表

 将来自多个过程的、以相同粒度表示的事实合并为单一的合并事实表。为过程关联性强，探索不同业务过程的之间的关联，提供简单快捷的分析。

事实表处理

1. 一致性：业务过程应该能够被清晰地定义，有着明确的业务边界；对于表的创建，应符合统一的规范，增加可读性；对于字段的使用，也应能够做到同词同义；
2. 可加性：度量值中类似销量，是完全可加的；库存，半可加的，你不能跨时间维度；单价，不可加的。而对于事实表中，我们尽可能的存储完全可加的度量值，对于半可加、不可加度量值，通过拆分子、分母的形式达到我们的目的

维度表

 维度，是包含于业务过程度量事件有关的文本环境。它们用于描述与“谁、什么、哪里、何时、如何、为什么”有关的事件。维度常为一个主体，事实是跟这个主体有关的事务。区别维度与事实，最重要的一点就是是否具有可计算性。

雪花维度

 为了维度表中的层级更加规范，通过与基本维度关联，获取低粒度属性。这个过程包含如果包含多重维度表层次时，这样的模型即为雪花模型。这样的模型，对于理解、查询、性能都有很大影响。建立扁平化、非规范化的维度表完全能够替代雪花。

杂项维度

 在业务发展中，有很多各种各样的小维度，重要而又庞杂。我们可以通过将这些小维度合并到统一的杂项维度表中进行管理。

支架维度

 支架维度类似与雪花维度，区别在于它是基本维度中，包含了其他属性维度。比如，银行维度中，引用日期维度。这样的辅助维度成为支架维度。同样指出，这样的方式不利于星型模型的建设，应该尽量较少使用。所希望的情况，维度之间的关联应该由事实表来完成。

退化维度

 常是功能被弱化的一些主键，比如订单号。在事实表中，存在的意义主要是统计一些订单数量等。或者上卷时，作为关联键，连接订单维度的数据。

---

建设过程的一些思想和方法

缓慢变化维

 对于变化的数据，我们怎么才能够追溯其历史呢？比如说，同样的商品，我想了解今天与昨天的价格差，是相对赚了，还是亏了。这个时候，我们就涉及到缓慢变化维的概念。

 简单来说，它就是用户解决历史数据变化的一种方法，让数据可追溯。而在处理缓慢变化维中，处理的方式有几种。
 1:重写
 只保留最新的数据,舍弃历史的数据。主要场景，业务不关心历史变化情况，或者不太会发生历史变化；
 2:增加新行
 增加的新行，采用修改的维度属性，同时增加额外三个列，标识行有效时间、截止时间、当前行标识(曾命名为：bistarttime/biendtime/bi_etltime)
 3:增加新属性
 又称替换现实。比如以前的部门叫BI，后来换了个洋气的名字，就数据科学。在存储时，原来记录部门的名称只有一个，考虑缓慢变化后，变成两个。另一个叫，前名称。有时候也会考虑多种属性，如：前前部门，这种不太用到。
 4.微型维度
 当遇到频繁+大量的数据修改时，那么记录这些变化的数据将带来大量的性能压力。这个时候，往往考虑对变化数据进行范围化设计。如消费金额，用户每个月的消费金额都不同，但是我们可以设置一个范围：比如0-1万元。这样，她的消费变化就稳定了。
 5.组合设计
 考虑特定的场景，将上述的这些处理方法进行组合。如：2+3

桥接表与多对多关系

 场景一：作者与书是一种多对多的关系,每本书可能有多个作者，作者从卖书的利润中获取收入。这个时候，最优的模型设计应该是怎么样的，来解决：书利润有多少钱，每个作者多少钱，top10的书，top10的作者呢 ？
 场景二：我们去体检，在某些项目上，我们有多条重复的记录。比如，测量身高、测量血液等。这个时候，我们应该怎么设计，能够将这些数据都记录下来呢？

 从模型的角度来考虑，我们应该尽可能的扁平化，有时应采用行列转换的方式来达到这个目的。而有时候，我们也需要一个桥接表，来记录这样的关系。

建模过程

1. 选择业务过程
    在传统的行业中，是有比较成型的模型设计(如：FSLDM)的，从总体上设计，分成十大主题(人、产品、财务...)，核心则是这些实体之间的关系。而在维度建模中，以业务过程中发生的事务作为一条中轴线(核心源),将实体(维度)关系联系在一起，来构建企业的数据仓库
2. 声明粒度  粒度，即是一种统计角度。一般情况下，应该从最细的粒度出发，以便足够覆盖业多变的需求。
3. 确定维度
    尽可能的将与事务相关的实体，纳入到事实表中。这样对于数据探索也有着很大的帮助
4. 确定事实
    可以理解为，需要哪里度量值吧数据建设，解决的目标就是从数据源头到数据价值实现的全链路工作，我们把这个链路比作有机蔬菜的商业化实现。那么，数据仓库建设就好比是这个商业化餐厅的厨师了。企业需求千万万，厨师的技能却是有章可循的。

 本篇文章是基于kimball的代表作《数据仓库工具箱》，如果你是分析师、架构师或者是业务，对维度建模感兴趣，那么不妨看上一看。对你来说，了解别人在干嘛，对沟通成功率也能多一分提升。如果想更深一步了解相关知识或者案例，建议您抽时间来看看这本书。

事实与维度

事实表

 事实，表示某个业务度量。比如你制造、消费、存储等，与之对应的都有一个可度量的事实。造了多少，花了多少，多少存货等。事实表往往保留着维度表的键，以进行关联分析不同维度下的事务发展与变化。

事务事实表

 对应一个细化的业务过程，对应的是时间或空间上某点的度量事件，比如购物时的下单过程。围绕着此过程，考虑的指标可能有：下单数，下单金额，下单商品数等。

周期快照事实表

 汇总发生在某一个特定周期，如某一天、某周、某月的多个度量事件。一般包含多个事实，因为符合同一个粒度的事实都被汇总。

累积快照事实表

 汇总发生在过程开始与结束之间可预测步骤内的度量事件（如入库、分拣、出库）。管道或工作流过程(下单、支付、退款等)具有定义的开始点、标准中间过程、定义的结束点，他们在此类事实表中都可以被建模。

合并事实表

 将来自多个过程的、以相同粒度表示的事实合并为单一的合并事实表。为过程关联性强，探索不同业务过程的之间的关联，提供简单快捷的分析。

事实表处理

1. 一致性：业务过程应该能够被清晰地定义，有着明确的业务边界；对于表的创建，应符合统一的规范，增加可读性；对于字段的使用，也应能够做到同词同义；
2. 可加性：度量值中类似销量，是完全可加的；库存，半可加的，你不能跨时间维度；单价，不可加的。而对于事实表中，我们尽可能的存储完全可加的度量值，对于半可加、不可加度量值，通过拆分子、分母的形式达到我们的目的

维度表

 维度，是包含于业务过程度量事件有关的文本环境。它们用于描述与“谁、什么、哪里、何时、如何、为什么”有关的事件。维度常为一个主体，事实是跟这个主体有关的事务。区别维度与事实，最重要的一点就是是否具有可计算性。

雪花维度

 为了维度表中的层级更加规范，通过与基本维度关联，获取低粒度属性。这个过程包含如果包含多重维度表层次时，这样的模型即为雪花模型。这样的模型，对于理解、查询、性能都有很大影响。建立扁平化、非规范化的维度表完全能够替代雪花。

杂项维度

 在业务发展中，有很多各种各样的小维度，重要而又庞杂。我们可以通过将这些小维度合并到统一的杂项维度表中进行管理。

支架维度

 支架维度类似与雪花维度，区别在于它是基本维度中，包含了其他属性维度。比如，银行维度中，引用日期维度。这样的辅助维度成为支架维度。同样指出，这样的方式不利于星型模型的建设，应该尽量较少使用。所希望的情况，维度之间的关联应该由事实表来完成。

退化维度

 常是功能被弱化的一些主键，比如订单号。在事实表中，存在的意义主要是统计一些订单数量等。或者上卷时，作为关联键，连接订单维度的数据。

建设过程的一些思想和方法

缓慢变化维

 对于变化的数据，我们怎么才能够追溯其历史呢？比如说，同样的商品，我想了解今天与昨天的价格差，是相对赚了，还是亏了。这个时候，我们就涉及到缓慢变化维的概念。

 简单来说，它就是用户解决历史数据变化的一种方法，让数据可追溯。而在处理缓慢变化维中，处理的方式有几种。
 1:重写
 只保留最新的数据,舍弃历史的数据。主要场景，业务不关心历史变化情况，或者不太会发生历史变化；
 2:增加新行
 增加的新行，采用修改的维度属性，同时增加额外三个列，标识行有效时间、截止时间、当前行标识(曾命名为：bistarttime/biendtime/bi_etltime)
 3:增加新属性
 又称替换现实。比如以前的部门叫BI，后来换了个洋气的名字，就数据科学。在存储时，原来记录部门的名称只有一个，考虑缓慢变化后，变成两个。另一个叫，前名称。有时候也会考虑多种属性，如：前前部门，这种不太用到。
 4.微型维度
 当遇到频繁+大量的数据修改时，那么记录这些变化的数据将带来大量的性能压力。这个时候，往往考虑对变化数据进行范围化设计。如消费金额，用户每个月的消费金额都不同，但是我们可以设置一个范围：比如0-1万元。这样，她的消费变化就稳定了。
 5.组合设计
 考虑特定的场景，将上述的这些处理方法进行组合。如：2+3

桥接表与多对多关系

 场景一：作者与书是一种多对多的关系,每本书可能有多个作者，作者从卖书的利润中获取收入。这个时候，最优的模型设计应该是怎么样的，来解决：书利润有多少钱，每个作者多少钱，top10的书，top10的作者呢 ？
 场景二：我们去体检，在某些项目上，我们有多条重复的记录。比如，测量身高、测量血液等。这个时候，我们应该怎么设计，能够将这些数据都记录下来呢？

 从模型的角度来考虑，我们应该尽可能的扁平化，有时应采用行列转换的方式来达到这个目的。而有时候，我们也需要一个桥接表，来记录这样的关系。

建模流程

1. 选择业务过程
    在传统的行业中，是有比较成型的模型设计(如：FSLDM)的，从总体上设计，分成十大主题(人、产品、财务...)，核心则是这些实体之间的关系。而在维度建模中，以业务过程中发生的事务作为一条中轴线(核心源),将实体(维度)关系联系在一起，来构建企业的数据仓库
2. 声明粒度  粒度，即是一种统计角度。一般情况下，应该从最细的粒度出发，以便足够覆盖业多变的需求。
3. 确定维度
    尽可能的将与事务相关的实体，纳入到事实表中。这样对于数据探索也有着很大的帮助
4. 确定事实
    可以理解为，需要哪里度量值吧