📌 Введение

• IT-экспертиза соответствия данных, содержащихся в базе MariaDB, первичным документам представляет собой комплексное компьютерно-техническое исследование, направленное на установление того, насколько сведения информационной системы совпадают с документами, на основании которых хозяйственные операции первоначально оформлялись и вводились в учёт. 💻🔎📄
• Объектами сопоставления могут выступать договоры, счета, товарные накладные, универсальные передаточные документы, акты выполненных работ, кассовые документы, платёжные поручения, складские ордера, спецификации, заявки, путевые листы, табели, производственные отчёты и иные документы, содержащие юридически или экономически значимую информацию.
• В информационной системе тем же документам могут соответствовать строки таблиц MariaDB, записи в связанных справочниках, журналы операций, сведения о пользователях, временные метки, статусы проведения, идентификаторы контрагентов, суммы, количество товаров, ставки налогов, реквизиты платежей и результаты автоматических расчётов.
• Экспертиза становится необходимой, когда между бумажными или электронными первичными документами и базой данных обнаруживаются расхождения. Например, в накладной указано 150 единиц товара, а в базе — 180; акт составлен на сумму 420 000 рублей, но в учётной системе отражено 520 000 рублей; дата документа не совпадает с датой создания записи; один документ представлен в базе несколькими операциями; либо сведения о хозяйственной операции были изменены после подписания первичного документа.
• Такие расхождения не всегда свидетельствуют о намеренном искажении данных. Они могут быть следствием ошибки оператора, особенностей программной логики, некорректного импорта, округления, неправильной настройки справочников, повторной синхронизации, сбоя транзакции, изменения документа в предусмотренном порядке или отражения одной хозяйственной операции несколькими техническими записями.
• Поэтому эксперт не должен ограничиваться механическим сравнением распечатки из базы с бумажным документом. Необходимо установить архитектуру информационной системы, структуру таблиц, взаимосвязь данных, правила формирования записей, логику приложения, историю изменений, состояние журналирования и происхождение представленной выгрузки.
• MariaDB является реляционной системой управления базами данных. В ней сведения обычно распределяются по множеству взаимосвязанных таблиц, а пользовательский документ, отображаемый на экране программы, может формироваться путём объединения десятков полей, расчётных выражений и справочных значений. Поэтому одна строка интерфейса не всегда соответствует одной строке физической таблицы.
• Экспертное исследование должно отвечать не только на вопрос, совпадают ли итоговые суммы. Оно должно определить, какие данные были введены из первичного документа, какие рассчитаны автоматически, какие были получены из справочников, кем и когда выполнялись изменения, сохранилась ли история редактирования и можно ли подтвердить целостность исследуемого массива.
• Для решения поставленных задач могут анализироваться рабочая база данных, резервные копии, журналы MariaDB, бинарные журналы, журналы аудита, программный код приложения, SQL-запросы, конфигурационные файлы, пользовательские журналы, документы из системы электронного документооборота и сведения операционной системы.
• Официальная документация MariaDB выделяет несколько видов серверных журналов, включая журнал ошибок, общий журнал запросов, журнал медленных запросов и бинарный журнал. Их наличие и сохранность могут существенно расширить возможности ретроспективного исследования действий с данными.
• Общий журнал запросов способен фиксировать получаемые сервером SQL-запросы, а также подключения и отключения клиентов. Вместе с тем такой журнал может быстро увеличиваться в объёме, поэтому в реальных системах он нередко отключён либо хранится ограниченное время.
• Дополнительным источником сведений может служить MariaDB Audit Plugin. Формат его записей предусматривает фиксацию времени, идентификатора сервера, пользователя, хоста и сведений о выполненной операции, однако фактическая полнота журнала зависит от настроек аудита в исследуемой системе.
• Если в системе применялись таблицы с системным версионированием, MariaDB позволяет хранить исторические состояния строк и выполнять запросы к данным на определённый момент времени. Наличие такой архитектуры может дать эксперту возможность сравнить текущую запись с её предыдущими версиями.
• При судебном рассмотрении спора экспертиза назначается для разрешения вопросов, требующих специальных знаний. В арбитражном процессе соответствующее основание закреплено статьёй 82 АПК РФ, а проведение исследования может быть поручено как государственным судебным экспертам, так и иным лицам, обладающим необходимыми специальными знаниями.
• Значительный опыт исследования баз данных, корпоративных информационных систем, электронных документов и журналов операций накоплен специалистами Союза «Федерация судебных экспертов», которые проводят независимые и судебные компьютерно-технические экспертизы MariaDB, MySQL, PostgreSQL, Microsoft SQL Server, Oracle Database и прикладных учётных систем.

