El sagrado CRUD (Create, Read, Update, Delete). Ha sido mi pan de cada día.

Sin embargo, las cosas se rompen cuando una empresa crece y piden "un reporte de ventas cruzado por zona geográfica y familia de producto de los últimos tres años".

La semana pasada, ingenuo de mí, lancé un SELECT con nosecuentos JOINs y varios GROUP BY directamente contra la base de datos de producción (OLTP). ¿El resultado? El sistema se bloqueó por completo durante diez minutos. Ha llegado el momento de aceptar que los sistemas transaccionales no sirven para la analítica. Bienvenidos al mundo del Business Intelligence (BI).

Del OLTP al OLAP: Un cambio de mentalidad

El problema fundamental es que una base de datos diseñada para capturar transacciones rápidas (OLTP) está altamente normalizada (para evitar redundancias) y optimizada para la escritura. Pero cuando quieres analizar tendencias (OLAP), necesitas leer millones de registros históricos.

La solución que estoy implementando pasa por montar un Data Warehouse: una base de datos separada, actualizada de madrugada mediante un proceso ETL (Extracción, Transformación y Carga).

Ensuciándonos las manos: Un mini-ETL artesanal

En lugar de instalar suites pesadísimas como Pentaho o Informatica, he empezado a orquestar un proceso ETL básico usando scripts SQL que se ejecutan vía cron.

La idea es desnormalizar los datos transaccionales y cargarlos en una "Tabla de Hechos" mucho más ancha y optimizada para lectura rápida.

-- 1. EXTRACCIÓN Y TRANSFORMACIÓN (Entorno Staging)
-- Juntamos los datos de múltiples tablas transaccionales normalizadas
CREATE TEMPORARY TABLE temp_ventas_transformadas AS
SELECT 
    v.id_venta,
    v.fecha,
    c.region_comercial,
    p.categoria_producto,
    v.cantidad * p.precio_unitario AS importe_total
FROM db_transaccional.ventas v
JOIN db_transaccional.clientes c ON v.id_cliente = c.id_cliente
JOIN db_transaccional.productos p ON v.id_producto = p.id_producto
WHERE v.fecha >= DATE_SUB(CURDATE(), INTERVAL 1 DAY);

-- 2. CARGA (Data Warehouse)
-- Insertamos los datos en nuestra tabla desnormalizada de analítica
INSERT INTO db_analitica.fact_ventas_diarias (
    id_venta, 
    fecha_sk, -- Surrogate key de tiempo
    region, 
    categoria, 
    importe
)
SELECT 
    id_venta,
    REPLACE(CAST(fecha AS CHAR), '-', ''), -- Formato YYYYMMDD para dimensión tiempo
    region_comercial,
    categoria_producto,
    importe_total
FROM temp_ventas_transformadas;

Ahora, cuando se necesita el informe, la consulta ataca directamente a db_analitica.fact_ventas_diarias. Los reportes que antes tumbaban el servidor en diez minutos, ahora se ejecutan en dos segundos.

Reflexión: El oro está en los datos

Pasar de programar interfaces para meter datos a diseñar arquitecturas para entender esos datos me ha volado la cabeza. El BI parece magia negra para los directivos, pero en el fondo, es pura ingeniería de datos y modelado inteligente.

Creo firmemente que el Business Intelligence va a dejar de ser un lujo de las empresas del Fortune 500. Con bases de datos open source cada vez más potentes, cualquier PYME va a empezar a exigir sus propios Data Warehouses. El futuro está en saber qué hacer con los terabytes de información que estamos acumulando. Dejad Java y empezad a estudiar BI.