Бесплатная консультация юриста

+7 (800) 301-07-30

Реклама jurik.ru

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

Архитектурные подходы к построению ЭА

Согласно общепринятой классификации‚ выделяют два фундаментальных направления построения электронных архивов‚ которые определяют архитектуру БД:

Атрибутный (классический) подход — Корпоративный электронный архив. Основан на структурированных данных и атрибутном поиске. Документ описывается набором метаданных (реквизитов): автор‚ дата‚ вид‚ номер‚ срок хранения‚ ключевые слова. Примеры систем: DOCS Open‚ XDOC‚ SoftSolution‚ PaperWise‚ 1С:Документооборот. Это направление доминирует в делопроизводстве и ECM-системах.
Полнотекстовый подход. Основан на индексировании полного текста документов (база законов‚ нормативных актов‚ научных публикаций). Поиск осуществляется по содержимому‚ а не только по карточке; Часто используется в сочетании с атрибутным (гибридные системы).

Важно: Современные промышленные решения (ECM‚ СЭД) почти всегда реализуют гибридную модель: структурированная БД метаданных + полнотекстовый поисковый движок (Elasticsearch‚ Sphinx‚ встроенные средства СУБД) + файловое хранилище бинарных объектов.

Двухуровневая физическая архитектура: БД + Файловое хранилище

Ключевой принцип проектирования — разделение хранения метаданных (карточек) и тело документа (файлов).

База данных под управлением СУБД (Metadata Store)

Хранит структурированную информацию: карточки документов‚ справочники‚ права доступа‚ протоколы аудита‚ связи между объектами. Используются реляционные СУБД (PostgreSQL‚ MS SQL Server‚ Oracle‚ SQLite для малых архивов).

Преимущества: ACID-транзакции‚ сложные выборки (SQL)‚ целостность ссылок‚ версионирование метаданных‚ масштабируемость.

Файловое хранилище (Content Store / BLOB Storage)

Хранит сами файлы (PDF‚ TIFF‚ JPG‚ DWG‚ видео‚ аудио). Доступ к файлам осуществляется не напрямую через файловую систему ОС‚ а через API архива.

Объектное хранилище (S3-совместимые): MinIO‚ AWS S3‚ Yandex Object Storage — стандарт для современных облачных и on-premise решений. Обеспечивает версионирование‚ репликацию‚ жизненный цикл (ILM).
Файловая система с дедупликацией: Для legacy-систем.
Хранение в БД (BLOB): Допустимо только для малых объемов (до нескольких ТБ)‚ так как раздувает БД‚ усложняет бэкап и репликацию.

Практика 1С:Документооборот: «Карточки документов хранятся в базе данных под управлением СУБД‚ а файлы‚ прикрепленные к карточкам‚ хранятся отдельно в специальном файловом хранилище».

Логическая структура: Метаданные и Классификация

«Структурирование данных — благодаря электронному архиву документы теперь можно систематизировать для своего удобства. Сортировать документацию возможно по виду и сроку хранения‚ а также по любым другим критериям».

Система классификации (Номенклатура дел / Классификатор)

Это «скелет» архива. В БД реализуется как иерархическая структура (дерево) с неограниченной вложенностью.

Уровни: Фوند → Опись → Дело / Том → Документ (или: Категория → Подкатегория → Вид документа).
Множественные разрезы (фасеты): Современные системы позволяют навигировать по разным измерениям одновременно:
- По папкам хранения (физическая/логическая структура сервера).
- По вопросам деятельности (функциональный классификатор).
- По видам документов (договор‚ акт‚ приказ‚ письмо).

Карточка документа (Набор реквизитов / Профиль метаданных)

Каждому виду документа соответствует свой набор атрибутов (схема). В БД это реализуется через таблицы: DocumentTypes‚ Attributes‚ DocumentAttributeValues (EAV-модель) или жесткую схему (отдельные таблицы/колонки для каждого типа).

Обязательные системные реквизиты (по рекомендациям Росархива и ГОСТ Р 7.0.100-2018):

Уникальный идентификатор (UID / GUID): «Присвоение каждому документу уникального идентификационного номера». Первичный ключ.
Идентификатор версии: Для версионирования.
Ссылка на классификатор (ID папки/вида): Внешний ключ.
Реквизиты идентификации: Номер‚ Дата регистрации‚ Вид документа‚ Тема/Наименование.
Контекстные реквизиты: Автор‚ Исполнитель‚ Организация-корреспондент‚ Номер исходящего/входящего.
Атрибуты хранения: Срок хранения (временный/постоянный)‚ Категория ценности‚ Дата акта экспертизы.
Атрибуты файла: Хэш-сумма (SHA-256) для контроля целостности‚ MIME-тип‚ Размер‚ Путь в хранилище (Object Key)‚ Количество листов.
Статусы и этапы ЖЦ: Черновик‚ На согласовании‚ Утвержден‚ В архиве‚ На уничтожении.
Права доступа (ACL): Связь с матрицей ролей/пользователей.

