Laboratorio 6 Tableros de control y KPIs

Juan Daniel Castrellon - 201729285

Marzo 2021

Índice
1. Introducción 2

2. Manejo de datos en StockItem 2

3. Modificación del ETL de hechos 6

4. Propuestas de manejo 9
4.1. Tipo 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Tipo 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Tipo 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4. Comparación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5. Big Query 14

6. Preguntas 15
6.1. ¿Cual es el objeitvo de la columna tk stock item? . . . . . . . . . . . 15
6.2. ¿Qué significa cada una de las opciones en el campo Type of dimension
update? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. ¿Cómo se puede saber que el proceso ETL manejó los cambios entre
los dos archivos? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.4. ¿Por qué se debe hacer el cambio para que la columna de la llave
subrogada sea de tipo Unique? . . . . . . . . . . . . . . . . . . . . . 16
6.5. ¿Qué pasa si uno de los datos reportados en la tabla de hechos no existe
en alguna de las dimensiones?¿Qué sugiere para evitar esa situación? . 16

7. Conclusión 16

1
1. Introducción
En este laboratorio, se trabajará como asesor de World Wide Importers (WWI), un
importador y distribuidor de productos de primera categorı́a. Actualmente, la empresa
se encarga de vender sus productos a supermercados, almacenes minoristas o tiendas
especializadas dentro de Estados Unidos, pero actualmente se está expandiendo a
otros paı́ses. WWI compra mercancı́as a mayoristas (juguetes, ropa, novedades), los
almacenan y los revenden. En caso de que no hayan suficientes productos, se realiza
el pedido a los mayoristas con el fin de suplir las necesidades de los clientes. Aún ası́,
en caso de que los clientes no deseen esperar a que WWI, pueden también cancelar el
pedido.
Anteriormente, ya se habı́a construido un proceso ETL que permitı́a subir la información
de una archivo .CSV a una base de datos Postgre. Aún ası́, estos datos no contaban con
el manejo de historial de cambios en las dimensiones de cliente y stock item, por lo
que para esta entrega se modificó el proceso ETL con en fin de manejar un historial. El
proceso consistió en añadir 4 columnas nuevas a la tabla en la que se va a manejar la
historia. Una llave primaria diferente al ID de la tienda, dos columnas que indican el
rango de fechas en que los datos tienen validez, y una última columna que indique la
versión del cambio. A continuación, se muestra el proceso seguido para implementar
estos cambios

2. Manejo de datos en StockItem

En primer lugar, vale la pena aclarar que para la implementación de este laboratorio,
se partió de lo trabajado previamente en el ETL creado para el laboratorio 5, donde
habı́a un proceso implementado que no maneja cambios. En primer lugar, para realizar
las pruebas, se deshabilitaron todos los caminos que podı́a tomar el Job implementado
previamente (a excepción de la ruta de stock item), como se ve a continuación

Figura 1: Flujos desactivados en Pentaho con el fin de únicamente correr lo relacionado

con el ETL de Stock Item

2
Una vez hecho esto, se creó una nueva transformación con el fin de no dañar el trabajo
realizado previamente. Transformation stock item apuntara a esta nueva transformación.
Asimismo, también era necesario cambiar los campos de la tabla. Por lo tanto, en el nodo
Stock item se modificó el SQL para añadir 4 nuevos campos: tk stock item, version,
date from y date to, como se ve a continuación:

Figura 2: Nueva sentencia SQL para crear la tabla stockitem historia con los atributos
necesarios para manejo de cambios

Ahora, es necesario realizar el flujo de la transformación. En primer lugar, añadimos

un nodo CSV file input que lea el archivo dimension stock item.csv. Luego, se añade el
nodo Dimension lookup/update, el cual se encarga de guardar estos cambios en la
base de datos. Hasta el momento, la transformación debe verse de la siguiente forma:

Figura 3: Transformación para el ETL de Stockitem historia

Ahora, es necesario configurar el nodo Dimension Lookup/update. En primer lugar,

en el campo Keys seleccionar el campo correspondiente a stock item key, como se
ve a continuación:

3
 Figura 4: Configuración del campo Keys del nodo Dimension lookup/update

A continuación, en la pestaña Fields se da click a la opción get fields. A continuación,

se modifican los campos Technical key field, donde asignamos la columna tk stock item,
y en Version field asignamos version. El resultado se ve a continuación:

Figura 5: Configuración del nodo Dimension lookup/update

4
Una vez hecho esto, se ejectuta el Job, y se deben ver los cambios en la base de datos.
A continuación, se muestra una consulta realizada en PGAdmin

Figura 6: Primer conjunto de datos subido. Este corresponde al conjunto de datos

original y tiene una fecha de validez entre 1900 y 2199

