1. Введение

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

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

2. Физическая структура СУБД PostgreSQL

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

Модель данных состоит из двух основных сущностей, связанных между собой:

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

— Таблица сотрудников (employees). Содержит персональные и профессиональные атрибуты работников (имя, фамилия, уникальный адрес электронной почты, телефон, оклад, дата приема). Идентификатор сотрудника также имеет тип UUID.

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

3. Верификация уникальности и ограничений целостности

Первым направлением интеграционного тестирования базы данных является проверка соблюдения ограничений на уникальность и запрет пустых значений (NOT NULL). Если бизнес-логика требует, чтобы у каждого сотрудника был уникальный рабочий email, автотест должен гарантировать, что СУБД аппаратно заблокирует попытку создания дубликата.

Методика интеграционной проверки уникальности состоит из следующих шагов:

— Этап подготовки: через тестовый HTTP-клиент отправляется валидный запрос на создание сотрудника с определенным адресом почты. Запись успешно фиксируется в PostgreSQL.

— Этап действия: отправляется второй запрос на создание другого сотрудника, но с тем же самым почтовым адресом.

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

Аналогичным образом проверяются ограничения NOT NULL: автотесты отправляют запросы с пропущенными обязательными полями и верифицируют, что база данных отклоняет транзакции, сохраняя согласованность схемы данных.

4. Тестирование каскадных операций и внешних ключей

Особое значение при проектировании реляционных баз данных имеет управление зависимыми сущностями при их удалении. В спроектированной системе кадрового учета для внешнего ключа department_id было настроено правило каскадного удаления (ON DELETE CASCADE). Это означает, что при ликвидации отдела из базы данных должны автоматически удаляться и все связанные с ним учетные записи сотрудников.

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

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

— С помощью прямого SQL-запроса автотест подтверждает, что записи физически появились в таблицах departments и employees в контейнере PostgreSQL.

— Отправляется HTTP-запрос на удаление ранее созданного отдела через API микросервиса.

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

Использование реального контейнера PostgreSQL в процессе выполнения тестов гарантирует, что поведение СУБД в тестовой среде абсолютно идентично поведению в продуктовом кластере Kubernetes.

5. Заключение

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

Литература:

1. Дейт К. Дж. Введение в системы баз данных. — М.: Вильямс, 2019. — 1328 с.
2. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. — М.: Вильямс, 2017. — 1440 с.
3. Ньюмен С. Создание микросервисов. — СПб.: Питер, 2021. — 416 с.
4. Хориков В. Принципы юнит-тестирования. — СПб.: Питер, 2021. — 320 с.