基于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.］