数据仓库工具箱—需要避免的常见的维度建模错误

1违反事实和纬度的一致性要求

如果两个或更多的事实表与同一个纬度关联，则必须以高度负责的精神确保这些维度具有同一性或仔细选择各自的子集。当确认跨多个事实表的维度具有一致性后，就可以在不同的数据源之间进行钻取操作

2希望用户查询规范化的原子数据

最低级别的数据最适合于纬度设计且应该将其作为维度设计的基础，聚集数据失去了某些多维性。不能利用聚集数据建立维度模型并希望用户能够无缝地下钻到第三范式数据以了解细节，规范化模型有助于在ET L过程中准备数据，但是绝不能用于向商业用户表示数据

3使用报表设计维度模型

纬度模型与预期的报表没有任何关系。相反，维度模型是度量过程的模型，数字度量构成了事实表的基础。适合事实表的维度其内容应该是描述变量的环境，维度模型需要牢牢的基于度量过程的实际，而不是基于用户如何选择定义报表

4忽视对事实粒度的声明并混淆事实粒度

所有的维度设计应该始于对建立数字性能度量的业务过程的阐述。其次必须精确的定义数据的粒度，以最原子化的方式建立事实表。粒度级别将能够优雅的抵御随意的攻击。第三使围绕这些度量构建的维度，具有同样的粒度，保持粒度一致是设计维度模型的关键步骤

5使用操作型键连接维度和事实

维度的操作型键或智能键应该由简单的整数型从1到N顺序排列的代理键替换，其中N是纬度表的总行数

6使用更多的硬件解决所有的性能问题

聚集或者获取汇总表，是一种提高查询性能的低成本方式

7忽略对维度变化进行跟踪的需要

用户通常希望能够理解纬度表属性中至少某个子集的变化所带来的影响

8将层次划分为多个维度

层次是一种级联的多对一关系序列。例如多个产品上卷到一个品牌，多个品牌上卷到一个分类，如果某个维度以最低级别粒度来表示，例如产品，则层次中所有更高级别可以在产品行中以唯一值表示

9限制使用冗长的描述符以节省空间

总试图保持对纬度容量的控制，事实上在每个数据仓库中，纬度表从几何上看总是比事实表小很多。在每个维度中尽量提供描述性文本的详细描述。纬度表中的文本属性为B I运用提供的浏览、约束或过滤的参数，并为报表提供了行和列的表头

10在事实表中放入文本属性

涉及度量环境的描述性文本属性应该放入维度表中