数据库实习论文快餐店管理系统数据库设计大学论文Word文档格式.docx

上传人:b****6 文档编号:20746177 上传时间:2023-01-25 格式:DOCX 页数:46 大小:590.98KB
下载 相关 举报
数据库实习论文快餐店管理系统数据库设计大学论文Word文档格式.docx_第1页
第1页 / 共46页
数据库实习论文快餐店管理系统数据库设计大学论文Word文档格式.docx_第2页
第2页 / 共46页
数据库实习论文快餐店管理系统数据库设计大学论文Word文档格式.docx_第3页
第3页 / 共46页
数据库实习论文快餐店管理系统数据库设计大学论文Word文档格式.docx_第4页
第4页 / 共46页
数据库实习论文快餐店管理系统数据库设计大学论文Word文档格式.docx_第5页
第5页 / 共46页
点击查看更多>>
下载资源
资源描述

数据库实习论文快餐店管理系统数据库设计大学论文Word文档格式.docx

《数据库实习论文快餐店管理系统数据库设计大学论文Word文档格式.docx》由会员分享,可在线阅读,更多相关《数据库实习论文快餐店管理系统数据库设计大学论文Word文档格式.docx(46页珍藏版)》请在冰豆网上搜索。

数据库实习论文快餐店管理系统数据库设计大学论文Word文档格式.docx

是根据系统详细调查过程中所得的资料和问卷调查的结果,按业务实际处理过程将它们绘制在同一张图上。

1.1数据流程图

数据流程图:

是一种能全面地描述信息系统逻辑模型的主要工具,它可以用少数几种符号综合地反映出信息在系统中的流动、处理和存储情况。

数据流程图的绘制采取自顶向下逐层分解的办法。

首先,画出顶层(第一层)数据流程图。

顶层数据流程图只有一张,应概括地反映信息系统最主要的逻辑功能、外部实体和数据存储,并且能让用户一看就明白这个系统的主要功能、外部实体以及与环境的主要联系是什么。

图1.1顶层业务流程图

第一层是对顶层数据流程图中的处理功能进行逐层分解,形成多级数据流程图

.图1.2第一层数据流程图

第二层是分解上层图中的数据处理。

一般沿着输入流的方向,凡数据流的组成或值发生变化的地方则设置一个数据处理,这样一直进行到输出数据流

P1采购分为P1.1购买食材,P1.2退货,P1.3检验,P1.4入库;

P2盘存与报损分为P2.1账实比对,P2.2报损处理,P2.3编制盘点清单;

P3销售分为P3.1顾客订单,P3.2厨师做菜,P3.3食材出库

图1.3进货系统

图1.4盘存与报销系统

图1.5销售系统

1.2数据字典

数据字典是用来对数据流程图中的各个元素作出详细的说明,是对数据流程图中的数据项、数据结构、数据流、处理逻辑、数据存储和外部实体进行定义和描述的工具,也是数据分析和管理工具,同时也是系统设计阶段进行数据库设计的重要依据。

(1)数据项:

又称数据元素,是数据的最小单位。

在数据字典中,数据项的描述包括:

数据项的名称、编号、简述;

数据项的类型及长度;

数据项的取值范围。

在快餐店管理系统中有53个数据项(见附录1)

(2)数据结构:

描述某些数据项之间的关系。

一个数据结构可以由若干个数据项组成;

也可以由若干个数据结构组成,还可以由若干个数据项和数据结构组成。

数据字典中对数据结构的定义包括以下内容:

数据结构的名称和编号;

简述;

数据结构的组成。

在快餐店管理系统中有14个数据结构(见附录2)

(3)数据流由一个或一组固定的数据项组成。

定义数据流时,不仅要说明数据流的名称、组成等,还应指明它的来源、去向和数据流量等.在快餐店管理系统中有29个数据流(见附录3)

(4)处理逻辑:

是对数据流程图中每一个不能再分解的基本处理的精确说明。

处理逻辑仅仅是对数据流程图中最底层的处理逻辑加以说明。

处理逻辑描述包括:

处理逻辑编号、名称、简述、输入及输出数据流、处理频率以及对处理的解释。

在快餐店管理系统中有10个处理逻辑(见附录4)

(5)数据存储:

在数据字典中只描述数据的逻辑存储结构,而不涉及它的物理组织。

通常情况下,数据存储给出某个文件的定义,并列出文件中记录的组成数据项。

数据存储描述的内容有:

数据存储编号、名称、简述、组成、相关联的处理等。

在快餐店管理系统中有9个数据存储(见附录5)

2.数据库结构设计

主要包括概念设计和逻辑设计两个部分。

2.1概念设计

概念设计目标:

将需求分析得到的用户需求抽象为信息结构(即概念模型)

任务和方法:

概念设计部分的主要任务是绘制E-R图。

首先绘制各个分E-R图,然后消除三类冲突,使之整合为全局ER图。

在需求分析阶段已经得到了应用需求,只有将这些应用需求进行综合、归纳与抽象,形成一个独立于具体DBMS的概念模型,具有以下特点才能更好地、更准确地用某一DBMS实现这些需求。

(1)能真实、充分地反映现实世界,包括事物和事物之间的联系,能满足用户对数据的处理要求,是对现实世界的一个真实模型。

(2)易于理解,从而可以用它和不熟悉计算机的用户交换意见,用户的积极参与是数据库设计成功的关键。

(3)易于更改,当应用环境和应用要求改变时,容易对概念模型修改和扩充。

(4)易于向关系、网状、层次等各种数据模型转换。

E-R图是关系模型的雏形,每个实体是一张表,实体与实体之间的关系可以合并到其中一个实体中,也可以单独形成另外一张独立的表,其中关系表和其相关的实体表是通过主键或外键来联系的。

一、建立分E-R图时,首先要对实体和属性进行划分。

划分准则有两条:

1.作为属性,必须是不可再分的数据项。

2.属性与其他实体之间不能有联系。

二、E-R图的三个要素是实体、属性和联系:

1、实体:

用矩形表示,矩形框内写明实体名。

2、属性:

椭圆形表示,椭圆内写明属性名称,并用连线与实体连接起来。

如果属性较多,为使图形更加简明,有时也将实体与其相应的属性另外单独用列表表示。

3、联系:

菱形表示,菱形框内写明联系名,并用连线分别与有关实体连接起来,同时在连线旁标上联系的类型。

2.1.1分E-R图建立

图2.1进货分E-R图

实体属性如下:

1.销售单(销售单ID,销售日期)

2.销售明细(销售明细ID,菜名ID,价格,备注)

3.食材(食材ID,食材名称,食材种类)

4.货架(货架ID,货架食材名称,货架食材种类,货架食材数量)

5.菜单细则(菜名编号,菜名,价格)

 

图2.2报损与报损分E-R图

实体属性:

1.缺损单(缺损编号,缺损菜名,缺损属性,缺损数量)

图2.3销售分E-R图

1.采购单(采购单ID,时间,备注)

2.采购明细(食材编号,采购单编号,明细ID,备注,食材种类,食材数量,价格)

3.供应商(供应商地址,供应商编号,供应商供应食材种类,供应商联系电话)

4.不合格清单(清单ID,备注)

5.供货单(供货单ID,时间,食材种类,食材数量,供应商编号)

6.检验(不合格清单ID,食材ID,不合格食材数量,检验时间)

2.1.2全局/整体E-R图

1.解决各分E-R图之间的冲突,将分E-R图合并起来生成初步E-R图。

冲突包括属性冲突,命名冲突,结构冲突。

其中属性冲突需要各部门讨论协商;

处理命名冲突通常也像处理属性冲突一样,通过讨论,协商等行政手段解决;

结构冲突是根据应用的语义对实体联系的类型进行综合和调整。

2.修改和重构。

消除不必要的冗余,生成基本E-R图。

消除冗余主要采用分析方法,即以数据字典和数据流程图为依据,根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。

图2.4总E-R图

2.菜单细则(菜名编号,菜名,价格,销售单ID)

4.货架(货架ID,货架存放量)

