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

Общие принципы проектирования БД электронного архива

• Уникальность имён полей. Каждое поле таблицы имеет уникальное имя, позволяющее однозначно идентифицировать его в запросах.
• Типизация данных. Поле хранит данные только одного типа (число, строка, дата, время и т.п.). Это обеспечивает целостность и упрощает индексацию.
• Нормализация. Для уменьшения избыточности данных рекомендуется проводить нормализацию до 3‑й нормальной формы, что обычно приводит к 5‑7 таблицам.
• Контроль целостности. Первичные и внешние ключи, ограничения NOT NULL, UNIQUE, CHECK гарантируют согласованность данных.
• Масштабируемость и производительность. Индексы, партиционирование и оптимизация запросов позволяют работать с миллионами записей.

Жизненный цикл документа в архиве

1. Регистрация (загрузка) документа.
2. Метаданные: заполнение полей описания, классификации, прав доступа.
3. Контроль версий и изменение статуса (активный, архивный, удалённый).
4. Хранение в физическом хранилище (файловая система, объектное хранилище).
5. Поиск и извлечение.
6. Уничтожение (по истечении срока хранения).

Логическая структура базы данных

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

Основные сущности

Связи между таблицами

• Document ↔ DocumentMeta – связь один‑ко‑одному (PK ↔ FK). Метаданные могут быть вынесены в отдельную таблицу для гибкой схемы.
• Document ↔ DocumentVersion – связь один‑ко‑многим. Одна запись в Document может иметь несколько версий.
• Document ↔ AccessRule – один‑ко‑многим. Для каждого документа может быть несколько правил доступа.
• AccessRule ↔ Subject – внешний ключ, указывающий, кому принадлежит правило.
• Document ↔ ArchivePolicy – один‑ко‑одному или один‑ко‑многим (в зависимости от требований к политике).

Ограничения и индексы

Для обеспечения целостности и ускорения запросов рекомендуется:

• Установить PRIMARY KEY на все идентифицирующие поля.
• Создать UNIQUE индексы на Document.Path (чтобы не было дублирования файлов).
• Индексы по полям поиска: Title, Author, Keywords, DocDate.
• Внешние ключи (FOREIGN KEY) с ON DELETE CASCADE для автоматического удаления связанных записей.
• Ограничения CHECK для контроля формата дат, размеров файлов и допустимых значений PermissionType.

Физическая структура и хранение файлов

База данных хранит только метаданные и ссылки на физические файлы. Файлы могут располагаться:

1. В файловой системе сервера (путь хранится в поле FilePath).
2. В объектных хранилищах (Amazon S3, Azure Blob, Google Cloud Storage) – в этом случае в базе хранится URI.
3. В специализированных системах хранения (WORM‑устройства) для обеспечения неизменности.

Для обеспечения надёжности рекомендуется использовать:

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

Пример ER‑диаграммы

Ниже представлена упрощённая ER‑диаграмма, отражающая основные сущности и их связи.

+----------------+ 1 +-------------------+
| Document |------------| DocumentMeta |
+----------------+ +-------------------+
| PK DocumentID | | PK MetaID |
| FilePath | | FK DocumentID |
| FileSize | | Title |
| MimeType | | Author |
| CreatedDate | | ... |
+----------------+ +-------------------+
 1 N
Document ------------ DocumentVersion
 1 N
Document ------------ AccessRule
 N 1
AccessRule ---------- Subject
 1 1
Document ------------ ArchivePolicy

Практические рекомендации при проектировании

Планирование требований

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

• Объём и типы документов (текст, изображения, видео).
• Требования к поиску (по полному тексту, метаданным, датам).
• Политики безопасности и аудита.
• Сроки хранения и правила уничтожения.

Выбор СУБД

Для большинства архивных решений подходят реляционные СУБД (PostgreSQL, MS SQL Server, Oracle). При необходимости гибкой схемы можно использовать гибридные решения (PostgreSQL + JSONB, MongoDB).

Нормализация vs. денормализация

