蛋白质数据库（ PDB.org ）是有关生物分子（主要是蛋白质）的结构数据的全球档案。 蛋白质数据库（PDB）由多个成员组织管理，这些组织负责存放，维护，加工和免费提供此生物学数据给科学界。 为了提供灵活性，可扩展性和数据交换便利性，PDB数据以XML格式提供。 此XML格式由称为蛋白质数据库标记语言（ PDBML ）的XML模式定义。

结构信息包括蛋白质所组成的分子原子的3-D坐标。 这些原子坐标也称为3-D结构或三级结构。 蛋白质的三级结构与其功能紧密相关。 因此，了解三级结构通常有助于理解蛋白质的内在功能。 例如，三级结构可用于解释疾病或开发新药。 也可以利用三级结构搜索PDB中蛋白质之间的相互作用。

挑战

截至2010年12月，Protein Data Bank存储库拥有70,000个条目（XML文档），其中包含超过5亿个原子坐标。 未压缩的总大小超过750 GB。 PDB中的单个XML文档的大小从几MB到1 GB以上。 基于近年来PDB存储库的快速增长（ 图1 ），PDB的规模预计将继续大幅增加。 因此，搜索和分析此信息变得越来越具有挑战性。

图1. PDB在过去20年中的增长

分析PDB数据的一种典型方法是编写一个自定义应用程序或一组脚本，以针对非常具体的研究问题搜索PDBML文档。 这种方法的缺点包括以下事实：

• 每次进行新研究时都要开发自定义代码，这是非常费力且费时的。
• 性能通常很差，因为所有文档都需要解析和搜索，即使其中只有一部分包含相关信息也是如此。
• 通常很难重用或合并现有的自定义代码以针对PDB数据编写新的或不同的查询。

选择具有pureXML的DB2 V9.7.3来解决这些挑战，主要是因为DB2具有处理预期数量的PDBML文档所需的可伸缩性和XML功能。 此外，可以通过IBM Academic Initiative免费提供DB2，用于非商业用途。 目的是将PDB信息存储在有效的数据库模式中，利用关系索引和XML索引进行有效的搜索，并使用XQuery和SQL / XML对PDB信息甚至表达复杂的查询。

蛋白质数据库的内容

在讨论用于PDB的DB2数据库设计之前，先了解一点PDB数据是有帮助的。

蛋白质的三级结构主要通过称为X射线衍射或X射线晶体学的方法通过实验确定（ 解决 ） 。 另一种不常用的方法称为溶液NMR（核磁共振）或NMR光谱。 确定（求解）蛋白质结构的方法导致在生成的XML文档中描述蛋白质结构的方式有所不同，这尤其体现在XML文件大小中。

蛋白质是动态分子，这意味着它们的三级结构可能会略有变化，例如，取决于其环境。 由于这些变化，NMR有条不紊地确定了代表同一蛋白质三级结构略微移位的多个实例（模型）。 因此，带有通过NMR产生的蛋白质数据的XML文件的大小可能非常大，例如100 MB到1 GB或更大。 此外，您还将在本文后面看到如何以及为何使用DB2范围分区将蛋白质的第一个（ 默认 ）模型与其变异模型分开。

清单1显示了一个PDBML文档的摘录。 您可以看到在该文档中可以出现的177种信息类别中的四种，包括研究的作者和所使用的实验方法（ <PDBx:exptlCategory> ）。 属性entry_id代表此文档的唯一PDB标识符。

清单1.样本PDBML文档的摘录（1BBZ.xml）