🧭 Раздел 1. Что является предметом IT-экспертизы

• Предметом исследования является не сама MariaDB как программный продукт, а фактические обстоятельства формирования, хранения, изменения и использования данных в конкретной информационной системе.
• Эксперт устанавливает, какие сведения содержатся в исследуемой базе, каким первичным документам они соответствуют, совпадают ли значения реквизитов, каким способом записи были созданы и возможно ли определить историю их изменения.
• В зависимости от обстоятельств дела исследование может включать установление соответствия дат, сумм, количества, наименований товаров, идентификаторов контрагентов, номеров документов, ставок налога, валюты, складов, подразделений, ответственных лиц и статусов операций.
• Отдельной задачей является определение логической связи между первичным документом и строками базы. Такая связь может подтверждаться номером документа, UUID, внутренним идентификатором, ссылкой на карточку контрагента, номером заказа, хешем электронного файла или набором совпадающих реквизитов.
• Эксперт также оценивает, является ли исследуемая запись исходной либо производной. Например, данные в таблице отчёта могут быть результатом SQL-представления, агрегирующего сведения из нескольких таблиц. В таком случае сравнение следует проводить с исходными операционными записями, а не только с итоговой витриной.
• Предмет экспертизы необходимо формулировать конкретно. Общий вопрос «Соответствует ли база документам?» слишком широк, поскольку база может содержать миллионы записей и множество функционально различных подсистем.
• Правильнее определить период, перечень хозяйственных операций, конкретные таблицы или документы, спорные поля и характер предполагаемого несоответствия.

📄 Раздел 2. Что понимается под первичными документами

• В практической экспертной работе первичными называют документы, которыми первоначально оформлялась хозяйственная, складская, финансовая, производственная, кадровая или иная операция.
• Такими документами могут быть бумажные оригиналы, подписанные электронные документы, сканированные образы, файлы из системы электронного документооборота и документы, сформированные непосредственно в информационной системе.
• Для эксперта принципиально важно установить происхождение представленного документа. Распечатка из той же базы MariaDB не всегда является независимым первичным источником. Она может представлять собой визуальное отображение тех же записей, соответствие которых проверяется.
• Например, если сторона представляет печатную форму накладной, автоматически сформированную приложением из исследуемой базы, совпадение этой формы с таблицами не подтверждает соответствие реальной хозяйственной операции. И документ, и запись могли быть сформированы из одного ошибочного набора данных.
• Более значимыми могут оказаться подписанный экземпляр накладной, файл электронного документа с электронной подписью, входящее сообщение оператора ЭДО, банковская выписка, складской ордер или документ контрагента.
• Эксперт должен разграничивать содержание документа, его технический формат и доказательственное происхождение. Компьютерно-техническое исследование может подтвердить структуру электронного файла, наличие подписи, метаданные и связь с базой, но правовую силу документа оценивает суд.

🗄️ Раздел 3. Особенности хранения данных в MariaDB

• MariaDB хранит данные в таблицах, каждая из которых имеет набор столбцов и строк. Однако прикладная информационная система обычно создаёт над базой собственную предметную модель.
• Один документ продажи может быть представлен записью в таблице заголовков, несколькими строками товаров, записями о налогах, проводках, движениях по складам, платежах, скидках и истории статусов.
• Например, таблица sales_documents может содержать номер, дату и контрагента, а таблица sales_items — отдельные товарные позиции. Информация о контрагенте может храниться в customers, сведения о номенклатуре — в products, а журнал изменений — в document_history.
• Поэтому эксперт сначала восстанавливает структуру связей. Он изучает первичные и внешние ключи, индексы, ограничения, представления, триггеры, хранимые процедуры и правила прикладной программы.
• Особое внимание уделяется типам данных. Сумма может храниться в DECIMAL, дата — в DATE, DATETIME или TIMESTAMP, а номер документа — в строковом поле. Неверное понимание типа способно привести к ошибочной интерпретации.
• Например, TIMESTAMP может отображаться с учётом часового пояса приложения или соединения. В результате одна и та же операция в журнале и пользовательском интерфейсе может визуально относиться к разным календарным датам.
• Эксперт должен установить версию MariaDB, используемый движок хранения, кодировку, параметры часового пояса, режим SQL и конфигурацию сервера, поскольку эти сведения влияют на обработку и отображение данных.

