点菜信息管理系统的设计与实现

1 引言

1.1 课题背景

现代社会，美食是每个人不可缺少的一部分，现如今，越来越多的人选择去知名的餐厅品尝美食，然而，在这些的知名的餐厅中，由于人的数量太多，所以导致餐厅做菜、上菜不及时，甚至有些客人看见如此庞大的人群堆积在餐厅中，只能对美食望而却步，所以，提升做菜、上菜的效率变的越来越重要。因此，一套高效率的流程标准是解决问题的关键。开发一个基于数据库点菜信息管理系统成为餐厅提高做菜、上菜的效率、接待更多的顾客不可或缺的组成部分。

1.2 选题意义

随着人民生活水平的不断提高，很多的餐厅面临着供不应求的问题，他们的餐厅由于没有一套点菜的标准，导致管理效率底下，浪费了顾客们大量的时间，也导致餐厅流失了很多顾客。所以开发点菜管理系统对于餐厅来说，能节约顾客的大量的时间以及可以帮助餐厅接待更多的顾客。点菜管理系统可以对日常工作中的员工、厨师和顾客等各类数据进行有效地管理，以实现业务的高效率化，提高更多的收益。

2 系统可行性分析

2.1 技术可行性分析

房屋中介管理系统将 SQLite 作为数据库，SQLite 作为开源的关系型数据库，并且具有成本低、体积小、速度快等特点。整个系统是基于 Django 框架搭建的，Django 框架本身就已经拥有了很多基础性的功能，不需要再去重复的完成大量的编码工作，提高了程序的规范性和代码的重用性。采用 Bootstrap4 + jQuery 作为前端的技术支持，后台使用 Python 面向对象语言。由此可见，实现点菜信息管理系统在技术上是完全可行的，并且可以完成点菜信息管理系统所需要的基本功能。

2.2 经济可行性分析

从目前的社会现状来看传统的点菜模式不仅浪费时间，效率低下，而且特别耗费成本与人力。于此不同，使用点菜信息管理系统能大大降低人力的成本这样就节省了相对应的成本开销，避免人员的冗余，并且开发系统使用的工具和技术都是开源的，投入该系统的成本并不高。所以对于餐馆来说开发一个点菜信息管理系统在当前的资金投入和使用该系统降低的成本上是可以接受的，由此来看此系统从经济上来看是可行的。

2.3 操作可行性分析

该系统使用的技术都是目前大众普遍使用的，并且操作简单，业务逻辑流程条例清晰，使用方便，并且用户使用起来上手快，容易理解，不需要理解太深的东西。由此来看，该系统从操作上来看是可行的。

3 系统分析

3.1 系统功能分析

该系统为点菜管理信息系统。网上点菜系统是一种可以自主选择、个性化、便捷化、特色化的点餐模式，它的大力推广使用为餐厅节约了成本，同时也解决了消费者在传统点菜时存在的不少麻烦。通过对系统的需求进行分析得出，该系统的功能模块分为三种，分别是管理员模块、用户模块、后厨模块，并且各个用户模块下对应着各自的功能实现。

3.1.1 管理员模块

管理员登录：对于已经存在管理员可进行登录。
订单信息查询：管理员可以查询系统内所有存在订单。
职工信息管理：管理员可以登录该系统对已经注册的职工个人信息进行增加、删除、改动、查找等操作。
餐桌信息管理：管理员可以对该系统对已经存在的餐桌信息进行增加、删除、改动、查找等操作。
菜品信息管理：管理员可以对该系统对已经存在的菜品信息进行增加、删除、改动、查找等操作。

管理员的用例图如图 1 所示。

图 1 管理员用例图

3.1.2 用户模块

选择桌号：顾客通过自主选择餐桌进入点菜。
菜谱信息查看：展示所有菜品类及菜品。
下单点菜：顾客可以自主选择及菜品来进行下单。
订单信息查看：顾客可以对自己的订单明细进行查询核对。
结账：结账时先核对订单，然后再进行对订单的批量支付或者全部支付。

用户的用例图如图 2 所示。

