一篇文章搞懂数据仓库:三种事实表(设计原则,设计方法、对比)
目录
1、三种事实表概述
2、三种事实表对比
3、事实表设计 8 大原则
4、事实表设计方法
第一步:选择业务过程及确定事实表类型
第二步:声明粒度
第三步:确定维度
第四步:确定事实
事实表作为数据仓库维度建模的核心,紧紧围绕着业务过程来设 计,通过获取描述业务过程的度量来表达业务过程,包含了引用的维度 和与业务过程有关的度量。
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:使用退化维度提高事实表的易用性
- 事实表中存储各种类型的常用维度信息,较少下游用户使用时关联多个表的操作;
- 通过退化维度,可以实现对事实表的过滤查询、控制聚合层次、排序数据、定义主从关系等;
- 易用性:对事实表,更较少关联操作、过滤查询、控制聚合层次、排序数据、定义主从关系等;
- 在 Kimball 的维度建模中,通常按照星形模型的方式设计,通过事实表的外键关联专门的维表,这种方式来获取维度,谨慎使用退化维表;这与大数据领域的事实表设计不一样;
- 思路:通过增加冗余存储,减少计算开销,提高使用效率;
4、事实表设计方法
Kimball 的维度模型设计 4 步法:选择业务过程、声明粒度、确定维度、确定事实;
当前的互联网大数据环境,维度模型的设计,是基于 Kimball 的四步维度建模方法进行了更进一步的改进:
第一步:选择业务过程及确定事实表类型
- 思路:详细分析需求,对业务的整个生命周期进行分析,明确关键的业务步骤,从而选择与需求有关的业务过程;
- 以实例说明:如何选择业务过程?如何确定事实表类型?
- 例:淘宝的一个交易订单
-
- 分析业务的生命周期:如上图,业务过程通常使用行为动词表示业务执行的活动;
- 明确关键的业务步骤:该订单流转的业务过程有 4 个:创建订单 → 买家付款 → 卖家发货 → 买家确认收货;
- 根据业务需求,选择与维度建模有关的业务过程;
- 如,是选择 “买家付款” 这个业务过程,还是选择 “创建订单” 和 “买家付款” 这两个业务过程,具体根据业务情况来定;
- 根据所选的业务过程确定事实表类型;
- 如,选择 “买家付款” 这个业务过程,则事实表类型应为只包含买家付款这一个业务过程的 “单事务事实表”;
- 如,选择了所有 4 个业务过程,并且需要分享各业务过程的时间间隔,则事实表类型应为包含了所有 4 个业务过程的 “累积快照事实表”;
第二步:声明粒度
- 粒度的作用:
- 粒度的声明,意味着精确定义事实表的每一行所表示的业务含义;
- 明确的粒度能够确保对实表中行的意思的理解不会产生混淆,保证所有的事实按照同样的细节层次记录;
- 粒度的选择:尽量选择最细级别的原子粒度,以确保事实表的应用具有最大的灵活性;
- 灵活性:支持无法预期的各种细节层次的用户需求;
- 对于订单级别,粒度可以定义为最细的订单级别;(如,父子订单,事实表的粒度可以定 “子订单级别” ;)
- 粒度的作用:
第三步:确定维度
- 完成了粒度声明,就意味着确定了主键,对应的维度组合以及相关的维度字段也可以确定了;
- 选择维度的原则:应该选择能够描述清楚业务过程所处的环境的维度信息;
- 如,淘宝订单 “付款事务事实表” 中,粒度为 “子订单”,相关的维度有买家、卖家、商品、收货人信息、业务类型、订单时间等;
第四步:确定事实
- 确定原则:选择与业务过程有关的所有事实,且事实的粒度要与所声明的事实表的粒度一致;
- 思路:可以通过回答 “过程的度量是什么” 来确定;
- 注意:将不可加性事实分解为可加的组件;(分解的原则:可以通过分解后的可加的属性值,计算得到不可加性事实)
汇总图:
参考文献:阿里巴巴大数据之路
整理不易,点个赞吧~
一篇文章搞懂数据仓库:三种事实表(设计原则,设计方法、对比)相关推荐
- 一篇文章搞懂数据仓库:维度表(设计原则、设计方法)
目录 1.什么是维度表? 2.维度表设计原则 (1)维度属性尽量丰富,为数据使用打下基础 (2)给出详实的.富有意义的文字描述 (3)区分数值型属性和事实 (4)沉淀出通用的维度属性,为建立一致性维度 ...
- 一篇文章搞懂数据仓库:数据应用--OLAP
目录 1.OLAP和OLTP的区别 2.OLAP分类 3.OLAP基本操作 4.OLAP选型 1.olap和oltp的区别 OLTP OLAP 对象 业务开发人员 分析决策人员 功能 日常事务处理 面 ...
- 一篇文章搞懂数据仓库:三范式与反范式
少年易老学难成,一寸光阴不可轻. 目录 一.第一范式 二.第二范式 三.第三范式 四.反范式化 五.范式化设计和反范式化设计的优缺点 5.1 范式化 (时间换空间) 5.2 反范式化(空间换时间) 六 ...
- 一篇文章搞懂数据仓库:常用ETL工具、方法
目录 一.什么是ETL? 二.ETL & ELT 三.常用的ETL工具 3.1 sqoop 3.2 DataX 3.3 Kettle 3.4 canal 3.5 StreamSets 四.ET ...
- 一篇文章搞懂数据仓库:数据仓库架构-Lambda和Kappa对比
在介绍Lambda和Kappa架构之前,我们先回顾一下数据仓库的发展历程: 传送门-数据仓库发展历程 写在前面 咳,随着数据量的暴增和数据实时性要求越来越高,以及大数据技术的发展驱动企业不断升级迭代, ...
- 一篇文章搞懂数据仓库:数据仓库规范设计
目录 一.为什么要进行规范设计? 二.设计规范 - 指标 三.命名规范 - 表命名 3.1 常规表 3.2 中间表 3.3 临时表 3.4 维度表 四.开发规范 五.流程规范 一.为什么要进行规范设计 ...
- c++ 计算正弦的近似值_一篇文章搞懂正弦保真性
本文介绍数字信号处理中"正弦保真性"这一概念,想要更好地理解本文所述内容,建议读者先阅读<一篇文章搞懂卷积>. 正弦保真性定义 一个正弦信号作为线性时不变系统的输入时, ...
- 一篇文章搞懂filebeat(ELK)
一篇文章搞懂filebeat(ELK) https://www.cnblogs.com/zsql/p/13137833.html 目录 一.filebeat是什么 1.1.filebeat和beats ...
- 【一篇文章搞懂】什么是分布式锁?为什么要用分布式锁?看这篇文章准没错!
简介 HikariCP 是用于创建和管理连接,利用"池"的方式复用连接减少资源开销,和其他数据源一样,也具有连接数控制.连接可靠性测试.连接泄露控制.缓存语句等功能,另外,和 dr ...
- 一篇文章搞懂架构师的核心技能
" 这是架构师系列的第一篇:核心技能,希望这个系列能完全揭示架构师这个职位:我先从核心技能开始,后续还有架构师之路,架构实战等架构师系列文章. 本文作者 陈睿 优知学院创始人,前携程定制旅游 ...
最新文章
- linux系统打包工具,Linux 压缩、解压缩和打包工具
- 学习区块链的十大理由
- Protobuf 安装及 Python、C# 示例
- ffmpeg 和 SDL 教程2:输出到屏幕
- SQLite学习手册(内置函数)
- Python之PIL库的运用、GIF处理h
- Redux有何优点?
- 遗传相似系数怎么计算_如何计算遗传变异系数
- 北大青鸟广州天河:最喜欢微软的10件事(二)
- VS Code快捷生成用户代码片段操作,以vue为例
- Un*、IdL分别突变情况下双闭环直流调速系统仿真
- STM32F107+LWIP+FreeRTOS
- 你听过“费斯汀格法则”吗?多少人因为不懂而被残害!好文!
- Ubuntu18.04手动安装Realtek网卡驱动
- 2021-06-07
- 川大和哈工大计算机学院,哈尔滨工业大学计算机科学与技术学院
- [USACO2.1]Healthy Holsteins 健康的荷斯坦奶牛 题解(DFS/BFS详解)
- Kafka 中 AR、ISR、OSR 是什么?ISR 的伸缩性什么?
- 业务中立_网络中立性的终结了吗?
- Windows10搭建ASP服务器