Общие сведения об моделировании кубов OLAP Service Manager в пакетах управления

Возможность определения настраиваемых элементов пакета управления использовалась для моделирования элементов пакета управления куба в режиме оперативной аналитической обработки (OLAP), включенных в Service Manager. Данные элементы пакета управления позволяют пользователю в декларативном режиме определять и настраивать куб OLAP на повышенном уровне абстракции. На основе определения развертывание этих элементов пакета управления создает правильные связи, компоненты и основные стандартные блоки куба OLAP на большем уровне детализации без каких-либо дополнительных пользовательских рекомендаций. В кубы OLAP входят два следующих основных элемента пакета управления:

• SystemCenterCube

• CubeExtension

SystemCenterCube

Элемент SystemCenterCube определяет куб OLAP с варьирующейся степенью детализации, которая зависит от ваших потребностей. Этот элемент состоит из следующих субэлементов:

• Группа мер

• Замена

• CustomMDX (пользовательский сценарий MDX)

• NamedCalculation (именованное вычисление)

• Измерение

• КПЭ

• Action (действие, в настоящий момент поддерживаются только действия детализации drill-through);

• ManyToManyRelationship (отношение "многие ко многим")

Группа мер

Каждый куб OLAP содержит коллекцию фактов, размещенных в киоске данных, при этом каждый член коллекции соответствует группе мер. Имя каждой группы мер должно быть уникальным в кубе OLAP. Однако один и тот же факт может соответствовать нескольким группам мер в кубе OLAP. К примеру, абстрактное отношение WorkItemAssignedToUser может быть трижды определено в кубе OLAP, используя уникальные имена групп мер ChangeRequestAssignedToUser, IncidentAssignedToUserи ProblemAssignedToUser. Вы можете настроить тот факт, чтобы только запросы на изменение, инциденты и проблемы были включены в соответствующую группу мер для куба OLAP.

Ниже приведен образец элемента пакета управления для группы мер IncidentAssignedToUser.

<MeasureGroup DateDimAlias="IncidentAssignedToUserDateDim" MeasureGroupName-"IncidentAssignedTouser" Fact="DWBase!WorkItemAssignedToUserFact"/>  

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

Атрибут	Обязательное поле	Значения	Определение
DateDimAlias	Нет	Строка	Имя измерения даты, которое используется для фильтрации данной группы мер. Если псевдоним не указан, измерение даты получает ролевое имя (MeasureGroupName)_DateDim.
Имя группы измерений	Да	Строка	Имя группы мер в кубе. Это имя должно быть уникальным в пределах куба.
Факт	Да	Факт отношений или пользовательский факт	Целевой объект группы мер, который должен являться фактом из хранилища данных.

Замена

Поскольку целевыми объектами фактов отношений в хранилище данных могут быть абстрактные отношения и измерения, вам потребуется выполнить подстановку конкретных измерений, чтобы группа мер содержала только те экземпляры, которые вы хотите просмотреть.

Это продемонстрировано в следующем примере.

<Substitution MeasureGroupName="IncidentAssignedTouser" RelationshipEndpoint="Source" Relationship="Workitem!System.WorkItemAssignedToUser" TargetDimension="DWBase!WorkItemDim" ReplacementDimension="IncidentDW!IncidentDim"/>  

В данном примере группа мер IncidentAssignedToUser указывает на отношение WorkitemAssignedToUser . Однако эта связь не только содержит инциденты, но и содержит запросы на изменение и проблемы, которые также были назначены всем пользователям. Чтобы убедиться, что эта группа мер содержит только инциденты, Service Manager заменяет WorkItemDim на IncidentDim. Это означает, что таблица, которая создается для группы мер в представлении источника данных, автоматически выполняет внутреннее соединение измерения WorkItemDim с IncidentDim, и возвращает только те экземпляры, для которых соединение проходит успешно на основании значений EntityDimKey или BaseManagedEntityId.

Помните о необходимости указать конечную точку отношения, на которой требуется выполнить подстановку. Этот элемент требуется, так как возможно, что измерения источника и конечной точки идентичны, а методология необходима для уникального определения того, какое измерение следует заменить. Примером такого отношения является WorkItemRelates to WorkItem.

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

