Транзакционные и нетранзакционные данные
Для решения задачи отслеживания всех производимых модификаций разумно использовать технологии темпоральных баз данных. Но на сегодняшний день полноценные промышленные реализации темпоральных баз данных, по сути, отсутствуют. Что любопытно, они вполне могли появиться лет пять-десять назад, но в силу модных тенденций в сфере управления данными, сместивших акценты в сторону поддержки XML и решения задач интеграции, темпоральные технологии остались в стороне. Некоторые современные СУБД содержат специализированные механизмы, которые позволяют использовать фоновую версионность значений атрибутов. Однако ее далеко не всегда удобно использовать.
Но важнее другое – реляционная модель данных предоставляет весьма широкие средства, которые вполне могут быть использованы для решения перечисленных выше проблем. Может быть, и не стоит искусственно расширять эту модель дополнительной временной размерностью?
Данные, обрабатываемые в каждой информационной системе, можно разделить на транзакционные и нетранзакционные. Транзакционные данные – это данные, каждая запись которых относится к фиксированному моменту времени и содержит сведения, фиксированные на данный момент времени, не изменяющиеся в будущем. Соответственно, нетранзакционными являются все остальные данные.
Транзакционные данные обычно представляют собой повторяющиеся примеры событий, явлений, происшествий одного и того же типа. Сюда относятся все заявки, счета, накладные – да и вообще все документы (как сущности), так как все они зафиксированы (это уже оформленные документы) и привязаны к некоторому моменту времени (времени их составления или регистрации).
Нетранзакционные данные, которые часто называют справочными или базовыми данными, представляют собой списки однотипных объектов: сущностей, предметов и абстрактных категорий. Как правило, это разнообразного рода справочники и классификаторы, другими словами – мастер-данные или, как частный случай, нормативно-справочная информация.
Нетрудно заметить, что связь между этими двумя категориями данных, как правило, односторонняя: при описании транзакционных схем могут использоваться как транзакционные, так и нетранзакционные данные, а при описании же нетранзакционных данных, как правило, используются только нетранзакционные данные.
Например, при составлении накладной используются несколько справочников (контрагентов, номенклатуры), а основанием для накладной может служить, например, счет.
С другой стороны, если не принимать во внимание конкретное информационное представление данных и процедуры их архивации и утилизации, то можно утверждать, что количество информационных объектов транзакционных данных постоянно увеличивается, так как регистрация каждого нового события вызывает появление новой записи. В то же время, количество информационных объектов нетранзакционных данных является относительно постоянным.
Значение каждой записи транзакционных данных, как правило, остается неизменным с момента ее фиксации. Исключения составляют случаи коррекции записи по причине неточностей или ошибок, что, кстати, в информационной системе обычно рассматривается как не совсем корректное действие – коррекция должна проводится отдельной операцией. Нетранзакционные данные не привязаны к конкретному моменту времени, но в течение своего жизненного цикла они могут определяться, а значения атрибутов каждого элемента таких данных могут изменяться.
Таким образом, проблема отслеживания модификаций, в основном, актуальна для нетранзакционных данных. Для транзакционных данных она имеет смысл лишь в части отслеживания исправлений.
Одной из основных причин появления проблем, связанных с представлением нетранзакционных данных, является то, что нетранзакционные данные часто воспринимаются как условно-постоянные и, как следствие, имеющие статичное представление в базах данных. Для записи данных в SQL используются операторы вставки (insert), изменения (update) и удаления (delete). Как правило, эти операторы используются весьма прямолинейно: появился новый объект – вставили новую запись, изменились его характеристики – обновили их, исчез объект – удалили запись. Справедливости ради, следует отметить, что для повышения ссылочной целостности вместо операции удаления в настоящее время все больше используется обновление дополнительного атрибута (статуса) записи.
Однако операция обновления тоже не безобидна. Прекращение существования объекта – это новая информация, и результатом должно быть не общее сокращение информации в базе данных, а наоборот, ее увеличение. Аналогично, при изменении характеристик одного из объектов поступает новая информация, и общий объем информации в базе данных также должен увеличиваться. То же самое можно сказать и про исправления. Другими словами, информационные элементы должны хранить информацию о жизненном цикле реальных объектов, а не повторять его.
Используя термины SQL, можно говорить, что для прекращения существования объектов и изменения их характеристик недопустимо использование операторов delete и update. Эти операторы являются служебными и должны использоваться исключительно в служебных целях: для перемещения, архивации и утилизации массивов данных. Таким образом, можно сделать вывод, что все данные, циркулирующие в базе данных, должны быть транзакционными; нетранзакционные данные должны представляться в виде цепочки транзакционных данных.
