4 に答える
これは、 Chain of Responsibilityのケースのように見えます。各立法府のハンドラーが必要です。最初にアプリケーションを最新のハンドラーに渡します。古すぎる場合は、前の立法府のハンドラーに渡されます。
いくつかのパターンを使用できます。たとえば、一時的なプロパティ パターンを使用して、特定の時点でアクティブなビジネス ルールを含むオブジェクトに作成できます。また、指定パターンを使用すると、特定の日付に基づいて有効になるビジネス ルールを作成できます。特定のポリシーが適用されるかどうかを決定できるように、有効日の範囲を各ポリシーに関連付けることができます。本の分析パターンには、シナリオに適用できる多くのパターンが含まれています。
編集: 一時的なプロパティではなく、一時的なオブジェクトパターンにリンクするつもりでした。これにより、データベース マッピングの実装が明らかになる可能性があります。
ルールが複雑な場合は、(ビジネス) ルール エンジンが必要になる場合があります。あなたのプラットフォームにどのような実装が存在するかはわかりませんが、Java の場合、典型的な選択肢はDroolsとそのExpert サブプロジェクトです。ルールを定義するためのドメイン固有の言語を定義します。Java 以外のユーザー向けのインターフェースがある場合があることに注意してください。
それ以外の場合は、Strategy パターンのようなものを試すことができます。2 つのメソッドappliesTo(date)とhandle(data). リストを反復し、戦略が日付に適用できる場合は、データを処理させます。
アーキテクチャ レベルでは、この問題を解決するための 2 つのアプローチがあります。
1 つ目は、ビジネス ロジックがデータに適用される前に、データを Warehouse に ETL することです。私はこのアプローチを好みます。
ただし、これができない場合もあります。つまり、データが OLTP (データ ウェアハウスに入力するために使用されるソース) に書き込まれる前にビジネス ロジックがデータに適用されるため、選択の余地がありません。この場合、この問題は通常、急速に変化するディメンションの問題と呼ばれます。(ここでの私の仮定は、あなたの質問で言及されているデータは、ファクト テーブルではなくディメンション テーブルに格納されているということです)。
この件に関しては、膨大な数の解説が Web で入手できます。これらのソースの中で、 Ralph Kimballによる記事 (無料) または書籍 (無料ではない) をお勧めします。
急速に変化する側面を調整する最善の方法は、ほぼ確実に事実固有のものです。それでも、おそらく最も一般的な手法は、新しいビジネス ロジックに対して適用されるデータを格納する新しいディメンション テーブルを作成することです。つまり、ビジネス ルールごとに個別のディメンション テーブルを DW スキーマに含めることになります。