数据库课程设计火车票售票管理系统.docx

上传人:b****5 文档编号:11709046 上传时间:2023-03-30 格式:DOCX 页数:23 大小:108.60KB
下载 相关 举报
数据库课程设计火车票售票管理系统.docx_第1页
第1页 / 共23页
数据库课程设计火车票售票管理系统.docx_第2页
第2页 / 共23页
数据库课程设计火车票售票管理系统.docx_第3页
第3页 / 共23页
数据库课程设计火车票售票管理系统.docx_第4页
第4页 / 共23页
数据库课程设计火车票售票管理系统.docx_第5页
第5页 / 共23页
点击查看更多>>
下载资源
资源描述

数据库课程设计火车票售票管理系统.docx

《数据库课程设计火车票售票管理系统.docx》由会员分享,可在线阅读,更多相关《数据库课程设计火车票售票管理系统.docx(23页珍藏版)》请在冰豆网上搜索。

数据库课程设计火车票售票管理系统.docx

数据库课程设计火车票售票管理系统

 

课程设计说明书

(数据库技术及实训)

 

题目:

火车票售票管理系统

 

院系:

计算机科学与工程学院

专业班级:

学号:

学生姓名:

指导教师:

 

2014年5月4日

课程设计(论文)任务书

计算机科学与工程学院数字媒体系

学号

学生姓名

专业(班级)

物联网工程12-2

设计题目

火车票售票管理系统

数据库:

SQLServer2005或2000开发语言:

C#、JAVA、C++等

(1)主要的数据表:

车次数据表,火车票信息数据表,顾客信息数据表等。

(2)主要功能模块

系统管理:

系统用户帐号添加、修改、删除、密码修改等。

火车票分类管理:

添加、删除、修改。

火车票信息管理:

实现图书信息的添加、修改、删除、查询等。

火车票查询:

要求提供多种检索方式。

火车票管理:

查询售票、改签、退票、帐户管理。

(1)1~3人为一个小组,小组成员既要有团队协作精神,又要分工明确。

每个学生都必须充分了解整个设计的全过程。

(2)从开始的系统需求分析到最后的系统测试,都要有详细的计划,设计文档应按照软件工程的要求书写。

(3)系统中的数据表设计应合理、高效,尽量减少数据冗余。

课程设计说明书字数要求3000以上,不包括图表。

第10周开始课程设计选题,然后和组员进行讨论与分析设计。

第11周收集、查阅资料形成课程设计思路。

第12周开始课程设计的前两部分,即系统分析和系统设计方面的设计。

第13周把后面两部分,即系统实现和总结完成。

第14周讨论并检查设计,进一步完善课程设计报告。

[1]王珊,萨师煊.数据库系统概论[M].北京:

高等教育出版社,2005.

[2]周奇.SQLServer2005数据库基础与应用技术[M].北京:

电子工业出版社,2008

[3]C#高级编程(第6版)中文版[M].

指导教师签字

教研室主任签字

年月日

摘要

中国铁路客票发售和预订系统的核心功能是建立一个覆盖全国铁路的计算机售票网络,实现客票管理和发售工作现代化,从而方便旅客购票和旅行,提高铁路客运经营水平和服务质量,系统可预订、预售和发售当日客票,具有售返程、联程等异地购票功能。

系统预售期为20天。

可以实现票额、坐席、制票、计费、结算、统计等工作的计算机管理。

系统采用微软推出的VisualStudio2005作为开发工具基于B/S结构,数据库采用微软的SQLServer2005进行数据库设计。

关键词:

铁路客运服务;计算机售票网络;SQLServer2005

目录

1系统分析1

1.1课题背景1

1.2目的和意义1

1.3可行性分析1

2系统设计3

2.1数据字典3

2.2数据流图3

2.3系统模块总体设计11

2.4数据库概念结构设计11

3系统实现13

3.1数据库逻辑结构设计13

3.3测试15

4总结16

4.1设计体会16

4.2系统改进16

参考文献17

1系统分析

1.1课题背景

中国拥有总里程超过五万公里的铁路线,是世界上最大的铁路运输网之一,而铁路客运服务在其中又占有非常重要的地位。

其中有5000多个车站承办业务,日开列车2000多列。

