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

Содержание

1. Цели и задачи БД ЗАГС
2. Требования к системе
3. Архитектура и типы СУБД
4. Структура базы данных
5. Безопасность и защита данных
6. Резервное копирование и восстановление
7. Интеграция с другими системами
8. Примеры запросов
9. Лучшие практики эксплуатации
10. Юридические аспекты

Цели и задачи БД отдела ЗАГС

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

Требования к системе

2.1 Функциональные требования

• Ввод, редактирование и удаление записей (CRUD‑операции).
• Поиск по различным параметрам: ФИО, дате, номеру акта, месту регистрации.
• Генерация печатных форм (PDF, XML) в соответствии с ГОСТ.
• Ведение истории изменений (audit trail).

2.2 Нефункциональные требования

• Высокая надёжность и отказоустойчивость.
• Скорость отклика не более 2 секунд для типовых запросов.
• Масштабируемость: возможность увеличения объёма данных без потери производительности.
• Поддержка резервного копирования и восстановления.
• Соответствие требованиям ФЗ‑152 «О персональных данных».

Архитектура и типы СУБД

Для большинства отделов ЗАГС рекомендуется использовать реляционную СУБД, так как структура актов естественно представима в виде таблиц. Наиболее популярные варианты:

• PostgreSQL, открытая СУБД, поддерживает расширенные типы данных и транзакции.
• Microsoft SQL Server — удобен в среде Windows, имеет встроенные инструменты для аудита.
• MySQL / MariaDB — просты в развёртывании, подходят для небольших отделов.

В случае необходимости интеграции с государственными порталами (например, Госуслуги) часто используют REST‑API поверх СУБД.

Структура базы данных

4.1 Основные таблицы

4.2 Пример DDL (PostgreSQL)

CREATE TABLE registration_offices (
 office_id SERIAL PRIMARY KEY,
 office_name VARCHAR(150) NOT NULL,
 address TEXT,
 phone VARCHAR(20),
 email VARCHAR(100)
);

CREATE TABLE persons (
 person_id SERIAL PRIMARY KEY,
 last_name VARCHAR(100) NOT NULL,
 first_name VARCHAR(100) NOT NULL,
 middle_name VARCHAR(100),
 birth_date DATE NOT NULL,
 gender CHAR(1) CHECK (gender IN ('M','F')),
 passport_series VARCHAR(4),
 passport_number VARCHAR(6)
);

