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

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

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

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

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

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

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

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

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

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