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

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 菜品基本信息表中，菜品编号唯一。

ALTER TABLE OrderSysterm_food
add constraint check_food
unique(ID);

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

ALTER TABLE OrderSysterm_foodtype
add constraint check_foodtype
unique(ID);

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

ALTER TABLE OrderSysterm_order
add constraint check_order
unique(ID);

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

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 位。

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])$');