## 建模方法論 > 數倉的建模或者分層，其實都是為了更好的去組織、管理、維護資料,所以當你站在更高的維度去看的話，所有的劃分都是為了更好的管理。小到JVM 記憶體區域的劃分，JVM 中堆空間的劃分(年輕代、老年代、方法區等)，大到國家的省市區的劃分，無一例外的都是為了更好的組織管理 1. **訪問效能**：能夠快速查詢所需的資料，減少資料I/O。 1. **資料成本**：減少不必要的資料冗餘，實現計算結果資料複用，降低大資料系統中的儲存成本和計算成本。 1. **使用效率**：改善使用者應用體驗，提高使用資料的效率。 1. **資料質量**：改善資料統計口徑的不一致性，減少資料計算錯誤的可能性，提供高質量的、一致的資料訪問平臺。 > 需要注意的建模其實是和公司的業務、公司的資料量、公司使用的工具、公司資料的使用方式密不可分的，因為模型是概念上的東西，需要理論落地至於落地到什麼程度，就取決於公司的現狀了 ## 正規化建模(關係型資料庫) 正規化建模法其實是我們在構建資料模型常用的一個方法，該方法的主要由Inmon所提倡，主要解決關係型資料庫得資料儲存，利用的一種技術層面上的方法，主要用於業務系統，**所以正規化建模主要是利用關係型資料庫進行數倉建設** 目前，我們在關係型資料庫中的建模方法，大部分採用的是三正規化建模法。 符合3NF要求的資料庫設計，基本上解決了資料冗餘過大，插入異常，修改異常，刪除異常的問題。 ### 三正規化 #### 第一正規化 屬性值不可再分，說直白點就是一列裡面不能包含多個小列，就像下面這樣  **1NF是所有關係型資料庫的最基本要求**，你在關係型資料庫管理系統（RDBMS），例如SQL Server，Oracle，MySQL中建立資料表的時候，如果資料表的設計不符合這個最基本的要求，那麼操作一定是不能成功的。也就是說，只要在RDBMS中已經存在的資料表，一定是符合1NF的 #### 第二正規化 這裡我們先說一下，為什麼有了第一正規化，還需要第二正規化，那是應為第一正規化，不能消除重複，存在資料冗餘過大，導致插入異常，刪除異常，修改異常的問題  所以要求每張表都要有一個主鍵，其它欄位(列)**完全依賴主鍵**，也就是說要求實體的屬性**完全依賴於主關鍵字**。也就是說表只描述一個事實，因為這賬號表描述了3個事實，學生、課程、和系 >例如，如果花名冊裡只有名字，沒有學號，則重名的話會很麻煩。 所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關係，例如上面的`系主任`和`系名` 就是不依賴學號的，所以這裡應該單獨拆出來 #### 第三正規化 所有欄位只能**直接依賴主鍵**，不得依賴於其它欄位(非主屬性) 消除依賴傳遞。所謂傳遞函式依賴指的是如果存在"A-->B-->C"的決定關係，則C傳遞函式依賴於A。也就是說**表中的欄位和主鍵直接對應不依靠其他中間欄位，說白了就是，決定某欄位值的必須是主鍵，而不是一個依賴於主鍵的其他欄位** ### 正規化建模的優缺點 #### 優點 節約儲存(尤其是利用資料庫進行數倉建設的時候) 規範化帶來的好處是通過**減少資料冗餘****提高更新資料的效率**，**同時保證資料完整性**。 結構清晰，易於理解 #### 缺點 構建比較複雜 查詢複雜(需要很多的關聯) 不適合在大資料環境下構建(1 查詢複雜 2 儲存很便宜) > 由於建模方法限定在關係型資料庫之上，在某些時候反而限制了整個資料倉庫模型的靈活性，效能等，特別是考慮到資料倉庫的底層資料向資料集市的資料進行彙總時，需要進行一定的變通才能滿足相應的需求。 ### 為什麼要學習正規化建模 上游資料來源往往是業務資料庫，而這些業務資料庫採用的實正規化建模，所以瞭解正規化建模可以幫助我們去合理的建設數倉 > 如果瞭解正規化建模，從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 所倡導，他的《[資料倉庫工具箱](https://www.cnblogs.com/fly-bird/articles/11332515.html)》，是資料倉庫工程領域最流行的數倉建模經典。維度建模以分析決策的需求出發構建模型，構建的資料模型為分析需求服務，因此它重點解決使用者如何更快速完成分析需求，同時還有較好的大規模複雜查詢的響應效能。 維度建模源自資料集市，主要面向分析場景 **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操作(上鑽下鑽) 維度建模非常直觀，緊緊圍繞著業務模型，可以直觀的反映出業務模型中的業務問題。不需要經過特別的抽象處理，即可以完成維度建模。 可擴充套件，維度模型是可擴充套件的。由於維度模型允許資料冗餘，因此當向一個維度表或事實表中新增欄位時，不會像關係模型那樣產生巨大的影響，帶來的結果就是更容易容納不可預料的新增資料。 #### 缺點 資料冗餘，維度補全後造成的資料浪費 靈活性差，維度變化造成的資料更新量大(例如刷資料的時候，需要刷大量的表) 與典型的正規化理論差異很大，如資料不一致，比如使用者發起購買行為的時候的資料，和我們維度表裡面存放的資料不一致 > 既然如此為什麼還要使用正規化建模呢，其實和我們使用的工具有關係 由於在構建星型模式之前需要進行大量的資料預處理，因此會導致大量的資料處理工作。而且，當業務發生變化，需要重新進行維度的定義時，往往需要重新進行維度資料的預處理。而在這些與處理過程中，往往會導致大量的資料冗餘。 如果只是依靠單純的維度建模，不能保證資料來源的一致性和準確性，**而且在資料倉庫的底層，不是特別適用於維度建模的方法**。 維度建模的領域主要適用與資料集市層，它的最大的作用其實是為了解決資料倉庫建模中的效能問題。維度建模很難能夠提供一個完整地描述真實業務實體之間的複雜關係的抽象方法 ## 總結 上述的這些方法都有自己的優點和侷限性，在建立自己的資料倉庫模型的時候，可以參考使用上述的三種資料倉庫得建模方法，在各個不同階段採用不同的方法，從而能夠保證整個資料倉庫建模的質量。 方法論僅僅停留在理論層面上，落地實現的才真正決定了數倉設計的好壞，當然再好的方法，只有在合適的階段使用，才有意義，才能發揮它最大