Bases de datos relacionales y tablas

Por qué se llaman «relacionales»

Vale empezar por acá porque casi todo el mundo lo tiene mal, incluido material educativo bastante difundido. No se llaman relacionales por las relaciones entre tablas. Se llaman así porque «relación» es el nombre matemático de lo que hoy llamamos tabla.

La documentación de PostgreSQL lo dice sin rodeos: es «un sistema para administrar datos guardados en relaciones», y aclara que «relación es esencialmente un término matemático para tabla».

El modelo lo formuló Edgar F. Codd en 1970, mientras trabajaba en IBM, en un artículo que propuso guardar los datos en tablas simples de filas y columnas en lugar de estructuras jerárquicas, y vincular esas tablas por los valores de sus columnas. Más de cincuenta años después sigue siendo el modelo dominante, lo cual dice bastante sobre lo acertada que era la idea.

Tabla, fila, columna

La estructura es simple y conviene fijar el vocabulario con precisión, porque después todo se apoya en él.

• Una tabla guarda información sobre un tipo de cosa: clientes, pedidos, productos. Si una tabla guarda dos tipos de cosa distintos, es una señal de que hay que partirla.
• Una fila —o registro, o tupla— es una instancia concreta: un cliente en particular.
• Una columna —o campo, o atributo— es una característica que todas las filas comparten, con un tipo de dato definido.

Hay un detalle que la documentación de PostgreSQL señala y que genera muchos errores silenciosos: las columnas tienen un orden fijo en cada fila, pero las filas no tienen orden garantizado dentro de la tabla. Puede parecer que salen en el orden en que las cargaste, y funcionar así durante meses, hasta el día en que el motor reorganiza los datos o alguien agrega un índice. Si el orden importa, hay que pedirlo con ORDER BY.

Tipos de dato: la primera restricción

Elegir el tipo de cada columna es la primera decisión de integridad que tomás, y es la que evita el problema de la planilla donde alguien escribió «noventa mil» en la columna de precio.

Los dos primeros «nunca» de esa tabla merecen énfasis porque son errores caros y frecuentes. Guardar dinero en un tipo de punto flotante produce diferencias de centavos que aparecen al sumar miles de registros, y son muy difíciles de explicar en una auditoría. Y guardar fechas como texto hace que «10/03/2026» y «2026-03-10» convivan en la misma columna, que ordenar alfabéticamente no coincida con ordenar cronológicamente, y que calcular «cuántos días pasaron» sea imposible sin limpiar todo primero.

Clave primaria y clave foránea

Acá está el mecanismo central del modelo. Dos conceptos, y con ellos se construye cualquier esquema.

Clave primaria

Identifica de forma única cada fila de su tabla. Tiene dos condiciones inseparables: no puede repetirse y no puede estar vacía. Es lo que permite decir «este cliente» sin ambigüedad.

La decisión práctica es qué columna usar, y hay dos escuelas. Una clave natural usa un dato real que ya identifica a la entidad: el número de documento, el correo, el código de producto. Una clave subrogada usa un número sin significado, generado automáticamente por el motor.

Clave foránea

Es una columna que contiene el valor de la clave primaria de otra tabla. En el diagrama, pedidos.cliente_id guarda el id de un cliente, y eso es todo el vínculo: no hay flechas guardadas en ninguna parte, solo un valor que coincide.

Lo importante es declararla. Podrías guardar el número sin decirle al motor qué significa, y funcionaría. Pero cuando la declarás como clave foránea, el motor empieza a trabajar para vos: rechaza un pedido cuyo cliente_id no exista, y no te deja borrar un cliente que tenga pedidos sin decidir antes qué pasa con ellos. Eso se llama integridad referencial, y es la diferencia entre una base que se cuida sola y una que depende de que la aplicación no tenga errores.

Los tres tipos de relación

Todo modelo, por complejo que sea, se descompone en estos tres casos.

Uno a muchos (1:N)

El más común con diferencia. Un cliente tiene varios pedidos, pero cada pedido pertenece a un solo cliente. La regla mecánica es simple y conviene memorizarla: la clave foránea va siempre en el lado «muchos». Es pedidos la que guarda cliente_id, nunca al revés.

Si intentaras hacerlo al revés —guardar los pedidos en la tabla de clientes— tendrías que poner varios valores en una sola columna, y eso es precisamente lo que el modelo relacional no permite. Esa restricción, que parece una limitación, es la que fuerza el buen diseño.

Muchos a muchos (N:M)

Un pedido lleva varios productos, y un producto aparece en varios pedidos. No se puede representar con una sola clave foránea, así que se crea una tabla intermedia con dos foráneas, una a cada lado.

CREATE TABLE pedido_producto (
  pedido_id   INT            NOT NULL,
  producto_id INT            NOT NULL,
  cantidad    INT            NOT NULL,
  precio_unit DECIMAL(10,2)  NOT NULL,   -- el precio 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)
);

