廣告-offline-warehouse--03-double_happy

數據庫&數據倉庫區別：

MySQL
1.範式：
	1.第0範式：
		 無重複數據
	2.第一範式：
		滿足屬性不可分
	3.第二範式 ：
		滿足第一範式基礎上，
		確保這張表 所有字段 都與 主鍵相關 
 4.第三範式：
        二範式的基礎上，確保數據表中的
        每一列數據都和主鍵直接相關，不能間接相關

問題：
	1.數據倉庫 和範式之間存在 一種什麼樣的關係？
	   即： 數倉中 維度建模
	   	第二範式中的  
	   		1.訂單表 就是  事實表
	   	   2.商品表 、用戶表 就是  維度表
	   	這就是 星星模型
    
       第三範式 就是 雪花模型
      
    即：
    	星星模型和雪花模型 區別就是：
    		維度表 是否和事實表 直接相連

2.有冗餘的 事實表？
	 即：
	 	第一範式
	 	就是 將一些維度信息 冗餘 到 事實表中的

數倉 和 數據庫 真正的區別： 即 各自的側重點
	1.數據庫 
		1.聯機事務處理 oltp(on-line transaction processing)
		就是 各種 增刪改查的操作
	2.數倉
		1.聯機分析處理 olap（）
		   就是 數據插入和查詢   不會去設計 數據的刪除和修改數據操作
		   即：
		   	Hive裏 你修改一條數據 對應hdfs 三個副本 都要修改 成本很大

維度表設計

維度：
	1.對環境的描述  
事實：
	1.指標 度量

eg:
	select itme,sum(gmv)
	from tbl
	group by item 

即：
	item --》維度
	sum(gmv) --> 聚合指標   


eg：
	分析交易過程：
		1. 廣告位、 時間、買家(客戶、消費者) 、賣家    ---》維度
		 即：
		 	用於分析 指標所需要的 一個多樣的 環境
		 	

2.維度獲取方式：
	1.業務定義的  
			即：
				業務方 會把 維度 和 指標 告訴你 
	2. 現成的 可視化 報表 上
	     從數據獲取 能看到！

1.如何去設計一張維度表
	1.選擇維度
		eg：做時間的維表、商品的維表、地區的維表
	2. eg：
		  select xx
		  from 
		  (
	    select xx       ---》 主 維表 
	     ) as t1 
	     left join ...    ---》關聯 維表
	  我們在開發的時候 先：
	    1.確認一張 主 維表
	           即：
	           	這張表 必然包含大部分 我們這張維表的信息
	3. 確定相關、需要關聯的 維表
	    eg:
	    	     主表：商品表
	    	     需要關聯的維表： spu、店鋪、商家
	4.確定維度屬性(就是 字段)
		1.儘可能的豐富（盡肯能 多選一些）
				即：下游使用  統計分析類操作 方便
		        就是 第二範式的表 變 第一範式  的過程
		 2.字段 作爲 維度 還是 事實
		 	1.用於查詢的約束條件(where) 或者 用於分組統計（group by）
		 		就是 維度
		 	2.參與實際的度量計算的  就是 事實

層次結構：
	上卷：
		就是維度越來越粗
	下鑽：
		就是維度越來越細

會有這樣的一個問題？
 eg：
 	上面的商品 維表中 沒有加入品牌字段 
 	就是說 類目、地區、品牌是否應該全部存在於一張商品維表當中？

	1.規範化
	2.反規範化

什麼是規範化？
	對於oltp 來說 ，會採用 規範化的方式
	1.一些 維度 移到 自身所屬表當中  刪除冗餘數據 

反規範化？
	退化維度
	冗餘一部分數據 到維表當中  下游使用 易用性比較高
	存儲成本高一些

大數據場景下 反規範化