维度建模（二）

Kimball维度建模基础

一、概览

1.1 基本概念

• 维度建模步骤：

  1. 选择业务过程
  2. 声明粒度
  3. 确定维度
  4. 确定事实

• 业务过程：指组织完成的业务型活动，如获取订单、会员注册、每月销售额快照等。业务过程事件获取度量，转化为事实表中的事实

• 粒度：用于确定事实表中一行代表什么，在选择维度和事实前必须确定粒度，确保维度和事实与粒度一致。原子粒度是最细粒度，通常维度建模要从原子粒度开始

• 维度：围绕某一过程时间，用于描述 “谁、什么、何处、何时、如何、为什么” 等背景

• 事实：设计过程事件的度量，通常是数量值，事实表的行与事件必须是一对一的关系，同一张表中所有行都必需有相同的粒度

• 维度模型扩展：

  • 可以在事实表创建新列，前提是新增事实与事实表粒度一致
  • 可以添加新的外键将维度关联到已存在的事实上，但前提是维度与事实粒度一致
  • 可以在维度表创建新列，用来增加维度属性
  • 可以使事实表更加原子化，方法是在维度表增加属性，然后以更细的粒度重置事实表

二、事实表技术基础

2.1 事实表结构

• 事实表存储真实世界中操作型事件产生的可度量数值
• 存储的字段包括与维度表关联的外键，度量的数值，以及可退化的维度属性和日期/时间戳

2.2 可加、半可加、不可加事实

• 可加：可加性度量是最灵活、最有用的，可以按与事实表关联的任何维度汇总
• 半可加：仅可对部分维度进行汇总，如账户余额不可按时间维度累加
• 不可加：某些度量是完全不能汇总的，例如比率

2.3 事实表中的NULL

• 事实表中可以存在空值度量，所有聚合函数都能对NULL做处理
• 事实表中与维度表关联的外键不能存在空值

2.4 一致性事实

• 如果某些度量存在不同的事实表中，应注意，如果要比较不同表中的同一度量，则要保证该度量的定义要保持一致
• 若不同表的事实定义是一致的，则度量的命名应是相同的，若定义不一致，则应有不同的命名

2.5 事务事实表

• 每一行对应时间或空间上某点的度量事件，仅当发生事件、产生度量时才会生成行
• 度量事实必须与实务保持粒度一致
• 包含与维度表关联的外键，也可包含精确的时间维度与退化维度

2.6 周期快照事实表

• 每一行汇总了发生在某一标准周期（一天、一周、一月等）内的多个度量事件
• 粒度是周期性的，而不是具体事件，任何与粒度一致的事实都是可以存在的
• 即使周期内没有发生事实，也会生成行，此时的度量为0或NULL

2.7 累积快照事实表

• 每一行汇总了发生在过程开始和结束之间可预测步骤内的度量事件，过程有标准的开始点、中间步骤与结束点
• 如订单信息，产生订单时会生成新的一行，当订单过程各个不同步骤发生时，这一行的信息则被修改
• 除了事件外键与每个关键步骤关联外，也包含其他维度和可选退化维度的外键

2.8 无事实的事实表

• 仅记录某一时刻发生的多维实体，而没有记录数值度量
• 如学生选课记录、客户交互记录，都没有可记录的数值度量

2.9 聚集事实表或OLAP多维数据

• 对原子粒度事实表进行简单上卷，可有效提高查询性能
• 包含外键来缩小一致性维度
• 构建过程是对来自多个原子粒度事实表的度量进行汇总
• OALP多维数据的构建与聚集事实表相同，不同的是OLAP直接对商业客户开放，而聚集事实表是提供给BI层访问的

合并事实表

• 将来自多个过程，粒度相同的事实合并为一个单一的合并事实表
• 适合需要共同分析的多过程度量
• 增加ETL负担，减少BI分析代价

三、维度表技术基础

