El Proyecto | Sobre nosotros | Contribuir | Donaciones | Licencia
HOME Mis cursos Finalizados
◄ Anterior
◄

Diagramas Entidad-Relación (ER)

Siguiente ►
►

En la lección anterior cerramos el documento de requisitos v1.0 de la ampliación de BiblioRed: catorce requisitos funcionales, diez reglas de negocio, doce consultas y un alcance delimitado. Es un texto excelente para discutir con el cliente y absolutamente inservible para programar. Entre esas dos cosas falta un paso: convertir la prosa en un dibujo.

El modelo entidad-relación es ese dibujo. Lo propuso Peter Chen en 1976 —lo situamos en la lección 01-03— y sigue siendo, cincuenta años después, la manera estándar de pensar un dominio antes de tocar el teclado. No es un diagrama decorativo que se hace al final para documentar: es una herramienta de razonamiento. Dibujar obliga a decidir cosas que la prosa permite dejar vagas, y por eso la mitad de las preguntas útiles de un proyecto aparecen mientras se traza una línea entre dos cajas.

Esta lección enseña el lenguaje completo —entidades, atributos, relaciones, cardinalidad, participación, jerarquías— y lo aplica, decisión a decisión, al encargo de BiblioRed. El entregable es el diagrama ER completo de BiblioRed ampliado, integrando las siete tablas que ya existían con todo lo nuevo. Sigue sin haber una sola sentencia CREATE TABLE: eso es la lección siguiente, y hay una razón para el orden.

Contenido

  1. Qué es un modelo conceptual y por qué se dibuja antes de que exista ninguna tabla
  2. Entidades: fuertes y débiles
  3. Atributos: simples, compuestos, multivaluados, derivados e identificadores
  4. Relaciones: binarias, reflexivas, ternarias y con atributos propios
  5. Cardinalidad: 1:1, 1:N y N:M
  6. Participación total o parcial: la otra mitad que todos confunden
  7. Las notaciones: Chen frente a pata de gallo
  8. El modelo ER extendido: generalización y especialización
  9. Dibujar BiblioRed, decisión a decisión
  10. Entregable: el diagrama ER completo de BiblioRed ampliado
  11. Herramientas para dibujar diagramas
  12. Errores Comunes y Consejos
  13. Ejercicios
  14. Conclusión

  1. Qué es un modelo conceptual y por qué se dibuja antes de que exista ninguna tabla

Un modelo conceptual es una representación de lo que existe en un dominio y de cómo se relaciona, sin comprometerse con ninguna tecnología. No dice tablas ni documentos ni columnas ni tipos. Dice: aquí hay socios, aquí hay eventos, y un socio se inscribe a muchos eventos.

Que sea independiente de la tecnología no es purismo académico: es lo que le da su utilidad. Tres consecuencias prácticas:

Se puede discutir con quien no es informático. La coordinadora de actividades de BiblioRed no va a revisar un CREATE TABLE, pero sí puede mirar una línea entre "evento" y "sala" y decir "eso está mal, el cuentacuentos de verano lo hacemos en el patio". Ese comentario, hecho en la fase del dibujo, cuesta borrar una línea. Hecho tres meses después, cuesta una migración.

Sirve igual para relacional que para documental. El mismo diagrama de BiblioRed puede derivar en un esquema PostgreSQL (04-03) o en colecciones de MongoDB con las técnicas de 03-03. La decisión de embeber o referenciar se toma después, sobre el modelo conceptual ya cerrado. Un diagrama ER es, en ese sentido, más duradero que cualquiera de los dos esquemas.

Hace visibles los agujeros. La prosa tolera la ambigüedad; un dibujo no. En cuanto se traza la línea entre EVENTO y SALA hay que decidir tres cosas obligatoriamente: cuántas salas por evento, cuántos eventos por sala, y si puede haber un evento sin sala. La prosa de R4 no respondía la tercera.

El criterio de calidad de un modelo conceptual no es que sea bonito, sino que cada línea sea una afirmación verificable sobre el negocio que alguien pueda confirmar o desmentir.

  1. Entidades: fuertes y débiles

Una entidad es una cosa del dominio con existencia propia y sobre la que queremos guardar información. Un conjunto de entidades (lo que coloquialmente llamamos "la entidad") es el tipo: SOCIO, EVENTO, SALA. Una instancia es un individuo concreto: la socia Marta Alsina, el club de lectura del 14 de mayo.

Entidad fuerte

Una entidad fuerte tiene un identificador propio y existe por sí sola. SOCIO es fuerte: Marta Alsina existe aunque nunca pida un préstamo. SALA es fuerte, EVENTO es fuerte, PONENTE es fuerte.

Entidad débil

Una entidad débil no puede identificarse por sí misma: necesita la identidad de otra entidad, llamada entidad propietaria o identificadora. Dos señales inequívocas:

  1. Sus instancias no tienen sentido sin su propietaria.
  2. Su identificador es parcial: distingue instancias solo dentro de una propietaria.

El ejemplo canónico en BiblioRed es el ejemplar. Según R2, los ejemplares se numeran dentro de su material: "el ejemplar 3 de El mapa del tiempo". El número 3 no identifica nada por sí solo —hay un ejemplar 3 de cada material del catálogo—; lo que identifica es la pareja (material, número). Ese "3" es el identificador parcial o discriminante.

Entidad Tipo Identificador Por qué
MATERIAL Fuerte Identificador propio Un material existe en el catálogo aunque no haya comprado aún ningún ejemplar
EJEMPLAR Débil de MATERIAL (material, nº de ejemplar) "Ejemplar 3" no significa nada sin decir de qué
INSCRIPCION Débil de EVENTO y SOCIO (evento, socio) Una inscripción no existe sin ambos
TELEFONO Débil de SOCIO (socio, número) Un teléfono suelto no es una entidad del dominio
PAGO Débil de MULTA (multa, nº de pago) Un pago solo tiene sentido contra una multa concreta

Una precisión que evita mucha confusión: en el modelo conceptual, una entidad es débil por una razón semántica (no existe sin la otra), no porque le vayamos a poner una clave compuesta. Lo segundo es una consecuencia habitual, pero es una decisión de la fase lógica, y en 04-03 veremos que a veces se resuelve con clave subrogada por comodidad sin dejar de ser conceptualmente débil.

La pregunta que decide: si desapareciera la entidad propietaria, ¿tendría sentido conservar esta? Si desaparece "El mapa del tiempo" del catálogo, ¿tiene sentido conservar su ejemplar 3? No. Es débil.

  1. Atributos: simples, compuestos, multivaluados, derivados e identificadores

Un atributo es una propiedad de una entidad o de una relación. Hay cinco tipos y distinguirlos importa, porque cada uno se transforma de una manera distinta en 04-03.

Simple (o atómico)

Un valor indivisible para el negocio: aforo, titulo, fecha_inscripcion. Es el caso normal.

Compuesto

Un atributo que se descompone en partes con significado propio. El caso de BiblioRed es R13: la dirección de una sucursal, hoy un texto único, que la web necesita descomponer en calle, número, código postal y ciudad.

                    ┌── calle
                    ├── numero
     direccion ─────┤
                    ├── codigo_postal
                    └── ciudad

La pregunta para decidir si se descompone es siempre la misma: ¿alguien va a buscar, filtrar u ordenar por una de las partes? R13 dice explícitamente que sí (buscar por código postal), así que se descompone. Si nadie fuera a hacerlo, un texto único sería la opción correcta y más simple.

Multivaluado

