Каждая логическая сущность предметной области
- физически реализуется как строк(а|и) в таблиц(е|ах) реляционной БД,
- имеет этап(ы) жизненного цикла, в течение котор(ого|ых) является действующей (активной, актуальной).
Например, запись справочника может быть активной в течение всего жизненного цикла – от ее создания до удаления, или до выведения системы из эксплуатации. А экземпляр мастер-данных (товар, партнер, сотрудник и т.д.), как правило, активен в течение некоторого периода времени, пока с ним работают бизнес-процессы (пока товар закупается или продается, пока партнер связан договорными отношениями, пока сотрудник не уволился, и т.д.).
Вообще говоря, в оперативных БД имеет смысл держать только сущности, жизненный цикл которых еще не закончился – то есть, либо активные в настоящий момент, либо потенциально активные в будущем. Когда же жизненный цикл логической сущности завершен, данные, которые представляют сущность, становятся историческими и должны перемещаться в хранилище данных. Это позволяет сохранять малый объем и высокую производительность оперативной БД.
Если активный период логической сущности совпадает с периодом ее жизненного цикла в БД, то помечать сущность как активную или неактивную нет необходимости – ведь она активна, пока существует. Если же бизнес-правила предполагают, что логическая сущность активна только в определенные периоды, то необходим способ для указания того, является ли сущность активной или неактивной в настоящий момент.
Чаще всего активность/неактивность логической сущности задается одним из двух способов:
- поле статуса,
- поля с первой и последней датами периода действия.
Также встречаются реализации, когда сущность имеет одновременно и поле статуса и период действия.
Поле статуса в общем случае
- принимает несколько значений, часть из которых характеризует сущность как активную, а другие – как неактивную;
- допускает не все, а только некоторые переходы между состояниями, то есть, изменение текущего значения на другое имеет ограничения.
Вырожденный частный случай – когда поле статуса принимает только два значения, "активно" и "неактивно", и при этом возможны переходы от каждого из этих значений к другому. Поскольку неактивная сущность может вновь стать активной, то такую сущность нельзя автоматически архивировать и удалять из БД. Иными словами, ни одно из значений поля статуса не является терминальным и не гарантирует, что сущность навсегда ушла в историю.
Другой пример: поле статуса принимает значения "создан", "выполняется", "завершен", и при этом переходы между состояниями возможны только в указанном порядке. Здесь значение "завершен" характеризует сущность как неактивную и представлющую только исторический интерес – а следовательно, сущность может быть автоматически архивирована и удалена из БД.
Итак, возможность возврата сущности из неактивного состояния в активное несовместима с автоматическим архивированием и удалением сущности из БД.
Изменение поля статуса с "активно" на "неактивно", или наоборот, немедленно изменяет состояние логической сущности – немедленно делает ее доступной или недоступной для бизнес-процессов. Тогда как второй из упомянутых способов – задание периода действия (активности) – позволяет заранее планировать дату и время начала и завершения действия сущности.
Сущность с периодом действия, который еще не наступил или уже миновал, – неактивна и игнорируеся бизнес-процессами. А сущность с периодом действия, включающим сегодняшнюю дату, активна и обрабатывается бизнес-процессами.
Устанавливать дату начала периода действия можно на любой из будущих дней (с осторожностью – на сегодня), а дату окончания периода действия – равной или большей дате начала. Невыполнение этих правил может привести к нарушению логической целостности данных в БД, как ее определяют бизнес-требования.
Если период действия, который остался в прошлом, нельзя изменить на период действия в будущем, чтобы снова активировать логическую сущность, то такая сущность может рассматриваться для автоматического архивирования и удаления из БД. Возможность для сущности изменить прошедщий период на будущий аналогична возможности изменить значение поля статуса с неактивного на активное.
В разных ситуациях могут быть полезны оба сценария: и немедленное активирование/деактивирование сущности при помощи изменения значения поля статуса, и активрование/деактивирование сущности "по расписанию" при помощи установки периода действия в будущем.
Если сущность имееет как период действия, так и поле статуса, то для нее возможны оба сценария. При этом сущность считается активной, если поле статуса имеет активное значение И период действия включает сегодняшнюю дату. Если одно из этих условий не выполняется – то сущность неактивна.
Активная сущность с периодом действия и полем статуса может быть временно деактивирована изменением значения поля статуса с "активно" на "неактивно", а затем активирована вновь. Это как на двери магазина, работающего с 10:00 до 22:00, посредине рабочего дня повесить табличку "учет" (и закрыть доступ покупателям), а через некоторое время снять ее (и открыть доступ).
Для полноты картины, рассмотрим промежуточный вариант между полем статуса со значениями "активно" и "неактивно" и периодом действия – одно поле с датой начала действия. Сущность с датой начала действия активна, если дата начала действия наступила, и неактивна – если дата начала действия не наступила или пуста. Очищая дату начала действия, пользователь немедленно деактивирует сущность. Устанавливая дату начала действия на один из будущих дней, пользователь планирует активирование сущности с указанной даты. (Аналогично, можно использовать и одно поле с датой завершения действия – только в этом случае указанная дата, при ее наступлении, будет деактививровать сущность.)
Следующая таблица суммирует возможности активирования/деактивирования сущностей тремя рассмотренными способами:
| Возможность | Поле статуса | Дата начала | Период действия | Период действия и Поле статуса |
|---|---|---|---|---|
| Активирование немедленное | + | + | + | + |
| Деактивирование немедленное | + | + | - | + |
| Активирование по расписанию | - | + | + | + |
| Деактивирование по расписанию | - | - | + | + |
| Уход сущности в историю | -/+ | - | -/+ | -/+ |
Уйдет ли сущность в историю с изменением значения ее поля статуса на неактивное – зависит от того, позволяет ли система вновь установить для сущности активный статус. Бывает и так и этак.
Уйдет ли сущность в историю с завершением периода действия – зависит от того, позволяет ли система изменить (отредактировать) период действия, оставшийся в прошлом, на будущий период. Как правило, системы запрещают изменения прошедших периодов, что согласуется с представлением о том, что прошлое и история неизменны. Однако, рассматривая период действия только как способ активирования и деактивирования сущности, можно игнорировать это представление.
Подводя итог.
При разработке процедур чистки оперативной БД, принимайте во внимание, позволяет ли система – и практикуют ли пользователи – повторное активирование ранее деактивированных сущностей. Если да, то согласовывайте с пользователями возможность удаления неактивных сущностей из оперативной БД.
Специалистам по данным необходимо знать жизненные циклы всех сущностей в оперативной БД и зафиксировать правила работы пользователей с теми сущностями, для которых система допускает повторое активирование. После чего автоматизировать контроль за выполнением этих правил пользователями.
Комментариев нет:
Отправить комментарий