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