数据仓库基本理论

1、关系模式范式

1.1 范式理论概述

关系型数据库设计时，遵照一定的规范要求，目的在于降低数据的冗余性和数据的一致性，目前业界范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。

范式的标准定义是：符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度。通俗地讲，范式可以理解为一张数据表的表结构所符合的某种设计标准的级别。

使用范式的根本目的是：减少数据冗余，尽量让每个数据只出现一次**，获取数据时通过 join 拼接出最后的数据**。

1.2 范式基本概念

学号	姓名	系名	系主任	课名	分数
20170901176	王小强	计算机系	马小腾	C 语言	95
20170901176	王小强	计算机系	马小腾	计算机基础	99
20170901176	王小强	计算机系	马小腾	高等数学	80
20170901179	李阳	经管系	王小石	经济学	95
20170901179	李阳	经管系	王小石	管理学	92
20170901186	张小俊	数学系	钱小森	高等数学	89
20170901186	张小俊	数学系	钱小森	线性代数	96

• ① 函数依赖

若在一张表中，在属性（或属性组）X 的值确定的情况下，必定能确定属性 Y 的值， 那么就可以说 Y 函数依赖于 X，写作 X → Y。

表中其他的函数依赖关系还有如： 系名 → 系主任 ； 学号 → 系主任；（学号，课名） → 分数。
以下函数依赖关系则不成立： 学号 → 课名；学号 → 分数课名 → 系主任；(学号，课名） → 姓名。

• ② 完全函数依赖

在一张表中，若 X → Y，且对于 X 的任何一个真子集X '（假如属性组 X 包含超过一个属性的话），X ’ → Y 不成立，那么我们称 Y 对于 X 完全函数依赖，记做：

例如：学号 F→ 姓名 ；（学号，课名） F→ 分数。

• ③ 部分函数依赖

假如 Y 函数依赖于 X，但同时 Y 并不完全函数依赖于 X，那么我们就称 Y 部分函数依赖于 X，记做：

简单来说，（学号，课名）→ 系名；学号 → 系名；那么（学号，课名）p→ 系名。

• ④ 传递函数依赖

假如 Z 函数依赖于 Y，且 Y 函数依赖于 X ，且 Y 不包含于 X，X 不函数依赖于 Y，那么我们就称 Z 传递函数依赖于 X，记做：

简单来说，系名 → 系主任，学号 → 系名，那么学号 T→ 系主任。

1.3 常见范式

1. 一范式（1NF）：域应该是原子性的，即数据库表的每一列都是不可分割的原子数据项（属性不可分割）。域：就是列的取值范围，比如性别的域就是（男，女）。 1NF 是所有关系型数据库的最基本要求。

2. 二范式（2NF）：在 1NF 的基础上，实体的属性完全函数依赖于主关键字（唯一性）， 不能存在部分函数依赖于主关键字（混合主键）。如果存在某些属性只依赖混合主键中的部分属性，那么不符合二范式。为了消除这种部分依赖，只有一个办法，就是将大数据表拆分成两个或者更多个更小的数据表。

3. 三范式（3NF）： 3NF 在 2NF 的基础之上，消除了非主属性对于主键（复合主键）的传递依赖。

所谓的范式，是用来学习参考的，设计的时候根据情况，未必一定要遵守，切记。
数据库三大范式通俗解释：https://blog.youkuaiyun.com/q957967519/article/details/81910547

2、数据仓库建模基本理论

2.1 数据仓库建模目标

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

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

上述的四点之间是存在冲突的，为了提高访问性能，可能会提高数据冗余（减少 Join）， 这样会降低计算成本，但是会导致数据存储成本很高，并且由于数据的冗余，会提高数据统计口径不一致的风险，我们的目的是通过合理的设计在性能、成本、效率和数据质量之间找到平衡点。

2.2 E-R 实体模型

2.2.1 基本理论

ER 模型是数据库设计的理论基础，当前几乎所有的 OLTP 系统设计都采用 ER 模型建模的方式。
在信息系统中，将事物抽象为“实体”、“属性”、“关系”来表示数据关联和事物描述；其中，实体：Entity，关系：Relationship，这种对数据的抽象建模通常被称为 ER 实体关系模型。

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

2.2.2 实体之间的对照关系

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

• 1:1，即 1 对 1 的关系，比如实体人、身份证，一个人有且仅有一个身份证号；（A->B： 相互完全依赖，知道 A 一定确定 B，知道 B 一定确定 A）。（动静分离：在数据库设计时，会将动态属性（年龄、地址、偏好、…）和静态属性（姓名、性别、身份证号、…）进行分离，剥离为两张表，一张父表，一张子表，从而提高性能）。
• 1:n，即 1 对多的关系，比如实体学生、班级，对于某 1 个学生，仅属于 1 个班级，而在 1
  个班级中，可以有多个学生；（一张学生表，一张班级表，通过班级 ID 这个外键进行关联）。
• n:m，即多对多的关系，比如实体学生、课程，每个学生可以选修多门课程，同样每个课程也可以被多门学生选修；（一张学生表，一张课程表，一张选课表）。

2.2.3 ER 建模的图形表示

在日常建模过程中：
“实体”：使用矩形表示；
“关系”：使用菱形表示；
“属性”：使用椭圆形表示；
所以 ER 实体关系模型也称作 E-R 关系图。

2.2.4 ER实体建模实例

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

2.3 维度模型

维度建模的理论由 Ralph Kimball 提出，他提出将数据仓库中的表划分为事实表和维度表两种类型。
维度建模源自数据集市，主要面向分析场景。
① “事实表”，用来存储事实的度量（measure）及指向各个维的外键值。
② “维度表”，用来保存该维的元数据，即维的描述信息，包括维的层次及成员类别等。

简单的说，维度表就是你观察该事物的角度（维度)，事实表就是你要关注的内容。例如用户使用滴滴打车，那么打车这件事就可以转化为一个事实表，即打车订单事实表，然后用户对应一张用户维度表，司机对应一张司机维度表。

