高校人事管理系统数据库设计.docx

《高校人事管理系统数据库设计.docx》由会员分享，可在线阅读，更多相关《高校人事管理系统数据库设计.docx（37页珍藏版）》请在三一办公上搜索。

1、 某某大学计算机与信息技术学院数据库系统课程设计论文题 目：高校人事管理系统数据库设计组 长 专 业 计算机科学与技术 班 级 授课教师 高校人事管理系统数据库设计 内容提要 高校人事管理系统包括人事档案信息录入、人事档案信息显示及人事信息查询等。系统开发采用了C+，有开发效率高，调试容易，维护方便等优点。实现了显示信息分页，组合查询等方便用户的功能，提高了高校人事管理的效率。目前软件市场有很多人事管理系统软件，有的功能强大，适合管理大型的集团型企业，有的功能单一，适合管理小型企业。针对高校的人事管理软件却没有通用的商业软件。因为高校的人事管理有其特殊性，每个院校之间的差别很大，管理方法存在很

2、大差别。市场化的通用商品软件很难满足所有高校的人事管理需求。高校的人事管理软件均采用定制化开发，根据本校的实际情况，开发切合本校实际的管理程序。在设计时我们根据E-R图的类型和一些实际需求转化为相应的关系模型，并通过分析关系模型中依赖关系，对关系模型进行了优化，同时根据确切需求分析各个关系模式所属范式和优化原因。最终确定了在数据库中存储所用的关系模式，定义了基本表和视图模式，确定了系统功能模块图，得到了数据库的关系图。根据以上得到的结果，构建出符合要求的数据库，通过物理设计将逻辑模型转化为物理模型，确定了存储结构和建立的索引以及功能模块。利用C+平台使数据库与程序相结合构成了具有相应功能的系统

3、。关键字：数据库；E-R图；数据流图；高校人事管理；系统设计；系统实现目 录1 引言32 需求分析阶段32.1 引言32.2 需求分析阶段的目标与任务32.3 需求分析阶段成果53.1 引言143.2 任务与目标144逻辑设计阶段174.1逻辑设计的任务和目标174.2数据组织174.2.1将E-R图转换为关系模型174.2.3数据库模式定义一八4.2.4 用户子模式定义204.3数据处理214.4数据库关系图225物理设计阶段225.1物理设计阶段的目标与任务225.2数据存储方面225.3教师/主任基本信息的查询和更新模块236数据库实施阶段236.1建立数据库、数据表、视图、索引236.

4、1.1 建立数据库236.1.2 建立数据表236.1.3 建立视图256.1.4 建立索引256.1.5 建立触发器266.2数据入库266.3创建各个功能的存储过程26七、应用设计：26八系统调试和测试29九、存在问题：30十、各学生贡献说明：30参考文献31附录1 存储过程定义31附录2 程序源代码（嵌入式SQL某模块读与写操作）32附录3 所有的SQL运行语句34341 引言随着信息技术的快速发展，数字化校园是高校教育信息化发展的必然趋势，也是未来 学校发展的必然方向。一个高校人事管理信息系统的好坏直接影响着教师的各类活动，从而影响着整个高校的教学、办学水平，所以一个高效的人事管理信息

5、系统对整个高校的发展起着至关重要的作用。这就是选用此作为设计课题的原因。设计过程按照数据库设计方式从需求分析、概念模型建立、逻辑设计、物理设计、数据库实现、系统实现几个阶段一步一步完成了设计的任务。2 需求分析阶段2.1 引言高校人事管理信息系统属于数字化校园应用支撑系统中比较重要的一环，其面向对象主要 是高校中的教师、管理人员和服务人员，其中教师是主体，管理人员是关键，所以高校的人事管理是以教师为主体对象的一种团体、社会活动。高校人事管理系统平台需要完成基本查询的功能，以及管理员，学生，部门主任三方之间的信息交互。经过调查需求，对三方所需的需要进行分析：管理员需要注册教师，学生，完成对学生教

