用户与订单之间的关系_数仓理论--关系建模与维度建模

一、OLTP与OLAP

当今的数据处理大致可以分成两大类：联机事务处理OLTP（on-linetransaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。

OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。二者的主要区别对比如下表所示。

二、关系模型与维度模型

关系模型严格遵循第三范式（3NF），较松散零碎，物理表数量多，数据冗余程度低。由于数据分布于众多的表中，这些数据可以更为灵活地被应用，功能性较强。主要应用于OLTP系统中，保证数据的一致性以及避免冗余，所以大部分业务系统的表都遵循第三范式。

维度模型主要应用于OLAP系统中，通常以某一个事实表为中心进行表的组织，主要面向业务，特征是可能存在数据的冗余，但是能方便的得到数据。

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

三、维度建模

在维度建模的基础上又分为3种模型：星型模型，雪花模型，星座模型。

（1）星型模型

标准的星型模型维度只有一层，而雪花模型可能会涉及多级，维度层级 是雪花模型与星型模型的主要区别。

（2）雪花模型

雪花模型，比较接近3NF，但是无法完全遵循，因为遵循3NF的性能成本太高。

（3）星座模型

星座模型与前两种情况的区别是事实表的数量，星座模型是基于多个事实表。

基本上是很多数据仓库的常态，因为很多数据仓库都是多个事实表。所以是否星座只反应是否有多个事实表，它们之间是否共享一些维度表。星座模型不和前两种模型冲突。

（4）模型的选择

星型还是雪花，取决于性能优先，还是灵活更优先。企业实际开发中，不会绝对选择一种，可以灵活组合，但整体来看，更倾向于维度更少的星型模型。尤其是Hadoop体系，减少Join就是减少Shuffle，性能差距很大。

四、维度表和事实表

（1）维度表：一般是对事实的描述信息。每一张维度表对应现实世界中的一个对象或者概念。例如：用户、商品、日期、地区等。

维度表的特征：

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

设计维表的主要步骤如下：

1. 选择业务过程：选择感兴趣的业务线：如下单，支付，退款，活动 ；时间允许可以选择全部业务线。
2. 声明粒度：一行代表信息：一条订单？一天的订单？一周的订单？ 选择最小粒度
3. 确认维度：维度退化：谁 。 什么时间 什么地点
4. 确认事实：度量值：如个数，件数，金额

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

每一个事实表的行包括：具有可加性的数值型的度量值、与维度表相连接的外键、通常具有两个及以上外键。

事实表的特征：

• 非常的大
• 内容相对的窄
• 经常发生变化，每天新增很多。

五、事实表还可以被分为三种

（1）事务型事实表

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

（2）周期型快照事实表

周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，以具有规律性的、可预见的时间间隔记录事实。例如每天或每月的总销售金额，或每月的账户余额等。

（3）累积型快照事实表

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