关于数据仓库的历史数据

作者：onesday 20070118

数据仓库中需要包含历史信息和当前信息，比如一个全球通用户C，之前使用了套餐P1，那么生产系统中就会有一条客户C使用套餐P1的记录R（C，P1），数据仓-库也会取到这条记录。现在该用户C把套餐P1改成套餐P2，那么生产系统中就会把原来的记录改成客户C使用套餐P2的记录R（C，P2），数据仓库从生产系统取-数据的时候，如何处理呢？

我觉得有2种处理方法：
1.在原来的记录R（C，P1）上做一个标志位，标识这条记录是否已经删除，这样的话，需要_update R（C，P1）以及_insert R（C，P2）。
2.原来的记录R（C，P1）不变，插入一条新的记录Rx（C，P1），Rx的作用是把R（C，P1）这条记录充销。这样的话，需要_insert R（C，P2）以及_insert Rx（C，P1）。

方法1比较直观，但是_update操作可能有效率问题，尤其是数据量很大的时候。
方法2的问题在于查询统计的时候，可能会比较麻烦，主要看充销怎么处理，因为要关联R（C，P1）和Rx（C，P1）两条记录。

在实际项目中，会怎么处理呢？

作者：shiming 20070118

请查阅Kimball的 the datawarehouse toolkit - slowly changing dimension

一句话，为每条记录增加一个起始日和终止日，对当前纪录可以使用特殊终止日作为标记。

作者：onesday 20070119

使用特殊终止日，其实就是采用第一种方法，_update R（C，P1），使用时间戳作为删除标识。
另外，Kimball的那本书我也看过，但是这种情况和缓慢维度变化不太一样。
套餐本身就是一个维度，因为并不是套餐本身发生了变化，只是用户从套餐P1变成套餐P2，所以维度上并没有变化，而是事实表发生了变化。
或者对缓慢维度变化的理解有不同？
这个问题主要是新纪录过来的时候，对老记录的处理。
后来我想了一下，觉得虽然不是缓慢维度变化，但是可以采用类似缓慢维度变化的处理方法。
使用标识字段来标识历史状态和当前状态。至于标识，可以是时间戳，也可以标志字段。

作者：Qing 20070119
我们目前的数据仓库，用的是onesday说得第一种方法。需要对老记录进行_update。这里用的标识字段就是一个"最后变更日期"，每条新纪录产生时，该字-段被设定一个非常大的日期值，比如20990101。当通过记录对比发现记录改变之后，更新该字段为当前日期。然后插入新纪录。

至于性能，可能不同的数据库有不同的处理方法吧，倒不是非常清楚了。我们用的是Teradata，这点倒没见什么问题。

作者：shiming 20070119
抱歉，我没有仔细看你的问题，就贸然回复了。我的观点只是第一种方法中的特殊标记使用日期要好于其他标记，它可以真实反应某个时点的snapshot。

我认为可以想象它是一种transaction，当更换套餐事件发生时，插入新的纪录，同时更新user dimension中的当前套餐外键，至于是否更新原纪录就取决于更新效率和查询效率间的平衡了。

作者：onesday 20070119

to shiming：
如果把用户看成一个维度，使用的套餐看成是该维度的一个属性，那么确实是属于缓慢维度变化。
但是如果把套餐作为一个维度，因为并不是套餐本身发生了变化，只是用户从套餐P1变成套餐P2，所以维度上并没有变化，应该属于事实表的变化。

to Qing：
今天忽然听到一种"奇怪"的说法，是关于在数据仓库中对记录进行_update的。

说是在数据仓库中对记录直接_update的效率还不如先_delete，然后_insert的效率。

感觉不可思议。

作者：shiming 20070119

呵呵，这样的话是mini dimension了，在事实表中同时记录用户和套餐信息。

那个"奇怪"说法，会不会是指如果_delete的依据是一个clustered index，那么就不用去到data page，因此比_update高效，但_insert本身还是要去data page的呀~或者能够保证新_insert的排在后面?随便猜猜~

作者：人虫 20070119

对上面的理解，我提下我自己的看法，假如说客户这个月换了套餐，下个月又换了其他的了，这样就不是什么缓慢变化维能处理的了，

像这样的情况，如果是不能循环变得情况，就如上面的，一种套餐只能有一次的话，可以采用加时间来处理。
如果是那种变来变去的，直接把这个维度转为事实来处理。