Аннотация. Статья представляет собой детальное методическое руководство по организации и проведению судебной экспертизы баз данных (БД) в рамках арбитражного процесса. Сформулирован комплексный алгоритм исследования, включающий фазы планирования, криминалистического сбора данных, многомерного технического анализа и синтеза доказательной информации. Подробно рассмотрены специализированные методики: ретроспективного восстановления данных, анализа журнальной регистрации, верификации бизнес-логики, установления цепочек взаимосвязей и выявления аномалий. На реальных кейсах из практики арбитражных судов продемонстрировано применение методик в спорах о неисполнении IT-договоров, корпоративных конфликтах, делах о банкротстве, налоговых спорах и защите интеллектуальной собственности. Приведена структурированная система вопросов, позволяющая трансформировать технические задачи в юридически значимые выводы. Материал предназначен для судебных экспертов, IT-аудиторов, юристов, специализирующихся на цифровых доказательствах, и арбитражных управляющих.

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

ВВЕДЕНИЕ. МЕТОДИЧЕСКИЙ ВЫЗОВ: ОТ НЕСТРУКТУРИРОВАННЫХ ДАННЫХ К ДОКАЗАТЕЛЬСТВЕННОЙ БАЗЕ

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

ГЛАВА 1. КОМПЛЕКСНЫЙ АЛГОРИТМ ПРОВЕДЕНИЯ ЭКСПЕРТИЗЫ БАЗ ДАННЫХ

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

ЭТАП 1. ПРЕДЭКСПЕРТНАЯ ПОДГОТОВКА И ПЛАНИРОВАНИЕ

1.1. Анализ материалов дела и постановки вопроса. Эксперт изучает исковое заявление, договор, техническое задание, акты, претензионную переписку. Формируется первичный глоссарий терминов и список ключевых дат, лиц, объектов (например, «договор №45 от 01.02.2023», «модуль отчетности», «контрагент ООО “Вектор”»).

1.2. Определение границ исследования. На основании вопросов суда/сторон определяется временной диапазон, перечень исследуемых объектов БД (конкретные таблицы, схемы, пользователи), необходимость анализа внешних систем.

1.3. Выбор инструментария. В зависимости от типа СУБД (Microsoft SQL Server, PostgreSQL, Oracle, 1С, MySQL) подбирается ПО: средства подключения и администрирования (SSMS, pgAdmin, Toad), инструменты для ETL (Extract, Transform, Load) и анализа данных (SQL-редакторы, Python с библиотеками pandas, sqlalchemy), средства визуализации (Power BI, Tableau для построения диаграмм взаимосвязей), софт для сравнения схем и данных (Redgate SQL Compare, ApexSQL Diff).

ЭТАП 2. КРИМИНАЛИСТИЧЕСКИЙ СБОР И ВЕРИФИКАЦИЯ ОБРАЗОВ ДАННЫХ

2.1. Получение и фиксация исходных артефактов. Работа ведется с образами дисков, резервными копиями БД (.bak, .dump), экспортами в SQL. Критически важно зафиксировать хэш-суммы (SHA-256) полученных файлов.

2.2. Воссоздание изолированного тестового окружения. БД разворачивается на выделенном сервере или в виртуальной машине. Цель — исключить влияние на производственные системы и обеспечить воспроизводимость результатов.

2.3. Базовый аудит целостности. Проверка консистентности БД штатными средствами СУБД (например, DBCC CHECKDB), анализ наличия и целостности основных таблиц. Создание снимка (snapshot) системы на начальном этапе.

ЭТАП 3. СТРУКТУРНЫЙ АНАЛИЗ И РЕКОНСТРУКЦИЯ МЕТАМОДЕЛИ

3.1. Экстракция метаданных. Автоматизированное извлечение информации о всех объектах схемы: таблицы, колонки, типы данных, первичные и внешние ключи, индексы, представления (VIEWS), синонимы. Используются системные каталоги (INFORMATION_SCHEMA, sys.*).

3.2. Построение ER-диаграммы (Entity-Relationship). Визуализация связей между сущностями. Это фундамент для понимания предметной области. Пример для спора о поставках: Контрагент —(1:N)→ Договор —(1:N)→ Накладная —(1:N)→ ПозицияТовара.

