回顾数据仓库建模流程

data-sun

已于 2023-09-06 19:27:41 修改

阅读量207

点赞数 2

文章标签：数据仓库

于 2023-09-05 23:43:00 首次发布

本文链接：https://blog.csdn.net/m0_54501766/article/details/132701270

版权

建模意义

为什么要建数据仓库，有什么意义？

将数据有序组织和存储，使数据得到高性能，低成本，高效率，高质量的使用

实际就是为了方便我们在处理数据时能更快的找到和运行计算出我们需要的结果

建模方法论

ER模型
维度模型

ER模型

理论：用实体关系模型来描述企业业务，用规范化的方式表示出来，在范式理论上符合3NF

那么什么是实体关系模型呢？

其实就是把数据抽象成两个概念：实体 & 关系

实体就是对象，和java中的概念一致，例如：学生，班级...

关系就是实体（对象）之间的关系，例如学生和班级之间的从属关系

什么是规范化呢？范式理论又是什么？所谓3NF到底是什么标准？

这里就引入范式的概念，其实就是概念上对数据划分的一个一个标准，目的是减少数据冗余，增强数据一致性（但这后面也导致了表的过度分散）

关系型数据库的范式一共有6种:

第一范式
第二范式
第三范式
巴斯科德范式
第四范式
第五范

为了解释这些范式，就又提出了几个新概念

完全函数依赖
部分函数依赖
传递函数依赖

举例说明：

小明的学号是001，他是的，系主任叫老明，高数成绩是100分

完全函数依赖就是一张表内容是学号:001,学科：高数，成绩：100分

我们只有拿学号和学科才能推出成绩，缺少学号,或者缺少学科我们都无法推出成绩，所以成绩完全依赖于学号和学科

部分函数依赖举例表：学号:001,姓名：小明，学科：高数

我们拿学号和学科可以推出姓名，但实际上我们只用学号就能推出姓名，所以姓名部分依赖于学号和学科

传递函数依赖举例表：学号：001，姓名：小明，二级学院：数智院，系主任：老明

我们拿学号可以推出二级学院，拿二级学院可以推出系主任，但是，系主任推不出学号，他主要依赖二级学院，这样就可以说系主任传递依赖于学号

理解这些依赖关系就可以解释三大范式了

第一范式：属性不可切割

每个列中不能存在叠合的关系，例如商品列中写5台电脑，就要分为商品和数量两列

第二范式：不能存在部分函数依赖

假如一张表有

学号，姓名，系名，系主任，课程名，分数

我们就要将其拆分为两张表，一张表为学号，课程名，分数，另一张表为系名，系主任

第三范式：不能存在传递函数依赖

假如有一张表：

学号，姓名，系名，系主任

我们要将其拆分为两张表，一张：学号，姓名，系名，另一张：系名，系主任

结论

这些范式规则的确帮助我们解决了表中的数据冗余问题，但是也带来了新的问题，表与表之间松散零碎，且产生了大量的表，这让我们的计算会越来越复杂要联系很多很多的表。

维度模型

概念：分为了事实和维度两个概念

可以理解为业务过程和环境概念

例如：下单这个业务过程，可以算做一个事实，而下单的时间，下单的用户，下单的商品等等等都可以算作环境也就是维度的概念

唯独模型是在ER模型基础上改进得到的，保留了一部分数据冗余，但更符合我们实际开发，仔细想想过多的表，松散的结构，我们在ｈｉｖｅ中分析时，ｊｏｉｎ过程或多或少会有ｓｈｕｆｆｌｅ的过程，严重拖慢我们的计算任务。维度模型付出更多的存储空间但也带来了更快的计算。

了解完两大模型，我们挑选出了维度模型来生产开发，接下来我们要对其中再深入一些

事实表

概念：事实表是我们建模的核心，以业务过程来设计。他的核心时与该业务过程有关的维度引用（维度表外键）和该业务的度量（通常是可累加的数字类型字段）

特点：细长，行多，列少，行的增速快

分类:事物事实表，周期快照事实表，累计快照事实表

一.事务性事实表

术语：最细粒度的操作事件

理解：最细的一层操作业务

设计流程

选择业务过程→声明粒度→确认维度→确认事实

1.选择业务过程

选择工作需要的业务过程（一个个不可拆分的行为事件），例如电商交易中的下单，取消订单，付款，退单等，都是业务过程

2.声明粒度

精确定义每张事务型事实表的每行数据表示什么，应该尽可能选择最细粒度，以此来应各种细节程度的需求

