想象你要把一间装满货架的仓库搬到新地址。仓库里有几百个货架（父表）,每个货架上堆着货箱（子表）,货箱上贴着标签，写着“本箱属于几号货架”（外键）。为了不把真实货单带走，你请人照着原样仿制一批货物（合成数据）,再搬过去。可是搬家师傅只图省事，把货箱一股脑丢进新仓库，标签却贴得乱七八糟——客人来取货时，谁也找不到自己的箱子。合成表格数据就是一次“搬仓库”:把客户表、订单表这些彼此关联的表全部换成脱敏的仿制品，同时保住每张订单指向哪个客户的外键标签。本文要教的，就是怎么把这些标签贴准、贴全，让新仓库既保护隐私，又能立刻正常营业。

岗位关联

对 AI 从业者来说，学会关系数据合成意味着你能在保护隐私的同时产出“联表查询不出错”的测试数据，让数据脱敏、模型评估和业务压测都能放心使用合成数据，这是数据工程质量的关键一环。

目录
  1. 可视化演示
  2. 关系数据库基础
  3. 合成数据价值
  4. 关系建模挑战
  5. 条件生成方法
  6. 约束传播机制
  7. 统计保真评估
  8. 工程化实践
  9. 业务真实应用
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

动态演示合成表格数据中的关系建模的核心机制，通过架构/数据/状态/性能四种模式展示关键概念与交互流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

合成表格数据中的关系建模：关系数据 关系数据合成的一致性挑战与整体 外键约束与表间关联的建模方法 核心机制可视化 合成表格数据中的关系建模整体架构与关键组件

关系数据库基础

回到搬仓库的现场。仓库里真正的骨架不是货箱，而是那一排排货架。货架上有唯一编号，箱子上也有唯一编号，但最要紧的是箱子侧面的标签——“所属货架号”。在数据库里，货架就是父表，货箱就是子表，箱子的“唯一箱号”叫主键(PK),标签上的“所属货架号”叫外键(FK)。一个货架能堆很多箱子，这就构成了一对多关系；如果一张表同时要参照两张表，就形成更复杂的多对多关系。所有标签都必须指向真实存在且有唯一编号的货架，这个规则叫引用完整性。

关系数据建模的第一步，就是搞清楚谁是父、谁是子，以及外键指向哪张表的哪个主键。比如订单表通常带着“customer_id“,它指向客户表的”id”。客户表是父表，订单表是子表。若一份合成数据把订单生成了，却让 customer_id 指向了不存在的客户，那么任何联表查询都会查到一堆空结果。用形式化语言描述，外键约束本质上是一个集合包含关系：子表里的每个外键值，都属于父表主键集合。

理解好“谁是父、谁是子”之后，才能谈“怎么仿制”。否则仿制出来的仓库，货架和货箱各说各话，连最基本的引用完整性都守不住。这也是为什么所有关系数据合成项目，都要先从梳理主键-外键血缘开始。

∀fk∈C, ∃pk∈P: fk=pk\displaystyle \forall fk \in C,\ \exists pk \in P:\ fk = pk
这条式子是说：子表 C 里的每个外键 fk,都能在父表 P 的主键集合中找到相等的 pk。它是一切关联建模的“地基”。
  1. 全称量词$\forall$ 表示“任意一条”,要求子表里所有外键都被纳入考量，不能放过任何一条漏网之鱼。
    ∀\displaystyle \forall
  2. 外键取值$fk$ 是子表中的外键列，相当于货箱上的货架标签，记录着“我属于谁”。
    fk\displaystyle fk
  3. 主键匹配$fk = pk$ 表示标签上的编号必须与某个货架的真实编号完全一致，差一位数字都不算合格。
    fk=pk\displaystyle fk = pk
  4. 整体约束把全称量词、存在量词和主键匹配连起来，就是对整张子表的合法性声明：凡是贴了标签的箱子，都必须能找到真实货架。
    ∀fk∈C, ∃pk∈P: fk=pk\displaystyle \forall fk \in C,\ \exists pk \in P:\ fk = pk

