手机公交查询系统的设计
手机公交查询系统算法的设计
直达的算法设计
现有A,B两个公交站，通过数据库查询语句“select * from businfo” 获得全部公交线路信息，再把每一路车的信息依次迭代出来，判断A站和B站是否同时在该线路中，如结果为true，则可以直达，同时将直达方案存入一个集合中，继续向下遍历，如果结果为false,则该车不能直达，继续向下遍历。
一次换乘的算法设计
一次换乘采用基于站点优先级和邻接矩阵的公交换乘算法，现在A,B两个公交站，通过数据库查询语句查找出经过A站的所有公交车集合Collection1,再通过数据库查询语句查找出经过B站的所有公交车集合Collection2,判断Collection1和Collection2是否有交集，若有，则得到一次换乘方案，存放在结果集合中。判断结束后，再按照经过站点总数对换乘方案进行排序，因为换乘结果往往数以百计，所以只取结果集的前N条记录展现给用户。若判断结束后没有找到一次换乘的方案，则执行2次换乘算法。
一次换乘算法，如图3所示。
图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