🔗 Раздел 4. Связь между первичным документом и записью базы

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

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

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

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

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

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

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

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

🔍 Раздел 5. Предварительное изучение информационной системы

Исследование начинается не с выполнения произвольных SQL-запросов, а с фиксации состояния системы и определения её архитектуры.

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

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

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

Рабочая информационная система может включать несколько MariaDB-серверов. Один обслуживает операции, второй используется для отчётности, третий является репликой, а четвёртый содержит архив.

Если эксперт исследует только отчётную копию, необходимо определить дату и механизм её синхронизации.

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

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

🛡️ Раздел 6. Сохранение цифровых доказательств

До начала содержательного анализа необходимо обеспечить сохранность исходных цифровых объектов.

Работа непосредственно с единственным экземпляром производственной базы создаёт риск изменения метаданных, журналов, служебных таблиц или данных.

Предпочтительным является создание криминалистической копии либо согласованной резервной копии, после чего исследование проводится на отдельной изолированной среде.

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

Если база доступна только на работающем сервере, эксперт документирует команды и средства, использованные для выгрузки.

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

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

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

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

💾 Раздел 7. Исследование резервных копий

Резервные копии позволяют сравнить состояние базы в разные даты и установить, существовала ли спорная запись ранее.

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

MariaDB предоставляет специализированный инструмент mariadb-backup, а актуальные версии могут сохранять сведения об операциях резервного копирования в служебной таблице истории. Однако наличие такой истории зависит от версии и конфигурации конкретной системы.

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

Например, в резервной копии на 10 марта сумма документа составляла 120 000 рублей, а в копии на 11 марта — уже 180 000 рублей. Это сужает временной интервал изменения, но само по себе не определяет конкретного пользователя.

Эксперт проверяет согласованность резервной копии и возможность её восстановления.

Файл с названием backup.sql не обязательно является полным и корректным дампом. Он может содержать только отдельные таблицы либо данные без структуры.

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

Поэтому она анализируется совместно с журналами, документами и другими источниками.

📜 Раздел 8. Общий журнал запросов

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

Для экспертизы такой журнал полезен тем, что способен показать непосредственные команды INSERT, UPDATE, DELETE, вызовы процедур и выборки.

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

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

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

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

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

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

🔄 Раздел 9. Бинарный журнал MariaDB

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

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

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

При строковом формате в журнале могут фиксироваться изменения конкретных строк, а при операторном — SQL-команды.

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

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

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

Но он не заменяет первичный документ и не подтверждает экономическую обоснованность операции.

Если бинарные журналы удалены по политике ротации, восстановить соответствующую историю только средствами MariaDB может быть невозможно.

👤 Раздел 10. Журналы аудита и действия пользователей

MariaDB Audit Plugin может фиксировать операции доступа и изменения в зависимости от настроенных событий и фильтров. Формат аудиторских записей включает временные сведения, идентификатор сервера, пользователя, хост и информацию об операции.

Эксперт сначала проверяет, был ли плагин установлен и активирован в спорный период.

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

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

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

Важно разграничивать пользователя MariaDB и пользователя прикладной системы. Программа может подключаться к серверу под общей технической учётной записью, а сведения о сотруднике хранить в собственном журнале.

В таком случае для атрибуции действия требуется сопоставить время SQL-операции, идентификатор сессии, запись приложения, IP-адрес, рабочее место и корпоративную аутентификацию.

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

🕒 Раздел 11. Даты и временные метки

Сравнение дат является одной из наиболее сложных частей исследования.

Первичный документ может содержать дату его составления, дату операции, дату подписания и дату получения.

В базе могут одновременно храниться document_date, created_at, updated_at, posted_at, paid_at и иные временные поля.

Эти значения имеют разный смысл. Дата накладной не обязана совпадать со временем создания записи в системе.

Документ могли оформить 5 апреля, внести в базу 6 апреля, провести по учёту 7 апреля, а изменить 10 апреля.

Эксперт изучает программную документацию, код и структуру таблиц, чтобы определить назначение каждого поля.

Также проверяется часовой пояс сервера, операционной системы, приложения и пользователя.

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

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

Поэтому нельзя автоматически считать последнюю временную метку датой изменения спорной суммы.

💰 Раздел 12. Сопоставление денежных сумм

