建模方法論

數倉的建?；蛘叻謱?，其實都是為了更好的去組織、管理、維護數據,所以當你站在更高的維度去看的話，所有的劃分都是為了更好的管理。小到JVM 內存區域的劃分，JVM 中堆空間的劃分(年輕代、老年代、方法區等)，大到國家的省市區的劃分，無一例外的都是為了更好的組織管理

1. 訪問性能：能夠快速查詢所需的數據，減少數據I/O。
2. 數據成本：減少不必要的數據冗余，實現計算結果數據復用，降低大數據系統中的存儲成本和計算成本。
3. 使用效率：改善用戶應用體驗，提高使用數據的效率。
4. 數據質量：改善數據統計口徑的不一致性，減少數據計算錯誤的可能性，提供高質量的、一致的數據訪問平臺。
   

   需要注意的建模其實是和公司的業務、公司的數據量、公司使用的工具、公司數據的使用方式密不可分的，因為模型是概念上的東西，需要理論落地至于落地到什么程度，就取決于公司的現狀了

范式建模(關系型數據庫)

范式建模法其實是我們在構建數據模型常用的一個方法，該方法的主要由Inmon所提倡，主要解決關系型數據庫得數據存儲，利用的一種技術層面上的方法，主要用于業務系統，所以范式建模主要是利用關系型數據庫進行數倉建設

目前，我們在關系型數據庫中的建模方法，大部分采用的是三范式建模法。

符合3NF要求的數據庫設計，基本上解決了數據冗余過大，插入異常，修改異常，刪除異常的問題。

三范式

第一范式

屬性值不可再分，說直白點就是一列里面不能包含多個小列，就像下面這樣

1NF是所有關系型數據庫的最基本要求，你在關系型數據庫管理系統（RDBMS），例如SQL Server，Oracle，MySQL中創建數據表的時候，如果數據表的設計不符合這個最基本的要求，那么操作一定是不能成功的。也就是說，只要在RDBMS中已經存在的數據表，一定是符合1NF的

第二范式

這里我們先說一下，為什么有了第一范式，還需要第二范式，那是應為第一范式，不能消除重復，存在數據冗余過大，導致插入異常，刪除異常，修改異常的問題

所以要求每張表都要有一個主鍵，其它字段(列)完全依賴主鍵，也就是說要求實體的屬性完全依賴于主關鍵字。也就是說表只描述一個事實，因為這賬號表描述了3個事實，學生、課程、和系

例如，如果花名冊里只有名字，沒有學號，則重名的話會很麻煩。
所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那么這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系，例如上面的系主任和系名 就是不依賴學號的，所以這里應該單獨拆出來

第三范式

所有字段只能直接依賴主鍵，不得依賴于其它字段(非主屬性) 消除依賴傳遞。所謂傳遞函數依賴指的是如果存在"A-->B-->C"的決定關系，則C傳遞函數依賴于A。也就是說表中的字段和主鍵直接對應不依靠其他中間字段，說白了就是，決定某字段值的必須是主鍵，而不是一個依賴于主鍵的其他字段

范式建模的優缺點

優點

節約存儲(尤其是利用數據庫進行數倉建設的時候)

規范化帶來的好處是通過減少數據冗余**提高更新數據的效率，同時保證數據完整性**。

結構清晰，易于理解

缺點

構建比較復雜

查詢復雜(需要很多的關聯)

不適合在大數據環境下構建(1 查詢復雜 2 存儲很便宜)

由于建模方法限定在關系型數據庫之上，在某些時候反而限制了整個數據倉庫模型的靈活性，性能等，特別是考慮到數據倉庫的底層數據向數據集市的數據進行匯總時，需要進行一定的變通才能滿足相應的需求。

為什么要學習范式建模

上游數據源往往是業務數據庫，而這些業務數據庫采用的實范式建模，所以了解范式建?？梢詭椭覀內ズ侠淼慕ㄔO數倉

如果了解范式建模，從er 模型可以了解到數據架構，例如一個電商系統，從er模型就可以知道哪些涉及到商品的管理、用戶的管理、訂單管理，拿到這些關系之后，我們就可以更好的進行數倉管理與建
數據源的規范定義需要我們了解范式理論，可以更好的和業務系統進行對接

數倉的稀有系統，如報表系統設計的時候也會使用到范式建模

ER實體建模

將事務抽象為"實體"（Entity）、"屬性"（Property）、"關系"（Relationship）來表示數據關聯和事物描述，這種對數據的抽象建模通常被稱為ER實體關系模型。

實體建模法并不是數據倉庫建模中常見的一個方法，它來源于哲學的一個流派。

從哲學的意義上說，客觀世界應該是可以細分的，客觀世界應該可以分成由一個個實 體，以及實體與實體之間的關系組成。我們在數據倉庫的建模過程中完全可以引入這個抽象的方法，將整個業務也可以劃分成一個個的實體，而每個實體之間的 關系，以及針對這些關系的說明就是我們數據建模需要做的工作。