图 2 用户用例图

3.1.3 后厨模块

后厨登录：对于已经存在后厨可进行登录。
后厨接单：对于已经存在的订单可以接单。
后厨上菜：对于已经接单的订单可以上菜。
菜单信息查看：对用户下单的菜品、价格等进行查看操作
订单信息查看：对已经存在的订单可以查看信息和状态（等待后厨接单、后厨已接单、等待上菜、上菜完成）。

后厨的用例图如图 3 所示。

图 3 后厨用例图

3.2 系统业务流程分析

该系统根据不同用户都有对应的业务流程。

（1）管理员更新职工信息操作的业务流程图，如图 4 所示。

图 4 更新职工信息业务流程图

（2）顾客实现点菜和结账的业务流程图，如图 5 所示。

图 5 顾客业务流程图

（3）后厨进行接单操作的业务流程图，如图 6 所示。

图 6 后厨接单业务流程图

3.3 系统数据流程分析

该系统通过数据流程图进行系统的数据流程分析。

1 顾客下单点菜操作、管理员后台管理和后厨进行配菜的顶层数据流程图，如图 7 所示。

图 7 顶层数据流图

2 顾客下单点菜操作的第二层数据流程图，如图 8 所示。

图 8 第二层数据流图

3 顾客下单点菜操作的第三层流程图，如图 9 所示。

图 9 第三层数据流图

3.4 数据字典

1 数据项

以下是本系统关于核心数据项的具体描述，包括编号、名称、含义说明、类型、长度、取值范围、取值含义、与其他逻辑项之间的关系与其他关系如表 2.1 所示。

表 2.1 数据项

编号	名称	含义说明	类型	数值约束	与其他逻辑项；之间的关系
I1	菜品编号	唯一标识菜品	整数型	1-999	为菜品记录；表的主码
I2	菜品类编号	唯一标识菜品类	整数型	1-999	为菜品类记录；表的主码
I3	订单编号	唯一标识订单	整数型	1-9999	为订单记录；表的主码
I4	职工编号	唯一标识职工	整数型	1-999	为职工记录；表的主码
I5	餐桌编号	唯一标识餐桌	整数型	1-999	为餐桌记录；表的主码
I6	身份证号	职工的身份证号	字符串型	18	为职工记录表；的身份证号码
I7	手机号	职工的手机号	字符串型	11	为职工记录表；的手机号码

2 数据结构

以下是本系统关于核心数据项的具体描述，包括编号、数据结构名、含义说明、组成之间的关系如表 2.2 所示。

表 2.2 数据结构

编号	名称	含义说明	组成
S1	菜品基本信息	菜品的基本信息	菜品编号，菜品种类编号，菜名，制作时间，数量，价格
S2	菜品类基本信息	菜品类的基本信息	菜品种类编号，菜品类名称
S3	订单基本信息	订单的基本信息	订单编号，餐桌编号，菜品总数，消费金额，下单时间，备注信息，支付时间，负责职工编号，支付状态
S4	订单明细信息	订单的明细信息	订单编号，菜品编号，菜品金额，菜品数量，备注信息，订单状态，接单时间，完成时间
S5	职工基本信息	职工的基本信息	职工编号，身份证号，姓名，性别，出生日期，联系方式，联系地址
S6	餐桌基本信息	餐桌的基本信息	餐桌编号，餐桌名字，负责职工编号

3 数据流

以下是本系统关于数据流的具体描述，包括名称、来源、去向如表 2.3 所示。

表 2.3 数据流

