在软件工程中，数据建模（data modeling）是在设计数据库时，将现实世界各类数据及其关系进行分析、抽象，从中找出内在联系，并形式化描述为数据模型，建立信息系统的数据库结构的过程。
数据建模是一种用于定义和分析数据的需求及其所需相应信息系统的过程。它可被应用为更广义的模型驱动工程的一部分。 数据建模不仅定义数据元素，还定义它们的结构和相互关系。
概述
数据建模是一种过程，用于定义和分析支持组织内相应信息系统范围的业务过程所需的数据需求。因此，数据建模过程涉及专业数据建模人员与业务相关方及信息系统的潜在用户密切合作。
从需求到实际的数据库，有三种不同类型的数据模型
数据建模可分为两种类型：战略性数据建模（作为信息系统战略的一部分，定义整体愿景和架构）和系统分析中的数据建模（在开发新数据库时创建逻辑数据模型）。
数据模型与数据建模的关系
数据建模与数据模型是紧密相关但含义不同的两个概念。简而言之：数据建模是过程，数据模型是产物。
数据建模是创建数据模型的活动和方法论。它涉及对现实世界的数据需求进行分析、抽象，并运用特定建模技术（如实体-关系模型）产生相应的形式化描述。数据模型则是这一过程的输出——一个具体的、结构化的关于数据组织方式的描述。这种关系类似于软件工程与软件本身的关系：软件工程是开发过程，软件是最终产品。
根据惠顿等人的观点，数据建模有时也被称为数据库建模，因为数据模型最终要在数据库中实现。
- 概念模式：描述领域的语义，定义实体类及其之间的关系。概念模式限定了使用该模型可以表达的事实或命题的种类。
- 逻辑模式：描述信息的结构，包括表、列、面向对象类或XML标签的描述。逻辑模式和概念模式有时可合二为一。
- 物理模式：描述数据存储的物理手段，涉及分区、CPU、表空间等。
这三种模式相对独立——存储技术的变化可以不影响逻辑或概念模式；表/列结构的变化可以不（必然）影响概念模式。但所有模式对应同一数据模型的结构必须保持一致。
建模方法论
主流的数据建模方法论可分为自顶向下和自底向上两类：
- 自底向上（视图集成模型）：通常从现有的数据结构、表单字段或屏幕报表出发，构建物理的、面向特定应用的模型。其优点是与现有系统紧密对应，但可能缺乏企业全局视角，不利于数据共享。
- 自顶向下（逻辑数据模型）：通过从了解主题领域的人员处获取信息，以抽象的方式创建逻辑数据模型。系统可能不会实现逻辑模型中的所有实体，但该模型可作为参考点或模板。
许多项目采用混合方法：既考虑应用的数据需求和结构，又一致地参考主题领域模型。在某些环境中，逻辑数据模型和物理数据模型之间的界限并不清晰。
实体-关系（ER）图是数据建模中最常用的图形化表示方法之一，有多种表示法，如陈品山的ER表示法、巴克表示法和IDEF1X等。
常见问题
根据韦斯特和福勒（1999）的研究，数据建模中常见的问题包括：
- 业务规则被固化在数据模型的结构中，导致业务方式的微小变化就引起计算机系统和接口的大幅更改；数据模型应当足够灵活，使业务变化能相对快速高效地在模型中实现。
- 实体类型未被正确识别，导致数据、数据结构和功能的重叠，增加了开发和维护成本。数据定义应尽量明确且易于理解，以减少误解和重复。
- 不同系统的数据模型任意差异过大，导致共享数据的系统间需要复杂的接口：接口成本可占当前系统总成本的25%到70%。在设计数据模型时应将接口需求纳入考量。
- 数据无法与客户和供应商电子化共享，因为数据的结构和含义尚未标准化。
参见
- 数据模型
- 数据仓库
- 实体-关系模型
- 软件工程
参考文献
评论 (0)