使用數據倉庫暫存數據庫作為操作數據的來源
您是否應該使用數據倉庫中的臨時數據庫作為操作數據的來源？
即，其他操作（非 BI）系統從該數據庫中獲取數據是一種良好的做法嗎？還是那裡的數據倉庫用於資訊報告/分析，而絕對不是用於資訊處理/提供給其他系統的？
一般來說，從數據倉庫系統的任何部分獲取運營數據是一種好的做法嗎？或者數據倉庫應該只是數據的消費者？
有一個論壇討論簡短但很好地討論了這個 IMO：Tek Tips - Using a data warehouse as a source system
需要考慮的幾點：
重複勞動/單一事實來源
作業系統是否需要對數據倉庫已經在執行的源數據應用相同的邏輯？
只讀源
作業系統是否期望將更改/更新寫回倉庫？
及時資訊
作業系統對倉庫的延遲滿意嗎？（一般為T-1）
服務水平協議
如果倉庫出現故障，對作業系統有何影響？根據我的經驗，倉庫本質上比事務系統具有較低的優先級，例如，可能有長達 24 小時的可用時間（用於查詢）和長達 4 天的 ETL 恢復、執行和倉庫保持最新。
如果作業系統是內部的且非關鍵的，這可能是可以接受的。如果它是面向客戶的，並從倉庫中檢索外匯匯率進行定價，則可能不是。
我認為該論壇文章中的引述總結得很好：
企業根據他們的要求推動技術解決方案。
您的角色是向企業提供事實。如果企業願意接受風險並繼續使用數據倉庫作為作業系統的來源，那麼我建議您以書面形式獲取並一式三份。
一個“兩全其美”的解決方案是讓倉庫在處理完數據後發布數據，以供作業系統使用。數據可以提取到文件或複製到另一個/作業系統的數據庫。這假設您的倉庫不是“實時的”。
我必須承認，每當有人建議將作業系統連接到我們的倉庫時，我都會大吃一驚。在我們的環境中，我們做出了不控制使用者如何使用數據的架構決策，前提是它不會不公平地影響我們的 ETL 流程或其他使用者。作業系統變成了另一個“使用者查詢”，因此我們為可用性和準確性提供與財務初級分析師 Joe Bloggs 相同的服務水平。
如果使用者需要更高級別的服務，那麼我們提供數據（通過 FTP 文件）而不是使用者提取數據（通過查詢/直接訪問）。這有助於對未來變化進行影響分析，因為這些摘錄在我們的 ETL 工具/套件中是可見的。