lynx286原创--缓慢变化维解决方案

Lynx286原创
www.mydwbi.com版权所有
欢迎转贴，转贴请注明出处。
如文本格式阅读不方便，请下载word版本。

2008-5-23

目录

缓慢变化维解决方案 1
参考文档：Wikipedia 2
一.新数据覆盖旧数据 3
二.保存多条记录，并添加字段加以区分 3
三.不同字段保存不同值 4
四．另外建表保存历史记录 4
五．混合模式 5
六．非常规混合模式 6

参考文档：Wikipedia

缓慢变化维定义

Wikipedia中的定义：
Dimension is a term in data management and data warehousing that refers to logical groupings of data such as geographical location, customer information, or product information.

Slowly Changing Dimensions (SCD) are dimensions that have data that slowly changes.

大意是说数据会发生缓慢变化的维度就叫”缓慢变化维”。
举个例子就清楚了：
在一个零售业数据仓库中，事实表保存着各销售人员的销售记录，某天一个销售人员从北京分公司调到上海分公司了，那么如何来保存这个变化呢？也就是说销售人员维度要怎么恰当的处理这一变化。先来回答一个问题，为什么要处理，或保存这一变化？如果我们要统计北京地区或上海地区的总销售情况的时候，这个销售人员的销售记录应该算在北京还是算在上海？当然是调离前的算在北京，调离后的算在上海,但是如标记这个销售人员所属区域？这里就需要处理一下这个维度的数据，即我们缓慢变化维需要做的事情。

处理缓慢变化维一般按不同情况有以下几种解决方案：

一. 新数据覆盖旧数据
此方法必须有前提条件，即你不关心这个数剧的变化。例如，某个销售人员的英文名改了，如果你不关心员工的英文名有什么变化则可直接覆盖(修改)数据仓库中的数据。

二. 保存多条记录，并添加字段加以区分
这种情况下直接新添一条记录，同时保留原有记录，并用单独的专用的字段保存区别。如：
(以下表格中Supplier_State表示上面例子中所属区域，为描述清晰，不用代理键表示)

Supplier_key Supplier_Code Supplier_Name Supplier_State Disable
001 ABC Phlogistical Supply Company CA Y
002 ABC Phlogistical Supply Company IL N
或：

Supplier_key Supplier_Code Supplier_Name Supplier_State Version
001 ABC Phlogistical Supply Company CA 0
002 ABC Phlogistical Supply Company IL 1

以上两种是添加数据版本信息或是否可用来标识新旧数据。
下面一种则是添加记录的生效日期和失效日期来标识新旧数据：

Supplier_key Supplier_Code Supplier_Name Supplier_State Start_Date End_Date
001 ABC Phlogistical Supply Company CA 01-Jan-2000 21-Dec-2004
002 ABC Phlogistical Supply Company IL 22-Dec-2004

空的End_Date表示当前版本数据，或者你也可一用一个默认的大时间 (如: 12/31/9999)来代替空值, 这样数据还能被索引识别到.

三. 不同字段保存不同值

Supplier_key Supplier_Name Original_Supplier_State Effective_Date Current_Supplier_State
001 Phlogistical Supply Company CA 22-Dec-2004 IL

这种方法用不同的字段保存变化痕迹.但是这种方法不能象第二种方法一样保存所有变化记录,它只能保存两次变化记录.适用于变化不超过两次的维度。

四. 另外建表保存历史记录

即另外建一个历史表来表存变化的历史记录，而维度只保存当前数据。

Supplier:
Supplier_key Supplier_Name Supplier_State
001 Phlogistical Supply Company IL

Supplier_History:
Supplier_key Supplier_Name Supplier_State Create_Date
001 Phlogistical Supply Company CA 22-Dec-2004

这种方法仅仅记录一下变化历史痕迹，其实做起统计运算来还是不方便的。

五. 混合模式
这种模式是以上几种模式的混合体，相对而言此种方法更全面，更能应对错综复杂且易变化的用户需求，也是较为常用的。

Row_Key Supplier_key Supplier_Code Supplier_Name Supplier_State Start_Date End_Date Current Indicator
1 001 ABC001 Phlogistical Supply Company CA 22-Dec-2004 15-Jan-2007 N
2 001 ABC001 Phlogistical Supply Company IL 15-Jan-2007 1-Jan-2099 Y

此中方法有以下几条优点：
1. 能用简单的过滤条件选出维度当前的值。
2. 能较容易的关联出历史任意一时刻事实数据的值。
3. 如果事实表中有一些时间字段(如：Order Date, Shipping Date, Confirmation Date)，那么我们很容易选择哪一条维度数据进行关联分析。

其中Row_Key和 Current Indicator字段是可有可无的，加上去更方便，毕竟维度表的数据都不大，多点冗余字段不占太大空间但能提高查询效率。
这种设计模式下事实表应以Supplier_key为外键，虽然这个字段不能唯一标识一条维度数据，从而形成了事实表与维表多对多的关系，因此在做事实和维度做关联时应加上时间戳字段(或Indicator字段)。

六. 非常规混合模式
上面说到第五种实现方式有点弊端，那就是事实表和维表不是多对一关系，而是多对多关系，这种关系不能在建模时解决只能在报表层面，在报表运行时解决，且在BI语意层建模时需要添加时间过滤条件，比较繁琐。
下面这种解决方案可以解决此多对多关系，但是得修改一下事实表：

