摘要：
數據庫是系統的根基，如果需求變更導致你要經常修改數據庫的字段，甚至需要修改表及表關系，相信多折騰幾次誰都受不了！因為數據庫結構的變化，不僅僅是數據庫本身的變更，實體類、數據操作層、邏輯層和表現層的代碼都需要改。更麻煩的是數據庫中如果已經存在大量的舊數據時，這些舊數據是不會“自動”適應新的數據庫結構的，你需要想辦法來“升級”這些舊數據。本文為你分享如何打造好系統的根基——做好數據庫設計！文章太長，分成上下兩篇了，此乃上篇。
大綱：
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）學生可以讀多門課程，每門課程都有相應的成績。
你覺得僅根據上述信息，是不是可以進行數據庫設計了？建議你先根據上述信息思考一下數據庫設計，完成后再繼續閱讀后文，這樣效果更好。
實際工作中因為工期壓力大，我們可能不會稍微停留一下思考一下這些需求，而是直接就是數據庫設計。這樣做有相當大的風險，很可能會導致數據庫設計不符合“三大范式”的要求的，導致一些問題，例如：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 數據庫設計小結
7.5 業務建模更上一層樓，打造更具彈性的數據庫設計
7.6 數據庫設計小結
本文是系列文章的其中一篇，要做軟件設計師一點都不簡單啊，請留意后續文章！
如果本文對你有幫助，麻煩點一下“推薦”啦，謝謝！
作者：張傳波
創新工場創業課堂（敏捷課程）講師
軟件研發管理資深顧問
CMMI首席專家
《火球——UML大戰需求分析》作者
軟件知識原創基地創辦人