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

+7 (800) 301-07-30

Реклама jurik.ru

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

Что такое электронный архив?

Электронный архив (ЭА) – это комплекс программных и аппаратных средств, обеспечивающих:

Надёжное хранение оригинальных файлов (PDF, DOCX, JPG и др.).
Управление версиями документов.
Контроль доступа и аудит действий пользователей.
Поиск по метаданным и полному тексту.
Интеграцию с другими ИТ‑системами (ERP, CRM, документооборотом).

Все перечисленные функции реализуются при помощи реляционной СУБД (PostgreSQL, MySQL, MS SQL Server) или NoSQL‑решений (MongoDB, Elasticsearch). Ниже будет показан пример на базе PostgreSQL, который подходит для большинства корпоративных задач.

Основные требования к базе данных электронного архива

Нормализация данных – минимизация избыточности, обеспечение целостности.
Поддержка версионирования – каждый документ может иметь несколько версий.
Контроль доступа – разграничение прав чтения/записи для разных ролей.
Журналирование – запись всех действий (создание, изменение, удаление).
Масштабируемость – возможность хранить миллионы записей без потери производительности.
Поиск – быстрый поиск по метаданным и, при необходимости, по полному тексту.

Типовая схема базы данных электронного архива

Ниже представлена примерная схема из пяти основных таблиц:

documents – справочник всех документов.
document_versions – версии файлов.
metadata – произвольные метаданные (типы, теги, даты).
users – пользователи системы.
access_log – журнал доступа.

Таблица `documents`

CREATE TABLE documents (
 doc_id BIGSERIAL PRIMARY KEY,
 title VARCHAR(255) NOT NULL,
 description TEXT,
 created_at TIMESTAMP WITHOUT TIME ZONE DEFAULT now,
 created_by BIGINT REFERENCES users(user_id),
 is_active BOOLEAN DEFAULT TRUE
);

Таблица `document_versions`

CREATE TABLE document_versions (
 version_id BIGSERIAL PRIMARY KEY,
 doc_id BIGINT REFERENCES documents(doc_id) ON DELETE CASCADE,
 version_number INTEGER NOT NULL,
 file_path VARCHAR(500) NOT NULL, -- путь к файлу в файловой системе или объектному хранилищу
 file_hash CHAR(64) NOT NULL, -- SHA‑256 для проверки целостности
 uploaded_at TIMESTAMP WITHOUT TIME ZONE DEFAULT now,
 uploaded_by BIGINT REFERENCES users(user_id),
 is_current BOOLEAN DEFAULT FALSE,
 CONSTRAINT uq_doc_version UNIQUE (doc_id, version_number)
);

Таблица `metadata`

CREATE TABLE metadata (
 meta_id BIGSERIAL PRIMARY KEY,
 doc_id BIGINT REFERENCES documents(doc_id) ON DELETE CASCADE,
 meta_key VARCHAR(100) NOT NULL,
 meta_value TEXT,
 CONSTRAINT uq_doc_meta UNIQUE (doc_id, meta_key)
);

Таблица `users`

CREATE TABLE users (
 user_id BIGSERIAL PRIMARY KEY,
 username VARCHAR(100) UNIQUE NOT NULL,
 password_hash CHAR(64) NOT NULL,
 full_name VARCHAR(200),
 role VARCHAR(50) NOT NULL, -- admin, archivist, viewer и т.д.
 created_at TIMESTAMP WITHOUT TIME ZONE DEFAULT now
);

Таблица `access_log`

CREATE TABLE access_log (
 log_id BIGSERIAL PRIMARY KEY,
 user_id BIGINT REFERENCES users(user_id),
 doc_id BIGINT REFERENCES documents(doc_id),
 action_type VARCHAR(20) NOT NULL, -- VIEW, DOWNLOAD, EDIT, DELETE
 action_time TIMESTAMP WITHOUT TIME ZONE DEFAULT now,
 ip_address INET
);

Пример работы с базой данных

Добавление нового документа

-- 1. Создаём запись в таблице documents
INSERT INTO documents (title, description, created_by)
VALUES ('Отчёт о продажах за Q1 2026', 'Финансовый отчёт', 12) -- 12 – id пользователя
RETURNING doc_id;
-- Предположим, получен doc_id = 101

