建模经验整理--20120310

Drill Across处理

在维度建模的数据仓库中，有一种操作叫Drill Across ，中文一般翻译为“交叉探查”。鉴于经验的局限，在这里我只能进行一下浅显的分析。

在基于总线架构（Bus Architecture）的维度建模中，大部分的维度表是由事实表共有的。比如“营销事务事实表”和“库存快照事实表”就会有相同的维度表，“日期维度”、“产品维度”和“商场维度”。这时，如果有个需求是想按共有维度来对比查看销售和库存的事实，这时就需要发出两个SQL，分别查出按维度统计出的销售数据和库存数据。然后再基于共有的维度进行外连接，将数据合并。这种发出多路SQL再进行合并的操作就是交叉探查。

当这种交叉探查的需求很常用时，有一种建模方法可以避免交叉探查，就是合并事实表（Consolidated Fact Table）。合并事实表是指将位于不同事实表中处于相同粒度的事实进行组合的一种建模方法。即新建立一个事实表，它的维度是两个或多个事实表的相同维度的集合，事实是几个事实表中感兴趣的事实。这个事实表的数据和其他事实表的数据一样来自Staging Area。

合并事实表在性能和易用性上都比交叉探查要好，但是被组合的事实表必须处于相同的粒度和维度层次上。

主子表的维度模型设计方法

首先对“主子表”这个词进行一下解释，举例来说，对于一个销售单来说，通常业务建模会有两个表，一个是销售主表，记录销售的总体信息；另一个是销售子表，记录销售的每个产品的信息。类似销售主子表这样的应用，在没有想到更恰当的词之前，我暂将其称之为“主子表”。以区别于为不知层深而建立的可以多层的单张 “父子表”。

在维度建模中，可以将这种“主子表”建立两个事实表，销售事实表和销售分列项事实表，分别记录两个级别的维度和事实，但是这并不是一个好的方法。因为这样建模时，我们无法对销售事实表中的事实在保留产品维度时对其他维度进行上卷操作。

解决的办法是将销售事实表中的事实数据分派的销售分列项事实表中，这个分派的工作需要用户的理解和支持。

这样销售事实表就可以不要了，一张销售分列项事实表就可以满足需求。

浅析退化维度

在维度建模的数据仓库中，有一种维度叫Degenerate Dimension，中文一般翻译为“退化维度”。这种退化维度一般都是事务的编号，如订单编号、发票编号等。这类编号需要保存到事实表中，但是不需要对应的维度表，所以称为退化维度。

退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，尤其是对维度建模的入门者。

退化维度经常会和其他一些维度一起组合成事实表的主键。在Kimball提出的维度建模中，事实表应该保存最细粒度的数据。所以对于象销售单这样的事实表来说，需要销售单编号和产品来共同作为主键，而不能用销售日期、商场、产品等用来分析的维度共同作为主键。

退化维度在分析中可以用来做分组使用。它可以将同一个事务中销售的产品集中在一起。