CREATE TABLE acts (
 act_id SERIAL PRIMARY KEY,
 act_type VARCHAR(20) CHECK (act_type IN ('birth','marriage','death','name_change')),
 act_number VARCHAR(30) UNIQUE NOT NULL,
 act_date DATE NOT NULL,
 registration_office_id INT REFERENCES registration_offices(office_id),
 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
 updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE act_persons (
 act_id INT REFERENCES acts(act_id) ON DELETE CASCADE,
 person_id INT REFERENCES persons(person_id) ON DELETE RESTRICT,
 role VARCHAR(30) NOT NULL,
 PRIMARY KEY (act_id, person_id, role)
);

CREATE TABLE documents (
 doc_id SERIAL PRIMARY KEY,
 act_id INT REFERENCES acts(act_id) ON DELETE CASCADE,
 file_path TEXT NOT NULL,
 file_type VARCHAR(10) NOT NULL,
 uploaded_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE audit_log (
 log_id SERIAL PRIMARY KEY,
 table_name VARCHAR(50) NOT NULL,
 record_id INT NOT NULL,
 operation VARCHAR(10) CHECK (operation IN ('INSERT','UPDATE','DELETE')),
 performed_by VARCHAR(100) NOT NULL,
 performed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
 old_value JSONB,
 new_value JSONB
);

4.3 Связи (ER‑диаграмма)

Для визуального представления можно использовать нотацию «Crow’s Foot». Основные связи:

• Один registration_office ↔ много acts.
• Один act ↔ много act_persons ↔ много persons (многие‑ко‑многим).
• Один act ↔ много documents.

Безопасность и защита данных

• Шифрование — хранить чувствительные поля (паспортные данные) в зашифрованном виде (PGP‑Symmetric, Transparent Data Encryption).
• Контроль доступа — роль‑ориентированная модель (операторы, администраторы, аудиторы). Пример ролей:
  • operator — ввод и просмотр записей.
  • supervisor — одобрение изменений, экспорт данных.
  • auditor — только чтение журнала аудита.
• Логирование — все изменения фиксируются в audit_log с указанием пользователя и времени.
• Регулярные проверки — сканирование уязвимостей, обновление патчей СУБД.

Резервное копирование и восстановление

1. Полные бэкапы раз в сутки (pg_dump, SQL Server Backup).
2. Инкрементные бэкапы каждые 2–4 часа.
3. Хранение копий в двух географически разнесённых местах (облачный сервис + локальный сервер).
4. Тестовое восстановление минимум раз в месяц.

Интеграция с другими системами

База данных ЗАГС часто взаимодействует с:

• Государственным реестром населения (ГРН).
• Системой электронных государственных услуг (Госуслуги).
• Медицинскими информационными системами (для подтверждения рождения).
• Судебными органами (для выдачи справок о браке/разводе).

Для интеграции рекомендуется использовать REST‑API с токен‑аутентификацией (OAuth 2.0) и форматами JSON/XML.

Примеры запросов

8.1 Поиск акта брака по фамилии супругов

SELECT a.act_number, a.act_date, o.office_name
FROM acts a
JOIN registration_offices o ON a.registration_office_id = o.office_id
JOIN act_persons ap1 ON a.act_id = ap1;act_id
JOIN persons p1 ON ap1.person_id = p1.person_id
JOIN act_persons ap2 ON a.act_id = ap2.act_id
JOIN persons p2 ON ap2.person_id = p2.person_id
WHERE a.act_type = 'marriage'
 AND ((p1.last_name ILIKE 'Иванов%' AND ap1.role = 'жених')
 OR (p2.last_name ILIKE 'Иванов%' AND ap2.role = 'невеста'));

8.2 Выдача выписки о рождении в PDF

-- Предполагаем, что в таблице documents хранится путь к готовому PDF
SELECT d.file_path
FROM acts a
JOIN documents d ON a.act_id = d.act_id
WHERE a.act_type = 'birth' AND a.act_number = 'BR-2025-00123';

8.3 Добавление нового акта смерти (транзакция)

BEGIN;

INSERT INTO acts (act_type, act_number, act_date, registration_office_id)
VALUES ('death', 'DE-2026-04567', '2026-07-08', 3)
RETURNING act_id INTO new_act_id;

INSERT INTO persons (last_name, first_name, middle_name, birth_date, gender,
 passport_series, passport_number)
VALUES ('Петров', 'Алексей', NULL, '1975-03-12', 'M', '45', '123456')
RETURNING person_id INTO deceased_id;

INSERT INTO act_persons (act_id, person_id, role)
VALUES (new_act_id, deceased_id, 'deceased');

COMMIT;

Лучшие практики эксплуатации

• Регулярно проводить тесты производительности (pgbench, SQL Server Profiler).
• Внедрять механизм мягкого удаления (soft delete) вместо физического DELETE, чтобы сохранять историю.
• Обеспечить унификацию форматов дат (ISO 8601) и кодировок (UTF‑8).
• Документировать все изменения схемы (DDL‑скрипты в системе контроля версий).
• Проводить обучение персонала по работе с системой и правилам защиты персональных данных.

Юридические аспекты

Работа с данными ЗАГС подпадает под действие нескольких нормативных актов РФ:

• ФЗ № 152‑2013 «О персональных данных», обязательное согласие субъекта, шифрование, журналирование.
• ФЗ № 115‑2002 «О государственной регистрации актов гражданского состояния» — требования к формату и срокам хранения записей (не менее 75 лет).
• ГОСТ Р 7.0.97‑2016 «Электронный документ. Требования к структуре и оформлению» — стандарты формирования электронных актов.

Для соответствия этим требованиям необходимо:

1. Вести реестр согласий (таблица consents).
2. Обеспечить доступность записей в течение установленного срока, используя архивные хранилища.
3. Проводить регулярные аудиты соответствия (внутренние и внешние).

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

При внедрении рекомендуется:

1. Сформировать техническое задание с учётом локальных особенностей (количество актов, интеграционные точки).
2. Выбрать СУБД, соответствующую требованиям к масштабируемости и поддержке шифрования.
3. Разработать и протестировать миграцию данных из бумажных архивов.
4. Обеспечить обучение персонала и документировать все бизнес‑процессы.

Только комплексный подход позволит отделу ЗАГС работать в полном соответствии с современными стандартами и ожиданиями граждан.