公交查詢系統(tǒng)的設計與實現(xiàn)

1、 公交查詢系統(tǒng)的設 計與實現(xiàn)班級：12物聯(lián)網(wǎng)工程學號：1201141057姓名：鄭秀成日期：2014年12月15日 引言隨著因特網(wǎng)發(fā)展的日新月異，人們利用網(wǎng)絡實現(xiàn)資源共享以及協(xié)同工作越來越成為時代的潮流，使用各種網(wǎng)上的軟件方便生活，已經(jīng)成為了一個不可扭轉的趨勢。以此設計題目為目的，選擇鄭州市作為實踐對象，以鄭州市公交系統(tǒng)為基礎，再利用所學知識，熟練運用開發(fā)工具后，開發(fā)一個鄭州市手機公交線路查詢軟件，并且盡可能將其開發(fā)為一個方便大眾使用的公交線路查詢軟件。而且在當今公交出行線路多數(shù)是通過PC機查詢獲得的，但是假想一下在公交出行線路走到一半的時候計劃有所變化，公交出行線路需要有所調整，那么如何能夠

2、動態(tài)掌握線路信息顯得尤為重要，而且將來對生活的滿意度也不僅僅是百姓致富安居樂業(yè)就足以，而是逐漸趨向于一個更人性化的服務。城市交通服務以及附屬的一些服務一直都在不斷的隨著社會的進步而進步，這些服務從最開始的直接人力服務轉向技術型服務，如電話詢問，路牌等，然而這些服務總是有比較大的局限性，即縱然你知道了這條路該怎么走，下條路線該通到哪卻不知，于是開發(fā)這個手機公交線路查詢軟件，可在手機上隨時隨地對公交線路進行查詢，對用戶將要出行的路線了如指掌，這對用戶來說可以省去很多麻煩，節(jié)省不少時間。本次畢業(yè)設計結合鄭州市公交線路系統(tǒng)開發(fā)一個鄭州公交線路手機查詢軟件,服務于大眾。 目錄第一章 需求分析與概要設計1

3、1.1 可行性分析11.2需求分析1系統(tǒng)功能需求21.2.2 服務器端需求分析21.2.3 客戶端需求分析31.2.4 開發(fā)環(huán)境及工具需求分析41.3 概要設計41.3.1 開發(fā)流程41.3.2 系統(tǒng)數(shù)據(jù)流圖51.3.3 系統(tǒng)整體結構說明61.3.4 系統(tǒng)功能模塊的劃分7第二章 模式設計102.1 C/S模式簡介102.2 B/S模式簡介102.3 B/S-C/S模式112.3.1 B/S-C/S模式定義112.3.2 B/S-C/S模式特點12第三章 數(shù)據(jù)庫設計133.1 數(shù)據(jù)庫結構133.2 服務器數(shù)據(jù)庫設計：133.3 客戶端數(shù)據(jù)庫設計：173.3.1 SQLite簡介173.

4、3.2 數(shù)據(jù)庫設計18第四章 系統(tǒng)測試204.1系統(tǒng)測試方案204.2 性能分析20總結21第1章 需求分析與概要設計1.1 可行性分析可行性分析是對系統(tǒng)進行全面、概要的分析。它的任務是確定項目開發(fā)時是否必要和可行。它的主要目標是：進一步明確系統(tǒng)的目標、規(guī)模和功能，對系統(tǒng)開發(fā)背景、必要性和意義進行調查分析，并且提出系統(tǒng)的邏輯模型和各種可能的方案，從而為系統(tǒng)開發(fā)項目的決策提供科學依據(jù)。主要從三個方面進行研究：（1）技術可行性：以現(xiàn)有技術進行系統(tǒng)開發(fā)及系統(tǒng)實施，是完全可行的。首先，從自身來分析，經(jīng)過2年多的學習已經(jīng)初步掌握了JSP控件、SQL數(shù)據(jù)庫等方面的編程技巧，對該軟件的設計并不存在

