一般的數據庫設計都需要滿足三范式，這是最基本的要求的，最高達到6NF，但是一般情況下3NF達到了就可以
一：1NF一范式的理解：
1NF是關系型數據庫中的最基本要求，就是要求記錄的屬性是原子性，不可分，就是屬性不能分，這是關系型數據庫的基本要求，不滿足這個就不能叫關系型數據庫了
例如：
講師 性別 班級 教室 代課時間 代課時間（開始，結束）
韓忠康 Male php0331 102 30天 2013-03-31,2013-05-05
韓忠康 Male php0228 106 30天 2013-02-28,2013-03-30
韓順平 male Php0228 106 15天 2013-03-31,2013-05-05
上面的代課時間字段設計就不滿足原子性，因為它可以再分的，開始時間和結束時間，需要按照下面來設計拆分：
講師 性別 班級 教室 代課時間 開始 結束
韓忠康 Male php0331 102 30天 2013-03-31 2013-05-05
韓忠康 Male php0228 106 30天 2013-02-28 2013-03-30
韓順平 male Php0228 106 15天 2013-03-31 2013-04-20
上面的就滿足了，但是有些時候也需要去違背這個1NF的設計：在用dede設計cms的時候后台的下載地址是將格式，名稱，分辨率這些進行評級在一個屬性里面，但是可以看作一個整體，因為這個屬性即使分開，那么各個成員的關系不是平等的，但是代課時間是不一樣的，比如分為開始時間和結束時間，兩個成員的關系基本一樣！所以也不矛盾！
二：2NF二范式的理解
2NF是不能有部分依賴，部分依賴的前提條件是有組合主鍵，就是每條記錄是需要一個主鍵的，這個主鍵可以是一個單獨的屬性，但也可以是組合主鍵，就是由記錄的多個屬性來唯一確定一條記錄，那么只要出現了組合主鍵就可以產生部分依賴，部分依賴是組合主鍵出現的前提下，剩余的屬性，不完全依賴於組合主鍵，也是部分依賴組合主鍵，比如該表的N條記錄中由組合主鍵中的一條或者幾條就可以確定剩余屬性的屬性，那么就可以說產生部分依賴，而在實際開發中，一般不采用組合主鍵，而是自己增加一個字段id自增長，作為主鍵，這樣的單屬性主鍵是不會產生部分依賴的！
例如：
講師P 性別 班級P 教室 代課時間 開始 結束
韓忠康 Male php0331 102 30天 2013-03-31 2013-05-05
韓忠康 Male php0228 106 30天 2013-02-28 2013-03-30
韓順平 male Php0228 106 15天 2013-03-31 2013-04-20
上面的設計可以用講師P，班級，兩個字段作為組合主鍵，但是問題來了，那么后面的教室僅僅由班級字段(組合主鍵中的一條)就可以確定，即所謂教室部分依賴於組合主鍵，那么就不符合2NF
應該按照下面就行設計：
IDP 講師 性別 班級 教室 代課時間 開始 結束
1 韓忠康 Male php0331 102 30天 2013-03-31 2013-05-05
2 韓忠康 Male php0228 106 30天 2013-02-28 2013-03-30
可以看到僅僅增加一個主鍵IDP就不存在部分依賴了，這是實際項目中開發中常用的手段！
三：3NF的理解：不能出現傳遞依賴：就是主鍵，非主鍵1，非主鍵2三者之間不能出現傳遞依賴關系，如果出現由主鍵可以推出非主鍵1,然后由非主鍵1可以推出非主鍵2，那么主鍵與非主鍵2就產生了傳遞依賴關系，這就不滿足三范式，通俗來講，在一個表的，當然以一條記錄為單位，主鍵和非主鍵之間可以產生父子關系，但是非主鍵之間是不能出現父子關系的！
例如：
IDP 講師 性別 班級 教室 代課時間 開始 結束
1 韓忠康 Male php0331 102 30天 2013-03-31 2013-05-05
2 韓忠康 Male php0228 106 30天 2013-02-28 2013-03-30
3 韓順平 male php0228 106 15天 2013-03-31 2013-04-20
上面的設計不滿足3NF:
主鍵1--推出--->班級php0331，班級php0331-----推出---->教室102,這樣給人的感覺，教室不是由主鍵IDP1直接推出的，好像由班級通過傳遞推出的；當然還存在
主鍵IDP---->講師------>性別
這樣的壞處就是會產生數據冗余，解決方案是把中間的代理抽出來作為另外一張表：
應該如下設計：
IDP 講師 班級 代課時間 開始 結束
1 韓忠康 php0331 30天 2013-03-31 2013-05-05|
2 韓忠康 php0228 30天 2013-02-28 2013-03-30|
3 韓順平 php0228 15天 2013-03-31 2013-04-20|
--------------------------------------------------------
講師 性別
韓忠康 male
韓順平 male
-----------------
班級 教室
php0228 106
php0331 102
-------------
可以看到這樣設計只需要用22個字段，而上面那種設計需要用24個字段，這樣就節省了2個字段，如果數據是海量的那么節省的數據應該更加多
這樣設計，其實為了避免非笛卡爾積數據的重復，當然，笛卡爾積的數據的重復是必須的！
那么數據庫的設計可以先按照自己的想法設計一個"大表"出來,然后進行拆分成符合三范式的表，當然一般的規律的實體都單獨作為一個表格
比如講師實體，班級實體，代課關系實體，但是最大的問題是開始不知道哪些是實體，其實除了看得見的，其實說的清的可以描述的關系也可以作為一個實體
，這一點是容易被忽視的，但是隨着經驗的提升，慢慢會了解！