主要讨论的概念如下
1，实际的销售模式
2，零售模式的扩展能力
3，抵制规范化冲动
零售业务中的实际查询是什么样的
场景：某用户，希望看到某年某月期间 某个地区通过促销快餐分类的销售总量。
可以按照图所示，按照日期维度中的月和年、商店维度中的地区，产品维度中的分类加以约束。
零售业销售模式查询
零售模式中如何扩展仓库的能力
场景一：如果发现维度的新文本描述符。
处理方式：
1，把这些属性作为新列增加进去。所有现存的应用将可以不受这些属性的影响继续工作。
2，如果这些属性只在特定时间点可用，则老的维度行中将插入不可用或类似的描述。如果用户希望通过新确定的属性跟踪历史数据变化，则场景更加复杂，可以通过缓慢变化维度处理。
场景二：如果发现新的维度。
处理方式：在事实表上增加外键列。将新维度的主键填写到该外键列上。
场景二：发现的新的可度量事实。
处理方式：
1，当新事实在同一个度量事件中可用，并与已经存在的事实粒度相同时候，这是增加新列，值填充至表中。
2，如果新事实仅仅在某个时间点可用，则将空值填充到旧的事实表行中。
3，当新的可度量事实以不同粒度出现时，此时建立属于新事实的事实表。因为在同一个事实表中出现不同粒度是错误的。
无事实的事实表
场景：例如处于促销状态，但是尚未售出的产品包括那些？
销售事实表记录的都是实际卖出的SKU。如果把那些包含0值的SKU都加入到事实表，则事实表将变得无比巨大。
处理方式：
无论产品是否卖出，我们每天(或者每周，等周期)每个商店中促销的产品加载一行。事实表确保能够看到被促销定义的键之间的关系，与其他事件例如产品销售无关。
如何确认促销产品中那些尚未卖出？
第一步：根据促销无事实的事实表确定促销期间的产品总数。
第二步：根据零售销售事实表已经卖出去的产品总数。
第三步：去上述两步结果的差集
促销所包含的无事实的事实表
抵制规范化的冲动
1，雪花模式是维度建模的合法分支，然而不主张采用雪花模式。雪花模式构成了一个复杂的结果。大量的表和连接操作造成性能问题。雪花模式有关节省磁盘空间的优势不是非常明显。对用户浏览维度的能力有负面影响。
产品维度的雪花模式
2，支架表，为某个事实表范围之内的维度建立附加的支架维度。尽管可以使用支架表，但是支架表不易被商业用户理解，限制了用户在单一维度中浏览属性的能力，尽量不要使用支架表。
允许使用的支架表实例
3，避免使用包含大量维度的蜈蚣事实表。即使蜈蚣表有紧凑的格式，事实表也是维度模型中的巨兽。包含太多的维度的事实表设计，将导致事实表需要更多的磁盘空间。这个和维度相比不是一个数量级的。在蜈蚣事实表中无法实现对大部分的的键构建有效索引。
建议多数业务可以用不超过20个维度的事实表表示，如果有更多的维度可以考虑合并关联维度。
包含大量规范化维度的事实表
作者：数据僧
链接：https://www.jianshu.com/p/2a24a3bdcbf2