Денежные расхождения могут возникать как вследствие изменения исходных данных, так и из-за расчётных особенностей.

Эксперт устанавливает, хранится ли итоговая сумма непосредственно в таблице или рассчитывается из товарных строк.

Исследуются цена, количество, скидка, налог, валюта, курс, стоимость доставки, округление и корректировки.

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

Прямое сравнение одного поля с итогом документа приведёт к ошибочному выводу.

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

Различие в одну или несколько копеек может возникнуть из-за порядка округления: по каждой строке либо по документу в целом.

Крупное расхождение требует анализа исходных позиций и истории изменений.

Эксперт должен показать расчёт, а не ограничиваться утверждением, что суммы «не совпадают».

Если итог формируется прикладной функцией или хранимой процедурой, её алгоритм также подлежит исследованию.

📦 Раздел 13. Сопоставление количества и номенклатуры

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

Первичный документ может содержать 10 коробок, а база — 120 единиц товара. Если в одной коробке находится 12 единиц, данные могут быть эквивалентны.

Наименование в документе и базе также может различаться. В первичном документе указывается коммерческое название, а в базе — внутренний код или сокращённое наименование.

Эксперт исследует справочник номенклатуры, штрихкоды, артикулы, единицы измерения и таблицы упаковок.

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

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

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

При наличии исторических справочников либо системного версионирования можно восстановить прежнее значение.

Эксперт должен отличать изменение хозяйственной записи от последующего изменения справочного описания.

🏢 Раздел 14. Контрагенты и связанные справочники

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

Запись продажи содержит только customer_id, а наименование, ИНН, адрес и банковские реквизиты извлекаются из карточки контрагента.

Если карточка была изменена, текущий отчёт может отражать новые сведения в старом документе.

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

Это не обязательно означает, что первоначальная операция была оформлена на другого контрагента.

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

Аналогичная проблема возникает при объединении дублирующих карточек или переназначении внутреннего идентификатора.

Для достоверного сопоставления используются устойчивые идентификаторы: ИНН, регистрационный номер, внутренний UUID и исторические записи.

Если система не хранит историю справочника, восстановление прежних реквизитов может потребовать анализа резервных копий.

🧮 Раздел 15. Автоматические расчёты и бизнес-логика

Часть сведений в MariaDB формируется не оператором, а программой.

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

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

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

Триггер может автоматически менять статус документа после добавления платежа.

Хранимая процедура может пересчитать итог после редактирования товарной строки.

Фоновое задание способно обновить валютный курс или распределить скидку.

Если эксперт сравнивает только конечную таблицу, он рискует ошибочно приписать автоматическое изменение пользователю.

В заключении желательно разграничить данные, непосредственно введённые оператором, данные, импортированные из внешней системы, и показатели, рассчитанные программно.

При необходимости выполняется контрольный расчёт в изолированной копии системы.

⚙️ Раздел 16. Триггеры, процедуры и скрытые механизмы изменения

MariaDB поддерживает механизмы, способные изменять данные без отдельного действия пользователя в интерфейсе.

Триггер выполняется автоматически при определённом событии над таблицей.

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

Хранимая процедура может содержать комплексную последовательность операций над несколькими таблицами.

Событие планировщика способно выполняться по расписанию и изменять данные ночью.

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

Особенно важно установить, соответствовала ли их версия периоду спорной операции. Текущий код мог быть изменён после события.

Для этого используются резервные копии схемы, система контроля версий и журналы развёртывания.

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

🧾 Раздел 17. Представления и отчётные таблицы

Пользователь часто работает не с физической таблицей, а с представлением или отчётной витриной.

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

Материализованная или промежуточная таблица может обновляться по расписанию и временно отставать от рабочей базы.

Если сторона предоставляет выгрузку из отчёта, эксперт устанавливает SQL-логику её формирования.

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

Такое расхождение не означает, что исходный документ в базе изменён.

Иной тип ошибки связан с фильтрацией. Отчёт может исключать отменённые строки или учитывать только проведённые документы.

Эксперт должен проследить данные от первичной таблицы до итоговой формы.

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

🔁 Раздел 18. Импорт, интеграция и синхронизация

Данные MariaDB могут поступать из внешних систем: электронного документооборота, интернет-магазина, CRM, банковского клиента, складской системы или оборудования.

Импорт может выполняться через API, файлы CSV, XML, JSON, очереди сообщений или прямое подключение.

Расхождение с первичным документом может возникнуть ещё до записи в MariaDB.

