国产视频www-国产视频xxx-国产视频xxxx-国产视频一二-一本大道香蕉中文日本不卡高清二区-一本久久精品一区二区

樹人論文網一個專業的學術咨詢網站!!!
樹人論文網

基于SOA和本體的指揮信息系統數據集成研究

來源: 樹人論文網發表時間:2021-04-20
簡要:摘 要:隨著信息化作戰的發展,迫切需要對指揮信息系統的數據進行集成整合,在分散異構的數據源上實現統一的數據交換。針對這一問題,提出了一種基于 SOA 和本體的多源異構數據

  摘 要:隨著信息化作戰的發展,迫切需要對指揮信息系統的數據進行集成整合,在分散異構的數據源上實現統一的數據交換。針對這一問題,提出了一種基于 SOA 和本體的多源異構數據集成架構,并詳細闡述了其體系結構、模塊設計、功能特點以及關鍵技術,最終實現了一個多源異構數據集成原型系統。通過 Web Service 技術解決了客戶端與服務端之間的遠程多源數據傳輸問題,同時利用本體技術在語義描述方面的優勢,有效整合了領域知識,實現了統一的數據訪問。結果表明,該系統克服了傳統平臺技術及數據共享技術在信息集成中的局限,解決了指揮信息系統數據空間異構、語義異構、格式異構的現實問題,實現了數據的有效集成。

