我們剛剛開始組建一個數據倉庫，這對於我們的報告要求非常有用，可將不同的數據源組合在一起。OLTP應用程序讀取數據倉庫數據設計
回顧一下數據的潛在用途，我們發現了一些潛在的情景，其中一些事務處理系統可以以有用的方式引用這些數據。很顯然，數據會過時，並針對讀取進行優化，但是在某些情況下，這對應用程序而言是很好的，並且可以減少核心服務器上的負載。
我的問題是：這是否被認爲是交易系統訪問存儲在數據倉庫中的數據的糟糕設計？顯然，我們倉庫的主要目的是報告，這讓我懷疑是否應該允許其他非報告系統讀取數據。我的直覺引導我遠離允許應用程序讀取和顯示數據，是否有充分理由傾聽他們？！
讓您的OLTP系統訪問DW數據並沒有錯，事實上，隨着系統的發展，您將看到事務處理和信息系統之間的界限模糊。
我也不會太擔心數據結構，只要你想出一些有用的東西。 3 NF可能是答案，但從多維數據庫訪問高度概括的數據可能也是一個很好的解決方案 - 取決於您嘗試解決的問題。
要考慮的最後一件事是您試圖從數據倉庫中獲取的數據類型。是彙總交易（例如平均銷售額）還是更像共享尺寸數據（例如客戶名稱和地址）？如果是後者，您可能需要考慮將主數據管理策略與數據倉庫策略相結合。
還有一件事，試着弄清楚爲什麼你在這些數據庫之間共享數據猶豫不決。這是你可以把手放在什麼地方，還是僅僅因爲你已經接受了我們行業的培訓，認爲他們需要分開？請記住，最終，我們的工作並非真正建立數據倉庫&商業智能系統;他們將以可靠，務實，節約成本的方式解決業務問題。
使倉庫成爲應用程序數據使用者以及分析數據使用者的中心沒有任何根本性的錯誤。以下是需要考慮的一些問題。
您需要一個技術解決方案來支持所需工作負載級別的可用性，事務隔離和一致性。例如。您能否確保應用程序不會遏制資源的分析查詢，反之亦然？即使在倉庫裝載期間，您是否能夠以一致且及時的方式將數據提供給應用程序？假設你能夠在幾小時內加載倉庫是不明智的 - 即使你認爲你今天可以做到這一點。
確保您的倉庫正常化（意味着至少Boyce-Codd /第五範式或接近它的東西）。對於任何倉庫來說這都是很好的建議，但尤其是如果您需要支持非分析性查詢的話。
您的應用程序是否需要更新倉庫？如果是這樣，那麼您需要考慮如何與ETL過程的其他部分集成。
考慮是否給應用程序一個自己的數據集市。這可能是最安全的選擇。