5.缺损关系(缺损编号,食材ID,缺损属性,缺损数量)

6.采购单(采购单ID,时间,备注)

7.采购明细(食材编号,采购单ID,明细ID,食材数量,价格)

8.供应商(供应商编号,供应商名称,供应商地址,供应商供应食材种类,供应商联系电话)

9.不合格清单(不合格清单ID,时间,供应商ID)

10.供货单(供货单ID,时间,食材ID,食材数量,供应商编号,采购单号)

11.存放(货架ID,食材ID,数量)

12.检验(不合格清单ID,食材ID,不合格食材数量,检验时间)

2.2逻辑设计

逻辑设计就是在E-R图的基础上转换出相对应的关系模式,并进行规范化处理,使各个关系模式满3NF。

2.2.1建立关系模式

E-R图向关系模型的转换一般遵循如下原则:

1.一个实体型转换为一个关系模式。

实体的属性就是关系的属性。

实体的码就是关系的码。

2.一个联系转化为一个关系模式,与该联系相连的各实体的码以及联系的属性转化为关系的属性,该关系的码则有三种情况:

若联系为1:

1,则每个实体的码均是该关系的后选码;

若联系为1:

n,则关系的码为n端实体的码;

若联系为m:

n,则关系的码为诸实体码的组合。

2.1联系为1:

1

一个1:

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

如果转换为一个独立的关系模式,则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,每个实体的码均是该关系的候选码。

如果与某一端对应的关系模式合并,则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。

2.2联系为1:

n

n联系可以转换为一个独立的关系模式,也可以与n端对应的关系模式合并。

如果转换为一个独立的关系模式,则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为n端实体的码。

如果与n端对应的关系模式合并,则在n端实体对应模式中加入1端实体所对应关系模式的码,以及联系本身的属性。

而关系的码为n端实体的码。

2.3联系为m:

一个m:

n联系转换为一个关系模式。

与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性。

而关系的码为各实体码的组合。

3.同一实体集的实体间的联系,即自联系,也可按上述1:

1、1:

n和m:

n三种情况分别处理。

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

为了减少系统中的关系个数,如果两个关系模式具有相同的主码,可以考虑将他们合并为一个关系模式。

合并方法是将其中一个关系模式的全部属性加入到另一个关系模式中,然后去掉其中的同义属性(可能同名也可能不同名),并适当调整属性的次序。

将E-R模型转换为关系模式有:

13.制作关系(食材编号,菜名编号)

14.缺损单(缺损单编号,时间)

注:

用下划线标明每个关系的主码。

2.2.2关系模式规范化处理

规范化理论正是用来改造关系模式,通过分解关系模式来消除其中不合适的数据依赖,以解决插入异常、删除异常、更新异常和数据冗余问题。

根据范式理论,分析每个关系的主属性和非主属性,写出每个非主属性对主码的函数依赖,以此来分析每一个关系模式是否满足3NF,对不满足3NF的关系模式要进行模式分解,使每个关系模式达到3NF的要求。

1.第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。

2、第二范式(2NF)是数据库规范化中所使用的一种正规形式。

它的规则是要求数据表里的所有数据都要和该数据表的主键有完全依赖关系;

如果有哪些数据只和主键的一部份有关的话,它就不符合第二范式。

同时可以得出:

如果一个数据表的主键只有单一一个字段的话,它就一定符合第二范式。

3、第三范式,是指每个非关键字列都独立于其他非关键字列,并依赖于关键字。

也就是指数据库中不能存在传递函数依赖关系。

关系模式R<

U,F>

中若不存在这样的码X、属性组Y及非主属性Z(Z(强制依赖)Y),使得X→Y,Y→Z,成立,Y→X不成立,则称R<

∈3NF。

若R∈3NF,则R的每一个非主属性既不部分函数依赖于候选码也不传递函数依赖于候选码

2.2.3用户子模式建立

根据需求分析,研究建立满足不同需求的用户子模式。

用户子模式也称外模式、子模式或用户模式,是数据库用户(包括应用程序员和最终用户)能够看见和使用的局部数据的逻辑结构和特征的描述;

