This website requires JavaScript.

The Microsoft Data Warehouse Toolkit 读书笔记(2) 设计纬度模型

本文将介绍设计维度模型的基本内容,是Kimball Lifecycle 的核心章节,如图Figure 2-1中间一行聚焦于数据.主要的目标是让用户可以获取到他们需要的数据,关键在于建立一个有用的,灵活的扩展性高的数据模型.这个模型需要支持现在以及未来预测分析。

Figure 2-1:

image

一个基本的零售维度模型

image

总线矩阵表

image

名词解释

factless fact tables: 一些业务流程并没有明确的度量,比如入职/离职记录、考勤记录等。这种称之为factless fact tables

conformed dimension: 一个维度所有业务流程都会用到

slowly changing dimensions (SCDs): 如果业务不关心变动则为type1 如果业务想要追溯则为type2,另外一种就是type3 用列分别显示旧值和新值,一般不太用。这样会导致表格太宽

Degenerate Dimensions : 事务ID 这种都称之为退化维,一般会放进事实表,用来做一些特别的分析.

one-to-many : 一般来说维度表与事实表的关系都是一对多. 也就是说维度表的一行对应多行事实表. 这样的关系很重要,可以避免重复计算.  然而现实情况中它们的关系可能很复杂,比如 事实表与维度表是多对多关系.或者两个维度表是多对多关系.

Many-to-many between the fact table and a dimension:  事实表与维度表之间多对多的关系出现在多个维度值可以匹配到单个事实事物的情况. 比如有一个大单可能有多个销售参与.为解决这个问题需要有一个中间表. 当然这样会有重复计算的风险,有可能的话可以增加哥哥销售的权重来处理.如图Figure 2-4 SalesRepGroup桥接表

image

Many-to-many between dimensions : 维度与维度间的多对多比较典型的是银行用户与账号的关系,一个账号可能由多个用户签署,或这个一个用户有多个账号.  处理这种情况我们也可以加个中间表来设计纬度

image

Variable-Depth Hierarchies 可变深层次结构  是指层次没有规律参差不齐.

Shrunken dimension 收缩纬度,如果你需要分类汇总,那么可能需要子表,因为其他多数属性并没有什么作用.如下图中的ProductSubcategory 就称之为Shrunken dimension

image

Junk Dimensions:业务系统中一般有表示状态或者类型的字段, 这个字段往往是个代理键,然后关联到另外一张很小的往往只有几行记录的表. 比如付款类型只允许 “Credit,” “Cash,” 或 “Account.”  事务类型只能是”Order,”或"Refund”.一个junk dimension 则是把这些小维度组合进一个表中. 比如这个表可以包含两个字段  Transaction_Type 和 Payment_Type   那么整个TransactionInfo 表只需要六行就能囊括所有可能的组合

三总事实表类型

  • transaction
  • periodic snapshot
  • accumulating snapshot

维度设计

日期相关:     ‘1900-01-01’表示未知,’9999-12-31’表示还未发生

角色相关:

image image

0条评论
avatar