5、技術上的難點。第二方面，在設計這個系統(tǒng)之前，我進行了一系列先期調研，查閱了有關使用JSP進行數(shù)據(jù)庫開發(fā)方面的論著、教材和論文，更多是利用網(wǎng)絡的便利條件，從網(wǎng)上查閱了北京、上海、廣州、昆明等大型城市的公交查詢系統(tǒng)，并認真地對其進行了分析研究，由于時間緊,任務重，我沒有更多的時間來開發(fā)完整的系統(tǒng)，所以就以查詢作為這個系統(tǒng)的核心。其次，從數(shù)據(jù)庫方面來分析，也是可行的。系統(tǒng)所建立的數(shù)據(jù)庫表中包含有五個字段：bus_number,bus_station1, bus_station2, bus_station3, bus_station4。bus_number用來存放車次，bus_station1, bu

6、s_station2, bus_station3, bus_station4這四個字段用來存放站點。（2）經(jīng)濟可行性：從這方面來說，本系統(tǒng)的開發(fā)作為課題來說不需要什么經(jīng)濟投入，因此來說也是可行的。（3）營運可行性:國內很早就開始應用公交查詢系統(tǒng)，我國大部分城市都有公交查詢系統(tǒng)。那么從這方面來說是可行的。1.2需求分析手機公交線路查詢軟件最基本的功能是能夠有效的為用戶提供查詢服務，在最短的時間內給用戶一條或多條到達目標地的路徑。整個查詢過程中，只有數(shù)據(jù)信息是依靠服務器同步獲取，其余功能均在手機端完成。在此分別對手機公交線路查詢軟件的服務器端和客戶端做需求分析。系統(tǒng)功能需求 本系統(tǒng)的用戶包括用戶和

7、管理員兩類，其中管理人員對此系統(tǒng)進行數(shù)據(jù)的修改、刪除、查找、添加路線以及發(fā)布公交動態(tài)等功能。而用戶則可運用本系統(tǒng)合理有效的查詢路線、安排行程。功能規(guī)劃：本系統(tǒng)有兩大功能：查詢功能以及更新維護功能。其中查詢功能包括站站查詢功能、車次查詢功能、公交站點車次查詢三項基本功能。功能描述：a.站站查詢：乘客通過輸入起點和終點的站名，那么通過這兩個車站的所有車次就會顯示出來供乘客選擇合適的乘車路線b.車次查詢：乘客通過輸入公交車車次就可以查詢出該車次經(jīng)過的所有站點，乘客可以根據(jù)站點來選擇自己的乘車路線c.公交站點車次查詢：這種方案一般針對不城市公交不熟悉的人，通過輸入站點或者車次就可以同時顯示站點和車次兩

8、種信息，根據(jù)這個就可以選出最佳的乘車方案。d.更新維護：管理員負責對公交路線修改和更新，以及系統(tǒng)的維護，同時公布最新的變動信息（包括車次變動和價格變動等）或者有關城市公交的新聞對性能的一般性規(guī)定：1靈活性：當要對系統(tǒng)進行添加數(shù)據(jù)或刪除、更新等操作時，可以容易地對系統(tǒng)進行操作，并且不影響系統(tǒng)的正常運行，更不會有任何出錯的現(xiàn)象。2數(shù)據(jù)精確:因為此數(shù)據(jù)為系統(tǒng)內部數(shù)據(jù),所以要求不能有誤差。3時間特性:系統(tǒng)應有即時性,能盡快查詢出所需結果1.2.2 服務器端需求分析服務器作為后臺，需要專業(yè)人員對服務器操作和維護，一般情況可由非專業(yè)人員借助管理軟件對服務器進行常規(guī)維護。服務器可以通過數(shù)據(jù)庫同步，為客戶端數(shù)

9、據(jù)庫提供數(shù)據(jù)。通過仔細分析服務器需求之后，服務器端要完成以下功能：1、服務器后臺管理功能服務器后臺管理是針對數(shù)據(jù)庫進行操作，具有增、刪、改、查功能。2、數(shù)據(jù)同步功能。采用Servlet技術，響應客戶端請求，返回給客戶端一端數(shù)據(jù)流，該數(shù)據(jù)流按照Xml語言規(guī)范寫入數(shù)據(jù)流。服務器端功能模塊劃分如圖1.1.1所示。圖 服務器端功能模塊圖1.2.3 客戶端需求分析客戶端主要是手機，用戶無法通過手機對本地數(shù)據(jù)庫進行操作，也無法對服務器數(shù)據(jù)庫操作，管理員可以通過手機瀏覽器登錄到服務器管理員頁面對數(shù)據(jù)庫進行操作，可以使用一些功能。該軟件應滿足若干要求，比如能夠隨時掌握公交信息，動態(tài)更新最新數(shù)據(jù)等。也要考慮作為

