民航售票管理系统实验报告

[键入文档标题]

[键入文档副标题]

安徽大学

计算机科学与技术1班

陈斌E

陈柚霖E

刘昊霖E

2016-9-20

目录

一、目的及要求

1.实验目的

(1)通过本次课程设计，熟练掌握一种开发语言（如C#）和一种数据库系统软件

（如SQL?server?2014）的使用。

(2)加深对软件工程的理解，训练编写程序的良好习惯。包括：认真编写需求分

析文档、做好系统功能和数据库设计、学会自己进行程序的算法、数据结构设计。

(3)培养良好的程序设计风格（模块划分、接口设计、程序界面、应用系统设计）

和习惯（程序备份、版本更新与控制），提高软件测试、调试的能力与技巧。

(4)通过本次课程设计，应该达到具有独立完成小型应用系统设计的能力，具备

编写较为规范的软件设计文档的能力。

2.实验要求

民航售票管理系统主要分为机场、航空公司和客户三方的服务。航空公司提供航线和飞机的资料，机场则对在本机场起飞和降落的航班和机票进行管理，而客户能得到的服务应该有航班线路和剩余票数的查询，以及网上订票等功能。客户又可以分为两类，一类是普通客户，对于普通客户只有普通的查询功能和订票功能，没有相应的机票优惠，另一种是经常旅客，需要办理注册手续，但增加了里程积分功能和积分优惠政策。机场还要有紧急应对措施，在航班出现延误时，要发送相应的信息。

本系统至少能完成如下查询功能：

(1)查某代售地某月售出的票数和金额。

(2)查航空公司拥有多少航班。

(3)查某天某航空还剩多少票或座位。

(4)查某天某航空还剩商务舱座位以及经济舱座位票价。

(5)查某航空公司拥有多少售票点、某月售出总金额以及某航线售出票数。

二、实验环境

本系统开发平台及运行环境如下：

系统开发平台：Microsoft Visual Studio 2015

系统开发语言：C#

数据库管理软件：SQL Server 2014

运行平台：Windows10 教育版

运行环境： Framework SDK

三、实验内容与步骤

1.系统需求分析

(1)信息要求：指用户需要从数据库中获得信息的内容与性质。数据库中需要存

储哪些数据。

本系统是针对民航售票进行管理，主要涉及航空公司信息、客户信息、飞机信息、航线信息、航班信息、订票信息等多种数据信息。

(2)处理要求：用户需要完成什么处理功能，对处理的响应时间有什么要求（给

出功能模块图）。

民航售票管理系统主要满足三类用户的要求，这三类用户分别是航空公司管理员、机场管理员和客户（分为普通客户和经常旅客）。航空公司管理员提供航线和飞机的资料，机场管理员则对在本机场起飞和降落的航班和机票进行管理，而客户能得到的服务应该有航班线路和剩余票数的查询，以及网上订票等功能。具体的需求分析如下：

1)航空公司管理员：

①提供飞机基本信息

②提供航班基本信息

③查询售票点信息、某月售出总金额以及某航线售出票数

2)机场管理员：

①对本机场的航班信息进行管理

②对本机场的机票信息进行管理

③查询某月售票数量和金额

3)客户：

①查询航班信息

②机票订购

③里程积分优惠(经常旅客)

功能模块图如下所示：

图1 功能模块图

(3)安全性与完整性要求。

数据库的安全性是指保护数据库，防止不合法的使用所造成的数据泄露和破坏。数据库系统中保证数据安全性的主要措施是进行存取控制，即规定不同用户对于不同数据对象所允许执行的操作，并控制各用户只能存取他有权（操作权力）存取的数据。存取控制机制分为自主存取控制?（DAC）与强制存取控制（MAC），主要包括两部分：??

一是定义用户权限，并将用户权限登记到数据字典中；

二是合法权限检查。

