想象一個場景，你想說服老闆搞資料倉庫建模，該如何說清楚其價值呢？

也許你會這麼說：

如果把資料看作圖書館裡的書，我們希望看到它們在書架上分門別類地放置；如果把資料看作城市的建築，我們希望城市規劃佈局合理；如果把資料看作電腦檔案和資料夾，我們希望按照自己的習慣有很好的資料夾組織方式，而不是糟糕混亂的桌面，經常為找一個檔案而不知所措。

資料模型就是資料組織和儲存方法，它強調從業務、資料存取和使用角度合理儲存資料。Linux的創始人Torvalds有一段關於“什麼才是優秀程式設計師”的話：“爛程式設計師關心的是程式碼，好程式設計師關心的是資料結構和它們之間的關係”，最能夠說明資料模型的重要性。

上面的話似乎有道理，但如此的表述還是技術化了一點，既沒有站在應用的角度看模型價值，描述的也不夠具體和形象，老闆聽起來肯定也是雲裡霧裡。

我這麼來理解資料倉庫建模的價值。

資料倉庫採集進來的原始資料是雜亂無章的，只有透過構建資料模型，將資料有序的組織和儲存起來之後（即模型），才能為上層應用提供高效靈活的支撐，優秀的資料倉庫模型對應用的價值主要體現在資料質量、響應速度、成本消耗及健壯水平四個方面：

1、資料質量

透過建模可以準確的理解業務和資料，實現業務和資料的標準對映，從而提升應用的有效性。

比如原始資料對於性別欄位的列舉值既有男女，也有01等形式，這種定義的分歧會對上層的應用產生干擾，資料模型應該依據資料標準對原始資料進行標準化，所謂“書同文，車同軌”，資料治理的要求往往要落在具體的資料建模中才能發揮作用。

2、響應速度

透過建模可以提前基於源資料生成應用所需的模型，提升應用響應能力。

寬表就是一種典型的模型，如果沒有寬表，應用就要將資料處理的複雜邏輯嵌入在應用中實現，無論是程式碼的開銷、處理的開銷及訪問的開銷都很大，因此往往需要預先生成模型來置換時間，也就是空間換時間。

風險在於應用變化無常，而模型往往後知後覺，現在只管殺不管埋的現象很多了，導致企業中80%的模型沒人使用，元資料很大的一個應用場景就是模型生命週期的管理。

3、資源消耗

透過建模可以實現公共資料的共享，提升複用能力。

比如發現某些應用共同需要某個計算欄位，則可以將這個計算欄位預先生成（即沉澱成模型），這樣有新的應用需要時可以直接使用，從而在資源和時間節省上一舉兩得。

從這個角度講，OLAP的CUBE其實就是一種建模，當然應用（上層模型也可以看成應用）如果不夠多，複用無從談起，建模也就失去了價值，很多時候感覺資料倉庫的模型沒啥卵用，大多時候是複用的效益不夠明顯所致。

4、健壯水平

透過建模可以實現應用與源資料的解耦，降低源資料變動對應用的影響，提升應用的健壯性。

比如有100個應用直接依賴某個源資料，如果這個源資料發生變動，則需要對100個應用都進行適配改造，代價非常大，而如果100個應用都是基於模型支撐的，則可以在保證模型北向應用介面不動的情況下，僅改造模型和源資料的南向介面就可以了，不僅改動的工作量大幅減少（比如原來改100次現在只需要改一次），同時保證了應用的連續性。

風險在於模型強制對映轉化往往開銷很大，模型的冗餘度、複雜度會越來越高，源資料變更後的一些新特性也會被拋棄，最終影響應用的支撐效率。

很多時候，搞清楚為什麼要資料倉庫建模，比資料倉庫模型怎麼建更有意義，因為前者決定了方向，搞清楚了本質就不容易走錯路，比如一些小而美的場景往往不需要建模。

關於資料倉庫模型怎麼建的文章已經很多了，無論是關係還是維度，相對也比較成熟，這裡就不再累述了。

仁者見仁智者見智，你認為是缺點可能別人認為是優點，隨便從你這挑一句

這裡你認為是牽一髮而動全身，但在別人那裡可能就是一處修改處處生效，你眼中的缺點正是別人眼中的優點[靈光一閃]

資料倉庫採集進來的原始資料是雜亂無章的，只有透過構建資料模型，將資料有序的組織和儲存起來之後，才能為上層應用提供高效靈活的支撐，

價值主要體現在 資料質量 響應速度 成本消耗上