10、手機軟件可能會出現(xiàn)查詢速度慢，數(shù)據(jù)流量過大，過度依賴服務器等問題。通過仔細分析用戶需求之后，該軟件要完成以下功能：1、查詢線路功能獲得線路經(jīng)過的每個站點信息以及線路的票價信息和發(fā)車時間信息。2、地圖查詢功能借助GoogleMap，完成公交查詢并顯示地圖線路。3、數(shù)據(jù)更新功能服務器響應客戶端請求返回一段數(shù)據(jù)流，客戶端接收此數(shù)據(jù)流后，按照Xml語言規(guī)范對數(shù)據(jù)流進行解析，解析后將數(shù)據(jù)存入客戶端數(shù)據(jù)庫。4、意見反饋功能通過手機郵件將意見發(fā)送到管理員的郵箱。 客戶端功能模塊劃分如圖1.1.2所示。圖1.2.2 客戶端功能模塊圖1.2.4 開發(fā)環(huán)境及工具需求分析服務器端開發(fā)環(huán)境，以windows7操作系統(tǒng)

11、為開發(fā)平臺，用Tomcat6.0做為服務器，Mysql5.0作為數(shù)據(jù)源，JSP作為開發(fā)工具，Dreamweaver8.0作為輔助開發(fā)工具，運行在一般的PC機上即可。客戶端開發(fā)環(huán)境，以Android手機操作系統(tǒng)為開發(fā)平臺，用Android手機操作系統(tǒng)自帶的SQLite作為數(shù)據(jù)源。Java語言和Xml語言作為開發(fā)工具，Eclipse3.5作為輔助開發(fā)工具。整個Android手機操作系統(tǒng)是在Android SDK提供的虛擬機中運行，該虛擬機運行在windows7操作系統(tǒng)上，所以客戶端的開發(fā)是在windows7操作系統(tǒng)上運行的Android操作系統(tǒng)中進行的二次開發(fā)。1.3 概要設計1.3.1 開發(fā)流程

12、開發(fā)流程如圖1.3.1所示。運行測試調試程序編寫程序確定功能調查研究優(yōu)化完善圖1.3.1 開發(fā)流程圖1.3.2 系統(tǒng)數(shù)據(jù)流圖系統(tǒng)數(shù)據(jù)流程如圖1.3.2所示。圖1.3.2 系統(tǒng)數(shù)據(jù)流圖1.3.3 系統(tǒng)整體結構說明該系統(tǒng)包括前臺和后臺兩部分，主要包括用登陸、站點輸入、線路輸出、站點修改、線路更新等功能。系統(tǒng)的整體功能模塊圖如圖1.2.3所示：圖整體功能模塊圖1.3.4 系統(tǒng)功能模塊的劃分公交查詢系統(tǒng)功能劃分模塊如下：1）查詢系統(tǒng)模塊 該模塊實現(xiàn)公交查詢功能?？蓪崿F(xiàn)按起點中轉站終點查詢查詢和按線路查詢兩種查詢方式。圖查詢系統(tǒng)模塊2）錄入系統(tǒng)模塊 該模塊實現(xiàn)數(shù)據(jù)的錄入、修改、刪除功能。該模塊由公交站點

13、管理與公交線路管理兩部分組成.詳細設計視圖如圖錄入系統(tǒng)模塊所示：圖錄入系統(tǒng)模塊3）信息輸入輸出模塊如圖所示： 圖信息輸出模塊第二章 模式設計2.1 C/S模式簡介 精簡的說：C/S模式是一種三層結構的系統(tǒng),第一層在客戶機上安裝了客戶機應用程序,第二層在服務器上安裝服務器管理程序，第三層是數(shù)據(jù)訪問層。在C/S模式的工作過程中,客戶機程序發(fā)出請求,服務器程序接收并且處理客戶機程序提出的請求,然后返回結果。C/S模式特點：(1)C/S模式將應用與服務分離,系統(tǒng)具有穩(wěn)定性和靈活性(2)C/S模式配備的是點對點的結構模式,適用于局域網(wǎng),有可靠的安全性(3)由于客戶端實現(xiàn)與服務器端的直接連接,沒有中間環(huán)節(jié)

