维度模型的设计应该基于对业务需求以及操作型源系统数据现实的综合理解开展。从业务用户中收集到需求后，应该对设计的数据来源有概略的认识，单单依靠需求来驱动模型会不可避免的包含无法确定来源的数据元素。同时，仅仅靠对源系统的数据分析来驱动模型不可避免的会忽略对业务分析至关重要的数据元素。
纬度模型的设计应该反映组织的主要业务过程事件，维度模型不应该被设计为仅能发布特定报表或回答特定问题。
事实表应该尽可能以最细级别的粒度构建，这样可以获得最大的灵活性和扩展性。
事实表粒度确定之后，事实应该与粒度定义保持一致，为提高性能或减少查询复杂性，聚集事实（如年到日汇总后）有时会进入事实行中，这些汇总是非常危险的，因为它们不是完全可加的。尽管年到日汇总减少了复杂性和某些特定查询的运行时间，但当在查询结果中包含多个日期时，将它放在事实表中会导致年到日的双重计算，重要的是一旦事实表粒度确定后，所有可加事实都具有统一粒度。
应该禁止在事实表中使用文本字段，包括神秘的标识和标志。
与事实表关联的所有维度应具有单一值，作为每个事实表行的度量。同样，每个维度属性也应该在给定的维度行中具有单一值，如果属性具有多对一关系，则这类层次关系可以在每个维度中表示。可能的情况下，应该尽量将维度拆散或将其规范化。
如果纬度属性中的两个组存在多对多关系时，应该将它们建模为不同的维度，并在事实表中构建针对这些维度的不同外键。然而，有时你会遇到一些情况，需要将这些维度合并到单一维度中，而不是将它们建模到事实表中包含不同外键的两个不同的维度中。
事件被建模为事实表时包含一系列键，每个键表示参与事件的一个纬度，事件表有时没有与它们关联的变量度量事实，因此，将这样的表称为无事实的事实表。
需要避免的常见维度建模错误：
1、违反事实和维度的一致性要求。
2、希望用户查询规范化的原子数据。
3、使用报表设计维度模型。
4、忽视对事实粒度的声明并混淆事实粒度
5、使用操作型键连接纬度和事实。
6.使用更多的硬件解决所有的性能问题。
7.将层次划分为多个纬度。
8.忽略对维度变化进行跟踪的需要。
9.限制使用冗长的描述符以节省空间
10.在事实表中放入文本属性。
网友评论