数据库课程设计宿舍报修系统
《数据库系统原理》课程设计报告
课题名称：宿舍报修系统
专业班级：
学号：
姓名：
指导老师：
成绩：
2014年6月
一、课题名称
宿舍报修系统
二、需求分析
第一部分调查用户需求
本系统的最终用户为宿舍楼管理员，宿舍楼的学生，宿舍楼的维修工人。根据我们日常生活中的经验，结合对自己学校宿舍楼管理老师，维修工人的咨询和对同宿舍楼同学的调查，得出用户的下列实际要求：
1.宿舍报修的基本情况
学生住在宿舍中，每栋楼都有特定的维修工人（水工、电工、木工），学生在上报维修表后，维修工人根据维修表上的信息进行维修。
1.1学生的基本信息
每个学生都有自己的登录密码，与之姓名对应，登录时要与数据库中所存信息匹配才可登录。相对应的还有该学生的宿舍楼号，宿舍号，手机号码。
1.2管理员的基本信息
管理员在登录宿舍报修系统时，需要用到其用户名和登录密码.，与数据库中所存的信息匹配时才可以登录。
1.3维修工人的基本信息
维修工人登录时所用的用户名和密码都是特定的，在验证与数据库中所存的信息匹配时才可以登录。每个维修工人都有各自所属的宿舍楼号，不同的维修工人有不同的维修类型。
1.4宿舍楼号的基本信息
每栋宿舍楼都有其唯一的楼号，以此来区分学生所属的楼号，维修工人所属的楼号。
1.5报修表的基本信息
宿舍楼中经常出现物品的损坏，比如灯泡坏了，水龙头坏了等，这时，同学们需要将物品损坏情况在报修表中填写清楚，以便维修工人进行维修。这时，需要记录报修的宿舍楼号，宿舍号，申请的报修类型，损坏的具体部位，同时记录预约维修的时间，申请维修的学生的姓名，电话。当损坏的物品维修完毕后，学生可将维修状态更改为已维修，表示该报修成功解决。
2.用户对系统的要求
2.1学生
2.1.1信息要求
学生用户登录后，能上报本宿舍维修类型（包括水工、电工、木工），每个类型应该给出具体部位（如水工类型的有水管、水龙头等），一旦维修类型确定，维修工人也就确定，并给出预约维修的日期和时间，申请维修的学生姓名、电话等。
2.1.2处理要求
学生能在登录宿舍报修系统之后，申请报修，表示宿舍物品有损坏，需要维修工人进行维修。
当宿舍物品报修及时解决后，申请报修的学生应该要再次登录宿舍报修系统，将维修状态更改为已维修，表明该报修问题已成功解决。
2.1.3安全性要求
(1).系统应设置登录用户的标识以鉴别是否是合法用户，并要求合法用户设置其密码，保证用户身份不被盗用；
(2).系统应对不同的数据设置不同的访问级别，限制访问用户可查询和处理数据的类别和内容；
(3).系统应对不同用户设置不同的权限，区分不同的用户，如区分普通用户（维修工人），学生，管理员。
2.1.4 完整性要求
(1).各种信息记录的完整性，信息记录内容不能为空；
(2).各种数据间相互的联系的正确性；
(3).相同的数据在不同记录中的一致性。
2.2.管理员
2.2.1信息要求
管理员能对维修类型（水工、电工、木工）进行管理，主要是确定每栋宿舍具体维修类型的工人人员（如5栋宿舍楼负责水工维修的是张三、电工是李四、木工是王五）。
2.2.2处理要求
管理员可以查询维修工人的基本信息，并且能对维修工人的基本信息进行更改。比如，将一号宿舍楼的水工调到二号宿舍楼，将二号宿舍楼的水工调到三号楼去，则维修工人在记录中的所属楼号都要作相应的变化等。
2.3维修工人
2.3.1信息要求
维修工人登录后，能查询到所有自己要维修信息，并手动模拟是否去维修过，并能查询已经维修过的信息和全部信息（包括未维修和已维修）。
2.3.2处理要求
维修工人在查看自己所要维修的报修表后，就可以去报修的宿舍进行维修；同时也能看到报修表上是否已维修的信息。
第二部分系统功能的设计和划分
根据如上得到的用户需求，我们将本系统按照所完成的功能分成以下几部分：
1.学生登录部分
(1)处理学生登录
(2)学生可以申请报修
(3)学生可以查看维修状态
(4)学生可以确认报修是否被处理
2.管理员登录部分
(1)处理管理员登录
(2)管理员可以查看维修工人的信息
(3)管理员可以更改维修工人的信息
3.维修工人登录部分
(1)处理维修工人登录
(2)维修工人可以查看报修表信息
(3)维修工人可以手动模拟是否去维修过
第三部分数据流图
1.涉及到用户登录，主要针对三类用户：管理员、学生、维修工人。用户登录数据流图
如图1所示。
图1 用户登录数据流图
说明：
数据源：用户
数据流：登录系统、用户功能、用户需要的信息
处理：身份认证
数据存储：数据库
2.涉及到学生申请宿舍报修，主要针对一类用户：学生。学生登记宿舍报修数据流图如图2所示。
图2 学生登记报修数据流图
说明：
数据源：学生
数据流：报修信息
处理：报修信息、查看维修状态
数据存储：报修登记表
3.涉及到管理员管理维修工人，主要针对一类用户：管理员。管理员管理维修工人数据流图如图3所示。
图3 管理员管理维修工人数据流图
说明：
数据源：管理员
数据流：已登记信息、已更新的信息
处理：查询信息、更新信息
数据存储：维修工人信息表
4.涉及到维修工人查看报修信息，主要针对一类用户：维修工人。维修工人查看报修信息数据流图如图4所示。
图4 维修工人查看报修信息数据流图
说明：
数据源：维修工人
数据流：报修信息、已登记信息、是否已维修
处理：查看报修信息、手动模拟是否报修
数据存储：报修信息表
5.涉及到宿舍报修流程，主要针对两类用户：学生和维修工人。宿舍报修数据流图如图5所示。
图5 宿舍报修数据流图
说明：
数据源：学生、维修工人
数据流：报修信息、查询信息、已修信息、维修信息
处理：报修信息、查询信息、确认是否维修
数据存储：学生报修登记表
6.涉及到宿舍报修总流程，主要针对三类用户：学生、管理员和维修工人。宿舍报修数据流图如图6所示。
图6 总数据流图
说明：
数据源：学生、管理员、维修工人
数据流：身份认证、报修信息、维修信息、查询信息
处理：身份认证、报修信息、维修信息、查询信息、确认是否已维修
数据存储：报修信息表、维修工人信息表、数据库
三、概念结构设计
E-R图
1.涉及到学生属性，主要针对一类用户：学生。学生属性图如图7所示。
图7 学生实体E-R图
说明：
学生的属性有：id、姓名、密码、宿舍楼号、宿舍号、联系方式
2..涉及到管理员属性，主要针对一类用户：管理员。管理员属性图如图8所示。
图8 管理员实体Ｅ－Ｒ图
说明：
管理员的属性有：id、姓名、密码
3.涉及到维修工人属性，主要针对一类用户：维修工人。维修工人属性图如图9所示。
图9 维修工人实体Ｅ—Ｒ图
说明：
维修工人的属性有：id、姓名、密码、所属楼号、类型
4.总Ｅ－Ｒ图，如图10所示。
图10 全局Ｅ－Ｒ图
说明：
针对三类用户：学生、管理员、维修工人
学生：申请报修、查询维修状态
管理员：管理维修工人信息
维修工人：查询报修信息
四、逻辑结构设计
1.有关学生信息的二维表，如表1所示。
表1 学生信息表
字段字段类型字段长度是否允许为空字段说明
id int 2 否学生的ID name varchar 50 否学生的姓名password varchar 50 否学生的登录密码houseid varchar 50 否学生的宿舍号buildingid int 2 否学生的宿舍楼号phone varchar 50 否学生的联系方式
创建学生信息表的ＳＱＬ语句：
CREATE TABLE [dbo].[T_学生信息](
[id] [int] IDENTITY(1,1) NOT NULL,
[name] [varchar](50) NOT NULL,
[password] [varchar](50) NOT NULL,
[houseid] [varchar](50) NOT NULL,
[buildingid] [int] NOT NULL,
[phone] [varchar](50) NOT NULL,
CONSTRAINT [PK_T_学生信息] PRIMARY KEY CLUSTERED (
[id] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
2．有关管理员信息的二维表，如表2所示。
表2 管理员信息表
创建管理员信息表的ＳＱＬ语句：
CREATE TABLE [dbo].[T_管理员信息](
[id] [int] IDENTITY(1,1) NOT NULL,
[name] [varchar](50) NOT NULL,
[password] [varchar](50) NOT NULL,
CONSTRAINT [PK_T_管理员信息] PRIMARY KEY CLUSTERED ( [id] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
3．有关维修工人信息的二维表，如表3所示。
创建维修工人信息表的sql语句：
CREATE TABLE [dbo].[T_维修工人信息](
[id] [int] IDENTITY(1,1) NOT NULL,
[name] [varchar](50) NOT NULL,
[password] [varchar](50) NOT NULL,
[buildingid] [int] NOT NULL,
[type] [varchar](50) NOT NULL,
CONSTRAINT [PK_T_维修工人信息] PRIMARY KEY CLUSTERED
([id] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
4．有关报修信息的二维表，如表4所示。
创建报修信息表的ＳＱＬ语句：
CREATE TABLE [dbo].[T_维修工人信息](
[id] [int] IDENTITY(1,1) NOT NULL,
[name] [varchar](50) NOT NULL,
[password] [varchar](50) NOT NULL,
[buildingid] [int] NOT NULL,
[type] [varchar](50) NOT NULL,
CONSTRAINT [PK_T_维修工人信息] PRIMARY KEY CLUSTERED
([id] ASC)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]) ON [PRIMARY]
5．有关宿舍楼号的二维表，如表5所示。
表5 building表
创建building表的ＳＱＬ语句：
CREATE TABLE [dbo].[building](
[id] [int] IDENTITY(1,1) NOT NULL,
CONSTRAINT [PK_building] PRIMARY KEY CLUSTERED
([id] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
五、数据库实施
1.用户登录如图１１所示。
图1 1用户登录界面图说明：通过输入用户名和密码再选择相关人员登录界面。
涉及到的表：学生信息表、管理员信息表、维修工人信息表
2.学生登录后如图12所示。
图12学生登录界面图说明：学生成功登陆后，选择功能界面。
3.学生报修信息内容如图13所示。
图13 学生报修信息图
说明：学生申请报修的报修信息表界面，信息填写完整后，提交。
涉及的表：报修信息表、学生信息表、宿舍楼号表
4.学生查看维修状态如图14所示。
图14 学生确认已维修显示图
说明：学生在确认维修后，登录将维修状态改为已维修，表明该报修问题已成功解决。涉及的表：学生信息表、报修信息表
5.管理员登录后如图15所示。
图15 管理员登录界面图
说明：管理员在成功登录后的功能查看界面。
6.管理员查看维修工人的基本信息，以及更改维修工人信息如图16所示。
图16管理员查询并修改工人信息图
说明：管理员可以查看维修工人的信息，也可以更新维修工人的信息。主要确定每栋宿舍具体维修类型的工人人员
涉及到的表：维修工人信息表、宿舍楼号表
7.维修工人登录后的界面如图17所示。
图17 维修工人登录界面图
说明：维修功能登录后的功能选择界面。
8.维修工人查询所有所有自己要维修的信息（已维修，未维修）如图18所示。
图18工人查询报修信息图
说明：维修工人登录后可以查看自己所要维修的全部信息，包括已维修，未维修。涉及的表：报修信息表、学生信息表、宿舍楼号表
六、总结
1.5周的课程设计很快地结束了，深刻地感受到这次课程设计的复杂度，但是当仔细去钻研的时候，会发现并没有困难到无法着手。这学期的数据库上机课程中只是按照书本编写代码，但这次课程设计却需要自己去设计、编写。当然，如果只拿着书本去做对我个人而言不大可能，于是就需要借助课外书籍、网络等工具，同时也要向同学请教、交流。
这十几天我不敢说自己有多少收获，获得了多少知识，但是最起码我了解了数据库设计的部分过程。用户要求、需求分析、数据流图、数据字典、E-R图、关系模型转换、物理设计、数据库实施，都是一步步来的，做好了前面的才能顺利的做接下来的。通过这次课程设计发现我们只掌握数据库的知识是远远不够的，在制作Ｃ＃窗体时，用到了很多的控件，在课程设计的过程中，充分的认识并熟练地运用了几个常用的窗体控件。
数据库的课程设计，最基本最基础的ＳＱＬ语句，其实在课程设计之前，我都不知道怎么写，课程设计结束，不能说有多会写，但至少，ＳＱＬ语句的模式是了解知道了。在刚开始，数据库的连接上，我就遇到了一个不小的问题，因为软件安装有点不同，我的是ＳＱＬ身份认证在数据库连接时有点不一样，代码要写完整，否则连接不成功，这个问题到最后还是问了老师才得到了解决。
每一次的课程设计对我么而言都是一种锻炼，通过一次次的课程设计，使我不断的进步，尽管进步是小的，但积少成多，还是有绩效的。
七、参考文献
[1] 王珊,萨师煊著.数据库系统概论（第四版）.高等教育出版社，2006
[2] 陈根才，孙建伶，林怀忠.数据库课程设计[M]. 杭州：浙江大学出版社,2005
[3] 钱雪忠，罗海驰，陈国俊.数据库原理及课程设计.北京：清华大学出版社，2009