高校數據倉庫多維數據建模分析

張 軍, 王芬芬

(湖南鐵道職業技術學院 圖書信息中心, 湖南 株洲412001)

0 引 言

隨著高校各類信息系統的深入使用,已經累積了大量的數據,有效組織與分析這些數據是當前高校信息化建設的主要任務。 很多高校前期已經建立了不同程度的,用于數據交換與共享的數據中心平臺,該平臺能夠實現簡單的數據集成,但當前高校業務數據已經呈現出歷史數據量大、數據異構、數據冗余且不一致,在統計方面也存在數據統計維度多、統計路徑多樣化等特征。 在這種條件下,要實現跨時間、跨業務的綜合統計分析是一項十分困難的工作。構建高校數據倉庫系統能有效解決上述問題,數據倉庫的ETL(Extract-Transform-Load)過程能有效的解決數據異構、冗余、不一致等問題,同時數據倉庫能夠在各種粒度上為多維數據的交叉分析提供支持［1］,并且所積累的大量歷史數據能夠為數據挖掘提供完善的數據樣本集。

1 架構設計

數據倉庫主要面向統計分析和數據挖掘,為高校的教學和管理決策提供支持。 其數據來源為高校內其它操作型業務數據庫和數據文件,這些數據按照高校制定的數據標準,經過清洗、轉換加載至數據倉庫中,為上層應用提供支撐。 本文所構建的高校數據倉庫主要包括源數據層、數據倉庫層和數據應用層,如圖1 所示。

源數據層。 該層為各業務系統的數據庫,是數據倉庫層的數量來源。

數據倉庫層。 該層主要分為近源數據、標準數據和主題數據3 個區域。 近源數據區貼近業務系統源數據,保存了各個業務系統的數據明細,與源業務系統的數據結構基本保持一致,唯一不同之處是在原有基礎之上添加了時間戳,形成不同版本的歷史數據。 標準數據區是數據倉庫的核心數據區,是按照單位制定的數據標準對近源數據進行標準化處理后的結果,該層數據符合數據庫第三范式建模要求。主題數據區對應宏觀的分析領域,通過對標準數據進行重新組織或匯總,為不同主題的數據建立維度匯總數據區,以滿足上層應用對數據的多樣化需求,該層采用維度建模的方法構建。

圖1 高校數據倉庫的架構設計Fig. 1 The architecture design of university data warehouse

數據應用層。 該層為用戶和數據倉庫層建立交互界面,依據用戶請求訪問倉庫內的數據,生成各類數據統計報表,實現對數據多維度、多層次的分析和隱性知識的挖掘。 包含了多維分析、統計報表、數據挖掘,以及為其它應用提供的數據接口［2］。

2 數據建模

數據建模是構建數據倉庫的核心工作之一,通過數據建模,能夠使高校建立全方位的數據視角,勾勒出高校各部門間的內在聯系,同時能夠有效解決各業務數據的一致性問題。 另外,數據建?？梢苑蛛x出底層技術的實現和上層業務的展現,能夠有效應對業務的變動,提高數據倉庫的靈活性。

依據圖1 所設計的高校數據倉庫架構,在數據倉庫層有3 個不同的數據區域,分別為近源數據區、標準數據區和主題數據區,其中近源數據區和標準數據區主要是完成數據的抽取與轉換,對數據進行標準化處理,其建模方法基本是采用傳統的數據庫范式建模法。 靈活多變的分析需求是主題數據區建模所必須應對的問題,依據高校具體的業務數據特點以及分析需求劃分主題域,每個主題對應1 個宏觀的分析領域,在主題數據區中為主題建立其所需的事實表與維度表,確定關聯關系,建立多維數據模型,進而為上層應用提供數據服務,其一般過程如圖2 所示。

圖2 主題數據區建模過程Fig. 2 Modeling process of subject data area

2.1 領域建模

