Bases de datos relacionales

Resumen

Una base de datos relacional organiza información en tablas compuestas por filas y columnas. Cada tabla representa una entidad o relación del sistema —usuarios, pedidos, pagos, productos— y las conexiones entre tablas se expresan con claves primarias, claves foráneas, constraints y joins.

Importa porque muchas aplicaciones necesitan consistencia fuerte, consultas estructuradas y reglas de integridad. Si un pago pertenece a un pedido, si un email debe ser único o si una compra debe guardarse completa o no guardarse, una base relacional ofrece mecanismos maduros para hacer cumplir esas reglas cerca de los datos.

Alcance y supuestos

Este paquete cubre bases de datos relacionales a nivel conceptual: tablas, filas, columnas, claves, constraints, joins, índices, SQL, transacciones y propiedades ACID.

No cubre un tutorial completo de SQL, diseño físico de almacenamiento, query planners, replicación, sharding, locks avanzados ni consenso distribuido. Asume que entiendes datos de aplicación, CRUD, APIs y que una app necesita persistir información entre requests.

Modelo mental

Piensa en una oficina con archivadores muy ordenados. Hay un archivador para clientes, otro para pedidos y otro para pagos. Cada ficha tiene un identificador único, y algunas fichas apuntan a otras: un pedido apunta al cliente que lo hizo; un pago apunta al pedido que pagó.

La base relacional no solo guarda papeles. También impone reglas: no puedes registrar un pago para un pedido inexistente, no puedes duplicar un email si existe una constraint única, y puedes consultar fichas relacionadas sin copiar todo en cada lugar.

La idea central es separar datos en estructuras claras y relacionarlas explícitamente. Eso permite consultar, validar y evolucionar el sistema sin convertir cada objeto en un documento gigante duplicado.

Uso práctico

Usa una base de datos relacional cuando tu problema necesita estructura, relaciones y consistencia:

• ✅ Pedidos, pagos, usuarios, permisos, inventario, facturación y auditoría.
• ✅ Consultas con filtros, agregaciones, joins y reportes sobre datos estructurados.
• ✅ Reglas fuertes como uniqueness, foreign keys, NOT NULL y transacciones.
• ❌ No es la mejor herramienta primaria para búsqueda semántica por significado; ahí una base vectorial puede complementar.
• ❌ No arregla un modelo de datos mal pensado: una tabla puede expresar bien o mal el dominio.

Ejemplo trabajado: proteger pedidos y pagos con claves

Supón que una aplicación registra pedidos y pagos. Sin relaciones explícitas, podrías guardar IDs sueltos y confiar en que la app no se equivoque. Una base relacional permite declarar la regla en el esquema:

CREATE TABLE customers (
  id UUID PRIMARY KEY,
  email TEXT NOT NULL UNIQUE
);

CREATE TABLE orders (
  id UUID PRIMARY KEY,
  customer_id UUID NOT NULL REFERENCES customers(id),
  total_cents INTEGER NOT NULL CHECK (total_cents > 0)
);

CREATE TABLE payments (
  id UUID PRIMARY KEY,
  order_id UUID NOT NULL REFERENCES orders(id),
  amount_cents INTEGER NOT NULL CHECK (amount_cents > 0)
);

Ese esquema dice varias cosas importantes:

• customers.id, orders.id y payments.id identifican filas de forma estable.
• orders.customer_id no puede apuntar a un cliente inexistente.
• payments.order_id no puede apuntar a un pedido inexistente.
• email no puede repetirse.
• total_cents y amount_cents no pueden ser cero o negativos.

Después puedes consultar datos relacionados:

SELECT
  customers.email,
  orders.id AS order_id,
  payments.amount_cents
FROM orders
JOIN customers ON customers.id = orders.customer_id
JOIN payments ON payments.order_id = orders.id
WHERE customers.email = 'felipe@example.com';

La app sigue teniendo lógica de negocio, pero la base protege invariantes fundamentales. Si dos procesos intentan escribir datos al mismo tiempo, las constraints y transacciones ayudan a evitar estados corruptos.

Antes de elegir o diseñar una base relacional, revisa cinco preguntas:

1. ¿Qué entidades existen y qué relación tienen entre sí?
2. ¿Qué invariantes deben cumplirse incluso si hay bugs o concurrencia?
3. ¿Qué consultas serán frecuentes y qué índices necesitan?
4. ¿Qué operaciones deben ser transaccionales?
5. ¿Qué datos pertenecen al modelo relacional y cuáles conviene llevar a búsqueda, cache o vector store?

Una base relacional brilla cuando los datos tienen forma, reglas y relaciones importantes. No compite con todas las bases; suele ser el sistema de registro que otras piezas complementan.

Evidencia

• IBM Think, What is a Relational Database? define una base relacional como un tipo de base que organiza datos en filas y columnas formando tablas relacionadas.
• Oracle Database Concepts, Introduction to Oracle Database describe una tabla como una representación bidimensional de una relación en filas y columnas.
• PostgreSQL documentation, Constraints explica que SQL permite definir constraints en columnas y tablas para controlar la integridad de los datos.