Проектирование и реализация информационной системы ГИБДД на MS Access для курсовой работы

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

Целью данной курсовой работы является разработка информационной системы «Учет данных в ГИБДД» на платформе MS Access. Для достижения этой цели были поставлены следующие задачи:

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

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

Какими теоретическими основами мы будем руководствоваться

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

Концепция нормализации

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

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

Методология «сущность-связь» (ER-моделирование)

Прежде чем создавать таблицы, необходимо спроектировать их структуру на концептуальном уровне. Для этого используется ER-моделирование (Entity-Relationship modeling). Этот подход оперирует тремя ключевыми понятиями:

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

Для уникальной идентификации каждой записи в таблице используется первичный ключ (Primary Key), а для установления связей между таблицами — внешний ключ (Foreign Key), который ссылается на первичный ключ в другой таблице.

Как грамотно поставить задачу и проанализировать предметную область

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

• Водители:
  • ID Водителя (ключ)
  • ФИО
  • Дата рождения
  • Адрес проживания
  • Номер водительского удостоверения
  • Категории прав
• Транспортные средства (ТС):
  • ID ТС (ключ)
  • Государственный регистрационный номер
  • VIN-код
  • Марка, модель
  • Год выпуска
  • ID владельца (связь с водителем)
• Инспекторы:
  • ID Инспектора (ключ)
  • ФИО
  • Должность, звание
  • Номер удостоверения
• Протоколы:
  • ID Протокола (ключ)
  • Дата и время составления
  • Место правонарушения
  • ID Инспектора (связь)
  • ID Водителя (связь)
  • ID ТС (связь)
• Правонарушения (справочник):
  • ID Правонарушения (ключ)
  • Статья КоАП
  • Описание нарушения
  • Размер штрафа

Система должна поддерживать такие основные бизнес-процессы, как «Регистрация нового транспортного средства за водителем» и «Оформление протокола об административном правонарушении». Определив, что система должна делать и с какими данными работать, мы можем перейти к визуализации ее структуры.

Проектируем концептуальную модель, или Строим ER-диаграмму нашей базы данных

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

Далее мы устанавливаем связи между этими сущностями. В нашей системе будут преобладать связи типа «один-ко-многим»:

• Один Инспектор может составить много Протоколов.
• Один Водитель может иметь много Транспортных средств.
• Один Водитель может быть упомянут во многих Протоколах.

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

Такие связи в реляционных базах данных реализуются через промежуточную (ассоциативную) таблицу. Мы создадим таблицу, например, Состав_Протокола, которая будет содержать всего два поля: ID Протокола и ID Правонарушения. Эта таблица эффективно «разрывает» сложную связь «многие-ко-многим» на две простые «один-ко-многим».

Как перейти от диаграммы к таблицам и обеспечить их целостность

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

Рассмотрим для примера структуру таблицы «Транспортные_средства»:

• ID_TS: Тип данных «Счетчик». Это первичный ключ, который будет автоматически присваивать уникальный номер каждой новой записи.
• Гос_номер: Тип «Короткий текст». Для хранения государственного регистрационного знака.
• VIN: Тип «Короткий текст». Для уникального идентификатора транспортного средства.
• Марка: Тип «Короткий текст».
• Модель: Тип «Короткий текст».
• Год_выпуска: Тип «Числовой».
• ID_Водителя: Тип «Числовой». Это внешний ключ, который будет ссылаться на поле ID_Водителя в таблице «Водители», устанавливая связь между автомобилем и его владельцем.

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

Воплощаем проект в жизнь, или Физическая реализация базы данных в MS Access

Когда проект готов «на бумаге», настало время реализовать его в СУБД. Процесс создания структуры базы данных в MS Access интуитивно понятен и состоит из нескольких шагов:

1. Создание таблиц. В MS Access перейдите на вкладку «Создание» и выберите «Конструктор таблиц». Здесь вы последовательно вводите имена полей и выбираете для них подходящие типы данных (Короткий текст, Числовой, Дата/Время и т.д.).
2. Задание свойств полей. Для каждого поля в нижней части экрана можно задать дополнительные свойства: размер поля, маску ввода, обязательное для заполнения поле и другие.
3. Установка первичного ключа. Выделите поле, которое будет первичным ключом (например, ID_TS), и на ленте конструктора нажмите кнопку «Ключевое поле».
4. Создание связей. После создания всех таблиц откройте схему данных («Работа с базами данных» -> «Схема данных»). Добавьте все таблицы на схему. Чтобы создать связь, просто «перетащите» мышью первичное поле из одной таблицы на соответствующее внешнее поле в другой.
5. Обеспечение целостности данных. В появившемся окне редактирования связи обязательно установите флажок «Обеспечение целостности данных». Это не позволит добавить в базу запись о транспортном средстве, владелец которого не существует в таблице «Водители».

Дополнительно для полей, по которым часто будет производиться поиск (например, «Гос_номер» или «ФИО»), целесообразно создать индексы. Это значительно ускорит выполнение запросов.

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

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

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

• Свободно перемещать и изменять размеры полей и их подписей.
• Добавлять различные элементы управления: кнопки, списки, вкладки.
• Создавать связанные формы. Например, на главной форме «Водитель» можно разместить подчиненную форму в виде таблицы, где будут отображаться все транспортные средства, принадлежащие именно этому водителю.
• Добавлять логику на кнопки. С помощью конструктора макросов или кода на VBA (Visual Basic for Applications) можно запрограммировать кнопки для выполнения таких действий, как «Сохранить запись», «Удалить», «Перейти к следующей записи» или «Открыть другую форму».

Хорошо спроектированный интерфейс скрывает от пользователя сложную структуру таблиц и делает работу с базой данных простой и безопасной.

Извлекаем нужную информацию, или Разработка системы запросов

Данные ценны не сами по себе, а той информацией, которую из них можно извлечь. Главным инструментом для извлечения, фильтрации и анализа данных в MS Access являются запросы. Они позволяют получать ответы на самые разные вопросы. В режиме конструктора запросов можно создавать как простые, так и очень сложные выборки.

Приведем несколько практических примеров:

1. Простой запрос на выборку: Найти всех водителей, у которых открыта категория «B». Мы просто добавляем таблицу «Водители» и в поле «Категории» в строке «Условие отбора» пишем `Like «*B*»`.
2. Запрос с параметром: Вывести список всех ТС определенной марки. В поле «Марка» в строке «Условие отбора» мы пишем `[Введите марку автомобиля]`. При запуске такого запроса Access попросит пользователя ввести нужную марку.
3. Запрос на основе нескольких таблиц: Вывести список всех правонарушений с указанием ФИО водителя и госномера автомобиля. Для этого в конструктор нужно добавить таблицы «Протоколы», «Водители» и «Транспортные_средства», связав их по соответствующим полям.
4. Итоговый запрос с группировкой: Посчитать общее количество нарушений для каждого инспектора. В этом запросе мы используем групповые операции, чтобы сгруппировать записи по ФИО инспектора и посчитать количество протоколов для каждой группы.

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

Как представить результаты работы, или Создание отчетов и тестирование системы

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

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

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

Тестирование системы

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

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

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

Заключение

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

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

• Удобные формы для ввода и редактирования данных.
• Гибкие запросы для анализа информации по различным критериям.
• Наглядные отчеты для вывода итоговой информации на печать.

Таким образом, можно сделать вывод, что поставленная во введении цель — разработка информационной системы «Учет данных в ГИБДД» — полностью достигнута.

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