Módulo 06: Relaciones: conceptos generales y cardinalidades

Objetivos del módulo

  • Definir qué es una relación (interrelación) y distinguir entre tipo de relación y ocurrencia
  • Conocer el grado de una relación: reflexivas, binarias, ternarias y n-arias
  • Usar los papeles (roles) para dar sentido a cada línea de una relación
  • Entender a fondo el tipo de correspondencia (1:1, 1:N, N:M) y las cardinalidades mínimas y máximas
  • Razonar las cardinalidades con diagramas de ocurrencias
  • Dominar la convención de cardinalidades del curso y traducirla a las demás: participación (look-here), Chen original, pata de gallo, Barker y UML
  • Deducir las cardinalidades a partir de un enunciado con un método sistemático
  • Decidir dónde colocar los atributos de una relación según su cardinalidad
  • Comprender las dependencias de existencia que provoca una participación mínima 1

1. El concepto de relación

1.1 Qué es una relación

Las entidades no viven aisladas: los clientes realizan pedidos, los profesores imparten asignaturas, los empleados trabajan en departamentos. Esas asociaciones son las relaciones.

📘 Concepto: Una relación o interrelación (relationship) es una asociación entre dos o más entidades que tiene significado para el sistema y que interesa registrar.

En muchos libros españoles (de Miguel, Piattini) se usa el término interrelación precisamente para no confundirlo con la relación del modelo relacional, que es otra cosa: una tabla. En este curso usaremos “relación” cuando hablemos del modelo E/R, y “tabla” (o “relación” en sentido formal, en los módulos 16 a 20) cuando hablemos del modelo relacional. El contexto siempre deja claro de qué se trata.

1.2 Representación

En la notación del curso, una relación se dibuja con un rombo que contiene su nombre, unido con líneas a las entidades que asocia:

flowchart LR
    CLIENTE[CLIENTE] --- realiza{realiza}
    realiza --- PEDIDO[PEDIDO]

Convenciones de nombre:

  • Un verbo (o una forma verbal) en minúsculas, que permita leer la relación como una frase: “un cliente realiza pedidos”.
  • Si hace falta, con guion bajo: trabaja_en, es_jefe_de.
  • Debe leerse con sentido al menos en un sentido; idealmente, en los dos (“un pedido es realizado por un cliente”).
  • Evita nombres vacíos como tiene, relacion o asociado cuando exista un verbo más preciso. tiene es aceptable para relaciones de composición evidentes (un pedido tiene líneas, un hotel tiene habitaciones).

1.3 Tipo de relación y ocurrencia

Igual que con las entidades, hay que distinguir el tipo de la ocurrencia:

📘 Concepto: Un tipo de relación es la descripción de una asociación entre tipos de entidades: “PROFESOR imparte ASIGNATURA”. Es lo que se dibuja en el diagrama.

📘 Concepto: Una ocurrencia (o ejemplar) de relación es una asociación concreta entre ocurrencias de entidades: “Marta imparte Bases de Datos”. Formalmente, un tipo de relación R entre las entidades E1, E2, …, En es un conjunto de tuplas (e1, e2, …, en), donde cada ei es una ocurrencia de Ei. Es decir, R es un subconjunto del producto cartesiano E1 × E2 × … × En.

Para razonar sobre relaciones, la herramienta más útil es el diagrama de ocurrencias: dibujamos las ocurrencias de cada entidad como puntos de un conjunto y las ocurrencias de la relación como líneas que los unen.

flowchart LR
    subgraph SP["PROFESOR"]
        p1["Marta"]
        p2["Pedro"]
        p3["Ana"]
    end
    subgraph SR["imparte"]
        r1(("r1"))
        r2(("r2"))
        r3(("r3"))
    end
    subgraph SA["ASIGNATURA"]
        a1["Bases de Datos"]
        a2["Programación"]
        a3["Entornos"]
    end
    p1 --- r1 --- a1
    p1 --- r2 --- a3
    p2 --- r3 --- a2

En este ejemplar, la relación imparte tiene tres ocurrencias: r1 = (Marta, Bases de Datos), r2 = (Marta, Entornos) y r3 = (Pedro, Programación). Ana no imparte ninguna asignatura (todavía).

⚠️ Importante: Como una relación es un conjunto de tuplas, no puede contener dos veces la misma tupla. Entre una ocurrencia concreta de PROFESOR y una concreta de ASIGNATURA hay, como mucho, una ocurrencia de imparte. Esta propiedad, que parece una curiosidad matemática, tiene consecuencias de diseño muy importantes (sección 9.3).

2. El grado de una relación

📘 Concepto: El grado de una relación es el número de entidades (o, más exactamente, de papeles) que participan en ella.

Grado Nombre Ejemplo Frecuencia
1 Unaria, reflexiva o recursiva EMPLEADO es jefe de EMPLEADO Habitual
2 Binaria CLIENTE realiza PEDIDO La gran mayoría
3 Ternaria PROFESOR imparte ASIGNATURA en GRUPO Ocasional
n > 3 n-aria MEDICO prescribe MEDICAMENTO a PACIENTE en CONSULTA Rara

Este módulo presenta los conceptos comunes a todas ellas. Cada tipo tiene su propio módulo de estudio en profundidad: el módulo de relaciones binarias, el módulo de relaciones reflexivas y el módulo de relaciones ternarias.

2.1 Relaciones binarias

Asocian dos entidades distintas. Son la base de casi todos los esquemas y sobre ellas explicaremos las cardinalidades en este módulo.

flowchart LR
    SOCIO[SOCIO] --- presta{presta}
    presta --- EJEMPLAR[EJEMPLAR]

2.2 Relaciones reflexivas (unarias)

Asocian una entidad consigo misma: las dos líneas del rombo llegan a la misma entidad, y cada una juega un papel distinto. En el esquema EMPRESA, un empleado puede ser jefe de otros empleados (columna jefe_id de empleados):

flowchart LR
    EMPLEADO[EMPLEADO] ---|"(0,1) jefe"| dirige{dirige}
    dirige ---|"(0,n) subordinado"| EMPLEADO

Otros ejemplos típicos: una asignatura es prerrequisito de otras asignaturas; una persona está casada con otra persona; un usuario de una red social sigue a otros usuarios; una categoría de producto es subcategoría de otra (columna categoria_padre_id de categorias en EMPRESA). Se estudian en detalle en el módulo de relaciones reflexivas.

2.3 Relaciones ternarias y n-arias

Asocian tres (o más) entidades a la vez, de forma que la asociación solo tiene sentido con las tres juntas. El ejemplo clásico: un proveedor suministra una pieza a un proyecto.

flowchart LR
    PROVEEDOR[PROVEEDOR] --- suministra{suministra}
    suministra --- PIEZA[PIEZA]
    suministra --- PROYECTO[PROYECTO]
    suministra --- s_cant([cantidad])

Una ocurrencia es, por ejemplo, (Hierros Martín, tornillo M8, Puente del Turia), con una cantidad de 5000 unidades.

⚠️ Importante: Una relación ternaria no equivale, en general, a tres relaciones binarias entre las mismas entidades. Saber que Hierros Martín suministra tornillos (a alguien), que suministra al Puente del Turia (algo) y que el Puente del Turia usa tornillos (de alguien) no permite deducir que Hierros Martín suministre tornillos al Puente del Turia: quizá los tornillos se los suministra otro proveedor. Cuándo usar una ternaria y cómo leer sus cardinalidades se estudia en el módulo de relaciones ternarias.

3. Papeles (roles)

📘 Concepto: El papel o rol (role) es la función que desempeña una entidad dentro de una relación. Se escribe como una etiqueta en la línea que une la entidad con el rombo.

En la mayoría de las relaciones binarias el papel es evidente y no se escribe: en “CLIENTE realiza PEDIDO”, el cliente es el que realiza y el pedido el realizado. Pero hay dos situaciones en las que el papel es imprescindible:

  1. Relaciones reflexivas: las dos líneas llegan a la misma entidad, y sin papeles no se sabe cuál es el jefe y cuál el subordinado.
  2. Varias relaciones entre las mismas entidades, o una relación en la que la misma entidad participa varias veces (un partido tiene un equipo local y un equipo visitante; un vuelo tiene un aeropuerto de origen y uno de destino).

En la notación del curso, el papel se escribe en la etiqueta de la línea junto a la cardinalidad: "(0,1) jefe".

Veamos el ejemplo de EMPRESA con ocurrencias reales del script empresa_datos.sql: Ana (100) es la directora general, y es la jefa de Luis (101) y Marta (102); Luis es jefe de Carmen (110) y de David (111).

flowchart TB
    e100["100 Ana"] -->|"jefe de"| e101["101 Luis"]
    e100 -->|"jefe de"| e102["102 Marta"]
    e101 -->|"jefe de"| e110["110 Carmen"]
    e101 -->|"jefe de"| e111["111 David"]

Cada flecha es una ocurrencia de dirige, y en cada una Ana, Luis o Marta juegan el papel de jefe y el otro empleado el de subordinado. Ana no tiene jefe (es la directora) y Carmen no tiene subordinados: ambas cosas son posibles porque las dos cardinalidades mínimas son 0.

💡 Consejo: Pon papeles siempre que dudes. No cuestan nada y evitan que el lector tenga que adivinar. En las reflexivas, sin papeles el diagrama es directamente incorrecto, porque no se puede leer.

4. Cardinalidad máxima: el tipo de correspondencia

4.1 Definición

Nos centramos ahora en las relaciones binarias entre dos entidades A y B, que son la base de todo.

📘 Concepto: La cardinalidad máxima de B en la relación R es el número máximo de ocurrencias de B con las que puede estar relacionada una ocurrencia de A. Solo nos interesa si ese máximo es 1 o muchos (n), aunque a veces es un número concreto (3, 5…).

📘 Concepto: El tipo de correspondencia (o razón de cardinalidad) de una relación binaria se obtiene combinando las dos cardinalidades máximas, y puede ser 1:1 (uno a uno), 1:N (uno a muchos) o N:M (muchos a muchos).

4.2 Correspondencia 1:1 (uno a uno)

Cada ocurrencia de A se relaciona como mucho con una de B, y cada ocurrencia de B como mucho con una de A.

Ejemplo: en una liga, cada equipo tiene un único entrenador y cada entrenador entrena a un único equipo.

flowchart LR
    subgraph SE["ENTRENADOR"]
        en1["Ibáñez"]
        en2["Mora"]
        en3["Salas"]
    end
    subgraph SQ["EQUIPO"]
        q1["Valencia BC"]
        q2["Unicaja"]
        q3["Gran Canaria"]
    end
    en1 --- q1
    en2 --- q2
    en3 --- q3

Ningún punto tiene más de una línea en ninguno de los dos lados.

4.3 Correspondencia 1:N (uno a muchos)

Cada ocurrencia de A se relaciona con muchas de B, pero cada ocurrencia de B se relaciona como mucho con una de A.

Ejemplo: un cliente realiza muchos pedidos; cada pedido es de un único cliente.

flowchart LR
    subgraph SC["CLIENTE"]
        c1["1001"]
        c2["1002"]
        c3["1013"]
    end
    subgraph SPD["PEDIDO"]
        pd1["5001"]
        pd2["5007"]
        pd3["5002"]
        pd4["5010"]
    end
    c1 --- pd1
    c1 --- pd2
    c2 --- pd3
    c2 --- pd4

En el lado de CLIENTE salen varias líneas de un mismo punto (“uno a muchos”); en el lado de PEDIDO, a cada punto llega como mucho una. El cliente 1013 no tiene pedidos (como ocurre en EMPRESA). Es el tipo de relación más frecuente en cualquier esquema. (Los números de pedido de los diagramas de este módulo son ilustrativos.)

💡 Consejo: 1:N y N:1 son el mismo tipo de correspondencia leído en sentidos opuestos. “CLIENTE–PEDIDO es 1:N” y “PEDIDO–CLIENTE es N:1” dicen lo mismo. Lo importante es saber en qué lado está el “muchos”.

4.4 Correspondencia N:M (muchos a muchos)

Cada ocurrencia de A se relaciona con muchas de B, y cada ocurrencia de B con muchas de A.

Ejemplo: un alumno se matricula en muchas asignaturas y en una asignatura hay muchos alumnos.

flowchart LR
    subgraph SAL["ALUMNO"]
        al1["Ana"]
        al2["Juan"]
        al3["Marta"]
    end
    subgraph SAS["ASIGNATURA"]
        as1["Bases de Datos"]
        as2["Programación"]
        as3["Lenguajes de Marcas"]
    end
    al1 --- as1
    al1 --- as2
    al2 --- as1
    al2 --- as3
    al3 --- as1

Hay puntos con varias líneas en los dos lados: Ana tiene dos asignaturas y Bases de Datos tiene tres alumnos.

4.5 Resumen: de las máximas al tipo

Máx. de B por cada A Máx. de A por cada B Tipo Ejemplo
1 1 1:1 EQUIPO–ENTRENADOR
n 1 1:N CLIENTE–PEDIDO
1 n N:1 (= 1:N al revés) PEDIDO–CLIENTE
n n N:M ALUMNO–ASIGNATURA

⚠️ Importante: Para obtener el tipo de correspondencia siempre hay que mirar los dos sentidos. Decir “un cliente tiene muchos pedidos” no basta para saber que la relación es 1:N: también hay que saber que “cada pedido es de un único cliente”. Si un pedido pudiera ser compartido por varios clientes, sería N:M.

5. Cardinalidad mínima: la participación

5.1 Definición

📘 Concepto: La cardinalidad mínima de B en la relación R es el número mínimo de ocurrencias de B con las que debe estar relacionada cada ocurrencia de A. Casi siempre es 0 o 1.

  • Mínima 0: la relación es opcional para A. Puede existir una ocurrencia de A sin ninguna B asociada. Se habla de participación parcial de A.
  • Mínima 1: la relación es obligatoria para A. Toda ocurrencia de A tiene al menos una B asociada. Se habla de participación total de A.

5.2 La mínima en un diagrama de ocurrencias

En el diagrama de ocurrencias, la mínima se ve en los puntos sin líneas. Volvamos a EMPRESA y a la relación entre DEPARTAMENTO y EMPLEADO, con datos reales del script: el departamento 10 tiene a Ana (100); el 40 tiene a Isabel (130) y a Jorge (131); el departamento 70 no tiene empleados, y el empleado 160 (Tomás) no tiene departamento.

flowchart LR
    subgraph SD["DEPARTAMENTO"]
        d10["10 Dirección"]
        d40["40 Contabilidad"]
        d70["70 Investigación"]
    end
    subgraph SEM["EMPLEADO"]
        e100["100 Ana"]
        e130["130 Isabel"]
        e131["131 Jorge"]
        e160["160 Tomás"]
    end
    d10 --- e100
    d40 --- e130
    d40 --- e131
  • El departamento 70 no tiene líneas → un departamento puede tener 0 empleados → la mínima de EMPLEADO (por cada departamento) es 0.
  • El empleado 160 no tiene líneas → un empleado puede tener 0 departamentos → la mínima de DEPARTAMENTO (por cada empleado) es 0.

Si la empresa tuviera la regla “todo empleado debe estar asignado a un departamento”, Tomás no podría existir sin línea, y la mínima de DEPARTAMENTO sería 1.

⚠️ Importante: Un diagrama de ocurrencias es un ejemplo, no una demostración. Que en los datos de hoy todos los departamentos tengan empleados no significa que la mínima sea 1: la mínima la fijan las reglas del negocio, que dicen qué estados son válidos. Los diagramas de ocurrencias sirven para razonar (y para encontrar contraejemplos): “¿podría existir un departamento sin empleados? Sí, cuando se acaba de crear”.

5.3 Valores distintos de 0, 1 y n

Las cardinalidades no tienen por qué ser solo 0, 1 y n. Cuando el negocio fija límites concretos, se escriben:

Pareja Significado Ejemplo
(0,3) Como mucho tres Un socio puede tener como máximo 3 libros prestados a la vez
(2,2) Exactamente dos Un partido de tenis individual lo juegan exactamente 2 jugadores
(1,5) De uno a cinco Un usuario de streaming crea entre 1 y 5 perfiles
(11,25) Entre once y veinticinco Un equipo de fútbol tiene entre 11 y 25 jugadores con ficha

Estos límites concretos se dibujan en el diagrama, pero al pasar al modelo relacional (módulo 17) normalmente no se pueden imponer con restricciones declarativas: el diseño lógico solo distingue entre “como mucho uno” y “muchos”. Hay que documentarlos y controlarlos en la aplicación o con programación en la base de datos.

6. La convención del curso: la pareja (mín, máx)

6.1 La regla

Juntando mínimo y máximo obtenemos una pareja (mín, máx) para cada lado de la relación. Este es el punto más importante del módulo, así que lo enunciamos con precisión:

📘 Concepto: Convención del curso. En una relación binaria entre A y B, la pareja (mín, máx) escrita en la línea de la entidad B indica con cuántas ocurrencias de B (como mínimo y como máximo) se relaciona una ocurrencia de A. Simétricamente, la pareja escrita junto a A indica con cuántas ocurrencias de A se relaciona una ocurrencia de B.

flowchart LR
    PROFESOR[PROFESOR] ---|"(1,1)"| imparte{"imparte<br/>1:N"}
    imparte ---|"(0,n)"| ASIGNATURA[ASIGNATURA]

Cómo leerlo, paso a paso:

  1. Elige una entidad de partida y piensa en una ocurrencia cualquiera: “un profesor”.
  2. Cruza el rombo con el verbo: “un profesor imparte…”.
  3. Lee la pareja del otro lado, la que está junto a la entidad de llegada: “…entre 0 y n asignaturas”.
  4. Repite en el sentido contrario: “una asignatura es impartida por… (1,1) … exactamente un profesor”.

El truco para no equivocarse es leer siempre la frase completa con la estructura “un/una ‹entidad de partida› ‹verbo› ‹pareja de la entidad de llegada› ‹entidad de llegada›”.

El tipo de correspondencia se obtiene de los máximos: el máximo junto a PROFESOR es 1 y el máximo junto a ASIGNATURA es n, así que es 1:N (un profesor, muchas asignaturas). En este curso lo indicaremos en el texto o dentro del rombo, como en el diagrama anterior.

⚠️ Importante: Esta convención es la de la notación de Chen extendida que se usa habitualmente en España y coincide con la forma de leer la pata de gallo y UML: lo que está escrito junto a una entidad habla del número de ocurrencias de esa entidad. Existe otra convención, la de participación, que pone la pareja en el lado contrario. Las dos son correctas, pero no se pueden mezclar: la sección 7 explica cómo traducir de una a otra. En TODO el curso se usa la convención descrita aquí.

6.2 Ejemplo trabajado: el esquema EMPRESA

Apliquemos la regla a tres relaciones del esquema EMPRESA, comprobándolas con las restricciones del script empresa_crear.sql:

Relación Pregunta Respuesta Pareja Dónde se escribe
DEPARTAMENTO–EMPLEADO ¿En cuántos departamentos trabaja un empleado? En ninguno o en uno (dept_id admite nulos) (0,1) Junto a DEPARTAMENTO
  ¿Cuántos empleados tiene un departamento? De ninguno (el 70) a muchos (0,n) Junto a EMPLEADO
CLIENTE–PEDIDO ¿Cuántos clientes tiene un pedido? Exactamente uno (cliente_id es NOT NULL) (1,1) Junto a CLIENTE
  ¿Cuántos pedidos tiene un cliente? De ninguno (1013, 1014) a muchos (0,n) Junto a PEDIDO
EMPLEADO–CLIENTE (comercial) ¿Cuántos comerciales tiene un cliente? Ninguno o uno (comercial_id admite nulos) (0,1) Junto a EMPLEADO
  ¿Cuántos clientes lleva un empleado? De ninguno a muchos (0,n) Junto a CLIENTE 
flowchart LR
    DEPARTAMENTO[DEPARTAMENTO] ---|"(0,1)"| trabaja{"trabaja<br/>1:N"}
    trabaja ---|"(0,n)"| EMPLEADO[EMPLEADO]
    EMPLEADO ---|"(0,1) comercial"| atiende{"atiende<br/>1:N"}
    atiende ---|"(0,n)"| CLIENTE[CLIENTE]
    CLIENTE ---|"(1,1)"| realiza{"realiza<br/>1:N"}
    realiza ---|"(0,n)"| PEDIDO[PEDIDO]

Léelo en voz alta en los dos sentidos de cada relación:

  • “Un departamento tiene de 0 a n empleados.” / “Un empleado trabaja en 0 o 1 departamentos.”
  • “Un empleado (en su papel de comercial) atiende de 0 a n clientes.” / “Un cliente es atendido por 0 o 1 comerciales.”
  • “Un cliente realiza de 0 a n pedidos.” / “Un pedido es realizado por exactamente 1 cliente.”

💡 Consejo: Fíjate en que el diseño conceptual se puede reconstruir a partir de las restricciones de las tablas: una clave ajena que admite nulos indica una mínima 0 (en el lado de la entidad referenciada), y una clave ajena NOT NULL indica una mínima 1. Lo verás al revés en el módulo 17, al transformar el diagrama en tablas.

6.3 Las combinaciones más habituales

Combinando mínimos (0 o 1) y máximos (1 o n) en los dos lados salen muchas posibilidades. Esta tabla resume las más frecuentes; el estudio de todos los casos, con su transformación, está en el módulo de relaciones binarias.

Junto a A Junto a B Tipo Se lee Ejemplo (A – B)
(1,1) (0,1) 1:1 Cada B tiene exactamente un A; cada A tiene como mucho un B PERSONA – CARNET_CONDUCIR
(0,1) (0,1) 1:1 Ambos lados opcionales EMPLEADO – PLAZA_APARCAMIENTO
(1,1) (1,1) 1:1 Ambos lados obligatorios EQUIPO – ENTRENADOR (en una liga que lo exige)
(1,1) (0,n) 1:N Cada B tiene un A; un A puede no tener B CLIENTE – PEDIDO
(1,1) (1,n) 1:N Cada B tiene un A; cada A tiene al menos un B PEDIDO – LINEA_PEDIDO
(0,1) (0,n) 1:N Opcional en ambos lados DEPARTAMENTO – EMPLEADO (EMPRESA)
(0,n) (0,n) N:M Opcional en ambos lados PRODUCTO – PROVEEDOR
(1,n) (0,n) N:M Cada B tiene al menos un A AUTOR – LIBRO (todo libro tiene autor)
(1,n) (1,n) N:M Obligatorio en ambos lados ASIGNATURA – PROFESOR (si toda asignatura tiene profesor y todo profesor imparte)

Recuerda cómo leer cada fila: la columna “Junto a A” dice cuántos A tiene cada B. Por ejemplo, en CLIENTE–PEDIDO, (1,1) junto a CLIENTE significa que cada pedido tiene exactamente un cliente.

6.4 ¿Y en las reflexivas y las ternarias?

La convención es la misma, pero conviene precisarla:

  • Reflexivas: cada línea corresponde a un papel. La pareja de la línea con el papel jefe dice cuántos jefes tiene un empleado (en su papel de subordinado): (0,1). La pareja de la línea subordinado dice cuántos subordinados tiene un empleado (en su papel de jefe): (0,n).
  • Ternarias: la pareja junto a la entidad A indica con cuántas ocurrencias de A se relaciona cada combinación de ocurrencias de las otras dos entidades. Por ejemplo, junto a PROVEEDOR: “para una pieza y un proyecto concretos, ¿cuántos proveedores hay?”. El módulo de relaciones ternarias desarrolla este razonamiento.

7. Otras convenciones de cardinalidad

7.1 Mirar al otro lado o mirar aquí

Las distintas notaciones se dividen en dos grandes familias según dónde escriben la información de cada entidad:

📘 Concepto: Mirar al otro lado (look-across): la cardinalidad escrita junto a la entidad B habla de cuántas ocurrencias de B tiene cada ocurrencia de A. Hay que “cruzar” la relación desde A para leerla. La usan la notación del curso, Chen original (para los máximos), la pata de gallo y UML.

📘 Concepto: Mirar aquí (look-here) o participación: la cardinalidad escrita junto a la entidad A habla de en cuántas ocurrencias de la relación participa cada ocurrencia de A. Se lee “sin cruzar”, desde la propia entidad. La usan la notación (mín, máx) de Elmasri y Navathe, el método francés Merise y algunos libros de texto.

En una relación binaria, la información es exactamente la misma: la pareja simplemente cambia de lado. Si en la notación del curso escribimos (0,n) junto a ASIGNATURA (“un profesor imparte de 0 a n asignaturas”), en la de participación escribimos (0,n) junto a PROFESOR (“un profesor participa en 0 a n ocurrencias de imparte”).

7.2 El mismo ejemplo en todas las notaciones

Usaremos la relación DEPARTAMENTO–EMPLEADO de EMPRESA, pero con una regla más interesante para que las dos mínimas sean distintas: todo empleado debe pertenecer a un departamento y un departamento puede no tener empleados.

  • Un empleado trabaja en exactamente un departamento.
  • Un departamento tiene de cero a muchos empleados.

a) Notación del curso (Chen extendida, look-across):

flowchart LR
    DEPARTAMENTO[DEPARTAMENTO] ---|"(1,1)"| trabaja{"trabaja<br/>1:N"}
    trabaja ---|"(0,n)"| EMPLEADO[EMPLEADO]

b) Notación de participación (Elmasri y Navathe, look-here): las parejas cambian de lado. Junto a EMPLEADO, “cada empleado participa en exactamente 1 ocurrencia de trabaja”; junto a DEPARTAMENTO, “cada departamento participa en 0 a n ocurrencias”.

flowchart LR
    DEPARTAMENTO[DEPARTAMENTO] ---|"(0,n)"| trabaja{trabaja}
    trabaja ---|"(1,1)"| EMPLEADO[EMPLEADO]

¡El dibujo es casi idéntico al anterior, pero con las parejas intercambiadas! Por eso, ante un diagrama de otro libro, lo primero es averiguar qué convención usa.

c) Chen original (1976): solo indica los máximos, con look-across (“1” junto a DEPARTAMENTO porque cada empleado tiene un departamento; “N” junto a EMPLEADO). La participación total se dibuja con una línea doble en el lado de la entidad que participa obligatoriamente (aquí, EMPLEADO). Mermaid no tiene líneas dobles; usamos una línea gruesa === para representarla:

flowchart LR
    DEPARTAMENTO[DEPARTAMENTO] ---|"1"| trabaja{trabaja}
    trabaja ===|"N"| EMPLEADO[EMPLEADO]

d) Pata de gallo (crow’s foot, look-across): el símbolo de cada extremo indica mínimo (el más próximo al centro de la línea: círculo = 0, raya = 1) y máximo (el más próximo a la entidad: raya = 1, pata = muchos).