名称	说明	来源	去向	组成
F1 点菜请求	顾客查看菜单，进行点菜	菜品基本信息	点菜请求处理	菜品编号，菜品种类编号，菜名，制作时间，数量职工编号，支付状态
F2 结账请求	顾客查看订单详情，进行结账	订单基本信息	结账请求处理	订单编号，餐桌编号，菜品总数，消费金额，下单时间，备注信息，支付时间，负责职工编号，支付状态
F3 接单	管理员查询订单信息，进行查看	后厨	订单详细信息	订单编号，菜品编号，菜品数量，消费金额，备注信息，订单状态，接单时间，完成时间
F4 上菜	管理员查询订单信息，进行查看	后厨	订单处理	订单编号，餐桌编号，菜品总数，消费金额，下单时间，备注信息，支付时间，负责职工编号，支付状态
F5 存储订单信息	管理员查看餐桌信息，修改餐桌负责人	点菜请求处理	订单基本信息表	订单编号，餐桌编号，菜品总数，消费金额，下单时间，备注信息，支付时间，负责职工编号，支付状态

4 数据存储

以下是本系统关于数据存储的具体描述，包括编号、名称、说明、来源、去向、组成如表 2.4 所示。

表 2.4 数据存储

名称	说明	来源	去向	组成
订单记录文件	所有订单信息	菜品信息表；餐桌信息表	Null	订单编号，菜品金额，菜品编号，菜品数量，消费金额，备注信息，订单状态，接单时间，完成时间

5 处理过程

以下是本系统关于处理过程的具体描述，包括编号、名称、说明、输入、输出、处理过程描述如表 2.5 所示。

表 2.5 处理过程

编号	名称	说明	输入	输出	处理过程描述
P1	下单点菜请求处理	接收点菜请求根据情况配菜，上菜	F1 点菜请求	F4 后厨接单；F5 后厨完成	接收顾客的点菜请求，后厨点击接单，等待后厨完成后进行上菜。
P2	结账请求处理	接收结账请求信息记录，更改订单信息	F2 结账请求	F5 订单信息	接受顾客的结账请求，并记录到订单信息表和订单明细表中

4 系统设计

4.1 功能结构设计

该系统的开发目的是相对比传统点菜的模式更加方便、有效地处理顾客下单点菜信息，方便需求人群的使用而开发的。主要的功能模块为：浏览菜谱、生成订单、结账、查询订单、职工信息操作、保存订单等。系统角色分为：后台管理模块、用户端模块、后厨模块。该系统的整体结构功能图如图 10 所示。

图 10 系统整体结构功能图

4.2 数据库设计

4.2.1 数据库概念结构设计

根据该系统所需的开发要求，通过实体属性图和 E-R 图来描述该系统的概念模型。

1 菜品类实体属性图，如图 11 所示。

图 11 菜品类实体属性图

2 菜品实体属性图，如图 12 所示。

图 12 菜品实体属性图

3 订单基本信息实体属性图，如图 13 所示。

图 13 订单基本信息实体属性图

4 职工实体属性图，如图 14 所示。

图 14 职工实体属性图

5 系统总体 E-R 图，如图 15 所示。

图 15 总体 E-R 图

4.2.2 将 E-R 图转换为关系模型

将 E-R 图转换为关系模式的转换规则如下：

1 实体转换为模式时，一个实体转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的码。

2 联系转换成为关系模式。

联系转换成为关系模式时，要根据联系方式的不同采用不同的转换方式。

①1:1 联系的转换方法

将 1:1 联系与某一端实体集所对应的关系合并，则需要在被合并关系中添加属性，其新增的属性为联系本身的属性和与联系相关的另一个实体集的码。

②1:n 联系的转换方法

在 n 端实体集中添加新属性，新属性由联系对应的 1 端实体集的码和联系自身的属性构成，新增属性后原关系的码不变。

③m:n 联系的转换方法

在向关系模型转换时，一个 m:n 联系转换为一个关系。

转换方法为：与该联系相连的各实体集的码以及联系本身的属性均转换为关系的属性，新关系的码作为两个相连实体码的组合（该码为多属性构成的组合码）。

依据以上转换规则，将 E-R 图转换为以下关系模式：

菜品类（菜品种类编号，菜品类名称），根据菜品类实体直接转换得到。

职工基本信息（职工编号，身份证号码，姓名，性别，出生日期，手机号码，联系地址），根据职工基本信息实体直接转换得到。

订单基本信息（订单编号，餐桌编号，菜品总数，消费金额，下单时间，备注信息，支付时间，负责职工编号，支付状态），根据菜品类实体和菜品基本信息实体的一对多关系转换得到。

