缓慢变化维

缓慢变化维

  维度建模的数据仓库中，缓慢变化维（Slowly Changing Dimensions，SCD）。缓慢变化维的提出是因为维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化。这种随时间发生变化的维度称之为缓慢变化维，并且把处理维度表的历史变化信息的问题称为处理缓慢变化维的问题，即处理SCD的问题。
  假设在第一次从业务数据库中加载了一批数据到数据仓库中，当时业务数据库有这样的一条顾客的信息。

顾客 BIWORK ，居住在北京，目前是一名 BI 的开发工程师。假设 BIWORK 因为北京空气质量 PM2.5 等原因从北京搬到了三亚。那么这条信息在业务数据库中应该被更新了 。

假设在数据仓库中实现了与业务数据库之间的同步，数据仓库中也直接将词条数据修改更新。之后做数据统计分析时，在数据仓库中所有对顾客 BIWORK 的销售都指向了 BIWORK 新的所在地三亚，但是实际上 BIWORK 在之前所有的购买都发生在北京。
  这是一个非常简单的例子，它描述了因一些基本信息的更改可能会引起数据归纳和分析出现的问题。但是有时，这种场景的的确确可能是存在的。为了解决类似于这样的问题需要了解数据仓库中的一个非常重要的概念 - 缓慢渐变维度。

缓慢变化维的解决方案

处理缓慢变化维的方法通常分为三种方式：
  第一种方式“TYPE 1”：不记录历史数据,新数据覆盖旧数据。最容易实现，但是没有保留历史数据，无法分析历史变化信息。如果该维度数据的变化并不是你所关心的，那么可以采用直接覆盖历史数据的方法。
  可以在 Customer 维度中使用来自业务数据库中的 Business Key - CustomerID 来追踪业务数据的变化，一旦发生变化那么就将旧的业务数据覆盖重写。DW 中的记录根据业务数据库中的 CustomerID 获取了最新的 City 信息，直接更新到 DW 中。

  第二种方式“TYPE 2”：保存多条记录,直接新添一条记录，同时保留原有记录，并用单独的专用的字段保存区别。这样处理，需要代理键的支持。实现方式是当有维度属性发生变化时，生成一条新的维度记录，主键是新分配的代理键，通过自然键可以和原维度记录保持关联。
  在数据仓库中更多是对相对静态的历史数据进行数据的汇总和分析，因此会尽可能的维护来自业务系统中的历史数据，能够真正捕获到这种历史数据的变化。可能需要分析的结果是 BIWORK 在 2012年的时候购买额度整体平稳，但是从2013年开始购买额度减少了，出现的原因可能与所在的城市有关系，在北京的门店可能比在三亚的门店相对要多一些。像这种情况，就不能很简单在数据仓库中将 BIWORK 当前所在城市直接更新，而应该新增加一条数据来说明现在 BIWORK 所在地是在 Sanya。

  但是如果仅仅在 DW 中新增一条新的数据仍然会出现新的问题，因为在 DW 中标识这个顾客是通过 CustomerID 来实现的，CustomerID是唯一的。然而在 DW 中新增一条数据来保存业务数据库中历史信息，就无法保证这条数据在 DW 中的唯一性了，其他的 DW 数据表关联到这张表就无法知道应该如何引用这个 Customer 的信息。实际上，如果 CustomerID 在 DW 中也作为主键来唯一标识 Customer 的话，在插入新数据的时候就会发生失败。
  因此需要继续保持 Business Key 业务键，因为它是关联到业务数据库的唯一纽带。做出改变的部分就是新增加一个 Key，一个数据仓库的键。在数据仓库的术语里面，这个唯一标识数据仓库表记录的键称之为 Surrogate Key 代理键，通常设置为DW表的主键。

  在上面这张表中，其中CustomerID - Business Key 业务键，用来连接业务数据库和数据仓库的键，注意无论在业务数据库还是数据仓库无论任何时候都不应该发生改变。DWID - Surrogate Key 代理键，一般设置为 DW 维度表的主键，用来在数据仓库内部中的维度表和事实表建立关联。
为什么使用代理键，有什么好处？
  假设业务数据库来自于不同的系统，对这些数据进行整合的时候有可能出现相同的 Business Key，这时通过 Surrogate Key 就可以解决这个问题。一般来自业务数据库中的 Business Key 可能字段较长，比如 GUID，长字符串标识等，使用Surrogate Key 可以直接设置成整形的。事实表本身体积就很大，关联 Surrogate Key 与关联 Business Key 相比，Surrogate Key 效率更高，并且节省事实表体积。使用 Surrogate Key 可以更好的解决这种缓慢渐变维度，维护历史信息记录。
  什么时候可以不用代理键？应当结实际业务，比如像有些业务表本身的 Business Key 就已经是整形的了，并且表中的属性基本上不随着时间或地理发生改变。比如像某些国家名称，地区编号编码等等基本上不会怎么发生改变，即使改变了也不需要维护历史记录这样的情况下可以直接使用业务数据库中的 Business Key 而不需要设置新的 Surrogate Key。

  仅仅设置新的 Surrogate Key - DWID 是不够的，还需要告诉数据仓库哪一条信息是现在正在使用的。当然可以根据 DWID 的顺序来查出最新的记录，但是每次都要比较 CustomerID 然后找出最大的 DWID 这样的查询比较麻烦。

因此可以额外一个标志表示这条数据是最新更改的。
另外的一种方式就是通过起始时间来标识，Valid To 为 NULL 的标识当前数据。

当然，也有将两者都综合的。

  还有一种情况：混合使用 Type 1 和 Type 2 的，比如说 Occupation 这个字段在业务数据库中发生了变化，但是可以不用维护这个历史信息，因此可能的做法是直接将最新的 Occupation 在数据仓库中覆盖掉。

根据实际情况，还有一种做法就是全部覆盖掉。

此种方法有以下几条优点：

• 能用简单的过滤条件选出维度当前的值
• 能较容易的关联出历史任意一时刻事实数据的值
• 如果事实表中有一些时间字段，可以很容易选择哪一条维度数据进行关联分析

  第三种方式“TYPE 3”：添加属性列。添加历史列，用不同的字段保存变化痕迹.它只能保存两次变化记录.适用于变化不超过两次的维度。这种方式的优点是可以同时分析当前及前一次变化的属性值，缺点是只保留了最后一次变化信息。
  比如说把要维护的历史字段新增一列，然后每次只更新 Current Column 和 Previous Column。这样，只保存了最近两次的历史记录。但是如果要维护的字段比较多，就比较麻烦，因为要更多的 Current 和 Previous 字段。所以 Type 3 SCD 用的还是没有 Type 1 和 Type 2 那么普遍。

  在实际建模中可以联合使用三种方式，也可以对一个维度表中的不同属性使用不同的方式，都需要根据实际情况来决定。但目的都是支持方便的分析历史变化情况。