10 ejemplos de bases de datos con tablas y consultas

EJEMPLO 01

Nómina: empleados y puestos

Una relación de uno a muchos

Una empresa ficticia guarda los puestos por separado y asigna un puesto a cada empleado. El sueldo del ejercicio pertenece al empleado: compartir puesto no obliga a cobrar lo mismo.

PRAGMA foreign_keys = ON;
CREATE TABLE puestos (
 id INTEGER PRIMARY KEY,
 nombre TEXT NOT NULL
);
CREATE TABLE empleados (
 id INTEGER PRIMARY KEY,
 nombre TEXT NOT NULL,
 puesto_id INTEGER NOT NULL REFERENCES puestos(id),
 sueldo INTEGER NOT NULL CHECK(sueldo >= 0)
);
INSERT INTO puestos VALUES (1, 'Soporte'), (2, 'Ventas');
INSERT INTO empleados VALUES
 (10, 'Ana', 1, 1200), (11, 'Luis', 1, 1400),
 (12, 'Eva', 2, 1300);

Consulta

SELECT e.nombre, p.nombre AS puesto, e.sueldo
FROM empleados AS e
JOIN puestos AS p ON p.id = e.puesto_id
ORDER BY e.id;

La clave foránea puesto_id apunta a un puesto existente. JOIN combina los datos relacionados para mostrar el nombre del puesto junto al empleado. Los importes son unidades monetarias enteras de un modelo didáctico; no se calcula una nómina legal completa.

Qué puede fallar: Asignar puesto_id = 99 se rechaza porque no existe ese puesto. La restricción no comprueba si el puesto elegido es realmente el de la persona.

EJEMPLO 02

Contabilidad: cuentas, subcuentas y movimientos

Agrupar y calcular

Este registro simplificado clasifica movimientos por subcuenta. No representa un sistema completo de asientos por partida doble.

PRAGMA foreign_keys = ON;
CREATE TABLE cuentas (
 id INTEGER PRIMARY KEY, nombre TEXT NOT NULL,
 grupo TEXT NOT NULL
);
CREATE TABLE subcuentas (
 id INTEGER PRIMARY KEY,
 cuenta_id INTEGER NOT NULL REFERENCES cuentas(id),
 nombre TEXT NOT NULL
);
CREATE TABLE movimientos (
 id INTEGER PRIMARY KEY,
 subcuenta_id INTEGER NOT NULL REFERENCES subcuentas(id),
 importe INTEGER NOT NULL
);
INSERT INTO cuentas VALUES (1, 'Ingresos', 'Resultados');
INSERT INTO subcuentas VALUES
 (11, 1, 'Ventas de libros'), (12, 1, 'Talleres');
INSERT INTO movimientos VALUES
 (1, 11, 100), (2, 11, 50), (3, 12, 80);

Consulta

SELECT s.nombre, SUM(m.importe) AS total
FROM subcuentas AS s
JOIN movimientos AS m ON m.subcuenta_id = s.id
GROUP BY s.id, s.nombre
ORDER BY s.id;

La consulta obtiene un dato calculado: el total de cada subcuenta. Los movimientos se conservan por separado para poder explicar de dónde procede cada suma. El grupo contable se registra en cuentas; no se repite en cada movimiento.

Qué puede fallar: Una suma correcta puede partir de importes incorrectos. La base guarda lo que se registra: se necesitan revisión, respaldo documental y reglas de acceso.

EJEMPLO 03

Banca: clientes, cuentas y una transferencia

Confirmar cambios juntos

Dos cuentas ficticias pertenecen a clientes distintos. El ejercicio transfiere 40 unidades de A a B, sin comisiones y dentro de una misma base de datos.

PRAGMA foreign_keys = ON;
CREATE TABLE clientes (
 id INTEGER PRIMARY KEY, nombre TEXT NOT NULL
);
CREATE TABLE cuentas (
 id TEXT PRIMARY KEY NOT NULL,
 cliente_id INTEGER NOT NULL REFERENCES clientes(id),
 saldo INTEGER NOT NULL CHECK(saldo >= 0)
);
INSERT INTO clientes VALUES (1, 'Ana'), (2, 'Luis');
INSERT INTO cuentas VALUES ('A', 1, 500), ('B', 2, 100);

Transferencia: ejecutar una vez

BEGIN;
UPDATE cuentas SET saldo = saldo - 40 WHERE id = 'A';
UPDATE cuentas SET saldo = saldo + 40 WHERE id = 'B';
COMMIT;

Consulta

SELECT id, saldo FROM cuentas ORDER BY id;

