数据仓库建模方法简介

炬南山 2020-04-30

193

数据仓库建模方法简介

市场上存在着各类数据库类的产品，有传统的RDBMS，如Oracle，MySQL，SQL Server，也有Greenplum，mongodb，及hadoop生态圈中的hive,hbase等。随着数据库种类和使用范围的不断扩大，它被逐步划分为两大基本类型：

A. 操作型数据库

主要用于业务支撑。一个公司往往会使用并维护若干个数据库，这些数据库保存着公司的日常操作数据，比如商品购买、酒店预订、学生成绩录入等，票务交易系统是个典型的操作型系统。

B. 分析型数据库

这里主要分析中的数据仓库，它是用于实时或离线数据分析。这类数据库作为公司的单独数据存储，负责利用历史数据对公司各主题域进行统计分析。

这两种类型的数据库模型有着非常不同的区别，操作型数据库往往采用的是范式建模，数据原子化，易于维护。但分析型数据库较多采用的是维度建模，数据冗余度较高，维护麻烦，但好处是便于二次计算，分析。下面我们将重点介绍分析型数据库（数据仓库模型）的详细内容。

维度建模的基本概念

维度建模(dimensional modeling)是专门用于分析型数据库、数据仓库、数据集市建模的方法。

它本身属于一种关系建模方法，但和操作型数据库中的关系建模方法相比增加了几个概念：

维度表（dimension）

表示对分析主题所属类型的描述。比如"昨天早上张三在京东花费200元购买了一个皮包"。那么以购买为主题进行分析，可从这段信息中提取三个维度：时间维度(昨天早上)，地点维度(京东), 商品维度(皮包)。通常来说维度表信息比较固定，且数据量小。

事实表（fact table）

表示对分析主题的度量。比如上面那个例子中，“某某在某个时间购买了多少的钱的某个东西” 这一连串的组合就是是事实信息。事实表包含了与各维度表相关联的外码，并通过JOIN方式与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表规模迅速增长。

接口表（interface table）

通常是指形成事实表中的过程表，数据含有大量的重复记录，无法直接进行分析，需进一步数据处理才可形成事实表。

在数据仓库中不需要严格遵守规范化设计原则，因为数据仓库少有更新，基本上大量的数据装载和查询。

模型组织结构分类

维度模型中通常包含三种模型：星型模型，雪花模型以及星座模型。

星型模型

星型模式(Star Schema)是最常用的维度建模方式，下图展示了使用星型模式进行维度建模的关系结构：

可以看出，星型模式的维度建模由一个事实表和一组维表组成，且具有以下特点:

a. 维表只和事实表关联，维表之间没有关联；

b. 每个维表的主码为单列，且该主码放置在事实表中，作为两边连接的外码；

c. 以事实表为核心，维表围绕核心呈星型分布；

d. 事实表与维度表之间并没有强制的外键约束

雪花模型

雪花模式(Snowflake Schema)是对星型模式的扩展，每个维表可继续向外连接多个子维表。下图为使用雪花模式进行维度建模的关系结构：

星型模式中的维表相对雪花模式来说要大，而且不满足规范化设计。雪花模型相当于将星型模式的大维表拆分成小维表，满足了规范化设计。然而这种模式在实际应用中比较少采用，因为这样做会导致开发难度增大，且连接效率降低。数据仓库允许少量的冗余从而提升开发效率及查询效率。

星座模型

星座模式(Fact Constellations Schema)也是星型模式的扩展。基于这种思想就有了星座模式：

前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。

案例演示

（向上滑动查看内容）

在进行维度建模前，首先要了解用户需求。假设经过多次的需求沟通确认得到以下ER图：

随后可利用建模工具将ER图直接映射到关系图

需求搜集完毕后，便可进行维度建模了。本例采用星型模型维度建模。但不论采取何种模式，维度建模的关键在于明确下面四个问题：

1. 哪些维度对主题分析有用

本例中根据产品(PRODUCT)、顾客(CUSTOMER)、商店(STORE)、日期(DATE)对销售额进行分析是非常有帮助的；

2. 如何使用现有数据生成维表

a. 维度PRODUCT可由关系PRODUCT，关系VENDOR，关系CATEGORY连接得到；

b. 维度CUSTOMER和关系CUSTOMER相同；

c. 维度STORE可由关系STROE和关系REGION连接得到；

d. 维度CALENDAR由关系SALESTRANSACTION中的TDate列分离得到；

3. 用什么指标来"度量"主题？

本例的主题是销售，而销量和销售额这两个指标最能直观反映销售情况；

4. 如何使用现有数据生成事实表？

销量和销售额信息可以由关系SALESTRANSACTION和关系SOLDVIA，关系PRODUCT连接得到；明确这四个问题后，便能完成维度建模：

这是个典型的星型模型结构，但仔细观察发现

1. 维表不满足规范化设计(不满足3NF)；

2. 事实表也不满足规范化设计(1NF都不满足)；

对于这两个问题，由于当前建模环境是数据仓库，较少或基本没有更新操作，所以不需要严格做规范化设计来消除冗余避免更新异常。

当然我们对维度表进行再细分，也可做出以雪花模型进行维度建模，如下所示：

但这样会加大查询人员负担：每次查询都涉及到太多表了。因此实际使用需要根据业务场景，避免遵从范式设计，导致查询性能下降。

假如该公司质量监管部门希望用分析销售主题同样的方法分析劣质产品，那么此时不需要重新维度建模，只需往模型里加入一个新的劣质产品事实表。之后新的数据仓库维度建模结果如下，这个就是一个星座模型结构了：

总结

星型模式/雪花模式/星座模式的关系如下图所示：

雪花模式是将星型模式的维表进一步划分，使各维表进一步规范化设计。而星座模式则是允许星型模式中出现多个事实表。在实际数据仓库建模中，星座模式才是最多出现的。

本期作者

本期作者|苏云金 从事电信运营商数据开发工作多年，擅长处理异构数据ETL，分析优化；精通OLAP和OLTP系统数据模型的构建和管控。

数据库

文章转载自炬南山，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。