Integración de previsiones presupuestarias y otros datos a diferente granularidad en Power BI

Introducción

El modelado de previsiones presupuestarias constituye uno de los escenarios más desafiantes en el campo del diseño y explotación de modelos de datos en Power BI. Las estructuras de datos en dicha herramienta se basan en el motor de Analysis Services y en la tecnología xVelocity (previamente denominada VertiPaq); de hecho, al ejecutar un archivo .pbix se inicia a su vez una instancia tabular de SSAS (SQL Server Analysis Services) en un puerto aleatorio.

En el modelo tabular, a diferencia de lo que ocurre en el multidimensional, las relaciones entre tablas se establecen utilizando una sola columna, que requiere que sus valores sean únicos en la tabla de búsqueda, por lo que no podemos definir relaciones entre hechos y dimensiones a diferentes granularidades directamente.

En este artículo veremos cómo manejar las relaciones entre tablas con distinta granularidad, escenario típico cuando tratamos de incluir previsiones presupuestarias en nuestro modelo. En este tema cada empresa es un mundo y todo depende del nivel de detalle al que se hayan definido dichas previsiones, pero el problema consiste a menudo en que la granularidad del presupuesto es completamente distinta a la del resto del modelo de datos.

Desnormalizando dimensiones de forma eficiente

Como vimos en una entrada anterior, cuando diseñamos un modelo de datos analítico, el enfoque principal debe situarse en lograr un diseño que favorezca la simplicidad en la exploración y agregación de los datos, a la vez que en obtener un rendimiento óptimo en la realización de consultas.

Las estructuras altamente normalizadas, con dimensiones organizadas en esquemas de copo de nieve que principalmente nos encontraremos en los sistemas de procesamiento de transacciones, no serán adecuadas para satisfacer las necesidades analíticas de la empresa teniendo la comprensibilidad del modelo por parte de los usuarios y la velocidad de consulta como objetivos principales. El hecho de disponer de más de una tabla por cada dimensión de la tabla de hechos de un proceso de negocio implica tener que realizar código más complejo para realizar una consulta que a su vez se ejecutará en un tiempo mayor, debido en parte al mayor número de relaciones.

Dimensión horaria en M

En casi cualquier modelo de datos que diseñemos será imprescindible disponer de una dimensión temporal que nos permita filtrar y segmentar los datos de las tablas de hechos en función de los atributos temporales que nos interesen en cada momento. La dimensión temporal más común y útil corresponde a aquella de nivel de granularidad diario, donde tendremos un registro por cada día del periodo abarcado por dicha dimensión.

Por otra parte, atributos relacionados con la dimensión horaria utilizados para describir los eventos registrados en las tablas de hechos aparecen con mucha menor frecuencia. No obstante, en algunas ocasiones en las que el tiempo queda registrado con un nivel de detalle inferior al día, la posibilidad de segmentar los datos por dichos atributos se convierte en uno de los temas principales a la hora de diseñar un almacén de datos analítico.

Análisis económico-financiero en Power BI

Introducción

Los informes económico-financieros, basados principalmente en las normas de registro y valoración de los diferentes elementos que componen los estados financieros que deben elaborarse bajo el Plan General de Contabilidad, han sido históricamente un proceso complejo y estático, que proporciona información limitada y con horizontes temporales predefinidos (cierre trimestral, anual…), con la que no podemos interactuar y profundizar en aquellos aspectos que nos interesan en cada momento, algo necesario si realmente queremos poder obtener información relevante y evaluar en detalle la evolución de las magnitudes empresariales en relación a sus objetivos.

Las herramientas de inteligencia de negocios nos permiten ir mucho más allá en la elaboración de este tipo de informes, tanto si se basan principalmente en la contabilidad financiera y se dirigen a los grupos de interés externos a la empresa, como si utilizan un amplio abanico de orígenes de datos internos y externos, y sus destinatarios principales son los directivos de la empresa, con el objetivo de facilitar la toma de decisiones en cualquier momento y lugar, proporcionando un instrumento de planificación, información y control simultáneo y dinámico de las diferentes partes de una organización, aumentando la capacidad de la empresa de crear valor económico.

Estructuras jerárquicas en tablas de hechos

Introducción

Un escenario muy frecuente cuando utilizamos bases de datos relacionales como origen de datos principal de un modelo que reproduce un proceso de negocio, como pueden ser las ventas de una empresa, es encontrarnos con dos tablas de hechos con distinta granularidad para describir el mismo proceso. Una de ellas contendrá un registro por cada ticket, albarán o factura emitida con los atributos generales de fecha, cliente, base imponible, impuesto etc., y la otra irá un poco más allá y registrará las ventas a nivel de cada producto vendido, es decir, existirá un registro por cada línea de detalle dentro de cada documento.

