En mi último artículo hacía una introducción al proceso de modelado de una base de datos relacional, utilizando como ejemplo el proceso de matriculación de un centro de enseñanza. Siguiendo con esa línea, en este artículo voy a describir cómo hacemos el modelo de datos en Bravo, uno de nuestros sistemas, en este caso uno especializado en centros de enseñanzas de idiomas. Para una introducción más teórica, podéis echar un vistazo al artículo de la wikipedia.

Caso de uso

Como en el artículo anterior, lo primero es hacer la descripción de un caso de uso que nos meta en materia, y nos ayude a entender cuál es la funcionalidad que tenemos que proporcionar (o, en este caso, una descripción de los procesos que tenemos que modelizar). Bueno, en realidad la descripción que hago es más parecida a una historia de usuario de eXtreme Programming que al caso de uso típico de UML, pero nos entendemos…

Si en el artículo anterior el actor principial del caso de uso es un alumno que acude a la escuela, en este caso es el responsable formativo o Director of studies (aquí hay una buena descripción del puesto). Es la persona, en un centro de formación, encargada de la elaboración de los horarios, la gestión de las incidencias (que ahora veremos) y la asignación de profesores y aulas a los grupos que se formen.

Su necesidad es la de tener controlados todos los horarios del centro de formación. Es decir, tiene que poder saber dónde está cada profesor en todo momento, qué clases no se han impartido y por qué y saber qué profesores hay disponibles y qué aulas están libres en un momento determinado.

También necesita saber cuántas horas ha trabajado cada profesor en un mes y cuántas horas un profesor tenía que haber trabajado, y el motivo de las cancelaciones.

Así, el director de estudios (DOS, de aquí en adelante) recibe la petición de formar un grupo nuevo para uno de los cursos definidos en el ejemplo anterior, porque se han matriculado muchos alumnos y no hay plazas suficientes. El DOS entonces primero decide el horario que tendrá el grupo. En el caso de este ejemplo, el curso para el que hay que crear el grupo define 3 horas por semana (es lo que se llama un curso extensivo), que se impartirán Lunes, Miércoles y Viernes de 19:00 a 20:00. Con esta información definida, el DOS necesita buscar un profesor que esté disponible en ese horario, y un aula que también lo esté. Una vez localizada toda la información necesaria para montar el horario, hay dejar anotado el nombre de los alumnos que asistirán a este grupo.

Con toda esta información definida, el grupo puede empezar. Normalmente, se le proporciona al profesor a principio de mes una hoja de asistencia, que es un informe en el que se detallan el horario de cada grupo con sus alumnos, para que el profesor pueda hacer un seguimiento de la asistencia de los alumnos y de las incidencias que puedan aparecer.

Una vez el grupo ha comenzado, y los alumnos están asistiendo a clase, al director de estudios se le pueden presentar varias situaciones que tiene que manejar:

1. El grupo cambia de profesor, de horario o de aula. Quizá porque el profesor se vaya de la empresa o por la razón que sea, de vez en cuando hay que cambiar el profesor de un grupo. Sin embargo, a la hora de aplicar este cambio es importante tener en cuenta que debemos mantener la información histórica. Es decir, cuando haya un cambio de horario debemos saber qué profesor había antes y cuál hay ahora, y cuándo se produjo el cambio. Para el cálculo de total de horas trabajadas, es imprescindible.
2. Entran alumnos nuevos, u otros dejan el grupo, cuando los alumnos se dan de alta y se incorporan al grupo, o quizá cuando un alumno cambia de grupo porque el horario le viene mejor. Como en el caso anterior, tendríamos que saber por qué grupos ha pasado el alumnos y cuándo se ha incorporado a cada grupo.
3. Una clase no se imparte, por ejemplo porque el profesor se ha puesto enfermo y no se ha encontrado sustituto a tiempo, o porque el centro estaba cerrado. En este caso, tenemos que saberlo, porque el nº de horas trabajadas por el profesor tendrá que cambiar, y hay algunos casos (cuando se ha contratado un nº de horas de formación concreto) en los que esa clase debe recuperarse en otro momento, ya sea otro día de la semana o quizá alargando la duración del grupo un poco.
4. Un profesor sustituye a otro. Es el caso en el que un profesor se pone enfermo, o se ha cogido un día libre, y otro profesor le sustituye. En este caso tenemos que saber quién tenía que dar la clase (ha impartido una hora menos) y quién ha dado la clase en realidad (hay impartido una hora más).
5. Un grupo se cierra. Se dan de baja todos los alumnos o (lo que es más común), se dan de baja tantos alumnos que no compensa mantener el grupo abierto, así que se reúnen dos grupos con pocos alumnos y se crea un grupo con un nº de alumnos más acorde con las necesidades tanto del centro como de los propios alumnos.

