КурсоваяИнформационные системыГод: 2025РосНОУ: Российский новый университет
👁 8💼 0

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

Загружена: 19.02.2026 10:50

Проект разработки клиент‑серверной информационной системы для турагентства: описаны предметная область, ER/логическая/физическая модели, скрипты создания БД и веб‑интерфейс на Flask. Практическая ценность — готовые SQL‑скрипты, процедуры и отчёты для внедрения.

Содержание

ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
Компания «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. Результаты анализа транзакций

Заключение

В ходе курсовой работы была спроектирована информационная система турагентства. В качестве СУБД использована MySQL, интерфейс спроектирован в виде клиент-серверного веб-приложения. Для разработки был использован язык программирования Python и фреймворк Flask.
Проектируемая система призвана обеспечивать автоматизацию процессов бронирования туров.
Разработанная система призвана обеспечить полную автоматизацию ключевых процессов бронирования туров, включая размещение заказов, отслеживание платежей, формирование отчетов и управление базой данных клиентов. Внедрение такой системы позволит повысить эффективность работы турагентства, сократить количество ошибок, связанных с ручной обработкой данных, а также повысить общее качество обслуживания клиентов.
Благодаря модульной архитектуре и использованию современных технологий система имеет потенциал для дальнейшего масштабирования и добавления новых функций, таких как интеграция с системами онлайн-платежей, мобильным приложением и рекомендательным движком.

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

