Última actualización: 2026-11-11

Contenido de esta página

• ¿Qué es el modelo relacional?
• Relación, tupla, atributo y dominio: el vocabulario en sentido matemático
• Restricciones de integridad: de dominio, de entidad y referencial
• Cómo pasar del modelo entidad-relación al modelo relacional
• Álgebra relacional: operadores, notación y equivalente en SQL
• Las 12 reglas de Codd
• ¿Para qué estudiar la teoría si ya existe SQL?

Historia real. El lunes 14 de octubre de 1985, la revista estadounidense Computerworld publicó un artículo de Edgar F. Codd. Su título era una pregunta: ¿su gestor de bases de datos es de verdad relacional? [3]. Codd había propuesto el modelo relacional quince años antes, y ahora le molestaba el uso que el mercado hacía de la palabra.

Casi todos los fabricantes decían que su producto era relacional. Según Codd, algunos le habían añadido a toda prisa unas pocas funciones relacionales a sistemas que no lo eran, solo para poder usar la etiqueta [3]. Su respuesta fue un examen: una regla cero y doce reglas numeradas. A la semana siguiente, en la misma revista, calificó con ellas a tres productos comerciales, con un punto por cada regla cumplida [4].

Para que ese examen tuviera sentido, el modelo tenía que ser algo más que «tablas conectadas». Tenía que ser una definición exacta, contra la cual medir.

Esa definición es el modelo relacional: la teoría que dice qué es una relación, qué reglas la protegen y qué operaciones se le pueden aplicar. SQL, el lenguaje con que se consultan las bases de datos de tablas, es su puesta en práctica. Y, como se verá, no siempre es una puesta en práctica fiel.

¿Qué es el modelo relacional?

El modelo relacional es una forma de describir los datos con herramientas de la teoría de conjuntos, la rama de las matemáticas que estudia colecciones de elementos. Todo dato vive en una relación, que se dibuja como una tabla. Codd lo dejó claro desde la primera línea de su definición: «el término relación se usa aquí en su sentido matemático aceptado» [1]. Las citas en inglés de esta página son traducción propia.

En 1985, Codd insistió en que el modelo tiene tres partes y advirtió que se olvidan con frecuencia [3]:

Parte del modelo	Qué responde	Dónde está en esta página
Estructural	¿Cómo se organizan los datos?	Relación, tupla, atributo, dominio y claves
De integridad	¿Qué datos se rechazan?	Restricciones de dominio, de entidad y referencial
Manipulativa	¿Cómo se obtienen datos nuevos a partir de los guardados?	Álgebra relacional

Esta página se queda con la teoría. Para qué sirve una base de datos de tablas y cómo se usa en un colegio o una tienda está en la guía de bases de datos relacionales. Y el camino que llevó de los archivos de cinta a Codd y a SQL se cuenta en la historia de las bases de datos.

Relación, tupla, atributo y dominio: el vocabulario en sentido matemático

Una relación es un conjunto de tuplas, y una tupla es una lista ordenada de valores, uno por cada atributo. Cada valor sale de un dominio, que es el conjunto de valores permitidos para ese atributo. En términos de Codd, si hay n dominios, una relación es un subconjunto del producto cartesiano de esos n dominios [1].

El producto cartesiano suena difícil y no lo es. Es la lista de todas las combinaciones posibles. Si el dominio de productores tiene 4 personas y el de productos tiene 4 cultivos, hay 16 parejas posibles. La relación «ofrece» guarda solo las parejas que son verdad: las que de verdad se venden.

El vocabulario básico de bases de datos, con su error típico en cada término, tiene su propia guía en fundamentos de bases de datos. Aquí va la equivalencia exacta entre el lenguaje matemático y el de una tabla en SQL. Grado y cardinalidad siguen la definición del curso de la Universidad de Cantabria [17]:

Término formal	En una tabla SQL	Ejemplo con un mercado campesino
Relación	Tabla	oferta
Tupla	Fila	(10, ‘PAP’, 1800): la productora 10 vende papa a 1.800 pesos el kilo
Atributo	Columna	precio_kg
Dominio	Tipo de dato con sus restricciones	Enteros mayores que cero
Grado	Número de columnas	oferta tiene grado 3
Cardinalidad	Número de filas	oferta tiene cardinalidad 9
Clave candidata	Columna o grupo de columnas que no se repite	La pareja productor y producto
Clave primaria	PRIMARY KEY	La clave candidata elegida
Clave foránea	FOREIGN KEY o REFERENCES	El código de productor dentro de oferta

Los datos del mercado campesino son inventados y sirven para todo el recorrido de la página. Codd ya usó el grado de una relación en 1970: las de grado 1 suelen llamarse unarias; las de grado 2, binarias, y las de grado n, n-arias [1].

