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

核心提示： 最佳实践：将SQL Server 2000分析服务中的虚拟维度转换成属性层次如果一个虚拟维度超过一个级别，那么能使用相关的属性作为级别，Project REAL分析服务技术探讨（2）(9)，把它转换成一个用户定义层次，迁移向导(Migration Wizard)将帮你自动的完成这个工作，我

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

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

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

可能的命名冲突

在同用户定义层次一起工作的时候，你可能会遇到命名上的冲突。这是因为用户定义的层次和属性层次一样共享了一样的命名空间。在SQL Server 2000分析服务中，有两种类型的名称：

维度/层次名称和级别(Level)名称。在分析服务2005中，有三种类型的名称空间：维度、用户定义层次和属性层次。因为用户定义层次和属性层次有相同的命名空间，因此就产生了潜在的命名冲突。

例如，你已经有一个名称为Buyer的维度。由于很多前端工具只显示层次的名称，所以你可能会创建其它名称为Buyer的层次。在分析服务2000中，你可以这么做。现在的挑战在于，如果你创建了一个名称为Buyer的层次，你将不能再创建一个名称为Buyer的属性层次。在Project REAL中，我们把属性层次重新命名为Buyer Name。如图7所示，所有相关的对象都必须唯一的被命名。