SSAS - Отношения атрибутов в естественной иерархии

Question

Мне сложно правильно понять лучшие сценарии использования для реализации отношений атрибутов между атрибутами измерения в SQL Server Analysis Services 2008 R2.

Из того, что я прочитал, кажется «неестественных иерархии» следует избегать, по соображениям производительности и «Природных» иерархий являются предпочтительными определяемым пользователем иерархий.

Ссылка: http://support.microsoft.com/kb/2131988

Это, как говорится, я хотел бы спросить ваши мысли по следующему сценарию:

У меня есть измерение со следующими атрибутами:

---

Размер Имя : DimReserveData
Размеры Члены:

Программа Line
Покрытие Код Тип
Покрытие
Покрытие Статус

---

Я хотел бы поместить эти атрибуты в иерархии, как показано ниже в том же порядке:

ReserveDataHierarchy
........................................
Программа Line
Покрытие Код
Покрытие Тип
Покрытие Статус
................................ ........

Иерархия информация:

Программа Line представляет собой код, представляющий программу страховой защиты, который предлагается. (например: AA-23, BB-25, CC-78 и т. д.)

Атрибут кода покрытия представляет собой числовой код, представляющий конкретную зону покрытия, предлагаемую для конкретной программной линии. (например: 123, 456 ect.)

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

Статус покрытия представляет статус данного покрытия (открыт или закрыт).

Таким образом, мы можем сказать следующее о кардинальности в иерархии:

Одна строка программы может содержать много кодов покрытия.
Один код покрытия может содержать много типов.
Один тип покрытия может содержать много значений состояния.

Таким образом, просмотр иерархии даст следующие атрибуты и члены-корреспонденты:

DimReserveData
...................... .................................................. ............................ * ..................... ............
Линия программы | Код покрытия | Тип покрытия | Статус покрытия .............................................. .................................................. ......................................
AA-12 ....... .......... 123 .................... автотранспорт ................ Открыть
BB-14 ................. 456 .................... carular ....... .......... Закрыто
CC-23 ................. 123 ................ ... автомобильный ................. Открыть
DD-23 ................. 456 ..... ............... Телевидение ...

Мой вопрос будет, если он было бы хорошей практикой моделировать эти атрибуты в пределах «Естественная» или «Неестественная» иерархия. Я бы хотел использовать иерархию «Natural», чтобы повысить производительность.

Очевидно, что для моделирования этой иерархии как «естественной» потребуется использование отношений атрибутов.

Вернемся к моей иерархической иерархии выше, будет ли возможна «естественная» иерархия, если один атрибут атрибута покрытия принадлежит нескольким линиям программы, а также несколько кодов покрытия, содержащих один и тот же тип покрытия?

В этом полезном сообщении: http://sqlserverpedia.com/blog/sql-server-bloggers/idiots-guide-to-ssas-attribute-relationships/ упоминается, что в сценарии, когда один город принадлежит к нескольким штатам или провинциям, можно изменить столбцы ключа атрибута, чтобы каждый атрибут внутри иерархии был определен однозначно.

Будет ли это работать в моем примере выше?

Я имею в виду, что я мог бы моделировать связи атрибутов, как так: (используя SSAS 2008 R2)

[суррогатного ключа Атрибут от Dimension] -> Покрытие Статус -> Покрытие Тип -> Покрытие кода - -> Программа Line

Каждый атрибут выше, будет иметь свои ключевые столбцы установить следующим образом:

.......................... ..........
Охват Статус:
...... ..............................
Покрытие Статус
Покрытие Тип

....... .............................
Тип покрытия:
............ ........................
Покрытие Тип
Покрытие Код

............. .......................
Покрытие Код:
....................................
Покрытие Код
Программа Line

....................................
Программа Line:
....................................
Линия программы

Будет ли это работать? Является ли этот сценарий более подходящим для иерархии «Неестественный»?

Я очень благодарен за ваше время, прочитав мое сообщение выше!

Спасибо!

Answer 1

Если вы ДОЛЖНЫ иметь их в иерархии, заставьте его быть естественным. Вы заплатите менее серьезное наказание за исполнение, чем просто используя неестественную иерархию. Штраф с принудительно-естественной иерархией связан прежде всего с увеличением размера ключа (так как вы будете использовать составные клавиши для натурализации иерархии).

Но, возможно, вам стоит подумать о том, чего именно вы пытаетесь достичь, заставив эти атрибуты в пользовательскую иерархию?

Следует ли упростить некоторые запросы MDX? Является ли размер слишком широким (слишком много атрибутов, непосредственно связанных с ключом) и вызывая давление памяти во время обработки?

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