Day32-17｜13.5.2 数据库设计与 XML 设计融合：让结构化数据与半结构化数据协同工作

对应教材：《系统架构设计师教程（第2版）》第13章“层次式架构设计理论与实践”13.5“数据架构规划与设计”中的 13.5.2“数据库设计与XML设计融合”。本文面向软考高级系统架构设计师，重点学习关系数据库与 XML 数据模型的差异、互补、映射、同步、查询、版本、安全和企业应用实践。

一、教材定位与学习目标

企业系统中的数据既有稳定、结构化、需要强约束和高并发事务处理的核心数据，也有结构变化频繁、层次复杂、来源多样和需要原样交换的半结构化数据。订单、账户、库存和员工主数据通常适合关系数据库；业务表单、外部交换文档、配置、电子合同和复杂报告可能更适合 XML。若把所有 XML 拆成大量关系表，结构变化和原文保留会变得困难；若把所有数据都存成 XML，又可能牺牲事务、查询性能、约束和统计能力。

数据库设计与 XML 设计融合的核心，是根据数据的稳定性、查询方式、事务要求、交换需求和生命周期选择合适的存储与表达方式，并建立可靠的映射和一致性机制。融合不意味着关系数据库和 XML 必须二选一，也不意味着把 XML 字符串随意塞入一个大字段就完成架构设计。架构师要回答：哪些字段是权威结构化数据，哪些是原文或扩展数据，如何校验和索引，如何同步，如何版本化，如何保证安全和可追溯。

本篇学习目标：

1. 理解关系数据、层次数据和半结构化 XML 的特点。
2. 掌握 XML 与关系表、列、关联和文档的映射策略。
3. 设计核心数据、扩展数据、原文、索引和查询模型的组合。
4. 处理 XML 与数据库之间的事务、同步、版本和冲突。
5. 能够结合案例题和论文说明数据库与 XML 融合的架构取舍。

二、关系数据库与 XML 数据模型的差异

1. 关系模型

关系数据库以表、行、列和约束组织数据，适合结构相对稳定、事务边界明确、需要连接和聚合查询的业务。它可以提供主键、外键、唯一、非空、检查、索引、事务、并发和备份恢复机制。

2. XML 模型

XML以树状文档组织数据，支持嵌套、重复、可选节点、属性、命名空间和扩展，适合文档交换、复杂层次结构和变化频繁的内容。XML能够保留原始结构和顺序，便于跨组织交换，但深层查询、局部更新、约束和高并发事务需要专门设计。

3. 半结构化数据

半结构化数据具有一定结构，但不要求所有记录完全相同。不同产品的配置可以共享基础字段，同时拥有各自扩展；不同机构提交的文档可以符合共同模式，又保留扩展节点。半结构化设计必须有核心字段、扩展边界、版本和校验规则，否则会退化为不可治理的自由文本。

三、融合架构的基本模式

1. XML作为交换格式，关系库作为权威存储

系统接收或发送 XML，但解析后把核心字段映射到关系表，必要时保存原文。该模式适合订单、患者、采购和财务等需要结构化查询和事务管理的业务。原文可以用于审计、重放和争议处理，但不能让业务查询完全依赖未索引的大字段。

2. XML作为文档存储，关系库保存索引和元数据

文档本身保存在 XML 文档库、对象存储或数据库 XML 类型中，关系表保存编号、类型、状态、所有者、版本和关键检索字段。该模式适合电子合同、报告、表单和复杂档案。核心查询字段要抽取或建立索引，避免每次扫描整份文档。

3. 关系核心加 XML 扩展列

固定核心属性使用关系列，变化频繁或组织自定义属性使用 XML 扩展列。该模式可以在稳定性和灵活性之间折中，但要限制扩展结构、定义 Schema、建立必要索引并防止所有字段都进入扩展列。

4. 双向映射与独立读模型

关系数据库保存业务写模型，XML作为外部交换或历史快照；系统通过映射器生成 XML，并通过校验器解析外部 XML。报表或搜索可以构建独立读模型。双向映射必须明确谁是权威源，不能让两个模型都自由修改同一业务属性。

四、XML 与关系数据的映射

1. 元素与列

简单元素可以映射为列，需定义类型、长度、精度、空值和默认值。嵌套元素不能简单拼成一个列名，应根据查询和更新需求拆成从表、JSON/XML列或文档存储。

2. 重复元素与明细表

订单中的多个明细、合同中的多个条款和报告中的多个结果通常映射为明细表。明细要保留顺序、业务标识、版本和父对象关系。若只保存 XML 原文而不拆核心明细，统计和约束会很困难。

3. 属性与元数据列

XML属性通常表示类型、标识和状态等辅助信息，可以映射为元数据列或同表字段。属性与元素的业务语义要统一，不能因为不同系统使用不同表达方式就丢失含义。

4. 选择分支与类型表

XML中的choice可以映射为类型字段加不同扩展表，或保留在文档列中。选择策略取决于分支稳定性、查询频率和结构差异。分支过多且变化频繁时，完全关系化可能产生大量空列和迁移；完全文档化又可能失去约束。

5. 命名空间与模型版本

