数据仓库中的模型设计(转)
數據倉庫的模型設計
A. 數據建模方法論
數據倉庫模型設計遵循“自頂向下、逐步求精”的設計原則。
模型設計分為三個階段:
1,概念模型
對業務的范圍和使用,從高度上進行抽象概括,也就是劃分主題域。
一般劃分為8個主題域:
客戶、服務、服務使用、賬務、結算、資源、客服、營銷
為什么要劃分主題域?
劃分主題域,是根據業務的應用和需要來劃分的,是用來達到數據與業務緊耦合的目的。
2,邏輯模型
對概念模型中的主題進行細化,定義實體與實體之間的關系,和實體的屬性。
即定義具體表的作用,表與表的約束,表的字段。形成ER圖。
這些實體的設計都是基于業務規則,可以說,這一階段主要面對的是業務。也就是“業務驅動建模”
3,物理模型
依照邏輯模型,在數據庫中進行建表、索引等。數據倉庫,為了滿足高性能的需求,可以增加冗余、隱藏表之間的約束等反第三范式操作。
這一階段,主要針對的是數據庫、硬件、性能。
范式:
第一范式:數據庫表的字段都是單一屬性,不可再分。
第二范式:數據庫表中不存在非關鍵字段對任一候選關鍵字段的部分函數依賴。
(部分函數依賴指的是存在組合關鍵字中的某些字段決定非關鍵字段的情況)。即要求所有屬性都依賴于主鍵。
第三范式:數據庫表中不存在非關鍵字段對任一候選關鍵字段的傳遞函數依賴。
范式是向下兼容的。
例如:
| 學生ID | 學生名稱 | 學生部門 | 課程ID | 課程名稱 | 成績 |
| 60100 | 張三 | 教育學院,心理系,1班 | English_1 | 英語1 | 80 |
1)違反第一范式。因為:學生部門可以分解為:學院,系,班級
2)違反第二范式。因為:關鍵字段是學生ID和課程ID, 但存在“課程ID”決定課程名稱和課程學分。
3)違反第三范式。因為:關鍵字段是學生ID,但存在可能名稱和學分依賴“課程ID”。
星型模型和雪花模型
首先,他們都是由一個事實表和一組維度表組成。
星型模型,也被稱為維度建模。
區別在于:
星型模型:維度表直接跟事實表連接,圖型像星星。
如區縣和地市做為同一維度都在地市表中。
*維度預處理,維度會預先進行分類,排序等預處理。
雪花模型:一些維度表不是直接與事實表連接,而是通過維度表中轉,圖形像雪花。
例如:
圖1:星型模型
圖2 雪花模型
從性能來看,星型模型查詢性能好。
為了提高性能,可以允許違反第三范式,適當的冗余、隱藏表之間的約束。
維度建模
將商業維度融合到數據模型中,由此得名維度建模。
或者說,為了分析方便(商業應用要求),將同一維度的不同層次的維度(如地市ID,區縣ID)都融合到事實表中(如用戶寬表)。
維度模型也是星型模型。
它 強調的是先對維度進行預處理,將多個維度集合到一個事實表,形成一個寬表,如上面的用戶統一視圖。包含了20多個維度。這樣可以組合各維度,形成靈活的報表查詢。
B. 分層設計原則
電信行業的數據倉庫都采用了分層設計原則。
總的來說,分三層:接口層、中間匯總層和應用層。
| 應用層 | 數據集市 | 地市數據集市、數據挖掘 |
| 應用層 | KPI報表、cagnos、主題分析、指標庫 | |
| 中間層 | 深度匯總層 | 信息聚合:用戶統一視圖、3G用戶統一視圖、固話用戶統一視圖 |
| 業務拓展:用戶行為、增值業務、集團業務、國際業務 | ||
| 輕度匯總層 | 清單匯總、用戶屬性聚合、費用匯總、集團客戶匯總等 | |
| 接口層 | 存儲層 | 接口備份、增量轉全量、減少I/O(分常用數據和歷史數據) |
| 接口層 | 日接口、月接口、增量接口、全量接口 |
特別強調的是:
中間層是數據倉庫最重要的一層。直接決定了數據倉庫的性能。
一般的做法是:
1)數據匯總。將底層數據按維度進行小顆粒度匯總
2)信息聚合。將多張表的信息聚合在一個表中。這樣的好處,是避免使用表關聯,提高查詢性能。
C. 主題域設計方法
如果說分層設計,是橫向的設計原則,那么主題分域是縱向的處理方法。
具體做法就是從業務上,高度的抽象和歸納,將數據劃分為不同的主題域。
分域后的好處:業務緊耦合、便于數據拓展、便于使用。
域是要具有明顯的表命名規則,如:
用戶信息域—— user
通信行為—— call
數據業務—— gprs
賬務 —— bill
客戶服務—— serv
xx經分系統的數據架構圖:
轉載于:https://www.cnblogs.com/K-han/p/5363666.html
總結
以上是生活随笔為你收集整理的数据仓库中的模型设计(转)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: html基础加强2
- 下一篇: 【一周读书】哲学家,你们都干了些什么?