餐桌基本信息（餐桌编号，餐桌名字，负责职工编号），根据职工基本信息实体负责餐桌基本信息实体的一对多关系转换得到。

订单明细信息（订单编号，菜品编号，菜品金额，菜品数量，备注信息，订单状态，接单时间，完成时间），根据选择菜品基本信息实体生成订单基本信息实体的多对多关系转换得到。

4.2.3 关系模式的规范化

关系模式菜品类（菜品编号，菜品名称），候选码为菜品编号，主属性为菜品编号，非主属性为菜品名称，选定主码为菜品编号，则存在函数依赖集为（菜品编号-> 菜品名称）不存在非主属性对码的部分函数依赖，也不存在非主属性对码的传递函数依赖，因此所以应付款项关系模式至少已经达到了 3NF。

关系模式菜品（菜品编号，菜品种类编号，菜名，制作时间，数量，价格），候选码为菜品编号，主属性为菜品编号，非主属性为菜品种类编号，菜名，制作时间，数量，价格，选定主码为菜品编号，则存在函数依赖集为（菜品编号-> 菜品种类编号，菜品编号 -> 菜名，菜品编号-> 制作时间, 菜品编号-> 数量，菜品编号-> 价格）不存在非主属性对码的部分函数依赖，也不存在非主属性对码的传递函数依赖，所以应付款项关系模式至少已经达到了 3NF。

关系模式订单基本信息（订单编号，餐桌编号，菜品总数，消费金额，下单时间，备注信息，支付时间，负责职工编号，支付状态），候选码为订单编号，主属性为订单编号，非主属性为餐桌编号，菜品总数，消费金额，下单时间，备注信息，支付时间，负责职工编号，支付状态，选定主码为订单编号，则存在函数依赖集为（订单编号-> 餐桌编号，订单编号 -> 菜品总数，订单编号-> 消费金额，订单编号-> 下单时间，订单编号-> 备注信息，订单编号-> 支付时间，订单编号-> 负责职工编号，订单编号-> 支付状态）不存在非主属性对码的部分函数依赖，也不存在非主属性对码的传递函数依赖，所以应付款项关系模式至少已经达到了 3NF。

关系模式订单明细信息（订单编号，菜品编号，菜品金额，菜品数量，备注信息，订单状态，接单时间，完成时间），候选码为（订单编号，菜品编号），主属性为（订单编号，菜品编号），非主属性为菜品金额，菜品数量，备注信息，订单状态，接单时间，完成时间，选定主码为（订单编号，菜品编号），则存在函数依赖集为{（订单编号，菜品编号）-> 菜品金额，（订单编号，菜品编号）-> 菜品数量，（订单编号，菜品编号）-> 备注信息，（订单编号，菜品编号）-> 订单状态，（订单编号，菜品编号）-> 接单时间，（订单编号，菜品编号）-> 完成时间}不存在非主属性对码的部分函数依赖，也不存在非主属性对码的传递函数依赖，所以应付款项关系模式至少已经达到了 3NF。

关系模式职工基本信息（职工编号，身份证号码，姓名，性别，出生日期，手机号码，联系地址），候选码为职工编号，主属性为职工编号，非主属性为身份证号码，姓名，性别，出生日期，手机号码，联系地址，选定主码为职工编号，则存在函数依赖集为（职工编号-> 身份证号码，职工编号-> 姓名，职工编号-> 性别，职工编号-> 出生日期，职工编号-> 手机号码，职工编号-> 联系地址）不存在非主属性对码的部分函数依赖，也不存在非主属性对码的传递函数依赖，所以应付款项关系模式至少已经达到了 3NF。

4.2.4 数据库表设计

本系统设计了共计七张数据库表，其中主要的表为：菜品类表、菜品表、订单基本信息表、订单详细信息表、职工基本信息表、餐桌基本信息表。

其他表的整体结构和上述表结构基本一致便不再一一赘述，仅介绍主要的这几种表设计。

