В статье рассматриваются вопросы разработки базы данных для комплекса программно-инструментальных средств мониторинга образовательного процесса в школьном учреждении. На начальных этапах разработки любой системы важно правильно спроектировать базу данных. Предлагается вариант архитектуры реляционной базы данных, в которой основные таблицы принадлежат нескольким подсистемам одновременно.
Ключевые слова: информационно-образовательная среда, база данных, контроль образовательного процесса, инструментальный комплекс, клиентская БД, PostgreSQL
Важным этапом разработки подсистемы контроля учащихся является создание базы данных. В Rails обычно используются три вида СУБД: SQLite, MySQL, PostgreSQL. Для системы мониторинга образовательного процесса была разработана системы с использованием СУБД PostgreSQL, т. к. эта современная СУБД ничем не уступает аналогам. Она является самой профессиональной, свободно распространяется и максимально соответствует стандартам SQL. От аналогов PostgreSQL отличается поддержкой востребованного объектно-ориентированного и/или реляционного подхода к базам данных. Например, СУБД обеспечивает полную поддержку надежных транзакций, т. е. атомарность, последовательность, изоляционность, прочность (Atomicity, Consistency, Isolation, Durability — ACID). Благодаря мощным технологиям PostgreSQL имеет высокую производительность. Параллельность достигается не за счет блокировки операций чтения, а благодаря реализации управления многовариантным параллелизмом (MVCC), что также обеспечивает соответствие требованиям ACID. PostgreSQL легко расширяется через встроенные процедуры, которые называются хранимыми процедурами. Эти функции упрощают использование постоянно повторяемых операций. Хотя PostgreSQL не может похвастаться большой популярностью в отличии от MySQL, существует довольно большое число приложений облегчающих работу с СУБД, что повышает мощность функционала [1].
Разработка структуры базы данных.
На текущий момент времени разработана и настроена база данных для подсистемы «Электронный журнал». Наглядную структуру БД можно вывести с помощью процедуры «railroady». В результате создания моделей сущностей и их связей в среде Ruby on Rails была разработана схема БД (Рис. 1):
Рис. 1. Логическая схема БД
Фрагмент физической модели БД представлен на рисунке 2.
Рис. 2. Фрагмент физической модели БД
Архитектура БД позволяет системе работать с 9 сущностями:
− Администратор (независимая сущность) — содержит учетные данные об администраторе сайта: Электронная почта, Пароль и др. Также в данной группе пользователей планируется назначить одной или нескольким записям наибольшие root-права суперадминистратора;
− Пользователь (независимая сущность) — абстрактный класс, от которого наследуются все пользователи: Ученики, Учителя, Родители;
− Учитель (зависимая сущность) — содержит необходимые данные о пользователях категории учитель;
− Ученик (зависимая сущность) — содержит необходимые данные о пользователях категории ученик;
− Родитель (зависимая сущность) — содержит необходимые данные о пользователях категории родителях;
− Класс (независимая сущность) — содержит необходимые данные о классах пользователей;
− Предмет (независимая сущность) — содержит необходимые данные о обучаемых дисциплинах;
− Ученик-Предмет (зависимая сущность) — связная таблица, которая содержит соответствие сущностей Ученик и Предмет, необходимое для простановки оценок;
− Предмет-Оценка (независимая сущность) — содержит данные по выставленных оценкам.
БД в среде Ruby on Rails создается постепенно с помощью миграций. Любое изменение полей таблиц также производится с помощью миграций. Ниже приведено пример миграции при создании таблицы «Классы»:
class CreateGrades < ActiveRecord::Migration[5.0]
def change
create_table :grades do |t|
t.string :name
t.integer :teacher_id
t.string :comment
t.timestamps
end
end
end
Для подсистемы идентификации предлагается модифицировать таблицу «Пользователи» путем добавления MAC адреса//IMEA идентификатора и IP адреса мобильного средства связи ученика и добавить таблицу «Присутствие»:
Рис. 3. Таблица «Присутствие» для БД
Данная таблица привязывается через таблицу «Присутствие_Ученик» к таблице «Ученик», для того, чтобы данные таблицы в дальнейшем можно было использовать для различных оповещений и push уведомлений.
Для поддержки работы с платежно-расчетной компонентой системы мониторинга в основную БД интегрированы таблицы (Рис. 4):
Рис. 4. Таблицы для финансовой компоненты
Таблица с учетными данными пользователей используется в каждой из подсистем. В этом основной смысл процесса интеграции, в рамках которого выполняется объединение разработанных программно-инструментальных средств в единую систему мониторинга.
Литература:
- devacademy.ru. [Электронный ресурс] — Режим доступа: http://devacademy.ru/posts/sqlite-vs-mysql-vs-postgresql/ (дата обращения: 03.05.2017).
- guides.rubyonrails.org [Электронный ресурс] — Режим доступа: http://guides.rubyonrails.org/configuring.html (дата обращения: 03.05.2017).
