? 何為關系模式? 1.關系的描述稱為關系模式(RelationSchema) 2.它可以形式化地表示為:R(U,D,dom,F),其中R為關系名,U為組成該關系的屬性名集合,D為屬性組U中屬性所來自的域,dom為屬性向域的映象集合,F為屬性間數據的依賴關系集合。 3.通常簡記
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等等,下面重點介紹前三種。
(范式,數據庫設計范式,數據庫的設計范式)是符合某一種級別的關系模式的集合。構造數據庫必須遵循一定的規則。在關系數據庫中,這種規則就是范式。關系數據庫中的關系必須滿足一定的要求,即滿足不同的范式。
如果關系模式R的每個關系r的屬性值都是不可分的原子值,也就是說數據庫表中的字段都是單一屬性的,不可再分。這個單一屬性由基本類型構成,包括整型、實數、字符型、邏輯型、日期型等。
例如:這種數據庫表是符合第一范式的
然而這種的數據庫表是不符合第一范式的
1.如果關系模式R是1NF,且每個非主屬性完全函數依賴于候選鍵,那么稱R是第二范式。
2.也就是說第二范式(2NF)是在第一范式(1NF)的基礎上建立起來的,即滿足第二范式(2NF)必須先滿足第一范式(1NF)。第二范式(2NF)要求數據庫表中的每個實例或行必須可以被惟一地區分。
3.第二范式(2NF)要求實體的屬性完全依賴于主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性,如果存在,那么這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體,新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列,以存儲各個實例的惟一標識。簡而言之,第二范式就是屬性完全依賴于主鍵。
4.不符合第二范式帶來的影響是出現數據冗余、刪除異常、更新異常、插入異常等等。
例如:一個訂單的表
從這個圖上我們可以看出這個表是有問題的,因為這個表是以訂單編號和產品編號為聯合主鍵的,這樣就會出現問題,問題就是產品的價格只是與產品編號有關,訂購日期只是與訂單編號有關,故而違背了第二范式的設計原則,應該將其拆分如下圖:
訂單信息:
產品信息:
這樣設計,在很大程度上減小了數據庫的冗余。如果要獲取訂單的信息,使用訂單編號到訂單信息表中查詢即可。
a)如果關系模式R是1NF,且每個非主屬性都不傳遞依賴于R的候選鍵。
b)也就是說滿足第三范式(3NF)必須先滿足第二范式(2NF)。簡而言之,第三范式(3NF)要求一個數據庫表中不包含已在其它表中已包含的非主關鍵字信息。
c)再進一步在第二范式的基礎上,數據表中如果不存在非關鍵字段對任一候選關鍵字段的傳遞函數依賴則符合第三范式。所謂傳遞函數依賴,指的是如果存在"A → B → C"的決定關系,則C傳遞函數依賴于A。因此,滿足第三范式的數據庫表應該不存在如下依賴關系: 關鍵字段 → 非關鍵字段x → 非關鍵字段y
舉例:同樣是訂單表
這樣把客戶信息和產品信息放入一個表中,在查詢時就得輸入客戶的全部信息,那么就會造成數據的冗余,如果將其拆分,分類之后就會減少數據的冗余。
訂單信息表:
顧客信息表:
這樣在查詢訂單信息的時候,就可以使用顧客編號來引用顧客信息表中的記錄,也不必在訂單信息表中多次輸入顧客信息的內容,減小了數據冗余。
1.滿足1NF的關系為規范化的關系,否則為非規范化的關系。
2.規范化的本質是提高數據獨立性,解決插入異常、刪除異常、修改復雜、數據冗余等問題的方法。
3.規范化的基本思想是逐步消除數據依賴中不適合的部分。
(一) 第一范式目標(1NF):確保每列的原子性。
(二) 第二范式目標(2NF):確保表中的每列,都和主鍵有關。
(三) 第三范式目標(3NF):確保每列都和主鍵列直接相關,而不是間接相關。
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com