Claves candidata, primaria y foránea según Codd

Codd definió la clave primaria como el atributo, o la combinación de atributos, cuyos valores identifican sin ambigüedad cada tupla [1]. Una relación puede tener varias combinaciones que cumplan esa función, sin atributos de sobra. Cuando eso pasa, se elige una de forma arbitraria y esa es la primaria [1]. Todas esas combinaciones posibles son las que hoy se llaman claves candidatas.

La clave foránea es un atributo de una relación cuyos valores son valores de la clave primaria de otra relación, o de la misma [1]. Así se conectan las tablas sin copiar datos: la oferta no repite el nombre de la productora, guarda su número.

¿Por qué una tabla SQL no es una relación?

Una tabla SQL se parece a una relación, pero conviene compararla con la relación en tres puntos. El curso de bases de datos de la Universidad de Cantabria, en España, lo advierte en una línea: «una relación no es una tabla» [17]. Las diferencias son estas:

1. Duplicados. Una relación es un conjunto, y en un conjunto nada se repite: Codd exigía que todas las filas fueran distintas [1]. PostgreSQL 18 es un gestor libre de bases de datos, hoy en su versión 18.6 [12]. Su documentación reconoce que una tabla puede tener varias filas idénticas, aunque normalmente no sea lo deseable [5].
2. Orden. En una relación, el orden de las filas no importa [1]. SQL tampoco garantiza un orden: las filas salen en un orden no especificado, salvo que se pida ordenar [5]. Aquí la tabla sí respeta el modelo, pero el usuario suele creer lo contrario.
3. Valores nulos. SQL admite NULL, una marca que significa «valor desconocido o que no aplica». Con NULL, una comparación ya no da solo verdadero o falso: en PostgreSQL, 7 = NULL da nulo, que se lee como «desconocido» [19].

La prueba de los duplicados es fácil de repetir. En SQLite 3.53.1, un motor de bases de datos que no necesita servidor, una tabla sin clave aceptó dos veces la misma fila: (10, ‘sábado’) y (10, ‘sábado’). La salida completa está en el ejercicio de más abajo.

Restricciones de integridad: de dominio, de entidad y referencial

Las restricciones de integridad son las reglas que impiden guardar datos imposibles. El modelo relacional define tres tipos básicos, y SQL tiene una orden para cada uno. Las tres se probaron en SQLite con el esquema del mercado campesino, y las tres rechazaron el dato malo.

Integridad de dominio

La integridad de dominio exige que cada valor pertenezca al dominio de su atributo. Un precio por kilo debe ser un número mayor que cero, no «barato» ni −500.

En SQL se escribe con el tipo de dato y con CHECK, la restricción que obliga a cumplir una condición. PostgreSQL la llama la restricción más genérica [6]. Para no repetir la misma condición en diez tablas, PostgreSQL tiene CREATE DOMAIN, que crea un dominio con nombre: en esencia, un tipo de dato con restricciones opcionales [7].

Ejemplo. Al insertar un precio de 0 pesos, SQLite respondió: CHECK constraint failed: precio_kg > 0.

Hay una historia detrás de CREATE DOMAIN. En 1985, Codd pidió que SQL añadiera una orden así y que la creación de tablas permitiera declarar las claves primarias y foráneas [4]. Hoy los dos pedidos existen en PostgreSQL [6] [7].

Integridad de entidad

La integridad de entidad dice que ningún componente de la clave primaria puede ser nulo [3]. La razón es de sentido común: si no se sabe quién es la productora, no se puede guardar qué vende.

En SQL la garantiza la orden PRIMARY KEY (clave primaria). En PostgreSQL, la clave primaria exige valores únicos y no nulos [6].

Ejemplo. Al repetir la pareja (productora 10, papa), SQLite respondió: UNIQUE constraint failed: oferta.id_productor, oferta.cod_producto.

Una advertencia práctica: SQLite no cumple esta regla por defecto en todas las columnas. Su documentación explica que, por un error de algunas versiones antiguas, admite nulos en la mayoría de las claves primarias, salvo en algunos casos. Uno de ellos es que la columna se declare NOT NULL, es decir, «no admite nulos» [13]. En la prueba, una clave primaria de texto sin NOT NULL aceptó dos filas nulas. Por eso el esquema de esta página escribe NOT NULL de forma explícita.

Integridad referencial

La integridad referencial dice que cada valor no nulo de una clave foránea debe coincidir con un valor de la clave primaria a la que apunta [3]. Es la regla que impide que una fila apunte a algo que no está: una oferta de un productor que no existe.