6、师的信息的修改查询，以及对某些特定要求可以实现数据的统计功能，管理员还可以根据一些规定删除某些学生或教师的信息；教师端可以实现对自己工资详单的查询，可以实现对自己的某些个人信息进行修改；部门主任可以对教师信息进行查询以及对个人信息的修改 为了完成上述的需求，将系统基本分为三个子系统：管理员端，教师端，部门主任端根据身份验证获得不同的权限，以不同的方式来访问同一个数据库。主要功能有：1. 管理员端：主要能实现对学生教师的增删改查以及统计。2. 教师端：能浏览自己的工资和其他个人信息，还可以进行修改。3. 部门主任端：可以对教师信息进行修改统计。2.2 需求分析阶段的目标与任务2.2.1处理对象1

7、. 管理员信息：用户名，密码，公告2. 教师信息：教师姓名、教师性别、教师身份证号、密码、教师学历、教师职务、职称、家庭住址、教师密码、部门编号、出生年月、所在部门、用户身份、工资3. 教师工资信息：教工编号、职称、职务、加班工资、考勤工资、基本工资、总工资、时间、教师姓名 首先从需求分析阶段中，确定了几项基本的处理对象，有可能这些处理对象不完全，需要在后续的各个阶段中不断修改和完善。2.2.2处理功能及要求1.管理员端的处理功能1）用户管理1、添加用户2、修改密码3、删除用户2） 部门管理 1、 查询部门信息2、 修改部门公告3、 增加部门类型4、 删除部门5、 统计部门信息3） 职工管理1

8、、 修改通知信息2、 职工测评3、 修改查询教师信息2.部门主任功能1）查看系统公告2）查看本部门成员3）修改个人资料 1、修改职工信息 2、修改自己信息4）查询员工考勤管理 1、修改员工考勤 2、查询员工考勤 3、删除员工考勤5）管理员工工资 1、合计员工工资 2、查询员工工资6）员工奖惩管理3职工功能1） 查看通知2） 申请病假3） 修改个人信息4） 查看个人工资4.能够提供一定的安全机制，提供数据信息授权访问，防止随意删改、查询。5.系统界面要友好，系统的健壮性要强，后台要稳定。2.2.3.安全性和完整性要求1） 安全性要求 系统的安全性也是一个需要重点考虑的问题。人事管理系统中保存了很

9、多敏感的信息，如教师的基本情况等。非授权用户不可查询、更改或删除。本系统所采用的方法是首先在进人系统时检查用户名和口令，因此非系统用户很难进入系统。即使能够进入系统，所有的涉及数据增加、更改和删除的地方都需要进行权限确认以保证操作合法进行。当然，数据库本身是加了密的，非法用户很难打开数据库而直接进行修改。而关于用户名与口令的信息则经过一定的算法加密后保存在数据库中。系统的安全性得到了较好的保证。2） 完整性要求系统完整性要求系统中数据的正确性以及相容性。可通过建立主、外键，确定了每个表中的主码，主码唯一，以及一个表与其他表相关联的外码；对于一些等级属性和一些确定取值范围的属性使用check约束

10、；还有一些标志变量，取值范围为0或1代表的意义不同，可以通过使用触发器来实现；以及要做到视图级联更新；有的值不能为空，若为空则没有意义整个元组不完整，则需要表示Not null通过定义实体完整性、参照完整性、用户定义完整性使其满足完整性要求。利用触发器可以对给出等级的限制，将超出的部分变为合法的范围内数据；利用触发器进行级联，修改一表中的项，将其他关联表的记录也同时删除。2.3 需求分析阶段成果2.3.1 体会与收获系统需求分析主要是通过对已有的人事管理系统功能进行参考，了解了山大等高校人事管理平台的的管理规则和运行机制，并通过上网搜索有关高校人事管理系统的知识。从许多人事管理的案例以及山大的

