構築資料庫

Ⅰ 如何建立一個資料庫

MySQL安裝完成後,要想將數據存儲到資料庫的表中,首先要創建一個資料庫。創建資料庫就是在資料庫系統中劃分一塊存儲數據的空間。在MySQL中，創建資料庫的基本語法格式如下所示：

CREATE DATABASE 資料庫名稱;

在上述語法格式中,「CREATE DATABASE」是固定的SQL語句,專門用來創建資料庫。「資料庫名稱」是唯一的，不可重復出現。

例如下面我們創建一個名稱為itcast的資料庫,SQL語句如下所示:

CREATE DATABASE itcast;

執行結果如下所示：

上述執行結果顯示出了資料庫itcast的創建信息，例如，資料庫itcast的編碼方式為utf-8。

Ⅱ 怎樣建立一個簡單資料庫

具體步驟如下：

1、首先打開我們的access程序，打開方法是單擊開始——所有程序。

Ⅲ phpStudy怎樣創建資料庫

1、單擊打開phpstudy軟體，然後單擊mySQL管理器。

(3)構築資料庫擴展閱讀

phpStudy一個PHP調試環境的程序集成包。該程序包集成最新的Apache+PHP+MySQL+phpMyAdmin+ZendOptimizer，一次性安裝，無須配置即可使用，是非常方便、好用的PHP調試環境。該程序不僅包括PHP調試環境，還包括了開發工具、開發手冊等。

1、MySQL資料庫用戶名：root，密碼root，安裝後請重新設置密碼。

2、本程序支持PHP5.3和PHP5.4一鍵切換，支持系統服務和非服務兩種啟動方式，自由切換。改變安裝路徑或拷貝到別的電腦上也可正常運行；即便是運行完再更改路徑也能運行，真正做到無須配置。重寫控制面板更加有效直觀地進行控製程序的啟停。

3、自帶FTP伺服器，支持多用戶，無需再安裝FTP伺服器。自帶網站掛馬監視器，隨時記錄文件的修改情況，讓掛馬文件無處可逃。

4、應網友的要求製作Nginx版和Lighttpd版。Nginx版為phpfind，Lighttpd版為phpLight。

Ⅳ 電子商務資料庫構建步驟是什麼

電子商務的資料庫構建步驟主要有以下幾點：
1.
需求分析：調查和分析用戶的業務活動和數據的使用情況，弄清所用數據的種類、范圍、數量以及它們在業務活動中交流的情況，確定用戶對資料庫系統的使用要求和各種約束條件等，形成用戶需求規約；
2.
概念設計：對用戶要求描述的現實世界，通過對其中住處的分類、聚集和概括，建立抽象的概念數據模型；
3.
邏輯設計：主要工作是將現實世界的概念數據模型設計成資料庫的一種邏輯模式，即適應於某種特定資料庫管理系統所支持的邏輯數據模式；
4.
物理設計：據特定資料庫管理系統所提供的多種存儲結構和存取方法等依賴於具體計算機結構的各項物理設計措施，對具體的應用任務選定最合適的物理存儲結構；
5.
驗證設計：在上述設計的基礎上，收集數據並具體建立一個資料庫，運行一些典型的應用任務來驗證資料庫設計的正確性和合理性等。

Ⅳ 資料庫是指什麼建立網站如何構建資料庫

資料庫就是存放信息的地方，比如一個網站用戶要登錄，那麼要將用戶的用戶名和密碼記錄在資料庫中。
你要建立網站，小型的用Access資料庫就可以了。
資料庫的設計是很麻煩的，因為要根據你的網站來設計。
比如你網站有用戶登錄版塊，那麼需要設計用戶表存在資料庫中。如果有日誌版塊，那麼需要一個日誌表記錄你的日誌，這個表可能有發表時間，題目，內容等欄位。

Ⅵ 如何構建資料庫的主從架構

「資料庫」主要有資料庫外部體系結構、內部體系結構兩種。
從資料庫最終用戶角度看，資料庫系統的結構分為單用戶結構、主從式結構、分布式結構、客戶/伺服器、瀏覽器/應用伺服器/資料庫伺服器多層結構，這是資料庫外部體系結構。
物理存儲結構、邏輯存儲結構、內存結構和實例進程結構，這是內部體系結構。

Ⅶ 求教公司的資料庫構建有哪些要素

簡述資料庫設計過程—希望可以幫你

資料庫設計(Database Design)是指對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統，使之能夠有效地存儲數據，滿足各種用戶的應用需求（信息要求和處理要求）。

