www.youtube.com/watch?

v=11uCN9pkqTA
http://www.megaupload.com/?d=C5MDQIT3

Modelo entidad-relacin, un ejemplo prctico (II. Horarios)

Por Domingo el 27 abril, 2010 En mi ltimo artculo haca una introduccin al proceso de modelado de una base de datos relacional, utilizando como ejemplo el proceso de matriculacin de un centro de enseanza. Siguiendo con esa lnea, en este artculo voy a describir cmo hacemos el modelo de datos en Bravo, uno de nuestros sistemas, en este caso uno especializado en centros de enseanzas de idiomas. Para una introduccin ms terica, podis echar un vistazo al artculo de la wikipedia.

Caso de uso
Como en el artculo anterior, lo primero es hacer la descripcin de un caso de uso que nos meta en materia, y nos ayude a entender cul es la funcionalidad que tenemos que proporcionar (o, en este caso, una descripcin de los procesos que tenemos que modelizar). Bueno, en realidad la descripcin que hago es ms parecida a una historia de usuario de eXtreme Programming que al caso de uso tpico de UML, pero nos entendemos Si en el artculo 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 descripcin del puesto). Es la persona, en un centro de formacin, encargada de la elaboracin de los horarios, la gestin de las incidencias (que ahora veremos) y la asignacin de profesores y aulas a los grupos que se formen. Su necesidad es la de tener controlados todos los horarios del centro de formacin. Es decir, tiene que poder saber dnde est cada profesor en todo momento, qu clases no se han impartido y por qu y saber qu profesores hay disponibles y qu aulas estn libres en un momento determinado. Tambin necesita saber cuntas horas ha trabajado cada profesor en un mes y cuntas horas un profesor tena que haber trabajado, y el motivo de las cancelaciones. As, el director de estudios (DOS, de aqu en adelante) recibe la peticin 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 impartirn Lunes, Mircoles y Viernes de 19:00 a 20:00. Con esta

informacin definida, el DOS necesita buscar un profesor que est disponible en ese horario, y un aula que tambin lo est. Una vez localizada toda la informacin necesaria para montar el horario, hay dejar anotado el nombre de los alumnos que asistirn a este grupo. Con toda esta informacin 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 estn 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

2.

3.

4.

5.

vaya de la empresa o por la razn 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 informacin histrica. Es decir, cuando haya un cambio de horario debemos saber qu profesor haba antes y cul hay ahora, y cundo se produjo el cambio. Para el clculo de total de horas trabajadas, es imprescindible. 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, tendramos que saber por qu grupos ha pasado el alumnos y cundo se ha incorporado a cada grupo. 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 formacin concreto) en los que esa clase debe recuperarse en otro momento, ya sea otro da de la semana o quiz alargando la duracin del grupo un poco. Un profesor sustituye a otro. Es el caso en el que un profesor se pone enfermo, o se ha cogido un da libre, y otro profesor le sustituye. En este caso tenemos que saber quin tena que dar la clase (ha impartido una hora menos) y quin ha dado la clase en realidad (hay impartido una hora ms). Un grupo se cierra. Se dan de baja todos los alumnos o (lo que es ms comn), se dan de baja tantos alumnos que no compensa mantener el grupo abierto, as que se renen dos grupos con pocos alumnos y se crea un grupo con un n de alumnos ms acorde con las necesidades tanto del centro como de los propios alumnos.

Descripcin de las entidades

Despus de la descripcin del proceso, detallo las entidades (tablas) que utilizamos para m0delizarlo:

Cursos: podis ver la descripcin en el artculo anterior. Profesores: el personal que imparte las clases.