是数据库用户的数据视图,是与某一应用有关的数据的逻辑表示一个数据库可以有多个外模式;

外模式就是用户视图;

外模式是保证数据安全性的一个有力措施。

快餐店系统包含了3个视图。

分别是

1.查询菜系含有辣椒的菜名

2.查询货架的存放量

3.采购的食材的数量

2.2.4关系模式逻辑结构定义

对每个关系模式要以表格形式描述其具体内容。

表2-1销售单关系模式

属性名

含义

数据类型

是否主键

是否外键

约束条件

xsno

销售单ID

Varchar2(40)

Notnull

xstime

销售日期

date

表2-2菜单细则关系模式

vno

菜名编号

Varchar2

(40)

vname

菜名

vprice

价格

Number

表2-3食材关系模式

scno

食材ID

scname

食材名称

sctype

食材种类

表2-4货架关系模式

hjno

货架ID

hjnum

货架存放量

表2-5缺损单关系模式

qsno

缺损编号

qssx

缺损属性

qsqty

缺损数量

表2-6采购单关系模式

buyno

采购单ID

buytime

时间

Date

beizhu

备注

Varchar(40)

表2-7采购明细关系模式

buymxno

Qty

price

明细ID

数量

number

表2-8供应商关系模式

gyno

供应商编号

gyname

供应商名称

gyaddress

供应商地址

gytel

供应商联系电话

表2-9不合格清单关系模式

Nqdbo

不合格清单编号

Varchar2(80)

表2-10供货单关系模式

ghno

供货单ID

ghtime

ghqty

供货食材数量

采购单号

供应商ID

表2-11存放关系模式

qty

表2-12检验关系模式

nqdno

不合格清单ID

nspqty

不合格数量

jytime

检验时间

表2-13制作关系模式

Scno

食材编号

表2-14缺损单关系模式

Qsno

缺损单编号

Time

3.数据库物理设计

为主要数据表建立了相应的索引如:

1.createindexIND_ADDRESSonGONGYINGSHANG(GYADDRESS)2.createindexIND_VPRICEonCAIDANXICE(VPRICE)

4.数据库实施与测试

主要包括数据库实施和测试两个部分。

4.1数据库及数据库对象建立

主要包括:

基本表、视图、索引、存储过程以及触发器的建立过程和建立语句。

4.1.1.基本表

1.销售单

createtablexiaoshoudan

(xsnovarchar2(40)primarykeynotnull,

xstimedate)

2.菜单细则

createtablecaidanxice

(vnovarchar2(40)primarykeynotnull,

vnamevarchar2(40)unique,

vpricenumber,

xsnovarchar2(40),

foreignkey(xsno)referencesxiaoshoudan(xsno))

3.食材

createtableshicai

(scnovarchar2(40)primarykeynotnull,

scnamevarchar2(40)unique,

sctypevarchar2(40))

4.货架关系

createtablehuojia

(hjnovarchar2(40)primarykeynotnull,

hjnumnumber)

5.缺损关系

createtablequesun

(qsnovarchar2(40)notnull,

scnovarchar2(40),

qsqtynumber,

qssxvarchar2(40),

primarykey(qsno,scno))

6.采购单

createtablecaigoudan

(buynovarchar2(40)primarykeynotnull,

buytimedate,

beizhuvarchar2(40)

7.采购明细

createtablecaigoumingxi

(scnovarchar2(40),

buynovarchar2(40),

buymxnovarchar2(40),

qtynumber,

primarykey(buyno,scno),

foreignkey(buyno)referencescaigoudan(buyno),

foreignkey(scno)referencesshicai(scno)

8.供应商

createtablegongyingshang

(gynovarchar2(40)primarykeynotnull,

gynamevarchar2(40),

gyaddressvarchar2(20),

gytelvarchar2(20)

9.不合格清单

createtablebuhegeqingdan

(Nqdnovarchar2(40)primarykeynotnull,

10.供货单

createtablegonghuodan

(ghnovarchar2(40)primarykeynotnull,

ghtimedate,

ghqt

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > IT计算机 > 计算机硬件及网络

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1