数据库应用技术大作业——旅馆管理系统数据库设计

数据库应⽤技术⼤作业——旅馆管理系统数据库设计
SQL实践作业：旅馆管理系统数据库设计与实现
————⾃动化学院⾃动化专业
⼩组成员及所完成的⼯作：
所完成的⼯作：数据库整体结构的设计，ER图的绘制和其他⼯作的审核
系统名称：旅馆管理系统
⼀、系统需求
1.背景：
随着科技和经济的发展，旅游业已经成为⼀个热门的产业，并且传统的⼿⼯已不适应现代酒店管理的需要，及时、准确、全⽅位的⽹络化信息管理成为必需。

在酒店的管理及业务⽇益复杂、要求在不断提⾼的现状下，利⽤⾼科技、现代化的电脑⾃动化管理系统来处理⽇益繁重的酒店业务，对于⼤型的酒店是必须具备的管理⽅式。

酒店客房管理系统是根据酒店对客房管理的实际情况进⾏编写的，主要⽬的是为了⽅便酒店对客房的实际情况进⾏集中的查询与管理⼯作，以提⾼整个酒店的⼯作。

酒店客房管理的科学化、系统化、信息化成为各个酒店追求的⽬标。

因此，⽽要实现这些功能，就要求各个酒店配备⼀套客房管理系统，以便在酒店内实施良好的完善的管理且以最快地速度响应客户的需求，及时为他们提供服务，为他们提供⼀个⾼效、便捷的居住环境。

2.旅店需求特点分析：
通过对旅店的调研，对于旅店的需求特点有了基本了解
(1)基本要求：系统能够进⾏客户的信息的存储，客户信息的删除，客户信息的
更新，客户账单的结算……因此要求系统⼀定要严密准确，不能
出现插⼊和删除异常，因此要求数据库系统的设计符合第四范式(2)⾼级要求：旅店⾯对的经常是⼀些突发的情况，⽐如客户的提前退房，客户
要求换房，客户要求其他的附加服务……这些突发事件是我们在
我们的系统中需要着重考虑的
3.旅客需求特点分析：
通过对⽤户的调研，我们发现⽤户希望住旅馆的⼿续能够尽量简单，但是要求旅馆的各种信息准确，出现错误的可能性尽量低
4.旅店管理系统需求分析：
●旅店的客房特点分析：
(1)通过每个房间唯⼀的房间号来区别(也就是我们数据库系统中的
room_num),房间分成不同的类型(room_type)有‘A’、‘B’、‘C’三种
类型，它们对应的价格也会不同，这个由顾客⾃⼰选择，体现了我们
设计系统的⼈性化；
(2)房间的状态(room_state)会根据是否有⽤户⼊住⽽不同，如果该房间
有⼈⼊住的话，那么就将房间的状态标记为busy；
(3)房间同时拥有‘IsBooked’状态，如果房间被预定的话，那么就将这
个房间的状态标记为‘Booked’，如果没有预定的话，那么房间的状
态为‘nobook’，这样的话⽅便旅客‘⼊住’、‘换房’、‘续住’种种
操作，避免住进了已经有⼈预订的房间,同时有些房间即使已经有⼈
预定了，但是在预定旅客之前其他旅客还是可以住进来的，只要他在
预定旅客⼊住之前退房就可以了，样⼤⼤提⾼了客房的利⽤率。

(4)考虑房间和顾客的关系，房间和旅客关系是⼀对多的，因为从现实出
发，房间分为‘单⼈房’、‘双⼈房’等，旅客的收费是按照‘床位’
来收费的，但是不同房间的床位的价格是不同的，但是在我们的数据
库中默认所有的房间都是单⼈房，这是我们设计的不⾜，更理想的是
在每种类型中分为‘单⼈房’、‘双⼈房’，然后为每个床位设⽴状态，
每位顾客都是按照床位来收房，⽽不是简单的按照房间来收费，但是
在现实⽣活中旅馆的类型⼜有很多种，我们所设计的数据库可能只是
适合其中的部分类型的旅馆。

