网上订票管理系统1 问题描述网上订票管理系统是在网络环境下实现飞机的订票业务的管理系统。
系统改变了传统的手工订票、送票、柜台支付方式，具有广泛的实用性。
网上订票系统的总目标是：在计算机网络，数据库和先进的开发平台上，利用现有的软件，配置一定的硬件，开发一个具有开放体系结构的、易扩充的、易维护的、具有良好人机交互界面的网上订票系统。
该系统是为机场、航空公司和客户提供订票退票等与机票相关容的管理系统，方便机场工作人员对机票的管理，以提高机场工作人员对机票管理工作的效率。
当前飞机订票问题：手工订票所产生的客座率低。
而我们的目标是：建立一个网上飞机订票系统数据库。
航空公司提供航线和飞机的资料，机场则对在本机场起飞和降落的航班和机票进行管理，而客户能得到的服务应该有查询航班航线、班次、票价和剩余票数以及网上订票功能。
2 需求分析2.1 功能性需求2.2 非功能性需求为了保证系统能够长期、安全、稳定、可靠、高效的运行，网上订票系统应该满足以下的性能需求：2.1.1系统处理的准确性和及时性系统处理的准确性和及时性是系统的必要性能。
在系统设计和开发过程中，要充分考虑系统当前和将来可能承受的工作量，使系统的处理能力和响应时间能够满足企业对信息处理的需求。
由于网上订票管理系统的查询功能对于整个系统的功能和性能完成举足轻重。
作为系统的很多数据来源，而机票数量和时间又影响企业的决策活动，其准确性很大程度上决定了网上订票管理系统的成败。
在系统开发过程中，必须采用一定的方法保证系统的准确性。
2.1.2系统的开放性和系统的可扩充性网上订票管理系统在开发过程中，应该充分考虑以后的可扩充性。
例如用户查询的需求会不断的更新和完善。
这些都要求系统提供足够的手段进行功能的调整和扩充。
而要实现这一点，应通过系统的开放性来完成，既系统应是一个开放系统，只要符合一定的规，可以简单的加入和减少系统的模块，配置系统的硬件。
通过软件的修补、替换完成系统的升级和更新换代。
2.1.3系统的易用性和易维护性网上订票管理系统是直接面对使用人员的，而使用人员往往对计算机并不时非常熟悉。
这就要求系统能够提供良好的用户接口，易用的人机交互界面。
要实现这一点，就要求系统应该尽量使用用户熟悉的术语和中文信息的界面；针对用户可能出现的使用问题，要提供足够的在线帮助，缩短用户对系统熟悉的过程。
网上订票管理系统中涉及到的数据是航空公司和机场的相当重要的信息，系统要提供方便的手段供系统维护人员进行数据的备份，日常的安全管理，系统意外崩溃时数据的恢复等工作。
2.1.4系统的标准性系统在设计开发使用过程中都要涉及到很多计算机硬件、软件。
所有这些都要符合主流国际、国家和行业标准。
同时，在自主开发本系统时，要进行良好的设计工作，制订行之有效的软件工程规，保证代码的易读性、可操作性和可移植性。
2.1.5系统的先进性目前计算系统的技术发展相当快，作为网上订票管理系统工程，应该保证系统在相当长的时间仍旧是先进的，在系统的生命周期尽量做到系统的先进，充分完成企业信息处理的要求而不至于落后。
这一方面通过系统的开放性和可扩充性，不断改善系统的功能完成。
另一方面，在系统设计和开发的过程中，应在考虑成本的基础上尽量采用当前主流并先进且有良好发展前途的产品。
2.1.6系统的响应速度网上订票管理系统在日常处理中的响应速度为秒级以及时反馈信息。
根据所需数据量的不同而从秒级到分钟级，原则是保证操作人员不会因为速度问题而影响工作效率。
2.3 数据需求2.3.1顶层数据流图2.3.2 0层数据流图3 概念设计3.1局部视图设计概念结构设计的第一步就是对需求分析阶段收集到的数据按照E-R模型的要求进行分类、组织，形成实体、实体的属性，标识试题的码，确定实体之间的联系类型（1：1？1：n？m：n？），设计分E-R图。
3.1.1将航空公司提供资料部分提取出来，如下图所示：航线信息对每个实体的属性定义如下：n航空公司{编号，名称，地址，联系方式} 飞机{编号，型号，座位数} 航线{起点，终点，编号}3.1.2将机场安排航班部分提取出来，如下图所示：对每个实体的属性定义如下：飞机{编号，型号，座位数} 航线{起点，终点，编号}1 nm3.1.3将客户的查询部分提取出来，如下图所示：在数据流图中的“客户信息”都可以作为属性来对待。
对每个实体和联系的属性定义如下：航班安排{编号，时间，票价}客户{编号，，性别，年龄，联系方式}3.1.4将客户的订票、退票部分提取出来，如下图对每个实体和联系的属性定义如下：订票信息{编号，票价}客户{编号，，性别，年龄，联系方式} 3.2视图集成3.2.1各子系统的分E-R图设计好后，下一步就是将所有的分E-R图综合成一个系统的总E-R图。
则集成后的总E-R图如下所示：其中对每个实体和联系的属性定义如下：航班安排{编号，时间，票价}航空公司{编号，名称，地址，联系方式}客户{编号，，性别，年龄，联系方式}飞机{编号，型号，座位数}航线{起点，终点，编号}订票信息{编号，票价}3.2.2再将属性加到上页所示的E-R 图上，最后得到的E-R 图如下所示：4 逻辑设计概念结构独立于任何DBMS数据模型的信息结构。
逻辑结构设计的任务就是把概念结构设计阶段设计好的基本E-R图转换为与选用的DBMS产品所支持的数据模型相符合的逻辑结构。
4.1 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, AID)此关系模式已包含了联系“提供”（5）“航班安排”联系所对应的关系模式：Flight(FID, PID, LID, Ftime, Price)（6）“订票信息”实体型所对应的关系模式：BookTicket(BID, FID, CID, Price)此关系模式已包含了联系“订票”和“退票”其中，以上的每个关系模式的键码都用下划线标出，外键码用斜体标出。
4.2数据模型的优化数据库逻辑设计的结果不是唯一的。
为了提高数据库应用系统的性能，还应该根据应用需要适当的修改、调整关系模式，这就是个数据模型的优化。
4.2.1确定数据依赖：（1）关系模式Airline(AID, Name, Addr, Cont)中的数据依赖AID->Name, AID->Name, AID->Addr, AID->Cont（2）关系模式Customer(CID, Name, Sex, Age, Cont)中的数据依赖CID->Name, CID->Sex, CID->Age, CID->Cont（3）关系模式Plane(PID, Type, SeatsNum, AID) 中的数据依赖PID->Type, PID->SeatsNum,PID->AID（4）关系模式Line(LID, SPosition, EPosition, AID)中的数据依赖LID->SPosition,LID->EPosition, LID->AID（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->Pay4.2.2 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。
分析后可知，关系模式BookTicket(BID, FID, CID, Price)和关系模式Flight(FID, PID, LID, Ftime, Price)有Price的数据冗余，于是将关系模式BookTicket改成BookTicket(BID, FID, CID)。
修改后的各个关系模式均没有冗余的联系。
4.2.3 按照规化理论对关系模式逐一进行分析，考查是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几式。
由于以上的关系模式的主码只有一个，所以不会存在部分函数依赖。
分析后可知也不存在传递依赖和多值依赖，以上的各关系模式都是3NF。
4.2.4 按照需求分析阶段得到的信息要求和处理要求，分析这些模式是否满足这些要求，确定是否要对某些模式进行合并或分解。
（1）关系模式Airline(AID, Name, Addr, Cont)能满足“修改公司信息”“增加航线”“修改航线”“删除航线”功能。
（2）关系模式Customer(CID, Name, Sex, Age, Cont)能满足“管理客户资料”“修改个人信息”功能。