A continuación, vamos a realizar los cambios. En este caso, vamos a cambiar el conjunto
de datos al que se encuentra en el archivo dimension stock item new.csv, donde hay
modificaciones a los productos adquiridos por WWI. Por lo tanto, es necesario que
el nodo para leer el CSV apunte ahora a este archivo. A continuación, en el nodo
Dimension lookup/update, se modifica el SQL, el cual indica que variaciones sobre
la tabla el nodo realizará, con el fin de cambiar unas variaciones automáticas que realiza
Pentaho. A continuación, se ejecuta este SQL haciendo click en Excecute.

Figura 7: Codigo SQL ejecutado para realizar las modificaciones necesarias a la base de
datos.

Por último, se vuelve a ejecutar el Job con el fin de que estos nuevos datos se suban a la
base de datos. El resultado es que, al realizar la consulta en PGAdmin, se debe ver que

5
los campos date from y date to ya no van desde 1900 hasta 2199. Por el contrario, los
datos subidos la primera vez deben tener un rango desde 1900-hoy y los datos subidos
ahora un rango entre hoy-2199.

Figura 8: Base de datos una vez se suben los datos con las modificaciones necesarias.

3. Modificación del ETL de hechos

Ahora, es necesario que la tabla de hechos se acomode a estos cambios propuestos. Para
esto, en primer lugar es necesario que el atributo tk stock item sea unique. Ahora, en el
Job se vuelven a activar todos los flujos. Luego, en el nodo SQL fact order se cambia
el SQL con el fin de que Stock Item Key apunte a tk stock item.

Figura 9: Modificación a la tabla de hechos para apuntar al atributo tk stock item

A continuación, se agrega un segundo nodo SQL que cree una tabla temporal, donde se
almacenarán los datos mientras se realiza el cambio. Esta tabla es idéntica a fact order.
A continuación, se puede ver la tabla creada

6
 Figura 10: Sentencia SQL que permite crear la nueva tabla

Figura 11: Job implementado en Pentaho con las modificaciones realizadas

Ahora, creamos una nueva transformación para el ETL de Fact Order. En primer lugar,
se crea un nodo CSV file input, donde se lee el archivo fact order new.csv. A
continuación, se crea un nodo Insert/Update que añada los datos a fact order temp:

7
 Figura 12: Configuración del nodo para insertar los atributos a la tabla temporal

Una vez se suben los datos a la tabla temporal, creamos una nueva tabla fact order join,
donde se almacenará el resultado de unir las tablas fact order temp y stocitem historia,
y filtrar aquellos datos donde la fecha de fact order estuviera entre las fechas
date from y date to de stock item

Figura 13: Sentencia usada para generar una nueva tabla con la unión entre
fact order temp y stocitem historia

A continuación, con el nodo Table Input se recogen todos los datos en la tabla
fact order join, para posteriormente, haciendo uso del nodo Insert/Update subir
estos datos a la base de datos definitiva. Por último, en el flujo del Job se añade un nodo
SQL para eliminar las tablas temporales. Ahora, se ejecuta todo el Job. El resultado es el

8
siguiente:

Figura 14: Consulta en PGAdmin que permite ver el resultado al ejecutar el trabajo

4. Propuestas de manejo
Asimismo, se buscó implementar cuatro tipos de cambio extras en el modelo. En total,
se implementaron 3 posibles formas de realizar el ETL, cada una corresponde a una
forma distinta de implementar el manejo de cambios. Según Kimball, existen un total
de 7 formas para manejar Sloowly Changing Dimensions, y se quizo implementar la
propuesta 2, 3 y 6. En este caso, se usó la dimensión Customer para realizar las pruebas
4.1. Tipo 2
En primer lugar, se implemento la dimensión cambiante tipo 2. Para este tipo, la idea es
generar nuevas columnas las cuales indiquen en que fechas tiene validez el dato entrante.
En este caso, la implementación es bastante similar a la implementada previamente. En
primer lugar, en el nodo customer se añaden las filas correspondientes a tk customer,
version, date from y date to. [1]

Figura 15: Creación de la tabla customer historia, con el fin de realizar el manejo de
historia para la dimensión

9
A continuación, en la transformación es necesario añadir los nodos para leer el CSV, y
luego el nodo de Dimension Lookup/Update. Acá realizamos las mismas configura-
ciones que para stock item.

Figura 16: Configuración del nodo Dimension Lookup/Update para el manejo de

cambios de la dimensión customer

Finalmente, una vez implementada esta forma de manejo de cambios la tabla resultante
se debe ver de la siguiente forma

Figura 17: Tabla de Customer implementada con manejo de cambios

4.2. Tipo 3
Para implementar el tipo 3, toca generar una nueva columna que indique el atributo
justamente anterior. Para esto, se modificó nuevamente el SQL que permite crear la tabla
customer con el fin de almacenar una fila extra llamada prev category [1]

10
Figura 18: Creación de la tabla customer historia tipo3, con el fin de realizar el manejo
de historia para la dimensión

Asimismo, se implementó una tabla customer temp donde se almacenan los datos para
ser preprocesados. Respecto a la transformación, se generaron 3 en bloque, con el fin de
respetar el orden en que se ejecutan los nodos. (Una transformación respeta el órden
solamente si el nodo requiere del output del anterior para funcionar. Por lo tanto, el flujo
es mejor manejarlo directamente desde el Job)

Figura 19: Sentencia usada para la creación de la tabla customer temp

Figura 20: Flujo para conseguir el manejo de historia tipo 3

En transformacion customer hay un nodo para leer el CSV y subir la información a

la tabla temporal

11
Figura 21: Flujo en transformacion customer que permite leer y subir la informa-
ción a la tabla temporal.

En transformacion customer2 únicamente hay un nodo que crea una tabla a partir
del resultado de unir la tabla temporal y lo que hay actualmente en customer historia tipo3.
El resultado guarda la la columna categorı́a de customer historia tipo3 en prev category.
A continuación, se puede ver la sentencia usada en este caso

Figura 22: Creación de la tabla Customer join la cual almacena la información de unir
la información entrante con la información en la base de datos.

Por último, en transformacion customer3 hay un nodo que permite leer la informa-
ción en Customer join y la sube a la tabla definitiva con un nodo insert/update

Figura 23: transformacion customer3 donde se suben los datos a la tabla final

Finalmente, se eliminan las tablas auxiliares usadas. De esta forma, se debe llegar a lo
siguiente:

Figura 24: Tabla final al implementar la estructura tipo 3

12
4.3. Tipo 6
Por su lado, el manejo tipo 6 es una combinación de los tipos 1, 2 y 3. Por lo tanto,
fue posible reusar el flujo previamente hecho para el Tipo 3. Aún ası́, se hicieron
unas pequeñas modificaciones. En primer lugar, se crearon nuevas columnas para
la tabla customer. Estas consisten en: prev category, date from, date to, version y
tk customer [1]

Figura 25: Sentencia usada para el manejo tipo 6

A continuación, se creó una tabla temporal. En esta tabla temporal se almacenaron los
datos entrantes para realizar un join con los datos que hay actualmente. Posteriormente,
lo que hay en este join se almacenó en la tabla definitiva. Esta vez, con el fin de manejar
el tiempo, no se usó un insert/update si no que dimension lookup/update

Figura 26: transformacion customer3 donde se suben los datos a la tabla final

De esta forma, al hacer una consulta a la tabla se debe ver de la siguiente forma

Figura 27: Tabla final al implementar la estructura tipo 6

4.4. Comparación
En general, seleccionar el tipo de manejo de historia depende de las necesidades del
cliente, además del contexto que dictan los datos. Por ejemplo, si hay datos que cambian
mucho con el tiempo, no serı́a recomendable hacer uso del tipo 2, pues consumirı́a
mucho espacio. Por el contrario, si se quiere hacer un análisis que tenga en cuenta el
tiempo, usar el tipo 3 tampoco serı́a recomendable.
En este caso, dada la cantidad de datos, es posible hacer uso del tipo 2 o 6. Estos tienen
la ventaja de que es posible hacer un análisis temporal del atributo en cuestión. En

13
cuanto a estos dos tipos, el 6 es el más completo, pues para cada atributo en la tabla de
hechos es posible conocer el estado actual de la dimensión, y el estado en el periodo de
tiempo en que se realizó esta transición. Aún ası́, no se me ocurren posibles análisis que
tengan en cuenta el valor actual del atributo. [1]
De esta forma, la mejor opción para el manejo temporal en este caso es el tipo 2. Esto
dada la cantidad de datos, además de permitir un análisis más completo posteriormente
según las necesidades del cliente. Asimismo, también es el que más fácil se puede
implementar en Pentaho, por lo que también habrı́a un menor tiempo de implementación
en el ETL para realizar posteriormente el análisis requerido por el cliente.

5. Big Query
Desafortunadamente, para el caso de Big Query, no me fue posible realizar el trabajo,
pues encontré la herramienta poco intuitiva para trabajar. Esto a pesar de intentar varias
veces realizar el procedimiento pedido, además de hacer búsquedas en internet que me
guiaran en el tema. Aún ası́, mi idea era cargar los datos a una tabla provisional, donde
habrı́a un atributo fecha inicio y fecha fin cuyos valores por defecto serı́an 1900 y 2199,
además de la llave subrogada y un número de versión. Luego, se actualizarı́an los datos
que se encuentran actualmente en la tabla con el fin de que su fecha fin fuera el dı́a de
hoy. Posteriormente, se suben los nuevos datos a la base de datos. Aún ası́, solamente
logré subir los datos a la tabla temporal, pues no supe como crear una nueva columna
como lo deseaba. A continuación, muestro imágenes del proceso que intenté seguir:

