公交卡管理信息系统

第一章系统规划

1.1系统开发背景

随着科学技术的不断发展，计算机科学日渐成熟，其强大的功能已为人们所深刻认识，它已进入人类社会的各个领域并发挥着越来越重要的作用。采用计算机进行信息化管理已成为现在管理方式的变革方向，而公交卡管理的全面自动化、信息化则也是其变革的方向之一。公交卡信息管理的好坏对公交车和乘客来说都至关重要，在很大程度上影响着人们的出行。因此，本文所研究的公交卡管理信息系统具有一定的使用价值和现实意义。

一直以来，人们乘坐公交都使用现金，售票员找零。到现在使用无人售票系统，在人们的零钞不够等原因的情况下，就逐渐开始了使用公交卡乘车的方法，但公交卡管理工作量大、容易混乱，另外时间一长，将产生大量的文件和数据，这对于查找、更新和维护都带来了不少的困难。鉴于此，本文研究了一种基于关系型数据库的公交卡信息管理方案。利用SQL SERVER 2005数据库管理系统灵活性和开发效率高的特点，开发出公交卡管理信息系统。该系统所具有的优点：检索迅速、查找方便、可靠性高、存储量大、保密性好、信息利用率高、成本低等。该系统能够极大地提高公交卡信息管理的效率，节省管理公交卡所需要的人力、物力，降低公交公司的管理费用，为公交卡信息管理的信息化、正规化奠定了坚实的基础。

1.2国内外现状

1.2.1国内现状分析

1.2.2国外现状分析

1.3系统开发目的

1.提高信息准确度；

2.改进管理和服务；

3.系统设计优良，界面设计精美、友好、快捷，人性化设计，后台管理功能强大、效率高；

4.更简便、信息化程度更高的公交卡管理流程。

1.4 项目开发计划

1.5 运行环境

1.硬件环境：CPU：1GHZ 以上 RAM：256M以上硬盘：2G以上

2.软件环境：

本文所采用的开发环境主要是基于数据库系统的SQL,利用SQL SERVER 2005创建公交卡注册信息表，充值表，挂失表，注销表，激活表以及连接数据库用的管理员信息表。利用特定的语言控件按钮以及一些程序代码实现一些特定的功能，例如：用户注册、充值、挂失、查询用户信息等，极大的提高了公交卡信息管理的效率。这些功能都可以在此文研究的系统中简单的实现，当然对于一些复杂的操作还要再仔细的考虑！

运行环境：Windows 8/Vista/win7/2000/2003

第二章系统分析

2.1可行性分析

2.1.1 技术可行性分析

2.1.2 经济可行性分析

2.1.3 社会可行性分析

2.2 需求分析

在公交卡管理系统中，管理员要为每个用户建立账户，并且录入用户信息，包括基本的姓名、性别、联系方式等，用户通过管理员注册后，会发放给用户一张公交卡，包括卡号和用户姓名和照片等基本信息。持有公交卡的用户，通过接触公交车上的刷卡机器，用户即可正常的乘坐公交车。当然，系统还提供强大的信息查询服务，查询可以通过多种方式实现，包括通过公交卡号查询和用户的身份证号码查询的方式。通过这些方式可以查询用户的基本信息和用户的充值消费情况。公交卡管理员通过该系统能够提供公交卡的挂失和注销服务，为丢失了公交卡的用户或者不愿再使用公交卡的用户提供更加优质的服务。具体功能如下: (1)公交IC卡办理:通过此功能，通过用户提供的信息，管理员录入

注册信息即可完成公交卡的注册，用户即可正常使用公交卡；(2)公交卡的充值：用户可以完成对公交卡的充值，可以继续使用公

交卡；

(3)公交卡的刷卡记录：用户每次刷卡后，可记录他的刷卡时间、金

额、卡号、余额、车号；

(4)公交卡的查询：对用户进行日、月、年的刷卡记录统计查询，从

而描绘出他的出行轨迹；

(5)公交卡挂失：挂失丢失的公交卡，冻结公交卡上的余额，让丢失

的公交卡不能再被其他人使用；

(6)公交卡的注销：如果用户要换卡或者不想继续使用公交卡可以通

过此卡办理注销；

第三章系统设计

3.1 总体设计

1.系统功能结构图

3.2 详细设计

3.2.1 输入设计

3.2.2 输出设计

数据库设计

4.2对数据模型进行优化

4.2.1优化后总的关系模型：

用户（用户编号，用户名，手机号码，用户身份证号，卡号,地址）

公交卡（卡号，卡类型，卡状态，余额，所属地）

充值表（流水号，机器号，业务名称）

刷卡记录表（流水号，卡号，卡类型，刷卡机号，刷卡金额，刷卡余额，刷卡时间）

注册单（消费编号，消费名称）

（卡编号，保证金，使用地点，使用时间，结束时间）

自行车（自行车编号，自行车存放地点）

充值（卡编号，支付编号，充值金额，充值时间）

支付方式（支付编号，支付名称）

挂失（卡编号，挂失时间，挂失地点）

激活（卡编号，激活时间）

注销（卡编号，用户编号，身份证，注销时间）

（1）用户（用户编号，用户姓名，手机号码，用户身份证号，卡号）

1. 该关系中，每个属性都是不可分的，所以该关系属于1NF。

2. 该关系中主码是(用户编号)，主属性有两个一个是用户编号，一个是用户身份证号, 所以存在非主属性对主码的部分函数依赖，不属于2NF。

3. 由需求可知用户编号可以决定卡号，所以存在非主属性对候选码的传递函数依赖并且不满足第二范式，不属于3NF。

4. 经过考虑，这样的关系模型并不会对产生数据冗余和增删改异常的情况，并且连接操作耗时，所以不将其继续规范化。

（2）公交卡（卡编号，卡类型，卡名称，折扣，卡状态，余额，业务编号） 1. 该关系中，每个属性都是不可分的，所以该关系属于1NF。 2. 该关系中主码是(卡编号)，是单属性,所以不存在非主属性对主码的部分函数依赖，已经属于2NF。 3.由需求可知卡编号可以决定业务名称，所以存在非主属性对候选码的传递函数依赖，不属于3NF。 4.由于以上关系已经存在属性对码的传递函数依赖，所以，不属于BCNF。

（4）充值（卡编号，支付编号，充值金额，充值时间） 1. 该关系中，每个属性都是不可分的，所以该关系属于1NF。 2. 该关系中主码是(卡编号)，是单属性,所以不存在非主属性对主码的部分函数依赖，已经属于2NF。 3. 该关系中不存在非主属性对候选码的传递函数依赖，属于3NF。 4. 由于以上关系已经不存在任何属性对码的传递函数依赖和部分依赖，所以，还属于 BCNF。

（6）挂失（卡编号，挂失时间，挂失地点） 1. 该关系中，每个属性都是不可分的，所以该关系属于1NF。 2. 该关系中主码是(卡编号)，是单属性,所以不