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

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

Целью настоящей работы является проектирование и реализация полнофункциональной базы данных для агентства пассажирских перевозок, способной обеспечить эффективный учёт, хранение и обработку информации, а также автоматизировать ключевые операционные процессы. Для достижения этой цели были поставлены следующие задачи: исследовать теоретические основы реляционных баз данных и систем управления базами данных (СУБД); проанализировать и выбрать оптимальные методологии проектирования; разработать концептуальную, логическую и физическую модели данных, учитывающие специфику предметной области; реализовать спроектированную базу данных с использованием выбранной СУБД; продемонстрировать возможности автоматизации процессов учёта и отчётности; а также обеспечить механизмы целостности, безопасности и оптимизации производительности. Объектом исследования является информационная система агентства пассажирских перевозок, а предметом — процесс проектирования и реализации реляционной базы данных для данной предметной области. В работе использованы методы системного анализа, моделирования данных (ER-моделирование, IDEF1X), структурного программирования и объектно-реляционного подхода. Структура дипломной работы последовательно ведёт читателя от фундаментальных теоретических концепций к практической реализации и обсуждению эксплуатационных аспектов, завершаясь выводами и перспективами развития.

Теоретические основы проектирования реляционных баз данных

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

История и принципы реляционной модели данных

Путешествие в мир реляционных баз данных начинается с 1970 года, когда Эдгар Фрэнк Кодд, выдающийся британский учёный, работавший в IBM, опубликовал свою знаковую работу «A Relational Model of Data for Large Shared Data Banks». Эта статья стала настоящим прорывом, предложив фундаментально новый подход к организации данных, который кардинально отличался от существовавших на тот момент иерархических и сетевых моделей. Кодд впервые ввёл понятие «реляционный», от английского «relation» — отношение, зависимость, связь, подчеркивая, что данные должны быть организованы в виде связанных таблиц.

Реляционная модель данных (РМД) определяет структуру, правила целостности и операции, которые могут быть выполнены над данными. В её основе лежат следующие ключевые понятия:

• Отношение (Relation): В контексте реляционной модели это синоним таблицы. Отношение состоит из строк и столбцов. Например, таблица «Пассажиры» является отношением.
• Кортеж (Tuple): Каждая строка в отношении называется кортежем и представляет собой отдельную запись. Если таблица «Пассажиры» содержит данные о конкретном человеке (имя, фамилия, паспортные данные), то каждая такая строка — это кортеж.
• Атрибут (Attribute): Каждый столбец в отношении называется атрибутом. Атрибуты описывают свойства сущности. Например, «Имя», «Фамилия», «ДатаРождения» — это атрибуты сущности «Пассажир». Каждый атрибут имеет домен — набор допустимых значений.
• Первичный ключ (Primary Key): Это один или несколько атрибутов, которые уникально идентифицируют каждый кортеж в отношении. Например, ID_Пассажира может быть первичным ключом в таблице «Пассажиры». Он гарантирует, что каждая запись уникальна и легко доступна.
• Схема отношения: Это описание структуры отношения, включающее имя отношения и список его атрибутов с указанием их доменов.

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

Системы управления базами данных (СУБД): назначение и классификация

Если реляционная модель — это архитектурный план, то Система Управления Базами Данных (СУБД) — это строитель и администратор, который воплощает этот план в жизнь и обеспечивает его бесперебойную работу. СУБД представляет собой сложный комплекс программно-языковых средств, разработанных для создания баз данных, а также для эффективного и безопасного управления данными, хранящимися в них.

Основные функции СУБД включают:

• Хранение данных: Эффективное размещение данных на носителях, их структурирование и организация для быстрого доступа.
• Управление данными: Поддержка операций добавления (INSERT), чтения (SELECT), обновления (UPDATE) и удаления (DELETE) данных.
• Обеспечение целостности данных: Гарантия того, что данные остаются точными, согласованными и надёжными, даже при сбоях или попытках некорректного ввода. Это достигается за счёт механизмов ссылочной целостности, ограничений уникальности и других правил.
• Обеспечение безопасности данных: Защита данных от несанкционированного доступа, изменения или удаления. СУБД предоставляет механизмы аутентификации, авторизации и разграничения прав доступа на различных уровнях.
• Управление транзакциями: Обеспечение атомарности, согласованности, изолированности и долговечности (ACID-свойства) операций, что критически важно для надёжности системы.
• Восстановление данных: Возможность восстановления базы данных до согласованного состояния после сбоев или ошибок.
• Многопользовательский доступ: Координация одновременного доступа к данным нескольких пользователей или приложений, предотвращение конфликтов и обеспечение согласованности.

Для взаимодействия с любой реляционной базой данных, управляемой РСУБД, используется универсальный и стандартизированный язык структурированных запросов — SQL (Structured Query Language). SQL получил статус стандарта Американского национального института стандартов (ANSI) в 1986 году и Международной организации по стандартизации (ISO) в 1987 году, что сделало его де-факто языком для работы с реляционными базами данных по всему миру. Он позволяет пользователям и приложениям определять структуру данных (DDL — Data Definition Language), манипулировать данными (DML — Data Manipulation Language), а также управлять доступом и безопасностью (DCL — Data Control Language).

СУБД можно классифицировать по различным критериям, например, по модели данных (реляционные, объектно-реляционные, документоориентированные, графовые и т.д.), по архитектуре (клиент-серверные, встроенные, распределённые) или по лицензированию (проприетарные, с открытым исходным кодом). Для данной дипломной работы ключевым является класс реляционных СУБД, которые благодаря своей надёжности, гибкости и масштабируемости остаются доминирующими в бизнес-приложениях, включая системы управления пассажирскими перевозками.

Методологии проектирования и нормализация баз данных

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

Концептуальное моделирование: Модель «сущность-связь» (ER-модель)

