数据仓库-维度建模

目录

1. 数据仓库定义

2. 数据仓库和数据库

3. 数仓分层

4. 维度建模

4.1 维度建模 VS 第三范式

4.2 维度建模设计过程

5. 粒度概念

6. 事实概念

6.1 事实表技术

7. 维度概念

7.1 维度表技术

8. 数据关系模型

8.1 星型模型

8.2 星座模型

8.3 雪花模型

9. 写在最后

---

1. 数据仓库定义

        数据仓库，英文名称为Data Warehouse，可简写为DW或DWH。数据仓库，是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它是单个数据存储，出于分析性报告和决策支持目的而创建。 为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。

2. 数据仓库和数据库

数据库主要用于事务处理，数据仓库主要用于数据分析。联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）

3. 数仓分层

数仓分层是数仓建设中的重要环节，详细介绍见数仓分层架构。

4. 维度建模

数据仓库实现了海量数据的存储，但是如何对这些数据进行有效的分析挖掘，就需要对数据进行建模，使数据具有结构。数据建模有很多种方式，维度建模是业界应用较多，被大多数人接受的一种技术。

维度建模的思想源于我们的现实世界，物理世界中天然的具有「事实」和「维度」的概念。事实一般表示事物的度量，维度是描述事实的环境，属性信息。用于描述与“Who,When,Where,What,Why,How”有关的信息。

例：订单数据

在订单数据中，如果要使用维度建模技术来构建数据模型，则订单为事实，描述订单的用户，时间，地点，商品，商家，渠道等都是订单事实的维度。

4.1 维度建模 VS 第三范式

维度建模：以商业用户可理解的方式发布数据；提供高效的查询性能。以需求驱动，自底向上建设 。

第三范式：数据规范、分散，数据统计需要更多的关联。以数据驱动，自顶向下建设。        

4.2 维度建模设计过程

• 选择业务过程：组织完成的操作型活动，比如：搜索结果、意向浏览、生成订单

• 声明粒度：粒度用于确定某一事实表中的行代表什么。不同的事实表粒度，要建立不同的物理表，在同一事实表中不要混用多种不同的粒度

• 确认维度：业务过程所涉及的“谁、什么、何处、何时、为什么、如何”等背景。维度表包含应用所需的用于过滤及分类事实的描述性属性

• 确认事实：业务过程事件的度量，基本上都是以数量值表示。所有事实只允许与声明的粒度保持一致。

5. 粒度概念

数据粒度，是指数据仓库中数据的细化和综合程度。根据数据粒度细化标准：细化程度越高，粒度越小；细化程度越低，粒度越大。一般来说，数仓底层的粒度较细，包含的信息较为具体，上层数据的粒度一般较粗，信息较为抽象。举个🌰：

明细层--用户交易明细表：粒度为 「用户*订单」

user_id	name	age	order_pk(订单编号)
001	zhangsan	18	aaa
001	zhangsan	18	bbb
002	lisi	19	ccc

 主题层--用户主题表：粒度为 「用户」

user_id	name	age	order_cnt（订单数量）
001	zhangsan	18	2
002	lisi	19	1

应用层--用户总下单量（指标）：粒度为 「所有用户」

user_cnt	order_total_cnt
2	3

上述例子可以看出，通常情况下底层数据粒度较低，包含信息较为详细（低粒度的数据可以包含粗粒度的信息，反之则不行），上层数据的粒度越来越粗，包含的信息越来越抽象，越来越有针对性，应用层的数据是直接面向客户的，具有业务含义。

6. 事实概念

发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。事实表的一行数据对应一个度量事件。事实表总是包含外键，用于关联与之相关的维度，也包含一些退化维度（如时间等）。

6.1 事实表技术

• 事实类型：可加、半可加、不可加

• 一致性事实：某些度量出现在不同的事实表中，应保证针对事实的技术定义是相同的。如果不同的事实表定义是一致的，则这些一致性的事实应该具有相同的命名

• 无事实的事实表：某些事件仅仅记录一系列某一时刻发生的多维实体。例如：在某一天中用户发生的搜索事件

• 聚集事实表：对原子粒度事实表数据进行简单的数字化上卷操作，目的就是为了提高查询性能。

• 合并事实表：将来自多个过程的，以相同粒度表示的事实合并为一个单一的合并事实表，这样做能够带来方便 。

7. 维度概念

每个维度表都包含单一的主键字段。维度表的主键可以作为与之关联的事实表的外键（例如：销售事实表中的地址外键字段也就是地址维度表中的主键字段）。维度表通常是一个宽表（字段多），是扁平型的非规范表，包含大量低粒度信息。

7.1 维度表技术

• 退化维度：维度除了主键没有其他内容。例如：订单事实表中的订单编号。

• 杂项维度：商业过程通常会产生一系列混杂的、低粒度的标识和指示器。与其为每个标识或属性定义不同的维度，不如建立单独的将不同维度合并到一起的杂项维度。比如：

  杂项id	性别	班级	年纪
  1	男	A	1
  2	男	B	2
  3	女	C	3

• 支架维度：维度可包含对其他维度的引用。支架维度可以使用，但是尽量少用。多数情况下，维度之间的关联应该由事实表来实现。在事实表中通过两个维度的不同外键相关联

• 多值维度与桥接表：某些情况下，维度存在合理的多值。在此情况下，多值维度必须通过一组维度建通过桥接表使一组中的单个维度与事实表一行关联。

• 一致性维度：当不同的维度表的属性具有相同列名和领域内容时，称维度表具有一致性。利用一致性维度属性与每个事实表关联，可将来自不同事实表的信息合并到同一报表中。比如：在意向表，订单表，支付表中，商户就是一个一致性维度。通过「商户」这个一致性维度，可以讲意向，订单，支付等事实合并起来。

8. 数据关系模型

在多维分析的商业智能解决方案中，根据事实表和维度表的关系，又可将常见的模型分为星型模型和雪花型模型。在设计逻辑型数据的模型的时候，就应考虑数据是按照星型模型还是雪花型模型进行组织。

8.1 星型模型

当所有维表都直接连接到“ 事实表”上时，整个图解就像星星一样，故将该模型称为星型模型

  

PS:PK就是主键的意思。

8.2 星座模型

由多个事实表组合，维表是公共的，可以被多个事实表共享。星座模型是数据仓库最常使用的模型。

如下图所示，订单事实表和支付事实表都连接到地址维度，这种关系模型就称为星座模型。地址维度也叫做订单事实和支付事实的共享维度，一致性维度。

8.3 雪花模型

当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 " 层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。

如下图，红色框内的维度表没有直接连接到事实表中，而是通过地址维度表连接事实表，这种关系模型就叫做雪花模型。

9. 写在最后

在数据仓库中，如何划分层次，主题。如何选择关系模型，都是要根据实际业务情况而定，脱离业务谈建模就是纸上谈兵。