合成数据价值

真实仓库里的货物往往带敏感信息，比如客户姓名、身份证号、订单金额。直接搬到测试环境，等于把真实财产清单交给所有人看，隐私风险极高。合成数据的作用，就是让师傅照着原样仿制一批“看起来差不多”的货物：货架数量相似、货箱大小相似、标签习惯相似，但具体内容全部替换成虚拟信息。原始数据是 D,合成数据就是 D̃。

为什么需要这样做？主要有三股推动力。第一是数据脱敏，银行、医院的生产库绝对不能直接给到测试环境；第二是测试数据生成，很多场景需要“像真实但又不存在”的数据来压测系统；第三是隐私与合规，GDPR、个人信息保护法都要求对外共享前做去标识化或合成化处理。只做单表脱敏很简单，难点在于：替换后的客户主键变了，订单表的外键怎么办？如果不同步替换，关联就断了。

合成数据的价值不在于“凭空造货”,而在于让仿制品保留真实仓库的可用结构。如果师傅把货架和货箱的对应关系弄丢了，那仿制出来的仓库连日常取货都做不到，更别提交给业务方做测试了。

D~=G(Z; θ)\displaystyle \tilde{D} = G(Z;\ \theta)
可以把 $G$ 想成一位仿制师傅，把 $Z$ 想成一张空白货单，$\theta$ 想成师傅的手艺参数。师傅照着空白货单填上仿制内容，就得到合成数据表 $\tilde{D}$。
  1. 合成数据表$\tilde{D}$ 头顶的波浪号表示“仿制版”,它从结构上模仿原始数据，但内容不再包含真实个体信息。
    D~\displaystyle \tilde{D}
  2. 生成器$G$ 是仿制师傅，可以是条件生成模型，也可以是一套基于统计分布的采样程序。
    G\displaystyle G
  3. 随机噪声$Z$ 是生成时的随机种子与噪声，相当于师傅手中那张本身没有意义的空白货单，填入不同内容便产出不同数据。
    Z\displaystyle Z
  4. 模型参数$\theta$ 决定师傅的仿制手法，比如学会了“客户的年龄分布”和“订单金额分布”,才能仿得又像又不真。
    θ\displaystyle \theta

关系建模挑战

搬仓库最容易出的乱子，是货箱到了新仓库却发现货架没来——或者货架换了新编号，箱子上的标签却没改。这样的货箱就是“无家可归的孤儿箱”,在数据库里叫孤儿记录(orphan record)。我们用一个指标来衡量这个乱子：孤儿率。它统计子表里有几条记录的外键，不在父表主键集合里。高孤儿率意味着引用完整性被严重破坏。

造成关系建模挑战的常见原因有三类。一是生成时没有感知外键，各表独立采样，随机生成了根本不存在的 customer_id;二是主键重映射不同步，父表主键已脱敏成新值，子表外键却还复制着旧值；三是级联删除没有建模，用户被删除后，与之关联的订单没有同步处理。任何一个环节出错，联表查询都会产出空结果或错乱结果。

面对这些挑战，我们需要建立“先父后子”的生成纪律：每次动工前先统计孤儿率，把它当成关系建模的血压计。一旦发现孤儿率过高，立刻停下生成流程，回头检查外键映射逻辑。

