解决这种问题就需要定位到出问题的数据。而生产环境中数据量一般会比较大，我们不大可能检查所有数据来发现可疑数据，这个时候，SSAS给出的错误提示就很有帮助了。

通常遇到处理异常，SSAS会有两种错误信息提示，一种是

Errors in the OLAP storage engine: The attribute key cannot be found: Table: TableName, Column: ColumnName1, Value: Value1. Table: TableName, Column: ColumnName2, Value: Value2.

这个错误提示会给出数据源中出错的数据，是在哪个表的哪个字段哪个值出的问题。

还有一个是

Errors in the OLAP storage engine: The record was skipped because the attribute key was not found. Attribute: generated attribute X of Dimension: DimensionName from Database: DatabaseName, Cube: CubeName, Measure Group: MeasureGroupName, Partition: PartitionName, Record: RecordNumber.

这个错误信息给出的是Analysis数据库中出错的位置，是哪个AS数据库的哪个数据立方体的哪个维度的哪个维度属性出的问题，以及出错条目编号是多少。

如果出错数据比较好辨认的话，那么我们可以直接在源数据库中使用like操作符查询相关的条目即可。例如下面这个例子：

我们可以很快将出错数据锁定在一个较小的范围。但是如果错误信息像下面这样：

你可能就没那么好定位了，这个时候我们就需要第二个错误提示的帮助了。

为了在处理失败时显示第二个错误提示，我们需要修改维度的ErrorConfiguration属性。打开维度的属性面板，展开ErrorConfiguration中的KeyNotFound，BIDS中如果你新建一个维度，那么默认配置会像下面这样：

如果处理失败，是不会显示第二个错误提示的。我们需要将KeyNotFound设置为ReportAndContinue，或者直接把整个ErrorConfiguration从(custom)改成(default)。

这样我们就能得到第二个错误提示了，第二个错误提示中有一个“记录(Record)”的编号，那么这个编号代表什么含义呢？

我一开始直觉的认为是EmployeeKey的主键键值，后来发现不对，于是猜测是处理时执行的Sql查询返回的结果集的行编号，后来发现又错了。

在经过一番测试后发现，错误提示中的“记录”编号，确实是和Sql查询返回的条目的行编号有关，但却有一定的偏移，一般情况下这个偏移值为1，也就是说，假设SSAS告诉你“记录”7出错了，那么就是第6行的数据出错了。

但有时候这个偏移不一定是1，有可能是2。至于规律和原因我暂时没找到。所以你只需要把出问题的维度属性相关的Sql查询放到Sql Server中运行一遍，然后根据错误提示中的“记录”号找到那附近的几行数据，一般就可以成功定位到错误数据了。

——Kevin Yang

你可能对下面的文章感兴趣

• 64位系统下IIS7 ISAPI处理器加载失败
• Analysis Services 2005 OLAP设计最佳实践
• Analysis Services：你应该使用多对多维度吗？
• BIDS对于维度属性键为可变长列时存在的Bug
• BIDS部署时出现元数据管理器发生错误
• OLAP中的AverageOfChildren聚合方式
• 全半角空格导致的Analysis Services处理错误
• 权限不足导致的Analysis性能计数器在Vista/win2008下失效的问题
• 解决维度成员中的非法Xml字符导致的查询错误

公司一台数据库服务器上部署了IIS网站（IIS7），利用Sql Server Analysis Services的msmdpump.dll组件，实现了通过HTTP层来访问Analysis Services（MSAS不支持HTTP远程访问，非HTTP的远程访问也一直没成功过）。运行状况一直良好，最近突然罢工。Debug发现在建立连接的时候总是抛出“The Connection either timed out or was lost”。

诊断

尝试用企业管理器直接连接Analysis Services，成功，数据访问也正常，说明Analysis Services服务运作正常。那看来问题是出在了IIS这一层。

直接在浏览器中通过http://machinename/olap/msmdpump.dll去访问的时候，会弹出一个保存文件的对话框。正常情况下，服务器会返回500，因为没有数据输入。现在弹出保存文件的对话框，说明IIS把这个dll资源当作一个普通文件来对待了，而不是调用ISAPI处理器来处理。

细看了网站的配置，似乎没有问题，重新部署了一个网站，重新配置了ISAPI处理器映射，问题依旧出现。

自己探索了很久，未果，Google了很久，一篇文章（IIS7 - Running 32-bit and 64-bit ASP.NET versions at the same time on different worker processes）提醒了我。这篇文章讲的是如何在不同的应用程序池进程上同时使用32位和64位的Asp.Net。

公司服务器出于性能考虑，用了64位系统。相应的msmdpump.dll文件也是64位的，但IIS的应用程序池进程是多少位的，我倒还真没考虑过。任务管理器一看，只有一个"w3wp.exe * 32”，果然是32位的。那问题的原因应该是，32位的应用程序池无法加载64位的Isapi处理器。

知道了问题所在，解决方法也很简单，启动一个64位的应用程序池就行了。打开应用程序池的高级设置，找到了“启用32位应用程序（enable32bitAppOnWin64）”的设置，将其从原来的True改成False（默认值为False）。这个选项的作用就是允许在64位操作系统上，以32位的应用程序池去加载32位的程序。

之所以会突然出现这个问题，是因为IIS的机器配置文件ApplicationHost.config文件中，全局应用程序池的enable32bitAppOnWin64默认值被意外修改为True。而我部署的IIS网站，由于没有显式设置此选项，因此会继承ApplicationHost.config文件中的默认值。

举一反三

64位系统下经常会出现一些莫名其妙的问题。因为64位系统允许运行32位应用程序，但是32位程序却无法加载64位程序集。所以如果你发现你的32位程序无法正常启动，查一查是否因为目标程序集是64位的缘故。例如最近安装了微软的StreamInsight，发现是32位的，但是本地的Sql Compact Framework是64位，结果启动的时候抛出了个DllNotFoundException。

——Kevin Yang

你可能对下面的文章感兴趣

• Analysis Services 2005 OLAP设计最佳实践
• Analysis Services：你应该使用多对多维度吗？
• BIDS部署时出现元数据管理器发生错误
• IIS7配置Gzip压缩
• IIS中使用子目录文件作为默认文档（Default Document）替代重定向
• OLAP中的AverageOfChildren聚合方式
• Silverlight启用Assembly Caching之后铁通用户无法访问
• SSAS处理时“找不到属性键”的解决办法
• 【推荐】两款HTTP流量分析工具的比较
• 为什么IIS7/7.5的Gzip不起作用

作者：Denny Lee

译者：Kevin Yang

英文链接：http://sqlcat.com/technicalnotes/archive/2008/02/11/analysis-services-should-you-use-many-to-many-dimensions.aspx

如果你是一个初学者，请注意，这篇文章并不是告诉你不要在Analysis Services中使用多对多（m:n）维度。事实上，这是一个非常棒的功能，它允许你将多个维度成员和多条事实数据之间建立关联关系。在很多商业领域，从零售行业到会计行业到医疗行业，多对多关系被大量使用着。但有时在处理多对多关系时，如果遇到大规模数据量，可能会遇到数据查询性能问题以及数据精准性问题。这篇技术文章就是为了说明多对多关系背后的工作原理和适合的商业应用场景，以及应用多对多关系可能带来的数据精准性问题。

相关背景

我在我之前的博文“How to handle many-to-many relationships in Yukon?”中提到的应用多对多关系的一个例子是地理维度。但现在我们将使用Adventure Works DW OLAP这个示例（相关代码在Codeplex的SQL Server 2005 SP2 Sample Databases上可以下载到）。

打开AdventureWorks数据库，在AdventureWorks数据立方体的“维度使用”标签卡下，我们可以看到[Sales Reason]维度通过[Sales Reasons]中间度量组关联到了[Internet Sales]度量组（图中没有显示）上。[Sales Reasons]旁边放了一个数学上用于表示“无穷”的图标，说明这个关系和常规维度（就像[Source Currency]维度和[Source Currency Code]度量组的关系）不一样，这是一个多对多关系。

单击[Sales Reasons]度量组，会弹出一个设计维度-度量组关联的对话框（见下图），在这里，你会注意到，[Sales Reason]和[Internet Sales]这两者之间的关系是多对多关系，并且，连接[Sales Reason]维度和[Internet Sales]度量组的中间度量组是[Sales Reasons]。

以下这张图说明了在这个场景中使用多对多维度的目的。我们希望把多个销售成功因素（例如价格很低，展示效果不错，或者其他因素）和一笔销售订单关联起来。

举个例子，John购买了一个高清电视机（对应事实表Internet Sales的一条记录），是因为最近正在大减价（销售成功因素：价格）并且超级联赛杯快要开始了（销售成功因素：其他）。

应用场景示例

我们回过头来看看[Adventure Works]的Sql以及Olap数据库的设计，这样可以更好地从技术上去理解多对多关系。在之前我们看到的[Adventure Works DW]Olap数据库中包含了[Internet Sales]和[Sales Reasons]度量组，以及[Sales Reason]维度。在AdventureWorks的Sql数据库中，这几个对象分别对应着FactInternetSales、FactInternetSalesReasons以及DimSalesReason表。

继续我们上面的例子，为了简单起见，我们只关注两条数据(SalesOrderNumber = 'SO69868', SalesOrderLineNumber = 2) 和(SalesOrderNumber = 'SO75088', SalesOrderLineNumber = 3)。

Sql查询为：

select SalesOrderNumber, SalesOrderLineNumber, SalesAmount
from FactInternetSales
where (SalesOrderNumber = 'SO69868' and SalesOrderLineNumber = 2) or
(SalesOrderNumber = 'SO75088' and SalesOrderLineNumber = 3)

结果集：

当你开始考虑FactInternetSales和FactInternetSalesReasons的多对多关系，需要将SalesReason表也加进来，你需要执行以下Sql查询：

select a.SalesOrderNumber, a.SalesOrderLineNumber, a.SalesAmount,
c.SalesReasonKey, c.SalesReasonName, c.SalesReasonReasonType
from FactInternetSales a
inner join FactInternetSalesReason b
on b.SalesOrderNumber = a.SalesOrderNumber
and b.SalesOrderLineNumber = a.SalesOrderLineNumber
inner join DimSalesReason c
on c.SalesReasonKey = b.SalesReasonKey
where (a.SalesOrderNumber = 'SO69868' and a.SalesOrderLineNumber = 2) or
(a.SalesOrderNumber = 'SO75088' and a.SalesOrderLineNumber = 3)

新的结果集如下：

从这两张表中你也可以看出，通过中间表FactInternetSalesReasons，你可以将多条销售成功因素记录关联到同一笔销售订单上。例如上述的SO75088订单，金额为$34.99，关联着“价格”和“其他”两条销售成功因素记录。

多对多维度的优势

这种通过中间表关联的优势在于，你可以将多个维度成员和一个事实表记录关联到一起。当你想要汇总这些值的时候，优势就体现出来了。例如，当你使用[Sales Reason]维度去查询[Internet Sales]度量组的时候，可以得到以下结果：

select {[Measures].[Internet Sales Amount]} on columns,
{[Sales Reason].[Sales Reason].members} on rows
from [Adventure Works]

上述结果集里头，由于[Price]和[Others]这两个销售成功因素都是SO75088这个订单成功的因素，因此其销售额都包含了SO75088订单的金额。而更不错的是，你现在有了一个[All Sales Reasons]的成员，用来表示总的销售金额$29,358,677.22。

你如果直接查询[Measures].[Internet Sales Amount]指标，得到的结果也是一样的。

select {[Measures].[Internet Sales Amount]} on columns
from [Adventure Works]

数据精准性问题

使用多对多维度的一个潜在问题就是数据重复计算，特别是当用户没能很好理解多对多背后原理的话，更有可能出现这种情况。例如，我们执行以下MDX查询：

select {[Measures].[Internet Sales Amount]} on columns,
{[Sales Reason].[Sales Reason].children} on rows
from [Adventure Works]

得到以下结果：

得到这样的数据之后，用户可能会直接使用上述的数据相加来计算总的销售金额，从而得到以下结果：

注意，这里的总和$30,856,531.52和前面提到的[All Sales Reasons]成员的汇总值$29,358,677.22很不一样，相差了$1,497,854.30，如果你从事金融方面工作的话，这个差别应该是足够明显了。

问题的复杂之处在于，当你应用多对多维度的时候，你无从知道那些成员会被重复计算，因为任何一单销售都有可能和任何一个销售成功因素关联。例如用户有可能直接把[Other]和[Price]成员的销售额相加，得到因为这两个原因而成交的订单销售额情况$11,224,325.90。但是这样的结果是错误的，因为有一些销售订单同时包含了这两个销售成功因素。因此总和应该是小于$11,224,325.90的。

有别的解决办法吗？

“是否应该使用多对多维度”，你主要需要考虑两个方面的问题：性能和数据精准性。

性能

在Analysis Services 性能指南中提到，有时候应用多对多是出于性能的考虑，其中一个情形就是对Distinct Count类型的度量进行泛化。使用多对多维度可以让你通过Analysis Services的sum、count、max、min等运算符实现和Distinct Count一样的逻辑。为了计算Distinct Count或者Sum，Analysis Services存储引擎需要直接对最小粒度的数据做转换。这是因为，当一个查询涉及到多对多维度的时候，聚合结果是在查询期间通过目标度量组和中间度量组在属性级别上完成的。查询的过程相对比较消耗CPU和内存。

多对多的性能考虑主要包括以下几个方面：

• 因为查询涉及到多对多维度，会在目标度量分组和中间度量分组之间生成一个Join连接，因此降低中间度量组的表大小（通常小于1百万行数据）可以提高查询性能。细节参考：Analysis Services Many-to-Many Dimensions: Query Performance Optimization Techniques 白皮书。
• 目标度量组和中间度量组之间的连接是哈希连接，因此完成此项操作非常消耗内存。
• 和Distinct Count不同，多对多关系不能被预聚合（虽然通常对于Distinct Count来说，要设计通用的预聚合也不是一件容易的事）。因此，涉及到多对多维度的查询无法使用预聚合或者聚合缓存，除非直接命中才有效。不过在几种特殊情形下多对多关系还是有可能被预聚合的，详细信息参考：Analysis Services Many-to-Many Dimensions: Query Performance Optimization 技术白皮书。
• 因为多对多无法被预聚合，很多MDX计算例如VisualTotals，subselects和Create Subcube都会遇到问题。

数据精准性

正如你在“数据精准性问题”这一节中看到的，在应用多对多关系的场景中你可能会得不到期望的值（例如重复计算）。所以，即便这是一项非常强大的功能，如果用户没有认识到背后的多对多关系，他可能会得到错误的结果。

分析

你可以参考Marco Russo写的Many-to-many维度建模，里头提及了很多基于多对多维度关系之上建模的解决方案。对于数据仓库以及商业智能问题来说，“是否应该使用多对多维度”这个问题，不存在一个绝对的答案。重要的是，你在实际应用之前，首先需要理解多对多背后的含义。

在 [Sales Reason]这个示例中，有多种情况可以判断是否应该使用多对多维度：

你想要多对多关系，并且经常会使用Sales Reason维度去剖析数据。

如果你经常需要使用Sales Reason维度去剖析数据，那么你其实并不需要一个中间度量组。在这个场景中，你可以将[FactInternetSales]和[FactInternetSalesReason]表合成一张新的事实表，然后基于这张表上建立新的数据立方体。因为你经常需要使用sales reason维度去剖析数据，当你使用[Price]成员去剖析数据的时候，以下高亮的行会被选中：

如果你选择了[Other]成员来剖析的话，以下高亮的行会被选中：

如果你想要获取汇总值，例如总销售额，你可以基于FactInternetSales表建立新的数据立方体，这样就不需要通过中间度量分组。

你实际上并不需要多对多关系

在我们这个场景中，实际上根本并不需要多对多关系。想想看，事实上，我们只需要规定，每笔销售订单只允许有一个销售成功因素即可。

或

另外一种处理办法是将此订单的销售额分摊到不同的销售成功因素上。

结论

注意，以上说的这些并不是要告诉你，不要去使用多对多维度。这是一项非常棒的功能，它让用户能够实现他们想要的效果——将多个维度成员关联到同一个事实表记录上，同时在计算总和的时候又不会出现重复计算的问题。但需要注意，使用多对多维度对于汇总值的影响（例如，将所有单元格的值汇总起来并不总是等于实际的总值）还有它对于其他维度的影响。同时，还需要考虑性能方面的问题，虽然在Analysis Services Many-to-Many Dimensions: Query Performance Optimization 技术白皮书中已经对如何优化多对多的查询性能做出了指导。在处理多对多问题上还有其他的解决方案，所以请确保你已经考虑过这些解决方案，并且已经理解了多对多的潜在问题。

——Kevin Yang

你可能对下面的文章感兴趣

• 64位系统下IIS7 ISAPI处理器加载失败
• Analysis Service 2005 OLAP Best Practice White Paper
• Analysis Services 2005 OLAP设计最佳实践
• BIDS对于维度属性键为可变长列时存在的Bug
• BIDS部署时出现元数据管理器发生错误
• Google Analytics中的Page维度
• OLAP中的AverageOfChildren聚合方式
• SSAS处理时“找不到属性键”的解决办法
• 全半角空格导致的Analysis Services处理错误
• 权限不足导致的Analysis性能计数器在Vista/win2008下失效的问题

而Sql Server相关的性能计数器却是正常的，按理说，Analysis和Sql Server是一块安装的，要出问题应该是一起出问题才是。我有两台安装了windows server 2008（X64）的服务器均是如此。我自用的win7机器也是一样的问题。

在经过一个月的搜索、发帖询问后，我总算在MSDN论坛上等到答案。Darren（这家伙相当热心，我好多莫名其妙的问题都是他解决或给的启发）说可能是权限问题，建议我把Olap服务从network service帐户改成使用admin帐号启动，我测试了一下，这下果然指标全都正常了。

回想起安装Sql Server的时候，好像默认是会使用Network Service启动的。真搞不懂。既然是因为权限不足的原因，起码也给个提示呀。更让我不解的是，Sql Server的服务也是使用Network Service帐户启动的，但是性能计数器却工作正常。

为了找到真正出现权限问题的地方，我用尽了各种方法，包括给那些我认为相关的文件加上network service权限，重建计数器，注册表对比和跟踪，跟踪msmdctr100.dll（性能计数器相关的dll）的活动，检查Analysis相关日志，等等。最终除了发现一些乱七八糟不想关的信息之外，还是没能找到问题所在，只好放弃。

希望此文对那些和我一样遭遇类似问题的童鞋有帮助。

——Kevin Yang

你可能对下面的文章感兴趣

• 64位系统下IIS7 ISAPI处理器加载失败
• Analysis Services 2005 OLAP设计最佳实践
• Analysis Services：你应该使用多对多维度吗？
• BIDS部署时出现元数据管理器发生错误
• OLAP中的AverageOfChildren聚合方式
• SSAS处理时“找不到属性键”的解决办法
• Win7/Vista高级用户必备的右键菜单Take back my Ownership!
• 全半角空格导致的Analysis Services处理错误
• 解决新创建的windows用户无法访问TFS的问题
• 解决维度成员中的非法Xml字符导致的查询错误

