SSDT 16.4 – Workspace integrado

Microsoft ha liberado una nueva version del SSDT, la versión  16.4, esta agrega una capacidad muy útil para aquellos que trabajan con SSAS Tabular, un Workspace integrado, es decir, nos evitar la necesidad de tener un servidor de SSAS para utilizar como Workspace.

Para cambiar un proyecto existente de manera que utilice Workspace integrado tenemos una nueva opción en las propiedades del proyecto.

Cuando pasamos a este modo, debemos observar que la propiedad «Workspace Server» muestra el puerto por el que atiende este SSAS Tabular.

En opciones del SSDT para la sección del diseñador del SSAS tenemos una nueva opción para indicar el valor de workspace por defecto.

SSDT – 16.3 – Tabular Model Explorer

Microsoft liberó una nueva actualización del SSDT, la versión 16.3 incorporando una funcionalidad muy útil para los desarrolladores de modelos Tabulares.

Este explorador es una ventana adicional que nos permite navegar de forma ordenada el modelo tabular en edición, siendo de utilidad en modelos con cierta complejidad por su cantidad de componentes, lease tablas, métricas, kpis, etc.

Muy util para aquellos que le dedicamos muchas horas a este producto

DAX – Función SUMMARIZECOLUMNS (parte 1)

La versión 2016 de SSAS (Analysis Services) ha incorporado muchas funciones DAX, entre ellas SUMMARIZECOLUMNS, función que podemos encontrar en Power Pivot de Excel 2016 y Power BI.

Es una función que en aplicaciones reales la he encontrado mejores tiempos de respuestas que la combinación CALCULATETABLE + ADDCOLUMNS + SUMMARIZE.

Es muy util cuando usamos DAX como lenguaje de consulta o para armar una tabla dentro de SSAS Tabular, funcionalidad disponible en SSAS 2016 en modo de compatibilidad 1200, en Power BI y Power Pivot de Excel 2016, pero esto de tablas es para otro día…

Cuando podríamos usar esta función, cuando armamos reportes con Reporting Services, ya sea en reportes paginados, reportes móviles o KPIs, estos dos últimos antes conocidos como Datazen e incorporados en SSAS 2016 EE.

Esta function retorna una tabla, y posee la siguiente sintaxis

SUMMARIZECOLUMNS
( 
 <groupBy_columnName>[, < groupBy_columnName >]…, 
 [<filterTable>]…
 [, <name>, <expression>]…
) 

La función posee tres areas o tipos de parámetros principales:

• Campos de agrupación
• Condiciones de filtro
• Expresiones o cálculos

He aqui algunos ejemplos sencillos para empezar

Ejemplo 1:

EVALUATE
SUMMARIZECOLUMNS ( Product[Color] )

Este ejemplo inicial nos devuelve todos los diferentes valores de la columna Color de la tabla Product

Ejemplo 2:

EVALUATE
SUMMARIZECOLUMNS ( Product[Color], "Total Units", [Internet Total Units] )

Este segundo ejemplo nos devuelve una tabla con totales por color, como podemos ver la funcion solo retorna los valores con datos, es decir, usa las expresiones para determianr si mostrar un registro o no.

Ejemplo 3

EVALUATE
SUMMARIZECOLUMNS (
 Product[Color],
 "Total Units", IGNORE( [Internet Total Units])
)

En este ejemplo usamos la funcion IGNORE que nos permite indicar a la funcion SUMMARIZECOLUMNS que no use esa expresion para determinar la existencia o no de datos.

Ejemplo 4

 EVALUATE
 SUMMARIZECOLUMNS (
     Product[Color],
     FILTER( Geography, Geography[Country Region Name] = "Germany" ),
     "Total Units", [Internet Total Units]
 )

En este ejemplo agregamos una condición de filtro, que no necesariamente debe ser sobre un campo o tabla que estemos utilizando en los campos de GROUP BY pero si debe estar afectado a la expression.

SSRS + Mobile Reports + DAX (parte 1)

Con SQL Server 2016, Microsoft integro la «Datazen» dentro de Reporting Services con la denominación de Reportes Móviles.

Si nuestra solución de DW/BI utiliza SSAS (Analysis Services), especialmente la versión Tabular, como capa semántica, es interesante evaluar a DAX como language de consulta, y evitar pensar en DAX en los modelos y MDX en las consultas.

También puede ser una opción interesante tener SSAS Tabular detrás de nuestros reportes móviles, para mejorar tiempos de respuestas o aprovechar el poder de cálculo de DAX, reduciendo la complejidad en los reportes.

Los reportes móviles requieren acceder a los datos a través de «Shared Datasets», estos pueden normalmente construirse con Report Builder o SSDT.

Para trabajar con DAX, vamos a necesitar trabajar los «Shared Datasets» con SSDT.

Los pasos para un reporte sencillo serían:

1- Definir conexión

2- Crear un «Shared Dataset»

Para trabajar con DAX debemos configurar el Dataset para comandos DMX de manera de ingresar el comando DAX.

Esto nos permite ingresar la sentencia DAX, y si necesitamos trabajar con parámetros, para este ejemplo inicial, ingresamos un DAX sencillo sin parámetros.

