ssas - SSAS层次结构的目的和作用？

Question

首先，我对概念的层次结构及其对DW星形模式设计的影响感到满意。我有一些具有很多属性的维度，并且可以在SSAS中创建很多层次结构。我想更好地理解OLAP引擎如何使用我创建的层次结构，以便可以对如何设计层次结构做出更明智的决定（这是很难键入的几次）。 SSAS对于出现在多个层次结构中的属性也有一些限制，因此有时我不得不做一些额外的工作来解决这些限制，或者决定哪个层次更为重要。

我还想知道层次结构可能带来哪些负面影响，例如使维度对于用户而言更加混乱。我可能会隐藏层次结构中包含的属性，以消除重复的属性并减少维度的混乱。但是用户希望查看他们通常在一年中的哪个月份获得更多的销售额。如果我已经隐藏了month属性，使其仅在Year-> Month层次结构中可用，那么他们是否被迫始终包含该层次结构的Year部分，从而阻止他们进行此类分析？

在有关层次结构的几篇文章中，有一些陈述是“允许用户向下钻取详细数据”。这具有误导性，因为您可以简单地将单独的年和月属性拖动到报表中，而无需使用层次结构即可完成此操作。因此，这种解释有些肤浅。我觉得这还不止于此。

一些文章似乎建议它确定是否考虑将属性用于聚合。这似乎很不直观，因为当您在多维数据集中包含属性时，我认为这种情况已经发生。我的意思是创建包含属性的多维数据集的全部目的是要使所有属性具有交集，以便您可以快速汇总它们的任何组合，因此，当某些内容暗示与之相反时，仅说属性就使我感到困惑在层次结构中考虑进行聚合：


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


有人可以解释与仅在多维数据集中包含属性相比，引擎如何使用我的层次结构吗？ （除了将属性分组在一起的美感）

不自然的等级制尤其使我感到困惑。在《 SSAS 2008绩效指南》中，它们以“性别->教育”层次结构为例。我认为我的用户每次都必须钻研Gender才能进入教育行业时，都会对“愚蠢的程序员”发脾气。

在何时以及何时不创建层次结构时，您遵循什么理性？

Answer 1

不确定我将说100％的注释是否适用于SSAS，但由于我们都是100％MDX / XMLA兼容的，因此类似。

您可以先阅读this和many-to-many documentation。

使用具有级别和属性的层次结构的第一个区别是性能。您有两种不同的下钻场景（以[Asia]作为特定成员，然后查找[Asia]的所有国家/地区）：


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


第一个选择是琐碎且非常快的（结构在内存中）。第二个含义是遍历所有国家，并“检查”它们是否存在（又名[亚洲]国家）。对于巨大的属性（> 100k），这可能会很痛苦。完成后，我们需要转到事实表，其中每个成员都有一组关联的事实行。具有单一层次结构的版本还是直接的。一加二可能意味着一些额外的内部业务-> [Asia]的所有行减去一个特定国家/地区的行。简化版本对于缓存也更方便。

其次，您定义了可以在GUI中直接使用的“自然”钻取路径。

最重要的是，您可以添加特殊的聚合类型（第一，最后，最小，最大...），这些类型将考虑给定层次结构的结构。

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

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