Módulo 12: Agregación

Objetivos del módulo

Comprender la limitación del modelo E/R básico: una relación solo puede asociar entidades, nunca otras relaciones
Definir la agregación como abstracción que trata una relación y sus entidades participantes como una entidad de nivel superior
Conocer el origen del concepto (Smith y Smith, 1977) y cómo aparece en las distintas notaciones: Chen extendida, EER de Elmasri y Navathe, Silberschatz y UML
Distinguir la agregación del E/R de la agregación y composición de UML, que expresan otra cosa
Representar agregaciones en la notación del curso y calcular y leer sus cardinalidades respecto a cada ocurrencia de la relación agregada
Modelar casos completos y variados: participaciones en proyectos, matrículas y calificaciones, consultas médicas y recetas, vuelos y tripulaciones
Saber cuándo tiene sentido agregar relaciones N:M, 1:N, 1:1 y ternarias, y cuándo anidar agregaciones
Elegir con criterio entre agregación, ternaria, entidad débil y entidad asociativa, demostrando la elección con ocurrencias
No confundir agregación con generalización
Anticipar cómo se transforma una agregación al modelo relacional y qué restricciones semánticas lleva asociadas

1. El problema: relacionar una relación con una entidad

1.1. La limitación del modelo E/R básico

En el modelo Entidad/Relación original de Peter Chen (1976), y en todo lo que has visto hasta el módulo 11, una relación es un conjunto de asociaciones entre ocurrencias de entidades. Formalmente, R ⊆ E₁ × E₂ × … × Eₙ, donde cada Eᵢ es un tipo de entidad. Por definición, una relación no puede participar en otra relación: en el diagrama, un rombo solo puede unirse a rectángulos, nunca a otro rombo.

Casi siempre esta regla es razonable, pero hay requisitos en los que lo que queremos asociar con una entidad no es otra entidad, sino un hecho: una participación, una matrícula, una consulta, un vuelo operado.

1.2. El caso que lo motiva

“Los empleados trabajan en proyectos; de cada participación interesa la fecha de incorporación y la función que desempeña el empleado. Todo proyecto tiene al menos un empleado. Además, cada empleado, en cada proyecto en el que trabaja, puede utilizar maquinaria de la empresa (ninguna, una o varias máquinas). Interesa saber cuántas horas ha usado cada máquina en cada participación.”

Lo que queremos representar se dibujaría así si el modelo lo permitiera:

flowchart LR
    EMPLEADO[EMPLEADO] ---|"(1,n)"| trabaja{"trabaja<br/>N:M"}
    trabaja ---|"(0,n)"| PROYECTO[PROYECTO]
    trabaja -.-|"INCORRECTO: rombo unido a rombo"| usa{usa}
    usa ---|"(0,n)"| MAQUINARIA[MAQUINARIA]

⚠️ Importante: Este diagrama no es válido en el modelo E/R: la arista discontinua une dos relaciones. Lo dibujamos solo para mostrar la intención: queremos que usa asocie una máquina con una ocurrencia de trabaja (con un par empleado-proyecto concreto), no con el empleado ni con el proyecto por separado.

1.3. Tres intentos fallidos

Antes de ver la solución, comprobemos con ocurrencias por qué las alternativas “legales” del modelo básico no sirven. La realidad que queremos guardar es esta:

Participación	Máquinas usadas (horas)
Eva en P1 (desde 01/03/2026, jefa de obra)	Grúa G2 (120 h), Retroexcavadora R1 (45 h)
Eva en P2 (desde 15/05/2026, asesora)	ninguna
Luis en P1 (desde 10/03/2026, operario)	Grúa G2 (30 h)
Marta en P3 (desde 02/02/2026, operaria)	Retroexcavadora R1 (60 h)

Intento 1: relacionar la máquina con el empleado.

usa (empleado, máquina)	horas
(Eva, Grúa G2)	120
(Eva, Retro R1)	45
(Luis, Grúa G2)	30
(Marta, Retro R1)	60

Eva trabaja en P1 y en P2. ¿En cuál de los dos usó la grúa? No se sabe. Y si Eva usara la grúa en P1 y en P2, no podríamos guardar las horas por separado, porque el par (Eva, Grúa G2) solo puede aparecer una vez.

Intento 2: relacionar la máquina con el proyecto.

usa (proyecto, máquina)	horas
(P1, Grúa G2)	150
(P1, Retro R1)	45
(P3, Retro R1)	60

¿Quién usó la grúa en P1, Eva o Luis? ¿Cuántas horas cada uno? Se ha perdido.

Intento 3: una ternaria EMPLEADO-PROYECTO-MAQUINARIA. Es el intento más razonable, y lo analizaste en el módulo 09:

Empleado	Proyecto	Máquina	fecha_incorporacion	funcion	horas
Eva	P1	Grúa G2	01/03/2026	jefa de obra	120
Eva	P1	Retro R1	01/03/2026	jefa de obra	45
Luis	P1	Grúa G2	10/03/2026	operario	30
Marta	P3	Retro R1	02/02/2026	operaria	60
Eva	P2	???	15/05/2026	asesora	???

La participación de Eva en P2 no se puede registrar: una ternaria no admite que falte la máquina.
La fecha de incorporación y la función se repiten en cada máquina de la misma participación: dependen solo del par (empleado, proyecto).
Si añadimos una binaria trabaja para registrar las participaciones sin máquina, nada impide que la ternaria contenga (Luis, P3, Grúa G2) aunque Luis no trabaje en P3.

1.4. La solución: la agregación

La idea es sencilla: si el modelo solo permite relacionar entidades, convirtamos la relación en algo que se comporte como una entidad. Encerramos trabaja, junto con EMPLEADO y PROYECTO, en una “caja” a la que damos nombre (PARTICIPACIÓN), y relacionamos esa caja con MAQUINARIA:

flowchart LR
    subgraph PARTICIPACION["PARTICIPACIÓN (agregación)"]
        direction LR
        EMPLEADO[EMPLEADO] ---|"(1,n)"| trabaja{"trabaja<br/>N:M"}
        trabaja ---|"(0,n)"| PROYECTO[PROYECTO]
        trabaja --- t_fecha([fecha_incorporacion])
        trabaja --- t_func([funcion])
    end
    PARTICIPACION ---|"(0,n)"| usa{"usa<br/>N:M"}
    usa ---|"(0,n)"| MAQUINARIA[MAQUINARIA]
    usa --- u_horas([horas])

Con este modelo se pueden guardar las cuatro participaciones (incluida la de Eva en P2, que simplemente no aparece en usa), la fecha y la función se guardan una vez por participación, y es imposible registrar el uso de una máquina en una participación que no existe.

2. Concepto de agregación

2.1. Definición

📘 Concepto: La agregación (aggregation) es una abstracción mediante la cual una relación, junto con las entidades que participan en ella (y sus atributos), se trata como una entidad de nivel superior (también llamada entidad agregada o entidad compuesta). Esa entidad de nivel superior puede participar en otras relaciones como si fuera una entidad más. Sus ocurrencias son las ocurrencias de la relación agregada.

Formalmente, si R ⊆ E₁ × E₂ es la relación agregada, la agregación A tiene como conjunto de ocurrencias exactamente el conjunto de ocurrencias de R. Una relación externa S entre A y otra entidad C es entonces S ⊆ A × C, es decir, un conjunto de pares de la forma ((e₁, e₂), c).

En el ejemplo, las ocurrencias de PARTICIPACIÓN son (Eva, P1), (Eva, P2), (Luis, P1) y (Marta, P3), y las de usa son ((Eva, P1), Grúa G2), ((Eva, P1), Retro R1), ((Luis, P1), Grúa G2) y ((Marta, P3), Retro R1).

2.2. Una analogía

Piensa en un contrato de alquiler. El contrato existe porque un inquilino y un propietario se han puesto de acuerdo sobre un piso: es una relación. Pero una vez firmado, el contrato “cobra vida propia”: se le asocia un aval bancario, se le aplican subidas anuales, se le adjuntan recibos. Nadie diría que el aval es “del inquilino” o “del piso”: es del contrato, es decir, de esa relación concreta. La agregación es la forma de decir en el diagrama: “esta relación es ya un objeto del que se pueden decir cosas”.

2.3. Qué queda dentro de la agregación

Elemento	¿Dentro?	Comentario
La relación agregada	Sí	Es el núcleo: sus ocurrencias son las de la agregación
Las entidades participantes	Sí	Identifican cada ocurrencia de la agregación
Los atributos de la relación agregada	Sí	Describen cada ocurrencia de la agregación (fecha_incorporacion, funcion)
Los atributos de las entidades	Sí (con su entidad)	Siguen siendo de la entidad, no de la agregación
Las relaciones externas	No	Unen la agregación con otras entidades
Los atributos de las relaciones externas	No	Son de la relación externa (las horas de uso son de usa)

2.4. Identificación de las ocurrencias

Como una ocurrencia de relación queda identificada por sus participantes, una ocurrencia de la agregación se identifica por los identificadores de las entidades de la relación agregada: la participación (Eva, P1) se identifica por el par (dni de Eva, código de P1). No hace falta (ni se debe) inventar un identificador para la agregación.

⚠️ Importante: De aquí se sigue una condición de uso: solo puedes agregar una relación si cada combinación de participantes aparece como mucho una vez. Si Eva pudiera incorporarse a P1, salir y volver a incorporarse (dos participaciones distintas con el mismo par), la relación trabaja no podría representar ambas, y mucho menos agregarse. En ese caso hay que añadir un participante (por ejemplo, un periodo) o convertir la participación en entidad (sección 11).

2.5. La agregación entre las abstracciones de datos

La agregación es una de las abstracciones clásicas del modelado de datos, que ya conoces en parte:

Abstracción	Qué hace	Relación que expresa	Dónde la has visto
Clasificación	Agrupa objetos con propiedades comunes en un tipo	“es una instancia de”	Ocurrencia → tipo de entidad (módulo 05)
Generalización	Agrupa tipos en un supertipo común	“es un” (is-a)	Jerarquías (módulo 11)
Agregación	Trata un conjunto de elementos relacionados como un objeto de nivel superior	“está formado por” / “es una relación tratada como objeto”	Este módulo
Asociación	Relaciona objetos independientes	“está relacionado con”	Relaciones (módulos 06-09)

En sentido amplio, toda entidad es una agregación de sus atributos (una PERSONA “agrega” nombre, fecha de nacimiento, dirección…). En el modelo E/R extendido, sin embargo, el término agregación se reserva para el caso concreto que estudiamos aquí: una relación tratada como entidad.

3. Historia y presencia en las notaciones

3.1. El origen: Smith y Smith (1977)

El concepto procede del artículo de John Miles Smith y Diane C. P. Smith, “Database Abstractions: Aggregation and Generalization”, publicado en 1977 en la revista ACM Transactions on Database Systems. En él proponen dos abstracciones fundamentales para el diseño de bases de datos:

Generalización: un conjunto de objetos similares se considera como un objeto genérico (el origen de las jerarquías del módulo 11).
Agregación: una relación entre objetos se considera como un objeto de nivel superior. Su ejemplo canónico es el de una reserva: cierta relación entre una persona, un hotel y una fecha se abstrae como el objeto “reserva”.

Su aportación clave fue mostrar que ambas abstracciones se pueden aplicar repetidamente, construyendo jerarquías de objetos cada vez más abstractos, y que un modelo de datos debería soportarlas de forma natural.

3.2. Del E/R de Chen al E/R extendido

El modelo de Chen de 1976 no incluía ninguna de las dos abstracciones. A lo largo de los años ochenta, distintos autores ampliaron el modelo con generalización, especialización, categorías y agregación, dando lugar a lo que hoy llamamos modelo E/R extendido (EER, Enhanced o Extended Entity-Relationship). La agregación es, de todas estas extensiones, la que menos uniformidad tiene entre autores y herramientas.

3.3. Silberschatz, Korth y Sudarshan