En SQL se escribe con FOREIGN KEY o REFERENCES (clave foránea). El manual de PostgreSQL la trata en su capítulo de restricciones [6]. En SQLite viene apagada y hay que activarla en cada conexión [14].

Ejemplo. SQLite rechazó dos cosas con FOREIGN KEY constraint failed: una oferta del productor 77, que no existe, y el borrado de una asociación que todavía tenía productores.

Cómo pasar del modelo entidad-relación al modelo relacional

El paso del modelo entidad-relación al relacional convierte un dibujo de cosas y vínculos en un conjunto de tablas con sus claves. Cómo se dibuja ese diagrama está explicado en la guía del modelo entidad-relación. Aquí se parte del diagrama ya hecho.

El libro Database System Concepts, de Silberschatz, Korth y Sudarshan, describe la conversión en sus diapositivas de la séptima edición [16]. Estas son las cinco reglas:

1. Entidad fuerte → una tabla con sus mismos atributos. Si un atributo es compuesto, como el nombre, se aplana en una columna por cada parte [16].
2. Entidad débil → una tabla que incluye, además, la clave primaria de la entidad de la que depende [16].
3. Atributo multivaluado → una tabla aparte con la clave de la entidad dueña y el atributo. Cada valor se vuelve una fila [16].
4. Relación 1:N → una clave foránea en el lado N. Si la participación del lado N es parcial, esa columna puede quedar con nulos [16]. En una relación 1:1, cualquiera de los dos lados puede recibir la clave [16].
5. Relación N:M → una tabla intermedia con las claves primarias de las dos entidades y los atributos propios de la relación [16].

Caso resuelto: una red de mercados campesinos

Enunciado (inventado). Una red de mercados campesinos registra productores. Cada productor pertenece a una sola asociación y puede tener varios teléfonos. Cada productor ofrece varios productos, y cada producto lo ofrecen varios productores; el precio por kilo depende de los dos. Un comprador institucional publica una canasta de productos que necesita.

Del diagrama a las tablas, regla por regla:

Pieza del diagrama	Regla	Resultado
Entidades fuertes Asociación, Productor y Producto	1	Tres tablas; el nombre del productor se aplana en nombres y apellidos
Atributo multivaluado teléfonos	3	Tabla productor_telefono, con clave compuesta (productor, teléfono)
Relación 1:N Asociación–Productor	4	Columna id_asociacion en productor, obligatoria porque todo productor tiene asociación
Relación N:M ofrece, con atributo precio	5	Tabla oferta con las dos claves y el precio

El caso no tiene entidades débiles, así que la regla 2 no se usa. Este es el esquema completo, con los datos de prueba, escrito para SQLite 3:

-- Red de mercados campesinos (datos inventados). Escrito para SQLite 3.
PRAGMA foreign_keys = ON;  -- SQLite: activa las claves foráneas en esta conexión

-- Regla 1: entidad fuerte -> tabla. El nombre compuesto se aplana en dos columnas.
CREATE TABLE asociacion (
  id_asociacion INTEGER PRIMARY KEY,
  nombre        TEXT NOT NULL UNIQUE
);

-- Regla 4: relación 1:N -> la clave de la asociación viaja al lado N (productor).
CREATE TABLE productor (
  id_productor  INTEGER PRIMARY KEY,
  nombres       TEXT NOT NULL,
  apellidos     TEXT NOT NULL,
  id_asociacion INTEGER NOT NULL REFERENCES asociacion (id_asociacion)
);

-- Regla 3: atributo multivaluado -> tabla propia con la clave del dueño.
CREATE TABLE productor_telefono (
  id_productor INTEGER NOT NULL REFERENCES productor (id_productor),
  telefono     TEXT    NOT NULL,
  PRIMARY KEY (id_productor, telefono)
);

CREATE TABLE producto (
  cod_producto TEXT PRIMARY KEY NOT NULL,  -- en SQLite, NOT NULL explícito: ver la nota de integridad de entidad
  nombre       TEXT NOT NULL
);

-- Regla 5: relación N:M -> tabla intermedia con las dos claves y el atributo propio.
CREATE TABLE oferta (
  id_productor INTEGER NOT NULL REFERENCES productor (id_productor),
  cod_producto TEXT    NOT NULL REFERENCES producto (cod_producto),
  precio_kg    INTEGER NOT NULL CHECK (precio_kg > 0),  -- integridad de dominio
  PRIMARY KEY (id_productor, cod_producto)              -- integridad de entidad
);

-- Productos que pide un comprador institucional (para la división).
CREATE TABLE canasta (
  cod_producto TEXT PRIMARY KEY NOT NULL REFERENCES producto (cod_producto)
);

