基于國家海洋應急管理平臺的數據交換系統的設計

周雪

（國家海洋信息中心天津市300171）

基于國家海洋應急管理平臺的數據交換系統的設計

周雪

（國家海洋信息中心天津市300171）

由于海洋勘探開發溢油、港口污染、陸源排污、海洋傾廢甚至海島礁爭端等海洋應急事務頻發，海洋應急管理信息化的要求也不斷提高，越來越多的海洋單位開始建立自己的海洋應急管理系統，通過整合單位內分散的信息資源，對信息進行處理、交換，實現海洋數據管理的規范性以及各相關單位、單位部門間的數據共享，從而促進海洋應急管理的信息化建設，提高海洋應急管理的綜合服務能力。由于海洋數據種類繁多，如何把這些數據及時地匯總并應用到應急管理平臺中，成為海洋應急管理體系建設的關鍵問題。建設數據交換系統實現了海洋應急數據之間的交換與共享。

跨平臺；數據獲?。粩祿粨Q；數據共享

1 項目背景

海洋應急管理，管理應對海洋自然災害，我國擁有將近300萬km2的的海域和3.2萬km的海洋線，如此遼闊的海洋面積導致我國海洋災害頻發，且種類繁多，危害巨大。2010年初發生的海冰危害，造成的港口封凍，航道停運和大面積的海洋生物死亡，直接經濟損失高達64億元[1]。以“十五”期間海洋災害統計狀況為例，在此期間，由海洋災害造成的經濟損失高達630億元，死亡人員約1 200人。其中風暴潮共發生67次，死亡失蹤人口377人，造成經濟損失611億元，占全部海洋災害造成經濟損失的97%[2]。

國家應急平臺體系建設已基本建成，聯結31個?。ㄗ灾螀^、直轄市）、新疆生產建設兵團、5個計劃單列市應急平臺以及部分具有應急職能的部門應急平臺和部門值班系統。隨著海嘯、溢油、赤潮、港口污染和海島爭端等海洋應急事件頻頻發生，為了正確、迅速地處置各種海洋突發事件，國家海洋局已建成了統一指揮、資源共享、準確預測、科學決策的應急指揮業務化平臺，實現綜合協調、監測監控、信息報告、綜合研判、指揮調度、異地會商和現場圖像采集等功能。目前我國海洋應急管理存在如下幾方面的問題。

1.1 基礎設施相對落后

隨著社會的不斷進步，面對海洋環境的不斷復雜，現有觀測系統的建設依然顯得略微薄弱。其中體現在幾個方面：離岸觀測目前采用浮標為主要觀測手段，由于浮標價格高昂，且拋灑不均勻，導致離岸數據的不全面。岸基觀測目前依靠海洋臺站，在3.2萬km的海岸線上分布著100多個海洋臺站，分布不甚合理，且間隔較大。

1.2 協同能力有待提高

相對于陸地環境，海洋環境更復雜多變，且區域劃分困難。所以在這一條件下，處理各類海洋災害需要國務院應急辦協調各有關部門以及地方政府等相關單位在統一的領導下，協同處理。因此，海洋災害突發事件在管理上需要建立一種互連互通、信息共享和協同應對的處理模式[3]。

1.3 信息管理系統相對落后

海洋應急平臺目前處于一個“信息孤島”的位置，由于海洋應急平臺與其他海洋業務系統處在不同的業務專網上，導致海洋應急平臺數據庫與其他業務系統數據庫之間并不能直接進行數據交換。

2 總體目標

從大數據的角度進行分析，海洋應急研判依托對海洋應急事件、海區突發事件、觀測信息、監測信息和預警信息等各類數據的綜合分析，數據量越大，對應急事件預判的準確性越高。針對一次國家級應急事件而言，從國家應急辦獲取應急事件的最新情況，并與各相關單位聯合采取應急預案與措施，可以避免因職能劃分不清造成的人力和物力的浪費而耽誤了應急事件的黃金時間。對于沿海的海洋類突發事件，海洋局作為海洋管理機構，需要及時了解事態發展情況并結合各類海洋實時信息對突發事件部署應急預案。海洋應急平臺數據交換應用系統的建立，解決了數據從收集、存儲、處理到共享的一系列數據交換與共享問題，并保證了整個數據交換與共享過程中數據的及時性、完整性、一致性與安全性。從根本上解決了目前海洋應急平臺數據庫空虛的問題，同時在經過處理之后的數據，不僅可以用于海洋應急平臺，還可以為國家級應急平臺提供數據支撐，也可以為其他應用提供數據支撐，還可以提供瀏覽查詢等功能，極大地提高了數據的利用率。

2.1 及時性

系統將數據獲取由原來的通過移動存儲交換變成數據的自動獲取，數據由海洋站收集至各海區分局匯總，分局利用觀測網鏈路向海洋預報中心發送的同時經海洋信息網鏈路發送至海洋局，保證了數據的及時性。

2.2 完整性

系統在數據處理過程中，從全局的角度，對數據庫進行綜合考慮，設立主鍵關聯各表，提高了數據處理過程的效率，為后續的數據共享提供了前提條件。

