Ø  何為關係模式？

   1.關係的描述稱為關係模式（RelationSchema）

   2.它可以形式化地表示為：R（U，D，dom，F），其中R為關係名，U為組成該關係的屬性名集合，D為屬性組U中屬性所來自的域，dom為屬性向域的映象集合，F為屬性間數據的依賴關係集合。

   3.通常簡記為：R(U)或R(A1，A2，…,An)

   4.其中R為關係名，U為屬性名集合，A1，A2，…,An為各屬性名。

  Ø  範式

    關係模式的好壞有一定的衡量標準，而這個標準就是模式的範式（Normal Forms，簡稱為NF），範式的種類與數據依賴有着直接的聯繫，基於FD即函數依賴（functional dependency，簡稱FD）的範式有1NF、2NF、3NF、BCNF等等，下面重點介紹前三種。

   u  範式定義

    （範式，數據庫設計範式，數據庫的設計範式）是符合某一種級別的關係模式的集合。構造數據庫必須遵循一定的規則。在關係數據庫中，這種規則就是範式。關係數據庫中的關係必須滿足一定的要求，即滿足不同的範式。

   u  三範式的介紹

    ²  第一範式（1NF）（無重複序列）

    如果關係模式R的每個關係r的屬性值都是不可分的原子值，也就是説數據庫表中的字段都是單一屬性的，不可再分。這個單一屬性由基本類型構成，包括整型、實數、字符型、邏輯型、日期型等。

    例如：這種數據庫表是符合第一範式的

    然而這種的數據庫表是不符合第一範式的

    ²  第二範式（2NF）屬性完全依賴於主鍵[消除部分子函數依賴]

    1.如果關係模式R是1NF，且每個非主屬性完全函數依賴於候選鍵，那麼稱R是第二範式。

    2.也就是説第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的，即滿足第二範式（2NF）必須先滿足第一範式（1NF）。第二範式（2NF）要求數據庫表中的每個實例或行必須可以被惟一地區分。

    3.第二範式（2NF）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關係。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。簡而言之，第二範式就是屬性完全依賴於主鍵。

    4.不符合第二範式帶來的影響是出現數據冗餘、刪除異常、更新異常、插入異常等等。

    例如：一個訂單的表

    從這個圖上我們可以看出這個表是有問題的，因為這個表是以訂單編號和產品編號為聯合主鍵的，這樣就會出現問題，問題就是產品的價格只是與產品編號有關，訂購日期只是與訂單編號有關，故而違背了第二範式的設計原則，應該將其拆分如下圖：

    訂單信息：

    產品信息：

    這樣設計，在很大程度上減小了數據庫的冗餘。如果要獲取訂單的信息，使用訂單編號到訂單信息表中查詢即可。

    ²  第三範式（3NF）屬性不依賴於其它非主屬性[消除傳遞依賴]

    a)如果關係模式R是1NF，且每個非主屬性都不傳遞依賴於R的候選鍵。

    b)也就是説滿足第三範式（3NF）必須先滿足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個數據庫表中不包含已在其它表中已包含的非主關鍵字信息。

    c)再進一步在第二範式的基礎上，數據表中如果不存在非關鍵字段對任一候選關鍵字段的傳遞函數依賴則符合第三範式。所謂傳遞函數依賴，指的是如果存在"A → B → C"的決定關係，則C傳遞函數依賴於A。因此，滿足第三範式的數據庫表應該不存在如下依賴關係： 關鍵字段 → 非關鍵字段x → 非關鍵字段y

    舉例：同樣是訂單表

    這樣把客户信息和產品信息放入一個表中，在查詢時就得輸入客户的全部信息，那麼就會造成數據的冗餘，如果將其拆分，分類之後就會減少數據的冗餘。

    訂單信息表：

    顧客信息表：

    這樣在查詢訂單信息的時候，就可以使用顧客編號來引用顧客信息表中的記錄，也不必在訂單信息表中多次輸入顧客信息的內容，減小了數據冗餘。

  Ø  小結

   1.滿足1NF的關係為規範化的關係，否則為非規範化的關係。

   2.規範化的本質是提高數據獨立性，解決插入異常、刪除異常、修改複雜、數據冗餘等問題的方法。

   3.規範化的基本思想是逐步消除數據依賴中不適合的部分。

      (一)  第一範式目標（1NF）：確保每列的原子性。

      (二)  第二範式目標（2NF）：確保表中的每列，都和主鍵有關。

      (三)  第三範式目標（3NF）：確保每列都和主鍵列直接相關，而不是間接相關。