网上订票管理系统docxWord文件下载.docx
《网上订票管理系统docxWord文件下载.docx》由会员分享，可在线阅读，更多相关《网上订票管理系统docxWord文件下载.docx（39页珍藏版）》请在冰点文库上搜索。
6）退票
7）注销
非功能性需求
为了保证系统能够长期、安全、稳定、可靠、高效的运行，网上订票系统应该满足
以下的性能需求：
系统处理的准确性和及时性
系统处理的准确性和及时性是系统的必要性能。
在系统设计和开发过程中，要充分
考虑系统当前和将来可能承受的工作量，使系统的处理能力和响应时间能够满足企业对
信息处理的需求。
由于网上订票管理系统的查询功能对于整个系统的功能和性能完成举足轻重。
作为
系统的很多数据来源，而机票数量和时间又影响企业的决策活动，其准确性很大程度
上决定了网上订票管理系统的成败。
在系统开发过程中，必须采用一定的方法保证系
统的准确性。
系统的开放性和系统的可扩充性
网上订票管理系统在开发过程中，应该充分考虑以后的可扩充性。
例如用户查询的
需求会不断的更新和完善。
这些都要求系统提供足够的手段进行功能的调整和扩充。
而
要实现这一点，应通过系统的开放性来完成，既系统应是一个开放系统，只要符合一定
的规范，可以简单的加入和减少系统的模块，配置系统的硬件。
通过软件的修补、替换
完成系统的升级和更新换代。
系统的易用性和易维护性
网上订票管理系统是直接面对使用人员的，而使用人员往往对计算机并不时非常熟
悉。
这就要求系统能够提供良好的用户接口，易用的人机交互界面。
要实现这一点，就
要求系统应该尽量使用用户熟悉的术语和中文信息的界面；
针对用户可能出现的使用问
题，要提供足够的在线帮助，缩短用户对系统熟悉的过程。
网上订票管理系统中涉及到的数据是航空公司和机场的相当重要的信息，系统要提
供方便的手段供系统维护人员进行数据的备份，日常的安全管理，系统意外崩溃时数据
的恢复等工作。
系统的标准性
系统在设计开发使用过程中都要涉及到很多计算机硬件、软件。
所有这些都要符合
主流国际、国家和行业标准。
同时，在自主开发本系统时，要进行良好的设计工作，制
订行之有效的软件工程规范，保证代码的易读性、可操作性和可移植性。
系统的先进性
目前计算系统的技术发展相当快，作为网上订票管理系统工程，应该保证系统在相
当长的时间内仍旧是先进的，在系统的生命周期尽量做到系统的先进，充分完成企业信
息处理的要求而不至于落后。
这一方面通过系统的开放性和可扩充性，不断改善系统的
功能完成。
另一方面，在系统设计和开发的过程中，应在考虑成本的基础上尽量采用当
前主流并先进且有良好发展前途的产品。
系统的响应速度
网上订票管理系统在日常处理中的响应速度为秒级以及时反馈信息。
根据所需数据
量的不同而从秒级到分钟级，原则是保证操作人员不会因为速度问题而影响工作效率。
数据需求
顶层数据流图
资料提供信息
网上订票
管理系统
客户订票查询
管理信息
管理查询
订票信息
1层数据流图
航线信息
查询航线
信息
查询航线信息请求
飞机信息
查新飞机
查询飞机信息请求
提供航
线资料
查询客户信息请求
提供飞机
查看客户
资料
查询个人
客户信息
查
客
航班信息
询
户
信
查询航班
航
息
班
请
查询航班信息请求
求
订机票请求
订机票
更新
订票
安排航
退机票请求
退机票订票
3概念设计
局部视图设计
概念结构设计的第一步就是对需求分析阶段收集到的数据按照E-R模型的要求进行分
类、组织，形成实体、实体的属性，标识试题的码，确定实体之间的联系类型（1：
11：
nm：
n），设计分E-R图。
将航空公司提供资料部分提取出来，如下图所示：
提供航
航线信息飞机信息
提供飞机
飞机信息飞机信息
经分析之后得到的分E-R图如下所示：
飞机
n
1
提供
m
航线
对每个实体的属性定义如下：
航空公司{编号，名称，地址，联系方式}
飞机{编号，型号，座位数}
航线{起点，终点，编号}
将机场安排航班部分提取出来，如下图所示：
航班安
排
将客户的查询部分提取出来，如下图所示：
在数据流图中的“客户信息”都可以作为属性来对待。
对每个实体和联系的属性定义如下：
航班安排{编号，时间，票价}
客户{编号，姓名，性别，年龄，联系方式}
将客户的订票、退票部分提取出来，如下图
客户订票信息
11
退票
订票信息{编号，票价}
视图集成
各子系统的分E-R图设计好后，下一步就是将所有的分E-R图综合成一个系统的总
E-R图。
则集成后的总E-R图如下所示：
其中对每个实体和联系的属性定义如下：
客户{编号，姓名，性别，年龄，联系方式
}
再将属性加到上页所示的E-R图上，最后得到的E-R图如下所示：
名称地址
编号
联系方式
座位数
型号
编号提供
时间
票价
年龄
姓名
飞机航线
编码
1订票信息
编号性别
起点
终点
4逻辑设计
概念结构独立于任何DBMS数据模型的信息结构。
逻辑结构设计的任务就是把概念结构
设计阶段设计好的基本E-R图转换为与选用的DBMS产品所支持的数据模型相符合的逻辑
结构。
E-R图向关系模型的转换
E-R图向关系模型的转换要解决的问题是如何将实体和实体型间的联系转换成为关系
模式，如何确定这些关系模式的属性和码。
关系模型的逻辑结构是一组关系模式的集合。
E-R图则是由实体型、实体型的属性和实体之间的联系3个要素组成的。
所以将E-R图转换成关系模型实际上就是要将实体型、实体型的属性和实体之间的联系转换成一组关系模式。
这种转换一般遵循如下原则：
（1）一个1：
1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为该关系的属性，每个实体的码均是该关系的候选码。
如果与某一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。
（2）一个1：
n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。
如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。
（3）一个m：
n联系转换为一个关系模式。
与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。
（4）3个或3个以上实体间的一个多元联系可以转换为一个关系模式。
与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组
合
（5）具有相同码的关系模式可合并。
根据以上的原则，通过E/R模型到关系模型的转化，可以得到如下关系模式：
（1）“航空公司”实体型所对应的关系模式：
Airline（AID,Name,Addr,Cont）
（2）“客户”实体型所对应的关系模式：
Customer（CID,Name,Sex,Age,Cont）
（3）“飞机”实体型所对应的关系模式：
Plane（PID,Type,SeatsNum,
AID
）
此关系模式已包含了联系“提供”
（4）“航线”实体型所对应的关系模式：
Line（LID,SPosition,EPosition,
（5）“航班安排”联系所对应的关系模式：
Flight（FID,PID,LID,Ftime,Price）
（6）“订票信息”实体型所对应的关系模式：
BookTicket（BID,FID,CID,Price）
此关系模式已包含了联系“订票”和“退票”
其中，以上的每个关系模式的键码都用下划线标出，外键码用斜体标出。
数据模型的优化
数据库逻辑设计的结果不是唯一的。
为了提高数据库应用系统的性能，还应该根据应用需要适当的修改、调整关系模式，这就是个数据模型的优化。
确定数据依赖：
（1）关系模式Airline（AID,Name,Addr,Cont）中的数据依赖
AID->
Name,AID->
Addr,AID->
Cont
（2）关系模式Customer（CID,Name,Sex,Age,Cont）
中的数据依赖
CID->
Name,CID->
Sex,CID->
Age,CID->
（3）关系模式Plane（PID,Type,SeatsNum,）
PID->
Type,PID->
SeatsNum,PID->
（4）关系模式Line（LID,SPosition,EPosition,
AID中的数据依赖
LID->
SPosition,LID->
EPosition,LID->
（5）关系模式Flight（FID,PID,LID,Ftime,Price）
FID->
PID,FID->
LID,FID->
Ftime,FID->
Price
（6）关系模式BookTicket（BID,FID,CID,Price）
BID->
FID,BID->
CID,BID->
Pay
对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。
分析后可知，关系模式
BookTicket（BID,
FID
CID
和关系模式
Flight（FID,
Price）
PID
LID
Ftime,Price）
有
的数据冗余，于是将关系模式
BookTicket
改成
BookTicket（BID,FID,CID）。
修改后的各个关系模式均没有冗余的联系。
按照规范化理论对关系模式逐一进行分析，考查是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。
由于以上的关系模式的主码只有一个，所以不会存在部分函数依赖。
分析后可知也不存在传递依赖和多值依赖，以上的各关系模式都是3NF。
按照需求分析阶段得到的信息要求和处理要求，分析这些模式是否满足这些要求，确定是否要对某些模式进行合并或分解。
（1）关系模式Airline（AID,Name,Addr,Cont）能满足“修改公司信息”“增加航线”
“修改航线”“删除航线”功能。
（2）关系模式Customer（CID,Name,Sex,Age,Cont）能满足“管理客户资料”“修
改个人信息”功能。
（3）关系模式
能满足“管理飞机（座位数）资
Plane（PID,Type,SeatsNum,）
料中所提供的相关数据”功能。
（4）关系模式
能满足“管理航空公司提供
的航线”功能。
（）关系模式
能满足“根据航空公司提供
5
Flight（FID,,
的航线，安排航班以及航班的机票”“如果出现晚点等情况，要记录并发送信息”“管理航班机票”功能。
（6）关系模式BookTicket（BID,FID,CID）能满足“注册”“登录”“查询航班”“查询余票和票价”“预定机票”“退票”“注销”
数据库的模式定义
数据库需要表述的信息有以下几种：
航空公司信息
根据以上的关系模式可以建立如下的表：
航空公司信息表
列名
数据类型
可否空
说明
Varchar
Notnull
航空公司编号
Name
航空公司名称
Addr
航空公司地址
航空公司联系方式
客户信息表
客户编号
客户姓名
Sex
客户性别
Age
Int
客户年龄
客户联系方式
飞机信息表
飞机编号
Type
飞机型号
SeatsNum
飞机座位数
varchar
航线信息表
航线编号
SPosition
航线起点
EPosition
航线终点
航班安排信息表
航班编号
Ftime
Datetime
航班时间
Real
订票信息表
BID
机票编号
5物理设计
数据库在实际物理设备上的存储结构和存取方法成为数据库的物理结构。
对于设计好
的逻辑数据模型选择一个符合应用要求的物理结构就是数据库的物理设计。
为了提高在表中搜索元组的速度，在实际实现的时候应该基于键码建立索引。
下面各
表中建立索引的表项。
（1）Airline（AID）
（2）Customer（CID）
（3）Plane（PID）
（4）Line（LID）
（5）Flight（FID）
（6）BookTicket（BID）
6数据库实现
用SQL实现建表
建立航空公司表
CREATETABLEAirline（
AIDvarchar（20）PRIMARYKEY,
Namevarchar（100）NOTNULL,
Addrvarchar（100）,
Contvarchar（200）
）;
建立客户表
CREATETABLECustomer（
CIDvarchar（20）PRIMARYKEY,
Namevarchar（50）NOTNULL,
Sexvarchar
（2）,
Ageint，
建立飞机信息表
CREATETABLEPlane（
PIDvarchar（20）PRIMARYKEY,
Typevarchar（50）NOTNULL,
SeatsNumintNOTNULL,
AIDvarchar（20）,CONSTRAINTFK_PLANE_AIDFOREIGNKEY（AID）REFERENCESAirline（AID）
建立航线表
CREATETABLELine（
LIDvarchar（20）PRIMARYKEY,
SPositionvarchar（100）NOTNULL,
EPositionvarchar（100）NOTNULL,
AIDvarchar（20）,CONSTRAINTFK_LINE_AIDFOREIGNKEY（AID）REFERENCESAirline（AID）
建立航班安排表
CREATETABLEFlight（
FIDvarchar（20）PRIMARYKEY,
PIDvarchar（20）,CONSTRAINTFK_FLIGHT_PIDFOREIGNKEY（PID）REFERENCESPlane（PID）,
LIDvarchar（20）,CONSTRAINTFK_FLIGHT_LIDFOREIGNKEY（LID）REFERENCESLine（LID）,
FtimedatetimeNOTNULL,
PricerealNOTNULL
建立订票信息表
CREATETABLEBookTicket（
BIDintPRIMARYKEYAUTO_INCREMENT,
FIDvarchar（20）,CONSTRAINTFK_BOOKTICKET_FIDFOREIGNKE
升级会员 