渐变维度(Slowly Changing Dimension)及其处理方法
要讨论什么是渐变维度,或者缓慢变化维度,就要先说说什么是维度。虽然经常挂在嘴边的词,但解释起来确实有难度,更不要说给出一个概念了。我们平时提到的0维的点,一维的线,二维平面,三维的立体空间已经挺复杂了,撇开不提,我们看看BI领域的维度是什么意思。
个人的理解,维度就是观察数据的不同角度。比如有一个魔方,我们从一个面看是绿色,转个角度,看起来就是红色了。现在举一个具体业务的例子,有一个超市的销售数据,我们就可以有不同的角度去看,从时间角度看,一个月来每天的销售额是上升的,还是下降的;从产品角度看,那种产品占销售分额最多,是食品还是日用品。这个例子中的时间和产品就分别是观察销售数据的维度,与此类似,也可以有营业员维度,价格维度,折扣维度等等。存储维度信息的表就叫做维度表。
维度分为三类,固定维度,渐变维度,和快变维度,今天我们仅介绍渐变维度,顾名思义,渐变维度就是在业务进行过程中,会发生变化,但又不会频繁变化的维度。比如我们企业中的部门,可能不时地会有机构调整,部门就会发生变化,但是又不会天天进行机构调整,因此我们可以把部门这个维度看作缓慢变化维。把存放部门这个维度的表,叫做缓慢变化维度表。
那么在数据仓库的ETL过程中应该怎么处理这种渐变的维度表呢?就以前面提到的维度表为例,我们创建表如下:
Dept (Dept_id, Dept_name)
有数据如下:
1 财务部
2 市场部
3 人事部
那么我们部门调整的时候,把3改为人力资源部了,那么第一种处理方法就是,直接修改Dept表,修改后的表中数据如下:
1 财务部
2 市场部
3 人力资源部
这样处理的好处是,处理简单快捷,减少空间消耗和管理难度。但是其缺点是不能记录维度历史,需要分期部门变化前的数据情况的时候便无从下手了,因此有了第二种处理办法,增加一个列,把部门变化的历史记录下来,修改以后的数据如下:
Dept_id Dept_name Dept_name_new
1 财务部 财务部
2 市场部 市场部
3 人事部 人力资源部
这种方法的好处是,可以记录下来维度变化的历史,方便分析历史数据,但其缺点是需要修改表结构,增加新列,那么每当部门变化的时候都需要变更表,维护的工作量很大。那么我们现在看一下第三种方法。
我们可以在表中增加列,部门的状态,状态时间如下
Dept_id Dept_name Status Status_time Dept_pre_id
1 财务部 A 2009-1-1
2 市场部 A 2009-1-1
3 人事部 U 2009-2-26
4 人力资源部 A 2009-2-26 3
这样就能记录到维度改变的历史,并且不用经常的修改表结构,只需要在维度变化的时候,更改表中数据就可以了。 这种方法的缺点是当维表数据量大的时候,会导致访问效率降低和存储空间的消耗增加。