EVALUATE
SUMMARIZECOLUMNS (
     Product[Color],
     Geography[Country Region Name],
     'Product Category'[Product Category Name],
     "Total Sales", [Internet Total Sales],
     "Total Units", [Internet Total Units]
 )

Creado el Dataset debemos desplegarlo en el servidor de reportes.

3- Crear Reporte móvil

Para crear el reporte debemos utilizar la aplicación «Mobile Report Publisher», e incorporar el Dataset construido con la sentencia DAX

Luego procedemos a construir el reporte, pudiendo quedar algo asi:

 

 

 

 

 

DAX – ALLSELECTED – Porcentaje de…

DAX es un language de funciones, como tal tenemos muchas funciones interesantes, y como son tantas algunas pueden pasar o muchas, sin que sepamos como podemos utilizarlas.

En este caso voy a mostrarles una utilidad sencilla de la function ALLSELECTED, si bien es un función que requiere mirar en detalle, si les interesa pueden leer el excelente articulo de Alberto Ferrari en el link.

Dada una métrica sencilla de cantidad de Clientes que posee la siguiente sintaxis:

Customers:=CALCULATE( DISTINCTCOUNT( [CustomerKey] ))

genero una segunda medida que la denomino Customers %, y que me muestra el % de Clientes… Ahora que %?, bien ahí está lo interesante…

Customers %:=
DIVIDE
( 
  [Customers], 
  CALCULATE([Customers], ALLSELECTED())
)

Utilizando la función ALLSELECTED estamos indicando que elimine el contexto de filtro de las filas y columnas pero manteniendo los demás contextos de filtros y filtros explícitos.

Si seleccionamos estas métricas por ejemplo en una tabla de PowerBI veríamos lo siguiente

Es decir, el total de clientes y como % el valor 100. Si agregamos columnas o filas que modifiquen el contexto veremos como funciona este ejemplo

 

 

 

 

DAX–Tabla de Parámetros para condicionar cálculos

A veces necesitamos que nuestras medidas calculadas varíen según parámetros seleccionados, como podrían ser diferentes tasas, representaciones numéricas, escenarios de análisis, conversiones de moneda.

Necesitamos armar una tabla con una única columna donde tendremos los valores de selección y aplicación, o una tabla con mas de un campo. Esta tabla no debe estar relacionada con otras tablas del modelo.

 

Creada e incorporada la tabla, debemos modificar nuestras medidas calculadas hacerlas sensibles a los valores seleccionados.

Tomando la siguiente expresión de ejemplo

Sales Amount:=SUM([SalesAmount])

 

Debemos modificar la expresión a la siguiente forma:

Sales Amount:=      IF(          HASONEVALUE(Escala[Escala]);          SUM([SalesAmount])/VALUES(Escala[Escala]);          SUM([SalesAmount])     )

 

Ahora si nuestra tabla de parámetros tiene mas de una columna la expresión debería tener la siguiente forma:

Sales Amount:=      IF(          HASONEVALUE(Escala[Factor]);          SUM([SalesAmount])*(1+VALUES(Escala[Factor]);          IF( NOT( FILTERED( Escala[Escala]) ),            SUM([SalesAmountQuota]),            BLANK()         )     )

Consideraciones para optimizar modelos Tabulares y PowerPivots

A continuación se enumeran algunos tips para “optimizar” el uso de memoria en los modelos tabulares o PowerPivot, en relación al uso de memoria RAM.

Importar solo las columnas útiles

Debido a que los datos son almacenados por columna, cada una de estas posee un costo, siendo mas caras aquellas que poseen una gran cantidad de valores diferentes, motivo por el cual es importante que al importar tablas en PowerPivot solo debemos incorporar aquellas columnas que utilizaremos en filtros, relaciones y cálculos.

Las columnas que podríamos excluir en la carga son:

Claves Primarias de tablas de hechos

Identificadores de transacciones en las tablas de hechos

GUIDs y columnas utilizadas para replicación o auditoria

Timestamp, Fechas de Creación y Modificación

Normalizar Columnas

Evitar incorporar columnas que son cálculos de otras y armar medidas o campos calculados en el modelo. Si tenemos por ejemplo las columnas cantidad, precio, y monto total, esta ultima podríamos excluirla, incorporando una medida o campo calculado utilizando cantidad y precio de la forma

Monto Total := SUMX( Ventas, Ventas[Precio] * Ventas[Cantidad])

En este ejemplo Precio y Cantidad serian columnas con una mayor tasa de compresión o mayor probabilidad de repetición de valores que el producto de ambas, siendo el monto total calculado en el momento de la consulta.

Dividir columnas de alta cardinalidad

Si una columna posee demasiados valores diferentes, como podría ser un ID de transacción o  fecha y hora de un evento, si dividimos en la carga en varias columnas, por ejemplo fecha y hora en dos columnas, estas ocupan mucho menos memoria que el campo original conteniendo ambos valores.

Reducir la precisión cuando es posible

Reduciendo la precisión de una columna podríamos quizás reducir la cantidad de valores diferentes, por ende el uso de memoria.