Módulo 15: Generalización y especialización

Objetivos del módulo

  • Comprender por qué el modelo E/R básico se queda corto y qué aporta el modelo E/R extendido (EER, Enhanced/Extended Entity-Relationship)
  • Definir con rigor superclase (supertipo) y subclase (subtipo) y la relación ES-UN (IS-A)
  • Distinguir los procesos de especialización (descendente) y generalización (ascendente)
  • Aplicar correctamente la herencia de atributos, identificador y relaciones, y modelar atributos y relaciones propios de cada subtipo
  • Dominar las restricciones de cobertura: total/parcial y exclusiva/solapada, con los cuatro casos posibles
  • Usar el atributo discriminante y diferenciar la especialización definida por atributo de la definida por el usuario
  • Modelar jerarquías de varios niveles y retículas con herencia múltiple
  • Modelar categorías o tipos unión y saber distinguirlas de una generalización
  • Conocer el concepto de agregación y de composición (que se desarrollan en el módulo de agregación)
  • Evitar los errores frecuentes, sobre todo el de crear jerarquías donde basta un atributo

1. Motivación: por qué extender el modelo E/R

El modelo Entidad/Relación que propuso Peter Chen en 1976 (entidades, atributos y relaciones) es suficiente para muchos problemas, pero tiene una carencia importante: no permite expresar que unas entidades son casos particulares de otras. En el mundo real esto ocurre constantemente:

  • Un alumno y un profesor son, ambos, personas de la universidad.
  • Un turismo, una furgoneta y una moto son vehículos de una empresa de alquiler.
  • Una cuenta corriente y una cuenta de ahorro son cuentas bancarias.
  • Una película y una serie son contenidos de una plataforma de streaming.

En 1977, John y Diane Smith describieron dos abstracciones fundamentales del modelado de datos: la generalización (ver varios tipos de objetos como un tipo más general) y la agregación (ver un conjunto de objetos relacionados como un objeto de nivel superior). Estas ideas, junto con la de categoría (tipo unión), se incorporaron al modelo E/R y dieron lugar al modelo E/R extendido (EER), tal y como lo presentan Elmasri y Navathe, o de Miguel y Piattini en la tradición española.

📘 Concepto: El modelo E/R extendido (EER) añade al modelo E/R básico los conceptos de subclase/superclase, especialización/generalización, herencia, categoría (tipo unión) y agregación, junto con las restricciones asociadas (cobertura, disjunción). Su objetivo es representar con más precisión la semántica del mundo real sin tener que recurrir a notas en lenguaje natural.

1.1. Qué pasa si no usamos jerarquías

Imagina que tenemos que modelar el personal de una universidad. Hay alumnos (con número de expediente y nota media) y profesores (con categoría y despacho). Todos tienen DNI, nombre, apellidos y email. Sin el modelo extendido, tenemos dos alternativas, y ambas son malas.

Alternativa A: una única entidad con todos los atributos.

flowchart LR
    PERSONA[PERSONA] --- a_dni([<u>dni</u>])
    PERSONA --- a_nom([nombre])
    PERSONA --- a_ema([email])
    PERSONA --- a_tipo([tipo])
    PERSONA --- a_exp(["num_expediente (0,1)"])
    PERSONA --- a_nota(["nota_media (0,1)"])
    PERSONA --- a_cat(["categoria (0,1)"])
    PERSONA --- a_desp(["despacho (0,1)"])

Problemas:

  • Muchos atributos opcionales que en realidad son obligatorios para una parte de las ocurrencias: num_expediente es obligatorio para los alumnos, pero el diagrama solo dice “(0,1)”. Se pierde semántica.
  • Si los profesores imparten asignaturas, la relación imparte quedaría unida a PERSONA, y el diagrama permitiría que un alumno impartiera asignaturas.
  • Hay que añadir restricciones en lenguaje natural del tipo “si tipo = ‘ALUMNO’ entonces num_expediente no es nulo y categoria es nula”, que el diagrama no muestra.

Alternativa B: dos entidades independientes.

flowchart LR
    ALUMNO[ALUMNO] --- b_dni([<u>dni</u>])
    ALUMNO --- b_nom([nombre])
    ALUMNO --- b_exp([num_expediente])
    PROFESOR[PROFESOR] --- c_dni([<u>dni</u>])
    PROFESOR --- c_nom([nombre])
    PROFESOR --- c_cat([categoria])

Problemas:

  • Los atributos comunes (dni, nombre, email…) se repiten.
  • Si una persona es a la vez alumno y profesor (un profesor que cursa un máster), aparece dos veces y sus datos pueden ser inconsistentes (dos emails distintos para el mismo DNI).
  • Las relaciones comunes (por ejemplo, “toda persona tiene una tarjeta universitaria”) hay que duplicarlas.
  • El diagrama no expresa que ambos son “personas”: se pierde la abstracción.

La solución EER: una jerarquía.

flowchart TB
    PERSONA[PERSONA] --- d_dni([<u>dni</u>])
    PERSONA --- d_nom([nombre])
    PERSONA --- d_ema([email])
    PERSONA --- j1{{"es un<br/>(parcial, solapada)"}}
    j1 --- ALUMNO[ALUMNO]
    j1 --- PROFESOR[PROFESOR]
    ALUMNO --- d_exp([num_expediente])
    ALUMNO --- d_nota([nota_media])
    PROFESOR --- d_cat([categoria])
    PROFESOR --- d_desp([despacho])

Ahora cada atributo está donde le corresponde, los obligatorios son obligatorios dentro de su subtipo, una persona aparece una sola vez aunque sea alumno y profesor, y cualquier relación se puede unir exactamente al nivel adecuado.

2. Superclases y subclases

2.1. Definiciones

📘 Concepto: Una subclase (o subtipo, subclass) S de una entidad C es un subconjunto de las ocurrencias de C que tiene interés por sí mismo, porque posee atributos o relaciones propios o restricciones distintas. C es la superclase (o supertipo, superclass). Formalmente, en todo momento se cumple S ⊆ C: toda ocurrencia de la subclase es también una ocurrencia de la superclase.

La relación entre una subclase y su superclase se llama relación ES-UN (IS-A): “un alumno es una persona”, “un turismo es un vehículo”. Fíjate en que:

  • No es una relación normal entre dos entidades distintas: una ocurrencia de ALUMNO y la ocurrencia de PERSONA correspondiente son el mismo objeto del mundo real, visto con distinto nivel de detalle. Por eso la relación ES-UN no tiene cardinalidades que elegir: siempre es “una ocurrencia del subtipo corresponde exactamente a una ocurrencia del supertipo, y una ocurrencia del supertipo corresponde como mucho a una ocurrencia de cada subtipo”.
  • La subclase no tiene identificador propio: hereda el de la superclase. Un alumno se identifica por su DNI, igual que la persona que es.
  • Una ocurrencia puede pertenecer a la superclase sin pertenecer a ninguna subclase (si la cobertura es parcial) o a varias subclases a la vez (si es solapada). Lo estudiaremos en la sección 5.

💡 Consejo: Una buena prueba para detectar una relación ES-UN es leerla en voz alta: “todo X es un Y”. Si la frase es verdadera siempre y para todas las ocurrencias de X, probablemente X es subtipo de Y. “Todo turismo es un vehículo” es cierto; “todo conductor es un vehículo” es absurdo: CONDUCTOR y VEHICULO se unen con una relación normal (conduce).

2.2. Notación del curso

En la notación de Chen extendida que usa este curso, la jerarquía se dibuja con un hexágono con el texto “es un” y, debajo, la cobertura entre paréntesis. El supertipo se une al hexágono, y del hexágono salen las líneas hacia los subtipos.

flowchart TB
    VEHICULO[VEHICULO] --- v_mat([<u>matricula</u>])
    VEHICULO --- v_marca([marca])
    VEHICULO --- v_modelo([modelo])
    VEHICULO --- jv{{"es un<br/>(total, exclusiva)"}}
    jv --- TURISMO[TURISMO]
    jv --- FURGONETA[FURGONETA]
    jv --- MOTO[MOTO]
    TURISMO --- t_plazas([num_plazas])
    FURGONETA --- f_carga([carga_max_kg])
    MOTO --- m_cc([cilindrada])
Elemento Representación en Mermaid Significado
Supertipo VEHICULO[VEHICULO] Entidad general, con el identificador y los atributos comunes
Hexágono jv{{"es un<br/>(total, exclusiva)"}} Jerarquía ES-UN y su cobertura
Subtipos TURISMO[TURISMO] unidos al hexágono Subconjuntos del supertipo con atributos o relaciones propios
Abreviaturas (t,e), (t,s), (p,e), (p,s) total/parcial, exclusiva/solapada

⚠️ Importante: En el diagrama, los subtipos no llevan identificador (ni subrayado, ni repetido). Si dibujas matricula también en TURISMO, es un error: el identificador se hereda.

2.3. Otras notaciones que encontrarás

Cada libro y cada herramienta dibuja las jerarquías de una forma. Conviene reconocerlas todas:

Notación Cómo dibuja la jerarquía Cobertura total Exclusiva / solapada
Chen extendida (de Miguel y Piattini, este curso) Triángulo o hexágono “es un” Texto (total) o (t) Texto (exclusiva/solapada) o (e)/(s)
Elmasri y Navathe (EER) Círculo unido al supertipo; símbolo ⊂ en las líneas hacia los subtipos Doble línea entre supertipo y círculo d (disjoint) u o (overlapping) dentro del círculo
UML (diagrama de clases) Flecha con punta triangular hueca del subtipo al supertipo {complete} {disjoint} / {overlapping}
Barker (Oracle) Subtipos dibujados dentro de la caja del supertipo Implícita (los subtipos cubren el supertipo) Siempre exclusiva
Pata de gallo / IE Varía según herramienta; a menudo un semicírculo con una línea Doble línea Una X o una letra

