人性化公共報修系統的數據庫設計

史書明 （常州工學院計算機信息與工程學院，江蘇 常州213002）

隨著計算機應用的深入推廣，企事業單位中使用 “公共報修系統”來改善后勤服務質量和效率的也越來越多。但是目前主流的公共報修系統在實際使用時，普遍暴露出通用性有余、針對性不強、功能有限等不足。在此，筆者對公共報修業務進行了細致的分析，提出了一套人性化的設計方案。

1 現行 “公共報修系統”的主要不足

目前多數 “公共報修系統”存在以下不足：①平臺開放，缺少 “用戶登錄”環節。看似便捷，卻不能阻止惡意的信息發布，而且報修時每次都要填寫報修人信息 （姓名、聯系電話等），如果經常報修，反而帶來麻煩，而且還容易出現由輸入錯誤帶來的意外。②報修一旦完成，不能修改。如果當時報修信息填寫有誤，不能更正，也不能撤單 （這也是缺少 “用戶登錄”環節帶來的弊病）。③報修信息中的“地點”信息，由報修人自己填寫，無法規范，而且容易出錯，也不便于日后統計。④缺少領導敦促功能，而實際工作中卻是需要的。⑤缺少評價、投訴功能，無法為維修員的工作實績提供有效的評估依據。⑥統計功能不豐富，不能為后勤服務工作的總結、規劃、發展提供確鑿、科學的分析手段。⑦缺少歷史數據轉存清理功能。歷史數據不能簡單刪除 （畢竟還是會有可能需要調閱很久以前的信息），但日積月累，會嚴重影響系統的運行效率。

2 報修業務分析

2．1 前臺業務分析

目前主流的公共報修系統，前臺通常只涉及2個角色，即 “報修方”和 “維修方”，缺乏 “管理方”，而且 “報修方”沒有 “登錄”的環節，因此功能和業務流都很單一。筆者在設計中引入了 “管理方”，報修方也增加了 “登錄”環節，使得系統更貼合了實際的業務需求，從而業務流也發生了明顯的變化，如圖1所示。

在圖1中，所有帶實線下劃線的操作都是由 “維修方”發起的，包括受理、完工、申請延期、申請撤銷、評價回復、投訴回復；所有帶虛線下劃線的操作都是由 “管理方”發起的，包括同意延期、拒絕延期、敦促、投訴回復；所有帶實線框的操作都是由系統自動發起的，包括過期、延期結束；其他操作都是由 “報修方”發起的，包括報修、主動撤銷、同意撤銷、拒絕撤銷、評價、修改評價、投訴、撤銷投訴。

按照筆者的設計，“報修方”、“維修方”和 “管理方”發起的所有操作中，除 “敦促”外，都允許修改，但是，為了體現嚴肅性，修改之前的歷史痕跡都應該得到保留。在圖1中可以看到，一次報修業務的最終狀態有4種：已完結、已撤銷、已過期、被投訴。通常，報修業務都應該終止在 “以完結”狀態。最順利的一次報修業務一般是這樣的：首先，報修人員登錄后進行 “報修”操作，業務進入初始狀態，即 “已報修，等待受理”。然后，相關的維修人員登錄后會收到這個報修，并予以受理，業務狀態轉入 “處理中”。接下來，在維修完成后，維修人員進行 “完工”操作，業務狀態轉入 “已處理，等待評價”（因為日后要通過對維修人員獲得的所有 “評價”進行統計分析，以評判該維修人的工作實績，因此 “評價”環節是必須的）。最后，報修人員進行評價，報修業務進入結束狀態，即 “已完結”。此后，維修方可以就報修方的評價進行評價回復，但不會改變業務的狀態。

報修業務也可以終止在 “已撤銷”的狀態。如報修人員發現自己誤報了，則可以 “主動撤銷”。維修人員受理報修后，發現此次報修因特殊原因不能處理 （如因外網光纜受損，導致不能訪問外網），則可以申請原報修人員撤銷報修，原報修人員批準后，業務終止于 “已撤銷”狀態。

報修業務若在規定時間內 （后臺可以指定一個天數）未能被受理或是沒有處理完畢的，則由系統自動終止，并標示為 “已過期”狀態。對過期的報修，報修方有權發起投訴，從而使業務終止于 “被投訴”狀態。若是未及時受理引起的過期，由于尚未確定維修人員，因此該投訴的回復由相關部門的管理人員負責；若是受理后的過期，即維修人員未能在規定時間內處理完畢，則該投訴的回復由受理的維修人員負責。投訴回復不影響業務狀態，報修方也可以撤銷已經發起的投訴，從而使業務狀態從 “被投訴”回復到 “已過期”狀態。