...
<PDBx:audit_authorCategory><PDBx:audit_author pdbx_ordinal="1"><PDBx:name>Pisabarro, M.T.</PDBx:name></PDBx:audit_author>...
</PDBx:audit_authorCategory>
...
<PDBx:structCategory><PDBx:struct entry_id="1BBZ"><PDBx:pdbx_descriptor>ABL TYROSINE KINASE, PEPTIDE P41</PDBx:pdbx_descriptor><PDBx:title>CRYSTAL STRUCTURE OF THE ABL-SH3 DOMAIN COMPLEXED WITHA DESIGNED HIGH-AFFINITY PEPTIDE LIGAND: IMPLICATIONS FORSH3-LIGAND INTERACTIONS</PDBx:title></PDBx:struct>
</PDBx:structCategory>
...
<PDBx:struct_keywordsCategory><PDBx:struct_keywords entry_id="1BBZ"><PDBx:pdbx_keywords>COMPLEX(TRANSFERASE/PEPTIDE)</PDBx:pdbx_keywords><PDBx:text>COMPLEX (TRANSFERASE-PEPTIDE), SIGNAL TRANSDUCTION,SH3 DOMAIN, COMPLEX (TRANSFERASE-PEPTIDE) complex</PDBx:text></PDBx:struct_keywords>
</PDBx:struct_keywordsCategory>
...
<PDBx:exptlCategory><PDBx:exptl entry_id="1BBZ" method="X-RAY DIFFRACTION"><PDBx:crystals_number>1</PDBx:crystals_number></PDBx:exptl>
</PDBx:exptlCategory>
...

测试数据库

由于时间和资源的限制，我们决定仅使用全部可用PDB数据量的一个子集来原型化和评估DB2数据库中PDBML文档的存储，索引和查询。 因此，选择了6029个文档的代表性样本，这些样本总计83 GB，约占截至2010年12月PDBML存档总容量的10％。这组文档包含大约17亿个XML元素，其中大约有22个XML元素。 15.4亿个元素通过原子坐标和其他信息描述了三级蛋白质结构。

PDBML文档的代表性样本必须准确反映具有X射线衍射产生的分子信息的文档的比例（较小的文档，占所有文档的83％）与Solution NMR（较大的文档，占所有文档的16％）。 这样可以确保通过实际混合大小文档来测试数据库配置和查询。

可用于此研究的数据库服务器是具有八个双核处理器（AMD Opteron 8220）和256GB主内存的Sun X4600 M2。 操作系统是Ubuntu 64位Linux®。 该存储由10个硬盘驱动器（每个698 GB； 7,200 rpm）组成，使用硬件控制器将其组织为单个逻辑卷（RAID 5）。

针对PDB的数据库设计建议

本节介绍了一组数据库设计建议，这些建议可为存储和分析PDB数据提供简单有效的数据库支持。 这些建议涉及数据库架构，在XML和关系存储之间进行选择，索引的定义以及具有分区和集群选项的物理数据组织。

混合XML /关系存储

当前，PDBML文档包含多达177种信息类别，其中大多数是可选的。 大量的可选PDBML元素使文档非常灵活且高度可变。 完全关系数据库模式将需要数百个表来表示PDBML。 PDB的这种关系数据库模式是在2005年开发的， 如图2所示。 拥有400多个表和3,000多个列，此架构的复杂性令人难以置信。 很难理解和查询这种数据库模式，因为单个PDB条目被分解并散布在数百个表中，这使用户很难知道哪些信息驻留在哪个表中。 因此，将大多数PDBML信息保持其原始XML格式并将其存储在单个XML列中会导致数据库设计更加简单，并以用户自然理解的格式保留数据。

图2. PDBML的完全关系数据库模式图

PDBML数据的高可变性的一个显着例外是原子坐标及其相关标记，它们遵循针对分子中每个原子重复的平坦且规则的结构，如清单2所示 。 由于蛋白质通常由成千上万个原子组成，因此原子坐标通常代表PDBML文档的90％或更多。

清单2. PDBML文档中的Atom坐标

