餐厅业务运营管理系统数据库设计

餐厅业务运营管理系统数据库设计

我国的饮食文化源远流长，随着我国经济的迅速发展和人民生活水平的不断提高，各类餐厅出现在大街小巷，而餐饮业的竞争也愈来愈激烈。要想在竞争中取得优势，必须在经营管理、产品服务等方面提高服务管理意识。而对餐厅的经营状况起重要作用的是运营管理。如何利用先进的管理手段，提高餐厅的管理水平，是每一位管理者所面临的重要课题。简单的服务标准已经不是制胜的锦囊，只有做到最细微之处才有机会让顾客体会到服务的优点，而精准、快捷、周全往往就是最基本的成功要素。面对着庞大的信息量，传统的人工方式导致餐馆管理上有许多不足，人力与物力过多浪费，餐馆管理费用增加。因此，采用全新的计算机网络和管理系统，将成为提高餐厅的管理效率，改善服务水准的重要手段之一。

数据库的应用极大地方便了信息管理，为管理人员决策和资源的合理利

用提供了数据支持。本论文将对餐厅的运营管理进行数据库的设计，以求方

便餐厅运营，为之提高效益，科学管理做出贡献。

一、数据库系统需求设计

1、餐厅业务运营管理系统主要是根据食客的订单信息分析菜品的受欢迎程度，以便适时调整采购计划，合理利用厨房资源，同时根据厨房食材使用情况提供采购信息，以根据菜单支付信息提供收支情况。

该系统设计的数据有:

账单数据。

采购清单数据。

该系统的处理需求如下：

查询菜品的点击次数。

查询原材料的使用情况。

查询原材料的采购情况。

查询不同菜品收支情况。

2、数据流程图

根据餐厅的实际管理过程和各种操作，由了解到的业务，画出业务流程

图，本系统的业务流程图如下所示

第一层数据流程图

订单处理

购货清单处理

开具发票

菜单处理

3、数据字典

数据流图表达了数据和处理的关系，数据字典则是系统中各类数据描述的集合，是进行详细的数据收集和数据分析所获得的主要成果。数据字典在数据库设计中占有很重要的地位。

数据字典通常包括数据项、数据结构、数据存储、数据流和处理过程5个部分。其中数据项是数据的最小组成单位，若干个数据项可以组成一个数据结构，数据字典通过对数据项和数据结构的定义来描述数据流、数据存储的逻辑内容。

3.1数据项是不可在分的数据单位。下面定义了系统需要的数据项：

3.2数据结构反映了数据之间的组合关系，。一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。对数据结构的描述通常包括数据结构名、含义等。

3.3数据存储是数据结构停留或保存的地方，也是数据流的来源和去向之一。他可以是手工文档或手工凭单，也可以是计算机文档。

3.4数据流是数据结构在系统内传输的路径。对数据流的描述通常包括以下内容:数据流名、说明、数据流来源、数据流去向、组成等。

3.5处理过程的具体处理逻辑一般是用判定表或判定树来描述。数据字典中只需要描述处理过程的说明信息，通常包括处理过程编号、名称、说明、输入数据流、输出数据流、处理等。

二、数据库概念模型设计

将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计。它是整个数据库设计的关键。

1、E-R模型

基本E-R图

主管分E-R图

购货分E-R图

财务分E-R图

实体描述

三、数据库逻辑模型设计

概念结构是独立于任何一种数据模型的信息结构。逻辑结构设计的任务就是把概念结构设计阶段设计好的基本E-R图转换为与所选用的DBMS产品所支持的数据模型想符合的逻辑结构。

E-R图转换的关系模型

1.顾客（顾客号，订单号）

主键：顾客号

函数依赖关系F：顾客号订单号

关系中不存在非主属性对候选键的部分与传递函数依赖，故“顾客”关系是第三范式。

2.订单（订单号，顾客号，日期）

主键：订单号

函数依赖关系F：订单号 {顾客号，日期}

关系中不存在非主属性对候选键的部分与传递函数依赖，故“订单”关系是第三范式。

3.发票（发票号，订单号，日期）

主键：发票号

函数依赖关系F：发票号 {订单号，日期}

关系中不存在非主属性对候选键的部分与传递函数依赖，故“发票”关系是第三范式。

4.菜品 (菜号，菜名，价格)

主键：菜号

函数依赖关系F：菜号 {菜名，价格}

关系中不存在非主属性对候选键的部分与传递函数依赖，故“菜品”关系是第三范式。

5.订购（订单号，菜号，数量）

主键：订单号+菜号

函数依赖关系F：{订单号，菜号} 数量

关系中不存在非主属性对候选键的部分与传递函数依赖，故“订购”关系是第三范式。

6.厨师（厨师号，厨师名，主管号）

主键：厨师号

函数依赖关系F：厨师号厨师名

关系中不存在非主属性对候选键的部分与传递函数依赖，故“厨师”关系是第三范式。

7.制作（菜号，厨师号）

主键：菜号+厨师号

关系中不存在非主属性对候选键的部分与传递函数依赖，故“制作”关系是第三范式。

8.主管（主管号，主管名）

主键：主管号

函数依赖关系F：主管号主管名

关系中不存在非主属性对候选键的部分与传递函数依赖，故“主管”关系是第三范式。

9.订货单（订货单号，主管号，日期）

主键：订货单号

函数依赖关系F：订货单号 {主管号，日期}

关系中不存在非主属性对候选键的部分与传递函数依赖，故“订货单”关系是第三范式。

10.货物（货号，订货单号，货名，价格，数量）

主键：货号

函数依赖关系F：货号 {订货单号，货名，价格，数量}

关系中不存在非主属性对候选键的部分与传递函数依赖，故“货物”关系是第三范式。

11.消耗（菜号，货号，用量）

主键：菜号+货号

函数依赖关系F：{菜号，货号} 用量

关系中不存在非主属性对候选键的部分与传递函数依赖，故“采购”关系是第三范式。

四、数据库物理模型的实现

数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于选定的数据库管理系统。为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程，就是数据库的物理设计。