領域建模就是對業務系統充分了解后,結合高校數據倉庫的建設需求,對關鍵業務抽象化,按照業務主線聚合進行分組,將業務數據進行綜合、歸類,最終形成面向相應宏觀分析領域的各個主題域。 主題域劃分通常采用樹形結構,采用逐級細分的思路進行設計。 本文依據高校的核心業務,定義了1 個公共主題和5 個業務主題,如圖3 所示。 公共主題包括了學校的基礎數據和標準代碼集,這些標準代碼集參考了國標和教育部相關標準,也包含了學校自定義的校標［3］。 部分公共維度也包含在代碼集中,比如時間、地理位置、專業、學歷學位等公共維度,它們通常與多個主題事實表產生關聯,形成多維分析模型。

2.2 邏輯建模

邏輯模型是在充分理解分析主題與用戶需求的基礎上,確定分析粒度,為每個主題事實選取分析維度,設計事實表及其相關聯的維度表。 事實就是對分析主題的度量,其度量屬性的值就是進行分析處理的對象,事實表的設計以能夠正確記錄歷史信息為準則。 維度則是對分析主題所屬類型的描述,是分析者觀察事實的角度,維度表的設計是以能夠用合適的角度來聚合事實內容為準則［4］。 事實表和維度表的設計是邏輯建模的關鍵,其設計的好壞也直接影響到整個數據倉庫系統的性能以及數據分析效果。

圖3 高校數據倉庫主題域劃分Fig. 3 Subject domain division of university data warehouse

多維數據模型依據事實表和維度表不同的組織形式,通常有三種設計模式,星型模式、雪花模式和事實星座模式。 本文以高校業務中比較核心的數據分析主題來闡述三種不同模式下的多維數據模型建立。

(1) 星型模式。 星型模式的基本結構就是事實表位于中心,維度表圍繞在事實表周圍［5］,這種模式能夠直觀的展示數據的多維功能。 教師主題下的教師基礎數據能夠從多個維度對高校師資結構進行統計分析,同時也可以作為教學、科研等與教師相關主題的教師維度。 教師基礎數據涉及的維度較多,如學歷、學位、學科、職稱、崗位、民族、籍貫等等,適合采用結構簡單的星型模式進行建模,不僅可以直觀的反映出業務邏輯,還便于對不同的維度進行靈活的組合分析。 為跟蹤教師基礎數據的變化過程,記錄和保留活動數據的歷史信息,本文事實表的設計引入了緩慢變化維的方法來捕獲變化數據。 在事實表中加入開始時間、結束時間和版本3 個屬性來實現記錄維度的緩慢變化,其中開始時間和結束時間標記了活動數據在該時間段內處于某一狀態,版本記錄了活動數據經歷的歷史狀態順序［6］。 教師基礎數據的星型模型如圖4 所示。

圖4 教師基礎數據星型模型Fig. 4 Star model of teachers'basic data

(2) 雪花模式。 雪花模式和星型模式有類似的邏輯模型,也是由事實表和維度表組成。 在雪花模式中,維度表中低基數的屬性被移除,形成單獨的表,基數是指表中一個屬性不同值的個數,這項操作就是維度規范化。 當維度被規范化成多個關聯的表,即形成了以事實表為中心的雪花型結構。 維度規范化將維度表中重復的組分離成一個新表,這些通過分解形成的表連接到主維度表而不是事實表,有效的減少了數據冗余,但卻不可避免的增加了表的數量,在執行查詢時,不得不連接更多的表。 但是規范化減少了存儲數據的空間需求,提高了數據更新的效率。

