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

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

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

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

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

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

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

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

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

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