Módulo 08: Relaciones reflexivas
Objetivos del módulo
- Definir qué es una relación reflexiva (también llamada unaria, recursiva o autorrelación) y por qué su grado se discute
- Comprender por qué los papeles (roles) son imprescindibles en cada extremo y aprender a nombrarlos
- Dibujar relaciones reflexivas en la notación del curso: dos aristas desde el mismo rectángulo al rombo, cada una con su papel y su cardinalidad
- Leer una relación reflexiva en lenguaje natural en ambos sentidos sin confundir los papeles
- Representar sus ocurrencias con diagramas bipartitos y con grafos de ejemplares
- Modelar reflexivas 1:1 (cónyuges, sucesión en un cargo), 1:N (empleado-jefe y categorías de EMPRESA, comentarios, carpetas) y N:M (prerrequisitos, lista de materiales, seguidores, amistad, rutas)
- Reconocer las estructuras que generan: cadenas, árboles, bosques, grafos dirigidos y no dirigidos
- Anotar como restricciones semánticas la irreflexividad, la aciclicidad, la simetría y la profundidad máxima
- Colocar correctamente los atributos de una relación reflexiva y modelar reflexivas con historial
- No confundir una relación reflexiva con una jerarquía de especialización
- Anticipar cómo se transforman al modelo relacional y cómo se consultan en SQL
1. Qué es una relación reflexiva
1.1. Definición
En el módulo anterior estudiaste las relaciones binarias entre dos tipos de entidad distintos. Pero muchas veces las ocurrencias de una entidad se relacionan con otras ocurrencias de la misma entidad: un empleado es jefe de otros empleados, una asignatura es prerrequisito de otras asignaturas, un usuario sigue a otros usuarios, una categoría contiene otras categorías.
📘 Concepto: Una relación reflexiva (recursive relationship, también relación unaria, recursiva o autorrelación) es una relación en la que un mismo tipo de entidad participa dos veces, desempeñando en cada participación un papel (role) distinto. Formalmente, si E es un tipo de entidad, una relación reflexiva R sobre E es un subconjunto de E × E: cada ocurrencia es un par ordenado (eᵢ, eⱼ) de ocurrencias de E, donde la primera posición corresponde a un papel y la segunda al otro.
💻 Ejemplo: En EMPRESA, la ocurrencia (Marta, Pablo) de la relación dirige significa “Marta (102), en el papel de jefe, dirige a Pablo (120), en el papel de subordinado”. El par (Pablo, Marta) significaría lo contrario, y es falso.
1.2. ¿Grado 1 o grado 2?
Los autores no se ponen de acuerdo en cómo contar el grado, y conviene que conozcas las dos posturas:
| Postura | Cómo cuenta el grado | Grado de una reflexiva | Nombre habitual |
|---|---|---|---|
| Por tipos de entidad distintos que intervienen (tradición española, de Miguel y Piattini) | Un solo tipo de entidad | 1 | Relación unaria o reflexiva |
| Por participaciones o papeles (Elmasri y Navathe, Silberschatz) | Dos participaciones de la misma entidad | 2 | Relación recursiva (binaria) |
Ambas describen exactamente lo mismo. En este curso la llamaremos relación reflexiva y diremos que es “unaria” cuando queramos destacar que solo interviene un tipo de entidad; pero estructuralmente se comporta como una binaria: tiene dos extremos, dos parejas de cardinalidades y un tipo de correspondencia 1:1, 1:N o N:M. Todo lo que aprendiste en el módulo de relaciones binarias se aplica aquí, con una dificultad añadida: los dos extremos están unidos a la misma entidad y solo los distinguen los papeles.
⚠️ Importante: No confundas el nombre “relación reflexiva” del modelo E/R con la propiedad reflexiva de las matemáticas (una relación R es reflexiva si todo elemento se relaciona consigo mismo: a R a). De hecho, la mayoría de las relaciones reflexivas del E/R son justo lo contrario: irreflexivas (nadie es su propio jefe). Lo verás en la sección 7.
1.3. Terminología
| Término | Dónde se usa | Significado |
|---|---|---|
| Relación reflexiva | Modelo E/R (tradición española) | Relación de una entidad consigo misma |
| Relación unaria | Modelo E/R (grado 1) | Sinónimo, contando tipos de entidad |
| Relación recursiva | Modelo E/R (Elmasri, Silberschatz) | Sinónimo, contando participaciones |
| Autorrelación | Uso coloquial y comentarios del script EMPRESA | Sinónimo |
| Clave ajena reflexiva o autorreferenciada | Modelo relacional | Clave ajena que referencia a la propia tabla (EMPLEADOS.jefe_id) |
| Jerarquía | Uso informal | Estructura en árbol que genera una reflexiva 1:N sin ciclos |
2. Los papeles: imprescindibles
2.1. Por qué una reflexiva sin papeles no significa nada
En una relación binaria entre CLIENTE y PEDIDO, cada arista lleva a una entidad distinta y no hay duda de qué significa cada extremo. En una reflexiva, las dos aristas llegan al mismo rectángulo. Observa este diagrama incorrecto:
flowchart LR
EMPLEADO[EMPLEADO] ---|"(0,1)"| dirige{dirige}
EMPLEADO ---|"(0,n)"| dirige
¿Qué dice? Que “un empleado se relaciona con 0..1 empleados” y que “un empleado se relaciona con 0..n empleados”. Pero ¿cuál es el jefe y cuál el subordinado? ¿Tiene cada empleado como mucho un jefe o como mucho un subordinado? El diagrama admite las dos lecturas, que describen organizaciones opuestas. Sin papeles, una reflexiva es ambigua.
⚠️ Importante: En una relación reflexiva es obligatorio indicar el papel de cada extremo. En una binaria entre entidades distintas los papeles son opcionales (el nombre de la entidad ya los indica); en una reflexiva son imprescindibles.
2.2. Notación del curso
Como ya adelantó el módulo 06, cada una de las dos aristas que unen el rectángulo con el rombo lleva una etiqueta con la cardinalidad seguida del papel, por ejemplo "(0,1) jefe":
flowchart LR
EMPLEADO[EMPLEADO] ---|"(0,1) jefe"| dirige{"dirige<br/>1:N"}
EMPLEADO ---|"(0,n) subordinado"| dirige
EMPLEADO --- e_id([<u>emp_id</u>])
EMPLEADO --- e_nombre([nombre])
EMPLEADO --- e_oficio([oficio])
La convención de cardinalidades es la misma de todo el curso, aplicada a papeles en lugar de a entidades:
📘 Concepto: La pareja escrita en la arista del papel P indica con cuántas ocurrencias que desempeñan el papel P se relaciona una ocurrencia que desempeña el otro papel.
- Arista (0,1) jefe: un empleado, en su papel de subordinado, tiene como mínimo 0 y como máximo 1 jefe.
- Arista (0,n) subordinado: un empleado, en su papel de jefe, tiene como mínimo 0 y como máximo n subordinados.
Máximos 1 (en jefe) y n (en subordinado): correspondencia 1:N. El “lado 1” es el papel jefe y el “lado N” el papel subordinado, igual que en una binaria el lado 1 es el padre.
2.3. Cómo leer una reflexiva en los dos sentidos
La plantilla es la de las binarias, pero nombrando el papel de origen:
“Cada ⟨entidad⟩, como ⟨papel origen⟩, ⟨verbo⟩ como mínimo ⟨mín⟩ y como máximo ⟨máx⟩ ⟨papel destino⟩”, donde (mín, máx) es la pareja de la arista del papel destino.
| Sentido | Frase | Pareja leída |
|---|---|---|
| Desde el papel jefe | “Cada empleado, como jefe, dirige de 0 a n subordinados” | Arista subordinado (0,n) |
| Desde el papel subordinado | “Cada empleado, como subordinado, es dirigido por 0 o 1 jefe” | Arista jefe (0,1) |
💡 Consejo: Un truco que evita casi todos los errores: escribe primero la frase “cada subordinado tiene ___ jefes” y pon la respuesta en la arista jefe; luego “cada jefe tiene ___ subordinados” y pon la respuesta en la arista subordinado. Es decir: la cardinalidad va en la arista del papel que estás contando.
2.4. Cómo nombrar los papeles
Reglas prácticas:
- Usa sustantivos que describan la función de la ocurrencia en la relación, en singular y minúsculas: jefe, subordinado, prerrequisito, seguidor.
- Los dos papeles deben ser distintos y, a ser posible, complementarios: el verbo del rombo se lee “⟨papel 1⟩ ⟨verbo⟩ a ⟨papel 2⟩” (“el jefe dirige al subordinado”).
- Evita papeles genéricos como empleado1 / empleado2, salvo en relaciones simétricas, donde no hay forma de distinguir los extremos (sección 6.4).
- No uses el nombre de la entidad como papel (empleado / empleado): no aporta nada.
| Relación | Entidad | Papel 1 | Papel 2 |
|---|---|---|---|
| dirige | EMPLEADO | jefe | subordinado |
| contiene | CATEGORÍA | categoría padre (o supercategoría) | subcategoría |
| responde a | COMENTARIO | original | respuesta |
| contiene | CARPETA | contenedora | subcarpeta |
| sucede a | MANDATO | predecesor | sucesor |
| está casada con | PERSONA | cónyuge A | cónyuge B |
| requiere | ASIGNATURA | dependiente | prerrequisito |
| se compone de | PRODUCTO | compuesto | componente |
| sigue a | USUARIO | seguidor | seguido |
| conecta | CIUDAD | origen | destino |
| es madre de | PERSONA | madre | hijo |
3. Diagramas de ocurrencias de las reflexivas
Hay dos formas de dibujar las ocurrencias de una reflexiva, y cada una sirve para una cosa.
3.1. Diagrama bipartito: el mismo conjunto dibujado dos veces
Se dibuja el conjunto de ocurrencias de la entidad dos veces, una por papel, y se unen con líneas. Es el diagrama de ocurrencias de las binarias y resulta ideal para comprobar las cardinalidades, porque basta con contar líneas en cada lado.
flowchart LR
subgraph S_JEF["EMPLEADO como jefe"]
j100("100 Ana")
j102("102 Marta")
j120("120 Pablo")
j121("121 Raquel")
end
subgraph S_SUB["EMPLEADO como subordinado"]
s100("100 Ana")
s102("102 Marta")
s120("120 Pablo")
s121("121 Raquel")
s122("122 Iván")
end
j100 --- s102
j102 --- s120
j120 --- s121
j120 --- s122
j121 ~~~ s100
Comprobación con los datos de ../recursos/empresa_datos.sql:
- En el lado “subordinado”, cada ejemplar tiene como mucho una línea y Ana (100) ninguna: la arista jefe lleva (0,1). ✔
- En el lado “jefe”, Pablo tiene dos líneas y Raquel ninguna: la arista subordinado lleva (0,n). ✔
3.2. Grafo de ejemplares
Se dibuja cada ocurrencia una sola vez como un nodo, y cada ocurrencia de la relación como una flecha que va del primer papel al segundo (en este módulo, siempre del jefe al subordinado, de la madre al hijo, del compuesto al componente…). Este diagrama muestra la estructura que forman los datos: cadenas, árboles, ciclos… Es el que usaremos más a partir de ahora.
flowchart TB
e100("100 Ana") --> e102("102 Marta")
e102 --> e120("120 Pablo")
e120 --> e121("121 Raquel")
e120 --> e122("122 Iván")
💡 Consejo: En un grafo de ejemplares, la cardinalidad máxima del papel que recibe las flechas se ve en las flechas entrantes (cada subordinado tiene como mucho una flecha entrante: máximo 1 jefe), y la del papel que emite las flechas, en las salientes (un jefe puede tener muchas flechas salientes).
4. Reflexivas 1:1
4.1. Concepto
En una reflexiva 1:1, cada ocurrencia se relaciona como mucho con otra en cada papel. En el grafo de ejemplares, cada nodo tiene como mucho una flecha entrante y una saliente. Las estructuras que aparecen son parejas y cadenas.
4.2. Persona casada con persona
💻 Ejemplo (registro civil simplificado): “Se registra con quién está casada actualmente cada persona. Una persona puede no estar casada y, si lo está, lo está con una sola persona.”
flowchart LR
PERSONA[PERSONA] ---|"(0,1) cónyuge A"| casada{"está casada con<br/>1:1"}
PERSONA ---|"(0,1) cónyuge B"| casada
PERSONA --- pe_dni([<u>dni</u>])
PERSONA --- pe_nombre([nombre])
casada --- ca_fecha([fecha_matrimonio])
- “Cada persona, como cónyuge A, está casada con 0 o 1 cónyuge B” (arista cónyuge B).
- “Cada persona, como cónyuge B, está casada con 0 o 1 cónyuge A” (arista cónyuge A).
flowchart LR
p1("Ana") --- p2("Luis")
p3("Marta") --- p4("Elena")
p5("Jorge")
Esta relación tiene dos particularidades:
- Es simétrica: si Ana está casada con Luis, Luis está casado con Ana. Los papeles cónyuge A y cónyuge B son artificiales (no hay un “primer” cónyuge). Por eso el grafo se dibuja sin flechas (líneas no dirigidas). No se usan papeles como esposo / esposa, que no sirven para los matrimonios entre personas del mismo sexo, legales en España desde 2005.
- Hay que decidir cómo se almacena el par: si se guarda (Ana, Luis), ¿hay que guardar también (Luis, Ana)? Se resuelve con una restricción semántica:
- RS1: Cada matrimonio se registra una sola vez: si existe (a, b) no puede existir (b, a).
- RS2: Una persona no puede estar casada consigo misma.
- RS3: Una persona no puede aparecer a la vez como cónyuge A en un matrimonio y como cónyuge B en otro (si no, tendría dos cónyuges a pesar de las cardinalidades (0,1)).
⚠️ Importante: Fíjate en RS3: en una reflexiva 1:1 simétrica, las cardinalidades (0,1) controlan cada papel por separado, pero no impiden que la misma persona ocupe un papel en un par y el otro papel en otro par. Es una sutileza que solo aparece en las reflexivas.
Si hubiera que registrar los matrimonios pasados (divorcios, viudedad, nuevas nupcias), la relación dejaría de ser 1:1 y el mismo par podría repetirse: se convertiría en una entidad MATRIMONIO (sección 9).
4.3. Relevo en un cargo: predecesor y sucesor
💻 Ejemplo (club deportivo): “Se registran los mandatos de presidencia del club. Cada mandato sucede como mucho a un mandato anterior y es sucedido como mucho por uno posterior. El primer mandato no sucede a ninguno y el actual no tiene sucesor.”
flowchart LR
MANDATO[MANDATO] ---|"(0,1) predecesor"| sucede{"sucede a<br/>1:1"}
MANDATO ---|"(0,1) sucesor"| sucede
MANDATO --- ma_num([<u>num_mandato</u>])
MANDATO --- ma_pres([presidente])
MANDATO --- ma_ini([fecha_inicio])
MANDATO --- ma_fin(["fecha_fin (0,1)"])
- “Cada mandato, como sucesor, sucede como mucho a un predecesor” (arista predecesor (0,1)). El primer mandato no tiene predecesor.
- “Cada mandato, como predecesor, es sucedido como mucho por un sucesor” (arista sucesor (0,1)). El mandato vigente no tiene sucesor.
flowchart LR
m1("M1 1985-1993") --> m2("M2 1993-2001")
m2 --> m3("M3 2001-2013")
m3 --> m4("M4 2013-actual")
La estructura es una cadena (lista enlazada). Fíjate en que la entidad es MANDATO y no PERSONA: si una misma persona fue presidente dos veces, con PERSONA tendría dos sucesores y dos predecesores y la relación no sería 1:1.
Otros ejemplos de reflexivas 1:1 en cadena: VAGÓN va enganchado detrás de VAGÓN, VERSIÓN de un documento sustituye a VERSIÓN, CAPÍTULO va a continuación de CAPÍTULO.
💡 Consejo: Las cadenas tienen restricciones típicas: RS: ningún mandato se sucede a sí mismo; RS: no puede haber ciclos (M4 no puede ser predecesor de M1); RS: el sucesor empieza cuando termina el predecesor. Además, a veces el orden ya se deduce de un atributo (
fecha_inicio): en ese caso la relación sucede a es derivable y podría omitirse. Inclúyela solo si aporta algo que el atributo no da (por ejemplo, si hay mandatos interinos que se solapan).
5. Reflexivas 1:N
5.1. Concepto
En una reflexiva 1:N, cada ocurrencia tiene como mucho un “padre” (papel del lado 1) y puede tener varios “hijos” (papel del lado N). En el grafo, cada nodo tiene como mucho una flecha entrante. Si además no hay ciclos, la estructura es un árbol (una sola raíz) o un bosque (varias raíces). Es, con mucho, el tipo de reflexiva más frecuente.
5.2. Empleado y jefe (esquema EMPRESA)
El script ../recursos/empresa_crear.sql crea la tabla EMPLEADOS con la columna jefe_id, una clave ajena que referencia a la propia tabla (fk_emp_jefe) y que admite nulos. En el E/R procede de esta relación:
flowchart LR
EMPLEADO[EMPLEADO] ---|"(0,1) jefe"| dirige{"dirige<br/>1:N"}
EMPLEADO ---|"(0,n) subordinado"| dirige
EMPLEADO --- e_id([<u>emp_id</u>])
EMPLEADO --- e_nombre([nombre])
EMPLEADO --- e_ape([apellidos])
EMPLEADO --- e_oficio([oficio])
EMPLEADO --- e_sal([salario])
| Pareja | Justificación con los datos de EMPRESA |
|---|---|
| jefe (0,1) | Cada empleado tiene como mucho un jefe directo. La mínima es 0 porque la directora general, Ana García (100), no tiene jefe (jefe_id nulo) |
| subordinado (0,n) | Un empleado puede dirigir a varios (Ana dirige a 5 directores, Luis a 5 empleados de ventas). La mínima es 0 porque la mayoría no dirige a nadie (Carmen, 110, o el becario Tomás, 160) |
El grafo de ejemplares con los 24 empleados es el organigrama de la empresa:
flowchart LR
e100("100 Ana<br/>DIRECTOR GENERAL") --> e101("101 Luis<br/>DIRECTOR")
e100 --> e102("102 Marta<br/>DIRECTOR")
e100 --> e103("103 Pedro<br/>DIRECTOR")
e100 --> e104("104 Laura<br/>DIRECTOR")
e100 --> e105("105 Javier<br/>DIRECTOR")
e101 --> e110("110 Carmen")
e101 --> e111("111 David")
e101 --> e112("112 Elena")
e101 --> e113("113 Sergio")
e101 --> e114("114 Lucía")
e102 --> e120("120 Pablo<br/>ANALISTA")
e102 --> e124("124 Hugo")
e102 --> e160("160 Tomás<br/>BECARIO")
e120 --> e121("121 Raquel")
e120 --> e122("122 Iván")
e120 --> e123("123 Sara")
e103 --> e130("130 Isabel")
e103 --> e131("131 Jorge")
e104 --> e140("140 Nuria")
e104 --> e141("141 Álvaro")
e105 --> e150("150 Rosa")
e105 --> e151("151 Manuel")
e105 --> e152("152 Cristina")
Es un árbol: una sola raíz (Ana), cada nodo con exactamente una flecha entrante salvo la raíz, y sin ciclos. Tiene 4 niveles (profundidad 3): Ana → Marta → Pablo → Raquel.
Restricciones semánticas que el diagrama E/R no expresa y deben anotarse:
- RS1 (irreflexividad): Un empleado no puede ser su propio jefe.
- RS2 (aciclicidad): Ningún empleado puede ser jefe, directo o indirecto, de sí mismo (no puede haber ciclos).
- RS3 (raíz única): Exactamente un empleado no tiene jefe: el director general.
⚠️ Importante: Las cardinalidades (0,1)-(0,n) permiten datos absurdos: que Raquel sea jefa de Pablo y Pablo jefe de Raquel a la vez (cada uno tiene un solo jefe, así que las cardinalidades se cumplen), o que Hugo sea su propio jefe. Solo las restricciones semánticas RS1 y RS2 los prohíben. Toda reflexiva jerárquica necesita estas restricciones anotadas.
5.3. Categoría y subcategoría (esquema EMPRESA)
La tabla CATEGORIAS tiene la columna categoria_padre_id, que referencia a la propia tabla (fk_cat_padre). Procede de esta relación:
flowchart LR
CATEGORIA[CATEGORÍA] ---|"(0,1) padre"| contiene{"contiene<br/>1:N"}
CATEGORIA ---|"(0,n) subcategoría"| contiene
CATEGORIA --- c_id([<u>categoria_id</u>])
CATEGORIA --- c_nombre([nombre])
- “Cada categoría, como subcategoría, está contenida en como mucho una categoría padre” (arista padre (0,1)). Las categorías principales no tienen padre.
- “Cada categoría, como padre, contiene ninguna, una o varias subcategorías” (arista subcategoría (0,n)).
Con los datos de EMPRESA:
flowchart TB
c1("1 Informática") --> c2("2 Portátiles")
c1 --> c3("3 Ordenadores sobremesa")
c1 --> c4("4 Periféricos")
c4 --> c5("5 Ratones y teclados")
c4 --> c6("6 Monitores")
c7("7 Electrónica") --> c8("8 Telefonía")
c7 --> c9("9 Audio")
c10("10 Oficina") --> c11("11 Mobiliario")
Aquí la estructura no es un árbol sino un bosque: hay tres raíces (Informática, Electrónica y Oficina). A diferencia de los empleados, en las categorías no tiene sentido exigir una raíz única. Fíjate también en que los productos se asignan a categorías de cualquier nivel: en EMPRESA el “Disco SSD 1TB” está en Informática (nivel 1) y el “Ratón inalámbrico”, en Ratones y teclados (nivel 3).
💡 Consejo: Si quisieras que existiera una sola raíz, podrías crear una categoría ficticia “Todas” y colgar de ella las tres principales. Es una técnica habitual en catálogos, pero es una decisión de diseño que hay que documentar.
5.4. Comentario y respuesta
💻 Ejemplo (foro o red social): “Los usuarios publican comentarios en una publicación. Un comentario puede ser respuesta a otro comentario, que a su vez puede ser respuesta de otro, sin límite. Un comentario puede tener muchas respuestas.”
flowchart LR
COMENTARIO[COMENTARIO] ---|"(0,1) original"| responde{"responde a<br/>1:N"}
COMENTARIO ---|"(0,n) respuesta"| responde
COMENTARIO --- co_id([<u>id_comentario</u>])
COMENTARIO --- co_texto([texto])
COMENTARIO --- co_fecha([fecha_hora])
PUBLICACION[PUBLICACIÓN] ---|"(1,1)"| tiene{"recibe<br/>1:N"}
tiene ---|"(0,n)"| COMENTARIO
PUBLICACION --- pu_id([<u>id_publicacion</u>])
flowchart TB
k1("C1: ¡Gran artículo!") --> k2("C2: Totalmente de acuerdo")
k1 --> k3("C3: No estoy de acuerdo")
k3 --> k4("C4: ¿Por qué?")
k4 --> k5("C5: Porque...")
k6("C6: ¿Hay segunda parte?")
Es un bosque: cada comentario “de primer nivel” (C1, C6) es la raíz de un hilo de conversación. La relación con PUBLICACIÓN es una binaria normal, pero ambas relaciones interactúan:
- RS1: Una respuesta debe pertenecer a la misma publicación que el comentario original al que responde.
- RS2: Un comentario no puede responderse a sí mismo ni formar ciclos.
- RS3 (opcional): La fecha de una respuesta es posterior a la de su original. Esta regla, por cierto, garantiza por sí sola la aciclicidad: si cada respuesta es posterior a su original, es imposible volver a un comentario anterior.
5.5. Carpeta y subcarpeta
💻 Ejemplo (gestor documental): “Las carpetas se organizan en árbol: cada carpeta está dentro de otra, salvo la carpeta raíz. Cada archivo está en una carpeta.”
flowchart LR
CARPETA[CARPETA] ---|"(0,1) contenedora"| dentro{"contiene<br/>1:N"}
CARPETA ---|"(0,n) subcarpeta"| dentro
CARPETA ---|"(1,1)"| guarda{"guarda<br/>1:N"}
guarda ---|"(0,n)"| ARCHIVO[ARCHIVO]
CARPETA --- ca_id([<u>id_carpeta</u>])
CARPETA --- ca_nombre([nombre])
ARCHIVO --- ar_id([<u>id_archivo</u>])
ARCHIVO --- ar_nombre([nombre])
ARCHIVO --- ar_tam([tamanyo])
flowchart TB
r("/") --> d1("Documentos")
r --> d2("Imágenes")
d1 --> d3("Facturas")
d1 --> d4("Contratos")
d3 --> d5("2026")
- RS1: Existe exactamente una carpeta raíz (la única sin contenedora).
- RS2: No puede haber ciclos (una carpeta no puede estar dentro de sí misma, directa o indirectamente). Por eso los sistemas operativos impiden mover una carpeta dentro de una de sus subcarpetas.
- RS3: Dos subcarpetas de la misma carpeta no pueden tener el mismo nombre. Fíjate en que el
nombreno es identificador de CARPETA (hay muchas carpetas “2026”), pero sí lo es combinado con la carpeta contenedora. Es la idea de identificación por dependencia que estudiarás en el módulo de entidades débiles.
5.6. Varias reflexivas sobre la misma entidad: madre y padre
Igual que entre dos entidades distintas puede haber varias relaciones (lo viste en el módulo de relaciones binarias), una entidad puede tener varias relaciones reflexivas, una por significado.
💻 Ejemplo (genealogía): “De cada persona se registra, si se conocen, su madre y su padre biológicos.”
flowchart LR
PERSONA[PERSONA] ---|"(0,1) madre"| madre_de{"es madre de<br/>1:N"}
PERSONA ---|"(0,n) hijo"| madre_de
PERSONA ---|"(0,1) padre"| padre_de{"es padre de<br/>1:N"}
PERSONA ---|"(0,n) hijo"| padre_de
PERSONA --- pe_id([<u>id_persona</u>])
PERSONA --- pe_nombre([nombre])
PERSONA --- pe_nac([fecha_nacimiento])
- La mínima de madre y padre es 0 porque en un árbol genealógico no se conocen los ascendientes de las personas más antiguas, aunque biológicamente todo el mundo tiene madre y padre. El diagrama modela lo que se registra, no la biología.
- RS1: La madre y el padre de una persona son personas distintas entre sí y distintas de ella.
- RS2: La fecha de nacimiento de la madre y del padre es anterior a la del hijo (lo que, de nuevo, impide los ciclos).
Fíjate en que cada relación por separado forma un bosque, pero las dos juntas forman un grafo más complejo (un árbol genealógico no es un árbol en sentido matemático: cada persona tiene dos ascendientes).
💡 Consejo: ¿Una relación “es progenitor de” con (0,2) en la arista progenitor no sería más sencilla? Sí, pero perdería la distinción entre madre y padre y no garantizaría que no haya “dos madres biológicas”. Es el mismo razonamiento que local/visitante del módulo anterior: papeles distintos, relaciones distintas.
6. Reflexivas N:M
6.1. Concepto
En una reflexiva N:M, cada ocurrencia puede relacionarse con varias en cada papel. En el grafo de ejemplares un nodo puede tener muchas flechas entrantes y salientes: la estructura es un grafo dirigido general (o no dirigido, si la relación es simétrica). Son las reflexivas más expresivas y las que más restricciones necesitan.
6.2. Asignatura prerrequisito de asignatura
💻 Ejemplo (plan de estudios): “Para matricularse de una asignatura hay que haber aprobado antes sus prerrequisitos, que pueden ser varios. Una asignatura puede ser prerrequisito de varias. De cada prerrequisito se indica si es obligatorio o solo recomendado.”
flowchart LR
ASIGNATURA[ASIGNATURA] ---|"(0,n) prerrequisito"| requiere{"requiere<br/>N:M"}
ASIGNATURA ---|"(0,n) dependiente"| requiere
ASIGNATURA --- as_cod([<u>codigo</u>])
ASIGNATURA --- as_nombre([nombre])
ASIGNATURA --- as_curso([curso])
requiere --- rq_tipo([tipo])
- “Cada asignatura, como dependiente, requiere ninguno, uno o varios prerrequisitos” (arista prerrequisito (0,n)).
- “Cada asignatura, como prerrequisito, es requerida por ninguna, una o varias asignaturas dependientes” (arista dependiente (0,n)).
- El atributo
tipo(‘OBLIGATORIO’ / ‘RECOMENDADO’) depende del par: es atributo de la relación.
Grafo de ejemplares (la flecha va del prerrequisito a la asignatura que lo exige):
flowchart LR
prog1("Programación I") --> prog2("Programación II")
prog2 --> edd("Estructuras de Datos")
mat("Matemática Discreta") --> edd
edd --> bd("Bases de Datos")
prog2 --> bd
bd --> bda("BD Avanzadas")
so("Sistemas Operativos") --> bda
Es un grafo dirigido acíclico (DAG, directed acyclic graph): una asignatura puede tener varios prerrequisitos (Bases de Datos requiere Estructuras de Datos y Programación II) y ser prerrequisito de varias, pero nunca puede haber ciclos (si BD requiere ED y ED requiriese BD, nadie podría matricularse de ninguna).
- RS1: Una asignatura no puede ser prerrequisito de sí misma.
- RS2: El grafo de prerrequisitos no puede contener ciclos.
- RS3 (recomendable): Un prerrequisito debe impartirse en un curso anterior o igual al de la asignatura que lo requiere (garantiza RS2 si es “anterior”).
⚠️ Importante: Observa que Programación II → Estructuras de Datos → Bases de Datos, y además Programación II → Bases de Datos directamente. ¿Es redundante esa flecha directa? Depende del significado: si “requiere” significa “requiere directamente”, es un dato válido (el plan exige expresamente las dos). Pero no se deben almacenar los prerrequisitos indirectos (que BDA requiere, a través de BD, Programación I): se deducen recorriendo el grafo (cierre transitivo). Almacenarlos sería redundancia.
6.3. Producto compuesto de productos: la lista de materiales (BOM)
La lista de materiales (bill of materials, BOM) es el ejemplo clásico de reflexiva N:M en la industria: un producto se fabrica a partir de otros productos (componentes), que a su vez se componen de otros.
💻 Ejemplo (fábrica de bicicletas): “Una bicicleta se compone de 1 cuadro, 2 ruedas y 1 sillín. Cada rueda se compone de 1 llanta, 32 radios y 1 cubierta. Un mismo componente (los radios) se usa en varios productos.”
flowchart LR
PRODUCTO[PRODUCTO] ---|"(0,n) compuesto"| compone{"se compone de<br/>N:M"}
PRODUCTO ---|"(0,n) componente"| compone
PRODUCTO --- pr_ref([<u>referencia</u>])
PRODUCTO --- pr_desc([descripcion])
PRODUCTO --- pr_coste([coste_unitario])
compone --- co_cant([cantidad])
- “Cada producto, como compuesto, se compone de ninguno o varios componentes” (arista componente (0,n)). Los productos básicos (radio, llanta) no se componen de nada.
- “Cada producto, como componente, forma parte de ninguno o varios compuestos” (arista compuesto (0,n)). La bicicleta terminada no forma parte de nada; los radios forman parte de la rueda delantera y de la trasera de varios modelos.
cantidaddepende del par (la rueda lleva 32 radios; otra rueda podría llevar 28): atributo de la relación.
flowchart LR
bici("Bicicleta urbana") -->|"1"| cuadro("Cuadro")
bici -->|"2"| rueda("Rueda 28 pulgadas")
bici -->|"1"| sillin("Sillín")
rueda -->|"1"| llanta("Llanta")
rueda -->|"32"| radio("Radio")
rueda -->|"1"| cubierta("Cubierta")
infantil("Bicicleta infantil") -->|"2"| rueda16("Rueda 16 pulgadas")
rueda16 -->|"20"| radio
La etiqueta de cada flecha es el atributo cantidad. A partir del grafo se calcula la explosión de materiales: para fabricar una bicicleta urbana hacen falta 2 ruedas × 32 radios = 64 radios. Ese cálculo multiplica las cantidades a lo largo de cada camino y suma los caminos: es un cálculo derivado que no se almacena.
Restricciones semánticas:
- RS1: Un producto no puede ser componente de sí mismo, ni directa ni indirectamente (aciclicidad).
- RS2: La cantidad es un entero mayor que 0.
📘 Concepto: La BOM es un DAG con pesos en las aristas. A diferencia de un árbol, un mismo componente (el radio) puede aparecer bajo varios compuestos: por eso es N:M y no 1:N. Si cada componente perteneciera a un único compuesto, sería un árbol (reflexiva 1:N) y la cantidad podría migrar a la entidad.
6.4. Usuario sigue a usuario (asimétrica) y amistad (simétrica)
Seguimiento: relación asimétrica.
💻 Ejemplo (red social de microblogging): “Un usuario puede seguir a otros usuarios, sin necesidad de que le sigan a él. Se guarda desde cuándo le sigue.”
flowchart LR
USUARIO[USUARIO] ---|"(0,n) seguidor"| sigue{"sigue a<br/>N:M"}
USUARIO ---|"(0,n) seguido"| sigue
USUARIO --- us_login([<u>login</u>])
USUARIO --- us_nombre([nombre_visible])
sigue --- si_desde([fecha_desde])
flowchart LR
ana("@ana") --> luis("@luis")
luis --> ana
ana --> marta("@marta")
jorge("@jorge") --> marta
luis --> marta
Que Ana siga a Luis no implica que Luis siga a Ana (aunque aquí sí ocurre). Cada sentido es una ocurrencia distinta: (Ana, Luis) y (Luis, Ana) son pares diferentes y pueden tener fecha_desde distintas. El grafo es dirigido y puede tener ciclos, y eso es correcto: no hay ninguna razón para prohibirlos.
- RS1: Un usuario no puede seguirse a sí mismo.
Amistad: relación simétrica.
💻 Ejemplo (red social de amistades): “Dos usuarios pueden ser amigos. La amistad es mutua.”
Si se modela igual que el seguimiento, aparecen los problemas de la sección 4.2: los papeles son artificiales (amigo A, amigo B) y hay que decidir si se guarda cada amistad una vez o dos.
flowchart LR
USUARIO[USUARIO] ---|"(0,n) amigo A"| amigo{"es amigo de<br/>N:M"}
USUARIO ---|"(0,n) amigo B"| amigo
USUARIO --- us_login([<u>login</u>])
amigo --- am_desde([fecha_desde])
flowchart LR
ana("@ana") --- luis("@luis")
ana --- marta("@marta")
luis --- marta
marta --- jorge("@jorge")
Dos políticas de almacenamiento, que deben anotarse como restricción semántica:
| Política | Qué se guarda | Ventaja | Inconveniente |
|---|---|---|---|
| Una vez, con un orden canónico | Solo (a, b) con a < b (por ejemplo, por login) | Sin duplicados; cada amistad es una ocurrencia | Para saber los amigos de X hay que buscar X en los dos papeles |
| Dos veces | (a, b) y (b, a) | Consultas sencillas: los amigos de X son los B de los pares (X, B) | Duplicación; hay que garantizar que siempre se insertan y borran ambos pares |
- RS1: Nadie es amigo de sí mismo.
- RS2: Cada amistad se registra una sola vez, con el login de amigo A alfabéticamente menor que el de amigo B (política “una vez”).
💡 Consejo: Una tercera solución elegante es reificar la amistad: una entidad AMISTAD unida a USUARIO por una relación binaria con cardinalidad (2,2) junto a USUARIO (“cada amistad une exactamente a 2 usuarios”) y (0,n) junto a AMISTAD. Desaparecen los papeles artificiales y la simetría es natural. Es útil si la amistad tiene más datos (fecha, quién la propuso, estado de la solicitud).
💻 Ejemplo: Muchas redes combinan ambas: una solicitud de amistad es asimétrica (solicitante / solicitado, con atributo
estado: ‘PENDIENTE’, ‘ACEPTADA’, ‘RECHAZADA’), y la amistad es la parte simétrica que se obtiene de las solicitudes aceptadas.
6.5. Rutas entre ciudades con distancia
💻 Ejemplo (empresa de transporte): “Se registran las conexiones directas por carretera entre ciudades, con la distancia en kilómetros y el tiempo estimado. Hay ciudades sin conexiones registradas todavía.”
flowchart LR
CIUDAD[CIUDAD] ---|"(0,n) origen"| conecta{"conecta con<br/>N:M"}
CIUDAD ---|"(0,n) destino"| conecta
CIUDAD --- ci_cod([<u>cod_ciudad</u>])
CIUDAD --- ci_nombre([nombre])
conecta --- cn_km([distancia_km])
conecta --- cn_min([minutos_estimados])
flowchart LR
vlc("Valencia") -->|"355 km"| mad("Madrid")
mad -->|"355 km"| vlc
vlc -->|"350 km"| bcn("Barcelona")
bcn -->|"350 km"| vlc
mad -->|"315 km"| zgz("Zaragoza")
zgz -->|"300 km"| bcn
Aquí la cuestión clave es si la relación es dirigida o no:
- Si las conexiones son de doble sentido y simétricas (misma distancia y tiempo), la relación es simétrica: se guarda cada conexión una vez y se anota la RS correspondiente, como en la amistad.
-
Si cada sentido puede ser distinto (una autopista de peaje en un sentido, obras en el otro, un vuelo o una línea de autobús que solo va en una dirección), la relación es asimétrica y cada sentido es una ocurrencia: el grafo es dirigido y con pesos. En el ejemplo, de Madrid a Zaragoza no se ha registrado la vuelta.
- RS1: Una ciudad no conecta consigo misma.
- RS2:
distancia_kmyminutos_estimadosson mayores que 0.
📘 Concepto: Con esta relación se puede calcular el camino más corto entre dos ciudades sin conexión directa (Valencia → Zaragoza), un problema clásico de grafos. Ese cálculo no se almacena: se deduce. Lo que se almacena son solo las conexiones directas.
7. Estructuras que representan y restricciones semánticas
7.1. Del tipo de correspondencia a la estructura
| Correspondencia | Entradas por nodo | Salidas por nodo | Estructura (sin ciclos) | Estructura (con ciclos) | Ejemplos |
|---|---|---|---|---|---|
| 1:1 | ≤ 1 | ≤ 1 | Parejas y cadenas | Anillos (cadena cerrada) | Cónyuges, mandatos, vagones |
| 1:N | ≤ 1 | Varias | Árbol (una raíz) o bosque (varias) | Como mucho un ciclo por componente conexa | Jefes, categorías, carpetas, comentarios |
| N:M | Varias | Varias | Grafo dirigido acíclico (DAG) | Grafo dirigido general | Prerrequisitos, BOM / Seguidores, rutas |
| N:M simétrica | — | — | Grafo no dirigido | Grafo no dirigido | Amistad, carreteras de doble sentido |
7.2. Vocabulario de las jerarquías
Cuando una reflexiva 1:N forma un árbol (o un bosque) se usa este vocabulario, que aparecerá también en las consultas jerárquicas de SQL:
| Término | Definición | En el organigrama de EMPRESA |
|---|---|---|
| Raíz | Nodo sin padre | Ana (100) |
| Hoja | Nodo sin hijos | Carmen (110), Raquel (121), Tomás (160)… |
| Nivel | Distancia a la raíz + 1 | Ana: 1; Marta: 2; Pablo: 3; Raquel: 4 |
| Profundidad (o altura) del árbol | Número de niveles − 1 (algunos autores la cuentan como el número de niveles) | 4 niveles: profundidad 3 |
| Ascendientes (antecesores) | Padre, padre del padre… hasta la raíz | De Raquel: Pablo, Marta, Ana |
| Descendientes | Hijos, hijos de los hijos… | De Marta: Pablo, Hugo, Tomás, Raquel, Iván, Sara |
| Hermanos | Nodos con el mismo padre | Raquel, Iván y Sara |
| Subárbol | Un nodo con todos sus descendientes | El departamento de Informática bajo Marta |
7.3. Propiedades matemáticas de una relación reflexiva
Como una reflexiva es una relación matemática R sobre un conjunto E, puede tener (o no) estas propiedades, que conviene anotar explícitamente porque las cardinalidades no las expresan:
| Propiedad | Definición | Ejemplo que la cumple | Ejemplo que no |
|---|---|---|---|
| Irreflexiva | Ningún elemento se relaciona consigo mismo: no existe (a, a) | dirige, sigue a, requiere | — (casi todas deben serlo) |
| Simétrica | Si (a, b) entonces (b, a) | es amigo de, está casada con | sigue a |
| Antisimétrica | Si (a, b) y a ≠ b, entonces no (b, a) | dirige, requiere, se compone de | sigue a (puede haber seguimiento mutuo) |
| Transitiva | Si (a, b) y (b, c) entonces (a, c) | es antecesor de (directo o indirecto) | dirige (directo) |
| Acíclica | No existe un camino que vuelva al nodo de partida | dirige, requiere, contiene (carpetas) | sigue a, conecta con |
⚠️ Importante: Las relaciones del E/R deben almacenar normalmente la relación directa (jefe inmediato, prerrequisito directo, componente directo). La relación transitiva (“es jefe directo o indirecto de”, “es prerrequisito indirecto de”) se deduce recorriendo la jerarquía. Modelarla además como otra relación sería redundante.
7.4. Los ciclos y la autorrelación
Las cardinalidades no impiden ninguno de estos datos, que son absurdos en una jerarquía de empleados:
flowchart LR
subgraph S_AUTO["Autorrelación"]
h124("124 Hugo") --> h124
end
subgraph S_CICLO["Ciclo"]
c121("121 Raquel") --> c122("122 Iván")
c122 --> c123("123 Sara")
c123 --> c121
end
- Hugo como jefe de sí mismo: el par (Hugo, Hugo) cumple (0,1) y (0,n).
- Raquel jefa de Iván, Iván jefe de Sara y Sara jefa de Raquel: cada uno tiene exactamente un jefe, así que las cardinalidades se cumplen. Pero ninguno de los tres “cuelga” de la directora general.
Por eso, para cada reflexiva, debes decidir y anotar qué se permite:
| Restricción | Cuándo aplicarla | Cómo se escribe |
|---|---|---|
| Irreflexividad | Casi siempre | “RS: Un X no puede ⟨verbo⟩ a sí mismo” |
| Aciclicidad | Jerarquías, composición, prerrequisitos, contención | “RS: Ningún X puede ser ⟨papel⟩ directo o indirecto de sí mismo” |
| Simetría (y política de almacenamiento) | Amistad, matrimonio, conexiones de doble sentido | “RS: La relación es simétrica; cada par se registra una sola vez con a < b” |
| Raíz única | Organigramas, sistemas de ficheros | “RS: Existe exactamente un X sin ⟨papel padre⟩” |
| Profundidad máxima | Catálogos o estructuras con límite de niveles | “RS: La jerarquía tiene como máximo 3 niveles” |
| Coherencia con otras relaciones | Respuestas en la misma publicación, jefe en el mismo departamento | “RS: El jefe de un empleado pertenece a su mismo departamento o es el director general” |
💡 Consejo: En Oracle, la irreflexividad se puede imponer con una sencilla restricción
CHECKque compare dos columnas de la misma fila (por ejemplo, quejefe_idsea distinto deemp_id), y la verás en el módulo de restricciones de integridad. La aciclicidad y la profundidad máxima, en cambio, afectan a muchas filas a la vez y no se pueden expresar con unCHECK: requieren lógica en la aplicación o disparadores (PL/SQL, ver el Curso de Oracle PL/SQL). Una alternativa muy usada para garantizar la aciclicidad es una regla de orden, como “la fecha de la respuesta es posterior a la del original” o “el prerrequisito es de un curso anterior”.
7.5. Profundidad de la jerarquía: ¿reflexiva o una entidad por nivel?
Una jerarquía se puede modelar de dos maneras:
Opción A: una entidad por nivel, unidas por relaciones binarias 1:N.
flowchart LR
COMUNIDAD[COMUNIDAD_AUTONOMA] ---|"(1,1)"| r1{"comprende<br/>1:N"}
r1 ---|"(1,n)"| PROVINCIA[PROVINCIA]
PROVINCIA ---|"(1,1)"| r2{"comprende<br/>1:N"}
r2 ---|"(1,n)"| MUNICIPIO[MUNICIPIO]
Opción B: una sola entidad con una reflexiva.
flowchart LR
ZONA[ZONA] ---|"(0,1) zona superior"| r3{"comprende<br/>1:N"}
ZONA ---|"(0,n) zona inferior"| r3
ZONA --- z_cod([<u>cod_zona</u>])
ZONA --- z_nombre([nombre])
ZONA --- z_tipo([tipo])
| Criterio | Favorece una entidad por nivel (A) | Favorece la reflexiva (B) |
|---|---|---|
| Número de niveles | Fijo y conocido (3 en la división territorial) | Variable o desconocido (categorías, carpetas, organigramas) |
| Atributos | Cada nivel tiene atributos distintos (la comunidad tiene parlamento; el municipio, código postal) | Todos los niveles tienen los mismos atributos |
| Relaciones con otras entidades | Cada nivel se relaciona con entidades distintas | Todos los niveles se relacionan igual (un producto puede ir a cualquier categoría) |
| Cardinalidades | Pueden ser distintas en cada nivel (toda provincia tiene municipios: (1,n)) | Iguales para todos los niveles |
| Evolución | El número de niveles no cambiará | Se pueden añadir niveles sin tocar el esquema |
⚠️ Importante: Un error frecuente es modelar una jerarquía de profundidad variable con una entidad por nivel: CATEGORÍA, SUBCATEGORÍA, SUBSUBCATEGORÍA… El día que el negocio necesite un cuarto nivel, hay que cambiar el esquema. El error contrario (una reflexiva para una jerarquía fija con niveles muy distintos) obliga a añadir un atributo
tipoy muchas restricciones semánticas para controlar qué puede ir debajo de qué.
8. Atributos de relación en reflexivas
Las reglas son las mismas que en las binarias (módulo de relaciones binarias), con una particularidad: como las dos entidades son la misma, “migrar al lado N” significa migrar a la propia entidad, como atributo de la ocurrencia que desempeña el papel del lado N.
| Correspondencia | ¿Dónde puede ir el atributo? | Ejemplo |
|---|---|---|
| 1:1 | En la relación, o en la entidad (como atributo de uno de los dos papeles, con nulos) | fecha_matrimonio en está casada con |
| 1:N | En la relación, o en la entidad como atributo del papel N (el hijo) | fecha_desde en dirige: “desde cuándo tiene a su jefe actual” → atributo del subordinado |
| N:M | Solo en la relación | cantidad en la BOM, distancia_km en conecta con, tipo en requiere, fecha_desde en sigue a |
💻 Ejemplo: En dirige (1:N), el atributo
fecha_desde(desde cuándo tiene un empleado a su jefe actual) tiene un único valor por subordinado, porque cada empleado tiene como mucho un jefe. Puede ser un atributo de EMPLEADO, pero entonces debe llamarse con claridad, por ejemplofecha_jefe_actual, porquefecha_desdea secas en EMPLEADO no se entiende. No puede ser un atributo del jefe: Pablo tiene tres subordinados, cada uno con su fecha.
⚠️ Importante: En la BOM,
cantidadno puede ir en PRODUCTO: la rueda tiene 32 radios, pero el radio aparece también en la rueda de 16 pulgadas con cantidad 20. Ni el compuesto ni el componente determinan por sí solos la cantidad: la determina el par.
9. Reflexivas con historial
9.1. El problema
La relación dirige de EMPRESA guarda el jefe actual. ¿Y si el negocio necesita saber quién fue el jefe de cada empleado en cada periodo? Ocurre lo mismo que con las binarias: si Iván tuvo como jefe a Pablo, luego a Hugo y luego otra vez a Pablo, el par (Pablo, Iván) se repite en el tiempo y una relación (que es un conjunto de pares) no puede almacenarlo dos veces.
9.2. Solución: reificar la relación reflexiva
Se crea una entidad (aquí, SUPERVISIÓN) con los datos del periodo, unida a EMPLEADO por dos relaciones binarias, una por cada papel:
flowchart LR
EMPLEADO[EMPLEADO] ---|"(1,1)"| ejerce{"ejerce como jefe<br/>1:N"}
ejerce ---|"(0,n)"| SUPERVISION[SUPERVISIÓN]
EMPLEADO ---|"(1,1)"| recibe{"es supervisado en<br/>1:N"}
recibe ---|"(0,n)"| SUPERVISION
SUPERVISION --- su_id([<u>id_supervision</u>])
SUPERVISION --- su_ini([fecha_inicio])
SUPERVISION --- su_fin(["fecha_fin (0,1)"])
EMPLEADO --- e_id([<u>emp_id</u>])
- Cada supervisión tiene exactamente un jefe (1,1) y exactamente un subordinado (1,1).
- Un empleado ejerce de jefe en 0 o más supervisiones (0,n) y es supervisado en 0 o más (0,n).
fecha_fines opcional: la supervisión vigente aún no ha terminado.
Restricciones semánticas:
- RS1: El jefe y el subordinado de una supervisión son empleados distintos.
- RS2: Los periodos de supervisión de un mismo subordinado no se solapan (en cada fecha tiene como mucho un jefe; así se conserva el “1” de la 1:N original).
- RS3:
fecha_fin, si existe, es posterior o igual afecha_inicio. - RS4: En ninguna fecha puede haber ciclos de supervisión.
Observa que la reflexiva ha desaparecido del diagrama: ahora son dos binarias entre EMPLEADO y SUPERVISIÓN. Los papeles se han convertido en los nombres de las dos relaciones.
9.3. Actual más histórico
Un diseño muy habitual conserva ambas cosas: la reflexiva dirige con el jefe actual (consulta inmediata, sin fechas) y la entidad SUPERVISIÓN con la historia. En ese caso hay que añadir una restricción de coherencia:
- RS5: El jefe actual de un empleado (relación dirige) coincide con el jefe de su supervisión sin
fecha_fin.
💡 Consejo: El mismo patrón sirve para el matrimonio con historial: una entidad MATRIMONIO con
fecha_celebracionyfecha_disolucion (0,1), unida a PERSONA por una relación con (2,2) junto a PERSONA (cada matrimonio une a exactamente dos personas) y (0,n) junto a MATRIMONIO (una persona puede haberse casado varias veces), más la restricción “una persona no puede tener dos matrimonios vigentes a la vez”.
10. Reflexiva frente a jerarquía de especialización
10.1. Dos “jerarquías” muy distintas
La palabra “jerarquía” se usa para dos conceptos del modelo E/R extendido que no tienen nada que ver:
| Relación reflexiva 1:N | Jerarquía de especialización/generalización | |
|---|---|---|
| Qué relaciona | Ocurrencias de una entidad con otras ocurrencias de la misma entidad | Tipos de entidad: un subtipo es un subconjunto del supertipo |
| Pregunta que responde | “¿Quién es el jefe de Pablo?”, “¿qué subcategorías tiene Periféricos?” | “¿Qué tipos de empleado hay y qué atributos propios tiene cada uno?” |
| Se lee | “Marta dirige a Pablo” (dos ocurrencias distintas) | “Un comercial es un empleado” (la misma ocurrencia vista como subtipo) |
| Cambia | Al insertar o modificar datos (cambiar de jefe) | Al modificar el esquema (añadir un subtipo) |
| Notación | Rombo con dos aristas al mismo rectángulo | Hexágono “es un” con cobertura (total/parcial, exclusiva/solapada) |
| Herencia de atributos | No: cada ocurrencia tiene sus propios valores | Sí: el subtipo hereda los atributos del supertipo |
💻 Ejemplo: “Portátiles es una subcategoría de Informática” es un dato: la categoría 2 tiene como padre a la 1 (reflexiva). Pero “un portátil es un producto que además tiene pulgadas, autonomía y peso” es un tipo: PORTÁTIL sería un subtipo de PRODUCTO con atributos propios (especialización). Una tienda puede tener las dos cosas a la vez sin que se mezclen.
10.2. Cuando se combinan
A veces el papel de una reflexiva solo puede desempeñarlo un subtipo:
💻 Ejemplo: “Los empleados pueden ser técnicos o directivos. Cada técnico está supervisado por un directivo.”
En este caso no hay reflexiva: la relación es binaria entre el subtipo DIRECTIVO y el subtipo TÉCNICO, porque los dos papeles los desempeñan tipos distintos. Si en cambio “cualquier empleado puede tener un jefe que sea directivo”, la relación sería binaria entre DIRECTIVO (papel jefe) y EMPLEADO (papel subordinado). Solo cuando cualquier ocurrencia puede desempeñar cualquiera de los dos papeles la relación es reflexiva sobre la entidad completa. Lo estudiarás con detalle en el módulo de generalización y especialización.
flowchart TB
EMPLEADO[EMPLEADO] --- j{{"es un<br/>(total, exclusiva)"}}
j --- DIRECTIVO[DIRECTIVO]
j --- TECNICO[TÉCNICO]
DIRECTIVO ---|"(1,1)"| supervisa{"supervisa<br/>1:N"}
supervisa ---|"(0,n)"| TECNICO
11. Avance: paso al modelo relacional y consultas en SQL
11.1. Transformación
En el módulo de transformación E/R → relacional (módulo 17) verás las reglas con detalle. Como anticipo, una reflexiva se transforma como una binaria, con la peculiaridad de que las dos claves apuntan a la misma tabla y deben tomar el nombre de los papeles:
| Correspondencia | Transformación | Ejemplo |
|---|---|---|
| 1:N | Clave ajena en la propia tabla, con el nombre del papel del lado 1 | EMPLEADOS.jefe_id, CATEGORIAS.categoria_padre_id |
| 1:1 | Clave ajena en la propia tabla con UNIQUE | MANDATOS.predecesor_id (única) |
| N:M | Tabla intermedia con dos claves ajenas a la misma tabla, una por papel | PRERREQUISITOS (asignatura_id, prerrequisito_id, tipo) |
Con la notación del curso, las dos reflexivas de EMPRESA:
EMPLEADOS (emp_id, nombre, apellidos, email, telefono (N), fecha_alta, oficio, salario, comision (N), jefe_id (N), dept_id (N))
- jefe_id → EMPLEADOS(emp_id)
- dept_id → DEPARTAMENTOS(dept_id)
- UK: email
CATEGORIAS (categoria_id, nombre, categoria_padre_id (N))
- categoria_padre_id → CATEGORIAS(categoria_id)
- UK: nombre
Y una N:M reflexiva, la lista de materiales:
PRODUCTOS_BOM (referencia, descripcion, coste_unitario)
COMPOSICION (*compuesto_ref*, *componente_ref*, cantidad)
- compuesto_ref → PRODUCTOS_BOM(referencia)
- componente_ref → PRODUCTOS_BOM(referencia)
En el grafo relacional, la reflexiva 1:N aparece como una flecha que sale de una tabla y vuelve a ella:
flowchart RL
EMPLEADOS -->|jefe_id| EMPLEADOS
CATEGORIAS -->|categoria_padre_id| CATEGORIAS
COMPOSICION -->|compuesto_ref| PRODUCTOS_BOM
COMPOSICION -->|componente_ref| PRODUCTOS_BOM
⚠️ Importante: La mínima 0 del papel jefe es la que permite que
jefe_idadmita nulos. Si fuera (1,1), ¡ningún empleado podría darse de alta el primero! Siempre que haya una jerarquía, alguien tiene que ser la raíz, así que la mínima del papel padre en una reflexiva 1:N es casi siempre 0.
11.2. Consultas
Las reflexivas exigen técnicas de consulta específicas que estudiarás en el bloque de DML. Aquí solo te anticipamos cuáles son:
| Pregunta | Técnica SQL | Dónde se estudia |
|---|---|---|
| “Nombre de cada empleado junto al nombre de su jefe” (un nivel) | SELF JOIN: combinar la tabla EMPLEADOS consigo misma usando dos alias (uno para el papel subordinado y otro para el papel jefe) | Módulo de consultas multitabla |
| “Todos los subordinados directos e indirectos de Marta, con su nivel” (todos los niveles) | Consultas jerárquicas de Oracle: START WITH, CONNECT BY PRIOR, la pseudocolumna LEVEL y SYS_CONNECT_BY_PATH | Módulo de consultas avanzadas |
| Lo mismo con SQL estándar | CTE recursivas: cláusula WITH que se referencia a sí misma | Módulo de operadores de conjuntos y CTE |
| “Cuántos radios hacen falta para una bicicleta” (explosión de la BOM) | CTE recursiva multiplicando cantidades a lo largo del camino | Módulo de operadores de conjuntos y CTE |
| Detectar ciclos en los datos | Cláusula NOCYCLE y CONNECT_BY_ISCYCLE (Oracle) o CYCLE en las CTE | Módulo de consultas avanzadas |
💡 Consejo: Fíjate en que los alias del SELF JOIN cumplen exactamente la misma función que los papeles del E/R: distinguir las dos participaciones de la misma entidad. Si en el diseño conceptual nombraste bien los papeles, escribir la consulta será inmediato.
12. Errores frecuentes
12.1. Omitir los papeles
Incorrecto: las dos aristas solo con “(0,1)” y “(0,n)” (sección 2.1). Correcto: “(0,1) jefe” y “(0,n) subordinado”.
12.2. Poner la cardinalidad en la arista equivocada
Incorrecto: “(0,n) jefe” y “(0,1) subordinado” para expresar que “un jefe tiene muchos subordinados”. Leído con la convención del curso dice que cada empleado tiene muchos jefes y como mucho un subordinado. Correcto: la cardinalidad va en la arista del papel que cuentas: “cada subordinado tiene como mucho 1 jefe” → “(0,1) jefe”.
12.3. Crear una entidad por papel
Incorrecto:
flowchart LR
JEFE[JEFE] ---|"(0,1)"| dirige{dirige}
dirige ---|"(0,n)"| EMPLEADO[EMPLEADO]
Los jefes también son empleados: tienen nombre, salario, departamento… y, a su vez, tienen jefe. Con dos entidades, Marta tendría que estar en JEFE (como jefa de Pablo) y en EMPLEADO (como subordinada de Ana), con sus datos duplicados. Correcto: una sola entidad EMPLEADO con una reflexiva. (Si solo los directivos pudieran ser jefes y tuvieran atributos propios, la solución sería una especialización, sección 10.2, nunca duplicar la entidad.)
12.4. Atributo que apunta a la misma entidad
Incorrecto: atributo jefe_id o nombre_jefe en EMPLEADO. Igual que en las binarias, en el E/R no hay claves ajenas: la asociación se dibuja con la relación reflexiva. nombre_jefe además es redundante: el nombre del jefe ya está en su propia ocurrencia de EMPLEADO.
12.5. No anotar irreflexividad ni aciclicidad
Incorrecto: entregar un organigrama, una BOM o un sistema de carpetas con la reflexiva y sin ninguna restricción semántica. Las cardinalidades no impiden los ciclos (sección 7.4). Correcto: anotar siempre RS de irreflexividad y, en jerarquías y composiciones, de aciclicidad.
12.6. Almacenar la relación transitiva
Incorrecto: guardar en requiere no solo los prerrequisitos directos, sino también los indirectos (“BDA requiere Programación I”), o añadir una segunda reflexiva “es jefe indirecto de”. Correcto: almacenar solo la relación directa y deducir la transitiva con consultas recursivas.
12.7. Simétrica sin política de almacenamiento
Incorrecto: modelar la amistad como reflexiva N:M sin decir si (a, b) implica (b, a), ni si se guarda una o dos veces. El resultado son datos incoherentes: Ana aparece como amiga de Luis, pero Luis no como amigo de Ana. Correcto: RS de simetría con la política elegida, o reificar la amistad con (2,2).
12.8. Una entidad por nivel en una jerarquía variable
Incorrecto: CATEGORÍA – SUBCATEGORÍA – SUBSUBCATEGORÍA cuando el número de niveles puede cambiar. Correcto: reflexiva sobre CATEGORÍA, con RS de profundidad máxima si el negocio la exige (sección 7.5).
12.9. Confundir reflexiva con especialización
Incorrecto: dibujar “Portátiles” o “Monitores” como subtipos de CATEGORÍA con un hexágono “es un”. Son ocurrencias de CATEGORÍA, no tipos. Correcto: reflexiva contiene sobre CATEGORÍA.
12.10. Reflexiva simple para hechos que se repiten
Incorrecto: añadir fecha_inicio y fecha_fin a la reflexiva dirige para guardar el historial de jefes. Una relación no puede repetir un par, y además la relación 1:N solo admite un jefe por empleado. Correcto: reificar en una entidad SUPERVISIÓN (sección 9).
13. Ejercicios resueltos
Ejercicio 1: Leer una reflexiva
Lee el diagrama en los dos sentidos e indica la correspondencia y la estructura que forman sus ocurrencias.
flowchart LR
SOCIO[SOCIO] ---|"(0,2) avalista"| avala{avala a}
SOCIO ---|"(0,n) avalado"| avala
Ver solución
- Desde el papel avalado (leo la arista avalista): “Cada socio, como avalado, es avalado por entre 0 y 2 avalistas”. Por ejemplo, un club exige uno o dos avales para entrar, y los socios fundadores no tienen aval.
- Desde el papel avalista (leo la arista avalado): “Cada socio, como avalista, avala a ninguno, uno o varios socios”.
- Máximos 2 y n: los dos son mayores que 1, así que es N:M (con un máximo concreto de 2 en un papel).
- Estructura: un grafo dirigido en el que cada nodo tiene como mucho 2 flechas entrantes. Si se exige que el avalista sea más antiguo que el avalado, no hay ciclos (DAG).
Restricciones a anotar: un socio no puede avalarse a sí mismo; sus dos avalistas, si tiene dos, son distintos (esto último ya lo garantiza que una relación no repite pares).
Ejercicio 2: Zonas geográficas de profundidad variable
“Una ONG organiza su trabajo en zonas: continentes, países, regiones, comarcas… El número de niveles no es el mismo en todos los países. Cada zona, salvo las de nivel superior, está dentro de una única zona. Cada proyecto se desarrolla en una zona de cualquier nivel.” Dibuja el diagrama.
Ver solución
La profundidad es variable y todas las zonas se relacionan igual con los proyectos: reflexiva 1:N.
flowchart LR
ZONA[ZONA] ---|"(0,1) zona superior"| incluye{"incluye<br/>1:N"}
ZONA ---|"(0,n) zona inferior"| incluye
ZONA ---|"(1,1)"| desarrolla{"acoge<br/>1:N"}
desarrolla ---|"(0,n)"| PROYECTO[PROYECTO]
ZONA --- z_cod([<u>cod_zona</u>])
ZONA --- z_nombre([nombre])
ZONA --- z_tipo([tipo])
PROYECTO --- p_cod([<u>cod_proyecto</u>])
- zona superior (0,1): cada zona está dentro de como mucho una zona; 0 para los continentes.
- zona inferior (0,n): una zona puede incluir muchas o ninguna (las comarcas).
- (1,1) junto a ZONA en acoge: cada proyecto se desarrolla en exactamente una zona; (0,n) junto a PROYECTO.
- RS1: Ninguna zona está incluida, directa o indirectamente, en sí misma.
El atributo tipo (‘CONTINENTE’, ‘PAÍS’…) es informativo; no condiciona la estructura.
Ejercicio 3: Validar ocurrencias
En la relación dirige de EMPLEADO (jefe (0,1), subordinado (0,n)) se proponen estos pares (jefe, subordinado): (1, 2), (1, 3), (2, 4), (3, 4), (4, 5), (5, 5), (6, 7), (7, 6). Indica qué pares incumplen las cardinalidades y cuáles las restricciones semánticas de irreflexividad y aciclicidad.
Ver solución
flowchart TB
n1("1") --> n2("2")
n1 --> n3("3")
n2 --> n4("4")
n3 --> n4
n4 --> n5("5")
n5 --> n5
n6("6") --> n7("7")
n7 --> n6
- Cardinalidades: el empleado 4 tiene dos jefes (2 y 3): incumple el máximo 1 de la arista jefe. Uno de los pares (2, 4) o (3, 4) sobra. El 5 también tiene dos “jefes” (4 y él mismo).
- Irreflexividad: (5, 5) la incumple: el 5 sería su propio jefe.
- Aciclicidad: (6, 7) y (7, 6) forman un ciclo. Con respecto a las cardinalidades son correctos (cada uno tiene un solo jefe), pero solo la RS de aciclicidad los prohíbe.
Corrigiendo, por ejemplo eliminando (3, 4), (5, 5) y (7, 6), queda un bosque con raíces 1 y 6.
Ejercicio 4: Genealogía
“Una aplicación de genealogía registra personas y, cuando se conocen, su madre y su padre. También registra los matrimonios actuales.” Dibuja el diagrama y enumera las restricciones.
Ver solución
Tres reflexivas sobre PERSONA, una por significado:
flowchart LR
PERSONA[PERSONA] ---|"(0,1) madre"| madre_de{"es madre de<br/>1:N"}
PERSONA ---|"(0,n) hijo"| madre_de
PERSONA ---|"(0,1) padre"| padre_de{"es padre de<br/>1:N"}
PERSONA ---|"(0,n) hijo"| padre_de
PERSONA ---|"(0,1) cónyuge A"| casada{"está casada con<br/>1:1"}
PERSONA ---|"(0,1) cónyuge B"| casada
PERSONA --- pe_id([<u>id_persona</u>])
PERSONA --- pe_nombre([nombre])
PERSONA --- pe_nac(["fecha_nacimiento (0,1)"])
Restricciones:
- RS1: Nadie es su propia madre, su propio padre ni su propio cónyuge.
- RS2: La madre y el padre de una persona son personas distintas.
- RS3: Si se conocen las fechas, la madre y el padre nacieron antes que el hijo (garantiza la aciclicidad).
- RS4: Cada matrimonio se registra una sola vez y una persona no puede ser cónyuge A en un matrimonio y cónyuge B en otro.
fecha_nacimiento es opcional porque en genealogía muchas veces se desconoce.
Ejercicio 5: Cuadro de un torneo eliminatorio
“En un torneo de tenis por eliminatorias, el ganador de cada partido pasa a un partido de la ronda siguiente, salvo la final. Cada partido, salvo los de primera ronda, se nutre de los ganadores de exactamente dos partidos anteriores.” Modela la relación entre partidos e indica la estructura.
Ver solución
flowchart LR
PARTIDO[PARTIDO] ---|"(0,1) siguiente"| pasa{"su ganador pasa a<br/>1:N"}
PARTIDO ---|"(0,2) anterior"| pasa
PARTIDO --- pa_id([<u>id_partido</u>])
PARTIDO --- pa_ronda([ronda])
- siguiente (0,1): el ganador de cada partido pasa como mucho a un partido; la final no tiene siguiente.
- anterior (0,2): cada partido se nutre de 0 partidos (primera ronda) o de 2. La pareja (0,2) admite también 1, que no es válido: se anota RS1: cada partido tiene 0 o exactamente 2 anteriores.
- Correspondencia 1:N con máximo concreto 2.
flowchart RL
q1("Cuartos 1") --> s1("Semifinal 1")
q2("Cuartos 2") --> s1
q3("Cuartos 3") --> s2("Semifinal 2")
q4("Cuartos 4") --> s2
s1 --> f("Final")
s2 --> f
La estructura es un árbol binario cuya raíz es la final.
- RS2: La ronda del partido siguiente es la ronda del anterior + 1 (garantiza la aciclicidad).
Ejercicio 6: Seguimiento y bloqueo
“En una red social, un usuario puede seguir a otros y también bloquearlos. No se puede seguir a quien te ha bloqueado.” Modela las relaciones y las restricciones.
Ver solución
Dos reflexivas N:M asimétricas sobre USUARIO:
flowchart LR
USUARIO[USUARIO] ---|"(0,n) seguidor"| sigue{"sigue a<br/>N:M"}
USUARIO ---|"(0,n) seguido"| sigue
USUARIO ---|"(0,n) bloqueador"| bloquea{"bloquea a<br/>N:M"}
USUARIO ---|"(0,n) bloqueado"| bloquea
USUARIO --- us_login([<u>login</u>])
sigue --- si_fecha([fecha_desde])
bloquea --- bl_fecha([fecha_bloqueo])
- RS1: Nadie se sigue ni se bloquea a sí mismo.
- RS2: Si A bloquea a B, B no puede seguir a A (restricción de exclusión entre los pares (B, A) de sigue a y (A, B) de bloquea a).
- RS3 (de negocio): Al bloquear a alguien, se elimina su seguimiento.
Ninguna de las dos relaciones es acíclica ni simétrica: el seguimiento mutuo y el bloqueo mutuo son posibles.
Ejercicio 7: Explosión de materiales
Con esta BOM, calcula cuántas unidades de cada producto básico hacen falta para fabricar un armario. Armario: 2 puertas, 1 cuerpo, 4 patas. Puerta: 1 tablero, 2 bisagras, 1 tirador. Cuerpo: 5 tableros, 12 tornillos. Bisagra: 4 tornillos. Dibuja el grafo e indica por qué es N:M.
Ver solución
flowchart LR
arm("Armario") -->|"2"| pue("Puerta")
arm -->|"1"| cue("Cuerpo")
arm -->|"4"| pat("Pata")
pue -->|"1"| tab("Tablero")
pue -->|"2"| bis("Bisagra")
pue -->|"1"| tir("Tirador")
cue -->|"5"| tab
cue -->|"12"| tor("Tornillo")
bis -->|"4"| tor
Se multiplican las cantidades a lo largo de cada camino y se suman los caminos que llegan al mismo producto básico:
| Producto básico | Caminos | Total |
|---|---|---|
| Tablero | Armario→Puerta→Tablero: 2 × 1 = 2; Armario→Cuerpo→Tablero: 1 × 5 = 5 | 7 |
| Tornillo | Armario→Cuerpo→Tornillo: 1 × 12 = 12; Armario→Puerta→Bisagra→Tornillo: 2 × 2 × 4 = 16 | 28 |
| Tirador | 2 × 1 | 2 |
| Pata | 4 | 4 |
Las bisagras (2 × 2 = 4) son un producto intermedio. La relación es N:M porque el tablero y el tornillo son componentes de varios compuestos (puerta y cuerpo, cuerpo y bisagra). Si fuera 1:N cada componente tendría un solo compuesto y el grafo sería un árbol. Los totales son datos derivados: no se almacenan.
Ejercicio 8: Prerrequisitos con errores
Un plan de estudios tiene estos prerrequisitos (prerrequisito → dependiente): Cálculo → Física; Física → Electrónica; Electrónica → Cálculo; Programación → Programación; Programación → Algoritmos; Cálculo → Electrónica. Detecta los errores y las posibles redundancias.
Ver solución
flowchart LR
cal("Cálculo") --> fis("Física")
fis --> ele("Electrónica")
ele --> cal
pro("Programación") --> pro
pro --> alg("Algoritmos")
cal --> ele
- Ciclo Cálculo → Física → Electrónica → Cálculo: nadie podría matricularse de ninguna de las tres. Incumple la RS de aciclicidad. Hay que eliminar Electrónica → Cálculo.
- Autorrelación Programación → Programación: incumple la irreflexividad.
- Posible redundancia: Cálculo → Electrónica, porque Cálculo ya es prerrequisito indirecto de Electrónica (a través de Física). Si requiere significa “requisito directo exigido en el plan”, es válido; si se añadió solo porque “se deduce”, sobra: la relación transitiva no se almacena.
Ejercicio 9: ¿Reflexiva o una entidad por nivel?
Decide cómo modelar: a) Universidad → Facultad → Departamento → Área de conocimiento, cada nivel con atributos distintos; b) la estructura de un libro electrónico, con partes, capítulos, secciones y subsecciones de profundidad variable; c) el menú de una aplicación web, con submenús anidados sin límite.
Ver solución
a) Una entidad por nivel con relaciones binarias 1:N: la profundidad es fija (4 niveles), cada nivel tiene atributos propios (la facultad tiene decano; el departamento, director y presupuesto) y probablemente relaciones distintas (los profesores pertenecen a departamentos; los títulos, a facultades).
b) Reflexiva 1:N sobre APARTADO ((0,1) apartado padre / (0,n) subapartado), con atributos titulo, orden y tipo. La profundidad es variable y todos los niveles tienen los mismos atributos. Habría que anotar RS de aciclicidad y, para el orden, que dos subapartados del mismo padre no tengan el mismo orden.
c) Reflexiva 1:N sobre OPCION_MENU ((0,1) opción padre / (0,n) subopción). Si la interfaz solo puede mostrar tres niveles, se añade una RS de profundidad máxima.
Ejercicio 10: Historial de tutores
“En un instituto, cada alumno de los cursos superiores puede tener como mentor a otro alumno de un curso superior. Se quiere guardar el historial: qué alumno fue mentor de cuál y durante qué curso académico; un mismo par puede repetirse en varios cursos.” Modela el historial.
Ver solución
El par (mentor, mentorizado) se repite en distintos cursos, así que la reflexiva no basta: se reifica en una entidad MENTORIA unida a ALUMNO por dos relaciones, una por papel.
flowchart LR
ALUMNO[ALUMNO] ---|"(1,1)"| es_mentor{"actúa como mentor en<br/>1:N"}
es_mentor ---|"(0,n)"| MENTORIA[MENTORÍA]
ALUMNO ---|"(1,1)"| recibe{"recibe<br/>1:N"}
recibe ---|"(0,n)"| MENTORIA
ALUMNO --- al_nia([<u>nia</u>])
ALUMNO --- al_curso([curso_actual])
MENTORIA --- me_id([<u>id_mentoria</u>])
MENTORIA --- me_anyo([curso_academico])
- Cada mentoría tiene exactamente un mentor y un mentorizado (1,1).
- Un alumno puede haber sido mentor o mentorizado en 0 o más mentorías (0,n).
- RS1: El mentor y el mentorizado de una mentoría son alumnos distintos.
- RS2: En un mismo curso académico, un alumno tiene como mucho un mentor.
- RS3: En el curso académico de la mentoría, el mentor está en un curso superior al del mentorizado (garantiza que no haya ciclos en un mismo año).
Ejercicio 11: Reflexiva o especialización
“Los profesores de una academia pueden ser titulares o colaboradores. Cada colaborador tiene asignado un titular como coordinador. Además, cualquier profesor puede sustituir a cualquier otro durante sus ausencias; se guarda la fecha de cada sustitución.” Identifica qué es especialización, qué es binaria y qué es reflexiva.
Ver solución
- Especialización: PROFESOR con los subtipos TITULAR y COLABORADOR (total, exclusiva): son tipos de profesor.
- Binaria entre subtipos: coordina, entre TITULAR (1,1) y COLABORADOR (0,n). No es reflexiva, porque cada papel lo desempeña un subtipo distinto.
- Reflexiva… con matiz: “cualquier profesor puede sustituir a cualquier otro” es una reflexiva sobre PROFESOR (sustituto / sustituido). Pero como se guarda la fecha de cada sustitución y el mismo par puede repetirse, hay que reificarla en una entidad SUSTITUCIÓN con dos relaciones a PROFESOR.
flowchart TB
PROFESOR[PROFESOR] --- j{{"es un<br/>(total, exclusiva)"}}
j --- TITULAR[TITULAR]
j --- COLABORADOR[COLABORADOR]
TITULAR ---|"(1,1)"| coordina{"coordina<br/>1:N"}
coordina ---|"(0,n)"| COLABORADOR
PROFESOR ---|"(1,1)"| sustituye{"sustituye en<br/>1:N"}
sustituye ---|"(0,n)"| SUSTITUCION[SUSTITUCIÓN]
PROFESOR ---|"(1,1)"| ausente{"es sustituido en<br/>1:N"}
ausente ---|"(0,n)"| SUSTITUCION
SUSTITUCION --- su_fecha([fecha])
SUSTITUCION --- su_id([<u>id_sustitucion</u>])
- RS1: En una sustitución, el sustituto y el sustituido son profesores distintos.
Ejercicio 12: Conexiones aéreas
“Una aerolínea registra las rutas directas entre aeropuertos. Cada ruta tiene un sentido (de Valencia a Londres no es lo mismo que de Londres a Valencia: los horarios y precios son distintos), una duración y un precio base.” Modela las rutas y explica si la relación es simétrica.
Ver solución
flowchart LR
AEROPUERTO[AEROPUERTO] ---|"(0,n) origen"| ruta{"tiene ruta directa a<br/>N:M"}
AEROPUERTO ---|"(0,n) destino"| ruta
AEROPUERTO --- ae_iata([<u>codigo_iata</u>])
AEROPUERTO --- ae_ciudad([ciudad])
ruta --- ru_dur([duracion_min])
ruta --- ru_precio([precio_base])
- origen (0,n): a un aeropuerto se llega desde 0 o más orígenes; destino (0,n): desde un aeropuerto se va a 0 o más destinos.
- La relación es asimétrica: (VLC, LHR) y (LHR, VLC) son ocurrencias distintas, con duración y precio propios. El grafo es dirigido con pesos y puede tener ciclos (VLC → LHR → VLC), lo cual es correcto.
- RS1: Un aeropuerto no tiene ruta consigo mismo.
- RS2:
duracion_minyprecio_baseson mayores que 0.
Si se necesitaran los vuelos concretos de cada ruta (fecha, avión, plazas), cada vuelo sería una entidad relacionada con la ruta, y la ruta, al tener que relacionarse con otra entidad, convendría reificarla también (una entidad RUTA con dos relaciones a AEROPUERTO: sale de y llega a).
14. Ejercicios propuestos
Ejercicio propuesto 1: Organigrama de un hospital
“Cada médico tiene como mucho un jefe de servicio, que también es médico. El jefe de servicio no tiene jefe. Un jefe tiene al menos 3 médicos a su cargo.” Dibuja la reflexiva y las restricciones. ¿Hay alguna contradicción con que “la mayoría de médicos no tienen a nadie a su cargo”?
Ejercicio propuesto 2: Sustitución de piezas
“En un almacén, una pieza puede ser sustituible por otras piezas equivalentes. Si A es sustituible por B, B también lo es por A.” Modela la relación, decide la política de almacenamiento y justifica si conviene almacenar la transitividad (si A ≡ B y B ≡ C, ¿A ≡ C?).
Ejercicio propuesto 3: Grafo de citas
“Un artículo científico cita a otros artículos anteriores. Se guarda en qué página se produce cada cita.” Dibuja el diagrama, indica la estructura y las restricciones (¿puede haber ciclos si los artículos citan solo trabajos ya publicados?).
Ejercicio propuesto 4: Árbol de tareas
“Un proyecto se descompone en tareas, que se descomponen en subtareas, sin límite. Además, algunas tareas no pueden empezar hasta que terminen otras (dependencias).” Identifica las dos reflexivas, su correspondencia y las restricciones de cada una.
Ejercicio propuesto 5: Partidos de ida y vuelta
“En una liga, cada partido de vuelta corresponde exactamente a un partido de ida, y cada partido de ida tiene como mucho un partido de vuelta (puede no haberse jugado aún).” Modela la reflexiva 1:1 y anota las restricciones (equipos intercambiados, fechas).
Ejercicio propuesto 6: Historial de categorías
Amplía las categorías de EMPRESA para registrar el historial de reorganizaciones del catálogo: en qué periodo cada categoría estuvo dentro de cada categoría padre. Dibuja el diagrama y enumera las restricciones.
Ejercicio propuesto 7: Red de metro
“Se registran las estaciones y los tramos entre estaciones consecutivas de cada línea, con la duración del tramo. Un tramo pertenece a una línea.” Discute si los tramos son una reflexiva N:M sobre ESTACIÓN o una entidad, teniendo en cuenta que dos líneas pueden compartir el mismo par de estaciones consecutivas.
Ejercicio propuesto 8: Revisión por pares
“En un congreso, cada artículo lo revisan entre 2 y 4 autores de otros artículos. Un autor no puede revisar artículos propios ni de coautores.” Decide si hay alguna reflexiva implicada y modela el caso completo con las restricciones semánticas.
Ejercicio propuesto 9: Mentores con límite
En el ejercicio resuelto 10, añade que un alumno puede ser mentor de como máximo 3 alumnos en el mismo curso académico. ¿Se puede expresar con una cardinalidad en el diagrama o necesitas una restricción semántica? Razónalo.
Resumen
| Concepto | Idea clave |
|---|---|
| Relación reflexiva | Una entidad participa dos veces con papeles distintos; R ⊆ E × E con pares ordenados |
| Grado | 1 contando tipos de entidad (unaria), 2 contando participaciones (recursiva); se comporta como binaria |
| Papeles | Obligatorios; sustantivos complementarios (jefe/subordinado); el verbo se lee “papel 1 verbo papel 2” |
| Notación | Dos aristas del mismo rectángulo al rombo, cada una con “(mín,máx) papel” |
| Cardinalidad | La pareja de la arista del papel P dice con cuántos P se relaciona una ocurrencia del otro papel |
| Diagramas de ocurrencias | Bipartito (comprobar cardinalidades) y grafo de ejemplares (ver la estructura) |
| 1:1 | Parejas y cadenas: cónyuges, sucesión de mandatos |
| 1:N | Árboles y bosques: jefe (EMPRESA), categorías (EMPRESA), comentarios, carpetas |
| N:M | Grafos dirigidos (DAG o con ciclos): prerrequisitos, BOM, seguidores, rutas |
| Simetría | Amistad, matrimonio: papeles artificiales, política de almacenamiento (una o dos veces) o reificar con (2,2) |
| Restricciones típicas | Irreflexividad, aciclicidad, raíz única, profundidad máxima, simetría, coherencia con otras relaciones |
| Transitividad | Se almacena la relación directa; la indirecta se deduce |
| Profundidad | Variable y niveles homogéneos → reflexiva; fija y niveles distintos → una entidad por nivel |
| Atributos | 1:N → pueden migrar a la entidad como dato del papel N; N:M → en la relación (cantidad, distancia) |
| Historial | Reificar: entidad con dos relaciones binarias a la entidad original, una por papel |
| Frente a especialización | Reflexiva = ocurrencias entre sí; especialización = tipos y subtipos (“es un”) |
| Relacional | 1:N → FK a la propia tabla (jefe_id); N:M → tabla con dos FK a la misma tabla |
| SQL | SELF JOIN (un nivel), CONNECT BY (Oracle) y CTE recursivas (todos los niveles) |