1.1 Overview of DBMS

ONLINE RESTAURANT MANAGEMENT SYSTEM 1
CHAPTER 1
INTRODUCTION
1.1 Overview of DBMS
A database management system (DBMS) refers to the technology for creating and
managing databases. Basically DBMS is a software tool to organize (create .retrieve, update
and manage) data in a database.
The main aim of a DBMS is a to supply a way to store up and retrieve
database information that is both convenient and efficient. By data, we mean known facts
that can be recorded and that have embedded meaning. Normally people use software
such as DBASE IV or V, Microsoft ACCESS , or EXCEL to store data in the form of
database.
Database systems are meant to handle large collection information .
management of data involves both defining structures for storage of information and
providing mechanisms that can do the manipulation of those stored and providing
database system must ensure the safety of the information stored ,despite system crashes
or attempt at unauthorized access.
1.2. History
Following the technology progress in the areas of processors, computer memory,
computer storage, and computer networks, the sizes, capabilities, and performance of
databases and their respective DBMSs have grown in orders of magnitude. The
development of database technology can be divided into three eras based on data model
or structure: navigational, SQL/relational, and post-relational.
The two main early navigational data models were the hierarchical model,
epitomized by IBM's IMS system, and the CODASYL model (network model),
implemented in a number of products such as IDMS.
The relational model, first proposed in 1970 by Edgar F. Codd, departed from
this tradition by insisting that applications should search for data by content, rather than
by following links. The relational model employs sets of ledger-style tables, each used
for a different type of entity.
JNNCE Department of CSE 2021-2022

By the early 1990s, however, relational systems dominated in all large-scale data
processing applications, and as of 2015 they remain dominant: IBM DB2, Oracle,
MySQL, and Microsoft SQL Server are the top DBMS. The dominant database language,
standardized SQL for the relational model, has influenced database languages for other
data models.
Object databases were developed in the 1980s to overcome the inconvenience of
object-relational impedance mismatch, which led to the coining of the term
"post-relational" and also the development of hybrid object-relational databases.
The next generation of post-relational databases in the late 2000s became known as
NoSQL databases, introducing fast key-value stores and document-oriented databases. A
competing "next generation" known as New SQL databases attempted new
implementations that retained the relational/SQL model while aiming to match the high
performance of NoSQL compared to commercially available relational DBMS.
1.3 Applications of DBMS
Nowadays DBMS are used in almost all the areas ranges from science, engineering,
medicine, business, industry, government, art, entertainment, education and training .
DBMS in Banking
We make thousands of transactions through banks daily and we can do this without going
to the bank. That is all possible just because of DBMS that manages all the bank transactions.
DBMS in Universities and colleges
Examinations are done online today and universities and colleges maintain all these
records through DBMS. Student’s registrations details, results, courses and grades all the
information are stored in database.
DBMS in Online Shopping
Online shopping has become a big trend of these days. No one wants to go to shops and
waste his time. Everyone wants to shop from home. So all these products are added and sold
only with the help of DBMS. Purchase information, invoice bills and payment, all of these
are done with the help of DBMS.

DBMS in Military
Military keeps records of millions of soldiers and it has millions of files that should be
keep secured and safe. As DBMS provides a big security assurance to the military
information so it is widely used in militaries. One can easily search for all the information
about anyone within seconds with the help of DBMS.
DBMS in Telecommunications
Any telecommunication company cannot even think about their business without DBMS.
DBMS is must for these companies to store the call details and monthly post paid bills.

CHAPTER 2
2.1 PROPOSED SYSTEM

