隨著交通運輸和經(jīng)濟的發(fā)展，越來越多的出行者需要考慮合理地選擇出行方案。通?？晒┏鲂姓哌x擇的出行方案比較多，如何為出行者快速提供到達目的地的可行性出行方案，是現(xiàn)今旅游、交通運輸?shù)刃袠I(yè)迫切需要解決的實際問題，同時也是學者研究的熱點和難點之一。為了解決交通出行問題，研究人員提出了出行路徑選擇模型與算法。出行選擇模型主要以換乘次數(shù)少與出行距離短為優(yōu)化目標，其目的是尋找一條路徑。因此出行路徑選擇模型中所涉及的多源交通數(shù)據(jù)量較大且關系復雜，目前多選擇利用關系數(shù)據(jù)庫存儲出行路徑選擇模型中所涉及的交通基礎數(shù)據(jù)。故對這些交通數(shù)據(jù)檢索并終確定的出行方案需要大量時間，而目前大多數(shù)的交通出行方案的查詢只是針對如飛機、火車或者汽車的這種單一的交通工具的點到點查詢。

　　數(shù)據(jù)庫（Database）是按照數(shù)據(jù)結構來組織、存儲和管理數(shù)據(jù)的倉庫，它產(chǎn)生于距今五十年前，隨著信息技術和市場的發(fā)展，特別是二十世紀九十年代以后，數(shù)據(jù)管理不再僅僅是存儲和管理數(shù)據(jù)，而轉變成用戶所需要的各種數(shù)據(jù)管理的方式。數(shù)據(jù)庫有很多種類型，從簡單的存儲有各種數(shù)據(jù)的表格到能夠進行海量數(shù)據(jù)存儲的大型數(shù)據(jù)庫系統(tǒng)都在各個方面得到了廣泛的應用。

　　1 路徑選擇模型

　　由于交通出行路徑查詢中涉及多源的交通數(shù)據(jù)較多，導致從出行者的起點到終點的出行方案很多。為了能夠快速準確查詢出可行的出行方案，本文采用了基于分層結構首尾協(xié)同的出行路徑模型來快速準確查詢可行的出行路線。該模型的基本思想就是同時從起點（S）和終點（T）查詢中轉站信息，直到找到匹配的可行方案。該模型的出行方案查詢策略如圖1所示。

　　該模型主要包括以下幾個部分：（1）選用SQL Server存儲的交通數(shù)據(jù)及該模型中所產(chǎn)生的中間數(shù)據(jù)；（2）同時從起點（S）和終點（T）查詢中轉站信息，然后再對中轉站信息進行匹配和查詢，直到找到可行出行方案；（3）比較給出可行出行方案。

　　該模型的具體描述如下：

　?。?）利用SQL Server建立包括交通信息表、臨時堆棧表、方案主表、方案子表和一些輔助臨時表等一系列的關系數(shù)據(jù)表。SQL（STructured Query Language），結構化查詢語言。SQL語言的主要功能就是同各種數(shù)據(jù)庫建立聯(lián)系，進行溝通。按照ANSI（美國國家標準協(xié)會）的規(guī)定，SQL被作為關系型數(shù)據(jù)庫管理系統(tǒng)的標準語言。SQL語句可以用來執(zhí)行各種各樣的操作，例如更新數(shù)據(jù)庫中的數(shù)據(jù)，從數(shù)據(jù)庫中提取數(shù)據(jù)等。絕大多數(shù)流行的關系型數(shù)據(jù)庫管理系統(tǒng)都采用了SQL語言標準。雖然很多數(shù)據(jù)庫都對SQL語句進行了再開發(fā)和擴展，但是包括Select, Insert, Update, Delete, Create,以及Drop在內(nèi)的標準的SQL命令仍然可以被用來完成幾乎所有的數(shù)據(jù)庫操作。

　?。?）從起點（S）開始向前查詢出所有經(jīng)過起點的交通信息集合。設這些信息集合為S1且層次為1;再以S1為起點向前查詢經(jīng)過S1的所有交通信息集合（不含同種交通工具的重復信息），設這些信息集合為S2且層次為2;則第i次搜索形成信息集合為Si且層次為i;經(jīng)過若干次搜索后可將以起點為出發(fā)點以終點為目的的整個交通數(shù)據(jù)搜索完畢。

　　（3）從終點（T）開始向后查詢出所有經(jīng)過終點的交通信息集合。設這些信息集合為T1且層次為1;再以T1為起點向前查詢出經(jīng)過T1的所有交通信息集合，設這些信息為T2且層次為2,則第j次搜索形成信息集合為Tj且層次為j,經(jīng)過若干次搜索后可將以終點為出發(fā)點以起點為目的的整個交通數(shù)據(jù)搜索完畢。

