第一天。

这是一个零售业的数据仓库设计，在此使用维度建模的工程方法进行维度设计，方法参照了《The Data Warehouse Toolkit: the Complete Guide to Dimensional Modeling》。我会在接下来的博客不断的完善，其中定然不泛会有不少改动。比如说日期维度一开始可能属性值并不是很多，因为在前期的设计模块中根本就用不着这些属性，为便于理解特意减少了属性的数量。到达后期的设计，需要加入一些财务模块的日期属性，届时会添加相应的财务日期属性。

管理一个零售业系统，从采购到仓库管理，再到销售，这些是核心环节，还有很多细节性的环节。短短几篇博客当然不能囊括所有的内容，我会择其一二进行细述，比如销售中的促销之类。

首先，先给此数据仓库进行下模块划分。我们从销售往订货方向进行展开，制定如下：零售管理，库存管理，采购管理，订单管理。

今天就做一个零售管理。根据维度建模的理论，我们逐步分析。

第一步，选择业务处理。

在此实例之中，管理方面要做的事就是更好的理解POS（Point Of Sales）系统记录的顾客购买情况。于是，建模所提供的的业务处理就相应成为一个POS零售业务。这类数据可以用来分析处什么促销条件下的什么日子里，在什么商店销售什么样的商品等方面的详细内容。

第二步，定义粒度。

业务处理确定下来了，接下来定义粒度。通过访问POS销售信息，能够得出一个关于商场销售非常详细的概况。虽然用户或许对与特定POS事务相联系的单个项目的分析不是很感兴趣，但数据库团队仍然无法预知出他们抽取数据的各种可能方式。某些层面上，他们需要详细到原子的粒度，而某些层面上则需要一些概括性的数据展示。比如，他们可能想弄清楚星期一相对于星期日在销售上的不同情况，这些就需要你提供一些总量的分析，也就是粒度的要求比较低。再比如，他们可能想了解有多少购买者会对优惠20%的小麦感兴趣，这些就需要提供详细的单价比对，销售量比对，销售额比对，也就是说对数据的粒度要求比较高。

第三步，选定维度。

一旦事务的粒度被选定，则时期、产品和商店方面的维度就应该随之被确定下来。可以假定，日历日期是由POS系统提供的日期值。产品需要进行分类统计、分析，所以产品也是一个维度。同时，我们还需要对各个商场的销售情况进行分析，商场也是一个维度。再次，销售过程中的促销手段可以带来营销利润，这是与其他同行竞争的不可或缺的部分，故而促销也是一个维度。

第四步，确定事实。

既然是零售管理，那所有的零售涉及的数据就要在一张逻辑表里面得到呈现。我们需要在一张逻辑表里面得知某个商品某时间在某个商场进行交易的价格。这就是事实表，通过设置表的主外键关系，事实表引用了所有其他维度表的主键从而形成了销售事实记录。

综上四步的设计，我们得到了文章之初的维度ERD。