路局站別應卸車系統的數據庫設計

陳小紅，陳曉東

（1.西安鐵路職業技術學院，助教，陜西 西安 710014；2.西安鐵路局新豐鎮車站，助理工程師，陜西 西安 710608）

路局站別應卸車計劃的編制在貨運工作計劃的編制中占有重要地位〔1〕。目前，該計劃的編制仍停留在手工編制的水平，效率低，工作量大。采用計算機編制路局站別應卸車系統可以極大地減少工作強度，提高數據的精確性，而數據庫的設計在路局站別應卸車系統（簡稱應卸車系統）的設計中占有重要的地位。為此，重點對應卸車系統開發過程中數據庫部分的設計環節進行討論。

1 需求分析

在計算機應用系統中，數據庫是管理信息系統（MIS）的核心，它的性能與管理是涉及MIS各方面的全局性問題，是保證MIS高效運行及安全的關鍵。數據庫的設計要充分考慮應用系統的功能，而應用系統的功能又決定于用戶各個方面的需求，包括現有的以及將來可能增加的需求。為此，下面分別進行分析。

人工編制路局站別應卸車計劃，主要是根據運貨4上的數據來完成當日18：00在站的管內工作車、次日自裝管內工作車及其有效車數、次日局（地區）間分界站接入的管內工作車及其有效車數等3部分卸車資源的推算。如果通過計算機來實現編制，應卸車系統應滿足用戶如下需求：

1）能夠對卸車資源的基礎數據進行系統錄入，存入數據庫。

2）根據站標準停留時間，標準接續時間及列車到站、發站時間推算接續車。

3）能對現有管重、自裝卸及接入管重卸車資源中有效車及整個卸車資源的推算。

4）能夠對基本數據進行查詢、刪除、修改、插入及命令的下達等操作。

5）方便用戶對于系統的維護。

為了滿足用戶的上述需求，應卸車系統應有3部分功能：

1）數據輸入功能。主要包括：①多個卸車資源基礎數據的輸入，主要包括預確報數據（當日15：00車流、各站間轉運車、列車掛運車、次日鄰局預報資源）的導入、轉運車以及用戶基礎數據的輸入等。②在站標準停留時間及標準接續時間的輸入。③列車到站、發站時間的輸入。

2）數據處理功能。主要包括：①根據站標準停留時間，標準接續時間及列車到站、發站時間推算接續車。②現有管重、自裝卸及接入管重卸車資源中有效車的推算。

3）數據輸出功能。主要包括：①現有管重、自裝卸及接入管重卸車資源中有效車的輸出。②現有管重、自裝卸及接入管重卸車資源（有效車和無效車之和）的輸出。③接續車的輸出。

另外，由于路局站別應卸車計劃涉及的站點、分界站、中間站等數據特別多，所以數據庫僅根據假設的路網結構進行設計，以簡化設計難度。在假定的路網結構中，全路有R，S，T，U等4個鐵路局，A站和F站分別為S局與R局、T局的分界站，T局和U局在G站分界。如圖1所示。

基于上述分析，采用PB開發工具和SQL2005數據庫系統，分別對數據庫系統進行概念設計、邏輯設計和物理設計。

2 數據庫概念設計

2.1 數據庫總體概念設計概念結構設計就是將用戶需求抽象為概念結構模型的過程。概念結構設計是整個數據庫設計的關鍵，它通過對用戶需求進行綜合、歸納與抽象，形成一個獨立于具體數據庫管理系統（Database Management System，簡稱 DBMS）的概念模型〔3〕。

從需求分析中的應卸車系統輸入、處理、輸出3部分功能可知，該系統數據庫中應包括如下實體：

1）基礎數據實體。包括當日15：00車流確報資源、各站間轉運車預報資源、列車掛運車預報資源、次日鄰局預報資源、鄰局預報數據自預測資源（這是由于次日鄰局預報資源的不準確性，采用鄰局預報數據自預測資源來提高次日局間分界站接入的管內工作車的精確性）。這些基礎實體中的數據需要用戶進行手工輸入或導入。

2）推算條件實體。包括站標準停留及接續時間、列車到發時間和接續車次。用來判斷18：00在途管內工作車、次日自裝管內工作車、臨局接入管重的工作車是否有效，臨站作業車是否已裝好。推算條件實體中的數據是實現次日應卸車有效車的關鍵，也需要用戶輸入。

3）輸出實體。包括現有管重資源、現有管重無效資源、自裝卸及接入管重資源、自裝卸及接入管重無效資源、總數據輸出資源，這些實體用來存放對前2部分實體數據進行推算處理后得到的數據。

4）用戶實體。即用戶信息資源，用來進行用戶的登錄和驗證。

2.2 數據庫具體概念設計由于應卸車系統數據庫涉及的實體眾多，且基礎數據實體和輸出實體的數據結構基本一致，下文只給出具有代表性的數據設計實體及其屬性。

1）當日15：00車流確報資源。用來存儲當日15：00～18：00間管內各站已有車及輸送車流情況，其實體屬性：站或列車編號、站a、站b、站c、站d、站E、站o、站P、站q、站r、站F、合計。屬性1表示某站或某列車15：00具有車流確報資源，屬性“站a”表示該站或列車到站a的15：00車流確報數。合計一列用來存儲某站所具有的總15：00車流確報數。

2）站標準停留時間及接續時間。在次日站別卸車計劃資源的推算過程中，多次用到標準站停及接續時間表。其實體屬性包括站編號、站標準停留時間、站標準作業時間及標準接續時間。

3）列車到發時間。列車到發時間全面反映了列車在運行圖上的準確到站、離站時間。為卸車資源有效性推算提供了重要的依據，其實體屬性包括：列車編號、站編號以及站的到達和開出時間。

