2. Обоснование модели данных
В данной работе будет использоваться реляционная модель базы данных. Обусловлено данное решение несколькими причинами: представление списка всех доступных путевок в табличном виде является наиболее наглядным; данные должны быть целостными, чтобы СУБД запрещала проведение ошибочных операций (например, добавление путевки с несуществующим местом, отрицательная стоимость путевки); в распоряжении пользователя имеются возможности поиска и фильтрации требуемой информации. Все эти требования делают необходимым выбор именно реляционной модели базы данных.
3. Обоснование выбора субд
Для построения базы данных будет использоваться одна из наиболее популярных реляционных СУБД PostgreSQL.
Ключевых характеристики данной СУБД:
Поддержка большого количества структур и типов данных;
Высокий уровень надежности и безопасности: СУБД отвечает требованиям ACID (атомарность, согласованность, изолированность и надежность);
СУБД может обрабатывать большие объемы данных: к примеру, максимальный размер таблицы – 32 терабайта, строки – 1,6 терабайт, отсутствует ограничение на размер БД и количество строк;
Быстродействие операций манипулирования с большим числом данных в сравнении с MySQL: при добавлении скорость быстрее в 3,46 раза, при внутреннем объединении в 1,66 раз, при выборке в 1,97 раз;
Базовая версия программы распространяется бесплатно;
Большое количество расширений, в том числе и бесплатных.
4. Описание функций групп пользвателей
Таблица 1 – Назначение прав пользователей
-
Объект
Клиент
Администратор БД
Таблица путевок
S
SUID
Таблица клиентов
SUID*
SUID
Таблица городов
S
SUID
Таблица стран
S
SUID
Таблица заказов
SID*
SUID
Таблица отелей
S
SUID
Таблица видов номера отелей
S
SUID
*Пользователь может взаимодействовать только с той информацией из таблиц заказов и клиентов, которая связана непосредственно с ним.
5. Описание функций управления данными
Данные хранятся в виде семи таблиц, указанных в таблице в прошлом разделе.
Рисунок 1 – Логическая модель данных
Манипулирование данными реализовано с помощью запросов и функций:
добавление, изменение, удаление осуществляется администратором с помощью стандартных операций: insert, update, drop; взаимодействие пользователя с БД осуществляется в основном с помощью созданных функций. Бронирование путевки: на вход функции подается id путевки, логин пользователя, выбранный тип номера в отеле; происходит расчет итоговой стоимости путевки и запись данных о бронировании в таблице «Заказы». При успешном добавлении выполняется триггер, вызывающий функцию, уменьшающую количество доступных путевок на один в таблице «Путевки» для забронированной путевки. Расчет стоимости путевки: входными параметрами являются id путевки и номер отеля, итоговая стоимость равна стоимости путевки без учета проживания плюс стоимость номера, умноженная на длительность тура. Формирование списка путевок по полярности происходит следующим образом: в таблице «Заказы» подсчитывается, сколько раз путевка была забронирована, затем соответствующие путевки выводятся в порядке убыванию этого числа.
Доступ к данным: администратор БД имеет доступ ко всей системе. Пользователь имеет возможность добавлять в таблицу «Клиенты» данные. Обновлять, удалять и получать он может только те строки, в которых указана информация о нем. С таблицей «Заказы» клиенту доступны следующие операции: добавление путевки (бронирование), удаление собственного заказа, получение информации о созданной брони. Пользователь может видеть всю информацию в следующих таблицах: «Страны», «Отели», «Отели_тип_номера», «Города», «Путевки».
Предоставление запрашиваемой информации пользователю: поиск путевок по виду, стоимости, месту реализованы по одной схеме: на вход – требуемый параметр, на выходе – список путевок, удовлетворяющих заданному условию. Функция вывода списка путевок по убыванию популярности не имеет входных параметров.