维度数据模型建模过程 (Kimball)
一、维度建模:
通常以星型模型构建
一个事实表
周围环绕多个维度表
建模过程
选择业务流程
声明粒度(维度的取值范围)
确认维度
确认事实
1 选择业务流程
确认哪些业务处理流程是数仓要覆盖的,是维度建模的基础
建模的第一个步骤:描述需要建模的业务流程
描述业务流程
使用简单的纯文本描述
业务流程建模标注(BPMN)——工作流的工具
2 声明粒度
确认数据的粒度,其实就是对应不同的维度的粒度
建议从原始粒度数据开始设计
例如:
时间粒度——秒级
地域粒度——乡镇级
商品分类——三级分类
3 维度建模过程 - 确认维度
维度的粒度必须和声明的粒度一致
维度表是事实表的基础,也说明了事实表的数据是从哪里采集来的
典型的维度都是名词
日期
商店
库存等
维度表存储了某一维度的所有相关数据,例如:日期维度应该包含:
年
季度
月
周
日
4 维度建模过程 - 确认事实
识别数字化的度量,构成事实表的记录
用户通过对事实表的访问获取数据仓库存储的数据
大部分事实表的度量都是数值类型的,可累加,可计算
二、维度规范化
与关系模型类似,维度也可以进行规范化
维度的规范化(又叫雪花化),可以去除冗余属性
一个非规范化维度对应一个维度表,规范化后,一个维度会对应多个维度表,维度被严格地以子维度的形式连接到一起
维度规范化后的结构等同于一个低范式级别的关系型结构
设计维度数据模型时,会因为如下原因而不对维度做规范化处理
规范化会增加表的数量,使结构跟复杂
不可避免的多表连接,使查询跟复杂
不适合使用位图索引
查询性能原因
总体来说,但多个维度共用某些通用的属性时,做规范化是有益的。例如:客户和供应商都有省、市、区县、街道等地理位置的属性,此时分离出一个地区属性就比较合适
三、星型模型
星型模型是维度模型最简单的形式,是数据仓库以及数据集市开发中使用最广泛的形式
星型模式由以下两类表构成
事实表
维度表
一个星型模式中可以有一个或多个事实表,每个事实表应用任意数量的维度表
中心是一个事实表,围绕表周围的维度表示星星的放射状分支
星型模式将业务流程分为事实和维度
事实包含业务的度量,如:销售价格、销售数量、距离、速度、重量都是事实
维度是对事实数据属性的描述,如:
日期
产品
客户
地址位置等是维度
事实表
记录特定事件的数字化的考量
由数字值和指向维度的外键组成
通常会把事实表的粒度级别设计得比较低,使得事实表可以记录很原始的操作型事件
三种类型
事务事实表。记录特定事件的事实,如:销售
快照事实表。记录给定时间点的事实,如:月底账户余额
累积事实表。记录给定时间点的聚合事实,如:当月总的销售金额
维度表
维度表的记录数通常比事实表少,但每条记录包含有大量用于描述事实数据的属性字段
维度表可以定义各种各样的特性,以下是几种最常用的维度表
时间维度表
地理维度表
产品维度表
人员维度表
范围维度表
优点
星型模式是非规范化的。在星型模式的设计开发过程中,不受应用于事务性关系数据库的范式规则的约束
简化查询。查询数据时,星型模型的连接逻辑比较简单,而从高度规范化的事务模型查询数据时,往往需要更多的表连接
简化业务报表逻辑
获得查询性能力
快速聚合
便于向立方体提供数据
星型模式被广泛用于高效建立 OLAP 立方体--》kylin(构建 cube)
缺点
不能保证数据的完整性。一次性地插入或更新操作可能造成数据异常。所以数据装载一般都是以高度受控方式,用批处理或准实时过程执行
对于分析需求不够灵活,跟偏重于特定目的建造数据视图,很难进行全面的数据分析
四、雪花模型
一种多维模型中表的逻辑布局
也由事实表和维度表组成
所谓雪花,就是将星型模式中的维度表进行规范化处理
但所有的维度表完成规范化后,就形成了以事实表为中心的雪花型结构,即雪花模式
将维度表进行规范化的具体做法是:
把低基数的属性从维度表走过来移除形成单独的表
基数指的是一个字段中不同值的个数(例如:性别的基数就很低)
雪花模式中,一个维度被规范化成多个关联的表,而在星型模式中,每个维度由一个单一的维度表所表示
一个规范化的维度对应一组具有层次关系的维度表,而事实表作为雪花模式的子表,存在具有层次关系的多个附表
一般维度表设计成一个低于 3NF 的级别
优点
一些 OLAP 多维数据库建模工具专为雪花模型进行了优化
规范化的维度属性节省了存储空间
缺点
增加了查询的连接操作和复杂度
雪花模式的表中装载数据,一定要有严格的控制和管理,避免数据的异常插入或更细腻
版权声明: 本文为 InfoQ 作者【大数据技术指南】的原创文章。
原文链接:【http://xie.infoq.cn/article/3e6da52d5f614656201cd4d0e】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论