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

8.4.1、ER 模型

数据仓库之父 Bill lnmon 提出的建模方法是从全企业的高度设计 3NF 模型，
用实体关系（ Entity Relationship, ER ）模型描述企业业务，
在范式理论上符合 3NF 。

数据仓库中的 3NF与OLTP 系统中的 3NF 的区别在于，
它是站在企业角度面向主题的抽象，
而不是针对某个具体 业务流程的实体对象关系的抽象。

其具有以下几个特点：
需要全面了解企业业务和数据实施周期非常长。
对建模人员的能力要求非常高。

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

其建模步骤分为三个阶段。

高层模型：

一个高度抽象的模型，
描述主要的主题以及主题间的关系，
用于描述企业的业务总体概况。

中层模型

在高层模型的基础上，细化主题的数据项。

物理模型（也叫底层模型）

在中层模型的基础上，考虑物理存储，
同时基于性能和平台特点进行物理属性的设计，
也可能做一 些表的合并、分区的设计等。

ER 模型在实践中最典型的代表是 Teradata 公司基于金融业务发布
FS-LDM (Financial Services Logical Data Model ），
它通过对金融业务的高度抽象和总结，
将金融业务划分为 10 主题 ，
并以设计面向金融仓库模型的核心为基础，
企业基于此模型做适当调整和扩展就能快速落地实施。

8.4.2 、维度模型

维度模型是数据仓库领域的 Ralph Kimball 大师所倡导的，
他的 The Data Warehouse olkit-The Complete Guide to Dimensional Modeling
数据仓库工程领域最流行的数据仓库建模的经典。

维度建模从分析决策的需求出发构建模型，为分析需求服务，
因此 它重点关注用户如何更快速地完成需求分析，
同时具有较好的大规模复 杂查询的响应性能。
其典型的代表是星形模型，以及在一些特殊场景下 使用的雪花模型。
其设计分为以下几个步骤。

1、选择需要进行分析决策的业务过程。

业务过程可以是单个业务事件，比如交易的支付、退款等；
也可以是某个事件的状态，比如当前的账户余额等；
还可以是一系列相关业务事件组成的业务流程，
具体需要看我们分析的是某些事件发生情况，还是当前状态， 或是事件流转效率。

2、选择粒度。

在事件分析中，我们要预判所有分析需要细分的程度， 从而决定选择的粒度。
粒度是维度的一个组合。

3、识别维表。

选择好粒度之后，就需要基于此粒度设计维表，
包括维度属性，用于分析时进行分组和筛选。

4、选择事实。

确定分析需要衡量的指标

8.4.3、Data Vault 模型

Data Vault Dan Linstedt 发起创建的一种模型，
它是 模型的生，其设计的出发点也是为了实现数据的整合，
但不能直接用于数据分析决策。
它强调建立一个可审计的基础数据层，
也就是强调数据的历史性、可追溯性和原子性，
而不要求对数据进行过度的一致性处理和整合，
同时它基于主题概念将企业数据进行结构化组织，
并引入了更进一步的范式处理来优化模型，
以应对游、系统变更的扩展性。
Data Vault 型由以下几部分组成。

• Hub ：

是企业的核心业务实体，
由 实体 key 、数据仓库序列代理键、装载时间、数据来源组成。

• Link ：

代表 Hub 之间的关系。
这里与模型最大的区别是将关系作为一个独立的单元抽象，
可以提升模型的扩展性。
它可以直接描述 1:1，1 :n和n:n 的关系，而不需要做任何变更。
它由 Hub的代理键、装载时间、数据来源组成。

• Satellite ：

是 Hub 的详细描述内容，
一个 Hub 可以有多个 Satellite 。
它由 Hub 的代理键、装载时间、来源类型、详细的 Hub 描述信息组成。

Data Vault 模型比 ER 模型更容易设计和产出，
它的 ETL 加工可实现配置化。
通过 Dan Linstedt 的比喻更能理解 Data Vault 的核心思想：
Hub 可以想象成人的骨架，
那么 Link 就是连接骨架的韧带，
而 Sate II ite就是骨架上面的血肉。

看如下实例（来自 Data ult Modeling Guide, 作者 Hans Hultgren ），
如图 8.1 所示。

8.4.4 Anchor 模型

Anchor Data Vault 模型做了进一步规范化处理，
Lars. Ri:innback 的初衷是设计 个高度可扩展的模型，
其核心思想是所有的扩展只是添加而不是修改，
因此将模型规范到 6NF ，
基本变成了 k-v 结构化模型。
我们看 Anchor 模型的组成。

• Anchors ：

类似于 Data Vault Hub ，代表业务实体，且只有主键。

• Attributes ：

功能类似于 Data Vault Satellite ，但是它更加规范化，
将其全部 k-v 结构化， 个表只有 Anchors 的属性描述。

• Ties ：

就是 Anchors 之间的关系，
单独用表来描述，
类似于 Data Vault Link ，
可以提升整体模型关系的扩展能力。

• Knots ：

代表那些可能会在 Anchors 中公用的属性的提炼，
比如性别、状态等这种枚举类型且被公用的属性。
在上述四个基本对象的基础上，
又可以细划分为历史的和非历史的，
其中历史的会以时间戳加多条记录的方式记录数据的变迁历史。

Anchor 模型的创建者以此方式来获取极大的可扩展性，
但是也会增加非常多的查询 join 操作。
创建者的观点是，
数据仓库中的分析查询只是基于一小部分字段进行的，
类似于列存储结构，
可以大大减少数据扫描，
从而对查询性能影响较小。
一些有数据表裁剪（ Table Elimination) 特性的数据库如 MariaDB 的出现，
还会大量减少 join 操作。
但是实际情况是不是如此，还有待商榷。

下面是一个 Anchor 模型图。
（来自 Anchor _Modeling-Agile _ormation _Modeling in Evolving Data _Environments ，作 Lars. Ronnback ），如 8.2 所示。