●旅客特点分析：
从旅馆的⾓度来说，最重要的就是准确地记录旅客在住宿期间⼀切信息，并且要求准确(1)lodger表⽤来记录旅客的信息，有lodger_name,id_num,room_num,e
checkin_date,exp_checkout_date,pre_payment
(2)lodger表⽤来记录当前正在发⽣‘⼊住’的旅客的信息，这个表是
动态的，
如果旅客退房，与之相关的表⽰checkout实体集，将⽤户的信
息载⼊这个表，因为退房的信息是⾮常关键的，因为旅店的账⽬
的结算是要依靠这个表的，然后他的信息就会从lodger这个表
中删除；
旅客可能要求‘换房’，实现这个功能的是change_room联系集
这个联系集联系了lodger和Room两个表，将原来的房间的状态
修改为‘Free’,将新⼊住的房间修改为‘busy’；
旅客可能要求续住，我们当然会满⾜这个要求，实现这个要求的
要求是联系集con_room，如果旅客续住那么在情况允许的情况下，
可以继续在原来的房间住宿，并修改exp_checkout_date 的信息，
如果原来的房间已经有⼈预定的话，那么建议旅客更改房间，重
新登记‘lodger’信息；
旅店的账⽬管理特点分析
旅店的账⽬管理系统是⼀个⽐较复杂的系统，要求每天都要进⾏更
新，同时还须具备‘⽇结’、‘⽉结’、‘季度结’、‘年结’的功能，与
此相关的是checkout,DayAccount,MonthAccount,YearAccount他们
最终依赖的表都是checkout表，在我们的系统中checkout表⽤于记
录退房⽤户的信息，我们并没有设定主键只是设⽴了外依赖，因为在
这个表中不可能有两个完全相同的元组
(lodger_name,room_num,cur_date,(cur_year,cur_month,cur_day)
,room_account,back_change),属性(lodger_name,room_num,cur_
date,)使任意两个元组都不可能相同，因为cur_date是精确到秒的，在实际情况中具有相同lodger_name,在同⼀时间内从同⼀个房间退
房时不会发⽣地，之所以不删除这个表的元组，是因为我们想保留这
些信息以便⽇后的查询，⽐如核对账单，⽐如发⽣刑事案件需要旅店
配合时，可能需要查询相关的信息……
⽇结DayAccount的实现也⽐较复杂，⾸先我们定制⼀个作业
‘Inseting DayAccount ’每天0:00:00向DayAccount插⼊⼀个⽤
于初始化的元组，然后建⽴⼀个checkout与DayAccount之间的触发
器，如果向checkout中插⼊信息，那么就将 room_account累加到
DayAccount中的day_account中去，这样就能⾃动统计了每天的盈
利状况
MonthAccount和YearAccount的算法和DayAccount类似，同样通
过定制作业和建⽴触发器，实现⾃动运算，在这就不多介绍了
⼆、系统概念模型（E-R图）
三、关系模式（逻辑模型）
四、物理设计（表结构）
Table1:Room(Entity Set)
Attribute:
room_num (房间号),
room_type (房间类型),
room_price(房间价格),
room_state(房间状态),
IsBooked (预定状态) PrimaryKey:
room_num
Table2：Lodger (Entity Set)
Attribute:
lodger_name (客户姓名),
id_num (⾝份证号),
room_num (房间号),
checkin_date (⼊住时间),
exp_checkout_date (预期退房时间),
pe_payment (客户预付款) PrimaryKey：
lodger_num,
id_num
ForeignKey：
room_num references Room
Table 3：Room_Prebook (Entity Set) Attribute:
reserve_name (预定客户姓名),
room_num (预定房间号),
exp_checkin_date( 预期⼊住时间),
pre_payment (预付款) PrimaryKey:
reserve_name
ForeignKey：
room_num references Room
Table4：DayAccount (Entity Set) Attribute：
cur_year (年),
cur_month (⽉),
cur_day (⽇),
day_account(⽉结)
PrimaryKey:
cur_year,
cur_month,
cur_day
Table5：checkout(Relation Set) Attribute:
lodger_name (客户姓名),
room_num (房间号),
cur_date (⽇期),
(cur_year,cur_month,cur_day)(年/⽉/⽇), live_days (住宿天数),
room_account (账单),
back_change (找零) ForeignKey:
lodger_name references Lodger room_num references Room Table6:MonthAccount(Entity Set) Attribute:
cur_year (年),
cur_month (⽉),
month_account (⽇结) PrimaryKey:
cur_year,
cur_month
Table7:YearAccount (Entity Set) Attribute:
cur_year (年),
year_account (年结) PrimaryKey:
cur_year
Table8:Remind(EntitySet) Attribute:
lodger_name (客户姓名),
room_num (房间号),
cur_date (⽇期)。