Проектирование и реализация базы данных для учета посещаемости занятий: полное руководство по курсовой работе

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

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

• Провести детальный анализ предметной области.
• Разработать инфологическую и логическую модели данных.
• Создать физическую структуру таблиц в среде MS Access.
• Разработать запросы для анализа данных, формы для ввода и отчеты для вывода информации.

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

1. Как системный анализ предметной области определяет успех всего проекта

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

1. Деканат: нуждается в сводных отчетах по группам и факультету для контроля общей дисциплины и выявления студентов с большим количеством пропусков.
2. Преподаватель: должен иметь возможность быстро отметить присутствующих на конкретном занятии по своей дисциплине.
3. Студент (косвенный пользователь): может запрашивать информацию о своей статистике посещаемости.

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

В нашей задаче это: «Студент», «Группа», «Дисциплина», «Преподаватель» и центральная сущность «Занятие», которая будет фиксировать факт проведения занятия в определенный день по конкретной дисциплине.

Каждая из этих сущностей обладает набором характеристик — атрибутов. Например, у «Студента» это будут ФИО и привязка к группе, у «Дисциплины» — ее название. Взаимодействие между ними определяет логику системы: преподаватель ведет дисциплины, студенты, объединенные в группы, посещают занятия по этим дисциплинам. Таким образом, постановка задачи на разработку формулируется как создание системы, которая позволяет хранить информацию об этих объектах и их связях, а также обеспечивать функции ввода данных о посещаемости и формирования аналитических отчетов.

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

2. Построение инфологической модели, или Как превратить идею в чертеж ER-диаграммы

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

Основываясь на анализе из предыдущего раздела, мы определили ключевые сущности. Теперь опишем их атрибуты и связи. Каждая сущность должна иметь уникальный идентификатор — первичный ключ (обычно это числовое поле, например, `StudentID` или `GroupID`).

Логика связей в нашей системе будет следующей:

• Связь между «Группой» и «Студентами» — «один-ко-многим» (в одной группе учится много студентов, но каждый студент принадлежит только одной группе).
• Связь между «Преподавателем» и «Дисциплинами» — также «один-ко-многим» (один преподаватель может вести несколько дисциплин).
• Связь между «Студентами» и «Дисциплинами» является более сложной — «многие-ко-многим» (один студент изучает много дисциплин, и одну дисциплину изучает много студентов). Такие связи в реляционных базах данных реализуются через промежуточную, связующую таблицу.

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

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

3. От концепции к структуре через процесс нормализации данных

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

Однако просто создать таблицы недостаточно. Чтобы база данных была эффективной и надежной, она должна быть нормализована. Нормализация — это процесс организации данных, направленный на устранение их избыточности и потенциальных аномалий (ошибок при вставке, обновлении или удалении данных). На практике для большинства учебных и коммерческих проектов достаточно доведения структуры до третьей нормальной формы (3NF).

Процесс нормализации можно описать пошагово:

1. Первая нормальная форма (1NF): Требует, чтобы все атрибуты были атомарными, то есть неделимыми. В каждой ячейке таблицы должно быть только одно значение, а повторяющиеся группы полей должны быть вынесены в отдельные таблицы. Например, нельзя в одном поле хранить несколько телефонных номеров студента.
2. Вторая нормальная форма (2NF): Применима к таблицам с составным первичным ключом. Она требует, чтобы все неключевые атрибуты полностью зависели от всего составного ключа, а не от его части. Это позволяет избежать дублирования информации.
3. Третья нормальная форма (3NF): Запрещает транзитивные зависимости, то есть зависимость неключевых атрибутов от других неключевых атрибутов. Если, например, в таблице студентов хранится ID группы и название группы, это нарушение 3NF, так как название группы зависит не от студента, а от ID группы. Название группы следует хранить в отдельной таблице «Группы».

Последовательно применив эти правила, мы получаем финальный набор логически выверенных таблиц. Для каждой таблицы определяются поля и типы данных: `Счетчик` или `INT` для идентификаторов, `Текстовый` (VARCHAR) для ФИО и названий, `Дата/Время` (DATE/DATETIME) для дат занятий.

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

4. Воплощение проекта в жизнь через создание таблиц и связей в MS Access

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

Процесс создания таблиц выглядит следующим образом:

