如何管理数据模型与业务模型之间映射?

业务领域有三种数据模型:

  • 1. 概念模型
  • 2. 规范化的核心概念模型
  • 3. 逻辑数据模型

对应于数据库中的模型:
  • 1.物理模型
  • 2. 物理业务数据模型
  • 3. 规范化的业务数据模型
  • 4. 逻辑数据模型

业务领域模型对应数据库模型的关系图如下:

上图显示了从业务部门的业务知识到文件和数据库结构的主要步骤和生成的步骤和工具。

1. 在克服部门孤岛的过程中,逻辑企业模型Logic Enterprise Model发挥着核心作用。
与首先创建“完整”企业数据模型的方法相反,建议通过集成来自正在进行的业务项目的部分逻辑数据模型(Logic Data Model)来构建逻辑企业模型。
由于其核心作用,该集成过程和该模型的维护需要分配给中央业务单元,例如首席数据办公室。
由于命名和定义是业务数据建模的必要部分,因此业务词汇表是逻辑企业模型的隐含组件。(业务词汇表类似DDD中无处不在的通用语言)

2. 如何迁移数据模型?
维护或迁移数据库都需要了解其结构(表、列、键等)。“逆向工程”通常可以直接从数据库中重新创建物理数据模型。
但是, 逆向工程过程可能会让预期用户感到沮丧,因为数据库中的隐蔽、缩写物理名称很常见,并且不会揭示理解和记录表和列用途所需的语义。此外,数据表的绝对数量可能是非常多。

3. 如何实现逆向工程?
无论是迁移,或者维护旧系统,唯一留下的模型可能就是数据库的物理模型,从物理模型如何提炼识别物理业务数据模型?最佳策略是找到核心表(即具有多个关系的表)的含义,并从感兴趣的子集中导航到相邻对象。
可以获得用逻辑名称和定义丰富模型所需的业务语义:

  • 作为逆向工程过程的一部分,如果数据库的开发人员使用内联文档功能(如 Oracle 或 SQL Server 支持的)。
  • 来自数据库外部来源(例如,ERP 系统通常将必要的业务信息保存在单独的字典中)。

逆向工程就是利用一些业务用户的知识来对逆向模型进行语义化。