引言：一直在從事資料庫開發和設計工作，也看了一些書籍，算是略有心得。很久之前就想針對關聯式資料庫設計進行整理、總結，但因為種種原因遲遲沒有動手，主要還是惰性使然。今天也算是痛下決心開始這項卓絕又令我興奮的工作。這將是一個系列的文章，我將以講座式的口吻展開討論（個人偷懶，這裡的總結直接拿去公司培訓新人用）。
系列的第一講我們先來回答下面幾個問題
資料庫是大樓的根基
大多數程式設計師都很急切，在瞭解基本需求之後希望很快的進入到編碼階段（可能只有產出程式碼才能反映工作量），對於資料庫設計思考得比較少。
這給系統留下了許多隱患。許多軟體系統的問題，如：輸出錯誤的資料，效能差或後期維護繁雜等，都與前期資料庫設計有著密切的關係。到了這個時候再想修改資料庫設計或進行優化等同於推翻重來。
我經常把軟體開發比作汽車製造。汽車製造會經過圖紙設計，模型製作，樣車製造，小批量試生產，最後是批量生產等步驟。整個過程環環相扣，後一過程是建立在前一過程正確的前提基礎之上的。如果在圖紙設計階段發現了一個紕漏，我們可以重新進行圖紙設計，如果到了樣車製造階段發現這個錯誤，那麼我們就要把從圖紙設計到樣車製造的階段重來，越到後面發現設計上的問題，所付出的代價越大，修改的難度也越大。
資料庫是整個應用的根基，沒有堅實的根基，整個應用也就岌岌可危了。
強大的資料庫面對不良設計也無能為力
現代資料庫管理系統（DBMS）提供了方便的圖形化介面工具，通過這些工具可以很方便的建立表、定義列，但我們設計出的結構好嗎？
關聯式資料庫有許多非常好的特性，但設計不當會使這些特性部分或完全的喪失。
我們來看看以下幾個資料庫不良設計造成的場景：
1. 資料一致性的喪失
一個訂單管理系統，維護著客戶和客戶下的訂單資訊。使用該系統的使用者在接到客戶修改收貨地址的電話後，在系統的客戶資訊頁面把該客戶的收貨地址進行了修改，但原先該客戶的訂單還是送錯了地址。
2. 資料完整性的喪失
公司戰略轉移，準備撤出某地區。系統操作人員順手把該地區的配置資訊在系統中進行刪除，系統提示刪除成功。隨後問題就來了，客服人員發現該地區的歷史訂單頁面一開啟就出錯。
3. 效能的喪失
一個庫存管理系統，倉庫管理員使用該系統記錄每一筆進出貨情況，並能檢視當前各貨物的庫存情況。在系統執行幾個月後，倉庫管理員發現開啟當前庫存頁面變得非常慢，而且整個趨勢是越來越慢。
上面這些場景都是由於資料庫設計不當造成的，根源包括：設計時引入了冗餘欄位，沒有設計合理的約束，對效能沒有進行充足設計等，上面的例子也只是滄海一粟。
資料庫平臺無關性
我在這個系列部落格裡討論的資料庫設計不針對任何一個關聯式資料庫產品。無論你使用的是Oracle，SQL Server，Sybase，亦或是開源資料庫如：MySQL，SQLite等，都可以用來實踐我們這裡討論的設計方法和設計理念，設計是這個系列博文的核心和靈魂。
注：在文中我會選用一個資料庫產品來進行演示，大家可以選用自己熟悉的資料庫產品來實驗。本文最後會給出一些免費資料庫產品的連結，大家可以下載學習。
一起學習共同進步
無論你是資料庫設計師，應用架構師，軟體工程師，資料庫管理員（DBA），軟體專案經理，軟體測試工程師等專案組成員，都能從該系列博文中有所收穫。大家一起討論，共同進步。
內容涉及領域
我對這一系列博文現在的設想是涉及資料庫設計的整個過程。從需求分析開始，到資料庫建模（概念資料建模），進行正規化化，直至轉化為SQL語句。
在我們一頭扎進資料庫設計之前，我們先了解一下除了關係型資料庫之外的資料儲存方式。
平面檔案（Flat File）
包括以.txt和.ini結尾的檔案。
eg: 一個.ini檔案的內容：
————————————————————
[WebSites]
MyBlog=http://www.cnblogs.com/DBFocus
[Directorys]
Image=E:DBFocus ProjectImg
Text=E:DBFocus ProjectDocuments
Data=E:DBFocus ProjectDB
————————————————————
優點：
檔案的儲存形式非常簡單，普通的編輯器都能對其進行開啟、修改
缺點：
無法支援複雜的查詢
沒有任何驗證功能
對平面檔案中間的內容進行插入、刪除操作其實是重新生成了一個新檔案
適用場景：
存放小量，修改不頻繁的資料，如應用配置資訊
Windows登錄檔
錯誤的修改Windows登錄檔會引起系統的紊亂，故不建議把很多資料存放在登錄檔中。
Windows登錄檔為樹形結構，存放著一些系統配置資訊和應用配置資訊。
通過把不同的配置存放在登錄檔的不同分支上，使得應用程式公共配置資訊與使用者個人配置資訊分離。
eg：某文件版本管理系統，能通過配置與本主機上安裝的檔案比較器建立關聯進行文件比較。這是一個公共配置資訊，檔案比較器路徑可以存放在登錄檔的HKEY_LOCAL_MACHINESOFTWARE分支下。
同時該文件版本管理系統能記錄使用者最近開啟的10個文件路徑。這是使用者個人配置資訊，對於不同的Windows使用者最近開啟的10個文件可以不同，這些配置資訊可存放在登錄檔的HKEY_CURRENT_USERSoftware分支下。
Excel表單（Spreadsheets）
優點：
Excel 非常普及，使用者對於Spreadsheet的表現形式非常熟悉
可以進行簡單統計，方便出各種圖表
缺點：
不適用於許多Spreadsheet之間關係複雜的情況
無法應對複雜查詢
資料驗證功能弱
適用場景：
資料量不是非常大的辦公自動化環境
XML
XML是一種半結構化的資料。相比於超文字標記語言（HTML），其標籤是可以自行定義的，即可擴充套件的。
eg：一個XML檔案內容
—————————————————–
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
<?xml version=”1.0” encoding=”UTF-8” ?> <ClassSchedule> <Class Name=“Psychology” Room=”Field 3”> <Instructor>Richard Storm</Instructor> <Students> <Student> <FirstName>Ben</FirstName> <LastName>Breaker</LastName> </Student> <Student> <FirstName>Carol</FirstName> <LastName>Enflame</LastName> <NickName>Candy</NickName> </Student> </Students> </Class> </ClassSchedule> |
—————————————————–
XML檔案有幾個特點。
首先，XML標籤要求嚴格對應，且不能出現交錯的現象。
其次，XML檔案必須有一個根節點，該節點包含所有其他元素。
第三，同級別的不同節點內不必包含相同的元素，如上例中第二個學生Carol有一個特別的節點NickName。這個特性使得在某些場景中XML比關聯式資料庫更能應對變化。
優點：
自然的層次型結構
文字內容通過標籤是自解釋的
通過XSD（XML Schema語言）可以驗證XML的結構
有許多輔助型技術如：XPath, XQuery, XSL, XSLT等
一些商業資料庫（如Oracle，SQL Server）已支援XML資料的儲存與操作
缺點：
資料的冗餘資訊較多
無法支援複雜的查詢
驗證功能有限
對XML中間的內容進行插入、刪除操作其實是重新生成一個新檔案
適用場景：
適合存放資料量不大，具有層次型結構的資料，如樹形配置資訊
NoSQL資料庫
非關係型資料庫我接觸的不是很多，除了給出一些產品名稱之外不做很多展開。園子裡已有一些文章，本文最後也給出了連結供大家學習、研究。
1. Key-Value資料庫
Redis, Tokyo Cabinet, Flare
2. 面向文件的資料庫
MongoDB, CouchDB
3. 面向分散式計算的資料庫
Cassandra, Voldemort
這幾年NoSQL非常熱。我認為NoSQL並不是“銀彈”，在某些SNS應用場景中NoSQL顯示了其優越性，但在如金融行業等對資料的一致性、完整性、可用性、事務性高要求的場景下，現在的NoSQL就未必適用。我們應充分分析應用的需求，非常謹慎地選擇技術和產品。
主要內容回顧
1.資料庫設計對於軟體專案成功的關鍵作用
2.本課程與資料庫產品無關，核心是設計的理念和方法
3.各種資料儲存所適用的場景
參考資料
1. Oracle Database 10g Express Edition
2. SQL Server 2008 R2 Express – Overview
4. NoSQL資料庫筆談