数据建模通常先从概念上表示数据，然后再通过选择的技术表示数据。分析师和利益相关者会在数据设计阶段创建几种不同类型的数据模型。以下是三种主要的数据模型类型：
概念数据模型
概念数据模型可全局概览数据。这类模型会说明以下内容：
系统包含的数据
数据属性以及针对数据的条件或约束
与数据相关的业务规则
数据的最佳组织方式
安全性和数据完整性要求
业务利益相关者和分析师通常会创建概念模型。它只是一个简单的图形表示，不遵循正式的数据建模规则。它的作用在于帮助技术和非技术利益相关者分享共同愿景，并就数据项目的目的、范围和设计达成一致。
概念数据模型示例
例如，汽车经销商的概念数据模型可能会显示如下数据实体：
“展厅”实体，表示经销商旗下各门店的信息
“汽车”实体，表示经销商目前库存的多辆汽车
“客户”实体，表示在经销商处购买汽车的所有客户
“销售”实体，表示关于实际销售的信息
“销售人员”实体，表示经销商处所有销售人员的信息
此概念模型还包括业务需求，例如以下信息：
每辆汽车必须属于一个特定的展厅。
每笔销售都必须至少有一名销售人员和一名与之关联的客户。
每辆汽车都必须具有品牌名称和产品编号。
每位客户都必须提供他们的电话号码和电子邮件地址。
因此，概念模型充当了业务规则与基础物理数据库管理系统（DBMS）之间的桥梁。概念数据模型也称作域模型。
逻辑数据模型
逻辑数据模型将概念数据类映射至技术数据结构。对于概念数据模型中确定的数据概念和复杂数据关系，它们给予了更详细地描述，例如：
各种属性的数据类型（例如，字符串或数字）
数据实体之间的关系
数据中的主要属性或关键字段
数据架构师和分析师共同协作，创建逻辑模型。他们在多个正式数据建模系统中选择一个，遵循该系统创建表示。有时候，敏捷型团队可能会选择跳过这一步，直接从概念模型转向物理模型。不过，这些模型对于设计大型数据库（称作数据仓库）和设计自动报告系统非常有帮助。
逻辑数据模型示例
在我们的汽车经销商示例中，逻辑数据模型对概念模型进行扩展并更深入了解数据类，如下所示：
“展厅”实体具有名称和位置等字段，这些是文本数据，而电话号码则为数字数据。
“客户”实体具有一个电子邮件地址字段，格式为 xxx@example.com 或 xxx@example.com.yy。字段名称不得超过 100 个字符。
“销售”实体具有客户姓名和销售人员姓名字段，销售日期采用日期数据类型，金额则采用十进制数据类型。
因此，逻辑模型充当了概念数据模型与开发人员用以创建数据库的基础技术和数据库语言之间的桥梁。但是，它们不依赖任何技术，您可以使用任何数据库语言进行实施。数据工程师和利益相关者通常会在创建逻辑数据模型后再做出技术决策。
物理数据模型
物理数据模型将逻辑数据模型映射到特定的 DBMS 技术并使用软件术语。例如，它们展现以下详细信息：
DBMS 中表示的数据字段类型
DBMS 中表示的数据关系
性能优化等其他详细信息
数据工程师会先创建物理模型，然后再进行最终设计实施。他们仍然会遵循正式的数据建模技术，以确保考虑到设计的各方各面。
物理数据模型示例
假设汽车经销商决定在 Amazon S3 Glacier Flexible Retrieval 中创建一个数据存档。他们的物理数据模型描述了以下具体信息：
在“销售”中，销售金额为浮点数据类型，销售日期为时间戳数据类型。
在“客户”中，客户姓名为字符串数据类型。
在 S3 Glacier Flexible Retrieval 术语中，Vault 是数据的地理位置。
您的物理数据模型还包括其他详细信息，例如您创建文件库时所在的 AWS 区域。 因此，物理数据模型充当了逻辑数据模型和最终技术实施之间的桥梁。