1. Переходим на вкладку «Создание» и выбираем «Конструктор таблиц».
2. В открывшемся окне последовательно вводим имена полей (атрибутов) для каждой таблицы, например, `StudentID`, `FullName`, `GroupID` для таблицы «Студенты».
3. Для каждого поля из выпадающего списка выбираем соответствующий тип данных. Для уникальных идентификаторов идеально подходит тип «Счетчик», который автоматически присваивает новое значение при добавлении записи. Для текстовых полей задаем тип «Короткий текст», а для дат — «Дата/время».
4. В свойствах поля в нижней части экрана можно задать дополнительные параметры: размер поля, маску ввода, значение по умолчанию и указать, является ли поле обязательным для заполнения.
5. Выделяем поле, которое будет первичным ключом (например, `StudentID`), и нажимаем кнопку «Ключевое поле» на панели инструментов.
6. Сохраняем таблицу под логичным именем (например, «Students» или «Groups»).

После того как все таблицы созданы, необходимо установить между ними связи, чтобы база данных «понимала» логику взаимодействия объектов. Это делается в специальном окне «Схема данных» (вкладка «Работа с базами данных»). Здесь нужно просто перетащить ключевое поле из одной таблицы (со стороны «один») на соответствующее внешнее поле в другой таблице (со стороны «многие»). При установке связи Access предложит включить опцию «Обеспечение целостности данных». Этот флажок критически важен: он не позволит добавить в журнал запись о несуществующем студенте или удалить группу, в которой еще числятся студенты.

База данных создана и наполнена первичными данными. Теперь нам нужно научиться извлекать из нее полезную информацию с помощью запросов.

5. Как задавать вопросы базе данных с помощью языка SQL и конструктора запросов

Сами по себе данные в таблицах имеют малую ценность. Сила базы данных заключается в возможности быстро извлекать, фильтровать, группировать и анализировать информацию. Эту функцию выполняют запросы. В MS Access существует два основных способа их создания: наглядный графический конструктор и написание кода на языке структурированных запросов — SQL (Structured Query Language).

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

Пример 1: Вывести всех студентов, пропустивших занятия по «Базам данных» более 3 раз.

В конструкторе запросов мы добавляем таблицы «Студенты», «ЖурналПосещаемости» и «Дисциплины», связываем их, выбираем нужные поля (ФИО студента), а в условиях отбора указываем название дисциплины и статус «Отсутствовал». Затем используем группировку для подсчета количества пропусков и накладываем условие «Больше 3».

На языке SQL это будет выглядеть примерно так:

SELECT Students.FullName, Count(Attendance.Status)
FROM Students
INNER JOIN Attendance ON Students.StudentID = Attendance.StudentID
INNER JOIN Disciplines ON Attendance.DisciplineID = Disciplines.DisciplineID
WHERE Disciplines.Name = "Базы данных" AND Attendance.Status = "Отсутствовал"
GROUP BY Students.FullName
HAVING Count(Attendance.Status) > 3;

Пример 2: Посчитать общее количество пропусков для каждого студента группы «ИСТ-1» за последний месяц.

Здесь также используются операции соединения таблиц (`JOIN`), фильтрации по группе и дате (`WHERE`), группировки по студентам (`GROUP BY`) и подсчета агрегатной функции (`COUNT`).

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

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

6. Проектирование пользовательского интерфейса для удобного управления данными

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

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

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

1. Форма для редактирования данных о студентах. Создается на основе таблицы «Студенты» с помощью Мастера форм. Он автоматически размещает все поля на макете. Затем в режиме конструктора можно улучшить ее внешний вид и добавить кнопки управления: «Добавить нового студента», «Сохранить», «Удалить».
2. Форма для ведения журнала посещаемости. Это более сложная, но и более важная форма. Она, как правило, создается на основе запроса, связывающего несколько таблиц. Для удобства пользователя вместо ручного ввода ID студента или дисциплины используются элементы управления «Поле со списком» (выпадающий список). Такой элемент позволяет выбрать, например, ФИО студента из списка, а в связанную таблицу автоматически подставится его числовой идентификатор. Это не только удобно, но и защищает от ошибок ввода.

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

Данные можно удобно вводить и просматривать. Финальный штрих — это подготовка итоговых документов для печати или анализа.

7. Как представить результаты работы через создание наглядных отчетов

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

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

Для нашей базы данных можно создать несколько полезных отчетов:

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

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

Проект полностью реализован — от идеи до готового программного продукта. Осталось подвести итоги проделанной работы.

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

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

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