Sql 自然层次结构中的属性关系

我发现很难正确理解在SQL Server Analysis Services 2008 R2中实现维度属性之间的属性关系的最佳用例场景

从我所阅读的内容来看，出于性能原因，似乎应避免使用“非自然层次结构”，而“自然”层次结构是首选的用户定义层次结构

参考：

话虽如此，我想问你对以下情况的看法：

我有一个具有以下属性的维度：

---

维度名称：DimReserveData
维度成员：

节目行
覆盖范围代码
覆盖类型
覆盖状态

---

我希望将这些属性按如下所示的相同顺序放置在层次结构中：

保留数据层次结构
........................................
节目行
覆盖范围代码
覆盖类型
覆盖状态
........................................

层次结构信息：

程序行是表示提供的保险范围程序的代码。（例如：AA-23、BB-25、CC-78等）

coverage code属性表示表示为特定程序行提供的特定覆盖范围的数字代码。（例如：123456等）

覆盖率类型表示与特定覆盖率代码关联的覆盖率类型。（例如：车辆或身体）

覆盖率状态表示给定覆盖率的状态（打开或关闭）

因此，关于层次结构中的基数，我们可以说：

一个程序行可以包含多个覆盖代码
一个覆盖代码可以包含多种类型
一个覆盖率类型可以包含多个状态值

因此，浏览层次结构将产生以下属性和相应的成员：

DimReserveData
....................................................................................................*.................................
节目行|覆盖代码|覆盖类型|覆盖状态 ......................................................................................................................................
AA-12…………123…………车辆…………开放式
BB-14 456车辆关闭
CC-23、123、车载、开放式 DD-23 456身体打开

我的问题是，在“自然”或“非自然”层次结构中对这些属性进行建模是否是一种好的做法。我希望使用“自然”层次结构来提高性能

显然，将此层次结构建模为“自然”需要使用属性关系

回到我上面的示例层次结构，如果一个给定的覆盖代码属性属于多个程序行以及包含相同覆盖类型的多个覆盖代码，那么“自然”层次结构是否可能

在这篇有帮助的文章中：提到了在一个城市属于多个州或省的场景中，可以修改属性键列，以便层次结构中的每个属性都是唯一定义的

在我上面的例子中，这会起作用吗

我想我可以这样建模属性关系：（使用SSAS2008R2）

[维度中的代理键属性]-->覆盖率状态-->覆盖率类型-->覆盖率代码-->程序行

上述每个属性的键列设置如下：

"
覆盖范围状态：
....................................
覆盖状态
覆盖类型

"
覆盖范围类型：
....................................
覆盖类型
覆盖范围代码

"
覆盖范围代码：
....................................
覆盖范围代码
节目行

"
节目行：
....................................
节目行

这样行吗？此场景是否更适合于“非自然”层次结构

我非常感谢你花时间阅读我上面的帖子

---

谢谢

如果必须在层次结构中包含这些，请强制它为自然层次结构。与仅仅使用不自然的层次结构相比，您将支付较轻的性能损失。强制自然层次的惩罚主要与关键点大小的增加有关（因为您将使用复合关键点来自然化层次）

但也许您应该考虑一下，通过将这些属性强制纳入用户层次结构，您试图实现什么

它是为了简化一些MDX查询吗？ 维度是否太宽（与键直接相关的属性太多）并在处理过程中造成内存压力

---

如果答案是简单地将这些属性分组到用户界面（Ex.Excel），那么您可能需要简单地考虑允许这些属性以您喜欢的顺序出现的命名约定…

< P>微软删除了您引用的KB（参考文献）

---

我真的对管理KB内容的人感到失望。有人需要把手指从钥匙上拿下来！这就是我的知识库，我可能花了一个多星期的时间帮助MS记录非自然层次结构中的意外问题（与属性的等效交叉连接相比）

覆盖率状态可能需要定义为计划行、覆盖率代码、覆盖率类型和覆盖率状态的组合。覆盖类型基于