Comment la conception de base de données aide-t-elle à organiser les enseignants, les leçons et les étudiants ?

Un investissement dans la connaissance rapporte le meilleur intérêt.

Benjamin Franklin

Dans le monde moderne, l'éducation est omniprésente. Aujourd'hui plus que jamais, elle joue un rôle important dans notre société. C'est tellement important, en fait, que beaucoup d'entre nous poursuivent leurs études bien après avoir terminé leurs études ou leurs études collégiales.

Nous avons tous entendu parler de l'apprentissage tout au long de la vie, de l'éducation non formelle et des ateliers pour tous les âges. Ces méthodes diffèrent de l'éducation formelle à bien des égards, mais elles ont aussi des points communs. Il y a des classes, des leçons, des professeurs et des étudiants. Et tout comme dans un cadre traditionnel, nous voudrons suivre l'horaire des cours, les données de présence et les résultats des instructeurs ou des élèves. Comment concevoir une base de données pour répondre à ces besoins ? C'est ce que nous allons couvrir dans cet article.

Présentation de notre modèle de base de données sur l'éducation

Le modèle présenté dans cet article nous permet de stocker des données sur :

• cours/conférences
• instructeurs/conférenciers
• étudiants
• participation aux conférences
• réussite des étudiants/enseignants

Nous pourrions également utiliser ce modèle comme emploi du temps scolaire, pour d'autres activités de groupe (cours de natation, ateliers de danse) ou même pour des activités individuelles comme le tutorat. Il reste encore beaucoup de place pour des améliorations, telles que le stockage des données de localisation des cours ou la durée des ateliers ; nous les couvrirons dans les prochains articles.

Commençons par les éléments de base de notre base de données Education :les tables.

Les trois grands :tableaux des étudiants, des enseignants et des classes

L'student , instructor , et class les tables constituent le cœur de notre base de données.

L'student La table ci-dessus est utilisée pour stocker des données de base sur les étudiants, mais elle peut être étendue en fonction de besoins spécifiques. À l'exception des trois attributs de contact, tous les attributs du tableau sont obligatoires :

• first_name – le nom de l'élève
• last_name – le nom de famille de l'élève
• birth_date – la date de naissance de l'élève
• contact_phone – le numéro de téléphone de l'élève
• contact_mobile – le numéro de téléphone portable de l'élève
• contact_mail – l'adresse e-mail de l'étudiant
• category_id – est une référence à la category catalogue. Avec cette structure, nous sommes limités à une seule catégorie par étudiant. Cela fonctionne dans la plupart des cas, mais dans certaines situations, nous pouvons avoir besoin d'espace pour répertorier plusieurs catégories. Comme vous pouvez le voir, l'ajout d'une relation plusieurs-à-plusieurs qui relie le student tableau avec la category dictionnaire résout ce problème. Dans ce scénario, cependant, nous devrons écrire des requêtes plus complexes pour gérer nos données.

Puisque nous l'avons mentionné, allons-y et discutons de la category tableau ici.

Ce tableau est un dictionnaire utilisé pour regrouper les élèves en fonction de certains critères. Le name l'attribut est la seule donnée de la table (en plus de id , la clé primaire) et c'est obligatoire. Un ensemble de valeurs pouvant être stockées ici est le statut d'emploi de l'étudiant :« étudiant », « employé », « sans emploi » et « retraité ». Nous pourrions également utiliser d'autres ensembles basés sur des critères très spécifiques, tels que « aime le yoga », « aime la randonnée », « aime le vélo » et « n'aime rien ».

Le instructor le tableau contient la liste de tous les instructeurs/conférenciers de l'organisation. Les attributs du tableau sont :

• first_name – le nom de l'instructeur
• last_name – le nom de famille de l'instructeur
• title – le titre de l'instructeur (le cas échéant)
• birth_date – la date de naissance du moniteur
• contact_phone – le numéro de téléphone du moniteur
• contact_mobile – le numéro de téléphone portable du moniteur
• contact_mail – l'adresse e-mail de l'instructeur

Le title et les trois contact les attributs ne sont pas obligatoires.

L'student table et instructor table partagent une structure similaire, mais il existe une autre possibilité pour organiser ces informations. Une deuxième approche serait d'avoir une person table (qui stocke toutes les données des employés et des étudiants) et a une relation plusieurs à plusieurs qui nous indique tous les rôles attribués à cette personne. L'avantage le plus important de la deuxième approche est que nous ne stockerons les données qu'une seule fois. Si quelqu'un est instructeur dans une classe et étudiant dans une autre, il n'apparaîtra qu'une seule fois dans la base de données, mais avec les deux rôles définis.