11、人事管理中找寻出一些基本的功能，在这些功能的基础上在绘制系统业务流程图，遇到了很多的问题，有的问题没法合理的表示出来，需要在过程中才会反应出来，仍需要继续改进，通过老师的帮助与指导，和组员之间一遍一遍的分析和完善，才逐步把业务各个过程了解清楚，最终顺利完成了需求分析阶段的任务。2.3.2 高校人事管理系统系统功能模块图1. 管理员功能模块图：2部门主任功能模块图：2. 教师功能模块图：2.3.3高校信息管理系统数据流图1.系统数据流图2管理员系统流图：2.1管理员子系统用户管理流图：2.2管理员子系统部门管理流图：2.3管理员子系统职工管理：3部门主任系统流图：3.1部门主任子系统工资流图：3

12、.2部门主任子系统个人信息流图：4职工系统数据流图：高校人事管路系统数据字典：（a）数据项：系统涉及的数据项有39项表1.1 数据项列表数据项编号数据项名数据项含义所属基本表存储结构别名DL-1用户名登录所需用户权限信息char(10)DL-2密码登录所需用户权限信息char(12)DL-3权限登录所需用户权限信息char(10)DL-4公告信息公告信息char(12)DL-5部门编号部门信息Char(16)DL-6部门名称部门信息Char(8)DL-7部门主任名部门信息char(10)DL-8缺课次数考勤信息char(20)DL-9请假原因考勤信息Char(20)DL-10是否批准考勤信息C

13、har(20)DL-11请假日期考勤信息Char(14)DL-12请假天数考勤信息Char(40)DL-一三奖励奖惩信息floatDL-14处罚原因奖惩信息floatDL-一五罚金奖惩信息Char(20)DL-16基本工资工资信息floatDL-17考勤所扣工资工资信息floatDL-一八奖金工资信息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职工家庭住址职工信息floa

14、tDL-26职工相片职工信息imageDL-27职工毕业学校职工信息Char(30)DL-28职工教龄职工信息Char(10)DL-29职工手机号职工信息Char(11)（b）数据结构：数据结构编号数据结构名数据结构含义组成DS-1管理员信息存储管理员基本信息用户名，密码，邮箱，权限 DS-2部门主任信息存储部门主任基本信息部门主任姓名，部门办公室电话，部门主任x，部门主任性别，部门主任年龄DS-3教师职工信息存储教师职工基本信息姓名、性别、年龄、职称、职工家庭住址、职工相片、毕业学校、教龄、手机号DS-4用户权限信息存储用户权限信息用户名、密码、权限DS-5工资信息存储用户工资信息基本工资、

15、考勤所扣工资、奖金、处罚金、税率DS-6奖惩信息存储员工奖惩信息奖励、处罚DS-7考勤信息存储员工考勤信息请假天数、请假日期、是否批准、缺课次数、请假原因DS-8部门信息存储部门信息部门编号、部门主任名、部门名称DS-9公告信息存储公告公告信息(c)逻辑描述管理员端处理逻辑描述处理编号处理功能处理过程PR-1判断管理员用户管理所涉及到的功能模块，进行相应的处理权限信息模块将权限表传入管理员模块，进行适应的处理之后，再将相应的的数据传入相应的模块PR-2判断管理员管理部门涉及到的功能模块部门主任信息模块、公告信息模块处理相应的数据，然后将处理结果传入相应模块PR-3判断管理员管理员工所涉及到的功

16、能模块职工信息模块、公告信息模块、职工测评模块处理相应的数据，然后将处理结果传入相应模块部门主任端处理逻辑描述处理编号处理功能处理过程PR-1判断部门主任查看公告和员工信息所涉及的功能模块 然后进行管理操作公告信息模块，员工信息模块，将公告信息传入公告信息模块，查询员工信息的过程中，将所需要的员工信息一次导入PR-2判断部门主任工资修改涉及的功能模块工资信息模块，考勤信息模块，奖惩信息模块确定工资管理所要涉及的功能模块，将消息传入相应的模块中，然后进行相应的操作PR-3判断部门主任管理员工考勤和奖惩涉及到的功能模块考勤信息模块，奖惩信息模块确定部门主任所要管理的模块并传入相应的模块教师职工端处

