¡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!