3.3. Анализ бизнес-правил на уровне схемы. Выявление CHECK-ограничений, UNIQUE-индексов, значений по умолчанию (DEFAULT). Например, ограничение CHECK (order_amount > 0) фиксирует бизнес-правило.

ЭТАП 4. СОДЕРЖАТЕЛЬНЫЙ АНАЛИЗ

4.1. Профилирование данных. Статистический анализ содержания таблиц: количество записей, распределение значений, процент NULL-значений, минимальные/максимальные даты. Выявление аномалий: пустые ключевые таблицы, тестовые данные в рабочих системах.

4.2. Верификация расчетных показателей. Для спорных сумм, процентов, количеств выполняются контрольные расчеты на основе исходных данных и сравнение с хранимыми в БД значениями. SQL-запросы вида: SELECT SUM(calculated_value) as calculated, SUM(stored_value) as stored FROM … HAVING calculated != stored.

4.3. Ретроспективный срез (Temporal Analysis). Если БД поддерживает темпоральность или есть история изменений, восстанавливается состояние данных на ключевую дату (дату спора, проверки, сделки). Используется SELECT … AS OF TIMESTAMP … или анализ журналов.

ЭТАП 5. АНАЛИЗ ПРОГРАММНОЙ ЛОГИКИ (КОДОВАЯ БАЗА)

5.1. Инвентаризация программных модулей. Составление реестра хранимых процедур (Stored Procedures), функций (Functions), триггеров (Triggers), пакетов (Packages).

5.2. Статический анализ исходного кода. Изучение текстов модулей. Цели:

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

Поиск «закладок», условий, срабатывающих при таких обстоятельствах (например, IF @client_id = 100 THEN …).

Анализ внешних вызовов (веб-сервисы, команды ОС) для установления интеграций.

5.3. Сравнение кода с эталоном. Если есть две версии БД (до и после изменений), проводится сравнение кода процедур для выявления внесенных правок (например, изменили алгоритм расчета после начала спора).

ЭТАП 6. ФОРЕНСИК-АНАЛИЗ ПОЛЬЗОВАТЕЛЬСКОЙ АКТИВНОСТИ

6.1. Аудит штатных средств СУБД. Анализ журналов транзакций, логов ошибок, следов SQL-аудита (если включен). Поиск записей о DDL-операциях (CREATE, ALTER, DROP) и критических DML-операциях (UPDATE, DELETE).

6.2. Анализ пользовательских журналов. Исследование таблиц прикладного аудита, которые часто создаются разработчиками (например, audit_log, history_table). Восстановление цепочки «кто, когда, что сделал».

6.3. Корреляция событий. Сопоставление времени операций в БД с другими цифровыми артефактами (логами почтового сервера о рассылке уведомлений, записями системы контроля доступа).

ЭТАП 7. СИНТЕЗ, ФОРМИРОВАНИЕ ВЫВОДОВ И ОТЧЕТНОСТИ

7.1. Сопоставление данных из разных источников. Перекрестная проверка: соответствуют ли данные в операционных таблицам данным в отчетных представлениях? Соответствует ли реализованная в коде логика заявленным в ТЗ требованиям?

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

7.3. Структурированное написание заключения. Четкое соответствие разделам исследования, однозначные ответы на вопросы, приложения с исходными данными для возможной проверки.

ГЛАВА 2. СПЕЦИАЛЬНЫЕ МЕТОДИКИ ДЛЯ РЕШЕНИЯ ТИПОВЫХ ЗАДАЧ АРБИТРАЖНЫХ СПОРОВ

2.1. Методика верификации выполнения работ по договору разработки/внедрения ПО.

Цель: Установить соответствие поставленного программного продукта (в форме БД и кода) условиям технического задания (ТЗ).

Шаги:

Сопоставление схемы. Автоматическое сравнение ER-диаграммы реальной БД с ER-диаграммой, указанной в ТЗ (или реконструированной из ТЗ). Формирование отчета о недостающих/лишних сущностях и атрибутах.

Функциональный тест кодом. Для каждого требования ТЗ вида «Система должна рассчитывать Х по формуле Y» ищется соответствующая хранимая процедура/функция. Проводится статический анализ ее кода на соответствие формуле Y.

