Методология проектирования и практическая реализация реляционной базы данных «Деканат» в среде MS Access 2010

Теоретические основы проектирования информационных систем

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

Целью данного аналитического проекта является разработка исчерпывающей методологии проектирования и последующей практической реализации реляционной базы данных для предметной области «Деканат учебного заведения», используя при этом систему управления базами данных (СУБД) MS Access 2010.

Базовые концепции СУБД и реляционной модели данных

Для построения любой информационной системы необходимо четко определить ее фундаментальные элементы.

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

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

Предметная область (ПО) — это часть реального мира, которую мы выбираем для изучения с целью организации управления и автоматизации. Для данного проекта предметная область — это все процессы, сущности и взаимосвязи, существующие в работе деканата (студенты, группы, оценки, дисциплины, преподаватели).

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

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

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

Концептуальное моделирование: ER-модель

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

ER-модель, предложенная Питером Ченом в 1976 году в его основополагающей статье «The Entity-Relationship Model — Toward a Unified View of Data», является ключевым инструментом для описания концептуальной схемы предметной области. Она позволяет разработчику выделить главные объекты (сущности) и установить логические взаимосвязи между ними.

Ключевые элементы ER-модели:

1. Сущности (Entity): Объекты, информацию о которых необходимо хранить (например, Студент, Группа, Преподаватель).
2. Атрибуты (Attribute): Характеристики сущностей (например, у сущности Студент атрибуты: ФИО, Дата рождения).
3. Связи (Relationship): Ассоциации между сущностями (например, связь «Учится» между Студентом и Группой). Связи характеризуются мощностью (кардинальностью), которая определяет количество экземпляров одной сущности, связанных с экземплярами другой (1:1, 1:M, M:M).

Анализ предметной области и методология разработки БД

Разработка базы данных — это не хаотичный процесс, а структурированный цикл, известный как Жизненный цикл базы данных (ЖЦБД, DBLC). Классическая методика включает стадии анализа требований, проектирования (концептуальное, логическое, физическое), реализации, эксплуатации и сопровождения. Логическое проектирование является критическим этапом для обеспечения качества всей системы.

Критический анализ ЖЦБД для малых проектов

Для небольших, четко определенных проектов, таких как разработка БД деканата в MS Access, часто применяется Каскадная модель (Waterfall model). Эта модель подразумевает строго последовательное выполнение всех этапов: от сбора требований до тестирования и ввода в эксплуатацию. Следовательно, каждый этап должен быть проработан максимально детально, чтобы минимизировать риски.

Стадия ЖЦБД	Адаптация для проекта «Деканат»
1. Анализ требований	Сбор данных о существующих формах учета, интервьюирование сотрудников деканата.
2. Концептуальное проектирование	Построение ER-модели.
3. Логическое проектирование	Нормализация таблиц до 3НФ, определение ключей.
4. Физическое проектирование	Определение типов данных, учет ограничений MS Access 2010.
5. Реализация	Создание таблиц, запросов, форм, отчетов в среде Access.
6. Эксплуатация и сопровождение	Тестирование, ввод данных, обучение персонала.

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

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

Функциональный анализ бизнес-процессов деканата

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

1. Управление контингентом студентов: Процессы зачисления, формирования учебных групп, перевода студентов с курса на курс, отчисления.
2. Учет успеваемости: Внесение результатов экзаменов и зачетов, хранение оценок, фиксация пересдач, привязка оценок к конкретной дисциплине и преподавателю.
3. Учет учебного плана: Хранение информации о читаемых дисциплинах, их объеме, закреплении за кафедрами.
4. Формирование отчетности: Создание списков студентов по группам, сводных ведомостей успеваемости, справок об обучении.

На основе этого анализа определяются основные сущности предметной области, которые станут основой для ER-модели:

• Студенты (ФИО, № зачетной книжки).
• Группы (Название, Курс, Специальность).
• Дисциплины (Название, Часы, Код).
• Преподаватели (ФИО, Должность).
• Кафедры (Название, Код).
• Ведомости/Оценки (Связь между Студентом, Дисциплиной, Преподавателем и результатом).

Логическое проектирование: Построение ER-модели и Нормализация до 3НФ

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

Разработка ER-диаграммы для предметной области «Деканат»

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

Ключевые связи:

1. Кафедры — Преподаватели: Связь один-ко-многим (1:M). Одна кафедра имеет много преподавателей, но каждый преподаватель принадлежит только одной кафедре.
2. Группы — Студенты: Связь один-ко-многим (1:M). В одной группе учится много студентов, но каждый студент числится только в одной группе.
3. Студенты — Дисциплины — Преподаватели: Связь многие-ко-многим (M:M). Студент изучает много дисциплин, и каждая дисциплина изучается многими студентами. Эта связь разрешается посредством промежуточной сущности УСПЕВАЕМОСТЬ (или Ведомость).

