Day28-10｜6.3.3 概念结构设计：用 E-R 模型建立统一的业务数据语言

本文对应《系统架构设计师教程（第2版）》第6章“数据库设计基础知识”6.3.3“概念结构设计”。概念结构设计是在数据需求分析基础上，独立于具体数据库管理系统，抽象出全局数据的实体、属性、联系和约束。它的成果不是立即可执行的建表脚本，而是一份业务、产品、开发、测试、数据和运维人员都能理解并共同确认的数据蓝图。概念结构设计做得越清楚，后续逻辑设计、接口设计、数据治理和系统架构的返工越少。

一、学习目标与考试定位

完成本节后，应能够解释概念结构设计的目标和特点；掌握实体、属性、联系、实体集、联系集、基数和参与约束；能够使用 E-R 模型描述一对一、一对多和多对多关系；能够处理弱实体、递归联系、泛化与特化、联系属性和时态关系；能够把多个局部视图集成为全局概念模型；能够在案例题中发现实体粒度不清、属性归属错误、关系基数错误和概念模型过早绑定技术的问题。

软考高级题目常通过业务描述考查建模能力：一个订单包含多个商品，一个员工可兼任多个项目，一个设备产生许多事件，一个账户可能有多次支付尝试。答题要先识别业务对象和联系，再明确基数、可选性、生命周期和联系属性，最后说明如何解决局部视图冲突及如何向逻辑模型转换。

二、概念结构设计的定位

概念模型描述企业或系统所关心的现实世界，不依赖某个 DBMS、编程语言或物理部署。它关注业务语义，而不是表名、索引、分区、字段长度和存储引擎。概念模型应能够回答：系统中有哪些重要对象；对象具有什么稳定特征；对象之间如何关联；哪些关系和状态必须满足约束。

概念结构设计有三个特点。第一，面向全局，尽量统一不同部门对数据的理解；第二，面向业务，使用领域语言表达对象和规则；第三，面向后续转换，为逻辑模型和应用架构提供稳定依据。它既不是页面原型，也不是某个部门的局部表结构。

三、E-R 模型的基本元素

1. 实体与实体集

实体是现实世界中可以区别和识别的对象，如客户、订单、商品、员工和设备。实体集是一类具有相同特征和规则的实体集合。识别实体时要看它是否具有独立标识、属性、生命周期和业务操作。

不要把每一个名词都建成实体。订单状态通常是订单的属性或状态机，页面按钮通常不是实体；但如果“支付尝试”有独立编号、时间、金额、渠道、结果和重试生命周期，就应作为实体建模。

2. 属性

属性描述实体或联系的特征，例如客户编号、订单时间、商品单价。属性可以是简单属性、复合属性、单值属性、多值属性、派生属性和可选属性。概念模型阶段要明确业务含义和是否需要独立生命周期，再决定后续逻辑表示。

联系本身也可以有属性。例如学生与课程之间的选课联系有成绩、选课时间和状态；订单与商品之间的明细联系有数量、成交价和优惠金额。把联系属性错误地放到任意一端，会造成重复或语义错误。

3. 联系

联系描述实体之间的业务关联，如客户下订单、订单包含商品、员工参与项目。联系可以是一元联系、二元联系或多元联系，也可以具有角色名称和属性。角色在递归联系或同类实体之间的关系中尤为重要，例如员工“汇报给”员工，需要区分上级和下属角色。

四、基数与参与约束

基数描述一个实体实例可以关联另一实体多少个实例，常见为一对一、一对多和多对多。参与约束描述实体是否必须参加某个联系，可以是全参与或部分参与。

“一个客户可以有多个订单”只说明从客户到订单的方向，仍需确认每个订单是否必须属于一个客户、客户没有订单是否允许存在、订单能否转移客户。基数和参与约束要通过业务访谈和实例验证确认，不能只凭开发习惯决定。

五、主标识与实体粒度

概念模型阶段要为实体识别业务标识，但不必立即确定物理主键。一个稳定标识应能区分实例，且在生命周期中尽量不变化。若业务标识可能重复或变化，应在逻辑层引入稳定内部标识，同时保留业务唯一约束和历史映射。

