Bases de datos: conceptos, SQL y diseño

Las bases de datos son sistemas organizados para almacenar, consultar y proteger información. Permiten que aplicaciones y analistas trabajen con datos de forma confiable, desde un inventario hasta el historial de transacciones de un banco.

¿Qué es una base de datos y para qué sirve?

Una base de datos (BD) es un conjunto de datos relacionados, administrado por un Sistema de Gestión de Bases de Datos (SGBD/DBMS). Su objetivo: registrar, consultar, actualizar y asegurar datos con eficiencia y control de concurrencia.

Diferencia entre archivos y sistemas de bases de datos

• Archivos planos: sin esquema formal; difícil mantener integridad, duplicidad alta.
• BD con SGBD: esquema explícito, consultas declarativas (SQL), transacciones, seguridad, backups y recuperación.

Casos de uso comunes

• E-commerce (productos, pedidos, pagos).
• Apps móviles (usuarios, sesiones, eventos).
• BI/analítica (reportes, tableros, KPIs).
• IoT/logs (telemetría, auditoría).

Modelo relacional en 10 minutos

El modelo relacional es la base de cualquier sistema de gestión de bases de datos moderno. En solo diez minutos puedes diseñar una estructura sólida que conecte tus entidades de forma lógica y coherente.

Primero, identifica las entidades principales (como clientes, productos o transacciones) y define sus atributos más relevantes. Luego, establece las relaciones entre ellas —uno a muchos, muchos a muchos o uno a uno— para reflejar cómo interactúan en el mundo real.

Finalmente, usa herramientas visuales como MermaidChart para transformar estas conexiones en un diagrama relacional claro y visual, ideal para documentar y comunicar la arquitectura de datos en tus proyectos. Obtén un 10% de descuento durante 12 meses en Mermaid Chart.

Tablas, tuplas, dominios y claves

• Dominio: tipo/validez del dato (p. ej., INTEGER, DATE).
• Clave primaria (PK): identifica de forma única una fila.
• Clave foránea (FK): referencia una PK de otra tabla, garantizando integridad referencial.

Esquema vs. instancia; diagramas de esquema

• Esquema: definición estática (CREATE TABLE).
• Instancia: datos en un momento dado.
• Diagramas: comunican entidades y relaciones (1:1, 1:N, N:M).

SQL esencial para consultas y definición

SQL es declarativo: indicas qué datos quieres, no cómo obtenerlos.

-- Productos con su categoría
SELECT p.id, p.nombre, c.nombre AS categoria
FROM productos p
JOIN categorias c ON c.id = p.categoria_id
WHERE p.activo = TRUE
ORDER BY p.nombre;

SELECT nombre
FROM productos
WHERE precio > (SELECT AVG(precio) FROM productos);

CREATE TABLE clientes (
  id SERIAL PRIMARY KEY,
  nombre VARCHAR(120) NOT NULL,
  email TEXT UNIQUE,
  creado_en TIMESTAMP DEFAULT NOW()
);

CREATE VIEW v_clientes_activos AS
SELECT id, nombre, email FROM clientes WHERE email IS NOT NULL;

SELECT categoria_id, COUNT(*) AS total, AVG(precio) AS precio_prom
FROM productos
GROUP BY categoria_id
HAVING COUNT(*) >= 10;

• NULL: “dato desconocido/ausente”. Usa IS NULL/IS NOT NULL.
• UNION/INTERSECT/EXCEPT: combinan resultados (compatibles en columnas/tipos).

Diseño lógico: E-R y normalización

Un buen diseño reduce duplicidad y anomalías de actualización.

Entidades, relaciones y cardinalidades

• Entidad: objeto del dominio (Cliente, Pedido).
• Relación: cómo interactúan (Cliente realiza Pedido).
• Cardinalidad: 1:1, 1:N, N:M (esta última suele requerir tabla intermedia).

1FN, 2FN, 3FN y BCNF con ejemplos

• 1FN: valores atómicos (no listas en una celda).
• 2FN: sin dependencias parciales en PK compuesta.
• 3FN: sin dependencias transitivas (atributos → solo dependen de la PK).
• BCNF: versión más estricta de 3FN.

