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

初级会员 注册时间: 2008-05-21 03:08:07 文章: 12 离线

总结得很好`
第五只比第二多了个代理键
第五种方法好~

初级会员 注册时间: 2008-06-15 23:38:45 文章: 12 离线

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

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

这篇文章被编辑了 1 次. 最近一次更新是在 2008-06-16 02:30:29

myoraclejava wrote:

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

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

row_key仅起行标识符作用，自增序列，或成为代理键，无其他作用，可有可无（文档中有说明的）

supplier_key在业务逻辑上是主键，但物理存储上不能作为主键，所以事实表与他仅在逻辑上是主外键关系，事实上事实表和此维表是多对多关系，因此这也是第六中方法要解决的问题。他们在物理上并不是主外键关系，而且我们做大项目时往往考虑到主外键关系可能会影响etl插入效率问题，有时候会不建索引和主外键关系，或etl后再重建索引和主外键。

欢迎大家共同探讨！

初级会员 注册时间: 2008-06-15 23:38:45 文章: 12 离线

你的回答证实了我的理解是正确的，只是我抠住文字，有点弄糊涂了。
我觉得，第五种模式较第二种模式，使跟踪维度变化避免了牵涉到业务数据，而只关系到supplier_key。
第六种较第五种，在数据上建立关系，避免在报表层加过滤。

初级会员 注册时间: 2008-07-22 23:53:26 文章: 5 离线

纬度变化有两种：
一种是纬度成员变化（最底层）；一种是纬度层次结构变化（机构的合并、分拆）；
不管采取那种方案，要清楚客户的最终想要什么。
根据的客户要求决定采取那种方案。

注意：历史是正确的，为什么要改变历史。

初级会员 注册时间: 2008-07-24 04:34:45 文章: 1 离线

lynx286 wrote:第六种，事实表和维表用
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 就行了。

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

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