INSERT INTO asociacion VALUES (1, 'Asociación El Roble'), (2, 'Asociación La Cumbre');
INSERT INTO productor VALUES
  (10, 'Ana',    'Rueda',  1),
  (11, 'Luis',   'Pabón',  1),
  (12, 'Marta',  'Celis',  2),
  (13, 'Jorge',  'Durán',  2);
INSERT INTO productor_telefono VALUES (10, '300 000 0001'), (10, '300 000 0002'), (12, '300 000 0003');
INSERT INTO producto VALUES ('PAP', 'Papa'), ('MOR', 'Mora'), ('FRI', 'Fríjol'), ('YUC', 'Yuca');
INSERT INTO oferta VALUES
  (10, 'PAP', 1800), (10, 'MOR', 4200), (10, 'FRI', 6500),
  (11, 'PAP', 1700), (11, 'YUC', 1500),
  (12, 'PAP', 1900), (12, 'MOR', 4000), (12, 'FRI', 6300), (12, 'YUC', 1600);
INSERT INTO canasta VALUES ('PAP'), ('MOR'), ('FRI');

Con las tablas listas, el siguiente paso habitual es revisarlas para que ningún dato se repita sin necesidad. Eso es la normalización de bases de datos, que tiene sus propias reglas.

Álgebra relacional: operadores, notación y equivalente en SQL

El álgebra relacional es el conjunto de operaciones que toman una o dos relaciones y devuelven otra relación. Su gracia es que el resultado siempre es del mismo tipo que la entrada, así que las operaciones se pueden encadenar como las de la aritmética.

Codd presentó varias operaciones en 1970, entre ellas la proyección y el join (la unión de dos relaciones por una columna común) [1]. En un informe del laboratorio de IBM, la empresa estadounidense de computadores, de marzo de 1972, las ordenó en dos grupos. Por un lado, las operaciones tradicionales de conjuntos: producto cartesiano, unión, intersección y diferencia. Por otro, las propias de las relaciones: proyección, join, división y restricción [2]. Lo que Codd llamaba restricción se parece a lo que hoy se enseña como selección: quedarse con las filas que cumplen una condición.

Los textos actuales separan los operadores básicos de los derivados, que son los que se arman combinando básicos. Las diapositivas de Silberschatz cuentan seis básicos: selección, proyección, unión, diferencia, producto cartesiano y renombrar [15]. Un teórico de la Universidad Nacional de Río Cuarto, en Argentina, pone el join y la división entre los derivados [18].

Operador	Notación	Qué devuelve	SQL equivalente	Resultado con los datos de prueba
Selección	σ precio_kg > 4000 (oferta)	Las filas que cumplen una condición	WHERE	3 filas: Ana con mora y fríjol, Marta con fríjol
Proyección	π id_asociacion (productor)	Solo algunas columnas, sin repetidos	SELECT DISTINCT	2 filas: asociaciones 1 y 2
Unión	R ∪ S	Las filas que están en una o en otra	UNION	Productores 10, 11 y 12
Diferencia	R − S	Las filas de la primera que no están en la segunda	EXCEPT	Productor 13
Producto cartesiano	asociacion × producto	Todas las combinaciones de filas	CROSS JOIN	8 filas (2 × 4)
Join natural	productor ⋈ asociacion	Las combinaciones que coinciden en la columna común	JOIN … USING	4 filas, una por productor
División	oferta ÷ canasta	Lo que se combina con todas las filas de la segunda	NOT EXISTS doble	Ana y Marta

Codd ya usaba π para la proyección [1], y las diapositivas de Silberschatz usan σ, Π, ∪, − y × para los básicos [15]. La división no tiene un signo único: el teórico de Río Cuarto la escribe r / s [18], y aquí se usa ÷. Estas son las consultas que produjeron la última columna:

-- 1. Selección: ofertas con precio mayor de 4.000 pesos el kilo
SELECT * FROM oferta WHERE precio_kg > 4000;

-- 2. Proyección: las asociaciones que tienen productores.
--    Sin DISTINCT, SQL devuelve 1, 1, 2, 2: una tabla admite repetidos.
SELECT DISTINCT id_asociacion FROM productor;

-- 3. Unión: quienes ofrecen mora o yuca
SELECT id_productor FROM oferta WHERE cod_producto = 'MOR'
UNION
SELECT id_productor FROM oferta WHERE cod_producto = 'YUC';

-- 4. Diferencia: productores registrados que no ofrecen nada
SELECT id_productor FROM productor
EXCEPT
SELECT id_productor FROM oferta;

-- 5. Producto cartesiano: todas las parejas asociación-producto
SELECT COUNT(*) FROM asociacion CROSS JOIN producto;

