㈠ 無縫空間資料庫設計與構建
(一)問題的提出
塔里木河流域生態環境動態監測系統的運轉需要大量的空間數據支持。在空間資料庫構建前期，採集了塔里木河流域的各尺度基礎地形圖、生態環境專題圖以及遙感影像資料等圖形、圖像數據，這些數據都是以分幅的成果進行收集和提交的，需要進入綜合資料庫中，以實現數據的共享。
我國國土版圖大，而且大部分位於中、低緯度地區，因此我國現行的大於1∶50萬比例尺的各種地形圖都採用高斯－克里格投影即橫切橢圓柱正形投影。經過高斯－克里格投影後的平面直角坐標系是以相切的經線(中央經線)的投影為X軸，以赤道的投影為Y軸。高斯－克里格投影具有以下特點:
(1)中央經線投影為直線，而且是投影的對稱軸(也是投影平面的X軸);
(2)高斯－克里格投影是等角投影，投影後具有角度不變、伸長固定的特點(即同一地點各個方向的長度比不變)，滿足等角的要求;
(3)中央經線上長度沒有變形，離中央經線越遠變形越大。為了限制投影變形，必須進行分帶投影。所謂分帶就是按照一定的經度差，將橢球體按經線劃分成若干個狹窄的區域，各個區域分別按高斯投影的規律進行投影，每一個區域就稱為一個投影帶。在每一個投影帶內，位於各帶中央的子午線就是軸子午線，各帶相鄰的子午線叫邊緣子午線。分帶之後，各帶均有自己的坐標軸和原點，形成各自獨立但又相同的坐標系統。根據國際通用方法，我國投影分帶主要有兩種:在我國1∶2.5萬到1∶50萬地形圖均採用6°分帶投影，1∶1萬及更大比例尺的地形圖採用3°分帶投影，以保證投影變形誤差滿足地圖的精度要求(王密等，2001)。
本系統所採集到的數據產品的空間參考大都是以高斯投影後的平面坐標為基礎的分幅數據。塔里木河流域地域廣闊，地理坐標介於東經73°10'～94°05'，北緯34°55'～43°08'之間，以1∶10萬基礎地形圖數據為例，按照高斯投影後的坐標分成了13°、14°、15°、16°四個6°高斯投影帶，每個帶的坐標都是以本帶的坐標原點為參考點，空間基準不統一，如果將這些數據直接進行入庫，將在跨帶處產生縫隙，不能形成邏輯意義上完整的河流表現，也無法完成基於整個流域的生態環境分析，因此，必須採用相應的數據處理與建庫技術，實現塔河整個流域數據的無縫集成管理，使之形成統一的整體。從基礎數據的獲取開始，進行精心設計和組織，分離出數據物理層和數據邏輯層，在統一的空間框架之下，將物理層歸化到邏輯層，以消除邏輯層的縫隙，從而實現用戶級的邏輯無縫空間資料庫。
(二)無縫資料庫
隨著GIS數據發布與共享技術的發展，無縫空間資料庫逐漸分化出兩個層次的含義:一是GIS系統內部的數據無縫，一是不同GIS實現互操作時的數據無縫。前者是通常意義的無縫，後者主要通過數據標准化與操作標准化來實現。無縫空間資料庫的最終含義體現在邏輯無縫資料庫。無論是多源還是單源、同構還是異構，跨越數據層呈現在用戶面前的GIS空間資料庫必須是邏輯無縫的。
空間數據的無縫連接是一個建立在用戶與資料庫介面基礎上的概念，意味著GIS管理的數據不再是單一、被硬性割裂的圖幅，而是范圍更加廣闊的區域，這個區域小可到一個城市，大可到一個國家甚至整個地球(王卉、王家耀，2004)。由於硬軟體條件的限制，計算機系統尚不能同時處理海量的空間數據，因此從具體技術的實施上，可採用將空間數據分塊存儲於資料庫中，資料庫提供相應的圖塊拼接信息。物理上空間數據是有縫隙的，但空間資料庫提供圖塊之間的接圖信息及相應的拼接訪問手段，保障了空間數據在使用上的空間連貫性，即數據在邏輯使用上是無縫的(王密等，2001)。
(三)縫隙產生原因
在現實世界中，地理空間是由地貌、地物組成的連續的表層空間，地理信息則是有關地理空間的一切有用的知識。在計算機世界中，地理信息通過抽象、建模形成數字化的表示形式，通過空間資料庫來進行表達、存儲和管理(朱欣焰等，2002)。空間地理數據縫隙是在數據的獲取、表示與處理過程中產生的數據不連續現象。
1.數據源
由於歷史和現實的原因，地圖是絕大多數GIS系統直接的數據源。地圖是地球三維橢球面的二維平面表達，本身對真實世界有扭曲;地圖是對連續空間的割裂表達，實體被分割到不同的地圖空間中去;高斯投影是基本比例尺地形圖經常選用的投影，也是絕大多數GIS系統的數學基礎，由於分帶的原因，使得投影後帶有高斯投影平面坐標的地圖無法實現無縫拼接。
2.數據表達與組織方式
空間地理幾何數據的表示主要有柵格和矢量兩種不同的形式。柵格形式是將地理表層空間劃分為一系列網格，空間目標由這些網格的位置及其量化值來表示，這些網格本身就是連續空間信息的離散表達。矢量形式則是將地理空間的一切事物、概念進行抽象，形成點、線、面，由點、線、面來組成各類空間目標。按點、線、面來分類和按分層的思想來組織空間數據，也割裂了實體之間內在的聯系。
在空間資料庫組織與管理上，目前主要有文件型、文件與關系資料庫混合型、全關系型以及對象關系型。傳統的文件型空間資料庫、文件與關系混合型空間資料庫，按圖幅或一定的區域范圍以文件的形式來組織與存儲空間幾何數據，不同的圖幅或區域之間存在縫隙。在文件與關系資料庫混合型的空間資料庫中，空間幾何數據貯存在文件中，屬性數據貯存在關系資料庫中，屬性數據和幾何數據之間通過內部標識來鏈接，空間幾何數據和屬性數據之間存在縫隙。
3.數據處理
數據處理的過程中也會引入縫隙，產生這種縫隙的原因有:①數據處理過程的順序不一致;②選擇的處理參數不一致;③數字化的精度不一致。
4.多源異構數據共享
數據屬性(數學基礎、比例尺、用途、時間、精度等)的不同，導致了數據的差異，這些差異是多層次和多方面的，它們集中體現了數據的異構。數據異構和多源往往是一體的，多源異構是系統內部和系統之間數據裂隙的主要原因(劉仁峰，2005)。
(四)數據縫隙類別和表現
數據縫隙基本可以分為物理縫隙和邏輯縫隙兩類。物理縫隙是地理空間的分離存儲，本來連續的實體空間被分離到不同的存儲空間和存儲單元中去，例如空間數據的分幅、分層存儲。邏輯縫隙是指邏輯上本身連續的信息不能以邏輯連續的方式呈現，例如跨越多幅圖的一條河流，在圖幅內查詢河流屬性(如長度)時只能獲取其在本圖幅內的相關信息而不是實體整體的信息。顯然，由於空間信息本身的海量特性，要完全意義上的實現物理無縫的空間資料庫目前還是不可能的，也沒有必要。GIS用戶關心的不是空間數據是物理無縫，因為GIS呈現給用戶的是數據邏輯層，只需要保證用戶看到的數據是邏輯無縫的。
物理有縫的資料庫向邏輯無縫資料庫的轉換是無縫空間資料庫構建的重要一環。
(五)無縫鑲嵌技術
數據的無縫連接包含以下幾個問題:投影、坐標系統、比例尺、數據精度等。對不同投影和坐標系統的空間數據在投影和坐標系統上統一採用相同的標准，當空間數據具有多尺度時，無縫連接尋找數據集之間連續的表達方式，它表現為不同尺度數據之間的集成。建立無縫空間數據的關鍵在於在合適的空間信息框架上實現多源異構空間數據的融合，框架是基礎，融合是手段。
1.合適的空間框架選擇
(1)適合多尺度信息表達。地球是一個開放的非常復雜的巨大系統，隨著觀察視角的變化，我們希望空間地理信息比例尺也自動增減。由於地圖的自動綜合受諸多因素的影響，目前比較可行的是採用多尺度空間數據支持來達到目的。所謂多尺度就是指系統內包含幾種不同比例尺(或解析度)的空間數據，其目的是為了適度地反映系統所關心區域的空間地理信息，以避免地物信息的過粗、失真或地物信息的負載量過大而無法使用。無縫空間資料庫也應該符合多尺度空間資料庫要求。
(2)適合大區域表達。各種自然和人文現象的空間分布，有其內在的原因和規律，這些原因和規律的獲得，往往需要研究大區域多因素的綜合作用;另一方面，對於全球范圍的環境變異和氣候變遷的研究需要基於數字地球的空間框架。大區域的表達，還涉及空間尺度問題，不應繼續採用歐氏空間尺度，而應該採用大地線尺度空間。
2.多源異構空間數據的融合
(1)GIS的迅速發展和廣泛應用導致了多源空間數據的產生。如何實現不同的GIS軟體共享並操作不同來源的地理數據，即GIS多源空間數據的集成，成為GIS發展的關鍵。目前GIS多源空間數據的集成主要朝著三個方向發展，一是通過建立統一的數據交換標准來約束並規范已有的各類地理信息系統，採用數據交換標准來進行空間數據交換;二是建立開放式地理數據互操作規范，進行地理信息系統互操作;三是GIS數據中間件技術。
(2)統一數據交換標准存在很多實現上的困難。互操作是一個重要發展趨勢，是在異構分布式資料庫中實現信息共享的途徑，它需要將GIS技術、分布處理技術、面向對象方法、資料庫設計及實時信息獲取方法更有效地結合起來。所謂GIS數據中間件技術是指能夠嵌入各類GIS系統的軟體，GIS開發者通過中間件開發商提供的介面，訪問和操作特定的數據源。
(3)在多源異構數據集成技術尚未成熟的時候，人們再次把目光投向數據本身，如果可以提供關於數據的詳細描述，是否可以提高融合數據的能力呢?於是，對於「關於數據的數據」的研究，即對於元數據的研究便普遍展開。從DublinCore到CSDGM與OGC，都提出了相應的元數據標准體系，有了完整而完善的元數據描述，必將提高數據的效能，從而最終促進多源異構資料庫向無縫空間資料庫的歸化。
為實現塔河整個流域數據的無縫集成管理，使之形成統一的整體，設計從縫隙產生的地方開始，分離出數據物理層和數據邏輯層，在統一的空間框架之下，將物理層歸化到邏輯層，以消除邏輯層的縫隙，從而實現用戶級的邏輯無縫空間資料庫;同時制定統一的數據提交規范，如所有矢量數據在入庫前統一採用經緯度坐標，柵格數據統一提供兩套數據，即高斯坐標和經緯度坐標，以滿足不同用戶的管理需求和精度要求。
㈡ sql如何創建系統資料庫
你要創建系統資料庫？？？
你可以直接建啊，不需要命令啊，當然命令可以而且有利學習
create database database-name 創建
drop database database-name 刪除
㈢ 如何將sql server 2008 geometry空間坐標導入arcmap
如何將sql server 2008 geometry空間坐標導入arcmap
很簡單的，進入arcgis的 arccatalog，找到你要設置空間參考的shp文件，右鍵屬性-XY坐標-選擇你要定義的坐標系-確定。
㈣ 如何用SQL語句創建資料庫
在SQL語句中，CREATE DATABASE 語句用於創建資料庫。
具體用法如下：
-from 樹懶學堂
資料庫表可以通過 CREATE TABLE 語句來添加。
㈤ 如何建立SQL資料庫，以及所需要軟體！詳細操作方法！重謝！！！
一、導出導入SQL Server里某個資料庫
1.在SQL Server企業管理器里選中要轉移的資料庫，按滑鼠右鍵，選所有任務->備份資料庫。
2.備份 選資料庫-完全，
目的 備份到 按添加按鈕
文件名 在SQL Server伺服器硬碟下輸入一個自定義的備份資料庫文件名(後綴一般是bak)
重寫 選重寫現有媒體
最後按確定按鈕。
如果生成的備份資料庫文件大於1M，要用壓縮工具壓縮後再到Internet上傳輸。
3.通過FTP或者remote desktop或者pcanywhere等方法
把第二步生成的備份資料庫文件或者其壓縮後的文件傳到目的SQL Server資料庫，如果有壓縮要解壓。
4.目的SQL Server資料庫如果還沒有此資料庫，先創建一個新的資料庫；
然後選中這個新創建的資料庫，按滑鼠右鍵，選所有任務->還原資料庫
還原->從設備->選擇設備->磁碟->添加（找到要導入的備份資料庫文件名）->確定
還原備份集->資料庫-完全
最後按確定按鈕。完全的資料庫導入成功了。
(如果在已經存在的SQL Server資料庫上還原資料庫可能遇到有還有其它人正在使用它而恢復操做失敗，
可以去看 ->管理->當前活動->鎖/對象->找到資料庫下鎖的進程號->到查詢分析器里用kill 進程號殺掉這些鎖，
然後再做還原)
注意：如果在原有的目的SQL Server資料庫上從備份文件(*.bak)還原資料庫
會把已經存在的表、存儲過程等資料庫對象全部替換成最近這次導入的備份資料庫里的內容。
如果一定要還原備份文件(*.bak)里部分數據,需要另外建一個新資料庫,
其邏輯名稱和數量同備份文件(*.bak)里資料庫的邏輯名稱和數量一致；
新資料庫的物理文件名稱取得一定要和備份文件(*.bak)里資料庫的物理文件不一樣才行。
㈥ sql語句怎麼寫算坐標經緯度之間的距離我是mysql資料庫。 請詳細點！謝謝！
這單用SQL語句是辦不到的吧
應該先把坐標從資料庫中取出，再用三角函數計算。
或者在存入資料庫之前，先把距離計算出來，一並存入。
㈦ 創建資料庫有哪幾種方法
創建資料庫的方法有兩種，使用向導創建資料庫，使用菜單創建資料庫和創建空資料庫；使用向導創建資料庫是一種簡單便捷的方法。
在物理上，資料庫的建設要遵循實際情況。即在邏輯上建立一個整體的空間數據車、框架統一設計的同時，各級比例尺和不同數據源的數據分別建成子庫，由開發的平台管理軟體來統一協調與調度。
(7)sql空間資料庫建立坐標系統擴展閱讀：
在建庫時，要充分考慮數據有效共享的需求，同時也要保證數據訪問的合法性和安全性。資料庫採用統一的坐標系統和高程基準，矢量數據採用大地坐標大地坐標的數據在數值上是連續的，避免高斯投影跨帶問題，從而保證資料庫地理對象的完整性，為資料庫的查詢檢索、分析應用提供方便。
在創建資料庫之時，要重點考慮獨立與完整性原則、面向對象的資料庫設計原則、建庫與更新有機結合的原則、分級共享原則、並發性原則、實用性原則。
㈧ sql 建立資料庫的問題
分配的空間主要是指預估的數據文件大小，要根據實際預計的需求定，定大了會佔用過多的磁碟空間，定義時候可以指定增加的選項（步長），所有定義初始值太小的話，數據不夠時候，會系統會頻繁調整空間，影響效率。當然如果初期不能預見實際大小，可以把步長放適當寬裕些，如10%
㈨ sql資料庫設計
一、資料庫設計過程
資料庫技術是信息資源管理最有效的手段。資料庫設計是指對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統，有效存儲數據，滿足用戶信息要求和處理要求。
資料庫設計中需求分析階段綜合各個用戶的應用需求（現實世界的需求），在概念設計階段形成獨立於機器特點、獨立於各個DBMS產品的概念模式（信息世界模型），用E-R圖來描述。在邏輯設計階段將E-R圖轉換成具體的資料庫產品支持的數據模型如關系模型，形成資料庫邏輯模式。然後根據用戶處理的要求，安全性的考慮，在基本表的基礎上再建立必要的視圖（VIEW）形成數據的外模式。在物理設計階段根據DBMS特點和處理的需要，進行物理存儲安排，設計索引，形成資料庫內模式。
1. 需求分析階段
需求收集和分析，結果得到數據字典描述的數據需求（和數據流圖描述的處理需求）。
需求分析的重點是調查、收集與分析用戶在數據管理中的信息要求、處理要求、安全性與完整性要求。
需求分析的方法：調查組織機構情況、調查各部門的業務活動情況、協助用戶明確對新系統的各種要求、確定新系統的邊界。
常用的調查方法有： 跟班作業、開調查會、請專人介紹、詢問、設計調查表請用戶填寫、查閱記錄。
分析和表達用戶需求的方法主要包括自頂向下和自底向上兩類方法。自頂向下的結構化分析方法（Structured Analysis，簡稱SA方法）從最上層的系統組織機構入手，採用逐層分解的方式分析系統，並把每一層用數據流圖和數據字典描述。
數據流圖表達了數據和處理過程的關系。系統中的數據則藉助數據字典（Data Dictionary，簡稱DD）來描述。
數據字典是各類數據描述的集合，它是關於資料庫中數據的描述，即元數據，而不是數據本身。數據字典通常包括數據項、數據結構、數據流、數據存儲和處理過程五個部分(至少應該包含每個欄位的數據類型和在每個表內的主外鍵)。
數據項描述＝｛數據項名，數據項含義說明，別名，數據類型，長度，
取值范圍，取值含義，與其他數據項的邏輯關系｝
數據結構描述＝｛數據結構名，含義說明，組成:｛數據項或數據結構｝｝
數據流描述＝｛數據流名，說明，數據流來源，數據流去向，
組成:｛數據結構｝，平均流量，高峰期流量｝
數據存儲描述＝｛數據存儲名，說明，編號，流入的數據流，流出的數據流，
組成:｛數據結構｝，數據量，存取方式｝
處理過程描述＝｛處理過程名，說明，輸入:｛數據流｝，輸出:｛數據流｝,
處理:｛簡要說明｝｝
2. 概念結構設計階段
通過對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型，可以用E-R圖表示。
概念模型用於信息世界的建模。概念模型不依賴於某一個DBMS支持的數據模型。概念模型可以轉換為計算機上某一DBMS支持的特定數據模型。
概念模型特點：
(1) 具有較強的語義表達能力，能夠方便、直接地表達應用中的各種語義知識。
(2) 應該簡單、清晰、易於用戶理解，是用戶與資料庫設計人員之間進行交流的語言。
概念模型設計的一種常用方法為IDEF1X方法，它就是把實體-聯系方法應用到語義數據模型中的一種語義模型化技術，用於建立系統信息模型。
使用IDEF1X方法創建E-R模型的步驟如下所示:
2.1 第零步——初始化工程
這個階段的任務是從目的描述和范圍描述開始，確定建模目標，開發建模計劃，組織建模隊伍，收集源材料，制定約束和規范。收集源材料是這階段的重點。通過調查和觀察結果，業務流程，原有系統的輸入輸出，各種報表，收集原始數據，形成了基本數據資料表。
2.2 第一步——定義實體
實體集成員都有一個共同的特徵和屬性集，可以從收集的源材料——基本數據資料表中直接或間接標識出大部分實體。根據源材料名字表中表示物的術語以及具有「代碼」結尾的術語，如客戶代碼、代理商代碼、產品代碼等將其名詞部分代表的實體標識出來，從而初步找出潛在的實體，形成初步實體表。
2.3 第二步——定義聯系
IDEF1X模型中只允許二元聯系，n元聯系必須定義為n個二元聯系。根據實際的業務需求和規則，使用實體聯系矩陣來標識實體間的二元關系，然後根據實際情況確定出連接關系的勢、關系名和說明，確定關系類型，是標識關系、非標識關系（強制的或可選的）還是非確定關系、分類關系。如果子實體的每個實例都需要通過和父實體的關系來標識，則為標識關系，否則為非標識關系。非標識關系中，如果每個子實體的實例都與而且只與一個父實體關聯，則為強制的，否則為非強制的。如果父實體與子實體代表的是同一現實對象，那麼它們為分類關系。
2.4 第三步——定義碼
通過引入交叉實體除去上一階段產生的非確定關系，然後從非交叉實體和獨立實體開始標識侯選碼屬性，以便唯一識別每個實體的實例，再從侯選碼中確定主碼。為了確定主碼和關系的有效性，通過非空規則和非多值規則來保證，即一個實體實例的一個屬性不能是空值，也不能在同一個時刻有一個以上的值。找出誤認的確定關系，將實體進一步分解，最後構造出IDEF1X模型的鍵基視圖（KB圖）。
2.5 第四步——定義屬性
從源數據表中抽取說明性的名詞開發出屬性表，確定屬性的所有者。定義非主碼屬性，檢查屬性的非空及非多值規則。此外，還要檢查完全依賴函數規則和非傳遞依賴規則，保證一個非主碼屬性必須依賴於主碼、整個主碼、僅僅是主碼。以此得到了至少符合關系理論第三範式的改進的IDEF1X模型的全屬性視圖。
2.6 第五步——定義其他對象和規則
定義屬性的數據類型、長度、精度、非空、預設值、約束規則等。定義觸發器、存儲過程、視圖、角色、同義詞、序列等對象信息。
3. 邏輯結構設計階段
將概念結構轉換為某個DBMS所支持的數據模型（例如關系模型），並對其進行優化。設計邏輯結構應該選擇最適於描述與表達相應概念結構的數據模型，然後選擇最合適的DBMS。
將E-R圖轉換為關系模型實際上就是要將實體、實體的屬性和實體之間的聯系轉化為關系模式,這種轉換一般遵循如下原則：
1）一個實體型轉換為一個關系模式。實體的屬性就是關系的屬性。實體的碼就是關系的碼。
2）一個m:n聯系轉換為一個關系模式。與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性。而關系的碼為各實體碼的組合。
3）一個1:n聯系可以轉換為一個獨立的關系模式，也可以與n端對應的關系模式合並。如果轉換為一個獨立的關系模式，則與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性，而關系的碼為n端實體的碼。
4）一個1:1聯系可以轉換為一個獨立的關系模式，也可以與任意一端對應的關系模式合並。
5）三個或三個以上實體間的一個多元聯系轉換為一個關系模式。與該多元聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性。而關系的碼為各實體碼的組合。
6）同一實體集的實體間的聯系，即自聯系，也可按上述1:1、1:n和m:n三種情況分別處理。
7）具有相同碼的關系模式可合並。
為了進一步提高資料庫應用系統的性能，通常以規范化理論為指導，還應該適當地修改、調整數據模型的結構，這就是數據模型的優化。確定數據依賴。消除冗餘的聯系。確定各關系模式分別屬於第幾範式。確定是否要對它們進行合並或分解。一般來說將關系分解為3NF的標准，即：
表內的每一個值都只能被表達一次。
•?表內的每一行都應該被唯一的標識（有唯一鍵）。
表內不應該存儲依賴於其他鍵的非鍵信息。
4. 資料庫物理設計階段
為邏輯數據模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）。根據DBMS特點和處理的需要，進行物理存儲安排，設計索引，形成資料庫內模式。
5. 資料庫實施階段
運用DBMS提供的數據語言（例如SQL）及其宿主語言（例如C），根據邏輯設計和物理設計的結果建立資料庫，編制與調試應用程序，組織數據入庫，並進行試運行。 資料庫實施主要包括以下工作：用DDL定義資料庫結構、組織數據入庫 、編制與調試應用程序、資料庫試運行
6. 資料庫運行和維護階段
資料庫應用系統經過試運行後即可投入正式運行。在資料庫系統運行過程中必須不斷地對其進行評價、調整與修改。包括：資料庫的轉儲和恢復、資料庫的安全性、完整性控制、資料庫性能的監督、分析和改進、資料庫的重組織和重構造。
建模工具的使用
為加快資料庫設計速度，目前有很多資料庫輔助工具（CASE工具），如Rational公司的Rational Rose，CA公司的Erwin和Bpwin，Sybase公司的PowerDesigner以及Oracle公司的Oracle Designer等。
ERwin主要用來建立資料庫的概念模型和物理模型。它能用圖形化的方式，描述出實體、聯系及實體的屬性。ERwin支持IDEF1X方法。通過使用ERwin建模工具自動生成、更改和分析IDEF1X模型，不僅能得到優秀的業務功能和數據需求模型，而且可以實現從IDEF1X模型到資料庫物理設計的轉變。ERwin工具繪制的模型對應於邏輯模型和物理模型兩種。在邏輯模型中，IDEF1X工具箱可以方便地用圖形化的方式構建和繪制實體聯系及實體的屬性。在物理模型中，ERwin可以定義對應的表、列，並可針對各種資料庫管理系統自動轉換為適當的類型。
設計人員可根據需要選用相應的資料庫設計建模工具。例如需求分析完成之後，設計人員可以使用Erwin畫ER圖，將ER圖轉換為關系數據模型，生成資料庫結構；畫數據流圖，生成應用程序。
二、資料庫設計技巧
1. 設計資料庫之前（需求分析階段）
1) 理解客戶需求，詢問用戶如何看待未來需求變化。讓客戶解釋其需求，而且隨著開發的繼續，還要經常詢問客戶保證其需求仍然在開發的目的之中。
2) 了解企業業務可以在以後的開發階段節約大量的時間。
3) 重視輸入輸出。
在定義資料庫表和欄位需求（輸入）時，首先應檢查現有的或者已經設計出的報表、查詢和視圖（輸出）以決定為了支持這些輸出哪些是必要的表和欄位。
舉例：假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼欄位而不要把郵政編碼糅進地址欄位里。
4) 創建數據字典和ER 圖表
ER 圖表和數據字典可以讓任何了解資料庫的人都明確如何從資料庫中獲得數據。ER圖對表明表之間關系很有用，而數據字典則說明了每個欄位的用途以及任何可能存在的別名。對SQL 表達式的文檔化來說這是完全必要的。
5) 定義標準的對象命名規范
資料庫各種對象的命名必須規范。
2. 表和欄位的設計（資料庫邏輯設計）
表設計原則
1) 標准化和規范化
數據的標准化有助於消除資料庫中的數據冗餘。標准化有好幾種形式，但Third Normal Form（3NF）通常被認為在性能、擴展性和數據完整性方面達到了最好平衡。簡單來說，遵守3NF 標準的資料庫的表設計原則是：「One Fact in One Place」即某個表只包括其本身基本的屬性，當不是它們本身所具有的屬性時需進行分解。表之間的關系通過外鍵相連接。它具有以下特點：有一組表專門存放通過鍵連接起來的關聯數據。
舉例：某個存放客戶及其有關定單的3NF 資料庫就可能有兩個表：Customer 和Order。Order 表不包含定單關聯客戶的任何信息，但表內會存放一個鍵值，該鍵指向Customer 表裡包含該客戶信息的那一行。
事實上，為了效率的緣故，對表不進行標准化有時也是必要的。
2) 數據驅動
採用數據驅動而非硬編碼的方式，許多策略變更和維護都會方便得多，大大增強系統的靈活性和擴展性。
舉例，假如用戶界面要訪問外部數據源（文件、XML 文檔、其他資料庫等），不妨把相應的連接和路徑信息存儲在用戶界面支持表裡。還有，如果用戶界面執行工作流之類的任務（發送郵件、列印信箋、修改記錄狀態等），那麼產生工作流的數據也可以存放在資料庫里。角色許可權管理也可以通過數據驅動來完成。事實上，如果過程是數據驅動的，你就可以把相當大的責任推給用戶，由用戶來維護自己的工作流過程。
3) 考慮各種變化
在設計資料庫的時候考慮到哪些數據欄位將來可能會發生變更。
舉例，姓氏就是如此（注意是西方人的姓氏，比如女性結婚後從夫姓等）。所以，在建立系統存儲客戶信息時，在單獨的一個數據表裡存儲姓氏欄位，而且還附加起始日和終止日等欄位，這樣就可以跟蹤這一數據條目的變化。
欄位設計原則
4) 每個表中都應該添加的3 個有用的欄位
•?dRecordCreationDate，在VB 下默認是Now()，而在SQL Server 下默認為GETDATE()
•?sRecordCreator，在SQL Server 下默認為NOT NULL DEFAULT USER
•?nRecordVersion，記錄的版本標記；有助於准確說明記錄中出現null 數據或者丟失數據的原因
5) 對地址和電話採用多個欄位
描述街道地址就短短一行記錄是不夠的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的靈活性。還有，電話號碼和郵件地址最好擁有自己的數據表，其間具有自身的類型和標記類別。
6) 使用角色實體定義屬於某類別的列
在需要對屬於特定類別或者具有特定角色的事物做定義時，可以用角色實體來創建特定的時間關聯關系，從而可以實現自我文檔化。
舉例：用PERSON 實體和PERSON_TYPE 實體來描述人員。比方說，當John Smith, Engineer 提升為John Smith, Director 乃至最後爬到John Smith, cio 的高位，而所有你要做的不過是改變兩個表PERSON 和PERSON_TYPE 之間關系的鍵值，同時增加一個日期/時間欄位來知道變化是何時發生的。這樣，你的PERSON_TYPE 表就包含了所有PERSON 的可能類型，比如Associate、Engineer、Director、CIO 或者CEO 等。還有個替代辦法就是改變PERSON 記錄來反映新頭銜的變化，不過這樣一來在時間上無法跟蹤個人所處位置的具體時間。
7) 選擇數字類型和文本類型盡量充足
在SQL 中使用smallint 和tinyint 類型要特別小心。比如，假如想看看月銷售總額，總額欄位類型是smallint，那麼，如果總額超過了$32,767 就不能進行計算操作了。
而ID 類型的文本欄位，比如客戶ID 或定單號等等都應該設置得比一般想像更大。假設客戶ID 為10 位數長。那你應該把資料庫表欄位的長度設為12 或者13 個字元長。但這額外占據的空間卻無需將來重構整個資料庫就可以實現資料庫規模的增長了。
8) 增加刪除標記欄位
在表中包含一個「刪除標記」欄位，這樣就可以把行標記為刪除。在關系資料庫里不要單獨刪除某一行；最好採用清除數據程序而且要仔細維護索引整體性。
3. 選擇鍵和索引（資料庫邏輯設計）
鍵選擇原則：
1) 鍵設計4 原則
•?為關聯欄位創建外鍵。
•?所有的鍵都必須唯一。
•?避免使用復合鍵。
•?外鍵總是關聯唯一的鍵欄位。
2) 使用系統生成的主鍵
設計資料庫的時候採用系統生成的鍵作為主鍵，那麼實際控制了資料庫的索引完整性。這樣，資料庫和非人工機制就有效地控制了對存儲數據中每一行的訪問。採用系統生成鍵作為主鍵還有一個優點：當擁有一致的鍵結構時，找到邏輯缺陷很容易。
3) 不要用用戶的鍵(不讓主鍵具有可更新性)
在確定採用什麼欄位作為表的鍵的時候，可一定要小心用戶將要編輯的欄位。通常的情況下不要選擇用戶可編輯的欄位作為鍵。
4) 可選鍵有時可做主鍵
把可選鍵進一步用做主鍵，可以擁有建立強大索引的能力。
索引使用原則：
索引是從資料庫中獲取數據的最高效方式之一。95%的資料庫性能問題都可以採用索引技術得到解決。
1) 邏輯主鍵使用唯一的成組索引，對系統鍵（作為存儲過程）採用唯一的非成組索引，對任何外鍵列採用非成組索引。考慮資料庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用作讀寫。
2) 大多數資料庫都索引自動創建的主鍵欄位，但是可別忘了索引外鍵，它們也是經常使用的鍵，比如運行查詢顯示主表和所有關聯表的某條記錄就用得上。
3) 不要索引memo/note 欄位，不要索引大型欄位（有很多字元），這樣作會讓索引佔用太多的存儲空間。
4) 不要索引常用的小型表
不要為小型數據表設置任何鍵，假如它們經常有插入和刪除操作就更別這樣作了。對這些插入和刪除操作的索引維護可能比掃描表空間消耗更多的時間。
4. 數據完整性設計（資料庫邏輯設計）
1) 完整性實現機制：
實體完整性：主鍵
參照完整性：
父表中刪除數據：級聯刪除；受限刪除；置空值
父表中插入數據：受限插入；遞歸插入
父表中更新數據：級聯更新；受限更新；置空值
DBMS對參照完整性可以有兩種方法實現：外鍵實現機制（約束規則）和觸發器實現機制
用戶定義完整性：
NOT NULL；CHECK；觸發器
2) 用約束而非商務規則強制數據完整性
採用資料庫系統實現數據的完整性。這不但包括通過標准化實現的完整性而且還包括數據的功能性。在寫數據的時候還可以增加觸發器來保證數據的正確性。不要依賴於商務層保證數據完整性；它不能保證表之間（外鍵）的完整性所以不能強加於其他完整性規則之上。
3) 強制指示完整性
在有害數據進入資料庫之前將其剔除。激活資料庫系統的指示完整性特性。這樣可以保持數據的清潔而能迫使開發人員投入更多的時間處理錯誤條件。
4) 使用查找控制數據完整性
控制數據完整性的最佳方式就是限制用戶的選擇。只要有可能都應該提供給用戶一個清晰的價值列表供其選擇。這樣將減少鍵入代碼的錯誤和誤解同時提供數據的一致性。某些公共數據特別適合查找：國家代碼、狀態代碼等。
5) 採用視圖
為了在資料庫和應用程序代碼之間提供另一層抽象，可以為應用程序建立專門的視圖而不必非要應用程序直接訪問數據表。這樣做還等於在處理資料庫變更時給你提供了更多的自由。
5. 其他設計技巧
1) 避免使用觸發器
觸發器的功能通常可以用其他方式實現。在調試程序時觸發器可能成為干擾。假如你確實需要採用觸發器，你最好集中對它文檔化。
2) 使用常用英語（或者其他任何語言）而不要使用編碼
在創建下拉菜單、列表、報表時最好按照英語名排序。假如需要編碼，可以在編碼旁附上用戶知道的英語。
3) 保存常用信息
讓一個表專門存放一般資料庫信息非常有用。在這個表裡存放資料庫當前版本、最近檢查/修復（對Access）、關聯設計文檔的名稱、客戶等信息。這樣可以實現一種簡單機制跟蹤資料庫，當客戶抱怨他們的資料庫沒有達到希望的要求而與你聯系時，這樣做對非客戶機/伺服器環境特別有用。
4) 包含版本機制
在資料庫中引入版本控制機制來確定使用中的資料庫的版本。時間一長，用戶的需求總是會改變的。最終可能會要求修改資料庫結構。把版本信息直接存放到資料庫中更為方便。
5) 編制文檔
對所有的快捷方式、命名規范、限制和函數都要編制文檔。
採用給表、列、觸發器等加註釋的資料庫工具。對開發、支持和跟蹤修改非常有用。
對資料庫文檔化，或者在資料庫自身的內部或者單獨建立文檔。這樣，當過了一年多時間後再回過頭來做第2 個版本，犯錯的機會將大大減少。
6) 測試、測試、反復測試
建立或者修訂資料庫之後，必須用用戶新輸入的數據測試數據欄位。最重要的是，讓用戶進行測試並且同用戶一道保證選擇的數據類型滿足商業要求。測試需要在把新資料庫投入實際服務之前完成。
7) 檢查設計
在開發期間檢查資料庫設計的常用技術是通過其所支持的應用程序原型檢查資料庫。換句話說，針對每一種最終表達數據的原型應用，保證你檢查了數據模型並且查看如何取出數據。
三、資料庫命名規范
1. 實體（表）的命名
1) 表以名詞或名詞短語命名，確定表名是採用復數還是單數形式，此外給表的別名定義簡單規則（比方說，如果表名是一個單詞，別名就取單詞的前4 個字母；如果表名是兩個單詞，就各取兩個單詞的前兩個字母組成4 個字母長的別名；如果表的名字由3 個單片語成，從頭兩個單詞中各取一個然後從最後一個單詞中再取出兩個字母，結果還是組成4 字母長的別名，其餘依次類推）
對工作用表來說，表名可以加上前綴WORK_ 後面附上採用該表的應用程序的名字。在命名過程當中，根據語義拼湊縮寫即可。注意，由於ORCLE會將欄位名稱統一成大寫或者小寫中的一種，所以要求加上下劃線。
舉例：
定義的縮寫 Sales: Sal 銷售；
Order: Ord 訂單；
Detail: Dtl 明細；
則銷售訂單明細表命名為：Sal_Ord_Dtl;
2) 如果表或者是欄位的名稱僅有一個單詞，那麼建議不使用縮寫，而是用完整的單詞。
舉例：
定義的縮寫 Material Ma 物品；
物品表名為：Material, 而不是 Ma.
但是欄位物品編碼則是：Ma_ID;而不是Material_ID
3) 所有的存儲值列表的表前面加上前綴Z
目的是將這些值列表類排序在資料庫最後。
4) 所有的冗餘類的命名(主要是累計表)前面加上前綴X
冗餘類是為了提高資料庫效率，非規范化資料庫的時候加入的欄位或者表
5) 關聯類通過用下劃線連接兩個基本類之後，再加前綴R的方式命名,後面按照字母順序羅列兩個表名或者表名的縮寫。
關聯表用於保存多對多關系。
如果被關聯的表名大於10個字母，必須將原來的表名的進行縮寫。如果沒有其他原因，建議都使用縮寫。
舉例：表Object與自身存在多對多的關系,則保存多對多關系的表命名為：R_Object；
表 Depart和Employee;存在多對多的關系；則關聯表命名為R_Dept_Emp
2. 屬性（列）的命名
1) 採用有意義的列名，表內的列要針對鍵採用一整套設計規則。每一個表都將有一個自動ID作為主健,邏輯上的主健作為第一組候選主健來定義,如果是資料庫自動生成的編碼，統一命名為：ID;如果是自定義的邏輯上的編碼則用縮寫加「ID」的方法命名。如果鍵是數字類型，你可以用_NO 作為後綴；如果是字元類型則可以採用_CODE 後綴。對列名應該採用標準的前綴和後綴。
舉例：銷售訂單的編號欄位命名：Sal_Ord_ID；如果還存在一個資料庫生成的自動編號，則命名為：ID。
2) 所有的屬性加上有關類型的後綴，注意，如果還需要其它的後綴，都放在類型後綴之前。
注: 數據類型是文本的欄位，類型後綴TX可以不寫。有些類型比較明顯的欄位，可以不寫類型後綴。
3) 採用前綴命名
給每個表的列名都採用統一的前綴，那麼在編寫SQL表達式的時候會得到大大的簡化。這樣做也確實有缺點，比如破壞了自動表連接工具的作用，後者把公共列名同某些資料庫聯系起來。
3. 視圖的命名
1) 視圖以V作為前綴，其他命名規則和表的命名類似；
2) 命名應盡量體現各視圖的功能。
4. 觸發器的命名
觸發器以TR作為前綴，觸發器名為相應的表名加上後綴，Insert觸發器加'_I'，Delete觸發器加'_D'，Update觸發器加'_U'，如：TR_Customer_I，TR_Customer_D，TR_Customer_U。
5. 存儲過程名
存儲過程應以'UP_'開頭，和系統的存儲過程區分，後續部分主要以動賓形式構成，並用下劃線分割各個組成部分。如增加代理商的帳戶的存儲過程為'UP_Ins_Agent_Account'。
6. 變數名
變數名採用小寫，若屬於片語形式，用下劃線分隔每個單詞，如@my_err_no。
7. 命名中其他注意事項
1) 以上命名都不得超過30個字元的系統限制。變數名的長度限制為29（不包括標識字元@）。
2) 數據對象、變數的命名都採用英文字元，禁止使用中文命名。絕對不要在對象名的字元之間留空格。
3) 小心保留詞，要保證你的欄位名沒有和保留詞、資料庫系統或者常用訪問方法沖突
5) 保持欄位名和類型的一致性，在命名欄位並為其指定數據類型的時候一定要保證一致性。假如數據類型在一個表裡是整數，那在另一個表裡可就別變成字元型了。
㈩ 空間資料庫建立
在遙感圖像處理系統空間資料庫的建立過程中，由於我們的大部分資料來源於現有的地圖，因而以地圖的數據處理，採用掃描矢量化的數字化手段進行數據錄入，各種地圖處理，數據入庫工作流程可分為預處理、圖形掃描數字化、圖層數據建立拓撲關系、建屬性資料庫、圖層矢量數據與屬性數據聯接、投影轉換、圖幅拼接、圖面整飾、數據入庫九個階段。如圖7-9所示。
圖7-9 數據採集工作流程圖
（1）圖形預處理
資源信息是多源和多尺度的。毫無疑問，對這些資料的初步整理是數字化工作進程的重要一環。
本系統將採用統一的坐標系統，坐標系為1980西安坐標系，高程系為1985國家高程基準。所有的圖形數據均應該轉換到此坐標系。
（2）圖形掃描數字化
在地圖數據採集過程中，由於地圖原圖質量、內容、比例尺和掃描過程中的種種因素，根據紙介質地圖的圖形要素和彩色特徵提取的分層圖仍會帶有各種雜訊以及不需要的其他一些信息，為了獲得正確的、干凈的數據，在數字化之前，要進行二值化、去臟、光滑、斷線修補、細化處理等預處理步驟。
（3）圖層數據建立拓撲關系與圖形編輯
矢量化後的各圖層，利用ArcGIS軟體提供的功能建立拓撲關系，在建拓撲關系時會發現圖形數據錯誤，要進行編輯、修改，再重新建立拓撲關系，這一過程可能做多次，直到數據正確為止。
（4）建屬性資料庫
按已採集的屬性數據表，和標准規定格式，利用通用的資料庫管理軟體建立分層資料庫，文字型數據要按標准代碼錄入。
（5）圖層矢量數據與屬性數據聯接
按圖元編碼（用戶ID）將矢量數據與屬性數據聯接。對於已建立聯接的各類空間數據和屬性數據，通過ArcGIS 系統對它們做進一步的編輯和修改，確保資料庫的准確性和完整性。在ArcGIS 系統中，圖形數據被分成「點」、「線」、「面」三種幾何要素，它們都有各自相關的屬性，在進行拓撲處理後，這三種要素間便擁有了相關的空間拓撲結構，這種空間數據關系與相應的屬性數據是一種動態聯結關系，這也是在ArcGIS系統中能夠進行空間分析的關鍵所在。屬性數據的編輯可通過ArcGIS系統的資料庫管理系統進行數據結構定義（如數據項名稱、類型、長度等）、數據編輯（如插入、刪除、拷貝等）、數據查詢檢索等等，形成可供使用的屬性資料庫。
（6）投影轉換
同一工作區可能利用不同比例、不同投影的圖件，要對不同來源、不同時間解析度和空間解析度的點、線、面數據進行計算，在拼接圖層之前必須對它們進行投影轉換，使最終形成的圖層均投影到一個坐標系統。
（7）圖幅接邊
圖幅接邊的目的是要保持圖面數據連續性。工作區有多幅圖構成，按上述步驟每幅圖分層建立起圖層之後，要對各相鄰圖幅分層進行拼接，圖幅的接邊精度要滿足相應比例尺的國家精度要求。各圖層中線圖元或面圖元拼接後其圖元編號要進行改變，在右邊圖幅中的圖元拼接後用左邊圖幅內的圖元編號，下邊圖幅的圖元改用上邊圖幅的圖元編號。其屬性數據也要合並為一個，屬性數據結構不相同的圖元（線或面）不能進行圖幅拼接。對於一些圖面標注的內容也要做相應的調整。到現在為止，已完成了圖形庫的建立工作。拼接完成後，仍按圖幅分開儲存與管理。
（8）數據入庫
前面數據處理的目的都是為了使圖形進入GIS資料庫系統中，以作為其他應用系統的數據基礎。圖形數據將採用空間數據管理方式、利用系統軟體將所有圖形及屬性統一存放於Oracle之中。
（9）圖件輸出與圖面整飾
在每一圖幅數字化完成後，或工作區各圖幅分層拼接之後，要對圖面標注內容逐一添加到圖面上。按有關圖例符號標准和用色標准對相應點、線、面圖元的線型、符號、顏色進行設置定義。再就圖名、圖例、比例尺及其圖面內容整飾後，輸出圖件成果。
（10）數據質量控制
檢查內容包括數據完整性、邏輯一致性、位置精度、屬性精度、接邊精度、現勢性等是否符合國家標准及有關技術規定。專題圖形資料庫建設質量控制的方案如下：
建立數據採集標准規范，詳細闡述不同要素的採集要求，作為數據採集的根本基準，統一採集認識。
進行數據採集人員培訓，熟練使用採集軟硬體，掌握採集規范，採集過程中填寫詳細的圖例簿，統一圖例簿格式，記錄每幅圖數據生產過程的基本情況，特別是作業時遇到的問題及處理意見，質量情況等。
數據質量控制採用分級分層管理方式，首先，數據生產操作人員在數據採集過程中嚴格遵守數據採集規范標准，採集後進行數據的第一次檢查；其次，資料庫集成人員進行第二次數據質量檢查；最後，系統總工隨機抽樣檢查。
檢查方式多種多樣，這里主要採用以下3種：屏幕視覺檢查，列印出圖檢查，查錯軟體檢查。