元仓库与源数据库的元数据信息的同步策略的研究与设计

1、元仓库与源数据库的元数据同步策略的研究与设计1 引言近年来，随着蛋白质组学技术的普及和基础研究的深入，生物信息学正面临一系列新的挑战。对高度复杂的海量蛋白质组学实验数据进行存储、共享与整合即是其中最重要的问题之一。各个数据源在物理上的分布、结构上的互异以及语义上的差异成为了对实验数据进行共享与整合的三大瓶颈。各个数据源的元数据不仅包含了数据的名称、类型等信息，还提供了数据的上下文描述信息，如果将各数据源的元数据按照一个统一的标准提取出来集中存放在一个元数据库中，将集成的元数据信息与用户建立的用户模式的相应字段进行关联，就能够通过解析用户模式得到对应的各数据源数据信息；将获得的各数据源查询结果进

2、行连接、合并等操作，并按用户模式进行输出，就能够实现数据的共享和整合。根据以上分析，我们课题组提出了基于元数据的蛋白质组学数据资源共享与整合方案，并在此基础上已经实现了针对关系数据库中各异域异构的源数据库中的元数据信息集成到CWM的元仓库模型中。但是元仓库的管理员并不能控制源数据库（以下的源数据库均为关系数据库）中的元数据的变化，如果源数据库的元数据信息发生了改变，而元仓库不能进行及时更新同步的话，就有可能造成元数据的悬挂，对用户的查询结果产生不可估量的影响。我们如何捕获源数据库中的结构变化信息，并将该元数据追加到元数据仓库中去，成为我们解决问题的重点。2 现有同步策略的分析与选择对象变化捕获

3、是数据同步的基础，它直接决定了数据同步的更新方式和选时方式。变化捕获不仅要获得复制对象的变化序列或当前映像，还要在对等式复制时提供尽可能详细的控制信息。通过对当前使用捕获方法的综合分析，目前主要有六种基本变化捕获形式，它们是：(1)基于快照法；(2)基于触发器法；(3)基于日志法；(4)基于API法；(5)影子表法；(6)变更轨迹表法。然而这些变化捕捉的方法均是捕捉数据库中数据的变化信息，我们要求获得的则是源数据库结构的变化信息，虽然这些方法和我们捕捉的对象不同，但是我们可以借鉴它们的原理和方法。由于基于快照发、影子表法和变更轨迹法的核心思想是变化后的数据库信息与原数据库信息进行比较，最终得出

4、变化的结果，这种方法效率比较低下，而且这些方法也不太适合对数据库结构变化的捕捉，所以不采用此种方法。基于API法是，主要应用在小型的非关系型的数据库中，而我们主要面对的源数据库对象都是关系数据库，因此这种方法也不适用于我们。基于触发器法和基于日志法这两种方法运行的效率和通用性都比较的高，但是首先由于基于日志法的实现方法相对而言比较复杂实现的难度较高。其次，是由于现在各主流的DBMS如SQL Server，Oracle，MySQL等都提供了DDL（该触发器主要在响应数据定义语言语句时执行存储过程）的触发器。又考虑到原课题组的成员实现的元数据的导入是通过分析SQL语句实现的，而通过DDL触发器能够

5、获得数据库的变化信息也是以SQL语句形式保存的，综合以上三点，我们最终选择了基于触发器法，来捕获数据库结构的变化信息。这样我们可以利用DDL触发器来记录类似“用户建立表”这种变化的操作。3 基于DDL触发器的元仓库与源数据库的元数据信息同步策略的设计经过以上分析，我们最终选择了基于DDL触发器的元仓库与源数据库的元数据信息同步策略。该方法首先通过各关系数据库的DDL触发器捕获到其元数据的变化信息并保存到源数据库结构变化信息表中，当元仓库的管理者向各数据源发送同步请求时，将信息表中的信息经过SQL语句清理缓冲器整理后，通过网络传送到管理元仓库的服务器中，元仓库服务器最终经过词法分析器将源数据库的

6、结构变化信息更新到元仓库中。元仓库与源数据库的元数据信息同步的流程如图3.1所示：图3.1元仓库与源数据库的元数据信息同步的流程图3.1 DDL触发器介绍DDL 触发器是一种特殊的触发器，它在响应数据定义语言 (DDL) 语句时触发。它们可以用于在数据库中执行管理任务，例如，审核以及规范数据库操作。使用 DDL 触发器，可以达到以下几种目的：第一，要防止对数据库架构进行某些更改。 第二，希望数据库中发生某种情况以响应数据库架构中的更改。 第三，要记录数据库架构中的更改或事件。与标准的DML触发器一样，DDL 触发器在响应事件时执行存储过程。 但与标准的DML触发器不同的是，它们并不在响应对表或

7、视图的 UPDATE、INSERT 或 DELETE 语句时执行存储过程。 它们主要在响应数据定义语言 (DDL) 语句执行存储过程。 这些语句包括 CREATE、ALTER、DROP、GRANT、DENY、REVOKE 和 UPDATE STATISTICS 等语句，然而这些语句正是引起源数据库的元数据信息改变的操作，所以我们通过DDL触发器就能够方便的获得源数据库的结构变化信息。 3.2 源数据库变化捕捉器的设计首先我们根据源数据库不同的DBMS编写相应的模块，通过该模块调用DDL触发器，将源数据库中的结构变化的信息保存到源数据库结构变化信息表中。以关系数据库中的SQLServer为例，我

8、们可以通过在其内部建立DDL触发器捕获捕获其的结构变化信息，例如：特定数据库中某些表的变化信息-表的删除添加和表的属性字段的更新等，都可以通过DDL触发器捕获到。创建DDL触发器的代码如下：CREATE TRIGGER DDLTest NDATABASEFORDDL_DATABASE_LEVEL_EVENTSASDECLARE data XMLDECLARE cmd NVARCHAR(1000)DECLARE posttime NVARCHAR(24)DECLARE spid NVARCHAR(6)DECLARE loginname NVARCHAR(100)DECLARE hostname

