数据库逻辑模型设计：从ER图到物理存储的完整实践指南

1. 为什么逻辑模型决定了数据库项目的大半成败

先说一个有点扎心的结论：很多数据库设计翻车，不是栽在SQL写不好、也不是服务器配置不给力，而是栽在逻辑模型阶段没有想清楚。我在实际项目里见过太多次——应用代码改了一茬又一茬，唯独表结构像打补丁一样越叠越厚，最后谁都不敢动。究其根源，基本都是逻辑模型这一步偷了懒。

逻辑模型是什么？它是介于业务需求和物理实现之间的那层"通用语言"。业务上描述"用户下单、订单包含多个商品"，逻辑模型就把它变成"客户实体、订单实体、商品实体，客户与订单是1:N关系，订单与商品是M:N关系"。它不关心数据最终存在MySQL还是Oracle里，也不关心用不用索引、怎么分表，只关心业务世界里的概念、规则和约束。

为什么要单独做这一层，而不是画完概念图直接建表？因为逻辑模型是所有后续工作的契约。程序员按它写业务代码，DBA按它设计物理存储，产品经理按它确认需求边界。如果这层契约是模糊的、有歧义的，下游所有环节都会拿各自的理解去实现，最后表结构、接口文档、代码逻辑三套说法，排查问题的时候你就知道什么叫痛苦。

还有一个经常被忽略的点：逻辑模型的修改成本，远高于代码的修改成本。代码错了改个方法、加个判断，影响范围是局部的；表结构错了要改字段、改数据、改索引、改接口、改缓存，一条链全要跟着动。尤其是上线之后已经有存量数据，改一张核心表的代价，往往能让一个小迭代变成一个"需要停服迁移"的大工程。所以在这个阶段多花几天，把模型磨清楚，是在给整个项目省钱。

这篇文章，我会按照自己实际做设计时的思路，把逻辑模型建模的核心要点、数据库系统架构的分层逻辑、存储结构的底层机制，以及从逻辑模型到物理存储的完整映射串起来讲一遍。内容偏基础但没有一句废话，适合刚接触数据库设计的人，也适合已经写过不少表、但想系统梳理一遍设计方法论的人。

2. 逻辑模型的建模核心：实体、属性、关系怎么落笔

2.1 实体识别：从业务描述里捞概念，而不是捞名词

实体（Entity）是逻辑模型的基本单元。但很多新手容易犯一个错误：把业务描述里出现的所有名词都当成实体。比如"用户点击购买按钮，系统生成订单，订单包含商品，商品属于分类"，这里"按钮""系统"显然不是实体，它们是动作载体或系统组件，不是我们需要持久化描述的业务概念。

我个人的经验是，判断一个词是不是实体，就问自己三个问题：

• 它有没有一组需要单独维护的、稳定的属性？比如"用户"有姓名、手机号、注册时间，明显需要；"按钮"没有属性需要维护，排除。
• 它在业务里是独立存在的概念，还是依附于另一个概念的描述？比如"订单明细"虽然离不开订单，但它本身承载数量、单价这些属性，有独立存在的必要。
• 业务规则里是否需要单独追踪它？比如"库存"，它既可以是商品的属性，也可以是一个实体，取决于你是只查当前库存量，还是需要记录库存变动的流水。要记录流水，就必须拆成实体。

还有一种情况是"弱实体"（Weak Entity）。它自己没有完整的主键，必须依赖父实体才能唯一标识。最典型的例子是订单明细：同一张订单下，明细可以有"明细编号"来区分，但如果没有订单号，这个明细编号没有任何全局意义。弱实体在逻辑模型里要用双线矩形表示，转换成关系模式时，它的主键是"父实体主键 + 局部标识"的复合主键。这一步处理不好，后面建表的时候主键设计就会纠结。

2.2 关系的维度：基数定对，模型就稳了一半

实体之间关系的核心是基数（Cardinality）和可选性（Optionality），这两者定义业务规则约束。

基数解决"一个A对应几个B"的问题，种类就三种：

• 1:1：一个A最多对应一个B，一个B最多对应一个A。比如"用户"和"用户详情"。
• 1:N：一个A对应多个B，一个B只属于一个A。比如"分类"和"商品"。
• M:N：一个A对应多个B，一个B也对应多个A。比如"订单"和"商品"，一张订单有多个商品，一个商品也出现在多张订单里。

