【课程设计】数据库：高铁票管理系统

摘要：本文主要介绍了高铁票管理系统火车票预订时间表，其中包括其选题功能绪论，对该系统的方案方式设计，以及过程实现等内容。因为系统的代码量较大，所以将要较为具象地对思想进行介绍，在必要时会列举一些例子，都会附上成果展示以及安装步骤。最后补充一下此次结伙作案的心得感受，只是十分宝贵的财富。

文章目录

序言——起因与动力

本系统是由五位华工师生（刘老师、陈老师、罗老师、鲁老师、卢老师）在闲暇时间中对数据库课程设计进行的一次尝试。缘由在于，尽管我们都有部份项目经验，因此通常状况下，都是由导师为我们所引导安排去施行任务的，所以在此课程下来后，我们就商量着感受一次，从零开始的自主实现项目过程。此次课设为对我们自身的增强有巨大的帮助，因此希望通过这篇文章分享下来。

对于该课设，对于我们的要求就是认真执行，定期举办组会与项目初验。在开发过程中，尝试了新的语言、开发工具以及开发方式等。其中最为印象深刻的是项目的集体讨论设计的过程、语雀gitee等协同开发工具、函数插口的注释标准化等细节内容、前端开发等初尝试。很多都是先前淡淡尝试过的内容，在本次课设中有了更丰富的知识获取。

其实，因为是第一次做这么大的安装工程，也遇见了一些困难的地方，例如在最初的数据库设定完成后，课设举行了一段时间，却发觉设计内容还要更改，此刻更改安装工程量较大，难免会出现一些焦虑情绪，当工作周期长时，也会出现部份拖沓松懈，在小组之间的鼓励与监督下，完成让课设继续进行。可惜的是对于本系统因为时间较短，虽然是开发并不完整的，并且存在并发性以及部份插入的等问题，然而此次课设感受十分难得，学到了许多课堂需不到的内容。

一、选题背景

本课题是实现对高铁票购票的管理系统，具备检票系统、系统管理、综合查询等功能。该系统分为三大版块，分别为检票系统、系统管理和产值对账。以下是每位模块具体介绍。

二、方案论证（设计观念）2.1运行和开发环境2.2面向对象编程

面向对象编程的优势在于易维护、开发效率高和易扩充等，对于易维护，只需维护局部模块，维护上去是十分便捷和费用较低；对于开发效率高，在硬件开发时，按照设计的还要对现实世界的事物进行具象，形成类，通过对类的封装，对其的使用开发的效率和品质；易扩充因为承继、封装、多态的特征，自然设计出高内聚、低耦合的系统结构，并且系统更灵活、更容易扩充，但是费用较低。

后端面向对象编程展现于，每位界面的每位组件都设计为一个类，例如在管理端的用户信息展示窗口中，首先对分栏器、用户信息栏、搜索框进行父类封装，在承继后，通过多态的编程思想，进行再封装，最后装配在一起。

前端面向对象编程展现于，对于数据库通过逻辑结构设计后，可以剖析出各个实体类，进行面对对象的编程。除了这般，因为设计部份工具操作，还额外定义了工具类，作为后端的辅助工具插口类。

2.3前后端分离

对于前后端分离，可以提升工作效率，分工愈发明晰。两端开发可以同时进行，只需通过插口完成联结，双方互不干扰。而且为了在该次大作业中增加每个成员的参与度，所以在任务分配上，每位人就会有对前后端的工作安排。

2.4数据库设计思路2.4.1需求剖析

用户登入注册：用户包括工作人员和旅客，有管理员、售票员、乘客3类用户；普通人可以通过注册功能成为新用户，用户通过登陆可以使用系统提供的相应功能，如添加旅客，订购船票，查询订单等等。

系统还要提供查询火车具体信息的功能：用户按照始发站和终点站，查询可以满足自己行程要求使得正常运行的动车，使得可以逐步查看驾车时间，抵达时间以及火车剩余坐位的数目和票价；用户可以搜索详细的某一趟车次，可以得到该车次的详细路线信息以及发车时间。

系统还要提供购票功能：购票员键入站点即可显示经过该站点的所有可售班次以及班次汽车的坐位状态；一个检票员可同时售数张相似或不同站点，相似或不同票种（一等、二等、站票）的船票，可以实现累加本次购票款，直到上次新检票开始；还应实现辅助提示应找款以及退款的功能，购票员可以查询当日购票账单，旅客也可以通过互联网售票。