Когда мы приступаем к проектированию базы данных, первым шагом всегда является концептуальное моделирование. Это своего рода «эскиз» предметной области, который позволяет нам зафиксировать основные объекты и их взаимосвязи без привязки к конкретной СУБД. Именно для этой цели была разработана модель «сущность-связь» (Entity-Relationship Model, ER-модель) тайваньско-американским учёным Питером Пин-Шеном Ченом в 1976 году. ER-модель является одним из наиболее известных методов семантического моделирования и позволяет ясно и наглядно описывать концептуальные схемы предметной области.

Ключевыми компонентами ER-модели являются:

• Сущность (Entity): Это предмет, объект или событие, которое может быть идентифицировано некоторым способом, отличающим его от других предметов. В контексте агентства пассажирских перевозок сущностями могут быть «Пассажир», «Рейс», «Билет», «Маршрут», «Транспортное средство», «Сотрудник». Каждая сущность обычно представляется прямоугольником на ER-диаграмме.
• Атрибут (Attribute): Это свойство сущности, как правило, атомарное (неделимое). Например, для сущности «Пассажир» атрибутами будут «Имя», «Фамилия», «ДатаРождения», «НомерПаспорта». Атрибуты часто изображаются овалами, присоединёнными к сущностям. Особое значение имеют ключевые атрибуты, которые уникально идентифицируют сущность (например, ID_Пассажира), они обычно подчёркиваются.
• Связь (Relationship): Это ассоциация, устанавливаемая между двумя или более сущностями, которая графически изображается линией (часто с ромбом, если связь имеет свои атрибуты) между сущностями. Связи могут быть бинарными (между двумя сущностями) или рекурсивными (сущность связана сама с собой). Важной характеристикой связи является её мощность или кардинальность (например, «один-к-одному», «один-ко-многим», «многие-ко-многим»), которая указывает, сколько экземпляров одной сущности может быть связано с экземплярами другой сущности. Например, «Пассажир» покупает «Билет» (один-ко-многим: один пассажир может купить много билетов).

ER-диаграмма (ERD) — это графическое представление ER-модели. Она выступает в роли визуального языка, который помогает разработчикам и заказчикам понять, какие данные есть в системе и как они взаимосвязаны. Преимущества ERD заключаются в способности разбить сложные системы и базы данных на более простые элементы, что упрощает анализ, проектирование и коммуникацию между участниками проекта.

Логическое проектирование: Методология IDEF1X

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

IDEF1X — это метод информационного моделирования данных, который является федеральным стандартом в США (FIPS PUB 184) и широко используется для формирования графических представлений информационных моделей, отражающих структуру и семантику информации. Он основан на концепции «сущность-связь», но адаптирован и расширен специально для моделирования реляционных баз данных.

Ключевые особенности IDEF1X:

• Строгий синтаксис: IDEF1X обладает более строгим и формализованным синтаксисом по сравнению с классической ER-моделью, что делает его идеальным для проектирования реляционных баз данных, где важна точность.
• Отображение связей: В IDEF1X связи между сущностями могут быть идентифицирующими (когда первичный ключ дочерней сущности включает первичный ключ родительской) и неидентифицирующими (когда первичный ключ дочерней сущности не включает первичный ключ родительской, а использует внешний ключ). Это позволяет более точно моделировать зависимость сущностей.
• Представление атрибутов: Атрибуты делятся на первичные (составляющие первичный ключ), альтернативные (уникальные, но не первичные) и неключевые.
• Иерархия обобщения/специализации: IDEF1X поддерживает механизмы наследования, позволяя моделировать общие сущности и их специализированные подтипы.

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

Нормализация реляционных баз данных

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

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

Рассмотрим основные нормальные формы:

1. Первая нормальная форма (1НФ): Это базовое требование для любой реляционной таблицы.
   • Каждая ячейка таблицы должна хранить только одно атомарное значение (неделимое).
   • Все данные в одной колонке должны быть одного типа.
   • Каждая запись (строка) должна уникально отличаться от других записей (т.е. должен существовать первичный ключ).

   Пример: Если в таблице «Рейсы» есть поле «Пассажиры» с несколькими именами, 1НФ будет нарушена. Необходимо создать отдельную таблицу «Пассажиры_Рейса», где каждый пассажир будет отдельной записью.

2. Вторая нормальная форма (2НФ): Требует, чтобы отношение находилось в 1НФ, и каждый неключевой атрибут функционально полностью зависел от первичного ключа, исключая частичные функциональные зависимости от составного ключа. Это означает, что если первичный ключ состоит из нескольких атрибутов (составной ключ), то каждый неключевой атрибут не должен зависеть только от части первичного ключа.
   • Пример: Если в таблице Билеты (НомерБилета, НомерРейса, Место, НазваниеМаршрута) первичный ключ — это (НомерБилета, НомерРейса), а НазваниеМаршрута зависит только от НомерРейса (части первичного ключа), то это нарушение 2НФ. Решение — вынести НазваниеМаршрута в отдельную таблицу Маршруты (НомерМаршрута, НазваниеМаршрута).
3. Третья нормальная форма (3НФ): Требует, чтобы отношение находилось в 2НФ и исключало транзитивные функциональные зависимости неключевых атрибутов от первичного ключа. То есть, каждый неключевой атрибут должен нетранзитивно зависеть от первичного ключа. Это означает, что неключевой атрибут не должен зависеть от другого неключевого атрибута, который, в свою очередь, зависит от первичного ключа.
   • Пример: В таблице Сотрудники (ID_Сотрудника, ФИО, Должность, НазваниеОтдела) первичный ключ — ID_Сотрудника. Если НазваниеОтдела определяется Должностью (неключевой атрибут), а Должность определяется ID_Сотрудника, то это транзитивная зависимость. Решение — вынести Должность и НазваниеОтдела в отдельную таблицу Отделы (ID_Отдела, НазваниеОтдела).

Нормализация является краеугольным камнем проектирования реляционных баз данных, так как она не только уменьшает избыточность, но и значительно повышает целостность данных, обеспечивая их точность и согласованность. Однако, следует отметить, что чрезмерная нормализация может привести к увеличению количества таблиц и, как следствие, к необходимости выполнения множества операций соединения между ними (JOINs), что иногда может замедлять выполнение запросов. Поэтому в реальных проектах иногда применяется денормализация для оптимизации производительности, но это должно быть осознанным решением, основанным на тщательном анализе.

