为了搞清楚gene ontology database的数据结构,必须得先了解清楚一个概念,什么是Directed Acyclic Graphs (DAG)。这个DAG被翻译成有向无环图,具体是个啥意思呢?
对于一个DAG来讲,有以下两个特征:
- 有向。数据间有指向性关系,A属于B,或者说A就是B的一种形式之类的。
- 无环。当你从任何一点开始,顺着指向走的话永远不可能走回原点。
下面就依据实际的例子来解释吧,关于定义,可以百科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里,我们可以这样写:
如果我们要找到所有属于pigment accumulation的子类,我们可以写:
对于树状的结构当然是没问题的。但是在现实的数据当中,一个子类只属于一个父类的情况并不是很多,在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的子类,似乎可以用:
这一句么可以选出的项是:
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 |
distance | integer |
The distance in terms of the number of “hops” between nodes in the |
|
relation_distance | integer |
(added 2008-10-27) The distance in terms of the number of “hops” over |
于是我们知道怎么去看GO数据库的结构图了。核心部分是term和term2term两个数据表,然后呢,外围有两个重要的表,一个是association用来关联term与gene和相关数据库的信息,一个是gene_product用来存取gene或者基因产物,基本上是种(species)水平的。
先这么多吧。今天搞清楚了什么是DAG了。