一：什么是纬度
在数据仓库当中，纬度表和事实表是最常见的名词，事实表将度量值描述为事实，将纬度描述为度量值的环境，没错广泛的定义其实纬度就是描述事实的一个环境。举个例子，一张订单表，支付金额是具体的数值，属于度量值，在什么时间，买的什么商品，属于什么类目，这些就是描述事实的环境。在纬度表里面的字段往往被称做纬度属性。纬度属性在实际的应用当中往往会被用来作为筛选或者聚合条件，例如group by，order by等。
在实际的应用当中，纬度属性往往是以id+name的形式出现，比如说商品主纬度表，有商品id，也有商品name，id主要是用于join的条件，name主要是用于筛选，group by，order by的条件。
纬度属性以id的形式出现，比如说商品id，那么它是自然键，还是代理键呢，一般来将在业务系统那边都是采用递增产生的代理键，但是同步到了数据仓库当中，就属于自然键，因为它具有实际意义，这个id就代表了这个商品，这是唯一的。
二：纬度设计的基本方法
1.选择纬度或新建纬度
纬度是建模的核心，在企业级的数据仓库当中必须要保证纬度的唯一性，不能存在业务意义相同的两张纬度表。不然在后续的使用过程当中会产生混淆，不利于维护。
2.确定主纬度表
纬度表的设计，一般存在星型模型和雪花模型的区分，它们强调的重点都是将核心纬度放在主纬度表，相对次要的，访问频率低，更新频繁的纬度放在从纬度表。
3.确定从纬度表
确定好主纬度表以后，就需要将此主纬度表衍生出来的从纬度表建设好，比如说商品主纬度表，就能衍生出类目纬度表，商家纬度表，店铺纬度表等等。当然从纬度表也能在衍生出从纬度表，一般来将为了后续方便使用，不进行多层join关系，一般就设计成两层就好，也就是常说的星型模型，如果需要遵循三范式那样来设计的话，就可以设计成雪花模型，层数就大于2了。这样虽然使用不便，但是更容易突出核心，从纬度的变化也不容易影响核心纬度。
4.确定纬度属性
- 尽可能多的生成丰富的纬度属性
一般来讲在设计的时候尽可能的将能带上的纬度都将其带上，因为谁也无法预估未来业务的发展，说不定哪天就能用上这个纬度。但是要注意纬度表的设计，将不常用的纬度属性，或者经常变更的纬度属性，放在从纬度表。 - 尽可能多的给出一些富有意义的文字说明
纬度属性不应该都是一些id值，而是应该id和name一起，id用于join其它表，name用于一些条件筛选等。如果是将多值纬度放于一个字段，那么更应该描述情况枚举情况。 - 区分数值型属性和事实
数值型字段一定是度量值吗？这不一定，主要可看用途，如果是用于统计，比如说简单的累加，那么其就是度量值，如果将其作为离散值，作为筛选的区间，那么它也可以是纬度属性，主要看怎么用。 - 沉淀出通用的纬度属性
有些维度属性获取需要进行比较复杂的逻辑处理，有些需要通过多表关联到，或者通过单表的不同字段混合处理得到，或者通过对单表 的某个字段进行解析得到。此时，需要将尽可能多的通用的维度属性进行沉淀。
三：纬度设计的注意事项
- 纬度的层次结构
针对这种多层次的维度，一般可以有两种处理方式，一：以多个维度来进行展示。二：将这些层次结构以从维度表的形式来展示（主从纬度表设计）。选择第二种方式在针对这些层次维度来做分析时，就是会多join一张表。 - 规范化和反规范化
目前纬度设计参考模型主要有星型模型和雪花模型，雪花模型就是严格规范化的，表与表之间不存在任何冗余，但是数据仓库的建设初衷并不是数据库，我们主要是用于数据分析，适当的冗余可以有效的提高数据分析的效率，将表里面的纬度属性退化到父表的属性，这个过程就被称做反规范化。实践证明，在实际的数据仓库建设过程当中，一定要学会适当的反规范化。