Проектирование базы данных для агентства пассажирских перевозок

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

Анализ предметной области и сбор требований

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

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

• Учёт рейсов: Хранение информации о каждом рейсе (номер рейса, маршрут, время отправления/прибытия, тип транспортного средства, статус).
• Учёт пассажиров: Регистрация данных о пассажирах (ФИО, паспортные данные, контактная информация).
• Учёт билетов: Фиксация информации о проданных билетах (номер билета, дата покупки, стоимость, место, связь с пассажиром и рейсом).
• Учёт маршрутов: Хранение данных о маршрутах (пункт отправления, пункт назначения, промежуточные остановки, расстояние).
• Учёт транспортных средств: Информация о подвижном составе (марка, модель, государственный номер, вместимость).
• Учёт персонала: Данные о водителях, контролёрах, кассирах и других сотрудниках (ФИО, должность, контактная информация).
• Бронирование и продажа билетов: Возможность оформления новых билетов, их оплаты и регистрации пассажиров на рейсы.
• Формирование расписания: Ведение и обновление графика движения транспортных средств.
• Формирование отчётности: Генерация различных отчётов (например, по пассажиропотоку, загруженности рейсов, выручке, эффективности маршрутов).

Нефункциональные требования также играют ключевую роль, влияя на архитектуру и выбор технологий:

• Надёжность: Система должна быть устойчива к сбоям и обеспечивать сохранность данных.
• Производительность: Быстрый отклик на запросы пользователей, особенно при поиске билетов и формировании отчётов.
• Безопасность: Защита персональных данных пассажиров и конфиденциальной информации агентства от несанкционированного доступа.
• Масштабируемость: Возможность расширения системы для обработки увеличивающегося объёма данных и числа пользователей.
• Удобство использования: Интуитивно понятный интерфейс для сотрудников агентства.
• Целостность данных: Гарантия того, что данные в базе всегда будут точными и согласованными.

Эти требования напрямую влияют на структуру базы данных. Например, требование к учёту рейсов порождает сущность «Рейс» с атрибутами типа «номер», «дата», «время». Требование к бронированию билетов подразумевает связь «Пассажир»-«Билет»-«Рейс» и механизмы контроля доступности мест.

Разработка концептуальной и логической модели данных

На основе собранных требований следующим шагом является построение концептуальной и логической моделей данных. Концептуальная модель, часто представленная в виде ER-диаграммы, позволяет визуализировать основные сущности предметной области и их взаимосвязи на высоком уровне абстракции.

Для агентства пассажирских перевозок типичные сущности включают:

• Пассажир: (ID_Пассажира, ФИО, ПаспортныеДанные, КонтактныйТелефон, Email)
• Рейс: (ID_Рейса, НомерРейса, ID_Маршрута, ID_Транспорта, ДатаОтправления, ВремяОтправления, ДатаПрибытия, ВремяПрибытия, Статус)
• Маршрут: (ID_Маршрута, НазваниеМаршрута, ПунктОтправления, ПунктНазначения, Расстояние)
• Билет: (ID_Билета, ID_Пассажира, ID_Рейса, Место, Стоимость, ДатаПокупки, СтатусБилета)
• ТранспортноеСредство: (ID_Транспорта, Марка, Модель, ГосНомер, Вместимость)
• Сотрудник: (ID_Сотрудника, ФИО, Должность, КонтактныйТелефон)

Связи между этими сущностями могут быть следующими:

• Пассажир покупает Билет (один-ко-многим: один пассажир может купить много билетов).
• Билет относится к Рейсу (многие-к-одному: много билетов на один рейс).
• Рейс использует Маршрут (многие-к-одному: много рейсов по одному маршруту).
• Рейс выполняется ТранспортнымСредством (многие-к-одному: много рейсов одним транспортным средством).
• Сотрудник обслуживает Рейс (один-ко-многим или многие-ко-многим, в зависимости от роли).

Пример упрощённой ER-диаграммы:

+-----------+       +-------+       +----------+       +-------------------+
| Пассажир  |-------| Билет |-------| Рейс     |-------| ТранспортноеСредство |
+-----------+       +-------+       +----------+       +-------------------+
  - ID_Пассажира (PK)  - ID_Билета (PK) - ID_Рейса (PK)  - ID_Транспорта (PK)
  - ФИО                  - ID_Пассажира (FK) - ID_Маршрута (FK) - Марка
  - ПаспортныеДанные     - ID_Рейса (FK)     - ID_Транспорта (FK) - Модель
  - КонтактныйТелефон    - Место             - ДатаОтправления    - ГосНомер
  - Email                - Стоимость         - ВремяОтправления   - Вместимость
                       - ДатаПокупки       - Статус
                       - СтатусБилета
                              |
                              |
                              +----------+
                              | Маршрут  |
                              +----------+
                                - ID_Маршрута (PK)
                                - НазваниеМаршрута
                                - ПунктОтправления
                                - ПунктНазначения
                                - Расстояние

Логическая модель данных, например, построенная с использованием методологии IDEF1X, детализирует эти сущности и связи до уровня таблиц, первичных и внешних ключей, а также уточняет кардинальность и типы связей, подготавливая модель к реализации в конкретной СУБД. На этом этапе происходит перевод концептуальных связей в механизмы внешних ключей, что является основой ссылочной целостности.

Физическая модель данных и выбор СУБД

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

Для реализации базы данных агентства пассажирских перевозок оптимальным выбором является PostgreSQL. Это мощная объектно-реляционная система управления базами данных (ОРСУБД) с открытым исходным кодом, которая обладает рядом преимуществ, делающих её идеальной для академических проектов и коммерческого использования:

• Объектно-реляционная природа: PostgreSQL не только поддерживает стандартные реляционные возможности, но и включает объектно-ориентированные функции, такие как наследование таблиц, сложные типы данных (массивы, JSON/JSONB), что позволяет гибко моделировать сложные предметные области.
• Полная поддержка стандартов: PostgreSQL полностью соответствует стандарту SQL, включая расширенные возможности, что обеспечивает высокую совместимость и переносимость кода.
• Надёжность и целостность данных (ACID): Благодаря полной поддержке алгоритмов транзакций и механизмам контроля целостности данных, PostgreSQL гарантирует атомарность, согласованность, изолированность и долговечность операций. Это критически важно для финансовых транзакций, таких как покупка билетов.
• Безопасность: PostgreSQL оснащена сложными средствами управления доступом, позволяющими администраторам предоставлять гранулированные разрешения на уровне записей (Row-Level Security, RLS) и даже ячеек (Cell-Level Security, CLS), что обеспечивает высокий уровень защиты конфиденциальных данных.
• Производительность и масштабируемость: Мощный механизм индексации (B-tree, GiST, GIN) значительно ускоряет процессы поиска и обработки данных. PostgreSQL демонстрирует высокую производительность при больших нагрузках и может масштабироваться для обработки значительных объёмов информации.
• Расширяемость: Открытый исходный код и архитектура PostgreSQL позволяют дополнять её собственными типами данных, функциями, операторами и модулями, что делает её чрезвычайно гибкой для специализированных задач.
• Активное сообщество и богатая документация: Будучи проектом с открытым исходным кодом, PostgreSQL поддерживается огромным сообществом разработчиков, что обеспечивает постоянное развитие, наличие обширной документации и поддержку.

На фоне других популярных СУБД, таких как MySQL (менее строгая в плане целостности по умолчанию) или проприетарных решений вроде Oracle/SQL Server (которые могут быть избыточно сложными и дорогими для дипломного проекта), PostgreSQL предлагает оптимальный баланс функциональности, надёжности, производительности и доступности. Это делает её идеальным выбором для проектирования и реализации базы данных для агентства пассажирских перевозок.

Реализация базы данных и автоматизация процессов с использованием PostgreSQL

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

Создание структуры базы данных в PostgreSQL

Процесс создания структуры базы данных в PostgreSQL начинается с определения таблиц, которые соответствуют сущностям, выделенным на этапе проектирования. Каждая таблица будет иметь набор столбцов (атрибутов), для которых необходимо указать соответствующие типы данных и ограничения.

Рассмотрим пример создания таблицы для сущности «Пассажир»:

CREATE TABLE Пассажиры (
    ID_Пассажира SERIAL PRIMARY KEY,
    ФИО VARCHAR(255) NOT NULL,
    ПаспортныеДанные VARCHAR(20) UNIQUE NOT NULL,
    КонтактныйТелефон VARCHAR(20),
    Email VARCHAR(255)
);

В этом примере:

• SERIAL PRIMARY KEY автоматически создаёт уникальный идентификатор для каждого нового пассажира и устанавливает его как первичный ключ, обеспечивая уникальность записей.
• VARCHAR(255) NOT NULL определяет строковый тип данных с максимальной длиной 255 символов и гарантирует, что поле не может быть пустым.
• UNIQUE NOT NULL для ПаспортныеДанные гарантирует, что каждая запись имеет уникальные паспортные данные, которые не могут быть null.

Далее, создаются таблицы для других сущностей, таких как «Рейсы», «Маршруты», «ТранспортныеСредства», «Сотрудники», и, что особенно важно, таблица «Билеты», которая связывает пассажиров и рейсы.

CREATE TABLE Маршруты (
    ID_Маршрута SERIAL PRIMARY KEY,
    НазваниеМаршрута VARCHAR(255) UNIQUE NOT NULL,
    ПунктОтправления VARCHAR(100) NOT NULL,
    ПунктНазначения VARCHAR(100) NOT NULL,
    Расстояние INTEGER
);

CREATE TABLE ТранспортныеСредства (
    ID_Транспорта SERIAL PRIMARY KEY,
    Марка VARCHAR(100) NOT NULL,
    Модель VARCHAR(100) NOT NULL,
    ГосНомер VARCHAR(20) UNIQUE NOT NULL,
    Вместимость INTEGER NOT NULL
);

CREATE TABLE Рейсы (
    ID_Рейса SERIAL PRIMARY KEY,
    НомерРейса VARCHAR(50) UNIQUE NOT NULL,
    ID_Маршрута INTEGER NOT NULL REFERENCES Маршруты (ID_Маршрута),
    ID_Транспорта INTEGER NOT NULL REFERENCES ТранспортныеСредства (ID_Транспорта),
    ДатаОтправления DATE NOT NULL,
    ВремяОтправления TIME NOT NULL,
    ДатаПрибытия DATE,
    ВремяПрибытия TIME,
    Статус VARCHAR(50) DEFAULT 'Запланирован'
);

CREATE TABLE Билеты (
    ID_Билета SERIAL PRIMARY KEY,
    ID_Пассажира INTEGER NOT NULL REFERENCES Пассажиры (ID_Пассажира),
    ID_Рейса INTEGER NOT NULL REFERENCES Рейсы (ID_Рейса),
    Место VARCHAR(10) NOT NULL,
    Стоимость NUMERIC(10, 2) NOT NULL,
    ДатаПокупки TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    СтатусБилета VARCHAR(50) DEFAULT 'Куплен',
    UNIQUE (ID_Рейса, Место) -- Каждое место на рейсе должно быть уникальным
);

Обратите внимание на использование REFERENCES для определения внешних ключей. Например, ID_Маршрута INTEGER NOT NULL REFERENCES Маршруты (ID_Маршрута) в таблице Рейсы устанавливает связь с таблицей Маршруты, гарантируя, что каждый рейс ссылается на существующий маршрут. Это критически важно для обеспечения ссылочной целостности, предотвращая появление «висячих» записей. Ограничение UNIQUE (ID_Рейса, Место) в таблице Билеты не позволит продать одно и то же место на одном рейсе дважды.