erDiagram
    DEPARTAMENTO ||--o{ EMPLEADO : "trabaja"

Se lee: junto a DEPARTAMENTO, || = “uno y solo uno” (cada empleado tiene exactamente un departamento); junto a EMPLEADO, o{ = “cero o muchos” (cada departamento tiene de 0 a n empleados).

e) UML (multiplicidades, look-across):

classDiagram
    class Departamento
    class Empleado
    Departamento "1" -- "0..*" Empleado : trabaja

Junto a Departamento, 1 (cada empleado está en exactamente un departamento); junto a Empleado, 0..* (cada departamento tiene de 0 a muchos empleados).

f) Barker (Oracle): usa pata de gallo para el máximo (look-across), pero la opcionalidad se dibuja en la mitad de la línea más próxima a la entidad a la que se refiere (look-here): línea continua = “debe”, discontinua = “puede”. Se lee con frases normalizadas: “cada EMPLEADO debe trabajar en uno y solo un DEPARTAMENTO” (mitad continua junto a EMPLEADO, sin pata junto a DEPARTAMENTO) y “cada DEPARTAMENTO puede tener uno o más EMPLEADOS” (mitad discontinua junto a DEPARTAMENTO, pata junto a EMPLEADO).

  ╭──────────────╮                              ╭──────────╮
  │ DEPARTAMENTO │- - - - - - - -──────────────<│ EMPLEADO │
  ╰──────────────╯                              ╰──────────╯
     mitad junto a DEPARTAMENTO: discontinua → "cada departamento PUEDE..."
     mitad junto a EMPLEADO:     continua    → "cada empleado DEBE..."
     extremo de EMPLEADO: pata (<) → "uno o más empleados"
     extremo de DEPARTAMENTO: sin pata → "uno y solo un departamento"

7.3 Símbolos de la pata de gallo

Símbolo en el extremo Mermaid erDiagram Significado (mín, máx)
Círculo + raya \|o / o\| Cero o uno: (0,1)
Raya + raya \|\| Uno y solo uno: (1,1)
Círculo + pata o{ / }o Cero o muchos: (0,n)
Raya + pata \|{ / }\| Uno o muchos: (1,n)

En Mermaid, la línea continua -- indica una relación identificadora y la discontinua .. una no identificadora (se explica en el módulo 10 al hablar de entidades débiles).

7.4 Tabla de equivalencias

Para una relación binaria A – R – B, esta tabla muestra dónde se escribe y cómo el hecho “cada ocurrencia de A se relaciona con entre 0 y muchas ocurrencias de B” y el hecho “cada ocurrencia de B se relaciona con exactamente una ocurrencia de A”:

