四、维度建模实践案列-零售业务(中)

主要围绕维度表设计，关注健壮的属性细节；

3.1 日期维度

日期维度是一张特殊的维度表，几乎所有维度模型中，都有日期维度；

与其他维度不同，日期维度可以提前建立，可以按行表示过去、现在、将来的日期，日期维度不会太大，就算包含20年的日期维度，也仅仅约7300行；

通常情况下，时间维度表的数据并不是来自于业务系统，而是手动写入，并且由于时间维度表数据的可预见性，无须每日导入，一般可一次性导入一年的数据。

案例,具体时间维度根据所在行业需要调整：

开发提示：在开发中，很多情况需要计算某个财务周期、节假日、某个周末、某个时间差等，直接使用sql函数不方便，可能很多函数不支持，那提前把这些维度数据放在维度表中，直接使用就变得很方便；

注意：

• 文本属性的标识和标志

  促销活动中，如果想知道节假日与非节假日促销效果，需要关联维度表，日期维度假日标识可能就是两个简单的标识(Y、N),从标识来看不能马上知道具体含义，简化这个流程，将编码替换成节假日/非节假日，直接简单明了不是很好吗？

  类似的套路可以用在工作日、周末等中；

• 当前与相对日期属性

  维度中，大多数日期维度不应该更新，比如IsCurrentDay表示当前时间，需要每天更新，还有某些属性具有滞后性，比如0表示今天、-1表示昨天、+1表示明天等；这些属性如果作为维表物理存储与维护，耗时耗力；这类属性适合作为计算列而不是作为物理列存储，这些滞后列没有存在维护的必要；

• 将当天时间作为维度或事实

  在数据分析中，如果你基于当前时间按照分钟级别维护到维度表，基于维度表每隔1分钟做一些汇总操作，最终的维度表将会变得很大，可以选择把当天时间作为维度表单独维护；

4、产品维度

产品维度其实就是表示每个SKU的描述性信息属性

4.1扁平化多对一层次

下图就是一张常见产品维度表属性字段

下图是笔者以前公司产品维度字段属性

从维表字段来看，表中包含SKU大多数描述信息，单个SKU可以上卷到品牌，品牌上卷到类别，类别分成多个层次；

产品下卷到平台属性、销售属性；每个层次都存在多对一的形式，比如多个产品对应一个品牌；

在维度表中，产品品牌、SKU描述等这些基本信息，具有唯一性；

如果产品很多，表中有大量重复属性；如果按照规范化方式设计维度表，这些冗余信息会被单独放在另一张表，通过关联取得；这种设计会造成性能损耗(雪花模型)；

将重复低粒度值保存在主维表是一种基本的维度建模技术，规范化这些值将其放在不同表将难以实现简单化与高性能的主要目标

4.2下钻维度属性

在维度模型上下钻只不过是在表头中从维度表获取特定行头，上卷移除表某些行头，下钻在表中添加更多行头

案例：

5、商店维度

商店维度描述零售连锁的每个门店

5.1多层次维度表

这里商店维度是本案列中主要的地理维度，每个商店在不同地址，可以按照地理属性对商店进行上卷操作，比如按照邮编、县区、省、国家等多个维度进行汇总操作；

在一个维度表中表示多个层次并不常见，跨多个层次的属性名称和值应该具有唯一性；

本案列中商品维度：

6、促销维度

促销维度描述销售商品促销条件

促销条件包括临时降价、报纸广告、礼券广告等

促销维度对一个公司来说很重要，作为一个管理者总是想知道公司那些促销渠道促进产品销售；

管理者还想知道促销产品在促销期间是否获得较大效果？

促销品促销前后销售情况如何？

促销是否有利可图？

同时采用多种促销机制是否有助于提升产品销售？

促销活动之间是否有影响？

下面是促销维度表：

7、实际销售模式

通过上面结合实际业务分析，可以得到很多类型的维度表，下面事实表结合维度表，得到大宽表，基于宽表，你可以在不同维度做上卷、下钻操作；

从图就能看到维度建模的简洁之处，如果随着业务发展有新的维度出现，新维度添加很方便，可以把相这些新属性添加到某张已经存在的表，或者单独建立一张独立的维度表，和事实表关联；

小结：本节主要结合实际业务，简述如何设计各种不同的维度表；本节主要围绕零售销售事实，设计了产品维度、促销维度、商店维度，其他维度设计思路相同，这里不一一简述；

下一小节将继续讨论事实表相关的案列
查看更多内容可关注微信公众号