Разработка запросов и процедур с использованием SQL и PL/pgSQL

После создания структуры, база данных оживает через операции манипуляции данными. SQL (Structured Query Language) является основным инструментом для взаимодействия с реляционными базами данных.

Примеры базовых SQL-запросов:

• INSERT (добавление данных):

  INSERT INTO Пассажиры (ФИО, ПаспортныеДанные, КонтактныйТелефон, Email)
  VALUES ('Иванов Иван Иванович', '1234 567890', '+79001234567', 'ivanov@example.com');
  

• SELECT (выборка данных):

  SELECT P.ФИО, B.Место, R.НомерРейса, M.НазваниеМаршрута
  FROM Пассажиры AS P
  JOIN Билеты AS B ON P.ID_Пассажира = B.ID_Пассажира
  JOIN Рейсы AS R ON B.ID_Рейса = R.ID_Рейса
  JOIN Маршруты AS M ON R.ID_Маршрута = M.ID_Маршрута
  WHERE P.ФИО = 'Иванов Иван Иванович';
  

• UPDATE (обновление данных):

  UPDATE Рейсы
  SET Статус = 'Отменен'
  WHERE ID_Рейса = 101;
  

• DELETE (удаление данных):

  DELETE FROM Пассажиры
  WHERE ID_Пассажира = 5;
  

Для автоматизации более сложных бизнес-логик и повышения производительности, PostgreSQL предлагает мощное процедурное расширение языка SQL — PL/pgSQL (Procedural Language/PostGres Structured Query Language). PL/pgSQL позволяет создавать хранимые процедуры, функции и триггеры, которые выполняются на стороне сервера, минимизируя сетевые задержки и обеспечивая атомарность сложных операций.

Пример функции PL/pgSQL для бронирования билета с проверкой доступности места:

CREATE OR REPLACE FUNCTION БронироватьБилет(
    p_id_пассажира INTEGER,
    p_id_рейса INTEGER,
    p_место VARCHAR(10),
    p_стоимость NUMERIC(10, 2)
)
RETURNS INTEGER AS $$
DECLARE
    v_место_занято BOOLEAN;
    v_id_билета INTEGER;
BEGIN
    -- Проверка, занято ли место
    SELECT EXISTS (
        SELECT 1 FROM Билеты WHERE ID_Рейса = p_id_рейса AND Место = p_место
    ) INTO v_место_занято;

    IF v_место_занято THEN
        RAISE EXCEPTION 'Место % на рейсе % уже занято.', p_место, p_id_рейса;
    END IF;

    -- Вставка нового билета
    INSERT INTO Билеты (ID_Пассажира, ID_Рейса, Место, Стоимость)
    VALUES (p_id_пассажира, p_id_рейса, p_место, p_стоимость)
    RETURNING ID_Билета INTO v_id_билета;

    RETURN v_id_билета;
END;
$$ LANGUAGE plpgsql;

Эта функция позволяет автоматически проверить доступность места перед бронированием, что значительно снижает вероятность ошибок и упрощает логику клиентского приложения.

Автоматизация процессов учёта и формирования отчётности

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

Автоматизация ввода и обработки информации:

• Сокращение времени на учёт: Вместо ручного заполнения журналов и таблиц, данные о пассажирах, билетах и рейсах вводятся непосредственно в систему, что занимает меньше времени и исключает дублирование.
• Минимизация ошибок: Системные ограничения (например, NOT NULL, UNIQUE, CHECK и внешние ключи) предотвращают ввод некорректных или противоречивых данных, значительно снижая вероятность человеческих ошибок. Функции и хранимые процедуры на PL/pgSQL дополнительно контролируют сложную бизнес-логику.
• Актуальная картина: Автоматическое обновление данных позволяет получить реальную картину объёма пассажирских перевозок и загруженности рейсов в любой момент времени.

Автоматизация формирования отчётности:
Одной из наиболее ценных возможностей автоматизированной БД является мгновенное формирование разнообразных аналитических отчётов, которые вручную потребовали бы часы или дни труда.

• Отчёты по пассажиропотоку: С помощью SQL-запросов можно легко получить данные о количестве пассажиров на конкретных маршрутах за определённый период, выявить пиковые часы или дни.

  SELECT M.НазваниеМаршрута, COUNT(B.ID_Билета) AS КоличествоПассажиров
  FROM Билеты AS B
  JOIN Рейсы AS R ON B.ID_Рейса = R.ID_Рейса
  JOIN Маршруты AS M ON R.ID_Маршрута = M.ID_Маршрута
  WHERE R.ДатаОтправления BETWEEN '2025-10-01' AND '2025-10-31'
  GROUP BY M.НазваниеМаршрута
  ORDER BY КоличествоПассажиров DESC;
  

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

  SELECT R.НомерРейса, T.Вместимость, COUNT(B.ID_Билета) AS ЗанятоМест,
             (COUNT(B.ID_Билета)::NUMERIC / T.Вместимость) * 100 AS ПроцентЗагрузки
  FROM Рейсы AS R
  JOIN ТранспортныеСредства AS T ON R.ID_Транспорта = T.ID_Транспорта
  LEFT JOIN Билеты AS B ON R.ID_Рейса = B.ID_Рейса
  GROUP BY R.НомерРейса, T.Вместимость
  ORDER BY ПроцентЗагрузки DESC;
  

• Финансовые отчёты: Анализ выручки по маршрутам, рейсам, периодам.
• Оптимизация расписания: Анализ информации о потоке пассажиров позволяет оптимизировать расписание движения транспортных средств, снизить затраты, повысить рентабельность перевозок и эффективность использования транспорта.

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

Обеспечение целостности, безопасности и производительности базы данных

Создать базу данных — это только полдела. Настоящая ценность системы проявляется в её способности надёжно хранить информацию, защищать её от несанкционированного доступа и быстро обрабатывать запросы. Эти три столпа — целостность, безопасность и производительность — являются фундаментальными для любой информационной системы, особенно в такой критичной сфере, как пассажирские перевозки.

