数据建模是为整个或部分信息系统创建可视化表示形式的过程，用于表明数据点和结构之间的联系。 其目的在于说明系统中使用和存储的数据类型、这些数据类型之间的关系、数据的分组和组织方式及其格式和属性。

数据模型是根据业务需求构建的。 规则和需求是通过业务利益相关方的反馈预先加以定义的，因此可纳入到新系统的设计之中，或者在现有系统迭代时进行调整。

可以在不同的抽象层次上对数据进行建模。 该过程首先会从利益相关方和最终用户那里收集业务需求相关信息。 然后再将这些业务规则转换为数据结构，制定出具体的数据库设计。 数据模型就好比是路线图、架构师的蓝图，或任何有助于更深入理解设计内容的正式图表。

数据建模采用标准化模式和正规方法。 这为定义和管理整个组织乃至组织之外的数据资源提供了一种通用、一致且可预测的方式。

理想情况下，数据模型是随着业务需求的变化而不断演变的文档。 在支持业务流程和规划 IT 架构及战略方面，它们发挥着重要的作用。 数据模型可以与供应商、合作伙伴和/或业内同行共享。

像任何设计过程一样，数据库和信息系统设计从一个很高的抽象层次开始，然后逐渐变得越来越具体且明确。 数据模型一般可以分为三类，具体因抽象程度而异。 该过程将从概念模型开始，然后发展到逻辑模型，最终是物理模型。 下面将更详细地讨论数据模型的各种类型：

• 概念数据模型。 这也称为领域模型，可围绕系统将包含的内容、如何组织这些内容和涉及哪些业务规则提供一个全局视图。 在收集初始项目需求的过程中，通常会创建概念模型。 通常情况下，它们包含实体类（定义要在数据模型中表示而且对业务至关重要的事物类型）、其特征和约束、彼此之间的关系以及相关的安全性和数据完整性要求。 所有符号通常都很简单。

   

• 逻辑数据模型。 它们不是那么抽象，而是提供了有关所考虑领域中的概念和关系的更多细节。 需要采用某种正式的数据建模符号系统。 这些模型表明了数据属性，例如数据类型及其对应的长度，并显示了实体之间的关系。 逻辑数据模型不会指定任何技术系统要求。 在敏捷或  DevOps  实践中，这个阶段通常会被忽略。 逻辑数据模型可用于高度程序化的实现环境，或者用于本质上面向数据的项目，例如 数据仓库设计 或报告系统开发。

   

• 物理数据模型。 它们为如何在数据库中实际存储数据提供了一种模式。  因此，它们的抽象度最低。 它们提供了能够以 关系数据库形式实现的最终设计，包括说明实体之间关系的关联表，以及用于保证这些关系的主键和外键。 物理数据模型可以包含特定于数据库管理系统 (DBMS) 的属性，包括性能调优。

作为一门学科，在数据建模过程中，会邀请利益相关方十分细致地评估数据处理和存储。 数据建模技术具有不同的约定，这些约定规定了使用哪些符号来表示数据、模型的布局方式以及业务需求的表达方式。 所有方法都提供了正式的工作流，其中包括以迭代方式执行的一系列任务。 这些工作流通常如下所示：

1. 确定实体。 在数据建模过程中，一开始应确定要建模的数据集中表示的事物、事件或概念。 每个实体都应该是连贯的，并且在逻辑上与所有其他实体分开。
2. 确定每个实体的关键属性。 每种实体类型都可以与所有其他实体类型区分开来，因为它具有一种或多种特有的性质，即属性。 例如，名为"客户"的实体可能具有名字、姓氏、电话号码和称呼等属性，而名为"地址"的实体则可能包括街道名称和门牌号、城市、州、国家和邮政编码。
3. 确定实体之间的关系。 最早的数据模型草案将指定每个实体与其他实体之间关系的性质。 在上面的例子中，每个客户"居住于"一个地址。 如果将该模型扩展为包含一个名为"订单"的实体，那么每个订单也会被运送到一个地址并开具账单。 这些关系通常使用统一建模语言 (UML) 进行记录。
4. 将属性完全映射到实体。 这将确保模型反映企业使用数据的方式。 若干正式的数据建模模式目前已被广泛使用。 面向对象的开发人员经常应用分析模式或设计模式，而来自其他业务领域的利益相关方则可能会转向其他模式。
5. 根据需要分配键，并决定用于平衡减少冗余需求与性能要求的规范化程度。 规范化是一种用于组织数据模型（及其表示的数据库）的技术，它会将名为"键"的数字标识符分配给数据组，用于表示它们之间的关系，而无需重复数据。 例如，如果为每个客户都分配了一个键，那么该键可以链接到他们的地址及其订单历史记录，而无需在客户名称表中重复此信息。 规范化往往会减少数据库所需的存储空间量，但也会以牺牲查询性能为代价。
6. 完成并验证数据模型。 数据建模是一个迭代过程，应该随着业务需求的变化而不断重复并优化。

