维度建模分享

1.十字路口：维度建模与范式建模的反思

1.1 范式建模

数据仓库之父 Bill Inmon 提出的建模方法，

其著有： 《 Building the Data Warehouse ( 建立数据仓库 ) 》

 主要思想是站在整个企业高度设计一个符合三范式的业务主题数据仓库，用 ER 模型来描述企业业务

该建模思想的出发点是为了整合企业全域数据，将分布在各个业务系统中的数据按企业关心的业务主题进行梳理与合并，

并进行一致性处理，为未来的数据分析决策提供全域数据支持，但并不能直接用于分析决策

 该建模思想具有如下特点：需要全面了解企业业务和数据；实施周期长；对建模人员的能力要求高

1.2 维度建模

维度建模是Ralph Kimball 大师所倡导的建模方法，
其著有：《The Data Warehouse Toolkit : The Complete Guide to Dimensional Modeling (数据仓库工具箱：维度建模完全指南)》，
维度建模从一个个具体的分析决策需求来构建模型，因此它重点关注用户如何更快速地完成数据分析，同时也具有较好的大规模复杂查询的响应性能。
其典型代表是星型模型，以及在一些特殊场景下使用的雪花模型 

维度与事实

维度与事实：在维度建模中，我们将分析的内容称为“事实”或“度量”，将分析的角度称为“维度”。比如在分析交易过程时，我们可以通过会员、店铺、商品、日期等维度来描述交易发生的环境。

维度主键：维度使用主键标识其唯一性，维度主键是确保与之相连的任何事实表之间引用完整性的基础。主键有两种形式：代理键和自然键，代理键是无业务含义的键，自然键是有业务含义的键，它们都是用于标识某维度的具体值。需要说明的是，在业务系统中是作为代理键的字段（如SKU_ID），对于数据仓库来说则属于自然键。

维度属性：维度表中表示维度的字段，称为维度属性；维度属性是根据约束条件进行查询、数据分组、报表标签生成，以及查询结果排序的基础。

维度表设计的一般原则

1 、维度属性尽量丰富。 比如在做商品维度设计时，可以放置尽量多的属性，避免后续在分析应用时因属性缺失，频繁修改表结构。

2 、维度属性应该是便于使用的。 如我们将 ODS 中的商品类目表，在做维度设计时，由递归形式转换为展平形式。

3 、维度表的命名规则、维表字段的命名规则以及相同或相似字段的类型应该是全域统一的。 —— 事实表也应如此

4 、通用维表的代码取值尽量是统一的。 一些维表，如币种、地域、性别、来源平台、事业部等，优先选用国标码或者行标码；如果

没有对应的国标行标，需要根据公司数据情况，整合出一套公司级的数据标准码。

5 、维表的整合与拆分。 我们需要将含义相同的业务系统维表进行整合与拆分。整合就是把多个来源不同格式的业务系统维表整合为

一张维表；拆分就是把业务系统的一张维度根据字段的主从关系拆分为多张维表。主要目的是为了易用、稳定和可扩展。

多值维度的处理

 当一个维表中的某个属性字段同时有多个值，我们称之为“多值属性”。

 比如商品 SKU维表、商品属性维表、商品图片维表、商品标签品均有一个或多个SKU、一个或多个属性、一张或多张图片，一个或多个标签，所以商品与SKU、属性、图片、标签都是多对多的关系。

对于这种多值属性的处理，一种方式是保持维度主键不变，将多值属性放在维

度的一个属性字段中，用 K-V 形式或者数组形式存储，这种方式扩展性好，但数

据使用比较麻烦。

第二种方式是保持维度主键不变，将多值属性放在维度的多个属性字段中，这种方式使用简单，但扩展性较差，比较适合于固定数量的值。

变化维度（缓慢变化维）的处理