14、,因此響應速度快(4)在C/S模式中,作為客戶機的計算機都要安裝客戶機程序,一旦軟件系統(tǒng)升每臺客戶機都要安裝客戶機程序,系統(tǒng)升級和維護較為復雜發(fā)。2.2 B/S模式簡介精簡的說：B/S模式是一種從傳統(tǒng)的三層C/S模式發(fā)展起來的新的網(wǎng)絡結構模式，其本質也是三層結構的C/S模式。在用戶的計算機上安裝瀏覽器軟件，在服務器上存放數(shù)據(jù)并且安裝服務應用程序，服務器有WWW服務器和文件服務器等。用戶通過瀏覽器訪問服務器，進行信息瀏覽、文件傳輸和電子郵件等服務。B/S模式特點：(1)系統(tǒng)開發(fā)、維護、升級方便 每當服務器應用程序升級時，只要在服務器上升級服務應用程序即可，用戶計算機上的瀏覽器軟件不需要修改，系統(tǒng)

15、開發(fā)和升級維護方便。(2)B/S模式具有很強的開放性 在B/S模式下，用戶通過通用的瀏覽器進行訪問，系統(tǒng)開放性好。(3)B/S模式的結構易于擴展 由于Web的平臺無關性，B/S模式的結構可以任意擴展，可以從包含一臺服務器和幾個用戶的小型系統(tǒng)擴展成為擁有成千上萬個用戶的大型系統(tǒng)。(4)用戶使用方便 B/S模式的應用軟件都是基于Web瀏覽器的，而Web瀏覽器的界面是類似的。對于無用戶交換功能的頁面。用戶接觸的界面都是一致的，用戶使用方便。2.3 B/S-C/S模式2.3.1 B/S-C/S模式定義B/S-C/S模式是將B/S模式和C/S模式組合而來的，吸取這兩種模式的優(yōu)點，達到互補的作用。B/S模

16、式和C/S模式都是三層結構，B/S模式第一層是表現(xiàn)層，第二層是業(yè)務邏輯層，第三層是數(shù)據(jù)訪問層。C/S模式三層結構中第一層是客戶端與B/S模式中的第一層不一樣，其余兩層相同。在B/S模式和C/S模式數(shù)據(jù)訪問過程和業(yè)務邏輯處理過程中是在服務器端完成，用戶只需接受服務器返回的結果。在B/S-C/S模式中，一部分數(shù)據(jù)訪問過程和業(yè)務邏輯處理過程在客戶端完成，另外一部分數(shù)據(jù)訪問過程和業(yè)務邏輯處理過程在服務器端完成。本手機公交線路查詢軟件一部分功能只要依靠手機本地數(shù)據(jù)庫就可以實現(xiàn)，令外一部分功能需要借助互聯(lián)網(wǎng)實現(xiàn)。目前不論是手機硬件還是計算機硬件，更新速度很快，而且硬件的配置水平也越來越高，在硬件條件允許的

17、情況下把一部分業(yè)務處理、數(shù)據(jù)訪問的過程放在客戶端去完成，那么對服務器的硬件要求就會低一些，甚至一些高性能的PC機就可以作為服務器。從整個作業(yè)量來看，本質上是把作業(yè)量往客戶端多分攤一部分，降低服務器的作業(yè)量，因此，對客戶端的硬件要求是比較高的。B/S-C/S模式結構如圖2.3.1 所示。圖2.3.1 B/S-C/S模式結構圖本軟件系統(tǒng)采用B/S-C/S模式，系統(tǒng)框架如圖2.3.2所示。圖2.3.2 系統(tǒng)框架圖2.3.2 B/S-C/S模式特點 B/S-C/S模式在繼承了B/S模式和C/S模式的優(yōu)點之后，還具有以下特點：(1) 可靠性高1、客戶端不必完全依賴于服務器，即便脫離服務器，還有手機數(shù)據(jù)庫

