数据仓库系列2-数据仓库建模介绍

一.建模理论

1.1 ER实体模型

在信息系统中，将事务抽象为“实体”（Entity）、“属性”（Property）、“关系”（Relationship）来表示数据关联和事物描述，这种对数据的抽象建模通常被称为ER实体关系模型。

实体：
通常为参与到过程中的主体，客观存在的，比如商品、仓库、货位、汽车，此实体非数据库表的实体表。

属性：
对主体的描述、修饰即为属性，比如商品的属性有商品名称、颜色、尺寸、重量、产地等。

关系：
现实的物理事件是依附于实体的，比如商品入库事件，依附实体商品、货位，就会有“库存”的属性产生；用户购买商品，依附实体用户、商品，就会有“购买数量”、“金额”的属性产品。

实体之间建立关系时，存在对照关系：
1:1：即1对1的关系
1:n：即1对多的关系
n:m：即多对多的关系

应用场景：

1. ER模型是数据库设计的理论基础，当前几乎所有的OLTP系统设计都采用ER模型建模的方式。
2. Bill Inom提出的数仓理论，推荐采用ER关系模型进行建模。
3. BI架构提出分层架构，数仓底层ods、dwd也多采用ER关系模型进行设计。

1.2 维度建模

维度建模源自数据集市，主要面向分析场景。Ralph Kimball推崇数据集市的集合为数据仓库，同时也提出了对数据集市的维度建模，将数据仓库中的表划分为事实表、维度表两种类型。

1.2.1 事实表

在ER模型中抽象出了有实体、关系、属性三种类别，在现实世界中，每一个操作型事件，基本都是发生在实体之间的，伴随着这种操作事件的发生，会产生可度量的值，而这个过程就产生了一个事实表，存储了每一个可度量的事件。

1.2.2 维度表

维度，顾名思义，看待事物的角度。比如从颜色、尺寸的角度来比较手机的外观，从cpu、内存等角度比较手机性能。

维度表一般为单一主键，在ER模型中，实体为客观存在的事务，会带有自己的描述性属性，属性一般为文本性、描述性的，这些描述被称为维度。

比如商品，单一主键：商品ID，属性包括产地、颜色、材质、尺寸、单价等，但并非属性一定是文本，比如单价、尺寸，均为数值型描述性的，日常主要的维度抽象包括：时间维度表、地理区域维度表等。

维度建模通常又分为星型模型和雪花模型。

雪花、星型模型

雪花、星型模型的选择：

1. 对于传统数据仓库:
   对于变化较少的维度，例如地区维度，省、市、区，可以采取星型模型，提高检索的效率。
   对于变化频繁的维度，例如公司部门的组织架构，为了程序的可维护性，可以采取雪花模型。当组织架构发生变化，我们只需要维护维度表即可。

2. 对于大数据系统:
   大数据和传统关系型数据库的计算框架不一样，例如对比mapreduce和oracle，在mapreduce里面，每多一个表的关联，就多一个job。mapreduce的每个任务进来，要申请资源，分配容器，各节点通信等。有可能YARN调度时长大于任务运行时间，例如调度需要5秒才能申请到资源，而表之间的join只需要2秒。hive优化里面，要尽可能减少job任务数，也就是减少表之间的关联，可以用适当的冗余来避免低效的查询方式，这是和oracle等其他关系型数据库不同的地方。
   所以针对大数据系统,尽可能的使用快照表及星型模型。

建模可以套用的模板:当事人模型

1.3 Data Vault模型

Data Vault是在ER模型的基础上衍生而来，模型设计的初衷是有效的组织基础数据层，使之易扩展，灵活应对业务变化，同时强调历史性、可追溯性和原子性，不要求对数据进行过度的一致性处理，并非针对分析场景所设计。

Data Vault模型是一种中心辐射式模型，其设计重点围绕着业务键的集成模式。这些业务键是存储在多个系统中的、针对各种信息的键，用于定位和唯一标识记录或数据。

