Banco de ejercicios

1. RESERVAS está en plural. Debe ser RESERVA: la entidad nombra qué es cada instancia.

2. o id_reserva. Es el identificador, así que debe ser #. Un UID nunca puede ser opcional.

3. * fecha_cancelacion. La gran mayoría de las reservas nunca se cancelan. Marcarla obligatoria haría imposible guardar una reserva vigente. Debe ser o.

4. # email_cliente. Dos problemas: como UID falla (el mismo cliente hace muchas reservas, así que ni siquiera es único), y el cliente no va como atributo suelto sino como entidad relacionada.

5. * precio_total es un atributo derivado. Se calcula con cantidad_noches y la tarifa, así que guardarlo duplica información que puede quedar inconsistente.

Aunque acá hay matiz: el precio de una reserva es un valor histórico, igual que el precio_unitario de una factura. Si la tarifa de la habitación sube después, la reserva tiene que seguir diciendo lo que se cobró. En ese caso guardarlo es correcto — pero entonces hay que guardar el precio acordado, no recalcularlo. La decisión depende del negocio, y lo que se evalúa es que sepas justificarla.

┌────────────────────────────────┐
│ RESERVA                        │
├────────────────────────────────┤
│ # id_reserva                   │
│ * fecha_reserva                │
│ * cantidad_noches              │
│ * precio_acordado              │
│ o fecha_cancelacion            │
└────────────────────────────────┘
     │
     └── relación hacia CLIENTE y hacia HABITACION

Los sufijos _paciente y _medico son la pista: cada vez que varios atributos comparten un sufijo, ahí hay una entidad escondida.

┌──────────────────────┐   ┌──────────────────┐   ┌──────────────────────┐
│ PACIENTE             │   │ CONSULTA         │   │ MEDICO               │
├──────────────────────┤   ├──────────────────┤   ├──────────────────────┤
│ # id_paciente        │──<│ * fecha          │>──│ # matricula          │
│ * nombre             │   │ * diagnostico    │   │ * nombre             │
│ o telefono           │   └──────────────────┘   │ * especialidad       │
│ o obra_social        │                          └──────────────────────┘
└──────────────────────┘

Lo que se gana:

• El teléfono de un paciente se escribe una vez, no una por consulta. Si cambia, se corrige en un solo lugar.
• Un paciente puede existir aunque nunca se haya atendido (se registró y todavía no vino).
• Un médico también, y su especialidad no se repite en cada consulta que atendió.
• Borrar una consulta no borra al paciente ni al médico.

Detalles de las decisiones:

• matricula es el UID natural de MEDICO — es única por ley, obligatoria y no cambia. Es uno de los pocos casos donde un UID natural es claramente la mejor opción.
• telefono y obra_social pasaron a o. Estaban como * porque en la tabla plana toda consulta tenía que llenar todo; ya separados, un paciente puede no tener obra social o no haber dejado teléfono.
• CONSULTA es la entidad intermedia de la N:M entre pacientes y médicos, con sus atributos propios fecha y diagnostico. Su UID no es barrado: el mismo paciente puede volver al mismo médico muchas veces, así que corresponde un id_consulta propio, o incluir la fecha en el UID.

a) EMPLEADO ─────< DEPARTAMENTO

Se lee: “Cada empleado debe trabajar en uno o más departamentos.”

La pata de gallo está del lado equivocado. Los “muchos” son los empleados, no los departamentos. Correcto:

DEPARTAMENTO - - - - - - - -< EMPLEADO

b) AUTOR >- - - - - LIBRO

Se lee: “Cada libro puede ser escrito por uno o más autores” y “cada autor puede escribir uno y solo un libro.”

Los dos extremos están invertidos: la pata de gallo debería tocar a LIBRO, y el trazo del lado de AUTOR debería ser continuo (todo libro tiene autor). Correcto:

AUTOR - - - - - - - -< LIBRO

c) FACTURA ──────── LINEA_FACTURA

Se lee: “Cada factura debe tener una y sola una línea.”

Falta la pata de gallo: una factura tiene varias líneas. Y además el lado de LINEA_FACTURA debería ser obligatorio pero el de FACTURA continuo también tiene sentido acá (una factura sin ninguna línea no significa nada). Correcto:

FACTURA ───────────────< LINEA_FACTURA

El patrón de los tres: el error es siempre el mismo, poner la pata de gallo en la entidad que la frase nombra primero en vez de en la que tiene muchas instancias. Leer en voz alta lo detecta cada vez.

┌──────────────────┐   ┌────────────────────┐   ┌──────────────────┐
│ PROVEEDOR        │   │ ABASTECIMIENTO     │   │ PRODUCTO         │
├──────────────────┤   ├────────────────────┤   ├──────────────────┤
│ # cuit           │──┼<│ * precio          │>┼─│ # codigo         │
│ * nombre         │   │ * dias_entrega     │   │ * nombre         │
│ o telefono       │   └────────────────────┘   │ * stock          │
└──────────────────┘                            └──────────────────┘

