缓慢变化维(II)

首先说一下概念,缓慢变化维(Slowly Changing Dimensions)指的是:维度表里面的数据并非是始终不变的,总会随着时间发生变化:

假设我们有一张我们公司的销售员维度表如下,记录了每个销售员的一些基本信息,那么随着时间的变化销售员可能会在各省公司间调岗,如将周杰伦调入北京分公司,针对这种变化,业务系统会直接将业务数据库中周杰伦的地址直接update为北京,而不会考虑历史变化,不过在数据仓库中由于有时我们需要进行历史变化分析,或者防止销售数据记录错误,所以需要对这种变化进行相应的处理,主要有以下三种办法:

1、TYPE1

与业务数据保持一直,同样为直接update。这样就难以记录历史变化,如果周杰伦于15年7月调入北京,那么我们想要知道北京销售员在15年的销售数据时,就会将周杰伦的业绩算入北京分公司下,实际上周杰伦7月份以前的销售数据均应算在台北,所以为了避免这样的问题就有了TYPE2的处理方式。

2、TYPE2

保留历史变化,如下图:

不过带来一个问题,当事实表中的销售数据与此维度表进行关联时,由于存在customer_id的数据有两条100的,所以会关联出两个数据,这样是有问题的,那么就引入了一个代理键的概念,相当于数据仓库为维度表分配一个主键,而不用当初业务数据库中的主键,如下:

不过此时又带来了另外一个问题,当业务事实表中有新的销售业绩数据插入的时候,需要在外键列中插入维度表的dw_customer_id,那么此刻需要先找到维度表中的customer_id,然后再找到最大的dw_customer_id插入进去(因为主键往往是自增的,最大的肯定是最新的),但是某些情况下如果向事实表中插入历史数据的情况,就无法判断具体是哪个台北周杰伦还是北京周杰伦的业绩了,所以往往在维度表中同样加入时间列,如2000/1/1-2015/7/1来记录周杰伦在台北,而周杰伦在北京时间字段起始为2015/7/2,末尾时间字段可以记录空值或用9999/9/9替代,有新变化再进行更新。

3、TYPE3

有时需求中并非所有字段的变化都进行记录并且不需要每次变化都记录,比如我们可能只关心address(所在地)的最近两次变化,那么可以这样记录:

这样做只可以记录少量的变化次数,需要的话也可以相应加上时间列,这种方式一般用到的比较少,多数均为TYPE1,TYPE2,根据是否有必要记录历史变化进行选择。

转自:http://www.cnblogs.com/charisna/p/4673866.html


  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值