专利名称：：跨平台移动存储介质数据系统的制作方法
技术领域：
：本发明涉及移动存储介质的数据管理技术，特别涉及一种跨平台移动存储介质数据系统。
背景技术：
：在计算机软盘淘汰后，基于外接移动存储介质的数据管理消失了，取而代之的是网络等新一代数据管理系统。可是随着各种高容量存储卡的出现，以及一些行业信息管理的数字化，基于CF卡、SD卡等移动介质的数据管理系统再次得到广泛应用。不过早些时侯的应用模式一般只是把移动存储卡作为数据备份，使用模式一般都是通过親器内部的Flash芯片等存储介质进行数据库存储，搡作完成后再将部分数据内容导出到外接存储卡上进行备份，以后再用还需再从外接存储卡导入到本机数据库。这种方式操作麻烦，而且并未使得本机的存储空间得到扩展。机器内存有完整的数据库，并未起到邇过卡这种移动介质增强安全性和独立性的作用。而且由于操作员的误搡作，可籠忘记备份数据，再次导入时就会造成后面操作的数据永久性丟失，这都不利于数据的管理。后来，随着管理系统设计的进步，很多应用系统开始自己设计卡中的存储格式，实现了基于移动存储介质的数据管理方案，使得数据完全存储于卡中，卡中数据实现了独立管理。这种方案往往能很好的麄足系统平台的某种应用，但由于是专门设计的存储结抅，包含数据庳的部分功能，几乎没有任何扩展性，更不具^^跨平台应用的特性。面且由于是专门定制的系统，价格一般都比较昂贵，不适合推广。
发明内容本发明的目的在于提供一种跨平台移动存储介质数据管理系统，该系统具有较好的扩展性能，并且适于跨平台应用。本发明跨平台移动存储介质数据管理系统，包括位于移动存储介质中的嵌入式数据库文件模块，以及位于应用平台中的与所述嵌入式数据文件模块相对应的数据库嵌入式接口库模块。优选地，所述嵌入式数据库文件模块中所使用的数据库为SQLite。SQUte是一个嵌入式SQL数据库引擎。和大多数SQL数据库不同，SQLite并不需要一个独立的服务进程。SQLite通过直接读写普通磁盘文件进行数据操作。包含多表、索引、触发器和视图的完整SQL数据库被保存在单一的磁盘文件中。数据库文件是跨平台的，也就是说在32位平台的操作和64位的操作系统之间、在大端(big-endian)和小端(l加e《ndian)数据结构的平台之间数据可以自由拷贝。SQLite是个十分紧凑的库。在所有功能打开时，当编译器处于最优设置时，库文件大小可以小于250KB。如果可选功能被省略的话，库文件的大小甚至可以降到180KB以下。SQLite可以运行在最小16KB的堆栈空间和100KB的堆空间上。如此小的资源开销，使得SQLite在内存资源有限的小型产品中应用十分广泛，如手机、PDA、mp3播放器等。SQLite在内存使用和速度上找到了很好的平衡点，提供的内存越高，数据库能够运行得越快。当然，低内存的环境下运行，表现也是十分出色的。所述的移动存储介质为CF卡、SD卡或U盘等任何移动存储介质。所述的应用平台包括但不限于Windows、Linux、嵌入式Linux或WindowsCE。本发明还提供一种跨平台移动存储介质数据管理方法，该方法包括在移动存储介质中植入一嵌入式数据库文件模块，在应用平台中植入一与所述嵌入式数据库文件模块相应的数据库嵌入式接口库模块。所述嵌入式数据库文件模块中所使用的数暴库为SQLite。本发明还提供一种将SQLite移植到应用平台的方法，该方法包1)下载SQLite源代码；2)安装配置相应平台的编译器；3)针对不同平台的编译工具，创建合适的工程文件；4)编译工程，生成最终的库文件；5)针对某些特殊的平台，对库文件进行优化裁剪。通过上述方法，本发明实现了将SQLite自Windows、Limix、嵌入式Linux以及WindowsCE等平台的移植。本发明提供的跨平台移动存储介质数据管理系统，实现了移动存储介质的跨平台数据管理，其实现成本低廉，适合推广使用》图l是跨平台移动存储介质数据系统模型-具体实施方式下面通过实施例进一步说明本发明，但不应理解为对本发明的限制。实施倒l跨平台移动存储介质数据系统1、系统的设计数据库从应用可以分为通用数据库和嵌入式数据库，从实现形式可以分为文件型数据库和基于C/S架构的数据库。由于应用是基于各个平台的嵌入式移动终端，大型的分布式数据库显然不适合。由于应用的对象是移动存储卡，而非将数据國定保存在某个特定的存储器中，基于c/s架构的嵌入式数据库显然不如基于文伶型的灵活易用，一般只能通过导出为其他格式文件的方式进行外部存储。而且，一般基于c/s架构的嵌入式数据库需要在嵌入式移动终墙上启服务，容量和系统资源消耗都相对比较大，不适合嵌入式终端使用，而且从性能角度看，优势又不明显，甚至不如文件型数据库。因此，系统采用基于文件型的嵌入式数据库。具体地说，采用嵌入式数据库文件模块用于存储嵌入式数据库文件，通过数据库嵌入式接口库模块实现对存储在嵌入是数据库文件模块中的数据库文件进行管理。如图1所示，存储卡上保存嵌入式数据库的文件。存储卡可以是CF卡、SD卡、U盘等任何移动存储介质。存储卡插到各个平台的读卡器上，通过驱动被系统识别，并挂载上相应系统的目录，使得搡作系统上层的应用程序能够读出保存在存储卡上的数据库文件》这种设计将平台之间的差异转化到硬件和驱动层上，使得基于数据库应用层软件的跨平台更易实现。应用的开发人员可以全心放在上层的逻辑上，不必了解底层的驱动和硬件，底层的改动也不会影响上层的软件,软件的更独立性好。系统构建时，首先基于各个应用的平台，移植数据库的嵌入式接口库。一般都以动态库或者静态库的形式生成，然后开发应用软件，调用生成好的接口库，实现对挂接上外部存储卡的路径下嵌入式数据库文件的搡作。图中粗箭头表示的是存储卡的硬件连接以及驱动挂载，虛线箭头表示的是应用层数据库文件的操作。现有的文件型嵌入式数据库产品中最有影响力的产品是BeikeleyDB和SQLite。这两个产品都是十分优秀的产品，功能和性能上都各有千秋，而且发展都很迅速，版本更新很快。近两年，对文件型嵌入式数据库产品的研究很热门，对这两款产品研究比较的文章很多，这两款数据库主要的特征比较总结如下表iBerkeleyDB和SQLite特征对照表SQIite代码开放开放开放<table>tableseeoriginaldocumentpage7</column></row><table>这两款嵌入式数据库的性能都非常优秀，基于不同条件下的评测互有胜负。SQLite由于支持SQL,需要对数据库的操作进行解析，因此要比直接通过函数直接搡作数据的BerketeyDB稍徽浪费一些效率，多数的评测的结果是SQLite速度比BerkeleyDB稍慢，不过差距很小，而且可能由于版本可测试条件的不同，有些测试甚至得出SQLite速度优于BerkdeyDB的结论。从实际嵌入式终端应用角度，这两款数据库都非常的快，一般的嵌入式应用人不会感到任何的时间延迟，因此在处理数据的性能上这两个数据库打了平手。在代码开放方面，这两款数据库都是完全开放源代码的，体积都很小，都非常适合嵌入式软件的应用。对于SQL这种标准语言的支持方面，显然SQLite占了上凤。尽管BerkeieyDB因此在效率上有徽小的提高，可是这显然不利于产品的普及，尤其是不利于开发基于SQL的应用(如数据库管理系统DBMS)。在数据库的容量支持方面，BerkeleyDB优势明显，高出SQLite近i00倍。可是这种优势在本系统内是无法体现的。现今较大的存储卡的存储单位还在GB的数量级，离TB的容量还差的很远。最后是产品很关心的费用问题(因为这个关系到产品的成本)。BerkdeyDB是对于个人应用是免费，但对于商业应用却要收取不菲的费用，相比较SQLite的完全免费，劣势就比较明显了。综合比较，最终系统选择SQLite作为系统的嵌入式数据库。2、不同平台下SQLite的移植系统框架搭建好、嵌入式数据库确定后，下一步就是让SQLite嵌入式数据库能够应用到不同的嵌入式操作系统平台中。SQLite移植的流程大致如下1)下载SQLite源代码；2)安装配置相应平台的编译器；3)针对不同平台的编译工具，创建合适的工程文件；4)编译工程，生成最终的库文件；5)针对某些特珠的平台，对库文件进行优化裁剪。当然，上面的步骤1)、2)并不是必须的。下面以嵌入式Linux平台和WindowsCE两个嵌入式操作系统平台为例详细说萌SQLite的应用移植方法。SQLite在Linux下的移植这里介绍SQLite在基于ARM的嵌入式Linux下的移植步骤。按照上面介绍的移植流程，首先需要下载SQLite的源代码。SQLite的官方网站提供了非常丰富的代码资源来方便移植。我们可以直接下载SQLite的C代码，自己创建链接库工程，显然比较麻烦》此外，SQLite的网站还提供了针对Linux的包含生成makefile配置文件的工程。通过这个工程，只需稍加修改，就可以将SQLite移植到嵌入式Linux上了。当然，针对PC的搡作系统，SQLite已经提供了已经编译好的库文件，可以直接下载使用。这里主要讨论嵌入式的移植，就不作详细介绍了。从官方网站下载完最新的SQLite源代码包。将下载的代码包解开，生成sqlite目录，另外新建一个与sqlite目录平行的同级目录,如sqlite-arm-Linux。这主要是为了将编译结果单独存放。由于这个移植的处理器是Intel的XScale处理器，调试用的是ARM的交叉编译器ami-linux-gcc，因此首先需要配置好交叉编译器。确保PATH变量中已经包含交叉编译工具arai-Linux-gcc。可用"echo$PATH"命令查看。如果PC机的Linux操作系统尚来安装交叉编译工具arm-Linux-gcc，那么要先在网上(如http:〃www.cmtekchina.com/)下载进行安装，并把arm-Linux-gcc添加到PATH变量中。下一步修改sqlite/src/sqlitelnUi。为了在ARMLinux下能正常运行SQLite，需要对sqlite/src/sqlitelnth作一定的修改，以确保btree(B树)有正确的变量大小，如"ptf，和"char".不同体系结构的Iimix,如x86和ARM，会有些差别.对于ARMLinux可以找到如下部分乡ifedeflNTPTRJTYPE#tfSQLlTE—PTR—SZ=4#defineINTPTR—TYPEint#eisesMefineNTPTRJTYPJEl加gjongfendif酋加上一句^defineSQUTE_PTR_SZ4这样后面的"typedefINTPTR_TYPEptr;"就是定义的"int"类型，而不是"longlong"。因为lcmgtong是GCC等编译器所特有的类型，不被arm-limix-gcc支持，如果不做此修改，会报编译错误.下面修改configure文件，进行一些配置.在sqlite目录下的configure中找到如下4处,并将其注释掉.这样做的目的是让canfigure不去检查交叉编译环境.请你自己确定自己的"aim-linux-"系列命令在你的PATH环境变量中.如你可以输入"atm4inux-"再按"TAB"键，看其是否自动完成命令行。#if*lcross_c(Hnpfling，="，w;th#"echo，tes—me:127l0:ot<k:unabletofindacompilerforbuiiidingbuildtookw>&5edw*las—me:enor:xu^ietofindacoUerfortx^idingbuildtoolsb&2;》#《(exitl);exitl;》;》tfse#((echo"，as一13264:orrar:cannotcheckffileiradsteiK^1(A1encrossconqpiliiig^&S#edu>"las—me:arror:(^tnnotcheckforfileexistencewhencrossc<mq>iiing*>&2;}#《(exitl);exitl;};》#elseAcross—aMtq>ilii^=y^&&弁《《ediolas—me:，3464:tot:cannedd^ckf<*fileexistencea^micn>^coai^pfling*>&5#echosias—me:ern^r:c^ffic^chedcfor份e^ci^icewhmcto^con^Hng^&2;》《(cxitl);exitl;W#test"lo*oss—compfling"=7es&&#".ecto"as_ine:13490:error:cannotcheckfcnrfiteeid^enoewteicrosscompiling"^"&5#edK>"las_me:enrorcannotciKckf议fiJeexistKorosscompiling">&2;;#〖(exitl);exitl;);)把它们都注释掉后，就可以进行configure了.在sqlite，-Linux目录下,输入命令'/sqlite/configure—bo^ann-Linux然后,在刚才自己新建的sqUte^ami-Linux目录下，将生成Makefile和一个libtool脚本,在执行make命令时将会用到它们.下面修改M论effle文件。将代码行BCC-aim-linux-gcc~g~02改成BCC-gcc-g^02。另外，一般是以静态链接的形式将sqlite放到ARMLinux的硬件板上运行的，所以继续修改Makefile,找到标记为"sqlite:"的代码段，将其中的libsqlite.la改成.111>8/1)一化么傲完上述修改，用make生成sqlite、libsqtite.a、Ubsqlite.so.其中Ubsqlite.a、1*8<111&.80文件都在./.1>8/下。此时生成的sqlite文件是还未strip过的，你可以使用命令"fflesqlite"查看文件信息。用幼ip处理过后，将去掉其中的调试信息，执行文件大小也将小很多.命令如下aniHlinux-stripsqlite(strip是Linux/UNIX下执行文件的减肥工具，能清除执行文件中不必要的标示符及调试信息，可减小文件大小而不彩响正常使用.文件一旦strip后就不能恢复原样了，所以strip是一个减肥工具而不是压缩工具.而且，被strip后的文件不包含调试信息，就不能用dbx来调试程序了.ann-linux-strip是用于嵌入式ARMLinux下的工具.)这样Sqlite已经在ARMLinux下跑了起来，然后就可以基于此进行进一步的应用开发了.SQLite在WindowsCE下的移植针对Windows系列平台，SQLite没有提供统一的工程配置文件，只提供了代码。需要根据不同平台自己创建工程.WindowsCE平台的应用软件开发最常用的开发工具是EVC和VisualS加dio。前者的最后发布的版本是4.0,多用于PlatfonnBuilder4.2以前版本的应用程序的开发，后者目前比较流行的版本是2005，最新的版本应该是2008。多用于PlatformBuilder5.0以后版本的应用程序的开发。这里以EVC4.0为例。首先下载源码资源包，里面只有.c和.h两种格式的文件，并解压到一个目录中。然后在Windows的开发环境下安装自己板子定制的SDK。这个SDK是用PlatfonnBuilder根据自己的开发板的硬件配置和功能需求定制的开发包。安装完会在EVC的编译器选择下找到支持该板子的选项。在EVC中新建一个工程。可以根据应用，创建静态库工程或者静态库工程。这里以动态链接库为例。在工程类型中选择动态链接库，输入工程文件名"sqlite3"，在"CPU类型"中选择ARMV41，然后下一步，选择一个空的动态库工程，选择"完成"即可。然后在左侧工程文件的框内加入下载的源码文件进来。编写Windows平台下的Dll动态链接库还需要接口定义def文件。可以根据需要将自己用到的SQLite接口函数列出，也可以从网上找到别人写好的包含所有接口函数的文件。将文件编写好也同样加入工程。这时如果我们直接进行编译，往往会出现很多错误。这主要是源码是针对所有平台发布的，有些需要调用的外部库或者代码不是Windows直接提供的，而且也不需要。我们只要把这些文件挑出来，从工程中移除就可以了。要移除的文件和SQlite不同时期发行的版本有关，越晚发布的版本支持的功能越多，越强大，需要移除的文件也就越多。但对于基本功能，SQLite都保持了很好的兼容性。以版本3.4.1来说，需要移除的文件有三个shell.c,telsqlite.c，icu.c。shell.c是用于生成sqlite命令行管理工具的，由于我们建立的是动态链接库的工程，并不生成可执行文件，园此这个对于我们是没有用的。tclsqlite.c是使得编译出来的库能够支持TCL脚本。由于TCL脾本多用于Linux/Unix中的网络编程，对于WindowsCE下的嵌入式编程是用不到的，因此我们也不需要这个文伶。icu.c是让SQLite库和ICU库("InternationalComponentsforUnicode",—个用于处理Unicode数据的开源库)融合。这个文件是有些老版本的SQLite中没有的。由于未使用ICU库，我们同样将这个文伴移除。下面点"build"按钮就可以生成板子专,塌的SQLite动态链接库文件了。Windows通用平台下的编译和WindowsCE平台的基本一致，只是编译的开发工具采用VC或者VisualS加dio，并且不需要定制SDK。SQLite的官方网站提供了编译好的通用Windows平台的SQLite库，可以直接下载使用，这里就不复述了。3、系统应用验证为了验证系统设计的可行性,笔者在Windows,Linux、嵌入式Linux、WindowsCE几个平台下分别进行了SQLite的移植，并且利用SQLite提供的库文件的接口函数，开发了简单的数据库管理验证系统，对同一张CF卡中的同一个数据库文件进行了增斓査改搡作。系统验证结果说明见下表表2不同平台测试结果验证表操作系统WindowsLinuxWindo郷CE嵌入式Linux<table>tableseeoriginaldocumentpage0</column></row><table>平台生成的数据)SQL数据查询(其他平台生成的数据)通过通过通过通过由上表可见，同一个CF卡的数据库文件在不同的平台的环境下实现了标准SQL的数据搡作。不过基于本系统进行跨平台软件的开发需要注意一个问题一一字符编码。尽管Unicode编码已经被很多操作系统支持，并成为系统默认的编码方式，可是很多应用还会采用其他编码方式，比如简体中文版的Windows系统通用的软件一般都是釆用的GBK编码。在不同平台的调试过程中会出现乱码问题。此外，SQLite数据库的函数接口对于数据的参数一般都是(:1131*字符串型，这种数据类型的字符串是以8bit0(即、0，)为字符串结束符的，而最通用的Unicode(UTF-16)编码的字符长度是16bit,对于序号考前的字符(如原标准ASCII字符)髙位8bit为0，编程时会造成字符串意外中断的情况，使得出现相应字符时数据处理出错。为解决以上问题，各个平台应用开发进行数据处理时应进行编码统一处理，将相应平台的数据编码格式转化为Unicode(UTF-8)格式能够很好的解决此问题。经测试，采用统一的Unicode(UTF-8)编码存入数据库，各个平台的应用都能正确解析出各种汉字、符号，甚至是不可见加密字符。权利要求1.一种跨平台移动存储介质数据管理系统，包括位于移动存储介质中的嵌入式数据库文件模块，以及位于应用平台中的与所述嵌入式数据文件模块相对应的数据库嵌入式接口库模块。2、如权利要求i所述的移动存储介质数据管理系统，其特征在于，所述嵌入式数据库文件模块中所使用的数据库为SQLite。3、如权利要求2所述的移动存储介质数据管理系统，其特征在于，所述的数据库嵌入式接口库为SQLite的嵌入式接口库。4、如权利要求"3任一项所述的移动存锗介质数据管理系统，其特征在于，所述的移动存储介质为CF卡、SD卡或U盘。5、如权利要求1~3任一项所述的移动存儲介质数据管理系统，其特征在于，所述的应用平台为Windows、Limws、嵌入式Limix或WindowsCE。6、一种跨平台移动存储介质数据管理方法，其特征在于，在移动存储介质中植入一嵌入式数据库文件模块，在应用平台中植入与所述嵌入式数据库文件模块相应的数据库嵌入式接口库模块，通过嵌入式接口库模块管理嵌入式数据库文件模块中的嵌入式数据库文件。7、如权利要求6所述的方法，其特征在于，所述嵌入式数据库文件模块中所使用的数据库为SQLite。8、如权利要求6所述的方法，其特征在于，该方法还包括将SQLite的嵌入式接口库移植到各应用平台上。9、如权利要求6^8任一项所述的方法，其待征在于，所述的应用平台为Windows、Linux、嵌入式Linux或WindowsCE。全文摘要本发明提供了一种跨平台移动存储介质数据管理系统，包括位于移动存储介质中的嵌入式数据库文件模块，以及位于应用平台中的与所述嵌入式数据文件模块相对应的数据库嵌入式接口库模块。嵌入式数据库文件模块中所使用的数据库为SQLite，数据库嵌入式接口库为SQLite的嵌入式接口库。本发明跨平台移动存储介质数据管理系统，实现了移动存储介质的跨平台数据管理，其实现成本低廉，适合推广使用。文档编号G06F17/30GK101266622SQ20081010600公开日2008年9月17日申请日期2008年5月7日优先权日2008年5月7日发明者吴巍荪,邓中亮申请人:北京邮电大学