第一篇：數據庫設計

目 錄 1 設計時間.....................................................................................................................................................1 2 設計目的.....................................................................................................................................................1 3 設計任務.....................................................................................................................................................1 4 設計內容................................................................................................................................................1 4.1需求分析...................................................................................................................................................2 4.2概念結構設計...................................................................................................................................................2 4.3邏輯結構設計...................................................................................................................................................5 4.5數據庫表空間和表設計...................................................................................................................................................6 4.6數據庫的實施...................................................................................................................................................8 4.7創建其它數據庫對象....................................................................................................................................................10 5總結與展望........................................................................................................................................................11 參考文獻.......................................................................................................................................................12 設計時間

時間：17周（2011年6月3~2011年6月8日）2 設計目的

數據庫原理及應用課程設計是軟件工程專業集中實踐性環節之一，是學習完《數據庫原理及應用》課程后進行的一次全面的綜合練習。其目的在于加深對數據庫基礎理論和基本知識的理解，掌握使用數據庫進行軟件設計的基本方法，提高運用數據庫解決實際問題的能力，最終實現對于給定的應用環境，構造最優的數據庫模式，建立數據庫及其應用系統，使之能夠有效地存儲數據，滿足各種用戶的應用需求（信息要求和處理要求）。同時，此次設計對于同學將來的畢業設計和具體工作實踐將有重要的意義。近年來，隨著計算機技術的發展和電腦的普及，特別是企業上網工程和辦公自動化的進展迅猛，越來越多的企業在管理部門紛紛采用MIS通過辦公室的一臺PC機完成復雜的日常業務處理，從而減少工作量提高效率。在這樣的背景下，更多的國有大中型企業從中受益。通常這樣的企業存在部門多，業務雜，數據流量大的特點，如果在各個部門使用一個針對性強，操作簡單而數據處理功能強大的MIS，無疑是能起到事半功倍的效果。3 設計任務

房產管理系統應具有分房、調房、退房和咨詢統計功能，同時應能對房產信息、住房信息、住戶基本信息及住戶家庭信息等進行管理，并建立住房和住戶之間的對應關系。對這些信息應能進行方便快捷的新增、修改和刪除等操作，另外還能快速找到所需的信息，這個就是 需要查詢功能 4 設計內容

房產管理系統。系統主要功能 1.分房，調房，退房詢，咨統計

2.用戶可以查詢房產信息，住房信息，住戶信息，住戶家庭信息 3.刪除，修改，新增信息 4.1需求分析

房產科把用戶申請表（按照統一的格式由用戶填寫）輸入系統后，系統首先檢查申請表的合法性，對不合法的申請表系統拒絕接受，對合法的申請表根據類型分別進行處理。

如果是分房申請，則根據申請者的情況計算其分數，當分數高于閾值分數時，按分數高低將申請單插到分房隊列的適當位置。每月最后一天進行一次分房活動，從空房文件中讀出空房信息，把好房優先分配給排在分房隊列前面的符合該登記住房條件的申請者，從空房文件中刪除掉這個房號的信息，從分房隊列中刪除申請單，并把此房號的信息和住戶信息一起寫到住房文件中，輸出住房分配單給住戶，同時計算房租并將算出的房租寫到房租文件中。如果是調房申請，則根據申請者的情況確定其住房等級，然后在空房文件中查找屬于給等級的空房，退掉原住房，再進行與分房類似的處理。如果是退房申請，則從住房文件和房租文件中刪除有關的信息，再把此房號的信息寫到空房文件中。

住戶可向系統詢問目前分房的閾值分數，居住某類房屋的條件，某房號的單位面積房租等信息。房產科可以要求系統打印出住房情況的統計表，或更改某類房屋的居住條件、單位面積房租等。

4.2概念結構設計

E-R圖是分為兩部分實體和屬性，每個實體可以有多個屬性，這些屬性用來表示實體的性質。不同實體之間可以用關系進行連接，表明各個實體之間的內在聯系。實體和實體之間的關系有一對一的關系（1：1），一對多的關系（1：N）和多對多的關系（N：M）。4.2.1 用戶與住房E-R圖 圖 4.2.1

4.2.2 管理員與用戶E-R圖

圖4.2.2 4.2.3操作員和住房E-R圖

圖4.2.3