Nowadays ,many restaurants manage their business by manual especially take
customer ordering. In traditional booking system, a customer has to go to restaurant or make
a phone call in order to get his meal reserved. Today ,restaurant waiter takes the customer
ordering by manual system with using paper. Customer does some formal conversation like
hello, hi, etc.
Than he demands for today’s menu items then he orders.it takes 5 to 10 minutes to
book the order and waiter book the order on paper so there is probability of lost and
duplicates customer information .restaurant management system puts the order in a queue
with specific priority according to time quantity, and than a cook is signed for the specific
order to complete it.
EXISTING SYSTEM
The current system is paper based. Papers are used in restaurants for displaying the
traditional menu cards, writing down the orders of customers, storing the records of
customers. The disadvantages of paper based system are that papers can get easily damaged
by stain marks; they can be lost due to fire or accidents or can get lost in general.
Hence, time and money is wasted. As traditional menu cards are paper based, any
changes that need to be made in the menu will require reprinting of the entire menu card,
leading to wastage.
For small changes, reprinting the entire menu card is impossible. Changes in the menu
card cannot be made dynamically. It is inefficient to access a particular record from the stack
of papers. This system is time consuming. One has to call a waiter number of times till he
notices it, and wait for him to arrive at their table to take their order.
Also the waiter can misinterpret the customer’s order since he is writing the order on
paper, and the case of serving a wrong dish is possible. · For placing any orders customers
have to visit hotels or restaurants to know about food items and then place order and pay. In
this method time and manual work is required. · While placing an order over the phone,
customer lacks the physical copy of the menu item, lack of visual confirmation that the order
was placed correctly. ·

Every restaurant needs certain employees to take the order over phone or in-person,
to offer a rich dining experience and process the payment. In today’s market, labor rates are
increasing day by day making it difficult to find employees when needed.
2.2 OBJECTIVES
 To develop android application for restaurant ordering system and provides facility to
update menu.
 To develop a software at kitchen and cashier to receive order from server.
 To establish network for kitchen , cashier and android device and print the bill a
customer side.
 Customer should be able to the feedback about the service and the food served by
e-restaurant android applications.
2.3 MODULES
 Module 1: Login Module In login module the customer and restaurants login will be
taken while they already registered on the application. Every manager/user will have
login id and password to login to the application.
·
 Module 2: Registration Module This module is displayed to the visitors if they need to
perform some order placements, and new registration for restaurants who wants to do
business with us on our online restaurant management application.
·
 Module 3:Add/Update/remove Menu This module is for admin. Admin have rights to
insert, update (modify) and delete the data in database as per his/her necessary
requirements.
 Module 4:Account Management Module There will be an account manager who will
manage all the online order transaction and he/she will be responsible for issuing printed
copy of customers payment receipts.
 Module 5: Station Tracking Module This module describes the current location of any
particular area over the usage of internet connectivity and GPS. This module is useful to
find the location of order placed and for estimated time delivery.

·
 Module 6: Place Order Module The activity is performed by customer itself whose
registration is already done. Once the verification is done by application, the order gets
confirmed and delivery will be given to the dedicated customers address.
·
 Module 7: Carting Module This is additional feature given to add the food items in
customer’s virtual basket just like pending orders or the orders which customer wants to
do later. But, if the customer is first time visiting then he/she will unable to place order
until he/she do registration to our application.
·
 Module 8: Order Manage Module In case, the customer come to know that the food or
service of restaurant is not good and estimated delivery time is too much as expected
then he/she can manage his/her orders under order manage module.
·
 Module 9: Messaging Module The private window for conversation between customer
and customer executives will be given inside the application where they can ask about
any kind of queries to the executives 24/7.
 Module 10: Logout Module The last module describes that after placing order or
performing some actions on the application the customer will click logout profile.

2.4 REQUIREMENTS
Hardware Requirements
1 RAM 4 GB/8 GB for faster output.
2 Hard Disk 500 GB
3 Miro Processor 2.0 GHz
4 Micro Processor Type Core i3/Core i5
5 Any Desktop or Laptop systems with high level configuration
Software Requirements
1 OS(Operating System) Windows XP/7/10
2 Programming Language Php, MySQL
Front End or Web

3 Technologies HTML, CSS, BOOTSTRAP, JavaScript
4 Back End PHP
5 Database MySQL database

CHAPTER 3
3.1 WORKING
Our main aim is to increase the efficiency of the food ordering and reduce human errors
and provide high quality services to the customers of the restaurants. The application on the
tablets must be able to communicate with the other devices.
firstly the customer or visitor will open the application and searches for food item menus
from nearby available location of customer. The customer sees the categorized menu card on
the android app. The selection of food items is done by person if he/she visiting our
application with or without login and registration module. At this stage, the registered and
non- registered persons can add food items in their shopping kart for temporary purpose.
If the customer wants to buy selected items then condition will be checked weather
customer login is done or not. If login is not done then application will force customer to
login first before ordering something. For performing all activities in project we will create
one database consists of all restaurants listed along with their daily food items and costs.
Once completing login task, the customer will place order from his nearest searched local
restaurants searched via server. After this the verification of customer order will be done by
making call given by customer at the time of login registration. After successful verification
admin will check is the order is confirmed by customer if not the whole Process begins from
start.
3.2 SCOPE OF THE PROJECT
Scope of the project in building a computerized system for silk route to handle billing
restaurant record was to handle to include the employees who are in the process of billing of
a customer storage of restaurant records and enables to view the records as desired. records.
The employees are given limited access in order to safe guard the privacy and security of
the records. The database in maintained in the whole project.

3.3 SEVEN STEPS FOR ER TO SCHEMA
CONVERSION :
Step 1: Mapping of Regular Entity Types
For each regular (strong) entity type E in the ER schema, create a relation R that
includes all the simple attributes of E. Include only the simple component attributes of a
composite attribute. Choose one of the key attributes of E as the primary key for R. If the
chosen key of E is a composite, then the set of simple attributes that form it will together
form the primary key of R. If multiple keys were identified for E during the conceptual
design, the information describing the attributes that form each additional key is kept in
order to specify secondary (unique) keys of relation R. Knowledge about keys is also kept
for indexing purposes and other types of analyses.
Step 2: Mapping of Weak Entity Types
For each weak entity type W in the ER schema with owner entity type E, create a
relation R and include all simple attributes (or simple components of composite attributes)
of W as attributes of R. In addition, include as foreign key attributes of R, the primary key
attribute(s) of the relation(s) that correspond to the owner entity type(s); this takes care of
mapping the identifying relationship type of W. The primary key of R is the combination
of the primary key(s) of the owner(s) and the partial key of the weak entity type W, if any.
If there is a weak entity type E2 whose owner is also a weak entity type E1, then E1
should be mapped before E2 to determine its primary key first.
Step 3: Mapping of Binary 1:1 Relationship Types
For each binary 1:1 relationship type R in the ER schema, identify the relations S and
T that correspond to the entity types participating in R. There are three possible
approaches:
1. The foreign key approach.

2. The merged relationship approach, and
3. The cross-reference or relationship relation approach.

The first approach is the most useful and should be followed unless special conditions
exist, as we discuss below.
1. Foreign key approach:

Choose one of the relations—S, say—and include as a foreign key in S the
primary key of T. It is better to choose an entity type with total participation in R
in the role of S.
Include all the simple attributes (or simple components of composite attributes)
of the 1:1 relationship type R as attributes of S.
Step 2: Merged relation approach:

An alternative mapping of a 1:1 relationship type is to merge the two entity types
and the relationship into a single relation. This is possible when both
participations are total, as this would indicate that the two tables will have the
exact same number of tuples at all times.
Step 3: Cross-reference or relationship relation approach:
The third option is to set up a third relation R for the purpose of
cross-referencing the primary keys of the two relations S and T representing the
entity types. As we will see, this approach is required for binary M:N
relationships. The relation R is called a relationship relation (or sometimes a
lookup table), because each tuple in R represents a relationship instance that
relates one tuple from S with one tuple from T. The relation R will include the
primary key attributes of S and T as foreign keys to S and T. The primary key of
R will be one of the two foreign keys, and the other foreign key will be a unique
key of R. The drawback is having an extra relation, and requiring an extra join
operation when combining related tuples from the tables.
Step 4: Mapping of Binary 1:N Relationship Types

For each regular binary 1:N relationship type R, identify the relation S that
represents the participating entity type at the N-side of the relationship type. Include as
foreign key in S the primary key of the relation T that represents the other entity type
participating in R; we do this because each entity instance on the N-side is related to at
most one entity instance on the 1-side of the relationship type. Include any simple

attributes (or simple components of composite attributes) of the 1:N relationship type as
attributes of S.
Step 5: Mapping of Binary M:N Relationship Types

For each binary M:N relationship type R, create a new relation S to represent R.
Include as foreign key attributes in S the primary keys of the relations that represent the
participating entity types; their combination will form the primary key of S. Also include
any simple attributes of the M:N relationship type (or simple components of composite
attributes) as attributes of S. Notice that we cannot represent an M:N relationship type by
a single foreign key attribute in one of the participating relations (as we did for 1:1 or 1:N
relationship types) because of the M:N cardinality ratio; we must create a separate
relationship relation S.
Step 6: Mapping of Multivalued Attributes

For each multivalued attribute A, create a new relation R. This relation R will
include an attribute corresponding to A, plus the primary key attribute K—as a foreign
key in R—of the relation that represents the entity type or relationship type that has A as a
multivalued attribute. The primary key of R is the combination of A and K. If the
multivalued attribute is composite, we include its simple components.
Step 7: Mapping of N-array Relationship Types

For each n-array relationship type R, where n > 2, create a new relation S to represent
R. Include as foreign key attributes in S the primary keys of the relations that represent
the participating entity types. Also include any simple attributes of the n-array
relationship type (or simple components of composite attributes) as attributes of S. The
primary key of S is usually a combination of all the foreign keys that reference the
relations representing the participating entity types. However, if the cardinality
constraints on any of the entity types E participating in R is 1, then the primary key of S
should not include the foreign key attribute that references the relation E' corresponding
to E.

3.4 THE FEATURES THAT CAN BE INCLUDED IN THIS

APPLICATION ARE AS FOLOWS:
 NUMBER OF PEOPLE WORKING:

This application will help in providing the details of the number of employees
working in a restaurant.
 ROLES ASSIGNED:
The restaurant will be consisting of the employees working for different roles. This
application will also helps to maintain the information regarding it.
The restaurant management system allows the owner of the restaurant to manage all the
details of the employees without much effort.
It can also store the details of the available time and money for managing the
restaurant well.it can give some suggestions to managing the restaurant well and how to
run it smoothly and efficiency.

CHAPTER 4
DATABASE DESIGN
4.1 Database Tables
The database is very important for all the system, because if we want store any kind
of information related to the system then this can be done only when there is a database
created for the system. Usually database is used to store the information of all the users
which may include usernames and their passwords and so on. It is also helps to perform
crude operations. In this project database design did not included any primary key and
foreign key instead tables are created separately for storing the data and retrieving from
the database.
1.CUSTOMER TABLE
Form_field Type Length Remark
username Varchar 30 Not Null
Full name Varchar 30 Not Null
email Varchar 30 Not Null
contact Varchar 30 Not Null
address Varchar 50 Not Null
password varchar 30 Not Null

2.FOOD
F_ID Varchar 30 Not Null
Name Varchar 30 Not Null
price Varchar 30 Not Null
Description Varchar 200 Not Null
R_ID Varchar 30 Not Null
Image path varchar 200 Not Null
3.MANAGER
Username Varchar 30 Not Null
Fullname Varchar 30 Not Null
Email Varchar 30 Not Null
Contact Varchar 30 Not Null
Address Varchar 50 Not Null
Password varchar 30 Not Null

4.ORDERS
ORDER_ID Varchar 30 Not Null
F_ID Varchar 30 Not Null
Foodname Varchar 30 Not Null
Price Varchar 30 Not Null
quantity Varchar 30 Not Null
Order date varchar - Not Null
R_ID varchar 30 Not Null
5.RESTAURANT
R_ID Varchar 30 Not Null
Name Varchar 30 Not Null
Email Varchar 30 Not Null
Contact Varchar 30 Not Null
Address Varchar 50 Not Null
M_ID varchar 30 Not Null

4.2 Entity diagram
email
email contact
email
Full name contact
R_ID name
name
User name username
contact
Restaurant
Manager Customer
HAS TELLS
address passwor
addre
CON d
address password GIVE ss
TAI S
M_ID NS
R_ID
quantity
F_ID Food Orders
name
ORDER_ID
date
description price
price F_ID
R_ID
F_NAME

CHAPTER 5
IMPLEMENTATION
5.1 ABSTRACT CODE

<?php
session_start(); // Starting Session
$error=''; // Variable To Store Error Message
if (isset($_POST['submit'])) {
if (empty($_POST['username']) || empty($_POST['password'])) {
$error = "Username or Password is invalid";
}
else
{
// Define $username and $password
$username=$_POST['username'];
$password=$_POST['password'];
// Establishing Connection with Server by passing server_name, user_id and
password as a parameter
require 'connection.php';
$conn = Connect();
// SQL query to fetch information of registerd users and finds user match.
$query = "SELECT username, password FROM CUSTOMER WHERE
username=? AND password=? LIMIT 1";
// To protect MySQL injection for Security purpose

$stmt = $conn->prepare($query);
$stmt -> bind_param("ss", $username, $password);
$stmt -> execute();
$stmt -> bind_result($username, $password);
$stmt -> store_result();
if ($stmt->fetch()) //fetching the contents of the row

{
$_SESSION['login_user2']=$username; // Initializing Session
header("location: foodlist.php"); // Redirecting To Other Page
} else {
$error = "Username or Password is invalid";
}
mysqli_close($conn); // Closing Connection
}
}

5.2 Screenshots.
1. Restaurant Home Page

The below image shows the home page for start-up of the project.
2.Customer Login page

3.User sign-in page
4.About us page

5.contact us
6.Mail us

7.Food_items
8.Cart

9.customer payment
10.online payment

11.cash on delivery
12.manager work

FUTURE SCOPE
 Enhanced and rich UI will be Designed.

 Special offer will be included.
 Another payment option will be included.
 User will get a discount of 30% in an order of Rs 300 above.
LIMITATIONS
Limitation of periodic system:

With the periodic system, the company knows the inventory level with certainly only
when it physically counts the inventory at end of each period. throughout the period ,the
company takes customer without knowing the exact inventory count or whether enough
products are available to meet customer demand.

CONCLUSION
The “ ONLINE RESTAURANT MANAGEMENT SYSTEM” is successfully
designed and developed to fulfill the necessary requirements, as identified in the
objectives. All the process are automated and systematically done consuming less
time.The users of the system also include employee who handle into related product
addition and assigning vehicle to placed the order.The system records the details in
MYSQL database so that it will be easy to retrieve later.The system will also
automatically calculate and displays the final bill so the bills will ready to print without
having any error because the information for that item is already inserted.

TEXT BOOKS REFERRED :
 PHP & MySQL Novice to ninja-by Kevin Yank

 Head first PHP & MySQL -BY Lynn Beighley & Michael Marisson

1.1 Overview of DBMS

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1.1 Overview of DBMS

Uploaded by

Copyright:

Available Formats

ONLINE RESTAURANT MANAGEMENT SYSTEM 1

1.1 Overview of DBMS

JNNCE Department of CSE 2021-2022

1.3 Applications of DBMS

DBMS in Universities and colleges

DBMS in Online Shopping

JNNCE Department of CSE 2021-2022

JNNCE Department of CSE 2021-2022

2.1 PROPOSED SYSTEM

JNNCE Department of CSE 2021-2022

JNNCE Department of CSE 2021-2022

JNNCE Department of CSE 2021-2022

1 RAM 4 GB/8 GB for faster output.

2 Hard Disk 500 GB

3 Miro Processor 2.0 GHz

4 Micro Processor Type Core i3/Core i5

5 Any Desktop or Laptop systems with high level configuration

1 OS(Operating System) Windows XP/7/10

2 Programming Language Php, MySQL

Front End or Web

4 Back End PHP

5 Database MySQL database

JNNCE Department of CSE 2021-2022

JNNCE Department of CSE 2021-2022

3.3 SEVEN STEPS FOR ER TO SCHEMA

1. The foreign key approach.

JNNCE Department of CSE 2021-2022

1. Foreign key approach:

Step 2: Merged relation approach:

Step 4: Mapping of Binary 1:N Relationship Types

JNNCE Department of CSE 2021-2022

Step 5: Mapping of Binary M:N Relationship Types

Step 6: Mapping of Multivalued Attributes

Step 7: Mapping of N-array Relationship Types

JNNCE Department of CSE 2021-2022

3.4 THE FEATURES THAT CAN BE INCLUDED IN THIS

 NUMBER OF PEOPLE WORKING:

JNNCE Department of CSE 2021-2022

Form_field Type Length Remark

username Varchar 30 Not Null

Full name Varchar 30 Not Null

email Varchar 30 Not Null

contact Varchar 30 Not Null

address Varchar 50 Not Null

password varchar 30 Not Null

JNNCE Department of CSE 2021-2022

Form_field Type Length Remark

F_ID Varchar 30 Not Null

Name Varchar 30 Not Null

price Varchar 30 Not Null

Description Varchar 200 Not Null

R_ID Varchar 30 Not Null

Image path varchar 200 Not Null

Form_field Type Length Remark

Username Varchar 30 Not Null

Fullname Varchar 30 Not Null

Email Varchar 30 Not Null

Contact Varchar 30 Not Null

Address Varchar 50 Not Null

Password varchar 30 Not Null

JNNCE Department of CSE 2021-2022

Form_field Type Length Remark