数据库完整性指数据的（逻辑而非物理）正确性和相容性。为了防止数据库中存在不合语义的数据，防止错误数据的输入和输出。数据库完整性技术包括完整性约束条件与完整性检查两部分。完整性约束条件指为维护数据库的完整性，DBMS提供加在数据库数据之上的语义约束条件，作为数据库模式的一部分存入数据库。完整性检查意味检查数据库是否满足完整性约束条件的机制。完整性约束条件作用的对象可以是关系、元组、列三种。其中列约束主要是列的类型、取值范围、精度、排序等的约束条件。元组的约束是元组中各个字段间的联系的约束。关系的约束是若干元组间、关系集合上以及关系之间的联系的约束。完整性约束条件涉及这三类对象，其状态可以是静态的，也可以是动态的。?完整性约束条件一般分为实体完整性、参考完整性?自定义完整性。定义实体完整性约束条件要考虑修改关系中主码的问题；定义参考完整性约束条件要考虑外码能否接受空值问题、在被参照关系中删除元组的问题（级联删除或受限删除）、在参照关系中插入元组时的

问题。

2.概念结构设计

根据分析，民航售票管理系统包含航空公司、机场、客户、飞机、座位、航线、航班及机票8个实体，各个实体的局部E-R图如下所示，其中航空公司编号是航空公司实体的主码，机场编号是机场实体的主码，客户编号是客户实体的主码，飞机编号是飞机实体的主码，座位编号是座位实体的主码，航线编号是航线实体的主码，航班编号是航班实体的主码，机票编号是机票实体的主码。

图2 航空公司实体及属性

图3机场实体及属性

图4客户实体及属性

图5 飞机实体及属性

图6 座位实体及属性

图7 航线实体及属性

8 航班实体及属性

图

(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种情况：

①1:1联系：任一相连实体的键都可以作为该关系的主键。

②1:n联系：n端(多端)实体的键作为该关系的主键。

③m:n联系：各端实体的键的组合为该关系的主键。

其中，1:1联系可以和联系的任意一端实体的关系模式合并，将联系的属

性和另一端关系模式的键加入该关系模式即可；1:n联系则需要和多端的

关系模式合并，在多端关系模式中加入联系的属性和1端关系模式的键

即可；m:n联系不能与实体合并，必须转换为单独的关系模式。

根据E-R图向关系数据模型转换的相关规则，将图18所示的E-R图转换为关系数据模型，得到民航售票管理系统的关系模式如下：

航空公司（编号，名称，地址，联系方式），应用规则1)。

航线（编号，航空公司编号，起点，终点，里程），应用规则2)-②1:n联系。

飞机（编号，航空公司编号，型号，座位数），应用规则2)-②1:n联系。

机场（编号，名称，地址，联系方式），应用规则1)。

航班（编号，飞机编号，航线编号，机场编号，时间，座位等级，票价），应用规则2)-①1:1联系及规则2)-②1:n联系。

座位（编号，飞机编号，等级，被选？），应用规则2)-②1:n联系。

客户（编号，姓名，联系方式，特殊客户？，积分），应用规则1)。

机票（编号，座位编号，航班编号，客户编号，金额），应用规则2)-①1:1联系及规则2)-②1:n联系。

(2)数据模型的优化。

数据库的逻辑设计的结果不是唯一的。为了进一步提高数据库应用系统的性能，还应该根据应用需要适当地修改、调整数据模型的结构，这就是数据模型的优化。关系数据模型的优化通常以规范化理论为指导。

(3)确定数据依赖。

分别写出每个关系内部属性的以及不同关系模式属性间的数据依赖。根据需求分析可知：

1.航空公司关系模式的数据依赖：{编号->名称，编号->地址，编号->联系

方式}；

2.航线关系模式的数据依赖：{编号->航空公司编号，编号->起点，编号->

终点，编号->里程}；

3.飞机关系模式的数据依赖：{编号->航空公司编号，编号->型号，编号->

座位数}；

4.机场关系模式的数据依赖：{编号->名称，编号->地址，编号->联系方式}；

5.航班关系模式的数据依赖：{编号->飞机编号，编号->航线编号，编号->

机场编号，编号->时间，（编号，座位等级）->票价}；

6.座位关系模式的数据依赖：{编号->飞机编号，编号->等级，编号->被选？}；