不同命名空间可以映射到不同业务模块或版本。映射器必须知道命名空间、模式版本和字段来源，不能只依据元素本地名称，否则同名字段可能被错误映射。

五、权威数据、原文和扩展数据设计

1. 明确权威源

客户名称、订单金额、合同状态等关键属性应有唯一权威源。XML交换文档可能携带这些字段，但接收后是否覆盖本地值，要根据业务和来源可信度决定。原文保存不代表原文自动成为业务权威。

2. 原文保存的价值

保存原始 XML 有利于审计、重放、争议处理、问题定位和未来重新解析。原文要有消息ID、来源、接收时间、Schema版本、签名摘要、处理状态和保留期限。敏感文档要加密、访问控制和脱敏。

3. 扩展机制

组织或产品扩展应使用命名空间、扩展节点和版本，不应随意修改核心字段。扩展字段要有负责人、类型、取值、是否可查询和生命周期；高频查询的扩展字段应抽取索引或关系列。

4. 快照与当前状态

XML文档常表示某一时点的完整快照，关系表可能表示当前状态。两者之间存在时间语义差异。系统要区分文档生成时间、接收时间、业务生效时间和当前更新时间，不能用最后修改时间代替全部含义。

六、同步、事务与一致性

1. 同步方向

同步可以是数据库生成 XML、外部 XML 更新数据库，或两者通过事件协作。每条同步链路要明确方向、触发、频率、失败重试、幂等和冲突处理。

2. 同事务解析和保存

小型 XML 接收场景可以在一个本地事务中完成解析、核心数据保存和处理记录写入。大文档和耗时校验不宜占用长事务，可以先保存原文和待处理状态，再异步解析和更新，流程通过状态机保证可追踪。

3. 可靠消息

数据库状态和消息发布可能出现一方成功、一方失败。可以采用事件表、可靠消息、事务消息和重试机制，确保后续生成或同步任务不丢失。消费者必须按消息ID和业务编号去重。

4. 冲突处理

如果本地用户修改了数据，同时外部 XML 带来更新，应根据来源优先级、版本、时间、业务状态和人工审核处理。不能简单使用“最后写入覆盖”，这可能让旧文档覆盖最新业务结果。

七、查询、索引与性能治理

1. 关键字段抽取

对经常按客户、订单、状态、时间和组织查询的字段，应抽取到关系列或建立 XML 索引。索引设计要结合选择性、数据量、更新成本和权限过滤。

2. 文档查询

完整文档读取适合详情和下载；列表、统计和筛选应使用元数据表或读模型。避免在高并发接口中反复解析大型 XML。必要时使用流式解析、分页和异步转换。

3. 局部更新

XML文档局部更新可能需要重新序列化整个文档，带来锁和写放大。频繁变化的字段应结构化存储，稳定的复杂内容再保存为 XML。文档更新要使用版本和乐观锁防止覆盖。

4. 缓存

Schema、字典和稳定模板可以缓存；涉及权限、租户和当前状态的文档缓存要包含版本和访问范围。缓存不能绕过 XML 签名、授权和数据脱敏。

八、安全与治理

1. 安全解析

不可信 XML 要禁用外部实体、DTD和远程资源，限制文档大小、深度、节点数和解析时间，防止XXE和资源耗尽。

2. 文档完整性

外部交换文档可以使用签名、摘要和时间戳验证来源和完整性。映射前要验证签名、来源、Schema版本和业务权限。

3. 敏感数据

XML文档可能包含身份证号、病历、合同和财务信息。存储、传输、日志和备份都要加密或脱敏，按字段和业务目的控制访问。错误日志不能打印完整文档。

4. 版本和生命周期

文档、Schema、映射器、数据库结构和业务规则要分别版本化。原文按保留期限归档或销毁，删除操作要符合合规要求并保留必要审计。

九、案例分析：电子合同管理平台

某企业合同平台接收外部供应商的 XML 合同，文档包含合同主体、条款、金额、附件和扩展字段。原系统将整个 XML 存在数据库大字段中，页面每次打开都解析全文；合同状态、金额和供应商名称也只能从文档中读取，导致查询慢、统计困难和状态覆盖。

1. 目标架构

关系表保存合同编号、供应商、合同类型、金额、状态、生效时间、版本、所有者和审计字段；XML 文档保存完整合同结构、条款、扩展和原文快照；附件使用对象存储，关系表保存文件元数据；关键条款和金额按查询需要抽取索引。

2. 接收流程

网关检查来源、签名、大小和安全解析；Schema校验通过后保存原文和消息记录；应用服务抽取核心字段并检查供应商、金额、合同状态和权限；成功后生成合同版本和处理事件；复杂条款解析异步执行，失败进入人工队列。

3. 一致性策略

合同当前状态和版本以关系模型为权威，XML作为该版本快照；用户修改合同通过应用服务产生新版本和新 XML，不允许直接改原文字段；外部更新通过版本号和来源规则判断，冲突时人工审核；全文检索和报表通过事件更新读模型。

4. 性能和安全