为了在日益加剧的客户运输竞争服务中确保优秀,改善铁路客户的服务质量,铁道部门一直在寻找提高竞争力、改善服务的途径。

计算机应用火车站售票的日常管理为火车站售票的现代化带来了前所未有的动力和机遇,为火车站票务管理领域的飞速发展提供了无限潜力。

能给火车站票务带来明显的经济效益和社会效益。

1.2目的和意义

火车票票务管理的全部数据处理都由人工操作,工作量大,工作效率低,错误率高,信息反馈不及时,因此本系统拟对该火车票票务管理做如下几方面改革:

✧系统功能重构

✧业务流程重组

✧数据流程重组

为解决上述问题,要根据目前火车票的管理模式和方法利用Internet、局域网和计算机开发基于Web的火车票订票管理信息系统,可以实现票额、坐席、制票、计费、结算、统计等工作的计算机管理。

形成统一的客票信息源,实现信息共享。

1.3可行性分析

根据火车售票的实际情况,对其所开展的业务简单介绍如下:

(1)查询。

为对车次信息的查询和对已订车票用户的车票信息的查询。

车次信息包括:

日期、车次、出发地、目的地、类型、座位号、票价。

车次信息只允许用户查询,不能修改。

(2)售票。

通过查询系统,可以根据客户的需求找到车次,再输入客户信息后确定售票,订票信息应包括:

姓名、身份证号、车次、日期、类型、座位号、票价。

(3)改签。

通过查询系统,根据客户名字找到购票信息,通过改签模块选择要改的车票。

(4)退票。

可退票,通过查询系统,根据客户的名字找到购票信息,通过退票模块退去已购车票。

(5)帐户管理。

只允许管理人员登录,管理人员可以修改票务信息。

图1-1功能层次图

 

2系统设计

2.1数据字典

数据字典的作用是在软件分析和设计的过程中给人提供关于数据的描述信息。

它主要是对数据流图中的数据流、处理逻辑、外部实体、数据存储和数据项等方面进行具体的定义。

数据流程图配以数据字典,就可以从图形和文字两个方面对系统的逻辑模型进行完整的描述。

编号

名称

别名

类型

长度

101-01

id

售票员编号

int

4

101-02

username

售票员姓名

varchar(50)

50

101-03

systemset

系统设置权限

bit

1

101-04

passagermanager

乘客管理权限

bit

2

101-05

ticketmanager

火车票管理权限

bit

3

101-06

ticketpurchase

火车票购买权限

bit

4

101-07

systemsearch

系统查询权限

bit

5

102-01

userid

售票员编号

int

4

102-02

username

售票员姓名

varchar(50)

50

102-03

pwd

售票员密码

varchar(51)

50

103-01

number

车次

varchar(10)

10

103-02

departure

出发地

varchar(100)

100

103-03

destination

目的地

varchar(50)

50

103-04

type

类型

int

4

103-05

seatnumber

座位号

int

4

103-06

price

票价

varchar(50)

50

103-07

date

日期

varchar(51)

50

103-08

remain

余票

varchar(52)

50

104-01

idnumber

身份证号

varchar(50)

50

104-02

name

姓名

varchar(50)

50

104-03

sex

性别

char(10)

10

104-04

passagertype

乘客类型

varchar(50)

50

105-01

number

车次

varchar(10)

10

105-02

idnumber

身份证号

varchar(50)

50

105-03

price

票价

varchar(50)

50

2.2数据流图

数据流图是以图形的方式描绘数据在系统中流动和处理的过程,由于它只反映系

统必须完成的逻辑功能,所以它是一种功能模型。

该火车票管理系统的数据流图描述

——由火车票管理员对火车票账户进行管理,包括系统基本信息、售票管理、退票及改签管理以及火车票查询。

以下将对火车票售票管理系统的具体各功能模块进行描述。

系统基本信息模块是对火车票的基本情进行管理,为火车票的管理工作搭建一个基础平台。

该数据流图如图2-2所示。

图2-1售票流程图

售票是是火车站的基本业务,是管理工作的重点。

其基本业务包括火车票数据查询、购票,退票管理和改签管理。

图2-2退票流程图

图2-3改签流程图

图2-4账户管理流程图

