干貨 | 數據倉庫建模超詳細攻略!
數據倉庫建模,就是數據的組織和存儲方法,它強調從業務出發,將數據有序組織和存儲起來。本文作者對數據倉庫建模常用模型進行了分析,一起來看一下吧。
一、數據倉庫建模是什么?
數據倉庫建模就是數據的組織和存儲方法,舉個例子,數據倉庫的建模就類似于家庭物品收納問題,我們會按照物品的特性以及自身的喜好將物品進行一個井然有序的整理收納,使我們清晰地知道物品歸放的位置,便于日后查找使用,也能無形地讓大腦標記物品位置,形成歸類統一意識,漸漸成為一種好習慣。
數據建模也是如此,它強調從業務出發,將數據有序組織和存儲起來,只有做到這樣,數據才可以高效率、高質量、高性能、低成本地使用,才可以更好地支持企業決策,賦能企業業務,提升企業綜合實力。
二、數據倉庫建模常用模型淺析
1. ER模型(實體關系模型)
數據倉庫之父Bill Inmon提出的建模方法是從全企業的高度,用實體關系(Entity Relationship,ER)模型來描述企業業務,并用規范化的方式表示出來,在范式理論上符合3NF。
1)什么是實體關系模型
實體關系模型由美籍華裔計算機科學家陳品山發明,用概念數據模型的描述所使用的數據或模式圖,實體關系模型將復雜的數據抽象為兩個概念——實體和關系。實體表示一個對象,例如商店、員工這兩個對象,關系是指兩個實體之間的關系,例如員工和商店的從屬關系。對象與對象的關系可以分為1-1,1-n,n-n這三種類型,舉例說明:
- 1-1:一個商店只能有一個店長,一個店長只能在一個商店中任職,則商店和店長就是1對1的關系。
- 1-n:一個商店有很多雇員,雇員只屬于這個商店。則商店和雇員就是1對多的關系。
- n-n:商店里有很多商品,商品也可以在多個商店售賣,則商店和商品就是多對多的關系。
2)范式理論是什么?
范式是表結構設計標準的級別,是關系的約束條件的規范,關系型數據庫的范式一共有六種,分別是第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF)。遵循的范式級別越高,數據冗余性就越低。
因為數據倉庫ER建模遵循3范式標準,本文就只針對于前3個范式進行講解,其他的范式不再贅述, 感興趣的讀者可以自己查詢下相關資料。
數據庫規范化就是使用一系列范式設計數據庫(通常是關系型數據庫)的過程,其目的是減少數據冗余,增強數據的一致性,必須要注意的一點是范式存在前置依賴,如要使用第三范式,設計數據庫時必須依賴于使用前兩個范式的之后,才可以按照第三范式的繼續設計數據庫表。具體設計時要根據業務實際流程,一般遵循第三范式即可。
第一范式:強調列的原子性,要求每列屬性不可分割。
上圖數據列中商品這一列的數據不是原子數據,它可以繼續分割成商品數量和商品名稱,按照第一范式進行調整后,如下圖所示:
第二范式:在1范式的基礎上,要求屬性必須依賴于主鍵,不能存在部分函數依賴。
函數依賴:某個屬性集x決定另一個屬性集y時,稱另一屬性集y依賴于該屬性集x。如學號和姓名,通過學號可以找到姓名,那么就說姓名依賴于學號。
完全函數依賴:通過xy能得到z,但是單獨通過x或者通過y得不到z,那么就稱z完全依賴于xy。如:學號,課程和成績??梢酝ㄟ^學號和課程得到成績,但是單獨通過課程和學號得不到課程,就說成績完全依賴于課程和學號。
部分函數依賴:通過xy能得到z,通過x得到z或者通過y也可以得到z,那么就說z部分依賴于xy,如學號、姓名和性別,通過學號和姓名可以找到性別,也可以通過學號單獨找到性別,就說性別部分依賴于學號和姓名。
傳遞函數依賴:通過x能得到y,通過y得到z,那么就說z傳遞依賴于x,如通過學號得到班級名稱,在通過班級名稱找到班主任,就可以說班主任傳遞依賴于學號。
如上圖所示:表中的主鍵如果是(學號、課程)的話,通過(學號、課程)可以找到成績,分數是完全依賴于(學號、課程)但是姓名可以單獨通過學號找到,姓名不完全依賴于找到(學號、課程),故不符合第二范式。調整后如下所示:
第三范式:消除依賴傳遞,任何非主屬性不依賴與其他非主屬性。
如圖所示:上邊這張表中,如果想要找到輔導,通過學號找到班級,通過班級找到輔導員,存在很明顯的函數依賴,故不符合第三范式要求,調整后如圖所示:
以上就是關于三范式的相關講解,那么按照Bill Inmon提出的數倉建模思想,用ER模型進行建模,首先以京東商城訂單流程為例子,整個交易環節中包含下單,取消訂單、支付,拆單、退款,發貨、收貨、退換貨、評價等,下圖為京東商城訂單截圖。
從圖中我們可以看出按照這樣的方式進行數據建模,雖然減少了數據冗余性,保證了數據的一致性,但是如果要查詢一個相關的指標或者事實可能需要關聯十幾張表,在數據量小,有索引的情況下可能還好些,如果數據量十分驚人,數以億計,那查詢的速度可能十分緩慢,甚至可能會造成宕機,顯而易見這種模型不太適合直接應用于業務分析和計算場景。
2. 維度模型
維度模型是Ralph Kimball 在90年代提出的數倉建模理論,并在于1996年發布的《The Data Warehouse Toolkit》一書中詳細介紹了維度建模理論知識。
維度建模之所以能受到廣泛的關注和認可,一方面是因為它從企業決策分析作為出發點,為數據分析服務,它的初衷是旨在,使用戶更快的完成數據分析,以及更好地實現大規模復雜的查詢操作。另外一方面,得益于技術的發展,基礎存儲硬件的成本逐年降低,同時硬件的計算性能也大幅度提升,才使得維度建模能夠走上歷史舞臺,得到海內外企業和用戶的認同。
維度模型將企業的業務通過兩個方面進行數據建模,即事實表和維度表。事實通常指企業具體的業務過程,如登錄、注冊、加購、下單等等,需要注意的是建模時通常會選擇最細粒度的業務過程數據作為事實表,如訂單事實表會選訂單明細表作為基礎事實表,而上邊簡述的ER模型則選訂單主表作為基礎,維度通常指業務過程發生時所處的環境,如何人、何地、何時、何種東西,何種方法做了哪些事情。
具體細節應該聯系業務過程,通過5W2H的方法進行分析,繪制出具體的總線矩陣。按照維度建模理論,我們將上述訂單過程進行了一個初步建模,中間的為事實表,周邊的為維度表,需要注意的是,本次建模的內容和上邊ER模型講解保持了一致,所以也沒有涵蓋所有的維度,如圖所示:
從上圖中可以看出,維度建模數據結構相對ER模型來說,更為清晰簡潔,查詢時連表操作相對較少,可以及時響應大量且復雜的查詢操作,提升業務分析速度,快速支持業務決策。但是數據存在大量冗余,需要消耗大量存儲空間。
本文由 @菜鳥數據之旅 原創發布于人人都是產品經理,未經作者許可,禁止轉載
題圖來自Unsplash,基于CC0協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
感謝分享?
哦吼,這和軟件工程需求工程都有點類似啊,設計方面還是有很多相似之處的。
學到了!有這么多數據模型!要好好研究運用到實際當中去