在資料庫領域內，常常把使用資料庫的各類系統統稱為資料庫應用系統。

一、資料庫和信息系統
(1)資料庫是信息系統的核心和基礎，把信息系統中大量的數據按一定的模型組織起來，提供存儲、維護、檢索數據的
功能，使信息系統可以方便、及時、准確地從資料庫中獲得所需的信息。
(2)資料庫是信息系統的各個部分能否緊密地結合在一起以及如何結合的關鍵所在。
(3)資料庫設計是信息系統開發和建設的重要組成部分。
(4)資料庫設計人員應該具備的技術和知識：
資料庫的基本知識和資料庫設計技術
計算機科學的基礎知識和程序設計的方法和技巧
軟體工程的原理和方法
應用領域的知識

二、資料庫設計的特點
資料庫建設是硬體、軟體和干件的結合
三分技術，七分管理，十二分基礎數據
技術與管理的界面稱之為逗干件地
資料庫設計應該與應用系統設計相結合
結構（數據）設計：設計資料庫框架或資料庫結構
行為（處理）設計：設計應用程序、事務處理等
結構和行為分離的設計
傳統的軟體工程忽視對應用中數據語義的分析和抽象，只要有可能就盡量推遲數據結構設計的決策早期的資料庫設計致力於數據模型和建模方法研究，忽視了對行為的設計
如圖：

三、資料庫設計方法簡述
手工試湊法
設計質量與設計人員的經驗和水平有直接關系
缺乏科學理論和工程方法的支持，工程的質量難以保證
資料庫運行一段時間後常常又不同程度地發現各種問題，增加了維護代價
規范設計法
手工設計方
基本思想
過程迭代和逐步求精
規范設計法(續)
典型方法：
(1)新奧爾良（New Orleans）方法：將資料庫設計分為四個階段
S.B.Yao方法：將資料庫設計分為五個步驟
I.R.Palmer方法：把資料庫設計當成一步接一步的過程
(2)計算機輔助設計
ORACLE Designer 2000
SYBASE PowerDesigner

四、資料庫設計的基本步驟
資料庫設計的過程(六個階段)
1.需求分析階段
准確了解與分析用戶需求（包括數據與處理）
是整個設計過程的基礎，是最困難、最耗費時間的一步
2.概念結構設計階段
是整個資料庫設計的關鍵
通過對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型
3.邏輯結構設計階段
將概念結構轉換為某個DBMS所支持的數據模型
對其進行優化
4.資料庫物理設計階段
為邏輯數據模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）
5.資料庫實施階段
運用DBMS提供的數據語言、工具及宿主語言，根據邏輯設計和物理設計的結果
建立資料庫，編制與調試應用程序，組織數據入庫，並進行試運行
6.資料庫運行和維護階段
資料庫應用系統經過試運行後即可投入正式運行。
在資料庫系統運行過程中必須不斷地對其進行評價、調整與修改
設計特點:
在設計過程中把資料庫的設計和對資料庫中數據處理的設計緊密結合起來將這兩個方面的需求分析、抽象、設計、實現在各個階段同時進行，相互參照，相互補充，以完善兩方面的設計

設計過程各個階段的設計描述：
如圖：

五、資料庫各級模式的形成過程
1.需求分析階段：綜合各個用戶的應用需求
2.概念設計階段：形成獨立於機器特點，獨立於各個DBMS產品的概念模式(E-R圖)
3.邏輯設計階段：首先將E-R圖轉換成具體的資料庫產品支持的數據模型，如關系模型，形成資料庫邏輯模式；然後根據用戶處理的要求、安全性的考慮，在基本表的基礎上再建立必要的視圖(View)，形成數據的外模式
4.物理設計階段：根據DBMS特點和處理的需要，進行物理存儲安排，建立索引，形成資料庫內模式