基于SOA和本體的指揮信息系統數據集成研究

  本文源自葉霞; 劉睿珩; 許飛翔; 岳增營, 火力與指揮控制 發表時間:2021-04-19《火力與指揮控制》雜志,月刊,于1976年經國家新聞出版總署批準正式創刊,由中國兵器工業集團有限公司主管,北方自動控制技術研究所主辦的學術性刊物,本刊在國內外有廣泛的覆蓋面,題材新穎,信息量大、時效性強的特點,其中主要欄目有:專家論壇、綜述、理論研究、工程實踐、試驗技術。

  關鍵詞:Web Service,本體技術,數據集成,語義異構

  在信息化戰爭背景下,指揮信息系統作為作戰指揮的“神經中樞”,已然成為各國部隊的建設重點之一,數據作為其“血液”,更是發揮著至關重要的作用。然而,隨著指揮信息系統數據需求的快速增長,各類數據資源的規模、結構、分布都發生了巨大變化。當前,由于各作戰單位指揮信息系統建設的階段性和分布性特點,這些系統的建設時間、開發人員、運行環境大都不一致,并且它們的數據源之間相互獨立,因此存在著大量冗余、異構的數據。這導致數據難以在系統之間流轉、共享和融合,容易產生“信息孤島”的現象[1]。

  為解決不同指揮信息系統數據之間存在的格式異構、空間異構、語義異構等問題,實現數據資源的高效利用。本文提出了一種基于 SOA(Service Oriented Architecture)[2]和本體技術的多源異構數據集成系統[3]。通過面向 SOA 的 WebService[4]技術,對多個孤立數據源進行整合,結合本體映射方法,合并不同指標體系中具有相同語義的概念,從而構建統一的全局指標本體,為指揮員提供一個完整統一的數據視圖,協助指揮中心對子單位數據資源進行管理。除此之外,通過統一底層數據源格式,系統還集中了數據模式轉換和查詢處理等功能,實現異構數據源的無縫鏈接和信息共享,為指揮員提供兼容可靠的查詢功能,便于獲取、集成和查看數據。因此,多源異構數據集成系統的設計實現成為了解決“信息孤島”問題的有效手段,是實現數據一體化訪問和挖掘運用的關鍵因素。

  1 相關研究

  數據集成指通過清理、映射和轉換等操作,將不同來源的數據合并到單個統一視圖的過程。起初的研究主要集中在聯邦數據庫系統[5,6]上,通過建立聯邦模式架構,實現各個數據源之間的相互聯系和獨立自治[7],但這種架構很難實現數據源的拓展。隨著數據存儲能力的提升,數據倉庫[8]能較好地整合多個數據源從而實現高效查詢,并得到了進一步運用[9],但數據倉庫不能很好地處理冗余數據,導致數據實時更新困難。為了更好地解決用戶與數據源之間的連接關系,一些工作在兩者之間建立一個中間件層[10],從而為用戶提供統一的數據視圖和訪問接口。但這種方法難以區分具有相似語義的數據,并且查詢效率很大程度上依賴于中間層的設計。因此,近年來越來越多的研究集中在實體匹配[11]和語義映射[12]等方面,但是這些方法往往只針對結構化或者非結構化類型的單一數據。XML (Extensible Markup Language)和本體技術[13]的引入為異構數據集成提供了一種新思路,利用 XML 在統一數據格式時的普適性以及本體技術嚴謹的概念結構和邏輯推理等特性,進一步提升了數據集成的效果[14]。本文以 Web Service 體系為框架并結合本體技術,針對指揮信息系統數據在空間、結構和語義上的差異,設計實現了一個多源異構數據集成系統。

  1.1 SOA 和 Web Service 概述

  SOA 即面向服務架構,它是一種軟件架構設計的模型和方法論,將應用程序的不同功能單元通過這些服務之間定義良好的接口和契約聯系起來。 SOA 的提出是在企業計算領域,就是要將緊耦合的系統,劃分為面向業務的,粗粒度,松耦合,無狀態的服務。在 SOA 的技術框架下,可以把雜亂無章的龐大系統整合成一個全面有序的系統,從而增加企業在業務發展過程中應用系統的靈活性,解決異構系統之間通信問題,實現最大的網絡資產利用率。

  Web Service 作為一個新型的分布式計算模型,是實現 SOA 這一理念的推薦標準,它由三個部分組成,分別為服務提供者、服務請求者和服務代理,通過發布、查找和綁定實現信息的傳輸。Web Service 的關鍵技術包括 XML、SOAP、WSDL 和 UDDI。

  XML 是指可擴展標記語言,是 Web Service 的技術基礎,Web Service 中各種信息的描述都是基于 XML。

  SOAP(Simple Object Access Protoco1)是指簡單對象訪問協議,是基于 XML 在分散或分布式的環境中交換信息的簡單的協議。允許服務提供者和服務請求者經過防火墻在 Internet 進行通訊交互。

  WSDL(WebService Description Language)是指網絡服務描述語言,也是基于 XML 語言的,用于描述 WebService 以及如何對它們進行訪問。

  UDDI (Universal Description,Discoveryand Integration)是指通用描述、發現與集成服務,用來創建 Web 服務注冊中心,它是 Web 服務注冊和發現的技術規范。UDDI 是一個獨立于平臺的框架,用于通過使用 Internet 來描述服務,發現企業,并對企業服務進行集成。

  Web Service 三角形的設計模型[15]被稱作 SOA 的體系結構,Web Service 模型如圖 1 所示。

  一個完整的 Web Service 體系結構的實現過程如圖 2 所示

  Step1:客戶查詢服務中介以請求特定的服務; Step2:服務注冊中心引導客戶找到滿足請求的服務 WSDL 文檔; Step3:服務請求者訪問 WSDL 文檔; Step4:WSDL 提供服務的具體描述信息; Step5:客戶根據 WSDL 生成相應的 SOAP 消息,發送給 Web 服務提供者; Step6:服務提供者應答 SOAP 消息,提供給請求者相應的服務。

  1.2 本體技術

  隨著語義網技術[16]的不斷發展成熟,異構數據集成的重點慢慢地轉移到解決語義異構的問題上,而目前本體技術利用對語義很好地描述能力可以很好地解決數據的語義異構問題,EhrigM 等在文獻[17]中介紹了本體集成的問題在歐洲委員會啟動的 SWAP(Semantic Weband Peer-to-peer)項目中首次被提出,該項目有著在每個終端建立各自的本體之后建立一個集成大本體的需求,因此提出了本體映射和本體合并的概念,本體技術的運用消除了數據集成過程中的語義異構問題,并最終實現語義融合的目的。

  本體概念的發展使得本體模型也在不斷地進行完善,最終得到公認的一套本體模型[18]:O={C, R,F,A,I}。

  1)C 代表類(class):是從本體中提取出用以表述事物對象的集合,描述領域內的實際概念,既可以是實際存在的事物,也可以是抽象的概念,比如邏輯推理、動作、策略和工作過程等;

  2)R 代表關系(relations):用于描述類(概念)之間的關系,表示了領域內的概念與概念之間的相互影響力,如 part-of、kind-of 等;

  3)F 代表函數(function):函數是一類特殊的關系,可以理解為關系的一個特例,在這種關系中前 n-1 個元素可以唯一決定第 n 個元素,

  4)A 代表公理(axioms):公理代表本體內存在的事實,多用來表示對概念或者實例的約束;

  5)I 代表實例(instances):表示具體某個類的實際存在,從語義方面講實例代表的就是具體對象。

  為解決指揮信息系統數據目前存在的空間異構、格式異構以及語義異構等問題,本文提出使用本體技術和基于 SOA 的 WebService 技術實現多源異構數據集成的方法,設計并實現了多源異構數據集成原型系統。

  2 基于 Web Service 和本體的多源異構數據集成原型系統設計

  2.1 需求分析

  不同的作戰單位在地理位置分布上十分的分散,而且每個單位指揮信息系統存儲數據的格式不盡相同,不利于進行聯合作戰指揮,難以提高部隊戰斗力。因此考慮將各個單位的數據集成起來,進行統一查詢,并將集成后的數據以二維數據表的形式輸出,可以很好地了解相應系統的作戰水平。

  多源異構數據集成原型系統是服務于基層作戰單位以及指揮中心的。該系統使用 Web Service 技術進行數據傳輸,利用 XML 技術和本體技術實現數據集成查詢 [19],提供給指揮員數據集成分析的功能,為各級指戰員高效完成作戰提供堅實的基礎,是信息化戰爭中不可或缺的一環。

  多源異構數據集成原型系統的主要參與者可以分為兩類:指揮中心技術員作為指揮中心用戶完成數據集成查詢等操作;各個子單位技術員作為子單位用戶完成數據采集處理等操作。具體的系統用戶及其功能性需求如表 1 所示。

  2.2 系統功能設計

  在充分調研了現有的指揮信息系統數據管理現狀后,結合用戶的需求,將系統劃分為各作戰單位使用的客戶端以及指揮中心使用的服務端。完整的系統功能設計如圖 3 所示。

  2.2.1 客戶端主要功能

  1)本地數據管理

  各作戰單位是數據的來源,對數據的管理尤為重要,直接關乎到后續數據集成效果的優劣,用戶需要通過此功能對本地的數據進行管理,不論是非結構化的文本數據還是結構化的數據庫數據,都可以進行增刪查改等操作。

  2)數據清洗及轉換

  規范的數據可以減少服務端進行集成所花費的時間,所以在客戶端需要實現數據的清洗[20]及格式的轉換。數據的清洗主要針對數據中出現的重復、缺失、不合理值的情況進行處理,從而得到規范的數據,方便后續的處理。由于在數據傳輸中采用 Web Service 技術,可擴展的標記語言 XML 作為 Web Service 平臺表示數據的基本格式,除了易于建立和易于分析外,其主要的優點在于它可以不受平臺和所使用軟件的影響。因此考慮將數據格式全部統一成 XML 格式的文件,以便于后續的數據傳輸和集成。

  3)上傳數據

  各個單位的客戶端在處理好數據后,需要將數據上傳至指揮中心的服務端,此過程中通過 Web Service 技術與服務端進行通信,同時進行數據的傳輸,從而將各個作戰單位的數據全都集中到指揮中心的服務端上,這是解決數據空間異構的重要步驟。

  4)系統設置

  系統在實現主要功能時,還應具備一些基礎功能。如語言選擇、時間調整、界面外觀設置、用戶名和密碼修改等通用設置,提供更好地用戶體驗。

  2.2.2 服務端主要功能

  1)用戶管理

  用戶管理主要針對服務端和客戶端用戶,對登錄到系統的用戶權限進行管理。為了充分考慮各個單位數據源的安全性,因此可以將每個客戶端看作一個數據源,同時對用戶和數據源進行相應的綁定。

  2)數據管理

  數據管理功能主要實現對各單位上傳的 XML 數據的管理,接收到各單位的數據后,可以進行增刪查改等操作。服務端還需對客戶端清洗過的數據進行檢查,如果數據依舊存在有重復、缺失、不合理值等情況,需要再次進行清洗修正。

  3)數據集成

  數據集成的功能主要利用本體集成相關技術,具體包括本體的構建、本體概念相似度的計算以及本體的映射,最終將各個單位的數據集成到一個全局本體中,這也是整個系統的關鍵技術。在相似度計算和本體映射中可以引入機器學習算法,提高計算精度和映射準確性。通過本體集成技術實現各個單位數據的高效集成,并存儲于服務端的數據庫中。

  4)集成結果查詢

  集成結果查詢為用戶提供了一個人性化查詢接口。將各個單位的數據集成到一起后,可實現用戶的按需查詢,例如,當用戶有查看某單位或某一天數據的需求時,可以通過系統搜索框輸入需要查詢的單位編號、日期、指標名稱等關鍵字,就可以在數據庫中查找相應的信息,后臺經過一些查詢內容的查詢轉換、最終向用戶呈現查詢結果。

  5)輔助功能

  輔助功能主要是保證管理員可以在服務端完成數據和代碼的維護。系統將重要的指標名稱進行標記,當有新的指標名稱出現時,進行相似度計算,實時更新本體概念庫,數據維護對于系統的運行十分重要,也是保證本體集成效果的重要措施。代碼維護功能可以保證系統正常的調試運行。

  6)系統設置

  同客戶端一樣,服務端也具備系統的基礎設置功能。

  2.3 系統體系結構設計

  本文在數據結構和相應算法的基礎上進行系統體系結構設計和開發,如圖 4 所示。系統采用基于 SOA 的三層 B/S 結構[21],其中包含應用層、中間層和信息源層。信息源層主要包含異構數據源,首先進行數據的清洗,然后將數據轉換為 XML 格式;中間層主要完成基于 Web Service 的數據安全傳輸、接口的管理以及基于本體的數據集成相關工作;應用層主要表現為網頁端系統,直接面向管理員和用戶。系統的體系結構設計如圖 4 所示。

  2.3.1 信息源層

  信息源層是整個系統的基礎,本課題研究的數據是來自于各個作戰單位指揮信息系統運行數據,數據源存儲于不同的單位,在不改變原有信息結構的基礎上,將結構化數據及非結構化文本數據轉化為 XML 格式后上傳至服務端,在服務端將 XML 文檔進行處理,構造局部本體,通過本體映射實現將局部本體映射到全局本體。實現數據的集成,以滿足后續的查詢需求。

  2.3.2 中間層

  中間層的主要任務是進行整個業務功能的完成。要為應用層訪問該系統的用戶提供功能操作和數據查看,向下需要協調各個單位的數據源,在這一層系統主要完成數據的交互、本體的構建、本體概念相似度的計算、本體的映射、集成數據查詢處理、Web Service 接口的管理等功能。

  2.3.3 應用層

  應用層處于多源異構數據集成原型系統的信息源層和中間層之上,主要是服務于系統框架中的信息的用戶和管理者,在本系統中以網頁的形式展現,為客戶端用戶和服務端管理員進行數據的傳輸、處理、集成、查詢提供用戶界面。用戶和管理員只需在網頁上選擇需要進行的操作或者查詢需要查找的信息,瀏覽器便可以接受用戶的請求并進行解析,將請求傳至中間層進行處理,完成相應的操作。這種方法的好處在于,用戶和管理員無需了解請求數據和系統數據在底層傳輸處理的細節,而是能夠直接在網頁系統上查看到中間層返回的結果,有著較好的人機交互體驗。

  3 系統關鍵模塊設計

  3.1 數據格式統一模塊

  數據格式的異構是當前數據集成所面臨的最基本的問題,不同的單位的指揮信息系統運行數據存儲的格式不盡相同,有的以 TXT、Word、Excel 或者 XML 格式進行存儲,有的存放在數據庫中,數據庫的選擇也不盡相同,有 Oracle、SQLServer、MySQL、 Access 等,統一各單位數據的數據格式是完成數據集成的第一步。由于 Web Service 和本體技術都對 XML 格式有著較好的親和力,因此,考慮以 XML 作為數據的統一格式。XML 作為一種機器可讀文檔的規范,在數據轉換領域有著廣泛的應用,特別是可以根據其語義約束的特性定義 XML 文件結構,以便于開發人員和解析工具處理。本文通過 XML Schema 定義各類元素及其系列屬性來確定 XML 文檔結構。在轉換數據格式時,對于需要集成的數據,根據結構特點,主要將其劃分為結構化和非結構化兩類,并按照預先定義的 XMLSchema 映射文件,在客戶端統一將本地數據轉換為 XML 格式。

  3.1.1 結構化數據到 XML 數據的轉換

  由于目前的數據庫管理系統存在很多差異,不同的應用領域,數據模型不盡相同,不同的生產商也生產出不同的數據庫,如 Oracle、SQL Server、 MySQL、Access 等。這些關系數據庫到 XML 的數據轉換主要是通過 XML Schema 直接建立與數據庫的映射。

  首先按照需求和 XML 文件的定義,根據映射規則生成 XMLSchema 映射文件,Schema 定義了在數據庫中檢索的數據,以及最終在 XML 文件中如何表示這些數據。然后利用文檔對象模型(Document Object Model,DOM)來解析 Schema 文件,根據映射的定義,將獲得的數據庫結果集轉化為目標 XML 文檔。

  3.1.2 非結構化文本數據到 XML 數據的轉換

  非結構化文本數據主要是以 TXT、Word、Excel 這些類型存儲的數據。其中,TXT 文本數據可以通過 java.io 流來進行輸入和輸出,完成對 TXT 文本的讀取,并將其中的文件結構和文件內容取出,按照 XML Schema 預設的格式寫入到同名的 XML 文檔中,最終實現 TXT 文檔到 XML 文檔的轉換;Word 文檔的轉換可以通過 Jacob(Java-COMBridge)技術對 Word 文檔內容進行讀取,Jacob 在 Java 與微軟 COM 組件之間建立橋梁,通過 JNI 功能訪問 Windows 平臺的 COM 組件或 win32 系統庫,完成讀取后按照 XML Schema 預設格式生成同名 XML 文檔; Excel 文檔到 XML 文檔的轉換可以通過 Java Excel API 實現[22],該組件可以對 Excel 文檔進行讀取、創建和更新。因此,使用 Java Excel API 讀取 Excel 文檔中所有單元格的內容及格式,并按照同樣的方法寫入到同名 XML 文檔。

  3.2 數據傳輸模塊

  結合各級指揮單元之間在空間分布上“散”和 “遠”的特點,依托指揮信息系統信息通信支撐網和其他共用信息基礎設施,數據交互模塊主要解決指揮信息系統在數據集成時所面臨的空間異構問題,以實現客戶端與服務端之間的數據交互,這里的數據不僅指系統數據,還包括請求和響應數據。

  首先為每個數據源創建相應的 WebService 接口,然后各子單位可根據指揮中心發布的 WSDL 文檔并通過 SOAP 協議上傳數據。在本系統中,服務端作為服務提供者進行 Web Service 接口的開發,而各單位的客戶端系統作為服務的請求者,根據服務端的 WSDL 文件配置交互的參數,并以 SOAP 消息的形式封裝 XML 數據,交互的參數、文檔以及返回值都采用 XML 格式[23]。客戶端與服務端進行通信時的數據交互流程如圖 5 所示。

  3.3 本體構建模塊

  在指揮信息系統中,由于不同單位建立的指標體系存在差異,相同的概念經常以不同的指標描述,容易引起語義異構問題。本體的構建[24]是利用本體技術進行數據集成的重要基礎,本系統將各單位上傳的 XML 文檔轉換為局部本體的形式,具體的構建流程如圖 6 所示。通過本體映射對具有相同語義的指標概念進行合并,從而實現指揮信息系統數據的集成和共享。

  首先將各個單位上傳的 XML 文檔,使用 XML Schema 進行描述,接著將 XML Schema 轉換成為 RDF Schema 模式,然后將 RDF 相關文件導入到 prot佴g佴 中,完成局部本體 OWL 的構建,最后將構建好的 OWL 本體文件導入到服務端系統。

  為增強與指揮信息系統領域與本體概念之間的相關性,在轉換成本體概念后,還需進一步的篩選,保證轉換后的概念可以有效表示指揮信息系統領域的相關指標[25],具體方法如下:

  1)劃定所研究的領域的知識范圍。比如指揮信息系統通信模塊相關數據的集成時,在構建本體時就要將領域知識范圍限定在指揮信息新系統通信相關領域,準確分析相關概念,盡量選擇認可度最高的概念作為本體構建的權威依據;

  2)分析領域知識中的相關概念和所構建的本體概念之間的差異與聯系。確保兩者之間不出現邏輯上的混亂和原則上的差錯;

  3)利用語義模型檢驗本體概念。將所構建的本體概念在語義網中進行表示,確保不會出現模棱兩可、表述不清的情形;

  4)確保人工評價的準確性。在使用本體構建原則對所構建的本體進行人工評價時,需要做到評價準確。對補充到本體中新的本體概念,也要進行評價,以確保本體的不斷完善。

  5)若完成上述操作,即可確定所構建的本體,并使用本體語言表示,添加到本體概念庫中。

  3.4 集成結果查詢模塊

  查詢處理也是系統的重要功能,當用戶需要查詢一些特定條件下的數據時,比如特定的單位、特定的時間或者特定的指標數據時,系統可以及時做出反應,將用戶需要的信息呈現出來。在查詢的過程中,系統需要根據用戶所輸入的關鍵詞與本體庫中的概念進行映射匹配,在全局本體中找到該概念的本體表達,然后將查詢命令分解為對局部本體的查詢,最后將查詢局部本體數據返回給用戶界面。

  本 研 究 用 到 兩 種 查 詢 語 言 OWL-QL 和 XQuery,分別對本體語言表示的概念和 XML 語言形式的概念進行查詢。OWL-QL 是 W3C 推薦的網絡本體查詢語言錯誤!未找到引用源。,由查詢回復和查詢回復協議組成,與傳統查詢語言不同,在查詢過程中,OWL-QL 需要對 OWL 知識庫進行推理,且支持應答格式的設定、多知識庫的選擇和使用。 XQuery 是一種針對于 XML 的查詢語言錯誤!未找到引用源。,類似于 SQL、OQL 等,能夠從 XML 文檔中抽取數據。XQuery 不僅擁有其它多種查詢語言的優點,而且適用于各種類型 XML 數據源的查詢。系統查詢處理的過程如圖 7 所示,具體步驟為:

  Step1:查詢生成器接收用戶所發出的查詢請求,將用戶的查詢關鍵詞接受后送給本體管理器。查詢生成器開始驗證查詢關鍵詞的語法,判斷所輸入的關鍵詞是否符合語法要求,符合要求時生成 OWL-QL 查詢語句送至本體管理器,否則提示輸入的查詢信息有誤;

  Step2:本體管理器根據得到詞語在全局本體內進行查找,當查找到全局本體里面的概念或者根據本體概念相似度計算模型得出的相近的概念時,將全局本體的查詢分解為對局部本體的查詢,此時查詢的概念為映射為全局本體概念前的所有相似概念,同時生成多個局部本體查詢語句,本體管理器會將結果送給查詢分解器;

  Step3:查詢分解器接收到本體管理器的查找結果后,生成 XQuery 查詢語句在各局部本體對應的 XML 文件中進行相關概念的查找;

  Step4:查詢處理器將查詢分解器最終查詢到的結果以數據表的形式返回到瀏覽器進行解析,用戶便可在網頁系統上看到查詢的結果。

  4 驗證與應用

  根據多源異構數據集成原型系統需求分析、功能設計、體系結構設計和關鍵模塊的設計,結合 Web Service、本體以及 XML 技術,基于 java 語言,使用 Eclipse IDE 開發,系統的整體展示如圖 8 所示。本文所實現的數據集成原型系統于 2019 年 8 月份進行了測試,測試過程中在 101 單位、102 單位、103 單位和 201 單位使用 IE 瀏覽器登錄數據集成原型系統客戶端,首先將各單位不同格式數據通過格式轉換功能統一成為 XML 格式的文件,然后通過 Web Service 上傳至指揮中心的服務端進行集成,服務端中使用本體集成相關功能進行語義融合和數據集成。

  系統在測試中可以基本完成相應的功能,但也存在部分測試用例不通過的情況,例如出現以下問題:各級用戶權限判別有誤;輸入錯誤或者無效的字段時,查詢界面沒有錯誤提示等。產生這些問題的主要原因主要來自于需求定義不明確、功能性錯誤、頁面設計和需求不一致以及開發過程中的疏忽等原因。經過后期的修改和調試工作,對本系統進行了再次測試,結果表明上述問題均得到了有效解決,實現了不同單位、不同格式、存在語義異構數據的集成,較好地驗證了系統設計的可行性。

  5 結論

  本文研究了基于 SOA 和本體的指揮信息系統數據集成方法和架構。將系統分為信息源層、中間層和應用層,通過 WebService 技術解決了數據集成中的數據源空間異構問題,使用 XML 統一了多種格式的數據源,解決了數據集成中的格式異構問題,利用本體技術解決了數據集成中的概念語義異構問題。實現了指揮信息系統多源異構數據的有效集成,為用戶提供全局視圖,為數據挖掘、決策支持提供基礎。同時設計實現的系統是實驗性質的,距離完成大數據的集成和戰場應用還有很大的差距,需要進一步改進完善。