El manual Database System Concepts (Silberschatz, Korth y Sudarshan) es probablemente el que más ha difundido la representación gráfica que usamos: la agregación se dibuja como un rectángulo que encierra el rombo de la relación y sus entidades, y de ese rectángulo salen las aristas hacia las relaciones externas. En sus ejemplos se agrega una relación (por ejemplo, la tutela de un estudiante por un profesor en un proyecto) para relacionarla después con otra entidad (la evaluación de esa tutela), exactamente el patrón de este módulo.

3.4. Elmasri y Navathe

En Fundamentals of Database Systems, Elmasri y Navathe tratan la agregación en el capítulo del modelo EER dedicado a los conceptos de abstracción (clasificación, identificación, especialización/generalización, agregación y asociación). Señalan explícitamente que el modelo E/R no permite relacionar una relación con otra, y discuten un ejemplo de entrevistas de trabajo: una empresa entrevista a candidatos y algunas entrevistas dan lugar a ofertas de empleo. Analizan las alternativas (una ternaria, que obligaría a que toda entrevista tuviera oferta; una agregación; y convertir la entrevista en entidad débil), que son exactamente las que estudiarás en las secciones 10 y 11.

3.5. La tradición española

En los textos españoles de referencia (de Miguel, Piattini y Marcos) el modelo E/R extendido incluye la agregación con una representación similar: un recuadro que engloba la relación y sus entidades. En ellos encontrarás también el término agregación aplicado a la relación compuesto/componente (un todo formado por partes, como un coche y sus piezas), más cercana a la idea de UML que veremos a continuación. En este curso, salvo que se diga lo contrario, “agregación” significa siempre relación tratada como entidad.

3.6. UML: agregación y composición no son lo mismo

⚠️ Importante: Si has estudiado UML (por ejemplo, en Programación o en Entornos de Desarrollo), conoces la agregación (rombo hueco) y la composición (rombo relleno). No son la agregación del modelo E/R. Es una coincidencia de nombre que provoca muchos errores.

Concepto	Qué expresa	Ejemplo	Equivalente en el modelo E/R
Agregación UML (rombo hueco)	Relación todo-parte débil: las partes pueden existir sin el todo y compartirse	Un EQUIPO está formado por JUGADORES	Una relación binaria 1:N o N:M normal
Composición UML (rombo relleno)	Relación todo-parte fuerte: las partes no existen sin el todo y pertenecen a uno solo	Un PEDIDO se compone de LÍNEAS	Una entidad débil con su relación de identificación (módulo 10)
Clase asociación UML	Una asociación que tiene atributos y puede tener sus propias asociaciones	La asociación Empleado-Proyecto como clase Participación asociada a Máquina	Agregación del E/R
Agregación E/R	Una relación tratada como entidad para relacionarla con otras	PARTICIPACIÓN usa MAQUINARIA	—

Es decir: el equivalente UML de la agregación del E/R es la clase asociación (association class), una clase unida con línea discontinua a una asociación, que puede tener atributos y participar en otras asociaciones.

3.7. Notaciones de pata de gallo

Las notaciones de pata de gallo (IE, Barker, la de Oracle SQL Developer Data Modeler o MySQL Workbench) no tienen agregación: ni siquiera tienen relaciones N:M con atributos. En ellas, la relación agregada se representa como una entidad asociativa (o de intersección) y la relación externa se une a esa entidad. Lo verás en el diagrama de tablas de la sección 13.

3.8. Resumen de notaciones

Notación	¿Tiene agregación?	Cómo se representa
Chen original (1976)	No	—
Chen extendida / de Miguel-Piattini (la del curso)	Sí	Recuadro alrededor de la relación y sus entidades
Silberschatz, Korth y Sudarshan	Sí	Recuadro alrededor de la relación y sus entidades
Elmasri y Navathe (EER)	Como concepto de abstracción	La discuten y proponen alternativas, sobre todo la entidad débil
UML	Como clase asociación	Clase unida con línea discontinua a la asociación
Pata de gallo (IE, Barker)	No	Entidad asociativa

4. Representación en la notación del curso

4.1. Reglas de dibujo

En el curso dibujamos la agregación con un subgraph de Mermaid (en papel, un rectángulo grande) que cumple estas reglas:

Encierra el rombo de la relación agregada, todas sus entidades participantes y los atributos de la relación.
Lleva un título con el nombre de la agregación: un sustantivo en MAYÚSCULAS que nombre el hecho (PARTICIPACIÓN, MATRÍCULA, CONSULTA, OPERACIÓN), seguido opcionalmente de “(agregación)”.
Las relaciones externas se unen al recuadro, no a ninguna de las entidades de dentro.
La cardinalidad de cada arista sigue la convención del curso (sección 5).
Las relaciones externas y sus atributos quedan fuera del recuadro.

Este es el aspecto del código Mermaid, por si quieres dibujar tus propios diagramas:

flowchart LR
    subgraph PARTICIPACION["PARTICIPACIÓN (agregación)"]
        direction LR
        EMPLEADO[EMPLEADO] ---|"(1,n)"| trabaja{"trabaja<br/>N:M"}
        trabaja ---|"(0,n)"| PROYECTO[PROYECTO]
    end
    PARTICIPACION ---|"(0,n)"| usa{"usa<br/>N:M"}
    usa ---|"(0,n)"| MAQUINARIA[MAQUINARIA]

Como en el resto del curso, el tipo de correspondencia de cada relación (N:M, 1:N, 1:N:M…) se escribe dentro del rombo, debajo del verbo.

💡 Consejo: En papel o en una pizarra, dibuja primero la relación interior como siempre, después el rectángulo que la envuelve, y por último las relaciones externas tocando el borde del rectángulo. Si una arista externa toca una entidad de dentro, has dibujado otra cosa (sección 4.3).

4.2. El nombre de la agregación

El rombo interior conserva su verbo (trabaja) y la caja recibe un sustantivo (PARTICIPACIÓN). Esta doble denominación es útil: el verbo se usa al leer la relación interior (“un empleado trabaja en un proyecto”) y el sustantivo al leer las externas (“una participación usa máquinas”). Si no encuentras un sustantivo natural para la caja, quizá la agregación no sea la estructura adecuada.

4.3. Entidades de dentro que también participan fuera

Una entidad incluida en la agregación puede participar, por sí misma, en otras relaciones. Por ejemplo, el empleado tiene un departamento, y además un empleado (con el papel de evaluador) evalúa cada participación:

flowchart LR
    subgraph PARTICIPACION["PARTICIPACIÓN (agregación)"]
        direction LR
        EMPLEADO[EMPLEADO] ---|"(1,n)"| trabaja{"trabaja<br/>N:M"}
        trabaja ---|"(0,n)"| PROYECTO[PROYECTO]
    end
    PARTICIPACION ---|"(0,n)"| evalua{"evalúa<br/>1:N"}
    evalua ---|"evaluador (0,1)"| EMPLEADO
    PARTICIPACION ---|"(0,n)"| usa{"usa<br/>N:M"}
    usa ---|"(0,n)"| MAQUINARIA[MAQUINARIA]

Aquí hay que distinguir dos aristas que parecen similares:

La arista PARTICIPACIÓN — evalúa toca el recuadro: une la relación con la participación (el par empleado-proyecto).
La arista evalúa — EMPLEADO toca la entidad de dentro: une la relación con un empleado en su papel de evaluador.

Lectura: “cada participación es evaluada por como mucho un empleado (0,1); un empleado evalúa de 0 a n participaciones (0,n)”. Una regla adicional, como “nadie evalúa su propia participación”, no se puede expresar en el diagrama y se escribe como restricción textual.

5. Cardinalidades entre la agregación y otras entidades

5.1. La regla

La convención del curso no cambia: la pareja (mín, máx) escrita junto a un elemento indica con cuántas ocurrencias de ese elemento se relaciona una ocurrencia del otro. Lo único nuevo es que uno de los extremos es la agregación, y una ocurrencia de la agregación es una ocurrencia de la relación agregada.

📘 Concepto: En una relación S entre una agregación A (de la relación R) y una entidad C:

La cardinalidad junto a C indica con cuántas ocurrencias de C se relaciona una ocurrencia concreta de R (un par concreto, por ejemplo Eva en P1).

La cardinalidad junto a A indica con cuántas ocurrencias de R (cuántos pares) se relaciona una ocurrencia concreta de C.

5.2. Las preguntas que hay que hacerse

Cardinalidad	Pregunta modelo	En el ejemplo
Junto a la entidad externa C	“Para una participación concreta (un empleado en un proyecto), ¿cuántas máquinas como mínimo y como máximo?”	“Eva en P1, ¿cuántas máquinas usa?” Ninguna, una o varias → (0,n)
Junto a la agregación A	“Para una máquina concreta, ¿en cuántas participaciones como mínimo y como máximo?”	“La grúa G2, ¿en cuántas participaciones se usa?” En ninguna, una o varias → (0,n)

💡 Consejo: Para no equivocarte, nombra siempre la ocurrencia de la agregación con sus dos componentes: “Eva en P1”, “Ana matriculada en Bases de Datos”, “el vuelo IB3170 del 4 de octubre con el avión EC-MLA”. Si te sorprendes diciendo “un empleado usa…”, estás pensando en EMPLEADO y no en PARTICIPACIÓN.

5.3. Ejemplo resuelto con ocurrencias

Ocurrencias de la agregación (las de trabaja):

Participación	Empleado	Proyecto	fecha_incorporacion	funcion
π1	Eva	P1	01/03/2026	jefa de obra
π2	Eva	P2	15/05/2026	asesora
π3	Luis	P1	10/03/2026	operario
π4	Marta	P3	02/02/2026	operaria

(Los nombres π1…π4 son solo etiquetas para hablar de ellas en el texto; la agregación no tiene identificador propio: π1 es el par (Eva, P1).)

Ocurrencias de usa:

Participación	Máquina	horas
(Eva, P1)	Grúa G2	120
(Eva, P1)	Retro R1	45
(Luis, P1)	Grúa G2	30
(Marta, P3)	Retro R1	60

Comprobación de cardinalidades:

Elemento fijado	Se relaciona con…	Recuento	Conclusión
(Eva, P1)	Grúa G2, Retro R1	2	Máximo n junto a MAQUINARIA
(Eva, P2)	—	0	Mínimo 0 junto a MAQUINARIA
Grúa G2	(Eva, P1), (Luis, P1)	2	Máximo n junto a PARTICIPACIÓN
Compresor C1	—	0	Mínimo 0 junto a PARTICIPACIÓN

Y esta inserción en usa sería rechazada por el modelo:

Participación	Máquina	Por qué
(Luis, P3)	Grúa G2	(Luis, P3) no es una ocurrencia de la agregación: Luis no trabaja en P3

📘 Concepto: Esta es la propiedad más valiosa de la agregación: la relación externa solo puede referirse a ocurrencias existentes de la relación agregada. Es una restricción de inclusión que el modelo garantiza por construcción, sin necesidad de escribirla aparte.

5.4. Las mínimas tienen aquí pleno sentido

En el módulo 09 viste que, en las ternarias, la mínima se calcula sobre pares que participan juntos en la relación y por eso es casi siempre 1: una ternaria no puede tener un par sin tercero. En la agregación la situación es distinta: la mínima junto a la entidad externa se calcula sobre ocurrencias que existen de la relación agregada, y esas ocurrencias existen por sí mismas. Por eso aquí la mínima 0 es perfectamente normal y todas las mínimas tienen un significado claro:

Mínima junto a C	Significado	Ejemplo
0	Una ocurrencia de R puede existir sin relacionarse con ninguna C	Una participación sin máquinas
1	Toda ocurrencia de R debe relacionarse con al menos una C	Toda operación de vuelo tiene al menos un tripulante
k > 1	Toda ocurrencia de R debe relacionarse con al menos k ocurrencias de C	Toda operación de vuelo tiene al menos 2 tripulantes (comandante y primer oficial)

Y la mínima junto a la agregación indica si toda ocurrencia de C tiene que estar asociada a alguna ocurrencia de R: (0,…) si puede haber máquinas sin usar; (1,…) si toda máquina debe haberse usado en alguna participación (poco habitual).