4.3邏輯結構設計

數據庫邏輯設計的任務是將概念結構轉換成特定DBMS所支持的數據模型的過程。從此開始便進入了“實現設計”階段，需要考慮到具體的DBMS的性能、具體的數據模型特點。

從E-R圖所表示的概念模型可以轉換成任何一種具體的DBMS所支持的數據模型，如網狀模型、層次模型和關系模型。這里只討論關系數據庫的邏輯設計問題，所以只介紹E-R圖如何向關系模型進行轉換。

關系模型的邏輯結構是一組關系模式的集合。E-R圖則是由實體，實體的屬性和實體間的聯系三個要素組成。所以將E-R圖轉換為關系模型實際上就是要將實體，實體的屬性和實體間的聯系轉換為關系模式。轉換原則如下。

1.實體類型的轉換:一個實體型轉換成一個關系模式。實體的屬性就是關系的屬性，實體的碼就是關系的碼。

2．聯系類型的轉換，根據不同的情況做不同的處理。

（1）一個1：1的聯系可以轉換為一個獨立的關系模式，也可以與任意一端對應的關系模式合并。如果轉換為一個獨立的關系模式，則與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性，每個實體的碼均是該關系的候選碼。如果與某一端實體對應的關系模式合并，則需要在該關系模式的屬性中加入另一個關系模式的碼和聯系本身的屬性。

（2）一個１：N的聯系可以轉換為一個獨立的關系模式，也可以與N端對應的關系模式合并。如果轉換為一個獨立的關系模式，則與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性，而關系的碼為N端實體的碼。（3）一個M：N聯系轉換為一個關系模式。與該聯系相連的各實體的碼為各實體碼的組合。（4）三個或三個以上實體間的一個多元聯系可以轉換為一個關系模式。與該多元聯系相連的各實休的碼以及聯系本身的屬性均轉換為關系的屬性，而關系的碼為各實體碼的組合。

（5）具有相同碼的關系模式可合并。

3.根據學生宿舍管理系統的E-R圖轉換為關系模型如下。

將每一個實體轉換成一個關系（關系就是給出關系名，屬性就是實體屬性，并標明該關系的主鍵用下劃線來表示）關系模式：

用戶信息表（戶主，部門，職稱，人口，房號）住房要求（戶主，要求）住房標準（面積，最低分數）

房產文件（房號，住房面積，分配標志，房租）

住房文件（戶主，職稱，部門，人口，分數，房號，住房面積）分房要求（戶主，部門，職稱，人口，分數，要求面積）退房要求（部門，房號）

調房要求（戶主，部門，職稱，人口，分數，面積，房號，申請面積）以上關系模式均為3NF。

4.5數據庫表空間和表結構設計

4.6數據庫的實施

1、登錄信息loca-in create table loca-in(Local-id char(20)not null, Local-p char（20）not null Local-r char(10)not null)tablespace susyhe_data;

2、用戶信息表user_info create table user_info(huzhu char（20）not null, primary key(huzhu)bumen char(20)not null, zhicheng char(10)not null, renkou char(8), fanghao int)tablespace sushe _data;

3、住房要求user_q create table user_q(huzhu char(20)not null, foreign key references faculty(huzhu), yaoqiu char(10)not null,)tablespace sushe_data;

4、住房標準zhu_b create table zhu_b(mianji int not null, primary key(huzhu), zuidifenshu int not null,)tablespace sushe _data;

5、住房文件zhu_w create table zhu_w(huzhu char(20)not null, primary key(huzhu)zhicheng char(10)not null, bumen char(20)not null, foreign key references major(bumen), fenshu int not null, renkou int fanghao char(4)zhufangmianji int)tablespace sushe _data;

6、房產文件fang_w create table fang_w(fanghao char(4)primary key, fenpeibiaozhi char(4)not null, fangzu int not null, zhufangmianji int not null,)Tablespace sushe_data;

7、分房要求fang_q create table fang_q(huzhu char(20)primary key not null, bumen char(20)not null, zhicheng char(10)not null, renkou int not null, fenshu int not null, yaoqiumianji int not nul)tablespace sushe_data;

8、調房要求tiao_q create table tiao_q(huzhu char(20)not null, primary key bymen char(20)not null, zhicheng char(10)not null renkou int not null fenshu int not null mianji int not null fanghao char(4)not null shenqingmianji int not null)tablespace sushe_data;

