Ejercicios de modelado lógico relacional de bases de datos · Ejercicio: (avanzado) Conservatorio

Ejercicio: (avanzado) Conservatorio

Puedes preparar tu diagrama. .

Enunciado #

Un conservatorio necesita gestionar estudiantes, clases, profesores e instrumentos. Cada estudiante puede asistir a varias clases y aprender distintos instrumentos. Además, se quiere conservar el historial de aprendizaje, con sus fechas, y saber qué instrumentos puede enseñar cada profesor.

Datos que debes almacenar #

  • Estudiante: id_estudiante (entero, identificador), nombre (texto), apellido (texto), edad (entero) y nivel_habilidad (enum; principiante, intermedio o avanzado).
  • Profesor: id_profesor (entero, identificador), nombre (texto), apellido (texto) y anio_contratacion (entero).
  • Instrumento: id_instrumento (entero, identificador), nombre (texto; guitarra, piano, batería, etc.) y tipo (texto; cuerda, viento, percusión, etc.).
  • Clase: id_clase (entero, identificador), fecha_inicio (fecha), duracion_semanas (entero) e id_profesor (entero).
  • Inscripcion: id_estudiante (entero) e id_clase (entero).
  • Especializacion: id_profesor (entero) e id_instrumento (entero).
  • HistorialInstrumento: id_estudiante (entero), id_instrumento (entero), fecha_inicio (fecha) y fecha_fin (fecha, opcional mientras siga aprendiendo).

Reglas del negocio #

  1. Estudiantes y clases se relacionan N:N. La PK de Inscripcion es (id_estudiante, id_clase).
  2. Cada clase tiene un único profesor y un profesor puede impartir varias clases.
  3. Un profesor puede enseñar varios instrumentos y un instrumento puede ser enseñado por varios profesores. Resuelve esta relación con Especializacion, cuya PK es (id_profesor, id_instrumento); no guardes una lista de instrumentos en una columna del profesor.
  4. El historial de aprendizaje resuelve la relación N:N entre estudiantes e instrumentos y conserva sus fechas.
  5. Para permitir que un estudiante retome el mismo instrumento en otro periodo, usa (id_estudiante, id_instrumento, fecha_inicio) como PK de HistorialInstrumento.
  6. Las fechas finales, cuando existan, no pueden ser anteriores a las iniciales. No se permiten periodos solapados del mismo estudiante e instrumento; estas reglas se validarían al implementar la base de datos.
  7. El documento no asocia cada clase a un instrumento concreto. Conserva ese alcance: la especialización del profesor y el historial del estudiante son relaciones propias, no se deducen de la asistencia a clase.

Diseña las siete tablas y sus relaciones. Se mantiene la edad como dato del documento; una aplicación real podría calcularla a partir de una fecha de nacimiento.

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.

Deja desactivados autoincremento, clave alternativa e índice. Deja vacíos el valor por defecto, las acciones ON DELETE y ON UPDATE y, salvo que se indique expresamente, CHECK. Usa los extremos 1 y n, o 1 y 1, en las conexiones; una FK opcional tiene NN desmarcado.

Una PK compuesta identifica por la combinación de sus campos: no marques cada componente como único por separado. Si una FK referencia una PK compuesta, dibuja una conexión por cada pareja de campos; todas juntas representan una única referencia a la misma fila. En una implementación SQL se debe declarar una sola FOREIGN KEY con todas esas columnas, no varias referencias independientes. El editor no comprueba por sí solo las reglas sobre varias filas ni todas las restricciones compuestas.

Cargando actividad al acercarte…