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

Descarga la tabla de transformación en PDF

Pasar del modelo entidad-relación al modelo relacional es convertir un diagrama (entidades, atributos y relaciones) en un conjunto de tablas con sus claves primarias y foráneas, listas para crearse en SQL. Es el paso que une el diseño conceptual con la base de datos real, y se hace siguiendo unas pocas reglas según el tipo de relación y su cardinalidad.

Si necesitas repasar entidades, atributos y cardinalidad antes de transformar, empieza por el modelo entidad-relación.

Cómo se escribe un esquema relacional

En esta guía cada tabla se escribe así:

Tabla (clave_primaria, atributo1, atributo2, clave_foránea → OtraTabla)

• Negrita y subrayado: clave primaria (PK). Si hay varios atributos subrayados, la clave primaria es la combinación de todos.
• → Tabla: clave foránea (FK) que apunta a la clave primaria de otra tabla.
• Los atributos sin marca son columnas normales.

Sobre la cardinalidad: en los diagramas de esta web, la pareja (mínimo, máximo) que aparece junto a una entidad indica con cuántas filas de esa entidad se relaciona cada fila de la otra. Por ejemplo, (1,1) junto a Cliente significa que cada diseño pertenece a exactamente un cliente.

Paso 1: entidades y atributos

• Entidad fuerte: se convierte en una tabla. Su identificador pasa a ser la clave primaria y sus atributos, las columnas.
• Atributo compuesto (por ejemplo, Dirección = calle + número + ciudad): se guardan sus componentes como columnas separadas.
• Atributo multivaluado (por ejemplo, Teléfonos): no cabe en una columna, así que se crea una tabla nueva con la clave de la entidad y el valor. La clave primaria es la combinación de las dos.
• Atributo derivado (por ejemplo, Edad a partir de la fecha de nacimiento): normalmente no se guarda, se calcula al consultar.
• Entidad débil: se convierte en una tabla que incluye la clave de la entidad fuerte de la que depende como clave foránea obligatoria, con borrado en cascada. Si su identificador solo es único dentro de la entidad fuerte, la clave primaria es la combinación de los dos.

Paso 2: relaciones binarias

Relación N:M (muchos a muchos)

La relación siempre se convierte en una tabla. Su clave primaria es la combinación de las claves primarias de las dos entidades, que a la vez son claves foráneas. Los atributos propios de la relación van en esta tabla.

Entidad1 (Id1, atributo1)
Entidad2 (Id2, atributo2)
Relación (Id1 → Entidad1, Id2 → Entidad2, atributoRelación)

Relación 1:N (uno a muchos)

La clave primaria de la entidad del lado 1 se copia como clave foránea en la tabla del lado N. Los atributos de la relación, si los hay, también pasan a la tabla del lado N. Lo que cambia es si esa clave foránea puede quedar vacía, y eso lo dice la participación que aparece junto a la entidad del lado 1:

• Participación (1,1): toda fila del lado N tiene pareja, así que la clave foránea es obligatoria (NOT NULL).
• Participación (0,1): puede haber filas del lado N sin pareja, así que la clave foránea admite valores nulos. Si la mayoría quedarían vacías, o la relación tiene muchos atributos propios, se puede crear una tabla aparte para la relación, con la clave del lado N como clave primaria.

Entidad1 (Id1, atributo1)
Entidad2 (Id2, atributo2, Id1 → Entidad1 NOT NULL, atributoRelación)

Con participación (0,1), lo habitual es la misma clave foránea pero admitiendo nulos. Con tabla aparte quedaría así:

Entidad1 (Id1, atributo1)
Entidad2 (Id2, atributo2)
Relación (Id2 → Entidad2, Id1 → Entidad1 NOT NULL, atributoRelación)

Relación 1:1 (uno a uno)

Depende de la participación de cada lado:

• (1,1) y (1,1): las dos entidades siempre van juntas, así que se pueden unir en una sola tabla, con la clave de cualquiera de ellas como clave primaria.
• (1,1) y (0,1): la clave de la entidad marcada con (1,1) se copia como clave foránea en la tabla de la entidad marcada con (0,1). Así la clave foránea nunca queda vacía. Debe ser NOT NULL y UNIQUE: el UNIQUE es lo que garantiza que la relación sigue siendo 1:1.
• (0,1) y (0,1): como cualquiera de los dos lados puede quedar sin pareja, se crea una tabla para la relación. Su clave primaria es la clave de una de las entidades, y la clave de la otra lleva UNIQUE. Si la clave primaria fuera la combinación de las dos, una fila podría emparejarse con varias y dejaría de ser 1:1.