六、資料庫設計技巧

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)高性能原則
保證所選購的伺服器，不僅能夠滿足運營系統的運行和業務處理的需要，而且能夠滿足一定時期的業務量增長的需要。一般可以根據經驗公式計算出所需的伺服器TpmC值，然後比較各伺服器廠商和TPC組織公布的TpmC值，選擇相應的機型。同時，用伺服器的市場價/報價除去計算出來的TpmC值得出單位TpmC值的價格，進而選擇高性能價格比的伺服器。
2)可靠性原則
可靠性原則是所有選擇設備和系統中首要考慮的，尤其是在大型的、有大量處理要求的、需要長期運行的系統。考慮伺服器系統的可靠性，不僅要考慮伺服器單個節點的可靠性或穩定性，而且要考慮伺服器與相關輔助系統之間連接的整體可靠性，如：網路系統、安全系統、遠程列印系統等。在必要時，還應考慮對關鍵伺服器採用集群技術，如：雙機熱備份或集群並行訪問技術。
比如，要保證系統(硬體和操作系統)在99.98%的時間內都能夠正常運作(包括維修時間)，則故障停機時間六個月不得超過0.5個小時。伺服器需7×24小時連續運行，因而要求其具有很高的安全可靠性。系統整機平均無故障時間(MTBF)不低於80000小時。伺服器如出現CPU損壞或其它機械故障，都能在20分鍾內由備用的機器自動代替工作，無須人員操作，保證數據完整。
3)可擴展性原則
保證所選購的伺服器具有優秀的可擴展性原則。因為伺服器是所有系統處理的核心，要求具有大數據吞吐速率，包括：I/O速率和網路通訊速率，而且伺服器需要能夠處理一定時期的業務發展所帶來的數據量，需要伺服器能夠在相應時間對其自身根據業務發展的需要進行相應的升級，如：CPU型號升級、內存擴大、硬碟擴大、更換網卡、增加終端數目、掛接磁碟陣列或與其它伺服器組成對集中數據的並發訪問的集群系統等。這都需要所選購的伺服器在整體上具有一個良好的可擴充餘地。一般資料庫和計費應用伺服器在大型計費系統的設計中就會採用集群方式來增加可靠性，其中掛接的磁碟存儲系統，根據數據量和投資考慮，可以採用DAS、NAS或SAN等實現技術。
4)安全性原則
伺服器處理的大都是相關系統的核心數據，其上存放和運行著關鍵的交易和重要的數據。這些交易和數據對於擁有者來說是一筆重要的資產，他們的安全性就非常敏感。伺服器的安全性與系統的整體安全性密不可分，如：網路系統的安全、數據加密、密碼體制等。伺服器在其自身，包括軟硬體，都應該從安全的角度上設計考慮，在藉助於外界的安全設施保障下，更要保證本身的高安全性。
5)可管理性原則
伺服器既是核心又是系統整體中的一個節點部分，就像網路系統需要進行管理維護一樣，也需要對伺服器進行有效的管理。這需要伺服器的軟硬體對標準的管理系統支持，尤其是其上的操作系統，也包括一些重要的系統部件。

Ⅸ 資料庫構建流程

構建相山地區地學空間資料庫是在對各類原始數據或圖件資料進行整理、編輯、處理的基礎上，將各類數據或圖形進行按空間位置整合的過程。其工作流程見圖 2.1。

圖2.1 相山地區多源地學空間資料庫構建流程

2.2.1 資料收集

相山地區有 40 多年的鈾礦勘查和研究歷史，積累了大量地質生產或科學研究資料。筆者收集的面上的資料包括原始的離散數據如航空放射性伽瑪能譜數據、航磁數據、山地重力測量數據、ETM 數據，而地面高精度磁測資料僅收集到文字報告和圖件。上述各類數據均可達到製作 1∶50000 圖件的要求。地質圖採用 1995 年核工業 270 研究所等單位共同實施完成的 「相山火山岩型富大鈾礦找礦模式及攻深方法技術研究」項目的 1∶50000附圖; 採用的 1∶50000 地形圖的情況見表 2.1。

2.2.2 圖層劃分

GIS 資料庫既要存儲和管理屬性數據和空間數據，又要存儲和管理空間拓撲關系數據。數據層原理: 大多數 GIS 都是將數據按照邏輯類型分成不同的數據層進行組織，即按空間數據邏輯或專業屬性分為各種邏輯數據類型或專業數據層。相山地區數字化地質圖包括地理要素和地質要素兩大部分，共設置 9 個圖層，每一圖層 (包括點、線或多邊形) 自動創建與之相對應的屬性表。

表2.1 採用的地形圖情況一覽表

注: 坐標系均為 1954 年北京坐標系，1956 年黃海高程系，等高距為 10 m。

(1) 水系圖層 (L6XS01) : 包括雙線河流、單線河流、水庫或水塘。

(2) 交通及居民地圖層 (L6XS02) : 包括公路和主要自然村及名稱。

(3) 地形等高線圖層 (L6XS03) : 包括地形等高線及高程和山峰高程點。

