Introducción

La estructura de los datos de FCTFiller ha sufrido numerosas transformaciones, al ser un proyecto desarrollado con metodología ágil. Por tanto, la base de datos ha estado en constante evolución y ha sufrido varias revisiones importantes, así como se han añadido campos y relaciones allá donde ha sido necesario. Muchas de estas modificaciones no han podido ser implementadas cumpliendo con todos los ideales teóricos del diseño de bases de datos, ya que hacerlo habría supuesto una doble inversión de tiempo: el rediseño en sí y la revisión y modificación del código afectado.

Esquema Entidad-Relación

El esquema de Entidad-Relación correspondiente a la base de datos a fecha del 21-06-2022 es el siguiente:

Respecto a este esquema, podemos hacer algunos apuntes:

• Todas las entidades débiles están marcadas con una línea discontinua.
• La clave curso_academico, repetida en muchas relaciones del diseño, se gestiona en la BBDD mediante la tabla auxiliar aux_curso_academico, que contiene el código de curso académico como clave primaria (21/22, por ejemplo) y las fechas de inicio y fin del mismo. Sin embargo, esta clave no es foránea en ninguna de las relaciones, por lo que queda excluida del E-R.
• Las localidades y provincias se definen en el cliente mediante la consulta a la BBDD de la tabla auxiliar ciudades, que contiene información de todos los municipios de España asociados con sus provincias y CC.AA.
• La entidad NOTIFICACION y SEMANA no tienen una relación estricta por clave foránea; la tabla notificaciones almacena un campo id_semana que puede ser NULL, aunque en un inicio se planteaba como una clave foránea.
• La inclusión de la tabla users se hizo en una fase avanzada de la aplicación, por lo que no existe una propagación real de claves foráneas, sino una equivalencia de los campos email y password en las tablas con las que se relaciona.

Propuesta de mejora

El equipo de desarrollo es consciente de la inconsistencia en algunas partes de la BBDD, fruto del desarrollo ágil y la inexperiencia. Es necesario hacer una revisión del diseño de la base de datos. Esto pasa, ante todo, por una nueva fase de entrevistas con el cliente, contando con el producto para mostrárselo y recibir un feedback. Con todo, hay algunas propuestas de mejoras que pueden plantearse independientemente de la nueva fase de análisis:

• Se debe integrar totalmente la tabla users en el diseño, eliminando referencias a las password fuera de dicha tabla y añadiendo una tabla de perfiles similar a las tablas de roles ya existentes.
• Las referencias a las rutas de los anexos en tablas ajenas a anexos (convenio o fct, por ejemplo) deben ser por la clave primaria (id) en lugar de un campo no primario (ruta_anexo).
• curso_academico debe pasar a ser una tabla central de la BBDD, y no auxiliar. Sus referencias deben ser por clave foránea, para asegurar la integridad de los datos.
• Se deben disponer triggers para ciertos eventos: inserción de un curso académico por año, caducidad de convenios tras cuatro años...
• Se debe revisar la elección de claves primarias: se ha comprobado que usar el DNI como clave primaria para todas las tablas de personas puede ser problemático en algunos sentidos. En este caso, la elección de una ID autonumérica, un e-mail o un código interno (como el caso de los alumnos) puede ser una mejor elección.
• Se debe hacer una propuesta de la entidad TRABAJADOR distinta, ya que no todos requieren los mismos datos: sólo se necesita el DNI del representante legal, y del responsable del centro no se registra ninguno. Este punto está muy relacionado con el anterior.
• Se ha de tener en cuenta la posibilidad de que un centro de estudios haga más de un convenio con una empresa si afecta a diferentes familias profesionales (convertir el convenio en una relación ternaria).
• Se debe revisar la propagación de claves, dado que en muchos casos se propagan claves secundarias en lugar de primarias.