Разработка иерархий измерений: Естественный или Неестественный

Я использую Analysis Services и при разработке размеров, я никогда не уверен, как далеко пойти для создания естественных иерархий.

То, что я имею в виду, я добавил во всех подлинных отношениях атрибута. Таким образом, большинство иерархий является естественным так или иначе, но обычно требуемая иерархия является 3 или больше уровнями со средним уровнем как медленно изменяющийся атрибут.

Сценарий отслеживает задания. Задание имеет много атрибутов, которые являются всеми помехами, но атрибут Должника (т.е. кто оплачивает счет) может измениться в течение задания. Таким образом, иерархии похожи на это

 - Manager -> Debtor -> Job Name
 - Director -> Debtor -> Job Name 
 - Office -> Debtor -> Job Name 
 - Office -> Manager -> Debtor -> Job Name

Таким образом в размере существует много иерархий, которые запускаются со статического атрибута (атрибутов) задания, сопровождаемого должником (ведьма медленно изменяется) с именем задания (ключ измерения) внизу.

Таким образом, то, что мы делаем в данный момент для "натурализования" этих иерархий, создают "поддельные" атрибуты для каждого должника, который появляется в иерархии, которая является комбинацией атрибутов выше его. например, поскольку первый пример выше атрибута уровня Должника имел бы ключ идентификатора менеджера и Должника. И для последнего примера уровень менеджера имел бы ключ менеджера и Office, и атрибут уровня Должника будет иметь ключ Office, менеджера и Должника. Мы затем скрываем все эти атрибуты, таким образом, они только используются в иерархиях.

Таким образом, это делает наши размеры намного более сложными, но мы действительно извлекаем пользу из дополнительной производительности на наших запросах. Часто это - значимое улучшение. Кроме сложности мы постоянно поражаем проблемы, потому что у нас теперь есть несколько версий "Должника", и ключ атрибута не является идентификатором должника. Таким образом, это влияет на действия Drillthrough и Reporting, а также делающий определенные типы из вычисления, более трудного, если мы хотим изменить поведение для определенных уровней.

Клиентами, которые мы используем, является Reporting Services, Excel и веб-Компоненты Office.

Мне сказали, что на ранних версиях сложных запросов SQL 2005 года, включающих неестественные иерархии, мог привести к серверу, полностью связываемому узлы, который является другой причиной, мы пошли на многое для предотвращения неестественных иерархий.

Кроме того, дизайн восклицательного знака, предупреждающий, так поразителен в Visual Studio, что это походит на действительно плохую вещь иметь неестественный hierachies.

Что другие разработчики делают в этих ситуациях? Как далеко Вы идете для предотвращения неестественных иерархий?