系统架构设计师-关系数据库核心基础概念

一、引言

（一）核心概念定义

关系数据库是建立在关系模型基础上的数据库，借助集合代数等数学概念和方法处理数据库中的数据，是当前企业级系统数据存储的主流技术。本文梳理的关系模型基础概念、完整性约束等内容，是数据库架构设计、SQL 优化、数据一致性保障的核心理论基础。

（二）软考知识体系定位

该知识点属于软考高级系统架构设计师考试大纲中 "数据库架构设计" 模块的基础考点，在上午客观题中每年必考 1-2 分，同时是后续学习分库分表、分布式事务、数据一致性等高级知识点的前置基础。

（三）技术发展脉络

关系模型由 IBM 研究员埃德加・科德于 1970 年在《大型共享数据库数据的关系模型》论文中首次提出，历经 50 余年发展，形成了 SQL 标准（SQL-86、SQL-92、SQL:2016 等多个版本），当前主流关系型数据库包括 MySQL、PostgreSQL、Oracle、SQL Server 等均严格遵循关系模型理论规范。

（四）本文知识点覆盖

本文系统讲解关系的三种类型、视图与物化视图差异、关系模型核心属性、三大完整性约束四大核心模块，结合考试真题与企业实际应用场景展开分析。

二、关系的三种类型与核心特性

（一）基本关系（基表）

1. 定义：基本关系是数据库中实际存储数据的逻辑载体，对应物理存储上的数据文件与索引文件，是数据持久化的核心单元。
2. 核心特性：
   （1）具有独立的存储结构，包含数据行、索引、约束等完整对象定义
   （2）支持增删改查全量操作，数据修改会持久化到存储介质
   （3）是所有其他关系类型的数据源，视图、查询表均基于基表生成
3. 实际应用：电商系统中的用户表、订单表、商品表均属于基表，例如淘宝的订单基表包含订单 ID、用户 ID、商品 ID、下单时间、金额等全量业务属性，单表存储规模可达 TB 级。

（二）查询表

1. 定义：查询表是 SQL 查询执行过程中临时生成的结果集，仅存在于查询执行生命周期内，不会持久化存储。
2. 核心特性：
   （1）生命周期与查询会话绑定，查询结束后自动释放
   （2）数据生成逻辑由 SELECT 语句定义，支持聚合、关联、过滤等计算
   （3）通常存储于内存或临时磁盘空间，访问速度快但不支持数据修改持久化
3. 应用场景：统计报表生成时的多表关联计算结果、分页查询的中间结果集均属于查询表，例如电商平台的月度销售统计查询，会临时生成包含商品类别、销售额、销量的查询表，返回前端后立即释放。

（三）视图表

1. 定义：视图表是由基表或其他视图导出的虚拟表，数据库仅存储其查询定义，不存储实际数据，访问时动态执行定义语句生成结果。
2. 核心特性：
   （1）数据完全依赖基表，基表数据更新时视图访问结果同步更新
   （2）支持授权控制，可限制用户仅访问基表的部分行列数据
   （3）部分满足条件的视图支持数据更新操作，更新会映射到基表
3. 应用场景：企业 HR 系统中，为普通员工创建的视图仅展示本人的基本信息、薪酬数据，隐藏其他员工的敏感信息，避免数据泄露。

三种关系类型的架构示意图，展示基表、查询表、视图表与物理存储、用户访问的关系

三、视图与物化视图的对比分析

（一）视图的核心机制

1. 实现原理：视图本质是存储在数据库中的 SQL 查询模板，访问视图时数据库会将视图定义语句与用户查询语句合并，生成执行计划后访问基表获取数据。
2. 核心优势：
   （1）简化操作：将复杂的多表关联、聚合逻辑封装为视图，用户无需编写复杂 SQL 即可获取目标数据
   （2）逻辑独立性：基表结构变更时，仅需调整视图定义即可保持上层应用接口不变，实现逻辑数据独立性
   （3）安全隔离：通过视图行列过滤，实现敏感数据的访问权限控制
3. 局限性：访问视图需要每次执行查询逻辑，当视图定义包含多表关联、复杂聚合时，查询性能会明显下降，不适合高频访问场景。

（二）物化视图的核心机制

