一、何为建模？

数据几乎总是用于两种目的：操作型记录的保存和分析型决策的制定。简单来说，操作型系统保存数据，分型型系统使用数据。前者一般仅反映数据的最新状态，按单条记录事务性来处理；其优化的核心是更快地处理事务。后者往往是反映数据一段时间的状态变化，按大批量方式处理数据；其核心是高性能、多维度处理数据。通常我们将操作型系统简称为OLTP（On-Line Transaction Processing）— 联机事务处理，将分析型系统简称为OLAP（On-Line Analytical Processing）— 联机分析处理。

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

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

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

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

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

二、维度建模

2.1 基本概念

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

【业务过程】：下订单

【粒度】：每笔订单（拆分为单个物品）

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

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

2.2 建模步骤

• 收集业务需求与数据实现

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

• 选择业务过程

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

• 声明粒度

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

• 确认维度（描述环境）

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

• 确认事实（用于度量）

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

• 部署方式 - 星型模型或多维模型

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

2.3 建模规范

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

• 数据域

指面向业务分析，将业务过程或者维度进行抽象的集合。在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中和扩展新的数据域。

• 业务过程

指企业的业务活动事件，如下单、支付、退款都是业务过程。请注意，业务过程是一个不可拆分的行为事件，通俗地讲，业务过程就是企业活动中的事件。

• 时间周期

用来明确数据统计的时间范围或者时间点，如最近30天、自然周、截至当日等。

• 修饰类型

是对修饰词的一种抽象划分，是从属于某个业务域的。

• 修饰词

指除了统计维度以外指标的业务场景限定抽象。修饰词隶属于一种修饰类型。

• 度量/原子指标

原子指标和度量含义相同，基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名词，如支付金额。

• 维度

维度是度量的环境，用来反映业务的一类属性，这类属性的集合构成一个维度，也可以称为实体对象。维度属于一个数据域，如地理维度（其中包挤国家、地区、省以及城市等级别的内容）、时间维度（其中包括年、季、月、周、日等级别的内容）。

• 维度属性

维度属性隶属于一个维度，如地理维度里面的国家名称、国家ID、省份名称等都属于维度属性。

• 派生指标

派生指标＝一个原子指标＋多个修饰词（可选）＋时间周期。可以理解为对原子指标业务统计范围的圈定。

三、设计要点

3.1 维度表设计

维度是维度建模的基础和灵魂。在维度建模中，将度量称为'事实'，将环境描述为'维度'，维度是用于分析事实所需要的多样环境。维度所包含的表示维度的列，称为维度属性。维度属性是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键。维度的作用一般是查询约束、分类汇总以及排序等。维度的设计过程就是确定维度属性的过程，如何生成维度属性，以及所生成的维度属性的优劣，决定了维度使用的方便性，成为数据仓库易用性的关键。正如Kimball所说的，数据仓库的能力直接与维度属性的质量和深度成正比。

在整个设计过程中，应当遵循下面一些原则：

• 维度属性尽量丰富，为数据使用打下基础。

• 给出详实的、富有意义的文字描述。

• 沉淀通用维度属性，为建立一致性维度做好铺垫。

• 严格区分事实与维度，通过使用场景进行区分。

3.2 事实表设计

事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和与业务过程有关的度量。在设计过程中，可以选择不同类型的事实表，它们有各自的适用场景。

在整个设计过程中，应当遵循下面一些原则：

• 选择一种适合的事实表类型。

• 事实尽可能完整，包含整个业务过程的全部事实。

• 确保每一个事实度量都是一致性，反复计算都会得到相同的结果。尽量记录一些“原子”事实，而不是加工后的结果。

• 可适当做些”维度退化属性”，提高事实表的查询性能。

• 为提高聚合性能，可适度做些上卷汇聚事实表。