公交卡管理系统

1、精选优质文档-倾情为你奉上公交卡管理系统1.引言公交交通是城市基础事业的重要组成部分，与城市经济、文化发展和广大市民的生活息息相关，随着城市人口的增多，人流量增加，为了减少堵车，保护环境，国家制定相应的政策，人民积极相应，乘车公交车拥挤的现象也随之产生，为了解决这一现象，就需要建立一个良好的公交管理系统，一方面，加快上车速度，减少站点停车时间，增加人们的出行效率；另一方面，帮助公交车公司管理客流量和货币，减少人工开支。公交卡管理信息系统主要解决一些公交卡的信息管理的问题，设计开发公交卡管理系统，一是实现公交卡一般功能的注册、充值、挂失、激活和注销功能，二是随着经济的逐步发展，完善公交卡功能，相

2、应出现的新功能如电子钱包，异地刷卡，自行车的租借功能，对用户支持用户信息的修改，网上支付充值等功能，操作员密码的修改和一些简单的查询功能。 在课程设计中，系统开发平台为Win7，数据库采用SQL Server 2008，程序运行平台为Win7。程序通过调试运行，初步实现了设计目标，并且经过适当完善后，将可以应用在公交管理部门的管理中，解决实际问题。2.需求分析2.1调查与初步分析在编写需求前，我们根据各个公交公司的公交卡占有率和使用情况和市场上对公交卡管理系统的相应的功能需要情况进行相应的调查和分析，首先是对各大网上公交卡管理系统进行了调查，其中包括：公交卡管理系统的界面设计、公交业务流程、公

3、交卡相应功能以及管理员的操作，这几大块进行了调查。结合当时的经济环境和市场需求，合并我们的调查和分析，总结出一套并属于自己特色的设计思路。用户分析：公交卡的使用者主要有以下几种：管理人员：公交卡管理系统的操作者和记录者，公交卡管理系统主要分为：注册管理系统、充值管理系统、注销管理系统、挂失管理系统、激活管理系统、电子钱包管理系统、异地刷卡管理系统、异地刷卡管理系统，而公交卡的记录者主要是管理注册、充值、注销、挂失几个一般活动，而公交卡管理系统的操作者主要是对公交卡管理系统的主要操作者，需要对数据库的操作有一定的要求。系统维护人员：计算机专业人员，熟悉数据库、操作系统、网络维护工作。维护人员为间

4、隔性用户。 公交卡持有者：公交卡管理系统的客户端使用者和持卡人，他们是公交卡管理系统的使用者，不是管理者，不能对管理系统进行更改工作。通过调查，公交卡管理系统需要做到以下几个特点：（1）提高信息准确度；（2）改进管理和服务； （3）系统设计优良，界面设计精美、友好、快捷，人性化设计，后台管理功能强大、效率高；  （4）更简便、信息化程度更高的公交卡管理流程。经过调查：建立公交卡管理系统的信息要求和持卡人的所有信息，以及持卡人在使用公交卡时或消费公交卡过程中公司内部所产生的信息情况。处理要求：系统管理者通过已有信息可以完成对持卡人、注册、充值、注销、激活、

5、使用电子钱包消费、异地刷卡、自行车功能进行管理。系统维护要求：对系统的随时间产生缺陷的功能进行维护和更新。2.2分析和表达需求2.2.1划分系统将系统按部门划分为若干子系统（视图），得到最顶层的数据流图。图2.1 公交卡管理系统最顶层数据流图2.2.2公交卡管理子系统数据流图由于公交卡管理子系统的业务流程比较复杂,所以在进行数据流程分析时,采用了”自顶向下”的分析方法,也就是结构化分析方法,具体做法是第一步: 确定顶层数据流图顶层数据流图概括了公交卡电子钱包管理子管理系统的总功能、主要的输入流、主要的输出流和主要的数据存储。图2.2 公交卡管理子系统注册管理系统数据流图图2.3 公交卡管理子系

