文章目录

一.建模理论
- 1.1 ER实体模型
- 1.2 维度建模
- - 1.2.1 事实表
  - 1.2.2 维度表
- 1.3 Data Vault模型
- 1.4 Anchor
二. 四种基本建模方法对比
三. 维度建模技术基本概念
- 3.1 收集业务需求与数据实现
- 3.2 协作维度建模研讨
- 3.3 4 步骤维度设计过程
- 3.4 业务过程
- 3.5 粒度
- 3.6 描述环境的维度
- 3.7 用于度量的事实
- 3.8 星型模式与 OLAP 多维数据库
- 3.9 方便地扩展到维度模型
参考:

一.建模理论

1.1 ER实体模型

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

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

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

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

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

应用场景：

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

1.2 维度建模

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

1.2.1 事实表

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

1.2.2 维度表

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

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

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

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

雪花、星型模型

雪花、星型模型的选择：

对于传统数据仓库:
对于变化较少的维度，例如地区维度，省、市、区，可以采取星型模型，提高检索的效率。
对于变化频繁的维度，例如公司部门的组织架构，为了程序的可维护性，可以采取雪花模型。当组织架构发生变化，我们只需要维护维度表即可。
对于大数据系统:
大数据和传统关系型数据库的计算框架不一样，例如对比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模型和维度模型。

ER模型
ER模型俗称范式模型，需要全方位的梳理业务流和数据流，项目周期长，对建模人员要求也高，传统的大中型公司稳定的系统可以采用ER模型。
维度模型
维度建模是面向分析场景而生，针对分析场景构建数仓模型，重点关注快速、灵活的解决分析需求，同时能够提供大规模数据的快速响应性能。针对性强，主要应用于数据仓库构建和OLAP引擎底层数据模型。

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

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

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

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

3.2 协作维度建模研讨

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

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

3.3 4 步骤维度设计过程

维度模型设计期间主要涉及 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 查询或应用，就可以方便地适应，且查询结果不会有任何改变。

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

参考:

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

数据仓库系列2-数据仓库建模介绍相关推荐

数据仓库系列之维度建模
上一篇文章我已经简单介绍了数据分析中为啥要建立数据仓库,从本周开始我们开始一起学习数据仓库.学习数据仓库,你一定会了解到两个人:数据仓库之父比尔·恩门(Bill Inmon)和数据仓库权威专家Ralp ...
数据仓库系列——3.维度建模概述及案例
概述数据仓库包含的内容很多,它可以包括架构.建模和方法论.对应到具体工作中的话,它可以包含下面的这些内容: 以Hadoop.Spark.Hive等组建为中心的数据架构体系. 各种数据建模方法,如维度 ...
数据仓库系列篇之管理规范
@Author : Spinach | GHB @Link : http://blog.csdn.net/bocai8058 文章目录前言 Hive存储规划数据模型设计命名规范表命名字段命名 ...
数据仓库系列1-高质量数据建模
一.前言: 虽然做数据工作5年了,从传统行业到互联网行业,感觉啥都懂点,但是没有一样可以拿出手的,干活时没问题,但是讲东西却存在问题,最近想系统的学习一下数据仓库只是,顺便记录下,也算是对学习的一个总 ...
数据仓库系列（四）数仓架构以及多维数据模型的设计
文章目录一.前言二.数据仓库的定义三.数据仓库的特点四.数据仓库的作用五.数据仓库的架构六.数据仓库的要求七 .数据仓库分层八.数据仓库四个层次的划分 8.1 ODS层 8.2 PDW ...
数据仓库系列：初识数仓
数据仓库系列:初识数仓前言: 本节是数据仓库系列文章的第一篇,本系列的目的在于快速的构建一套最小化可运行的基础数据体系,过程中也会涉及一些数仓的理论知识,但更偏重的是数仓的实现和背后的思考逻辑.所以 ...
数据仓库(3)数仓建模之星型模型与维度建模
维度建模是一种将数据结构化的逻辑设计方法,也是一种广泛应用的数仓建模方式,它将客观世界划分为度量和上下文.度量是常常是以数值形式出现,事实周围有上下文包围着,这种上下文被直观地分成独立的逻辑块,称 ...
数据仓库常用几种建模方法
本文主要的主线就是回答下面三个问题: 什么是数据模型为什么需要数据模型如何建设数据模型最后,我们在本文的结尾给大家介绍了一个具体的数据仓库建模的样例,帮助大家来了解整个数据建模的过程. 一. 什 ...
大数据系列之数据仓库Hive命令使用及JDBC连接
Hive系列博文,持续更新~~~ 大数据系列之数据仓库Hive原理大数据系列之数据仓库Hive安装大数据系列之数据仓库Hive中分区Partition如何使用大数据系列之数据仓库Hive命令使用 ...
数据仓库的几种建模方法
背景接着上个文章数据仓库简述,想写一篇数据仓库常用模型的文章,但是自己对数据仓库模型的理解程度和建设架构并没有下面这个技术专家理解的深刻,并且自己去组织语言,可能会有不准确的地方,怕影响大家对数据仓 ...

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