在日常建模中，"實體"用矩形表示，"關系"用菱形，"屬性"用橢圓形。ER實體關系模型也稱為E-R關系圖

雖然實體法粗看起來好像有一些抽象，其實理解起來很容易。即我們可以將任何一個業務過程劃分成 3 個部分，實體，事件和說明。

描述一個簡單的事實：“小明開車去學校上學”。以這個業務事實為例，我們可以把“小明”，“學?！笨闯墒且粋€實體， “上學”描述的是一個業務過程，我們在這里可以抽象為一個具體“事件”，而“開車去”則可以看成是事件“上學”的一個說明。

應用場景

ER模型是數據庫設計的理論基礎，當前幾乎所有的OLTP系統設計都采用ER模型建模的方式。

Bill Inom提出的數倉理論，推薦采用ER關系模型進行建模。

BI架構提出分層架構，數倉底層ods、dwd也多采用ER關系模型進行設計。

由于實體建模法，能夠很輕松的實現業務模型的劃分，因此，在業務建模階段和領域概念建模階段，實體建模法有著廣泛的應用。

業務歸納

使用的抽象歸納方法其實很簡單，任何業務可以看成 3 個部分：

1. 實體，主要指領域模型中特定的概念主體，指發生業務關系的對象
2. 事件，主要指概念主體之間完成一次業務流程的過程，特指特定的業務過程
3. 說明，主要是針對實體和事件的特殊說明

維度建模

概念和背景

維度模型是數據倉庫領域大師Ralph Kimball 所倡導，他的《數據倉庫工具箱》，是數據倉庫工程領域最流行的數倉建模經典。維度建模以分析決策的需求出發構建模型，構建的數據模型為分析需求服務，因此它重點解決用戶如何更快速完成分析需求，同時還有較好的大規模復雜查詢的響應性能。

維度建模源自數據集市，主要面向分析場景 Ralph Kimball 推崇數據集市的集合為數據倉庫，同時也提出了對數據集市的維度建模，將數據倉庫中的表劃分為事實表、維度表兩種類型。

一般也稱之為星型結構建模，有時也加入一些雪花模型在里面。維度建模是一種面向用戶需求的、容易理解的、訪問效率高的建模方法

維度模型通常以一種被稱為星型模式的方式構建。所謂星型模式，就是以一個事實表為中心，周圍環繞著多個維度表。

還有一種模式叫做雪花模式，是對維度做進一星型模型做OLAP分析很方便

為什么選擇維度建模

適配大數據的處理方式

維度模型的非強范式的，可以更好的利用大數據處理框架的處理能力，避免范式操作的過多關聯操作，可以實現高度的并行化。

數據倉庫大多數時候是比較適合使用星型模型構建底層數據Hive表，通過大量的冗余來提升查詢效率，星型模型對OLAP的分析引擎支持比較友好，這一點在Kylin中比較能體現。

雪花模型在關系型數據庫中如MySQL，Oracle中非常常見，尤其像電商的數據庫表。

自下而上的建設現狀

表已經存在，業務已經開發完畢，需求直接提過來了，這幾乎是一個普遍現狀，因為很少有公司會提前成立數據部門，讓數據部門跟隨著業務從頭開始一直成長，都是當業務發展到一定的階段了，想通過數據來提高公司的運營效果

簡單的模型 使用簡單

這個模型相對來說是比較簡單的，簡單主要體現在兩個方面

1. 維度建模非常直觀，緊緊圍繞著業務模型，可以直觀的反映出業務模型中的業務問題。不需要經過特別的抽象處理，即可以完成維度建模。這一點也是維度建模的優勢。
2. 星型結構的實現不用考慮很多正規化的因素，設計與實現都比較簡單。

分層和建模的關系

明細層的范式模型

明細層采用傳統的三范式關系模型。這一層次的數據模型要將業務過程描述清楚，將源數據（即業務系統）中隱含的、有歧義的概念進行清晰化，如活躍用戶、VIP用戶等。該層次的數據模型追求的目標是靈活地表達業務過程，要保證數據一致性、唯一性、正確性，以盡量少的代價與源數據保持數據同步，同時該層次的數據模型不建議開給不懂技術的業務人員直接使用，因此，采用關系型的三范式模型是最佳的選擇。

集市層的維度模型

集市層是按照業務主題、分主題構建出來的、面向特定部門或人員的數據集合，該層次的數據模型會開放給業務人員使用，進行數據挖掘及業務分析。由于業務員多數不懂數據庫技術，缺少將業務需求轉換為關系型數據結構的邏輯思維，更寫不出復雜的SQL語句，因此，越簡單的數據模型，越能被他們所接受，因此，這個層次所構建出來的數據模型，要按照業務過程進行組織，每個事實表代表一個獨立的業務過程，事實表之間不存在直接的依賴關系，這樣業務人員可以很容易地將分析需求對應到事實表上，利用工具或手工寫出簡單的SQL，將統計數據提取出來進行分析。