5.5. Plantillas de lectura

Extremo	Plantilla	Ejemplo
Junto a C	“Cada [ocurrencia de R, dicha con sus dos participantes] se relaciona con entre mín y máx [C]”	“Cada empleado, en cada proyecto en el que trabaja, usa entre 0 y n máquinas”
Junto a A	“Cada [C] se relaciona con entre mín y máx [ocurrencias de R]”	“Cada máquina se usa en entre 0 y n participaciones de empleados en proyectos”

5.6. Las cardinalidades de la relación interior no cambian

La relación agregada conserva sus propias cardinalidades, que se calculan y leen como siempre (módulos 06-09): “un proyecto tiene entre 1 y n empleados” (1,n) junto a EMPLEADO; “un empleado trabaja en entre 0 y n proyectos” (0,n) junto a PROYECTO. Agregar una relación no altera su significado interno; solo le permite participar en otras relaciones.

6. Ejemplos completos

6.1. Participaciones en proyectos y maquinaria

Es el ejemplo que has seguido hasta ahora. Lo completamos con identificadores y restricciones:

flowchart LR
    subgraph PARTICIPACION["PARTICIPACIÓN (agregación)"]
        direction LR
        EMPLEADO[EMPLEADO] ---|"(1,n)"| trabaja{"trabaja<br/>N:M"}
        trabaja ---|"(0,n)"| PROYECTO[PROYECTO]
        trabaja --- t_fecha([fecha_incorporacion])
        trabaja --- t_func([funcion])
        EMPLEADO --- e_id([<u>emp_id</u>])
        PROYECTO --- p_id([<u>proyecto_id</u>])
    end
    PARTICIPACION ---|"(0,n)"| usa{"usa<br/>N:M"}
    usa ---|"(0,n)"| MAQUINARIA[MAQUINARIA]
    usa --- u_horas([horas])
    MAQUINARIA --- m_id([<u>maquina_id</u>])
    MAQUINARIA --- m_desc([descripcion])

Lectura completa:

Un empleado trabaja en 0 a n proyectos; un proyecto tiene de 1 a n empleados. De cada participación se guardan la fecha de incorporación y la función.
Cada participación (un empleado en un proyecto) usa de 0 a n máquinas; cada máquina se usa en 0 a n participaciones. De cada uso se guardan las horas.

Restricciones que no expresa el diagrama:

RS1: las horas de uso son mayores que 0.
RS2: una máquina solo puede usarse en proyectos del departamento al que pertenece la máquina (si se modelara esa pertenencia).

6.2. Matrículas, convocatorias y calificaciones

“Un instituto gestiona las matrículas del curso académico en vigor (al acabar el curso los datos se archivan en otro sistema). Cada alumno se matricula de una o varias asignaturas, y de cada matrícula interesa la fecha y si el alumno repite la asignatura. En el curso hay dos convocatorias de evaluación, ordinaria y extraordinaria. En cada convocatoria a la que se presenta, el alumno obtiene una calificación de la asignatura (de 0 a 10).”

La calificación no es del alumno (tiene muchas), ni de la asignatura (tiene muchos alumnos), ni siquiera del par alumno-convocatoria (en una convocatoria el alumno tiene una nota por asignatura): es de la matrícula en una convocatoria. La matrícula existe aunque el alumno no se haya presentado a ninguna convocatoria todavía, así que la estructura es una agregación:

flowchart LR
    subgraph MATRICULA["MATRÍCULA (agregación)"]
        direction LR
        ALUMNO[ALUMNO] ---|"(0,n)"| se_matricula{"se matricula<br/>N:M"}
        se_matricula ---|"(1,n)"| ASIGNATURA[ASIGNATURA]
        se_matricula --- m_fecha([fecha_matricula])
        se_matricula --- m_rep([repetidor])
    end
    MATRICULA ---|"(0,n)"| se_califica{"se califica en<br/>N:M"}
    se_califica ---|"(0,2)"| CONVOCATORIA[CONVOCATORIA]
    se_califica --- c_nota([nota])

Cardinalidades de la relación externa:

Pregunta	Respuesta	Cardinalidad
Para la matrícula de Ana en Bases de Datos, ¿en cuántas convocatorias se califica?	En ninguna (aún no se ha evaluado o no se presenta), en una o en las dos	(0,2) junto a CONVOCATORIA
Para la convocatoria ordinaria, ¿cuántas matrículas se califican?	Muchas (o ninguna, antes de la evaluación)	(0,n) junto a MATRÍCULA

Observa la máxima 2: no hay más convocatorias en el curso. Las cardinalidades no tienen por qué ser solo 1 o n.

Ocurrencias:

Matrícula (alumno, asignatura)	Convocatoria	nota
(Ana, Bases de Datos)	Ordinaria	4,5
(Ana, Bases de Datos)	Extraordinaria	6,0
(Ana, Programación)	Ordinaria	8,2
(Bruno, Bases de Datos)	Ordinaria	7,1

La matrícula (Bruno, Programación) puede existir sin ninguna fila en se califica en (Bruno aún no se ha presentado).

Restricciones textuales:

RS1: la nota está entre 0 y 10.
RS2: una matrícula solo se califica en la convocatoria extraordinaria si en la ordinaria no se aprobó (nota menor que 5) o no se presentó.

💡 Consejo: ¿Y si la base de datos guardase todo el historial del alumno, con los cursos en que repite? Entonces el par (Ana, Bases de Datos) podría aparecer en dos cursos académicos distintos y la relación binaria ya no serviría. Tendrías que agregar una ternaria ALUMNO-ASIGNATURA-CURSO ACADÉMICO (sección 8) o convertir la matrícula en entidad (sección 11).

6.3. Consultas médicas y recetas

“En un centro de salud los médicos atienden a los pacientes. Un médico atiende a un mismo paciente como mucho una vez al día, pero puede atenderlo muchos días. De cada consulta interesan la hora, el motivo y el diagnóstico. En una consulta el médico puede recetar varios medicamentos, indicando la posología y la duración del tratamiento en días.”

Como el par médico-paciente se repite en días distintos, la consulta es una ternaria MÉDICO-PACIENTE-DÍA (módulo 09, sección 7.3). Fijando pares: un médico y un paciente, varios días; un médico y un día, varios pacientes; un paciente y un día, varios médicos (por ejemplo, su médico de familia y el pediatra). Es de tipo N:M:P. Esa ternaria es la que agregamos como CONSULTA y relacionamos con MEDICAMENTO:

flowchart LR
    subgraph CONSULTA["CONSULTA (agregación)"]
        direction LR
        MEDICO[MÉDICO] ---|"(1,n)"| atiende{"atiende<br/>N:M:P"}
        atiende ---|"(1,n)"| PACIENTE[PACIENTE]
        atiende ---|"(1,n)"| DIA[DÍA]
        atiende --- a_hora([hora])
        atiende --- a_motivo([motivo])
        atiende --- a_diag([diagnostico])
    end
    CONSULTA ---|"(0,n)"| receta{"receta<br/>N:M"}
    receta ---|"(0,n)"| MEDICAMENTO[MEDICAMENTO]
    receta --- r_pos([posologia])
    receta --- r_dur([duracion_dias])

Pregunta	Respuesta	Cardinalidad
En la consulta de la Dra. López a Juan el 04/10/2026, ¿cuántos medicamentos se recetan?	Ninguno, uno o varios	(0,n) junto a MEDICAMENTO
El ibuprofeno 600 mg, ¿en cuántas consultas se ha recetado?	Ninguna, una o muchas	(0,n) junto a CONSULTA

📘 Concepto: La entidad DÍA representa un calendario: sus ocurrencias son fechas. Es un recurso habitual cuando la fecha forma parte de la identidad del hecho. En el modelo relacional normalmente no genera tabla propia: la fecha queda como columna de la clave de la tabla de consultas.

Alternativa: si en el sistema real cada receta tiene número propio (la receta electrónica) y datos como la fecha de dispensación en la farmacia, la RECETA debería ser una entidad, relacionada con la consulta (1:N) y con los medicamentos. Cuanta más vida propia tiene un hecho, más se acerca a ser entidad (sección 11).

6.4. Vuelos operados y tripulaciones

“Una aerolínea programa vuelos (por ejemplo, el IB3170 Madrid-Lima, con salida programada a las 23:55). Cada día que se opera un vuelo se le asigna un avión, identificado por su matrícula (EC-MLA). Un avión opera varios vuelos el mismo día y un vuelo se opera con distintos aviones según el día. De cada operación interesa la hora real de salida y de llegada. A cada vuelo operado se le asigna una tripulación de, como mínimo, dos tripulantes (comandante y primer oficial), cada uno con una función.”

Primero, la relación interior. El hecho “el vuelo V se opera el día F con el avión A” es una ternaria VUELO-AVIÓN-FECHA (mínimas calculadas, como en el módulo 09, sobre pares que participan juntos):

Fijamos…	Pregunta	Cardinalidad
vuelo IB3170, día 04/10/2026 (el vuelo se opera ese día)	¿Con cuántos aviones? Exactamente uno	(1,1) junto a AVIÓN
avión EC-MLA, día 04/10/2026 (el avión vuela ese día)	¿Cuántos vuelos opera? Uno o varios	(1,n) junto a VUELO
vuelo IB3170, avión EC-MLA (ese avión ha operado ese vuelo)	¿En cuántos días? Uno o muchos	(1,n) junto a FECHA

Tipo 1:N:M. La agregamos como OPERACIÓN y la relacionamos con TRIPULANTE:

flowchart LR
    subgraph OPERACION["OPERACIÓN (agregación)"]
        direction LR
        VUELO[VUELO] ---|"(1,n)"| opera{"se opera<br/>1:N:M"}
        opera ---|"(1,1)"| AVION[AVIÓN]
        opera ---|"(1,n)"| FECHA[FECHA]
        opera --- o_sal([hora_real_salida])
        opera --- o_lle([hora_real_llegada])
    end
    OPERACION ---|"(0,n)"| tripula{"tripula<br/>N:M"}
    tripula ---|"(2,n)"| TRIPULANTE[TRIPULANTE]
    tripula --- t_funcion([funcion])

Pregunta	Respuesta	Cardinalidad
Para el IB3170 del 04/10/2026 operado con el EC-MLA, ¿cuántos tripulantes?	Al menos 2, normalmente bastantes más	(2,n) junto a TRIPULANTE
Para la tripulante Laura Sanz, ¿en cuántas operaciones participa?	En muchas (o en ninguna, si acaba de incorporarse)	(0,n) junto a OPERACIÓN

Ocurrencias:

Operación (vuelo, avión, fecha)	Tripulante	funcion
(IB3170, EC-MLA, 04/10/2026)	Laura Sanz	comandante
(IB3170, EC-MLA, 04/10/2026)	Diego Ruiz	primer oficial
(IB3170, EC-MLA, 04/10/2026)	Sofía Marín	sobrecargo
(IB3171, EC-MLA, 05/10/2026)	Laura Sanz	comandante
(IB3171, EC-MLA, 05/10/2026)	Diego Ruiz	primer oficial

⚠️ Importante: La mínima 2 junto a TRIPULANTE significa que una operación no puede existir sin al menos dos tripulantes. En la práctica, esto obliga a registrar la operación y su tripulación en la misma transacción, o a aceptar que la regla se compruebe al “cerrar” la programación. Si la aerolínea programa los aviones semanas antes que las tripulaciones, la mínima correcta sería 0 y la regla “al menos dos tripulantes antes del despegue” se escribiría como restricción textual.

Restricciones textuales:

RS1: en cada operación hay exactamente un tripulante con función “comandante” y uno con función “primer oficial”.
RS2: un tripulante no puede estar en dos operaciones que se solapen en el tiempo.
RS3: los pilotos deben estar habilitados para el modelo del avión de la operación (inclusión respecto a una relación TRIPULANTE habilitado para MODELO, si se modela).

6.5. Resumen de los ejemplos