OrphanRate=∣{ r∈C~: r.fk∉P~.pk }∣∣C~∣\displaystyle \text{OrphanRate} = \frac{|\{\, r \in \tilde{C}:\ r.\text{fk} \notin \tilde{P}.\text{pk} \,\}|}{|\tilde{C}|}
孤儿率 = 外键悬空的子记录数 ÷ 子表总记录数。它直观反映“一批货箱里有多少箱子找不到货架”。
  1. 分子集合$\{ r \in \tilde{C}:\ ... \}$ 把子表里满足特定条件的记录挑出来装进集合，准备计数。
    {r∈C~: r.fk∉P~.pk}\displaystyle \{ r \in \tilde{C}:\ r.\text{fk} \notin \tilde{P}.\text{pk} \}
  2. 悬空条件$r.\text{fk} \notin \tilde{P}.\text{pk}$ 表示“这条记录的外键不在父表主键集合中”,即标签指向了不存在的货架。
    r.fk∉P~.pk\displaystyle r.\text{fk} \notin \tilde{P}.\text{pk}
  3. 子表规模$|\tilde{C}|$ 表示子表总行数，用来把孤儿数量归一化成比率，便于跨表对比。
    ∣C~∣\displaystyle |\tilde{C}|
  4. 整体比率分子分母相除，得到 0 到 1 之间的值，乘 100% 就是业务上常说的“外键命中率”的互补指标。
    ∣{ r∈C~: r.fk∉P~.pk }∣∣C~∣\displaystyle \frac{|\{\, r \in \tilde{C}:\ r.\text{fk} \notin \tilde{P}.\text{pk} \,\}|}{|\tilde{C}|}

条件生成方法

正确搬仓库的姿势，不是把货箱往地上一倒再瞎贴标签，而是“先立货架，再配货”:师傅先按规划把货架编号全部定好，然后搬一箱货，看一眼它原来属于几号货架，在新仓库找到对应编号，贴上标签放好。这套流程对应关系数据合成里的核心方法：父表先行抽样，然后基于父记录进行条件生成。

具体做法是：第一步，用生成模型按原始分布合成父表，拿到一批新的主键；第二步，遍历原始子表每条记录，找到它原来的父记录；第三步，从新主键中选出与原父记录对应的替代者，把子记录“挂”到它下面。这里的数学本质是条件概率——我们要的不是子表的整体分布，而是“给定父记录之后”子记录应该长成什么样。

条件生成是关系建模的灵魂。没有它，每张表都像是被丢进搅拌机打散的碎片；有了它，新的客户表一诞生，订单表就自动知道该往谁名下挂，外键命中率从源头就有了保障。

P(rc∣rp)=P(rc, rp)P(rp)\displaystyle P(r_c \mid r_p) = \frac{P(r_c,\ r_p)}{P(r_p)}
意思是在已知“父记录 $r_p$ 存在”的前提下，子记录 $r_c$ 出现的概率。父先出现，子的分布跟着父走，这就是条件生成与独立生成的根本区别。
  1. 条件概率符号$P(r_c \mid r_p)$ 读作“在 $r_p$ 发生的条件下 $r_c$ 的概率”,竖线后面是条件，前面是目标。
    P(rc∣rp)\displaystyle P(r_c \mid r_p)
  2. 联合概率$P(r_c,\ r_p)$ 表示两条记录同时出现、成对出现的可能性，相当于“这箱货和这个货架本来就在一起”。
    P(rc, rp)\displaystyle P(r_c,\ r_p)
  3. 边缘概率$P(r_p)$ 表示父记录单独出现的概率，不管子记录有没有，父表本身也有自己的分布规律。
    P(rp)\displaystyle P(r_p)
  4. 整体公式联合概率除以边缘概率，就像把“共同的缘分”除以“货架本身的存在感”,剩下的才是“货架对货箱的条件约束”。
    P(rc, rp)P(rp)\displaystyle \frac{P(r_c,\ r_p)}{P(r_p)}

约束传播机制

仓库里的货架不可能永远不变。旧仓库用的是“货架 A-01”,新仓库可能改成"A-001"。货架编号一变，所有贴在货箱上的标签都必须跟着变，这个连锁反应在数据库里叫约束传播。合成数据中最常见的就是主键重映射：父表的主键脱敏后全部换成新值，于是必须定义一个映射函数 h,把旧主键映射到新主键，再沿着外键关系传播到所有子表。