Сущность УСПЕВАЕМОСТЬ является ключевой для хранения результатов:

• Она связывает: Студента (Внешний ключ), Дисциплину (Внешний ключ), Преподавателя (Внешний ключ).
• Содержит атрибуты: Оценка, Дата сдачи.
• Первичный ключ: `{КодСтудента, КодДисциплины, Дата Сдачи}`.

Формальный процесс нормализации отношений

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

Аномалии в реляционных базах данных:

• Аномалия вставки: Невозможность добавить информацию об одном объекте (например, о новой Дисциплине), пока нет связанных данных о другом.
• Аномалия удаления: Потеря информации о целом объекте при удалении связанной записи (например, удаление последнего студента из группы приводит к потере информации о самой Группе).
• Аномалия обновления: Необходимость обновлять одно и то же значение в нескольких местах (например, изменение названия Кафедры требует изменения во всех записях Преподавателей этой Кафедры).

Для устранения этих аномалий мы приводим таблицы к Третьей Нормальной Форме (3НФ).

Определение функциональной зависимости (ФЗ): Атрибут X функционально определяет атрибут Y (записывается как X → Y) тогда и только тогда, когда каждому значению X соответствует в точности одно значение Y.

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

Рассмотрим пример таблицы, потенциально содержащей транзитивную зависимость:

Исходная таблица (УСПЕВАЕМОСТЬ_ПРЕПОДАВАТЕЛЬ)	Тип
КодСтудента	PK
КодДисциплины	PK
Оценка
ДатаСдачи
КодПреподавателя	FK
ФИО_Преподавателя
Кафедра_Преподавателя

Анализ функциональных зависимостей (ФЗ):

1. Полная ФЗ от ключа: {КодСтудента, КодДисциплины} → {Оценка, ДатаСдачи, КодПреподавателя}. (Оценка ставится конкретному студенту по конкретной дисциплине).
2. Зависимость, нарушающая 3НФ:
   • КодПреподавателя → ФИО_Преподавателя (Код однозначно определяет ФИО).
   • КодПреподавателя → Кафедра_Преподавателя (Код однозначно определяет Кафедру).
   • Транзитивная зависимость: {КодСтудента, КодДисциплины} → КодПреподавателя → Кафедра_Преподавателя. (Неключевой атрибут Кафедра_Преподавателя зависит не только от ключа, но и от другого неключевого атрибута КодПреподавателя).

Декомпозиция до 3НФ (Устранение транзитивной ФЗ):

Мы должны выделить зависимые атрибуты и их детерминант (КодПреподавателя) в отдельную таблицу.

1. Таблица 1: УСПЕВАЕМОСТЬ (3НФ)
   • УСПЕВАЕМОСТЬ (КодСтудента, КодДисциплины, Оценка, ДатаСдачи, КодПреподавателя)
   • Устранена транзитивная зависимость.
2. Таблица 2: ПРЕПОДАВАТЕЛИ (3НФ)
   • ПРЕПОДАВАТЕЛИ (КодПреподавателя, ФИО_Преподавателя, КодКафедры)
   • Теперь информация о Кафедре не повторяется каждый раз при записи оценки, что значительно снижает избыточность.

Особенности физической реализации в MS Access 2010

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

Архитектура MS Access и ее ограничения

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

Особенности файл-серверной архитектуры:

1. Хранение: Файл БД (с расширением .accdb или .mdb) хранится централизованно на сетевом сервере.
2. Обработка: Обработка данных (выполнение SQL-запросов, фильтрация, сортировка) не выполняется сервером. Вместо этого, эти задачи полностью перекладываются на клиентские рабочие станции с помощью встроенного движка Access Database Engine (ACE) (преемник Jet Engine).
3. Сетевой трафик (Критический недостаток): При выполнении даже простого запроса SELECT клиентский движок ACE вынужден запрашивать и скачивать с сервера по сети **целые страницы или блоки данных** (включающие большие фрагменты таблиц) для последующей локальной фильтрации и обработки. Это создает высокий сетевой трафик, критически замедляя работу при большом количестве одновременных пользователей.

Технические ограничения MS Access 2010:

• Максимальный размер БД: Общий размер ACCDB-файла не должен превышать 2 ГБ (за вычетом системных объектов). Для деканата среднего вуза это может стать критическим ограничением в долгосрочной перспективе, если не проводить регулярную архивацию.
• Максимальное количество пользователей: Ограничено 255 одновременными пользователями. Однако на практике стабильная работа рекомендуется для небольших групп (до 5-10 человек).

Для повышения надежности и удобства обслуживания в Access всегда рекомендуется **разделение БД** на:

• Backend (внутренний файл): Содержит только таблицы данных и хранится на сервере.
• Frontend (внешний файл): Содержит формы, отчеты, запросы, макросы и логику, и устанавливается локально на рабочих станциях пользователей.

Реализация структуры данных

Создание структуры таблиц в MS Access 2010 выполняется в режиме «Конструктор таблиц».

Типы данных: Выбор корректного типа данных критически важен для экономии памяти и обеспечения точности.

Атрибут	Рекомендуемый тип данных Access	Описание
Код (PK)	Счетчик (AutoNumber)	Автоматически генерирует уникальное целое число. Физически представлен как 4-байтовое длинное целое (Long Integer).
ФИО, Название	Текстовый (Text)	Длина до 255 символов.
Дата рождения	Дата/Время (Date/Time)	Для хронологических данных.
Курс, Семестр	Числовой (Number) – Байт	Малое целое число (0-255) для экономии памяти.
Оценка	Числовой (Number) – Целое	Целое число для отметок (2, 3, 4, 5).

Схема данных и целостность:

После создания таблиц устанавливаются связи в окне «Схема данных». Для обеспечения целостности данных по ссылкам (Referential Integrity) необходимо активировать эту опцию при создании связи между первичным и внешним ключом. Это гарантирует, что нельзя добавить студента в несуществующую группу и нельзя удалить группу, пока в ней числятся студенты (если не выбрано каскадное удаление). Проверка Третьей Нормальной Формы гарантирует правильность этих связей.

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

Эффективная БД требует не только логически корректной структуры, но и удобного, интуитивно понятного интерфейса, который позволит сотрудникам деканата быстро выполнять свои функции.

Разработка SQL-запросов для обработки данных

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

Пример 1: Запрос на выборку (SELECT)

Задача: Получить фамилии и группы всех студентов третьего курса.

SELECT [Фамилия Студента], [Название Группы]
FROM Студенты
WHERE [Курс] = 3;

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

Пример 2: Запрос на обновление (UPDATE)

Задача: Увеличить курс на 1 для всех студентов, успешно закончивших учебный год.

UPDATE Студенты
SET Курс = Курс + 1
WHERE Курс < 5;

Пример 3: Итоговый запрос

Задача: Рассчитать средний балл студентов по всем предметам.

SELECT [Фамилия Студента], AVG(Оценка) AS Средний_Балл
FROM (Студенты INNER JOIN УСПЕВАЕМОСТЬ ON [Студенты].[КодСтудента] = [УСПЕВАЕМОСТЬ].[КодСтудента])
GROUP BY [Фамилия Студента]
HAVING AVG(Оценка) >= 3.0;

Проектирование навигации и форм

Пользовательский интерфейс (UI) служит буфером между пользователем и сложной структурой данных, обеспечивая защищенный ввод и редактирование.

1. Формы для ввода/редактирования: Создаются формы, которые привязываются к одной или нескольким связанным таблицам (например, форма "Студенты" с подчиненной формой "Успеваемость"). Это позволяет пользователю вводить данные, не взаимодействуя напрямую с таблицами, что предотвращает случайное повреждение структуры.
2. Профессиональная навигация: Для создания централизованной панели управления, которая открывается автоматически при запуске приложения, рекомендуется использовать:
   • Диспетчер кнопочных форм (Switchboard Manager): Это встроенное средство Access, которое автоматически создает таблицу Switchboard Items для хранения структуры меню и генерирует набор макросов для переходов. Это наиболее академически корректный способ создания главной навигационной панели для курсовой работы.
   • Форма навигации (Navigation Form): Более современный инструмент, позволяющий быстро создать интерфейс с вкладками, аналогичный веб-интерфейсам.

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

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

Заключение

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

Поставленная цель достигнута путем последовательного прохождения всех этапов Жизненного цикла базы данных (DBLC), адаптированного под специфику малого проекта. Были проведены:

1. Системный анализ: Выделены ключевые бизнес-процессы деканата и определены основные сущности.
2. Концептуальное и логическое проектирование: Разработана ER-диаграмма и проведена формальная нормализация отношений до Третьей Нормальной Формы (3НФ) с демонстрацией устранения транзитивных функциональных зависимостей.
3. Физическая реализация: Учтены и проанализированы архитектурные особенности и ограничения MS Access 2010 (файл-серверная архитектура, движок ACE, ограничение 2 ГБ), что позволило обосновать необходимость разделения БД на Front/Backend.
4. Практическая реализация: Создана структура данных с корректным выбором типов полей (включая использование Счетчик как Long Integer), установлены связи с обеспечением целостности данных. Разработан пользовательский интерфейс с применением профессиональных инструментов (Диспетчер кнопочных форм) и представлены примеры SQL-запросов.

