首先，我对层次结构在概念方面的含义以及它如何影响DW星形模式的设计感到满意。我有一些具有大量属性的维度，我 可以 在SSAS中创建大量层次结构。我想更好地理解OLAP引擎如何使用我创建的层次结构，以便我可以就如何设计层次结构做出更明智的决定（这是前几次键入的一个难以理解的词）。 SSAS关于出现在多个层次结构中的属性也存在局限性，因此有时我需要做额外的工作来解决这些限制或决定哪个层次结构更重要。
我也想知道层次结构可能带来的负面影响，例如使维度更容易让用户感到困惑。我可能隐藏层次结构中包含的属性以消除重复属性并使维度更容易混淆。但是，用户希望看到一年中的哪几个月他们通常会获得更多销售额。 如果我隐藏了month属性，使其只能通过Year-＆gt; Month层次结构，那么他们是否必须始终包含层次结构的Year部分，以防止他们进行此类分析？
关于层次结构的文章很少说明了“允许用户深入查看详细数据”的效果。这是误导性的，因为您可以简单地将单独的年份和月份属性拖到报表中，而您在不使用层次结构的情况下完成了这一操作。所以这样的解释有点肤浅。我觉得必须有更多的东西。
有些文章似乎建议它确定是否考虑将属性用于聚合。这似乎是反直觉的，因为我认为在多维数据集中包含属性时已经发生了这种情况。我的意思是创建一个由属性组成的立方体的全部意义是要有一个所有属性的交集，这样你就可以快速聚合它们的任何组合，所以当一些东西暗示与之相反时，它只会混淆我在层次结构中考虑聚合：
属性仅在属性层次结构中公开[与用户相对 层次结构]不会被自动考虑用于聚合 聚合设计向导。涉及这些属性的查询是 通过总结主键的数据来满足。没有 聚合的好处，查询这些属性的性能 层次结构可能很慢。 -SSAS 2008性能指南
有人可以解释引擎如何使用我的层次结构，而只是在多维数据集中包含该属性？ （除了将属性组合在一起的美学）
不自然的等级制度让我感到困惑，特别是对我而言。在SSAS 2008性能指南中，他们将一个示例显示为Gender-＆gt; Education层次结构。我认为我的用户每次不得不通过性别训练去教育时都会嘟“”愚蠢的程序员“。
您何时以及何时不创建层次结构时遵循什么理性？
答案 0 :(得分：15)
不确定100％我将说的评论是否适用于SSAS，但由于我们都是100％兼容MDX / XMLA，因此它类似。
您可以先阅读this和many-to-many documentation。
使用层次结构与级别和属性之间的第一个区别是性能。您有两种不同的情景进行深入研究（将[亚洲]视为特定成员，让我们找到[亚洲]的所有国家/地区）：
第一个选项很简单且非常快（结构在内存中）。第二个意味着迭代所有国家并“检查”它们是否存在（又称[亚洲国家]）。这可能是巨大属性（> 100k）的痛苦。完成后，我们需要转到我们的事实表，其中每个成员都有一组关联的事实行。具有单个层次结构的版本也是直接的。有两个人可能意味着一些额外的内部操作 - ＆gt; [亚洲]的所有行减去特定国家的行。简化版本对缓存也更方便。
其次，您可以定义一个可以直接在GUI中使用的“自然”钻取路径。
最重要的是，您可以添加特殊的聚合类型（First，Last，Min，Max ...），这些类型将考虑给定层次结构。
有成功的OLAP解决方案可以在没有分层结构的情况下工作，但是您可以使用较少的功能来制作解决方案。
我希望它能帮助您更好地理解这些概念。