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.

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:

Días festivos nacionales en dimensión temporal

Aquellos profesionales que trabajan en temas relacionados con la gestión analítica de los datos de una empresa, conocen que existen multitud de análisis interesantes que dependen íntegramente de la dimensión temporal del modelo de datos. Sin una dimensión temporal cuyos metadatos se adapten a las características de la empresa en cuestión, nos resultará difícil captar aquellos elementos que marcan la diferencia y constituyen el verdadero valor añadido proporcionado por las herramientas de inteligencia de negocios en la toma de decisiones empresariales.

En algunos negocios, es especialmente importante la incidencia de los días festivos. Si por ejemplo estamos analizando las ventas de un restaurante, las llamadas entrantes en un call center o las estadísticas de una página web, probablemente encontraremos diferencias significativas en los datos en función de si el día es festivo o no. En este artículo vamos a ver cómo podemos extraer esta información en tiempo real desde API’s en línea y añadirla a nuestra dimensión temporal.

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

Dimensión temporal en M

Una de las dimensiones críticas a la hora de crear un modelo de datos analítico es, sin duda, la dimensión temporal. En los últimos años, las herramientas de inteligencia de negocios suelen incluir una jerarquía temporal automática que se crea a partir de los campos de fecha presentes en el modelo. La pregunta es:

¿Necesito una tabla separada como dimensión temporal en el modelo de datos, o me vale con usar las jerarquías automáticas que me ofrecen estas herramientas?