某维度表的字符串列同时出现两条记录，A记录以半角空格（英文空格）结束，B记录以全角空格（中文空格）结束，除此之外其他部分均相同。Analysis Service处理的时候抛出“Key not found”的异常，导致处理失败。

为了实验，我们创建两张非常简单的表：

-- 员工交易事实表
Create Table [FactTransaction](
    [TransactionKey] [int] not null,
    [EmployeeKey] [int] not null
)
-- 员工维度表
Create Table [DimEmployee](
    [EmployeeKey] [int]not null,
    [EmployeeName] [nvarchar](32) not null
)

接着我们开始往维度表中添加几条记录。

insert into DimEmployee(EmployeeKey,EmployeeName)values(1,'员工 ')    -- 半角空格
insert into DimEmployee(EmployeeKey,EmployeeName)values(2,'员工　')    -- 全角空格

然后我们在BIDS中新建一个Analysis Service的Olap工程，将DimEmployee表作为维度表，并新建指标TotalTransactions ::= Count(TransactionKey)表示每个员工的交易数量：

所有设置保持默认，OK，现在开始处理Employee维度。这个时候Analysis Service会提示你：

Processing Dimension Attribute 'EmployeeKey' failed. 1 rows have been read.

OLAP 存储引擎中存在错误: 处理时找不到以下属性键: 表:“dbo_DimEmployee”，列:“EmployeeName”，值:“员工 ”。该属性为“EmployeeName”。

这个错误翻译成英文就是Key not found.

问题分析

发生了什么事

在我们上面设计的OLAP方案中，一个EmployeeKey有且只能有一个EmployeeName，EmployeeKey属性的处理依赖于EmployeeName属性。这个依赖关系在维度设计视图中的Attribute Relationship属性关系面板中指定。

Analysis Service会在处理完EmployeeName属性之后再处理EmployeeKey属性。在处理每一个EmployeeKey属性成员的时候，都会去找对应的EmployeeName属性成员。

上面的处理错误实际上就是说，在处理EmployeeKey的某个成员的时候，它对应的EmployeeName属性成员应该是“员工 ”（全角空格）的——从表记录中可以看到这个对应关系——但是在属性存储文件（Analysis Service自己的存储结构）中却找不到该属性成员。

这里没有告诉我们到底是哪个EmployeeKey属性成员处理的时候出了问题，但是由于我们的数据仓库非常简单，我们可以直接看出来，EmployeeName=“员工 ”（全角空格）的EmployeeKey为2。

那为什么全角空格的EmployeeName属性成员没有导入到Analysis Service的属性存储文件中呢？我们来展开看一下处理EmployeeName时Analysis Service向Sql Server发起的查询。

SELECT
  DISTINCT
 [dbo_DimEmployee].[EmployeeName] AS [dbo_DimEmployeeEmployeeName0_0]
  FROM [dbo].[DimEmployee] AS [dbo_DimEmployee]

将这行代码放到Sql Server中去执行一下，我们发现sql Server只给我们返回了半角空格的记录，全角空格的记录被过滤掉了。这也就解释了，为什么全角空格的属性成员没能进入Analysis service中。进而导致依赖这个成员的属性处理失败。

Sql Server Collation

这里需要提一下Sql Server的排序规则（Collation）。排序规则会影响数据之间的比较以及顺序。具体细节参见MSDN：SQL Server Collation Fundamentals 。这里我只提一个和这个问题相关的，并且容易被人遗忘的设置，那就是Width-Sensitive（宽度敏感）设置。我们知道，有些字符既有单字节形式（半角字符），又有双字节形式（全角字符），例如1234和１２３４。如果设置为宽度不敏感，那么Sql Server就会将这些字符的单双字节形式一视同仁。这样你在select distinct的时候，单双字节字符形式的字符串就只能一个。这也就是为什么上面我们select distinct的时候只出来半角空格的缘故。

Sql Server和Analysis Service排序规则相同为什么还会出错？

Analysis Service自己也有一个排序规则的设置。我们检查了一下这两者的设置，发现是一样的。那么Analysis Service在查找“员工 ”（全角空格）属性成员的时候，即使找不到这个成员，但是应该至少可以匹配到“员工 ”（半角空格）的成员才是呀。关键是，半角空格的成员也根本不存在。默认情况下，所有字符串类型的维度属性在处理时都会被right trim，也就是结尾的空格均会被去除。

也就是说，最终进入Analysis Service的属性成员是“员工”，不带任何空格，而这个成员和全角空格（全角空格无法被right trimming掉）的显然无法匹配上。

发散一下

如果Analysis设置了对每个属性成员左右都trim的话，那么一旦数据仓库出现“ 员工”（左边带全角空格）和“ 员工”（左边带半角空格）的数据的时候，处理失败。

如果数据仓库中同时出现“员工”，“员工 ”（全角空格），那么也会造成出错，这是因为select distinct会将右侧空格去除之后再比较数据是否相等。

如果将维度属性的Trimming设置为None的话，那么当数据仓库中出现“员工”，“员工   ”（若干个半角空格结尾）这样数据的时候，也会造成处理失败，这也是为什么Analysis Service默认设置为right trimming的其中一个原因（和Sql Server的行为保持一致）。

如果数据中同时出现“员工 ”（半角空格），“员工 ”（全角空格），“员工 ”（先全角空格，再tab空格）这样的数据组合，处理正常。

总结

出现这样的情况，不好通过改变Sql Server或者Analysis Service的排序规则来修正这个问题。只能在ETL的阶段对此类数据进行预处理，将末尾的全角空格给剔除掉。如果业务系统对全半角的区别不感兴趣，也可以直接使用正则表达式将所有全角字符替换成相应的半角字符。

——Kevin Yang

你可能对下面的文章感兴趣

• 64位系统下IIS7 ISAPI处理器加载失败
• Analysis Services 2005 OLAP设计最佳实践
• Analysis Services：你应该使用多对多维度吗？
• BIDS部署时出现元数据管理器发生错误
• OLAP中的AverageOfChildren聚合方式
• Sql Server中修改自增长列经常需要用到的配置
• Sql Server重命名所有外键约束
• SSAS处理时“找不到属性键”的解决办法
• SSIS调用存储过程失败
• Visual Studio编辑器一次缩进/反缩进4个空格

问题描述

最近在项目中遇到这么个情况，在展开维度成员的时候，服务端抛出了“The server sent an unrecognizable response”的异常，看了下异常细节，给出的信息是“'', hexadecimal value 0x01, is an invalid character. Line 1, position 6771. (System.Xml) ”。

问题解决

出现这样问题的原因在于，微软的Analysis Service使用XMLA（XML for Analysis）语言和其他客户端进行交互，包括执行Mdx、DMX、Sql等。如果服务端返回的成员（关键列、名字、标题、成员值等）含有一些非打印字符的话，那么就无法直接在Xml中表示，这样就会导致客户端无法解析返回的Xml响应，而出现上述的错误。

Analysis Service在Process的时候，出于性能考虑默认情况下是不会对数据进行这种Xml非法字符的检测。不过Analysis Service也提供了一个设置开关，允许我们在处理阶段检测这些非法字符，并做一定的规范化处理。在BIDS中，我们打开维度属性的属性面板，有一个InvalidXmlCharacters的设置，如下图所示：

默认情况下其值为Preserve，也就是保留这些非法字符。它还有其他两个选项。Remove表示移除这些非法字符，只保留合法的Xml字符。Replace表示使用问号?替换非法字符，一个非法字符对应一个问号。在实际应用中，InvalidXmlCharacters需要根据项目的实际情况进行设置。如果对数据的这种清理可以放到ETL阶段，那么最好放到ETL阶段，因为这样可以加快Analysis Service处理的速度。否则就只能在Process的时候做检测了。对于Remove和Replace，我比较倾向于选择Remove。因为既然已经是非打印字符了，用问号代替固然能够和其他数据区分开来，但是对于最终用户来说，大部分情况下只会增加他们的迷惑而已。

剔除非法Xml字符

在Xml 1.0规范（第五版，06/11/2008）的2.2一节中提到了Xml合法字符的范围：

/* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */

Char ::=   #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]

规范中建议，所有Xml处理器都应该正确处理上述范围的这些字符。

我们可以在处理字符串的时候使用正则表达式剔除掉非法的Xml字符，以保证最终进入Analysis Service的字符都是Xml合法字符。

[^\x09\x0A\x0D\x20-\uD7FF\uE000-\uFFFD\u10000-\u10FFFF]

对应的C#代码如下，出于性能考虑，可以将函数内部的正则表达式存储为成员变量，并设置为预编译模式。

public static String StripInvalidXmlChars(String input)
{
  Regex re = new Regex(@"[^\x09\x0A\x0D\x20-\uD7FF\uE000-\uFFFD\u10000-\u10FFFF]");
  return re.Replace(input, "");
}

参考文档：

Invalid XML Characters: when valid UTF8 does not mean valid XML

unprintable characters in member names cause error

Xml 1.0规范

——Kevin Yang

你可能对下面的文章感兴趣

• 64位系统下IIS7 ISAPI处理器加载失败
• Analysis Services 2005 OLAP设计最佳实践
• Analysis Services：你应该使用多对多维度吗？
• BIDS对于维度属性键为可变长列时存在的Bug
• BIDS部署时出现元数据管理器发生错误
• Google Analytics中的Page维度
• Javascript中获取出错代码所在文件及行数
• OLAP中的AverageOfChildren聚合方式
• SSAS处理时“找不到属性键”的解决办法
• Visual Studio小贴士——加了Try-Catch也能自动定位到异常代码

但是测试结果却发现，得到的数据根本就不是我们期望的。后来查资料找到了关于这个聚合方式的说明：

AverageOfChildren——对某个成员的聚合值等于其所有子成员的平均值。

