Project REAL分析服务技术探讨

可能的命名冲突

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

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

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

图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）。无论是不提升一个列使其成为属性还是依赖于关系型数据源的复杂性和丰富性，都是一个很好的选择。

我们体传了一些指导方针，帮助你确定什么时候将一个列提升为属性。你会发现这些信息非常有用。

◆首先，确定你是否需要对这个列进行分析。属性层次是一个最基本的方法，帮助终端用户完成分析。它们使用将它们选择的属性层次作为对象使用，点击或者拖拉，区分或者转动。如果一个列不是属性，它们将不能被操作或者分析。

统一空间模型（Unified Dimensional Model ，UDM）的真正力量在于它采取了一个丰富的属性层次集，能够帮助用户完成数据分析。这种分析可以使用预定义的对象，例如用户定义层次或者那些可以完成特殊操作的对象。属性层次对于特殊分析是很有用的。例如，你可能想分析比较某个地区精装书和简装书销售情况。用户定义层次Store.ByGeography允许你一直向下钻，知道你想要的一个级别，也就是地方或者地区。另以方面，你能够将Item.Department属性层次拖到网格上，网格中包含了关于精装书和和简装书的数量情况。如果你没有将Department提升到属性，你将不能完成这样的操作。

如果你希望将来在一个列上面能执行分析，那么你应该将它提升为属性。例如，Item维度表包含了一个被称为Original EAN的列。这个分配给书本的第一个EAN值。（这个数目将来可能会变化）。我们决定，终端用户不会做基于它的分析，因此我们没有显示它。由于当前的EAN数目还没有达到要求的地步，因此我们要马上将它提升为维度的属性。但是，我们可能犯了一个错误。如果将来有用户想使用这个列用于分析的机会，我们将把它提升为属性。

在一个大表中，你不能提升任何列。当一个表中包含很多潜在的可提升列，需要决定提升哪一个是一项挑战性的工作。例如，在Project REAL的Item表中有超过144个列，它们都可以被提升为属性。让用户自己来跟踪这些信息显然是不合情理的。

◆如果一个属性只有在层次上下文中才有一点概念上的益处（换句话说，它基本上没有分析的潜力），可以将它提升为一个属性层次（这样你能够把它添加到一个用户定义层次上），但需要将它设置成隐藏。这不会干扰终端用户的视线。

例如，我们设置Buyer.Buyer Alpha 属性层次为隐藏。这个属性层次只是Buyer层次中购买人员的名字的第一个字符，只是起到了导航的作用。我们不希望终端用户在名字的第一个字母上做一些单机的分析。

下面是当不必将一个关系列提升为属性层次的应用实例。

◆如果维度中的一个列没有机能上的依赖关系(在3范式上下文中)，那么就不用提升它。例如，Item维度表中大概有15个左右的列不依赖于Item。它们只是用来给这一些Item所代表的信息，规格化成列（也就是属性）。因为它们机能上不依赖于Item。因此，这些规格化的列不必在包含到Item的属性层次中。最终，我们从这些数据配置成我们想要的信息，但这部分并没有包含到Project REAL中。这只是因为包含在RDBMS表中的一个列并不一定要包含到多维度的数据模型中。

◆不用提升那些和维度没有仍和商业关联的列。在表中包含一些只是出于管理目的的列，并不是很少见。这些列并不描述实体（例如一本书或者仓库）。这种类型的列可能包含一个存储数据最后被更新的日期的列；或者包含一个是谁修改这个数据的列；或者创建记录的日期。由于它们和维度没有任何关联，因此，这些列不用被提升为属性。

共20页: 9 下一页

【内容导航】

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