数据仓库建模

维度建模简介

多数情况下，数据仓库的好坏直接取决于维度属性的设置；DW/BI环境的分析能力直接取决于维度属性的质量和深度。为维度属性提供详细的业务术语耗费的精力越多，效果就越好。为属性列填充领域值耗费的精力越多，效果就越好。为确保属性值的质量耗费的时间越多，效果就越好。强大的维度属性带来的回报是健壮的分片-分块分析能力。

可以通过分析该列是一种包含多个值并作为计算的参与者的度量，这种情况下该 列往往可能是事实；
或者该列是对具体值的描述，是一个常量，某一约束和行标识的参与者，此时该 属性往往是维度属性。

维度模型表示每个业务过程包含事实表，事实表存储事件的数值化度量，围绕事实表的是多个维度表，维度表包含事件发生时实际 存在的文本环境。这种类似星状的结构通常称为星型连接。

构建维度模型一般经历四个阶段：第一个阶段是高层设计时期，定义业务过程维度模型的范围，提供每种星形模式的技术和功能描述；第二个阶段是详细模型设计时期，对每个星形模型添加属性和度量信息；第三个阶段是进行模型的审查、再设计和验证等工作；第四个阶段是产生详细设计文档，提交ETL设计和开发。

1. 高层模型
   高层模型设计阶段直接产出目标是创建高层维度模型图，它是业务过程中的维表和事实表的图形描述。确定维表创建初始属性列表，为每个事实表创建提议度量。
2. 详细模型
   详细的维度建模过程是为高层模型填补缺失的信息，解决设计问题，并不断测试模型能否满足业务需求，确保模型的完备性。确定每个维表的属性和每个事实表的度量，并确定信息来源的位置、定义，确定属性和度量如何填入模型的初步业务规则。
3. 模型审核和验证
   本阶段主要召集相关人员进行模型的审核和验证，根据审查结果对详细维度进行再设计。
4. 提交ETL设计和开发
   最后完成模型详细设计文档，提交ELT开发人员，进入ETL设计和开发阶段，由ETL人员完成物理模型的设计和开发。

指导方针

首先，在建设大数据数据仓库时，要进行充分的业务调研和需求分析。这是数据仓库的基石，业务调研和需求分析做得是否充分直接决定了数据仓库建设是否成功。
其次，进行数据总体架构设计，主要是根据数据域对数据进行划分。按照维度建模理论，构建总线矩阵、抽象出业务过程和维度。
再次，对报表需求进行抽象整理出相关指标体系，使用工具完成指标规范定义和模型设计。
最后，就是代码研发和运维。

总线矩阵

维表

层次维度

维度中的一些描述性属性以层次方式或一对多的方式相互关联，可以理解为包含连续主从关系的属性层次。

一致性维度和交叉探查

表现为以下几种：

• 共享维表
• 一致性上卷，其中一个维度的维度属性是另一个维度的维度属性的子集，而且两个维度的公共维度属性结构和内容相同。
• 交叉属性，两个维度具有部分相同的维度属性

维度设计

【 维度整合】

• 命名规范的统一。表名、字段名等统一。
• 字段类型统一。相同和相似字段的字段类型统一。
• 公共代码及代码值的统一。公共代码及标志性字段的数据类型、命名方式等统一。
• 业务含义相同的表的统一。主要依据高内聚低偶合的理念，在物理实现中，将业务关系大、源系统影响差异小的表进行整合；将业务关系小，源系统影响差异大的表进行分而置之。通常有以下几种方式：
• 采用主从表的设计方式，将两个或多个表都的字段放到主表中，从属信息分别放在各自的表中。对于主表中的主键，要么采用复合主键-源主键和系统或表区别标志；要么采用唯一主键-“源主键和系统或表区别标志”生成新的主键。通常采用复合主键的方式。
• 直接合并，共有信息和个性信息都放在同一个表中。如果表字段的重合度较低，则会出现大量空值，对于存储和易用性有影响，需要谨慎选择。
• 不合并，因为源表的表结构及主键等差异较大，无法合并，使用数据仓库多个表分别存放各自的数据。

【表级别整合】

