軟件設計是怎樣煉成的（6）——打造系統的底蘊（數據庫設計）（下篇）

摘要：

數據庫是系統的根基，若是需求變動致使你要常常修改數據庫的字段，甚至須要修改表及表關係，相信多折騰幾回誰都受不了！由於數據庫結構的變化，不只僅是數據庫自己的變動，實體類、數據操做層、邏輯層和表現層的代碼都須要改。更麻煩的是數據庫中若是已經存在大量的舊數據時，這些舊數據是不會「自動」適應新的數據庫結構的，你須要想辦法來「升級」這些舊數據。本文爲你分享如何打造好系統的根基——作好數據庫設計！文章太長，分紅上下兩篇了，此乃下篇。

 

大綱：

1.什麼是優秀的設計？
2.優秀的設計能節省項目工做量
3.優秀設計從分析需求開始
4.軟件系統不是木桶型的
5.軟件設計的「大道理」
6.規劃系統骨架——架構設計
7.打造系統的底蘊——數據庫設計
8.細節決定成敗——詳細設計
9.用戶感受好纔是真的好——用戶體驗設計
10.持續提高設計水平

 

本文章是系列文章之一，若是你尚未看過以前的文章，建議先看完前面的文章再看本篇，這樣效果更好。

 

 

7.打造系統的底蘊——數據庫設計

 

 

7.4 考勤系統的業務建模及數據庫設計

 

學生選課系統這個案例比較簡單，主要是幫助你們理解」業務概念模型驅動數據庫設計「。接下來咱們繼續用」考勤系統「這個例子爲你分享，個人主要目的有：

1）對考勤系統進行行爲建模；

2）經過另一個例子再次體會如何用類圖分析業務概念模型；

3）根據業務概念模型，同時考慮到咱們的現實狀況，咱們要作一個「老土」的數據庫設計；

4）深挖業務概念模型，作一個「高端大氣」的數據庫設計。

本小節爲你分享第一、二、3點。

 

這個考勤系統的需求請參考前面的文章，若是忘記了必定要從新看看噢！

你能夠會發現，前面的文章沒有詳細描述請假（外出）的審批流程，下面咱們經過一個圖來看看這個流程吧，這個圖就是業務行爲建模的其中一個結果。

 

圖7.6 請假審批流程活動圖

 

瞭解這個流程後，咱們將會對業務概念模型有更加清晰的認識，下面直接上兩個業務建模的圖：

 

圖7.7 考勤系統的業務概念建模1

 

圖7.8 考勤系統的業務概念建模2

 

上面兩個圖結合一塊兒看纔是完整的業務建模，由於一張圖太大可能會顯示不下，或者顯示出來很差看，因此才拆分紅兩張圖。

 

根據上述業務建模，如何來設計數據庫呢？若是照搬學生考勤系統的作法，那麼一個類至少要對應一個數據表，這樣設計的話彷佛有點麻煩，後續寫起代碼來也可能挺麻煩的。咱們要思考這個系統的主要需求是什麼？這個系統主要是圍繞請假（外出）的審批流程進行的，其實就是一個簡單的工做流，咱們要解決提出申請以及多個層次的審批問題。現實項目中進度壓力是很大的，也會受制於各類限制條件，因此能解決須要當中主要矛盾的設計就是一個好設計，因此我有這樣的一個老土的設計，能知足需求，實現起來也比較簡單。請看下面的兩個圖，節選了部分的數據庫設計。

 

圖7.9 考勤系統的數據庫設計1

 

圖7.10 考勤系統的數據庫設計2

 

這個設計至關老土，原本應該拆分爲多張表的所有弄到一張表去：

1）當提出請假申請時，請假申請表就多了一條記錄，這條記錄審批相關的字段所有都是空的；

2）當去到某個審批環節時，該申請記錄只須要更新相應的字段就好了。

 

這個程序的代碼寫起來也比較簡單，例如：表現層不須要針對不一樣的流程環節設計不一樣的界面，直接能夠經過一個界面搞定，固然還要寫一堆 If Else 或 Switch Case。表現層的代碼思路以下圖：

7.11 考勤系統的表現層代碼思路

 

當員工提出請假申請時，他只能看到1這部分的內容，二、三、4部分隱藏；當部門經理審批申請時，1部分只讀，2部分可編輯，三、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大戰需求分析》做者

軟件知識原創基地創辦人