3. Especialización y generalización

Las jerarquías pueden descubrirse siguiendo dos caminos opuestos. El resultado en el diagrama es el mismo; lo que cambia es el proceso mental por el que llegas a él.

3.1. Especialización (descendente)

📘 Concepto: La especialización (specialization) es el proceso descendente (top-down) de definir un conjunto de subclases a partir de una entidad ya existente, en función de alguna característica que distingue a sus ocurrencias.

Partes de una entidad y te das cuenta de que algunas de sus ocurrencias tienen propiedades particulares. Por ejemplo, en una empresa tienes EMPLEADO y descubres en las entrevistas con el cliente que:

  • “Los comerciales tienen una zona de ventas asignada y cobran comisión.”
  • “Los técnicos tienen una especialidad y unas certificaciones.”
  • “Los administrativos no tienen datos adicionales.”
flowchart TB
    EMPLEADO[EMPLEADO] --- e_id([<u>num_empleado</u>])
    EMPLEADO --- e_nom([nombre])
    EMPLEADO --- e_sal([salario])
    EMPLEADO --- je{{"es un<br/>(parcial, exclusiva)"}}
    je --- COMERCIAL[COMERCIAL]
    je --- TECNICO[TECNICO]
    COMERCIAL --- c_com([porcentaje_comision])
    COMERCIAL ---|"(0,n)"| asignado{"asignado<br/>1:N"}
    asignado ---|"(1,1)"| ZONA[ZONA]
    TECNICO --- t_esp([especialidad])
    TECNICO --- t_cert(((certificacion)))

Fíjate en que ADMINISTRATIVO no aparece como subtipo: no tiene atributos ni relaciones propios, así que no aporta nada. Por eso la cobertura es parcial: hay empleados (los administrativos) que no pertenecen a ningún subtipo.

3.2. Generalización (ascendente)

📘 Concepto: La generalización (generalization) es el proceso ascendente (bottom-up) de identificar características comunes a varias entidades y crear con ellas una superclase que las agrupe.

Ahora partes de varias entidades que has identificado por separado y te das cuenta de que comparten atributos y relaciones. Por ejemplo, en una plataforma de vídeo has modelado PELICULA (título, año, duración, director) y SERIE (título, año, número de temporadas). Ambas tienen título, año y géneros, y ambas pueden ser valoradas por los usuarios. Generalizas creando CONTENIDO:

flowchart TB
    CONTENIDO[CONTENIDO] --- co_id([<u>cod_contenido</u>])
    CONTENIDO --- co_tit([titulo])
    CONTENIDO --- co_anio([anio])
    CONTENIDO ---|"(0,n)"| valora{"valora<br/>N:M"}
    valora ---|"(0,n)"| USUARIO[USUARIO]
    CONTENIDO --- jc{{"es un<br/>(total, exclusiva)"}}
    jc --- PELICULA[PELICULA]
    jc --- SERIE[SERIE]
    PELICULA --- pe_dur([duracion_min])
    SERIE --- se_ntemp([num_temporadas]):::derivado
    classDef derivado stroke-dasharray: 5 5

La relación valora, que antes habría que duplicar (valora_pelicula, valora_serie), ahora se define una sola vez sobre el supertipo.

⚠️ Importante: Al generalizar a menudo hay que inventar un identificador común. Si PELICULA se identificaba por un código P-0001 y SERIE por S-0001, los dos identificadores pueden colisionar o tener formatos distintos. El supertipo necesita un identificador válido para todas sus ocurrencias (aquí, cod_contenido).

3.3. Comparación

Aspecto Especialización Generalización
Dirección Descendente (top-down) Ascendente (bottom-up)
Punto de partida Una entidad general Varias entidades parecidas
Pregunta que te haces “¿Hay ocurrencias con propiedades particulares?” “¿Estas entidades tienen algo en común?”
Riesgo típico Crear subtipos innecesarios (sin propiedades propias) Forzar un supertipo entre entidades que solo se parecen por casualidad
Cobertura más habitual Parcial (no todas las ocurrencias se especializan) Total (el supertipo surge precisamente de los subtipos)
Resultado en el diagrama El mismo: supertipo + hexágono + subtipos El mismo

💡 Consejo: En la práctica de un examen o un proyecto mezclarás los dos procesos. Lo importante es que el diagrama final sea correcto, no por qué camino hayas llegado. Pero si te acostumbras a hacerte las dos preguntas al revisar tu diagrama, encontrarás jerarquías que se te habían escapado y eliminarás las que sobran.

4. Herencia de atributos y relaciones

4.1. Qué se hereda

📘 Concepto: Herencia (inheritance): cada subtipo hereda todos los atributos (incluido el identificador) y todas las relaciones de su supertipo. Además puede tener atributos y relaciones propios, que solo existen para sus ocurrencias.

Elemento del supertipo ¿Lo hereda el subtipo? Comentario
Identificador Sí El subtipo no define otro identificador principal
Atributos simples, compuestos, multivaluados, derivados Sí Con las mismas restricciones (obligatoriedad, dominio)
Relaciones en las que participa Sí Con las mismas cardinalidades
Restricciones semánticas Sí Una regla sobre todos los empleados afecta también a los comerciales
Subtipos de otros niveles No aplica Un subtipo puede tener sus propios subtipos (sección 7)

El subtipo puede añadir atributos y relaciones, pero no quitar ninguno de los heredados. Si un atributo del supertipo no tiene sentido para alguno de los subtipos, está mal colocado: debe bajar a los subtipos donde sí tiene sentido.

💻 Ejemplo: Si VEHICULO tiene el atributo num_puertas, MOTO lo hereda… y una moto no tiene puertas. La solución no es dejarlo “a nulo en las motos”, sino bajarlo a TURISMO y FURGONETA. Si además fuera común a ellos dos, podrías plantearte un nivel intermedio (VEHICULO_CERRADO), aunque normalmente no compensa por un solo atributo.

4.2. Atributos propios de los subtipos

Los atributos propios se dibujan unidos al subtipo. Pueden ser de cualquier clase: obligatorios, opcionales, multivaluados, compuestos o derivados. Lo que nunca puede haber en un subtipo es un segundo identificador principal; sí puede haber, en cambio, una clave alternativa propia del subtipo (por ejemplo, el num_expediente de un alumno, que es único entre los alumnos), que se marca con (AK) como cualquier clave alternativa.

flowchart TB
    PERSONA[PERSONA] --- p_dni([<u>dni</u>])
    PERSONA --- p_nom([nombre])
    PERSONA --- jp{{"es un<br/>(parcial, solapada)"}}
    jp --- ALUMNO[ALUMNO]
    jp --- PROFESOR[PROFESOR]
    ALUMNO --- al_exp(["num_expediente (AK)"])
    ALUMNO --- al_ing([anio_ingreso])
    PROFESOR --- pr_cat([categoria])
    PROFESOR --- pr_tel(((telefono_despacho)))

4.3. Relaciones propias de los subtipos

Este es uno de los motivos más importantes para crear una jerarquía: hay relaciones en las que solo participa una parte de las ocurrencias. Cada relación se une al nivel exacto de la jerarquía donde tiene sentido:

flowchart TB
    PERSONA[PERSONA] --- p_dni([<u>dni</u>])
    PERSONA ---|"(1,1)"| tiene{"tiene<br/>1:1"}
    tiene ---|"(0,1)"| TARJETA[TARJETA_UNIVERSITARIA]
    PERSONA --- jp{{"es un<br/>(parcial, solapada)"}}
    jp --- ALUMNO[ALUMNO]
    jp --- PROFESOR[PROFESOR]
    ALUMNO ---|"(0,n)"| matricula{"matricula<br/>N:M"}
    matricula ---|"(1,n)"| ASIGNATURA[ASIGNATURA]
    PROFESOR ---|"(1,1)"| imparte{"imparte<br/>1:N"}
    imparte ---|"(0,n)"| ASIGNATURA
    PROFESOR ---|"(0,n)"| adscrito{"adscrito<br/>1:N"}
    adscrito ---|"(1,1)"| DEPARTAMENTO[DEPARTAMENTO]

Lectura del diagrama (recuerda la convención: la pareja escrita junto a una entidad indica con cuántas ocurrencias de esa entidad se relaciona una ocurrencia de la otra):

  • Toda persona (alumno, profesor o ninguna de las dos cosas) puede tener una tarjeta universitaria: la relación tiene está en el supertipo.
  • Solo los alumnos se matriculan: un alumno se matricula en 1 a n asignaturas; una asignatura tiene de 0 a n alumnos matriculados.
  • Solo los profesores imparten: cada asignatura la imparte exactamente un profesor (1,1); un profesor imparte de 0 a n asignaturas.
  • Solo los profesores están adscritos a un departamento, y lo están obligatoriamente a uno (1,1).

⚠️ Importante: Si adscrito se uniera a PERSONA, el diagrama obligaría a los alumnos a estar adscritos a un departamento (cardinalidad mínima 1). Colocar una relación en el nivel incorrecto cambia las cardinalidades efectivas y es un error grave.

4.4. Relaciones entre subtipos y con el propio supertipo