2.3.1 事实表往往包含三个重要元素：

- 1.维度表外键
- 2.度量数据
- 3.事件描述信息

例如在电商场景中的一次购买事件，涉及主体包括客户、商品、商家，产生的可度量值包括商品数量、金额、件数等。

2.3.2 维度表

每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键，当然，维度表行的描述环境应与事实表行完全对应。维度表通常比较宽，是扁平型非规范表，包含大量的低粒度的文本属性。

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

综上所述，如果针对用户的下单行为（单一商品）进行维度建模，我们可以得到如下模型：

2.4 建模方法总结

ER 模型以及维度模型是当前主流的建模方法。

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

ER 模型的特点如下：

1. 需要全面梳理企业所有的业务和数据流。
2. 实施周期长。
3. 对建模人员要求高。

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

维度建模的特点如下：

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

2.5 星型模式、雪花模式与星座模式

2.5.1 星型模式

星型模式是维度模型中最简单的形式，也是数据仓库以及数据集市开发中使用最广泛的形式。

星型模式由事实表和维度表组成，一个星型模式中可以有一个或多个事实表，每个事实表引用任意数量的维度表。星型模式的物理模型像一颗星星的形状，中心是一个事实表， 围绕在事实表周围的维度表表示星星的放射状分支，这就是星型模式这个名字的由来。星型模式将业务流程分为事实和维度。事实包含业务的度量，是定量的数据，如销售价格、销售数量、距离、速度、重量等是事实。维度是对事实数据属性的描述，如日期、产品、客户、地理位置等是维度。一个含有很多维度表的星型模式有时被称为蜈蚣模式，显然这个名字也是因其形状而得来的。蜈蚣模式的维度往往只有很少的几个属性，这样可以简化对维度表的维护，但查询数据时会有更多的表连接，严重时会使模型难于使用，因此在设计中应该尽量避免蜈蚣模式。

