Design and Realization of Order Information Management System

1 Introduction

1.1 Subject background

In modern society, food is an indispensable part of everyone. Nowadays, more and more people choose to go to well-known restaurants to taste food. However, in these well-known restaurants, due to the large number of people, restaurants do The dishes and serving are not timely, and some customers even see such a huge crowd piled up in the restaurant, they can only be discouraged by the food, so it is becoming more and more important to improve the efficiency of cooking and serving. Therefore, a set of efficient process standards is the key to solving the problem. Developing a database-based ordering information management system has become an indispensable part for restaurants to improve cooking and serving efficiency and receive more customers.

1.2 Significance of topic selection

With the continuous improvement of people's living standards, many restaurants are facing the problem of short supply. Their restaurants do not have a set of ordering standards, resulting in low management efficiency, wasting a lot of time for customers, and causing the restaurant to lose many customers. . Therefore, the development of an order management system for restaurants can save a lot of time for customers and help restaurants receive more customers. The order management system can effectively manage various data such as employees, chefs and customers in daily work, so as to achieve high business efficiency and increase more revenue.

2 System Feasibility Analysis

2.1 Technical Feasibility Analysis

The housing intermediary management system uses SQLite as the database, and SQLite is an open source relational database, and has the characteristics of low cost, small size, and fast speed. The whole system is built based on the Django framework. The Django framework itself already has many basic functions, and there is no need to repeat a lot of coding work, which improves the standardization of the program and the reusability of the code. Bootstrap4 + jQuery is used as the technical support of the front end, and Python object-oriented language is used in the background. It can be seen that it is technically feasible to realize the ordering information management system, and can complete the basic functions required by the ordering information management system.

2.2 Economic Feasibility Analysis

Judging from the current social situation, the traditional ordering mode is not only a waste of time and inefficient, but also particularly costly and manpower-consuming. Different from this, using the à la carte information management system can greatly reduce the cost of manpower, which saves the corresponding cost and avoids redundancy of personnel, and the tools and technologies used in the development system are all open source, and the cost of investing in the system Not high. Therefore, it is acceptable for restaurants to develop an order information management system in terms of current capital investment and the reduced cost of using the system. From this point of view, the system is economically feasible.

2.3 Operation Feasibility Analysis

The technology used in this system is currently commonly used by the public, and the operation is simple, the business logic process regulations are clear, and it is easy to use, and the user is quick to use it, easy to understand, and does not need to understand too deep. From this point of view, the system is feasible from an operational point of view.

3 System Analysis

3.1 System function analysis

The system is an a la carte management information system. The online ordering system is a self-selecting, personalized, convenient, and characteristic ordering mode. Its vigorous promotion and use has saved costs for restaurants, and at the same time solved many problems that consumers have when ordering traditionally. trouble. Through the analysis of the requirements of the system, it is concluded that the functional modules of the system are divided into three types, namely the administrator module, user module, and kitchen module, and each user module corresponds to its own function realization.

3.1.1 Administrator module

Administrator login: For existing administrators, you can log in.
Order information query: administrators can query all existing orders in the system.
Employee information management: administrators can log in to the system to add, delete, modify, search and other operations on registered employee personal information.
Table information management: The administrator can add, delete, modify, search and other operations to the existing table information in the system.
Dishes information management: administrators can add, delete, modify, search and other operations to the existing dish information in the system.

The administrator's use case diagram is shown in Figure 1.

Figure 1 Administrator use case diagram

3.1.2 User modules

Select the table number: Customers can order food by choosing the table independently.
Recipe information viewing: display all dishes and dishes.
Order a la carte: customers can choose their own dishes and dishes to place an order.
View order information: Customers can check their order details.
Checkout: When checking out, check the order first, and then make a batch payment or full payment for the order.

The user's use case diagram is shown in Figure 2.

Figure 2 User use case diagram

3.1.3 Back kitchen module

Back kitchen login: You can log in to the existing back kitchen.
Receiving orders in the back kitchen: orders can be received for existing orders.
Serving in the back kitchen: For orders that have already been placed, dishes can be served.
View menu information: view the dishes and prices ordered by the user
View order information: You can view the information and status of existing orders (waiting for the back kitchen to receive the order, the back kitchen has received the order, waiting for the food to be served, and the food to be served).