Lectura en voz alta:

Cada ABASTECIMIENTO debe corresponder a un y solo un PROVEEDOR. Cada ABASTECIMIENTO debe corresponder a un y solo un PRODUCTO. Cada PROVEEDOR puede abastecer uno o más PRODUCTOS. Cada PRODUCTO puede ser abastecido por uno o más PROVEEDORES.

Las decisiones:

• cuit es un buen UID natural de PROVEEDOR: único por ley, obligatorio para facturar, y no cambia. Es de los pocos casos donde no hace falta un id artificial.
• precio y dias_entrega van en la entidad intermedia, y esa es la prueba de que hacía falta: no son del proveedor (cobra distinto por cada producto) ni del producto (cada proveedor lo cobra distinto). Son de la combinación.
• El UID de ABASTECIMIENTO es barrado: el par (proveedor, producto) identifica un acuerdo, y no tiene sentido que el mismo proveedor tenga dos precios distintos para el mismo producto al mismo tiempo.
• stock está en PRODUCTO, no en ABASTECIMIENTO. Es el stock total del supermercado, no depende de quién lo trajo. Ponerlo en la intermedia sería un error clásico: obligaría a sumar filas para saber cuánto hay.

Extensión, si quieres seguir: ¿dónde pondrías el historial de precios, para saber qué cobraba ese proveedor el año pasado? La respuesta es una entidad más colgando de ABASTECIMIENTO, con la fecha desde la que rige cada precio — el mismo patrón que aparece cada vez que un dato necesita conservar su historia.

┌──────────────────────┐   ┌──────────────────────┐   ┌──────────────────────┐
│ HUESPED              │   │ RESERVA              │   │ HABITACION           │
├──────────────────────┤   ├──────────────────────┤   ├──────────────────────┤
│ # id_huesped         │──<│ # id_reserva         │>──│ # numero             │
│ * documento          │   │ * fecha_entrada      │   │ * tipo               │
│ * nombre             │   │ * fecha_salida       │   │ * tarifa_noche       │
│ * email              │   │ * estado             │   └──────────────────────┘
│ o telefono           │   └──────────────────────┘
└──────────────────────┘

Lectura:

Cada RESERVA debe corresponder a un y solo un HUÉSPED. Cada RESERVA debe ser de una y sola una HABITACIÓN. Cada HUÉSPED puede tener una o más RESERVAS. Cada HABITACIÓN puede tener una o más RESERVAS.

Los UID:

• HABITACION: numero, natural. El hotel ya numera sus habitaciones y ese número no cambia.
• HUESPED: id_huesped artificial, con documento marcado como único aparte. El documento parece un buen UID natural, pero falla con extranjeros de documentación distinta y con cargas erróneas que hay que corregir.
• RESERVA: id_reserva propio, NO barrado. Este es el punto interesante: un UID barrado con (huésped, habitación) prohibiría que el mismo huésped vuelva a la misma habitación en otro viaje. Agregar fecha_entrada lo arreglaría, pero un id propio es más simple y es lo que el hotel usa para hablar con el cliente (“su reserva número 4471”).

Otras decisiones:

• estado es * con valores confirmada/cancelada. Toda reserva tiene un estado desde que se crea.
• tarifa_noche está en HABITACION, pero ojo: si las tarifas cambian por temporada, el precio de una reserva vieja se perdería. Un modelo más completo guardaría el precio_acordado en RESERVA, por el mismo motivo del precio_unitario de una factura.
• Lo que el modelo no impide: dos reservas confirmadas de la misma habitación en fechas superpuestas. Ninguna restricción del modelo E-R puede expresar eso; se controla con lógica de aplicación o con restricciones específicas del motor. Reconocer ese límite es parte de saber modelar.

┌────────────────┐
│ INSTRUCTOR     │
├────────────────┤
│ # id_instructor│
│ * nombre       │
│ * email        │
│ o biografia    │
└────────────────┘
        │ crea
        │
┌────────────────┐         ┌──────────────────┐
│ CURSO          │────────<│ LECCION          │
├────────────────┤         ├──────────────────┤
│ # id_curso     │         │ # id_leccion     │
│ * titulo       │         │ * titulo         │
│ * precio       │         │ * duracion_min   │
│ o descripcion  │         │ * orden          │
└────────────────┘         └──────────────────┘
    │        │
    │        └──────────────────┐
    │                           │
┌──────────────────┐     ┌──────────────────┐
│ INSCRIPCION      │     │ RESEÑA           │
├──────────────────┤     ├──────────────────┤
│ # id_inscripcion │     │ # id_reseña      │
│ * fecha          │     │ * puntaje        │
│ * precio_pagado  │     │ * fecha          │
│ * porcentaje     │     │ o comentario     │
└──────────────────┘     └──────────────────┘
    │                           │
