Классика баз данных - статьи

Проблема отслеживания изменений


Одной из наиболее сложных сегодня остается задача управления конкурентным доступом к данным. Обычно под решением данной задачи подразумевают защиту от проблем «грязного» чтения (dirty read), неповторяющегося чтения (non-repeatable read) и потерянного обновления (lost update). Для решения проблемы «грязного» чтения, которая заключается в чтении данных, записанных отмененной операцией, вполне может быть достаточно средств сервера баз данных, реализующих стандартные транзакции.

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

Однако защиту от аналогичных проблем требуется обеспечивать и при ручной обработке данных пользователями с использованием их клиентских приложений. Основное отличие здесь заключается в том, что каждый пользователь работает не напрямую с данными, содержащимися в СУБД, а с некоторой их локальной копией, загруженной в клиентское приложение. Зачастую это приводит к тому, что когда два пользователя сохраняют изменения в одном и том же элементе данных (причем их исправления могли касаться разных его свойств), более раннее изменение теряется, причем клиент, чье изменение потеряно, может некоторое время этого даже не видеть.

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

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

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

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



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

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

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


Содержание раздела