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

核心提示： 图7：在属性层次和用户自定义层次之间的命名冲突你不能在将一个属性层次命名为Return Vendor，也不能将一个用户定义层次命名为Return Vendor，Project REAL分析服务技术探讨（2）(10)，因而在我们的设计中，我们扩展了在SQL Server 2000分析服务中使

图7：在属性层次和用户自定义层次之间的命名冲突

你不能在将一个属性层次命名为Return Vendor，也不能将一个用户定义层次命名为Return Vendor。因而在我们的设计中，我们扩展了在SQL Server 2000分析服务中使用的典型命名转换。在复杂的情形下，在名称经常被重用到的地方，我们用“By ”来命名用户定义层次（name代表了在用户定义层次中整备分析的属性）。对于这个对则也有一个例外。存在一些知名的关系，我们不必再做出澄清。例如Time.Calendar和$12.50。“By ”这个规则不是很适用。Time.By Calendar和Time.By Fiscal 看上去很不正常。但是对于那些用户定义层次和属性层次有相同名称的情况而言，命名转换是一个很有用的窍门。

将关系表中的列提升为多维度设计中的属性

每当我们检查Project REAL多维度设计的时候，我们经常问我们自己，是否需要在数据源视图的维度表中包含一个特殊的关系列作为一个属性视图。我们把这个过程称为提升（Promoting）列。

图8：提升数据源中的一个列作为一个维度的属性

例如，在数据源视图的维度表中，一个Item维度有超过144个可用的列。为所有的这些列创建属性并不能很有效的利用资源，因为一部分列在分析中从来没有被用到。最后，我们决定使用其中的44个列作为维度中的属性。

一个有趣的设计问题是是否需要将维度表中的所有列都应改添加（或者提升）到一个属性层次中。默认情况下，维度向导（Dimension Wizard）能够完成这项工作。它会将所有的列移动到一个属性层次。你不得不手动地把某些列从属性层次中去掉或者防止被提升（Promoting）。无论是不提升一个列使其成为属性还是依赖于关系型数据源的复杂性和丰富性，都是一个很好的选择。