¿Cómo ayuda el diseño de la base de datos a organizar a los profesores, las lecciones y los estudiantes?

Una inversión en conocimiento paga el mejor interés.

Benjamin Franklin

En el mundo moderno, la educación es omnipresente. Ahora más que nunca, juega un papel importante en nuestra sociedad. De hecho, es muy importante que muchos de nosotros continuemos nuestra educación mucho después de terminar la escuela o la universidad.

Todos hemos oído hablar del aprendizaje permanente, la educación no formal y los talleres para todas las edades. Estos métodos difieren de la educación formal en muchos aspectos, pero también tienen cosas en común. Hay clases, lecciones, profesores y alumnos. Y al igual que en un entorno tradicional, querremos realizar un seguimiento del horario de clases, los datos de asistencia y el rendimiento del instructor o del estudiante. ¿Cómo podemos diseñar una base de datos para satisfacer estas necesidades? Eso es lo que cubriremos en este artículo.

Presentamos nuestro modelo de base de datos de educación

El modelo presentado en este artículo nos permite almacenar datos sobre:

• clases/conferencias
• instructores/conferencistas
• estudiantes
• asistencia a conferencias
• rendimiento de estudiantes/profesores

También podríamos utilizar este modelo como horario escolar, para otras actividades en grupo (clases de natación, talleres de baile) o incluso para actividades individuales como tutorías. Todavía hay mucho espacio para mejoras, como el almacenamiento de datos de ubicación de clase o la duración del taller; Cubriremos esto en próximos artículos.

Comencemos con los elementos básicos de nuestra base de datos de Educación:las tablas.

Los Tres Grandes:Mesas de Estudiante, Instructor y Clase

El student , instructor y class las tablas constituyen el núcleo de nuestra base de datos.

El student La tabla, que se muestra arriba, se utiliza para almacenar datos básicos sobre los estudiantes, pero se puede ampliar según las necesidades específicas. Con la excepción de los tres atributos de contacto, todos los atributos de la tabla son obligatorios:

• first_name – el nombre del estudiante
• last_name – el apellido del estudiante
• birth_date – la fecha de nacimiento del estudiante
• contact_phone – el número de teléfono del estudiante
• contact_mobile – el número de teléfono móvil del estudiante
• contact_mail – la dirección de correo electrónico del estudiante
• category_id – es una referencia a la category catalogar. Con esta estructura, estamos limitados a una sola categoría por alumno. Eso funciona en la mayoría de los casos, pero en algunas situaciones es posible que necesitemos espacio para enumerar varias categorías. Como puede ver, agregando una relación de muchos a muchos que conecta el student tabla con la category diccionario resuelve este problema. Sin embargo, en este escenario, necesitaremos escribir consultas bastante más complejas para manejar nuestros datos.

Ya que lo mencionamos, sigamos adelante y discutamos la category mesa aquí.

Esta tabla es un diccionario que sirve para agrupar a los alumnos en función de determinados criterios. El first_name El atributo es el único dato en la tabla (además de id , la clave principal) y es obligatorio. Un conjunto de valores que podría almacenarse aquí es el estado laboral del estudiante:"estudiante", "empleado", "desempleado" y "jubilado". También podríamos usar otros conjuntos basados ​​en algunos criterios muy específicos, como "le gusta el yoga", "le gusta el senderismo", "le gusta andar en bicicleta" y "no le gusta nada".

El instructor La tabla contiene una lista de todos los instructores/profesores de la organización. Los atributos en la tabla son:

• first_name – el nombre del instructor
• last_name – el apellido del instructor
• title – el título del instructor (si corresponde)
• birth_date – la fecha de nacimiento del instructor
• contact_phone – el número de teléfono del instructor
• contact_mobile – el número de teléfono móvil del instructor
• contact_mail – la dirección de correo electrónico del instructor

El title y los tres contact Los atributos no son obligatorios.