约束传播还有另一面：级联约束更新。如果父表某条记录被删除，子表中引用它的记录要么跟着删除，要么在业务上被禁止删除该父记录。生成合成数据时，我们要把这些业务规则一并建模：主键变了，外键同步变；父记录删了，子记录要有明确去向；批量插入子表后，再做一次外键约束校验，确保没有漏网之鱼。这样才能让合成数据在“结构完整性”上经得起推敲。

约束传播让合成数据的“血缘关系”在脱敏后仍然不断线。它和条件生成互为表里：条件生成解决“孩子怎么生”,约束传播解决“长辈改身份后孩子怎么改户口”。

fk′=h(pk),h: PKold→PKnew\displaystyle fk' = h(pk),\quad h:\ \text{PK}_{\text{old}} \to \text{PK}_{\text{new}}
旧主键通过映射函数 h 变成新主键，所有外键也随之换成新值。这相当于搬家师傅手里的“新旧货架对照表”。
  1. 新外键$fk'$ 带撇号表示更新后的外键，它是子表在新仓库里重新贴上的标签。
    fk′\displaystyle fk'
  2. 映射函数$h$ 是一张查不到就报错的对照表，输入旧主键，输出新主键，保证一一对应。
    h\displaystyle h
  3. 旧主键集合$\text{PK}_{\text{old}}$ 是脱敏前的主键取值区间，映射表的“左半部分”。
    PKold\displaystyle \text{PK}_{\text{old}}
  4. 新主键集合$\text{PK}_{\text{new}}$ 是脱敏后的新主键取值区间，映射表的“右半部分”,整体式子表达的就是“旧标签换新标签”的全过程。
    PKnew\displaystyle \text{PK}_{\text{new}}

统计保真评估

搬完仓库不能直接营业，得先盘点：新仓库每个货架上的货箱数量分布、货物类别占比，和原来的仓库像不像？如果原来 60% 的货架都堆满了生鲜箱，新仓库却有 80% 是空箱，那这套合成数据在业务上就“失真”了。统计保真评估，就是检查合成数据与原始数据在统计层面的相似度。

常用的指标有三个层次。第一是分布相似度，看单列的取值分布是否接近，比如订单金额直方图；第二是关联强度保持，看两列之间的相关性是否保留，比如“高消费客户往往下更多订单”这条规律，合成数据里还在不在；第三是统计检验方法，比如卡方检验，从“差异是否显著”的角度给出量化结论。注意，卡方检验关注的是观察频数是否偏离期望频数，而不是只看行数是否相等。

统计保真评估的本质，是给“仿得像不像”这件事装上一把尺子。光靠肉眼看不准，要用卡方、相关系数这些客观指标反复比对，才能保证搬进新仓库后的数据分析结论和原仓库保持一致。

χ2=∑i=1k(Oi−Ei)2Ei\displaystyle \chi^2 = \sum_{i=1}^{k} \frac{(O_i - E_i)^2}{E_i}
$\chi^2$ 越大，说明合成数据与原始数据越“不像”;反之越小，说明两者分布越接近。它是搬家后的“对账审计”。
  1. 卡方统计量$\chi^2$ 是希腊字母卡方，专用来度量“实际观察”与“理论期望”之间的差距。
    χ2\displaystyle \chi^2
  2. 求和范围$\sum_{i=1}^{k}$ 把全部 k 个分组逐个加起来，比如按价格分 10 档就加 10 次。
    ∑i=1k\displaystyle \sum_{i=1}^{k}
  3. 偏差平方$(O_i - E_i)^2$ 是第 $i$ 组的观察频数与期望频数之差，平方后不管正负偏差都当作正贡献。
    (Oi−Ei)2\displaystyle (O_i - E_i)^2
  4. 归一化分母除以 $E_i$ 相当于按期望量级做缩放，让小数量的分组的偏差不会被大数组淹没。
    (Oi−Ei)2Ei\displaystyle \frac{(O_i - E_i)^2}{E_i}

工程化实践