-- 6. Join natural: cada productor con el nombre de su asociación
SELECT nombres, nombre
FROM productor JOIN asociacion USING (id_asociacion);

-- 7. División: productores que ofrecen TODOS los productos de la canasta
SELECT p.id_productor, p.nombres
FROM productor AS p
WHERE NOT EXISTS (            -- no existe un producto de la canasta...
  SELECT 1 FROM canasta AS c
  WHERE NOT EXISTS (          -- ...que este productor no ofrezca
    SELECT 1 FROM oferta AS o
    WHERE o.id_productor = p.id_productor
      AND o.cod_producto = c.cod_producto
  )
);

Tres detalles separan el álgebra de su versión en SQL. Primero, la proyección del álgebra quita los repetidos por definición [1], y en SQL hay que pedirlo con DISTINCT [10]. Segundo, UNION y EXCEPT sí quitan los repetidos, salvo que se escriba ALL, y solo funcionan si las dos consultas tienen el mismo número de columnas con tipos compatibles [9]. Tercero, PostgreSQL advierte que NATURAL JOIN es bastante más riesgoso: si un cambio en las tablas añade una columna con el mismo nombre, el join la usa también [8]. Por eso el ejemplo usa USING, que nombra la columna de unión a mano.

La división relacional con NOT EXISTS

La división responde preguntas con la palabra «todos»: qué productores ofrecen todos los productos de la canasta. Codd la presentó como la contraparte algebraica del cuantificador universal [2], el «para todo» de la lógica.

SQL no tiene una orden DIVIDE, así que se escribe con una doble negación. La consulta se lee así: un productor sirve si no existe un producto de la canasta que él no ofrezca. Ana ofrece papa, mora y fríjol. Marta ofrece esos tres y además yuca. Luis no ofrece mora, y Jorge no ofrece nada. El resultado fue Ana y Marta, como se esperaba.

Para comprobarlo de otra manera, se ejecutó también la fórmula del teórico de Río Cuarto, hecha solo con operadores básicos [18]. Primero se arman todas las parejas productor-producto que deberían existir; luego se restan las que existen. Dio lo mismo: productores 10 y 12.

Hay una diferencia sutil que vale la pena conocer. Con la canasta vacía, la consulta con NOT EXISTS (no existe) devolvió a los cuatro productores, incluido Jorge, que no vende nada. Es lógica pura: si no se pide nada, todos cumplen. La versión que parte de la tabla oferta, en cambio, solo puede devolver a quien ofrece algo.

Las 12 reglas de Codd

Las 12 reglas de Codd son el examen que Codd publicó en 1985 para decidir si un gestor de bases de datos merece llamarse relacional [3]. Todas se apoyan en la regla cero: un sistema que se anuncie como relacional debe poder administrar sus bases de datos por completo con sus capacidades relacionales [3].

N.º	Nombre	Qué exige, en pocas palabras
1	De la información	Toda la información se representa de una sola manera: como valores en tablas, incluidos los nombres de tablas y columnas
2	Del acceso garantizado	Cada dato se puede alcanzar con el nombre de la tabla, el valor de la clave primaria y el nombre de la columna
3	Tratamiento sistemático de los nulos	Hay un valor nulo, distinto del texto vacío y del cero, para la información faltante o que no aplica, sea cual sea el tipo de dato
4	Catálogo en línea basado en el modelo	La descripción de la base se guarda como datos comunes y se consulta con el mismo lenguaje
5	Sublenguaje de datos completo	Al menos un lenguaje sirve para definir datos y vistas, manipular datos, fijar restricciones, dar permisos y marcar transacciones
6	Actualización de vistas	Toda vista que en teoría se puede actualizar, el sistema la actualiza
7	Inserción, actualización y borrado de alto nivel	Se insertan, cambian y borran conjuntos de filas en una sola operación, no solo una fila a la vez
8	Independencia física	Los programas siguen funcionando aunque cambie la forma de guardar los datos o de llegar a ellos
9	Independencia lógica	Los programas siguen funcionando ante cambios en las tablas que no pierden información, como partir una tabla en dos
10	Independencia de la integridad	Las restricciones se definen en el lenguaje relacional y se guardan en el catálogo, no en los programas
11	Independencia de la distribución	Los programas no se enteran si los datos se reparten entre varios sitios o se redistribuyen
12	De la no subversión	Un lenguaje de bajo nivel, de una fila a la vez, no puede saltarse las reglas de integridad del lenguaje relacional

