摘要：
資料庫是系統的根基，如果需求變更導致你要經常修改資料庫的欄位，甚至需要修改表及表關係，相信多折騰幾次誰都受不了！因為資料庫結構的變化，不僅僅是資料庫本身的變更，實體類、資料操作層、邏輯層和表現層的程式碼都需要改。更麻煩的是資料庫中如果已經存在大量的舊資料時，這些舊資料是不會“自動”適應新的資料庫結構的，你需要想辦法來“升級”這些舊資料。本文為你分享如何打造好系統的根基——做好資料庫設計！文章太長，分成上下兩篇了，此乃下篇。
大綱：
1.什麼是優秀的設計？
2.優秀的設計能節省專案工作量
3.優秀設計從分析需求開始
4.軟體系統不是木桶型的
5.軟體設計的“大道理”
6.規劃系統骨架——架構設計
7.打造系統的底蘊——資料庫設計
8.細節決定成敗——詳細設計
9.使用者感覺好才是真的好——使用者體驗設計
10.持續提升設計水平
本文章是系列文章之一，如果你還沒有看過之前的文章，建議先看完前面的文章再看本篇，這樣效果更好。
7.打造系統的底蘊——資料庫設計
7.4 考勤系統的業務建模及資料庫設計
學生選課系統這個案例比較簡單，主要是幫助大家理解”業務概念模型驅動資料庫設計“。接下來我們繼續用”考勤系統“這個例子為你分享，我的主要目的有：
1）對考勤系統進行行為建模；
2）通過另外一個例子再次體會如何用類圖分析業務概念模型；
3）根據業務概念模型，同時考慮到我們的現實情況，我們要做一個“老土”的資料庫設計；
4）深挖業務概念模型，做一個“高階大氣”的資料庫設計。
本小節為你分享第1、2、3點。
這個考勤系統的需求請參考前面的文章，如果忘記了一定要重新看看噢！
你可以會發現，前面的文章沒有詳細描述請假（外出）的審批流程，下面我們通過一個圖來看看這個流程吧，這個圖就是業務行為建模的其中一個結果。
圖7.6 請假審批流程活動圖
瞭解這個流程後，我們將會對業務概念模型有更加清晰的認識，下面直接上兩個業務建模的圖：
圖7.7 考勤系統的業務概念建模1
圖7.8 考勤系統的業務概念建模2
上面兩個圖結合一起看才是完整的業務建模，因為一張圖太大可能會顯示不下，或者顯示出來不好看，所以才拆分成兩張圖。
根據上述業務建模，如何來設計資料庫呢？如果照搬學生考勤系統的做法，那麼一個類至少要對應一個資料表，這樣設計的話似乎有點麻煩，後續寫起程式碼來也可能挺麻煩的。我們要思考這個系統的主要需求是什麼？這個系統主要是圍繞請假（外出）的審批流程進行的，其實就是一個簡單的工作流，我們要解決提出申請以及多個層次的審批問題。現實專案中進度壓力是很大的，也會受制於各種限制條件，所以能解決需要當中主要矛盾的設計就是一個好設計，所以我有這樣的一個老土的設計，能滿足需求，實現起來也比較簡單。請看下面的兩個圖，節選了部分的資料庫設計。
圖7.9 考勤系統的資料庫設計1
圖7.10 考勤系統的資料庫設計2
這個設計相當老土，本來應該拆分為多張表的全部弄到一張表去：
1）當提出請假申請時，請假申請表就多了一條記錄，這條記錄審批相關的欄位全部都是空的；
2）當去到某個審批環節時，該申請記錄只需要更新相應的欄位就行了。
這個程式的程式碼寫起來也比較簡單，例如：表現層不需要針對不同的流程環節設計不同的介面，直接可以通過一個介面搞定，當然還要寫一堆 If Else 或 Switch Case。表現層的程式碼思路如下圖：
7.11 考勤系統的表現層程式碼思路
當員工提出請假申請時，他只能看到1這部分的內容，2、3、4部分隱藏；當部門經理審批申請時，1部分只讀，2部分可編輯，3、4部分隱藏，副總和總經理審批時也進行類似的處理。
資料庫設計不能單純僅僅從資料庫的角度來考慮，還需要整體平衡這個專案的工作量，一般來說能解決需求當中的主要矛盾，能讓整個開發工作量降下來，並且是專案團隊有能力做到的設計，這樣的資料庫設計及軟體設計才是好的設計。
考勤系統的業務建模及資料庫設計，也說明了這樣的最佳實踐：
1）業務結構建模和行為建模是很有必要的，業務建模這一步可以多深入一些，不要因為專案進度緊而壓縮你的時間，這裡的時間投入所帶來的回報是超值的；
2）業務建模讓我們對需求的理解更深，讓我們的資料庫設計及軟體設計”進可攻退可守“；
3）遇到進度壓力及各種限制條件時，你不一定非要照這個業務模型來設計你的資料庫和程式碼，你可以退一步，用一個”老土“的資料庫設計及程式設計來解決問題；
4）你也可以採取更加進取的設計策略，這點下一小節為你分享。
7.5 業務建模更上一層樓，打造更具彈性的資料庫設計
本小節為你分享前文提到的第 4 個目標：深挖業務概念模型，做一個“高階大氣”的資料庫設計。但這個目標實在太“偉大”了，這裡能僅為你分享開始的一部分，後續有機會我再發文章分享更多內容。
我們有更多的思考：如果請假（外出）審批流程改變了，例如增加了審批環節，怎麼辦？按照前面的“老土”設計的話就麻煩了，我們需要增加“請假申請表”的欄位，而表現層的程式碼也需要修改，需要更多的If Else。
當然我們可能還有一個更好的處理辦法，就是認為這是需求變更，對客戶說：no money no talk（沒有錢沒商量）。只要前期我們的業務分析足夠到位，將流程圖、業務概念圖等全部畫出來，並且跟客戶確認好了，客戶就不能賴賬了，增加審批環節，這明顯就是需求變更嘛，是需要工作量，需要付錢滴！但是我們為什麼不能將程式做得更有彈性呢？為什麼不能做一個“全活”的工作流呢？這樣我們的軟體將會更有競爭力，幫助我們賺到更多的錢。
前文的文章提到的工作流，分為三種層次：
1）死的工作流：就是程式碼寫死的（hard code），資料庫設計也是死的，流程或表單有任何變化，都可能需要改程式碼和資料庫設計。
2）半死不活的工作流：部分地方寫死，部分地方是靈活的，能適應部分需求變化。
3）全活的工作流：程式碼和資料庫設計等都是靈活的，能基本適應流程及表單的變化，不需要修改程式碼或資料庫設計，只要配置一下就可以搞定。
前面這個老土的設計，是屬於那種一種層次呢？
我都不好意思說了了，這是“死的工作流”，彈性最差的！流程稍微改變，就要到處修改，包括修改資料庫設計和程式碼。
下面我們嘗試一下做“活的工作流”，我們需要再進一步分析業務模型，找出流程的規律，針對規律來設計資料庫和軟體！
圖7.12 考勤系統業務概念模型的深入挖掘
上圖紅色虛線框框裡面的內容就是規律，而且其他部分可以看成是這種規律的一個“例項”。
這個圖揭示了這樣的規律：
1）從提出申請開始，後續的審批其實就是一個”審批鏈”；
2）“申請”對應一個“首次審批”，“首次審批”後續是“下一個審批”；
3）對應某一個“審批”來說，如果它不是“首次審批”，它對應一個“上一個審批”。
如果資料庫及程式能針對這樣的規律進行設計，那麼只要是符合這個規律的情況，系統都可以適應，這樣就不怕審批流程的變化了！
圖7.12 可能有點難度，如果沒有應用類圖分析業務的經驗，會更加難理解此圖，但這僅僅是挑戰的開始！當我們需要打造更具彈性的系統的時候，我們面臨兩大挑戰：
1）透視需求發現需求本質的能力，建立更深層次的業務模型；
2）根據第1）點的業務模型，設計出相應的資料庫設計及軟體設計。
這兩大挑戰都是難度很高的，圖 7.12 僅僅是業務模型進一步深挖的開始，打造“活的工作流”難度是很大的，將來有機會再分享更多文章。
7.6 資料庫設計小結
資料庫設計的好壞決定了系統的底蘊，無論是“老土”的設計還是“高階大氣”的設計，都是為專案的目標服務的。
一般來說我們應該達到以下基本要求：
1）意識上要重視資料庫設計，資料庫設計上的時間投資是超值的；
2）良好的業務建模（包括結構建模和行為建模）是良好資料庫設計的基礎，並且可以讓你在後續工作中“進可攻退可守”；
3）在業務概念模型的基礎上搭建資料庫，你可以採用類似學生選課系統的資料庫設計方法（業務實體類與資料表一一對應），也可以採用考勤系統的“老土”設計方法（合併業務實體類到一個表中）。
當條件成熟時，我們可以考慮進一步提升我們的業務深挖能力及彈性設計的能力，讓我們的軟體更好賣，讓我們可以賺取更高的薪金！
本文是系列文章的其中一篇，要做軟體設計師一點都不簡單啊，請留意後續文章！
如果本文對你有幫助，麻煩點一下“推薦”啦，謝謝！
作者：張傳波
創新工場創業課堂（敏捷課程）講師
軟體研發管理資深顧問
CMMI首席專家
《火球——UML大戰需求分析》作者
軟體知識原創基地創辦人