Eclipse酒店管理系统(java).docxVIP

需求剖析 1.1需求剖析报告 酒店管理系统是面向酒店的的各项事务，包括酒店管理，订单管理、菜系 管理等业务办理工作，是利用计算机进行集中管理而开发的系统。该系统是鉴于Eclipse连结SQLServer2005数库进行开发的酒店管理系统，力争与实际相联合拥有查问、管理等功能，在达到使酒店的管理和营运趋于计算机化，使之更为方便、快捷以提高工作效率。 主要包括五大管理模块： 1)登录管理 提供用户登录、注销等功能 用户登录 用户退出 菜品管理 用户能够对菜名、菜品、单位、助记符等进行查问、改正、增添、删除 操作。 名称 单位 助记符 3）菜系管理 用户能够对酒店内的所有菜系进行查问、改正、增添、删除操作。 菜系名称 4）台号管理 用户能够对酒店内的所有的台号进行查问、改正、增添、删除操作。 台号 座位数 5）结账管理 操作员能够对系统的使用者以及该系统中数据库里的多张表中数据项进行查问操作 日结账 月结账 年结账 6）用户管理 操作员能够进行查问、增添、删除用户信息等操作，并能够改正自己的用户密码 改正密码 用户管理 7）菜单管理 目前操作员能够进行开单、签单、取消等操作，并进行金额结账 开单签单 金额结账 1.2数据流图 客户信息 客户 收银信息 菜单信息  酒店管 理系统  管理人员信息 管理人员 系统管理 图1.顶级数据流图 数据 客 户  前台数据 后台 订餐数据 图2.第二层流程图 数据库观点设计 在酒店管理系统中，存在菜品、菜系、台号、定单、用户等几个对象实体，以菜品、菜系、台号、定单以及用户这几个对象为例，一个定单对应多个菜品，同时一个菜品只能属于一个菜系；一个定单中有多个菜系，一个菜系拥有多个菜品。一个定单对应一个操作员，一个操作员只能对应一个定单；一个定单对应一个台号，一个台号只能对应一个定单。 （1）上述剖析对应的实体-属性图如下所： 编号菜名助记符单位单价种类 菜品 图3.1菜品 编号  菜系名 菜系 图3.2菜系 座位数 台编号 台号 图3.3台号 编号 台号 订购时间 总金额 操作员编号 订单 图3.4订单 编号账单号订单号数量金额 菜品单 图3.5菜品单 用户号用户名性别日期筑面卡号高密码权限 用户 图3.6用户 （2）实体-联系图如下： 用户 1 签单 n 11１n 台号对应订单波及菜品单 １１ 波及波及 n n 菜品 n １ 拥有 菜系 图3.8实体-联系图 数据库的逻辑设计 E-R模型所表示的全局观点构造，是对用户数据需求的一种抽象表示形式，它独立于任何一种数据模型。为了实现用户的需求，必须将观点构造进一步转变为与我们采用的详细的机器上DBMS产品所支持的数据模型相切合的逻辑构造，这就是数据库逻辑设计的任务。 首先要实现的是E-R模型向关系模型的变换，将E-R模型变换为关系模型实际上就是要将实体、实体的属性和实体间的联系变换为关系模式的过程。 这种变换一般按照如下规则： 关于实体种类的变换：将每个实体种类变换成一个关系模式，实体的属性为关系模式的属性，实体的码即为关系模式的码。 关于实体间联系的变换，根据三种不同情况作出不同的办理： 若实体间的联系是1：1，能够在两个实体种类变换成的两个关系模式中的随意一个关系模式的属性中加入另一个关系模式的码和联系的属性。 ②若实体间的联系是1：N，则在N端实体种类变换成的关系模式中加入1 端实体种类变换成的关系模式的码和联系的属性。 ③若实体间的联系是N：M，则将联系种类也变换成关系模式，其属性为两头实体种类的码加上联系种类的属性，而关系的码则为两头实体的码的联合。 经过以上所述原则，由E-R图变换获得如下的关系模式 表4.1系统中所用到的基本信息表及用途 表名用途 Tb_desk台号 Tb_menu菜品 Tb_order_form订单 Tb_order_item菜品单 Tb_sort菜系 Tb_user用户 表4.2台号基本信息表(Tb_desk) 表4.3菜品信息表（Tb_menu） 表4.4订单信息表(Tb_order_form) 表4.5菜品单信息表(Tb_order_item) 表4.6菜系信息表（Tb_sort） 表4.7用户信息表(Tb_user) .4数据库词典 4.1．餐台信息表 表名 tb_desk 序号 字段名 数据种类 拘束 备注 1 num varchar(6) 非空 台号 2 seating int 非空 座位数 3 state char(4) 非空 状态 4.2.管理员表 表名 tb.manager 序号 字段名 序号 字段名 备注 1 id 1 id 编号 2 record_num 2 record_num 用户名 3 password 3 password 登录密码 4 purview_system 4 purvie