主要讨论的概念如下

1，维度属性，包括指标、数字话描述以及多层次
2，日历日期维度，加上当天时间维度
3，因果维度，例如：促销维度
4，退化维度，例如：交易数据号码

日期维度
日期维度和其他维度不同，可以提前建立日期维度表。可以在表中按行表示10年或者20年甚至是100年的不同日期。可以涵盖存储的历史，也可以包含未来的几年，日期维度表是相对较小的维度表。

日期维度表

日期维度样例

注意：
1，维度模型总会需要详尽的日期维度表。sql日期函数不支持范围广泛的日期属性，包括周，财务周期，季节，假日，周末等。与其试图将这些非标准日历计算放入查询中，不如放在日期维度表中，通过查询直接获得。
2，将当天的时间作为维度或者事实的时候，例如15分钟间隔，小时，换挡等。当天的时间通常从日期维度中分离出来，以避免提高执行维度计算的复杂性。
3，对于当前和相对日期的属性，我们交给BI应用去处理
4，对于日期维度中的文本属性和标志，例如是否是周末，是否是假日等。建议使用文本方式标识。我个人采用了代码编码标识，如图上图所示。

产品维度
产品维度描述仓库中存储的每一个SKU(产品统一编码)。多数零售商在其总部管理其产品主文件，并将部分子集频繁地下载到每个商店的POS系统上。为每个商品定义适当的产品主记录(唯一的sku)是管理层的职责。

1，扁平化多对一层次。通常不用担心扁平化对存储空间的要求。将重复的低粒度值保存在主维度表中是一种基本的维度建模技术。

产品维度表

2，设计具有内嵌含义的属性。在维度表中按照自然键概念确定的操作型产品代码，通常情况下具有内嵌含义，不同部分表示产品的不同特征，多个部分组成的属性都应该完整的保存在维度表中。例如操作型代码的第1到第4表示渠道商，第5到第10个字符表示制造商，则渠道商，制造商的名称也应该包含在维度表属性中。
3，所为属性或者事实的数字值。如果数字是用于计算，则应该属于事实表，如果数字能预先定义稳定的数字值，则应该当成维度属性。有时候，数字值同时可以用于计算以及过滤／分组功能，那么应该在事实表和维度表同时存储该值。
4，下钻维度属性。合理的产品维度可以包含50个左右描述性属性，每个属性可以作为约束和构建行头指针表识的来源，在维度模型上进行下钻，只不过是在维度表中增加了行头指针属性。上卷操作将移除行表头。

商店维度
1，多层次维度表。每个商店可以考虑为一个地址。可以按照任何地理属性对商店进行上卷操作，例如：邮编、国家、省、市。跨多个层次的属性名称和值应该具有唯一性。
图中的Floor Plan类型，Photo Processing 以及Financial Service类型都是短文本描述符，描述特定的商店，不要用一位字符代码描述他们，使用具有可理解的含义。
2，商店维度表中的日期。如果用户希望按照被标准日历去分组和约束，则通常需要和日期维度一起去使用

商店维度

促销维度
促销维度描述了促销的条件。促销条件包括临时降价，终端通道展示，报纸广告，礼券等。促销维度通常被认为是一种因果维度，因为他描述了认为可能导致产品销售发生改变的原因。

促销维度表
促销是否有效通常从以下几个因素考虑：
1，提升：促销产品的销售是否在促销期间获得大幅提升。
2，降低：促销产品在促销前，促销后，与促销期间的销售比较，是否有降低。
3，销售侵蚀：促销产品在销售方面表现良好，但是其他类似的产品销售却明显降低了。
4，市场增大：促销分类中的所有产品是否都获得了销售方面的净总增益，对比促销前，促销期间，促销后。
5，促销是否有利可图。促销的利润考虑整个促销分类的利润与基本销售利润之比，需要考虑促销期间的销售侵蚀以及促销开销的影响。

存粹从逻辑上考虑，通常将4个不同的因果机制(降价，广告，展示，礼券)区分开，建立不同的维度表而不是合并在一个维度中。
赞成合并在一起的理由如下(个人喜欢这种方式)：
1，如果4个因果机制高度关联，合并而成的单一维度，不会比任何一个单独维度大很多。
2，合并为单一维度浏览方便，观察降价，广告，展示，礼券的相互影响关系。
赞成放入不同表的理由如下：
1，对业务群体来说，当分别考虑不同机制时候，不同的维度可能更容易理解。
2，对不同维度的管理可能比合并维度的管理更直接

其他零售业维度
任何出现在事实表度量事件中的表示单一值的描述性属性都可以选为维度
有关某个维度是否应该和某个事实表关联的决策应该基于事实表申明的粒度来确定是或者不是
事务号码的退化维度
退化维度是没有对应维度表的维度键，例如事务空值号码，订单号码，发票号码，提货单号码，通常产生空。