目录
1.2 ER实体建模(Entity-relationship model)
1 建模方法
数据仓库的建模方法有多种，每一种建模方法代表了哲学上的一个观点，代表了一种归纳、概括世界的一种方法。
常见的有 范式建模法、维度建模法、实体建模法等，每种方法从本质上将是从不同的角度看待业务中的问题，不管是从技术层面还是从业务层面，都代表了哲学上的一种世界观。
1.1 范式建模（关系型数据库）
范式建模法其实是我们在构建数据模型常用的一个方法，主要由Inmon所提倡，主要解决关系型数据库得数据存储，利用的一种技术层面上的方法，主要用于业务系统，所以范式建模主要是利用关系型数据库进行数仓建设。
1.1.1 第一范式(1NF)
强调的是列的原子性，即列不能够再分成其他几列，1NF是所有关系型数据库的最基本要。
问题：不能消除重复，存在数据冗余过大，导致插入异常，删除异常，修改异常等问题。
1.1.2 第二范式(2NF)
第二范式（Second Normal Form, 2nd NF）是指每个表必须有主关键字（Primary key），其他数据元素与主关键字一一对应。通常称这种关系为函数依赖（Functional dependence）关系，即表中其他数据元素都依赖于主关键字，或称该数据元素惟一地被主关键字所标识。
简单地理解，2NF就是所有非主键字段都要依赖于整个主键，而不是其中的一部分。不符合 2NF 的设计容易产生冗余数据。
第二范式的两个必要条件：
- 首先要满足第一范式
- 每一个非主属性都完全函数依赖于任何一个主键
1.1.3 第三范式(3NF)
首先是 2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。
第二范式（2NF）和第三范式（3NF）的概念很容易混淆，区分它们的关键点在于：
- 2NF：非主键列是否完全依赖于主键，还是依赖于主键的一部分
- 3NF：非主键列是直接依赖于主键，还是直接依赖于非主键列
1.1.4 范式建模优缺点
- 优点
- 范式化的更新操作通常比反范式化要快
- 当数据较好的范式化时，就只有很少或者没有重复数据，所以只需要修改更少的数据
- 范式化的表通常更小，可以更好地放在内存里，所以执行操作会更快
- 很少有多余的数据意味着检索列表数据时更少需要DISTINCT或者GROUP BY语句
- 缺点：范式化设计的schema的缺点是通常需要关联
- 构建复杂
- 查询复杂
- 不适合大数据
1.2 ER实体建模(Entity-relationship model)
将事务抽象为"实体"（Entity）、"属性"（Property）、"关系"（Relationship）来表示数据关联和事物描述，这种对数据的抽象建模通常被称为ER实体关系模型。实体建模法并不是数据仓库建模中常见的一个方法，它来源于哲学的一个流派。
1.2.1 ER 模型三个关键
- 数据结构：ER 模型中的数据表现为实体与属性之间的关系
- 数据完整性：对于ER模型，键（key）用于实体或者关系类型，而基数约束或者参与约束用于关系类型
- 数据操作：ER 模型中不存在对数据的任何操作
1.2.2 ER 模型约束关系
ER模型中的约束关系通常是指实体与实体之间基于某种关系下的约束，主要包括两种：
- 基数比例（Cardinality ratios）：指定实体允许参与到关系中的最大数目
- 多对多
- 一对多
- 一对一
- 参与约束（Participation constraints）：指定某个实体在其与其他实体的依赖关系中是否必然存在
- 完全参与
- 局部参与：一般情况下，默认为局部参与
1.2.3 ER模型实体类型父类与子类关系
实体类型的父类与子类指的是拥有不同名称的同一个概念，子类通常是父类实体根据其具体的应用意义所采用的的更加显式的表达。父类与子类之间的关系被称为 ISA 关系类型。
- 专门化：自上而下定义一个实体所拥有的子类的集合。
- 一般化：自下而上地把拥有共同属性的多个子类归纳成一个单一的父类
1.2.4 ER模型构建流程
- 识别所以实体类型（包括弱实体类型）；
- 识别所有关系类型（包括 ISA 关系和依赖关联）；
- 识别所有实体和关系类型对应的属性（以及每个属性的定义域）；
- 识别每个实体的主键；
- 辨别步骤 2 中找出的所有关系中的基数比例；
- 确定上述关系的参与约束；
- 确定 ISA 关系中的分离约束和完整性约束。
1.2.5 ER建模优缺点
- 优点
由于实体建模法，能够很轻松的实现业务模型的划分，因此，在业务建模阶段和领域概念建模阶段，实体建模法有着广泛的应用。从笔者的经验来看，再没有现成的行业模型的情况下，我们可以采用实体建模的方法，和客户一起理清整个业务的模型，进行领域概念模型的划分，抽象出具体的业务概念，结合客户的使用特点，完全可以创建出一个符合自己需要的数据仓库模型来。
- 缺点
由于实体说明法只是一种抽象客观世界的方法，因此，注定了该建模方法只能局限在业务建模和领域概念建模阶段。因此，到了逻辑建模阶段和物理建模阶段，则是范式建模和维度建模发挥长处的阶段。
1.3 维度建模（非关系型数据库）
维度模型是数据仓库领域大师Ralph Kimball 所倡导，他的《数据仓库工具箱》，是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。
1.3.1 模型实现
星型模型和雪花模型的主要区别在于对维度表的拆分：雪花模型维度表的设计更加规范，一般符合3NF；星型模型：一般采用降维的操作，利用冗余来避免模型过于复杂，提高易用性和分析效率。
- 星型模型
核心是一个事实表及多个非正规化描述的维度表组成，维度表之间是没有关联的，维度表是直接关联到事实表上的，只有当维度表极大，存储空间是个问题时，才考虑雪花型维度，简而言之，最好就用星型维度即可。当所有维表都直接连接到“ 事实表”上时，整个图解就像星星一样，故将该模型称为星型模型
星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余，如在地域维度表中，存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录，那么国家 A 和省 B 的信息分别存储了两次，即存在冗余。
- 雪花模型
星形模式中的维表相对雪花模式来说要大，而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表，满足了规范化设计。然而这种模式在实际应用中很少见，因为这样做会导致开发难度增大，而数据冗余问题在数据仓库里并不严重。
可以认为雪花模型是星型模型的一个扩展，每个维度表可以继续向外扩展，连接多个子维度。当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。
1.3.2 维度建模优缺点
维度建模是面向分析场景而生，针对分析场景构建数仓模型，重点关注快速、灵活的解决分析需求，同时能够提供大规模数据的快速响应性能。
- 优点
-
方便使用，模型简单
-
针对各个维作了大量的预处理，极大的提升数据仓库的处理能力
-
维度建模非常直观，紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理，即可以完成维度建模
-
- 缺点
- 数据冗余，维度补全后造成的数据浪费
- 灵活性差，维度变化造成的数据更新量大(例如刷数据的时候，需要刷大量的表)
2 数仓分层
数仓分层设计，参考图片：https://www.cxyzjd.com/article/qq_41587243/117283258
2.1 ODS
ODS(Operational Data Store) 操作性数据，是作为数据库到数据仓库的一种过渡，ODS的数据结构一般与数据来源保持一致，便于减少ETL的工作复杂性，而且ODS的数据周期一般比较短。ODS的数据最终流入DW。
数据来源：
- 业务库
- 埋点日志
- 消息队列
2.2 DW
DW (Data Warehouse)数据仓库，是数据的归宿，是数据仓库的主体，在这里，从 ODS 层中获得的数据按照主题建立各种数据模型。
- 数据明细层：DWD（Data Warehouse Detail）
- 主要对ODS数据层做一些数据清洗和规范化的操作
- 数据中间层：DWM（Data WareHouse Middle）
- 数据服务层：DWS（Data WareHouse Servce）
- 数据集市层（DM）date market，又称DWS, data warehouse service或主题层，存放的是轻度聚合的数据
- 维表层：（Dimension）
2.4 APP层
应用层的数据，一般都要求比较快的响应速度，因此一般是放在 Mysql、PG、Redis中。
2.5 其他层
2.5.1 TMP层
每一层的计算都会有很多临时表，专设一个TMP层来存储我们数据仓库的临时表。
2.5.2 DIM维度表
也叫数据字典DICT，比如国家代码和国家名、地理位置、中文名、国旗图片等。
504
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
