勤工助学管理系统.doc

附件1：学 号： 2012131113课 程 设 计题 目实验室勤工俭学管理系统学 院计信学院专 业金融信息化班 级1班学生姓名蒋汉指导教师张世勇2012年6月24日重庆工商大学课程设计成绩评定表学院：计信学院 班级：金信1班 学生姓名：蒋汉 学号：2012131113项目分值优秀(100x90)良好(90x80)中等(80x70)及格(70x60)不及格(x60)评分参考标准参考标准参考标准参考标准参考标准学习态度15学习态度认真，科学作风严谨，严格保证设计时间并按任务书中规定的进度开展各项工作学习态度比较认真，科学作风良好，能按期圆满完成任务书规定的任务学习态度尚好，遵守组织纪律，基本保证设计时间，按期完成各项工作学习态度尚可，能遵守组织纪律，能按期完成任务学习马虎，纪律涣散，工作作风不严谨,不能保证设计时间和进度技术水平与实际能力25设计合理、理论分析与计算正确，实验数据准确，有很强的实际动手能力、经济分析能力和计算机应用能力，文献查阅能力强、引用合理、调查调研非常合理、可信设计合理、理论分析与计算正确，实验数据比较准确，有较强的实际动手能力、经济分析能力和计算机应用能力，文献引用、调查调研比较合理、可信设计合理，理论分析与计算基本正确，实验数据比较准确，有一定的实际动手能力，主要文献引用、调查调研比较可信设计基本合理，理论分析与计算无大错，实验数据无大错设计不合理，理论分析与计算有原则错误，实验数据不可靠，实际动手能力差，文献引用、调查调研有较大的问题创新10有重大改进或独特见解，有一定实用价值有较大改进或新颖的见解，实用性尚可有一定改进或新的见解有一定见解观念陈旧论文(计算书、图纸)撰写质量50结构严谨，逻辑性强，层次清晰，语言准确，文字流畅，完全符合规范化要求，书写工整或用计算机打印成文；图纸非常工整、清晰结构合理，符合逻辑，文章层次分明，语言准确，文字流畅，符合规范化要求，书写工整或用计算机打印成文；图纸工整、清晰结构合理，层次较为分明，文理通顺，基本达到规范化要求，书写比较工整；图纸比较工整、清晰结构基本合理，逻辑基本清楚，文字尚通顺，勉强达到规范化要求；图纸比较工整内容空泛，结构混乱，文字表达不清，错别字较多，达不到规范化要求；图纸不工整或不清晰指导教师评定成绩： 2014年 6月 24日目 录1 需求分析11.1系统目标11.2业务需求及处理流程11.3功能需求及数据需求分析31.4业务规则分析42 概念设计52.1命名规范52.2 实体集及属性62.3 联系集及属性82.4 系统总ER图83 逻辑设计103.1 数据字典设计103.2 基本数据设计113.3 业务数据设计143.4 其它数据设计153.5 视图设计153.6 触发器设计163.7 存储过程设计164 模式求精174.1 存在的问题174.2 解决方案175 物理设计185.1 设计目标185.2 数据分布185.3 索引实现196 安全设计206.1 设计目标206.2 用户设计206.3 权限设计207 总结.228 附录1 数据库脚本239 附录2 触发器与存储过程301 需求分析1.1 系统目标随着网络技术的发展和计算机的日益普及，数据库的应用范围越来越广泛，数据库应用的功能也越来越强大，在强调管理，强调信息的现代社会中它变得越来越普及。计算机技术的飞速发展，数据库技术作为数据管理的一个有效的手段，在各行各业中得到越来越广泛的应用。该程序在设计过程中严格遵循软件工程学的方法，用分阶段的生命周期计划严格管理，并主要讲述了程序的总体设计、详细设计阶段，对程序进行需求迭代，不断修正和改进，利用SQL SERVER 2000的强大数据库功能，直到形成一个完善的可行性系统和优美、秀丽的界面，方便实用的查询与维护功能共同构成了“勤工助学管理系统”。勤工助学是任何一所高校都需要进行的一项工作。因此，开发制作勤工助学管理系统具有较大的社会现实意义。勤工助学管理系统是以Web作为交流平台。系统管理员将工作的基本信息发布到网站上，所有用户都可查询工作信息，但只有会员才能申请工作并接受工作，获得工作，以使会员实现学习和工作的二者兼得，减轻家庭负担。该勤工助学管理系统支持3类用户：游客、会员、管理员。游客可以随意浏览管理员发布的工作信息，但是只有在注册为网站会员之后才能申请工作及接受工作。会员登录系统后，可进行的主要操作有：通过不同方式查询工作信息、申请工作、确认工作、发布留言等。系统管理员登陆后，可进行的操作有：维护会员的信息、维护与发布工作信息、处理工作申请、回复留言等。1.2 业务需求及处理流程开发勤工助学管理系统的目的主要是为了帮助高校勤工部门提高工作效率，同时满足部分企业用人需求，增加在校学生的社会实践活动并达到减轻家庭负担的目的，实现高校勤工助学管理的系统化、规范化和自动化。故系统最终实现的主要功能如下：(1) 主要业务包括：工作信息的发布与查询、分配与接受新的工作、工作记录、计算工资、发布或回复留言等。(2) 工作的相关信息由管理员发布，所有学生会员都可以查找和接受工作。因此，工作的分派是非常方便的。在完成工作之后，可以浏览工作记录，工作记录包括工作信息以及工资等。同时，会员可以发布留言，这样可以及时地提高服务的质量。另外，学校之外的一些公司、机构也能够发布工作信息，但这些工作是不能分派给会员的。主要业务的处理流程如下：(1) 勤工助学管理系统功能如图1-1所示：图1-1 勤工助学管理系统功能模块(2) 管理员和学生会员的主要操作流程如图1-2所示： 图1-2 勤工助学管理系统的主要业务流程1.3 功能需求及数据需求分析勤工助学管理系统的主要功能和数据需求包括：(1) 会员注册管理学生会员（即申请工作的对象）注册。学生会员注册时要求填写基本信息，包括姓名、学号、密码、性别、专业、班级、地址、电话、空闲时间、银行卡号等信息。公司会员（即提供工作的对象）注册。公司会员注册时要求填写基本信息，包括公司名称、公司法人姓名、密码、地址、电话、电子邮箱等信息。系统检查所有信息填写正确后提示会员注册成功，并返回会员编号。(2) 工作信息管理增加工作信息。当公司会员有新工作发布时，管理员负责添加和发布工作信息，包括提供工作的公司会员编号、工作内容、工作时间、工作地点、工资以及所需人数等。工作信息查询。所有人都可以查询管理员发布的工作信息及工作内容，但只有学生会员才能接受工作，并查询到自己的工作任务。工作信息的更新与删除。工作信息发布后，管理员可随时更新和删除工作信息。工作分配。管理员按照学生会员注册时填写的空闲时间来分配工作。但只有当会员确认之后才可以开始工作。接收工作。当会员登录到界面之后，可以查询自己的工作信息并及时地接收工作，否则，将被视为放弃该工作。(3) 工作单管理工作单查询。学生会员确认工作后，会生成工作单。会员可随时查询工作单的最新状态以及全部历史记录。工作单受理。工作单生成之后，管理员对订单进行审核。如发现工作单信息不正确，则返回会员重新填写。如正确无误，则可通知学生会员开始工作。(4) 用户管理会员信息维护。会员可修改、删除和更新自己的信息，管理员可修改、删除和更新所有会员的信息。会员等级。系统可对学生会员进行分级，即根据会员接受工作的次数来划分等级。(5) 留言管理发布留言。会员可在网站发表留言或者评论。留言需记录留言人、留言内容、发布时间等信息。回复留言。管理员可回复留言，并记录回复人和回复时间及回复内容。1.4 业务规则分析(1) 所有用户都可以浏览管理员发布的工作信息，但是只有会员才能申请工作及接受工作。(2) 只有会员可以申请工作。如果用户想申请工作，则必须注册成为会员。管理员会核查用户的信息，如果符合条件，用户将成为正式会员。(3) 每位会员由会员编号唯一标识，会员编号由系统按时间顺序自动生成。(4) 每份工作由工作编号唯一标识，工作编号由系统按时间顺序自动生成。(5) 只有管理员可以修改、更新和删除由学校或者学校外部提供的工作的相关信息。(6) 只有管理员可以分配工作。(7) 工作被分为可分配工作和不可分配工作。可分配工作主要包括学校提供的工作；不可分配工作主要包括一些社会团体、组织等提供的工作(8) 管理员根据会员的工作次数来分配工作。如果会员没有在规定的时间内确认招聘信息，管理员将认为该会员放弃该工作并将其重新分配。(9) 只有在会员确认工作信息之后才会生成工作单。在订单受理之前，会员可以修改相关信息甚至取消该工作单。但是订单深刻通过之后，则不允许再做任何修改。(10) 每个工作单用工作单编号唯一标识。工作单编号由系统按时间顺序生成，后生成的工作单具有更大的编号。(11) 当工作完成后，则更新该工作单的状态更新为“已完成”。(12) 员工可对工资发放提出意见。单位可根据自身实际的情况进行相应的调整。(13) 在工作完成后，管理员将根据工作反馈记录会员的工作情况，同时，管理员需要完成工作记录表和工资表。(14) 学生会员的等级分为3类：正常；警告，即如果学生会员没有在规定的时间确认工作的次数超过3次，则对其发出警告；黑名单，即如果学生会员没有在规定的时间确认工作的次数超过5次，系统会自动注销其会员资格，当其再次进行注册时，会谨慎考虑其注册资格。(15) 所有用户都可以发布留言，一个用户可发表多条留言，一个管理员可回复多条留言。2 概念设计2.1 命名规范在数据库的设计中，尽量不用汉字，最好用英文。(1) 实体集和联系的命名规则实体集和联系均以其对应的英文单词命名，且单词首字母要大写。例如：实体集管理员(Admin)、学生会员(Student)、公司会员(Company)、工作(Job)、留言(Message)、分派(Assign)、确认(Confirm)以及提供(Provide)等。(2) 属性的命名规则 若属性由简单词组成，则直接以其对应的英文单词命名，单词首字母小写。例如：出生年月(birthday)、住址(address)、电话(telephone)、薪水(salary)、邮箱(e-mail)以及银行卡号(bankcard)等。 若属性由复合词组成，则采用小驼峰法来命名，即混合使用大小写字母来构成属性的名字，属性名的每一个逻辑断点都由一个大写字母来标记。如果名字过长，可采用英文简写。例如：管理员姓名(adminName)、学号(studentNo)、密码(stuPassword)以及缺席次数(absenceNum)等。(3) 具体的编码规则如下： 管理员编号(adminNo)的编码规则：以字母A开头加3位数字组成，如A001； 学号(studentNo)的编码规则：以江西财经大学学生学号入库，如0082782； 公司编号(companyNo)的编码规则：以字母C开头加4位数字组成，如C0001； 工作编号(jobNo)的编码规则：以字母J开头加7位数字组成，数字部分前4位为公司编号的数字部分，如J0001005； 意向编号(willNo)的编码规则：以字母W开头加上学号组成，如W0082782； 工作单编号(orderNo)的编码规则：以11位数字组成，前8位为工作单生成的日期，如20101224001； 类别编号(sortNo)的编码规则：以字母S开头加3位数字，如S001； 留言编号(messageNo)的编码规则：以字母M开头加6位数字组成，如M000001； 工作单状态(bookState)的编码规则：取值0，1，2。0代表正在进行中，1代表工作已完成，2代表工资已结算。2.2 实体集及属性(1) 管理员(Admin)实体集。其属性有管理员编号(adminNo)、登录密码(adminPassword)、管理员姓名(adminName)、性别(sex)、出生年月(birthday)、住址(address)、电话(telephone)、薪水(salary)以及邮箱(e-mail)等。其E-R图如图2-1所示。图2-1 管理员实体集的E-R图(2) 学生会员(Student)实体集。其属性有：学号(studentNo)、姓名(studentName)、密码(stuPassword)、性别(sex)、出生年月(birthday)、专业(professional)、班级(class)、宿舍(dormitory)、电话(telephone)、邮箱(e-mail)、空闲时间(freetime)、缺席次数(absenceNum)、会员等级(level) 工资(salary)以及银行卡号(bankcard)等。其E-R图如图2-2所示。图2-2 学生会员实体集的E-R图(3) 公司会员(Company)实体集。其属性有：公司编号(companyNo)、公司名称(companyName)、公司法人姓名(legal)、登陆密码(comPassword)、地址(address)、电话(telephone)以及电子邮箱(e-mail)等。其E-R图如图2-3所示。图2-3 公司会员实体集的E-R图(4) 工作(Job)实体集。其属性有：工作编号(jobNo)、工作名称(jobName)、工作属性(jobProperty)、工作类别(sortNo)、工作信息(jobInfo)、所需人数(personNeed)、开始时间(startime)、截止时间(deadline)、工资(salary)以及公司编号(companyNo)。其E-R图如图2-4所示。图2-4 工作实体集的E-R图(5) 留言(Message)实体集。其属性有：留言编号(messageNo)、内容(messageContent)以及发布时间(releaseDate)等。注意，留言人和回复人等信息要通过建立会员与留言、管理员与留言之间的联系解决。其E-R图如图2-5所示。图2-5留言实体集的E-R图(6) 工作意向(Jobwill)实体集。其属性有：意向编号(willNo)、学号(studentNo)、工作类别(sortNo)、开始时间(startTime)、结束时间(endTime)、备注(note)以及期望工资(salaryWant)。其E-R图如图2-6所示。图2-6 留言实体集的E-R图2.3 联系集及属性基于2.2节设计得到的实体集，可确定如下联系集：(1) 管理员与工作之间的“分派(Assign)”联系集。它是一个多对多联系，其描述属性是：分派日期(assignDate)。(2) 学生会员与工作之间的“确认(Confirm) ”联系集。它是一个多对多联系，因为学生会员在确认工作信息后会自动生成工作单，其描述属性是：工作单编号(orderNo)、确认时间(confirmTime)、完成时间(completeTime)、工作单状态(orderState)。(3) 公司会员与工作之间的“提供(Provide)”联系集。它是一个一对多联系集，其描述属性是：提供日期(provideDate)。(4) 学生会员与工作意向之间的“提交(Submit)”联系集。它是一个一对一联系集, 其描述属性是：提交日期(submitDate)。(5) 会员与留言之间的“发布(Release)”联系集。它是一对多联系，其描述属性是：发布日期(releaseDate)。(6) 管理员与留言之间的“回复(Reply)”联系集。它是一对多联系，其描述属性是：回复日期(replyDate)和回复内容(replyContent)。 2.4 系统总ER图根据2.2与2.3节设计的全部实体集、联系集及其描述属性，得到系统总ER图。如图2-7所示。图2-7系统的总E-R图3 逻辑设计3.1 数据字典设计重庆工商大学勤工助学管理系统中的一些数据的组织结构基本上是一致的，并且在客户界面通常以下拉列表框、列表框和网格形式出现，因此，为了便于管理和查询，设计了该系统的数据字典。(1) 性别字典(DCsex)，如表3-1所示。表3-1 性别字典属性名称属性类型是否允许为空默认值约束含义sexNochar(1)NOT NULL性别编号sexNamechar(2)NOT NULL性别描述(2) 专业字典(DC professional)，如表3-2所示。表3-2 专业字典属性名称属性类型是否允许为空默认值约束含义professionalNochar(5)NOT NULL专业编号professionalNamevarchar(30)NULL专业名称(3) 班级字典(DCclass)，如表3-3所示。表3-3 班级字典属性名称属性类型是否允许为空默认值约束含义classNochar(3)NOT NULL班级编号classNamevarchar(30)NULL班级名称(4) 宿舍字典(DCdormitory)，如表3-4所示。表3-4 宿舍字典属性名称属性类型是否允许为空默认值约束含义dormitoryNochar(3)NOT NULL宿舍编号dormitoryNamechar(20)NOT NULL宿舍名称(5) 缺勤次数字典(DCabsenceNum)，如表3-5所示。表3-5 缺勤次数字典属性名称属性类型是否允许为空默认值约束含义absenceNumNochar(1)NOT NULL缺勤次数编号absenceNumNamechar(10)NOT NULL缺勤次数描述(6) 会员等级字典(DClevel)，如表3-6所示。表3-6 会员等级字典属性名称属性类型是否允许为空默认值约束含义levelNochar(1)NOT NULL会员等级编号levelNamechar(10)NOT NULL会员等级描述(7) 工作属性字典(DCjobProperty)，如表3-7所示。表3-7 工作属性字典属性名称属性类型是否允许为空默认值约束含义jobPropertyNochar(1)NOT NULL1工作属性编号jobPropertyNamechar(10)NOT NULL可分配工作属性描述IfVoidNumber(1)NOT NULL1只能取0和1是否可分配(8) 工作单状态字典(DCorderState) ,如表3-8。表3-8 工作单状态字典属性名称属性类型是否允许为空默认值约束含义orderStateNochar(1)NOT NULL0订单状态编号orderStateNamevarchar(30)NOT NULL未完成订单状态描述IfVoidNumber(1)NOT NULL0只能取0和1是否作废(9) 语言种类字典(DClanguage) ,如表3-9。表3-9 语言种类字典属性名称属性类型是否允许为空默认值约束含义languageNochar(3)NOT NULL001语言种类编号languageNamevarchar(30)NULL中文语言种类描述3.2 基本数据设计重庆工商大学勤工助学管理系统的基本数据主要是由本系统数据库的实体集构成，它将具有相同类型及相同性质的实体集合在一起，便于管理和查询等操作。根据之前的实体集和联系集的定义，该系统的基本数据由以下6个部分构成。(1) 管理员(Admin)表：由管理员(Admin)强实体集转化而来，如表3-10所示。表3-10 管理员表 Admin属性名称数据类型是否允许为空是否为主外键属性描述adminNochar(4)Not nullprimary key管理员编号adminPasswordchar(6)Not null登陆密码adminNamevarchar(10)Not null管理员姓名sexchar(1)Not null性别birthdaydatetimeNull出生年月addressvarchar(50)Null住址telephonechar(11)Null电话salarynumeric(8,2)Not null工资e-mailchar(30)Null邮箱(2) 会员(Student)表：由学生会员(Student)强实体集转化而来，如表3-11所示。表3-11 学生会员表 Student属性名称数据类型是否允许为空是否为主外键属性描述studentNochar(7)Not nullprimary key学号studentNamevarchar(10)Not null姓名stuPasswordchar(6)Not null登陆密码sexchar(1) Not null性别birthdaydatetime Not null出生年月professionalchar(40) Not null专业classvarchar(20)Not null班级dormitoryvarchar(50)Null宿舍telephonechar(11) Not null电话e-mailvarchar(30) Null电子邮箱freetimedatetimeNull空闲时间absenceNumint Not null缺勤次数levelintNot null等级salarynumeric(8,2)Not null工资bankcardchar(19)Not null银行卡号(3) 公司会员(Company)表：由公司会员(Company)强实体集转化而来，如表3-12所示。表3-12 公司会员表 Company属性名称数据类型是否允许为空是否为主外键属性描述companyNochar(5)Not nullprimary key公司编号companyNamevarchar(20) Not null公司名称legalvarchar(10)Not null法人姓名comPasswordchar(6) Not null登陆密码addressvarchar(20) Not null地址telephonechar(12) Not null电话e-mailchar(30)Not null电子邮箱(4) 工作(Job)表：由工作(Job)强实体集和提供(Provide)联系集共同转化而来，如表3-13所示。由于联系集提供(Provide)为一对多联系，故可合并到工作(Job)表中来。表3-13 工作表 Job属性名称数据类型是否允许为空是否为主外键属性描述jobNochar(8)Not nullprimary key工作编号jobNamevarchar(20) Not null工作名称jobPropertyvarchar(20)Not null工作属性sortNochar(4)Not nullforeign key references jobSort工作类别jobInfovarchar(100)Null工作信息personNeedint Null所需人数startTimedatetime Not null开始时间deadlinedatetime Null截止时间属性名称数据类型是否允许为空是否为主外键属性描述salarynumeric(8,2)Null工资（小时）companyNochar(5)Not nullforeign key reference Company公司编号provideDatedatetimeNot null提供时间(5) 留言(Message)表：由留言(Message)强实体集和发布(Release)和回复(Reply)两个联系集共同转化而来，如表3-14所示。由于联系集发布(Release)和回复(Reply)都是一对多联系，故可合并到留言(Message)表中来。表3-14 留言表 Message属性名称数据类型是否允许为空是否为主外键属性描述messageNochar(7)Not nullprimary key留言编号adminNochar(4)Not nullforeign key reference Admin管理员编号studentNochar(7) Not nullforeign key reference Student学号releaseDatedatetime Not null发布日期messageContentvarchar(100) Null留言内容replyContentvarchar(100)Null回复内容replyDatedatetime Not null回复日期(6) 工作意向(Workwill)表：由工作意向(Workwill)和提交(Submit)联系集共同转化而来，如表3-15所示。由于联系集提交(Submit)为一对一联系，故可合并到工作意向(Workwill)表中来。表3-15 工作意向表 Workwill属性名称数据类型是否允许为空 是否为主外键属性描述willNochar(8)Not nullprimary key意向编号studentNochar(7)Not nullforeign key reference Student学号sortNochar(4)Not nullforeign key references Sort工作类别starTimedatetime Not null开始时间endTimedatetime Not null结束时间notechar(100) Null备注salarywantnumeric(8,2)Null预期工资submitDatedatetimeNot null提交时间另外，为了满足系统需求，还设计两种基本数据，即空闲时间(freetime)和工作类别(jobSort)。(1) 空闲时间(freetime)表，如表3-16所示。表3-16空闲时间表 freetime属性名称数据类型是否允许为空 是否为主外键属性描述studentNochar(7)Not nullprimary keyforeign key reference Student学号startTimedatetime Not nullprimary key开始时间endTimedatetime Not nullprimary key结束时间(2) 工作类别(jobSort)表：如表3-17所示。表3-17 工作类别表 jobSort属性名称数据类型是否允许为空 是否为主外键属性描述sortNochar(4)Not nullprimary key类比编号sortNamevarchar(20) Null类别名称3.3 业务数据设计重庆工商大学勤工助学管理系统其他数据主要是联系各个实体集之间的联系集，它是多个实体之间的某种行为需要的反映。本系统涉及的联系集如表3-18所示。表3-18 联系集相互关系的实体集联系集的名称管理员与工作分派(Assign)学生会员与工作确认(Confirm)公司会员与工作提供(Provide)学生会员与工作意向提交(Submit)会员与留言发布(Release)管理员与留言回复(Reply)在上述联系中，联系集分派(Assign)和确认(Confirm)均为多对多联系，不能与任一实体集合并，故单独建表。(1) 分派(Assign)表：由分派(Assign)联系集转化而来，如表3-19所示。表3-19 分派表 Assign属性名称数据类型是否允许为空 是否为主外键属性描述adminNochar(4)Not nullprimary keyforeign key references admin管理员编号studentNochar(7)Not nullprimary keyforeign key references member学号jobNo char(8)Not nullprimary keyforeign key references job工作编号assignDatedatetimeNot null分派时间(2) 确认(Confirm)表：由确认(Confirm)联系集转化而来，如表3-20所示。表3-20 确认表 Confirm属性名称数据类型是否允许为空 是否为主外键属性描述orderNochar(11)Not nullprimary key工作单编号jobNochar(8)Not nullprimary keyforeign key references Job工作编号studentNochar(7)Not nullprimary keyforeign key references Student学号属性名称数据类型是否允许为空 是否为主外键属性描述confirmTimedatetimeNull确认时间completeTimedatetimeNull完成时间orderStatechar(1)Not null工作单状态3.4 其它数据设计(1) 设计审计表：以学生会员的操作为例，建立一张跟踪(TraceStudent)表。当管理员向学生会员表中插入或删除一天记录以及学生会员完成提交工作意向、确认工作信息等操作时，该操作的名称和操作时间就会被记录在跟踪表中，以便追踪。(2) 快速汉字输入法：在该系统中为工作名称设计拼音表和五笔表，提供更方便的汉字输入。(3) 月度工作单统计总表(MonthOrder)，用于统计某个月份的工作单和工作单金额，如表3-21。表3-21月度订单统计总表字段名称数据类型是否允许为空 是否为主外键属性描述MOrderNochar(10)Not nullprimary key订单统计表编号startimedatetimeNot null起始日期endtimedatetimeNot null截止日期MordernumericNull月度工作单数量MOrderSumnumericNull月度总金额3.5 视图设计视图是虚表，其作用是方便数据库的用户进行查询操作。江西财经大学勤工助学管理系统的视图设计如下。(1) 创建工作视图JobView。规定管理员可通过该视图查询、更新和删除工作的基本信息，网站的会员以游客可以通过查询该视图得到关于工作的所有信息，便于他们做出选择。(2) 创建工作单视图OrderView。规定管理员可通过该视图查询会员的工作记录，以便其更高效的分配工作；学生会员则可通过该视图查询自己的工作记录，包括工作日期、工作次数以及所获得的工资等。(3) 创建留言视图MessageView。规定管理员可以一次性看到多条留言，便于回复，而会员以及游客查询时可以看到其他会员对于某份工作的评价，为自己选择工作提供参考。3.6 触发器设计触发器是用户定义在关系表上的一类由事件驱动的存储过程，由服务器自动激活。触发器可以进行更为复杂的检查和操作，具有更精细和更强大额数据控制能力。重庆工商大学勤工助学管理系统的触发器要实现的目标主要是与Insert, Update, Delete操作有关的。(1) 创建插入触发器studentIns，当管理员向学生(Student)表中插入一条新的工作信息时，触发器就会自动地将该操作着的名称和操作时间记录在一张表中，以便追踪。(2) 创建更新触发器jobUpd，当管理员要修改工作(Job)表中的工作编号时，会自动工作单即确认(Confirm)表中的工作编号，确保了高效率。(3) 创建删除触发器studentDel，当某学生会员的缺勤次数超过5次时，系统会自动注销其会员资格，并删除该学生会员在学生会员(Student)表中的信息。3.7 存储过程设计存储过程设计主要包括数据库中管理员的操作，对会员的操作以及所有人都可以进行的一些查询操作。(1) 创建存储过程proAdmin，输入某管理员的编号，统计该管理员分派工作的信息，并返回学号、工作编号以及工作类别。(2) 创建存储过程proStudent，输入某学生的姓名，统计该学生的工资，并返回该同学的学号、缺勤次数及会员等级。(3) 创建存储过程proCompany，输入某公司编号，统计该公司提供工作的信息，并返回工作编号、工作名称、所需人数以及工资。4 模式求精4.1 存在的问题分析了用户的需求后，可以发现学生会员(Student)关系模式中存在一个对非属性的函数依赖关系：levelabsenceNum，由此导致的问题是数据冗余，即每一个相同等级的会员都要存放absenceNum信息。该模式不满足BCNF范式。因此，需要对学生会员(Student)实体集进行分解。4.2 解决方案针对上述存在的问题，给出如下解决方案。基于数据冗余，需要对学生会员(Student)实体集进行分解。依据BCNF分解算法，学生会员(Student)可以分解成如下两个关系模式：Student (studentNo, stuPassword, studentName, sex, birthday, professional, class, dormitory, telephone, e-mail, freetime, salary, bankcard, level)Level (level, absenceNum)可以验证，关系模式Student和Level都满足BCNF要求，且分解是无损分解。5 物理设计5.1 设计目标由于数据库最终都是要存储在物理设备上的，因此，在充分了解了给定的DBMS和硬件系统的前提下，物理设计就是要为一个给定的逻辑数据模型选取一个最适合应用环境的物理结构的过程。那么，主要的设计目标是：(1) 提高数据库的性能，以满足应用的性能需求；(2) 有效利用存储空间，合理存放易变部分、稳定部分、经常存取部分和存取频率较低部分的数据；(3) 综合考虑存取时间、存储空间利用率和维护代价三方面的因素，在三者之间找到一个权衡点。5.2 数据分布数据分布主要是确定数据的存放位置和存储结构，包括确定关系表、索引、数据字典、日志和备份文件等的存储结构和存放位置。首先，要确保数据存放位置的基本原则：根据应用情况将易变部分与稳定部分、存取频率较高部分与存取频率较低部分分开存放，以提高系统性能。其次，确定数据库物理结构的内容：(1) 确定数据存放位置 为提高系统性能，数据应根据应用情况将易变部分和稳定部分、经常存取部分和存取频率较低部分分开来存放。(2) 确定数据库存储结构影响数据存放位置和存储结构的因素除了硬件环境外，还包括存取时间、存储空间利用率和维护代价三个方面的因素。这三个方面常常是相互矛盾的，比如说消除一切冗余数据虽能够节约存储空间和减少维护代价，但往往会导致检索代价的增加，因此必须将它们综合考虑，权衡利弊，选择一个折中方案。最后，综合考虑得到该数据库的数据分布：(1) 数据库数据备份、日志文件备份等由于只在故障恢复时才使用，而且数据量很大，可以考虑存放在磁带上。(2) 由于目前许多计算机都有多个磁盘， 因此把不需要怎么变动的数据字典存储在D盘上；而各关系表即前面所提到的基本数据和业务数据，索引和日志存放在E盘上。5.3 索引实现本系统采用的索引是采用树索引存储结构，它可以在数据插入和删除的情况下仍能保持较好的执行效率。由于管理员、会员或者游客在查询各类信息时，往往会按照某个搜索码进行查询。所以，应建立文件的树索引，使其在物理上按搜索码存储。树索引的一般规则是：(1) 如果一个(或一组)属性经常在查询条件中出现，则考虑在这个(或这组)属性上建立索引(或组合索引)；(2) 如果一个属性经常作为最大值和最小值等聚集函数的参数，则考虑在这个属性上建立索引；(3) 如果一个(或一组)属性经常在连接操作的连接条件中出现，则考虑在这个(或这组)属性上建立索引。因此，我们考虑到该数据库中查询最多的应该是工作信息，且查询条件多为工作类别，故以工作类别为搜索码建立索引，把工作类别在逻辑上按顺序存储。另外，查询工作类别时，希望得到的信息是具体有关的信息，这时候就需要工作类别编号作为连接条件，将工作类别(jobSort)表与工作(Job)表进行连接，所以还需在工作类别编号上建立索引。具体索引实现如图5-1所示。图5-1 jobSort文件与Job文件的树索引的叶结点结构6 安全设计6.1 设计目标重庆工商大学勤工助学管理系统的设计目标是防止不合法的使用所造成的数据泄密、更改或破坏，因为数据库中的数据资源是共享资源，因此必须在数据库系统中建立一套完整的使用规则进行数据库保护。那么就是让被授权的用户访问数据库的相应部分，提高对数据库的安全保护，前提是所有被授权的用户在访问数据库之前都要通过身份验证。数据库的创建者即管理员可以通过自己设定的账号和密码的认证进入数据，并且可以修改变动的新信息，做到时刻更新数据库，为数据库的访问者提供及时的消息，为他们的准确决策提供方便。如当机场的航班的起飞时间做了调整时，这时候数据库的创建者就要进入数据库去改动相应的时间信息等。数据库的访问者，可以通过注册成为会员，其中，更具会员身份的不同，分为学生会员和公司会员。当会员要再次访问时，需通过身份认证进入才能对数据库中的某些客体进行访问。如会员能查看他们各自注册时填写的主要信息，并且可以不断完善自己的所有信息，但是会员看不到其他会员的信息，会员可以发布留言等；而管理员可以查看所有的会员的信息，也可以回复各个会员的留言等。6.2 用户设计重庆工商大学勤工助学管理系统面向的用户主要分为三类。第一类是数据库的管理员，通过相应的身份认证后进入数据库，主要的任务就是及时修改数据库中需要改动的新消息并为学生会员分派工作等；第二类是会员，分为学生会员和公司会员两类，同样都需要通过相应的身份认证。学生会员主要是查询工作的相关信息、申请工作、确认工作等；公司会员主要是查询工作的相关信息以及提供工作。第三类是游客，