データウェアハウスのビジネスロジック
私の質問は：
ビジネスロジックはデータウェアハウスのデータストアに保存する必要がありますか？それとも、レポートアプリケーションにのみ存在する必要がありますか？
より具体的な例を挙げます。
CRM運用システムには、リードとオポチュニティ、およびリードステータスとオポチュニティステージの抽象的な概念があります。これらの概念は非常に一般的でよく理解されており、さまざまなCRMツールで使用されています。
また、ビジネスユーザーは、ステータス「生のリード」からステータス「インサイドセールス適格リード」へのすべてのリードのコンバージョン率など、合法的に質問することができます。
次に、データウェアハウスの設計者にとって、質問は次のようになります。1。呼び出し後に誰かがリードステータスをxからyに変更した場合、それはファクトテーブルのどこかの行である必要がありますか？ （おそらく呼び出しと同じ行に）はいの場合、ファクトテーブルに、実際のイベントだけでなく、抽象的なビジネス概念を格納しています。 2.そして、より大きな問題は、データウェアハウスが「リード」や「機会」などの用語を認識している必要があるかどうかです。はいの場合-2。ファクトテーブルにold_statusとnew_statusの列を含める必要がありますか？ 3.または、ステータスの変更はゆっくりと変化するディメンションとして処理する必要がありますか？
ビジネスロジックがデータウェアハウスに直接保存されている場合、多くのビジネス上の質問が簡単になります。 （リードステータス変換メトリック、機会ステージ進行速度メトリックなど）しかし、変更に対してより脆弱であり、実装がより複雑であり、おそらく「動詞は事実であり、名詞は次元である」パラダイムを汚染しているようです。
この設計にどのようにアプローチする必要がありますか？また、ここでのベストプラクティスと指針となる原則は何ですか？
マックス
私の答えは大いにあります。ビジネスロジックをデータウェアハウスに保存する必要があります。それは、そもそもデータウェアハウスのアイデアの1つです。リードを表示またはフィルタリングするレポートが数十ある場合は、誰かをリードとして認定するルールが変更されるかどうかを想像してください。また、さまざまなツール/システムを使用してDWHデータにアクセスする必要がある場合は、すべてのロジックを複製する必要があります。最後に、この種のラベルの計算には時間がかかる可能性があるため、レポートを高速に実行するために、すべてをDWHで事前計算する必要があります。
最初の質問に答えるには-はい、SCDを使用する必要があります。いくつかのアプローチがあり、要件に最も適したものを選択する必要があります。ユーザーがデータを分析する方法がすべてです（ここから設計を開始する必要があります。
私のアプローチは常に、データベース層にできるだけ多くのビジネスロジックを格納することでした。これは、レポートレイヤーを変更した場合、すべてのビジネスルールを書き直す必要があるためです。データベースではなく部門が認識しているので、データベース層よりもレポート層を変更する可能性が高くなります。また、多くの企業が複数の異なるBIレポートソリューションを使用していることもわかりました。つまり、ルールを繰り返さずに保存できるのはデータベースだけです。ここでデータベースレイヤーについて話しているときは、キューブについても言及しています。