基于springboot的酒店客房管理系统----数据库课程设计_酒店管理系统的数据流图和数据字典

1.需求分析

应用背景：近年来，随着社会的快速发展和互联网的高速兴起，各地的旅客量迅速增加，酒店、宾馆数量也随之急剧增加，有关客房管理的各种信息量也在不断成倍长，酒店就需要各种各样的能使工作人员对这种庞大的信息进行更快更方便更准确管理的系统。在当今时代，计算机已经被大众广泛应用，人们都习惯于在网络上进行购物、工作等一系列活动。例如，人们去外地旅游，大多数人就会选择通过网上根据自己需要来预订客房，此时酒店就需要相应的客房管理系统来提供并管理客房的相关信息。因此，酒店客房管理系统对于酒店的客房信息管理有着非常重要的作用，特别是对于客房数量比较多的酒店来说，这个系统不仅方便了客户，也方便了工作人员，同时也节省了大量的时间。

系统目标：根据开发设计系统时系统应该满足的可操作性，实用性，可靠性以及可维护性等原则，针对酒店客房管理系统的主要数据和功能需求，开发了基于mysql且利用java语言书写，利用html,css,javascipt实现前端界面和springboot整合ssm实现后端功能,利用mybatis远程连接数据库实现该系统的相关功能的简要酒店客房管理系统。

1.1用例模型

1.1.1用例图

1.1.2用例描述

1.2过程模型

此处大多功能的数据字典和数据流图基本一致，下面列举几个有代表性的功能的数据字典和数据流图。

1.2.1数据流图

上下文图：

图1.1 上下文图

0层数据流图：

图1.2 0层数据流图

1层数据流图：

图1.3 房间信息查询数据流图

图1.4 客户信息录入数据流图

图1.5 客户信息修改数据流图

图1.6 预定信息管理数据流图

图1.7 入住信息办理数据流图

图1.8 退房结账信息数据流图

1.2.2数据字典

1. 房间信息查询

数据结构：房间基本信息（房间号，房间类型，房间价格，所需押金，房间状态，房间大小，床位数、有无配备早餐）

对数据项进行分析，主要分析如下：

房间号:对每个房间分配具有唯一特殊的编号，也是系统为客户提供房间信息和管理员管理房间的依据。

数据流分析：

这些数据项由管理员输入系统，并最终通过查询功能呈现给管理员或者用户。

1. 客户信息录入

数据结构：客户信息（客户编号，姓名，性别，证件类型，证件号码，联系电话，客户级别）

对数据项进行分析，主要分析如下：

客户编号:在添加新客户时为客户分配的具有唯一标识的编号，也是系统查询客户信息的依据。

证件号码:号码对应唯一的一个公民，是查询客户信息的另一依据。

客户级别:系统根据不同的客户级别提供不同程度上的优惠折扣率。

数据流分析：

这些数据项由管理员输入系统，并最终保存到数据库相应的表中。

1. 客户信息修改

数据结构和数据项与上述一致，不在赘述

数据流分析：

修改时，数据项从数据库检索出来，作为修改后，又提交回客户信息表。

1. 预定信息管理

数据结构：预定信息（客户编号，客户姓名，性别，证件类型，证件号码，联系电话，房间号，房间类型，支付金额，预计入住时间，预计离开时间）

对数据项进行分析，主要分析如下：

客户编号:在添加新客户时为客户分配的具有唯一标识的编号，也是系统查询客户信息的依据。

证件号码:号码对应唯一的一个公民，是查询客户信息的另一依据。

房间号:对每个房间分配具有唯一特殊的编号，也是系统为客户提供房间信息和管理员管理房间的依据。

支付金额：支付金额=房间价格X客户级别提供的优惠折扣率

数据流分析:

客户先查询当前空闲房间，选择某个房间填写预定信息，系统接收处理之后将相关信息提供给管理员进行信息登记和审核。

1. 入住信息办理

数据结构：入住信息（客户编号，客户姓名，证件类型，证件号码，房间号，入住时间，预计离开时间，押金，预定金额，付款金额）

对数据项进行分析，主要分析如下：

客户编号:在添加新客户时为客户分配的具有唯一标识的编号，也是系统查询客户信息的依据。

证件号码:号码对应唯一的一个公民，是查询客户信息的另一依据。

房间号:对每个房间分配具有唯一特殊的编号，也是系统为客户提供房间信息和管理员管理房间的依据。

押金：根据每个房价类型的不同需要不同的押金

预定金额：若没有办理相关预定，则预定金额=0；若若已经办理相关预定，则预定金额=预定时支付的金额。

付款金额：付款金额=预定金额+押金。

数据流分析：

管理员将这些数据项输入到系统中，系统接收处理完成后进行相关信息的存储，并存入到相关报表中。

1. 退房结账信息

数据结构：退房结账信息（客户编号，房间号，入住时间，退房时间，定金，共需付款金额，还需支付金额，结算信息）

对数据项进行分析，主要分析如下：

