Charlie’s path to dEAth

January 17, 2009

喜洋洋与灰太狼

很长一段时间了，要是有幸不加班，到家可以和儿子一起看这个动画片。到了后来，一岁的儿子远没有我的兴趣大，他还不理解每个小羊小狼的对话、神态、性格和心理上的微妙特点，因为他还没有开始了解这个社会，没有体会社会中各类人的可爱之处。当然老婆也不理解我，作为一个正常的准中年人，她不喜欢这些。我们三个人有两道代沟。

我很喜欢灰太狼

他很爱自己的老婆和家庭。
为了老婆的幸福，准确点说是老婆的虚荣，执着追求，不屈不挠，不怕挫折。
非常朴素节俭。
有思想有创意，立即行动，执行力超强。指挥团队时体现出非凡的领导才能。

爱和命运是他难以成功的唯一原因。

Filed by charlie at 7:41 pm under Life, son
No Comments

January 15, 2009

分子结构式的表达和存储

化学分子结构式的表达方法有很多。最基本的方法当然就是图片文件，图片文件的确仅适用于展示，不适用于分析和检索。常见的以文本形式存储的化学结构包括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.

其他商业插件

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的字符串存储空间，会高于这个方案中的存储空间。尤其是在小分子数据库中。