Назначение и влияние иерархий SSAS?

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

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

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

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

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

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

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

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