關于“元數據”的理解
?
??? 一直都對元數據一知半解，當然理論我都知道，但是主要是沒有實際應用過，所以對這方面的知識還是比較好奇，想多了解一下。最近又看到一篇關于“元數據”的文章，發現寫得不錯，摘錄下來留存。
?
?
元數據
?
??? 元數據(Metadata)：就是數據的數據，用于建立、管理、維護和使用數據倉庫。元數據管理是企業級數據倉庫中的關鍵組件，貫穿于建立數據倉庫的整個過程。
?
元數據使得用戶可以掌握數據的歷史情況，如數據從哪里來？流通時間有多長？更新頻率是多大？數據元素的含義是什么？對它已經進行了哪些計算、轉換和篩選等等。在需求不確定情況下，在瞬間萬變的商業環境下，元數據可以更好的支持需求的變化，降低項目風險。
元數據貫徹于建立數據倉庫的整個過程，不只是ETL過程需要元數據的支持。
?
??? 
?
元數據分類
?
通常把元數據分為技術元數據(Technical Metadata)和業務元數據(Business Metadata)。
?
???
技術元數據
是描述關于數據倉庫技術細節的數據，這些元數據應用于開發、管理和維護數據倉庫，它主要包含以下信息。
?
??? 1、數據倉庫結構的描述，包括倉庫模式、視圖、維、層次結構和導出數據的定義，以及數據集市的位置和內容；
??? 2、業務系統、數據倉庫和數據集市的體系結構和模式；
??? 3、匯總用的算法，包括度量和維定義算法，數據粒度、主題領域、聚合、匯總和預定義的查詢與報告；
??? 4、由操作環境到數據倉庫環境的映射，包括源數據和它們的內容、數據分割、數據提取、清理、轉換規則和數據刷新規則及安全（用戶授權和存取控制）。
?
???
業務元數據
從業務角度描述了數據倉庫中的數據，它提供了介于使用者和實際系統之間的語義層，使得不懂計算機技術的業務人員也能夠“讀懂”數據倉庫中的數據。業務元數據主要包括以下信息：使用者的業務術語所表達的數據模型、對象名和屬性名；訪問數據的原則和數據的來源；系統所提供的分析方法及公式和報表的信息。
?
??? 在信息打包過程中，需要用包圖表示維度和類別還有它們之間的傳遞和映射關系，實際上這個操作就是在原業務系統的基礎上創建了元數據。其中的維度、類別還有層次關系是屬于典型的技術型元數據，而業務系統中與之對應的術語則屬于業務元數據。比如日期、區域、產品、客戶年齡和客戶狀況等維度，實際銷售、計劃銷售、預測銷售、計劃偏差和預測偏差等指標皆屬于元數據。這些數據在分析中起到了極為重要的作用。
?
?
元數據的作用
?
??? 從元數據的類型和作用來看，元數據實際上是要解決何人在何時、何地為了什么原因及怎樣使用數據倉庫的問題。再具體化一點，元數據在數據倉庫管理員的眼中是數據倉庫中的包含了所有內容和過程的完整知識庫和文檔，而在最終用戶（即數據分析人員）眼中，元數據則是數據倉庫的信息地圖。
?
??? 數據分析員為了能有效地使用數據倉庫環境，往往需要元數據的幫助。尤其是在數據分析員進行信息分析處理時，他們首先需要去查看元數據。元數據還涉及到數據從操作型環境到數據倉庫環境中的映射。當數據從操作型環境進入數據倉庫環境時，數據要經歷一系列重大的轉變，包含了數據的轉化、過濾、匯總和結構改變等過程。數據倉庫的元數據要能夠及時跟蹤這些轉變，當數據分析員需要就數據的變化從數據倉庫環境追溯到操作型環境中時，就要利用元數據來追蹤這種轉變。另外，由于數據倉庫中的數據會存在很長一段時間，其間數據倉庫往往可能會改變數據的結構。隨著時間的流逝來跟蹤數據結構的變化，是元數據另一個常見的使用功能。
?
??? 元數據描述了數據的結構、內容、鏈和索引等項內容。在傳統的數據庫中，元數據是對數據庫中各個對象的描述，數據庫中的數據字典就是一種元數據。在關系數據庫中，這種描述就是對數據庫、表、列、觀點和其他對象的定義；但在數據倉庫中，元數據定義了數據倉庫中的許多對象——表、列、查詢、商業規則及數據倉庫內部的數據轉移。元數據是數據倉庫的重要構件，是數據倉庫的指示圖。元數據在數據源抽取、數據倉庫開發、商務分析、數據倉庫服務和數據求精與重構工程等過程都有重要的作用，元數據在整個數據倉庫開發和應用過程中的巨大影響。因此，設計一個描述能力強并且內容完善的元數據，對數據倉庫進行有效地開發和管理具有決定性意義。
?
?
?
*******************************************************
?
??? 在數據倉庫中，元數據的概念被強化了，在每個數據倉庫項目的總體架構圖中，幾乎都有”元數據治理”模塊來橫貫其他模塊。顯然，這表示它是一種基礎模塊，可以服務于諸如OLAP、ETL等其他模塊。但實際上，卻很少見一個完成了的數據倉庫項目中有獨立的元數據部分。大多項目，元數據都是分散在各種BI工具中。
??? 這些分散的元數據是不一致的，例如對一張表的結構定義，可能出現在ER設計工具中，當然也會在數據庫的數據字典中，還有可能在ETL工具的源、目標定義中。如此多的重復定義，當然會發生數據不一致現象，卻也正好為元數據治理工具留下廣闊空間，它們的作用就是集中治理這些分散的元數據，就像數據倉庫一樣，從不同的源采集數據，有ETL，也有清洗，甚至重新建模。
??? 元數據(metadata)這個詞現在到處泛濫。其實我對元數據充其量只能說有自己的理解而已，并不能確信這個理解是正確的。
?
??? 我認為，數據結構分為三個層次(UML可是四層哦)：
??? 實例層：直接描述特異化的數據場景；
??? 元數據層：描述實例的結構的一組數據；
??? 元數據的元數據層：描述元數據的結構的一組數據。
??? 元數據就是用來描述實例或者描述元數據的一種結構。
??? 元數據的特征有這樣幾個：第一是元數據一定不依賴業務反而被業務所依賴，相當業務的多變性，元數據是相對穩定的；第二是元數據具有廣泛的可復用性，而業務的可復用性極差；第三是元數據注重結構，而業務注重行為。
?
??? 在Xml中，元數據就是模式(Schema)，在數據庫中，元數據就是數據庫對象定義，包括表、視圖、關系約束、存貯過程、觸發器、函數、數據庫用戶、數據庫角色等等定義。在對象空間，元數據就是類型、接口、方法、方法參數、屬性的定義。在結構化程序空間，元數據就是函數及函數的參數。
?
??? 我之所以反復強調參數，是因為我們在定義一個接口或者方法的參數時總是非常隨便，但定義一個Xml文檔模式或者數據庫對象時總是小心翼翼的，很受束縛。這顯然有一定的不合理之處。仔細推敲，我的結論就是：第一，我們設計每個方法的參數時，特別是設計每個虛擬方法的參數時一定要小心一點，盡量不要濫用參數重構。第二，我們在設計一個Xml文檔結構或者數據庫結構的時候可別那么畏首畏尾的，就象平時寫程序時設計一個方法的參數那樣。這樣就平衡了。
?
??? 總結以往多年的數據庫設計，我歸納為兩個原則和兩個方法：
??? 降冗優先原則(降冗是數據庫設計時的首要要素)；
??? 平行引用原則(所有的關系都必須是單向的并且不能交叉)；
??? 依職責拆分方法(同一基數不同職責或者不同的維護方法或者不同的維護期必須拆分)；
??? 依基數合并方法(同一基數且職責相同必須合并)。
?
??? 忽然發現，其實這些原則和方法在整個元數據層都適用，不僅僅只針對數據庫設計。
?
*******************************************************
?