Программисты сегодня востребованы во всех отраслях народного хозяйства. И школы – не исключение. Внедрение электронных журналов, электронных баз знаний и электронных экзаменаторов дают большой прогресс в развитии образования. Но единого языка, на котором бы разговаривали учителя и завучи с программистами, к сожалению, нет. Из-за незнания специфики работы школ программисты пишут программы, которые при внедрении вызывают раздражение учителей. А из-за того, что многие тонкости планирования и учета учебного процесса учителя считают «само собой разумеющимися», программисты узнают о них, когда программа уже закончена. Поэтому поделюсь своим небольшим опытом в работе со школами.
Любая база данных начинается со справочников. Справочники – это оси измерений, по которым будет расти и развиваться Ваша база данных. Мы тоже начнем со справочников. Даже если Вы пишете программу для одной школы, начните со справочника школ. Ведь ученики могут приходить из других школ прямо во время учебного года, а могут и уходить в другие школы. Да и учителя нередко увольняются и устраиваются на работу, переходя из школы в школу. Для регистрации этих движений и нужна ось-шкала-справочник школ. В самой таблице могут быть колонки с наименованием и адресом, почтовыми и телеграфными реквизитами, даже расчетные счета можно туда включить, но главное – любой справочник содержит уникальный ключ, который позволит однозначно связать строки из других таблиц с единственной нужной строкой в справочнике школ.
Мы уже упомянули учеников и учителей. По ним тоже должны быть справочники. Вот только атрибуты этих справочников нужно набирать осторожно. Поскольку в процессе работы будут передвижения как тех, так и других и по классам, и по школам, и по урокам или предметам, в справочники следует заносить только неизменные параметры: Фамилия, Имя, Отчество, год рождения, пол, ну и другие атрибуты, не меняющиеся во времени. А вот все то, что связано с изменениями в процессе работы или обучения, следует разместить в отдельных таблицах, где указать ключ-ссылку на ученика/учителя, дату перехода в новое состояние и прочие элементы, описывающие переход. Для более понятного рассмотрения, введем еще справочник классов, в которые сгруппированы ученики. Сам справочник содержит немного столбцов: название (1а, 11к) и уникальный ключ для ссылок. Кроме этого, должен быть справочник кабинетов, связанный со зданием. И таблица связи между классами, кабинетами и уроками, которые эти классы занимают во время занятий. Этот пример будет в рассмотрении ориентировочного расписания.
Вернемся к ученикам. Полное описание ученика, которое мы начали со справочника, должно содержать следующие таблицы:
- перевод из класса/школы в другой класс/школу, кто, когда, по какой причине;
- получение оценки по предмету, когда, в каком классе, от какого учителя;
- посещение занятий – кто, когда, в каком классе;
- выполнение персональных заданий;
- получение поощрений и взысканий;
- выставление итоговых оценок за учебный период.
Из этого примера видно, что «ученик» – это многогранное понятие, и его «деятельность» в школе должна регистрироваться по многим параметрам в нескольких таблицах, с обязательной фиксацией времени каждого события и описанием самого события.
То же самое можно сказать и о преподавателях. Поступление на работу, выход в отпуск, общественные нагрузки – это примеры того, чем занимаются преподаватели, кроме проведения уроков в классе. Для преподавателей должна предусматриваться возможность временного ухода на лечение (больничный лист) и замены другого преподавателя, в случае необходимости. У преподавателя должна быть привязка к кабинету, в котором он проводит основное время и в котором несет ответственность за чистоту и порядок. Каждый учитель может одновременно присутствовать только в одном кабинете и только на одном уроке, поэтому должна быть таблица-карта привязки преподавателя к уроку, кабинету и классу, которому преподносится урок по определенному предмету.
Теперь немного о реляционных базах и их возможностях. Рассмотрим следующие справочники, данные здесь только для примера:
Справочник учеников:
- Код ученика
- Фамилия
- Имя
- Отчество
- Дата рождения
- Пол
- ключ-ссылка на новый код ученика
- дата перехода на новый код ученика
В процессе предварительного обсуждения статьи выяснилось, что фамилия, имя и отчество ученика может меняться в связи с изменениями состава семей. И это обязательно должно быть зафиксировано в архивах учебного процесса. Поэтому добавлены последние два поля справочника, позволяющие строить цепочку изменений в личных данных ученика. Ведь при выпуске его из школы понадобятся данные за весь период обучения, под какой бы фамилией ученик ни учился. Но к счастью, такие изменения очень редкие, поэтому строить ради них новую таблицу не стоит.
Список учителей:
- Код преподавателя
- Фамилия
- Имя
- Отчество
- год рождения
Список предметов:
- код предмета
- наименование
- коэффициент трудности
Список школ:
- код школы
- номер школы
- наименование школы
- Адрес
- Почтовые реквизиты
- Банковские реквизиты
Список классов:
- код школы
- код класса
- наименование класса
- дата присвоения имени.
В последнее время кроме прежних 1а, 7в, классам стали присваивать длинные имена, поднимающие настроение учащихся и определяющие учебную ориентацию класса, например «1-а Victory». На следующий год этот же 1-а может иметь другое имя, и эти имена надо будет архивировать, по мере их замены. Поэтому классы снабжены полем «Дата присвоения имени».
Список кабинетов:
- код школы
- код кабинета
- наименование кабинета
- вместимость.
Теперь рассмотрим привязку Учителя к школе:
- код школы
- код преподавателя
- дата приема на работу
- дата увольнения.
Каждый преподаватель может преподавать один, два и более предметов, поэтому привязка предметов к преподавателям может выглядеть так:
- код школы
- код преподавателя
- код предмета
- дата, с которой учитель может преподавать предмет
Аналогичные таблицы привязки должны быть созданы для распределения ответственности и объемов работ между преподавателями. К ним относятся:
- Распределение классов и групп в классах между преподавателями;
- Распределение объемов внеклассной работы;
- Возможные замены преподавателей на время отсутствия одного или нескольких.
Самое сложное в работе завуча школы – составить расписание так, чтобы не было «окон» (пустых уроков) у учеников, чтобы соблюсти все требования учителей (совместители-предметники обычно работают 2-3 дня в неделю), чтобы без накладок разместить все занятия по кабинетам, спортзалам, мастерским и другим местам проведения занятий. Кроме перечисленных трудностей бывают двухсменные школы, где последние занятия первой смены накладываются на первые уроки второй смены. Результатом такого труда должна стать следующая таблица:
1. Код школы
2. Код класса
3. Код строки расписания
4. Номер группы, если предмет делит класс на группы
5. Код учителя
6. Код 2-го учителя, если предмет делит класс на группы
7. Код предмета
8. Код кабинета или места проведения занятия
9. Код 2-го кабинета, если предмет делит класс на группы
10. Номер недели (четная/нечетная)
11. День недели проведения урока
12. Номер урока
Стоит заметить, что в конкретном случае список столбцов таблицы может быть увеличен, ну а где-то, где классы не делятся, может быть и уменьшен.
Чтобы избежать накладок в виде «один преподаватель должен быть одновременно в двух разных классах» необходимо создать целый ряд таблиц занятости.
Занятость класса:
1. Код школы
2. Код класса
3. Номер недели (четная/нечетная)
4. День недели проведения урока
5. Номер урока
6. Код строки расписания
Занятость преподавателя:
1. Код школы
2. Код учителя
3. Номер недели (четная/нечетная)
4. День недели проведения урока
5. Номер урока
6. Код строки расписания
Занятость кабинета:
1. Код школы
2. Код кабинета
3. Номер недели (четная/нечетная)
4. День недели проведения урока
5. Номер урока
6. Код строки расписания
Регистрация прихода-ухода учеников в школу может быть осуществлена в таблице
1. Код школы
2. Код ученика
3. Дата приема
4. Код класса
5. Код школы, из которой прибыл ученик, или код первичного поступления
6. Причина перевода или приема
Аналогичным образом можно создать таблицу для регистрации перемещения ученика из класса в класс
1. Код школы
2. Код ученика
3. Код класса, откуда ученик переведен
4. Код класса, куда ученик переведен
5. Дата перевода
6. Причина перевода
Ниже приведу пример журнала регистрации оценок учеников:
1. Код школы
2. Код класса
3. Код ученика
4. Код предмета
5. Код темы, за которую выставлена оценка.
6. Код учителя
7. Дата получения оценки
8. Оценка
9. Замечания учителя
10. Фактическая дата внесения оценки по часам компьютера.
Такой подход позволит отбирать оценки по любым критериям, например, что было у ученика в прошлой школе по предмету, или каков средний балл ученика за период, вычисление средних показателей класса, учителя, предмета и другие статистические данные.
Очень часто завучу приходится решать задачу замены преподавателя. Болезни, аварии и пробки на дорогах, домашние проблемы преподавателей превращаются в проблему завуча: «Кого направить в класс, где отсутствует преподаватель?» Завуч должен иметь возможность оценить наличие свободных учителей, предупредить их о необходимости дополнительного выхода на работу и – самой главное – зафиксировать такие изменения в журнале регистрации фактических выходов учителей. И у учителей должна быть возможность внести и просмотреть данные в журналах о своих незапланированных выходах.
Вы, наверное, заметили, что все таблицы с накопительными данными начинаются с кода школы. Места этот код занимает мало, для него достаточно двухбайтового поля (0-65535), зато отбор можно производить по всем школам, в которых побывал ученик или только по одной. Для кабинетов и предметов тоже достаточно двух байт. А вот для кодов учеников и учителей желательно брать не менее 4 байт, поскольку данные будут накапливаться во времени, и количество зарегистрированных учеников за 50 лет будет измеряться миллионами. Преподаватели меняются реже, но все равно количество принятых учителей за десятки лет набежит больше 65 тысяч. Даже классы с длинным наименованиями требуют 4-х байтового ключа.
Отмечу еще одно качество программы, без которого работать с ней становится с годами очень трудно – это архивы. Практически вся информация о прохождении учебы должна храниться не менее 50 лет. Теперь представьте себе список учеников за такой срок. Следует делить пространство данных на оперативную и архивную информацию. Надо предусматривать перенос информации в архив, по мере завершения учебы, перевода в другую школу, увольнения или других причин завершения взаимодействия с данной школой. Наблюдаются частые случаи временного перевода ученика в другую школу с последующим его возвратом. То же самое можно сказать об учителях.
Восстановление данных из архива должно быть очень дозировано или отфильтровано. В качестве фильтра должен быть не только код ученика или учителя, но и обязательно период, за который восстанавливаются данные, школа, для которой производится выемка данных из архива. Необходимо отметить, что задание периода действия практически любой функции – это реальная необходимость. Можно ввести в поля ввода значения по умолчанию, но нужно обязательно дать возможность пользователю изменить даты начал и конца проводимой операции.
Стоит взять пример с классических программ WORD и EXCEL в части возможности отменить последние внесенные изменения (функция UNDO). Преподаватель, работающий с вашей программой, имеет право на ошибку. Если он ошибочно ввел не те данные или не туда, особенно при пакетном вводе на 100-200 записей, а отменить изменения нельзя, то будет потрачено много времени на исправление оплошности. А если при этом портятся «чужие» данные, Ваша программа станет причиной конфликта. Поэтому функция UNDO на несколько шагов назад просто незаменима для Вашей программы.
Еще один совет о качестве оформления входных форм. Если Ваше окно разделено на подокна и каждом из них имеются даты, надо предусмотреть автоматическую синхронизацию движения во всех связанных подокнах. Например, в левом окне список учеников и их оценки по датам (дата, как правило в верхней строке). В правом окне тематический план с датами в первой колонке и наименованием темы во второй. Надо обязательно добиться, чтобы скроллинг левого окна по горизонтали (по датам) сопровождался скроллингом правого окна по вертикали (тоже по датам). Это нужно, чтобы учитель видел, за какую тему он выставил оценки ученику.
Еще немного об отношениях «школа – ученик». В большинстве случаев этих отношений не видно, но имеется немало прецедентов, когда происходит оспаривание оценок, выставленных за период обучения. База данных могла бы быть неким «свидетелем по делу» в вопросе правильности оценок, полученных учеником. Для этого стоит максимально полно фиксировать все действия преподавателей, например ввод и замену учебных тем в журналах. Следует сопровождать все действия преподавателей датой выполнения действий по часам компьютера. И обязательно подробно фиксировать выставление оценок с обязательной фиксацией фактического времени заполнения журнала оценок.
Раз уж речь зашла о перечне учебных тем, надо отметить еще одну особенность современного преподавания – ориентацию классов на углубленное изучение одних предметов в ущерб другим. Эта особенность предполагает, что в разных классах выделяется разное число учебных часов на одни и те же предметы. Соответственно этому тематический план составляется не для всей школы, а для каждого класса отдельно. И при составлении расписания классам выделяется неодинаковое число часов на изучение предметов. Такую гибкость несложно обеспечить, снабдив таблицу тематического плана полем «Код класса». Тогда можно каждому классу ввести свой тематический план, а для большинства поставить обобщающий код (например ноль) для тех часов и предметов, которые должны быть использованы по умолчанию для всех классов. Естественно, при отборе данных программа должна сначала выбрать индивидуальные данные для класса, а потом заполнить свободные места обобщенными данными.
О тематическом журнале можно говорить много. С одной стороны, желательно избегать повторения одинаковых записей. Но, с другой стороны, темы из года в год повторяются. А часы на них выделяются по-разному, ведь жизнь не стоит на месте. Может стоит иметь «скользящий» тематический список, из которого можно одни темы переносить в архив, другие добавлять? Вот удалять полностью из системы запись можно, только если тема не использовалась 50 лет. Иначе грош цена всем нашим архивам.
Тематический план желательно разбить на две или больше таблицы. В первой код темы, наименование и дата появления темы в справочнике. А во второй конкретизация по годам, классам и часам проведения. Например:
- Код темы
- Код класса
- Число часов
- учебный год
- дата ввода или корректировки данных
Такой подход обеспечит единство наименований при разнообразии учебных нагрузок по классам и годам.
И еще об одном участнике учебного процесса стоит упомянуть – это Родитель. В современном мире это активный деятель, который следит за состоянием учебного процесса и защищает интересы своего ребенка. Ничего плохого в этом нет, но накладывает на программиста дополнительные обязанности. Нужно создать справочник родителей, в котором указать фамилию, имя, отчество, домашний адрес, телефон, логин для просмотра данных своего ребенка. Ни в коем случае в этот справочник не должны попасть данные о ребенке. Необходимо помнить – у одного ученика может быть несколько родителей (бабушек и дедушек), и у одного родителя может быть несколько детей. Поэтому списки родителей должны быть независимы от списков учеников, но обязательно должны быть таблицы привязки родителей к ученикам. Такой привязкой может быть:
- Код школы
- Код ученика
- Код родителя
- дата начала привязки
- дата прекращения привязки
В этой статье нет подробной постановки задач регистрации школьного учебного процесса. Мне хотелось показать, что не надо все показатели собирать в справочники, потому что многие показатели меняются во времени. И не надо экономить таблицы, лучше объединять данные из разных таблиц запросами, чем выделять отдельные поля в длинных записях. Реляционная база данных тем и хороша, что позволяет за счет таблиц связей создавать очень сложные и удивительно гибкие средства для хранения и отбора данных. Именно такие «таблицы отношений» значительно упрощают последующую модернизацию и развитие системы.
Последняя заповедь программиста – если Вы закончили писать программу и сдали ее заказчику, значит программа начала свою самостоятельную жизнь. И теперь она будет требовать от программиста развития, расширения и углубления своих возможностей. Можно начать работу над программой. Закончить эту работу можно только уничтожив программу.
Спасибо, что дочитали статью до конца.