主站蜘蛛池模板: 国产自线一二三四2021 | 国产精品黄页网站在线播放免费 | 欧美最猛性xxxxx亚洲精品 | 国产网曝手机视频在线观看 | 99久久综合国产精品免费 | 久色乳综合思思在线视频 | 欧美一级一片 | 一级毛片无毒不卡直接观看 | 国产精品99久久久久久小说 | 成人精品第一区二区三区 | 亚洲精品成人久久 | 亚洲欧美在线视频免费 | 国产丶欧美丶日韩丶不卡影视 | 日韩精品特黄毛片免费看 | 69性欧美高清影院 | 久久国产午夜精品理论片34页 | 久久网站免费 | 真人一级毛片免费完整视 | 国产三级麻豆 | 欧美亚洲国产精品久久久久 | 国产色爽女小说免费看 | 欧美精品一区二区精品久久 | 日本高清va不卡视频在线观看 | 久久99精品国产免费观看 | 久久怡红院 | 精品色综合 | 日韩一级欧美一级 | 白嫩美女一级毛片免费看 | 国产一区二区三区在线免费 | 国产在线精品观看 | 找个毛片看看 | 国产精品欧美亚洲日本综合 | 亚洲高清国产一区二区三区 | 成人精品国产亚洲欧洲 | 亚洲影院在线播放 | 久草在在线视频免费 | 在线视频一区二区三区四区 | 男女视频免费在线观看 | 在线观看国产精品日本不卡网 | 欧美一级高清片在线 | 一本久久精品一区二区 |