数据建模与数据库管理系统一同演变，随着企业数据存储需求的不断增长，模型类型也日渐复杂。 以下是几种模型类型：

• 分层数据模型 以树状格式表示一对多关系。 在这种类型的模型中，每条记录都有一个映射到一个或多个子表的根或父项。 该模型在 IBM 信息管理系统 (IMS) 中实现，于 1966 年推出，并迅速得到广泛使用，尤其是在银行业。 尽管这种方法的效率低于最近开发的数据库模型，但它仍在可扩展标记语言 (XML) 系统和地理信息系统 (GIS) 中使用。
• 关系数据模型 最初由 IBM 研究员 E.F. Codd 在 1970 年提出。 如今，企业计算中常用的许多不同关系数据库中仍在实现这种模型。 关系数据建模无需详细了解正在使用的数据存储的物理属性。 这里的数据段通过使用表显式连接起来，降低了数据库的复杂性。

关系数据库经常使用结构化查询语言 (SQL) 进行数据管理。 这些数据库可以很好地维护数据完整性，并最大限度地减少冗余。 它们通常用于销售终端系统以及其他类型的交易处理。

• 实体关系 (ER) 数据模型 使用形式化图表来表示数据库中实体之间的关系。 数据架构师使用多种 ER 建模工具来创建可视图，传达数据库设计目标。
• 面向对象的数据模型 以面向对象的编程方式赢得了关注，并于 20 世纪 90 年代中期开始流行。 所涉及的"对象"是对现实世界实体的抽象。 这些对象归入不同的类层次结构，并具有相关的特征。 面向对象的数据库可以合并表，但也可以支持更复杂的数据关系。 这种方法可用于多媒体和超文本数据库以及其他用例。
• 维度数据模型 由 Ralph Kimball 开发，旨在优化数据检索速度，以在 数据仓库中展开分析。 虽然关系模型和 ER 模型都强调高效存储，但维度模型却增加了冗余，以便更轻松地定位信息，进行报告和检索。 这种建模通常用于 OLAP 系统。

两种流行的维度数据模型都是星型模式，其中数据被组织成事实（可测量项目）和维度（参考信息），每个事实都被其关联的维度以星形模式所环绕。 另一种是雪花模式，它类似于星型模式，但包括关联维度的附加层，使得分支模式更加复杂。

通过数据建模，开发人员、数据架构师、业务分析师和其他利益相关方可以更轻松地查看和理解数据库或数据仓库中数据之间的关系。 此外，它还可以：

• 减少软件和数据库开发中的错误。
• 提高整个企业内文档编制和系统设计的一致性。
• 改进应用和数据库性能。
• 简化整个组织内的数据映射。
• 增进开发人员和商业智能团队之间的沟通。
• 在概念、逻辑和物理级别简化并加快数据库设计过程。

数据建模工具

如今，许多商业和开源计算机辅助软件工程 (CASE) 解决方案都得到了广泛应用，包括多种数据建模、图表和可视化工具。 以下是一些示例：

• erwin Data Modeler 是一种基于 Integration DEFinition for information modeling (IDEF1X) 数据建模语言的数据建模工具，该语言现在支持其他符号方法，包括维度方法。
• Enterprise Architect 是一种可视化建模和设计工具，支持对企业信息系统和架构以及软件应用和数据库进行建模。 它基于面向对象的语言和标准。
• ER/Studio 是数据库设计软件，可与当今几种最流行的数据库管理系统相兼容。 它支持关系和维度数据建模。
• 免费的数据建模工具 包括开源解决方案，例如 Open ModelSphere。