Grupos: La oferta de horarios y das 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 Mircoles de 19:00 a 20:00 y Viernes de 13:00 a 14:00, es ms comn de lo que parece). Adems, hay que almacenar el historial de horarios por los que ha pasado el grupo, incluyendo los profesores. Clases: Cada uno de los das 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 despus 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 formacin, como los que se describen en todo el artculo, pero tambin podemos tener grupos que gestionen las tareas administrativas de los profesores (preparacin de clases, etc.) o incluso la agenda del personal no docente, simplemente diferenciando por tipo de tarea. Tipos de cancelacin: Necesitamos saber cuando una clase no se imparte, as que nos har falta una gestin de motivos de cancelacin, y por tanto una entidad que los defina. Alumnos: ya la vimos en el artculo anterior. Alumnos en grupos: Tenemos que almacenar la informacin de qu alumnos estn apuntados a qu grupos y, adems, nos hace falta saber, segn el caso de uso, cundo entr y cundo 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.

Grficamente:

Con PK se marcan las claves primarias, y con FK, las claves ajenas algunas lneas 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 podis ver, slo estn 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 seccin describiremos los campos de cada tabla.

Campos
Como siempre, slo pongo los campos que considero ms relevantes para la descripcin del modelo de datos, y no repito los campos de clave ajena para las relaciones, que ya estn descritos en el grfico. La definicin de cursos y grupos es la misma que en la que hay en el artculo de matriculacin:

Cursos

nombre: varchar(100) descripcion: Memo. Se utilizar, en el contrato que se imprime para el cliente, para hacer una descripcin 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 tipologas, 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 bsquedas se hacen sobre este campo y es ms fcil encontrar al profesor en cuestin. direccin: Memo telefono, telefono_movil: varchar(50). No os quedis cortos con el tamao de los campos, ms vale pasarse que dejarlo con 9 dgitos y descubrir que tienes que poner el +34 delante para poder mandar SMS despus. NIF_NIE, Pasaporte: en campos separados

Grupos

nombre: varchar(100) codigo: varchar(20). Siempre viene bien tener una codificacin adems del nombre. Por ejemplo, en algunos sistemas lo utilizamos para guardar el cdigo del grupo en la Fundacin Tripartita. fecha_inicio: date fecha_fin: date. Por defecto, las del curso al que pertenece el grupo, y adems estas fechas no pueden estar fuera de las fechas del curso al que pertenecen. lugar: varchar(100) de imparticin del grupo. En general, hacemos una gestin de aulas, pero eso lo ampliar en otro artculo.

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. Mximo nmero de alumnos permitidos en el grupo. numero_alumnos: Integer. Es el nmero de alumnos existentes en el grupo. Este campo es de slo lectura para el usuario, y es calculado, a travs de una serie de Triggers en la base de datos, para poder saber rpidamente el nmero de alumnos activos en cada grupo sin tener que estar sumando.

Horarios

