餐厅点餐系统数据库实现

相关主题
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

点餐数据库

第一部分调查用户需求

本系统的最终用户为顾客,管理员。

一、餐馆的基本情况:

顾客到餐馆自助点餐,每个餐桌上都配有点餐设备,点餐之后通过网银结账,等餐,吃饭。

(1)订单信息:餐桌号,菜的编号,价格,

(2)餐馆的菜单信息:菜的编号,菜名,价格

(3)管理员:编号,,登录系统密码

(4)发票信息:发票编号,日期,价格,收款人

二、用户对系统的要求:

A、信息要求

1、订单信息:餐桌号,菜的编号,价格

2、餐馆的菜单信息:菜的编号,菜名,价格

3、发票信息:发票编号,日期,价格,管理员

B、处理要求

1、当顾客订单信息发生改变时,能自行进行修改。比如某些顾客加菜时,顾客点餐信息就应该做相应的修改。

2、当餐馆的菜单信息需要发生变更时,管理员能对其进行修改。

3、当顾客结账后,管理员能根据其订单通知厨房做菜并打印发票。

4、顾客结账后就餐。

C、安全性与完整性要求

安全性要求:

(1)系统应设置访问用户的标识以鉴别是否是合法用户,即是否为管理员,并要求合法用户设置其密码,保证用户身份不被盗用。

完整性要求:

(1)各种信息记录的完整性,信息记录容不能为空

(2)各种数据间相互联系的正确性

(3)相同数据在不同记录中的一致性

第二部分系统功能的设计和划分

1、管理员可以查询顾客的订单信息

2、管理员可以更新餐馆的菜单信息

3、管理员可以修改顾客的订单信息

4、管理员可以修改登录密码

5、管理员可以根据订单开发票。

6、顾客可以查看餐馆的菜单信息

7、顾客可以更新自己的订单信息

第三部分数据流图

接收订单流图:

处理订单流图:

加餐流图:

管理员开发票流图:

顾客

管理员

总数据流图:

E-R图:

第四部分数据字典

1.数据项:

菜单数据字典:

订单数据字典:

2.数据结构:

3.数据流:

4.数据存储:

5.处理过程

第五部分概念结构设计

一、概念结构设计:

根据需求分析中画出的点餐系统的数据流图,可以看出在餐馆点餐系统中一切活动都是以顾客为核心,而各种处理也是由顾客主动去完成,如点餐、结账等。在整个数据流图中顾客处于核心地位,而餐馆的各个职能部门则完成相应的数据处理操作,如在结账后由管理员通知厨房做菜并开发票。在需求分析中我们从分析餐馆的结构入手,我们得出点餐系统存在着5个方面的需求,从而可以设计出5个概念模式,为下一步的概念结构设计打好基础,

这五个概念模式为:顾客点餐,管理员查询订单,管理员处理订单,顾客加餐和管理员开发票。

点餐系统概念结构

(1)分数据流图在第三部分

(2)对应于各个分数据流图的E—R图设计为:

(3)实体及相应的属性

1.菜单:{菜编号,菜名,菜价};

2.订单:{座位号,菜编号,菜价,发票号};

3.管理员:{管理员编号,管理员,管理员性别,年龄,出生日期,,用户密码};

4.发票:{发票号,日期,总价,管理员编号,管理员}

二、逻辑结构设计:

在概念设计的基础上,根据设计得到系统总的E-R图,按照概念模式与关系表转化的一般规则,结合实际的需要进行逻辑设计,E—R图中的实体、实体的属性和实体之间的联系转化为关系模式。最后生成的关系及关系表如下(同时附说明):

1.菜单:{菜编号,菜名,菜价};

说明:由菜单生成的关系模式,

2.订单:{座位号,菜编号,菜价,发票号};

说明:由订单生成的关系模式,由于订单跟菜单的联系是1:n,故将菜单的主码菜编号加入到订单关系模式中。

3.管理员:{管理员编号,管理员,用户密码};

说明:由管理员生成的关系模式

4.发票:{发票号,日期,总价,管理员编号}

说明:由发票生成的关系模式,由于发票跟管理员的联系是n:m,故将管理员的主码管理员编号加入到发票关系模式中。

三、物理结构设计:

需要建立索引的属性:

相关文档
最新文档