我发现很难正确理解在SQL Server Analysis Services 2008 R2中实现维度属性之间属性关系的最佳用例场景。
根据我的阅读，出于性能原因，出现“非自然层次结构”，“自然”层次结构是首选的用户定义层次结构。< / p>
参考：http://support.microsoft.com/kb/2131988
话虽如此，我想就下列情况提出您的想法：
我有一个包含以下属性的维度：
尺寸名称： DimReserveData
维度成员：
计划行
覆盖代码
覆盖类型
覆盖范围状态
我想将这些属性放在层次结构中，如下所示，顺序相同：
ReserveDataHierarchy
........................................
计划专线
覆盖代码
覆盖类型
覆盖状态
........................................
层次结构信息：
计划行是代表所提供的保险范围计划的代码。 （例如：AA-23，BB-25，CC-78等）
coverage代码属性表示代表为特定程序行提供的特定coverage的数字代码。 （例如：123,456等）
覆盖类型表示与特定覆盖代码关联的覆盖类型。 （例如：车辆或身体）。
覆盖状态表示给定覆盖范围的状态（打开或关闭）。
因此，我们可以在层次结构中说出关于基数的以下内容：
一个程序行可以包含许多覆盖代码。
一个覆盖代码可以包含许多类型。
一种覆盖类型可以包含许多状态值。
因此，浏览层次结构将产生以下属性和相应的成员：
DimReserveData
.................................................. .................................................. * .................................
计划行|覆盖代码|覆盖类型|覆盖状态
.................................................. .................................................. ..................................
AA-12 ................. 123 ....................车辆........ ........打开
BB-14 ................. 456 ....................车辆........ .........关闭
CC-23 ................. 123 ...................车辆......... ........打开
DD-23 ................. 456 ....................身体........ ..............打开
我的问题是，如果在“自然”或“非自然”层次结构中对这些属性进行建模是一种好习惯。我想使用“自然”层次结构来提高性能。
显然，将此层次结构建模为“自然”将需要使用属性关系。
回到上面的示例层次结构，如果一个给定的Coverage Code属性属于多个Program Lines以及包含相同Coverage Type的多个Coverage Code，是否可以使用“Natural”层次结构？
在这篇有用的帖子中：http://sqlserverpedia.com/blog/sql-server-bloggers/idiots-guide-to-ssas-attribute-relationships/提到在一个城市属于多个州或省的情况下，可以修改属性键列，以便层次结构中的每个属性都是唯一定义的。
这可以在上面的例子中使用吗？
我在想我可以像这样建模属性关系:(使用SSAS 2008 R2）
[来自维度的代理键属性] - ＆gt;覆盖状态 - ＆gt;覆盖类型 - ＆gt;覆盖率代码 - ＆gt;计划行
上面的每个属性的关键列都设置如下：
....................................
覆盖状态：
....................................
覆盖状态
覆盖类型
....................................
覆盖类型：
....................................
覆盖类型
覆盖范围代码
....................................
承保范围代码：
....................................
覆盖代码
程序行
....................................
计划行：
....................................
程序行
这会有用吗？这种情况更适合“非自然”层次结构吗？
我非常感谢您在上面阅读我的帖子的时间！
谢谢！
答案 0 :(得分：1)
如果你必须在层次结构中使用它们，强制它是一个自然的。与仅使用不自然的层次结构相比，您将支付不那么严重的性能损失。强制自然层次结构的惩罚主要与密钥大小的增加有关（因为您将使用复合键来自然化层次结构）。
但也许您应该考虑通过将这些属性强制转换为用户层次结构来实现您想要实现的目标？
是否简化了一些MDX查询？ 尺寸是否太宽（与键直接相关的属性太多）并且在处理期间导致内存压力？
如果答案仅仅是为用户界面（例如Excel）分组这些属性，您可能需要考虑简单地使用允许这些属性按您喜欢的顺序显示的命名约定...
答案 1 :(得分：0)
Microsoft删除了您引用的KB（参考：http://support.microsoft.com/kb/2131988）
我真的对那些在那里管理KB内容的人感到沮丧。有人需要将手指从DEL键上移开！那是我的知识库，我可能花了一个多星期的时间来帮助MS记录非自然层次结构中的意外问题（与属性的等效交叉联接相比）！！！