La transacción agrupa ambas modificaciones. Tras COMMIT, los saldos suman 600, igual que antes. Si se decide cancelar antes de confirmar, ROLLBACK deshace los cambios de esa transacción. En una aplicación también hay que validar que las dos cuentas existen y comprobar cuántas filas se actualizan. [3]

Qué puede fallar: Una transacción no reconoce por sí sola al destinatario correcto ni autoriza al usuario. Ante un error, la aplicación debe manejarlo y cancelar cuando corresponda; no debe continuar hasta confirmar una operación parcial.

EJEMPLO 04

Biblioteca: libros prestados y devueltos

Consultar un valor ausente

Cada ejemplar físico tiene un identificador. Un préstamo sin fecha de devolución todavía está abierto en este registro.

PRAGMA foreign_keys = ON;
CREATE TABLE ejemplares (
 id INTEGER PRIMARY KEY, titulo TEXT NOT NULL
);
CREATE TABLE prestamos (
 id INTEGER PRIMARY KEY,
 ejemplar_id INTEGER NOT NULL REFERENCES ejemplares(id),
 devuelto TEXT
);
INSERT INTO ejemplares VALUES
 (1, 'Atlas del cielo'), (2, 'Atlas del cielo');
INSERT INTO prestamos VALUES
 (10, 1, NULL), (11, 2, '2026-09-30');

Consulta

SELECT p.id AS prestamo, e.titulo
FROM prestamos AS p
JOIN ejemplares AS e ON e.id = p.ejemplar_id
WHERE p.devuelto IS NULL
ORDER BY p.id;

IS NULL busca ausencia de valor: no equivale a una cadena vacía ni a la palabra «NULL». Dos ejemplares pueden compartir título; por eso el título no se usa como identificador de la copia.

Qué puede fallar: La clave foránea acredita que el ejemplar existe, pero este esquema todavía no impide dos préstamos abiertos para la misma copia. Esa regla requiere otro control.

EJEMPLO 05

Inventario: existencias por almacén

Una clave de dos columnas

El producto A está en dos almacenes. Lo que debe ser único es la combinación de producto y almacén.

PRAGMA foreign_keys = ON;
CREATE TABLE existencias (
 producto TEXT NOT NULL,
 almacen TEXT NOT NULL,
 cantidad INTEGER NOT NULL CHECK(cantidad >= 0),
 PRIMARY KEY(producto, almacen)
);
INSERT INTO existencias VALUES
 ('A', 'Norte', 8), ('A', 'Sur', 5), ('B', 'Norte', 3);

Consulta

SELECT producto, SUM(cantidad) AS unidades
FROM existencias
GROUP BY producto
ORDER BY producto;

La clave primaria compuesta permite repetir A en almacenes distintos, pero no registrar dos filas A–Norte. La consulta suma existencias por producto, sin perder el detalle de ubicación.

Qué puede fallar: CHECK rechaza cantidades negativas, pero no detecta que alguien introdujo 80 cuando había 8. La validez del formato y la exactitud del dato son cosas diferentes.

EJEMPLO 06

Escuela: alumnos inscritos en cursos

Una relación de muchos a muchos

Un alumno puede cursar varias materias y un curso puede tener varios alumnos. Una tabla intermedia registra cada inscripción.

PRAGMA foreign_keys = ON;
CREATE TABLE alumnos (
 id INTEGER PRIMARY KEY, nombre TEXT NOT NULL
);
CREATE TABLE cursos (
 id INTEGER PRIMARY KEY, nombre TEXT NOT NULL
);
CREATE TABLE inscripciones (
 alumno_id INTEGER NOT NULL REFERENCES alumnos(id),
 curso_id INTEGER NOT NULL REFERENCES cursos(id),
 PRIMARY KEY(alumno_id, curso_id)
);
INSERT INTO alumnos VALUES (1, 'Eva'), (2, 'Leo');
INSERT INTO cursos VALUES (10, 'Arte'), (20, 'Ciencias');
INSERT INTO inscripciones VALUES (1, 10), (1, 20), (2, 20);

Consulta

SELECT a.nombre AS alumno, c.nombre AS curso
FROM inscripciones AS i
JOIN alumnos AS a ON a.id = i.alumno_id
JOIN cursos AS c ON c.id = i.curso_id
ORDER BY a.id, c.id;

La tabla intermedia representa una relación. Esto muestra por qué no toda tabla tiene que representar una entidad como «persona» o «curso». Cada fila combina dos claves.

Qué puede fallar: Inscribir de nuevo a Eva en Arte genera un conflicto de clave primaria. Si se necesitan cursos por año, el modelo debe distinguir también las ediciones o periodos.

EJEMPLO 07

Reservas de una sala

