“ 维度建模是数仓的核心,建模的好坏,决定了数仓对于企业支撑的价值。 ”\
01 基本概念
企业可以通过一系列维数相同的数据集市递增地构建数据仓库,通过使用一致的维度,能够共同看到不同数据集市中的信息,这表示它们拥有公共定义的元素。这里我主要介绍维度建模方法。这一方法是Kimball最先提出的,其最简单的描述就是,按照事实表、维度表来构建数据仓库、数据集市。
事实表
在多维数据仓库中,保存度量值的详细值或事实的表称为“事实表”。一个按照州、产品和月份划分的销售量和销售额存储的事实表有5个列,概念上与下面的示例类似。
Sate | Product | Mouth | Units | Dollars |
---|---|---|---|---|
WA | Mountain-100 | January | 3 | 7.95 |
WA | Cable Lock | January | 4 | 7.32 |
OR | Mountain-100 | January | 3 | 7.95 |
OR | Cable Lock | January | 4 | 7.32 |
WA | Mountain-100 | February | 16 | 42.40 |
在这些事实表的示例数据行中,前3个列——州、产品和月份——为键值列。剩下的两个列——销售额和销售量——为度量值。事实表中的每个列通常要么是键值列,要么是度量值列,但也可能包含其他参考目的的列——例如采购订单号或者发票号。
事实表数据行中包含了您想从中获取度量值信息的最底层级别的明细。换句话说,事实表中对每个维度的最详细的项目成员都有数据行。如果有使用其他维度的度量,只要为那些度量和维度创建另一个事实表即可。数据仓库中可能包含拥有不同度量值和维度的不同事实表。
前面表格中的示例数据行显示了事实表的概念布局。事实是事实表几乎总会使用一个整数值来表示(维度)成员,而不使用描述性的名称。因为事实表往往会包含数量多得无法想象的数据行——在一个中等大小的数据仓库中,事实表动辄包含上百万行数据——使用整数键值可以有效地减小事实表的大小。事实表真正的布局如下所示。
STATE_ID | PROD_ID | Month | Sales_Units | Sales_Dollars |
---|---|---|---|---|
1 | 347 | 1 | 3 | 7.95 |
1 | 447 | 1 | 4 | 7.32 |
2 | 347 | 1 | 3 | 7.95 |
2 | 447 | 1 | 4 | 7.32 |
1 | 347 | 2 | 16 | 42.40 |
在事实表中使用整数键值时,维度成员的名称需要放到另一种表中——也就是维度表。通常,事实表中的每个维度都有一个维度表。
事实表前缀为Fact。
归纳:
每个数据仓库都包含一个或者多个事实数据表。事实数据表可能包含业务销售数据,如现金登记事务。
所产生的数据,事实数据表通常包含大量的行。事实数据表的主要特点是包含数字数据(事实),并且这些数字信息可以汇总,以提供有关单位作为历史的数据,每个事实数据表包含一个由多个部分组成的索引,该索引包含作为外键的相关性纬度表的主键,而维度表包含事实记录的特性。事实数据表不应该包含描述性的信息,也不应该包含除数字度量字段及使事实与纬度表中对应项的相关索引字段之外的任何数据。
包含在事实数据表中的“度量值”有两中:一种是可以累计的度量值,另一种是非累计的度量值。最有用的度量值是可累计的度量值,其累计起来的数字是非常有意义的。用户可以通过累计度量值获得汇总信息,例如。可以汇总具体时间段内一组商店的特定商品的销售情况。非累计的度量值也可以用于事实数据表,单汇总结果一般是没有意义的,例如,在一座大厦的不同位置测量温度时,如果将大厦中所有不同位置的温度累加是没有意义的,但是求平均值是有意义的。
一般来说,一个事实数据表都要和一个或多个纬度表相关联,用户在利用事实数据表创建多维数据集时,可以使用一个或多个维度表。
维度表
维度表包含了维度的每个成员的特定名称。维度成员的名称称为“属性”(Attribute)。假设Product维度中有3种产品,那么维度表将如下所示。
PROD_ID | Product_Name |
---|---|
347 | Mountain-100 |
339 | Road-650 |
447 | Cable Lock |
产品名称是产品成员的一个属性。因为维度表中的Product ID与事实表中的Product ID相匹配,称为“键属性”。因为每个Product ID只有一个Product Name,显示时用名称来替代整数值,所以它仍然被认为是键属性的一部分。
在数据仓库中,维度表中的键属性必须为维度的每个成员包含一个对应的唯一值。用关系型数据库术语描述就是,键属性称为主键列。每个维度表中的主键值都与任何相关的事实表中的键值相关。在维度表中出现一次的每个键值都会在事实表中出现多次。例如Mountain-100的Product ID 347只在一个维度表数据行中出现,但它会出现在多个事实表数据行中。这称为一对多关系。在事实表中,键值列(它是一对多关系的“多”的一方)称为外键列。关系型数据库使用匹配的主键列(在维度表中)和外键列(在事实表中)值来联接维度表到事实表。
把维度信息移动到一个单独的表中,除了使得事实表更小外,还有额外的优点——可以为每个维度成员添加额外的信息。例如,维度表可能为每个产品添加种类(Category)信息,如下所示。
PROD_ID | Product_Name | Category |
---|---|---|
347 | Mountain-100 | Bikes |
339 | Road-650 | Bikes |
447 | Cable Lock | Accessories |
现在种类是产品的另一个属性。如果知道Product ID,不但可以推断出Product Name,而且可以推断出Category。键属性的名称可能是唯一的——因为每个键只有一个名称,但其他属性不需要是唯一的,例如Category属性可能会出现好几次。这样一来,便可以创建按照产品和类别对事实表信息进行分组的报表。
维度表前缀为Dim。
归纳:
维度表可以看作是用户来分析数据的窗口,纬度表中包含事实数据表中事实记录的特性,有些特性提供描述性信息,有些特性指定如何汇总事实数据表数据,以便为分析者提供有用的信息,维度表包含帮助汇总数据的特性的层次结构。例如,包含产品信息的维度表通常包含将产品分为食品、饮料、非消费品等若干类的层次结构,这些产品中的每一类进一步多次细分,直到各产品达到最低级别。
在维度表中,每个表都包含独立于其他维度表的事实 特性,例如,客户维度表包含有关客户的数据。维度表中的列字段可以将信息分为不同层次的结构级。
结论:
1、事实表就是你要关注的内容;
2、维度表就是你观察该事务的角度,是从哪个角度去观察这个内容的。
例如,某地区商品的销量,是从地区这个角度观察商品销量的。事实表就是销量表,维度表就是地区表。
(1)退化维度(DegenerateDimension)\
在维度类型中,有一种重要的维度称作为退化维度,亦维度退化一说。这种维度指的是直接把一些简单的维度放在事实表中。退化维度是维度建模领域中的一个非常重要的概念,它对理解维度建模有着非常重要的作用,退化维度一般在分析中可以用来做分组使用。
(2)缓慢变化维(Slowly Changing Dimensions)
维度的属性并不是始终不变的,它会随着时间的流逝发生缓慢的变化,这种随时间发生变化的维度我们一般称之为缓慢变化维(SCD)。
SCD常用的三种处理方式:\
① TYPE1 直接覆盖原值\
② TYPE2 增加维度行\
在为维度成员增加新行时,需为其分配新的主代理键。 并且,至少需要在维度行再增加三列: 有效日期、截止日期、行标识。 这个地方可联想拉链表设计。\
③ TYPE3 增加属性列
④ 混合方式
可根据实际业务场景,混合或选择使用以上三种方式,以快速方便而又准确的分析历史变化情况。\
粒度
用于确定某一事实表中的行表示什么,是业务最小活动单元或不同维度组合,即业务细节程度。\
维度建模流程
维度建模步骤:选择业务过程->声明粒度->确定维度->确定事实。旨在重点解决数据粒度、维度设计和事实表设计问题。
声明粒度,为业务最小活动单元或不同维度组合。以共同粒度从多个组织业务过程合并度量的事实表称为合并事实表,需要注意的是,来自多个业务过程的事实合并到合并事实表时,它们必须具有同样等级的粒度。
02 建模方法
数据仓库建模方法论可分为:维度建模、范式建模、Data Vault模型、Anchor模型。
2.1 维度模型\
企业中最流行、也是最经典的数仓建模经典,数据仓库大师Ralph Kimball的经典著作《数据仓库工具箱 维度建模权威指南 第三版》一本书进行了论述。从事数据仓库/ETL/BI的同学,强烈建议买一本至少读一遍。
按数据组织类型划分可分为星型模型、雪花模型、星座模型。
(1)星型模型\
星型模型主要是维表和事实表,以事实表为中心,所有维度直接关联在事实表上,呈星型分布。
图来源于Kimball《The Data Warehouse Toolkits -3rd Edition》
(2)雪花模型\
雪花模型,在星型模型的基础上,维度表上又关联了其他维度表。这种模型维护成本高,性能方面也较差,所以一般不建议使用。尤其是基于hadoop体系构建数仓,减少join就是减少shuffle,性能差距会很大。
(3)星座模型\
星座模型,是对星型模型的扩展延伸,多张事实表共享维度表。数仓模型建设后期,大部分维度建模都是星座模型。
2.2 范式模型\
即 实体关系(ER)模型,数据仓库之父Immon提出的,从全企业的高度设计一个3NF模型,用实体加关系描述的数据模型描述企业业务架构,在范式理论上符合3NF。此建模方法,对建模人员的能力要求非常高。
2.3 Data Vault模型
DataVault由Hub(关键核心业务实体)、Link(关系)、Satellite(实体属性) 三部分组成 ,是Dan Linstedt发起创建的一种模型方法论,它是在ER关系模型上的衍生,同时设计的出发点也是为了实现数据的整合,并非为数据决策分析直接使用。
2.4 Anchor模型
高度可扩展的模型,所有的扩展只是添加而不是修改,因此它将模型规范到6NF,基本变成了K-V结构模型。企业很少使用,本文不多做介绍。
03 建模工具\
建模工具,一般企业以Erwin、powerdesigner、visio,甚至Excel等为主。也有些企业自行研发工具,或使用阿里等成熟套装组件产品。
3.1 PowerDesigner
是Sybase的企业建模和设计解决方案,是能进行数据库设计的强大的软件,是一款开发人员常用的数据库建模工具。使用它可以分别从概念数据模型(Conceptual Data Model)和物理数据模型(Physical Data Model)两个层次对数据库进行设计。
3.2 ERWin
全称是ERwin Data Modeler,是CA公司的数据建模工具。ERwin提供数据库结构,管理界面的容易简单,图形显示对视觉复杂。
另附一张 www.erwinchina.com 中文官网首页截图,这几句话很霸气有木有~~
3.3 Visio
Visio 是Office 软件系列中的负责绘制流程图和示意图的软件,是一款便于IT和商务人员就复杂信息、系统和流程进行可视化处理、分析和交流的软件。同时它也可以用来数据库建模。\
打开visio 2010,文件—>新建—>数据库—>数据库模型图。建立数据库模型图之后,菜单栏多出一个菜单项"数据库"。
3.4 Excel Mapping
通过我们最熟悉的Excel进行维护数据模型、血缘关系和元数据管理,话不多说,直接上图:
04. 结语\
对于数仓而言,模型就是命脉,好与坏直接决定企业数据存储、处理和应用。
对于维度建模,真正理解了粒度和一致性维度,也就理解了维度建模的魂。\
对于建模工具,没有最好只有更好,适合业务的就是最好的。
希望大家可以关注下公众号,会定期分享自己从业经历、技术积累及踩坑经验,支持一下,鞠躬感谢~
关注公众号回复:“资料全集”