真实业务里的仓库，不是几十个货架，而是几十万甚至上百万个。如果搬家师傅一个一个货箱慢慢搬，搬完再做全表校验，业务早就等不及了。工程化实践要回答的问题是：如何高效地大批量生成关系数据，还能保证外键一致性。核心思路是“分区域并行搬，最后统一对账”。

实际操作中，团队会先把父表按某种规则分片，比如按用户 ID 哈希成 16 个分区，每个分区并行生成父记录；再并行生成各自的子记录，因为子记录只需知道自己分区内的父主键；最后把所有分区的外键信息收集起来，做一次批次更新和一致性校验。这样把串行的“生成 → 校验 → 更新”改造成并行的“边生成边攒映射，最后统一刷外键”,大幅缩短搬仓时间。

工程化实践把关系建模从“纸面理论”变成了“生产可跑”。没有它，再完美的条件生成和约束传播，也扛不住亿级数据量的现实考验。

S=TserialTparallel\displaystyle S = \frac{T_{\text{serial}}}{T_{\text{parallel}}}
加速比 $S$ 衡量“并行搬仓比串行搬仓快了多少倍”。并行度越高、等待越少，加速比越大，仓也就搬得越快。
  1. 加速比$S$ 是性能指标，大于 1 说明并行比串行快，等于 2 表示快了一倍。
    S\displaystyle S
  2. 串行时间$T_{\text{serial}}$ 是只有一个师傅慢慢搬完全部货物所需的总时长。
    Tserial\displaystyle T_{\text{serial}}
  3. 并行时间$T_{\text{parallel}}$ 是多位师傅同时分区域搬货所需的总时长，包含最后汇总对账的时间。
    Tparallel\displaystyle T_{\text{parallel}}
  4. 整体公式两个时间相除，就是并行改造带来的收益倍数；如果并行通信开销过大，加速比反而可能小于 1。
    TserialTparallel\displaystyle \frac{T_{\text{serial}}}{T_{\text{parallel}}}

业务真实应用

新仓库终于装修完毕，开门营业。客人报出订单号，系统必须立刻把订单连同客户的姓名、地址一起取出来——这就要用到联表查询。如果订单表的外键找不到客户表的主键，查询直接返回空，客人会以为订单丢了。所以，关系数据合成的最终验收标准，就是看它在真实业务场景里跑不跑得通、查不查得到数据。

三大典型场景最能体现它的价值。第一，联表查询测试：测试环境需要大量“客户-订单-支付流水”联表数据，用于回归验证报表系统；第二，测试环境再造：预发环境要无限接近生产，同时不能触碰真实隐私；第三，数据共享合规：对外部合作伙伴提供研究数据时，既要保留关联性又要满足法律要求。这三类场景都指向同一个数学动作：对子表和父表做连接查询，并按业务条件筛选。

当合成数据能稳稳支撑起这些联表查询时，“搬仓库”才算真正成功。它不是制造一堆漂亮的假数据，而是让脱敏后的数据依然拥有真实业务世界的关联骨架，让开发、测试、分析都在安全的环境里安心取数。

R=σcond(C⋈P)\displaystyle R = \sigma_{\text{cond}}(C \bowtie P)
先把子表 $C$ 和父表 $P$ 做自然连接（找到外键-主键匹配对）,再按条件 $\text{cond}$ 筛选，得到的结果 $R$ 就是“客人要的取货单”。
  1. 结果集$R$ 是查询返回的最终数据，相当于客人取到的货箱清单。
    R\displaystyle R
  2. 连接运算$\bowtie$ 表示把两张表按“子表外键 = 父表主键”的条件拼接起来，像把货箱和货架信息合成一张完整单据。
    C⋈P\displaystyle C \bowtie P
  3. 选择运算$\sigma_{\text{cond}}$ 是按条件筛选行，比如“只查本月下单的客户”,过滤掉不相关的记录。
    σcond\displaystyle \sigma_{\text{cond}}
  4. 整体表达式连接在前、选择在后，先在结构上对齐关系，再从结果里挑出业务需要的部分，这就是联表查询在关系代数里的标准写法。
    R=σcond(C⋈P)\displaystyle R = \sigma_{\text{cond}}(C \bowtie P)