Un subtipo puede relacionarse con otro subtipo de la misma jerarquía, o con el supertipo. Por ejemplo, en un hospital, el MEDICO supervisa a los MIR (médicos internos residentes), y ambos son subtipos de PERSONAL:

flowchart TB
    PERSONAL[PERSONAL] --- pe_id([<u>num_colegiado</u>])
    PERSONAL --- jh{{"es un<br/>(total, exclusiva)"}}
    jh --- MEDICO[MEDICO]
    jh --- MIR[MIR]
    jh --- ENFERMERO[ENFERMERO]
    MEDICO ---|"(1,1) tutor"| tutela{"tutela<br/>1:N"}
    tutela ---|"(0,n) residente"| MIR

💡 Consejo: Cuando una relación une dos subtipos, comprueba si en realidad no debería subir al supertipo. Pregunta: “¿puede un enfermero tutelar a un MIR?”. Si la respuesta es no, la relación entre subtipos es correcta y aporta semántica que se perdería en el supertipo.

5. Restricciones de cobertura

Una jerarquía no queda completamente definida hasta que respondes a dos preguntas sobre sus ocurrencias:

  1. ¿Toda ocurrencia del supertipo pertenece a algún subtipo? → restricción de totalidad (o completitud).
  2. ¿Puede una ocurrencia del supertipo pertenecer a más de un subtipo a la vez? → restricción de disyunción (o exclusividad).

5.1. Total o parcial (restricción de completitud)

📘 Concepto: Sea C el supertipo y S1, S2, …, Sn los subtipos.

  • La especialización es total (total) si toda ocurrencia de C pertenece al menos a un subtipo: S1 ∪ S2 ∪ … ∪ Sn = C.
  • Es parcial (partial) si puede haber ocurrencias de C que no pertenecen a ningún subtipo: S1 ∪ S2 ∪ … ∪ Sn ⊆ C.
  • Total: “Toda cuenta bancaria es corriente o de ahorro”. No existe una cuenta que no sea de ningún tipo.
  • Parcial: “Algunos empleados son comerciales o técnicos; los demás son empleados sin más”.

5.2. Exclusiva o solapada (restricción de disyunción)

📘 Concepto:

  • La especialización es exclusiva o disjunta (disjoint) si una ocurrencia de C puede pertenecer como mucho a un subtipo: Si ∩ Sj = ∅ para todo i ≠ j.
  • Es solapada o con solapamiento (overlapping) si una misma ocurrencia puede pertenecer a varios subtipos a la vez.
  • Exclusiva: “Un vehículo es turismo, furgoneta o moto, pero no dos cosas a la vez”.
  • Solapada: “Una persona de la universidad puede ser alumno y profesor a la vez”.

5.3. Los cuatro casos

Las dos restricciones son independientes, así que hay cuatro combinaciones. Conviene que tengas un ejemplo claro de cada una.

Caso 1: total y exclusiva (t, e)

Toda ocurrencia del supertipo está en exactamente un subtipo. Es el caso de una partición.

💻 Ejemplo: En un banco, toda CUENTA es o bien CUENTA_CORRIENTE (con límite de descubierto y tarjeta asociada) o bien CUENTA_AHORRO (con tipo de interés y plazo). No existen cuentas “genéricas”, y una cuenta no puede ser de los dos tipos.

flowchart TB
    CUENTA[CUENTA] --- c_iban([<u>iban</u>])
    CUENTA --- c_saldo([saldo])
    CUENTA --- c_fec([fecha_apertura])
    CUENTA --- jc{{"es un<br/>(total, exclusiva)"}}
    jc --- CORRIENTE[CUENTA_CORRIENTE]
    jc --- AHORRO[CUENTA_AHORRO]
    CORRIENTE --- cc_desc([limite_descubierto])
    AHORRO --- ca_int([tipo_interes])
    AHORRO --- ca_plazo([plazo_meses])

Caso 2: total y solapada (t, s)

Toda ocurrencia está en al menos un subtipo, y puede estar en varios.

💻 Ejemplo: En una universidad que solo guarda datos de las personas con las que tiene un vínculo, toda PERSONA es ALUMNO, PROFESOR o PAS (personal de administración y servicios), o varias de estas cosas a la vez: un miembro del PAS puede estar matriculado en un máster; un profesor puede estar haciendo el doctorado como alumno.

flowchart TB
    PERSONA[PERSONA] --- p_dni([<u>dni</u>])
    PERSONA --- p_nom([nombre])
    PERSONA --- jp{{"es un<br/>(total, solapada)"}}
    jp --- ALUMNO[ALUMNO]
    jp --- PROFESOR[PROFESOR]
    jp --- PAS[PAS]
    ALUMNO --- al_exp([num_expediente])
    PROFESOR --- pr_cat([categoria])
    PAS --- pa_pue([puesto])

Caso 3: parcial y exclusiva (p, e)

Una ocurrencia está en como mucho un subtipo, y puede no estar en ninguno.

💻 Ejemplo: En un concesionario, un VEHICULO puede ser ELECTRICO (autonomía, tiempo de carga) o HIBRIDO (capacidad de batería, modo eléctrico), o ninguna de las dos cosas (vehículos de combustión, que no tienen datos especiales). Un vehículo no puede ser eléctrico e híbrido a la vez.

flowchart TB
    VEHICULO[VEHICULO] --- v_bas([<u>num_bastidor</u>])
    VEHICULO --- v_mod([modelo])
    VEHICULO --- jv{{"es un<br/>(parcial, exclusiva)"}}
    jv --- ELECTRICO[ELECTRICO]
    jv --- HIBRIDO[HIBRIDO]
    ELECTRICO --- el_aut([autonomia_km])
    ELECTRICO --- el_carga([tiempo_carga_min])
    HIBRIDO --- hi_bat([capacidad_kwh])

Caso 4: parcial y solapada (p, s)

Una ocurrencia puede estar en ninguno, uno o varios subtipos. Es la opción menos restrictiva.

💻 Ejemplo: En un club deportivo, un SOCIO puede ser además JUGADOR de algún equipo (con ficha federativa), ENTRENADOR (con titulación) o DIRECTIVO (con cargo), o varias cosas a la vez, o ninguna (un socio que solo paga la cuota y usa las instalaciones).

flowchart TB
    SOCIO[SOCIO] --- s_num([<u>num_socio</u>])
    SOCIO --- s_nom([nombre])
    SOCIO --- s_cuota([cuota])
    SOCIO --- js{{"es un<br/>(parcial, solapada)"}}
    js --- JUGADOR[JUGADOR]
    js --- ENTRENADOR[ENTRENADOR]
    js --- DIRECTIVO[DIRECTIVO]
    JUGADOR --- ju_fic([num_ficha])
    ENTRENADOR --- en_tit([titulacion])
    DIRECTIVO --- di_car([cargo])

Resumen de los cuatro casos

Cobertura Abreviatura Una ocurrencia del supertipo está en… Expresión en conjuntos Ejemplo
Total, exclusiva (t, e) exactamente 1 subtipo S1 ∪ … ∪ Sn = C y Si ∩ Sj = ∅ Cuenta corriente / de ahorro
Total, solapada (t, s) 1 o más subtipos S1 ∪ … ∪ Sn = C Alumno / profesor / PAS
Parcial, exclusiva (p, e) 0 o 1 subtipo Si ∩ Sj = ∅ Vehículo eléctrico / híbrido
Parcial, solapada (p, s) 0, 1 o más subtipos Ninguna restricción adicional Socio jugador / entrenador / directivo

💡 Consejo: Un truco para deducir la cobertura es contarte las ocurrencias con los dedos. “¿Puedo tener un socio que no sea nada más?” Sí → parcial. “¿Puedo tener un socio que sea jugador y entrenador?” Sí → solapada. Haz siempre las dos preguntas por separado; el error más habitual es responder solo una y suponer la otra.

5.4. Qué implican en las operaciones

Las restricciones de cobertura no son solo “adornos” del diagrama: determinan qué operaciones son válidas sobre los datos. Elmasri y Navathe las resumen en reglas de inserción y borrado:

Operación Regla
Borrar una ocurrencia del supertipo Se borra automáticamente de todos los subtipos a los que pertenece (ya no existe el objeto)
Insertar una ocurrencia en el supertipo con cobertura total Hay que insertarla también en al menos un subtipo (en exactamente uno si es exclusiva)
Insertar en un subtipo La ocurrencia debe existir (o crearse a la vez) en el supertipo
Especialización definida por atributo La ocurrencia se coloca automáticamente en el subtipo que indica el valor del discriminante
Especialización parcial Se puede insertar en el supertipo sin insertar en ningún subtipo
Cambiar una ocurrencia de subtipo en una exclusiva Hay que sacarla del subtipo antiguo antes de meterla en el nuevo (por ejemplo, un empleado temporal que pasa a fijo)

⚠️ Importante: Cuando transformes la jerarquía a tablas (módulo 17), la mayoría de estas reglas no las garantiza la estructura. Por ejemplo, que una jerarquía sea exclusiva y se haya implementado con una tabla por subtipo exige comprobar que un mismo identificador no aparezca en dos tablas de subtipo, algo que no se puede expresar con un CHECK de una sola fila y suele requerir triggers (ver el Curso de Oracle PL/SQL) o lógica de aplicación. Por eso es tan importante dejarlas documentadas en el diagrama.

5.5. Jerarquías estáticas y dinámicas

Una cuestión relacionada, que el diagrama no recoge pero que conviene anotar, es si una ocurrencia puede cambiar de subtipo a lo largo de su vida:

  • Estática: una cuenta corriente nunca se convierte en cuenta de ahorro; un turismo nunca se convierte en moto.
  • Dinámica: un empleado temporal puede pasar a fijo; un alumno puede convertirse también en profesor.