　?。?）比較Si中任意中轉站集中任意和Tj中相同的中轉站，找到從起點到終點的出行可行方案?；诜謱咏Y構首尾協(xié)同的兩次以內(nèi)中轉出行路徑查詢算法的流程圖如圖2所示。

　　由圖1可以得出如表1所示的直達、和二次轉車出行條件。

　　2 算法實現(xiàn)

　　基于SQL Server的存儲平臺，設計了包含交通信息表（表2）、臨時堆棧表（表3）、方案主表、方案子表和一些輔助臨時表等用來存儲路徑選擇過程中所涉及的數(shù)據(jù)。其中交通信息表格用來存儲交通基礎信息，該表中包括車次/航班號、站點序號以及站點編號等字段。臨時堆棧表用來將每次查詢出的車次信息按層次保存。SQL Server 是一個關系數(shù)據(jù)庫管理系統(tǒng)。它初是由Microsoft、 Sybase 和AshtON-Tate三家公司共同開發(fā)的，于1988 年推出了個OS/2 版本。在Windows NT 推出后，Microsoft與Sybase 在SQL Server 的開發(fā)上就分道揚鑣了，Microsoft 將SQL Server 移植到Windows NT系統(tǒng)上，專注于開發(fā)推廣SQL Server 的Windows NT 版本。Sybase 則較專注于SQL Server在UNIX 操作系統(tǒng)上的應用。方案主表是方案子表明細的匯總，具體字段見表4.

　　3 應用與結果分析

　　首先，根據(jù)圖2和表1確定中轉車次數(shù)少的方案，根據(jù)方案查詢出相應的信息，并將信息保存到臨時堆棧表中（為解決同城多個站點中轉問題，中轉時使用地點編號作為中轉條件）；然后，生成可行的出行方案并保存到臨時結果子表中；，對臨時結果子表進行匯總并將結果保存到臨時結果主表中。

　　3.1 臨時堆棧表數(shù)據(jù)查詢

　　臨時堆棧表的數(shù)據(jù)是分層的，其S1和S2層是從起點查詢的，T1和T2層是從終點查詢的。其對應的表關聯(lián)如下：

　　層：

　　T_TRAFFIC_INFO T1,T_TRAFFIC_INFO T2 Where

　　T2.F_NB_STATION_ID=（S） AND T1.F_VC_TRAIN_NO=

　　T2.F_VC_TRAIN_NO AND T1.F_NB_SEQ_NO>T2.F_NB_SEQ_NO

　　第二層：

　　T_TRAFFIC_INFO T1,#T_STACK T2,T_TRAFFIC_INFO T3 WHERE

　　T2.F_NB_LAY=1 And T2.F_NB_LOCATION_ID=

　　T3.F_NB_LOCATION_ID And T1.F_VC_TRAIN_NO

　　!=T2.F_VC_TRAIN_NO And T1.F_VC_TRAIN_NO=

　　T3.F_VC_TRAIN_NO And T1.F_NB_SEQ_NO>T3.F_NB_SEQ_NO

　　第三層：

　　T_TRAFFIC_INFO T1,#T_STACK T2,T_TRAFFIC_INFO T3 WHERE T2.F_NB_LAY=4 And T2.F_NB_LOCATION_ID=

　　T3.F_NB_LOCATION_ID And T1.F_VC_TRAIN_NO=T3.F_VC_TRAIN_NO And T1.F_NB_SEQ_NO<T3.F_NB_

　　SEQ_NO And T1.F_VC_TRAIN_NO!=T2.F_VC_TRAIN_NO

　　第四層：

　　T_TRAFFIC_INFO T1,T_TRAFFIC_INFO T2 Where

　　T2.F_NB_STATION_ID=（T） AND T1.F_VC_TRAIN_NO=

　　T2.F_VC_TRAIN_NO AND T1.F_NB_SEQ_NO<T2.F_NB_SEQ_NO

　　3.2 臨時結果子表查詢

　　在臨時堆棧表數(shù)據(jù)的基礎上，根據(jù)表1所對應中轉類型的條件可直接獲得此中轉類型的所有方案數(shù)；再將具體的方案信息保存到臨時結果表中（先保存到子表中，主表信息可根據(jù)子表的方案號進行匯總得到）。

　　3.3 結果分析

　　將起點、終點及其他參數(shù)作為存儲過程的入口參數(shù)，通過參數(shù)便可獲得相應出行方案信息，同時可根據(jù)策略對這些方案進行排序，從而獲得出行者所需要的方案。

　　本文討論了一種基于分層結構首尾協(xié)同的出行路徑選擇模型，通過對中轉信息進行快速檢索，并對相應信息判斷是否匹配，以便找出相對優(yōu)化的出行路徑。但該算法僅適合起點（S）與終點（T）中都是有若干條線路途徑的地點。