17、理逻辑描述处理编号处理功能处理过程PR-1判断教职工查看个人信息所涉及的功能模块 然后进行管理操作职工信息模块，奖惩信息模块，考勤信息模块先确定职工查询所要涉及的功能模块，将所要的字段信息传入相应信息模块或进行编辑信息PR-2判断教职工查看公告和工资所要涉及的功能模块公告信息模块，工资信息模块，确定员工所要查询信息所要涉及的功能模块，将消息传入相应的模块中，然后进行相应的操作PR-3判断教职工病假申请涉及到的功能模块考勤信息模块将考勤相关信息传入考勤信息模块3 概念设计阶段3.1 引言系统开发的总体目标是实现高校人事管理系统系统化，实现教师学生的基本需求，基本做到高效、智能化管理。主要任务是实

18、现增删改查功能，对教师信息和其他信息进行管理和操作。概念设计阶段主要是将需求分析阶段得到的用户需求抽象为信息结构(概念模型)的过程,它是整个数据库设计的关键。3.2 任务与目标 （1）选择中层数据流为切入点，通常选择实际系统中的子系统； （2）设计分E-R图，即各子模块的E-R图； （3）生成初步E-R图，通过合并方法，做到各子系统实体、属性、联系统一； （4）生成全局E-R图，通过消除冲突等方面。在本系统中，从三个不同的功能端下手。分析各子系统的数据流图和数据字典，知道整个系统功能围绕“部门主任”、“教师”和“管理员”的处理。根据实体与属性间的两条准则：作为“属性”，不能再具有需要描述的性质

19、。“属性”不能与其他实体具有联系。从分层的数据流图中将系统分为三个子系统：管理员子系统，职工子系统，部门主任子系统。某一层的数据流图中，每个局部应用都对应了一组数据流图，局部应用涉及的数据都已经收集在数据字典中了。现在将这些数据从数据字典中抽取出来，根据数据流图，确定实体之间的联系及其类型。根据管理员数据流图确定了管理端分E-R图；根据部门主任子系统数据流图确定了部门主任E-R图；根据职工子系统数据流图确定了职工E-R图。对于三个分E-R图，通过消除属性冲突，例如将所有的编号都统一为数值型，将所有的用户名和密码统一为字符型，将联系方式统一为字符型；消除命名冲突，将同名异义的取不同的名称，将异名

20、同义的改为统一名称；消除结构冲突，将实体的属性统一，对在不同E-R图中相同实体的不同联系进行调整，得到了系统的E-R图。3.3 阶段结果（1）根据不同的对象，分别画出各分ER图：(a)教师E-R图(b)部门主任E-R图(c)管理员E-R图(d)E-R图合并（3）各ER图各实体主要属性如下所示：1. 部门主任：部门名称，主任姓名，主任家庭住址，主任电话，主任办公室电话，主任年龄，主任性别2. 教师职工 ：职工姓名，职工编号，职工性别，职工手机号，职工职称，职工教龄，职工住址，职工所在部门，职工工资3. 工资 ：基本工资，工资税率，奖金，罚金，总工资4. 管理员 ：管理员帐号，密码4逻辑设计阶段4

21、.1逻辑设计的任务和目标以上的概念设计阶段是独立于任何一种数据模型的，但是逻辑设计阶段就与选用的DBMS产品发生关系了，系统逻辑设计的任务就是将概念设计阶段设计好的基本E-R图转换为选用DBMS产品所支持的数据模型相符合的逻辑结构。具体内容包括数据组织（将E-R图转换成关系模型、模型优化、数据库模式定义、用户子模式设计）、数据处理（画出系统功能模块图）两大任务。4.2数据组织4.2.1将E-R图转换为关系模型1、职工与病假（1：n），公告是（n:m）的关系，若将这些放在同一个表的话会造成数据冗余，浪费存储空间，所以可以将职工单独列为一个表，病假，公告各做一个表，通过职工号相联系2、管理员和职工

