https://wenku.baidu.com/view/b6bd5ccb4028915f804dc294.html 資料倉庫建模案例

https://wenku.baidu.com/view/623fb724482fb4daa58d4b69.html 資料倉庫建模規範1.0

http://bigdata.51cto.com/art/201611/520727.htm  資料倉庫優化資料分析

https://wenku.baidu.com/view/80f35707844769eae009ed29.html?re=view  資料倉庫的建模方法

http://www.docin.com/p-1292730739.html  資料倉庫維度集定義

寬表的思考

寬表從字面意義上講就是欄位比較多的資料庫表。通常是指業務主題相關的指標、維度、屬性關聯在一起的一張資料庫表。由於把不同的內容都放在同一張表儲存，寬表已經不符合三正規化的模型設計規範，隨之帶來的主要壞處就是資料的大量冗餘，與之相對應的好處就是查詢效能的提高與便捷。這種寬表的設計廣泛應用於資料探勘模型訓練前的資料準備，通過把相關欄位放在同一張表中，可以大大提高資料探勘模型訓練過程中迭代計算時的效率問題。

一 寬表的優點

1.      寬表淺意上的好處

在當前這個專案中，大量使用了寬表，欄位超過一百五十個欄位的寬表有五張，分別是客戶機構級資訊表、客戶客戶經理級資訊表、客戶經理資訊表、集團客戶資訊表、戰略客戶資訊表。

從上面的表名中可以猜到，這是個CRM專案，我這裡能列舉出來的優點也是在專案中體現出來的優點。

大量使用寬表究竟給我們帶來了什麼好處？

•  窺一表知全貌
•  查詢速度快（此處我一直保留疑問）

窺一表知全貌：這個好處很明顯，尤其是收到報表開發人員的歡迎，他們不關心資料如何儲存，只關心這張報表是不是很方便，很快的能開發出來。還有一個就是資料分析人員，銀行業大部分資料分析人員很討厭做表關聯，他們喜歡一條記錄看到客戶的全貌。

查詢速度快：大多數情況確實如此，大部分SQL慢都是由於表關聯造成的，所以大家都在思考不關聯出結果。於是，出現了將一些常用的資訊都做成了大寬表，此處讓我這種正規化強迫症患者很是頭疼……

二 寬表的不便

從一個ETL人員角度講，使用寬錶帶給我的痛苦遠遠大於它帶給我的快樂，此處描述一下我們目前面對的系統，從系統出發解釋寬錶帶來的問題。

專案是一個CRM系統，以倉庫資料（TD）為基礎，進行建模、資料加工，作為倉庫的一個集市落地後，在將這部分資料，同步到查詢伺服器（DB2）上，每日從TD到DB2的資料量約為16G，同步資料的方式為TD匯出資料生成txt，上傳到FTP伺服器後在通過SHELL載入到DB2。

瞭解了專案的背景，就可以列舉出在使用寬表時有如下不便

• 指令碼過長，不易維護
• 欄位的增刪過於複雜

因為要在兩個系統中同步兩張表一份資料，增刪欄位時一定要考慮一致性，同時要考慮歷史資料如何處理。每次都需要經過如下步驟：

1.        修改TD表結構

2.        修改TD指令碼

3.        修改匯出資料指令碼

4.        修改DB2表結構

5.        修改DB2載入資料的Shell指令碼

每次變動都伴隨這大量的工作，同時還需要因為這個欄位載入新的歷史資料或更新這個欄位的內容，此處在專案後期維護中帶來了很大的工作量。

三 如何優雅的使用寬表

寬表在倉庫的彙總層大量使用，如客戶、存款、貸款等通用的實體都被設計為寬表。這些寬表會面臨我上面提到的問題嗎？

顯然不會，倉庫的表很少因為個人需求而增減欄位，同時倉庫大多隻負責原始資料的儲存，不會涉及到太複雜的欄位加工邏輯，故大多數彙總層的表都被設計為寬表。

要想優雅的使用寬表，我認為需要注意以下這一點：

欄位是否會頻繁增減

對於不涉及到事務的表且欄位不會頻繁增加，建議設計為寬表，尤其對於BI系統。

當然，這只是一個最簡單粗暴的原則，真正做的時候，你要考慮對於不同的資料庫產品，寬表中很多欄位是否為空等。

針對不用的場景做不同的選擇，這句話，聽起來很虛，其實很實。