数据库远程数据上报策略及实现

数据库远程数据上报策略及实现

武汉大学计算机学院(430072) 邓其军 牛晓太 余小鹏
武汉湖北教育学院(430076) 刘姜涛

在很多数据库应用程序中，都要用到数据远程上报的功能，如人口普查、城市危险源及事故普查、各种考试数据上报等。这些应用程序都需要将各下级部门的特定数据提取出来，通过各种方式上报到上级部门，再由上级部门进行汇总。上级部门在进行数据汇总时，有时候只需要考虑新数据的插入问题。如养路费征收IC卡网络管理系统，此时下级的每条数据记录是输入的，在数据上报之后不会发生已经输入的数据记录在下级被修改，从而上级也要发生相应修改的情况。此时，用该文提到的用BulkCopy方法就可以满足其需要。但是有的情况下，上级部门的数据汇总必须考虑下级数据所有的变化情况(新数据的插入、已有数据记录的修改、已有数据记录的删除)。此时，用BulkCopy方法就无法对数据进行修改与删除了。除非在数据上报时，下级部门将其所有数据都拷贝一份上传；上级部门在数据接收时，将该下级部门的历史数据全部删除，再导入其数据，才能保证与下级的数据的一致性。显然，这样的处理方式，必然导致数据的传输及处理量大增，而且很多都是做无用功，特别是在很多情况下需要用电话拨号网络进行数据传输的时候，其效率非常低。

1总体策略

在作者参与开发的"城市重大危险源普查及事故管理系统"中，其下级部门为各企业，上级部门为政府安全生产管理部门。在该系统中，企业定期向政府部门上报相关的危险源及事故信息。其中危险源是指企业各种锅炉压力容器、加油站等可能发生危险的地点分布情况。这些危险源信息可能被增加、修改或删除。系统开发语言为VC++6．0，企业端数据库为Access或SQL Server，政府端数据库为SQL Server，用OLE DB方式连接数据库，用嵌入式SQL Server语言直接操作数据库数据。上下级之间的数据传输方式为软盘、邮件和FFP三种方案。本系统主要采用了数据库日志及数据压缩技术，尽可能地减少数据传送量。

数据库日志就是在用VC的嵌入式SQL Server语言进行数据库操作时，将SQL Server脚本经过适当的转换后记录在一个数据库日志表(pubTbDBLog)中。上报数据时只需要提取pubTbDBLog表的部分内容。政府端接收后，按顺序执行上报的SQL Server脚本，即能实现与企业端的数据完全一致。

数据上报与接收的流程如图1所示。

2数据库日志操作

数据库日志操作的目的是保存SQL脚本，即将企业端对数据库的操作记录下来，存放在数据库日志记录表pub-TbDBLog(nld，STrTable，strSQL，strOperType，strGuid，dtOper，beUped)中。其中nId为主键，自动增量；strTable为SQL操作的数据库表名；strSQL为对数据库进行操作的脚本；strOperType为操作类型，包括插入、修改、删除三种；strGuid为一个GUID值(惟一ID号，长度为32位字符)，用来惟一标识一条记录；dtOper为操作时间，取每条记录生成(即对数据库的每操作)的当前时间；beUped标识当前记录是否已经上报过。

2．1数据库操作的要求

在本系统中，当对需要上报数据的表进行操作时，必须满足如下要求：

(1)数据库记录的修改(包括添加、删除、修改)必须在程序中直接用嵌入式SQL脚本实现。

(2)执行数据库操作必须使用一个全局函数ExecuteSQLCmd(CString strCmd)，其中strCmd为执行数据库操作的SQL脚本。该函数将脚本写入pubTbDBLog表。

2．2保存SQL脚本的过程说明

下面以企业端用户向危险源记录表rsiTbSource(nID，strEnNo，sfrName，strSite，strRank，strType，dtSetUp)中插入一条危险源记录为例，说明保存SQL脚本的操作过程。

(1)用户通过对话界面输入危险源信息，其中strEnNo表示企业编号，strName表示危险源名称，strSite表示危险源位置，strRank表示危险源等级，strType表示危险源类型，dtSetUp表示危险源建立日期。另外nID是一个自动增量，作为主键标识，没有具体意义。rsiTbSource表除了以上字段外，还有其他字段，本处为简化而省略。 (2)用户输入信息完毕，点击"保存"命令按钮，系统将用户输入的信息拼成一条SQL脚本，如：CString strCmd=INSERT INTO rsiTbSource(strEnNo，strName，strSite，strRank，
strType，dtSetUp)VALUES('420124098987001'，'热水锅炉'，'武汉市武昌区武汉大学二区'，'二级'，'锅炉压力容器'，'2003-7-21')。

(3)系统调用ExecuteSQLCmd函数，包括以下(4)、(5)、(6)的内容。

(4)对strCmd进行解析，同时生成一个32位的GUID值，将strCmd修改为strCmd=INSERT INTO rsiTbSouree(strEnNo，strName，strSite，strRank，strType，dtSetUp，strGuid)VALUES('420124098987001'，'热水锅炉'，'武汉市武昌区武汉大学二区'，'二级'，'锅炉压力容器'，'2003-7-21'，'ed32wq3ddvervgjl6tgj8fjFFVBfgwgw')。

