Курсовая: Проект ИС турагентства на MySQL и Flask

ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
Компания «Good Journey Travel Agency» предлагает широкий спектр услуг, связанных с путешествиями, включая бронирование туров, бронирование отелей, туристические пакеты для конкретных стран и индивидуальное планирование путешествий. Основные бизнес-процессы включают [1]:
Получение запросов от клиентов: клиенты могут связаться с агентством через веб-сайт, мобильное приложение или по телефону, чтобы забронировать туры или запросить информацию.
Подбор тура: менеджеры подбирают подходящие туры для клиентов на основе их предпочтений, таких как место назначения, продолжительность, бюджет и тип отдыха.
Обработка заказов: после выбора тура клиент переходит к оформлению заказа и подписанию договора на обслуживание, в котором излагаются условия поездки.
Организация проживания в отеле: система помогает в выборе и подтверждении размещения в отеле, включенного в тур.
Обработка платежей: клиенты оплачивают услуги с помощью онлайн-платежей или других доступных вариантов.
Отслеживание заказов: сотрудники отслеживают статус каждого заказа от бронирования до завершения.
Управление взаимоотношениями с клиентами: система ведет подробные профили клиентов и историю бронирований для предоставления лучшего обслуживания, и персонализации будущих предложений.
Маркетинг и продвижение: Агентство активно продвигает свои услуги через различные каналы, такие как социальные сети, кампании по электронной почте и онлайн-реклама.
Финансовый учет и анализ: Система отслеживает все финансовые транзакции, генерирует отчеты и поддерживает принятие решений на основе данных.
Развитие и инновации: Компания постоянно совершенствует свои предложения, анализируя отзывы клиентов и внедряя новые типы туров и цифровые инструменты.
Внедрение системы баз данных для управления бронированием туров принесет несколько преимуществ:
Повышенная операционная эффективность [2]: Автоматизация ключевых процессов, таких как проверка доступности туров, управление клиентами и отслеживание платежей, значительно сократит ручную работу и сведет к минимуму ошибки.
Увеличение дохода: Улучшенный пользовательский опыт, более быстрое время обработки и лучшие маркетинговые стратегии помогут привлечь больше клиентов и увеличить продажи.
Гибкая и масштабируемая система: База данных будет поддерживать масштабируемость, что позволит компании легко расширять свою деятельность и добавлять новые функции по мере необходимости [3].
Разработанная система должна обеспечивать полную автоматизацию процессов бронирования и управления турами.
Функциональные требования к информационной системе включают:
Создание и редактирование данных о клиентах, турах, странах, отелях и заказах.
Ведение истории всех бронирований и взаимодействий с клиентами.
Формирование отчетов по заказам, платежам, популярным направлениям и эффективности работы сотрудников.
Управление клиентской базой данных, включая добавление новых клиентов, обновление персональных данных и назначение статусов лояльности.
Настройка прав доступа для различных категорий пользователей (например, администраторов, менеджеров, клиентов).
Пользовательский интерфейс должен быть реализован как веб-приложение, состоящее из набора веб-страниц, позволяющих пользователям эффективно выполнять поставленные задачи.
Интерфейс системы должен быть удобным для пользователя, интуитивно понятным и простым в навигации, обеспечивая доступность как для сотрудников, так и для клиентов.
Система должна обеспечивать защиту от несанкционированного доступа к конфиденциальным данным, включая информацию о клиентах, финансовые записи и внутренние операции. Она должна поддерживать безопасную аутентификацию и управление доступом на основе ролей.
Информационная система должна иметь возможность интеграции с официальным сайтом компании, что позволит осуществлять онлайн-бронирование туров и проверку наличия мест в режиме реального времени. Кроме того, она может поддерживать интеграцию со сторонними сервисами, такими как платежные шлюзы и системы бронирования отелей.
Система будет разработана как клиент-серверное приложение с использованием реляционной базы данных (MySQL) и с использованием объектно-ориентированного подхода при разработке программного обеспечения для обеспечения модульности, возможности повторного использования и удобства обслуживания.
ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ
Этап концептуального проектирования
Фаза концептуального проектирования является начальным этапом разработки базы данных, в ходе которого создается общая модель данных, которая полностью независима от любых технических деталей реализации. На этом этапе определяются основные сущности и их связи на основе предметной области.
Для домена информационной системы туристического агентства были определены следующие ключевые сущности:
Страна — описывает страны, в которых предлагаются туры.
Отель — представляет отели, включенные в различные туры.
Тур — описывает туристические пакеты, доступные для бронирования.
Клиент — содержит информацию о клиентах, которые бронируют туры.
Сотрудник — представляет сотрудников, работающих в туристическом агентстве.
Заказ — регистрирует бронирования, сделанные клиентами.
Оплата — отслеживает платежные транзакции, связанные с заказами.
Концептуальная модель графически представлена ​​на рисунке 1 в виде ER-диаграммы.
Рисунок 1 – Концептуальная ER-модель базы данных
Как видно из диаграммы, многие сущности связаны через отношения «многие ко многим», которые будут преобразованы в отдельные таблицы на этапе логического проектирования для соответствия реляционной модели данных.
Этап логического проектирования
Следующим этапом в процессе проектирования базы данных является фаза логического проектирования, которая преобразует концептуальную модель в структуру, отражающую особенности выбранной модели данных (в данном случае реляционной модели). В ходе логического проектирования создаются схемы отношений, определяются первичные и внешние ключи и формируется общая логическая структура базы данных.
Логическая модель базы данных представлена ​​на рисунке 2. Следует отметить, что сущности в логической модели в значительной степени соответствуют тем, которые были определены в ранее разработанной концептуальной модели. Для реализации отношений «многие ко многим» была создана таблица пересечений «OrderDetails», которая представляет отдельные бронирования туров в каждом заказе.
Кроме того, было введено несколько справочных таблиц:
Страны — описание стран, в которых предлагаются туры;
Отели — содержат информацию об отелях, включенных в различные туры;
Эти таблицы поддерживают нормализацию и помогают поддерживать целостность данных во всей системе.
Эта логическая структура обеспечивает гибкость и масштабируемость, точно отражая реальные бизнес-процессы в туристическом агентстве.
Рисунок 2 – Логическая ER-модель базы данных
Этап физического проектирования
Заключительным этапом процесса проектирования базы данных является фаза физического проектирования, которая фокусируется на создании конкретной реализации базы данных в выбранной системе управления базами данных (СУБД). На этом этапе рассматриваются технические особенности системы, включая методы хранения данных, создание индексов и методы оптимизации доступа.
Для реализации базы данных была выбрана СУБД MySQL из-за ее широкого использования, надежности и надежного набора функций, что делает ее идеальным выбором для современных информационных систем на основе веб-технологий.
В физической модели данных, показанной на рисунке 3, каждому атрибуту были назначены соответствующие совместимые с MySQL типы данных. Кроме того, имена таблиц и столбцов были переведены на английский язык для обеспечения лучшей совместимости с языками программирования при последующей разработке интерфейса информационной системы.
Рисунок 3 - Физическая ER-модель базы данных
После этой модели следующим шагом является написание скрипта для генерации таблиц базы данных в соответствии с разработанной физической структурой. Чтобы гарантировать, что скрипт может быть выполнен несколько раз без ошибок, первым выполняемым действием является проверка существования таблиц и их удаление при необходимости, как показано на рисунке 4.
После этого все требуемые таблицы создаются с использованием соответствующих операторов CREATE, что гарантирует правильную инициализацию структуры базы данных.
Рисунок 4 - Фрагмент скрипта создания базы данных
Полный листинг скрипта создания базы данных приведен в приложении к пояснительной записке.
ПРОЕКТИРОВАНИЕ ПОЛЬЗОВАТЕЛЬСКИХ ИНТЕРФЕЙСОВ
Список требуемых транзакций
Основные операции, выполняемые менеджером туристического агентства, включают:
Получение списка доступных туров в определенной стране — позволяет фильтровать туры по месту назначения.
Получение списка туров в указанном ценовом диапазоне — помогает клиентам и менеджерам находить туры, соответствующие определенному бюджету.
Получение списка туров, отправляющихся в определенный диапазон дат, — поддерживает планирование и бронирование поездок на определенные периоды.
Получение списка отелей, расположенных в определенной стране, — предоставляет дополнительную информацию о вариантах размещения.
Получение списка клиентов, которые сделали бронирования, — помогает управлять отношениями с клиентами и коммуникацией.
Получение списка заказов (бронирований), размещенных в течение определенного периода, — помогает в создании отчетов и анализе тенденций продаж.
Получение списка ожидающих или неоплаченных заказов — позволяет отслеживать платежи и следить за клиентами.
Обновление статуса заказа — позволяет сотрудникам изменять статус бронирования (например, с «ожидает» на «оплачен»). Добавление нового тура в базу данных — позволяет администраторам расширить каталог доступных туров.
Создание отчета по самым популярным турам — дает представление о спросе и помогает в принятии маркетинговых решений.
Эти транзакции необходимы для повседневной работы, обеспечивая эффективное управление турами, клиентами и заказами, а также поддерживая принятие решений на основе данных в информационной системе туристического агентства.
Анализ транзакций на этапе логического проектирования
Чтобы получить список туров, доступных в определенной стране, необходимо выполнить запрос к таблице Tours с условием, что country_id соответствует указанному параметру. Результат должен включать такие поля, как tour_name, start_date, end_date, price и description. Чтобы отобразить название страны вместо ее идентификатора, необходимо выполнить соединение между таблицами Tours и Countries с использованием внешнего ключа country_id.
Чтобы получить список туров в указанном ценовом диапазоне, необходимо выполнить запрос к таблице Tours с фильтром, примененным к полю price — больше или равно минимальному значению и меньше или равно максимальному значению. Выходные данные должны включать tour_name, country_id, start_date, end_date и price. Опять же, соединение с таблицей Countries позволяет отображать полное название страны для ясности.
Чтобы получить список туров, отправляющихся в определенный диапазон дат, необходимо выполнить запрос к таблице Tours, отфильтровав ее по полю start_date. Условие должно указывать, что start_date больше или равно началу периода и меньше или равно концу периода. Результат должен включать tour_name, start_date, end_date, price и связанную информацию об отеле. Объединение с таблицей Hotels через hotel_id позволяет извлекать сведения о размещении, включенном в тур.
Чтобы получить список отелей, расположенных в определенной стране, необходимо выполнить запрос к таблице Hotels с условием, что country_id соответствует предоставленному значению. Результат должен включать hotel_name, address, stars и description. Объединение с таблицей Countries гарантирует, что вместо идентификатора может отображаться название страны.
Чтобы получить список клиентов, которые сделали бронирования, запрос должен выбрать такие поля, как first_name, last_name, email и phone из таблицы Clients. Кроме того, данные из таблицы Orders должны быть объединены с использованием внешнего ключа client_id, чтобы гарантировать включение только клиентов с подтвержденными бронированиями.
Чтобы получить список заказов (бронирований), размещенных в течение определенного периода, записи из таблицы Orders должны быть отфильтрованы на основе поля order_date. Условие должно проверять, что order_date попадает между двумя указанными датами. Этот запрос также должен включать информацию о клиенте, объединяясь с таблицей Clients через client_id, и сведения о туре, объединяясь с таблицами OrderDetails и Tours. Вывод должен включать имя клиента, название тура, дату заказа и общую стоимость.
Чтобы получить список ожидающих или неоплаченных заказов, необходимо выполнить запрос к таблице Orders, отфильтровав по полю статуса, установленному на «ожидает оплаты» (или эквивалент). Этот запрос также должен быть объединен с таблицами Clients и Tours, чтобы предоставить подробную информацию о каждом заказе, включая имя клиента и название тура.
Чтобы обновить статус заказа, необходимо использовать оператор UPDATE в таблице Orders, указав столбец статуса на основе order_id. Эта операция должна сопровождаться логикой проверки, чтобы гарантировать, что только авторизованные пользователи могут выполнять это действие, и что переходы между статусами следуют определенным бизнес-правилам.
Чтобы добавить новый тур в базу данных, необходимо выполнить оператор INSERT в таблице Tours, заполнив такие поля, как tour_name, country_id, hotel_id, start_date, end_date, price, description и available_seats. Ограничения внешнего ключа должны обеспечивать ссылочную целостность с таблицами Countries и Hotels.
Наконец, чтобы создать отчет о самых популярных турах, запрос должен агрегировать данные из таблицы OrderDetails, подсчитывая, сколько раз был забронирован каждый тур. Этот запрос должен быть объединен с таблицей Tours, чтобы отобразить названия туров и использовать группировку и упорядочение, чтобы сначала представить наиболее забронированные туры.
Эти описания транзакций формируют основу для реализации запросов и операций на этапе физического проектирования и служат справочным материалом для разработки прикладного уровня информационной системы туристического агентства.
Документация на пользовательские интерфейсы
Интерфейс пользователя включает набор веб-страниц, с помощью которых пользователь может просматривать данные из таблиц базы данных, добавлять новые записи, изменять существующие и удалять ненужные. Также интерфейс обеспечивает отображение отчетов по различным категориям, что позволяет эффективно управлять информацией о клиентах, турах, заказах и платежах.
Информационная система должна удовлетворять следующим функциональным требованиям:
Пользователь должен иметь возможность просмотра списка таблиц базы данных;
Пользователь должен иметь возможность просмотра содержимого заданной таблицы БД;
Интерфейс должен предоставлять возможность добавления новых записей в таблицу;
Интерфейс должен предоставлять возможность изменения данных в выбранной записи;
Интерфейс должен предоставлять возможность удаления заданной записи из таблицы;
Информационная система должна предоставлять возможность формировать отчет об активных заказах (заказах, статус которых «ожидает оплаты»);
Информационная система должна предоставлять возможность формировать отчет о клиентах агентства.
Интерфейс информационной системы разработан с использованием языка программирования Python и веб-фреймворка Flask. Для реализации базы данных использовалась СУБД MySQL.
После запуска информационной системы пользователь должен перейти в веб-браузере по адресу http://127.0.0.1:5000, чтобы попасть на главную страницу.
Рисунок 5 - Отображение списка таблиц базы данных
При нажатии на кнопку с названием определенной таблицы БД пользователь переходит на страницу просмотра записей этой таблицы. Записи отображаются в табличном виде, где последний столбец каждой строки содержит кнопки «Изменить» и «Удалить», позволяющие редактировать или удалять соответствующую запись.
Внизу таблицы расположена форма добавления новой записи, которая повторяет структуру полей таблицы. После заполнения формы и нажатия кнопки «Добавить» в базу данных будет добавлена новая запись.
В качестве примера добавим тестовую запись в таблицу hotels (рисунок 6).
Рисунок 6 – Добавление тестовых записей в таблицу hotels
Продемонстрируем удаление записи из таблицы clients, например, записи с client_id = 7 (Иван Иванов). Для этого в соответствующей строке нажмем кнопку «Удалить». Страница автоматически обновится, и удаленная запись исчезнет из таблицы (рисунок 7).
Рисунок 7 – Удаление тестовой записи из таблицы clients
Для перехода к отчетам следует в адресной строке браузера ввести http://127.0.0.1:5000/report. Страница отчетов содержит выпадающий список, в котором можно выбрать нужный отчет и нажать кнопку «Показать». После этого в таблице ниже отобразится содержимое выбранного отчета.
На рисунке 8 показан отчет о незавершенных заказах.
Рисунок 8 – Отчет о незавершённых заказах
Отчет о клиентах показан на рисунке 9.
Рисунок 9 – Отчет о клиентах
Таким образом, все заявленные функциональные требования выполнены. Разработанный пользовательский интерфейс позволяет эффективно управлять данными, добавлять, редактировать и удалять записи, а также формировать отчеты для анализа деятельности турагентства.
Реализация транзакций средствами выбранной СУБД
Описание реализованных в СУБД транзакций представлено в таблице
Таблица 1. Описание реализованных в СУБД MySQL транзакций
Далее покажем исходный код скриптов для организации каждой из транзакций и результат их выполнения в СУБД MySQL.
Скрипт и результат выполнения процедуры GetToursByCountry показаны на рисунках 10 и 11.
Рисунок 10 - Скрипт создания процедуры GetToursByCountry
Рисунок 11 - Результат выполнения процедуры GetToursByCountry
Скрипт и результат выполнения процедуры GetToursByPriceRange показаны на рисунках 12 и 13.
Рисунок 12 - Скрипт создания процедуры GetToursByPriceRange
Рисунок 13 - Результат выполнения процедуры GetToursByPriceRange
Скрипт и результат выполнения процедуры GetToursByDateRange показаны на рисунках 14 и 15.
Рисунок 14 - Скрипт создания процедуры GetToursByDateRange
Рисунок 15 - Результат выполнения процедуры GetToursByDateRange
Скрипт и результат выполнения представления ClientInfo показаны на рисунках 16 и 17.
Рисунок 16 - Скрипт создания представления ClientInfo
Рисунок 17 - Результат вызова представления ClientInfo
Скрипт и результат выполнения процедуры GetOrdersByPeriod показаны на рисунках 18 и 19.
Рисунок 18 - Скрипт создания процедуры GetOrdersByPeriod
Рисунок 19 - Результат выполнения процедуры GetOrdersByPeriod
Скрипт и результат выполнения процедуры PendingOrders показаны на рисунках 20 и 21.
Рисунок 20 - Скрипт создания представления PendingOrders
Рисунок 21 - Результат выполнения представления PendingOrders
Скрипт и результат выполнения процедуры AddNewClient показаны на рисунках 22 и 23.
Рисунок 22 - Скрипт создания процедуры AddNewClient
Рисунок 23 - Результат выполнения процедуры AddNewClient
Скрипт и результат выполнения процедуры UpdateClientInfo показаны на рисунках 24 и 25.
Рисунок 24 - Скрипт создания процедуры UpdateClientInfo
Рисунок 25 - Результат выполнения процедуры UpdateClientInfo
Скрипт и результат выполнения процедуры AddNewTour показаны на рисунках 26 и 27.
Рисунок 26 - Скрипт создания процедуры AddNewTour
Рисунок 27 - Результат выполнения процедуры AddNewTour
Скрипт и результат выполнения процедуры RecordPayment показаны на рисунках 28 и 29.
Рисунок 28 - Скрипт создания процедуры RecordPayment
Рисунок 29 - Результат выполнения процедуры RecordPayment
Анализ транзакций на этапе физического проектирования
Целью этого анализа является определение функциональных характеристик транзакций, которые будут выполняться в базе данных, и выявление наиболее важных из них. Чтобы гарантировать, что разработанный физический дизайн базы данных соответствует требуемому уровню производительности, необходимо собрать как можно больше информации о транзакциях, которые будут выполняться. Для каждой транзакции требуются как качественные, так и количественные характеристики:
Ожидаемая частота выполнения;
Связи и атрибуты, к которым обращается транзакция, а также тип доступа (R – извлечение, I – вставка);
Ограничения на приемлемое время выполнения.
Во многих случаях нецелесообразно анализировать все транзакции, поэтому мы должны сосредоточиться только на самых «важных». Возвращаясь к диаграмме, используемой на этапе логического проектирования (см. рисунок 3.1), нам необходимо определить, к каким связям наиболее интенсивно осуществляется доступ во время выполнения транзакции. Для этого мы вычисляем количество входящих стрелок для каждой сущности.
Таблица 2. Количество входящих стрелок на сущность
Поскольку в этом примере было проанализировано лишь небольшое количество транзакций, количество входящих стрелок для каждой сущности относительно схоже. Однако в реальных сценариях 2–3 сущности обычно имеют значительно больше входящих стрелок, чем другие. На этапе физического проектирования имеет смысл сосредоточиться только на тех транзакциях, которые обращаются к отношениям с большим количеством входящих стрелок. В нашем случае это таблицы Client, Tour и особенно Order, через которые проходят все заявленные транзакции.
Далее мы оцениваем ожидаемое количество строк в каждом отношении, а также среднюю и максимальную кардинальность. Например, мы ожидаем около 500 клиентов, до 100 туров и более 1000 заказов в год.
При анализе каждой транзакции важно не только знать среднее и максимальное количество вызовов в час, но и понимать, в какие дни недели и время суток транзакция обычно выполняется, включая периоды пиковой нагрузки. Например, некоторые транзакции могут оставаться на постоянном уровне в течение дня, но показывать явный всплеск в конце месяца из-за подготовки отчета. Другие транзакции могут выполняться только по будням с 9:00 до 18:00.
Когда потоки транзакций требуют частого доступа к определенным отношениям, выбранные стратегии доступа становятся весьма значимыми. Если эти транзакции независимы, риск проблем с производительностью снижается. Однако, если их планы выполнения конфликтуют, потенциальные проблемы можно частично решить, тщательно проанализировав транзакции и найдя способы их изменения для повышения производительности. В нашем случае мы должны сосредоточиться на транзакциях, включающих таблицы Client, Tour и особенно Order.
Результаты анализа представлены в таблице 3.
Таблица 3. Результаты анализа транзакцийПоказать/скрыть дополнительное описание