<Substitution MeasureGroupName="IncidentAssignedToUser" RelationshipEndpoint="Target" Relationship="Workitem!System.WorkItemAssignedToUser" AliasTargetDimensionAs="AssignedToUserDim" TargetDimension="DWBase!UserDim"/>  

В данном примере псевдонимом измерения куба является AssignedToUserDim. Это имя измерения, которое будет использоваться для фактической фильтрации данного куба. Установка псевдонимов дает возможность адаптировать имена для создания в кубе нужных отношений "многие ко многим". Такой подход позволяет расширить возможности фильтрации и аналитических операций.

И наконец, подстановки можно применять не только для фактов отношений, но и для пользовательских фактов. В таком сценарии конечной точкой отношения будет значение None. В таблице ниже дается описание атрибутов подстановки.

Атрибут	Обязательное поле	Значения	Определение
ИмяГруппыИзмерений	Да	Строка	Имя группы мер, в которой следует выполнить подстановку
Точка Завершения Отношений	Да	(Target, Source, None)	Конечная точка отношения, в которой требуется выполнить подстановку. По умолчанию имеет значение None для пользовательских фактов.
Отношение	Нет	ManagementPackRelationship	Подстановочное отношение.
AliasTargetDimensionAs	Нет	Строка	Псевдоним исходного целевого измерения
ЗаменитьПсевдонимРазмерыКак	Нет	Строка	Псевдоним подстановочного измерения
DimensionAlias	Нет	ManagementPackDimension	Псевдоним измерения из пользовательского факта (при наличии)

Custom MDX (Пользовательские сценарии MDX)

Пользовательские сценарии многомерных выражений (MDX) позволяют модифицировать куб OLAP и адаптировать его под необходимые характеристики. Так как Service Manager основан на модели, невозможно определить все возможные семантические потребности при учете широкого спектра требований и точных спецификаций для бизнес-потребностей конкретного пользователя в домене. Пользовательские сценарии MDX можно применять в отношении куба OLAP для реализации определенных сценариев, необходимых пользователям для выполнения вычислений и замеров.

Именованное вычисление

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

<NamedCalculation ID="IncidentsPastTargetResolutionTime" Target="IncidentDW!IncidentDim" ColumnType="Int">  
<Calculation>(case when ( (([Status] = 'IncidentStatusEnum.Resolved' OR [Status] = 'IncidentStatusEnum.Closed') AND ResolvedDate > TargetResolutionTime) OR (([Status] != 'IncidentStatusEnum.Resolved' AND [Status] != 'IncidentStatusEnum.Closed') AND GETUTCDATE() > TargetResolutionTime)) then 1 else 0 end )</Calculation>  
</NamedCalculation>  

В данном примере измерение Incident содержит определенные данные, такие как состояние инцидента и допустимое время его разрешения. Однако нет собственной меры, которая вычисляет количество инцидентов, превышающих целевое время разрешения, хотя этот тип данных очень полезен для системного администратора. Этот сценарий можно создать с помощью именованного вычисления и агрегирования данных, чтобы пользовательская мера может нацелиться на новый атрибут, а затем представить сведения для конечного пользователя.

Помните, что Service Manager поддерживает только измерения целевого объекта NamedCalculation. Именованное вычисление не может нацеливание фактов. В таблице ниже дается описание атрибутов именованного вычисления.

Атрибут	Обязательное поле	Значения	Определение
Идентификатор	Да	Строка	Имя именованного вычисления.
Назначение	Да	ManagementPackDimension	Целевое измерение меры
Тип столбца	Да	(Целое число, Тип Double)	Тип столбца на языке SQL
Тип	Нет	(Количество, Сумма)	Тип меры

Вычисление подэлемента <> содержит в качестве значения определение именованного вычисления. Значение хранится в виде выражения MDX.

Измерение

Пользовательские меры позволяют выполнять статистические вычисления, используя числовые атрибуты измерений. Service Manager не поддерживает пользовательские меры на основе фактов. Продолжая приведенный выше пример именованного вычисления, Service Manager определяет настраиваемую меру для IncidentsPastTargetResolutionTime следующим образом:

<Measure ID="IncidentsPastTargetResolutionTimeCount" Target="IncidentDW!IncidentDim" Type="Sum" Property="IncidentsPastTargetResolutionTime"/>  

В приведенном XML-коде в качестве целевого измерения меры указывается IncidentDimension, целевым же свойством является IncidentsPastTargetResolutionTime. Это пользовательское свойство, определенное ранее. Пользовательские меры могут ссылаться как на собственные, так и на вычисляемые свойства измерения.

И наконец, тип измерения указывается как Sum ("Сумма"). Тип измерения может указываться как Sum или Count. Из-за соображений производительности типы мер", отличных от Service Manager, не допускаются. В таблице ниже дается описание атрибутов меры.

Атрибут	Обязательное поле	Значения	Определение
Идентификатор	Да	Строка	Наименование меры
Назначение	Да	ManagementPackDimension	Целевое измерение меры
Свойство	Да	Строка	Свойство целевого измерения
Тип	Нет	(Количество, Сумма)	Тип меры

ManyToManyRelationship (отношение "многие ко многим")

Элемент ManyToManyRelationship позволяет дизайнеру добавлять в куб OLAP пользовательские измерения типа "многие ко многим", тем самым расширяя диапазон аналитических сценариев. Описание отношений "многие ко многим" выходит за рамки данного документа. Тем не менее можно изучить данную концепцию и ее преимущества. Дополнительные сведения о ManyToManyRelationship см. в статье "Революция "многие ко многим" 2.0.

Во время развертывания куба Service Manager автоматически добавляет измерения "многие ко многим" в куб для всех связей one-hop без какого-либо взаимодействия с вами. Однако Service Manager не добавляет измерения "многие ко многим" для каскадных связей (с несколькими прыжками) из-за экспоненциального увеличения возможных связей, которые можно добавить. Добавление таких отношений в полном объеме может привести к значительному снижению производительности при просмотре куба OLAP. Это обусловлено тем, что агрегаты отношений "многие ко многим", как правило, не вычисляются при обработке, а также необходимостью вычисления соединений при просмотре куба OLAP. Если вам необходимо специальное каскадное отношение типа "многие ко многим", его можно создать, используя элемент пакета управления, после чего оно будет добавлено в куб OLAP. В экземплярах, где имеется несколько промежуточных групп, вы можете пойти другим путем — измените автоматически созданное отношение "многие ко многим", указав другую промежуточную группу мер. В этом случае Service Manager автоматически использует первую группу, которая обнаружена. Ниже приведен образец элемента пакета управления для определения отношения "многие ко многим".

<ManyToManyRelationship CubeDimension="ServiceDim" TargetMeasureGroup="AlertAboutConfigItem" IntermediateMeasureGroup="ServiceContainsConfigItem" />  

В следующей таблице описаны атрибуты связи "многие ко многим".

Атрибут	Обязательное поле	Значения	Определение
CubeDimension	Да	Строка	Имя измерения "многие ко многим" в кубе
TargetMeasureGroup	Да	Строка	Целевая группа мер для создания отношения "многие ко многим"
IntermediateMeasureGroup	Да	Строка	Промежуточная группа мер для создания отношения "многие ко многим"

КПЭ

Компании и организации могут использовать показатели KPI, чтобы быстро оценить работоспособность предприятия путем измерения его продвижения в сторону заранее установленной цели. Каждый показатель KPI имеет целевое и фактическое значение. Целевое значение — это количественная цель, достижение которой важно для успеха организации. Крупные объемы данных отфильтровываются в одно дискретное значение, которое можно использовать для наблюдения за производительностью предприятия и оценки его продвижения в сторону важных целей и вех. Примеры показателей KPI — ВУЗ, поставивший целью успешно выпустить 90 % всех своих учащихся в течение пяти лет или баскетбольная команда, цель которой — не дать команде противника сделать более 50 % бросков за всю игру. Для отображения группы показателей KPI можно использовать систему показателей, позволяющую представить общую работоспособность компании в виде моментального снимка. Ниже приведен образец показателя KPI.

