基于SQLite的战场态势信息快速存取研究

王 浩，邵高平，胡泽明

（解放军信息工程大学 信息系统工程学院，河南 郑州450002）

0 引 言

随着军事现代化的高速发展，军事通信技术已成为决定战争胜负的决定性因素之一［1］。而集信息获取、存储与分发等功能于一体的移动终端设备是军事通信技术中实现信息交互的重要环节。如美军的 “地面勇士单兵系统［2］”，能够为士兵提供各种实时战场态势信息，并存储历史作战态势信息以供查询，进而为作战人员准确判断战场形势提供可靠依据。由于传统的商用数据库如Oracle、Sybase以及其他桌面环境下的数据库管理系统在嵌入式移动环境下难以发挥优势［3］，而嵌入式数据库因其良好的可靠性和卓越的实时性被广泛地应用于军事、航空航天等高精尖技术及实时性要求极高的领域中［4］，因此在军用移动终端设备中采用嵌入式数据库进行态势信息的存储是一种较为合理的选择。

然而，当前国内一般采用Oracle等大型关系数据库存储战场态势信息并进行相关研究［5，6］，而使用嵌入式数据库进行态势信息的存储研究较少。本文首先概要的介绍嵌入式数据库SQLite，说明选取其作为战场态势信息存储数据库的原因；然后对战场态势信息进行分类，根据各类信息的描述方式提出了一种态势信息存储模型－ITT，并在此基础上借鉴Hash表检索思想对数据库表结构进行设计，进而提出了一种实时查询预处理方法；最后通过仿真实验比较说明了该存取方法的有效性。

1 嵌入式数据库SQLite

SQLite是2000年发布的一款开源的、嵌入式关系型数据库。它没有独立运行的进程，其代码嵌入应用程序代码中，作为托管它的程序的一部分，可以方便地应用于嵌入式系统中。SQLite支持大多数SQL92，简单易用，速度也很快，同时还提供了丰富的数据库接口；不需要特殊的数据库管理器和配置数据库；代码仅需极小的存储空间，完整配置的少于250KB；运行速度比普通的C／S数据库系统更快；移植性强，可以应用于很多嵌入式平台如QNX、VxWorks、Symbian、Palm OS和 Windows CE。由于其源代码完全开放，可以免费应用于任何领域，甚至包括商业应用［7］。

SQLite体系结构简洁，并采用一些独特的方法进行关系型数据库管理。它由划分为3个子系统的共8个独立模块组成，如图1所示。

图1 SQLite体系结构

接口由SQLite C API组成，程序、脚本语言以及与SQLite交互的库文件最终都是通过接口函数与SQLite交互。词法分析器 （tokenizer）和语法分析器 （paraser）协同处理文本形式的结构化查询语句 （structured query language，SQL），SQL语句先被分解为一个个词法符号 （Token），经过评估后以语法树形式重组，然后下传给代码生成器。代码生成器将语法树翻译成一种SQLite专用的汇编代码，这些汇编语言由一些最终由虚拟机执行的指令组成。虚拟机也叫做虚拟数据库引擎 （virtual database engine，VDBE），其独立于顶层操作系统、CPU和系统体系结构。后端由B－Tree、页缓存 （pager）以及操作系统接口组成。一个数据库由多个B树组成－每张表以及每个索引各对应一个B树 （表使用B＋Tree，索引使用B－Tree），B树为VDBE提供O （log N）级时间复杂度的查询和插入，pager根据B树的请求从磁盘读取／写入页面。

目前，市场上有多种为嵌入式应用设计的关系数据库产 品，如 Sybase SQL Anywhere、Oracle TimesTen 和BerkleyDB、Pervasive PSQL以及微软的Jet Engine。一些厂家将其大型数据库产品裁剪开发出嵌入式的变种，如IBM的DB2Everyplace、Oracle的Database Lite和微软的SQL Server Express。开源数据库 MySQL和Firebird也提供了嵌入式版本。所有这些产品中，只有SQLite是开源的、不受许可证费用约束，而且是专门为嵌入式设计的。文献 ［8］通过比较分析证实在嵌入式应用程序开发方面，SQLite是嵌入式轻量级数据库的首选。

2 基于Hash表的态势信息存取方法

选取好合适的数据库后，需要从用户角度并结合所要存储的信息特性设计数据存储方案，以满足用户实时存储与查询需求。下面先对战场态势信息进行分类，然后通过讨论态势信息的描述方式提出了一种态势信息存储模型－ITT，并在该模型的基础上结合Hash表的检索思想对数据库表结构进行了设计，据此提出了一种战场态势信息的实时查询方法。

