時間：2022-03-19 20:50:46
導語：在數據庫技術論文的撰寫旅程中，學習并吸收他人佳作的精髓是一條寶貴的路徑，好期刊匯集了九篇優秀范文，愿這些內容能夠啟發您的創作靈感，引領您探索更多的創作可能。
目前，著名數據庫管理系統有Oracle、Sybase、Informix、Microsoft、MicrosoftAccess、VisualFoxPro等,這些產品各以自己特有的功能，在數據庫市場上占有一席之地。下面簡要介紹幾種常用的數據庫管理系統。
1.Oracle。Oracle是一個最早商品化的關系型數據庫管理系統，也是應用廣泛、功能強大的數據庫管理系統。Oracle作為一個通用的數據庫管理系統，不僅具有完整的數據管理功能，還是一個分布式數據庫系統，支持各種分布式功能。Oracle使用PL/SQL語言執行各種操作，具有可開放性、可移植性、可伸縮性等功能。
2.Sybase。最新版本的SybaseAdaptiveServer與以前的版本相比，具有更豐富的功能設置，Sybase比較強大的地方在于它對資源的低占有率上。在這一方面，Sybase15還引入了新的“專利查詢過程技術”，顯示了增強的性能和降低的硬件資源消耗。
3.MicrosoftSQLServer。MicrosoftSQLServer是一種典型的關系型數據庫管理系統，可以在許多操作系統上運行，它使用Transact-SQL語言完成數據操作。由于MicrosoftSQLServer是開放式的系統，其它系統可以與它進行完好的交互操作。
4.MicrosoftOffice。作為MicrosoftOffice組件之一的MicrosoftAccess是在Windows環境下非常流行的桌面型數據庫管理系統。Access既擁有用戶界面(VB可以用來開發用戶界面)；也擁有邏輯、流程處理，即VBA語言(VB也可以用來做邏輯處理)；又可以存儲數據，即在“表”中存儲數據。使用MicrosoftAccess無需編寫任何代碼，只需通過直觀的可視化操作就可以完成大部分數據管理任務。在MicrosoftAccess數據庫中，包括許多組成數據庫的基本要素。這些要素是存儲信息的表、顯示人機交互界面的窗體、有效檢索數據的查詢、信息輸出載體的報表、提高應用效率的宏、功能強大的模塊工具等。
5.VisualFoxPro。VisualFoxPro是Microsoft公司VisualStudio系列開發產品之一，簡稱VFP是Xbase數據庫家族的成員，可以運行于Windows9X/2000和WindowsNT平臺的32位的數據庫開發系統。VisualFoxPro提供了一個功能強大的集成化開發環境，采用可視化和面向對象的程序設計方法，使數據管理和應用程序的開發更加簡便。VisualFoxPro是數據庫管理軟件，可實現數據與應用程序獨立。
二、如何選擇適合自己的數據庫軟件
1.按性能應從以下幾個方面予以考慮：
(1)構造數據庫的難易程度；(2)程序開發的難易程度；(3)數據庫管理系統的性能分析；(4)對分布式應用的支持；(5)并行處理能力；(6)可移植性和可擴展性；(7)數據完整性約束；(8)并發控制功能；(9)容錯能力；(10)安全性控制；(11)支持漢字處理能力。
2.按需求來選擇
選擇一個數據庫的主要理由就是它的功能是否可以很好地支持你的應用程序。人們通常使用數據庫來完成的任務有：支持Web、事務處理、文本搜索，有的情況下復制也是一個重要的要求。在事務處理方面，Oracle看上去更有領先優勢，接下來是微軟的SQLServer。沒有一個開源數據庫具有可以與Oracle相媲美的事務處理功能。
3.按易用性和管理來選擇；
4.按支持性來選擇；
5.按成本因素來選擇。
三、結論
Oracle是商業數據庫的代表，具有非常豐富的功能、廣泛的平臺支持和大量的附加功能。目前Access更常用一些，Access不是一種存儲格式，是一種軟件。ACCESS這個軟件本身就具有開發者使用的界面和適合于“最終用戶”的界面。但學習FoxPro可為學型數據庫管理軟件大典基礎。微軟的SQLServer只可以運行在其Windows操作系統平臺上。不過由于Windows操作系統的廣泛普及，缺乏對其他系統的支持并沒有阻擋SQLServer的市場份額的增長。SQLServer是真正的中大型數據庫,VFP是桌面數據庫,使用方便、易學，但實際上犧牲了真正數據庫的一些功能，如安全性；此外，VFP既是數據庫又是編程語言（開發工具）。SQLServer是中大型數據庫,VFP是帶有自身數據庫的編程語言。
總體來說，選擇什么樣的數據庫要看你的應用程序的需要。如果它是以閱讀數據庫為主的Web應用，MySQL無疑是最佳選擇。而如果需要那些事務處理和復雜的數據庫功能，那么可選擇Oracle和微軟的SQLServer。如果你需要一些商業數據庫的高級功，但又不想支付授權費用，那么可以考慮PostgreSQL或Ingres。對于嵌入式數據庫應用，MySQL和Sybase所占有的系統資源最少。總之，最適合的才是最好的！
參考文獻：
[1]劉守根.數據庫管理系統的現狀和發展方向初探.內江科技，2006，(2).
[2]陳業斌.分布式數據庫管理系統的設計與實現.安徽工業大學學報(自然科學版)，2005,(3).
[3]姬志剛.計算機、網絡與信息社會.科技咨詢導報，2006，(20).
[4]薛向陽.數據庫管理系統的開發與程序的設計.渭南師范學院學報，2005,(2)
[5]竺洪平.數據庫管理系統的設計與程序的開發.中小學電教，2005，(6).
本文以面向文檔的NoSQL作為數據持久層，面向文檔的NoSQL數據庫的數據結構設計相對于關系型數據庫來說容易許多，在對數據進行查詢、數據庫操作接口方面都有很大的優勢］。因為面向文檔的NoSQL數據庫不支持多張表的JOIN操作，因此在對面向文檔的NoSQL數據集合進行設計的時候需要考慮到這方面的因素。本監測系統主要的業務功能可以分為3個模塊，分別是小區信息查詢模塊、報表統計模塊和用戶、終端管理模塊，因此，數據集合的設計同樣從這三個方面進行設計。各個數據集合之間的關系如圖1所示。考慮到在對數據表進行設計所依據的原則基本一致，因此以下僅對小區信息查詢模塊的數據表設計進行著重分析。設計數據模型需要結合系統的特點進行分析。此系統主要實現的功能是對小區天線參數信息進行保存、管理，并以友好的界面展示給用戶，并響應用戶的各種操作。因此，在大部分的操作中，存儲天線實時參數的ANTENNAARGS表會產生大量的插入操作，本文根據各個表的不同讀寫比進行了設計，如圖2所示。本文將天線表、區域表以內嵌的形式放入了小區表，將天線參數表設計成單獨的集合，并以引用的方式指向了小區表主要是考慮到天線參數集合是被訪問最頻繁的表，會產生大量的讀寫操作，因此在小區集合與天線參數集合之間采用的是范式化的模式。其中，天線工參表(ANTENANARGS表)用來存儲從各個采集終端傳輸至管理系統的小區天線實時數據信息，具體如表1所示。小區信息表(CELL表)用來存儲各個小區的地址、天線相關參數詳細信息，如表2所示。除了上述表之外還有采集終端表(TERMI-NAL)、天線信息表(ANTENNA)和告警表(ALARM-REPORT)等。數據庫運行時，自動將所對應的數據存入相應表中。
2數據庫自動分片設計
管理系統在運行中會產生大量的寫操作，進而帶來頻繁的磁盤I/O操作，在大數據下，最好采用將數據庫分布在多臺服務器上，即分片［7］。本文采用Auto-Sharding(自動分片)及Replic-Set(復本集)相結合的方式來減輕單個數據庫服務器的負載，即在每臺Server上各自運行一個實例，組成一個Replic-Set，最后再各運行一個實例，組成ConfigServer。直接執行Addshard操作即可增加分片以緩解服務器的壓力，實現動態擴展。分片的實現重點在于片鍵設計。本文將保存天線參數信息的集合聲明了一個復合片鍵{Lacci:1，Day:1}。當來自不同的小區(可以根據Lacci進行判斷)向集群系統插入數據時，可以預計到在大部分情況下，同一小區的數據會落在單個塊或片上。
3數據庫查詢的實現
數據查詢功能為本數據庫設計的重要功能之一。數據庫將小區信息、天線參數等相關的數據信息根據用戶的要求，以界面或報表的形式全部或部分的顯示給用戶。基于本數據庫的設計，用戶通過數據查詢菜單進入相應查詢界面，獲取小區信息、終端信息及告警信息等。實現“天線工程參數查詢”功能的工作流程如圖3所示。為了實現小區天線參數查詢功能，客戶端需要向數據庫發送2次請求，用戶根據需求，向控制器發送查詢請求，控制器處理查詢命令，對相應的小區進行信息查詢，待小區返回信息后，將用戶的查詢命令發送至對應小區，根據需求讀取有用信息，并返回給用戶。跟關系型數據庫相比，由于省去了大量的多表連接操作，實際上查詢的效率要高于基于關系型數據庫的多表連接查詢。查詢工作的SQL語句如下。
4數據庫備份與恢復
數據安全在數據庫設計中有很重要的地位。在各種意外情況下，如計算機硬件故障等，對數據庫進行備份和恢復能夠保障數據的完整性和安全性，使得數據損失降到最小［8］。本數據庫設計的備份選用的是副本集的方式［7］:在主節點上進行操作，寫入的數據被一步地同步到所有的從節點上，并從主節點或從節點上讀取數據，如果主節點由于某些原因斷線，會自動將一個從節點提升為主節點。在查詢分析器中運用SQL語句完成數據庫的備份和恢復。在數據庫管理界面中，用戶通過數據庫備份與恢復功能進行相應操作，確保數據的正確行和完整性。
5結束語
1.1有效避免資源浪費現象的發生
對于計算機軟件系統而言，數據庫作為其中的核心內容，需要得到人們的重點關注。在數據庫設計的過程中，需要通過對軟件工程的定義分析，實現對不同軟件工程項目的認識及理解，滿足數據庫編程的基本需求，從而有效避免了數據資源浪費現象的發生。在軟件設計中，設計人員需要提高對軟件數據庫編程的重視，通過對數據庫資源的綜合性分析，避免數據庫出現使用性能不高的問題，解決數據故障限制因素。對于不良的數據庫而言，其后期系統的維護頻率會不斷增多，從而造成了計算機軟件維修中資源浪費的現象。
1.2提高計算機軟件系統運行速度
在計算機系統設計及分析中，需要通過對軟件系統的運用，實現對程序功能的穩定發揮，為數據資源的系統運行提供有效支持。而且，在高性能數據軟件系統運用中，可以通過對計算機系統的操作分析，進行準確、快速的信息傳輸，全面提高軟件系統的運行速度。同時，在計算機軟件系統使用的過程中，通過對數據庫資源的拓展分析，可以為用戶提供便利性的服務支持，減少數據資源浪費現象的發生。通過計算機軟件數據庫的構建，可以實現對數據庫資源的合理革新，從而為數據資源的儲存軟件系統的管理提供有效支持。
2計算機軟件工程中的數據庫建立
開展計算機軟件工程建設過程中，首先要針對數據庫系統進行完善，設計構建基礎的框架，計算機軟件通常是在網絡環境下運行使用的，因此在建設期間，也要考慮是否存在影響因素，通過各個系統之間的相互配合，來實現軟件功能，數據庫中的信息安全性也能夠得到保障。對于軟件工程中針對數據庫編程管理問題，在建立初期要有明確的使用方向，完成基礎框架設計后需要針對功能方面采取完善措施，不斷的補充其中的功能，并提升軟件自身防御能力，這樣即使是在網絡運行使用環境下，也能最大限度的避免受到病毒攻擊，確保數據信息安全，同時數據庫中信息的更新速率也能夠達到使用需求標準。數據庫建立是基于編程技術基礎上來開展的，對于一些技術性問題，通過功能之間的協調使用，可以更好的避免出現技術性問題，同時在軟件工程投入使用后最大限度的利用數據庫資源，在網絡環境中也能夠實現軟件的自動更新檢測。建立過程中要選擇適合的程序匯編語言，通過語言來完成功能框架編寫，選擇適合的匯編語言，針對不同的功能模塊也可以做出區分，這樣可以更好的幫助提升設計效果。
3對數據庫文件的應用
3.1面向對象的數據庫存儲模式選擇
數據庫存儲模式選擇，需要在分區后進行，存儲功能中可能會出現不同程度的功能隱患問題。這種數據庫存儲模式選擇也是對用戶訪問權限的定義，在軟件使用過程中，為確保內部重要信息的安全性，會對用戶的訪問權限進行定義，這樣不同級別的用戶所能夠登陸到的界面也存在差異，數據庫信息也都得到安全保障。基于文件類型選擇基礎上所進行的文件訪問，也更高效合理，實現上述功能在程序編寫期間要重點設計，根據所存儲的信息類型來對數據庫做出選擇，避免出現更深層次的問題，并幫助合理優化資源，利用過程中達到更理想的效果。不同資源在使用時需要根據所接收到的指令來調動數據庫內部信息，實現資源利用方面的優化。
3.2數據庫文件的加密保護
文件加密保護主要是針對基礎信息來進行的，這部分信息關系到使用者的個人隱私，一旦泄露會造成嚴重的影響，因此在所開展的數據庫文件加密保護中，要根據不同信息的重要程度來設置等級，采用登陸口令以及密碼加密的形式來進行保護，登陸到數據庫文件內部需要輸入相應的加密密匙，這樣工作人員可以根據常見問題來探討解決加密措施，以免文件應用過程中受到網絡病毒的影響，造成數據庫使用期間癱瘓問題。對于文件加密期間的數據信息選擇，通過各個系統之間的文件加密選擇，如果出現功能方面的沖突問題，可以通過系統的框架結構優化來達到更理想的優化使用模式。為各個系統之間的功能優化創造有利環境。
3.3數據存儲模式使用方法比較
存儲功能使用性能是否穩定，要從使用方法對比過程中來進行探討，觀察運行狀態下的軟件是否存在功能不穩定的現象，并從技術性角度來深入探討預防措施。設計期間的功能選擇直接關系到后續網絡訪問所選擇的形式，以及工作任務開展期間可能會遇到的相關問題，幫助提升系統投入使用后的功能穩定性，通過這種工作模式上的創新利用，可以幫助避免網絡環境中軟件使用受到計算機病毒的入侵，并最大程度的保護數據庫中信息的安全性，對于一些比較常見的技術性問題，對于這種配合方法的選擇也能夠達到更理想的運行效果。系統在運行過程中會對所接收到的信息快速篩選，將其中的有用信息進行歸類，這樣可以根據使用需求快速的調動數據庫內的信息，軟件投入使用后也可以根據操作需求對功能進行更新處理，這種方法的實現也需要各個系統之間的相互配合。對存儲模式進行對比，觀察其中所存在的問題，更有利于下一階段軟件功能設計的實現。
3.4開發設計中的編程技術選擇
編程技術選擇過程中，要以軟件功能的穩定性來進行探討，觀察在系統設計中對資源的利用是否優化，以及可能會出現的功能不穩定現象。針對比較常見的系統功能問題，在編程階段的技術選擇可以采用對比的方法來進行，觀察系統功能的穩定性，發現數據傳輸不準確的現象要及時采取解決控制措施，預防軟件的功能出現大面積癱瘓，影響到正常工作使用。程序檢測工作開展也是針對這些技術選擇問題來進行的，對所開發設計出的軟件進行穩定性檢測，為系統的運行創造出安全適合的環境，在這樣的環境下才能夠解決運行穩定性問題，并達到系統需求的工作環境。軟件功能穩定性與編程技術的選擇之間有很大關系，因此在選擇編程方法時要考慮是否可以解決這一技術優化利用的問題。開發初期階段出現問題可以重新優化基礎框架結構，這樣后續的建設計劃也可以順序開展，在這樣的環境下，計算機程序匯編面臨著功能實現與網絡環境安全防護的雙重任務，實現各項工作任務也是十分復雜的。
1.建立學籍檔案數據庫使學籍檔案的管理效率、檢索速度和查準率有了明顯的提高。面對日積月累的檔案，沿用傳統的手工目錄查詢檔案已經不能適應形勢的要求，傳統的案卷目錄檢索點單一，不支持模糊查詢，檢索起來費勁費時，而且查全率和查準率很難得到保障。以復旦大學1960年以后形成的學生學籍檔案為例，如本專科生的學生成績表、畢業生登記表，不以個人為單位立卷的，而是以年度、院系或專業為單位裝訂成冊，學生的學籍變更如休學、退學、復學、轉學不能在案卷目錄上體現出來，這樣難免會降低檔案的查準率。我們將學生的個人信息輸入計算機，建立學生信息數據庫，只要定義任一檢索條件或組合查詢，即可迅速準確地篩選出符合條件的記錄。
2.采用學籍檔案數據庫管理緩解了檔案保存與利用之間的矛盾。學籍檔案的形成年度跨度較大，尤其是具有百年歷史的高校，學籍檔案對于研究高校教育史具有重要的參考價值，而檔案不同于一般的歷史文物，具有記錄性和原始性的特點，隨著社會的發展，學籍檔案的利用率在不斷提高，檔案的破損速度也在加快，這樣就產生了學籍檔案“保存”與“利用”之間的矛盾。將學籍檔案原文數字化，存入數據庫，不僅可以解決“保存”與“利用”的矛盾，而且還大大提高了查檢速度。
3.學籍檔案數字化是檔案信息上網的基礎。網絡化已成為時代的主旋律，網絡技術的應用更推動了檔案事業邁上新的層次。檔案信息是重要的信息資源，檔案信息只有上網才能體現它的價值，才能為更多人所利用。大量的檔案信息寓于紙質的案卷、文件之中，雖然電子文件已經達到相當程度的普及，但大量較早時期形成的檔案都還是紙質的，這是檔案信息上網的一大障礙。只有將這些紙質檔案轉化為電子文件，才能真正成為電子信息。
2、建設學籍檔案數據庫
1.學生信息數據庫的基本結構
學生信息數據庫由10個輸入字段組成，分別是：學號、姓名、字、號、籍貫、院、系、專業、入學年月、畢業年月，同時，這些字段又是多途徑組合查詢的檢索入口。
我們用Access2000來開發學籍檔案信息管理系統，Access是一種關系型數據庫，它為用戶提供了數據庫管理的工具集和應用程序開發環境，是中小型數據庫應用領域中最通用的數據庫軟件。由于Access數據庫和VB(VisualBasic)語言結合得比較好，對于數據庫開發人員，利用VB語言以及Access數據庫提供的可視化工具和向導，便可以設計出具有一定規模、功能強大的數據庫應用系統。Access還具有數據訪問的功能，可以創建用來添加、編輯、查看、處理學籍檔案數據庫當前記錄的Web頁，也可以通過電子郵件發送數據。
2.制作掃描文件
采用掃描錄入方式將學籍檔案按原貌逐頁存儲為圖像文件，學籍檔案原件有5項基本內容：畢業照、學生學籍表、分年課程學分表、畢業資格審查表、中學畢業證書，以學號作為文件名標識，例如某人學號為13561，那么他的掃描文件分別為13561a、13561b、13561c、13561d、13561e，依次類推。
計算機圖像文件的格式很多，常見的圖像格式有：BMP、JPEG、TIFF等，使用上各有長短。不同的格式其文件大小、打開速度、支持顏色、壓縮耗損等參數均不相同。BMP格式的圖像沒有壓縮、最能體現實物的原貌，大多數瀏覽器如IE、Netscape等都支持這種格式。然而其文件大，占用系統資源最多，打開速度慢，特別是在網絡上傳輸時，其打開和下載速度更難適應要求。因此在圖像格式的選擇上必須考慮Web圖像的要求。JPEG格式的圖像壓縮比例大，圖像文件做得小，網絡下載速度也最快，支持顏色也多。TIFF格式的文件適合做動態圖形，但是色彩層次的還原性比較差。所以，建設大量圖片形式的掃描文件庫選擇以*.JPG格式保存比較好。
經過比較和測試，用100dpi的掃描分辨率掃描的圖像在清晰度和文件大小之間達到較好的平衡。
3.學籍檔案數據庫系統的設計
對所有的掃描文件編制目錄索引，目錄索引用數據庫方式建立，每一圖像文件以其存儲地址與其在目錄索引中的記錄相鏈接。利用目錄索引可檢出所需檔案之圖像文件的存放地址，通過地址借助鏈接顯示該檔案原文的圖像。
我們設計的復旦大學學生學籍檔案信息管理系統由數據庫文件，掃描文件，超文本文件及程序文件組成。分別開設四個子目錄存放這四部分的文件。
數據庫文件即學籍信息數據庫，由手工錄入的學生信息組成，一人一條記錄，是檢索的依據，也是鏈接的基礎。
掃描文件即學籍檔案的原文掃描件，由于數量多，必需用一個大容量的硬盤來存放，為了保證數據的安全，還應分期分批進行數據備份。
超文本文件即*.html文件，通過程序生成，通過學號建立超文本鏈接。
程序文件由輸入界面、查詢界面組成，并分別嵌入IE控件。程序啟動后，歷讀學籍檔案文件夾中的掃描圖形文件，依學號自動編寫相應的HTML文件，供輸入、查詢中的瀏覽器閱讀。
系統采用先掃描后輸入的方式。在輸入界面內，選擇學號，程序調用對應的HTML文件，瀏覽器顯示對應學籍表，依據學籍表輸入相關信息，使數據庫的輸入工作簡潔直觀，可方便完成數據的保存、編輯和打印等工作。
在查詢界面內，可按各字段進行獨立或組合檢索，并在網頁內給出結果集合。點擊學號，瀏覽器給出該學生的全部檔案資料。并可直接打印，郵寄各文件。
3、建設學籍檔案數據庫的難點和解決辦法
1.學籍檔案具有原始性的特點。雖然文檔一體化管理在信息系統技術上已逐步走向成熟，但是大量歸檔后的文件卻不能做到全部數字化。自動文字識別軟件OCR技術的應用大大提高了數字化的效率，但是這種軟件要求印刷體的規范化文字，而對歷史檔案原始資料中大量形形的手寫字體很難識別。由于時代所限，早期形成的歷史檔案都是紙質的，這也是實現檔案數字化的瓶頸。所以，通過掃描技術，將原始的學籍檔案材料，轉換為圖像文件存儲在計算機中，是一種比較現實可行的辦法。通過學籍檔案數據庫可以快速調用原文數據庫即掃描文件庫中的文件，也省卻了調卷的繁復。
2.學籍檔案材料不統一。學籍檔案是散頁的，各種材料大小不一，有些材料甚至有缺損，在掃描時需要對有殘缺和破損的照片在進行修補，我們可以用圖像處理技術對掃描的圖像文件進行加工，使之達到滿意的效果。
一、實驗情境設計
某小型企業已建立采用B/S結構設計的銷售管理系統，其后臺數據庫名稱為example，products表和orders表是example數據庫中的兩張表。要求用戶a～e能登錄數據庫服務器并按照設計的訪問控制權限訪問相應的服務器及數據庫資源，訪問用戶及權限設置如表1所示：表1用戶及訪問權限設置表
二、實驗技術分析
本實驗主要實現在SQLSERVER中對數據庫安全性的管理問題。首先明確SQLServer中身份驗證的種類和實現步驟，然后再熟悉為用戶分配登錄賬號和權限的操作方法，對于SQLServer安全性的各種管理，尤其是對數據庫訪問控制操作有深入要求。要管理數據庫安全性，必須了解各種賬號和權限，因為安全性就是通過它們的分配來實現的。所以掌握它們的區別和用處非常重要。（一）SQLSERVER身份驗證模式SQLSERVER身份驗證模式指SQLSERVER如何處理用戶名和密碼的問題，SQLSERVER提供兩種身份驗證模式。1、Windows身份驗證模式，在這種方式下，用戶只可以使用Windows身份登陸連接到SQLServer，由Windows操作系統對客戶端進行身份驗證。我們知道，SQLServer和Windows同屬于微軟公司的產品。當使用Windows身份驗證連接到SQLServer時，SQLServer使用Windows操作系統中的信息驗證賬戶名和密碼，用戶不必重復提交登錄名和密碼。這種驗證方式的弊端在于若采取B/S結構服務器，遠程客戶機無法連接到服務器，這時須使用混合驗證模式。2、混合驗證模式，即可以同時使用Windows身份驗證和SQLServer身份驗證。使用具體驗證方式取決于在最初通信時使用的網絡庫。如果一個用戶使用TCP/IP進行登錄驗證，則使用SQLServer身份驗證；如果用戶使用命名管道，則登錄時將使用Windows身份驗證。[1]圖1SQLServer安全性決策樹通過以上兩種身份驗證模式，用戶如果想使用指定的登錄名稱和密碼連接到SQLServer，SQLServer會按照圖1所示的安全性決策樹進行安全身份驗證。本實驗中要實現在采用B/S結構設計的銷售管理系統中讓不同的客戶端用戶能訪問服務器的數據庫資源，所以身份驗證模式可以設置為“SQLServer和Windows身份驗證模式”。（二）賬號和權限1、登錄帳戶登錄賬戶是讓用戶登錄到SQLServer服務器中用的賬號，如果用戶不能登錄SQLServer的服務器，也就不能訪問該服務器上的數據庫資源。在實驗中，需要創建登錄帳戶logina～logine，讓這些帳戶都能登錄數據庫服務器。2、數據庫用戶一個SQLServer服務器下面可以建多個數據庫。能登錄到SQLServer服務器，不一定能訪問到服務器中的數據庫。在實驗中，需要創建數據庫用戶userb～usere，使這些數據庫用戶都能訪問sample數據庫。3、角色為了便于管理數據庫的的權限，SQLServer提供了若干“角色”，“角色”就是用一種方法來把用戶集中到一個單元中，并在此單元上應用權限。SQLServer提供了預定義的服務器角色和數據庫角色，也可以在數據庫中創建用戶自定義的數據庫角色。在實驗中，用到如下兩個固定的服務器角色和數據庫角色：sysadmin固定服務器角色的成員可以在數據庫引擎中執行任何活動。db_backupoperator固定數據庫角色的成員可以備份數據庫。由于本實驗中用戶a需要訪問控制全部服務器資源，即用戶a要求完全的數據庫服務器訪問權限，所以用戶a應設置為固定服務器角色sysadmin的成員之一，使之成為服務器的超級管理員。用戶a的安全訪問流程如圖2所示。圖2用戶a安全訪問流程用戶b要能備份數據庫，可以將其添加到數據庫角色db_backupoperator中，用戶b的安全訪問流程如圖3所示。用戶c與用戶d都要訪問數據庫中的表，所不同的是具體的訪問對象及訪問權限，在實驗中可以創建兩個自定義的數據庫角色R1和R2，將用戶userc、用戶userd分別添加到R1角色R2角色中。4、權限在為用戶和角色分配登錄帳戶后，還必須為他們分配權限以增強數據庫的安全性。權限詳細地說明了可以讓用戶使用哪些數據庫對象，并可以對它們進行哪些處理。用戶在數據庫內的權限取決于用戶帳戶的權限和該用戶所屬的角色成員。在實驗中為R1角色授予查詢、修改products表的權限，為R2角色授予查詢orders表的權限，為用戶usere添加訪問products表、orders表的權限。用戶c～用戶d訪問數據庫資源的控制方式如圖4所示。圖4用戶c～用戶e安全訪問流程
三、實驗過程
該實驗需要每人PC機一臺，操作系統為Win－dowsxp或win7，實驗的數據庫管理系統軟件為SQLServer2005或SQLServer2008。請學生務必用每個用戶的身份進行登錄、比較操作以校驗數據庫安全訪問控制實驗過程的正確性。
四、實驗總結
摘要分析了幾種網絡計算模式的特點，針對客戶機/服務器模式設計了一個地理信息系統(GIS)訪問數據庫的結構框架——客戶端分為GIS功能層和數據庫請求層兩層，服務器存放數據，并將此結構與ESRI公司的空間數據庫引擎(SDE)作了對比；通過比較幾種數據庫訪問的程序實現方式，認為ODBCAPI在開放性方面是良好的.最后給出的MAPGIS實例表明：采用上述設計思路的應用系統不但利用了原有MAPGIS的研究成果，實現了GIS訪問網絡數據庫的功能，而且還具有良好的開放性.
關鍵詞地理信息系統，數據庫訪問，空間數據庫引擎(SDE)，C/S模式，ODBC.
引言
近年來，網絡技術得到迅速的發展，這就為信息資源的共享提供了技術上的可能.作為信息密集型的地理信息系統(GIS)上升到網絡平臺可謂適逢其時.但從目前的應用情況來看，除了國外極少的公司擁有網絡版的GIS之外，在國內還處于試驗研制的階段.因此，盡快地研制出我國自主版權的網絡GIS的原型和產品，并在技術手段上達到國際先進水平，是擺在我們面前的一項迫切的任務.
1網絡計算的幾種模式及特點
(1)傳統的集中式.這是一種主機-終端模式，所有的計算任務和數據管理任務都集中在主機上，終端只是主機輸入/輸出設備的延長.這種模式的優點是容易管理，缺點是對主機的性能要求很高，也浪費了作為終端的計算機的計算能力，并且從性能價格比來看，在購置費用相當的情況下，一臺主機的性能往往比不上幾臺計算機所組成網絡的性能；因此這種模式已逐漸退出主流.字串5
(2)客戶機/服務器(client/server，簡稱C/S)模式.一般說來，在這種模式下，服務器只集中管理數據，而計算任務分散在客戶機上，客戶機和服務器之間通過網絡協議來進行通訊.客戶機向服務器發出數據請求，服務器將數據傳送給客戶機進行計算，計算完畢，計算結果可返回給服務器.這種模式的優點充分利用了客戶機的性能，使計算能力大大提高；另外，由于客戶機和服務器之間的通訊是通過網絡協議進行的，是一種邏輯的聯系，因此物理上在客戶機和服務器兩端是易于擴充的.它是目前占主流的網絡計算模式.
(3)瀏覽器/服務器(browser/server)模式.在這種模式下，用戶端只需一通用的瀏覽器，如Netscape或Explore，便代替了形形的各種應用軟件.服務器則為Web服務器.瀏覽器和服務器之間通過TCP/IP這一通訊協議進行連接.瀏覽器發出數據請求，由Web服務器向后臺取出數據并計算，將計算結果返回給瀏覽器.這種模式的優點是：由于用戶端所用軟件只是一個簡單的瀏覽器，用戶基本上無需培訓，用戶端軟件也無需維護；軟件的升級與修改只在服務器端進行，對用戶透明；服務器與瀏覽器可處于不同的操作系統平臺.其缺點為：Web動態技術不夠成熟，各種標準有待統一，如各廠家的動態協議互不支持、瀏覽器之爭等.總之，它是一種先進的但發展還未成熟的技術.字串4
基于以上的分析，應選擇客戶機/服務器模式作為GIS訪問網絡數據庫的實現模式.
2C/S模式下的GIS訪問網絡數據庫的結構設計
設計在總體上分為C/S兩層(見圖1)，以充分利用C/S模式的跨平臺、易擴充、數據獨立等優點.在client端又分兩層來進行設計——GIS功能層和數據請求層，GIS功能層是GIS的功能實現部分，數據請求層是GIS的數據實現部分.數據請求層作為一中間層，起到數據轉換的作用，對上是具有GIS特點的數據文件，對下是標準的數據庫記錄.這種分層設計的形式一方面充分利用了現有的單機版本GIS研究成果；另一方面，GIS功能層和數據請求層的開發可同時進行，只要接口標準不變，本層的變動不會影響到另一層.
Fig.1ThegeneralframeworkofGISaccessingdatabasebasedonC/Smodel
值得一提的是ESRI公司的空間數據庫引擎(spatialdatabaseengine，簡稱SDE)的設計方案(見圖2).它是目前國際上領先的GIS數據處理的網絡計算模型.其數據的訪問形式為：由用戶的應用程序(userapplication)通過SDE應用編程接口(SDEAPI)向SDE服務器提出空間數據請求，SDE服務器內存放有空間對象模型，并依據空間對象的特點在本地完成空間數據的搜索，并將搜索結果通過網絡向用戶的應用程序返回.字串2
對比圖1和圖2可以看出兩者采用的都是C/S模式，并且都將GIS功能實現與數據請求進行分層處理；所不同的是面向數據庫的數據請求實現的位置：圖1
在客戶機端實現，圖2在服務器端實現.在服務器端實現的主要優點為：(1)對于空間對象模型及相關的計算模式的升級可以只在服務器端實現，而且對客戶機端透明；(2)由于SDE服務器與數據庫ORACLE7.2的結合非常緊密，因此數據的搜尋速度非常快.對于圖1來說，把數據請求層放在客戶機端，對數據庫的依賴程度就不同于SDE服務器，后者對數據庫的選型有極強的依賴性(目前SDE服務器只在ORACLE7.2實現)，相反，它是一種非常開放的結構，它所支持的服務器不但可跨數據庫系統平臺，而且還可跨操作系統平臺.可以說，圖1和圖2兩種設計模式的優缺點是相互對應的.
3數據庫訪問方式的比較
基于程序的訪問數據庫的幾種方法如下.
(1)專用的數據庫訪問工具.如PowerBuilder，Delphi等，它偏向于對數據庫中數據的管理和顯示，具有限的計算功能.既不適于用它來開發GIS應用系統，也難以將它們的數據操縱功能與現有的GIS應用系統緊密結合.
(2)嵌入數據庫語言的常規語言.各數據庫廠家為了讓用戶程序能直接訪問自已的數據庫，基本上都提供了專有的面向C語言的預編譯頭和靜態庫，如Sybase公司的OPENCLIENT和ORACLE的PRO*C.字串5
(3)開放數據庫互連性應用編程接口(opendatabaseconnectivityapplicationprogramminginterface，簡稱ODBCAPI)［2，3］.它是微軟(Microsoft)公司提出的數據庫訪問形式.它通過確保所有的應用系統遵循標準的調用層接口，提供對特定數據源命令進行解釋的驅動程序來保持應用系統的互用性.這樣的應用系統是開放的，只要有相應數據源的ODBC的驅動，它就無需改變代碼而可訪問相應的數據庫.
在確定訪問數據庫的方式時，ODBCAPI的開放性的優勢是不言而喻的，但這種方式在效率上不如第二種訪問形式.應說明的是：ODBCSQL語法分為3層，即最小層、核心層和擴展層，盡管目前的大型數據庫都能支持到擴展層，但為了保證應用系統的開放性，在具體編程實現時，盡量只使用最小層和核心層的語法.
4某電信局配線系統的實現
客戶機為MAPGIS/ODBC/WINDOWS95，服務器為SQLSERVER/WINDOWSNT，要訪問的相關表中記錄約為13萬條.要求從地理底圖上選中某一DP，在數據庫中尋找出從這一DP到配線架的可用通路，并在數據庫中作相應配線修改.如圖3所示.結果表明：(1)程序實現了MAPGIS訪問網絡數據庫的功能；(2)客戶機和服務器均為PC機(主頻166MHz)，每次操作反應時間為數秒，換機觀察，發現服務器的性能是整個網絡計算的瓶頸.
字串8
5結論
(1)C/S模式為目前網絡平臺GIS的首選，將GIS功能與數據庫訪問分層實現有利于保護現有的開發成果；(2)將數據請求層放在客戶端和以ODBC作為數據庫的訪問方式保證了應用系統的開放性，其訪問可跨越數據系統和操作系統平臺；(3)實例表明，應用系統的反應速度更多取決于服務器的性能，而不是ODBC的效率.
參考文獻
1/base/common/userconf/proc96/TO100/PAP094/P94A.HTM.1998.4
關鍵詞：古典文獻數據庫 公共古典文獻數據庫 文獻檢索服務系統
計算機技術的飛速發展，為古典文獻研究的現代化提供了堅實的基礎，其貢獻是有目共睹的。然而，計算機技術在古典文獻研究中的運用仍然存在著極為嚴重的缺陷也是不容回避的。筆者近幾年來主持并直接參加設計“e書庫”數據庫的過程中，感到有必要將自己的一些想法提供給正在設計有關軟件的計算機專業人員、愿意使用該類軟件的專家學者們參考。
一、我國古典文獻數據庫建設的歷程
自古以來，歷代學者對古典文獻整理與研究一直沿襲手工操作的方式，然而自上世紀80年代后，計算機技術開始涉入到古典文獻研究中，對傳統的古典文獻整理與研究方法（自然也對一切需要使用古典文獻資料的專業研究）起到了極大沖擊。
首先簡單回顧一下計算機技術在古典文獻研究領域內發展的歷程。上世紀80年代初，我國一些圖書館、大專院校及科研機構陸續開始大規模地利用計算機設計并建立數據庫。大致說來有兩類數據庫，一類是書目數據庫，一類是文獻數據庫。南京圖書館于90年代初率先建立書目數據庫，對讀者檢索有關書目起到了極大的幫助。之后，各地圖書館紛紛效尤，類似的書目數據庫很快就普及了。雖說至今各地圖書館的書目數據庫的檢索方式，仍存在機讀編碼格式不統一的問題，然而書目數據庫提供的方便快捷的查詢功能，對讀者來說無疑是一件大好事，具體到學術研究來說，至少為研究者提供了一個比較方便的查找有關古典文獻的實用工具。
在建立書目數據庫的同時，一些大專院校與科研機構開始研發各自的文獻數據庫。從數據制作格式來說，大致可以區分為兩類，一類是圖像格式，即將按原著內容掃描成PDF圖像文本，另一類是元數據格式，即錄入文獻文本內容（或掃描并轉化為電子文本）導入數據庫，并轉換成可閱讀與檢索的數據庫機讀格式。一般說來，無論是PDF格式還是元數據格式，它們數據庫容量都較大，也提供了較為原始的檢索方式，為學術研究提供了不小的幫助。從上述兩類制作格式的數據庫來說，PDF圖像文本可以直接閱讀圖像文字，但總體說來不太適應古典文獻整理與研究的需要。而元數據格式較為精致，初步具備了較為方便的常用的功能，可以檢索、作卡片等等。
古典文獻數據庫從收錄的文獻內容來說，大致可以分為兩類：一類是類目數據庫，即按“類”收錄有關圖籍，如經學類、史學類、文學類以及甲骨文、金文或出土文獻資料、石刻資料等等，另一類是綜合數據庫，如《四庫全書》、《四部叢刊》、《國學寶典》之類數據庫。
大陸最早的古典文獻數據庫是河南大學的《宋人筆記檢索系統南宋主要歷史文獻》，建立于1987年。之后，各種數據庫紛紛涌現，比較重要的有南京大學、河南大學、蘇州大學聯合研制的《計算機甲骨文信息處理系統》、中國社會科學院《全唐詩》、《先秦魏晉南北朝詩》、《全上古三代秦漢三國六朝文》、《十三經》、《全唐文》、《諸子集成》等數據庫、北京大學《全宋詩》數據庫、南京師范大學《全唐五代宋詞》數據庫、四川大學《宋會要輯稿》數據庫（與海外合作）等等。港臺古籍數字化起步較早，均采用繁體字形式。1984年臺灣中央研究院歷史語言研究所開始研發《漢籍全文資料庫》，香港中文大學則有《漢及以前全部傳世文獻》、《魏晉南北朝全部傳世文獻》、《竹簡帛書出土文獻》數據庫等等。其中《竹簡帛書出土文獻》收錄《馬王堆漢墓帛書》、《武威漢簡》、《睡虎地秦墓漢簡》、《銀雀山漢簡》、《居延漢簡釋文合校》及其它散見簡牘共140多萬字的竹簡帛書出土文獻，價值頗高。
值得注意的是，這些數據庫主要是提供給本單位研究人員使用的，當然也有部分數據庫對外開放，為其他研究者提供一定幫助。雖然這些數據庫有種種限制，但它們無疑為古典文獻的研究（當然包括其它專業的學術研究）提供了方便。之后，隨著網絡技術的發展，各科研機構、大專院校、各地方的圖書館、以及其它數以百計的網站向用戶提供收費或不收費的古籍文獻檢索服務，甚至還提供古籍文獻的下載服務。顯然，這些工作的開展，為學術研究的現代化提供了極為有力的支持。至今為止，據筆者所查索到的除科研機構、大專院校、各地圖書館數據庫之外，提供各種文獻下載的中文網站至少在200個以上，其中就有不少古籍文獻下載的網站。這些古典文獻數據庫或有關網站的建立，確實為古典文獻整理與研究乃至其它學術研究提供了極有價值的幫助。
二、目前存在的問題
當然，我們也應該清醒地看到，在古典文獻數據庫大量涌現的同時，一些潛在的問題與數據庫本身的缺陷嚴重地制約著古典文獻數據庫的正常發展。
從古典文獻數據庫技術發展角度來說，筆者認為大致經過三個發展階段。第一階段是PDF圖像文本數據庫，其數據來源主要是以掃描方式獲得，形成PDF圖像文本。這種圖像文本優點是直觀，與原書分毫不差，但它的缺點是功能極其單一，僅可供瀏覽圖像和簡單地檢索書目。雖然第一階段的數據庫功能極少，但畢竟能方便而直觀地閱讀文獻了，因此引起了學者們廣泛的興趣。必須指出的是，由于功能太少，這類數據庫難以進一步發展。
第二階段是元數據數據庫，以香港迪志公司投資、書同文數字化技術有限公司設計、上海人民出版社出版的《四庫全書》、書同文數字化技術有限公司設計、萬方數據電子出版社的《四部叢刊》、尹小林《國學寶典》、南開大學永川公司的《二十四史》，以及大陸、港臺等大專院校或科研機構制作的較大型的數據庫為代表。它們的優點是具有較多的基本功能，如檢索、卡片、打印等功能，有些還附加了日歷查詢、字典、音樂背景等附加功能。然而，它們都不允許對數據庫內的文本錯誤進行修訂、沒有圖表處理能力、不提供功能升級服務（某些軟件提供所謂新版本，實際上只是增加一些文獻文本，并未真正提升軟件服務功能）。而且由于各自為政，開發者大都采取自定義方法來自造非常用的生僻詞，因此各種數據庫之間字庫不能相互兼容。這一階段的古典文獻數據庫也有吸收第一階段數據庫有圖像的優點，如上述提及的《四庫全書》就附有圖像，以利研究者核對文字。該階段絕大多數數據庫注意到版權問題，但仍有一些數據庫在版權上出現較大問題，乃至引起法律糾紛。
計算機技術廣泛地涉入文科研究領域，各種古典文獻數據庫紛紛建立，當然給古典文獻整理與研究的現代化提供了極其有利的幫助，然而，在筆者看來，目前計算機技術在這一領域中的運用形成紛亂無序的“戰國時代”，有許多亟待解決的問題，否則將會影響或說削弱計算機技術在古典文獻研究（乃至其它學術研究）中巨大作用。對此弊病，筆者擬作一概述，企望引起有關部門、數據庫開發者及使用者的重視，以期真正使計算機技術對古典文獻整理與研究起到更大的促進作用。大致說來，主要問題有以下幾個方面：
其一，缺乏整體領導與規劃，國家投資與收益不對稱。當然，首先應該看到，國家有關部門已經著手做了一些規劃，也實施建立一些比較大的古典文獻數據庫，如2002年10月，國家科技圖書文獻中心受科技部的委托，牽頭聯合中國科技信息研究所、國家圖書館、上海圖書館、中科院圖書館、北京大學圖書館等單位，啟動了我國數字圖書館標準規范建設項目。這一項目的目的就是力圖建立我國比較統一和規范的數字圖書館標準，自然也會對建立古典文獻數據庫有較大的借鑒與參考的價值。又如北京大學《中國基本古籍庫》、上海圖書館《古籍影像光盤制作及檢索系統》等等，也由國家有關部門投入大量資金，而且已經啟動并完成了部分內容。不過也應該強調，由于國家沒有制定出一個比較符合國內數據庫發展狀況的真正有價值的規范體系，因此這些項目的承擔者仍是各自為政，數據庫之間并不能兼容，不可能形成技術“合力”。再從所取得的社會效益或說實際使用價值來看，也不盡人意。因為至今為止建立的各種數據庫仍人為地設置許多障礙，無法使它們實現較大的使用價值。數據庫由國家投資，收益自然應該歸國家，或者成為不收費的公益數據庫，但目前收益既不歸國家，又未能成為公益數據庫，這不能不說是個極大的遺憾。實際上，數據庫制作者無償利用國家投資進行了開發，制作完成后卻獲得相當豐厚的收益，使人感到有“國家投資，個別單位圖利”的印象。筆者不反對交納一定使用費用，但收費單位一定應該說明收費后去向，絕不允許產生國家投資而由個別單位乃至某些個人得利的情況。
其二，開發商嗜利忘義，數據庫錯誤嚴重。除上述由國家投資開發的古典文獻數據庫外，還有一些有一定技術實力的軟件開發商加入到古典文獻數據庫的開發中來了。比較而言，各科研機構、大專院校及各地圖書館建立的古典文獻數據庫質量較高，而開發商則很少關注數據庫中的文獻質量。我們承認確有少量開發商制作的數據庫質量較高，如迪志公司開發的《四庫全書》之類，然而象《四庫全書》這樣的數據庫確實鳳毛麟角，難以尋覓。我們發現，甚至有些開發商僅僅是把文本進行文字掃描導入，疏于校對，因此文本錯誤百出，難以卒讀。由于利益驅使，絕大多數開發商都以“獨自開發”為己任，數據庫設計相互保密，互不兼容，使用戶深感不便。這些問題已嚴重地影響到古典文獻數據庫的正常發展了。
其三，熱門文獻數據重復，冷門文獻數據罕見。雖說目前數據庫品種繁多，但由于考慮到使用者對文獻內容的需求，因此許多開發者熱衷于開發那些熱門數據，而一些比較冷門的文獻則鮮有人問津。實際上，冷門的文獻并非是沒有學術價值的文獻，只是使用人較少而已。因而，目前不但數據庫中文獻內容重復現象極為普遍，甚至同名同姓的數據庫也有不少，如《四庫全書》就出現了武漢大學版、上海人民出版社版等數種不同版本。且不說那些數量繁多、質量也不甚高的數據庫浪費了多少人力物力，其實也使用戶陷入無可適從、欲舍不能的境地。用戶往往為了某些少量文獻內容不得不購買和安裝整個數據庫操作系統，而且這些龐大的數據庫大量占據硬盤空間，導致計算機運行速度大為減慢。而那些允許網上檢索的文獻數據庫又往往容量極大，上網檢索者多，導致“交通阻塞”！
其四，技術關卡重重，難以互相兼容。各開發者既鑒于不同開發目的與技術條件，又為防止他人解密，因此在開發過程中在數據庫某些程序中人為設置技術障礙，以保障自己利益不受損害。自然，開發者需要投入大量人力物力，保障本身利益不受損害是無可非議的。然而也由于人為地設置了障礙，卻使各種文獻數據庫之間不能兼容，無法形成合力，先進的技術反而成為技術壁壘。實際上，這一情況大大浪費了寶貴的人力資源與財力，對古典文獻的開發與利用有百害而無一利。另外，由于技術壁壘，在古典文獻數據庫的文字方面更導致許多問題。我國古籍常用漢字大約為4萬余個，這還不包括超過2萬個異體字及數千甲骨文、金文等古文字。然而我國目前在計算機上采納的國標字庫(GB)和擴展字庫(GBK)，兩者相加也只有27000余字，這與我國古籍常用漢字數量相比，實在差距太大。因此，如此小的字庫與需求相比確實是捉襟見肘。為了彌補這一缺陷，一些軟件設計者就采取在自定義區自造字（乃至占據字庫中擴展B的位置）、有些也用圖片方式來填字。而這些自造字、圖片字，拷貝到WORD文本之后，由于內碼位置的差異就變成其它字了，從而導致文本錯誤。
其五，功能單調，難以真正為科研服務。建立較早的古典文獻數據庫功能比較單調，只能做些簡單檢索、拷貝，沒有更為先進的功能，不能適應學術研究的需要。后來的一些古典文獻數據庫也存在類似問題，例如《四庫全書》的檢索功能，雖說可以采用添加“作者”、“書名”等限定條件，但檢索結果只是羅列一排出處，無法直觀地了解檢索到的具體內容。而且《四庫全書》也沒有提供更多的功能給用戶，因此這一巨大的工程仍遠遠不能滿足用戶的需求。況且這一數據庫目前已經“定型”，不再繼續開發，使用戶對此深感遺憾。而其它古典文獻數據庫設計者的思維大多仍停留在“文本之爭”當中，重復著原來設計思想的錯誤，沒有更多地開發為科研服務的有效功能，因此在筆者看來，這一做法顯然不可能真正擺脫古典文獻數據庫目前面臨著的困境。
其六，學術圈地，使人心有余而力難用。解放后，一些國家級出版社化費了極大的精力，組織專家點校了不少重要古籍，為學術研究的發展作出了極大貢獻。然而時至計算機時代的來臨，卻出現了“版權”的問題。一些制作者忽視了國家有關版權法規，直接利用了一些出版社的成果來牟取經濟利益，理所當然地會產生版權糾紛。筆者以為，保護版權是每個學者乃至每個公民應盡的責任，根本毫無討價還價的余地。然而問題是，現在一些出版社由于各種原因，沒有對自己已出版的點校過的古籍進行開發，而愿意開發這些古籍資源者卻無法涉入其中，導致他們處于既想開發這一寶藏又無法回避版權問題的尷尬境地，這就使眾多需要使用者望洋興嘆。如果有關出版社不愿授權，那么想要開發這些古籍者只能返回到沒有標點的原始文本中去。這種情況確實使每一個希望使用古典文獻數據庫的用戶感到極其失望，而且嚴重影響了古典整理與研究的現代化進度。
上述種種現實情況，已經是制約計算機技術對古典文獻整理與研究支持的瓶頸了，如果不解決這些問題，計算機技術即使再發達，恐怕也難以對古典文獻整理與研究予以真正意義上的支持與幫助。
三、如何解決古典文獻數據庫存在的問題
古典文獻數據庫存在的問題是十分明顯的，那么如何解決這些問題，以利學術研究（當然包括文獻研究）的迅速發展？筆者以為現在應該設計和開發出新一代文獻數據庫的軟件。按照筆者設想，這代軟件應該以建立能自由升級的公共古典文獻數據庫為目的，是一種以提供強大功能為主、徹底解決版權問題的數據庫，實際上是建立一個規模巨大的功能相對完善的學術研究資源庫。所謂公共古典文獻數據庫是綜合性數據庫，只能由國家有關部門作為主要規劃者，它應該盡可能地包羅我國傳世古典文獻、碑刻資料和出土文獻等。在此基礎上允許建立適應每個研究者研究范圍的個性化的文獻檢索服務系統。個性化的文獻檢索服務系統是指每個具體研究者所擁有的安裝在各自計算機上的文獻檢索服務系統，它擁有一定數量的適合自己研究的范圍的古典文獻文本。其實，各個研究者并不需要一個“包羅萬象”的規模極其巨大的數據庫，即使象占據6至7個G硬盤的《四庫全書》，具體到一個研究者真正需要的內容并不是全部，而是其中一部分內容。
問題的關鍵在于公共古典文獻數據庫與個性化文獻檢索服務系統兩者之間的技術“契合”，即兩者互相兼容的程度。公共古典文獻數據庫應該與個性化文獻檢索服務系統有所區別，公共古典文獻數據庫應該側重于文獻數量的完善、完備，而個性化文獻檢索服務系統則應該考慮其功能強大。因此，從本質上說，公共古典文獻數據庫應該是一個統一的設計比較周密、與其它個性化數據庫在技術上能實現良好兼容的的數據庫；而個性化文獻檢索服務系統應該是“百花齊放”式的但必須能與公共古典文獻數據庫兼容而非各自為政的小型數據庫。兩者關系是源與流的關系。鑒于此，筆者以為目前應該從兩個層次上來解決問題，一是盡快建立公共古典文獻數據庫；一是繼續開發個性化文獻檢索服務系統。
根據筆者近幾年的實踐，感到要解決這些問題并非不可能的。其實只要認真對目前計算機技術在古典文獻整理與研究中存在的問題作一分析與梳理，重點突破一些瓶頸問題，應該說是能解決上述這些問題的。那么怎么才能突破上述這些瓶頸呢？筆者以為以下幾個方面是值得考慮的。
其一，加強總體規劃，建立公共古典文獻數據庫。作為一個具體單位來說，誰也沒有可能建立一個包羅萬象的古典文獻數據庫，因此，這只能由國家有關部門組織人力物力來完成。其實，就目前來說，國家投入資金并不少，但由于制度原因，只是向某些重點院校或科研單位、向重點項目投入巨資，而這些單位建立起各自為政的古典文獻數據庫、期刊數據庫，雖然也為學術研究作了一些貢獻，但不可否認的是，由于各自設計思路不同，相互之間不能兼容，已經妨礙到數據庫進一步發展了。以筆者愚見，國家有關部門應該主動負起責來，加強領導，重新考慮古典文獻數據庫的立項問題，組織力量、投入資金，真正建立起一個規模巨大、能為絕大多數研究者利用的公共古典文獻數據庫。同時也應該考慮所立項的古典文獻數據庫與其它數據庫（如現代文獻數據庫、當代文獻數據庫、期刊數據庫等）之間的兼容關系，只有這樣，或許若干年之后就能建立起一個價值極大的能真正為學術服務的公共古典文獻數據庫，乃至包羅一切文獻的數據庫。當然，就公共古典文獻數據庫來說，可以進行適量收費服務，但主要仍應該定位在“公益”上，不以“利”為主，這樣才能真正建立一個有價值的公共古典文獻數據庫來。
其二，數據庫內容與文獻檢索服務系統分離。這個問題與上述問題是緊密關聯在一起的，如果不能真正做到數據庫內容與文獻檢索服務系統分離，那么目前“列國紛爭”的面貌是不可能真正解決的。
我們知道，一個古典文獻數據庫實際上是兩大部分組成的，一是古典文獻數據庫內容，即數據庫所包括的文獻文本，二是對這些數據進行管理的文獻檢索服務系統。其實目前所見有關古典文獻數據庫都是“兩者合一”，即既包含一些文獻數據內容，又有具體的操作服務系統。事實上，這些古典文獻數據庫在功能上明顯存在缺陷的。就目前古典文獻數據庫管理形式來說，一是網絡管理，一是個人管理。前者是網絡數據庫，一般是單位所擁有的數據庫，即我們所說的網絡版，后者是安裝在個人電腦中的個人版。就功能來說，網絡版沒有必要具有卡片、文本修訂、書簽等個性化的功能，個人版應該具有做卡片、文本修訂、書簽、文獻管理等個性化的功能。就文獻數量來說，網絡版自然力求文獻內容豐富，盡可能包羅文獻文本，而個人版實際所需要的文獻數量是根據各自研究需要而定的，因而強行“規定”使用所有文獻內容并不值得肯定。就文獻內容來說，網絡版與個人版都應該允許不斷地增加其數據庫文獻內容，但不同的是，網絡版應該是只增不減，而個人版應該允許用戶根據研究需要自由增減文獻內容。
在筆者看來，應該從單純的文本內容競爭的思維中解脫出來，進入以文獻檢索服務系統競爭為主，文本竟爭為輔的體系，或許是解決古籍文獻數據庫的出路。也就是說，擅長計算機技術的開發者（開發商）應該注重文獻檢索服務功能的開發與完善，而具體文本的整理可由研究學術的專業人士來完成。這樣，開發者就可能開發出比較成功的文獻檢索服務系統，而數據庫中的文本也由于專業人士的加入而能大大提高文本的準確率，然后合成為一個規模較大的公共古典文獻數據庫。當然，輸入和整理古典文獻文本可以采用投標（或以申報項目形式）來確定，規定統一格式，要求保證文本的正確率達到一定比例，完成后再分別導入這一公共古典文獻數據庫中；經過若干年努力，最終能形成一個規模巨大、適應于學術研究的公共古典文獻數據庫。我想，采取這種措施不但節省了大量重復投資，真正做到人盡其才，物盡其用，而且一旦建立起這個規模巨大的公共古典文獻數據庫，可以解決了目前數據庫泛濫、文本錯誤太多、重復勞動等弊病，而且真正能做到廣大學者對古典資源“共享共有”。
在此基礎上，各個開發商可以力求開發學者們個性化的文獻檢索服務系統，它無須考慮文獻文本內容，但必須功能強大、操作方便，并與公共古典文獻數據庫完全兼容，學者們通過“購買”文本或其它方式來方便地組建自己的數據庫，這樣或許會給學術研究帶來真正的方便。
還須補充的是，我國的古典文獻中有大量表格與圖片，而由于技術原因，目前所有古典文獻數據庫都沒有導入原著的表格與圖片，極個別數據庫有少量圖片也是不能檢索，這是目前眾多古典文獻數據庫的重大失誤之一。其實只要真正化力氣去探索，這個問題是不難解決的。因為筆者曾作過設計并反復試驗，只要設計合理，圖片與表格不但可以導入數據庫，而且都是可以在數據庫中進行檢索。
其三，加速確定字庫方案，以利數據庫健康發展。當然，要真正解決公共古典文獻數據庫問題，還必須解決字庫問題。目前，國家雖然組織專家在論證有關字庫問題，然而由于進程不快，遠遠落后于當今計算機技術發展的需要。按照筆者的看法，應該建立一個以Unicode字庫為基礎的、適應漢語古籍需要的、并與國際接軌的真正有中國特色的字庫。這就需要抓緊工作，迅速落實擴展字庫B的內碼。同時根據我國漢字的具體特點，對自定義區域的6400字的內碼配置也應該有所規范，這樣才能使漢語字庫統一問題落實到實處。如果真能做到如此，那么就能真正解決目前古典文獻數據庫之間字庫互不兼容問題。
與字庫相關聯的是字體問題。古典文獻數據庫應該考慮到古代文獻對文字的特殊需要，筆者以為凡是古代文獻數據庫中的文本應該保留繁體字，以防繁簡不分而導致文義偏差。就目前計算機技術來說，解決這一問題是毫無困難的。其實用繁體字輸入文本早已不是問題，而掃描古籍文本再轉換成文字的技術也十分成熟，如北京書同文公司的“數碼翰林”OCR識別系統，應該說是極有價值的識別軟件，對絕大多數繁體文字能夠正確識別。如果能再進一步加以改進，使擴充字庫數量并與Unicode字庫兼容，那么古代文獻的文字識別問題是可以得到解決的。應該強調的是，古代文獻以繁體字導入數據庫，但應該允許在數據庫中自由進行繁簡轉換，換句話說，若需要使用繁體字時，文本可以保留繁體字，而需要簡體時，可以十分方便地轉換成簡體，這樣就適應用戶對繁簡體的不同需要了。
其四，徹底解決古典文獻版權問題。這是困撓計算機古典文獻數據庫建設的重要難題之一。自然，這一問題要真正得到落實確實存在相當困難的，因為版權保護工作任重道遠！不過，即使困難再大，古籍文獻數據化的發展的潮流是不可能停止的。筆者以為，有關出版社在維護自身法定的版權權益的前提下，應該從大局出發，在收取一定數量的報酬前提下，允許制作有關古典文獻的數據庫，以利學術研究的發展。至于報酬多少可以也應該實事求是地酌情商定，國家有關部門應該主動與那些出版社協調，亦可將目前大量分散投入到各課題中的資金中抽出部分來補償有關出版社，雙贏互利，以求突破版權瓶頸，早日解決這一棘手的問題。
與此相關的是古典文獻電子文本的版權問題，這也是個極難處理的問題。因為用戶若貪圖小利，版權意識不強，不愿化費代價使用電子文本，就容易產生“盜版”問題，如此就使得制作古典文獻電子文本者的正當利益大受損失。按筆者設想，如果真正能夠由國家有關部門主管古典文獻數據庫建設工作，那么就可以設想建立公共古典文獻數據庫規定導入數據庫的文獻文本都給予一個“統一編號”，沒有統一編號的文獻就不能直接導入公共古典文獻數據庫和個人使用的文獻檢索服務系統中，也就是說，個人使用古典文獻電子文獻必須化費一定的代價才能取得使用權，這樣就可以保證制作古典文獻電子文本者的一定收益，防止版權意識不強者侵權使用。同時由于古典文獻電子文本都有了統一編號，那么也就可以防止某一具體文獻文本重復錄入的問題。即使有部分重復，古典文獻電子文本也可以在用戶選擇過程中優勝劣汰。
其五，建立公平的交易平臺。建立龐大的公共古典文獻數據庫當然需要投入巨大的資金，而這種古典文獻數據庫自然不是每一個普通研究者購買得起的。在筆者看來，大專院校、科研機構應該在經濟允許的前提下購買有關數據庫，以供教學、研究之需。當然也應該允許個人在交納一定數量的經費后，自由上網使用這一數據庫，并允許購買（下載）一定數量的古典文獻文本，自行導入各自的文獻檢索服務系統，以利建立個性化的有實用價值的數據庫。如果真能做到這樣的話，那么就將會促進學術研究的迅速發展。
>> 基于Web的數據庫遠程自主實驗平臺 基于Web的遠程數據庫管理探究 基于 SQL Server的煤礦應急救援平臺數據庫研究 基于Web數據庫的考務管理平臺方案 基于Linux平臺Apache\PHP\MySQL數據庫的WEB商務系統設計 基于Web平臺的數據庫加密技術應用探究 基于PHP技術的基因數據庫Web平臺設計 基于Web數據庫的數據庫挖掘技術探究 基于Web數據庫的數據庫挖掘技術研究 淺談基于ASP的WEB數據庫訪問技術 基于XML數據庫的Web應用研究 基于數據庫應用的WEB結構分析 基于的WEB數據庫應用 基于Web的數據庫技術分析 基于WEB數據庫安全的訪問技術 基于WEB的數據庫訪問技術 基于Web的數據庫技術探究 淺談基于JSP的數據庫Web訪問技術 基于Web數據庫的安全問題探析 基于Web的數據庫技術淺析 常見問題解答 當前所在位置：
范茂魁.2009.制約特勤隊伍地震救援專業化發展因素及對策[J].消防科學與技術，28（3）：217-222.
何少林，李佐唐，姚子文.2006.甘肅省地震應急基礎數據庫管理服務軟件系統研制[J].西北地震學報，28（2）：149-153.
吉雍慧.2008.數字圖書館中的檢索結果聚類和關聯推薦研究[J].情報分析與研究， （2）：69-75.
雷秋霞，陳維鋒，黃丁發等.2011.地震現場搜救力量部署輔助決策系統研究[J].地震研究，34（3）：385-388.
李東平，姚遠，2009.浙江省地震應急基礎數據庫建設研究[J].科學技術與工程，9（9）：2474-2479.
劉紅桂，王建宇，徐桂明.2005.基于GIS的江蘇省地震應急基礎數據庫與震害快速評估技術[C]// 江蘇省測繪協會.2005數字江蘇論壇――電子政務與地理信息技術論文專輯.江蘇：《現代測繪》編輯部，10-12.
聶高眾，陳建英，李志強等.2002.地震應急基礎數據庫建設[J].地震，22（3）：105-112.
王東明.2008.地震災場模擬及救援虛擬仿真訓練系統研究[D].哈爾濱：中國地震局工程力學研究所.
王東明.2013.中國地震救援廢墟安全評估綜合管理系統[J].土木工程學報，46（2）：301-306.
【論文摘 要】分析了城市綠化管理的評價指標，在此基礎上分析了地理信息系統（GIS）在城市綠化管理中的作用，分別介紹了GIS、數據庫技術和.NET技術三種技術在城市綠化管理中的應用，最后提出基于信息管理技術的城市綠化管理的對策與建議。
城市綠地作為城市結構中的自然生產力主體，對城市系統和生態發展起著至關重要的作用，是改善城市生態質量，調節城市生態平衡的主要載體。我國城市綠地的破碎化程度很高，采取人工手段提前綠地信息的難度自然就變得非常大，運用信息系統對城市綠地進行規劃管理能夠推進城市綠地管理的現代化水平，提高綠地管理效率。城市綠化管理信息系統的減輕城市綠化的規劃設計、建設施工和養護管理等各項管理工作復雜程度的有效方式，同時能夠合理地利用人力、物力和財力等資源，提高城市綠化管理質量，實現科學管理。城市綠化管理信息系統為園林綠化管理部門提供數據信息，以便于統計部門進行規劃，實現內部管理標準化和城市綠化管理條理化。
一、城市綠化評價指標
城市綠化系統的概念仍在不斷完善中，與此同時，關于城市綠化的指標體系也在不斷調整和完善。國際上關于城市綠化的評價指標有很多，例如，聯合國在1996年提出市區公園綠地定額為60m2/人，而實際上，無論是在發達國家還是在發展中國家，很多城市都超過了這一指標。其他國家也都根據本國的實際情況提出了不同的城市綠化評價指標，我國基本建設委員會于1980年頒布了《城市規劃定額指標暫行規定》，確定了城市綠地定額近期3-5m2/人，遠期7-11m2/人，跟地區根據此指標也規定了本地區的綠地系統指標。
二、城市綠化信息管理技術
城市綠化信息涉及到大量的地理空間數據，因此對城市綠化管理與評價體系在技術方面提出了很大的挑戰，隨著信息技術發展，信息管理系統相關技術應用于城市綠化管理，較為明顯的是地理信息系統技術的使用，關鍵技術包括地理信息系統技術（GIS），數據庫技術和.NET技術。
（一）GIS技術
GIS最早出現在60年度，是從國外引進的一種數據管理技術，與傳統的分析方法相比，GIS將傳統分析方法中單一、靜態的數據進化為多數據源、多時相以及時空結合的綜合分析方式，能夠進行數據綜合和模擬分析，并且能夠得到傳統方法難以得到的重要信息，因此，這一技術已經應用到綠地管理的各個領域，成為各城市進行規劃的必要工具。目前，國際上大多數的GIS軟件公司已經把開發組件式軟件作為重要的發展戰略，因為組件式的GIS技術成為現在各城市進行城市綠化管理主要應用的信息管理技術軟件。國際上主要的組件式GIS商用軟件的分類包括MapObjects和ArcObjects。MapObjects 技術能夠實現人性化和清晰化的數據分析，并實現地圖操作相關功能，ArcObjects是一個非常重要的組件平臺，也是目前功能最強、組件最全、結構最復雜的平臺。GIS在國內一些地理信息系統研究機構得到了很好的發展，例如中國地質大學和武漢大學地理信息系統研究中心都對這一軟件進行了深入的研究，為我國發展GIS組件技術做出了很大的貢獻。
（二）數據庫技術
數據庫技術能夠將數據集合按照一定的結構、組織和描述性特點進行儲存，具有較小的冗余度，而且數據的獨立性非常高，具有易擴展性，能夠為多種用戶進行共享，非常適合我國城市綠地管理中的信息系統管理與應用。在城市綠地管理過程中，數據庫管理系統在確保數據安全可靠的同時，能夠提高用戶使用數據的方便性和簡單性，用戶對數據的操作能夠通過數據庫進行運行。數據庫技術有很多，配合Windows服務器版操作系統進行使用能夠提高其在城市綠地管理中的應用效率。
（三）系統開發平臺（.NET技術平臺）
NET開發平臺是完全不同于傳統應用開發的技術架構，包含很多組件，主要可簡化且規范應用系統的開發與部署，進而可以提高城市綠化管理數據的可移植性，安全性和可再利用價值。.NET開發平臺包含的各類組件、服務架構及技術層次都有共同的標準和規格，存在較好的兼容性，能夠解決過去城市綠化管理中使用的信息管理軟件無法使信息產品彼此實現兼容的問題。這一開發平臺在我國各城市的綠地管理中有著廣泛的應用，并有大量的成功案例。
三、構建城市綠化管理數據庫的建議
建設城市綠化數據庫，是一個系統性的工程，既包括信息管理軟件的應用與管理，又包括數據的分析與維護。因此，在進行城市綠化管理數據庫建設的過程中，要注意基礎地理空間數據的建設，綠化規劃數據庫的建設以及元數據庫的建設，確保空間和非空間的數據能夠通過信息管理軟件實現一體化集成。第一，空間數據庫，包括基礎地理空間數據庫、綠化規劃數據和綠化現狀數據庫；第二是屬性數據庫，主要包括植被規劃目標、系統資源的屬性數據和有關城市綠地規劃和管理的元數據。
建設城市綠化管理信息系統能夠實現城市植被地理分別的信息管理，提高城市綠化管理效率，在城市綠化管理中，很多管理內容和管理任務都是與地理分布有關的，在各項管理中存在大量雜亂的、分散的資料和數據，因此建立城市綠化管理信息系統，并通過GIS技術和數據庫技術的結合能夠有效地分析如此龐大的數據，并為城市綠化管理提出建議奠定基礎。
參考文獻
[1]趙愛華，楊鳳海.基于GIS的城市綠化管理信息系統設計與研究[J].微計算機信息，2007，23（8）.
[2]姜文峰，鄭文剛，王彥文，趙春江.城市綠地自動化節水灌溉系統的研究[J].節水灌溉，2005，（1）.