Паттерн «периодические реквизиты»

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

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

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

Основ сущности

id

Attr1

…

Attr n

Периодический реквезит

Id_attr

Id_main_eatity

data

value

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

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

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

Select ФИО FROM ФИОсотрудника

WHERE id=… AND(dt<01.09)

ORDER BY dt DESC

LIMIT 1 offset 0

Решение проблемы 1. Проблема решается двумя способами. Первый – для первого запоминаемого значения периодического реквизита дата начала действия реквизита устанавливается на технический ноль дат. Проблемы с этим решением могут возникнуть при переносе данных с одной СУБД на другую(даже при переносе с одной версии одной и той же СУБД).

Семантически это решение может оказаться неверным. По нашему примеру, как минимум, мы укажем ФИО человеку на дату до его рождения.

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