数仓-数仓建模方法介绍

1. 关系模式范式

众所周知，RDBMS设计时，需要遵照一定的规范要求，目的在于降低数据的冗余性和数据的一致性，目前业界范式有：

1NF

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

2NF

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

上述表格中，如果想表达某个学生分数的时候，是通过（学生ID，所修课程）来作为主键，唯一确定分数；而一个学生只能属于一个系，可以理解为所属系是依赖于学生ID的（即给出一个学生ID，就可以给出所属系），这就产生了局部依赖。
该表会带来什么问题呢？
1）如果学生所属系改变了，则需要更新该学生的所有记录的所属系和系主任，如果存在上万条记录呢？那么就会带来性能问题。
2）如果系主任改变了，同样需要做大量改动，也会带来性能问题。
所以作出如下拆分：

1. 表1：
   

3NF

在2NF的基础上，任何非主属性不依赖于其他非主属性（非主属性不存在依赖关系）。

大多数RDBMS业务场景达到3NF即可满足我们业务需求，后续三项范式不再展开介绍。
BCNF
4NF
5NF

4.ER实体关系模型

4.1什么是ER模型？

1）在信息系统中，将事物抽象为“实体”、“属性”、“关系”来表示数据关联和事物描述。
2）三者用来做什么呢？
实体：通常为参与到过程中的主体，客观存在的，比如商品、仓库、货位、汽车等；此实体非数据库中的实体表。
属性：对主体的描述、修饰即为属性，比如商品的属性有商品名称、颜色、尺寸、重量、产地等。
关系：现实的物理事件是依附于实体的，比如商品入库事件，依附实体商品、货位，就会有“库存”的属性产生；用户购买商品，依附实体用户、商品，就会有“购买数量”、“金额”的属性产品。
3）实体之间建立关系时，存在哪些对照关系呢？
1:1，一对一关系，比如一个人有且仅有一个身份证号
1:n，一对多关系，比如一个班级有多个学生，但是一个学生只能属于一个班级
m:n，多对多关系，比如学生选课，每个学生可以选修多门课程，每门课程也可以被多个学生选修
4）如何建立ER模型呢？
1）抽象出实体
2）梳理实体间的关系
3）梳理实体属性、关系属性
4）构建ER图

4.2小结

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

5.维度建模

5.1 雪花模型和星型模型的对比

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

5.2 维度建模应用

维度建模源自数据集市，主要面向分析场景
数据仓库建模
主流的OLAP引擎的底层数据模型
转载自-更多详细见

6.维度建模优缺点

优点：
1）星型模式之所以广泛被使用，在于针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等。通过这些预处理，能够极大的提升数据仓库的处理能力。特别是针对 3NF 的建模方法，星型模式在性能上占据明显的优势。
2）维度建模非常直观，紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理，即可以完成维度建模。
缺点
1）由于在构建星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些与处理过程中，往往会导致大量的数据冗余。
2）如果只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法

7.范式建模优缺点

优点
从关系型数据库的角度出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模。但其
缺点
由于建模方法限定在关系型数据库之上，在某些时候反而限制了整个数据仓库模型的灵活性，性能等，特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时，需要进行一定的变通才能满足相应的需求。
以上转载自