ｅｇ：订单事实表中一行数据表示的是一个订单中的一个商品项

3.确认维度

确定与每张事务型事实表相关的维度有哪些，尽量多的选择与业务过程相关的环境信息。因为维度的丰富程度就决定了维度模型能够支持的指标丰富程度

4.确认事实

其实就是度量值，或者说一个可以反应这个业务过程的总结，例如件数，金额．．．

缺陷

这样定性看来，事务性事实表划分的很细，这就导致在遇到某些特定类型的需求，其逻辑可能会比较复杂，或者效率会比较低下。

ｅｇ：存量型指标、多事物关联统计

存量型指标

例如平台虚拟货币，以事务性事实表的话我们会设立两张表，一张是获取货币，一张是消耗货币，当我们被要求统计截至当日的各用户虚拟货币余额时，我们就要将两张表进行聚合，不论是从逻辑上还是效率上考虑，这都不是一个好的方案

多事物关联统计

现在有个需求：统计最近30天，用户下单到支付的时间间隔的平均值

怎么做呢？统计思路应该是找到下单事务事实表和支付事务事实表，过滤出最近30天的记录，然后按照订单id对两张事实表进行关联，之后用支付时间减去下单时间，然后再求平均值。

听起来就是关联两列相减再取平均值，但是实际开发中，下单事务事实表和支付事务事实表两表都是大表，这样ｊｏｉｎ时（ｓｈｕｆｆｌｅ）的时间是很长的，严重影响工作效率。

所以我们引出了另外类型的两种事实表来完善。

二.周期性快照事物表

定义：以具有规律性的、可预见的时间间隔来记录事实

理解：隔一段时间计算保存一份结果到数据仓库，这样在下次计算时，能够减少一些计算任务。

设计流程

确认粒度→确认事实

1.确认粒度

实际就是选择多久统计一次, 大部分是每日一次

2.确认事实

统计的业务，如指标为统计每个仓库中每种商品的库存，则事实为商品库存。这里的事实类型是指度量值的类型，分为：可加事实，半可加事实，不可加事实

可加事实

可以按照与事实表相关的所有维度进行累加，例如事务型事实表中的事实

半可加事实

只能按照与事实表相关的一部分维度进行累加，例如周期型快照事实表中的事实

ｅｇ：各仓库中各商品的库存每天快照事实表为例，这张表中的库存事实可以按照仓库或者商品维度进行累加，但是不能按照时间维度进行累加，因为将每天的库存累加起来是没有任何意义的

不可加事实

完全不具备可加性，例如比率型事实。不可加事实通常需要转化为可加事实，例如比率可转化为分子和分母

三.累计快照事实表

概念:基于一个业务流程中的多个关键业务过程联合处理而构建的事实表,例如交易流程中的下单,支付,发货,确认收货.累计型快照事实表通常有多个日期字段,每个日期字段对应一个过程.我们这里可以把业务过程称作里程碑.

用处:主要用于分析业务过程之间的时间间隔等需求.例如上面引文中的用户下单到支付的时间间隔的平均值

设计流程:选择业务过程→声明粒度→确认维度→确认事实

1.选择业务过程

选择目标流程中的多个业务过程

2.声明粒度

确定每行数据表示的是什么,选择最小粒度

3.确认维度

选择与业务过程相关的维度,每个业务过程需要一个日期维度

4.确认事实

选择各业务过程的度量值

按照我的理解来总结一下这三个事实表,事务性事实表就是普通的描述一个过程的事实表,里面有度量值和维度(环境)相关的id,能够解决大部分要求,但是由于划分的比较细,导致我们在处理一些存量型数据,多事务关联统计型的问题时没办法高效率的解决,所以引出了周期性快照事务表和累计快照事实表,这两张表分别用来解决上述两种问题.既然我事务性事实表在处理存量型(拿虚拟货币举例)时又要对单个表从头求总额,又要联立两张再聚合计算,那不如我每天算一次,将结果保存到hdfs相应目录里,等到我哪天要用了,我就把昨天的结果拿出来,再把今天发生的带上计算,这样我就省去了从头求到昨天的历史了;同理对于多事务关联统计型问题,如果我用事务性事实表,我要对两表来联立计算,那不如我直接给你俩放一张表,这样我每次工作的时候就不用再联立你俩了,毕竟联立join的shuffle过程非常花时间,一个业务流程我给你算一张表,那样我就省去了自己去联立的逻辑和时间,方便了我的工作.事务性事实表能够解决所有问题,但是对于某些优化不太好,所以在优化的目的下提出周期性快照事务表,累积性快照事实表.