汪海平
(河南省工業學校,河南 鄭州 450011)
DI 數據交換模型的開發,是信息數據流建設的重點內容,只有設計號數據交換的模型,數據中心和各業務系統的數據才能暢通無阻的運行,才消除數據孤島,實現數字校園建設的進一步發展,本文以學生基礎數據流轉進行說明。
學校中使用率最高的數據,當屬學生數據,學生數據的數據流模型說明如下:

1.1.1 招生系統到數據中心的學生基本信息
數據交換說明:該同步模型是將招生系統表中的數據抽取到數據中心的學生招生信息表,該表中的數據來源是招生系統中已經刷身份證進行確認過的學生數據,如招生系統中對該學生沒有進行確認,則不進行抽取。抽取的數據,供學工系統抽取,以便進行分班和分學號使用。
數據源系統:招生系統;數據源數據表:tb_stus_state;目標系統:數據中心平臺;目標數據庫表:tb_stus_state;數據抽取或推送方向:招生系統到數據中心平臺;DI 數據模型名稱:tb_stus_state.dbr。
1.1.2 學工系統到數據中心的學生基本信息
數據交換說明:該同步模型是將學工系統表中已經分班分學號的學生數據抽取到數據中心的學生信息表,該表中的數據來源是學工系統中已經分過班級和學號的學生數據,如學工系統中對該學生信息進行了修改,則同樣會進行再次抽取修改后的數據。此時抽取到數據中心的數據,為學生的正式數據,供其他系統抽取使用。
數據源系統:學工系統;數據源數據表:TB_XJDA_XJXX、TB_BASE_SJZD_BZDMB、XS_DORM_VW、TB_BASE_BJ_BJXXB BJ;目標系統:數據中心平臺;目標數據庫表:TA_XSGL_XST;數據抽取方向:學工系統到數據中心平臺;DI 數據模型名稱:TA_XSGL_XST.dbr。
1.1.3 數據中心到一卡通系統的學生基本信息
數據交換說明:該同步模型是將數據中心系統表中的數據推送到一卡通系統的人員信息表,該表中的數據來源是數據中心的學生數據,推送到時,將學生數據推送到一卡通中間庫,然后由新開普自己的內部同步程序自動抽取到一卡通正式庫中,若學生信息修改,則也會將修改后的數據推送到一卡通中。
數據源系統:數據中心;數據源數據表:TA_XSGL_XST;目標系統:一卡通中間庫;目標數據庫表:M_BASE_CUSTOMERS;數據推送方向:數據中心到一卡通中間庫。DI 數據模型名稱:M_BASE_CUSTOMERS.dbr。
1.1.4 數據中心到教務系統的學生基本信息
數據交換說明:該同步模型是將數據中心系統表中的數據推送到教務系統的學生信息表,需要注意的是,在推送學生信息之前,應該先推送班級信息,這樣,學生就是自動歸屬到相應的班級內。因教務系統數據表沒有updatetime 字段,因此,目前使用的是全量更新方式,更新時,只更新在校在籍的最近兩屆學生,歷史數據不進行更新和推送。
數據源系統:數據中心;數據源數據表:TA_XSGL_XST;目標系統:教務系統;目標數據庫表:T_JW_STUDENTSTATUS;數據推送方向:數據中心到教務系統;DI 數據模型名稱:T_XS_STUDENT.dbr。
1.1.5 教務系統到妙思圖書系統的學生基本信息
數據交換說明:該同步模型是將教務系統表中的數據抽取到妙思圖書系統,該同步程序接口部署在妙思圖書系統上,可以根據年份對數據進行抽取,抽取的條件是教務系統必須已經有相應學生數據。
數據源系統:教務系統;數據源數據表:T_JW_STUDENTSTATUS;目標系統:妙思圖書借閱系統;目標數據庫表:dbo.dzxxb;數據抽取方向:教務系統到妙思圖書借閱系統;DI 數據模型名稱:無。
班級數據、教師數據、專業數據、課程數據、組織機構數據與學生數據流轉類似(隱去)。
DI 數據交換模型在日程運行維護過程中,會因為某些交換模型所用到的數據源數據庫信息修改,或者目標服務器賬號密碼更新等問題,導致數據交換中心的自動化運行停止,甚至也可能會導致其他正常的數據同步模型也無法正常執行,遇到這些情況,該如何逐步拍出故障進行處理呢,下面是具體的執行步驟,按照此步驟,一般常見的數據交換模型故障都能被處理掉,具體操作步驟如下。
第一步,用管理員賬號登錄數據交換平臺,訪問地址為:***。訪問此平臺建議使用谷歌瀏覽器或者使用谷歌內核的瀏覽器,根據使用經驗,UC 瀏覽器的支持效果最好。
進入該平臺后,依據左側菜單欄找到監控管理--》整體監控--》作業總體監控,在該界面下找到出現報錯的DI Job 作業,如下圖所示。
第二步,通過遠程桌面進入數據交換平臺服務器,打開桌面DI Studio 軟件。
第三步,找到報錯的DI Job 作業,測試該作業上牽涉到的數據庫連接,如果數據庫無法連接,則說明數據源或者目標數據庫的數據庫出現了問題,需要排查數據庫連接賬號信息。如果數據庫連接都是正常的,則需要先手動執行一次同步,看同步程序能否正常執行,此時,需要排查執行結果日志記錄,查看是哪個步驟出現的問題,一個正常的DI 數據模型,一般出現問題的錯誤日志是“違反惟一性數據約束”,此時,查看數據表數據源中抽取的數據是不是出現了已經同步過的數據,或者數據表數據源中的主鍵字段出現了NULL 值,這時會造成如上提示,根據錯誤日志逐步排查即可解決問題。