Descripción de las entidades

Después de la descripción del proceso, detallo las entidades (tablas) que utilizamos para m0delizarlo:

• Cursos: podéis ver la descripción en el artículo anterior.
• Profesores: el personal que imparte las clases.
• Grupos: La oferta de horarios y días entre los que los alumnos pueden elegir para asistir a clase, dentro de cada curso.
• Horarios: Dentro de cada grupo, tenemos que almacenar su horario (que puede tener una estructura compleja, por ejemplo: Lunes y Miércoles de 19:00 a 20:00 y Viernes de 13:00 a 14:00, es más común de lo que parece). Además, hay que almacenar el historial de horarios por los que ha pasado el grupo, incluyendo los profesores.
• Clases: Cada uno de los días de clase dentro del horario del grupo. Por ejemplo, si tenemos un horario Lunes de 19:00 a 20:00, entre el 1 y el 30 de Abril, tendrá que haber un registro para cada Lunes entre esas dos fechas, para que después podamos gestionar si las clases se han impartido o no, cada una por separado.
• Tipos de tarea: Hay situaciones en las que es conveniente diferenciar qué se hace en los horarios del grupo. Podemos tener grupos de formación, como los que se describen en todo el artículo, pero también podemos tener grupos que gestionen las tareas administrativas de los profesores (preparación de clases, etc.) o incluso la agenda del personal no docente, simplemente diferenciando por tipo de tarea.
• Tipos de cancelación: Necesitamos saber cuando una clase no se imparte, así que nos hará falta una gestión de motivos de cancelación, y por tanto una entidad que los defina.
• Alumnos: ya la vimos en el artículo anterior.
• Alumnos en grupos: Tenemos que almacenar la información de qué alumnos están apuntados a qué grupos y, además, nos hace falta saber, según el caso de uso, cuándo entró y cuándo salió cada alumno de su grupo.
• Asistencia: Para cada una de las clases, tenemos que saber qué alumnos estaban apuntados a ella, y para cada uno de ellos, si asistió a clase o no.

Gráficamente:

Con PK se marcan las claves primarias, y con FK, las claves ajenas… algunas líneas se cruzan, no lo puedo evitar. Las flechas indican que una tabla es ‘hija’ de otra, con la punta de flecha apuntando al padre.

Como podéis ver, sólo están indicados los campos que forman el modelo de datos… las claves primarias y las claves ajenas, que en cualquier caso deben estar ocultas al usuario final. En la siguiente sección describiremos los campos de cada tabla.

Campos

Como siempre, sólo pongo los campos que considero más relevantes para la descripción del modelo de datos, y no repito los campos de clave ajena para las relaciones, que ya están descritos en el gráfico. La definición de cursos y grupos es la misma que en la que hay en el artículo de matriculación:

Cursos

• nombre: varchar(100)
• descripcion: Memo. Se utilizará, en el contrato que se imprime para el cliente, para hacer una descripción larga del curso en el que el alumno se está matriculando. En uno de los sistemas que tenemos, en lugar de tener un campo memo, tenemos una tabla separada en la que se guardan, por tipologías, distintos campos memo, que se imprimen en distintos lugares del contrato.
• fecha_inicio: date
• fecha_fin: date

Profesores

• nombre, primer_apellido, segundo_apellido: varchar(100)
• nombre_completo: es una costumbre crear un campo calculado que almacene el nombre completo del profesor. Así, las búsquedas se hacen sobre este campo y es más fácil encontrar al profesor en cuestión.
• dirección: Memo
• telefono, telefono_movil: varchar(50). No os quedéis cortos con el tamaño de los campos, más vale pasarse que dejarlo con 9 dígitos y descubrir que tienes que poner el +34 delante para poder mandar SMS después.
• NIF_NIE, Pasaporte: en campos separados

Grupos

• nombre: varchar(100)
• codigo: varchar(20). Siempre viene bien tener una codificación además del nombre. Por ejemplo, en algunos sistemas lo utilizamos para guardar el código del grupo en la Fundación Tripartita.
• fecha_inicio: date
• fecha_fin: date. Por defecto, las del curso al que pertenece el grupo, y además estas fechas no pueden estar fuera de las fechas del curso al que pertenecen.
• lugar: varchar(100) de impartición del grupo. En general, hacemos una gestión de aulas, pero eso lo ampliaré en otro artículo.
• notas: memo, del grupo
• horario: varchar(100) del grupo. En realidad, el horario se trata como una tabla por debajo de esta, pero no voy a entrar en tanto nivel de detalle ahora.
• maximo_alumnos: Integer. Máximo número de alumnos permitidos en el grupo.
• numero_alumnos: Integer. Es el número de alumnos existentes en el grupo. Este campo es de sólo lectura para el usuario, y es calculado, a través de una serie de Triggers en la base de datos, para poder saber rápidamente el número de alumnos activos en cada grupo sin tener que estar sumando.

