由於資料收集的來源多元，資料形式與內容不一，造成在系統開法時將先面 對的是處理各種差異性資料的問題，而在以往的研究中大多將此步驟忽略或是草 率處理，若沒辦法將資料處理妥當，日後在系統開發或應用時將產生開發上的問 題，例如功能開發時無法彈性新增修改，或是無法取出所要的資料，若是無法自 動化的處理資料，當面對龐大的資料量湧入時，靠人工處理將花上大筆時間與人 力，且較難維持系統營運的穩定性。
尤其是現今透過網際網路公開化的資料日益增多，如機器端傳回的資料經由 轉換過後成大量的格式化資料，或是各種資料庫軟體的格式，故如何妥善且自動 化地處理大量資料，篩選出系統所需要的資料，將是本研究探討的重點。
首先將定義VD 資料與 GPS 資料之資料結構，並探討其資料特性與內容，
以作為資料處理的準備，接續探討正規化的步驟與定義，制定出資料處理的方法 與程序，並建立在相同時間間隔的基準點上，進行即時資料融合程序，建立兩者 資料的關聯性，形成關聯式資料庫。
2.2.1 資料來源與資料結構
在處理資料之前必須先瞭解資料的結構，包括資料的特性、內容、記載項目、
頻率與資料中出現特殊代號的意義等，而在制定ER Model 時已經將資料的實體 與屬性記載清楚，在這裡要釐清的將是資料本身賦予的意義與內涵，對於系統應 用上的關連性與限制等，所以在此將討論VD 資料與 GPS 資料的資料結構，作 為資料處理與資料融合程序的準備。
和以往研究所不同的是，本研究所取得的VD 資料是屬於格式化後的 XML 資料，並非直接由車輛偵測器之機器端傳回的資料，故在本研究中並不探討電腦 化交通號誌控制系統通訊協定中的資料格式，而是探討純粹的XML 格式。而計
程車GPS 資料是屬於資料庫的格式，並非單純的（National Marine Electronics Association, NMEA）格式，如 NMEA-0180、0182、0183，而是關聯式資料庫
（Relational Database, RDB）。故在本研究中，VD 資料是採 XML 格式，GPS 資 料採關聯式資料庫之格式來進行研究的探討。
2.2.1.1 台北市交通控制中心 VD 資料結構
本研究中所探討的車輛偵測器資料，是由台北市交通控制中心所提供，透過 網際網路的方式放置在「台北市交通控制中心之資料交換中心」網站上開放給使 用者使用，並沒有連線權限上的限制，在資料格式上是屬於XML 格式，在網頁 上同時一次提供台北市交通控制中心所裝設之所有車輛偵測器的即時交通資 料，若是與以往車輛偵測器直接接收的資料格式來看有相當大的不同，XML 提 供的是一個標準化、精簡化的資料格式，伺服器同一時間更新網頁上所有車輛偵 測器的資料，所以從XML 所擷取的資料之時間點視為相同。
在資料內容上，為車輛偵測器傳回之應有的資料，其中包括資料來源、時間、
路段編號、路段名稱、平均車速、平均佔有率、旅行時間與車流總量。
在資料範圍上，車輛偵測器散佈在台北市當中，故地理區域範圍在台北市區 的範圍以內。
在資料更新時間上，「台北市交通控制中心之資料交換中心」網站約五分鐘 更新一次網頁，所以資料更新頻率是五分鐘更新一次。
在資料數量上，台北市交通控制中心總共有提供119 個車輛偵測器之 VD 資 料，假設每五分鐘會更新一次，每一天一個車輛偵測器會有288 筆資料，一天全 部119 個車輛偵測器共有 34272 筆資料。
台北市交通控制中心之資料交換中心之網頁所提供之資料如圖2.5 所示。
圖2.5 台北市交通控制中心資料交換中心之 VD_XML 資料 2.2.1.2 計程車 GPS 資料結構
本研究中所探討之計程車GPS 資料，係由衛星派遣計程車中心所提供之非 公開資料，屬於有權限的資料，無法公開自由取得，透過資料庫與資料庫的連結 來取得資料，故資料格式是資料庫的形式，衛星派遣中心所使用的資料庫為 Oracle Database，它與實際由 GPS 所傳回的資料有些許不同，一般 GPS 傳回的 是字串格式，每次只有一筆資料，而本研究所取得的是衛星派遣計程車中心的車 隊所有GPS 資料，所以在資料格式上與資料數量上明顯與一般 GPS 有所不同。
在資料內容上，包括車輛編號、事件編號、時間、X 座標、Y 座標、任務編 號。車輛編號為計程車的編號，而時間為資料存取的時間，X 座標為東經座標，
Y 座標為北緯座標，而任務編號是當此計程車的客人為計程車中心所派遣的任務 時，將會產生一個編號，作為派遣時所用。
在事件編號的部份，此欄位所要記載的是車輛事件的狀態，其中的事件狀態
包括有開錶、閉錶、執行中心任務、啟動引擎、熄火、跨格等六種事件狀態，將
在資料數量上，目前衛星派遣計程車車隊共有約1300 台的計程車，由於沒 有固定的資料更新頻率，所以沒有固定的資料量，但是經由本研究統計一天約有 150000 筆資料。
衛星派遣計程車之GPS 資料之資料庫原始資料，如圖 2.6 所示。
圖2.6 計程車 GPS 資料之資料庫畫面
2.2.2 資料處理程序（Data Process）
由於研究的資料量龐大，VD 資料一天有 34272 筆資料，計程車 GPS 資料一 天有150000 筆資料，故資料處理程序要透過系統來協助自動化且穩定地進行。
為了要篩選出需要的資料，必須透過資料處理程序，包括資料擷取、資料轉換、
資料清理、資料載入等這些步驟，將遠端的資料透過擷取後，經由轉換與清理的 規則程序處理後，載入資料庫當中，成為可用的資料。故此節中將針對資料結構，
進行正規化的步驟，配合研究的需求，制定資料處理程序的步驟與規則，篩選出 研究所要的資料。
2.2.2.1 資料正規化（Normalization）
資料庫的目的就是儲存資料，而且前提是要能夠自由取出資料，本研究認為 這是資料庫最重要的一個特性，同時目前資訊科技變動萬千，資料來源與格式豐 富多元，又經常發生系統需求不斷地改變的情況。所以在架構系統之前，在上一 節已經介紹過的資料結構，基於系統穩定、開發富有彈性的考量下，資料要盡量 的安定，便可以設計出自由度高的系統，而要達到這種理想的方法，就是透過資 料結構的正規化，使用正規化後的資料結構來儲存資料，資料取出的自由度就會 提高，也比較能彈性的增加系統功能。
正規化的目的，重點就是要將資料的重複性降到最低，也就是減少資料重複 的意思，而本研究的資料結構透過正規化的步驟讓資料的重複性降到最低，讓系 統的穩定性提高，系統開發保有彈性。根據正規化的定義（E. F. Codd, 1970），
在本研究中的VD 資料與 GPS 資料，兩者分別都進行到「第三正規化」的步驟，
也就是包含了第一正規化、第二正規化與第三正規化的條件，其條件如表2.2 所 示，透過正規化將實體的意義具體化，系統開發更明瞭。
表2.2 正規化的條件列表 正規化 條件
第一正
規化 欄位中沒有重複項目
第二正 規化
滿足第一正規化條件，並且所有的非識別鍵從屬於識別 鍵
第三正 規化
滿足第二正規化條件，並且所有的非識別鍵互為獨立存 在
2.2.2.2 資料處理程序
本研究的資料結構透過ER Model 的制定以及資料正規化處理後，將針對資 料來源進行資料處理程序，將資料過濾成可用的資料，而資料處理的程序按照順 序為資料擷取（Data Extraction）、資料轉換（Data Transformation）、資料清理（Data Cleaning）、資料載入（Data Load），而資料處理程序流程如圖 2.7 所示。
圖2.7 資料處理程序流程圖
1.資料擷取
資料擷取的步驟，首先確定資料更新的頻率與資料內容，透過網際網路的方 式連線遠端的伺服器或資料庫，將即時資料擷取。
2.資料轉換
此時系統將判斷是否為新的資料，若是新的資料，則存取資料，若非新的資 料，則不存取資料。將資料丟入制定好的ER Model 當中，並建立好資料庫的 DB Schema，則可以將 VD 之 XML 資料轉換為 Microsoft SQL Server 的資料，而 計程車GPS 之 Oracle 資料轉換為 Microsoft SQL Server 的資料，產生新的資料庫。
3.資料清理
依照制定好的DB Schema，將資料不吻合者刪除，留下吻合的資料。
就VD 資料而言，依照 DB Schema 將內容與長度不吻合者、不該空白的欄 位空白者全部都予以刪除。
就計程車資料而言，依照DB Schema 將內容與長度不吻合、不該空白的刪 除外，其次是檢查時間欄位VEHEVNTIME 中資料是否完整，完整的資料必須為
「西元年/月/日 上(下)午 時/分/秒」，更重要的是挑選出營業中的行駛資料。
而營業中的資料挑選條件，第一種是從事件編號欄位VEHEVNID 中選擇有 資料開頭有開錶訊息（事件編號為3233）與資料結尾有閉錶訊息（事件編號為 3234），而兩者間的訊息就是營業中的資料，如圖 2.8 所示。
圖2.8 計程車營業中資料-開錶與閉錶
第二種是從備註欄位VEHJOBNO 中選擇非空白欄位的資料，由於備註欄是 紀錄由衛星派遣中心所派遣任務的任務編碼，所以當此備註欄有文字時，代表此 資料為計程車正在執行派遣的任務，故屬於營業中的資料，如圖2.9 所示。
圖2.9 計程車營業中資料-備註欄有文字
依照上述說明將VD 資料與 GPS 資料作資料清理程序，清除不符合規定的 資料，留下所需要的資料，而資料清理程序之流程圖如圖2.10 所示。
4.資料載入
依照資料轉換、資料清理的步驟後，將處理完成的資料載入資料庫當中。
圖2.10 資料清理流程圖