数据模型介绍

一. 数据模型（OLTP，数据层面）

1.数据模型定义：

描述和操作数据，数据间联系，数据约束。

数据库-数据模型（分类、三要素、概念）_zdplife的博客-CSDN博客_数据库数据模型

数据模型分类 - wangb021 - 博客园

2.组件：数据结构、数据操作、数据约束

1.结构部分：创建数据库的规则 DDL；2.操纵部分：对数据的操作 DML；3.完整性约束：确保数据准确性。

3.分类：

数据模型的发展历史：

层次数据模型 -> 网状数据模型 -> 关系数据模型 -> ER数据模型 -> 语义数据模型 （对象--关系数据模型/扩展的关系数据模型， 面向对象数据模型）

3.1. 概念数据模型（信息模型）：E-R模型（实体（对象），属性（对象的性质），联系，约束）

实体：

3.1.1 特殊化/泛化：超类/子类

3.1.2 聚合：has a, is a part of. 表示整体和部分的弱联系。

3.1.3 组合：compose. 表示整体和部分的强联系。

3.2. 结构数据模型：面向计算机系统的，用于DBMS的实现

3.2.1. 关系模型：数据被组织成关系，在SQL中被称为表，其中每个关系都是元组的无序集合，在SQL中称为行。没有复杂的嵌套结构。

3.2.2. 层次模型：文档模型，树形结构。主要存储格式是JSON, XML, 二进制编码。

3.2.3. 网状模型：图状数据模型，以上两种模型适用于多对一的关系。图状数据模型适用于解决一对多和多对多的关系。

3.3. 物理数据模型：描述数据如何存储在计算机中

3.3.1. 统一模型 unifying model

3.3.2. 帧存储 frame memory

二. 数据模型（OLAP，表层面，维度建模）

三大数据模型：星型模型、雪花模型、星座模型_曼莎70的博客-CSDN博客_星型模型

数据仓库系列：星型模型和雪花型模型 - 知乎

1. 星型模型

星型模型中只有一张事实表，以及0张或多张维表，事实表与维表通过主键外键相关联，维表之间不存在关联关系，当所有维表都关联到事实表时，整个图形非常像一种星星的结构，所以称之为“星型模型”。

星型模型是最简单最常用的模型。星型模型本质是一张大表，相比于其他数据模型更合适于大数据处理。其他模型可以通过一定的转换，变为星型模型。

星型模型的缺点是存在一定程度的数据冗余。因为其维表只有一个层级，有些信息被存储了多次。比如一张包含国家、省份、地市三列的维表，国家列会有很多重复的信息。

2. 雪花模型

当一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的"层次"区域，这些被分解的表都连接到主维表而不是事实表。
其优点是通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能，避免了数据冗余。其缺点是增加了主键-外键关联的几率，导致查询效率低于星型模型，并且不利于开发。

3. 星座模型

星座模型也是星型模型的扩展。区别是星座模型中存在多张事实表，不同事实表之间共享维表信息，常用于数据关系更复杂的场景。其经常被称为星系模型。

4. 对比

4.1 查询性能角度来看

在OLTP-DW环节，由于雪花型要做多个表联接，性能会低于星型架构；但从DW-OLAP环节，由于雪花型架构更有利于度量值的聚合，因此性能要高于星型架构。

4.2 模型复杂度角度

星型架构更简单方便处理

4.3 层次结构角度

雪花型架构更加贴近OLTP系统的结构，比较符合业务逻辑，层次比较清晰。

4.4 存储角度

雪花型架构具有关系数据模型的所有优点，不会产生冗余数据，而相比之下星型架构会产生数据冗余

属性	星型模型（星座模型）	雪花模型
事实表	1张或多张	1张或多张
维度表	一级维表	多层级维表
数据总量	多	少
数据冗余度	高	低
可读性	高	低
表个数	少	多
表宽度	宽	窄
查询逻辑	简单	复杂
查询性能	高	低
扩展性	差	好

5. 总结

通过上面的对比分析，可以发现数据仓库更适合使用星型模型来构建底层数据 hive 表，通过数据冗余来减少查询次数以提高查询效率。雪花模型在关系型数据库中（MySQL/Oracle）更加常见。在具体规划设计时，应结合具体场景及两者的优缺点来进行设计，找到一个平衡点去开展工作。

根据项目经验，一般建议使用星型模型。因为在实际项目中，往往最关注的是查询性能问题，至于磁盘空间一般都不是问题。当然，在维度表数据量极大，需要节省存储空间的情况下，或者是业务逻辑比较复杂、必须要体现清晰的层次概念情况下，可以使用雪花型模型。