Во-первых, я чувствую себя комфортно с тем, что такое иерархия с точки зрения концепции и как она влияет на дизайн схемы DW star star. У меня есть некоторые параметры с большим количеством атрибутов, и я мог создавать множество иерархий в SSAS. Я хотел бы лучше понять, как механизм OLAP использует созданные мной иерархии, чтобы я мог принять более обоснованное решение о том, как я разрабатываю свои иерархии (это сложное слово для ввода первых нескольких раз). Существуют также ограничения с SSAS в отношении атрибутов, появляющихся в нескольких иерархиях, поэтому иногда мне приходится выполнять дополнительную работу, чтобы обойти эти ограничения или решить, какая иерархия важнее.
Я также задаюсь вопросом, какое негативное воздействие может иметь иерархия, например, сделать измерение более запутанным для пользователей. Я мог бы скрыть атрибуты, которые включены в иерархии, чтобы устранить дублирующий атрибут и сделать измерение менее запутанным. Но тогда пользователь хочет увидеть, какие месяцы года они обычно получают больше продаж. Если я спрятал атрибут месяца, чтобы он был доступен только через иерархию Year- > Month, они вынуждены всегда включать в себя часть года иерархии, не позволяя им выполнять такой анализ?
В нескольких статьях по иерархиям было указано что-то, что "позволяет пользователю переходить к детальным данным". Это вводит в заблуждение, потому что вы можете просто перетащить отдельные атрибуты года и месяца в отчет, и вы достигли именно этого, не используя иерархию. Поэтому такое объяснение немного поверхностно. Я чувствую, что должно быть намного больше, чем это.
Некоторые статьи, похоже, предлагают определить, учитываются ли атрибуты для агрегации. Это кажется встречным интуитивным, потому что я думал, что это уже происходит, когда вы включили атрибут в куб. Я имею в виду, что цель создания куба, состоящего из атрибутов, состоит в том, чтобы иметь пересечение всех атрибутов, чтобы вы могли быстро агрегировать любую комбинацию из них, поэтому меня смущает, когда что-то подразумевает противоположность тому, что говорят только атрибуты в иерархиях рассматриваются для агрегации:
Атрибуты, отображаемые только в иерархиях атрибутов [в отличие от пользователя иерархии] автоматически не учитываются для Мастер проектирования агрегации. Запросы, включающие эти атрибуты, удовлетворяется путем суммирования данных из первичного ключа. Без преимущества агрегации, производительность запросов по этим атрибутам иерархии могут быть медленными. -SSAS 2008 Руководство по эффективности
Может ли кто-нибудь объяснить, как движок использует мои иерархии, в отличие от простого атрибута в кубе? (помимо эстетики группировки атрибутов вместе)
Неестественные иерархии сбивают меня с толку, в частности. В Руководстве по эффективности SSAS 2008 они показывают один пример в качестве иерархии Gender- > Education. Я думаю, что мои пользователи будут бормотать "глупых программистов" каждый раз, когда им приходилось проходить через Пол, чтобы добраться до образования.
Какое рациональное вы следите за тем, когда и когда не создавать иерархию?