1. 实现原理：物化视图是将查询结果实体化存储的对象，创建时执行查询语句并将结果持久化存储，后续访问直接读取存储的结果数据，无需再次执行查询逻辑。
2. 刷新机制：
   （1）全量刷新：清空原有数据，重新执行查询语句生成全部结果，适合数据量小、更新频率低的场景
   （2）增量刷新：仅同步基表中发生变更的数据，通过日志或触发器识别数据变化，刷新效率更高
   （3）定时刷新：通过定时任务按固定周期刷新，例如每日凌晨刷新前一天的统计数据
3. 适用场景：适合查询频率高、数据实时性要求不高的统计分析场景，例如电商平台的每日销售报表、用户行为统计结果，使用物化视图可将查询延迟从秒级降低到毫秒级。

（三）两种视图的对比分析

视图与物化视图的访问流程对比图

四、关系模型核心属性定义与应用

（一）核心属性定义

1. 目 / 度：关系模式中属性的个数，例如包含用户 ID、姓名、年龄三个属性的用户表，其度为 3。
2. 候选码：能唯一标识关系中每一个元组的最小属性或属性组，候选码的任意真子集都无法满足唯一标识要求，例如用户表中的身份证号、用户 ID 都可以作为候选码。
3. 主码：从候选码中选定的一个作为元组的唯一标识，一个关系只能有一个主码，主码属性不能为空值，例如用户表通常选择用户 ID 作为主码。
4. 主属性与非主属性：包含在任意一个候选码中的属性称为主属性，不包含在任何候选码中的属性称为非主属性，例如用户表中用户 ID、身份证号是主属性，姓名、年龄是非主属性。
5. 外码：关系中的某个属性或属性组不是该关系的主码，但对应另一个关系的主码，用于建立两个关系之间的关联，例如订单表中的用户 ID 是外码，对应用户表的主码用户 ID。
6. 全码：关系模式的所有属性共同组成候选码，即所有属性组合起来才能唯一标识元组，例如选课关系包含学生 ID、课程 ID 两个属性，两者共同作为候选码，该关系的候选码就是全码。

（二）典型应用场景

1. 电商订单系统中，订单表的主码为订单 ID，用户 ID 为外码关联用户表，商品 ID 为外码关联商品表，通过外码建立订单、用户、商品三者的关联关系。
2. 企业考勤系统中，考勤记录关系包含员工 ID、考勤日期、打卡时间三个属性，员工 ID + 考勤日期共同作为候选码，属于复合主码，两个属性均为主属性。

关系模型核心属性关联示意图，展示候选码、主码、外码在多表关联中的应用

五、三大完整性约束的设计与实现

（一）实体完整性约束

1. 定义：规定基本关系的主属性不能取空值，且不能存在重复值，确保每个元组都是唯一可识别的。
2. 实现原理：数据库通过主码约束自动实现实体完整性，创建表时指定主码后，数据库会自动校验主码值的唯一性与非空性，插入或更新数据时如果违反约束会直接拒绝操作。
3. 应用场景：订单表的订单 ID 作为主码，数据库会确保每个订单的 ID 唯一且不为空，避免出现重复订单或无标识订单。

（二）参照完整性约束

1. 定义：外码的取值要么为空值，要么等于被引用关系中某个元组的主码值，确保关系之间关联的一致性。
2. 实现机制：数据库通过外键约束实现参照完整性，支持级联更新、级联删除、限制操作三种策略：
   （1）级联更新：被引用表的主码更新时，自动更新引用表的外码值
   （2）级联删除：被引用表的元组删除时，自动删除引用表中关联的元组
   （3）限制操作：如果引用表存在关联数据，拒绝被引用表的更新或删除操作
3. 应用场景：订单表中的用户 ID 外码关联用户表的用户 ID，当删除用户表中某个用户时，如果订单表中存在该用户的订单，数据库会根据外键策略进行处理，避免出现订单关联不存在的用户 ID 的情况。

（三）用户自定义完整性约束

1. 定义：根据具体业务需求定义的约束，反映特定应用场景的数据语义要求，不属于通用的完整性规则。
2. 实现方式：
   （1）非空约束：限制属性值不能为空
   （2）唯一约束：限制属性值不能重复
   （3）检查约束：限制属性的取值范围，例如年龄在 18-60 之间，金额大于 0
   （4）触发器：实现复杂的业务规则校验，例如订单金额大于 10000 时需要自动进入审核流程
