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

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

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

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

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

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

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

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

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

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