维度设计

measure = 事实

context = 维度

没有测量事实，就只有定性概念和分类。

维度是用来分析上下文的，只有通过维度，才能发现——数据有没有变化，变化的背后有没有问题。

维度和属性在哪里发现？

如果是刚来的数据人员，通过观察已有数据产品（报表）、与业务人员沟通中获取业务关系的context。

因为一般他们是数据的使用者，最为了解需要关注何样的分类分组数据。

维度基本设计

维度设计过程就是在确定维度属性的过程， Kimball理论中提过，数据仓库的能力直接到维度属性的质量和深度成正比。

以维度建模为核心，要保证维度的唯一性。
先从主维表开始，以之为根。 一般是ODS表，直接来自业务数据库的同步对应表。
确定相关维度，数据仓库是多个数据源的整体系统，不同业务系统或者同一业务系统之间的维表可能存在关联性。 根据对业务梳理，要确定主维表的延伸。

例如商品名称、商品ID是主维表，而商品对应的分类，所属店铺，就是关联维度。

留意数值型维度

多数情况下，维度是分类字段（categorical variable)，但也会出现数值型。

比如商品价格，可以用来作为求平均、最大时以测量事实；
比如按价格区间： 0-99, 100-999,1000元以上执行分组的商品销售统计，这又是描述维度。
所以切勿将维度和事实表和数值与分类进行强硬划分。

维度沉淀

原始信息有些情况下能直接作为维度来使用，如 xxx.status 这个字段取0和1分别表示用户的两种状态。

但有一类场景是由原始字段加工而来的，如在线商品状态是指商品上架状态与发布时间限定在某个值以后。 为避免下游再次处理，或者多人使用造成口径的不一致，需要额外地将这个维度沉淀出来，对外提供这个信息。

维度层次结构

某些场景下，维度是一个多级结构或者是主从关系的。
比如商品的分类信息作为维度，一级分类、二级分类、三级分类... 这本身就是一个多级定义。

根据这个结构，可以沿着层次向下钻取。

核心维度表

商品、卖家、买家、类目等核心描述，应有且只有一个维度表，基于这些公共维度的交叉查询不会产生二义性。 这类维度表也称为共享维表。