菜品类表主要记录了各种菜品的信息，如表 1 foodtype 菜品类表所示。

表 1 foodtype 菜品类表

序号	字段	类型	长度	长度	含义
1	Id	int		菜品种类编号	菜品种类编号
2	Name	Varchar	20	20	菜品类名称

菜品表主要记录了菜品的信息。如表 2 food 菜品表所示。

表 2 food 菜品表

序号	字段	类型	长度	长度	含义
1	id	int			菜品编号
2	food-Type_id	int		菜品种类编号	菜品种类编号
3	title	varchar	20	20	菜名
4	cost_time	int			制作时间
5	amount	int			数量
6	price	float			价格

订单基本信息表主要记录了订单的基本信息，如表 3 order 订单基本信息表所示。

表 3 order 订单基本信息表

序号	字段	类型	长度	含义
1	id	int		订单编号
2	table_id	int		餐桌编号
3	food-amount	int		菜品总数
4	table_price	float		消费金额
5	create_time	Varchar	20	下单时间
6	comment	varchar	50	备注信息
7	pay_time	varchar	20	支付时间
8	staff_id	int	11	负责职工编号
9	Is_pay	boolean		支付状态

已订单明细表主要记录了订单的各种基本信息，如表 4 订单明细 order_item 表所示。

表 4 orderitem 订单明细表

序号	字段	类型	长度	含义
1；2	order_id；number	int；int	；	订单编号；菜品数量
3	food_id	int		菜品编号
4	food_price	float		菜品金额
5	comment	varchar	50	备注信息
6	status	int		订单状态
7	start_cook_time	time		接单时间
8	end_cook_time	time		完成时间

职工基本信息表主要记录了职工的基本信息。如表 5 staff 职工基本信息表所示。

表 5 staff 职工基本信息表

序号	字段	类型	长度	含义
1	id	int		职工编号
2	Staff_id	varchar	18	身份证号码
3	name	varchar	20	姓名
4	gender	varchar	5	性别
5	born_date	date		出生日期
6	phone	varchar	11	手机号码
7	address	varchar	50	联系地址

餐桌基本信息表主要记录了餐桌的基本信息，如表 6 staff_table 餐桌基本信息表所示。

表 6 staff_table 餐桌基本信息表

序号	字段	类型	长度	含义
1	id	int		餐桌编号
2	table_name	varchar	20	餐桌名字
3	staff_id	int		负责职工编号

4.2.5 数据库表中约束设计

为保证数据库表中数据的完整性和一致性，针对数据库中表的结构，设计了以下约束。

1 菜品基本信息表中，菜品编号唯一。

c++ ALTER TABLE OrderSysterm_food add constraint check_food unique(ID);

2 菜品类基本信息表中，菜品类的编号唯一。

c++ ALTER TABLE OrderSysterm_foodtype add constraint check_foodtype unique(ID);

3 订单基本信息表中，订单编号唯一。

c++ ALTER TABLE OrderSysterm_order add constraint check_order unique(ID);

4 员工基本信息表中，员工联系方式的长度为 11 位。

c++ ALTER TABLE OrderSysterm_staff add constraint check_AdminUserTel check(phone like '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]');

5 员工基本信息表中，员工身份证号的长度为 18 位。

c++ ALTER TABLE OrderSysterm_staff add constraint check_AdminUserTel check(citizenID like '^([1-9]\d{5}[12]\d{3}(0[1-9]|1[012])(0[1-9]|[12][0-9]|3[01])\d{3}[0-9xX])$');

5 系统实现

使用该系统的第一步便是选择身份，该系统分配了顾客、后厨和管理员三种角色进行登录跳转到各自对应的主界面中，实现各自的功能操作。主界面如图 16 所示。

图 16 主界面

5.1 顾客页面实现

1 顾客点菜界面

在主界面中点击点菜，即可进入顾客点菜页面，在选择好菜品后点击桌号，即可选择当前桌号，点击提交即可生成订单。如图 17 所示。

图 17 顾客点菜界面

2 顾客订单详情界面