模型實現

模型的實現主要指的是在維度建模過程中，需要對維度表和事實表進行關聯設計，而這里我們對維度表的設計，就決定了我們最終與事實表關聯的之后的形態。也就是說我們可以根據事實表和維度表的關系，又可將常見的模型分為星型模型和雪花型模型

星型模型和雪花模型的主要區別在于對維度表的拆分，對于雪花模型，維度表的設計更加規范，一般符合3NF；而星型模型，一般采用降維的操作，利用冗余來避免模型過于復雜，提高易用性和分析效率。

星型模型

核心是一個事實表及多個非正規化描述的維度表組成，維度表之間是沒有關聯的，維度表是直接關聯到事實表上的，只有當維度表極大，存儲空間是個問題時，才考慮雪花型維度，簡而言之，最好就用星型維度即可

當所有維表都直接連接到“ 事實表”上時，整個圖解就像星星一樣，故將該模型稱為星型模型

星型架構是一種非正規化的結構，多維數據集的每一個維度都直接與事實表相連接，不存在漸變維度，所以數據有一定的冗余，如在地域維度表中，存在國家 A 省 B 的城市 C 以及國家 A 省 B 的城市 D 兩條記錄，那么國家 A 和省 B 的信息分別存儲了兩次，即存在冗余。

雪花模型

星形模式中的維表相對雪花模式來說要大，而且不滿足規范化設計。雪花模型相當于將星形模式的大維表拆分成小維表，滿足了規范化設計。然而這種模式在實際應用中很少見，因為這樣做會導致開發難度增大，而數據冗余問題在數據倉庫里并不嚴重

可以認為雪花模型是星型模型的一個擴展，每個維度表可以繼續向外擴展，連接多個子維度。

當有一個或多個維表沒有直接連接到事實表上，而是通過其他維表連接到事實表上時，其圖解就像多個雪花連接在一起，故稱雪花模型

星座模型

前面介紹的兩種維度建模方法都是多維表對應單事實表，但在很多時候維度空間內的事實表不止一個，而一個維表也可能被多個事實表用到。在業務發展后期，絕大部分維度建模都采用的是星座模式。

可以認為是多個事實表的關聯或者是星型模型的關聯，其實到了業務發展后期都是星座模型

應用場景

維度建模是面向分析場景而生，針對分析場景構建數倉模型，重點關注快速、靈活的解決分析需求，同時能夠提供大規模數據的快速響應性能。

針對性強，主要應用于數據倉庫構建和OLAP引擎底層數據模型

優點

方便使用，模型簡單

適合大數據下的處理操作(其實就是shuffle)

適合OLAP操作(上鉆下鉆)

維度建模非常直觀，緊緊圍繞著業務模型，可以直觀的反映出業務模型中的業務問題。不需要經過特別的抽象處理，即可以完成維度建模。

可擴展，維度模型是可擴展的。由于維度模型允許數據冗余，因此當向一個維度表或事實表中添加字段時，不會像關系模型那樣產生巨大的影響，帶來的結果就是更容易容納不可預料的新增數據。

缺點

數據冗余，維度補全后造成的數據浪費

靈活性差，維度變化造成的數據更新量大(例如刷數據的時候，需要刷大量的表)

與典型的范式理論差異很大，如數據不一致，比如用戶發起購買行為的時候的數據，和我們維度表里面存放的數據不一致

既然如此為什么還要使用范式建模呢，其實和我們使用的工具有關系

由于在構建星型模式之前需要進行大量的數據預處理，因此會導致大量的數據處理工作。而且，當業務發生變化，需要重新進行維度的定義時，往往需要重新進行維度數據的預處理。而在這些與處理過程中，往往會導致大量的數據冗余。

如果只是依靠單純的維度建模，不能保證數據來源的一致性和準確性，而且在數據倉庫的底層，不是特別適用于維度建模的方法。

維度建模的領域主要適用與數據集市層，它的最大的作用其實是為了解決數據倉庫建模中的性能問題。維度建模很難能夠提供一個完整地描述真實業務實體之間的復雜關系的抽象方法

總結

上述的這些方法都有自己的優點和局限性，在創建自己的數據倉庫模型的時候，可以參考使用上述的三種數據倉庫得建模方法，在各個不同階段采用不同的方法，從而能夠保證整個數據倉庫建模的質量。

方法論僅僅停留在理論層面上，落地實現的才真正決定了數倉設計的好壞，當然再好的方法，只有在合適的階段使用，才有意義，才能發揮它最大的價值