<PDBx:atom_siteCategory><PDBx:atom_site id="1"><PDBx:B_iso_or_equiv>37.41</PDBx:B_iso_or_equiv><PDBx:Cartn_x>1.039</PDBx:Cartn_x><PDBx:Cartn_y>16.834</PDBx:Cartn_y><PDBx:Cartn_z>18.876</PDBx:Cartn_z><PDBx:auth_asym_id>A</PDBx:auth_asym_id><PDBx:auth_atom_id>N</PDBx:auth_atom_id><PDBx:auth_comp_id>ASN</PDBx:auth_comp_id><PDBx:auth_seq_id>1</PDBx:auth_seq_id><PDBx:group_PDB>ATOM</PDBx:group_PDB><PDBx:label_alt_id xsi:nil="true" /><PDBx:label_asym_id>A</PDBx:label_asym_id><PDBx:label_atom_id>N</PDBx:label_atom_id><PDBx:label_comp_id>ASN</PDBx:label_comp_id><PDBx:label_entity_id>1</PDBx:label_entity_id><PDBx:label_seq_id>1</PDBx:label_seq_id><PDBx:occupancy>1.00</PDBx:occupancy><PDBx:pdbx_PDB_model_num>1</PDBx:pdbx_PDB_model_num><PDBx:type_symbol>N</PDBx:type_symbol></PDBx:atom_site><PDBx:atom_site id="2"><PDBx:B_iso_or_equiv>36.15</PDBx:B_iso_or_equiv><PDBx:Cartn_x>-0.213</PDBx:Cartn_x><PDBx:Cartn_y>16.205</PDBx:Cartn_y><PDBx:Cartn_z>18.364</PDBx:Cartn_z>...</PDBx:atom_site><PDBx:atom_site id="3"><PDBx:B_iso_or_equiv>33.97</PDBx:B_iso_or_equiv><PDBx:Cartn_x>-0.549</PDBx:Cartn_x><PDBx:Cartn_y>16.779</PDBx:Cartn_y><PDBx:Cartn_z>16.986</PDBx:Cartn_z>...</PDBx:atom_site>...
</PDBx:atom_siteCategory>

原子信息的平坦且规则的结构非常适合传统的关系表。 实际上，原子坐标和标签是非分层数据，因此XML并不是最佳选择。 因此，我们决定使用一种混合数据库模式，该模式将atom_site信息存储在关系表中，并将每个PDBML文档的其余部分存储在XML列中，但是从文档中删除了<atom_siteCategory> 。 这有几个优点：

• 精简的PDBML文档要小得多，从而提高了插入和加载性能以及XML查询性能。 插入或加载时的XML解析工作量减少了大约90％。
• 关系列中的原子信息所占用的空间少于其详细XML表示形式中的空间。
• 可以使用传统的关系方法来查询原子数据，对于非分层数据，该方法比XML导航更为有效。
• 由于每个原子都在单独的行中表示，因此索引可以帮助加快对给定PDBML条目内特定原子的搜索。

所选的数据库模式由两个表组成，如清单3所示。 对于每个PDB条目，第一个（ xmlrpdb.pdbxml ）都有一行。 该表只有两列：

• 主键pdb_id包含XML属性entry_id的四个字符的PDB条目标识符。
• XML列pdbxml_file保存除<atom_siteCategory>之外的整个PDBML文档。

第二个表（ xmlrpdb.atom_site ）为每个原子坐标（即，对于PDBML文档中的每个<atom_site>元素）包含一个关系行。 pdb_id列是将原子坐标链接到pdbxml表中相应PDBML文档的外键。

两个表都存储在页空间为32 KB的表空间中，以最大化读取大量行的性能分析查询。

清单3. DB2中用于PDB的混合XML /关系数据库模式