可选性解决"是否允许不出现"的问题：是强制（Must）还是可选（May）。比如"订单"和"收货地址"，下单必须填地址，这是强制；"用户"和"优惠券"，用户可以不领券，这是可选。

基数定错的后果非常典型。我见过一个会员系统的设计，把"用户"和"角色"设计成1:1，理由是"一个用户只有一个角色"。后来业务要加"一个用户可以既是运营又是推广"，表结构只能硬改，加关联表，数据还得清洗。如果当初建模时多问一句"未来会不会有多个角色"，这个问题根本不会发生。设计时永远假设业务复杂度会上升，能拆M:N就尽量不要硬塞成1:N或1:1。

2.3 关系的转换规则：从ER图到关系模式的固定套路

逻辑模型最终要转成关系模式（也就是表结构），转换有一套约定俗成的规则，掌握了就不容易出错：

• 每个实体转成一张表，实体属性就是表字段。
• 1:1关系，可以把一方的外键放到另一方表中，也可以合并成一张表。如果两侧属性都不多且访问频率接近，合并更合适。
• 1:N关系，"一"方的主键作为外键放到"N"方表中。比如"分类"和"商品"，商品表里存分类ID。
• M:N关系，必须新建一张中间表，中间表的主键是两侧实体主键的组合（必要时再加一个自增主键），同时两侧实体的主键在中间表中都作为外键。比如"订单表、商品表、订单明细表"就是经典的三表结构。

这套规则看起来简单，但实际项目里最容易出问题的是：M:N关系被简化成"在A表中加一个逗号分隔的B_ID字符串"。这种设计在逻辑模型阶段就错了，因为它违反了第一范式，后续查询、统计、关联全都要写恶心的字符串处理逻辑。我极力反对这种"图省事"的做法，除非你有极其充分的理由（比如某个字段只是给业务方做展示，永不需要关联查询），否则一律拆中间表。

2.4 属性的细节：唯一性、派生值与原子性

属性设计里有三个细节值得专门提一下。

第一是唯一性标识。逻辑模型阶段就要明确哪些属性具有唯一性约束，这不仅影响主键选择，也决定后续索引设计。比如"用户"有user_id和mobile两个唯一标识，user_id是内部主键，mobile是业务唯一键。建模时就要把这个区别标出来，物理设计阶段才知道哪里要建唯一索引。

第二是派生属性（Derived Attribute）。"订单总额"就是典型的派生属性——它可以通过"明细数量 × 单价"算出来。理论上的建议是不存派生属性，但实际项目里，为了查询效率、为了满足报表的实时性需求，会故意把序额冗余存储在订单表上。这个在逻辑模型阶段可以先标记出来"这是派生属性，物理实现时再决定是否冗余"，不要把它和基础属性混在一起，否则以后维护口径时容易糊涂。

第三是属性原子性。第一范式要求属性不可再分，但"不可再分"是个业务判断。比如"地址"，在一个只做统计分析的场景里拆成省、市、区、详细地址四段是合理的；在一个只做整体展示的场景里，一个字符串就够了。所以原子性不是绝对标准，而是要看业务需要怎么使用这个数据。关键是在逻辑模型阶段把决定记录下来，别等建表了再争论。

3. 范式理论在实际建模中的拿捏：不是越规范越好

3.1 三范式到底在说什么

范式理论是逻辑模型设计绕不开的内容，但很多教材讲得太抽象。用大白话概括：

• 第一范式（1NF）：字段不可再分。一个字段不能存一个集合，不能存逗号分隔的多值。这是底线，除了极少数特殊场景（比如JSON字段做扩展），绝大部分情况都要遵守。
• 第二范式（2NF）：在1NF基础上，非主键字段必须完全依赖于整个主键，而不能只依赖主键的一部分。这条只对复合主键有意义。比如"订单明细（订单ID，商品ID，商品名称，数量）"里，商品名称只依赖商品ID，不依赖订单ID，这就是部分依赖，要拆出去。
• 第三范式（3NF）：在2NF基础上，非主键字段不能传递依赖于主键。也就是说，A决定B，B决定C，那C应该跟着B走，而不是跟着A走。比如"订单（订单ID，客户ID，客户姓名）"，客户姓名通过客户ID传递依赖于订单ID，应该拆到客户表里。

