¡Jueves! Primer post del año 2023 y continuamos con la serie de datamart. Este post tocaba la semana pasada pero ya me perdonaréis, pero me estuve preparando para examinarme de la certificación DP-500: Azure Enterprise Data Analyst Associate (¡y la aprobé! J). Ya os contaré en otro post como ha sido mi experiencia con esta certificación.

Recapitulemos, en el post anterior hablamos de cómo creábamos un datamart, su carga de datos, el query folding y unos tips con buenas prácticas, si te lo perdiste, te dejo aquí el link. En este post veremos el proceso de transformación, carga y claves para un correcto modelado. Como suelo decir, este proceso son los cimientos de nuestro modelo.

Antes empezar con todo el proceso de transformación, debemos de tener claro el objetivo de nuestro modelo y las preguntas de negocio a las que tenemos que dar respuesta:

·        Analizar las ventas temporales por:

o   Producto, categoría y subcategoría.

o   Promociones aplicadas.

o   Continentes, países y tiendas con más ventas

o   Medio por el que se han realizado las ventas.

o   Empleados con más ventas.

Una vez obtenidos los requerimientos de nuestro modelo, lo que a mí me gusta realizar, es la identificación de las tablas, es decir, identificar las tablas de hechos y las de dimensión. Para ello creamos un grupo para cada uno de ellas:

 

Y a las tablas de hechos les añadimos el prefijo “Fact_” y las arrastramos al grupo recién creado:

 
 

Y realizamos casi el mismo proceso para las tablas de dimensión, pero sin añadir aún el prefijo “Dim_” que lo haremos más adelante, y se nos queda el siguiente esquema, que, aunque no será el definitivo, nos aporta una visión más clara de nuestro modelo:


 

Os estaréis preguntado por qué no le he puesto el prefijo “Dim_” a las tablas, bien, el motivo es que no todas las tablas las consideraremos como dimensión, sino que algunas serán atributos de las tablas de dimensión, y puede que no sea necesario cargarlas a nuestro modelo. Acordaros que nuestro objetivo siempre que podamos, será llegar a un modelo en estrella. Como dice Toni Jurado, “Sigue el camino de la estrella” (y qué mejor que la noche de los Reyes Magos ... J )

Uno de los requerimientos del negocio, es el análisis de los datos por producto, categoría y subcategoría. Vamos a analizar las tablas, para ello seleccionamos la tabla de Categoría:

 
 

Vemos que tiene 6 columnas que son:

  • ProductCategoryKey  (Clave de negocio o clave Principal) à Tipo número entero.
  • ProductCategoryLabel à Tipo texto
  • ProductCategoryName à Tipo texto
  • ProductCategoryDescription à Tipo texto
  • ETLLoadID à Tipo número entero
  • LoadDate à Tipo fecha y hora
  • UpdateDate à Tipo fecha y hora


De este primer análisis, debemos eliminar las columnas que no sean necesarias para nuestro modelo, y estas son: ProductCategoryLabel, ETLLoadID, LoadDate y UpdateDate.

¿Por qué no son necesarias? Porque no son un requisito para el análisis de nuestro modelo y, por tanto, no las necesitamos. 

 
 

Nota: las columnas LoadDate y UpdateDate son columnas de tipo fecha y hora, si para nuestro modelo las necesitásemos, recordar que deberíamos separarlas en dos columnas, una con la fecha otra con la hora ya que se comprimen mejor.

Ahora, vamos a la tabla ProductSubcategory:

  • ProductSubcategoryKey  (Clave de negocio o clave Principal) à Tipo número entero.
  • ProductSubcategoryLabel à Tipo texto
  • ProductSubcategoryName à Tipo texto
  • ProductSubcategoryDescription à Tipo texto
  • ProductCategoryKey à (Clave secundaria) à Tipo número entero
  • ETLLoadID à Tipo número entero
  • LoadDate à Tipo fecha y hora
  • UpdateDate à Tipo fecha y hora

De este análisis, debemos eliminar las columnas que no sean necesarias para nuestro modelo, y estas son: ProductSubcategoryLabel, ETLLoadID, LoadDate y UpdateDate.


 
 

