В данном обзоре мы предлагаем определиться с терминами и понять разницу между концепциями версионирования и историчности в базах данных.
Часто можно услышать термин «версионирование данных в БД», но что именно скрывается за этой фразой?
Историчность — это сохранение истории состояния объектов в базе данных. Практически любой бизнес-объект подвержен изменениям, и для того, чтобы не утратить важную информацию о его характеристиках в определённые моменты времени, необходимо фиксировать историю этих изменений.
Существует несколько методов реализации историчности в базах данных, о которых вы можете подробнее узнать в ряде специализированных статей, например, тут.
Ниже приведен один из подходов, который, хотя и не является самым эффективным, вполне наглядно иллюстрирует суть процесса «сохранения истории».
Допустим, в системе существует таблица объектов, в которой каждому объекту присваивается уникальный код (object_code). Этот код может быть и составным, формируясь из нескольких полей.
В таблице также фиксируются два ключевых параметра типа даты: [дата с] и [дата по], которые определяют временные рамки существования конкретного состояния объекта. Эти поля могут хранить как обычные даты, так и дату с указанием времени.
Пример таблицы, поддерживающей историчность
Все записи с одинаковым кодом (object_code) — это состояния одного объекта.
Объект с кодом OBJECT_1 имеет 2 записи: с 1 января 2000 года по 28 февраля 2025 года он назывался «Наименование объекта 1», а затем 1 марта 2025 сменил свое название на «Новое наименование объекта 1».
Объект с кодом OBJECT_2 имеет всего одно состояние и никогда не изменялся.
Версионирование — это процесс, при котором один и тот же объект может существовать в нескольких версиях одновременно, подобно параллельным мирам. Рассмотрим на примере Хранилища Данных.
1 февраля 2025 года в систему была загружена информация из источника за январь 2025, на основе которой были проведены расчеты и составлены отчеты. Однако в марте этого же года данные за январь 2025 были скорректированы в источнике, и в хранилище поступила обновленная информация.
Важным моментом является то, что мы не можем заменить старые данные, полученные в феврале, новыми, поскольку отчеты, составленные ранее, должны оставаться в системе наряду с данными, на основании которых они были сгенерированы. В то же время нам необходима и новая версия данных за январь 2025 года, например, для подготовки квартального отчета. Вследствие чего у нас появились две версии информации за один и тот же период (январь 2025 года).
Существует несколько подходов к реализации версионирования. Один из распространенных методов включает создание таблицы версий, в которой фиксируются идентификатор версии и дата ее создания. Далее, в таблицах, подлежащих версионированию, добавляется ссылка на соответствующий идентификатор из этой таблицы.
Пример таблицы версий и версионированной таблицы фактов
В фактовой таблице fct_object первая и вторая строки (раскрашены на рисунке выше желтым цветом) относятся к первой версии данных, а третья и четвертая – ко второй. Данные в поле value_fact в этих строках разные, а значит и отчеты, сформированные на этих данных в феврале (по первой версии) и в апреле (по второй версии) будут разными.
Журналирование — это еще один способ анализа информации в ретроспективе. Хотя этот подход не является основной целью написания данного обзора, он все же заслуживает упоминания.
Обычно в таблицах журналов (логов) фиксируются данные на момент внесения изменений, а также их новые значения, дополненные информацией о том, кто и когда совершил эти изменения. Хотя такой подход иногда воспринимается как форма историчности, следует отметить, что он больше касается технических аспектов, в то время как истинная историчность связана с бизнес-датами.
Пример таблицы журналирования
