【文章內容簡介】 根據上面的需求分析，總共需要6個工作表的數(shù)據支持：出勤記錄表、請假記錄表、加班記錄表、出差記錄表、員工基本信息表，消息記錄表。員工信息實體圖 對象：員工，員工的屬性如圖51所示：員工身份證號碼姓名性別籍貫員工類型員工編號 年齡聯(lián)系電話職務圖51員工信息實體圖考勤信息實體圖 對象：考勤，考勤的屬性如圖52所示：考勤記錄員工編號上班時間考勤時間狀態(tài)考勤編號圖52 出勤記錄實體圖請假信息實體圖 對象：請假，請假的屬性如圖53所示：請假信息請假編號員工編號請假開始時間請假結束時間請假原因圖53 請假實體圖加班信息實體圖 對象：加班信息，加班信息的屬性如圖54所示：加班信息員工編號加班編號加班開始時間加班結束時間部門圖54 加班實體圖出差信息實體圖 對象：出差信息，出差信息的屬性如圖55所示：出差信息 員工編號出差編號出差開始時間出差結束時間部門圖55 出差實體圖消息信息實體圖 對象：消息信息，消息信息的屬性如圖56所示：消息信息 員工編號消息編號消息標題 消息內容部門圖56 消息實體圖邏輯結構設計是數(shù)據庫設計的第二個階段，這個階段就是要根據已經建立的概念數(shù)據模型，以及所采用的某個數(shù)據庫管理系統(tǒng)軟件的數(shù)據模型特征，按照一定的轉換規(guī)則，把概念模型轉換為這個數(shù)據庫管理系統(tǒng)所能夠接受的邏輯數(shù)據模型。邏輯數(shù)據模型是用戶通過數(shù)據庫管理系統(tǒng)看到的現(xiàn)實世界，它描述了數(shù)據庫數(shù)據的整體結構。從理論上講，實際邏輯結構應該選擇最適合于描述與表達相應概念結構的數(shù)據模型，然后對支持這種數(shù)據模型的各種DBMS進行比較，綜合考慮性能、價格等各種因素，從中選出最合適的DBMS。本系統(tǒng)選擇的DBMS是SQL Server2000，根據此產品設計邏輯結構分了以下三步進行：(1)將概念結構轉化為一般的關系模型。(2)將轉化來的關系模型向SQL Server2000支持的數(shù)據模型轉換。(3)對數(shù)據模型進行優(yōu)化。并對數(shù)據模型進行適當?shù)男薷?、調整進行以下優(yōu)化：(1)確定數(shù)據依賴。(2)對于各個關系模式之間的數(shù)據依賴進行極小化處理，消除冗余的聯(lián)系。(3)按照數(shù)據依賴的理論對關系模式逐一進行分析，考查是否存在部分函數(shù)依賴、傳遞函數(shù)依賴、多值依賴等，確定各關系模式分別屬于第幾范式。通過進一步的分析得到如下關系模式：員工信息表：（員工編號，身份證號碼，姓名，性別，出生日期，籍貫，聯(lián)系方式）；考勤信息表: (考勤編號,上班時間,考勤時間,狀態(tài)，員工編號)；加班信息表: (加班編號,員工編號，加班開始時間,結束時間,部門)；出差信息表: (出差編號,員工編號，出差開始時間，結束時間,部門)；請假信息表: (請假編號,員工編號，請假時間,結束時間,請假原因)；消息信息表：（消息編號，員工編號，消息標題，消息內容，部門）；通過對ER圖和關系模式的分析得到如下表：考勤管理記錄表，請假記錄表，加班記錄表，出差記錄表，員工基本信息表，消息記錄表。（1） 考勤管理記錄表考勤管理記錄表主要包括：考勤編號、員工編號、員工姓名、員工上班時間、員工考勤時間，員工狀態(tài)表示員工是否遲到。它們的基本屬性如表51所示。設置考勤編號為主鍵。 表51 Attendance考勤記錄表列 名數(shù) 據 類 型可 否 為 空ID自動編號NOTNULL考勤編號文本（6）NOTNULL員工編號文本（6）NOTNULL狀態(tài)文本（1）NULL上班時間日期NULL考勤時間日期NULL（2） 請假記錄表請假記錄表主要包括：請假編號、員工編號、員工請假開始時間、員工請假結束時間，員工請假原因。它們的基本屬性如表52所示。設置請假編號為主鍵。 表52 Leave請假記錄表列 名數(shù) 據 類 型可 否 為 空ID自動編號NOTNULL請假編號文本（6）NOTNULL員工編號文本（6）NOTNULL開始時間日期NOTNULL結束時間日期NOTNULL請假事由文本（50）NOTNULL（3） 加班記錄表加班記錄表主要包括：加班編號、員工編號、員工加班開始時間、員工加班結束時間、員工加班日期、員工所屬部門。它們的基本屬性如表53所示。設置加班編號為主鍵。表53 OverTime 加班記錄表列 名數(shù) 據 類 型可 否 為 空ID自動編號NOTNULL加班編號文本（6）NOTNULL員工編號文本（6）NOTNULL加班開始時間日期NOTNULL加班日期日期NOTNULL加班結束時間日期日期部門文本（10）NOTNULL職務文本（5）NOTNULL（4） 出差記錄表出差記錄表主要包括：出差編號、員工編號、員工出差開始時間、員工出差結束時間、員工所屬部門。它們的基本屬性如表54所示。設置出差編號為主鍵。 表54 Errand 出差記錄表列 名數(shù) 據 類 型可 否 為 空ID自動編號NOTNULL出差編號文本（6）NOTNULL員工編號文本（6）NOTNULL出差開始時間日期NOTNULL出差結束時間日期NOTNULL部門文本（10）NOTNULL職務文本（5）NOTNULL（5） 員工記錄表員工記錄表主要包括：員工編號、員工籍貫、員工姓名、員工性別、員工所在部門、員工電話、員工身份證號碼、員工所在職務。它們的基本屬性如表55所示。設置員工編號為主鍵。 表55 Person 員工基本信息表列 名數(shù) 據 類 型可 否 為 空員工編號文本（6）NOTNULL員工籍貫文本（4）NOTNULL員工姓名文本（6）NULL性別文本（1）NOTNULL部門文本（3）NULL職位文本（3）NULL聯(lián)系電話文本（12）NULL身份證號碼文本（20）NULL（6） 消息記錄表消息記錄表主要包括：消息編號、員工編號、消息標題、消息內容，消息發(fā)送的部門。它們的基本屬性如表56所示。設置消息編號為主鍵。 表56 Idea 消息記錄表列 名數(shù) 據 類 型可 否 為 空ID自動編號NOTNULL消息編號文本（6）NOTNULL員工編號文本（6）NOTNULL消息內容文本（50）NOTNULL部門文本（6）NOTNULL 數(shù)據庫物理結構設計數(shù)據庫物理設計階段的任務是根據具體計算機系統(tǒng)(DBMS和硬件等)的特點，為給定的數(shù)據庫模型確定合理的存儲結構和存取方法。所謂的“合理”主要有兩個含義：一個是要使設計出的物理數(shù)據庫占用較少的存儲空間，另一個對數(shù)據庫的操作具有盡可能高的速度。物理結構設計階段實現(xiàn)的是數(shù)據庫系統(tǒng)的內模式，它的質量直接決定了整個系統(tǒng)的性能。因此在確定數(shù)據庫的存儲結構和存取方法之前，對數(shù)據庫系統(tǒng)所支持的事務要進行仔細分析，獲得優(yōu)化數(shù)據庫物理設計的參數(shù)。物理結構設計階段實現(xiàn)的是數(shù)據庫系統(tǒng)的內模式，它的質量直接決定了整個系統(tǒng)的性能。因此在確定數(shù)據庫的存儲結構和存取方法之前，對數(shù)據庫系統(tǒng)所支持的事務要進行仔細分析，獲得優(yōu)化數(shù)據庫物理設計的參數(shù)。6 系統(tǒng)詳細設計 管理員登錄界面設計依據需求分析，啟動系統(tǒng)時，最先出現(xiàn)的就是“登錄”界面，如圖61所示，用戶登錄可作為獨立窗體，當用戶登錄時，首先出現(xiàn)的是一個登錄頁面，只有輸入正確的管理員姓名與密碼時，才能進入考勤系統(tǒng)。圖 61 登錄界面考勤管理系統(tǒng)主界面的設計，是對用戶對系統(tǒng)不同操作功能的分類，將相同的操作放在同一個菜單中，將另外相同的操作放在另外一個菜單中。不同的權限的用戶有不同的操作范圍，最高權限的用戶有最高的使用權限，將獲得全部的操作。其他低權限的用戶將獲得部分系統(tǒng)操作的功能，其它的將灰色顯示，表示用戶不可用。如圖62所示。將系統(tǒng)的主界面設計為六個主菜單：菜單一為員工管理，包含二個子菜單為員工查詢、添加員工信息。菜單二為消息管理，包含三個子菜單為消息查詢、消息發(fā)送、收件信息查看，消息信息列表?？记跁r間管理，請假管理，出差管理，加班管理，分別是對員工狀態(tài)的記錄。圖 62 管理員主界面添加消息界面的設計，是用于管理員或者領導給本系統(tǒng)的所有用戶發(fā)布公司消息，主要添加內容有：消息發(fā)送的標題主要內容，要閱讀的部門，接受者則是要發(fā)送的對象主要針對的是一個部門。6