如何管理資料模型與業務模型之間對映？

• 1. 概念模型
• 2. 規範化的核心概念模型
• 3. 邏輯資料模型

• 1.物理模型
• 2. 物理業務資料模型
• 3. 規範化的業務資料模型
• 4. 邏輯資料模型

上圖顯示了從業務部門的業務知識到檔案和資料庫結構的主要步驟和生成的步驟和工具。

1. 在克服部門孤島的過程中，邏輯企業模型Logic Enterprise Model發揮著核心作用。
與首先建立“完整”企業資料模型的方法相反，建議透過整合來自正在進行的業務專案的部分邏輯資料模型（Logic Data Model）來構建邏輯企業模型。
由於其核心作用，該整合過程和該模型的維護需要分配給中央業務單元，例如首席資料辦公室。
由於命名和定義是業務資料建模的必要部分，因此業務詞彙表是邏輯企業模型的隱含元件。(業務詞彙表類似DDD中無處不在的通用語言)

2. 如何遷移資料模型？
維護或遷移資料庫都需要了解其結構（表、列、鍵等）。“逆向工程”通常可以直接從資料庫中重新建立物理資料模型。
但是， 逆向工程過程可能會讓預期使用者感到沮喪，因為資料庫中的隱蔽、縮寫物理名稱很常見，並且不會揭示理解和記錄表和列用途所需的語義。此外，資料表的絕對數量可能是非常多。

3. 如何實現逆向工程？
無論是遷移，或者維護舊系統，唯一留下的模型可能就是資料庫的物理模型，從物理模型如何提煉識別物理業務資料模型？最佳策略是找到核心表（即具有多個關係的表）的含義，並從感興趣的子集中導航到相鄰物件。
可以獲得用邏輯名稱和定義豐富模型所需的業務語義：

• 作為逆向工程過程的一部分，如果資料庫的開發人員使用內聯文件功能（如 Oracle 或 SQL Server 支援的）。
• 來自資料庫外部來源（例如，ERP 系統通常將必要的業務資訊儲存在單獨的字典中）。