flink车联网项目前篇：项目设计（第64天）

系列文章目录

5. 车联网项目设计
   5.1 数仓分层
   5.2 数仓主题
6. 数据建模
7. 数据仓库建模方法论
   2.1 关系建模
   2.1.1 ER模型
   2.1.2 关系模式范式

---

前言

本文介绍车联网项目设计，数仓分层，数仓主题，数据建模。

5. 车联网项目设计

5.1 数仓分层

本项目共分为四层，ODS/DWD/DWS/ADS。
其中实时数仓 ADS 层直接存入到 StarRocks 结果表中，离线数仓 ADS 层会在 MaxCompute 中存一份再存到StarRocks 结果表中。
维度表不作为数仓分层，而是作为主题出现。

5.2 数仓主题

本项目共5个主题域，7个主题，具体如下：

注：上表中只是教学项目中涉及的主题域和主题，在真实项目中的主题和需求等都要更多一些。
上述项目中，司机主题、乘客主题、投诉申诉主题、推荐上车点主题的时效性要求不高，为离线计算；其他主题为实时计算。

数据仓库建模

1. 数据建模

数据几乎总是用于两种目的：操作型记录的保存和分析型决策的制定。简单来说，操作型系统保存数据，分析型系统使用数据。前者一般仅反映数据的最新状态，按单条记录事务性来处理；其优化的核心是更快地处理事务。后者往往是反映数据一段时间的状态变化，按大批量方式处理数据；其核心是高性能、多维度处理数据。
通常将操作型系统简称为 OLTP（On-Line Transaction Processing）— 联机事务处理，将分析型系统简称为 OLAP（On-Line Analytical Processing）— 联机分析处理。
针对这两种不同的数据用途，如何组织数据，更好地满足数据使用需求。这里就涉及到数据建模问题。即设计一种数据组织方式（模型），来满足不同场景。

2. 数据仓库建模方法论

2.1 关系建模

数据仓库之父 Bill Inmon 提出的建模方法是从全企业的高度，用实体关系（Entity Relationship，ER）模型来描述企业业务，并用规范化的方式表示出来，在范式理论上符合3NF。

2.1.1 ER模型

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

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

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

在日常建模中，“实体”用矩形表示，“关系”用菱形，“属性”用椭圆形。

2.1.2 关系模式范式

范式是关系模式满足不同程度的规范化要求的标准。范式的种类与数据依赖有着直接联系，满足不同程度要求的关系称为不同的范式等级。其中,满足最低程度要求的范式属于第一范式，简称1NF；在第一范式中进一步满足一些要求的关系属于第二范式，简称2NF，依次类推，还有第三范式(3NF)、BC范式(BCNF)、第四范式(4NF)和第五范式(5NF)，这些都是关系范式。
范式的目的是减少数据冗余，增强数据的一致性。遵循的范式级别越高，数据冗余性就越低。

 第一范式（1NF）:
1NF是关系模式应具备的最起码的条件，如果数据库设计不能满足第一范式，就不称为关系型数据库。
定义：如果关系模式R的每个关系r的属性都是不可分的数据项，那么就称R是第一范式的模式。
例如 (学生信息表)：

以上的表就不符合，第一范式：联系方式字段可以再分。
满足第一范式(1NF)的表结构应该如下：

 第二范式（2NF）：
定义：如果关系模式R是1NF，且每个非主属性完全函数依赖于候选键，那么就称R是第二范式。
例如 (产品流水凭证模板表), 产品代码和交易类型是联合主键：

通过产品代码和交易类型可以确定凭证模板代码, 差额凭证模板代码, 产品名称, 所以可以把 (产品代码, 交易类型) 作为主键。
但是, 产品名称并不完全依赖于(产品代码, 交易类型), 只要产品代码就能确定产品名称, 这种依赖叫不完全依赖(或部分依赖)。
第二范式不能有不完全依赖，修改后, 满足第二范式：

 第三范式（3NF）：
定义: 首先要满足第二范式，其次非主属性之间不存在函数依赖。由于满足了第二范式，表示每个非主属性都函数依赖于主键。如果非主属性之间存在了函数依赖，就会存在传递依赖，这样就不满足第三范式。
例如(产品流水凭证模板表), 产品代码和交易类型是联合主键：

差额凭证模板代码依赖于主键 (产品代码, 交易类型), 差额凭证模板名称依赖于差额凭证模板 代码, 这就存在传递依赖, 不满足第三范式。
修改使其满足第三范式：

 总结：简单来说，
第一范式：列不能再分。
第二范式：建立在第一范式基础上，消除部分依赖。
第三范式：建立在第二范式基础上，消除传递依赖。
2.1.3 小结
实体关系模型的基本假设是数据仓库的需求会发生变化，因此实体关系模型设计所要求的高度抽象、独立性，在面对频繁变化时体现出了其优势。另外，实体关系模型所遵循的三范式在减少数据冗余方面有天然优势，在数据量不断膨胀增长的背景下，规范化的数据模型对于降低不必要的数据存储十分有意义。

实体关系模型在OLAP应用中，主要存在两大问题：

1. 实体关系模型对数仓建模者的视野有较高要求，需要对企业的业务系统和架构充分理解，因此模型构建在学习成本方面有一定的劣势。
2. 对于分析型需求来说，实体关系模型较为松散、零碎，物理表数量多，需要进行大量的关联、查询的性能问题非常凸显。
   因此，实体关系模型在OLAP建设体系中更适合基础数据层的建设，目的是将各个系统中的数据以整个企业角度按主题进行相似性组合和合并，并进行一致性处理。