Проектирование и реализация базы данных для автоматизированной системы управления «Деканат»

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

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

• Проведение системного анализа предметной области «Деканат» для выявления ключевых процессов и информационных потоков.
• Разработка инфологической модели данных, концептуально описывающей сущности и их взаимосвязи.
• Построение логической модели на основе реляционного подхода и ее оптимизация с помощью процесса нормализации.
• Сравнительный анализ и обоснованный выбор системы управления базами данных (СУБД) для реализации проекта.
• Физическое проектирование БД с учетом особенностей выбранной СУБД.
• Создание SQL-скриптов для генерации структуры базы данных, ее наполнения тестовыми данными и выполнения типовых запросов.
• Проведение тестирования для проверки целостности и функциональности созданной базы данных.

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

1. Системный анализ предметной области «Деканат»

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

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

В рамках АСУ «Деканат» можно выделить несколько ключевых ролей пользователей, каждая из которых имеет свои задачи и требует определенного уровня доступа к данным:

1. Администратор: Обладает полными правами на управление структурой и данными БД, включая создание и удаление учетных записей пользователей.
2. Сотрудник деканата: Имеет доступ к добавлению и редактированию информации о студентах, группах, учебных планах и успеваемости.
3. Преподаватель: Получает доступ к просмотру расписания своих занятий и проставлению оценок по своим дисциплинам.
4. Студент: Имеет права на просмотр своего расписания, учебного плана и личной успеваемости.

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

2. Разработка инфологической модели как основы структуры данных

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

В предметной области «Деканат» можно выделить следующие ключевые сущности:

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

Между этими сущностями существуют логические связи. Например, один студент может принадлежать только одной группе, а в одной группе может быть много студентов. Это классический пример связи «один-ко-многим» (1:М) между сущностями «Группа» и «Студент». В то же время, один преподаватель может вести много дисциплин, и одну дисциплину могут вести несколько преподавателей, что формирует связь «многие-ко-многим» (M:N) между «Преподавателем» и «Дисциплиной». Тщательное определение всех сущностей и связей на этом этапе является залогом построения логичной и эффективной структуры данных.

3. Построение логической модели и приведение ее к нормальным формам

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

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

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

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

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

4. Сравнительный анализ и обоснование выбора системы управления базами данных

Имея готовую логическую модель, необходимо выбрать технологический инструмент для ее воплощения — систему управления базами данных (СУБД). На рынке существует множество реляционных СУБД, но для образовательных и enterprise-проектов чаще всего рассматриваются три основных варианта: PostgreSQL, MySQL и Microsoft SQL Server. Выбор должен быть основан на объективном сравнении по ключевым критериям.

Сравнительный анализ популярных реляционных СУБД

Критерий	PostgreSQL	MySQL	MS SQL Server
Лицензирование	Бесплатное (Open Source)	Двойное (бесплатная Community и платные коммерческие)	Платное (есть бесплатная версия Express)
Производительность	Высокая, особенно на сложных запросах	Очень высокая на операциях чтения	Высокая, тесная интеграция с ОС Windows
Инструменты	pgAdmin, DBeaver (сторонние)	MySQL Workbench (официальный)	Microsoft SQL Server Management Studio (SSMS)

Для целей данной курсовой работы выбор делается в пользу Microsoft SQL Server (в редакции Express). Этот выбор обоснован несколькими причинами. Во-первых, наличие бесплатной версии Express снимает лицензионные ограничения для учебного проекта. Во-вторых, MS SQL Server обладает мощной и удобной интегрированной средой управления Microsoft SQL Server Management Studio (SSMS), которая значительно упрощает процессы проектирования, разработки и администрирования. В-третьих, данная СУБД широко распространена в корпоративной среде, что делает изучение работы с ней практически ценным навыком.

5. Физическое проектирование базы данных в среде выбранной СУБД

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

Процесс включает в себя следующие действия:

1. Выбор типов данных: Для каждого атрибута в каждой таблице подбирается наиболее подходящий тип данных из тех, что предлагает MS SQL Server. Например, для ФИО студента используется `NVARCHAR(150)`, для идентификаторов — `INT`, для дат — `DATE` или `DATETIME2`. Правильный выбор типов данных важен для оптимизации производительности и занимаемого дискового пространства.
2. Определение ключей: Для каждой таблицы назначается первичный ключ (`PRIMARY KEY`) — поле или набор полей, уникально идентифицирующих каждую запись. Для реализации связей между таблицами используются внешние ключи (`FOREIGN KEY`), которые ссылаются на первичные ключи в связанных таблицах, обеспечивая ссылочную целостность.
3. Назначение ограничений целостности: Для поддержания корректности данных используются дополнительные ограничения, такие как `NOT NULL` (поле не может быть пустым), `UNIQUE` (все значения в поле должны быть уникальными) и `CHECK` (значение в поле должно удовлетворять заданному условию).
4. Создание индексов: Для полей, которые будут часто использоваться в условиях поиска (например, ФИО студента или название группы), создаются индексы. Индекс — это специальная структура, которая позволяет СУБД находить строки значительно быстрее, что критически важно для производительности при больших объемах данных.

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

6. Разработка SQL-скриптов для создания, наполнения и манипулирования данными

На этом этапе мы переходим от проектирования к реализации. Все, что было спроектировано в физической модели, теперь переводится на язык структурированных запросов — SQL (Structured Query Language). Разрабатывается полный набор скриптов, необходимых для жизненного цикла базы данных.

Создание структуры (DDL — Data Definition Language):
Пишется основной скрипт, содержащий команды `CREATE TABLE`. Для каждой таблицы, определенной на предыдущем этапе, создается соответствующая команда, которая описывает все ее столбцы, их типы данных, первичные и внешние ключи, а также все ограничения (`NOT NULL`, `UNIQUE`).

Наполнение тестовыми данными (DML — Data Manipulation Language):
Чтобы базу данных можно было тестировать, ее необходимо наполнить осмысленными данными. Для этого пишутся скрипты с использованием команды `INSERT`. Для каждой таблицы создается 5-10 записей, имитирующих реальную информацию (например, несколько студентов, групп, преподавателей и их оценок).

Запросы для извлечения данных (DQL — Data Query Language):
Это самая важная часть с точки зрения будущего приложения. Создаются практические запросы с использованием команды `SELECT`, которые решают типовые задачи деканата. Например:

• Вывести список всех студентов определенной группы (используется `WHERE`).
• Показать средний балл каждого студента (используется `GROUP BY` и `AVG`).
• Получить расписание конкретного преподавателя на неделю (используется `JOIN` для соединения таблиц «Преподаватель», «Расписание» и «Дисциплина»).

Также демонстрируются примеры использования команд `UPDATE` для изменения существующих данных и `DELETE` для их удаления. Для обеспечения целостности данных при выполнении сложных операций, состоящих из нескольких шагов, упоминается важность использования транзакций (`BEGIN TRANSACTION`, `COMMIT`, `ROLLBACK`).

7. Тестирование базы данных и концепция взаимодействия с пользователем

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

1. Тестирование структуры: Проверка того, что все таблицы, столбцы и индексы созданы в соответствии с физической моделью.
2. Тестирование ограничений целостности: Выполнение «негативных» сценариев для проверки срабатывания защиты. Например, попытка добавить студента с уже существующим номером зачетной книжки (проверка `UNIQUE`), попытка привязать оценку к несуществующему студенту (проверка `FOREIGN KEY`) или попытка оставить пустым обязательное поле (проверка `NOT NULL`).
3. Тестирование логики запросов: Выполнение `SELECT`-запросов, написанных на предыдущем этапе, и ручная проверка результатов на тестовых данных для подтверждения их корректности.

После подтверждения работоспособности БД важно концептуально описать, как она станет основой для пользовательского приложения. Разные роли пользователей, определенные на этапе анализа, будут взаимодействовать с данными через интерфейс (формы, отчеты, дашборды). Например, Студент через личный кабинет будет выполнять `SELECT`-запрос для просмотра своих оценок, а Сотрудник деканата через специальную форму будет использовать команды `INSERT` и `UPDATE` для зачисления новых студентов и редактирования их данных. Спроектированная база данных полностью поддерживает этот функционал благодаря продуманной структуре и разграничению доступа.

Заключение

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

Поставленная во введении цель — спроектировать и реализовать БД «Деканат» — была полностью достигнута. Все сформулированные задачи успешно выполнены. Ключевыми результатами работы являются:

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

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