2.5.2 雪花模式

雪花模式是一种多维模型中表的逻辑布局，其实体关系图有类似于雪花的形状，因此得名。

与星型模式相同，雪花模式也是由事实表和维度表所组成。所谓的“雪花化”就是将星型模型中的维度表进行规范化处理。当所有的维度表完成规范化后，就形成了以事实表为中心的雪花型结构，即雪花模式。

将维度表进行规范化的具体做法是，把低基数的属性从维度表中移除并形成单独的表。基数指的是一个字段中不同值的个数，如主键列具有唯一值， 所以有最高的基数，而像性别这样的列基数就很低。

在雪花模式中，一个维度被规范化成多个关联的表，而在星型模式中，每个维度由一个单一的维度表所表示。一个规范化的维度对应一组具有层次关系的维度表，而事实表作为雪花模式里的子表，存在具有层次关系的多个父表。

2.5.3 星座模式

数据仓库由多个主题构成，包含多个事实表，而维表是公共的，可以共享，这种模式可以看做星型模式的汇集，因而称作星系模式或者事实星座模式。

2.6 模式的选择

在数据仓库建模时，会涉及到模式的选择，我们要根据不同模式的特点选择适合具体业务的模式：

1.冗余： 雪花模型符合业务逻辑设计，采用 3NF 设计，有效降低数据冗余；星型模型的维度表设计不符合 3NF（如果是雪花模型改造成了星型模型，那么肯定不符合3NF，因为一定发生了表的整合，即降维，一定有传递依赖，但是**，并不是所有的星型模型都不符合 3NF**，很多星型模型的表是符合 3NF 的），反规范化，维度表之间不会直接相关，牺牲部分存储空间。
2. 性能： 雪花模型由于存在维度间的关联，采用 3NF降低冗余，通常在使用过程中，需要连接更多的维度表，导致性能偏低；星型模型反三范式，采用降维的操作将维度整合，以存储空间为代价有效降低维度表连接数，性能较雪花模型高。（ 星型表的数据冗余大，是用存储空间换取效率 ）（ BI 的一些工具对于星型模型的支持更规范化 ）。
3. ETL ：雪花模型符合业务 ER 模型设计原则，在 ETL 过程中相对简单，但是由于附属模型的限制，ETL 任务并行化较低（由于雪花模型中有很多的维度依赖，在 ETL 的时候， 需要在保持 3NF 的前提下对数据进行清洗，即对数据一致性/规范化的处理，例如数据来自于多个业务系统，各个系统对于用户的定义不一致，此时要对每个业务定义的用户数据进行规范化处理，在 3NF 的限制下必然会降低并行度）；星型模型在设计维度表时反范式设计， 所以在 ETL 过程中整合业务数据到维度表有一定难度，但由于避免附属维度，可并行化处理（不用关注太多的关联关系，避免了维度表之间的关联关系，并行度较高，注意，一般场景下星型模型的并行化程度更高，并不是所有场景）。

Hive 的分析通过 MapReduce 实现，每多一个 Join 就会多出一个 MapReduce 过程，对于雪花模型，由于存在着很多维度表之间的关联，这就会导致一次分析对应多个 MapReduce 任务，而星型模型由于不存在维度表的关联，因此一个 MapReduce 就可以实现分析任务。
MapReduce 本身是一个支持高吞吐量的任务，它的每个任务都要申请资源、分配容器、节点通信等待，需要 YARN 的调度，由于相互关联的维度表本身会很小，join 操作用时很少，YARN 调度的时长可能都大于实际运算的时长，因此我们要尽可能减少任务个数，对于 Hive 来说就是尽可能减少不必要的表的关联。还有一点，雪花模型中拆分出的维度表，每个表对应至少一个文件，这就涉及到 I/O 方面的性能损耗。

因此，我们要采用适当的数据冗余，避免不必要的表之间的关联。

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