客户编号:在添加新客户时为客户分配的具有唯一标识的编号，也是系统查询客户信息的依据。

房间号:对每个房间分配具有唯一特殊的编号，也是系统为客户提供房间信息和管理员管理房间的依据。

定金：办理预定时支付的金额。

共需付款金额：从办理入住到退房需要的金额。

还需支付金额：共需支付金额-定金；

结算信息：声明顾客还需要支付的金额或者酒店应返还的金额。

数据流分析：

客户发出退房申请，管理员处理相关信息后，根据房间物品的情况来退还客户押金，多退少补，并将该信息存储到退房结账报表中。

1.3 安全性和完整性需求

1、所有管理员和客户均可查询客房信息，但只有管理员才能对客房信息进行添加，删除和修改

2、管理员可以查看、删除，修改用户信息，而用户只能查看，修改自己的信息。

3、管理员可以查看，删除，增加，修改入住信息，预定信息和退房信息，而客户只能查看自己的预定信息。

1.4 数据字典

1.4.1数据项

1.4.2数据结构

1.4.3数据流

部分 数据流

1.4.4数据存储

1)客户信息=客户编号+客户姓名+客户性别+客户证件编号+客户联系电话+客户级别编号；

2)房间信息=客户编号+房间编号+入住时间+退房时间+付款金额+退还押金+总支付金额；

3)预定信息=客户编号+房间编号+预定支付金额+预计入住时间+预计离开时间;

4)退房信息=客户编号+房间编号+入住时间+退房时间+付款金额+退还押金+总支付金额；

5)入住信息=客户编号+房间编号+入住时间+预计离开时间+预定金额+付款金额

1.4.5数据过程

客户信息录入: 管理员或客户通过系统输入客户的个人资料和联系方式，创建新的客户档案。

客户信息修改: 管理员或客户通过系统更改已有客户档案中的信息。

房间信息查询: 客户通过系统查询可用客房的类型、价格和可预订信息。

客户退房:客户填写退房信息，客户完成付款、结算账单后，退回房卡并离开房间，标志着客户正式离开酒店。

客户入住房间: 客户提供预订信息和身份证明后，办理入住手续并领取房卡或钥匙，进入所预订的客房；系统添加相应的注入信息；

客户预定房间: 客户通过酒店系统预订特定类型和日期的客房，并提交预订请求。

2概念结构设计

2.1 ER模型

2.1.1 实体及属性

客户=客户编号+姓名+性别+证件类型+证件号码+联系电话+客户级别

房间=房间号+房间类型+房间价格+所需押金+房间状态+房间大小+床位数+有无配备早餐

管理员=用户名+密码

用户=用户名+密码

2.1.2 实体之间的联系

客户与房间的预定关系：一个房间可以对应多个客户，一个房间在不同时间可以被不同的客户预定，一个客户也可以对应多个房间，一个客户在不同时间可以预定不同的房间，故房间与客户是多对多的关系；预定信息=客户编号+客户姓名+性别+证件类型+证件号码+联系电话+房间号+房间类型+预定支付金额+预计入住时间+预计离开时间；

客户与房间的入住关系：一个房间可以对应多个客户，一个房间在不同时间可以被不同的客户入住，一个客户也可以对应多个房间，一个客户在不同时间可以入住不同的房间，故房间与客户是多对多的关系；入住信息=客户编号+客户姓名+证件类型+证件号码+房间号+入住时间+预计离开时间+押金+预定金额+付款金额；

客户与房间的退房关系：一个房间可以对应多个客户，一个房间在不同时间可以被不同的客户退房，一个客户也可以对应多个房间，一个客户在不同时间可以退不同的房间，

故房间与客户是多对多的关系；退房结账信息=客户编号+房间号+入住时间+退房时间+付款金额+退还押金+总收入金额；

2.2 E-R图

2.2.1 房间实体及属性

图2.1 房间实体及属性E-R图

2.2.2 客户实体及属性

图2.2 客户实体及属性E-R图

2.2.3客户与房间的预定关系E-R图

图2.3 预定关系E-R图

2.2.4客户与房间的入住关系

图2.4 入住关系E-R图

2.2.5客户与房间的退房关系

图2.5 退房关系E-R图

2.2.6全局E-R图

上述的E-R图全部为分E-R图，需要将它们消除冲突并消除冗余后合并得到最终的全局E-R图。先分析上面实体之间的关系，显然房间和客户存在实体型的一对多关系，管理员和房间之间存在多对多的关系。通过分析，可以发现，客户的证件类型可以抽象出一个单独的身份证件实体来表示客户和管理者中的证件属性;同样客户级别也抽象出单独的客户级别实体来进行记录。后续房间状态和房间类型在进行相关金额计算的时候也需要单独用到，因此将它们独立为两个实体，分别为房间状态实体和房间类型实体；上诉实体的属性在最终的全局E-R图有体现出来，这样我们成功消除了可能产生的结构冲突，同一对象在不同应用中具有不同的抽象，同一实体在不同子系统的E-R图中所包含的属性个数和属性排列次序不完全相同和实体间的联系在不同的E-R图中为不同类型这三类结构冲突经常会出现在初步的E-R图中，需要加以注意。