6、统充值管理系统数据流图图2.4 公交卡管理子系统挂失管理系统数据流图图2.5 公交卡管理子系统激活管理系统数据流图图2.6 公交卡管理子系统注销管理系统数据流图图2.7 公交卡管理子系统电子钱包管理系统数据流图图2.8 公交卡管理子自行车管理系统数据流图顶层数据流图概括了公交卡管理子管理系统的总功能、主要的输入流、主要的输出流和主要的数据存储。2.2.3数据字典1 数据项（数据项描述=数据项名，数据类型）用户编号=用户编号，数值型用户姓名=用户姓名, 字符型身份号=身份号，数值型公交卡编号=卡编号, 数值型公交卡类型编号=卡类型编号, 数值型消费编号=消费编号，数值型消费名称=消费名称, 字符

7、型支付编号=支付编号，数值型2 数据结构（数据结构描述=数据结构名，含义说明，组成）用户信息=用户编号，用户姓名，用户电话，用户身份号，用户地址，备注公交卡信息=公交卡编号，公交卡类型，公交卡名称，公交卡状态，公交卡余额，备注电子钱包业务信息=公交卡编号，消费名称，消费金额，余额，消费时间，备注自行车业务信息=公交卡编号,押金,使用状态,使用时间,结束时间，备注3 数据流（数据流描述=数据流名，说明，数据流来源，数据流去向）用户信息，填写注册登记表时的信息，用户，用户信息表充值数据，用户使用现金或网上充值的信息，用户，公交卡充值信息表挂失数据，用户挂失时的信息，用户，公交卡挂失表激活，用户取消

8、挂失的状态的信息，用户，公交卡激活表注销，用户填写注销登记的信息，用户，用户注销情况表使用电子钱包，用户使用电子钱包消费的信息，用户，电子钱包信息表使用自行车业务，用户租借自行车的信息，用户，自行车业务情况表4 数据存储（数据存储描述=数据存储名，说明，编号，输入的数据流，输出的数据流，组成）用户信息=用户信息，填写注册登记表时的信息，用户编号，用户信息，组成：用户信息充值数据=金额，充值金额，公交卡编号，金额，组成：充值数据挂失数据=卡状态，公交卡丢失的信息，公交卡编号，状态，组成：挂失数据激活数据=卡状态，公交卡拥有的信息，公交卡编号，状态，组成：激活数据电子钱包使用数据=消费名称，使用电

9、子钱包支付金额，公交卡编号，消费金额，组成：电子钱包使用数据自行车使用数据=使用时间，使用自行车的信息，公交卡编号，时间，组成：自行车使用数据 5 处理过程（处理过程描述=处理过程名，输入：数据流，输出：数据流，处理的简要说明）用户注册，输入：注册登记表，输出：批准的用户信息，用户持有公交卡充值，输入：支付金额，输出：用户余额，为用户充值挂失，输入：挂失数据，输出：挂失状态，暂停用户卡内活动激活，输入：用户信息，输出：公交卡状态，开启公交卡的业务活动注销，输入：用户信息，输出：批准用户信息，删除用户信息电子钱包消费，输入：消费名称，输出：余额，扣除电子钱包金额使用自行车，输入：使用时间，输出：

10、结束时间，统计时间时间3.概念结构设计3.1设计各个子系统（视图）的分E-R图选择中层数据流图中的公交卡管理子系统中七个公交卡管理子系统数据流图作为设计分E-R图的依据；根据数据流图逐一设计分E-R图，确定局部应用中的实体、实体的属性、码、实体之间的联系及其类型。注册管理系统、充值管理系统、挂失管理系统、激活管理系统、注销管理系统、电子钱包管理系统、自行车管理系统是公交卡管理系统的七个子系统，通过分析七个子系统的需求分析的结果，我们可以知道该子系统需要描述的实体有：用户，公交卡，公交卡业务，金额，充值、挂失、激活、注销、电子钱包业务、自行车业务等。对于每一个用户的公交卡都有多个卡的业务与之对应

11、，同时，多张卡又与多种卡类细节对应。还有其他实体与实体之间的联系，一一写出后可以得到以下关于七个公交卡管理子系统的概念结构即E-R模型。1） 选择中层数据流图作为设计分E-R图的依据；图3.1 公交卡管理系统中注册管理系统的E-R图图3.2 公交卡管理系统中充值管理系统的E-R图图3.3 公交卡管理系统中挂失管理系统的E-R图图3.4 公交卡管理系统中激活管理系统的E-R图图3.5 公交卡管理系统中注销管理系统的E-R图图3.6 公交卡管理系统中电子钱包管理系统的E-R图图3.7 公交卡管理系统中自行车管理系统的E-R图将七部分的E-R图合并得到公交卡管理系统的E-R图图3. 8 公交卡管理系

12、统E-R图属性：用户用户编号 ，用户姓名，手机号码，用户地址，用户身份证号，卡号公交卡卡号，卡编号，支付编号，办理编号，金额公交卡类型卡编号，卡类型编号，卡类型办理方式办理编号，办理方式支付方式支付编号，支付名称消费方式消费编号 ，消费名称折扣规则卡类，金额，折扣充值卡编号，支付编号，充值金额，充值时间挂失卡编号，挂失时间，公交卡状态，挂失地点激活卡编号，激活时间，公交卡状态注销卡编号，用户编号，身份证，注销时间电子钱包卡编号，消费编号，消费地点，消费时间，消费金额，余额自行车业务卡编号，保证金，使用地点，使用时间，结束时间自行车自行车编号，自行车存放地点3.2 概念结构验证检查概念结构是否具

13、有一致性(内部无矛盾)、准确性(能准确反映原来的视图结构，包括实体、属性、联系)并满足需求分析的要求(支持所需处理的实现)。若存在问题则作进一步的修改，直到满足要求为止。4.逻辑结构设计公交卡管理系统的关系模型如下：用户（用户编号 ，用户姓名，手机号码，用户身份证号，卡号）公交卡（卡编号，卡类型，卡名称，卡状态，余额）其他业务（卡编号，业务编号，业务名称）折扣规则（卡类， 金额， 折扣）电子钱包（卡编号，消费编号，消费地点，消费时间，消费金额，余额）消费内容（消费编号，消费名称）自行车（卡编号，保证金，使用地点，使用时间，结束时间）充值（卡编号，支付编号，充值金额，充值时间）挂失（卡编号，挂失

14、时间，公交卡状态，挂失地点）激活（卡编号，激活时间，公交卡状态）注销（卡编号，用户编号，身份证，注销时间）电子钱包（卡编号，消费编号，消费地点，消费时间，消费金额，余额）自行车业务（卡编号，保证金，使用地点，使用时间，结束时间）自行车（自行车编号，自行车存放地点）4.2对数据模型进行优化4.2.1优化后总的关系模型：用户（用户编号 ，用户姓名，手机号码，用户身份证号，卡号）公交卡（卡编号，卡类型，卡名称，折扣，卡状态，余额，业务编号）其他业务（卡编号，业务编号，业务名称）电子钱包（卡编号，消费编号，消费地点，消费时间，消费金额，余额）消费内容（消费编号，消费名称）自行车业务（卡编号，保证金，使

15、用地点，使用时间，结束时间）自行车（自行车编号，自行车存放地点）充值（卡编号，支付编号，充值金额，充值时间）支付方式（支付编号，支付名称）挂失（卡编号，挂失时间，挂失地点）激活（卡编号，激活时间）注销（卡编号，用户编号，身份证，注销时间）4.2.2对会员管理子系统部分关系模型的优化：（1）用户（用户编号 ，用户姓名，手机号码，用户身份证号，卡号）1. 该关系中，每个属性都是不可分的，所以该关系属于1NF。2. 该关系中主码是(用户编号)，主属性有两个一个是用户编号，一个是用户身份证号,所以存在非主属性对主码的部分函数依赖，不属于2NF。3. 由需求可知用户编号可以决定卡号，所以存在非主属性对候