Si la jerarquía es dinámica, valora si de verdad quieres un subtipo o si lo que estás modelando es un papel o un estado que cambia con el tiempo (lo veremos en los errores frecuentes, sección 11, y la dimensión temporal en el módulo 13).

6. El atributo discriminante

6.1. Especialización definida por atributo y definida por el usuario

📘 Concepto: Una especialización está definida por atributo (attribute-defined) cuando la pertenencia a cada subtipo viene determinada por el valor de un atributo del supertipo, llamado atributo discriminante (o atributo de definición). Está definida por el usuario (user-defined) cuando no existe tal atributo y es el usuario quien decide, ocurrencia a ocurrencia, a qué subtipos pertenece.

Ejemplos:

  • Definida por atributo: VEHICULO tiene el atributo tipo con valores {‘TURISMO’, ‘FURGONETA’, ‘MOTO’}. El valor del atributo indica a qué subtipo pertenece cada vehículo.
  • Definida por predicado (variante de la anterior, en la que cada subtipo tiene su condición): un EMPLEADO es DIRECTIVO si nivel >= 8; es JUNIOR si antigüedad < 2. Las condiciones pueden ser sobre atributos distintos.
  • Definida por el usuario: un CLIENTE es CLIENTE_PREFERENTE porque el departamento comercial así lo decide, sin una regla automática.

6.2. Notación del discriminante

En la notación del curso, el atributo discriminante se escribe como etiqueta de la línea que une el supertipo con el hexágono, y además se dibuja como atributo del supertipo:

flowchart TB
    VEHICULO[VEHICULO] --- v_mat([<u>matricula</u>])
    VEHICULO --- v_tipo([tipo])
    VEHICULO ---|"tipo"| jv{{"es un<br/>(total, exclusiva)"}}
    jv ---|"TURISMO"| TURISMO[TURISMO]
    jv ---|"FURGONETA"| FURGONETA[FURGONETA]
    jv ---|"MOTO"| MOTO[MOTO]

En las líneas hacia cada subtipo puedes escribir el valor del discriminante que le corresponde, como en el diagrama.

6.3. Discriminante y cobertura

El discriminante y la cobertura están relacionados:

Situación del discriminante Cobertura que implica
Atributo monovaluado y obligatorio, cada valor corresponde a un subtipo Total y exclusiva
Atributo monovaluado y opcional (o con valores sin subtipo, como ‘OTRO’) Parcial y exclusiva
Atributo multivaluado (por ejemplo, roles = {‘JUGADOR’, ‘ENTRENADOR’}) Solapada
Varios atributos booleanos (es_jugador, es_entrenador) Solapada (total si se exige al menos uno verdadero)

⚠️ Importante: Un discriminante monovaluado solo puede definir especializaciones exclusivas: una ocurrencia no puede tener dos valores a la vez en un atributo de un solo valor. Si la jerarquía es solapada, el discriminante tiene que ser multivaluado o un conjunto de indicadores.

💡 Consejo: El atributo discriminante resulta muy útil al pasar a tablas: si implementas la jerarquía con una sola tabla (módulo 17), el discriminante se convierte en una columna tipo con un CHECK (tipo IN (...)), y las reglas “si es MOTO entonces cilindrada no es nula” se escriben como CHECK de fila.

7. Jerarquías de varios niveles y retículas

7.1. Jerarquías de varios niveles

Un subtipo puede ser, a su vez, supertipo de otros subtipos. La herencia es transitiva: un subtipo de segundo nivel hereda los atributos y relaciones de su supertipo directo y de todos los supertipos que hay por encima.

💻 Ejemplo: En una universidad, PERSONA se especializa en EMPLEADO y ALUMNO. A su vez, EMPLEADO se especializa en DOCENTE y ADMINISTRATIVO, y DOCENTE en CATEDRATICO, TITULAR y ASOCIADO.

flowchart TB
    PERSONA[PERSONA] --- p_dni([<u>dni</u>])
    PERSONA --- p_nom([nombre])
    PERSONA --- j1{{"es un<br/>(parcial, solapada)"}}
    j1 --- EMPLEADO[EMPLEADO]
    j1 --- ALUMNO[ALUMNO]
    EMPLEADO --- e_ss([num_seg_social])
    EMPLEADO --- e_sal([salario])
    ALUMNO --- a_exp([num_expediente])
    EMPLEADO --- j2{{"es un<br/>(total, exclusiva)"}}
    j2 --- DOCENTE[DOCENTE]
    j2 --- ADMINISTRATIVO[ADMINISTRATIVO]
    DOCENTE --- d_area([area_conocimiento])
    ADMINISTRATIVO --- ad_neg([negociado])
    DOCENTE --- j3{{"es un<br/>(total, exclusiva)"}}
    j3 --- CATEDRATICO[CATEDRATICO]
    j3 --- TITULAR[TITULAR]
    j3 --- ASOCIADO[ASOCIADO]
    ASOCIADO --- as_emp([empresa_origen])

Un ASOCIADO tiene dni y nombre (de PERSONA), num_seg_social y salario (de EMPLEADO), area_conocimiento (de DOCENTE) y empresa_origen (propio).

Observaciones importantes:

  • Cada nivel tiene su propia cobertura. En el ejemplo, el primer nivel es (parcial, solapada) porque hay personas que solo son contactos externos y un empleado puede ser también alumno; el segundo es (total, exclusiva); el tercero también.
  • El identificador está solo en la raíz. Todos los niveles se identifican por dni.
  • La relación ES-UN se compone: “un asociado es un docente, que es un empleado, que es una persona”.

⚠️ Importante: No abuses de los niveles. Cada nivel que añades se traduce más tarde en tablas, claves ajenas y restricciones adicionales. Si un nivel no aporta ni atributos ni relaciones ni restricciones propios, sobra. En el ejemplo, CATEDRATICO y TITULAR no tienen nada propio dibujado: si en el análisis no aparece nada que los distinga, el tercer nivel debería sustituirse por un atributo categoria en DOCENTE, y solo ASOCIADO justificaría un subtipo (lo veremos en la sección 11).

7.2. Varias especializaciones de la misma entidad

Una misma entidad puede especializarse según varios criterios independientes, cada uno con su propio hexágono y su propia cobertura:

flowchart TB
    EMPLEADO[EMPLEADO] --- e_id([<u>num_empleado</u>])
    EMPLEADO --- e_contr([tipo_contrato])
    EMPLEADO --- e_jor([tipo_jornada])
    EMPLEADO ---|"tipo_contrato"| jc{{"es un<br/>(total, exclusiva)"}}
    jc --- FIJO[FIJO]
    jc --- TEMPORAL[TEMPORAL]
    EMPLEADO ---|"tipo_jornada"| jj{{"es un<br/>(total, exclusiva)"}}
    jj --- COMPLETA[JORNADA_COMPLETA]
    jj --- PARCIAL[JORNADA_PARCIAL]
    TEMPORAL --- t_fin([fecha_fin_contrato])
    PARCIAL --- p_horas([horas_semana])

Cada criterio es exclusivo dentro de sí mismo, pero un empleado pertenece a la vez a un subtipo de cada especialización: puede ser TEMPORAL y de JORNADA_PARCIAL.

⚠️ Importante: No mezcles criterios distintos en un solo hexágono. Si dibujas un único hexágono con FIJO, TEMPORAL, JORNADA_COMPLETA y JORNADA_PARCIAL, la cobertura ya no se puede expresar correctamente: no es exclusiva (un empleado está en dos subtipos), pero tampoco es “solapada” sin más (no puede ser fijo y temporal).

7.3. Retículas y herencia múltiple

📘 Concepto: Una subclase compartida (shared subclass) es una subclase que tiene más de una superclase. Cuando existe alguna, la jerarquía deja de ser un árbol y pasa a ser una retícula (lattice). La subclase compartida hereda de todas sus superclases: es la herencia múltiple.

💻 Ejemplo: En la universidad, un BECARIO_INVESTIGACION es a la vez un ALUMNO (está matriculado en el doctorado) y un EMPLEADO (cobra una nómina de la universidad). Tiene atributos propios: la convocatoria de la beca y el grupo de investigación.

flowchart TB
    PERSONA[PERSONA] --- p_dni([<u>dni</u>])
    PERSONA --- p_nom([nombre])
    PERSONA --- j1{{"es un<br/>(parcial, solapada)"}}
    j1 --- EMPLEADO[EMPLEADO]
    j1 --- ALUMNO[ALUMNO]
    EMPLEADO --- e_sal([salario])
    ALUMNO --- a_exp([num_expediente])
    EMPLEADO --- j2{{"es un<br/>(parcial)"}}
    ALUMNO --- j3{{"es un<br/>(parcial)"}}
    j2 --- BECARIO[BECARIO_INVESTIGACION]
    j3 --- BECARIO
    BECARIO --- b_conv([convocatoria])
    BECARIO ---|"(0,n)"| pertenece{"pertenece<br/>1:N"}
    pertenece ---|"(1,1)"| GRUPO[GRUPO_INVESTIGACION]