The use case diagram of the back kitchen is shown in Figure 3.

Figure 3 Example diagram of back kitchen

3.2 System business process analysis

The system has corresponding business processes according to different users.

(1) The business flow chart of the administrator updating employee information operation, as shown in Figure 4.

Figure 4 Business flow chart for updating employee information

(2) The business flow chart of ordering and checkout for customers, as shown in Figure 5.

Figure 5 Customer business flow chart

(3) The business flow chart of the kitchen receiving orders, as shown in Figure 6.

Figure 6 Business flow chart of receiving orders in the back kitchen

3.3 System data flow analysis

The system analyzes the data flow of the system through the data flow chart.

1 The top-level data flow chart of customer ordering operation, administrator background management and back kitchen garnishing, as shown in Figure 7.

Figure 7 Top-level data flow diagram

2 The data flow chart of the second layer of the customer's ordering operation is shown in Figure 8.

Figure 8 The second layer data flow diagram

3 The flow chart of the third layer of the customer's ordering operation is shown in Figure 9.

Figure 9 Layer 3 data flow diagram

3.4 Data Dictionary

1 data item

The following is the specific description of the core data items of this system, including the number, name, meaning description, type, length, value range, value meaning, and the relationship with other logical items and other relationships as shown in Table 2.1.

Table 2.1 Data Items

serial number	name	Meaning	type	numerical constraints	relationship with other logical items;
I1	dish number	Uniquely identify the dish	Integer	1-999	Record for the dishes; the main key of the table
I2	dish category number	Uniquely identifies the dish category	Integer	1-999	Record for the dish category; the main key of the table
I3	order number	uniquely identifies the order	Integer	1-9999	is the order record; the primary key of the table
I4	employee number	Uniquely identifies the employee	Integer	1-999	Record for employee; primary key of table
I5	table number	Uniquely identify the dining table	Integer	1-999	record for table; master key of table
I6	ID number	Employee's ID number	string type	18	Record sheet for employees; ID number
i7	Phone number	Employee's mobile phone number	string type	11	Record sheet for employees; mobile phone number

2 data structure

The following is the specific description of the core data items of this system, including the number, data structure name, meaning description, and the relationship between components, as shown in Table 2.2.

Table 2.2 Data Structure

serial number	name	Meaning	composition
S1	Basic information of dishes	Basic information of dishes	Dish ID, Dish Type ID, Dish Name, Production Time, Quantity, Price
S2	Basic information of dishes	Basic information of dishes	dish category number, dish category name
S3	Basic order information	Basic information of the order	Order number, table number, total number of dishes, consumption amount, order time, remark information, payment time, responsible employee number, payment status
S4	Order Details	order details	Order number, dish number, dish amount, dish quantity, remarks, order status, order receiving time, completion time
S5	Basic information of employees	Basic information of employees	Employee number, ID number, name, gender, date of birth, contact information, contact address
S6	Table basic information	Basic information about the dining table	Table number, table name, employee number in charge

3 data flow

The following is a specific description of the data flow in this system, including the name, source, and destination, as shown in Table 2.3.

Table 2.3 Data Flow

name	illustrate	source	whereabouts	composition
F1 A la carte request	Customers view the menu and order	Basic information of dishes	A la carte request processing	Dish number, dish type number, dish name, production time, quantity employee number, payment status
F2 Checkout Request	The customer checks the order details and proceeds to checkout	Basic order information	Checkout request processing	Order number, table number, total number of dishes, consumption amount, order time, remark information, payment time, responsible employee number, payment status
F3 order	The administrator queries the order information and checks it	back kitchen	order details	Order number, dish number, dish quantity, consumption amount, remarks information, order status, order receiving time, completion time
F4 serving	The administrator queries the order information and checks it	back kitchen	order processing	Order number, table number, total number of dishes, consumption amount, order time, remark information, payment time, responsible employee number, payment status
F5 stores order information	The administrator checks the table information and modifies the person in charge of the table	A la carte request processing	Order Basic Information Form	Order number, table number, total number of dishes, consumption amount, order time, remark information, payment time, responsible employee number, payment status

4 data storage

The following is a specific description of the data storage in this system, including number, name, description, source, destination, and composition, as shown in Table 2.4.

Table 2.4 Data Storage

