http://www.mydwbi.com/posts/list/13.page JForum - http://www.jforum.net [url]www.mydwbi.com[/url]版权所有
欢迎转贴，转贴请注明出处。
如文本格式阅读不方便，请下载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可作为复合主键在两实体间建立链接。


]]> http://www.mydwbi.com/posts/preList/144/675.page http://www.mydwbi.com/posts/preList/144/675.page GMT http://www.mydwbi.com/posts/preList/144/676.page http://www.mydwbi.com/posts/preList/144/676.page GMT http://www.mydwbi.com/posts/preList/144/757.page http://www.mydwbi.com/posts/preList/144/757.page GMT 这个方式
如果想看历史数据的统计 怎么实现 不是很明白
和我理解的不一样]]> http://www.mydwbi.com/posts/preList/144/776.page http://www.mydwbi.com/posts/preList/144/776.page GMT 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 就行了。]]> http://www.mydwbi.com/posts/preList/144/777.page http://www.mydwbi.com/posts/preList/144/777.page GMT 既然全部为0 就可以不存这个字段了吧]]> http://www.mydwbi.com/posts/preList/144/794.page http://www.mydwbi.com/posts/preList/144/794.page GMT Version_Number Supplier_key Supplier_Code ISNEW_FLAG Supplier_Name Supplier_State Start_Date End_Date
[color=red]1 [/color] 001 N ABC001 Phlogistical Supply Company CA 22-Dec-2004 15-Jan-2007
[color=red]2 [/color] 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 [color=red]1 [/color] 132 Bags 22-Dec-2006 15-Oct-2006
2 001 [color=red]2 [/color] 324 Chairs 15-Jan-2007 1-Jan-2007
事实表来新记录始终得到维度表中ISNEW_FLAG 为'Y'的记录

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

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

]]> http://www.mydwbi.com/posts/preList/144/795.page http://www.mydwbi.com/posts/preList/144/795.page GMT
“始终得到维度表中ISNEW_FLAG 为'Y'的记录” 和“维表中的当前数据版本号始终为0”不是一样得效果吗? 数据仓库建模还要考虑报表语义层建模得方便。

两个日期字段方便取得某一行记录生效的时间区间，一个时间字段就不好区分了，数据仓库的数据两一般比较大，尽量少做关联（join），多一两个冗余字段关系不大。]]> http://www.mydwbi.com/posts/preList/144/797.page http://www.mydwbi.com/posts/preList/144/797.page GMT 寒
疑问的是 Supplier_version_number 这个在事实表的值一直都是0?]]> http://www.mydwbi.com/posts/preList/144/803.page http://www.mydwbi.com/posts/preList/144/803.page GMT 寒
疑问的是 Supplier_version_number 这个在事实表的值一直都是0?[/quote]

是。
同时保持维表中当前可用得那条记录得version_number 是0]]> http://www.mydwbi.com/posts/preList/144/804.page http://www.mydwbi.com/posts/preList/144/804.page GMT ]]> http://www.mydwbi.com/posts/preList/144/811.page http://www.mydwbi.com/posts/preList/144/811.page GMT 目前我遇到的情况是机构的合并和拆分问题，即：Supplier_key会有规律的改变，而且原来一条记录可能会变成n条，n条会变成1条。
不知道这样的情况怎么解决？
我初步的想法是在你的第6种方案中再加入,super_Supplier_key
呵呵]]> http://www.mydwbi.com/posts/preList/144/860.page http://www.mydwbi.com/posts/preList/144/860.page GMT 目前我遇到的情况是机构的合并和拆分问题，即：Supplier_key会有规律的改变，而且原来一条记录可能会变成n条，n条会变成1条。
不知道这样的情况怎么解决？
我初步的想法是在你的第6种方案中再加入,super_Supplier_key
呵呵[/quote]

机构的合并和拆分问题确实比较复杂， 希望老兄解决后能将需求和解决方案详细描述一下，与大家分享。 ]]> http://www.mydwbi.com/posts/preList/144/863.page http://www.mydwbi.com/posts/preList/144/863.page GMT 还指望老大能给点建议呢！]]> http://www.mydwbi.com/posts/preList/144/870.page http://www.mydwbi.com/posts/preList/144/870.page GMT 还指望老大能给点建议呢！[/quote]

论坛是大家的论坛，是大家讨论的地方，我一个人在那说有什么意思，留点空间给大家讨论吧，这才是论坛的气氛。]]> http://www.mydwbi.com/posts/preList/144/873.page http://www.mydwbi.com/posts/preList/144/873.page GMT 第五 只比第二 多了个代理键
第五种方法好~ ]]> http://www.mydwbi.com/posts/preList/144/914.page http://www.mydwbi.com/posts/preList/144/914.page GMT 这种设计模式下事实表应以Supplier_key为外键，虽然这个字段不能唯一标识一条维度数据，从而形成了事实表与维表多对多的关系，因此在做事实和维度做关联时应加上时间戳字段(或Indicator字段)。 [/quote]

在第5 种模式中，row_key有何作用，supplier_key并不能为维表主键，那么事实表又怎么以supplier_key为外键呢？
应该不加任何主外键约束吧。]]> http://www.mydwbi.com/posts/preList/144/967.page http://www.mydwbi.com/posts/preList/144/967.page GMT 这种设计模式下事实表应以Supplier_key为外键，虽然这个字段不能唯一标识一条维度数据，从而形成了事实表与维表多对多的关系，因此在做事实和维度做关联时应加上时间戳字段(或Indicator字段)。 [/quote]

在第5 种模式中，row_key有何作用，supplier_key并不能为维表主键，那么事实表又怎么以supplier_key为外键呢？
应该不加任何主外键约束吧。[/quote]


[list]row_key仅起行标识符作用，自增序列，或成为代理键，无其他作用，可有可无（文档中有说明的）[/list]
[list]supplier_key在业务逻辑上是主键，但物理存储上不能作为主键，所以事实表与他仅在逻辑上是主外键关系，事实上事实表和此维表是多对多关系，因此这也是第六中方法要解决的问题。他们在物理上并不是主外键关系，而且我们做大项目时往往考虑到主外键关系可能会影响etl插入效率问题，有时候会不建索引和主外键关系，或etl后再重建索引和主外键。
[/list]

欢迎大家共同探讨！ ]]> http://www.mydwbi.com/posts/preList/144/969.page http://www.mydwbi.com/posts/preList/144/969.page GMT 你的回答证实了我的理解是正确的，只是我抠住文字，有点弄糊涂了。
我觉得，第五种模式较第二种模式，使跟踪维度变化避免了牵涉到业务数据，而只关系到supplier_key。
第六种较第五种，在数据上建立关系，避免在报表层加过滤。]]> http://www.mydwbi.com/posts/preList/144/973.page http://www.mydwbi.com/posts/preList/144/973.page GMT 一种是纬度成员变化（最底层）；一种是纬度层次结构变化（机构的合并、分拆）；
不管采取那种方案，要清楚客户的最终想要什么。
根据的客户要求决定采取那种方案。

注意：历史是正确的，为什么要改变历史。]]> http://www.mydwbi.com/posts/preList/144/1476.page http://www.mydwbi.com/posts/preList/144/1476.page GMT 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 就行了。[/quote]

按照楼主的说法:
我们其实在刷新事实表的时候首先需要解决一个问题即把维表的Version_Number刷新进入事实表中.

如果要这样做的话,我们完全可以加上一个字段,dim_sequence,维表中所有维值会初始化为不同的sequence值,若其中维值发生变化,则sequence自动递增1,即整个维表以dim_sequence为主键,在刷新时将当前维值的dim_sequence放进事实表中,以后需要展现时,通过dim_sequence关联即可.
当然,维表的每一条记录还是要保留其生命周期的,即start_date,end_date 能更方便地查得更多的信息.


]]> http://www.mydwbi.com/posts/preList/144/1495.page http://www.mydwbi.com/posts/preList/144/1495.page GMT