Una vez ya hecho el trabajo de limpieza de estas dos tablas, podemos combinarlas entre ellas. Para ello, vamos a Combinar consultas y seleccionamos la columna por la que queremos combinarlas:


 
 

Como dato importante, vemos que de los 44 registros de la tabla ProductSubcategory, hay 44 coincidencias. ¿Esto qué significa? Que para cada fila de las 44 de la tabla ProductSubcategory, hay una coincidencia exacta en la tabla ProductCategory. O lo que es lo mismo, cada subcategoría tiene una categoría asociada.

A continuación, expandimos la tabla combinada y seleccionamos las columnas que necesitamos:

 
 

Si nos fijamos en los pasos aplicados en la consulta, el plegado de consultas se mantiene:

 
 

¿Y por qué se mantiene el plegado de consultas? Por qué no lo hemos roto en la tabla ProductCategory. En cambio, si lo hubiésemos roto, al combinarla con la tabla ProductSubcategory, el plegado estaría roto. Por eso, salvo que sea indispensable, debemos mantener el plegado hasta el final.

Si os fijáis en la parte de las consultas, en la tabla ProductSubcategory, nos ha aparecido un icono de un rayo, ¿qué significa?

 
 

Significa que es una entidad calculada, o lo que es lo mismo, realizar cálculos en almacenamiento. En nuestro caso, no queremos cargar al modelo la tabla ProductCategory, ya que la hemos combinado con la tabla ProductSubcategory, por lo que deshabilitamos la carga de la misma y acto seguido nos desaparece el icono del rayo:

 
 

Ahora vamos a la tabla Product y realizamos el mismo proceso que hemos hecho en las otras dos tablas que son: seleccionamos las columnas que queremos y combinamos la tabla con ProductSubcategory. 

 

 
 

Ahora ya tenemos nuestra tabla de dimensión completa… ¿Seguro? Sí pero no, ya que es recomendable coger el hábito de crear nuestras propias claves subrogadas, que son claves que generamos nosotros mismos y que no tienen relación con el modelo del negocio. ¿Con que objetivo?

  • Evitar las claves que no sean numéricas. (en este caso lo son, pero muchísimas veces no lo son)
  • Posibilidad de tener SCD (Dimensiones lentamente cambiantes)

 

Antes de generar la columna índice, debemos asegurarnos de que no tenemos ningún registro duplicado en nuestra tabla de dimensión dado que la relación con la tabla de hechos va a ser 1 a varios.  Para ello, seleccionamos la tabla completa, haciendo click en la zona superior izquierda de la tabla:

 
 

Si hubiésemos quitado duplicados seleccionando una columna, sólo quitaría los duplicados de esa columna. Como podemos ver, nos sigue manteniendo el plegado de consultas J.

 

Ahora, ¿cómo generamos una clave subrogada? Vamos a la opción Agregar columna y seleccionamos “Columna de índice”, y que comience desde 1.

 

Y automáticamente, Power Query nos ha generado una columna que será la que usemos como clave subrogada.

 
 

En este paso, podemos aprovechar y cambiarle el nombre sin añadir un paso extra. Para ello, en la barra de pasos, escribimos el nombre que le queremos dar a la columna nueva, en este caso “IsProductCategory”:

 
 

Y podemos ver que el nombre de la columna se ha modificado correctamente y en la parte de pasos aplicados no se ha añadido uno nuevo.Pero fijaros que hemos roto el query folding con este último paso, por lo que este paso no se evaluará en el origen sino en destino.

Ahora, para tener la vista de consultas más limpia, creamos un grupo nuevo para mover las tablas que son los atributos de dimensión.

 

Tal y como podéis ver en la siguiente imagen:

 
 
 

Y por último y a modo de limpieza y orden del modelo, una vez ya modelizada nuestra tabla de dimensión Product, le añado el sufijo “Dim_” para que de un vistazo rápido se distingan rápidamente las tablas.

 
 
 
 

Y con esto, ya tenemos nuestra tabla de dimensión producto, preparada para ser utilizada.Y por hoy, hasta aquí ya está bien que sino me lío y os tengo aquí hasta mañana.

¡Nos vemos en los datos!