基本步驟：
1.瞭解功能需求；
2.根據需求抽取實體對象、關係、分析細化行爲；
3.繪製E-R圖；
4.E-R圖轉換成模型（粗表）；
5.用三範式優化模型，根據表關係、行爲、規則細化、拆分粗表；
6.數據庫建表；
基本原則：
1.先面向對象，把對象及屬性列全了，再考慮面向過程。先列實體，再列實體間的關係，再細化關係。
2.一定要結合業務需求考慮表依賴關係，主外鍵關係不能混亂或者弄反，儘量考慮表之間關係是不是存在1：N的情況
3.表關係爲1：N的，N方要有1方的主鍵字段作爲外鍵
4.表關係存在N:N的時候一定要加入中間表做成N：1：N
庫設計：
1、數據庫名稱要明確，可以加前綴或後綴的方式，使其看起來有業務含義，比如數據庫名稱可以爲Business_DB(業務數據庫）。
2、在一個企業中，如果依賴很多產品，但是每個產品都使用同一套用戶，那麼應該將用戶單獨構建一個庫，叫做企業用戶中心。
3、不同類型的數據應該分開管理，例如，財務數據庫，業務數據庫等。
4、由於存儲過程在不同的數據庫中，支持方式不一樣，因此不建議過多使用和使用複雜的存儲過程。爲數據庫服務器降低壓力，不要讓數據庫處理過多的業務邏輯，將業務邏輯處理放到應用程序中。
表設計：
1、 數據庫表命名，將業務和基礎表區分，採用駝峯表示法等。
2、 數據不要物理刪除，應該加一個標誌位，以防用戶後悔時，能夠恢復。還有就是比如人員登記加入某系統，採用登記卡的方式，一段時間後該人員退出了該系統，那麼此時我們將該人員對應的記錄標記爲不可用，那麼這個人就從系統中移除了，一段時間後這個人又回來了，那麼我們直接修改標記字段爲可用，這個人就從新加入系統，避免了其它信息的錄入。
3、 數據是否有效的標示字段，其作用爲：例如某條記錄只有經過某個流程或者被某個人員審覈通過後纔有用，在這之前一直沒有用。
4、 排序字段，按照某種類型來排序（sortcode）最好不依賴id排序，這樣方便我們查詢記錄時按照某種方式排序，而不依賴id。
5、 數據是否允許刪除和允許編輯，例如管理員不能刪除，這樣我們在查詢數據時就可以根據該字段標示來決定某條記錄是否可以編輯。而不用固化到代碼中。
6、 增加備註字段，雖然我們考慮了很多用戶需要輸入信息的需求，但是無論何時我們都不可能考慮全，因此可以定義一個備註字段，允許用戶將其它的信息填寫在這裏。無論表設計的再神奇，那麼還是加一個備註字段。
7、 將記錄創建人Id和記錄創建人名字做爲字段，這樣看起來或許感到冗餘有了Id還要名字幹什麼，使用住外鍵關聯不就可以了嗎，但是我們可以這樣思考，如果只使用名字，那麼人多了免不了名字重複，只使用id當然沒有問題，但是我們查詢時爲了知道創建者的人名需要關聯查詢另外一張表，性能上不好，而且數據庫看起來不是那麼一目瞭然。並且創建人的名字也不是經常修改的。
8、 添加時間，有添加時間可以明確知道記錄什麼時候添加的。
9、 修改時間，可以知道記錄什麼時候被修改了，一旦數據出現問題，可以根據修改時間來定位問題。比如某人在這個時間做了哪些事。
10、修改人id和名字，其作用就是標記誰對記錄做了修改
11、最後修改人
12、最後修改時間
13、記錄所屬公司id，方便我們查詢只屬於某個公司的記錄
14、記錄所屬部門id，方便我們查詢只屬於某個部門的記錄
15、記錄所屬工作組id，方便我們查詢只屬於某個工作組的記錄
16、基本表及其字段之間的關係, 應儘量滿足第三範式。但是，滿足第三範式的數據庫設計，往往不是
最好的設計。爲了提高數據庫的運行效率，常常需要降低範式標準：適當增加冗餘，達到以空間換時間
的目的。
17、若兩個實體之間存在多對多的關係，則應消除這種關係。消除的辦法是，在兩者之間增加第三個實
體。這樣，原來一個多對多的關係，現在變爲兩個一對多的關係。要將原來兩個實體的屬性合理地分配
到三個實體中去。這裏的第三個實體，實質上是一個較複雜的關係，它對應一張基本表。一般來講，數
據庫設計工具不能識別多對多的關係，但能處理多對多的關係。
18、 主鍵PK的取值方法，PK是供程序員使用的表間連接工具，可以是一無物理意義的數字串, 由程序自動加1來實現。也可
以是有物理意義的字段名或字段名的組合。不過前者比後者好。當PK是字段名的組合時，建議字段的個
數不要太多，多了不但索引佔用空間大，而且速度也慢。
19、主鍵與外鍵在多表中的重複出現, 不屬於數據冗餘，這個概念必須清楚，事實上有許多人還不清楚
。非鍵字段的重複出現, 纔是數據冗餘！而且是一種低級冗餘，即重複性的冗餘。高級冗餘不是字段的
重複出現，而是字段的派生出現。
〖例4〗：商品中的“單價、數量、金額”三個字段，“金額”就是由“單價”乘以“數量”派生出
來的，它就是冗餘，而且是一種高級冗餘。冗餘的目的是爲了提高處理速度。只有低級冗餘纔會增加數
據的不一致性，因爲同一數據，可能從不同時間、地點、角色上多次錄入。因此，我們提倡高級冗餘(派
生性冗餘)，反對低級冗餘(重複性冗餘)。
20、中間表是存放統計數據的表，它是爲數據倉庫、輸出報表或查詢結果而設計的，有時它沒有主鍵與
外鍵(數據倉庫除外)。臨時表是程序員個人設計的，存放臨時記錄，爲個人所用。基表和中間表由DBA維
護，臨時表由程序員自己用程序自動維護。
21、防止數據庫設計打補丁的方法是“三少原則”
(1) 一個數據庫中表的個數越少越好。只有表的個數少了，才能說明系統的E--R圖少而精，去掉了
重複的多餘的實體，形成了對客觀世界的高度抽象，進行了系統的數據集成，防止了打補丁式的設計；
(2) 一個表中組合主鍵的字段個數越少越好。因爲主鍵的作用，一是建主鍵索引，二是做爲子表的
外鍵，所以組合主鍵的字段個數少了，不僅節省了運行時間，而且節省了索引存儲空間；
(3) 一個表中的字段個數越少越好。只有字段的個數少了，才能說明在系統中不存在數據重複，且
很少有數據冗餘，更重要的是督促讀者學會“列變行”，這樣就防止了將子表中的字段拉入到主表中去
，在主表中留下許多空餘的字段。所謂“列變行”，就是將主表中的一部分內容拉出去，另外單獨建一
個子表。這個方法很簡單，有的人就是不習慣、不採納、不執行。
數據庫設計的實用原則是：在數據冗餘和處理速度之間找到合適的平衡點。“三少”是一個整體概
念，綜合觀點，不能孤立某一個原則。該原則是相對的，不是絕對的。“三多”原則肯定是錯誤的。試
想：若覆蓋系統同樣的功能，一百個實體(共一千個屬性) 的E--R圖，肯定比二百個實體(共二千個屬性)
的E--R圖，要好得多。
提倡“三少”原則，是叫讀者學會利用數據庫設計技術進行系統的數據集成。數據集成的步驟是將
文件系統集成爲應用數據庫，將應用數據庫集成爲主題數據庫，將主題數據庫集成爲全局綜合數據庫。
集成的程度越高，數據共享性就越強，信息孤島現象就越少，整個企業信息系統的全局E—R圖中實體的
個數、主鍵的個數、屬性的個數就會越少。
提倡“三少”原則的目的，是防止讀者利用打補丁技術，不斷地對數據庫進行增刪改，使企業數據
庫變成了隨意設計數據庫表的“垃圾堆”，或數據庫表的“大雜院”，最後造成數據庫中的基本表、代
碼錶、中間表、臨時表雜亂無章，不計其數，導致企事業單位的信息系統無法維護而癱瘓。
“三多”原則任何人都可以做到，該原則是“打補丁方法”設計數據庫的歪理學說。“三少”原則
是少而精的原則，它要求有較高的數據庫設計技巧與藝術，不是任何人都能做到的，因爲該原則是杜絕
用“打補丁方法”設計數據庫的理論依據。
22、在給定的系統硬件和系統軟件條件下，提高數據庫系統的運行效率的辦法是：
(1) 在數據庫物理設計時，降低範式，增加冗餘, 少用觸發器, 多用存儲過程。
(2) 當計算非常複雜、而且記錄條數非常巨大時(例如一千萬條)，複雜計算要先在數據庫外面，以
文件系統方式用C++語言計算處理完成之後，最後才入庫追加到表中去。這是電信計費系統設計的經驗。
(3) 發現某個表的記錄太多，例如超過一千萬條，則要對該表進行水平分割。水平分割的做法是，
以該表主鍵PK的某個值爲界線，將該表的記錄水平分割爲兩個表。若發現某個表的字段太多，例如超過
八十個，則垂直分割該表，將原來的一個表分解爲兩個表。
(4) 對數據庫管理系統DBMS進行系統優化，即優化各種系統參數，如緩衝區個數。
(5) 在使用面向數據的SQL語言進行程序設計時，儘量採取優化算法。
總之，要提高數據庫的運行效率，必須從數據庫系統級優化、數據庫設計級優化、程序實現級優化
，這三個層次上同時下功夫。
主鍵設計：
1、不建議用多個字段做主鍵，單個表還可以，但是關聯關係就會有問題，主鍵自增是高性能的。導入導出就有問題
2、一般情況下，如果有兩個外鍵，不建議採用兩個外鍵作爲聯合住建，另建一個字段作爲主鍵。除非這條記錄沒有邏輯刪除標誌，且該表永遠只有一條此聯合主鍵的記錄。
3、一般而言，一個實體不能既無主鍵又無外鍵。在E—R 圖中, 處於葉子部位的實體, 可以定義主鍵，也可以不定義主鍵(因爲它無子孫), 但必須要有外鍵(因爲它有父親)。
主鍵與外鍵的設計，在全局數據庫的設計中，佔有重要地位。當全局數據庫的設計完成以後，有個美國數據庫設計專家說：“鍵，到處都是鍵，除了鍵之外，什麼也沒有”，這就是他的數據庫設計經驗之談，也反映了他對信息系統核心(數據模型)的高度抽象思想。因爲：主鍵是實體的高度抽象，主鍵與、外鍵的配對，表示實體之間的連接。