Fuente de las reglas: Codd, en Computerworld [3]; los nombres en español siguen, con ajustes, el curso de la Universidad de Cantabria [17]. Una vista es una consulta guardada con nombre, que se usa como si fuera una tabla. Trabajar con conjuntos de filas incluye los casos de cero o una: Codd aclara que una tabla con cero filas o con una sola sigue siendo una relación válida [3].

¿Por qué ningún motor cumple todas las reglas de Codd?

La afirmación tiene fecha y autor. En 1985, Codd escribió que ningún gestor que él conociera podía afirmar con honestidad que era plenamente relacional [3] [4]. Y criticó también el borrador de la norma de SQL del instituto de normas de Estados Unidos, que le parecía aún menos fiel al modelo que algunos productos [3].

Cuatro décadas después, la documentación de los motores muestra dónde siguen las distancias. Dos ejemplos de PostgreSQL 18:

• Contra la estructura. Una tabla puede guardar filas idénticas [5], algo que una relación no permite.
• Contra la regla 6. PostgreSQL actualiza de forma automática solo las vistas simples. Entre otras condiciones, la vista debe tener una sola tabla o vista en su FROM, la parte de la consulta que dice de dónde salen los datos [11]. Para las demás hacen falta mecanismos adicionales que programa el usuario.

¿Para qué estudiar la teoría si ya existe SQL?

Mi posición, y es una opinión: quien diseña bases de datos sin conocer el modelo relacional aprende sus reglas a golpes. Y las aprende una a una, cuando ya hay datos de por medio.

La consulta de la división es el mejor ejemplo. Escrita en SQL, la doble negación parece un truco. Vista desde el álgebra, es solo la forma de decir «todos», y deja de dar miedo. Lo mismo pasa con DISTINCT, que no es un adorno: es el punto exacto donde SQL se aparta de la teoría y el programador tiene que corregirlo.

Para escribir consultas a diario basta SQL. Para saber cuándo una consulta miente, hace falta la teoría. Y esa teoría está escrita en artículos de libre lectura y en documentación gratuita, a la distancia de una conexión a internet, sin licencia que pagar.

Preguntas frecuentes

¿Qué es una tupla en una base de datos?

Una tupla es una fila de una relación: una lista de valores, uno por cada atributo, tomados de sus dominios. En la tabla de ofertas, (10, ‘PAP’, 1800) es una tupla. Codd hablaba de n-tuplas: listas de n valores, tantos como atributos tenga la relación.

¿El álgebra relacional y SQL son lo mismo?

No. El álgebra relacional es la teoría: un conjunto de operaciones sobre relaciones que se escribe con símbolos como σ y π. SQL es un lenguaje práctico que funciona con tablas, y esas tablas pueden tener repetidos y nulos. Al pasar de una a otro hay que cuidar esas dos diferencias, como muestra el caso de DISTINCT.

¿Cuál es la diferencia entre el modelo relacional y el modelo entidad-relación?

Con el diagrama ya dibujado, el paso al modelo relacional es casi mecánico. Cada entidad fuerte se vuelve una tabla. Cada vínculo de uno a muchos pasa a ser una clave foránea. Cada vínculo de muchos a muchos pide una tabla intermedia. Esa traducción, con las cinco reglas de esta página, separa a un modelo del otro. El diagrama marca qué atributo identifica a cada entidad. Pero no dice dónde va cada clave foránea ni qué restricciones tendrá cada tabla hasta que se traduce.

¿Qué diferencia hay entre una clave candidata y una clave primaria?

Una clave candidata es cualquier atributo, o grupo de atributos, que identifica cada fila sin sobrar nada. Una tabla puede tener varias. La clave primaria es la candidata que el diseñador elige como identificador oficial. Las demás siguen ahí y conviene protegerlas con UNIQUE para que no se repitan.

¿Por qué un NULL no es igual a otro NULL?

Porque NULL no es un valor, sino la marca de un valor desconocido. Comparar dos desconocidos no da verdadero ni falso, sino desconocido. Por eso, para buscar nulos se escribe «IS NULL» («es nulo») y no «= NULL». En la prueba con SQLite, la comparación NULL = NULL devolvió nulo.

Referencias

