大家好，又见面了，我是你们的朋友全栈君。

1.需求分析

2.概念结构设计

2.1 数据需求

2.1.1下订单阶段需要的数据：

2.1.2点菜阶段需要的数据：

2.1.3结账阶段需要的数据：

2.1.4员工管理需要的数据：

2.1.5顾客管理需要的数据：

2.1.6消费记录管理需要的数据有：

2.2事务需求

2.2.1数据录入

2.2.2数据更新/删除

2.2.3数据查询

2.3数据项

2.2抽象出系统的实体

2.3设计E-R图

2.3.1菜谱（Menus）E-R图

2.3.2顾客（Tomer）E-R图

2.3.3餐桌（FoodTable）E-R图

2.3.4员工（Worke）E-R图

2.3.5订单（Oder）E-R图

2.3.6消费记录（ Sales_bill）E-R图

2.3.7折扣规则（Discount_rules）E-R图

2.3.8全局E-R图

3. 逻辑结构设计

3.1转换规则

3.2 根据以上规则得到如下关系模型（红色字体的属性为主码）

4. 数据库物理设计与实施

4.1创建数据库

4.2建立基本表

4.2.1菜谱（Menus）

4.2.2顾客（Tomer）

4.2.3餐桌（FoodTable）

4.2.4员工（Worke）

4.2.5订单（Oder）

4.2.6菜谱_订单（Menus_Oder）

4.2.7折扣规则（Discount_rules）

4.2.8消费账单（Sales_bill）

4.3管理基本表

4.4建立和管理视图

4.4.1建立视图

4.4.2管理视图

5.访问数据库

5.1数据查询

5.1.1 Foodtable表

5.2.1menus表

5.1.3员工表(worke)

5.1.4消费记录（ Sales_bill）

5.1.5顾客（Tomer）

5.1.6订单（Oder）

5.1.7折扣规则（Discount_rules）

5.1.8点菜（menus_oder）

5.2数据更新

6.数据库维护

6.1备份数据库

总结与心得

附录：

1.需求分析

通过了解餐饮行业的特点和实际情况，从分析饭店的基本情况入手，结合要实现的功能，对系统的可行性进行分析，为提高其可行性，故做了以下数据分析。

2.概念结构设计

2.1 数据需求

餐桌数据包括餐桌号、座位数、状态（空/有人）。 餐厅存储有顾客信息，员工信息。菜品信息有菜品编号、名称、类别、价格等 。

具体数据需求如下：

2.1.1下订单阶段需要的数据：

顾客信息：包括顾客编号。

订单信息：包括订单编号、消费时间。

餐桌信息：包括编号、可容人数、使用状态等

员工信息：包括员工工号。

2.1.2点菜阶段需要的数据：

订单信息：订单编号

菜品信息：包括菜品编号、菜品名称、菜品数量等。

2.1.3结账阶段需要的数据：

订单信息：包括订单编号、顾客编号

菜品信息：包括菜品编号、菜品名称、菜品数量等。

员工信息：包括员工工号

折扣信息：包括消费金额、折扣数

2.1.4员工管理需要的数据：

员工档案：包括工号、姓名、性别、工资

2.1.5顾客管理需要的数据：

顾客档案：包括编号、姓名、性别等。

2.1.6消费记录管理需要的数据有：

消费信息：订单编号、消费金额、折扣后金额、结账时间

2.2事务需求

2.2.1数据录入

录入顾客信息、录入餐桌信息、录入员工信息、录入菜品信息

2.2.2数据更新/删除

更新/删除餐桌信息、更新/删除菜谱菜品信息、更新/删除员工信息、更新/删除顾客信息、更新/删除订单菜品信息

2.2.3数据查询

查询可用餐桌信息、查询在售菜品信息、查询订单信息、查询顾客点菜信息 、查询员工信息、查询顾客消费信息

2.3数据项

FoodTable（餐桌）数据项

Menus（菜谱）数据项

Worke（员工）数据项

Tomer（顾客）数据项

Oder（订单）数据项

Menus_Oder（点菜）数据项

Discount_rules（折扣规则）数据项

Sales_bill（消费账单）数据项

2.2抽象出系统的实体

菜谱（Menus）

