1. 人員

連載之11原創：胖子劉（轉載請註明作者和出處，謝謝）1.       人員在需求調研和分析階段、通常需要製作使用案例圖，記錄當前應用系統Actor及用例。假設系統Actor包括公司員工、簽約人、供應商聯絡員、客戶聯絡員4種類型，那麼有些系統可能就會設計成4個表來分別儲存。如果某個人所屬的公司既是本公司的供應商又是客戶，他則既是供應商聯絡員、又是客戶連鎖員，那麼這個人的資訊就要在“供應商聯絡員”、“客戶聯絡員”表裡各存一條記錄，這就造成了資料冗餘。為了避免這種情況，我們採用“主擴充模式”進行設計，首先抽取4種Actor的共同屬性建立“人員”表，然後建立其餘4個表格儲存體主表的擴充屬性。在這一節，我們重點講述主表、即“人員”表的設計細節，其他表的設計放到後面再說。人員表的主鍵為什麼是“當事人ID”，而不是“人員ID”呢？這個問題留到第3節講述，此處只要把它看作是人員表的主鍵就可以了。在設計人員表以及其他實體表的時候，需要注意實體屬性的類型。一般可以分成三類：（1）自然屬性，與該實體緊密相關，除非錄入錯誤，否則不存在修改的情況；（2）社會屬性，與實體鬆散相關，會隨著實際情況的變化而變化；（3）系統屬性，與實體基本無關，屬於系統控制層次的屬性。對照上面的“人員表”我們可以看到，對於確定的一個人，排除錄入錯誤的情況，他的“出生日期”、“社會安全號碼”是不會發生變化的，這就是一個人的自然屬性；除此以外的其他屬性都是社會屬性，都有可能會發生變化。大家都知道目前國內改名的現象比較多，儘管公安機關的限制很嚴，依然擋不住改名的熱潮。至於身高、體重、職務、婚姻狀況，就更不用說了，就像美女的臉、說變就變。護照一般都有有效期間，過了有效期間需要重新領新的護照，號碼自然會發生變化。為什麼“性別”也會變化呢？其實“性別”的取值範圍是有國家標準的，取值分別是“男性”、“女性”、“未知的性別”、“未確定的性別”，感興趣的朋友可以在網上搜搜。一般在錄入人員資訊的時候，如果不知道該人是男是女，預設應當選“未知的性別”，等以後知道了具體性別再作修正；此外男變女、女變男也不是什麼新鮮事了，所以人的“性別”也是社會屬性。說了這麼多，大家可以發現，一般的“社會屬性”的名稱前都有一個“現”字，用來提示大家這個屬性是社會屬性，是很可能會發生變化的，目前資料庫裡儲存的只是最後一次修改的結果。有些系統（例如我舉的這個例子）不關心這些屬性的變化過程，只要有一個最新值就可以了。有些系統則必須跟蹤屬性變化的全過程，例如“幹部考評系統”，可能就要記錄某人“職務”變化的全部曆史；“海關出入境登記系統”，就要記錄一個人“護照”號碼所有的變化；“康體中心”可能會記錄其會員在一段時間內每天的“體重”變化值，等等。這樣，就需要採用“主從模式”或者“名值模式”來進行相應設計，而不是簡簡單單的建一個表完事了。但是無論是什麼系統，在記載人員的“自然屬性”的時候，由於其不會產生變化曆史，所以只要作為“人員”表的欄位就可以了。“系統屬性”，屬於系統控制手段的範疇。例如有些系統對人員管理較嚴格、不允許隨便增刪個人記錄，就在人員表中設定一個屬性——“狀態”，取值範圍是“新增/有效/無效”。辦事員錄入一個人員資訊後，“狀態”屬性被設定為“新增”，由管理員審核通過後屬性改為“有效”，只有狀態為“有效”的人員才能進行相應的業務處理；當需要刪除人員資訊時，將“狀態”屬性改為“無效”。這就是實體的系統屬性。對於一個屬性而言，它到底是“自然屬性”、還是“社會屬性”，需要我們在作需求分析階段認真分析業務、與一線業務人員充分溝通之後予以確定。而“系統屬性”一般是在系統設計階段、結合商務邏輯確定。