系统还要提供管理功能：包括用户管理、线路设置、站点设置、票价设置等。该系统主要分为四大部份，分别为用户、车票、车次和路线版块，每位版块可以进行查询与更改操作，管理员可以添加、修改和删掉用户信息、线路信息、车票信息以及车次信息。

系统还要提供产值对账功能：包括购票员对账、汇总报表。对营销毁款进行管理，可以实时把握西站产值状况，便于财务监督。才能迅速、准确地生成各类产值对账报表。汇总报表主要包括：按照用户选择或则键入的各类条件（包括：时间，购票员，票号等）汇总北站营运数据，包括：售票汇总，改签汇总，预购票汇总，废票汇总，综合汇总，财务汇总火车票预订时间表，检票员对账单等等。

系统还要提供综合查询功能：包括：汇总线路、站点、班线、班次等各类基础数据；统计运营数据，生成日报表、月报表和任意时段报表；以汇总表方式，显示转让票张数、售票总额以及购票状况。

2.4.2概念结构设计admin管理员、user用户、售票员实体：在该实体中，用户id为字段，拿来作为每一个用户的惟一标志，同时也作为登录系统的用户名使用；身分属性适于辨别用户的类别，1为普通用户，2为管理员，3为检票员；每位用户都有惟一的身分证号和电话号码。

route路线实体：在该实体中，路线id为字段，拿来作为每一条路线的惟一标志，另外还记录了该路线途径的每一站以及抵达该站的时刻。

train车次实体：在该实体中，车次id为字段，拿来作为每一个车次的惟一标志；不同车次的火车拥有自己的一等座人数、二等座人数和三等座人数；路线id作为该实体的主键与路线表相联系，该车次的一等座、二等座以及三等座的售价也通过对应路线的耗时和价钱参数估算下来。

船票实体：在该实体中，车次id和发车日期作为联合字段，车次id作为主键与车次表相关联；一等座、二等座以及三等座剩余人数分别记录了某一车次某一日期当日的不同船票类别的剩余人数。

用户订单实体：在该实体中，订单id作为键值，拿来作为每一份订单的惟一标志；对于每一份独立的订单，记录着用户订购某一张船票的所有信息：包括用户身分证号、购买车次id、车票类别（一等座、二等座和三等座）、该船票的售价、下单时间、起始站、终点站、出发时间、账单id以及是否发生退款行为（1为发生了订票2为未发生订票）；其中车次id作为该实体类别的字段与车次表相关联，可以对应到相关车次的详细信息。

bill用户帐单实体：在该实体中，帐单id作为字段，拿来作为每一份帐单的惟一标志；购票员id作为主键与用户表相关联，且该用户身分属性的值为3，代表着该帐单对应的某一个检票员；订单id作为主键与订单表相关联，适于记录该订单属于某一帐单，一份帐单可以对应到多份订单；因此该实体还包括应付总额和实付总额这两个属性，通过这两个属性可以估算出找零总额。

整体E-R图

2.4.3逻辑结构设计

实体转换为关系机制

用户信息（用户id，电话号码，密码，身分证号，真实姓名，用户类别，性别，注册日期）

路线信息（路线id，出发时间，抵达时间，出发站，目的站，后边站1，后边站2，后边站3，后边站4，后边站5，后边站6，后边站7，后边站8，抵达时间1，抵达时间2，抵达时间3，抵达时间4，抵达时间5，抵达时间6，抵达时间7，抵达时间8）

车次信息（车次id，路线id，一等座人数，二等座人数，三等座人数，一等票售价，二等票售价，三等票售价）

船票信息（车次id，发车日期，一等座剩余人数，二等座剩余人数，三等座剩余人数）

订单信息（订单id，用户身分证号，帐单id，车次id，船票类别，售价，下单时间，发车时间，出发地，目的地，是否订票）

帐单信息（帐单id，订单id，购票员id，实付总额，应付总额）

联系转换为关系机制

用户拥有订单（用户身分证号，订单编号）

订单拥有车次（订单编号，车次编号）

火车拥有路线信息（车次编号，路线编号）

帐单拥有订单（帐单编号，订单编号）

帐单对应购票员（帐单编号，购票员编号）

船票拥有车次（车次编号，发车日期）

实体与联系进行合并

User表设计如下：

Route表设计如下：

Train表设计如下：

表设计如下：

表设计如下：

Bill表设计如下：

2.5硬件框架与步骤