7.客户关系模式的数据依赖：{编号->姓名，编号->联系方式，编号->特殊

客户？，编号->积分}；

8.机票关系模式的数据依赖：{编号->座位编号，编号->航班编号，编号->

客户编号，编号->金额}；

(4)对各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。

采用分析方法，根据数据项之间逻辑关系的说明，已经消除了各个关系模式之间的数据冗余联系。

(5)按照数据依赖的理论确定个关系模式分别属于第几范式。

根据各个范式的定义：

1)航空公司关系模式属于BCNF，因为该关系模式的码是航空公司编号，且

每一个决定因素都包含码，所以∈BCNF；

2)航线关系模式属于BCNF，因为该关系模式的码是航线编号，且每一个决

定因素都包含码，所以∈BCNF；

3)飞机关系模式属于BCNF，因为该关系模式的码是飞机编号，且每一个决

定因素都包含码，所以∈BCNF；

4)机场关系模式属于BCNF，因为该关系模式的码是机场编号，且每一个决

定因素都包含码，所以∈BCNF；

5)航班关系模式属于1NF，因为该关系模式的码是（编号，座位等级），存

在非主属性部分依赖于码，所以∈1NF；

6)座位关系模式属于BCNF，因为该关系模式的码是座位编号，且每一个决

定因素都包含码，所以∈BCNF；

7)客户关系模式属于BCNF，因为该关系模式的码是客户编号，且每一个决

定因素都包含码，所以∈BCNF；

8)机票关系模式属于BCNF，因为该关系模式的码是机票编号，且每一个决

定因素都包含码，所以∈BCNF；

(6)用户子模式设计。

将概念模型转换为全局逻辑模型后，还应该根据局部应用需求，结合具体DBMS的特点设，计用户的外模式。

机场管理员查某代售地某月售出的票数和金额，建立相应视图：

视图1（机场编号，机场名称，月售票数，月售票金额）；

客户查航空公司拥有多少航班，建立相应视图：

视图2（航空公司编号，航空公司名称，航班总数）；

客户查某天某航空还剩多少票或座位，建立相应视图：

视图3（航空公司编号，航空公司名称，剩余票数，剩余座位数）；

客户查某天某航空还剩商务舱座位以及经济舱座位票价，建立相应视图：视图4（航空公司编号，航空公司名称，航班编号，座位等级，票价）；

航空公司管理员查某航空公司拥有多少售票点、某月售出总金额以及某航线售出票数，建立相应视图：

视图5（航空公司编号，航空公司名称，售票点总数，月售总金额）；

视图6（航空公司编号，航空公司名称，航线编号，售出票数）；

(7)对不同级别用户定义不同的视图保证系统安全性。

客户只能查看航空公司、机场等基本信息，及票价信息、座位信息，个人基本信息；航空公司管理员可以查看涉及该航空公司的所有信息（如售票统计信息等），机场管理员可以查看涉及该机场的所有信息（如该机场售票统计信息等）。

4.数据库与应用系统的实施和维护

(1)应用程序的编码和调试。

(2)给出截图（标明图号）简单阐述该模块的基本功能。

给出该模块的设计思路，针对难点部分进行详细地阐述。

首先是登录模块：

输入用户名和密码，选择登录用户，点击登录。链接数据库，检查数据库中是否存在该用户，以及密码是否正确，如果错误，提示用户名或密码错误，否则进入相应的用户界面。

相关代码：

ells[j].Value == null)

{

("存在不完整信息,请检查录入信息", "提示");

return;

}

}

}

for (int i = 0; i < ; i++)

{

string sql = "";

switch (type)

{

case 1:

sql = ("insert into Plane values('{0}','{1}',{2},'{3}')", [i].Cells[0].(), [i].Cells[1].(), [i].Cells[2].Value), Aid);

break;

case 2:

sql = ("insert into Sit values('{0}','{1}','{2}','N')", [i].Cells[0].(), [i].Cells[1].(), [i].Cells[2].());

break;

case 3:

sql = ("insert into Line

values('{0}','{1}','{2}',{3},'{4}')", [i].Cells[0].(), [i].Cells[1].(), [i].Cells[2].(),