9、退房要求tui_q create table tui_q(bumen char(20)primary key, fanghao char(4)not null,)tablespace sushe_data;

4.7創建其它數據庫對象 視圖的創建：

創建視圖用于查尋用戶信息 CREATE VIEW yhxx AS SELECT yaoqiu,zhufangmianji FROM user_info JOIN user_q ON user_info.huzhu= user_q.huzhu JOIN zhu_w ON user_q.huzhu=zhu_w.huzhu 觸發器的創建：

創建觸發器zfq，使得在退房要求表中執行退房申請時，則從住房文件和房租文 件中刪除有關的信息，再把此房號的信息寫到空房文件中

CREATE TRIGGER zfq ON tui_q FOR delect AS BEGIN delect tui_q SET bumen,fanghao to fang_w END.存儲過程的創建：

創建一個存儲過程fang_w1，輸入房號，返回分配標志，房租，住房面積。（一個輸入變量，三個輸出變量）

CREATE PROC fang_w1 @fanghao char(4),@fenpeibiaozhi char(4)output,@fangzu int output,@zhufangmianji int output, AS SELECT @fenbeibiaozhi=分配標志,@fangzu=房租,@zhufangmianji=住房面積 FROM fang_w WHERE 房號=@fangha 5總結與展望

在課程設計中也遇到很多問題，在和同學與老師交流過程中都得到解決，也處理了一些在理論課上沒遇到的問題與困難，對今后學習很有幫助。短短一周的課程設計已經結束，在課程設計中每個人都遇到了一定的問題，通過老師和同學的幫助、指導所有問題都得到了解決，也使自己對一些問題有了新的看法和認識。在這一周中，通過我們的親身實踐和學習不僅鞏固了之前所學的知識，也使自己明白了之前學習中的盲點。

課程設計是開放教育試點專業學生整個學習過程中的一個重要實踐環節，通過課程設計認識到自己的不足，例如，缺乏動手能力，平時大家都學習理論知識，所以實踐能力相對薄弱，出現眼高手低的情況，在實際操作中會出現各種錯誤。課程設計也是學生在校學習期間學習成果的綜合總結，它對于培養學生的科研能力，提高其綜合能力及全面素質具有重要的意義。參考文獻

[1] 王珊.薩師煊《數據庫系統概論》.高等教育出版社.2011 [2] 張龍祥.數據庫原理與設計.北京:人民郵電出版社.2000 [3] 李紅.數據庫原理與應用.北京:高等教育出版社.2002 [4] 王能斌.數據庫系統原理.北京:電子工業出版社.2002 [5] 張立科.信息管理系統開發實例導航.北京:人民郵電出版社.2005 [6] 邵洋.數據庫系統開發實例導航.北京:人民郵電出版社.2003 [7] 李振格.sql server 2000 中文版入門與提高．清華大學出版社．2008

第二篇：數據庫設計流程

數據庫設計流程

目前數據庫設計一般分為6個階段，即需求分析階段，概念結構設計階段，邏輯結構設計階段，物理結構設計階段，實施階段，運行與維護階段。

(1)需求分析階段

需求分析階段的主要任務是指通過充分調查現實世界要處理的對象, 詳細了解計算機系統的工作情況, 明確用戶的各種需求, 然后確定系統的各項功能。數據庫系統不僅要按照當前的應用要求來設計, 而且必須充分考慮今后可能的擴充和改變。

(2)概念結構設計階段

概念結構設計階段的主要任務是將需求分析階段所得到的用戶需求抽象為概念模型, 而描述概念模型的具體工具主要是E-R 模型。

(3)邏輯結構設計階段

邏輯結構設計階段的主要任務是把概念結構設計階段設計的基本E-R 模型轉換為與選用DBMS產品所支持的數據模型相符合的邏輯結構。具體來說, 就是首先將概念結構轉換為一般的關系、網狀、層次模型, 然后將轉換來的模型向特定DBMS 支持下的數據模型轉換, 最后對數據模型進行優化。

(4)物理結構設計階段

物理結構設計階段的主要任務是為一個指定的邏輯數據模型選取一個符合應用要求的物理結構。具體來說, 就是首先確定數據庫的物理結構, 即數據庫的存取方法和存儲結構;然后對數據庫的物理結構進行評估, 評估的重點是存取時間的長短和存儲空間的大小。