Анализ полноты данных. Проверка наличия и объема тестовых данных, необходимых для демонстрации работы ключевых функций. SQL-запрос: SELECT table_name, COUNT(*) as row_count FROM … GROUP BY table_name.

Тестирование граничных условий. Запуск процедур с тестовыми наборами данных, включая ошибочные, для проверки устойчивости и соответствия требованиям к валидации.

2.2. Методика ретроспективного восстановления хозяйственной операции.

Цель: Восстановить полную цепочку документооборота и движений по конкретной сделке на определенную дату.

Шаги:

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

Темпоральный анализ. Для каждой найденной записи извлечение ее состояния на нужную дату через темпоральные запросы или анализ журнала изменений (change_log).

Реконструкция workflow. Построение последовательности событий на основе временных меток (created_at, approved_at, posted_at).

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

2.3. Методика выявления фактов неправомерного изменения (фальсификации) данных.

Цель: Обнаружить технические признаки некорректного, задним числом, изменения или удаления учетных записей.

Шаги:

Анализ автоинкрементных идентификаторов. Поиск нелогичных пропусков в последовательности ID, которые могут указывать на удаление записей. SELECT t1.id + 1 as missing_id FROM table t1 WHERE NOT EXISTS (SELECT 1 FROM table t2 WHERE t2.id = t1.id + 1).

Расследование временных меток. Проверка логики created_at < updated_at. Поиск записей, где updated_at существенно позже created_at и при этом близко к дате возникновения спора.

Сравнение с независимыми логами. Сопоставление данных из основной таблицы с записями в таблице аудита или логами приложения. Обнаружение расхождений.

Анализ триггеров отката. Поиск триггеров типа INSTEAD OF UPDATE/DELETE, которые могут маскировать реальные операции.

2.4. Методика расчета фактических объемов и сумм по данным БД.

Цель: На основе сырых данных БД получить агрегированные показатели (оборот, задолженность, количество операций) для сравнения с заявленными сторонами.

Шаги:

Разработка алгоритма агрегации. Написание сложного SQL-запроса или скрипта на Python, который точно воспроизводит логику расчетов, исходя из структуры данных. Например, расчет дебиторской задолженности: SUM(invoice_amount) — SUM(payment_amount) GROUP BY client_id.

Верификация алгоритма. Проверка результатов агрегации на небольшой выборке вручную.

Формирование результирующих наборов. Создание отчетов в формате, удобном для восприятия судом (таблицы с итогами, диаграммы).

2.5. Методика анализа соответствия работы системы внутренним регламентам.

Цель: Проверить, соблюдались ли при совершении операций в системе автоматизированные правила, предписанные внутренними документами.

Шаги:

Формализация регламента. Перевод пункта регламента (например, «Скидка более 20% требует согласования финансового директора») в формальное правило: IF discount > 20 THEN approval_status = ‘pending_fd_approval’.

Поиск реализации правила. Обнаружение в коде процедур или триггеров проверок, соответствующих этому правилу.

Выборка исключений. Поиск записей в данных, которые нарушают это правило (SELECT * FROM orders WHERE discount > 20 AND approval_status != ‘pending_fd_approval’).

Аудит процесса согласования. Если правило предполагает workflow, анализ соответствующих таблиц согласований на его полноту.

ГЛАВА 3. СИСТЕМА МЕТОДИЧЕСКИ ОРИЕНТИРОВАННЫХ ВОПРОСОВ ДЛЯ ЭКСПЕРТИЗЫ

Вопросы сформулированы так, чтобы ответ на них требовал применения конкретной методики и давал технически четкий результат.

Блок А: Вопросы на структурно-функциональный анализ (Методика 2.1)

Соответствует ли логическая структура представленной базы данных (состав таблиц, их атрибуты и связи) структуре, определенной в Техническом задании (приложение №) к договору? Представьте отчет о совпадениях и расхождениях в виде сравнительной таблицы.

Реализованы ли в коде хранимых процедур или функций алгоритмы, соответствующие описанию бизнес-процессов в пунктах [X, Y, Z] Приложения к договору? Приведите тексты соответствующих фрагментов кода и дайте пояснения.

