渐变维度（Slowly Changing Dimension）及其处理方法

渐变维度（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

这样就能记录到维度改变的历史，并且不用经常的修改表结构，只需要在维度变化的时候，更改表中数据就可以了。 这种方法的缺点是当维表数据量大的时候，会导致访问效率降低和存储空间的消耗增加。

转自：http://blog.csdn.net/xiaoxu0123/archive/2010/03/25/5417894.aspx