Перспективы дальнейшего развития системы включают: расширение функционала до учета учебных планов в разрезе часов и преподавателей, а также, при увеличении числа пользователей или объема данных, переход на более масштабируемую клиент-серверную архитектуру (например, MS SQL Server). Это устранит ключевой недостаток файл-серверной модели Access — высокий сетевой трафик, обеспечив при этом стабильность и производительность в условиях роста нагрузки на систему.

Список использованной литературы

1. Бастриков, М. В. Информационные технологии управления : учебное пособие / М. В. Бастриков, О. П. Пономарев ; Ин-т «КВШУ». – Калининград : Изд-во Ин-та «КВШУ», 2007. – 140 с.
2. Бочаров, Е. П. Интегрированные корпоративные информационные системы: Принципы построения. Лабораторный практикум на базе системы «Галактика» : учеб. пособие / Е. П. Бочаров, А. И. Колдина. – М. : Финансы и статистика, 2007. – 288 с.
3. Вендров, А. М. Практикум по проектированию программного обеспечения экономических информационных систем : учеб. пособие. – 2-е изд., перераб. и доп. – М. : Финансы и статистика, 2006. – 192 с.
4. Гергенов, А. С. Информационные технологии в управлении : учебное пособие. – Улан-Удэ : Изд-во ВСГТУ, 2007. – 72 с.
5. Канке, А. А. Анализ финансово-хозяйственной деятельности предприятия / А. А. Канке, И. П. Кошевая. – 2-е изд., испр. и доп. – М. : Форум: ИНФРА, 2007. – 288 с.
6. Захарова, И. Г. Информационные технологии в образовании. – М.: Академия, 2010. – 67 с.
7. Новые педагогические и информационные технологии в системе образования. – М.: Академия, 2009.
8. Подласый, И. П. Педагогика. – М. : 2010. – 145 с.
9. Полат, Е. С. Современные педагогические и информационные технологии в системе образования / Е. С. Полат, М. Ю. Бухаркина. – М. : 2008. – 98 с.
10. Базы данных : учебник для высших учебных заведений / А. Д. Хомоненко, В. М. Цыганков, М. Г. Мальцев ; под ред. А. Д. Хомоненко. – 4-е изд., доп. и перераб. – СПб. : КОРОНА принт, 2007. – 736 с.
11. Жизненный цикл базы данных [Электронный ресурс] // Студенческий научный форум. URL: scienceforum.ru (дата обращения: 24.10.2025).
12. Жизненный цикл базы данных. Основные этапы проектирования базы данных [Электронный ресурс]. URL: berpt.ru (дата обращения: 24.10.2025).
13. Концептуальное и логическое проектирование реляционных БД [Электронный ресурс]. URL: academy.lv (дата обращения: 24.10.2025).
14. Нормализация отношений [Электронный ресурс]. URL: studfile.net (дата обращения: 24.10.2025).
15. Автоматизация деятельности типового деканата : научная статья [Электронный ресурс] // cyberleninka.ru. URL: cyberleninka.ru (дата обращения: 24.10.2025).
16. Анализ основных бизнес-процессов образовательной деятельности высшего учебного заведения [Электронный ресурс] // cyberleninka.ru. URL: cyberleninka.ru (дата обращения: 24.10.2025).
17. Архитектура «файл-сервер» в информационных системах [Электронный ресурс]. URL: pivot-table.ru (дата обращения: 24.10.2025).
18. Архитектура многопользовательских систем баз данных [Электронный ресурс]. URL: studme.org (дата обращения: 24.10.2025).
19. Спецификации Access [Электронный ресурс] // Служба поддержки Майкрософт. URL: microsoft.com (дата обращения: 24.10.2025).
20. Нормализация отношений до 3НФ и выше [Электронный ресурс]. URL: learn-more.kz (дата обращения: 24.10.2025).
21. Третья нормальная форма | Основы реляционных баз данных [Электронный ресурс] // hexlet.io. URL: hexlet.io (дата обращения: 24.10.2025).
22. Access 2010 в примерах : Учебное пособие [Электронный ресурс]. URL: kpfu.ru (дата обращения: 24.10.2025).
23. Получение записей с помощью Access SQL [Электронный ресурс] // Microsoft Learn. URL: microsoft.com (дата обращения: 24.10.2025).
24. Что такое ER-диаграмма и как ее создать? [Электронный ресурс]. URL: yandex.ru (дата обращения: 24.10.2025).
25. Разработка информационной системы средствами MS Access 2010 [Электронный ресурс]. URL: rosuchebnik.ru (дата обращения: 24.10.2025).
26. Создание пользовательского интерфейса [Электронный ресурс]. URL: studfile.net (дата обращения: 24.10.2025).