22、，部门主任，职工评价，公告是（1：n）的关系，同上可以将管理员单独成表，部门主任和职工评价单独成表，管理员与部门主任通过部门编号联系，管理员和职工可以通过职工号相联系，管理员与公告可以通过公告类型相联系。3、工资是建立在部门主任和职工之间的联系（n:m），一个职工和他所对应的部门主任可以确定一个工资信息，所以可以将职工编号作为码，并将工资信息做一表。4、职工与奖惩之间的联系为（1：n）,可以通过职工编号与奖惩信息表相关联，并将职工编号作为码。5、职工，部门主任，管理员与权限之间的联系(n:1)的关系，所以可以建立一个权限表，通过部门编号，职工编号与之联系综上所述得到如下关系模型:职工信息（职工

23、姓名，职工编号，职工性别，职工手机号，职工职称，职工教龄，职工住址，职工所在部门，职工工资）公告信息（公告编号，公告类型，公告内容，公告时间，职工编号）病假信息（病假编号，请假原因，请假时间，请假多久，职工编号）奖惩信息（奖惩编号，奖励原因，奖励额度，惩罚原因，惩罚额度，职工编号）部门主任信息（部门编号，部门名称，主任姓名，主任家庭住址，主任电话，主任办公室电话）工资信息（工资编号，基本工资，工资税率，奖金，罚金，总工资，职工编号）权限信息（编号，权限，密码，姓名）4.2.2模型优化根据以上得到的关系模式进行优化：职工信息：职工编号职工姓名，职工编号职工性别，职工编号职工手机号，职工编号职工职

24、称，职工编号职工教龄，职工编号职工住址，职工编号职工所在部门，职工编号职工工资。该关系满足1NF，而且其中除了码职工编号外，其他非主属性都完全依赖于主属性，因为职工编号是码，故也满足BCNF所以已优化。公告信息：公告编号公告类型，公告编号公告内容，公告编号公告时间满足BCFN，故不需要优化。病假信息：病假编号请假原因，病假编号请假时间，病假编号请假多久，病假编号职工编号。满足BCFN，不需优化。奖惩信息：奖惩编号奖惩原因，奖惩编号奖励额度，奖惩编号惩罚原因，奖惩编号惩罚额度，奖惩编号职工编号。满足BCNF，故不需优化。部门主任信息：部门编号主任姓名，部门编号主任住址，部门编号主任手机号，部门编

25、号主任办公室电话，部门名称部门编号，部门名称主任姓名，部门名称主任电话，部门名称主任家庭住址。该关系模式满足2NF，在部门名称存在传递依赖，若把部门编号与部门名称建立一个表，将会满足BCNF，但使用起来比较繁琐，效率降低，一般只用部门名称去得到其他信息而不需要部门编号，所以在这里分表也没有必要。工资信息：工资编号基本工资，工资编号奖金，工资编号罚金，工资编号总工资，工资编号职工编号，满足BCNF，已经优化。权限信息：编号权限，编号密码，满足BCNF，无需优化。4.2.3数据库模式定义表2.1 职工信息表列名数据类型可否为空说明职工编号charnot null主码职工姓名charnot null

26、用户名职工性别charnot null性别职工手机号charnot null手机职工职称charnot null职称职工住址floatnot null职工工资floatnot null总工资表2.2 公告信息表列名数据类型可否为空说明公告编号charnot null公告编号公告类型charnot null职工公告，主任公告公告内容charnot null内容公告时间datenot null发布时间表2.3 病假信息表列名数据类型可否为空说明病假编号charnot null病假编号职工编号CharNot null 职工编号请假原因charnot null请假说明请假时间datenot null请

27、假时间请假多久intnot null请假多长时间表2.4 奖惩信息表列名数据类型可否为空说明奖惩编号charnot null奖惩编号职工编号CharNot null职工编号奖励原因charnot null受奖励说明奖励额度charnot null奖励等级，奖金等所获奖励惩罚原因charnot null惩罚说明惩罚额度charnot null处分程度表2.5 部门主任信息表列名数据类型可否为空说明部门编号charnot null部门编号部门名称charnot null部门名称主任姓名charnot null主任家庭住址charnot null主任电话charnot null主任办公室电话char

