Проектирование иерархий измерений: естественное или неестественное - PullRequest
Новая
       12

Проектирование иерархий измерений: естественное или неестественное

24 голосов
/ 05 февраля 2010

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

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

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

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

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

Итак, что мы делаем на данный момент, чтобы «натурализовать» эти иерархии, это создать «поддельные» атрибуты для каждого должника, который появляется в иерархии, которая представляет собой комбинацию атрибутов над ней. например в первом примере выше атрибут уровня должника будет иметь ключ идентификатора менеджера и должника. И в последнем примере уровень менеджера будет иметь ключ Manager и Office, а атрибут уровня должника будет иметь ключ Office, Manager & Debtor. Затем мы скрываем все эти атрибуты, чтобы они использовались только в иерархиях.

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

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

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

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

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

1 Ответ

2 голосов
/ 17 февраля 2010

Способ создания иерархий в медленно меняющемся измерении в кубе SSAS состоит в том, чтобы синтезировать псевдо-иерархию с фактическими ключами, скрытыми за кулисами, но просто показывая атрибуты, как если бы они были ключами. 

Office     Manager    DebtorKey  Debtor      JobKey   Job Name    From        To
Scunthorpe Bloggs     101        Scarper&Co  2001     Fixit       2010-01-01  2010-01-31
Scunthorpe Bloggs     102        Bodgett     2002     Fixit       2010-02-01  9000-01-01

Эта иерархия строится поверх исходного медленно меняющегося измерения и используется для установления отношений атрибутов. Вы хотите, чтобы уровни в иерархии имели правильные отношения атрибутов. IIRC это необходимо для того, чтобы куб выполнил оптимизацию «Autoexists» (разрешите не пустоту только из измерения до попадания в таблицу фактов) - вот почему куб работает медленно, когда эти отношения не установлены.

Возможно, вам придется применить иерархию к измерению в SQL перед построением куба. Конечно, если вы хотите загрузить обновления, ключи должны оставаться статичными, хотя, если у вас есть время, чтобы выполнить полное обновление, это может не потребоваться.

...