<KPI ID="IncidentResolutiuonKpi" >  
<Caption> The ratio of incidents resolved </Caption>  
<Value>IIF(([Measures].[IncidentDimCount])> 0,([Measures].[IncidentsResolvedCount]/[Measures].[IncidentDimCount]),null)</Value>   
<Goal>1.0</Goal>   
<GreenThreshold> 0.75</GreenThreshold>  
<YellowThreshold>0.5 </YellowThreshold>  
<Direction>Up</Direction>  
<StatusGraphic>Thermometer</StatusGraphic>   
</KPI>  

В таблице ниже дается описание атрибутов показателя KPI.

Атрибут	Обязательное поле	Значения	Определение
Идентификатор	Да	Строка	Наименование показателя KPI
Заголовок	Да	Строка	Описание показателя KPI
Значение	Да	Строка	Сценарий MDX, определяющий числовое значение показателя KPI
Цель	Да	Строка	Целевое значение ключевого показателя эффективности
Green Threshold (зеленый порог)	Да	Строка (от 0,1 до 1)	Любое число, указанное выше или ниже этого порогового значения, в зависимости от направления, помечается как зеленое в символе состояния.
Желтый порог	Да	Строка (от 0,1 до 1)	Любое число, указанное выше или ниже порогового значения, в зависимости от направления, но не соответствует зеленому порогу, помечается как желтый в символе состояния. Число, которое не соответствует желтому порогу, помечается красным в символе состояния.
Направление	Да	(Вверх, вниз)	Если направление вверх, все числа над зеленым или желтым порогом помечаются соответствующим символом. Со значением Down ("вниз") соответствующим символом будут отмечены все числа, находящиеся ниже зеленого или желтого порога.
Рисунок состояния	Да	(Фигуры, дорожное освещение, дорожные знаки, датчик, обратныйgauge, термометр, цилиндр, лица, дисперсииArrow)	Символ, представляющий ключевой показатель эффективности.

Действие

Действия — это события, которые можно активировать в кубе OLAP при доступе к данным в кубе. Только действия детализации поддерживаются Service Manager. Пример действия приведен ниже.

<Action ID="DrillThroughOnWICreatedByUser" MeasureGroupName="CreatedByUser" ActionType="DrillThrough">   
<DrillThroughColumns CubeDimension="WorkItemCreatedByUser_UserDim">   
<Property PropertyName="FirstName" />   
<Property PropertyName="LastName" />   
<Property PropertyName="Company" />   
<Property PropertyName="Department" />   
<Property PropertyName="Office" />   
</DrillThroughColumns>   
</Action>  

В таблице ниже дается описание атрибутов действия.

Атрибут	Обязательное поле	Значения	Определение
Идентификатор	Да	Строка	Наименование действия детализации drill-through
ИмяГруппыИзмерений	Да	Строка	Целевая для действия группа мер
Тип действия	Да	(Детализация)	Тип действия Только действия детализации поддерживаются Service Manager.
CubeDimension	Да	Строка	Измерение куба, являющееся целью действия, которое должно быть срезом в группе мер.
ИмяСвойства	Да	Строка	Атрибут измерения, отображаемый при выполнении действия детализации drill-through

CubeExtension

Основное предназначение элемента CubeExtension — позволить вносить изменения в куб OLAP после развертывания его в службах SSAS без необходимости удаления и повторной установки куба. Если куб OLAP содержит многолетние данные, воссоздание куба может занять длительное время, так как потребуется полная обработка всех разделов куба.

Элемент CubeExtension может определять следующие элементы:

• NamedCalculation (именованное вычисление)

• ManyToManyRelationship (отношение "многие ко многим")

• КПЭ

• Измерение

• Действие

• CustomMDX (пользовательский сценарий MDX)

Любую настройку, выполненную в элементе CubeExtension, также можно определить в объекте SystemCenterCube. Единственная настройка, которая не разрешена, — добавление фактов или групп мер и подстановок в куб.

Следующие шаги

• При необходимости устранять неполадки кубов OLAP.