Например, интеграционный модуль неправильно интерпретировал десятичный разделитель, обрезал ведущие нули или преобразовал дату в другом часовом поясе.

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

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

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

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

Необходимо также проверить обратную синхронизацию. Иногда изменения, внесённые в одной системе, позднее перезаписываются данными другой.

🧑‍💻 Раздел 19. Ручное изменение данных администратором

В некоторых организациях администраторы или разработчики имеют возможность выполнять SQL-команды непосредственно в базе.

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

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

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

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

Также могут различаться временные метки в основной и исторической таблице.

Однако невозможность создания записи через текущую версию интерфейса не доказывает прямое SQL-вмешательство. Ранее могла использоваться другая версия программы.

Эксперт должен исследовать историческую бизнес-логику и избегать категорических выводов при недостатке данных.

🗑️ Раздел 20. Удалённые и отменённые записи

Удаление документа в прикладной системе может реализовываться по-разному.

Физическое удаление означает удаление строки из таблицы.

Логическое удаление сохраняет запись, но устанавливает признак deleted, is_active или специальный статус.

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

Эксперт определяет применяемый механизм и анализирует связанные таблицы.

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

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

Если документ был логически удалён, он может не отображаться пользователю, но продолжать влиять на отчёты из-за ошибки запроса.

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

🕰️ Раздел 21. Системно-версионируемые таблицы

MariaDB поддерживает системно-версионируемые таблицы, позволяющие хранить историю строк и обращаться к состоянию данных на определённый момент. Официальная документация описывает запросы FOR SYSTEM_TIME AS OF, BETWEEN и ALL, а также служебные временные границы версий.

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

Например, документ был создан с суммой 300 000 рублей, затем изменён на 350 000 рублей, а позднее возвращён к первоначальному значению.

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

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

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

Эксперт проверяет структуру таблицы, период действия версионирования и способ хранения истории.

MariaDB также поддерживает модели прикладного времени и бивременные таблицы, объединяющие системную историю с периодом действия данных в предметной области. Такие структуры могут быть полезны, когда необходимо различать момент внесения записи и период, к которому она относится.

🔐 Раздел 22. Целостность и контрольные суммы

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

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

Контрольная сумма подтверждает неизменность конкретного файла между двумя моментами при условии корректной фиксации исходного значения.

Она не доказывает достоверность содержащихся внутри данных.

Если сторона сначала изменила базу, затем создала дамп и рассчитала его контрольную сумму, хеш подтвердит только неизменность уже подготовленного дампа.

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

Эксперт проверяет алгоритм их формирования, перечень включённых полей и место хранения ключей.

Если хеш охватывает только сумму и дату, изменение контрагента может остаться незамеченным.

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

📁 Раздел 23. Логическая выгрузка и её ограничения

Для экспертизы часто предоставляется файл SQL, CSV или Excel, выгруженный из MariaDB.

Такой файл может быть удобен, но не является полной копией информационной системы.

CSV обычно не содержит типов данных, индексов, связей, триггеров, процедур и истории операций.

Excel-файл может дополнительно изменить даты, ведущие нули, большие идентификаторы и формат чисел.

SQL-дамп способен включать структуру и данные, но его состав зависит от параметров создания.

Эксперт проверяет, какие базы и таблицы вошли в выгрузку, присутствуют ли представления, процедуры, события и триггеры.

Необходимо также установить, в какой момент создан файл и кем.

Если исследование ограничено выгрузкой, выводы формулируются применительно к её содержимому, а не ко всей производственной системе.

В заключении нельзя писать, что «в базе отсутствует запись», если эксперту предоставили только выборочный CSV-файл.

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

🖥️ Раздел 24. Пользовательский интерфейс и фактические данные

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

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

Поля могут быть вычислены на стороне приложения без сохранения результата в MariaDB.

Например, интерфейс показывает статус «Оплачен», если сумма платежей равна сумме документа, хотя отдельного поля такого статуса в базе нет.

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

Эксперт сопоставляет экранную форму, сетевые запросы, серверный API, SQL-операции и содержимое базы.

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

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

👥 Раздел 25. Пользователи, роли и права доступа

Для установления возможности изменения данных исследуются учётные записи и права.

Эксперт определяет, какие пользователи могли создавать, редактировать, проводить, отменять и удалять документы.

Следует разграничивать права MariaDB и права прикладной системы.

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