该大作业的硬件框架分为三层，为表现层、应用层与数据层。表现层主要功能为数据修饰及展示、获取用户信息、发送数据访问恳求；应用层主要功能为相应访问恳求、提供数据访问插口、嵌入式数据库编程、数据封装更改；数据层主要功能为数据库设计、数据初始化、储存、增删查改。工具箱为整个争创开发过程提供相应工具，以便开发进行。

程序步骤设置为从登录界面踏入，可以从登录界面中选择打开注册界面完成注册，还可以选择身分，完成登入操作，踏入用户界面、售票员界面以及管理员界面。其中管理员界面可以打开汇总界面，查看销售状况。对于用户界面、售票员界面以及管理员界面，都是采取访问应答的形式获取数据并完成数据整理展示到后端，而汇总界面，这是依据当晚的购票状况，获取相应数据并完成整理与展示。

2.6后端设计

管理员界面：分为三大版块，分别为标题区、功能选择区以及显示区，标题区会对硬件的信息和字体进行展示，并提供用户的基本信息；功能选择区将要对管理层的功能进行分类，并通过标签显示，由键盘单击来确定数据显示界面；显示区则是对前端数据传到后，对数据完成整理并进行展示。

购票员界面：分为三大版块，分别为标题区、售票区以及帐单递交区，标题区会对硬件的信息和字体进行展示，并提供购票员的基本信息；购票区可以由购票员键入目的站和终点站对符合条件的车次信息进行查找并显示；帐单递交区则是对购票员处理的一系列订单进行递交操作。

用户界面：该界面与检票员界面相同，分为三大版块，分别为标题区、售票区以及帐单递交区，标题区会对硬件的信息和字体进行展示，并提供购票员的基本信息；购票区可以由购票员键入目的站和终点站对符合条件的车次信息进行查找并显示；帐单递交区则是对购票员处理的一系列订单进行递交操作。

三、过程阐述

因为系统内容较大，所以在此介绍过程阐述的大体思路，必要时进行详细样例的说明。而更具体的内容会可以通过分工，详细查看每个成员的试验报告，上面包括了详细的代码实现方法。

3.1任务分工

后端

前端

3.2整体框架

设置为从登录界面踏入，可以从登录界面中选择打开注册界面完成注册，还可以选择身分，完成登入操作，踏入用户界面、售票员界面以及管理员界面。其中管理员界面可以打开汇总界面，查看销售状况。对于用户界面、售票员界面以及管理员界面，都是采取访问应答的形式获取数据并完成数据整理展示到后端，而汇总界面，这是依据当晚的购票状况，获取相应数据并完成整理与展示。

3.3后端开发

样例：此处列举车次信息查看窗口，该窗口由分栏器、搜索框以及信息展示三个组件进行构成。其中分栏器是直接通过ui生成代码，再通过编译器完成封装，直接使用的。对于搜索框与信息展示栏，我们通过ui生成后，进行父类封装，再承继父类内容，完成多态封装，在此产生符合列车信息查看的组件要求。再通过布局将各个组件组合上去。

3.4图表描绘

详细实现方式：

3.5前后端交互

需求功能实现方法：首先在ui界面中查看是否数据违法或填写信息不完全，再者应用层从数据层获取数据进行处理，再与后端数据比较或交互等操作，最后完成业务功能。

在此进行一个样例说明：在后端发送获取报表信息的恳求后，后端会对信息进行检测，假如正确会传到到前端中，通过服务层进行数据的估算处理与封装，最后传回给后端。或许在过程中使用了工具系列的其他方式，当发生错误时，将要对错误信息进行报错。

3.6应用层插口

应用功能实现方法：从数据层中获取对应数据，再者应用层从数据层获取数据进行处理，对数据进行估算统计与整理判定数据生成是否成功，进行相应的提示，并传输生成后的数据。

详细样例为：在统计前五名的购票员产量时，首先在数据层获取数据并进行相应的整理，在到应用层中处理数据，最后将数据返回，并提示对应信息

3.7数据库编程

数据库连结操作：此处使用了json文件进行配置，其中补充了关于数据库连结的各类信息，详细代码如下：

数据库的插口整体框架：首先会判定传到参数的正确性，例如宽度与违法字符等再者通过字符串条纹的形式，将mysql句子完成条纹，成后通过游标进行执行假如成功则复印提示信息，假如失败将要抛出异常，同时进行数据库的回滚操作。

四、成果展示（部份）4.1登入界面

登陆界面ui图

检测填入信息合法性

权限不足提示

4.2注册界面

注册ui截面图

检测填入信息合法性

注册成功告诫

注册失败告诫

显示按键实现

4.3车次信息展示界面（与其他信息展示界面基本一致）