fecha_inicio, fechafin : date. Por defecto, sern 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 da de la semana, y si el horario tiene L = s y X = s, entonces el horario es Lunes y Mircoles, o poner un campo da de tipo entero y tener un registro de horario para cada da de la semana. Me inclino por la primera solucin, que hemos utilizado en nuestro sistema Atenea que por la segunda, que es la que utilizamos en Bravo. Los das de la semana no son algo que vaya a cambiar, y el interface y la forma de mostrar el horario es ms fcil de implementar y ms intuitivo para el usuario cuando usas una sla 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 situacin 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 tendrn todas las clases del horario. Tambin existe la posibilidad de poner un tipo de cancelacin por defecto, como hemos hecho en Atenea. Lo vemos ms 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 das de clase individuales, y por tanto lo que hay es una fecha hora_inicio, hora_fin: Time. Por defecto sern las del horario al que pertenece la clase. Estn tambin en la tabla de clases porque eso te permite gestionar excepciones, del tipo que la clase de hoy dura media hora ms 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 cancelacin por defecto, que ser el que tengan todas las clases (nosotros utilizamos clase impartida, para indicar que no ha habido cancelacin), o tambin podemos poner el tipo de cancelacin en el horario, de forma que todas las clases de ese horario tendrn ese tipo de cancelacin y luego nosotros cambiamos el tipo de cancelacin para las clases que no se imparten. Notas pedaggicas: Memo. Suele ser buena idea poner un campo de notas pedaggicas que, el profesor, al rellenar la asistencia (lo vemos ms 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 dnde 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 despus fcilmente las horas segn los tipos de tarea. Por ejemplo, podemos tener un tipo de tarea Horas lectivas y otra Horas lectivas en Sbado, 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 cancelacin

Nombre : varchar(100) clase_impartida: boolean. As podemos tener distintos tipos de cancelacin que indican que la clase no se ha impartido, y luego sumar todas juntas para saber cuntas horas se han impartido y cuntas no. implica_pago_profesor: Segn el tipo de cancelacin y el convenio, hay tipos de cancelacin 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 artculo sobre facturacin), y en estos casos se da la circunstancia de que las cancelaciones no son slo por parte del profesor o del centro de formacin: en estos casos, es posible (de hecho, es lo ms comn) que sea el cliente el que cancele la clase. Normalmente, se definen en este caso dos tipos de cancelacin: Cancelacin en plazo, que es cuando el cliente ha avisado de que no va a darse la clase, y entonces no se le factura, o Cancelacin fuera de plazo, que es el caso tan tpico en el que el profesor se presenta y no hay nadie a quin 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 evala el avance del alumno, es importante tener en cuenta a cuntas clases el alumno ha acudido realmente, no cuntas 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 slo nombre por si primer_apellido: varchar(100) segundo_apellido: varchar(100) nombre_completo: varchar(300): etc. de datos personales (profesin, telfonos, email, etc.)

Alumnos en grupos

fecha_inicio: date

fecha_fin: date. Suele ser una interseccin entre la duracin del grupo y la de la matrcula, pero cuando el alumno cambia de grupo, para una matrcula puede haber varios registros de alumnos en grupos. Hay que tener en cuenta tambin la posibilidad de que en un mismo curso, pagando ms, un alumno pueda asistir a varios grupos (esto tambin lo he visto).

Asistencia

asiste: boolean. Normalmente, cuando se crean los registros de asistencia (que se crean automticamente cuando se crean las clases), el campo asiste est inicializado a NULL, para que as sepamos que esta informacin todava 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 artculo se basa en la idea de que la asistencia de los alumnos y la cancelacin de una clase son cosas separadas, porque la gestionan personas separadas. La informacin de cancelacin de clases implica que se indique el motivo de dicha cancelacin, y dicha informacin va a afecta a la facturacin al cliente y al pago a los profesores, y por tanto es responsabilidad del DOS. La informacin de asistencia de los alumnos tiene valor desde el punto de vista acadmico (para calcular los porcentajes de asistencia de los alumnos a la hora de evaluar el rendimiento) y se usa en conjuncin con la informacin de calificaciones. Como actualizar esta informacin es muy trabajoso por el volumen de datos que representa, los sistemas en general estn pensados para que sean los profesores los que introduzcan esta informacin. Como la informacin 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 definicin de las tablas, tiene muchos procesos automticos, 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 das de clase, e incluyendo la gestin de das 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 estn incluidos en la base de datos El trabajo principal de los DOS, y la fuente principal de informacin de produccin 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 haca en el lado cliente del sistema, y el rendimiento dejaba muchsimo que desear.

