建模过程中 税务数据分析 数据建模剖析

八、数据模型篇—— 建模综述

• 8.1 OLTP和OLAP讲解
• 8.2 典型的数据仓库建模方法论

• 8.2.1 ER模型
• 8.2.2 维度模型 Kimball
• 8.2.3 Data Vault模型
• 8.2.4 Anchor模型

• 8.3 数据模型实践

数据建模就是数据组织和存储档案，强调从业务、数据存取和使用角度存储数据。

数据模型十分重要，好处有：

1. 性能。能快速查询想要的数据，减少数据的I/O吞吐
2. 成本。减少不必要的数据冗余，实现计算结果复用，降低计算和存储成本
3. 效率。改善用户使用数据体验，提高使用数据效率
4. 质量。改善数据统计口径的不一致

为什么要设计数据分层：需要一套行之有效的数据组织和管理方法来让我们的数据体系更有序

1. 复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层解决特定的问题。复杂的查询有多个子语句
2. 清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能够更方便地定位和理解
3. 数据血缘追踪：当数据出现问题之后，快速准确地定位到问题，并清楚它的危害范围
4. 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算，用空间换时间，通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据。
5. 统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径

8.1 OLTP和OLAP讲解

OLTP (online transaction processing) 联机事务处理过程

面向的主要数据操作是随机读写，

主要采用满足3NF的实体关系模型存储数据，从而在事务处理中解决数据的冗余和一致性，

侧重基本的、日常的事务处理，包括数据的增删改查。

OLAP (Online Analytical Processing) 联机分析处理

主要数据操作是批量读写

事务处理中的一致性并不是所关注的，主要关注数据的整合，以及在复杂大数据查询处理的性能

需要以大量历史数据为基础，再配合上时间点的差异，对多维度及汇整型的信息进行复杂的分析。

8.2 典型的数据仓库建模方法论

8.2.1 ER模型

用实体关系（Entity Relationship）模型描述企业业务，在范式理论上符合3NF，是站在企业角度面向主题的抽象。

用ER数据建模的出发点是整合数据，将各个系统中的数据以整个企业角度按照主题进行相似性组合和合并，并进行一致性处理，为数据分析决策服务，但不能直接用于决策分析。

3NF：

• 第一范式：原子性，字段不可分。是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即每一个属性都是原子的，不能再分，也可以理解为不能表中套表。
• 第二范式：唯一性，要求每个非主属性完全依赖于主键，不存在对主键的部分函数依赖。
• 第三范式：不存在属性对主键的传递依赖

建模阶段：

1. 高层模型。高度抽象的模型，描述主要的主题和主题间的关系，描述企业的业务总体概况
2. 中层模型。细化主题的数据项。
3. 物理模型（底层模型）。考虑物理存储，并基于性能和平台特点进行物理属性设计，可以能做表的合并、分区。

8.2.2 维度模型 Kimball

从决策分析的需求出发构建模型。关注如何快速地完成需求分析，同时具有较好的大规模复杂查询的响应性能。典型代表：星形模型、雪花模型

建模阶段：

1. 分析决策的业务过程（可以是单个业务时间比如支付、退款，也可以是一系列事务组成的业务流程）
2. 选择粒度，选择细分的程度。粒度是维度的一个组合
3. 识别维表。基于粒度设计维表，包括维度属性。
4. 选择事实。确定需要衡量的指标

星形模式

• 由一个事实表和一组维表构成，以事实表为核心，维表围绕核心呈星状分布
• 维表只和事实表关联，维表之间没有关联
• 每个维表的主键为单列，且该主键放在事实表中，作为两边连接的外码

雪花模式

• 每个维表可继续向外连接多个子维表
• 雪花模型相当于将星形模式的大维表拆分成小维表，满足规范化设计，在实际中较少

星座模式

• 多对多
• 维度空间内的事实表可能不止一个，一个维表可能被多个事实表用到
  ￮ 好处：能够共享维度 和 设置细节/聚集事实表
  ￮ 共享维度：公司希望用分析销售主题的方法分析劣质产品，不需要重新建模，只需要加入一个新的劣质产品事实表
  ￮ 细节事实表：每条记录表示单一事实，通常设置TID属性，查询灵活但速度慢
  ￮ 聚集事实表：每条记录聚合多条事实，无TID属性，速度快但查询功能受到一定限制

8.2.3 Data Vault模型

强调可审计的基础数据层，也就是强调数据的历史性、可追溯性和原子性，不过度追求一致性处理。

基于主题概念进行结构化组织

• Hub：骨架，核心业务实体。由实体key、数据仓库序列代理键、装载时间、数据来源组成。
• Link：韧带，代表Hub之间的关系，作为一个独立的单元抽象（和ER模型最大的区别），可以直接描述1:1，1:n的关系。由代理键、装载时间、数据来源组成
• Satellite：血肉，是Hub的详细描述内容。由Hub的代理键、装载时间、来源类型、详细描述组成

8.2.4 Anchor模型

对Data Vault规范化处理，一个高度可扩展的模型，所有的扩展只是增加不是修改，基本变成k-v结构化模型。

• Anchors：类似于Hub，代表业务实体，只有主键
• Attributes：类似于Satellite，全部k-v结构化，一个表只有一个Anchors的属性描述
• Ties：类似Link，单独用表表示，提升模型关系的扩展能力
• Knots：代表多个Anchors中公共的属性提炼，如性别、状态等枚举类型且被公用的属性
• 可以划分为历史和非历史的，以时间戳加多条记录的方式记录数据变迁

8.3 数据模型实践

• 第一阶段，完全应用驱动，满足报表需求，基于Oracle数据库特性的利用进行数据存储和加工，部分使用维度建模的缓慢变化维方式进行历史数据处理。两层模型：ODS + DSS（decision support system）
• 第二阶段，将ER模型+维度模型方式应用改变烟囱式的开发模式，四层模型：

• ODL（操作数据层），和源系统保持一致
• BDL（基础数据层），希望引入ER模型，加强数据整合，构建一致的基础数据模型
• IDL（接口数据层），基于维度模型方法，构建集市层
• ADL（应用数据层），完成应用的个性化和基于展现需求的数据组装

• 第三阶段，以Kimball的维度建模维核心理念，数据公共层着力解决数据存储和计算的共享问题