Notación Familia “Cada A tiene de 0 a n B” “Cada B tiene exactamente 1 A”
Curso (Chen extendida) Look-across (0,n) junto a B (1,1) junto a A
Participación (Elmasri, Merise) Look-here (0,n) junto a A (1,1) junto a B
Chen original Look-across (solo máx.) N junto a B; línea simple junto a A 1 junto a A; línea doble junto a B
Pata de gallo Look-across o{ junto a B \|\| junto a A
UML Look-across 0..* junto a B 1 junto a A
Barker Máx. look-across, mín. look-here Pata junto a B; línea discontinua junto a A Sin pata junto a A; línea continua junto a B

Y la equivalencia de los valores más usados:

Curso / participación Pata de gallo UML Chen original (máx.)
(0,1) \|o 0..1 1
(1,1) \|\| 1 1 + participación total
(0,n) o{ 0..* o * N
(1,n) \|{ 1..* N + participación total
(2,5) No tiene símbolo (comentario) 2..5 No tiene

💡 Consejo: Para convertir rápidamente entre la notación del curso y la de participación en una relación binaria, basta con intercambiar las dos parejas. Para convertir a pata de gallo o UML, las parejas se quedan en el mismo lado y solo cambia el símbolo.

7.5 Cuidado con las ternarias

En las relaciones de grado mayor que 2, las dos familias dejan de ser equivalentes: en look-here, la pareja junto a A dice en cuántas ocurrencias de la relación participa cada A; en look-across, la pareja junto a A dice cuántas A hay para cada combinación de las otras entidades. Son informaciones diferentes y no se pueden traducir simplemente cambiando de lado. Lo verás en el módulo de relaciones ternarias.

8. Cómo deducir las cardinalidades de un enunciado

8.1 Las cuatro preguntas

Para cada relación binaria entre A y B, hazte siempre estas cuatro preguntas, pensando en una ocurrencia concreta (no en el conjunto):

Pregunta Respuesta Se escribe
1. Dado un A, ¿con cuántos B se relaciona como mínimo? 0 o 1 (u otro número) Mínimo junto a B
2. Dado un A, ¿con cuántos B se relaciona como máximo? 1 o n (u otro número) Máximo junto a B
3. Dado un B, ¿con cuántos A se relaciona como mínimo? 0 o 1 Mínimo junto a A
4. Dado un B, ¿con cuántos A se relaciona como máximo? 1 o n Máximo junto a A

💻 Ejemplo: “Un socio de la biblioteca puede tener prestados hasta 3 ejemplares a la vez; un ejemplar, en un momento dado, está prestado a un socio o está en la estantería.”

  1. Un socio, como mínimo, ¿cuántos ejemplares tiene prestados? 0 (“puede”).
  2. Como máximo: 3 (“hasta 3”).
  3. Un ejemplar, como mínimo, ¿a cuántos socios está prestado? 0 (puede estar en la estantería).
  4. Como máximo: 1.

Resultado: (0,3) junto a EJEMPLAR y (0,1) junto a SOCIO. Tipo 1:N (un socio, varios ejemplares).

flowchart LR
    SOCIO[SOCIO] ---|"(0,1)"| tiene_prestado{"tiene_prestado<br/>1:N"}
    tiene_prestado ---|"(0,3)"| EJEMPLAR[EJEMPLAR]

8.2 Palabras clave del enunciado

Expresión en el enunciado Indica Ejemplo
“cada”, “todo”, “siempre”, “debe”, “obligatoriamente”, “al menos uno” Mínimo 1 “Todo pedido debe tener al menos una línea”
“puede”, “algunos”, “opcionalmente”, “si lo tiene”, “en su caso” Mínimo 0 “Un cliente puede tener un comercial asignado”
“un”, “uno”, “un único”, “un solo”, “como mucho uno” Máximo 1 “Cada vehículo pertenece a un único cliente”
“varios”, “muchos”, “uno o más”, sustantivo en plural Máximo n “Un autor escribe varios libros”
“hasta k”, “como máximo k”, “no más de k” Máximo k “Hasta 5 perfiles por cuenta”
“exactamente k”, “k” Mínimo y máximo k “En un partido se enfrentan dos equipos”
“ninguno o varios”, “cero o más” (0,n)  
“uno o varios”, “uno o más” (1,n)  

⚠️ Importante: El artículo “un” es engañoso. “Un profesor imparte asignaturas” no significa que el máximo de PROFESOR sea 1: “un” ahí significa “un profesor cualquiera”. Hay que buscar si el enunciado dice “un único” o si se deduce de otra frase. Ante la duda, haz la pregunta de forma explícita: “¿puede una asignatura tener dos profesores?”.

8.3 Factores que cambian las cardinalidades

El tiempo: ¿situación actual o histórico? Es el factor más importante y el que más errores provoca.

  • “Un empleado trabaja en un departamento” (hoy): EMPLEADO–DEPARTAMENTO es 1:N.
  • “Queremos saber en qué departamentos ha trabajado cada empleado a lo largo de su carrera”: un empleado ha estado en muchos departamentos → N:M (y probablemente con atributos fecha_inicio y fecha_fin).

Antes de fijar un máximo, pregunta siempre: ¿esto es en un momento dado o a lo largo del tiempo? El tratamiento del histórico se estudia en el módulo 13.

El momento del alta. La mínima 1 exige que, desde el primer momento, la ocurrencia esté relacionada. Si un departamento se da de alta antes de contratar a nadie, la mínima de EMPLEADO junto a la relación no puede ser 1 aunque “normalmente” todos los departamentos tengan empleados. Piensa en el estado inicial y en el estado final de cada ocurrencia: ¿qué pasa el día que se crea? ¿y cuando se va el último empleado?

Los casos límite. ¿Puede un pedido no tener empleado que lo gestione? (En EMPRESA, sí: los pedidos 5014 y 5023 no tienen empleado.) ¿Puede haber un producto que nunca se haya vendido? (El producto 14.) Los casos raros son los que deciden las mínimas.

El alcance del sistema. “Todo libro tiene al menos un autor” es cierto en la realidad, pero si la biblioteca no registra los autores de las obras anónimas o colectivas, la mínima en la base de datos será 0.

8.4 Ejemplos analizados

Frase del enunciado Análisis Resultado
“Cada factura corresponde a una única reparación, y una reparación terminada genera una factura” Factura → reparación: (1,1). Reparación → factura: la no terminada no tiene factura → (0,1) (1,1) junto a REPARACION, (0,1) junto a FACTURA. 1:1
“Los médicos atienden a los pacientes; un paciente tiene asignado un médico de cabecera” Paciente → médico de cabecera: (1,1) si es obligatorio, (0,1) si no (preguntar). Médico → pacientes: (0,n) (1,1) o (0,1) junto a MEDICO, (0,n) junto a PACIENTE. 1:N
“Un curso puede tener varios profesores, y un profesor puede dar varios cursos” Ambos máximos n; las mínimas no se dicen: supuesto razonable (0,n) en ambos o preguntar (0,n) / (0,n). N:M
“Cada usuario puede crear hasta cinco listas de reproducción; una lista pertenece a su creador” Usuario → listas: (0,5). Lista → usuario: (1,1) (1,1) junto a USUARIO, (0,5) junto a LISTA. 1:N
“Un pedido consta de una o más líneas” Pedido → líneas: (1,n). Línea → pedido: (1,1) aunque no se diga (una línea sin pedido no tiene sentido) (1,1) junto a PEDIDO, (1,n) junto a LINEA_PEDIDO. 1:N

8.5 Cuando el enunciado no lo dice

Es muy frecuente que el enunciado indique solo los máximos, o solo un sentido. Entonces:

  1. Aplica el sentido común del dominio (una línea de pedido sin pedido no tiene sentido; un cliente sin pedidos sí).
  2. Prefiere la mínima 0 cuando haya duda razonable: es la opción menos restrictiva y la que menos problemas da al insertar datos.
  3. Documenta el supuesto junto al diagrama: “Supuesto: un mecánico puede no haber participado aún en ninguna reparación”.

9. Atributos de relación

9.1 Concepto

📘 Concepto: Un atributo de relación es una propiedad que no pertenece a ninguna de las entidades por separado, sino a la asociación entre ellas: su valor depende de la combinación concreta de ocurrencias.

El ejemplo clásico es la nota: no es una propiedad del alumno (un alumno tiene muchas notas) ni de la asignatura (una asignatura tiene muchas notas), sino de “este alumno en esta asignatura”.

flowchart LR
    ALUMNO[ALUMNO] ---|"(0,n)"| cursa{"cursa<br/>N:M"}
    cursa ---|"(1,n)"| ASIGNATURA[ASIGNATURA]
    cursa --- c_nota(["nota (0,1)"])
    cursa --- c_fecha([fecha_matricula])

Otros ejemplos: las horas que un empleado dedica a un proyecto (columna horas de la tabla asignaciones de EMPRESA), la cantidad de una pieza que un proveedor suministra a un proyecto, la fecha en que un socio tomó prestado un ejemplar.

Para saber si un atributo es de la relación, aplica esta prueba: si para conocer su valor necesitas saber las dos ocurrencias (o las tres, en una ternaria), es de la relación.

9.2 Dónde colocarlo según la cardinalidad

Tipo ¿Dónde puede ir el atributo? Ejemplo
N:M Siempre en la relación: no puede ir en ninguna entidad, porque cada ocurrencia de cualquiera de ellas está asociada a muchas nota de ALUMNO–ASIGNATURA; horas de EMPLEADO–PROYECTO
1:N En la relación o en la entidad del lado N (cada ocurrencia del lado N participa como mucho en una ocurrencia de la relación) fecha_alta_en_departamento de EMPLEADO–DEPARTAMENTO puede ir en EMPLEADO
1:1 En la relación o en cualquiera de las dos entidades fecha_asignacion de EMPLEADO–PLAZA_APARCAMIENTO 
flowchart LR
    DEPARTAMENTO[DEPARTAMENTO] ---|"(0,1)"| trabaja{"trabaja<br/>1:N"}
    trabaja ---|"(0,n)"| EMPLEADO[EMPLEADO]
    trabaja --- t_fi([fecha_incorporacion])

En este diagrama, fecha_incorporacion (al departamento) podría dibujarse también como atributo de EMPLEADO, porque cada empleado está, como mucho, en un departamento. En el diseño conceptual es preferible dejarlo en la relación, porque describe la asociación y no al empleado: si el empleado deja el departamento, ese dato pierde el sentido. Al pasar a tablas, los atributos de una relación 1:N acaban en la tabla del lado N junto a la clave ajena (módulo 17).

⚠️ Importante: Si un atributo que parecía de la relación resulta depender de una sola entidad, no es de la relación. La fecha_nacimiento del alumno no depende de la asignatura: es de ALUMNO. Y si depende de la relación y de algo más (por ejemplo, de la fecha), quizá la relación sea en realidad ternaria o haya una entidad escondida.

9.3 La trampa de las repeticiones

Recuerda la propiedad de la sección 1.3: entre un alumno concreto y una asignatura concreta solo puede haber una ocurrencia de cursa. Por tanto, solo hay sitio para una nota. ¿Qué pasa si el alumno suspende y vuelve a cursar la asignatura al año siguiente? Con este diagrama, la nota nueva sustituye a la antigua: el histórico se pierde.

Si el negocio necesita guardar varias “veces” de la misma pareja (varias convocatorias, varios préstamos del mismo libro al mismo socio, varias visitas del mismo paciente al mismo médico), una relación binaria con atributos no basta. Las soluciones son modelar la “vez” como una entidad (débil o fuerte: módulo 10) o usar una relación ternaria con una entidad que represente el tiempo. Ambas se estudian en el módulo 10, en el módulo de relaciones binarias y en el módulo 13.

10. Dependencia de existencia

10.1 La participación mínima 1 crea dependencias

Cuando la mínima es 1, una ocurrencia no puede existir sin estar relacionada. Esto tiene consecuencias directas en las operaciones:

📘 Concepto: Existe dependencia de existencia de A respecto de B cuando la cardinalidad mínima junto a B es 1: toda ocurrencia de A debe estar relacionada con alguna ocurrencia de B, de modo que A no puede existir sin B.

Ejemplo con EMPRESA: (1,1) junto a CLIENTE en realiza significa que todo pedido depende de un cliente.

Operación Consecuencia
Insertar un pedido Hay que indicar su cliente en el mismo momento; el cliente debe existir antes
Borrar un cliente con pedidos No se puede dejar los pedidos “huérfanos”: o se impide el borrado, o se borran también sus pedidos (en cascada), o se reasignan a otro cliente
Modificar el cliente de un pedido Se puede cambiar a otro cliente existente, pero nunca dejarlo sin cliente

En el diseño físico, estas decisiones se implementan con la clave ajena NOT NULL y su acción referencial. En EMPRESA, la FK de pedidos hacia clientes no tiene acción de borrado (Oracle impide borrar un cliente con pedidos), mientras que la de lineas_pedido hacia pedidos tiene ON DELETE CASCADE (al borrar un pedido se borran sus líneas). La diferencia no es casual, y la explicaremos en el módulo 10: las líneas no tienen sentido sin su pedido; los pedidos sí tienen valor (contable, histórico) aunque se quisiera borrar el cliente.

10.2 Obligatoriedad mutua: el problema del huevo y la gallina

Si las dos mínimas son 1, ninguna de las dos ocurrencias puede existir sin la otra:

flowchart LR
    DEPARTAMENTO[DEPARTAMENTO] ---|"(1,1)"| trabaja{"trabaja<br/>1:N"}
    trabaja ---|"(1,n)"| EMPLEADO[EMPLEADO]

“Todo empleado está en un departamento” y “todo departamento tiene al menos un empleado”. ¿Qué se inserta primero? Si insertamos el departamento, durante un instante no tiene empleados; si insertamos el empleado, durante un instante no tiene departamento. Las soluciones son:

  • Insertar ambos dentro de la misma transacción y comprobar las restricciones al final (restricciones diferidas, módulo 24).
  • Relajar una de las dos mínimas a 0 en la implementación y controlar la regla de otra forma.
  • Revisar si la regla es realmente cierta en todo momento (¿de verdad no puede existir ni un minuto un departamento sin empleados?).

💡 Consejo: Las mínimas 1 en ambos lados son correctas en el diseño conceptual si reflejan la realidad, pero márcalas mentalmente como “puntos delicados” para el diseño lógico y físico. La restricción “al menos un empleado por departamento” (mínima 1 del lado N) no se puede imponer con una clave ajena: requiere comprobaciones adicionales (con restricciones diferidas y procesos, o con triggers, que se estudian en el Curso de Oracle PL/SQL).

10.3 Dependencia de existencia no es lo mismo que entidad débil

Que los pedidos dependan de los clientes no convierte a PEDIDO en una entidad débil: un pedido tiene identidad propia (su número), tiene sentido por sí mismo como documento y, de hecho, no se borra al borrar el cliente. Una entidad débil es un caso más fuerte de dependencia, que se estudia en el módulo 10 junto con la diferencia entre dependencia en existencia y dependencia en identificación.

11. Errores frecuentes

Error Ejemplo Solución
Escribir la pareja en el lado equivocado (mezclar convenciones) Poner (0,n) junto a PROFESOR para decir “un profesor imparte 0..n asignaturas” En el curso, la pareja va junto a la entidad contada: (0,n) junto a ASIGNATURA
Deducir el tipo mirando un solo sentido “Un cliente tiene muchos pedidos, luego 1:N” sin comprobar el otro sentido Hacer siempre las cuatro preguntas
Confundir “un” con “un único” “Un profesor imparte asignaturas” → máximo 1 “Un” suele ser “uno cualquiera”
Deducir las mínimas de los datos de ejemplo “Todos los departamentos tienen empleados” porque en los datos es así Las mínimas las fijan las reglas, no los datos
Mínima 1 imposible en el alta Departamento (1,n) empleados, cuando los departamentos se crean vacíos Pensar en el estado inicial
Olvidar los papeles en una reflexiva Dos líneas sin etiqueta entre EMPLEADO y dirige Añadir jefe y subordinado
Atributo de relación en una entidad (N:M) nota en ALUMNO Atributo de la relación
Usar una binaria cuando hay repeticiones Préstamos del mismo libro al mismo socio en fechas distintas Entidad PRESTAMO (módulo 10)
Relación sin nombre o con nombre vacío Rombo relacion Un verbo que se lea en frase
Confundir situación actual con histórico “Trabaja en un departamento” cuando se pide la trayectoria Preguntar por el tiempo

12. Ejercicios

Ejercicio 1: De ocurrencias a cardinalidades

En una academia de música, este diagrama de ocurrencias representa un estado típico y válido de la relación entre PROFESOR e INSTRUMENTO (“un profesor enseña instrumentos”). Además se sabe que todo profesor debe enseñar al menos un instrumento, y que pueden registrarse instrumentos que todavía no enseña nadie.

flowchart LR
    subgraph SPR["PROFESOR"]
        pr1["Lucía"]
        pr2["Andrés"]
        pr3["Sofía"]
    end
    subgraph SIN["INSTRUMENTO"]
        in1["Piano"]
        in2["Guitarra"]
        in3["Violín"]
        in4["Arpa"]
    end
    pr1 --- in1
    pr1 --- in2
    pr2 --- in2
    pr3 --- in3
    pr3 --- in1

a) Deduce las cuatro cardinalidades y el tipo de correspondencia. b) Dibuja la relación con la notación del curso. c) Dibújala con la notación de participación y con pata de gallo.

Ver solución

a) Las cuatro preguntas:

Pregunta Razonamiento Valor
Un profesor, ¿cuántos instrumentos como mínimo? La regla dice “al menos uno” 1
Un profesor, ¿cuántos como máximo? Lucía y Sofía enseñan dos: “varios” n
Un instrumento, ¿cuántos profesores como mínimo? El arpa no tiene ninguno, y la regla lo permite 0
Un instrumento, ¿cuántos como máximo? Piano y guitarra tienen dos n

Tipo: máximo n en los dos lados → N:M.

Fíjate en que el diagrama de ocurrencias no permitía saber la mínima de INSTRUMENTO por cada profesor: todos los profesores del ejemplo tienen instrumento, pero eso podría ser casualidad. La ha fijado la regla. En cambio, el arpa sin profesor sí demuestra que la mínima de PROFESOR por instrumento es 0 (el estado es válido).

b) Notación del curso: “un profesor enseña de 1 a n instrumentos” → (1,n) junto a INSTRUMENTO; “un instrumento lo enseñan de 0 a n profesores” → (0,n) junto a PROFESOR.

flowchart LR
    PROFESOR[PROFESOR] ---|"(0,n)"| ensena{"ensena<br/>N:M"}
    ensena ---|"(1,n)"| INSTRUMENTO[INSTRUMENTO]

c) Participación (se intercambian las parejas) y pata de gallo (mismo lado que el curso):

flowchart LR
    PROFESOR[PROFESOR] ---|"(1,n)"| ensena{ensena}
    ensena ---|"(0,n)"| INSTRUMENTO[INSTRUMENTO]

