数仓(五)：数据建模--ER模型/维度建模，概念模型/逻辑模型/ 物理模型

 一、数仓建模的目标

访问性能：能够快速查询所需的数据，减少数据I/O。
数据成本：减少不必要的数据冗余，实现计算结果数据复用，降低大数据系统中的存储成本和计算成本。
使用效率：改善用户应用体验，提高使用数据的效率。
数据质量：改善数据统计口径的不一致性，减少数据计算错误的可能性，提供高质量的、一致的数据访问平台。

所以，大数据的数仓建模需要通过建模的方法更好的组织、存储数据，以便在性能、成本、效率和数据质量之间找到最佳平衡点。

二、关系模式范式

关系型数据库设计时，遵照一定的规范要求，目的在于降低数据的冗余性和数据的一致性，目前业界范式有：

第一范式（1NF）：

域都是原子性的，即数据库表的每一列都是不可分割的原子数据项。

例如下面这张表：

ID    商品    商家ID    用户ID
1    4件毛衣    B0001    U00001
“商品”字段就不是原子性的，可以分割成“4件”和“毛衣”。

第二范式（2NF）：

在1NF的基础上，实体的属性完全依赖于主关键字，不能存在仅依赖主关键字一部分的属性，也就是不存在局部依赖。

例如下面这张表：

学生ID    所属系    系主任    所修课程    分数
S001    物理系    张三    C001    90
S001    物理系    张三    C002    100
主键ID为“学生ID，所修课程”，但是字段“所属系”只依赖于“学生ID”，不符合2NF。

第三范式（3NF）：

在2NF的基础上，任何非主属性不依赖于其它非主属性，也就是不存在传递依赖。

例如下面这张表：

订单ID    商品ID    商品颜色    商家ID    用户ID
O00001    G0001    白色    B0001    U00001
主键为“订单ID”，但是字段“商品颜色”依赖于“商品ID”，不符合3NF。

三、四种建模方法

1、ER实体关系模型

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

1. 实体：通常为参与到过程中的主体，客观存在的，比如商品、仓库、货位、汽车，此实体非数据库表的实体表。
2. 属性：对主体的描述、修饰即为属性，比如商品的属性有商品名称、颜色、尺寸、重量、产地等。
3. 关系：现实的物理事件是依附于实体的，比如商品入库事件，依附实体商品、货位，就会有“库存”的属性产生；用户购买商品，依附实体用户、商品，就会有“购买数量”、“金额”的属性产品。

实体之间建立关系时，存在对照关系：

1:1：即1对1的关系
1:n：即1对多的关系
n:m：即多对多的关系

在日常建模中，“实体”用矩形表示，“关系”用菱形，“属性”用椭圆形。ER实体关系模型也称为E-R关系图。

关系模型严格遵循第三范式（3NF），数据冗余程度低，数据的一致性容易得到保证。由于数据分布于众多的表中，查询会相对复杂，在大数据的场景下，查询效率相对较低。

1.场景
学生选课系统，该系统主要用来管理学生和选修课程，其中包括课程选修、学生管理功能，现需要完成数据库逻辑模型设计。
2.实现步骤
①.抽象出主体 —— 学生，课程；
②.梳理主体之间的关系 —— 选修；（学生与选修课程是一个多对多的关系）
③.梳理主体的属性；
④.画出 E-R 关系图； 

应用场景：

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

2、维度建模

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

事实表：

在ER模型中抽象出了有实体、关系、属性三种类别，在现实世界中，每一个操作型事件，基本都是发生在实体之间的，伴随着这种操作事件的发生，会产生可度量的值，而这个过程就产生了一个事实表，存储了每一个可度量的事件。   事实表包含了与各维度表相关联的外键，并通过JOIN方式与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表规模迅速增长。

维度表：

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

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

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

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

星型模型： 