Un atributo que puede tener varios valores a la vez para la misma instancia. En BiblioRed hay dos, y los dos se detectan por un plural en el enunciado:

  • Los idiomas de subtítulos de un DVD (R1).
  • Los teléfonos de un socio, hasta tres (R12).

Es importante no confundirlo con un atributo que cambia con el tiempo: el estado de un ejemplar cambia, pero en cada momento tiene uno solo. Multivaluado significa simultáneo.

Derivado

Un atributo cuyo valor se calcula a partir de otros y por tanto no necesita almacenarse. BiblioRed tiene varios:

Atributo derivado Se calcula a partir de Requisito
Plazas libres de un evento plazas_ofertadas − inscripciones confirmadas (con acompañantes) C2, RN2
Importe pendiente de una multa importe − suma de sus pagos R11
Días de retraso de un préstamo fecha_devolucion − fecha_devolucion_prevista R10
Sucursal de un evento La sucursal de su sala R4
Nº de ejemplares de un material Cuenta de sus ejemplares RN10

En un diagrama se marcan (clásicamente, con un óvalo de línea discontinua) precisamente para dejar constancia de que no se guardan. Que a veces se acabe guardando uno por rendimiento es una decisión posterior y consciente, que tiene nombre —desnormalización— y se estudia en 05-04.

Identificador (o clave)

El atributo, o conjunto de atributos, que distingue una instancia de otra dentro del conjunto. En el modelo conceptual se llama clave candidata; cuando se elige una, es la clave primaria. Retomamos aquí exactamente lo de 02-01 y la decisión de diseño del apartado 10 de 04-01.

En BiblioRed la sala ilustra un matiz fino: según R3, el nombre de sala solo es único dentro de su sucursal. Es decir, nombre no es identificador de SALA, pero la pareja (sucursal, nombre) sí lo es. Un identificador que necesita a la entidad relacionada es la marca clásica de una entidad débil… y en efecto, una sala es conceptualmente débil respecto a su sucursal. Lo asumiremos así y en 04-03 veremos qué hacemos con ello.

Tabla resumen

Tipo de atributo Señal para detectarlo Ejemplo en BiblioRed Cómo se transforma (04-03)
Simple Un valor, indivisible aforo, titulo Una columna
Compuesto Se puede trocear con sentido direccion de sucursal Varias columnas, o una si nadie busca por las partes
Multivaluado Aparece en plural subtítulos de un DVD, teléfonos Tabla aparte
Derivado "Se calcula", "es el total de" plazas libres, deuda pendiente No se almacena (o vista / columna generada)
Identificador "Cada X tiene su número" ISBN, código de ejemplar Clave primaria o UNIQUE

  1. Relaciones: binarias, reflexivas, ternarias y con atributos propios

Una relación (o interrelación) es una asociación entre instancias de entidades. En el enunciado casi siempre corresponde a un verbo: un socio se inscribe a un evento, un evento se celebra en una sala, un préstamo genera una multa.

Grado de la relación

El grado es cuántas entidades participan:

Grado Nombre Ejemplo en BiblioRed
2 Binaria SOCIO — se_inscribe — EVENTO
1 Reflexiva (o recursiva) Un material es la continuación de otro material
3 Ternaria EVENTO — PONENTE — ROL: quién participa, en qué evento, con qué papel (R7)

La inmensa mayoría de las relaciones útiles son binarias. Las de grado superior son raras, difíciles de leer y casi siempre son tres binarias disfrazadas; volveremos sobre ello en el apartado 9 y con más contundencia en 04-03.

Relación reflexiva

Es una relación de una entidad consigo misma. Se lee siempre con dos roles distintos, y sin nombrarlos el diagrama es incomprensible.

        ┌──────────────┐
        │   MATERIAL   │
        └──┬────────┬──┘
   (obra)  │        │  (continuación)
           └───◇────┘
           es_continuacion_de

En BiblioRed no está en los requisitos v1.0, pero es útil verla porque aparece en casi todos los dominios: empleado/jefe, categoría/subcategoría, material/secuela.

Relación con atributos propios

Este es el concepto más importante del apartado. Hay datos que no pertenecen a ninguna de las dos entidades, sino a su cruce.

Piensa en la inscripción de R6. La fecha de inscripción, ¿es un atributo del socio? No: un socio no tiene "una fecha de inscripción", tiene muchas, una por evento. ¿Es un atributo del evento? Tampoco, por lo mismo. Es un atributo de la relación: existe solo cuando ese socio concreto se cruza con ese evento concreto.

Relación Atributos propios Requisito
SOCIO — se_inscribe — EVENTO fecha de inscripción, estado, acompañantes R6
PONENTE — participa — EVENTO rol, honorarios R7
EVENTO — trata — MATERIAL papel (principal / recomendado) R8

La regla infalible para detectarlos: si un atributo necesita saber ambas claves para tener un valor, pertenece a la relación. "¿Cuáles son los honorarios de Elena Roig?" no tiene respuesta; "¿cuáles son los honorarios de Elena Roig en el taller del 12 de junio?" sí.

Las relaciones N:M siempre admiten atributos propios; las 1:N también pueden tenerlos, aunque en la práctica se acaban absorbiendo en el lado N.

  1. Cardinalidad: 1:1, 1:N y N:M

La cardinalidad (o razón de cardinalidad) responde a: ¿con cuántas instancias del otro lado se puede asociar una instancia de este?

Tipo Significado Ejemplo en BiblioRed Requisito
1:1 Cada A con como mucho un B, y cada B con como mucho un A EVENTO — tiene — INFORME R9
1:N Cada A con muchos B; cada B con un solo A SALA — acoge — EVENTO R4
N:M Cada A con muchos B y cada B con muchos A SOCIO — se_inscribe — EVENTO R6

Cómo se determina, en la práctica

Se hacen dos preguntas, una por sentido, y se anota cada respuesta:

Pregunta 1: Un evento, ¿en cuántas salas se celebra? → En una (R4). Pregunta 2: Una sala, ¿cuántos eventos acoge? → Muchos.

Conclusión: SALA 1 — N EVENTO.

Repetido para las relaciones nuevas de BiblioRed:

Relación ¿Cuántos del lado derecho? ¿Cuántos del lado izquierdo? Cardinalidad
SUCURSAL – tiene – SALA Una sucursal tiene 1..6 salas Una sala está en 1 sucursal 1:N
TIPO_EVENTO – clasifica – EVENTO Un tipo clasifica muchos eventos Un evento tiene 1 tipo 1:N
SALA – acoge – EVENTO Una sala acoge muchos eventos Un evento usa 1 sala 1:N
SOCIO – se_inscribe – EVENTO Un socio se inscribe a muchos Un evento admite muchos socios N:M
PONENTE – participa – EVENTO Un ponente participa en muchos Un evento tiene varios ponentes N:M
EVENTO – trata – MATERIAL Un evento trata varios materiales Un material se trata en varios eventos N:M
EVENTO – tiene – INFORME Un evento tiene 0 o 1 informe Un informe es de 1 evento 1:1
PRESTAMO – genera – MULTA Un préstamo genera 0..3 multas (una por motivo) Una multa viene de 1 préstamo 1:N
MULTA – se_liquida – PAGO Una multa recibe varios pagos Un pago es de 1 multa 1:N
MATERIAL – tiene – EJEMPLAR Un material tiene 0..N ejemplares Un ejemplar es de 1 material 1:N

Cardinalidad mínima y máxima

Lo anterior es la cardinalidad máxima (1 o "muchos"). También existe la mínima (0 o 1), y es la que expresa la obligatoriedad. La notación completa, muy usada en Europa, escribe ambas: (0,1), (1,1), (0,N), (1,N).

   EVENTO ──(1,1)──◇ se_celebra_en ◇──(0,N)── SALA