El student mesa y instructor table comparten una estructura similar, pero existe otra posibilidad de organizar esta información. Un segundo enfoque sería tener una person table (que almacena todos los datos de empleados y estudiantes) y tiene una relación de muchos a muchos que nos dice todos los roles asignados a esa persona. La ventaja más importante del segundo enfoque es que almacenaremos los datos solo una vez. Si alguien es instructor en una clase y estudiante en otra, aparecerá solo una vez en la base de datos, pero con ambos roles definidos.

¿Por qué seleccionamos el enfoque de dos tablas para nuestro modelo de base de datos educativa? Generalmente, los estudiantes y los instructores se comportan de manera diferente, tanto en la vida real como en nuestra base de datos. Por eso, podría ser conveniente almacenar sus datos por separado. Podemos encontrar otras formas de fusionar cualquier información de la misma persona que aparece en ambas tablas (por ejemplo, un par de consultas de inserción/actualización basadas en una identificación externa, como un número de seguro social o número de IVA).

La class table es un catálogo que contiene detalles sobre todas las clases. Podemos tener múltiples instancias de cada tipo de clase. Los atributos de la tabla son los siguientes (todos son obligatorios excepto end_date ):

• class_type_id – es una referencia al class_type diccionario.
• first_name – es un nombre corto de la clase.
• description – esta descripción es más específica que la del class_type mesa.
• start_date – la fecha de inicio de la clase.
• end_date – la fecha de finalización de la clase. No es obligatorio porque es posible que no siempre sepamos la fecha exacta de finalización de cada clase por adelantado.
• completed – es un valor booleano que indica si todas las actividades planificadas de la clase han finalizado. Esto es útil cuando hemos llegado a la end_time planificada. para una clase, pero otras actividades de la clase aún no se han completado.

El class_type table es un catálogo simple, destinado a almacenar información básica sobre las conferencias o clases que se ofrecen a los estudiantes. Podría contener valores como "Idioma inglés (grupo)", "Idioma polaco (grupo)", "Idioma croata (grupo)", "Idioma inglés (en persona)" o "Clases de baile". Solo tiene dos atributos obligatorios:name y description , los cuales no necesitan más explicación.

El class_schedule tabla contiene tiempos específicos para conferencias y clases. Todos los atributos de la tabla son obligatorios. El class_id atributo es una referencia a la class tabla, mientras que start_time y end_time son las horas de inicio y finalización de esa conferencia específica.

¿Quién está aquí? Tablas relacionadas con la asistencia

El attend tabla almacena información sobre qué estudiante asistió a qué clase y el resultado final. Los atributos en la tabla son:

• student_id – es una referencia al student mesa
• class_id – es una referencia a la class mesa
• class_enrollment_date – es la fecha en que el estudiante comenzó a asistir a esa clase
• class_drop_date – la fecha en que el alumno abandonó la clase. Este atributo tendrá valor solo si el estudiante abandonó la clase antes de la fecha de finalización de la clase. En ese caso, el drop_class_reason_id también se debe establecer el valor del atributo.
• drop_class_reason_id – es una referencia al drop_class_reason mesa
• attendance_outcome_id – es una referencia al attendance_outcome mesa

Todos los datos excepto class_drop_date y drop_class_reason_id es requerido. Estos dos se completarán si y solo si un estudiante abandona la clase.

El drop_attendance_reason table es un diccionario que contiene las diversas razones por las que un estudiante puede abandonar un curso. Solo tiene un atributo, reason_text , y es obligatorio. Un conjunto de valores de ejemplo podría incluir:"enfermedad", "pérdida de interés", "no tiene suficiente tiempo" y "otros motivos".

El attendance_outcome La tabla contiene descripciones sobre la actividad de los estudiantes en un curso determinado. El outcome_text es el único atributo en la tabla y es obligatorio. Un conjunto de valores posibles es:"en progreso", "completado con éxito", "completado parcialmente" y "no ha completado la clase".