Reglas de las retículas:

  1. Raíz común. Todas las superclases de una subclase compartida deben tener una raíz común (aquí, PERSONA), de la que heredan el mismo identificador. Si no existe raíz común, lo que tienes no es una subclase compartida, sino probablemente una categoría (sección 8).
  2. Solapamiento en el nivel superior. Para que una ocurrencia sea a la vez EMPLEADO y ALUMNO, la especialización de PERSONA en esos dos subtipos tiene que ser solapada. Si la hubieras marcado como exclusiva, la retícula sería contradictoria y BECARIO_INVESTIGACION estaría siempre vacía.
  3. Herencia sin duplicados. BECARIO_INVESTIGACION hereda dni y nombre una sola vez, aunque le lleguen por dos caminos. Las ocurrencias de la subclase compartida son exactamente la intersección de las de sus superclases que cumplen la condición de pertenencia: BECARIO ⊆ EMPLEADO ∩ ALUMNO.
  4. Conflictos de nombres. Si EMPLEADO y ALUMNO tuvieran un atributo con el mismo nombre y distinto significado (por ejemplo, fecha_alta como fecha de contratación y como fecha de matrícula), hay que renombrarlos para evitar ambigüedad.

💡 Consejo: Las retículas son elegantes en el papel, pero complican mucho la transformación a tablas. Antes de usarlas pregúntate si la subclase compartida tiene realmente atributos o relaciones propios. Si BECARIO_INVESTIGACION solo significara “persona que es empleado y alumno a la vez”, no hace falta dibujarla: ya se deduce de que la persona está en los dos subtipos.

7.4. Árbol frente a retícula

Característica Jerarquía en árbol Retícula
Superclases por subclase Una Una o varias
Herencia Simple Múltiple
Requisito de raíz Una raíz por árbol Raíz común obligatoria para las subclases compartidas
Complejidad de transformación Moderada Alta
Uso típico Clasificaciones (vehículos, cuentas, contenidos) Personas con varios papeles a la vez

8. Categorías o tipos unión

8.1. El problema: una relación con “una cosa u otra”

Imagina el registro de la propiedad de vehículos de la Dirección General de Tráfico. El propietario de un vehículo puede ser:

  • una persona (identificada por DNI, con nombre y fecha de nacimiento),
  • una empresa (identificada por CIF, con razón social y sector), o
  • un banco (identificado por su código de entidad, cuando el vehículo está en leasing).

Persona, empresa y banco son entidades completamente distintas, con identificadores distintos y que existen por sí mismas para otros fines. No existe una “superclase natural” de la que sean subtipos: no tiene sentido decir que “toda persona es un propietario”, porque la mayoría de las personas no tienen vehículos.

📘 Concepto: Una categoría o tipo unión (category, union type) es una subclase cuyas ocurrencias son un subconjunto de la unión de las ocurrencias de varias superclases distintas, que pueden tener identificadores distintos. Formalmente, PROPIETARIO ⊆ PERSONA ∪ EMPRESA ∪ BANCO. Cada ocurrencia de la categoría pertenece a una sola de las superclases.

8.2. Notación

En la notación del curso, la categoría se dibuja con un hexágono que contiene el símbolo ∪ (unión). Las superclases se unen al hexágono, y del hexágono sale una línea hacia la categoría:

flowchart TB
    PERSONA[PERSONA] --- pe_dni([<u>dni</u>])
    PERSONA --- pe_nom([nombre])
    EMPRESA[EMPRESA] --- em_cif([<u>cif</u>])
    EMPRESA --- em_raz([razon_social])
    BANCO[BANCO] --- ba_cod([<u>cod_entidad</u>])
    BANCO --- ba_nom([nombre])
    PERSONA --- u1{{"∪<br/>(categoría parcial)"}}
    EMPRESA --- u1
    BANCO --- u1
    u1 --> PROPIETARIO[PROPIETARIO]
    PROPIETARIO --- pr_id([<u>id_propietario</u>])
    PROPIETARIO ---|"(1,1)"| posee{"posee<br/>1:N"}
    posee ---|"(1,n)"| VEHICULO[VEHICULO]
    VEHICULO --- v_mat([<u>matricula</u>])

Elementos clave:

  • La flecha desde el hexágono ∪ hacia PROPIETARIO indica que la categoría es el subconjunto que se forma a partir de las superclases.
  • PROPIETARIO lleva un identificador sustituto propio (id_propietario), porque sus ocurrencias proceden de superclases con identificadores diferentes (DNI, CIF y código de entidad no son comparables ni tienen el mismo formato).
  • Un propietario posee de 1 a n vehículos, y cada vehículo tiene exactamente un propietario.

⚠️ Importante: El identificador sustituto de una categoría es casi obligatorio en la práctica. Sin él, la relación posee no sabría con qué identificador referenciar al propietario. Algunos autores no lo dibujan en el modelo conceptual y lo añaden en el paso a tablas; en este curso lo dibujamos para dejarlo claro.

8.3. Categoría total y parcial

  • Categoría parcial: la categoría contiene un subconjunto de la unión. No todas las personas, empresas y bancos son propietarios. Es el caso del ejemplo y el más habitual.
  • Categoría total: la categoría contiene todas las ocurrencias de la unión. Por ejemplo, si en un sistema solo se registran personas y empresas en cuanto que son titulares de alguna cuenta, toda persona y toda empresa es un TITULAR.

💡 Consejo: Una categoría total se parece mucho a una generalización: si todas las ocurrencias de las superclases están en la categoría, a menudo es más simple generalizar (crear un supertipo TITULAR con PERSONA y EMPRESA como subtipos). La categoría tiene sentido cuando las superclases son entidades independientes, con identificadores distintos y con vida propia en el sistema.

8.4. Herencia en las categorías: herencia selectiva

En una generalización, el subtipo hereda los atributos del supertipo. En una categoría ocurre algo distinto: cada ocurrencia de la categoría hereda los atributos solo de la superclase a la que pertenece. Un propietario que es una persona tiene dni y nombre; uno que es una empresa tiene cif y razon_social. Esto se llama herencia selectiva.

8.5. Categoría frente a generalización

Es un punto que se pregunta mucho en los exámenes porque los dos diagramas se parecen.

Aspecto Generalización / especialización Categoría (tipo unión)
Número de superclases Una superclase, varios subtipos Varias superclases, una subclase (la categoría)
Relación de conjuntos Cada subtipo ⊆ supertipo Categoría ⊆ superclase1 ∪ superclase2 ∪ …
Identificador Todos comparten el del supertipo Las superclases tienen identificadores distintos; la categoría suele necesitar uno sustituto
Herencia El subtipo hereda todo del supertipo Cada ocurrencia hereda solo de su superclase (herencia selectiva)
Existencia previa El supertipo agrupa lo común de los subtipos Las superclases son entidades independientes con su propia vida
Ejemplo VEHICULO → TURISMO, MOTO PROPIETARIO = subconjunto de PERSONA ∪ EMPRESA ∪ BANCO
Pregunta clave “¿Todo X es un Y?” “¿Este papel lo puede desempeñar un A, un B o un C?”

💻 Ejemplo: Compara estos dos enunciados:

  1. “Los clientes de la empresa pueden ser particulares o empresas. De todos guardamos un código de cliente, dirección y teléfono; de los particulares, además, el DNI y la fecha de nacimiento; de las empresas, el CIF y la persona de contacto.”
  2. “El pagador de una multa puede ser una persona o una empresa; ambas existen en el sistema con su DNI o su CIF y se usan en muchos otros procesos (padrón, licencias, impuestos).”

El primero es una generalización: CLIENTE es el supertipo con identificador común (cod_cliente) y atributos comunes; PARTICULAR y EMPRESA son subtipos (total, exclusiva). El segundo es una categoría: PERSONA y EMPRESA son entidades independientes, y PAGADOR es el subconjunto de su unión que paga multas.

8.6. Alternativa sin categoría: la restricción de exclusividad

Una categoría se puede evitar uniendo VEHICULO directamente a PERSONA, EMPRESA y BANCO con tres relaciones distintas, y añadiendo una restricción de exclusividad (“cada vehículo participa en exactamente una de las tres relaciones”). Es otra forma correcta de modelarlo; la estudiaremos en el módulo 13. La categoría es preferible cuando el “propietario” participa en varias relaciones (posee vehículos, paga impuestos, recibe notificaciones…), porque así no hay que triplicar cada una.

9. Agregación (introducción)

📘 Concepto: La agregación (aggregation) es una abstracción que permite tratar una relación (junto con las entidades que une) como si fuera una entidad de nivel superior, para poder relacionarla a su vez con otras entidades. Es necesaria porque en el modelo E/R una relación solo puede unir entidades, nunca relaciones.

9.1. Ejemplo: EMPLEADO trabaja en PROYECTO usando MAQUINA

Los empleados trabajan en proyectos (relación N:M trabaja). Algunas de esas participaciones, no todas, requieren el uso de máquinas: “Ana usa la impresora 3D cuando trabaja en el proyecto Alfa, pero no cuando trabaja en el proyecto Beta”. La máquina no se asigna al empleado ni al proyecto por separado, sino a la participación concreta de un empleado en un proyecto.

flowchart LR
    subgraph AGR["trabajo (agregación)"]
        EMPLEADO[EMPLEADO] ---|"(1,n)"| trabaja{"trabaja<br/>N:M"}
        trabaja ---|"(1,n)"| PROYECTO[PROYECTO]
    end
    AGR ---|"(0,n)"| usa{"usa<br/>N:M"}
    usa ---|"(0,n)"| MAQUINA[MAQUINA]

El subgraph encierra la relación agregada (trabaja) con sus entidades: el conjunto se comporta como una entidad, “TRABAJO”, que se relaciona con MAQUINA a través de usa. Lectura: cada participación de un empleado en un proyecto usa de 0 a n máquinas, y cada máquina se usa en 0 a n participaciones.

