Vue d’ensemble des cubes OLAP de Modeling Service Manager dans les packs d’administration
La possibilité de définir des éléments de pack d’administration personnalisés a été utilisée pour modéliser les éléments du pack d’administration de cube OLAP (Online Analytical Processing) inclus dans Service Manager. Ces éléments de pack d'administration permettent à l'utilisateur de définir et de personnaliser de manière déclarative un cube OLAP à un niveau d'abstraction plus élevé. En fonction de la définition, le déploiement de ces éléments de pack d’administration crée les relations, composants et blocs de construction fondamentaux du cube OLAP à un niveau de détail plus élevé, sans aucune aide supplémentaire de l’utilisateur. Les deux principaux éléments de pack d'administration inclus dans les cubes OLAP sont les suivants :
SystemCenterCube
CubeExtension
SystemCenterCube
L'élément SystemCenterCube définit le cube OLAP à divers degrés de détail, en fonction de vos besoins. Cet élément contient les sous-éléments suivants :
MeasureGroup
Substitution
CustomMDX
NamedCalculation
Mesure
Indicateur de performance clé
Action (seules les actions d'extraction sont actuellement prises en charge)
ManyToManyRelationship
MeasureGroup
Chaque cube OLAP contient une collection de faits existant dans le mini-Data Warehouse, où chaque membre de la collection correspond à un groupe de mesures. Chaque groupe de mesures doit avoir un nom unique dans le cube OLAP. Toutefois, un même fait peut correspondre à plusieurs groupes de mesures dans un cube OLAP. Par exemple, la relation abstraite WorkItemAssignedToUser peut être définie trois fois dans un cube OLAP, à l'aide des noms de groupes de mesures uniques ChangeRequestAssignedToUser, IncidentAssignedToUseret ProblemAssignedToUser. Vous pouvez personnaliser le fait afin que seules les demandes de modification, les incidents et les problèmes soient inclus dans le groupe de mesures respectif pour le cube OLAP.
L'exemple suivant montre l'élément de pack d'administration du groupe de mesures IncidentAssignedToUser :
<MeasureGroup DateDimAlias="IncidentAssignedToUserDateDim" MeasureGroupName-"IncidentAssignedTouser" Fact="DWBase!WorkItemAssignedToUserFact"/>
Lorsque le cube OLAP est déployé, la dimension, les sous-dimensions et les relations de clés étrangères sont automatiquement calculées, et la vue de source de données est mise à jour avec ces nouveaux éléments. Le tableau suivant décrit les attributs des groupes de mesures.
| Attribut | Requis | Valeurs | Définition |
|---|---|---|---|
| DateDimAlias | Non | Chaîne | Nom de la dimension de date qui filtre les données selon ce groupe de mesures. Si aucun alias n'est défini, le nom « (MeasureGroupName)_DateDim » sera automatiquement attribué à la dimension de date de rôle actif. |
| MeasureGroupName | Oui | Chaîne | Nom du groupe de mesures du cube. Ce nom doit être unique au sein du cube. |
| Fact | Oui | Relationship ou CustomFact | Cible du groupe de mesures, qui doit correspondre à un fait de l'entrepôt de données. |
Substitution
Les faits de relation de l'entrepôt de données peuvent cibler des relations et des dimensions abstraites. Par conséquent, vous devez substituer les dimensions concrètes, afin que le groupe de mesures ne contienne que les instances que vous souhaitez parcourir.
L'exemple suivant illustre ce concept.
<Substitution MeasureGroupName="IncidentAssignedTouser" RelationshipEndpoint="Source" Relationship="Workitem!System.WorkItemAssignedToUser" TargetDimension="DWBase!WorkItemDim" ReplacementDimension="IncidentDW!IncidentDim"/>
Dans cet exemple, le groupe de mesures IncidentAssignedToUser pointe vers la relation WorkitemAssignedToUser . Toutefois, cette relation ne contiendra pas seulement des incidents, mais elle contiendra également des demandes de modification et des problèmes qui ont également été affectés à tous les utilisateurs. Pour vous assurer que ce groupe de mesures contient uniquement des incidents, Service Manager remplace WorkItemDim par IncidentDim. Ainsi, la table créée dans la vue de source de données pour le groupe de mesures effectuera automatiquement une jointure interne sur WorkItemDim à l'aide d'IncidentDim, puis renverra uniquement les instances contenant une jointure valide en fonction d'EntityDimKey ou de BaseManagedEntityId.
N'oubliez pas que vous devez définir le point de terminaison de la relation dans laquelle effectuer la substitution. Cet élément est requis, car il est possible que les dimensions source et de point de terminaison soient identiques et qu’une méthodologie soit nécessaire pour identifier de manière unique la dimension à remplacer. WorkItemRelates to WorkItemest un exemple d'une telle relation.
L'élément de substitution est également utilisé pour définir les dimensions d'alias du cube. En d’autres termes, vous pouvez définir un nom d’alias pour une dimension, mais il n’est pas nécessaire de remplacer réellement une dimension. En effet, la substitution dans ce cas n’est pas sur la dimension, mais sur la dimension de cube ou le nom de dimension d’alias, comme illustré dans l’exemple suivant :
<Substitution MeasureGroupName="IncidentAssignedToUser" RelationshipEndpoint="Target" Relationship="Workitem!System.WorkItemAssignedToUser" AliasTargetDimensionAs="AssignedToUserDim" TargetDimension="DWBase!UserDim"/>
Dans cet exemple, l'alias de la dimension de cube est AssignedToUserDim. C'est le nom de la dimension qui sera utilisé pour filtrer les données d'après ce cube. Grâce à la définition des noms d'alias, les noms peuvent être adaptés de façon à permettre les relations plusieurs-à-plusieurs de votre choix au sein du cube. Cela permet ainsi des capacités de filtrage et d'analyse plus avancées.
Enfin, les substitutions sont valides non seulement pour les faits de relation, mais également pour les faits personnalisés. Dans ce scénario, le point de terminaison de relation serait défini sur None. Le tableau suivant décrit les attributs de substitution.
| Attribut | Requis | Valeurs | Définition |
|---|---|---|---|
| MeasureGroupName | Oui | Chaîne | Nom du groupe de mesures pour lequel effectuer la substitution |
| RelationshipEndPoint | Oui | (Target, Source, None) | Point de terminaison de la relation devant effectuer la substitution. Par défaut, la valeur est None pour les faits personnalisés. |
| Relationship | Non | ManagementPackRelationship | Relation à utiliser pour la substitution. |
| AliasTargetDimensionAs | Non | Chaîne | Nom d'alias de la dimension ciblée d'origine |
| AliasReplacementDimensionsAs | Non | Chaîne | Nom d'alias pour la dimension substituée |
| DimensionAlias | Non | ManagementPackDimension | Alias de dimension d'un fait personnalisé (s'il en existe un) |
Expressions multidimensionnelles (MDX) personnalisées
Vous pouvez utiliser des scripts personnalisés d'expression multidimensionnelle (MDX) pour modifier et adapter un cube OLAP à vos besoins. Étant donné que Service Manager est basé sur un modèle, il est impossible de déterminer tous vos besoins sémantiques possibles lors de la prise en compte du large spectre des exigences et des spécifications exactes pour les besoins métier spécifiques au domaine d’un utilisateur particulier. Les expressions multidimensionnelles (MDX) personnalisées permettent de définir des scripts MDX qui seront appliqués au cube OLAP, afin de permettre certains scénarios nécessaires aux mesures et à l'instrumentation.
Calcul nommé
Vous pouvez utiliser des calculs nommés pour définir de nouveaux attributs dans une dimension qu'une mesure personnalisée pourra cibler ultérieurement. Cela permet d'étendre le schéma dimensionnel et de le personnaliser selon vos besoins. L'exemple suivant provient de 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>
Dans cet exemple, la dimension Incident contient des données, telles que l'état de l'incident et le délai de résolution cible. Toutefois, il n’existe aucune mesure native qui calcule le nombre d’incidents qui ont dépassé le temps de résolution cible, bien que ce type de données soit très utile pour un administrateur de systèmes. Vous pouvez créer ce scénario à l’aide d’un calcul nommé et agréger les données afin qu’une mesure personnalisée puisse cibler le nouvel attribut, puis présenter les informations à un utilisateur final.
N’oubliez pas que Service Manager prend uniquement en charge les dimensions de ciblage NamedCalculation. NamedCalculation ne peut pas cibler les faits. Le tableau suivant décrit les attributs de calcul nommé.
| Attribut | Requis | Valeurs | Définition |
|---|---|---|---|
| id | Oui | Chaîne | Nom du calcul nommé. |
| Cible | Oui | ManagementPackDimension | Dimension cible de la mesure |
| ColumnType | Oui | (Int, Double) | Type SQL de la colonne |
| Type | Non | (Count, Sum) | Type de la mesure |
Le calcul de sous-élément <> contient, comme valeur, la définition du calcul nommé. La valeur est stockée sous la forme d'une expression MDX.
Mesure
Vous pouvez utiliser des mesures personnalisées pour agréger et afficher des données en fonction d'attributs numériques de dimensions. Service Manager ne prend pas en charge les mesures personnalisées en fonction des faits. En suivant l’exemple de calcul nommé ci-dessus, Service Manager définit une mesure personnalisée sur IncidentsPastTargetResolutionTime comme suit :
<Measure ID="IncidentsPastTargetResolutionTimeCount" Target="IncidentDW!IncidentDim" Type="Sum" Property="IncidentsPastTargetResolutionTime"/>
Dans ce code XML, la cible de la mesure est IncidentDimension, et la propriété spécifique est IncidentsPastTargetResolutionTime. Il s'agit de la propriété personnalisée qui a été définie précédemment. Les mesures personnalisées peuvent cibler les propriétés natives ou calculées de la dimension.
Enfin, le type de mesure est défini comme une somme. Les valeurs possibles d'un type de mesure sont Sum et Count. En raison des considérations relatives aux performances, les types de mesures Service Manager Distinct Count ne sont pas autorisés. Le tableau suivant décrit les attributs de mesure.
| Attribut | Requis | Valeurs | Définition |
|---|---|---|---|
| id | Oui | Chaîne | Nom de la mesure |
| Cible | Oui | ManagementPackDimension | Dimension cible de la mesure |
| Propriété | Oui | Chaîne | Propriété de la dimension cible |
| Type | Non | (Count, Sum) | Type de la mesure |
ManyToManyRelationship
ManyToManyRelationship permet aux concepteurs des cubes d'ajouter des dimensions plusieurs-à-plusieurs personnalisées aux cubes OLAP, afin de permettre des scénarios d'analyse avancés. La définition des relations plusieurs-à-plusieurs n'entre pas dans le cadre de ce document. Toutefois, vous pouvez examiner ce concept et ses avantages. Pour plus d’informations sur le ManyToManyRelationship, consultez The Many-to-Many Revolution 2.0.
Pendant le déploiement du cube, Service Manager ajoute automatiquement des dimensions plusieurs-à-plusieurs au cube pour toutes les relations « un tronçon », sans aucune interaction de votre part. Toutefois, Service Manager n’ajoute pas de dimensions plusieurs-à-plusieurs pour les relations en cascade (multi-tronçon) en raison de l’augmentation exponentielle des relations possibles qui peuvent être ajoutées. L'ajout de toutes ces relations peut fortement dégrader les performances lors de l'exploration du cube OLAP. Cela est dû au fait que les agrégations de relations plusieurs-à-plusieurs ne sont pas calculées au cours du traitement, ainsi qu'au fait que les jointures sont évaluées pendant l'exploration du cube OLAP. Pour obtenir une relation plusieurs-à-plusieurs en cascade spécifique, vous pouvez définir la relation à l'aide d'un élément de pack d'administration pour qu'elle soit ajoutée au cube OLAP. À l'inverse, vous pouvez remplacer une relation plusieurs-à-plusieurs générée automatiquement, afin d'utiliser un autre groupe de mesures intermédiaire dans les instances contenant plusieurs groupes intermédiaires. Dans ce cas, Service Manager utilise automatiquement le premier groupe rencontré. Voici un exemple d'élément de relation de pack d'administration plusieurs-à-plusieurs :
<ManyToManyRelationship CubeDimension="ServiceDim" TargetMeasureGroup="AlertAboutConfigItem" IntermediateMeasureGroup="ServiceContainsConfigItem" />
Le tableau suivant décrit les attributs de relation plusieurs-à-plusieurs.
| Attribut | Requis | Valeurs | Définition |
|---|---|---|---|
| CubeDimension | Oui | Chaîne | Nom de la dimension de cube plusieurs-à-plusieurs |
| TargetMeasureGroup | Oui | Chaîne | Groupe de mesures cible devant créer la relation plusieurs-à-plusieurs |
| IntermediateMeasureGroup | Oui | Chaîne | Groupe de mesures intermédiaire devant créer la relation plusieurs-à-plusieurs |
Indicateur de performance clé
Les organisations et les sociétés peuvent utiliser des indicateurs de performance clés (KPI) pour estimer rapidement l'état de santé d'une entreprise en mesurant les progrès réalisés dans le cadre des objectifs prédéfinis. Chaque indicateur de performance clé possède une valeur cible et une valeur réelle. La valeur cible est un objectif quantitatif qui est essentiel à la réussite de l'organisation. De grandes quantités de données sont filtrées pour obtenir une valeur discrète qui peut être utilisée pour surveiller les performances et les progrès réalisés dans le cadre des objectifs définis et des tests d'évaluation. Comme exemples de KPI, imaginons une université dont l'objectif est d'obtenir des étudiants 90 % de réussite sur quatre ans, ou une équipe de basket dont l'objectif est de diminuer de 50 % les chances de l'équipe adverse de lancer un panier au cours d'un match. Vous pouvez utiliser un tableau de bord pour afficher un groupe d'indicateurs de performance clés, et obtenir ainsi un aperçu instantané de la santé globale d'une entreprise. Voici un exemple d'indicateur de performance clé :
<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>
Le tableau suivant décrit les attributs d'indicateur de performance clé.
| Attribut | Requis | Valeurs | Définition |
|---|---|---|---|
| id | Oui | Chaîne | Nom de l'indicateur de performance clé |
| Caption | Oui | Chaîne | Description de l'indicateur de performance clé |
| Valeur | Oui | Chaîne | Script MDX définissant la valeur numérique de l'indicateur de performance clé |
| Objectif | Oui | Chaîne | Valeur cible de l’indicateur de performance clé |
| Green Threshold | Oui | String (entre 0,1 et 1) | Tout nombre supérieur ou inférieur à ce seuil, selon la direction, est marqué comme vert dans le symbole d’état. |
| Seuil jaune | Oui | String (entre 0,1 et 1) | Tout nombre supérieur ou inférieur au seuil, selon la direction, mais ne respecte pas le seuil vert est marqué comme jaune dans le symbole d’état. Un nombre qui ne répond pas au seuil jaune est marqué comme rouge dans le symbole d’état. |
| Sens | Oui | (Haut, Bas) | Si la direction est vers le haut, les nombres au-dessus du seuil vert ou jaune sont marqués avec le symbole correspondant. De même, si elle a la valeur « Down », les nombres inférieurs au seuil vert ou jaune sont représentés par le symbole correspondant. |
| Graphique d’état | Oui | (Shapes, TrafficLight, RoadSigns, Gauge, ReversedGauge, Thermomètre, Cylindre, Faces, VarianceArrow) | Symbole qui représente l’indicateur de performance clé. |
Action
Les actions sont des événements que vous pouvez déclencher sur un cube OLAP lorsque vous accédez aux données dans le cube. Seules les actions d’extraction sont prises en charge par Service Manager. Voici un exemple d'action :
<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>
Le tableau suivant décrit les attributs d'action.
| Attribut | Requis | Valeurs | Définition |
|---|---|---|---|
| id | Oui | Chaîne | Nom de l'action d'extraction |
| MeasureGroupName | Oui | Chaîne | Groupe de mesures ciblé de l'action |
| ActionType | Oui | (DrillThrough) | Type d'action. Seules les actions d’extraction sont prises en charge par Service Manager. |
| CubeDimension | Oui | Chaîne | Dimension de cube qui est la cible de l’action, qui doit être un segment sur le groupe de mesures |
| PropertyName | Oui | Chaîne | Attribut de la dimension qui s'affiche lors de l'exécution de l'action d'extraction |
CubeExtension
Le principal objectif de l'élément CubeExtension est de permettre de modifier le cube OLAP après son déploiement sur SSAS, sans avoir à le désinstaller, puis à le réinstaller. Lorsqu'un cube OLAP contenant l'équivalent d'années de données a fait l'objet d'un traitement complet, le processus de recréation du cube sera très long, car toutes les partitions devront être entièrement retraitées.
L'élément CubeExtension peut définir les éléments suivants :
NamedCalculation
ManyToManyRelationship
Indicateur de performance clé
Mesure
Action
CustomMDX
Chaque personnalisation définie dans un élément CubeExtension peut également être définie dans un objet SystemCenterCube. La seule personnalisation qui n’est pas autorisée est l’ajout de faits ou de groupes de mesures et de substitutions au cube.
Étapes suivantes
- Si nécessaire, résolvez les problèmes liés aux cubes OLAP.