将上述局部E-R图合并后得到全局E-R图如下：

图2.6 全局E-R图

3逻辑结构设计

3.1 E-R图向关系模型的转换

3.1.1 数据库模式

客户：（客户编号，姓名，性别，证件类型，证件号码，联系电话，客户级别）

房间：（房间号，房间类型，房间价格，所需押金，房间状态，房间大小，床位数、有无配备早餐）

预定信息：（客户编号，客户姓名，性别，证件类型，证件号码，联系电话，房间号，房间类型，预定支付金额，预计入住时间，预计离开时间）

入住信息：（客户编号，客户姓名，证件类型，证件号码，房间号，入住时间，预计离开时间，押金，预定金额，付款金额）

退房结账信息：（客户编号，房间号，入住时间，退房时间，付款金额，退还押金，总收入金额）

3.1.2数据库外模式

外模式，是数据库用户，包括应用开发员和用户能够看到和使用的局部数据的逻辑结构和特征的描述，在具体数据库系统中即为视图，是于某个应用或功能有关的数据的逻辑表示。

酒店客房管理系统的设置的视图和相关信息如下：

客户个人信息视图

在本系统中，无论是客户本身还是管理员都需要经常对客户个人信息查看，这些信息包括客户编号，客户姓名，客户性别，客户电话号码，客户录入的身份证件类型，证件号码，客户级别。定义为视图customer_info_view。

所有的房间信息视图

客户需要查询正处于空房状态的房间信息，而管理员需要查询所有状态下的所有房间信息进行管理，这个视图信息包括房间号码、房间类型、房间一天入住价格、房间押金、房间大小、房间床位数、房间是否配备早餐、房间状态。定义为视图all_room_view。

所有的预定信息视图

管理员在进行预定管理时需要经常查看当前的所有预定信息，也可以根据需要导出所有的预定信息，包括已经失效的预定信息。这些数据包括客户编号、客户姓名、客户电话号码、客户级别、房间编号、房间类型、预定入住时间、预计退房时间、预定支付金额以及标识某元组当前是否正处于预定状态的信息表中。定义为视图all_reserve_view。

3.1.3关系模型的优化

对于客户关系模型而言，所有的非主属性不完全函数依赖于它们各自的主码，因此两个关系模型不属于2NF。存在数据冗余，修改异常等问题，需要进一步优化，需要将证件类型和证件号码单独抽象出来一个身份证件实体；同样客户级别也不完全依赖于主码，因此也需要单独将客户级别的属性抽象出来一个用户实体。

对于房间关系模型，所有的非主属性不完全函数依赖于它们各自的主码，因此关系模型不属于2NF，存在数据冗余，修改异常等问题，而且后续对于各种金额计算和产生报表需要根据房间类型和房间状态来筛选，因此单独将房间类型和房间状态抽象出来为两个实体，分别为房间类型实体和房间状态实体。

经过分解得到以下几个关系:

客户：(客户编号，客户姓名，性别，证件编号，联系电话，级别编号)

身份证件：(证件编号，证件类型，证件号码)

用户级别：(级别编号，级别名称，折扣率)

房间：(房间编号，房间类型编号，房间状态编码，房间大小，房间床位数，是否配备早餐)

房间状态：(房间状态编号，房间状态名称)

房间类型：(房间类型编号，房间类型名称，房间价格，房间押金)

对于分解后的关系模型，可以看到所有的非主属性都完全函数依赖于主码编号,因此分解后的上诉表属于2NF。而且不存在非主属性传递依赖的关系，属于3NF。初步优化后的结果可能会存在部分数据的冗余，但是如果将其拆分，后续大量的查询将会频繁使用多表连接查询，大大降低系统执行效率，而这部分的数据冗余的代价较低，因此此处采用空间换时间的策略，不再对员工关系模型进行分解。

对于预定信息和入住信息，退房结账信息的关系模型，因为是管理员对客户和房间进行统一的管理，但实际上还是客户与房间实体之间的相互关系，因此实际上还是客户与房间之间的E-R模型。对客户实体，房间实体进行优化之后产生身份证件实体、房间类型实体、房间状态实体，因此在上诉实体的情况下，对预定联系，入住联系，退房结账联系进行相关优化，优化后的模型属性如下所示：

预定信息：（客户编号，房间编号，预定支付金额，定金，预计入住时间，预计离开时间）

入住信息：（客户编号，房间编号，入住时间，预计离开时间，预定金额，付款金额）

退房结账信息：（客户编号，房间编号，入住时间，退房时间，付款金额，退还押金，总收入金额）

至此，基本解决了原来的数据冗余过大，修改异常的问题。

经过上述优化后，得到最终的关系模型如下:

客户：(客户编号，客户姓名，性别，证件编号，联系电话，级别编号)

身份证件：(证件编号，证件类型，证件号码)

用户级别：(级别编号，级别名称，折扣率)

