程序员笔记|3个问题带你入门数据建模

数据几乎总是用于两种目的：操作型记录的保存和分析型决策的制定。简单来说，操作型系统保存数据，分型型系统使用数据。

前者一般仅反映数据的最新状态，按单条记录事务性来处理;其优化的核心是更快地处理事务。

后者往往是反映数据一段时间的状态变化，按大批量方式处理数据;其核心是高性能、多维度处理数据。

通常我们将操作型系统简称为OLTP(On-Line Transaction Processing)— 联机事务处理，将分析型系统简称为OLAP(On-Line Analytical Processing)— 联机分析处理。

针对这两种不同的数据用途，如何组织数据，更好地满足数据使用需求。这里就涉及到数据建模问题。即设计一种数据组织方式(模型)，来满足不同场景。在OLTP场景中，常用的是使用实体关系模型(ER)来存储，从而在事务处理中解决数据的冗余和一致性问题。在OLAP场景中，有多种建模方式有：ER模型、星型模型和多维模型。下面分别说明下：

1. ER模型

OLAP中的ER模型，与OLTP中的有所区别。其本质差异是站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系的抽象。

2. 星型模型

星型模型，是维度模型在关系型数据库上的一种实现。该模型表示每个业务过程包含事实表，事实表存储事件的数值化度量，围绕事实表的多个维度表，维度表包含事件发生时实际存在的文本环境。这种类似于星状的结构通常称为"星型连接"。其重点关注用户如何更快速地完成需求分析，同时具有较好的大规模复杂查询的响应性能。在星型模型基础上，在复杂场景下还可以进一步衍生出雪花模型。

3. 多维模型

多维模型，是维度模型的另一种实现。当数据被加载到OLAP多维数据库时，对这些数据的存储的索引，采用了为维度数据涉及的格式和技术。性能聚集或预计算汇总表通常由多维数据库引擎建立并管理。由于采用预计算、索引策略和其他优化方法，多维数据库可实现高性能查询。

在这三种方式中，星型模型使用较多，下面也着重对这种方式进行说明。

二、维度建模

1. 基本概念

在建模过程中，涉及到很多概念。下面通过一个场景来，来说明它们。例如：常见的电商下单环节，每个用户提交一笔订单(仅限一个物品)，就对应于一条订单记录。

【业务过程】：下订单

【粒度】：每笔订单(拆分为单个物品)

【维度】：地域、年龄、渠道等(可供分析的角度)

【事实/度量】：订单金额等(可用于分析的数据)

2. 建模步骤

(1) 收集业务需求与数据实现

在开始维度建模工作之前，需要理解业务需求，以及作为底层源数据的实际情况。通过与业务方沟通交流、查看现有报表等来发现需求，用于理解他们的基于关键性能指标、竞争性商业问题、决策制定过程、支持分析需求的目标。同时，数据实际情况可通过与数据库系统专家交流，了解访问数据可行性等。

(2) 选择业务过程

业务过程是组织完成的操作型活动。业务过程时间建立或获取性能度量，并转换为事实表中的事实。多数事实表关注某一业务过程的结果。过程的选择非常重要的，因为过程定义了特定的设计目标以及对粒度、维度、事实的定义。

(3) 声明粒度

声明粒度是维度设计的重要步骤。粒度用于确定某一事实表中的行表示什么。在选择维度或事实前必须声明粒度，因为每个候选维度或事实必须与定义的粒度保持一致。在从给定的业务过程获取数据时，原子粒度是最低级别的粒度。强烈建议从关注原子级别粒度数据开始设计，因为原子粒度数据能够承受无法预期的用户查询。

(4) 确认维度(描述环境)

维度提供围绕某一业务过程事件所涉及的"谁、什么、何处、何时、为什么、如何"等背景。维度表包含分析应用所需要的用于过滤及分类事实的描述性属性。牢牢掌握事实表的粒度，就能够将所有可能存在的维度区分开来。

(5) 确认事实(用于度量)

事实，涉及来自业务过程事件的度量，基本上都是以数据值表示。一个事实表行与按照事实表粒度描述的度量事件之间存在一对一关系，因此事实表对应一个物理可观察的事件。在事实表内，所有事实只允许与声明的粒度保持一致。

(6) 部署方式 - 星型模型或多维模型

选择一种维度模型的落地方式。既可以选择星型模型，部署在关系数据库上，通过事实表及通过主外键关联的维度表;也可以选择多维模型，落地于多维数据库中。

3. 建模规范

以维度建模为理论基础，定义一系列术语来描述建模对象。下图摘自于《阿里巴巴大数据实践之路》。

(1) 数据域