16、选码的传递函数依赖并且不满足第二范式，不属于3NF。4. 经过考虑，这样的关系模型并不会对产生数据冗余和增删改异常的情况，并且连接操作耗时，所以不将其继续规范化。（2）公交卡（卡编号，卡类型，卡名称，折扣，卡状态，余额，业务编号）1. 该关系中，每个属性都是不可分的，所以该关系属于1NF。2. 该关系中主码是(卡编号)，是单属性,所以不存在非主属性对主码的部分函数依赖，已经属于2NF。3. 由需求可知卡编号可以决定业务名称，所以存在非主属性对候选码的传递函数依赖，不属于3NF。4.由于以上关系已经存在属性对码的传递函数依赖，所以，不属于BCNF。（3）电子钱包（卡编号，消费编号，消费地点，消费

17、时间，消费金额，余额）1. 该关系中，每个属性都是不可分的，所以该关系属于1NF。2. 该关系中主码是(卡编号)，是单属性,所以不存在非主属性对主码的部分函数依赖，已经属于2NF。3. 该关系中存在卡编号决定消费名称，存在非主属性对候选码的传递函数依赖，不属于3NF。4. 经过考虑，这样的关系模型并不会对产生数据冗余和增删改异常的情况，并且连接操作耗时，所以不将其继续规范化。（4）充值（卡编号，支付编号，充值金额，充值时间）1. 该关系中，每个属性都是不可分的，所以该关系属于1NF。2. 该关系中主码是(卡编号)，是单属性,所以不存在非主属性对主码的部分函数依赖，已经属于2NF。3. 该关系中

18、不存在非主属性对候选码的传递函数依赖，属于3NF。4. 由于以上关系已经不存在任何属性对码的传递函数依赖和部分依赖，所以，还属于BCNF。（5）自行车（卡编号，保证金，使用地点，使用时间，结束时间）1. 该关系中，每个属性都是不可分的，所以该关系属于1NF。2. 该关系中主码是(卡编号)，主码是单属性,所以存在非主属性对主码的部分函数依赖，已经属于2NF。3. 该关系中不存在非主属性对候选码的传递函数依赖，属于3NF。4. 由于以上关系已经不存在任何属性对码的传递函数依赖和部分依赖，所以，还属于BCNF。（6）挂失（卡编号，挂失时间，挂失地点）1. 该关系中，每个属性都是不可分的，所以该关系属

19、于1NF。2. 该关系中主码是(卡编号)，是单属性,所以不存在非主属性对主码的部分函数依赖已经属于2NF。3. 由于卡编号可以决定挂失时间，所以存在非主属性对候选码的传递函数依赖，不属于3NF。4. 经过考虑，这样的关系模型并不会对产生数据冗余和增删改异常的情况，并且连接操作耗时，所以不将其继续规范化。（7）激活（卡编号，激活时间）1. 该关系中，每个属性都是不可分的，所以该关系属于1NF。2. 该关系中主码是(卡编号)，是单属性,所以不存在非主属性对主码的部分函数依赖，已经属于2NF。3. 由于卡编号可以决定激活时间，所以存在非主属性对候选码的传递函数依赖，不属于3NF。4. 经过考虑，这样的关系模型并不会对产生数据冗余和增删改异常的情况，并且连接操作耗时，所以不将其继续规范化。（8）注销（卡编号，用户编号，身份证，注销时间）1. 该关系中，每个属性都是不可分的，所以该关系属于1NF。2. 该关系中主码是(卡编号)，