GO数据库学习笔记(3)

为了搞清楚gene ontology database的数据结构,必须得先了解清楚一个概念,什么是Directed Acyclic Graphs (DAG)。这个DAG被翻译成有向无环图,具体是个啥意思呢?
对于一个DAG来讲,有以下两个特征:

  1. 有向。数据间有指向性关系,A属于B,或者说A就是B的一种形式之类的。
  2. 无环。当你从任何一点开始,顺着指向走的话永远不可能走回原点。

下面就依据实际的例子来解释吧,关于定义,可以百科wiki一下。
下面这个图就是一个简单的树状数据结构,在这个结构里,有一种类似根枝叶的结构。比如我们想从biological process走到cellular pigment accumulation就只有一条路:biological process->pigmentation->pigment accumulation->cellular pigment accumulation。

这种树状结构在数据库里怎么来存呢?我们可以那建立一个字表,这个字表专门用来存找到某个元素的路径。理解起来就象文件夹一样。OK,我们来建一个表,表的示例如下:

Table: biological_process

ID	Path	Name
1	root	biological process
2	B.	pigmentation
3	B.	cellular process
4	B.P.	pigment accumulation
5	B.C.	cellular pigmentation
6	B.P.P.	cellular pigment accumulation

如果我们要找到所有属于pigmentation的子类,这个就比较容易了,在SQL里,我们可以这样写:

SELECT * FROM biological_process WHERE Path LIKE ‘B.P.%’

如果我们要找到所有属于pigment accumulation的子类,我们可以写:

SELECT * FROM biological_process WHERE Path LIKE ‘B.P.P.%’

对于树状的结构当然是没问题的。但是在现实的数据当中,一个子类只属于一个父类的情况并不是很多,在GO数据库当中的数据就不是这个样子。比如说这个例子,我们知道cellular pigmentation不但属于cellular process,还属于pigmentation;还有cellular pigment accumulation不但属于pigment accumulation,还属于cellular pigmentation。这样的话,Path中的值就不能只存一个值,于是从A点找到B点的可能路径会变得很多。有些时候,这个存取成本会变得很高,这样我们不得不寻找一种可以更好的存取数据的方法。

从上图中我们发现,它个特点完全符和有向无环图的特点。那么就可以依照前人的办法来存取数据了。这个办法就是把表分成两个部分,一个表专门用来存取每一个元素,另一个表专门用来存取元素与元素之间的关系,在GO数据库中只有几种关系,比如说is_a, part_of或者regulates。建表如下:一个表就叫:term,另一个表示元素间关系的表就叫term2term表吧。

Table: term
tID    term_type
1    biological process
2    pigmentation
3    cellular process
4    pigment accumulation
5    cellular pigmentation
6    cellular pigment accumulation

Table: term2term
ID    term1_id    term2_id    relationship_type
1    2        1        is_a
2    3        1        is_a
3    4        2        is_a
4    5        3        is_a
5    6        4        is_a
6    5        2        is_a

这个时候如果我们要找到所有属于pigmentation的子类,似乎可以用:

SELECT * FROM term WHERE tID IN (SELECT term1_id FROM term2term WHERE term2_id = 2)

这一句么可以选出的项是:

4    pigment accumulation

5    cellular pigmentation

这样选出的数据全不全呢?显然不是很全,因为cellular pigment accumulation也应该是pigmentation的一个子类啊。这怎么办呢?没办法,只能把所有的关系全部存进去。我们就加些关系呗,把下图中的虚线部分全部都加进去不就得了?

这样似乎是没有问题的。但是有些时候有读取数据的时候,又会觉着这个时效性并不是总很好,而且所属关系的层次并不是很明确。于是在GO数据库里,term2term还是只存取两两之间有这种直接关系的(图中实线箭头表示),又用了另外一个表格graph_path来专门存取所有元素之间的关系(包括实线箭头和虚线箭头两部分数据)。graph_path的结构如下:

F-Key Name Type Description
id serial

PRIMARY KEY

go_graph.term.id term1_id integer

NOT NULL

the object node See docs for *term.term1_id*

go_graph.term.id term2_id integer

NOT NULL

the subject node See docs for *term.term2_id*

go_graph.term.id relationship_type_id integer

References an entry in the term table corresponding to the INFERRED
relation that holds between term2 and term1. For future extension. See:
http://wiki.geneontology.org/index.php/Transitive_closure

distance integer

The distance in terms of the number of “hops” between nodes in the
asserted graph (term2term). The relationship_type_id is ignored here.
Example: if A part_of B is_a C part_of D, then distance=3 for A part_of
D

relation_distance integer

(added 2008-10-27) The distance in terms of the number of “hops” over
relationship_type_id in the asserted graph (term2term). Example: if A
part_of B is_a C part_of D, then relation_distance=2 for A part_of D

于是我们知道怎么去看GO数据库的结构图了。核心部分是term和term2term两个数据表,然后呢,外围有两个重要的表,一个是association用来关联term与gene和相关数据库的信息,一个是gene_product用来存取gene或者基因产物,基本上是种(species)水平的。

先这么多吧。今天搞清楚了什么是DAG了。

Leave a Reply

  

  

  

%d 博主赞过: