Day28-02｜6.1.2 数据模型：把现实世界组织成可计算、可约束的数据结构

本文对应《系统架构设计师教程（第2版）》第6章“数据库设计基础知识”6.1.2“数据模型”。数据模型是对现实世界数据、数据之间联系、数据语义和操作约束的抽象描述。数据库设计不是先建几张表再补字段，而是先理解业务对象、关系、规则和访问方式，再逐步形成概念模型、逻辑模型和物理模型。系统架构师需要掌握不同数据模型的结构特征、优缺点和适用场景，并能解释模型选择如何影响一致性、扩展性、性能和维护成本。

一、学习目标与考试定位

完成本节后，应能够说明数据、数据模型、模式、实例和数据抽象的含义；掌握层次模型、网状模型、关系模型、面向对象模型和半结构化模型的基本特征；理解概念模型、逻辑模型和物理模型的职责边界；能够根据业务关系、事务边界、查询模式和质量目标选择模型；能够在案例题中分析模型设计错误，如重复数据、关系表达不足、过度嵌套、主键不稳定和物理结构泄露到业务层。

软考高级题目常把数据模型放在数据库设计、信息系统架构和案例分析中综合考察。题干可能描述“组织结构是树形”“社交关系需要多跳查询”“订单和明细必须保持一致”“字段经常变化”“报表查询复杂”。答题不能只写数据库名称，而应说明数据结构、关系约束、访问模式、事务要求、扩展代价和治理方式。

二、什么是数据模型

现实世界中的人、组织、商品、订单、设备和事件具有大量属性和关系。数据模型用一组概念、符号和规则对这些对象进行抽象，使它们能够被存储、查询、更新和验证。一个完整的数据模型通常包含数据结构、数据操作和完整性约束三个方面。

数据结构描述数据由什么组成、如何组织以及彼此如何关联；数据操作描述如何插入、删除、修改、查询和遍历；完整性约束描述哪些状态是合法的，例如主键不能重复、订单明细必须属于已有订单、余额不能低于业务允许的下限。

数据模型还要区分模式与实例。模式是对数据结构和约束的稳定描述，例如客户表包含客户编号、姓名和联系方式；实例是某一时刻实际存储的数据。系统运行时实例不断变化，而模式变化通常需要设计、评审、迁移和兼容策略。

三、数据抽象的三个层次

1. 概念模型

概念模型面向业务人员和需求分析人员，描述业务对象、属性和联系，不依赖具体数据库产品。实体—联系模型（E-R 模型）是常用概念模型，通过实体、属性和联系表达现实世界。例如“客户下订单”“订单包含商品”“员工属于部门”。概念模型的重点是业务语义和边界，而不是索引、分区和字段类型。

2. 逻辑模型

逻辑模型把概念模型转换为某类数据库能够理解的结构，例如关系模型中的表、列、主键、外键和约束，或文档模型中的聚合和嵌套。逻辑模型仍然可以相对独立于具体磁盘、节点和硬件，但已经需要明确数据组织方式、关联方式和一致性边界。

3. 物理模型

物理模型描述数据在具体平台上的存储和访问实现，包括索引、分区、分片、副本、压缩、表空间、存储引擎、缓存、冷热分层和物理参数。物理模型需要根据容量、吞吐、延迟、可用性、安全和成本优化，但不能破坏概念和逻辑层表达的业务语义。

可以这样记忆：

概念模型回答“业务上有什么、如何关联”；逻辑模型回答“用什么数据结构表示”；物理模型回答“在具体平台上怎样存得快、用得稳、扩得开”。

四、层次模型

层次模型使用树形结构表示数据，节点代表记录类型，父节点与子节点之间形成一对多关系。一个子节点通常只有一个父节点，根节点是整个树的起点。组织机构、文件目录、产品分类和行政区划都天然具有层次结构。

层次模型的优点是结构直观，沿固定路径访问时效率较高，适合表示稳定的树状关系。父子约束清晰，遍历一个子树也比较自然。

它的局限也很明显。现实业务经常存在多对多和交叉关系，一个节点可能属于多个上级，层次模型需要复制数据或增加复杂指针才能表达；当访问路径变化时，应用程序与结构容易耦合；树的结构调整可能影响大量下游程序。对于组织架构，还要注意“员工兼任多个部门”“矩阵管理”和历史归属等情况，不能见到树形就简单套用层次模型。

现代关系数据库和文档数据库也可以表示树，例如邻接表、路径枚举、嵌套集合、递归查询和嵌套文档。模型选择要结合更新频率、树深度、跨层查询和一致性要求。

五、网状模型

网状模型在记录之间使用有向图或集合类型联系，允许一个记录拥有多个父记录，能够表达一对一、一对多和多对多关系。相对于层次模型，网状模型更适合复杂关联和多路径导航。

网状模型的优势是关系表达能力较强，沿预先定义的导航路径访问可以高效；它能够避免层次模型中因多父节点造成的部分限制。缺点是结构复杂，应用需要了解指针和访问路径，数据结构变化会引起程序调整；设计者必须提前考虑访问路线，临时查询和 ad hoc 分析能力较弱。

网状模型对理解现代图数据库和关系数据库的关联很有帮助。很多业务关系本质上是图，但是否需要图模型，取决于关系遍历深度、路径分析频率、数据规模和一致性要求，不是所有多对多关系都必须使用图数据库。

六、关系模型

关系模型用二维表表示数据，表由行和列组成，行代表元组，列代表属性。表之间通过主键、外键和其他约束建立联系。关系模型以集合和谓词为基础，查询可以描述“需要什么结果”，而不是必须指定从哪个指针开始导航，因此具有较好的数据独立性和通用查询能力。

1. 关系模型的基本要素

域是属性可能取值的集合；属性是关系中的列；元组是关系中的一行；关系是满足一定结构的元组集合；候选键能够唯一标识元组，主键是被选定的候选键，外键用于引用其他关系的主键或候选键。

关系模型要求同一列中的值具有相对一致的语义和域，表中的行列顺序通常不承载业务意义。通过主键保证实体唯一，通过外键表达参照关系，通过非空、唯一、检查和业务约束保证合法状态。

2. 关系模型的优势

关系模型结构规范、语义清楚，适合事务处理、复杂关联、聚合查询和强一致性场景。SQL 具有成熟的查询和管理能力，事务、并发、备份恢复、安全审计和工具生态较完整。数据独立性和标准化设计有助于系统长期维护。

3. 关系模型的局限

关系模型对结构变化敏感，复杂对象需要拆成多表并通过连接重组；大规模水平扩展、跨地域低延迟和超高写入场景需要额外的分片、复制和一致性设计；高频关联查询在数据量增长后可能带来连接成本。使用关系模型并不意味着必须把所有内容都规范化到极致，设计应结合事务和访问模式。

七、面向对象数据模型

面向对象数据模型把数据组织为对象，支持对象标识、封装、类、继承、组合和方法。它适合描述具有复杂结构和行为的数据，如工程设计、地理信息、仿真、媒体对象和复杂领域模型。

面向对象模型可以减少对象与数据库之间的映射阻抗，让应用对象更直接地持久化；继承和组合有助于复用模型。但它也可能造成查询语言、事务管理、跨语言互操作和长期模式演进问题。企业系统中常见的 ORM 并不等于数据库本身就是面向对象模型，而是在关系模型与对象模型之间提供映射层。

架构师要注意 ORM 的便利可能隐藏查询和事务成本。一个对象导航可能触发大量隐式查询，复杂对象更新可能导致意外的级联操作。应明确加载策略、事务边界、聚合根、查询投影和索引，并对生成的 SQL 或实际访问行为进行验证。

八、半结构化与文档模型

半结构化数据通常没有严格固定的表格模式，但数据中包含字段名、嵌套层次或标记信息，例如 JSON、XML 和日志事件。文档模型以文档或聚合为基本存储单位，允许不同文档具有一定程度的字段差异。