2核心数据流定义

数据字典的内容主要是对数据流程图中的数据项、数据结构、数据流、处理逻辑、数据存储和外部实体等六方面进行具体的定义。

数据流编号:

D01

数据流名称:

票务信息

简述:

关于车票的基本信息

数据流来源:

顾客通过查询

数据流去向:

买票

数据流组成:

103-01+103-02+103-03+103-04+103

-05+103-06+103-07+103-08+104-01+104-02+104-04+105-01+105-02+105-0

数据流编号:

D02

数据流名称:

发出买票请求

简述:

乘客选择的去买车票

数据流来源:

p1.1

数据流去向:

售票员

数据流组成:

101-01+103-01+103-02+103-03+103-06

数据流编号:

D03

数据流名称:

查询

简述:

售票员对车票剩余情况查询

数据流来源:

售票员

数据流去向:

F1车次数据表

数据流组成:

101-01+101-02+102-03+103-08

数据流编号:

D04

数据流名称:

反馈

简述:

通过数据表将车票信息反馈给售票员

数据流来源:

F1车次数据表

数据流去向:

售票员

数据流组成:

103-06+103-08+105-01

数据流编号:

D05

数据流名称:

请求处理

简述:

售票员向系统请求处理票务信息

数据流来源:

售票员

数据流去向:

P1.2

数据流组成:

103-07+103-06+103-08

数据流编号:

D06

数据流名称:

车费、车座信息、票价

简述:

系统处理数据传达给顾客

数据流来源:

p1.2

数据流去向:

顾客

数据流组成:

103-07+103-06+103-08+103-05+103-04+103-01

数据流编号:

D11

数据流名称:

车票信息

简述:

顾客对车票信息进行查询

数据流来源:

顾客

数据流去向:

P2.1

数据流组成:

103-01+103-02+103-03+103-04+103

-05+103-06+103-07+103-08+104-01+104-02+104-04+105-01+105-02+105-03

数据流编号:

D12

数据流名称:

判断能否退票

简述:

通过退票规定判断是否能退票

数据流来源:

P2.1

数据流去向:

F3

数据流组成:

103-06+103-07+103-08

数据流编号:

D13

数据流名称:

查询规定

简述:

售票员通过查询规定进行判断退票的可行性

数据流来源:

售票员

数据流去向:

F3

数据流组成:

103-06+103-07+103-08+101-01+101-02+102-01+102-02+102-03

数据流编号:

D14

数据流名称:

根据顾客要求

简述:

售票员根据顾客信息查询系统

数据流来源:

售票员

数据流去向:

P2.2

数据流组成:

103-06+103-07+103-08+101-01+101-02+102-01+102-02+102-03

 

数据流编号:

D15

数据流名称:

反馈

简述:

系统反馈销售记录

数据流来源:

P2.2

数据流去向:

F2

数据流组成:

103-06+103-07+103-08

数据流编号:

D16

数据流名称:

应退票价、不能退的车票

简述:

系统判断是否能为顾客退票

数据流来源:

P2.2

数据流去向:

顾客

数据流组成:

103-06+103-07+103-08+104-04+104-02+104-03+105-02

数据流编号:

D21

数据流名称:

车票信息

简述:

车票的基本信息

数据流来源:

火车票管理员

数据流去向:

P3.1

数据流组成:

103-01+103-02+103-03+103-04+103

-05+103-06+103-07+103-08+104-01+104-02+104-04+105-01+105-02+105-0

数据流编号:

D22

数据流名称:

判断能否退票

简述:

根据改签规定判断能否退票

数据流来源:

P3.1

数据流去向:

F5

数据流组成:

103-06+103-07+103-08

数据流编号:

D23

数据流名称:

查询规定

简述:

售票员查询改签规定

数据流来源:

售票员

数据流去向:

F5

数据流组成:

103-06+103-07+103-08

数据流编号:

D24

数据流名称:

根据顾客要求

简述:

售票员分类处理顾客要求

数据流来源:

售票员

数据流去向:

P3.2

数据流组成:

103-06+103-07+103-08+101-01+101-02+102-01+102-02+102-03

数据流编号:

D25

数据流名称:

同意改签、不同意改签

简述:

返回改签的结果

