数据仓库工具箱—读书笔记02(Kimball维度建模技术概述02、事实表技术基础)

发布于:2024-12-19 ⋅ 阅读:(16) ⋅ 点赞:(0)

Kimball维度建模技术概述

记录一下读《数据仓库工具箱》时的思考,摘录一些书中关于维度建模比较重要的思想与大家分享🤣🤣🤣

在这里插入图片描述
第二章前言部分作者提到:技术的介绍应该通过涵盖各种行业的熟悉的用例展开(赞同哈哈 确实比抽象地讲解概念要好理解🤣🤣🤣)。

书中从第三章开始是通过各行业的用例去讲解维度建模,第二章则是维度建模技术的总体介绍(很多概念,挺抽象的🤣🤣🤣)。

前言部分作者也有提到:我们并不期望您一开始就从头到尾阅读本章,但希望您能将本章作为所提供的技术参考。本节介绍的技术,在所有维度设计工作中都需要考虑。本书的每一章几乎都会涉及本节所介绍的概念。

Kimball维度建模技术概述01、基本概念
书接上回~🤣🤣🤣🤣🤣🤣

2.2 事实表技术基础

2.2.1 事实表结构

  • 发生在现实世界中的操作型事件,其所产生的可度量数值存储在事实表中。
  • 事实表的设计完全依赖于物理活动,不受可能产生的最终报表的影响。

在这里插入图片描述

  1. 主键

    • 通常为复合主键,由多个外键组合,唯一标识一条记录(例如 订单ID + 产品ID。)。
  2. 外键

    • 连接维度表的字段,提供事实表记录的上下文(如时间ID、产品ID、客户ID)。
  3. 度量值

    • 存储可聚合的指标数据(如销售额、订单数量、库存量)。
  4. 粒度

    • 每条记录代表的业务事件或过程的最小单位(如每笔订单的每个商品)。
字段名 类型 描述
fact_id INT 主键
time_id INT 时间维度外键
product_id INT 产品维度外键
customer_id INT 客户维度外键
sales_amount DECIMAL 销售金额
sales_quantity INT 销售数量

Tip:事实表也可包含可选的退化维度键和日期/时间戳。(退化维度,在专栏里维度表技术基础里有讲~)


2.2.2 可加、半可加、不可加事实

事实表中的数字度量可划分为三类:

类别 定义 示例 适用场景 注意事项
可加事实 在所有维度上都可以直接求和的度量值。 销售金额、销售数量、成本 适用于跨时间、产品、客户等维度的总量分析。 无需额外计算逻辑,直接进行求和操作即可。
半可加事实 只能在某些维度上求和,而在其他维度(通常是时间维度)上不能求和。 库存量、账户余额、银行存款 时间快照、状态监控场景,例如监控某日的库存或余额状态。 时间维度上不能直接求和,需通过取最近值或计算变化量等方式分析。
不可加事实 在所有维度上都无法直接求和的度量值,通常是比率或衍生指标。 利润率、平均单价、转化率 适用于分析比率、平均值或需要权重处理的业务场景,例如分析效率。 必须结合上下文设计加权平均、除法等逻辑,不能通过直接聚合获得结果。
类别 示例字段名 示例描述 是否可跨时间维度求和 处理方法
可加事实 sales_amount 记录销售金额,例如一笔订单的总金额。 直接使用 SUM(sales_amount) 进行求和即可。
可加事实 sales_qty 记录销售数量,例如商品的销售件数。 可按时间、商品、客户等维度聚合计算总量。
半可加事实 stock_qty 记录某一时间点的库存量,例如每天的库存快照。 取最新时间点的值或计算时间点之间的变化量。
半可加事实 account_bal 记录某一时间点的账户余额,例如每天的账户快照。 取最后一个时间点的余额作为有效值。
不可加事实 profit_margin 记录利润率,例如单个商品的利润率。 按比率的定义公式重新计算(如总利润/总收入)。
不可加事实 avg_price 记录平均单价,例如按订单计算的商品平均单价。 通过加权计算重新求值(如总金额/总数量)。

