数据仓库工具箱——维度建模(Dimensional Modeling)摘要（二）

申明：本文若有任何晦涩难以理解之处，敬请留言指明，以求简明通俗。

 

      维度设计的四个步骤：

      1、选择商业过程。应该选取最有影响的、最有价值的那块先进行。这也是符合敏捷里Scrum的原则。

      2、申明商业过程的粒度。取最细节、最原子的粒度。

      3、选择维度。粒度已经决定了基本维度，同时可以增加更多维度。如果增加的维度导致产生了更多的事实行，那么粒度就需要重新申明。换句话说，原先的粒度并不是最原子、不可分的。

      4、识别事实。这里举例销售量、销售额（单价X销售量）和成本额（成本X销售量）作为事实。

      毛利润等于销售额减去成本额，它在各个维度中都具有极好的可加性。我们建议物理地存储毛利润，这样可以消除用户出错的可能性。用户错误计算造成的代价远高于存储的成本。还有一种建议是使用视图来达成正确性并节省存储。如果所有访问都通过该视图，不允许有例外，那么这个方式是比较可行的。另外一种想法是在查询工具中进行计算，但现实经验是我们很少会只用单一的共同的工具存取数据，所以这个方法不建议。

      毛利润率等于毛利润除以销售额，它在任何维度中都不具有可加性。因为百分比或比率是非可加性的。分子与分母都应该存储在事实表里，然后通过查询工具求出比率。这里求取的是和值的比率，而非比率的和值。

      单价也是非加型事实。

      在设计初期，估计最大事实表的行数是很有帮助的。可以简单的问业务源系统的专家，一个合理的时段内有多少事务生成。还可以通过年销售额除以平均售价，估算一年的事务数。

 

      关于日期维度的属性，希望能起到抛砖引玉的效果。

      这里一般会有一个叫“星期(Day of Week)”的列，表示这天是星期几。业务源系统里可能会用0-6或者1-7来表示这七天，我们也可以额外用一列来保留业务源系统里的值，但在维度表里，肯定要有一列用“星期一(Monday)”这类可以直接在报表里当标签使用的值。特别是Y和N，0和1这类是非指示符(Indicator)，强烈建议显式地标签化。

      其他有助于分析的列：日(Day Number in Calendar Month)（从1到30或31），月(Calendar Month Number)（从1到12），月份(Calendar Month Name)（从一月(January)到十二月(December)），年月(YYYY-MM)，季度（从1到4），季度编号（Q1到Q4），年季度编号（2010-Q4），节假日指示(Holiday Indicator)（节假日(Holiday)或非节假日(Nonholiday)），工作日指示(Weekday Indicator)（工作日(Weekday)或周末(Weekend)），财年相关的一套日历等等所有分析需要用到的都可以考虑进去。

      此外建议的还有，销售季节（比如圣诞、情人节、非节日等），主要事件（比如911或者金融危机等可能对分析数据由影响的特殊事件）。一般性的促销活动(promotion)不会在日期表里处理，而会在额外的promotion维度表里处理。因为这类活动不是仅仅关系到日期，同时还关系到特定的产品和商店。

      这里用的是日期维度。如果需要与时间相关的维度，应该存储在单独的时间维度表里。考虑到组合维度数量的庞大，两个维度表应该分开更合理。但多数情况，时间维度表并不是那么必须的。

 

      关于产品维度表，一般零售商在总部会有一个统一的产品主文件，可以从该文件来获得这类数据。产品维度表最关键的准则就是层级关系在一个维度表里体现，此时允许冗余。其实前一章已经提过，不需要分离单独的表来达到范式化。但值得注意的是，产品维度表里的某些属性可以和该层级体系无关，同时我们允许维度表里存在一套以上的层级体系。

      向下钻取(drill down)就是增加维度表里的一些属性列，向上钻取(drill up)就是减少维度表里的一些属性列。

 

      商店维度表里的销售面积是数值型且可加的，但由于其不变性和更多地使用在约束性上，我们将它归到维度表。商店维度表里的开业日期列是一个连接到日期维度视图的外键。我们为它创建一个视图，视图名和列名都要重新命名以区分原表。这种维度表的外键连接的维度表称作支架(outrigger)。

 

      促销维度表是一个因果维度，促销必然导致销售发生变化。促销结果评估的因素：较之基线(baseline)的增长(lift)、促销期前后的减少、促销产品附近产品滞销、所有促销产品是否都有市场增长、除去促销成本是否赢利。

      促销维度表推荐的列：Promotion Name, Price Reduction Type, Promotion Media Type, Ad Type, Display Type, Coupon Type, Ad Media Name, Dispaly Provider, Promotion Cost, Promotion Begin Date, Promotion End Date等等。

      促销维度表里需要包含一行“不在促销列”从而避免那些非促销产品的空值外键。为保持引用一致性，在维度表里相应地插入一行标识该维度不可用，以避免事实表里的空外键。

 

      雪花模型会影响位图索引的使用。而位图索引在low-cardinality的字段上非常有效率。

 

      关于维度表的数量。绝大多数情况下，少于15个维度表就足够了。如果大于25个维度表就应该将相关的维度表进行合并。如果合并维度表显著小于两个小表的笛卡尔积，那么合并该表是比较明智的。

 

      使用代理键(surrogate key)，简单说就是要为维度表生成独立的无意义的整型主键。独立于源系统的键值，从而不会受源系统操作的影响。如果使用有意义日期直接作为主键，那么“日期不可用”这样的值就无法表达了。整型主键只要4字节，也就是32位，能提供大约20亿条（2的31次方）主键。同时，代理键也是渐变维度的基础。通常情况下，我们不会对退化维度分配代理键，但是如果该退化维度在跨地域或其他范围内不具有唯一性，那就有必要引入代理键了。又如该退化维度是一个24字节的数字加字母列，则可以考虑使用代理键，不退化该维度。

 

      Market Basket Analysis是产生于对同时出现在一个购物车/订单的两个商品放在一条数据行里进行分析的技术。用来分析类似于“尿片与啤酒”现象的方法。将同一订单里的商品两两配对，使用两个商品列（例如A产品列和B产品列）、两个商品计量单位列、两个商品销售总额列等。然后还有一列篮子计数(Basket Count)计算该组产品出现在一个篮子里（也就是某一组商品出现在一张小票里）的次数。篮子计数是半可加的，因为三个以上的商品两两配对就会出现重复。这是需要小心的。同时可以为配对的商品外键引用，创建单一专门的维度表。

      N个产品在一个订单里，会产生N*(N-1)对有序组合或者N*(N-1)/2对无序组合。这是个乘方级别的增长。鉴于实际有意义的分析是被频繁组合在一起并且组合比例（数量或销售额）处于某种平衡的商品。因此这里引进一个修剪算法：先使用商品的高层级关系（例如商品类目）进行筛选，然后逐级降低到商品。