数据流来源:

P3.2

数据流去向:

顾客

数据流组成:

103-06+103-07+103-08+104-04+104-02+104-03+105-02

数据流编号:

D31

数据流名称:

反馈数据

简述:

向高层管理反馈数据

数据流来源:

客户

数据流去向:

P4.1

数据流组成:

103-01+103-02+103-03+103-04+103

-05+103-06+103-07+103-08+104-01+104-02+104-04+105-01+105-02+105-03

数据流编号:

D33

数据流名称:

反馈查询结果

简述:

根据要查询数据反馈查询结果

数据流来源:

P4.3

数据流去向:

系统管理员

数据流组成:

103-07+103-06+103-08

数据流编号:

D34

数据流名称:

发送客户要求

简述:

系统管理员发送客户要求给退票规定

数据流来源:

系统管理员

数据流去向:

P6

数据流组成:

103-07+103-06+103-08+103-05+103-04+103-01

数据流编号:

D35

数据流名称:

系统检查

简述:

根据退票规定检查结果

数据流来源:

F6

数据流去向:

P4.2

数据流组成:

103-07+103-06+103-08+103-05+103-04+103-01

3.核心处理逻辑定义

处理逻辑编号:

P1.1

处理逻辑名称:

买票

简述:

买票操作

输入的数据流:

D01

处理:

根据顾客输入的购票信息,进行数据操作

输出的数据流:

D02

处理逻辑编号:

P1.2

处理逻辑名称:

票务处理

简述:

对火车票相关信息管理

输入的数据流:

D05

处理:

根据输入的信息进行操作

输出的数据流:

D06

处理逻辑编号:

P2.1

处理逻辑名称:

查询数据

简述:

对车票相关信息进行查询

输入的数据流:

D11

处理:

根据输入的信息进行查询操作

输出的数据流:

D12

处理逻辑编号:

P2.2

处理逻辑名称:

分类处理

简述:

根据顾客要求和销售记录对火车票进行分类处理

输入的数据流:

D03

处理:

根据输入的信息进行退票、拒绝退票操作操作

输出的数据流:

D15,D16

3.重要数据存储编号

数据存储编号:

F1

数据存储名称:

车次数据表

简述:

存储车票数据

数据存储组成:

I03-01+I03-02+I03-03+I03-04+I03-05+I03-06+I03-07+I03-08

关键字:

I03-01

相关联的处理:

P1.1,P1.2

数据存储编号:

F2

数据存储名称:

销售记录

简述:

存储车票销售的记录

数据存储组成:

I04-01+I04-02+I04-03+I04-04

关键字:

I05-01

相关联的处理:

P2.2

数据存储编号:

F3

数据存储名称:

退票规定

简述:

存储退票相关的规定

数据存储编号:

F3

数据存储名称:

书架信息表

简述:

存储书架设置信息的记录

数据存储组成:

I04-01+I04-02

关键字:

I04-01

相关联的处理:

P1.3

2.3系统模块总体设计

本系统一共分为三个模块,每个模块之间虽然在表面上是相互独立的,但是在对数据库的访问上是紧密相连的。

每个功能模块的设计都是根据前几个阶段的分析来设计的,符合系统的设计要求。

根据上述功能的分析,系统中模块分为车票查询、车票预定、更新火车票信息三个子系统。

模块设计如图2-5所示。

图2-5H图

2.4数据库概念结构设计

(1)概述

在系统的数据库设计中,首先要对系统分析得到的数据词典中的数据存储进行分析,分析各数据存储之间的关系,可采用E-R图的方法进行数据结构分析。

这里以火车票预定数据库为例。

(2)实体-关系模型(E-R模型)

 

图2-6E-R图

(3)建立逻辑模型

实体:

车次信息表(车次,出发地,目的地,类型,座位号,票价,日期,余票)

顾客信息表(身份证号,姓名,性别,乘客类型)

火车票信息表(车次,身份证号,票价)

联系:

查询、买票、退票、改签

3系统实现

3.1数据库逻辑结构设计

根据火车票的实际情况,本系统的数据库命名为:

ticketmanager是用来存储售票员信息、车次信息、顾客信息、火车票信息等的各种数据。

