這個問題和工作相關，最近思考也比較多，可以發表些個人看法。但工作日淺，希望以後有更深的理解再做更新。

為什麼要有元資料？

這個問題是我加入公司第一個疑問的問題，畢竟應用在三層或者MVC結構中最終要和資料庫的互動，無論是結構化還是非結構化的資料來源，都要轉成SQL或者類似SQL的查詢語言，對於一個技術人員而言，自然而然覺得使用者的需求直接被轉化為SQL語句是自然而然的事情。定義元資料感覺像是多此一舉，而元資料和資料庫表列的對映關係又非常複雜，實際上會增大開發的難度和工作量。

關於這個問題，我覺得元資料有兩方面的價值：

1. 服務於業務

對大多數公司而言，業務和技術即使不是完全無關的兩個領域，但至少有很多不重合的地方，要求業務人員直接寫SQL去獲取分析所需要的資料是非常困難的。雖然網際網路行業的很多資料分析人員具有SQL相關的知識，但首先對於很多傳統領域（比如製造，銷售），具有相關技術的業務人員還比較少，另外即使是在網際網路領域，當面對資料提取需要的數十行甚至上百行SQL，業務人員難免會焦頭爛額於其中，思考這個Column_ID和DESC是什麼含義，那幾個表不同的列名會不會有相關性，等等。公司的分工要求是人盡其職的，如果業務人員花過多的時間在如何獲取資料上而不是想獲取什麼資料上，對於資料分析的效率是有很大影響的。

元資料的好處在於它是一種高層抽象，你可以理解它為邏輯層，在這裡我們可以使用業務人員更熟悉的術語而遮蔽具體實現的細節。比如資料倉庫的維度模型，我們可以定義事實表，定義維度表，事實表和維度表下面隱藏著具體的物理表，業務人員只需要和事實維度打交道（在什麼維度下獲取什麼事實，當然這只是泛泛而言），而事實維度的概念更容易表述（最基本的寫個文件給股東看，股東或許對庫存週轉率還有興趣，如果看到一頓column_name大概就無法交流下去了）

2. 擴充套件性

如1所言，元資料封裝了底層實現。我認為擴充套件性一方面指的是資料來源，比如異構資料來源，業務人員不需要關於分析的資料是從資料庫來還是Hadoop來，不需要關於底層的實現，元資料是一個介面，接口裡面可能是key-value，可能是column，或者其它什麼，我們不需要關心。另外一方面為底層的調優預留了空間。不可否認自動化生成的SQL有它的問題，但事實上由一個數據庫的門外漢（我就是）寫出來的SQL不會好到哪裡去，甚至會因為不一致性和語法錯誤浪費更多的時間。元資料讓業務人員只在上層搞（在這裡多補充一聚，元資料系統在通過不斷定義新的model來實現業務的靈活性），而把底層交給熟悉資料庫的專業人員。

如何定義元資料？

這裡可以參考Kimball的維度模型，比如最基本的元資料可以有事實(Fact)，維度(Dimension)，當然還可以有其它很多，比如對於報表領域，你可以定義report的概念來包含相關的事實與維度。推薦microstrategy的相關文件，當然各家都有各家自己的設計觀念，即使簡單說可能也要好長的篇幅了，希望以後有時間總結下。

如何才算好的元資料？

慚愧，這點等我瞭解清楚再補充。