王晶春
(長春理工大學 信息化中心,長春 130022)
隨著網絡、信息技術水平的不斷提高,高校數字化校園建設的不斷投入及深入開展,很多高校建立了涵蓋學校教學、科研、管理、服務在內的眾多業務系統,改變了以往傳統的教學、管理及辦公模式,為學校各部門、教師和學生提供多種便捷、高效的服務。
校園網的業務系統越來越多,系統間數據集成[1]關系的復雜化、數據流向的多元化,沒有統一的身份管理,總體上使維護集成工作復雜,這樣就形成了基礎數據不能共享、數據重復錄入、用戶的認證信息過多、業務流程不能跨部門協同、信息孤島等諸多問題,因此迫切要求高校從總體上規劃數據集成的總體架構,以指導數據集成工作有條不紊的展開。
本文在對高校數據集成特點總結的基礎上,提出一套符合其行業特點的總體架構方案,對高校數據集成具體實施提出一個參考性建議。
目前許多高校數字化校園的數據集成工作還處于初級階段,還未提高到總體架構的高度。數據集成工作都是由于各業務系統的數據需求才慢慢開展的,是一個自下而上的過程,隨著數字化校園的不斷發展,業務系統不斷增加、各業務系統間的交互越來越多,越來越復雜、數據流向多元化,使集成工作的維護工作量增大。
高校各業務應用系統之間沒有相互連接的信息渠道,數據被存儲在不同的數據庫、文件服務器當中,只有給予權限的用戶可以訪問,這樣為高校整體管理設置的障礙,形成了一系列的信息孤島。每個獨立的業務系統都是一個數據源,如人事系統獨有教工信息數據源、教務系統獨有學生信息源、舍管系統獨有學生舍管信息源等,每個數據源都是異構[2]的,形成了巨大的異構數據環境。這些異構的數據源之間還存在著千絲萬縷的聯系,遇到具體的業務需要時,這些分散的數據按需進行集成。每個業務系統的開發時期不同,內部之間存在的不可兼容性,全盤放棄的話勢必造成浪費,怎樣實現這些異構數據源之間的共享是高校數字化校園急需解決的問題,高校數據集成工作顯得尤為重要。
目前許多高校已經著手進行數據集成,數據集成在建設初期用戶都是按照需求在小范圍組織系統內做一些簡單的集成工作,或僅從技術實現角度上考慮,但是各業務系統間的關系越來越復雜,對數據集成的需求越來越復雜,這就要求高校要從整體高度規劃集成工作,設計出一個數據集成的總體架構。
2.1.1 點對點架構產生
數據集成架構初期是點對點結構[3],如圖1所示。

圖1 點對點架構
高校各業務系統剛剛開始開發運行,雖然系統之間各自獨立運行,但建設初期都會需要其他系統的一些數據,如:(1)學工系統需要從教務系統獲取學生信息進行獎學金、學生貸款的管理等;(2)財務系統要從教務系統中獲取學生信息進行繳費管理;(3)舍管系統需從教務系統中獲取學生信息進行宿舍分配。發生此類需求時,數據集成工作一般為自發方式,當某一系統需要向其他系統獲取數據時,大多采用的方式都是定期通過磁介質拷貝、電子郵件或備份數據庫文件等方法獲取所需數據,只要其他系統更新數據,就會造成同一數據在幾個系統間的不一致,若遇到其他系統的數據清洗等工作,集成工作就更是難上加難了。
2.1.2 點對點架構特點
數據集成范圍小,未考慮其他系統的融合,信息重復問題嚴重;各系統間數據不一致;需求較隨意,不確定;周期上不固定;集成方式大都采用手工導入、導出或者自行開發等方法。
2.1.3 點對點架構弊端
集成范圍小、擴展難、標準無法確定、全局應用無法展開。
2.2.1 星形架構產生
點對點架構存在許多弊端,隨著高校數字化校園建設的不斷發展,數據集成開始從全局角度考慮,各業務系統數據集成的要求越來越復雜,一個業務系統可能要和多個業務系統之間進行信息交互,星形架構[4]應運而生,如圖2所示,整個架構的形狀與星形類似。

圖2 星形架構
星形架構使得各業務系統不再是信息孤島,數據可以在全局范圍內流動,數據集成的質量得到提高,對異構數據源的處理也得以加強。
2.2.2 星形架構下存在的問題
(1)業務系統較少時,實現數據集成快速簡便,業務系統越來越多,形成一定規模后,此架構的擴展性差的缺點就顯現出來了。
(2)隨著業務系統的增多,ELT編寫變得復雜并難以維護。
(3)增加了系統之間的耦合度,一個系統出現問題影響全局,數據服務的質量、集成效率降低了。
(4)一份數據在各業務系統中有多個入口和出口,數據的一致性難以保證。
(5)安全性難以保證,各系統之間交互、授權、沒有統一管理,勢必影響系統的安全。
2.2.3 星形架構的弊端
可擴展性差、無法做到低耦合、數據質量無法保證、不能做到上層應用、缺乏權限控制。
因此,星形架構雖然解決了全局范圍內數據集成的問題,但是在低耦合、數據標準維護、可擴展性、上層應用、權限管理等上仍然存在一定的問題。
集線器架構的出現解決了星形架構存在的問題,集線器架構如圖3所示,此架構設計了一中心節點,整體架構與集線器相似,各個業務系統與中心數據平臺節點的集成關系成輻射狀。

