数据仓库工具箱—处理维度变换

首先，确定采购是建模的业务过程，采购事务包括采购请求、采购订单，托运通知、发票和付款等

多个采购事务来自不同的源系统。购买系统负责提供购买需求和购买订单。仓库系统，负责提供发货通知和仓库清单，账户支付系统负责处理供应商付款。

是否应该建立一个包含用于观察所有采购食务的类型纬度的混合事务事实表，或者为每个事务类型建立不同的事实表。这个问题是设计上的一个两难问题，存在于很多事务环境中，不仅仅出现在采购款事务环境中。作为维度建模者，需要基于对业务需求的全面理解，并权衡源数据的现实情况，制定设计决策。

除了需要考虑多个采购事务事实表的决策外，还需要开发快照事实表，以全面解决业务需求。

累积快照是指应定义良好的里程碑建模的过程，如果过程不断持续，始终不会结束，采用累积快照并不是一个好的选择。

对每个维度表的属性，都需要考虑为其定义处理变化的策略。

类型0:保留原始值

类型1:重写：对其响应需要重写维度行中的旧值，以当前值替换，属性始终反映最近的情况。

类型2:增加新行

类型3:增加新属性

类型4:增加微型维度

类型5:微型维度与类型1支架表

类型6:将类型1属性增加的类型2维度。

订单管理。

订单事务事实表比较自然的粒度是每行表示每个订单的每个列表明细。

产品纬度是最常见最重要的纬度表之一。

大多数产品纬度都具有以下共同特征

大量冗长的、描述性的列

一个或多个属性层次，加上没有层次的属性

重新建立操作型产品代码到代理键的映射

增加描述性属性值以扩大或替换操作型代码

检查属性值，确保没有拼写错误，不可能存在的值、多变量等

将属性定义、解释、元数据来源文档化

客户维度为每个发送产品的不同地址建立一行客户维度按照不同的业务特性来划分，可能是中等程度大小或超大型

客户维度经常存在一个不同的层次。客户维度中另一个潜在的层次是制造商销售组织。是否应该被建模为不同的维度，或者增加到客户维度中去。如果销售代理与客户以一对一或多对多关系高度相关，则将销售组织属性与客户属性合并到一个维度中是一种可行的方法

当实体之间存在固定的、不随时间变化的、强关联的关系时，它们应该被建模到单一维度中

退化维度通常被保留作为操作型事务的标识符