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

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

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

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

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

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

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

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

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

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

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

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

Ответ 1

Способ выполнения иерархий в медленно изменяющемся измерении в кубе 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 перед конструированием куба. Конечно, если вы хотите загружать обновления, ключи должны оставаться статическими, хотя, если у вас есть время для полного обновления, это может быть не нужно.