Agregación	Relación interior	Tipo interior	Relación externa	Cardinalidad junto a la entidad externa
PARTICIPACIÓN	EMPLEADO trabaja en PROYECTO	N:M	usa MAQUINARIA	(0,n)
MATRÍCULA	ALUMNO se matricula de ASIGNATURA	N:M	se califica en CONVOCATORIA	(0,2)
CONSULTA	MÉDICO atiende a PACIENTE en DÍA	N:M:P	receta MEDICAMENTO	(0,n)
OPERACIÓN	VUELO se opera con AVIÓN en FECHA	1:N:M	tripula TRIPULANTE	(2,n)

7. Agregación de relaciones N:M, 1:N y 1:1

¿Se puede agregar cualquier relación binaria? Sí, pero no siempre aporta lo mismo. Depende de cómo se identifican sus ocurrencias.

7.1. Relaciones N:M: el caso natural

En una N:M, cada ocurrencia es un par que no se puede reducir a ninguna de las dos entidades: Eva en P1 no es “Eva” ni “P1”. Por eso todo lo que se diga de ese par necesita la agregación (o convertir el par en entidad). Es, con diferencia, el caso más frecuente, y todos los ejemplos de la sección 6 con relación interior binaria son N:M.

7.2. Relaciones 1:N: casi equivalen a la entidad del lado N

En una 1:N, cada ocurrencia de la entidad del lado “N” participa como mucho una vez. Por tanto, cada ocurrencia de la relación se puede identificar solo con esa entidad. Ejemplo:

“Cada alumno de FP hace las prácticas (FCT) en una sola empresa; una empresa acoge a varios alumnos. Cada estancia en prácticas tiene asignado un profesor del centro que hace el seguimiento (que puede no estar asignado todavía).”

flowchart LR
    subgraph PRACTICA["PRÁCTICA (agregación)"]
        direction LR
        ALUMNO[ALUMNO] ---|"(0,n)"| hace{"hace prácticas en<br/>1:N"}
        hace ---|"(0,1)"| EMPRESA[EMPRESA]
    end
    PRACTICA ---|"(0,n)"| sigue{"es seguida por<br/>1:N"}
    sigue ---|"(0,1)"| PROFESOR[PROFESOR]

Una práctica es (Ana, TecnoSoft); como Ana solo tiene una empresa, “la práctica de Ana” y “Ana” se identifican igual. ¿Podríamos haber relacionado PROFESOR directamente con ALUMNO? Casi:

Modelo	Qué expresa	Qué falta
Agregación PRÁCTICA es seguida por PROFESOR	Se hace el seguimiento de la estancia en la empresa; si el alumno no tiene empresa, no puede tener profesor de seguimiento	Nada
ALUMNO es seguido por PROFESOR	Se hace el seguimiento del alumno	Restricción textual: “solo los alumnos con empresa asignada pueden tener profesor de seguimiento”

Ambos modelos acaban igual en el relacional: la tabla de alumnos tendrá una columna con la empresa y otra con el profesor, y una restricción que impida tener profesor sin empresa (algo así como CHECK (dni_profesor IS NULL OR cif_empresa IS NOT NULL), como verás en el módulo de transformación).

💡 Consejo: Agregar una 1:N es correcto y a veces más expresivo, pero no imprescindible. Úsala cuando quieras dejar claro que el hecho externo depende de la asociación y no de la entidad. Si dudas, relaciona con la entidad del lado N y añade la restricción.

7.3. Relaciones 1:1: el significado cambia según con qué se relacione

En una 1:1, cada ocurrencia se identifica por cualquiera de sus dos participantes. Ejemplo:

“Cada departamento tiene como mucho un director, y un empleado dirige como mucho un departamento. La empresa asigna un coche oficial al cargo de dirección.”

flowchart LR
    subgraph DIRECCION["DIRECCIÓN (agregación)"]
        direction LR
        EMPLEADO[EMPLEADO] ---|"(0,1)"| dirige{"dirige<br/>1:1"}
        dirige ---|"(0,1)"| DEPARTAMENTO[DEPARTAMENTO]
    end
    DIRECCION ---|"(0,1)"| asignado{"tiene asignado<br/>1:1"}
    asignado ---|"(0,1)"| COCHE["COCHE OFICIAL"]

Aquí la agregación tiene un significado muy preciso, que se ve comparando las tres opciones posibles:

El coche se relaciona con…	Significado	Si Eva deja de dirigir Ventas y la sustituye Luis…
EMPLEADO	El coche es de la persona	Eva se queda el coche
DEPARTAMENTO	El coche es del departamento	El coche sigue en Ventas, lo use quien lo use
DIRECCIÓN (agregación)	El coche es del par director-departamento	La ocurrencia (Eva, Ventas) desaparece y con ella la asignación: hay que asignar el coche de nuevo a (Luis, Ventas)

Las tres son correctas; dependen de lo que quiera la empresa. La agregación de una 1:1 tiene sentido cuando el hecho externo pertenece al cargo ocupado por esa persona, y debe revisarse si cambia cualquiera de los dos.

7.4. Resumen

Tipo de la relación agregada	Cómo se identifica una ocurrencia	¿Aporta la agregación?
N:M	Por el par completo	Sí, imprescindible (o convertir en entidad)
1:N	Por la entidad del lado N	Opcional: equivale a relacionar con esa entidad + restricción de inclusión
1:1	Por cualquiera de las dos entidades	Opcional: expresa que el hecho es del par y caduca si cambia cualquiera
Ternaria o n-aria	Según sus máximas (módulo 09)	Sí cuando el hecho externo depende del trío

8. Agregación de relaciones ternarias

8.1. Cómo funciona

Nada impide agregar una relación de grado 3 o superior: la agregación encierra el rombo y sus tres entidades, y cada ocurrencia de la agregación es un trío. Ya lo has visto en la CONSULTA (MÉDICO-PACIENTE-DÍA) y en la OPERACIÓN (VUELO-AVIÓN-FECHA). Las cardinalidades de la relación externa se calculan igual:

Junto a la entidad externa: “para un trío concreto, ¿cuántas C?” (“para el IB3170 del 04/10/2026 con el EC-MLA, ¿cuántos tripulantes?”).
Junto a la agregación: “para una C concreta, ¿cuántos tríos?”.

💡 Consejo: Cuando la ternaria interior es de tipo 1:N:M o 1:1:N, un par basta para identificar cada trío. La operación (IB3170, EC-MLA, 04/10/2026) queda identificada por (IB3170, 04/10/2026), porque el avión está determinado. Eso no cambia el diagrama, pero sí la clave de la tabla (sección 13).

8.2. Una agregación que participa en una ternaria

La relación externa tampoco tiene por qué ser binaria. En el módulo 09 (sección 11) estudiaste el horario como cuaternaria y viste que, si primero se decide quién imparte cada asignatura en cada grupo y luego se programa, el modelo natural es una agregación. Aquí está:

flowchart LR
    subgraph IMPARTICION["IMPARTICIÓN (agregación)"]
        direction LR
        PROFESOR[PROFESOR] ---|"(1,1)"| imparte{"imparte<br/>1:N:M"}
        imparte ---|"(1,n)"| ASIGNATURA[ASIGNATURA]
        imparte ---|"(1,n)"| GRUPO[GRUPO]
    end
    IMPARTICION ---|"(1,1)"| se_programa{"se programa en<br/>1:1:N"}
    se_programa ---|"(1,1)"| AULA[AULA]
    se_programa ---|"(1,n)"| FRANJA["FRANJA HORARIA"]

La relación se programa en es una ternaria entre la agregación IMPARTICIÓN, AULA y FRANJA. Sus cardinalidades se calculan fijando pares que participan juntos, como en cualquier ternaria (módulo 09), pero uno de los elementos del par puede ser una ocurrencia de la agregación:

Fijamos…	Pregunta	Cardinalidad
la impartición (Ana, Bases de Datos, 1º DAM-A) y el aula A1, programadas juntas	¿En cuántas franjas? En una o en varias	(1,n) junto a FRANJA
la impartición (Ana, Bases de Datos, 1º DAM-A) y la franja lunes 8:00, programadas juntas	¿En cuántas aulas? Exactamente una	(1,1) junto a AULA
el aula A1 y la franja lunes 8:00, ocupadas	¿Cuántas imparticiones? Exactamente una	(1,1) junto a IMPARTICIÓN

Este modelo recoge en la estructura la regla “un aula, en una franja, tiene una sola clase”, y además permite registrar quién imparte cada asignatura en cada grupo antes de hacer el horario. Siguen quedando reglas que el diagrama no expresa:

RS1: un profesor no puede tener dos sesiones programadas en la misma franja.
RS2: un grupo no puede tener dos sesiones programadas en la misma franja.

9. Agregaciones anidadas

9.1. Agregar una relación en la que ya participa una agregación

Una relación externa que une una agregación con otra entidad es, a su vez, una relación. Por tanto, también se puede agregar. Volvamos a las matrículas (sección 6.2) y añadamos un requisito:

“Un alumno puede solicitar la revisión de una calificación. La revisión la resuelve un único profesor, que anota la nota revisada y la fecha de resolución.”

La revisión no es de la matrícula (que tiene hasta dos calificaciones), ni de la convocatoria: es de una calificación concreta, es decir, de una ocurrencia de se califica en. Agregamos esa relación como CALIFICACIÓN, que contiene a su vez la agregación MATRÍCULA:

flowchart LR
    subgraph CALIFICACION["CALIFICACIÓN (agregación)"]
        direction LR
        subgraph MATRICULA["MATRÍCULA (agregación)"]
            direction LR
            ALUMNO[ALUMNO] ---|"(0,n)"| se_matricula{"se matricula<br/>N:M"}
            se_matricula ---|"(1,n)"| ASIGNATURA[ASIGNATURA]
        end
        MATRICULA ---|"(0,n)"| se_califica{"se califica en<br/>N:M"}
        se_califica ---|"(0,2)"| CONVOCATORIA[CONVOCATORIA]
        se_califica --- c_nota([nota])
    end
    CALIFICACION ---|"(0,n)"| revisa{"revisa<br/>1:N"}
    revisa ---|"(0,1)"| PROFESOR[PROFESOR]
    revisa --- r_nota([nota_revisada])
    revisa --- r_fecha([fecha_resolucion])

Lectura de la relación exterior:

Cada calificación (Ana en Bases de Datos, convocatoria ordinaria) es revisada por como mucho un profesor: (0,1) junto a PROFESOR.
Cada profesor revisa de 0 a n calificaciones: (0,n) junto a CALIFICACIÓN.

Una ocurrencia de CALIFICACIÓN se identifica por ((alumno, asignatura), convocatoria): por los identificadores de todas las entidades que contiene.

9.2. Cuándo parar

Las agregaciones anidadas son correctas, pero el diagrama se vuelve difícil de leer muy rápido. Recomendaciones:

Situación	Recomendación
Un nivel de agregación	Normal y legible
Dos niveles	Aceptable si cada nivel tiene un nombre claro (MATRÍCULA, CALIFICACIÓN)
Tres o más niveles	Convierte los niveles intermedios en entidades (débiles o con identificador propio): ganarás legibilidad sin perder información
La agregación interior tiene muchos atributos o se usa en muchas relaciones	Mejor como entidad desde el principio

💡 Consejo: Una buena señal de que una agregación debería ser entidad es que necesites agregarla otra vez. Si el hecho tiene tanta vida propia que participa en relaciones que a su vez participan en otras, probablemente el negocio ya lo trata como una “cosa” con identidad (un expediente, una solicitud, un documento).

10. Agregación frente a ternaria

10.1. Las mismas tres entidades, dos modelos distintos

Con tres entidades A, B y C caben dos estructuras que a primera vista parecen equivalentes: una ternaria A-B-C o una binaria A-B agregada y relacionada con C. No lo son. Vamos a verlo con el ejemplo que discuten Elmasri y Navathe, adaptado:

“Las empresas entrevistan a candidatos (cada empresa entrevista a cada candidato como mucho una vez; interesa la fecha y el entrevistador). Algunas entrevistas dan lugar a una oferta de empleo (con puesto y salario). Cada oferta procede de una única entrevista.”