9.2. ¿Por qué no una ternaria?

Si modeláramos EMPLEADO, PROYECTO y MAQUINA con una única relación ternaria, cada ocurrencia de la relación necesitaría las tres entidades: no se podría registrar que Ana trabaja en el proyecto Beta sin máquina. La agregación separa los dos hechos: “Ana trabaja en Beta” existe por sí mismo, y “en ese trabajo usa la impresora” es un hecho adicional y opcional.

9.3. Composición

En UML se distingue además la composición, una forma fuerte de agregación del tipo todo-parte en la que las partes no existen sin el todo y se destruyen con él (las líneas de un pedido no existen sin el pedido). En el modelo E/R esta semántica se expresa con entidades débiles con dependencia en existencia (módulo 10).

💡 Consejo: La agregación, sus variantes (agregación de relación, agregación compuesto/componente), la composición y la comparación detallada con las relaciones ternarias se estudian en profundidad en el módulo de agregación. Aquí basta con que sepas reconocerla y dibujarla.

10. Resumen de la notación EER del curso

El siguiente diagrama reúne en un solo ejemplo los elementos de este módulo: jerarquía con discriminante, relaciones a distintos niveles, una categoría y una agregación. Corresponde a una pequeña empresa de alquiler de vehículos.

flowchart TB
    classDef derivado stroke-dasharray: 5 5
    VEHICULO[VEHICULO] --- v_mat([<u>matricula</u>])
    VEHICULO --- v_tipo([tipo])
    VEHICULO --- v_km([km_totales]):::derivado
    VEHICULO ---|"tipo"| jv{{"es un<br/>(total, exclusiva)"}}
    jv --- TURISMO[TURISMO]
    jv --- FURGONETA[FURGONETA]
    TURISMO --- t_pl([num_plazas])
    FURGONETA --- f_car([carga_max_kg])
    FURGONETA ---|"(0,n)"| requiere{"requiere<br/>N:M"}
    requiere ---|"(0,n)"| PERMISO[TIPO_PERMISO]
    PARTICULAR[PARTICULAR] --- pa_dni([<u>dni</u>])
    EMPRESA[EMPRESA] --- em_cif([<u>cif</u>])
    PARTICULAR --- u1{{"∪<br/>(categoría parcial)"}}
    EMPRESA --- u1
    u1 --> ARRENDATARIO[ARRENDATARIO]
    ARRENDATARIO --- ar_id([<u>id_arrendatario</u>])
    subgraph ALQ["alquiler (agregación)"]
        ARRENDATARIO ---|"(0,n)"| alquila{"alquila<br/>N:M"}
        alquila ---|"(0,n)"| VEHICULO
    end
    ALQ ---|"(0,n)"| incluye{"incluye<br/>N:M"}
    incluye ---|"(0,n)"| EXTRA[EXTRA]
Elemento EER Símbolo en el curso Mermaid
Jerarquía ES-UN Hexágono “es un” con cobertura j{{"es un<br/>(total, exclusiva)"}}
Cobertura (total|parcial, exclusiva|solapada) o (t,e), (t,s), (p,e), (p,s) Texto dentro del hexágono
Discriminante Etiqueta en la línea supertipo-hexágono X ---\|"tipo"\| j
Valor del discriminante Etiqueta en la línea hexágono-subtipo j ---\|"MOTO"\| MOTO
Categoría (unión) Hexágono “∪” con flecha hacia la categoría u{{"∪<br/>(categoría parcial)"}} y u --> CAT
Agregación Recuadro que encierra la relación y sus entidades subgraph AGR["nombre (agregación)"] ... end
Atributo derivado Borde discontinuo :::derivado
Tipo de correspondencia Dentro del rombo r{"alquila<br/>N:M"}
Clave alternativa (también en subtipos) Sufijo (AK) en la etiqueta (["num_expediente (AK)"])

11. Errores frecuentes

11.1. Crear una jerarquía cuando basta un atributo “tipo”

Es el error más frecuente con diferencia. El estudiante descubre que “hay clientes nacionales e internacionales” y dibuja inmediatamente una jerarquía con dos subtipos vacíos.

Incorrecto:

flowchart TB
    CLIENTE[CLIENTE] --- c_id([<u>cod_cliente</u>])
    CLIENTE --- c_nom([nombre])
    CLIENTE --- jc{{"es un<br/>(total, exclusiva)"}}
    jc --- NACIONAL[NACIONAL]
    jc --- INTERNACIONAL[INTERNACIONAL]

Correcto:

flowchart TB
    CLIENTE[CLIENTE] --- c_id([<u>cod_cliente</u>])
    CLIENTE --- c_nom([nombre])
    CLIENTE --- c_tipo([tipo])

con la restricción documentada: tipo ∈ {‘NACIONAL’, ‘INTERNACIONAL’}.

⚠️ Importante: Regla de oro: un subtipo solo está justificado si tiene al menos una de estas cosas:

  1. Atributos propios que no tienen sentido para el resto de ocurrencias.
  2. Relaciones propias en las que solo participan sus ocurrencias.
  3. Restricciones o cardinalidades distintas (por ejemplo, un atributo heredado que es obligatorio solo en ese subtipo, o una relación que en ese subtipo es obligatoria).

Si no cumple ninguna, sustitúyelo por un valor de un atributo del supertipo.

Para decidir puedes usar esta tabla:

Pregunta Si la respuesta es “sí”
¿Los grupos tienen atributos distintos? Jerarquía
¿Los grupos participan en relaciones distintas? Jerarquía
¿Solo cambia una “etiqueta” que sirve para filtrar o clasificar? Atributo tipo
¿Los valores del tipo cambian con frecuencia o los define el usuario (nuevas categorías cada año)? Entidad TIPO_X relacionada (no jerarquía ni atributo con valores fijos)
¿El tipo tiene atributos propios (descripción, tarifa, descuento)? Entidad TIPO_X relacionada

11.2. Usar una jerarquía para modelar estados

“Un pedido puede estar pendiente, enviado, entregado o cancelado” no es una jerarquía: es un estado que cambia con el tiempo y que se modela con un atributo estado (y, si interesa el historial de estados, con una entidad de historial; ver el módulo 13). Un pedido pendiente no tiene atributos distintos de uno enviado; a lo sumo, fecha_envio es opcional.

11.3. Confundir papeles (roles) con subtipos

Que una persona sea “conductor” de un vehículo no la convierte en subtipo CONDUCTOR de PERSONA: es un papel en una relación (PERSONA conduce VEHICULO). Solo tiene sentido un subtipo CONDUCTOR si tiene atributos propios (número de permiso, fecha de expedición, puntos) o relaciones propias.

11.4. Repetir en el subtipo el identificador o atributos heredados

Dibujar dni en PERSONA y otra vez en ALUMNO y PROFESOR es redundante y confuso: parece que son atributos distintos. Los atributos heredados no se dibujan en los subtipos.

11.5. Poner identificadores distintos en los subtipos

Si ALUMNO se identifica por num_expediente y PROFESOR por num_registro_personal, y la superclase PERSONA no tiene identificador, el diagrama es incorrecto: el supertipo debe tener un identificador válido para todas sus ocurrencias. Los identificadores particulares pueden quedarse en los subtipos como claves alternativas.

11.6. Colocar una relación en el nivel equivocado

Unir imparte a PERSONA en lugar de a PROFESOR permite que un alumno imparta clase. Unir tiene_tarjeta a ALUMNO y a PROFESOR (duplicada) en lugar de a PERSONA es redundante. Pregúntate siempre: ¿quién participa realmente en esta relación?

11.7. Elegir mal la cobertura

  • Marcar como exclusiva una jerarquía donde una persona puede ser alumno y profesor.
  • Marcar como total una jerarquía en la que hay ocurrencias “genéricas” (empleados que no son ni comerciales ni técnicos).
  • Olvidar indicar la cobertura (el hexágono vacío no dice nada; en un examen se considera incompleto).

11.8. Jerarquías con un solo subtipo sin justificación

Una jerarquía con un único subtipo es correcta (por ejemplo, EMPLEADO → DIRECTIVO, parcial, porque los directivos tienen coche de empresa y bonus), pero muchas veces delata que se ha creado un subtipo innecesario. Comprueba la regla de oro.

11.9. Usar subtipos donde hay instancias

Dibujar VEHICULO con subtipos SEAT_IBIZA, RENAULT_CLIO y FORD_FOCUS confunde tipos con valores. Los modelos de coche son ocurrencias de una entidad MODELO (con marca, potencia, plazas), relacionada con VEHICULO. Una pista: si cada año aparecen subtipos nuevos, no son subtipos.

11.10. Confundir categoría y generalización

Si las supuestas “superclases” de una categoría tienen el mismo identificador y atributos comunes, en realidad es una generalización al revés. Y si unos supuestos “subtipos” tienen identificadores distintos y vida independiente, probablemente es una categoría o una exclusividad.

11.11. Usar una ternaria cuando el hecho es opcional (o al revés)

Si una entidad participa solo “a veces” en un hecho que existe por sí mismo (la máquina en el trabajo de un empleado), no uses una ternaria: usa una agregación. Lo verás en detalle en el módulo de agregación.

12. Ejercicios

Ejercicio 1: Determinar la cobertura