(5)执行脚本命令(不使用ExecuteSQLCmd函数)。

(6)如果第(5)步执行成功，则向pubDBLog表插入一条记录(strTbSource，strCmd，i，ed32wq3ddvervgjl6tgj8fjFFVBfgwgw，2003-7-21，0)，其中的strCmd是第(4)步中strCmd的所有字符。

3数据上报

数据上报是将pubTbDBLog中符合条件的记录提取出来，进行压缩后传给上级。

3．1上报数据提取 在提取数据前要对pubTbDBLog表中的记录进行一些预处理。由于每次对需要上报的数据库表的操作都被记录在了pubTbDBLog表中，有些记录(为了方便，称pubTbDBLog表中的一条记录为"记录"，称需要上报的数据表中的一条记录为"数据")是不必要的，上报之前需要进行简化。例如：向数据库表中插入一条数据，后来对该数据进行了若干次修改，删除该条数据。此时，pubTbDBLog中有三个以上与这条数据相关的记录(它们在pubTbDBLog表中的strGuid字段值相同)，其strOperType值分别是"i"、"u"、"d"。如果这三个记录都被上报，并在政府端被先后执行，其结果还是没有该条数据，白白浪费了执行三次SQL命令的时间。

因此，如果与某个strGuid值相关的数据被删除，则在政府端只需要执行删除操作，即与该strGuid值相关的pubTbDBLog表中的记录只需要上报一条删除的操作即可。实现对这种情况的pubTbDBLog表简化的SQL脚本如下：

DELETE FROM pubTbDBLog WHERE strOperType<>'d'
AND strGuid IN(SELECT DISTINCT a．s strGuid
FROM pubTbDBLog a WHERE a．strOperType='d')

完成简化后，即可将pubTbDBLog中符合条件(提取数据的条件是：未曾上报过的数据或指定时间范围内的数据)的数据提取出来放入一个文件中。存放导出数据的文件可以是Access数据库表，或者是文本文件。作者用的是Access数据库表，它经过压缩解压缩后能在政府端直接取Access表中的SQL脚本执行；也可以用文本文件，但上报时需要将符合条件的pubTbDBLog表记录放入一个临时文件，再用bulkCopy的方法存入文本文件。在政府端用bulkInsert的方法向一个与pubTbDBLog相同结构的表导入数据，再执行该表的记录中的SQL脚本。

3．2数据文件压缩

通常情况下，企业端向政府端报送数据是经过电话拨号网络进行的，其传输速率较低。因此，有必要对存放导出数据的Access文件或文本文件进行压缩后再传递。本系统使用了WinZip的数据压缩与解压缩接口。其过程如下(假定字符串filepathname指向需要压缩的文件)：

4数据接收

政府端数据接收的工作包括三个步骤：选择文件、解压缩、导入数据。

4．1选择数据文件

对应于企业端通过磁盘和邮件上报的数据，政府端首先需要将其存放到本地计算机的硬盘上，再进行数据文件选择和接收。

选择文件时，调用打开文件对话框，再由用户选定一个或多个指定类型(*．cmp)的文件。对于每一个选中的文件，系统对其执行解压缩和导入数据的操作。

4．2解压缩

与前面所述的文件压缩一样，解压缩与采用了WinZip提供的接口。其过程如下：

4．3导入数据

从一个被解压缩后生成的Access数据库向政府端数据库导入数据的过程为：连接该Access数据库；按先后顺序从该数据库表pubTbDBLog中提取记录；执行该条记录的SQL脚本。下面只对SQL脚本的执行进行说明。

对于删除和修改操作，SQL脚本可以直接执行。因为如果上报了重复的数据，即使某条记录已经被删除或修改，再执行同样的删除或修改操作，SQL命令的执行也不会造成语法错误或数据错误。

对于插入操作，SQL脚本则不能直接执行。因为如果上报了重复的数据，则直接执行插入会使数据库中存在二条同样的数据。因此，先要执行删除操作，将对应的数据删除(由于pubTbDBLog表中有二个字段记录了SQL脚本对应的表名和GUID值，删除操作很容量执行)。即使该数据不存在，SQL命令的执行也不会造成语法错误或数据错误。

5结论

本文讨论的基于数据库操作日志和数据压缩的数据上报与接收技术，有着很强的通用性。对于任何一个应用系统，只要在数据库中建立一个数据库日志表，并且下级端执行数据库操作时满足2．1中提及的二个条件，就能使用。特别是对于需要上传的数据涉及的表较多、下级端对数据经常需要修改、上下级数据要求较高度的一致性的情况，其优点更加明显。 本系统的数据上报与接收策略也有一些不足之处。例如，企业端pubTbDBLog表中数据的导出，可能用bulkCopy效率更高；数据导出与接收时，暂时还没有使用多线程技术等。这些都需要在以后的工作中进一步完善。