Механизмы обеспечения целостности данных

Целостность данных — это гарантия того, что информация в базе данных является точной, полной, согласованной и актуальной. Нарушение целостности может привести к серьёзным ошибкам в бизнес-процессах и потере доверия к системе. Реляционные СУБД, такие как PostgreSQL, предоставляют мощные механизмы для её подде��жания:

• Первичные ключи (Primary Keys): Как уже упоминалось, первичный ключ уникально идентифицирует каждую запись в таблице. Он гарантирует, что не будет дубликатов записей, что является основой целостности.
• Внешние ключи (Foreign Keys): Это, пожалуй, наиболее важный механизм для поддержания ссылочной целостности. Внешний ключ в одной таблице ссылается на первичный ключ в другой таблице, устанавливая связь между ними. Основная задача внешнего ключа — предотвращение некорректных данных в таблицах, гарантируя, что в «дочерней» таблице не будет ссылок на несуществующие записи в «родительской» таблице.
  • Например, ID_Рейса в таблице Билеты является внешним ключом, ссылающимся на ID_Рейса в таблице Рейсы. Это означает, что невозможно продать билет на рейс, который не существует в базе данных.
  • Реляционные СУБД поддерживают автоматический контроль ссылочной целостности, позволяя настраивать действия при удалении или обновлении родительской записи: CASCADE (каскадное удаление/обновление), SET NULL (установка NULL), RESTRICT (запрет операции).
• Ограничения (Constraints):
  • NOT NULL: Гарантирует, что столбец не может содержать пустое значение.
  • UNIQUE: Гарантирует уникальность значений в столбце (например, ПаспортныеДанные должны быть уникальными для каждого пассажира).
  • CHECK: Позволяет определить пользовательское правило для значений в столбце (например, Стоимость билета должна быть больше нуля).
• Нормализация данных: Как было подробно рассмотрено, процесс нормализации, заключающийся в достижении 1НФ, 2НФ и 3НФ, является фундаментальным для устранения избыточности и повышения целостности данных, обеспечивая их точность и согласованность.

Безопасность данных: разграничение доступа и защита информации

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

• Аутентификация и Авторизация:
  • Аутентификация: Проверка подлинности пользователя (например, по логину и паролю) при попытке подключения к базе данных.
  • Авторизация: Определение прав доступа пользователя к конкретным объектам базы данных (таблицам, представлениям, функциям) и типам операций (чтение, запись, изменение, удаление).
• Управление привилегиями: Администраторы предоставляют разрешения на доступ к данным, выбирая определённые данные для конкретных пользователей или ролей. PostgreSQL позволяет назначать права на чтение, изменение и удаление данных с высокой степенью детализации.
  • Разграничение доступа на уровне объектов (Object-Level Security): Предоставление прав SELECT, INSERT, UPDATE, DELETE на целые таблицы или представления.
  • Разграничение доступа на уровне записей (Row-Level Security, RLS): Это мощный механизм, позволяющий контролировать доступ к отдельным строкам таблицы на основе атрибутов пользователя или данных. Например, сотрудник может видеть только те рейсы, за которые он отвечает.
  • Разграничение доступа на уровне ячеек (Cell-Level Security, CLS): Более гранулированный контроль, позволяющий ограничить доступ к отдельным ячейкам. Например, только администратор может видеть полную информацию о зарплате сотрудников, тогда как другие пользователи видят только их должности.
• Шифрование данных: Данные могут быть зашифрованы как «в покое» (на диске), так и «в движении» (при передаче по сети), что защищает их от перехвата.
• Журналирование и аудит: СУБД ведут журналы всех операций, что позволяет отслеживать, кто, когда и какие данные изменял, что критически важно для расследования инцидентов безопасности.
• Резервное копирование и восстановление: Регулярное создание резервных копий и наличие стратегии восстановления данных являются неотъемлемой частью общей стратегии безопасности.

Оптимизация производительности базы данных

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

• Влияние нормализации: Хотя нормализация способствует повышению целостности данных, чрезмерно нормализованное проектирование базы данных может привести к снижению производительности. Это происходит из-за увеличения количества таблиц и, как следствие, необходимости выполнения множества операций соединения (JOIN) между ними для получения полной информации, что замедляет выполнение запросов. В некоторых случаях (например, для отчётности) может быть применена денормализация, то есть контролируемое введение избыточности для ускорения определённых запросов, но это требует тщательного анализа и мониторинга целостности.
• Индексы: Индексы — это специальные структуры данных, которые значительно ускоряют операции поиска и сортировки в таблицах. Они работают подобно предметному указателю в книге, позволяя СУБД быстро находить нужные данные, не сканируя всю таблицу.
  • Например, индекс на ПаспортныеДанные в таблице Пассажиры ускорит поиск пассажира по этому полю.
  • Однако, чрезмерное количество индексов может замедлить операции INSERT, UPDATE и DELETE, так как каждый раз при изменении данных требуется обновлять и индексы.
• Оптимизация запросов: Написание эффективных SQL-запросов является одним из важнейших способов повышения производительности. Это включает:
  • Использование WHERE условий для фильтрации данных на ранней стадии.
  • Избегание SELECT * и выбор только необходимых столбцов.
  • Оптимальное использование JOIN и избегание вложенных запросов там, где это возможно.
  • Использование EXPLAIN ANALYZE в PostgreSQL для анализа планов выполнения запросов и выявления «узких мест».
• Конфигурация СУБД: Тонкая настройка параметров PostgreSQL (например, объём выделяемой памяти, размер кэша, параметры журналирования) может значительно повлиять на производительность.
• Аппаратное обеспечение: Достаточные ресурсы (процессор, память, быстрые диски) являются фундаментальной основой для высокой производительности.

Поддержание баланса между целостностью, безопасностью и производительностью — это постоянный процесс, который требует глубокого понимания как теоретических принципов, так и практических инструментов СУБД.

Документирование и стандартизация

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

Стандарты разработки информационных систем (ГОСТы)