1 、历史拉链维表：

 主要处理方式是新增两个日期字段（ start_dt 和 end_dt ），来描述维度属性的变化轨迹。

 在历史拉链维表中，代理键无法定位唯一一条维度数据，需要通过“代理键 +start_dt ”进行唯一定位。

 维度表通过“代理键 +start_dt ”，与事实表中的“维表代理键 +业务日期”进行关联，可以获取到事实表当时日期的维度属性

值。

 通过筛选历史拉链维表中每一个代理键的 start_dt 为 max(start_dt) 的数据，可以获取到当前状态的全量维度数据。

 在维护历史拉链维表的同时，如再新增 1 个有效标志位字段（ is_valid ），将 max(start_dt) 的那些维度数据置为 1 ，其余置为 0，则通过筛选历史拉链维表中每一个代理键的 is_valid=1 的数据，可以更方便地获取到当前状态的全量维度数据

2 、全量快照维表：

 主要处理方式是将每天的全量维表数据作为一个日期快照，来记录维表属性的变化轨迹。

 这种处理方式一般适用于数据量较小且维度属性会变化的维表；如果维度数据量大，带来的计算和存储压力将是非常大的。

两类事实表

事实表主要有如下两种类型：

1 、明细事实表（原子事实表）：用来描述业务过程，跟踪空间或时间上

某点的度量事件，保存的是最原子的数据。

2 、汇总事实表（快照事实表）：使用具有规律性的、可预见的时间间隔

来记录事实，时间间隔如每天、每月、每年等。

事实表设计的一般原则

 在选择维度与事实之前，必须先确定粒度，同一个事实表中不能有多个不同粒度的事实

 只选择与业务过程相关的事实，可以把业务相近或者相关、粒度相同、高概率同时访问的数据设计为一个数据模型

尽可能包含所有与业务过程相关的事实，可以建立核心模型与扩展模型分离体系，核心模型中的字段支持常用的核心业务，且必须是稳定的；扩展模型中的字段支持个性化需求，避免频繁进行字段调整而影响核心模型的稳定性

 事实表的字段命名需要统一且可理解。具有相同含义的字段在不同表中的命名必须相同，必须使用规范定义中的名称，且命名是易于理解的

 事实的计量单位要保持一致

 对事实中的 null 值要进行处理

 可以使用退化维度来提高事实表的易用性

事实表设计的一般方法

1 、确定业务过程

 在收到一个业务需求后，我们需要对其进行详细的需求分析，找出与需求有关的业务过程。

2 、确定数据粒度：

 应该尽量选择最细级别的原子粒度，以确保事实表的应用具有最大的灵活性。

 比如对于订单过程而言，粒度可以被定义为最细的订单级别，比如为子订单（每种 SKU 都对应一个子订单），而不是父订单。

3 、确定维度：

 确定粒度后，也就意味着确定了主键，对应的维度组合以及相关的维度字段就可以确定了。

 比如在在天猫订单付款明细事实表中，粒度为子订单，相关的维度有会员、店铺、商品 SKU 、收货人、订单时间等。

4 、确定事实：

 应该选择与业务过程有关的所有事实，且事实的粒度需要与所确定的事实表的粒度一致。

 事实一般都是可聚合的，比如在天猫订单付款明细事实表中，同粒度的事实有子订单分摊的支付金额、邮费、优惠金额等。

单业务事实表与多业务事实表的选择

 单业务事实表与多业务事实表

        单事务事实表：一个业务过程建立一个事实表，只反映一个业务过程的事实

        多业务事实表：多个业务过程只建立一个事实表，可以同时反映多个业务过程的事实

 适用多业务事实表的场景

        不同业务过程之间具有相似性

        不同业务过程之间的粒度必须一致

        不同业务过程之间拥有相似的维度

 多业务事实表的设计方法

        不同业务过程的事实使用不同的事实字段进行存放。

           这种设计方法适用于不同业务过程的度量差异较大时；其优点是易于理解

        不同业务过程的事实使用同一个事实字段进行存放，并增加一个业务过程标签来区分。

           这种设计方法适用于当不同业务过程的度量差异较小时；其优点是计算与存储成本较低