第四步,如果是數據庫連接錯誤,把所有數據庫連接修改完成之后,拷貝這個DI Job 到運行環境。即:從服務器C:primetondidistudioproject rans 下拷貝job到D:diserverdiserverproject rans。
如果是因為違反惟一性約束導致的同步無法執行,排除錯誤數據即可,不需要修改DI JOB。
原理說明如下:
C:primetondidistudioproject rans 此目錄是用于存放distudio 里的job
D:diserverdiserverproject rans 此目錄是用于存放運行服務器里的job
重啟桌面上server、governor、agent 這三個可執行程序即可使得修改后的job 生效。
注意:若DI Studio 里面的job 跟運行環境里面的job 不一樣,可先從D:diserverdiserverproject rans 下拷 貝job 到C:primetondidistudioproject rans 里,然后再進行修改即可。
中職學校的特點,不如高校學生和普教階段學生那么固定,學生流動和變化相對較大,因此,信息數據流不能建設成一成不變的模型,要根據情況,可以隨時修改,隨時適應新情況的變化。
其次,解決信息數據流過程中的“卡脖子”環節,如新生報到時,需要給報到的學生分配學號和班級,如果這個環節做不好,就會造成后續環節中斷,如無法在新生報到當天給予學生發一卡通。因此,應將此環節前移,減少對多個系統的依賴,學生的學號和班級信息數據生成之后再往后續系統流動,提高教師和學生的用戶體驗。
中職學校數字校園建設經過多年發展,目前并無統一的標準來確定什么類型的數據應該有哪個系統產生;學校業務系統積累的各類信息數據應該怎樣流動才更合理,也無可遵循的規則;結構化數據和非結構化數據的數據交換,也只是依據學校本身的情況進行。針對上述情況,本文組針對我校在數字校園建設過程中出現的問題,進行信息數據流建設有效策略研究。
數字校園建設經過多年發展,我校業務系統不斷增多,由此不可避免地產生了“信息孤島”,通過建立一套信息數據流建設的有效策略方案,依托我校已經建立的數據中心平臺,整合校園內各類信息資源,最終實現各類信息數據按需流動,為后期將我校建設為智慧校園,可視化和預警平臺、大數據應用、智能化應用等提供必備條件。