erDiagram
    PROFESOR }o--|{ INSTRUMENTO : "ensena"

En la pata de gallo, junto a PROFESOR aparece }o (cero o muchos profesores por instrumento) y junto a INSTRUMENTO |{ (uno o muchos instrumentos por profesor).

Ejercicio 2: Cardinalidades de una biblioteca

Deduce las cardinalidades de cada relación, razonando las cuatro preguntas, y dibuja el diagrama completo con la notación del curso:

“La biblioteca tiene libros, de los que puede haber varios ejemplares (al menos uno por libro registrado); cada ejemplar es de un único libro. Cada libro pertenece a una única editorial; de algunas editoriales todavía no hay libros. Un libro tiene uno o varios autores, aunque hay obras anónimas que no tienen ninguno registrado, y un autor solo se registra si tiene algún libro en la biblioteca. Un socio puede tener como máximo 4 ejemplares prestados a la vez; un ejemplar está prestado a un socio o no lo está.”

Ver solución
Relación Pregunta Respuesta Pareja / lado
LIBRO–EJEMPLAR (tiene) Un libro, ¿cuántos ejemplares? “al menos uno”, “varios” (1,n) junto a EJEMPLAR
  Un ejemplar, ¿cuántos libros? “un único” (1,1) junto a LIBRO
EDITORIAL–LIBRO (publica) Una editorial, ¿cuántos libros? “de algunas todavía no hay” → 0; varias (0,n) junto a LIBRO
  Un libro, ¿cuántas editoriales? “una única” (1,1) junto a EDITORIAL
AUTOR–LIBRO (escribe) Un autor, ¿cuántos libros? “solo se registra si tiene algún libro” → 1; varios (1,n) junto a LIBRO
  Un libro, ¿cuántos autores? “uno o varios”, pero las anónimas tienen 0 (0,n) junto a AUTOR
SOCIO–EJEMPLAR (tiene_prestado) Un socio, ¿cuántos ejemplares? “como máximo 4” (0,4) junto a EJEMPLAR
  Un ejemplar, ¿cuántos socios? “a un socio o no lo está” (0,1) junto a SOCIO 
flowchart LR
    LIBRO[LIBRO] ---|"(1,1)"| tiene{"tiene<br/>1:N"}
    tiene ---|"(1,n)"| EJEMPLAR[EJEMPLAR]
    EDITORIAL[EDITORIAL] ---|"(1,1)"| publica{"publica<br/>1:N"}
    publica ---|"(0,n)"| LIBRO
    AUTOR[AUTOR] ---|"(0,n)"| escribe{"escribe<br/>N:M"}
    escribe ---|"(1,n)"| LIBRO
    SOCIO[SOCIO] ---|"(0,1)"| tiene_prestado{"tiene_prestado<br/>1:N"}
    tiene_prestado ---|"(0,4)"| EJEMPLAR

Observaciones:

  • “Un libro tiene uno o varios autores, aunque hay obras anónimas”: la segunda parte de la frase corrige la mínima. Lee siempre la frase completa.
  • tiene_prestado representa solo la situación actual (los préstamos activos). Si la biblioteca necesita el historial de préstamos, este diseño no sirve: un socio puede tomar prestado el mismo ejemplar varias veces (sección 9.3). Se resolverá en el módulo 10 con una entidad PRESTAMO.
  • El límite “4” se dibuja, pero en el modelo relacional no se podrá imponer con una clave ajena: hay que documentarlo.
  • Es probable que EJEMPLAR sea una entidad débil de LIBRO (ejemplar 1, 2, 3 de cada libro): lo verás en el módulo 10.

Ejercicio 3: Leer un diagrama

Escribe, en lenguaje natural y en los dos sentidos, todo lo que dice este diagrama de un hospital. Indica el tipo de correspondencia de cada relación.

flowchart LR
    MEDICO[MEDICO] ---|"(1,1)"| pertenece{pertenece}
    pertenece ---|"(1,n)"| SERVICIO[SERVICIO]
    SERVICIO ---|"(0,1) jefe"| dirige{dirige}
    dirige ---|"(1,1)"| MEDICO
    PACIENTE[PACIENTE] ---|"(0,n)"| ingresa{ingresa}
    ingresa ---|"(0,1)"| CAMA[CAMA]
    CAMA ---|"(1,1)"| ubicada{ubicada}
    ubicada ---|"(1,n)"| SERVICIO
Ver solución

¡Cuidado! Este ejercicio tiene trampa: hay que leer cada pareja junto a la entidad que cuenta, no junto a la entidad de partida. Vamos relación por relación.

pertenece (MEDICO – SERVICIO):

  • Junto a SERVICIO, (1,n): “un médico pertenece a entre 1 y n servicios”.
  • Junto a MEDICO, (1,1): “un servicio tiene exactamente un médico”.
  • Tipo: el máximo junto a MEDICO es 1 y junto a SERVICIO es n → 1:N (un médico, muchos servicios).

Esto es muy probablemente un error del diagrama: lo razonable es que un servicio tenga muchos médicos y cada médico pertenezca a un único servicio. El diseñador escribió las parejas con la convención de participación. Corregido: (1,n) junto a MEDICO y (1,1) junto a SERVICIO.

dirige (SERVICIO – MEDICO, con papel jefe en la línea de SERVICIO): aquí el papel está mal colocado. Leído literalmente: junto a MEDICO (1,1): “un servicio es dirigido por exactamente un médico”; junto a SERVICIO (0,1): “un médico dirige 0 o 1 servicios”. Eso sí es razonable (1:1). Pero el papel jefe corresponde al médico, por lo que debería escribirse en la línea de MEDICO: "(1,1) jefe".

ingresa (PACIENTE – CAMA):

  • Junto a CAMA, (0,1): “un paciente está ingresado en 0 o 1 camas” (en un momento dado).
  • Junto a PACIENTE, (0,n): “en una cama hay de 0 a n pacientes”.

Otro error probable: en una cama, en un momento dado, hay como mucho un paciente → debería ser (0,1) junto a PACIENTE. Si se quiere el histórico de ingresos, ninguna de las dos lecturas sirve y hace falta una entidad INGRESO.

ubicada (CAMA – SERVICIO):

  • Junto a SERVICIO, (1,n): “una cama está ubicada en entre 1 y n servicios”; junto a CAMA, (1,1): “un servicio tiene exactamente una cama”. De nuevo invertido: lo razonable es (1,1) junto a SERVICIO (cada cama está en un servicio) y (1,n) junto a CAMA (cada servicio tiene muchas camas).

Diagrama corregido:

flowchart LR
    MEDICO[MEDICO] ---|"(1,n)"| pertenece{"pertenece<br/>1:N"}
    pertenece ---|"(1,1)"| SERVICIO[SERVICIO]
    SERVICIO ---|"(0,1)"| dirige{"dirige<br/>1:1"}
    dirige ---|"(1,1) jefe"| MEDICO
    PACIENTE[PACIENTE] ---|"(0,1)"| ingresa{"ingresa<br/>1:1"}
    ingresa ---|"(0,1)"| CAMA[CAMA]
    CAMA ---|"(1,n)"| ubicada{"ubicada<br/>1:N"}
    ubicada ---|"(1,1)"| SERVICIO

Moraleja: mezclar convenciones produce diagramas que “parecen” correctos pero dicen lo contrario de lo que se quería. Lee siempre en voz alta cada pareja con la frase “un ‹partida› ‹verbo› ‹pareja› ‹llegada›”.

Ejercicio 4: Traducir entre notaciones

Este diagrama está tomado de un libro que usa la notación de participación (look-here) de Elmasri y Navathe. Tradúcelo a la notación del curso, a pata de gallo y a UML, y explica qué significa.

flowchart LR
    USUARIO[USUARIO] ---|"(1,5)"| crea{crea}
    crea ---|"(1,1)"| PERFIL[PERFIL]
    PERFIL ---|"(0,n)"| valora{valora}
    valora ---|"(0,n)"| SERIE[SERIE]
Ver solución

En participación, la pareja junto a una entidad dice en cuántas ocurrencias de la relación participa esa entidad:

  • USUARIO (1,5) en crea: cada usuario crea entre 1 y 5 perfiles.
  • PERFIL (1,1) en crea: cada perfil lo crea exactamente un usuario.
  • PERFIL (0,n) en valora: cada perfil valora de 0 a n series.
  • SERIE (0,n) en valora: cada serie es valorada por 0 a n perfiles.

Notación del curso: en binarias basta con intercambiar las parejas.

flowchart LR
    USUARIO[USUARIO] ---|"(1,1)"| crea{"crea<br/>1:N"}
    crea ---|"(1,5)"| PERFIL[PERFIL]
    PERFIL ---|"(0,n)"| valora{"valora<br/>N:M"}
    valora ---|"(0,n)"| SERIE[SERIE]

(En valora ambas parejas son iguales, así que el intercambio no cambia nada.)

Pata de gallo: mismo lado que la notación del curso. El límite 5 no tiene símbolo y se indica en la etiqueta.

erDiagram
    USUARIO ||--|{ PERFIL : "crea (max 5)"
    PERFIL }o--o{ SERIE : "valora"

UML:

classDiagram
    class Usuario
    class Perfil
    class Serie
    Usuario "1" -- "1..5" Perfil : crea
    Perfil "0..*" -- "0..*" Serie : valora

UML es la única de las tres (además de la del curso) que expresa directamente el límite 1..5.

Ejercicio 5: Dónde va cada atributo

En una plataforma de cursos en línea se definen estas relaciones. Para cada atributo, indica si debe ir en una entidad o en la relación, y por qué.

  1. ALUMNO (0,n) — se_inscribe — (0,n) CURSO. Atributos: fecha de inscripción, porcentaje completado, fecha de nacimiento del alumno, precio pagado.
  2. PROFESOR (1,1) — crea — (0,n) CURSO (la pareja (1,1) junto a PROFESOR: cada curso lo crea un profesor). Atributos: fecha de creación del curso, especialidad del profesor.
  3. CURSO (0,1) — tiene_certificado — (0,1) PLANTILLA_CERTIFICADO. Atributo: fecha desde la que se usa esa plantilla en ese curso.
Ver solución
  1. se_inscribe es N:M:
    • fecha_inscripcion: depende del alumno y del curso → relación.
    • porcentaje_completado: depende del alumno y del curso → relación.
    • fecha_nacimiento: depende solo del alumno → ALUMNO.
    • precio_pagado: depende de la inscripción concreta (puede haber descuentos o cambios de precio) → relación. No confundir con el precio actual del curso, que es atributo de CURSO.
  2. crea es 1:N (un profesor crea muchos cursos; cada curso lo crea un profesor):
    • fecha_creacion: cada curso tiene una sola creación, así que puede ir en la relación o en CURSO (el lado N). Como la fecha describe al curso en sí (y el curso no cambia de creador), lo natural es ponerla en CURSO.
    • especialidad: depende solo del profesor → PROFESOR.
  3. tiene_certificado es 1:1: fecha_desde puede ir en la relación, en CURSO o en PLANTILLA_CERTIFICADO. Como describe la asociación (si se cambia de plantilla, la fecha cambia), es preferible dejarla en la relación.
flowchart LR
    ALUMNO[ALUMNO] ---|"(0,n)"| se_inscribe{"se_inscribe<br/>N:M"}
    se_inscribe ---|"(0,n)"| CURSO[CURSO]
    se_inscribe --- i_fecha([fecha_inscripcion])
    se_inscribe --- i_pct([porcentaje_completado])
    se_inscribe --- i_precio([precio_pagado])
    PROFESOR[PROFESOR] ---|"(1,1)"| crea{"crea<br/>1:N"}
    crea ---|"(0,n)"| CURSO
    CURSO --- c_fc([fecha_creacion])
    PROFESOR --- p_esp([especialidad])
    ALUMNO --- a_fn([fecha_nacimiento])

¿Y si un alumno puede inscribirse dos veces en el mismo curso (por ejemplo, porque caducó su acceso)? Entonces la relación N:M no basta (solo hay una ocurrencia por pareja) y habría que crear una entidad INSCRIPCION: es la trampa de la sección 9.3.

Ejercicio 6: Dependencias de existencia y orden de inserción

Dado este diagrama de una agencia de viajes:

flowchart LR
    CLIENTE[CLIENTE] ---|"(1,1)"| hace{"hace<br/>1:N"}
    hace ---|"(0,n)"| RESERVA[RESERVA]
    RESERVA ---|"(1,n)"| incluye{"incluye<br/>N:M"}
    incluye ---|"(0,n)"| VIAJE[VIAJE]
    GUIA[GUIA] ---|"(1,1)"| acompana{"acompana<br/>1:N"}
    acompana ---|"(1,n)"| VIAJE

a) Lee todas las relaciones en los dos sentidos. b) Indica qué dependencias de existencia hay. c) ¿En qué orden habría que dar de alta los datos de un viaje nuevo con su primera reserva? ¿Hay algún problema? d) ¿Qué ocurre si se quiere borrar un guía?

Ver solución

a) Lectura:

  • Un cliente hace de 0 a n reservas; una reserva la hace exactamente 1 cliente.
  • Una reserva incluye de 0 a n viajes… ¡cuidado! La pareja junto a VIAJE es (0,n): “una reserva incluye de 0 a n viajes”. La pareja junto a RESERVA es (1,n): “un viaje está incluido en 1 a n reservas”.
  • Un guía acompaña de 1 a n viajes; un viaje lo acompaña exactamente 1 guía.

b) Dependencias de existencia (mínima 1 en el lado contrario):

  • RESERVA depende de CLIENTE ((1,1) junto a CLIENTE).
  • VIAJE depende de RESERVA ((1,n) junto a RESERVA): un viaje no puede existir sin al menos una reserva. Esto es sospechoso: normalmente un viaje se programa antes de que nadie lo reserve. Probablemente el diseñador quería decir que “una reserva incluye al menos un viaje”, es decir, (1,n) junto a VIAJE y (0,n) junto a RESERVA. Hay que preguntar.
  • VIAJE depende de GUIA ((1,1) junto a GUIA).
  • GUIA depende de VIAJE ((1,n) junto a VIAJE): un guía no puede existir sin acompañar algún viaje. También sospechoso: un guía recién contratado aún no tiene viajes.

c) Tal como está el diagrama, para dar de alta un viaje hace falta: un guía que lo acompañe (pero el guía, a su vez, necesita tener un viaje: obligatoriedad mutua entre GUIA y VIAJE) y al menos una reserva (que a su vez necesita un cliente). El orden sería: CLIENTE → (GUIA y VIAJE a la vez, en la misma transacción) → RESERVA y la ocurrencia de incluye, todo antes de comprobar las restricciones. Es un diseño muy incómodo; corrigiendo las dos mínimas sospechosas a 0 (viaje sin reservas, guía sin viajes), el orden sería simplemente GUIA → VIAJE → CLIENTE → RESERVA → incluye.

