目錄
摘 要 I
ABSTRACT II
1緒論 1
1.1選題的背景及研究意義 1
1.1.1選題的背景 1
1.1.2選題的意義 2
1.2國內外的研究現狀 2
1.2.1高標準農田建設研究現狀 2
1.2.2信息管理系統在高標準農田建設研究現狀 3
1.3論文研究內容 5
1.4本章小結 6
2高標準農田建設信息管理系統建設相關技術和理論依據 7
2.1Sqlserver 數據庫技術 7
2.2GIS 技術 7
2.2.1GIS 組件式開發 8
2.2.2ArcGIS 9
2.2.3ArcGIS Engine 9
2.3高標準農田建設信息全生命周期管理 10
2.4本章小結 11
3系統分析與設計 12
3.1系統需求分析 12
3.1.1用戶需求分析 12
3.1.2可行性分析 12
3.2系統設計原則及思想路線 13
3.2.1系統設計原則 13
3.2.2系統設計思想 14
3.3 系統體系結構 14
3.3.1系統總體結構 14
3.3.2系統技術路線 15
3.4系統功能模塊設計 16
3.4.1用戶管理模塊 17
3.4.2數據管理模塊 17
3.4.3地圖操作模塊 17
3.4.4建設監管模塊 18
3.4.5系統管理模塊 18
3.5數據庫設計 18
3.5.1概念設計 19
3.5.2邏輯設計 20
3.5.3物理設計 21
3.6基于關聯規則算法的建設監管 38
3.6.1關聯規則 38
3.6.2關聯規則中的 Apriori 算法 39
3.6.3Apriori 算法在建設監管方面的應用 40
3.7本章小結 43
4高標準農田建設信息管理系統—以 X 縣為例 44
4.1系統概述 44
4.2系統開發環境 44
4.3系統主要功能模塊實現 44
4.3.1連接數據庫 44
4.3.2用戶管理模塊 46
4.3.3數據管理模塊 49
4.3.4地圖操作模塊 53
4.3.5系統管理模塊 57
4.4本章小結 58
5結論與展望 59
5.1結論 59
5.2展望 59
攻讀學位期間參與的科研項目及發表的學術論文 60
致謝 61
參考文獻 62
1緒論
1.1選題的背景及研究意義
1.1.1選題的背景
高標準農田是指土地平整、集中連片、設施完善、農電配套、土壤肥沃、生 態良好、抗災能力強,與現代農業生產和經營方式相適應的旱澇保收、高產穩產, 劃定為永久基本農田的耕地。
糧食問題是我國政府一直以來所關注的重點民生問題。自2010 年以來,國 務院提出各地區要因地制宜,在改善條件的同時也要提高質量的要求,要以提高 高產穩產高標準的農田比例為目標,在多地同時開展土地建設,農村道路建設, 防護工作建設以及水利設施建設。
2011年7 月20 日,國務院領導就我國農田發展提出了具體要求,“切實加 強耕地保護,確保耕地保有量不減少、質量有提高。制定并實施全國土地整治規 劃,加快建設高標準農田,力爭‘十二五'期間再建成 4億畝旱澇保收的高標準 農田”[1]。同年 10 月,我國發布的“十二五”規劃綱要中明確指出:“嚴格保 護耕地,加快農村土地整理復墾。加強以農田水利設施為基礎的田間工程建設, 改造中低產田,大規模建設旱澇保收高標準農田”[2]。由此可見,建設高標準的 農田是解決糧食問題的基本途徑,也讓這項工作成為“十二五”工作中的重點項 目。
2011年10 月,我國領導人對于高標準農田的建設再一次提出了詳細的要求 和標準:“要打造以土地整治為主要內容的、統籌城鄉發展的平臺,實現城市化、 工業化、農業現代化的同步發展。”結合全國正在開展的土地整治規劃要求,在 計劃實行期間,我國將會建設出 4 億畝高標準農田,爭取到2020 年達成8 億畝 高標準農田的建設目標[3]。
我國政府格外關心高標準農田的建設,已在全國多地開展相關試驗,并且取 得了一定的成果。同時,在建設過程當中,有建設工作者發現并提出高標準農田 建設項目存在的較多問題以及困難。例如,土地相關數據采集時間較長,整理困 難,信息碎片化,此外高標準農田建設又有周期短、投資大的特點,參與建設人 員多,信息協調管理差,在建設傳遞項目數據的過程中難以保證數據的完整性、 可靠性,導致了許多人力物力資源浪費的情況。由此可見科學手段的使用對于高 效管理高標準農田建設信息是非常有必要的。
1.1.2選題的意義
通過閱讀并調查分析國內外土地管理的現狀和針對土地開發的信息管理系 統的研究狀況,讓我對目前土地信息管理使用的相關技術、發展歷程、不同土地 信息管理系統解決的問題以及其優勢都有一定的了解。其次分析目前高標準農田 建設存在的問題和需求,結合可以使用的現代化技術,從而確定本文所研究的高 標準農田建設信息管理系統的設計路線與設計思想,進而實現整個系統的設計制 作。
高標準農田建設信息管理系統的研究與探索在國內還處于初級階段,高標準 農田建設信息管理系統的建立對我國土地產業的發展具有重要意義:
1、梳理了高標準農田建設過程中系統的業務需求,確定了業務需求與系統 功能模塊的關系,并根據需求合理規劃了系統架構。
2、建立了一套高標準農田建設過程管理與可視化信息系統,該系統具有數 據庫創建、用戶信息管理、項目數據管理、數據可視化、數據監控和統計等一系 列功能,形成了一個高效可靠的管理平臺。
3、高標準農田建設過程包含的項目資料和屬性信息可以為后續建設管理部 門查詢和處理再利用打下堅實的基礎。
1.2國內外的研究現狀
1.2.1高標準農田建設研究現狀
國外發達國家早在十六世紀就開始了對于土地的整理規劃,如美國、德國、 日本、俄羅斯等都進行過類似的農田建設項目。從谷歌地球等有衛星影像的軟件 上可以看到國外發達國家的農田都已經規劃的十分完整美觀,這便于后續機械化 農業的開展。
德國是世界上最早頒布有關土地整理法律的國家,德國的農田建設任務是農 村土地的重新調整,具體措施包括條塊調整、公路建設、土壤保護、水利建設、 景觀保護等。農田建設不僅涉及土地利用,而且要重新調整土地,進行重新規劃 布局,在開展農田建設中取得了非常好的效果。
德國的農田建設可以分為四個階段:16 世紀中葉至 19 世紀末,德國的土地 整理進入了以地塊簡單合并及調整田田間道路為主以提高農業生產力的階段。第 二階段是從 20 世紀初到第二次世界大戰期間,以農業基礎設施的完善促進農業 發展的階段。從第二次世界大戰后到 20 世紀 70 年代初,土地整理步入了以鄉村 綜合整理促進農村發展的階段,也就是第三階段。20 世紀 70 年代初之后,進入 了以鄉村綜合整理與自然保護促進地區發展的第四階段。德國農田建設的主要內 容包括促進農業、保護耕作區,滿足大型設施對土地的需求,保護和建立以自然 與景觀相結合的生態系統,促進農村發展,改善村莊條件[4]。
日本的現代化農業大體上經歷了四個時期。第一個時期是從1880-1900 年, 是學習西方和歐洲的現今農業技術以提高農業生產力時期;第二個時期是從1900 年到第二次世界大戰結束,以多施肥料為主的勞動密集,出現技術改良的高潮; 第三個時期是第二次世界大戰后到70 年代初。通過推廣現代化技術的應用,建 立現代化農業;第四個時期是70 年代后,通過農田基礎設施建設推廣高性能的 農業機械化,并利用化學技術和生物技術提高土壤質量[5]。
從國外農田建設的發展來看,雖然不同國家的自然條件、社會制度、經濟發 展水平等方面存在著差異,但是國外的農田建設的很多方法與措施是值得我國在 高標準農田建設中借鑒與參考的。通過國外在現代農業發展進程中對農田建設所 采取的措施及國內對農田改造的發展與研究,可以為我國正在開展的高標準農田 建設提供寶貴經驗。
我國現代意義的農田建設時間起步較晚,在 20世紀 50年代,農田整理的主 要內容就是重新分配土地;20 世紀50 年代后期,農田整理的主要內容是進行土 地權屬關系的變更;20世紀 60年代,我國的農田整理工作處于停滯時期;20世 紀 70 年代全國農田建設得到大發展,農田整理工作開始得到重視,主要是以平 整土地、完善田間道路、溝渠、防護林為主要內容,改善了農業生產條件,提高 了土地生產能力;20 世紀80 年代,我國農村開始實行聯產承包責任制,農田整 理工作又一次進行土地權屬關系的調整;20 世紀90 年代至今,經濟的快速發展 使得耕地的數量不斷減少,我國開始進行土地利用總體規劃的編制,通過各種方 法和措施,不斷挖開發土地潛力,增加耕地數量,提高土壤質量,改善田間基礎 設施與生態環境[6]。
目前,農田整理工作的開展已是走向成熟,對農田改造的形式多樣,利用中 央政府直接投資,地方配套的政策,統一組織。隨著社會經濟的快速發展,農田 建設的內容不斷擴展和延伸。國土資源部已由原來的土地整理轉變為高標準基本 農田建設,提出高標準基本農田這一概念的目的,主要是通過農田建設項目達到 高產穩產、保障糧食安全、方便機械化耕作、抗災能力強、減少破壞生態環境等 目的。
1.2.2信息管理系統在高標準農田建設研究現狀
國外發達國家不僅對農田進行規劃整理還建立了對應的土地信息庫。如德國 在上世紀八十年代就開始應用GIS技術建立土地地籍信息庫。美國也在ESRI公 司的協同幫助下已制定了 GIS 技術標準同時建立了美國地理信息系統。日本也隨 之在上世紀九十年代使用 GIS 技術進行了土地整理和土壤改良等項目[7]。
發達國家目前對于農田管理已經是世界先進水平,但這些發達國家仍然在研 究如何進一步提高農田管理技術。可以看到,這些國家在研究如何向全自動化、 設施化、智能化等方向發展。
除了發達國家,還有許多和我國一樣在農田管理處于發展中的國家,同樣有 許多學者正在研究結合現代化技術在農田建設管理方向的應用。如 Stojanka Brankovid8]等人在2015年提出農業用地評估是整個土地整理中最精細到的一部 分,在發表的論文中以塞爾維亞土地合并中實施的一種標準土地評估方法概述了 在土地整合過程中使用不同的地理數據源和空間數據分析評估農業用地。
塞爾柱克大學的 Mevlut Uyan 在 2016 年提出了基于土地統計分析和 GIS 的 土地整理項目確定農業土壤指數的研究[9],使用克里格方法用已知點估計未知點 結合 GIS 技術確定和評估項目區域中每個農業地塊土壤指數,最后將得到的結果 與計算農業地塊土壤指數的經典方法對比。
泰國的WanitaBoonchom[10]等人于2017年針對許多種植甘蔗的小型農場, 運用貪婪算法和啟發式方法提出了一套土地整合和犁地方案,提高農場中甘蔗的 產量,也便于收割機的運作。
ArnostMuller[11]也在2018年發表期刊論文介紹了捷克共和國土地整理的過 程和地理信息系統當前使用情況。雖然捷克共和國土地整理也主要是運用 CAD 軟件制圖設計,但是作者在文中強調了土地整理數據標準化的重要性,還提出了 一種新的景觀規劃(公共設施規劃)的面向對象數據模型,它允許將這些標準化 的數據存儲在中心空間數據庫中,并向每個對象添加屬性信息。數據模型與數據 標準化相結合,為后續的通用設施規劃中 GIS 系統的應用建設奠定了基礎。
印度的學者 Aswani Kumar Munnangi 等人也于 2020 年提出要結合地理信息 技術加強土地整理工作[12],針對印度正在進行的土地整理中土地合并這一點,結 合印度北方邦的土地現狀利用先進的地籍測繪技術,將人工智能與 GIS 集成開發 建立一套數據處理信息系統,實現改善、簡化和加快土地整理工作。
地理信息系統[13]是一種特殊而重要的空間信息系統。它是在計算機軟硬件系 統的支持下,采集、存儲、管理、計算、分析、顯示和描述整個或部分地球表面 (包括大氣)空間的地理分布數據。
目前二次開發的 GIS 軟件已廣泛應用于醫療、交通、資源管理等多個行業, 取得了顯著的成果。我國的高標準農田研究是最近幾年才發展起來的,在應用地 理信息系統等技術方面還處于探索階段。
賈麗娟[14]于 2011 年利用 GIS 和層次分析法等相關算法,研究影響農田質量 的因素,分析出最有利于高標準農田建設開展的區域。羅華艷,楊旺彬,馮潔[15] 于 2013 年結合欽江流域的實際情況研究了高標準農田建設開展的潛力區比例, 為高標準農田建設提供參考。譚福林,陽益虎[16]在 2016 年結合實際高標準農田 建設項目,分析過往高標準農田建設中缺乏的先進手段從而引進了無人機技術, 能有效的監測項目區狀況且節省人力物力。侯海,波徐搏[17]于 2018 年在綏化市 使用多種方法結合計算出了當地的高標準農田潛力指數,最后利用 GIS 的數據可 視化把結果展示出來利于觀察,分析總結并針對綏化市的實際情況提出了建議。
高標準農田在我國提出以來,我國陸續在江西、四川、廣西、新疆、福建等 多地開展建設,據統計高標準農田建設不僅讓農作物的產量得到了明顯提升,還 對當地的經濟發展有很強的推動作用,把農民手頭荒廢的土地整理成有效耕地。 但目前我國的高標準農田建設過程中還存在明顯信息協同性差、管理模式落后等 問題。
綜上所述,國外發達國家對農田土地整理的信息化管理研究比較早,技術和 方法都比較成熟,國內和其他國家研究開始相對較晚,但吸收了發達國家的經驗 技術,進步迅速。不僅是從國家頒布的高標準農田建設的相關技術標準還是國內 學者對高標準農田項目區域選址研究;在研究內容方面不斷細化深入。但是目前 多是對農田潛力評價、選址劃定、確權等方面的研究。對于建設信息管理方面的 研究較少,即便有譚福林等學者研究了無人機技術管理高標準農田的方式,雖然 能節省人力物力的同時更好觀察目前的建設情況,但是在信息時效性方面較差, 這對于短期內建設龐大的高標準農田項目是非常不利的。本文正是針對高標準農 田建設過程信息及時協調管理這一點展開研究。
1.3論文研究內容
高標準農田建設信息管理系統首先要需求調研,確定高標準農田建設過程信 息管理系統的總體目標,是以實現高標準農田建設從外業調查階段、設計階段、 招標施工以及驗收階段、運行階段的全生命周期信息管理為目標,結合 GIS 技術、 數據庫技術等先進技術手段構建一個 C/S 架構的高標準農田信息管理平臺。
本論文的主要研究內容如下:
(1)經過對高標準農田建設過程用戶的需求調研,結合高標準農田建設過 程的實際情況以及相關的規范文獻,通過衛星影像等資料收集和建設過程中項目 數據分析等方法確定本高標準農田建設過程信息管理系統的總體需求,明確系統 開發所需要的關鍵技術。
(2) 在明確了高標準農田建設信息管理系統需求的基礎上,完成高標準農 田建設信息管理系統的總體架構設計和設計路線,系統的主要功能模塊,并對各 功能模塊進行說明。
(3) 根據高標準農田建設信息管理系統設計目標、系統設計原則及總體結 構,確定系統運行所需要的環境為 Windows7 及以上,采用 Geodatabase 空間數 據庫模型與SQL Server屬性數據庫一起作為系統底層數據庫,然后用.NET框架 結合GIS組件作為系統開發工具實現系統界面展示,在高標準農田建設信息管理 系統各功能模塊設計上采用C#編程語言組織系統的邏輯結構,獲取系統界面中 用戶輸入的各類動態參數,依據其邏輯規則傳遞獲取到的參數,顯示相應的數據 信息。最后按照預期目標與用戶需求對系統各功能模塊進行調試,修改完成后可 進一步測試高標準農田建設信息管理系統是否可以正常運行。
(4) 對本課題的研究內容、思想路線以及高標準農田建設信息管理系統實 現的具體過程進行歸納總結,得出本課題的主要研究成果,并結合系統實現過程 中存在的問題提出建議。
1.4本章小結
本章主要介紹了選題背景及意義、國內外對高標準農田建設的研究現狀和主 要研究內容,在當前全面推展高標準農田建設的大背景下,針對高標準農田建設 過程存在的信息孤島、數據碎片化等問題提出對高標準農田建設過程信息管理系 統的研究,在查閱了國內外農田管理現代化技術相關文獻,確定了要實現的預期 目標,結合目前先進的科學方法確立本文研究的主要內容,制定了本文的技術路 線。
2高標準農田建設信息管理系統建設相關技術和理論依據 2.1Sqlserver 數據庫技術
數據庫技術是一門研究如何更好的管理數據,并把這些數據應用于實際中的 學科。數據是數據庫技術研究和管理的對象[18]。因此,數據庫技術的內容主要包 括:對現有數據進行統一的組織和管理,按照指定的結構完成相應的數據庫和數 據倉庫的建立[19];建立一個能夠實現的數據管理應用系統,該系統具有修改數據、 刪除數據、添加數據、查詢數據等多種功能;最后使用該系統實現對數據的分析 處理。
SQL[20]( Structured Query Language)是上世紀八十年代提出的,具有簡潔、 靈活、功能強大等特點,是能夠提供結構化的查詢語言[21]。使用者不需要指定它 對數據存放的方法,還可以嵌套到其他如C#等編程語言中,具有極強的靈活性。 在數據庫建立后還可以根據實際需求更改 SQL 語句,不會影響原有數據庫的運 行,這表現出 SQL 語言極高的擴展性。也因此國內外普遍采用 SQL 數據庫產品, 如 SQL Server, Oracle, DB2, MySQL 等數據庫管理系統[22]。
Microsoft SQL Served23堤微軟公司開發的關系型數據庫管理系統,SQL Server2014 在原有的版本上進一步提升,具有很強的可用性。在更新的許多功能 中值得注意的一點就是, 2014 版本可以把固態硬盤虛擬成內存的一部分從而作 為緩沖池的延伸,以低成本提高了內存的處理能力[24]。與 Access 數據庫相比, SQL Server2014 有較強的安全性可靠性,可以允許多個用戶同時訪問[25]。與 Oracle 數據庫相比, SQL Server2014 有著友好易用的界面窗口,在數據處理速度 方面也更勝一籌,最重要是成本方面, Oracle 對硬件配置的要求更高,也不便于 維護,使用 SQL Server2014 降低了系統開發和系統后期管理的成本[26]。相對比 MySQL 數據庫而言, SQL Server2014 功能更加強大[27]。
2.2GIS 技術
在 GIS 剛出現的時候,往往只有比較單一的功能,沒有形成完整的體系。隨 后各種功能模塊逐漸聯系到一起形成GIS軟件包(GIS Package),也就是我們所知 道的集成式GIS(Integrated GIS)[28]。集成GIS是GIS發展的新階段。它的優點是 集成了 GIS 的各種功能,成為一個獨立完整的系統。其缺點是系統復雜龐大,成 本高,難以與其他應用或系統集成[29]。
隨后又出現了模塊化GIS(Modular GIS)[30],模塊化GIS能把不同功能劃分為 一系列模塊,運行于統一的基礎環境之上。相比集成式GIS,模塊化GIS劃分更 加細致,利于用戶使用。但這兩種GIS模式都很難和管理信息系統或者其他專業 應用模型集成,給專業度要求較高的行業帶來了困擾。
為解決這個問題,有研究者提出核心式GIS(Core GIS)®】的概念。開發人員 可以采用高級編程語言和核心GIS提供的動態庫,以此重組實現目標功能。但是, 核心 GIS 所提供的動態庫屬于底層,對開發人員的技術水平有較高的要求。難以 推廣核心 GIS, GIS 發展一度陷入了瓶頸期。
打破這一瓶頸的就是組件式GIS[32](Components GIS,縮寫為ComGIS)的出 現。
2.2.1GIS 組件式開發
組件 GIS 是基于標準組件平臺的[33],每個組件都可以自由靈活地重組,具 有直觀的界面和方便的標準界面。
組件式的GIS是一個高度收縮性的軟件平臺。相交于傳統GIS系統中,空 間數據管理是直接由廠商提供的[34]。這不僅限制了用戶對于數據的分析,也影響 了用戶根據數據的優劣來選擇數據庫,并提高了系統建設成本。但組件式GIS 主要把系統功能模塊劃分為完全不同功能的幾個控件,控件又能方便通過可視化 地IDE工具進行集成,最終形成可以在不同專業不同行業中應用GIS系統。相 對于傳統的開發工具,組件式GIS更適用于現在的農業發展。組件式GIS由一 系列可靈活拆分重組的同類型組件所構成,并且允許跨語言運用,具有標準的通 信接口,在數據進行管理過程當中所造成的困難,也得到了極大的解決[35]。相比 傳統的開發工具,其優勢主要如下:
(1) 功能強大。組件GIS可以基于32位或者64位系統平臺開發應用,但 相對而言32位的兼容性更好一些,開發人員在開發的時候也大多是選用32位。 與傳統GIS相比,不論是處理速度還是數據管理能力都旗鼓相當。組件式GIS 可以實現傳統GIS對空間的查詢功能,也能像傳統GIS那樣分析數據。
(2) 系統集成度高。GIS應用系統實際上是對GIS數據、基本空間處理功 能與各種應用模型進行集成[36]。 GIS 組件和其他工具聯合構成應用系統界面,再 用高級編程語言和GIS組件提供的開發接口實現具體的邏輯結構。組件GIS可 以嵌入通用開發環境,實現高效的無縫集成,最終組成開發者想要得到的應用系 統。
(3) 成本較低。用戶可以根據自身需求選擇控件,控件本身不需要開發者 另外學習其他編程語言,只需要了解對應接口特性即可,在學習成本、開發成本 上都很大程度的減輕了經濟負擔。也方便了后期人員的管理維護,降低了維護難 度和成本。
2.2.2ArcGIS
圖 2-1 ArcGIS 軟件架構
Fig.2-1 ArcGIS Software Architecture
ArcGIS 由 美 國 環 境 系 統 研 究 所 公 司 ( Environmental Systems Research Institute, Inc.簡稱ESRI)所推出的處理地理信息的平臺[3刀。ArcGIS并不僅僅是 一個 GIS 應用軟件,而是可以對地理數據進行管理、編輯、分析的 GIS 產品家 族體系的總稱,進而為各種類型用戶提供相對全面的 GIS 解決方案[38]。 ArcGIS 中包含有 ArcGIS Desktop (桌面 GIS)、Embedded GIS (嵌入式 GIS)、Server GIS (服務器GIS)、Mobile GIS (移動GIS)陰。本文在設計高標準農田建設信息 管理系統時,主要運用的就是 Embedded GIS 和 Server GIS。 ArcGIS Engine 是以 ArcObject 為基礎上的完備的嵌入式 GIS 組件庫和工具庫[40]。開發者能用它創建 一個完整的,可擴展性的、可定制的桌面應用程序。
2.2.3ArcGIS Engine
ArcGIS Engine 是一個完整的、打包的嵌入式 GIS 組件庫和工具庫,開發者 可以通過它將 ArcGIS 功能集成到 Microsoft Word、 Excel 等應用軟件中,創建集 中定制的應用軟件[41]。 ArcGIS Engine 由兩部分組成:用于構建軟件的開發工具 包和使已完成的應用程序能夠運行的Runtime (運行時環境)。ArcGIS引擎開發 包是一個基于組件的軟件開發產品,可以用來構建定制的 GIS 和其他地圖應用軟 件。 ArcGIS Engine Runtime 是一個使終端用戶軟件能夠運行的核心 ArcObjects 組件產品,并且將被安裝在每一臺運行 ArcGIS Engine 應用程序的計算機上[42]。
2.3高標準農田建設信息全生命周期管理
本文是以研究實現高標準農田建設全生命周期信息管理為目標,因此首先要 了解項目工程全生命周期[43]的具體定義,然后把高標準農田和全生命周期這一概 念結合起來。
中國建筑業協會對工程項目全生命周期的定義是:“工程項目的生命周期包 括工程項目的決策階段、實施階段和使用階段。其中決策階段包括項目建議書、 可行性研究;實施階段包括設計工作、建設準備、建設工程以及使用前竣工驗收 等[44]。”
英國皇家特許測量師學會的定義[45]是:“項目的(全)生命周期是指包括整 個項目的建造、使用以及最終清理的全過程。項目的(全)生命周期一般可劃分 為:項目的建造階段、運營階段以及清理階段。項目的建造、運營和清理階段還 可以進一步劃分為更詳細的階段,這些階段構成了一個項目的全生命周期。”
如今工程項目的生命周期在我們學習的書本上是從工程項目的提出,也就是 工程項目構思,到整個工程項目的批準立項、具體實施、竣工驗收、交付生產與 使用,再到工程項目終止使用所經歷的全過程。如下圖 2-1 所示
依據規范文件 以及調查數據 等對工程項目 進行設計
圖 2-1 高標準農田項目全生命周期管理
Fig.2-1 Life-cycle management of high-standard farmland projects 結合高標準農田的建設過程和項目工程生命周期概念,可以把整個高標準農 田項目對應劃分成項目啟動、外業調查、農田設計、招投標、施工驗收、運行監 測、整理歸檔七個階段。
第一項是項目啟動階段,對應書本上從工程項目構思到批準立項的前期策劃 階段,這一階段也稱為概念階段。該階段主要是從整體上考慮問題,提出工程項 目總目標和總功能的具體要求,為后面的批準立項做前期準備材料。該階段工作 的實施主體是工程項目的投資者和建設單位[46]。
第二項是外業調查階段,該階段主要從現狀出發,依據經驗和規范文件等資 料先對需要調查的項目進行劃分,依照不同項目類別擬定特征參數,再利用無人 機、衛星遙感等先進技術或人工調查等方法采集項目區的參數,最后歸類存檔為 后面的設計階段做數據資料準備。
第三項是農田設計階段,這一階段中,依據規范文件的設計要求和外業調查 的特征參數以及業主的要求對項目區進行合理的規劃。外業調查階段、農田設計 階段以及后面的招標部分共同組成了生命周期從批準立項到開始施工的計劃設 計階段。
第四項是招投標階段。這一階段是對設計好的項目進行分標,由建設單位或 者其他單位組織招標,讓有意向的公司進行投標操作。最后由招標方選擇合適的 投標公司,最終記錄在系統中。
第五項是施工驗收,對應施工建造階段,從工程項目開始施工到工程項目建 成、通過竣工驗收并交付使用為止。該階段工作的實施主體是施工單位和相關單 位(如提供工程項目監理咨詢服務的監理單位或者工程項目管理單位)。
第六項是運行使用階段,管理人員可以通過查看各工程項目以往的數據以及 運行的狀況,為后續管理和其他工程項目提供參考。
第七項是整理歸檔。在工程項目無法繼續實現工程項目原有價值或因拆遷等 原因不得不被拆除時,把之前的信息整理存檔,以供未來其他建設提供參考。
由于完整的全生命周期涉及過程較多,開發難度較大,對于部分階段在系統 設計時做了相應的簡化。系統設計時把高標準農田信息管理項目主要分為四個階 段,分別是調查準備階段、設計階段、招標施工以及驗收階段、運行階段。
2.4本章小結
本章主要介紹高標準農田建設信息管理系統開發所涉及到的數據庫技術、
GIS技術和全生命周期信息管理的概念。在數據庫技術中說明了其研究對象、SQL 語言以及 SQL Sever 與其他數據庫相比的優勢所在。在說明 GIS 技術時,描述了 GIS 的發展歷程,組件 GIS 的優點到本系統開發使用的 ArcGIS Engine 組件包。 最后結合項目工程全生命周期信息管理的概念,對高標準農田信息進行了階段劃 分,便于更好的對高標準農田建設信息進行管理研究。
3系統分析與設計
3.1系統需求分析
在高標準農田建設信息管理系統設計研發之前,需要對整個系統進行全面需 求分析。系統需求分析要以最終要實現的目標為核心,從用戶需要、技術是否支 持、經濟上是否可行等方面綜合分析、全方面的探討高標準農田建設信息管理系 統設計的可行性[47]。
3.1.1用戶需求分析
系統開發主要為 XX 縣高標準農田建設工作者服務,為此本人積極參與高標 準農田建設過程,結合相關文件、規范以及系統建設原則,對高標準農田建設工 作者在高標準農田建設信息管理方面的需求進行了歸納總結。
( 1)數據庫需求:由于目前高標準農田建設信息管理方式落后,各類項目 信息管理分散,數據格式不統一,在多方傳遞的過程容易丟失重要數據,造成了 信息共享困難、資源嚴重浪費。因此,需要將分散在各個部門的數據收集起來, 按照一定的標準進行分類,再按統一的規范格式進行整合,構建高標準農田建設 信息管理系統的基礎信息數據庫,便于對信息進行更新、修改和存儲等,實現高 標準農田項目信息的統一管理。
(2)便捷性需求:由于高標準農田項目信息管理系統的使用者并非計算機 專業人士,所以在系統設計時應注重操作方便、界面簡單直觀。同時也應順應信 息化管理的潮流,以實現人機交互為目標,充分利用現有數據資源,盡可能實現 信息自動提取,簡化信息的操作步驟。以達到在提高管理人員工作效率的同時保 證信息的準確性、可靠性。
3.1.2可行性分析
1 )經濟可行性分析
高標準農田建設信息管理系統在經濟成本方面主要有兩個方面,一是應用系 統開發成本;二是軟硬件的配置成本,用戶在使用本系統時需要的用戶電腦的軟 硬件環境滿足系統運行的最低要求。在高標準農田建設信息管理系統開發成本上, 使用 ArcEngine 組件開發,完成后能獨立運行,即使購買版權也只需要 ArcEngine 的相關許可,在一定程度上為高標準農田建設信息管理系統開發節省了大量的成 本。在軟硬件配置成本方面,高標準農田系統對電腦配置的要求并不高,市面上 的計算機都可以滿足。而且目前電子產品更新換代十分迅速,淘寶電商等渠道也 以廠家直銷,使用低廉的價格吸引著消費者。綜上所述,本系統無論是在研發還 是運行過程中的成本都不高,這證明了高標準農田建設信息管理系統在經濟上是 可行的。
( 2)技術可行性分析
本系統是基于C/S模式,采用C#語言開發,利用SQL Server 2014數據庫對 大量數據管理功能和ArcEngine組件包對數據的處理和可視化能力開發設計了高 標準農田建設信息管理系統。本高標準農田建設信息管理系統采用了 UI (表現 層)、DAL (數據訪問層)、BLL (業務邏輯層)加上Model (實體類庫)的三 層架構,通過此架構模型將高標準農田數據庫和應用系統的業務邏輯分開,從而 保證了高標準農田數據庫的安全性和可擴展性。高標準農田建設信息管理系統在 軟硬件方面也沒有太多要求,市面上的電腦基本都可以滿足運行條件。綜上所述, 高標準農田建設信息管理系統在技術上是可行的。
3.2系統設計原則及思想路線
3.2.1系統設計原則
高標準農田建設信息管理系統設計的基本原則主要有以下幾點:
第一,規范性原則。本系統主要是為高標準農田建設相關部門提供關鍵有效 的信息數據,必須強調系統應用設計的規范性,主要包括系統中項目數據是如何 劃分、特征數據的基本概念、各類數據存儲的結構及最終數據展示的成果等幾個 方面,從而便于高標準農田建設工作者們理解數據和使用數據。另外,還要注意 信息數據的交換格式、分類編碼、數據內容和組織都要嚴格遵循現有的國家標準、 地方標準以及行業標準,這有利于以后數據的集成,讓不同系統不同平臺的數據 庫可以相互查閱,實現數據流通。
第二,實用性與易用性原則。系統設計時要保證系統的實用性與易用性相結 合,滿足用戶需要是最基本原則。從數據庫中各個項目數據表的設計、高標準農 田建設信息管理系統的結構設計、一直到各個系統模塊的功能實現,都要實際有 效的滿足高標準農田建設信息管理的基本要求。在這個基礎上,盡量簡潔界面和 業務的操作步驟方便用戶使用,此外還應該建立幫助文檔幫助用戶更好的使用本 系統。
第三,完備性原則。系統設計的完備性不僅要保證系統中各個功能模塊的完 備性,同時也要保證底層數據庫中的數據信息的完備性。不能遺漏任何一個對建 設有用的數據,這一點在后面數據表建立的時候會進行詳細的說明。
第四,可擴展性原則。未來各類信息系統的發展方向都是以實現高集成性、 數據之間共享互通為目標。因此現在在設計高標準農田信息的管理系統的時候就 要考慮到這一點。例如用戶管理方面,就要預留標準的通信接口,便于以后和其 他系統實現用戶信息流通。在數據方面也要預留查詢等接口,供其他項目開展作 為依據和借鑒。
第五,適用性原則。由于參與高標準農田建設的工作者水平參差不齊,為了 不影響高標準農田建設項目的順利開展,系統在設計時一定要保證窗口界面簡潔 易懂。讓使用者感受到高標準農田建設信息管理系統帶來的便捷功能和數據的完 整可靠性。
3.2.2系統設計思想
根據國家頒布實施的《高標準農田建設通則》(GB/T30600-2014)和《基 本農田數據庫標準》(TD/T1019-2009 )等規章條例作為系統設計的指導思想, 以實現高標準農田建設全生命周期信息管理,減少資源浪費現象為目標。在高標 準農田建設過程數據管理流程基礎上,通過現代化技術:GIS技術、QL Services、 Visual Stdio等技術,采用C#編程語言完成對高標準農田建設信息管理系統的設 計。通過結合地理信息技術使高標準農田建設信息管理系統具有數據可視化的功 能,能記錄不同建設階段的農田信息數據的變化特點,使高標準農田建設信息管 理系統在日常工作中為其工作者提供一個高效、可靠、直觀的工作平臺。
3.3 系統體系結構
此高標準農田建設信息管理系統的設計目標是通過結合項目區高標準農田 建設過程中的相關數據,按照數據庫的建庫標準和規范,依據由國土部和農業部 牽頭制訂的《高標準農田建設通則》(GB/T30600-2014),進行基本農田信息 管理系統的設計研發。
3.3.1系統總體結構
GIS 組件技術由于其易于開發的特點,近些年來活躍于各個行業領域。高標 準農田建設信息管理系統和大多數使用GIS組件作為開發基礎的應用系統一樣, 在開發時,一般都采用主流的C/S (客戶機/服務器)或B/S (瀏覽器/服務器模式) 架構,這兩種架構各自有優缺點[48]。B/S勝在便捷,可以不用下載客戶端,直接 通過瀏覽器隨時進行訪問,在維護成本方面也更低[49]。但C/S勝在人機交互響應 更快速、數據安全可靠性高等方面,而本系統更偏重數據的安全可靠性,在綜合 分析和 ArcGIS Engine 的技術特點后,出于技術及安全性等因素考慮,系統設計 按照C/S設計模式。
高標準農田建設信息管理系統的總體結構設計分為表現層、邏輯層、數據層 三層。表示層是人機交互的一層,也就是用戶直接面對的窗口界面。界面是否簡 潔、系統是否易于操作在表現層中能最直觀的體現出來。高標準農田建設信息管 理系統主要由主體框架和窗體界面組成應用層。邏輯層主要是梳理系統的各項業 務需求,并將其劃分成系統的構件,如類、模塊、組件等。在之后的設計中再使 用接口等程序編寫將這些構件之間、構件與表現層之間都聯系起來,不斷調試程
序最終實現預期功能。邏輯層是連接表現層與數據層之間的橋梁,也是系統總體 的核心部分。數據層采用 SQL Server2014 存儲屬性數據,空間數據則通過空間 數據庫引擎 ArcSDE 傳遞給 Geodatabase 空間數據模型,以此來實現對空間數據 的訪問。同時它還具有封裝功能,負責對數據進行保護,避免由于數據改動對邏 輯層和應用層的影響,系統具體架構如圖 3-1 所示。
用戶管理模塊 數據操作模塊 地圖操作模塊 建設監管模塊 系統管理模塊
System
3.3.2系統技術路線
根據設計目的與設計思想確定高標準農田建設信息管理系統的任務目標,收 集地方的影像資料以及參考附近地區做的土地整理相關資料。
在這些資料的基礎上,通過現場調研和咨詢,結合高標準農田的建設過程分 析出用戶對高標準農田建設信息管理系統的需求,通過利用 ArcSDE、SQL Server、 ArcEngine 等技術進行系統的數據庫設計和系統總體結構設計。根據系統的開發 技術需求選擇適合的開發環境,再通過C#語言具體設計與實現系統中的各個功 能模塊,最終完成整個高標準農田建設信息管理系統的設計與實現過程。
系統設計好以后需要進行軟件測試,反復對功能模塊測試,發現系統設計實 現過程中存在的不足后加以修改完善,使其能滿足預期設計目標的需求。確定出 能夠滿足系統運行的軟硬件環境,為今后的使用者提供計算機配置的參考。
如圖 3-2 所示的是高標準農田建設信息管理系統的設計路線。
圖 3-2 高標準農田建設信息管理系統設計路線
Fig.3-2 Design Route of High Standard Field Information Management System
3.4系統功能模塊設計
把系統功能劃分成不同模塊進行設計,簡化復雜問題。每個模塊相互獨立又 相互聯系,通過參數的傳遞控制程序的邏輯選擇,最終組合成完整的高標準農田 建設信息管理系統。模塊化設計能控制程序設計的復雜性,方便開發人員開發, 在保證系統穩定性的同時也為后面對系統進一步擴展性打下基礎。
依照高標準農田建設信息管理系統的需求分析,可以把系統劃分為五大塊模 塊,分別是用戶數據模塊、數據操作模塊、地圖操作模塊、建設監管模塊、系統 管理模塊。它們各自模塊功能相互獨立,但又有著部分聯系,下面是系統總體功 能模塊圖,如圖 3-3 所示。
圖 3-3 系統總體功能模塊圖
Fig.3-3 System General Function Module Chart
3.4.1用戶管理模塊
用戶管理模塊主要是針對用戶信息的處理,包括用戶登錄登出、用戶信息的 修改、用戶事務管理、不同用戶權限的設置等。用戶事務管理可以接收查看其他 用戶提交給該用戶的問題,該用戶可遠程了解問題情況并作出相應處理。用戶權 限設計可以設定不同級別的用戶對數據有不同系統的操作權限,在一定程度上也 保證了系統數據的安全。用戶通過填寫用戶名和密碼來登錄高標準農田信息管理 類系統,這相當于數據保護的又一道鎖。
3.4.2數據管理模塊
數據管理模塊包括對數據資料進行基礎的添加、修改、刪除、查詢等操作、 數據提交更新和數據統計。在數據的基礎操作中只有查詢數據不需要權限,可供 任意用戶訪問,進行其他三項數據操作則必須擁有相應權限才可以操作,否則會 彈出對話框提示權限不足。除此之外,高標準農田信息管理中還有一個關鍵環節 就是根據有效的動態監測,及時的進行各個建設項目基礎數據的更新。就比如說, 對于某鎮進行了現場調研,擁有相應權限的用戶將數據錄入系統檢查無誤后,提 交給下一個環節。數據統計也是非常重要的,可幫助建設管理者快速查詢當前項 目的進展情況和總體項目數量,便于后續工作安排。
3.4.3地圖操作模塊
地圖操作主要是使用GIS組件實現項目數據可視化,不僅可以實現地塊文 件的放大、縮小、移動、全幅顯示等基本操作,還可以連接數據庫預覽項目建設 情況,也可以對現狀和項目建設階段有一個整體的可視化概念,便于管理部門對 項目進度等方面進行管理。
3.4.4建設監管模塊
建設監管主要利用 Apriori 關聯規則算法,挖掘數據庫中多次重復出現數據 之間的祥和聯系,達到更加科學、規范化的管理。引入數據挖掘技術中的 Apriori 關聯規則算法能夠很好發現隱含在高標準農田管理系統中建設安全方面有價值 的信息,能夠更好的為監管部門或其他部門提供更多、更好、更優質的數據支撐 和決策依據。
3.4.5系統管理模塊
系統管理模塊主要系統維護、系統備份、數據字典的管理。系統維護備份是 所有系統管理中十分重要的一塊內容,能有效保護系統安全和數據安全,在出現 數據丟失等問題時及時恢復數據。數據字典的存在讓系統更具有靈活性和可擴展 性。當用戶需要更改或標準更改時,管理人員可以修改數據字典以實現相應的請 求。一般來說,數據字典不需要修改,而且配置良好。
3.5數據庫設計
需求分析的工作完成后,就可以開始對數據庫進行設計例如數據結構、字段 命名等。按照系統需求分析得到的結果結合數據庫設計的要求,可以把數據庫的 設計分為需求分析、概念設計、邏輯設計和物理設計等階段[50],具體數據庫設計 流程如圖 3-4 所示。
圖 3-4 數據庫設計
Fig.3-4 Database design steps
本文數據包含空間數據與屬性數據兩部分,屬性數據可以直接導入關系數據 庫中進行存儲,而空間數據則需要借助數據庫引擎來實現數據管理[51]。
3.5.1概念設計
數據庫的概念設計是建立起一個信息模型,把現實中的信息轉化為機器可以 理解的形式[52]。具體來說,就是用一定的模型方法總結理解數據需求,轉換成數 據庫可以識別的信息。
在概念設計階段,主要目標就是理清系統到底要管理和存儲什么數據,數據 類型是什么,不同類型數據是以什么依據劃分的,不同類型的數據之間有什么聯 系。
對于高標準農田建設信息管理系統進行概念設計中,應該先確定建模的目標, 弄清楚建模涉及到的項目類型有哪些、類型中分別有什么業務需求;然后定義實 體集,定義實體集可以分項定義;其次是定義聯系,這是十分關鍵的一步。每個 實體之間擁有什么樣的直接聯系、間接聯系。在標注時最好標注間接聯系,由此 建立起一個完整的信息模型。
概念設計主要采用的建模方法為E-R (Entity-RelationDiagram)模型即實體 聯系模型,在邏輯設計中將對 E-R 模型的構造做進一步實例分析。在這里已經 知道高標準農田建設是以建設高標準農田為目標,圍繞農田主要限制性因素或全 面質量提升而開展的土地平整、土壤改良與培肥、灌溉與排水、田間道路、農田 防護與生態環境保持、農田輸配電,以及其他工程建設,并保障其高效利用的建 設活動[53]。
根據這個目標,在實際建設中主要涉及八種類型的項目建設,分別是項目道 路、項目機井、項目變壓器、項目排水溝、項目橋、項目涵、項目木林、項目田 塊。這里就以高標準農田建設中機井項目為例介紹部分E-R模型,如下圖3-5所 示。
3.5.2邏輯設計
數據庫邏輯設計就是要把概念設計的結果也就是E-R模型轉換成計算機系 統能識別的關系模式,模式之間的結構合理,數據之間沒有不合理的數據依賴性, 滿足各種應用的處理和使用要求。為數據庫的物理設計及數據庫高效、正確地運 行打下基礎。設計方可以設計多個項目,每個項目有一個對應的項目區域,每個 項目有多條項目數據。故上述E-R模型圖包含四種關系,這四種關系分別是: 設計方與機井項目之間有設計關系,多對多。機井項目與項目數據之間有擁有關 系,一對多。機井項目與項目區域有對應關系,一對一。鄉鎮與項目區域有提供 關系,一對多。
(1)設計關系。設計關系聯系了“設計方”實體集和“機井項目”實體集。 且聯系關系為m: n (多對多關系),根據轉換規則可以轉化為以下關系模式: 設計方(設計方的用戶賬號,設計方的用戶密碼,設計方姓名,聯系電話,設 計方公司名稱,公司地址,權屬信息,用戶權限) 。
機井項目(序列號,項目編碼)。
(2)擁有關系。擁有關系聯系了“機井項目”實體集和“項目數據”實體 集。且聯系關系為1: n (一對多關系),根據轉換規則可以轉化為以下關系模 式:
機井項目(序列號,項目編碼)。
項目數據(調查情況,機井編碼, x 坐標, y 坐標,機井內徑,機井外徑, 是否配備水泵,是否配電,是否配備流量計)。
( 3)對應關系。擁有關系聯系了“機井項目”實體集和“項目區域”實體 集。且聯系關系為 1:1(一對一關系),根據轉換規則可以轉化為以下關系模 式:
機井項目(序列號,項目編碼)。 項目區域(區域坐標,區域大小,標識碼)。
( 4)提供關系。提供關系聯系了“項目區域”實體集和“鄉鎮”實體集。
且聯系關系為1: n (—對多關系),
(5)根據轉換規則可以轉化為以下關系模式: 項目區域(區域坐標,區域大小,標識碼)。 鄉鎮(鄉鎮編碼,鄉鎮名稱)
3.5.3物理設計
經過前文中數據庫的概念設計和邏輯設計之后,能得到數據的關系模式和數 據之間的邏輯結構。但是這些數據要如何存儲,保證目前的數據能完整的存放, 后續增加數據也不會由于存儲不當產生丟失現象。在數據存儲時也要盡量考慮到 系統分配的空間大小問題,提升數據處理的性能。這就需要對數據庫的物理設計 做進一步研究。考慮應用數據在實際管理系統中的具體儲存結構和數據存取方式, 以此來保障數據的完整性、安全性、可恢復性。我們在進行物理結構設計時,要 注意合理的對文件進行組織排列,也就是研究如何把前文 E-R 模型中的各種關 系轉化成關系表,然后再按照一定的規律映射到數據表中。
ArcSDE 是用來聯系關系數據庫和空間數據的數據引擎,本文中設計的高標 準農田建設信息管理系統中的空間數據就是通過ArcSDE把收集到的SHP數據、 CAD 數據等可以按照 Geodatabase 模型存儲于 SQL Server2014 中。各個項目類 型的屬性數據也利用 SQLServer2014 以數據表的形式存儲在數據庫中。
本系統主要涉及的屬性數據表有用戶信息表、項目機井、道路、變壓器、橋 梁、涵洞、排水溝、木林田塊等分別在調查階段、設計階段、招標施工以及驗收 階段、運行階段的數據表等。涉及的空間數據表有村級區域屬性、柵格數據屬性 等。各屬性數據表以及相關說明如下所示。
首先是用戶信息數據表,主要用來管理用戶的登錄以及用戶的操作權限。如 表 3-1 所示,記錄用戶的基本信息如賬號、密碼等。其中權屬表示該公司是屬于 業主、設計、施工、監理以及其他監督管理部門中的哪一方。用戶登錄系統后系 統會根據權屬自動分配一定的權限,當遇到權限不足等情況可以向管理員申請, 在管理員通過后用戶會獲得相應權限。
表 3-1 用戶信息 Tab3-1 The information of user
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 account char 是 否 賬號
2 password varchar 否 否 密碼
3 name varchar 否 否 姓名
4 sex bit 否 否 性別
5 tell char 否 否 聯系電話
6 company varchar 否 否 公司名稱
7 unit varchar 否 否 權屬
8 accessLevel varchar 否 否 權限等級
10 remark varchar 否 否 備注
其次是高標準農田實際建設內容的分項工程:
(1)機井在調查階段、設計階段、招標施工以及驗收階段、運行階段的數
據表,如下表 3-2到 3-5 所示。
表 3-2 項目機井(調查階段) Tab3-2 Project wells (investigation phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 examine_num int 否 否 調查編號
3 town_num int 否 否 鄉鎮編碼
4 village_num int 否 否 村莊編碼
5 x varchar 否 否 機井 X 坐標
6 y varchar 否 否 機井 Y 坐標
7 wellcondition int 否 是 完好程度
8 photo varchar 否 是 照片
9 examine_r int 否 是 機井內徑
10 pump bit 否 是 有無水泵
11 electric bit 否 是 有無配電
12 time data 否 否 修改日期
13 transactor_id char 否 否 經辦人
14 remark varchar 否 是 備注
表 3-3 項目機井(設計階段) Tab3-3 Project wells (design phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id varchar 否 否 機井編碼
3 town_num int 否 否 鄉鎮編碼
4 village_num int 否 否 村莊編碼
5 x varchar 否 否 機井 X 坐標
6 y varchar 否 否 機井 Y 坐標
7 state_num int 否 是 機井類型
8 insideR int 否 是 照片
9 outsideR int 否 是 機井內徑
10 deep int 否 是 機井井深
11 pump bit 否 是 有無水泵
12 pumppower int 否 是 水泵功率(kw)
13 electric bit 否 是 是否配電
14 wellhouse bit 否 是 是否配備井蓋
15 flowmeter bit 否 是 是否配備流量計
16 electeic_id varchar 否 是 變壓器編碼
17 efficient bit 否 是 是否在高效區
18 time data 否 否 修改日期
19 transactor_id char 否 否 經辦人
20 remark varchar 否 是 備注
表 3-4 項目機井(招標施工驗收階段)
Tab3-4 Project wells (acceptance stage of tender construction)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id varchar 否 否 機井編碼
3 segment int 否 否 所在標段
4 company varchar 否 否 施工單位
5 level varchar 否 否 資質等級
6 file varchar 否 否 驗收材料地址
7 JS bit 否 否 建設方是否通過驗收
8 JL bit 否 否 監理方是否通過驗收
9 SJ bit 否 否 設計方是否通過驗收
10 KC bit 否 否 勘測方是否通過驗收
11 JD bit 否 否 監督方是否通過驗收
12 remark varchar 否 是 備注
表 3-5 項目機井(運行階段) Tab3-5 Project wells (operational phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id varchar 否 否 機井編碼
3 condition varchar 否 否 運行狀態
4 manager varchar 否 否 管理者
5 problem varchar 否 是 維修問題
6 photo varchar 否 是 問題拍照
7 solution varchar 否 是 解決方案
8 maintenanceTime varchar 否 是 維修時間
9 remark varchar 否 是 備注
(2)道路在調查階段、設計階段、招標施工驗收階段、運行階段的數據表, 如下表 3-6 到表 3-9 所示。
表 3-6 項目道路(調查階段) Tab3-6 Project roads (investigation phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 examine_num varchar 否 否 調查編號
3 town_num int 否 否 鄉鎮編碼
4 startpointx varchar 否 否 道路起點X坐標
5 startpointy varchar 否 否 道路起點 Y 坐標
6 finishpointx varchar 否 否 道路終點 X 坐標
7 finishpointy varchar 否 否 道路終點 Y 坐標
8 photo varchar 否 是 照片
9 ex_width int 否 是 調查時道路寬度
10 condition int 否 是 現狀路面情況
11 time data 否 否 修改日期
12 transactor_id char 否 否 經辦人
13 remark varchar 否 是 備注
表 3-7 項目道路(設計階段) Tab3-7 Project roads (design phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id int 否 否 道路編碼
3 town_num int 否 否 鄉鎮編碼
5 startpointx varchar 否 否 道路起點 X 坐標
6 startpointy varchar 否 否 道路起點 Y 坐標
7 finishpointx varchar 否 否 道路終點 X 坐標
8 finishpointy varchar 否 否 道路終點 Y 坐標
9 state_num int 否 否 道路類型
10 length int 否 否 道路設計長度
11 width int 否 是 路面凈寬
12 basewidth int 否 是 路基寬度
13 material varchar 否 是 路面材料
14 materialwidth varchar 否 是 材料厚度
15 compactiondegree varchar 否 是 壓實度
16 time data 否 否 修改日期
17 transactor_id char 否 否 經辦人
18 remark varchar 否 是 備注
表 3-8 項目道路(招標施工驗收階段)
Tab3-8 Project roads (acceptance stage of tender construction)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id varchar 否 否 道路編碼
3 segment int 否 否 所在標段
4 company varchar 否 否 施工單位
5 level varchar 否 否 資質等級
6 fileaddress varchar 否 否 驗收材料地址
7 JS bit 否 否 建設方是否通過驗收
8 JL bit 否 否 監理方是否通過驗收
9 SJ bit 否 否 設計方是否通過驗收
10 KC bit 否 否 勘測方是否通過驗收
11 JD bit 否 否 監督方是否通過驗收
12 remark varchar 否 是 備注
表 3-9 項目道路(運行階段) Tab3-9 Project roads (operational phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id varchar 否 否 道路編碼
3 condition varchar 否 否 運行狀態
4 manager varchar 否 否 管理者
5 problem varchar 否 是 維修問題
6 photo varchar 否 是 問題拍照
7 solution varchar 否 是 解決方案
8 maintenanceTime varchar 否 是 維修時間
9 remark varchar 否 是 備注
(3)變壓器在調查階段、設計階段、招標施工驗收階段、運行階段的數據 表,如表 3-10 到表 3-12 所示。
表 3-10 項目變壓器(調查階段)
Tab3-10 Project transformers (investigation phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 examine_num varchar 否 否 調查編號
3 town_num int 否 否 鄉鎮編碼
4 village_num int 否 否 村莊編碼
5 x varchar 否 否 變壓器X坐標
6 y varchar 否 否 變壓器 Y 坐標
7 photo varchar 否 是 照片
8 condition int 否 是 完好程度
9 ex_distributionroom int 否 是 有無配電房
10 ex_capacity int 否 是 調查容量
11 time data 否 否 修改日期
12 transactor_id char 否 否 經辦人
13 remark varchar 否 是 備注
表 3-11 項目變壓器(設計階段) Tab3-11 Project transformers (design phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id int 否 否 變壓器編碼
3 town_num int 否 否 鄉鎮編碼
5 village_num int 否 否 村莊編碼
6 x varchar 否 否 變壓器X坐標
7 y varchar 否 否 變壓器 Y 坐標
8 state_num int 否 否 變壓器類型
9 capacity int 否 是 變壓器容量
10 electric_line int 否 是 高壓線長度
11 distributionroom bit 否 是 是否設置配電房
12 time data 否 否 修改日期
13 transactor_id char 否 否 經辦人
14 remark varchar 否 是 備注
表 3-12 項目變壓器(招標施工驗收階段)
Tab3-12 Project transformers (acceptance stage of tender construction)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id varchar 否 否 變壓器編碼
3 segment int 否 否 所在標段
4 company varchar 否 否 施工單位
5 level varchar 否 否 資質等級
6 fileaddress varchar 否 否 驗收材料地址
7 JS bit 否 否 建設方是否通過驗收
8 JL bit 否 否 監理方是否通過驗收
9 SJ bit 否 否 設計方是否通過驗收
10 KC bit 否 否 勘測方是否通過驗收
11 JD bit 否 否 監督方是否通過驗收
12 remark varchar 否 是 備注
Tab3-12 表 3-12 項目變壓器(運行階段) Project transformers (operational phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id varchar 否 否 變壓器編碼
3 condition varchar 否 否 運行狀態
4 manager varchar 否 否 管理者
5 problem varchar 否 是 維修問題
6 photo varchar 否 是 問題拍照
7 solution varchar 否 是 解決方案
8 maintenanceTime varchar 否 是 維修時間
9 remark varchar 否 是 備注
(4)橋在調查階段、設計階段、招標施工驗收階段、運行階段的數據表, 如表 3-13 到表 3-16 所示。
表 3-13 項目橋(調查階段) Tab3-13 Project bridges (investigation phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 examine_num varchar 否 否 調查編號
3 town_num int 否 否 鄉鎮編碼
4 village_num int 否 否 村莊編碼
5 x varchar 否 否 項目橋 X 坐標
6 y varchar 否 否 項目橋 Y 坐標
7 photo varchar 否 是 照片
8 condition int 否 是 完好程度
9 span int 否 是 跨度
10 spannum int 否 是 跨數
11 bridgewidth int 否 是 橋面寬度
12 bridgelength int 否 是 橋身長度
13 time data 否 否 修改日期
14 transactor_id char 否 否 經辦人
15 remark varchar 否 是 備注
表 3-14 項目橋(設計階段) Tab3-14 Project bridges (design phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id varchar 否 否 項目橋編碼
3 town_num int 否 否 鄉鎮編碼
4 village_num int 否 否 村莊編碼
5 x varchar 否 否 項目橋 X 坐標
6 y varchar 否 否 項目橋 Y 坐標
7 photo varchar 否 是 照片
8 state_num int 否 是 項目橋類型
9 span int 否 是 設計跨度
10 spannum int 否 是 設計跨數
11 bridgewidth int 否 是 設計橋面寬度
12 bridgelength int 否 是 設計橋身長度
13 time data 否 否 修改日期
14 transactor_id char 否 否 經辦人
15 remark varchar 否 是 備注
表 3-15 項目橋(招標施工驗收階段)
Tab3-15 Project bridges (acceptance stage of tender construction)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id varchar 否 否 項目橋編碼
3 segment int 否 否 所在標段
4 company varchar 否 否 施工單位
5 level varchar 否 否 資質等級
6 fileaddress varchar 否 否 驗收材料地址
7 JS bit 否 否 建設方是否通過驗收
8 JL bit 否 否 監理方是否通過驗收
9 SJ bit 否 否 設計方是否通過驗收
10 KC bit 否 否 勘測方是否通過驗收
11 JD bit 否 否 監督方是否通過驗收
12 remark varchar 否 是 備注
Tab3-16 表 3-16 項目橋(運行階段)
Project bridges (operational phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id varchar 否 否 項目橋編碼
3 condition varchar 否 否 運行狀態
4 manager varchar 否 否 管理者
5 problem varchar 否 是 維修問題
6 photo varchar 否 是 問題拍照
7 solution varchar 否 是 解決方案
8 maintenanceTime varchar 否 是 維修時間
9 remark varchar 否 是 備注
(5)涵在調查階段、設計階段、招標施工驗收階段、運行階段的數據表, 如表 3-17 到表 3-20 所示。
表 3-17 項目涵(調查階段) Tab3-17 Project culverts(investigation phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 examine_num varchar 否 否 調查編號
3 town_num int 否 否 鄉鎮編碼
4 village_num int 否 否 村莊編碼
5 x varchar 否 否 項目橋 X 坐標
6 y varchar 否 否 項目橋 Y 坐標
7 photo varchar 否 是 照片
8 condition int 否 是 完好程度
9 span int 否 是 跨度
10 spannum int 否 是 跨數
11 cluvertwidth int 否 是 寬度
12 time data 否 否 修改日期
13 transactor_id char 否 否 經辦人
14 remark varchar 否 是 備注
表 3-18 項目涵(設計階段) Tab3-18 Project culverts (design phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id varchar 否 否 項目涵編號
3 town_num int 否 否 鄉鎮編碼
4 village_num int 否 否 村莊編碼
5 x varchar 否 否 項目橋 X 坐標
6 y varchar 否 否 項目橋 Y 坐標
7 photo varchar 否 是 照片
8 condition int 否 是 完好程度
9 span int 否 是 跨度
10 spannum int 否 是 跨數
11 cluvertwidth int 否 是 寬度
12 time data 否 否 修改日期
13 transactor_id char 否 否 經辦人
14 remark varchar 否 是 備注
表 3-19 項目涵(招標施工驗收階段)
Tab3-19 Project culverts (acceptance stage of tender construction)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id varchar 否 否 項目涵編碼
3 segment int 否 否 所在標段
4 company varchar 否 否 施工單位
5 level varchar 否 否 資質等級
6 fileaddress varchar 否 否 驗收材料地址
7 JS bit 否 否 建設方是否通過驗收
8 JL bit 否 否 監理方是否通過驗收
9 SJ bit 否 否 設計方是否通過驗收
10 KC bit 否 否 勘測方是否通過驗收
11 JD bit 否 否 監督方是否通過驗收
12 remark varchar 否 是 備注
Tab3-20 表 3-20 項目涵(運行階段) Project culverts (operational phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id varchar 否 否 項目涵編碼
3 condition varchar 否 否 運行狀態
4 manager varchar 否 否 管理者
5 problem varchar 否 是 維修問題
6 photo varchar 否 是 問題拍照
7 solution varchar 否 是 解決方案
8 maintenanceTime varchar 否 是 維修時間
9 remark varchar 否 是 備注
(6)排水溝在調查階段、設計階段、招標施工驗收階段、運行階段的數據 表,見表 3-21 到表 3-24。
表 3-21 項目排水溝(調查階段)
Tab3-21 Project drainage (investigation phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 examine_num varchar 否 否 調查編號
3 town_num int 否 否 鄉鎮編碼
4 startpointx varchar 否 否 道路起點X坐標
5 startpointy varchar 否 否 道路起點 Y 坐標
6 finishpointx varchar 否 否 道路終點 X 坐標
7 finishpointy varchar 否 否 道路終點 Y 坐標
8 photo varchar 否 是 照片
9 length int 否 是 排水溝長度
10 width int 否 是 排水溝底寬
11 deep int 否 是 排水溝深度
12 dredging varchar 否 是 疏浚情況
13 time data 否 否 修改日期
14 transactor_id char 否 否 經辦人
15 remark varchar 否 是 備注
表 3-22 項目排水溝(設計階段) Tab3-22 Project drainage (design phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id varchar 否 否 排水溝編碼
3 town_num int 否 否 鄉鎮編碼
4 startpointx varchar 否 否 道路起點X坐標
5 startpointy varchar 否 否 道路起點 Y 坐標
6 finishpointx varchar 否 否 道路終點 X 坐標
7 finishpointy varchar 否 否 道路終點 Y 坐標
8 photo varchar 否 是 照片
9 state_num int 否 是 排水溝類型
10 length int 否 是 設計長度
11 width int 否 是 設計底寬
12 deep int 否 是 設計深度
13 slope int 否 是 設計邊坡
14 n int 否 是 糙率
15 q int 否 是 排澇流量
16 time data 否 否 修改日期
17 transactor_id char 否 否 經辦人
18 remark varchar 否 是 備注
表 3-23 項目排水溝(招標施工驗收階段)
Tab3-23 Project drainage (acceptance stage of tender construction)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id varchar 否 否 排水溝編碼
3 segment int 否 否 所在標段
4 company varchar 否 否 施工單位
5 level varchar 否 否 資質等級
6 fileaddress varchar 否 否 驗收材料地址
7 JS bit 否 否 建設方是否通過驗收
8 JL bit 否 否 監理方是否通過驗收
9 SJ bit 否 否 設計方是否通過驗收
10 KC bit 否 否 勘測方是否通過驗收
11 JD bit 否 否 監督方是否通過驗收
12 remark varchar 否 是 備注
Tab3-24 表 3-24 項目排水溝(運行階段)
Project drainage (operational phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id varchar 否 否 排水溝編碼
3 condition varchar 否 否 運行狀態
4 manager varchar 否 否 管理者
5 problem varchar 否 是 維修問題
6 photo varchar 否 是 問題拍照
7 solution varchar 否 是 解決方案
8 maintenanceTime varchar 否 是 維修時間
9 remark varchar 否 是 備注
(7)表 3-25到表 3-28 項目木林在調查階段、設計階段、招標施工驗收階 段、運行階段的數據表。
表 3-25 項目木林(調查階段) Tab3-25 Project woods (investigation phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 examine_num varchar 否 否 調查編號
3 town_num int 否 否 鄉鎮編碼
4 x1 varchar 否 否 樹木 X1 坐標
5 y1 varchar 否 否 樹木 Y1 坐標
6 x2 varchar 否 是 樹木 X2 坐標
7 y2 varchar 否 是 樹木 Y2 坐標
8 x3 varchar 否 是 樹木 X3 坐標
9 y3 varchar 否 是 樹木 Y3 坐標
10 x4 varchar 否 是 樹木 X4 坐標
11 y4 varchar 否 是 樹木 Y4 坐標
12 photo varchar 否 是 照片
13 sum int 否 是 樹木數量
14 width int 否 否 樹木種類
15 time data 否 否 修改日期
16 transactor_id char 否 否 經辦人
17 remark varchar 否 是 備注
表 3-26 項目木林(設計階段) Tab3-26 Project woods (design phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id varchar 否 否 木林編碼
3 town_num int 否 否 鄉鎮編碼
4 x1 varchar 否 否 樹木 X1 坐標
5 y1 varchar 否 否 樹木 Y1 坐標
6 x2 varchar 否 是 樹木 X2 坐標
7 y2 varchar 否 是 樹木 Y2 坐標
8 x3 varchar 否 是 樹木 X3 坐標
9 y3 varchar 否 是 樹木 Y3 坐標
10 x4 varchar 否 是 樹木 X4 坐標
11 y4 varchar 否 是 樹木 Y4 坐標
12 state_num int 否 是 木林類型
13 photo varchar 否 是 照片
14 sum int 否 是 樹木數量
15 width int 否 否 樹木種類
16 time data 否 否 修改日期
17 transactor_id char 否 否 經辦人
18 remark varchar 否 是 備注
表 3-27 項目木林(招標施工驗收階段)
Tab3-27 Project woods (acceptance stage of tender construction)l
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id varchar 否 否 木林編碼
3 segment int 否 否 所在標段
4 company varchar 否 否 施工單位
5 level varchar 否 否 資質等級
6 fileaddress varchar 否 否 驗收材料地址
7 JS bit 否 否 建設方是否通過驗收
8 JL bit 否 否 監理方是否通過驗收
9 SJ bit 否 否 設計方是否通過驗收
10 KC bit 否 否 勘測方是否通過驗收
11 JD bit 否 否 監督方是否通過驗收
12 remark varchar 否 是 備注
表 3-28 項目木林(運行階段) Tab3-28 Project woods (operational phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id varchar 否 否 木林編碼
3 condition varchar 否 否 運行狀態
4 manager varchar 否 否 管理者
5 problem varchar 否 是 維修問題
6 photo varchar 否 是 問題拍照
7 solution varchar 否 是 解決方案
8 maintenanceTime varchar 否 是 維修時間
9 remark varchar 否 是 備注
(8)田塊在調查階段、設計階段、招標施工驗收階段、運行階段的數據表, 見表 3-29 到表 3-32。
表 3-29 項目田塊(調查階段) Tab3-29 Project fields (investigation phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 examine_num varchar 否 否 調查編號
3 town_num int 否 否 鄉鎮編碼
4 village_num int 否 否 村莊編碼
5 x1 varchar 否 否 田塊Xi坐標
6 y1 varchar 否 否 田塊Yi坐標
7 x2 varchar 否 是 田塊X2坐標
8 y2 varchar 否 是 田塊丫2坐標
9 x3 varchar 否 是 田塊X3坐標
10 y3 varchar 否 是 田塊丫3坐標
11 x4 varchar 否 是 田塊X4坐標
12 y4 varchar 否 是 田塊丫4坐標
13 photo varchar 否 是 照片
14 width int 否 是 作物種類
15 time data 否 否 修改日期
16 transactor_id char 否 否 經辦人
17 remark varchar 否 是 備注
表 3-30 項目田塊(設計階段) Tab3-30 Project fields (design phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id int 否 否 田塊編碼
3 town_num int 否 否 鄉鎮編碼
5 village_num int 否 否 村莊編碼
6 x1 varchar 否 否 田塊Xi坐標
7 y1 varchar 否 否 田塊Yi坐標
8 x2 varchar 否 是 田塊X2坐標
9 y2 varchar 否 是 田塊丫2坐標
10 problem varchar 否 是 土地問題
11 solution int 否 是 處理措施
12 time data 否 否 修改日期
13 transactor_id char 否 否 經辦人
14 remark varchar 否 是 備注
表 3-31 項目田塊(招標施工驗收階段)
Tab3-31 Project fields (acceptance stage of tender construction)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
i num int 是 否 序號
2 id varchar 否 否 田塊編碼
3 segment int 否 否 所在標段
4 company varchar 否 否 施工單位
5 level varchar 否 否 資質等級
6 fileaddress varchar 否 否 驗收材料地址
7 JS bit 否 否 建設方是否通過驗收
8 JL bit 否 否 監理方是否通過驗收
9 SJ bit 否 否 設計方是否通過驗收
i0 KC bit 否 否 勘測方是否通過驗收
ii JD bit 否 否 監督方是否通過驗收
i2 remark varchar 否 是 備注
表 3-32 項目田塊(運行階段) Tab3-32 Project fields (operational phase)
序號 字段名稱 字段類型 是否主鍵 能否為空 注釋
1 num int 是 否 序號
2 id varchar 否 否 田塊編碼
3 condition varchar 否 否 運行狀態
4 manager varchar 否 否 管理者
5 problem varchar 否 是 維修問題
6 photo varchar 否 是 問題拍照
7 solution varchar 否 是 解決方案
8 maintenanceTime varchar 否 是 維修時間
9 remark varchar 否 是 備注
3.6基于關聯規則算法的建設監管
3.6.1關聯規則
關聯規則通常被用于挖掘數據間的潛在規則,找到項目之間聯系[54]。最初在 上世紀八十年代被用于對超市購物單中隱藏的信息進行發掘,以分析客戶的購買 習慣[55]。對于關聯規則有如下定義:
設I = {Ii,【2,…,心是一個項目集合,事務數據庫D = {t1, t2, ...,tn}是
由一系列具有唯一標識TID的事務構成,每個事務t1 (i = 1, 2, ..., n)都對
應 I 上的一個子集。
(1) 支持度:給定一個全局項目集I和數據事務總數D。一個項目集I]GI 在D上的支持度(Support)是包含事務I1在D中所占的百分比。
Support (IQ =|| {t€ DR Gt} ||/|| D ||=P (1丿 (3-1)
其中| {tG D|Ii Gt} II也稱為支持度計數。
(2) 置信度:給定一個全局項目集I和數據事務總數D。一個定義在I和D 上的關聯規則形h - I2,它的置信度是指同時包含【1和【2的事務數與包含h的事 務數之比,即
Confidence(I1 -I2)= Support(IE2) (3-2)
1 2 Support(I1 )
其中,
Support (I】t I?) = P (Ii AI2) (3-3)
在研究中通常有人為規定的兩個指標,分別是最小支持度(MinSupport)和最 小置信度(MinConfidence)。只有高于這個最小值才能說明他們之前是有關聯規則 的 [56]。
3.6.2關聯規則中的 Apriori 算法
Apriori 算法是經典的關聯規則算法,也是目前數據挖掘領域中使用最為活
躍的算法之一[57]。但僅靠上面兩個指標計算容易出現誤導,因為在置信度滿足條 件的時候,置信度與原有的支持度相比可能反而會發生下降,因此需要增加提升 度這一指標驗證關聯規則有效性,其公式為:
提升度反映了關聯規則中的 X 重點內容與 Y 的相關性,提升度 >i 且越高 表明關聯性有效;否則是無效的。
整個算法的大致算法思想和流程如下所述。
首先遍歷一次數據庫,對所有事物進行劃分,找到所有單獨的項集,其中只 包含了一個項目,稱作 i 項集。然后統計所有的 i 項集在數據集合中出現的次數, 保存次數總和高于最小支持度的 i 項集。這些 i 項集的集合就是頻繁 i 項集 Li。
之后進入迭代階段,通過已得到的頻繁k項集Lk+i來尋找新一階段的頻繁 k+1項集Lk+i-首先候選k+i項集Ck+i由Lk中的成員兩兩組合而得出,而后統
計數據集合中候選 k+i 項集 Ck+i 中元素出現的頻率。將頻率值高于最小支持度 MinSupport 的 k+i 項集存入頻繁 k+i 項集 Lk+i 中。
循環下去,直到沒有新候選或頻繁的項目集合產生。 最終,迭代循環停止時,就可以得到所有的滿足設定閾值的頻繁項集。而后
可以進一步計算頻繁項集的置信度,并根據置信度得到最終的關聯規則。具體流 程如圖 3-6 所示。
圖 3-6 Apriori 算法流程圖
Fig.3-6 Apriori Algorithm Flow Chart
3.6.3Apriori 算法在建設監管方面的應用
目前,關聯規則廣泛的運用于生活的諸多領域。在高標準農田建設安全管理 方面同樣可以深度尋求數據之間的聯系,達到更加科學、規范化的管理。引入數 據挖掘技術中的 Apriori 關聯規則算法能夠很好發現隱含在高標準農田管理系統 中建設安全方面有價值的信息,能夠更好的為監管部門或其他部門提供更多、更 好、更優質的數據支撐和決策依據。
本次實驗就以在本系統運行的過程中積累的大量責任主體、工程質量檢查、 問題類別等信息進行關聯性挖掘。針對建設過程數據中包含的主體單位類型、工 程項目類別、工程地點、工程進度狀態、工程性質、技術問題描述等屬性進行了 關聯規則挖掘,尋找他們之間的聯系,對高標準農田監管工作人員有著輔助決策 的作用。以下是運用 Apriori 算法挖掘數據之間聯系的步驟。
3.6.3.1 數據預處理
為了提高實驗的準確度,挖掘出對高標準農田監管工作人員有輔助決策作用 的關聯規則,首先去除了存在錯誤輸入和空缺的數據記錄。同時根據工程項目所 在地,將工程地點歸類為六個項目區。根據數據實際情況,將工程性質分為四種, 新建、保留、更新、再利用。最后結合關聯規則挖掘的數據類型需要把出現的問 題總結歸納為以下的幾種,如下表3-33問題類別描述所示。表3-34為部分實驗 數據。
表 3-33 問題類別描述
Tab3-33 Description of the problem category
問題類別 具體含義 問題類別 具體含義
01 道路長寬厚度不滿足設計要求 15 變壓器配電房質量不達標
02 機井深度不滿足規范標準 16 變壓器高壓線布置不符合規范要求
03 機井井蓋材料與設計不符 17 木林項目管護責任和措施不到位
04 機井配電與設計不符 18 田間工程設施產權不清晰
05 機井水泵功率不達標 19 土地地塊平整度不達標
06 機井位置有偏差 20 工人施工安全防護措施不到位
07 排水溝的開挖寬度、深度不足 21 防護用具穿戴不符合規范要求
08 排水溝開挖墊層不達標 22 施工用電不規范
09 溝渠建后管護責任和措施不到位 23 腳手架安全防護措施不到位
10 項目橋質量不達標 24 臨邊、臨空安全防護措施不到位
11 項目橋長度、寬度與設計不符 25 高空安全防護措施不到位
12 項目涵質量不達標 26 施工便道安全防護措施不到位
13 項目涵布置與設計不符 27 安全警示標志設置不符合規范要求
14 變壓器布置與設計不符
表 3-34 實驗數據(部分)
Tab3-34 Experimental data (partial)
主體單位 工程項目類別 項目區 村莊 工程性質 建設狀態 問題
監理單位 道路 項目區2 孫西村 新建 施工階段 01
設計單位 道路 項目區2 代集村 新建 設計階段 26
設計單位 機井 項目區2 代集村 更新 設計階段 02
檢測單位 機井 項目區2 袁店村 保留 施工階段 03
施工單位 機井 項目區2 袁店村 新建 施工階段 06
監理單位 田塊 項目區2 寺前李村 更新 施工階段 19
建管單位 田塊 項目區2 孫西村 更新 運行階段 27
施工單位 變壓器 項目區2 孫西村 保留 施工階段 21
施工單位 變壓器 項目區2 屈樓村 保留 施工階段 25
建管單位 木林 項目區2 袁店村 新建 運行階段 17
3.6.3.2 實驗結果與分析
在文章的 3.6.2 節中已經對 Apriori 算法進行了詳細的介紹,根據算法需要計 算數據集中的每一個數據項的支持度和任意K個項集的關聯規則的置信度并對 其進行數據分析。現將數據庫中存放的一千多條數據的五種類型的主體單位分為 Ai-A5,八種工程項目類別分為Bi-B8,地點方面主要統計六個項目區分別為 Ci-C6,四種工程性質分為Di-D4,四種建設狀態分別為Ei-E4,二十七種技術 問題分為F0i-F28。在對實驗數據整理的時候為了減少不必要的候選集的產生, 先對數據進行有效處理,把出現次數少于 5 次的數據刪去不計。可以得到如下表 3-35 所示的有效數據集合。
表 3-35 有效數據集合
Tab3-35 Effective data sets
單項集 條目數 單項集 條目數 單項集 條目數
Ai 230 C4 20i Fii 73
A2 i89 C5 44 Fi3 25
A3 i76 C6 98 Fi4 28
A4 2i4 Di 389 Fi5 59
A5 203 D2 329 Fi6 35
Bi 78 D3 297 Fi7 8i
B2 i36 Ei 280 Fi8 34
B3 222 E2 262 Fi9 i3
B4 i3i E3 329 F20 i27
B5 25i E4 i4i F2i 37
B6 ii6 F0i 6i F22 26
B7 69 F02 82 F23 i5
B8 i2 F06 ii7 F24 9
Ci i6i F07 44 F25 4i
C2 247 F08 56 F26 22
C3 264 F09 30 F27 i9
根據有效數據集,使用 Apriori 算法開始遍歷尋找頻繁項集。為了在后續實 驗中保留更多數據挖掘發現關聯規則,這里設置最小支持度和最小置信度分別為 0.03 和 0.3。可以得到的結果如表 3-36 所示。
表 3-36 頻繁項集
Tab3-35 Effective data sets
頻繁項集 支持度 置信度 提升度
A4&Bi&C2&E3&F26 0.58 0.62 i.i3
A3&B2&Ci&E2&F06 0.39 0.73 i.36
A4&B3&C2&E3&F20 0.64 0.77 i.28
Ai&B7&C5&E4&Fi7 0.44 0.53 i.85
根據尋找到的頻繁項集,可以得到如下結論:
(1){A4=施工單位,C2=項目區2,Bi=道路項目,E3=施工階段}—{問題 =26}的支持度為 0.58,置信度為 0.62,證明他們之間有較強的關聯規則。且提升 度為i.i3,大于i,表明該規則是有效的。這表示項目區2的施工等單位在道路 施工時要注意做好施工便道的安全防護措施。
(2){A3=設計單位,B2=機井項目,Ci=項目區i,己2=設計階段}-{問題 =F06}的支持度為0.39,置信度為0.73,證明他們之間有較強的關聯規則。且提 升度為i.36,大于i,表明該規則是有效的。這說明了設計單位在項目區i機井 項目的設計階段發現很多機井項目的位置有偏差,需要重點核對數據,查看是外 業調查數據出現問題,還是衛星影像、數據輸出轉換等方面出現問題。
(3){A4=施工單位,B3=變壓器項目,C2=項目區2, E3=施工階段}-{問 題=F20}的支持度為0.64,置信度為0.77,證明他們之間有較強的關聯規則。且 提升度為i.28,大于i,表明該規則是有效的。這說明施工單位在項目區2變壓 器施工階段出現了比較多的工人施工安全防護不得到位的情況,其他部門也要重 點檢查施工現場安全防護措施問題,保證施工安全。
(4){Ai=建設單位,B7=木林項目,C5=項目區5,己4=運行階段}-{問題 =Fi7}的支持度為0.44,置信度為0.53,證明他們之間有較強的關聯規則。且提 升度為i.85,大于i而且相比其他項較高。不僅能說明該規則有效,還說明發生 的可能性很大。這表明項目區 5 的建設單位在木林項目運行階段要注意后期的管 理維護。
通過這些分析結果可以有效輔助有關部門加強高標準農田工程建設質量安 全監管工作,提高監管效率。
3.7本章小結
本章主要說明了高標準農田建設信息管理系統需求分析、體系結構以及每個 模塊的預期功能,最后對高標準農田底層數據庫進行設計。以機井項目為例說明 設計數據庫時運用的 E-R 模型結構,結構中邏輯關系是什么,最終轉化成數據 表的形式存儲在數據庫中。還具體分析了建設監管模塊中 Apriori 算法是如何運 用的。
4高標準農田建設信息管理系統—以 X 縣為例
4.1系統概述
本系統選用C#作為開發語言,基于ArcEngine組件技術進行的二次開發,C# 語言既有C和C++和VB的大部分優點,有著良好的開發能力。可以很好地解決 傳統的土地建設管理中存在的信息孤島、數據碎片化、容易丟失等缺陷,為數據 的安全可靠性提供有力保障。具體功能方面,本系統可以實現:用戶管理,主要 是用戶的安全登錄、用戶信息的修改、用戶權屬、用戶權限設置、用戶事務通知 等,幫助用戶更好及時的管理數據;數據操作功能,主要是增加、修改、刪除、 查詢等基礎操作,還可以完成數據的更新提交給下一權屬方,協助多方管理數據, 保證信息準確性和及時性。還可以進行空間數據的部分操作,比如SHP數據、 CAD 數據空間數據的輸入輸出等;地圖操作功能,主要是地圖的放大、縮小、 移動等;系統管理功能,主要是對系統的維護、系統資料的備份、數據字典的管 理等,有效保證信息的安全性。其中系統數據主要可分為圖形數據和屬性數據兩 方面來管理,對于外業調查中所獲得的屬性數據主要利用數據操作模塊和用戶權 限設置合作管理,實現對分項信息的登記變更。而獲得的圖形數據,如SHP數 據、 CAD 數據、柵格數據等則主要通過地圖操作模塊進行數據添加以及可視化 管理,便于管理人員更加直觀的觀察管理數據。
4.2系統開發環境
根據系統概述,選用以下的開發環境,如表 4-1 所示。
表 4-1 系統的開發環境
Tab4-1 System development environment
類別 選用平臺
操作系統
系統基礎平臺
系統開發平臺 系統的開發語言 數據庫 Windows 7
ArcGISEngine10.2、ArcGIS10.2
Visual Studio 2015 Visual C# SQLserver2005、Geodatabase
4.3系統主要功能模塊實現
4.3.1連接數據庫
數據都存放在數據庫中,因此首要的任務就是如何連接數據庫,這樣才可以
把相應的數據從數據庫中調取。以下是連接數據庫的相關代碼。
public static string conStr="server=127.0.0.1;database=GBZNT;
uid=xuena;pwd= 123";//連接字符串
private static SqlConnection _sqlCon = null;//連接
private static SqlTool」nstance = null;//實例
private static object」ock = new object();〃鎖 public static SqlTool Instance
{
set
{Instance = _instance;}
get
{
if (_instance == null)
{
lock (_lock)
{
_instance = new SqlTool();
if (_sqlCon == null)
{
_sqlCon = new SqlConnection(conStr); }}}
return _instance;
}}
public DataTable ExecuteQuery(string sql)
{
DataSet myDs = new DataSet(); SqlDataAdapter myDa = new SqlDataAdapter(); if (_sqlCon.State == ConnectionState.Closed)
{
_sqlCon.Open();
}
myDa.SelectCommand = new SqlCommand(sql, _sqlCon); myDa.Fill(myDs);
_sqlCon.Close(); return myDs.Tables[0];
}
public void ExecuteQuery2(string sql)
{
DataSet myDs = new DataSet();
SqlDataAdapter myDa = new SqlDataAdapter();
if (_sqlCon.State == ConnectionState.Closed)
{
_sqlCon.Open();
}
myDa.SelectCommand = new SqlCommand(sql, _sqlCon); myDa.Fill(myDs);
_sqlCon.Close();
}
本次實驗采用的是本地數據庫,所以在連接字符串中直接設置為 i27.0.0.i。 后面是要連接的數據庫名稱,以及訪問該數據庫需要的用戶名和密碼。數據庫本 身的用戶名和密碼增添了數據的安全性。后面則是配置數據庫的連接、實例和線 程鎖。線程鎖的作用的是保證程序穩定的執行,在執行的過程不受外界的干擾, 其他線程想要工作就必須等到該線程工作完成后才可以執行。在連接好數據庫之 后就可以開始具體搭建各個功能模塊了。
4.3.2用戶管理模塊
4.3.2.1用戶登錄
系統登錄界面設置為第一次登錄需要先進行注冊,注冊為保證安全由管理人 員統一注冊。注冊完成后根據已有用戶名密碼進行登錄,系統會先檢測用戶輸入 的信息是否符合標準,這里設置的是用戶名只能由數字組成,密碼長度不小于六 位數。再符合標準的基礎的上,系統會檢測用戶名和密碼是否與數據庫中的信息 匹配。如果不符合標準或者匹配錯誤,程序會執行 MessageBox 函數中的 show 方法,在彈出的對話框中會顯示“用戶名或密碼錯誤,請重新輸入”,如果匹配 正確即可進入高標準農田建設信息管理系統主界面。在檢測用戶名與密碼是否與 數據庫中存放的信息一致時,必須要考慮到 SQL 注入攻擊, SQL 注入攻擊是攻 擊數據庫的常用手段之一。為了保證系統安全,常用的防止 SQL 注入攻擊的方 法有使用 PreparedStatement 接口采用預編譯語句集、使用正則表達式過濾傳入的 參數、字符串過濾、JSP中調用該函數檢查是否包含非法字符、JSP頁面判斷代 碼。本次實驗采用的是字符串過濾的辦法。用戶登錄具體流程如圖 4-i 所示。
4.3.2.2系統主界面 在用戶登錄后,用戶進入高標準農田建設信息管理系統客戶端的主界面,系 統主界面如圖 4-3 所示。
本系統的主界面采用 Windows 的風格模式,它是由標題欄、菜單欄、列表 圖層區、數據顯示區組成的。主界面頂部為標題欄藍,標題欄下面是菜單欄,主 要包括文件管理,數據編輯,視圖管理、地圖操作、用戶管理、系統工具五個部 分;屏幕左側為圖層列表區,可快速定位到相關的項目區域;屏幕中間為數據顯 示區,由于篇幅限制,此處數據顯示區是以研究區 i 為例展示的項目區域范圍; 屏幕右下角為坐標信息。
圖 4-3 系統主界面
Fig.4-3 System interface
4.3.2.3用戶信息查詢及權限管理 點擊菜單欄中用戶管理選項卡,可查看用戶的個人信息,如圖 4-4 所示。
用戶個人信息包括賬號、密碼、姓名、性別、電話、公司等,部分信息可根 據用戶的需要修改。其中權屬表示該賬號是建設單位、設計單位、監理單位、施 工單位以及其他單位中哪一方。權限等級分為兩級,第一級只可對數據進行查看 和提交上報問題,第二級權限可對相應權屬范圍內的數據進行修改。查看更多用 戶信息需要管理員權限,否則會有 MessageBox 函數中的 show 方法,在彈出的 對話框中會顯示“抱歉,您的權限不足”。
4.3.3數據管理模塊
數據顯示分為兩種模式,一是表格模式對數據進行顯示,二是地圖模式對數 據進行顯示。點擊菜單欄中窗口視圖可以切換顯示表格數據。數據管理流程如圖 所示:
圖 4-5 數據管理流程圖
Fig.4-5 Data management flow chart
不同項目類型有不同的特征參數,本節主要以項目區中機井項目為例介紹表 格模式下的數據管理。首先由調查人員對項目進行外業調查。登錄系統后,把調 查的數據整理錄入系統。
點擊菜單欄中數據操作下的添加數據按鈕,系統會彈出添加數據窗口。按照 提示填入項目數據信息。填寫完成后,點擊保存按鈕,有“保存成功”字樣的提 示框彈出即表示數據保存成功。錄入完成后數據如圖 4-6 所示。
圖 4-6 機井項目調查階段數據
Fig.4-6 Project well investigation phase data
對有問題的數據可以雙擊該行數據查看數據詳情進行修改,如圖 4-7 所示, 數據詳情中還會顯示錄入時間,經辦人,和備注等信息。在數據量龐大的情況下, 也可通過上方的查詢條件和查詢關鍵字查詢處理。確認無誤后點擊上方的提交按 鈕,該數據便可由臨時數據正式存入數據庫中。
圖 4-7 數據詳情窗口
Fig.4-7 Data Details Window 提交過程的代碼為:
sql = "insert into well(x,y,town_num,village_num,examine_num,wellcondition, examine_r,pump,electric) values(@x,@y,@selecttown,@selectvillage,@examinenum,
@condition,@examR,@pump,@electric)";
SqlParameter[] pms2 = new SqlParameter[]{
new SqlParameter("@x",SqlDbType.NVarChar,15) {Value=textBox1.Text},
new SqlParameter("@y",SqlDbType.NVarChar,15) {Value=textBox2.Text}, new SqlParameter("@selecttown",SqlDbType.Int) {Value=comboBox1.SelectedIndex + 1},
new SqlParameter("@selectvillage",SqlDbType.Int) {Value=selectvillage},
new SqlParameter("@examinenum",SqlDbType.Int) {Value=textBox12.Text},
new SqlParameter("@examR",SqlDbType.Int)
{Value=Convert.ToInt32(textBox13.Text)},
new SqlParameter("@condition",SqlDbType.Int) {Value=comboBox3.SelectedIndex+1},
new SqlParameter("@pump",SqlDbType.Bit) {Value=comboBox4.SelectedIndex},
new SqlParameter("@electric",SqlDbType.Bit){Value=comboBox5.SelectedIndex},
};
int r = SqlHelper.ExecuteNonQuery(sql, pms2);
this.Text = "提交數據成功";
已經提交的數據如需要刪除,只需選中要刪除的數據行,點擊數據工具的刪
除會彈出操作提示框,點擊確定即可利用SQL語句刪除該數據。相關代碼為:
DialogResult result = MessageBox.Show("確定要刪除嗎?","操作提示",
MessageBoxButtons.OKCancel, MessageBoxIcon.Warning);
int num = Convert.ToInt32(label7.Text);
if (result == System.Windows.Forms.DialogResult.OK)
{
string sql = string.Format("delete from {0} where {1} = {2}", ItemName,
ItemName+"_num",label7.Text);
int count = Convert.ToInt32(SqlHelper.ExecuteNonQuery(sql));
if (count > 0)
{this.Text="刪除成功";
flag = 1;}}
其次由設計方登錄系統,結合調查階段數據對高標準農田機井項目進行設計。 項目機井設計時可先查看調查數據,根據設計需要選擇機井狀態。保留是不需要 重新打井,直接在現有的基礎上配套設施;更新是尺寸等不符合設計規范,需要 重新打井;廢棄是不再使用。也可以直接添加新建機井的數據。設計方設計好并 錄入數據后同樣提交,數據便可進入下一個階段。在招標施工以及驗收階段,
用戶可對有問題的數據進行查詢,并向設計方或者其他方發送問題報告,如圖
4-8 所示。
Fig.4-8 Issue report window 其他方在收到問題報告后可以在用戶管理的事務通知中查看,并對問題進行 處理回復。
4.3.2.2 建設監管數據統計 在整個建設過程中,會有大量的問題報告。提取這些數據中的有效信息,運 用本文中 3.6 所述的 Apriori 算法對數據進行深度挖掘。統計完成的結果以 TXT 記事本格式輸出。統計過程部分代碼如下:
Output IApriori.ProcessTransaction(double minSupport, double minConfidence, IEnumerable<string> items, string[] transactions)
{
IList<Item> frequentItems = GetL1FrequentItems(minSupport, items, transactions);
ItemsDictionary allFrequentItems = new ItemsDictionary(); allFrequentItems.ConcatItems(frequentItems);
IDictionary<string, double> candidates = new Dictionary<string, double>(); double transactionsCount = transactions.Count();
do{
candidates = GenerateCandidates(frequentItems, transactions); frequentItems = GetFrequentItems(candidates, minSupport, transactionsCount);
allFrequentItems.ConcatItems(frequentItems);} while (candidates.Count != 0);
HashSet<Rule> rules = GenerateRules(allFrequentItems);
IList<Rule> strongRules = GetStrongRules(minConfidence, rules, allFrequentItems);
Dictionary<string, Dictionary<string, double>> closedItemSets = GetClosedItemSets(allFrequentItems);
IList<string> maximalItemSets = GetMaximalItemSets(closedItemSets); return new Output
{StrongRules = strongRules, MaximalItemSets = maximalItemSets, ClosedItemSets = closedItemSets, FrequentItems = allFrequentItems}; }
4.3.4地圖操作模塊
地圖基本操作包括地圖的放大、縮小、移動等,地圖的放大、縮小是用到 MapControl 控件里的 Extent 方法,地圖的移動主要用到 MapControl 控件里 Pan 來實現。
地圖模式主要是對表格模式的數據可視化,讓高標準農田建設工作者能好的 吸收掌握數據情況。雙擊左邊圖層列表中項目類型將查詢數據庫中該范圍下項目 數據并可視化顯示。如圖 4-9 所示為項目區2 調查階段的項目機井的現狀圖。階 段可由菜單欄的地圖操作中階段設置,默認為調查階段。
圖 4-9 調查階段機井可視化圖
Fig.4-9 Visualization of Machine Well in Investigation Stage
查詢數據庫并顯示的代碼如下:
gFlagLayer = 1;//圖層標識
List<Model> pList= this .GetModelBySql(" select well1.num,well1.x,well1.y from well1 where tname='{0}' and vname='{1}'", SelectTown, SelectViilage"); if(pList!= null && pList.Count > 0)
{
List<Model> pAddList = new List<Model>();
if (gData_First_Old == null || gData_First_Old.Count == 0)
{
gData_First_Old = pList; pAddList = pList;
}
else
{
foreach (Model item in pList)
{
int index = gData_First_Old.FindIndex(delegate (Model it) { return it.Name == item.Name; });
if (index != -1)
{
continue;}
else
{pAddList.Add(item);// 添加點數據}
}
}
this.AddDataToTable(pList); this.AddGraphicByDataAndPNG(pAddList, esriSimpleMarkerStyle.esriSMSCircle); gData_First_Old = pList;
this.toolStripLabel2.Text= "0/0";
int init = 0;
this.toolStripLabel2.Text = init.ToString() + "/" + (this.dataGridView1.RowCount-1).ToString();}
在設計階段,機井的可視化如圖 4-10所示。
圖 4-10 設計階段機井可視化圖 Fig.4-10 Visualization of Machine Well in Design Stage 設計階段項目機井有三種狀態類型,分別為保留現有機井、更新現有機井、 新建機井。在上圖中保留現有機井為十字圖形,更新現有機井為圓圈圖形,新建 機井為點狀圖形。這些可以通過菜單欄中地圖操作的顯示設置中調整。 顯示設置是通過 ArcGIS Engine 中的 Symbol 類改變圖層的符號來改變顯示 的形狀代碼為:
ISimpleMarkerSymbol pSSymbol = new SimpleMarkerSymbolClass(); //符號設置
if (gFlag == "AddFirst")// 十字圖形
{ pSSymbol.Style = esriSimpleMarkerStyle.esriSMSCross;
}
else if (gFlag == "AddSecond")//圓圈圖形
{
pSSymbol.Style = esriSimpleMarkerStyle.esriSMSCircle;
}
else if(gFlag == "AddThird")
{
//pSSymbol.Style = esriSimpleMarkerStyle.esriSMSCircle
}
else if(gFlag == "AddForth")
{
pSSymbol.Style = esriSimpleMarkerStyle.esriSMSSquare;// 方形圖案}
除了機井、橋、涵這些類型的項目可以用點的形式表現以外,其他項目還有 需要用線的形式表示,比如道路項目,如圖 4-11所示是項目區 2 設計階段道路 可視化圖。其中粗實線表示現狀硬化路。細實線表示現狀田間路,部分田間路是 土路。結合現狀查看,項目區現有田間道路總體良好,可以納入高標準農田道路 規劃,絕大部分農田均有道路通達,基本滿足農業生產需求。對于部分道路需要 延長使其滿足通達率要求,新建延長的道路在圖中使用虛線表示。
對照高標準農田建設要求,田間道路布置應適應農業現代化的需要,與田、 水、林、電、村規劃相銜接。結合現狀道路調查屬性表,項目區內部分田間道路 路面為土路,無路基和排水溝,路況較差,坑洼不平,需要結合高標準農田總體 規劃,將該部分道路進行升級改造,路面升級改造為混凝土路。
4.3.5系統管理模塊
為了高標準農田建設信息管理系統數據的出現安全問題或可能泄密的情況, 系統 管理中歷史記錄、系統備份、系統維護以及數據字典僅對管理員開放。幫助可提 供給所有用戶查看。歷史記錄主要是負責記錄用戶登錄系統時間以及用戶操作; 系統備份是由管理員定期備份記錄,防止外界原因導致數據丟失或損壞后可以通 過備份好的數據恢復系統。
系統維護同樣是保障系統安全中不可缺少的一環,隨著用戶的增加,系統會 出現各種問題,對于重大漏洞等問題一定要及時維護,保障系統數據安全。數據 字典是關于數據庫中數據的描述,在需求分析階段建立,是下一步進行概念設計 的基礎,并在整個數據庫設計過程中不斷修改、充實、完善。其內容包括數據項、 數據結構、數據流、數據存儲、處理過程。幫助則提供給用戶一些操作幫助以及 系統版本、其他信息等。
系統備份窗口如圖 4-13 所示。系統備份中可以查看備份的時間、備份文件 的文件名、備份存放地址以及執行備份操作的管理員和管理員賬號信息。
-8裁備份 _ □ X
文件名稱:r -1 備份時間; v| 備份項目:| 寸 備份時間:r 二 備份賬戶;匚
刪除備份 新窪備份 J
萱詢
備份文件名 存放路徑 備份時間 備份項目 經辦人 經辦人賬戶
» 備阻 1 \SQL\Prog, F遼 esMticro *£t S... 20200204 項目道路 張三 2020100601
備份2 D \SQL\Prog) 4n Files\Mivro v£t S... 20200205 全部項目 張三 2020100601
備份3 D \SQL\Fro^*m FilesM^icro *£t S... 20200207 全部項目 劉一 2020120301
備份4 D \SQL\Progi am FilesMticro oft S... 20200213 項目機井 劉一 2020120301
圖 4-13 系統備份窗口
Fig.4-13 System backup window
4.4本章小結
本章主要以項目區為例,測試運行高標準農田建設信息管理系統的各個功能 模塊, 對如何操作管理數據做了說明。測試得到的結果表明,該系統界面簡潔明了,能 及時的對用戶操作作出響應,實現數據屬性查詢、數據可視化、用戶之間信息傳 遞等多種功能。
5結論與展望
5.1結論
高標準農田在建設過程中存在著信息量大、信息碎片化;各方信息交互差, 在數據傳遞過程中難以保證數據的完整性,造成人力物力資源浪費。使用現代信 息化技術手段來提高建設過程數據管理工作的效率和水平使非常有必要的。
本次研究以幫助高標準農田建設為目標,分析了國內外農田發展的研究現狀, 結合全生命周期的概念和河南省某市高標準農田建設項目,設計高標準農田建設 信息管理系統。得到的主要成果有:
(1)高標準農田建設信息管理系統可以實現項目數據的輸入輸出、普通的 增刪改查等基本操作管理,用戶還可以對有疑問的數據向數據提供方發送問題報 告,提供給參與建設的多方部門一個交流的平臺,使信息協調一致。
(2)使用GIS組件設計,實現了高標準農田項目數據可視化,圖像和屬性 的統一管理,為參與建設各部門了解建設進度和整體的工程情況提供便利。
( 3)結合了 Apriori 算法對系統運行過程中存儲的大量數據進行深度挖掘, 尋找這些數據之間的潛在聯系。在建設監管方面能提出一些建議,能幫助工作人 員有針對性的開展建設監管工作。
( 4)系統界面十分友好,采用為大眾所熟悉的 Window 界面,菜單、按鍵 等也設置的十分簡單,便于使用和操作。
5.2展望
目前本系統能基本滿足高標準農田信息的管理需求,科技仍在飛速發展,使 用者也會對高標準農田信息管理提出更高的要求,系統本身也存在著許多不足之 處,需要進一步完善加強。
(1) 增強系統的穩定性。目前的高標準農田建設信息管理系統同時接入的 用戶還比較少,在大量用戶請求接入的情況下必須要增加系統的穩定性,同時還 要進一步優化系統設計程序,去掉比較繁瑣的步驟,保證系統響應速度。
(2) 向智能化方向發展。目前高標準農田信息系統在外業調查等階段中還 存在需要大量人工的現象,即使是借助無人機等技術,也需要人工把數據導入到 系統中。如何把GPS等技術連接到系統中,實現信息的自動獲取和現場確認等, 都是日后需要學習完善的地方。
(3) 向集成性發展。對于高標準農田,國內還有許多土地評價、農田確權 等系統出現。從發展趨勢來看,這些系統在未來都會向著集成的方向發展。從單 一性能到多功能,能更好的實現數據之間的互通共享,更好的發揮這些系統的作 用。
攻讀學位期間參與的科研項目及發表的學術論文
參加項目情況:
1、信陽市商城縣水庫除險加固工程;
2、商丘市睢縣高標準農田規劃。 發表論文情況:
1、田林鋼,魏暄云,王素云.Supermap組件式開發在洪水演進中的應用研究[J]. 水利與建筑工程學報,2020,18(06):223-227.
致謝
時光總是無聲無息地從身邊溜走,在華北水利水電大學的三年時光轉眼即逝。 即將畢業之際,心中感慨萬千。在這里,我不僅學到了很多專業知識,還學到了 很多做人做事的道理。非常感謝老師、同學、師兄師姐師弟師妹們的陪伴和幫助, 讓我度過了一個非常充實的研究生生活,也讓我受益良多。
首先要感謝我的導師,田林鋼教授。田老師在帶領我們做項目的時候,不僅 訓練了我們的專業技能知識,也教導了我們做人做事的方法。在找不到突破口的 時候,老師也會耐心的提點我,幫助我尋找方向。田老師經常告訴我們對于錯誤 的方向也不要全盤否定,而是要學會總結,吸取其中正確的部分總結錯誤的原因, 為下一次嘗試做鋪墊。從論文選題、數據處理、需求分析、系統設計、系統實現 以及論文寫作的過程中,田老師給我提出了許多的寶貴意見。
同時也要感謝宋永嘉老師,三年來,一直對我們生活的關心,讓我和外省的 同學們來到學校后也能感受到家的溫暖。也要感謝您在學習上對我們的幫助,在 小論文初稿完成后,您一字一句的幫我們審核論文語句是否通順,排版布局是否 合理,并提出很多寶貴的意見。在投稿后也督促我們時刻關注審核進度。
在這三年讀研期間,不但有老師們的諄諄教導,還與朋友們度過了一段非常 美好的時光。感謝同門兄弟姐妹們對我學習工作中的幫助與支持,感謝師兄師姐 在軟件方面提供的建議以及學習軟件的幫助與支持,感謝所有幫助過我的同學及 朋友們,感謝你們對我論文的順利完成給予的幫助與支持!
感謝水利2018級2班的全體同學和跟我一起生活了三年的舍友,在生活上 對我的關懷照顧,愿我們以后工作生活都能快樂,順利。也要感謝我的父母親人, 是你們一直支持著我,一直鼓勵我。是你們作為我堅實的后盾,我才有動力去追 求去實現更好的自己。
感謝華北水利水電大學在學習上給我們提供了良好的學習和科研住宿環境, 在生活上給我們提供了優越的住宿條件。
最后,感謝評閱論文和出席學位論文答辯會的各位專家、教授,感謝他們在 百忙中給予的指導!
參考文獻
[1]李倩.數量時代過去產能時代到來——國土資源部土地整理中心副主任鄖文 聚談高標準農田建設[J].中國土地,2012(03):8-11.
[2]鄖宛琪,朱道林,湯懷志.中國土地整治戰略重塑與創新J].農業工程學 報,2016,32(04):1-8.
[3]中國稅務網.國務院關于全國高標準農田建設總體規劃的批復J].當代農村 財經, 2013(31):5-5.4-24.
[4]潘明才.德國土地復墾和整理的經驗與啟示J].國土資源,2002(01):50-51.
[5]吳良.日本現代農業發展的實踐與啟示[J].世界農業,2012(01):78-82.
[6]王璦玲,趙庚星,史娟.我國土地整理發展的現狀、問題與對策研究J].山東農業 大學學報(社會科學版),2005(04):45-48+125-126.
[7]李樹君,方憲法,南國良,等.數字農業工程技術體系及其發展J].農業機械學 報,2003,34(5):157-160.
[8]Stojanka BrankoviC and Ljiljana ParezanoviC and Dragisa Simovic. Land consolidation appraisal of agricultural land in the GIS environment[J]. Geodetski Vestnik, 2015, 59(2) : 320-334.
[9]Mevlut Uyan. Determination of agricultural soil index using geostatistical analysis and GIS on land consolidation projects: Acase study in Konya/Turkey[J]. Computers and Electronics in Agriculture, 2016, 123 : 402-409.
[10]Wanita Boonchom et al. Land consolidation of small-scale farms in preparation for a cane harvester[J]. Computers and Electronics in Agriculture, 2017, 142 : 59-69.
[11]Arnost Muller. GIS approach to publishing common facilities plans of land consolidation in the Czech Republic[J]. Geodetski Vestnik, 2018, 62(4) : 641-656.
[12]Aswani Kumar Munnangi and Bharat Lohani and Subhas Chandra Misra. A review ofland consolidation in the state ofUttar Pradesh, India: Qualitative approach[J]. Land Use Policy, 2020, 9
[13]湯國安.地理信息系統教程[M].高等教育出版社,2007.
[14]賈麗娟.重慶市高標準農田建設標準及模式研究[D].西南大學,2011.
[15]羅華艷,楊旺彬,馮潔.高標準基本農田建設潛力區研究——以欽州市欽北區
為例[J].安徽農業科學,2013,41(29):11776-11778.
[16]譚福林,陽益虎.無人機技術在高標準基本農田建設項目竣工驗收中的應用
[J].農業工程,2016,6(05):92-94.
[17]侯海波,徐搏.基于GIS的綏化市高標準基本農田潛力評價研究J].測繪與空 間地理信息,2018,41(03):87-90.
[18]王珊,薩師煊.數據庫系統概論[M].高等教育出版社,1983.
[19]史嘉權.數據庫系統概論[M].清華大學出版社,2006.
[20]屠海波.應用SQL語言進行數據查詢與統計[J].中國衛生統計,2007,
24(4):424-425.
[21]余小高.用嵌入式SQL語言開發ORACLE數據庫應用的方法研究[J].計算機 應用與軟件,2004(04):22-24.
[22]瞿中,譚舸,湯曉輝,等.數據庫系統原理與應用[M].人民郵電出版社,2013.
[23]許謙,李元棟,王彧之.基于SQL Server的高校信息資源管理系統設計J].現代 電子技術,2020,43(20):115-118.
[24]喬根森.SQL Server 2014管理最佳實踐(第3版)[M].清華大學出版社,2015.
[25]崔再惠.Access數據庫與SQL Server數據庫主要功能的比較J].鞍山師范學 院學報, 2009, 11(006):51-52.
[26]閆旭.淺談SQL Server數據庫的特點和基本功能[J].價值工程,2012, 31(022):229-231.
[27]茅祚庥.五強爭鋒DB2、SQLServer、MySQL、Oracle9i及ASE數據庫比 評[J].中文信息:程序春秋,2002, 000(005):20-21.
[28]郭秋英.當前GIS發展的幾個特點[J].測繪通報,1998, 05(5):43-43.
[29]趙耀龍,巢子豪.歷史GIS的研究現狀和發展趨勢J].地球信息科學學 報,2020,22(05):929-944.
[30]周博,施文軍,劉小勇.農業工程信息系統中遙感與GIS集成應用研究J].農機 化研究,2007(10):149-152+156.
[31]陳紅艷,于曉峰,李曉燕,等.城鎮地籍數據庫建設及發展趨向[J].測繪通 報,2010(07):65-67+74.
[32]RawatPK. GIS development to monitor climate change and its geohydrological consequences on non-monsoon crop pattern in Himalaya[J]. Computers & Geosciences, 2014, 70(C):80-95.
[33]田林鋼,魏暄云,王素云.Supermap組件式開發在洪水演進中的應用研究J].水 利與建筑工程學報,2020,18(06):223-227.
[34]顧斌.基于GIS的房產登記和交易系統的設計與研究[D].南京郵電大學, 2012.
[35]王冬武,何志剛,伍遠安,等.基于GIS的湖南省數字漁業信息系統J].江蘇農業 科學,2016,44(07):431-435.
[36]王兆紅,詹偉,邱菀華.基于GIS與工作流技術的設施管理系統J].遼寧工程技 術大學學報(自然科學版),2009,28(01):119-122.
[37]BearmanN, Fisher P F . Using sound to represent spatial data in ArcGIS[J].
Computers & Geosciences, 2012, 46:157-163.
[38]Kanwarpreet SINGH,Virender KUMAR.Hazard assessment of landslide disaster using information value method and analytical hierarchy process in highly tectonic Chamba region inbosom of Himalaya[J] . Journal of Mountain Science,2018,15(04):808-824.
[39]吳功和,叢明日.基于ArcGIS Server的分布式GIS應用[J].測繪科學技術學 報, 2006(01):52-55.
[40]王世巖,彭文啟,李振海,等.基于ArcGIS Engine的全國水環境管理信息系統設 計與實現[J].中國水利水電科學研究院學報,2007(03):191-195.
[41]Qin R , Lin L . Development of a GIS-based integrated framework for coastal seiches monitoring and forecasting: A North Jiangsu shoal case study[J]. Computers &Geosciences, 2017, 103(JUN.):70-79.
[42]ChenJ, LinZB, Chen Y L , et al. System developing of eco-environmental information Tupu toolset based on ArcGis Engine and C#. ScienceofSurveyingand Mapping, 2010.
[43]王光麗.全生命周期工程造價管理理論構建及啟示J].商業時 代,2012(18):94-95.
[44]蒯鵬程,趙二峰,李培聰,等. 基于 BIM 的水利水電工程全生命周期管理研究
[J]. 水電能源科學,2018,036(012):133-136.
[45]英國皇家特許建造協會,李世蓉,許選明,等. 建設項目監理實用規程——現 代建筑管理譯叢[M].中國建筑工業出版社,2001.
[46]田櫻.水利工程全生命周期投資控制的關鍵因素分析J].華北水利水電學院 學報(社科版),2012,28(06):87-89.
[47]秦楠,馬亮,黃銳.基于系統理論過程分析的軟件安全性需求分析與驗證方法
[J].計算機應用,2020,40(11):3261-3266.
[48]李國慶,潘振波,王丹,等.基于C/S與B/S混合架構的配電地理信息系統[J].電 網技術,2009,33(06):102-106.
[49]劉媛,張偉,王知學.基于B/S和C/S架構的嵌入式遠程監控系統[J].儀表技術 與傳感器,2008(10):39-41.
[50]Rex Hogan. APractical Guide to Database Design[M].CRC Press:2018-03-08.
[51]詹金貴.基于GIS的農地確權管理信息系統的設計[D].昆明理工大學,2019.
[52]Rex Hogan. APractical Guide to Database Design, Second Edition[M]. Taylor and Francis, 2018
[53]GB/T 30600-2014,高標準農田建設通則[S].
[54]Puneet Matapurkar,Saurabh Shrivastava. Applications of FP-Growth andApriori Algorithm for Mining Fuzzified Spatial Dataset[J]. International Journal of Engineering and Advanced Technology (IJEAT),2019,9(2).
[55]Tao Li. Mining Association Rules on Enrollment Information of Higher Vocational Colleges Using the Apriori Algorithm[J]. Journal of Advanced Computational Intelligence and Intelligent Informatics,2019,23(4).
[56]Xiaoli Wang,Kui Su,Lirong Su. Research on Improved Apriori Algorithm Based on Data Mining in Electronic Cases[J]. International Journal ofHealthcare Information Systems and Informatics (IJHISI),2019,14(3).
[57]吳俊杰,劉冠男,王靜遠,等.數據智能:趨勢與挑戰J].系統工程理論與實 踐,2020,40(08):2116-2149.