1. 垂直整合，即不同的来源表包含相同的数据集，只是存储的信息不同。
2. 水平整合，即不同的来源表包含不同的数据集，不同子集之间无交叉，也可以存在部分交叉。

缓慢变化维度

SCD: Slowly Changed Dimension
【SCD0】保留原始值
【SCD1】重写，覆盖维度行中的旧值，始终反映最近的情况
【SCD2】增加新行，在表中增加三列方便管理。分别为：行有效日期、行失效日期和当前行指示器
【SCD3】增加新属性
【SCD4】增加微型维度
【SCD5】混合SCD1和SCD4，微型维度主键引用的是SCD1属性，重写概要的变化 。若微型维度主键在主维度中，则称为支架；若只存在于事实表外键，则为微型维度。
【SCD6】混合SCD1,SCD2,SCD3。为获取变化（SCD2）建立新行，增加新列以跟踪当前分配（SCD3),后续变化 采用SCD1.
【SCD7】双重SCD1和SCD2

快照维表

以天为周期，每天保留一份全量的维度快照数据。任意一天的事实均可以获取当天的维度信息，也可以获取最新的维度信息，通过限定日期，采用自然键关联即可。
此方法的弊端在于存储的浪费。

极限存储

历史拉链存储指的是利用维度模型缓慢变化维的第二种处理方式。这种方式是通过新增两个时间戳，将所有以天为粒度的变更数据都记录下来。

事实表

事实表设计原则

原则1：尽可能包含所有与业务过程相关的事实
事实表设计的目的是为了度量业务过程，所以分析哪些事实与业务过程有关是设计中非常重要的关注点。在事实表中应该尽量包含所有与业务过程相关的事实，即使存在冗余，但是因为事实通常为数字型，带来的存储开销也不会很大。

原则2：只选择与业务过程相关的事实
在选择事实时，应该注意只选择与业务过程有关事实。

原则3：分解不可加性事实为可加的组件
对于不具备可加性条件的事实，需要分解为可加的组件。

原则4：在选择维度和事实之前必须先声明粒度
粒度的声明是事实表设计中不可忽视的重要一步，粒度用于确定事实表中一行所表示业务的细节层次，决定了维度模型的扩展性，在选择维度和事实之前必须先声明粒度，且每个维度和事实必须与所定义的粒度保持一致。

原则5：在同一个事实表中不能有多种不同粒度的事实
事实表中的所有事实需要与表定义的粒度保持一致，在同一个事实表中不能有多种不同粒度的事实。

原则6：事实的单位要保持一致

原则7：对事实的null值要处理

原则8：使用退化维度提高事实表的易用性

事务事实表

比较	单事务事实表	多事务事实表
业务过程	一个	多个
粒度	相互间不相关	相同粒度
维度	相互间不相关	一个
事实	只取当前业务过程中的事实	保留多个业务过程中的事实，非当前业务过程中的事实需要置零处理
冗余维度	多个业务过程，需要冗余多次	不同的业务过程只需要冗余一次
理解程度	易于理解，不会混淆	难以理解，需要通过标签来限定
计算存储成本	较多，每个业务过程都需要计算存储一次	较少，不同业务过程整合到一起，降低了存储计算量，但是非当前业务过程的度量存在大量零值

1. 单事务事实表
2. 多事务事实表

周期快照事实表

周期快照事实表，简称“快照事实表”，快照事实表在确定的时间间隔内，对实体的度量进行抽样。

• 快照事实表的粒度通常以维度形式声明；
• 事务事实表是稀疏的，但是快照事实表是稠密的；
• 事务事实表中的事实是完全可加的，但是快照模型将至少包含一个用来展示半可加性质的事实。

稠密性是快照事实表的重要特征。

设计步骤：

1. 确定粒度
   确定采样周期，针对维度的快照事实表等。
2. 确定状态度量
   确定好粒度后，针对此粒度确定需要采样的状态度量

周期快照事实表分为单维度快照事实表和多维度事实表。
两类事实表的共同特点是，都可以从事务事实表进行汇总产出，这是周期快照事实表常见的一种产出模式。除此之外，还有一种产出模式，即直接使用操作型系统数据作为周期快照事实表的数据源进行加工。

全量快照事实表

特殊的周期快照事实表