Indica la cobertura (total/parcial, exclusiva/solapada) de cada jerarquía y justifícala:

  1. INSTRUMENTO → CUERDA, VIENTO, PERCUSION en el inventario de un conservatorio que solo tiene instrumentos de esas tres familias.
  2. ARTICULO_BLOG → CON_VIDEO, CON_GALERIA (un artículo puede incluir vídeo, galería de fotos, ambos o ninguno).
  3. PACIENTE → HOSPITALIZADO, AMBULATORIO (en un momento dado, un paciente está ingresado o se le atiende en consulta, pero no las dos cosas; todos están en uno de los dos casos).
  4. PRODUCTO → PERECEDERO, CONGELADO en un supermercado (algunos productos no son ni una cosa ni otra; los congelados nunca se consideran perecederos en este sistema).
  5. MIEMBRO_ONG → VOLUNTARIO, SOCIO_CONTRIBUYENTE, TRABAJADOR (una persona entra en la ONG porque es al menos una de estas cosas y puede ser varias).
  6. LIBRO → EN_PAPEL, ELECTRONICO en una librería en la que muchos títulos se venden en los dos formatos.
Ver solución
Nº Cobertura Justificación
1 (total, exclusiva) Todos los instrumentos pertenecen a una familia y solo a una
2 (parcial, solapada) Puede haber artículos sin vídeo ni galería (parcial) y artículos con ambos (solapada)
3 (total, exclusiva) Todo paciente está en uno de los dos casos y no en los dos a la vez
4 (parcial, exclusiva) Hay productos que no son de ningún subtipo; los dos subtipos no se solapan por definición del negocio
5 (total, solapada) Todos son al menos una cosa; pueden ser varias
6 (parcial, solapada) si hay títulos solo de catálogo; (total, solapada) si todo libro se vende al menos en un formato La disyunción es solapada sin duda; la totalidad depende de si existen libros sin formato a la venta (por ejemplo, anunciados pero no publicados)

Observa el caso 3: el paciente puede cambiar de subtipo con el tiempo (jerarquía dinámica). La cobertura describe la situación en cada instante. Si además interesa el historial de ingresos, lo correcto sería modelar INGRESO como entidad, y quizá la jerarquía sobre.

En el caso 6, la jerarquía probablemente está mal planteada: lo que se vende es una edición en un formato. Una alternativa mejor es LIBRO (obra) relacionado 1:N con EDICION, que tiene un atributo formato, y una jerarquía sobre EDICION solo si los formatos tienen atributos distintos (peso y páginas en papel; tamaño en MB y DRM en electrónico).

Ejercicio 2: Empresa de alquiler de vehículos

Una empresa de alquiler quiere guardar de cada vehículo su matrícula, marca, modelo, fecha de compra y kilómetros. Los vehículos son turismos, furgonetas o motos (siempre uno de los tres). De los turismos interesa el número de plazas y si tienen cambio automático; de las furgonetas, la carga máxima y el volumen de carga; de las motos, la cilindrada y si incluyen casco. Las furgonetas de más de 3500 kg requieren un tipo de permiso de conducir concreto, que se guarda en el sistema (código y descripción). Cada vehículo está asignado a una oficina (código, ciudad, dirección), y una oficina puede tener muchos vehículos. Dibuja el diagrama E/R extendido indicando el discriminante.

Ver solución
flowchart TB
    VEHICULO[VEHICULO] --- v_mat([<u>matricula</u>])
    VEHICULO --- v_mar([marca])
    VEHICULO --- v_mod([modelo])
    VEHICULO --- v_fec([fecha_compra])
    VEHICULO --- v_km([km])
    VEHICULO --- v_tipo([tipo])
    VEHICULO ---|"(0,n)"| asignado{"asignado<br/>1:N"}
    asignado ---|"(1,1)"| OFICINA[OFICINA]
    OFICINA --- o_cod([<u>cod_oficina</u>])
    OFICINA --- o_ciu([ciudad])
    OFICINA --- o_dir([direccion])
    VEHICULO ---|"tipo"| jv{{"es un<br/>(total, exclusiva)"}}
    jv ---|"TURISMO"| TURISMO[TURISMO]
    jv ---|"FURGONETA"| FURGONETA[FURGONETA]
    jv ---|"MOTO"| MOTO[MOTO]
    TURISMO --- t_pl([num_plazas])
    TURISMO --- t_aut([cambio_automatico])
    FURGONETA --- f_car([carga_max_kg])
    FURGONETA --- f_vol([volumen_m3])
    MOTO --- m_cc([cilindrada])
    MOTO --- m_cas([incluye_casco])
    FURGONETA ---|"(0,n)"| requiere{"requiere<br/>1:N"}
    requiere ---|"(0,1)"| PERMISO[TIPO_PERMISO]
    PERMISO --- pe_cod([<u>cod_permiso</u>])
    PERMISO --- pe_des([descripcion])

Decisiones:

  • (total, exclusiva) porque el enunciado dice “siempre uno de los tres”. Por ser total y exclusiva, el discriminante tipo es monovaluado y obligatorio.
  • requiere se une a FURGONETA y no a VEHICULO, porque solo las furgonetas pueden requerir un permiso especial. Cada furgoneta requiere 0 o 1 tipo de permiso; un tipo de permiso puede ser requerido por 0 a n furgonetas.
  • Restricción no expresada en el diagrama: R1: una furgoneta participa en requiere si y solo si su carga_max_kg > 3500. Hay que anotarla en el diccionario de datos.
  • asignado está en el supertipo porque todos los vehículos están en una oficina.

Ejercicio 3: Jerarquía multinivel y subclase compartida

En un hospital, todo el personal tiene número de empleado, nombre, DNI y fecha de contratación. El personal es sanitario o no sanitario (siempre uno de los dos). El personal sanitario tiene número de colegiado y puede ser médico (con especialidad) o enfermero (con unidad asignada); no hay otro tipo de sanitario. El personal no sanitario tiene una categoría laboral. Además, algunos miembros del personal son docentes del hospital universitario (con un código de profesor y un departamento universitario); pueden ser docentes tanto sanitarios como no sanitarios. Los médicos que además son docentes se llaman profesores clínicos y tienen asignado un número de alumnos tutorizados. Dibuja el diagrama.

Ver solución
flowchart TB
    PERSONAL[PERSONAL] --- p_num([<u>num_empleado</u>])
    PERSONAL --- p_dni(["dni (AK)"])
    PERSONAL --- p_nom([nombre])
    PERSONAL --- p_fec([fecha_contratacion])
    PERSONAL --- j1{{"es un<br/>(total, exclusiva)"}}
    j1 --- SANITARIO[SANITARIO]
    j1 --- NOSANITARIO[NO_SANITARIO]
    SANITARIO --- s_col([num_colegiado])
    NOSANITARIO --- n_cat([categoria_laboral])
    SANITARIO --- j2{{"es un<br/>(total, exclusiva)"}}
    j2 --- MEDICO[MEDICO]
    j2 --- ENFERMERO[ENFERMERO]
    MEDICO --- m_esp([especialidad])
    ENFERMERO --- e_uni([unidad])
    PERSONAL --- j3{{"es un<br/>(parcial)"}}
    j3 --- DOCENTE[DOCENTE]
    DOCENTE --- d_cod([cod_profesor])
    DOCENTE --- d_dep([departamento_univ])
    MEDICO --- j4{{"es un<br/>(parcial)"}}
    DOCENTE --- j5{{"es un<br/>(parcial)"}}
    j4 --- PCLINICO[PROFESOR_CLINICO]
    j5 --- PCLINICO
    PCLINICO --- pc_alu([num_alumnos_tutorizados])

Decisiones:

  • Hay dos especializaciones independientes de PERSONAL: por tipo de personal (total, exclusiva) y por docencia (parcial, con un solo subtipo). Al ser un criterio distinto, va en otro hexágono. Una especialización con un único subtipo no necesita indicar exclusiva/solapada.
  • PROFESOR_CLINICO es una subclase compartida de MEDICO y DOCENTE, con raíz común PERSONAL. Es posible porque las dos especializaciones de PERSONAL son independientes: un médico puede ser docente.
  • Se justifica dibujar PROFESOR_CLINICO porque tiene un atributo propio (num_alumnos_tutorizados). Si no lo tuviera, bastaría con saber que la persona es médico y docente.
  • especialidad podría ser una entidad ESPECIALIDAD (si interesa guardar datos de cada especialidad); con lo que dice el enunciado basta como atributo.

Ejercicio 4: ¿Jerarquía, atributo o entidad?

Para cada situación, decide si modelarías una jerarquía, un atributo o una entidad relacionada, y justifícalo:

  1. Las habitaciones de un hotel son individuales, dobles o suites.
  2. Las suites tienen además un número de estancias, si incluyen jacuzzi y un mayordomo asignado (empleado del hotel).
  3. Los socios de un gimnasio tienen una modalidad de cuota (mensual, trimestral, anual), cada una con un precio que la dirección cambia cada año.
  4. Los usuarios de una red social pueden ser cuentas personales o cuentas de empresa; las de empresa tienen CIF, sector y pueden contratar campañas de publicidad.
  5. Los empleados pueden estar de baja o en activo.
