正規化建模（經典數倉----關係型資料庫）

　　不多贅述，直接三正規化：

　　第一正規化：

　　保證每列的原子性。即資料庫表中的所有欄位值都是不可分解的原子值。

　　第二正規化：

　　保證一張表只描述一件事情。即除主鍵外其他欄位完全依賴於主鍵。

　　第三正規化：

　　不可傳遞依賴。即表中的欄位和主鍵直接對應不依靠其他中間欄位，說白了就是，決定某欄位值的必須是主鍵。

ER實體建模：

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

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

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

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

維度建模：

　　好處：

　　1.適配大資料的處理方式

　　維度模型的非強正規化的，可以更好的利用大資料處理框架的處理能力，避免正規化操作的過多關聯操作，可以實現高度的並行化。資料倉庫大多數時候是比較適合使用星型模型構建底層資料Hive表，通過大量的冗餘來提升查詢效率，星型模型對OLAP的分析引擎支援比較友好，這一點在Kylin中比較能體現。雪花模型在關係型資料庫中如MySQL，Oracle中非常常見，尤其像電商的資料庫表。

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

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

　　分層和建模的關係：　　

　　明細層的正規化模型：

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

　　星型和雪花模型的介紹及不同：

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

　　星型模型：
　　核心是一個事實表及多個非正規化描述的維度表組成，維度表之間是沒有關聯的，維度表是直接關聯到事實表上的，只有當維度表極大，儲存空間是個問題時，才考慮雪花型維度，簡而言之，最好就用星型維度即可當所有維表都直接連線到“ 事實表”上時，整個圖解就像星星一樣，故將該模型稱為星型模型。
　　星型架構是一種非正規化的結構，多維資料集的每一個維度都直接與事實表相連線，不存在漸變維度，所以資料有一定的冗餘，如在地域維度表中，存在國家 A 省 B 的城市 C 以及國家 A 省 B 的城市 D 兩條記錄，那麼國家 A 和省 B的資訊分別儲存了兩次，即存在冗餘。

　　雪花模型：
　　星形模式中的維表相對雪花模式來說要大，而且不滿足規範化設計。雪花模型相當於將星形模式的大維表拆分成小維表，滿足了規範化設計。然而這種模式在實際應用中很少見，因為這樣做會導致開發難度增大，而資料冗餘問題在資料倉庫裡並不嚴重，可以認為雪花模型是星型模型的一個擴充套件，每個維度表可以繼續向外擴充套件，連線多個子維度。當有一個或多個維表沒有直接連線到事實表上，而是通過其他維表連線到事實表上時，其圖解就像多個雪花連線在一起，故稱雪花模型。