2 Обоснование модели данных
Для реализации БД решено выбрать реляционную базу данных. Данная модель подходит для постоянно изменяющихся потоков данных, таблицы можно легко добавлять, изменять и удалять, не нарушая целостность данных. Это позволяет легко адаптировать базу данных под изменяющиеся требования и добавлять новые данные без значительных изменений в существующей структуре.
Главным достоинством данной модели для БД школы является простота и доступность для понимания конечным пользователем. Завучу не потребуется иметь дела с физической структурой памяти, а работать непосредственно с уже имеющейся в БД информацией.
Перед непосредственным созданием БД необходимо отобразить логику взаимодействия системы, для этого создается концептуальная ER-диаграмма, которая представлена на рисунке 1.
В блоке «ВЕДОМОСТЬ» содержится информация об успеваемости каждого ученика по заданным предметам. Модальности отношений учитывают, что ученик должен получить оценку в ведомость, то есть не аттестация означает оценку «2», при этом в ведомости должны содержаться все предметы.
«РАСПИСАНИЕ» является самой большой таблицей и содержит большую часть необходимых сведений для завуча. Модальности для данного блока учитывают, что занятия для некоторого класса необязательно должны проходить, например если данный класс закрыт на карантин, кроме того, может случится так что некоторого предмета не будет в расписании, например физкультура и могут присутствовать кабинеты, в которых занятий временно нет. При этом если расписание существует, то оно должно содержать минимум одно занятие, в некотором кабинете для некоторого класса.
Блок «ПРЕПОДАВАНИЕ» необходим для фиксирования данных о том какие предметы может преподавать каждый учитель. Данный блок введен искусственно для устранения связи «многое ко многим» между сущностями «УЧИТЕЛЬ» и «ПРЕДМЕТ», так как один учитель может преподавать несколько предметов, и один предмет может преподаваться разными учителями. Информация о том какие предметы ведет учитель для конкретного класса содержаться в «РАСПИСАНИЕ».
Отношение между сущностями «УЧИТЕЛЬ» и «КАБИНЕТ» является отношением «один к одному», тот факт, что у некоторых учителей может не быть своего кабинеты отражается в модальности отношения, однако из-за этого количество записей в таблицах совпадать не будет, поэтому данный вид отношения возможен условно.
Рисунок 1 - Концептуальная ER-диаграмма проектируемой БД
Концептуальная диаграмма была построена с помощью онлайн сервиса «Miro» [1]
3 Обоснование выбора субд
Для реляционной модели данных соответственно необходима реляционная СУБД. Предпочтение было отдано СУБД PostgreSQL.
В большинстве СУБД, рассчитанных на средние и небольшие проекты, есть ограничения по объему базы и количеству записей в ней. В PostgreSQL ограничений нет [2].
Ограничения касаются только конкретных записей. Одна таблица может занимать не больше 32 Тб, а одна запись — 1,6 Тб. В одном поле записи может быть не больше 1 Гб данных, а максимальное количество полей зависит от типа и составляет от 250 до 1600 штук. Максимальных значений хватает, чтобы хранить в БД любые данные [2].
Данная СУБД является бесплатной с открытым исходным кодом, которая рассчитана на работу с объемными проектами. Она мощная, производительная, способна эффективно работать с большими массивами данных [2].
Важная особенность PostgreSQL - возможность одновременного доступа к базе с нескольких устройств. В СУБД реализована клиент-серверная архитектура, когда база данных хранится на сервере, а доступ к ней осуществляется с клиентских компьютеров. Благодаря этому базу данных можно расширить, внести дополнительные группы пользователей и функционал, что позволит, например учителям вносить изменения в БД, а ученикам просматривать данные о расписании и успеваемости.
PostgreSQL является максимально надежной и стабильной, с минимальным количеством багов, что является преимуществом в сравнении, например с MySQL.
С учетом особенностей выбранной СУБД, строится физическая диаграмма которая учитывает допустимые типы и наименования полей и таблиц, ограничения целостности и т.п. Физическая диаграмма представлена на рисунке 2.
Рисунок 2 – Физическая диаграмма БД
Следует отметить, что такие атрибуты как CLASS_NUMBER (номер класса), GRADE (оценка) и CLASSROOM_NUMBER (номер кабинета) должны иметь строковый тип данных, так как могут содержать буквы в зависимости от системы оценивания и нумеровки кабинетов.