人事管理_高校人事管理系統(tǒng)數(shù)據(jù)庫設計_第1頁
人事管理_高校人事管理系統(tǒng)數(shù)據(jù)庫設計_第2頁
人事管理_高校人事管理系統(tǒng)數(shù)據(jù)庫設計_第3頁
人事管理_高校人事管理系統(tǒng)數(shù)據(jù)庫設計_第4頁
人事管理_高校人事管理系統(tǒng)數(shù)據(jù)庫設計_第5頁
已閱讀5頁,還剩33頁未讀 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領

文檔簡介

某某大學計算機與信息技術學院數(shù)據(jù)庫系統(tǒng)課程設計論文題 目:高校人事管理系統(tǒng)數(shù)據(jù)庫設計組 長 專 業(yè) 計算機科學與技術 班 級 授課教師 高校人事管理系統(tǒng)數(shù)據(jù)庫設計 內(nèi)容提要 高校人事管理系統(tǒng)包括人事檔案信息錄入、人事檔案信息顯示及人事信息查詢等。系統(tǒng)開發(fā)采用了C+,有開發(fā)效率高,調(diào)試容易,維護方便等優(yōu)點。實現(xiàn)了顯示信息分頁,組合查詢等方便用戶的功能,提高了高校人事管理的效率。目前軟件市場有很多人事管理系統(tǒng)軟件,有的功能強大,適合管理大型的集團型企業(yè),有的功能單一,適合管理小型企業(yè)。針對高校的人事管理軟件卻沒有通用的商業(yè)軟件。因為高校的人事管理有其特殊性,每個院校之間的差別很大,管理方法存在很大差別。市場化的通用商品軟件很難滿足所有高校的人事管理需求。高校的人事管理軟件均采用定制化開發(fā),根據(jù)本校的實際情況,開發(fā)切合本校實際的管理程序。在設計時我們根據(jù)E-R圖的類型和一些實際需求轉(zhuǎn)化為相應的關系模型,并通過分析關系模型中依賴關系,對關系模型進行了優(yōu)化,同時根據(jù)確切需求分析各個關系模式所屬范式和優(yōu)化原因。最終確定了在數(shù)據(jù)庫中存儲所用的關系模式,定義了基本表和視圖模式,確定了系統(tǒng)功能模塊圖,得到了數(shù)據(jù)庫的關系圖。根據(jù)以上得到的結(jié)果,構(gòu)建出符合要求的數(shù)據(jù)庫,通過物理設計將邏輯模型轉(zhuǎn)化為物理模型,確定了存儲結(jié)構(gòu)和建立的索引以及功能模塊。利用C+平臺使數(shù)據(jù)庫與程序相結(jié)合構(gòu)成了具有相應功能的系統(tǒng)。關鍵字:數(shù)據(jù)庫;E-R圖;數(shù)據(jù)流圖;高校人事管理;系統(tǒng)設計;系統(tǒng)實現(xiàn)努力了的才叫夢想,不努力的就是空想!如果你一直空想的話,無論看多少正能量語錄,也趕不走滿滿的負能量!你還是原地踏步的你,一直在看別人進步。目 錄1 引言32 需求分析階段32.1 引言32.2 需求分析階段的目標與任務32.3 需求分析階段成果53.1 引言143.2 任務與目標144邏輯設計階段174.1邏輯設計的任務和目標174.2數(shù)據(jù)組織174.2.1將E-R圖轉(zhuǎn)換為關系模型174.2.3數(shù)據(jù)庫模式定義184.2.4 用戶子模式定義204.3數(shù)據(jù)處理214.4數(shù)據(jù)庫關系圖225物理設計階段225.1物理設計階段的目標與任務225.2數(shù)據(jù)存儲方面225.3教師/主任基本信息的查詢和更新模塊236數(shù)據(jù)庫實施階段236.1建立數(shù)據(jù)庫、數(shù)據(jù)表、視圖、索引236.1.1 建立數(shù)據(jù)庫236.1.2 建立數(shù)據(jù)表236.1.3 建立視圖256.1.4 建立索引256.1.5 建立觸發(fā)器266.2數(shù)據(jù)入庫266.3創(chuàng)建各個功能的存儲過程26七、應用設計:26八系統(tǒng)調(diào)試和測試29九、存在問題:30十、各學生貢獻說明:30參考文獻31附錄1 存儲過程定義31附錄2 程序源代碼(嵌入式SQL某模塊讀與寫操作)32附錄3 所有的SQL運行語句34331 引言隨著信息技術的快速發(fā)展,數(shù)字化校園是高校教育信息化發(fā)展的必然趨勢,也是未來 學校發(fā)展的必然方向。一個高校人事管理信息系統(tǒng)的好壞直接影響著教師的各類活動,從而影響著整個高校的教學、辦學水平,所以一個高效的人事管理信息系統(tǒng)對整個高校的發(fā)展起著至關重要的作用。這就是選用此作為設計課題的原因。設計過程按照數(shù)據(jù)庫設計方式從需求分析、概念模型建立、邏輯設計、物理設計、數(shù)據(jù)庫實現(xiàn)、系統(tǒng)實現(xiàn)幾個階段一步一步完成了設計的任務。2 需求分析階段2.1 引言高校人事管理信息系統(tǒng)屬于數(shù)字化校園應用支撐系統(tǒng)中比較重要的一環(huán),其面向?qū)ο笾饕?是高校中的教師、管理人員和服務人員,其中教師是主體,管理人員是關鍵,所以高校的人事管理是以教師為主體對象的一種團體、社會活動。高校人事管理系統(tǒng)平臺需要完成基本查詢的功能,以及管理員,學生,部門主任三方之間的信息交互。經(jīng)過調(diào)查需求,對三方所需的需要進行分析:管理員需要注冊教師,學生,完成對學生教師的信息的修改查詢,以及對某些特定要求可以實現(xiàn)數(shù)據(jù)的統(tǒng)計功能,管理員還可以根據(jù)一些規(guī)定刪除某些學生或教師的信息;教師端可以實現(xiàn)對自己工資詳單的查詢,可以實現(xiàn)對自己的某些個人信息進行修改;部門主任可以對教師信息進行查詢以及對個人信息的修改 為了完成上述的需求,將系統(tǒng)基本分為三個子系統(tǒng):管理員端,教師端,部門主任端根據(jù)身份驗證獲得不同的權(quán)限,以不同的方式來訪問同一個數(shù)據(jù)庫。主要功能有:1. 管理員端:主要能實現(xiàn)對學生教師的增刪改查以及統(tǒng)計。2. 教師端:能瀏覽自己的工資和其他個人信息,還可以進行修改。3. 部門主任端:可以對教師信息進行修改統(tǒng)計。2.2 需求分析階段的目標與任務2.2.1處理對象1. 管理員信息:用戶名,密碼,公告2. 教師信息:教師姓名、教師性別、教師身份證號、密碼、教師學歷、教師職務、職稱、家庭住址、教師密碼、部門編號、出生年月、所在部門、用戶身份、工資3. 教師工資信息:教工編號、職稱、職務、加班工資、考勤工資、基本工資、總工資、時間、教師姓名 首先從需求分析階段中,確定了幾項基本的處理對象,有可能這些處理對象不完全,需要在后續(xù)的各個階段中不斷修改和完善。2.2.2處理功能及要求1.管理員端的處理功能1)用戶管理1、添加用戶2、修改密碼3、刪除用戶2) 部門管理 1、 查詢部門信息2、 修改部門公告3、 增加部門類型4、 刪除部門5、 統(tǒng)計部門信息3) 職工管理1、 修改通知信息2、 職工測評3、 修改查詢教師信息2.部門主任功能1)查看系統(tǒng)公告2)查看本部門成員3)修改個人資料 1、修改職工信息 2、修改自己信息4)查詢員工考勤管理 1、修改員工考勤 2、查詢員工考勤 3、刪除員工考勤5)管理員工工資 1、合計員工工資 2、查詢員工工資6)員工獎懲管理3職工功能1) 查看通知2) 申請病假3) 修改個人信息4) 查看個人工資4.能夠提供一定的安全機制,提供數(shù)據(jù)信息授權(quán)訪問,防止隨意刪改、查詢。5.系統(tǒng)界面要友好,系統(tǒng)的健壯性要強,后臺要穩(wěn)定。2.2.3.安全性和完整性要求1) 安全性要求 系統(tǒng)的安全性也是一個需要重點考慮的問題。人事管理系統(tǒng)中保存了很多敏感的信息,如教師的基本情況等。非授權(quán)用戶不可查詢、更改或刪除。本系統(tǒng)所采用的方法是首先在進人系統(tǒng)時檢查用戶名和口令,因此非系統(tǒng)用戶很難進入系統(tǒng)。即使能夠進入系統(tǒng),所有的涉及數(shù)據(jù)增加、更改和刪除的地方都需要進行權(quán)限確認以保證操作合法進行。當然,數(shù)據(jù)庫本身是加了密的,非法用戶很難打開數(shù)據(jù)庫而直接進行修改。而關于用戶名與口令的信息則經(jīng)過一定的算法加密后保存在數(shù)據(jù)庫中。系統(tǒng)的安全性得到了較好的保證。2) 完整性要求系統(tǒng)完整性要求系統(tǒng)中數(shù)據(jù)的正確性以及相容性??赏ㄟ^建立主、外鍵,確定了每個表中的主碼,主碼唯一,以及一個表與其他表相關聯(lián)的外碼;對于一些等級屬性和一些確定取值范圍的屬性使用check約束;還有一些標志變量,取值范圍為0或1代表的意義不同,可以通過使用觸發(fā)器來實現(xiàn);以及要做到視圖級聯(lián)更新;有的值不能為空,若為空則沒有意義整個元組不完整,則需要表示Not null通過定義實體完整性、參照完整性、用戶定義完整性使其滿足完整性要求。利用觸發(fā)器可以對給出等級的限制,將超出的部分變?yōu)楹戏ǖ姆秶鷥?nèi)數(shù)據(jù);利用觸發(fā)器進行級聯(lián),修改一表中的項,將其他關聯(lián)表的記錄也同時刪除。2.3 需求分析階段成果2.3.1 體會與收獲系統(tǒng)需求分析主要是通過對已有的人事管理系統(tǒng)功能進行參考,了解了山大等高校人事管理平臺的的管理規(guī)則和運行機制,并通過上網(wǎng)搜索有關高校人事管理系統(tǒng)的知識。從許多人事管理的案例以及山大的人事管理中找尋出一些基本的功能,在這些功能的基礎上在繪制系統(tǒng)業(yè)務流程圖,遇到了很多的問題,有的問題沒法合理的表示出來,需要在過程中才會反應出來,仍需要繼續(xù)改進,通過老師的幫助與指導,和組員之間一遍一遍的分析和完善,才逐步把業(yè)務各個過程了解清楚,最終順利完成了需求分析階段的任務。2.3.2 高校人事管理系統(tǒng)系統(tǒng)功能模塊圖1. 管理員功能模塊圖:2部門主任功能模塊圖:2. 教師功能模塊圖:2.3.3高校信息管理系統(tǒng)數(shù)據(jù)流圖1.系統(tǒng)數(shù)據(jù)流圖2管理員系統(tǒng)流圖:2.1管理員子系統(tǒng)用戶管理流圖:2.2管理員子系統(tǒng)部門管理流圖:2.3管理員子系統(tǒng)職工管理:3部門主任系統(tǒng)流圖:3.1部門主任子系統(tǒng)工資流圖:3.2部門主任子系統(tǒng)個人信息流圖:4職工系統(tǒng)數(shù)據(jù)流圖:高校人事管路系統(tǒng)數(shù)據(jù)字典:(a)數(shù)據(jù)項:系統(tǒng)涉及的數(shù)據(jù)項有39項表1.1 數(shù)據(jù)項列表數(shù)據(jù)項編號數(shù)據(jù)項名數(shù)據(jù)項含義所屬基本表存儲結(jié)構(gòu)別名DL-1用戶名登錄所需用戶權(quán)限信息char(10)DL-2密碼登錄所需用戶權(quán)限信息char(12)DL-3權(quán)限登錄所需用戶權(quán)限信息char(10)DL-4公告信息公告信息char(12)DL-5部門編號部門信息Char(16)DL-6部門名稱部門信息Char(8)DL-7部門主任名部門信息char(10)DL-8缺課次數(shù)考勤信息char(20)DL-9請假原因考勤信息Char(20)DL-10是否批準考勤信息Char(20)DL-11請假日期考勤信息Char(14)DL-12請假天數(shù)考勤信息Char(40)DL-13獎勵獎懲信息floatDL-14處罰原因獎懲信息floatDL-15罰金獎懲信息Char(20)DL-16基本工資工資信息floatDL-17考勤所扣工資工資信息floatDL-18獎金工資信息floatDL-19處罰金額工資信息char(10)DL-20稅率工資信息Char(12)DL-21職工姓名職工信息Char(40)DL-22職工性別職工信息Char(2)DL-23職工年齡職工信息char(10)DL-24職工職稱職工信息Char(20)等級DL-25職工家庭住址職工信息floatDL-26職工相片職工信息imageDL-27職工畢業(yè)學校職工信息Char(30)DL-28職工教齡職工信息Char(10)DL-29職工手機號職工信息Char(11)(b)數(shù)據(jù)結(jié)構(gòu):數(shù)據(jù)結(jié)構(gòu)編號數(shù)據(jù)結(jié)構(gòu)名數(shù)據(jù)結(jié)構(gòu)含義組成DS-1管理員信息存儲管理員基本信息用戶名,密碼,郵箱,權(quán)限 DS-2部門主任信息存儲部門主任基本信息部門主任姓名,部門辦公室電話,部門主任聯(lián)系電話,部門主任性別,部門主任年齡DS-3教師職工信息存儲教師職工基本信息姓名、性別、年齡、職稱、職工家庭住址、職工相片、畢業(yè)學校、教齡、手機號DS-4用戶權(quán)限信息存儲用戶權(quán)限信息用戶名、密碼、權(quán)限D(zhuǎn)S-5工資信息存儲用戶工資信息基本工資、考勤所扣工資、獎金、處罰金、稅率DS-6獎懲信息存儲員工獎懲信息獎勵、處罰DS-7考勤信息存儲員工考勤信息請假天數(shù)、請假日期、是否批準、缺課次數(shù)、請假原因DS-8部門信息存儲部門信息部門編號、部門主任名、部門名稱DS-9公告信息存儲公告公告信息(c)邏輯描述管理員端處理邏輯描述處理編號處理功能處理過程PR-1判斷管理員用戶管理所涉及到的功能模塊,進行相應的處理權(quán)限信息模塊將權(quán)限表傳入管理員模塊,進行適應的處理之后,再將相應的的數(shù)據(jù)傳入相應的模塊PR-2判斷管理員管理部門涉及到的功能模塊部門主任信息模塊、公告信息模塊處理相應的數(shù)據(jù),然后將處理結(jié)果傳入相應模塊PR-3判斷管理員管理員工所涉及到的功能模塊職工信息模塊、公告信息模塊、職工測評模塊處理相應的數(shù)據(jù),然后將處理結(jié)果傳入相應模塊部門主任端處理邏輯描述處理編號處理功能處理過程PR-1判斷部門主任查看公告和員工信息所涉及的功能模塊 然后進行管理操作公告信息模塊,員工信息模塊,將公告信息傳入公告信息模塊,查詢員工信息的過程中,將所需要的員工信息一次導入PR-2判斷部門主任工資修改涉及的功能模塊工資信息模塊,考勤信息模塊,獎懲信息模塊確定工資管理所要涉及的功能模塊,將消息傳入相應的模塊中,然后進行相應的操作PR-3判斷部門主任管理員工考勤和獎懲涉及到的功能模塊考勤信息模塊,獎懲信息模塊確定部門主任所要管理的模塊并傳入相應的模塊教師職工端處理邏輯描述處理編號處理功能處理過程PR-1判斷教職工查看個人信息所涉及的功能模塊 然后進行管理操作職工信息模塊,獎懲信息模塊,考勤信息模塊先確定職工查詢所要涉及的功能模塊,將所要的字段信息傳入相應信息模塊或進行編輯信息PR-2判斷教職工查看公告和工資所要涉及的功能模塊公告信息模塊,工資信息模塊,確定員工所要查詢信息所要涉及的功能模塊,將消息傳入相應的模塊中,然后進行相應的操作PR-3判斷教職工病假申請涉及到的功能模塊考勤信息模塊將考勤相關信息傳入考勤信息模塊3 概念設計階段3.1 引言系統(tǒng)開發(fā)的總體目標是實現(xiàn)高校人事管理系統(tǒng)系統(tǒng)化,實現(xiàn)教師學生的基本需求,基本做到高效、智能化管理。主要任務是實現(xiàn)增刪改查功能,對教師信息和其他信息進行管理和操作。概念設計階段主要是將需求分析階段得到的用戶需求抽象為信息結(jié)構(gòu)(概念模型)的過程,它是整個數(shù)據(jù)庫設計的關鍵。3.2 任務與目標 (1)選擇中層數(shù)據(jù)流為切入點,通常選擇實際系統(tǒng)中的子系統(tǒng); (2)設計分E-R圖,即各子模塊的E-R圖; (3)生成初步E-R圖,通過合并方法,做到各子系統(tǒng)實體、屬性、聯(lián)系統(tǒng)一; (4)生成全局E-R圖,通過消除沖突等方面。在本系統(tǒng)中,從三個不同的功能端下手。分析各子系統(tǒng)的數(shù)據(jù)流圖和數(shù)據(jù)字典,知道整個系統(tǒng)功能圍繞“部門主任”、“教師”和“管理員”的處理。根據(jù)實體與屬性間的兩條準則:作為“屬性”,不能再具有需要描述的性質(zhì)?!皩傩浴辈荒芘c其他實體具有聯(lián)系。從分層的數(shù)據(jù)流圖中將系統(tǒng)分為三個子系統(tǒng):管理員子系統(tǒng),職工子系統(tǒng),部門主任子系統(tǒng)。某一層的數(shù)據(jù)流圖中,每個局部應用都對應了一組數(shù)據(jù)流圖,局部應用涉及的數(shù)據(jù)都已經(jīng)收集在數(shù)據(jù)字典中了。現(xiàn)在將這些數(shù)據(jù)從數(shù)據(jù)字典中抽取出來,根據(jù)數(shù)據(jù)流圖,確定實體之間的聯(lián)系及其類型。根據(jù)管理員數(shù)據(jù)流圖確定了管理端分E-R圖;根據(jù)部門主任子系統(tǒng)數(shù)據(jù)流圖確定了部門主任E-R圖;根據(jù)職工子系統(tǒng)數(shù)據(jù)流圖確定了職工E-R圖。對于三個分E-R圖,通過消除屬性沖突,例如將所有的編號都統(tǒng)一為數(shù)值型,將所有的用戶名和密碼統(tǒng)一為字符型,將聯(lián)系方式統(tǒng)一為字符型;消除命名沖突,將同名異義的取不同的名稱,將異名同義的改為統(tǒng)一名稱;消除結(jié)構(gòu)沖突,將實體的屬性統(tǒng)一,對在不同E-R圖中相同實體的不同聯(lián)系進行調(diào)整,得到了系統(tǒng)的E-R圖。3.3 階段結(jié)果(1)根據(jù)不同的對象,分別畫出各分ER圖:(a)教師E-R圖(b)部門主任E-R圖(c)管理員E-R圖(d)E-R圖合并(3)各ER圖各實體主要屬性如下所示:1. 部門主任:部門名稱,主任姓名,主任家庭住址,主任電話,主任辦公室電話,主任年齡,主任性別2. 教師職工 :職工姓名,職工編號,職工性別,職工手機號,職工職稱,職工教齡,職工住址,職工所在部門,職工工資3. 工資 :基本工資,工資稅率,獎金,罰金,總工資4. 管理員 :管理員帳號,密碼4邏輯設計階段4.1邏輯設計的任務和目標以上的概念設計階段是獨立于任何一種數(shù)據(jù)模型的,但是邏輯設計階段就與選用的DBMS產(chǎn)品發(fā)生關系了,系統(tǒng)邏輯設計的任務就是將概念設計階段設計好的基本E-R圖轉(zhuǎn)換為選用DBMS產(chǎn)品所支持的數(shù)據(jù)模型相符合的邏輯結(jié)構(gòu)。具體內(nèi)容包括數(shù)據(jù)組織(將E-R圖轉(zhuǎn)換成關系模型、模型優(yōu)化、數(shù)據(jù)庫模式定義、用戶子模式設計)、數(shù)據(jù)處理(畫出系統(tǒng)功能模塊圖)兩大任務。4.2數(shù)據(jù)組織4.2.1將E-R圖轉(zhuǎn)換為關系模型1、職工與病假(1:n),公告是(n:m)的關系,若將這些放在同一個表的話會造成數(shù)據(jù)冗余,浪費存儲空間,所以可以將職工單獨列為一個表,病假,公告各做一個表,通過職工號相聯(lián)系2、管理員和職工,部門主任,職工評價,公告是(1:n)的關系,同上可以將管理員單獨成表,部門主任和職工評價單獨成表,管理員與部門主任通過部門編號聯(lián)系,管理員和職工可以通過職工號相聯(lián)系,管理員與公告可以通過公告類型相聯(lián)系。3、工資是建立在部門主任和職工之間的聯(lián)系(n:m),一個職工和他所對應的部門主任可以確定一個工資信息,所以可以將職工編號作為碼,并將工資信息做一表。4、職工與獎懲之間的聯(lián)系為(1:n),可以通過職工編號與獎懲信息表相關聯(lián),并將職工編號作為碼。5、職工,部門主任,管理員與權(quán)限之間的聯(lián)系(n:1)的關系,所以可以建立一個權(quán)限表,通過部門編號,職工編號與之聯(lián)系綜上所述得到如下關系模型:職工信息(職工姓名,職工編號,職工性別,職工手機號,職工職稱,職工教齡,職工住址,職工所在部門,職工工資)公告信息(公告編號,公告類型,公告內(nèi)容,公告時間,職工編號)病假信息(病假編號,請假原因,請假時間,請假多久,職工編號)獎懲信息(獎懲編號,獎勵原因,獎勵額度,懲罰原因,懲罰額度,職工編號)部門主任信息(部門編號,部門名稱,主任姓名,主任家庭住址,主任電話,主任辦公室電話)工資信息(工資編號,基本工資,工資稅率,獎金,罰金,總工資,職工編號)權(quán)限信息(編號,權(quán)限,密碼,姓名)4.2.2模型優(yōu)化根據(jù)以上得到的關系模式進行優(yōu)化:職工信息:職工編號職工姓名,職工編號職工性別,職工編號職工手機號,職工編號職工職稱,職工編號職工教齡,職工編號職工住址,職工編號職工所在部門,職工編號職工工資。該關系滿足1NF,而且其中除了碼職工編號外,其他非主屬性都完全依賴于主屬性,因為職工編號是碼,故也滿足BCNF所以已優(yōu)化。公告信息:公告編號公告類型,公告編號公告內(nèi)容,公告編號公告時間滿足BCFN,故不需要優(yōu)化。病假信息:病假編號請假原因,病假編號請假時間,病假編號請假多久,病假編號職工編號。滿足BCFN,不需優(yōu)化。獎懲信息:獎懲編號獎懲原因,獎懲編號獎勵額度,獎懲編號懲罰原因,獎懲編號懲罰額度,獎懲編號職工編號。滿足BCNF,故不需優(yōu)化。部門主任信息:部門編號主任姓名,部門編號主任住址,部門編號主任手機號,部門編號主任辦公室電話,部門名稱部門編號,部門名稱主任姓名,部門名稱主任電話,部門名稱主任家庭住址。該關系模式滿足2NF,在部門名稱存在傳遞依賴,若把部門編號與部門名稱建立一個表,將會滿足BCNF,但使用起來比較繁瑣,效率降低,一般只用部門名稱去得到其他信息而不需要部門編號,所以在這里分表也沒有必要。工資信息:工資編號基本工資,工資編號獎金,工資編號罰金,工資編號總工資,工資編號職工編號,滿足BCNF,已經(jīng)優(yōu)化。權(quán)限信息:編號權(quán)限,編號密碼,滿足BCNF,無需優(yōu)化。4.2.3數(shù)據(jù)庫模式定義表2.1 職工信息表列名數(shù)據(jù)類型可否為空說明職工編號charnot null主碼職工姓名charnot null用戶名職工性別charnot null性別職工手機號charnot null手機職工職稱charnot null職稱職工住址floatnot null職工工資floatnot null總工資表2.2 公告信息表列名數(shù)據(jù)類型可否為空說明公告編號charnot null公告編號公告類型charnot null職工公告,主任公告公告內(nèi)容charnot null內(nèi)容公告時間datenot null發(fā)布時間表2.3 病假信息表列名數(shù)據(jù)類型可否為空說明病假編號charnot null病假編號職工編號CharNot null 職工編號請假原因charnot null請假說明請假時間datenot null請假時間請假多久intnot null請假多長時間表2.4 獎懲信息表列名數(shù)據(jù)類型可否為空說明獎懲編號charnot null獎懲編號職工編號CharNot null職工編號獎勵原因charnot null受獎勵說明獎勵額度charnot null獎勵等級,獎金等所獲獎勵懲罰原因charnot null懲罰說明懲罰額度charnot null處分程度表2.5 部門主任信息表列名數(shù)據(jù)類型可否為空說明部門編號charnot null部門編號部門名稱charnot null部門名稱主任姓名charnot null主任家庭住址charnot null主任電話charnot null主任辦公室電話charnot null辦公室電話表2.6 工資信息表列名數(shù)據(jù)類型可否為空說明工資編號charnot null工資編號職工編號CharNot null職工編號基本工資floatnot null不同職工基本工資不同工資稅率floatnot null獎金floatnot null因某些獎勵獲節(jié)日所獲得獎金罰金floatnot null因某些處罰所扣資金時間datetimenot null總工資floatnot null每月實獲工資表2.7 權(quán)限信息表列名數(shù)據(jù)類型可否為空說明編號charnot null職工編號和部門編號權(quán)限charnot null不同用戶權(quán)限不同密碼charnot null登陸密碼姓名CharNot null登錄賬號4.2.4 用戶子模式定義表2.7 用戶子模式定義編號用戶子模式(View)作用(共性:提供數(shù)據(jù)保密和安全保護機制)V1TeacherView便于查詢和修改教師職工的基本信息V2GongziView便于查詢當月職工工資詳細V3JisuanView便于職工工資計算表2.8 教師職工信息視圖列名數(shù)據(jù)類型可否為空說明職工編號Charnot null職工的唯一標識職工姓名Charnot null職工的名字職工地址Charnot null職工的家庭住址職工手機號Charnot null職工聯(lián)系方式職工工資Charnot null職工月工資表2.9 工資信息視圖列名數(shù)據(jù)類型可否為空說明職工編號Charnot null每個職工的標識基本工資Charnot null職工的基本工資獎金Charnot null當月所受獎勵處罰Charnot null當月處罰所扣總工資Charnot null當月所領工資表2.9 工資計算信息視圖列名數(shù)據(jù)類型可否為空說明職工編號Charnot null職工的標識獎金Charnot null獎勵金額罰金Charnot null處罰金額請假時間Charnot null考勤里請假時間請假多久Charnot null考勤中請假時間長度4.3數(shù)據(jù)處理系統(tǒng)功能圖4.4數(shù)據(jù)庫關系圖5物理設計階段5.1物理設計階段的目標與任務 數(shù)據(jù)庫的物理設計就是為邏輯數(shù)據(jù)模型選取一個最合適應用要求的物理結(jié)構(gòu)的過程,在這個階段中要完成兩大任務:(1)確定數(shù)據(jù)庫的物理結(jié)構(gòu),在關系數(shù)據(jù)庫中主要是存取方法和存儲結(jié)構(gòu);(2)對物理結(jié)構(gòu)進行評價,評價的重點是時間和空間效率。 如果評價結(jié)果滿足原設計要求,則可進入到物理實施階段,否則就需要重新計劃或者修改物理結(jié)構(gòu),甚至需要返回邏輯設計階段修改數(shù)據(jù)模型。5.2數(shù)據(jù)存儲方面為數(shù)據(jù)庫中各基本表建立的索引如下:1. 由于基本表職工表的職工信息,主碼職工編號,聯(lián)系電話經(jīng)常在查詢中,作為連接操作的連接條件出現(xiàn),且它們是唯一的,在兩個屬性上建立唯一性索引。2. 由于基本表出勤記錄,缺勤時間經(jīng)常在查詢條件中出現(xiàn)在兩個屬性上建立聚簇索引。3. 工資信息基本表的屬性名稱,獎金,罰款經(jīng)常在查詢中出現(xiàn),考慮在其之上建立聚簇索引。5.3教師/主任基本信息的查詢和更新模塊 將實現(xiàn)對教職工、部門主任的基本信息更新(查詢、添加、刪除)操作,用于教職工的調(diào)職,新增,離校等操作的更新。具體如下:6數(shù)據(jù)庫實施階段6.1建立數(shù)據(jù)庫、數(shù)據(jù)表、視圖、索引6.1.1 建立數(shù)據(jù)庫 create database GXRSHGLXT;6.1.2 建立數(shù)據(jù)表(1)職工表的建立CREATE TABLE Teacher(TSno nchar (20),TName nchar (30),TSex nchar(4), TPhonecall nchar(11),TAddress nchar(30) TZhicheng nchar(16),TJage smallint,TDept nchar(16),TSalary money, CONSTRAINT PK_Teacher PRIMARY KEY CLUSTERED)(2)工資表的建立 CREATE TABLE Salary(TSno nchar(20),BSalary money,JLMoney money,CHFMoney money,SUMSalary money, CONSTRAINT PK_Salary_1 PRIMARY KEY CLUSTERED)(3)權(quán)限表的建立CREATE TABLE QuanXian(Sno nchar(20),Password nchar(20),LVL nchar(4),TName nchar(30), CONSTRAINT PK_QuanXian PRIMARY KEY CLUSTERED)(4)公告表CREATE TABLE Note(NoteSno nchar(20),NoteLx nchar(4),NoteContent nchar(60),NoteTime datetime, CONSTRAINT PK_Note PRIMARY KEY CLUSTERED)(5)考勤表CREATE TABLE BJ(TSno nchar(20),BJReason nchar(50),BJDuoJiu nchar(10),BJTime datetime, CONSTRAINT PK_BJ PRIMARY KEY CLUSTERED)(6)獎懲表CREATE TABLE JLCHF(TSno nchar(20),JLReason nchar(50),JLEdu nchar(50),JLMoney money,CHFReason nchar(50),CHFEdu nchar(50),CHFMoney money, CONSTRAINT PK_JLCHF PRIMARY KEY CLUSTERED)6.1.3 建立視圖(1)創(chuàng)立教職工基本信息視圖,用于修改和查詢CREATE VIEW TeacherViewASSELECT TSno, TName, TPhonecall, TAddress, TSalaryFROM Teacher(2)創(chuàng)建工資信息視圖,用于職工當月工資查詢CREATE VIEW GongZiASSELECT TSno, BSalary, JLMoney, CHFMoney, SUMSalaryFROM Salary(3)創(chuàng)建工資計算視圖,用于職工工資的合計CREATE VIEW JiSuanViewASSELECT JLCHF.TSno, JLCHF.JLMoney, JLCHF.CHFMoney, BJ.BJTime, BJ.BJDuoJiuFROM BJ INNER JOIN JLCHF ON BJ.TSno =JLCHF.TSnoGROUP BY JLCHF.TSno, JLCHF.JLMoney, JLCHF.CHFMoney, BJ.BJTime, BJ.BJDuoJiu6.1.4 建立索引CREATE INDEX SalarySY ON Salary(SUMSalary);CREATE INDEX TeacherSY ON Teacher(TPhonecall);其余表都建立了相應的聚集索引。6.1.5 建立觸發(fā)器1規(guī)定教師工資經(jīng)過獎懲扣錢之后也不得低于3000元,如果少于3000,則改為最低標準3000元。createtriggerTeacher_salbeforeinsertorupdateonteacherforeachrowasbeginif(new.job=*)and(new.salOpen(select * from QuanXian,_variant_t(IDispatch *)theApp.m_pConnection,true),adOpenDynamic,adLockPessimistic,adCmdText); if(m_pRecordset_user-GetRecordCount() != 0)while(!m_pRecordset_user-adoEOF)strname = m_pRecordset_user-GetCollect(NAME).bstrVal;strpwd = m_pRecordset_user-GetCollect(PASSWORD).bstrVal;nlevel = m_pRecordset_user-GetCollect(LEVEl).lVal;if(strname.CompareNoCase(m_strLoginName) = 0 & strpwd.CompareNoCase(m_strLoginPwd) = 0 & nlevel = m_nLoginLevel)/記錄權(quán)限theApp.m_Level = m_nLoginLevel;theApp.Loginstatus = true;MessageBox(登錄系統(tǒng),系統(tǒng)登錄); CDialog:OnOK();return;m_pRecordset_user-MoveNext();MessageBox(用戶名和密碼錯誤,系統(tǒng)登錄);(2) 數(shù)據(jù)適配器寫操作(以管理員填寫注入職工信息為例)CString sql,str;sql = select * from StudentInfo ;m_pRecordset_stu.CreateInstance(ADODB.Recordset);m_pRecordset_stu-Open(_variant_t)sql,_variant_t(IDispatch *)theApp.m_pConnection,true),adOpenDynamic,adLockPessimistic,adCmdText); if(m_pRecordset_stu-GetRecordCount()!= 0)while(!m_pRecordset_stu-adoEOF)str = m_pRecordset_stu-GetCollect(ID).bstrVal;if(str.CompareNoCase(m_strID) = 0)AfxMessageBox(該編號的職工記錄已存在);retu

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論