Unicidad de una franja

Un centro cultural reserva una sala mediante franjas fijas de una hora. La fecha y la hora se guardan con el mismo formato.

PRAGMA foreign_keys = ON;
CREATE TABLE reservas (
 id INTEGER PRIMARY KEY,
 sala TEXT NOT NULL,
 inicio TEXT NOT NULL,
 UNIQUE(sala, inicio)
);
INSERT INTO reservas VALUES
 (1, 'A', '2026-10-12 10:00'),
 (2, 'A', '2026-10-12 11:00'),
 (3, 'B', '2026-10-12 10:00');

Consulta

SELECT sala, inicio FROM reservas
WHERE inicio = '2026-10-12 10:00'
ORDER BY sala;

UNIQUE(sala, inicio) impide repetir la misma franja para la misma sala. Reservar otra sala a esa hora sí es válido.

Qué puede fallar: Esta restricción no valida fechas ni detecta cualquier solapamiento. Si las duraciones fueran variables, dos inicios distintos podrían superponerse y haría falta otra regla.

EJEMPLO 08

Tienda: pedidos y líneas de compra

Calcular un total sin repetir datos del pedido

Un pedido reúne varias líneas. El precio de cada línea es el acordado al comprar, no necesariamente el precio actual del catálogo.

PRAGMA foreign_keys = ON;
CREATE TABLE pedidos (
 id INTEGER PRIMARY KEY, cliente TEXT NOT NULL
);
CREATE TABLE lineas (
 pedido_id INTEGER NOT NULL REFERENCES pedidos(id),
 numero INTEGER NOT NULL,
 cantidad INTEGER NOT NULL CHECK(cantidad > 0),
 precio_cent INTEGER NOT NULL CHECK(precio_cent >= 0),
 PRIMARY KEY(pedido_id, numero)
);
INSERT INTO pedidos VALUES (50, 'Mara');
INSERT INTO lineas VALUES (50, 1, 2, 300), (50, 2, 1, 450);

Consulta

SELECT pedido_id,
 SUM(cantidad * precio_cent) AS total_cent
FROM lineas
GROUP BY pedido_id
ORDER BY pedido_id;

El total es 1.050 centavos, equivalentes a 10,50 unidades monetarias en una moneda de cien centavos por unidad. Guardar enteros evita representar esos importes mediante aproximaciones de coma flotante. Aquí no se añaden impuestos ni descuentos.

Qué puede fallar: Recalcular una venta antigua con el precio actual alteraría su historia. Reducir redundancia no significa borrar datos que describen condiciones distintas.

EJEMPLO 09

Estación meteorológica

Datos ordenados en el tiempo

Una estación registra tres temperaturas. El instante es parte de la identidad de cada lectura.

PRAGMA foreign_keys = ON;
CREATE TABLE lecturas (
 estacion TEXT NOT NULL,
 instante TEXT NOT NULL,
 temperatura REAL NOT NULL,
 PRIMARY KEY(estacion, instante)
);
INSERT INTO lecturas VALUES
 ('N', '2026-10-01 08:00', 18),
 ('N', '2026-10-01 09:00', 20),
 ('N', '2026-10-01 10:00', 22);

Consulta

SELECT estacion, AVG(temperatura) AS media
FROM lecturas
GROUP BY estacion
ORDER BY estacion;

La media aritmética de estas tres lecturas es 20 °C. Una colección de observaciones temporales también puede guardarse en tablas relacionales; describir los datos como «serie temporal» no obliga a usar un único tipo de gestor.

Qué puede fallar: Tres medidas no bastan para llamar al resultado «temperatura media del día». Para combinar estaciones hay que definir unidades, horarios, zona horaria y tratamiento de lecturas ausentes.

EJEMPLO 10

Catálogo con documentos

Otra forma de organizar los datos

Una base documental puede representar cada producto mediante un documento con campos y estructuras anidadas. Este JSON ilustra un producto ficticio; no es una consulta ejecutada en un gestor.

{
  "id": "P-07",
  "nombre": "Mochila",
  "atributos": {
    "capacidad_l": 20,
    "color": "azul"
  },
  "etiquetas": [
    "viaje",
    "urbana"
  ]
}

El color se encuentra dentro de atributos; etiquetas contiene dos elementos. En MongoDB los documentos se almacenan en BSON, una representación binaria con tipos adicionales a JSON. El ejemplo solo ilustra la estructura: no se ha ejecutado en MongoDB. [9]

Qué puede fallar: Una estructura flexible también necesita criterios de validación. Mezclar capacidad_l con capacidad_ml sin definir unidades puede producir comparaciones incorrectas. Documental no significa «sin reglas».