房间：(房间编号，房间类型编号，房间状态编码，房间大小，房间床位数，是否配备早餐)

房间状态：(房间状态编号，房间状态名称)

房间类型：(房间类型编号，房间类型名称，房间价格，房间押金)

预定信息：（客户编号，房间编号，预定支付金额，定金，预计入住时间，预计离开时间）

入住信息：（客户编号，房间编号，入住时间，预计离开时间，预定金额，付款金额）

退房结账信息：（客户编号，房间编号，入住时间，退房时间，共需付款金额，还需支付金额，结算信息）

3.2 转换为MySQL8的关系模型

1客户表(customer)

表3.1 客户表

2身份证件表(IdentityDocument)

表3.2 身份证件表

3客户级别表(userlevel)

表3.3 身份证件表

4房间类型表(roomtype)

表3.4 客户级别表

5房间状态表(roomstatus)

表3.5 房间状态表

6房间表(room)

表3.6 房间表

7预定信息表(reservation)

表3.7 预定信息表

8入住信息表(checkininfo)

表3.8 入住信息表

9退房结账信息表(check_out)

表3.9 退房结账信息表

10用户表(users)

表3.10 用户表

11管理员表administrators)

表3.11 管理员表

4物理结构设计

4.1存取方法

4.1索引的建立

物理结构设计的任务是根据数据库管理系统支持的存取方法确定选择存取方法，常见的存取方法为索引和聚簇方法。

1.聚簇索引

设计聚簇，一般来说需要考虑以下条件：

1. 经常使用连接操作的关系
2. 一个关系的一组属性经常出现在相等比较条件中
3. 一个关系的一个或者一组属性值重复率高
4. 不经常更新的表中属性

对于user_level表、ID表、room_status、room_type不经常更新，而且与customer表、room表、admin表进行进行连接。因此应该使用聚簇。因为MySQL存储引擎会自动给主码建立聚簇索引，因此上诉表中的属性不需要我们去手动建立聚簇索引。

2.索引设计

对于索引的建立，一般来说需要考虑下面的条件：

(1)一个或者一组属性经常出现在查询条件中

(2)属性经常作为聚集函数的参数

(3)属性经常出现在连接条件中

(4)属性的属性值变动大，数据不集中

(5)基于上诉原则，我们建立以下索引:

系统经常根据电话号码进行客户查询(根据实际意义，电话号码只属于一个人),因此需要对客户中电话号码建立索引，实现如下:

图4.1 客户电话索引图

因为建立的基本表中的主键属性为大部分连接查询的条件信息，而MySQL的存储引擎自动会给主码建立索引信息，因此无需我们再次进行索引建立。

而且对于索引建立来说，并不是说索引越多越好，因为索引的建立需要消耗空间，同时维护和查找索引同样要付出代表，因此索引的建立应该适中。

4.2 存储结构

4.2.1数据的存放位置

确定数据的存放位置和存储结构要综合考虑存取时间、存储空间利用率和维护代价三方面的因素。这三个方面常常都是相互矛盾的，因此需要进行权衡选择折中的方法。

为了提高系统性能，应该根据应用情况将数据的易变部分和稳定部分，经常存储和存取频率较低部分进行分开存储，这种情况特别适合于多用户和多数据量的情况，具体的存放原则是:

(1)减少访问上的冲突，提高并发性能。对于数据操作事务尽力能够访问存放于不同磁盘分区上的数据，提高I/0的并发性能，提高访问速率。

(2)分散数据表中的数据，均衡数据操作。数据库中的数据访问频率是不均匀的，对于经常访问的数据应该分散到不同的磁盘分区，充分利用每个磁盘分区的访问性能。

(3)减少数据的变迁，缓解访问压力。对于经常被访问的数据位置应该有一个相对固定的存储位置，不能经常性的更改，这样能有效缓解系统的瓶颈。

因此能将前面建立的表和索引进行分开存储，将经常访问的信息分别存储到不同的磁盘中，提高I/O并发度。

4.2.2系统配置

关系型数据库一般都提供了一些系统配置变量和存储分配参数，供设计人员和数据库管理人员进行物理优化。初始情况下，系统都为这些变量赋予默认值，但这些值不一定使用于每一种应用场景，在进行物理设计时需要对一些变量进行赋值，以让数据库性能更符合设计预期。

常见的系统配置变量有：同时使用数据库的用户数，同时打开的数据库对象数，内存分配参数，缓冲区分配参数，存储分配参数，物理块大小，锁的数目等。对于本次设计的系统而言，大部分系统配置变量都采用默认值，只修改了创建数据库时字符集的指定为UTF8。

5数据库实施

5.1创建数据库及数据库对象

5.1.1创建数据库

图5.1 创建数据库sql代码图

5.1.2创建表

a)创建身份证件表

图5.2 创建身份证件表sql图

b)创建客户级别表

图5.3 创建客户级别表sql图

c)创建房间类型表

图5.4 创建房间类型表sql图

d)创建房间状态表

图5.5 创建房间状态表sql图