4）接續車次。在次日站別卸車資源的推算過程中，有一部分車次需要在技術站中轉，在中轉時有效性推算需根據接續時間表和接續車次表。接續車次表主要包括列車編號、站編號和接續列車編號。

5）現有管重資源。現有管重資源全面反映了次日在站管內工作車和18：00在途管內工作車的資源。根據運貨4，現有管重資源為在站管內工作車和在途管內工作車之和。其實體屬性：站或列車編號、站a、站b、站c、站d、站E、站o、站P、站q、站r、站F、合計。屬性1表示某站或某列車具有現有管重資源，屬性“站a”表示該站或列車到站a的現有管重工作車數。合計一列用來存儲某站或某列車所具有的現有管重總和。

3 數據庫邏輯設計

3.1 數據庫總體邏輯設計邏輯結構設計是將概念結構模型轉換成某個DBMS所支持的數據模型，并對其進行優化。設計主要分為2個步驟進行：

1）繪制從概念結構設計出來的各實體的E—R圖（實體—聯系圖），并對其進行合并優化。

2）將優化后的E—R圖按關系模式轉換原則轉換成關系。雖然基礎數據各實體轉換成關系后具有相同的碼，但在該數據庫中并未對其進行合并。因為，一是表示的數據含義不一樣；二是合并后屬性列名之間有重復還需重新命名；三是不利于數據處理部分的操作。同理，數據輸出部分的實體也是轉換成各自的關系，不對其合并，方便用戶操作和輸出。

3.2 數據庫具體邏輯設計通過數據庫的總體邏輯設計得知，應卸車系統數據庫總共具有14個關系模型。考慮到很多實體結構一致，在這里只給出概念結構設計中提到的實體轉換成的邏輯模型，其中有下劃線者為關鍵碼。

1）當日15：00車流確報資源表：站或列車編號、站a、站b、站c、站d、站E、站o、站P、站q、站r、站F、合計。

2）站標準停留時間及接續時間：站編號、站標準停留時間、站標準作業時間、標準接續時間。

3）列車到發時間：列車編號、站編號、站到達時間、站開出時間。

4）接續車次：列車編號、站編號和接續列車編號。其中站編號為外鍵，與站標準停留時間及接續時間表相聯系。

5）現有管重資源：站或列車編號、站a、站b、站c、站d、站E、站o、站P、站q、站r、站F、合計。

4 數據庫物理設計

數據庫的物理設計是根據數據庫邏輯設計的結果，研制一個有效的、可實現的物理數據庫結構及存儲結構。該數據庫采用SQL 2005數據庫管理模式，主要是對上述關系的存儲結構進行設計，包括對各屬性的數據類型、長度、是否為空，是否為主鍵及相應備注信息進行設計。在這里主要對現有管重資源表、站標準時間及接續時間表、列車到發時間表及接續車次表的物理設計進行闡述，其他不再累述。

4.1 現有管重資源表現有管重資源關系表物理設計要求：

1）因為站或列車編號能唯一標識某一條記錄，所以將其定義為主鍵。根據站及列車的實際編號長度，將其類型定義為varchar（變長字符串），最大長度為10，根據關系的范式要求其值不能為空。

2）屬性“站a”至“站F”存儲具體到該站的現有管重車數，將其數據類型定義為smallint（短整型），長度為5，根據關系的范式要求其值可為空。

3）最后一列屬性“合計”存儲某站現有管重車數之和，因數值比較大，將其定義為int（整型），其值可為空。

4.2 站標準時間及接續時間表站標準時間及接續時間關系表物理設計要求：

1）因為站編號能唯一標識某一條記錄，所以將其定義為主鍵，并與現有管重資源表保持一致。將其類型定義為varchar（可變字符串），長度為10，其值不能為空。

2）屬性列站標準停留時間、站標準作業時間和標準接續時間在系統中以min為單位，定義為varchar（變長字符串），最大長度為4，其值可為空。

4.3 列車到發時間表列車到發時間關系表物理設計要求：

1）列車到發時間關系為多對多的關系，因為列車編號和站編號的組合能唯一標識某一條記錄，所以將列車編號和站編號定義為主鍵。將列車編號和站編號類型定義為varchar（可變字符串），長度為10，其值不能為空。

2）站到達時間和在站開出時間根據其實際含義定義為datetime（日期型），將格式設置為“yyyymmdd”，占用8字節，其值可為空。

4.4 接續車次表接續車次關系表物理設計要求：

1）因為列車編號能唯一標識某一條記錄，所以將其定義為主鍵，與前表保持一致。數據類型設置為varchar型，長度為10，其值不能為空。

2）站編號為外鍵， 通過它和站標準停留時間及接續時間關系表相關聯，站編號的其它設置與列車編號設置一致。

3）接續列車編號不是主鍵，其值可為空。

5 結束語

應卸車系統數據庫通過相應的邏輯步驟進行概念設計、邏輯設計及物理設計，能很好地為路局站別應卸車系統服務。它能完整地反映卸車資源各種信息之間的聯系，有效地進行數據存儲，數據存儲和讀取的速度較快，對現實生產中應卸車計劃系統的設計有很好的借鑒作用。當然，如果對數據庫的訪問權限進行有針對性的設計，數據庫會更完善。

〔1〕齊 斌.鐵路局日班卸車計劃的計算機編制〔J〕.鐵道運營技術，2007，13（1）：36-37.

〔2〕宋建業，謝金寶.鐵路運輸調度指揮與統計分析〔M〕.北京：中國鐵道出版社，1993.

〔3〕施威銘.SQL Server 2005中文版設計實務〔M〕.北京：機械工業出版社，2006.