Ejercicios de modelado lógico relacional de bases de datos · Ejercicio: (medio) Gestion eventos musicales

Ejercicio: (medio) Gestion eventos musicales

Puedes preparar tu diagrama. .

Enunciado #

Diseña una base de datos para gestionar conciertos, promotores, artistas y asistentes. Además de organizar el cartel de cada concierto, debe guardar los datos de las entradas adquiridas.

Datos que debes almacenar #

  • Promotor: id_promotor (entero, identificador), nombre (texto), email (texto) y tlfn (texto).
  • Concierto: id_concierto (entero, identificador), titulo (texto), fecha (fechahora), lugar (texto), precio_base (decimal) y estado (enum; programado, en_progreso, finalizado o cancelado).
  • Artista: id_artista (entero, identificador), nombre (texto) y nacionalidad (texto, opcional).
  • Asistente: id_asistente (entero, identificador), nombre (texto) y email (texto).
  • Los datos de cada entrada: fecha_compra (fechahora), precio (decimal) y numero_asiento (texto).

Reglas del negocio #

  1. Cada concierto es organizado por un único promotor y un promotor puede organizar varios conciertos. Añade id_promotor (entero) donde corresponda.
  2. Cada concierto cuenta con uno o varios artistas y cada artista puede tocar en varios conciertos a lo largo de su carrera.
  3. Un asistente puede acudir a varios conciertos y un concierto puede recibir a varios asistentes.
  4. Para este ejercicio, cada asistente adquiere como máximo una entrada para cada concierto. La fecha de compra, el precio pagado y el asiento pertenecen a esa entrada.
  5. El precio pagado se conserva aunque posteriormente cambie el precio base del concierto.
  6. Un asiento no puede asignarse a dos asistentes del mismo concierto. Todos los conciertos de esta práctica tienen asientos numerados.

Usa ConciertoArtista para el cartel, con id_concierto e id_artista (enteros) como PK compuesta. Usa Entrada para la asistencia, con id_concierto e id_asistente (enteros) como PK compuesta, además de sus tres datos propios. Diseña las seis tablas y sus relaciones.

La combinación (id_concierto, numero_asiento) debe ser única. Como el editor solo ofrece unicidad por campo, no marques numero_asiento como único global: impediría reutilizar el mismo número en distintos conciertos. Esta restricción compuesta y la existencia de al menos un artista por concierto deben controlarse al implementar la base de datos.

Criterios para el challenge #

Conserva los nombres de tablas y campos indicados; los nombres de campos están escritos sin tildes y con guiones bajos. Los tipos entre paréntesis corresponden a las opciones del editor. Todos los campos son obligatorios (NN), salvo los marcados como opcionales; marca las claves primarias (PK), foráneas (FK) y las restricciones de unicidad que se deducen de las reglas.

Para esta práctica, deja desactivados autoincremento, clave alternativa e índice, y deja vacíos CHECK, valor por defecto y las acciones ON DELETE y ON UPDATE. Representa las relaciones con los extremos 1 y n, o 1 y 1; la opcionalidad de una FK se indica con NN desmarcado. Las reglas que afectan a varias filas, los rangos de valores y los catálogos de valores se razonan aparte: no se comprueban solo con las conexiones del diagrama.

Cargando actividad al acercarte…