CREATE TABLE xmlrpdb.pdbxml (pdb_id             CHAR(4) NOT NULL,pdbxml_file        XML NOT NULL,PRIMARY KEY (PDB_ID))
IN ts_data32k INDEX IN ts_index32k;CREATE TABLE xmlrpdb.atom_site (pdb_id                CHAR(4) NOT NULL,atom_site_id          INTEGER NOT NULL,auth_asym_id          VARCHAR(10) WITH DEFAULT NULL,auth_atom_id          VARCHAR(20) NOT NULL,auth_comp_id          VARCHAR(3) NOT NULL,auth_seq_id           VARCHAR(20) NOT NULL,b_iso_or_equiv        DECIMAL(7,3) NOT NULL,b_iso_or_equiv_esd    DECIMAL(7,3) WITH DEFAULT NULL,cartn_x               DECIMAL(7,3) NOT NULL,cartn_x_esd           DECIMAL(7,3) WITH DEFAULT NULL,cartn_y               DECIMAL(7,3) NOT NULL,cartn_y_esd           DECIMAL(7,3) WITH DEFAULT NULL,cartn_z               DECIMAL(7,3) NOT NULL,cartn_z_esd           DECIMAL(7,3) WITH DEFAULT NULL,group_pdb             VARCHAR(10) NOT NULL,label_alt_id          VARCHAR(10) WITH DEFAULT NULL,label_asym_id         VARCHAR(10) WITH DEFAULT NULL,label_atom_id         VARCHAR(20) WITH DEFAULT NULL,label_comp_id      VARCHAR(10) NOT NULL,label_entity_id       SMALLINT NOT NULL,label_seq_id          SMALLINT WITH DEFAULT NULL,occupancy             DECIMAL(7,3) NOT NULL,occupancy_esd         DECIMAL(7,3) WITH DEFAULT NULL,pdbx_pdb_atom_name    VARCHAR(10) WITH DEFAULT NULL,pdbx_pdb_ins_code     VARCHAR(10) WITH DEFAULT NULL,pdbx_PDB_model_num SMALLINT NOT NULL,type_symbol           VARCHAR(10) WITH DEFAULT NULL,PRIMARY KEY (pdb_id, atom_site_id),FOREIGN KEY (pdb_id) REFERENCES xmlrpdb.pdbxml(pdb_id),CONSTRAINT group_chk CHECK (group_PDB in ('ATOM', 'HETATM'))
) IN ts_atom_data_32k INDEX IN ts_atom_index32k;

（可选）可以在pdbxml表上定义CHECK约束，以确保四字符PDB标识符符合PDB标准。 第一个字符必须是1到9之间的数字，接下来的三个字符必须是0到9之间的数字或A和Z之间的大写字符（请参见清单4 ）。

清单4. CHECK约束以强制使用适当的pdb_id值

ALTER TABLE xmlrpdb.pdbxmlADD CHECK (SUBSTR(pdb_id, 1, 1) BETWEEN '1' AND '9')ADD CHECK ((SUBSTR(pdb_id, 2, 1) BETWEEN '0' AND '9') OR(SUBSTR(pdb_id, 2, 1) BETWEEN 'A' AND 'Z'))ADD CHECK ((SUBSTR(pdb_id, 3, 1) BETWEEN '0' AND '9') OR(SUBSTR(pdb_id, 3, 1) BETWEEN 'A' AND 'Z'))ADD CHECK ((SUBSTR(pdb_id, 4, 1) BETWEEN '0' AND '9') OR(SUBSTR(pdb_id, 4, 1) BETWEEN 'A' AND 'Z'));

填充混合数据库架构

将PDBML文档插入我们的混合数据库模式的概念过程如图3所示 。 需要从XML文档中提取和删除<atom_siteCategory>数据，并将其插入到相关的atom_site表中（蓝色）。 精简文档本身将插入到pdbxml表中。 我们称此过程为原子位点分离。

图3.分离了atom_site数据的PDBML文档的混合存储

由于数据量大，原子站点分离（混合数据库架构的填充）需要具有高性能。 因此，应尽可能减少昂贵的XML解析。 再看一下清单2中XML格式的原子坐标，我们发现94.5％的字符是标记，而只有5.5％的字符是实际值。 因此，标记与值的比率非常高，这意味着可能需要大量XML解析才能提取相对少量的可用数据。 您很快就会了解这种考虑如何影响了我们如何填充两个表的决定。