2.1 战场态势信息分类

战场态势信息主要包括自然环境、与空间密切相关的人文环境、军事目标和作战集团以及作战行动的位置、状态和进展等信息［9］，种类多、数量巨大。战场环境下，作战单元通过其所携带的相关终端设备获取战场综合态势信息。文献 ［10］将态势信息分为地理空间信息、目标属性信息和属性信息这三类，为方便设计存储模型及表结构，将其划分为定位信息、标绘信息、代码指挥信息和战果战损四类。各类信息的说明如下：

（1）定位信息：由定位导航卫星所提供的目标 （敌、我作战单元）位置信息，其主要属性包括目标ID、定位时间、经度、纬度、高程、速度、方向等。定位信息的记录条数在所有态势信息中是最多的。

（2）标绘信息：敌我双方的兵力部署、障碍物位置等需要在终端屏幕上标绘显示的信息。这类信息的主要属性有目标ID、发现时间、经度、纬度、高程、作战任务、地名等。

（3）代码指挥信息：上级下达的文电文书等作战指挥命令信息，其主要属性包括部队ID、发报时间、优先级别、秘密等级、压缩方式、用户报文、发送方式等。

（4）战果战损信息：作战过程中和战斗结束各个作战单元的人员、武器装备损伤，以及击毙击伤敌人员、武器装备数量信息。其属性包括部队ID、发报时间、击伤数量、击伤乘 （武器装备）数、击毙数量、击毙乘数、俘虏数量、俘虏乘数、受伤数量、受伤乘数、牺牲数量、牺牲乘数等。

2.2 存储模型及表结构

态势信息的存储是为了满足用户快速查询的需求，存储模型的设计应充分考虑用户需求，即用户的查询习惯。语法中对于历史事件的描述一般由 “三要素”组成，即“主体对象”、“历史时刻 （段）”和 “事件”。结合2.1中对于四类态势信息属性的说明，可知描述战场态势信息的“三要素”为 “部队编号 （ID）”、“报告时间 （Time）”、“信息类型 （Type）”。这种描述方式符合使用移动终端设备用户的查询习惯，如查询 “某一支部队在某一历史时刻段的某 （几种）类型信息”。结合态势信息该种描述形式，提出如图2所示的态势信息存储模型。

图2 战场态势信息存储模型－ITT

其中虚线框内的1：N表示信息类型和态势信息之间是一对多的关系。按照本文对于态势信息的分类方法，N＝4。依据该存储模型对态势信息进行存储，供作战人员查询检索。根据检索过程中的存储位置不同，检索方法分为内部检索和外部检索；而根据检索的环境的不同分为静态检索和动态检索［11］。而无论哪一种查询，结构中记录的相对位置是随机的，与其关键字之间不存在确定的关系，其检索时需一系列和关键字的比较，且其查找效率与记录个数相关。理想的情况是不经过任何比较，一次存取即能得到所查记录。Hash表正是基于这种理想情况而建立的。在Hash查找中，记录的存储位置与其关键字之间有一个确定的对应关系f，使得每个关键字与结构中的唯一一个存储位置对应。故在查找时只需根据映射函数f找到给定值K的像f （K）。联系态势信息的存储模型，结合Hash表的搜索思想对战场态势信息数据库表设计如下。

表1 hash＿table

表1的作用类似于Hash表。由上述的战场态势信息的描述方式可知，信息生成时间、部队编号和信息类型这3个字段能唯一确定一条态势信息记录。RecordNum与其他三字段为映射关系，即

通过映射函数f得到RecordNum的值，该值作为具体的态势信息的唯一标识符，通过该值即能快速准确定位某一条态势信息记录。设ReportTime的值为x，x∈N＋且x≥103；ID的值为y，y∈N＋且103＞y≥102；Type的值为z，z∈ ｛0，1，2，3｝；RecordNum的值p由下式确定

由式 （2）可知，作战时间、部队编号和信息类型确定唯一的一个p，保证了态势信息标识符不会发生冲突。定位信息表设计如下。

其中表2中字段名称加粗显示的为基本信息字段，无论态势信息属于四类中的哪一类，在其表结构中基本信息字段必不可少。军标库号和军标代号是为实现态势信息在电子地图上的实时显示。其他三类态势信息的表结构类似定位信息。四类态势信息表的主键 （RecordNum）值集合Ui，i，j∈ ｛0，1，2，3｝与 hash＿table表 的 主 键 （Record－Num）值集合Up的关系满足下式