顾客（Tomer）

餐桌（FoodTable）

员工（Worke）

订单（Oder）

消费记录（ Sales_bill）

折扣规则（Discount_rules）

2.3设计E-R图

2.3.1菜谱（Menus）E-R图

2.3.2顾客（Tomer）E-R图

2.3.3餐桌（FoodTable）E-R图

2.3.4员工（Worke）E-R图

2.3.5订单（Oder）E-R图

2.3.6消费记录（ Sales_bill）E-R图

2.3.7折扣规则（Discount_rules）E-R图

2.3.8全局E-R图

3. 逻辑结构设计

3.1转换规则

一个实体型转换成一个关系模型。实体的属性就是关系的属性，实体的码就是关系的码。

实体型间的联系常有如下不同的情况：

a. 一个1:1联系可以转换为一个独立的关系模式，也可以任意一端对应的关系模式合并。

b. 一个1：n联系可以转换成一个独立的关系模式，也可以与n端对应的关系模式合并。

c. 一个m:n联系转换成一个关系模式。

d. 3或3个以上实体间的一个多联系可以转换成一个关系模式。

e. 具有相同码的关系模式可合并。

3.2 根据以上规则得到如下关系模型（红色字体的属性为主码）

菜谱（菜品编号，菜品名称，菜品类别，菜品价格）

顾客（顾客编号，姓名，性别，年龄，联系方式）

餐桌（餐桌号，座位数，使用状态）

员工（工号，姓名，性别，年龄，工资）

订单（订单编号，顾客编号，消费时间，餐桌编号，服务员编号）

菜谱_订单（订单编号，菜品编号，菜品名称，菜品数量）

消费记录（订单号，消费金额，折扣后金额，账单时间）

折扣规则（消费金额，折扣）

4. 数据库物理设计与实施

数据库在物理设备上的存储结构与存取方法就是数据库的物理结构，它依赖于选定的数据库管理系统，为一个给定的逻辑数据模型选取一个最合适的应用环境的物理结构过程，就是数据库的物理设计。这一阶段主要任务时确定数据库的物理结构，并不断的进行优化处理，主要建立索引，触发器，存储过程。

4.1创建数据库

4.2建立基本表

4.2.1菜谱（Menus）

4.2.2顾客（Tomer）

4.2.3餐桌（FoodTable）

4.2.4员工（Worke）

4.2.5订单（Oder）

4.2.6菜谱_订单（Menus_Oder）

4.2.7折扣规则（Discount_rules）

4.2.8消费账单（Sales_bill）

4.3管理基本表

有时候应用环境和应用需求的改变，我们需要修改已经建立好的基本表的模式结构或者更新已经插入的数据。mysql语句采用alter table<>语句修改基本表的结构，利用drop<>子句删除基本表,利用update更新已经插入的数据。alter table语句以修改基本表的名字，增加新列或者增加新的完整性约束条件，修改原有列的定义，包括修改列名和数据类型等。drop子句用于删除指定的完整性约束条件。UPDATE用于把插入表的数据更新改变。

因为在建立表时将Tomer表中的T_sex错误的录为T_rsex，因此用alter table 表名 change 旧字段名 新字段名 新字段类型。

4.4建立和管理视图

视图是一个虚拟表，其内容由查询定义。同真实表一样，视图包含一系列带有名称的列和行数据，但视图并不是数据库真实存储的数据表。视图是从一个、多个表或者视图中导出的表，包含一系列带有名称的数据列和若干条数据行。

4.4.1建立视图

4.4.2管理视图

将王昭君的电话改为**********

这张图片不能放上

5.访问数据库

5.1数据查询

5.1.1 Foodtable表

5.2.1menus表

5.1.3员工表(worke)

5.1.4消费记录（ Sales_bill）

5.1.5顾客（Tomer）

5.1.6订单（Oder）

5.1.7折扣规则（Discount_rules）

5.1.8点菜（menus_oder）

5.2数据更新

将员工表（worker）中的06号员工W_age数据项改为20,W_salary改为5100。

原来的表：

修改过程

改过之后

6.数据库维护

数据库维护包括许多内容，包括用户权限的设置、数据库完整性维护、数据库的备份、表的备份、日志备份等。

