❶ 建立空間資料庫的原理、方法和步驟
一、目標任務
1.主要工作任務
《1∶25萬內陸乾旱區地下水資源評價塔里木盆地地下水勘查空間資料庫》是在綜合研究已有資料的基礎上，補充野外實際工作，建立了58個標准圖幅的1∶25萬空間資料庫。
2.技術要求
採用中國地質大學開發的MAPGIS軟體平台，完全依照中國地質調查局提出的各項技術標准，執行中國地質調查局最新修訂的《西北地下水資源勘查評價空間資料庫工作指南》2.0版及其他相關標准。對選定的58幅1∶25萬標准圖幅綜合水文地質圖、地質圖、生態環境水文地質圖、地貌圖、地下水開發利用規劃圖、地下水水化學類型圖、地下水資源分布圖、平原區地下水質量分區圖、綜合水文地質剖面圖、重點流域等水位線圖等圖件進行數字化處理和空間資料庫的建立。
參考標准或引用標准:
GB 2260中華人民共和國行政區劃代碼
GB 9649地質礦產術語分類代碼
GB/14157水文地質術語
GB/T 14538-93綜合水文地質圖圖例及色標（1∶200000～1∶500000）
GB/T 14848地下水質量標准
GB/T 13923-92，國土基礎信息數據分類與代碼（中國標准出版社，1992）
DZ/T 0197-1997數字化地質圖圖層及屬性文件格式（國家行業標准）
西北地下水資源勘查評價空間資料庫工作指南
3.提交成果
1）資料庫成果（光碟匯交）:見表6-1。
2）文檔:屬性表、圖幅基本概況表、工作日誌、自檢表、互檢表、質檢組檢查表、圖面檢查表。
表6-1 成果匯交光碟物理存儲結構
3）塔里木盆地地下水勘查包括58個標准圖幅的水文地質專業圖件共7張彩色噴墨全要素圖各1張、重點流域等水位線圖3張和綜合水文地質剖面圖1張。
4）《1∶25萬內陸乾旱區地下水資源評價塔里木盆地地下水勘查空間資料庫》建庫報告一份。
二、工作方法及流程
（一）項目組織與實施
項目由新疆地質調查院組織，由水文地質工程地質、繪圖、計算機等專業技術骨幹組成，嚴格按照規范和技術要求實施。
（二）工作方法
概據任務書的要求，收集、購買已出版的塔里木盆地58幅圖的地理信息數字化成果數據，採用中國地質大學開發的MAPGIS6.1軟體平台，將此數據在經緯秒格式下進行拼接，按《西北地下水資源勘查評價空間資料庫工作指南》標准對地理屬性進行了修改。各類專業圖件經過專業人員的編圖，經審查合格後，採用彩色或灰度掃描，進行圖形數字化，做到圖元丟失率為0，誤差小於0.02mm，其精度均達到設計要求。數據在矢量化過程中以作者原圖為主的原則，屬性內容以報告和圖面內容相結合的方法採集，成果資料中沒有的不予反映。
（三）工作流程
本次資料庫建設完全按照《西北地下水資源勘查評價空間資料庫工作指南》的具體要求，對相關數據資料進行整理。在MAPGIS支持環境下完成圖形數據的輸入和編輯，利用Access系統下創建的滿足《西北地下水資源勘查評價空間資料庫工作指南》數據結構要求的數據表，完成外掛屬性數據的錄入，並實現圖層與屬性數據的連接。
1.數據信息組成
根據新疆塔里木盆地地下水勘查總體設計書的要求，確定此次工作數據信息的內容為基礎地理、基礎地質、社會經濟信息、水文地質信息（含水文地質條件、水文地質觀測、地下水資源等）、環境地質信息、元數據信息，具體的數據信息與內容見表6-2。
表6-2 主要數據類型與數據特徵
2.圖層劃分
新疆塔里木盆地空間資料庫的建設，從基礎資料圖件到成果表達圖件，多數內容涉及大量的矢量圖形。因此，標准化處理必須確定各種圖件的圖層劃分、圖元、屬性等方面的內容，以使圖形庫最大限度地達到共享。圖形分層主要考慮到便於圖形的操作、管理和計算，同時考慮數據本身的專業數據特點。圖層劃分詳見表6-3 。
表6-3 塔里木盆地地下水勘查空間資料庫圖層劃分
續表
注:#代表含水層編號，含水層未分時，#用「0」替代。
圖6-1 工作流程示意圖
3.數據准備階段
作者原圖及簡單圖件用二值或灰度，以300dpi精度掃描，復雜圖件用彩色以300DPI精度掃描。所有圖件的圖式圖例參數說明文件放入README文件夾中。
4.數據矢量化階段
放大70倍進行圖件的數字化處理。點線數字化時，要保證其准確性和自然光滑，有坐標的點採用單點展繪的方法直接投影到1∶25萬圖中，保證了精度。線數字化時，為確保拓撲時弧段不變形，未採用MAPGIS系統提供的線圓滑功能。
5.檢查矢量化圖件
噴繪數字化圖件，對照原圖進行自檢、互檢、抽檢，並由水文地質專家進行100％的檢查，確保矢量化後的圖形數據與原圖件一致性和完整性。
6.誤差校正
塔里木盆地面積大，橫跨4個帶。各帶圖件經檢查無誤後，生成基於原圖高斯北京投影帶方式的理論圖框，進行誤差校正。每標准圖幅採集13個控制點，除4個角點外，其餘點均勻分布在圖幅內。
7.無投影格式下重新拓撲
將檢查無誤的數據投影到經緯度格式。在經緯度下再進行各帶各類圖件的拼接，為確保套合精度，重新進行拓撲，錄入面屬性，再將參與做面的線從整體拓撲圖層中弧轉線中分離出來，做線屬性。
8.噴繪圖件
對參與整體拓撲的圖層進行拓撲處理、錯誤檢查、修改，然後編輯區顏色。將各圖層形成工程文件後，彩噴出圖。再由繪圖專業人員和水文地質專家對照原圖檢查，檢查出錯誤進行修改，再出圖，再次檢查，直至完全無誤，最後彩噴成果圖件。
9.填寫屬性卡片
屬性卡片的內容以原圖和原報告為主要依據。
10.錄入屬性
在MAPGIS屬性庫管理模塊中將各圖層ID號和圖元編號做唯一。
11.轉換文件格式
將經緯度格式下的屬性文件，生成E00文件，轉入ARCINFO中，形成最終的ARCINFO格式數據。
工作流程見圖6-1。
❷ 如何合理和有效的進行資料庫設計
通常情況下，可以從兩個方面來判斷資料庫設計的是否規范:
1)一是看看是否擁有大量的窄表
窄表往往對於OLTP比較合適，符合範式設計原則
2)寬表的數量是否足夠的少。
所謂的寬表就是欄位比較多的表，包含的維度層次比較多，造成冗餘也比較多，毀範式設計，但是利於取數統計
若符合這兩個條件，我們可以說資料庫設計的比較好.
當然這是兩個泛泛而談的指標。為了達到資料庫設計規范化的要求，一般來說，需要符合以下五個要求。
要求一：表中應該避免可為空的列。
雖然表中允許空列，但是，空欄位是一種比較特殊的數據類型。資料庫在處理的時候，需要進行特殊的處理。如此的話，就會增加資料庫處理記錄的復雜性。當表中有比較多的空欄位時，在同等條件下，資料庫處理的性能會降低許多。
所以，雖然在資料庫表設計的時候，允許表中具有空欄位，但是，我們應該盡量避免。若確實需要的話，我們可以通過一些折中的方式，來處理這些空欄位，讓其對資料庫性能的影響降低到最少。
要求二：表不應該有重復的值或者列。
如現在有一個進銷存管理系統，這個系統中有一張產品基本信息表中。這個產品開發有時候可以是一個人完成，而有時候又需要多個人合作才能夠完成。所以，在產品基本信息表產品開發者這個欄位中，有時候可能需要填入多個開發者的名字。
如進銷存管理中，還需要對客戶的聯系人進行管理。有時候，企業可能只知道客戶一個采購員的姓名。但是在必要的情況下，企業需要對客戶的采購代表、倉庫人員、財務人員共同進行管理。因為在訂單上，可能需要填入采購代表的名字;可是在出貨單上，則需要填入倉庫管理人員的名字等等。
為了解決這個問題，有多種實現方式。但是，若設計不合理的話在，則會導致重復的值或者列。如我們也可以這么設計，把客戶信息、聯系人都放入同一張表中。為了解決多個聯系人的問題，可以設置第一聯系人、第一聯系人電話、第二聯系人、第二聯系人電話等等。若還有第三聯系人、第四聯系人等等，則往往還需要加入更多的欄位。
所以，我們在資料庫設計的時候要盡量避免這種重復的值或者列的產生。筆者建議，若資料庫管理員遇到這種情況，可以改變一下策略。如把客戶聯系人另外設置一張表。然後通過客戶ID把供應商信息表跟客戶聯系人信息表連接起來。也就是說，盡量將重復的值放置到一張獨立的表中進行管理。然後通過視圖或者其他手段把這些獨立的表聯系起來。
要求三：表中記錄應該有一個唯一的標識符。
在資料庫表設計的時候，資料庫管理員應該養成一個好習慣，用一個ID號來唯一的標識行記錄，而不要通過名字、編號等欄位來對紀錄進行區分。每個表都應該有一個ID列，任何兩個記錄都不可以共享同一個ID值。另外，這個ID值最好有資料庫來進行自動管理，而不要把這個任務給前台應用程序。否則的話，很容易產生ID值不統一的情況。
另外，在資料庫設計的時候，最好還能夠加入行號。如在銷售訂單管理中，ID號是用戶不能夠維護的。但是，行號用戶就可以維護。如在銷售訂單的行中，用戶可以通過調整行號的大小來對訂單行進行排序。通常情況下，ID列是以1為單位遞進的。但是，行號就要以10為單位累進。如此，正常情況下，行號就以10、20、30依次擴展下去。若此時用戶需要把行號為30的紀錄調到第一行顯示。此時，用戶在不能夠更改ID列的情況下，可以更改行號來實現。如可以把行號改為1，在排序時就可以按行號來進行排序。如此的話，原來行號為30的紀錄現在行號變為了1，就可以在第一行中顯示。這是在實際應用程序設計中對ID列的一個有效補充。這個內容在教科書上是沒有的。需要在實際應用程序設計中，才會掌握到這個技巧。
要求四：資料庫對象要有統一的前綴名。
一個比較復雜的應用系統，其對應的資料庫表往往以千計。若讓資料庫管理員看到對象名就了解這個資料庫對象所起的作用，恐怕會比較困難。而且在資料庫對象引用的時候，資料庫管理員也會為不能迅速找到所需要的資料庫對象而頭疼。
其次，表、視圖、函數等最好也有統一的前綴。如視圖可以用V為前綴，而函數則可以利用F為前綴。如此資料庫管理員無論是在日常管理還是對象引用的時候，都能夠在最短的時間內找到自己所需要的對象。
要求五：盡量只存儲單一實體類型的數據。
這里將的實體類型跟數據類型不是一回事，要注意區分。這里講的實體類型是指所需要描述對象的本身。筆者舉一個例子，估計大家就可以明白其中的內容了。如現在有一個圖書館里系統，有圖書基本信息、作者信息兩個實體對象。若用戶要把這兩個實體對象信息放在同一張表中也是可以的。如可以把表設計成圖書名字、圖書作者等等。可是如此設計的話，會給後續的維護帶來不少的麻煩。
如當後續有圖書出版時，則需要為每次出版的圖書增加作者信息，這無疑會增加額外的存儲空間，也會增加記錄的長度。而且若作者的情況有所改變，如住址改變了以後，則還需要去更改每本書的記錄。同時，若這個作者的圖書從資料庫中全部刪除之後，這個作者的信息也就盪然無存了。很明顯，這不符合資料庫設計規范化的需求。
遇到這種情況時，筆者建議可以把上面這張表分解成三種獨立的表，分別為圖書基本信息表、作者基本信息表、圖書與作者對應表等等。如此設計以後，以上遇到的所有問題就都引刃而解了。