AI 应用场景

银行联机交易测试数据再造

阶段：数据生成与增强

解决的问题：银行测试环境需要客户、账户、流水三张高关联表，传统做法是直接对生产库做脱敏导出，但往往把流水表的账号外键脱敏脱断了，导致联表报表大面积为空。关系数据合成通过“先抽客户表，再按客户-账户-流水的链式条件生成”,保证每笔流水都能落到已生成的账户上。

具体案例：某支付公司在压测前需要千亿级流水数据。改造前随机造数导致交易明细与账户无法关联；改造后先合成 2 万客户，再按账户分级条件生成流水，联表命中率达到 100%,压测报表全部正常返回。

医疗科研数据共享脱敏

阶段：数据脱敏与隐私计算

解决的问题：医院要把患者、就诊记录、处方记录交给外部科研团队，直接给原始外键等于把身份关联结构一并泄露。合成方案先对患者主键做不可逆重映射，再把新主键沿就诊、处方外键逐级传播，既保护隐私又保留完整诊疗链。

具体案例：某药企在真实世界研究中收到 5 万条合成病历，同一个患者的多次就诊仍能串成完整病史链，但姓名、手机号等敏感字段全部替换为虚拟值，合规部门顺利放行。

数据库迁移与全链路压测演练

阶段：数据迁移与验证

解决的问题：老数据库迁向新架构时，外键规则和存储结构都变了，需要一个足够大且关联完好的数据副本验证迁移脚本。关系合成数据可以按需生成“订单-商品-商家”等关联数据，反复演练迁移流程而不触碰生产数据。

具体案例：某电商在双十一前将订单库迁至新分库，先在预发环境用合成数据跑了全链路压测，提前发现三条外键中断脚本，上线后订单与商品联表查询零异常。

Python 演示

python44 行
import random  class ForeignKeyGenerator:    """外键感知的合成数据生成器(教学演示版)"""     def __init__(self, parent_count, child_count, seed=42):        random.seed(seed)        self.parent_count = parent_count        self.child_count = child_count        self.child_rows = []     def generate(self):        # 第一步:先生成父表主键,它们是外键的合法取值来源        self.parent_ids = [f"P{i:04d}" for i in range(self.parent_count)]        pk_set = set(self.parent_ids)         # 第二步:为每条子记录从现有父主键中随机采样外键        for i in range(self.child_count):            fk = random.choice(self.parent_ids)            self.child_rows.append({                "child_id": f"C{i:04d}",                "parent_fk": fk            })         # 第三步:人为删除一个父记录,再让最后一条子记录引用它        removed = self.parent_ids.pop()        self.child_rows[-1]["parent_fk"] = removed         # 第四步:用"仍然存活"的父主键集合筛出孤儿记录        valid_pks = set(self.parent_ids)        orphan_rows = [            row for row in self.child_rows            if row["parent_fk"] not in valid_pks        ]        return orphan_rows  if __name__ == "__main__":    demo = ForeignKeyGenerator(parent_count=20, child_count=200)    orphans = demo.generate()    total = len(demo.child_rows)    hit_rate = (total - len(orphans)) / total    print(f"外键命中率: {hit_rate:.2%}, 孤儿记录数: {len(orphans)}")
目的：用 20 个父记录和 200 条子记录模拟“先父后子”的条件生成流程，再人为删除一个父记录，演示外键悬空后孤儿记录如何被识别。
  1. self.parent_ids = [f"P{i:04d}" for i in range(self.parent_count)]为每一位“货架”先生成唯一编号，这就是父表主键。
  2. pk_set = set(self.parent_ids)把主键列表转成集合，方便后续 O(1) 判断外键是否有效。
  3. fk = random.choice(self.parent_ids)从现存货架中随机挑一个，保证生成瞬间外键不悬空。
  4. removed = self.parent_ids.pop()模拟现实中有人撤走一个货架，即挖掉一个主键。
  5. self.child_rows[-1]["parent_fk"] = removed特意让最后一条子记录引用已删除货架，制造一条可演示的孤儿记录。
  6. valid_pks = set(self.parent_ids)重新统计“仍然存活”的货架编号，作为外键有效集。
  7. if row["parent_fk"] not in valid_pks孤儿判定：外键不在合格集里，立刻报警。
  8. hit_rate = (total - len(orphans)) / total用命中率量化“标签贴对的比例”,评估整套生成流程的好坏。