(5)實施階段

實施階段的主要任務是用RDBMS 提供的數據定義語言和其他實用程序將邏輯結構設計和物理結構設計的結果詳細描述出來, 成為DBMS 可以接受的源代碼;再經過系統調試產生目標模式, 最后完成數據的載入工作。

(6)運行與維護階段

運行與維護階段的主要任務包括數據庫的轉儲和恢復, 數據庫完整性和安全性控制, 數據庫性能改造、分析和監督, 數據庫的重構造和重組織。

第三篇：數據庫設計心得

數據庫設計經驗談

數據庫設計經驗談

一個成功的管理系統，是由：[50% 的業務 + 50% 的軟件] 所組成，而 50% 的成功軟件又有 [25% 的數據庫 + 25% 的程序] 所組成，數據庫設計的好壞是一個關鍵。如果把企業的數據比做生命所必需的血液，那么數據庫的設計就是應用中最重要的一部分。有關數據庫設計的材料汗牛充棟，大學學位課程里也有專門的講述。不過，就如我們反復強調的那樣，再好的老師也比不過經驗的教誨。所以我歸納歷年來所走的彎路及體會，并在網上找了些對數據庫設計頗有造詣的專業人士給大家傳授一些設計數據庫的技巧和經驗。精選了其中的 60 個最佳技巧，并把這些技巧編寫成了本文，為了方便索引其內容劃分為 5 個部分：

第 1 部分設計數據庫表

總共 24 個指南性技巧，涵蓋表內字段設計以及應該避免的常見問題等。

第 3 部分保證數據完整性

討論如何保持數據庫的清晰和健壯，如何把有害數據降低到最小程度。

第 5 部分設計數據庫之前 考察現有環境

在設計一個新數據庫時，你不但應該仔細研究業務需求而且還要考察現有的系統。大多數數據庫項目都不是從頭開始建立的；通常，機構內總會存在用來滿足特定需求的現有系統（可能沒有實現自動計算）。顯然，現有系統并不完美，否則你就不必再建立新系統了。但是對舊系統的研究可以讓你發現一些可能會忽略的細微問題。一般來說，考察現有系統對你絕對有好處。

定義標準的對象命名規范

一定要定義數據庫對象的命名規范。對數據庫表來說，從項目一開始就要確定表名是采用復數還是單數形式。此外還要給表的別名定義簡單規則（比方說，如果表名是一個單詞，別名就取單詞的前 4 個字母；如果表名是兩個單詞，就各取兩個單詞的前兩個字母組成 4 個字母長的別名；如果表的名字由 3 個單詞組成，你不妨從頭兩個單詞中各取一個然后從最后一個單詞中再取出兩個字母，結果還是組成 4 字母長的別名，其余依次類推）對工作用表來說，表名可以加上前綴 WORK_ 后面附上采用該表的應用程序的名字。表內的列[字段]要針對鍵采用一整套設計規則。比如，如果鍵是數字類型，你可以用 _N 作為后綴；如果是字符類型則可以采用 _C 后綴。對列[字段]名應該采用標準的前綴和后綴。再如，假如你的表里有好多“money”字段，你不妨給每個列[字段]增加一個 _M 后綴。還有，日期列[字段]最好以 D_ 作為名字打頭。

檢查表名、報表名和查詢名之間的命名規范。你可能會很快就被這些不同的數據庫要素的名稱搞糊涂了。假如你堅持統一地命名這些數據庫的不同組成部分，至少你應該在這些對象名字的開頭用 Table、Query 或者 Report 等前綴加以區別。

如果采用了 Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符號來標識對象（比如 tbl_Employees）。我在和 SQL Server 打交道的時候還用過 tbl 來索引表，但我用 sp_company（現在用 sp_feft_）標識存儲過程，因為在有的時候如果我發現了更好的處理辦法往往會保存好幾個拷貝。我在實現 SQL Server 2000 時用 udf_（或者類似的標記）標識我編寫的函數。

工欲善其事, 必先利其器

