数据仓库缓慢变化维度

[liaosunny]

在网上看到,有些内容:
历史数据保留，新增数据也要保留。这时，要将原数据更新，将新数据插入，我们使用UPDATE / INSERT。比如：某一员工2005年在A部门，2006年时他调到了B部门。那么在统计2005年的数据时就应该将该员工定位到A部门;而在统计2006年数据时就应该定位到B部门，然后再有新的数据插入时，将按照新部门(B部门)进行处理，这样我们的做法是将该维度成员列表加入标识列，将历史的数据标识为“过期”，将目前的数据标识为“当前的”。另一种方法是将该维度打上时间戳，即将历史数据生效的时间段作为它的一个属性，在与原始表匹配生成事实表时将按照时间段进行关联，这种方法的好处是该维度成员生效时间明确。

小弟因第一次接触这些信息,请问上面的表,如何设计啊.哪位高人能给个表的例子啊?

[dawugui]

不懂，帮顶，学习，蹭分.

[liaosunny]

不知道是不是这样:
如,我有张订单的事实表,其中有:order_number,order_status等等,在从OLTP中拿数据时,假设,我是原表复制过来的,那我在数据仓库中再增加一列为:insert_time ,它的值就设为当时的:getdate()这样吗?
如果是这样的话,那我的表,会不会增长得过快了?

[Me_online]

[Quote=引用 4 楼 liaosunny 的回复:]
不知道是不是这样:
如,我有张订单的事实表,其中有:order_number,order_status等等,在从OLTP中拿数据时,假设,我是原表复制过来的,那我在数据仓库中再增加一列为:insert_time ,它的值就设为当时的:getdate()这样吗?
如果是这样的话,那我的表,会不会增长得过快了?
[/Quote]

For the Order fact table, usually in business perspective you don't have to keep the Record update time, since the Order doesn't have the expired or not.

The Slowly changing dimension (SCD) is about Dimension table, not fact. Usually(SCD2) will include: StartDate(or EffectiveDate), EndDate (or ExpiredDate) and ActiveFlag.

[liaosunny]

[Quote=引用 7 楼 fpzgm 的回复:]

1、对于人员部门变更，我的做法是给人员另外加一个字段，比如version，然后组成联合键进行关联
2、对于订单产品的变化，可以采用作差增补的方法，有的由于时间的原因数据没有补上的话直接update，因为update之前的数据没有任何意义
[/Quote]

目前考虑,将order信息,分成两张表,一张为:状态信息,和一些本身数据的更新时间,增加时间等,做一个order的维度表,然后,再将明细做一张事实表,根据你们的经验,是否两张表都加上一个时间戳来表示呢? 但这样,就不能做数据增量的更新了,只能全部更新,这个还满大工作量的.

[liaosunny]

附上订单内容:
order:
ordersn order_status order_add_time order_updateime
102015545 1 2010-9-12 12:30:10

orderdetail
ordersn barcode amount price
102015545 6325141 2 35
假设我今天更新了一订单,并将 amount 成 1,我的表应该怎么设计好啊?

[fpzgm]

[Quote=引用 11 楼 liaosunny 的回复:]
附上订单内容:
order:
ordersn order_status order_add_time order_updateime
102015545 1 2010-9-12 12:30:10

orderdetail
ordersn barcode amount price
102015545 6325141 2 35
假设我今天更新了一订单,并将 am……
[/Quote]

不明白你意思，为什么要分成两张表呢？放一起就好啦，作为事实表
ordersn order_status order_add_time order_updateime barcode amount price ……
102015545 1 2010-9-12 12:30:10 6325141 2 35

这样不就行了？上面这个事实表应该还有人员编号如saler_id
在上面的表里面再增加一个字段如saler_version，组成联合键

然后人员维度表这样设计
saler_id saler_version saler_name start_time end_time
1 0 a 2009-9-12 00:00:00 2010-9-12 00:00:00
1 1 a 2010-9-12 00:00:00 2099-12-31 00:00:00
每次变化，新增一条记录，并修改上一条的结束时间
事实表里面的saler_version直接根据add_time between start_time and end_time对应的saler_version，然后可以关联了吧……

至于更新的问题，要看你对于原数据的看法，如果觉得原来的数据没有用了，可以直接替换，修改order_updateime
如果觉得原数据还有参考价值，作增补
原来数据：
102015545 1 2010-9-12 6325141 2 35
增补数据
102015545 1 更新时间 6325141 -1 35

[liaosunny]

[Quote=引用 5 楼 me_online 的回复:]

引用 4 楼 liaosunny 的回复:
不知道是不是这样:
如,我有张订单的事实表,其中有:order_number,order_status等等,在从OLTP中拿数据时,假设,我是原表复制过来的,那我在数据仓库中再增加一列为:insert_time ,它的值就设为当时的:getdate()这样吗?
如果是这样的话,那我的表,会不会增长得过快了?


For the Order ……
[/Quote]

en,那订单的状态是会变的,而且,订单里的产品啊,数量都会变的,那这样怎么处理啊?或,有某张订单,会出现退货的情况?如果不加时间的话,那怎么处理啊?

[fpzgm]

1、对于人员部门变更，我的做法是给人员另外加一个字段，比如version，然后组成联合键进行关联
2、对于订单产品的变化，可以采用作差增补的方法，有的由于时间的原因数据没有补上的话直接update，因为update之前的数据没有任何意义

[alwaystar]

缓慢变化的维表：
代理键 生效日期 失效日期 员工ID 员工姓名 所属部门
------------------------------------------------------
1 20010101 20091231 A 张三 营业部
2 20100101 20991231 A 张三 市场部

事实表：
员工代理键 数据所属日期 事实数据
---------------------------------
1 20050101 100.00
2 20100501 220.00

归纳：
1、缓慢变化维可以认为是维度的关键属性发生变化时，根据变化时间将数据进行拆分并独立ID（代理键）化（个人观点描述，大体是这样）
2、维度中必须包含生命周期（有效时间段）和虚拟的ID（代理键），这样才能有效区分数据的变化
3、事实表中用维表ID（代理键）进行外键匹配，保证按照时间统计可区分维度属性的变化
4、事实表尽量包含一个数据所属日期，以保证数据是可逆的，也就是说当事实表损坏的时候可利用数据所属日期重新匹配维表(数据所属日期 between 所属日期)

[alwaystar]

更正：
数据所属日期 between （生命周期）

[BIConsulting]

Slowly changing dimension,渐变维，
参考
http://en.wikipedia.org/wiki/Slowly_changing_dimension

[emmylee001]

[Quote=引用 12 楼 fpzgm 的回复:]
引用 11 楼 liaosunny 的回复:
附上订单内容:
order:
ordersn order_status order_add_time order_updateime
102015545 1 2010-9-12 12:30:10

orderdetail
ordersn barcode amount price
102015545 6325141 2 35
假设

事实表里面的saler_version直接根据add_time between start_time and end_time对应的saler_version，然后可以关联了吧……
[/Quote]
对于 事实表的saler_version 直接根据add_time between start_time and end_time对应的saler_version关联,在ssas中应该如何新建关系呢？谢谢!!