Project REAL分析服务技术探讨（2）

以下是几个注释。首先，如果你使用Project REAL提供的一个相同的数据库，执行这个练习，在维度处理过程中，不会产生任何错误（警告或致命的错误）。你必须扫描你的维度，并留意成员没有出现在预定位置的情况。

记录键的唯一性被用于约束相关的属性。如果你没有指定相关的属性，那所有的属性都被关联到键。由于键必须是唯一的，那所有的都没有问题。然而，当你开始指定相关的属性，你大概能说出关于属性的一些事情。你会说，这个键是唯一的。注意在前面的例子中，当我们发现键不唯一而带来问题的时候，就是发现相关的属性了。

如果我们不能再生成唯一键，我们智能选择移去属性相关性。我们这么做之后，属性就智能直接的关联到键属性，键属性要求是唯一的。没有相关的属性使得产生一个高质量的集合设计成为一件不可能的事情。这也是分析服务中的对于“键”你最后应该注意的地方。最后再强调一样，一定要确保在整个维度中，所有你设计处理的键都应该是唯一的。

最佳实践：总是扫描你的维度，确保它们包含你预期的广泛的、甚至是分布的成员。

如果你看到一个专注于分布式的，然后发生了一些不可能的事情。要么就是唯一键没有标识出潜在的属性或者层次的顺序不准确。例如，你疏忽的指定了Year、Month、Quarter而不是Year、Quarter、Month。上述两种情况都会导致不正常的层次，但在处理过程中，不会有任何提示。

如果你打算定义一个属性关系，它们必须在数据上基于有效的模式。属性关联对于设计和实现一个高性能的系统是非常重要的。如果一个键结果导航系统执行一个错误的上滚操作会发生什么呢？例如，如果你在一个正常层次中颠倒了两个级别，会发生什么呢？

假定你正在定义一个Store正常层次的顺序是（All、Region、District、City、Store），实际上定义的却是（All、District、Region、City、Store）。正常的顺序是由属性关联来构建的。在这种情况下，这种单方面的被用于构建一个属性关联就不在被数据所支持。一种情况可能是一个Region能上滚到许多个District。然而这种计算是错误的。在运行时，数据被计算了两次，并且在层次上也是错误的。系统不能正常运行并返回错误的结果。所以，在定义属性关联的时候尤需注意，因此即使定义错误也不会返回任何错误。