这是什么意思呢？假设我定义了一个“总销售额”和“平均销售额”这两个指标。当我看中国的数据的时候，假设中国的总销售额是34000万的话，因为中国下面有34个省级行政区（34个Member），因此平均销售额就是1000万。这是按照字面上的理解。但实际上，这样理解是错误的。MSDN上给出的解释并没有明确指明，AverageOfChildren这个聚合方式只是针对时间维度起作用。

在Analysis Service中内置了很多常见的维度类型，如时间维度，地理纬度，帐户维度等。你可以将你创建的维度的“类型”属性标记为内置的维度类型。这样的好处是，Analysis Service对这些标记为特殊类型的维度有额外的支持。例如如果你的Cube中包含一个标记为“时间维度”类型的维度时，那么你就可以在Mdx中使用和时间相关的函数，如Ytd等。类似的，AverageOfChildren这个聚合类型也是需要时间维度的支持，你首先需要在工程中显式指定至少一个时间维度。这个聚合方式的意义就是对所有的时间——以天为单位——求平均值。例如当前时间维度选择的成员是[2003年]，而03年有销售额数据的共有365天，那么

AverageOfChildren(销售额） =  总销售额 / 365

如果范围再进一步缩小，选择[2003年3月份]，由于3月份每天都有销售额，因此AverageOfChildren就等于总销售额除以31。你可以按具体日期去查看，你会发现，每天的总销售额和平均销售额是一样的。这是因为具体日期的粒度已经是最小的了。

由于这个AverageOfChildren聚合方式只是针对时间维度的，不能满足大量的应用场景，因此通常我们都需要自己定义这样一个求平均值的计算指标。公式很简单：

平均值=总值 / 维度成员个数

例如我们想看月利润平均值，那么首先我们定义一个“总利润”的指标，那么

月利润平均值 = 总利润 / Count([Time].[CalendarMonth].children)

(update: 在Analysis Services 2008下，似乎这个聚合方式已经变成了对小时求平均，而不是以天作为最小单位。反正不管怎么样，这个聚合方式实在没什么太大作用)

——Kevin Yang

你可能对下面的文章感兴趣

• 64位系统下IIS7 ISAPI处理器加载失败
• Analysis Service 2005 OLAP Best Practice White Paper
• Analysis Services 2005 OLAP设计最佳实践
• Analysis Services：你应该使用多对多维度吗？
• BIDS部署时出现元数据管理器发生错误
• SSAS处理时“找不到属性键”的解决办法
• 全半角空格导致的Analysis Services处理错误
• 权限不足导致的Analysis性能计数器在Vista/win2008下失效的问题
• 解决维度成员中的非法Xml字符导致的查询错误

Data Source Design Best Practices / 数据源设计最佳实践

1. Do use only supported OLEDB providers in a Data Source
在数据源中仅仅使用被支持的OLEDB提供者
2. Do not use the .Net SqlClient Data Provider to connect to a SQL Server data source
忌用.NET SqlClient 数据提供者连接SQL Server数据源

Dimension Design Best Practices / 维度设计最佳实践

1. Do create attribute relationships wherever they exist in the data
尽量创建属性关联(Attribute Relationships)如果它们的数据存在关联
2. Avoid creating attributes that will not be used
避免创建不被使用的属性(Attribute)
3. Do not create hierarchies where an attribute of a lower level contains fewer members than an attribute of the level above
不要创建这样的层次-子级别某属性的成员数少于父亲级别该属性的成员个数
4. Do not include more than one non-aggregatable attribute per dimension
在同一个维度中切勿包含一个以上的非聚合属性
5. Do use key columns that completely and correctly define the uniqueness of the members in an attribute
正确使用关键列定义成员在属性上的唯一性
6. Do perform Process Index after doing a Process Update if the dimension contains flexible AttributeRelationships or a parent-child hierarchy
如果维度上含有Flexible的属性关系或者含有父子层次，在做处理更新时候需要重做Process Index
7. Do use numeric keys for attributes that contain many members (>1 million)
给属性列使用数字类型，尤其含有百万记录成员的
8. Do not create redundant attribute relationships
不要创建多余的属性关联，比如A->B, B->C, 则A->C不必手工创建
9. Do include the key columns of snowflake tables joined to nullable foreign keys as attributes that have NullProcessing set to UnknownMember
设置NullProcessing为UnknownMember，如果维度表外键关联可能为NULL的列
10. Do set the RelationshipType property appropriately on AttributeRelationships based on whether the relationships between individual members change over time
根据成员属性的不同特点设置合适的RelationshipType(Flexible或者Rigid)
11. Avoid using ErrorConfigurations with KeyDuplicate set to IgnoreError on dimensions
为了检测数据唯一完整性，有的时候需要改变KeyDuplicate的默认值
12. Do define explicit default members for non-aggregatable Attributes
对于非聚合属性定义默认成员
13. Avoid creating user-defined hierarchies that do not have attribute relationships relating each level to the level above
不要创建某个等级和它的父级没有关联关系的自定义层次
14. Avoid creating diamond-shaped attribute relationships
避免创建钻型属性关联
(关于钻行关联，可以参考这篇Blog以及AS2008可能会去除这个限制：http://sqlblog.com/blogs/mosha /archive/2007/06/07/katmai-june-ctp-attribute-relationships-tab.aspx )
15. Consider setting AttributeHierarchyEnabled to False on attributes that have cardinality that closely matches the key attribute
对于那些如同key attribute只是起标识作用的属性，可以设置AttributeHierarchyEnabled属性为false来禁用属性层次
16. Consider setting AttributeHierarchyVisible to False on the key attribute of parent-child dimensions
设置父子维度的key attribute的AttributeHierarchyVisible为False
17. Avoid setting UnknownMember=Hidden
避免设置UnknownMember=Hidden
18. Do use MOLAP storage mode for dimensions with outline calculations (custom rollups, semi-additive measures, and unary operators)
对含有outline计算的维度记得使用MOLAP存储模式
19. Do use a 64 bit server if you have dimensions with more than 10 million members
如果维度下成员含有千万个数量级，需要考虑使用64位的服务器了
20. Do set the OrderBy property for time attributes and other attributes whose natural ordering is not alphabetical
对于那些不是数字类型的属性(Attribute)，比如时间，记得设置它的OrderBy属性(Property)
21. Do expose a DateTime MemberValue for date attributes
对于日期属性，尽量暴露它的MemberValue属性（有些客户端会根据这个属性来对待日期时间）
22. Do set AttributeHierarchyEnabled to False, specify a ValueColumn and specify the MimeType of the ValueColumn on attributes that contain images
对于图片属性，应该要设置AttributeHierarchyEnabled为False,并且设置它的MimeType为图片类型
23. Avoid setting IsAggregatable to False on any attribute other than the parent attribute in a parent-child dimension
除了父子维度的parent属性外，不要设置属性的IsAggregatable为false
24. Do set dimension and attribute Type properties correctly for Time, Account, and Geography dimensions
对于时间，帐户，地理维度记得设置他们的维度和属性类型
25. Consider creating user-defined hierarchies whenever you have a chain of related attributes in a dimension
如果维度中属性有一系列的关联关系，记得创建自定义层次
26. Do include all desired attributes of a logical business entity in a single dimension instead of splitting them up over several dimensions
尽量在一个维度中把描述一个业务实体所有必要关联属性，而不是分到多个维度中
27. Do not combine unrelated business entities into a single dimension
也不要把没有关联的多个业务实体放到同一个维度中
28. Do set NullProcessing to UnknownMember on each attribute that has nulls and is used to join to a referenced dimension
对于有NULL值的属性并用于关联另外的维度，需要设置它的NullProcessing为UnknowMember
29. Do set NullKeyConvertToUnknown to IgnoreError on the ErrorConfiguration on any measure groups that contain a dimension referenced through a nullable column
对于任何度量组含有的维度如果引用含有NULL值，记得设置NullKeyConvertToUnknown为IgnoreError，并且UnknownMember设为Visible
30. Consider setting AttributeHierarchyVisible to False for attributes included in user-defined hierarchies
考虑设置AttributeHierarchyVisible为false如果该属性在自定义的层次中被使用
31. Do not use proactive caching settings that put dimensions into ROLAP mode
考虑性能不要使用Proactive caching设置维度为ROLAP模式（可设置OnlineMode为OnCacheComplete）
32. Avoid making an attribute non-aggregatable unless it is at the end of the longest chain of attribute relationships in the dimension
避免设置维度的属性（Attribute）为non-aggregatable除非它在一个相当长的属性关联关系链的末端
33. Consider creating at least one user-defined hierarchy in each dimension that does not contain a parent-child hierarchy
为非父子结构的维度创建至少一个自定义层次
34. Do set the InstanceSelection property on attributes to help clients determine the best way to display attributes for member selection
设置Attribute的InstanceSelection属性，这样客户端工具可以在用户选择成员时候显示正常的属性值

Cube Design Best Practices / 立方体设计最佳实践

1. Avoid including unrelated measure groups in the same cube
避免在一个立方体中包含不关联的度量组
2. Avoid having too many parent-child dimensions in a cube, especially when the dimension contains custom rollups or unary operators
避免在一个立方体中含有大量父子维度，尤其是维度含有自定义的Rollup或者一元操作符(?)
3. Do set AttributeHierarchyEnabled to False on any cube attributes that are below the level of granularity of all measure groups in the cube
当Attribute比立方体中所有度量组的粒度层次还要低的时候，可以设置它的AttributeHierarchyEnabled为false
4. Avoid having very big intermediate measure groups or dimensions of many-to-many dimensions
在多对多的维度中不要含有过大的度量组或者维度
5. Consider using a processing query when using the scheduled polling option of proactive caching
当使用定时Proactive caching时候考虑使用processing query
6. Avoid creating multiple measure groups that have the same dimensionality and granularity
不要创建相同广度和力度的度量组
7. Do put each distinct count measure into a separate measure group
在每个度量组中创建各自的计算度量
8. Do set any explicit default members of role-playing dimensions directly on the cube dimensions
在立方体维度上直接设置role-playing维度的默认成员
9. Do reuse dimensions multiple times in a cube instead of creating duplicates of a dimension
在立方体中重复利用已有的维度而不复制一个相同维度
10. Avoid having cubes with a single dimension
切勿创建只有一个维度的立方体
11. Do use the smallest numeric data type possible for measures
尽可能为度量使用最小数据类型
12. Do ensure that the Collation property of OLAP objects is consistent with the collation of the relational source data when dealing with multilingual data
使用多语言数据时候，保持OLAP对象中的Collation和对应数据源中设置是一致的
13. Do materialize referenced dimensions
物化(?)引用维度
14. Avoid using linked dimensions, especially if your cube has outline calculations (custom rollups, semi-additive measures, or unary operators) or scripts
避免使用外接维度，尤其是立方体含有计算成员或者脚本

Partition Design Best Practices / 分区设计最佳实践

1. Avoid having partitions with more than 20 million rows
分区数据控制在2000万条以内
2. Avoid having many small partitions in a measure group
同一度量组内不要含有太多小分区
3. Do set the Slice property on partitions that are ROLAP or partitions that use proactive caching
如果使用ROLAP模式或者Proactive caching，设置Slice属性进行切片
4. Consider partitioning a distinct count measure group along the dimension used most often to query the distinct count measure
如果分区的度量组含有计算度量，记得同时包含使用次数最多的维度

Aggregation Design Best Practices / 聚集(聚合)设计最佳实践

1. Consider having aggregations for each partition of significant size
对每个分区进行合适大小的聚集
2. Do include the granularity attribute of the time dimension in aggregations for measure groups with semi-additive measures
对含有semi-additive度量的度量组，记得聚集时包含时间维度上的相关粒度的属性
3. Do not build too many aggregations
不要建立太多聚集（< 500）
4. Consider sharing aggregation designs between partitions of similar size and usage
对相似大小和使用特性的分区上使用公用相同的聚集（一般每个度量组有三种聚集即可）
5. Consider creating separate aggregation designs for partitions with significantly different size or usage
对不同大小不同使用的分区，创建单独的不同策略的聚集
6. Do use a lower performance gain with regular aggregation design and a higher performance gain with usage-based optimization
一般聚集设计的时候，采用获取较低性能的方式，而对基于使用率优化时选择高性能获取方式
7. Consider setting AggregationUsage to Unrestricted on high-use attributes that are not the key of a dimension and not in a hierarchy
对于不是key或者不在层次中的属性，设置它的AggregationUsage为Unrestricted以便系统在聚集时会优先考虑它
8. Avoid Setting AggregationUsage to Full on Large Attributes
在大属性上避免设置AggregationUsage属性为Full
9. Do set member and row counts accurately for the partition when designing aggregations
设计聚集时候精确提供成员和记录行总数
10. Consider including the granularity attribute of the intermediate dimensions of many-to-many dimensions in aggregations
在含有多对对的维度设计聚集时候，考虑包含中间维度上的粒度属性
11. Do include in aggregations the granularity attribute of dimensions that contain unary operators or custom rollups
如果在维度上包含一元操作符或者自定义Rollup，在聚集时候要考虑它的粒度属性
12. Avoid creating aggregations that are larger than one-third the size of the fact data
聚集大小不要超过事实表大小的三分之一
13. Do remove aggregation designs that are not applied to any partitions
删除不适合任何分区的聚集
14. Do not create aggregations that contain multiple attributes from the same attribute relationship chain
不要给来自同一属性关联组内的多个属性重复创建聚集
15. Consider including in aggregations only those attributes with rigid relationships to their dimension keys
只包含那些刚性的维度建立聚集

英文原文：

Data Source Design Best Practices

OLAP databases in Analysis Services 2005 have several special requirements that are important to ensure trouble-free access to source data.

Do use only supported OLEDB providers in a Data Source

Analysis Services was designed and tested to work with a specific set of OLE DB providers. Although other OLE DB providers are available, and the Data Source Wizard lets you choose any compatible provider, the capabilities and behavior of different providers can differ substantially. This is true even for different providers that connect to the same database. Therefore, you should use only the supported providers.  For a list of officially supported providers, see http://msdn2.microsoft.com/en-us/library/ms175608.aspx.

Do not use the .Net SqlClient Data Provider to connect to a SQL Server data source

Because the Analysis Services server runs in native code, you can get better performance by using a native provider. Therefore, do not use the .Net SqlClient Data Provider; instead, use the Microsoft OLE DB Provider for SQL Server or the SQL Native Client provider.

Top Of Page

Dimension Design Best Practices

Good dimension design is the most important aspect of a well designed Analysis Services OLAP database. Although the wizards in Analysis Services do much of the work to get you started, it is important to review the design that is created by the wizard and ensure that the attributes, relationships, and hierarchies correctly reflect the data and match the needs of your end-users.

Do create attribute relationships wherever they exist in the data

Attribute relationships are an important part of dimension design.  They help the server optimize storage of data, define referential integrity rules within the dimension, control the presence of member properties, and determine how MDX restrictions on one hierarchy affect the values in another hierarchy.  For these reasons, it is important to spend some time defining attribute relationships that accurately reflect relationships in the data.

Avoid creating attributes that will not be used

Attributes add to the complexity and storage requirements of a dimension, and the number of attributes in a dimension can significantly affect performance.  This is especially of attributes which have AttributeHierachyEnabled set to True. Although SQL Server 2005 Analysis Services can support many attributes in a dimension, having more attributes than are actually used decreases performance unnecessarily and can make the end-user experience more difficult.

It is usually not necessary to create an attribute for every column in a table. Even though the wizards do this by default in Analysis Services 2005, a better design approach is to start with the attributes you know you'll need, and later add more attributes.  Adding attributes as you discover they are needed is generally better a better practice than adding everything and then removing attributes.

Do not create hierarchies where an attribute of a lower level contains fewer members than an attribute of the level above

A hierarchy such as this is frequently an indication that your levels are in the incorrect order: for example, [City] above [State]. It might also indicate that the key columns of the lower level are missing a column: for example, [Year] above [Quarter Number] instead of [Year] above [Quarter with Year].  Either of these situations will lead to confusion for end-users trying to use and understand the cube.

Do not include more than one non-aggregatable attribute per dimension

Because there is no All member, each non-aggregatable attribute will always have some non-all member selected, even if not specified in a query.  Therefore, if you include multiple non-aggregatable attributes in a dimension, the selected attributes will conflict and produce unexpected numbers. 

For example, in a time dimension it might not make sense to sum the members of [Calendar Year] or [Fiscal Year], but if both are made non-aggregatable, whenever a user asks for data for a specific [Calendar Year] it will be filtered by the default [Fiscal Year] unless they also specify the [Fiscal Year].  Worse, because [Calendar Year] and [Fiscal Year] do not align but overlap, it is difficult to obtain the full data for either a [Calendar Year] or a [Fiscal Year] because the one is filtered by the other.

Do use key columns that completely and correctly define the uniqueness of the members in an attribute

Usually a single key column is sufficient, but sometimes multiple key columns are necessary to uniquely identify members of an attribute.  For example, it is common in time dimensions to have a [Month] attribute include both [Year] and [Month Name] as key columns.  This is known as a composite key and identifies January of 1997 as being a different member than January of 1998. When you use [Month] in a time hierarchy that also contains [Year], this distinction between January of 1997 and January of 1998 is important. 

It may also make sense to have a separate [Month of Year] attribute that has only [Month Name] as the key.  This [Month of Year] attribute contains a single January member that spans all years, which can be useful for comparing seasonal data. However, this attribute should not be used in a hierarchy together with [Year] because there is no relationship between [Month of Year] and [Year]. 

Similar distinctions between [Quarter] and [Quarter of Year], [Semester] and [Semester of Year], and so on should also be made by setting appropriate key columns.

Do perform Process Index after doing a Process Update if the dimension contains flexible AttributeRelationships or a parent-child hierarchy

An aggregation is considered flexible if any attribute included in the aggregation is related, either directly or indirectly, to the key of its dimension through an AttributeRelationship with RelationshipType set to Flexible.  Aggregations that include parent-child hierarchies are also considered flexible.

When a dimension is processed by using the Process Update option, any flexible aggregations that the dimension participates in might be dropped, depending on the contents of the new dimension data.  These aggregations are not rebuilt by default, so Process Index must then be explicitly performed to rebuild them.

Do use numeric keys for attributes that contain many members (>1 million)

Using a numeric key column instead of a string key column or a composite key will improve the performance of attributes that contain many members.  This best practice is based on the same concept as using surrogate keys in relational tables for more efficient indexing.  You can specify the numeric surrogate column as the key column and still use a string column as the name column so that the attribute members appear the same to end-users. As a guideline, if the attribute has more than one million members, you should consider using a numeric key.

Do not create redundant attribute relationships

Do not create attribute relationships that are transitively implied by other attribute relationships.  The alternative paths created by these redundant attribute relationships can cause problems for the server and are of no benefit to the dimension.  For example, if the relationships A->B, B->C, and A->C have been created, A->C is redundant and should be removed.

Do include the key columns of snowflake tables joined to nullable foreign keys as attributes that have NullProcessing set to UnknownMember

If tables that are used in a dimension are joined on a foreign key column that might contain nulls, it is important that you include in your design an attribute whose key column is the corresponding key in the lookup table. Without such an attribute, the OLAP server would have to issue a query to join the two tables during dimension processing.  This makes processing slower; moreover, the default join that is created by the OLAP server would exclude any rows that contain nulls in the foreign key column.  It is important to set the NullProcessing option on the key column of this attribute to UnknownMember.  The reason is that, by default, nulls are converted to zeros or blanks when the engine processes attributes.  This can be dangerous when you are processing a nullable foreign key. Conversion of a null to zero at best produces an error; in the worst case, the zero may be a legitimate value in the lookup table, thereby producing incorrect results.

To handle nullable foreign keys correctly, you must also set UnknownMember to Visible on the dimension. The Cube Wizard and Dimension Wizard currently set this property automatically; however, the Dimension Wizard lets you manually de-select the key attribute of snowflake tables. You must not deselect the key column if the corresponding foreign key is nullable.

If you do not want to browse the attribute that contains the lookup table key column, you can set AttributeHierarchyVisible to False.  However, AttributeHierarchyEnabled must be set to True because it is necessary that all other attributes in the lookup table be directly or indirectly related to the lookup key attribute in order to avoid the automatic creation of new joins during dimension processing.

Do set the RelationshipType property appropriately on AttributeRelationships based on whether the relationships between individual members change over time

The relationships between members of some attributes, such as dates in a given month or the gender of a customer, are not expected to change.  Other relationships, such as salespeople in a given region or the marital status of a customer, are more prone to change over time.  You should set RelationshipType to Flexible for those relationships that are expected to change and set RelationshipType to Rigid for relationships that are not expected to change.

When you set RelationshipType appropriately, the server can optimize the processing of changes and re-building of aggregations.

By default, the user interface always sets RelationshipType to Flexible.

Avoid using ErrorConfigurations with KeyDuplicate set to IgnoreError on dimensions

When KeyDuplicate is set to IgnoreError, it can be difficult to detect problems with incorrect key columns, incorrectly defined AttributeRelationships, and data consistency issues.  Instead of using the IgnoreError option, in most cases it is better to correct your design and clean the data.  The IgnoreError option may be useful in prototypes where correctness is less of a concern. Be aware that the default value for KeyDuplicate is IgnoreError. Therefore, it is important to change this value after prototyping is complete to ensure data consistency.

Do define explicit default members for non-aggregatable attributes

By default, the All member is used as the default member for aggregatable attributes. This default works very well for aggregatable attributes, but non-aggregatable attributes have no obvious choice for the server to use as a default member, therefore a member will be selected arbitrarily. This arbitrarily selected member is then selected whenever the attribute is not explicitly included in an MDX query. To avoid this, it is important to explicitly set a default value for each non-aggregatable attribute. 

Default members can be explicitly set either on the DimensionAttribute or in the cube script.

Avoid creating user-defined hierarchies that do not have attribute relationships relating each level to the level above

Having attribute relationships between every level in a hierarchy makes the hierarchy strong and enables significant server optimizations.

Avoid creating diamond-shaped attribute relationships

A Diamond-shaped relationship refers to a chain of attribute relationships that splits and rejoins but contains no redundant relationships.  For example, Day->Month->Year and Day->Quarter->Year have the same start and end points, but do not have any common relationships.  The presence of multiple paths can create some ambiguity on the server.  If preserving the multiple paths is important, it is strongly recommended that you resolve the ambiguity by creating user hierarchies that contain all the paths.

Consider setting AttributeHierarchyEnabled to False on attributes that have cardinality that closely matches the key attribute

When an attribute contains roughly one value for each distinct value of the key attribute, it usually means that the attribute contains only alternative identification information or secondary details.  Such attributes are usually not interesting to pivot or group by.  For example, the Social Security number or telephone number may be interesting properties to view, but there is very little value in being able to pivot and group based on SSN or telephone.  Setting AttributeHierarchyEnabled to False on such attributes will reduce the complexity of the dimension for end-users and improve its performance.

If you want to be able to browse such attributes, you can set AttributeHierarchyEnabled to True; however, you should consider setting AttributeHierarchyOptimized to NotOptimized and setting GroupingBehavior to DiscourageGrouping. By setting these properties, you can improve performance and indicate to the users that the attribute is not very useful for grouping.

Consider setting AttributeHierarchyVisible to False on the key attribute of parent-child dimensions

Because the members of the key attribute are also contained in the parent-child hierarchy in a more organized manner, it is usually unnecessary and confusing to the end-user to expose the flat list of members contained in the key attribute.

Avoid setting UnknownMember=Hidden

When you suppress unknown members, the effect is to hide relational integrity issues; moreover, because hidden members might contain data, results might appear not to add up. Therefore, we recommend that you avoid use of this setting except in prototype applications.

Do use MOLAP storage mode for dimensions with outline calculations (custom rollups, semi-additive measures, and unary operators)

Dimensions that contain custom rollups or unary operators will perform significantly better using MOLAP storage.  The following dimension types will also benefit from using MOLAP storage: an Account dimension in a measure group that contains measures aggregated using ByAccount; the first time dimension in a measure group that contains other semi-additive measures.

Do use a 64 bit server if you have dimensions with more than 10 million members

If a dimension contains more than 10 million members, using an x64 or an IA-64-based server is recommended for better performance.

Do set the OrderBy property for time attributes and other attributes whose natural ordering is not alphabetical

By default, the server orders attribute members alphabetically, by name.  This ordering is especially undesirable for time attributes.  To obtain the desired ordering, use the OrderBy and OrderByAttributes properties and explicitly specify how you want the members ordered.  For time-based attributes, there is frequently a date or numeric key column that can be used to obtain the correct chronological ordering.

Do expose a DateTime MemberValue for date attributes

Some clients, such as Excel, will take advantage of the MemberValue property of date members and use the DateTime value that is exposed. When Excel recognizes the value as DateTime, Excel can treat the value as a date type and apply date functions to the value, as well as provide better formatting and filtering.  If the key column is a single DateTime column and the name column has not been set, this MemberValue is automatically derived from the key column and no action is necessary.  However, in other cases, you can ensure that the MemberValue is DateTime by explicitly specifying the ValueColumn property of the attribute.

Do set AttributeHierarchyEnabled to False, specify a ValueColumn and specify the MimeType of the ValueColumn on attributes that contain images

Because there is no value in browsing the member names of an attribute that contains an image, you should disable browsing by setting AttributeHierarchyEnabled to False.  To help clients recognize and display the member property of the attribute as an image, specify the ValueColumn property of the attribute and then set MimeType to an appropriate image type.

Avoid setting IsAggregatable to False on any attribute other than the parent attribute in a parent-child dimension

Non-aggregatable attributes have non-all default members. These default members affect the result of queries whenever the attributes are not explicitly included.  Because parent-child hierarchies generally represent the most interesting exploration path in dimensions that contain them, it is best to avoid having non-aggregatable attributes other than the parent attribute.

Do set dimension and attribute Type properties correctly for Time, Account, and Geography dimensions

For time dimensions, it is important to set the dimension and attribute types correctly so that time-related MDX functions and the time intelligence of the Business Intelligence Wizard can work correctly.  For Account dimensions, it is similarly important to set appropriate account types when using measures with the aggregate function ByAccount.  Geography types are not used by the server, but provide information for client applications.

A common mistake is to set the Type property on a dimension but not on an attribute, or vice-versa. Another common mistake when configuring time dimensions is to confuse the different time attribute types, such as [Month] and [Month of Year].

Consider creating user-defined hierarchies whenever you have a chain of related attributes in a dimension

Chains of related attributes usually represent an interesting navigation path for end-users, and defining hierarchies for these will also provide performance benefits.

Do include all desired attributes of a logical business entity in a single dimension instead of splitting them up over several dimensions

In Analysis Services 2000, each hierarchy was in reality a separate dimension and attributes such as gender and age would also be separate dimensions.  In Analysis Services 2005, a dimension can and should contain the complete information about a logical business entity, including multiple hierarchies and many attributes.  This does not mean that every piece of information available must be included in the dimension, but rather that any desired information should be included in one dimension instead of split over many dimensions.

There are two exceptions to this guideline:

1. A dimension can only contain one parent-child hierarchy.

2. To model multiple joins to a lookup table within a dimension's schema, you must create a separate dimension based on the lookup table and then use this as a referenced dimension.

Do not combine unrelated business entities into a single dimension

Combining attributes of independent business entities, such as customer and product or warehouse and time, into a single dimension will not only create a confusing model, but also reduce query performance because auto-exist will be applied across attributes within the dimension.

Another way to state this rule is that the values of the key attribute of a dimension should uniquely identify a single business entity and not a combination of entities.  Generally this means having a single column key for the key attribute.

Do set NullProcessing to UnknownMember on each attribute that has nulls and is used to join to a referenced dimension

By default, nulls are converted to zeros or blanks when the engine processes attributes.  This can be dangerous when processing a nullable foreign key, because if a null is converted to zero when zero is a legitimate value in the reference dimension, the join on the values can produce incorrect results. At best, conversion to zero will produce an error.

To prevent these errors, you must also set UnknownMember to Visible on the referenced dimension.

The Cube Wizard in SQL Server 2005 Analysis Services handles both settings automatically, except when dealing with existing dimensions where UnknownMember is not set to Visible.

Do set NullKeyConvertToUnknown to IgnoreError on the ErrorConfiguration on any measure groups that contain a dimension referenced through a nullable column

By default, nulls are converted to zeros or blanks when the engine processes granularity attributes.  This can be dangerous when you are processing a nullable foreign key, because if a null value is converted to zero and zero is a legitimate value in the dimension, the join can produce incorrect results. At best, the conversion will produce errors.

To prevent conversion of nulls, you must also set UnknownMember to Visible on the dimension.

The Cube Wizard in SQL Server 2005 Analysis Services handles these settings automatically, except when dealing with existing dimensions where UnknownMember is not set to Visible.

Consider setting AttributeHierarchyVisible to False for attributes included in user-defined hierarchies

It is usually not necessary to expose an attribute in its own single level hierarchy when that attribute is included in a user-defined hierarchy.  This duplication only complicates the end-user experience without providing additional value. 

One common case in which it is appropriate to present two views of an attribute is in time dimensions.  The ability to browse by [Month] and the ability to browse by [Month-Quarter-Year] are both very valuable. However, these two month attributes are actually separate attributes.  The first contains only the month value such as “January” while the second contains the month and the year such as “January 1998”.

Do not use proactive caching settings that put dimensions into ROLAP mode

For performance reasons, we strongly discourage the use of dimension proactive caching settings that may put the dimension in ROLAP mode.  To ensure that a dimension with proactive caching enabled will never enter ROLAP mode, you should set the OnlineMode property to OnCacheComplete.  You can also prevent use of ROLAP mode by deselecting the Bring online immediately check box in the Storage Options dialog box.

Avoid making an attribute non-aggregatable unless it is at the end of the longest chain of attribute relationships in the dimension

Non-aggregatable attributes have non-all default members that affect the result of queries in which values for those attributes are not explicitly specified.  Therefore, you should avoid making an attribute non-aggregatable unless that attribute is regularly used.  Because the longest chain of attributes generally represents the most interesting exploration path for users, it is best to avoid having non-aggregatable attributes in other, less interesting chains.

Consider creating at least one user-defined hierarchy in each dimension that does not contain a parent-child hierarchy

Most (but not all) dimensions contain some hierarchical structure to the data which is worth exposing in the cube.  Frequently the Cube Wizard or Dimension Wizard will not detect this hierarchy. In these cases, you should define a hierarchy manually.

Do set the InstanceSelection property on attributes to help clients determine the best way to display attributes for member selection

If there are too many members to display in a single list, the client user interface can use other methods, such as filtered lists, to display the members. By setting the InstanceSelection property, you provide a hint to client applications to suggest how a list of items should be displayed, based on the expected number of items in the list.

Recommended guidelines for setting this property are as follows:

Property Value

Description

Guidelines

None

Do not display a selection list. Enable users to enter values directly.

DropDown

The number of items is small enough to display in a drop-down list.

<100 members

List

The number of items is too large for a drop-down list but does not require filtering.

< 500 members

FilteredList

The number of items is large enough to require users to filter the items to be displayed.

< 5000 members

MandatoryFilter

The number of items is so large that the display must always be filtered.

> 5000 members

The following C# code sample shows how to set the property dynamically:

if ( estimatedCount < 100 )     attribute.InstanceSelection = InstanceSelection.DropDown;
else if ( estimatedCount< 500 )     attribute.InstanceSelection = InstanceSelection.List;
else if ( estimatedCount< 5000 )     attribute.InstanceSelection = InstanceSelection.FilteredList;
else     attribute.InstanceSelection = InstanceSelection.MandatoryFilter;

Top Of Page

Cube Design Best Practices

Well-designed cubes will better match the needs of your end-users. The following best practices can improve usability and also performance of the cube.

Avoid including unrelated measure groups in the same cube

Having many measure groups in a cube can adversely affect the query performance of the cube, even for queries that only use a single measure group.  If your DSV contains many potential fact tables and they will not usually be used together, consider creating multiple smaller cubes containing topic areas that are used together.  Then, you can enable occasional cross-topic querying by creating linked measure groups that join together all measure groups in a special cross-topic cube.

Avoid having too many parent-child dimensions in a cube, especially when the dimension contains custom rollups or unary operators

Parent-child dimensions, especially those that contain custom rollups and unary operators, are very powerful and flexible.  However, in order to prevent poor query performance, such parent-child dimensions should only be used as necessary.

Do set AttributeHierarchyEnabled to False on any cube attributes that are below the level of granularity of all measure groups in the cube

Attributes are considered below the level of granularity for a measure group when no chain of attribute relationships exists between the granularity attribute and the attribute in question.  Such attributes will never have any data associated with them in the cube and will only confuse end-users.  For example, if a time dimension contains day, week, month and year attributes, whereas an inventory cube contains only data updated on a weekly basis, it is best to disable the day attribute for this cube by setting AttributeHierarchyEnabled to False for the day attribute only.

Avoid having very big intermediate measure groups or dimensions of many-to-many dimensions

Having very big intermediate measure groups could lead to potential performance issues in many-many dimensions. “Very big” means larger than the measure group or more than one million rows. You can also experience performance issues when using very big dimensions in many-many dimension relationships.

Consider using a processing query when using the scheduled polling option of proactive caching

A polling query is typically a singleton query that returns a value Analysis Services can use to determine whether changes have been made to a table or other relational object.  The polling query tells the proactive caching mechanism when it must read in new data. 

In contrast, a processing query is a query that returns a rowset that contains the changes made to a table associated with an Analysis Services object since the last time the table was polled, in order to incrementally update the multidimensional OLAP (MOLAP) cache for the object. Therefore, the processing query tells the proactive caching mechanism what data is new.  By setting the processing query, you can configure the system to read and process only the new data, instead of re-reading and re-processing the whole table.

Avoid creating multiple measure groups that have the same dimensionality and granularity

Having too many measure groups can adversely affect performance.  Moreover, the presence of many similar measure groups presents a more complex model to the end-user by dividing data on a common subject.  Instead, you should consider creating a single measure group that contains multiple partitions.  The common exception to this guideline is distinct count measures, which for performance reasons should be in their own measure groups.

Do put each distinct count measure into a separate measure group

Put each distinct count measure into its own measure group. This will improve performance.

Do set any explicit default members of role-playing dimensions directly on the cube dimensions

A dimension that has been given a different name in a cube than it has outside the cube is said to be role-playing.  The name that is used in the cube is known as the role the dimension plays within that cube.  Role-playing is used most often when a dimension plays more than one role in a cube.  For example, the [Order Date] and [Ship Date] cube dimensions are both based on the [Date] dimension, but are assigned different names, or roles.

Because such a dimension has a different name in the cube, whereas the default member expression is evaluated in the context of the cube, any explicit reference to the original dimension name in the default member will be invalid.  To specify the default member on the cube dimension, you can use the following syntax in the cube’s calculation script:

ALTER CUBE CurrentCube UPDATE DIMENSION <dimension name>, DEFAULT_MEMBER='<default member>'

This has the added benefit of enabling different default members for each of the roles a dimension plays in a cube. Such role specific default members frequently make sense from the business perspective.

Do reuse dimensions multiple times in a cube instead of creating duplicates of a dimension

In Analysis Services 2000, it was necessary to create new copies of a dimension for role-playing. In other words, to use two identical date dimensions, [Ship Date] and [Order Date], you needed to have two separate dimensions.  However, in Analysis Services 2005, this is not necessary and should be avoided as it will introduce unnecessary storage and maintenance costs.

Avoid having cubes with a single dimension

If a cube has only one dimension, you should consider splitting this single dimension into multiple dimensions based on logical business entities.  Typically, a cube contains only a single dimension because it was based on a single de-normalized table, which the Cube Wizard was unable to break into multiple dimensions. 

This single dimension almost always contains multiple logical business entities. From the perspective of the user, the different business entities would be more cleanly modeled and navigated as separate dimensions.

Do use the smallest numeric data type possible for measures

The data type of measures must be large enough to hold the largest aggregated value (the "all" value) but should be no larger than necessary to reduce storage costs.

Do ensure that the Collation property of OLAP objects is consistent with the collation of the relational source data when dealing with multilingual data

Collation controls both the sorting and equivalence of strings; therefore it is important to have the Analysis Services server use the appropriate collation for the data. If you use the wrong collation, you might see strange results, especially if the column is used for a distinct count measure. 

Collations can be set at the level of the server, database, cube, and dimension and also on individual column bindings.  The important point is to have the collation of your OLAP objects be consistent with the collation of the relational data on which they are built.  For example, the caption columns of translations usually contain text in another language and are therefore likely to have a different collation.

Do materialize referenced dimensions

To improve performance, reference dimensions should be materialized.  The only exception to this is the rare case when you are creating a reference dimension relationship between a local dimension and a linked measure group.  When a reference dimension is created by using the user interface for SQL Server 2005 Analysis Services, it will be materialized by default. 

Avoid using linked dimensions, especially if your cube has outline calculations (custom rollups, semi-additive measures, or unary operators) or scripts

Although it is possible to use dimensions linked from another database (or server) with a local measure group, this will adversely affect performance and should be avoided when possible. Instead, consider creating a local copy of the dimension. Even on the same server,   you should avoid linked dimensions.

Top Of Page

Partition Design Best Practices

Following some simple best practices can help ensure an effective data storage strategy that will enable the OLAP server to scale efficiently to your data volumes.

Avoid having partitions with more than 20 million rows

Large partitions should generally be broken up into multiple smaller partitions for better performance. As a rule, no partition should have more than 20 million rows.

Avoid having many small partitions in a measure group

Small partitions should generally be combined into fewer, larger partitions for better performance. As a guideline, consider combining partitions when a measure group has more than five partitions with less than two million rows each.

Do set the Slice property on partitions that are ROLAP or partitions that use proactive caching

Use of the Slice property lets the server know which partitions it must look in for data to answer queries.  For example, if a partition contains a slice that states it contains only data for 2002, when a query requests sales in 2003, the server will know it does not have to look in that partition in order to answer that query.

For MOLAP partitions, you do not have to specify the slice because the server will be able to figure out the relevant partitions after the data has been processed.  However, when you use proactive caching, it’s a good idea to specify the slice manually since the partition may be treated as ROLAP during the construction of the MOLAP cache.  (If a slice is manually specified on a MOLAP partition and that slice is not consistent with the data that is contained in the partition, the server will raise an error during processing of the data.) 

For ROLAP partitions, a slice should be specified or the partition will always have to be queried. 

To set the Slice property in Business Intelligence Development Studio, select the partition in the Partitions tab of the Cube Editor. In the Properties window, click the text box for the Slice property.  Click the ellipsis (...) button to open the Partition Slice dialog box. You can type an MDX expression to specify the member on which you want to slice.  To slice on multiple hierarchies, enter a tuple containing the members on which you want to slice.

Consider partitioning a distinct count measure group along the dimension used most often to query the distinct count measure

When partitioning a measure group that includes a distinct count measure, consider partitioning the measure group along the dimension that is most often used to query distinct count measure. This will provide improved query performance by reducing the frequency that all partitions must be accessed.

Top Of Page

Aggregation Design Best Practices

Good aggregation design is important for achieving good performance when dealing with large amounts of data. Although aggregation design is a complex topic, much of the complexity can be handled automatically by the Storage Design Wizard in SQL Server 2005 Analysis Services.  If you decide to manually design aggregations using some other tool, you’ll need to plan your design much more carefully.  The following best practices contain guidance to help succeed in both scenarios.

Consider having aggregations for each partition of significant size

Aggregations will generally improve the performance for partitions of non-trivial size. We recommend using aggregations when partition size exceeds 500,000 rows.

Do include the granularity attribute of the time dimension in aggregations for measure groups with semi-additive measures

Semi-additive measures are calculated at run time by using the granularity attribute of the time dimension.  Therefore, only aggregations that contain this granularity attribute will help performance when calculating the value of semi-additive measures. 

If you set the AggregationUsage property to Full, the Aggregation Design Wizard and the Usage-Based Optimization Wizard will include this attribute in every aggregation.  If you manually design your aggregations, make sure to include such attributes in every aggregation.

Do not build too many aggregations

Do not build excessive aggregations. This can adversely affect performance by of increasing search space during queries and increasing the work necessary during processing.  As a rule of thumb, do not build more than 500 aggregations per partition.

Consider sharing aggregation designs between partitions of similar size and usage

It is usually not necessary or desirable from a management perspective to create separate aggregation designs for every partition.  You generally only need different aggregation designs for partitions that have different sizes or usage patterns. Therefore, similar aggregation designs are not necessary and will add complexity to the database. 

Partitions that have similar size and usage should share the same aggregation designs. As a rule, three aggregation designs per measure group are generally enough.

Consider creating separate aggregation designs for partitions with significantly different size or usage

When partitions have significantly different size or usage patterns, it is generally better to create separate aggregation designs and customize the design appropriately.  For example, it makes sense to create separate partitions for each month of the current year and use the same aggregation design for these partitions. However, you will probably want to create a separate aggregation design for the partition that contains all the data for a past year.  This is better because archived data usually is combined into larger partitions and is accessed less frequently.

For example, the storage settings for partitions can be managed by using the following guidelines:

   Frequently queried partitions -> Use MOLAP with lots of aggregations

   Periodically queried partitions -> Use MOLAP with less or no aggregations

   Rarely queried partitions -> Use ROLAP with no aggregations

Do use a lower performance gain with regular aggregation design and a higher performance gain with usage-based optimization

When you design generic aggregations, you should target a lower performance gain (20-30%).  When you design aggregations using the Usage-Based Optimization Wizard, you should target a higher performance gain (70-80%), because these aggregations are more specific to actual use.

Consider setting AggregationUsage to Unrestricted on high-use attributes that are not the key of a dimension and not in a hierarchy

By default, the aggregation design algorithm considers only key attributes and attributes in natural hierarchies for inclusion in aggregations.  Although this is usually the best strategy, if you have an attribute that is neither the key attribute nor contained in a hierarchy, but you expect people to group by the attribute or filter on it, you should consider setting AggregationUsage to Unrestricted. When you do this, the aggregation design algorithm will consider the attribute when it designs aggregations.

Avoid Setting AggregationUsage to Full on Large Attributes

Avoid setting the AggregationUsage property to Full on attributes that have many members. If you use the Aggregation Wizard, this setting may prevent any aggregations from being created, because this setting prevents the wizard from creating aggregations that do not include this attribute.

Do set member and row counts accurately for the partition when designing aggregations

Although member and row counts do not have to be exact, they should be reasonably accurate because they will be used to evaluate the cost, both in disk size and read time, of aggregations. Moreover, these counts will significantly affect the aggregations chosen by the aggregation design algorithm. 

You may find that not all members of a dimension exist in a partition, especially when the partition policy is based on the dimension: for example, in time-based partitioning.  When this is true, it is important to provide an accurate approximation of the actual count of members found in the partition.

Consider including the granularity attribute of the intermediate dimensions of many-to-many dimensions in aggregations

When accessing data using a many-to-many dimension, the server will always use the granularity attribute of the dimension that serves as an intermediate dimension for that many-to-many dimension.  Therefore, only aggregations that contain this granularity attribute will help performance when using many-to-many dimensions.  Aggregations on other attributes of the intermediate dimension can still be useful when the intermediate dimension is used directly, and when the many-to-many dimension is not used in a query.

If you have multiple dimensions shared between the measure groups in a many-to-many relationship, it is undefined which dimension the server will use as the intermediate dimension. Therefore, you should consider including the granularity attributes of each such potential intermediate dimension in aggregations.

Do include in aggregations the granularity attribute of dimensions that contain unary operators or custom rollups

Unary operators and custom rollups are calculated at run time from the granularity attribute of the dimension that contains them.  Therefore, only aggregations that contain this granularity attribute will help performance when using dimensions with unary operators or custom rollups. 

The Aggregation Design Wizard and the Usage-Based Optimization Wizard will automatically include such dimension’s granularity attributes in aggregations.  However, if you manually design aggregations, be sure to include such granularity attributes in every aggregation.

Avoid creating aggregations that are larger than one-third the size of the fact data

Aggregations this large generally do not help performance.  The Aggregation Design Wizard and Usage-Based Optimization Wizard will apply this rule automatically, but you should monitor the size of aggregations and the size of the fact data when you manually design aggregations.

Do remove aggregation designs that are not applied to any partitions

Remove any aggregation designs that are not used by any partitions. These can slow metadata operations and offer no benefit.  Removal of unused aggregations is performed automatically when you use the Copy Aggregation Design dialog box in SQL Server Management Studio. Removal of unused aggregations is also automatic in the Aggregation Design Wizard and the Usage-Based Optimization Wizard. However, if you manually create aggregation designs you should review the design when you have finished and remove unnecessary aggregations.

Do not create aggregations that contain multiple attributes from the same attribute relationship chain

It is redundant to include an attribute in an aggregation if the value of the attribute is implied by an attribute already in the aggregation, because the implied attribute’s value can be calculated from the first attribute.  Also, for a given query, only one of these attributes is of interest in the aggregation.  The best practice is to remove the implied attribute from the aggregation and, optionally, create a new aggregation that contains the implied attribute but not the implying attribute.  The Aggregation Design Wizard and Usage-Based Optimization Wizard will apply this rule automatically, but if you manually design aggregations, you may have to modify your design to remove redundant attributes.

Consider including in aggregations only those attributes with rigid relationships to their dimension keys

Aggregations are considered flexible when any attribute included in the aggregation is related, either directly or indirectly, to the key of its dimension through any attribute relationship that has RelationshipType set to Flexible.  Aggregations are also considered flexible when they include a parent-child hierarchy.  Because a flexible aggregation might be dropped during a Process Update of a dimension and will only be recreated when Process Index is performed, a better practice is to create rigid aggregations whenever possible, instead of flexible aggregations.  Sometimes you can achieve this by selecting an attribute closer to the key of the dimension.

For example, assume the following chain of relationships, where the notation ==> means a rigid relationship and --> means a flexible relationship:

    Customer ==> City --> Sales Region ==> Country

Given these relationships, any aggregations that use Sales Region or Country will be flexible, whereas aggregations that use Customer or City may be rigid.  To avoid creating a flexible relationship, you might include City in the aggregation instead of Sales Region.

你可能对下面的文章感兴趣

• 64位系统下IIS7 ISAPI处理器加载失败
• Analysis Service 2005 OLAP Best Practice White Paper
• Analysis Services 2005 OLAP设计最佳实践白皮书（中文）
• Analysis Services：你应该使用多对多维度吗？
• BIDS对于维度属性键为可变长列时存在的Bug
• BIDS部署时出现元数据管理器发生错误
• OLAP中的AverageOfChildren聚合方式
• SSAS处理时“找不到属性键”的解决办法
• 全半角空格导致的Analysis Services处理错误
• 权限不足导致的Analysis性能计数器在Vista/win2008下失效的问题

还有一次，是因为在Cube中建立了计算成员，但是忘了写表达式，结果后来部署的时候出错。在BIDS中，你没法指望能够双击错误就定位到出错的地方，你只能把每个设置的地方都看一看，哪里有可能出错。而且，在BIDS中，重构能力稍微弱了一点，像我改变了维度中的属性名称，结果属性关联中相应的名称居然没有帮我自动更改，等到编译的时候才提醒我。

像这种莫名其妙的问题，在做技术的时候我们经常会遇到。解决的办法也没有“范式”可循，只能7分靠经验，3分靠运气了。

你可能对下面的文章感兴趣

• 64位系统下IIS7 ISAPI处理器加载失败
• Analysis Service 2005 OLAP Best Practice White Paper
• Analysis Services 2005 OLAP设计最佳实践
• Analysis Services：你应该使用多对多维度吗？
• BIDS对于维度属性键为可变长列时存在的Bug
• OLAP中的AverageOfChildren聚合方式
• SSAS处理时“找不到属性键”的解决办法
• 全半角空格导致的Analysis Services处理错误
• 权限不足导致的Analysis性能计数器在Vista/win2008下失效的问题
• 解决维度成员中的非法Xml字符导致的查询错误