Раннев, Г.Г. Измерительные информационные системы. Учебник для студентов высших учебных заведений. Гриф УМО МО РФ / Г.Г. Раннев. - М.: Академия (Academia), 2021. - 493 c.
Анашкина, Н.В. Технологии и методы программирования: Учебное пособие для студентов учреждений высшего профессионального образования / Н.В. Анашкина, Н.Н. Петухова, В.Ю. Смольянинов. - М.: ИЦ Академия, 2021. - 384 c.
Балдин, К.В. Информационные системы в экономике: Учебник / К.В. Балдин, В.Б. Уткин. - М.: Дашков и К, 2020. - 395 c.
Бодров, О.А. Предметно-ориентированные экономические информационные системы: Учебник для вузов / О.А. Бодров. - М.: Гор. линия-Телеком, 2019. - 244 c.
Варфоломеева, А.О. Информационные системы предприятия: Учебное пособие / А.О. Варфоломеева, А.В. Коряковский, В.П. Романов. - М.: НИЦ ИНФРА-М, 2020. - 283 c.
ПРИЛОЖЕНИЯ
Скрипт генерации базы данных
-- Таблица стран
CREATE TABLE countries (
country_id INT AUTO_INCREMENT PRIMARY KEY,
country_name VARCHAR(100) NOT NULL UNIQUE,
description TEXT
);
-- Таблица отелей
CREATE TABLE hotels (
hotel_id INT AUTO_INCREMENT PRIMARY KEY,
hotel_name VARCHAR(150) NOT NULL,
country_id INT,
address VARCHAR(255),
stars INT CHECK (stars BETWEEN 1 AND 5),
description TEXT,
FOREIGN KEY (country_id) REFERENCES countries(country_id) ON DELETE SET NULL
);
-- Таблица клиентов
CREATE TABLE clients (
client_id INT AUTO_INCREMENT PRIMARY KEY,
first_name VARCHAR(50) NOT NULL,
last_name VARCHAR(50) NOT NULL,
email VARCHAR(100) UNIQUE,
phone VARCHAR(20),
birth_date DATE,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
-- Таблица сотрудников
CREATE TABLE employees (
employee_id INT AUTO_INCREMENT PRIMARY KEY,
first_name VARCHAR(50) NOT NULL,
last_name VARCHAR(50) NOT NULL,
position VARCHAR(100),
salary DECIMAL(10,2),
hire_date DATE,
phone VARCHAR(20)
);
-- Таблица туров
CREATE TABLE tours (
tour_id INT AUTO_INCREMENT PRIMARY KEY,
tour_name VARCHAR(150) NOT NULL,
country_id INT,
hotel_id INT,
start_date DATE,
end_date DATE,
price DECIMAL(10,2),
description TEXT,
available_seats INT DEFAULT 0,
FOREIGN KEY (country_id) REFERENCES countries(country_id) ON DELETE SET NULL,
FOREIGN KEY (hotel_id) REFERENCES hotels(hotel_id) ON DELETE SET NULL
);
-- Таблица заказов
CREATE TABLE orders (
order_id INT AUTO_INCREMENT PRIMARY KEY,
client_id INT,
employee_id INT,
order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
status ENUM('ожидает оплаты', 'оплачен', 'отменён') DEFAULT 'ожидает оплаты',
total_price DECIMAL(10,2),
FOREIGN KEY (client_id) REFERENCES clients(client_id) ON DELETE CASCADE,
FOREIGN KEY (employee_id) REFERENCES employees(employee_id) ON DELETE SET NULL
);
-- Таблица деталей заказа (многие ко многим: заказ может содержать несколько туров)
CREATE TABLE order_details (
order_detail_id INT AUTO_INCREMENT PRIMARY KEY,
order_id INT,
tour_id INT,
quantity INT DEFAULT 1,
price_per_unit DECIMAL(10,2),
FOREIGN KEY (order_id) REFERENCES orders(order_id) ON DELETE CASCADE,
FOREIGN KEY (tour_id) REFERENCES tours(tour_id) ON DELETE CASCADE
);
-- Таблица платежей
CREATE TABLE payments (
payment_id INT AUTO_INCREMENT PRIMARY KEY,
order_id INT,
amount DECIMAL(10,2),
payment_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
payment_method VARCHAR(50),
status ENUM('успешно', 'в обработке', 'отклонено') DEFAULT 'в обработке',
FOREIGN KEY (order_id) REFERENCES orders(order_id) ON DELETE CASCADE
);
Код программы
app.py
from flask import Flask, render_template, request, redirect, url_for
import mysql.connector
app = Flask(__name__)
# Database connection configuration
db_config = {
'host': 'localhost',
'user': 'root',
'password': 'root',
'database': 'travel agency'
}
# Connect to the database
def get_db_connection():
return mysql.connector.connect(**db_config)
# Home page: List all tables in the database
@app.route('/')
def index():
connection = get_db_connection()
cursor = connection.cursor()
cursor.execute("SHOW TABLES")
tables = [table[0] for table in cursor.fetchall()]
connection.close()
return render_template('index.html', tables=tables)
# Table content page: Display rows of a selected table
@app.route('/table/<table_name>', methods=['GET', 'POST'])
def table(table_name):
connection = get_db_connection()
cursor = connection.cursor()
# Get column names
cursor.execute(f"DESCRIBE `{table_name}`")
columns = [column[0] for column in cursor.fetchall()]
if request.method == 'POST':
# Handle adding new row
values = [request.form.get(col) for col in columns]
placeholders = ', '.join(['%s'] * len(values))
columns_str = ', '.join([f"`{col}`" for col in columns])
query = f"INSERT INTO `{table_name}` ({columns_str}) VALUES ({placeholders})"
cursor.execute(query, values)
connection.commit()
return redirect(url_for('table', table_name=table_name))
# Get all rows from the table
cursor.execute(f"SELECT * FROM `{table_name}`")
rows = cursor.fetchall()
connection.close()
return render_template('table.html', table_name=table_name, columns=columns, rows=rows)
# Edit a row
@app.route('/edit/<table_name>/<int:row_id>', methods=['GET', 'POST'])
def edit_row(table_name, row_id):
connection = get_db_connection()
cursor = connection.cursor()
# Get column names
cursor.execute(f"DESCRIBE `{table_name}`")
columns = [column[0] for column in cursor.fetchall()]
primary_key = columns[0]  # Assuming first column is the primary key
if request.method == 'POST':
updates = ', '.join([f"`{col}` = %s" for col in columns if col != primary_key])
values = [request.form[col] for col in columns if col != primary_key]
values.append(row_id)
query = f"UPDATE `{table_name}` SET {updates} WHERE `{primary_key}` = %s"
cursor.execute(query, values)
connection.commit()
return redirect(url_for('table', table_name=table_name))
# Fetch current data
cursor.execute(f"SELECT * FROM `{table_name}` WHERE `{primary_key}` = %s", (row_id,))
row_data = cursor.fetchone()
connection.close()
return render_template('edit.html', table_name=table_name, columns=columns, row=row_data)
# Delete a row
@app.route('/delete/<table_name>/<int:row_id>')
def delete_row(table_name, row_id):
connection = get_db_connection()
cursor = connection.cursor()
primary_key = None
# Find primary key
cursor.execute(f"DESCRIBE `{table_name}`")
for col in cursor.fetchall():
if 'PRI' in col:
primary_key = col[0]
break
if primary_key:
cursor.execute(f"DELETE FROM `{table_name}` WHERE `{primary_key}` = %s", (row_id,))
connection.commit()
connection.close()
return redirect(url_for('table', table_name=table_name))
# Report page: Generate reports
@app.route('/report', methods=['GET', 'POST'])
def report():
columns = []
rows = []
if request.method == 'POST':
report_type = request.form['report_type']
connection = get_db_connection()
cursor = connection.cursor()
if report_type == 'unfinished_orders':
cursor.execute("""
SELECT
CONCAT(clients.first_name, ' ', clients.last_name) AS client_name,
tours.tour_name AS tour_name,
orders.order_date AS order_date,
orders.status AS status
FROM orders
JOIN clients ON orders.client_id = clients.client_id
JOIN order_details ON orders.order_id = order_details.order_id
JOIN tours ON order_details.tour_id = tours.tour_id
WHERE orders.status = 'ожидает оплаты'
""")
rows = cursor.fetchall()
columns = ['ФИО', 'Тур', 'Дата заказа', 'Статус']
elif report_type == 'clients':
cursor.execute("""
SELECT
clients.first_name,
clients.last_name,
clients.email,
clients.phone,
clients.birth_date
FROM clients
""")
rows = cursor.fetchall()
columns = ['Имя', 'Фамилия', 'Email', 'Телефон', 'Дата рождения']
connection.close()
return render_template('report.html', columns=columns, rows=rows)
if __name__ == '__main__':
app.run(debug=True)

Подробное описание

📘 О чем эта работа

Курсовой проект посвящён проектированию информационной системы бронирования турагентства Good Journey Travel Agency. В работе описаны предметная область и бизнес‑процессы (подбор тура, оформление заказов, организация проживания, обработка платежей), разработаны концептуальная, логическая и физическая модели данных, а также реализован прототип веб‑интерфейса на Flask и набор SQL‑скриптов для MySQL.

📚 Что внутри

Документ содержит полный набор проектных артефактов и реализаций:

  • Концептуальная ER‑модель с сущностями: Country, Hotel, Tour, Client, Employee, Order, Payment.
  • Логическая модель с таблицей пересечения order_details для связи «многие‑ко‑многим» между заказами и турами.
  • Физическая модель и полный SQL‑скрипт создания БД: таблицы countries, hotels, clients, employees, tours, orders, order_details, payments с ограничениями и внешними ключами.
  • Реализация транзакций в MySQL: хранимые процедуры и представления, включая GetToursByCountry, GetToursByPriceRange, GetToursByDateRange, GetOrdersByPeriod, AddNewClient, UpdateClientInfo, AddNewTour, RecordPayment и представления ClientInfo, PendingOrders.
  • Скрипты примеров выполнения процедур и результаты (скриншоты/лог выполнения) и фрагменты кода генерации БД.
  • Веб‑интерфейс на Python/Flask: исходный код app.py с подключением к базе, CRUD для всех таблиц, страницы /table/ и /report (отчёты: незавершённые заказы, список клиентов). Примеры URL: http://127.0.0.1:5000 и /report.
  • Анализ транзакций и требований: ожидаемые объёмы (примерно 500 клиентов, ~100 туров, >1000 заказов в год), частоты вызовов транзакций и рекомендации по индексированию/оптимизации.
  • Документация по пользовательским интерфейсам: формы добавления/редактирования/удаления записей, отчёты и примеры использования.

📊 Для кого подходит

Работа полезна студентам IT‑ и прикладных направлений (информационные системы, программистам начального уровня), преподавателям для проверки, а также разработчикам, которым нужен шаблон системы бронирования с MySQL и Flask для быстрого прототипа.

✨ Особенности

В проекте собраны практические артефакты: готовый SQL‑скрипт создания БД с внешними ключами, набор хранимых процедур для типичных операций (поиск туров по стране/цене/датам), реализованный CRUD‑веб‑интерфейс на Flask с формами и страницей отчётов, а также анализ транзакционной нагрузки и рекомендации по оптимизации. Есть конкретные имена процедур и примеры запросов, что облегчает прямое внедрение или адаптацию.

❓ Частые вопросы

Подойдет ли для моего ВУЗа?
Структура соответствует стандартным требованиям курсовой: введение, главы (описание предметной области, проектирование БД, интерфейсы), заключение, список литературы и приложения с кодом.

Можно адаптировать?
Да. SQL‑скрипты и Flask‑код написаны модульно: достаточно скорректировать схему, права доступа и настройки подключения (в app.py в db_config) для адаптации под конкретные требования.

Контакты реализации и интеграции

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