采用理想的數據庫設計工具，比如：SyBase 公司的 PowerDesign，她支持 PB、VB、Delphe 等語言，通過 ODBC 可以連接市面上流行的 30 多個數據庫，包括 dBase、FoxPro、VFP、SQL Server 等，今后有機會我將著重介紹 PowerDesign 的使用。

獲取數據模式資源手冊

正在尋求示例模式的人可以閱讀《數據模式資源手冊》一書，該書由 Len Silverston、W.H.Inmon 和 Kent Graziano 編寫，是一本值得擁有的最佳數據建模圖書。該書包括的章節涵蓋多種數據領域，比如人員、機構和工作效能等。其他的你還可以參考：[1]薩師煊 王珊著 數據庫系統概論(第二版)高等教育出版社 1991、[2][美] Steven M.Bobrowski 著 Oracle 7 與客戶／服務器計算技術從入門到精通 劉建元等譯 電子工業出版社，1996、[3]周中元 信息系統建模方法(下)電子與信息化 1999年第3期，1999 暢想未來，但不可忘了過去的教訓

我發現詢問用戶如何看待未來需求變化非常有用。這樣做可以達到兩個目的：首先，你可以清楚地了解應用設計在哪個地方應該更具靈活性以及如何避免性能瓶頸；其次，你知道發生事先沒有確定的需求變更時用戶將和你一樣感到吃驚。

一定要記住過去的經驗教訓！我們開發人員還應該通過分享自己的體會和經驗互相幫助。即使用戶認為他們再也不需要什么支持了，我們也應該對他們進行這方面的教育，我們都曾經面臨過這樣的時刻“當初要是這么做了該多好..”。

在物理實踐之前進行邏輯設計

在深入物理設計之前要先進行邏輯設計。隨著大量的 CASE 工具不斷涌現出來，你的設計也可以達到相當高的邏輯水準，你通常可以從整體上更好地了解數據庫設計所需要的方方面面。

了解你的業務

在你百分百地確定系統從客戶角度滿足其需求之前不要在你的 ER（實體關系）模式中加入哪怕一個數據表（怎么，你還沒有模式？那請你參看技巧 9）。了解你的企業業務可以在以后的開發階段節約大量的時間。一旦你明確了業務需求，你就可以自己做出許多決策了。

一旦你認為你已經明確了業務內容，你最好同客戶進行一次系統的交流。采用客戶的術語并且向他們解釋你所想到的和你所聽到的。同時還應該用可能、將會和必須等詞匯表達出系統的關系基數。這樣你就可以讓你的客戶糾正你自己的理解然后做好下一步的 ER 設計。

創建數據字典和 ER 圖表

一定要花點時間創建 ER 圖表和數據字典。其中至少應該包含每個字段的數據類型和在每個表內的主外鍵。創建 ER 圖表和數據字典確實有點費時但對其他開發人員要了解整個設計卻是完全必要的。越早創建越能有助于避免今后面臨的可能混亂，從而可以讓任何了解數據庫的人都明確如何從數據庫中獲得數據。

有一份諸如 ER 圖表等最新文檔其重要性如何強調都不過分，這對表明表之間關系很有用，而數據字典則說明了每個字段的用途以及任何可能存在的別名。對 SQL 表達式的文檔化來說這是完全必要的。

創建模式

一張圖表勝過千言萬語：開發人員不僅要閱讀和實現它，而且還要用它來幫助自己和用戶對話。模式有助于提高協作效能，這樣在先期的數據庫設計中幾乎不可能出現大的問題。模式不必弄的很復雜；甚至可以簡單到手寫在一張紙上就可以了。只是要保證其上的邏輯關系今后能產生效益。

從輸入輸出下手

在定義數據庫表和字段需求（輸入）時，首先應檢查現有的或者已經設計出的報表、查詢和視圖（輸出）以決定為了支持這些輸出哪些是必要的表和字段。舉個簡單的例子：假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼字段而不要把郵政編碼糅進地址字段里。

報表技巧

要了解用戶通常是如何報告數據的：批處理還是在線提交報表？時間間隔是每天、每周、每月、每個季度還是每年？如果需要的話還可以考慮創建總結表。系統生成的主鍵在報表中很難管理。用戶在具有系統生成主鍵的表內用副鍵進行檢索往往會返回許多重復數據。這樣的檢索性能比較低而且容易引起混亂。

理解客戶需求