(4) 蓋層圖層 (D6XS04) : 包括第四系 (Q) 和上白堊統南雄組 (K2n) 及其厚度和主要岩性。

(5) 火山岩系圖層 (L6XS05) : 包括下白堊統打鼓頂組 (K1d) 、鵝湖嶺組 (K1e) 及各種淺成- 超淺成侵入體 (次火山岩體) 的分布和主要岩性特徵。

(6) 基底圖層 (L6XS06) : 含下三疊統安源組 (T3a) 、震旦系 (Z) 、燕山早期花崗岩 (γ5) 、加里東期花崗岩 (γ3) 。

(7) 構造圖層 (L6XS07) : 相山地區褶皺構造不發育，構造圖層主要包括實測的和遙感影像解譯的線性斷裂或環形構造。

(8) 礦產圖層 (L6XS08) : 包括大、中、小型鈾礦床和礦點。

(9) 圖框及圖幅基本信息圖層 (L6XS09) : 數字化地質圖的總體描述，內容包括圖框、角點坐標、涉及的 1∶500000 標准圖幅編號、調查單位及出版年代等。

圖層名編碼結構如下:

相山鈾礦田多源地學信息示範應用

2.2.3 圖形輸入

圖形輸入或稱圖形數字化，是將圖形信息數據化，轉變成按一定數據結構及類型組成的數字化圖形。MapGIS 提供智能掃描矢量化和數字化兩種輸入方式。本次採用掃描矢量化輸入，按點、線參數表事先設定預設參數，分別將地形底圖和地質底圖掃描成柵格圖像的 TIF 文件，按照圖層劃分原則，在計算機內分層進行矢量化。線型、花紋、色標、符號等均按 《數字化地質圖圖層及屬性文件格式》行業標准執行。

對於已建立的圖層，按點、線、多邊形分別編輯修改，結合地質圖、地形圖及相關地質報告，採集添加有關屬性數據，用以表示各圖層點、線、多邊形的特徵。拓撲處理前先將多邊形的地質界線校正到標准圖框內進行修改，去掉與當前圖層區域邊界無關的線或點。對於圖幅邊部不封閉的區域，採用圖框線作為多邊形的邊界線，使圖幅內的多邊形均成為封閉的多邊形。拓撲處理後進行圖形數據與屬性數據掛接。

在 MapGIS 實用服務子系統誤差校正模塊中，將數字化地圖校正到統一的大地坐標系統中。圖形資料庫採用高斯-克呂格 (6 度帶) 投影系統，橢球參數: 北京54/克拉索夫斯基。

MapGIS 數據文件交換功能使系統內部的矢量圖層很容易實現 Shape 和 Coverage 等文件格式的轉換。在圖形處理模塊將上述各圖層轉成 Shape 文件格式。

2.2.4 離散數據網格化

在收集的原始資料中，除 1∶50000 地形圖和地質圖之外，航空放射性伽瑪能譜數據(包括原始的和去條帶處理後的數據) 、航磁數據、山地重力測量數據都是離散的二維表格數據。用 GeoExpl 網格化。GeoExpl 數據處理與分析系統提供了多種網格化計算的數學方法，本次選用克立格插值方法，網格間距 15 m。重力和航磁數據網格化後，進行不同方向或不同深度的延拓處理。所有網格化數據均採用了與上述圖形數據相同的地圖投影和坐標系統。

2.2.5 網格化數據影像化

MapGIS 網格化文件格式為 grd，可直接被 Erdas Imagine 讀取，GeoExpl 網格化文件包括重磁處理反演後的網格化文件可轉換成 Surfer.grd 後，被 Erdas Imagine 讀取。然後將上述網格化數據一一轉成 img 影像數據格式。

2.2.6 DEM 生成

地形等高線 (L6XS03) 文件在 MapGIS 空間分析子系統 DEM 分析模塊中，生成 DEM柵格化文件: L6XS03.grd，再轉成 img 格式，文件名改為: XSDEM。

經過上述程序形成的各類矢量或柵格數據，在 ArcView 平台建立 「相山資料庫」工程文件，將上述各 Shape 圖形和 img 影像文件一一添加到該工程文件中。該工程文件即為相山地區矢量、柵格一體化地學空間資料庫。該資料庫，一可以對這類地學空間信息實現由 GIS 支持的圖層管理，二可以視需要不斷進行數字—圖形—圖像的轉換，三可以將多源地學信息進行疊合和融合，以實現多源地學信息的深化應用和分析，為實現相山地區鈾資源數字勘查奠定基礎。