天天看点

维度设计

1.维度设计基础

维度是维度建模的基础和灵魂。

在维度建模中,将度量称为”事实“,将环境描述为”维度“,维度是用于分析事实所需要的多样环境。

维度所包含的表示维度的列,称为维度属性。

维度属性是查询约束条件、分组和报表标签生成的基本来源,是数据易用性的关键。

维度的作用一般是查询约束、分类汇总以及排序等。

获取维度或维度属性的方式:一是在报表中获取;二是可以在和业务人员的交谈中发现维度或维度属性。

维度使用主键标识其唯一性,主键也是确保与之相连的任何事实表之间存在引用完整性的基础。

主键的分类:代理键和自然键。它们都是用于标识某维度的具体值。

两者的区别:代理键是不具有业务含义的键,一般用于处理缓慢变化维;自然键是具有业务含义的键。

维度的设计过程就是确定维度属性的过程,如何生成维度属性,以及所生成的维度属性的优劣,决定了维度使用的方便性,成为数据仓库易用性的关键。

维度设计方法步骤:

第一步,选择维度或新建维度

第二步,确定主维表

第三步,确定相关维表

第四步,确定维度属性

第一阶段,是从主维表中选择维度属性或生成新的维度属性

第二阶段,是从相关维表中选择维度属性或生成新的维度属性

确定维度属性的几点提示:

1)尽可能生成丰富的维度属性

2)尽可能多地给出包括一些富有意义的文字性描述

3)区分数值型属性和事实

4)尽量沉淀出通用的维度属性

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

当属性层次被实例化为一系列维度,而不是单一的维度时,被称为雪花模式。大多数联机事务处理系统(OLTP)的底层数据结构在设计时采用此种规范化技术,通过规范化处理将重复属性移至其自身所属的表中,删除冗余数据。

将维度的属性层次合并到单个维度中的操作称为反规范化。

数据仓库总线架构的重要基石之一就是一致性维度。在针对不同数据域进行迭代构建或并行构建时,存在很多需求是对于不同数据域的业务过程或者同一数据域的不同业务过程合并在一起观察。

将不同数据域的商品的事实合并在一起进行数据探查,如计算转化率等,称为交叉探查。

维度一致性的几种表现形式:

共享维表;

一致性上卷,其中一个维度的维度属性是另一个维度的维度属性的子集,且两个维度的公共维度属性结构和内容相同;

交叉属性,两个维度具有部分相同的维度属性。

2.维度设计高级主题

1)维度整合

将面向应用的数据转换为面向主题的数据仓库数据,本身就是一种集成。

具体体现在如下几个方面:

命名规范的统一;字段类型的统一;公共代码及代码值的统一;业务含义相同的表的统一。

通常有如下几种集成方式:

采用主从表的设计方式,将两个表或多个表都有的字段放在主表中(主要基本信息),从属信息分别放在各自的从表中;直接合并,共有信息和个性信息都放在同一个表中;不合并。

表级别的整合,有两种表现形式:

第一种,垂直整合,即不同的来源表包含相同的数据集,只是存储的信息不同;

第二种,水平整合,即不同的来源表包含不同的数据集,不同子集之间无交叉,也可以存在部分交叉。

2)水平拆分

在设计过程中需要重点考虑以下三个原则:扩展性,效能,易用性。

根据数据模型设计思想,在对维度进行水平拆分时,主要考虑如下两个依据:

第一个依据是维度的不同分类的属性差异情况;

第二个依据是业务的关联程度。

3)垂直拆分

4)历史归档

归档策略方式:

第一种,同前台归档策略,在数据仓库中实现前台归档算法,定期对历史数据进行归档;

第二种,同前台归档策略,但采用数据库变更日志的方式;

第三种,数据仓库自定义归档策略。

注:如果技术条件允许,能够解析数据库binlog日志,建议使用归档策略中的第二种,规避前台归档算法。

3.维度变化

1)缓慢变化维

缓慢变化维的提出是因为在现实世界中,维度的属性并不是静态的,它会随着时间的流逝发生缓慢的变化。

三种处理缓慢变化维的方式:

第一种,重写维度值;

第二种,插入新的维度行;

第三种,添加维度列。

2)快照维表

处理缓慢变化维的方法是采用快照方式。

优点:简单有效,开发和维护成本低;使用方便,理解性好。

缺点:存储浪费大。

3)极限存储

在快照维表的基础上,又可以降低存储的方式就是极限存储。

采用缓慢变化维的第二种处理方式处理,但是这种存储方式对于下游使用方存在一定的理解障碍,因此会存在较高的解释成本。同时,随着时间的推移,分区数量会极度膨胀。故而引出极限存储。

透明化,分月做历史拉链表。

采用极限存储的处理方式,优点:极大地压缩了全量存储的成本,又可以达到对下游用户透明的效果,是一种比较理想的存储方式;缺点:产出效率很低,对于变化频率高的数据并不能达到节约成本的效果。

4)微型存储

微型维度的创建是通过将一部分不稳定的属性从主维度中移出,并将它们放置到拥有自己代理键的新表中来实现的。

未被采用的原因如下:微型维度的局限性;ETL逻辑复杂;破坏了维度的可浏览性。

继续阅读