9、NVARCHAR(100)SET data=ChangeCatch()SETcmd=data.value('(/EVENT_INSTANCE/TSQLCommand/CommandText)1',' NVARCHAR(1000)')SET cmd=LTRIM(RTRIM(REPLACE(cmd,'','')SETposttime=data.value('(/EVENT_INSTANCE/PostTime)1','NVARCHAR(24)')SET spid=data.value('(/EVE

10、NT_INSTANCE/SPID)1','nvarchar(6)')SETloginname=data.value('(/EVENT_INSTANCE/LoginName)1','NVARCHAR(100)')SEThostname=HOST_NAME()INSERT INTO dbo.ChangeInfor ( Command, PostTime, HostName, LoginName ) VALUES ( cmd, posttime , hostname , loginname )使用 ChangeCatch() 函数，可以捕获有关

11、激发 DDL 触发器的事件的信息，并将其保存到我们的ChangeInfor日志表中。ChangeCatch() 函数的是返回 xml 值，采用以下的命令进行解析：SETcmd = LTRIM(RTRIM(REPLACE(cmd,'','') 这样当我们对源数据库进行修改时，DDL触发器就会将修改的信息捕捉到，并保存到数据库的ChangeInfor的数据库结构变化信息表中。其结果如图3.2所示：图3.2源数据库结构变化信息表以上的示例，展示了该方法在关系数据库SQLServer中的实现方法，在其它的关系数据库中，我们也可以效仿上面的方法，实现数据库结构信息变化的捕

12、获，在这里就不再一一的赘述。3.3 SQL语句清理缓冲器的设计由DDL触发器捕获的数据库的结构变化信息是将源数据库中所有的结构变化信息，都以SQL语句的形式存储到相应的表格信息中。由于这些信息没有经过筛选和清理，因此这些数据信息是杂乱无章的，如果，我们直接用这些数据信息对元仓库进行更新的话，有可能会造成一些操作的冗余和无效的操作，浪费元仓库服务器的资源。例如：在一个源数据库中，由于某种需要对库中的某个表格A的结构进行了一些相应的改动后DBA又将该表删除。那么无疑DDL触发器会将对表格A的改动操作和删除操作的SQL语句都进行了保存，如果我们直接通过DDL触发器得到的信息与元仓库中的元数据进行同步

13、一致的话，那么原来我们对表A的修改的操作，就得在元仓库中相应的元数据也进行修改，毋庸置疑这些操作基本上对元仓库的最终结构来说是无用功，因为最终该表在源数据库中被删除掉了。像以上这种情况，在源数据库与元仓库的一致性的过程中还有很多。那么我们如何避免这些无用的操作呢？在这里我们设计了一个源数据库的SQL缓冲清理器。我们设计的基本原则是，首先将DDL触发器捕捉到的源数据库的变化信息保存到一张临时的信息表中，当元仓库的管理者向源数据库提出获得变化信息的请求时，先对这些信息进行清理，拿上面表A的例子来说，我们通过缓冲清理器的分析处理之后，我们只需要最终把表A删除的信息传送到元仓库的服务器的相应模块中，进

14、行处理即可。这样我们不但解决了元仓库更新时，无效操作等问题，还减少了网络间数据的传送量。源数据库结构变化捕捉器的总体结构如图3.3所示。图3.3 源数据结构变化捕捉器的总体结构图3.4 元仓库更新的设计当在某一特定的时刻，元仓库的管理者需要对元仓库进行更新时，通过internet获得源数据库的结构变化信息，利用语法分析器对这些结构变化的SQL语句进行语法分析，对于任意关系数据库，我们都可以对其全部DDL语言编写相应的Parser，在词法语法分析的过程中提取相应的元数据，对其进行自动提取与导入。一般情况下针对关系数据库结构变化(引起元数据变化的主要原因)的SQL语句主要有下表所示情况。 表3.1

15、 SQL的数据定义语句操作对象操作方式创建删除修改模式Create SchemaDrop Schema表Create TableDrop TableAlter Table视图Create ViewDrop View索引Create IndexDrop IndexSQL通常不提供修改模式定义、修改视图定义和修改索引定义等操作。用户如果想修改这些对象，只能先将他们删除掉，然后再进行重建。SQL语言用Alter Table 语句修改基本表，修改的内容一般有以下几种情况：Alter Table <表名> 添加： ADD <新列名> <数据类型> 完整性约束 删除：

16、Drop Column <列名> <完整性约束名> 修改： Alter Column <列名> <数据类型> 这样，我们就需要通过语法分析器，分析这些SQL语句的内容，根据具体的内容信息触发相应的模块函数。例如，当语法分析器分析得到某条SQL语句中包含“Create Table”，则自动的调用CreateTable（），将此新建的表及其所属的内容，添加到元仓库的相应的位置中。我们在分析了SQL数据库定义语句后，编写了如下的函数模块：SQL_Create（）、SQL_Drop（）、SQL_Alter（）。在SQL_Create（）函数模块下又包含了CreateIndex()、CreateTable（）、CreateSchema（） 等几个模块子函数。在SQL_Drop（）函数模块下又包含了DropIndex（）、DropTable（）、DropSchema（）等几个模块子函数。在SQL_Alter（）函数模块针对Column的操作包含了AlterAdd（）、AlterDrop（）、AlterAlter（）等几个子函数模块。从以上可以看出，提取函数是按照SQL脚本的BNF范式进行提取的。当提取和转换程序解析到CREATE