以 學 生 學 籍 事 實 表(FACT ＿ STUDENT ＿STATUS)及其教學班級維度表(DIM＿CLASS)為例,進行雪花建模,闡述維度規范化的過程,分析其在存儲空間及更新效率上的優勢。 以某高校為例,該校有在校生20000 人,12 個二級學院,25 個教學系部,共計400 個教學班級。 如果以星型模式進行建模,事實表有20000 條記錄,教學班級維度有400 條記錄,共計20400 條記錄,每個學生所屬的二級學院以及教學系部作為教學班級的屬性,顯式的存放在教學班級維度表中。 對教學班級維度進行規范化處理,建立二級學院維度表(DIM＿COLLEGE)和教學系部維度表(DIM＿COLL＿DEPART),事實表沒有變化,總的記錄數變為20437(20000＋400＋12＋25)條記錄,規范化增加了新表,總的記錄數也增加了,但是不難看出,在教學班級維度表中存放的不再是二級學院和教學系部具體的屬性信息,而是它們的主鍵值,具體的屬性信息統一存放在其相關的維度表中,這樣就大大減少了數據存儲所占用的空間,教學班級的數量越大,這種空間優勢就越明顯。 在數據更新方面,如果學校發生了院系調整,只需更新二級學院及教學系部維度表,對數據量較大的事實表的影響是十分微小的。

實際上,星型模式是雪花模式的一個特例(維度沒有多個層級)。 雪花模型的主要缺點是維度屬性規范化增加了查詢的連接操作和復雜度。 相對于平面化的單表維度,多表連接的查詢性能會有所下降。 但雪花模型的查詢性能問題近年來隨著數據瀏覽工具的不斷優化而得到緩解。 學生學籍數據的雪花模型,如圖5 所示。

圖5 學生學籍數據雪花模型Fig. 5 Snowflake model of student status data

(3) 事實星座模式。 高校數據倉庫由多個主題構成,包含了多個事實表,很多事實表里包含了大量公共的維度,這些維度供多個事實表共享使用,形成了多個星型模式的匯集,這種結構就是事實星座模式,也稱為星系模式。 以高校財務明細事實表和科研項目事實表為例,它們之間存在著大量的公共維度,比如項目負責人、項目類別、項目來源、項目級別、立項時間、結項時間等等,多個事實表與多個公共維度交叉連接,是數據倉庫構建過程中常用的建模方式。

多維數據模型是數據倉庫的核心,也是OLAP(聯機分析處理)的靈魂。 上述三種多維數據的建模方法都是由一組維度和事實的集合組成的,該模型可以用一個n(n ≥2) 維數據立方體表示,數據立方體中的維來自維度表,空間中的點來自事實表,每個點(以取n = 3 為例,1*1*1)包含事實數據,稱為存儲單元。 多維數據分析的核心操作就是對數據立方體進行鉆取(Drill-down)、上卷(Roll-up)、切片(Slice)、切塊(Dice)以及旋轉(Pivot)。 鉆取和上卷是通過改變維度的層次,調整分析粒度來觀察數據,切片是通過固定數據立方體上某一維度上的選定值,觀察數據在剩余維度上的分布情況,如果是對兩個及以上的維度執行選擇就是切塊操作,旋轉即是變換維度在數據立方體上的方向［7］。

針對高校業務數據結構繁雜,且存在著大量聚合分析的特點,本文在圖5 的學生學籍數據雪花模型中進行了維度層次結構的設計。 以教學班級維度為例,教學班級隸屬于教學系部,教學系部隸屬于二級學院,層次之間通過外鍵連接,能夠實現“教學班級→教學系部→二級學院”的上卷或“二級學院→教學系部→教學班級”的鉆取。 建立維度層次關系,可以用來定義切片路徑,數據立方體可以通過教學班級、教學系部或者二級學院進行切片分析。

2.3 物理建模

物理建模的主要工作是將所設計的邏輯模型在合適的數據庫管理工具中實現,包括選擇合適的數據庫管理工具,設計數據表的結構及其屬性類型,建立用于快速訪問的索引策略,明確數據的存儲方式及存儲位置,制定實施數據的裝載與清洗策略。

依據本文在數據倉庫層中所設計的分區域存儲和治理數據的策略,需要創建的物理表主要包括如下幾類：

(1)為滿足數據倉庫元數據管理和數據ETL 的需求,所創建的配置表、日志表等。