1. Codd, Edgar F. A Relational Model of Data for Large Shared Data Banks, Communications of the ACM, vol. 13, n.º 6, junio de 1970, pp. 377-387 (DOI 10.1145/362384.362685) — sección 1.3: «The term relation is used here in its accepted mathematical sense»; relación como subconjunto del producto cartesiano de n conjuntos (dominios); grado n, unarias, binarias, ternarias y n-arias; propiedades del arreglo: el orden de las filas no importa y todas las filas son distintas; clave primaria, claves primarias no redundantes y elección arbitraria de una; clave foránea (puede apuntar a la misma relación); sección 2.1: operaciones sobre relaciones, entre ellas permutación, proyección (que elimina filas duplicadas), join, composición y restricción. Texto leído en el PDF de la ACM archivado. ACM: Codd 1970, PDF en Internet Archive — Consultada: 2026-11-11.
2. Codd, Edgar F. Relational Completeness of Data Base Sublanguages, informe de investigación RJ 987, IBM Research Laboratory, San José (California), 6 de marzo de 1972 — operaciones del álgebra relacional en dos clases: tradicionales de conjuntos (producto cartesiano, unión, intersección, diferencia) y propias de relaciones (proyección, join, división, restricción); unión, intersección y diferencia solo entre relaciones compatibles; la división como contraparte algebraica del cuantificador universal. Copia alojada por la Universidad Libre de Bozen-Bolzano. Universidad de Bozen-Bolzano: Codd 1972 (PDF) — Consultada: 2026-11-11.
3. Codd, Edgar F. Is your DBMS really relational?, Computerworld, vol. 19, n.º 41, 14 de octubre de 1985, sección In Depth — casi todo fabricante afirmaba que su gestor era relacional y algunos añadieron pocas funciones relacionales para reclamar la etiqueta; el modelo tiene tres partes (estructural, manipulativa y de integridad), lo que se olvida con frecuencia; ningún producto conocido por el autor podía afirmar con honestidad ser plenamente relacional; el borrador de la norma ANSI era menos fiel que algunos productos; regla cero y reglas 1 a 12; integridad de entidad (ningún componente de una clave primaria puede ser nulo) e integridad referencial (cada valor no nulo de clave foránea debe coincidir con un valor de clave primaria del mismo dominio); una relación con cero o una tupla sigue siendo válida. Texto leído en el escaneo del número completo (la transcripción automática omite palabras cortas; no se toman citas literales). Internet Archive: Computerworld, 14 de octubre de 1985 — Consultada: 2026-11-11.
4. Codd, Edgar F. Does your DBMS run by the rules?, Computerworld, vol. 19, n.º 42, 21 de octubre de 1985, sección In Depth — segunda parte: evaluación de DB2 (IBM), IDMS/R (Cullinet) y Datacom/DB (Applied Data Research) con un punto por regla cumplida y cero por incumplimiento o apoyo parcial; repite que ningún producto conocido podía afirmar ser plenamente relacional; pide extender CREATE TABLE para declarar claves primarias y foráneas y añadir una orden CREATE DOMAIN a SQL. Internet Archive: Computerworld, 21 de octubre de 1985 — Consultada: 2026-11-11.
5. PostgreSQL Global Development Group. PostgreSQL 18 Documentation, 5.1. Table Basics — SQL no garantiza el orden de las filas, que aparecen en un orden no especificado salvo que se pida ordenar; SQL no asigna identificadores únicos a las filas, por lo que puede haber filas idénticas, lo que normalmente no es deseable. PostgreSQL 18: Table Basics — Consultada: 2026-11-11.
6. PostgreSQL Global Development Group. PostgreSQL 18 Documentation, 5.5. Constraints — CHECK como la restricción más genérica; la clave primaria exige valores únicos y no nulos, como máximo una por tabla; la teoría relacional pide que toda tabla tenga clave primaria, pero PostgreSQL no lo impone; la clave foránea mantiene la integridad referencial entre dos tablas relacionadas. PostgreSQL 18: Constraints — Consultada: 2026-11-11.
7. PostgreSQL Global Development Group. PostgreSQL 18 Documentation, CREATE DOMAIN — un dominio es, en esencia, un tipo de dato con restricciones opcionales sobre el conjunto de valores permitidos; sirve para reunir en un solo lugar restricciones comunes a varias columnas. PostgreSQL 18: CREATE DOMAIN — Consultada: 2026-11-11.
8. PostgreSQL Global Development Group. PostgreSQL 18 Documentation, 7.2. Table Expressions — CROSS JOIN forma el producto cartesiano, con N × M filas; NATURAL es una forma abreviada de USING con todas las columnas de igual nombre y es considerablemente más riesgoso ante cambios del esquema. PostgreSQL 18: Table Expressions — Consultada: 2026-11-11.
9. PostgreSQL Global Development Group. PostgreSQL 18 Documentation, 7.4. Combining Queries (UNION, INTERSECT, EXCEPT) — unión, intersección y diferencia; eliminan filas duplicadas salvo con ALL; las consultas deben ser compatibles para la unión (mismo número de columnas y tipos compatibles). PostgreSQL 18: Combining Queries — Consultada: 2026-11-11.
10. PostgreSQL Global Development Group. PostgreSQL 18 Documentation, 7.3. Select Lists — DISTINCT elimina las filas duplicadas del resultado; ALL, el comportamiento por defecto, las conserva. PostgreSQL 18: Select Lists — Consultada: 2026-11-11.
11. PostgreSQL Global Development Group. PostgreSQL 18 Documentation, CREATE VIEW — las vistas simples son actualizables automáticamente; condiciones: exactamente una entrada en FROM, sin WITH, DISTINCT, GROUP BY, HAVING, LIMIT ni OFFSET, sin UNION, INTERSECT ni EXCEPT y sin agregados en la lista de selección. PostgreSQL 18: CREATE VIEW — Consultada: 2026-11-11.
12. PostgreSQL Global Development Group. Versioning Policy — la versión 18 tiene como versión menor actual la 18.6, con primera publicación el 25 de septiembre de 2025. PostgreSQL: política de versiones — Consultada: 2026-11-11.
13. SQLite. CREATE TABLE, sección sobre PRIMARY KEY — según el estándar SQL, la clave primaria debería implicar NOT NULL; por un error de algunas versiones antiguas, SQLite admite nulos en la mayoría de columnas de clave primaria salvo INTEGER PRIMARY KEY, tablas WITHOUT ROWID o STRICT, o columnas declaradas NOT NULL. SQLite: CREATE TABLE — Consultada: 2026-11-11.
14. SQLite. SQLite Foreign Key Support — las restricciones de clave foránea están desactivadas por defecto y la aplicación debe activarlas. SQLite: Foreign Key Support — Consultada: 2026-11-11.
15. Silberschatz, Abraham; Korth, Henry F. y Sudarshan, S. Database System Concepts, 7.ª edición, diapositivas del capítulo 2 «Intro to Relational Model» — seis operadores básicos del álgebra relacional: selección (σ), proyección (Π), unión (∪), diferencia (−), producto cartesiano (×) y renombrar (ρ); el join como combinación de selección y producto cartesiano. db-book.com: diapositivas del capítulo 2 — Consultada: 2026-11-11.
16. Silberschatz, Abraham; Korth, Henry F. y Sudarshan, S. Database System Concepts, 7.ª edición, diapositivas del capítulo 6, sección «Reduction to Relation Schemas» — entidad fuerte a esquema con los mismos atributos; atributos compuestos aplanados; entidad débil con la clave primaria de la entidad identificadora; atributo multivaluado como esquema aparte; relación muchos a muchos con las claves de las dos entidades y sus atributos descriptivos; relaciones uno a muchos con un atributo extra del lado «muchos», con posibles nulos si la participación es parcial; en 1:1, cualquiera de los dos lados. db-book.com: diapositivas del capítulo 6 — Consultada: 2026-11-11.
17. Zorrilla Pantaleón, Marta Elena y Duque Medina, Rafael. Tema 02. El modelo relacional, curso Bases de Datos, OCW Universidad de Cantabria, 2011 — «!CUIDADO!, una relación no es una tabla» (así, con el signo de apertura invertido en el original); propiedades de la relación como conjunto (sin tuplas iguales, sin orden de tuplas ni de atributos); las 12 reglas de Codd (Computerworld 1985) con sus nombres en español y la regla 0. Universidad de Cantabria: Tema 2, el modelo relacional (PDF) — Consultada: 2026-11-11.
18. Universidad Nacional de Río Cuarto (Argentina). Teórico 3: Álgebra Relacional, asignatura Bases de Datos, 2015 — el álgebra relacional como lenguaje procedimental cuyos operadores toman una o dos relaciones y devuelven otra; operadores básicos (selección, proyección, unión, diferencia, producto cartesiano, renombramiento) y derivados (intersección, join, división, theta join), que se forman combinando los básicos; equivalencia de la división con operadores básicos. UNRC: teórico de álgebra relacional (PDF) — Consultada: 2026-11-11.
19. PostgreSQL Global Development Group. PostgreSQL 18 Documentation, 9.2. Comparison Functions and Operators — los operadores de comparación ordinarios dan nulo, que significa «desconocido», cuando una entrada es nula (por ejemplo, 7 = NULL); no se debe escribir expresión = NULL; la lógica booleana incluye el valor desconocido (IS UNKNOWN). PostgreSQL 18: Comparison Functions and Operators — Consultada: 2026-11-11.

Cómo investigamos esta página

• Pregunta que responde: qué es el modelo relacional en sentido formal y cómo se traduce cada pieza a SQL
• Fuentes: identificadas 27 → incluidas 19
• Criterios de inclusión: artículos originales de Codd, documentación oficial de PostgreSQL y SQLite, libro de texto y cursos universitarios
• Fecha de corte de los datos: 2026-11-11