数据库系统原理课程设计.docx
《数据库系统原理课程设计.docx》由会员分享，可在线阅读，更多相关《数据库系统原理课程设计.docx（23页珍藏版）》请在冰豆网上搜索。
数据库系统原理课程设计
《数据库系统原理》课程设计
系统实现报告
学号：
37060522
姓名：
蔡元睿
2009年12月23日
目录
1.系统功能需求分析4
1.1需求描述4
1.2实现环境5
2．系统功能结构设计5
2.1模块的划分5
2.2管理员模块的设计5
2.3订单处理子系统模块的设计6
2.3.1前台服务员功能设计7
2.3.2厨师组功能设计8
2.3.3后台的服务员组功能设计8
3．数据库基本表的定义8
4．主要模块实现技术10
4.1单件模式10
4.2观察者模式10
4.3使用的触发器、过程、函数。
11
触发器11
触发器correct_price11
过程12
过程getSingleDayTurnover（indowntimestamp,inuptimestamp）12
过程getContinuousDayTurnover（indowntimestamp,inuptimestamp）12
过程getLabourParamaters（inrolechar（15）,indowntimestamp,inuptimestamp）13
过程getNewID（）13
函数14
函数newId（）14
5．主要源程序简要说明14
5.1Data包14
5.2Ui包14
RunService类14
Login类14
ChefGroupUI类15
FrontClerkGUI类15
WaiterGroupUI类15
ManagerGUI类15
MyChartFactory类15
5.3State包15
EmployeeState类15
MenuItemState类15
OrderState类15
Role类16
RoomState类16
StaffState类16
5.4Observer包16
MenuItemObserver接口16
OrderListObserver接口16
OrderObserver接口17
RoomStateObserver接口17
StaffStateObserver接口17
5.5Model包17
5.6MyException包17
6．系统实现结果18
6.1管理员的操作界面18
6.1.1员工状态18
6.1.2菜单管理19
6.1.3报表系统19
6.2前台服务员的操作界面21
6.3厨师的操作界面22
6.4后台服务员的操作界面23
7．总结23
1.系统功能需求分析
1.1需求描述
为了提高饭店员工之间的协调工作的效率，我开发了饭店管理系统，使得前台服务员、厨师、后台服务员之间的协调趋向于无缝。
尽量缩短员工的协作时间，为顾客提供快速优质的服务。
饭店的管理系统，有多个前台服务员，多个厨师小组，多个后台服务小组，每个厨师小组在某一个上课只能处理一个订单，每个后台服务员小组在某个时刻只能处理一个订单。
管理员可以检查雇员的工作状态，管理菜单。
饭店日常工作的流程：
雇员具体的责任：
前台服务员
1.1根据客人的需要填写订单，并提交订单；
1.2查看每一个没有结账的订单的详细状态；
1.3监视房间的使用状态；
1.4预览账单、打印账单。
厨师组
2.1获取未处理的订单，进行处理；
2.2处理订单，根据工作的进行，改变每一道菜的状态。
后台的服务员组
3.1获取厨师处理中的订单，并且该定还没有别的服务员负责处理；
3.2处理订单，根据工作的进行，改变每一道菜的状态。
管理员
4.1监视雇员的工作状态；
4.2查看经营情况，包括雇员的劳动量、营业额、受欢迎的菜。
4.3管理菜单，包括添加、修改、删除菜样。
1.2实现环境
硬件配置：
512M内存、1.6GHz处理器、多台显示器。
操作系统：
WindowsXP、Vista、Windows7
软件环境：
JDK1.5+MYSQL
2．系统功能结构设计
2.1模块的划分
本系统有四种参与者，分别是：
管理员、前台服务员、厨师、后台服务员。
系统主要模块划分
系统主要划分为四个模块：
管理员模块，前台服务员模块、厨师模块、后台服务员模块。
模块的粗略关系如下：
2.2管理员模块的设计
管理员不参与订单的处理过程，因此把管理员模块单独提出来为一个相对独立的子系统。
管理员实现的功能主要都与静态数据的读取有关，没有与别的对象有过多的交互，逻辑相对简单。
管理员模块实现的主要功能：
1.管理员监视员工的工作状态；
在员工的状态集对象中记录员工的工作对象，一旦某个员工的工作状态发生改变，状态集对象就会发生相应的改变。
然后状态集对象就会通知管理员，发生了变化。
2.管理员查看经营的情况；
管理员通过时间的约束，来了解饭店的各项经营指数。
例如，管理员可以看某天的营业额，或者其他连续天数的营业额。
3.管理员对菜单管理。
管理员可以对菜单进行添加删改的工作。
2.3订单处理子系统模块的设计
订单的一般处理流程，如图
根据流程我们可以设计出子系统的静态结构，如下：
图中对应的术语表
术语
中文名称
备注
FrontClerk
前台服务员
负责录入订单和打印账单的前台服务员
Waiter
后台服务员
负责端菜的服务员，以小组为单位。
Chef
厨师
负责制作菜的厨师，以小组为单位。
Order
订单
现实中的订单。
OrderList
订单队列
管理所有未结账的订单。
MenuItem
菜样
一道菜。
Room
房间
RoomState
房间的状态集
监视所有的房间的状态。
2.3.1前台服务员功能设计
制定订单的流程：
（1）选定空闲的房间，获取房间的使用权；
（2）根据客人的订的菜录入；
（3）提交订单，设定订单的状态为未处理，加入订单队列。
结账的流程：
（1）检查订单是否全部处理完毕；
（2）未处理完毕，拒绝结账。
（3）处理完毕，打印账单。
2.3.2厨师组功能设计
获取未处理订单的流程：
（1）选择订单；
（2）检查订单的状态是否有厨师在处理；
（3）没有，则成功获取订单，改变订单的状态为处理状态，往订单添加厨师信息；
（4）有，则获取失败，重新选择订单。
处理具体一道订单过程：
（1）选择要处理的菜；
（2）检查该道菜是否已经处理过；
（3）否，则处理该道菜，把该道菜的状态改为处理中；
（4）有，则选择其他为处理的菜；
（5）处理完成一道菜后，把该道菜的状态改为处理完毕。
2.3.3后台的服务员组功能设计
获取未处理订单的流程：
（1）选择订单；
（2）假如订单的状态是有厨师处理并且没有别的后台服务员在处理；
（3）符合条件，则获取订单成功往订单添加服务员信息；
（4）否则，则获取失败，重新选择订单。
处理订单的流程：
（1）选择要送出的菜；
（2）假如该道菜已经处理完毕并且没有送出；
（3）符合，则送出该道菜，把该道菜的状态改为送出；
（4）否则，则选择其他未送出的处理的菜；
（5）每一道菜都送出之后，则把该订单的状态改为，全部处理完毕。
3．数据库基本表的定义
表关系的概要图：
表的详细说明：
订单表（guestorder）
列名
数据类型
备注
Id
Int
订单的编号，主键
roomNO
Int
房间的号码，外键引用房间表的roomNO
BeginTime
Timestamp
订单的开始时间
Endtime
Timestamp
结账时间
Chef
Char（10）
外键，引用员工表中的厨师的名字。
Waiter
Char（10）
外键，引用员工表中的前台服务员的名字。
菜单表（menu）
列名
数据类型
备注
Name
Char（20）
主键，菜名
Kind
Char（20）
所属种类
Price
Double
单位价格
订单_菜单表（order_menu）
列名
数据类型
备注
Order_id
Int
外键，引用订单表的id
Name
Char（20）
外键，引用菜单表的name
Quantity
Int
当前点菜的份数
房间表（room）
列名
数据类型
备注
RoomNO
Int
房间号，主键
Capacity
Int
房间的容量
员工表（staff）
列名
数据类型
备注
Name
Char（10）
主键，名字
Role
Char（10）
角色，职务
4．主要模块实现技术
4.1单件模式
由于在本系统中有几个需要全局量，如，订单队列（OrderList）、房间的状态（RoomState）、员工的状态（StaffState）。
所以我采用了经典设计模式中的单件模式。
以OrderList为例，示例代码如下：
publicclassOrderList{
privatestaticOrderListinstance;
privateOrderList（）{
}
publicstaticOrderListgetInstance（）{
if（instance==null）
instance=newOrderList（）;
returninstance;
}
}
注意，OrderList类的构造方法被声明为私有的方法，所以不能直接地实例化OrderList，并且该类有一个特殊的静态属性instance（OrderList类型）。
所以我们只能通过OrderList的静态方法getInstance（）访问唯一的实例化的OrderList对象instance。
从而使得只有一个OrderList对象能够被实例化，从而保证了数据的一致性。
4.2观察者模式
在本系统中，几个系统的参与者，前台服务员、厨师、后台服务员都需要监视一些量。
例如他们都需要监视订单队列（OrderList）的状态，厨师和后台服务员需要观察他们当前处理的订单（order）的状态以及每一道菜（MenuItem）的状态，前台服务员还需要监视房间的状态（RoomState）。
为了使得被监视的量在改变的时候，能够及时让监视它们的观察者能够根据改变及时做出调整。
我在订单处理子系统的实现中大量的使用的了观察者模式。
下面以订单队列的实现举例：
实现结构图如下：
由于FrontClerk、Chef和Waiter都需要观察OrderList，所以他们都需要根据自己的情况实现OrderListObserver接口，实现OrderListObserver接口后，OrderListObserver就可以视为他们的向上型。
OrderList中有几个必要的元素需要说明，属性Observers保留了OrderList的观察者的所有引用。
addObserver（）方法提供OrderList添加观察者到Observers中的功能，removeObserver（）方法提供OrderList删除观察者的功能。
最为重要的方法为notify（），在notify（）方法中，遍历每一个observer，调用他们的update（）方法，从而把变化广播出去。
在所有关于OrderList的状态变化的地方都应该调用notify（）方法。
使用观察者模式能够使得观察者们及时地捕捉到变化。
4.3使用的触发器、过程、函数。
触发器
触发器correct_price
为了防止输入不合法的价格，当输入的价格为负数的时候，自动把它调整为整数。
脚本如下：
delimiter$$
createtriggercorrect_price
beforeinsertonmenuforeachrow
begin
ifnew.price<0.0then
setnew.price=0-new.price;
endif;
end$$
过程
过程getSingleDayTurnover（indowntimestamp,inuptimestamp）
通过传入一天的营业的开始时间和结束时间为参数，而获得计算当天的营业额所需要的参数。
脚本如下：
DELIMITER$$
DROPPROCEDUREIFEXISTS`restaurantimproved`.`getSingleDayTurnover`$$
CREATEPROCEDURE`restaurantimproved`.`getSingleDayTurnover`（indowntimestamp,inuptimestamp）
BEGIN
selectbeginTime,quantity,pricefromguestorderinnerjoinorder_menuon（guestorder.id=order_menu.order_id）innerjoinmenuon（order_menu.name=menu.name）whereguestorder.beginTime>=downandguestorder.beginTimeEND$$
DELIMITER;
过程getContinuousDayTurnover（indowntimestamp,inuptimestamp）
通过传入营业的开始时间和结束时间为参数，从而获取计算连续天数的营业额参数。
脚本如下：
DELIMITER$$
DROPPROCEDUREIFEXISTS`restaurantimproved`.`getContinuousDayTurnover`$$
CREATEPROCEDURE`restaurantimproved`.`getContinuousDayTurnover`（indowntimestamp,inuptimestamp）
BEGIN
selectbeginTime,（quantity*price）astmpsumfromguestorderinnerjoinorder_menuon（guestorder.id=order_menu.order_id）innerjoinmenuon（order_menu.name=menu.name）whereguestorder.beginTime>=downandguestorder.beginTime<=up;
END$$
DELIMITER;
过程getLabourParamaters（inrolechar（15）,indowntimestamp,inuptimestamp）
通过传入角色名、开始和结束时间为参数，从而获取计算厨师和后台服务员的劳动量参数。
脚本如下：
DELIMITER$$
DROPPROCEDUREIFEXISTS`restaurantimproved`.`getLabourParamaters`$$
CREATEPROCEDURE`restaurantimproved`.`getLabourParamaters`（inrolechar（15）,indowntimestamp,inuptimestamp）
BEGIN
ifrole='chef'then
selectchef,beginTime,quantityfromguestorderinnerjoinorder_menuon（guestorder.id=order_menu.order_id）whereguestorder.beginTime>=downandguestorder.beginTime<=up;
elseifrole='waiter'then
selectwaiter,beginTime,quantityfromguestorderinnerjoinorder_menuon（guestorder.id=order_menu.order_id）whereguestorder.beginTime>=downandguestorder.beginTime<=up;
endif;
END$$
DELIMITER;
过程getNewID（）
通过调用函数newid（），获取新的guestorder的ID。
脚本如下：
DELIMITER$$
DROPPROCEDUREIFEXISTS`restaurantimproved`.`getNewID`$$
CREATEPROCEDURE`restaurantimproved`.`getNewID`（）
BEGIN
selectnewID（）;
END$$
DELIMITER;
函数
函数newId（）
获取新的guestorder的ID
DELIMITER$$
DROPFUNCTIONIFEXISTS`restaurantimproved`.`newId`$$
CREATEFUNCTION`restaurantimproved`.`newId`（）RETURNSINT
BEGIN
return（selectmax（id）fromguestorder）+1;
END$$
DELIMITER;
5．主要源程序简要说明
我的代码组成主要包括6个包：
data、ui、state、observer、model、myException。
5.1Data包
主要包括访问数据库数据的接口。
Data包的属下还有六个包，分别为：
chart包，为报表系统提供数据访问的接口；frontData提供前台服务员初始化的数据；menuData包提供数据库中menu表的数据访问接口；orderData包提供访问数据库中guestmenu表的接口；roomData包提供访问数据库中的room表的接口；staffData包提供访问数据库中staff表的接口，用来初始化员工们的状态。
5.2Ui包
主要是用户接口的实现源码。
包括如下类：
RunService类
用于启动整个系统服务的程序。
Login类
用于一般用户的登录界面程序。
ChefGroupUI类
用于实现厨师操作界面的程序。
FrontClerkGUI类
用于实现前台服务员的操作界面的程序。
WaiterGroupUI类
用于实现后台服务员操作界面的程序。
ManagerGUI类
用于实现管理员操作界面的程序。
MyChartFactory类
用于实现报表系统的工厂类，可以过类中的createChart（）方法生成报表对象。
5.3State包
主要代表系统的一些环境状态的类组成。
EmployeeState类
枚举员工的工作状态，有两种状态：
working和nonworking。
MenuItemState类
枚举一道菜的状态，Waite表示在等待中，Cooking表示正在制作中，Finished表示制作完毕，Deliver表示已经送到顾客的房间。
OrderState类
枚举一份订单的状态，Waite表示在等待中，Handle表示正在处理中，Finished表示处理完毕，Payed表示已经结账了
Role类
枚举员工的职务，manager表示管理员，chef表示厨师，waiter表示后台服务员，front表示前台音乐。
RoomState类
用单件模式实现的房间的状态集合的类，实现了OrderListObserver接口。
主要的接口有：
isUsing（int）根据房间号判断该房间是否正在使用中；
abandonRoomUsingRight（int）放弃给定房间号的房间的使用权；
getRoomUsingRight（int）获取给定房间号的房间的使用权。
StaffState类
用单件模式实现的员工的状态集合的类。
主要的接口有：
isWorking（Object）判断某个员工是不是在工作状态；
setWorking（Object）设定某个员工的状态为工作状态；
setNonworking（Object）设定某个员工的状态为非工作状态；
isAllNonworking（）判断所有的员工是不是都已经退出系统，处于非工作状态。
5.4Observer包
包含定义的观察者的接口。
MenuItemObserver接口
定义观察具体的一道菜的观察者接口，每个实现了MenuItemObserver接口中的menuItemUpdate（）方法。
被观察者对应model包中的MenuItem类。
OrderListObserver接口
定义观察具体的一道菜的观察者接口，每个实现了OrderListObserver接口中的orderListUpdate（）方法。
被观察者对应model包中的OrderList类。
OrderObserver接口
定义观察具体的一道菜的观察者接口，每个实现了OrderObserver接口中的orderUpdate（）方法。
被观察者对应model包中的Order类。
RoomStateObserver接口
定义观察具体的一道菜的观察者接口，每个实现了RoomStateObserver接口中的roomStateUpdate（）方法。
被观察者对应state包中的RoomState类。
StaffStateObserver接口
定义观察具体的一道菜的观察者接口，每个实现了StaffStateObserver接口中的staffStateUpdate（）方法。
被观察者对应statel包中的StaffState类。
5.5Model包
包含对现实中的模型的映射类，包含了模型层的主要逻辑。
ChefGroup类映射厨师，提供一些基本的操作。
WaiterGroup类映射后台服务员，提供一些基本的操作。
FrontClerk类映射前台台服务员，提供一些基本的操作。
Manager类映射管理员，提供一些基本的操作。
MenuItem类映射一道菜，提供一些基本的操作。
并且作为被观察者，提供添加添加删除观察者和广播观察者的方法。
如：
addObserver（MenuItemObserver）removeObserver（MenuItemObserver）、notifyObservers（）。
Order类映射一份订单，提供一些基本的操作。
并且作为被观察者，提供添加添加删除观察者和广播观察者的方法。
如：
addObserver（OrderObserver）、removeObserver（OrderObserver）、notifyObservers（）。
还有实现MenuItemObserver接口，观察包含的每一道菜的状态。
OrderList类映射订单队列，提供一些基本的操作。
并且作为被观察者，提供添加添加删除观察者和广播观察者的方法。
removeOrder（Order）、addOrder（Order）、not
升级会员 