《数据库原理》 外卖订餐系统Word文件下载.docx
- 文档编号:13759748
- 上传时间:2022-10-13
- 格式:DOCX
- 页数:30
- 大小:370.05KB
《数据库原理》 外卖订餐系统Word文件下载.docx
《《数据库原理》 外卖订餐系统Word文件下载.docx》由会员分享,可在线阅读,更多相关《《数据库原理》 外卖订餐系统Word文件下载.docx(30页珍藏版)》请在冰豆网上搜索。
本着为客户服务、替客户着想的原则出发,将根据客户对“网上订餐”系统的基本功能需求进行设计。
1.2相关技术分析
数据库设计是设计一个数据库管理系统的核心技术,因此,在设计一个系统之前必须设计好数据库,目前数据设计的一般过程分为六个阶段如图10.1所示:
需求分析阶段、概念结构设计阶段、逻辑结构设计阶段、物理结构设计阶段、实施阶段和运行与维护阶段。
1、需求分析阶段:
需求分析阶段的主要任务是指通过充分调查现实世界要处理的对象,详细了解计算机系统的工作情况,明确用户的各种需求,然后确定系统的各项功能。
数据库系统不仅要按照当前的应用要求来设计,而且必须充分考虑今后可能的扩充和改变。
2、概念结构设计阶:
概念结构设计阶段的主要任务是将需求分析阶段所得到的用户需求抽象为概念模型,而描述概念模型的具体工具主要是E-R模型。
3、逻辑结构设计阶段:
逻辑结构设计阶段的主要任务是把概念结构设计阶段设计的基本E-R模型转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构。
具体来说,就是首先将概念结构转换为一般的关系、网状、层次模型,然后将转换来的模型向特定DBMS支持下的数据模型转换,最后对数据模型进行优化。
4、物理结构设计阶段:
物理结构设计阶段的主要任务是为一个指定的逻辑数据模型选取一个符合应用要求的物理结构。
具体来说,就是首先确定数据库的物理结构,即数据库的存取方法和存储结构;
然后对数据库的物理结构进行评估,评估的重点是存取时间的长短和存储空间的大小。
5、实施阶段:
实施阶段的主要任务是用RDBMS提供的数据定义语言和其他实用程序将逻辑结构设计和物理结构设计的结果详细描述出来,成为DBMS可以接受的源代码;
再经过系统调试产生目标模式,最后完成数据的载入工作。
6、运行与维护:
运行与维护阶段的主要任务包括数据库的转储和恢复,数据库完整性和安全性控制,数据库性能改造、分析和监督,数据库的重构造和重组织。
2系统功能设计
2.1系统总体结构设计图
2.2系统功能模块
2.2.1模块名称
1、顾客信息管理模块,
2、菜品信息管理模块
3、送餐员信息管理模块
4、订单信息管理模块
5、留言信息管理模块
2.2.2功能模块分析
1、顾客信息管理模块
a)顾客信息的登记、删除、修改
b)顾客可给买过的菜品留言
a)菜品信息的录入、修改、删除
b)菜品信息的多关键字检索查询
送餐员信息的增加、删除和修改
a)订单信息可被送餐员和顾客查询
b)订单信息的修改和删除
a)只允许买过该菜品的顾客对该菜品评价
b)顾客可对留言进行修改删除
3数据库设计
3.1需求分析
3.1.1数据流图
3.1.2数据字典
(a)数据项:
表1.1数据项列表
数据项编号
数据项名
数据项含义
与其它数据项的关系
存储结构
别名
001
CID
顾客编号
char(10)
002
CNAME
顾客姓名
char(20)
003
CSEX
顾客性别
Nchar
(1)
004
CADDRESS
顾客住址
char(30)
005
CTELL
顾客电话
char(15)
006
EID
送餐员编号
007
ENAME
送餐员姓名
Char(20)
008
ESEX
送餐员性别
nchar
(1)
009
EADDRESS
送餐员住址
char(30)
010
ETELL
送餐员电话
char(15)
011
DID
菜品编号
char(10)
012
DNAME
菜品名称
013
DPRICE
菜品单价
Money(5)
单价
014
OID
订单编号
015
OTIME
订单提交时间
Date
提交时间
016
ODNUM
订单各菜品数量
char(6)
菜品数量
017
OSTATE
订单送达时间
char(8)
送达时间
018
MID
留言编号
019
MMID
留言人编号
同CID
020
MDID
留言菜品编号
同DID
021
MCONTENT
留言内容
char(300)
(b)数据结构:
表1.2数据结构列表
数据结
构编号
数据结构名
数据结构
含义
组成
01
CUSTOMER
顾客信息
CID,CNAME,CSEX,CADDRESS,CTELL
02
EMPLOYEE
送餐员信息
ED,EName,ESex,EADDRESS,ETELL,
03
DISHES
菜品信息
DID,DName,DPRICE
04
ORDERCP
订单信息
OID,OTIME,ODNUM,OSTATE
05
MESSAGE
留言信息
MID,MDID,MMID,MCONTENT
(c)处理逻辑描述
表1.3处理逻辑列表
处理编号
处理功能
处理过程
A
判断顾客、送餐员查询涉及的功能模块
顾客信息模块、菜品信息模块、订单信息模块、送餐员信息模块、留言信息模块:
先确定查询所涉及的功能模块;
然后,根据要查询的内容,确定查询数据流向;
最后显示查询结果。
B
判断菜品、顾客、送餐员修改要涉及的模块,同时把相应的修改数据传到相应的模块之中
顾客信息模块、菜品信息模块、送餐员信息模块、订单信息模块、留言信息模块:
先确定更新所涉及的功能模块;
然后,把更新信息传送到相应的模块中;
最后,进行相应的更新操作。
3.2概念结构设计
概念设计阶段主要是将需求分析阶段得到的用户需求抽象为信息结构(概念模型)的过程,它是整个数据库设计的关键。
本外卖订餐系统的主要任务及目标如下:
(1)设计分E-R图,即各子模块的E-R图;
(2)生成初步E-R图,通过合并方法,做到各子系统实体、属性、联系统一;
(3)生成全局E-R图,通过消除冲突等方面。
根据实体与属性间的两条准则:
①作为“属性”,不能再具有需要描述的性质。
②“属性”不能与其他实体具有联系。
局部E-R图a、b、c、d、e如下:
a)顾客信息E-R图
b)送餐员信息E-R图
c)菜品信息E-R图
d)留言消息E-R图
e)订单消息E-R图
n
m
1nnn
全局E-R图
3.3逻辑结构设计
1.将E-R图转换为关系模型
实体型转换为关系模式。
实体的属性就是关系的属性,实体的码就是关系的码。
对于实体间的联系则有以下不同的情况:
一个m:
n联系转换为一个关系模式。
与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为各实体码的组合。
一个1:
n联系可以转换为一个独立的关系模式,也可以与n端对应的关系模式合并。
如果转换为一个独立的关系模式,则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为n端实体的码。
一个1:
1联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。
三个或三个以上实体间的一个多元联系可以转换为一个关系模式。
与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为各实体码的组合。
具有相同码的关系模式可合并。
具体的基本E-R图向关系模型的转化如下:
顾客:
CUSTUMER(CID、CNAME、CSEX、CADDRESS、CTELL)
送餐员:
EMPLOYEE(EID、ENAME、ESEX、EADDRESS、ETELL)
菜品:
DISHES(DID、DNAME、DPRICE)
订单:
ORDERCP(OID、OTIME、OSTATE、CID、CNAME、CADDRESS、CTELL、EID、ETELL、DNAME、DPRICE、ODNUM)
留言:
MESSAGE(MID、MMID、MDID、MCONTENT)
关系模式CUSTUMER,EMPLOYEE,DISHES,ORDER,MESSAGE不存在非主属性对主属性的部分函数依赖,也不存在传递函数依赖,已经达到了3NF。
2.数据库模式定义
根据分析,本数据库共创建如下5个表。
顾客信息表
列名
数据类型
可否为空
说明
Char
notnull
NChar
送餐员信息表
EName
ESex
送
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 数据库原理 数据库原理 外卖订餐系统 数据库 原理 外卖 系统