数据仓库缓慢变化维度解决思路

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

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

[解决办法]

SQL code

不懂，帮顶，学习，蹭分.
[解决办法]

[解决办法]
探讨

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

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


[解决办法]
缓慢变化的维表：
代理键  生效日期  失效日期  员工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 所属日期)
[解决办法]
探讨

附上订单内容:
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……

[解决办法]
Slowly changing dimension,渐变维，
参考
http://en.wikipedia.org/wiki/Slowly_changing_dimension