Pourquoi avons-nous choisi l'approche à deux tables pour notre modèle de base de données pédagogique ? Généralement, les étudiants et les instructeurs se comportent différemment, à la fois dans la vraie vie et dans notre base de données. Pour cette raison, il pourrait être judicieux de stocker leurs données séparément. Nous pouvons trouver d'autres moyens de fusionner les informations d'une même personne qui apparaissent dans les deux tableaux (par exemple, une paire de requêtes d'insertion/mise à jour basées sur un identifiant externe, tel qu'un numéro de sécurité sociale ou un numéro de TVA).

La class table est un catalogue qui contient des détails sur toutes les classes. Nous pouvons avoir plusieurs instances de chaque type de classe. Les attributs du tableau sont les suivants (tous sont obligatoires sauf end_date ):

• class_type_id – est une référence au class_type dictionnaire.
• name – est un nom abrégé de la classe.
• description – cette description est plus précise que celle du class_type tableau.
• start_date – la date de début du cours.
• end_date – la date de fin du cours. Ce n'est pas obligatoire car nous ne connaissons pas toujours à l'avance la date de fin exacte de chaque cours.
• completed – est une valeur booléenne qui indique si toutes les activités de classe planifiées sont terminées. C'est pratique lorsque nous avons atteint le end_time prévu pour une classe, mais d'autres activités de classe doivent encore être terminées.

Le class_type table est un simple catalogue, destiné à stocker des informations de base sur les conférences ou les cours proposés aux étudiants. Il peut contenir des valeurs telles que "Langue anglaise (groupe)", "Langue polonaise (groupe)", "Langue croate (groupe)", "Langue anglaise (en personne)" ou "Cours de danse". Il n'a que deux attributs obligatoires - name et description , qui n'ont pas besoin d'explications supplémentaires.

Le class_schedule le tableau contient des horaires spécifiques pour les conférences et les cours. Tous les attributs du tableau sont obligatoires. Le class_id l'attribut est une référence à la class table, tandis que start_time et end_time sont les heures de début et de fin de cette session spécifique.

Qui est là ? Tableaux relatifs aux présences

Le attend La table stocke des informations concernant quel élève a assisté à quelle classe et le résultat final. Les attributs du tableau sont :

• student_id – est une référence au student tableau
• class_id – est une référence à la class tableau
• class_enrollment_date – est la date à laquelle l'élève a commencé à assister à ce cours
• class_drop_date – la date à laquelle l'élève a quitté la classe. Cet attribut n'aura de valeur que si l'élève a abandonné le cours avant la date de fin du cours. Dans ce cas, le drop_class_reason_id la valeur de l'attribut doit également être définie.
• drop_class_reason_id – est une référence au drop_class_reason tableau
• attendance_outcome_id – est une référence au attendance_outcome tableau

Toutes les données sauf class_drop_date et drop_class_reason_id est requis. Ces deux seront pourvus si et seulement si un élève abandonne le cours.

Le drop_attendance_reason table est un dictionnaire contenant les différentes raisons pour lesquelles un étudiant peut abandonner un cours. Il n'a qu'un seul attribut, reason_text , et c'est obligatoire. Un exemple d'ensemble de valeurs pourrait inclure :"maladie", "perte d'intérêt", "n'a pas assez de temps" et "autres raisons".

Le attendance_outcome Le tableau contient des descriptions de l'activité des étudiants dans un cours donné. Le outcome_text est le seul attribut de la table et il est obligatoire. Un ensemble de valeurs possibles est :"en cours", "complété avec succès", "complété partiellement" et "n'a pas terminé la classe".

Qui est responsable ? Tableaux liés à l'enseignement

Le teach , drop_teach_reason et teach_outcome les tables utilisent la même logique que le attend , drop_attendance_reason et attendance_outcome les tables. Toutes ces tables stockent des données sur les activités liées aux cours des instructeurs.

Le teach table est utilisée pour stocker des informations sur quel instructeur enseigne quelle classe. Les attributs du tableau sont :

• instructor_id – est une référence au instructor tableau.
• class_id – est une référence à la class tableau.
• start_date – est la date à laquelle l'instructeur a commencé à travailler sur ce cours.
• end_date – est la date à laquelle l'instructeur a cessé de travailler sur cette classe. Ce n'est pas obligatoire car nous ne pouvons pas savoir à l'avance si l'instructeur enseignera jusqu'à la date de fin du cours.
• drop_teach_reason_id – est une référence au drop_teach_reason table. Ce n'est pas obligatoire car l'instructeur ne peut pas abandonner le cours.
• teach_outcome_id – est une référence au teach_outcome_reason tableau.

