文章目录

一、数仓分层
二、范式理论
三、关系建模与维度建模
四、维度表和事实表
- 4.1 维度表
- 4.2 事实表
五、数据仓库建模
- 5.1 ODS层
- 5.2 DWD层
- 5.3 DWS层
- 5.4 DWT层
- 5.5 ADS层

一、数仓分层

在这里插入图片描述
数据仓库为什么要分层？

把复杂问题简单化：将复杂的任务分解成多层来完成，每一层只处理简单的任务，方便定位问题；
减少重复开发：规范数据分层，通过的中间层数据，能够减少极大的重复计算，增加一次计算结果的复用性；
隔离原始数据：不论是数据的异常还是数据的敏感性，使真实数据与统计数据解耦开。

数仓命名规范

层次	表命名规则
ODS层	ods表名
DWD层	dwd_dim/fact表名
DWS层	dws表名
DWS层	dws表名
ADS层	ads_表名
临时表	xxx_tmp
用户行为表	以log为后缀

脚本名称	脚本命名规则
基本脚本	数据源to目标_db/log.sh
用户行为脚本	以log为后缀
业务数据脚本	以db为后缀

二、范式理论

范式概念：

定义：设计一张数据表的表结构，符合的标准级别。规范和要求

优点：关系型数据库设计时，遵照一定的规范要求，目的在于降低数据的冗余性

缺点：范式的缺点是获取数据时，需要通过Join拼接出最后的数据

分类：目前业界范式有：第一范式、第二范式、第三范式、巴斯-科德范式、第四范式、第五范式

函数依赖：

函数依赖名称	说明
完全函数依赖	通过AB能得出C，但是AB单独得不出C，那么说C完全依赖于AB
部分函数依赖	通过AB能得出C，通过A也能得出C，或者通过B也能得出C，那么说C部分依赖于AB
传递函数依赖	通过A得到B，通过B得到C，但是C得不到A，那么说C传递依赖于A

三范式区分：

三范式名称	规定
第一范式（1NF）	属性不可切割
第二范式（2NF）	不能存在部分函数依赖
第三范式（3NF）	不能存在传递函数依赖

三、关系建模与维度建模

当今的数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。二者的主要区别对比如下表所示：

对比属性	OLTP	OLAP
读特性	每次查询只返回少量记录	对大量记录进行汇总
写特性	随机、低延时写入用户的输入	批量导入
使用场景	用户，Java EE项目	内部分析师，为决策提供支持
数据表征	最新数据状态	随时间变化的历史状态
数据规模	GB	TB到PB

① 关系建模
在这里插入图片描述
关系模型如图所示，严格遵循第三范式（3NF），从图中可以看出，较为松散、零碎，物理表数量多，而数据冗余程度低。由于数据分布于众多的表中，这些数据可以更为灵活地被应用，功能性较强。关系模型主要应用与OLTP系统中，为了保证数据的一致性以及避免冗余，所以大部分业务系统的表都是遵循第三范式的。

② 维度建模
在这里插入图片描述
维度模型如图所示，主要应用于OLAP系统中，通常以某一个事实表为中心进行表的组织，主要面向业务，特征是可能存在数据的冗余，但是能方便的得到数据。

关系模型虽然冗余少，但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这会大大降低执行效率。所以通常我们采用维度模型建模，把相关各种表整理成两种：事实表和维度表两种。

四、维度表和事实表

4.1 维度表

一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。

例如：用户、商品、日期、地区等。

维表的特征：

维表的范围很宽（具有多个属性、列比较多
跟事实表相比，行数相对较小：通常< 10万条
内容相对固定：编码表

4.2 事实表

事实表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。“事实”这个术语表示的是业务事件的度量值（可统计次数、个数、金额等），例如，订单事件中的下单金额。

每一个事实表的行包括：具有可加性的数值型的度量值、与维表相连接的外键、通常具有两个和两个以上的外键、外键之间表示维表之间多对多的关系。

事实表的特征：

非常的大
内容相对的窄；列数较少
经常发生变化，每天会新增加很多

① 事务型事实表

以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。

② 周期型快照事实表

周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，例如每天或者每月的销售额，或每月的账户余额等。

③ 累积型快照事实表

累计快照事实表用于跟踪业务事实的变化。例如，数据仓库中可能需要累积或者存储订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。

订单id	用户id	下单时间	打包时间	发货时间	签收时间	订单金额
		3-8	3-8	3-9	3-10

五、数据仓库建模

5.1 ODS层

保持数据原貌不做任何修改，起到备份数据的作用。
数据采用压缩，减少磁盘存储空间（例如：原始数据100G，可以压缩到10G左右）
创建分区表，防止后续的全表扫描

5.2 DWD层

DWD层需构建维度模型，一般采用星型模型，呈现的状态一般为星座模型。

维度建模一般按照以下四个步骤：选择业务过程→声明粒度→确认维度→确认事实

① 选择业务过程

在业务系统中，挑选需求的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。

② 声明粒度

数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。

声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。

典型的粒度声明如下：订单中，每个商品项作为下单事实表中的一行，粒度为每次下单；

每周的订单次数作为一行，粒度就是每周下单
每月的订单次数作为一行，粒度就是每月下单

③ 确定维度

维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。

④ 确定事实

此处的“事实”一词，指的是业务中的度量值，例如订单金额、下单次数等。

在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。
在这里插入图片描述

	时间	用户	地区	商品	优惠券	活动	度量值
订单	√	√	√			√	件数/金额
订单详情	√		√	√			件数/金额
支付	√		√				金额
加购	√	√		√			件数/金额
收藏	√	√		√			个数
评价	√	√		√			个数
退款	√	√		√			件数/金额
优惠券领用	√	√			√		个数