3. 序列数据库与结构数据库工程

在蛋白结构预测工程中，数据库不是“查资料的地方”，而是整个流水线的输入层与标签层。序列数据库决定“预测什么”，结构数据库决定“用什么监督、用什么评估”。本节围绕 UniProt、PDB、SCOP、CATH 四类核心资源，讲清它们的数据组织方式、检索接口、版本管理策略，以及如何做可复现的批量下载。

一、四类数据库的定位与数据组织

UniProt 是蛋白序列与功能注释的中心库，由 UniProtKB 主体构成，分为两部分：Swiss-Prot 是人工审编、注释质量高、条目数约 57 万量级；TrEMBL 是自动注释、规模达 2.5 亿量级。每条条目以 accession（如 P00533）为稳定标识，entry name 会随物种或功能修订变化，因此工程中应以 accession 作为主键。UniProt 还提供 UniRef 聚类（UniRef100/90/50）与 UniParc 归档，前者用于去冗余建库，后者用于追踪序列历史版本。

PDB 是实验解析的三维结构库，当前条目数约 22 万。其组织单位是 entry（4 字符 ID，如 1TUP），内部包含 chain、residue、atom、ligand、assembly 等层级。PDB 同时提供 mmCIF（推荐）、PDBx/mmJSON、传统 PDB 格式；大分子条目必须用 mmCIF，因为 PDB 格式在原子数与链数上有硬限制。PDB 的元数据包括实验方法（X-RAY、EM、NMR）、分辨率、R-free、链与实体映射等，这些字段是筛选训练集的关键。

SCOP 与 CATH 是结构分类数据库，用于给结构域打层级标签。SCOP 采用 Class → Fold → Superfamily → Family → Protein → Species 层级；CATH 采用 Class → Architecture → Topology → Homologous superfamily 四级。两者都基于结构域划分，但边界与聚类标准不同，因此同一 PDB 链在 SCOP 与 CATH 中可能得到不同域划分。工程中常把 SCOP/CATH 标签作为结构域级监督信号，或用于构建“同源不泄漏”的评估划分。

二、检索：从网页到可编程接口

UniProt 的检索入口有三类：网页端、REST API（rest.uniprot.org）和 FTP 批量文件。REST API 支持按 accession、gene、organism、reviewed 等字段查询，并可用 format=fasta 直接取序列。例如取人 EGFR 的审编序列：

curl -s "https://rest.uniprot.org/uniprotkb/P00533.fasta"
# 批量：按关键词取 reviewed 人类激酶
curl -s "https://rest.uniprot.org/uniprotkb/stream?query=organism_id:9606+AND+reviewed:true+AND+keyword:Kinase&format=fasta" -o human_kinase.fasta

PDB 的检索可用 RCSB 的 Search API 与 Data API。Search API 做条件筛选，Data API 按 entry ID 取 mmCIF。例如筛选分辨率优于 2.0 Å、X-RAY 方法、含单链的条目：

curl -s -X POST "https://search.rcsb.org/rcsbsearch/v2/query" \
  -H "Content-Type: application/json" \
  -d '{"query":{"type":"group","logical_operator":"and","nodes":[
    {"type":"terminal","service":"text","parameters":{"attribute":"rcsb_entry_info.resolution_combined","operator":"less","value":2.0}},
    {"type":"terminal","service":"text","parameters":{"attribute":"exptl.method","operator":"exact_match","value":"X-RAY DIFFRACTION"}}]},
    "return_type":"entry","request_options":{"paginate":{"start":0,"rows":100}}}'

SCOP 与 CATH 的检索通常通过其 FTP 发布的分类文件完成：SCOP 提供 dir.cla.scop.txt、dir.des.scop.txt 等映射文件；CATH 提供 cath-domain-list.txt、cath-b-superfamily-list.txt。工程中更常见的做法是下载这些映射表，在本地用 PDB chain ID 或 UniProt accession 做 join，而不是逐条调用接口。

三、版本管理：release 号与校验和

四类数据库都按 release 发布。UniProt 用 2024_05 这类年月号；PDB 用每周快照，可按日期取 pdb/data/structures/divided/mmCIF/ 下的历史版本；SCOP 用 2.08、CATH 用 v4.3.0。版本管理的核心原则是：任何训练、评估、对比实验都必须记录数据库 release 号与下载日期，否则结果不可复现。

具体做法是维护一份 manifest.tsv，字段包括：资源名、release、下载 URL、文件大小、SHA-256、下载时间。下载后立即计算校验和并与官方发布的校验文件比对。例如 UniProt 的 RELEASE.metalink 内含各文件的 MD5；PDB 的 md5sum 文件按目录发布。若校验不一致，说明传输损坏或版本已滚动，应重新拉取并记录。

四、批量下载的可复现流程

批量下载不是“多跑几条 curl”，而是一条带校验、可重入、可审计的流水线。下面给出一个可参考的示例流程，参数为教学示例，实际使用时按需替换 release 与路径。

1. 锁定版本：在配置文件中写死 UNIPROT_RELEASE=2024_05、PDB_SNAPSHOT=2024-05-01、SCOP_VERSION=2.08、CATH_VERSION=v4.3.0。
2. 拉取清单：UniProt 取 https://ftp.uniprot.org/pub/databases/uniprot/previous_releases/release-2024_05/ 下的 RELEASE.metalink；PDB 取对应日期的 md5sum；SCOP/CATH 取各自 FTP 的 release 说明文件。
3. 下载主体文件：UniProt 取 uniprot_sprot.fasta.gz 与 uniprot_trembl.fasta.gz；PDB 按需取 pdb_seqres.txt.gz 与 mmCIF 分卷；SCOP/CATH 取分类映射表。
4. 校验：对每个文件计算 SHA-256，与清单比对，写入 manifest。
5. 解压与索引：FASTA 用 makeblastdb 或 mmseqs createdb 建索引；mmCIF 用 gemmi 或 Bio.PDB 解析出 chain 级元数据表；SCOP/CATH 映射表导入 SQLite 或 Parquet。
6. 冻结快照：把 manifest、索引、元数据表打包为只读快照，打上 release 标签，后续所有实验引用该标签。

一个常见的坑是：UniProt 的 TrEMBL 文件很大（数十 GB 压缩），全量下载再建索引耗时较长。若任务只涉及已审编序列，可只取 Swiss-Prot；若需要覆盖度，建议用 UniRef50 或 UniRef90 替代 TrEMBL 全量，既降低冗余又减少存储。另一个坑是 PDB 的 mmCIF 分卷目录结构会随 release 调整，脚本中不要硬编码过深的路径，应先用清单文件解析出实际路径。

五、把四类库串成一条工程链路

典型的结构预测工程链路是：从 UniProt 取目标序列（或从 PDB 的 pdb_seqres 取已知结构序列），用 UniRef 去冗余构建训练/验证集；用 PDB 的 entry 元数据筛选高质量结构（分辨率、方法、链长、配体）；用 SCOP/CATH 的域标签做域级划分，确保训练集与测试集在同源层级上不泄漏；最后把 release 号、校验和、筛选条件写入实验配置。这样，从序列到结构、从结构到标签、从标签到评估，每一步都有明确的来源与版本，预测结果才具备可解释性与可复现性。

检索与下载的具体命令会随 API 版本变化，但“锁定 release、校验文件、冻结快照”这三条原则不会变。把这三条固化进脚本与 manifest，数据库工程就从一次性操作变成了可维护的基础设施。