Le drop_teach_reason table est un simple dictionnaire. Il contient un ensemble d'explications possibles pour lesquelles l'instructeur a terminé l'enseignement du cours avant sa date de fin. Il n'y a qu'un seul attribut obligatoire :reason_text . Cela peut être « maladie », « passé à un autre projet/emploi », « démissionner » ou « autre raison ».

Le teach_outcome tableau décrit le succès de l'instructeur sur un cours particulier. Le outcome_text est le seul attribut de la table et il est obligatoire. Les valeurs possibles pour ce tableau pourraient être :"en cours", "réalisé avec succès", "réalisé partiellement" et "n'a pas terminé la classe d'enseignement".

La student_presence La table est utilisée pour stocker des données sur la présence des étudiants pour une session spécifique. Nous pouvons supposer que pour chaque conférence, l'instructeur notera la présence et/ou l'absence de tous les étudiants. Les attributs du tableau sont :

• student_id – est une référence au student tableau
• class_schedule_id – est une référence au class_schedule tableau
• present – est un marquage booléen indiquant si l'étudiant est présent ou non en cours

Nous pourrions surveiller la présence des étudiants dans une classe spécifique avec une requête comme celle qui suit (en supposant que @id_class contient l'identifiant de classe que nous voulons).

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 table "instructor_presence" utilise la même logique que la table "student_presence", mais ici nous voulons nous concentrer sur les instructeurs. Les attributs du tableau sont :

• instructor_id – est une référence au instructor tableau
• class_schedule_id – est une référence au class_schedule tableau
• present – est une valeur booléenne indiquant si l'instructeur est présent ou non en cours

Nous pourrions utiliser la requête ci-dessous pour surveiller l'activité de l'instructeur en classe :

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 

Terminons maintenant en abordant les tableaux des personnes de contact.

Qui pouvons-nous appeler ? Tableaux des personnes à contacter

Dans la plupart des cas, nous n'avons pas besoin de stocker les informations de contact d'urgence (c'est-à-dire qu'en cas d'urgence, contactez cette personne). Cependant, cela change lorsque nous enseignons aux enfants. Selon la loi ou la coutume, nous devons avoir une personne de contact pour chaque enfant que nous enseignons. Dans nos tableaux modèles – contact_person , contact_person_type et contact_person_student – nous montrons comment cela peut être fait.

Le contact_person table est la liste des personnes liées aux étudiants. Bien sûr, nous n'avons pas besoin d'énumérer tous les parents; la plupart du temps, nous aurons un ou deux contacts par étudiant. C'est un bon moyen de trouver « qui vous allez appeler » lorsque l'étudiant doit ou veut partir plus tôt. Les attributs du tableau sont :

• first_name – est le nom de la personne à contacter
• last_name – est le nom de famille de la personne
• contact_phone – est le numéro de téléphone de la personne
• contact_mobile – est le numéro de téléphone portable de la personne
• contact_mail – est l'adresse e-mail de la personne

Les coordonnées ne sont pas obligatoires, bien qu'elles soient très utiles.

Le contact_person_type table est un dictionnaire avec un seul attribut obligatoire :type_name . Des exemples de valeurs stockées dans cette table sont :"mère", "père", "frère", "sœur" ou "oncle".

Le contact_person_student table est une relation plusieurs-à-plusieurs qui relie les personnes de contact et leur type aux étudiants. Les attributs du tableau sont (tous sont obligatoires) :

• contact_person_id – est une référence au contact_person tableau
• student_id – est une référence au student tableau
• contact_person_type_id – est une référence au contact_person_type tableau

Il peut être utile de mentionner que cette relation plusieurs-à-plusieurs relie trois tables ensemble. La paire d'attributs contact_person_id et student_id est utilisée comme clé alternative (UNIQUE). De cette façon, nous désactiverons les entrées en double qui relient des étudiants individuels à la même personne de contact. L'attribut contact_person_type_id ne fait pas partie de la clé alternative. Si tel est le cas, nous pourrions avoir plusieurs relations pour la même personne de contact et le même élève (en utilisant différents types de relations), ce qui n'a aucun sens dans des situations réelles.

Le modèle présenté dans cet article devrait pouvoir couvrir les besoins les plus courants. Néanmoins, des parties du modèle pourraient être exclues dans certains cas, par ex. nous n'aurions probablement pas besoin de tout le segment des personnes-ressources si nos élèves sont des adultes. Comme je l'ai déjà dit, nous y ajouterons des améliorations en temps voulu. N'hésitez pas à ajouter des suggestions et à partager votre expérience dans les sections de discussion.