Я только начал работать в правительственном агентстве, и у меня возникла интересная проблема: бизнес-правила зависят от законодательной власти, и поэтому они должны соблюдать точные периоды времени, в течение которых законодательная власть была активной.
Чтобы привести пример, если субъект подал заявку на субсидию на определенную дату, он должен быть оценен в соответствии с критериями, действующими на данную дату. Та же субсидия, для кого-то, кто применялся позднее, имеет разные критерии. Мне было интересно, существует ли известная схема, чтобы упорядочить эти временные правила. На данный момент код посыпается выражениями, похожими на:
if application.date >"July 17th, 2008"
Каков наилучший способ решения этой проблемы?
Это выглядит как случай для Цепочка ответственности. У вас будут обработчики для каждого законодательного органа. Сначала вы передаете приложение последнему обработчику. Если он слишком стар, он передает его обработчику предыдущего законодательного органа.
Вы можете использовать несколько шаблонов. Например, используя шаблон временных свойств, вы можете создать на объекте, который содержит бизнес-правила, которые активны в определенный момент времени. Кроме того, используя шаблон спецификации вы можете создавать бизнес-правила, которые действуют на определенную дату. Вы можете связать диапазон эффективной даты с каждой политикой, чтобы можно было принять решение о применении данной политики. В книге Шаблоны анализа содержится много шаблонов, которые могут быть применимы в вашем сценарии.
EDIT: Я хотел бы ссылаться на временный объект вместо височного свойства. Это может пролить свет на реализацию сопоставления базы данных.
Если правила сложны, вам может понадобиться (бизнес-правила). Я не знаю, какие реализации существуют для вашей платформы, но для Java типичный выбор Drools и его Экспертный подпроект. Он определяет язык, специфичный для домена, для определения правил. Обратите внимание, что он может иметь интерфейс для пользователей, не являющихся java.
В противном случае вы можете попробовать что-то вроде Стратегия стратегии - у вас есть список стратегий с двумя методами appliesTo(date) и handle(data). Вы перебираете список и если стратегия применима к дате - пусть она обрабатывает данные.
На уровне архитектуры существует два подхода к решению этой проблемы.
Во-первых, это ETL-данные для вашего склада до того, как бизнес-логика применяется к данным. Я предпочитаю этот подход.
Иногда, однако, это невозможно сделать - например, бизнес-логика применяется к данным перед ее записью в OLTP (источник, используемый для заполнения хранилища данных), поэтому у вас нет выбора. В этом случае эту проблему обычно называют проблемой быстро меняющейся размерности. (Мое предположение заключается в том, что данные, указанные в вашем вопросе, хранятся в таблице измерений, а не в таблице фактов).
Существует огромное количество комментариев по этому вопросу, доступных в Интернете. Среди этих источников я рекомендую любую из статей (бесплатно) или книги (не бесплатно) Ральф Кимбалл.
Лучший способ согласования быстро меняющегося измерения почти наверняка специфичен; тем не менее, возможно, наиболее распространенным методом является c * создание новой таблицы измерений *, которая хранит данные, применяемые к новой бизнес-логике. Другими словами, у вас в вашей схеме DW будет отдельная таблица измерений для каждого бизнес-правила.