Acerca del modelado de cubos OLAP en módulos de administración

Publicado: julio de 2016

Se aplica a: System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager

La capacidad para definir elementos personalizados del módulo de administración se utilizaba para modelar los elementos del módulo de administración de cubos de procesamiento analítico en línea (OLAP) que se incluyen en System Center 2012 – Service Manager. Estos elementos del módulo de administración permiten al usuario definir y personalizar un cubo OLAP en un nivel superior de abstracción de forma declarativa. De acuerdo con la definición, mediante la implementación de estos elementos del módulo de administración se crean las relaciones, los componentes y los bloques de creación fundamentales adecuados para el cubo OLAP con un mayor nivel de detalle, sin instrucciones adicionales del usuario. Los dos elementos principales del módulo de administración que se incluyen en los cubos OLAP son los siguientes:

• SystemCenterCube

• CubeExtension

El elemento SystemCenterCube define el cubo OLAP hasta un cierto grado de detalle, en función de las necesidades específicas. Este elemento contiene los siguientes subelementos:

• MeasureGroup

• Substitution

• CustomMDX

• NamedCalculation

• Medida

• KPI

• Action (sin embargo, actualmente solo se admiten las acciones de obtención de detalles)

• ManyToManyRelationship

MeasureGroup

Cada cubo OLAP contiene una colección de hechos que existen en el data mart, donde cada miembro de la colección corresponde a un grupo de medida. Cada grupo de medida debe tener su propio nombre único dentro del cubo OLAP. Sin embargo, un solo hecho puede corresponder a varios grupos de medida de un cubo OLAP. Por ejemplo, la relación abstracta WorkItemAssignedToUser puede estar definida tres veces en un cubo OLAP, con los nombres del grupo de medida únicos de ChangeRequestAssignedToUser, IncidentAssignedToUser y ProblemAssignedToUser. Tal y como se describe en la sección Substitution, puede personalizar el hecho para que las solicitudes de cambio, los incidentes y los problemas solo se incluyan en el grupo de medida respectivo del cubo OLAP.

En el ejemplo siguiente se muestra el elemento del módulo de administración para el grupo de medida IncidentAssignedToUser:

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

Cuando se implementa el cubo OLAP, las relaciones de dimensión, de subdimensiones y de clave externa se calculan automáticamente, y la vista de origen de datos se actualiza con estos nuevos elementos. La tabla siguiente describe los atributos del grupo de medida.

Dado que los hechos de relación en el almacenamiento de datos pueden tener como destino relaciones y dimensiones abstractas, es necesario sustituirlos por dimensiones concretas para que el grupo de medida solo contenga instancias que desea examinar.

Esto se ilustra en el ejemplo siguiente.

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

En este ejemplo, el grupo de medida IncidentAssignedToUser tiene como destino la relación WorkitemAssignedToUser. Sin embargo, esta relación no sólo contendrá incidentes, sino también las solicitudes de cambio y los problemas que también se han asignado a los usuarios. Para garantizar que este grupo de medida solo contiene incidentes, Service Manager sustituye WorkItemDim por IncidentDim. Esto significa que la tabla que se ha creado en la vista de origen de datos para el grupo de medida realiza automáticamente una combinación interna de WorkItemDim con IncidentDim y devuelve únicamente las instancias con combinación válida, de acuerdo con EntityDimKey o BaseManagedEntityId.

Recuerde que debe definir el extremo de la relación en la que desee realizar la sustitución. Este elemento es necesario, ya que las dimensiones de origen y de extremo podrían ser idénticas y se requiere una metodología para identificar de forma única la dimensión que se debe sustituir. Un ejemplo de este tipo de relación es WorkItemRelates to WorkItem.

El elemento de sustitución también se utiliza para definir las dimensiones de alias para el cubo. En otras palabras, puede definir un nombre de alias para una dimensión, pero no es necesario sustituir una dimensión. De hecho, la sustitución en este caso no se realiza en la dimensión, sino en el nombre de la dimensión del cubo o en el nombre de la dimensión del alias, como se muestra en el ejemplo siguiente:

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

En este ejemplo, el nombre de la dimensión del cubo de alias es AssignedToUserDim. Éste es el nombre de la dimensión que se utilizará para filtrar realmente en este cubo. Si se permite a los usuarios definir los nombres de alias, los nombres se pueden personalizar específicamente para habilitar las relaciones de varios a varios que se desean en el cubo. Esto permite que tanto el filtrado como las capacidades analíticas más avanzados sean posibles.

Por último, las sustituciones no solo son válidas para los hechos de relación, sino también para los hechos personalizados. En este escenario, el extremo de la relación se establecería en None. En la tabla siguiente se describen los atributos de sustitución.

Puede utilizar scripts de expresión multidimensional (MDX) personalizados para modificar y adaptar el cubo OLAP a las especificaciones exactas de sus necesidades. Dado que Service Manager se basa en modelos, es imposible determinar todas sus posibles necesidades semánticas a la hora de tener en cuenta el amplio espectro de requisitos y especificaciones exactas para las necesidades empresariales de dominio específico de un usuario concreto. El recurso MDX personalizado posibilita la definición de los scripts MDX que se aplicarán al cubo OLAP para habilitar escenarios específicos que los usuarios necesitan para medir e instrumentar.

Puede utilizar cálculos con nombre para definir nuevos atributos en una dimensión que una medida personalizada tendrá como destino más adelante. Esto permite ampliar el esquema dimensional y personalizarlo según sus necesidades específicas. El ejemplo siguiente se ha extraído 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>  