常见误区

误区我只要把每张表单独跑一遍生成模型，行数对得上、每列分布像，就算完成了。表之间的关联无所谓，反正测试环境查得出来就查，查不出来也不影响单表功能验证。

正解单表分布正确只是第一步。订单表的外键如果找不到客户表的主键，联表查询直接空转，业务报表、风控模型全都会拿不到完整数据。正确做法是把外键约束当成一等的生成目标，通过条件生成保证关联完整，再在结束时统计孤儿率。

为何常见：多数基础生成模型按单表独立训练，新手容易把表格数据看成互相独立的样本集，忽略了数据库的关系语义。

误区外键不就是一列数字吗？我直接随机生成 1 到 1000 的整数填进去，看起来有模有样，查数据库也不会报错。

正解外键的取值空间不是全域，而是父表主键的实际集合。如果父表主键只到 50,子表随机生成到 1000,就会有 95% 的记录变成孤儿。外键本质是指针语义，必须从父表主键集合里采样。

为何常见：把外键当普通数值特征处理，没理解它指向另一个表主键的引用关系。

误区父表主键反正也不写真实姓名，直接把原始外键值原样搬进合成数据，关联一定不会断，这不就是最安全的做法吗？

正解如果父表主键脱敏后已重映射为新值，直接复制旧外键会导致关联断裂；更严重的是，复用原始外键会让攻击者反推出原始记录的关联结构，隐私保护形同虚设。正确方式是通过映射函数 h 把旧外键同步转换成新外键。

为何常见：看到“外键”两个字就以为只是复制数字，没有意识到主键也会被脱敏重编码，外键必须和主键联动。

误区我检查过了，所有外键都能在父表里找到对应主键，引用完整性已经 100%,统计保真肯定也达标了。

正解外键有效只说明引用完整，不代表统计保真。比如“高端客户订单金额显著更高”这种跨表相关性，可能在外键有效的情况下完全消失。要真正评估保真度，还得用卡方检验、相关系数对比等工具检查列间关联强度。

为何常见：把“约束校验”等同于“质量评估”,忽略了业务分析师真正看重的，是跨表联动规律是否被保留。

面试题

Q1. 合成表格数据时，最容易导致联表查询测试失败的原因是？

单选题 · easy

  • A.单表行数太少
  • B.表间关联断裂← 正确答案
  • C.主键不是自增
  • D.字段类型不匹配

答案：B。表间关联断裂意味着订单表的外键找不到客户表主键，联表查询会返回空集或漏数据。主键自增、字段类型与关联断链无关，单表行数多也挽救不了坏掉的关联。

Q2. 关于外键约束，下列说法正确的是？

单选题 · easy

  • A.外键取值必须全局唯一
  • B.外键必须与父表无关
  • C.外键需落在父表主键集合内← 正确答案
  • D.外键只能指向同一张表

答案：C。外键的合法取值域就是父表主键集合，像货箱标签必须指向真实货架。外键不要求全局唯一，也不与父表无关，更不是只能指向同一张表。

Q3. 以下哪些做法有助于在合成数据中保留关系一致性？

