最近在讀一本《資料庫系統 設計、實作與管理》的書，其中的資料庫設計部分寫的挺好的，另外在本書中也講到了資料庫生命周期的概念，我覺得有所收益，特寫下此博文！
在軟體開發中，我們經常會提到軟體系統開發的生命周期，大緻分為：計劃、分析、設計、實作、運維幾個階段，整體流程和動作如下圖所示：
而針對資料庫模組化和資料庫應用開發來說，也有其自己的“資料庫生命周期”，database life cycle，簡稱dblc。dblc大緻上分為6個階段：資料庫初始研究，資料庫設計，實作和裝載，測試和評價，運作，維護和演化。其對于的生命周期圖為：
也許作為一個資料庫模型設計人員或者開發人員來說，隻關心參與3個階段，但是其實每個階段都應該參與其中，畢竟這6個階段是不斷疊代的過程。
下面我們來分别說明一下這6個階段。
簡單的說就是前期的需求調研階段，隻不過軟體開發中的需求調研是站在軟體的角度，而資料庫設計人員則應該站在資料庫的角度分析使用者的需求，主要做到以下目标：
分析公司的狀況。
定義問題和限制。
定義目标。
定義範圍和邊界。
這是資料庫生命周期中最重要的環節，也是最燒腦細胞的環節。這個環節工作的好壞直接關系到最終軟體是否滿足使用者和系統的需求。資料庫設計又進一步劃分為幾個階段：概念設計、dbms的選擇、邏輯設計、實體設計。
而對概念模型的驗證，一方面需要檢查使用者需求中的對象和屬性是否都在概念模型中，其次，檢查crud在模型上的操作是否會造成異常，另外也需要從報表的角度考慮，是否能夠寫出對應的報表的查詢，查詢效率是否可接受。在整個模型驗證過程中，可能把一些屬性獨立出來成新的實體，也可能把關系從一對多改為多對多，也可能出于性能上的考慮，對一些表進行反範式化處理。對概念模型的驗證一般以子產品為機關進行驗證，而且概念模型的定義是獨立于硬體和軟體的，保證了模型的簡潔。
目前市面上的dbms可選擇性并不是很大，企業級dbms就是oracle，ibm db2和sql server，這些dbms功能強大完備，但是價格昂貴，而免費開源的有mysql，postgresql，這都是很流行的開源資料庫，而如果系統小而簡單的話，還可以考慮sqlite,access等單機資料庫。這前面說的都是rdbms，也就是關系型的資料庫，還有其他對象資料庫，文檔資料庫，層次資料庫如果需要也可進行選擇，尤其是随着網際網路的興起，現在nosql非常火，也增加了dbms的選擇範圍。
不管怎麼說，dbms的選擇主要還是考慮以下幾個方面：
開銷/預算。這裡除了軟體和硬體本身的采購價格，還需要包括學習成本，運維開銷，轉換成本等。
dbms的特征和工具。如關注系統的可用性，安全性，擴充性等。
基礎模型。是關系型的還是對象型的，或者文檔型。
便利性。dbms可以便利的在不同平台，系統，語言之間進行移植。
硬體要求。
邏輯模型就是将概念模型轉換為特定dbms支援的模型，是以邏輯模型是與軟體相關的。邏輯模型中的表、外鍵是可以通過概念模型的實體、關系轉換而來，但是對于視圖、存儲過程、函數、使用者等，都需要在邏輯模型中設計。
實體模型是與具體的實體硬體相關，可以通過邏輯模型轉換而來。在實體設計中，需要考慮具體的資料存儲，資料分布等，在實體模型中要求設計師充分了解軟體和硬體環境，充分發揮軟體和硬體的特性。
常用的資料庫模組化工具如powerdesigner或者erwin都可以将實體模型生成對應的sql語句，然後我們在dbms中運作sql，便可實作我們設計的資料庫模型。在實作了資料庫模型後，我們還需要進一步研究其性能，安全，備份與恢複，以及完整性和公司标準。這些一般都是由dbms提供的工具支援的。
資料一旦裝載到資料庫後，dba就要對資料庫的性能，完整性，并發通路和安全限制進行測試和優化。這個測試和評價階段是與軟體開發并行進行的。如果測試和評價結果不滿足要求，就需要對系統和模型進行調整。其中包括：
調整dbms的配置參數，修改實體設計（比如索引和分區的修改），修改邏輯設計（比如增加備援字段），更新或者更換dbms的軟硬體平台。
資料庫通過了評測階段，就認為是可運作的了。在實際生産環境的運作過程中，産生了真實的資料，一些在測試階段無法預見的問題可能會被遇到，比如查詢緩慢，資料不一緻，死鎖等問題都可能遇到。棘手的問題需要緊急更新檔，而一些小bug則可能在下一個版本中修正，而這些在運作中對資料庫的更新檔和修改，就是一個維護和演化的過程。
資料庫的日常維護工作包括備份與恢複，使用者權限配置設定，系統監控，系統定期安全審計等。對于系統更新檔和新版本開發，則是對模型的演化，需要在更新生産系統資料庫時對資料庫模型進行同步的更新，這便進入了資料庫生命周期的疊代過程。