28、not null办公室电话表2.6 工资信息表列名数据类型可否为空说明工资编号charnot null工资编号职工编号CharNot null职工编号基本工资floatnot null不同职工基本工资不同工资税率floatnot null奖金floatnot null因某些奖励获节日所获得奖金罚金floatnot null因某些处罚所扣资金时间datetimenot null总工资floatnot null每月实获工资表2.7 权限信息表列名数据类型可否为空说明编号charnot null职工编号和部门编号权限charnot null不同用户权限不同密码charnot null登陆密码姓名Ch

29、arNot null登录账号4.2.4 用户子模式定义表2.7 用户子模式定义编号用户子模式(View)作用(共性：提供数据保密和安全保护机制)V1TeacherView便于查询和修改教师职工的基本信息V2GongziView便于查询当月职工工资详细V3JisuanView便于职工工资计算表2.8 教师职工信息视图列名数据类型可否为空说明职工编号Charnot null职工的唯一标识职工姓名Charnot null职工的名字职工地址Charnot null职工的家庭住址职工手机号Charnot null职工联系方式职工工资Charnot null职工月工资表2.9 工资信息视图列名数据类型可否

30、为空说明职工编号Charnot null每个职工的标识基本工资Charnot null职工的基本工资奖金Charnot null当月所受奖励处罚Charnot null当月处罚所扣总工资Charnot null当月所领工资表2.9 工资计算信息视图列名数据类型可否为空说明职工编号Charnot null职工的标识奖金Charnot null奖励金额罚金Charnot null处罚金额请假时间Charnot null考勤里请假时间请假多久Charnot null考勤中请假时间长度4.3数据处理系统功能图4.4数据库关系图5物理设计阶段5.1物理设计阶段的目标与任务 数据库的物理设计就是为逻辑数据

31、模型选取一个最合适应用要求的物理结构的过程，在这个阶段中要完成两大任务：（1）确定数据库的物理结构，在关系数据库中主要是存取方法和存储结构；（2）对物理结构进行评价，评价的重点是时间和空间效率。 如果评价结果满足原设计要求，则可进入到物理实施阶段，否则就需要重新计划或者修改物理结构，甚至需要返回逻辑设计阶段修改数据模型。5.2数据存储方面为数据库中各基本表建立的索引如下：1. 由于基本表职工表的职工信息，主码职工编号，x经常在查询中，作为连接操作的连接条件出现，且它们是唯一的，在两个属性上建立唯一性索引。2. 由于基本表出勤记录，缺勤时间经常在查询条件中出现在两个属性上建立聚簇索引。3. 工资