文档模型适合以整体读取和更新的业务聚合，例如商品详情、内容、用户偏好和配置。它可以减少多表连接，结构演进较灵活，适合快速迭代和多层嵌套数据。但过度嵌套会造成文档过大、局部更新困难和并发冲突；过度引用又可能重新引入复杂关联。设计时必须先识别聚合边界、更新边界和查询边界。

半结构化并不代表没有模式。实际系统仍要通过 JSON Schema、接口契约、版本字段、校验器和兼容策略维护“可演进的模式”。如果不同团队随意写入同名字段的不同含义，灵活性最终会变成数据治理失控。

九、图数据模型

图模型以节点和边表达实体及其关系，边可以带有方向、类型和属性。它适合社交网络、推荐关系、知识图谱、路径规划、依赖分析和反欺诈等需要多跳遍历的场景。

图模型的优势是关系是一等公民，多跳查询和路径分析表达自然；关系变化不必像固定表结构那样频繁增加连接表。局限是通用事务、批量分析、分布式扩展、数据治理和团队能力可能成为约束。对只有一两层关联的普通业务，关系表加索引往往更简单可靠。

十、模型选择的架构方法

选择数据模型时，建议按以下顺序分析：首先明确核心业务对象和数据所有权；其次识别实体之间的基数、生命周期和事务边界；再次整理主要读写路径、查询深度、更新频率和数据规模；然后评估一致性、可用性、延迟、扩展性、安全和合规要求；最后比较模型复杂度、团队技能、运维能力、迁移成本和退出方案。

一个系统可以采用多模型组合，但必须明确权威数据源和同步关系。例如关系数据库保存订单和库存的权威状态，文档库保存商品展示聚合，图数据库保存推荐关系，搜索引擎提供全文检索，数据仓库提供分析。多模型的核心风险是数据重复和同步不一致，应设计事件、重放、对账、补偿和重建机制。

十一、数据模型常见错误

第一，把现实对象和数据库表一一机械对应，忽略业务聚合、生命周期和事务；第二，把不稳定的业务属性作为主键，导致更新和关联困难；第三，为了“规范化”拆出过多表，在线查询大量连接，或为了方便读取把所有数据塞进一个大文档；第四，把多对多关系当成两个一对多关系处理，却没有中间关系的属性和唯一约束；第五，把物理索引、分区和数据库厂商类型直接写进业务需求，造成逻辑与物理耦合；第六，允许半结构化数据无约束写入，最终无法治理。

数据模型评审应重点检查：对象定义是否完整；主键是否稳定；关系基数是否正确；空值语义是否明确；历史和状态是否需要保留；删除和归档规则是否明确；数据所有者和访问权限是否确定；变更是否向后兼容；主要查询是否有可接受的实现路径。

十二、案例分析：从单体关系模型演进到多模型架构

某内容平台使用一组关系表保存文章、作者、标签、评论、推荐关系和访问统计。平台发展后，文章详情查询需要连接十余张表，推荐服务需要频繁进行多跳关系查询，访问统计又占用交易数据库资源。团队提出把所有关系表直接迁移到文档数据库，并认为这样就能解决性能问题。

问题分析

原模型同时承担内容聚合读取、关系遍历和统计分析三类负载，访问模式不同，造成连接和资源竞争。直接全部迁移到文档数据库会使评论、作者、标签和文章的更新边界变得模糊，也不一定适合多跳推荐和统计聚合。问题不在于关系模型“过时”，而在于单一模型承担了不匹配的职责。

改进方案

先确定文章发布、评论审核等核心事务边界，保留关系数据库或事务型存储作为权威源；为文章详情构建按读取模式组织的文档投影，通过事件或增量同步更新；推荐关系和多跳查询使用图模型或经过验证的关系索引结构；访问统计进入分析存储，采用流式或批量处理；为投影重建、事件重放、延迟监控、失败补偿和数据对账建立机制。迁移采用双读校验和灰度切换，不能一次性切断旧系统。

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