(2) 在近源數據區用于存儲原始數據的源數據表。

(3) 在標準數據區用于存儲對源數據表進行清洗和轉換的標準數據表。

(4) 在主題數據區用于存儲多維數據模型所生成的維度表和事實表。

在具體設計過程中,需要對物理模型中的數據定義和數據格式進行規范化處理,也包括所遇到的一些設計共性問題,如在物理模型中所需要的主鍵是采用自然鍵還是代理鍵。 自然鍵就是用實體現有的屬性組成鍵值,在業務概念上是唯一的。 代理鍵就是新增一列不具有業務含義的鍵值表示數據唯一。 本文設計的大多事實表都是采用自增序列的代理鍵為主鍵,因為高校業務繁多,業務需求變更頻繁,代理鍵不與業務產生耦合,業務需求的變更對其不會產生影響,更容易維護。 另外,時間戳字段也是一個設計共性問題,數據的變化一般是發生在字段一級的,如果給每一個字段蓋上一個時間戳,雖然能夠最詳細的記錄標識數據的變化,但會大大增加數據的存儲量,采用在行一級上添加時間戳,當數據發送變化時,時間戳字段同步更新,通過系統時間與時間戳字段的值來決定所抽取數據。

在索引創建策略上,按照索引使用的頻率,由高到低逐步添加,使用主關鍵字和外部關鍵字建立索引,根據實際情況可以設計多種索引結構。 在數據的具體存放位置上,將索引和數據表分開存放,索引存放在高速存儲設備上,數據表可存放于一般存儲設備,以加快數據的查詢速度。

3 實現與應用

在上述數據模型的基礎上,構建高校數據倉庫還需要完成數據ETL 的實施,ETL 是將各個業務中的異構數據源經過抽取、轉換、加載到數據倉庫的過程。 ETL 是數據倉庫實施的核心內容,常用的開發工具有Oracle 公司的ODI(Oracle Data Integrator)、開源工具Kettle 等,也可以直接編寫存儲過程。 本文選擇ODI 作為主要的ETL 實現工具,但對邏輯復雜,且對執行效率有較高需求的ETL,則直接使用存儲過程來完成。

完成從各業務系統中抽取源數據后,對數據進行清洗和標準化也是一項重要的工作。 數據清洗主要對源數據中出現的殘缺數據、錯誤數據、重復數據以及違反邏輯規定的數據等問題數據進行統一的處理［8］。 表1 給出了針對高校業務系統常見的數據問題,以及對其所采取的清洗策略。 數據標準化就是依據制定的信息標準對清洗后的數據進行規范化處理,如不同業務系統的同一數據的數據格式或使用的數據字典可能不一致,就需要將其按照數據倉庫的信息標準進行規范化處理。

完成數據倉庫各個層次的數據處理后,就可以為上層應用提供數據服務了,主要包括一些數據查詢系統、在線分析系統、決策支持系統、數據挖掘與數據接口等。

表1 數據清洗的常見問題及策略Tab. 1 Common problems and strategies of data cleaning

4 結束語

本文基于典型的數據倉庫構建技術,結合高校具體的數據統計與分析需求,針對高校業務系統零散、數據類別繁雜的特點,提出將數據倉庫分為近源數據區、標準數據區和主題數據區3 個區域,每個區域的數據具有不同的特點,同時采取不同的治理策略。 多維數據建模是構建數據倉庫核心內容,它能夠滿足對數據進行多層次、多角度的分析需求,本文選取了高校教師基礎數據和學生學籍數據作為建模分析對象,分別給出星型模式和雪花模式的多維數據模型,由于篇幅有限,所構建的數據模型只列出了主要的關鍵字段,但它依然可以作為高校在構建數據倉庫時進行數據建模的參考。 本文的數據倉庫架構以及所使用的多維數據建模方法已經應用于某高校的大數據分析平臺,能夠靈活的分析與統計高校業務數據,自動生成各類復雜的數據報表。