一、概述
在多維分析的商業智能解決方案中，根據事實表和維度表的關系，又可將常見的模型分為星型模型和雪花型模型。在設計邏輯型數據的模型的時候，就應考慮數據是按照星型模型還是雪花型模型進行組織。
當所有維表都直接連接到“ 事實表”上時，整個圖解就像星星一樣，故將該模型稱為星型模型，
星型架構是一種非正規化的結構，多維數據集的每一個維度都直接與事實表相連接，不存在漸變維度，所以數據有一定的冗余，
如在地域維度表中，存在國家 A 省 B 的城市 C 以及國家 A 省 B 的城市 D 兩條記錄，那么國家 A 和省 B 的信息分別存儲了兩次，即存在冗余。
當有一個或多個維表沒有直接連接到事實表上，而是通過其他維表連接到事實表上時，其圖解就像多個雪花連接在一起，故稱雪花模型。
雪花模型是對星型模型的擴展。它對星型模型的維表進一步層次化，原有的各維表可能被擴展為小的事實表，形成一些局部的 " 層次 " 區域，這些被分解的表都連接到主維度表而不是事實表。如圖 2，將地域維表又分解為國家，省份，城市等維表。
它的優點是 : 通過最大限度地減少數據存儲量以及聯合較小的維表來改善查詢性能。雪花型結構去除了數據冗余。
此在冗余可以接受的前提下，實際運用中星型模型使用更多，也更有效率（空間換易用與效率）。
二、使用選擇
1.數據優化
雪花模型使用的是規范化數據，也就是說數據在數據庫內部是組織好的，以便消除冗余，因此它能夠有效地減少數據量。通過引用完整性，其業務層級和維度都將存儲在數據模型之中。
▲圖1 雪花模型
相比較而言，星形模型實用的是反規范化數據。在星形模型中，維度直接指的是事實表，業務層級不會通過維度之間的參照完整性來部署。
▲圖2 星形模型
2.業務模型
主鍵是一個單獨的唯一鍵(數據屬性)，為特殊數據所選擇。在上面的例子中，Advertiser_ID就將是一個主鍵。外鍵(參考屬性)僅僅是一個表中的字段，用來匹配其他維度表中的主鍵。在我們所引用的例子中，Advertiser_ID將是Account_dimension的一個外鍵。
在雪花模型中，數據模型的業務層級是由一個不同維度表主鍵-外鍵的關系來代表的。而在星形模型中，所有必要的維度表在事實表中都只擁有外鍵。
3.性能
第三個區別在於性能的不同。雪花模型在維度表、事實表之間的連接很多，因此性能方面會比較低。舉個例子，如果你想要知道Advertiser 的詳細信息，雪花模型就會請求許多信息，比如Advertiser Name、ID以及那些廣告主和客戶表的地址需要連接起來，然后再與事實表連接。
而星形模型的連接就少的多，在這個模型中，如果你需要上述信息，你只要將Advertiser的維度表和事實表連接即可。
4.ETL
雪花模型加載數據集市，因此ETL操作在設計上更加復雜，而且由於附屬模型的限制，不能並行化。
星形模型加載維度表，不需要再維度之間添加附屬模型，因此ETL就相對簡單，而且可以實現高度的並行化。
總結
通過上面的對比，我們可以發現數據倉庫大多數時候是比較適合使用星型模型構建底層數據Hive表，通過大量的冗余來提升查詢效率，星型模型對OLAP的分析引擎支持比較友好，這一點在Kylin中比較能體現。而雪花模型在關系型數據庫中如MySQL，Oracle中非常常見，尤其像電商的數據庫表。在數據倉庫中雪花模型的應用場景比較少，但也不是沒有，所以在具體設計的時候，可以考慮是不是能結合兩者的優點參與設計，以此達到設計的最優化目的。
參考鏈接：http://blog.csdn.net/u010454030/article/details/74589791
三、建模四步走
1.選取要建模的業務處理流程
關注業務處理流程，而不是業務部門！
2.定義業務處理的粒度
“如何描述事實表的單個行？”
3.選定用於每個事實表行的維度
常見維度包括日期、產品等
4.確定用於形成每個事實表行的數字型事實
典型的事實包括訂貨量、支出額這樣的可加性數據
對於通過計算而得到的事實是否應該物理地存放在數據庫表中，《工具箱》中給出的建議是應該存放，利用少量的存儲空間來避免用戶的計算錯誤，是可取的，但是對於不可加的數據（例如零售中的毛利潤率、單價等）不用單獨存放，只需存放銷量與銷售額、毛利潤這樣的在各個緯度上的可加性數據即可。對於利率這樣的百分比數據，事實表中存放分子、分母即可！
小結就是：確定業務流程->確定粒度->確定緯度->確定事實