数据库课程设计-飞机订票系统分析与设计.docVIP

. 飞机订票系统分析与设计 1需求分析 为了方便旅客，拟开发一个机票预订系统。旅行社工作人员把预订机票的旅客信息（姓名、性别、工作单位、身份证号码、旅行时间、旅行目的地等）输入系统，系统为旅客安排航班，并打印出取票通知单和帐单，旅客在飞机起飞前一天凭票通知和帐单交款取票，系统校对无误即印机票给旅客。 第一步：找出数据源点和数据终点，确定数据流画出顶层数据流程图 数据源点和数据终点表示数据的外部来源和去处。它通常是系统之外的人员或组 织，不受系统控制。 从问题描述中我们可以知道系统的源点和终点。如“旅行社工作人员把预订机票 的旅客信息输入系统”和“旅客凭票通知和帐单交款取票，系统校对无误后将打印机票给旅客”我们可已依据这两句话，初步了解到了系统的数据源点和数据终点。 有些人会有疑问了，“旅客在飞机起飞前一天凭票通知和帐单交款取票”，那样顾客不是和系统交互了吗？那怎么没有顾客向系统传递信息的数据流呢？的确，顾客是和系统交互了，但不是直接交互，而是间接的通过旅行社工作人员来和系统交互的，所以我们把“旅客在飞机起飞前一天凭票通知和帐单交款取票”这个处理交给了旅行社工作人，因此，就有了上面的图型（工作人员根据旅客的要求和系统进行交互）。机票预订系统的基本系统模型如下： 旅客信息 取票信息 机票 图1 系统模型 第二步：自顶向下，逐层细化 现在我们可以开始细化基本系统模型，从顶层数据流程图可以判断出 “信息处理”、“订票处理”、“取票处理”是订票系统必须完成的主要功能，细化后的第一层数据流程图如下： D1 订票信息 无票或缺票 取票信息 订票信息 （取票通知单与帐单） 旅客信息 错误信息 取票信息 机票 出错信息 D2 取票清单 图2 细化后的数据流程图图 在上图中我们增加了“订票信息”和“取票信息”两个数据存储。 我们现在来看看功能1“信息处理”如何进一步细化，从图2可以知道功能1必定有一子功能是用于判断信息是取票还是订票的，我们命名为“信息类型判断”；根据我们的经验，对于旅行社工作人员输入的信息，系统应该提供一个功能来处理输入（把外部信息转化为内部信息），我们命名为“接收信息”；进一步，考虑下面问题：如果接收信息中的身份证号码不存在，怎么办？很明显，“信息处理”里面应该有一项功能来识别旅客的信息是否合法，验证信息的输入格式是否合法。因此可以分解出“验证信息”的子功能。功能1的流程图如下： D3 旅客信息 错误信息 订票信息 旅客信息 信息 信息 取票信息 图3 功能1“信息处理”数据流程图 对功能2“订票处理”进行细化。问题中关于订票过程的描述有“旅行社工作人员把预订机票的旅客信息（姓名、性别、工作单位、身份证号码、旅行时间、旅行目的地等）输入系统，系统为旅客安排航班，并打印出取票通知单和帐单”，找功能的一般思路是从输入输出着手的，在这里我们可以看出输出的描述“打印出取票通知单和帐单”，因此我们可以认为有一个功能专门负责“打印出取票通知单和帐单”这项功能，命名为“生成取票信息”。 功能2的输入应该是功能1“信息处理”流出的数据流“旅客信息”当“订票处理”接收到这个数据流的时候，还不是为其安排航班。因为还不知道有没有满足旅客的机票，因此必有一个功能判断旅客的需要机票是否存在，如果没有票或票数不足，返回信息。如果有满足旅客要求的机票，那么更新数据存储“机票信息”中的数据。我们把这项功能命名为“机票验证”。 当确定有合适的机票且已经订购时，就要“为旅客安排航班”了！别急，我们想想在安排航班之前我们是否还有其他工作没有完成或有什么可以完善的呢？这样说吧，如果我要定2张A到B的机票和3张C到D的机票，“订票系统”如何处理呢？很明显，系统一次仅能接收2地点相同的订票，如果要预定“A到B的机票和C到D的机票”，那么就要分两次来处理了，打印的取票通知单和帐单分别有2份。我们当然希望对于一个旅客仅有一份取票通知单和帐单，这样不仅方便旅客也节约材料和系统处理时间。 如何来解决上面提出的问题呢？我们可以给每一个旅客分配一张订