2.3 一致性

系統對數據進行統一的定義，從根本上避免了因字段沖突造成的錯誤，為后續數據的統一處理與共享提供了可行條件。

2.4 安全性

系統提供了用戶管理與認證功能，為數據交換與共享提供了一個安全可靠的環境。

3 需求分析

海洋局的信息系統較多，且由于建設時間、投入情況的不同，使用的技術也不盡相同，使得國家海洋應急平臺與其他各信息系統之間的數據交換存在一定困難。在海洋局網絡整合之后，合并冗余鏈路，網絡逐層向下延伸，數據逐層匯總，向上一級單位報送，最終在海洋局主節點匯總，并同時在信息中心進行數據備份。在網絡整合的基礎上，逐層匯總的數據最終先到達國家海洋局主節點，在國家海洋局進行數據處理整合后，發往不同單位或在本地保存。在國家海洋應急平臺的基礎上建設數據交換應用系統，為海洋應急平臺與其他海洋信息系統之間的數據交換提供了極大的便利。

3.1 數據獲取

數據交換應用系統主要涉及4類數據，并由不同的路徑獲取，數據獲取如圖1所示。

（1）第一種數據來源：由上級應急單位下發的有關應急事件的相關信息和下級單位上報的所屬海區發生的應急事件的相關信息。對于這類數據，由于國家應急體系建設的要求，所以海洋局與國家應急辦采用相同的應急管理平臺系統，并將系統部署至下級海區各分局，對于此類數據，由于各級單位使用的應急管理平臺系統的數據庫的無異性，所以這部分數據可以歸并為一類情況，進行統一處理。

圖1 數據獲取

（2）第二種數據來源：是由國家海洋信息中心提供的基礎信息數據，此類數據多為GIS數據，數據獲取時，考慮到數據格式、數據大小等問題，以及數據保密程度，應采取本地數據獲取方式。

（3）第三種實時類數據，由各種海洋觀測設備獲取的海洋實時數據。對于這類數據應采取數據傳輸到本地后，系統自動識別獲取。

（4）第四種海洋局機關紙質信息，對于這類信息，系統應該充分考慮到，在系統設計時應留有本地信息錄入功能。

3.2 數據存儲

根據數據獲取的實際情況，設計數據交換應用系統數據庫，滿足對各類數據的存儲，在數據庫設計時應充分考慮到數據名稱沖突等問題。

3.3 數據處理

對本地數據進行處理，統一數據格式，獲取統一的數據產品，為后續數據共享提供條件。根據用戶的實際需求，數據處理的環節應統一數據格式，綜合比較各類數據傳輸格式，XML更適用于此類異構數據庫之間的數據轉換與傳輸，數據交換應用系統將全部數據格式處理為XML格式，方面后期統一的傳輸與使用。在數據處理環節，系統考慮到不同格式與XMM格式之間的數據格式轉換。

3.4 數據共享

在統一數據格式之后，數據交換應用系統輸出統一的數據產品，供后期使用，根據用戶的實際需求，數據產品用途主要有兩種：第一種，進行數據傳輸，通過網絡專線傳輸至海洋應急平臺系統，對于這部分數據，數據交換應用系統應根據海洋應急平臺系統所需要的數據的不同和海洋應急平臺數據庫的不同制定不同的方案。第二種，對于本地數據對用戶提供瀏覽、查詢等功能。

4 系統設計

數據交換應用系統應在實現需求分析的各項功能的基礎上，提高系統的運行性、實用性性和通用性等性能為出發點，對數據交換應用系統進行全面的設計。數據交換應用系統的設計應滿足以下幾方面的要求：

（1）系統接地性

數據交換應用系統建設要以系統的實用性為出發點，在系統切合實際需求的基礎上，考慮數據交換技術的發展方向，選用先進成熟的產品和開發平臺，構建一個切合實際、符合數據交換業務需求的系統。

（2）數據獲取標準化

數據交換應用系統具有多種數據來源，且設計數據格式種類繁多的特點，系統需要設計統一標準的接口規范，保證各系統以統一標準實現數據接口。充分考慮到數據來源的多樣性，系統接口設計應具備良好的可配置性和可擴展性，通過配置能夠適應多種系統接口的適用性，滿足對各類數據進行獲取的實際需要。

（3）可靠性與安全性

軟/硬件資源需要數據交換應用系統的7×24 h不間斷可靠運行，必須根據服務器、網絡等設備的實際性能，制定完善的可靠性保證措施，保證系統高度可靠的運行。數據交換應用系統應遵循國家信息安全要求加強信息安全防護。系統對重要業務數據進行重點防護，同時對網絡攻擊、木馬軟件和系統頻繁調用具備一定的檢測和防御能力。

（4）可擴展性

在進行硬件配置、方案設計時，數據交換應用系統設計應充分考慮到國際應急指揮未來的發展需要，使其具備良好的可擴展性。同時要考慮為系統的升級和硬件改造提供有力保證。

4.1 系統邏輯架構

