C# 开发视角：概念模型、逻辑模型、物理模型完整理解

C#开发视角：概念模型、逻辑模型、物理模型完整理解

这三者本质是数据分层设计思想，不只是数据库专用，写C#业务系统、三层架构、ORM（Dapper/SqlSugar/EF）每天都会碰到，从抽象到落地分三层：

一、三层从上到下关系

概念模型（最高抽象） → 逻辑模型（业务结构化） → 物理模型（机器存储实现）
层层细化，一层比一层贴近代码、数据库。

1. 概念模型 Conceptual Model（业务层、需求层）

核心定位

只描述业务实体与业务关系，完全不考虑数据库、不考虑C#类、不考虑字段类型，纯业务语言。
回答：系统里有哪些东西、它们之间是什么关系。

组成元素

实体、实体属性、实体关系（一对一/一对多/多对多）

举例（林业文件管理系统）

• 实体：操作员、文件、文件夹、操作日志
• 关系：一个操作员可以产生多条操作日志；一个文件夹包含多个文件
• 只关心业务含义，不提int、varchar、主键、外键、表结构

C#对应场景

需求文档、业务流程图、ER总图、领域需求描述、DDD领域实体粗划分。
没有任何代码、数据库细节，纯业务沟通模型。

2. 逻辑模型 Logical Model（业务代码/实体类层）

核心定位

把概念模型规范化、结构化，剥离存储细节，面向程序设计，对应C#实体类、DTO、领域Model。
确定：实体有哪些属性、字段含义、约束、关联关系，但不指定数据库类型、长度、存储引擎。

特点

1. 标准化，消除冗余（三范式）
2. 定义属性名称、业务约束（非空、唯一、枚举值）
3. 定义外键关联、导航关系
4. 不关心：数据库varchar(50)、自增主键、索引、分区、存储引擎

举例承接上面林业系统

操作员逻辑模型：

• OperatorId：操作员唯一标识
• OperatorName：操作员姓名（不能为空）
• Password：登录密码
• CreateTime：创建时间
  关联：日志持有OperatorId关联操作员

C#对应代码（逻辑模型载体）

// 这就是典型逻辑模型：业务实体，只定义业务属性和关联，无关数据库细节
public class Operator
{
    public long OperatorId { get; set; }
    public string OperatorName { get; set; }
    public string Password { get; set; }
    public DateTime CreateTime { get; set; }
    // 导航属性：一对多关系
    public List<OperateLog> Logs { get; set; }
}

• EF Core / SqlSugar 的 Entity 实体类 = 逻辑模型
• DTO、ViewModel 也属于业务侧逻辑模型变种
  只描述程序层面的数据结构，不绑定数据库存储规则。

3. 物理模型 Physical Model（数据库落地层）

核心定位

逻辑模型映射到真实存储介质（SQLite/SQL Server），完全面向数据库硬件、存储引擎。
增加所有底层存储细节，是最终建表脚本、数据库真实结构。

新增物理层专属信息

• 字段数据类型、长度、精度：varchar(32)、bigint、datetime
• 主键、自增标识、外键约束
• 索引、联合索引、唯一索引
• 字段默认值、是否允许NULL
• 表名、字段名映射、分表、分区、存储引擎
• 字符集、排序规则

承接例子：操作员物理模型（SQLite建表）

CREATE TABLE Operator(
    OperatorId BIGINT PRIMARY KEY AUTOINCREMENT,
    OperatorName VARCHAR(20) NOT NULL,
    Password VARCHAR(64) NOT NULL,
    CreateTime DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
);
CREATE INDEX idx_operator_name ON Operator(OperatorName);

C#对应场景

1. ORM特性标记（映射物理存储规则）

[SugarTable("Operator")] // 物理表名
public class Operator
{
    [SugarColumn(IsPrimaryKey = true, IsIdentity = true)] // 物理主键自增
    public long OperatorId { get; set; }

    [SugarColumn(Length = 20, IsNullable = false)] // 物理字段长度、非空
    public string OperatorName { get; set; }

    [SugarColumn(Length = 64, IsNullable = false)]
    public string Password { get; set; }

    [SugarColumn(IsNullable = false, DefaultValue = "CURRENT_TIMESTAMP")]
    public DateTime CreateTime { get; set; }
}

2. 数据库迁移脚本、建库语句、索引优化脚本
3. 数据库性能调优相关设计（分表、索引、字段压缩）

二、三层模型完整流转（C#开发标准流程）

1. 概念模型：和业务、客户沟通，梳理有哪些业务对象、关系（无代码无库）
2. 逻辑模型：抽象成C#实体类、领域模型，规范属性、关联、业务校验（只关心程序业务）
3. 物理模型：给实体加数据库映射特性，生成建表SQL，设计索引、字段类型，落地到数据库存储

三、一句话区分记忆

1. 概念模型：客户看得懂的业务名词（什么东西、有什么关系）
2. 逻辑模型：程序员看得懂的C#实体类（程序里数据长什么样）
3. 物理模型：数据库看得懂的表结构（硬盘里数据怎么存）

四、常见开发误区

1. 混淆逻辑与物理：在实体类里写死数据库长度、索引逻辑，破坏分层，换数据库就要改实体
   规范做法：逻辑实体只保留业务属性，物理映射单独用特性/配置类分离
2. 跳过概念模型直接建表：需求一变，表和实体全部重构，扩展性极差
3. DDD领域实体 = 逻辑模型；数据库表 = 物理模型；需求ER图 = 概念模型

五、拓展：对应三层架构关系

• 概念模型 → 需求层 / 领域需求
• 逻辑模型 → 业务层 Model / DTO
• 物理模型 → 数据访问层（Dapper/EF/SqlSugar）+ 数据库表结构