Напротив, администратор базы может технически изменить запись, хотя не включён в прикладной справочник пользователей.

Исследуются роли, привилегии, группы, журналы выдачи доступа и изменения настроек.

Текущие права не всегда соответствуют правам на дату события.

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

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

Наличие доступа означает техническую возможность, но само по себе не доказывает фактическое выполнение операции.

🧑‍⚖️ Раздел 26. Разграничение компетенции эксперта и суда

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

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

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

Некорректным будет вопрос: «Подтверждает ли база задолженность ответчика?»

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

Вопрос «Сфальсифицирована ли база?» также чрезмерно общий и содержит оценочную правовую составляющую.

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

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

❓ Раздел 27. Вопросы, которые можно поставить перед экспертом

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

Основной вопрос может быть сформулирован так:

«Соответствуют ли сведения о хозяйственных операциях, содержащиеся в представленной базе данных MariaDB, данным первичных документов за период с ___ по ___?»

Однако для полноценного исследования его желательно конкретизировать.

Можно спросить:

«Какие записи базы MariaDB соответствуют представленным товарным накладным?»

«Совпадают ли номера, даты, контрагенты, товарные позиции, количество и суммы записей с реквизитами первичных документов?»

«Какие конкретные расхождения выявлены между первичными документами и базой?»

«Имеются ли в базе записи, для которых среди представленных материалов отсутствуют соответствующие первичные документы?»

«Имеются ли первичные документы, сведения о которых отсутствуют в базе?»

«Содержатся ли в базе дублирующие записи по одной хозяйственной операции?»

«Выполнены ли спорные записи в один период либо создавались и изменялись в разные даты?»

«Каковы даты и время создания и изменения спорных записей?»

«Какие учётные записи использовались при создании или изменении данных?»

«Имеются ли в журналах MariaDB сведения об SQL-операциях над спорными записями?»

«Сохранились ли предыдущие версии записей в исторических таблицах, резервных копиях или бинарных журналах?»

«Какие значения содержались в записях до их изменения?»

«Могли ли выявленные изменения быть сформированы автоматически триггером, процедурой, интеграционным модулем или фоновым заданием?»

«Соответствует ли итоговая сумма алгоритму расчёта, реализованному в информационной системе?»

«Обусловлено ли расхождение ошибкой исходных данных или особенностями формирования отчёта?»

«Имеются ли признаки прямого изменения таблиц в обход штатного интерфейса?»

«Является ли представленная выгрузка полной копией необходимых таблиц и метаданных?»

«Позволяют ли представленные материалы достоверно установить историю спорных записей?»

🚫 Раздел 28. Некорректные вопросы эксперту

Некорректно спрашивать: «Кто похитил денежные средства посредством базы MariaDB?»

Эксперт может исследовать записи и учётные данные, но вопрос о совершении преступления и виновности лица относится к компетенции следствия и суда.

Некорректен вопрос: «Являются ли сведения базы юридически достоверными?»

Техническое исследование устанавливает происхождение, целостность и соответствие данных, но не определяет их юридическую силу.

Некорректно: «Обязан ли ответчик выплатить сумму, указанную в базе?»

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

Некорректно: «Подделал ли бухгалтер записи?»

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

Некорректно: «Можно ли доверять всей информационной системе?»

Экспертиза должна иметь конкретные объекты и проверяемые критерии.

Некорректно: «Имеются ли любые нарушения в базе?»

При миллионах записей такой вопрос неопределён и практически неисполним.

Чёткая постановка задачи повышает проверяемость и доказательственную ценность заключения.

📋 Раздел 29. Методика сопоставления данных

Сначала эксперт составляет реестр первичных документов.

Для каждого документа фиксируются номер, дата, вид операции, контрагент, договор, валюта, позиции, количество, цена, налог и итоговая сумма.

Затем определяется схема хранения соответствующих сведений в MariaDB.

Эксперт выявляет основные и связанные таблицы, ключевые поля и алгоритмы формирования.

После этого создаётся таблица соответствия между документами и записями.

Сравнение проводится по каждому реквизиту, а не только по итоговой сумме.

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

Для каждого расхождения исследуется история.

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

Завершающим этапом является оценка причин и подготовка воспроизводимых запросов, на основании которых сделаны выводы.

🧪 Раздел 30. Контрольные SQL-запросы

SQL-запросы должны быть документированы таким образом, чтобы другой специалист мог повторить исследование.

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

При этом необходимо избегать изменения рабочей базы.

Запросы выполняются в режиме чтения либо на исследовательской копии.

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

Эксперт проверяет уникальность ключей и количество строк до и после соединения.

При агрегировании указывается, по каким полям выполняется группировка.

Если данные имеют статус удаления или отмены, условия фильтрации описываются отдельно.

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

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

📊 Раздел 31. Статистический анализ больших массивов

Если исследуются десятки или сотни тысяч документов, ручное сравнение невозможно.

Эксперт разрабатывает автоматизированную процедуру сопоставления.

Сначала выполняется точное сравнение по устойчивым идентификаторам.

Затем анализируются записи, не найденные однозначно.

Для них могут применяться составные критерии: дата, сумма, контрагент и сходство номера.

Результаты разделяются на совпадения, расхождения и неоднозначные соответствия.

Не следует использовать приблизительное сопоставление без последующей проверки, если от результата зависит вывод о конкретной операции.

Статистический анализ также позволяет выявить систематические закономерности.

Например, все расхождения могут относиться к одному периоду, пользователю, типу документа или интеграционному каналу.

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

В заключении необходимо указать объём проверенной совокупности и количество записей каждой категории.

⚠️ Раздел 32. Типичные причины расхождений

Расхождения между MariaDB и первичными документами могут быть вызваны множеством причин.

Распространённой является ошибка ручного ввода: неверная цифра, дата, количество или контрагент.

Другой причиной становится последующее исправление хозяйственной операции без корректного оформления нового документа.

Дублирование возникает при повторном импорте или отсутствии контроля уникальности.

Различия могут формироваться из-за округления, перерасчёта налога, изменения курса или единиц измерения.

Иногда база хранит корректные исходные данные, но отчёт формирует неверный результат из-за ошибки SQL-соединения.

Возможна рассинхронизация между несколькими системами.

Отдельную категорию составляют прямые административные изменения.

Эксперт должен рассматривать все технически обоснованные версии и не объявлять любое расхождение намеренной фальсификацией.

Вывод о причине строится на совокупности журналов, архитектуры, временных меток и программной логики.

📚 Раздел 33. Пять подробных практических кейсов

🔹 Кейс 1. Изменение суммы акта после его подписания

Организация представила подписанный акт выполненных работ на сумму 1 240 000 рублей. В учётной системе на базе MariaDB тот же документ отражался на сумму 1 740 000 рублей.

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

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

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

Историческая таблица показала, что первоначально сумма записи составляла 1 240 000 рублей и полностью совпадала с подписанным актом.

Через шестнадцать дней поле стоимости было изменено на 1 740 000 рублей.

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

При этом в системе отсутствовали новая версия акта, дополнительное соглашение или запись об изменении объёма работ.

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

🔹 Кейс 2. Дублирование накладных при повторном импорте

При инвентаризации обнаружилось, что база MariaDB показывает поступление товара в объёме, почти вдвое превышающем сведения бумажных накладных.

Заказчик предположил умышленное создание фиктивных операций.

Экспертиза установила, что документы поступали из внешней складской системы через ночной импорт.

Каждое сообщение имело внешний идентификатор, но в таблице MariaDB отсутствовало уникальное ограничение по этому полю.

После временного сбоя интеграционный сервис повторно отправил пакет за три дня.

Часть документов была создана второй раз с новыми внутренними идентификаторами, но с одинаковыми внешними номерами, датами, товарами и суммами.

Журнал интеграции подтвердил повторную обработку сообщений.

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

Эксперты составили перечень дублей и рассчитали корректный объём поступления после их исключения.

🔹 Кейс 3. Несовпадение наименования контрагента

В договоре и актах указывалось ООО «Север», тогда как в текущей выгрузке MariaDB по старым операциям отображалось ООО «Север-Логистика».

Одна сторона заявила, что документы относятся к другому юридическому лицу.

Исследование показало, что таблица операций содержала только числовой идентификатор контрагента.

При формировании отчёта наименование и адрес извлекались из текущей карточки справочника.

Несколько лет спустя администратор переименовал карточку и заменил реквизиты после реорганизации делового партнёра.

История справочника в рабочей базе не сохранялась.

Однако в резервной копии на дату операции карточка с тем же внутренним идентификатором содержала первоначальное наименование ООО «Север» и соответствующий ИНН.

Эксперт установил, что сама хозяйственная запись не переназначалась. Несовпадение возникло из-за динамического использования актуального значения справочника при печати старого документа.

🔹 Кейс 4. Ошибка отчёта при корректных исходных данных

Компания предъявила требование о задолженности, рассчитанной отчётом из информационной системы.

Первичные документы и платежи были загружены в MariaDB без видимых расхождений, однако итог отчёта превышал задолженность на несколько миллионов рублей.

Эксперт исследовал SQL-представление, формировавшее отчёт.

Таблица продаж соединялась с товарными строками и платежами одновременно.

Если документ содержал пять товарных позиций и два платежа, каждая сумма платежа повторялась пять раз.

Последующее агрегирование складывало размноженные значения и искажало расчёт.

Исходные документы, суммы продаж и платежей в операционных таблицах соответствовали первичным материалам.

Несоответствие возникало исключительно на уровне отчётного SQL-запроса.

Эксперт подготовил корректный запрос и пересчитал взаиморасчёты.

Случай показал, что ошибочный отчёт не всегда означает искажение первичных данных базы.

🔹 Кейс 5. Спор об авторе изменения документа

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

Журнал приложения указывал на учётную запись менеджера, который отрицал внесение изменений.

Экспертиза установила, что все пользователи филиала подключались к приложению через терминальный сервер.

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

Журнал MariaDB показывал только общую техническую учётную запись приложения.

IP-адрес соответствовал серверу приложений, а не конкретному рабочему месту.

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

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

Такой вывод сохранил границу между доказанным цифровым фактом и предположением. 📚

📝 Раздел 34. Как подготовить материалы к экспертизе

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

Следует предоставить оригиналы или достоверные электронные экземпляры документов.

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

Необходимо сохранить бинарные журналы и аудиторские файлы до истечения сроков их ротации.

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

Если используется интеграция, передаются исходные сообщения и журналы обмена.

Важны резервные копии за даты до и после предполагаемого изменения.

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

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

Каждый передаваемый цифровой объект должен быть описан, упакован и снабжён контрольной суммой.

⚖️ Раздел 35. Использование заключения в судебном споре

Экспертное заключение может использоваться для подтверждения наличия или отсутствия расхождений между учётной системой и первичными документами.

Оно также помогает определить объём спорных операций, историю изменения записей и технический источник ошибки.

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

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

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

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

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

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

В сложных спорах целесообразна комплексная компьютерно-техническая и бухгалтерская экспертиза.

🔍 Раздел 36. Как оценивать качество экспертного заключения

Необходимо проверить, какие именно цифровые объекты исследовал эксперт.

Если ему предоставили только Excel-таблицу, но в выводах говорится обо всей MariaDB, заключение выходит за пределы исследованного материала.

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

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

В заключении должны быть описаны таблицы и поля, из которых получены значения.

SQL-запросы либо их существенная логика должны быть доступны для проверки.

Необходимо оценить, учитывались ли связанные справочники, статусы, удалённые записи, часовые пояса и расчётные алгоритмы.

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

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

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

🏁 Заключение

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

Её задача не сводится к визуальному сравнению двух таблиц.

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

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

Совпадение одного номера или суммы не всегда достаточно для идентификации операции.

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

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

Поэтому эксперт обязан исследовать альтернативные технические версии.

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

Системно-версионируемые таблицы способны сохранять предыдущие состояния строк, если соответствующий механизм был включён до спорных событий.

Резервные копии позволяют определить временной интервал изменения и сравнить состояние базы в разные даты.

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

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

Изменение данных в отчёте не всегда означает изменение исходных таблиц.

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

Учётная запись пользователя не всегда тождественна физическому лицу, выполнившему действие.

Для персональной атрибуции необходима совокупность журналов приложения, операционной системы, аутентификации и MariaDB.

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

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

Экспертные вопросы следует формулировать применительно к конкретному периоду, документам, таблицам и реквизитам.

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

При необходимости IT-исследование дополняется бухгалтерской, экономической, почерковедческой или технико-криминалистической экспертизой документов.

Значительный опыт проведения подобных исследований накоплен Союзом «Федерация судебных экспертов», специалисты которого выполняют независимые и судебные компьютерно-технические экспертизы MariaDB, исследуют соответствие баз данных первичным документам, восстанавливают историю записей, анализируют SQL-операции, журналы аудита, резервные копии и программную логику корпоративных информационных систем. 📚

Полную контактную информацию, телефон и адрес офиса, а также дополнительные сведения по данному вопросу можно найти на официальном сайте 🔴 https://krimexpert.ru