Содержит ли база данных в своих основных таблицах объем тестовых или рабочих данных, достаточный для проверки функционирования заявленных в ТЗ модулей? Укажите количество записей в ключевых таблицах на дату [дата].

Блок Б: Вопросы на ретроспективный анализ и восстановление операций (Методика 2.2)

Каково было состояние данных, относящихся к сделке по договору № [номер] (статус, суммы, обязательства) в базе данных на дату [конкретная дата, например, дата предъявления претензии]? Восстановите эту информацию на основе имеющихся данных и журналов.

Возможно ли на основании журналов изменений (логов) базы данных восстановить полную последовательность действий пользователей (с указанием учетных записей и временных меток), связанных с изменением условий по лицевому счету контрагента [наименование] в период с [дата] по [дата]?

Имеются ли в базе данных технические возможности для фиксации факта одобрения (согласования) операции пользователем с определенной ролью? Если да, зафиксировано ли такое одобрение для операции [описание]?

Блок В: Вопросы на выявление аномалий и фальсификаций (Методика 2.3)

Обнаружены ли в исследуемой базе данных технические признаки, позволяющие предполагать, что записи, датированные периодом [период], были внесены или изменены позднее? (Проанализируйте последовательности первичных ключей, логику временных меток created_at/updated_at, наличие записей в журналах об удалениях).

Существуют ли в базе данных дублирующие или логически противоречащие друг другу записи об одном и том же факте хозяйственной жизни (например, две накладные с одним номером, акт с разными суммами)? Если да, представьте их список.

Зафиксированы ли в журналах базы данных факты непосредственного выполнения SQL-запросов на изменение (UPDATE, DELETE) данных, минуя штатный интерфейс прикладного программного обеспечения, в отношении таблиц, содержащих данные по [предмет спора]?

Блок Г: Вопросы на агрегацию и расчет (Методика 2.4)

Какой совокупный объем товаров/услуг (в натуральном и денежном выражении) был отражен в базе данных как поставленный/оказанный контрагенту [наименование] по договору № [номер] за период с [дата] по [дата]? Предоставьте детализированную выборку, лежащую в основе расчета.

Рассчитайте на основе данных операционных таблиц базы данных размер дебиторской задолженности контрагента [наименование] перед компанией [наименование] на дату [дата]. Опишите использованную для расчета формулу (алгоритм).

Каков был остаток товара на складе [номер] по номенклатурной позиции [наименование] согласно данным базы данных на конец дня [дата]? Воспроизведите расчет, исходя из данных о приходе и расходе.

Блок Д: Вопросы на анализ соответствия регламентам (Методика 2.5)

Соответствует ли зафиксированная в базе данных последовательность статусов при согласовании заявки на оплату № [номер] порядку, установленному внутренним регламентом компании (прилагается)? Если нет, укажите, на каком этапе и в чем заключается нарушение.

Были ли при проведении автоматического расчета бонусов за период [период] применены ко всем контрагентам одинаковые условия (процентные ставки, алгоритмы), указанные в действующем на тот момент Положении о бонусах? Выявите контрагентов, для которых условия расчета отличались.

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

ГЛАВА 4. ПРАКТИЧЕСКИЕ КЕЙСЫ ПРИМЕНЕНИЯ МЕТОДИК

Кейс 1: Спор о качестве внедрения CRM-системы (Методики 2.1, 2.4)

Задача: Заказчик утверждал, что система не считает ключевой показатель KPI «Средний чек по менеджеру».

Ход по методике 2.1: Эксперт сопоставил структуру БД с ТЗ. Обнаружил таблицы sales, managers, products. В ТЗ формула: SUM(sales.amount) / COUNT(DISTINCT sales.invoice_id) по каждому менеджеру.

Ход по методике 2.4: Анализ кода показал, что существующая отчетная процедура делила SUM(amount) на COUNT(sales.id) (количество позиций, а не чеков), что искажало результат.

Действие: Эксперт написал корректный SQL-запрос, вычислил показатель по правильной формуле и сравнил с выводимым системой, продемонстрировав расхождение в 25-40%. В заключении был приведен и правильный, и ошибочный код, а также таблица расхождений.

Итог: Суд признал недостаток существенным, взыскал с подрядчика стоимость доработки.