En la siguiente imagen podemos ver un ejemplo de esta situación, donde tanto los albaranes como las facturas presentan una estructura de datos del tipo descrito:

Medidas semi-aditivas en DAX

En cualquier sistema de BI, podemos crear cálculos o medidas de 3 tipos distintos:

• Medidas aditivas: son generalmente la mayor parte de las medidas que nos encontraremos en un modelo de datos analítico, y se caracterizan porque podemos usar la función SUM() para agregar sus valores en función de cualquier atributo dimensional. Un ejemplo típico pueden ser las ventas, cuyo total podemos desglosar en la suma de las ventas por producto, por mes, por cliente, así como por cualquier otro atributo que nos interese para filtrar o segmentar dicho cálculo.

• Medidas semi-aditivas: son las más complejas y en las que vamos a profundizar en este artículo. Este tipo de cálculos pueden usar la función SUM() para agregar sus valores solo en función de determinadas dimensiones, pero se necesita otro tipo de agregación distinta para segmentar por los atributos de alguna otra dimensión. Ejemplos típicos de este tipo de medidas son las tablas de inventarios y las de los saldos de las cuentas contables, que no pueden agregarse en función de los atributos de la dimensión temporal mediante una suma simple.

• Medidas no aditivas: son aquellas que no pueden agregarse usando la función SUM() en función de ninguno de los atributos presentes en el modelo de datos. Un ejemplo típico es el tipo de cambio de una moneda respecto a otra.

Uso de la función USERELATIONSHIP en columnas calculadas

Introducción

En un modelo tabular con relaciones inactivas podemos usar la función USERELATIONSHIP() para activar una de ellas durante el tiempo de ejecución de un determinado cálculo con DAX. Para ello, simplemente tenemos que especificar dicha función (y los parámetros correspondientes) como uno de los argumentos de filtro de la función CALCULATE(). El uso de USERELATIONSHIP() es sencillo cuando queremos crear una medida, pero se complica si lo que deseamos es utilizar dicha función en la definición de una columna calculada. En este artículo vamos a ver qué es lo que ocurre en estos casos, explicando uno de los aspectos más importantes que se produce cuando ejecutamos la función CALCULATE() dentro de una columna calculada, o de forma más general, dentro de un contexto de fila: la transición de contexto.

Estructuras de datos en entornos analíticos

Cuando diseñamos un modelo de datos analítico, uno de los aspectos clave a tener en cuenta corresponde al nivel de normalización/desnormalización con que queremos dotar a la estructura del mismo. Es probable que la mayoría de los orígenes de datos que utilicemos a nivel profesional correspondan a sistemas de procesamiento de transacciones (OLTP). Estos sistemas son bases de datos relacionales optimizadas para llevar a cabo las tareas diarias de una oficina, principalmente la gestión de pedidos, facturas, reclamaciones, realización de asientos contables, etc…

En estos sistemas nos encontraremos normalmente con estructuras altamente normalizadas, donde prácticamente cada atributo se almacena en una tabla y, por lo tanto, un solo objeto, como por ejemplo «Cliente», estará almacenado en 10 o 20 tablas distintas relacionadas entre sí. Esto se debe a que dichas bases de datos OLTP están diseñadas para gestionar continuas operaciones de introducción y modificación de datos, por lo que una estructura de este tipo proporciona la ventaja de ahorrar tamaño en disco (lo que normalmente se traducirá en mayor velocidad) y que los cambios que introduzcamos en un atributo solo tengan que actualizarse una vez.

La función USERELATIONSHIP

En cualquier modelo de datos es relativamente frecuente la necesidad de analizar un mismo parámetro en función de fechas distintas que describen un mismo evento. Por ejemplo, podemos disponer de una tabla de pedidos donde, para cada uno de ellos, tengamos una fecha de pedido, una de entrega y una de envío. Pueden existir varias relaciones entre dos tablas en un modelo tabular, pero solo una de ellas puede permanecer activa durante la realización de un cálculo determinado, requiriendo la desactivación de las demás:

Grupos de medidas en Power BI Desktop

En numerosas ocasiones, cuando estamos trabajando con modelos de datos complejos, con muchas tablas y relaciones, y que requieren un número considerable de medidas, es importante tener en cuenta el lugar de almacenamiento de las mismas. Por ejemplo, es probable que tras cargar al modelo de datos todas las consultas necesarias para obtener la información que el usuario precisa, nos encontremos en la vista de relaciones con algo así: