作者：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下失效的问题

为了说明这个区别，我引用之前一篇文章《Google Analytics中的UniquePageView和Visit的区别》中的实验数据。

实验步骤

我在自己的网站上放了三个很特殊的静态页面，并加上了ga的代码，这样可以排除其他不必要的干扰。

• gatestpage_a.html
• gatestpage_b.html
• gatestpage_c.html

实验的几点说明：

• 为了模拟不同用户访问我的网站，我会清除掉所有的Cookie
• 为了模拟同个用户的不同会话，我会重启浏览器
• 为了保证数据能够成功发送到Google服务器，我使用HTTP Watch来监视所有发送的数据

测试访问记录（测试时间2009-12-06 21:40）：

• 用户A  会话1  gatestpage_a.html 
• 用户A  会话1  gatestpage_b.html 
• 用户A  会话1  gatestpage_b.html
• 用户A  会话1  gatestpage_c.html 
• 用户A  会话2  gatestpage_a.html 
• 用户A  会话2  gatestpage_c.html 
• 用户B  会话3  gatestpage_a.html
• 用户B  会话3  gatestpage_a.html  
• 用户C  会话4  gatestpage_a.html 
• 用户C  会话4  gatestpage_b.html
• 用户C  会话5  gatestpage_c.html

报表观察

热门内容（Top Content）报表中的Page维度

我们先来看热门内容报表中用到的Page维度。

从上面的报表中的pageview数据来看，这里的页面应该指的是所有页面的访问情况。PageView指的是页面被访问的次数，包括重复访问，而UniquePageView则剔除了重复访问的成分，一次会话只计一次，这和Visit的定义是一样的。

自定义报表（Custom Reporting）中的Page维度

上面的热门内容报表中的指标是针对单个页面的，如果我们从Page维度来看访问量（Visit）指标，结果又是怎样呢？为此，我创建了一个自定义报表。

非常简单，只有一个维度和一个指标。报表汇总结果如下：

我们可以看到，这里只列出了两个页面，gatestpage_a.html和gatestpage_c.html。这两个页面有什么特别的呢？我们回去看一下实验的步骤，发现，这两个页面均是曾经“担任”过着陆页面的角色。也就是说，在这里，我们报表中选择的“页面维度”不是列出所有页面，而是列出所有着陆页面。后面的visit指标则代表着某个页面作为着陆页面的会话数。

高级群体中的Page维度

在高级群体中，也有一个Page维度，这又是代表什么意思呢？是所有页面还是着陆页面呢？还是其他？为此我创建了一个高级群体，仅包含一个条件，Page精确匹配/gatestpage_b.html。

我们回到热门内容报表中，应用此高级群体。理所当然的我们可能会认为报表中只会列出b页面的数据。

但是我们看到，报表并不是只列出了b页面的数据，其他页面的数据也有，只不过发生了一些差异。我们回过头去对比一下这里的数据和上面写的实验步骤，我们就可以得出结论，这时候看的内容，其实是b页面和b页面相关页面的报表。

如果用户没看过或者不理解我之前文章中提到的高级群体的过滤方式的话，那么可能不会容易理解这里看到的数据。

我们再将此高级群体应用在之前创建的自定义报表上面：

我们看到，报表中只列出了gatestpage_a.html页面，visits数据为2。对比实验步骤，我们就知道，这里看的内容，是访问过b页面的所有会话的着陆页面报表。

也就是说，在高级群体这里的“页面维度”，实际上也是代表“所有页面”的意思。

希望此文章能够帮你更好的理解Google Analytics工具。

——Kevin Yang

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

• Analysis Services：你应该使用多对多维度吗？
• BIDS对于维度属性键为可变长列时存在的Bug
• Document.Referrer丢失的几个原因
• 当Google Analytics、Firefox和IIS走到了一起…
• 盘点国内外不同特色的Web流量分析工具
• 解决维度成员中的非法Xml字符导致的查询错误
• 高效使用Google Analytics进行Web流量分析

问题描述

最近在项目中遇到这么个情况，在展开维度成员的时候，服务端抛出了“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也能自动定位到异常代码

后来使用排除法发现，在出问题的维度中只留下一个Key属性时就没有问题了，然后我再将数据仓库中该维度表的各个列逐个添加到此维度中去，发现当添加了存放Url的可变长列（NVarchar，2048）时就会出错。检查了一下该维度属性的KeyColumns设置，发现上面属性键确实是设置对了，但是该键的DataSize值确实1024。

猜想可能这是BIDS的一个bug吧。

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

• Analysis Services 2005 OLAP设计最佳实践
• Analysis Services：你应该使用多对多维度吗？
• BIDS部署时出现元数据管理器发生错误
• Google Analytics中的Page维度
• SSAS处理时“找不到属性键”的解决办法
• 解决维度成员中的非法Xml字符导致的查询错误