¿Quién está a cargo? Mesas relacionadas con la enseñanza

El teach , drop_teach_reason y teach_outcome las tablas usan la misma lógica que el attend , drop_attendance_reason y attendance_outcome mesas. Todas estas tablas almacenan datos sobre las actividades relacionadas con el curso de los instructores.

El teach La tabla se utiliza para almacenar información sobre qué instructor está enseñando qué clase. Los atributos en la tabla son:

• instructor_id – es una referencia al instructor mesa.
• class_id – es una referencia a la class mesa.
• start_date – es la fecha en que el instructor comenzó a trabajar en esa clase.
• end_date – es la fecha en que el instructor dejó de trabajar en esa clase. No es obligatorio porque no podemos saber de antemano si el instructor enseñará hasta la fecha de finalización de la clase.
• drop_teach_reason_id – es una referencia al drop_teach_reason mesa. No es obligatorio porque el instructor no puede abandonar la clase.
• teach_outcome_id – es una referencia al teach_outcome_reason mesa.

El drop_teach_reason table es un simple diccionario. Contiene un conjunto de posibles explicaciones por las que el instructor terminó de impartir la clase antes de su fecha de finalización. Solo hay un atributo obligatorio:reason_text . Esto podría ser "enfermedad", "traslado a otro proyecto/trabajo", "renunciar" u "otro motivo".

El teach_outcome La tabla describe el éxito del instructor en un curso en particular. El outcome_text es el único atributo de la tabla y es obligatorio. Los valores posibles para esta tabla podrían ser:"en progreso", "completado con éxito", "completado parcialmente" y "no ha completado la clase de enseñanza".

La student_presence La tabla se utiliza para almacenar datos sobre la presencia de estudiantes para una clase específica. Podemos suponer que para cada clase el instructor anotará la presencia y/o ausencia de todos los estudiantes. Los atributos en la tabla son:

• student_id – es una referencia al student mesa
• class_schedule_id – es una referencia al class_schedule mesa
• present – es una marca booleana si el estudiante está presente en la lección o no

Podríamos monitorear la presencia de los estudiantes en una clase específica con una consulta como la siguiente (asumiendo que @id_class contiene la identificación de la clase que queremos).

SELECT
	a.id, 
	CONCAT(a.first_name, ' ', a.last_name) AS student_name,
	a.number_total, 
	CONCAT(CONVERT(a.number_present / a.number_total * 100, DECIMAL(5,2)), '%') AS percentage,
	a.attendance_outcome
FROM
(
SELECT 
	student.id, 
	student.first_name, 
	student.last_name, 
	SUM(CASE WHEN student_presence.present = True THEN 1 ELSE 0 END) AS number_present,
	COUNT(DISTINCT class_schedule.id) AS number_total,
	attendance_outcome.outcome_text AS attendance_outcome
FROM class
	INNER JOIN attend ON class.id = attend.class_id
	INNER JOIN student ON attend.student_id = student.id
	LEFT JOIN class_schedule ON class_schedule.class_id = class.id
	LEFT JOIN student_presence ON student_presence.student_id = student.id AND student_presence.class_schedule_id = class_schedule.id
	LEFT JOIN attendance_outcome ON attendance_outcome.id = attend.attendance_outcome_id
WHERE class.id = @id_class
GROUP BY 
	student.id, 
	student.first_name, 
	student.last_name, 
	attendance_outcome.outcome_text
) a  

La tabla "instructor_presence" usa la misma lógica que la tabla "student_presence", pero aquí queremos centrarnos en los instructores. Los atributos en la tabla son:

• instructor_id – es una referencia al instructor mesa
• class_schedule_id – es una referencia al class_schedule mesa
• present – es un valor booleano que representa si el instructor está presente en la lección o no

Podríamos usar la siguiente consulta para monitorear la actividad del instructor en clase:

