浅谈维度建模

前言：本人作为BI方向相关的数据系统后端开发，虽然不是从事具体的数仓方面的工作，但是对维度建模过程有个大致了解，可加深对于系统现有的架构设计的理解（比如数据模型构建，指标库的作用），能够对数据的扭转过程有个清晰的认识，方便与数仓同学进行合作，故小记一下。

Inmon vs Kimball

Inmon

自顶向下，即从数据源到数据仓库再到数据集市的（数据仓库->数据集市）一种瀑布流开发方法
数据源往往是异构的，比如从自行定义的爬虫数据就是较为典型的一种，数据源是根据最终目标自行定制的
不强调事实表和维度表的概念，因为数据源变化的可能性较大，需要更加强调数据的清洗工作，从中抽取实体-关系
可以称之为数据集成

该图片摘自网络，侵删！

Kimball

自底向上的，即从数据集市到数据仓库再到数据源(数据集市->数据仓库)的一种敏捷开发方法
Kimball的维度数据仓库是基于维度模型建立的企业级数据仓库，架构可以称之为“总线体系结构”
对于Kimball模式，数据源往往是给定的若干个数据库表，数据较为稳定但是数据之间的关联关系比较复杂，需要从这些OLTP中产生的事务型数据结构抽取出分析型数据结构，再放入数据集市中方便下一步的BI与决策支持

该图片摘自网络，侵删！

维度建模

概述

维度建模是一种将数据结构化的逻辑设计方法，它将客观世界划分为度量和上下文。
度量是常常是以数值形式出现，事实周围有上下文包围着，这种上下文被直观地分成独立的逻辑块，称之为维度。

3NF

3NF主要强调消除冗余，规范化的3NF将数据划分为多个不同的实体，每个实体之间构成一个关系表

• 第一范式：要求数据库表中的每一行都是唯一的，这通常通过主键来确定。并且要求属性是原子性的，不能再细分

• 第二范式：在第一范式的基础上，还要求每个非键属性必须完全函数依赖于整个候选键，例如一个学生表（姓、名、年龄、身高），想要知道年龄，必须通过姓和名两个候选键，而不能只通过名就知道其年龄

• 第三范式：在第二范式的基础上，还要求每个非键属性必须非传递依赖于候选键，也就是说所有非键属性之间相互独立。这里边怎么理解呢？可以认为在一张表中，不能通过一个非键属性就能知道另一个非键属性

实体-关系建模 vs 维度建模

• 实体-关系建模：面向应用，遵循第三范式，以消除数据冗余为目标的设计技术
• 维度建模：面向分析，为了提高查询性能可以增加数据冗余，反规范化的设计技术

维度建模优点

• 便于理解
• 提高查询性能
• 对称性
• 可扩展性

基本要素

事实表

维度模型中的事实表存储组织机构业务过程事件的性能度量结果
“事实”这一术语表示某个业务度量
事实表中的每行对应一个度量事件，每行的数据是一个特定级别的细节数据，成为粒度

三种基本事实表粒度

• 事务事实表
  它是面向事务的，其粒度是每一行对应一个事务，它是最细粒度的事实表

• 周期快照事实表
  它是按照良好的时间周期间隔(每天，每月)来捕捉业务活动的执行情况，一旦装入事实表就不会再去更新，它是事务事实表的补充，而非替代品

• 累积快照事实表
  它用于描述业务过程中某个不确定时间跨度里的活动，它随着业务活动的发生会不断的更新

维度表

维度表包含与业务过程度量事件有关的文本环境。用于描述“谁、什么、哪里、何时、如何、为什么”

维度属性可作为查询约束、分组、报表标识的主要来源

• 缓慢变化维

类型1:字段值发生变化时覆盖原来的值

类型2:字段值发生变化时会新增一行，重新分配代理键，每一行添加开始日期，结束日期，版本号，是否当前值 eg:历史部门记录表（生效时间、失效时间）

类型3:每条记录会新增一列来标识变化前的值，发生变化时，把旧值放到新增的列中，把新值覆盖旧值

类型4:混合类型

• 日期维
  它是数据仓库必须有的维度，包含日期，日期所属的周，月，季度，年等信息
  eg:公共日期表

• 角色维
  相同的维度表在维度模型中扮演不中的逻辑角色，一般通过创建视图来表示

• 杂项维
  如果每个属性值都很少，可以把这些维度的组合起来生成一个维度表

• 支架维
  如果维度之间是一对多的关系或区别于原维度的多个描述性维度属性，可以建雪花型支架维度

• 多值维度桥接维
  如果二个维度表是多对多的关系，可以使用多值维度设计

• 微型维
  一个大型维有些属性变化比较频繁，把这些属性单独生成一个微型维度表

• 缩小维
  它是维度表的一个子集或部分属性

• 查找维
  系统里代码表里维度信息

• 层次维
  有些维度表是有层次结构的，可以通过视图生成树形结构的维度表

• 手工维护的维表
  有些数据不在业务系统里，需要业务用户手工维护的维度表

一致性维度和事实

企业数据仓库应该建立一个一致性维度和事实，而不是为每个部门建立维度和事实。

• 一致性维度
  具有一致的维度关键字，一致的属性列名称，一致的属性定义和一致的属性值。一致性维度要么是统一的，要么是维度表的一个子集。

• 一致性事实
  指每个度量在整个数据仓库中都是唯一的统计口径，为了避免歧义，一个度量只有唯一的业务术语。

三种模型

星型

• 最常用的维度建模方式,以事实表为中心，所有的维度表直接连接在事实表上，像星星一样
• 维表只和事实表关联，维表之间没有关联
• 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键
• 以事实表为核心，维表围绕核心呈星形分布

雪花

• 是对星型模式的扩展
• 雪花模式的维度表可以拥有其他维度表的，虽然这种模型相比星型更规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能也比星型模型要低。所以一般不是很常用

星座

• 星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息
• 在业务发展后期，绝大部分维度建模都采用的是星座模式

维度模型设计方法

• 选定业务过程
• 根据业务过程的优先级选定业务过程
• 确定粒度
• 确定事实表粒度，最好是原子级粒度
• 确定维度
• 有了业务过程和粒度，就要选择相关的维度
• 确定事实
• 选择适用于业务过程的事实

总结

在进行维度建模的过程中，必须遵循的一个原则是同一事实表中的所有度量行必须具有相同的粒度，并且必须注意其简单性和对称性
维度属性的好坏直接决定着数据仓库的好坏，DW/BI的分析能力也直接取决于维度属性的质量和深度。维度属性设计的好，能直接体现在分片-分块分析能力

参考
《数据仓库工具箱（第三版）》