Horarios

• fecha_inicio, fechafin : date. Por defecto, serán las del grupo con el que estamos trabajando, pero si cambiamos de horario a mitad del grupo, habrá que cerrar el horario anterior (cambiar fecha_fin) y crear un horario nuevo.
• L,M,X,J,V: Boolean. Aquí hay dos formas de hacerlo… puedes poner campos booleanos para cada día de la semana, y si el horario tiene L = sí y X = sí, entonces el horario es Lunes y Miércoles, o poner un campo «día» de tipo entero y tener un registro de horario para cada día de la semana. Me inclino por la primera solución, que hemos utilizado en nuestro sistema Atenea que por la segunda, que es la que utilizamos en Bravo. Los días de la semana no son algo que vaya a cambiar, y el interface y la forma de mostrar el horario es más fácil de implementar y más intuitivo para el usuario cuando usas una sóla fila que cuando tienes 3 para el mismo horario.
• hora_inicio, hora_fin: Time
• id_profesor: por defecto, es el profesor definido como profesor del grupo, pero podemos tener la situación en la que haya dos profesores en el mismo grupo (como pasa muy a menudo con los seminarios y los cursos intensivos).
• id_tipo_tarea: Integer. Es el tipo de tarea por defecto que tendrán todas las clases del horario. También existe la posibilidad de poner un tipo de cancelación por defecto, como hemos hecho en Atenea. Lo vemos más abajo, en las clases.

Clases

• fecha: Date. A estas alturas, ya no tenemos fecha de inicio y fecha de fin… esto es ya cada uno de los días de clase individuales, y por tanto lo que hay es una fecha
• hora_inicio, hora_fin: Time. Por defecto serán las del horario al que pertenece la clase. Están también en la tabla de clases porque eso te permite gestionar excepciones, del tipo que la clase de hoy dura media hora más para recuperar parte de una clase anterior que se canceló, cosas así.
• id_tipo_tarea: el tipo de tarea del horario, por defecto. Igual que antes, está replicado en esta tabla para permitir excepciones.
• id_tipo_cancelacion: Tenemos dos formas de proceder… podemos definir un tipo de cancelación por defecto, que será el que tengan todas las clases (nosotros utilizamos «clase impartida», para indicar que no ha habido cancelación), o también podemos poner el tipo de cancelación en el horario, de forma que todas las clases de ese horario tendrán ese tipo de cancelación y luego nosotros cambiamos el tipo de cancelación para las clases que no se imparten.
• Notas pedagógicas: Memo. Suele ser buena idea poner un campo de notas pedagógicas que, el profesor, al rellenar la asistencia (lo vemos más abajo) puede completar. Esto hace que, cuando un profesor tiene que hacerse cargo de un grupo que ya ha empezado, puede leer las notas que dejó el otro profesor (lo que se llama el Class Record) y saber por dónde van y qué es lo siguiente que hay que hacer.

Tipos de Tarea

• nombre: varchar(100)
• lectiva, transporte, administrativa : boolean. Con estos campos podemos sumar después fácilmente las horas según los tipos de tarea. Por ejemplo, podemos tener un tipo de tarea «Horas lectivas» y otra «Horas lectivas en Sábado», que se pagan de distinta forma y queremos tener controladas, pero sin embargo todas son horas lectivas, y a la hora calcular totales de horas, las queremos agrupadas.

Tipos de cancelación

• Nombre : varchar(100)
• clase_impartida: boolean. Así podemos tener distintos tipos de cancelación que indican que la clase no se ha impartido, y luego sumar todas juntas para saber cuántas horas se han impartido y cuántas no.
• implica_pago_profesor: Según el tipo de cancelación y el convenio, hay tipos de cancelación que, aunque no cuenten como clase impartida, sí que se van a pagar al profesor.
• implica_cobo_cliente: En el caso de los grupos para empresa o en los individuales, normalmente se factura por horas (lo veremos en el artículo sobre facturación), y en estos casos se da la circunstancia de que las cancelaciones no son sólo por parte del profesor o del centro de formación: en estos casos, es posible (de hecho, es lo más común) que sea el cliente el que cancele la clase. Normalmente, se definen en este caso dos tipos de cancelación: Cancelación en plazo, que es cuando el cliente ha avisado de que no va a darse la clase, y entonces no se le factura, o Cancelación fuera de plazo, que es el caso tan típico en el que el profesor se presenta y no hay nadie a quién darle clase. En este caso, normalmente, la clase se factura aunque no haya sido impartida, pero es importante para el DOS saber qué clases han sido canceladas de esta manera. A final de curso, cuando se evalúa el avance del alumno, es importante tener en cuenta a cuántas clases el alumno ha acudido realmente, no cuántas se le ha facturado al cliente.