看起來這應該是顯而易見的事，但需求就是來自客戶（這里要從內部和外部客戶的角度考慮）。不要依賴用戶寫下來的需求，真正的需求在客戶的腦袋里。你要讓客戶解釋其需求，而且隨著開發的繼續，還要經常詢問客戶保證其需求仍然在開發的目的之中。一個不變的真理是：“只有我看見了我才知道我想要的是什么”必然會導致大量的返工，因為數據庫沒有達到客戶從來沒有寫下來的需求標準。而更糟的是你對他們需求的解釋只屬于你自己，而且可能是完全錯誤的。

第 2 部分選擇鍵和索引 數據采掘要預先計劃

我所在的某一客戶部門一度要處理 8 萬多份聯系方式，同時填寫每個客戶的必要數據（這絕對不是小活）。我從中還要確定出一組客戶作為市場目標。當我從最開始設計表和字段的時候，我試圖不在主索引里增加太多的字段以便加快數據庫的運行速度。然后我意識到特定的組查詢和信息采掘既不準確速度也不快。結果只好在主索引中重建而且合并了數據字段。我發現有一個指示計劃相當關鍵——當我想創建系統類型查找時為什么要采用號碼作為主索引字段呢？我可以用傳真號碼進行檢索，但是它幾乎就象系統類型一樣對我來說并不重要。采用后者作為主字段，數據庫更新后重新索引和檢索就快多了。

可操作數據倉庫（ODS）和數據倉庫（DW）這兩種環境下的數據索引是有差別的。在 DW 環境下，你要考慮銷售部門是如何組織銷售活動的。他們并不是數據庫管理員，但是他們確定表內的鍵信息。這里設計人員或者數據庫工作人員應該分析數據庫結構從而確定出性能和正確輸出之間的最佳條件。

使用系統生成的主鍵

這類同技巧 1，但我覺得有必要在這里重復提醒大家。假如你總是在設計數據庫的時候采用系統生成的鍵作為主鍵，那么你實際控制了數據庫的索引完整性。這樣，數據庫和非人工機制就有效地控制了對存儲數據中每一行的訪問。

采用系統生成鍵作為主鍵還有一個優點：當你擁有一致的鍵結構時，找到邏輯缺陷很容易。

分解字段用于索引

為了分離命名字段和包含字段以支持用戶定義的報表，請考慮分解其他字段（甚至主鍵）為其組成要素以便用戶可以對其進行索引。索引將加快 SQL 和報表生成器腳本的執行速度。比方說，我通常在必須使用 SQL LIKE 表達式的情況下創建報表，因為 case number 字段無法分解為 year、serial number、case type 和 defendant code 等要素。性能也會變壞。假如和類型字段可以分解為索引字段那么這些報表運行起來就會快多了。

鍵設計 4 原則

* 為關聯字段創建外鍵。* 所有的鍵都必須唯一。* 避免使用復合鍵。

* 外鍵總是關聯唯一的鍵字段。

別忘了索引

索引是從數據庫中獲取數據的最高效方式之一。95% 的數據庫性能問題都可以采用索引技術得到解決。作為一條規則，我通常對邏輯主鍵使用唯一的成組索引，對系統鍵（作為存儲過程）采用唯一的非成組索引，對任何外鍵列[字段]采用非成組索引。不過，索引就象是鹽，太多了菜就咸了。你得考慮數據庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用作讀寫。

大多數數據庫都索引自動創建的主鍵字段，但是可別忘了索引外鍵，它們也是經常使用的鍵，比如運行查詢顯示主表和所有關聯表的某條記錄就用得上。還有，不要索引 memo/note 字段，不要索引大型字段（有很多字符），這樣作會讓索引占用太多的存儲空間。

不要索引常用的小型表

不要為小型數據表設置任何鍵，假如它們經常有插入和刪除操作就更別這樣作了。對這些插入和刪除操作的索引維護可能比掃描表空間消耗更多的時間。

不要把社會保障號碼（SSN）或身份證號碼（ID）選作鍵

永遠都不要使用 SSN 或 ID 作為數據庫的鍵。除了隱私原因以外，須知政府越來越趨向于不準許把 SSN 或 ID 用作除收入相關以外的其他目的，SSN 或 ID 需要手工輸入。永遠不要使用手工輸入的鍵作為主鍵，因為一旦你輸入錯誤，你唯一能做的就是刪除整個記錄然后從頭開始。

