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

前言

本文隶属于专栏《大数据理论体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！

本专栏目录结构和参考文献请见大数据理论体系

---

正文

ER 模型

数据仓库之父 Bill Inmon 提出的建模方法是从全企业的高度设计一个 3NF 模型，用实体关系 ( EntityRelationship ， ER ) 模型描述企业业务，在范式理论上符合 3NF 。

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

OLTP 系统中的 3NF（三范式）是指：

• 第一范式（确保每列保持原子性）；
• 第二范式（确保表中的每列都和主键相关）；
• 第三范式（确保每列都和主键列直接相关,而不是间接相关）。

其具有以下几个特点：

• 需要全面了解企业业务和数据。
• 实施周期非常长。
• 对建模人员的能力要求非常高。

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

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

• 高层模型：一个高度抽象的模型，描述主要的主题以及主题间的关系，用于描述企业的业务总体概况。
• 中层模型：在高层模型的基础上，细化主题的数据项。
• 物理模型（也叫底层模型）：在中层模型的基础上，考虑物理存储，同时基于性能和平台特点进行物理属性的设计，也可能做一些表的合并、分区的设计等。

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

---

维度模型

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

维度建模从分析决策的需求出发构建模型，为分析需求服务，因此它重点关注用户如何更快速地完成需求分析，同时具有较好的大规模复杂查询的响应性能。

其典型的代表是星形模型，以及在一些特殊场景下使用的雪花模型。

关于星形模型和雪花模型请参考我的这篇博客——数据仓库是如何建模的？

其设计分为以下几个步骤：

• 选择需要进行分析决策的业务过程。 业务过程可以是单个业务事件，比如交易的支付、退款等；也可以是某个事件的状态，比如当前的账户余额等；还可以是一系列相关业务事件组成的业务流程，具体需要看我们分析的是某些事件发生情况，还是当前状态，或是事件流转效率。
• 选择粒度。在事件分析中，我们要预判所有分析需要细分的程度，从而决定选择的粒度。 粒度是维度的一个组合。
• 识别维表。选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。
• 选择事实。确定分析需要衡量的指标。

---

Data Vault 模型

Data Vault 是 Dan Linstedt 发起创建的一种模型，它是 ER 模型的衍生，其设计的出发点也是为了实现数据的整合，但不能直接用于数据分析决策。

它强调建立一个可审计的基础数据层，也就是强调数据的历史性、可追溯性和原子性，而不要求对数据进行过度的一致性处理和整合；同时它基于主题概念将企业数据进行结构化组织，并引入了更进一步的范式处理来优化模型，以应对源系统变更的扩展性。

DataVault 模型由以下几部分组成：

• Hub :是企业的核心业务实体，由实体 key 、数据仓库序列代理键、装载时间、数据来源组成。
• Link：代表 Hub 之间的关系。 这里与 ER 模型最大的区别是将关系作为一个独立的单元抽象，可以提升模型的扩展性。 它可以直接描述 1 : 1 、 1 : n 和 n : n 的关系，而不需要做任何变更。 它由 Hub 的代理键、装载时间、数据来源组成。
• Satellite：是 Hub 的详细描述内容，一个 Hub 可以有多个 Satellite 。它由 Hub 的代理键、装载时间、来源类型、详细的 Hub 描述信息组成。

DataVault 模型比 ER 模型更容易设计和产出，它的 ETL 加工可实现配置化。

通过 Dan Linstedt 的比喻更能理解 DataVault 的核心思想：

Hub 可以想象成人的骨架，那么 Link 就是连接骨架的韧带，而 Satellite 就是骨架上面的血肉。

---

Anchor 模型

Anchor 对 Data Vault 模型做了进一步规范化处理， Lars Ronnback 的初衷是设计一个高度可扩展的模型，其核心思想是所有的扩展只是添加而不是修改，因此将模型规范到 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 操作。

但是实际情况是不是如此，还有待商榷。