三范式解决了什么问题？本质上就是消除数据冗余和更新异常。如果同一份数据在表里出现多份，更新的时候漏改一份，数据就不一致了；删除某个记录可能连带把不该删的信息也删没了。这些都是"异常"。

3.2 什么时候该故意违反范式

理论归理论，实际做项目的时候你会发现，完全满足三范式的模型，在查询场景里经常性能不佳。原因很简单：范式化把数据拆得细，查询时要用大量JOIN把它拼回来；而JOIN是数据库操作里最昂贵的操作之一，表越大、关联越多，延迟越高。

我举一个常见的例子。订单表满足三范式时，客户名称要关联客户表才能拿到。如果你做的是一个高并发的订单列表页，每次查询都要JOIN客户表，压力会非常大。这时候常见的做法就是，在订单表里冗余一个"客户名称"字段。查询时少一次JOIN，换来的是数据的重复存储，代价是"如果客户改名，订单表里的存量数据不会自动更新"。

所以范式设计不是铁律，而是平衡。我建议采用这样的判断标准：优先按三范式设计，然后针对"高频查询路径"和"不可接受的JOIN成本"做有选择的冗余。每次违反范式都应该是显式的决策，而不是顺手为之。最好在数据库设计文档里记录"为什么这里故意冗余"，方便后来的人理解，也方便Review时有人质疑时你能给出理由。

另一个需要澄清的点是：不要太早做反范式优化。在数据量还没起来、业务逻辑还没稳定的时候，提前冗余字段往往过两三个月就发现冗余错了维度。等到确实出现性能瓶颈，再用实际数据验证优化效果，才是稳妥的做法。

3.3 实际建模中的操作建议

基于我多年的设计经验，逻辑模型阶段的范式判断可以走这个流程：

1. 先按业务需求画出最贴近真实世界的ER模型，不要一开始就想性能问题。
2. 把所有实体都标准化到3NF，确保每个非主键字段只依赖主键、不传递依赖。
3. 找出核心高频查询路径，评估JOIN深度和数据量。
4. 针对明确的性能问题，选择性地做冗余、加字段、加派生属性。
5. 每一步取舍都记录在案。

这个流程保证你"先有一个正确、清晰的基础模型，再做可控的偏离"。反过来，如果一开始就拍脑袋设计一堆冗余字段，后面排查数据不一致的代价会非常高昂。

4. 数据库系统架构：从查询到落盘的分工逻辑

4.1 三层模式架构：数据独立性的基础

数据库系统的经典架构是三层模式（Three-Schema Architecture），这个概念是理解整个数据库系统的钥匙。

• 外部模式（External Schema）：面向具体应用或用户的视图层。每个应用看到的是数据的一个子集，比如订单系统关心订单数据，用户系统关心用户数据。这一层相当于"给特定用户定制的窗口"。
• 概念模式（Conceptual Schema）：整个数据库的统一逻辑视图，描述所有数据及其关系。这层就是逻辑模型落地的结果。
• 内部模式（Internal Schema）：物理存储层，描述数据在磁盘上怎么存、怎么索引、怎么组织。

为什么要把一个数据库拆成三层？核心目的是实现数据独立性。逻辑独立性说的是：概念模式变了（比如新增一个字段），外部模式不用变，应用程序不用改；物理独立性说的是：内部模式变了（比如调整存储引擎、重建索引），概念模式不用变，应用程序更不用改。

这个架构的价值在真实项目里体会特别深。比如业务方说"订单详情要把快递单号也展示出来"，在逻辑模式加一个字段就够了，应用层视图不用动。又比如DBA说"这个表要换一种索引结构来提升性能"，应用代码完全无感。没有这层抽象，每一次底层调整都可能引发应用层的连锁改动。

4.2 一条SQL的旅程：解析、优化、执行

当你往数据库发一条SQL，它经过的路径是理解数据库架构的最好方式。整体可以分成四个阶段：