我在破解他人的程序時候，我看到很多人把 SSN 或 ID 還曾被用做系列號，當然盡管這么做是非法的。而且人們也都知道這是非法的，但他們已經習慣了。后來，隨著盜取身份犯罪案件的增加，我現在的同行正痛苦地從一大攤子數據中把 SSN 或 ID 刪除。

不要用用戶的鍵

在確定采用什么字段作為表的鍵的時候，可一定要小心用戶將要編輯的字段。通常的情況下不要選擇用戶可編輯的字段作為鍵。這樣做會迫使你采取以下兩個措施：

* 在創建記錄之后對用戶編輯字段的行為施加限制。假如你這么做了，你可能會發現你的應用程序在商務需求突然發生變化，而用戶需要編輯那些不可編輯的字段時缺乏足夠的靈活性。當用戶在輸入數據之后直到保存記錄才發現系統出了問題他們該怎么想？刪除重建？假如記錄不可重建是否讓用戶走開？

* 提出一些檢測和糾正鍵沖突的方法。通常，費點精力也就搞定了，但是從性能上來看這樣做的代價就比較大了。還有，鍵的糾正可能會迫使你突破你的數據和商業/用戶界面層之間的隔離。

所以還是重提一句老話：你的設計要適應用戶而不是讓用戶來適應你的設計。

不讓主鍵具有可更新性的原因是在關系模式下，主鍵實現了不同表之間的關聯。比如，Customer 表有一個主鍵 CustomerID，而客戶的定單則存放在另一個表里。Order 表的主鍵可能是 OrderNo 或者 OrderNo、CustomerID 和日期的組合。不管你選擇哪種鍵設置，你都需要在 Order 表中存放 CustomerID 來保證你可以給下定單的用戶找到其定單記錄。

假如你在 Customer 表里修改了 CustomerID，那么你必須找出 Order 表中的所有相關記錄對其進行修改。否則，有些定單就會不屬于任何客戶——數據庫的完整性就算完蛋了。如果索引完整性規則施加到表一級，那么在不編寫大量代碼和附加刪除記錄的情況下幾乎不可能改變某一條記錄的鍵和數據庫內所有關聯的記錄。而這一過程往往錯誤叢生所以應該盡量避免。

可選鍵(候選鍵)有時可做主鍵

記住，查詢數據的不是機器而是人。假如你有可選鍵，你可能進一步把它用做主鍵。那樣的話，你就擁有了建立強大索引的能力。這樣可以阻止使用數據庫的人不得不連接數據庫從而恰當的過濾數據。在嚴格控制域表的數據庫上，這種負載是比較醒目的。如果可選鍵真正有用，那就是達到了主鍵的水準。

我的看法是，假如你有可選鍵，比如國家表內的 state_code，你不要在現有不能變動的唯一鍵上創建后續的鍵。你要做的無非是創建毫無價值的數據。如你因為過度使用表的后續鍵[別名]建立這種表的關聯，操作負載真得需要考慮一下了。

別忘了外鍵

大多數數據庫索引自動創建的主鍵字段。但別忘了索引外鍵字段，它們在你想查詢主表中的記錄及其關聯記錄時每次都會用到。還有，不要索引 memo/notes 字段而且不要索引大型文本字段（許多字符），這樣做會讓你的索引占據大量的數據庫空間。

第 4 部分各種小技巧 文檔、文檔、文檔

對所有的快捷方式、命名規范、限制和函數都要編制文檔。

采用給表、列[字段]、觸發器等加注釋的數據庫工具。是的，這有點費事，但從長遠來看，這樣做對開發、支持和跟蹤修改非常有用。

取決于你使用的數據庫系統，可能有一些軟件會給你一些供你很快上手的文檔。你可能希望先開始在說，然后獲得越來越多的細節。或者你可能希望周期性的預排，在輸入新數據同時隨著你的進展對每一部分細節化。不管你選擇哪種方式，總要對你的數據庫文檔化，或者在數據庫自身的內部或者單獨建立文檔。這樣，當你過了一年多時間后再回過頭來做第 2 個版本，你犯錯的機會將大大減少。

使用常用英語（或者其他任何語言）而不要使用編碼

