0Pricing
SQL Interview Prep · Lección

Modelado ER y cardinalidad de relaciones

Traducir los requisitos en entidades, relaciones y tablas de unión.

Modelado ER y cardinalidad de relaciones es una lección gratuita de SQL Interview Prep en CoddyKit. Esta es la lección 2 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de SQL Interview Prep, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de SQL Interview Prep incluye 4 lecciones en total.

Por qué el modelado ER aparece en las entrevistas

Después de la normalización, los entrevistadores comprueban si puede convertir los requisitos en un esquema. El enunciado suele ser abierto: «Diseñe una base de datos para una aplicación de viajes compartidos» o «Modele un sistema de biblioteca».

Se trata de un ejercicio de modelado entidad-relación (ER). Evalúan cómo identifica entidades, atributos y las relaciones entre ellos, incluida la cardinalidad.

La habilidad consiste en convertir los sustantivos y verbos de una descripción en tablas y claves foráneas.

Entidades, atributos y relaciones

Tres componentes básicos forman cualquier modelo ER:

  • Entidad: aquello sobre lo que almacena datos (Customer, Order, Product). Normalmente se convierte en una tabla.
  • Atributo: una propiedad de una entidad (name, price, created_at). Normalmente se convierte en una columna.
  • Relación: la forma en que se conectan las entidades (un Customer places un Order). Se implementa mediante claves foráneas o tablas de unión.

Consejo a partir del enunciado: los sustantivos se convierten en entidades o atributos, y los verbos en relaciones.

Cardinalidad: el concepto central

La cardinalidad describe cuántas instancias de una entidad se relacionan con otra. Hay tres categorías:

  • Uno a uno (1:1): una fila de esta tabla corresponde como máximo a una fila de la otra.
  • Uno a muchos (1:N): una fila de esta tabla corresponde a muchas filas de la otra (es el caso más común).
  • Muchos a muchos (M:N): las filas de ambos lados corresponden a muchas filas del otro lado.

Determinar correctamente la cardinalidad indica dónde colocar las claves foráneas y si necesita una tabla de unión.

Implementación de relaciones uno a muchos

Una relación uno a muchos se implementa colocando la clave foránea en el lado de «muchos». Un cliente tiene muchos pedidos, por lo que cada fila de pedido contiene customer_id.

En una entrevista, indique siempre la dirección de forma explícita: «De un cliente a muchos pedidos, por lo que la FK está en orders».

CREATE TABLE customers (
  customer_id INT PRIMARY KEY,
  name        VARCHAR(100)
);

CREATE TABLE orders (
  order_id    INT PRIMARY KEY,
  customer_id INT NOT NULL,
  order_date  DATE,
  FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
);

Implementación de relaciones muchos a muchos

Una base de datos relacional no puede almacenar directamente una relación M:N. La respuesta que esperan los entrevistadores es una tabla de unión (también llamada tabla puente, de enlace o asociativa).

Los estudiantes se matriculan en muchos cursos, y cada curso tiene muchos estudiantes. Cree una tabla enrollments cuya clave combine ambas claves foráneas. Así se resuelve M:N en dos relaciones 1:N.

CREATE TABLE students (
  student_id INT PRIMARY KEY,
  name       VARCHAR(100)
);

CREATE TABLE courses (
  course_id  INT PRIMARY KEY,
  title      VARCHAR(100)
);

CREATE TABLE enrollments (
  student_id INT,
  course_id  INT,
  enrolled_at DATE,
  PRIMARY KEY (student_id, course_id),
  FOREIGN KEY (student_id) REFERENCES students(student_id),
  FOREIGN KEY (course_id)  REFERENCES courses(course_id)
);

La tabla de unión puede almacenar datos

Una pregunta de seguimiento habitual es: «¿Dónde se almacena la calificación que obtuvo un estudiante en un curso?»

La calificación pertenece a la relación, no únicamente al estudiante ni al curso. Por eso se almacena en la tabla de unión. Esta es la idea que los entrevistadores quieren comprobar: los atributos de una relación M:N se almacenan en la tabla puente.

Ejemplos: fecha de matrícula, calificación, cantidad en una línea de pedido y un rol en la pertenencia a un proyecto.

ALTER TABLE enrollments
  ADD COLUMN grade CHAR(2);
-- grade describes THIS student in THIS course,
-- so it belongs on the junction table

Implementación de relaciones uno a uno

La relación 1:1 es menos frecuente. Se implementa dando a la tabla dependiente una clave foránea que también sea una clave única (a menudo, la propia clave primaria).

Por ejemplo, user y user_profile pueden contener detalles ampliados y opcionales. Hacer que user_id sea la clave primaria de la tabla de perfiles garantiza que cada usuario tenga como máximo un perfil.

CREATE TABLE users (
  user_id INT PRIMARY KEY,
  email   VARCHAR(255)
);

CREATE TABLE user_profiles (
  user_id INT PRIMARY KEY,           -- 1:1 enforced here
  bio     TEXT,
  avatar_url VARCHAR(255),
  FOREIGN KEY (user_id) REFERENCES users(user_id)
);

Opcionalidad y participación

La cardinalidad tiene una segunda dimensión que suele interesar a los entrevistadores: la opcionalidad (también llamada participación).

  • Obligatoria: todo pedido debe tener un cliente, por lo que customer_id es NOT NULL.
  • Opcional: un usuario puede tener un perfil o no, por lo que la relación puede estar ausente.

La participación obligatoria se expresa con NOT NULL en la clave foránea. Mencionar la posibilidad de NULL demuestra que tiene en cuenta restricciones reales, no solo las formas.

Relaciones autorreferenciales

Algunas relaciones apuntan de una entidad a sí misma. Un empleado tiene un gerente que también es empleado; una categoría tiene una categoría padre.

Esto se modela con una clave foránea que referencia la misma tabla. Los entrevistadores esperan este caso en organigramas y estructuras de árbol, y se combina naturalmente con self-joins y CTE recursivas.

CREATE TABLE employees (
  employee_id INT PRIMARY KEY,
  name        VARCHAR(100),
  manager_id  INT NULL,
  FOREIGN KEY (manager_id) REFERENCES employees(employee_id)
);
-- manager_id NULL = top of the hierarchy (e.g. CEO)

Un breve recorrido por el modelado

Practique el método de convertir verbos en relaciones. Enunciado: «Los clientes realizan pedidos; cada pedido contiene muchos productos; los productos pertenecen a proveedores».

  • Customer 1:N Order (FK customer_id en orders).
  • Order M:N Product -> tabla de unión order_items (con quantity).
  • Supplier 1:N Product (FK supplier_id en products).

Indique cada cardinalidad y dónde se coloca la clave. Esa explicación es lo que marca la diferencia en la entrevista.

Preguntas aclaratorias que debe hacer

Los entrevistadores valoran a los candidatos que hacen preguntas antes de diseñar. Algunas buenas preguntas aclaratorias son:

  • «¿Puede un producto pertenecer a más de un proveedor?» (determina 1:N frente a M:N).
  • «¿Debe todo pedido tener al menos un artículo?» (participación).
  • «¿Necesitamos el historial o solo el estado actual?» (determina si hacen falta tablas adicionales).

Las respuestas cambian la cardinalidad y la cantidad de tablas, así que nunca dé nada por sentado. Hacer preguntas demuestra experiencia.

Comprobación rápida

Está modelando estudiantes y cursos, donde cada estudiante puede tomar muchos cursos y cada curso tiene muchos estudiantes.

Repaso: modelado ER y cardinalidad

Ahora puede abordar una pregunta abierta de diseño de esquemas:

  • Convierta los sustantivos en entidades o atributos y los verbos en relaciones.
  • 1:N: coloque la clave foránea en el lado de muchos.
  • M:N: use una tabla de unión que contenga ambas claves foráneas y cualquier atributo de la relación.
  • 1:1: use una clave compartida o única en la tabla dependiente.
  • Use NOT NULL para expresar la participación obligatoria y claves foráneas autorreferenciadas para las jerarquías.
  • Haga preguntas aclaratorias antes de establecer la cardinalidad.

Preguntas frecuentes

¿La lección «Modelado ER y cardinalidad de relaciones» es gratis?

Sí — el texto completo de «Modelado ER y cardinalidad de relaciones» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de SQL Interview Prep, actualiza a CoddyKit PRO. El curso de SQL Interview Prep incluye 4 lecciones en total.

¿Qué aprenderé en «Modelado ER y cardinalidad de relaciones»?

Traducir los requisitos en entidades, relaciones y tablas de unión. Practicas SQL Interview Prep con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar SQL Interview Prep?

No se requiere experiencia previa. SQL Interview Prep en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 2 de 4.

¿Cuánto tiempo toma la lección «Modelado ER y cardinalidad de relaciones»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de SQL Interview Prep?

Sí. Cada lección de SQL Interview Prep incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

  1. Normalización hasta la 3NF
  2. Modelado ER y cardinalidad de relaciones
  3. Esquema de estrella y diseño de almacenes de datos
  4. Colección completa de problemas de simulación de entrevista
← Volver a SQL Interview Prep