ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ УЧЕТА РАСЧЕТОВ ЗА ПРОЖИВАНИЕ В ОБЩЕЖИТИИ

В настоящее время актуальной задачей является разработка различных информационных систем. Студентам Белгородского национального исследовательского университета, живущим в общежитии, была бы очень полезна информационная система учета расчетов за проживание. Получение своевременной и достоверной информации об оплате позволит избежать накопления долгов. Так же сбор сведений об оплате за проживание студентов в общежитии является важной задачей для администрации общежития. Поэтому авторами статьи была разработана автоматизированная система учета расчетов за проживание в общежитии (СУРПО).

Автоматизированная информационная система предназначена для решения следующих задач: 1) хранение информации о проживающих; 2) фиксация результатов расчета за проживание; 3) формирование и учет перерасчетов за проживание; 4) контроль доступа в систему.

Система должна обеспечивать следующие функции: 1) ввод, вывод, хранение информации о пользователях; 2) вывод, хранение информации об оплате; 3) формирование, хранение, удаление информации об проживающих в общежитии.

Система должна: 1) проводить контроль вводимой информации о проживающих; 2) блокировать некорректные действия пользователя при работе с системой; 3) обеспечивать целостность данных; 4) обеспечивать разграничение прав доступа; 5) хранить данные в отдельной базе; 6) быть интуитивно понятной для всех категорий пользователей; 7) ввод данных осуществляется в специально отведенных полях.

Для проектирования СУРПО были построены функциональная модель (IDEF0), описание бизнес-процессов (IDEF3), диаграммы потоков данных (DFD) с использованием AllFusion Process Modeler r7 [1].

В рамках методологии функционального моделирования IDEF0 бизнес-процесс представляется в виде набора функций, которые взаимодействуют между собой, а также показываются информационные, людские и производственные ресурсы, требуемые для каждой функции.

Методология моделирования IDEF3 позволяет графически описать и задокументировать процессы, фокусируя внимание на течении этих процессов и на отношениях процессов и важных объектов, являющихся частями этих процессов.

В данной работе на основе нотации DFD была разработана контекстная диаграмма, которая показывает входные и выходные ресурсы, механизм управления (рисунок 1).

В диаграмме объект «Студент» запрашивает данные у объекта «Формирование расчетов за проживание в общежитии»; входными параметрами являются: «Запрос квитанции за проживание» и «Номер студенческого билета»; выходным параметром является «Квитанция за проживание».

Объект «Формирование расчетов за проживание в общежитии» передает и запрашивает данные у объекта «Сотрудник бухгалтерии», входными параметрами являются: «Данные студенческого билета» и «Запрос текущего счета студента». Выходным параметром от объекта «Сотрудник бухгалтерии» является «Детализация счета студента».

Рисунок 1 – Контекстная диаграмма

Более подробная схема представлена на рисунке 2.

Рисунок 2 – Декомпозиция контекстной диаграммы

Декомпозицию процесса «Формирование расчетов за проживание в общежитии» можно разделить на 3 составляющие: «Проверка на проживание в общежитии», «Проверка счета студента» и «Формирование квитанции».

В блоке «Проверка на проживание в общежитии» входным запросом от объекта «Студент» является «Запрос квитанции за проживание» по номеру студенческого билета. Объект «Проверка на проживание в общежитии» запрашивает в базе данных информацию о студенте (входным запросом является «Запрос данных о студенте»), в ответ получая всю необходимую информацию о студенте. Выходным потоком является «Проверенные данные о студенте». Этот поток передается в следующий блок «Проверка счета студента», который передает параметры и запрос объекту «Сотрудник бухгалтерии». Входными параметрами являются: «Данные студенческого билета» и «Запрос текущего счета студента». Выходным потоком является «Детализация счета студента», он передается объекту «Проверенные данные о студенте». Выходной поток – «Проверенные данные счета студента», он передается непосредственно в блок «Формирование квитанции», который отправляет квитанцию за проживание объекту «Студент».

Детализация процесса «Проверка на проживание в общежитии» изображен на рисунке 3.

Процесс можно разделить на 2 составляющие: «Формирование запроса данных о студенте» и «Проверка данных о студенте». В блок «Формирование запроса данных о студенте» входят потоки «Запрос квитанции за проживание», «Номер студенческого билета» и «Данные о студенте». Выходными потоками является «Запрос данных о студенте» и «Данные о студенте». Поток «Данные о студенте» передается непосредственно в блок «Проверка данных о студенте». От этого блока выходной поток – «Проверенные данные о студенте».

Детализация процесса «Проверка счета студента» представлена на рисунке 4. В блок «Запрос на детализацию счета» входным потоком является «Проверенные данные о студенте» и «Детализация счета студента». Выходными потоками является «Данные студенческого билете», «Запрос текущего счета студента» и «Детализация счета студента».

Рисунок 3 – Проверка на проживание в общежитии

Поток «Детализация счета студента» передается непосредственно в блок «Проверка счета». От этого блока выходной поток – «Проверенные данные счета студента».

Рисунок 4 – Проверка счета студента

Детализация процесса «Формирование квитанции» представлена на рисунке 5.

Рисунок 5 – Формирование квитанции

В блок «Формирование «счет-извещение» входным потоком является «Проверенные данные счета студента», а также этот поток входит в блок «Формирование «счет-квитанция»». Выходящей информацией блока «Формирование «счет-извещение»» является «Счет-извещение», а выходной информацией блока «Формирование «счет-квитанция»» является «Счет-квитанция» которые входят в блок «Формирование квитанции». Из этого блока выходит информация «Квитанция за проживание».

После формирование квитанции пользователь может войти в систему как «Студент» или «Заведующий общежитием», вести свои данные (в случае пользователя «Студент») или данные студента (в случае пользователя «Заведующий общежитием») и провести операцию оплаты за проживание в общежитии.

Неотъемлемой частью СУПРО является база данных. Построение информационной модели предполагает выделение сущностей, их атрибутов и первичных ключей, идентификацию связей между сущностями [2, 3, 4]. Общепринятым видом графического изображения реляционной модели данных является ER-диаграмма, на которой сущности изображаются прямоугольниками, соединенные между собой связями. Такое графическое представление облегчает восприятие структуры базы данных по сравнению с текстовым описанием.

На рисунке 6 представлена логическая-физическая модель для систематизации учета расчетов за проживание в общежитии. Разработанная модель базы данных СУРПО содержит восемь таблиц, каждая из которых хранит определенную информацию. Каждая из таблиц непосредственно связана друг с другом.

Таблица «bill» – это таблица «Учета», которая используется для хранения сводной информации о проживающих в общежитии студентах. Содержит следующие поля: bill_id – номер учетной записи в таблице «bill»; booking_id – связь с таблицей «booking»; total – всего учетной записи в таблице «bill».

Рисунок 6 – Схема БД СУРПО.

Таблица «booking» – это таблица «Записей», которая используется для хранения данных о сроках проживания каждого студента в общежитии. Содержит следующие поля: booking_id – номер учетной записи в таблице «booking»; room_id – связь с таблицей «room»; student_id – связь с таблицей «student»; «from_date» и «to_date» – запись о сроках проживания студента; count_days – запись о проживание в итог; is_active – проверяет присутствие проживающего в общежитии «да или нет».

Таблица «student» – это таблица «Студенты», используется для хранения личных данных о каждом студенте, проживающем в общежитии. Содержит следующие поля: student_id – номер студента в таблице «student»; post_code – почтовый индекс студента, проживающего в общежитии; «patronymic», «last-name», «first_name» – ФИО студента; password – личный пароль студента для входа в систему; home_address – домашние адрес; email_address – почтовый адрес; date_of_bith – дата рождения; phone_num – мобильный номер; photo – фотография.

Таблица «hostel» – это таблица «Общежитие», которая используется для хранения данных об общежитии. Содержит следующие поля: hostel_id – номер общежитии в таблице «hostel»; user_id – связь с таблицей «user»; name – название общежитии; address – адрес; post_codе – почтовый индекс; phone_num – мобильный номер.

Таблица «room» – это таблица «Комнаты», в которой хранятся данные о секциях и комнатах в общежитии. Содержит следующие поля: room_id – номер комнаты в таблице «room»; hostel_id – связь с таблицей «hostel»; roomtype_id – связь с таблицей «roomType».

Таблица «roomType» – это таблица «Секция», которая хранит данные о типе комнат. Содержит следующие поля: roomtype_id – номер секции в таблице «roomType»; room_size – размер комнаты; room_image – изображения комнаты; room_description – описание комнаты; room_price – стоимость помещении; num_of_students – номер студента.

Таблица «user» – это таблица «Пользователь», которая используется для хранения данных о пользователях СУРПО с разграниченными правами доступа. Содержит следующие поля: user_id – номер пользователя в таблице «user»; userType_id – связь с таблицей «userType»; first_name – Имя; last_name – Фамилия; patronymic – Отчество; email_address – почтовый адрес; phone_num – мобильный номер; post_code – почтовый индекс; password – пароль для входа в систему.

Таблица «userType» – это таблица «Тип пользователя», которая используется для определения типа: студент или заведующий. Содержит следующие поля: userType_id – номер типа пользователя в таблице «userType»; status – кто и себя представляет пользователь; is_active – для определения типа пользователя.

Подводя итоги проведенной работы, можно сделать вывод: автоматизированная система учета расчетов за проживание в общежитии дает пользователю быстрый и своевременный доступ к информации об оплате, что позволит избежать накопления долгов, причем контроль происходит как со стороны студента, так и со стороны администрации общежития.

Список литературы:

1. Дубейковский В.И. Эффективное моделирование с Allfusion Process Modeler 4.1.4 и Allfusion PM [Текст] / В.И. Дубейковский. – СПБ.: «ДИАЛОГ-МИФИ», 2007. – 384 с.
2. Дейт К.Дж Основы будущих систем баз данных. Третий манифест [Текст] / Дейт К.Дж, Хью Дарвен. – М.: Янус–К, 2004. – 656 с.
3. Дейт К.Дж. Введение в системы баз данных (седьмое издание) [Текст] / Дейт К.Дж. – М.: Вильямс, 2001. – 1072 с.
4. Дж. Уорсли, К.Дж. Дрейк. PostgreSQL. Для профессионалов. [Текст] / Дж. Уорсли, К.Дж. Дрейк. – СПб.: Питер, 2003. – 260 с.