Modelo A: ternaria.

flowchart LR
    EMPRESA[EMPRESA] ---|"(1,n)"| entrevista{"entrevista<br/>1:N:M"}
    entrevista ---|"(1,n)"| CANDIDATO[CANDIDATO]
    entrevista ---|"(1,1)"| OFERTA[OFERTA]

Modelo B: agregación.

flowchart LR
    subgraph ENTREVISTA["ENTREVISTA (agregación)"]
        direction LR
        EMPRESA[EMPRESA] ---|"(0,n)"| entrevista{"entrevista<br/>N:M"}
        entrevista ---|"(0,n)"| CANDIDATO[CANDIDATO]
        entrevista --- e_fecha([fecha])
        entrevista --- e_entr([entrevistador])
    end
    ENTREVISTA ---|"(1,1)"| da_lugar{"da lugar a<br/>1:1"}
    da_lugar ---|"(0,1)"| OFERTA[OFERTA]

En el modelo B: cada entrevista da lugar a como mucho una oferta (0,1) junto a OFERTA; cada oferta procede de exactamente una entrevista (1,1) junto a ENTREVISTA.

10.2. Criterio 1: ¿puede existir la relación interior sin la exterior?

Estas son las entrevistas reales:

Empresa	Candidato	fecha	¿Oferta?
TecnoSoft	Ana	01/09/2026	Sí: O1 (analista, 32.000 €)
TecnoSoft	Bruno	02/09/2026	No
Datalia	Ana	05/09/2026	No

Con el modelo A (ternaria), solo se puede guardar una fila:

Empresa	Candidato	Oferta
TecnoSoft	Ana	O1

Las entrevistas de Bruno con TecnoSoft y de Ana con Datalia no se pueden registrar, porque una ocurrencia de la ternaria necesita los tres participantes. Y la fecha de la entrevista no tiene dónde guardarse sin depender de la oferta.

Con el modelo B (agregación), las tres entrevistas son ocurrencias de ENTREVISTA, y solo una de ellas aparece en da lugar a:

ENTREVISTA (empresa, candidato)	fecha	da lugar a
(TecnoSoft, Ana)	01/09/2026	O1
(TecnoSoft, Bruno)	02/09/2026	—
(Datalia, Ana)	05/09/2026	—

📘 Concepto: Criterio principal. Si la relación entre A y B existe por sí misma, aunque no haya ninguna C asociada, el modelo correcto es la agregación. La ternaria solo es adecuada cuando el hecho no existe sin los tres participantes.

10.3. Criterio 2: ¿debe C asociarse solo a pares existentes?

El parche habitual del modelo A es añadir una binaria EMPRESA-CANDIDATO para guardar todas las entrevistas, y mantener la ternaria para las que tienen oferta. Mira lo que puede pasar:

entrevista (binaria)	entrevista con oferta (ternaria)
(TecnoSoft, Ana)	(TecnoSoft, Ana, O1)
(TecnoSoft, Bruno)	(Datalia, Bruno, O2)
(Datalia, Ana)

La fila (Datalia, Bruno, O2) dice que hay una oferta procedente de una entrevista de Datalia con Bruno… que no existe en la binaria. Además, el par (TecnoSoft, Ana) está guardado dos veces. Hay redundancia y riesgo de incoherencia. La agregación hace imposible este error, porque da lugar a solo admite ocurrencias de ENTREVISTA.

💡 Consejo: El módulo 13 (Restricciones avanzadas) ofrece otra forma de evitar la incoherencia: dibujar una restricción de inclusión (flecha discontinua -.-> entre los dos rombos) que obligue a que todo par de la ternaria esté en la binaria. Es correcto, pero el par sigue guardándose dos veces y la restricción hay que comprobarla aparte. La agregación consigue lo mismo por construcción y sin redundancia.

10.4. Criterio 3: ¿tiene el par atributos propios?

La fecha y el entrevistador dependen del par (empresa, candidato), no de la oferta. En la ternaria, o no se pueden guardar (si no hay oferta) o se mezclan con la oferta. Si el par tiene atributos propios, es un indicio fuerte de agregación (o de entidad).

10.5. Criterio 4: ¿qué restricciones necesitas expresar?

Cada estructura expresa en el diagrama restricciones distintas:

Restricción	¿La expresa la ternaria?	¿La expresa la agregación?
C solo se asocia a pares (a, b) existentes	No	Sí (por construcción)
El par (a, b) puede existir sin C	No	Sí (mínima 0 junto a C)
Todo par (a, b) existente tiene al menos k ocurrencias de C	Solo para k = 1, y es implícito: en una ternaria no hay pares sin tercero (módulo 09, sección 6)	Sí (mínima k junto a C)
(a, c) → b: “un empleado usa una máquina concreta en un solo proyecto”	Sí (máxima 1 junto a B)	No: hay que escribirla como restricción textual
(b, c) → a	Sí (máxima 1 junto a A)	No

Es decir, la agregación es más expresiva respecto a la existencia y la inclusión, y la ternaria respecto a las dependencias que involucran a C con uno solo de los componentes.

10.6. Cuándo es mejor la ternaria

La ternaria es la estructura correcta cuando ningún par existe por sí solo con significado propio:

PROVEEDOR suministra PIEZA a PROYECTO: el par (proveedor, pieza) no representa nada si no se ha suministrado a un proyecto (y si hubiera que guardar el catálogo, sería otra relación binaria con su propio significado, no la interior de una agregación).
JUGADOR juega en EQUIPO durante TEMPORADA: el par (jugador, equipo) sin temporada no es un hecho del negocio.
PILOTO conduce COCHE en CARRERA: el par (piloto, coche) no existe sin la carrera.

10.7. ¿Y si la mínima junto a C es 1 o más?

Si toda ocurrencia de A-B debe asociarse al menos con una C, el criterio 1 ya no distingue: la relación interior nunca existe sin la exterior. En ese caso:

Situación	Elección
El par tiene atributos propios (fecha, función…)	Agregación: en la ternaria esos atributos se repetirían en cada C
El par no tiene atributos y la máxima junto a C es n	Ternaria y agregación guardan la misma información; la ternaria es más sencilla, la agregación expresa mejor la intención
El par no tiene atributos y la máxima junto a C es 1	Ternaria 1:N:M (con el 1 en C) o agregación: equivalentes en el relacional

La OPERACIÓN de vuelo (sección 6.4) tiene mínima 2 junto a TRIPULANTE, pero la operación tiene atributos propios (horas reales) y un avión determinado: una cuaternaria VUELO-AVIÓN-FECHA-TRIPULANTE repetiría el avión y las horas en cada tripulante. La agregación es claramente mejor.

10.8. Diagrama de decisión

flowchart TB
    Q0{"¿El mismo par A-B<br/>puede repetirse<br/>como hechos distintos?"} -->|Sí| ENT["Entidad débil o con<br/>identificador propio<br/>(sección 11)"]
    Q0 -->|No| Q1{"¿El par A-B existe<br/>sin ninguna C?"}
    Q1 -->|Sí| AGR["Agregación de A-B<br/>relacionada con C"]
    Q1 -->|No| Q2{"¿El par A-B tiene<br/>atributos propios?"}
    Q2 -->|Sí| AGR
    Q2 -->|No| Q3{"¿Necesitas dependencias<br/>como (A, C) → B?"}
    Q3 -->|Sí| TER["Ternaria A-B-C"]
    Q3 -->|No| AMB["Ternaria o agregación:<br/>elige la que mejor<br/>refleje los requisitos"]

11. Agregación frente a entidad débil

11.1. La equivalencia

Toda agregación se puede sustituir por una entidad: la relación agregada se “cosifica” y se convierte en una entidad unida a sus antiguos participantes. Si esa entidad se identifica por sus participantes, es una entidad débil con dos relaciones de identificación (módulo 10). Es la alternativa que recomiendan Elmasri y Navathe y la única que admiten las herramientas de pata de gallo.

El ejemplo de la sección 6.1, con PARTICIPACIÓN como entidad débil:

flowchart LR
    classDef debil stroke-width:4px
    EMPLEADO[EMPLEADO] ---|"(1,1)"| de_emp{"de<br/>ID"}:::debil
    de_emp ---|"(0,n)"| PARTICIPACION[PARTICIPACIÓN]:::debil
    PROYECTO[PROYECTO] ---|"(1,1)"| en_proy{"en<br/>ID"}:::debil
    en_proy ---|"(1,n)"| PARTICIPACION
    PARTICIPACION --- pa_fecha([fecha_incorporacion])
    PARTICIPACION --- pa_func([funcion])
    PARTICIPACION ---|"(0,n)"| usa{"usa<br/>N:M"}
    usa ---|"(0,n)"| MAQUINARIA[MAQUINARIA]
    usa --- u_horas([horas])

La entidad débil PARTICIPACIÓN no tiene identificador parcial: se identifica solo por el empleado y el proyecto de los que depende, así que no puede haber dos participaciones con el mismo par, igual que en la relación original.

11.2. Correspondencia de cardinalidades

En la agregación	En la entidad débil
trabaja: (1,n) junto a EMPLEADO (un proyecto tiene de 1 a n empleados)	en: (1,n) junto a PARTICIPACIÓN (un proyecto tiene de 1 a n participaciones)
trabaja: (0,n) junto a PROYECTO (un empleado está en 0 a n proyectos)	de: (0,n) junto a PARTICIPACIÓN (un empleado tiene de 0 a n participaciones)
Cada ocurrencia de trabaja tiene un empleado y un proyecto (implícito)	(1,1) junto a EMPLEADO y (1,1) junto a PROYECTO
Atributos de trabaja	Atributos de la entidad PARTICIPACIÓN
usa entre la agregación y MAQUINARIA	usa entre PARTICIPACIÓN y MAQUINARIA (relación binaria normal)

Observa la regla: la cardinalidad que en la relación original estaba junto a una entidad pasa a escribirse junto a la nueva entidad, en la relación de identificación con la otra entidad. Y junto a las entidades originales aparece siempre (1,1).

11.3. Variante: entidad con identificador propio

Si la participación tiene un código propio en la realidad (por ejemplo, un número de expediente de asignación), se modela como entidad fuerte con su identificador, unida a EMPLEADO y PROYECTO por relaciones normales con (1,1) junto a ellos. En ese caso hay que añadir la restricción de unicidad que antes era implícita:

RS: no hay dos participaciones con el mismo empleado y el mismo proyecto.

Si, en cambio, se permite que el par se repita (un empleado sale de un proyecto y vuelve a entrar, con dos fechas de incorporación), esa restricción no se escribe, y la entidad es la única opción válida: ni la relación ni la agregación pueden representar pares repetidos (sección 2.4).

11.4. Cuándo preferir cada una

Criterio	Agregación	Entidad débil	Entidad con identificador propio
Se quiere destacar que el hecho es una relación entre A y B	✔
El enunciado describe el hecho con un verbo (“trabaja”, “se matricula”)	✔
El hecho tiene identificador en la realidad (nº de expediente)			✔
El par puede repetirse		✔ (con identificador parcial, p. ej. un número de orden)	✔
El hecho tiene muchos atributos o participa en muchas relaciones		✔	✔
Se necesitan agregaciones anidadas de más de dos niveles		✔	✔
Se trabaja con una herramienta de pata de gallo		✔	✔
El diagrama debe seguir la notación Chen extendida de un examen que pide agregación	✔

💡 Consejo: Las tres opciones producen el mismo esquema relacional (salvo, en la tercera, una columna de código y una restricción UNIQUE). La elección es, sobre todo, de claridad conceptual. En un examen, si el enunciado dice “agregación”, úsala; si no, elige y justifica en una línea.

12. Agregación frente a generalización

Agregación y generalización nacieron juntas (Smith y Smith, 1977), y precisamente por eso se confunden a menudo. Son abstracciones ortogonales:

Aspecto	Generalización / especialización (módulo 11)	Agregación (este módulo)
Pregunta que responde	“¿Qué tipos de X hay?”	“¿Qué se puede decir de este hecho entre X e Y?”
Relación que expresa	“es un” (is-a): un INGENIERO es un EMPLEADO	“relación tratada como objeto”: una PARTICIPACIÓN es el hecho de que un empleado trabaje en un proyecto
Ocurrencias del elemento de nivel superior	Las mismas que las de los subtipos (cada ingeniero es un empleado)	Pares (o tríos) de ocurrencias de las entidades participantes
Herencia	Los subtipos heredan atributos y relaciones del supertipo	No hay herencia: las entidades de dentro conservan sus atributos y la agregación tiene los de la relación
Símbolo en el curso	Hexágono “es un” con (total/parcial, exclusiva/solapada)	Recuadro (`subgraph`) alrededor de la relación
Transformación al relacional	Varias estrategias (una tabla, una por subtipo, una por entidad)	Una tabla para la relación agregada, referenciada por la externa

Confusiones típicas que debes evitar:

Dibujar un recuadro alrededor de un supertipo y sus subtipos pensando en “agrupar” la jerarquía. El recuadro solo se usa para agregar una relación.
Usar la agregación como “es parte de” (un MOTOR es parte de un COCHE). Eso es una relación binaria normal (o una composición UML / entidad débil, sección 3.6).
Relacionar un subtipo cuando lo que se quiere es relacionar un hecho. “Los empleados que trabajan en proyectos usan máquinas” no significa que haya un subtipo EMPLEADO_DE_PROYECTO: las máquinas se usan en cada participación, no por ser un tipo de empleado.

13. Cómo se transforma al modelo relacional (adelanto)

Las reglas completas de transformación se estudian en el módulo 17 (Transformación E/R → relacional). Aquí solo anticipamos la idea con el ejemplo principal, para que veas que la agregación tiene una traducción directa y limpia.

13.1. El ejemplo principal

Cada entidad genera su tabla, como siempre.
La relación agregada (trabaja, N:M) genera una tabla cuya clave primaria es compuesta: las claves de EMPLEADO y PROYECTO.
La relación externa (usa, N:M) genera una tabla que referencia a la tabla de la relación agregada mediante una clave ajena compuesta (no a EMPLEADOS y PROYECTOS por separado), además de a MAQUINAS.

EMPLEADOS (emp_id, nombre, …)

PROYECTOS (proyecto_id, nombre, …)

MAQUINAS (maquina_id, descripcion)

PARTICIPACIONES (*emp_id*, *proyecto_id*, fecha_incorporacion, funcion (N))

emp_id → EMPLEADOS(emp_id)
proyecto_id → PROYECTOS(proyecto_id)

USOS (*emp_id*, *proyecto_id*, *maquina_id*, horas)

(emp_id, proyecto_id) → PARTICIPACIONES(emp_id, proyecto_id)
maquina_id → MAQUINAS(maquina_id)
CHECK: horas > 0

flowchart RL
    USOS -->|"(emp_id, proyecto_id)"| PARTICIPACIONES
    USOS -->|maquina_id| MAQUINAS
    PARTICIPACIONES -->|emp_id| EMPLEADOS
    PARTICIPACIONES -->|proyecto_id| PROYECTOS

El mismo esquema en diagrama de tablas (pata de gallo), donde la agregación ha desaparecido y PARTICIPACIONES aparece como entidad asociativa:

erDiagram
    EMPLEADOS ||--o{ PARTICIPACIONES : "trabaja"
    PROYECTOS ||--|{ PARTICIPACIONES : "tiene"
    PARTICIPACIONES ||--o{ USOS : "usa"
    MAQUINAS ||--o{ USOS : "se usa en"
    EMPLEADOS {
        NUMBER emp_id PK
        VARCHAR2 nombre
    }
    PROYECTOS {
        NUMBER proyecto_id PK
        VARCHAR2 nombre
    }
    MAQUINAS {
        NUMBER maquina_id PK
        VARCHAR2 descripcion
    }
    PARTICIPACIONES {
        NUMBER emp_id PK, FK
        NUMBER proyecto_id PK, FK
        DATE fecha_incorporacion
        VARCHAR2 funcion
    }
    USOS {
        NUMBER emp_id PK, FK
        NUMBER proyecto_id PK, FK
        NUMBER maquina_id PK, FK
        NUMBER horas
    }

⚠️ Importante: La clave ajena compuesta (emp_id, proyecto_id) → PARTICIPACIONES es la traducción relacional de la restricción de inclusión de la sección 5.3. Si se hubiera modelado como ternaria, USOS tendría dos claves ajenas separadas (emp_id → EMPLEADOS y proyecto_id → PROYECTOS), y la base de datos aceptaría usos de máquinas en participaciones inexistentes, como (Luis, P3).

13.2. Conexión con el esquema EMPRESA

La tabla PARTICIPACIONES es, en esencia, la tabla ASIGNACIONES del esquema EMPRESA del curso (ver ../recursos/empresa_crear.sql): clave primaria (emp_id, proyecto_id) y atributos de la relación (fecha_asignacion, horas, funcion). Si quisieras ampliar EMPRESA con la maquinaria, la nueva tabla de usos referenciaría a ASIGNACIONES con una clave ajena compuesta (emp_id, proyecto_id), exactamente como en el ejemplo.

13.3. Variantes que verás en el módulo 17

Situación	Resultado relacional (idea)
Relación externa con máxima 1 junto a C (la práctica es seguida por un profesor)	No hace falta tabla nueva: la clave de C se añade como columna (clave ajena) a la tabla de la relación agregada
Relación agregada 1:N (sección 7.2)	La relación agregada ya se habría absorbido en la tabla del lado N; la externa se apoya en esa tabla
Agregación de una ternaria 1:N:M (OPERACIÓN)	La tabla de la agregación tiene la clave que dictan sus máximas: OPERACIONES (cod_vuelo, fecha, matricula_avion, …), y TRIPULACIONES la referencia por (cod_vuelo, fecha)
Agregaciones anidadas (CALIFICACIÓN)	Cada nivel es una tabla cuya clave incluye la del nivel interior: REVISIONES referencia a CALIFICACIONES por (alumno_id, asignatura_id, convocatoria_id)

14. Restricciones semánticas asociadas

La agregación garantiza por sí misma algunas restricciones y deja otras para la documentación. Conviene revisarlas siempre:

Restricción	Ejemplo	¿Cómo se garantiza?
Inclusión de la relación externa en la agregada	Solo se usan máquinas en participaciones existentes	Por construcción (en el relacional, clave ajena compuesta)
Dependencia existencial	Si Eva deja el proyecto P1, ¿qué pasa con sus usos de maquinaria?	Decisión de diseño: borrarlos con la participación (cascada) o impedir el borrado mientras existan. Debe documentarse
Mínima mayor que 0 junto a la entidad externa	Toda operación tiene al menos 2 tripulantes	No la garantiza una clave ajena: requiere comprobación en la aplicación o mecanismos procedimentales (disparadores, que se estudian en el Curso de Oracle PL/SQL)
Coherencia entre la relación externa y los componentes	Nadie evalúa su propia participación; la fecha de uso de una máquina es posterior a la fecha de incorporación	Restricción textual
Inclusión respecto a otra relación	La excursión contratada debe ofrecerse en el viaje contratado; el piloto debe estar habilitado para el modelo de avión	Restricción textual (o modelado adicional)
Cardinalidad por valor de un atributo	Exactamente un comandante por operación	Restricción textual
Exclusividad entre relaciones externas	Una matrícula se convalida o se califica, pero no ambas	Restricción de exclusión (módulo 13)
Temporal	Solo se califica en la extraordinaria si no se aprobó la ordinaria	Restricción textual

Las que no garantiza la estructura se anotan con las convenciones del módulo 13: notas unidas con línea discontinua y restricciones entre relaciones con línea discontinua entre los rombos. Por ejemplo, si una matrícula puede convalidarse (con una resolución de convalidación) o calificarse, pero no ambas cosas:

flowchart LR
    classDef nota fill:#fff8dc,stroke:#999,stroke-dasharray: 3 3
    subgraph MATRICULA["MATRÍCULA (agregación)"]
        direction LR
        ALUMNO[ALUMNO] ---|"(0,n)"| se_matricula{"se matricula<br/>N:M"}
        se_matricula ---|"(1,n)"| ASIGNATURA[ASIGNATURA]
    end
    MATRICULA ---|"(0,n)"| se_califica{"se califica en<br/>N:M"}
    se_califica ---|"(0,2)"| CONVOCATORIA[CONVOCATORIA]
    se_califica --- c_nota([nota])
    MATRICULA ---|"(0,n)"| convalida{"se convalida por<br/>1:N"}
    convalida ---|"(0,1)"| RESOLUCION["RESOLUCIÓN DE CONVALIDACIÓN"]
    se_califica -.-|"exclusión"| convalida
    R1["R1: la nota está entre 0 y 10"]:::nota
    R1 -.- c_nota

Lectura de la exclusión: una misma ocurrencia de MATRÍCULA no puede participar a la vez en se califica en y en se convalida por.

💡 Consejo: Al terminar un diagrama con agregaciones, recorre cada relación externa y pregúntate: “¿qué pasa con esta ocurrencia si desaparece la ocurrencia de la relación agregada a la que se refiere?”. La respuesta (borrar, impedir, conservar como histórico) es una decisión del negocio que debes anotar; en el módulo 13 (Restricciones avanzadas) verás cómo documentar este tipo de reglas de forma sistemática.

15. Errores frecuentes

Error	Síntoma	Solución
Unir un rombo con otro rombo	Diagrama inválido en el modelo E/R	Agregar la relación interior (sección 1)
Unir la relación externa a una entidad de dentro en lugar de al recuadro	Las máquinas quedan asociadas al empleado, no a la participación	La arista debe tocar el borde de la agregación (sección 4.3)
Leer la cardinalidad junto a C como si se fijara una entidad de dentro	“Un empleado usa como mucho n máquinas”	Fijar una ocurrencia de la relación agregada: “un empleado, en un proyecto” (sección 5.2)
Usar una ternaria cuando el par existe por sí mismo	No se pueden registrar participaciones sin máquina; atributos repetidos	Agregación (sección 10.2)
Ternaria + binaria “para tener las dos cosas”	Redundancia e incoherencias (usos en participaciones inexistentes)	Agregación (sección 10.3)
Agregar una relación cuyos pares pueden repetirse	Matrículas de repetidores que “machacan” la anterior	Añadir un participante (CURSO ACADÉMICO) o convertir en entidad (secciones 2.4 y 11.3)
Confundir agregación E/R con agregación UML	Usar el recuadro para “es parte de”	La agregación E/R es una relación tratada como entidad (sección 3.6)
Confundir agregación con generalización	Recuadros alrededor de jerarquías	Hexágono “es un” para jerarquías; recuadro solo para relaciones (sección 12)
Inventar un identificador para la agregación	Atributo “id_participacion” dentro del recuadro	La agregación se identifica por sus participantes; si necesitas un código, es una entidad (sección 11.3)
Anidar agregaciones sin límite	Diagramas ilegibles con recuadros dentro de recuadros	A partir del tercer nivel, convertir en entidades (sección 9.2)
En el relacional, referenciar EMPLEADOS y PROYECTOS por separado desde USOS	La base de datos admite usos en participaciones inexistentes	Clave ajena compuesta a la tabla de la relación agregada (sección 13)
Olvidar qué pasa con la relación externa al borrar la agregada	Usos “huérfanos” o borrados inesperados	Documentar la dependencia existencial (sección 14)

16. Ejercicios

Ejercicio 1: ¿Qué estructura necesita cada requisito?

Para cada requisito, indica si lo modelarías con relaciones binarias, una ternaria, una agregación o una entidad, y justifícalo en una frase:

“Los socios de un gimnasio se inscriben en actividades. A cada inscripción se le puede asignar una taquilla.”
“Los proveedores suministran piezas a los proyectos; interesa la cantidad suministrada.”
“Un cliente contrata un viaje. Cada contratación puede incluir un seguro y varias excursiones opcionales.”
“Un empleado pertenece a un departamento y cada departamento está en una sede.”
“Un conductor alquila coches; puede alquilar el mismo coche muchas veces y cada alquiler genera una factura.”
“Un profesor dirige el trabajo de fin de ciclo de un alumno; cada dirección es evaluada por un tribunal de exactamente tres profesores.”

Ver solución

Nº	Estructura	Justificación
1	Agregación	La inscripción (socio, actividad) existe sin taquilla; la taquilla se asigna a la inscripción, no al socio ni a la actividad
2	Ternaria	Ningún par existe por sí solo; la cantidad depende del trío
3	Agregación con dos relaciones externas	El seguro y las excursiones son de la contratación; la contratación existe sin ellos
4	Dos binarias	Cadena de hechos independientes: empleado-departamento y departamento-sede
5	Entidad ALQUILER	El par (conductor, coche) se repite; además el alquiler genera facturas y tiene datos propios
6	Agregación DIRECCIÓN (PROFESOR dirige a ALUMNO) relacionada con PROFESOR (papel de miembro del tribunal) con cardinalidad (3,3) junto a PROFESOR	El tribunal evalúa la dirección; cardinalidad exacta 3. Restricción textual: el director no forma parte de su propio tribunal

Ejercicio 2: Conservatorio

“Los alumnos de un conservatorio estudian uno o varios instrumentos, y cada instrumento lo estudian varios alumnos. De cada estudio interesa el curso (de 1º a 6º) en que está el alumno en ese instrumento. A cada alumno, en cada instrumento, se le asigna un profesor, aunque al principio del año puede estar sin asignar. Un profesor da clase a muchos alumnos en uno o varios instrumentos.”

a) Dibuja el modelo con agregación. b) Demuestra con ocurrencias por qué una ternaria ALUMNO-INSTRUMENTO-PROFESOR no sirve. c) ¿Cambiaría tu respuesta si todo estudio tuviera profesor desde el primer día?

Ver solución

a) Modelo:

flowchart LR
    subgraph ESTUDIO["ESTUDIO (agregación)"]
        direction LR
        ALUMNO[ALUMNO] ---|"(0,n)"| estudia{"estudia<br/>N:M"}
        estudia ---|"(1,n)"| INSTRUMENTO[INSTRUMENTO]
        estudia --- es_curso([curso])
    end
    ESTUDIO ---|"(0,n)"| ensena{"es impartido por<br/>1:N"}
    ensena ---|"(0,1)"| PROFESOR[PROFESOR]

Lectura: cada alumno estudia de 1 a n instrumentos y cada instrumento lo estudian de 0 a n alumnos. Cada estudio (un alumno en un instrumento) tiene como mucho un profesor (0,1); cada profesor imparte de 0 a n estudios.

b) Ocurrencias reales al empezar el curso:

Alumno	Instrumento	curso	Profesor
Leo	Violín	3º	Elena
Leo	Piano	1º	(sin asignar)
Marina	Violín	5º	Elena

En una ternaria, la fila (Leo, Piano) no se puede guardar porque falta el profesor. Además, el curso depende del par (alumno, instrumento), no del profesor: si se cambia de profesor a Leo en Violín, el curso no cambia.

c) Si todo estudio tuviera profesor desde el principio (mínima 1 junto a PROFESOR), la ternaria sería de tipo 1:N:M con el 1 en PROFESOR: el par (alumno, instrumento) determina al profesor, la clave de la tabla sería (alumno, instrumento) y el curso dependería de esa clave sin repetirse. Ambas soluciones serían equivalentes en el relacional (sección 10.7). Aun así, la agregación expresa mejor que el estudio es el hecho principal y el profesor se le asigna.

Ejercicio 3: Cardinalidades con ocurrencias

Siguiendo con el gimnasio del ejercicio 1, las reglas son: “a cada inscripción se le puede asignar como mucho una taquilla; una misma taquilla puede asignarse a varias inscripciones (de actividades en horarios distintos)”. Estas son las ocurrencias actuales:

Inscripción (socio, actividad)	Taquilla asignada
(Rita, Pilates)	—
(Rita, Natación)	T12
(Tomás, Natación)	T13
(Uxía, Spinning)	T12

a) Escribe las cardinalidades de la relación externa y comprueba que las ocurrencias las cumplen. b) Indica si se aceptan estas inserciones en la relación externa: ((Rita, Pilates), T05); ((Rita, Natación), T20); ((Tomás, Pilates), T07).

Ver solución

a) Junto a TAQUILLA: para una inscripción, de 0 a 1 taquillas → (0,1). Junto a INSCRIPCIÓN: para una taquilla, de 0 a n inscripciones → (0,n).

Elemento fijado	Se relaciona con	Recuento
(Rita, Pilates)	—	0 (mínimo 0 junto a TAQUILLA)
(Rita, Natación)	T12	1 (máximo 1)
T12	(Rita, Natación), (Uxía, Spinning)	2 (máximo n junto a INSCRIPCIÓN)

flowchart LR
    subgraph INSCRIPCION["INSCRIPCIÓN (agregación)"]
        direction LR
        SOCIO[SOCIO] ---|"(0,n)"| se_inscribe{"se inscribe en<br/>N:M"}
        se_inscribe ---|"(1,n)"| ACTIVIDAD[ACTIVIDAD]
    end
    INSCRIPCION ---|"(0,n)"| tiene{"tiene asignada<br/>1:N"}
    tiene ---|"(0,1)"| TAQUILLA[TAQUILLA]

b) Inserciones:

Inserción	Resultado	Motivo
((Rita, Pilates), T05)	Aceptada	La inscripción existe y no tenía taquilla
((Rita, Natación), T20)	Rechazada	Esa inscripción ya tiene T12 y la máxima junto a TAQUILLA es 1
((Tomás, Pilates), T07)	Rechazada	(Tomás, Pilates) no es una ocurrencia de la agregación: Tomás no está inscrito en Pilates

Ejercicio 4: Agencia de viajes

“Los clientes contratan viajes del catálogo (un cliente puede contratar varios viajes y un viaje lo contratan muchos clientes; un cliente no contrata dos veces el mismo viaje). De cada contratación interesan la fecha y el número de plazas. Cada contratación puede incluir un seguro de viaje (de entre los tipos que ofrece la agencia) y una o varias excursiones opcionales, indicando cuántas personas van a cada excursión. Las excursiones que se pueden contratar dependen del viaje.”

Dibuja el diagrama completo, léelo y escribe las restricciones textuales.

Ver solución

flowchart LR
    subgraph CONTRATACION["CONTRATACIÓN (agregación)"]
        direction LR
        CLIENTE[CLIENTE] ---|"(0,n)"| contrata{"contrata<br/>N:M"}
        contrata ---|"(1,n)"| VIAJE[VIAJE]
        contrata --- co_fecha([fecha])
        contrata --- co_plazas([num_plazas])
    end
    CONTRATACION ---|"(0,n)"| incluye{"incluye<br/>1:N"}
    incluye ---|"(0,1)"| SEGURO["TIPO DE SEGURO"]
    CONTRATACION ---|"(0,n)"| reserva{"reserva<br/>N:M"}
    reserva ---|"(0,n)"| EXCURSION[EXCURSIÓN]
    reserva --- re_pers([num_personas])
    VIAJE ---|"(0,n)"| ofrece{"ofrece<br/>1:N"}
    ofrece ---|"(1,1)"| EXCURSION

Lectura:

Un cliente contrata de 1 a n viajes; un viaje lo contratan de 0 a n clientes.
Cada contratación incluye como mucho un tipo de seguro (0,1); cada tipo de seguro está incluido en 0 a n contrataciones.
Cada contratación reserva de 0 a n excursiones; cada excursión se reserva en 0 a n contrataciones, con el número de personas.
Cada excursión la ofrece exactamente un viaje (1,1); un viaje ofrece de 0 a n excursiones.

Fíjate en que VIAJE está dentro de la agregación y también participa, por sí mismo, en ofrece.

Restricciones textuales:

RS1: una contratación solo puede reservar excursiones ofrecidas por su viaje (inclusión entre reserva y ofrece).
RS2: el número de personas de cada excursión reservada no supera el número de plazas de la contratación.
RS3: num_plazas mayor que 0.

Ejercicio 5: Valoraciones útiles

“En una plataforma de streaming, cada usuario puede valorar cada película una sola vez (puntuación de 1 a 5, comentario opcional y fecha). Los demás usuarios pueden marcar una valoración como útil.”

Modela el requisito. ¿Qué restricción no puede expresar el diagrama?

Ver solución

flowchart LR
    subgraph VALORACION["VALORACIÓN (agregación)"]
        direction LR
        USUARIO[USUARIO] ---|"(0,n)"| valora{"valora<br/>N:M"}
        valora ---|"(0,n)"| PELICULA[PELÍCULA]
        valora --- v_punt([puntuacion])
        valora --- v_com(["comentario (0,1)"])
        valora --- v_fecha([fecha])
    end
    VALORACION ---|"(0,n)"| marca{"marca como útil<br/>N:M"}
    marca ---|"(0,n)"| USUARIO

Lectura: cada valoración (un usuario sobre una película) puede ser marcada como útil por 0 a n usuarios; cada usuario marca como útiles de 0 a n valoraciones. USUARIO aparece dentro de la agregación (como autor) y fuera (como quien marca): son papeles distintos de la misma entidad.

Restricciones que el diagrama no expresa:

RS1: un usuario no puede marcar como útil su propia valoración.
RS2: la puntuación es un entero entre 1 y 5.

Ejercicio 6: De agregación a entidad

Transforma la agregación CONTRATACIÓN del ejercicio 4 en: a) una entidad débil; b) una entidad con identificador propio (un localizador). Indica en cada caso cómo quedan las cardinalidades y qué restricción hay que añadir.

Ver solución

a) Entidad débil identificada por CLIENTE y VIAJE:

flowchart LR
    classDef debil stroke-width:4px
    CLIENTE[CLIENTE] ---|"(1,1)"| de_cli{"de<br/>ID"}:::debil
    de_cli ---|"(1,n)"| CONTRATACION[CONTRATACIÓN]:::debil
    VIAJE[VIAJE] ---|"(1,1)"| de_via{"sobre<br/>ID"}:::debil
    de_via ---|"(0,n)"| CONTRATACION
    CONTRATACION ---|"(0,n)"| incluye{"incluye<br/>1:N"}
    incluye ---|"(0,1)"| SEGURO["TIPO DE SEGURO"]
    CONTRATACION ---|"(0,n)"| reserva{"reserva<br/>N:M"}
    reserva ---|"(0,n)"| EXCURSION[EXCURSIÓN]

Las cardinalidades de contrata se trasladan así: “un cliente contrata de 1 a n viajes” pasa a ser “un cliente tiene de 1 a n contrataciones” (1,n) junto a CONTRATACIÓN en de; “un viaje lo contratan de 0 a n clientes” pasa a “un viaje tiene de 0 a n contrataciones” (0,n) junto a CONTRATACIÓN en sobre. Junto a CLIENTE y VIAJE, (1,1). La unicidad del par es implícita, porque la entidad débil se identifica solo por sus dos propietarios.

b) Entidad fuerte CONTRATACIÓN con identificador localizador, unida a CLIENTE y VIAJE por relaciones normales con las mismas cardinalidades. Hay que añadir:

RS: no hay dos contrataciones del mismo cliente para el mismo viaje.

(Si la agencia permitiera que un cliente contrate el mismo viaje dos veces, por ejemplo en fechas de salida distintas, se omitiría esta restricción y la opción b) sería la única válida.)

Ejercicio 7: Adelanto de la transformación

Escribe el esquema relacional (notación del curso) de los ejercicios 2 y 5, siguiendo la idea de la sección 13.

Ver solución

Conservatorio (ejercicio 2). La relación externa tiene máxima 1 junto a PROFESOR, así que no genera tabla: el profesor se añade como columna a la tabla de la relación agregada.

ALUMNOS (alumno_id, nombre, …)

