人事管理系统数据库课程设计SQLServer.docx
《人事管理系统数据库课程设计SQLServer.docx》由会员分享，可在线阅读，更多相关《人事管理系统数据库课程设计SQLServer.docx（53页珍藏版）》请在冰点文库上搜索。
人事管理系统数据库课程设计SQLServer
人事管理系统数据库课程设计（SQLServer）
实验报告
课程号：
B0900980
实验项目：
数据库设计、创建、治理，数据库操作
学 号
姓 名
潘欢
同组人学号
姓名
自己
实验
地点
工程学院机房〔文波〕
指导
教师
肖慎勇
时刻
2021年6月
评语〔要求〕：
按时完成实验；实验内容和过程记录完整；回答以下问题完整、正确；实验报告的撰写认真、格式符合要求。
成绩
教师签字
肖慎勇
一、实验目的
1．明白得并把握数据库设计的概念、方法和步骤。
2．初步应用数据库设计方法。
了解需求分析的内容。
3．重点运用ER模型进行概念设计，然后将ER模型转换为关系模型。
4．深入明白得SQLServer2005数据库的储备结构。
5．深入明白得SQLServer2005的数据类型、表对象设计与定义。
6．把握SQLServer2005Managementstudio的应用。
运用交互方式和命令方式建立数据库和表。
7．认识和把握Transact-SQL的数据库操作。
8．深入明白得视图意义。
把握SQLServer中创建、治理与应用视图的方法。
9．深入明白得数据库安全的概念。
10．深入明白得SQLServer2005的安全体系框架。
11．把握登录与服务器角色的概念、操作与应用。
把握数据库用户、固定角色、自定义角色、架构的概念、操作与应用。
把握数据库权限的概念、操作与应用。
12．明白得事务的概念。
13．深入明白得并把握服务器编程的意义及方法。
14．能够编写各种自定义函数和储备过程。
。
15．明白得触发器，并能够编写、应用触发器。
二、实验设备〔环境〕及要求
PC、WindowsXP、SQLSERVER2005
三、实验内容及要求
实验项目：
人事综合治理系统
通过调查、收集信息、分析，写出分析与设计报告。
1.简要的系统需求分析
包括业务分析、功能需求分析、信息需求分析。
试分析该系统的差不多业务，运算机信息系统需要完成的差不多功能、信息系统需要处理的信息。
2.概念设计
设计系统的概念模型，采纳ER模型。
3.逻辑设计
将ER模型为关系模型，指出每个关系的主键、外键和必要的约束。
4.写出数据库的物理设计
包括储备组织结构、表的结构设计等。
5.T-SQL命令方式创建数据库的操作
利用SQL命令创建数据库文件、表、索引、联系和主键、外键等约束。
〔实验报告应写出实验的过程，包括必要的截图。
〕
6.利用T-SQL命令增加、删除、修改数据。
7.利用T-SQL命令进行数据的检索和统计
依照自己设计的数据库和输入的数据，写出至少10个查询要求及对应的SQL查询命令，应该包含如下功能：
投影和选择；
多表连接；
分组统计与HAVING；
子查询；
查询结果储存。
8.利用SQL命令创建视图对象
依照开发的系统的需要，至少设计三个视图：
基于单表的、包含多表连接的、包含统计运算的。
利用SQL对视图进行查询。
9.对视图进行插入、删除、修改数据操作。
体会视图与表的异同。
10.编写自定义函数。
〔1〕编写一个自定义函数，将一个字符串作为自变量，返回颠倒顺序的字符串。
写出源代码。
〔2〕编写一个自定义函数，能够实现参数化查询的功能。
自己设定函数的具体要求，然后编写出来。
11.编写利用游标进行数据处理的储备过程。
并在储备过程中应用事务的概念。
自己确定过程的具体要求，然后编写出来。
12.编写一个实现修改表的触发器，实现完整性操纵。
13.设置服务器身份验证模式。
用命令创建假设干不同验证模式的登录账户。
14.将部分登录给予服务器角色。
然后撤消。
15.将部分登录映射到你的数据库中成为用户。
16.创建自定义角色、架构。
17.通过角色给用户授权。
18.直截了当给用户授权，验证其获得权限前后的操作差别。
19.删除用户和自定义的角色。
四、回答以下问题
1．你如何认识需求分析在系统开发中的地位和重要性？
答：
我觉得需求分析确实是把客户的功能描述转化为开发员所能明白得的功能描述，并在客户描述的基础上去除不合理的地点，补充系统缺失的地点，最后为系统的概要设计，详细设计提供准确，有效的数据基础。
在需求分析中要把系统所要处理的业务明白得透彻，并把其中的信息整理归类。
然后还需要把整个系统所要实现的功能的逻辑思路理清晰，这些工作差不多上系统开发能够连续做下去的基础。
假如需求分析没有做好，或者说对整个系统的总体框架不明晰，那么在后面的设计中会专门纷乱，显现专门多的问题。
因此我觉得需求分析能够说是系统开发的核心部分，做好这步，后面的就能清晰的进行了。
2．设计ER图、关系模型分别属于数据库设计的哪一时期？
答：
ER图属于概念设计时期；关系模型处于逻辑设计时期
3．主键、外键关于关系数据库的意义何在？
答：
主键是对表的约束，保证数据的唯独性！
外键是建立表于表之间的联系，方便程序的编写！
主键和外键是把多个表组织为一个有效的关系数据库的粘合剂。
主键和外键的设计对物理数据库的性能和可用性都有着决定性的阻碍。
4．在数据库储备结构设计时要考虑哪些因素？
答：
第一要确定数据的存放位置和储备结构，包括：
确定关系、索引、聚簇、日志、备份等的储备安排，确定系统配置。
同时要综合考虑存取时刻、储备空间利用率和爱护代价3个方面的因素。
把它们进行权衡，选择一个折中的方案。
5．在表设计时关于数据类型的选择和使用如何考虑？
答：
〔1〕第一要清晰明白得数据库中各种数据类型的用法和范畴；
〔2〕应该依照字段的实际类型来考虑数据类型；
〔3〕要估量表中数据的大小范畴，来确定数据类型的大小，幸免空间不足或者白费。
6.交互式如何实现表之间的联系？
SQL命令如何实现表之间的联系？
答：
〔1〕交互式：
在治理平台中，展开要操作的数据库，选择〝数据库关系图〞选项，然后单击鼠标右键，在弹出的快捷菜单中选择〝新建数据库关系图〞命令，在弹出的窗口中选择要建立关系的表后，那么会弹出数据库关系图设计窗口。
然后右键单击关系图的空白页面，在弹出的快捷菜单中，能够新建或添加数据库中已定义的表，在该表的关联菜单中选择〝属性〞选项，能够创建或定义该表的关系、键、索引和约束或修改当前的附加特性。
〔2〕SQL命令：
ALTERTABLE
ADDCONSTRAINTconstraint_name
PRIMARY KEY[CLUSTERED|NONCLUSTERED]
[FOREIGNKEY]
REFERENCESref_table
7．假如在定义表时进行了主键、外键以及约束等完整性设置，关于数据的输入有何阻碍？
试举例说明。
答：
定义主键：
定义主键来强制不承诺空值的指定列中输入值的唯独性。
假如在数据库中为表定义了主键，那么可将该表与其它表相关，从而减少冗余数据。
表只能有一个主键。
假如主键包含不止一列，那么在一列中承诺有重复值，但主键中所有列值的每个组合必须唯独。
定义外键：
外键引用完整性表示得到正常爱护的表之间的关系。
表中的数据只应指向另一个表中的现有行，不应指向不存在的行。
主键约束：
使用单列或者多列组合，表示每一条记录的唯独性，值不能为空；外键约束：
是为了加强数据表之间的关键的表中的单列或者多列值，必须依靠另外的表存在；唯独约束：
不承诺数据库中的某一列数据有重复，然而承诺有空值存在。
主键和唯独性约束定义了表中记录的唯独性，然而主键列的值不鞥为空，而唯独键约束的列的值能够为空值；
8．用INSERTINTO命令输入，假如数据与字段数量和要求不一致有什么问题？
当表定义中有默认值的时候，插入记录是否能够省略该字段的数据？
答：
假如数据与字段数量和要求不一致，那么会插入失败，同时SQLServer将显示错误信息。
有默认值时能够省略该字段数据，系统会为该列提供默认值。
9．HAVING子句有什么作用？
答：
HAVING字句与WHERE子句一样，也能够起到按条件选择记录的功能，但HAVING子句是作用于组，必须与GROUPBY子句连用，用来指定每一分租内应满足的条件。
10．当通配字符作为一般字符参与匹配查询时，如何解决如此的问题？
答：
转义，对通配符加[]。
11．可否利用视图进行数据的插入、删除、修改？
答：
能够通过视图对基础表中的数据进行检索、添加、修改和查询。
然而插入、修改、删除数据是只能做单表的，基于多表的视图不能够删除和修改。
12．依照自己的体会，谈谈视图在数据库体系中的作用。
模式
答：
利用视图能够简化用户操作数据的方式。
可将经常使用的连接、投影、联合查询和选择查询定义为视图，如此每次对特定的数据执行进一步操作时，不必指定所有条件和限定。
除此之外还能够定制数据，导出数据。
还能够用GRANT和REVOKE命令为各种用户授予在视图上的操作权限，如此通过视图，用户只能查询或修改他们各自所能见到的数据，数据库中的其他数据对他们来说是不可见的或不可修改的。
保证数据库的安全性。
13．视图是如何储存的？
视图中的数据是否确实储备在文件中？
答：
储存视图将更换服务器上的视图定义。
当您储存视图时，基础数据库引擎将使用新的视图定义。
在查询和视图设计器中打开视图定义并对其进行修改。
〔1〕在查询和视图设计器中打开视图定义并对其进行修改。
〔2〕从〝文件〞菜单中单击〝储存view_name〞，其中view_name是打开的视图的名称。
14．SQLSERVER有几种身份验证模式？
区别是什么？
不同验证模式的登录账户有何区别？
答：
有两种〔1〕windows身份验证模式，是默认的验证模式，使用windows操作系统的安全机制验证用户身份，只要用户能够通过windows用户账号验证，同时是SQLServer的登录账户，即可连接到SQLServer而不用进行身份验证，只适用于能够提供有效身份验证的windows操作系统。
〔2〕混合的验证模式：
在该模式下，Windows和SQLServer两种验证模式都可用，对可信任连接用户，直截了当采纳windows的身份验证，否那么采纳SQLServer模式，用户在连接SQLServer时必须提供登录名和密码，SQLServer自己执行认证处理，假如输入的登录信息与系统表syslogins中的某几条记录相匹配时说明登录成功。
15．Sa账户有何特点？
答：
Sa账户是SQLServer的专门账户，sa账户拥有服务器和所有的数据库。
即Sa账户拥有最高的治理权限，能够执行服务器范畴内所有操作。
它是以SQLServer身份验证的，因此必须设置一个密码。
同时，sa账户的属性不能够更换，密码能够修改。
Sa登录时无法删除的。
16．共有几种服务器角色？
最高权限的角色是什么？
能够创建数据库的角色是哪个？
答：
共有8种固定服务器角色，分别是：
sysadmin，serveradmin，setupadmin，securityadmin，processadmin，dbcreator，diskadmin，bulkadmin；同时每一个登录用户都属于public服务器角色。
最高权限的角色是sysadmin；能够创建数据库的角色是：
sysadmin，dbcreator；
17．数据库用户和登录账户有什么关系？
guest是什么用户？
有何作用？
答：
这是两种不同级别的安全机制，登录账户是SQLServer级的安全性设置，而数据库用户那么是数据库级的安全性设置。
登录账户用于登录服务器，然而当某一用户要访问某个数据库时，除了能够成为服务器的一个登录以外，还必须成为那个数据库的用户账户，即获得一定的授权。
数据库用户账号在一样情形下是从某个登录账户中映射过来的。
Guest是来宾用户，是用来共享文件的。
任何一个登录都能够以此身份访问数据库。
Guest自动本身只具有public权限。
也能够由其他用户授权。
18．数据库角色有哪两类？
PUBLIC角色有何特点？
答：
数据库角色分为固定的数据库角色和用户定义数据库角色。
每个数据库都有一系列固定数据库角色。
尽管每个数据库中都存在名称相同的角色，但各个角色的作用域只是在特定的数据库内。
用户定义数据库角色是用户依照工作的职能定义一系列角色，并给每个角色指派了适合这项工作的权限。
从而在数据库中治理这些权限。
PUBLIC角色的特点：
默认不具有任何权限，但用户可对此角色进行授权，他不能被删除，是所有user自动拥有的角色。
数据库中的每个用户都属于public数据库角色。
假如想让数据库中的每个用户都能有某个特定的权限，那么将该权限指派给public角色。
假如没有给用户专门授予对某个对象的权限，他们就使用指派给public角色的权限。
19．用户与架构有什么关系？
系统默认架构是什么？
如何样为用户指定架构？
答：
SQLServer2000中数据库用户和构架是隐式连在一起的，架构将用户和权限之间建立了一个间接地点式。
数据库架构是一个独立于数据库用户的非重复命名空间，能够将架构视为对象的容器。
每个数据库用户差不多上与该用户同名架构的所有者；而在SQLServer2005中构架和用户是不同的实体。
一个对象只能属于一个架构，就像一个文件只能存放于一个文件夹中一样。
与文件夹不同的是，架构是不能嵌套的。
系统默认架构是dbo架构；通过使用CREATEUSER和ALTERUSER语句，能够分配一个默认架构；也能够通过SSMS在该用户的属性下面分配一个默认架构。
20.什么是安全对象？
如何样为数据库用户指定查询表的权限？
答：
安全对象是SQLServer数据库引擎授权系统操纵对其进行访问的资源。
安全对象范畴有服务器、端点和架构。
21．简述自定义函数、储备过程和触发器的异同。
答：
〔1〕自定义函数、储备过程、和触发器差不多上模块化设计的类型。
〔2〕函数最后是返回一个值，在表达式中调用，定义函数时要定义函数的函数名、参数、函数值类型和函数体。
〔3〕储备过程经编译后放在数据库服务器端，供客户端调用，处理一件事或完成一个功能，有单独的调用命令。
调用过程时，是实际参数与形参的传递〔值传递和名传递两种〕。
定义过程时需定义过程名、参数、过程体。
它能够实现完整性操纵机。
〔4〕触发器实质是一种专门类型的储备过程，它在插入、修改或删除时触发执行。
能够实现由主键和外键所不能保证的参照完整性和数据的一致性。
22．什么是游标？
应用游标的步骤是什么？
答：
游标是对表的运用的一种机制，相当于在表上定义一条指针，把表中的数据按一行一行的来读取。
把表中的数据取出来放在高级语言的变量中，是SQL语言与高级语言之间的桥梁。
应用游标的步骤：
〔1〕声明游标〔2〕打开游标，即把外存上的数据调入内存，运行查询〔3〕提取数据（4）关闭游标〔5〕开释游标
五、分析讨论
通过实验我觉得最重要的是系统分析，逻辑设计和物理设计时一定要认真想清晰每张表的属性和它们之间的相互联系，如此在后面使用查询的时候才可不能出错，假如前面没做好，后面做查询的时候就会显现各种错误，如数据结构定义不统一，外键冲突等问题。
除此之外要做好一个数据库系统，要把握好学习中的每一步，平常上课学习专门有用，好好学了，做的时候就会比较轻松。
除此之外，我觉得函数和触发器那部分比较难，只会实现简单的查询、删除、修改操纵。
对基于多表的带参函数运用还比较弱。
以下为本次实验的过程记录报告撰写。
〔可包括必要的截图〕
人事综合治理系统
信管10031009030340潘欢
1.简要的系统需求分析
人事治理系统是专门通用的治理信息系统，是企事业单位实现办公自动化的前提和基础。
一个公司要正常运作必定有一个健全的人事治理系统，来治理职员的信息，包括职员编号、姓名、性别、民族工资及奖惩考勤情形。
除此之外，系统还供职员查询个人和公共信息，治理员对职员信息进行更换或删除，治理公司的人事变更和治理，大大提高公司内部职员治理的工作效率。
1.1业务分析
〔1〕部门治理：
对公司的部门进行编号，将每一个部门的部门号、部门名称、部门描述和部门负责人信息统一储存在部门信息档案中。
当新增或去除某个部门时，将其信息添加到部门信息档案或或从中删除。
当部门信息发生变化时，修改对应和相关的属性值。
〔2〕职员信息治理：
对公司里的所有职员进行统一编号；将每一位职员的信息录入到职员信息档案中。
对新聘用的职员，将其信息加入到职员信息档案中；关于解雇的职员，将其信息从信息档案中删除。
当职员的信息发生变动时，修改职员信息档案中相应的属性。
同时供职员自己查询使用。
其下还包含有个人家庭关系和个人呢工作学习的经历，各放在一张表格中。
〔3〕职员职务调动治理：
同样对公司职员的职务进行统一编号；登记职员调动前后的具体职务，以及调动时刻。
〔4〕奖惩治理：
依照每个职员的编号登记奖惩缘故和奖惩金额及奖惩月份。
〔5〕考勤治理：
依照职员编号，登记职员每个月的全勤，出差，请假时日和加班迟到早退信息。
〔6〕工资治理：
对所有职员的每笔工资进行编号，记录工资记录表。
1.2功能需求分析
〔1〕一样用户能够查询个人信息和修改自己的登录密码；
〔2〕治理员能够查询所有职员的信息并能够做添加、修改、删除的操作。
2.概念设计
ER模型设计
3.逻辑结构设计
将ER模型转化为关系模型
〔1〕部门〔部门编号+部门名称+部门简介+部门负责人〕；PS：
部门编号为主码
〔2〕职员信息〔职员编号+姓名+性别+民族+生日+政治面貌+文化程度+婚姻状况+籍贯+身份证号+工作证号+办公+手机号码+部门编号+职务+状态+工资+备注〕Ps：
职员编号为主码，部门编号为外码
〔3〕职务调动信息〔调动编号+职员编号+调动前职务+调动后职务+调动日期+批复部门号〕PS：
调动编号为主码，职员编号为外码
〔4〕奖惩信息〔奖惩编号+职员编号+奖励事由+奖励金额+处罚事由+处罚金额〕PS：
奖惩编号为主码+职员编号为外码
〔5〕考勤信息〔考勤月份+职员编号+全勤天数+出差天数+病假天数+事假天数+旷工天数+迟到时刻+早退时刻+…〕PS:
考勤月份为主码，职员编号为外码
〔6〕工资信息〔工资编号+职员编号+差不多工资+奖励金额+处罚金额+考勤月份〕PS：
工资编号为主码，职员编号和考勤月份为外码
〔7〕治理员信息〔用户名+密码+用户类型〕PS：
用户名为主码；
4.数据库的物理设计
〔1〕具体表的结构设计
部门：
编号
字段名称
数据结构
约束条件
1
部门编号
int
Notnullprimarykey
2
部门名称
varchar（40）
Notnull
3
部门职能描述
Varchar（400）
null
4
部门负责人编号
Char（3）
Notnull
职员：
编号
字段名称
数据结构
约束条件
1
职员编号
Char（4）
Notnullprimarykey
2
姓名
Varchar（50）
Notnull
3
性别
Char
（2）
null
4
民族
varchar（40）
null
5
生日
datetime
null
6
政治面貌
varchar（40）
null
7
文化程度
varchar（40）
null
8
婚姻状况
varchar（20）
null
9
籍贯
varchar（60）
null
10
身份证号
varchar（20）
null
11
办公
varchar（30）
null
12
手机号码
varchar（30）
null
13
部门编号
int
null
14
职务
varchar（20）
null
15
职员状态〔1-在职，2-兼职，3，试用，4-离职，5-退休〕
tinyint
null
职员调动：
编号
字段名称
数据结构
约束条件
1
调动编号
Char
（2）
Notnullprimarykey
2
职员编号
Char（4）
Notnull
3
调动前职务
Varchar（20）
Null
4
调动后职务
Varchar（20）
null
5
调动日期
Datetime
Null
6
批复部门编号
int
Notnull
奖惩：
编号
字段名称
数据结构
约束条件
1
奖惩编号
Char
（2）
Notnullprimarykey
2
职员编号
Char（4）
Notnull
3
奖励事由
Varchar（200）
Null
4
奖励金额
smallint
Null
5
处罚事由
Varchar（200）
Null
6
处罚金额
smallint
null
考勤：
编号
字段名称
数据结构
约束条件
1
考勤编号
Char（3）
Notnullprimarykey
2
考勤月份
Datetime
Notnull
3
职员编号
int
Notnull
4
全勤天数
Decimal（4,1）
Null
5
出差天数
Decimal（4,1）
Null
6
病假天数
Decimal（4,1）
Null
7
事假天数
Decimal（4,1）
Null
8
旷工天数
Decimal（4,1）
Null
9
法定休假天数
Decimal（4,1）
Null
10
迟到时刻〔分〕
Tinyint
Null
11
早退时刻（分）
Tinyint
Null
12
一类加班天数〔法定节假日加班〕
Int
Null
13
二类加班天数〔周六或周日加班〕
Int
Null
14
三类加班天数〔日常加班〕
Int
Null
工资：
编号
字段名称
数据结构
约束条件
1
工资编号
Char（3）
Notnullprimarykey
2
职员编号
Char（4）
Notnull
3
差不多工资
money
Null
4
考勤月份
Datetime
Notnull
5
奖励金额
money
Null
6
处罚金额
money
null
用户治理：
编号
字段名称
数据结构
约束条件
1
用户名
Varchar（40）
Notnullprimarykey
2
密码
Varchar（40）
Notnull
3
用户类型〔1-系统治理员，2-一般用户
tinyint
Notnull
家庭关系：
编号
说明
数据结构
约束条件
1
编号
tinyint
Notnullprimarykey
2
职员编号
int
Notnull
3
姓名
Varchar（50）
Null
4
性别
Char
（2）
Null
5
年龄
tinyint
Null
6
与本人关系
Varchar（20）
Null
7
工作单位
Varchar（40）
null
工作经历：
编号
说明
数据结构
约束条件
1
编号
tinyint
Notnullprimarykey
2
升级会员 