蛋白质组学元数据仓库的管理与维护.doc

蛋白质组学元数据仓库的管理与维护摘 要：在针对生物数据源具有的分布、异构和动态等特性下，建立的蛋白质组学元数据仓库的基础上，本文给出了删除元数据的方法，以及解决了由于删除元数据和生物数据源更新而带来的元仓库中元数据的变化，而引起的用户模式与元数据的映射不匹配等问题。关键词：删除；元数据；生物数据源Proteomics data warehouse management and maintenanceAbstract: In response to biological data source has the distribution, heterogeneous and dynamic characteristics, establishment of a proteomics metadata of data warehouse based on, This paper presents a method to remove metadata, and solve remove metadata and biological data source update metadata warehouse metadata changes caused by user-mode metadata mapping does not match the other issues.Keywords: Deleted; metadata; biological data sources基金项目：国家高技术研究发展计划（863计划）资助(2006AA02A312)Foundation Item：Supported by National High Technology Research and Development Program of China (2006AA02A312)1 引言随着科技的不断进步，人类对生物信息学的研究也在不断地深入。为了应对生物技术高速发展而引发的数据存储、分析等的应用需求，新的数据库不断建立，存储的数据呈指数级增长(图1)，研究人员需要的数据也开始不只限于某个单一数据库，而是分散在多个相关数据源中5。对高度复杂的海量实验数据进行存储、共享与整合成为了生物信息学研究中最重要的问题之一。目前各个大型生物数据库是由不同的研究机构在不同技术与科研条件下根据其自身的需要建立的，研究或应用的背景也各不相同，从而形成语法、语义、模式等方面的异构1。除此之外，这些数据库大都具有分布、自治和动态的特点，给科研人员的访问和使用带来了极大的影响。伴随着研究发展而新出现的生物数据库也有类似的问题。诸多的异构数据源严重影响了数据的共享与整合，给研究工作造成了许多困难。图1主要生物数据库规模呈指数级增长趋势图2多年来，人们试图通过各种办法来解决数据整合的问题。联邦数据库、中间件和数据仓库等技术在不同的着重点和应用上部分的解决了数据共享问题，然而数据源模式异构的问题还是没有从根本上得到解决。元数据是关于数据的数据，是对数据源所存储数据的详细描述，不仅包含了数据的名称、类型等信息，还提供了数据的上下文描述信息，例如数据的来源、取值范围、业务规则等。如果将各数据源的元数据按照一个统一的标准提取出来集中存放在一个元数据库中，并映射到按照用户的查询要求而建立的用户模式上，就能够通过解析用户模式得到对应的各数据源模式查询；对各数据源查询结果进行连接、合并等操作，并按用户模式进行输出，就能够实现数据的共享和整合。基于以上分析，我们提出了基于元数据的蛋白质组学数据资源共享与整合方案，本文讨论的内容是元仓库的管理与维护，主要是在元仓库的基础上删除元数据的方法，并解决由于删除元数据和生物数据源更新而带来的元数据的变化，以及在这种情况下如何解决用户模式与元数据的映射等一系列问题。2工作基础在引言部分中已经介绍过，元数据包含了对数据源中数据的详细描述。因此，通过抽取各数据源的元数据，可以对要集成的数据源在结构上有一个更直观的认识。与数据仓库的集成方法相比，使用元数据进行数据集成有以下特点：（1）元数据库中存储的是各数据源的结构信息，按照统一的元数据标准进行描述后集中存放在元数据库中，能够保持各数据源的结构特征。（2）建立元数据库所抽取的多个数据源的元数据与海量的实验数据相比存储压力要小得多，而且由于各数据源的结构相对稳定，元数据更新频率远低于数据更新频率，同时在查询时是通过元数据直接访问相关的数据源，能够保证查询效率和结果的准确与全面。公共仓库元模型（Common Warehouse Metamodel, CWM）是一个完整的描述数据仓库和业务分析领域的元模型，提供了构建元数据所需的语法和语义。CWM元模型具有良好的树状层次结构和继承机制，已经获得了广泛的支持，成为了元数据的一个重要标准1。刘文杰等设计并实现了一个元数据提取与导入工具MetaPro 1.03，提供了一个基于CWM元模型的元数据集成解决方案，能够根据各相关数据源DBMS的SQL脚本生成元数据库，并针对不同DBMS生成的SQL脚本建立了相应的处理模块。该工具是整个整合方案的基础和重要组成部分。其次郭超等同学设计并实现了基于元数据的分布数据库集成查询工具。对元数据以及CWM元模型进行分析，使用相关接口实现对元数据库的浏览，设计并建立用户模式以及用户模式与元数据间的映射方法，以支持用户的查询。该工具通过分析用户提交的查询条件，把针对用户模式的查询转换为针对各数据库的查询语句；对各数据库返回的查询结果进行整合与清理，并按照用户模式进行输出4。通过MetaPro 1.03生成的元数据库和基于元数据的分布数据库集成查询工具，为本文讨论的内容奠定了基础。3问题的提出及关键技术的研究3.1问题的提出1.在元仓库建立的过程中并没有建立相应的元数据删除模块，要想将元仓库中的某些元数据删除，只能将元仓库中所有的数据清除，重新从各数据源中提取元数据重建元仓库，这样就给元仓库的使用造成没必要的麻烦。如果没有办法将元仓库中的过期或垃圾数据清除，这将会使元仓库中包含的数据量越来越大，最终会引起系统运行效率的低下，甚至崩溃。2.如果删除的元数据是与用户模式中的用户模式字段已经建立了映射关系的，那么将如何处理这些映射关系。3.当某一数据源更新时，需要同时的更新相应的元仓库中的元数据。由于用户模式是建立在元仓库中的元数据基础上的，当元数据发生变化时，那些与该数据发生关联的用户模式中的用户模式字段信息，应该如何进行处理。3.2关键技术的研究背景要想将元仓库中的元数据删除，就必须了解元仓库的结构和特点。CWM本身是由若干互不相同但又紧密相关的元模型（包，Package）构成的，CWM元模型由五个层次21个独立的包组成，每个包都描述了与在数据仓库和业务分析领域中的特定部分相关的类、关联和约束。图3-1 关系包组织结构图图3-1中显示的为关系包中主要的框架。从图中可以看出关系整体上是一个树形结构，树根为Catalog类，可以有多个Schema节点，而Schema由节点NamedColumnSet、Procedure、Trigger、SQLIndex构成。图中的每一个叶子节点都是一棵子树。图3-2给出物化的NamedColumnSet节点Table的子数关系。 图3-2 Table类的子树图CWM关系包描述的是关系数据库的元数据，Catalog、Schema是两个命名空间，表示服务器和数据库的概念。由于元仓库主要关心的是多个数据库的元数据集成，因此元仓库的重心就转到Schema命名空间下。Schema的组合端有四个，其中NamedColumnSet可以物化成两个类Table和View。因为模型集成中考虑集成的类是关系包中实际描述关系数据库的类。如NamedColumnSet是一个Table或View类，所以集成时不会考虑NamedColumnSet类，而直接考虑Table或View类。这样，Schema命名空间按照其组合关联，可以划分五个部分：Table，SQLIndex，Trigger，Procedure和View，每个部分可以是个子树。由以上分析可知：CWM大量使用了UML的继承特性。对CWM关系型包类之间的联系的正确理解是对完整的删除元数据的有力保证。因此在对所元数据删除之前，要确定描述元数据的类之间的依赖关系，即要确定被删除元数据所涉及到的CWM关系型包的类，以及它们之间的关系。其关系如图3-3所示。图3-3 CWM部分实体类及类与类之间的关系3.3具体解决方案因此当删除元仓库中的某一个元数据时，首先要确定该元数据的实体类下是否含有子类，如果该数据的实体类下没有子类，则判断该元数据是否与用户模式中的用户模式字段建立了映射关系，若该元数据与用户模式中的用户模式字段建立了映射关系，如果直接删除他们之间的映射关系，可能会造成当用户在使用用户模式进行查询时，无法获得正确和完整的数据。那么如何处理这一问题呢？由于我们并非生物学家，不能准确的理解其中术语的含义，因此我们将删除信息提供给用户模式的制定者（生物学家），由他们来最终确定是删除该映射，还是将该用户模式字段与其它的元数据进行关联，最后通过函数prodeletes(int ,Connection)调用存储过程“Delete_包名_类名 _ID INT”将该元数据删除。若该元数据的实体类下有相应的子类，则通过函数CWMGetMVLinks()调用存储过程“Get_关联端Id INT”读取其子类的数据信息，并对子类中的数据再次进行以上的判断。具体的流程如图3-4所示。 图3-4 元数据删除流程图如果某一数据源由于某种需要进行了更新，那么将该数据源中的元数据提取到元仓库中时，由于元数据在结构和内容上发生了大量的变化。原来用户模式中的用户模式字段与元数据中的映射关系将不再适合，若直接将这些关系直接删除的话，那么就需要用户模式的制定者重新建立模式字段与元数据映射，这样就会造成大量不必要的繁琐工作。那么如何处理这一问题呢？我们提出了一种半自动化的方式完成这些链接工作。当数据源更新完毕并将该数据源的元数据导入到元仓库后，系统会自动的提取原数据源中与用户模式字段已经建立了映射关系的元数据m，并将该元数据与更新后的元数据n进行核对。如果更新后的元数据n中有与m中的元数据名称和类型完全相同的元数据时，我们先自动的将这样的元数据与相应的用户模式中的字段进行映射，并将映射信息提供给用户模式的制定者（生物学家），由他们来最终确定是否保存这样映射，还是将该用户模式字段与其它的元数据进行关联或删除该映射。倘若更新后的元数据n中有与m中的元数据名称和类型完全相同的元数据时，则将该映射关系删除，并把涉及到该关联用户字段暂时存放到一张临时的表里，并将这些信息提供给用户模式的制定者，由他们来最终确定是悬挂该字段，还是将该用户模式字段与其它的元数据进行映射。具体的流程如图3-5所示。 图3-5 重建用户模式字段映射流程图4未来的展望本课题来源于863计划课题“人类肝脏蛋白质组生物信息学研究”的一个子课题“蛋白质组学元数据仓库的管理与维护” 。课题的最终目的是使用本体来标注数据源的元数据来解决语义理解，以及利用本体进行推理，体现各数据源元数据之间在概念层次上的关系，进行智能化的数据挖掘，进一步扩展应用的范围6。那么如果数据源更新，元仓库中的数据发生变化，就会有部分本体与元数据的映射产生不匹配或悬挂的问题。如何解决该问题和自动化的实现本体的标注工作，以及元数据删除后如何有效的整合和利用删除后的空间，需要课题组在将来进行更进一步的研究。5 结束语本文给出了在元仓库的基础上删除元数据的方法，以及解决了由于删除元数据和生物数据源更新时而带来的元仓库中元数据的变化，而引起的用户模式与元数据的映射等问题。课题组将来通过本体标注元数据后，元仓库发生变化时，解决本体标注悬挂的问题正在考虑解决中，相关工作会在后续的文章中介绍。参考文献1 黎建辉，佘怀化，阎保平. 基于元数据的关系数据库语义集成方法. 计算机工程J, 2008, 34(6): 54-56.2 林 毅，宁 洪，王 挺，等 .基于元数据的数据