一篇文章搞懂数据仓库:三种事实表(设计原则,设计方法、对比)

事实表作为数据仓库维度建模的核心,紧紧围绕着业务过程来设 计,通过获取描述业务过程的度量来表达业务过程,包含了引用的维度 和与业务过程有关的度量。

1、三种事实表概述

=============

事实表有三种类型 : 事务事实表、周期快照事实表累积快照事实表

  • 1.1 事务事实表

也称原子事实表,描述业务过程,跟踪控件或时间上某点的度量事件,保存的是最原子的数据;

个人理解:类似于mysql binlog日志,每一次相关的 change 都记录下来,生成一行新的数据

  • 1.2 周期快照事实表

以一个周期为时间间隔,来记录事实,一般周期可以是每天、每周、每月、每年等;

个人理解:只看某个业务过程,比如订单收货,数据按订单收货时间来切分,周期可以为每天、每月等。

  • 1.3 累积快照事实

用来描述过程开始和结束之间的关键步骤事件,覆盖过程的整个生命周期,通常具有多个日期字段来记录关键时间点;当过程随着生命周期不断变化时,记录也会随着过程的变化而被修改;

个人理解:要看整个生命周期的多个业务过程,比如:创建订单 → 买家付款 → 卖家发货 → 买家确认收货。粒度是一个订单一行数据,创建订单时间,付款时间,发货时间,收货时间,分别作为一个字段,便于计算不同业务过程的时间间隔。

2、三种事实表对比

=========

 事务事实表 周期快照事实表 累积快照事实表 
时期/时间 离散事务时间点 以有规律的、可预测的 用于时间跨度不确定的不断变化的工作流 
日期维度 事务日期 快照日期 相关业务过程涉及的多个日期 
粒度每行代表实体的一个事务 每行代表某时间周期的一个实体 每行代表一个实体的生命周期 
事实 事务事实累积事实相关业务过程事实和时间间隔事实 
事实表加载 插入 插入 插入与更新 
事实表更新 不更新 不更新 业务过程变更时更新 

3、事实表设计 8 大原则

=============

  • 原则 1:尽可能包含所有与业务过程相关的事实

  • 分析哪些事实与业务过程相关,是设计过程中非常重要的关注点;

  • 在事实表中,尽量包含所有与业务过程相关的事实,即使存在冗余,由于事实通常是数字型,存储开销不会太大;

  • 原则 2:只选择与业务过程相关的事实

  • 如,订单的下单这个业务过程,事实表中不应该存在支付金额这个表示支付业务过程的事实;

  • 原则 3:分解不可加性事实为可加的组件

  • 如,订单的优惠率,应分解为订单原价金额与订单优惠金额两个事实存储在事实表中;

  • 原则 4:在选择维度和事实之前必须先声明粒度

  • 粒度用于确定事实表中一行所表示业务的细节层次,决定了维度模型的扩展性;

  • 每个维度和事实必须与所定义的粒度保持一致;

  • 设计事实表时,粒度定义越细越好,一般从最低级别的原子粒度开始;

  • 因为原子粒度提供了最大限度的灵活性,可以支持无法预期的各种细节层次的用户需求;

  • 原则 5:在同一个事实表中不能有多种不同粒度的事实

  • 疑问:怎么判断不同事实的粒度是否相同?

  • 粒度为票一级;(实际业务中,一个订单可以同时支付多张票)

  • 票支付金额和票折扣金额,两个事实的粒度为 “票级”,与定义的粒度一致;

  • 订单支付金额和订单票数,两个事实的粒度为 “订单级”,属于上一层订单级数据,与 “票级” 事实表的粒度不一致,且不能进行汇总;

  • 如果,以订单金额和订单票数这两个维度汇总总金额和总票数,会造成大量的重复计算;

  • 原则 6:事实的单位要保持一致

  • 如,订单金额、订单优惠金额、订单运费这 3 个事实,应该采用统一的计量单位,统一为元或者分,以方便使用;

  • 原则 7:对事实的 null 值要处理

  • 原因:在数据库中,null 值对常用数字型字段的 SQL 过滤条件都不生效;如,大于、小于、等于、大于或等于、小于或等于;

  • 处理:用 0 代替 null ;

  • 原则 8:使用退化维度提高事实表的易用性

  1. 事实表中存储各种类型的常用维度信息,较少下游用户使用时关联多个表的操作;

  2. 通过退化维度,可以实现对事实表的过滤查询、控制聚合层次、排序数据、定义主从关系等;

  • 易用性:对事实表,更较少关联操作、过滤查询、控制聚合层次、排序数据、定义主从关系等;

  • 在 Kimball 的维度建模中,通常按照星形模型的方式设计,通过事实表的外键关联专门的维表,这种方式来获取维度,谨慎使用退化维表;这与大数据领域的事实表设计不一样;

  • 思路:通过增加冗余存储,减少计算开销,提高使用效率;