Entidad1yEntidad2 (Id1, atributo1, Id2 UNIQUE, atributo2, atributoRelación)

En el diagrama, Entidad 2 está marcada con (1,1) y Entidad 1 con (0,1): cada fila de Entidad 1 tiene siempre su pareja en Entidad 2, así que la clave foránea va en Entidad 1.

Entidad1 (Id1, atributo1, Id2 → Entidad2 NOT NULL UNIQUE, atributoRelación)
Entidad2 (Id2, atributo2)

Entidad1 (Id1, atributo1)
Entidad2 (Id2, atributo2)
Relación (Id1 → Entidad1, Id2 → Entidad2 NOT NULL UNIQUE, atributoRelación)

Paso 3: relaciones reflexivas

Una relación reflexiva une una entidad consigo misma, cada lado con un papel distinto (por ejemplo, empleado y jefe). Se transforma igual que una binaria, pero las claves foráneas apuntan a la misma tabla:

• 1:1: una clave foránea a la propia tabla, con UNIQUE.
• 1:N: una clave foránea a la propia tabla, opcional si el papel lo es (el director general no tiene jefe).
• N:M: una tabla nueva con dos claves foráneas a la misma tabla, que juntas forman la clave primaria.

En el diagrama, cada fila se relaciona como mucho con otra de la misma tabla (0,1), que a su vez puede tener varias (0,N). Con empleados y jefes:

Empleado (IdEmpleado, nombre, IdJefe → Empleado)

Cada papel (Rol 1 y Rol 2) se convierte en una clave foránea. Por ejemplo, con asignaturas y sus prerrequisitos:

Asignatura (IdAsignatura, nombre)
Prerrequisito (IdAsignatura → Asignatura, IdPrerrequisito → Asignatura)

Paso 4: relaciones ternarias

Una relación entre tres entidades siempre se convierte en una tabla, con las claves de las tres entidades como claves foráneas y los atributos propios de la relación. Lo que cambia es qué claves forman la clave primaria:

Cardinalidad	Clave primaria de la tabla	Ejemplo
N:N:N	Las tres claves	Relación (Id1, Id2, Id3)
1:N:N	Las dos claves de los lados N. La del lado 1 es solo clave foránea	Relación (Id1, Id2, Id3)
1:1:N	La clave del lado N más una de las claves de los lados 1. La otra combinación lleva UNIQUE	Relación (Id1, Id2, Id3)
1:1:1	Dos claves cualesquiera. Las otras combinaciones de dos llevan UNIQUE	Relación (Id1, Id2, Id3)

La regla general: las claves de los lados con cardinalidad máxima 1 no hacen falta para identificar una fila, porque quedan determinadas por las demás.

Paso 5: generalización y especialización

Cuando una entidad general (supertipo) se divide en subtipos, hay tres opciones. Usaremos el ejemplo de Empleado, que se especializa en Arquitecto, Administrativo e Ingeniero:

1. Una sola tabla para todo: el supertipo absorbe los atributos de todos los subtipos y una columna discriminadora indica el tipo de cada fila. Es la opción más sencilla, pero deja muchas columnas vacías.
   Empleado (IdEmpleado, nombre, dirección, fechaNacimiento, salario, puesto, comisiones, númeroProyectos, pulsaciones, nivel, especialidad, añosExperiencia)
2. Una tabla por subtipo: cada subtipo hereda los atributos del supertipo y este desaparece. Solo es válida si la jerarquía es total y exclusiva (todo empleado es exactamente de un tipo).
   Arquitecto (IdEmpleado, nombre, dirección, fechaNacimiento, salario, comisiones, númeroProyectos) y así con cada subtipo.
3. Una tabla para el supertipo y otra por subtipo: cada subtipo guarda solo sus atributos y usa la clave del supertipo como clave primaria y foránea a la vez (una relación 1:1). Es la opción más flexible y la que mejor encaja con cualquier tipo de jerarquía.
   Empleado (IdEmpleado, nombre, dirección, fechaNacimiento, salario, puesto)