3. 应用场景：员工表中职称字段为 "工程师" 的员工月薪不能低于 3500 元，电商订单的收货地址不能为空，商品库存不能小于 0 等规则，都属于用户自定义完整性约束。

（四）真题考点解析

软考考试中该知识点常以场景题形式考查，典型考题如下：

1. 仓库关系 W 中的 "负责人" 引用员工关系的员工号，属于参照完整性约束
2. 库存关系 I 中的 "仓库号，产品号" 唯一标识 I 中的每一个记录，属于实体完整性约束
3. 员工关系 E 中的职称为 "工程师" 的月薪不能低于 3500 元，属于用户定义完整性约束

三大完整性约束的作用范围与实现机制图

六、关系模型的前沿发展与考试趋势

（一）技术发展动态

1. 云原生关系数据库：阿里云 PolarDB、腾讯云 TDSQL 等云原生数据库，在遵循关系模型核心规范的基础上，实现了存储计算分离、弹性扩缩容、分布式强一致等特性，支持 PB 级数据存储与百万级 QPS 访问能力。
2. 多模数据库：PostgreSQL、MySQL 8.0 等传统关系数据库新增了 JSON、GIS、时序数据等非关系型数据的存储与查询能力，支持关系模型与非关系模型的混合应用。
3. 增量物化视图：新一代数据库支持自动增量刷新的物化视图，结合 CDC（变更数据捕获）技术实现秒级数据延迟，大幅提升复杂查询的性能。

（二）软考考试趋势

1. 考点融合：将关系模型基础概念与分布式数据库、数据一致性等高级知识点结合考查，例如考查分布式环境下如何实现实体完整性与参照完整性。
2. 场景化考查：通过企业实际架构案例，要求考生判断不同场景下的完整性约束设计方案是否合理，以及出现数据不一致问题的根因分析。
3. 新技术结合：考查关系模型在云原生数据库、分布式数据库中的实现差异，例如分布式环境下主码的设计原则，外键约束的适用限制等。

关系数据库技术演进路线图

七、总结与备考建议

（一）核心要点提炼

1. 关系分为基表、查询表、视图表三类，只有基表实际存储数据，查询表与视图表均为虚拟表。
2. 视图仅存储 SQL 定义，访问时动态生成数据，适合实时性高、访问频率低的场景；物化视图存储实际数据，通过刷新机制同步更新，适合查询频率高、实时性要求低的场景。
3. 候选码是唯一标识元组的最小属性组，主码是选定的候选码，外码用于建立表之间的关联，全码是所有属性共同组成的候选码。
4. 实体完整性约束确保主属性非空且唯一，参照完整性约束确保表之间关联的一致性，用户自定义完整性约束满足业务特定规则。

（二）软考考试重点提示

1. 高频考点：视图与物化视图的区别、三类完整性约束的应用场景、候选码 / 主码 / 外码的定义判断，这些知识点在上午客观题中每年必考。
2. 易错点：全码的判断、参照完整性的级联操作规则、视图可更新的条件，这些知识点容易混淆，需要结合实例深入理解。
3. 案例题考点：在下午案例分析题中，可能会要求考生针对具体业务场景设计完整性约束方案，分析数据不一致问题的原因并给出解决方案。

（三）实践应用建议

1. 架构设计阶段，优先根据业务需求选择合适的关系类型，高频统计查询场景优先考虑物化视图，敏感数据访问场景使用视图做权限隔离。
2. 主码设计优先选择无业务含义的自增 ID 或分布式 ID，避免使用业务字段作为主码，减少主码变更的风险。
3. 分布式数据库架构中，谨慎使用外键约束，避免跨节点关联导致的性能下降，可通过应用层实现参照完整性逻辑。

（四）学习路径建议

1. 基础阶段：掌握本文梳理的所有基础概念，完成近 5 年软考真题中相关考点的练习，确保基础知识点不丢分。
2. 进阶阶段：学习 SQL 优化、索引设计、事务隔离级别等数据库核心知识点，建立完整的关系数据库知识体系。
3. 高级阶段：学习分布式数据库、分库分表、读写分离等高级架构设计知识，结合实际项目案例提升架构设计能力。