資料庫範式與資料庫設計

1、資料庫範式：
       第1範式：屬性必須是原子的，不可分的。從實體的角度看就是實體屬性的類型只能是基礎資料型別 (Elementary Data Type)，不能是複合資料型別。這一條對於關聯式資料庫來說很容易滿足，但對於物件導向資料庫來說就不一定了。而且需要特別注意的是資料庫範式的考察必須與具體的需求相關，也就是屬性的原子性不是絕對的，而是相對於需求的。比如對於學生表（學號，姓名，學校），對於學校這個屬性而言，如果我們不需要更進一步的考察，那麼學校屬性就是原子的，如果需要進一步分解學校這個屬性，比如為學校（學校編號，校名，成立日期），那麼學校屬性就是非原子的。

      第2範式：非主屬性a不能部分依賴於侯選鍵R。如果非主屬性a部分依賴於侯選鍵R，則說明這個非主屬性和其依賴的主屬性集合A(A是R的真子集)在這張表中存在行上的資料重複。比如使用者角色關係表(使用者ID,角色ID，角色名稱),其中(使用者ID,角色ID)為侯選鍵,角色名稱依賴於角色ID,就是一種部分依賴,這種設計有4個問題：
       1) 是資料存放區冗餘:在這張表中角色ID和角色姓名存在大量的儲存冗餘（比如一個角色對應N個使用者，則角色名稱需要重複存N次).
        2)是更新異常：如果某一行的角色姓名被修改，就必須同時更新所有對應角色ID的角色姓名，不能僅僅只更新侯選鍵所在的行；
        3)插入異常：如果新增加一個角色，由於沒有選課，則無法錄入;
        4)刪除異常：同樣的，如果使用者角色關係刪除後就可能導致角色資訊業被刪除；
        為了避免上述問題，則可以增加一張表2(角色ID,角色姓名),將使用者角色關係表改為(使用者ID,角色ID)，就可以消除使用者角色關係表中的部分依賴，從而減少資料冗餘和異常操作問題。雖然增加一個主鍵列關係ID,可以消除這種部分依賴，但並不能解決問題的實質：儲存冗餘和操作異常.
      第3範式：在第二範式的基礎上，屬性不能依賴於其它非主屬性。  如果一個屬性依賴於其它非主屬性，一樣會存在範式2中所說的幾個問題，解決辦法同範式2。
      BCNF(鮑依斯-科得範式)：若關係模式是第一範式，且每個屬性都不傳遞依賴於關係模式的候選索引鍵.很容易證明該範式滿足第2範式，因為如果有非主屬性a部分依賴於侯選鍵R1(候選索引鍵R)，則很容易得出R->R1->a,即a傳遞依賴於R，與定義不符合。    同樣也可以證明BCNF滿足第3範式，因為一個屬性如果依賴於其它非主屬性，則必然傳遞依賴於其候選索引鍵。其實BCNF表達的是一個關係模式中，任何屬性都只能直接依賴於候選索引鍵，從消除了主屬性對候選索引鍵的傳遞依賴，在第3範式並沒有限制主屬性不能能依賴於其它主屬性。

      從上面的範式可以看出，提出範式的根本目的是消除冗餘和各種操作異常。但在實際中，並不能會完全滿足上述範式，一是出於效能的考慮，通過冗餘一定的資料來換取效能上優勢或者程式編寫上的便利。這種例子比較多，但需要注意的是，冗餘的這些資料一般是不需要改動，或者改動非常少的，或者一致性要求可以忽略，而且不會帶來操作異常中的插入和刪除異常問題，比如訂單明細表（訂單號，明細序號，產品編碼，產品名稱）和產品資訊表（產品編碼，產品名稱)還是會有兩張表，這種冗餘就不會產生插入和刪除異常，而且一般產品資訊表中的產品名稱修改的可能性比較小，訂單明細中的產品名稱不會修改，更新異常不會太嚴重，因此這種冗餘是可以的，影響就非常小；另外一種情況是根據業務必須冗餘的，非常典型的就是帶有法律意義的有價證券的設計上，比如合約如果涉及到產品，為了電子版和紙質版一致，那麼產品名稱和產品ID就都需要儲存（當然，在產品一旦使用就不能修改名稱的情況下，這種儲存就沒必要，這裡只是為了舉例）.還有一種情況就是看起來是不符合範式，但實際上並不違背範式，這主要是一些模板性基礎資料表和業務表之間的冗餘。  （以上舉例中的表設計僅僅是為了舉例，不是必然的，在不同的要求下，情況會不一樣）。