6.1备份数据库

完全备份：这是大多数人常用的方式，它可以备份整个数据库，包含用户表、系统表、索引、视图和存储过程等所有数据库对象。但它需要花费更多的时间和空间，所以，一般推荐一周做一次完全备份。

事务日志备份：事务日志是一个单独的文件，它记录数据库的改变，备份的时候只需要复制自上次备份以来对数据库所做的改变，所以只需要很少的时间。为了使数据库具有鲁棒性，推荐每小时甚至更频繁的备份事务日志。

差异备份：也叫增量备份。它是只备份数据库一部分的另一种方法，它不使用事务日志，相反，它使用整个数据库的一种新映象。它比最初的完全备份小，因为它只包含自上次完全备份以来所改变的数据库。它的优点是存储和恢复速度快。推荐每天做一次差异备份。

文件备份：数据库可以由硬盘上的许多文件构成。如果这个数据库非常大，并且一个晚上也不能将它备份完，那么可以使用文件备份每晚备份数据库的一部分。由于一般情况下数据库不会大到必须使用多个文件存储，所以这种备份不是很常用。

备份截图：

总结与心得

在这个课程设计中，我学到的东西还是很多的，感受颇多。第一，这次课程设计巩固了之前学习到的知识，并将学到的知识进行了串联。第二，我初略学到了设计一个数据库的几个步骤：需求分析，概念结构设计，逻辑结构设计，物理结构设计，运行，实现，运行和维护。但是我到现在还是不会使用触发器，并且对于查询的实验和方法还是有些单一。

这一学期的数据库就以这次实训落幕了。感觉挺不舍的。虽然之后也没有相关的课程了，但我觉得我对数据库的学习并不会就此止步。接下来的想法就是把所学到的知识强化，达到能运用自如，并且想要学会C++或是JAVA跟数据库的连接。

附录：

4.2建立基本表 4.2.1菜谱（Menus） create table Menus( M_id varchar(10) primary key, M_name varchar(20), M_class varchar(10), M_price float);

4.2.2顾客（Tomer） create tale Tomer (T_id varchar(10) primary key, T_name varchar(10) not null T_rsex varchar(4) check (T_sex=’男’or T_sex=’女’) , T_phone varchar(20) );

4.2.3餐桌（Foodtable) create table Foodtable (Cz_id varchar(10) primary key, Cz_number int not null, Cz_zt varchar(6)check(Cz_zt=”空” or Cz_zt=”有人”));

4.2.4员工（Worke） create table Worke (W_id varchar(10) primary key, W_name varchar(10), W_sex varchar(4) check(W_sex=’男’ or W_sex=’女’), W_age int, W_salary float) ;

4.2.5订单（Oder） create table der (O_id varchar(10) primary key, T_id varchar(10) not null, time datetime not null, Cz_id varchar(10) not null, W_id varchar(10) not null, foreign key(T_id) references Tomer(T_id), foreign key(Cz_id)references Foodtable(Cz_id), foreign key(W_id) references Worke(W_id));

4.2.6菜谱_订单（Menus_Oder） create table Menus_Oder (O_id varchar(10), M_id varchar(10), M_name varchar(10), M_number int not null, Primary key(M_id ,O_id), foreign key(M_id) references Menus(M_id ), foreign key(O_id) references Oder(O_id) ) ;

4.2.7折扣规则（Discount_rules） create table Discount_rules (Je float primary key, Zk float)

4.2.8消费记录 Sales_bill create table Sales_bill (O_id varchar(10) primary key , S_price float, S_priceafter float, time datetime, foreign key(O_id ) references Oder(O_id ) );

这篇文章的基本框架来源于数据库课程设计餐饮下单管理系统 – 百度文库 修改了一下格式应该好看了许多吧。 这个博客就是整个word，附录就是数据库源码，有点小毛病，能运行出来的就直接拿走。 因为太多人要，所以花了点时间把数据输进去了。 资源自取：（勿做伸手党，请留下你的赞和关注） 链接：点击下载 提取码：p29k 数据库课程设计饭店点餐系统.zip_饭店点餐系统-数据库文档类资源-CSDN下载

发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/144199.html原文链接：https://javaforall.cn