Las bases de datos están detrás de prácticamente cualquier decisión que se toma hoy en un negocio. Bien pensadas o mal pensadas, dependiendo de quién las diseñó. Entender esa diferencia es lo que separa a las empresas que toman decisiones con confianza de las que pierden horas buscando errores en hojas de cálculo.

¿Por qué Excel deja de funcionar cuando el negocio crece?

Excel es una herramienta brillante. Nació para hacer cálculos, organizar información y explorar datos rápido. Para eso es inmejorable. El problema aparece cuando un negocio crece y empieza a usarlo para algo que no es su dominio [0:27].

Piensa en una bodega de supermercado donde alguien tiró cincuenta mil productos en el piso, sin estantes, sin etiquetas, sin orden. Si necesitas encontrar algo específico, vas a tardar horas. Eso es Excel con datos masivos: antes de dejarte hacer cualquier cosa, carga todo en memoria [1:07]. Cada fila, cada celda, cada fórmula.

Una base de datos tiene índices —como los estantes numerados de esa bodega— que le dicen exactamente dónde buscar. El resultado es milisegundos en lugar de minutos [1:17].

¿Cuáles son los tres problemas que resuelve una base de datos?

• Rendimiento: búsquedas rápidas gracias a índices, sin cargar todo en memoria.
• Concurrencia: cientos de usuarios simultáneos sin que se pisen entre sí, mientras que Excel se corrompe cuando dos personas editan al mismo tiempo [0:36].
• Integridad: reglas que impiden inconsistencias como escribir "Colombia" con mayúscula y "colombia" con minúscula, que para Excel son dos cosas distintas pero para el negocio son el mismo país [1:47].

Estos no son bugs ni errores de uso. Son límites de diseño [2:07]. Y son exactamente los tres problemas que una base de datos relacional resuelve.

Cuando una empresa empieza a tratar sus datos como un activo, la primera cosa que cambia es simple: todos trabajan con la misma información. No hay cinco versiones del mismo reporte circulando por correos o chats. Hay una sola fuente de verdad, y todos la ven igual [2:28].

¿Qué diferencia hay entre OLTP y OLAP?

Existen dos mundos que es necesario conocer. El primero se llama OLTP (Online Transaction Processing), que significa procesamiento de transacciones en línea [3:08]. Piensa en un cajero automático: metes la tarjeta, pides dinero, el sistema consulta tu saldo, deduce el monto y entrega los billetes. Todo en fracciones de segundo.

¿Qué pasa si algo falla a mitad del proceso?

Aquí entran las propiedades ACID [5:31], que son las garantías de que tu dinero está seguro:

• Atomicidad: o la operación se completa entera, o no pasa nada. Si los billetes no salen, la deducción se revierte automáticamente [5:33].
• Consistencia: después de cada transacción, la base queda en un estado válido [5:44].
• Aislamiento: cada transacción trabaja como si fuera la única. Si quedan cinco unidades y dos clientes piden tres al mismo tiempo, el sistema pone a uno en fila para no vender más de lo que hay [5:52].
• Durabilidad: una vez confirmada la transacción, queda grabada aunque se corte la luz un segundo después [6:26].

Las claves primarias aseguran que cada pedido sea único. Las claves foráneas impiden crear un pedido para un cliente que no existe. Y la normalización evita que tengas que actualizar la dirección del cliente en quinientos registros diferentes [4:53]. Un solo lugar, una sola verdad.

¿Cómo funciona OLAP para las decisiones estratégicas?

El segundo mundo es OLAP (Online Analytical Processing), procesamiento analítico en línea [6:38]. Si OLTP registra lo que pasa ahora, OLAP analiza lo que ya pasó.

Imagina que la gerencia pregunta: ¿cuáles fueron los diez productos más vendidos por región en toda Latinoamérica en los últimos dos años? Esa consulta necesita barrer millones de filas, agrupar, sumar, promediar. Puede tomar quince segundos, y está bien, porque el gerente puede esperar por un reporte que informa decisiones estratégicas [6:56].

OLAP no sigue las reglas de normalización estricta. Al contrario, usa desnormalización deliberada [7:16]. A veces se repite el nombre del producto un millón de veces en la misma tabla, porque si cada consulta analítica tiene que unir diez tablas normalizadas, se vuelve muy lento. La redundancia, que en OLTP es un problema, en OLAP es una estrategia.

Esto se organiza en un esquema de estrella: una tabla central de hechos conectada a tablas de dimensiones como productos, clientes y períodos de tiempo [5:34]. Netflix y Spotify usan exactamente este enfoque para analizar historiales masivos y deducir qué recomendarte [6:42].

¿Cómo conectan OLTP y OLAP en la práctica?

Durante el día, el sistema OLTP captura todo lo que pasa: cada venta, cada pedido, cada actualización de stock. De noche, un proceso toma esos datos, los limpia, los organiza y los carga en el sistema de análisis donde vive el OLAP. Ese proceso se llama ETL (Extracción, Transformación y Carga) [7:16].

La calidad del análisis depende directamente de la calidad de los datos de origen. Si el OLTP tiene datos sucios, esa suciedad llega hasta los dashboards ejecutivos [7:29]. Los reportes reflejan lo que hay debajo. Siempre.

Por eso construir bien el OLTP no es solo un ejercicio técnico. Es la base de todo lo que viene después. Si puedes pensar en un ejemplo real de tu trabajo donde la falta de estas restricciones haya generado pedidos fantasma, clientes duplicados o datos inconsistentes, ya estás entendiendo por qué esto importa. Comparte tu experiencia y reflexiona sobre qué tipo de consultas —OLTP u OLAP— son las que más necesita tu equipo.