e)创建客户表

图5.6 创建客户表sql图

f)创建房间表

图5.7 创建房间表sql图

g)创建预定信息表

图5.8 创建预定信息表sql图

h)创建入住信息表

图5.9 创建入住信息表sql图

i)创建退房信息表

图5.10 创建退房信息表sql图

j)创建administrators表

图5.11 创建账号密码表sql图

K）创建users表

图5.12 创建账号密码表sql图

5.1.3创建视图

1. customer_info_view视图

图5.13 创建customer_info_view视图

2.all_room_view视图

图5.14 创建all_room_view视图

3.all_reserve_view视图

图5.16 创建all_reserve_view视图

5.1.4存储函数和触发器

为了实现插入数据和更新数据时，对于一些数据计算和更改，本系统设置了触发器和存储函数来辅助实现，具体如下:

1. 存储函数，用于根据客户等级和房间类型计算出每天的费用

图5.18 repay存储函数

1. 触发器，当在customer表中插入数据sex='M'或者'F'自动转换成'男'和'女'

图5.19 sex_confirm触发器

1. 触发器，当在customer表中更新数据sex='M'或者'F'自动转换成'男'和'女’.

图5.19 sex_update触发器

1. 触发器，当当向checkininfo表插入数据后，如果该customer_id和room_id在reservation表中，应该把reservation表中的re_flag设置为0,并将房间状态从预定房改为入住房。

如果不在reservation表中，则将房间状态从空房改为入住房。

图5.19 chin_update触发器

1. 触发器，当向reservation表插入数据后，应该把房间状态从空房改为预定房。

图5.20 re_update触发器

1. 写一个触发器，当向checkininfo表中插入customer_id,room_id,check_in_date,

expected_check_out_date,后计算出 reservation_amount,payment_amount,cii_flag并插入表中。

图5.20 chin_money_count触发器

1. 触发器，向reservation表插入数据时，从roomtype表查询出押金，然后计算预计入住天数，算出reservation_payment=一天房价*预计入住天数*0.3，再将re_flag赋值为1.

图5.20 reservation_payment_count触发器

1. 触发器，向checkoutinfo表插入数据时，从checkininfo表查询出reservation_payment，从checkininfo表查出check_in_info，算出total_count,need_pay,然后得出返回信息。2.触发器，当向checkoutinfo表插入数据后，应该立刻把check_in表中的chin_flag设置为0,并将房间状态改为空房。

所有触发器展示：

5.2装入数据

1. 向管理员表插入数据，用于登录认证
2. 向房间状态表插入数据

3.向房间类型表插入数据

1. 向房间表插入数据：
2. 向客户级别表插入数据

1. 向customer表插入数据

1. 向checkininfo表插入数据

1. 向checkoutinfo表插入数据

1. 向administrators表插入数据

5.3部分关键功能说明

1. 连接数据库模块

在application.yml下实现数据库的连接，服务器端口配置server:port:80指定了应用程序的服务器端口，此应用程序将在端口80上监听HTTP请求。即在访问http://localhost:80即可访问到相关应用程序。

在进行数据库操作时，每次操作都需要获取数据库连接，使用完毕后应该将连接释放，会导致性能下降：频繁地建立和释放连接会增加系统开销和延迟，导致系统性能下降；要解决这个问题，可以使用连接池来管理数据库连接，连接池可以重用连接，减少连接的创建和释放开销；因此数据库配置建立了一个使用Druid连接池的数据源。连接到名为hotel_system的MySQL数据库，该数据库位于localhost的端口3306上。连接使用了com.mysql.cj.jdbc.Driver JDBC驱动程序，连接凭据包括用户名root和密码123456。JDBC URL中的serverTimezone=UTC是将服务器的时区设置为UTC。

thymeleaf: prefix: classpath:/templates/ suffix: .html 是thymeleaf的自动配置了规则前缀和后缀，所以只要我们把html页面放在calsspath:/templates/下，thymeleaf就能自动渲染。

mybatis:configuration:map-underscore-to-camel-case: true配置针对MyBatis持久层框架，指定了配置选项，其中 map-underscore-to-camel-case: true 表示在处理数据库查询结果时，将下划线分隔的列名转换为驼峰命名规则，使得Java结果集对象中的字段名更符合Java的命名习惯。

实现代码如下：

5.4界面的设计实现和部分代码

界面的设计和相关代码存放在对应的源代码文件，这里只对几个主要的功能模块进行解释和代码呈现，具体的代码可以到指定源代码中查看。

1. 登录界面

程序运行后，我们可以访问http://localhost:80/index进行登录，登录分为管理员和普通用户登录，选择不同的用户登录进入不同页面，其核心主要是管理员或用户输入用户名和密码，通过前端表单接收用户名和密码，然后用ajax把表单数据封装成json数据，然后通过相关接口传送到后端；其登录界面相关逻辑代码如下:

身份校验逻辑代码：

登录功能实现结果：

1. 管理员操作界面