练习一

某业务要求表示“公司—部门—员工”的组织关系，同时存在员工兼任多个部门和临时借调。团队选择严格的树形层次模型。请分析风险。

参考答案：严格层次模型假设一个节点只有一个父节点，不能自然表示兼任和借调等多父、多时态关系，复制员工数据会造成更新不一致。应在概念模型中把员工、部门、任职关系和借调关系分开，给关系增加角色、开始时间、结束时间和状态等属性；逻辑层可用关系模型的关联表或经过验证的图模型表达，并明确当前组织和历史组织的查询需求。

练习二

某团队将订单、所有订单明细、支付记录和物流轨迹全部嵌入一个文档，文档超过数兆字节且并发更新冲突严重。应如何改进？

参考答案：文档边界与更新边界不匹配。应识别订单主状态、明细、支付和物流的生命周期与事务边界，保留必须原子更新的聚合，拆分高频独立更新或高增长集合；通过引用、事件和查询投影组织读取；控制文档大小、索引和版本，明确支付和订单状态的一致性策略。不能只把文档拆小，还要说明跨文档更新、重试、补偿和对账方式。

练习三

请解释概念模型、逻辑模型和物理模型的区别，并说明为什么不能在需求阶段直接确定分区键。

参考答案：概念模型表达业务对象、属性和联系；逻辑模型选择关系、文档、图等结构并定义键、约束和聚合；物理模型落实到具体数据库的索引、分区、副本、存储参数和部署方式。分区键依赖数据量、访问模式、热点、扩容、地域和故障目标，需求阶段信息通常不足；过早确定会把物理假设泄露到业务层。应先稳定业务和逻辑语义，再依据容量和性能验证选择物理方案，并保留演进与迁移路径。

十四、论文写作素材

论文中可以这样描述数据模型设计：我先从业务流程、数据所有权、生命周期和质量属性出发，建立概念模型，识别核心实体、属性、关系基数、状态和完整性约束；再根据事务边界和主要访问模式形成逻辑模型，明确主键、外键、聚合、索引需求和一致性范围；最后结合容量、吞吐、延迟、可用性、安全和成本设计物理模型。

对于交易数据，我选择适合强约束和事务处理的关系结构，避免把关键业务规则全部放在应用层；对于内容、会话、推荐关系和分析数据，根据读取模式和数据特征采用文档、键值、图或分析存储。多模型架构中明确权威数据源、同步事件、投影重建、失败重试、数据对账和回滚机制。对模型进行评审和原型验证，重点测试高频查询、并发更新、数据增长、故障恢复和模式演进。

在实施过程中，我将概念、逻辑和物理模型纳入配置管理，建立需求到数据对象、接口、代码和测试的追踪关系；通过数据字典、命名规范、模式版本和迁移脚本治理变化；上线前执行数据校验、性能测试和恢复演练。这样既保证业务语义稳定，又允许底层技术根据规模和质量目标演进。

十五、今日复盘

数据模型是现实世界与数据库实现之间的抽象桥梁，包含结构、操作和约束。层次模型适合固定树形路径，网状模型适合复杂导航关系，关系模型适合结构化事务与通用查询，面向对象模型适合复杂对象，文档模型适合聚合读取和灵活结构，图模型适合多跳关系。概念、逻辑和物理模型分别解决业务表达、数据结构和具体存储问题。

选择模型时不要从数据库产品名出发，而要回答：谁拥有数据？实体如何关联？什么必须原子完成？主要怎么读写？数据怎样增长？哪些不一致可以接受？怎样备份、审计、迁移和恢复？

记忆主线：

现实对象与关系 → 概念模型 → 逻辑数据结构 → 物理存储实现；模型服务于业务边界，技术选择服从访问模式和质量属性。

下一篇进入 6.1.3 数据库管理系统，重点学习 DBMS 的组成、功能、事务、并发控制、恢复、安全与系统架构。