Se lee: un evento se celebra en una sala como mínimo y como máximo (obligatorio, exactamente una); una sala acoge entre cero y muchos eventos. Ese (0,N) dice que puede existir una sala sin ningún evento, cosa que la cardinalidad 1:N sola no decía.

Un detalle que confunde a mucha gente: en la notación (mín,máx), los números se anotan en el lado de la entidad a la que describen, mientras que en la notación de pata de gallo los símbolos se dibujan junto a la entidad del otro extremo. Es la causa más frecuente de diagramas leídos al revés.

  1. Participación total o parcial: la otra mitad que todos confunden

La participación responde a una pregunta distinta de la cardinalidad: ¿tiene que participar toda instancia de esta entidad en la relación, o puede haber alguna que no participe?

  • Participación total (obligatoria): toda instancia participa. Se dibuja con línea doble en Chen, o con un trazo perpendicular | en pata de gallo.
  • Participación parcial (opcional): puede haber instancias que no participen. Círculo o en pata de gallo.

Que sean dos cosas distintas se ve mejor con un ejemplo donde no coinciden:

Relación Cardinalidad Participación de A Participación de B
EVENTO (A) — tiene — INFORME (B) 1:1 Parcial: hay eventos sin informe (R9) Total: no hay informe sin evento
MATERIAL (A) — tiene — EJEMPLAR (B) 1:N Parcial: un material recién catalogado puede no tener ejemplares aún (R2) Total: todo ejemplar es de algún material
SUCURSAL (A) — tiene — SALA (B) 1:N Total: toda sucursal tiene al menos una sala (R3, "entre 1 y 6") Total: toda sala está en una sucursal
SOCIO (A) — se_inscribe — EVENTO (B) N:M Parcial: la mayoría de socios no se inscribe a nada Parcial: un evento recién creado no tiene inscritos

El error clásico es decir "es 1:N" y creer que con eso está todo dicho. La cardinalidad dice cuántos; la participación dice si hace falta al menos uno. Son ejes independientes y se combinan libremente:

Participación parcial Participación total
Máx. 1 0 o 1 (opcional) Exactamente 1 (obligatorio)
Máx. N 0 o muchos 1 o muchos

Las consecuencias en la fase lógica son directísimas y por eso conviene fijarlo bien ahora:

Decisión conceptual Consecuencia en 04-03 / 04-04
Participación total del lado N en una 1:N La clave ajena es NOT NULL
Participación parcial del lado N La clave ajena admite NULL
Participación total del lado 1 ("toda sucursal tiene ≥1 sala") No se puede expresar con una restricción simple: necesita un disparador o validación en la aplicación

Esa última fila es una limitación real del modelo relacional que conviene conocer desde ya: "toda sucursal tiene al menos una sala" no lo garantiza ninguna clave ajena. Se documenta como regla de negocio y se decide dónde vive; el criterio general lo cerramos en 04-04.

  1. Las notaciones: Chen frente a pata de gallo

El modelo ER tiene el mismo contenido en cualquier notación; cambia el dibujo. Hay que conocer dos.

Notación de Chen (1976)

La original. Rectángulos para entidades, rombos para relaciones, óvalos para atributos, colgando de su entidad.

                 ┌──────────┐              ┌──────────┐
     (nombre)────│          │              │          │────(titulo)
                 │  SALA    │              │  EVENTO  │
     (aforo)─────│          │◇────────────◇│          │────(inicio)
                 └──────────┘   acoge      └──────────┘
                       1            N

Es muy expresiva —los atributos se ven, los atributos derivados llevan óvalo discontinuo, los multivaluados óvalo doble— y por eso se usa en la enseñanza. Y es impracticable en un dominio real: un diagrama de veinte entidades con todos sus atributos en óvalos no cabe en ninguna pantalla ni en ninguna pared.