SELECT
	a.id, 
	CONCAT(a.first_name, ' ', a.last_name) AS instructor_name,
	a.number_total,
	CONCAT(CONVERT(a.number_present / a.number_total * 100, DECIMAL(5,2)), '%') AS percentage,
	a.teach_outcome
FROM
(
SELECT 
	instructor.id, 
	instructor.first_name, 
	instructor.last_name, 
	SUM(CASE WHEN instructor_presence.present = True THEN 1 ELSE 0 END) AS number_present,
	COUNT(DISTINCT class_schedule.id) AS number_total,
	teach_outcome.outcome_text AS teach_outcome
FROM class
	INNER JOIN teach ON class.id = teach.class_id
	INNER JOIN instructor ON teach.instructor_id = instructor.id
	LEFT JOIN class_schedule ON class_schedule.class_id = class.id
	LEFT JOIN instructor_presence ON instructor_presence.instructor_id = instructor.id AND instructor_presence.class_schedule_id = class_schedule.id
	LEFT JOIN teach_outcome ON teach_outcome.id = teach.teach_outcome_id
WHERE class.id = @id_class
GROUP BY 
	instructor.id, 
	instructor.first_name, 
	instructor.last_name, 
	teach_outcome.outcome_text
) a 

Ahora, terminemos discutiendo las tablas de personas de contacto.

¿A quién podemos llamar? Tablas de personas de contacto

En la mayoría de los casos, no necesitamos almacenar información de contacto de emergencia (es decir, en caso de emergencia, comuníquese con esta persona). Sin embargo, esto cambia cuando enseñamos a los niños. Por ley o por costumbre, necesitamos tener una persona de contacto para cada niño al que enseñamos. En nuestras tablas modelo:contact_person , contact_person_type y contact_person_student – Demostramos cómo se puede hacer esto.

La contact_person La tabla es una lista de personas relacionadas con los estudiantes. Por supuesto, no necesitamos enumerar a todos los parientes; en su mayoría tendremos uno o dos contactos por estudiante. Esta es una buena manera de encontrar "a quién llamarás" cuando el estudiante necesite o quiera irse temprano. Los atributos en la tabla son:

• first_name – es el nombre de la persona de contacto
• last_name – es el apellido de la persona
• contact_phone – es el número de teléfono de la persona
• contact_mobile – es el número de teléfono móvil de la persona
• contact_mail – es la dirección de correo electrónico de la persona

Los datos de contacto no son obligatorios, aunque son muy útiles.

El contact_person_type table es un diccionario con un solo atributo requerido:type_name . Ejemplos de valores almacenados en esta tabla son:"madre", "padre", "hermano", "hermana" o "tío".

El contact_person_student table es una relación de muchos a muchos que conecta a las personas de contacto y su tipo con los estudiantes. Los atributos en la tabla son (todos son obligatorios):

• contact_person_id – es una referencia a la contact_person mesa
• student_id – es una referencia al student mesa
• contact_person_type_id – es una referencia al contact_person_type mesa

Puede valer la pena mencionar que esta relación de muchos a muchos conecta tres tablas entre sí. El par de atributos contact_person_id y student_id se utiliza como clave alternativa (ÚNICA). De esa forma, deshabilitaremos las entradas duplicadas que conectan a estudiantes individuales con la misma persona de contacto. El atributo contact_person_type_id no es parte de la clave alternativa. Si es así, podríamos tener múltiples relaciones para la misma persona de contacto y el mismo estudiante (usando diferentes tipos de relación), y eso no tiene sentido en situaciones de la vida real.

El modelo presentado en este artículo debería ser capaz de cubrir las necesidades más comunes. Aún así, partes del modelo podrían excluirse en algunos casos, p. probablemente no necesitaríamos todo el segmento de personas de contacto si nuestros estudiantes son adultos. Como dije antes, agregaremos mejoras a esto con el tiempo. Siéntase libre de agregar sugerencias y compartir su experiencia en las secciones de discusión.