原文地址:
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)等插件接口,是能够实现相同的功能的。这也正是我现在正在进行的工作。
开源。用在PostgreSQL上。在checkmol/matchmol 和OpenBabel的基础上开发的。文档很nice,但是似乎很久没有更新了。典型的案例是http://www.chemcollect.de/
开源。用在MySQL上,UDF形式的插件。基于OpenBabel。SVN代码更新比较勤。
This project aims at creating an open source chemistry plugin / cartridge for the relational database system Oracle.
其他商业插件
- CambridgeSoft Oracle Cartridge
- Symyx Direct, Cartridge for Oracle
- CHORD, a commercial chemical cartridge for PostgreSQL, is sold by gNova. 基于OEChem。OEChem也不是免费的。
- 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来实现。
相对于用插件的方案,优势在于
- 不限制于数据库平台。
- 更稳定。插件的质量高低,运行于何种进程空间,是否会出现异常,都将直接影响服务器。在重要的运营服务器上,更是隐患。
- 性能(performance)更优。对原子和键的查询都可直接利用数据库服务器的索引。
- 存储空间上(可能)有改善。当设计得当时,原子、键建立字典表,事实表就都是数字组成的关联表。在基于插件的系统中,以子结构检索为例,为了尽量减少性能消耗最大的插件函数计算,往往会生成碎片(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
周锐 阅读(1052)
评论(0) 编辑 收藏 所属分类:
Chemistry 、
Java