Taller_​DateTime_​InDatabase_​Laura y Licie_​v2

Taller: Métodos de optimización de flujos de trabajo en KNIME

Procesamiento De Datos Date&Time Tecnicas de agregación de Datos in-database

 Estudiantes: Licie Balcazar, Laura Pérez y Aduy García

• Programa: Maestría en Ciencia de Datos

• Universidad: Universidad Autónoma de Bucaramanga (UNAB)

• Asignatura: Analisis De Datos Basadas En Flujos De Trabajo

• Fecha de entrega: 20 de Octubre de 2026

Objetivo: Practicar el manejo de datos Date&Time y comparar la agregación de ventas trimestrales hecha en memoria (KNIME) con la hecha dentro de la base de datos (in-database), y filtrar tiendas con un DB Joiner.

Entradas: Customer_data.xlsx (11.578 filas, 17 columnas; Date como texto yyyy-MM-dd, de 2018-01-04 a 2022-12-31) y database.mv.db (base H2). Ambos viajan en la carpeta data/ del workflow.

Salidas: tabla CustomerData escrita en H2; dos gráficos de áreas apiladas con las ventas trimestrales Online vs Onsite (en memoria e in-database) y la tabla de órdenes de las tiendas con ventas totales mayores a 6.000.

Fases: I. Date&Time en KNIME → II. Filtrado, pivoteo y ordenamiento in-database → III. DB GroupBy + DB Joiner.

Supuestos: el trimestre es el calendario (Q1 = ene–mar). El DB Writer reemplaza la tabla CustomerData en cada ejecución para que el flujo sea repetible. Las ventas son la suma de Price.

I. PROCESAMIENTO DATE&TIME (EN MEMORIA)

Excel Reader → String to Date&Time (Date a fecha) → Date&Time Part Extractor (Month, Quarter, Year) → Date&Time-based Row Filter (desde 01/01/2019, 11.236 filas) → Pivot (grupos Quarter y Year × StoreType, suma de Price, 16 trimestres; la salida queda ordenada por trimestre: 2019/1, 2020/1, 2021/1, 2022/1, 2019/2…) → Expression (QuarterAndYear) → Stacked Area Chart.

La agregación genera 16 periodos trimestrales. Al agrupar por Quarter en primer orden dentro del nodo Pivot, los datos se estructuran por trimestres homogéneos

(Q1 de todos los años, luego Q2, etc.), evidenciando la necesidad de un ordenamiento cronológico explícito para análisis de series de tiempo.

II. PROCESAMIENTO IN-DATABASE: FILTRADO, PIVOTEO Y ORDENAMIENTO (PUSHDOWN OPTIMIZATION EN H2)

H2 Connector → DB Writer (salida del Part Extractor como tabla CustomerData). DB Table Selector lee esa tabla (la conexión de variable desde el DB Writer garantiza que la tabla exista antes) → DB Row Filter (Year >= 2019) → DB Pivot (grupos Quarter y Year × StoreType, SUM(Price)) → DB Sorter (Year y luego Quarter, ascendente: orden cronológico) → DB Reader → Expression → Stacked Area Chart. Todo el cálculo ocurre en la base; KNIME solo recibe 16 filas.

En esta Fase II toda la carga computacional pesada (filtrado, pivoteo, agregación y ordenamiento) se delega directamente al motor SQL de la base de datos H2, el objetivo es el de

ejecutar las operaciones de filtrado, agregación y ordenamiento dentro del motor SQL H2 para optimizar la eficiencia computacional y reducir la transferencia de datos hacia KNIME.

La técnica de Pushdown Optimization minimiza la latencia I/O al reducir el volumen de transferencia de 11,236 filas a solo 16 filas consolidadas. Además, la adición explícita de

DB Sorter corrige la secuencia temporal de la visualización, reflejando la curva real de crecimiento del negocio a lo largo de los 16 trimestres.

III. FILTRADO Y UNIÓN DE TIENDAS IN-DATABASE (DB JOINER)

DB GroupBy (StoreID, SUM(Price)) → DB Row Filter (SUM(Price) > 6000: 67 de 130 tiendas) → DB Joiner inner por StoreID (izquierda: CustomerData, derecha: tiendas > 6000) → DB Reader: 7.197 órdenes.

El objetivo es filtrar el histórico transaccional completo conservando únicamente las órdenes pertenecientes a tiendas de alto volumen de ventas (Suma de Price > 6,000) mediante procesamiento nativo en SQL.

Combina la agregación de alto nivel con el detalle transaccional original. El nodo DB Reader actúa como el punto de extracción final que traslada las 7,197 órdenes seleccionadas desde el motor H2 hacia KNIME para su posterior análisis

¿SON IGUALES LAS DOS VISUALIZACIONES?

No se ven iguales, aunque los datos son los mismos. Las dos ramas producen los mismos 16 montos trimestrales (por ejemplo 2019/1: Online 3.925,02 y Onsite 8.524,53), pero en distinto orden:

• Rama I: el Pivot con grupos Quarter y Year ordena primero por trimestre (2019/1, 2020/1, 2021/1, 2022/1, 2019/2…). El eje horizontal no es cronológico y el gráfico sube y baja en "dientes de sierra".

• Rama II: el DB Sorter ordena por Year y luego por Quarter, así que el gráfico es cronológico y muestra la tendencia de crecimiento.

Lección: el orden de los grupos no garantiza un orden temporal; para series de tiempo hay que ordenar explícitamente. Otras diferencias menores: el DB Pivot entrega las columnas Onsite, Online (colores invertidos) y H2 suma en decimal exacto frente a la doble precisión de KNIME. Ordenadas y redondeadas a 2 decimales, el Table Difference Finder (sección IV) no encuentra ninguna diferencia de valores.

Ojo con los colores: en el gráfico I el azul es Online y el verde Onsite; en el gráfico II es al revés (azul Onsite, verde Online), porque el DB Pivot entrega las columnas en otro orden. Los valores de cada canal son los mismos.

HALLAZGOS

• Crecimiento Anual: Las ventas crecen cada año: 51.322 (2019) → 89.454 (2020) → 198.693 (2021) → 422.606 (2022).

• Participación por canal: Onsite concentra el 60,5 % de las ventas desde 2019 y Online el 39,5 %.

• Extremos Temporales: Trimestre más alto: 2022/1 (111.562); más bajo: 2019/3 (12.141).

• Concentración de Tiendas: Las 67 tiendas con ventas > 6.000 explican el 62,3 % de las ventas totales; la mayor es Store_2369 (9.864).

• Alcance del flujo: Proceso exclusivo de preparación, agregación y conciliación de datos (ETL/ELT), sin modelos predictivos de Machine Learning.

IV. COMPROBACIÓN FORMAL Y DASHBOARD

Sorter ordena la rama I por Year y Quarter (igual que el DB Sorter) y Expression redondea Online/Onsite a 2 decimales en ambas ramas → Table Difference Finder compara la rama II contra la rama I (0 filas = valores iguales). El componente Dashboard comparativo muestra los dos gráficos lado a lado (la rama I tal como sale del Pivot, para ver la diferencia de orden), el conteo de diferencias, y los hallazgos y conclusiones: clic derecho → Open view.

El objetivo es auditar la equivalencia numérica entre el procesamiento en memoria (Rama I) y la optimización in-database (Rama II), consolidando los hallazgos en un tablero ejecutivo interactivo.