填充关系atom_site表的一种选择是使用带有XMLTABLE函数的INSERT语句。 这样的语句可以解析整个PDBML文档并提取原子信息以作为关系行插入。 此外，XQuery Update表达式可以从插入到pdbxml表中的每个PDBML文档中删除<atom_siteCategory>子树。 这样的XQuery Update表达式也可以成为INSERT语句的一部分，以便在将<atom_siteCategory>写入XML列之前将其删除，而不是在插入之后执行单独的步骤。

另一种选择是在数据库外部使用专用预处理器，将原子数据提取到关系平面文件中，并将其从每个PDBML文档中删除。 这样的预处理器是用C ++实现的，它具有以下优点：

• 它可以向数据添加所需的注释，例如来自序列和结构比对的信息或依赖于应用程序的几何变换（例如原子坐标的旋转或平移）。
• 它可以在不使用通用XML解析器的情况下实现。 而是针对PDBML文档的特定文件结构进行了设计和优化。 它利用了有关原子数据的平面结构，元素之间是否存在换行符以及其他特征的特殊知识。 结果，专用预处理器比任何使用XML解析的解决方案至少快10倍。

预处理6029个压缩后的PDBML文档的数据集（即解压缩后的83 GB）并将准备好的数据加载到pdbxml表和atom_site表中仅花费了1小时44分钟。 可以下载预处理器（请参阅下载 ）。

压缩

考虑到PDB归档中的数据量及其快速增长，在DB2中压缩数据很有用。 这减少了存储消耗并提高了性能。 尽管DB2中的压缩和解压缩消耗了一些额外的CPU周期，但是压缩还减少了从磁盘读取一定数量的数据所需的物理I / O操作数。 此外，DB2表空间的压缩页在主内存中的DB2缓冲池中保持压缩状态。 结果，与未压缩相比，压缩允许在内存中存储更多数据，这增加了缓冲池命中率，并提高了可用内存的利用率。 我们发现压缩的I / O和内存优势超过了额外的CPU成本，并带来了总体更高的性能。

清单5中的以下命令用于压缩两个表。

清单5.启用压缩和REORG表

ALTER TABLE xmlrpdb.pdbxml COMPRESS YES;
REORG TABLE xmlrpdb.pdbxml LONGLOBDATA RESETDICTIONARY;ALTER TABLE xmlrpdb.atom_site COMPRESS YES;
REORG TABLE xmlrpdb.atom_site LONGLOBDATA RESETDICTIONARY;

表1总结了空间消耗的减少。 压缩之后，可以将6,029个PDBML文档中包含的信息存储在少67.4％的页面中（即，比不进行压缩的空间少三倍）。

表1.压缩节省的空间

	压缩前	压缩后	积蓄
xmlrpdb.pdbxml	176,256页	44,736页	74.6％
xmlrpdb.atom_site	264,960页	99,264页	62.5％
总	441,216页	144,000页	67.4％

页面大小为32 KB，最终存储的144,000页相当于4.4 GB，仅占83 GB原始原始数据量的5.3％。 如果将这个比率推算到PDB归档文件的当前总大小，我们发现0.75 TB的PDB信息将仅使用大约40.7 GB的空间以及一些索引空间存储在DB2中。

巨大的存储节省源于两个因素。 首先，通过在预处理步骤中将原子坐标转换为关系格式，可以消除原子信息中标记与值的高比率。 其次，DB2压缩将剩余的XML和关系数据缩小了3倍。

数据库分区

尽管空间消耗已大大减少，但PDB数据量仍继续快速增长。 而且，可以通过将数据分布在多个数据库分区上来减少复杂分析查询的响应时间，从而使所有分区并行处理其分配的数据。 这些数据库分区可以驻留在同一台计算机上，以利用多核系统的所有CPU功能，也可以以无共享配置分散在多台计算机上。 可通过IBMInfoSphere®Warehouse获得DB2数据库分区功能（DPF），该软件包包含具有高级功能的DB2以及其他设计，报告和数据库管理工具。

