数据库设计期末——学生宿舍管理系统

1 需求分析

学生宿舍管理系统主要满足三类用户的需求，分别是管理人员（设置为系统管理员）、宿管员及学生，三类用户所具有的操作权限及操作内容是有所区别的。学生宿舍管理系统中系统管理员可以对学生入住个人信息、学生宿舍更改信息和退宿信息等进行有效的管理和维护，包括增加、删除和修改等基本的操作和维护功能以及灵活的查询功能。入住新生与老生都能够对个人的基本信息、退宿和宿舍更改等所涉及的相关信息进行查询、更新等操作。

具体的需求分析如下。

系统管理员：

1）维护学生入住登记的个人基本信息。实现对学生入住登记个人信息的添加、删除和更新等。学生入住信息包括学生的学号、姓名、性别、专业、院系、年龄、电话、育人导师姓名、育人导师电话、学业导师姓名、学业导师电话、宿舍号等。

2）权限管理。系统管理员可以设置不同用户的权限，确保操作的安全性和规范性。

3）配置系统参数。系统管理员可以配置系统的基本参数，如默认分配原则、费用标准等。

4）备份与修复。系统管理员可以定期备份学生入住的基本信息数据，确保数据安全，并在需要时进行数据恢复。

5）日志管理。系统管理员可以查看系统的操作日志，记录每次操作的时间、操作人员和操作内容。

6）系统监控和性能优化。系统管理员可以监控系统的运行状态，确保系统的稳定性和性能，而且系统管理员还可以进行性能优化，提高系统的响应速度和处理能力。

学生用户：

1）查询和修改学生的个人信息：如电话、紧急联系人等。

2）查看入住信息。学生可以查看自己的入住信息，包括寝室号、室友信息等。

3）提交入住申请。新生可以提交入住申请，填写个人信息，等待管理员审核和分配寝室。

4）查询空余床位。学生可以查询各宿舍楼、楼层的空余床位情况，选择合适的寝室。

5）更换寝室申请。学生因特殊原因需要更换寝室时，可以提交更换申请，说明理由。

6）查询费用明细。学生可以查询自己的住宿费、水电费等费用明细，支持按月份、学期等条件查询。

7）在线缴费。学生可以通过系统在线缴纳各项费用，支持多种支付方式。

8）保修申请。学生可以拨打保修电话描述宿舍设施的保修申请，包括故障描述、预约维修时间等。

9）查看公告通知。学生可以在管理系统中查看宿舍管理的相关公告和通知，如宿舍检查时间、安全提示等。

宿管员：

1）宿舍分配。宿管员可以选择手动分配或者自动分配给学生合适的宿舍。

2）学生管理。宿管员可以录入新入住学生的个人信息，生成入住记录；还可以修改学生的个人信息，如更换寝室、更新联系方式等。宿管员还可以查询学生的入住信息，包括当前居住的寝室号、入住时间和室友信息等。

3）出入登记。宿管员可以记录学生的进出公寓情况，包括进出时间、进出次数等。

4）费用查询和统计。宿管员可以查询每个宿舍的费用情况，生成详细的费用报表。

还可以按宿舍楼、楼层、寝室等条件进行费用统计。

5）处理保修申请、查看维修记录。宿管员可以查看和处理学生的报修请求，记录维修进度和结果。还可以记录宿舍设施的维护情况，包括维修时间、维修人员、维修结果等。

6）发布公告通知。宿管员可以发布宿舍管理的相关公告和通知，如宿舍检查时间、安全提示等。

学生宿舍管理的基本规定如下：每个宿舍必须有一个唯一的编号，用于标识和管理；每栋宿舍楼分为若干层，每层有若干个寝室，楼层编号保持连续；不同宿舍的费用标准可以不同，具体收费标准由学校统一制定；新生入学时，宿管员根据学生的院系和年级，按照分配原则进行寝室分配；学生中途需要更换寝室时，应向宿管员提出申请，说明理由，经批准后方可调整；不同院系、年级的同学可以住同一间宿舍。

2 概念结构设计

2.1 抽象出系统的实体

根据分析，宿舍管理系统主要包括学生、宿舍、宿管员三个实体。另外除了这三个实体之外，还有其他实体集，如维修信息表、卫生检查表、水电收费表等。其中学生在入住时需要登记入住信息，学号是学生实体的主键，其基本属性主要有学号，姓名，性别，院系，班级，联系方式，宿舍号等；学生入住时所在楼层、宿舍号是唯一的，其主要属性有宿舍号、楼层号、可容纳人数，入住学生姓名等；一个宿管员可以管理多个宿舍，宿管员的主要属性有工号、姓名、性别、年龄、联系电话等。实体之间的关系为：一个宿舍可以容纳多个学生，一个宿管员也可以管理多个宿舍，学生入住的宿舍是唯一的。

根据上述分析，可以得到各个局部的E-R图，有学生实体、宿舍实体、宿管员实体、维修实体、卫生检查实体、水电收费实体、以及学生出入实体，它们分别如下图所示：

2.2 设计分E-R图

根据2.1对每一个实体集所有属性的分析，可以得到各实体集之间的约束关系，它们之间的联系分E-R图分别如下图所示：

 首先是学生与宿舍的关系，如下图：

2.3 合并各分E-R图，生成初步E-R图

2.4 系统全局E-R图

对初步的E-R图加以分析，发现维修关系图未体现，经过改造得到更加系统的全局E-R图如下图所示：

3 逻辑结构设计

数据库的逻辑结构设计是根据概念结构设计的全局E-R图，按照转换规则将E-R图转换成数据模型的过程。它主要包括三个步骤：首先，将E-R图中的实体、属性和联系转换为关系数据库中的表、字段和约束；其次，对转换后的关系模式进行规范化处理，确保数据的一致性和完整性；最后，将优化后的关系模式具体化为数据库表结构，包括表的定义、字段的定义、主键和外键的设置等，确保数据库设计既满足功能性需求，又具有良好的性能和可维护性。

