SSAS层次结构的目的和效果？

首先，我对层次结构的概念以及它如何影响DW星型模式的设计感到满意。我有很多属性的维度，我可以在SSA中创建很多层次结构。我希望更好地了解OLAP引擎如何使用我创建的层次结构，以便我能够对如何设计层次结构做出更明智的决定（这是一个很难在最初几次键入的词）。对于出现在多个层次结构中的属性，SSA也有一些限制，因此有时我必须做额外的工作来克服这些限制，或者决定哪个层次结构更重要

我还想知道层次结构可能会有什么负面影响，比如让用户对维度更加困惑。我可能会隐藏层次结构中包含的属性，以消除重复属性并减少维度的混乱。但是用户希望看到他们通常在一年中的哪个月获得更多的销售额如果我隐藏了“月份”属性，使其只能通过“年度->月份”层次结构使用，是否强制他们始终包括层次结构中的“年度”部分，从而阻止他们进行此类分析？

关于层次结构的文章中很少提到“允许用户深入到详细的数据”。这是有误导性的，因为您可以简单地将单独的年和月属性拖到报表中，而无需使用层次结构就可以实现这一点。所以这样的解释有点肤浅。我觉得肯定还有很多事情要做

一些文章似乎认为，它决定了是否考虑将属性用于聚合。这似乎与直觉相反，因为我认为在多维数据集中包含属性时已经发生了这种情况。我的意思是，创建一个由属性组成的多维数据集的整个要点是，所有属性都有一个交集，这样您就可以快速地对它们的任何组合进行聚合，因此，当有与此相反的东西表示只考虑层次结构中的属性进行聚合时，我会感到困惑：

属性仅在属性层次结构中公开[与用户相反] 系统不会自动将层次结构]考虑用于聚合 聚合设计向导。涉及这些属性的查询是 通过汇总主键中的数据而感到满意。没有 聚合的好处，针对这些属性的查询性能 层次结构可能很慢。 -SSAS 2008性能指南

有人能解释一下引擎是如何使用我的层次结构的，而不是仅仅将属性包含在多维数据集中的吗？（除了将属性组合在一起的美学）

对我来说，不自然的层次结构尤其令人困惑。在SSAS 2008绩效指南中，他们展示了一个例子，即性别->教育层次结构。我想每次我的用户为了接受教育而不得不钻性别的空子时，他们都会咕哝着“愚蠢的程序员”

---

什么时候以及什么时候不创建层次结构，你会遵循什么理性？

不确定我要说的评论100%适用于SSA，但由于我们都是100%MDX/XMLA兼容的，这是相似的

你可以从阅读和阅读开始

使用具有级别和属性的层次结构的第一个区别是性能。您有两种不同的细分场景（以[亚洲]为特定成员，让我们查找[亚洲]的所有国家）：

• 使用具有级别：[Asia].children（）的层次结构
• 使用属性：（[亚洲]，[国家]）

第一个选项非常简单且非常快（结构在内存中）。第二种方法意味着遍历所有国家，并“检查”它们是否存在（也就是亚洲国家）。对于大型属性（>100k）来说，这可能是一个难题。完成后，我们需要转到事实表，其中每个成员都有一组关联的事实行。具有单一层次结构的版本也是直接的。一行加两行可能意味着一些额外的内部操作->亚洲的所有行减去特定国家的行。简化版对于缓存来说也更方便

其次，您定义了一个“自然”的深入路径，可以直接在GUI中使用

在顶部，您可以添加特殊的聚合类型（First、Last、Min、Max…），这些类型将考虑给定层次结构的结构

有一些成功的OLAP解决方案可以在没有层次结构的情况下工作，但您可以使用的功能较少，无法制作解决方案

---

我希望它能帮助您更好地理解这些概念。

切换到Dvorak布局，在其上键入层次结构要容易得多；）