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

核心提示： 最佳实践：如果你告诉系统属性是关联的，则它们必须是关联的，Project REAL分析服务技术探讨（2）(8)，数据必须支持关联，另外，还包含了一个Department正规维度（这个维度构建于一个Item维度的视图），在最终的设计方案中，键的唯一性必须允许这些关联能够被执行，这就带来一个有

最佳实践：如果你告诉系统属性是关联的，则它们必须是关联的。

数据必须支持关联。另外，键的唯一性必须允许这些关联能够被执行。

这就带来一个有趣的问题。如果你只是没有定义相关的属性，将发生什么？令人惊讶的是，一个有效层次返回了一个正确地结果，如图6所示。

图6：没有定义属性关联的Time

图6所示的层次看上去是有效的。当你查询一个系统，数目都是正确的。问题在于，没有相关的属性，系统无法意识到属性之间重要的关系。这种关系标识一个上滚是能够在层次上预先计算好的（SQL Server 2000分析服务使用集合达到这个目的）。相反，系统不会在查询计算的时候使用它的运行时来完成上滚。由于没有设计集合，因此你没有告诉系统层次里面的属性是相关的。所以，你得到一个清晰的层次并很好的列举了层次，但是你不能使用预先计算的集合用来计算子集，因此性能收到了影响。

将虚拟维度转换成属性层次

不幸的是，在我们的Project REAL中，我们不能包含我们在转换到SQL Server 2005之前在SQL Server 2000分析服务中设计的文档。相比于最终的设计，原先的设计要更加简单一些。现在差不多有一打的维度被去掉了。取而代之的是属性层次，绝大部分都是在Item维度中。例如，原先的系统携带了五个虚拟的维度，这些维度是在Item维度中，基于厂商关联建立起来的。 因此，在原先的设计中，都是用维度来针对Source Vendor，Return Vendor、Purchase Vendor等。那么在使用SQL Server 2005 的REAL的最终设计中，它们分别被Item. Source Vendor, Item.Return Vendor等属性层次所取代。在原先的设计中，还包含了一个Department正规维度（这个维度构建于一个Item维度的视图）。在最终的设计方案中，也被Item.Department 属性层次所取代。