3.1 E-R图转换为关系模型

E-R图中实体应该单独提取出来作为一个关系模式，其中主键应用下划线标出。

首先，从E-R图中识别出所有的实体和联系，并将其转化为关系模式。每个实体对应一个关系模式，每个联系也对应一个关系模式。以下是具体的转化过程：

1.学生（Student）

属性：学号、姓名、性别、院系、班级、联系方式

主键：学号

2.宿舍（Dormitory）

属性：宿舍号, 宿舍类型, 可容纳人数, 剩余床位数, 楼层号

主键：宿舍号

3.宿管员（Manager）

属性：工号, 姓名, 性别, 联系方式

主键: 工号

4.维修工 (Repairman)

属性：维修工姓名, 联系方式

主键: 维修工姓名

5.卫生检查 (SanitationCheck)

属性: 检查编号, 检查时间, 宿舍楼号, 检查人员, 检查总评

主键: 检查编号

6.收费记录 (ChargeRecord)

属性: 记录编号, 记录时间, 宿舍楼号, 每学期用水量, 每学期用电量, 水电费单价, 电费用单价, 总费用

主键：记录编号

7.出入登记 (EntryExitRegister)

属性: 登记编号, 外出时间, 回归时间, 联系方式, 宿舍号

主键: 登记编号

8.维修记录 (RepairRecord)

属性: 报修单号, 预约上门时间, 报修设施, 报修宿舍号

主键: 报修单号

3.2 关系模式优化

接下来，我们对这些关系模式进行规范化处理，确保它们满足第三范式（3NF）。

其中，第一范式到第四范式的含义如下：

第一范式（1NF）：所有字段都是原子的，不可再分。

第二范式（2NF）：消除非主属性对部分键的依赖。

第三范式（3NF）：消除非主属性对主键的传递依赖。

第三范式（3NF）：消除非主属性对主键的传递依赖。

这里主要是检查是否存在部分依赖和传递依赖，并消除它们。

1.学生——宿舍关系模式

     原始关系模式： 学生 (Student)

学号 (StudentID) [PK]

姓名 (Name)

性别 (Gender)

                    联系方式 (Contact)

                  院系 (Department)

                    班级 (Class)

                    宿舍号 (DormitoryID) [FK]

     规范化处理：部分依赖：无   传递依赖：无

     最终关系模式： 学生 (Student)

学号 (StudentID) [PK]

姓名 (Name)

性别 (Gender)

                    联系方式 (Contact)

                  院系 (Department)

                    班级 (Class)

学生宿舍 (StudentDormitory)

学号 (StudentID) [PK, FK]

                  宿舍号 (DormitoryID) [PK, FK]

2.宿管员——宿舍关系模式

         原始关系模式：宿管员 (Manager)

                       工号（ManagerID）

                       姓名（Name）

                       性别：（Gender）

                       联系方式（Contact）

                       宿舍号 (DormitoryID) [FK]

          规范化处理：部分依赖：无   传递依赖：无

          最终关系模式：宿管员 (Manager)

工号 (ManagerID) [PK]

姓名 (Name)

性别 (Gender)

联系方式 (Contact)

宿管员宿舍 (ManagerDormitory)

工号 (ManagerID) [PK, FK]

宿舍号 (DormitoryID) [PK, FK]

3.维修工——维修记录关系模式

        原始关系模式：  维修工 (Repairman)

                        维修工姓名 (RepairmanName) [PK]

                        维修工联系方式（Contact）

维修记录 (RepairRecord)

报修单号 (RepairID) [PK]

预约上门时间 (AppointmentTime)

报修设施 (Facility)

报修宿舍号 (DormitoryID) [FK]

维修工姓名 (RepairmanName) [FK]

          规范化处理：部分依赖：无   传递依赖：无

          最终关系模式： 维修工 (Repairman)

                        维修工姓名 (RepairmanName) [PK]

                        维修工联系方式（Contact）

维修记录 (RepairRecord)

报修单号 (RepairID) [PK]

预约上门时间 (AppointmentTime)

报修设施 (Facility)

报修宿舍号 (DormitoryID) [FK]

维修工姓名 (RepairmanName) [FK]

4.卫生检查——宿舍关系模式

           原始关系模式： 卫生检查 (SanitationCheck)

  检查编号 (CheckID) [PK]

检查时间 (CheckTime)

宿舍楼号 (DormitoryBuilding) [FK]

检查人员 (Inspector)

检查总评 (OverallRating)                  

          规范化处理：部分依赖：无   传递依赖：无

          最终关系模式： 卫生检查 (SanitationCheck)

  检查编号 (CheckID) [PK]

检查时间 (CheckTime)

宿舍楼号 (DormitoryBuilding) [FK]

检查人员 (Inspector)

检查总评 (OverallRating)           

5.收费记录——宿舍关系模式

原始关系模式：收费记录 (ChargeRecord)

             记录编号 (RecordID) [PK]

             记录时间 (RecordTime)

             宿舍楼号 (DormitoryBuilding) [FK]

            每学期用水量 (WaterUsage)

            每学期用电量 (ElectricityUsage)

            水电费单价 (WaterRate)

电费用单价 (ElectricityRate)

            总费用 (TotalCost)

因满足第三范式的要求，故保持原始关系模式不变。

6.出入登记——宿舍关系模式

             原始关系模式： 出入登记 (EntryExitRegister)

登记编号 (RegisterID) [PK]

外出时间 (OutTime)

回归时间 (ReturnTime)

联系方式 (Contact)