Иерархические связи и виртуальные папки

«Можно создать сложную иерархическую структуру из физических и виртуальных папок для хранения данных‚ настроить связи между файлами в архиве».

Физические папки: Отражают реальное размещение в хранилище (шардинг по дате/типу).
Виртуальные папки / Представления (Views): Динамические выборки (Saved Queries)‚ не дублирующие файлы. Пример: «Все договоры 2024 года»‚ «Документы на согласовании у Иванова».
Связи между документами: Графовые структуры (Parent-Child‚ Related‚ Supersedes‚ Attachment). Реализуются таблицей связей DocumentLinks (SourceID‚ TargetID‚ LinkType).

Структура БД: Основные сущности (ER-диаграмма в тексте)

Ниже приведена типичная нормализованная схема для реляционной СУБД.

Справочники (Reference Data)

Classificators (Классификаторы/Номенклатуры): ID‚ ParentID‚ Code‚ Name‚ RetentionPeriodID‚ IsVirtual.
DocumentTypes (Виды документов): ID‚ ClassificatorID‚ Name‚ AttributeSchemaID‚ NumberingRuleID.
Attributes (Атрибуты/Реквизиты): ID‚ TypeID‚ Name‚ DataType (String‚ Date‚ Ref‚ Integer‚ Bool)‚ IsRequired‚ IsSearchable‚ ValidationRegex.
RetentionPeriods (Сроки хранения): ID‚ Years‚ Action (Destroy‚ TransferToStateArchive‚ Review).
Organizations / Contacts (Контрагенты/Сотрудники): Интеграция с AD/LDAP/HR-системами.

Транзакционные таблицы (Transactional Data)

Documents (Карточки документов):

ID (PK‚ UUID)‚ VersionID‚ DocumentTypeID‚ ClassificatorNodeID‚
StatusID‚ RegistrationNumber‚ RegDate‚ Title‚
AuthorID‚ CreatorID‚ CreatedAt‚
CurrentFileID (FK to Files)‚ HashSum‚ SizeBytes‚
RetentionPeriodID‚ DispositionDate‚ // Дата реализации срока
ACL_ID (FK to AccessControlList)

DocumentAttributes (Значения реквизитов — EAV или JSONB):
```
DocumentID‚ AttributeID‚ ValueString‚ ValueDate‚ ValueRefID‚ ValueNumber‚ ValueJson
```
Современный подход: использование JSONB (PostgreSQL) или JSON (MS SQL) для гибких схем без джойнов.

Files (Файлы / Версии файлов):

ID‚ DocumentID‚ VersionNum‚ StorageProviderID‚ ObjectKey (Path in S3)‚
MimeType‚ Size‚ HashSHA256‚ PageCount‚
CreatedAt‚ CreatedByID‚ IsPrimary (основной PDF/оригинал)

DocumentLinks (Связи): SourceDocID‚ TargetDocID‚ LinkTypeID (Parent‚ Attachment‚ Resolution‚ Copy).

Системные / Служебные таблицы

AuditLog / EventStore: Неизменяемый журнал всех действий (Кто‚ Что‚ Когда‚ Старое значение‚ Новое значение). Критично для правовой значимости и расследований. «Можно посмотреть эти данные‚ сформировать отчёты по действиям пользователей в архиве».
SearchIndexQueue / FullTextIndex: Таблица для синхронизации с поисковым движком.
Tasks / Workflows: Задачи согласования‚ подписания‚ экспертизы.
DigitalSignatures (ЭП): Хранение отсоединенных подписей (CAdES/XAdES)‚ сертификатов‚ отметок времени‚ результатов проверки.

Обеспечение целостности‚ безопасности и масштабируемости

Целостность и Аутентичность

Хеширование: SHA-256 для каждого файла и подписи. Проверка по расписанию (Fixity Check).
Электронная подпись (КЭП): Хранение подписей в БД (таблица Signatures) с привязкой к версии файла. Поддержка долгосрочных форматов (CAdES-A‚ PAdES-LTV).
Журнал аудита (WORM): Таблица аудита должна быть «append-only» (только вставка)‚ защищенная от админов БД (Row Level Security‚ триггеры запрета UPDATE/DELETE).

Масштабируемость и Производительность

Партиционирование (Partitioning): Таблицы Documents‚ AuditLog‚ DocumentAttributes секционируются по дате (месяц/год) или ID классификатора.
Индексация: Составные индексы под частые отчеты (Status + Date + Author). GIN-индексы для JSONB и полнотекстового поиска (tsvector).
Шардинг хранилища: Распределение файлов по нескольким S3-бакетам/нодам MinIO.
Read Replicas: Отчетная нагрузка и поиск считываются с реплик‚ не блокируя запись.