32、信息基本表的属性名称，奖金，罚款经常在查询中出现，考虑在其之上建立聚簇索引。5.3教师/主任基本信息的查询和更新模块 将实现对教职工、部门主任的基本信息更新（查询、添加、删除）操作，用于教职工的调职，新增，离校等操作的更新。具体如下：6数据库实施阶段6.1建立数据库、数据表、视图、索引6.1.1 建立数据库 create database GXRSHGLXT；6.1.2 建立数据表(1)职工表的建立CREATE TABLE Teacher(TSno nchar (20),TName nchar (30),TSex nchar(4), TPhonecall nchar(11),TAddress

33、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）权限表的建立CREATE TABLE QuanXian

34、(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

35、(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)创立教职工基本信息视图，用于修改和查询CREA

36、TE VIEW TeacherViewASSELECT TSno, TName, TPhonecall, TAddress, TSalaryFROM Teacher（2）创建工资信息视图，用于职工当月工资查询CREATE VIEW GongZiASSELECT TSno, BSalary, JLMoney, CHFMoney, SUMSalaryFROM Salary（3）创建工资计算视图，用于职工工资的合计CREATE VIEW JiSuanViewASSELECT JLCHF.TSno, JLCHF.JLMoney, JLCHF.CHFMoney, BJ.BJTime, BJ.BJDuoJ

37、iuFROM 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 建立触发器1规定教师工资经过奖惩扣钱之后也不得低于3000元，如果少于3000，则改为最低标准3000元。crea

38、tetriggerTeacher_salbeforeinsertorupdateonteacherforeachrowasbeginif（new.job=*）and(new.sal3000)thennew.sal:=3000;endif;end;6.2数据入库系统包括教师基本信息管理、部门主任基本信息管理、管理员信息管理、测评信息管理、查询信息管理等四大功能模块，共有8张基本表,采用事先在Excel中录入数据,然后使用SQLServer2000数据导入/导出向导功能,直接将数据导入到相应的基本表中。6.3创建各个功能的存储过程系统共创建了4个存储过程，具体列表如下：表3.1 创建的存储过程列表

39、：编号存储过程名称定义作用P-1Teacher_insert详见附录1-1在职工表中插入职工信息P-2Query_Teacher详见附录1-2查询职工信息P-3Query_Salary详见附录1-3查询职工工资信息P-4Delete_Teacher详见附录1-4删除职工信息（其它表的查询、修改、删除与以上各表的存储过程定义大致相同，这里不再具体列出）七、应用设计：（1）注册和登陆窗口：只有在用户名、密码都正确的情况下，并且选择身份与用户名所在身份相符，才能登录相应的窗口。（2）登录成功后（3）（4）当部门主任进行查询操作时，直接输入职工号即可显示对应员工的信息（5）职查询工资详情（6）管理员管

40、理用户八系统调试和测试对Mini电子商务平台系统进行测试，验证每个功能是否符合要求，具体的测试如下：（1）通过视图查看各个基本表和视图中的数据（2）检测各个触发器的功能（3）对应用程序的测试（通过界面操作和数据库中各个表格检查，确认所有功能都能够正确的操作数据库，必须提供相应的检查步骤和结果，可以以附录的形式提供）九、存在问题：整个设计和实现的过程中其实很多项目和过程都是没有满足实际需求的，只能是作为一个理论上的实现。例如一个学校的人事管理系统还应该包括学生，而我们这里只考虑了老师和部门主任，而且在部门主任之上还有许多机构没有考虑；再设计的这几个功能大多都是最基本的功能，不能真正满足学校的教学

41、需求；安全性与完整性只做到了几处的约束，当测试时才发现有许多地方没有考虑到，比如在数据结构设计的过程中，性别，工资，教龄，密码等一些数据没有加以限制，导致用户在输入时可能由于数据格式不统一而导致出错；安全性没有采用数据库管理系统所给的授权功能，用程序控制不知道会不会在某种程度也会造成不安全。十、各学生贡献说明：因为整个设计过程主要分为需求分析，概念逻辑设计，物理设计，数据库实施等。故我们小组各组员负责情况如下：需求分析阶段：在需求分析阶段我们通过网上查询对当前的一些数据系统进行了对比，决定设计一款高校人事管理系统，首先由某某同学设计了管理员，部门主任以及职工所具有的功能和要求，某某同学负责数据

42、完整性和安全性的分析，然后由某某同学进行数据流图的描述与绘制，此后同学负责数据字典和数据结构以及处理逻辑的设计。观念设计阶段：由同学根据需求分析中的数据流图先依次画了管理员，部门主任，职工功能端的E-R图，然后在这三个E-R图的基础上整理出了整个系统的E-R图。并根据E-R中各实体确立了各实体所具有的的主要属性。逻辑设计阶段：介于该阶段功能比较复杂，我组在E-R图转换为关系模式这一块由 完成，在模型优化模块由同学完成，数据库模式定义和子模式的定义同学完成。物理设计阶段：此阶段主要涉及了索引的设计与建立和数据的存储以及功能模块的实现，主要功能由同学设计。数据库实施阶段：数据库的实施即表、视图等的创建，由同学设计主要部门，并根据同学和同学的建议做了一定修改。总结：由我组三人共同总结整个设计过程中遇到的问题和