关于数据仓库中缓慢变化维的总结
首先说一下概念，缓慢变化维（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，根据是否有必要记录历史变化进行选择。