Arquitecto (IdEmpleado → Empleado, comisiones, númeroProyectos)

Ejemplo completo: la imprenta

Este es el diagrama de la imprenta que se explica en la guía del modelo entidad-relación. Vamos a transformarlo paso a paso.

1. Entidades fuertes: Cliente, Producto, Factura, Empleado y Departamento pasan a ser tablas con su identificador como clave primaria.
2. Atributos multivaluados: los teléfonos de Cliente y de Empleado van a dos tablas nuevas.
3. Pertenece (N:1, cada empleado pertenece a un departamento, participación (1,1)): la clave de Departamento pasa a Empleado como clave foránea obligatoria.
4. Enviar (1:N) y la entidad débil Diseño: la clave del cliente pasa a Diseño como clave foránea obligatoria, con borrado en cascada.
5. Realiza (N:M entre Producto y Empleado): nueva tabla con las dos claves como clave primaria.
6. Solicita (ternaria 1:N:M; Cliente en el lado 1): nueva tabla. La clave primaria son las claves de Producto y Factura; la de Cliente es solo clave foránea.

El esquema relacional resultante:

Cliente (dni_cif, nombre, apellidos, email, direccion, cp, localidad, tipo_cliente)
TelefonoCliente (dni_cif → Cliente, telefono)
Producto (nombre_producto, descripcion, tamano, tipo_papel, impresion, acabado)
Factura (num_factura, importe, pago, envio)
Solicita (dni_cif → Cliente, nombre_producto → Producto, num_factura → Factura)
Diseno (id_diseno, formato, tamano, dni_cif → Cliente)
Departamento (nombre_departamento, email)
Empleado (dni, seguridad_social, nombre, apellidos, email, direccion, salario, comision, nombre_departamento → Departamento)
TelefonoEmpleado (dni → Empleado, telefono)
Realiza (nombre_producto → Producto, dni → Empleado)

Y en SQL (válido en PostgreSQL y MySQL):

CREATE TABLE cliente (
  dni_cif      VARCHAR(12) PRIMARY KEY,
  nombre       VARCHAR(80) NOT NULL,
  apellidos    VARCHAR(120),
  email        VARCHAR(120),
  direccion    VARCHAR(150),
  cp           CHAR(5),
  localidad    VARCHAR(80),
  tipo_cliente VARCHAR(20)
);

CREATE TABLE telefono_cliente (
  dni_cif  VARCHAR(12),
  telefono VARCHAR(15),
  PRIMARY KEY (dni_cif, telefono),
  FOREIGN KEY (dni_cif) REFERENCES cliente (dni_cif) ON DELETE CASCADE
);

CREATE TABLE producto (
  nombre_producto VARCHAR(80) PRIMARY KEY,
  descripcion     VARCHAR(255),
  tamano          VARCHAR(20),
  tipo_papel      VARCHAR(40),
  impresion       VARCHAR(40),
  acabado         VARCHAR(40)
);

CREATE TABLE factura (
  num_factura VARCHAR(20) PRIMARY KEY,
  importe     DECIMAL(10,2) NOT NULL,
  pago        VARCHAR(20),
  envio       VARCHAR(40)
);

-- Ternaria 1:N:M: la clave del lado 1 (cliente) no forma parte de la clave primaria
CREATE TABLE solicita (
  dni_cif         VARCHAR(12) NOT NULL,
  nombre_producto VARCHAR(80),
  num_factura     VARCHAR(20),
  PRIMARY KEY (nombre_producto, num_factura),
  FOREIGN KEY (dni_cif) REFERENCES cliente (dni_cif),
  FOREIGN KEY (nombre_producto) REFERENCES producto (nombre_producto),
  FOREIGN KEY (num_factura) REFERENCES factura (num_factura)
);

-- Entidad débil: no existe sin su cliente
CREATE TABLE diseno (
  id_diseno INT PRIMARY KEY,
  formato   VARCHAR(20),
  tamano    VARCHAR(20),
  dni_cif   VARCHAR(12) NOT NULL,
  FOREIGN KEY (dni_cif) REFERENCES cliente (dni_cif) ON DELETE CASCADE
);

