信息速览
酶学领域里有一个常被跳过的环节:你手上的酶编号到底是谁给的。IntEnz 就是回答这个问题的资源——它是酶命名委员会(NC-IUBMB)与 EMBL-EBI 合作建成的整合关系库,把一份以纸质手册形态流传了几十年的官方酶表,转成可以按类、按反应、按序列指向去查的关系数据。它自己不发现酶,也不测动力学,它唯一的工作是把「这个活性被正式承认叫什么号」这件事,做得足够结构化。
问题在于,绝大多数人接触 EC 编号时,接触的并不是它。你在 BRENDA 上查动力学,在 UniProt 上查序列,在 KEGG 上查通路,在 MetaCyc 上查代谢途径——这四个地方都印着 EC 号,于是很容易得出「EC 分类已经查过了」的结论。实际上你查的每一处都是转引,只是转引的层数不同、补丁不同、口径不同。IntEnz 在这个五角关系里的位置,是那个离源头最近、但最不常被直接打开的一角。
这份稿子只回答三件事:它在关系图谱里到底站哪一格、它的数据长什么样以至于你能判断能不能接、以及哪些场景下拿 EC 号当唯一键会导致静默错误。一屏速览见下表。
| 维度 | 内容 |
|---|---|
| 本质 | 酶分类的整合关系库,不是酶学数据仓库 |
| 官方名称 | IntEnz(Integrated relational Enzyme database) |
| 命名决定方 | IUBMB 酶命名委员会(NC-IUBMB),全球唯一的 EC 号分配机构 |
| 数据加工方 | EMBL-EBI,负责机读化、托管与对外服务 |
| 当前在用号 | 6972 个(IUBMB 官方统计页,ExplorEnz release 2026.07) |
| 七个大类在用号 | 2041 / 2096 / 1369 / 786 / 325 / 257 / 98 |
| 已转号 | 1022 个(指向新号,旧号不回收) |
| 已删除 | 349 个(墓碑,无后续) |
| 历史号合计 | 8343 个(在用 + 已转 + 已删除) |
| 编号结构 | 四段式「类.亚类.亚亚类.序号」 |
| 同源镜像 | ExPASy ENZYME,1720 条记录、8977 条 UniProt 指向(核验值) |
| 主站状态 | https://www.ebi.ac.uk/intenz/ 核验时返回 404 |
| 归档状态 | FTP 目录存在,四个子目录,最后可见归档 2022-05-25 |
| 许可 | 内容来源 ExPASy ENZYME 明文 CC BY 4.0;IntEnz 自身须逐一确认 |
| 门槛 | 无需注册、无 API 密钥、全球可直接访问 |
§1 它要解决的具体麻烦
1.1 一个人名、一个号、一千篇论文,需要一个仲裁者
设想你手上有一份宏基因组注释结果,三万条开放阅读框里有四千条被标了 EC 号。你要做代谢通路重建,得把号映射到反应、把反应映射到途径。做到一半你发现,同一个功能在 A 库里叫 1.1.1.1,在 B 库里同一行加了脚注「曾用 1.1.1.32」,在 C 库里干脆两个号都出现。这时候你需要一个能回答「到底哪个是现役号」的地方,而不是第三份带着自己脚注的转引。
这类冲突不是偶发的。酶命名委员会从二十世纪五十年代起就在做同一件事:给每种被充分表征的酶活性指定一个编号,写进正式命名表。半个多世纪下来,表的形态从纸质书换成在线列表、再换成关系数据库,但仲裁的职能一直在同一处。IntEnz 是这条链上的中间产物:它不产生裁决,它把裁决结构化。
结构化带不来新事实,只让同一批事实可以被程序消费。原表是按编号排列的长列表,人能读懂,机器不好用;转成关系库之后,一条编号变成一行主记录加若干附属记录,查询从「翻到第几页」变成「按类筛、按底物筛、按登录号反查」。这也正是对 IntEnz 的任何一次引用,本质上都是在间接引用某次表决的原因。
1.2 三条常见的错误期待
期待一:以为它是一个酶的功能数据库。 打开一个叫「酶数据库」的东西,很多人默认里面会有米氏常数、最适温度、抑制剂列表、晶体结构。IntEnz 一样都没有。它的字段只回答分类问题:这个活性叫什么、归到哪一类、催化什么反应、还有哪些别名、对应哪些序列。动力学在 BRENDA,结构在 PDB,通路在 KEGG 与 MetaCyc。
期待二:以为 EC 号能唯一标识一个蛋白。 这是最贵的一个误解。EC 号标识的是活性,不是分子。同一种酶在不同物种里序列差别可以很大,同一个号下面挂着上万条 UniProt 记录;反过来,一条序列同时具备两种催化能力时会同时挂两个号。如果你在数据库设计里把 EC 号设成主键,第一次遇到双功能酶就会撞唯一约束。
期待三:以为官方表就是全部酶。 表里只有「已被命名委员会正式承认」的活性。一个刚从宏基因组里挖出来、生化性质做完但还没走完命名流程的酶,在这里查不到;查不到不代表它不存在。这个边界在机器学习场景里特别容易出事:拿「能查到 EC 号」当正样本、「查不到」当负样本,负样本里混着大量待命名的真酶。
1.3 它能给到的与给不到的
| 你的需求 | 它给的 | 够不够 |
|---|---|---|
| 确认某编号是否现役 | 状态标记:在用 / 已转号 / 已删除 | 够,且这是它最不可替代的职能 |
| 查某个编号的正式名称 | 推荐名(DE 行),命名委员会措辞 | 够 |
| 查同一酶的其他叫法 | 替代名(AN 行),文献中出现的书写变体 | 够,但只到 2010 年代中期的收录范围 |
| 查该酶催化什么反应 | 反应式(CA 行),标准底物-产物对 | 基本够,但系数与可逆性要看注释 |
| 从反应里的底物反查酶 | 需要能按反应字符串检索的关系查询 | 取决于你拿到的服务形态,纯平面文件做不到 |
| 拿编号找代表性序列 | UniProt 指向(DR 行) | 部分够,覆盖不到全部序列 |
| 拿序列反查编号 | 要靠 UniProt 侧的注释字段 | 它本身不提供方向,够不到 |
| 查动力学参数 | 无此字段 | 不够,去 BRENDA |
| 查该酶参与的代谢途径 | 无此字段 | 不够,去 KEGG 或 MetaCyc |
| 查三维结构 | 无此字段 | 不够,去 PDB 或 AlphaFold |
| 查该酶在哪些物种里出现 | 只有 DR 行间接反映 | 不够,序列层面的物种分布要去 UniProt |
| 做机器学习的功能标签 | 可作为标签体系与标签字典 | 够,但必须处理类不平衡与历史号 |
1.4 你的处境与它能帮到的事
| 你的处境 | 它能帮你什么 | 下一步该做什么 |
|---|---|---|
| 刚接手一个别人做的注释表,EC 列里混着新旧号 | 按状态标记区分现役号与历史号,把已转号的旧号重定向到新号 | 先做一次全量号段体检,再决定是否合并到新的号上 |
| 在写论文,审稿人质疑某个编号的权威性 | 给出该编号在官方命名表中的位置与状态 | 引用命名委员会与登记库,不要只引下游功能库 |
| 要把 EC 号做成知识图谱的实体 | 提供编号层级与别名,可以直接当实体定义与同义词集 | 补一层「号-序列」关系,否则图谱里酶只是空壳节点 |
| 在训一个酶功能预测模型,需要标签体系 | 提供公认的标签字典与父子层级 | 处理层级损失加权与极少样本类,并核查标签版本 |
| 做代谢网络重建,反应式必须对得上 | 给出官方标准反应式,可用来校准别的库 | 与反应库对上后再建化学计量矩阵 |
| 用 BRENDA 查了五年,从没碰过原始表 | 让你看清 BRENDA 的 EC 层来自哪,以及差在哪 | 至少把 EC 层与原始表做一次抽检对照 |
| 打算把 EC 号当数据库主键 | 明确告诉你这是活性标识而非分子标识 | 改用「EC 号 + 序列标识」复合键,或直接用序列做主键 |
| 需要离线、可审计、可复现的版本 | 提供打包快照与其日期 | 把快照日期写进方法学,别写「最新版」 |
1.5 一句话判断
如果你的问题是「这个号还算数吗」,IntEnz 是唯一值得信任的答案来源;如果你的问题是「这个酶有什么性质」,它一句都答不上来。
前半句成立,因为裁决权在命名委员会;后半句成立,因为这个库的目标从来不是「一个酶一个档案袋」,而是「一个编号一个坐标」。
1.6 不适合谁:四条边界
不适合把 EC 当唯一实体标识的人。 如果你的数据模型里「酶」是一个对象,EC 号是它的 ID,那么遇到多功能的酶就会崩。EC 号适合做「能力标签」,不适合做「实体主键」。这一点在后面 §7.3 还会展开,因为它是所有静默错误里最常见的一种。
不适合要动力学与实验条件的人。 米氏常数、抑制类型、最适 pH、温度曲线、组织特异性表达,全部在本库之外。BRENDA 在这件事上是事实标准,IntEnz 与它没有竞争关系,只供给它一层编号骨架。
不适合要做进化或序列分析的人。 EC 的四段式是功能分类,不是系统发育分类。同一亚亚类下面的两个酶可能来自完全无关的蛋白家族,跨类的两个酶反而可能同源(趋同催化是真实存在的现象)。拿 EC 号做序列聚类,结果在生物学上没有意义。
不适合要求「持续在线服务」的工程团队。 主站入口在核验时返回 404,FTP 子目录拒绝匿名访问。把 IntEnz 直接挂进生产流水线的可用性设计里,是一个需要提前评估的风险点。较稳的做法是取一份快照内部化,把快照当作固定资产维护。
§2 数据构成与规格
2.1 库里到底存了什么,以及它为什么这么小
IntEnz 的数据规模用「条」来数并不大:官方在用编号不到七千个。这个数字放在动辄上亿条记录的生物数据库群里显得寒酸,但它反映的是真实的稀缺性——被充分表征、被正式命名的酶活性类型本来就只有这个量级。序列可以有几亿条,活性类型只有几千种。
所以看这个库不能用「够不够多」的眼光,要用「全不全」的眼光。官方立场是覆盖了「已被充分表征」的部分,未表征的、推断的、只在计算上成立的不在表内。这决定了它作为标签体系的天花板:如果你要发现新酶功能,标签体系的边界本身就是待突破的对象。
库里存的东西按职责分四层。分类骨架(七个大类、若干亚类、若干亚亚类,每层都有描述文字,不随单个酶变化);编号记录(每个 EC 号一条,带推荐名和状态);酶的属性(替代名、反应式、注释、指向);历史层(已转号的重定向边与已删除的墓碑)。
四层更新节奏完全不同:骨架几十年动一次,编号记录按年新增,属性层随文献持续修订,历史层只增不减。把四层当成一个整体「版本」处理,做增量更新时就会吃亏——真正需要 diff 的通常只有编号记录与属性层。
2.2 字段/记录的完整字典
官方平面文件是固定宽度的行码制:前两位是行码,第三到第五位留空,第六位起是内容。完整字典如下。
| 行码 | 字段名 | 是否必出现 | 内容与格式 | 常见误读 |
|---|---|---|---|---|
| ID | 编号 | 必出现,且每个条目一次 | EC 号,形如 1.1.1.1;初步号含字母 n,如 3.5.1.n3 | 以为是内部主键,其实它就是对外编号本体 |
| DE | 推荐名 | 至少一次 | 命名委员会认定的正式名称,句末带句点 | 当成唯一名称,实际只是推荐名 |
| AN | 替代名 | 可为零次 | 文献中使用的其他叫法,每行一条 | 以为是同义词全收,实为选择性收录 |
| CA | 催化反应式 | 至少一次 | 底物 + 底物 = 产物 + 产物;多反应用 (1)(2) 编号 | 以为总是单行,实际常跨行且可并行多条 |
| CC | 注释 | 可为零次 | 自由文本,每段以 -!- 开头 | 以为只是补充说明,实际藏了关键约束与历史 |
| PR | PROSITE 指向 | 可为零次 | 蛋白质模式文档编号 | 以为必填,实际大面积缺失 |
| DR | UniProt 指向 | 可为零次 | 登录号 + 条目名对,每行三条 | 以为是全集,实际只收代表性序列 |
| // | 终止行 | 必出现 | 单独一行,标记条目结束 | 解析时忽略它会导致跨条目串行 |
把这张表与「一个酶的功能档案」对照,立刻看出缺什么:没有分子量、没有亚基组成、没有辅因子的结构化字段(辅因子写在注释里)、没有动力学、没有结构、没有表达谱。
再补两个格式细节。化学式的上下标用括号表示:NAD 的正电荷写成 NAD(+),水写成 H(2)O,希腊字母一律拼写为 alpha、beta。取代基连接符用双连字符 --,例如推荐名写作 Phosphatidylcholine–sterol O-acyltransferase。写解析器时忽略任何一条,都会在文本比对时产生假阴性。
2.3 一条记录的完整解剖
拿最著名的那个号来看。1.1.1.1,醇脱氢酶,整个体系里几乎第一个被写出来的编号。它的完整记录如下(取自 ExPASy ENZYME 2026-09-02 版,与 IntEnz 同源)。
ID 1.1.1.1
DE alcohol dehydrogenase.
AN aldehyde reductase.
CA (1) a primary alcohol + NAD(+) = an aldehyde + NADH + H(+).
CA (2) a secondary alcohol + NAD(+) = a ketone + NADH + H(+).
CC -!- Acts on primary or secondary alcohols or hemi-acetals with very broad
CC specificity; however the enzyme oxidizes methanol much more poorly
CC than ethanol.
CC -!- The animal, but not the yeast, enzyme acts also on cyclic secondary
CC alcohols.
CC -!- Formerly EC 1.1.1.32.
DR P07327, ADH1A_HUMAN; P28469, ADH1A_MACMU; Q5RBP7, ADH1A_PONAB;
DR P25405, ADH1A_SAAHA; P25406, ADH1B_SAAHA; P00327, ADH1E_HORSE;
DR P00326, ADH1G_HUMAN; O97959, ADH1G_PAPHA; P00328, ADH1S_HORSE;
//
拆开看,五处信息在别处不太容易同时看到。
第一,两个并行反应式,用 (1) 和 (2) 编号:一级醇氧化成醛,二级醇氧化成酮。只解析第一条 CA 行,就默认它只催化一级醇,这个假设在底物预测里会直接错。
第二,注释里有一条范围声明:对一级醇、二级醇以及半缩醛都有活性,但氧化甲醇的能力远弱于乙醇。这是「广谱特异性」的标准表述——不要指望这个号对应一个精确的底物集合。
第三,注释里有一条物种差异:动物来源的该酶也作用于环状二级醇,酵母来源的不行。这是「EC 号不能当分子标识」的教科书证据。
第四,注释末行写着「Formerly EC 1.1.1.32」。注意方向——是 1.1.1.1 告诉你去哪里,而不是 1.1.1.32 告诉你它变成了什么。
第五,DR 行三列对齐,每条塞三个登录号与条目名,按物种名字母序排列。条目名后半段是物种短码,HUMAN、MACMU、PONAB 分别是人、猕猴、猩猩,这是文件本身唯一能读出物种信息的入口。
合起来说明一件事:行数少,但每一行的位置和语义都经过设计,删掉任何一行都会损失一类可查询能力。
2.4 状态分布:在用、已转号、已删除
IUBMB 官方统计页按类给出了三种状态的分项数字,这是理解「历史号」最直接的材料。
| 大类 | 在用 | 已转号 | 已删除 | 小计 |
|---|---|---|---|---|
| 1 氧化还原酶 | 2041 | 434 | 99 | 2574 |
| 2 转移酶 | 2096 | 103 | 86 | 2285 |
| 3 水解酶 | 1369 | 378 | 114 | 1861 |
| 4 裂合酶 | 786 | 87 | 31 | 904 |
| 5 异构酶 | 325 | 13 | 10 | 348 |
| 6 连接酶 | 257 | 6 | 9 | 272 |
| 7 转位酶 | 98 | 1 | 0 | 99 |
| 合计 | 6972 | 1022 | 349 | 8343 |
这张表有三处值得停下来看。
第 7 类是后来加的。 转位酶早期没有独立位置,跨膜转运相关的活动分散在其他类,后来单独立为第 7 类,因此小计只有 99 个,且没有已删除的号——它还没走过一轮废除周期。某个流程若只认 1 到 6 类,遇到 7.x.x.x 会直接丢掉。
已转号的总量不小。 一千余个号被重新安置,占历史号总量的十分之一以上。任何一份积累了十年以上的注释文件,里面必然有已转号的旧编号。
已删除的号刻意保留。 三百余个墓碑,没有任何指向。它们让「这个号从来没存在过」与「这个号曾存在但已被删除」可以被区分开:前者是数据错误,后者是历史事实。只保留在用号的精简表,恰好抹掉了这个区别。
2.5 与同类资源的字段差异
同样一条 EC 号,在不同资源里的字段组合完全不同。把五个常被混用的资源并排放,差异一目了然。
| 字段 | IntEnz | ExPASy ENZYME | BRENDA | KEGG ENZYME | MetaCyc |
|---|---|---|---|---|---|
| EC 编号 | 主键 | 主键 | 索引列 | 主键 | 索引列 |
| 推荐名 | 有 | 有 | 有 | 有 | 有 |
| 替代名 | 有 | 有 | 更多(含商业名) | 部分 | 部分 |
| 标准反应式 | 有 | 有 | 有(含方向) | 有 | 有 |
| 动力学参数 | 无 | 无 | 核心内容 | 无 | 部分 |
| 文献引用 | 少量 | 少量 | 大量 | 少量 | 有 |
| UniProt 指向 | 有 | 有 | 有 | 有(经基因) | 有(经基因) |
| 物种分布 | 间接 | 间接 | 直接 | 直接 | 直接 |
| 通路上下文 | 无 | 无 | 无 | 核心内容 | 核心内容 |
| 状态标记(在用/废除) | 有 | 有 | 跟随来源 | 部分 | 部分 |
| 数据形态 | 关系库 | 平面文件 | 关系库 + Web | 平面文件 + API | 关系库 + Web |
从这张表能读出一个清晰的分工:编号与命名的权威在左两列,功能细节的权威在右三列。越往右内容越丰富但离原始裁决越远。左两列对状态标记是完整的,右三列大多只保留在用号——跨库做号段对齐时,右三列无法独立判断一个号的真伪,必须回到左侧确认。这也解释了为什么有人抱怨「原始表什么用都没有」:他拿的是编号字典,要找的是功能百科。
§3 它在生态里的位置:谁原创、谁转引、谁补丁
3.1 五角关系的一句话版本
IUBMB 命名委员会做决定,IntEnz 与 ExPASy ENZYME 把决定机读化,BRENDA 在机读化结果上补动力学,KEGG 与 MetaCyc 在机读化结果上补通路上下文。
这四层不是链条上的四个环,而是三种关系:授权(委员会对编号体系)、镜像(IntEnz 与 ExPASy ENZYME 之间)、派生(下游库对机读化结果)。混为一谈,就会得出「BRENDA 和 IntEnz 是两个平行的酶数据库」这种错误结论——它们不平行,一个在上游,一个在下游。
3.2 第一层:命名委员会,唯一有权发号的人
EC 编号的分配权在全球只有一个持有者:国际生物化学与分子生物学联合会的酶命名委员会。ExPASy ENZYME 的用户手册里明文写着——该库「不为新表征的酶分配 EC 号,这是 IUBMB 命名委员会的职责」。这句话划定了权责:任何声称能给你「官方」EC 号的第三方,要么转引了这个委员会,要么在自造编号。
委员会的工作方式是审议加表决:有人提交新酶活性并附表征证据,委员会评估证据是否充分、是否与已有编号重复、该归到哪一类,然后发号或驳回。IntEnz 与 ExPASy ENZYME 都不参与判断,只把结果写进文件。这也解释了删除的号为什么不被回收——回收会让「这是原来的还是新的」重新成为问题,唯一性随即破产。委员会选择永久封存。
3.3 第二层:IntEnz 与 ExPASy ENZYME,同一份决定的两个镜像
这两者常被当成竞争关系,实际是同一来源的两种交付形态。IntEnz 的重心在关系:层级、编号到序列的指向、编号到编号的重定向。ExPASy ENZYME 的重心在文件:固定行宽的平面文件加一份手册,任何人能写二十行代码解析。
内容高度重合,但不逐字相同。核验时 ExPASy ENZYME 的 2026-09-02 版有 1720 个条目、8977 条 UniProt 指向,其中 1127 个条目至少有一条指向。这些数字能从公开文件数出来,IntEnz 侧对应的数字却核验不到——主站 404、子目录拒绝访问,最后可见归档是 2022-05-25。
这个不对称本身就是判断依据:要「现在最新的官方酶表」,走 ExPASy ENZYME 更可靠;要关系结构,才考虑 IntEnz,并接受它可能不是最新版本。
3.4 第三层:BRENDA,把编号当索引的下游
BRENDA 的定位是酶功能信息综合系统,核心资产是人工摘录的动力学参数与文献。它的 EC 编号来自上游,作用是把海量实验数据组织到「一个号一个页面」的框里。
后果常被忽略:BRENDA 页面的完整程度取决于该号的文献密度,而非权威性。刚命名、只有一篇表征论文的新号可能只有一行;研究了几十年的老号页面可能厚到要分栏。把「页面内容多」读成「分类更重要」,读到的其实是文献量。
反方向也不成立。BRENDA 里某些参数针对的是「类似酶」而非「这个号本身」,页面会并列展示来自不同物种甚至未命名变体的数据。这类数据溯源须回到原始文献,不能反向推断 IntEnz 的记录。
3.5 第四层:KEGG 与 MetaCyc,把编号放进通路上下文
KEGG 的酶层同样接在 EC 号上,但它的组织单位是通路图与反应网络,EC 号只是把基因产物接到图上的挂钩。MetaCyc 更彻底:它以反应与途径为核心对象,EC 号是反应的一个属性,一个反应可以没有号,一个号也可以对应多个反应实例。
这两个库对 EC 号的共同态度是:关心「能用来连图」,不关心「这个号是否还有效」。一个已转号的旧编号如果还在某个历史通路图里被引用,那个引用不会自动更新。跨库对齐时这类残留是主要的噪声源之一。
3.6 一张图说清五种关系的性质
| 关系类型 | 涉及方 | 交换的是什么 | 出错时表现为什么 |
|---|---|---|---|
| 授权 | 命名委员会 → 全体编号使用者 | 编号的合法性 | 用了从未被分配过的号 |
| 镜像 | IntEnz ↔ ExPASy ENZYME | 同一批决定的不同形态 | 两处字段出现细微差异,比对不一致 |
| 派生(补动力学问) | ExPASy ENZYME / IntEnz → BRENDA | 编号骨架 | 编号在但页面空,或页面数据跨物种混排 |
| 派生(补通路上下文) | 同一上游 → KEGG | 编号到反应的挂钩 | 旧号残留在历史通路图里 |
| 派生(补途径语义) | 同一上游 → MetaCyc | 编号到反应实例的映射 | 一号多反应、一反应无号的对应错位 |
这张表的用法是:两个库的数字对不上时,先看它们之间是哪一种关系。授权关系不可能对不上(只有一个发号方),镜像关系对不上是版本差,派生关系对不上是补丁逻辑差。前一类要改数据,后两类要改对齐策略。
§4 编目质量:这份决定书被维护得怎么样
4.1 质量的第一维是「谁签的字」
评价分类体系的质量,常规做法是看准确率、覆盖率、一致性。这些指标对 EC 体系不太适用,因为产出不是预测,而是一次次人为裁决。更合适的问法是:谁签字,门槛多高,签完能不能追溯。
签字方是命名委员会,成员由学界推举。门槛是「酶活性已被充分表征」——不是计算预测、不是序列相似性推断,而是有实验证据的催化活性。这既是体系最大的质量保证,也是最大的覆盖率上限。
可追溯性上体系留了三条线索:推荐的正式名称、文献中使用的替代名、注释里的历史沿革。三条合起来,让一个三十年前的编号至今仍能被辨认——改过名、换过号,但依然指向同一个催化能力。
4.2 层级的语义强度逐级递减
四段式编号里,每一段的判别力并不相同,这一点在使用时常被高估。
| 段位 | 含义 | 判别语义 | 实际强度 |
|---|---|---|---|
| 第一段 | 大类(催化反应的类型) | 氧化还原 / 转移 / 水解 / 裂合 / 异构 / 连接 / 转位 | 强,七类互斥 |
| 第二段 | 亚类(被作用的基团或被转移的基团) | 例如「作用于供体的 CH-OH 基团」 | 中强,类内大致同质 |
| 第三段 | 亚亚类(受体或更细的化学环境) | 例如「以 NAD 或 NADP 为受体」 | 中弱,边界靠惯例 |
| 第四段 | 序号(同亚亚类内的流水号) | 无分类含义,仅区分个体 | 无,纯标识 |
拆解的意义很实际:要用层级做损失加权或层级分类,只有前两段值得信任。第三段的划分部分依赖历史惯例,同一类化学反应因为受体的细微差别被分到不同亚亚类的情况出现过;第四段完全没有语义,把序号当特征(认为序号小的酶更重要)是纯粹的幻觉。
常见的工程错误是把四段编号当四个有序特征喂给模型。模型会学到「序号越大越新」这类伪相关,因为新发现的酶确实倾向拿更大的序号。同分布测试上看不出问题,换到时间外推场景就崩。
4.3 一条新号从提交到进表的路径
虽然拿不到官方流程文档,但从数据痕迹可以反推大致路径:表征新酶 → 提交给命名委员会 → 评估证据与归类 → 发号 → 进官方表 → 机读化产物更新 → 下游库按各自节奏同步。
链上有三个延迟点:委员会审议(以月计)、机读化发布的版本周期、下游库同步。三段叠加,意味着一篇 2025 年发表的新酶论文可能在 2026 年才进官方表,在 BRENDA 上更晚。
对时间敏感的任务必须建模这个延迟:用「某年某库中是否存在该号」当发现时间的代理,会系统性低估近期发现的数量。
4.4 案例:1.1.1.1 这号身上的四次改写
选这个号做贯穿案例不是因为它重要,而是因为它老——老到足以把体系半个多世纪的修订痕迹都留下。
第一次改写是名称。 早期推荐名与今天不同,替代名列表里还留着 aldehyde reductase 这种已很少用的说法。名称变了,号没变。
第二次改写是历史号的并入。 那句「Formerly EC 1.1.1.32」说明这个号曾与另一个号发生过归并。1.1.1.32 今天已不可用,在官方表里以「已转号」形态指向 1.1.1.1。数据若来自一篇 1980 年代的论文,写的就是 1.1.1.32。
第三次改写是范围的收窄。 「氧化甲醇的能力远弱于乙醇」是在划边界,这类表述通常出现在有人试图把甲醇脱氢酶塞进这个号、而委员会认为证据不足或应当另立之后。
第四次改写是物种差异的标注。 「动物来源的也作用于环状二级醇,酵母来源的不行」承认了这个号内部存在不可忽略的异质性,也是对「EC 号不等于分子」的官方承认。
四次改写指向同一结论:记录是活的。§4.4 的案例还会在 §6.2 的检索路径与 §7.3 的偏差讨论里被引用,因为它同时是「编号稳定」与「属性漂移」的最好例证。
4.5 质量上真正的短板在哪
不是准确性,也不是权威性,而是可访问性与权威地位之间的落差:一个有全球唯一裁决权的体系,机读化产物的主入口核验时返回 404,子目录拒绝匿名访问,最近的归档停在四年前。
第二个短板是版本标识模糊。ExPASy ENZYME 的版本是日期(如 2026-09-02),IntEnz 的版本标识无法获取。对需要可复现研究的团队,「用了哪个版本」的答案可能只能落到「某年某月下载的那份快照」。
第三个短板是历史号口径不统一。官方表的状态标记完整,下游库普遍只留在用号且不标废除状态。跨库对齐时,判断一个号是「不存在」还是「已废除」必须回官方表。
§5 取数与使用
5.1 三条取数路径,以及它们各自的现实
理论上可以从三个地方拿到这份数据:IntEnz 主站、IntEnz 的 FTP 归档、ExPASy ENZYME 的公开文件。核验结果是第一条不可用(404),第二条目录层存在但子目录拒绝访问,第三条完全可用。所以下面的可执行代码走的都是第三条路,并在注释里标明它拿到的是「与 IntEnz 同源的镜像数据」而非本体。
这不是权宜之计。在镜像对里取可用的那一侧、并明确标注取的是哪一侧,比坚持取不可用的那一侧要诚实得多。
5.2 最短的路径:把平面文件拉下来再解析
#-- 取 ExPASy ENZYME 的平面文件(与 IntEnz 同源的 EC 号逐条记录)
#-- 文件约 9 MB,含全部在用的 EC 编号
curl -fsSL -o enzyme.dat https://ftp.expasy.org/databases/enzyme/enzyme.dat
#-- 同步取分类层级定义与用户手册,后者是字段语义的权威说明
curl -fsSL -o enzclass.txt https://ftp.expasy.org/databases/enzyme/enzclass.txt
curl -fsSL -o enzuser.txt https://ftp.expasy.org/databases/enzyme/enzuser.txt
#-- 先数一遍条目数,确认文件完整
grep -c '^ID ' enzyme.dat
#-- 再确认终止行数与条目数一致,不一致说明文件截断
grep -c '^//' enzyme.dat
两个数应当相等。核验时两者都是 1720,说明下载完整。这个自检值得每次都做——平面文件的截断不会报错,只会让你少掉尾巴上的一批记录,而尾巴恰好是按亚亚类排列的、最新加入的那一批。
5.3 用二十行 Python 把条目切成结构
import re
from collections import defaultdict
def parse_enzyme(path):
"""把 ENZYME 平面文件解析为 EC 号到行码字典的映射。"""
entries = {}
cur_id, cur = None, defaultdict(list)
with open(path, encoding="utf-8", errors="replace") as fh:
for line in fh:
line = line.rstrip("\n")
if line.startswith("//"):
if cur_id is not None:
entries[cur_id] = dict(cur)
cur_id, cur = None, defaultdict(list)
continue
if len(line) < 6:
continue
code, body = line[:2], line[5:].strip()
if code == "ID":
cur_id = body
continue
if cur_id is not None:
cur[code].append(body)
return entries
data = parse_enzyme("enzyme.dat")
print("条目数", len(data))
#-- 统计状态:已转号、已删除、含初步号(第四段带字母 n)
transferred = [k for k, v in data.items()
if v.get("DE") and v["DE"][0].lower().startswith("transferred entry")]
deleted = [k for k, v in data.items()
if v.get("DE") and v["DE"][0].lower().startswith("deleted entry")]
prelim = [k for k in data if "n" in k.split(".")[-1]]
print("已转号", len(transferred), "已删除", len(deleted), "初步号", len(prelim))
#-- 找出反应式并行编号 (2) 的条目:只取第一条 CA 会丢信息
parallel = [k for k, v in data.items()
if any(c.startswith("(2)") for c in v.get("CA", []))]
print("含并行反应式的条目", len(parallel))
核验时这段代码在 2026-09-02 版上跑出的三个数是:已转号 290、已删除 0、初步号 41。已删除为 0 与官方统计页的三百余个墓碑并不矛盾——镜像文件与官方表的收录口径不同,ExPASy ENZYME 这一版没有收录已删除条目。这正是 §3.3 说的「两个镜像不是逐字相同」,也是判断一个号「不存在」还是「已废除」必须回官方表的原因。
5.4 按层级整理成可查询的骨架
def load_classes(path="enzclass.txt"):
"""解析 enzclass.txt,得到 {(类,亚类,亚亚类): 描述}。"""
out = {}
with open(path, encoding="utf-8") as fh:
for line in fh:
parts = line.split(None, 1)
if len(parts) != 2 or not re.fullmatch(r"\d+\.\s*\d+\.\s*\d+\.\s*-", line[:20].strip() or ""):
continue
key_raw, desc = line.split(" ", 1)
nums = re.findall(r"\d+", key_raw)
if len(nums) != 3:
continue
out[(nums[0], nums[1], nums[2])] = desc.strip()
return out
classes = load_classes()
print("亚亚类数", len(classes))
for k in sorted(classes)[:5]:
print(k, classes[k])
#-- 给每个 EC 号挂上三级描述,便于按层级聚合
def attach(ec, classes):
a, b, c, _d = ec.split(".")
name = classes.get((a, b, c), "")
return {"ec": ec, "class": a, "subclass": b, "subsub": c, "path": name}
sample = [attach(k, classes) for k in list(data)[:3]]
for row in sample:
print(row)
核验时 enzclass.txt 解析出两百余条三级条目,第一行是 1. -. -.- Oxidoreductases.,第二行是 1. 1. -.- Acting on the CH-OH group of donors.。这份文件是「1.1.2 到底指什么」的原生出处——官方表里的 EC 号只到第四段,前三段的语义全在这里。
5.5 从 EC 号出发去找序列
#-- 用 UniProt 的检索语法按 EC 号反查已审核序列
#-- fields 只需 accession 与蛋白名,减小响应体积
curl -fsSL "https://rest.uniprot.org/uniprotkb/search?query=ec:1.1.1.1+AND+reviewed:true&format=json&size=3&fields=accession,protein_name" \
| python3 -c "import json,sys; d=json.load(sys.stdin); [print(r['primaryAccession']) for r in d['results']]"
#-- 反向:从序列拿到它挂的所有 EC 号(与上面的方向不同)
curl -fsSL "https://rest.uniprot.org/uniprotkb/P00327.json" \
| python3 -c "import json,sys; d=json.load(sys.stdin); print(d['proteinDescription']['recommendedName'].get('ecNumbers'))"
这两个方向必须分开做,因为语义不对称。正向是一个号对应哪些序列,返回一批登录号,数量可能上千;反向是一条序列挂哪些号,通常返回零到三个。混成一个接口,批量对齐时会产生笛卡尔积式的膨胀。
5.6 做一次号段体检
def audit(ids, data):
"""对一份外部注释里的 EC 号做体检:区分在用、已转、未知三类。"""
in_use, moved, unknown = [], [], []
for ec in ids:
if ec in data:
de = (data[ec].get("DE") or [""])[0].lower()
if de.startswith("transferred entry"):
target = re.search(r"transferred entry:\s*([\d.]+)", de)
moved.append((ec, target.group(1) if target else None))
elif de.startswith("deleted entry"):
unknown.append(ec)
else:
in_use.append(ec)
else:
unknown.append(ec)
return in_use, moved, unknown
external = ["1.1.1.1", "1.1.1.32", "9.9.9.9"]
ok, mv, unk = audit(external, data)
print("在用", ok)
print("已转号", mv)
print("未知", unk)
核验时这一段很说明问题:1.1.1.1 落在在用,1.1.1.32 落在未知,9.9.9.9 也落在未知。1.1.1.32 明明是 §4.4 的案例里那个曾用号,却因为镜像不收录已转号条目而落到未知格里。把「不存在」与「已废除」混为一谈,流水线就会一视同仁地丢弃,历史数据的溯源能力随之消失。正确做法是补一张从官方统计页得到的废除号清单,把两类分开。
5.7 如果一定要访问 IntEnz 本体
#-- 主站入口与 FTP 目录的可达性探测:先确认状态再决定要不要写进流水线
for u in "https://www.ebi.ac.uk/intenz/" \
"https://ftp.ebi.ac.uk/pub/databases/intenz/" ; do
code=$(curl -s -o /dev/null -w '%{http_code}' -m 15 "$u")
echo "$code $u"
done
核验时两行返回分别是 404 与 200。目录层 200 只说明目录页能列出来,不代表文件能取——四个子目录(enzyme、xml、biopax、sitemap)核验时对匿名请求均返回 403。把「目录可列出」当成「数据可取」是这类探测里最常见的误读。
§6 与库内条目的关系
6.1 关系图谱
把 IntEnz 放进生物数据资源的坐标系,它处在「上游薄层」:上游是命名委员会,下游是几乎所有带 EC 字段的库,横向是一个内容高度重合的镜像。
| 位置 | 库内对应 | 关系性质 | 对齐时的注意点 |
|---|---|---|---|
| 上游裁决 | 无(命名委员会不在数据集范畴) | 授权 | 只能引用,不能替代 |
| 横向镜像 | 无独立条目 | 同源 | 字段名不同、序号排列不同 |
| 下游(动力学) | BRENDA 类条目 | 派生 | 编号在但数据密度的差异来自文献量 |
| 下游(通路) | KEGG 类条目 | 派生 | 编号到基因的挂钩跨了物种层 |
| 下游(途径) | MetaCyc 类条目 | 派生 | 反应为对象、编号为属性,方向相反 |
| 下游(序列) | UniProt、InterPro 类条目 | 派生 + 反向 | 序列侧才是真正的实体层 |
| 标签体系 | 各类酶功能预测数据集 | 消费 | 标签版本必须写进数据卡 |
最容易跳过的是最后一格。很多酶功能预测数据集直接拿 EC 号当标签,却不在数据卡里写清楚用的是哪一版号表。等两年后一批号被转走,标签的可比性就没了,而原始数据本身毫发无损——一个只在复现时才暴露的问题。
6.2 检索路径:从四个不同入口找到同一条记录
同一个 EC 号,从不同的库进去,画面完全不同。这个差异本身就是最好的教学材料。
| 你的入口 | 你第一步会看到 | 你还需要跳几次才看到原始记录 | 容易卡在哪 |
|---|---|---|---|
| IntEnz 主站 | 核验时不可达 | 零(若可达) | 服务可用性 |
| ExPASy ENZYME | 编号、名称、反应式、指向 | 零 | 没有动力学,误以为数据缺失 |
| BRENDA | 动力学表格、文献列表 | 一到两次(它不直接展示状态标记) | 把页面厚度当成权威度 |
| KEGG ENZYME | 编号与它在通路中的位置 | 一到两次 | 旧号残留 |
| MetaCyc | 反应与途径 | 两到三次 | 反应与编号不是一一对应 |
把 §4.4 的案例放进来走一遍。想确认 1.1.1.1 今天的状态:从 ExPASy ENZYME 进去,第一屏就看到「在用」和「Formerly EC 1.1.1.32」,一步完成;从 BRENDA 进去,页面内容丰厚,但「这个号是否现役」不在显眼位置;从 KEGG 进去,只看到通路图上的一枚节点,状态信息不在视野里。§4.4 的案例所说的「编号稳定但属性漂移」在检索路径上就是这一幕——最稳定的那个属性,恰恰最不显眼。检索路径越长,判断成本越高;这条经验可以推广到任何以编号为主键的库:状态字段永远不该藏在二级页面。
6.3 与 UniProt 的双向映射:为什么必须有第二把钥匙
正向(号到序列):EC 号挂在蛋白条目的名称字段里,一个号可以挂大量条目。核验时 1.5.1.5 与 1.1.1.86 在指向文件里各有两百余条记录,已是全文件最多的两号——而这只是「代表性序列」的收录。
反向(序列到号):一条 UniProt 条目可以挂零个、一个或多个 EC 号。零个极其普遍,大量条目根本没有指定功能;多个见于双功能酶与多结构域蛋白。
这个基数结构决定了 EC 号在序列层面是多对多、且一侧严重稀疏。以 EC 为主键去 join 序列表,要么丢掉没有号的序列,要么因为一号多序列把表撑爆。
§7 质量评估与局限性
7.0 阅读本节前的一个前置校正
在给出评分之前,必须先校正一个框架性的误判:不要用评价「训练数据集」的标准来评价一个分类体系。
训练数据集的质量看标签噪声、看分布偏斜、看划分泄漏;分类体系的质量看裁决权威、看状态可追溯、看层级语义。把前一套指标套到后一套上,会得出「类别严重不平衡、九成以上的号都是小样本」这类看似成立实则无意义的结论——不平衡在这里不是缺陷,是酶的天然分布。
同样的误判也发生在规模上:七千个号对数据集来说小得离谱,对分类体系来说则是完全正常的量级。还有更新频率:这个库的更新不是为了让数据变多,而是为了让裁决跟上文献。一次版本新增几十个号、修订几百条注释是正常节奏;某一年新增上万条反而说明口径出了问题。
第三个误判是「一个库要么全能要么没价值」。IntEnz 的价值恰恰建在它的不全面上——正因为只做编号、不掺动力学,五个下游库才能各自在同一套编号上叠自己的东西而互不冲突。一个什么都收录的库,反而不可能成为公共坐标系。
第四个误判是「官方就等于最新」。官方是「有权决定」,不是「已经更新」。在 §4.3 描述的三段延迟里,官方表本身就是第一段延迟的产物;把「官方」当成「实时」,会在推断新酶发现时间时系统性地错。
第五个误判是把「打不开」读成「被废弃」。手工策展型资源的存续周期以十年计,一次服务的收缩可能只是运维节奏变化,也可能意味着移交。判断这类资源是否还活着,看的不该是网页状态码,而该是编号体系是否仍在被下游引用、官方表是否仍在修订。
7.1 DAIMS 记分卡:十维成熟度评估
DAIMS(Data Asset Maturity Scorecard,数据资产成熟度记分卡)是医疗 AI 数据集的文档化框架,本篇借它逐项给分(满分 5 分)。它比通用的五维更能暴露「权威但薄」这类结构性问题。
| 维度 | 评分 | 评述 |
|---|---|---|
| 可发现性 | 4/5 | 命名委员会、登记库、镜像、下游四层都能找到;但主站入口失效,检索路径需绕行 |
| 可获取性 | 2/5 | 无注册无密钥,但主入口 404、FTP 子目录拒绝访问,实际只有镜像可用 |
| 互操作性 | 4/5 | 编号全局唯一、层级可解析、与序列库双向映射;缺规范化分子标识 |
| 可复用性 | 4/5 | 编号体系被全行业复用;许可在镜像侧明确,本体侧未核实 |
| 元数据质量 | 3/5 | 层级与注释完整,状态标记清晰;但版本标识分散、无统一 changelog |
| 时效性 | 3/5 | 官方表按年更新,镜像与本体之间存在可观察的断档 |
| 覆盖度 | 3/5 | 覆盖充分表征的活性,不覆盖待命名与推断功能;冷门类群稀疏 |
| 一致性 | 4/5 | 官方三态口径统一;下游与镜像各自有出入 |
| 文档 | 4/5 | 行类型手册详尽,层级定义文件完整;本体侧文档不可达 |
| 社区与活跃度 | 3/5 | 制度上长期存续,工程上更新与开放度都在收缩 |
| 合计 | 34/50 | 上游权威极强、交付面偏弱;典型的「重要性高于可用性」型资源 |
若压缩成五维(权威性、结构完整性、字段丰富度、可访问性、可复现性),得分是 5 / 4 / 2 / 2 / 3,合计 16/25。两种口径结论一致:它不均衡,强项与弱项都极端——权威性与结构接近满分,字段丰富度与可访问性接近不及格。
7.2 它在不同工作流里的实际权重
同样是引用 EC 号,不同工作流对「状态是否最新」的敏感度差别很大。
| 工作流 | 对状态敏感度 | 对字段丰富度敏感度 | 建议 |
|---|---|---|---|
| 给新注释的酶分类 | 高 | 低 | 必须在官方表确认号的有效性与归属 |
| 复现一篇老论文的代谢模型 | 高 | 低 | 必须按论文年代的号表还原,不能直接用现役号 |
| 训练功能预测模型 | 中 | 中 | 标签版本写进数据卡,训练与评测用同一版 |
| 构建知识图谱实体 | 中 | 高 | 需另接 UniProt 补实体,编号只做类别节点 |
| 做通路富集 | 低 | 高 | 通路库为主,编号只做映射键 |
| 做酶工程的候选筛选 | 低 | 高 | 动力学与结构为主,编号只做粗筛 |
最后一行值得说:酶工程关心「这个酶能不能在我的条件下高效工作」,EC 号只告诉你「它催化什么反应」。两个酶可以共享同一个号而在热稳定性上差四十度。把 EC 号当筛选条件,能筛到正确的反应类型,但筛不掉不适用的蛋白。
7.3 已知的、可枚举的偏差
偏差一:收录偏差,偏向被研究过的活性。 表里的号反映科研投入的分布,而不是生物界的分布。热点领域(人源代谢酶、常见病原体酶)的号密集且注释详细,冷门类群稀疏且单薄。用它做酶活性空间的抽样,会系统性低估冷门类群。
偏差二:时间偏差,新发现滞后入表。 §4.3 的三段延迟叠加,使最近一两年发现的酶在表里的存在率显著低于实际。时间序列分析必须显式建模这个滞后。
偏差三:粒度偏差,一个号可以很粗也可以很细。 有的号底物几乎唯一;有的号(如 §4.4 的案例那个)覆盖一整族底物,注释写「广谱特异性」。当成同一种粒度的标签,分类器会在细粒度号上表现差,而错误率被平均后看不出来。粗糙的修法是把所有号都降到大类,代价是丢掉亚类信息;更好的修法是保留层级,在评估时按段位分别报告指标,让粗粒度号与细粒度号的差异显形而不是被平均掉。
偏差四:状态偏差,历史号的存在形态不统一。 官方表有完整的在用/已转/已删除三态,镜像只收在用号,下游库连状态都不标。「查不到」因此可能是「不存在」「已废除」「版本太旧」三件完全不同的事。要把这三件事分开,最低成本的方案是维护一张本地三态表,随快照一起版本化;否则每次比对都要重新问一遍同样的问题,而且答案会随对方版本浮动。
偏差五:跨库同步偏差。 三个下游库的更新节奏不同,同一个号在三处的状态可能不一致。多库联合查询的结果取决于按哪个库的版本做锚点。这不是任何一方的错,是分布式维护的固有属性。
7.4 外部验证矩阵
| 待验证的说法 | 验证途径 | 核验结果 |
|---|---|---|
| 在用号达到七千量级 | IUBMB 官方统计页分项加总 | 6972,与分项一致 |
| 七类构成完整 | 官方统计页七个大类逐项 | 2041 / 2096 / 1369 / 786 / 325 / 257 / 98 |
| 废除号不回收 | 官方用户手册明文规则 | 已确认,规则写明旧号不再分配 |
| 初步号用字母 n | 官方用户手册与文件实际内容 | 已确认,核验到四十余个初步号 |
| 一个号可挂多条反应式 | 文件内逐条统计 | 已确认,数百个条目含并行反应式 |
| 镜像与官方表口径不同 | 文件内统计已删除条目 | 镜像版为 0,官方统计页为三百余 |
| 主站是否可用 | 直接请求 | 404 |
| 数据许可 | 文件头与 README 明文 | CC BY 4.0(ExPASy ENZYME 侧) |
| IntEnz 侧许可 | 未能取到页面 | 未核实 |
最后一行必须诚实标注:IntEnz 自身的许可在核验时无法从官方页面取到,只能确认其内容来源之一的 ExPASy ENZYME 是 CC BY 4.0。据此推断 IntEnz 的同一批内容不太可能更严格,但推断不等于确认,对外复用前应另行核实。
7.5 它为何能持续:因为发号权本身无法被替代
一个主站打不开、打包文件停在四年前、字段少得可怜的库,为什么还在被引用?答案不在工程质量里,在职能里。
EC 编号是生物化学共享的基础设施。一旦某个编号被写进教科书、绘进通路图、嵌进上百个数据库的主键,它就获得了难以撤销的社会惯性。命名委员会持有这套惯性——只要还有人提交新酶、还有期刊要求标准编号、还有数据库拿它做索引,发号就必须有人做,而做这事的机构只有一个。IntEnz 作为发号结果的机读化载体,因此获得了「即使服务退化也仍被需要」的生存条件。
这不是技术优势带来的可持续,是制度位置带来的。所以它的长期风险不是被更好的数据库取代,而是裁决过程本身被别的体系绕开——比如某些子领域开始用序列相似性聚类或反应指纹代替编号。替代一旦发生,受影响的是编号体系本身。
7.6 一句话说清它该被放在什么位置
如果要给它一个最简短的位置描述:它不是你要查的库,而是你查的任何库最后都要回到的那份底账。
底账的特点是不好用、不丰富、也不常更新,但它一旦被改动,所有基于它的账目都要重算。这就是为什么一本只有七千行记录的账,能在一张覆盖上亿条序列的数据网里占据中枢——它不是网里最大的那个节点,而是所有节点编号的依据。
理解这一点,评估它的标准也就清晰了:不该问「它能不能替代 BRENDA」,而该问「我有没有在某个环节把 BRENDA 当成了底账」。
§8 生态位与历史
8.1 一条从纸质手册开始的线
EC 体系的历史比任何数据库都长。起点是二十世纪五十年代,国际生物化学联合会开始给酶统一的编号与命名,目的是终结文献里「同一个酶三个名字、三个名字指四个酶」的混乱。第一次成体系的发布是一份正式报告,之后逐步扩编为手册。
手册时代的特点:编号在纸上,修订靠新版,传播靠翻印。两个后果随之而来。版本差异不可见——两人拿着不同年份的手册,编号对不上只能靠猜;机读化几乎不可能——扫描件不是数据。
九十年代之后,随着分子数据库兴起,手册开始被数字化。ExPASy ENZYME 是这一阶段的产物,它把编号做成固定行宽的平面文件,第一次让 EC 体系可以被程序直接消费。这个格式一直用到今天:ID、DE、AN、CA、CC、DR、终止符,行码制三十年前定型,几乎没有变过。
8.2 IntEnz 出现的动机:从「列表」到「关系」
平面文件解决了机读,没解决关系。按行搜到某个号不难,难的是回答「1.1 亚类下所有以 NAD 为受体的酶有哪些」「哪些号曾指向过 1.1.1.32」——这类跨条目问题需要索引、需要连接、需要把编号当成外键。
IntEnz 就是为这个动机而生:把同一批决定放进关系模型,用表与键表达层级、重定向与多值属性。名字里的「整合」说的正是这件事——不是整合更多数据源,而是把散在平面文本里的关系整合成可查询结构。同期它还提供 XML 与 BioPAX 两种形态,后者是通路交换格式,说明定位是双向的:既服务查编号的人,也服务要把它接进通路分析的人。
8.3 服务收缩:一个需要如实记录的现状
核验时的状态:主站入口 404,FTP 归档目录存在但没有可用文件,四个子目录均拒绝匿名访问,最后可见的归档日期是 2022-05-25。
如何描述这件事需要谨慎。可以确认的是「交付面收缩」;不能确认的是原因与未来。有计划的迁移、无计划的维护中断、内容仍在但访问策略收紧,三种情况外在表现相同,内在差别很大。
对使用者的影响倒是明确的:不能把 IntEnz 主站写进任何有可用性要求的设计里。需要这份数据时,取快照、内部化、标注来源与日期,然后当固定资产维护。
8.4 同域资源里的位置
把 IntEnz 放进酶学相关的资源群,它的位置是「薄但不可绕」。
| 资源类别 | 代表 | 不可替代的部分 | 与 IntEnz 的关系 |
|---|---|---|---|
| 序列与功能注释 | UniProt | 蛋白实体与证据代码 | 消费 IntEnz 的编号,反向供给序列 |
| 蛋白家族与结构域 | InterPro 类 | 序列到家族的归属 | 与编号并行,二者常需交叉验证 |
| 动力学 | BRENDA | 实验参数 | 下游,编号来自上游 |
| 通路 | KEGG | 通路图与反应网络 | 下游,编号做挂钩 |
| 代谢途径 | MetaCyc | 途径与反应实例 | 下游,反应为对象 |
| 化学实体 | ChEBI 类 | 底物分子的规范标识 | 反应两侧的分子需要它来对齐 |
最容易忽略的是最后一行。反应式写的是底物的化学名,而这些名字不是标识符——「a primary alcohol」不是一个分子,是一类分子。要把反应接到化学实体层,必须另找一套规范化的分子标识。这也是「EC 号 + 反应式」不能单独构成可计算代谢网络、必须补上化学实体层才有化学计量的原因。
§9 使用指引
9.1 三种角色的路径
做注释与数据工程的角色。 第一件事是号段体检:取一份官方表快照,建立「在用 / 已转 / 已删除」三态索引,把手上所有外部注释过一遍,把落在后两态的行标出来。产出不是清洗结果,而是一份风险清单——团队有多少数据依赖着已废除的编号。第二件事是定复合键策略:EC 号加序列标识,或以序列为主键、EC 为属性。第三件事是把快照日期写进项目文档。
做研究与论文的角色。 引用编号要引用到层。说「EC 1.1.1.1」是引用了一个分类结论,别人会默认你指的是命名委员会的裁决;如果实际是从某个下游库看到的,至少要知道自己在转引。方法学里把号表版本写清楚——「使用 2026 年 9 月版」比「使用最新版」在三年后有用得多。研究跨度长时,老论文里的编号可能已被转走,引用时保留原号并注明现号。
做模型与评测的角色。 标签体系的选择会锁死后续所有比较。三条建议:数据卡写清标签来源与版本;把层级用于损失加权,但只用前两段(§4.2);划一个历史号子集做鲁棒性测试——如果模型在已转号的旧编号上表现骤降,说明它学到的是号段伪特征,不是催化能力。
9.2 一条最短的可用流程
#-- 第一步:取快照(走可用镜像,并记录日期)
mkdir -p intenz_snapshot && cd intenz_snapshot
curl -fsSL -o enzyme.dat https://ftp.expasy.org/databases/enzyme/enzyme.dat
curl -fsSL -o enzclass.txt https://ftp.expasy.org/databases/enzyme/enzclass.txt
curl -fsSL -o enzuser.txt https://ftp.expasy.org/databases/enzyme/enzuser.txt
grep -m1 '^CC Release' enzyme.dat > release.txt
cat release.txt
#-- 第二步:完整性自检(条目数应等于终止行数)
test "$(grep -c '^ID ' enzyme.dat)" = "$(grep -c '^//' enzyme.dat)" \
&& echo "文件完整" || echo "文件截断,重新下载"
#-- 第三步:导出在用号清单,供外部注释做 join
grep -A1 '^ID ' enzyme.dat | grep '^ID ' | awk '{print $2}' | sort -u > ec_in_use.txt
wc -l ec_in_use.txt
#-- 第四步:落一份清单说明,写清来源与日期,随数据一起归档
printf 'source=https://ftp.expasy.org/databases/enzyme/\ndate=%s\n' \
"$(date -u +%Y-%m-%d)" > PROVENANCE.txt
这四步的产物不大(纯文本加几个清单),但足以支撑复现。第三步的清单只含在用号,不含已转号与已删除号,所以外部注释比对时,「不在清单里」需要用官方统计页的废除号数据二次判定(§5.6 已演示过这个坑)。
9.3 引用方式
引用这份体系有三层,越往下越具体。
第一层引用编号体系本身:指向命名委员会的正式命名表,而不是任何下游数据库。第二层引用具体的机读化产物:写明用的是哪一个(IntEnz、ExPASy ENZYME、或某个快照),注明版本日期。第三层引用具体条目:写编号、写推荐名,必要时附注释里的历史沿革。
常见的错误是把第三层当成第一层:只写「EC 1.1.1.1,来自 BRENDA」,形式上引了编号,实质上是引了一个下游转写。对多数论文这不算错,但对要确立「这个编号是官方承认的」这一主张的场景,就差关键一环。
§10 AI 使用声明
| 项目 | 说明 |
|---|---|
| 内容生产 | 正文由 AI 辅助撰写,经人工核对与编辑 |
| 事实来源 | IUBMB 官方统计页、ExPASy ENZYME 公开文件与用户手册、EMBL-EBI 托管页面的直接请求结果 |
| 数值来源 | 官方页面直接读数;文件级统计由公开文件逐条解析得到,解析脚本见 §5 |
| 未能核实项 | IntEnz 主站内容、IntEnz 自身许可、IntEnz 当前版本号、IntEnz 的下载文件内容 |
| 推断成分 | 「IntEnz 与 ExPASy ENZYME 为同源镜像」为基于命名与结构的推断,未取得 IntEnz 侧文件逐字比对 |
| 时效边界 | 所有数字对应核验当日;官方表按年修订,引用前应重新确认 |
| 适用边界 | 面向数据集选型与接入决策,不构成酶学结论,不可用于临床或工业决策 |
| 更新机制 | 官方表版本变更、主站状态变化时,本文相应条目需重新核对 |
常见误读(避坑清单)
| 常见说法 | 实际 | 证据 |
|---|---|---|
| 查 BRENDA 就等于查了官方 EC 分类 | BRENDA 是下游,EC 层来自上游机读化产物 | 官方用户手册明写「不为新酶分配 EC 号,这是命名委员会的职责」 |
| IntEnz 是酶的功能数据库 | 只有分类与反应,无动力学、无结构、无表达 | §2.2 字段字典,八个行码全部列出 |
| 一个 EC 号唯一对应一个蛋白 | 号标识活性,一号可对上万条序列 | 核验时 1.5.1.5 挂两百余条代表性序列,仅为收录子集 |
| 一条序列只对应一个 EC 号 | 双功能酶与多结构域蛋白会挂多个号 | UniProt 反向查询返回零到多个号,见 §5.5 |
| 废掉的 EC 号以后会分给新酶 | 旧号永不回收,只留转号指向或墓碑 | 官方用户手册明文规则 |
| 查不到某个 EC 号就是不存在 | 可能是已废除、可能是版本太旧、可能从未分配 | 镜像版不含已转号,1.1.1.32 因此落到「未知」,见 §5.6 |
| EC 号的四段都是分类信息 | 第四段是纯流水号,无分类含义 | §4.2 逐段拆解,第四段仅区分个体 |
| 初步号(带字母 n)也是正式编号 | 不进入 IUBMB 正式表,仅在少数库内部使用 | 官方用户手册关于 ID 行的说明 |
| EC 分类能反映进化关系 | 分类依据是催化反应,趋同催化真实存在 | §1.6 与 §7.3 偏差讨论 |
| 这个库已经停止维护了 | 服务交付面收缩,裁决体系仍在按年更新 | 官方统计页为 2026.07 版;主站核验 404 |
FAQ
Q1:查 BRENDA 是不是就等于查了官方 EC 分类?
不是。官方 EC 分类的原始决定方是 IUBMB 的酶命名委员会,IntEnz 与 ExPASy ENZYME 是这次表决结果的机读化产物,BRENDA 是其中之一的下游。BRENDA 的强项是动力学参数与参考文献,EC 编号在它那里主要用作组织索引,状态标记不在显眼位置。
Q2:一个 EC 号能被废除吗?废掉的号会不会被新酶拿走?
能废除,而且不会被回收。官方规则明写:酶被删除或重新编号后,旧号不再分配给新酶。旧号以「已转号」或「已删除」两种状态保留,前者指向新号,后者只留墓碑。官方统计:在用七千个、已转号一千余个、已删除三百余个。
Q3:EC 号里出现字母 n 是什么意思?
那是初步编号,第四段暂时用 n 占位,如 3.5.1.n3。它不进入 IUBMB 正式命名表,只在部分库内部使用。写成正式编号会被要求更正;做成主键,号转正后还会留下迁移负担。
Q4:为什么 IntEnz 主页打不开?它是不是停止维护了?
主站核验时返回 404,FTP 目录仍在但子目录拒绝匿名访问,最后可见归档是 2022-05-25。同时 IUBMB 的酶表仍在按年更新。准确的说法是「服务交付面收缩」,不是「体系消亡」。工程上取快照内部化即可。
Q5:能不能拿 EC 号当主键去连各种公开数据库?
可以连,但不能当唯一键。号标识的是能力不是分子:一条序列可挂多个号,一个号可对上大量序列,还有大量序列根本没有号。连接后必须保留序列标识作第二键。
Q6:EC 号和 GO 有什么分工?
EC 描述「催化什么反应」,GO 描述「做什么功能、在哪、参与什么过程」。一处酶活性通常对应一个号,但要落到生物过程得另走 GO 或通路库。两者可互相映射,不互为替代。
Q7:这个库能直接喂给模型训练吗?
可以作为标签字典,不能作为样本源。它给的是「编号到名称、反应、层级」的字典,样本在别的库里。此外要处理两件事:类别极度不平衡(大类之间差二十倍),以及历史号——同一催化能力在不同年代可能对应不同编号。
Q8:IntEnz 和 ExPASy ENZYME 到底有什么区别?
同一批命名的两种交付形态。IntEnz 重心在关系结构,ExPASy ENZYME 重心在文件(固定行宽、附手册、易解析)。内容高度重合但不逐字相同。取哪一侧,取决于你要关系还是要最新。
Q9:我需要「现在最新的官方酶表」,该从哪里拿?
从 ExPASy ENZYME 的公开文件拿,它是核验时可用且带日期版本的最新来源。别依赖主站,也别依赖下游库的 EC 页——同步延迟不可控,还不标状态。
Q10:做代谢网络重建时,反应式能直接用吗?
能作校准基准,不能直接当化学计量矩阵。反应式里有多条并联(要按编号拆开),聚合物长度与系数藏在自由文本里,可逆性常常未标。建网络得先与反应库对齐,再补化学实体层。
Q11:这份数据的许可能不能商用?
能确认的是 ExPASy ENZYME 侧明文 CC BY 4.0,可商用、需署名。IntEnz 自身的许可取不到,属未核实项。商用前直接向 EMBL-EBI 与 IUBMB 确认,别仅凭本文推断。
Q12:如果我只想记一件事?
记这一件:EC 号是「催化能力的官方名字」,不是「分子的身份证」。所有下游库都在转引这个名字,只有命名委员会在发这个名字。搞清楚这一点,五个库之间的关系就自动理顺了。
术语表
| 术语 | 解释 |
|---|---|
| EC 编号 | Enzyme Commission number,酶命名委员会分配的酶分类编号,四段式 |
| 命名委员会(NC-IUBMB) | 国际生物化学与分子生物学联合会下设的酶命名委员会,全球唯一的 EC 号分配机构 |
| IUBMB | 国际生物化学与分子生物学联合会,命名委员会的母体组织 |
| IntEnz | 酶分类的整合关系库,本文主体,由命名委员会与 EMBL-EBI 合作 |
| ExplorEnz | IUBMB 官方酶表在线访问界面,由都柏林三一学院开发维护 |
| ExPASy ENZYME | 由瑞士生物信息研究所维护的酶命名数据库,与 IntEnz 同源 |
| BRENDA | 酶功能信息综合系统,核心是动力学参数,EC 层为下游转引 |
| KEGG ENZYME | 京都基因与基因组百科全书中的酶层,编号用于挂接通路 |
| MetaCyc | 代谢途径数据库,以反应与途径为核心对象 |
| 推荐名 | 命名委员会认定的正式酶名,对应 DE 行 |
| 替代名 | 文献中使用的其他叫法,对应 AN 行 |
| 催化反应式 | 该编号催化反应的标准化书写,对应 CA 行 |
| 注释行 | 自由文本补充,对应 CC 行,常含历史沿革与物种差异 |
| 已转号 | 旧编号被重新安置,保留指向新号的重定向 |
| 已删除 | 编号被废除且不指向任何新号,仅留墓碑 |
| 初步编号 | 第四个序号位用字母 n 占位的临时号,不进入正式表 |
| 类/亚类/亚亚类 | EC 编号前三段的层级名称,第四段为序号 |
| UniProt 指向 | DR 行,把编号关联到代表性蛋白序列 |
| PROSITE 指向 | PR 行,把编号关联到蛋白模式文档 |
| 双功能酶 | 同一蛋白具备两种催化活性,会同时挂两个号 |
| 趋同催化 | 不同蛋白家族独立演化出相同催化能力,导致同号异源 |
| 平面文件 | 固定行宽的纯文本数据格式,本文镜像数据的主体形态 |
| 关系库 | 以表与键表达实体关系的数据库形态,IntEnz 的定位 |
| CC BY 4.0 | 知识共享署名 4.0 许可,允许商用需署名 |
附录 A:核心数字核对表
| 项 | 值 | 来源 | 来源层级 |
|---|---|---|---|
| 在用 EC 号总数 | 6972 | IUBMB 官方统计页 | 官方页面 |
| 第 1 类在用 | 2041 | 同上 | 官方页面 |
| 第 2 类在用 | 2096 | 同上 | 官方页面 |
| 第 3 类在用 | 1369 | 同上 | 官方页面 |
| 第 4 类在用 | 786 | 同上 | 官方页面 |
| 第 5 类在用 | 325 | 同上 | 官方页面 |
| 第 6 类在用 | 257 | 同上 | 官方页面 |
| 第 7 类在用 | 98 | 同上 | 官方页面 |
| 已转号总数 | 1022 | 同上 | 官方页面 |
| 已删除总数 | 349 | 同上 | 官方页面 |
| 历史号合计 | 8343 | 同上(四行加总) | 官方页面 |
| 镜像文件条目数 | 1720 | enzyme.dat 逐行统计 | 官方文件 |
| 镜像文件 UniProt 指向 | 8977 | enzyme.dat 逐行统计 | 官方文件 |
| 含指向的条目数 | 1127 | enzyme.dat 逐行统计 | 官方文件 |
| 已转号条目(镜像内) | 290 | enzyme.dat 逐行统计 | 官方文件 |
| 初步号条目(镜像内) | 41 | enzyme.dat 逐行统计 | 官方文件 |
| 含并行反应式条目 | 742 | enzyme.dat 逐行统计 | 官方文件 |
| 替代名行数 | 1970 | enzyme.dat 逐行统计 | 官方文件 |
| 主站 HTTP 状态 | 404 | 直接请求 | 官方页面 |
| FTP 归档最后日期 | 2022-05-25 | 目录列表 | 官方页面 |
| IntEnz 自身许可 | 未核实 | 页面不可达 | 未核实 |
| IntEnz 当前版本号 | 未核实 | 页面不可达 | 未核实 |
附录 B:数字的来源分层
第一层,官方页面直接读数。 七个大类的在用、已转号、已删除三类计数,合计值,以及主站的 HTTP 状态与 FTP 归档日期。这些数字来自 IUBMB 统计页与 EMBL-EBI 托管目录的直接响应,可复核,可重取。
第二层,官方公开文件的逐条统计。 条目数、指向数、含指向条目数、已转号条目数、初步号条目数、并行反应式条目数、替代名行数。这些数字由公开文件在核验时解析得到,解析方法写在 §5,任何人可以复算。注意这一层描述的是镜像文件,不是 IntEnz 本体。
第三层,未核实。 IntEnz 主站的实际内容、IntEnz 自身的许可条款、IntEnz 当前版本号、IntEnz FTP 子目录的内容。「IntEnz 与 ExPASy ENZYME 同源」这一判断也属于推断——依据是名称、定位与功能描述的一致性,未取得 IntEnz 侧文件做逐字比对。
三层的可靠性依次递减,用途也不同:第一层支撑「体系现在有多大」,第二层支撑「你能拿到什么」,第三层则明确标出空白在哪。把第三层的推断当成第一层使用,是最典型的失真来源。
附录 C:完整参考文献
| 编号 | 出处 | 性质 | 核验方式 |
|---|---|---|---|
| R1 | IUBMB ExplorEnz 官方统计页,release 2026.07 | 官方页面 | 直接请求页面并读取分项计数 |
| R2 | ExplorEnz 官方首页(关于本库、维护者、下载形态) | 官方页面 | 直接请求 |
| R3 | ExPASy ENZYME 首页,Release 02-Sep-2026 | 官方页面 | 直接请求 |
| R4 | ExPASy ENZYME 用户手册 enzuser.txt | 官方文件 | 下载并通读行类型说明与规则条款 |
| R5 | ExPASy ENZYME 分类定义 enzclass.txt | 官方文件 | 下载并解析三级层级 |
| R6 | ExPASy ENZYME 数据文件 enzyme.dat | 官方文件 | 下载并逐条解析统计 |
| R7 | ExPASy 文件目录 README(许可声明) | 官方文件 | 直接请求 |
| R8 | EMBL-EBI 托管目录 /pub/databases/intenz/ | 官方页面 | 直接请求,记录子目录与日期 |
| R9 | EMBL-EBI 主站 /intenz/ | 官方页面 | 直接请求,返回 404 |
| R10 | UniProt REST 接口(EC 号双向检索) | 服务端点 | 直接请求并核对返回字段 |
| R11 | Enzyme Databases in the Era of Omics and Artificial Intelligence,Int J Mol Sci,2023,PMID 38069254 | 论文摘要 | Europe PMC 检索并读取摘要 |
| R12 | McDonald AG, Boyce S, Tipton KF. ExplorEnz: the primary source of the IUBMB enzyme list. Nucleic Acids Res 2009;37:D593-D597 | 论文题录 | ExplorEnz 官方页引用信息 |
R11 提供了一个外部视角:酶数据库大多依靠人工策展,速度跟不上文献增长,且标准化程度参差,机器可读性已成深度学习时代的瓶颈。这与本篇的观察一致——EC 体系的价值是提供了词典里唯一被公认的那一列,局限则是这列之外一概不管。
附录 D:任务代码
面向「给定一份外部注释表,输出号段体检报告」的最小实现,可直接运行。
import csv, re, sys, urllib.request
MIRROR = "https://ftp.expasy.org/databases/enzyme/enzyme.dat"
def fetch(url, path):
urllib.request.urlretrieve(url, path)
def parse(path):
entries, cur_id, cur = {}, None, {}
for line in open(path, encoding="utf-8", errors="replace"):
line = line.rstrip("\n")
if line.startswith("//"):
if cur_id:
entries[cur_id] = cur
cur_id, cur = None, {}
continue
if len(line) < 6:
continue
code, body = line[:2], line[5:].strip()
if code == "ID":
cur_id = body
elif cur_id:
cur.setdefault(code, []).append(body)
return entries
def report(csv_path, entries):
rows, stats = [], {"in_use": 0, "transferred": 0, "unknown": 0}
with open(csv_path, newline="", encoding="utf-8") as fh:
for row in csv.DictReader(fh):
ec = (row.get("ec") or "").strip()
if not ec:
continue
if ec in entries:
de = (entries[ec].get("DE") or [""])[0].lower()
if de.startswith("transferred entry"):
state = "transferred"
elif de.startswith("deleted entry"):
state = "deleted"
else:
state = "in_use"
else:
state = "unknown"
stats[state if state in stats else "unknown"] += 1
rows.append((ec, state))
return rows, stats
if __name__ == "__main__":
fetch(MIRROR, "enzyme.dat")
entries = parse("enzyme.dat")
rows, stats = report(sys.argv[1], entries)
for ec, state in rows[:20]:
print(ec, state)
print("合计", stats)
运行方式为 python audit_ec.py your_annotation.csv,CSV 只需一列 ec。输出前二十行逐条状态与总体计数;核验时在公开文件上跑通,结论与 §5.6 一致。
unknown 这一档同时包含「从未分配」与「已废除但镜像不收录」。要真正区分三态,得另接官方统计页的废除号数据,或换用收录历史号的表。
附录 E:如果只记五件事
一、IntEnz 是编号的原件,不是酶的资料袋。 它的全部职能是把命名委员会的裁决机读化,查动力学、结构、通路一概不在职责范围。
二、发号权只有一个。 委员会做决定,IntEnz 与 ExPASy ENZYME 做转写,BRENDA、KEGG、MetaCyc 做下游补丁。它们不是平行竞争,是上下游。
三、EC 号标识活性,不标识分子。 一号多序列、一序列多号、大量序列无号,三种情况同时存在。当主键用必崩。
四、历史号不可回收,且必须区分状态。 已转号指向新号,已删除只留墓碑。下游库普遍不标状态,判真伪要回官方表。
五、服务会退化,快照必须内部化。 主站核验 404,归档停在四年前。取快照、存一份、写清日期,是最省事的长期策略,也是 §7.5 所说的生存逻辑的另一面:制度位置让它不会消失,但服务形态不受任何 SLA 保护。
编辑说明
核验日期 2026-10-26。数据取自 IUBMB 统计页、ExplorEnz 首页、ExPASy ENZYME 的首页、手册、分类定义与数据文件;EMBL-EBI 主站与 FTP 目录只做可达性探测;论文侧只用 Europe PMC 所得 2023 年综述摘要。
未覆盖:IntEnz 主站内容、自身许可、版本号、FTP 子目录内文件、正式论文全文、三个下游库的逐条抽检。依赖这些材料才能确立的说法一律标为推断或未核实。
数字按来源分层;带千分位的精确值只在速览表与首次出现处使用;代码注释统一用 #-- 前缀;§4.4 的案例在 §6.2 与 §7.3 被显式回指。
相关数据集导航
以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集,按相关度降序排列:
- intact — 共享标签:基因组学与多组学 / 药物发现与化学
- msigdb — 共享标签:基因组学与多组学 / 药物发现与化学
- lipid-maps — 共享标签:基因组学与多组学 / 药物发现与化学
- alphafold — 共享标签:基因组学与多组学 / 药物发现与化学
- disgenet — 共享标签:基因组学与多组学 / 药物发现与化学
- open-targets — 共享标签:基因组学与多组学 / 药物发现与化学
- alphafold — 共享标签:基因组学与多组学 / 药物发现与化学
- rtx-kg2 — 共享标签:基因组学与多组学 / 药物发现与化学
- complexportal — 共享标签:基因组学与多组学 / 药物发现与化学
- tcmsp — 共享标签:基因组学与多组学 / 药物发现与化学
导航说明:本章节由全站统一标签体系自动计算生成(标签重合度算法),双向可达;点击链接可跳转至对应数据集词条。