Data Vault模型包含三种基本结构：
1）中心表-Hub：唯一业务键的列表，唯一标识企业实际业务，企业的业务主体集合。
2）链接表-Link：表示中心表之间的关系，通过链接表串联整个企业的业务关联关系。
3）卫星表-Satellite：历史的描述性数据，数据仓库中数据的真正载体。

Data Vault是对ER模型更进一步的规范化，由于对数据的拆解更偏向于基础数据组织，在处理分析类场景时相对复杂，适合数仓底层构建，目前实际应用场景较少。

1.4 Anchor

Anchor是对Data Vault模型做了更进一步的规范化处理，初衷是为了设计高度可扩展的模型，核心思想是所有的扩张只添加而不修改，于是设计出的模型基本变成了K-V结构的模型，模型范式达到了6NF。

由于过度规范化，使用中牵涉到太多的join操作，目前没有实际案例，仅作了解。

二. 四种基本建模方法对比

  Data Vault模型和Anchor模型对于审计类的系统比较适用，当前的数据仓库模型大多采用ER模型和维度模型。

1. ER模型
   ER模型俗称范式模型，需要全方位的梳理业务流和数据流，项目周期长，对建模人员要求也高，传统的大中型公司稳定的系统可以采用ER模型。

2. 维度模型
   维度建模是面向分析场景而生，针对分析场景构建数仓模型，重点关注快速、灵活的解决分析需求，同时能够提供大规模数据的快速响应性能。针对性强，主要应用于数据仓库构建和OLAP引擎底层数据模型。

三. 维度建模技术基本概念

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

  开始维度建模工作前 ，项目组需要理解业务需求 ，以及作为基础的源数据的实际情况 。 通过与业务代表交流来发现需求 ，用于理解他们的基于关键性能指标 、竞争性商业问题、 决策制定过程 、支持分析需求的目标。同时，数据实际情 况可以通过与源系统专家交流 ， 构建高层次数据分析访问数据可行性来揭示 。

  脱离了实际业务的建模就是扯淡，建模前一定要与熟悉企业的业务流及数据流。

3.2 协作维度建模研讨

  维度模型应该由主题专家与企业数据管理代表合作设计而成 。工作由数据建模者负责，但模型应该通过与 业务代表开展一系列高级别交互讨论获得 。这些讨论组也为 丰富业务需求提供了一种机会 。维度模型不应该由那些不懂业务以及业务需求的人来设计 ，协作是成功的关键 。

  最了解业务的是一线的业务人员及业务领导，在实际建模过程中，一定要多与业务人员沟通，协助才是成功的关键，闭门造车是行不通的。

3.3 4 步骤维度设计过程

维度模型设计期间主要涉及 4 个主要的决策 ：

1. 选择业务过程
2. 声明粒度
3. 确认维度
4. 确认事实

要回答上述问题，需要考虑业务需求以及协作建模阶段涉及的底层数据源 。按照业务过程 、粒度 、维度 事实声明的流程 ，设计组确定表名和列名 、示例领域值以及业务规则 。而业务数据管理代表必须参与详细的设计活动 ，以确保涵盖正确的业务 。

3.4 业务过程

  业务过程是组织完成的操作型活动 ，例如 ，获得订单 、处理保险索赔 、学生课程注册 或每个月每个账单的快照等 。业务过程事件建立或获取性能度量 ，并转换为事实表中的事 实。多数事实表关注某一业务过程的结果 。过程的选择是非常重要的 ，因为过程定义了特定的设计目标 以及对粒度 、维度、事实 的定义 。每个业务过程对应企业数据仓库总线矩阵 的一行。

  以贷款业务为场景，一次贷款申请行为可以理解为一个业务过程，申请时间、申请产品可以理解为维度，申请金额这个可以理解为度量。