• 解析器（Parser）：把SQL文本拆成语法树，检查语法是否正确、表名和字段是否存在。这里有个容易踩的坑：如果SQL里有拼写错误，解析器这一层就会直接抛错，而不是等到执行的时候。所以排查SQL报错时，先怀疑语法，再怀疑权限和表结构。
• 查询优化器（Optimizer）：这是最核心也最神奇的部分。它接收语法树，生成多种执行计划（比如先关联A表再关联B表，还是反过来；走索引还是全表扫描），然后估算每种计划的代价，选中它认为最优的那个。优化器依赖统计信息（表的行数、索引的区分度等），统计信息陈旧，优化器就会做出"错误"的计划。
• 执行器（Executor）：按优化器选定的执行计划，一步步调用存储引擎的接口去取数据、做计算、返回结果。
• 存储引擎（Storage Engine）：真正和磁盘打交道的那一层。负责数据页的读写、索引的维护、事务的日志记录等。

理解这条链路之后，数据库优化就不再玄学了。慢查询要么是优化器选错计划（统计信息不准或索引缺失），要么是存储引擎读盘太慢（数据分页不合理或IO瓶颈），要么是执行器做了大量无谓的计算（比如排序、临时表）。排查慢查询时，第一步永远是看执行计划，而不是盲目加内存。

4.3 事务与恢复：架构里容易被忽视的部分

数据库系统里还有一个容易被忽视的组件是事务管理器和恢复管理器。事务管理器确保一组操作要么全部成功要么全部回滚（原子性），多个事务并发执行时互不干扰（隔离性）。恢复管理器则负责在系统崩溃后，把数据库恢复到某个一致状态。

这两个模块依赖的核心机制是日志（Write-Ahead Log，WAL）。简单说：在把数据页真正写入磁盘之前，先把操作记录写入日志。这样即使系统在写入过程中崩溃，重启后可以通过日志重放或回滚来恢复一致性。

这个机制和逻辑模型设计有什么关系？关系在字段长度的选择上。如果设计表时把某个字段长度定得太小，业务数据超长后会面临两种选择：改字段长度（需要连日志一起考虑，在线DDL成本高），或者截断数据（可能破坏业务）。这都是在逻辑模型阶段可以避免的。所以一个负责任的数据库设计者，在建模时就会考虑字段的业务增长空间，而不是今天够用就行。

5. 存储结构：数据到底怎么躺在磁盘上

5.1 页和块：数据库读写的最小计量单位

数据库磁盘存储最基础的概念是"页"（Page），也叫"块"（Block）。在主流数据库中，页大小通常是4KB到16KB。关键是：数据库以页为单位做磁盘IO，也就是说，哪怕你只需要一条记录，数据库也会把整页数据读进内存。

这个机制引出一个重要的设计推论：把业务上经常一起访问的数据尽量放在同一页或相邻页。这就是为什么主键设计、聚簇索引设计对性能影响巨大——因为它们的物理排列方式，决定了你访问一条数据时，附近的数据是不是也大概率被读进内存，从而减少后续IO。

页的内部结构也有讲究。常见的是"插槽页"（Slotted Page）结构：页头记录页内有多少条数据、每条数据的偏移量，数据从页尾部向前填充。这样做的好处是，当数据记录长度不等时，更新操作不需要频繁移动整页数据，只要调整插槽偏移就可以。理解这一点，就知道为什么变长字段（VARCHAR）和定长字段（CHAR）在存储上的行为了——变长字段的记录会填充在页的不同位置，更新时如果变长值增大，可能要把记录挪到新位置，产生"行迁移"。高频繁更新的场景，行迁移带来的IO开销是隐性杀手。

5.2 表空间、段、区、页：一层一层的存储容器

数据库存储有清晰的层级：

• 表空间（Tablespace）：逻辑上最大的存储容器，一个表空间可以包含多个数据文件。
• 段（Segment）：一个表或索引对应一个段。段是逻辑对象在物理存储上的映射。
• 区（Extent）：一组连续的页，段按区为单位扩展空间。连续页的优势是顺序扫描时IO效率高。
• 页（Page）：最小的IO单位，前面说过了。

这个层级关系决定了空间规划的思路。比如在表数据量增长前预估区的大小、预分配空间，可以避免频繁扩展带来的碎片和性能抖动。我做运维时见过不少表因为频繁扩展导致数据文件碎片化严重，查询越来越慢，最后只能重建表来整理空间。如果当初规划表空间时留够余量、及时监控增长趋势，这些都是可以避免的。

5.3 行存储与列存储：不同查询模式的取舍

存储结构还有一个大方向的选择：行存储（Row-based）还是列存储（Column-based）。

