Во-первых, я чувствую себя комфортно с тем, что иерархия с точки зрения концепции и как это влияет на дизайн звездной схемы DW.У меня есть некоторые измерения с большим количеством атрибутов, и я мог бы создать множество иерархий внутри SSAS.Мне бы хотелось лучше понять, как механизм OLAP использует создаваемые мной иерархии, чтобы я мог принять более обоснованное решение о том, как я проектирую свои иерархии (это сложное слово для ввода в первые несколько раз).Существуют также ограничения в SSAS в отношении атрибутов, появляющихся в нескольких иерархиях, поэтому иногда мне приходится выполнять дополнительную работу, чтобы обойти эти ограничения или решить, какая иерархия важнее.
Мне также интересно, какое негативное влияние может оказать иерархия,например, сделать измерение более запутанным для пользователей.Я мог бы скрыть атрибуты, включенные в иерархию, чтобы исключить дублирующийся атрибут и сделать измерение менее запутанным.Но затем пользователь хочет увидеть, в какие месяцы года они обычно получают больше продаж. Если я скрыл атрибут месяца, чтобы он был доступен только через иерархию Год-> Месяц, вынуждены ли они всегда включать часть иерархии Год, не позволяя им проводить такой анализ?
В нескольких статьях об иерархиях было сказано что-то вроде «предоставления пользователю возможности детализировать данные».Что вводит в заблуждение, потому что вы можете просто перетащить отдельные атрибуты года и месяца в отчет, и вы сделали это без использования иерархии.Так что такое объяснение немного поверхностно.Я чувствую, что в этом должно быть что-то большее.
Некоторые статьи, кажется, предлагают, чтобы он определял, следует ли рассматривать атрибуты для агрегирования.Это кажется противоречивым, потому что я думал, что это уже происходит, когда вы включили атрибут в куб.Я имею в виду, что весь смысл создания куба, состоящего из атрибутов, состоит в том, чтобы иметь пересечение всех атрибутов, чтобы вы могли быстро агрегировать по любой их комбинации, поэтому меня смущает, когда что-то подразумевает противоположность этому, говоря только атрибутыв иерархиях рассматриваются для агрегирования:
Атрибуты, доступные только в иерархиях атрибутов [в отличие от пользовательских иерархий], автоматически не рассматриваются для агрегирования мастером проектирования агрегации.Запросы с этими атрибутами удовлетворяются путем суммирования данных из первичного ключа.Без преимуществ агрегирования производительность запросов к этим иерархиям атрибутов может быть низкой.-SSAS 2008 Performance Guide
Может кто-нибудь объяснить, как движок использует мои иерархии в отличие от простого включения атрибута в куб?(кроме эстетики группировки атрибутов вместе)
Неестественные иерархии вводят меня в заблуждение, в частности, чертовски.В Руководстве по эффективности SSAS 2008 они показывают один пример в виде иерархии «Гендер-> Образование».Я думаю, что мои пользователи будут бормотать «глупого программиста» каждый раз, когда им нужно было углубленно изучать гендерные вопросы, чтобы получить образование.
Насколько рационально следовать, когда и когда не нужно создавать иерархию?