本節書摘來自華章社群《dba修煉之道：資料庫管理者的第一本書》一書中的第1章，第1.5節資料庫管理、資料管理和系統管理，作者（美）craig s. mullins，更多章節内容可以通路雲栖社群“華章社群”公衆号檢視
1.5 資料庫管理、資料管理和系統管理
一些企業分别為資料的商業方面和技術方面定義了不同的角色。資料的商業方面與資料管理是保持一緻的，而更多技術方面都由資料庫管理掌控。并不是每一家企業都有資料管理的職位，而許多企業都将資料管理并入資料庫管理了。
許多企業都将資料管理并入了資料庫管理。
有時企業也将資料管理的技術方面進行分離，dba負責使用dbms，而其他角色（系統管理或系統程式設計）負責安裝并更新dbms。
1.5.1 資料管理
資料管理（data administration，da）把資料資源管理的商業方面和用于資料管理的技術分離開。da存在于一家企業，與資料的實際商業使用者聯系更加密切。da團隊負責了解商業詞彙并将其轉換成邏輯資料模型。回到前面所說的應用程式開發生命周期，資料管理者（da）會更多地參與需求收集、分析和設計階段。而dba參與設計、開發、測試和運作階段。
da和dba的另一個有差別因素是他們工作的重點。da負責以下問題：
确定并編寫商業使用者需要的資料目錄；
概念化産品并邏輯化資料模型，準确描述業務流程中的資料元素之間的關系；
産生企業資料模型，它要整合所有企業/業務流程使用的資料；
為企業設定資料政策；
确定資料擁有者和管理者；
為資料的控制和使用設定标準。
總之，da可看作企業的首席資料官。盡管da的職位和技術沒什麼特别的關系，但依我看來，da根本不是一個行政職位。實際上很糟糕，許多it企業聲稱它們把資料看作公司的财産，但當你審視它們的行為時便會發現此聲明的虛假。資料政策的責任常移交給一些技術專家，但他們不能專注于非技術性的、商業方面的資料管理。這些專家可以很好地保證資料的可用性、性能和可恢複性，但通常不能保證資料的品質，也不能設定公司的資料政策。
資料管理者可看作企業的首席資料官。
實際上，資料很少被視作真正的企業資産。看看每家企業都有的資産吧：資金、人力資源、裝置和原材料，每一種都是模式化的：賬戶一覽表、企業組織圖和層次報表、建築藍圖和辦公室布局及材料賬單，每一種都可跟蹤、都受保護。企業還請來專業會計師確定資産賬目沒有任何差池。我們能說大部分公司也這樣對待資料嗎？
一個成熟的da組織負責規劃并指導整個企業的資料使用需求。這個角色圍繞資料是如何記錄、共享和實施的展開工作。da的一個很大的責任是確定将資料元素在資料字典或資料存儲庫中予以準确地記錄。這是da和dba之間另外一個關鍵差別，da關注存儲庫，而dba關注實體資料庫和dbms。
此外，da進行中繼資料，這與處理資料的dba截然相反。中繼資料稱作“資料的資料”，更準确地說，中繼資料是對資料和業務所需要的資料的描述。資料管理負責業務和中繼資料政策。
這裡舉幾個中繼資料的例子，它可以包括資料元素的定義，某個資料元素的業務名稱，該元素的任何縮寫形式，該元素的資料類型及長度。沒有了中繼資料，資料就難以使用。比如，數字12是個資料，但是什麼類型的資料呢？換句話說，12意味着什麼？沒有中繼資料我們就無從知道。考慮下面幾個問題：
這是代表每年的第12個月嗎？
代表某個月的第12天？
會是年齡嗎？
鞋碼？
是一個iq？但願不是如此。
其他
但是也有更多技術方面的中繼資料，還以剛才的數字12為例：
12是大數字還是小數字？
它的域是什麼？（也就是說，12所可能表示的單個數值屬于什麼領域。）
資料類型是怎樣的？整型還是一個“有零刻度”的十進制數？
中繼資料為資料提供了得以了解的上下文，是以也就成為資料的資訊。在許多企業，中繼資料沒有系統地捕獲和編目，而大多存在于商業使用者的腦子裡。中繼資料在系統中捕獲的位置遍布檔案定義中的多個程式，以及準确性參差不齊的文檔中，或長時間不用的程式定義中。當然，其中一些位置在dbms的系統目錄中。
中繼資料為資料提供了得以了解的上下文，是以也就成為資料的資訊。
綜合的中繼資料政策使得企業知道所控制的資産資訊并衡量這些資産的價值。更多關于中繼資料的資訊請參考第22章。
da對公司資料資産的最大貢獻之一是建立資料模型。概念化資料模型能夠非常高水準地概括出資料需求。邏輯化資料模型為資料類型、長度、關系及基數提供了深入的細節。da采用标準化技術提供能夠準确描述企業的資料需求的完善資料模型。
很多dba會把資料管理當做單純的資料模型摒棄，因為有人要從終端使用者那裡獲得資料庫需求。但真正的da的作用遠不隻是單純的資料模型，而是一種面向商業管理的、為企業資料資産服務的準則。
為什麼在一本關于資料庫管理的書中花這麼多時間來讨論資料管理呢？為數不多的企業實作并雇傭了da。企業做得越大，越有可能設定da職位。然而，當一家企業裡da的角色沒有确定時，dba就要承擔資料策劃與模組化的職責了。而由于以下原因，dba通常不能夠承擔da所有的職責。
dba要履行許多其他技術方面的職責，這占用了他大部分的時間。
dba團隊的經理一般沒有行政職務使他決定政策。
dba一般不具備與商業使用者有效溝通并達成共識的技巧。
坦率地說，大部分的dba更願意處理技術問題及與技術專家打交道，而非碰觸業務問題及非技術人員。
當da和dba在企業共存時，這兩個團隊要非常密切地合作。當然，沒有必要要求他們有共同的經理，不過若有，可能更容易促進他們的合作。無論如何，重要的是兩個團隊之間要有一定程度的技術交流。因為da永遠不會像dba那樣了解實體資料庫，而dba也不會像da那樣了解資料的業務問題，每種工作都借鑒其他工作的知識就會更有效率。
總之，企業若真正關心資料的品質、完整性和再利用時，都會安排da的職位。
1.5.2 資料庫管理
資料庫管理是整本書的重點，本節就不花太多時間來定義它了。本書以後的部分會給出詳細的定義。本節将快速概括當da也存在時，dba團隊所起的作用。如圖1-3所示，dba管理資料而da管理中繼資料，現在就更深入了解一下吧。
dba的首要職責就是了解da建構的資料模型并能夠與應用程式開發者以及其他相關技術人員讨論該模型。邏輯資料模型是dba用來建立實體資料庫的映射。dba要把邏輯資料模型轉換成一種有效的實體資料庫設計。重要的是，dba結合dbms中用到的知識，根據邏輯模型建立一個有效且合适的實體資料庫設計。dba最終的實體模型對于da的依賴不會比da的概念和邏輯資料模型對dba的依賴更多。
dba是da團隊與技術人員及應用程式程式設計人員之間溝通的橋梁。當然，dba的工作大多是對基于資料庫的實體設計建立的資料庫以及通路這些資料庫的應用程式的持續支援。有關這些職責的概述會在1.6節展開。
dba是da團隊與技術人員以及應用程式程式設計人員之間溝通的橋梁。
1.5.3 系統管理
一些較大的企業會設定系統管理（sa）或系統程式設計的職位，有助于dbms的實施和運作。當sa和dba共存時，sa負責dbms的安裝和設定。他們一般不負責資料庫的設計和支援。而dba負責資料庫，sa負責dbms的安裝、修改和支援。如果你不清楚這種差別，請參閱附錄a中資料庫術語的明确定義。
此外，sa還負責it基礎設施的實施，配置dbms與其他授權系統軟體一起運作。sa可能需要和其他技術人員合作來配置事務處理器、消息隊列、軟體、網絡協定以及作業系統參數，使dbms有效地運作。為了開發資料庫，sa還要通過合理地設定dbms，向dbms供應商申請持續維護，以及更新dbms版本來確定it基礎設施正常運作。
為了開發資料庫，系統管理者還要通過合理地設定dbms，向dbms供應商申請持續維護，以及更新dbms版本來確定it基礎設施正常運作。
與da一樣，sa和dba之間也要交叉教育訓練技能。sa永遠都不會像dba那樣了解實體資料庫，但dba也不太可能像sa那樣懂得系統軟體的安裝以及它們之間深入的技術關系。了解一些其他的知識，每種工作都能更有效地發揮它的作用。
當沒有獨立的sa團隊或沒有專注于dbms的sa時，dba就要承擔系統管理和程式設計的責任了。圖1-4中對da、dba和sa的職責提供了簡短的描述。