Ticketmanager数据库共分为5张信息表,以下是系统的5张表的信息,如表3-1至3-5所示。

表3-1addset(售票员权限表)

序号

英文名

中文名

类型

长度(字符)

1

id

售票员编号

int

4

2

username

售票员姓名

varchar(50)

50

3

systemset

系统设置权限

bit

1

4

passagermanager

乘客管理权限

bit

1

5

ticketmanager

火车票管理权限

bit

1

6

ticketpurchase

火车票购买权限

bit

1

7

systemsearch

系统查询权限

bit

1

 

表3-2conductor(售票员信息表)

序号

英文名

中文名

类型

长度(字符)

1

userid

售票员编号

int

4

2

username

售票员姓名

varchar(50)

50

3

pwd

售票员密码

varchar(50)

50

 

表3-3number(车次信息表)

序号

英文名

中文名

类型

长度(字符)

1

number

车次

varchar(10)

10

2

departure

出发地

varchar(100)

100

3

destination

目的地

varchar(50)

50

4

type

类型

int

4

5

seatnumber

座位号

int

4

6

price

票价

varchar(50)

50

7

date

日期

varchar(50)

50

8

remain

余票

varchar(50)

50

 

表3-4customer(顾客信息表)

序号

英文名

中文名

类型

长度(字符)

1

idnumber

身份证号

varchar(50)

50

2

name

姓名

varchar(50)

50

3

sex

性别

char(10)

10

4

passagertype

乘客类型

varchar(50)

50

 

表3-5ticketnumber(火车票信息表)

序号

英文名

中文名

类型

长度(字符)

1

number

车次

varchar(10)

10

2

idnumber

身份证号

varchar(50)

50

3

price

票价

varchar(50)

50

3.2数据库逻辑结构实现

创建数据库的相关SQL代码如下:

创建数据库:

Createdatabaseticketmanager;

创建表addset:

Createtableaddset(

Idintprimarykey,

Usernamevarchar(50),

Systemsetbit,

Passagermanagerbit,

Ticketmanagerbit,

Ticketpurchasebit,

Systemsearchbit

);

Createtableconductor(

Useridintprimarykey,

Usernamevarchar(50),

Pwdvarchar(50)

);

Createtablenumber(

Numbervarchar(10)primarykey,

Departurevarchar(100),

Destinationvarchar(50),

Typeint,

Seatnumberint,

Pricevarchar(50),

Datevarchar(50),

Remainvarchar(50)

);

Createtablecustomer(

Idnumbervarchar(50)primarykey,

Namevarchar(50),

Sexchar(10),

Passagertypevarchar(50)

);

Createtableticketnumber(

Numbervarchar(10)primarykey,

Idnumbervarchar(50),

Pricevarchar(50)

);

 

3.3测试

系统测试是信息系统的开发周期中一个十分重要的活动。

尽管在系统开发周期的各个阶段均采取了严格的技术审查,但仍然难免遗留下差错,如果没有再投入运行前的系统测试阶段被发现纠正,问题迟早会在运行中暴露出来,到那时要纠正错误将要会付出更大的代价。

因此我们有必要进行系统测试。

我们要以找错误为目的,不是要证明程序无错,而是要精心选取那些易于发生错误的测试数据,以十分挑剔的态度,去寻找程序的错误。

测试工作应避免由原开发软件的个人或小组来承担。

设计测试用列不仅要包括合理、有效的输入数据,还要包括无效的或者不合理的输入数据。

不仅要检验程序是否做了该做的事,还要检查程序是否同时做了不该做的事。

保留测试用例,将会给重新测试和追加测试带来方便。

4总结

4.1设计体会

这次课程设计的成功,让我深刻感受到了组员团结合作的重要性,一开始我们组员商讨的意见不统一,然后就开始各做各的,结果快一个星期了每个人都没多大进展。

后来我们反复讨论修改决定大家分工合作,一个人做一个模块,每个人把自己负责的一块写好,然后放在一起大家来检查,经过这个方法,我们每个人的任务就轻了很多,做课程设计的兴趣也就多了很多,于是很快大家就完成了各自的任务。

另外,通过这次课程设计我也深刻意识到学习计算机编程,

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

当前位置:首页 > 解决方案 > 解决方案

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

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