18、的支持，可以繼續(xù)使用一部分功能。2、客戶端的數(shù)據(jù)丟失的時候，可以采用數(shù)據(jù)庫同步的方式從服務器獲得新的數(shù)據(jù)信息。(2) 省資源一部分作業(yè)在客戶端完成，服務器的訪問量和作業(yè)量都會減少，省資源，維護起來會更加方便。第三章 數(shù)據(jù)庫設計3.1 數(shù)據(jù)庫結構服務器數(shù)據(jù)庫為總數(shù)據(jù)源，每一個客戶端都擁有獨立的小型數(shù)據(jù)庫?？蛻舳藬?shù)據(jù)庫信息從服務器端同步獲得。服務器的數(shù)據(jù)庫是基于Mysql建立，客戶端數(shù)據(jù)庫是基于SQLite建立。數(shù)據(jù)庫體系結構如圖4.1.1所示。圖3.1.1 數(shù)據(jù)庫體系結構圖3.2 服務器數(shù)據(jù)庫設計： 用戶的需求具體體現(xiàn)在對各種信息的提供、保存、更新和查詢等方面。因此，一個滿足要求的數(shù)據(jù)庫必須充分

19、滿足對各種信息的輸入輸出需要。公交查詢系統(tǒng)應滿足以下信息需求：l 管理員必須先登錄系統(tǒng)后臺管理才能對系統(tǒng)中線路、站點等信息進行添加、刪除、修改等工作。l 普通用戶不需進行注冊就可以直接查詢相關信息。l 一輛公交車經(jīng)過多個站點。l 每個站點有多輛公交叫信息。l 一輛公交只有一條行駛線路。l 一條線路包括多個站點。綜合上面對網(wǎng)上購物系統(tǒng)數(shù)據(jù)庫的需求分析，考慮到未來功能上的擴展，設計如下的數(shù)據(jù)項結構：l 管理員信息包括的數(shù)據(jù)項：帳號、姓名和密碼。l 公交車信息包括的數(shù)據(jù)項：線路號、始發(fā)時間、末班時間、車輛等級、車輛類型、始發(fā)站、 終點站。l 站點信息包括的數(shù)據(jù)項：站點名稱、要經(jīng)過的線路號。l 線路信

20、息包括的數(shù)據(jù)項：線路號、線路中包括的站點號。通過上面數(shù)據(jù)庫的需求分析可知，該系統(tǒng)的實體有管理員實體、公交車實體、線路實體、站點實體。管理員實體如圖3.2.1 所示：管理員 NumPasswordName圖3.2.1 管理員實體圖公交車實體圖如圖3.2.2所示：公交車BusNumEndTimeBeigenStBeigenTimeEndStBusStateBusLevel 圖3.2.2公交車實體圖線路實體如圖3.2.3所示：線路NoteLineNumEndStBeigenSt圖3.2.3 線路實體圖站點實體圖如圖3.2.4所示：站點StNoteStName 圖3.2.4站點實體圖 各實體間關系的E

21、-R圖如圖3.2.5 所示：添加、刪除、修改管理員站點1n添加、刪除、修改1m包括nn公交車行駛線路11mn查詢用戶查詢nm圖3.2.5各實體間關系E-R圖 根據(jù)上面的E-R圖，本軟件服務器端定義的arashmen數(shù)據(jù)庫設計了以下4張表：站點表：station(表2)、線路表：routes(表3)、發(fā)車時間表:departuretime(表4)、票表:fare(表5)。本軟件服務器數(shù)據(jù)庫所包含的表的描述如表1。 表3.1 管理員信息表數(shù)據(jù)名稱字段類型說明Account文本管理員帳號Name文本管理員姓名PassWord文本管理員密碼線路的信息表如表3.2所示： 表3.2 線路信息表數(shù)據(jù)名稱字段

22、類型說明LineName文本線路名稱BeigenSt文本起始站點EndSt文本終止站點Note文本線路信息公交車的信息表如表3.3所示：數(shù)據(jù)名稱字段類型說明BusNum文本公交線路號BeigenSt文本始發(fā)站EndSt文本終點站BusLevel文本公交等級BusState 文本公交類型BeigenTime文本始發(fā)時間EndTime文本末班時間 表3.3公交車信息表站點的信息表如表3.4 所示： 表3.4站點信息表數(shù)據(jù)名稱字段類型說明StName文本站點名稱StNote文本站點信息3.3 客戶端數(shù)據(jù)庫設計：3.3.1 SQLite簡介Android數(shù)據(jù)庫使用的是SQLiteDatabase，我們

