1、维度建模

维度建模以分析决策的需求出发构建模型，构建的数据模型为数据分析服务。它重点解决如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。
因此，说白了，所谓的维度建模就是一种组织数据仓库的形式、模型，用这种方式组织搭建的数据仓库，对快速支持数据分析有着巨大的帮助。目前也是比较主流的数仓模型了。

2、维度建模的基础知识

1）事实与事实表

事实表是指其中保存了大量业务度量数据的表，是数仓最核心的表。

事实表中的度量值一般称为事实。通常，最有用的事实就是数字类型的事实和可加类型的事实。

事实表的粒度，决定了数据仓库中数据的详细程度。

一般事实表中只存放数字或一些flag用来统计，如：销售金额、成本等。另外，通常事实表中的数据不允许修改，新的数据只是简单地添加到事实表中。

事实表特点：数据量庞大、列数少、经常变化。因为事实表是一张业务表，业务数据是不断变化的。

• 事务事实表：该类型表的一行对应空间或时间上某点的度量事件。与粒度同层次的事实表，可以直接将事实字段进行Sum、Count等聚合操作。
• 周期快照事实表：该类型表中的每行汇总了发生在某一标准周期，如某天、某周、某月的多个度量事件。这类表非常适合跟踪长期的过程，如银行账户和其他形式的财务报表。
• 无事实事实表：没有度量事实，仅记录一系列某一时刻发生的多维实体。非事实型事实表**:通常用来跟踪一些时间或者说明某些活动的范围。
• 累积快照事实表：行汇总了发生在过程开始和结束之间可预测步骤内的度量事件。管道或工作流过程（履行订单、索赔过程），都可以在此类事实表中被建模。

2）维度与维度表

维度表是用户来分析数据的窗口，比如时间、地区、用户等。

维度表中包含事实表中记录的特性，有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息。

维度表等特点：很多描述性的列，行数较少，内容较固定。比如地域，省市区县这些内容基本不会变化。

关于维度表，主要看看缓慢变化维。

什么是缓慢变化维？在现实世界中，维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化。这种随时间发生变化的维度我们一般称之为缓慢变化维。

比如，在一个零售业数据仓库中，事实表存着销售人员的销售记录，某天一个销售人员从北京分公司调到上海分公司了，那么如何来保存、处理这个变化呢？

如果我们要统计北京地区或上海地区的总销售情况的时候，这个销售人员的销售记录应该算在北京还是算在上海？当然是调离前的算在北京，调离后的算在上海,但是如何标记这个销售人员所属区域？这里就需要处理一下这个维度的数据，即我们缓慢变化维需要做的事情。

处理缓慢变化维的三种方式：

• 直接覆盖原值：这个比较简单粗暴。但是如果想要做历史分析的话，就比较难了，一般不太覆盖。
• 增加属性列：增加一个新列，来记录变化。这种适合变化比较少的情况，如果经常变化，增加无限量个字段明显不合适。
• 增加维度行：直接增加一条新纪录，并用一个专门的字段（可以是时间、版本、是否生效等等）进行标识，区分哪个数据是最新的。

3）粒度

粒度是指数据仓库的数据单位中，保存数据的细化程度的级别。简单点来看，在实事表中一条记录所表达的业务细节，就是粒度。

通常，为了便捷的下钻分析，我们都会使用到最小粒度。比如订单表中，最小粒度就是一条订单的记录。

使用最小粒度的优点：

• 可以频繁的ETL操作
• 很多数据挖掘需要最小粒度数据
• 方便向下钻取

当然，使用最小粒度也有缺点：

• 存储和维护代价较高
• 需要进一步构建汇总事实表来支持汇总数据查询

4）切片、切块、旋转

• 切片：切片：从多维数组中选定一个二维子集，切出一个“平面” 。比如选中上图的2011年，这就是一个切片。
• 切块：从多维数组中选定一个三维子集，切出一个“立方体” 。比如上图中，年度选择了2011、2012，然后看所有的数据内容，这就是一个切块。
• 旋转：改变一个报告（页面）显示的维方向。

5）钻取（上钻、下钻）

根据维层次，改变数据分析的粒度，就是钻取分析，主要包括上钻（也叫上卷）和下钻。

