《数据库课程设计餐饮管理系统.docx》由会员分享，可在线阅读，更多相关《数据库课程设计餐饮管理系统.docx（10页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、数据库课程设计餐饮管理系统 数据库系统原理课程设计报告 课题名称：_ 餐饮管理系统_ 专业班级： 学号： 姓名：_ 指导老师： 2022年6月 一、课题名称 餐饮管理系统 餐饮管理系统功能主要包括客人点菜、结账、对员工资料进行管理、对餐桌信息进行统一设置、对消费情况进行查询、对系统权限进行设置等功能。基本功能如下：（1）餐桌信息查询：实现能查询当前饭店中说有餐桌使用情况，即哪些餐桌已用，哪些未用，客人可以对未使用的餐桌进行使用申请。 （2）客人点菜：实现客人点菜功能。当客人餐桌申请后，点击申请的餐桌，可以在饭店提供的菜单上实现点菜，点菜后提交，生成订单，用于结账。 （3）客人结账：实现客人结账
2、功能。当客人吃晚饭后，可以点击相应的餐桌，实现结账。 (4)登录：系统根据用户名和密码登录后台。此处用户分为管理员用户和营业员。管理员用户拥有后台所有权限；营业员即饭店员工。 （5）管理员功能：管理员登录后台后，可以维护餐桌、菜单、营业员用户的基本信息，包括对信息的增加、查询、修改、删除等功能。 （6）营业员功能：可以对自己的信息进行修改，并可以实现对客人点菜后及结账后餐桌的管理，即客户点菜后，其申请的餐桌其他客人不能申请使用，只有当客人结账后，其餐桌才可被申请使用；营业员还具有对生成的账单管理功能，当客人结账时，通知其结账费用。 二、需求分析 第（一）部分调查用户需求 本系统的最终用户为餐厅
3、管理员，本餐厅的营业员以及客人。根据日常生活中的经验，得出用户的下列实际要求： A、餐厅的基本情况 餐厅里有餐桌、客人、菜单、订单、账单、营业员、管理员 1、餐桌的基本信息 每个餐桌都有唯一的餐桌号，有相应的座位数，以及使用状况 2、菜单的基本信息 菜单中的每样菜都有唯一的菜号，每样菜有相应的菜名、价格 3、订单基本信息 每个订单都有唯一的订单号，对应的餐桌号，菜号、点菜日期 4、账单的基本信息 每个账单有唯一的账单号，对应的订单号，菜的总价格，及收银人员（即营业员），支付日期 5、营业员的基本信息 每个营业员有唯一的工号，对应的姓名、性别、年龄、工资 B、用户对系统的要求 1、客人 1）信息
4、要求 能够了解餐桌使用状况、菜单的基本信息、生成订单 2）处理要求 申请可用餐桌的使用权，根据菜单的基本信息生成订单 2、营业员 1）信息要求 营业员能够了解餐桌使用状况、菜单的基本信息、订单的基本信息、账单的基本信 息、自己的基本信息。 2）处理要求 可以修改自己个人的基本信息；由菜单及订单的基本信息生成账单；根据账单的菜 总价通知客人所需支付的钱数并收取费用；当客人结账后，营业员将其所对应的餐 桌使用状况设置为可用 3、管理员 1）信息要求 管理员能够了解餐桌的状况、菜单的基本信息、营业员的基本信息 2）处理要求 可以对餐桌、菜单、营业员的基本信息进行增加、查询、修改、删除等操作 4、安全
5、性要求 系统应设置访问用户的标识以鉴别是否是合法用户，并要求合法用户设置其密码，保证用户身份不被盗用； 系统应对不同的数据设置不同的访问级别，限制访问用户可查询和处理数据的类别和内容； 系统应对不同用户设置不同的权限，区分不同的用户，如区分普通用户（营业员），管理员。 5、完整性要求 各种信息记录的完整性，信息记录内容不能为空； 各种数据间相互的联系的正确性； 相同的数据在不同记录中的一致性。 第(二)部分系统功能的设计和划分 根据如上得到的用户需求，我将本系统按照所完成的功能分成以下几部分： A、用户管理部分 1、处理用户登录 2、用户可以查询、申请餐桌。 3、用户可以查询菜单信息。 4、用
6、户可以提交生成订单信息。 B、管理员管理部分 1、处理管理员、营业员登录 2、管理员可以查询餐厅的餐桌、菜单、营业员信息。 3、管理员可以更新餐厅的餐桌、菜单、营业员信息。 4、营业员可以查询餐桌、菜单、订单、账单、个人信息 5、管理员可以更新餐桌、账单、个人的基本信息 6、管理员、营业员可以修改管理员密码。 第(三)部分数据流图 图2.1 餐桌分数据流图 图2.2 菜单分数据流图 图2.4 账单分数据流图 图2.3 订单分数据流图 图2.5 营业员分数据流图 图2.6 总数据流图 第（四）部分数据字典 A、数据项 表2.1 餐桌数据字典 表2.2 菜单数据字典 表2.3 订单数据字典 表2.
7、4 营业员数据字典 表2.5 账单数据字典 表2.6 管理员数据字典 B、数据结构 三、概念结构设计 第（一）部分局部E-R图 图3.1 餐桌的实体及属性图（别的实体属性图略）说明：图3.2 .(13) 局部实体关系E-R图 图 3.2.1客人及其关系局部E-R图 图 3.2.2营业员管理及其关系局部E-R图 图 3.2.3管理员管理及其关系局部E-R图第(二)部分全局E-R图 四、逻辑结构设计 第（一）部分E-R图向关系模型的转换 A、转换规则 一个实体型转换为一个关系模式。实体的属性就是关系的属性，实体的码就是冠希的码。 实体型间的联系常有如下不同的情况： 1、一个1：1联系可以转换为一个
8、独立的关系模式，也可以与任意一端对应的关系模式合并。 2、一个1：n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。 3、一个m：n联系转换为一个关系模式。 4、3或3个以上实体间的一个多联系可以转换为一个关系模式。 5、具有相同码的关系模式可合并。 B、根据以上规则得到如下关系模型： 餐桌（餐桌号，座位数，使用状况）餐桌号为主码 菜单（菜号，菜名，价格）菜号为主码 订单（订单号，餐桌号，菜号，点菜日期）前三个为主码 营业员（工号，姓名，性别，年龄，工资，密码）工号为主码 账单（账单号，订单号，总价格，工号，结账日期，）账单号为主码 管理员（用户ID，用户密码）用户ID为主码
9、 说明：E-R图中存在的m：n关系不需要转换为一个关系模式，因为所有营业员可管理全部餐桌与账单；所有管理员可管理全部餐桌、营业员、菜单。 第（二）部分优化 A、确定数据依赖。 B、对各个关系模式间的数据依赖进行极小化分析，减小冗余。 C、按照数据依赖的理论对关系模式进行分析，看是否存在部分函数依赖或函数传递依赖或 多值依赖等，确保各关系模式满足第三范式。 D、按照需求分析阶段得到的处理要求，分析对于这样的应用环境这些模式是否合适，确定 是否要对某些模式进行合并或分解。 E、对关系模式进行必要的分解，提高数据操作的效率和存储空间的利用率。 第（三）部分用户子模式 A、规则 1、使用更符合用户习惯的别名。 2、可以对不同级别的用户定义不同的VIEW，以保证系统的安全。 3、简化用户对系统的使用。 B、根据上述规则将上面关系模型转为以下模型： D（Dno,Dch,Dsta） C (Cno,Cna,Cpr) R(Rno,Dno,Cno,Rtime) W(Wno,Wna,Wsex,Wage,Wwag,Wsec) M(Mno,Rno,Mpr,Wno,Mtime) U(Uname,Upassword)