Exemples / Gestion scolaire
Gestion scolaire
La base d’une école relie élèves et matières par les inscriptions. C’est la table d’association, et elle porte aussi la note. Les enseignants assurent les cours d’une matière pendant un trimestre. Les présences sont rattachées à l’inscription, avec une ligne par élève et par jour de cours.
Ci-dessous, ErdDocs dessine ce schéma à partir de son SQL, avec toutes les tables et relations. L’onglet « Dictionnaire de données » contient la version imprimable, complète et gratuite sur cette page. Le SQL se trouve plus bas.
Survolez une table pour mettre en évidence ses relations. Un clic les fige.
Le rôle de chaque table
- students / teachersDeux tables séparées. Élèves et enseignants ne partagent que le nom, leurs données et leur cycle de vie diffèrent.
- coursesL’entrée du programme. CS-101 existe une seule fois, quel que soit le nombre de sessions.
- sectionsLe cours, c’est une matière assurée par un enseignant pendant un trimestre. C’est ce que les élèves suivent réellement.
- enrollmentsTable d’association entre élève et cours. En plus des liens, elle porte la note.
- attendanceRattachée à l’inscription par une clé étrangère composée. On ne peut pas noter présent un élève à un cours où il n’est pas inscrit.
Des choix de conception à reprendre
- La séparation entre matière et cours est le fondement du schéma. Si l’on inscrit les élèves directement aux matières, tout casse dès qu’une matière est assurée deux fois. Il y a alors deux trimestres et deux enseignants, mais une seule colonne de note, qui ne veut plus rien dire.
- Les présences référencent l’inscription par une clé étrangère composée (student_id, section_id). C’est donc la base elle-même qui refuse la présence d’un élève non inscrit.
- La note accepte NULL au lieu d’avoir une valeur par défaut. Une note vide signifie que le trimestre est en cours, et non que l’élève a eu zéro.
Le SQL
Dialecte PostgreSQL. Ce SQL est déjà dans l’outil ci-dessus, et vous pouvez le copier librement dans votre base ou dans une migration.
CREATE TABLE students (
id bigserial PRIMARY KEY,
student_no varchar(20) NOT NULL UNIQUE,
full_name varchar(120) NOT NULL,
enrolled_on date NOT NULL
);
CREATE TABLE teachers (
id bigserial PRIMARY KEY,
full_name varchar(120) NOT NULL,
department varchar(80) NOT NULL
);
CREATE TABLE courses (
id bigserial PRIMARY KEY,
code varchar(12) NOT NULL UNIQUE,
title varchar(160) NOT NULL,
credits int NOT NULL
);
COMMENT ON COLUMN courses.code IS 'Code de la matière, par ex. CS-101';
CREATE TABLE sections (
id bigserial PRIMARY KEY,
course_id bigint NOT NULL REFERENCES courses(id),
teacher_id bigint NOT NULL REFERENCES teachers(id),
term varchar(20) NOT NULL,
room varchar(20)
);
COMMENT ON TABLE sections IS 'Une matière qu’un enseignant assure pendant un trimestre ; les élèves s’inscrivent aux cours, pas aux matières';
CREATE TABLE enrollments (
student_id bigint NOT NULL REFERENCES students(id),
section_id bigint NOT NULL REFERENCES sections(id),
grade varchar(2),
PRIMARY KEY (student_id, section_id)
);
COMMENT ON COLUMN enrollments.grade IS 'NULL jusqu’à la fin du trimestre';
CREATE TABLE attendance (
student_id bigint NOT NULL,
section_id bigint NOT NULL,
class_date date NOT NULL,
present boolean NOT NULL,
PRIMARY KEY (student_id, section_id, class_date),
FOREIGN KEY (student_id, section_id) REFERENCES enrollments(student_id, section_id)
);Questions fréquentes
Où mettre les responsables légaux ?
Dans une table guardians et une table d’association student_guardians. C’est une relation plusieurs à plusieurs : les frères et sœurs partagent leurs responsables, et un élève peut en avoir plusieurs.
Pourquoi ne pas mettre teacher_id dans courses ?
Parce que la même matière est enseignée par des enseignants différents selon les trimestres. L’enseignant appartient au cours, pas à l’entrée du programme.