CREATE TABLE departamento (
  nombre_departamento VARCHAR(60) PRIMARY KEY,
  email               VARCHAR(120)
);

CREATE TABLE empleado (
  dni                 VARCHAR(9) PRIMARY KEY,
  seguridad_social    VARCHAR(12) UNIQUE,
  nombre              VARCHAR(80) NOT NULL,
  apellidos           VARCHAR(120),
  email               VARCHAR(120),
  direccion           VARCHAR(150),
  salario             DECIMAL(10,2),
  comision            DECIMAL(10,2),
  nombre_departamento VARCHAR(60) NOT NULL,
  FOREIGN KEY (nombre_departamento) REFERENCES departamento (nombre_departamento)
);

CREATE TABLE telefono_empleado (
  dni      VARCHAR(9),
  telefono VARCHAR(15),
  PRIMARY KEY (dni, telefono),
  FOREIGN KEY (dni) REFERENCES empleado (dni) ON DELETE CASCADE
);

-- N:M entre producto y empleado
CREATE TABLE realiza (
  nombre_producto VARCHAR(80),
  dni             VARCHAR(9),
  PRIMARY KEY (nombre_producto, dni),
  FOREIGN KEY (nombre_producto) REFERENCES producto (nombre_producto),
  FOREIGN KEY (dni) REFERENCES empleado (dni)
);

En SQL los nombres van sin tildes ni «ñ» (diseno, tamano) para evitar problemas de codificación. Si quieres saber más sobre CREATE TABLE y las restricciones, tienes la guía para crear tablas en SQL.

Tabla resumen

Elemento del diagrama	Resultado en el modelo relacional
Entidad fuerte	Tabla; el identificador es la clave primaria
Entidad débil	Tabla con la clave de la entidad fuerte como clave foránea obligatoria (y como parte de la clave primaria si su identificador no basta)
Atributo multivaluado	Tabla nueva: clave de la entidad + valor
Relación N:M	Tabla nueva; clave primaria = claves de las dos entidades
Relación 1:N	Clave del lado 1 como clave foránea en el lado N (obligatoria si la participación es (1,1))
Relación 1:1 (1,1)(1,1)	Una sola tabla
Relación 1:1 (1,1)(0,1)	Clave foránea NOT NULL UNIQUE en la tabla del lado (0,1)
Relación 1:1 (0,1)(0,1)	Tabla nueva; clave primaria = una clave, la otra UNIQUE
Reflexiva	Como la binaria equivalente, con claves foráneas a la misma tabla
Ternaria	Tabla nueva; clave primaria = claves de los lados N
Generalización	Una tabla, una por subtipo o supertipo + subtipos

Preguntas frecuentes

¿Qué diferencia hay entre el modelo entidad-relación y el modelo relacional?

El modelo entidad-relación es conceptual: describe qué datos existen y cómo se relacionan, sin pensar en tablas. El modelo relacional es lógico: organiza esos datos en tablas con claves primarias y foráneas, listas para implementarse en un sistema gestor de bases de datos.

¿Cuándo se convierte una relación en una tabla?

Siempre en las relaciones N:M y en las ternarias. En las 1:1 con participación (0,1) en los dos lados, y opcionalmente en las 1:N con participación (0,1), cuando la clave foránea quedaría vacía casi siempre. En el resto de casos, la relación se representa con una clave foránea.

¿En qué tabla va la clave foránea de una relación 1:N?

En la tabla del lado N. Por ejemplo, si un departamento tiene muchos empleados, cada empleado guarda el departamento al que pertenece, y no al revés.

¿Qué pasa con los atributos de una relación?

Van a la tabla que representa la relación. Si la relación no tiene tabla propia (una 1:N resuelta con clave foránea), van a la tabla donde está la clave foránea.

¿Hace falta normalizar después de transformar?

Si el diagrama está bien hecho, las tablas resultantes suelen estar ya en tercera forma normal. Aun así, conviene revisarlas, sobre todo si hay atributos que dependen de otros que no son clave. Lo explicamos en la guía para diseñar una base de datos relacional.

Para seguir aprendiendo:

• Qué es una base de datos relacional
• Modelo entidad-relación: entidades, atributos, relaciones y cardinalidad
• Cómo crear tablas en SQL