数据库课程设计之饭卡管理系统.docx

数据库课程设计之饭卡管理系统.docx

《数据库课程设计之饭卡管理系统.docx》由会员分享，可在线阅读，更多相关《数据库课程设计之饭卡管理系统.docx（19页珍藏版）》请在冰豆网上搜索。

数据库课程设计之饭卡管理系统

xxxx大学

数据库课程设计报告

题目名称学生饭卡管理系统

班级：

小组成员：

指导教师:

2010年1月2日

目录

1引言1

1.1系统定义1

1.2开发目的……………………………………………………………………………………….1

1.3系统背景…………………………………………………………………………………...1

2需求分析1

2.1数据流程图……………………………………………………………………………………..1

2.2数据字典………………………………………………………………………………………..4

2.2.1数据项……………………........................................................................................4

2.2.2数据结构……………………………………………………………………………….5

2.2.3数据流…………………………………………………………………………………6

2.2.4数据存储…………………………………………..……………………………………8

3概念结构设计………………………………………………………………………………………12

4逻辑结构设计………………………………………………………………………………………12

5物理结构设计………………………………………………………………………………………12

6心得体会……………………………………………………………………………………………12

1引言

1.1系统定义：

饭卡管理系统是一套针对大学校园食堂饮食交费、一般消费等方面的信息管理系统，它包括了同学在校内消费各方面内容：

刷卡消费、查询、存款，学生信息管理等。

方便地对同学饭卡信息进行各项操作，定时进行数据的备份更新，保持数据的一致性和准确性，各方面的内容应该相互联系，最终产生各种查询统计报表，以供同学进行检查。

1.2开发目的

饭卡管理系统的主要目的就是把人们从繁琐的交费，找零工作中解放出来，用计算机实现对饭卡的存款，消费，查询、修改、删除以及存储等功能。

同时，用计算机能够快速准确地完成供档案资料的统计和汇总工作以供使用。

1.3系统背景

用户通过系统首页面，创建饭卡，存入钱。

消费时根据饭卡编号判断该用户是否是合法用户，同时进行消费操作。

管理员可以对系统进行注册饭卡、注销饭卡、修改饭卡信息等操作。

2需求分析

2.1数据流程图

图2-1顶层数据流程图

图2-2第二层数据流程图：

饭卡系统

（1）注册系统

（2）充值系统

（3）查询系统

（4）挂失系统

（5）注销系统

图2-3第三层数据流程

2.2数据字典

2.21数据项

学生信息数据项名

数据类型

长度

值域范围

说明

Sno

字符型

6

000001~999999

唯一标识每个学生

Sname

字符型

6

000001~999999

学生的名称

Ssex

字符型

2

男，女

性别

Stel

字符型

11

学生的电话号码

Class

字符型

8

00000001~99999999

班级

Sdept

字符型

8

00000001~99999999

学生所在系

Address

字符型

6

000001~999999

学生住处

卡信息数据项名

数据类型

长度

值域范围

说明

Cno

字符型

6

000001~999999

卡号

Yu‘e

数值型

6

000001~999999

余额

Clock

字符型

1

0或1

若卡上锁显示1，否则为0

卡历史数据项名

数据类型

长度

值域范围

说明

Time

日期型

6

000001~999999

时间

Expenses

数值型

6

000001~999999

金额

Operation

字符型

6

000001~999999

操作

卡历史数据项名

数据类型

长度

值域范围

说明

Dno

字符型

6

000001~999999

食堂号

Wno

字符型

6

000001~999999

窗口号

Manager

字符型

6

000001~999999

负责人

2.22数据结构

编号：

名称：

学生别名：

简述：

描述学生信息

组成：

学号，姓名，性别，班级，系，电话号码，住所

编号：

名称：

饭卡别名：

餐卡

简述：

描述饭卡信息

组成：

卡号，余额，锁

编号：

名称：

饭卡历史别名：

简述：

描述学生对饭卡进行的消费、充值、查询等操作。

组成：

卡号，时间，额，操作

编号：

名称：

食堂别名：

简述：

描述食堂信息

组成：

食堂号，窗口号，负责人

2.23数据存储

编号：

T1名称：

学生信息表别名：