3.1 维度表结构

• 包含单一主键，作为与之关联的任何事实表的外键
• 通常较宽，扁平型非规范表，包含大量低粒度文本属性
• 用作查询和应用的约束和分组定义目标

3.2 维度代理键

• 维度表的主键不是操作型系统的自然键，由于需要跟踪变化，若采用自然键则需要多个维度行来表示。且自然键可能由多个系统生成，必然会出现兼容性问题
• 可以为每个维度建立无语义的整形主键，从1开始按顺序自动累加1
• 日期维度是高度可预测的且稳定的，可以使用更有意义的主键

3.3 自然键、持久键、超自然键

• 操作型系统的自然键受业务规则影响，无法被DW控制
• 为某一实体创建不受业务影响的单一不变的主键，即称为持久性超自然键
• 最好的持久键应独立于原始操作过程，并以整数1开始分配，当某行的代理键发生变化时持久键不变

3.4 下钻

• 分析数据的最基本方法
• 需要在查询加上一个行头指针，指针为一个维度属性，附加SQL的group by表达式
• 不需要事先存在的层次定义，或下钻路径

3.5 退化维度

• 可能存在某些维度仅包含主键，而无其他维度属性
• 当某一事实表维度继承了全部维度表属性，记录某个度量数值，维度表便只有外键了
• 此时会将这种退化维度放在事实表中，表明没有关联的维度表
• 常见于交易和累计快照事实表中

3.6 非规范化扁平维度

• 抵制操作型系统的规范化设计思路，将维度表设计为冗余的、较宽的表，包含尽量多固定深度层次的属性
• 两个好处：简化、查询速度

3.7 多层次维度

• 包含不同层次的维度属性，如日期维度可以包含天、周、月、年，地理维度可以包含国、省、市、区等

3.8 文档属性的标识和指示器

• 缩写、真假标识、业务指标可以作为维度表中文本含义的补充解释
• 操作代码所包含的含义应拆分为描述含义不同的多个维度属性

3.9 维度表中的NULL

• 维度表的一行可能不会被全部填充，属性没用被用于所有维度行的情况即会产生NULL值
• 由于不同系统在分组是对空值的处理规则不同，应尽量避免在维度表中使用NULL值，可以使用unknown等字符串填充

3.10 日历日期维度

• 利用日期维度可对事实表按日期、月份、财报周期或日历上的特殊日期进行分析
• 日历日期维度可以包含多个属性，如周数、月份、财务周期、法定假日等属性
• 日期维度的主键可以使用一个整数表示YYYMMDD，而不用使用顺序分配的代理键
• 如果需要更加精确的时间精度，可以在事实表增加不同精度的时间戳属性，日期时间戳并非日期维度表的外键，而是作为单独的列存在

3.11 扮演角色的维度

• 单个物理维度表可被事实表多次引用，这些引用代表的意义不同
• 如事实表可以有多个日期维度外键，每个外键表示不同的日期维度视图，代表不同的含义
• 这些维度视图（唯一的属性列名）被称为角色

3.12 杂项维度

• 商业事务过程中的事件可能存在许多混杂的、低粒度的标识和指示器
• 与其维护大量的混杂维度，不如创建一个将这些维度合并到一起的杂项维度
• 杂项维度不需要包含所有可能的笛卡尔积，只需要组合那些实际会发生的属性值组合即可

3.13 雪花维度

• 当维度表中的属性层次为规范化时，可以分割为多层维度表，通过属性键关联到基础维度表，这一维度结构即称为雪花模式
• 实际设计中应避免雪花模式，使用扁平非规范化的星型模式完全可以达到相同的效果，且查询性能更高

3.14 支架维度

• 维度表可以引用其他维度表，比如账户维度表的开户日期可以引用日期维度表，被引用的维度即称为支架维度
• 应尽量减少支架维度的使用，不同维度应在事实表中使用不同的外键进行关联