1.建模目标

数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。Linux的创始人Torvalds有一段关于“什么才是优秀程序员”的话：“烂程序员关心的是代码，好程序员关心的是数据结构和它们之间的关系”，其阐述了数据模型的重要性。有了适合业务和基础数据存储环境的模型，那么大数据就能获得以下好处。

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

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

以空间换时间以时间换空间

以空间换时间： Join 维度表事实表 ===> 大宽表
以时间换空间：本身一张大事实表 ==> 事实表 + 多张维度表

2.关系型数据库范式

设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式。

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

第一范式(1NF)：字段不可分，每个字段是原子级别的，多个字段组织在一起形成一个字段是违反第一范式的
第二范式(2NF)：有主键，非主键字段依赖主键
第三范式(3NF)：非主键字段不能相互依赖
巴斯-科德范式(BCNF)：在3NF基础上，任何非主字段不能对主键子集依赖
第四范式(4NF)：在满足3NF的基础之上，表中不能包含一个实体的两个或多个互相独立的多值因子
第五范式(5NF)完美范式：在满足4NF的基础之上，表必须可以分解为较小的表，除非那些表在逻辑上拥有与原始表相同的主键

各种范式呈递次规范，越高的范式数据库冗余越小。有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。

满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一个数据库设计如果符合第二范式，一定也符合第一范式。如果符合第三范式，一定也符合第二范式。一般说来，数据库只需满足第三范式(3NF）就行了。总之，规范化的过程就是在数据库表设计时移除数据冗余的过程。随着规范化的进行，数据冗余越来越少，但数据库的效率也越来越低。

3.ER对象关系实体模型

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

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

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

1:1   即1对1的关系，比如实体人、身份证，一个人有且仅有一个身份证号
1:n   即1对多的关系，比如实体学生、班级，对于某1个学生，仅属于1个班级，而在1个班级中，可以有多个学生
n:m   即多对多的关系，比如实体学生、课程，每个学生可以选修多门课程，同样每个课程也可以被多门学生选修

在日常建模过程中：所以ER实体关系模型也可以称作E-R关系图

“实体”用矩形表示
“关系”用菱形表示
“属性”用椭圆形表示

应用场景：

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

4.维度模型

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

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

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

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

4、选择事实。确定分析需要衡量的指标。

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

4.1.事实表

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

电商场景：一次购买事件，涉及主体包括客户、商品、商家，产生的可度量值，包括商品数量、金额、件数等，所以订单明细表，就是一张事实表。

事实表设计原则：摘自《大数据之路：阿里巴巴大数据实践》

原则1:尽可能包含所有与业务过程相关的事实。事实表设计的目的是为了度量业务过程，事实越多，越有利于多角度多维度度量业务

原则2:只选择与业务过程相关的事实。比如下单事件，不应该存储支付金额

原则3:分解不可加性事实为可加的组件。比如订单的优惠率，应该分解为订单的原价与订单优惠金额两个事实存储在事实表中

原则4:在选择维度和事实之前必须先声明粒度。粒度是维度的组合。先确定粒度，再确定维度。粒度用于确定事实表中一行所表示业务的细节层次，决定了维度模型的扩展性，在选择维度和事实之前必须先声明粒度，且每个维度和事实必须与所定义的粒度保持一致。

原则5:在同一个事实表中不能有多种不同粒度的事实。事实表中的所有事实需要与表定义的粒度保持一致，在同一个事实表中不能有多种不同粒度的事实。

原则6:事实的单位要保持一致，对于同一个事实表中事实的单位应该保持一致。比如订单的金额、订单优化金额、订单运费金额这三个事实，应该采用一致的计量单位，统一为元或者分，方便实用。

原则7:对事实的null值要处理。对于事实表中事实度量为null值的处理，因为在数据库中null值对常用数字型字段的sql过滤条件都不生效，比如大于，小于，等于…，建议用零值填充。

原则8:使用退化维度提高事实表的易用性。这样设计的主要目的是为了减少下游用户使用时关联多个表进行操作。直接通过退化维度实现事实表的操作。通过增加存储的冗余，提高计算的速度。空间置换时间的方式。

4.2.维度表

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

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

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

维度表设计原则：

原则1：每个维表必须有而且只有一个最明细层作为该维表的颗粒度。

原则2：任何一个维表若被多个事实表使用，尽量沉淀出通用的维度属性，这些属性作为公共维表属性来设计公共维表。

原则3：除非出于性能考虑，否则每一个非键属性应只出现在一张维表里。

原则4：尽可能生成丰富的维度属性，尽可能多地给出包括一些富有意义的文字性描述

原则5：维表应尽量保存业务使用的代码和ID，以及描述信息。

原则6：维表的主键（代理键）应做为事实表的外键包含在事实表内。

原则7：每个维表中要有相应的行记录来处理特殊的情形来避免在事实表中置空值。如记录不存在，以及迟到的维记录。

原则8：通常情况下，一个维度模型，不应该携带很多的维度，否则会增加查询的负担，响应性能，个位数最佳

原则9：需要记录属性变化的维的主键应该是使用代理键，并使用具有业务含义，业务用户可识别的代码作为自然键。业务系统自带的代理键不能做为维表的主键。

4.3.模型分层

分层通用做法：

ODS(Operational Data Store) 原始数据层
DWD(Data Warehouse Detail) 明细数据层
DWS(Data Warehouse Service) 汇总数据层
ADS(Application Data Store) 数据应用层

总体原则：

1、数据库名、数据表名、字段名全部小写，单数形式，使用"_"进行分割；
2、不准出现大写与复数表达形式，要见名知意；
3、不能出现SQL语法中关键字，例如：table等；
4、最好形成统一的，业界共识的标准和规范，比如阿里的 MySQL规范

关于表命名的一些企业最佳实践：

1、ODS层命名为ods开头 + DWD层命名为dwd开头 + DWS层命名为dws开头 + ADS层命名为ads开头
2、表名的命名中，包含分层信息，包含可选的系统标识，业务主题，粒度，维度信息等
3、临时库表命名为xxxxx_tmp + 备份库表命名为xxxxx_bak

5. 模型分类

在构建数据仓库的维度建模中，一般有三种模式。星型模型/雪花模型/星座模型

在多维分析的商业智能解决方案中，根据事实表和维度表的关系，又可将常见的模型分为星型模型和雪花型模型。在设计逻辑型数据的模型的时候，就应考虑数据是按照星型模型还是雪花型模型进行组织。

5.1.星型模型

当所有维表都直接连接到“ 事实表”上时，整个图解就像星星一样，故将该模型称为星型模型。 星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余

星形模型的维度建模由一个事实表和一组维度表组成，有以下特点：

1、维度表只和事实表关联，维度表之间没有关联；
2、每个维表的主码为单列，且该主码放置在事实表中，作为两边连接的外码；
3、以事实表为核心，维表围绕核心呈星形分布；

5.2.雪花模型

当一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的"层次"区域，这些被分解的表都连接到主维度表而不是事实表。

优点：通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。

雪花模型的特点：

1、将星形模式的大维度表拆分未小维度表，满足规范化设计，但不利于开发。
2、星型模型因为数据的冗余所以很多统计查询不需要做外部的连接，因此一般情况下效率比雪花型模型要高。在冗余可以接受的前提下，实际运用中星型模型使用更多，也更有效率。
3、在雪花模型中，数据模型的业务层级是由一个不同维度表主键-外键的关系来代表的。而在星形模型中，所有必要的维度表在事实表中都只拥有外键。

5.3.星座模型

星座模式也是星型模式的扩展。

星座模型特点：

1、星型模型和雪花模型都是基于多个维表对应事实表，有的时候一个维度表可能被多个事实表用到，这个时候就需要采用星座模式。

5.4.模型对比

雪花模型是将星型模型的维度表进一步划分，使得各维度表满足规范化设计。而星座模型允许星型模型中出现多个事实表，更符合实际业务需求。 雪花模型使得维度分析更加容易。

综上所述可以看出：星型模型和雪花模型主要区别就是对维度表的拆分：

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

星型模型和雪花模型的主要区别：

冗余：

雪花模型符合业务逻辑设计，采用3NF设计，有效降低数据冗余；

星型模型的维度表设计不符合3NF，反规范化，维度表之间不会直接相关，牺牲部分存储空间。

性能：

雪花模型由于存在维度间的关联，采用3NF降低冗余，通常在使用过程中，需要连接更多的维度表，导致性能偏低；

星型模型反三范式，采用降维的操作将维度整合，以存储空间为代价有效降低维度表连接数，性能较雪花模型高。

ETL处理：

雪花模型符合业务ER模型设计原则，在ETL过程中相对简单，但是由于附属模型的限制，ETL任务并行化较低；

星型模型在设计维度表时反范式设计，所以在ETL过程中整合业务数据到维度表有一定难度

离线数仓（三）数仓建模基本理论相关推荐

我理解的算法 - 三数之和及两数、三数之和扩展题
我理解的算法 - 三数之和及两数.三数之和扩展题 LeetCode 15.三数之和扩展三数之和变种题两数之和变种题 LeetCode 15.三数之和这道题的题目大家自行查看:链接在这 ,题目和 ...
《漫画算法2》源码整理-6 两数之和三数之和
两数之和 import java.util.*;public class TwoSum {public static List<List<Integer>> twoSum(in ...
两数、三数、四数之和相关题目（Leetcode题解-Python语言）
作为 Leetcode 的第一题,两数之和自然是知名度最高的,从两数之和出发也有不少的衍生题目,下面就让我们好好地解决它们. 1. 两数之和 class Solution:def twoSum(sel ...
基础数学（二）两数之和三数之和
目录两数之和_牛客题霸_牛客网三数之和_牛客题霸_牛客网两数之和_牛客题霸_牛客网给出一个整型数组 numbers 和一个目标值 target,请在数组中找出两个加起来等于目标值的数的下标,返 ...
c++ 快排优化（三数取中法）
快排优化(三数取中法) 文章目录快排优化(三数取中法) 前言一.三数取中法二.递归思想三.程序实现过程(代码) 1.取基准数(三数取中) 2.快速排序(递归) 总结前言作为刚刚入门c和c+ ...
【LeetCode】两数之和、三数之和、四数之和系列
文章目录两数之和★ 三数之和★★ 四数之和★★ 四数相加Ⅱ★★ 最接近的三数之和★★ 此篇文章总结下力扣中的两数之和.三数之和.四数之和及一系列求数组中满足达到目标值的元组个数的问题,仔细阅读下面的 ...
【离线数仓-3-数仓建模方法理论汇总】
离线数仓-3-数仓建模方法理论汇总离线数仓-3-数仓建模方法理论汇总 1.数仓概述 2.数据仓库核心架构(Hive) 3.数据仓库建模概述 4.数据仓库建模方法论 1.ER(Entity Relat ...
离线实时一体化数仓与湖仓一体—云原生大数据平台的持续演进
简介:阿里云智能研究员林伟 :阿里巴巴从湖到仓的演进给我们带来了湖仓一体的思考,使得湖的灵活性.数据种类丰富与仓的可成长性和企业级管理得到有机融合,这是阿里巴巴最佳实践的宝贵资产,是大数据的新一代架 ...
离线数仓12—— 数仓开发之DWD层
文章目录第9章数仓开发之DWD层 9.1 交易域加购事务事实表 9.2 交易域下单事务事实表 9.3 交易域取消订单事务事实表 9.4 交易域支付成功事务事实表 9.5 交易域退单事务事实表 9. ...
电商离线数仓-业务数仓指标(GMV主题/转化率主题)
GMV和转化率 GMV主题 GMV的概念 GMV表的创建 GMV表里导入数据转化率转化率概念转化率表的创建转化率表里导入数据 ADS层用户行为漏斗分析 GMV主题 GMV的概念什么是GMV? ...

离线数仓（三）数仓建模基本理论