摘要：
資料庫是系統的根基，如果需求變更導致你要經常修改資料庫的欄位，甚至需要修改表及表關係，相信多折騰幾次誰都受不了！因為資料庫結構的變化，不僅僅是資料庫本身的變更，實體類、資料操作層、邏輯層和表現層的代碼都需要改。更麻煩的是資料庫中如果已經存在大量的舊資料時，這些舊資料是不會“自動”適應新的資料庫結構的，你需要想辦法來“升級”這些舊資料。本文為你分享如何打造好系統的根基——做好資料庫設計！文章太長，分成上下兩篇了，此乃上篇。
大綱：
1.什麼是優秀的設計？
2.優秀的設計能節省項目工作量
3.優秀設計從分析需求開始
4.軟體系統不是木桶型的
5.軟體設計的“大道理”
6.規劃系統骨架——架構設計
7.打造系統的底蘊——資料庫設計
8.細節決定成敗——詳細設計
9.使用者感覺好才是真的好——使用者體驗設計
10.持續提升設計水平
本文章是系列文章之一，如果你還沒有看過之前的文章，建議先看完前面的文章再看本篇，這樣效果更好。
7.打造系統的底蘊——資料庫設計
7.1 資料庫結構變更可大可小
資料庫欄位的微調，比方說增加一個欄位、修改一個欄位等等，是很常見的事情。當然這樣的事情經常發生的話，也是挺讓人厭煩的，所以我們可能會在資料庫中增加一些保留欄位。以前參考前輩的資料庫設計時，經常會發現一些“保留欄位”，於是自己也去模仿一下，後來發現好像沒有什麼用。比方說：當需要增加一個字元型的欄位時，我會去找一個字元型的保留欄位，將原來欄位的名字由“保留1”改為合適的名字；當需要增加一個數字型的欄位時，去找一個數字型的保留欄位，將原來欄位的名字由“保留X”改為“XXX”。這樣的做法，和增加一個欄位有什麼區別呢？還不如取消保留欄位，需要時再添加欄位就是了。資料庫欄位的變更還算是小變化，雖然會帶來資料操作層、業務層、表現層代碼的修改，也可能需要“升級”舊資料，但這些都算是“小動作”，還不算“很可怕”，“最可怕”的可能是資料表或表關係上的變化，例如：原來的表設計不合理，需要將一個表拆分為兩個或以上的表；需求發生變化，需要增加更多表格；原來的表關係不對需要修改等等，這些變化將會導致程式的大範圍修改。正因為資料庫的結構變化可大可小，可能遇到相關問題的時候我們會採取“將就”的策略，僅僅是對資料庫進行修修補補，不太敢從根本上改造資料庫，以致雪球越滾越大，最終有一天會探索資料庫結構實在無法適應需求了，但工期壓力又超級巨大，這時只能祝你好運了！
7.2 資料庫結構變更的源頭是什嗎？
資料庫變更的原因可能有：1）客戶的需求並沒有發生什麼變化，而是我們前期的需求分析不到位，或者是我們前期對資料庫設計不重視，導致資料庫設計不合理。2）客戶的業務發生變化，以致資料庫也需要調整設計。無論是哪種情況，其實都是業務概念驅動資料庫設計！請看前文出現過的一個圖：
圖7.1 業務概念驅動資料庫設計
此圖是前文說明“由底而上”的設計思路時的一個圖，現在我們再重新理解一下：1）“需求分析”活動有三種工作產物：業務概念圖、商務程序圖和用例/使用者故事。2）“業務概念圖”是“設計資料庫”活動的“輸入”，也就是“業務概念圖”是資料庫設計的重要依據。
那什麼是“業務概念”呢？下面我們通過執行個體來理解“業務概念性模型驅動資料庫設計”。
7.3 案例：學生選課系統——業務概念性模型驅動資料庫設計
案例：學生選課系統的業務建模
某學生選課系統部分需求如下：
1）學生基本資料：學號、姓名、年齡、所在學院、學院地址、學院聯絡電話。
2）課程基本資料：名稱、學分、類別（必修、限選、任選）。
3）學生可以讀多門課程，每門課程都有相應的成績。
你覺得僅根據上述資訊，是不是可以進行資料庫設計了？建議你先根據上述資訊思考一下資料庫設計，完成後再繼續閱讀後文，這樣效果更好。
實際工作中因為工期壓力大，我們可能不會稍微停留一下思考一下這些需求，而是直接就是資料庫設計。這樣做有相當大的風險，很可能會導致資料庫設計不符合“三大範式”的要求的，導致一些問題，例如：1）該拆分的表沒有拆分，表關係不合適；2）欄位設計不合適；3）資料冗餘，容易出現不一致等等。如果我們能先進行業務建模，可以協助我們避免這些問題。
是對上述需求的業務概念建模分析：
圖7.2 選課系統的業務概念建模
我通常用UML的類圖來整理業務概念性模型，簡介一下這個圖的基本文法：1）圖中的一個個矩形就是類，這個圖有四個類：學生、學院、課程、成績；2）學生與學院之間，學生與課程之間有實線相連，表示它們”有關係“；3）學生與學院之間的關係是 ”* 對 1“，表示多個學生對應1個學院；4）學生與課程之間的關係是 ”* 對 *“，表示多個學生對應多個課程；5）成績這個類有一條虛線連到學生與課程之間的實線，這個成績類叫關聯類別，這可能是比較難以理解的，它表示的是學生與課程之間的關係的約束，這個”成績“你可以理解為：每個學生在每個課程中的成績。
補充說明一下，嚴格來說業務建模有兩種：業務結構建模和業務行為建模。上述案例其實做的是“業務結構建模”，主要是對資料結構進行分析；“業務行為建模”主要是對流程、過程等進行分析，圖7.1中“需求分析”的其中一個工作產品是“商務程序圖”，這個“商務程序圖”就是行為建模的產品。後續文章會為大家分享更多行為建模的內容。
根據這個業務概念建模，我們可以進行以下的資料庫設計，我們將通過三個圖來說明。
圖7.3 選課系統的資料庫設計1右上方是業務建模的小圖，方便大家對照來看，圖7.3 展示了”學生類“與”學院類“對應的資料庫設計。
圖7.4 選課系統的資料庫設計2此圖展示了”課程類“和”成績類“所對應的資料庫設計，請重點看”成績類“的資料庫設計。
是上述兩個圖的匯總：
圖7.5 選課系統的資料庫設計3
這個資料庫設計一共有4個資料表，請對照圖7.2來思考一下，業務概念建模是如何驅動資料庫設計的。如果忽略了”業務概念建模“這一步，我們的資料庫設計可能會：1）沒有能拆分出學生表、學院表、課程表；2）沒有能拆分及設計出合適的成績表。
如果你曾經用過E-R圖（實體關聯圖），或者用過 Power Design 軟體設計過資料庫，你會發現上述文章的內容也就是那麼一回事！用類圖分析業務概念，確實與E-R圖很類似，道理也是共通的，但是還是有一些區別的：1）E-R 圖一般是直接面向資料庫設計的，實體之間的關係一般就是1對1、1對多，而多對多的關係通過兩個1對多來間接實現；2）類圖也能表示上述關係，但類圖可以表達更豐富的內容，比如：繼承（泛化）、包含（彙總、組合）、依賴、關聯類別等等。也就是說用類圖分析業務概念性模型，能達到更廣和更深的效果，當然這是我個人的體會，僅供參考。
如果你一直用 E-R 圖用得好好，也沒有必要非要轉成類圖來分析。無論是類圖、 E-R 圖，還是其他的什麼圖或工具，我們的目的都是為了更好的理解需求，梳理業務和整理出合適的業務概念性模型，為資料庫設計打好基礎。
本想一篇文章寫完，但不知不覺越寫越長，又捨不得刪減內容，所以分成上下兩篇了，下篇為你分享：7.4 考勤系統的業務建模及資料庫設計
7.5 業務建模更上一層樓，打造更具彈性的資料庫設計
7.6 資料庫設計小結
本文是系列文章的其中一篇，要做軟體設計師一點都不簡單啊，請留意後續文章！
活動資訊：
“軟體設計是怎樣煉成的”這個系列的文章當中出現了很多UML圖，而且文章一直很強調需求驅動設計，如果你對這些話題感興趣，歡迎你考慮我即將在深圳舉辦的一個活動：敏捷遇上UML詳情請猛點這個連結：http://blog.csdn.net/fireball1975/article/details/19550771
本活動已經在CSDN社區活動發布，詳見：http://huiyi.csdn.net/module/meeting/meeting/info/706/community
作者：張傳波
創新工場創業課堂（敏捷課程）講師
軟體研發管理資深顧問
CMMI首席專家
《火球——UML大戰需求分析》作者
www.umlonline.org創辦人
