图3 一次换乘算法示意图
图4 二次换乘算法示意图 二次换乘的算法设计 二次换乘采用上下矩阵算法，现有A,B两个公交站，先通过数据库查询语句和程序业务逻辑得到A站能直达的所有站点，放在集合Collection1中，再按照A站的方法找出B站能知道的所有站点，放在集合Collection2中，再判断是否有公交车可以从Collection1中的站点直达Collection2中的站点，如果，则将方案存放到结果集合中。至此为止，根据公交线路设计的理论，是肯定可以找到二次换乘的方案的，故不再考虑3次换乘方案。 二次换乘算法，如图4所示。 手机公交查询数据库的设计 数据库的逻辑设计
图5 数据库主要E-R图 准确了解与分析用户需求（包括数据与处理）是整个设计过程的基础。而根据用户需求设计合适的数据库以及选择恰当的数据库以确保系统能高速稳定的运行则是数据库设计的根本目地。 由于本系统涉及到大量数据的读取，并且对安全性要求不高，故选用占用系统资源较少并且速度相对较快的MySQL作为本系统的数据库。 通过对用户需求的分析以及对系统本身应用背景的研究，可以看出本系统需要有以下数据支持：公交线路信息，公交站点信息，站点附近标志信息，用户通知信息，同时考虑到节约系统资源，在用户进行完站站查询后还会产生一个存放查询结果的缓存信息。由上述可以确认该算法所关系到的数据表。 根据上述分析，可以得出公交信息模型的E-R图，如图5所示。 公交信息相关数据库的数据字典，如表1所示。 表1 公交信息相关的数据字典 序 号 数 据 项 名 称 数 据 项 内 容 1. 公交线路信息 公交线路的信息汇总 1.1 线路ID 公交线路的ID 1.2 线路NO 公交线路的名称，如502A 1.3 经过站点 公交线路经过的站点 1.4 收发车时间 公交车的收发车时间 1.5 是否上下行 判断该公交车是否有上下行 2. 公交站点信息 公交站点相关信息 2.1 公交站名 该站点的站名 2.2 附近标志1 附近标志1的名字 2.3 附近标志2 附近标志2的名字 2.4 附近标志3 附近标志3的名字 2.5 附近标志4 附近标志4的名字 2.6 附近标志5 附近标志5的名字 2.7 附近标志6 附近标志6的名字 2.8 附近标志7 附近标志7的名字 2.9 附近标志8 附近标志8的名字 2.10 附近标志9 附近标志9的名字 2.11 附近标志10 附近标志10的名字 3. 站点附近标志汇总 站点附近标志性建筑物或者地名的汇总 3.1 标志ID 标志编号 3.2 标志名称 站点附近标志性建筑物或者地段的名称
数据库的物理设计 （1）公交线路信息表 负责存放公交线路信息，考虑到部分公交车存在上行和下行不一致的情况，表中添加了是否上下行的字段，以供算法确认。如表2所示。 表2公交线路信息表 公交线路信息表(businfo) 字段名 注释 Busid 公交车的id Busno 公交车的车号 stop1 第1个站的站名 stop2 第2个站的站名 …… …… …… …… stop50 第50个站的站名 Time 公交车的发车收车时间 Startend 公交车的起点和终点 Updown 是否有上下行
（2） 站点信息表 负责存放站点相关信息，并且存放一定的周围标志建筑和地名的信息，以供算法进行模糊查询。如表3所示。 表3站点信息表 &nbs
首页 上一页 1 2 3 4 5 6 7 下一页 尾页 3/10/10