我们建议使用DPF，通过对pdb_id列的值进行哈希处理，将pdbxml表和atom_site表中的数据分布在整个数据库分区中。 这是通过将子句DISTRIBUTE BY HASH(pdb_id)到相应的CREATE TABLE语句来实现的。 pdb_id列中的大量不同值确保行在数据库分区上的分布相对均匀。 通过散列其连接键（ pdb_id ）来分布两个表，还可以确保给定PDBML文档的所有原子行都存储在与PDBML文档本身相同的数据库分区中。 这种并置意味着始终可以在每个数据库分区中评估两个表之间的联接，并且永远不需要跨分区传送数据。

范围划分

范围分区 （也称为表分区 ）使您可以根据指定列中的值对表中的数据进行分区，以便具有相同值的行将位于同一分区中。 范围分区的概念与数据库分区正交。 如果同时使用数据库分区和范围分区，则表中的行将首先在数据库分区中进行哈希处理，然后在每个数据库分区中进行范围分区。

范围分区可以用于多种目的。 目的之一是分别更轻松地引入和推出新数据和旧数据。 当DB2查询优化器确定只需要检查一部分分区来回答特定查询时，另一个目的就是基于分区消除来提高性能。 对于PDB，部署了范围分区以从分区消除中受益，而不是简化数据的导入和导出。

由于以下原因，我们决定通过pdbx_PDB_model_num列对atom_site表进行分区：记住，可以使用称为NMR的方法通过实验确定蛋白质的三级结构，该方法会为同一蛋白质产生多个三级结构。 这些变体称为模型 ，并由字段pdbx_PDB_model_num编号。 pdbx_PDB_model_num = 1值表示pdbx_PDB_model_num = 1的第一个（默认）模型。 其他变体是相同蛋白质的非默认模型，并且具有pdbx_PDB_model_num >= 2 。 通过X射线衍射在结构上确定的蛋白质只有pdbx_PDB_model_num = 1模型。

清单6显示了具有范围分区的atom_site表的扩展定义。 属于第一个模型的所有原子坐标（ pdbx_PDB_model_num = 1 ）存储在一个分区中，而任何变体（ pdbx_PDB_model_num >= 2 ）存储在另一个分区中。 尽管目前PDB中只有约16％的蛋白质具有NMR产生的变异，但是它们变异的数量如此之大，以至于两个分区的记录数量大致相同。

清单6.具有范围分区的表定义

CREATE TABLE xmlrpdb.atom_site (pdb_id             CHAR(4) NOT NULL,...pdbx_PDB_model_num SMALLINT NOT NULL,type_symbol           VARCHAR(10) WITH DEFAULT NULL,PRIMARY KEY (pdb_id, atom_site_id),FOREIGN KEY (pdb_id) REFERENCES xmlrpdb.pdbxml(pdb_id),CONSTRAINT group_chk CHECK (group_PDB in ('ATOM', 'HETATM'))
)
-- IN ts_atom_data_32k
INDEX IN ts_atom_index32k
PARTITION BY RANGE (pdbx_PDB_model_num)
(PARTITION DEF_MODELS      STARTING (1) ENDING (1) IN TS_ATOM_DATA1_32K,PARTITION NON_DEF_MODELS  STARTING (2) ENDING (MAXVALUE) IN TS_ATOM_DATA2_32K
);

我们之所以选择这种范围划分方案，是因为许多PDB查询通常会区分默认和非默认蛋白质模型，因此可以从划分中受益。 例如，分析所有或大多数默认模型的查询仅需要扫描分区DEF_MODELS ，这将所需的I / O减少了一半。

多维聚类

除了范围分区之外， 多维聚类 （MDC）还可用于基于一个或多个列对表中的行进行聚类。 在聚类列中具有相同值的行实际上一起存储在同一存储单元中。 这可以极大地提高沿一个或多个聚类维度约束和选择数据的查询的性能。 像DPF一样，MDC也可以通过IBM InfoSphere Warehouse获得。

群集列的选择需要基于预期的查询工作量，因此群集支持最常见和最关键的查询。 例如，许多PDB查询可能会根据所涉及的氨基酸来搜索原子数据。 因此，基于列label_comp_id聚集atom_site表可能是有益的，在大多数文档中，列包含氨基酸的三个字母的代码。 要实现此集群，请将以下子句添加到清单3中的第二个CREATE TABLE语句中： ORGANIZE BY DIMENSIONS(label_comp_id) 。

另一个示例是通过group_PDB列对atom_site表进行集群。 我们对几个样本查询进行了评估，这些样本查询将其搜索限制在单个group_PDB值（即"HETATOM" ）中，并发现它可以将查询性能提高四倍。

PDB查询和性能

在本节中，我们讨论两个示例查询以演示：

• 可以轻松地对PDB数据进行甚至复杂的分析。
• 前面各节中描述的数据库设计决策的好处。

清单7中的查询从所有PDB条目中选择PDB标识符，分辨率和描述，其中实验方法为"X-RAY DIFFRACTION"并且分辨率（ ls_d_res_high ）小于2.5。 分辨率以Ångstrøm（1Å= 0.1纳米）表示，并用作分析原子结构的质量度量。 分辨率小于2Å的结构是高分辨率结构（即，可以非常精确地确定其原子的位置）。 分辨率大于3Å的结构精度较低，通常会被忽略。

清单7.查询具有最佳X射线分辨率的前10条记录

SELECT pdb_id, x.resolution, x.pdbx_descriptor
FROM xmlrpdb.pdbxml,XMLTABLE('$PDBXML_FILE/*:datablock/*:refineCategory/*:refine[@pdbx_refine_id = "X-RAY DIFFRACTION" and *:ls_d_res_high <= 2.5 ]'COLUMNSresolution      DEC(9,5)      PATH '*:ls_d_res_high',pdbx_descriptor VARCHAR(2000) PATH '../../*:structCategory/*:struct/*:pdbx_descriptor') AS x
-- WHERE
--   upper(x.pdbx_descriptor) LIKE '%UNKNOWN%' or
--   upper(x.pdbx_descriptor) LIKE '%UNCHARACTERIZED%'
ORDER BY x.resolution
FETCH FIRST 10 ROWS ONLY;

清单8显示了该查询的结果。 与自定义代码相比，使用DB2 pureXML的好处之一是很容易修改SQL / XML查询来优化搜索。 例如， 清单7包含三个注释行以及一个附加的WHERE子句。 它们可用于进一步过滤描述符，以找到尚未或无法表征的那些结构。

清单8.清单7中的查询产生的结果

PDB_ID RESOLUTION  PDBX_DESCRIPTOR
------ ----------- -------------------------------------------------
2VB1       0.65000 LYSOZYME C (E.C.3.2.1.17)
2B97       0.75000 Hydrophobin II
2OV0       0.75000 PROTEIN
2I16       0.81000 Aldose reductase (E.C.1.1.1.21)
2I17       0.81000 Aldose reductase (E.C.1.1.1.21)
2HS1       0.84000 HIV-1 Protease V32I mutant (EC 3.4.23.16)
2F01       0.85000 Streptavidin
2OL9       0.85000 SNQNNF peptide from human prion residues 170-175
2PF8       0.85000 Aldose reductase (E.C.1.1.1.21)
2P74       0.88000 Beta-lactamase CTX-M-9a (E.C.3.5.2.6)10 record(s) selected.