多选题 · mid

  • A.父表先行抽样生成← 正确答案
  • B.外键感知条件生成← 正确答案
  • C.完全随机生成外键
  • D.级联约束传播校验← 正确答案

答案：ABD。搬仓库时正确做法是先摆好货架（父表）,再对照货架配货（条件生成）,最后有人复核标签（约束校验）。完全随机生成外键等于乱贴标签，必然产生找不到货架的孤儿箱，因此不能选 C。

Q4. 数据库中的“孤儿记录”指的是？

单选题 · easy

  • A.缺少主键值的记录
  • B.外键指向不存在父表主键的记录← 正确答案
  • C.重复写入两次的记录
  • D.主键与外键取值相同的记录

答案：B。孤儿记录就像无家可归的货箱——它的外键指向一个根本不存在的货架。缺少主键叫主键空值，重复写入是冗余，主外键相同是自定义规则，都不是孤儿定义。

Q5. 条件生成中 $P(\text{子记录} \mid \text{父记录})$ 表达的含义是？

单选题 · mid

  • A.子表出现的边缘概率
  • B.给定父记录时子记录的生成概率← 正确答案
  • C.父表记录的条件总数
  • D.子表记录的累计分布

答案：B。竖线后面是条件，前面是目标。这个式子回答“当父记录已经存在时，子记录按什么概率生成”,对应货架确定后货箱的摆放规律。边缘概率和累计分布都没有携带父表信息。

Q6. 以下哪些指标可用于评估合成数据的统计保真？

多选题 · hard

  • A.卡方检验统计量← 正确答案
  • B.分布距离度量← 正确答案
  • C.总行数是否一致
  • D.列间相关系数对比← 正确答案

答案：ABD。卡方检验、分布距离和相关系数对比都能量化合成数据与原始数据的差异。总行数一致只说明规模相同，说明不了分布形态和跨表关联是否保留，因此不能只靠它评估保真。

Q7. 大规模生成关联表数据时，推荐采用哪种工程方式？

单选题 · mid

  • A.每行串行生成并同步等待
  • B.并行生成各表后批次修正外键← 正确答案
  • C.随机生成后丢弃全部子表
  • D.每次插入后全表扫描校验

答案：B。并行生成能大幅压缩搬仓时间，批次修正外键又避免了频繁校验的 I/O 开销。串行等待和全表扫描校验在大数据量下都太慢，随机生成后丢弃子表则完全丢失了关系建模目标。

Q8. 父表主键被重编码后，级联更新所做的操作是？

单选题 · easy

  • A.同步修改子表外键为新值← 正确答案
  • B.删除所有子表记录
  • C.保持子表外键旧值不变
  • D.只更新父表的索引

答案：A。级联更新就是货架重新编号后，系统自动把所有货箱标签同步换成新编号。删除子表、保持旧值或只更新索引，都会让外键悬空或引用错误，违背关联一致性。

Q9. 为什么不能直接把原始外键复制到合成数据中？

多选题 · mid

  • A.主键已脱敏需要同步映射← 正确答案
  • B.直接复制会泄露原始关联← 正确答案
  • C.会破坏引用完整性← 正确答案
  • D.复制后查询一定会变慢

答案：ABC。主键脱敏后外键必须跟着映射函数走，否则关联就断了；直接复制原始外键等于把真实关联结构透露给攻击者；父主键变了而外键没变，引用完整性也会被破坏。查询性能与是否复制外键无关。

Q10. 百万级父表主键全量重映射时，更新子表外键最合理的做法是？

单选题 · extreme

  • A.逐行更新且开启长事务
  • B.哈希映射后批量替换← 正确答案
  • C.删除全部外键再重建
  • D.仅在查询时临时关联

答案：B。先建立旧主键→新主键的哈希映射（相当于新旧货架对照表）,再对子表外键批量替换，一次扫描即可完成迁移。逐行更新太慢，删除外键重建会破坏约束，临时关联无法支持写入场景。这和小型示例里 valid_pks 判断是同一思路，只是规模放大。