Ejemplo simple (evitar dependencias transitivas):

• Tabla mala: Pedido(id, cliente_id, cliente_email, total)
cliente_email depende de cliente_id, no de id directamente.
• Mejor: Cliente(id, email, ...) y Pedido(id, cliente_id, total).

Almacenamiento físico e índices

Los índices aceleran búsquedas a costa de espacio y costo de escritura.

B+-trees y hashing

• B+-tree: eficiente en rangos/ordenamientos; hojas enlazadas.
• Hash: muy rápido para igualdad, no para rangos.

Índices optimizados para escritura (LSM) y por columnas

• LSM-tree: ingesta alta (merge por niveles); ideal para escrituras masivas.
• Columnar: almacena por columna; excelente para analítica/scan y compresión.

Procesamiento y optimización de consultas

El optimizador elige un plan con costo estimado (estadísticas, selectividad).

Costos, planes y estadísticas

• Manten estadísticas actualizadas (ANALYZE/auto-stats).
• Observa el plan (EXPLAIN/EXPLAIN ANALYZE) para detectar cuellos de botella.

Joins, ordenamientos y materialización

• El motor combina operadores (Nested Loop/Hash Join/Merge Join) y decide usar índices, ordenar o materializar subconsultas según el costo.

Transacciones y confiabilidad (ACID)

• Atomicidad: todo o nada.
• Consistencia: reglas/constraints siempre válidas.
• Aislamiento: transacciones no se pisan.
• Durabilidad: cambios persisten tras confirmar.

Aislamiento, niveles y concurrencia

Niveles típicos: READ COMMITTED, REPEATABLE READ, SERIALIZABLE.
Problemas: lecturas sucias, no repetibles, fantasmas.
Técnicas: bloqueo, MVCC, timestamp ordering.

Recuperación ante fallos y journaling

Principios: write-ahead logging (WAL), checkpoints y replay del log para recuperar estado consistente.

Paralelas, distribuidas y en la nube

Escala horizontal para alto volumen/latencia global.

Particionamiento, replicación y consenso (2PC, Raft)

• Particionamiento (sharding): divide datos por rango/hash.
• Replicación: alta disponibilidad/lecturas; síncrona vs asíncrona.
• 2PC: coordina commits entre nodos.
• Raft/Paxos: consenso para líderes y logs replicados.

Consistencia y disponibilidad (visión general)

• Compromisos entre latencia y consistencia percibida (consistencia fuerte vs eventual).

Big Data y analítica

MapReduce, Spark y streaming

• MapReduce: divide/combina tareas lote.
• Spark: memoria distribuida, APIs de alto nivel (SQL, ML).
• Streaming: ingesta continua (ventanas, estado, latencia baja).

OLAP, data warehousing y minería de datos

• OLTP vs OLAP: transaccional vs analítico.
• Data warehouse: modelo en estrella, tablas de hechos y dimensiones.
• Minería de datos: patrones, segmentación, predicción.

Tendencias: blockchain y contratos inteligentes (visión DB)

• Libro mayor inmutable, consenso distribuido, smart contracts.
• Casos: trazabilidad, tokenización y liquidación.

Buenas prácticas, errores comunes y checklist

Buenas prácticas

• Diseña con E-R y normaliza hasta 3FN (o BCNF si aplica).
• Índices alineados a consultas críticas (filtros, JOINs, ORDER BY).
• Automatiza backups, verificación y pruebas de recuperación.
• Observabilidad: métricas, logs, planes y alertas.
• Seguridad: mínimos privilegios, cifrado en tránsito/descanso.

Errores comunes

• Sobrerrelacionar o subnormalizar sin medir impacto.
• Crear índices “por si acaso” (lentifica escrituras y consumo de disco).
• Olvidar el manejo de NULL y tipos (casts costosos).
• No actualizar estadísticas; ignorar EXPLAIN.

Checklist rápido

• Esquema claro (PK/FK, tipos correctos).
• Integridad y constraints activas (NOT NULL, CHECK, UNIQUE).
• Índices solo donde aportan.
• Transacciones cortas y consistentes.
• Backups + pruebas de restauración periódicas.

FAQs Bases de datos