Recientemente nos hemos visto involucrados en un proyecto SSAS Multidimensional en el que existía una dimensión de cuentas padre-hijo bastante compleja y con un operador unario por en medio. Es por esto que nos hemos decidido a describir brevemente la implementación por defecto de SSAS y la que utilizamos finalmente para mejorar el rendimiento.

  • Implementación nativa padre-hijo + operador unario de SSAS: Esta es posiblemente la manera más rápida y sencilla de implementar la jerarquía de cuentas. Por contra, a poco que nuestro proyecto sea algo complejo su rendimiento puede caer drásticamente.

Para usarla solo necesitamos que el origen de la dimensión tenga una relación padre-hijo y por supuesto el operador unario.

  • Jerarquía aplanada + Operador unario: En lugar de definir en SSAS una jerarquía padre – hijo, si previamente aplanamos la jerarquía podemos definirla como una jerarquía “normal” (de la misma forma que una jerarquía de año, mes y día). Podemos seguir usando el operador unario nativo que ofrece SSAS, pero no es lo más eficiente.
  • Jerarquía aplanada + “Factor”: Si el rendimiento de la implementación nativa de la jerarquía padre-hijo + operador unario se nos antoja insuficiente podemos quitarle el trabajo que se le atraganta a SSAS. Sin embargo, la siguiente aproximación tiene un problema, perdemos el control sobre las cuentas que tienen el operador unario “~” y que no deben agregar hacia arriba. Si tenemos este tipo de cuentas deberemos crear distintas jerarquías o tratarlas de alguna manera con MDX.

Para esta aproximación usaremos la jerarquía aplanada y una tabla de hechos donde definimos el operador unario como 1 o -1 (en función de si era + o -) y el id de cuenta. De esta forma, relacionamos esta tabla en el cubo por el id de cuenta y la medida se multiplicará por el “factor”, que le cambiará el signo para que sume o reste.

Cálculos de tiempo personalizados

Si para ciertas cuentas no queremos sumar en los cálculos temporales, sino hacer otra operación, por ejemplo, la media, podemos definir una columna (TBAverage) que para cada cuenta indique si suma (0) o hace media (1). La usaremos en el cubo como una medida que comprobaremos para cada nivel para detectar si esa cuenta debe sumar o hacer media para los cálculos temporales.

A continuación, puedes ver la presentación de la charla ‘Hilando fino en SSAS multidimensional’ del SolidQ Summit 2018:

0 Shares:
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like

Despliegue de Proyectos en Integration Services 2012

En entradas anteriores hemos revisado las características que ofrece el nuevo modelo de servidor de Integration Services, que se basa en Proyectos y Entornos en lugar de Paquetes y Configuraciones.En SQL Server 2012 se mantendrá la compatibilidad con el modelo de despliegue anterior, basado en paquetes, con la denominación Package Deployment Model. Los procedimientos para realizar despliegues en este modo no han variado desde versiones anteriores por lo que nos centraremos en el modelo de despliegue de proyectos Project Deployment Model.
SQL Server en Kubernetes (Parte 2)
Leer más

Matar al mensajero – SQL Server en Kubernetes (Parte 2)

En la primera parte de este artículo explicamos en qué consiste un SQL Server en contenedores y mostramos una forma sencilla de crear un entorno Kubernetes manejado. En esta segunda parte vamos a enfocarnos en los escenarios más críticos donde el uso de contenedores puede añadirnos latencias y esperas extras que acaben impactando en el rendimiento percibido por nuestros usuarios tras una migración de SQL Server a contenedores.