Cómo diseñar una base de datos sencilla

El caso que vamos a diseñar

Diseñar en abstracto no se aprende, así que vamos con un caso concreto y lo llevamos hasta el final. La descripción, tal como podría salir de una conversación con quien va a usar el sistema:

Esa última frase es la más importante de todas, y es el tipo de detalle que solo aparece si preguntás. Vamos a ver por qué condiciona el diseño entero.

Paso 1: encontrar las entidades

La técnica es mecánica y funciona sorprendentemente bien: subrayá los sustantivos de la descripción y quedate con los que se repiten y tienen características propias.

En nuestro caso salen tres claros: cliente, pedido y producto. Cada uno es un tipo de cosa distinto, con datos propios, y existe independientemente de los otros: un producto sigue siendo un producto aunque nadie lo haya comprado.

Los verbos que conectan dos sustantivos son las relaciones: un cliente hace pedidos, un pedido incluye productos.

Paso 2: atributos y tipos

Para cada entidad, qué datos guardamos y de qué tipo. Acá es donde se paga o se ahorra trabajo futuro.

Tres decisiones de esa tabla que no son obvias. El id numérico en las tres es una clave subrogada: no significa nada, y por eso nunca hay que cambiarlo. El precio va en DECIMAL y no en un tipo de punto flotante, porque el punto flotante introduce errores de redondeo que aparecen al sumar. Y la fecha va en DATE, no en texto, porque en texto se pierde poder comparar y calcular.

Fijate en qué no está: el total del pedido. Es un dato calculable a partir de sus productos, y guardar algo que se puede calcular es abrir la puerta a que la copia y el cálculo no coincidan. Hay una excepción legítima, y la vemos en la sección de desnormalización.

Paso 3: definir las relaciones

Para cada par de entidades conectadas, la pregunta se hace en las dos direcciones. Es la única forma de no equivocarse.

• Cliente y pedido. ¿Un cliente cuántos pedidos tiene? Varios. ¿Un pedido de cuántos clientes es? De uno. Entonces es uno a muchos, y la clave foránea va en el lado «muchos»: pedidos.cliente_id.
• Pedido y producto. ¿Un pedido cuántos productos lleva? Varios. ¿Un producto en cuántos pedidos aparece? En varios. Entonces es muchos a muchos, y hace falta una tabla intermedia.

Y acá vuelve la frase clave del pedido original: «la factura vieja tiene que seguir mostrando lo que se pagó». Si el precio vive solo en productos y mañana lo actualizás, todas las facturas históricas cambian de monto. La solución es guardar el precio del momento de la compra en la tabla intermedia. No es duplicación: es un dato distinto —lo que se pagó— que casualmente coincide con el precio actual el día de la venta.

Paso 4: normalizar

Normalizar es reorganizar las tablas para que cada dato viva en un solo lugar. Se hace por etapas llamadas formas normales, y cada una elimina un tipo concreto de repetición. Suele explicarse con definiciones abstractas que no se entienden; con tablas concretas se vuelve evidente.

Primera forma normal: un valor por celda

El punto de partida tiene una columna productos con «Teclado, Mouse, Monitor» adentro. Eso rompe la regla más básica: cada celda contiene un solo valor. Mientras esté así no se puede consultar por producto, ni sumar por producto, ni relacionarlo con la tabla de productos.

La solución es abrir el grupo: una fila por cada producto del pedido. Se gana la capacidad de consultar, y se paga con que ahora se repite todo lo demás en cada fila.

Segunda forma normal: nada que dependa de parte de la clave

Con la clave compuesta por pedido y producto, aparece el problema: el precio depende solo del producto, no del pedido. Está repetido en cada fila donde aparece ese producto, así que si hay que corregirlo hay que corregirlo en muchos lugares.

La solución es sacar el producto y su precio a su propia tabla, y dejar en la intermedia solo lo que depende de la combinación: la cantidad y el precio pagado.

Tercera forma normal: nada que dependa de otra columna no clave

Queda un caso más sutil. En la tabla de pedidos están el nombre del cliente y su ciudad, pero la ciudad no depende del pedido: depende del cliente. Eso se llama dependencia transitiva, y su consecuencia práctica es que si un cliente se muda, hay que actualizar todos sus pedidos.

La solución es sacar el cliente y sus datos a la tabla clientes, y dejar en pedidos solo la referencia.

Paso 5: el esquema final

El diseño completo, escrito en SQL. Notá que las restricciones no son decoración: son las reglas que hacen que la base se cuide sola.

CREATE TABLE clientes (
  id      INT          PRIMARY KEY AUTO_INCREMENT,
  nombre  VARCHAR(80)  NOT NULL,
  correo  VARCHAR(120) NOT NULL UNIQUE,
  ciudad  VARCHAR(80),
  alta    DATE         NOT NULL DEFAULT (CURRENT_DATE),
  activo  BOOLEAN      NOT NULL DEFAULT TRUE
);

CREATE TABLE productos (
  id      INT            PRIMARY KEY AUTO_INCREMENT,
  nombre  VARCHAR(120)  NOT NULL,
  precio  DECIMAL(10,2) NOT NULL,
  CHECK (precio >= 0)
);