表2 定位报告表position＿report

当需要查询 “某部队在某时刻段的某类型态势信息”时，先通过检索hash＿table表，进而定位到某具体态势信息表，即表hash＿table与四类态势信息表之间存在如图3所示的关系。

图3 四类态势信息表与hash＿table之间的关系

图3中1－∞表示在不同表的两同名字段间实施参照完整性约束 （referential integrity constraint）。即无论在哪一类态势信息表中，其每行的RecordNum值都与hash＿table中某项RecordNum值相匹配。

2.3 实时查询预处理方法

战场态势信息按照2.2中所设计的存储模型存入各类态势信息表中后，还需要进一步对用户的实时查询需求进行考虑。当输入语义为 “查询某一部队在某时刻段的某类型信息”的SQL语句时，其查询处理步骤为：

步骤1 在hash＿table上执行该SQL语句，得到多个信息标识符，用集合U′0表示；

步骤2 将集合U′0中的所有元素作为查询参数，在该类信息表中定位到具体信息。

由于嵌入式系统资源有限，当集合U′0中元素个数众多时，具体态势信息的查询以及查询后在终端屏幕上的绘制显示将耗费很长时间，这并不能满足作战人员的实时性要求 （一般态势信息的查询到显示时间应不大于1.5s）。如当查询某几个作战单元在历史某几个小时内的轨迹信息时，假定终端一秒钟定位一次，集合U′0的元素个数将有可能达到几十万甚至上百万。由于终端屏幕尺寸有限，且只需少量的点 （关键点，其个数与缩放等级相关）即能确定作战单元的轨迹，因此在step2中完全没有必要将所有的定位信息都取出。为此，提出一种采用抽取压缩的查询预处理方法。

令序列x（n）＝ ｛x1，x2，x3，…，xn｝为在hash＿table上的查询结果集合，其元素个数为n，满足用户态势信息查询耗时要求的最大的集合元素个数 （即抽取门限值）为Δ，当n＞Δ时对x（n）进行D倍抽取，即在x（n）中每隔D个点取一个点，抽取后的元素集合为y （m），其元素个数为m；当n≤Δ时不抽取，即抽取压缩函数FD有如下形式

其中y（m）＝x（Dn）。为尽量保证抽取压缩后的序列不过多的损失其细节，抽取倍数D应满足如下表达式

3 实验分析

图4 战场态势信息实时查询流程

为了分析在ITT基础上数据库表结构设计的有效性，以及实时查询预处理方法的性能，针对常规存取策略 （简称方法A）和本文所提的存取方法 （简称方法B）进行比较。在方法A（该方法应用于某大型实装数据库系统）的数据库表结构设计中，不同类型的态势信息存储于不同的表中，每一个表的基本结构如图5所示。

图5 方案A表结构

方法B在方法A的基础上增加了一个能够快速定位的表－hash＿table。执行态势信息查询时，方法A直接在具体类型信息表中取出所有符合查询条件的信息；方法B通过先查hash＿table得到信息标识符集合，经过抽取处理后再在具体类型信息表中取出相应信息。

3.1 仿真设置

为对两方案进行详细分析比较，需要生成模拟态势信息数据库，并进行查询响应时间的测试。仿真实验平台为联想开天M4600台式机，Pentium （R）4处理器，主频为2.8GHz，512MB内存，SQLite数据库版本为3.7.10。为简化比对分析过程，假设共有100支作战单元，每个作战单元所携带的移动终端设备均能接收到本机以及其他所有终端的所有类型态势信息，终端开机整型时间值为1000，其中定位信息每1s接收一次，每一类态势信息只存储于一个表中，每一个表中均包含基本信息字段。在VC6.0环境下使用两种不同的方案建立数据库，创建各类态势信息表，并产生模拟态势信息存储于各个表中，其具体信息如表3所示。

表3 两种方案下态势信息数据库说明

表3中乘号 “×”左边数值表示部队ID个数，右边数值表示每一个ID所产生的某一类态势信息条数。考虑到终端屏幕尺寸及其军标符号的绘制能力，抽取门限值Δ设定为200。

3.2 实验结果