图中的订单表就是一个事实表，你可以理解他就是在现实中发生的一次操作型事件，我们每完成一个订单，就会在订单中增加一条记录。我们可以回过头再看一下事实表的特征，在维度表里没有存放实际的内容，他是一堆主键的集合，这些ID分别能对应到维度表中的一条记录。

首先，我们想一下，如果我们不这样设计的话，我们一般会怎么做？如果设计下面这张表。你信不信，我能列出来50个字段！

可以看出，星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：

                a. 维表只和事实表关联，维表之间没有关联；

                b. 每个维表的主码为单列，且该主码放置在事实表中，作为两边连接的外码；

                c. 以事实表为核心，维表围绕核心呈星形分布

星型模型由一个事实表和一组维表组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。强调的是对维度进行预处理，将多个维度集合到一个事实表，形成一个宽表。这也是我们在使用hive时，经常会看到一些大宽表的原因，大宽表一般都是事实表，包含了维度关联的主键和一些度量信息，而维度表则是事实表里面维度的具体信息，使用时候一般通过join来组合数据，相对来说对OLAP的分析比较方便。 

维度模型：

1. 数据冗余小（因为很多具体的信息都存在相应的维度表中了，比如用户信息就只有一份）
2. 结构清晰（表结构一目了然）
3. 便于做OLAP分析（数据分析用起来会很开心）
4. 增加使用成本，比如查询时要关联多张表
5. 数据不一致，比如用户发起购买行为的时候的数据，和我们维度表里面存放的数据不一致

再说我们这张大款表的优点：

1. 业务直观，在做业务的时候，这种表特别方便，直接能对到业务中。
2. 使用方便，写sql的时候很方便。

缺点：

1. 数据冗余巨大，真的很大，在几亿的用户规模下，他的订单行为会很恐怖
2. 粒度僵硬，什么都写死了，这张表的可复用性太低。

雪花模型： 

        雪花模式(Snowflake Schema)是对星形模式的扩展，每个维表可继续向外连接多个子维表。下图为使用雪花模式进行维度建模的关系结构：

举个例子：零售公司销售主题的维度建模

假定和某零售公司进行多次需求PK后，得到以下ER图：

 维度建模的关键在于明确下面四个问题：

1. 哪些维度对主题分析有用？

本例中，根据产品(PRODUCT)、顾客(CUSTOMER)、商店(STORE)、日期(DATE)对销售额进行分析是非常有帮助的；

2. 如何使用现有数据生成维表？

a. 维度PRODUCT可由关系PRODUCT，关系VENDOR，关系CATEGORY连接得到；

b. 维度CUSTOMER和关系CUSTOMER相同；

c. 维度STORE可由关系STROE和关系REGION连接得到；

d. 维度CALENDAR由关系SALESTRANSACTION中的TDate列分离得到；

3. 用什么指标来"度量"主题？

本例的主题是销售，而销量和销售额这两个指标最能直观反映销售情况；

4. 如何使用现有数据生成事实表？

销量和销售额信息可以由关系SALESTRANSACTION和关系SOLDVIA，关系PRODUCT连接得到；

明确这四个问题后，便能轻松完成维度建模：

 但这样的设计也存在一定问题，例如：维表不满足规范化设计(不满足3NF)；事实表也不满足规范化设计(1NF都不满足)； 维度建模中各维度的主码由***ID变成***Key；以雪花模型进行维度建模可解决前两个问题，如下所示：

 但这样会加大查询人员负担：每次查询都涉及到太多表了。因此在实际应用中，雪花模型仅是一种理论上的模型。总的来说，数据仓库建模是一个综合性技术，需要使用到ER建模、关系建模、维度建模等技术。由于业务的复杂性决定了由单一技术是无法达到理想状态的，因此一个优秀的数据仓库建模团队既要有坚实的数据仓库建模技术，还要有对现实业务清晰、透彻的理解。

雪花、星型模型对比：

星型模型和雪花模型的主要区别在于对维度表的拆分，

1. 对于雪花模型，维度表的设计更加规范，一般符合3NF；
2. 而星型模型，一般采用降维的操作，利用冗余来避免模型过于复杂，提高易用性和分析效率。

1. 冗余：雪花模型符合业务逻辑设计，采用3NF设计，有效降低数据冗余；星型模型的维度表设计不符合3NF，反规范化，维度表之间不会直接相关，牺牲部分存储空间。
2. 性能：雪花模型由于存在维度间的关联，采用3NF降低冗余，通常在使用过程中，需要连接更多的维度表，导致性能偏低；星型模型反三范式，采用降维的操作将维度整合，以存储空间为代价有效降低维度表连接数，性能较雪花模型高。
3. ETL：雪花模型符合业务ER模型设计原则，在ETL过程中相对简单，但是由于附属模型的限制，ETL任务并行化较低；星型模型在设计维度表时反范式设计，所以在ETL过程中整合业务数据到维度表有一定难度，但由于避免附属维度，可并行化处理。

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

维度建模的特点如下：

• 不需要完整的梳理企业业务流程和数据；
• 实施周期根据主题边界而定，容易快速实现 demo 。   

维度建模的缺点

• 维度建模之前需要进行大量的数据预处理，因此会导致大量的数据处理工作（ETL）。
• 当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些与处理过程中，往往会导致大量的数据冗余。
• 如果只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。

浅谈数仓模型（维度建模） - 知乎

大数据和传统关系型数据库的计算框架不一样，例如对比Hive和oracle， Hive 的分析通过 MapReduce 实现，在mapreduce里面，每多一个表的关联，就多一个job。对于雪花模型，由于存在着很多维度表之间的关联，这就会导致一次分析对应多个 MapReduce 任务，而星型模型由于不存在维度表的关联，因此一个 MapReduce 就可以实现分析任务。

MapReduce 本身是一个支持高吞吐量的任务，mapreduce的每个任务进来，要申请资源，分配容器，各节点通信等。由于相互关联的维度表本身会很小，join 操作用时很少，有可能YARN调度时长大于任务运行时间（例如调度需要5秒才能申请到资源，而表之间的join只需要2秒）。因此hive优化里面，要尽可能减少job任务数，也就是减少表之间的关联，可以用适当的冗余来避免低效的查询方式，这是和oracle等其他关系型数据库不同的地方。还有一点，雪花模型中拆分出的维度表，每个表对应至少一个文件，这就涉及到 I/O 方面的性能损耗。 

在实际项目中，不会刻意地去考虑雪花模型，而是刻意地去考虑星型模型，特别是大数据领域的建模，倾斜于使用数据冗余来提高查询效率，倾向于星型模型；雪花模型只会应用在一些我们要求模型的灵活性，要求保证模型本身稳定性的场景下，但是雪花模型并不是首选

3、Data Vault模型

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

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

Data Vault模型包含三种基本结构：

1）中心表-Hub：唯一业务键的列表，唯一标识企业实际业务，企业的业务主体集合。

2）链接表-Link：表示中心表之间的关系，通过链接表串联整个企业的业务关联关系。

3）卫星表-Satellite：历史的描述性数据，数据仓库中数据的真正载体。

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

4、Anchor

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

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

几种基本建模方法对比：

当前主流建模方法为：ER模型、维度建模。

1）ER模型

ER模型常用于OLTP数据库建模，应用到构建数仓时更偏重数据整合，站在企业整体考虑，将各个系统的数据按相似性一致性进行合并处理，为数据分析、决策服务，但并不便于直接用来支持分析。

问题：
a）需要全面梳理企业所有的业务和数据流；
b）实施周期长；
c）对建模人员要求高。

2）维度模型

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

维度建模的有优点：

1. 不需要完整的梳理企业业务流程和数据；
2. 实施周期根据主题边界而定，容易快速实现 demo 。 
3. 业务直观，结构清晰（表结构一目了然），在做业务的时候，这种表特别方便，直接能对到业务中。
4. 便于做OLAP分析，使用方便，写sql的时候很方便。（数据分析用起来会很开心）使用方便，写sql的时候很方便。

维度建模的缺点

• 维度建模之前需要进行大量的数据预处理，因此会导致大量的数据处理工作（ETL）。
• 当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些与处理过程中，往往会导致大量的数据冗余。
• 如果只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。
• 数据冗余巨大，真的很大，在几亿的用户规模下，他的订单行为会很恐怖
• 粒度僵硬，什么都写死了，这张表的可复用性太低。

模型选择和设计的原则：

a）数仓模型的选择是灵活的，不局限于某一种模型方法；
b）数仓模型的设计也是灵活的，以实际需求场景为导向；
c）模型设计要兼顾灵活性，可扩展，而对终端用户透明性；
d）模型设计要考虑技术可靠性和实现成本。

四、数据库及数据仓库模型设计的三个主要步骤

概念模型设计 , 逻辑模型设计 , 物理模型设计 是数据库及数据仓库模型设计的三个主要步骤

1. 概念模型

概念模型就是在了解了用户的需求 , 用户的业务领域工作情况以后 , 经过分析和总结 , 提炼出来的用以描述用户业务需求的一些概念的东西 ; 如销售业务中的 客户 和 定单 , 还有就是 商品 , 业务员 , 用 USE CASE 来描述就是 : 业务员 与 客户 就购买 商品 之事签定下 定单 , 概念模型使用 E-R 图表示 , E-R 图主要是由实体 , 属性和联系三个要素构成的 , 该阶段需完成 :

• 1. 该系统的商业目的是什么 , 要解决何种业务场景
• 2. 该业务场景中 , 有哪些人或组织参与 , 角色分别是什么
• 3. 该业务场景中 , 有哪些物件参与 , 
• 4. 此外需要具备相关行业经验 , 如核心业务流程 , 组织架构 , 行业术语
• 5. 5w1h：who ,  what , when , where , why,  how

 

2. 逻辑模型

逻辑模型是将概念模型转化为具体的数据模型的过程 , 即按照概念结构设计阶段建立的基本 E-R 图 , 按选定的管理系统软件支持的数据模型 (层次/网状/关系/面向对象) , 转换成相应的逻辑模型 , 这种转换要符合关系数据模型的原则 ;
还以销售业务为例 : 客户 信息基本上要包括 : 单位名称 , 联系人 , 联系电话 , 地址等属性
商品 信息基本上要包括 : 名称 , 类型 , 规格 , 单价等属性
定单 信息基本上要包括 : 日期和时间属性 ; 并且 定单 要与 客户 , 业务员 和商品 明细关联 , 该阶段需完成 :

• 1. 分多少个主题 , 每个主题包含的实体
• 2. 每个实体的属性都有什么
• 3. 各个实体之间的关系是什么
• 4. 各个实体间是否有关系约束

3. 物理模型

物理模型就是针对上述逻辑模型所说的内容 , 在具体的物理介质上实现出来 , 系统需要建立几个数据表 : 业务员信息表 , 客户信息表 , 商品信息表 , 定单表 ; 系统要包括几个功能 : 业务员信息维护 , 客户信息维护 , 商品信息维护 , 建立销售定单 ; 表 , 视图 , 字段 , 数据类型 , 长度 , 主键 , 外键 , 索引 , 约束 , 是否可为空 , 默认值 , 该阶段需完成 :

• 1. 类型与长度的定义
• 2. 字段的其他详细定义 , 非空 , 默认值
• 3. 却准详细的定义 , 枚举类型字段 , 各枚举值具体含义
• 4. 约束的定义 , 主键 , 外键

这三个过程 , 就是实现一个数据库设计的三个关键的步骤 , 是一个从抽象到具体的一个不断细化完善的分析 , 设计和开发的过程 ;