為什么我們經常采用編碼（比如 9935A 可能是?青島啤酒?的供應代碼，4XF788-Q 可能是帳目編碼）？理由很多。但是用戶通常都用英語進行思考而不是編碼。工作 5 年的會計或許知道 4XF788-Q 是什么東西，但新來的可就不一定了。在創建下拉菜單、列表、報表時最好按照英語名排序。假如你需要編碼，那你可以在編碼旁附上用戶知道的英語。

保存常用信息

讓一個表專門存放一般數據庫信息非常有用。我常在這個表里存放數據庫當前版本、最近檢查/修復（對 FoxPro）、關聯設計文檔的名稱、客戶等信息。這樣可以實現一種簡單機制跟蹤數據庫，當客戶抱怨他們的數據庫沒有達到希望的要求而與你聯系時，這樣做對非客戶機/服務器環境特別有用。

測試、測試、反復測試

建立或者修訂數據庫之后，必須用用戶新輸入的數據測試數據字段。最重要的是，讓用戶進行測試并且同用戶一道保證你選擇的數據類型滿足商業要求。測試需要在把新數據庫投入實際服務之前完成。

檢查設計

在開發期間檢查數據庫設計的常用技術是通過其所支持的應用程序原型檢查數據庫。換句話說，針對每一種最終表達數據的原型應用，保證你檢查了數據模型并且查看如何取出數據。

Microsoft Visual FoxPro 設計技巧

對復雜的 Microsoft Visual FoxPro 數據庫應用程序而言，可以把所有的主表放在一個數據庫容器文件里，然后增加其他數據庫表文件和裝載同原有數據庫有關的特殊文件。根據需要用這些文件連接到主文件中的主表。比如數據輸入、數據索引、統計分析、向管理層或者政府部門提供報表以及各類只讀查詢等。這一措施簡化了用戶和組權限的分配，而且有利于應用程序函數（存儲過程）的分組和劃分，從而在程序必須修改的時候易于管理。

第四篇：數據庫設計原則

4.3.1數據庫設計原則

數據庫設計的基本原則是在系統總體信息方案的指導下，各個庫應當為它所支持的管理目標服務，在設計數據庫系統時，應當重點考慮以下幾個因素:

1、數據庫必須層次分明，布局合理。

2、數據庫必須高度結構化，保證數據的結構化，規范化和標準化，這是建立數據庫和進行信息交換的基礎。數據結構的設計應該遵循國家標準和行業標準，尤其要重視編碼的應用。

3、在設計數據庫的時候，一方而要盡可能地減小冗余度，減小存儲空間的占用，降低數據一致性問題發生的可能性，另一方面，還要考慮適當的冗余，以提高運行速度和降低開發難度。

4、必須維護數據的正確性和一致性。在系統中，多個用戶共享數據庫，由于并發操作，可能影響數據的一致性。因此必須用“鎖”等辦法保證數據的一致性。

5、設定相應的安全機制，由于數據庫的信息、對特定的用戶有特定的保密要求，安全機制必不可少。

第五篇：數據庫設計經驗談

數據庫設計經驗談

一個成功的管理系統，是由：[50% 的業務 + 50% 的軟件] 所組成，而 50% 的成功軟件又有 [25% 的數據庫 + 25% 的程序] 所組成，數據庫設計的好壞是一個關鍵。如果把企業的數據比做生命所必需的血液，那么數據庫的設計就是應用中最重要的一部分。有關數據庫設計的材料汗牛充棟，大學學位課程里也有專門的講述。不過，就如我們反復強調的那樣，再好的老師也比不過經驗的教誨。所以我歸納歷年來所走的彎路及體會，并在網上找了些對數據庫設計頗有造詣的專業人士給大家傳授一些設計數據庫的技巧和經驗。精選了其中的 60 個最佳技巧，并把這些技巧編寫成了本文，為了方便索引其內容劃分為 5 個部分：

第 1 部分設計數據庫表

總共 24 個指南性技巧，涵蓋表內字段設計以及應該避免的常見問題等。第 3 部分保證數據完整性

討論如何保持數據庫的清晰和健壯，如何把有害數據降低到最小程度。

第 5 部分-各種小技巧

不包括在以上 4 個部分中的其他技巧，五花八門，有了它們希望你的數據庫開發工作會更輕松一些。