战场环境下，及时掌握己方部队的历史行动轨迹以及当前所处位置对于提升部队的协同作战能力有着重要影响，为此，实验耗时测试的查询语句设为 “查询某一支部队（ID＝188）在某一历史时刻段内的轨迹信息”，测试次数为12次，去掉一个最大值和一个最小值取均值作为查询响应耗时。表4和表5分别给出了两种方案在不同时刻段内的详细的查询耗时测试数据，数据单位秒。

其中表5中的查询响应耗时由两部分构成，一部分是在hash＿table上查询耗时，另一部分是在具体类型信息表中批量查询耗时。其中批量查询耗时与抽取门限值Δ相关。方案A和方案B所产生的态势信息数据库大小分别为231MB和289MB，根据表4和表5测试的数据结果，表6对两者的测试数据进行了综合对比。

表4 方案A查询响应耗时测试

表5 方案B查询响应耗时测试

表6 两种方案查询响应耗时对比

采取本文提出的存储模型设计的表结构，虽然牺牲了一定的存储空间，但在增加实时预处理模块后，方案B的查询效率比方案A的效率高。对于实时性要求很高的战场环境而言，这种以存储空间换取查询响应时间的做法是有意义的。

4 结束语

战场信息系统的建设要求对于移动终端上的态势信息高效存取加以研究。本文首先选取终端态势信息管理数据库－SQLite，然后根据信息描述方式提出存储模型，结合Hash思想设计数据库表结构并提出了一种态势信息的实时查询预处理方法。最后通过实验说明本文所提出的态势信息存取方法的有效性。下一步的工作是结合高效缓存原理对于实时查询预处理方法进行改进。

［1］GUO Hongyu.Design of individual soldiers terminal handheld device ［D］.Harbin：Harbin University of Science and Technology，2010（in Chinese）. ［郭泓宇.单兵作战手持终端设备的设计［D］.哈尔滨：哈尔滨理工大学，2010.］

［2］XIONG Wenfeng.The design and realization of military PDA hardware system based on XScale PXA255 ［D］.Xian：Xidian University，2006 （in Chinese）.［熊文峰.基于XScale PXA255军用PDA的硬件设计与实现 ［D］.西安：西安电子科技大学，2006.］

［3］LIU Lin.The security research of embedded database SQLite［D］.Kunming：Kunming University of Science and Technology，2010（in Chinese）.［刘琳.嵌入式数据库SQLite的安全性研究［D］.昆明：昆明理工大学，2010.］

［4］CAO Yanyun.Study on development of embedded database［J］.Electronic Engineering ＆ Product World，2010，17 （3）：16－18 （in Chinese）. ［曹艳芸.嵌入式数据库发展状况研究［J］.电子产品世界，2010，17 （3）：16－18.］

［5］LI Hu.Research and realization of battlefield situation system based on Skyline ［D］.Changsha：National University of Defense Technology，2008 （in Chinese）.［李虎.基于Skyline的战场态势系统研究与实现 ［D］.长沙：国防科技大学，2008.］

［6］MA Yaming，HUA Yixin，ZHANG Yajun.Study on data model of battlefield situation information ［J］.Journal of System Simulation，2009，21 （4）：948－953 （in Chinese）. ［马亚明，华一新，张亚军.战场态势信息数据模型研究 ［J］.系统仿真学报，2009，21 （4）：948－953.］

［7］Grant Allen，Mike Owens.The definitive guide to SQLite［M］.2rd ed.Apress，2010：8－13.

［8］CEN Dongmei.Research and implementation of spatial database storage technology based on SQLite ［D］.Wuhan：Wuhan Uni－versity of Science and Technology，2009 （in Chinese）. ［岑冬梅.基于SQLite的空间数据库存储技术的研究与实现 ［D］.武汉：武汉科技大学，2009.］

［9］CHEN Yinchuan.Research and realization of battlefield situation information system ［D］.Zhengzhou：PLA Information Engineering University，2006 （in Chinese）.［陈引川.战场态势信息系统的研究与实现 ［D］.郑州：解放军信息工程大学，2006.］

［10］XIE Wei.The study of battlefield situation information system based on GIS and RS ［D］.Chengdu：Southwest Jiaotong University，2010 （in Chinese）.［谢卫.基于 GIS和RS的战场态势信息系统研究 ［D］.成都：西南交通大学，2010.］

［11］YAO Mengmeng.The study of the data organization and retrieval algorithm of embedded electronic map ［D］.Hangzhou：Zhejiang University of Technology，2009 （in Chinese）.［姚萌萌.嵌入式电子地图的数据组织与检索算法研究 ［D］.杭州：浙江工业大学，2009.］