數據倉庫中的業務邏輯
我的問題是：
業務邏輯是否應該儲存在數據倉庫數據儲存中？還是應該只存在於報告應用程序中？
舉一個更具體的例子：
在 CRM 作業系統中，存線上索和機會、線索狀態和機會階段的抽象概念。這些概念非常常見，很好理解，並在不同的 CRM 工具中使用。
業務使用者可以合法地提出問題，例如，從“原始潛在客戶”狀態到“內部銷售合格潛在客戶”狀態的所有潛在客戶的轉化率是多少。
那麼對於數據倉庫設計者來說，問題就變成了： 1. 當有人在呼叫後將潛在客戶狀態從 x 更改為 y 時，那應該是某處事實表中的一行嗎？（可能與呼叫在同一行）如果是，那麼我們在事實表中儲存抽象的業務概念，而不僅僅是現實世界的事件。2. 更大的問題是，數據倉庫是否應該知道“潛在客戶”和“機會”之類的術語？如果是—— 2. 事實表是否應該有 old_status 和 new_status 列？3. 或者，狀態變化是否應該作為一個緩慢變化的維度來處理？
如果業務邏輯直接儲存在數據倉庫中，很多業務問題就會變得更容易提出。（引導狀態轉換指標、機會階段推進速度指標等）但它似乎更易變化，實施起來更複雜，並且可能會污染“動詞是事實，名詞是維度”的範式。
我應該如何處理這個設計，這裡的最佳實踐和指導原則是什麼？
最大限度
我的回答是肯定的——你應該將業務邏輯儲存在數據倉庫中。這首先是數據倉庫的想法之一。如果您有數十份報告顯示或過濾潛在客戶，想像一下將某人定為潛在客戶的規則是否會發生變化。此外，如果您必須使用不同的工具/系統訪問 DWH 數據怎麼辦 - 您需要複製所有邏輯。最後，計算這種標籤可能很耗時，這就是為什麼您希望在 DWH 中預先計算所有內容以使報告快速執行。
要回答您的第一個問題 - 是的，您應該選擇 SCD。有幾種方法，您應該選擇最適合您要求的方法 - 這完全取決於使用者想要如何分析數據（這是設計應該開始的地方。