在顾客选菜界面中点击提交后即可进入顾客订单界面，此界面显示下单的数量、金额、时间、是否支付等。如图 18 所示。

图 18 顾客订单详情界面

3 顾客支付订单界面

在顾客订单详情界面中核对订单详情后，点击支付订单，点击确定支付，即可完成支付。如图 19 所示。

图 19 顾客支付订单界面

5.2 后厨页面实现

1 后厨登陆界面

在主界面中点击后厨，即可进入后厨的登陆界面。如图 20 所示。

图 20 后厨的登陆界面

2 后厨接单界面

输入账号密码后，即可进入后厨界面。在顾客生成订单后，后厨可以点击接单和完成，完成后等待管理员点击上菜（此界面 30 秒动态刷新订单信息）。如图 21 所示。

图 21 后厨接单界面

5.3 管理员页面实现

1 管理员登陆界面

在主界面中点击管理，即可进入管理员登陆界面。如图 22 所示。

图 22 管理员登陆界面

2 管理员界面

输入账号密码即可进入管理员界面，如图 23 所示。

图 23 管理员界面

3 管理员结账界面

在管理员界面中，点击结账即可系统已经存在的和未结账的订单进行结账处理。如图 24 所示。

图 24 管理员结账界面

4 管理员查看订单界面

在管理员界面中，点击订单即可查询系统内所有存在订单（包括结账和未结账的订单）。如图 25 所示。

图 25 管理员查看订单界面

5 管理员管理职工界面

在管理员界面中，点击员工即可查询系统内所有存在的员工信息，在此界面可以对已经注册的职工个人信息进行增加、删除、改动、查找等操作。如图 26 所示。

图 26 管理员管理职工界面

6 管理员管理餐桌界面

在管理员界面中，点击餐桌即可查询系统内所有存在的餐桌信息，在此界面可以对已经存在的餐桌信息进行增加、删除、改动、查找等操作。如图 27 所示。

图 27 管理员管理餐桌界面

7 管理员管理菜品界面

在管理员界面中，点击菜品即可查询系统内所有存在的菜品信息，在此界面可以对已经存在的菜品信息进行增加、删除、改动、查找等操作。如图 28 所示。

图 28 管理员管理菜品界面

6 总结

这次的数据库课程设计只有一个星期的时间，而我们需要将在数据库课堂上和实验中学习到的知识运用到实际的管理系统中，还需要设计相应的界面，这着实不是一件容易的事情。

确定选择“点菜管理信息系统”这个题目后，我们通过查找相关资料以及自己对点菜系统的理解确定了需要做的几个主要功能：点菜、结账等，然后拓展到现在的所有功能。功能的完善大多是在开发过程中因为实际需要而发现问题并解决的，还有的是为了更人性化更适合用户角度使用而添加的，相应的数据库表单也是在开发过程中逐步完善。在开发过程中遇到很多问题，比如订单的几个数据项前前后后改了很多次，因为生成订单需要前后端沟通，每次修改也就会耗费许多时间来进行调试，而如果一开始就能详细地对订单表进行描述，在后期不需要添加新的主属性，那么一定会减少很多可压缩的调试时间。

在开发技术方面，这次尝试了 Python 的 Web 框架 Django 作为后端的 Web 应用，后端的数据库使用了 Django 推荐的 SQLite ，虽然不适合实际生产环境，但是便于上手，也使得我们能够在系统的其他地方进行一点点细节上的打磨，前端使用了 Bootstrap4 + jQuery 来开发。在开发前期，许多时间用在了前端的细节优化上，通过 Bootstrap 将界面统一风格，也因此将管理页面中订单和上菜提醒直观表现出来，不需要进入二级菜单就能将上菜信息传达上来。在后期逐渐将数据存储所需的约束与触发操作完善。

这次数据库课设对我们来说是一个综合能力的考验，也是将数据库系统与所学知识的结合，通过这次课设，我对数据库设计能力有了很大提高，也学会了在应用中引入数据库、维护数据库，不过所体现的问题也是以后需要不断学习、实践的地方。