民航售票管理系统实验报告Word下载.docx
《民航售票管理系统实验报告Word下载.docx》由会员分享，可在线阅读，更多相关《民航售票管理系统实验报告Word下载.docx（46页珍藏版）》请在冰豆网上搜索。
机场还要有紧急应对措施，在航班出现延误时，要发送相应的信息。
本系统至少能完成如下查询功能：
（1）查某代售地某月售出的票数和金额。
（2）查航空公司拥有多少航班。
（3）查某天某航空还剩多少票或座位。
（4）查某天某航空还剩商务舱座位以及经济舱座位票价。
（5）查某航空公司拥有多少售票点、某月售出总金额以及某航线售出票数。
二、实验环境
本系统开发平台及运行环境如下：
系统开发平台：
MicrosoftVisualStudio2015
系统开发语言：
C#
数据库管理软件：
SQLServer2014
运行平台：
Windows10教育版
运行环境：
FrameworkSDK
三、实验内容与步骤
1.系统需求分析
（1）信息要求：
指用户需要从数据库中获得信息的内容与性质。
数据库中需要存储哪些数据。
本系统是针对民航售票进行管理，主要涉及航空公司信息、客户信息、飞机信息、航线信息、航班信息、订票信息等多种数据信息。
用户名和密码信息：
字段名
数据类型
长度
主键否
描述
Username
varchar
16
是
用户名
Password
密码
Userclass
char
1
用户类别
航空公司信息：
Aid
编号
Aname
64
名称
Aaddr
地址
Acont
32
联系方式
机场信息：
APid
APname
APaddr
APcont
客户信息：
Cid
Cname
姓名
Ccont
11
IsSpec
特殊客户？
Points
int
里程积分
飞机信息：
Pid
Type
型号
SeatsNum
座位数
外键
航空公司编号
座位信息：
Sid
Level
座位等级
飞机编号
IsChoose
是否被选
航线信息：
Lid
SPosition
起点
EPosition
终点
Distance
real
里程
航班信息：
Fid
Ftime
datetime
时间
航线编号
机场编号
Price
票价
订票信息：
Bid
Identity（1,1）
航班编号
客户编号
座位编号
Pay
购票金额
Btime
购票时间
（2）处理要求：
用户需要完成什么处理功能，对处理的响应时间有什么要求（给出功能模块图）。
民航售票管理系统主要满足三类用户的要求，这三类用户分别是航空公司管理员、机场管理员和客户（分为普通客户和经常旅客）。
航空公司管理员提供航线和飞机的资料，机场管理员则对在本机场起飞和降落的航班和机票进行管理，而客户能得到的服务应该有航班线路和剩余票数的查询，以及网上订票等功能。
具体的需求分析如下：
1）航空公司管理员：
1提供飞机基本信息
2提供航班基本信息
3查询售票点信息、某月售出总金额以及某航线售出票数
2）机场管理员：
1对本机场的航班信息进行管理
2对本机场的机票信息进行管理
3查询某月售票数量和金额
3）客户：
1查询航班信息
2机票订购
3里程积分优惠（经常旅客）
功能模块图如下所示：
图1功能模块图
（3）安全性与完整性要求。
数据库的安全性是指保护数据库，防止不合法的使用所造成的数据泄露和破坏。
数据库系统中保证数据安全性的主要措施是进行存取控制，即规定不同用户对于不同数据对象所允许执行的操作，并控制各用户只能存取他有权（操作权力）存取的数据。
存取控制机制分为自主存取控制?
（DAC）与强制存取控制（MAC），主要包括两部分：
?
一是定义用户权限，并将用户权限登记到数据字典中；
二是合法权限检查。
数据库完整性指数据的（逻辑而非物理）正确性和相容性。
为了防止数据库中存在不合语义的数据，防止错误数据的输入和输出。
数据库完整性技术包括完整性约束条件与完整性检查两部分。
完整性约束条件指为维护数据库的完整性，DBMS提供加在数据库数据之上的语义约束条件，作为数据库模式的一部分存入数据库。
完整性检查意味检查数据库是否满足完整性约束条件的机制。
完整性约束条件作用的对象可以是关系、元组、列三种。
其中列约束主要是列的类型、取值范围、精度、排序等的约束条件。
元组的约束是元组中各个字段间的联系的约束。
关系的约束是若干元组间、关系集合上以及关系之间的联系的约束。
完整性约束条件涉及这三类对象，其状态可以是静态的，也可以是动态的。
完整性约束条件一般分为实体完整性、参考完整性?
自定义完整性。
定义实体完整性约束条件要考虑修改关系中主码的问题；
定义参考完整性约束条件要考虑外码能否接受空值问题、在被参照关系中删除元组的问题（级联删除或受限删除）、在参照关系中插入元组时的问题。
2.概念结构设计
根据分析，民航售票管理系统包含航空公司、机场、客户、飞机、座位、航线、航班及机票8个实体，各个实体的局部E-R图如下所示，其中航空公司编号是航空公司实体的主码，机场编号是机场实体的主码，客户编号是客户实体的主码，飞机编号是飞机实体的主码，座位编号是座位实体的主码，航线编号是航线实体的主码，航班编号是航班实体的主码，机票编号是机票实体的主码。
图2航空公司实体及属性
图3机场实体及属性
图4客户实体及属性
图5飞机实体及属性
图6座位实体及属性
图7航线实体及属性
图8航班实体及属性
图9机票实体及属性
（1）逐一设计分ER图，合并分ER图，生成基本ER图。
根据需求分析的结果可以看到，在民航售票管理系统中一个航空公司可以提供多条航线、多架飞机，飞机拥有多个座位，一个机场可以安排多个航班，一个航班对应一架飞机、涉及一条航线、可以有多个客户选择乘坐，一个客户可以订购多张机票，一张机票对应一个座位。
由以上分析可得各个局部的E-R图，如下所示（忽略各个实体的属性）：
图10航空公司与飞机及航线之间的E-R图
图11飞机与航班之间的E-R图
图12航班与航线之间的E-R图
图13机场与航班之间的E-R图
图14客户与航班之间的E-R图
图15客户与机票之间的E-R图
图16飞机与座位之间的E-R图
图17座位与机票之间的E-R图
（2）若在合并中存在属性冲突、命名冲突以及结构冲突，给出解决办法，若存在不必要的冗余，则消除并给出设计方法。
合并分E-R图并不是单纯地将各个分E-R图画在一起，而是必须消除各个分E-R图中的不一致，以形成一个能为全系统中所有用户共同理解和接受的统一的概念模型。
各个分E-R图之间的冲突包括3种：
属性冲突、命名冲突以及结构冲突。
经过分析，将航空公司、机场、客户、飞机、座位、航线、航班及机票之间进行关联。
因此，合并各个分E-R图，生成基本E-R图，如下所示：
图18民航管理系统基本E-R图
（3）基本ER图中要求标明主码、外码、联系类型。
基本E-R图中，各实体的主码用下划线加粗显示，外码倾斜加粗表示，联系类型表明于连接线上。
3.逻辑结构设计
（1）给出由ER得到的关系模型，并注明转换过程中应用的规则。
E-R图向关系数据模型转换的基本规则如下：
1）一个实体转换为一个关系模式，实体的属性就是关系的属性，实体的键就是关系的键；
2）一个联系转化为一个关系模式，与该联系相连的各个实体的键以及联系的属性为该关系的属性，该关系的键分为3种情况：
11:
1联系：
任一相连实体的键都可以作为该关系的主键。
21:
n联系：
n端（多端）实体的键作为该关系的主键。
3m:
各端实体的键的组合为该关系的主键。
其中，1:
1联系可以和联系的任意一端实体的关系模式合并，将联系的属性和另一端关系模式的键加入该关系模式即可；
1:
n联系则需要和多端的关系模式合并，在多端关系模式中加入联系的属性和1端关系模式的键即可；
m:
n联系不能与实体合并，必须转换为单独的关系模式。
根据E-R图向关系数据模型转换的相关规则，将图18所示的E-R图转换为关系数据模型，得到民航售票管理系统的关系模式如下：
航空公司（编号，名称，地址，联系方式），应用规则1）。
升级会员 