В Российской Федерации разработка информационных систем, включая базы данных, регламентируется рядом государственных стандартов (ГОСТов). Их применение в дипломной работе не только демонстрирует академическую строгость и профессионализм, но и обеспечивает унификацию, качество и возможность дальнейшей интеграции разработанной системы.

Применимые ГОСТы могут включать:

• ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»: Определяет структуру и содержание технического задания, что является отправной точкой для любого проекта. В этом документе фиксируются цели, задачи, требования к системе, состав функций и другие ключевые аспекты.
• ГОСТ 19.101-77 «Единая система программной документации. Виды программ и программных документов»: Регламентирует общие требования к программной документации, которая включает описание базы данных, запросов, процедур и т.д.
• ГОСТ 19.201-78 «Единая система программной документации. Техническое задание. Требования к содержанию и оформлению»: Конкретизирует требования к содержанию и оформлению технического задания.
• ГОСТ 34.201-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»: Определяет типы документов, их комплектность и правила обозначения на различных этапах жизненного цикла АС.
• ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла систем»: Хотя это международный стандарт, адаптированный в РФ, он описывает процессы жизненного цикла систем и программного обеспечения, включая этапы проектирования, реализации, тестирования и поддержки.
• ГОСТ Р 52292-2004 «Информационная технология. Электронный обмен данными. Общие положения»: Может быть актуален, если предполагается интеграция с другими системами.

Следование этим стандартам обеспечивает структурированность работы, чёткость изложения, сопоставимость результатов и, что немаловажно, облегчает понимание проекта другими специалистами. Для дипломной работы, это подтверждает способность студента работать в соответствии с принятыми в индустрии нормами.

Состав и содержание проектной документации

Проектная документация — это всеобъемлющий набор документов, описывающих систему от начала до конца. Она является «паспортом» базы данных и включает в себя:

1. Техническое задание (ТЗ): Описывает обоснование, цели, задачи, функциональные и нефункциональные требования к системе. Это первый и самый важный документ, определяющий scope проекта.
2. Пояснительная записка: Содержит описание предметной области, анализ существующих решений, теоретические основы, выбор технологий, обоснование проектных решений.
3. Концептуальная модель данных (ER-диаграмма): Графическое представление сущностей и связей на высоком уровне абстракции. Должна включать описание сущностей, их атрибутов и типов связей.
4. Логическая модель данных (IDEF1X-модель): Детализированное представление структуры данных, включающее таблицы, первичные и внешние ключи, атрибуты с указанием их типов данных и ограничений, а также правила нормализации.
5. Физическая модель данных: Описание структуры базы данных в терминах конкретной СУБД (PostgreSQL), включая DDL-скрипты для создания таблиц, индексов, представлений.
6. Описание базы данных: Детальное описание каждой таблицы (название, назначение, список полей, их типы, ограничения, комментарии), связей между таблицами.
7. Схемы таблиц: Визуальное представление структуры таблиц, их полей и связей, часто генерируемое СУБД или инструментами моделирования.
8. Описание запросов и процедур: Примеры основных SQL-запросов (SELECT, INSERT, UPDATE, DELETE) и подробное описание разработанных хранимых процедур и функций на PL/pgSQL, включая их назначение, параметры, возвращаемые значения и алгоритм работы.
9. Описание пользовательского интерфейса (если есть): Скриншоты форм, отчётов, описание их функциональности и взаимодействия с базой данных.
10. Руководство пользователя и администратора: Документация по установке, настройке, эксплуатации системы и управлению ею.
11. Тестовые сценарии и результаты тестирования: Описание методов и результатов проверки работоспособности и корректности базы данных.

Каждый из этих документов должен быть оформлен в соответствии с принятыми стандартами и ГОСТами, обеспечивая полноту, ясность и однозначность представления информации. Качественная документация — это залог успешности проекта и его долгосрочной жизнеспособности.

Заключение

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

Мы начали с глубокого погружения в теоретические основы реляционных баз данных, проследив их развитие от знаковых работ Эдгара Ф. Кодда до современных концепций СУБД. Были детально рассмотрены ключевые понятия, такие как отношения, кортежи, атрибуты и ключи, а также функции систем управления базами данных и роль SQL как универсального языка взаимодействия.

На этапе проектирования мы проанализировали и применили ведущие методологии: ER-модель Питера Чена для концептуального моделирования, позволившую визуализировать сущности и их связи в предметной области, и методологию IDEF1X для создания строгой логической модели, адаптированной под реляционные базы данных. Особое внимание было уделено процессу нормализации, с подробным описанием первой, второй и третьей нормальных форм, что обеспечило минимизацию избыточности и повышение целостности данных.

Для практической реализации была обоснованно выбрана мощная объектно-реляционная СУБД PostgreSQL. Её возможности, включая поддержку стандартов, ACID-свойства, расширяемость и развитые механизмы безопасности, оказались оптимальными для данного проекта. Мы продемонстрировали процесс создания структуры базы данных в PostgreSQL, включая определение таблиц, типов данных, первичных и внешних ключей, а также разработали примеры SQL-запросов и хранимых процедур на PL/pgSQL для автоматизации типовых операций, таких как бронирование билетов и формирование отчётов.

Критически важным аспектом работы стало исследование механизмов обеспечения целостности, безопасности и производительности базы данных. Была подчёркнута роль внешних ключей в поддержании ссылочной целостности, а также рассмотрены современные методы защиты информации, включая разграничение доступа на уровне записей и ячеек (RLS/CLS). Вопросы оптимизации производительности, включая влияние нормализации, использование индексов и написание эффективных запросов, также нашли своё отражение.

Наконец, мы акцентировали внимание на важности документирования и стандартизации, обозначив применимые ГОСТы и требования к составу проектной документации, что подчёркивает академическую строгость и практическую ценность работы.

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