-- 2. Добавляем первую версию файла
INSERT INTO document_versions (doc_id, version_number, file_path, file_hash, uploaded_by, is_current)
VALUES (101, 1, '/archive/2026/Q1_sales_report_v1.pdf',
 'a3f5c2e9d4b6... (SHA‑256)', 12, TRUE);

-- 3. Добавляем метаданные
INSERT INTO metadata (doc_id, meta_key, meta_value)
VALUES
 (101, 'department', 'Finance'),
 (101, 'year', '2026'),
 (101, 'quarter', 'Q1');

Поиск документов по метаданным

SELECT d.doc_id, d.title, d.created_at, m.meta_key, m.meta_value
FROM documents d
JOIN metadata m ON d.doc_id = m.doc_id
WHERE m.meta_key = 'department' AND m.meta_value = 'Finance'
 AND d.is_active = TRUE
ORDER BY d.created_at DESC;

Получение текущей версии документа

SELECT dv.file_path, dv.file_hash, dv.uploaded_at, u.full_name AS uploader
FROM document_versions dv
JOIN users u ON dv.uploaded_by = u.user_id
WHERE dv.doc_id = 101 AND dv.is_current = TRUE;

Регистрация действия пользователя (журналирование)

INSERT INTO access_log (user_id, doc_id, action_type, ip_address)
VALUES (12, 101, 'VIEW', '203.0.113.45');

Практический пример: «Alee Архив 3»

Компания Alee Software выпустила версию Alee Архив 3, в которой реализована поддержка:

Хранения файлов в облачном объектном хранилище (Amazon S3, Azure Blob).
Автоматического расчёта SHA‑256 хеша для каждой версии.
Интеграции с LDAP/Active Directory для управления ролями.
Полнотекстового поиска через Elasticsearch.

Ниже показан упрощённый SQL‑скрипт, который можно импортировать в PostgreSQL и сразу начать работу с «Alee Архив 3»:

-- Пользователи
INSERT INTO users (username, password_hash, full_name, role)
VALUES
 ('admin', '5e884898da28047151d0e56f8dc6292773603d0d6aabbdd', 'Иван Иванов', 'admin'),
 ('archivist1', '2c1743a391305fbf367df8e4f069f9f9', 'Мария Петрова', 'archivist');

-- Пример документа
INSERT INTO documents (title, description, created_by)
VALUES ('Техническое задание на проект X', 'ТЗ проекта X, версия 1.0', 2)
RETURNING doc_id; -- получаем, например, 200

INSERT INTO document_versions (doc_id, version_number, file_path, file_hash, uploaded_by, is_current)
VALUES (200, 1, '/archive/projectX/TZ_v1.docx', 'd2d2d2d2...', 2, TRUE);

INSERT INTO metadata (doc_id, meta_key, meta_value)
VALUES
 (200, 'project', 'X'),
 (200, 'type', 'ТЗ'),
 (200, 'status', 'approved');

После выполнения этих запросов в системе появятся:

Пользователь archivist1 с правами архивариуса.
Документ «Техническое задание на проект X» с первой версией и набором метаданных.

Лучшие практики проектирования БД электронного архива

Разделяйте файлы и метаданные. Физические файлы хранятся в файловой системе или объектном хранилище, а в БД сохраняются только ссылки и контрольные суммы.
Используйте индексы. На полях doc_id, meta_key, meta_value и created_at создавайте отдельные индексы для ускорения поиска.
Обеспечьте целостность данных. Включайте внешние ключи и ограничения UNIQUE (например, уникальный номер версии).
Храните историю изменений. Не удаляйте записи, а помечайте их как неактивные (is_active = FALSE) и сохраняйте в журнале.
Шифруйте конфиденциальные данные; Пароли, токены и, при необходимости, сами файлы должны быть зашифрованы.
Регулярно делайте резервные копии. Для БД – pg_dump/pg_basebackup, для файлов – копии в отдельном хранилище;

База данных электронного архива – это «костяк», без которого невозможно обеспечить надёжное хранение, поиск и контроль доступа к цифровым документам. В статье мы рассмотрели:

Ключевые требования к такой базе.
Типовую схему из пяти таблиц с примерами DDL‑операций.
Практические запросы для добавления, поиска и журналирования.
Конкретный пример реализации в продукте Alee Архив 3.
Рекомендации по оптимизации и безопасности.

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

Помните: правильная модель данных – залог эффективности всей системы.