name	illustrate	source	whereabouts	composition
order record file	All order information	dish information table; table information table	Null	Order number, dish amount, dish number, dish quantity, consumption amount, remarks, order status, order receiving time, completion time

5 process

The following is the specific description of the processing process of this system, including the number, name, description, input, output, and description of the processing process, as shown in Table 2.5.

Table 2.5 Process

serial number	name	illustrate	enter	output	Process description
P1	Order a la carte request processing	Receive a la carte request Serve dishes according to the situation, serve	F1 A la carte request	F4 Kitchen accepts orders; F5 Kitchen completes	After receiving the customer's order request, the back kitchen clicks to accept the order, and waits for the back kitchen to complete the order before serving.
P2	Checkout request processing	Receive checkout request information records, change order information	F2 Checkout Request	F5 order information	Accept the customer's checkout request and record it in the order information table and order details table

4 System Design

4.1 Functional structure design

The purpose of the development of this system is that it is more convenient and effective to process customer order information than the traditional order mode, and it is developed to facilitate the use of people in need. The main functional modules are: browse recipes, generate orders, checkout, query orders, operate employee information, save orders, etc. The system roles are divided into: background management module, client module, and kitchen module. The overall structure and function diagram of the system is shown in Figure 10.

Figure 10 The overall structure and function diagram of the system

4.2 Database design

4.2.1 Database conceptual structure design

According to the development requirements of the system, the conceptual model of the system is described through entity attribute diagram and ER diagram.

1 The entity attribute diagram of dishes, as shown in Figure 11.

Figure 11 Entity attribute diagram of dishes

2 The attribute map of dish entity, as shown in Figure 12.

Figure 12 dish entity attribute map

3 The entity attribute diagram of basic order information, as shown in Figure 13.

Figure 13 Entity attribute diagram of basic order information

4 The employee entity attribute diagram, as shown in Figure 14.

Figure 14 Employee entity attribute map

5 The overall ER diagram of the system is shown in Figure 15.

Figure 15 Overall ER Diagram

4.2.2 Converting ER Diagrams to Relational Models

The conversion rules for converting an ER diagram to a relational schema are as follows:

1 When an entity is converted to a schema, an entity is converted to a relational schema. The attribute of the entity is the attribute of the relationship, and the code of the entity is the code of the relationship.

2 The relationship is transformed into a relational schema.

When the connection is converted into a relational model, different conversion methods should be adopted according to the different contact methods.

① Conversion method of 1:1 contact

To merge a 1:1 relationship with a relationship corresponding to an entity set at one end, you need to add attributes to the merged relationship, and the newly added attributes are the attributes of the relationship itself and the code of another entity set related to the relationship.

② Conversion method of 1:n connection

Add a new attribute in the n-terminal entity set. The new attribute is composed of the code of the corresponding 1-terminal entity set and the attribute of the relationship itself. After the attribute is added, the code of the original relationship remains unchanged.

③ Conversion method of m:n relationship

When converting to a relational model, an m:n relationship is converted to a relationship.

The conversion method is: the codes of each entity set connected to the relationship and the attributes of the relationship itself are converted into the attributes of the relationship, and the code of the new relationship is a combination of two connected entity codes (the code is a combination code composed of multiple attributes).

According to the above conversion rules, the ER diagram is converted into the following relational schema:

Dish category (dish category number, dish category name), directly converted from the dish category entity.

Employee basic information (employee number, ID card number, name, gender, date of birth, mobile phone number, contact address) can be directly converted from the employee basic information entity.

The basic information of the order (order number, table number, total number of dishes, consumption amount, order time, remark information, payment time, responsible employee number, payment status) is obtained by converting the one-to-many relationship between the dish entity and the dish basic information entity .

Basic table information (table number, table name, employee number in charge) is obtained through conversion of the one-to-many relationship between the employee basic information entity responsible for the table basic information entity.

The order details (order number, dish number, dish amount, dish quantity, remark information, order status, order receiving time, completion time) are converted from the many-to-many relationship of the order basic information entity generated by selecting the dish basic information entity.

4.2.3 Normalization of relational schemas

Relational mode dish category (dish number, dish name), the candidate code is the dish number, the main attribute is the dish number, the non-main attribute is the dish name, and the selected main code is the dish number, then there is a functional dependency set as (dish number -> dish name) there is no partial functional dependence of non-key attributes on the code, and there is no transfer function dependence of non-key attributes on the code, so the account payable relationship model has at least reached 3NF.

Relational mode dishes (dish number, dish type number, dish name, production time, quantity, price), the candidate code is the dish number, the main attribute is the dish number, and the non-main attribute is the dish type number, dish name, production time, quantity, If the main code is selected as the dish number, then there is a functional dependency set as (dish number -> dish type number, dish number -> dish name, dish number -> production time, dish number -> quantity, dish number -> price ) There is no partial functional dependence of non-key attributes on codes, and no transfer function dependence of non-key attributes on codes, so the payable relationship model has at least reached 3NF.

Basic order information in relational mode (order number, table number, total number of dishes, consumption amount, order time, remark information, payment time, responsible employee number, payment status), the candidate code is the order number, the main attribute is the order number, and the non-main The attributes are table number, total number of dishes, consumption amount, order time, remark information, payment time, responsible employee number, payment status, and the selected main code is order number, then there is a functional dependency set as (order number -> table number, Order number -> total number of dishes, order number -> consumption amount, order number -> order time, order number -> remarks information, order number -> payment time, order number -> responsible employee number, order number -> payment status ) There is no partial functional dependence of non-key attributes on codes, and no transfer function dependence of non-key attributes on codes, so the payable relationship model has at least reached 3NF.

Relational model order details (order number, dish number, dish amount, dish quantity, remark information, order status, order receiving time, completion time), the candidate code is (order number, dish number), and the main attribute is (order number, dish number), the non-main attributes are dish amount, dish quantity, remark information, order status, order receiving time, completion time, the selected main code is (order number, dish number), then there is a functional dependency set as {(order number , dish number) -> dish amount, (order number, dish number) -> dish quantity, (order number, dish number) -> remarks information, (order number, dish number) -> order status, (order number, dish number No.) -> order receiving time, (order number, dish number) -> completion time} There is no partial functional dependence of non-main attributes on codes, and there is no transfer function dependence of non-main attributes on codes, so the payable relationship model At least 3NF has been reached.

Basic employee information in relationship mode (employee number, ID number, name, gender, date of birth, mobile phone number, contact address), candidate code is employee number, main attribute is employee number, non-main attribute is ID number, name, gender , date of birth, mobile phone number, contact address, and the main code is selected as the employee number, then there is a functional dependency set as (employee number -> ID card number, employee number -> name, employee number -> gender, employee number -> birth date, employee number -> mobile phone number, employee number -> contact address) there is no partial functional dependence of non-primary attributes on codes, and there is no transfer function dependence of non-primary attributes on codes, so the payable relationship model has at least reached 3NF.

4.2.4 Database table design

This system designs a total of seven database tables, the main tables are: dish category table, dish table, order basic information table, order detailed information table, employee basic information table, table basic information table.

The overall structure of other tables is basically the same as the above-mentioned table structure, so we will not repeat them one by one, but only introduce the main table designs.

The dish category table mainly records the information of various dishes, as shown in Table 1 foodtype dish category table.

Table 1 foodtype list of dishes

serial number	field	type	length	length	meaning
1	Id	int		dish type number	dish type number
2	Name	Varchar	20	20	dish name

The dish table mainly records the information of the dishes. As shown in Table 2 food dishes table.

Table 2 food menu list

serial number	field	type	length	length	meaning
1	id	int			dish number
2	food-Type_id	int		dish type number	dish type number
3	title	varchar	20	20	dish name
4	cost_time	int			production time
5	amount	int			quantity
6	price	float			price

The order basic information table mainly records the basic information of the order, as shown in Table 3 order basic information table.

Table 3 order basic information table

serial number	field	type	length	meaning
1	id	int		order number
2	table_id	int		table number
3	food-amount	int		Total number of dishes
4	table_price	float		Amount of consumption
5	create_time	Varchar	20	order time
6	comment	varchar	50	Remarks
7	pay_time	varchar	20	Payment time
8	staff_id	int	11	Responsible employee number
9	Is_pay	boolean		Payment status

The order details table mainly records various basic information of the order, as shown in Table 4 order_item table of order details.

Table 4 orderitem order details

serial number	field	type	length	meaning
1；2	order_id；number	int；int	；	order number; number of dishes
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])$');