En este ejemplo, la dimensión del incidente contiene datos, como el estado del incidente y el tiempo de resolución planeado. Sin embargo, no existe ninguna medida nativa para calcular el número de incidentes que exceden el tiempo de resolución planeado, si bien este tipo de datos es muy útil para un administrador de sistemas. Puede crear este escenario mediante un cálculo con nombre y agregar los datos, de modo que una medida personalizada pueda tener como destino el nuevo atributo, y después presentar la información a un usuario final.

Recuerde que Service Manager solo admite dimensiones de destino NamedCalculation. NamedCalculation no puede tener hechos como destino. En la tabla siguiente se describen los atributos de cálculo con nombre.

El subelemento <Calculation> contiene como valor la definición del cálculo con nombre. El valor se almacena como una expresión MDX.

Puede usar medidas personalizadas para agregar y visualizar datos en función de los atributos numéricos de las dimensiones.Service Manager no admite medidas personalizadas basadas en hechos. Siguiendo con el ejemplo del cálculo con nombre anterior, Service Manager define una medida personalizada en IncidentsPastTargetResolutionTime de la forma siguiente:

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

Al revisar este código XML, vemos que el destino de la medida es IncidentDimension y la propiedad específica es IncidentsPastTargetResolutionTime. Se trata de la propiedad personalizada que se definió anteriormente. Las medidas personalizadas pueden tener como destino propiedades nativas o calculadas en la dimensión.

Por último, el tipo de medida se define como una suma. Los valores posibles para un tipo de medida incluyen Sum y Count. Por motivos de rendimiento, no se permiten los tipos de medidas de recuento distintivas de Service Manager. En la tabla siguiente se describen los atributos de las medidas.

ManyToManyRelationship permite al diseñador de cubos agregar a los cubos OLAP dimensiones de varios a varios personalizadas, con el fin de habilitar escenarios analíticos avanzados. La definición de las relaciones de varios a varios queda fuera del alcance de este documento. Sin embargo, puede investigar este concepto y sus ventajas.Para obtener más información sobre ManyToManyRelationship, consulte La revolución 2.0 de la relación de varios a varios.

Durante la implementación del cubo, Service Manager agrega al cubo dimensiones de varios a varios de forma automática para todas las relaciones de "un salto", sin ninguna interacción por parte del usuario. Sin embargo, Service Manager no agrega dimensiones de varios a varios para las relaciones en cascada (multisalto), debido al aumento exponencial de relaciones posibles que se podrían agregar. Si se agregan todas estas relaciones, se podría degradar significativamente el rendimiento a la hora de examinar el cubo OLAP. Esto se debe a que, generalmente, las agregaciones de relaciones de varios a varios no se calculan durante el procesamiento y a que las uniones se evalúan mientras se explora el cubo OLAP. Si desea una relación específica de varios a varios en cascada, puede definir la relación mediante un elemento del módulo de administración, el cual se agregará al cubo OLAP. Por el contrario, puede sobrescribir una relación de varios a varios generada automáticamente para utilizar un grupo de medida intermedio diferente, en los casos en que existan varios grupos intermedios. En este caso, Service Manager utiliza automáticamente el primer grupo que se encuentra. El siguiente es un ejemplo de un elemento de relación de varios a varios del módulo de administración:

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

La tabla siguiente describe los atributos de las relaciones de varios a varios.

Las organizaciones y las empresas pueden utilizar indicadores clave de rendimiento (KPI) para calcular rápidamente el estado de la empresa mediante la medición de su progreso hacia un objetivo predefinido. Cada KPI tiene un valor del objetivo y un valor real. El valor del objetivo es un objetivo cuantitativo que es crítico para el éxito de la organización. Se filtran grandes cantidades de datos en un valor discreto, que se puede utilizar para supervisar el rendimiento y el progreso hacia los objetivos y los criterios de referencia. Entre algunos ejemplos de KPI encontramos una universidad con un objetivo de aprobados en cuatro años del 90% de sus alumnos o un equipo de baloncesto con el objetivo de lograr que el equipo rival enceste menos del 50 por ciento de los tiros en un partido. Puede utilizar un cuadro de mandos para mostrar un grupo de KPI, que proporcione en una instantánea el estado general de la empresa. El siguiente es un ejemplo de 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>  

En la tabla siguiente se describen los atributos de KPI.

Las acciones son eventos que puede desencadenar en un cubo OLAP cuando tiene acceso a los datos del mismo.Service Manager solo admite acciones de obtención de detalles. El siguiente es un ejemplo de una acción:

<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>  

En la tabla siguiente se describen los atributos de las acciones.

El objetivo principal del elemento CubeExtension es permitir la modificación del cubo OLAP una vez implementado en SSAS, sin necesidad de desinstalar y reinstalar el cubo. Si el cubo OLAP se ha procesado completamente con años de datos, volver a crearlo resulta lento, ya que todas las particiones se tienen que procesar completamente.

El elemento CubeExtension puede definir los siguientes elementos:

• NamedCalculation

• ManyToManyRelationship

• KPI

• Medida

• Acción

• CustomMdx

Cada personalización que se define en un elemento CubeExtension también se puede definir en un objeto SystemCenterCube. La única personalización que no está permitida es la adición de hechos o grupos de medida y las sustituciones al cubo.

Información sobre los cubos OLAP