五、数据模型工具：ERwin & PownerDesigner

        当今的商业决策对基于海量 的数据依赖越来越强烈，正确而连贯的数据流对商业用户做出快速、灵活的决策起到决定性的作用。建立正确的数据流和数据结构才能保证最好的结果，这个过程叫做数据建模。在实际行业运用的过程中，为了避免认为错误并且加快进度，我们需要使用专业的软件来帮助我们建立数据逻辑模型和物理模型、生成DDL，并且能够生成报告来描述这个模型，同时分享给其他伙伴。下面所列出的工具都是精挑细选的数据建模工具，推荐给大家使用。

1、PowerDesigner
　　PowerDesigner是目前数据建模业界的领头羊。功能包括：完整的集成模型，和面向包含IT为中心的、非IT为中心的差异化建模诉求。支持非常强大的元数据信息库和各种不同格式的输出。PowerDesigner拥有一个优雅且人性化的界面，非常易懂的帮助文档，快速帮助用户解决专业问题。

2、ER/Studio
　　ER/Studio 是一个支持多平台环境的直观数据建模工具，并且本地集成了用于处理大数据平台，例如-MongoDB和Hadoop Hive。它能够进行正向和逆向工程，并且拥有“比较合并”功能，能够输出例如XML、PNG、JPEG等格式文档。内建自动执行任务功能支持当前流行数据库平台。ER/Studio功能非常强大，拥有直观的界面和很好的用户支持特别易于马上开始工作。

3、Sparx Enterprise Architect
　　Enterprise Architect是一个拥有丰富功能的数据建模工具。自诩是高性价比的明智之选。Enterprise Architect帮助企业用户快速建立强大的可维护的系统，而且很容易在共享项目中扩展到大型的协作团队中去。 Enterprise Architect 同样有动态运行模拟模型的能力，用以验证模型和更加正确和深入的理解原来商业系统运作的方式。

4、CA ERwin
　　ERwin 也是业界领先的数据建模解决方案，能够为用户提供一个简单而优雅的界面同时处理复杂的数据环境问题。Erwin的解决方案提提供敏捷模型，同时元数据可以放在普通的数据库中进行处理，这样就能够保证数据的一致性和安全性。Erwin支持高度自定义的数据类型、APIs，允许自动执行宏语言等等。Erwin还建有一个很活跃的用户讨论社区，使得用户之间可以分享知识和各种经验。

        erwin是一个数据库关系实体模型（ER Model）设计工具，与Power Designer（Sybase公司开发）成为最常用的两种数据库设计工具。目前该工具被CA收购，成为CA数据库解决方案中的一个关键部分。与微软的Vision相比，erwin只能设计er model，而且设计界面选项较多，相对来说并不那么友好，增加了使用的难度。

        但如果你是一个出色的数据库应用开发者，那你一定会发现erwin的好处。因为在设计模型层次和复杂度提高以后，visio难以应付众多的数据对象设计和对象之间的关系设计。而且erwin提供了数据库正向工程、逆向工程和文档正向工程功能，可以把设计直接实施到数据库后者把数据库中的对象信息读到erwin设计中，也可以生成设计文档，格式还可以自动定义。在本教程中，将告诉大家我是怎样简单的使用erwin来进行数据库设计的。这里强调了简单二字，就是说有很多只有20%机会用到的80%的功能本教程是不会介绍的。本文用到的erwin版本是4.0。

5、IBM - InfoSphere Data Architect
　　InfoSphere 是一个很创新的、运行在开源平台-Eclipse上的数据建模工具。Infopshere主要聚焦于一下三个主要的特性：高效、简洁、高度集成。InfoSphere能够帮助商业用户建立逻辑、物理模型图，并且之后能非常方便的在各种不同的应用和系统中进行使用。InfoSphere是一个端到端的解决方案，可以快速高效地用在建立、部署、更新数据模型。同时也非常简易的集成了IBM的其他相关产品。