管理人員除了在報修業務的過程中能夠進行一些干預操作外，在實際工作中，還有一些特權，主要是對信息的查看、統計和分析。如查看某個員工上半年的報修次數；統計某幾個維修人員上一年度的用戶評分情況；比較同一時間段內不同樓宇中相同報修小類的發生次數等等。

圖1 前臺業務狀態圖

2．2 后臺業務分析

后臺的主要業務通常涉及人員管理、公共信息管理、系統維護等等。人員管理主要包括賬號管理、角色 （權限）管理；公共信息管理主要包括報修位置 （故障發生的具體位置）管理、報修類別管理、時間段管理 （主要針對數據轉儲和統計）；系統維護主要包括數據庫的備份、還原、系統初始化、歷史數據的轉存和調用等等。其中轉儲歷史數據的直接目的就是將過期數據從主數據中剔除，以提高系統的運行效力，但考慮到日后可能會需要調閱這些歷史數據，因此采取轉儲的形式。轉儲后的歷史數據需要被“調閱”后才能看到，但 “調閱歷史數據”的功能不會向普通用戶開放，發生的頻率很低，所以由此帶來的不便也很有限。

2．3 特色業務分析

1）“用戶地址簿” 因為大多數用戶在報修時的地址信息是相對固定的，所以 “用戶地址簿”的使用可以幫助用戶方便準確地填寫地址信息。“用戶地址簿”的產生途徑有2種，一種是用戶自定義，另一種是系統自動生成。系統自動生成又可以按2種方式，一種是取最近使用過的若干個地址，按時間的由近到遠排序；另一種是取最近一階段使用頻率最高的若干個地址，按使用頻率由高到低排序。

2）“時間段定義” 轉儲歷史數據的首要目的是給現行系統減負，其次是為了日后的調閱。“調閱”通常會指明一個 “時間段”，如果沒有對時間段進行具體的說明和定義，那么，在需要調閱某個歷史時間段的數據時，用戶在起止日期的確定上往往會很迷茫。如2011年的某天，校領導要求調閱2005～2006學年第一學期的有關數據。這個時間段到底應該從哪天算起又是到哪天結束，恐怕沒人能立即提供正確的答案。然而，如果事先現進行了 “時間段定義”，就可以方便地從 “時間段列表”中選擇，而不必擔心出錯。

3 數據庫設計

3．1 數據庫的總體設計

數據庫中的數據表被分為2大類：一類是與報修業務直接相關的表，這里稱為 “前臺類表”；另一類是與報修業務不直接相關的表，這些表主要面向后臺系統管理員，這里稱為 “后臺類表”。

1）前臺類表的設計 前臺類表的設計以前臺業務的分析為基礎，因此涉及以下一些表：①前臺用戶要求登錄后方可進行操作，因此需要有一個用戶表 （users）。另外需要一個用戶所在部門的信息表（departments），以方便用戶管理。②前臺的用戶有不同角色，不同角色的用戶會被分配不同的操作權限，因此需要有一個用戶角色表 （user＿character）和一個操作類型表 （operations）。③用戶報修需要提供位置信息。這里將位置信息分成由大到小的3級——區域、樓宇、房間 （房間也兼有 “場所的含義”，如3樓走廊）。因此需要有區域信息表 （areas）、樓宇信息表 （buildings）和房間信息表（rooms）——這3個表之間是逐級關聯的。④用戶的報修項目還需要指定類別。這里將類別信息分成由大到小的3級——維修部 （如總務處）、工種 （如強電）、小類 （如照明），其中，“工種”也可理解為是 “大類”。因此需要有維修部信息表 （這個表可以借用前面的部門信息表）、大類信息表 （big＿class）和小類信息表 （small＿class），顯然，這3個表之間也是逐級關聯的。⑤前臺用戶的各種操作都需要被記錄下來，形成一個流水賬，因此需要有記錄表 （records）。這個記錄表是信息量最大的表，日積月累后會影響系統運行效率，所以需要被定期轉儲和清理。為了方便日后的調閱，轉儲的方式可以是建立一個結構相同的轉儲表，然后將需要轉儲的歷史數據導入其中。⑥為了實現 “用戶地址簿”，需要一個用戶地址簿表 （user＿addressbook）。