數據交換應用系統邏輯架構從上至下由接入層、應用層、服務層、數據庫層和網絡層構成，如圖2所示。整個系統架構以應用層和服務層為系統核心，資源層提供為支撐，接入層提供多種接入方式，為不同用戶提高高效、全面的服務服務。系統安全、運行維護和監控日志管理貫穿系統的各個層面，為架構中的各層次提供安全支撐服務。

4.2 數據組織

為了科學的管理和使用數據，為滿足數據交換應用系統的實際需求，根據數據關聯程度和數據存儲等特性，從邏輯上講數據交換應用系統數據庫劃分為事件庫、觀測信息數據庫、監測信息數據庫、預報信息數據庫、地理信息數據庫、基礎信息和統計分析數據庫。系統數據庫邏輯結構示意如圖3所示。

4.3 數據模型

數據模型是對數據特征的抽象表示，是對數據庫管理的教學形式框架表示，是數據庫系統中用來提供數據信息表示和數據操作手段的形式構架。數據交換應用系統的主要業務的數據模型如圖4所示。

5 系統實現

數據交換應用系統具體功能的實現在系統需求分析的基礎上、以系統設計為指導，實現系統最終目標。系統模塊具體功能實現，包括系統用戶界面設計實現和具體功能實現兩部分，通過系統模塊實現的描述最終實現可應用的數據交換應用系統。系統具體功能實現部分采用C/S結構，采用JAVA語言開發的基于Oracle 10G數據庫實現，具體模塊由數據管理、成果管理、用戶管理和系統管理4部分組成。

5.1 數據管理模塊

數據管理由數據添加、刪除、修改、導入、導出和發布組成。數據添加是在數據庫中添加新數據條目的過程；數據刪除是在確定數據有誤或過期的情況下從數據庫中刪除數據條目的過程；數據修改是對已添加數據進行修改的過程；數據倒入導出是對格式數據批量導入、導出數據庫的過程。

圖2 系統框架圖

數據添加功能是一個建立新的數據條目的過程，數據添加的時候通過數據添加頁面錄入的數據信息，調用程序單元，將數據保存到數據庫并生成唯一的數據編號。數據添加實現如圖5所示，此功能實現方法如下：

管理員或高級用戶打開數據新建功能界面錄入信息并保存。

（1）判斷事件名稱、事件類型、發生事件、區域代碼、經度、緯度、事件詳情等必填元素是否都填寫完整，對于未填寫的元素進行提示。

（2）如果符合校驗則調用事件編號生成規則產生新的事件編號，并將此事件數據保存到數據庫并提示用戶數據添加成功。

5.2 成果管理模塊

共享管理模塊是由成果瀏覽和成果查詢兩部分組成。成果瀏覽是用戶瀏覽數據庫中已被審核發布數據的過程；成果查詢是用戶對于數據庫中全部已審核發布的數據進行關鍵字檢索的過程。

共享查詢功能是對數據庫中全部審核發布的數據進行按多種條件組合查詢的過程，可以根據需要選擇不同條件單獨或者組合查詢。數據查詢實現如圖6所示，此功能實現方法如下：

操作人員錄入查詢條件查詢

（1）判斷是否錄入查詢條件，如果沒有提示請錄入查詢條件。

（2）如果有查詢條件則根據條件調用后臺查詢語句返回查詢結果。

5.3 用戶管理模塊

用戶管理由用戶添加、刪除、修改、和權限制定4部分組成。用戶添加是指在數據庫中添加新用戶條目的過程；數據刪除是在確定用戶已經離開工作崗位或離職的情況下從數據庫中刪除用戶條目的過程；數據修改是對已添加用戶基本信息進行修改的過程；制定權限是對用戶權限重新制定的過程。

5.4 系統管理模塊

圖3 數據交換系統數據庫邏輯結構

系統管理由修改密碼和退出登錄兩部分組成。修改密碼是用戶登錄系統后對登錄初始密碼進行修改的過程，退出登錄是用戶退出系統的過程。

6 結語

隨著國家應急管理的逐步發展與完善，海洋應急管理也逐步走上正規化與規模化，海洋應急管理平臺也由以海洋局機關為核心節點，向沿海省廳、海區分局和下屬單位延伸，海洋應急管理平臺的海洋應急研判依托對海洋應急事件、海區突發事件、觀測信息、監測信息和預警信息等各類數據的綜合分析，數據量越大，對應急事件的預判的準確性越高。數據交換應用系統的設計目標就是獲取各類海洋信息，增加各類海洋信息系統之間的數據交換，為海洋應急平臺提供龐大的數據支撐。對數據進行統一處理，提供統一的數據格式并用于后期的數據共享服務。本文在研究了XML格式在數據交換領域的特性與優越性以后，提出了以XML為基礎的數據交換模式，實現了數據交換應用系統的設計方案。

圖4 數據模型圖

圖5 數據添加實現

圖6 數據查詢實現

81-83.

[2]呂建華，曲風風.完善我國海洋環境突發事件應急聯動機制的對策建議[J].公共管理理論，2010（9）：131-134.

[3]中國海洋災害公報[R].國家海洋局，1995-2010.

[1]齊平.我國災害應急管理研究[J].海洋環境科學，2006，25（4）：

2016-11-10