Alumnos

• nombre: varchar(100). Lo mismo que en clientes, pero lo requerido es nombre y primer apellido (en clientes es sólo nombre por si
• primer_apellido: varchar(100)
• segundo_apellido: varchar(100)
• nombre_completo: varchar(300):
• etc. de datos personales (profesión, teléfonos, email, etc.)

Alumnos en grupos

• fecha_inicio: date
• fecha_fin: date. Suele ser una intersección entre la duración del grupo y la de la matrícula, pero cuando el alumno cambia de grupo, para una matrícula puede haber varios registros de alumnos en grupos. Hay que tener en cuenta también la posibilidad de que en un mismo curso, pagando más, un alumno pueda asistir a varios grupos (esto también lo he visto).

Asistencia

• asiste: boolean. Normalmente, cuando se crean los registros de asistencia (que se crean automáticamente cuando se crean las clases), el campo asiste está inicializado a NULL, para que así sepamos que esta información todavía no está disponible. Será el profesor cuando introduzca la asistencia el que indique si el alumno asiste o no. Mientras tanto… no se sabe.
• falta_justificada: boolean. Todo el proceso que está definido en este artículo se basa en la idea de que la asistencia de los alumnos y la cancelación de una clase son cosas separadas, porque la gestionan personas separadas. La información de cancelación de clases implica que se indique el motivo de dicha cancelación, y dicha información va a afecta a la facturación al cliente y al pago a los profesores, y por tanto es responsabilidad del DOS. La información de asistencia de los alumnos tiene valor desde el punto de vista académico (para calcular los porcentajes de asistencia de los alumnos a la hora de evaluar el rendimiento) y se usa en conjunción con la información de calificaciones. Como actualizar esta información es muy trabajoso por el volumen de datos que representa, los sistemas en general están pensados para que sean los profesores los que introduzcan esta información. Como la información de cancelaciones puede afectar directamente a sus pagos, los profesores no la introducen directamente en el sistema. Por tanto, que todos los alumnos tengan asiste = NO no implica que la clase esté cancelada… es lo tendrá que introducir el DOS, incluyendo el motivo.

Triggers y procedimientos almacenados

Este proceso, como hemos visto por la definición de las tablas, tiene muchos procesos ‘automáticos’, propios de la base de datos. Principalmente:

• Al crear un horario, tiene que haber un trigger que inserte en la base de datos todas las clases de ese horario, teniendo en cuenta la fecha de inicio y de fin y los días de clase, e incluyendo la gestión de días no lectivos si la hemos hecho.
• De la misma forma, necesitamos un trigger que al crear clases o incluir alumnos en grupos inserte en la base de datos los registros de asistencia de los alumnos y las clases a los que pertenecen.

Es muy importante que estos dos procesos estén incluidos en la base de datos… El trabajo principal de los DOS, y la fuente principal de información de producción en la empresa es esta parte, y por tanto es muy importante que estos procesos sean ágiles. En las primeras versiones de Bravo, este proceso sea hacía en el lado cliente del sistema, y el rendimiento dejaba muchísimo que desear.

Consideraciones finales

Creo que más o menos es todo… es muy importante que seamos conscientes de que esta gestión de horarios es muy detallada, y que por tanto implica mucha gestión para mantenerla al día: además de dar de alta los grupos, hay que mantener los cambios de profesor y ser muy preciso con las fechas de modificación, hay que introducir las cancelaciones, la asistencia de los alumnos… implica muchas horas de trabajo mantenerlo al día. A la hora de hacer una implementación como esta, hay que valorar los beneficios que reporta. Al principio del artículo he hablado que este modelo está pensado para centros de enseñanza de idiomas, lo cual no es del todo exacto. Este modelo está pensado para organizaciones que necesitan saber el número exacto de horas que se han trabajado en un periodo de tiempo dado, ya sea para facturar al cliente (como ocurre en los centros de idioma, en los departamentos de enseñanza para empresas) como para pagar al personal.

No he hablado de la gestión de los contratos de los profesores, o del proceso de facturación mismo, que incluiré en otros artículos, ni he descrito la manera de obtener informes de totales de horas (que se basa simplemente en sumar la duración de las clases en base a los criterios de fechas, tipos de cancelación, tareas, profesores, etc. que se necesiten).

Intentaré, en mi siguiente artículo, hacer un descripción de un proceso de facturación en el que se tengan que cobrar horas, y de cómo dejarlo lo suficientemente abierto como para facturar cualquier otra cosa.

Saludos a todos,

d