Защита персональных данных (152-ФЗ / GDPR)

Шифрование данных в покое (TDE / LUKS / S3 SSE-KMS) и в движении (TLS 1.3).
Псевдонимизация/Токенизация ПДн в аналитических копиях БД.
Ролевая модель доступа (RBAC/ABAC) на уровне строк (RLS) в СУБД.

Специфика отраслевых архивов (Примеры)

Тип архива	Особенности структуры БД
Кадровый архив	Строгая привязка к физлицу (Сотрудник). Сложные временные срезы (История изменений должности‚ зарплаты). Долгосрочное хранение (75 лет). Интеграция с ЗУП/HRM.
Договорной / Юридический	Граф связей: Договор → Доп. соглашения → Счета → Акты → Переписка. Версионирование текста договора (Redline). Контроль этапов: Проект → Согласование → Подписание → Исполнение.
Технический / Проектный (PLM/PDM)	Хранение CAx-файлов (SolidWorks‚ AutoCAD‚ Revit). Связи «Сборка, Деталь»‚ «Чертеж — Спецификация». Управление конфигурациями (Baselines). Метаданные: Ревизия‚ Стадия (П‚ Р‚ И)‚ Формат (A1‚ A3).
Архив ЭДО (Операторы ЭДО)	«Общая база данных включает сразу все документы с ЭП от операторов ЭДО‚ отсканированные копии бумажных носителей». Парсинг XML/JSON (УПД‚ УКД‚ СЧФ) в реквизиты БД автоматически. Хранение конвертов (Envelopes) и квитанций.

Современные тренды: ECM‚ Cloud-Native и Low-Code

«Самый продвинутый способ организовать архив в рамках системы электронного документооборота (СЭД) или платформы ECM».

Headless ECM / API-first: БД инкапсулирована за микросервисами (Document Service‚ Search Service‚ Retention Service). Фронтенд (Web‚ Mobile‚ 1C‚ SAP) обращается через REST/GraphQL/gRPC.
Kubernetes / Operator Pattern: Развертывание СУБД (PostgreSQL Operator)‚ MinIO‚ Search как StatefulSets. Автобэкапы‚ Point-in-Time Recovery (PITR).
Low-Code конфигурация схемы: Администратор создает виды документов‚ реквизиты‚ правила нумерации и жизненные циклы через UI‚ не меняя схему БД вручную (метаданные генерируют DDL или используют JSONB).
AI/ML интеграция: Колонки в БД для векторных эмбеддингов (pgvector) для семантического поиска‚ автоклассификации (BERT/LLM) и извлечения сущностей (NER) при загрузке.

Чек-лист проектирования структуры БД ЭА

[ ] Выбрана СУБД (PostgreSQL — лучший баланс открытости‚ JSONB‚ полнотекст‚ партиционирование).
[ ] Разделено хранение: Метаданные в БД‚ Файлы в S3-совместимом хранилище.
[ ] Спроектирована иерархия классификатора (Номенклатура) с поддержкой множественных фасетов.
[ ] Определены профили метаданных (схемы реквизитов) для каждого вида документа.
[ ] Внедрены UID (UUID v7) для всех сущностей;
[ ] Реализовано версионирование документов и файлов.
[ ] Настроена таблица связей (Graph) для отражения бизнес-процессов.
[ ] Создана неизменяемая таблица аудита (WORM) с защитой от привилегированных пользователей.
[ ] Интегрирован полнотекстовый поиск (PostgreSQL tsvector + Elasticsearch/OpenSearch для масштаба).
[ ] Реализованы политики хранения (Retention Policies) как автоматизированные джобы (Legal Hold‚ Destruction‚ Transfer).
[ ] Обеспечено шифрование (At Rest‚ In Transit) и RLS для ПДн/Гостайны.
[ ] Подготовлена схема миграции/обмена данными (XML/JSON по стандартам Росархива / ISAD(G)).

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

Разделение ответственности: СУБД для структуры и логики‚ Объектное хранилище для контента.
Гибкость схемы: JSONB/EAV для адаптации под меняющиеся регламенты без простоев.
Неизменяемость аудита: Гарантия доверия к архиву.
Стандартизация метаданных: Соответствие требованиям Росархива и ГОСТ для интероперабельности.

Грамотная архитектура на старте позволяет избежать дорогой миграции данных через 3-5 лет‚ когда объем архива исчисляется десятками миллионов карточек и терабайтами файлов‚ а требования регуляторов становятся строже.

Архитектурные подходы к построению электронного архива и структура базы данных