维度建模方法总结

维度建模方法总结

一、ER模型

1.1、实体关系模型

实体关系模型将复杂的数据抽象为两个概念——实体和关系。实体表示的是一个对象，例如学生、班级，关系是指两个实体之间的关系，例如学生和班级之间的从属关系。

1.2、三范式

1.2.1、函数依赖

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

1.2.2、第一范式

第一范式1NF的核心原则：属性不可切割

1.2.3、第二范式

第二范式2NF核心原则：不能存在部分函数依赖

1.2.4、第三范式

第三范式3NF核心原则：不能存在传递依赖

二、维度建模

	维度模型将复杂的业务通过事实和维度两个挂念进行呈现。事实通常对应业务过程，而维度通常对应业务过程发生时所处的环境。
	业务过程可以概括为一个个不可拆分的行为事件，例如电商交易中的下单，取消订单，付款，退单等。

2.1、事实表

	事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计。其包含与该业务过程有关的维度引用（维度表外键）以及该业务过程的度量（通常是可累加的数字类型字段）。

2.1.1、事实表特点

	事实表通常比较细长，即列比较少，但行多，且行的增速快

2.1.2、事实表分类

	事实表有三种类型：分别是事务型事实表、周期快照事实表和累加快照事实表，每种事实表都具有不同的特点和适用场景。

2.1.3、事务型事实表

1、概述
	事务型事实表用来记录各个业务过程，他保存的是各个业务过程的原子操作事实，即最细粒度的操作事件。粒度是指事实表中一行数据所表达的业务细节程度。
2、设计流程
	选择业务过程->声明粒度->确认维度->确认事实
	2.1、选择业务过程
		在业务系统中，挑选感兴趣的业务过程，业务过程可以概括为一个个不可拆分的行为事件，例如：下单、取消订单、付款、退单等。通常一个业务过程对应一张事务型事实表。
	2.2、声明粒度
		业务过程确定后，需要为每个业务过程声明粒度，即精确定义每张事务型事实表的每行数据表示什么。例如：
		订单事实表中一行数据表示的是一个订单中的一个商品项。
	2.3、确定维度
		确定维度具体是指，确定与每张事务型事实表相关的维度有哪些。
		应尽量选择与业务过程相关的环境信息，维度的丰富程度决定了维度模型能够支持的指标丰富程度。
	2.4、确定事实
		此处事实一词，指的是每个业务过程的度量值（通常是可累加的数字类型的值，例如：次数、个数、件数、金额）
	第一步选择业务过程可以确定有哪些事务型事实表，第二步可以确定每张事务型事实表的每行数据是什么，第三步可以确定每张事务型事实表的维度外键，第四步可以确定每张事务型事实表的度量值字段。
3、不足
	事务型事实表可以保存所有业务过程的最细粒度的操作事件，故理论上可以支撑与各个业务过程相关的各种统计粒度的需求。但是对于某些特点类型的需求，其逻辑可能会比较复杂或是效率比较低下。例如：
	3.1、存量型指标
		例：以虚拟货币为例，虚拟货币业务包含的业务过程主要包括获取货币和使用货币，两个业务过程各自对应一张事务型事实表，一张存储所有的获取货币的原子操作事件，另一张存储所有的使用货币的原子操作事件。
		如果想要统计截止当日的各用户虚拟货币余额。由于获取货币和使用货币均会影响到余额，故需要对两张事务型事实表进行聚合，且需要区分两者对余额的影响（加或减），另外需要对两张表的全表数据聚合才能得到统计结果。
	3.2、多事务关联统计
		例：现需要统计近30天，用户下单到支付的时间间隔的平均值。统计思路应该是找到下单事务事实表和支付事务事实表，过滤出近30天的记录，然后按照订单id对两张表进行关联，之后用支付时间减去下单时间，然后求平均值。
		但是两张事实表都为大表，大表join大表的操作应尽量避免。

2.1.4、周期型快照事实表