• 下钻：从汇总数据深入到细节数据进行观察或增加新维
• 上钻（上卷）：从某一维上将低层次的细节数据概括到高层次的汇总数据或减少维数
• 钻透：直接下钻到最明细的数据

3、维度建模常用模型

1）星型模型

事实表被维度表所包围，且维度表没有被新的表连接。

每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。

2）雪花模型

有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上，就像雪花一样。

雪花模型去除了数据冗余，更贴近与业务。尽可能降低数据存储量以及联合较小的维表来改善查询性能。

但是雪花模型分析数据时，需要关联的内容越来越多，操作比较复杂。但数据的存储量下来了。

3）星座模型

无论是星型模型还是雪花模型，都是单事实表的情况。但通常来讲，实践当中大部分情况都是多事实表的。这时就是需要星座模型了。

所谓星座模型，是多个事实表共享维度表， 因而可以视为星型模型的集合，故亦称星座模型（星系模型）。

星座模型是数据仓库最常使用的模型。

3、维度建模与范式建模

1）范式建模

范式建模是数仓之父 Inmon 所倡导的，“数据仓库”这个词就是这位大师所定义的，这种建模方式在范式理论上符合 3NF，这里的 3NF 与 OLTP 中的 3NF 还是有点区别的：关系数据库中的 3NF 是针对具体的业务流程的实体对象关系抽象，而数据仓库的 3NF 是站在企业角度面向主题的抽象。

Inmon 模型从流程上看是自上而下的，自上而下指的是数据的流向，“上”即数据的上游，“下”即数据的下游，即从分散异构的数据源 -> 数据仓库 -> 数据集市。以数据源头为导向，然后一步步探索获取尽量符合预期的数据，因为数据源往往是异构的，所以会更加强调数据的清洗工作，将数据抽取为实体-关系模型，并不强调事实表和维度表的概念。

范式建模就是将源表抽取为实体表，关系表，所以范式建模即是实体关系（ER）模型。数据没有冗余，符合三范式设计规范。

2）维度建模

Kimball 模型从流程上看是自下而上的，即从数据集市-> 数据仓库 -> 分散异构的数据源。Kimball 是以最终任务为导向，将数据按照目标拆分出不同的表需求，数据会抽取为事实-维度模型，数据源经 ETL 转化为事实表和维度表导入数据集市，以星型模型或雪花模型等方式构建维度数据仓库，架构体系中，数据集市与数据仓库是紧密结合的，数据集市是数据仓库中一个逻辑上的主题域。

使用 Kimball 模式，需要将数据抽取为事实表和维度表。

在 Kimball 的维度建模中，不需要单独维护数据关系表，因为关系已经冗余在事实表和维度表中。

3）两种建模方式对比

范式建模：范式建模的优点：能够结合业务系统的数据模型，较方便的实现数据仓库的模型；同一份数据只存放在一个地方，没有数据冗余，保证了数据一致性；数据解耦，方便维护。但同时也带来了缺点：表的数量多；查询时关联表较多使得查询性能降低。

维度建模：优点是模型结构简单，面向分析，为了提高查询性能可以增加数据冗余，反规范化的设计，开发周期短，能够快速迭代。缺点就是数据会大量冗余，预处理阶段开销大，后期维护麻烦；还有一个问题就是不能保证数据口径一致性。

4）混合使用范式建模和维度建模

范式建模必须符合准三范式设计规范，如果使用混合建模，则源表也需要符合范式建模的限制，即源数据须为操作型或事务型系统的数据。通过 ETL 抽取转换和加载到数据仓库的 ODS 层，ODS 层数据与源数据是保持一致的，所以 ODS 层数据也是符合范式设计规范的，通过 ODS 的数据，利用范式建模方法，建设原子数据的数据仓库 EDW，然后基于 EDW，利用维度建模方法建设数据集市。

结合两种建模方式的各自规范，混合建模按照“松耦合、层次化”的基本架构原则进行实施。混合数据仓库架构方法主要包含以下关键步骤：业务需求分步构建、分层次保存数据、整合原子级的数据标准、维护一致性维度等。

参考文章： https://www.easemob.com/news/6520