Назначение и эффект иерархий SSAS?

Во-первых, мне комфортно, что такое иерархия с точки зрения концепции и как она влияет на дизайн звездообразной схемы DW. У меня есть измерения с множеством атрибутов, и я мог создать множество иерархий в SSAS. Я хотел бы лучше понять, как механизм OLAP использует иерархии, которые я создаю, чтобы я мог принимать более обоснованное решение о том, как я проектирую свои иерархии (это трудное слово для ввода в первые несколько раз). В SSAS также есть ограничения в отношении атрибутов, появляющихся в нескольких иерархиях, поэтому иногда мне приходится выполнять дополнительную работу, чтобы обойти эти ограничения или решить, какая иерархия более важна.

Мне также интересно, какое негативное влияние может иметь иерархия, например, создание размер более запутанный для пользователей. Я мог бы скрыть атрибуты, включенные в иерархии, чтобы исключить повторяющийся атрибут и сделать измерение менее запутанным. Но затем пользователь хочет узнать, в какие месяцы года у него обычно больше продаж. Если я скрыл атрибут месяца, чтобы он был доступен только через иерархию Год-> Месяц, вынуждены ли они всегда включать часть иерархии Год, не позволяя им выполнять такой анализ?

Я мало в статьях об иерархиях говорилось что-то вроде «позволяющего пользователю перейти к подробным данным». Что вводит в заблуждение, потому что вы можете просто перетащить отдельные атрибуты года и месяца в отчет, и вы добились этого без использования иерархии. Так что такое объяснение немного поверхностно. Я чувствую, что это должно быть намного больше.

Некоторые статьи, кажется, предполагают, что он определяет, будут ли атрибуты учитываться для агрегирования. Это кажется нелогичным, потому что я думал, что это уже происходит, когда вы включаете атрибут в куб. Я имею в виду, что весь смысл создания куба, состоящего из атрибутов, состоит в том, чтобы иметь пересечение всех атрибутов, чтобы вы могли быстро агрегировать любую их комбинацию, поэтому меня смущает, когда что-то подразумевает обратное, говоря только атрибуты в иерархиях рассматриваются для агрегирования:

Атрибуты отображаются только в иерархиях атрибутов [в отличие от пользователя иерархии] не рассматриваются автоматически для агрегирования Мастер создания агрегатов. Запросы с этими атрибутами доволен суммированием данных из первичного ключа. Без преимущество агрегатов, производительность запросов по этим атрибутам иерархии могут быть медленными. -SSAS 2008 Performance Guide

Может ли кто-нибудь объяснить, как движок использует мои иерархии в отличие от простого включения атрибута в куб? (помимо эстетики объединения атрибутов вместе)

Неестественные иерархии особенно сбивают с толку меня. В SSAS 2008 Performance Guide они показывают один пример в виде иерархии «Гендер-> Образование». Я думаю, что мои пользователи бормотали «тупой программист» каждый раз, когда им приходилось разбираться в гендерных вопросах только для того, чтобы добраться до образования.

Какую рациональность вы используете, когда и когда не создавайте иерархию?