3.5 粒度

  声明粒度是维度设计的重要步骤 。粒度用于确定某 一事实表中的行表示什么 。粒度声明是设计必须履行的合同 。在选择维度或事实前必须声明粒度 ，因为每个候选维度或事实 必须与定义的粒度保持 一致 。在所有维度设计中强制 实行一致性是保证 BI 应用性能和易用 性的关键 。在从给定的业务过程 获取数据时 ，原子粒度是最低级别的粒度 。我们强烈建议从关注原子级别粒度数据开始设计 ，因为原子粒度数据 能够承受无法预期的用户 查询 。上 卷汇总粒度对性能调整 来说非常重要 ，但这样的粒度往往要猜测业务公共问题 。针对不同 的事实表粒度 ，要建立不同的物理表 ，在同一事实表 中不要混用多种不同的粒度 。

  以贷款业务为场景，还款分多期，还款事实表的粒度可以是每一期还款为粒度，也可以是整个贷款单的还款为粒度。

3.6 描述环境的维度

  维度提供围绕某 一业务过程事件所涉及的 “ 谁 、什么 、何处、何时、为什么 、如何” 等背景 。维度表包含 Bl 应用所需要的用于过滤及分 类事实 的描述性属性 。牢牢掌握事实表 的粒度 ，就能够将所有可能存在 的维度区分开 。当与给定事实表行关联时 ，任何情况下都 应使维度保持单 一值。
  维度表有时被称为数据仓库的 “ 灵魂”，因为维度表包含确保 DW/BI 系统能够被用作 业务分析的入口和描述性标识 。主要的工作都放在数据 管理与维度表的开发方面，因为它 们是用户 BI 经验的驱动者 。

  以贷款业务为场景，贷款申请的申请时间、申请产品、客户的地域、客户的年龄等都属于维度，通过个维度的分析可以有助于我们找到目标客群，提升整个申请环节的效率，为企业创收。

3.7 用于度量的事实

  事实涉及来自业务过程事件的度 量 ，基本上都是以数 量值表示 。一个事实表行与按照 事实表粒度描述的度量事件之间存在一对一关系，因此事实表对应一个物理可观察的事件 。 在事实表 内，所有事实只允许与声明的粒度保持一致。例如 ，在零售事务中 ，销售产品 的 数量与其总额是良好的事实 ，然而商店经理的工资不允许存在于零售事务中 。

  以贷款业务为场景，申请金额就是事实表的度量值。

3.8 星型模式与 OLAP 多维数据库

  星型模式是部署在关系数据库管理系统 (RDBMS）之上的多维结构 。典型地，主要包含 事实表 ，以及通过主键／外键关系与之关联的维度表 。联机分析处理（OLAP）多维数据库是 实现在多维数据库之上的多维结构 ，它与关系型星型模式内容等价 ，或者说来源于关系型 星型模式 。OLAP 多维数据库包含维度属性和事实表 ，但它能够使用 比 SQL 语言具有更强 的分析能力的语言访 问，例如 ，XMLA 和 MDX 等 。OLAP 多维数据库包含在基本技术 的 列表中 ，因为 OLAP 多维数据库通常是部署维度 DW/BI 系统的最后步骤 ，或者作为 一种 基于多个原子关系型星型模式的聚集结构 。

3.9 方便地扩展到维度模型

  维度模型对数据关系发生变化具有灵活的适应性 。当发生以下所列举的变化时 ，不需 要改变现存的 BI 查询或应用 ，就可以方便地适应 ，且查询结果不会有任何改变 。

1. 当事实与存在的事实表粒度 一致时 ，可以创建新列 。
2. 通过建立新的外键列 ，可 以将维度关联到己经存在的事实表上 ，前提是维度列与 事实表粒度保持一致。
3. 可以在维度表上通过建立新列添加属性 。
4. 可以便事实表 的粒度更原子化 ，方法是在维度表上增 加属性 ，然后以更细的粒度 重置事实表 ，小心保存事实表及维度表 的列名。

参考:

1. https://blog.csdn.net/andyguan01_2/article/details/90242471