实体粒度决定数据含义。把“订单”定义为一次下单，把“订单明细”定义为某订单中的某商品项，把“支付尝试”定义为一次支付请求，这些粒度不同的对象不能混成一个实体。粒度过粗会丢失细节，粒度过细会增加不必要的复杂度。

六、弱实体、泛化与特化

弱实体不能仅靠自身属性唯一标识，必须依赖强实体及识别联系。例如订单明细可能通过订单编号和明细序号识别；它不能脱离订单独立存在。概念模型要表达弱实体的存在依赖和标识方式。

泛化与特化用于表达共同属性和差异属性。员工可以泛化为人员，普通员工、外包员工和管理人员是特化类型；账户可以特化为个人账户和企业账户。使用泛化时要确认类型是否互斥、是否完全覆盖、子类生命周期是否独立，以及逻辑层采用单表、父子表还是其他方式。

过度使用继承会使模型复杂，实际业务中若子类规则差异很小，使用类型属性和约束可能更简单；若子类拥有不同生命周期、权限和行为，则应保留清晰的特化结构。

七、时态和历史关系

概念模型不能只描述当前状态，还要识别历史和有效期。员工属于部门的关系可能随时间变化，商品价格可能有生效和失效时间，客户地址在下单时需要保存快照。应明确当前关系、历史关系和事件记录是否同时存在。

例如“客户有收货地址”可以表示当前地址集合；“订单使用收货地址”则应保存下单时的地址快照，不能随着客户后续修改地址而改变历史订单。概念模型阶段明确时态语义，后续逻辑和物理设计才不会产生数据丢失。

八、局部视图设计与全局视图集成

大型系统通常由多个部门和子系统分别提供局部数据视图。销售关心客户和订单，仓储关心商品、库存和出入库，财务关心支付、发票和结算。先建立局部概念模型，再集成为全局模型，能够降低一次性建模的复杂度，但会出现命名、定义、结构和约束冲突。

1. 冲突类型

命名冲突是同一含义使用不同名称，或同名词表示不同含义；定义冲突是字段范围、单位或口径不同；结构冲突是同一对象在不同视图中被建成实体、属性或联系；约束冲突是基数、可空、状态和生命周期规则不一致。

2. 冲突消解方法

先建立业务术语表和数据字典，明确对象定义、单位、口径和责任人；再通过访谈和实例核对识别谁是权威来源；对结构冲突分析生命周期、访问和所有权；对规则冲突区分不同业务场景，必要时拆分概念或增加角色、状态和有效期。冲突处理结果要记录决策、理由、影响和待验证风险。

3. 集成原则

全局模型不是简单把所有局部实体堆在一起，而是去重、统一、保留必要差异，并明确边界。一个“客户”若在销售和会员体系含义不同，不能强行合并为一个实体；可以建立客户主数据、会员档案和关系映射，说明各自责任。

九、概念模型评审

概念模型评审应邀请业务专家、产品、架构、开发、测试、数据治理、安全和运维共同参与。评审重点包括：实体是否覆盖关键业务事实；属性定义是否清晰；联系基数和参与约束是否正确；联系属性是否归属正确；主标识是否稳定；历史和状态是否保留；敏感数据是否识别；数据所有权和来源是否明确；模型是否能支持关键查询和事务。

评审不能只看图形是否美观。应使用典型场景走模型，例如创建订单、修改客户、支付重试、退款、商品换价、员工调岗和数据归档，逐步检查每个事实保存在哪里、由谁修改、如何关联和如何恢复。对高风险模型应构造样例数据验证是否能表达正常、异常和边界状态。

十、从概念模型到逻辑模型

概念模型转换为关系模型时，实体通常转换为关系，属性转换为列，标识转换为候选键或主键，1:N 联系在 N 端增加外键，M:N 联系转换为独立关系，弱实体包含所属强实体的标识。泛化可以转换为单表、父子表或具体子类表。

转换过程中不能丢失业务语义。联系属性必须进入联系关系，时态关系要有有效期或历史结构，多值属性要拆分或使用合理的集合结构，业务约束要映射为数据库约束、服务规则或流程控制。

十一、案例分析：物流平台的概念模型冲突