• 行存储：数据按行连续存放，一行数据的所有字段在磁盘上靠在一起。适合OLTP（在线事务处理）场景，因为业务操作通常是"取某一行数据的所有字段"，比如订单详情、用户信息。
• 列存储：数据按列连续存放，同一列的所有值在磁盘上靠在一起。适合OLAP（在线分析处理）场景，因为分析查询通常是"对某一列做聚合计算"，比如统计所有订单的总额，只需要读"总额"那一列，列存储能大幅减少IO。

逻辑模型对这个选择的影响是：如果同一个逻辑模型既要支撑事务操作，又要支撑分析统计，那在物理设计时可能要考虑"一份逻辑模型、两种存储布局"的方案——常见做法是OLTP数据通过同步工具（ETL）流入OLAP列存储数据库。这不是逻辑模型的问题，但逻辑模型阶段如果已经意识到"这张表未来会被怎么查"，物理存储选型就会更有方向。

5.4 索引的物理结构：B+树与哈希

索引是存储结构里最影响查询性能的部分。最常见的是B+树索引和哈希索引。

B+树是大多数关系型数据库的默认索引结构。它的特点是：

• 所有数据都存储在叶子节点，叶子节点之间通过链表相连。
• 非叶子节点只存索引键和指向子节点的指针。
• 从根节点到叶子节点的路径长度固定（树高），因此查询性能稳定。

B+树非常擅长范围查询（比如WHERE create_time BETWEEN '2024-01-01' AND '2024-03-01'），因为叶子节点链表让顺序扫描非常高效。这也是为什么"LIKE 'keyword%'"能走索引而"LIKE '%keyword'"通常不能走——前缀匹配可以沿着B+树定位，后缀匹配无法利用有序性。

哈希索引则完全不同：它通过哈希函数将键值映射到对应的桶，等值查询（WHERE id = 100）只需一次哈希计算，速度极快。但它完全不支持范围查询，也不支持排序。所以选择索引结构的依据，永远是你实际的查询模式。如果只是等值查询，哈希索引效率远超B+树；一旦涉及范围，B+树才是正确选择。

从逻辑模型到索引设计，有一个经常被忽略的映射关系：逻辑模型中的每个唯一约束，在物理实现中通常都要对应一个唯一索引。如果你在逻辑模型阶段定义了"用户手机号唯一"，物理实现时忘了加唯一索引，那么并发插入下就可能产生重复手机号——当时不报错，等业务用到时就炸了。

6. 从逻辑模型到物理存储：一次完整的映射实践

6.1 逻辑属性到物理字段的类型选择

逻辑模型不关心字段物理类型，但落到存储结构时，类型选择直接影响性能和空间。

通用原则是：先选对类别，再选保守的长度，不要过度使用大字段。

• 数值型：整型（INT、BIGINT）选型要考虑取值范围和未来增长。主键建议直接用BIGINT，别省那4个字节到后面INT溢出，那是灾难性的。
• 字符型：定长的用途其实很窄，只有像"国家代码""状态码"这种长度绝对固定才用CHAR，其他一律VARCHAR。VARCHAR是变长的，但它有额外1~2字节的记录长度开销，所以也不是越小越好，关键是合理。
• 日期时间：能存DATETIME/TIMESTAMP就不要存字符串。字符串在比较、计算、排序上性能差一个量级，而且稍不注意格式不一致就出问题。

还有一个经验：逻辑模型里的布尔值，物理存储用TINYINT(1)或BIT，用应用层转换语义，不要直接用字符串'Y'/'N'。因为后者的值域不可控，应用层容易写错大小写，产生脏数据。

6.2 主键选择：代理键与自然键之争

主键是逻辑模型到物理存储最重要的映射点。最核心的争论是：用代理键（自增ID、雪花ID）还是自然键（业务上天然唯一的字段，比如身份证号、订单号）。

我的建议很明确：优先使用代理键作为主键，自然键作为唯一约束保留。原因有三点：

1. 自然键通常更长且可能变更。比如客户编号，一旦业务规则调整、编号规则变化，作为主键会牵一发动全身。
2. 自然键的全局唯一性容易被业务变化打破。比如手机号，看起来唯一，但可能被回收再分配，历史上还有过注销重注册的情况。
3. 代理键对B+树索引的插入效率更友好。自增ID的顺序递增意味着新数据总是插入B+树的最右侧叶子节点，不会导致页的频繁分裂；而随机的UUID会导致大量随机插入，引发页分裂和碎片化，写性能大幅下降。

