① 想找一篇資料庫論文、、
資料庫設計與優化
摘 要：資料庫技術是計算機科學中發展最快的領域之一，也是應用最廣的技術之一，它已成為計算機信息系統與應用系統的核心技術和重要基礎。本文討論資料庫設計流程的所有重要方面，包括需求分析階段；概念設計階段；邏輯設計階段；物理設計階段；資料庫實施階段；資料庫運行維護階段的六個階段，並提出資料庫設計中所出現的各種問題，並歸納分析了解決這些問題的種種途徑。
關鍵詞：資料庫設計；數據冗餘；資料庫管理系統
引言：近年來，隨著多媒體技術、空間資料庫技術和計算機網路的飛速發展，資料庫系統的發展十分迅速，應用領域愈來愈廣，企事業單位、政府部門的行政管理、辦公自動化；企業生產計劃管理；軍隊物資管理；銀行財務管理；鐵路、民航飛機票預定系統；鐵路車次調度系統；賓館、酒店房間預定系統；圖書館管理；政府部門的計劃和統計系統；人口普查；氣象預報；地震，勘探等大量數據的貯存和統計分析；以及最近google推出的全球衛星定位系統、手機GPRS定位系統，其背後都是一個規模巨大的資料庫。
如何合理高效地為政府管理人員或企業高層決策人員、設計資料庫管理系統服務已成為當務之急。好的靈活的資料庫設計，既能給前台應用程序的設計帶來簡便，又能給後台資料庫的編碼和擴充，和系統的維護帶來極大的便利。現在關系型資料庫已成為業界的主流，而我們討論的也主要是基於關系型資料庫的。
目前設計資料庫系統主要採用的是以邏輯資料庫設計和物理資料庫設計為核心的規范設計方法。其中邏輯資料庫設計是根據用戶要求和特定資料庫管理系統的具體特點，以資料庫設計理論為依據，設計資料庫的全局邏輯結構和每個用戶的局部邏輯結構。物理資料庫設計是在邏輯結構確定之後，設計資料庫的存儲結構及其他實現細節。
在資料庫設計開始之前，資料庫設計人員將始終參與資料庫設計，他們的水平直接影響了資料庫系統的質量：用戶在資料庫設計中也舉足輕重的，他們主要參加需求分析和資料庫的運行維護，他們的積極參與不但能加速資料庫設計，而且是決定資料庫設計的質量的又一因素。程序員和操作人員則在系統實施階段參與進來，分別負責編製程序和准備軟硬環境。
資料庫設計的總流程
一、 資料庫設計的六個階段
各種規范化設計方法在設計步驟上存在差別，各有千秋。通過分析、比較與綜合各種常見的資料庫規范化設計方法，一般將資料庫設計分為以下六階段：需求分析階段；概念設計階段；邏輯設計階段；物理設計階段；資料庫實施階段；資料庫運行維護階段。（如下圖所示）
二、 需求分析
要設計一個有效的資料庫，必須用系統工程的觀點來考慮問題。在系統分析階段，設計者和用戶雙方要密切合作，共同收集和分析數據管理中信息的內容和用戶對處理的需求。在調研中，首先要了解資料庫所管理的數據將覆蓋哪些工作部門，每個部門的數據來自何處，它們是依照什麼樣的原則處理加工這些數據的，在處理完畢後輸出哪些信息到其他部門。其次要確定系統的邊界，在與用戶充分討論的基礎上，確定計算機數據處理范圍，確定哪些工作要由人工來完成，確定人機介面界面。最後得到業務信息流程圖。信息流程圖中的每個子系統都可抽象為以下所示的框圖。
在系統分析過程中，要確定數據管理的信息要求和處理要求。信息要求是指用戶需要從資料庫中獲得信息的內容與性質。由用戶的信息要求可以導出數據要求，即在資料庫中需要存儲哪些數據。處理要求是指用戶要求完成什麼處理功能，對處理的響應時間有什麼要求，處理方式是批處理還是聯機處理。新系統的功能必須滿足用戶的信息要求，處理要求，安全性和完整性要求。這一階段的工作是否能准確地反映實際系統的信息流程情況和用戶對資料庫系統的要求，直接影響到以後各階段的工作，並影響到資料庫系統將來運行的效率，因為分析階段的工作是整個數據設計的基礎。
三、 概念設計
在需求分析階段資料庫設計人員充分調查並描述了用戶的應用需求，但這些應用需求還是現實世界的具體需求，應該首先把他們抽象為信息世界的結構，才能更好地、更准確地用某個DBMS實現用戶的這些需求。將需求分析得到的用戶需求抽象為信息結構即概念模型的過程就是概念結構設計。概念結構獨立於資料庫邏輯結構，也獨立於支持資料庫的DBMS。它是現實世界與機器世界的中介，它一方面能夠充分反映現實世界，包括實體和實體之間的聯系，同時又易於向關系、網狀、層次等各種數據模型轉換。它是現實世界的一個真實模型，易於理解，便於和不熟悉計算機的用戶交換意見，使用戶易於參與。當現實世界需求改變時，概念結構可以很容易地作出相應調整。因此概念結構設計是整個資料庫設計的關鍵所在。概念結構設計一般需要兩個階段：第一個階段是根據用戶對數據和處理的需求，為產生全局視圖，得到每個用戶各自的局部視圖，對每個用戶的局部數據結構進行描述。第二階段是在定義了各用戶的局部視圖的基礎上，利用一定的工具分析各個局部視圖，並把它們合並成一個統一的全局數據結構，即全局視圖。全局視圖被稱為資料庫概念模型。實際上，概念設計得到的實體模型。由於實體模型（如用E-R方法）不易描述，故實體模型通常是用一些原始表格來描述，這樣比較直觀。
四、 邏輯設計
概念結構是各種數據模型的共同基礎，它比數據模型更獨立於機器，更抽象，從而更加穩定。但為了能夠用某一DBMS實現用戶需要，還必須將概念結構進一步轉化為相應的數據模型，這正是資料庫邏輯結構設計所要完成的任務。從理論上講，設計邏輯結構應該選擇最適於描述與表達相應概念的結構模型，然後對支持這種數據模型的各種DBMS進行比較，綜合考慮性能、價格等各種因素，從中選出最合適的DBMS。但在實際當中，往往是已給定了某台機器，設計人員沒有選擇DBMS的餘地。目前DBMS產品一般只支持關系、網狀、層次3種模型中的某一種，對某一種數據模型，各個機器系統又有許多不同的限制，提供不同的環境與工具。所以設計邏輯結構的一般要分3步進行：
將概念結構轉化為一般的關系、網狀、層次模型。
將轉化來的關系、網狀、層次模型向特定DBMS支持下的數據模型轉換。
對數據模型進行優化。
一般資料庫邏輯設計的結果要符合下面的准則：
把以同樣方式使用的段類型存儲在一起。
按照標准使用來設計系統。
在用於例外的分離區域。
最小化表空間沖突。
將數據字典分離。
五、 物理設計
對於給定的邏輯數據模型選取一個最適合應用環境的物理結構的過程為物理設計。資料庫的物理結構主要指資料庫的存儲記錄格式、存儲記錄安排和存儲方法，這些都依賴於所使用的系統。在網狀模型和層次模型系統中，這一部分內容較復雜，因為它們是用指針表示記錄的聯系。關系模型系統比較簡單一些，僅包含索引機制、空間大小、塊的大小等內容。在設計物理結構時，應先確定資料庫的物理結構，然後對物理結構進行評價。評價的重點是時間和空間的效率。數據的存儲決定了資料庫佔用多少空間，數據的處理決定了操作時間的效率。物理結構設計應盡量減少存儲空間的佔用，也應盡量減少操作次數，做到相應時間越快越好。如果評價結果滿足原設計要求，則轉向物理實施。否則，就要重新修改或重新設計物理結構，有時甚至要回到邏輯設計階段修改數據模型。物理設計完成之後，就應該得到詳細的磁碟分配方案、存儲方案、各種基表的詳細信息等。根據這些信息就可以上機建立資料庫。
六、 資料庫實施
對資料庫的物理設計初步評價完後，就可以開始建立資料庫了。資料庫實施主要包括：用DDL定義資料庫結構，組織數據入庫，編制與調試應用程序，資料庫試運行。所謂使用DDL定義資料庫結構，就是使用DBMS的建庫命令建立相應的用戶資料庫結構。組織資料庫入庫就是將裝載在其他介質上的數據輸入到資料庫中去。為了完成相應的操作和檢索，需要編制很多程序，形成一個程序系統來使用該資料庫，這部分是程序設計的任務。一切就緒之後，就可以試運行資料庫了。
七、 系統管理和維護
資料庫試運行結果符合設計目標後就可以真正投入運行了。資料庫投入運行標志著開發任務基本完成和維護工作開始，並不意味著設計過程的終結。由於應用環境在不斷地變化，資料庫運行過程中物理存儲也不會不斷變化。對資料庫設計進行評價、調整、修改等維護工作是一項長期的任務，也是設計工作的繼續和改進。
在資料庫運行的階，對資料庫經常性的維護工作主要由DBA完成，這包括以下內容：
資料庫的轉儲和恢復
資料庫的安全性、完整性控制
資料庫的性能監督、分析和改進
資料庫的重組織和重構造
解決資料庫設計中存在的問題
一、需求分析採集
設計一個資料庫，第一件的事情就是搞好用戶需求分析，需求分析是對現實世界深入了解的過程，資料庫能否正確地反映現實世界，主要決定於需求分析。而需求分析的採集主要是由設計人員和該單位有關工作人員合作進行的。需求分析的結果整理成需求說明。需求說明是資料庫技術人員和應用單位的工作人員取得共識的基礎，必須得到有關管理人員確認。需求說明經過評審後，才成為正式的需求文檔，為下一步的資料庫設計打好基礎。在定義資料庫表和欄位需求（輸入）時，首先應檢查現有的或者已經設計出的報表、查詢和視圖（輸出）以決定為了支持這些輸出哪些是必要的表和欄位。假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼欄位而不要把郵政編碼糅進地址欄位里。
二、考察現有系統
在需求分析採集的過程中，不僅要耐心地和用戶討論業務需求而且還要考察現有的系統。大多數資料庫項目都不是從頭開始建立的；通常，機構內總會存在用來滿足特定需求的現有系統（可能沒有實現自動計算）。顯然，現有系統並不完美，否則你就不必再建立新系統了。
三、分析各種可能的變化
在具體設計每一個欄位時一定要從長遠角度考慮它以後的擴充，給出一定的預留空間。這樣你設計的資料庫的伸縮性就非常好。以後在系統升級維護時就非常容易，不至於重構整個系統。這方面的一個典型例子就是：身份證的長度問題，以前是15位，現在是18位，如果你當時設計成15位的話，為那3位的擴充你將會付出多大代價啊。
四、資料庫邏輯性設計
鍵選擇原則：
1.鍵設計原則為關聯欄位創建外鍵。所有的鍵都必須唯一；避免使用復合鍵。外鍵總是關聯唯一的鍵欄位。
2.使用系統生成的主鍵。設計資料庫的時候採用系統生成的鍵作為主鍵，那麼實際控制了資料庫的索引完整性。這樣，資料庫和非人工機制就有效地控制了對存儲數據中每一行的訪問。採用系統生成鍵作為主鍵還有一個優點：當擁有一致的鍵結構時，找到邏輯缺陷很容易。
五、關系模式規范化的度
對資料庫進行關系模式規范化不僅有助於消除資料庫中的數據冗餘、刪除、插入等異常出錯的可能性，而且，還使你的設計比較科學、規范，同時也使你的系統的伸縮性，以及後期維護特別容易。
3NF通常被認為在性能、擴展性和數據完整性方面達到了最好平衡。其定義為：關系R中若不存在這樣的碼X、屬性組Y及非主屬性Z(Z包含於Y)使得X決定Y、Y不依賴於X、Y決定Z成立，則稱R屬於3NF。
此外，還有BCNF，4NF、5NF等更高層次的關系規范化，但是不是關系規范化的程序越高， 就越實用呢，就越能滿足我們的要求呢？我只能用不一定來回答，因為這要視情況而定。其實，在有些項目中是非常慎用關系模式的。因為如果規范化的程序越高，勢必要將一個大表拆分成幾個小表，在這些小表中用一些鍵值進行聯接，在查詢時就需要對多個表進行連接，而聯接時最易產生迪卡爾積，這樣查詢結果集就成幾何倍增，非常影響查詢的效率。所以為了追求效率我們有時不對表進行關系規范化也是必要的，這樣的例子很多。
六、要為盡量減輕前台的編碼而工作
不要養成對資料庫的復雜操作都放到前台來管理的習慣，這樣會使你的程序的可讀性非常差，同時也造成數據的不一致，而且會對後期的維護帶來很大隱患。這一塊完全應該是DBA的工作。這方面的典型例子就是數據的更新和刪除操作。如果我們把這兩種操作都放在前台來管理的話，就需要對多個表進行操作，操作不當的話，就會造成數據不一致。而如果DBA在後台對這幾個表搭建關系的話，你在前台只要對一個主表進行操作，那麼其他的幾個從表就會自動更新。由此可見DBA的工作的重要性。所以，請不要把數據的管理工作都放到前台來做，因為這不是體現你編程能力的時機。
七、合理使用數據類型
我們要合理使用一些常規的數據類型，這樣不僅能減少數據冗餘，而且也能使你的設計更加科學、明確，同時也能使你的數據更加准確。如Oracle9i中有一個float類型，它並沒有限定小數位，如果你輸入時帶小數位的話，它會將它精確得很長，雖然你在往資料庫中存放時限定了小數位，但當你在前台進行輸出時，就有可能出現小數位精度過度的情況，所以可用numeric來替代。但同時又有另一個問題發生了：例如我們用asp開發網站時用的vbscript就不支持該類型（它只認float）。所以我們應該綜合考慮多種因素酌情設計。
八、用視圖隱藏細節
我們考慮這樣的情況，當我們在進行資料庫模式設計時需要將一張大表拆分為幾張小表，而在進行查詢時又需要將幾張小表合並為一張大表。如果表比較多的話，我們就要編寫復雜的SQL語句，有沒有一種機制將這幾張小表一次合並為一張虛表，然後對一張表查詢，這樣操作起來就會簡單得多。答案是肯定的。在Oracle9i中可以用視圖解決。視圖是在你的資料庫和你的應用程序代碼之間提供另一層抽象，你可以為你的應用程序建立專門的視圖而不必非要應用程序直接訪問數據表。這樣做還等於在處理資料庫變更時給你提供了更多的自由，同時也對數據的一些底層操作進行了隱藏。
結論
總之，我們在進行資料庫設計時，一定要綜合考慮多種因素，具體問題具體分析，既要考慮當前實現的可行性，又要考慮以後的升級維護；既要減輕前台編碼的負擔，又要讓後台的管理簡單易行；既要讓前台的查詢效率高，又要讓後台的實現方便可行。資料庫設計是一項綜合性設計，決非一朝一夕之功，只有在工作、學習中多思考、多動腦、多總結、靈活運用所學知識，綜合考慮各種因素，平衡把握每個細節，這樣資料庫設計才會更加科學、合理。
參考文獻：
1 大型資料庫技術及應用 重慶大學出版社 王 越 劉加伶 李 梁 著
2 資料庫系統概論 高等教育出版社 王 珊 薩師煊 著
3 資料庫管理系統 清華大學出版社 尹買華 著
4 軟體設計方法 清華大學出版社 王 選 著 5 資料庫設計 機械工業出版社 何玉潔 著
② 怎樣設計一個好的資料庫
資料庫設計(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）模式：模式也稱邏輯模式或概念模式。
優點：是資料庫中全體數據的邏輯結構和特徵的描述,是所有用戶的公共數據視圖.
（2）外模式：外模式也稱用戶模式。
優點：它是資料庫用戶能夠看見和使用的局部數據的邏輯結構和特徵的描述,是資料庫用戶的數據視圖,是與某一應用有關的數據的邏輯表示.外模式通常是模式的子集.
（3）內模式：內模式也稱存儲模式。
優點：一個資料庫只有一個內模式.它是數據物理結構和存儲方式的描述,是數據在資料庫內部的表示方式。
④ 資料庫邏輯模型
資料庫關系模型（資料庫邏輯模型）是將數據概念模型轉換為所使用的資料庫管理系統（DBMS）支持的資料庫邏輯結構，即將E-R圖表示成關系資料庫模式。資料庫邏輯設計的結果不是唯一的，需利用規范化理論對資料庫結構進行優化。
在關系模型中，資料庫的邏輯結構是一張二維表。在資料庫中，滿足下列條件的二維表稱為關系模型：
1）每列中的分量是類型相同的數據；
2）列的順序可以是任意的；
3）行的順序可以是任意的；
4）表中的分量是不可再分割的最小數據項，即表中不允許有子表；
5）表中的任意兩行不能完全相同。
由此可見，有序的航空物探測量剖面數據不滿足資料庫關系模型條件第3條「行的順序可以是任意的」，因此，不能簡單地直接利用關系資料庫（如Oracle，SQL Server，Sybase等）來管理剖面數據，需將數據在資料庫中的存儲方式改為大欄位存儲，確保不因資料庫數據的增加和刪除等操作改變剖面數據有序特性。
一、大欄位存儲
（一）大欄位存儲技術
大欄位LOB（Large Object）技術是Oracle專門用於存放處理大對象類型數據（如多媒體材料、影像資料、文檔資料等）的數據管理技術。LOB包括內部的和外部的兩種類型。內部LOB又分CLOB（字元型）、BLOB（二進制型）等3種數據類型，其數據存儲在資料庫中，並且支持事務操作；外部LOB只有BFILE類型，其數據存儲在操作系統中，並且不支持事務操作。LOB存放數據的長度最大可以達到4G位元組，並且空值列（沒有存放數據）不佔空間（圖2-6）。
圖2-6 大欄位存儲示意圖
由於外部LOB存放在操作系統文件中，其安全性比內部LOB差一些。此外，大欄位的存儲支持事務操作（批量提交和回滾等），而外部LOB不支持事務操作。所以，航空物探測量剖面數據採用BLOB來存儲。對於BLOB類型，如果數據量小於4000位元組，資料庫通常採用行內存儲，而數據量大於4000位元組採用行外存儲。分析航空物探測量剖面數據，每個場值數據佔4個位元組（單精度），目前航磁數據采樣率為10次/s，4000位元組只能存儲100 s數據；一般情況下航空物探測量每條測線飛行時間至少在10 min以上，每條測線數據量遠遠大於4000位元組。所以，航空物探測量剖面數據採用行外存儲方式，即大欄位列指定「Disable Storage In Row」的存儲參數。
由於大欄位類型長度可變，最大可到4G。假設測線飛行時間為T，場值采樣率為n次/s，測線場值數據量為4Tn，所以有4Tn≤4G。單條測線飛行時間T不會超過10 h（36000 s，航空物探測量1架次至少飛行1個往返2條測線），則場值的采樣率n≤4G/4T=4×1024×1024×1024/4×36000次/s=29826次/s。採用大欄位來存儲測量數據，不僅能夠減少數據表的記錄數，提高查詢效率，而且使得采樣率的擴展不受限制。
（二）大欄位存儲技術應用
由於航空物探數據的數據量較大，現有的航磁測量數據按基準點方式（點存儲）存儲可達幾億個數據記錄。若按磁場數據采樣點存儲方式（簡稱「場值存儲方式」），則記錄條數=（磁場數據采樣率/坐標采樣率）點存儲方式的記錄數，達幾十億條數據記錄，且隨著數據采樣率的擴展、測點的加密，航空物探測量數據量隨著時間的推移呈現快速增長之勢。顯然，如果採用常規的表結構來存儲，勢必造成數據的存儲、管理、檢索、瀏覽和提取都非常困難。另一方面，從航空物探專業應用需求來說，很少對單個測點的場值數據進行運算、分析等操作，一般至少是對一條測線或以上測線，多數時候是需要對整個測區的場值數據進行化極、上延、正反演擬合等。
因此，在航空物探資料庫表結構設計時，改變過去將基準點或場值點數據記錄作為資料庫最小管理對象的理念，採用了大欄位存儲技術，將測線作為資料庫最小管理對象，將測線上的測量數據，如坐標數據和磁場、重力場數據分別存儲在相應大欄位中。在航空物探資料庫建設中，大量採用資料庫的大欄位存儲技術（詳見《航空物探信息系統資料庫結構設計》）。
（三）大欄位存儲效率
以航磁測量數據為例分析大欄位存儲技術優勢。如果以場值存儲方式存儲測線數據，則每條記錄包含架次號、測線號、基準號、地理坐標、投影坐標、磁場數據等，由於坐標數據采樣率2次/s，磁場數據采樣率10次/s，每5個磁場數據中，只有第1個磁場數據有坐標數據，其他4個坐標數據是內插出來，因此在測線記錄中會產生大量冗餘的數據坐標數據。採用點存儲方式存儲的測線數據記錄數等於線上基準點數，若採用大欄位存儲方式，一條測線數據只存儲為1條數據記錄（圖2-7），一般一條測線的測點數近萬個，甚至更多，可見採用大欄位存儲大大減少測線數據存儲記錄數，提高數據的存取效率。
以某測區的兩條航跡線為例，分別採用3種方式測試資料庫的數據存儲效率。磁場數據的采樣率10次/s，坐標數據采樣率2次/s，兩條測線上共有基準點8801個。以場值方式存儲先內插坐標信息，使得每個場值數據都擁有自己的坐標，然後存入資料庫，共有數據記錄44005條，寫入資料庫時間為57.22 s，讀取時間為1.03 s。第二種方式是以采樣點的方式進行存儲，共有8801條記錄，寫入資料庫時間為9.47 s，讀取需要0.91 s。第三種方式是以大欄位的形式存儲，只有2條記錄，寫入資料庫1.03 s，讀取時間為0.44 s（表2-2）。大欄位數據存儲記錄數最少，存取效率最高。用整個測區數據測試效果更加明顯。
表2-2 三種數據存儲方法的存取效率比較
圖2-7 大欄位存儲方式示意圖
二、聯合主鍵
主外鍵是關系型資料庫建立表間關系的核心。在航空物探空間資料庫建設過程中，要素類與要素類之間、要素類與對象類之間，以及對象類與對象類之間的關系的描述有3種形式，即拓撲關系——描述要素類與要素類之間結點、鄰接和聯通關系；疊加關系——描述要素類與要素類之間的相交、包含與分類關系；隸屬關系——描述對象類與對象類之間的派生關系。前兩種關系是採用空間數據模型建立的關系，而隸屬關系是通過主鍵建立的對象類與對象類之間的關系。在建立一對一、一對多的表間關系時，需要在整個資料庫表中確定具有唯一性的一個欄位作為主鍵（主關鍵字）。
按照傳統的航空物探數據的檔案管理模式，每個項目分配一個自然數作為檔案號，項目的所有資料均與此檔案號相聯系。勘查項目和科研項目的檔案號是獨立編號的，且均從001開始。加之人工管理的原因，存在1個項目2個檔案號和2個項目1個檔案號的情況，因此現行的檔案號與項目之間的對應關系不具備唯一性，不能作為項目的唯一標識，即不能作為資料庫表的主鍵。項目編號也不能作為資料庫表的主鍵，項目編號也只是近十年的事，以前的項目沒有項目編號。
綜合考慮上述因素和項目具有分級、分類的特點，提出了構造項目唯一標識碼（簡稱「項目標識」）的方法，並以此碼作為資料庫表的主鍵。
項目標識（主鍵）：AGS+項目類別（2位）+項目起始年份（4位）+檔案號（6位）
標識含義：AGS——航空物探的縮位代碼；
項目類別——2位代碼，01代表勘查項目、02代表科研項目；
起始年份——4位代碼，項目開始年號；
檔案號——6位代碼，為了與傳統的項目管理方式相銜接，後面3～4位是
項目檔案管理模式下的檔案號，不足部分補零。
以上15位編碼是一級項目的項目標識，二級及其以下級別的項目標識是在上一級項目標識基礎上擴展2位數字代碼，中間用「.」號隔開，數字為該級項目的序號。項目標識定義為30位編碼，適用於六級以內的項目。例如：AGS022004000576.08.04.02，表示該項目為2004年開展的檔案號為576的航空物探科研項目（一級項目）的第8課題（二級項目）第4子課題（三級項目）的第2專題。由此可見，該項目標識不僅僅是一個建立表間關系的關鍵字，同時還表達了不同級別項目間的隸屬關系。在系統軟體開發時，利用此關系生成了項目的分級樹形目錄，用戶對項目的層次關系一目瞭然，便於項目查詢。
資料庫的主鍵一經確定，相應地需要確定聯合主鍵的組成及其表達方式。所謂聯合主鍵就是數據資料的唯一標識，在一個資料庫表中選擇2個或者2個以上的欄位作為主鍵。由於航空物探數據絕大部分與項目標識有關，加之數據的種類較多，分類復雜，單憑主鍵確定資料庫表中記錄的唯一性，勢必需要構建極其復雜的主鍵，這種方法既不利於主鍵的數據操作，又會造成大量的數據冗餘，合理地使用聯合主鍵技術可以很好地解決資料唯一問題。以項目提交資料為例，提交的資料分為文字類資料、圖件類資料和媒體類資料，我們對資料進行分類和編號，例如100代表文字資料（110——World文檔，120——PDF文檔），200代表圖件資料（210——基礎地理資料、220——基礎地質資料，230——航跡線圖，240——剖面圖，250——等值線圖等），300代表媒體資料（310——PPT文檔，320——照片等），第1位（百位）表示該資料的類型，第2～3位表示該類資料的序號。
在資料庫管理和項目資料查詢時，採用項目標識與資料分類編號作為聯合主鍵（圖2-8），可以高效地實現復雜數據的查詢。在整個資料庫系統中多處（項目查詢、數據提取等模塊）使用聯合主鍵技術。
圖2-8 聯合主鍵實例
三、信息標准化
為了實現數據共享，在航空物探資料庫建模過程中，參考和引用了近百個國家信息化標准，編制了4個中心信息化標准和1個圖件信息化工作指南。
（一）引用的國家信息化標准
1）地質礦產術語分類代碼：地球物理勘查，地球化學勘查，大地構造學，工程地質學，結晶學及礦物學，礦床學，水文地質學，岩石學，地質學等。
2）國家基礎信息數據分類與代碼，國土基礎信息數據分類與代碼，地球物理勘查技術符號，地面重力測量規范，地面磁勘查技術規程，地面高精度磁測技術規程，大比例尺重力勘查規范，地理信息技術基本術語，地理點位置的緯度、經度和高程的標准表示法，地名分類與類別代碼編制規則。
3）地球空間數據交換格式；數學數字地理底圖數據交換格式；數字化地質圖圖層及屬性文件格式。
（二）本系統建立的信息化標准
編寫了「航空物探空間數據要素類和對象類劃分標准」，「航空物探項目管理和資料管理分類代碼標准」，「航空物探勘查分類代碼標准」，「航空物探信息系統元數據標准」，「航空物探圖件信息化工作指南」，以便與其他應用系統進行信息交換，實現資料庫資料共享。
航空物探空間數據要素類和對象類劃分標准：根據物探方法、數據處理過程以及推斷解釋方法和過程，把與GIS有關的數據劃分為不同類型的要素類-對象類數據，按專業、比例尺、數據內容對要素類和對象類進行統一命名，使空間資料庫中的每個要素類和對象類的命名具有唯一性，防止重名出現。規定要素類-對象類資料庫表結構及數據項數值類型。
航空物探項目管理和資料管理分類代碼標准：規定了航空物探項目管理和資料管理的相關內容，包括航空物探勘查項目和科研項目的項目立項、設計、實施、成果、評審、資料匯交等項目管理的全過程中的內容，以及項目成果資料和收集資料的歸檔、發送、銷毀、借閱等資料管理與服務過程中的內容和數據項代碼。
航空物探勘查分類代碼標准：在「地質礦產術語分類代碼 地球物理勘查」（國家標准GB/T 9649.28—1998）增加了航磁、航重專業方面所涉及的數據採集、物性參數、方法手段、儀器設備、資料數據解釋及成圖圖件等內容和數據項代碼。
航空物探信息系統元數據標准：規定了航空物探空間數據管理與服務的元數據（數據的標識、內容、質量、狀況及其他有關特徵）的內容。
四、航跡線數據模型
（一）航跡線模型的結構
航空物探測量是依據測量比例尺在測區內布置測網（測線和切割線）。當飛機沿著設計的測線飛行測量時，航空物探數據收錄系統按照一定的采樣率採集采樣點的地理位置、高度和各種地球物理場信息。採用屬性數據分置的方法，將測線地理位置信息從航空物探測量數據中分離出來，形成航跡線要素類表，在此表中只存儲與航跡線要素類有關的數據，如項目標識、測區編號、測線號、測線類型（用於區分測線、切割線、不同高度線、重復線等）、坐標、高度值等；將航跡線的對象類數據（磁場、重力場基礎數據）分別以大欄位形式存儲在各自的二維表中，它們共享航跡線，解決了多源有序不同采樣率的航空物探測量數據的數據存儲問題，在滿足要素類空間查詢的同時，統一數據的存儲方式（圖2-9）。航跡線要素類隸屬於測區要素類，它們之間為空間拓撲（包含）關系。測區從屬於勘查項目，每個勘查項目至少有一個測區，它們之間為1對多關系。有關項目信息存放在項目概況信息對象類表中，各種表之間通過項目標識進行聯接。
圖2-9 航跡線數據模型結構
（二）航跡線的UML模型
統一建模語言UML（Unified Modeling Language）是一種定義良好、易於表達、功能強大且普遍適用的建模語言。它溶入了軟體工程領域的新思想、新方法和新技術。UML是面向對象技術領域內佔主導地位的標准建模語言，成為可視化建模語言的工業標准。在UML基礎上，ESRI定義了空間資料庫建模的ArcGIS包、類庫和擴展原則。
圖2-10 與航跡線有關的資料庫表邏輯模型結構圖
在確定航跡線數據模型後，以它為基礎，使用UML完成與航跡的有關的項目概況信息、測區信息、原始數據等資料庫表邏輯模型設計（圖2-10）。
由UML模型生成Geodatabase模式時，模型中的每個類都對應生成一個要素類或對象類。類的屬性映射為要素類或對象類的欄位。基類屬性中包含的欄位，在繼承類中不需重復創建。例如，每個類都包括項目標識等欄位，可以創建一個包含公共屬性的基類，其他類從該類繼承公共的屬性，而無需重復建基類中包含的屬性。因為基類沒有對應的要素類或對象類，所以將基類設置為抽象類型。要素類之間的關系採用依賴關系表示。
五、資料庫邏輯模型
關系資料庫的邏輯結構由一組關系模式組成，因而從概念結構到關系資料庫邏輯結構的轉換就是將概念設計中所得到的概念結構（ER圖）轉換成等價的UML關系模式（圖2-11）。在UML模型圖中，要素數據集用Geodatabase工作空間下的靜態包表示。要素集包不能互相嵌套，為了容易組織，在生成物理模型後，在要素數據集包中自定義嵌套。要素數據集與空間參考有關，但是空間參考不能在UML中表達。要素類和二維表都是以類的形式創建的，區別是要素類繼承Feature Class的屬性，而二維表繼承Object屬性。為了表達每種元素的額外屬性，比如設置字元型屬性欄位的字元串長度，設置要素類的幾何類型（點、線或面）需要使用Geodatabase預定義的元素標記值。
圖2-11 邏輯設計關系轉換
基於航空物探數據的內在邏輯關系進行分析，使用統一建模語言（UML）構建數據實體對象間的關系類，定義了航空物探資料庫的邏輯模型（圖2-12）。