La carga de la tabla de hechos es el paso donde conectas todas las dimensiones de tu Data Warehouse para registrar métricas reales del negocio. Si ya construiste tus dimensiones con Pentaho, este flujo te muestra cómo unirlas para almacenar ventas, cantidades y descuentos con trazabilidad histórica.

¿Cómo se cargan dimensiones pequeñas como territorios y productos?

Cuando el volumen de datos es bajo, no necesitas pasar por un archivo intermedio en S3. Redshift acepta sin problema un insert directo desde Pentaho.

Para la dimensión de territorios el flujo replica el de clientes: lees el input SQL, haces lookup, agregas un campo de fecha de ejecución del ETL, validas si el registro es nuevo y generas un ID consecutivo [00:30]. La diferencia está en la salida: en lugar de un output a S3, configuras un output de tabla, identificas los campos manualmente y listas los que vas a insertar.

¿Cuándo conviene insertar directo a Redshift en vez de usar S3 + COPY? Cuando la tabla es pequeña, como territorios o productos. Para volúmenes altos, sigue siendo mejor cargar un CSV a S3 y ejecutar un copy.

El flujo de productos es idéntico al de territorios. Misma lógica, misma salida directa a tabla.

¿Cómo construir una dimensión tipo 2 de vendedores en Pentaho?

Aunque parezca compleja por ser lentamente cambiante tipo 2, la dimensión de vendedores es probablemente la más sencilla, porque Pentaho tiene un step que automatiza el versionado.

El flujo arranca con el input de los datos de vendedores. Seleccionas y renombras los campos directamente en el step (otra forma de transformar nombres sin tocar el SQL), aplicas reglas de negocio como reemplazar M y F por masculino y femenino, tomas la fecha del sistema y entras al step clave: Dimension Lookup/Update [02:30].

La configuración funciona así:

• Conexión a la tabla destino en el Data Warehouse.
• Búsqueda por el código del vendedor.
• Definición del ID del vendedor como llave subrogada.
• Llave de vigencia con fecha de inicio mínima en 1900 y fecha fin máxima en 9999.

El registro con año 9999 indica el registro vigente. Cuando un vendedor cambia, Pentaho cierra el registro anterior y abre uno nuevo automáticamente.

¿Cómo se genera la dimensión de tiempo sin una fuente de datos?

La dimensión de tiempo no tiene origen en el transaccional, así que la generas desde cero con el step Generate Rows [03:45].

Los pasos son:

1. Generas 2000 registros con un campo date base en formato entero año-mes-día.
2. Agregas una secuencia que parte en cero y suma de uno en uno a una variable llamada días suma.
3. Calculas el ID de la fecha sumando la fecha base más los días de la iteración.
4. Haces una copia del campo y extraes día, mes, año, día de la semana y día del año.
5. Cargas todo a la tabla de tiempos en formato entero.

El resultado es una dimensión completa con 2000 fechas listas para cruzar con cualquier hecho.

¿Cómo se cruzan las dimensiones para cargar la tabla de hechos?

La tabla fact de ventas guarda indicadores (cantidad, valor vendido, descuento) y atributos que apuntan a las dimensiones (producto, vendedor, cliente, territorio, fecha).

Desde el SQL transaccional traes la factura, el detalle, la fecha, el territorio, el cliente, el vendedor y el producto. Aprovechas la query para calcular operaciones como cantidad por unidad vendida y descuento por cantidad, así reduces transformaciones posteriores en Pentaho.

¿Qué debe contener una tabla de hechos? Solo IDs y métricas numéricas. Nunca códigos operativos ni varchar, salvo que sean datos de consulta puntual que no se usen para cruces.

El flujo en Pentaho replica el de las dimensiones: input, fecha de carga, validación de registro nuevo, consecutivo y salida a S3 o update. Lo que cambia es que ahora cruzas contra cada dimensión para resolver los IDs.

¿Cómo resolver el ID de un vendedor en una dimensión tipo 2?

Usas el step Database Lookup validando dos condiciones [05:30]:

• Que el código del vendedor coincida.
• Que la fecha de la venta esté entre la fecha de inicio y fin de vigencia del registro.

Esto evita asignar un registro desactualizado. Si un vendedor era cajero cuando hizo la venta y hoy es administrador, recuperas el ID que tenía en ese momento histórico. Si el cruce no encuentra registro, asignas un -1 por defecto para reportar la inconsistencia.

¿Cómo se cruzan las demás dimensiones?

El patrón se repite con cada dimensión:

• Fechas: cruzas la fecha de la venta con la fecha de la dimensión de tiempo y obtienes el ID.
• Territorios: cruzas por código de territorio.
• Clientes: cruzas por código de cliente.
• Productos: cruzas por código de producto.
• Fact: cruzas por las llaves únicas de la factura para identificar si la venta ya existe.

En cada caso, si el cruce devuelve nulo, fuerzas un -1. Así detectas faltantes en las dimensiones antes de que contaminen los reportes.

¿Qué sigue después de cargar dimensiones y hechos?

Con dimensiones y fact cargadas, ya tienes un Data Warehouse funcional. Lo que falta es orquestar la ejecución: definir el orden de los procesos, qué corre primero, qué depende de qué y cómo se programa todo en Pentaho.

¿Qué reglas de negocio aplicarías tú al cruzar dimensiones tipo 2 en tu propio modelo? Cuéntalo en los comentarios.