1、概述
	周期快照事实表一具有规律性的、可预见的时间间隔来记录事实，主要用于分析一些存量型（例如商品库存、账户余额）或状态型（空气温度、行驶速度）指标。
	对于商品库存、账户余额这些存量型指标，业务系统中通常会计算并保存最新结果，所以定期同步一份全量数据到数据仓库，构建周期型快照事实表，就能轻松应对此类统计需求，而无需再对事务型事实表中大量的历史记录进行聚合。
	对于空气温度、行驶速度这些状态型指标，由于他们的值往往是连续的，我们无法捕获其变动的原子事务操作，所以无法使用事务型事实表统计此类需求，而只能定期对其进行采样，构建周期型快照事实表。
2、设计流程
	2.1、确定粒度
		周期型快照事实表的粒度可由采样周期和维度描述，故确定采集周期和维度后即可确定粒度。
		采样周期通常选择每日。
		维度可根据统计指标决定，例如指标为统计每个仓库中每种商品的库存，则可确定维度为仓库和商品。
		确定完采样周期和维度后，即可确定该表粒度为每日-仓库-商品。
	2.2、确认事实
		事实可根据统计指标决定，例如指标为每个仓库中每种商品的库存，则事实为商品库存。
3、事实类型
	此处事实类型是指度量值的类型，而非事实表的类型。事实（度量值）共分为三类，分别是可加事实，半可加事实和不可加事实。
	3.1、可加事实
		可加事实是指可以按照与事实表相关的所有维度进行累加，例如事务型事实表中的事实。
	3.2、半可加事实
		半可加事实是指只能按照与事实表相关的一部分维度进行累加，例如周期型快照事实表中的事实。以上述各仓库中各商品每天的库存的快照事实表为例，这张表中的库存事实可以按照仓库或者商品维度进行累加，但是不能按照时间维度进行累加，因为将每天的库存累加起来是没有任何意义的。
	3.3、不可加事实
		不可加事实是指完全不具备可加性，例如比率型事实。不可加事实通常需要转化为可加事实，例如比率可转化为分子和分母。

2.1.5、累积型快照事实表

1、概述
	累计快照事实表是基于一个业务流程中的多个关键业务过程联合处理而构建的事实表，如交易流程中的下单、支付、发货、确认收货业务过程。
	累计型快照事实表通常具有多个日期字段，每个日期对应业务流程中的一个关键业务过程。
	累计型快照事实表主要用于分析业务过程之间的时间间隔等需求。例如用户下单到支付的平均时间间隔，使用累计型快照事实表进行统计，就能避免两个事务事实表的关联操作，从而变得十分简单高效。
2、设计流程
	选择业务过程->声明粒度->确认维度->确认事实
	2.1、选择业务过程
		选择一个业务流程中需要关联分析的多个关键业务过程，多个业务过程对应一张累计型快照事实表。
	2.2、声明粒度
		精确定义每行数据表示的是什么，尽量选择最小粒度。
	2.3、确认维度
		选择与各业务过程相关的维度，需要注意的是，每个业务过程均需要一个日期维度。
	2.4、确认事实
		选择各业务过程的度量值。

2.2、维度表

	维度表是维度建模的基础和灵魂。事实表紧紧围绕业务过程进行设计，而维度表则围绕业务过程所处的环境进行设计。维度表主要包含一个主键和各种维度字段，维度字段称为维度属性。

2.2.1、维度表设计步骤

1、确定维度
	在设计事实表时，已经确定了与每个事实表相关的维度，理论上每个相关维度均需要对应一张维度表。但是可能存在多个事实表与同一个维度都相关的情况，这种情况需要保证维度的唯一性，即只创建一张维度表。另外，如果某些维度表的维度属性很少，只有一个名称，则可不创建该维度表，而把该表的维度属性直接增加到与之相关的事实表中，这个操作称为维度退化。
2、确定主维表和相关维表
	主维表和相关维表均指业务系统中与某维度相关的表。例如业务系统中与商品相关的表有sku_info（商品表），base_trademark（品牌表），base_category3（商品三级品类表），base_category2（商品二级品类表），base_category1（商品一级品类表）。其中sku_info称为商品维度的主维表，其余表称为商品维度的相关维表，维度表的粒度通常与主维表相同。