主界面展示，当管理员登录成功后进入管理员界面，对于不同功能的操作可以点击页面菜单栏的选项进入相应的操作。

1. 客户操作界面

主界面展示，当客户登录成功后进入客户界面，对于不同功能的操作可以点击页面菜单栏的选项进入相应的操作。

1. 具体的页面功能会在后续的系统功能测试中展示，相关逻辑代码可以到对应的源代码中查找，这里不再进行赘述。

5.5关键功能代码展示

a.房间状态页面展示：

实现代码：

本系统均使用MSCM实现

1. controller控制层：controller通过service的接口来控制业务流程，也可通过接收前端传过来的参数进行业务操作。

1.  model 层又称数据模型层，存放实体类，与数据库中的属性值基本保持一致。

1.  service层，又称业务逻辑层：主要是针对具体的问题的操作，把一些数据层的操作进行组合，间接与数据库打交道（提供操作数据库的方法）。要做这一层的话，要先设计接口，在实现类。

Service接口：

Service实现类:

1.  mapper层，又称数据存储对象，相当于DAO层，mapper层直接与数据库打交道（执行SQL语句），接口提供给service层。

这里就只是一个数据查询展示，相对比较简单，房间类型，身份证件，用户级别表也是只做了简单查询，故此不做过多描述，因为这四个表在实际中几乎不需要进行增删改操作，也为了节省时间。

b.客户信息功能实现：

• 添加功能的实现：

Controller层：从前端页面获取customerId传到后端

Service层：

Service接口：

Service实现类：

Mapper层：

@Inrest: 这是对象关系映射框架的注解，用于指示该方法是一个数据库添加方法。insert into customer (customer_name, customer_gender , customer_document_id, " +

            "customer_id_number, customer_contact_number, customer_level_id)" +

            " values (#{customerName},#{customerGender},#{customerDocumentId}," +

            "#{customerIdNumber},#{customerContactNumber},#{customerLevelId})") 这是一个 SQL 添加语句，它会从名为 customer 的数据库表中添加封装成customer对象的数据。结果展示：

当点击添加客户按钮，跳转到添加客户详情页面：

点击添加按钮，若符合要求则会显示添加成功。

添加成功后可以看到页面多了一条刚刚我们添加的数据：

同时，数据库也添加到了相关数据：

但是这里出现了小问题，因为我在添加这条数据之前删了一条数据，会导致编号自增删除之后不连续，所以出现了52号数据而不是51号，所以这里用手动自增的方式修改编号

SQL代码：

结果展示：

• 删除功能的实现：

Controller层：从前端页面获取customerId传到后端

Service层：

Service接口代码：

Service实现类代码：

Model层：Customer实体类，与数据库的customer表相对应。

Mapper层：

@Delete: 这是对象关系映射框架的注解，用于指示该方法是一个数据库删除方法。"delete from customer where customer_id=#{customerId}": 这是一个 SQL 删除语句，它会从名为 customer 的数据库表中删除customer_id等于customerId,而这个customerId是从函数deleteCustomerById中获取。

结果展示：

点击编号为51的客户信息的删除按钮，点击确定后删除了编号为51的客户信息

可以看到页面最后一个是编号为50的数据，编号为51的已被删除。

数据库表中的数据：

• 更新功能的实现：

Controller层：

Service层：

Service接口：

Service实现类:

Mapper层：

@Update: 这是对象关系映射框架的注解，用于指示该方法是一个数据库更新方法。"update customer set customer_name=#{customerName}, customer_gender=#{customerGender}, " +            "customer_document_id=#{customerDocumentId},customer_id_number=#{customerIdNumber},"customer_contact_number=#{customerContactNumber},customer_level_id=#{customerLevelId}  where customer_id=#{customerId}" 这是一个 SQL更新语句，它会从名为 customer 的数据库表中更新数据封装成customer对象的数据，当customer_id=customerId时，更新对象；

结果展示：

更新前数据：

点击编辑按钮进入更新客户详情页面：

其中客房信息，预定信息，入住信息和退房信息，实现功能逻辑基本相同，故只给出客户信息代码实现，等到功能展示将做更详细说明。由于时间关系，预定信息，入住信息和退房信息并未做更新操作，为了页面美观，保留了编辑按钮。

视图功能实现：

视图功能管理三个模块均实现了分页查询，但是由于实现逻辑一样，所以故只展示一个页面代码。

• 分页功能实现：

为了方便实现，在pom.xml导入了PageHelper插件帮助实现mybatis分页展示。

Controller层：

Service层：

Service接口：

Service实现类：

Model层：

Mapper层：

@Select 注解：表示这个方法是用于执行查询操作的。 SQL 查询语句是 "SELECT * FROM customer_info_view LIMIT #{offset}, #{pageSize}"，查询的是名为 customer_info_view 的视图（View）中的所有列（*表示所有列）。LIMIT 子句用于限制返回的结果行数，#{offset} 和 #{pageSize} 是 MyBatis 的参数占位符，用于接收实际的参数值。

