【文章內容簡介】 和修改公告信息、查看所有用戶的部分信息。綜上所述，系統(tǒng)功能流程圖如下：圖31 系統(tǒng)功能模塊圖 數(shù)據(jù)庫需求分析數(shù)據(jù)庫在一個網(wǎng)站、系統(tǒng)中占據(jù)著絕對重要的角色，數(shù)據(jù)庫設計的好壞將直接影響著該網(wǎng)站或系統(tǒng)的順利運行，因此要做好一個網(wǎng)站或系統(tǒng)，首選要設計好數(shù)據(jù)庫。數(shù)據(jù)庫設計時主要分為需求分析、概念結構設計、邏輯結構設計、物理結構設計、驗證設計和運行與維護設計，最終得到一個完整的數(shù)據(jù)庫。數(shù)據(jù)庫需求分析將從用戶和管理員兩個角度分析該系統(tǒng)需要哪些表、表之間有哪些聯(lián)系、表中有哪些數(shù)據(jù)及其數(shù)據(jù)類型、需要哪些視圖，即獲得用戶和管理員對信息的要求、處理要求及安全性與完整性要求。信息要求：指系統(tǒng)用戶需要從數(shù)據(jù)庫中獲得信息的內容和性質，由信息要求可以導出數(shù)據(jù)要求，即在數(shù)據(jù)庫中需要存儲哪些數(shù)據(jù)；處理要求：指系統(tǒng)用戶要完成什么處理功能，對處理的響應時間又什么要求，處理方式是批處理還是聯(lián)機處理。 信息要求用戶（前臺）：用戶需要從數(shù)據(jù)庫讀取或存入的數(shù)據(jù)包括路線信息數(shù)據(jù)、車次信息數(shù)據(jù)、站點信息數(shù)據(jù)、公告信息數(shù)據(jù)、天氣信息數(shù)據(jù)、留言信息數(shù)據(jù)、個人信息數(shù)據(jù)等。路線信息數(shù)據(jù)：用戶所查詢站到站的所有路線按所需時間、換乘次數(shù)或所需費用排序的路線號、車次、經過的站點、所需總時間、所需總費用、中轉站等。車次信息數(shù)據(jù)：用戶所查詢車次的首班時間、末班時間、目前運行狀態(tài)、運行區(qū)間、經過的站點、次序、時間、票價、發(fā)車間隔時間等。站點信息數(shù)據(jù)：包含用戶所輸入數(shù)據(jù)的所有站點的信息，經過這些站點的車次的信息。公告信息數(shù)據(jù)：公告的標題、時間、內容等。天氣信息數(shù)據(jù)：日期、星期、氣候、風況、最高氣溫、最低氣溫、空氣質量等。留言信息數(shù)據(jù)：留言人、留言標題、留言內容、留言時間、回復人、回復內容、回復時間等；個人信息數(shù)據(jù)：個人ID、用戶名、登錄密碼等。管理員（后臺）：路線、車次、站點、公告、留言、天氣、所有用戶及個人信息等數(shù)據(jù)。 處理要求用戶（前臺）：對路線、車次、站點的查詢操作處理，其中對路線進行按時間、換乘次數(shù)或者費用排序的處理；登錄、免費注冊、修改個人用戶名、修改密碼操作處理；查看所有留言、查看與某人相關留言、查看與自己相關留言、發(fā)表留言操作處理；查看公告信息及天氣信息操作處理。管理員（后臺）：對路線、車次、站點、公告、天氣信息的增刪改查操作處理；登錄、查看個人信息、修改密碼操作處理；查看所有留言、回復留言操作處理；查看所有用戶的部分信息操作處理。 性能需求分析 為了保證系統(tǒng)能夠安全、長久、順利、高效的運行，城市公交查詢系統(tǒng)應該滿足以下的性能需求： 系統(tǒng)的及時性 系統(tǒng)對于公交車次、路線、站點、公告等信息應及時反應，首先是管理員對數(shù)據(jù)庫中的數(shù)據(jù)及時進行添加、刪除和修改操作，其次是系統(tǒng)從數(shù)據(jù)庫獲取更新數(shù)據(jù)的及時性，只有這樣，才能保證用戶得到及時的、正確的信息以及時調整自己的行程。 系統(tǒng)的準確性 城市公交查詢系統(tǒng)是一個正規(guī)的、城市公交公司管理的、被乘客信任的系統(tǒng)，若系統(tǒng)中有不正確、過期的信息將會影響乘客的行程、甚至是直接利益，所以，城市公交查詢系統(tǒng)一定得保證其數(shù)據(jù)的正確性。要保證系統(tǒng)數(shù)據(jù)的正確性，首選管理員一定得及時有效的更新數(shù)據(jù)庫信息，保證數(shù)據(jù)的正確性，其次是系統(tǒng)必須要及時獲取數(shù)據(jù)庫中的更新數(shù)據(jù)，所以系統(tǒng)的響應速度要求要快。 系統(tǒng)的易用性 決定一個系統(tǒng)的優(yōu)劣，功能的完整性是一個要素，另一個要素是系統(tǒng)的易用性。城市公交查詢系統(tǒng)作為一個實用性的系統(tǒng)，其易用性非常重要。對于使用某系統(tǒng)的用戶來說，能簡單的在該系統(tǒng)找到想要的信息、想要操作的功能才是一個實用的系統(tǒng)，當然系統(tǒng)的外觀也會增加用戶使用欲望。第4章 系統(tǒng)概要設計第4章 系統(tǒng)概要設計概要設計是指將用戶需求轉化為數(shù)據(jù)結構和軟件的系統(tǒng)結構，數(shù)據(jù)結構設計即數(shù)據(jù)庫設計，將用戶的信息需求轉化為數(shù)據(jù)庫中的表結構設計；軟件的系統(tǒng)結構即功能模塊設計，將用戶的處理需求轉化為對系統(tǒng)的功能模塊設計。下面就系統(tǒng)功能模塊設計和數(shù)據(jù)庫設計詳細介紹。 概述系統(tǒng)概要設計是將系統(tǒng)需求分析階段所分析的用戶的信息要求和處理要求抽象化為對系統(tǒng)數(shù)據(jù)庫的設計和對系統(tǒng)的功能設計。功能模塊設計是將一個復雜的系統(tǒng)按功能進行模塊劃分，建立模塊的層次結構及調用關系，確定模塊間的接口及人機交互界面等。數(shù)據(jù)庫設計包括設計數(shù)據(jù)庫中的表及表結構，系統(tǒng)要用到的用戶子模式（即視圖）等。在系統(tǒng)概要設計階段中，最終要確定系統(tǒng)的功能和數(shù)據(jù)庫的表及表結構。 功能模塊我將系統(tǒng)功能分為兩塊：前臺用戶功能和后臺管理員功能。 前臺用戶前臺功能是用戶可以實現(xiàn)的功能，主要包括登錄注冊、修改密碼、修改個人信息、路線查詢、車次查詢、站點查詢、公告信息查看、天氣信息查看和留言板；詳細描述：路線查詢：用戶輸入始發(fā)站和終點站，可以直達的為公交直達，給出時間；不能直達的可分為換乘最少、費用最少和時間最少，以供用戶選擇；換乘最少：按換乘次數(shù)排序，若換乘次數(shù)相等，則按所需時間排序；若所需時間也相等，則再按所需費用排序；費用最少：按所需總費用排序，若所需總費用相等，則按所需時間排序；若所需總時間也相等，則再按所需換乘次數(shù)排序；時間最少：按所需總時間拍排序，若時間相等，則按所需換乘次數(shù)排序，若換乘次數(shù)也相等，則再按所需費用排序。車次查詢：用戶輸入要查詢的車次，系統(tǒng)給出用戶查詢的公交所經過的站點及始發(fā)站到各站點所需時間、費用及公交的大略定位，用戶也可以通過鏈接查到所經過的各站點的詳細信息；站點查詢：用戶輸入要查詢的站點，系統(tǒng)給出經過該用戶所查詢的站點及含有該站名的車次，用戶也可以通過鏈接查到這些車次的詳細信息；用戶登錄、注冊、修改信息：若用戶擁有系統(tǒng)賬號就可以在留言板上發(fā)表和回復留言；系統(tǒng)為用戶提供登錄、免費注冊、修改密碼、修改個人信息功能；說明：未登錄用戶可以查看所有留言，但是不能回復和發(fā)表留言；留言板：用戶有疑問或不知道的可以在留言板上留言；公交公告信息：用戶可以查看所有公告信息；天氣信息：用戶可以在首頁查看當天及未來一周的天氣信息，包括日期、星期、氣候、風況、最高氣溫、最低氣溫和空氣質量。綜上所述，系統(tǒng)用戶的功能模塊圖如下：圖41 用戶功能模塊圖 后臺管理員介紹再詳細一點綜上所述，管理員的功能模塊圖如下：圖42 管理員功能模塊圖 數(shù)據(jù)庫設計數(shù)據(jù)庫設計是根據(jù)用戶的需求，在數(shù)據(jù)庫管理系統(tǒng)（在此我用的是MySql）上設計數(shù)據(jù)庫的結構和數(shù)據(jù)庫的過程。由于設計數(shù)據(jù)庫是一個非常復雜的過程，不可能一蹴而就，在設計過程中會不斷的、反復的修改、求精，所以下面將從數(shù)據(jù)庫的概念結構設計、邏輯結構設計和物理結構設計三個階段詳述數(shù)據(jù)庫設計。 數(shù)據(jù)庫概念結構設計在設計數(shù)據(jù)庫的初始階段要用數(shù)據(jù)模型來表現(xiàn)數(shù)據(jù)庫的結構與語義以實現(xiàn)對現(xiàn)實世界進行抽象。目前廣泛使用的數(shù)據(jù)模型分為兩種：獨立于計算機系統(tǒng)的“概念數(shù)據(jù)模型”和“結構數(shù)據(jù)模型”，在本次系統(tǒng)設計與實現(xiàn)中我將采用概念數(shù)據(jù)模型中的“實體聯(lián)系模型（ER模型）”來描述數(shù)據(jù)庫的結構和含義以對現(xiàn)實世界進行抽象。ER模型是用ER圖來表示數(shù)據(jù)模型的方法，它直接從現(xiàn)實世界抽象出實體類型及實體間聯(lián)系，它的優(yōu)點有：接近人的思維，容易理解；與計算機無關，用戶容易接受。 實體和屬性的定義如下：管理員表：登錄ID、用戶名和密碼；站點表：編號和站名；車次表：編號、車次、服務類型、車輛類型、運行區(qū)間、首班發(fā)車時間、末班發(fā)車時間、發(fā)車間隔時間；線路表：編號、車次、站點、次序、時間、票價、方向。用戶表：用戶賬號、用戶名、登錄密碼、用戶頭像。留言表：留言編號、用戶名、標題、留言人、留言內容、留言時間、狀態(tài)。回復表：回復編號、留言編號、回復人、回復內容、回復時間。天氣信息表：日期、氣候、風況、最高氣溫、最低氣溫和空氣質量。公告信息表：公告ID、公告標題、公告內容、公告時間。系統(tǒng)總ER圖如下：圖43 系統(tǒng)總ER圖 數(shù)據(jù)庫邏輯結構設計邏輯結構設計的任務就是把概念結構設計階段設計好的基本ER圖轉換為與選用DBMS（Database Management System，數(shù)據(jù)庫管理系統(tǒng)）產品所支持的數(shù)據(jù)模型相符合的邏輯結構。邏輯結構設計一般分為三個步驟進行：將概念結構轉換為一般的關系、網(wǎng)狀、層次模型；將轉換來的關系、網(wǎng)狀、層次模型向特定的DBMS支持下的數(shù)據(jù)模型轉換；對數(shù)據(jù)模型進行優(yōu)化。將概念結構設計中得到的ER圖轉換為關系模型，如下文所示（下劃線表示主碼）：管理員（登錄ID，用戶名，密碼）；列名數(shù)據(jù)類型長度約束條件是否為主鍵loginIDvarchar50非空是managerNamevarchar50唯一否loginPasswordvarchar50非空否表 41 管理員信息表站點（編號，站名）；列名數(shù)據(jù)類型長度約束條件是否為主鍵station_IDint20非空是station_namevarchar50非空、唯一否表 42 站點信息表車次（編號，車次，服務類型，車輛類型，運行區(qū)間，首班發(fā)車時間，末班發(fā)車時間，發(fā)車間隔時間）；列名類型長度約束條件是否為主鍵car_IDint20非空是car_namevarchar50唯一、非空否serviceTypevarchar50自動or人工否carTypevarchar20K、G or S否drivingRangevarchar50無否firstTimetime無否lastTimetime無否jiange_timeint20無否表 43 車次信息表線路（編號，車次，站點，次序，時間，票價，方向）；列名類型長度約束條件是否為主鍵route_IDint20非空是car_namevarchar50非空否station_namevarchar50非空否route_orderint20非空否drivingTimetime非空否priceint20非空否directionvarchar20非空否表 44 路線信息表用戶（用戶賬號，用戶名，登錄密碼，用戶頭像）；列名類型長度約束條件是否為主鍵users_IDvarchar20非空是users_namevarchar100唯一否user_passwordvarchar50非空否users_photoint200無否apply_timedatetime無否表45 用戶信息表留言（留言編號，用戶名，標題，留言人，留言內容，留言時間，狀態(tài)）；列名類型長度約束條件是否為主鍵ment_IDint20非空是users_namevarchar100非空否ment_titlevarchar100無否ment_contentvarchar200非空否ment_statevarchar50未回復or 已回復否ment_timedatetime非空否表 46 留言信息表回復（回復編號，留言編號，回復人，回復內容，回復時間）；列名類型長度約束條件是否為主鍵reply_IDint20非空是ment_IDint20非空否reply_namevarchar50非空否reply_contentvarchar200非空否reply_timedatetime非空