以下是数据库表设计中 概念模型、逻辑模型、物理模型 的完整对比,涵盖 目标、主要内容、所处阶段、面向人群、数据库无关性 五个维度,清晰明了,便于工程实践参考:
📊 三模型对比总表
| 维度 | 概念模型(Conceptual Model) | 逻辑模型(Logical Model) | 物理模型(Physical Model) |
|---|---|---|---|
| 目标 | 理解和表达业务需求,建立统一的业务语义 | 定义系统数据结构,支持功能实现 | 指导数据库实际建表与部署 |
| 主要内容 | - 实体(Entity) - 实体间关系(Relationship) - 业务规则 - 属性(不定义类型) (常用 ER 图表示) | - 表名、字段名 - 字段数据类型(如整型、字符串、日期) - 主键、外键 - 唯一约束、非空约束 - 可选:索引、视图、逻辑关系 | - 具体 DBMS 数据类型(如 VARCHAR(255)、BIGINT) - 存储引擎(InnoDB/MyISAM) - 字符集(utf8mb4) - 分区策略、表空间 - 索引类型(B+树、全文索引) - 默认值、自增、注释等 |
| 所处阶段 | 需求分析阶段 / 架构初期 | 概要设计阶段(High-Level Design) | 详细设计阶段 / DBA 实施阶段 |
| 面向人群 | 业务分析师、产品经理、领域专家、架构师 | 系统架构师、后端开发、测试工程师 | DBA、运维工程师、性能优化工程师 |
| 数据库无关性 | ✅ 完全无关(纯业务视角) | ✅ 技术中立(不绑定 MySQL/Oracle/PostgreSQL) | ❌ 强依赖具体 DBMS(语法、特性、限制) |
🔍 补充说明
1. 概念模型
- 关注"业务世界有什么",不关心如何存储;
- 示例: "用户"是一个实体,有"姓名""邮箱"属性;
"用户"与"订单"是一对多关系。
2. 逻辑模型
-
回答"系统需要哪些数据结构";
-
是概要设计文档的核心组成部分;
-
示例:
markdown表:user - user_id: 整型,主键 - email: 字符串,非空,唯一 - created_at: 日期时间
3. 物理模型
-
回答"在某数据库中如何建表";
-
由逻辑模型结合具体数据库特性细化而来;
-
示例(MySQL):
sqlCREATE TABLE user ( user_id BIGINT AUTO_INCREMENT PRIMARY KEY, email VARCHAR(128) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_email (email) ) ENGINE=InnoDB CHARSET=utf8mb4;
✅ 工程实践建议
- 概要设计文档 → 放 逻辑模型(含逻辑ER图 + 字段说明表);
- 详细设计文档 / DDL 脚本 → 放 物理模型;
- 需求规格说明书 → 可附 概念模型(用于对齐业务理解)。
💡 一句话总结 :
概念模型讲"业务",逻辑模型讲"结构",物理模型讲"实现"。概要设计重在"结构",故用逻辑模型。