官方:基因本体(GO)知识库是有关基因功能的全球最大信息来源。 这些知识既是人类可读的,也是机器可读的,并且是生物医学研究中大规模分子生物学和遗传学实验的计算分析的基础。
在读懂基因本体论(Gene Ontology)前,我们先看看什么是本体论:
本体论(Ontology )是探究世界的本原或基质的哲学理论 。
本体论通常处理的问题:存在哪些本质,如何将这些本质分组,在层次结构内关联以及如何根据相似性和差异进行细分 。
基因本体论(Gene Ontology)包含生物学领域知识体系本质的表示形式,本体通常由一组类(或术语或概念)组成,它们之间具有关系。 基因本体论(GO)从三个方面(GO domains)描述了我们对生物学领域的了解:
理解了上述的概念,现在举个例子,如果站在基因本体论GO的角度来解释一个基因的话:
基因产物:细胞色素C(cytochrome c)
分子功能:氧化还原酶活性
细胞组分:线粒体基质
生物过程:氧化磷酸化
自定义同义词类型也用于本体中。 例如,许多同义词被指定为系统同义词。 此类型的同义词是术语名称的确切同义词。
GO以图的形式构建,术语作为同种的节点,术语间的关系(对象属性)作为连接。
GO图中的节点与其他节点可以具有任意数量和类型的关系, 就像层次结构,例如,家谱或一个物种的分类法
一个节点可能与多个子节点(更特定的节点)具有连接,也可以具有多个父节点(较宽的节点)
利用关系与关系间的连接可以推断相应的分组注释,节点间关系的推断,这个会在后面详细研究:
上图表示:A is a B,B is part of C,所以可以推断 A is part of C
节点间总体与部分关系:
一个节点可能与一个节点有一部分关系。 下图说明了这一点:
上图: mitochondrion 是两个节点的父节点:it is an organelle and it is part of the cytoplasm ; organelle 有两个子节点: mitochondrion is an organelle, and organelle membrane is part of organelle
我们将上面的关系图简化表示为 箭头导向性图 ,这是图中常见的关系表示:
接下我们详细看看GO是怎样来描述这几种关系的:
如果我们说 A is a B ,则意味着节点A是节点B的子类型。例如,有丝分裂细胞周期是细胞周期,或者裂解酶活性是催化活性。
应该注意的是,a并不代表是实例。 从本体论上来说,一个实例是某个事物的具体示例。 例如 猫是哺乳动物,但加菲猫是猫的实例,而不是猫的亚型。 GO中的术语表示实体或现象的类别,而不是特定的表现形式(或实例)。 但是,如果我们知道猫是哺乳动物,则可以说猫的每个实例都是哺乳动物。
使用 is a 对批注进行分组是 安全的 。例如,如果将基因产物X注释为具有酪氨酸激酶活性,并且本体论证明酪氨酸激酶活性是激酶活性的一种(类型),那么我们可以安全地得出结论,基因产物X具有激酶活性。
利用上面得到结论,我们可以将 is a 关系和其他关系类型结合来推断,下图表示了可以推断的关系:
关系的一部分用于表示整个部分的关系。 part of 只有当B一定是A的一部分时,才会在A和B之间部分关系:无论B存在于何处,它都是A的一部分,B的存在意味着A的存在。但是,考虑到A的出现,我们不能肯定地说B的存在。
使用的 part of 进行分组注释是 安全的 。 例如,如果将基因产物X标注为位于线粒体内膜上,而本体论记录了线粒体内膜与线粒体之间的关系的一部分,则可以安全地得出结论X位于线粒体内。
利用上面得到结论,我们可以将 part of 关系和其他关系类型结合来推断,下图表示了可以推断的关系:
has part 是对关系部分的逻辑补充,它从父级的角度代表了“部分-整体”关系。
与 part of 一样,GO关系 has part 仅在A始终将B作为一部分的情况下使用,即A必定具有B的部分。 但是,如果B存在,我们不能肯定地说A存在。 即所有A都有B部分,但是A只是B的一部分。
使用 has part 注释进行分组是 不正确的 。 例如,我们可以在本体论中断言受体酪氨酸激酶活性具有部分激酶活性。 然而,将所有注释归类到受体酪氨酸激酶活性下的激酶活性将是不正确的。
利用上面得到结论,我们可以将 has part 关系和其他关系类型结合来推断,下图表示了可以推断的关系:
一种过程直接影响另一种过程或质量的表现,即前者调节后者。 调节的目标可以是另一种过程,例如调节途径或酶促反应,或者可以是质量,例如细胞大小或pH。 与 part of 关系类似,该关系专门用于表示必定的调节:如果同时存在A和B,则B总是调节A,但是A可能不总是受B调节,即所有B都调节A一些A受B调节。
如果将基因产物X注释为参与调节糖酵解的过程,则不能得出结论X参与糖酵解是 不正确的 。 但是,某些工具使用调节关系来对批注进行分组, 这可用于基因集富集, 所得的基因集包括与分组术语有因果关系的过程中涉及的基因。
利用上面得到结论,我们可以将 regulates 关系和其他关系类型结合来推断,下图表示了可以推断的关系:
GO的结构可以用下图来表示,这个图也叫有向无环图(Directed Acyclic Graph ,DAG)。
如上图所示,三个GO域(细胞成分,生物学过程和分子功能)分别由一个单独的根本体术语表示。
一个域中的所有术语都可以将其父源追溯到一个根术语,通过到本体根的中间术语可能存在许多不同的路径。
这三个根节点是不相关的,并且没有公共的父节点,这意味着来自不同本体的术语之间没有任何关系。但是,GO本体之间也存在其他关系,例如,分子功能术语“细胞周期蛋白依赖性蛋白激酶活性”是生物过程“细胞周期”的一部分。GO本体间相关 http://geneontology.org/docs/ontology-relations/ 。
某些基于图的软件可能需要一个根节点。在这种情况下,可以将“假”术语添加为三个现有根节点的代。
GO只代表生物学的当前认知,因此随着生物学知识的积累,它会不断地被修订和扩展。也就是说目前的GO术语不一定代表某个基因产物所有的功能,组分或参加的过程,只是现阶段对它的认知。
每周更新一次,由GOC本体团队与请求更新的科学家共同完成的。
模型的转换 E-R图如何转换为关系模型呢?我们先看一个例子。
图2.1是学生和班级的E-R图,学生与班级构成多对一的联系。根据实际应用,我们可以做出这个简单例子的关系模式:
学生(学号,姓名,班级)
班级(编号,名称)
“学生.班级”为外键,参照“班级.编号”取值。
这个例子我们是凭经验转换的,那么里面有什么规律呢?在2.2节,我们将这些经验总结成一些规则,以供转换使用。 (1)一个实体型转换为一个关系模式
一般E-R图中的一个实体转换为一个关系模式,实体的属性就是关系的属性,实体的码就是关系的码。
(2)一个1:1联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。
图2.2是一个一对一联系的例子。根据规则(2),有三种转换方式。
(i) 联系单独作为一个关系模式
此时联系本身的属性,以及与该联系相连的实体的码均作为关系的属性,可以选择与该联系相连的任一实体的码属性作为该关系的码。结果如下:
职工(工号,姓名)
产品(产品号,产品名)
负责(工号,产品号)
其中“负责”这个关系的码可以是工号,也可以是产品号。
(ii) 与职工端合并
职工(工号,姓名,产品号)
产品(产品号,产品名)
其中“职工.产品号”为外码。
(iii) 与产品端合并
职工(工号,姓名)
产品(产品号,产品名,负责人工号)
其中“产品.负责人工号”为外码。
(3)一个1:n联系可以转换为一个独立的关系模式,也可以与n端对应的关系模式合并。
(i) 若单独作为一个关系模式
此时该单独的关系模式的属性包括其自身的属性,以及与该联系相连的实体的码。该关系的码为n端实体的主属性。
顾客(顾客号,姓名)
订单(订单号,……)
订货(顾客号,订单号)
(ii) 与n端合并
顾客(顾客号,姓名)
订单(订单号,……,顾客号)
(4)一个m:n联系可以转换为一个独立的关系模式。
该关系的属性包括联系自身的属性,以及与联系相连的实体的属性。各实体的码组成关系码或关系码的一部分。
教师(教师号,姓名)
学生(学号,姓名)
教授(教师号,学号)
(5)一个多元联系可以转换为一个独立的关系模式。
与该多元联系相连的各实体的码,以及联系本身的属性均转换为关系的属性,各实体的码组成关系的码或关系码的一部分。
(6)具有相同码的关系模式可以合并。
(7)有些1:n的联系,将属性合并到n端后,该属性也作为主码的一部分
这类问题多出现在聚集类的联系中,且部分实体的码只能在某一个整体中作为码,而在全部整体中不能作为码的情况下才出现(其它情况本人还没碰到,呵呵,欢迎指教)。
比如上篇文章介绍的管理信息系统中订单与订单细节的联系。
关于什么是聚集,2.3节介绍。 这部分本应在概念设计中介绍的,用到了才想起来,这里补充一下。
关于现实世界的抽象,一般分为三类:
(1) 分类:即对象值与型之间的联系,可以用“is member of”判定。如张英、王平都是学生,他们与“学生”之间构成分类关系。
(2) 聚集:定义某一类型的组成成分,是“is part of”的联系。如学生与学号、姓名等属性的联系。
(3) 概括:定义类型间的一种子集联系,是“is subset of”的联系。如研究生和本科生都是学生,而且都是集合,因此它们之间是概括的联系。
例:猫和动物之间是概括的联系,《Tom and Jerry》中那只名叫Tom的猫与猫之间是分类的联系,Tom的毛色和Tom之间是聚集的联系。
订单细节和订单之间,订单细节肯定不是一个订单,因此不是概括或分类。订单细节是订单的一部分,因此是聚集。 有了关系模型,可以进一步优化,方法为:
(1) 确定数据依赖。
(2) 对数据依赖进行极小化处理,消除冗余联系(参看范式理论)。
(3) 确定范式级别,根据应用环境,对某些模式进行合并或分解。
以上工作理论性比较强,主要目的是设计一个数据冗余尽量少的关系模式。下面这步则是考虑效率问题了:
(4) 对关系模式进行必要的分解。
如果一个关系模式的属性特别多,就应该考虑是否可以对这个关系进行垂直分解。如果有些属性是经常访问的,而有些属性是很少访问的,则应该把它们分解为两个关系模式。
如果一个关系的数据量特别大,就应该考 虑是否可以进行水平分解。如一个论坛中,如果设计时把会员发的主贴和跟贴设计为一个关系,则在帖子量非常大的情况下,这一步就应该考虑把它们分开了。因为 显示的主贴是经常查询的,而跟贴则是在打开某个主贴的情况下才查询。又如手机号管理软件,可以考虑按省份或其它方式进行水平分解。 这部分主要是考虑使用方便性和效率问题,主要借助视图手段实现,包括:
(1) 建立视图,使用更符合用户习惯的别名。
(2)对不同级别的用户定义不同的视图,以保证系统的安全性。
(3)对复杂的查询 *** 作,可以定义视图,简化用户对系统的使用。
物理设计主要工作是选择存取方法(索引),以及确定数据库的存储结构,这里就不说明了。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)