清单7中的查询中的谓词是弱选择的，因此需要对pdbxml表进行全表扫描。 表2总结了此表扫描查询的性能如何从我们的两个设计决策中受益：原子站点分离和压缩。 在我们的环境中，此表扫描受I / O约束。 DB2压缩减轻了I / O瓶颈，并将查询经过时间减少了40％以上（从244秒减少到128秒）。 将原子站点数据提取到单独的关系表中，极大地减少了pdbxml表的大小，将查询性能提高了近4 1/2倍，从138秒提高到31秒。

表2.清单7中查询的响应时间（无索引）

原子部位分离	压缩	响应时间
没有	没有	244秒
没有	是	138秒
是	是	31秒

清单9显示了另一个示例查询，该查询确定不同原子（或离子）在不同化合物中出现的频率。 WHERE子句将搜索限制在所谓的杂原子上，并且仅考虑每种蛋白质的第一个模型。

清单9.杂原子出现的分析

SELECT label_atom_id                   AS "Atom", COALESCE(label_comp_id, 'none') AS "Compound", COUNT(*)                        AS "Occurrences"
FROM xmlrpdb.atom_site
WHERE group_PDB = 'HETATM'AND pdbx_PDB_model_num = 1
GROUP BY label_atom_id, label_comp_id
ORDER BY COUNT(*),label_comp_id DESC;

清单10中显示了结果行的子集。 最常见的化合物是水（HOH），其中的氧（O）是其原子之一。 氢的报告数量（以H1的H1和H2表示）很低，因为检测氢需要非常高的分辨率，而这并非总是可以实现的。

（人类）血红蛋白是由多个分子组成的蛋白质，这种分子可以与称为血红素的非蛋白质化合物相互作用。 血红素（HEM）是一种多原子，非蛋白质的有机结构，能够将铁（FE）离子定位在其中心。 另一方面，该铁离子对于氧结合至关重要。 清单10中的结果表明，铁与血红素化合物一起频繁出现。 尽管这是一个简单的示例，但它证明了检测PDB数据中有意义的相关性以及更好地了解蛋白质如何在分子水平上相互作用和相互作用的效率。

清单10.清单9中的查询产生的结果的子集

Atom     Compound        Occurrences
-------- --------------  -------------------------
O        HOH             1571965
MG       MG              7159
...
H1       HOH             1858
H2       HOH             1858
ZN       ZN              1664
...
CL       CL              1318
CA       CA              1295
...
FE      HEM           379
NA       HEM             379

表3显示了即使没有查询特定的索引，我们用于原子站点分离，压缩，范围分区和多维聚类的数据库设计选择也可以提供出色的性能。

表3.清单9中查询的响应时间（无索引）

原子部位分离	压缩	范围划分	MDC	响应时间
是	是	没有	没有	38.7秒
是	是	是	没有	25.8秒
是	是	是	是	5.5秒

摘要

本文介绍了如何在DB2中使用pureXML和关系数据管理功能来有效地存储和查询Protein Data Bank（PDB）。 基于蛋白质数据的内在特征，我们设计了优化的混合数据库方案。 为了获得最佳性能和最小的空间消耗，我们建议使用数据库分区，范围分区，压缩和多维群集。 此外，XML索引和关系索引的组合可以进一步提高查询性能。 基于DB2的PDB继续用于研究，例如在整个PDB中搜索某些蛋白质相互作用，并帮助解释结构水平上的异常相互作用。

致谢

基于DB2的PDB的开发是由德国德累斯顿工业大学生物技术中心的Maria Teresa Pisabarro的结构生物信息学研究小组完成的。 该项目由SAP联合创始人Klaus Tschira的基金会资助。 另外，还要感谢Henrik Loeser对本文所述工作的帮助，以及德国柏林布赫分子医学中心马克斯·德布吕克中心（MDC）的柏林医学系统生物学研究所（BIMSB）提供的生产服务器。

翻译自: https://www.ibm.com/developerworks/data/library/techarticle/dm-1109proteindatadb2purexml/index.html