维度表是事实表 不可或缺的组成部分 。维度表包含与 业务过程度量事件有关的文本环境。它们用于描 述与“ 谁、什么、哪里、何时、如何 、为什么” 有关的事件。

与事实表比较 ， 维度表趋向于包含较少的行。但由千可能存在大量文本列而导致存在多列的情况 。每个维度表由单一主键定义，用于在与事实表连接操作时实现参照完整性的基础。

维度属性可作为查询约束、分组、报表标识的 主要来源 。对查询或报表请求来说， 属性以词或词组 加以区分。例如， 当用户希望按照品牌来查看销售额时， 要查看的品牌必须存在于维度属性中。

维度表的属性是所有查询约束和报表标识的来源，属性应该包含真实使用的词汇而不是令人感到迷惑的缩写。应该尽量减少在维度表中使用代码， 应该将代码替换为详细的文本属性。

多数情况下，数据仓库的好坏直接取决于维度属性的设置；DW/BI 环境的分析能力直接取决千维度属性的质量和深度。为维度属性提供详细的业务术语耗费的精力越多，效果就越好。为属性列填充领域值耗费的精力越多 ， 效果就越好 。为确保属性值的质量耗费的时间越多， 效果就越好。强大的维度属性带来的回报是健壮的分片－分块分析能力 。

维度提供数据的入口点 ，提供所有 DW/BI 分析的最终标识和分组

在分析操作型源数据时，有时不清楚一个数值数据元素应该是事实 性还是维度 属性。可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量，  这种情况下该列往往可能是事实；或者该列是对具 体值的描述 是一个常量、某一约束和行标识的参与者， 此时该属性往往是维度 属性。

对维度模式首先需要注意的是其简单性和对称性。显然，简单性对业务用户有利，因为数据易于理解和查询。

维度模型的简单性也带来性能方面的好处。数据库优化器处理这些很少使用连接操作的简单模式会更高效。

维度模型非常适于变化。维度模型可预测的框架可适应用户行为的变化 。每个维度的地位都相同 ， 所有维度在事实表中都存在对应的入口点。对期望的查询模式 ， 维度模型没有任何偏见。

粒度最小的数据或原子数据具有最 多的维度。尚未聚集的原子数据是最具有可表达性的数据。这些原子数据是构建能满足用户提  出任意查询的事实表的设计基础。对维度模型来说， 可以将全新维度增加到模式中 ，只要该维度的单 一值被定义到已经存在的事实表行中。