範式判斷流程圖數據庫
1. 四種範式之間關係函數
2. 第二範式、第三範式、BCNF區別:性能
2NF:非主鍵列和主鍵列之間,是徹底依賴於主鍵,仍是依賴於主鍵的一部分(只依賴某個主鍵);spa
3NF:非主鍵列之間,不存在依賴,只直接依賴主鍵。.net
BCNF:主鍵列之間,不存在依賴。設計
通常關係數據庫都知足第一範式,先肯定是幾個主鍵屬性。ci
第一範式:列不可再分產品
第二範式:非主鍵屬性所有依賴於主鍵屬性it
第三範式:非主鍵屬性之間無依賴關係table
第四範式:主鍵屬性之間無依賴關係
3. 第一範式:列不可分。每一列都是不可分割的基本數據項。
a. 反例:
StudyNo
Name
Sex
Contact
20040901
john
Male
Email:kkkk@ee.net,phone:222456
20040902
mary
famale
email:kkk@fff.net phone:123455
contact字段能夠再分,不符合第一範式。
b. 正解:
StudyNo
Name
Sex
Phone
20040901
john
Male
Email:kkkk@ee.net
222456
20040902
mary
famale
email:kkk@fff.net
123455
4. 第二範式:在第一範式基礎上,對於多關鍵字表,非主屬性不能部分依賴於主鍵(eg:只依賴某個主鍵);對於單關鍵字表,不存在部分依賴狀況(只依賴一個主鍵,所有依賴),全符合。
better eg:
訂單明細表:【OrderDetail】(OrderID,ProductID,UnitPrice,Discount,Quantity,ProductName)。
由於咱們知道在一個訂單中能夠訂購多種產品,因此單單一個 OrderID 是不足以成爲主鍵的,主鍵應該是(OrderID,ProductID)。顯而易見 Discount(折扣),Quantity(數量)徹底依賴(取決)於主鍵(OderID,ProductID),而 UnitPrice,ProductName 只依賴於 ProductID。因此 OrderDetail 表不符合 2NF。不符合 2NF 的設計容易產生冗餘數據。
能夠把【OrderDetail】表拆分爲【OrderDetail】(OrderID,ProductID,Discount,Quantity)和【Product】(ProductID,UnitPrice,ProductName)來消除原訂單表中UnitPrice,ProductName屢次重複的狀況。
a. 反例:
StudyNo
Name
Sex
Phone
ClassNo
ClassAddress
20040901
john
Male
Email:kkkk@ee.net
222456
200401
#12A
20040902
mary
famale
email:kkk@fff.net
123455
200402
#8A
主鍵是studyNo和classNo。classAddress部分依賴主鍵classNo,須要變爲兩個表。
b. 正解:
學生表
StudyNo
Name
Sex
Phone
20040901
john
Male
Email:kkkk@ee.net
222456
20040902
mary
famale
email:kkk@fff.net
123455
教室表
ClassNo
ClassAddress
200401
#12A
200402
#8A
c. 消除數據冗餘和增、刪、改異常。
(1) 數據冗餘:
同一門課程由n個學生選修,"學分"就重複n-1次;同一個學生選修了m門課程,姓名和年齡就重複了m-1次。
(2) 更新異常:
若調整了某門課程的學分,數據表中全部行的"學分"值都要更新,不然會出現同一門課程學分不一樣的狀況。
(3) 插入異常:
假設要開設一門新的課程,暫時尚未人選修。這樣,因爲尚未"學號"關鍵字,課程名稱和學分也沒法記錄入數據庫。
(4) 刪除異常:
假設一批學生已經完成課程的選修,這些選修記錄就應該從數據庫表中刪除。可是,與此同時,課程名稱和學分信息也被刪除了。很顯然,這也會致使插入異常。
5. 第三範式:在第二範式基礎上,非關鍵字段對任一主鍵不能傳遞函數依賴。非主鍵列必須直接依賴於主鍵,不能傳遞依賴。即不能存在:非主鍵列 A 依賴於非主鍵列 B,非主鍵列 B 依賴於主鍵的狀況。總之,非主鍵列之間不能存在依賴關係。
better eg:
訂單表【Order】(OrderID,OrderDate,CustomerID,CustomerName,CustomerAddr,CustomerCity)主鍵是(OrderID)。
其中 OrderDate,CustomerID,CustomerName,CustomerAddr,CustomerCity 等非主鍵列都徹底依賴於主鍵(OrderID),因此符合 2NF。不過問題是 CustomerName,CustomerAddr,CustomerCity 直接依賴的是 CustomerID(非主鍵列),而不是直接依賴於主鍵,它是經過傳遞才依賴於主鍵,因此不符合 3NF。
經過拆分【Order】爲【Order】(OrderID,OrderDate,CustomerID)和【Customer】(CustomerID,CustomerName,CustomerAddr,CustomerCity)從而達到 3NF。
a. 反例:
StudyNo
Name
Sex
Phone
BounsLevel
Bouns
20040901
john
Male
Email:kkkk@ee.net
222456
優秀
¥1200
20040902
mary
famale
email:kkk@fff.net
123455
良
¥800
主鍵是StudyNo,只有一個主鍵StudyNo,並且符合第二範式。可是非主鍵列bounsLevel和bouns存在依賴關係。
b. 正解:
學生表
StudyNo
Name
Sex
Phone
BounsNo
20040901
john
Male
Email:kkkk@ee.net
222456
1
20040902
mary
famale
email:kkk@fff.net
123455
2
獎學金等級表
BounsNo
BounsLevel
Bouns
1
優秀
¥1200
2
良
¥800
c. 消除數據冗餘和增、刪、改異常。
6. 鮑依斯-科得範式(BCNF):在第三範式的基礎上,數據庫表中若是不存在任何字段對任一候選關鍵字段的傳遞函數依賴則符合第三範式。即不存在關鍵字段決定關鍵字段的狀況。
a. 反例:StoreHouseManager
StoreHouseID(倉庫ID)
GoodsID(商品ID)
ManagerID(管理員ID)
GoodsNum(商品數量)
001
20130104
1
200
主鍵是
(倉庫ID, 商品ID) →(管理員ID, 數量) 或
(管理員ID, 商品ID) → (倉庫ID, 數量),
(倉庫ID, 商品ID)和(管理員ID,商品ID)都是StorehouseManage的候選關鍵字,表中的惟一非關鍵字段爲數量
知足第三範式。可是,存在關鍵字段決定關鍵字段狀況。
(倉庫ID) → (管理員ID)
(管理員ID) → (倉庫ID)
b. 正解:
倉庫管理表
StoreHouseID(倉庫ID)
GoodsID(商品ID)
GoodsNum(商品數量)
001
20130104
200
倉庫表
StoreHouseID(倉庫ID)
ManagerID(管理員ID)
001
1
c. 消除增、刪、改異常。
(1) 刪除異常:
當倉庫被清空後,全部"存儲物品ID"和"數量"信息被刪除的同時,"倉庫ID"和"管理員ID"信息也被刪除了。
(2) 插入異常:
當倉庫沒有存儲任何物品時,沒法給倉庫分配管理員。
(3) 更新異常:
若是倉庫換了管理員,則表中全部行的管理員ID都要修改。
應用的範式等級越高,則表越多。表多會帶來不少問題:1 查詢時要鏈接多個表,增長了查詢的複雜度2 查詢時須要鏈接多個表,下降了數據庫查詢性能而如今的狀況,磁盤空間成本基本能夠忽略不計,因此數據冗餘所形成的問題也並非應用數據庫範式的理由。所以,並非應用的範式越高越好,要看實際狀況而定。第三範式已經很大程度上減小了數據冗餘,而且減小了形成插入異常,更新異常,和刪除異常了。因此大多數狀況應用到第三範式已經足夠,在必定狀況下第二範式也是能夠的。