简述：

描述学生信息

组成：

学号，姓名，性别，班级，系，电话号码，住所

关键字：

学号

相关处理：

找到学生相关信息

记录长度：

50

记录数：

数据量：

10000

编号：

T2名称：

饭卡信息表别名：

简述：

描述饭卡信息

组成：

卡号，余额，锁

关键字：

卡号

相关处理：

找到饭卡相关信息

记录长度：

50

记录数：

数据量：

10000

编号：

T3名称：

饭卡历史信息表别名：

简述：

描述饭卡历史信息

组成：

卡号，时间，额，操作

关键字：

卡号，时间

相关处理：

找到学生对饭卡操作信息

记录长度：

50

记录数：

数据量：

100000

编号：

T4名称：

食堂信息表别名：

简述：

描述食堂信息

组成：

食堂号，窗口号，负责人

关键字：

食堂号，窗口号

相关处理：

找到食堂信息

记录长度：

20

记录数：

数据量：

100

2.24数据流

编号：

L1名称：

注册信息别名：

简述：

获取卡

若为数据流

来源：

管理员

去向：

注册

峰值流量：

10000

编号：

L2名称：

充值额别名：

简述：

对饭卡充值

若为数据流

来源：

管理员

去向：

存储与消费

峰值流量：

10000

编号：

L3名称：

挂失信息别名：

简述：

若饭卡丢失，对饭卡加锁

若为数据流

来源：

管理员

去向：

挂失

峰值流量：

10000

编号：

L4名称：

充值额别名：

简述：

对饭卡冲值的金额

若为数据流

来源：

存储与消费

去向：

饭卡信息数据

峰值流量：

1000

编号：

L5名称：

消费额别名：

简述：

学生每次刷卡的消费

若为数据流

来源：

饭卡信息数据

去向：

存储与消费

峰值流量：

300

编号：

L6名称：

余额别名：

简述：

学生饭卡的余额

若为数据流

来源：

存储与消费

去向：

饭卡信息数据

峰值流量：

1000

编号：

L7名称：

饭卡编号别名：

简述：

饭卡的卡号，以示区别

若为数据流

来源：

刷卡器

去向：

存储与消费

峰值流量：

10000

编号：

L8名称：

响应信息别名：

简述：

刷卡器上显示的信息

若为数据流

来源：

存储与消费

去向：

刷卡器

峰值流量：

10000

编号：

L9名称：

消费金额别名：

简述：

刷卡的消费

若为数据流

来源：

刷卡人员

去向：

存储与消费

峰值流量：

1000

编号：

L10名称：

锁信息别名：

简述：

显示卡是否上锁

若为数据流

来源：

挂失

去向：

饭卡信息数据

峰值流量：

10000

编号：

L11名称：

饭卡信息别名：

简述：

显示饭卡的基本信息

若为数据流

来源：

饭卡信息数据

去向：

查询

峰值流量：

10000

编号：

L12名称：

消费信息别名：

简述：

向学生显示消费的基本信息

若为数据流

来源：

查询

去向：

学生

峰值流量：

10000

编号：

L13名称：

注销信息别名：

简述：

学生申请注销饭卡

若为数据流

来源：

注销

去向：

学生

峰值流量：

10000

2.25处理

编号：

P1名称：

注册

输入信息：

注册信息

数据存储：

饭卡信息存储

输出信息：

简要说明：

学生申请饭卡，给予注册

编号：

P2名称：

存储与消费

输入信息：

充值额

数据存储：

饭卡信息

输出信息：

充值额，响应信息

简要说明：

对学生充值、消费等处理

编号：

P3名称：

查询

输入信息：

饭卡信息

数据存储：

饭卡信息，学生信息

输出信息：

学生消费信息及基本信息

简要说明：

查询学生的消费信息

编号：

P4名称：

挂失

输入信息：

挂失信息

数据存储：

饭卡信息数据

输出信息：

锁信息

简要说明：

对学生丢失的饭卡挂失加锁

编号：

P5名称：

注销

输入信息：

饭卡信息

数据存储：

饭卡信息数据

输出信息：

注销信息

简要说明：

对学生的饭卡进行注销，取消相应的信息

编号：

