引論：我們為您整理了1篇數據管理論文:范文，供您借鑒以豐富您的創作。它們是您寫作時的寶貴資源，期望它們能夠激發您的創作靈感，讓您的文章更具深度。
數據管理論文:海洋遙感數據管理論文
1多傳感器遙感影像數據建模
1.1建模原理
為實現多源異構遙感影像數據的統一管理，需要建立統一的數據模型。在邏輯結構上將遙感影像數據劃分為描述性元數據信息和數據實體，在業務流程上將數據建模分為元數據建模和數據建模。
1.2元數據建模
遙感影像通常格式特定、數據量大，而元數據是對影像獲取信息、質量信息、空間特征等的概括抽取，通常為文本格式、數據量小，具有信息豐富、讀取方便等優點[11-12]。本文根據元數據描述對象的特點和數據管理要求，構建了海洋遙感影像元數據的統一模型，如圖1所示。其中，數據要素級信息由元數據解析讀取獲得；數據集級信息可批量手工錄入，便于按照專項、區塊、調查單位及時間等對各專項數據進行管理；數據庫級信息在數據入庫時由系統自動掃描數據的存儲路徑、大小、狀態、權限等生成。
1.3數據建模
本文基于面向對象的思路方法，將多源異構的海洋遙感數據抽象表達為數據實體、元數據、空間特征和快視圖等基本組成部分及其對應關系。建立數據模型由E-R圖表示，如圖2所示。由于目前存檔的海洋遙感影像數據包含多種星源影像、航空影像和4D產品，且同源數據還包含不同級別、類型產品，因此，需要對每種產品類型數據分別構建數據模型，完成主數據標識確定、影像ID命名規則、數據對象和元數據識別規則等定義，流程如圖3所示。影像數據建模支持面向多種數據源的各種影像目錄模型的定義，具備對影像數據存儲方式、數據格式、坐標系統等參數的設置。
2多傳感器影像數據模型實體自動提取與匹配
2.1技術路線
為將構建的數據模型應用于實踐，本文提出多傳感器影像數據模型實體的自動提取與匹配技術，解決了如下幾個關鍵問題：①多源異構影像元數據自動識別與解析；②空間特征、快視圖及影像覆蓋范圍矢量自動提取與生成；③數據ID命名規則制定及數據模型實體間自動匹配。技術路線如圖4所示。
2.2元數據自動提取與輸出
根據構建的數據模型，本文建立了一套自動提取與輸出元數據信息表的技術流程，核心是從多源異構的元數據中提取出與元數據模型對應的字段信息，消除數據沖突，并利用元數據中關于空間特征的描述自動生成影像數據矢量覆蓋范圍。具體如下：1）元數據文件識別：依據建立的數據模型，對每類影像產品定義元數據文件格式。如ALOS影像產品定義“HDR-*.txt”為元數據格式。2）元數據格式解析及數據沖突消除：建立元數據提取配置文件，將多源元數據文件中的字段名稱對應至提取配置模板中，消除元數據命名沖突和語義沖突。命名沖突指相同字段（如影像左上角緯度）在不同元數據中有不同名稱（如ImageSceneLeftTopLatitude、SCENE_UL_CORNER_LAT等）或同一字段（如ProductType）在不同元數據中表示不同意思（產品類型或產品處理級別）。語義沖突指不同元數據對同一字段在描述方式、內容上的不同造成的語義不一致性，如投影帶號在不同元數據中表示為ZoneNumber和ZoneNo.兩種形式。本文數據沖突消除方法的實質是通過元數據配置文件將多源元數據字段名稱映射到元數據模型的全局名稱，通過提取配置模板和輸出模板兩步實現。3）元數據信息提取：將元數據文件內容全部讀入內存，用程序分步定位的方法提取元數據字段信息。以ALOS影像元數據“UTMZone="51N"……”為例，提取投影帶號信息需先定位至“UTMZone”字段，查找“=”后、符號“"”之間的字符串，即為帶號“51N”。又如，XML格式的RAPIDEYE元數據文件中，提取成像時間需定位至以“<eop:acquisitionDate>”開始、“</eop:acquisitionDate>”結束中間的字符串，即為成像時間。元數據信息提取將原始元數據字段對應至提取配置模板字段，生成中間元數據文件。4）元數據信息輸出：定義元數據輸出配置模板，將中間元數據文件字段對應至元數據模型中的字段。輸出配置模板按衛星影像、航空影像、4D產品和動力衛星數據等設置四類。輸出時還可對模板字段進行批量統一賦值。5）矢量范圍輸出：由元數據提取影像四角坐標值，調用ArcGIS腳本語言函數CreateFeaturesFromTextFile_samples()，將四角坐標文本文件、分隔符、輸出矢量文件和空間參考基準作為輸入參數，生成帶有空間參考信息的ShapeFile格式的影像范圍矢量。
2.3基于GDAL的快視圖自動提取
以往快視圖作用僅定位于數據瀏覽不同，本文提出的數據模型要求將快視圖匹配至影像空間特征，并錄入關系型數據庫實現集成管理。然而，影像產品數據集中提供的快視圖通常不包含空間坐標信息，因歷史原因各單位匯交數據中快視圖或已丟失或因重命名已不滿足數據模型識別要求，加之航空影像、4D產品通常不具備快視圖，快視圖自動提取面臨較多問題。因此，針對多源異構影像，本文基于GDAL（GeospatialDataAbstractionLibrary）對快視圖自動提取并匹配至空間特征，流程如圖5所示。GDAL是X/MIT許可協議下的開源地理柵格空間數據轉換庫，支持幾乎所有常見的遙感圖像文件格式的讀取、格式轉換和重采樣等基本操作。本文選用開放源代碼的GDAL庫作為多源影像的訪問引擎，為影像的訪問和基本處理提供統一接口。提取后的快視圖具有了和影像文件一致的空間坐標和數學基準。
2.4數據模型實體自動匹配
本文在分析各類影像產品數據建模的基礎上，提出基于規則的影像ID命名方法，通過指定影像惟一ID實現影像數據文件、快視圖、元數據和矢量范圍的自動匹配。具體如下：1）針對特定影像類型，根據數據模型定位至元數據文件，確定元數據存放目錄，將元數據上級文件夾記為ParentDirectory(1)。定位至元數據的好處在于：與元數據信息提取的過程相一致避免重復搜索；部分影像數據分波段存放（如中巴、TM等）或分塊存放（如WorldView），定位至影像文件很難形成與影像數據包一對一的關系。元數據文件通常與影像文件在同一目錄、名稱一致，并且元數據中通常有影像文件名信息。2）制定影像ID命名規則，標識惟一影像數據包。通常情況下，元數據文件名能夠標識惟一影像數據包時，采用元數據文件夾名命名；若不行，則需要考慮數據文件名、或上級（ParentDirectory（1））至上幾級文件夾名（ParentDirectory（N））的組合形式來命名影像ID。部分示例如表1所示。特征的相互匹配，為數據建庫和入庫管理奠定基礎。
3多傳感器海洋遙感影像集成與管理
根據數據模型和集成管理的要求，本文研發設計了多傳感器影像自動加工工具（以下簡稱“工具”）和海洋遙感影像管理信息系統（以下簡稱“系統”）。考慮到數據安全和保密需要，工具設計為單機版，系統采用C/S架構。系統采用.NetFrameWork框架搭建平臺，利用ArcGISEngine組件做專業性功能開發；服務器端部署Oracle11g數據庫和ArcSDE空間數據引擎，服務器端與客戶端通過內網連接。工具研發基于多傳感器遙感影像數據模型實體自動提取匹配技術，對不同影像元數據操作提供統一的配置交互界面（見圖6）。工具支持用戶根據影像類型和建模要求配置元數據提取和輸出模板，提供預定義的影像ID命名規則。模板與規則均以XML格式保存，支持用戶自定義修改，擴展性強。工具能夠從元數據和影像數據文件中批量生成元數據信息表、快視圖和空間特征一一對應的標準數據集，并通過影像ID與原始數據包自動匹配，與后端管理系統有效銜接。依據本文構建的多源異構影像數據模型，系統按照“元數據表+快視圖+空間特征數據文件”的方式，將數據存儲路徑記錄在二進制變長字段內，并將影像對應的元數據信息表、空間特征和快視圖信息存放于關系型數據庫表中，從而實現了海量數據的無縫管理。系統提供數據空間范圍、快視圖、數據包詳情的查詢瀏覽、分析統計等功能，并支持用戶通過選擇元數據記錄、下載相應的遙感影像數據實體。如圖7所示。數據建模是整個系統的核心內容。系統將入庫配置環節設計為功能模塊，按照“元數據項管理—資料建模—數據建模—編目管理”的步驟，向導式指引用戶完成數據建模和存儲規劃。其中，元數據項管理完成元數據項的定義；資料建模為元數據模型的定義；數據建模為每類資料構建數據模型；編目管理為數據入庫設計相應的數據節點。系統入庫需用戶提供影像數據實體文件存儲路徑，以及影像加工工具生成的標準元數據表、快視圖和矢量文件。入庫過程中，系統首先根據數據模型校驗是否能在指定路徑下正確識別遙感影像原始數據包。校驗完成后，系統根據主標識字段（即影像ID），自動匹配影像數據包、元數據表、快視圖和矢量范圍，并根據元數據模型判定輸入元數據表信息是否正確、齊全。在所有判定條件都滿足后，系統掃描并存儲每條數據文件的存儲路徑，并將元數據表、快視圖和矢量范圍入庫。系統支持用戶瀏覽查詢、編輯修改和數據下載等操作。用戶可按數據節點、數據查詢結果等方式瀏覽影像快視圖、矢量覆蓋范圍和元數據表，并可對元數據表編輯修改。數據查詢支持數據節點下自定義幾何形狀（線或多邊形）、跨數據節點綜合模糊查詢兩種查詢方案。數據下載通過元數據表、快視圖或矢量范圍等與數據文件的自動匹配，在記錄存儲路徑下定位相應數據文件并提供下載服務。
4結束語
本文基于面向對象的思想，將多源異構的海洋遙感數據抽象表達為數據實體、元數據、空間特征和快視圖等基本組成部分及其對應關系，構建統一的數據模型。從數據要素級、數據集級和數據庫集，建立了統一的海洋遙感影像元數據模型；從數據主標志判定、影像ID命名規則、快視圖判定等方面完成了各類遙感影像產品的數據模型構建。采用“元數據+快視圖+空間特征數據文件”的管理方式，實現了海量數據的無縫管理。依據構建的數據模型，本文提出多傳感器影像數據模型實體自動提取與匹配技術，實現了數據實體與元數據信息、空間特征和快視圖的自動提取與匹配，構成了多傳感器遙感數據實體與元數據一體化集成管理模式的基礎，并在我國現有海洋遙感影像數據管理系統中得到了成功應用，從根本上實現了海量多源遙感影像數據的統一集成和靈活管理，提升了現有海洋遙感數據的信息化管理服務能力。
作者：王祎婷 邢喆 李四海 李艷雯 焦紅波 單位：北京師范大學 地理學與遙感科學學院 國家海洋信息中心
數據管理論文:油氣井生產數據管理論文
油氣井生產數據管理軟件的總體設計思路是利用DTU配套的ActiveX控件實現了GPRS透明傳輸；當DTU數據上傳到數據管理中心時，觸發數據采集、解碼、存儲等一系列動作，并利用DundasChart控件繪制實時數據曲線。另外，軟件根據用戶界面操作，觸發數據查詢、歷史曲線繪制、報表導出、參數設置等功能。
1功能模塊設計
油氣井生產數據管理軟件有三個功能模塊：數據采集與存儲、數據查詢與導出、系統設置。數據采集與存儲：通過ActiveX控件獲取進口DTU上傳的數據，然后根據系統設置中的數據結構對數據進行解碼和校驗。將數據存儲于數據庫對應表中，并同時將數據寫入Dun-dasChart控件，重新繪制對應井的曲線。數據查詢與導出：通過井號、起始時間、結束時間等關鍵字段，進行組合查詢，查詢的結果以報表和曲線形式呈現，可以對數據進行增加、刪除、編輯等操作，也可以導出到EXCEL報表中，方便用戶進一步使用或分析數據。系統設置：為其它模塊正常運行提供基礎參數，包括生產數據管理軟件使用的網絡IP、偵聽端口號、DTU注冊ID、DTU通訊密碼、DTU對應的井號、實時監控的范圍、告警閥值、數據結構（數據解碼與校驗）、數據庫備份與還原、用戶名和密碼以及擁有的權限。
2數據庫設計
數據庫設計遵循第三范式的規則，數據表中的每一列數據都和主鍵直接相關，使得數據冗余度較低，數據庫結構合理。數據庫包括五張數據表：生產數據、DTU參數、生產井信息、用戶信息、本系統參數。生產數據表的主要字段為：DTU注冊ID、壓力、溫度、流量、液面高度、時間等。DTU參數表的主要字段為：DTU注冊ID、電話號碼、網絡協議、網絡IP、端口號、登錄時間、更新時間、工作狀態等。生產井信息的主要字段為：井號、DTU注冊ID、生產單位、開井時間、備注等。用戶信息表的主要字段為：用戶名、密碼、所屬部門、角色、權限等。
3曲線設計（顯示沒一點的值）
采用DundasChart控件為生產數據管理軟件提供先進的數據可視化功能。利用DundasChart控件創建實時曲線和歷史曲線，兩種曲線在元素布局上保持一致，方便使用者快速獲取和理解曲線中所蘊含的信息，但在樣式設計上采用不同風格，以便使用者快速區分實時曲線和歷史曲線。另外，實時曲線是不斷向左滑動的，當有新的數據時，首先刪除最早的數據，然后添加新的數據點，始終保持最近五個數據點的曲線。歷史曲線根據查詢結果繪制曲線，同時顯示所有符合查詢條件的點。當使用者更換查詢條件或修改數據時，歷史曲線會重新繪制。生產數據管理軟件最多同時顯示六口井的實時曲線，同時監控所有井的狀態；當生產數據超過告警閥值，軟件會彈出警告提示；如果當前顯示的實時曲線不包括該異常井，軟件會用異常井的實時曲線替換當前顯示的一口井的實時曲線。另外，實時曲線和歷史曲線可以放大和縮小，隱藏或顯示告警閥值線，隱藏或顯示指定井的曲線。
4軟件實現
生產數據管理軟件在.NET平臺上，使用C#技術在Micro-softVisualStudio2008環境下進行開發，后臺使用SQLServer2005數據庫，GPRS通訊使用OCX(ObjectLinkingandEmbe-ddingControleXtension)控件，繪制曲線采用圖表控件。
作者：胡軍 單位：中國石化江漢油田分公司石油工程技術研究院
數據管理論文:醫療秘密共享技術數據管理論文
一、秘密共享技術
使用秘密共享技術可利用多個數據中心形成低成本的醫療數據云，實現云計算時代的數據管理要求，即不需要自己保管關鍵數據，有安全的地方保存關鍵數據，任何地點、任何時間可使用數據，僅合法用戶可訪問數據，降低初始投資和運營成本，確保業務的持續性。秘密共享也是一種加密技術。以Shamir［1］的（k，n）門限秘密共享方案為例，其原理是將秘密消息加密并分割成n個分享份額后分布存儲到不同的遠程數據中心，多個數據中心構成低成本的醫療數據云。每個數據中心存放的單個分享份額看起來毫無意義，傳輸和存儲不再需要額外的機密性保護，秘密只能從不同數據中心收集滿任意k個組成的授權子集中得以恢復，而對于不足k個分享份額的非授權子集，即使擁有無限計算能力和無限大的存儲器也無法恢復秘密，因為秘密共享技術的安全性不像傳統加密技術那樣基于復雜的計算，而是基于信息理論，所以可保障秘密的長期安全性，目前主要用于安全要求較高的密鑰管理方面。此外，n個分享份額具有冗余性，即使任意（n－k）個分享份額遭到損壞或因網絡故障不能獲取，也能從其余的k個分享份額中恢復出秘密，這可保障業務的持續性。秘密共享方案可以是的，也可以是不的。（k，n）門限方案具有的安全性，即少于門限值k個的分享份額得不到原始消息的任何信息，方案的缺點是每個分享份額的長度≥原始消息的長度，即所有分享份額的總容量≥原始消息的n倍，如果用于數據量很少的密鑰共享是沒有問題，目前實際應用的幾乎都是秘密共享方案，但對于數據量較大的醫療數據管理來說，效率和安全一樣重要。
二、提高秘密共享技術的效率
要提高秘密共享技術的效率首先可從算法入手，目前典型的秘密共享算法是Shamir［1］的多項式插值法，這種算法的優點是不管（k，n）門限方案中k和n取什么值，都能用通用的公式實現加密和解密。有作者提出了（k，n）門限方案的異或運算方法［2－4］，異或運算的效率要比多項式插值法高很多，這種方法沒有通用的加密或解密公式，不同的k和n取值，需設計不同的加密和解密方法，這使得加密和解密方法也成了秘密的一部分，雖然通用性不高，但安全性更高。Yamamoto［5］提出的（k，L，n）秘密共享方案可大幅減少計算量和傳輸量，該方案被設計成1個原始消息s可從n個分享份額中的任意k個分享份額獲得重構，從任何（k－L）個或更少的分享份額中得不到原始消息的任何信息，但可能會從（K－j）（其中，j＝1，2，…，L－1）個分享份額組成的跳板（Ramp）集合中獲得一點兒有關原始消息的信息，由于該方案可能會犧牲一點安全性，所以被稱為不的秘密共享。但根據對已有（k，L，n）方案的具體算法的研究發現，Ramp集合的不安全性是可以避免和消除的。此方案的優點是：每個分享份額的位長是原始消息長度的1／L，所有分享份額的總容量降為原始消息的n／L，這將使計算量和傳輸量比（k，n）方案降低大約L倍。（k，L，n）方案的概念自提出以來，根據廣泛的國內外文獻檢索結果顯示，目前國際上實際的應用案例還非常少，迄今還沒發現任何醫院使用這項技術進行數據安全管理。
三、秘密共享服務軟件
我們開發了秘密共享服務測試軟件，使用了異或運算的（3，2，4）Ramp秘密共享技術，發現該技術可勝任大容量醫療數據的分布式存儲。該秘密共享服務軟件可為用戶提供遠程備份、遠程訪問、共享與交換等醫療數據的安全管理功能。用戶通過常規方式在指定文件夾中存儲1個文件，該文件就會被自動加密并分割成4個子文件，子文件又被分布存儲到4個數據中心，每個數據中心存放的單個子文件毫無意義。用戶隨時隨地再次登錄并打開文件時，秘密共享服務軟件又自動從不同的遠程數據中心收集任意3個子文件，恢復出原始文件，同時相關聯的應用程序會自動開啟，文件又可被編輯和瀏覽。任何一個子文件遭破壞或因網絡故障無法獲取，也不會影響文件的恢復。將秘密共享服務軟件用于醫療數據的遠程備份可兼顧安全性和冗余性，從而保障業務的持續性；用于遠程訪問可使遠程工作者無需隨身攜帶數據，隨時隨地通過賬號遠程登錄秘密共享服務文件夾抽取數據；通過多用戶共享1個秘密共享文件夾可為多用戶或多機構的醫療數據交換與共享提供多一種選擇。
四、秘密共享方案的優勢
1．兼顧安全性和可用性 由于存儲的數據已被加密成非敏感數據，傳輸和存儲不需要額外的機密性保護；分割出來的子文件被分布存儲到幾個不同的地點，可應對大范圍災難的發生；子文件具有（n－k）個冗余備份，即使（n－k）個子文件被偷竊或由于網絡故障等原因不能即時獲取，也不會影響原始文件的恢復；少于k個子文件則不能獲知有關原始文件的任何信息；用戶不需將敏感數據小心地攥在自己手里，合法用戶可隨時隨地遠程抽取所需要的數據，避免了隨身攜帶數據可能導致的數據丟失和泄露的風險，如筆記本電腦被偷或閃存的丟失等。2．高效 加密和解密使用異或運算比傳統的多項式插值法快很多，同時，（k，L，n）Ramp方案又使得計算量和傳輸量比傳統秘密共享方案降低了約L倍。3．經濟 使用秘密共享技術構建的醫療數據云是低成本的存儲資源，子文件的傳輸和存儲不需要額外的隱私保護措施，降低了醫療機構的初始投資和運營成本。
作者：龔慶悅 胡孔法 龔志千 申俊龍
數據管理論文:聯通用戶數據管理論文
1部門信息維護
（1）部門管理：按行政線展示，通過行政管理關系管理部門；按業務線展示，通過業務上級部門關系管理部門。系統缺省提供已有涉及渠道管理部門信息，數據來源M域系統、B-SDM系統、集中渠道系統。部門修改功能。支持按部門名稱或部門編碼模糊查詢。（2）部門行政關系查詢：系統缺省提供已有涉及渠道管理部門信息，數據來源總部管理數據庫。部門關系樹按行政管理部門建立，即可進行行政管理部門查詢功能。（3）業務部門管理：系統缺省提供已有涉及渠道管理部門信息，數據來源總部管理數據庫。部門新增、修改、刪除和查詢功能。（4）部門補充信息：將新增的部門添加行政管理部門。（5）部門補充業務線：將新增的部門補充業務線。（6）部門導出：對部門查詢出的內容進行導出。
2人員信息維護
（1）自有人員信息管理：支持對部門的人員信息的選擇添加、修改和查詢功能。支持人員修改時對渠道名稱的修改。支持人員添加與管理渠道之間的維護。（2）自有人員導出：查詢出符合條件的聯通自有人員信息，并且將這些信息導出為EXCLE格式。（3）社會人員導出：查詢出符合條件的歸屬渠道社會人員信息，并且將這些信息導出為EXCLE格式。（4）社會人員帳號管理：支持對社會渠道中的人員信息、帳號信息的新增、修改、刪除（注銷）功能。支持批量導入注冊功能。支持區分人員是實體人員還是虛擬人員，對于標記虛擬人員的員工禁止登入使用系統。支持對是否客戶經理以及客戶經理類型的區分。支持新增人員與管理渠道之間的維護。（5）虛擬人員維護：查詢出歸屬地域以下的所有存在人員賬號信息的自有人員信息。提供虛擬人員新增功能，虛擬人員新增必需要掛靠已有的自有人員帳號下。提供虛擬人員修改功能。提供虛擬人員注銷功能。提供虛擬人員詳細信息查看功能。
3數據變更提醒
變更提醒：在我的工作臺中人工處理M域發起的部門新增、修改、注銷操作。提供在我的工作臺中人工處理渠道發起的部門維護操作。提供在我的工作臺中人工處理B-SDM發起的部門維護操作。
4接口異常處理
記錄管理：查詢出操作員所在省份的記錄信息。通過【查詢明細】按鈕，可以查詢與記錄關聯的明細信息。通過【重新發送】按鈕，對發送失敗的明細信息重新發送。通過【人工處理完成】按鈕，將發送失敗的明細信息置為人工處理完成狀態。
5系統管理
系統管理員可以管理用戶分組，維護組的信息，通過增加新組添加一個新的用戶分類方式。系統有默認的超級管理員，只能做設置系統管理員的操作。由系統管理員設置部門管理員，部門管理員具有對整個系統的部門、用戶管理權。部門管理員能設置轄內下級部門的管理員。（1）權限管理：權限管理是按不同的工作范圍和角色管理系統操作者享有的資源及訪問的范圍，通過對一些要素的靈活控制實現權限管理，分為業務操作權限和數據權限。（2）日志管理：日志是系統運行過程中，在某一時刻對系統某一運行狀態的記錄。集中渠道管理的任一功能模塊，均應將處理狀態、處理結果、進程執行情況等信息記錄日志，供系統維護人員瀏覽查詢。
6結束語
本文對中國聯通統一用戶管理項目的建設和功能模塊做了詳細的介紹，通過總部的統一部署和管理，統一管理企業中各個系統的用戶的公共信息,解除各個系統中人員信息的冗余。實現了部門分級維護、人員按各種分類方式方便地管理和企業內部各個系統的單點登錄。
作者：李瑩
數據管理論文:教學資源元數據與數據管理論文
一、教學資源庫建設規劃
教學資源主要是指教學過程中教師和學生使用的課程資源，可以理解為教學過程中的軟資源。教學資源的元數據可分為兩個層次：直接對教學資源進行描述的元數據，稱為教學資源信息ERI(EducationResourcesInformation)；對教學資源的組織目錄進行描述的元數據，稱為教學資源目錄信息ERII(EducationResourcesIndexInformation)。其中ERII根據資源規模可抽象為多個層次。元數據是指描述數據的數據，是指與業務技術過程及企業使用數據有關的所有物理數據以及包含知識的信息，是指來自企業內外所有(軟件或其他介質含有的)物理數據和(員工和各種媒介中含有的)知識，包括物理數據的格式、技術和業務過程、數據的規則和約束以及企業使用數據的結構。教學資源中的元數據是指描述教學資源的類型、規格、屬性、聯系、約束等信息的數據。教學資源庫建設規劃如下。(1)提取教學資源知識單元，結合教學資源本身及其應用的特點，確定元數據的基本數據結構。知識單元是教學資源中可應用于交流使用并能完整描述一個知識點的最小單元。目前在知識單元劃分上還沒有具體的規范標準。一般由課程專家和教學專家參照教育部課程建設規范中的要求對教學資源進行三級劃分，將劃分得到的第三級資源作為知識單元進行管理，并向上逐層擴展，得到相應層次的粗粒度資源。(2)構建教學資源目錄樹。目錄樹從根節點開始，包含一個對其所有數據的層次視圖，并提供基于樹形的搜索系統。教學資源目錄信息ERII根據資源規模可抽象為多個層次。按照目前的慣例和一般使用情況，將課程資源按內容及其關系，劃分成大的章，章內再劃分小節，小節中又可包含若干更細分的知識單元。這種結構可以看作是教學資源目錄信息ERII的外在顯現，即教學資源目錄樹。(3)教學資源服務。在教學資源使用過程中，系統存在三種角色：資源提供者、資源管理者、資源消費者。資源消費者是指教師或學生，他們提出資源消費請求，包括對資源質和量上的要求；資源管理者即資源中介，是系統管理中心，主要管理ERI或ERII，并根據資源消費者提出的請求進行必要的計算，反饋消費者信息，滿足其需求；資源提供者是教學資源存儲中心，主要負責資源的存儲，并按接收到的指令為消費者提供相關資源。按照信息流動的不同方式，分析他們之間的工作模式，相應地設置層次結構。將資源與其元數據適當分隔存儲管理，在資源服務時采取資源信息處理和資源實體傳遞兩條線的方式，減輕資源的負擔，平衡網格環境的負載，有利于提高系統的整體性能。
二、關鍵技術
1.元數據結構設計
本文擬采用的元數據基本結構如右表所示。需要說明的是，該元數據結構根據教育部課程教學及大綱規范要求，結合本學科方向課程及教學實踐，以及資源管理和軟件開發的需要，并綜合其他相關因素形成。
2.教學資源目錄樹構建
目錄樹是指存儲有關網絡資源信息的特殊數據庫，把網絡環境中的各種資源都作為目錄信息，在目錄樹結構中分層存儲、訪問、管理和使用。目錄樹將分布式系統中的用戶和資源，以及其他對象統一組織起來，提供一個單一邏輯視圖，允許用戶透明地訪問網絡上的資源。一個由目錄樹支持的網絡系統是一個集成、網絡化、統一的系統，而不是各個獨立功能部分的簡單聚合。目錄的內容稱為對象類(ObjectClass)和項(Entry)。對象類描述什么信息可存儲在目錄中，而項把相關信息組合在一起，也可以理解為對象為抽象約束，項為信息內容。ERI之上的ERII逐層抽象或封裝生成，下層的ERII是上次ERII的一個項，這是逐層遞歸或遞推的過程，因此它們采用一致的管理操作方式，軟件算法具有可復用性。元數據信息采用數據庫方式存儲，方便檢索管理，而資源本身仍以文件方式存儲于磁盤。為了管理的方便和統一，資源庫的物理存儲與資源管理的目錄樹結構基本保持一致。通過目錄樹方式記錄存儲教學資源數據信息，與資源庫本身的層次結構(樹型結構)相統一，同時也與Internet及各種管理中的層次結構相一致，為教學資源管理提供方便，易于使用現有技術手段進行管理。
3.教學資源服務
在教學資源庫中，資源建設是基礎，資源管理是關鍵，要對資源進行深層次的應用，就需要對資源進行規范化建設和管理。資源提供者對資源進行存儲、傳輸等控制管理，資源的搜索、協調傳輸等任務主要由資源管理者完成。網格資源管理的目的是有效調度、管理、配置可利用資源，將實際上的異構環境轉換成一個虛擬的同構環境。基于網格的教學資源管理是網格資源管理的進一步延伸，需要完成資源尋址和定位，找到特定的教學資源。教學資源本身也屬于網格資源的一部分，教學資源節點與網格節點也是統一的。在基于網格的教學資源管理中，選擇基于的網格資源管理方法，滿足教學資源訪問中的結構關系，能夠方便地搜索到資源及資源信息所在的服務器，與Internet和網格層次管理結構一致，而且層次化的體系也有利于系統的維護和管理。系統在用戶和資源之間架起了一座橋梁。基于網格的教學資源體系，通過的方式將異構、分布的大型教學資源庫中的資源進行提取共享。通常一個資源請求任務被派分給一組Agent，這些Agent根據被請求資源特征，在構造層各計算節點間自主地移動，尋找資源信息，獲得資源服務，完成自身的任務，滿足用戶在廣域范圍內對教學資源的個性化請求。結構由三部分組成，如下圖所示。上面是用戶(消費者)，提供資源服務請求；下面是資源提供者，提供教學資源；中間是服務系統。消費者通過就近(或網格結點)提出資源服務請求，通過當前獲得的資源信息ERI以及資源目錄信息ERII，進行分析計算，并根據結果將請求任務分發到相關的，進一步處理；根據獲得的教學資源分布信息，按照一定的模式交付給用戶。
三、結束語
綜上所述，采用元數據對教學資源進行管理，在一定程度上回避了本體學習和語義這兩個目前還不太成熟的處理技術，為教學資源深層次地開發應用打下了基礎。采用層次結構，延伸使用了網格技術的成功之處，有利于教學資源的擴展和分層控制管理。資源中介主要對資源的元數據信息進行管理，資源消費者通過與中介交涉獲取所需要資源的信息，然后根據獲取的元數據信息從資源提供者那里獲得所需的資源實體內容。這樣將一個教學資源的獲取過程分為兩條線，從單一任務來看這增加了訪問成本和訪問時間，但對于網格環境的大量訪問來說，起到了任務分流和負載平衡的作用。
作者：許琦 馮羽靜 單位：臺州職業技術學院臺州中小企業信息化應用技術研究所 臺州職業技術學院機電研究所 臺州職業技術學院臺州中小企業信息化應用技術研究所
數據管理論文:天文數據設計數據管理論文
1數據庫入庫和管理工具AutoDB
隨著天文數據的日益增加，存儲和管理天文數據變得非常重要，尤其在天文數據的歸檔和管理方面，占有舉足輕重的地位。能夠很好地管理海量的天文數據就相當于在后續的科學研究中成功了一大半。通過對天文數據管理方面知識的了解，經過一系列的研究與開發，最終開發了一個高效的天文數據自動入庫管理工具AutoDB，旨在幫助天文學家提高工作效率，促進天文學研究的進展。
1.1AutoDB的設計思路與方法
在之前的裴彤等人的設計中，已經實現了天文數據的自動入庫，該工具采用Python[11]語言編寫，并且能夠自動地添加pcode字段，建立HTM（HierarchicalTriangularMesh）[11]索引分區，便于以后的交叉認證工作。HTM是一種多層次的、遞歸的球面分割方法，可將天球分成多級的三角網絡，每個網絡都有一個pocde，利用HTM可以將一個大星表從邏輯上分割為多個小星表[11]，HTM分級算法采用C語言編寫，充分地利用了C語言的高性能和Python語言的高開發效率。然而該程序僅支持底層數據庫為MySQL，且只支持CSV格式的文件，且文件中的數據不能為空，若為空則會拋出錯誤，在使用方面具有一定的局限性。其HTM分區是對ra和dec進行計算產生pcode值來實現天空分區，同時使用pcode_htmN數據列來存儲這些值，然后對其進行btree索引，方便后續的高效查詢。首先，其計算的算法必須跟隨著后續數據的復雜性進行優化，其次，先計算在存儲勢必有I/0性能限制，使用btree一維索引間接性的對赤經ra和赤緯dec索引，無法利用天文數據的空間性，且若想實現一定半徑內的查詢需要非常復雜的SQL語句。為了解決這些問題，我們仔細地閱讀了裴彤等人的論文和程序代碼[12]，在深入分析其原理的基礎上，對自動入庫管理工具進行了更加的完善和改進：（I）底層數據庫同時支持MySQL和PostgreSQL；（II）針對PostgreSQL數據庫，使用一種新類型Q3C索引，其直接與數據庫進行交互，無其他I/0交互，直接對赤經ra和赤緯dec進行空間索引，并且提供簡單的SQL語句來實現復雜的查詢；（III）數據格式同時支持FITS格式和CSV格式；（IV）數據優化，若其中存在為空的數據項，數據項自動變為’9999’或者’NULL’，則入庫時不會拋出錯誤。下面分別展開闡述。一、底層數據庫架構工具的底層數據庫是基于MySQL和PostgreSQL兩種數據庫開發的。這兩種都是非常好的開源數據庫，對于選擇哪種數據庫更好取決于哪種數據庫更能滿足用戶的需求。之前采用的是MySQL數據庫，然而由于數據量的增加，數據表格越來越龐大，一個表格甚至達到了幾十億行，對于表本身的容量遠遠地超過了物理內存的大小，甚至出現了連建索引也不能改善性能的情況，這樣查詢時間會將大大地延長，在此情況下非常有必要對數據進行分表管理，即將表拆分為一系列較小的、與之相關聯的表來進行替代，通過對子表的數據查詢，就相當于對整個表進行了查詢操作。對基于MySQL數據庫分表來說，取決于數據引擎(InnoDB)，不支持哈希分區表，而PostgreSQL數據庫支持臨時表、常規表以及范圍和列表類型的分區表。而且PostgreSQL的表分區是通過表繼承和規則系統完成的，所以可以實現更復雜的分區方式。且在索引方面，PostgreSQL支持B-樹、哈希、R-樹和Gist索引，MySQL取決于數據引擎，大多數為B-Tree索引。由于天文數據具有空間屬性，位置坐標為（赤經ra，赤緯dec），其索引會是一個二維的。建立一個高效的索引非常重要，使用第三方擴展庫如Q3C索引即是采用的二維索引，又如使用PGSphere中的GIST索引，會使數據的查詢更加高效。所以在當數據量非常大的時候，或者需要使用到第三方庫時，對于空間點索引時，采用Postgresql比采用MySQL要方便得多。但若數據量不是很大，對于億行級以下的數據量，不需要采用第三方庫去支持創建索引的數據，則是采用MySQL比較好。同時MySQL的性能方面要比PostgreSQL較為高效。面對種種數據管理的需求，我們增加PostgreSQL作為該入庫工具的底層數據庫是必要的，天文工作者可以根據自己的需求存儲到不同的數據庫中。二、Q3C索引龐大的數據儲存在數據庫中，若想能夠高效的使用這些數據，必須對其數據創建索引，索引不僅能夠加快數據的查詢速度，而且會使數據的管理變得簡單容易，可以大副提高系統的性能。當然索引的創建也不是越多越好，因為索引過多會隨著數據量的增加而加大數據庫的負荷，就起不到提高系統的性能的作用，反而會降低性能，所以索引的使用要得當。在本系統中，由于我們是對天文數據進行入庫管理，天文數據的復雜性、空間性決定了普通的一維索引并不能很好地解決天文數據的查詢管理要求，所以我們是用了一個全新Q3C(QuadTreeCube)對天空分區索引，其能夠很好地對天文數據進行二維的空間索引，Q3C索引方案為開源項目運用于數據庫PostgreSQL中，大家在使用的同時也可以隨時進行修改，非常適用于學術研究，由于直接運用于數據庫，使用者不需要書寫任何算法，相比于HTM，首先需要對天文數據進行分區計算pcode值，然而分區計算算法需要由使用者編寫，這樣會無形地增加風險，同時也帶來了復雜化。Q3C的產生是專門針對天文數據的，其目的性非常明確。雖然普通的索引如btree也能夠用于天文數據，但是如果需要進行錐形查詢，在不使用Q3C索引的前提下，其查詢SQL語句會非常復雜，并且查詢速度非常慢，而且也只能運用于數據量較少的情況下，數據過多極有可能導致內存不足而出現程序卡死現象，然而上面的問題對于Q3C索引來說都不存在，所以這種基于四叉樹的空間索引Q3C就顯得非常實用了。Q3C索引不僅能夠提供天文數據特有的查詢，而且也提供交叉認證功能，這對以后的數據處理來說，很大程度地簡化了工作量，同時又容易使用，而且不論是在查詢方面，還是交叉認證方面，Q3C會提供的簡單的SQL語句就能夠執行處理工作，而HTM方面則需要從數據庫中提取數據，然后利用算法進行處理，當數據量非常大的時候，程序的性能就會受到影響。三、支持的數據文件格式入庫管理工具同時支持兩種類型的數據格式文件：CSV(Comma-SeparatedValues)格式文件和FITS(FlexibleImageTransportSystem)格式文件。CSV文件由任意數目的記錄組成，記錄間以某種換行符分隔；每條記錄由字段組成，字段間的分隔符是其它字符或字符串，最常見的是逗號或制表符。FITS格式是天文學界常用的數據格式，它專門為在不同平臺之間交換數據而設計。1988年的國際天文學聯合會IAU（InternationalAstronomicalUnion）大會指定IAU的FITS工作組全權負責此格式的修訂。FITS文件由文件頭和數據組成。在文件頭中存儲有對該文件的描述，如觀測目標、源的位置、觀測時間、曝光時間等信息，同時也可以在文件頭中注明觀測時的視場、精度等，便于后期的數據管理和分析之用。文件頭部分每行占80個字符，并以END結尾。FITS文件的容量大小通常比相同數據量的CSV文件小，在本地存儲中占用硬盤容量小，且天文數據文件采用FITS格式存儲的文件占大多數。針對FITS格式文件數據，我們開發了一個分析FITS文件頭文件的工具，用來得到頭文件中表格數據中的列名和每個列對應的數據格式，方便天文學家在使用入庫工具時編寫readme文件。在輸入不同格式文件時，工具會自動地判斷文件的格式選擇相應的程序實現自動入庫。四、存儲數據的優化龐大的天文數據中有時難免會存在的超過數據庫中較大數據存儲大小的數據或者小于數據庫中支持的最小數據，不過在數據庫中可以自己定義數據類型來支持導入的數據，但這樣便失去兼容性了，使得不同數據庫之間數據的交換和融合變得很困難，而且在對于文件中的數據項為空的時候，存儲到數據庫中會產生一些錯誤，所以在入庫之前很有必要先對數據進行優化。因為不符合要求的數據非常少，而且改變其大小不會影響到后續的數據分析環節，故在入庫前，在程序中把超出數據庫較大支持數據的記錄數和小于數據庫最小支持數據的記錄數更改為數據庫所支持較大和最小的數據記錄數，同時對于文件中為空的數據項，程序會根據數據類型的不同，自動的填充‘9999’或‘NULL’字樣，方便數據的錄入和后續的計算分析。
1.2AutoDB流程圖
在存儲FITS格式文件的數據時，我們還專門開發了一個分析FITS文件頭文件的小工具，方便天文學家存儲時選擇自己想要存儲的數據列。在使用過程中，天文學家也不需要編寫任何的代碼，同時該工具有很好的易用性。根據不同的格式文件，有著不同的入庫流程，下面給出了文本CSV文件和FITS文件的入庫流程，如圖1所示。
1.3AutoDB系統環境支持
AutoDB采用Python語言編寫，推薦使用Linux操作系統。由于Python是跨平臺型語言，若需要在WINDOWS系統中使用也非難事，需要安裝Python，一般的Linux發行版本都會自帶Python程序，同時也需要下列數據庫系統（異地或本地均可）和第三方庫作為支持：1)PostgreSQL(9.0+)：支持近期的SQL語法，更高的功能完整性。2)MySQL（5.1+）：性能非常的高效。3)Q3C（QuadTreeCube）：一種基于PostgreSQL數據庫的新的天文數據的索引概念，提供海量天文數據的查詢與融合。該工具中同時嵌入了一個很好的虛擬終端，用戶可以根據虛擬終端的反饋，了解自己在使用過程中出現了哪些錯誤，從而糾正錯誤，使得程序地運行。
1.4AutoDB圖形用戶界面
AutoDB圖形入庫界面如2所示，用戶可以選擇入哪種數據庫，入庫的數據文件及數據的說明文件，創建HTM的級數，每次分次上傳的記錄數，赤經赤緯列要指出等。在這里，用戶可以直接點擊程序運行圖形界面，也可以手動地在命令行中使用命令來運行圖形界面，其圖形界面和主程序是分開的，其協助用戶按照各個參數，并收集起來，按照一定的規范得到收集的參數，供主程序使用。也就是說主程序不依賴于圖形界面，用戶也可以手動地編輯被指定的文件來運行主程序。FITS頭文件分析工具會把FITS頭中的數據輸出到文件中，該文件名由用戶定義，在FITSSOURCEFILE對應的一行中瀏覽添加FITS源文件，然后在FITSHEADFILE一行中輸入想要創建FITS頭文件名，界面如下圖3所示。在使用入庫工具時，用戶需要編寫readme文件供程序使用，其格式如下：及時行為各列列名（即數據庫表中的列名字段，請參照MySQL/PostgreSQL對字段命名相關文檔），以一個或者多個空行分隔；第二行與及時行相對應，為每列的數據類型（如：float、char、varchar、double、int，具體請參照MySQL/PostgreSQL數據類型相關文檔[13]），同樣是以一個或者多個空行分隔，內容中不能有引號，字段不能為空或NULL。同時在對FITS文件進行入庫時，需要參照頭分析工具得出的頭文件以及格式轉換文件編寫readme文件。頭文分析工具得到的頭文件實例如圖4所示，格式轉換文件如圖5所示。編寫readme文件完畢后，即可使用自動入庫工具進行數據的錄入，數據庫可以自己選擇，數據庫服務器可以是本地服務器或遠程服務器。使用遠程服務器時，應該保障遠程服務器支持遠程連接，否則將會報錯。
2實驗結果
2.1Q3C索引與非Q3C索引的查詢性能比較
在使用索引的時候，我們最在意的是索引是否能夠提高查詢效率，對于具體選擇哪種索引方式，要看哪種索引提高的性能更高些。為此我們做了如下的實驗測試（在數據庫命令行的形式下使用SQL語句進行查詢的實驗）。實驗數據為Pan-STARRS數據，總共11,495,847個星表源數據。對比使用Q3C索引情況下和不使用Q3C索引（對ra與dec進行B-tree索引）的情況下，實現以赤經赤緯（5度,50度）為中心，查詢半徑在0.1度到0.9度變化范圍內的錐形查詢，比較隨著提取結果源數目的增多上述兩種方案的查詢時間，其結果如圖6和圖7所示。我們從圖7和圖8中可以看出，隨著查詢半徑的增大，符合查詢條件的源數目也在不斷增多，同時查詢時間以近乎線性速度增長，說明查詢元組數目越多，消耗的時間也就越多。還發現使用非Q3C索引的查詢時間是使用Q3C索引時間的至少100多倍以上，可見Q3C索引方式的有效性。Q3C索引具有層次結構、平等區域、異維度分布等特性的天空分區方案，對天文數據的處理具有得天獨厚的優勢。特別是對于數據量大的情況下，我們非常有必要使用Q3C對數據索引，其表現不僅僅是數據查詢速度的提高，對日后的交叉認證起到了打下了很好的基礎。這也正是我們選擇Q3C索引的原因。
2.2AutoDB工具的應用
AutoDB能夠快速地將數據存儲到相應的數據庫中，上傳數據的速度與本地機器硬件性能、數據庫的配置以及數據庫服務器的位置（本地或異地）、數據量的多少以及索引的復雜程度都有著直接或間接的關系。建議在使用過程中本地機器中不要運行太多的其他程序。我們使用的是SDSS部分數據進行的實驗，總共有100,000,000行數據導入數據庫中，測試平臺使用的是兩臺計算機平臺，一個是本地數據庫平臺和程序運行平臺，另外一個是遠程數據庫運行平臺，通過百兆以太網訪問遠程數據庫平臺。具體配置如表1所示。在實驗過程中多次分別對本地和遠程數據庫進行了入庫，在入庫時將數據分割為100,000,00行，200,000,00行，400,000,00行，600,000,00行，800,000,00行，100,000,000行數據導入數據庫中，得出實驗結果，如表2所示。單從數據上傳的速度來看，MySQL數據庫的速度要優于PostgreSQL數據庫。
3總結與展望
針對當前天文大數據的特點，我們致力于開發高效、易用的海量天文數據自動入庫工具。考慮到天文數據的海量性、分布性等特點，我們分析了現有的入庫工具的優缺點，總結了前人的設計成果，結合實際需求，應用了高效的Q3C索引方案，改進開發了一個更加高效的大型天文數據自動入庫工具AutoDB，同時也參照了國際上SAADA工具的功能。該工具能夠更好地協助天文工作者方便地存儲、管理和處理數據。為后續研究工作中的數據融合、分析與挖掘做出了很好的鋪墊，是海量異地異構多波段天文數據融合和挖掘工作的根本保障。AutoDB還有很多需要值得改進的地方，因為我們底層數據庫的設計是基于MySQL和PostgreSQL，所以用戶的數據庫選擇方面只能選擇MySQL和PostgreSQL，這點對于用戶來說就有點局限性。在自動入庫的工作中，數據庫的性能是一個不能忽視的方面，性能是否良好會直接影響CPU的利用率，所以非常有必要對數據庫性能進行調優，在數據量非常大的時候，除了對數據表進行分表以外，也可以對數據庫內存進行調整，來達到最適合當前CPU工作的狀態內存容量，同時也可以安裝一些數據庫的監控工具和趨勢預測軟件，如vmstat、iosta、top、Munin等等，對數據庫進行實時的監控，保障數據庫在任何時刻都處于高效狀態。在程序的編寫方面，我們使用的是INSERT語句對文件的數據進行上傳的，而沒有使用更加高效的數據庫自己所帶的專有命令，如PostgreSQL的copy命令，這樣勢必會影響數據的插入速度和效率，由于專有命令沒有一個接口程序去引用，這個我們會在后續的工作中進一步研究。參照SAADA工具的設計思路和優點，如SAADA工具支持大部分的關系數據庫，SAADA不僅可以建數據庫，而且可以收集不同的數據進行整合分析，同時能夠將整理好的數據在web中真正地實現了數據的共享，下一步工作，我們也會根據需求進一步實現基于web服務，實現網頁建庫和網頁查詢，這樣工具使用起來就會更加的方便，也會根據大家使用的情況反饋來進一步地加以改進和提高。當然一個設計好的工具永遠不是盡善盡美的，結合不斷變化的需求，工具也要隨之調整，從而一步一步地健壯起來，這樣才能夠與時俱進，不斷地促進天文學研究的發展。
作者：鐘守波 韓波 張彥霞 趙永恒 何勃亮 單位：武漢大學國際軟件學院 中科院光學天文重點實驗室
數據管理論文:高速公路機電設備數據管理論文
1高速公路機電設備
要構建一個基于物聯網的高速公路設備數據管理系統，首先要對數據的源頭或者說是數據的歸屬地進行研究。主要有以下幾大方面:1)收費系統設備高速路收費系統設備是由控制機、欄桿機、報警器、收費顯示屏、車輛分離器、信號燈以及輔助的計重系統組成的［4］。所產生的數據主要有車輛車牌號、駛入高速時間和地點、駛出高速的時間和地點、車輛重量、車輛型號、收款數量。收費系統總監控室還要匯總收費站數量、收費島數量、收費人員工號等基本數據。2)監控系統設備監控系統一方面是設置在收費站的車道、收費廣場、收費亭內等收費監控地點;另一方面是設置了高速公路沿線交通狀況監控、設備運行情況、設備故障數據等。攝像機的種類也會因安裝和用途的不同采用不同的型號。3)通信系統設備高速機電系統的通信主要依靠光纖傳輸、數控交互、圖像數字數據傳輸、移動通信及電源等部分組成。建立基于物聯網的高速公路設備數據管理系統，對通信系統的要求較高，要求該系統要穩定、快速、實時，多采用光纖傳輸。
2基于物聯網的高速公路設備數據管理系統
2．1基于物聯網的高速公路設備傳輸通信
RFID技術是建立物聯網數據傳輸通信的基本技術，它主要包括閱讀器(例如手持機如圖2所示)、標簽、解讀器、應用軟件等部分組成［3］。標簽進入掃描磁場之后，能夠收到解讀器的射頻信號，然后將產品信息從芯片中提取出來，以一種感應電流的方式輸送給解讀器進行解碼，送到信息處理中心進行數據處理，形成數據流，通過無線網絡，例如WIFI、3G\4G網絡，到達數據中心。整個系統中的閱讀機是系統中至關重要的設備，一般會具有讀、寫功能，和信息控制和數據處理的功能，主要由收發模塊、控制模塊、耦合模塊和接口組成。應答器可以通過耦合從閱讀器那里得到能量和時序，如果存在地域、用戶、管理模式的差異，系統能夠更好的保持穩定性和安全性。針對高速公路機電設備的閱讀器數量較多，在收費站、收費廣場、收費亭以及高速公路沿途設備都要有設置。
2．2設備資產全壽命周期管理
通過對設備使用情況的登記、定期核查等措施，將高速公路設備的租賃、購買時間、周期維護時間、事故處理情況、報廢時間等數據輸入到設備數據管理數據庫中，并設定到期提醒功能，對周期維護進行警告提醒，對事故處理情況進行定期清查，對使用年數較長的設備要重點管理，對全系統的設備進行科學的分類，實現分類批量的管理和維護。對設備故障情況實現分析統計，提高設備利用率、降低維修率。
2．3設備數據存儲結構
本系統的數據存儲結構主要采用鏈表結構。鏈表結構的數據庫更方便更新，當設備出現維護或更換信息時，對鏈表進行及時的更新。在系統日常管理中，也可以將鏈表數據保存成文件的形式，但是如果需要重新更新數據，要將文件數據恢復成鏈表結構的有序表形式。鏈表中的數據類型包括所有的該系統中的有效信息，例如設備出廠時間、維護時間、使用次數等。
2．4設備數據挖掘
數據挖掘是從海量的數據中通過各種分析手段，例如關聯、聚類、演變等分析方法，找出數據中隱藏的某種規律，為系統的管理和使用提供有用的決策。本文所建立的高速公路設備數據管理系統儲存了大量的設備數據和信息，我們通過對設備數據的分類、排序、檢索等方法，通過關聯、演變等分析，能夠實現設備的使用率、設備的維修率、設備故障點統計的分析，進一步實現設備維護周期的科學制定、設備故障自動檢測和診斷等決策類的功能。對高速公路路況信息，收費系統數據的挖掘，能夠實現高速公路的路況分析、擁堵路段的分析，進一步實現高速公路收費站合理設置地點和數量的決策功能。為高速公路管理智能化提高了數據支持。
3結論
本系統通過物聯網的射頻技術建立高速公路數據傳輸和管理系統，實現了對高速公路設備的生命周期進行管理，以及機電全過程智能管理應用數據挖掘，實現對資產和過程的智能化感知、識別和管理。本系統能有效地為高速公路機電系統管理提供設備使用和采購分析等數據，為日后建立更為的高速公路機電設備智能化管理系統提供技術基礎。
作者：王琛 單位：山西欣奧特自動化工程有限公司
數據管理論文:COM組件數據管理論文
1系統設計
業務模型設計依據管道SCADA系統維護流程，采用面向對象思想對系統業務模型進行描述，業務模型如圖1。數據庫設計根據客戶方要求，數據庫設計需要每個區域每種類型的數據分開存儲，以防數據混亂，但基本就分為四類：字典數據庫、靜態數據數據庫、子表數據庫、測試相關人員數據庫。
2系統實現
2.1數據錄入
遵循“所見即所得”的思想，主要的錄入界面與報告證書界面保持高度一致，這樣每個頁面就代表了一個報告，為了更方便用戶使用，我選擇了用樹形結構的菜單。子表數據的錄入使用了DatagridView控件。
2.2數據查詢
本系統采取的措施為，將每個功能模塊需要查詢的屬性列名存儲在字典數據庫中，當我們指定了某個功能模塊后，就可以在數據庫中查詢需要被查詢的屬性列名。這樣不僅有效的達到查詢的目的，還使代碼量減少。
2.3報告出具
2.3.1Word報告出具
由于word本身是一個實現了自動化的COM組件，所以我們可以用C#語言和其提供的結構來訪問和操縱Word文檔。具體實現步驟如下：（1）生成word程序對象。（2）指定word模板路徑。（3）生成word文檔對象并打開模板文檔。（4）獲取模板中的所有書簽。（5）給所有書簽賦值。（6）保存word文件。
2.3.2Excel報告的出具
Excel報告的出具有兩種方案可以實現。一種是基于流和COM組件的操作，一種是只基于COM組件的操作。考慮到效率，我們選擇后者，實現步驟如下：（1）獲取到處的數據表。（2）將所有滿足要求的數據以流的形式全寫入一個excel中。（3）生成Excel程序對象。（4）定義一個新的工作簿。（5）打開模板工作簿（此模板可以說一個空的excel文檔，不起到任何作用,只是提供了一個載體而已）。（6）得到一個sheet。（7）將數據分割為一個一個的報告，并循環填充表格的表頭（可適當的增減行列，以達到需要的目的）。（8）另存為。（9）退出Excel，并且釋放調用的COM資源。
3結束語
系統從SCADA維護中心本身出發，根據其工作流程及計算機的實現技術，充分考慮SCADA維護中心獲取數據的方法與流向，使系統設計更為合理。開發過程遵循“方便實用、能解決問題，能夠滿足用戶需求”的根本原則，綜合考慮數據庫設計，數據庫建設以及軟件開發相關理論采用“高內聚低耦合”的原則，從科學、實用的角度劃分模塊。此系統的成功開發，將進一步規范評價工作，大大提高工作效率。
作者：李曉鵬 余傳梅 王偉
數據管理論文:環境監測數據管理論文
一、環境監測的特點
環境監測一般包括常規監測和污染源監測[6]。常規監測的對象是大氣、噪聲、河流等，污染源監測對象通常是一些工業單位，我國的工業單位眾多，單位之間有各不相同，給環境監測工作帶來了更大的困難。大氣、河流、降水甚至噪聲都是環境監測的內容，每一項檢測內容又有不同的監測指標，此外還涉及到污染物的排放量、治理效果等，所以環境監測工作量繁重。環境監測工作關聯性較強，而且還是按照一定的順序進行的。環境監測工作和其他的環保工作也相關聯，因此環境監測工作在滿足自身要求的同時，還需要同時滿足各項工作要求。必須建立健全環境監測數據管理系統。在進行數據統計分析工作時，必須按照要求生成格式化的標準報表與非標準報表。
二、環境監測數據管理系統
1、環境監測模塊
該模塊的功能在于通過時間觸發器連續或間斷地對某地區環境條件下的污染物性質變化進行判斷，同時對污染物濃度發展情況、趨勢進行預測，通過預測分析污染物的變化趨勢及其可能性，判定環境問題、污染問題發生的結果。環境監測通常是按照檢測目的劃分的，其中包括兩部分，即監視性監測、特定監測。在系統設計過程中，應當參照監測目的對相關模塊進行劃分，并在此基礎上確定監視性監測、特定監測子系統。環境監測數據管理系統，圍繞著空氣質量、水質質量以及廢棄物和噪聲進行常規性的監測，從而實現數據管理、預測和統計分析，重點數據繪制環境質量圖過程中顯示出來，從而使其更加的直觀。其具體的功能結構設計如下圖所示。
2、排污申報與環境污染源管理模塊
環保法及相關法規規定的排污單位，一定要履行申報義務，排污申報是污染管理系統的一個非常重要的功能。對于該模塊而言，其包含如下功能：數據匯總，即對污染源數據進行及時的匯總，采取相關信息資料。數據查詢：根據排污單位、污染源對其進行查詢；數據管理，即排污申請填寫，對污染源信息資料進行維護；數據分析，即針對性的對重點企業、污染源進行分析。在數據查詢功能設計過程中，查詢危險源以及排污企業，并且基于GIS技術的應用在地圖上對排污企業的具體位置顯示出來；按單位名稱和污染源名稱對其進行查詢，并且按地區對污染源進行查詢。數據分析功能設計為：分析污染事故緩沖區，對重點污染源進行分析，并且用圖表將其顯示出來；污染物歷年數據分析；地區污染物以及污染企業分析等。排污申報及污染源管理系統如下圖所示。
3、環境在線監控模塊
監控的主要內容是污染源排放在線監控煙塵、污水（主要是COD、流量、TOC以及總磷和pH值等），同時還包括污染源噪聲。首先，系統登陸。客戶端管理軟件提供具體的授權訪問模式，以確保該系統管理的安全性。授權用戶利用賬號、密碼登錄該數據管理系統，并且用戶權限由管理員進行分配。比如，管理員可以進行建庫、控制、監測以及其他高級功能；一般用戶則只能使用基本的系統功能，比如在線監測和基本的圖表報表打印等。系統登錄過程中，先輸入用戶名、登錄密碼，然后驗證身份，進入該系統主界面。其次，系統界面。客戶端管理界面為XP風格界面，客戶端管理軟件所有功能均可通過在界面右側選擇任務欄目實現，任務欄為可展開/收縮的風格控件，功能欄目為類Web風格的超級鏈接。界面中部為GIS地理信息系統，GIS的主要功能通過GIS工具欄實現。界面右側還有若干窗口顯示即時消息、系統報警以及快速查看數據等功能。數據輸入：把各類污染物的監測數據都存儲起來，構建成一個數據庫，這樣可以方便數據統計，也為技術人員的分析提供了數據基礎。通過先進的計算機技術，把這些數據都統一管理，然后按照監測地點、監測類型、監測時間等信息，分類處理這些數據，方便用戶選擇，使他們可以快速的掌握到想要了解的信息。此外，必須注意數據的存儲工作，多做一些備份，以免數據丟失，影響環境監測工作不能正常的進行。數據修改：錄入環境監測數據以后，管理人員要認真仔細的核對數據，要及時的修改和更正以及刪除無效的數據，確保數據的性[4]。數據修改有條件修改、當前記錄修改和替換修改的功能，這些功能的設置，可以方便管理人員快速、高效的進行修改工作，也能提高數據的性。數據備份：由于環境監測數據眾多，而且是環境監測分析工作的基礎，一旦丟失，就會給環境檢測部門帶來很大的損失，所以管理人員在管理數據的時候必須注意數據的備份工作，把數據存儲在不同的工具下，預防電腦崩潰使數據丟失。確保數據的安全性，保障環境監測工作的順利進行。數據查詢。數據查詢可以幫助用戶很快的找到他們需要的數據，使他們更好的進行環境監測工作。在查詢數據的過程中，用戶可以設置條件，然后數據庫中相關的數據就會自動出現，這樣可以減少查詢時間，提高查詢的效率，而且還能保障數據的性。數據輸出：數據輸出一般采用打印輸出、屏幕輸出[5]以及文件輸出三種輸出方法。打印輸出，顧名思義就是把數據報表通過打印機打印出來；屏幕輸出則是把數據制作成圖形和圖表的形式顯示在電腦屏幕上，供用戶查看，然后根據這些信息來分析環境狀況；文件輸出就是把環境監測數據、分析結果通過不同的文件格式存儲在磁盤上，可供用戶下載查看。數據統計：數據庫中的數據一般只是環境監測的原始數據，可供用戶進行查看、統計分析，然后更好的進行環境保護工作。數據統計分為常規統計和選擇統計兩種。常規統計是按照報表的要求進行的，要計算監測點以及區域的年、月、日均值等，然后保存。選擇統計則是按照用戶的定義條件進行的，靈活性較大。數據分析：數據分析是把數據轉化為圖形或者圖表的形式來展示數據信息，可以使用戶更加直觀、清晰的掌握環境的質量和變化情況，方便環境監測部門快速、高效的處理環境問題，更好的服務環境保護工作。
4、環境監測部門的職能
建立環境監測數據管理系統是為了更好的管理環境監測的數據，為了使環境監測部門管理人員可以、快捷的掌握環境質量信息，因此必須要符合環境監測部門的工作要求，提高工作人員的管理水平，滿足環境信息化的需求，做好環保工作。環境監測主要是監測污染源以及常規的監測，做好了這兩種工作才能保障我國環境污染狀況不再加劇。常規監測是一項銜接性很強的工作，需要經過一系列的過程：現場采樣，樣品登記，分析實驗等等，通過審核簽字才能生成分析報表。在進行常規監測工作的時候，一定要有序進行[3]，這樣才能保障分析報表的性。污染源監測也是一項非常繁瑣的工作，進行污染源監測工作時首先要委托登記，其次分配任務，然后按照現場采樣、樣品登記等的順序進行監測工作。現階段我國已經控制了污染源的排放量，只有減少污染源的排放，我國的環境質量才能得到徹底的改善。
三、結語
綜上所述，開發和實現環境監測數據管理系統，是當前我國環境監測部門的主要任務。建立健全了環境監測數據管理系統，可以提高管理人員的工作效率，可以增加監測數據的性，是用戶進行數據分析的基礎。系統的建立也實現了環境監測數據管理的科學化、現代化，而且把數據轉化為圖形圖表使用戶可以更加直觀的了解了環境質量的現狀，推動了我國環保事業的發展。
作者：周春何 張秀云 單位：麗水市環境監測中心站
數據管理論文:海洋水文氣象數據管理論文
1數據多重存儲和分級管理
數據多重存儲體現在同一數據既要存儲到本地數據庫中又要存儲到相應的文件中。存儲在本地數據庫中的數據即可用于本地管理與存儲，也可用于數據的查找和對外提供二次開發接口。存儲在文件中的數據以文本文件的格式被傳輸至海洋環境預報單位［4］。數據分級管理主要體現在數據庫結構設計上。將水文、氣象觀測數據進行分級存儲，分為臨時數據存儲表和最終數據存儲表。臨時存儲表中存儲當前小時進入數據管理系統的數據，并在后續小時數據進入系統后將臨時數據表中數據打包插入最終數據表中。臨時數據表限定數據量閾值，超過設定閾值后臨時數據表數據將被自動刪除。最終數據表每個觀測要素一個表，記錄該數據當天數據，包括該要素當天各整點數據值、數據極值和當天每分鐘的數據值。
2系統功能模塊設計
根據觀測數據使用對象的不同［5］，將系統進行模塊化設計為：數據上傳模塊和本地數據管理模塊。數據上傳模塊將實時觀測數據上傳至海洋環境預報單位；本地數據管理模塊用于海洋觀測站本地數據管理與存儲，并對外提供二次開發接口。此外，該模塊可根據業務需求生成數據上傳模塊所用的數據文件。系統結構類見圖2。軟件開發環境針對上述業務需求，采用了VisualStudioC＃2010作為軟件開發平臺，數據庫系統采用SQLServer2005。其中，VisualStudioC＃2010是一種現代的面向對象的程序開發語言，它使得程序員能夠在新的微軟．NET平臺上快速開發種類豐富的應用程序。．NET平臺提供了大量的工具和服務，能夠較大限度地發掘和使用計算及通信能力［6］。SQLServer2005能提供大型系統所需的數據庫服務，可實現成千上萬的用戶同時連接。SQLServer2005為這樣的環境提供了的保護，具有防止問題發生的安全措施，可在多個用戶之間有效地分配可用資源。此外，還可以在一臺計算機上運行多個SQLServer2005實例［7］。
3系統實現
3．1數據庫邏輯結構設計
海洋站水文氣象觀測數據要在海洋觀測站、海洋中心站、海區預報中心及國家預報中心等各單位使用，其中：海洋觀測站端僅使用本站數據；海洋中心站使用本中心站下屬各海洋站數據；海區預報中心使用本海區下屬各海洋站數據；國家預報中心使用所有海洋站的數據。這些數據是連續不間斷產生和使用的。因此，在建立海洋站水文氣象數據庫時，必須考慮大規模數據的存儲問題。在建立數據庫的同時，構建出符合海洋觀測預報業務的數據模型，設計了水文要素臨時數據表（tempdata＿sw表）、氣象要素臨時數據表（tempdata＿qx表）和風要素臨時存儲表（tempdata＿wi表）、風要素數據存儲表（WI表）、相對濕度數據存儲表（HU表）、氣溫數據存儲表（AT表）、氣壓數據存儲表（BP表）、降雨量數據存儲表（RN表）、能見度數據存儲表（VB表）、海水溫度數據存儲表（WT表）、海水鹽度數據存儲表（SL表）、潮位數據存儲表（WL表）等多個表格。其中，臨時表每個要素每小時1行數據，用于存放近3d每分鐘生成的實時數據。數據存儲表每個要素每天1行數據，用于存放整點值數據、極值數據以及該天每分鐘數據（表1至表5）。以上5個表為數據庫邏輯結構設計所需的表，其中表1至表3為臨時數據存儲表，表4為氣象要素數據表、表5為水文要素數據表，其余水文氣象要素數據正式表的表結構與表4和表5結構一致。此外，風要素表結構中DataXX為風向值與風速值的組合，即“風向值風速值”。
3．2系統程序實現與運行結果
3．2．1數據庫觸發器設計結構化查詢語言StructureQueryLanguage（SQL）是專門為數據庫建立的操作命令集，是一種功能齊全的數據庫語言。SQL主要由兩部分組成：DDL（DataDefinitionLanguage）和DML（DataManipulationLanguage）。其中，DDL是建立數據庫表及列的指令群，DML是操作數據庫記錄的指令群。以下SQL語句實現了海洋水文氣象數據庫觸發器的設計。上述程序以潮位（WL）數據為例，實現了水文要素的數據臨時表向正式表的級聯更新。其中，水文要素數據更新為本時刻00分數據到正式表本小時的更新。利用以上函數接口，實現了水文氣象數據管理，并被海洋站上位機軟件調用，完成了海洋站水文氣象數據的管理。
4結束語
系統利用數據庫技術和面向對象技術，整合現有觀測設備的數據類型，實現了海洋觀測數據的自動化管理，有效降低了海洋觀測系統的管理成本，同時系統為海洋觀測數據的模塊化管理和使用提供了對外接口。實現了海洋水文氣象觀測數據的模塊化和業務化應用，為進一步提高海洋觀測預報的精細化水平，更好服務于海洋經濟發展管理的支持能力奠定了基礎。
作者：李博 王斌 葉穎 王鵬 孫成龍 閆秦 單位：國家海洋技術中心
數據管理論文:橋梁結構海量數據管理論文
1海量數據管理系統的總體設計
1．1中央數據庫
中央數據庫部署在北京數據中心，采用Ora-cle/SqlServer群集，具體隨方案選擇而定。入庫方式:通過人工或網絡傳輸的方式獲取數據庫備份，經過導入程序入庫;中央數據庫存儲項目的歷史數據，其存儲數據量比現場數據庫要高出1～2個數量級。中央數據庫要支持快速的數據查詢、文件導入導出和Web訪問，主要功能如下:將經過處理的實時數據寫入現場數據庫;支持數據的歷史回放和離線分析;支持歷史海量數據庫的實時備份、清除和異地恢復;提供與評估軟件平臺的文件導出和數據接口;支持數據的后期操作和查詢、編輯、更改［3］。各模塊功能見表1，整體結構設計見圖2。
1．2現場數據庫
現場數據庫針對具體項目，部署在現場監控中心，存儲的是處理后的實時數據，要求定期備份、刪除、異地恢復、更新。實時數據的特點是數據量大，數據入庫較快。在設計現場數據庫的時候，主要考慮如下:各個監測類型原始數據互不干擾;數據寫入要求實時，考慮擁堵策略和故障恢復策略;靈活配置監測項、監測點的數據存儲庫表結構［4］;一定時期的歷史數據在線回放和分析;單一監測類型數據存儲(由于處理系統需要在較長時間內持續對采集數據進行處理，即使一種設備，持續累計多天的時候，數據量也會非常大，需要考慮以何種方式對多天數據進行組織)。現場數據庫配置版本為SQLServer數據庫。
1．3結構特征值數據庫
本數據庫主要存儲橋梁結構采集數據的特征值，包括結構應變、加速度、索力等原始數據的較大值、最小值、平均值及方差等，特點是數據量相對較小，但數據計算頻繁，使用頻率較高。此數據庫數據量小但關系較復雜，由于其入庫頻率相對于原始數據來說比較低，故采用較為簡單的單庫表結構。特征數據庫配置版本為SQLServer數據庫。
2海量數據庫詳細設計優化方案
2．1高速大容量數據存儲與管理
通過對系統的總體評估，擬采用以下措施解決系統中大數據量的存儲與管理問題。通過使用OracleRAC(集群)模式加強底層數據庫的處理性能;使用存儲過程的方式來進一步加強數據庫的交互性能;定期進行數據備份與清理，避免存儲過多的低使用率數據(比如，數據庫一般可以保持6個月到1年的數據，其它數據通過磁帶庫等存儲介質將數據備份轉移，減輕數據庫的處理壓力);對海量數據進行分區操作(例如針對按年份存取的數據，我們按年進行分區，不同的數據庫有不同的分區方式，而不同的文件組存于不同的磁盤分區下，這樣將數據分散開，減小磁盤I/O，減小了系統負荷，而且還可以將日志、索引存放于不同的分區下);建立廣泛的索引［5］。對大表建立索引，例如針對大表的分組、排序等字段，都要建立相應索引，一般還可以建立復合索引。當插入表時，首先刪除索引，插入完畢，建立索引，并實施聚合操作，聚合完成后，再次插入前還是刪除索引。要注意索引使用的時機，索引的填充因子和聚集、非聚集索引都要考慮。在對海量數據進行查詢處理過程中，查詢的SQL語句的性能對查詢效率的影響是非常大的［6］。在對SQL語句的編寫過程中，例如減少關聯，少用或不用游標，設計好高效的數據庫表結構等都十分必要。
2．2數據庫優化設計
橋梁結構橋梁索力數據量較大，由于實時數據處理系統平時的主要操作是橋梁索力的插入及數據查詢，對數據的實時性及可恢復性要求不高，并不要求的精度，允許一定的數據損失，對數據庫的一致性、并發性及事物的隔離性要求不高，但對于大數據的吞吐量要求較高，故可將其定位為針對插入操作的OLTP系統及部分的OLAP系統［7］。所以考慮降低數據庫的隔離級別和并發一致性控制以提高數據庫性能，優先滿足海量數據插入的吞吐量要求。Oracle版本的數據庫優化設計如表2所示。
3系統應用項目及領域
本系統已經軟件實現并應用到南京第4長江大橋的結構監測后期運營管理中，不但能較好的彌補新系統的數據處理與存儲管理短板，還能融合到已經投入使用的大型結構監測系統中。同時，本系統力爭建立一個基于結構監測的北京大型數據中心，中心數據庫主要服務于建立全壽命期的數字化、信息化橋梁數據中心，用于橋梁結構海量歷史數據的存儲管理和挖掘分析，為日后的離線數據分析和歷史狀態追溯提供支持。同時，以中央數據庫為基礎和平臺，根據結構的分析和報告編制需求，可以單項和并行的完成數據應用和管理。
作者：周兵 周鋒 單位：中交公路規劃設計院 橋梁結構安全監測事業部 河南中原水利水電工程集團有限公司
數據管理論文:國有企業數據管理論文
一、培養大數據高端人才
大數據管理與大數據應用都離不開大數據技術，但更離不開大數據人才。沒有人才，再先進的設備只能是“豪華擺設”;沒有人才，再先進的技術也只能是“紙上談兵”。因此，推進大數據管理，除了需要培養一大批的IT人才外，還迫切需要培養一大批大數據人才———數據管理師、數據分析師，造就一批數據科學家等高端人才。因為只有他們才能駕輕就熟處理海量的信息，并從中挖掘出“數據財富”。此外，面對全體員工傳播大數據知識，普及大數據技術，培訓大數據技能，奠定推進大數據管理的群眾基礎和技術基礎，同樣也是一項長期而艱巨的任務。
二、構筑大數據管理“一站式”工程，建設“大數據管理智庫”新平臺
1．加強內、外部數據的“一站式”管理。對企業來說，數據無處不在，無時不有，究其來源，無非企業內部和外部兩個渠道。內部數據的活水源頭是各單位、各部門、各專業的統計報表提供的數據;外部數據一方面是國家管理部門、行業管理部門、機構等的統計數據，另一方面是來自互聯網、移動互聯網、各種傳感器等信息感知和采集終端采集的數據。這些數據，日積月累，最終“百川歸海”，匯成大數據的海洋。大數據時代，企業通過建立“大數據管理智庫”，打破渠道的邊界，把不同來源的數據整合在一起，實施一站式管理，讓數據時時刻刻為企業提供服務。2．注重數據挖掘環節的“一站式”管理。企業數據挖掘過程也是數據發現和梳理的過程，其有4個重要環節:采集、存儲、分析、預測。企業建立了“大數據管理智庫”，對這4個環節實施一站式管理，可以大大“提純”數據價值。首先是盡可能采集異源甚至是異構的數據，去偽存真，多角度驗證數據的性和可信性。其次是要用到冗余配置、分布化和云計算技術，分類、過濾和去重，減少存儲量，同時加入便于檢索的標簽。第三是將高維數據降維后度量與處理，利用上下文關聯進行語義分析，從大量動態而且可能是模棱兩可的數據中綜合信息，導出可理解的內容。第四是將數據分析后預測出的結論應用到企業中去。3．突出價值鏈上數據的“一站式”管理。企業價值鏈可以分為基本增值活動和輔助性增值活動兩大部分。基本增值活動，即一般意義上的“生產經營環節”，如材料供應、成品開發、生產運行、成品儲運、市場營銷和售后服務。這些活動都與商品實體的加工流轉直接相關;輔助性增值活動，包括組織建設、人事管理、技術開發和采購管理。價值鏈的每一個環節都有相伴而生的數據。過去這些數據處在分散狀態。大數據時代，企業通過“大數據管理智庫”平臺，對這些數據實施一站式管理，有利于每一個環節的價值再創造和價值鏈的增值。
三、構筑大數據管理“一體化”工程，打造“大數據管理融合”新生態
1．大數據與云計算技術融合。大數據作為非結構化和電子化的海量數據，數量之大、類型之多、變化之快，前所未有。以云計算為代表的計算技術的不斷進步，為我們提供了強大的計算能力，從而構建起了一個與物質世界相平行的數字世界。國有企業推進大數據管理，就必須建立和完善自己的云計算系統，否則，就是“巧婦難為無米之炊”。2．大數據與市場調研的融合。大數據時代，沒有數據是不能的，但數據也不是萬能的。比如:數據不懂社交、不知道背景;數據不能反映客戶的心理;數據分析擅長的是“量”而非“質”等。因此，國有企業在推進大數據管理時，如果將傳統的市場調研智慧與大數據的巨大威力相結合，可能會在定性分析和定量分析方面產生巨大的優勢。尤其在背景分析、心理分析方面，可以彌補大數據的短板。大數據時代，沒有調查研究、沒有大數據，就沒有發言權，就沒有決策權。3．大數據與信息化建設融合。大數據發軔于信息化建設，伴隨著信息化建設的進程同步成長，但同時又遵循自身發展的規律，自成一體。改革開放以來，國有企業在信息化建設方面邁出了堅實的步伐，這為推進大數據管理奠定了扎實的基礎和一個高的起點。大數據時代，可以真正實現大數據管理與信息化“一體化建設”，相互促進，共同發展。4．大數據與電子商務的融合。大數據與電子商務是“前店后廠”的關系。電子商務在前臺直接面對客戶，大數據則在后臺充當“幕后英雄”，默默無聞為前臺提供強大支撐和品質服務。電子商務作為一個新的商業模式從真正的興起、發展，也僅僅只有短短十多年的時間。實踐證明，電子商務相較傳統的鋼鐵貿易交易，能夠極大節約時間、人力、資金和渠道成本，能夠更快速、更深入、更廣泛的開發消費市場，同時，也能夠密切聯系供應商、采購商、服務商等產業鏈上的各個環節，不斷拓展企業的發展空間。當前，由于制約鋼鐵企業電子商務發展的因素還很多，因此，鋼鐵企業電子商務發展非常緩慢，這顯然落后于時代前進的步伐。相信在大數據時代，電子商務將煥發出勃勃生機，成為鋼鐵企業獨領風騷的新的商業模式。
作者：李國甫 單位：武鋼大學
數據管理論文:高校電子數據管理論文
一、我省高校電子數據管理中存在的問題
1．高校信息化建設條塊分割，缺乏統一規劃
目前高校所開發與使用的軟件大多只針對特定的業務，沒有一個綜合的管理平臺，各部門各自為重，而部門對數據管理的意識不足，數據標準與格式不一，缺乏全局性的規劃，各個軟件系統生成的數據不具有兼容性，許多數據離開生成軟件便不具有可讀性，海量的數據不能為大眾所利用，成為信息孤島。正因為這些軟件生成的數據對軟件的依賴性，導致無法向檔案部門提供可利用的電子數據，不同的軟件生成的數據只能保存于不同部門的特定電腦或服務器上，由特定的人進行讀取，有些數據雖然能縱向傳輸，但無法實現真正的數據共享。此弊端首先表現在同一單位內部各部門之間無法進行高效通暢的數據共享和交流，協同辦公無法真正實現［1］。其次，由于數據不能共享，造成許多不必要的重復勞動。當同一套數據需要通過不同軟件向不同部門多頭報送時，形成了多個部門在做同一件事的格局。如果數據能共享且具有較強的可讀性或者各數據需求部門所需的數據格式一致的話，那么只需一個部門即可完成，作為一個單位，對外提供的數據也才會真正保持一致性。
2．高校電子數據缺乏統一管理
目前高校垂直傳輸的數據如何保管、利用沒有相應的規定，從而導致不必要的混亂。首先體現在網絡版業務軟件的推行使工作人員放松了紙質檔案存檔的意識，認為反正系統中隨時可以調用，沒必要再多此一舉。對于垂直傳輸的數據，正常情況下隨時都可以在軟件中調用，但是基層部門要不要保留數據，如何保留，上級部門也沒有硬性要求。一旦所使用的軟件系統出了問題，很容易導致電子數據的丟失，比如，省內某高校報教育部門的基層統計數據，是通過網上直報，后來上級教育部門的軟件進行升級與數據置換時將以前的數據丟失，要求各高校重新上傳以前的數據，而此高校統計員沒有及時進行數據備份，也沒及時打印紙質報表，一切工作必須重新開展。這種對系統的過度依賴思想給自己釀成了不必要的麻煩。其次由于高校電子數據分散于各個部門，而電子數據的可讀性低，一方面，許多電子數據離開數據生成軟件便不具可讀性，另一方面電子數據本身容易損壞而失去可讀性，如電腦遭受病毒攻擊可能導致電腦中的數據丟失，備份的電子載體如受到劃傷、潮濕、折疊等損毀，或者隨著保存時間的延長而變為不可讀，電子數據的這些特殊性迫切需要有專門的人、專門的設備與工具進行統一的保管與維護，定期對其可讀性進行檢查。此外，目前各單位購買的辦公軟件或自行開發的協同辦公系統，也主要停留在網上收發文以及公告、通知與新聞的。并且這些數據自動生成后都是存放在網站所處的服務器上，也沒有專門人員對數據進行管理，更談不上異地備份，一旦服務器損壞或者網站內容已過有效期，這些數據便會逐漸消失或人為刪除。因此，在信息化的推進過程中，電子數據的管理急需跟進。
3．高校電子數據的真實性缺乏相應規范
紙質檔案的真實性易于維護和識別，但電子檔案的任何修改通常不會留下改動痕跡，其真實性辨別的難度大。如果有人為因素進行偽造的話很容易達到目的，因此，電子數據作為證據的可信度遠不如紙質檔案。電子檔案的鑒定不僅要開展內容鑒定，還要開展技術鑒定、利用多種軟件硬件檢測設備，檢測電子文件的完整性、真實性與可讀性，即雙重鑒定才能實現［2］，從而導致電子數據的社會認可度相對于紙質檔案來說要低得多。
二、關于電子數據管理的對策
1．加強對電子數據管理頂層設計
教育信息化建設主要是以各類業務的需要為出發點，各自為營，沒有考慮數據的存取與易讀性及公眾利用數據的便利性。高校各業務部門都比較熱衷于各類業務軟件的購買與開發，但各類業務軟件的設計往往只考慮了局部業務流程如何進一步簡化，并沒有從學校信息化的總體規劃上去考慮，只考慮了本部門工作需要，缺乏頂層規劃。而網站建設也僅定位于網上審批和新聞，強調無紙化辦公，而對信息存儲、管理與使用等沒有給予應有的重視，缺少對數據資源的整合。我省高校教育信息化起步較早，上個世紀90年代末就成立了信息化領導小組，負責對全省高校的信息化建設進行規劃與引導，但高校檔案信息化建設近兩年才真正啟動，2014年底已完成了一期(省級平臺)項目，今年初開始組織開展教育系統檔案信息化二期工作，省教育廳主要負責省級數據中心建設，參與建設的高校主要負責本單位不涉密檔案目錄數字化及紙質檔案選擇性數字化等。目前檔案信息化平臺的構建只是針對現有的檔案資源的管理，還沒有針對高校各業務軟件的對接及相應電子數據的管理。我省信息化建設是分領域分部門推進，檔案信息化只是作為其中的一個子項目參與建設，并沒有真正融入信息化建設的全過程，因此，很多信息化建設項目忽略了數據的存儲、管理與利用，而側重于業務問題的處理及數據的垂直傳輸。因此，我們有必要在推進教育信息化的過程中，考慮電子檔案管理的要求，對電子數據管理進行頂層設計，建立全省高校數據中心，高校所有的業務軟件生成的電子數據最終都能匯集到這里，形成一個大的高校數據云，供大家隨時隨地利用。這樣不僅解決了數據的管理與存儲問題，還能大大提高數據的可利用性。
2．借鑒科層化管理模式，加強電子數據管理
“科層化”管理模式，是由德國社會經濟學家馬克思?韋伯在《社會組織與經濟組織理論》中構建的一種基于法理的，以實現高效率與合理化為目標的理想化的組織管理模式［3］。目前我省高校所使用的業務軟件種類豐富，同一業務軟件版本眾多，大量的重復開發與引進造成了資源的浪費，信息的重復采集大大降低了工作效率。省級教育行政部門作為科層式組織結構中的頂層管理者，可以承擔起省級高校數據中心的模型構建，確定數據中心需要匯集的基本數據類型與模型，組織開發相關的業務軟件與應用界面或向全國引進的軟件加以改造與完善，然后在省內高校推廣使用，這樣有利于統一數據的采集標準與格式，有利于數據的集中管理與利用。各高校作為科層化管理模式的中層，其職能是貫徹決策，使業務軟件在相關的業務部門得到應用，為軟件的正常運行提供必要的條件。高校各部門的工作人員作為基層工作者，主要職能是執行決策，對業務數據按要求進行錄入處理。借鑒科層化管理模式，明確各層級的職責，才可避免每個高校都搞信息化設計，每個業務部門都開發或引進業務軟件的現象。重復開發重復建設，造成許多的資源浪費，導致大量信息孤島的形成，背離了信息化建設所要實現的節約行政成本、簡化工作、信息共享、便于利用的目的。
3．制定相關的數據管理規定與標準
標準是對重復性事物和概念所作的統一規定，它是以科學技術和客觀實踐經驗為基礎的，其目的是為了獲得工作、生產、科研的秩序和社會效益［4］。制定相關的數據管理規定與標準能夠優化工作流程，簡化工作程序。對于數據的形成與管理，我們必須用相應的標準加以規范，實施前端控制，以規避數據格式的混亂，讓數據一產生就是標準的，包括其使用的語言、生成格式、字段名、字段長度、數據描述等等，只有這樣，信息化建設對電子數據的管理才能符合檔案管理的要求。此外，對于電子數據的真實性、安全性，電子數據如何鑒定和歸檔，電子印章的使用等問題都有待進行明確的規定。只有有了統一的規定與標準，才能實現電子數據的科學管理，為數據中心的構建與實施提供必要條件。
4．提品質案管理人員的業務水平
檔案工作者習慣于傳統的檔案管理方式，強調紙質檔案的保管。盡管現在數字檔案館的建設如火如荼，但也僅停留在電子公文、電子照片、電子視頻等電子文件的收集與管理，以及將紙質文件電子化方面，把信息化僅僅當作部門工作的計算機化。由于大部份電子數據離開相應的生成軟件便不具備可讀性，業務部門及檔案工作部門缺乏相應的技術實力，無法實現對業務軟件的設計與數據的轉換，沒有相應的實力對各類數據進行整合與開發。檔案工作者原有的知識結構已不適應電子數據管理的要求，面對五花八門的電子數據顯得無能為力。檔案部門既懂軟件設計又懂檔案管理的人才非常稀少，因此無法真正參與到信息化的設計當中去。信息化的設計過程中，為了簡化程序設計，往往也會忽視數據的存儲與管理這一塊，由于多方面的原因，檔案工作部門作為一個邊緣部門在信息化過程中常被邊緣化，因此，通過進修與培訓提高現有檔案工作人員的信息化建設水平，通過引進信息化建設中的中高端人才加入檔案工作領域，提品質案工作隊伍的整體業務水平，才能有實力參與到高校信息化的設計過程中去，才能在未來的信息化建設中發揮自己應有的力量。總之，我省高校的電子數據管理還處在一種分散的狀態，數據分布在高校不同的部門和網絡環境中，同時經過多年的信息化建設，高校各業務部門都已擁有自己的業務軟件，這些軟件由于使用的編程語言不同，使用的數據標準與結構不同，導致數據無法共享與直接利用，與信息化建設的初衷是相違背的。我們有必要對這些分散的數據進行集中管理，而要實現這一目標，就必須構建一個全省高校數據中心的模型，借鑒科層化管理模式，由教育行政部門組織開發各高校現有的業務模塊，包括學籍、教務、財務、科研、圖書、資產等管理系統，各高校通過統一的平臺入口將相關數據直接上傳到數據中心，真正實現數據的綜合管理與利用。
作者：何艷平 單位：湖南廣播電視大學
數據管理論文:企業公共數據管理論文
1公共數據管理技術發展趨勢
Gartner的研究報告顯示，公共數據管理應被視為實現企業內信息管理戰略的一部分，沒有廣泛的企業信息管理和基礎架構的支持，公共數據管理解決方案將不能有效的維持高質量和可重用性的數據。圖5為2012年Gartner的關于公共數據管理技術的成熟度曲線。縱觀公共數據管理技術成熟度曲線，公共數據管理市場正在逐步走向成熟。雖然在兩年之內還沒有新的技術出現，但是從整體上看，公共數據管理市場仍具有可開發的潛力。2012年的公共數據管理技術成熟度曲線的特點是，有些技術在高峰期到達前就已過時，這些技術將被更廣泛的公共數據管理技術所替代，如多域公共數據管理解決方案。使用低質量的公共數據去改善業務過程只會導致低預期的結果，所以維護單一版本的公共數據是非常有必要的。
2公共數據管理體系
公共數據管理體系主要涵蓋了公共數據標準、管理組織、管理流程和質量管理4部分，旨在創建企業級信息視圖，建立一個有效的端到端的數據管理體系，在整個數據生命周期內采用一項綜合、協調且有計劃的方案，從而提升決策過程中所需數據的一致性和可信度，提升數據的安全性及質量水平，將數據對收入的貢獻潛力較大化。2.1公共數據標準體系2.1.1公共數據標準識別企業公共數據編碼標準體系是基于企業業務運作及管理需求而建立的，首先以各項業務分析作為關鍵輸入，分析出核心業務組件(CBM)模型，而后根據公共數據識別的原則定位各業務相關的公共數據對象，并按照公共數據分類的原則，從公共數據共享的業務領域、信息系統范圍等角度出發，篩選出公共數據，從現行標準、應用集成情況、數據責任人、管理流程及平臺支持維度對每一項公共數據對象進行詳細分析，確定管理策略，制定公共數據標準，進而形成公共數據標準體系。2.1.2公共數據標準體系企業公共數據通常包括人、財、物、業務伙伴和基礎數據5個方面，代表了企業整個層面公共的業務實體，跨業務領域、跨信息系統。因此公共數據標準是應用于多個信息系統的基礎類標準，需在整個企業范圍內統一制定，并嚴格執行。2.1.3公共數據標準管理流程公共數據編碼標準管理流程一般包括注冊與立項、制修訂與、宣貫與執行、檢查與復審、使用與維護等5個階段，實現公共數據的全生命周期管理(圖6)。2.2公共數據管理組織和職責在公共數據管理過程中，從標準的制定到標準的執行會涉及標準和數據責任部門、標準部門、標準執行部門3個重要的角色。通常標準和數據責任部門是財務、采購部門，主要負責公共數據編碼標準的制修訂、解釋和監督執行。企業的標準化管理機構負責標準，標準由企業的各級公共數據責任部門分級負責執行。在整個組織體系中，標準和數據責任部門(DataOwner)直接影響公共數據管理的最終效果和管理水平。實踐證明，最有效的公共數據責任部門是業務與管理高度統一的部門，但具體企業還需具體分析。2.3公共數據編碼管理根據企業業務管理特點和要求的不同，公共數據將采取集中制、審批制和備案制3種管理方式，歸口業務管理部門將按不同的方式對公共數據進行編碼。公共數據管理從公共數據的業務活動出發，逐個分析各節點的業務需求，為數據標準、數據質量、管理體系及系統功能的提升提供需求指導和應用思路。圖7展現了數據從產生到消亡的生命周期管理。2.4公共數據質量管理數據質量管理主要從事前防范、事中監控及事后治理3個方向進行管理。，管控流程一般主要包括數據質量監控、數據質量分析、數據清理及長效保障4個環節(圖8)。
3公共數據管理系統建設
企業要實現公共數據管理，需搭建相應的系統用于公共數據的申請、審批和集成管理。公共數據管理系統包含公共數據的查詢、申請、審批、、質量管控和集成等功能，通過企業服務總線實現與企業各信息系統的集成，為各集成系統提供公共數據編碼服務(圖9)。通過公共數據管理系統的建設，不僅可以落實企業公共數據標準的執行、規范公共數據管理流程，還能較大化發揮公共數據管理的實施效益，為企業應用系統集成應用和信息共享奠定堅實的數據基礎。
4總結
隨著信息化建設的不斷成熟，公共數據管理將作為企業運作過程中一種常態的管理職能。企業通過公共數據管理，可取得一系列成果：①制定一系列公共數據編碼標準，既可滿足企業跨部門、跨業務領域的數據共享需求，也滿足了企業系統間信息交互數據一致性的需求；②成立數據管理組織，可指導企業公共數據編碼標準的制修訂、推廣實施、運維管理等工作；③建設相應的公共數據編碼管理系統，為企業各信息系統的數據共享提供技術支持；④建立企業統一共享公共數據編碼庫，有利于企業做出正確的統計分析及業務決策。綜上所述，公共數據管理是企業信息化建設過程中必不可少的部分，將為企業的系統集成、業務協同、決策應用等發揮更大的助力作用。
作者：黃幽麗 馮霈 張棟 朱麗娜 路艷玲 單位：中國石油集團東方地球物理勘探有限責任公司信息技術中心
數據管理論文:存儲資源池數據管理論文
1存儲虛擬化技術應用過程
首先對原有分割的San網絡進行改造，形成統一san網絡，為數據中心的所有存儲設備和服務器提供端到端的通訊；其次通過現場測試比較選購一臺具有虛擬化功能的容量為100T高端存儲設備對原有存儲進行整合，虛擬化為邏輯上的存儲資源池，并按照存儲設設備類型和性能劃分高、中、低三個存儲資源組；另外根據各應用系統對存儲性能、容量的要求進行分類；在保障業務數據安全的前提下，對各業務數據進行整理，逐一分級遷移到新建存儲資源池中。
2應用效果
項目實施后形成了邏輯上的存儲資源池，實現了多臺存儲設備的集中監控和統一管理，工作量和維護成本得以降低。各應用系統共享統一的存儲資源池，可按照資源需求規劃和既定策略進行資源分配，應用系統暫時不需要的資源可以動態分配給其它系統使用。通過存儲動態分層技術，確保現最重要最繁忙的數據總是保存在性能好的存儲上，而次要數據保存在其它存儲資源上；通過克隆或鏡像方式將重要數據復制到存儲資源池中低端存儲設備上，使老舊設備繼續發揮作用，并以較低的成本提高數據安全性。
2.1提高資源利用率實現了存儲資源的集中統一管理
項目實施后將原來各獨立的存儲域邏輯上整合成一個整體的存儲域，并按邏輯分區方式保障業務性能等級，通過虛擬資源調配將整個虛擬化整合后的資源動態供應給相關應用，改變原有存儲獨占模式為多應用共享，提高資源利用率。實現在各個存儲層次，根據業務性能等級數據實現動態分層，對業務系統系統進行存儲改造，最終實現最重要最繁忙的數據總是存儲在性能好的存儲上，而次要數據將保存在性能普通的陣列。數據在性能好陣列與普通陣列的遷移將是自動的并且對應用是透明的。如圖1所示。
2.2有效的提升了重要數據的讀寫速度
將業務數據，按照重要性和使用頻度進行分級（1）使用在線中高端磁盤系統，保存實時的、高使用價值的業務數據；（2）使用近線中低端磁盤系統，保存不常訪問的、但有較高使用價值的數據；（3）使用離線磁帶設備，保存基本需保留的、低使用價值的歷史數據。
2.3以較低投入帶來了數據安全性較大的提高
通過項目建設可以極大的提高云南電網業務數據的安全性，實現方法是通過存儲資源的集中統一管理我們可以在異構存儲上通過數據克隆技術，以較低的成本實現基于時間點剝離做數據復用，將重要數據在磁盤陣列內甚至在磁盤陣列間進行復制，同時保持多份可以方便使用數據除了能提高數據安全性外，還可以為開發測試、查詢、備份等功能，簡單、易維等一些臨時任務提供一個數據副本，對生產數據不造成任何安全和性能影響。如圖2所示。
2.4實現存儲的網絡擴展使存儲資源的使用更加方便靈活
對原有存儲設備升級改造完成后部分原有老設備將不再提供給業務應用系統使用，為了更好利用這些設備考慮增加一套NAS網關，并將其接入到SAN網絡，NAS網關可以直接使用已經池化得富余或者暫時不用的存儲空間（這些空間可以分別來自于多臺存儲），并通過網絡提供給那些無法接入到SAN的服務器或計算機使用。部門或者個人可以將文件通過NAS網關提供的文件共享服務，方便、安全的進行共享和交換。NAS網關提供的NFS作為一個工業級標準的共享文件系統，NFS卷的安裝和卸載非常簡單，并支持多用戶端，任何與網絡相連的服務器可以方便利用虛擬化軟件來使用和運行虛擬機。和SAN比較NAS網關提供的NFS雖然受帶寬限制（SAN一般為4GB/S,NAS一般為1GB/S）但是由于服務器使用網絡存儲資源時不用配置LUN和SAN，只需ip可達就可以方便的使用，因此利用NFS能更快的實現虛擬機的故障切換和數據遷移，特別當部分無HBA卡的服務器需要進行虛擬化應用時，可利用NAS作為服務器共享存儲。
3結論
通過實踐證明存儲虛擬化技術的應用不但能提高存儲資源的利用效率，而且能有效的提高存儲系統運維管理水平，并為未來該領域的其它性新技術的應用奠定了夯實的基礎，隨著應用的深化可以依托存儲資源池進一步為用戶提供網絡文件同步管理、云備份等存儲服務。
作者：胡永華 白楓