Кейс 2: Доказывание реальности поставок в налоговом споре (Методики 2.2, 2.3)

Задача: Налоговая инспекция реальности поставок, считая накладные «бумажными».

Ход по методике 2.2: Эксперт восстановил цепочку по накладной №Х в ERP: 1) Создание заказа клиентом в orders (с IP-адресом клиента). 2) Формирование задания в wms_tasks на отбор. 3) Сканирование штрих-кодов товаров сотрудником склада (данные из scan_log с ID сканера). 4) Автоматическое обновление остатков в inventory. 5) Формирование электронной ТТН и отметка об отправке.

Ход по методике 2.3: Проверка временных меток показала логичную последовательность без «перескоков» времени. Автоинкрементные ID в смежных таблицах были согласованы.

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

Итог: Суд отклонил претензии ИФНС, признав поставки документально подтвержденными.

Кейс 3: Вывод активов в преддверии банкротства (Методики 2.3, 2.4)

Задача: Управляющий оспаривал перевод денег на счет «дружественной» фирмы за неделю до подачи заявления о банкротстве.

Ход по методике 2.3: Анализ таблицы payment_orders показал, что запись о платеже была создана (created_at) задним числом, но id записи был на 1000 единиц больше, чем у платежей, датированных этим днем. Это указывало на позднее внесение.

Ход по методике 2.4: Анализ связанной таблицы invoice не выявил счета, на который бы ссылался этот платеж. SQL-запрос: SELECT * FROM invoices WHERE id = (SELECT invoice_id FROM payment_orders WHERE id=ХХХ) вернул NULL.

Действие: Эксперт составил отчет, наглядно показавший аномалию в последовательности ID и отсутствие первичного документа-основания в системе.

Итог: Сделка признана подозрительной, средства возвращены в конкурсную массу.

Кейс 4: Конфликт акционеров: несанкционированное изменение реестра (Методики 2.5, 2.2)

Задача: Миноритарий утверждал, что его доля была уменьшена в корпоративной БД без решения собрания.

Ход по методике 2.5: Внутренний регламент требовал для изменения доли наличия записи в таблице shareholder_decisions с типом SHARE_CHANGE.

Ход по методике 2.2: Анализ таблицы shareholdings и связанного журнала shareholdings_audit показал, что запись об уменьшении доли была внесена прямой правкой (UPDATE), причем в поле changed_by стоял NULL. В таблице shareholder_decisions записей за этот период не было.

Действие: Эксперт представил SQL-запрос, выявляющий все изменения в shareholdings без соответствующих записей в shareholder_decisions.

Итог: Действия были признаны неправомерными, данные восстановлены.

Кейс 5: Спор о нарушении исключительных прав на ПО (Методика 2.1, анализ кода)

Задача: Правообладатель обвинял бывшего партнера в использовании скопированной БД и бизнес-логики в конкурирующем продукте.

Ход по методике 2.1 (углубленный): Эксперт провел сравнение не только структуры, но и хэш-сумм уникальных элементов:

Сравнил структуры БД – 95% совпадение.

Проанализировал имена и сигнатуры хранимых процедур – совпадение 80%.

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

Действие: Заключение содержало таблицу совпадений и листинги идентичных процедур с подсвеченными одинаковыми комментариями.

Итог: Суд вынес решение о нарушении исключительных прав и взыскал компенсацию.

ГЛАВА 5. ЗАКЛЮЧЕНИЕ: МЕТОДИЧЕСКАЯ СТРОГОСТЬ КАК ОСНОВА ДОКАЗАТЕЛЬСТВЕННОЙ СИЛЫ

Представленная методическая система трансформирует экспертизу БД из искусства в ремесло, основанное на повторяемых и проверяемых операциях. Ее строгое соблюдение позволяет:

Обеспечить полноту исследования, минимизируя риск упустить критически важные данные.

Гарантировать объективность, так как каждый шаг документирован и может быть воспроизведен независимым экспертом.

Повысить убедительность для суда, поскольку выводы подкрепляются не общими словами, а конкретными цифрами, листингами кода и схемами.

Защититься от критики в состязательном процессе, так как методология соответствует современным стандартам IT-аудита и криминалистики данных.

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