Day28-04｜6.1.4 数据库三级模式
Day28-04｜6.1.4 数据库三级模式：用分层抽象隔离业务、逻辑与存储变化
本文对应《系统架构设计师教程（第2版）》第6章“数据库设计基础知识”6.1.4“数据库三级模式”。数据库三级模式结构由外模式、模式和内模式组成，通过外模式/模式映像以及模式/内模式映像，把用户视图、全局逻辑结构和物理存储结构分离开来。它是理解数据库系统数据独立性的基础，也是系统架构中“抽象、封装和隔离变化”的典型体现。
一、学习目标与考试定位
完成本节后，应能够准确区分外模式、模式和内模式；理解两级映像的作用；说明逻辑数据独立性和物理数据独立性的含义；能够分析视图、数据权限、存储变更和模式演进之间的关系；能够在案例题中判断“修改表结构导致所有程序改动”“更换索引影响业务代码”等问题；能够在论文中将三级模式与分层架构、数据治理、接口兼容和数据库演进联系起来。
软考题目容易混淆“模式”和“外模式”，也常把数据库模式与软件架构模式混在一起。这里的模式是数据库的逻辑结构描述，不是 MVC、分层或设计模式。答题时应先写清三级模式各自服务的对象，再说明映像如何隔离变化，最后结合视图、权限、迁移和兼容策略说明工程价值。
二、为什么需要三级模式
数据库既要面向不同用户提供不同数据视图，又要维护一个全局一致的逻辑结构，还要根据硬件和性能要求调整物理存储。如果应用直接依赖磁盘文件、页布局和索引，任何存储优化都会引发大面积修改；如果每个用户都自行理解全局数据，容易产生口径和权限混乱。
三级模式把同一数据库分成三个抽象层次：用户看到自己需要的数据；数据库管理员和设计人员维护全局逻辑结构；系统根据实际平台管理文件、索引、分区和存储组织。层次之间通过映射转换，应用不必知道底层数据究竟保存在哪个文件或节点。
可以用一条主线记忆：
外模式面向用户和应用，模式面向数据库整体，内模式面向存储实现；外模式/模式映像隔离用户视图变化，模式/内模式映像隔离物理存储变化。
三、外模式
外模式也称子模式或用户模式，是数据库用户能够看到和使用的数据视图。一个数据库可以有多个外模式，不同业务、角色或应用可以通过不同外模式访问同一数据库。
例如，客服外模式只提供客户基本信息和订单状态，财务外模式还需要发票和收款数据，运营外模式提供统计字段，但不应暴露身份证号和支付敏感信息。外模式可以隐藏无关字段、限制数据行、重命名列、组合多个表或提供面向业务的稳定接口。
外模式的价值包括简化用户使用、提高安全性、支持数据独立性和屏蔽逻辑结构复杂度。视图是实现外模式的常用机制，但外模式不等同于某一条 SQL 查询；它是一组面向特定用户或应用的可管理数据描述。
外模式设计要注意性能和可更新性。复杂视图可能导致查询计划低效，某些聚合视图不能直接更新；视图字段变化还可能影响应用契约。因此要把视图版本、权限、依赖和性能纳入配置管理。
四、模式
模式也称概念模式或逻辑模式，是数据库中全体数据的逻辑结构和特征描述。它描述实体、属性、联系、约束、数据类型、完整性规则和数据之间的语义关系，不针对某个具体用户。
模式体现企业或系统对数据的整体理解。例如客户、订单、商品、库存和支付之间的关系，主键和外键，订单状态的合法转换，金额精度和时间语义，都属于模式层需要表达或约束的内容。模式是数据库设计、数据治理和应用协作的重要依据。
模式变更通常影响多个外模式和应用，因此要进行影响分析、兼容设计、迁移和验证。增加字段、增加可选关系可能比较容易兼容，删除字段、改变字段含义、改变主键或收紧约束则可能造成广泛影响。模式不应随着某个应用的临时需求任意变化。
五、内模式
内模式也称存储模式，是数据库在物理存储层的描述。它定义数据如何组织在存储介质上，包括文件结构、记录布局、页和块、索引、聚簇、分区、压缩、加密、存储引擎和物理参数等。
内模式主要由 DBMS 和数据库管理员管理，应用通常不需要了解。为了提高查询性能，可以增加索引、调整分区、改变表的物理组织或迁移到新的存储介质，只要不改变模式和外模式的语义，应用就不应被迫修改。这正是物理数据独立性的基础。
但是，现代应用常通过 ORM、SQL 优化、提示、分区键和读写分离配置间接依赖物理结构，完全隔离并不现实。架构师应识别这些泄露点，把关键物理假设写入容量模型和技术文档，设置兼容和验证机制，避免把不可替代的物理细节散落在业务代码中。
六、两级映像
1. 外模式/模式映像
外模式/模式映像定义某一个外模式与全局模式之间的对应关系。它把外部用户视图转换为全局逻辑结构，也把模式中的数据转换为外模式能够理解的形式。一个模式可以对应多个外模式，因此不同用户可以看到不同的数据范围和组织方式。
当全局逻辑模式在一定范围内变化时，只要调整外模式/模式映像，外部应用可以保持相对稳定，这体现了逻辑数据独立性。例如将客户姓名拆分为姓和名，或者把订单状态拆成状态码和状态时间，只要外部视图仍提供原有字段和语义，部分应用不必立刻改动。
逻辑独立性通常比物理独立性更难完全实现，因为逻辑结构变化可能改变业务语义、关系和约束。架构师应通过视图、API、数据服务、模式版本和兼容窗口降低影响，而不是承诺任何模式变化都不会影响应用。
2. 模式/内模式映像
模式/内模式映像定义全局逻辑模式与物理存储结构之间的对应关系。它负责把逻辑记录映射到文件、页、索引、分区或分布式节点。物理存储变化时，只要修改映像和相关内部实现，逻辑模式和外部应用可以保持不变，这体现了物理数据独立性。
物理独立性通常较强，因为增加索引、改变文件组织、分区和压缩多数不改变业务语义。但物理变化仍可能影响性能、锁行为、资源消耗、成本和可用性，因此不能只看“应用能否运行”，还要做性能、容量和故障验证。
七、数据独立性
1. 物理数据独立性
物理数据独立性是指当数据库的内模式发生变化时，尽量不需要改变模式和外模式。常见变化包括存储设备更换、文件组织调整、索引增加、分区策略变化、压缩方式改变和数据迁移。它使数据库管理员能够根据性能和容量优化存储，而不必修改所有应用。
2. 逻辑数据独立性
逻辑数据独立性是指当数据库的模式发生变化时，尽量不需要改变外模式和应用程序。常见手段包括视图、兼容字段、模式版本、API 适配和渐进迁移。逻辑独立性对应用演进特别重要，但受业务语义和约束变化影响，通常实现难度更高。
3. 不要把独立性理解成无限兼容
数据独立性是相对的，不是任何变化都能被完全隐藏。若删除核心字段、改变金额单位、改变主键语义或修改一致性规则，应用必须感知并调整。正确做法是明确兼容范围、变更影响和迁移窗口，而不是用复杂视图长期掩盖错误设计。
八、三级模式与视图、权限和数据服务
外模式不仅用于方便查询，也承担安全和职责隔离。通过视图可以只暴露必要字段和数据行，结合角色权限限制读取和更新范围。敏感信息应进一步采用脱敏、加密、审计和最小权限，不能认为“使用视图”就自动安全。
在微服务或数据服务架构中，每个服务的读模型、接口模型和数据库模型也可以形成类似的隔离：业务消费者依赖稳定契约，服务内部可以调整表结构和索引。若服务直接共享数据库表，外模式边界被破坏，数据库内部结构变化会跨服务传播，最终形成紧耦合。
数据仓库、数据湖和数据服务还要管理不同层次的模式：原始数据模式、标准化模式、主题模型、服务视图和报表模型。数据血缘、口径、权限和版本必须清楚，否则多个外部视图会产生相互矛盾的“事实”。
九、模式演进与兼容策略
数据库模式演进常用向后兼容和渐进迁移。以增加字段为例，可以先在模式中增加可选字段，应用先读旧字段并逐步写入新字段；完成回填和双读校验后切换读取；经过观察窗口，再停止旧字段写入并最终删除。这个过程要有版本、监控、回滚和数据校验。
对表拆分、字段重命名、主键替换和数据分片，应采用双写、变更数据捕获、数据对账、灰度流量和回退方案。双写虽然能支持迁移，但会产生写入失败不一致、顺序和重试问题，必须记录失败、补偿和最终校验。模式变更工具、迁移脚本和数据库版本要纳入配置管理，不应靠人工在生产环境执行临时命令。
十、三级模式与系统架构设计
三级模式体现了架构设计中的关注点分离。外模式类似面向消费者的稳定契约，模式类似领域和数据的全局逻辑约束，内模式类似基础设施和物理实现。它提醒架构师：业务语义、接口表达和存储优化要有边界，不能让一个层次承担所有变化。
在做架构决策时，要问三个问题：用户和应用真正需要看到什么；系统必须维护哪些全局数据规则；为了质量属性，底层需要怎样存储和部署。答案分别对应外模式、模式和内模式。这样既能支持多个外部视图，又能让底层技术演进保持可控。
十一、案例分析：数据库拆分导致应用全面改造
某企业客户中心原有一张客户表，销售、客服、营销和财务应用都直接访问表结构。为了满足隐私要求，数据库团队将姓名、联系方式和身份证信息拆分到不同表，并重命名多个字段；同时为了性能增加分区和索引。由于没有外模式和兼容层，所有应用同时报错，部分报表还读取了不应暴露的敏感字段。
问题分析
应用直接依赖模式和内模式，三级模式之间没有有效隔离。逻辑结构拆分本身可能合理，但没有通过外模式/模式映像、视图、数据服务和版本迁移保持兼容；物理优化本应对应用透明，却因为 SQL 中写死分区和存储假设而产生影响；权限也没有按不同角色建立外部视图。
改进方案
先建立全局逻辑模式和数据分类，明确客户主数据、敏感字段、所有权和访问规则。为销售、客服、营销和财务分别设计外模式或数据服务，只提供必要字段和操作；通过兼容视图、字段映射和版本契约逐步迁移应用。底层拆分、分区和索引通过模式/内模式映像及访问层隐藏，使用性能测试确认变化。迁移期间保留旧接口、双读校验和回滚窗口，完成审计和数据脱敏验证后再关闭旧结构。
十二、综合知识练习与详细答案
练习一
请说明三级模式和两级映像分别是什么，并指出哪种数据独立性通常更容易实现。
参考答案：外模式是面向用户或应用的局部视图；模式是数据库全局逻辑结构和约束；内模式是物理存储结构。外模式/模式映像连接外模式与模式，模式/内模式映像连接模式与内模式。模式/内模式映像使索引、文件、分区等物理变化对上层透明，形成物理数据独立性；外模式/模式映像支持逻辑结构变化对应用相对透明，形成逻辑数据独立性。通常物理独立性相对更容易实现，逻辑独立性受业务语义变化影响更大。
练习二
数据库管理员增加索引后，应用功能没有修改但响应时间变长。是否说明物理数据独立性失效？
参考答案：不能仅凭响应变慢判断映像失效。物理数据独立性主要指物理结构变化不必修改逻辑模式和应用语义；索引增加可能改变执行计划、写入开销、锁竞争和资源使用，应用仍能正确运行，但质量属性受到影响。应检查统计信息、执行计划、索引维护、写入负载和资源指标，评估物理优化是否达到性能目标，必要时回退或调整索引。独立性不等于性能完全不受影响。
练习三
某应用直接查询数据库内部表和分区字段，数据库团队无法重构存储结构。请提出架构改进方向。
参考答案：应用越过外模式直接依赖模式和内模式，造成强耦合。应建立面向业务的视图、数据访问层或数据服务，隐藏表、分区、索引和存储引擎细节；定义稳定字段、权限和版本契约；对高风险变更采用兼容视图、渐进迁移、双读校验和回滚窗口；同时禁止新应用继续直接依赖物理字段，并通过评审和配置管理控制数据库访问边界。
十三、论文写作素材
论文中可以这样写：在数据架构设计阶段，我采用三级模式思想划分用户视图、全局逻辑数据结构和物理存储实现。根据销售、客服、财务等角色的职责建立不同外模式，通过视图或数据服务隐藏无关字段和敏感数据；在模式层统一定义实体、关系、主键、完整性约束、数据口径和生命周期；在内模式层根据容量、吞吐、延迟和可用性设计索引、分区、副本、压缩和存储布局。
为了降低变化影响，我建立外模式/模式映像和模式/内模式映像对应的兼容机制。对逻辑模式变更采用版本化接口、兼容字段、双读校验、数据回填和渐进切换；对物理结构优化通过索引、分区和存储迁移实现，使用执行计划、性能压测和容量监控验证，而不让业务代码依赖物理细节。所有模式、视图、迁移脚本和权限变更进入配置管理，完成评审、测试、审计和回滚准备。
十四、今日复盘
三级模式的关键不是记住三个名词，而是理解抽象和隔离：外模式面向不同用户和应用，模式描述全局逻辑结构，内模式描述物理存储；外模式/模式映像支持逻辑数据独立性，模式/内模式映像支持物理数据独立性。架构实践中，视图、数据服务、模式版本、兼容迁移、权限和配置管理都是实现这种思想的手段。
记忆主线：
外模式看局部，模式管全局，内模式管存储；逻辑映像隔离业务结构变化，物理映像隔离存储实现变化。
下一篇进入 6.2.1 关系数据库基本概念，继续学习关系、元组、属性、键、完整性约束和关系数据库的基本术语。