某物流平台由订单、仓储和运输三个团队共同建设。订单团队把“地址”作为订单字段，仓储团队把地址作为客户属性，运输团队又把地址当作可复用的站点实体。三方都使用“收货地址”名称，但订单历史必须保留下单时地址，仓储需要维护当前地址，运输还要通过站点编号规划路线。项目组若直接合并字段，后续必然出现历史订单被修改和路线无法复用的问题。

问题分析

这是概念定义、结构和生命周期的多重冲突。订单地址是历史快照，客户地址是当前可维护信息，运输站点是具有独立编号、坐标和运营状态的实体，三者不能简单视为同一个属性。命名相同不代表业务语义相同。

改进方案

建立术语和全局概念模型：客户拥有可维护的地址档案，订单保存下单时的地址快照并关联原始地址标识，运输系统维护可复用的站点实体和路线关系；明确三者来源、责任、同步和历史规则。对地址标准化、地理编码和人工修正建立数据质量流程，订单创建时完成必要快照和校验。逻辑模型中采用不同关系和外键，物理层再根据查询和容量设计索引、缓存和空间检索。

十二、综合知识练习与详细答案

练习一

某团队把“订单包含商品”设计成订单表中的 product1、product2、product3 三个字段。请从概念结构设计角度指出问题。

参考答案：团队把多对多联系和联系属性错误地展开成固定数量的属性，无法表达商品数量不定、成交价、优惠和历史快照，也导致结构扩展和查询统计困难。概念模型应建立订单实体、商品实体和订单明细联系，明确一个订单包含多个明细、一个商品可出现在多个订单中，并在联系上保存数量、价格和状态。

练习二

一个员工可以同时参与多个项目，在不同项目中担任不同角色，并有开始和结束时间。应如何建模？

参考答案：员工与项目是多对多联系，参与项目的角色、开始时间和结束时间属于联系属性。应建立“员工—项目参与”联系实体，保存员工、项目、角色、有效期和状态，并定义同一员工在同一项目同一时段的唯一性或业务约束。不能把项目编号列表放入员工属性，也不能把角色固定在员工实体中。

练习三

销售部门的客户与客服部门的客户定义不一致，如何进行全局概念模型集成？

参考答案：先识别命名、定义、结构和约束冲突，建立术语表和数据字典；通过访谈、样例和来源核对确认客户主数据、销售关系和客服档案的责任边界；若业务语义不同，不强行合并为一个实体，可建立客户主实体、销售客户关系和客服档案，并用稳定标识关联；记录统一口径、映射、同步、权限和历史规则，经过业务评审后再转换逻辑模型。

十三、论文写作素材

论文中可以这样描述概念结构设计：在完成数据需求分析后，我组织业务、产品、开发、测试、数据、安全和运维人员分别建立局部 E-R 模型，识别实体、属性、联系、基数、参与约束、生命周期和数据所有权；再通过术语表、数据字典和样例数据解决同名异义、异名同义、单位和口径冲突，形成全局概念模型。

对订单、商品、客户、支付、库存和物流等核心对象，我重点确认实体粒度、稳定标识、联系属性、历史快照、状态转换和异常流程；对多对多、弱实体、递归关系和时态关系进行显式建模。通过典型业务场景走查概念模型，验证它能表达正常、异常和边界状态，且不提前绑定某种数据库、表结构或物理存储。

在转换逻辑模型时，我将实体、联系、基数和约束映射为表、键、外键、状态和服务规则，对无法在单库约束的跨服务不变量设计事件、幂等、补偿和对账。概念模型、决策、术语和冲突处理记录进入配置管理，为后续物理设计、接口设计和数据迁移提供可追溯依据。

十四、今日复盘

概念结构设计的任务是用业务语言建立全局数据蓝图。E-R 模型的核心元素是实体、属性和联系，设计时必须确认实体粒度、稳定标识、关系基数、参与约束和联系属性；对弱实体、递归、泛化、历史和时态关系要显式表达。多个局部视图集成时，要解决名称、定义、结构和约束冲突，不能简单拼接或强行合并。

记忆主线：

识别实体与属性 → 明确联系与基数 → 定义标识、约束和时态 → 集成局部视图 → 场景走查和评审 → 转换为逻辑模型。

下一篇进入 6.3.4 逻辑结构设计，学习 E-R 模型向关系模型转换、关系模式优化、视图和数据完整性设计。