Figura 28: Creación de la tabla temporal para almacenar los nuevos datos

14
Figura 29: Creación de los nuevos atributos, los cuales bloqueaban mi acceso a Big-
Query y no me dejaban avanzar. La idea era generar estas columnas para posteriormente
usarlas en el manejo de cambios.

6. Preguntas
6.1. ¿Cual es el objeitvo de la columna tk stock item?
Esta llave corresponderá a la llave primaria de la tabla. Debido al manejo del cambio,
la llave otorgada en la fuente de datos original (archivo csv) ya no es única, por lo que
no puede funcionar como llave primaria. Por lo tanto Pentaho otorga una llave única a
cada entrada de la tabla con el fin de identificar correctamente una fila en la tabla de
hechos.
6.2. ¿Qué significa cada una de las opciones en el campo Type of
dimension update?
Insert: Es una opción que permite manejar el cambio tipo 2. En este caso, cuando
un cambio es detectado, se genera una nueva fila en la dimensión.
Update: Esta opción permite manejar el cambio tipo 1. En este caso, al detectar
un cambio en la dimensión, simplemente actualiza el valor en lugar de crear una
nueva fila.
Punch through: Esta opción también actualiza una fila en la tabla. En lugar de
actualizar una única fila, actualiza todas las versiones que hay en los cambios tipo
2.
Date of last insert or update: Permite que, automaticamente se maneje una
columna de fecha donde se mantiene registro del dı́a donde se inserta o actualiza
el dato.
Date of last insert: Esto permite que se maneje automáticamente una columna
que indica cuando fue la última vez que se insertaron datos a la tabla.
Date of last update: Esto permite que se maneje automáticamente una columna
que indica cuando fue la última vez que se actualizaron datos en la tabla.

15
 Last version: Permite tener información en una fila que permite conocer cual es
la última versión del dato en la tabla. [2]

6.3. ¿Cómo se puede saber que el proceso ETL manejó los cambios
entre los dos archivos?
La forma de saber si el ETL manejo correctamente los cambios entre los archivos
es ver los atributos de date from y date to. En caso de haber sido actualizados
correctamente, la fecha date from de los datos entrantes debe corresponder al dı́a
donde se realiza el cambio. Por el contrario, la fecha date to de los datos antiguos se
cambiara por la fecha del dı́a donde se realiza el cambio.
6.4. ¿Por qué se debe hacer el cambio para que la columna de la
llave subrogada sea de tipo Unique?
En primer lugar, cabe aclarar que la columna de la llave subrogada es la nueva llave
primaria en el modelo dimensional. Uno de los atributos de una llave primaria es que
sea única. Asimismo, al querer hacer una referencia a esta columna desde la tabla de
hechos, es necesario la llave foranea haga referencia a un único elemento de la tabla de
dimensión. Esta es la forma en que es posible decirle a Postgres que esta tabla es única,
y por lo tanto puede ser referenciada. [3]
6.5. ¿Qué pasa si uno de los datos reportados en la tabla de hechos
no existe en alguna de las dimensiones?¿Qué sugiere para evi-
tar esa situación?
En caso de que una dimensión en la tabla de hechos no exista, esto va a causar un
problema. Esto debido a que para añadir el campo de un Foreign Key es necesario que
la este valor se encuentre en un único dato de la columna que está siendo referenciada.
De esta forma, en caso de no encontrar el dato en la tabla de hechos Postgre mostrará
un error. Para solucionar esto, se puede usar en la sentencia INSERT el atributo on ON
CONFLICT DO NOTHING el cual dice que, en caso de haber un error, no haga nada.

7. Conclusión
En general, encontré más fácil el proceso en Pentaho, pues el sistema de nodos me
ayudó a guiarme en el proceso que seguı́an los datos para se actualizados. Por su lado,
BigQuery al requerir conocimiento en el SQL para realizar el ETL me parece que es
una herramienta más compleja de usar. Aún ası́, BigQuery tiene la ventaja de ser un
software en la nube.
Creo que, en cuanto a facilidad, Pentaho es mucho mejor, pues, como se vió en el
laboratorio, con esta herramienta fue con la que pude realizar el ETL, mientras que con
BigQuery se me complicó al punto de no alcanzar a realizar el ETL para la entrega del
laboratorio. Es por eso que, en lo personal, Pentaho me parece una mejor herramienta a
usar. En especial si uno no tiene conocimientos profundos en el lenguaje SQL.

Referencias
[1] Ralph Kimball and Margy Ross. The data warehouse toolkit.

16
[2] 2021.
[3] Silvia Cai. Handle slowly changing dimensions with pentaho kettle – part1 -
perficient blogs, 2021.

17