┌────────────────┐              │
│ USUARIO        │──────────────┘
├────────────────┤
│ # id_usuario   │
│ * nombre       │
│ * email        │
│ * fecha_registro│
└────────────────┘

Las cinco decisiones que definen este modelo:

1. LECCION es 1:N desde CURSO, no N:M. Una lección pertenece a un solo curso. El atributo orden es lo que permite mostrarlas en secuencia; sin él, no habría forma de saber cuál va primero.

2. INSCRIPCION resuelve la N:M entre USUARIO y CURSO, con tres atributos propios: fecha, precio_pagado y porcentaje. El precio_pagado está separado del precio del curso a propósito: si el curso sube de precio o se vende con descuento, hay que conservar lo que efectivamente se cobró.

3. RESEÑA es una entidad aparte, no atributos de INSCRIPCION. Es la decisión más discutible del modelo y hay que poder defenderla: como no toda inscripción genera una reseña, meter puntaje y comentario en INSCRIPCION dejaría esas columnas vacías en la mayoría de las filas. Separarla también permitiría después permitir más de una, o moderarlas.

4. La regla “solo se puede reseñar un curso en el que estás inscripto” no la expresa el modelo. Se podría forzar haciendo que RESEÑA cuelgue de INSCRIPCION en vez de conectar con USUARIO y CURSO por separado. Es una alternativa mejor si esa regla es estricta — y notar la diferencia entre las dos opciones es exactamente lo que se evalúa en este ejercicio.

5. porcentaje es un atributo derivado guardado a propósito. Se podría calcular contando lecciones vistas, pero eso requeriría otra entidad (LECCION_VISTA) que el enunciado no pide. Guardarlo es una simplificación consciente, no un descuido — y si más adelante hiciera falta saber qué lecciones vio, esa entidad aparecería y el porcentaje pasaría a calcularse.

La trampa está en “el mismo vuelo AR1234 sale todos los días, y cada salida es distinta”.

Hay que distinguir dos cosas que el lenguaje común llama igual:

• VUELO — la ruta programada: AR1234 va de EZE a MAD, sale 22:00, llega 15:30. Es una definición que se repite todos los días.
• VUELO_PROGRAMADO (o salida) — la instancia concreta: AR1234 del 15 de marzo de 2026, con ese avión y esos pasajeros.

Un pasaje no es para “AR1234”: es para AR1234 de un día determinado. Y el avión asignado puede cambiar de un día para otro. Modelar sin esa separación hace imposible saber quién viajó en qué salida.

┌──────────────────┐
│ AEROPUERTO       │
├──────────────────┤
│ # codigo_iata    │───┐ origen
│ * nombre         │───┤ destino
│ * ciudad         │   │
└──────────────────┘   │
                       │
┌──────────────────────┴───┐        ┌──────────────────┐
│ VUELO                    │        │ AVION            │
├──────────────────────────┤        ├──────────────────┤
│ # numero                 │        │ # matricula      │
│ * hora_salida            │        │ * modelo         │
│ * hora_llegada           │        │ * cant_asientos  │
└──────────────────────────┘        └──────────────────┘
          │                                  │
          └────────────┐        ┌────────────┘
                ┌──────────────────────┐
                │ VUELO_PROGRAMADO     │
                ├──────────────────────┤
                │ # id_vuelo_prog      │
                │ * fecha              │
                │ * estado             │
                └──────────────────────┘
                          │
                ┌──────────────────────┐    ┌──────────────────┐
                │ PASAJE               │────│ PASAJERO         │
                ├──────────────────────┤    ├──────────────────┤
                │ # id_pasaje          │    │ # id_pasajero    │
                │ * asiento            │    │ * documento      │
                │ * clase              │    │ * nombre         │
                │ * precio             │    │ * email          │
                └──────────────────────┘    └──────────────────┘

Lo demás que hay que notar:

• AEROPUERTO se relaciona dos veces con VUELO, una como origen y otra como destino. Dos relaciones distintas entre las mismas dos entidades es perfectamente válido, y es la única forma de expresarlo. En el modelo relacional se convierte en dos claves foráneas hacia la misma tabla.
• PASAJE es la entidad intermedia entre PASAJERO y VUELO_PROGRAMADO, con asiento, clase y precio como atributos del vínculo.
• El UID de VUELO_PROGRAMADO podría ser barrado con (número de vuelo, fecha), que es único y significativo. Un id propio también sirve y es más cómodo de referenciar desde PASAJE.
• codigo_iata es un UID natural excelente: internacionalmente único, estable y ya usado en todos lados. Es el ejemplo de libro de cuándo no inventar un id artificial.

La lección general: cuando un enunciado dice “cada X se repite” o “el mismo X pero en otra fecha”, casi siempre hay dos entidades donde parecía haber una: la plantilla y la ocurrencia. Pasa con vuelos y salidas, con materias y cursadas, con clases de gimnasio y sus sesiones, con series y episodios.