4、事实表设计方法

=========

Kimball 的维度模型设计 4 步法:选择业务过程、声明粒度、确定维度、确定事实;

当前的互联网大数据环境,维度模型的设计,是基于 Kimball 的四步维度建模方法进行了更进一步的改进:

  • 第一步:选择业务过程及确定事实表类型

  • 思路:详细分析需求,对业务的整个生命周期进行分析,明确关键的业务步骤,从而选择与需求有关的业务过程;

  • 以实例说明:如何选择业务过程?如何确定事实表类型?

  • 例:淘宝的一个交易订单

  1. 分析业务的生命周期:如上图,业务过程通常使用行为动词表示业务执行的活动

  2. 明确关键的业务步骤:该订单流转的业务过程有 4 个:创建订单 → 买家付款 → 卖家发货 → 买家确认收货;

  3. 根据业务需求,选择与维度建模有关的业务过程;
    自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数Python工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!

因此收集整理了一份《2024年Python开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。

img

img

img

img

img

img

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上前端开发知识点,真正体系化!

由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新

如果你觉得这些内容对你有帮助,可以扫码获取!!!(备注Python)

79.png)

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上前端开发知识点,真正体系化!

由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新

如果你觉得这些内容对你有帮助,可以扫码获取!!!(备注Python)

img
  • 22
    点赞
  • 13
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
数据仓库中的宽表和汇总表是数据仓库中非常重要的两个表。下面我向您介绍一下它们的设计方法: 1. 宽表设计方法 宽表是指包含了多个数据源(表)中的所有数据的一张表。它能够提高数据查询的效率,避免了多表关联查询的过程,同时也能够方便数据分析师进行数据建模、分析和报表制作。宽表的设计方法如下: - 根据业务需求,选择需要加入宽表的数据源,包括数据源的字段、数据类型等。 - 将各个数据源的数据合并到一张表中,通过一些特定的字段进行关联,如日期、地点、产品等。 - 对宽表进行必要的数据清洗和转换,包括数据类型的转换、数据格式的规范化、空值处理等。 - 对宽表进行能优化,包括数据压缩、数据分区、索引等操作,提高查询效率。 2. 汇总表设计方法 汇总表是指在数据仓库中,把细节数据按照一定的规则聚合起来的一张表,通常是根据不同的维度进行聚合。汇总表的设计方法如下: - 根据业务需求,确定需要聚合的指标和维度。 - 对每个维度,定义需要聚合的指标和聚合方式,如求和、平均数、最大值、最小值等。 - 对于聚合结果,根据业务需求,可以设计多个汇总表,包括日、周、月、季度、年等不同的时间粒度表。 - 对汇总表进行必要的数据清洗和转换,包括数据类型的转换、数据格式的规范化、空值处理等。 - 对汇总表进行能优化,包括数据压缩、数据分区、索引等操作,提高查询效率。 总之,数据仓库中的宽表和汇总表设计方法,需要根据具体的业务需求和数据特征进行设计和优化,以提高数据仓库的数据查询效率和数据分析的准确

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值