3、确定维度属性
	确定维度属性即确定维度表字段。维度属性主要来自于业务系统中与该维度对应的主维表和相关维表，维度属性可以直接从主维表或相关维表中选择，也可通过进一步加工得到。
	确定维度时需要遵循以下要求：
	3.1、尽可能生成丰富的维度属性
		维度属性是后续做分析统计时的查询约束条件、分组字段的基本来源，是数据易用性的关键。维度属性的丰富程度直接影响到数据模型能够支持的指标的丰富程度。
	3.2、尽量不使用编码，而使用明确的文字说明，一般可以编码和文字共存。
	3.3、尽量沉淀出通用的维度属性
		有些维度属性的获取需要进行比较复杂的逻辑处理，例如需要通过多个字段拼接得到。
		为避免后续每次使用时重复处理，可将这些维度属性沉淀到维度表中。

2.2.2、维度设计要点

1、规范化与反规范化
	规范化是指使用一系列范式设计数据库的过程，其目的是减少数据冗余，增强数据的一致性。通常情况下，规范化之后，一张表的字段会拆分到多张表。
	反规范化是指将多张表的数据冗余到一张表，其目的是减少join操作，提高查询性能。在设计维度表时，如果对其进行规范化，得到的维度模型称为雪花模型，如果对其进行反规范化，得到的模型称为星型模型。
	数据仓库系统的主要目的是用于数据分析和统计，所以是否方便用户进行统计分析决定了模型的优劣。采用雪花模型，用户在统计分析过程中需要大量的关联操作，使用复杂度高，同时查询性能很差，而采用星型模型，则方便、易用且性能好。所以出于易用性和性能考虑，维度表一般是很不规范化的。
2、维度变化
	维度属性通常不是静态的，而是会随时变化的，数据仓库的一个重要特点就是反映历史的变化，所以如何保存维度的历史状态是维度设计的重要工作之一。保存维度数据的历史状态，通常有以下两种做法，分别是全量快照表和拉链表。
	2.1、全量快照表
		离线数仓的计算周期通常为每天一次，所以可以每天保存一份全量的维度数据。
		优点：简单有效，开发和维护成本低，方便理解和使用。
		缺点：浪费存储空间，尤其是当数据的变化比例比较低时。
	2.2、拉链表
		拉链表的意义就在于能够更加高效的保存维度信息的历史状态。
		2.2.1、什么是拉链表
			拉链表可以记录每条信息的生命周期，一旦一条记录的生命周期结束，就重新开始一条新的记录，并把当前日期放入生效开始日期。
			如果当前信息至今有效，在生效结束日期中填入一个极大值（如9999-12-31）
		2.2.2、为什么要做拉链表
			拉链表适用于：数据会发生变化，但是变化频率并不高的维度（即缓慢变化）
		2.2.3、如何使用拉链表
			通过，生效开始日期<=某个日期 and 生效结束日期>=某个日期，能够得到某个时间点的数据全量切片。
3、多值维度
	如果事实表中一条记录在某个维度表中有多条记录与之对应，称为多值维度。例如，下单事实表中的一条记录为一个订单，一个订单可能包含多个商品，所以商品维度表中就可能有多条数据与之对应。
	针对这种情况，通常采用以下两种方案解决。
	第一种：降低事实表的粒度，例如将订单事实表的粒度由一个订单降低为一个订单中的一个商品项。
	第二种：在事实表中采用多字段保存多个维度值，每个字段保存一个维度id。这种方案只适用于多值维度个数固定的情况。
4、多值属性
	维度表中的某个属性同时有多个值，称为“多值属性”，例如商品维度的平台属性和销售属性，每个商品均有多个属性值。
	针对这种情况，通常可以采取以下两种方案。
	第一种：将多值属性放到一个字段，该字段内容为key1:value1，key2:value2，key3:value3的形式，例如一个手机商品的平台属性值为“品牌：华为，系统：鸿蒙，CPU：麒麟990”
	第二种：将多值属性放到多个字段，每个字段对应一个属性。这种方案只适用于多值属性个数固定的情况。