Fijate en dos detalles que separan un modelo pensado de uno copiado. El primero: la clave primaria es compuesta por las dos columnas juntas, lo que impide cargar dos veces el mismo producto en el mismo pedido. El segundo, y más interesante: la tabla intermedia tiene columnas propias. La cantidad y el precio unitario no pertenecen al pedido ni al producto: pertenecen a la combinación. Y guardar el precio del momento de la compra es lo que evita que la factura del año pasado cambie cuando actualizás la lista de precios.

Uno a uno (1:1)

El menos frecuente. Cada fila de una tabla se corresponde con una sola de la otra: un usuario y su perfil extendido. Se implementa poniendo una clave foránea con restricción UNIQUE en una de las dos tablas.

Antes de usarlo conviene preguntarse por qué no es una sola tabla. Hay dos razones legítimas: separar datos que casi nunca se consultan para que no pesen en cada lectura, y separar datos sensibles para poder darles permisos distintos. Si no es por una de esas dos, probablemente sean una sola tabla.

NULL: el valor que no es un valor

NULL significa «acá no hay valor». No es cero, no es texto vacío, no es falso: es la ausencia de dato. Y se comporta de una forma que sorprende a todo el mundo la primera vez.

NULL no es igual a NULL. Una condición como WHERE telefono = NULL no devuelve nada, nunca, ni siquiera para las filas que tienen el teléfono vacío. La razón es coherente si se piensa: si no sé un valor y no sé otro, no puedo afirmar que sean iguales. Para preguntar por la ausencia hay que escribir IS NULL o IS NOT NULL.

Eso se propaga a los cálculos: cualquier operación aritmética con un NULL da NULL. Y en las funciones de agregado se ignora, lo que a veces es lo que querés y a veces no: un promedio sobre una columna con nulos promedia solo las filas que tienen valor.

Restricciones: reglas que el motor hace cumplir

La documentación de PostgreSQL plantea muy bien por qué hacen falta: los tipos de dato son una restricción, pero «demasiado gruesa». Una columna de precio es numérica, pero nada en el tipo impide que sea negativa. Las restricciones cierran ese hueco.

Hay una objeción habitual: «eso ya lo valida la aplicación». Y la respuesta es que la aplicación no es el único camino a los datos. Hay scripts de migración, cargas masivas, otra aplicación que se conecta a la misma base, y alguien corrigiendo algo a mano un viernes a la tarde. La restricción en la base es la única que se aplica siempre, sin importar quién escriba.

Índices, en dos párrafos

Un índice es una estructura auxiliar que el motor mantiene para encontrar filas rápido, igual que el índice de un libro evita leerlo entero. Sin índice, buscar un cliente por su correo obliga a recorrer toda la tabla; con índice, la búsqueda es casi inmediata incluso con millones de filas.

El precio es que cada índice hace más lenta la escritura, porque hay que actualizarlo en cada inserción o modificación, y ocupa espacio. Las claves primarias y las columnas UNIQUE se indexan automáticamente. Más allá de eso, la regla razonable al empezar es: indexá las columnas por las que buscás y las claves foráneas, y no agregues más «por si acaso». Optimizar índices sin medir es adivinar.

Errores frecuentes al modelar

• No declarar las claves foráneas. Guardar el número sin decirle al motor qué significa desperdicia la única protección real contra datos huérfanos.
• Usar un dato de negocio como clave primaria. El día que hay que corregirlo, el cambio se propaga a todas las tablas que lo referencian.
• Guardar dinero en punto flotante. Los errores de redondeo aparecen al sumar y son imposibles de justificar.
• Guardar fechas como texto. Se pierde ordenar, comparar y calcular, y conviven varios formatos en la misma columna.
• Varios valores en una sola columna. Una columna «teléfonos» con «11-1234, 11-5678» separados por coma es una tabla que falta.
• Columnas numeradas. producto_1, producto_2, producto_3 es siempre una relación uno a muchos disfrazada, y se rompe con el cuarto producto.
• Confiar en el orden de las filas. Sin ORDER BY no hay orden garantizado, aunque durante meses parezca que sí.
• Dejar todo aceptando NULL. Es cómodo al principio y produce una tabla llena de registros a medias.

Preguntas frecuentes

Fuentes

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

1. PostgreSQL. Concepts. «Relación» como término matemático para tabla, estructura de filas y columnas, y la aclaración de que SQL no garantiza el orden de las filas.
2. PostgreSQL. Constraints. Por qué los tipos de dato son una restricción «demasiado gruesa» y qué agrega cada restricción disponible.
3. PostgreSQL. Data Types. Tipos disponibles y sus características.
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 que formuló el modelo relacional. Publicación con acceso restringido; se cita como referencia bibliográfica.
5. Underc0de, foro. Sección Base de Datos. Material de la comunidad sobre bases de datos y SQL.