一個好的數據模型應該考慮處理的業務流程的上下文，然后用通知支持該流程的決策所需的數據類型來處理該上下文。但是實現這個過程并不是這么容易的。

長期以來，數據模型一直是數據工程師和數據科學家的抽象領域。造成混淆的部分原因是，總是在模型的技術（或物理）結構中討論數據模型。物理上，指的是數據元素和數據集的技術名稱，數據庫和數據轉換的技術名稱，以及最終用戶和許多IT員工幾乎不了解或不了解的R和Python等編程語言的術語。

這導致公司無法承受的用戶和IT業務分析師隊伍中對數據模型的原始恐懼，這種恐懼阻礙了針對企業最終目標的數據模型的開發，而這種模型并沒有進入數據技術領域，很少有人會從中受益。要改變這種思維方式，業務分析師必須直接參與定義數據模型-但他們不必在業余時間參加數據科學和編程課程來完成這項工作。

定義業務需求

數據模型需要解決什么業務問題？這是一個自動化的貸款決策過程嗎？還是針對特定牛群的牛飼料中使用的最佳配料的配方設計師？

業務分析師最有能力與用戶合作并可視化所需的業務流程和數據。分析人員還可以用簡單的英語描述這些需求。得到的結果是一個邏輯數據模型，通常以氣泡圖的形式顯示所需的不同數據，并附帶說明以解釋如何處理數據。

在執行此操作時，業務分析師仍將重點放在業務需求上。不必擔心必須使用哪些數據集，系統或編程模塊來實現業務模型。

與IT和數據科學合作

一旦形成了數據氣泡的邏輯圖表，并描述了處理該數據需要發生的情況，業務分析師就會與IT或數據科學見面。

這些人將數據模型的邏輯模型轉換為物理模型，以IT術語定義了數據存儲，系統內部，需要編寫的程序等。

IT工程師和數據科學家需要此物理數據模型來完成工作，但是對業務分析師的需求卻很少。業務分析師僅需要具有技術術語和流程的工作知識，可以與IT進行高層溝通，并充當與最終用戶的聯絡人，以確保保持數據模型和應用程序的開發不變當然還有業務用例。

試用并安裝數據模型的結果

數據模型和應用程序一旦構建，最終用戶就可以試用它們了。在此過程中，業務分析師扮演著至關重要的角色，充當用戶與IT /數據科學之間的聯絡人。在此過程中，將對分析應用程序進行微調，簽名，然后將其安裝在生產環境中。

在許多方面，業務分析師在數據建模中扮演的角色與分析師過去所做的工作并沒有太大的不同。分析師定義了用戶對應用程序的需求，闡明了基本的業務設計，通過IT擴展了流程，并最終在生產中試用和安裝了該應用程序。

盡管可能需要一些術語和技術來掌握與技術人員進行數據模型的討論，但是了解數據建模的基礎知識和詞匯并不困難。應該鼓勵CIO和業務分析人員，他們現在必須適應數據建模以及如何最好地為業務提供結果并灌輸對其用戶的信心。