2）后臺類表的設計 后臺類表的設計，以后臺業務的分析為基礎，因此涉及以下一些表：①前臺用戶的個人信息可以由前臺用戶自行維護，但是用戶的角色、權限則是由后臺管理員維護的。不同角色的有著不同的權限，即可以進行不同的操作，需要有一個用戶權限表 （rights）來羅列每個角色都可以進行哪些操作。②用戶報修時會涉及調用與 “位置信息”相關的3個表，以及與 “報修類別”相關的3個表中的內容項，但是，很顯然，這6個表的維護是后臺管理員的職責和權限。③為了增強系統的安全性，需要建立系統運行日志，即記錄所有的操作，包括操作發生的時間、發起該操作的用戶、操作的類型、操作的概要性說明、IP地址等等。這些都需要一個表來記錄，即日志表 （logs）。顯然，這個“日志表 （logs）”和 “記錄表 （records）”一樣也需要被定期轉儲和清理。④歷史數據的轉儲和調閱都會涉及 “時間段定義”業務，因而需要一個時間段表 （interval）來維護時間段列表。⑤整個系統的全局信息需要一個表來維護，即系統表 （system）。其中包含 “系統標題”、“版權”、“后臺管理員賬號”等常規信息，還要包含支持前面提到的 “用戶地址簿”業務的相關信息，如每個用戶的地址條目數上限；默認系統要求報修被受理的時限；默認系統要求報修被處理完畢的時限等等。⑥根據圖1，一條報修記錄生成后，會經歷不同的狀態。這些狀態包括已報修、已撤銷、處理中、已完結、已過期、被投訴、申請延期中、暫緩處理、等待評價、敦促中、申請撤銷中等等。這些狀態的表述可能會需要修改，而且，2～5個字的短語可能不足以將其含義表達清楚，因此需要配以解釋說明，所以就需要一個狀態表 （state）來維護這些信息。⑦同大多數用戶管理機制一樣，需要向前臺用戶提供 “找回密碼”的途徑，常見的就是 “密碼問題”。為了方便管理，不推薦由用戶自定義密碼問題，而是由系統設定，因此需要一個密碼問題表 （question）。⑧每個維修員都應該有明確的職責分工，包括負責維修的區域、建筑；負責維修的大類、小類，因此需要一個職責分工表 （responsibility）。⑨報修方在業務進入 “完工”狀態后，可以對此次報修處理進行評級，但是評級的習慣有多種，有的用 “滿意、基本滿意、不滿意”；有的用 “優、良、中、差”。為了滿足通用性，需要一個評級表 （grade）。可以在這個表中引入 “評級”和 “評級值”的概念—— “評級”是直接顯示給前臺用戶的，每一個 “評級”對應一個 “評級值”，這個值主要是面向日后的統計分析的。

3．2 重點表的設計

所有表中 “記錄表 （records）”的設計是最為講究的，因為它直接為日后的統計分析提供第一手的數據。“能夠提供豐富的統計分析功能”是系統人性化的重要表現。因此筆者對這個表向統計分析功能提供信息的能力有很高的要求，記錄表的結構如表1。表1中，第1～14字段，是報修方在提交報修信息后寫入的。其中第2～6字段來自于報修方的登錄信息，第7～13字段是由報修方填寫的。第15個字段，是根據第7～13字段的內容到 “職責分工表 （responsibility）”中查詢后得到的。第16、17個字段，是在維修方進行 “受理”操作后根據維修人員的登錄信息寫入的 （因為有r＿selectable＿mm字段的存在，所以很容易就可以實現 “僅相關的維修人員才能看到該報修信息”的功能，也就只有這些相關的維修人員才能受理此項報修）。第18個字段是根據 “系統表 （system）”中的相關信息確定的。第19個字段是維修人員進行 “完工”操作時寫入的。第20個字段是根據報修方的 “評級”操作而寫入的。第21個字段用于記錄所有的評價、投訴、評價回復、投訴回復等。第22個字段的內容隨不同的操作而改變，以反映該報修業務的當前狀態。

表1 記錄表 （records）的結構

3．3 細節設計

區域信息表 （areas）、樓宇信息表 （buildings）和房間信息表 （rooms）以及部門信息表 （departments）、大類信息表 （big＿class）和小類信息表 （small＿class）中的內容是要提供給前臺用戶在報修時選擇的。為了方便程序設計時控制這些表中信息項的顯示，可以加入2個字段：“次序”（order，數值型）和 “是否可見”（visible，布爾型）。

［1］Connolly T M．數據庫設計教程 ［M］．第2版 ．何玉潔 譯 ．北京：機械工業出版社，2005．

［2］鮑威爾 ．數據庫設計入門經典 ［M］．沈潔 譯 ．北京：清華大學出版社，2007．