Как спроектировать базу данных для школы с предметами, учителями и учениками

Что проверяют

Видите ли вы связи «многие ко многим» и сущность, которая их соединяет. Школа кажется простой, но ловушек сразу несколько: учитель ведёт несколько предметов, у класса разные учителя по разным предметам, всё меняется от года к году. Следом просят написать запрос вроде «все ученики этого учителя» или добавить оценки.

Как отвечать

Начните с уточнений: нужна ли история за несколько лет, расписание, оценки, деление класса на группы. Дальше сущности:

• students, teachers, subjects: справочники. В teachers нет поля subject_id, иначе учитель ограничен одним предметом;
• school_classes: класс вроде «7А» в конкретном учебном году с классным руководителем. class в Python ключевое слово, поэтому модель удобнее назвать SchoolClass, а поле school_class;
• class_students: ученик, класс и год с UNIQUE (student_id, academic_year), чтобы ученик не попал в два класса сразу;
• teacher_subjects: какие предметы учитель вообще может вести;
• teaching_assignments: центральная таблица: класс, предмет, учитель, с уникальностью по (class_id, subject_id). К ней привязываются расписание и оценки. Деление на группы потребует ещё одной сущности;
• grades: ученик, назначение, дата, оценка с CHECK на допустимый диапазон.

В Python это модели SQLAlchemy 2.0 в стиле Mapped[...] с миграциями Alembic или модели Django, где связь «многие ко многим» с атрибутами оформляется через ManyToManyField(..., through=...). Упомяните индексы по внешним ключам: PostgreSQL сам их не создаёт.

Где спотыкаются

Заводят суррогатный enrollment_id и забывают про уникальность пары ученика и класса. База принимает дубли, и отчёт по классу считает ученика дважды.

Не вводят учебный год. В сентябре ученики переходят в следующий класс, и перезапись class_id стирает историю оценок и состава.

Путают класс как группу учеников и класс как курс по предмету. Одна таблица Classes на оба смысла делает любой запрос неоднозначным, и интервьюер это заметит.