Ver solución
  1. Atributo tipo en HABITACION (valores ‘INDIVIDUAL’, ‘DOBLE’, ‘SUITE’), si solo se trata de clasificar. Si cada tipo tiene precio por noche, capacidad… entonces entidad TIPO_HABITACION.
  2. Ahora las suites tienen atributos propios (num_estancias, jacuzzi) y una relación propia (asignado con EMPLEADO): jerarquía HABITACION → SUITE (parcial, con un solo subtipo). Las individuales y dobles no necesitan subtipo porque no tienen nada propio. El tipo puede seguir siendo un atributo para distinguir individual/doble.
  3. Entidad MODALIDAD_CUOTA (código, nombre, precio) relacionada con SOCIO (cada socio tiene una modalidad; cada modalidad, muchos socios). No es jerarquía (los socios no tienen atributos distintos según su cuota) ni simple atributo (la modalidad tiene su propio atributo precio, que cambia). Si interesa el precio histórico, ver el módulo 13.
  4. Jerarquía USUARIO → CUENTA_EMPRESA (parcial) o USUARIO → CUENTA_PERSONAL, CUENTA_EMPRESA (total, exclusiva) si las personales tienen algún atributo propio (fecha de nacimiento, por ejemplo). Se justifica por los atributos propios (cif, sector) y la relación propia con CAMPAÑA.
  5. Atributo situacion (o, mejor, una entidad BAJA débil de EMPLEADO con fechas de inicio y fin y motivo si interesa el historial). Nunca una jerarquía: es un estado que cambia con el tiempo.

Ejercicio 5: Categoría o generalización

Un ayuntamiento gestiona licencias de obra. El solicitante de una licencia puede ser un ciudadano (DNI, nombre, dirección) o una empresa (CIF, razón social, representante). Los ciudadanos y las empresas ya existen en la base de datos municipal porque se usan en el padrón, los impuestos y otros trámites. Cada licencia (número de expediente, fecha de solicitud, presupuesto de obra, estado) tiene un solo solicitante, y un solicitante puede pedir muchas licencias. Además, del solicitante interesa guardar un teléfono y un email de contacto para las licencias, que pueden no coincidir con los del padrón. Dibuja el diagrama y explica por qué has elegido categoría o generalización.

Ver solución
flowchart TB
    CIUDADANO[CIUDADANO] --- c_dni([<u>dni</u>])
    CIUDADANO --- c_nom([nombre])
    CIUDADANO --- c_dir([direccion])
    EMPRESA[EMPRESA] --- e_cif([<u>cif</u>])
    EMPRESA --- e_raz([razon_social])
    EMPRESA --- e_rep([representante])
    CIUDADANO --- u1{{"∪<br/>(categoría parcial)"}}
    EMPRESA --- u1
    u1 --> SOLICITANTE[SOLICITANTE]
    SOLICITANTE --- s_id([<u>id_solicitante</u>])
    SOLICITANTE --- s_tel([telefono_contacto])
    SOLICITANTE --- s_ema([email_contacto])
    SOLICITANTE ---|"(1,1)"| solicita{"solicita<br/>1:N"}
    solicita ---|"(1,n)"| LICENCIA[LICENCIA]
    LICENCIA --- l_exp([<u>num_expediente</u>])
    LICENCIA --- l_fec([fecha_solicitud])
    LICENCIA --- l_pre([presupuesto])
    LICENCIA --- l_est([estado])

Es una categoría parcial:

  • CIUDADANO y EMPRESA son entidades independientes, con identificadores distintos (DNI y CIF) y vida propia en otros procesos municipales.
  • No todo ciudadano ni toda empresa solicita licencias: la categoría es un subconjunto de la unión → parcial.
  • SOLICITANTE tiene atributos propios (telefono_contacto, email_contacto) y una relación propia (solicita), lo que justifica crearla en lugar de unir LICENCIA con dos relaciones exclusivas.
  • Un solicitante tiene de 1 a n licencias (solo es solicitante quien ha pedido alguna); cada licencia tiene exactamente 1 solicitante.

Una generalización (SOLICITANTE como supertipo con CIUDADANO y EMPRESA como subtipos) sería incorrecta, porque obligaría a que todo ciudadano fuera solicitante y a que ciudadanos y empresas compartieran identificador.

Ejercicio 6: Encuentra los errores

Un compañero ha entregado este diagrama para modelar los productos de una tienda online. Encuentra al menos cinco errores y propón el diagrama corregido. Información del enunciado: todos los productos tienen código, nombre y precio; los productos son físicos (con peso y dimensiones, se envían con una empresa de transporte) o digitales (con tamaño del fichero y URL de descarga), nunca ambos; los productos pueden estar en oferta o no.

flowchart TB
    PRODUCTO[PRODUCTO] --- p_nom([nombre])
    PRODUCTO --- p_pre([precio])
    PRODUCTO --- p_peso([peso])
    PRODUCTO ---|"(1,1)"| envia{"envia<br/>1:N"}
    envia ---|"(0,n)"| TRANSPORTISTA[TRANSPORTISTA]
    PRODUCTO --- jp{{"es un"}}
    jp --- FISICO[FISICO]
    jp --- DIGITAL[DIGITAL]
    jp --- OFERTA[EN_OFERTA]
    FISICO --- f_cod([<u>codigo</u>])
    DIGITAL --- d_cod([<u>codigo</u>])
    DIGITAL --- d_tam([tamano_mb])
    DIGITAL --- d_url([url_descarga])
Ver solución

Errores:

  1. El supertipo no tiene identificador y los subtipos sí (codigo repetido en cada uno). El identificador debe estar en PRODUCTO y heredarse.
  2. peso está en el supertipo, pero solo tiene sentido para los productos físicos. Además faltan las dimensiones.
  3. La relación envia está en el supertipo: obligaría a que los productos digitales tuvieran transportista (1,1). Debe ir en FISICO.
  4. El hexágono no indica la cobertura.
  5. Se mezclan dos criterios en la misma especialización: el formato (físico/digital) y la oferta (sí/no).
  6. EN_OFERTA no tiene atributos ni relaciones propios: no justifica un subtipo. Es un atributo (o, si interesa el porcentaje y las fechas de la oferta, una entidad OFERTA relacionada).

Diagrama corregido:

flowchart TB
    PRODUCTO[PRODUCTO] --- p_cod([<u>codigo</u>])
    PRODUCTO --- p_nom([nombre])
    PRODUCTO --- p_pre([precio])
    PRODUCTO --- p_ofe([en_oferta])
    PRODUCTO --- jp{{"es un<br/>(total, exclusiva)"}}
    jp --- FISICO[FISICO]
    jp --- DIGITAL[DIGITAL]
    FISICO --- f_peso([peso])
    FISICO --- f_dim([dimensiones])
    FISICO ---|"(0,n)"| envia{"envia<br/>1:N"}
    envia ---|"(1,1)"| TRANSPORTISTA[TRANSPORTISTA]
    DIGITAL --- d_tam([tamano_mb])
    DIGITAL --- d_url([url_descarga])

Observa también la corrección de las cardinalidades de envia: con la convención del curso, “cada producto físico se envía con exactamente un transportista” se escribe (1,1) junto a TRANSPORTISTA, y “un transportista envía de 0 a n productos” se escribe (0,n) junto a FISICO. El diagrama original tenía las parejas cambiadas de lado.

Ejercicio 7 (propuesto): Biblioteca universitaria

Los fondos de una biblioteca tienen una signatura, un título y un año. Pueden ser libros (ISBN, editorial, número de páginas), revistas (ISSN, periodicidad) o material audiovisual (formato, duración). Los libros pueden ser, además, de referencia (no se prestan) o de préstamo. Los usuarios de la biblioteca pueden ser alumnos, profesores o personal externo autorizado, y solo los alumnos y profesores pueden reservar salas de estudio. Dibuja el diagrama con todas las jerarquías, indicando coberturas y discriminantes, y anota las restricciones que no se puedan dibujar.

Ejercicio 8 (propuesto): Taller de bicicletas

Un taller vende y repara bicicletas. Los clientes del taller pueden ser particulares o clubes ciclistas (que ya existen en una base de datos federativa con su código de club). Las bicicletas pueden ser de carretera, de montaña o eléctricas; las eléctricas pueden ser también de montaña. Decide si necesitas una categoría o una generalización para los clientes y qué cobertura tiene la jerarquía de bicicletas. Justifica cada decisión.

Resumen

Concepto Definición breve Notación del curso
Modelo EER E/R básico + subclases, herencia, categorías y agregación —
Superclase / subclase S ⊆ C: toda ocurrencia del subtipo es ocurrencia del supertipo Hexágono “es un” entre ambos
Relación ES-UN Vínculo entre subtipo y supertipo; mismo objeto, distinto nivel de detalle Líneas del hexágono
Especialización Proceso descendente: de lo general a lo particular —
Generalización Proceso ascendente: de lo particular a lo general —
Herencia El subtipo hereda identificador, atributos y relaciones del supertipo Los heredados no se dibujan en el subtipo
Total / parcial ¿Toda ocurrencia está en algún subtipo? (S1 ∪ … ∪ Sn = C) (t) / (p)
Exclusiva / solapada ¿Puede estar en varios subtipos? (Si ∩ Sj = ∅) (e) / (s)
Discriminante Atributo del supertipo cuyo valor determina el subtipo Etiqueta en la línea supertipo-hexágono
Jerarquía multinivel Un subtipo es supertipo de otros; herencia transitiva Varios hexágonos encadenados
Retícula Subclase compartida con varias superclases y raíz común Subtipo unido a dos hexágonos
Categoría (tipo unión) Subconjunto de la unión de superclases distintas; herencia selectiva Hexágono “∪” con flecha hacia la categoría
Agregación Una relación tratada como entidad para relacionarla con otras subgraph que encierra la relación
Composición Agregación fuerte todo-parte; en E/R, entidad débil Ver módulo 10
Regla de oro Un subtipo necesita atributos, relaciones o restricciones propios Si no, atributo tipo
Navegación  
← Módulo anterior: Entidades débiles Siguiente módulo: Agregación →