列表使用结构化列和索引，详情按需读取 XML；Schema和映射器缓存编译结果；文档加密存储，访问按供应商、组织和角色控制；审计记录文档版本、操作者、来源、签名和处理结果。

5. 指标

通过合同列表响应时间、XML解析耗时、结构化字段查询命中率、版本冲突数、文档处理成功率、人工处理时长、敏感文档越权数和历史可追溯率评价效果。

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

练习一：单项选择

对于需要高频条件查询和统计的订单金额、状态等字段，较合理的做法是（ ）。

A. 永远只保存在 XML 原文中 B. 抽取为结构化列或读模型，并保留必要原文 C. 每次查询时解析所有 XML D. 让客户端自行解析和统计

答案：B。高频查询字段应结构化，原文可用于审计、重放和完整性保存。

练习二：多项选择

数据库与 XML 融合设计通常需要考虑（ ）。

A. 权威数据源 B. 原文与快照 C. Schema和版本 D. 同步和幂等 E. 只采用最后写入覆盖冲突

答案：A、B、C、D。最后写入覆盖可能造成旧文档覆盖最新业务状态，不能作为通用冲突策略。

练习三：案例题

某系统把全部业务数据保存为 XML 大字段，虽然适应了字段变化，但订单查询、统计和并发更新性能很差。项目组准备把所有 XML 拆成关系表。请分析两种极端方案的问题并给出改进方案。

参考答案：全部 XML 大字段可以保留复杂结构和扩展，但高频条件查询、聚合统计、局部更新和并发控制成本高，重复解析造成性能压力；全部关系化虽然查询和约束较强，但复杂文档、层次结构、原文顺序和频繁扩展会导致表数量增加、迁移频繁、字段空置和原文丢失。改进时应按数据特征采用混合模型：订单编号、客户、金额、状态、组织和时间等核心字段使用关系列并建立索引；明细根据查询和事务要求拆表；复杂条款和扩展内容保存为 XML 文档或扩展列；保留原文、Schema版本和处理记录；明确关系状态为权威源，XML为交换或版本快照；通过事件、可靠消息和幂等实现同步；对大文档采用异步解析、流式处理和按需读取；设计版本、乐观锁、冲突审核、加密和安全解析；通过压测、数据对账和历史重放验证。

十一、案例题答题模板

遇到数据库与 XML 融合、文档存储、数据交换和半结构化数据类题目，可以按以下顺序作答：

1. 分析核心数据、扩展数据、原文、查询、事务和交换需求。
2. 选择关系列、明细表、XML列、文档库、对象存储和读模型的组合。
3. 定义 XML Schema、命名空间、版本、映射器和字段语义。
4. 明确权威数据源、快照、同步方向、事务、事件、幂等和冲突处理。
5. 对高频查询字段建立列或索引，对大文档采用流式、异步和按需读取。
6. 加入安全解析、签名、加密、脱敏、权限、审计和生命周期治理。
7. 通过性能、兼容、对账、重放、恢复和数据安全测试验证方案。

十二、论文写作素材

开头素材

“某电子合同平台原先将合同全部保存为 XML 大字段，虽然能够适应不同产品的扩展，但合同列表、统计和状态更新性能较差，历史版本和业务权威关系也不清晰。为兼顾结构化查询与复杂文档保存，我参与设计数据库与 XML 融合架构，将合同核心属性结构化存储，将条款和扩展内容保存为版本化 XML，并建立 Schema、映射、同步、权限和审计机制。”

正文素材

可以重点写四点：第一，如何区分关系数据库的核心事务数据、XML文档、扩展字段和附件；第二，如何通过元素、重复节点、命名空间、Schema和映射器建立双模型对应；第三，如何确定权威源和快照关系，使用可靠消息、幂等、事件、版本和冲突审核保障一致性；第四，如何处理文档查询、索引、局部更新、大文档解析、XXE、防泄露、加密和生命周期。要强调数据库与 XML 不是简单二选一。

结尾素材

“实践表明，数据库与 XML 融合的关键不是把一种数据格式嵌入另一种存储，而是根据数据稳定性、查询方式、事务要求和交换边界进行分层建模。通过核心结构化、复杂内容文档化、权威源明确和版本同步可追溯，系统可以同时获得关系模型的可靠查询能力和 XML 的灵活表达能力。”

十三、今日复盘

本节核心结论是：关系数据库擅长核心结构化事务和查询，XML擅长层次化文档、扩展和跨系统交换；融合设计必须明确权威源、映射、版本、同步、索引、安全和生命周期。

请回答：

1. 什么数据适合关系列，什么数据适合 XML 文档或扩展列？
2. 为什么保存 XML 原文不等于 XML 是业务权威源？
3. XML 重复元素、choice和命名空间如何映射到关系模型？
4. 数据库状态与 XML 快照不一致时如何处理？
5. 大 XML 文档如何进行查询、解析和性能优化？
6. 如何防范 XML 解析攻击和敏感文档泄露？

请以合同、订单或医疗报告为例，画出“关系核心数据—XML文档/扩展—Schema—映射—事件同步—读模型”的关系，标注权威源、版本、事务、索引、加密、审计和冲突处理位置。完成后，你就掌握了 13.5.2 的核心内容。