圖3 集線器架構
集線器架構通常以某個關系型數據庫為中心節點,并作為數據集成中心,ELT先按照統一的數據存儲模型將各業務系統的數據加載到數據集成中心,這樣數據集成中心根據各部門的數據需求將相關數據加載到各業務系統中,整個數據交互看上去像一個集線器一樣。

表1 集線器架構優點
此架構中各業務系統需要的數據都存放在數據集成中心,各業務系統按需加載數據,這樣保證了數據在各業務系統之間的一致性,避免了數據在各系統之間的重復,避免數據冗余;各業務系統之間相互獨立,數據不發生交互,總體上各業務系統做到了低耦合。
由此可見,集線器架構解決了點對點架構、星形架構中存在的問題,具有低耦合、擴展性強、數據質量保證、全局集成、為上層應用提供基礎數據以及權限統一管理的優點,是目前較符合高校數據集成工作現狀的一個總體架構模式。集線器架構優點如表1所示。
(1)過程一:如圖4所示,過程一是數據集成中心的數據源,ELT將人事、教務等內部業務系統數據和外部數據抽取到中心數據庫,經過清洗轉換,將數據轉換為標準的統一格式,其他各業務系統根據自身需求,從中心數據庫提取數據。

圖4 過程一

圖5 過程二
(2)過程二:如圖5所示,過程二分為兩個階段,第一階段(虛線框)中數據集成中心為全局數據庫提供數據,供各業務系統的應用及基礎報表查詢,同時數據集成中心從各業務系統中的獲取數據,并轉換為統一標準的數據;第二階段是數據集成中心為數據倉庫提供數據,進行統計數據分析和數據挖掘。
ELT是利用數據庫的處理能力,E表示從源數據庫抽取數據,L表示把數據加載到目標庫的臨時表中,T表示對臨時表中的數據進行轉換,然后加載到目標庫目標表中。
它的轉換過程都是在轉換服務器中進行的,這種處理方式不需要有中間的轉換服務器,所有的轉換都是在數據庫中進行,可以節約資源。
Oracle的 ODI是使用 ELT 的理念(Extract、Load&Transform,即抽取、裝載、轉換)設計出來的數據抽取/數據轉換工具,ODI:Oracle Data Integrator的簡稱,是Oracle的數據集成類工具。

圖6 ELT體系結構圖
在總體架構中,數據集成中心和各應用業務系統之間的數據流是雙向的,和全局數據庫間的數據流也是雙向的,數據標準由全局數據庫提供,供其他應用業務系統使用。[5]
數據集成中心和數據倉庫之間的數據流是單向的,數據集成中心為數據倉庫提供數據,供用戶分析和挖掘,以便輔助決策。
因此建立的中心節點是一個數據集成交互平臺,一方面可以用于各應用業務系統間的集成,另一方面形成全局數據庫,有了統一的數據標準。
3.4.1 優點
(1)做到了信息編碼統一
過程一中所有基礎業務系統數據抽取到中心數據庫,經過清洗轉換,將數據轉換為標準的統一格式,各業務系統按需統一從中心庫獲取數據,這樣保證了數據在各業務系統的統一。
(2)無冗余業務數據
需共享的數據存儲在數據中心,各系統中不再存貯共享數據,避免數據重復。
(3)數據只有唯一的入口、出口,誰的數據,誰負責維護。
(4)學校整體的信息較容易掌握,為輔助學校決策做好基礎。
3.4.2 數據集成中心為中心節點
許多高校在數據集成應用中將全局數據庫作為架構的中心節點,雖然這樣能滿足架構的要求,但長期這樣應用會有很多弊端:
(1)數據集成中心結構根據需求變化會做相應改變和拓展,而全局庫主要是面向上層應用,其結構要求穩定。
(2)數據集成中心會有大量數據中轉、處理,全局庫需想各業務系統提供數據,如果再做數據中心,會超負荷,形成系統瓶頸。
(3)從安全角度上講,數據未經處理直接在全局庫進行操作,可能會對全局庫造成數據污染,影響其上層應用。
因此將數據庫中心作為中心節點,將全局庫從中心節點抽離、獨立起來,解決了上述弊端。
本文對數字校園建設中面臨的異構數據源現狀進行了分析,對比分析幾類數據集成體系架構,提出目前較適合高校數據集成工作的集線器式總體架構模式,適應高校發展的好的架構模式能加快構建數據化校園信息平臺,是促進數字化校園高效統一發展的有力基石。
[1]唐偉.面向數據集成的數字化校園建設[J].計算機教育,2013(2):50-54.
[2]敖毅.面向數字圖書館的五層模型異構數據集成架構研究[J].情報學報,2005,24(6):723-727.
[3]李建花.面向校園網的高校數據集成方案的研究與應用[D].濟南:濟南大學,2011.
[4]包林玉.數字化校園建設中異構數據集成技術的研究[D].成都:西南科技大學,2009.
[5]杜偉.高校數據集成整體規劃方案[J].信息安全與技術,2012(2):64-66,82.