Supplier Dimension:
Version_Number Supplier_key Supplier_Code Supplier_Name Supplier_State Start_Date End_Date
1 001 ABC001 Phlogistical Supply Company CA 22-Dec-2004 15-Jan-2007
0 001 ABC001 Phlogistical Supply Company IL 15-Jan-2007 1-Jan-2099

Fact Delivery: (为描述清晰，同样不使用代理键标识维度)
Delivery_Key Supplier_key Supplier_version_number Quantity Product Delivery_Date Order_Date
1 001 0 132 Bags 22-Dec-2006 15-Oct-2006
2 001 0 324 Chairs 15-Jan-2007 1-Jan-2007

此方案中向维表中的当前数据版本号始终为0，即插入维度数据时先将老版本的数据的version_number改成1（递增），然后再插入当前数据，此时才能保持当前数据版本号始终为0。
事实表中插入数据时所有的维度数据版本号始终全部为0。
因此此方案完全可解决事实表和维表多对多关系问题，另外还有个优点是能保证事实表和维表的参照完整性，而且我们在用ERwin,PowerDesigner等建模工具建模时，Version_Number和Supplier_key可作为复合主键在两实体间建立链接。

中级会员 注册时间: 2008-04-27 22:20:20 文章: 48 离线

個人認為方法二比較適中，加上生效和失效日期便于識別

初级会员 注册时间: 2008-05-28 02:50:46 文章: 10 离线

很好的资料,谢谢楼主!

六. 非常规混合模式
这个方式
如果想看历史数据的统计怎么实现不是很明白
和我理解的不一样

第六种，事实表和维表用
Fact_Delivery.Supplier_key = Supplier_Dimension.Supplier_key and
Fact_Delivery.Version_Number = Supplier_Dimension.Version_Number
关联就行了，其他条件如Delivery_Date between xxx and yyy 限制你说说得历史时间段，
然后加些group by 就行了。

那这个"事实表中插入数据时所有的维度数据版本号始终全部为"无必要吧
既然全部为0 就可以不存这个字段了吧

Supplier Dimension:
Version_Number Supplier_key Supplier_Code ISNEW_FLAG Supplier_Name Supplier_State Start_Date End_Date
1 001 N ABC001 Phlogistical Supply Company CA 22-Dec-2004 15-Jan-2007
2 001 Y ABC001 Phlogistical Supply Company IL 15-Jan-2007 1-Jan-2099
Version_Number新的记录来就自加1
Fact Delivery: (为描述清晰，同样不使用代理键标识维度)
Delivery_Key Supplier_key Supplier_version_number Quantity Product Delivery_Date Order_Date
1 001 1 132 Bags 22-Dec-2006 15-Oct-2006
2 001 2 324 Chairs 15-Jan-2007 1-Jan-2007
事实表来新记录始终得到维度表中ISNEW_FLAG 为'Y'的记录

这样可以很直接的关联到某个事实记录对应的维度属性不需要时间做BETWEEN
这样不知道后来方不方便后面做展现

我也是刚接触这个自己都不是很清晰我自己的是否可行
感觉这样的话事实表就不需要两个日期字段了吧就一个就够了
还有你的事实表两个日期字段是基于什么考虑的

不存在这个字段那就跟第五种一样了，第六种是在第五种得基础上解决多对多关系，在BI语意层建模时需要添加时间过滤条件，数据仓库模型建模时也不方便等问题得。

“始终得到维度表中ISNEW_FLAG 为'Y'的记录” 和“维表中的当前数据版本号始终为0”不是一样得效果吗? 数据仓库建模还要考虑报表语义层建模得方便。

两个日期字段方便取得某一行记录生效的时间区间，一个时间字段就不好区分了，数据仓库的数据两一般比较大，尽量少做关联（join），多一两个冗余字段关系不大。

晕了已经
寒
疑问的是 Supplier_version_number 这个在事实表的值一直都是0?

zdcku wrote:晕了已经
寒
疑问的是 Supplier_version_number 这个在事实表的值一直都是0?

是。
同时保持维表中当前可用得那条记录得version_number 是0

恩理解了

初级会员 注册时间: 2008-05-18 21:11:33 文章: 10 离线

老大，看了你的文章有所启发，不过没我现在的业务复杂
目前我遇到的情况是机构的合并和拆分问题，即：Supplier_key会有规律的改变，而且原来一条记录可能会变成n条，n条会变成1条。
不知道这样的情况怎么解决？
我初步的想法是在你的第6种方案中再加入,super_Supplier_key
呵呵

yevolx wrote:老大，看了你的文章有所启发，不过没我现在的业务复杂
目前我遇到的情况是机构的合并和拆分问题，即：Supplier_key会有规律的改变，而且原来一条记录可能会变成n条，n条会变成1条。
不知道这样的情况怎么解决？
我初步的想法是在你的第6种方案中再加入,super_Supplier_key
呵呵

机构的合并和拆分问题确实比较复杂，

希望老兄解决后能将需求和解决方案详细描述一下，与大家分享。

初级会员 注册时间: 2008-05-18 21:11:33 文章: 10 离线

还指望老大能给点建议呢！

yevolx wrote: 还指望老大能给点建议呢！

论坛是大家的论坛，是大家讨论的地方，我一个人在那说有什么意思，留点空间给大家讨论吧，这才是论坛的气氛。