为了搞清楚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了。