Перспективы дальнейшего развития проекта включают: разработку полноценного пользовательского интерфейса (web- или desktop-приложения) для взаимодействия с базой данных; интеграцию с платёжными системами; внедрение модулей для онлайн-бронирования билетов; расширение функционала для аналитики пассажиропотока с использованием инструментов Business Intelligence; а также исследование возможностей масштабирования и обеспечения высокой доступности системы.

Данная дипломная работа демонстрирует глубокое понимание принципов проектирования и реализации реляционных баз данных, их практическое применение в условиях реального бизнеса и способность создавать надёжные, безопасные и эффективные информационные системы.

Список использованной литературы

1. Атре Ш. Структурный подход к организации баз данных. М.: Финансы и статистика, 2003.
2. Внешний ключ: что это такое и как он работает — подробное объяснение. Skyeng. URL: https://skyeng.ru/articles/vneshnij-klyuch-chto-eto-takoe-i-kak-on-rabotaet-podrobnoe-obyasnenie/ (дата обращения: 07.11.2025).
3. Внешние ключи в базах данных — как они работают и зачем нужны. EdgeЦентр. URL: https://edgecenter.ru/blog/foreign-keys-in-databases/ (дата обращения: 07.11.2025).
4. Дейт Д. Введение в системы баз данных. М.: Наука, 2005.
5. Диго С.М. Проектирование и использование баз данных. М.: Финансы и статистика, 2004.
6. Змитрович А.И. Базы данных. Мн.: Университетское, 2003.
7. Информатика: Учебник / Под ред. проф. Н.В. Макаровой. М.: Финансы и статистика, 2004.
8. Информационные системы в экономике / Под ред. В.Дика. М.: Финансы и статистика, 2005.
9. Карпова Т. Базы данных: модели, разработка, реализация. СПб.: Питер, 2006.
10. Мартин Д. Организация баз данных в вычислительных системах. М., 2002.
11. Модель «сущность-связь». Интуит. URL: http://www.intuit.ru/studies/courses/652/508/lecture/11832?page=3 (дата обращения: 07.11.2025).
12. Нагао. Структуры и базы данных, 2005.
13. Основы методологии IDEF1X. Корпоративный менеджмент. URL: https://www.cfin.ru/management/controlling/idef1x_basics.shtml (дата обращения: 07.11.2025).
14. Основы работы с базами данных. Лекция 3: Разработка модели базы данных. Интуит. URL: http://www.intuit.ru/studies/courses/652/508/lecture/11832?page=4 (дата обращения: 07.11.2025).
15. Основные понятия модели Entity-Relationship (Сущность-Связи). Интуит. URL: http://www.intuit.ru/studies/courses/652/508/lecture/11832?page=5 (дата обращения: 07.11.2025).
16. Острейковский В.А. Информатика. М.: Высшая школа, 2004.
17. PostgreSQL: все, что нужно знать для быстрого старта. Рег.облако. URL: https://reg.ru/cloud/blog/postgresql-dlya-nachinayushhih (дата обращения: 07.11.2025).
18. Примеры и принципы нормализации реляционных баз данных (БД). DecoSystems. URL: https://decosystems.ru/blog/normalizatsiya-bazy-dannykh (дата обращения: 07.11.2025).
19. Проектирование структуры баз данных. URL: https://studfile.net/preview/6060124/page:11/ (дата обращения: 07.11.2025).
20. Реляционные базы данных. Yandex Cloud — Документация. URL: https://cloud.yandex.ru/docs/managed-postgresql/concepts/relational-database (дата обращения: 07.11.2025).
21. Реляционные базы данных. Информатика. Фоксфорд Учебник. URL: https://foxford.ru/wiki/informatika/relyatsionnye-bazy-dannyh (дата обращения: 07.11.2025).
22. Робинсон С. Microsoft Access 2000. СПб.: Питер, 2006.
23. Система управления базами данных (СУБД): что это такое и зачем нужна. Cloud.ru. URL: https://cloud.ru/blog/chto-takoe-subd-dlya-chego-nuzhna-i-kakie-byvayut (дата обращения: 07.11.2025).
24. СУБД (Системы управления базами данных) — что это, какие бывают. itglobal. URL: https://itglobal.com/ru/blog/chto-takoe-subd/ (дата обращения: 07.11.2025).
25. СУБД: что это, виды, структура, функции — где и как используются системы управления базами данных, примеры. Яндекс Практикум. URL: https://practicum.yandex.ru/blog/chto-takoe-subd/ (дата обращения: 07.11.2025).
26. Тиори, Фрей. Проектирование структур баз данных. М.: Мир, 2003.
27. Ульман Д. Основы систем баз данных. М.: Финансы и статистика, 2004.
28. Учет и управление пассажирскими перевозками в конфигурации программы 1С. Кодерлайн. URL: https://coderline.ru/blog/uchet-i-upravlenie-passazharskimi-perevozkami-v-konfiguratsii-programmy-1s/ (дата обращения: 07.11.2025).
29. Цикритзис Д., Лоховски Ф. Модели данных. М., 2005.
30. Что такое ER-диаграмма и как ее создать? Lucidchart. URL: https://www.lucidchart.com/pages/ru/chto-takoe-er-diagramma (дата обращения: 07.11.2025).
31. Что такое PostgreSQL: основные принципы работы и возможности базы данных. Kvantech. URL: https://kvantech.ru/blog/postgresql-chto-eto-kak-rabotaet-i-kak-nachat-polzovatsya/ (дата обращения: 07.11.2025).
32. Что такое диаграмма взаимосвязи объектов? Miro. URL: https://miro.com/ru/guides/er-diagram/ (дата обращения: 07.11.2025).
33. Что такое нормализация базы данных? Академия доступного IT образования. URL: https://www.academit.ru/blog/chto-takoe-normalizatsiya-bazy-dannykh/ (дата обращения: 07.11.2025).
34. Что такое реляционная база данных? Amazon Web Services (AWS). URL: https://aws.amazon.com/ru/relational-databases/ (дата обращения: 07.11.2025).
35. Что такое реляционная база данных. Академия Selectel. URL: https://selectel.ru/blog/relational-database/ (дата обращения: 07.11.2025).