23、來簡單的介紹下Android平臺上的SQLiteDatabase 。SQLite是一款輕型的數(shù)據(jù)庫，是遵守ACID的關聯(lián)式數(shù)據(jù)庫管理系統(tǒng)，它的設計目標是嵌入式的，而且目前已經(jīng)在很多嵌入式產(chǎn)品中使用了它，它占用資源非常的低，在嵌入式設備中，可能只需要幾百K的內存就夠了。它能夠支持Windows/Linux/Unix等等主流的操作系統(tǒng)，同時能夠跟很多程序語言相結合，比如Tcl、PHP、Java等，還有ODBC接口，同樣比起Mysql、PostgreSQL這兩款世界著名開源的數(shù)據(jù)庫管理系統(tǒng)來講，它的處理速度比他們都快。該軟件數(shù)據(jù)庫的建立是完全在Android平臺上執(zhí)行Java代碼，通過DVM編譯來建

24、立的，沒有什么輔助工具，由于整個SQLite數(shù)據(jù)庫是非可視化操作，所有對數(shù)據(jù)庫的操作都是通過執(zhí)行Java代碼實現(xiàn)，在完成其查詢功能的時候沒有使用數(shù)據(jù)庫高級編程，較為麻煩的關節(jié)是在如何有機的將客戶端數(shù)據(jù)庫整體結構實現(xiàn)出來，實現(xiàn)過程是無可視界面，也沒有數(shù)據(jù)庫輔助工具情況下，整個過程很抽象。且表的設計應盡量簡單，不要有錯綜復雜的關系，每張表都是獨立的，不存在任何約束，數(shù)據(jù)庫也是獨立數(shù)據(jù)庫，不采用Android特有的可共享數(shù)據(jù)庫。3.3.2 數(shù)據(jù)庫設計E-R關系如圖3.3.1所示。圖3.3.1 客戶端數(shù)據(jù)庫E-R圖根據(jù)上面的E-R圖，本軟件客戶端定義的arashmen數(shù)據(jù)庫中包含以下4張表：站點表：s

25、tation(表7)、線路表：routes(表8)、發(fā)車時間表:departuretime(表9)、票表:fare(表10)。本軟件服務器數(shù)據(jù)庫所包含的表的描述如表6。表3.6 數(shù)據(jù)庫概況表表名描述主要字段stations(站點表)保存站點信息ID，stationroutes(線路表)保存線路信息ID，RouteName，ContentDeparturetime(發(fā)車時間表)保存首班發(fā)車時間保存末班發(fā)車時間RouteNameFirstDepartureTime,LastDepartureTimefare(票價信息表)保存公交線路票價信息ID，isFixed，F(xiàn)ullFare表3.7 站點表字段

26、名數(shù)據(jù)類型長度主鍵/外鍵默認值描述idInt4PKID，自動增長StationVarchar50站點名稱表3.8 線路表字段名數(shù)據(jù)類型長度主鍵/外鍵默認值描述RouteNameChar20PK線路名稱ContentLongText線路全徑表3.9 發(fā)車時間表字段名數(shù)據(jù)類型長度主鍵/外鍵默認值描述idInt4PKID，自動增長RouteNameChar20FK線路名稱FirstDepartureTimeTime首班發(fā)車時間LastDepartureTimeTime末班發(fā)車時間表3.10 票價信息表字段名數(shù)據(jù)類型長度主鍵/外鍵默認值描述idInt4PKID，自動增長RouteNameChar20FK線路名稱isFixedFareChar5是否為分段計費FullFareDouble8全程票價第四章 系統(tǒng)測試4.1系統(tǒng)測試方案根據(jù)本程序的實際情況，進行了如下測試：1） 輸入異常數(shù)據(jù)或進行異常操作在主頁面中輸入與車次無關的站點信息，系統(tǒng)將對所輸入的信息與數(shù)據(jù)庫中的信息作比較，如果沒有找到相對應的信息，則系統(tǒng)顯示為空。當用戶沒有輸入任何字符的時候，系統(tǒng)會提示用戶輸入相應的信息，以便查詢。只有符合數(shù)據(jù)庫中的信息，才能進行相應的查找。2） 災難恢復性測試由于本系統(tǒng)需要一個數(shù)據(jù)庫作為數(shù)據(jù)存儲的平臺，所以當數(shù)據(jù)庫遭到破壞的時候就無法運行，所以管理員在日常的添加、修改和刪除前都要進行必要的數(shù)據(jù)庫備份