¡Bienvenidos, muy buenos días tardes o noches , según donde me leas !

Continuando con la fase 2 del modelado de datos:

En esta etapa del reto de hoy, nos centraremos en el modelado de datos. Abordaremos correcciones y destacaremos la importancia de las llaves primarias, claves subrogadas, claves de negocio y por qué Power BI no se lleva bien con tablas de hechos que contienen mucho texto. Lo haremos de manera concisa y comprensible. ¡Vamos con toda la energía!

PEROO!! antes que nada vemos un poco de teoría , para entrar en contexto, vamos será breve jejeje.

Llave Primaria (Primary Key): En el contexto del post, la llave primaria se refiere a un campo en una tabla de base de datos que tiene una característica especial. Este campo contiene valores únicos para cada fila de la tabla y se utiliza para identificar de manera única cada registro en esa tabla. En el post, se menciona la creación de la llave primaria «PK_Customer» para la dimensión «Dim_Customer». La llave primaria garantiza la integridad y unicidad de los datos en esa tabla.
Llave Foránea (Foreign Key): La llave foránea, también mencionada como «clave foránea», es un campo o conjunto de campos en una tabla que establece una relación con la llave primaria de otra tabla. En el post, meciono la creación de una llave foránea llamada «ID_Customer» en una tabla de hechos para relacionarla con la llave primaria «PK_Customer» en la dimensión «Dim_Customer». Las llaves foráneas se utilizan para establecer relaciones entre tablas y permiten vincular datos relacionados en diferentes tablas de la base de datos.
Clave Subrogada (Surrogate Key): En el post, se hace referencia a la creación de una clave subrogada «autoincrementable» para la dimensión «Dim_Customer». Una clave subrogada es un tipo especial de llave primaria que se crea específicamente con el propósito de ser una identificación única para un registro, independientemente de los datos del mundo real que represente. En este caso, se usa una clave subrogada en lugar de, por ejemplo, utilizar el número de cliente como llave primaria. Esto puede ayudar a mejorar el rendimiento y la eficiencia del modelo de datos.
Clave de Negocio (Business Key): Se refiere a un campo o conjunto de campos en una tabla que se basa en datos del mundo real y que se utiliza para identificar de manera única los registros en esa tabla desde una perspectiva del negocio. Por ejemplo, el número de cliente o el nombre del producto podrían ser claves de negocio en una base de datos de ventas. Tibien es importante entender que , las claves de negocio se utilizan como base para crear llaves primarias o se usan en combinación con claves subrogadas para garantizar la integridad de los datos.

Es fundamental recordar que aún no hemos creado las llaves primarias y las llaves foráneas, elementos necesarios para un adecuado modelado de datos.

Comencemos revisando la dimensión que hemos creado en este paso, denominada «Dim_Customer». En esta dimensión, agregaremos la columna «segment» para desnormalizarla y eliminar duplicados, siguiendo el criterio mencionado en la publicación anterior, basado en la granularidad de los datos: fina, media o gruesa.

Ahora, debemos comprender cómo afecta el tamaño del modelo de datos tener un campo de clave primaria en nuestro modelo. Usaremos la dimensión «Dim_Customer» como ejemplo. Si mantenemos la relación únicamente con el campo «CustomerID», no obtendremos beneficios significativos en términos de tamaño. Esto se debe a que Power BI y VertiPaq, al importar datos, funcionan de manera más eficiente cuando se evitan campos de texto o cadenas largas en las tablas de hechos. En su lugar, es preferible crear una clave subrogada autoincrementable para la dimensión y luego incorporar esta columna en la tabla de hechos mediante una fusión (merge). Posteriormente, podemos eliminar las columnas no deseadas, dejando una tabla de hechos limpia con campos aditivos, llaves primarias y campos cuantificables no categóricos, como lo sugiere Kimball en su libro.

Este enfoque de trabajo se aplicará al resto de las dimensiones. El primer paso será crear el campo autoincrementable utilizando Power Query (imagen 2), lo que generará nuestra llave primaria «PK_Customer» para la dimensión «Customer». Luego, realizaremos la primera fusión con la tabla de hechos, seleccionando la tabla de hechos y cruzando las tablas mediante el campo común «CustomerID» (imagen 3 y 4) . El resultado será una columna que seleccionaremos como nuestra clave «PK_Customer» (imagen 5), que actuará como nuestra llave foránea. Ahora podemos eliminar específicamente las columnas de la dimensión (imagen 6).

¿Por qué realizamos este proceso? La respuesta radica en el tamaño del modelo de datos y su impacto,. Utilizaremos DAX Studio para analizar el tamaño de las tablas, columnas, relaciones y tipos de campo en nuestro modelo de datos, con los cambios aplicados en DAX STUDIO, podemos ver que mide 1,22 MB.

Ahora Cargar un modelo sin seguir los pasos anteriores, es decir, sin crear una clave subrogada ejecutamos de nuevo DAX STUDIO , revela una diferencia significativa de 9 MB en el tamaño. Aunque parece insignificante, es crucial tener en cuenta que este tamaño aumentará con el tiempo. Por lo tanto, estos pasos son fundamentales para comprender el funcionamiento de un modelo de datos en Power BI, la importancia de las claves subrogadas, las llaves primarias y cómo reducir el tamaño del modelo siguiendo las mejores prácticas de Kimball y las recomendaciones de Microsoft.

Una vez que hemos demostrado la relevancia de un modelo de datos eficiente, repetiremos los pasos anteriores para crear llaves primarias, claves subrogadas, realizar fusiones con la tabla de hechos y eliminar columnas no deseadas para optimizar nuestro modelo.

Hemos creado las siguientes dimensiones:

Dim_Customer (imagen 8)
Dim_Country (imagen 9)
Dim_Retail (imagen 10)
Dim_Product (imagen 11)
Dim_Shipmode (imagen 12)
Dim_Returned (imagen 13)

Recuerda que replicamos los pasos que realizamos para «Dim_Customer» en la creación de campos subrogados y llaves primarias para cada dimensión, fusionamos las tablas (imagen 14), traemos las columnas necesarias a la tabla de hechos (imagen 15) y luego eliminamos las columnas que ya están presentes en la tabla de hechos. De esta manera, mantenemos la integridad de los datos y creamos un modelo eficiente siguiendo las convenciones de diseño.

Como puedes observar, realizamos las modificaciones necesarias para editar nuestro modelo de datos y mantenerlo eficiente y controlado (imagen 16). El resultado es un modelo en estrella (imagen 17).

Bueno para cerrar la idea de crear este post es destacar la importancia de las llaves primarias, las llaves foráneas, las claves subrogadas y las claves de negocio en el modelado de datos en Power BI.

Estos conceptos son esenciales para garantizar la integridad de los datos, optimizar el rendimiento del modelo y reducir el tamaño del mismo. Además, se enfatiza la importancia de seguir las mejores prácticas de diseño de datos de Kimball y las recomendaciones de Microsoft para lograr un modelo de datos eficiente en Power BI.

Documentación oficial :https://learn.microsoft.com/es-es/power-bi/guidance/star-schema

Lectura de sugerencia (Obligatoria jejeje): El libro de Toni Jurado el cual es una maravilla: https://www.lulu.com/search?page=1&q=fundamentos+de+modelado&pageSize=10&adult_audience_rating=00

Libro de Kimball que es fundamental para nuestros modelos de datos.

La próxima edición abordará la creación de la tabla de fechas en la fase 3.

Business Intelligence Technical.