P1.1名称：

判断学生信息一致性

输入信息：

注册信息

数据存储：

是、否

输出信息：

确认信息

简要说明：

判断学生信息是否正确

编号：

P1.2名称：

读取学生信息创建卡

输入信息：

确认信息

数据存储：

学生和饭卡信息数据

输出信息：

学生和饭卡信息

简要说明：

根据学生信息给其注册卡，建立卡信息

编号：

P1.3名称：

创建饭卡信息历史记录表

输入信息：

学生和饭卡信息

数据存储：

饭卡历史信息

输出信息：

创建全部信息

简要说明：

记录学生日常消费信息

编号：

P2.1名称：

存钱

输入信息：

存取额

数据存储：

饭卡余额信息

输出信息：

余额

简要说明：

对学生的饭卡充值

编号：

P2.2名称：

消费

输入信息：

消费额

数据存储：

饭卡余额信息

输出信息：

余额

简要说明：

记录学生的消费情况

编号：

P3.1名称：

判断条件合理性

输入信息：

学生信息

数据存储：

饭卡信息

简要说明：

判断学生信息与饭卡信息是否一致

编号：

P3.2名称：

查询

输入信息：

饭卡信息

数据存储：

饭卡信息和学生信息

输出信息：

查询结果

简要说明：

查询学生的消费信息

编号：

P4.1名称：

挂失状态转换

输入信息：

挂失信息

数据存储：

饭卡信息数据

输出信息：

锁信息

简要说明：

对饭卡进行加锁和解锁的转换

编号：

P4.2名称：

挂失计时

输入信息：

计时开始信息

数据存储：

饭卡信息数据

输出信息：

设置时间

简要说明：

记录挂失时间

编号：

P5.1名称：

判断挂失

输入信息：

注销时间

数据存储：

饭卡信息数据

输出信息：

注销卡号

简要说明：

判断饭卡是否已挂失

编号：

P5.2名称：

注销

输入信息：

注销卡号

数据存储：

饭卡信息数据

输出信息：

注销信息

简要说明：

对饭卡注销

3概念设计

4逻辑设计

学生（学号，姓名，性别，电话号码，班级，系，住所）

饭卡（卡号，消费余额，锁，学号）

卡历史（卡号，时间，消费金额，操作）

食堂（食堂号，窗口号，负责人）

5物理设计

名称

中文名称

类型

长度

取值范围

是否为空

备注

Sno

学号

Char

6

000001~999999

否

Sname

姓名

Char

6

000001~999999

否

Ssex

性别

Char

2

男，女

否

Stel

电话号码

Char

11

000001~999999

是

Class

班级

Char

8

00000001~99999999

否

Sdept

系

Char

8

00000001~99999999

否

Address

住所

Char

6

000001~999999

是

名称

中文名称

数据类型

长度

值域范围

是否为空

备注

Cno

卡号

Char

6

000001~999999

否

Yu‘e

余额

Int

6

000001~999999

是

Clock

锁

Char

1

0或1

是

Sno

学号

Char

6

000001~999999

否

名称

中文名称

数据类型

长度

值域范围

是否为空

备注

Cno

卡号

Char

6

000001~999999

否

Time

时间

Date

6

000001~999999

否

Expenses

消费

Int

6

000001~999999

是

Operation

操作

Char

6

000001~999999

是

名称

中文名称

数据类型

长度

值域范围

是否为空

备注

Dno

食堂编号

Char

6

000001~999999

否

Wno

窗口号

Char

6

000001~999999

否

Manager

负责人

Char

6

000001~999999

否

6设计说明及体会

1、通过整个过程的设计我们了解到了团结合作的重要性。

2、整个小组从管理的角度，全面系统的体验了数据库课程设计的整个过程，发现了完成一项开发软件工程的辛苦与不易。

3、需求分析阶段是时间花的最长、讨论最激烈的阶段。

即便如此，还是觉得需求分析做的不是很彻底，但因为时间及能力的原因，也没法做得更细致了。

4、为了做好设计我们浏览了好多相关资料，加强了自主学习的能力。

任务分配：

由三人共同讨论、分析，形成初步思路，最后的设计报告由三人组合形成，并再次讨论进行修改。