d) Si se borra un guía que acompaña viajes, esos viajes se quedarían sin guía, lo que viola (1,1). Opciones: impedir el borrado mientras tenga viajes, reasignar sus viajes a otro guía antes de borrarlo, o (muy improbable que sea deseable) borrar sus viajes en cascada.

Ejercicio 7: Modelo completo con cardinalidades

Dibuja el diagrama E/R (solo entidades, relaciones y cardinalidades; con los atributos de relación que aparezcan) y justifica cada pareja:

“En un taller de formación profesional, cada alumno pertenece a un único grupo, y un grupo tiene entre 10 y 30 alumnos. Cada grupo tiene un tutor, que es un profesor; un profesor es tutor como mucho de un grupo. Los profesores imparten módulos a los grupos: un mismo módulo puede impartirse a varios grupos, a un grupo se le imparten varios módulos, y un profesor puede impartir varios módulos. Se quiere saber, de cada alumno y cada módulo, la nota final.”

Ver solución
Relación Cardinalidades y justificación
GRUPO–ALUMNO (pertenece) Un alumno, a “un único grupo” → (1,1) junto a GRUPO. Un grupo, “entre 10 y 30” → (10,30) junto a ALUMNO. 1:N
PROFESOR–GRUPO (tutoriza) Un grupo “tiene un tutor” → (1,1) junto a PROFESOR (papel tutor). Un profesor, “como mucho de un grupo” → (0,1) junto a GRUPO. 1:1
PROFESOR–MODULO–GRUPO (imparte) Asocia tres entidades a la vez (“los profesores imparten módulos a los grupos”): es una relación ternaria. Sus cardinalidades se razonan en el módulo de relaciones ternarias; aquí la dejamos indicada
ALUMNO–MODULO (evalua) Un alumno tiene nota en varios módulos y un módulo tiene muchos alumnos → (0,n) y (0,n), N:M, con el atributo nota_final 
flowchart LR
    GRUPO[GRUPO] ---|"(1,1)"| pertenece{"pertenece<br/>1:N"}
    pertenece ---|"(10,30)"| ALUMNO[ALUMNO]
    PROFESOR[PROFESOR] ---|"(1,1) tutor"| tutoriza{"tutoriza<br/>1:1"}
    tutoriza ---|"(0,1)"| GRUPO
    PROFESOR --- imparte{imparte}
    imparte --- MODULO[MODULO]
    imparte --- GRUPO
    ALUMNO ---|"(0,n)"| evalua{"evalua<br/>N:M"}
    evalua ---|"(0,n)"| MODULO
    evalua --- ev_nota(["nota_final (0,1)"])

Decisiones comentadas:

  • La mínima 10 de pertenece implica que un grupo no puede existir con menos de 10 alumnos. ¿Es cierto el día que se crea el grupo, antes de la matrícula? Probablemente es una regla de apertura del grupo, no de existencia. En la práctica se documentaría como restricción y se usaría (0,30) o (1,30) en la implementación.
  • nota_final es atributo de la relación N:M, y opcional porque se registra al final del curso.
  • No se ha relacionado ALUMNO con MODULO a través de GRUPO porque la nota es de cada alumno en cada módulo, independientemente de quién lo imparta.

Ejercicio 8: Cuatro preguntas en ambos sentidos

Para cada frase, escribe las cuatro preguntas y sus respuestas, la pareja de cada lado (notación del curso) y el tipo. Si el enunciado no lo aclara, indica el supuesto.

a) “Cada país tiene una capital, que es una ciudad.” b) “Un jugador de tenis disputa partidos individuales; en cada partido se enfrentan dos jugadores.” c) “Una persona puede ser titular de varias cuentas bancarias, y una cuenta puede tener hasta cuatro titulares.”

Ver solución

a) PAIS – CIUDAD (tiene_capital):

  • Un país, ¿cuántas capitales? Exactamente 1 → (1,1) junto a CIUDAD.
  • Una ciudad, ¿de cuántos países es capital? 0 (la mayoría de ciudades no son capitales) o 1 → (0,1) junto a PAIS.
  • Tipo 1:1. (Supuesto: no se consideran países con varias capitales oficiales, como Bolivia o Sudáfrica. Si existieran, sería (1,n) junto a CIUDAD.)

b) JUGADOR – PARTIDO (disputa):

  • Un jugador, ¿cuántos partidos? De 0 (recién inscrito) a n → (0,n) junto a PARTIDO.
  • Un partido, ¿cuántos jugadores? Exactamente 2 → (2,2) junto a JUGADOR.
  • Tipo N:M. Observa que con una única relación no se distingue quién es el jugador 1 y quién el 2 (por ejemplo, quién sacó primero o quién ganó). Si eso interesa, es mejor usar dos relaciones con papeles distintos (jugador1 y jugador2, o ganador y perdedor), cada una con (1,1) junto a JUGADOR: se estudia en el módulo de relaciones binarias.

c) PERSONA – CUENTA (es_titular):

  • Una persona, ¿cuántas cuentas? “puede ser titular de varias” → (0,n) junto a CUENTA (supuesto: el banco registra personas sin cuenta, por ejemplo, avalistas; si no, (1,n)).
  • Una cuenta, ¿cuántos titulares? “hasta cuatro”; toda cuenta tiene al menos uno → (1,4) junto a PERSONA.
  • Tipo N:M.
flowchart LR
    PERSONA[PERSONA] ---|"(1,4)"| es_titular{"es_titular<br/>N:M"}
    es_titular ---|"(0,n)"| CUENTA[CUENTA]

Ejercicios propuestos

✏️ Ejercicio: Propuesto 1 — Diagrama de ocurrencias. Dibuja un diagrama de ocurrencias de la relación PROYECTO–EMPLEADO del esquema EMPRESA usando los datos de la tabla asignaciones del script empresa_datos.sql. A partir de él y de las restricciones de empresa_crear.sql, deduce las cardinalidades. ¿Qué te dice el proyecto 5 sobre la mínima?

✏️ Ejercicio: Propuesto 2 — Red social. Deduce las cardinalidades (cuatro preguntas por relación) y dibuja el diagrama: “Un usuario publica mensajes; cada mensaje lo publica un único usuario. Un usuario puede dar ‘me gusta’ a muchos mensajes, y un mensaje puede tener muchos ‘me gusta’; se guarda la fecha de cada ‘me gusta’. Un mensaje puede ser respuesta de otro mensaje. Los usuarios pueden pertenecer a grupos, y cada grupo tiene un único administrador, que debe ser miembro del grupo.” Señala qué restricción no puede expresar el diagrama.

✏️ Ejercicio: Propuesto 3 — Cinco notaciones. Dibuja la relación CATEGORIA–PRODUCTO de EMPRESA (cada producto pertenece a una categoría obligatoriamente; una categoría puede no tener productos) en la notación del curso, en participación, en Chen original, en pata de gallo y en UML.

✏️ Ejercicio: Propuesto 4 — Histórico. “Un vehículo de alquiler está asignado a una oficina.” Dibuja la relación suponiendo que solo interesa la situación actual. Después, rediseñala suponiendo que interesa saber en qué oficinas ha estado cada vehículo y en qué fechas. ¿Qué cambia en las cardinalidades? ¿Basta con añadir atributos de fecha a la relación? Razónalo con la sección 9.3.

✏️ Ejercicio: Propuesto 5 — Detectar errores. Un compañero ha dibujado ESCUDERIA (0,n) — corre_para — (2,2) PILOTO queriendo decir que “cada escudería tiene exactamente dos pilotos y cada piloto corre para una escudería (o ninguna, si es reserva)”. Explica qué dice realmente su diagrama según la convención del curso y corrígelo.

Resumen

Concepto Idea clave
Relación (interrelación) Asociación entre entidades; rombo con un verbo en minúsculas
Tipo / ocurrencia El tipo se dibuja; cada ocurrencia es una tupla de ocurrencias de entidades; no hay tuplas repetidas
Grado Reflexiva (1), binaria (2), ternaria (3), n-aria; cada una tiene su módulo dedicado
Papel (rol) Función de la entidad en la relación; imprescindible en reflexivas y relaciones múltiples
Cardinalidad máxima Máximo de ocurrencias de B por cada A: 1 o n (o un número)
Tipo de correspondencia 1:1, 1:N, N:M; se obtiene de los dos máximos
Cardinalidad mínima 0 = participación opcional (parcial); 1 = obligatoria (total)
Convención del curso La pareja (mín, máx) junto a B dice con cuántas B se relaciona una A (look-across)
Participación (look-here) Elmasri, Merise: la pareja va en el lado contrario; en binarias basta con intercambiar
Pata de gallo / UML Look-across: mismo lado que el curso; símbolos \|o, \|\|, o{, \|{ / 0..1, 1, 0..*, 1..*
Deducir cardinalidades Cuatro preguntas pensando en una ocurrencia; palabras clave; tiempo, alta y casos límite
Atributo de relación Depende de la combinación; en N:M siempre en la relación; en 1:N puede ir al lado N; en 1:1, a cualquier lado
Dependencia de existencia Mínima 1 en el otro lado: condiciona inserciones y borrados; mínimas 1 mutuas = huevo y gallina
Navegación  
← Módulo anterior: Entidades y atributos Siguiente módulo: Relaciones binarias →