Project REAL分析服务技术探讨

考虑一下对话框中行的数目也是一件有趣的事情。在我们用Year创建链接键之前，Month属性层次返回了13条记录。这就是当我们根据一个未知成员的月键，使用SELECT DISTINCT，你期望得到的结果。当我们添加了Year链接键后，新的处理会返回219条记录，因为SELECT DISTINCT语句中包括了年。

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

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

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

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

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

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

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

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

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

这就带来一个有趣的问题。如果你只是没有定义相关的属性，将发生什么？令人惊讶的是，一个有效层次返回了一个正确地结果，如图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 属性层次所取代。

最佳实践：将SQL Server 2000分析服务中的虚拟维度转换成属性层次

如果一个虚拟维度超过一个级别，那么能使用相关的属性作为级别，把它转换成一个用户定义层次。迁移向导(Migration Wizard)将帮你自动的完成这个工作。然而，当你手动的迁移或者在SQL Server 2005中重新设计的时候，你都应该意识到这些自动的转换。如果在虚拟维度总，仅有一个简单的级别，那么可以直接从数据模型中（和应用程序代码中）直接删除这个虚拟维度，直接使用属性关联即可。当你在考虑你的2005设计的时候，需要重新考虑每一个维度，并询问自己是否能将这个实体作为其它维度的属性？如果确实是这样，就可以用属性层次来代替。这能够降低系统的复杂性，对于终端用户也具有更多的意义。这些属性层次都揭露了原来的维度类型，并且这样做能增加一些对潜在的多维度设计的理解。

例如，原来Project REAL的设计中包含一个被称为Department的虚拟维度。它标识书籍能在那些仓库部门（例如硬皮或者软皮书籍）购买到。Department虚拟维度是从Item维度的一个成员属性上获得的，我们将它转化为Item维度中的一个属性层次。因而，终端客户能够清晰的看到相关联的Item，而不是Stores或者其它的维度。

共20页: 8 下一页

【内容导航】

原文：Project REAL分析服务技术探讨(8)