Consideraciones finales
Creo que ms o menos es todo es muy importante que seamos conscientes de que esta gestin de horarios es muy detallada, y que por tanto implica mucha gestin para mantenerla al da: adems de dar de alta los grupos, hay que mantener los cambios de profesor y ser muy preciso con las fechas de modificacin, hay que introducir las cancelaciones, la asistencia de los alumnos implica muchas horas de trabajo mantenerlo al da. A la hora de hacer una implementacin como esta, hay que valorar los beneficios que reporta. Al principio del artculo he hablado que este modelo est pensado para centros de enseanza de idiomas, lo cual no es del todo exacto. Este modelo est pensado para organizaciones que necesitan saber el nmero 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 enseanza para empresas) como para pagar al personal. No he hablado de la gestin de los contratos de los profesores, o del proceso de facturacin mismo, que incluir en otros artculos, ni he descrito la manera de obtener informes de totales de horas (que se basa simplemente en sumar la duracin de las clases en base a los criterios de fechas, tipos de cancelacin, tareas, profesores, etc. que se necesiten). Intentar, en mi siguiente artculo, hacer un descripcin de un proceso de facturacin en el que se tengan que cobrar horas, y de cmo dejarlo lo suficientemente abierto como para facturar cualquier otra cosa. Saludos a todos,
Estructura de la Base de Datos

Tabla Asignatura Campo Tipo Cotejamiento Atributos Nulo Predeterminado Extra Artistica int(11) No Biologia int(11) No Castellano int(11) No Contabilidad int(11) No Economia int(11) No EduFisica int(11) No Emprendimiento int(11) No Filosofia int(11) No Fisica int(11) No Informatica int(11) No Ingles int(11) No Matematica int(11) No Naturales int(11) No Religion int(11) No Quimica int(11) No Sociales int(11) No

Campo AsignaCodi
Tabla Docente

Tipo Cotejamiento Atributos Nulo Predeterminado Extra int(11) No

Campo Tipo Cotejamiento Atributos Nulo Predeterminado Extra Identificacion int(15) No Nombres text utf8_general_ci No Apellidos text utf8_general_ci No Expedida text utf8_general_ci No FechaNito date No Direccion text utf8_general_ci No Telefono int(10) No E-mail text utf8_general_ci No Materia text utf8_general_ci No Profesin text utf8_general_ci No

Empresa o Entidad Campo Tipo IdColegio int(5) NomColegio text Direccion varchar(70) Ciudad varchar(50) Dmento varchar(50) Telefono varchar(10) Rector varchar(70) CoordiJor varchar(70) NitColegio varchar(15) Resoluccion varchar(30) RegDane varchar(15)

Cotejamiento Atributos Nulo Predeterminado Extra No utf8_general_ci No utf8_general_ci No utf8_general_ci No utf8_general_ci No utf8_general_ci No utf8_general_ci No utf8_general_ci No utf8_general_ci No utf8_general_ci No utf8_general_ci No

Tabla Estudiante Campo Tipo Cotejamiento Atributos Nulo Predeterminado Extra Nombres text utf8_general_ci No Apellidos text utf8_general_ci No TipoDocumen text utf8_general_ci No Identificacion int(15) No Expedida text utf8_general_ci No FechaNito date No Sexo text utf8_general_ci No Direccion text utf8_general_ci No

Campo TelefonoEst Grado Procedencia NomAcudien TelefonoAcu

Tipo Cotejamiento Atributos Nulo Predeterminado Extra int(10) No text utf8_general_ci No text utf8_general_ci No text utf8_general_ci No text utf8_general_ci No

Grado Campo Tipo Cotejamiento Atributos Nulo Predeterminado Extra Grado 6 text utf8_general_ci No Grado 7 text utf8_general_ci No Grado 8 text utf8_general_ci No Grado 9 text utf8_general_ci No Grado 10 text utf8_general_ci No Grado 11 text utf8_general_ci No IdGrado int(5) No

Tabla Logros Campo Tipo Cotejamiento Atributos Nulo Predeterminado Extra IdLogro int(3) No Logro text utf8_general_ci No AsignaCodi int(3) No

Tabla Notas Campo Tipo Cotejamiento Atributos Nulo Predeterminado Extra IdNota int(10) No IdEstudiante int(11) No IdMateria int(11) No NotaFinal int(11) No Observacion text utf8_general_ci No