团队作业第五次—项目系统设计与数据库设计
作業描述
| 作業要求 | 團隊作業第五次—項目系統設計與數據庫設計 |
| 團隊名稱 | 待就業六人組 |
| 作業目標 | 宏觀的對系統的整體結構設計,并在此基礎上,進行數據庫設計 |
| 系統設計說明書.pdf | Github鏈接 |
| 數據庫設計說明書.pdf | Github鏈接 |
| 第五次作業評審表.pdf | Github鏈接 |
| 第五次作業答辯PPT.pdf | Github鏈接 |
一、設計類圖
在OOA模型中,我們初步建立了類圖,描述了系統中行為實體間的靜態結構。在OOD階段,我們詳細分析了類與類之間所存在的關聯性,從控制類、邊界類、實體類的角度出發,進一步總結梳理出系統整體的靜態組織結構。
1.1 登錄子系統類圖
1.2 參與者類圖
1.3 智能推送類
1.4 信息管理類圖
1.5 信息查詢類圖
1.6 投遞簡歷類圖
1.7 審核簡歷類圖
1.8 私信類圖
二、系統體系結構設計
2.1 系統分析
由OOA階段的分析可知,類圖體現了校招平臺在微觀上的靜態結構,但由于整個系統內容繁多,較為龐大,使用類圖分析將大大增多工作量,因此我們從宏觀上對整個系統進行分析,將之劃分為互有聯系又相對獨立的幾部分,如下圖所示。
2.1.1 用戶包圖
2.1.2 登錄包圖
2.1.3 界面包圖
2.1.4 接口包圖
2.2 結構設計
進行了以上分析之后,本平臺根據小組成員過去的開發經驗,決定采用MVC框架模式。MVC采用單一入口模式進行項目部署和訪問,準確處理好模塊與模塊之間的聯系。MVC包括三個部分:控制器,定義后使用視圖和模型,負責通信、轉發請求、響應請求;視圖,實現靜態的圖形界面設計;模型定義相應的控制器編寫算法等等實現程序功能、實現具體的數據管理和數據庫設計。MVC通用的模型設計如下圖所示。
針對MVC架構對類和操作進行分析,得到的分析結果如下圖:
2.3 功能模塊設計
根據系統需求分析對系統進行整體的模塊設計,設計出校招平臺的總體功能模塊結構圖(HIPO圖)將系統分為八部分,如下圖所示。
三、數據庫設計
根據系統的功能需求和系統架構模型,完成了系統的數據庫設計。
3.1 數據流圖
3.1.1 頂層數據流圖
3.1.2 求職者數據流圖
3.1.3 招聘者數據流圖
3.2 E-R圖設計
根據不同實體類型、屬性和聯系,完成對數據庫E-R圖設計,如下圖。
3.3 關系模型分析
將E-R圖轉換為關系模型。
- 公司(公司id,電話號碼,密碼,公司名,頭像鏈接,郵箱,企業描述,是否通過審核)
- 學生(學生id,密碼,電話號碼,用戶名,頭像鏈接,郵箱,性別,學校,專業,職業,當前城市,期望城市)
- 招聘會(招聘會id,公司id,時間,地點,面向人群,描述)
- 招聘信息(招聘信息id,公司id,時間戳,崗位描述,聯系人及聯系方式,任職資格,工作地點,投遞要求,工作職責,薪酬福利,招聘或者兼職,有效)
- 簡歷(簡歷id,student_id,電話號碼,用戶名,簡歷頭像鏈接,郵箱,性別,最高學歷,職業,當前城市,期望城市,教育背景,證書,項目經歷,實踐經歷,自我評價,簡歷狀態)
- 簡歷投遞(簡歷投遞id,公司發布的職位信息的id,簡歷id,投遞狀態)
- 聊天室(學生id,hr_id,聊天室id,發送方)
- 聊天記錄(記錄id,聊天室id,內容,時間戳)
3.4 表結構設計
結合MySQL數據庫管理系統特點和E-R圖設計,主要表的結構如下:(1)student表
| student_id | char(128) | 否 | 無 | 隨機生成的主鍵 |
| passwd | char(32) | 否 | 無 | 密碼 |
| telephone | char(14) | 否 | 無 | 電話號碼 |
| user_name | char(20) | 否 | 無 | 用戶名 |
| head_url | varchar(256) | 否 | 無 | 頭像鏈接 |
| char(32) | 否 | 無 | 郵箱 | |
| sex | tinyint(4) | 否 | 無 | 性別 |
| school | char(64) | 否 | 無 | 學校 |
| specialty | varchar(64) | 否 | 無 | 專業 |
| occupation | varchar(32) | 否 | 無 | 職業 |
| present_city | varchar(64) | 否 | 無 | 當前城市 |
| expected_city | varchar(64) | 否 | 無 | 期望城市 |
(2)企業信息表
| company_id | char(128) | 否 | 無 | 隨機生成的主鍵 |
| telephone | char(14) | 否 | 無 | 電話號碼 |
| passwd | char(32) | 否 | 無 | 密碼 |
| company_name | varchar(50) | 否 | 無 | 公司名 |
| head_url | varchar(256) | 否 | 無 | 頭像鏈接 |
| char(32) | 否 | 無 | 郵箱 | |
| description | text | 否 | 無 | 企業描述 |
| status | tinyint(4) | 否 | 無 | 是否審核 |
(3)招聘職位信息表
| publish_time | timestamp | 否 | 當前時間 | 時間戳 |
| company_id | char(128) | 否 | 無 | 公司id |
| description | text | 否 | 無 | 崗位描述 |
| recruitment_id | int(11) | 否 | 無 | 主鍵 |
| contact | varchar(32) | 否 | 無 | 聯系人及聯系方式 |
| qualifications | varchar(128) | 否 | 無 | 任職資格 |
| location | varchar(64) | 否 | 無 | 工作地點 |
| delivery_request | varchar(64) | 否 | 無 | 投遞要求 |
| duty | varchar(64) | 否 | 無 | 工作職責 |
| salary | varchar(64) | 否 | 無 | 薪酬福利 |
| type | int(11) | 否 | 無 | 招聘或者兼職 |
| validate | int(11) | 否 | 無 | 有效 |
(4)簡歷信息表
| resume_id | int(11) | 否 | 自增 | 簡歷id |
| user_id | char(128) | 否 | 無 | 外鍵 |
| telephone | char(14) | 否 | 無 | 電話號碼 |
| user_name | char(20) | 否 | 無 | 用戶名 |
| head_url | varchar(256) | 否 | 無 | 頭像鏈接 |
| char(32) | 否 | 無 | 郵箱 | |
| sex | tinyint(4) | 否 | 無 | 性別 |
| highest_education | tinyint(4) | 是 | NULL | 最高學歷 |
| occupation | varchar(32) | 否 | 無 | 職業 |
| present_city | varchar(64) | 否 | 無 | 當前城市 |
| expected_city | varchar(64) | 否 | 無 | 期望城市 |
| degree | varchar(1024) | 否 | 無 | 教育背景 |
| certificate | varchar(1024) | 否 | 無 | 證書 |
| project_experience | varchar(2048) | 否 | 無 | 項目經歷 |
| practical_experience | varchar(2048) | 否 | 無 | 實踐經歷 |
| self_evaluation | varchar(128) | 否 | 無 | 自我評價 |
| resume_status | int(11) | 否 | 無 | 0代表未投遞,1代表已投遞, |
(5)簡歷投遞表
| resume_delivery_id | int(11) | 無 | 自增 | 簡歷投遞id |
| recruitment_id | int(11) | 無 | 無 | 招聘信息的id |
| resume_id | int(11) | 無 | 無 | 簡歷id |
| delivery_status | int(11) | 無 | 0 | 投遞狀態 |
四、驗收驗證標準
界面和功能驗收驗證標準已經在需求規格說明書中已經涉及,這里不再贅述。這次的驗收驗證標準主要是對系統設計和數據庫設計:
4.1 系統體系結構需滿足MVC設計模式
MVC設計模式是將整個系統劃分為
(1)表現層(Presentation layer):包含表示代碼、用戶交互GUI、數據驗證。 該層用于向客戶端用戶提供GUI交互,它允許用戶在顯示系統中輸入和編輯數據,同時 系統提供數據驗證功能。
(2)業務邏輯層(Business layer):包含業務規則處理代碼,即程序中與業務 相關專業算法、業務政策等等。該層用于執行業務流程和制訂數據的業務規則。業務邏 輯層主要面向業務應用,為表示層提供業務服務。
(3)數據持久層(Persistence layer):包含數據處理代碼和數據存儲代碼。數 據持久層主要包括數據存取服務,負責與數據庫管理系統(如數據庫)之間的通信。
三個層次的每一層在處理程序上有各自明確的任務,在功能實現上有清晰的區分, 各層與其余層分離,但各層之間存有通信接口。
4.2 數據庫需滿足第三范式
- 第一范式(1NF):強調的是列的原子性,即列不能夠再分成其他幾列。
- 第二范式(2NF):首先是 1NF,另外包含兩部分內容,一是表必須有一個主鍵;二是沒有包含在主鍵中的列必須完全依賴于主鍵,而不能只依賴于主鍵的一部分。
- 第三范式(3NF):首先是 2NF,另外非主鍵列必須直接依賴于主鍵,不能存在傳遞依賴。即不能存在:非主鍵列 A 依賴于非主鍵列 B,非主鍵列 B 依賴于主鍵的情況。
4.3 數據庫對不同的用戶要有明確的權限劃分
- 游客:只有查看公開數據的權限
- 求職者:游客的權限+投遞簡歷的權限
- 招聘者:游客的權限+發布招聘消息+審核求職信息的權限
- 系統管理員:具有系統提供的一切權限
五、預期規劃
點擊鏈接查看預期規劃
六、組員貢獻占比
| 221600306 | XRK | 7h+1h | 95% | 系統體系結構設計、答辯 | 19.76% |
| 221600307 | Yellye | 6h | 90% | 系統體系結構設計 | 14.33% |
| 221600315 | 黎煥明 | 8h+1h | 90% | 關系模型設計、數據表設計、答辯 | 20.49% |
| 221600319 | Litm | 4h | 85% | 類圖改進、功能模塊層次圖、算法改進 | 11.3% |
| 221600327 | oirving | 2.5h | 85% | 類圖改進、功能模塊層次圖、評審表 | 8.24% |
| 221600329 | supermingjun | 10h+1h | 95% | 任務安排、數據流圖、類圖改進、文檔審核&整合、博文撰寫、PPT制作、答辯 | 25.88% |
附:第四次團隊作業答辯——反思與總結
點擊鏈接查看
轉載于:https://www.cnblogs.com/onlineservice666/p/10708099.html
總結
以上是生活随笔為你收集整理的团队作业第五次—项目系统设计与数据库设计的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 一个奇鸽船新体验:类似的木函软件
- 下一篇: 单词系统文档