Notación de pata de gallo (crow's foot, Bachman/Barker)

La que se usa hoy en la industria y la que implementan todas las herramientas. Las entidades son cajas con la lista de atributos dentro, las relaciones son líneas, y los símbolos de los extremos codifican cardinalidad y participación a la vez.

Los símbolos se leen en el extremo que toca a la entidad, y describen cuántas instancias de esa entidad corresponden a una del otro lado:

Símbolo ASCII Mínimo Máximo Se lee
Trazo + trazo || 1 1 Exactamente uno
Círculo + trazo o| 0 1 Cero o uno
Trazo + pata |{ 1 N Uno o muchos
Círculo + pata o{ 0 N Cero o muchos

Tabla de equivalencia entre notaciones

Concepto Chen Pata de gallo Mermaid erDiagram
Entidad fuerte Rectángulo simple Caja ENTIDAD { ... }
Entidad débil Rectángulo doble Caja, línea identificadora -- (línea sólida)
Relación Rombo Línea con etiqueta A ||--o{ B : "verbo"
Relación identificadora Rombo doble Línea continua --
Relación no identificadora — Línea discontinua ..
Atributo Óvalo Fila dentro de la caja Fila con tipo y nombre
Atributo clave Óvalo subrayado Marca PK PK
Atributo multivaluado Óvalo doble No existe: se saca a otra entidad Entidad aparte
Atributo derivado Óvalo discontinuo No existe: se anota o se omite Comentario
Atributo compuesto Óvalo con óvalos hijos No existe: columnas separadas Filas separadas
Cardinalidad máx. 1 1 junto al rombo || o o| || / o|
Cardinalidad máx. N N junto al rombo |{ o o{ |{ / o{
Participación total Línea doble Trazo | |
Participación parcial Línea simple Círculo o o
Relación ternaria Rombo con tres líneas No existe: se convierte en entidad Entidad intermedia

Fíjate en las cuatro filas donde pone "no existe". Pata de gallo pierde expresividad respecto a Chen en atributos multivaluados, derivados, compuestos y relaciones ternarias. No es un defecto casual: pata de gallo está a medio camino entre el modelo conceptual y el lógico, y esos cuatro conceptos desaparecen en la transformación a tablas (los veremos morir uno a uno en 04-03). Por eso la práctica habitual es: pensar en Chen, dibujar en pata de gallo y anotar en texto lo que la notación no recoge. Es exactamente lo que haremos con BiblioRed.

Una advertencia sobre mermaid

Mermaid implementa pata de gallo. Es una herramienta excelente porque el diagrama vive como texto en el repositorio, junto al código, y se versiona con él. Pero hereda las cuatro limitaciones anteriores y añade una propia: no dibuja jerarquías de generalización. Cuando aparezcan, en el apartado 8, las explicaremos con tablas y ASCII.

  1. El modelo ER extendido: generalización y especialización

El modelo ER básico no sabía expresar que "un libro es un tipo de material". El modelo ER extendido (EER) añade las jerarquías de tipo, y es exactamente lo que R1 necesita.

El problema de BiblioRed

R1 dice que el catálogo debe admitir libros, DVD, revistas y audiolibros. Todos comparten título, idioma, editorial, año y fecha de alta. Cada uno tiene lo suyo: ISBN y páginas el libro; duración, formato y región el DVD; ISSN, número y periodicidad la revista; duración, narrador y formato el audiolibro.

Modelarlo como cuatro entidades independientes rompe todo lo demás: un ejemplar tendría que apuntar a una de las cuatro y no se sabría a cuál; un préstamo tampoco; y la consulta C10 ("los diez materiales más prestados, desglosados por tipo") necesitaría unir cuatro consultas. Modelarlo como una sola entidad con todos los atributos deja narrador a NULL en el 90 % de las filas y hace imposible exigir que un libro tenga ISBN.

La solución es la generalización: una superentidad MATERIAL con lo común y cuatro subentidades con lo específico.

                        ┌───────────────────────┐
                        │       MATERIAL        │
                        │  material_id (PK)     │
                        │  titulo, idioma,      │
                        │  editorial, anio,     │
                        │  fecha_alta, autor    │
                        └───────────┬───────────┘
                                    │
                                   ╱d╲          d = disjunta
                                  ╱   ╲         doble línea = total
                        ══════════╧════╧══════════
                    │           │           │           │
            ┌───────┴──┐ ┌──────┴───┐ ┌─────┴────┐ ┌────┴──────┐
            │  LIBRO   │ │   DVD    │ │ REVISTA  │ │AUDIOLIBRO │
            │ isbn     │ │ duracion │ │ issn     │ │ duracion  │
            │ paginas  │ │ formato  │ │ numero   │ │ narrador  │
            │ encuad.  │ │ region   │ │ periodic.│ │ formato   │
            └──────────┘ │{subtitul}│ └──────────┘ └───────────┘
                         └──────────┘

Los dos ejes que hay que decidir

Toda jerarquía se caracteriza por dos propiedades independientes, y hay que fijarlas explícitamente porque cambian el diseño:

Eje 1 — Disyunción frente a solapamiento

Significado Ejemplo
Disjunta (disjoint, d) Una instancia pertenece a lo sumo a una subentidad Un material es libro o DVD o revista o audiolibro
Solapada (overlapping, o) Una instancia puede pertenecer a varias Una persona puede ser a la vez socio y ponente

Eje 2 — Totalidad frente a parcialidad

Significado Ejemplo
Total (línea doble) Toda instancia de la superentidad pertenece a alguna subentidad Todo material es de uno de los cuatro tipos
Parcial (línea simple) Puede haber instancias que no sean de ningún subtipo Un empleado que no es ni comercial ni técnico

Combinándolos salen cuatro casos, y cada uno se implementa distinto en 04-03:

Combinación Qué significa Consecuencia en el esquema
Total y disjunta Cada instancia está en exactamente una subentidad Se puede usar cualquiera de las tres estrategias; la "tabla por clase concreta" solo es viable aquí
Total y solapada Cada instancia está en una o más Fuerza tabla única o tabla por subclase
Parcial y disjunta Cero o una subentidad Tabla única o tabla por subclase; la superentidad debe poder existir sola
Parcial y solapada El caso más flexible y más costoso Tabla por subclase

La decisión de BiblioRed

La jerarquía de materiales es total y disjunta. Se discutió con el cliente y quedó escrito:

  • Total: todo lo que se cataloga es de uno de los cuatro tipos. Si mañana llegan mapas o partituras, se añade un subtipo. No existen materiales "genéricos".
  • Disjunta: un material concreto es libro o audiolibro, nunca ambos. La versión narrada de "El mapa del tiempo" es otro material distinto, con su propio identificador, no el mismo material con dos naturalezas. Esta pregunta se hizo explícitamente y la respuesta orienta todo el diseño.

Un contraejemplo útil para ver que no siempre es así: si BiblioRed decidiera modelar PERSONA como superentidad de SOCIO y PONENTE, esa jerarquía sería solapada (un socio puede dar un taller) y parcial (hay personas en el sistema que no son ni una cosa ni otra). En la v1.0 no se hace: R7 dice que los ponentes son entidad propia, y duplicar el nombre de las cuatro personas que son ambas cosas es un precio menor comparado con la complicación de una jerarquía solapada. Es una decisión consciente y va al registro de decisiones.

Las tres estrategias para llevar esta jerarquía a tablas —tabla única, tabla por subclase, tabla por clase concreta— con su tabla comparativa de ventajas e inconvenientes son el apartado 10 de la lección siguiente.

  1. Dibujar BiblioRed, decisión a decisión

Ahora recorremos el documento de requisitos de 04-01 y construimos el diagrama. El valor de este apartado está en las preguntas de cada paso, no en el resultado.

Paso 1 — Punto de partida: lo que ya existe

Siete entidades del esquema actual: SUCURSAL, AUTOR, SOCIO, LIBRO, EJEMPLAR, PRESTAMO, RESERVA. No se tocan por capricho, pero R1 obliga a un cambio estructural: LIBRO se convierte en subentidad de MATERIAL, y las relaciones que apuntaban a LIBRO (EJEMPLAR y RESERVA) pasan a apuntar a MATERIAL. Es el cambio más profundo de toda la ampliación y conviene identificarlo pronto.

Paso 2 — Salas (R3)

  • ¿Entidad? Sí: tiene atributos propios (aforo, planta, accesible) y ciclo de vida.
  • ¿Relación con sucursal? SUCURSAL 1 — N SALA.
  • ¿Participación? Total en los dos lados: toda sala está en una sucursal y toda sucursal tiene entre 1 y 6 salas.
  • Decisión fina: el nombre solo es único dentro de la sucursal (R3). Conceptualmente, SALA es una entidad débil de SUCURSAL con discriminante nombre.

Paso 3 — Tipos de evento (R5)

Aplicamos los criterios del apartado 8 de 04-01: tiene atributos propios (descripción, duración estándar), el usuario gestiona el conjunto de valores. Entidad, con relación TIPO_EVENTO 1 — N EVENTO. Participación total del lado del evento (todo evento tiene tipo), parcial del lado del tipo (puede haber un tipo recién creado sin eventos).

Paso 4 — Eventos (R4)

Entidad fuerte, con titulo, descripcion, inicio, fin, plazas_ofertadas, estado, publicado.

  • Relación con SALA: 1:N (una sala, muchos eventos).
  • Pregunta obligada de la participación: ¿puede haber un evento sin sala? Aquí es donde la coordinadora mencionó el cuentacuentos de verano en el patio. Decisión: participación parcial —la sala es opcional—, pero RN8 exige que si el evento está publicado, tenga sala. Se anota como regla de negocio para 04-04.
  • Atributo derivado: la sucursal del evento es la de su sala (R4). No se dibuja como relación con SUCURSAL: sería redundancia. Se anota como derivado.
  • Atributo derivado: las plazas libres (C2). Tampoco se almacena.

Paso 5 — Inscripciones (R6)

Aquí está el corazón de la ampliación.

  • ¿Cardinalidad? Un socio a muchos eventos, un evento con muchos socios: N:M.
  • ¿Tiene atributos propios? Sí: fecha, estado, acompañantes. Relación N:M con atributos.
  • ¿Identificador? La pareja (evento, socio), que es literalmente la regla de R6 ("un socio no puede inscribirse dos veces al mismo evento"). Es decir: entidad débil dependiente de dos propietarias.
  • ¿Participación? Parcial en ambos lados.

Este es el punto donde el modelo conceptual paga su precio: en Chen sería un rombo con tres óvalos colgando; en pata de gallo hay que dibujarlo ya como una caja intermedia. No es un error de la notación, es el anticipo de la transformación de 04-03.

Paso 6 — Ponentes y participaciones (R7)

  • PONENTE: entidad fuerte (nombre, apellidos, email, biografía, si es externo).
  • Relación con EVENTO: N:M con atributos (rol, honorarios).
  • La trampa: R7 dice que en un mismo evento una persona puede desempeñar más de un papel. Eso significa que la pareja (evento, ponente) no identifica la participación: hace falta el rol. Conceptualmente es una relación ternaria entre EVENTO, PONENTE y ROL.

¿Es ROL una entidad de verdad? Aplicando los criterios de 04-01: conjunto pequeño (moderador, tallerista, autor invitado, presentador), estable, sin atributos propios, nadie lo gestiona. Es un atributo, no una entidad. Así que en lugar de una ternaria pura tenemos una N:M identificada por (evento, ponente, rol), con rol como parte del identificador. Es la forma habitual en que las ternarias aparentes se resuelven en la práctica, y en 04-03 volveremos sobre ello con la regla 9.

Paso 7 — Materiales tratados en un evento (R8)

N:M limpia entre EVENTO y MATERIAL, con un atributo propio: papel (principal / recomendado). Participación parcial en ambos lados. Es el ejemplo más simple de N:M del diagrama y sirve de contraste con las dos anteriores.

Paso 8 — Informe del evento (R9)

  • Cardinalidad 1:1: un evento tiene como mucho un informe, un informe es de un evento.
  • Participación: parcial del lado del evento (muchos eventos no tienen informe), total del lado del informe.
  • Pregunta obligada: ¿por qué no meter los tres campos del informe dentro de EVENTO? Porque solo tienen valor para eventos ya celebrados; en EVENTO estarían a NULL en la mayoría de las filas y no se podría distinguir "aún no redactado" de "cero asistentes". La discusión completa de las tres opciones para una 1:1 es la regla 6 de 04-03.

Paso 9 — Multas y pagos (R10, R11)

  • MULTA se relaciona con PRESTAMO: 1:N, porque un préstamo puede generar hasta tres multas, una por motivo.
  • Decisión discutible y por eso interesante: ¿se relaciona la multa también con el socio? El socio se puede obtener por el préstamo, así que sería derivado. Pero R10 admite multas por pérdida que podrían no venir de un préstamo (un socio que pierde un material que consultó en sala). Se decide mantener la relación directa con SOCIO y hacer que la relación con PRESTAMO sea de participación parcial. Queda registrado como decisión, con su motivo.
  • PAGO es entidad débil de MULTA (1:N): un pago no existe sin su multa. Participación total del lado del pago, parcial del lado de la multa (una multa recién emitida no tiene pagos).
  • Atributo derivado: el importe pendiente (R11). No se almacena.

Paso 10 — Atributos multivaluados (R12, R1)

Los dos plurales del enunciado se convierten en entidades débiles:

  • TELEFONO débil de SOCIO, con discriminante numero y atributo tipo.
  • SUBTITULO débil de DVD, con discriminante idioma.

Paso 11 — Atributo compuesto (R13)

La dirección de la sucursal se descompone en calle, número, código postal y ciudad. No genera entidad ni relación: es un cambio dentro de la caja de SUCURSAL.

Resumen de las decisiones registradas

# Decisión Alternativa descartada Motivo
D1 LIBRO pasa a ser subtipo de MATERIAL Cuatro entidades independientes Ejemplares, préstamos y reservas necesitan una entidad común (R1, C10)
D2 Jerarquía total y disjunta Solapada Un audiolibro es otro material, no el mismo con dos caras
D3 TIPO_EVENTO es entidad Atributo de texto El usuario debe poder añadir tipos (R5)
D4 La sala del evento es opcional Obligatoria Eventos al aire libre; RN8 la exige solo si está publicado
D5 ROL es atributo, no entidad Ternaria pura con entidad ROL Conjunto estable y sin atributos propios
D6 MULTA se relaciona con SOCIO y con PRESTAMO Solo con PRESTAMO Puede haber multas sin préstamo (pérdida en sala)
D7 El informe va en entidad aparte Columnas dentro de EVENTO Nulos masivos y ambigüedad entre "sin redactar" y "cero"
D8 PERSONA no se generaliza sobre SOCIO y PONENTE Jerarquía solapada parcial Complejidad desproporcionada para cuatro casos
D9 Plazas libres, deuda pendiente y sucursal del evento son derivados Columnas almacenadas Redundancia; se revisará por rendimiento en 05-04

  1. Entregable: el diagrama ER completo de BiblioRed ampliado

Este es el resultado. Está en notación de pata de gallo con mermaid, integra lo existente y lo nuevo, y va acompañado de las anotaciones que la notación no puede expresar.

erDiagram
    SUCURSALES ||--|{ SALAS : "dispone de"
    SUCURSALES ||--o{ SOCIOS : "da de alta"
    SUCURSALES ||--o{ EJEMPLARES : "custodia"

    SOCIOS ||--o{ TELEFONOS_SOCIO : "tiene"
    SOCIOS ||--o{ PRESTAMOS : "realiza"
    SOCIOS ||--o{ RESERVAS : "solicita"
    SOCIOS ||--o{ INSCRIPCIONES : "se inscribe"
    SOCIOS ||--o{ MULTAS : "acumula"

    AUTORES ||--o{ MATERIALES : "escribe"

    MATERIALES ||--o{ EJEMPLARES : "se materializa en"
    MATERIALES ||--o{ RESERVAS : "es reservado en"
    MATERIALES ||--o{ EVENTOS_MATERIALES : "se trata en"
    MATERIALES ||--o| MATERIALES_LIBRO : "es un"
    MATERIALES ||--o| MATERIALES_DVD : "es un"
    MATERIALES ||--o| MATERIALES_REVISTA : "es un"
    MATERIALES ||--o| MATERIALES_AUDIOLIBRO : "es un"
    MATERIALES_DVD ||--o{ SUBTITULOS_DVD : "ofrece"

    EJEMPLARES ||--o{ PRESTAMOS : "es prestado en"
    PRESTAMOS ||--o{ MULTAS : "genera"
    MULTAS ||--o{ PAGOS : "se liquida con"

    SUCURSALES {
        int sucursal_id PK
        varchar nombre UK
        varchar dir_calle "compuesto R13"
        varchar dir_numero
        char dir_codigo_postal
        varchar dir_ciudad
        varchar telefono
        date fecha_apertura
    }
    SALAS {
        int sala_id PK
        int sucursal_id FK "debil: nombre unico por sucursal"
        varchar nombre
        int aforo
        smallint planta
        boolean accesible
    }
    SOCIOS {
        int socio_id PK
        varchar nombre
        varchar apellidos
        varchar email UK
        date fecha_alta
        int sucursal_id FK
        boolean activo
    }
    TELEFONOS_SOCIO {
        int socio_id PK,FK "debil de SOCIOS"
        varchar numero PK
        varchar tipo "movil / fijo / trabajo"
    }
    AUTORES {
        int autor_id PK
        varchar nombre
        varchar apellidos
        varchar nacionalidad
        smallint anio_nacimiento
    }
    MATERIALES {
        int material_id PK
        varchar tipo_material "libro / dvd / revista / audiolibro"
        varchar titulo
        int autor_id FK "opcional"
        varchar editorial
        smallint anio_publicacion
        varchar idioma
        date fecha_alta
    }
    MATERIALES_LIBRO {
        int material_id PK,FK
        varchar isbn UK
        int num_paginas
        varchar encuadernacion
    }
    MATERIALES_DVD {
        int material_id PK,FK
        int duracion_min
        varchar formato_video
        smallint codigo_region
    }
    MATERIALES_REVISTA {
        int material_id PK,FK
        varchar issn
        varchar numero
        varchar periodicidad
    }
    MATERIALES_AUDIOLIBRO {
        int material_id PK,FK
        int duracion_min
        varchar narrador
        varchar formato_audio
    }
    SUBTITULOS_DVD {
        int material_id PK,FK "multivaluado R1"
        varchar idioma PK
    }
    EJEMPLARES {
        int ejemplar_id PK
        varchar codigo UK
        int material_id FK "debil: num_ejemplar unico por material"
        smallint num_ejemplar
        int sucursal_id FK
        varchar estado
        date fecha_adquisicion
    }
    PRESTAMOS {
        int prestamo_id PK
        int socio_id FK
        int ejemplar_id FK
        date fecha_prestamo
        date fecha_devolucion_prevista
        date fecha_devolucion "nulo si no devuelto"
        numeric recargo "OBSOLETA, ver MULTAS"
    }
    RESERVAS {
        int reserva_id PK
        int socio_id FK
        int material_id FK
        date fecha_reserva
        date fecha_expiracion
        varchar estado
    }
    MULTAS {
        int multa_id PK
        int socio_id FK
        int prestamo_id FK "opcional D6"
        varchar motivo "retraso / deterioro / perdida"
        numeric importe
        date fecha_emision
        varchar estado
    }
    PAGOS {
        int pago_id PK
        int multa_id FK "debil de MULTAS"
        timestamptz fecha_pago
        numeric importe
        varchar metodo
        varchar referencia
    }

    TIPOS_EVENTO ||--o{ EVENTOS : "clasifica"
    SALAS ||--o{ EVENTOS : "acoge"
    EVENTOS ||--o{ INSCRIPCIONES : "recibe"
    EVENTOS ||--o| INFORMES_EVENTO : "se documenta en"
    EVENTOS ||--o{ PARTICIPACIONES : "cuenta con"
    PONENTES ||--o{ PARTICIPACIONES : "interviene en"
    EVENTOS ||--o{ EVENTOS_MATERIALES : "trata"

    TIPOS_EVENTO {
        int tipo_evento_id PK
        varchar codigo UK
        varchar nombre
        varchar descripcion
        int duracion_estandar_min
    }
    EVENTOS {
        int evento_id PK
        varchar titulo
        varchar descripcion
        int tipo_evento_id FK
        int sala_id FK "opcional D4"
        timestamptz inicio
        timestamptz fin
        int plazas_ofertadas
        varchar estado
        boolean publicado
    }
    INSCRIPCIONES {
        int evento_id PK,FK "N:M con atributos R6"
        int socio_id PK,FK
        timestamptz fecha_inscripcion
        varchar estado
        smallint acompanantes
    }
    INFORMES_EVENTO {
        int evento_id PK,FK "relacion 1:1 R9"
        int asistentes_reales
        numeric valoracion_media
        varchar observaciones
        date fecha_redaccion
    }
    PONENTES {
        int ponente_id PK
        varchar nombre
        varchar apellidos
        varchar email UK
        varchar biografia
        boolean externo
    }
    PARTICIPACIONES {
        int evento_id PK,FK "ternaria resuelta D5"
        int ponente_id PK,FK
        varchar rol PK
        numeric honorarios
    }
    EVENTOS_MATERIALES {
        int evento_id PK,FK "N:M R8"
        int material_id PK,FK
        varchar papel "principal / recomendado"
    }

Lo que el diagrama no puede decir (anotaciones obligatorias)

Como advertimos en el apartado 7, hay cuatro conceptos que pata de gallo no representa. Van aquí, y forman parte del entregable tanto como el dibujo:

A. La jerarquía de generalización. Las cuatro relaciones MATERIALES ||--o| MATERIALES_* no son cuatro relaciones 1:1 independientes: son una jerarquía total y disjunta. La restricción real, que ninguna línea expresa, es:

Todo material pertenece a exactamente una de las cuatro subentidades, y la subentidad debe coincidir con el valor de tipo_material.

B. Los atributos derivados. No aparecen en ninguna caja, deliberadamente:

Derivado Fórmula
Plazas libres de un evento plazas_ofertadas − Σ(1 + acompanantes) de las inscripciones confirmadas
Importe pendiente de una multa importe − Σ pagos.importe
Sucursal de un evento eventos → salas → sucursal_id
Deuda total de un socio Σ pendientes de sus multas en estado pendiente
Días de retraso fecha_devolucion − fecha_devolucion_prevista

C. Las entidades débiles. Mermaid dibuja SALAS como una entidad normal. La afirmación real es que el nombre de la sala solo es único dentro de su sucursal, lo mismo que num_ejemplar dentro de su material. Anotado en los comentarios de las cajas y recogido en 04-03.

D. Las reglas de negocio RN1–RN10. Ninguna es dibujable. Siguen vivas en el documento de 04-01 y se convierten en restricciones en 04-04.

Validación del diagrama contra las consultas

Antes de dar por bueno un modelo conceptual, se recorre la lista de consultas del documento de requisitos y se comprueba que cada una tiene un camino en el diagrama:

Consulta Camino en el diagrama ¿Responde?
C1 Agenda del mes por sucursal EVENTOS → SALAS → SUCURSALES, filtrando publicado Sí
C2 Plazas libres EVENTOS → INSCRIPCIONES (derivado) Sí
C3 Inscritos con teléfono EVENTOS → INSCRIPCIONES → SOCIOS → TELEFONOS_SOCIO Sí
C4 Historial de un socio SOCIOS → INSCRIPCIONES → EVENTOS Sí
C5 Ocupación por sala y trimestre SALAS → EVENTOS → INSCRIPCIONES Sí
C6 Recaudación por mes y método PAGOS Sí
C7 Socios con deuda > 20 € SOCIOS → MULTAS → PAGOS (derivado) Sí
C8 Catálogo por tipo e idioma MATERIALES Sí
C9 DVD con subtítulos en catalán MATERIALES_DVD → SUBTITULOS_DVD Sí
C10 Más prestados por tipo PRESTAMOS → EJEMPLARES → MATERIALES Sí
C11 Ponentes con > 3 eventos PONENTES → PARTICIPACIONES Sí
C12 Eventos sin informe EVENTOS anti-join con INFORMES_EVENTO Sí

Doce de doce. Si alguna hubiera fallado, el diagrama estaría incompleto, y es infinitamente más barato descubrirlo aquí que después de escribir el DDL.

  1. Herramientas para dibujar diagramas

Un repaso breve; el detalle está en la lección 09-03.

Herramienta Tipo Nota
Mermaid Diagrama como texto El que hemos usado. Vive en el repositorio, se versiona con el código, se renderiza en GitHub y en editores. Limitado en jerarquías y ternarias.
dbdiagram.io / DBML Diagrama como texto, en la web Sintaxis específica de bases de datos; exporta a SQL.
PlantUML Diagrama como texto Más expresivo que mermaid; soporta jerarquías.
draw.io / diagrams.net Dibujo libre Control total del aspecto, ningún control de la coherencia.
pgModeler, MySQL Workbench, DBeaver Modelado con ingeniería inversa Leen una base existente y dibujan su esquema; útiles para documentar lo que ya hay.
Papel y pizarra — Sigue siendo la mejor para las dos primeras horas.

El criterio de elección, más importante que la herramienta: para el modelo conceptual, prioriza la velocidad de cambio (papel, pizarra, mermaid), porque vas a redibujarlo diez veces. Para el diagrama final que acompaña al esquema, prioriza que viva junto al código y se versione con él, porque un diagrama en el disco duro de alguien está obsoleto en tres semanas.

Errores Comunes y Consejos

Confundir cardinalidad con participación. El error número uno. "Es 1:N" no dice si el lado N puede estar vacío. Las dos preguntas son distintas y hay que hacer las dos, siempre, para cada relación.

Poner el símbolo de pata de gallo en el lado equivocado. Los símbolos van junto a la entidad que describen, contando cuántas instancias de esa entidad hay por cada una del otro lado. En la notación (mín,máx) es al revés. Un diagrama leído al revés genera claves ajenas en el lado incorrecto, que es de los errores más caros de corregir.

Modelar una relación N:M sin preguntarse si tiene atributos. Casi todas los tienen. Si INSCRIPCIONES se hubiera dibujado como una simple N:M sin caja, no habría dónde poner la fecha, el estado ni los acompañantes, y R6 habría quedado sin cubrir.

Crear entidades para lo que son atributos. Una tabla idiomas con dos columnas, una tabla estados con cuatro filas, una tabla nacionalidades... Multiplican los JOIN sin aportar nada. Aplica los cinco criterios de 04-01 antes de crear cada caja.

Dibujar relaciones redundantes. Si EVENTO → SALA → SUCURSAL, dibujar además EVENTO → SUCURSAL crea un ciclo en el que las dos rutas pueden dar respuestas distintas. Cada vez que aparezca un ciclo en el diagrama, hay que justificarlo o eliminarlo: casi siempre una de las aristas es derivada.

Olvidar la dimensión temporal. "Un socio pertenece a una sucursal" es 1:N hoy. Si hace falta saber a cuál pertenecía en 2024, es una N:M con fechas. Preguntar "¿necesitas el histórico?" en cada relación cuesta cinco segundos.

Meter atributos de rendimiento en el modelo conceptual. num_inscritos en EVENTOS es la respuesta a un problema que aún no existe. En el conceptual va como derivado; si la medición demuestra que hace falta, se almacena en la fase física con los ojos abiertos (05-04).

Consejo: nombra las relaciones con un verbo y en un solo sentido. "Acoge", "genera", "se liquida con". Un diagrama con relaciones sin nombre o llamadas "tiene" es un diagrama que no se puede leer en voz alta, y leerlo en voz alta es la mejor validación disponible.

Consejo: dibuja primero sin atributos. Diez cajas y las líneas entre ellas. La estructura se ve mucho mejor y los atributos, que son la parte fácil, se añaden después.

Consejo: cuenta las líneas que salen de cada entidad. Una entidad con siete relaciones suele estar haciendo dos trabajos y ser candidata a dividirse. Una entidad con ninguna suele sobrar o estar mal conectada.

Ejercicios

Ejercicio 1 — Cardinalidad y participación

Para cada afirmación, determina la cardinalidad y la participación de cada lado, y exprésalo en notación de pata de gallo con mermaid (A ||--o{ B : "verbo"). Justifica la participación citando el requisito.

  1. Un ejemplar pertenece a una sucursal; una sucursal custodia muchos ejemplares.
  2. Un pago liquida una multa; una multa se liquida con varios pagos.
  3. Un tipo de evento clasifica muchos eventos; un evento tiene un tipo.
  4. Un socio realiza muchos préstamos; un préstamo es de un socio.
  5. Un evento tiene como mucho un informe; un informe es de un evento.

Ejercicio 2 — Modelar una ampliación nueva

BiblioRed añade a la v1.1 el siguiente requisito:

R15 — Préstamo de equipos a asociaciones. Las asociaciones del barrio (con nombre, CIF, persona de contacto y teléfono) pueden llevarse en préstamo equipos técnicos (proyectores, altavoces, pantallas). Cada equipo tiene un código de inventario, una descripción, la sucursal donde se guarda y su estado. Un vale de préstamo puede incluir varios equipos a la vez, tiene fecha de salida, fecha prevista de devolución y fecha real. Si un equipo vuelve estropeado se registra una incidencia con fecha, descripción y coste estimado de reparación. Un equipo puede tener varias incidencias a lo largo de su vida.

Dibuja el fragmento de diagrama ER en mermaid. Indica para cada relación su cardinalidad y participación, señala si hay entidades débiles, atributos multivaluados o derivados, y anota al menos dos decisiones de diseño con su motivo.

Ejercicio 3 — Jerarquía de generalización

BiblioRed se plantea unificar SOCIOS y PONENTES bajo una superentidad PERSONAS con los datos comunes (nombre, apellidos, email, teléfono).

  1. Determina si la jerarquía sería disjunta o solapada y total o parcial, justificándolo con los requisitos.
  2. Enumera dos ventajas y dos inconvenientes concretos de hacerlo.
  3. Decide si lo harías en la v1.0 y escribe la entrada del registro de decisiones (decisión / alternativa descartada / motivo).

Soluciones

Solución al Ejercicio 1

erDiagram
    SUCURSALES ||--o{ EJEMPLARES : "custodia"
    MULTAS ||--o{ PAGOS : "se liquida con"
    TIPOS_EVENTO ||--o{ EVENTOS : "clasifica"
    SOCIOS ||--o{ PRESTAMOS : "realiza"
    EVENTOS ||--o| INFORMES_EVENTO : "se documenta en"
# Cardinalidad Participación izquierda Participación derecha Justificación
1 1:N Parcial (o{): una sucursal nueva puede no tener ejemplares aún Total (||): todo ejemplar está en alguna sucursal R2
2 1:N Parcial: una multa recién emitida no tiene pagos Total: no existe pago sin multa (entidad débil) R11
3 1:N Parcial: un tipo recién creado puede no tener eventos Total: todo evento tiene tipo R4, R5
4 1:N Parcial: la mayoría de socios no tiene préstamos activos, y hay socios sin ninguno Total: todo préstamo es de un socio Esquema existente
5 1:1 Parcial (o|): la mayoría de eventos no tiene informe Total: no hay informe sin evento R9

Nota sobre el caso 5: o| en el extremo derecho es lo que distingue una 1:1 opcional de una 1:1 obligatoria, y es precisamente lo que justificará poner el informe en tabla aparte en 04-03.

Solución al Ejercicio 2

erDiagram
    ASOCIACIONES ||--o{ VALES_EQUIPO : "solicita"
    SUCURSALES ||--o{ EQUIPOS : "guarda"
    SUCURSALES ||--o{ VALES_EQUIPO : "tramita"
    VALES_EQUIPO ||--|{ LINEAS_VALE : "incluye"
    EQUIPOS ||--o{ LINEAS_VALE : "se presta en"
    EQUIPOS ||--o{ INCIDENCIAS_EQUIPO : "sufre"

    ASOCIACIONES {
        int asociacion_id PK
        varchar nombre
        varchar cif UK
        varchar contacto_nombre
        varchar contacto_telefono
    }
    EQUIPOS {
        int equipo_id PK
        varchar codigo_inventario UK
        varchar descripcion
        int sucursal_id FK
        varchar estado
    }
    VALES_EQUIPO {
        int vale_id PK
        int asociacion_id FK
        int sucursal_id FK
        date fecha_salida
        date fecha_prevista
        date fecha_devolucion "nulo si no devuelto"
    }
    LINEAS_VALE {
        int vale_id PK,FK "debil de VALES_EQUIPO"
        int equipo_id PK,FK
        varchar estado_devolucion
    }
    INCIDENCIAS_EQUIPO {
        int incidencia_id PK
        int equipo_id FK
        int vale_id FK "opcional"
        date fecha
        varchar descripcion
        numeric coste_estimado
    }
Relación Cardinalidad Participación Nota
ASOCIACIONES – VALES_EQUIPO 1:N Parcial / Total Una asociación puede no haber pedido nada nunca
VALES_EQUIPO – LINEAS_VALE 1:N Total en ambos lados (||--|{) Un vale sin ningún equipo no tiene sentido
EQUIPOS – LINEAS_VALE 1:N Parcial / Total Un equipo puede no haberse prestado nunca
EQUIPOS – INCIDENCIAS_EQUIPO 1:N Parcial / Total La mayoría de equipos no tiene incidencias
  • Entidad débil: LINEAS_VALE, identificada por (vale_id, equipo_id). Es la N:M entre vale y equipo, y aparece porque "un vale incluye varios equipos" (el plural del enunciado).
  • Atributo multivaluado: ninguno explícito. Si se pidieran varios teléfonos de contacto por asociación, aparecería otro.
  • Atributos derivados: días de retraso del vale (fecha_devolucion − fecha_prevista), coste total de incidencias de un equipo.

Decisiones registradas:

Decisión Alternativa descartada Motivo
ASOCIACIONES es entidad propia, no un tipo de SOCIOS Reutilizar socios con un campo es_asociacion Los atributos son distintos (CIF, persona de contacto) y las reglas de préstamo también; mezclarlos produciría nulos masivos y CHECK condicionales
INCIDENCIAS_EQUIPO cuelga de EQUIPOS, no de LINEAS_VALE Colgarla del vale Un equipo puede estropearse fuera de un préstamo; la relación con el vale se conserva como opcional para saber quién lo devolvió así
La persona de contacto es atributo, no entidad Entidad CONTACTOS En v1.1 no tiene atributos propios ni ciclo de vida independiente; si mañana hacen falta varios contactos por asociación, se promociona

Solución al Ejercicio 3

1. Naturaleza de la jerarquía.

  • Solapada: nada impide que un socio de BiblioRed imparta un taller. R7 dice explícitamente que los ponentes pueden ser "personal propio o profesionales externos", y ninguna de las dos categorías excluye ser socio. Una persona podría ser socio y ponente a la vez.
  • Parcial: si la superentidad PERSONAS recogiera también, por ejemplo, contactos de asociaciones o personal administrativo, habría personas que no son ni socios ni ponentes. Incluso limitándola a los dos subtipos actuales, es parcial en el sentido de que nada garantiza que toda persona registrada sea de uno de los dos tipos.

Por tanto: jerarquía parcial y solapada, la combinación más flexible y también la más costosa de implementar.

2. Ventajas e inconvenientes.

Ventajas Inconvenientes
Los datos de contacto de una persona que es socia y ponente están en un solo sitio: se cumple "una cosa, un sitio" y un cambio de email se hace una vez Toda consulta sobre socios pasa a necesitar un JOIN adicional: C3, C4 y C7 se complican sin ganar nada
El correo electrónico sería único a nivel de persona, no por tabla, evitando que la misma persona figure con dos direcciones distintas La jerarquía solapada impide la estrategia de tabla por clase concreta y obliga a comprobar la coherencia entre subtipos
Facilita futuros subtipos (personal, contacto de asociación) sin duplicar campos Sobre-ingeniería para cuatro casos reales de solapamiento: se paga complejidad permanente por un beneficio marginal

3. Decisión para la v1.0: no hacerlo. Entrada del registro:

Decisión Alternativa descartada Motivo
SOCIOS y PONENTES se mantienen como entidades independientes; no se crea la superentidad PERSONAS Jerarquía de generalización parcial y solapada sobre PERSONAS La coordinación estima cuatro casos de solapamiento sobre 12.000 socios. El coste es un JOIN extra en todas las consultas de socios (C3, C4, C7) y comprobaciones de coherencia entre subtipos, frente al beneficio de evitar cuatro duplicados. Se revisará si el catálogo de personas crece con más subtipos (personal, contactos de asociaciones).

Esta última fila ilustra el criterio del apartado 12.5 de la lección 04-01: la generalización es correcta desde el punto de vista teórico y sobre-ingeniería desde el punto de vista práctico. El diseño no es el modelo más puro, sino el más adecuado al problema real.

Conclusión

Esta lección ha convertido catorce requisitos en prosa en un modelo conceptual completo.

  • Un modelo conceptual describe qué existe y cómo se relaciona, sin comprometerse con ninguna tecnología. Eso le permite discutirse con quien no es informático, servir igual para relacional que para documental, y —lo más valioso— hacer visibles los agujeros que la prosa tolera.
  • Las entidades son fuertes o débiles. Una entidad débil no se identifica sola: necesita la de su propietaria, y su identificador es parcial. En BiblioRed lo son los ejemplares, las inscripciones, los teléfonos, los pagos y las salas.
  • Los atributos son de cinco tipos y cada uno se transformará distinto: simple (columna), compuesto (varias columnas), multivaluado (tabla aparte), derivado (no se almacena) e identificador.
  • Las relaciones se detectan en los verbos. Su grado es casi siempre binario; las reflexivas necesitan roles nombrados y las ternarias casi siempre esconden algo más simple. Lo decisivo: las relaciones pueden tener atributos propios, y la regla infalible para detectarlos es que necesiten ambas claves para tener valor.
  • La cardinalidad (1:1, 1:N, N:M) se determina con dos preguntas, una por sentido. La participación (total o parcial) responde a una pregunta distinta —si puede haber instancias que no participen— y es un eje independiente. Confundirlas es el error más frecuente del modelado.
  • Se conocen dos notaciones: Chen, más expresiva y solo viable en dominios pequeños, y pata de gallo, la de la industria, que pierde cuatro conceptos (multivaluados, derivados, compuestos y ternarias) precisamente porque están a punto de desaparecer en la transformación a tablas. La práctica correcta es pensar en Chen, dibujar en pata de gallo y anotar en texto lo que el dibujo no recoge.
  • El modelo ER extendido aporta la generalización/especialización, con dos ejes que hay que fijar siempre: disjunta o solapada y total o parcial. La jerarquía de materiales de BiblioRed es total y disjunta, y esa decisión condiciona todo lo que viene después.
  • El diagrama de BiblioRed se construyó en once pasos, con nueve decisiones registradas con su motivo y su alternativa descartada.
  • El entregable es el diagrama ER completo en mermaid, con veintiuna entidades, más las cuatro anotaciones que la notación no puede expresar: la jerarquía, los derivados, las entidades débiles y las diez reglas de negocio.
  • El diagrama se validó contra las doce consultas del documento de requisitos, y las doce tienen camino. Esa comprobación es lo que separa un dibujo bonito de un modelo utilizable.

Tenemos el dibujo, tenemos las anotaciones y tenemos la validación. Lo que no tenemos todavía es una sola tabla. En la lección siguiente, 04-03 Transformación de Diagramas ER a Esquemas Relacionales, aprenderemos el algoritmo que convierte este diagrama en CREATE TABLE: diez reglas mecánicas —entidad fuerte, atributo compuesto, multivaluado, derivado, 1:N, 1:1, N:M, entidad débil, ternaria y jerarquía— cada una con su ejemplo de BiblioRed y su SQL. Ahí es donde los rombos se convierten en claves ajenas, los atributos multivaluados en tablas y esa jerarquía total y disjunta de materiales se resuelve, por fin, eligiendo entre tres estrategias con consecuencias muy distintas.

◄ Anterior
◄
Siguiente ►
►

Fundamentos de Bases de Datos

Módulo 1: Introducción a las Bases de Datos

Módulo 2: Bases de Datos Relacionales

Módulo 3: Bases de Datos No Relacionales

Módulo 4: Diseño de Esquemas

Módulo 5: Normalización

Módulo 6: Transacciones, Rendimiento y Seguridad

Módulo 7: Ejercicios Prácticos

Módulo 8: Casos de Estudio

Módulo 9: Recursos Adicionales

El Proyecto | Sobre nosotros | Contribuir | Donaciones | Licencia
© Copyright 2026. Todos los derechos reservados