2.2.3 事实表中的空值

  • 事实表中可以存在空值度量(所有聚集函数sum、count等都可针对空值事实计算)。

  • 但是事实表中的外键不能存在空值,因为它们是维度表与事实表之间的关联桥梁。空值的外键意味着事实表中的记录没有关联到任何有效的维度数据,无法确保确保数据的完整性和一致性(引发数据质量问题)。
    在这里插入图片描述


2.2.4 事务事实表(Transactional Fact Table)

事务事实表记录的是单个业务事务或事件的详细信息,每条记录代表一个独立的操作,如一次购买、一次交易或一次订单等。数据粒度通常非常细,每一行记录都是一个具体的事务。

在这里插入图片描述

  • 粒度细:每条记录表示一个单独的事件或操作。
  • 数据量大:由于记录详细的事务,数据量较大,且随着业务发展不断增加。
  • 高更新频率:事务数据通常在操作发生时实时更新。
  • 适用于实时或近实时分析:事务事实表能提供详细的业务过程数据,用于监控和分析业务活动。
字段名 描述
transaction_id 事务ID(唯一标识)
customer_id 客户ID
product_id 产品ID
time_id 时间ID(外键)
quantity 销售数量
sales_amount 销售金额
payment_status 付款状态

2.2.5 周期快照事实表(Periodic Snapshot Fact Table)

周期快照事实表记录在特定时间点或时间段内的业务状态,通常会在某个固定时间间隔(如每天、每周或每月)进行快照。

在这里插入图片描述

每条记录通常代表某个周期结束时的业务状态,体现的是在该时间点的“快照”信息

  • 粒度较粗:每条记录代表一个周期的业务状态,而不是单个事务。
  • 数据量较小:与事务事实表相比,周期快照事实表记录的数量较少,因为它仅记录周期性汇总的业务状态。
  • 周期性更新:快照表通常定期(如每天、每月)更新,更新频率较低。
  • 适用于趋势分析和汇总:周期快照表非常适合用于分析业务在特定时间点的状态变化,例如月度销售趋势、客户活跃度变化等。
字段名 描述
snapshot_date 快照日期
customer_id 客户ID
total_sales 总销售金额
total_quantity 总销售数量
total_orders 总订单数量

2.2.6 累计快照事实表(Cumulative Snapshot Fact Table)

累计快照事实表记录的是某个度量数据(如库存数量、账户余额等)的累积变化情况。与周期快照表不同,累计快照表记录的是从一个起始点开始,随时间积累变化的数据状态。这种表适用于需要持续积累的度量数据,如库存、客户余额、累计销售等。

在这里插入图片描述

  • 粒度较粗:每条记录通常表示某个特定时间点的累计度量数据。
  • 持续更新:与周期快照表不同,累计快照表在每次数据更新时都会进行累积。它不会丢失先前的累积数据,而是随着时间推移不断更新。
  • 适用于长期趋势分析:累计快照表能够帮助跟踪业务的长期变化,如追踪某个客户的累计购买金额、账户余额变化等。
字段名 描述
snapshot_date 快照日期
account_id 账户ID
balance 累计余额
total_deposit 累计存款
total_withdrawal 累计取款
  • 每条记录表示某个时间点的账户余额,包括从账户创建到该日期的所有存款和取款的累计情况。

特性 事务事实表 周期快照事实表 累计快照事实表
粒度 细粒度,每个事件或事务一条记录 粗粒度,按周期(如日、月、年)记录状态 粗粒度,按累积数据(如累计销售额)记录
数据量 大,随时间增加,记录每个事务 相对较小,通常按周期记录数据 适中,数据随着累计情况不断增长
更新频率 高,实时或近实时更新 低,定期(如每日、每月)更新 持续更新,随着业务过程变化而更新
适用场景 详细的业务过程分析,如订单追踪 趋势分析、月度或季度报告等 长期数据跟踪,如账户余额、累计销售等
示例 每一笔订单的详细信息 月度销售汇总数据 客户账户余额的累计变化

整理不易 列位点赞收藏关注多多支持🤣🤣🤣~


网站公告

今日签到

点亮在社区的每一天
去签到