如果确实需要用分布式ID（雪花号），逻辑模型阶段就把ID类型定为BIGINT，不要用VARCHAR存数字ID——字符串比较比整型比较慢，还会浪费空间。

6.3 逻辑关系到物理实现的落地

逻辑模型里的关系，落到物理存储时要考虑三件事：外键约束、索引、级联规则。

外键约束：从数据一致性角度讲，外键约束能保证引用的完整性，防止孤儿数据。但从性能角度讲，外键约束在每次插入和删除时都有额外的检查开销。互联网公司普遍的做法是：逻辑模型保留关系，物理实现时去掉外键约束，由应用层保证数据一致性。这个取舍没有绝对对错，取决于你对数据一致性的容忍度和性能诉求。但至少，逻辑模型阶段的关系定义决定了应用层必须实现哪些检查逻辑。

索引：外键字段几乎总是需要建索引的。原因很简单：如果通过订单表关联查客户，数据库需要根据客户ID去客户表中查找，如果客户表的外键字段没有索引，就需要全表扫描。很多慢查询的根源，就是外键字段忘了建索引。

级联规则：逻辑模型要明确父记录删除时，子记录怎么办。是CASCADE（级联删除）、SET NULL（置空）还是RESTRICT（禁止删除）？这个决策一定要结合业务语义。比如删除一个分类时，如果分类下还有商品，通常应该禁止删除，而不是悄悄把商品都删了。在逻辑模型阶段就定义好这些规则，物理实现时才能正确配置约束，避免误删数据。

6.4 一个完整案例：客户-订单-商品模型从逻辑到存储

最后用一个经典案例把整个过程串起来。

业务需求：客户可以下订单，订单包含多个商品，每个商品有数量、单价，订单有关联的收货地址。要支持查询"某客户的订单列表"、"某订单的总额"、"商品的销量统计"。

逻辑模型设计：

• 实体：客户（客户ID、姓名、手机号、注册时间）、订单（订单ID、下单时间、订单状态、收货地址、订单总额）、商品（商品ID、商品名称、价格、库存量）、订单明细（明细ID、数量、单价、小计）。
• 关系：客户1:N订单；订单1:N订单明细；商品1:N订单明细（即订单和商品通过订单明细中间表形成M:N关系）。
• 应用范式分析：客户姓名在订单表里不存（属于传递依赖），通过客户ID关联查；订单总额是派生属性，先标记，物理设计时决定是否冗余。

物理映射决策：

• 客户表：主键用BIGINT自增ID，手机号建唯一索引，姓名用VARCHAR(50)，注册时间DATETIME。
• 订单表：主键BIGINT，客户ID建普通索引，订单状态用TINYINT码值表替代字符串，订单总额冗余存储（因为订单列表页高频查询，不想每次聚合明细），收货地址用VARCHAR(200)字符串存储（因为展示整体地址即可，不需要拆分统计）。
• 订单明细表：主键是复合主键（订单ID + 明细序号），但考虑到业务上需要用自增ID做更多关联，我实际做时会加一个自增主键，再对（订单ID）建索引，同时保留业务上的复合唯一键（订单ID + 商品ID）。

这个案例里可以看到逻辑模型和物理存储的映射不是机械的：订单总额在逻辑模型里是派生属性，但物理实现时选择冗余；订单明细的逻辑主键是复合主键，但物理实现时为了灵活性和性能，加了一层代理键。这些决策每一条都有自己的理由，而不是"数据库能这样存就照这样建"。

映射时如果有条件，记得在建表完成后用真实数据量做一次索引和查询演练。我见过太多项目，表结构在开发环境跑得很欢，一上生产、数据量涨到千万级，原来舒服的查询突然变成几秒钟的任务。提前用接近真实规模的数据测试，能避免很多上线后才发现的性能事故。

做完这一步，一个数据库设计方案就算真正闭环了：从业务需求出发画逻辑模型，用范式规则约束模型质量，再结合系统架构和存储结构的底层机制，把逻辑模型映射成高效的物理实现。整个过程最花时间的一定是逻辑模型阶段——但这也是最值得投入的阶段。