@Param 注解用于将方法参数与 SQL 查询语句中的参数占位符进行映射。在这里，@Param("offset") 表示将方法参数 offset 映射到 SQL 查询语句中的 #{offset}，同理，@Param("pageSize") 表示将方法参数 pageSize 映射到 SQL 查询语句中的 #{pageSize}。

结果展示如下：在数据库里客户信息视图有五十条数据，在页面展示一页10条，共5页。

模糊查询功能实现：

实现代码：

Controller层：

Service层：

Service接口：

Service实现类：

Mapper层：

@Select 注解： 表示用于执行查询操作。在这里，查询的是名为 customer_info_view 的视图中，满足特定条件的数据；查询语句是 "SELECT * FROM customer_info_view WHERE customer_contact_number LIKE CONCAT('%', #{phone}, '%')". 这里使用了 LIKE 操作符进行模糊匹配，CONCAT('%', #{phone}, '%') 用于构建一个模糊匹配的字符串，其中 #{phone} 是 MyBatis 的参数占位符，用于接收实际的电话号码参数。

@Param 注解： 用于将方法参数与 SQL 查询语句中的参数占位符进行映射。@Param("phone") 表示将方法参数 phone 映射到 SQL 查询语句中的 #{phone}。

结果展示：

在搜索框搜入3915，即可实现

把数据展示到页面上：

5.6系统功能展示

5.6.1登录与注册功能展示：

管理员登录：

进入管理员界面：

客户登陆：

进入客户登录界面：

注册功能展示：

数据库user表：

5.6.2管理员界面功能展示：

1. 房间信息视图：

模糊查询搜索房间类型：

1. 预定信息视图:

1. 客户信息视图：

模糊查询客户电话

1. 客房信息

添加房间：

添加成功：

结果显示：

删除房间：

删除成功：

结果展示：

更新房间前：

更新房间：

更新房间成功：

更新完结果展示：

房间状态展示：

房间类型展示：

预定信息展示：

添加预定：

结果展示：

删除预定：删除编号为19的数据

结果展示：

入住信息展示：

添加入住信息：

结果展示：删除入住信息：

删除入住信息：删除编号为19的数据

结果展示：

退房信息展示：

添加退房信息：

结果展示：

删除退房信息：删除编号为19的数据

编号为19的数据被删除

客户展示：

更新前数据：

更新客户：

点击编辑按钮进入更新客户详情页面：添加客户：

添加成功后可以看到页面多了一条刚刚我们添加的数据：

可以看到页面最后一个是编号为50的数据，编号为51的已被删除。

身份证件展示：

用户级别展示：

5.6.3客户界面功能展示：

房间预定功能：

预定信息添加：

个人信息展示：

个人信息修改：

查看个人预定信息功能：

6 数据库运行和维护

6.1 数据库转储策略

数据转储：DBA定期将数据库复制到磁盘上保存起来，能够使因某种原因而遭到破坏的数据库进行恢复为上一次备份的状态。

转储方法：

①静态转储：转储期间不能对数据库进行任何存取等活动，是最直接的转储方法，必须等待转储完毕后才能对数据库进行存取修改等操作；静态转储效率会比较低，转储期间，新的事务无法进行；

②动态转储：转储期间允许对数据进行存取或者修改；动态转储相比静态转储的好处是转储期间，不会影响新事务的运行，效率有所提高；但转储结束后的数据并不能保证即时生效，如果转储期间，事务对数据进行了修改的话，转储后的数据就不能与原数据库中的数据保持一致性，因此要把转储期间事务对数据库进行的修改活动等记录下来成为日志文件，再合并上转储后的数据，才能与原数据库保持数据一致性；

③海量转储：每次都转储整个数据库；相比于动态转储的好处是，不用担心数据一致性的问题，在转储后不必进行记录日志文件等操作，对于恢复数据库会相对简单；但若数据库很大，那么每次转储耗费时间就会很长，也浪费存储空间；

④增量转储：每次只转储上次备份后变化的数据；相对于海量转储，提高了转储效率，只对更新的数据进行转储，实际上也是减少了数据冗余，是比较实用高效的转储方法。

6.2数据库备份与恢复方案

6.2.1数据库备份

在进行数据库更改操作中，可能会导致数据错误，甚至数据库奔溃的情况，因此需要进行数据库数据的相关备份；使用 mysqldump 命令可以备份整个数据库或特定表的数据和结构。

# 备份整个数据库到文件

mysqldump -u username -p dbname > backup.sql

# 备份特定表到文件

mysqldump -u username -p dbname table_name > table_backup.sql

这将提示输入密码，然后将数据库或表的内容导出到指定的 SQL 文件中。

这里用dataGrip图视化实现数据库备份把hotel_system数据库数据保存到桌面下文件夹drmp文件夹，保存的数据文件名为data.sql；点击hotel_system备份整个库，右键点击Export with ‘mysqldump’,

6.2.2数据库恢复：

使用备份文件还原数据库或表。

# 还原整个数据库

mysql -u username -p dbname < backup.sql

# 还原特定表

mysql -u username -p dbname < table_backup.sql

这将提示输入密码，然后将备份文件中的内容还原到数据库或表中。在dataGrip图视化工具需要恢复数据的库上右键点击Restore with ‘mysql’

6.2.3 MySQL 主从备份：

主从备份是通过在主服务器上使用 mysqldump 备份数据，然后将备份文件复制到从服务器并还原的方式实现的。在主服务器上执行备份：mysqldump -u username -p --single-transaction --master-data=2 dbname > master_backup.sql这将创建一个带有主服务器信息的备份文件,将备份文件传输到从服务器上。

在从服务器上还原备份：mysql -u username -p dbname < master_backup.sql

这将在从服务器上还原主服务器的数据。

6.3数据报表导出功能

首先是在pom.xml导入相关依赖：

在Controller层给出Get接口以响应相关导出报表的HTTP请求。，该接口处理导出请求，并调用相应的服务层方法生成Excel文件。

图5.35 数据报表导出代码

6.4连接池的使用

在进行数据库操作时，每次操作都需要获取数据库连接，使用完毕后应该将连接释放，会导致性能下降：频繁地建立和释放连接会增加系统开销和延迟，导致系统性能下降；要解决这个问题，可以使用连接池来管理数据库连接，连接池可以重用连接，减少连接的创建和释放开销；因此数据库配置建立了一个使用Druid连接池的数据源，用于提高性能。

6.5权限管理

根据功能需求分析可以知道该系统有管理员和客户两类用户，因此需要root用户对管理员和客户进行授权。

1. 客户授权

下面以客户用户张三为例，在数据库中创建用户zs，并赋予相关权限，由功能需求可知，客户对reserve视图，reservation表，Customer表有查询功能，客户对reservation表具有添加的权限，对于Customer表中除了用户级别字段没有修改权限其余都能修改,但是因为MySQL对用户权限赋予最低为表级，无法定位到字段。

在数据库中创建用户和授权如下:

2.管理员授权

下面以管理员admin为例，在数据库中创建用户admin,并赋予相关权限，由功能需求可知，管理员对于所有表的增删改查都具有权限，同时具有把权限赋给其他人的权限。

在数据库中创建用户和赋予权限如下：

6.6查询优化

1. 建立索引实现查询优化：

 

得出的查询时间需要91ms

对上述查询进行优化我们可以建立以下索引：

再次执行查询语句可以看到查询需要91ms；

并没有实现查询的优化；有时候，索引并不总是带来性能的提升，有时甚至可能导致性能下降。在这种情况下，可能有其他因素导致了性能问题。

（2）使用INNER JOIN代替隐式JOIN： 明确使用INNER JOIN语法，而不是隐式的WHERE子句连接。这可以使查询更加清晰，并可能有助于优化器生成更有效的查询计划。

我们可以得出查询需要85ms，做到了查询的优化。

小  结

1. 收获与体会

本次数据库的课程设计我收获了很多，首先基于一个系统的数据库设计，让我重新理解老师课堂上讲解的内容，例如触发器的使用，存储函数的使用，视图的建立，索引建立等等，什么时候使用这些技术来提高数据的查询和更新效率；其次，针对酒店客房管理系统，需要根据需求来设计系统的逻辑模型，这一块十分关键，中间也是因为自己理解上的问题导致修改系统的E-R模型，进一步体会到从需求到设计的关键性是提炼出模型；设计完E-R模型后，需要将这些数据模型转化成数据库系统能操作的关系对象，根据范式分析和实际情况分解关系，得到最终的关系模式，这里对于数据冗余，数据操作异常有了进一步的体会；最后在数据库实施阶段，我熟悉了更多的SQL语句，如增删改查，多表连接等功能，在图视化部分，学习利用java语言springboot提供的框架与数据库进行连接，将mybatis与SQL结合，实现数据增删改查，用web制作页面的展示。

本次设计过程虽然耗费的时间比较长，但是这个过程中收获的东西是无法用时间来衡量的，这为我将来学习更深层次的技术打下一定的基本，我个人很享受这个过程，希望在未来能有更多的机会接触这种类似项目的开发。

1. 系统需要改进的地方

  性能优化方面，在涉及到数据库查询的优化、索引的使用方面仍然需要学习使用其他的查询优化方法。

功能方面：由于时间关系，本系统并没有对预定，入住和退房做更新功能，导致功能相对欠缺，另外，并没有对时间操作有很好的把握，在预定，入住，退房功能，对一段时间进行预定，入住或退房，而这段时间之前和之后都没有进行相关的处理，比如说时间冲突。

用户界面方面：由于此界面是参考网上模板，与实际的酒店管理系统差距较大，而且界面过于繁琐，需要进行简化，尤其是对于好一部分页面跳转时由于前端接口与后端接口出现不对应而导致进入错误页面。

安全性方面： 酒店客房管理系统涉及到大量敏感信息，包括客人个人信息。确保系统具有强大的安全性，采用加密技术保护数据，实施合适的身份验证和授权机制。