Нормализованные таблицы упрощают поддержку и обеспечивают целостность, однако для часто используемых запросов (поиск по ключевым словам) может потребоваться денормализованная «таблица поиска», содержащую предвычисленные индексы.

Индексация и полнотекстовый поиск

Для ускорения поиска рекомендуется:

• Создать полнотекстовые индексы (PostgreSQL GIN на поле DocumentMeta.Title и DocumentMeta.Description).
• Использовать внешние движки (Elasticsearch, Solr) и синхронизировать их с основной БД.

Безопасность

Ключевые меры:

• Шифрование данных в покое (Transparent Data Encryption).
• Контроль доступа на уровне строк (Row‑Level Security) – пользователи видят только те документы, на которые у них есть права.
• Аудит операций (логирование INSERT/UPDATE/DELETE).

Архивирование и удаление

Политика ArchivePolicy должна автоматически переводить документы в «архивный» статус, а после истечения RetentionPeriod – инициировать безопасное уничтожение (удаление файлов и очистка записей).

Пример DDL‑скрипта (PostgreSQL)

CREATE TABLE Subject (
 SubjectID SERIAL PRIMARY KEY,
 SubjectType VARCHAR(20) NOT NULL, -- 'User' or 'Group'
 Name VARCHAR(100) NOT NULL UNIQUE
);
CREATE TABLE Document (
 DocumentID SERIAL PRIMARY KEY,
 FilePath TEXT NOT NULL,
 FileSize BIGINT NOT NULL,
 MimeType VARCHAR(50) NOT NULL,
 CreatedDate TIMESTAMP NOT NULL DEFAULT now
);

CREATE TABLE DocumentMeta (
 MetaID SERIAL PRIMARY KEY,
 DocumentID INT NOT NULL REFERENCES Document(DocumentID) ON DELETE CASCADE,
 Title VARCHAR(255) NOT NULL,
 Author VARCHAR(150),
 Description TEXT,
 Keywords TEXT,
 DocDate DATE,
 CONSTRAINT uq_doc_title UNIQUE (DocumentID, Title)
);

CREATE TABLE DocumentVersion (
 VersionID SERIAL PRIMARY KEY,
 DocumentID INT NOT NULL REFERENCES Document(DocumentID) ON DELETE CASCADE,
 VersionNumber INT NOT NULL,
 VersionDate TIMESTAMP NOT NULL DEFAULT now,
 ChangedBy INT NOT NULL REFERENCES Subject(SubjectID),
 CONSTRAINT uq_version UNIQUE (DocumentID, VersionNumber)
);

CREATE TABLE AccessRule (
 RuleID SERIAL PRIMARY KEY,
 DocumentID INT NOT NULL REFERENCES Document(DocumentID) ON DELETE CASCADE,
 SubjectID INT NOT NULL REFERENCES Subject(SubjectID),
 PermissionType VARCHAR(10) NOT NULL CHECK (PermissionType IN ('READ','WRITE','DELETE'))
);

CREATE TABLE ArchivePolicy (
 PolicyID SERIAL PRIMARY KEY,
 DocumentID INT NOT NULL REFERENCES Document(DocumentID) ON DELETE CASCADE,
 RetentionPeriod INTERVAL NOT NULL,
 DisposalDate DATE,
 Status VARCHAR(20) NOT NULL CHECK (Status IN ('ACTIVE','ARCHIVED','DISPOSED'))
);

Данный скрипт иллюстрирует основные принципы: уникальные имена полей, типизацию, первичные и внешние ключи, ограничения CHECK и уникальность.

Структура базы данных электронного архива должна быть продумана с учётом требований к целостности, безопасности и масштабируемости. Ключевые элементы – это таблицы Document, DocumentMeta, DocumentVersion, AccessRule, Subject и ArchivePolicy. Правильное использование первичных и внешних ключей, индексов и ограничений обеспечивает надёжную работу системы, а гибкая схема позволяет адаптировать архив под новые типы документов и бизнес‑процессы.

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