INSTRUMENTOS (instrumento_id, nombre)

PROFESORES (profesor_id, nombre, …)

ESTUDIOS (*alumno_id*, *instrumento_id*, curso, profesor_id (N))

alumno_id → ALUMNOS(alumno_id)
instrumento_id → INSTRUMENTOS(instrumento_id)
profesor_id → PROFESORES(profesor_id)
CHECK: curso BETWEEN 1 AND 6

Valoraciones (ejercicio 5). La relación externa es N:M y referencia a la tabla de la agregación con una clave ajena compuesta. Como USUARIO aparece con dos papeles, renombramos las columnas:

USUARIOS (usuario_id, nombre, …)

PELICULAS (pelicula_id, titulo, …)

VALORACIONES (*autor_id*, *pelicula_id*, puntuacion, comentario (N), fecha)

autor_id → USUARIOS(usuario_id)
pelicula_id → PELICULAS(pelicula_id)
CHECK: puntuacion BETWEEN 1 AND 5

MARCAS_UTIL (*usuario_id*, *autor_id*, *pelicula_id*)

usuario_id → USUARIOS(usuario_id)
(autor_id, pelicula_id) → VALORACIONES(autor_id, pelicula_id)
CHECK: usuario_id <> autor_id

Observa que la restricción RS1 del ejercicio 5 (no marcar la propia valoración) se puede implementar aquí con un simple CHECK, porque las dos columnas están en la misma fila.

Ejercicio 8: Agregación anidada

“Los investigadores participan en proyectos con un porcentaje de dedicación. Cada participación puede estar financiada por uno o varios organismos (ministerio, comunidad autónoma, empresa…), con un importe por organismo. Cada financiación concreta puede ser auditada por un auditor, que emite un informe con fecha y resultado.”

a) Dibuja el modelo. b) ¿Cómo se identifica una ocurrencia de la agregación exterior? c) Si además las auditorías tuvieran incidencias que hay que relacionar con normas incumplidas, ¿qué harías?

Ver solución

flowchart LR
    subgraph FINANCIACION["FINANCIACIÓN (agregación)"]
        direction LR
        subgraph PARTICIPACION["PARTICIPACIÓN (agregación)"]
            direction LR
            INVESTIGADOR[INVESTIGADOR] ---|"(1,n)"| participa{"participa en<br/>N:M"}
            participa ---|"(0,n)"| PROYECTO[PROYECTO]
            participa --- pa_ded([dedicacion])
        end
        PARTICIPACION ---|"(0,n)"| financia{"es financiada por<br/>N:M"}
        financia ---|"(0,n)"| ORGANISMO[ORGANISMO]
        financia --- fi_imp([importe])
    end
    FINANCIACION ---|"(0,n)"| audita{"es auditada por<br/>1:N"}
    audita ---|"(0,1)"| AUDITOR[AUDITOR]
    audita --- au_fecha([fecha_informe])
    audita --- au_res([resultado])

Lectura: cada participación es financiada por 0 a n organismos y cada organismo financia de 0 a n participaciones; cada financiación es auditada por como mucho un auditor y cada auditor audita de 0 a n financiaciones.

b) Una ocurrencia de FINANCIACIÓN es ((investigador, proyecto), organismo): se identifica por los identificadores de las tres entidades que contiene.

c) Sería un tercer nivel de agregación (AUDITORÍA relacionada con NORMA). Es el momento de convertir al menos la auditoría en una entidad (con identificador propio, por ejemplo un número de informe), relacionada con la financiación auditada, con el auditor y con las normas incumplidas (sección 9.2).

Ejercicio 9: ¿Agregación o ternaria?

Decide la estructura para cada caso y justifícalo con ocurrencias:

“Los músicos pertenecen a grupos (un músico puede estar en varios grupos). En cada grupo, el músico toca uno o varios instrumentos; los vocalistas no tocan ninguno.”
“En un festival, cada grupo actúa en uno o varios conciertos (escenario y día), con una hora de inicio. En cada actuación interpreta un repertorio de canciones en un orden.”
“Una discográfica registra qué músico toca qué instrumento en qué canción grabada. Un músico puede tocar varios instrumentos en una canción y el mismo instrumento en muchas canciones; en una canción, un instrumento lo pueden tocar varios músicos.”

Ver solución

Agregación PERTENENCIA (MÚSICO pertenece a GRUPO) toca INSTRUMENTO (0,n). Ocurrencias: (Carla, Los Robles) toca guitarra y armónica; (Pau, Los Robles) es vocalista y no toca nada. Con una ternaria MÚSICO-GRUPO-INSTRUMENTO, la pertenencia de Pau no podría registrarse.
Agregación ACTUACIÓN (GRUPO actúa en CONCIERTO, con hora_inicio) interpreta CANCIÓN (con el atributo orden). Ocurrencias: (Los Robles, Escenario Norte 12/07) interpreta “Río” (orden 1) y “Sal” (orden 2). La actuación existe y tiene hora aunque el repertorio no esté decidido, y la hora no depende de la canción. Una ternaria GRUPO-CONCIERTO-CANCIÓN repetiría la hora de inicio en cada canción y no permitiría registrar la actuación antes de fijar el repertorio.
Ternaria N:M:P MÚSICO-INSTRUMENTO-CANCIÓN. El par (músico, instrumento) no es un hecho del negocio para la discográfica (no guarda “qué instrumentos sabe tocar cada músico”), ni (músico, canción) ni (instrumento, canción) existen sin el tercero. Ocurrencias: (Carla, guitarra, “Río”), (Carla, armónica, “Río”), (Pau, guitarra, “Río”), (Carla, guitarra, “Sal”): ningún par determina al tercero.

Fíjate en que los casos 1 y 2 parecían ternarias a primera vista: la clave fue preguntarse si el par existe por sí mismo.

Ejercicio 10: Encuentra los errores

Un compañero presenta cuatro decisiones de diseño. Explica qué está mal en cada una y cómo corregirla:

Para el ejemplo de las matrículas (sección 6.2), une la relación se califica en directamente a la entidad ASIGNATURA que está dentro del recuadro MATRÍCULA.
En un sistema que guarda todo el historial académico (con repetidores), agrega la relación binaria ALUMNO se matricula de ASIGNATURA.
Para indicar que INGENIERO y OPERARIO son tipos de EMPLEADO, dibuja un recuadro “agregación” que encierra las tres entidades.
En el relacional de la sección 13, define USOS con emp_id → EMPLEADOS(emp_id) y proyecto_id → PROYECTOS(proyecto_id).

Ver solución

La arista debe tocar el recuadro, no la entidad interior. Tal como está, el diagrama dice que las convocatorias califican asignaturas, no matrículas: la nota sería de la asignatura, igual para todos los alumnos.
Con historial, el par (alumno, asignatura) se repite en cursos distintos, y una relación no admite pares repetidos (sección 2.4). Hay que agregar una ternaria ALUMNO-ASIGNATURA-CURSO ACADÉMICO o convertir la matrícula en entidad.
Es una generalización, no una agregación: se dibuja con el hexágono “es un” y su cobertura (módulo 11). El recuadro solo se usa para tratar una relación como entidad.
Con dos claves ajenas separadas, la base de datos admite usos de máquinas en participaciones que no existen (por ejemplo, Luis en P3). Debe haber una clave ajena compuesta (emp_id, proyecto_id) → PARTICIPACIONES(emp_id, proyecto_id).

Ejercicios propuestos

✏️ Ejercicio: En un hospital, un cirujano opera a un paciente en un quirófano en una fecha (como mucho una operación por paciente y día). En cada intervención participan varios enfermeros con una función y se consume material quirúrgico (con cantidades). Modela el requisito con agregación, calcula todas las cardinalidades y escribe las restricciones textuales.

✏️ Ejercicio: En una liga, cada jugador pertenece a un equipo en cada temporada (ternaria del módulo 09, sección 5.3). Cada ficha (jugador, equipo, temporada) puede tener un patrocinador personal con un importe. Dibuja la agregación de la ternaria y explica cómo se identifica cada ocurrencia de la agregación teniendo en cuenta sus cardinalidades.

✏️ Ejercicio: En una biblioteca, los socios reservan libros (títulos, no ejemplares). Cuando hay un ejemplar disponible, la reserva se satisface con un ejemplar concreto. Modela el requisito con agregación y, después, con una entidad RESERVA con identificador propio. Compara ambos diagramas.

✏️ Ejercicio: Para la relación 1:1 EMPLEADO dirige DEPARTAMENTO, escribe tres requisitos distintos sobre una secretaria asignada que obliguen a relacionarla, respectivamente, con EMPLEADO, con DEPARTAMENTO y con la agregación DIRECCIÓN. Justifica cada uno con lo que ocurre cuando cambia el director.

✏️ Ejercicio: Dibuja las tres alternativas de Elmasri y Navathe para el ejemplo de entrevistas y ofertas de la sección 10 (ternaria, agregación y entidad débil ENTREVISTA). Para cada una, indica qué ocurrencias de la tabla de la sección 10.2 se pueden registrar y cuáles no.

✏️ Ejercicio: En un taller mecánico, cada vehículo pasa revisiones (como mucho una al día). En cada revisión intervienen uno o varios mecánicos y, por cada mecánico que interviene, se anotan las tareas realizadas (de un catálogo) y el tiempo empleado en cada una. Decide si necesitas agregaciones anidadas o entidades, y dibuja tu solución.

✏️ Ejercicio: Explica, con un ejemplo propio, la diferencia entre la agregación del modelo E/R, la agregación UML y la composición UML. Para cada una, indica cómo la representarías en la notación del curso.

✏️ Ejercicio: Amplía el esquema EMPRESA del curso (../recursos/empresa_crear.sql) con una tabla MAQUINAS y una tabla de usos de maquinaria por asignación. Escribe el esquema relacional de las dos tablas nuevas con la notación del curso, indicando la clave ajena compuesta hacia ASIGNACIONES y decidiendo, de forma razonada, qué debe ocurrir con los usos al borrar una asignación.

Resumen

Concepto	Idea clave
Limitación del E/R básico	Una relación solo asocia entidades: no se puede unir un rombo con otro rombo
Agregación	Abstracción que trata una relación y sus entidades como una entidad de nivel superior que puede participar en otras relaciones
Origen	Smith y Smith (1977), junto con la generalización; incorporada al modelo E/R extendido
Ocurrencias	Las de la relación agregada; se identifican por los identificadores de sus participantes
Condición de uso	Cada combinación de participantes aparece como mucho una vez; si se repite, entidad
Notación del curso	Recuadro (`subgraph`) que encierra la relación, sus entidades y sus atributos; las relaciones externas tocan el borde
UML	El equivalente es la clase asociación; agregación y composición UML son relaciones todo-parte, otra cosa
Cardinalidad junto a C	Para una ocurrencia de la relación agregada (un par concreto), ¿cuántas C?
Cardinalidad junto a la agregación	Para una C, ¿cuántas ocurrencias de la relación agregada?
Inclusión	La relación externa solo puede referirse a ocurrencias existentes: garantizada por construcción
N:M, 1:N, 1:1	N:M: imprescindible; 1:N: casi equivale a la entidad del lado N; 1:1: el hecho es del par y caduca si cambia
Ternarias agregadas	Cada ocurrencia es un trío; útil para consultas, vuelos operados, imparticiones
Anidadas	Posibles; a partir del tercer nivel, mejor entidades
Agregación vs ternaria	Si el par existe sin C, o tiene atributos propios, o C debe referirse a pares existentes: agregación
Agregación vs entidad débil	Equivalentes; la entidad es obligatoria si el par se repite o con pata de gallo
Agregación vs generalización	“Relación como objeto” frente a “es un”: abstracciones distintas
Relacional	Tabla de la relación agregada con clave compuesta; la externa la referencia con clave ajena compuesta
Restricciones	Dependencia existencial, mínimas mayores que 0, coherencia con los componentes, exclusividad: documentarlas

Navegación
← Módulo anterior: Generalización y especialización	Siguiente módulo: Restricciones avanzadas →