CREATE TABLE pedidos (
  id         INT         PRIMARY KEY AUTO_INCREMENT,
  cliente_id INT         NOT NULL,
  fecha      DATE        NOT NULL,
  estado     VARCHAR(20) NOT NULL DEFAULT 'nuevo',
  FOREIGN KEY (cliente_id) REFERENCES clientes(id)
);

CREATE TABLE pedido_producto (
  pedido_id    INT            NOT NULL,
  producto_id  INT            NOT NULL,
  cantidad     INT            NOT NULL,
  precio_pagado DECIMAL(10,2) NOT NULL,   -- el del día de la compra
  PRIMARY KEY (pedido_id, producto_id),
  FOREIGN KEY (pedido_id)   REFERENCES pedidos(id),
  FOREIGN KEY (producto_id) REFERENCES productos(id),
  CHECK (cantidad > 0)
);

Cuatro tablas para un sistema completo de pedidos. La clave primaria compuesta de la intermedia impide cargar dos veces el mismo producto en el mismo pedido, y los CHECK impiden precios negativos y cantidades en cero.

Cuándo conviene no normalizar

Desnormalizar es repetir datos a propósito, y no es un pecado: es una decisión de ingeniería con un costo conocido. El caso típico es un informe que se consulta mil veces por día y cuyos datos cambian una vez por mes: recalcular el total de cada pedido en cada consulta es trabajo desperdiciado.

Lo que separa una desnormalización sana de un problema son tres condiciones:

1. Que sea consciente y documentadaEscrito en el repositorio: qué está duplicado, por qué, y quién mantiene la copia sincronizada.
2. Que llegue después de medirPrimero diseñás normalizado y medís. Desnormalizar antes de tener el problema es optimizar a ciegas.
3. Que tenga un mecanismo de sincronizaciónSi guardás el total del pedido, algo tiene que actualizarlo cuando cambian sus líneas. Si ese algo es «me acuerdo de hacerlo», va a fallar.

Y hay un caso que parece desnormalización y no lo es: el precio_pagado de nuestro esquema. No es una copia del precio del producto; es un dato distinto —el importe de esa transacción— que resulta igual el día de la venta. Guardarlo no repite información: la preserva.

Tres decisiones que siempre aparecen

No están en los manuales de normalización y aparecen en todos los proyectos reales.

¿Borrar o marcar como inactivo? Un cliente que se va no se puede borrar: sus pedidos pasados lo referencian y perderías el historial. Se marca con una columna activo o una fecha de baja, que es lo que hace nuestro esquema. La pregunta que resuelve el caso: si borro esto, ¿queda algo huérfano o pierdo información que alguien puede necesitar?

¿Cuándo guardar fecha de creación y modificación? Casi siempre, y desde el principio. Son dos columnas que casi no cuestan y que responden preguntas que van a aparecer: cuándo se cargó esto, qué se modificó esta semana, en qué orden se dieron de alta. Agregarlas después significa tener esos datos vacíos para todo lo que ya existe.

¿Qué hacer con los datos personales? Esta merece pensarse en la etapa de diseño, no después. La regla más efectiva es no guardar lo que no vas a usar: lo que no está en la base no se puede filtrar. Si el sistema no necesita la fecha de nacimiento, no la pidas. Y para los datos que sí hacen falta, el diseño debería contemplar desde el inicio quién puede leerlos —con usuarios y permisos separados— y qué se hace cuando alguien pide que borren los suyos.

Errores frecuentes al diseñar

• Empezar por las tablas en lugar de por la descripción. Sin entender el dominio, el esquema modela lo que uno supone y no lo que hace falta.
• Columnas numeradas. producto_1, producto_2, producto_3 es siempre una relación uno a muchos disfrazada, y se rompe con el cuarto.
• Varios valores separados por coma. Rompe la primera forma normal y hace imposible consultar por esos valores.
• Guardar lo que se puede calcular. Un total guardado se desincroniza del cálculo, salvo que haya un mecanismo explícito que lo mantenga.
• Guardar el precio actual en lugar del pagado. Las facturas históricas cambian de monto cuando actualizás la lista de precios.
• Usar un dato de negocio como clave primaria. El día que hay que corregirlo, el cambio se propaga a todas las tablas.
• Crear tablas para atributos simples. Una tabla de dos columnas que solo guarda un nombre suele ser un atributo que se separó de más.
• Diseñar directamente en el editor de SQL. Cuesta ver el conjunto y las relaciones. Un dibujo, aunque sea a mano, detecta la mitad de los problemas antes.
• Pedir datos personales «por si acaso». Es el error más difícil de revertir: lo que no guardás no se puede filtrar.

Preguntas frecuentes

Fuentes

Documentación oficial y referencias consultadas para esta guía. Fecha de consulta: 27 de julio de 2026.

1. PostgreSQL. Constraints. Restricciones disponibles y por qué los tipos de dato solos no alcanzan para garantizar la integridad.
2. PostgreSQL. Data Types. Tipos disponibles, incluidos los numéricos exactos para valores monetarios.
3. PostgreSQL. Data Definition. Creación de tablas, claves y relaciones.
4. Codd, E. F. «A Relational Model of Data for Large Shared Data Banks». Communications of the ACM, vol. 13, n.º 6, 1970, pp. 377-387. Artículo original del modelo relacional, donde se introducen las primeras formas normales. Publicación con acceso restringido; se cita como referencia bibliográfica.
5. Underc0de, foro. Sección Base de Datos. Material de la comunidad sobre modelado y SQL.