posts - 431,  comments - 344,  trackbacks - 0
原文地址:http://blog.charliezhu.com/category/chemoinformatics/(Charlie 是个牛人啊)

分子结构式的表达和存储

化学分子结构式的表达方法有很多。最基本的方法当然就是图片文件,图片文件的确仅适用于展示,不适用于分析和检索。常见的以文本形式存储的化学结构包括InChI,SMILES,Molfiles,CML等。对于这些格式,在inchi.info网站上有一个不错的比较。原文还带有一些注释。

  InChI InChIKey SMILES Molfile CML
线性(不用换行) Yes Yes Yes No No
唯一性 Yes No Possibly No No
可读性 Hardly Impossible Easily Hardly Hardly
定义原子几何位置 No No No Yes Yes
长度(每原子字符数) ~2 ~1 1-2 ~50 ~50
软件支持 (0-1) 0.3 0.1 0.2 1 0.5

在数据库中作为结构式信息进行存储,比较重要的考虑因素就是唯一性、存储空间。所以使用InChI, SMILES作为结构式的描述信息都可行。

这个表里需要注意的是,InChIKey与Molfile/CML在唯一性上都是No,但有很大不同。不同的分子结构有可能用同一个InChIKey表达;同一个分子式,可以表示成不同的Molfile/CML。这都对数据库中的 一项重要工作,检索带来大麻烦。

找到合适的分子结构式表达方式,用文本的方式存储起来,并不复杂。执行一些简单的操作,比如通过分子结构(精确)查找分子,也和普通的数据库操作没什么两样。

但是要通过结构式信息进行分子参数计算、子结构检索、描述符(fingerprint)生成及索引、分子相似性计算等工作时,往往需要在关系数据库上增加插件来实现。

关系数据库插件 (cartridge)

下面的插件,没有一个是应用于MS SQL Server的。SQL Server也提供了扩展存储过程(SQL Server 2000)及CLR(SQL Server 2005)等插件接口,是能够实现相同的功能的。这也正是我现在正在进行的工作。

pgchem::tigress

开源。用在PostgreSQL上。在checkmol/matchmol 和OpenBabel的基础上开发的。文档很nice,但是似乎很久没有更新了。典型的案例是http://www.chemcollect.de/

mychem

开源。用在MySQL上,UDF形式的插件。基于OpenBabel。SVN代码更新比较勤。

OrChem

This project aims at creating an open source chemistry plugin / cartridge for the relational database system Oracle.

其他商业插件

  1. CambridgeSoft Oracle Cartridge
  2. Symyx Direct, Cartridge for Oracle
  3. CHORD, a commercial chemical cartridge for PostgreSQL, is sold by gNova. 基于OEChem。OEChem也不是免费的。
  4. JChem Cartridge, adds chemical intelligence to the Oracle platform.

一本新书

Design and Use of Relational Database in Chemistry,《在化学领域设计和使用关系数据库》。作者是gNova公司的TJ O’Donnell, Ph. D.,那这本书里用到的方法,也自然是这个公司的CHORD插件了。不过这本书对关系数据库中,化学信息的应用,写得比较全面和系统了(从目录上看)。就是有点灌水,连关系数据理论都要占一章。写一本书,讲解理论的同时推销自己的产品,还能挣稿费,这绝对是个好办法。Amazon上的定价是$93.56。

不需要插件的解决方案

Chemical Substructure Search in SQL
Adel Golovin and Kim Henrick,
EMBL-EBI Hinston Hall Genome Campus, Cambridge, U.K.
J. Chem. Inf. Model., Article ASAP
DOI:
10.1021/ci8003013

这是一篇发表不久的文章。我很感叹之前为什么没有过这么直接的思路。分子结构用SMILES表达的原理中,实际上就已经将分子结构抽象为原子(Atom)和键(Bond)之间的组合,并且用生成树(spanning tree)构造成字串。

分子、原子、键、分子结构(spanning tree),都可以,而且很适合在关系数据库中表达出来。子结构检索等功能操作,也可以用基本的SQL来实现。

相对于用插件的方案,优势在于

  1. 不限制于数据库平台。
  2. 更稳定。插件的质量高低,运行于何种进程空间,是否会出现异常,都将直接影响服务器。在重要的运营服务器上,更是隐患。
  3. 性能(performance)更优。对原子和键的查询都可直接利用数据库服务器的索引。
  4. 存储空间上(可能)有改善。当设计得当时,原子、键建立字典表,事实表就都是数字组成的关联表。在基于插件的系统中,以子结构检索为例,为了尽量减少性能消耗最大的插件函数计算,往往会生成碎片(fingerprint)索引,所使用的存储空间,加上SMILES的字符串存储空间,会高于这个方案中的存储空间。尤其是在小分子数据库中。

其他参考资料

Fast Substructure Search series, by Rich Apodaca

How to create a web-based molecular structure database with free software[PDF], by Norbert Haider (Checkmol/matchmol)

posted on 2009-09-24 21:20 周锐 阅读(1039) 评论(0)  编辑  收藏 所属分类: ChemistryJava

只有注册用户登录后才能发表评论。


网站导航: