資料庫第一範式
❶ 資料庫知識什麼是1NF,2NF,3NF
1NF即第一範式,是指資料庫表的每一列都是不可分割的基本數據項,同一列中不能有多個值,即實體中的某個屬性不能有多個值或者不能有重復的屬性。
2NF即第二範式,是指每個表必須有且僅有一個數據元素為主關鍵字(Primary key),其他數據元素與主關鍵字一一對應。
3NF即第三範式,是指表中的所有數據元素不但要能唯一地被主關鍵字所標識,而且它們之間還必須相互獨立,不存在其他的函數關系。
(1)資料庫第一範式擴展閱讀:
第二範式的規則是要求數據表裡的所有非主屬性都要和該數據表的主鍵有完全依賴關系;如果有哪些非主屬性只和主鍵的一部份有關的話,它就不符合第二範式。如果一個數據表的主鍵只有單一一個欄位的話,它就一定符合第二範式(前提是該數據表符合第一範式)。
如果出現重復的屬性,就可能需要定義一個新的實體,新的實體由重復的屬性構成,新實體與原實體之間為一對多關系。在第一範式1NF中表的每一行只包含一個實例的信息。
參考資料來源:
網路——範式
網路——1NF
網路——第二範式
網路——第三範式
❷ 舉例說明一下怎麼算是第一範式、第二範式、第三範式
1.第一範式:存在非主屬性對碼的部分依賴關系 R(A,B,C) AB是碼 C是非主屬性 B-->C B決定C C部分依賴於B。如果關系R 中所有屬性的值域都是單純域,那麼關系模式R是第一範式的。
那麼符合第一模式的特點就有:有主關鍵字、主鍵不能為空、主鍵不能重復,、欄位不可以再分。例如:
StudyNo | Name | Sex | Contact
20040901 john Male Email:[email protected],phone:222456
20040901 mary famale email:[email protected] phone:123455
以上的表就不符合,第一範式:主鍵重復(實際中資料庫不允許重復的),而且Contact欄位可以再分
所以變更為正確的是:
StudyNo | Name | Sex | Email | Phone
20040901 john [email protected] 222456
20040902 mary [email protected] 123455
2.第二範式:存在非主屬性對碼的傳遞性依賴 R(A,B,C) A是碼 A -->B ,B-->C。如果關系模式R是第一範式的,而且關系中每一個非主屬性不部分依賴於主鍵,稱R是第二範式的。所以第二範式的主要任務就是:滿足第一範式的前提下,消除部分函數依賴。
StudyNo | Name | Sex | Email | Phone | ClassNo | ClassAddress
01 john [email protected] 222456 200401 A樓2
01 mary [email protected] 123455 200402 A樓3
這個表完全滿足於第一範式,主鍵由StudyNo和ClassNo組成,這樣才能定位到指定行。但是,ClassAddress部分依賴於關鍵字(ClassNo-〉ClassAddress,所以要變為兩個表:
表一
StudyNo | Name | Sex | Email | Phone | ClassNo
01 john [email protected] 222456 200401
01 mary [email protected] 123455 200402
表二
ClassNo | ClassAddress
200401 A樓2
200402 A樓3
3.第三範式
不存在非主屬性對碼的傳遞性依賴以及部分性依賴 ,
StudyNo | Name | Sex | Email | bounsLevel | bouns
20040901 john [email protected] 優秀 $1000
20040902 mary [email protected] 良 $600
這個完全滿足了第二範式,但是bounsLevel和bouns存在傳遞依賴,更改為:
StudyNo | Name | Sex | Email | bouunsNo
20040901 john [email protected] 1
20040902 mary [email protected] 2
bounsNo | bounsLevel | bouns
1 優秀 $1000
2 良 $600
這里可以用bounsNo作為主鍵,基於兩個原因
(1)不要用字元作為主鍵。可能有人說:如果我的等級一開始就用數值就代替呢?
(2)但是如果等級名稱更改了,不叫 1,2 ,3或優、良,這樣就可以方便更改,所以一般優先使用與業務無關的欄位作為關鍵字。
一般滿足前三個範式就可以避免數據冗餘。
(2)資料庫第一範式擴展閱讀:
設計關系資料庫時,遵從不同的規范要求,設計出合理的關系型資料庫,這些不同的規范要求被稱為不同的範式,各種範式呈遞次規范,越高的範式資料庫冗餘越小。
目前關系資料庫有六種範式:第一範式(1NF)、第二範式(2NF)、第三範式(3NF)、巴斯-科德範式(BCNF)、第四範式(4NF)和第五範式(5NF,又稱完美範式)。
設計關系資料庫時,遵從不同的規范要求,設計出合理的關系型資料庫,這些不同的規范要求被稱為不同的範式,各種範式呈遞次規范,越高的範式資料庫冗餘越小。
目前關系資料庫有六種範式:第一範式(1NF)、第二範式(2NF)、第三範式(3NF)、巴斯-科德範式(BCNF)、第四範式(4NF)和第五範式(5NF,又稱完美範式)。滿足最低要求的範式是第一範式(1NF)。在第一範式的基礎上進一步滿足更多規范要求的稱為第二範式(2NF),其餘範式以次類推。一般說來,資料庫只需滿足第三範式(3NF)就行了。
參考鏈接:
網路-資料庫範式
❸ 第一範式第二範式第三範式的定義是什麼
第一範式定義是指資料庫表的每一列都是不可分割的基本數據項,同一列中不能有多個值,即實體中的某個屬性不能有多個值或者不能有重復的屬性。
第二範式定義是屬性完全依賴於主鍵,要求資料庫表中的每個實例或行必須可以被唯一地區分。為實現區分通常需要為表加上一個列,以存儲各個實例的惟一標識。
第三範式定義是要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字信息。
第一範式第二範式第三範式的要求
第一範式要求消除拆分欄位至原子欄位,即不可再拆分;第二範式要求消除部分函數依賴,實現完全函數依賴;第三範式要求消除傳遞函數依賴。
每個屬性不可再分。相近或一樣的屬性要盡量合並在一起確保不會產生冗餘數據。是對關系模型的基本要求,不滿足第一範式的關系,不能稱之為關系型資料庫。符合第一範式的關系,每個屬性都不可以再分割。
❹ 什麼是資料庫三大範式
1
第一範式(1nf)
在任何一個關系資料庫中,第一範式(1nf)是對關系模式的基本要求,不滿足第一範式(1nf)的資料庫就不是關系資料庫。
所謂第一範式(1nf)是指資料庫表的每一列都是不可分割的基本數據項,同一列中不能有多個值,即實體中的某個屬性不能有多個值或
者不能有重復的屬性。如果出現重復的屬性,就可能需要定義一個新的實體,新的實體由重復的屬性構成,新實體與原實體之間為一對多關系
。在第一範式(1nf)中表的每一行只包含一個實例的信息。例如,對於圖3-2
中的員工信息表,不能將員工信息都放在一列中顯示,也不能將
其中的兩列或多列在一列中顯示;員工信息表的每一行只表示一個員工的信息,一個員工的信息在表中只出現一次。簡而言之,第一範式就是
無重復的列。
2
第二範式(2nf)
第二範式(2nf)是在第一範式(1nf)的基礎上建立起來的,即滿足第二範式(2nf)必須先滿足第一範式(1nf)。第二範式(2nf)要
求資料庫表中的每個實例或行必須可以被唯一地區分。為實現區分通常需要為表加上一個列,以存儲各個實例的唯一標識。如圖3-2
員工信息
表中加上了員工編號(emp_id)列,因為每個員工的員工編號是唯一的,因此每個員工可以被唯一區分。這個唯一屬性列被稱為主關鍵字或主
鍵、主碼。
第二範式(2nf)要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性,如果存在,那麼這個
屬性和主關鍵字的這一部分應該分離出來形成一個新的實體,新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列,以
存儲各個實例的唯一標識。簡而言之,第二範式就是非主屬性非部分依賴於主關鍵字。
3
第三範式(3nf)
滿足第三範式(3nf)必須先滿足第二範式(2nf)。簡而言之,第三範式(3nf)要求一個資料庫表中不包含已在其它表中已包含的非主
關鍵字信息。例如,存在一個部門信息表,其中每個部門有部門編號(dept_id)、部門名稱、部門簡介等信息。那麼在圖3-2的員工信息表中
列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表,則根據第三範式(3nf)也
應該構建它,否則就會有大量的數據冗餘。簡而言之,第三範式就是屬性不依賴於其它非主屬性。
❺ 關於資料庫的1範式,2範式,3範式和BC範式,求大神說明一下~不是很懂啊
1範式指在關系模型中,對於添加的一個規范要求,所有的域都應該是原子性的,即資料庫表的每一列都是不可分割的原子數據項,而不能是集合,數組,記錄等非原子數據項。
即實體中的某個屬性有多個值時,必須拆分為不同的屬性。在符合第一範式(1NF)表中的每個域值只能是實體的一個屬性或一個屬性的一部分。簡而言之,第一範式就是無重復的域。
2範式,在1NF的基礎上,非碼屬性必須完全依賴於候選碼(在1NF基礎上消除非主屬性對主碼的部分函數依賴)。
3範式,在2NF基礎上,任何非主屬性不依賴於其它非主屬性(在2NF基礎上消除傳遞依賴)。
BC範式,Boyce-Codd Normal Form(巴斯-科德範式),在3NF基礎上,任何非主屬性不能對主鍵子集依賴(在3NF基礎上消除對主碼子集的依賴)。
(5)資料庫第一範式擴展閱讀
第二範式為資料庫規范化中所使用的一種正規形式。它的規則是要求數據表裡的所有非主屬性都要和該數據表的主鍵有完全依賴關系;如果有哪些非主屬性只和主鍵的一部份有關的話,它就不符合第二範式。同時可以得出:如果一個數據表的主鍵只有單一一個欄位的話,它就一定符合第二範式(前提是該數據表符合第一範式)。
❻ 資料庫設計範式的第一範式
無重復的列
資料庫表的每一列都是不可分割的原子數據項,而不能是集合,數組,記錄等非原子數據項。如果實體中的某個屬性有多個值時,必須拆分為不同的屬性
在任何一個關系資料庫中,第一範式(1NF)是對關系模式的設計基本要求,一般設計中都必須滿足第一範式(1NF)。不過有些關系模型中突破了1NF的限制,這種稱為非1NF的關系模型。換句話說,是否必須滿足1NF的最低要求,主要依賴於所使用的關系模型。
❼ 資料庫中第一二三四範式應該怎樣去理解
第一範式(1NF):在關系模式R中的每一個具體關系r中,如果每個屬性值 都是不可再分的最小數據單位,則稱R是第一範式的關系。例:如職工號,姓名,電話號碼組成一個表(一個人可能有一個辦公室電話 和一個家裡電話號碼) 規范成為1NF有三種方法:
一是重復存儲職工號和姓名。這樣,關鍵字只能是電話號碼。
二是職工號為關鍵字,電話號碼分為單位電話和住宅電話兩個屬性
三是職工號為關鍵字,但強制每條記錄只能有一個電話號碼。
以上三個方法,第一種方法最不可取,按實際情況選取後兩種情況。
第二範式(2NF):如果關系模式R(U,F)中的所有非主屬性都完全依賴於任意一個候選關鍵字,則稱關系R 是屬於第二範式的。
例:選課關系 SCI(SNO,CNO,GRADE,CREDIT)其中SNO為學號, CNO為課程號,GRADEGE 為成績,CREDIT 為學分。 由以上條件,關鍵字為組合關鍵字(SNO,CNO)
在應用中使用以上關系模式有以下問題:
a.數據冗餘,假設同一門課由40個學生選修,學分就 重復40次。
b.更新異常,若調整了某課程的學分,相應的元組CREDIT值都要更新,有可能會出現同一門課學分不同。
c.插入異常,如計劃開新課,由於沒人選修,沒有學號關鍵字,只能等有人選修才能把課程和學分存入。
d.刪除異常,若學生已經結業,從當前資料庫刪除選修記錄。某些門課程新生尚未選修,則此門課程及學分記錄無法保存。
原因:非關鍵字屬性CREDIT僅函數依賴於CNO,也就是CREDIT部分依賴組合關鍵字(SNO,CNO)而不是完全依賴。
解決方法:分成兩個關系模式 SC1(SNO,CNO,GRADE),C2(CNO,CREDIT)。新關系包括兩個關系模式,它們之間通過SC1中的外關鍵字CNO相聯系,需要時再進行自然聯接,恢復了原來的關系
第三範式(3NF):如果關系模式R(U,F)中的所有非主屬性對任何候選關鍵字都不存在傳遞信賴,則稱關系R是屬於第三範式的。
例:如S1(SNO,SNAME,DNO,DNAME,LOCATION) 各屬性分別代表學號,
姓名,所在系,系名稱,系地址。
關鍵字SNO決定各個屬性。由於是單個關鍵字,沒有部分依賴的問題,肯定是2NF。但這關系肯定有大量的冗餘,有關學生所在的幾個屬性DNO,DNAME,LOCATION將重復存儲,插入,刪除和修改時也將產生類似以上例的情況。
原因:關系中存在傳遞依賴造成的。即SNO -> DNO。 而DNO -> SNO卻不存在,DNO -> LOCATION, 因此關鍵遼 SNO 對 LOCATION 函數決定是通過傳遞依賴 SNO -> LOCATION 實現的。也就是說,SNO不直接決定非主屬性LOCATION。
解決目地:每個關系模式中不能留有傳遞依賴。
解決方法:分為兩個關系 S(SNO,SNAME,DNO),D(DNO,DNAME,LOCATION)
注意:關系S中不能沒有外關鍵字DNO。否則兩個關系之間失去聯系。
BCNF:如果關系模式R(U,F)的所有屬性(包括主屬性和非主屬性)都不傳遞依賴於R的任何候選關鍵字,那麼稱關系R是屬於BCNF的。或是關系模式R,如果每個決定因素都包含關鍵字(而不是被關鍵字所包含),則RCNF的關系模式。
例:配件管理關系模式 WPE(WNO,PNO,ENO,QNT)分別表倉庫號,配件號,職工號,數量。有以下條件
a.一個倉庫有多個職工。
b.一個職工僅在一個倉庫工作。
c.每個倉庫里一種型號的配件由專人負責,但一個人可以管理幾種配件。
d.同一種型號的配件可以分放在幾個倉庫中。
分析:由以上得 PNO 不能確定QNT,由組合屬性(WNO,PNO)來決定,存在函數依賴(WNO,PNO) -> ENO。由於每個倉庫里的一種配件由專人負責,而一個人可以管理幾種配件,所以有組合屬性(WNO,PNO)才能確定負責人,有(WNO,PNO)-> ENO。因為 一個職工僅在一個倉庫工作,有ENO -> WNO。由於每個倉庫里的一種配件由專人負責,而一個職工僅在一個倉庫工作,有 (ENO,PNO)-> QNT。
找一下候選關鍵字,因為(WNO,PNO) -> QNT,(WNO,PNO)-> ENO ,因此 (WNO,PNO)可以決定整個元組,是一個候選關鍵字。根據ENO->WNO,(ENO,PNO)->QNT,故(ENO,PNO)也能決定整個元組,為另一個候選關鍵字。屬性ENO,WNO,PNO 均為主屬性,只有一個非主屬性QNT。它對任何一個候選關鍵字都是完全函數依賴的,並且是直接依賴,所以該關系模式是3NF。
分析一下主屬性。因為ENO->WNO,主屬性ENO是WNO的決定因素,但是它本身不是關鍵字,只是組合關鍵字的一部分。這就造成主屬性WNO對另外一個候選關鍵字(ENO,PNO)的部 分依賴,因為(ENO,PNO)-> ENO但反過來不成立,而P->WNO,故(ENO,PNO)-> WNO 也是傳遞依賴。
雖然沒有非主屬性對候選關鍵遼的傳遞依賴,但存在主屬性對候選關鍵字的傳遞依賴,同樣也會帶來麻煩。如一個新職工分配到倉庫工作,但暫時處於實習階段,沒有獨立負責對某些配件的管理任務。由於缺少關鍵字的一部分PNO而無法插入到該關系中去。又如某個人改成不管配件了去負責安全,則在刪除配件的同時該職工也會被刪除。
解決辦法:分成管理EP(ENO,PNO,QNT),關鍵字是(ENO,PNO)工作EW(ENO,WNO)其關鍵字是ENO
缺點:分解後函數依賴的保持性較差。如此例中,由於分解,函數依賴(WNO,PNO)-> ENO 丟失了, 因而對原來的語義有所破壞。沒有體現出每個倉庫里一種部件由專人負責。有可能出現 一部件由兩個人或兩個以上的人來同時管理。因此,分解之後的關系模式降低了部分完整性約束。
一個關系分解成多個關系,要使得分解有意義,起碼的要求是分解後不丟失原來的信息。這些信息不僅包括數據本身,而且包括由函數依賴所表示的數據之間的相互制約。進行分解的目標是達到更高一級的規范化程度,但是分解的同時必須考慮兩個問題:無損聯接性和保持函數依賴。有時往往不可能做到既有無損聯接性,又完全保持函數依賴。需要根據需要進行權衡。
1NF直到BCNF的四種範式之間有如下關系:
BCNF包含了3NF包含2NF包含1NF
很少有人做到很符合以上幾個範式的,一般說來,第一範式大家都可以遵守,完全遵守第二第三範式的人很少了,遵守的人一定就是設計資料庫的高手了,BCNF的範式出現機會較少,而且會破壞完整性,你可以在做設計之時不考慮它,當然在ORACLE中可通過觸發器解決其缺點。
❽ 第一範式第二範式第三範式怎麼區分
滿足第一範式 就是每個屬性都不可在拆分,滿足第二範式,非屬性值要完全依賴主編碼 非碼屬性不相互依賴,滿足第三範式,不存在傳遞依賴。
❾ 資料庫有幾種範式
目前關系資料庫有六種範式,即第一範式(1NF)、第二範式(2NF)、第三範式(3NF)、巴斯−科德範式(BCNF)、第四範式(4NF)和第五範式(5NF,又稱完美範式)。滿足最低要求的範式是第一範式(1NF)。在第一範式的基礎上進一步滿足更多規范要求的稱為第二範式(2NF),其餘範式依次類推。一般來說,資料庫只需滿足第三範式(3NF)。
第一範式(1NF)第一範式(1NF)是指在關系模型中,對域添加的一個規范要求,所有的域都應該是原子性的,即資料庫表的每一列都是不可分割的原子數據項,而不是集合、數組、記錄等非原子數據項。即實體中的某個屬性有多個值時,必須拆分為不同的屬性。在符合第一範式(1NF)表中的每個域值只能是實體的一個屬性或一個屬性的一部分。
簡而言之,第一範式(1NF)是最基本的範式,如果資料庫表中的所有欄位值都是不可分解的原子值,就說明該資料庫表滿足第一範式(1NF)。在任何一個關系資料庫中,第一範式(1NF)是對關系模式設計的基本要求,所有設計的數據模型都必須滿足第一範式(1NF)。
從上面的定義描述中,可以歸納出第一範式(1NF)具有如下幾個顯著特點:((1)資料庫表中的欄位都是單一屬性。
①欄位不可再分。
②同一列中不能有多個值。
(2)單一屬性由基本類型構成。
①整型。
②實數。
③字元型。
④邏輯型。
⑤日期型。
⑥其他類型。
滿足以上兩大特徵的表就是符合第一範式(1NF)的表,不滿足以上任一特徵的表都是不符合第一範式(1NF)的表。
例如,圖欄位可再分的表所示的「電話」欄位可以再拆分成「手機」與「座機」欄位,不滿足「欄位不可再分」的要求,因此不符合第一範式(1NF)要求。
欄位可再分的表
又如,圖欄位可再分的表所示的「姓名」欄位包含「張偉」與「宋鑫」兩個值,不滿足「同一列中不能有多個值」的要求,因此也不符合第一範式(1NF)要求。
同一列中有多個值的表
第二範式(2NF)第二範式(2NF)是在第一範式(1NF)的基礎上建立起來的,即滿足第二範式(2NF)必須先滿足第一範式(1NF)。第二範式(2NF)要求資料庫表中的每個實例或記錄必須可以被唯一地區分。選取一個能區分每個實體的屬性或屬性組,作為實體的唯一標識。例如,員工表中的身份證號碼即可實現每個員工的區分,該身份證號碼即候選鍵,任何一個候選鍵都可以被選作主鍵。在找不到候選鍵時,可額外增加屬性以實現區分。如果在員工關系中沒有對其身份證號碼進行存儲,而姓名可能會在資料庫運行的某個時間重復,無法區分出實體時,設計身份證號碼等不重復的編號以實現區分,被添加的編號選作主鍵。注意:該主鍵的添加是在ER設計時添加,不是在建庫時隨意添加。
第二範式(2NF)要求實體的屬性完全依賴於主關鍵字。所謂完全依賴,是指不能存在僅依賴主關鍵字一部分的屬性,如果存在,那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體,新實體與原實體之間是一對多的關系。為實現區分,通常需要為表加上一個列,以存儲各個實例的唯一標識。
簡而言之,第二範式(2NF)在第一範式(1NF)的基礎之上更進一層。第二範式(2NF)需要確保資料庫表中的每一列都和主鍵相關,而不能只與主鍵的某一部分相關(主要針對聯合主鍵而言)。也就是說在一個資料庫表中,一個表中只能保存一種數據,不可以把多種數據保存在同一個資料庫表中。
所謂聯合主鍵,是指由兩個或兩個以上的欄位共同組成數據表的主鍵。如圖聯合主鍵表所示,單憑「客戶」欄位無法確定表中唯一的記錄,單憑「開戶銀行」欄位也無法確定表中唯一的與「開戶銀行」一起組成數據表的聯合主鍵。
聯合主鍵表
從上面的定義描述中,可以歸納出第二範式(2NF)具有如下幾個顯著特點:((1)資料庫表滿足第一範式(1NF)。
(2)資料庫中每個表均有主鍵。
①單欄位主鍵。
②聯合主鍵。即不能存在單個主鍵欄位決定非主鍵欄位的情況。
例如,表中有A、B、C、D、E五個欄位,若A與B為聯合主鍵(A,B),如有A決定C的情況(A→C),則不符合第二範式(2NF)。
滿足以上特徵的表就是符合第二範式(2NF)的表,不滿足以上任何一特徵的表都是不符合第二範式(2NF)的表。
例如,如圖所示,所有欄位均不可再拆分,因而滿足第一範式(1NF)的要求,但表中沒有任何一個欄位可以確定表中的唯一記錄,即表中沒有主鍵,因此其不滿足「資料庫中每張表均有主鍵」的要求,所以不符合第二範式(2NF)要求。
又如,如圖所示,滿足第一範式(1NF)的要求,並且在原來的基礎上增加了「ID」欄位作為表的主鍵,因此其符合第二範式(2NF)要求。
沒有主鍵的數據表
增加了主鍵的數據表
重新分析圖1−3所示的聯合主鍵表,此表符合第一範式(1NF)「欄位不可再拆分」的要求,並且有「客戶」與「開戶銀行」兩個欄位作為表的聯合主鍵(客戶,開戶銀行),但其是否就是一個符合第二範式(2NF)的表呢?
進一步分析,就可以發現:「客戶電話」欄位由「客戶」欄位決定,「開戶行地址」欄位由「開戶銀行」欄位決定;即存在如下依賴關系:客戶→客戶電話,開戶銀行→開戶行地址。
(客戶,開戶銀行)為主鍵欄位,(客戶電話,開戶行地址)為非主鍵欄位,因此,其不符合聯合主鍵中「不能存在單個主鍵欄位決定非主鍵欄位」的情況,所以可以認定其並不是符合第二範式(2NF)的數據表。
例1.1判斷如圖所示的學生信息表是否符合第二範式(2NF)。
圖所示中存在聯合主鍵(學號,課程編號),但存在(學號→姓名)、(課程編號→課程名)的依賴關系,即存在某個主鍵欄位決定非主鍵欄位的情況,因此其不符合第二範式(2NF),不是第二範式(2NF)表。可考慮把此表拆成分數表(見圖)、課程表(見圖)和姓名表(見圖),則此三個表是符合第二範式(2NF)的表。
圖學生信息表
圖分數表
圖課程表
圖姓名表
第三範式(3NF)第三範式(3NF)是第二範式(2NF)的一個子集,即滿足第三範式(3NF)必須滿足第二範式(2NF)。第三範式(3NF)要求一個關系中不包含已在其他關系包含的非主關鍵字信息。
第三範式(3NF)就是任何非主屬性不依賴於其他非主屬性,也就是在滿足第二範式(2NF)的基礎上,任何非主屬性不得傳遞依賴於主屬性。第三範式(3NF)需要確保數據表中的每一列數據都和主鍵直接相關,而不能間接相關。數據不能存在傳遞關系,即每個屬性都跟主鍵有直接關系而不是間接關系。如屬性之間含有A→B→C這樣的關系,是不符合第三範式(3NF)的。
當數據表不符合第三範式(3NF)時,會有大量的冗餘數據,還會存在插入異常、刪除異常、數據冗餘度大、修改復雜等問題。
從上面的定義描述中,可以歸納出第三範式(3NF)具有如下幾個顯著特點:((1)資料庫表滿足第二範式。
(2)資料庫表的非主鍵欄位不存在傳遞依賴關系(即非主鍵欄位不能決定其他非主鍵欄位)。例如,表中有A、B、C、D、E五個欄位,若A為主鍵,如有C決定D的情況(C→D)則不符合第三範式(3NF)。
滿足以上特徵的表就是符合第三範式(3NF)的表,不滿足以上任何一特徵的表都是不符合第三範式(3NF)的表。
如圖所示,表中有主鍵(工號),因而滿足第二範式(2NF)的要求;但表中非主鍵欄位間存在傳遞依賴關系:非主鍵欄位「部門」決定非主鍵欄位「部門電話」和「部門主管」(部門→部門電話,部門→部門主管),因此不符合第三範式(3NF)的要求。
圖非主鍵欄位存在傳遞依賴關系的表
例1.2判斷圖所示的學生院屬信息表是否符合第三範式(3NF)。
圖學生院屬信息表
圖中有主鍵(學號),則滿足第二範式(2NF)的要求,但存在(所在學院→學院電話)、(所在學院→學院地點),即存在非主鍵欄位決定其他非主鍵欄位的情況,因此其不符合第三範式(3NF)的要求,不是第三範式(3NF)表。可考慮把此表拆成學生表(見圖)和學院表(見圖),則兩個表是符合第三範式(3NF)的表。
圖學生表
圖學院表
❿ 資料庫三大範式通俗理解是什麼
1、第一範式(1NF):
所謂第一範式(1NF)是指在關系模型中,對於添加的一個規范要求,所有的域都應該是原子性的,即資料庫表的每一列都是不可分割的原子數據項,而不能是集合,數組,記錄等非原子數據項。
即實體中的某個屬性有多個值時,必須拆分為不同的屬性。在符合第一範式(1NF)表中的每個域值只能是實體的一個屬性或一個屬性的一部分。簡而言之,第一範式就是無重復的域。
2、第二範式(2NF)
在1NF的基礎上,非碼屬性必須完全依賴於候選碼(在1NF基礎上消除非主屬性對主碼的部分函數依賴)
第二範式(2NF)是在第一範式(1NF)的基礎上建立起來的,即滿足第二範式(2NF)必須先滿足第一範式(1NF)。第二範式(2NF)要求資料庫表中的每個實例或記錄必須可以被唯一地區分。選取一個能區分每個實體的屬性或屬性組,作為實體的唯一標識。
3、第三範式(3NF)
在2NF基礎上,任何非主屬性不依賴於其它非主屬性(在2NF基礎上消除傳遞依賴)第三範式(3NF)是第二範式(2NF)的一個子集,即滿足第三範式(3NF)必須滿足第二範式(2NF)。簡而言之,第三範式(3NF)要求一個關系中不包含已在其它關系已包含的非主關鍵字信息。
關系模型結構
1、單一的數據結構——關系(表文件)。關系資料庫的表採用二維表格來存儲數據,是一種按行與列排列的具有相關信息的邏輯組,它類似於Excel工作表。一個資料庫可以包含任意多個數據表。在用戶看來,一個關系模型的邏輯結構是一張二維表,由行和列組成。這個二維表就叫關系,通俗地說,一個關系對應一張表。
2、元組(記錄)。表中的一行即為一個元組,或稱為一條記錄。
3、屬性(欄位)。數據表中的每一列稱為一個欄位,表是由其包含的各種欄位定義的,每個欄位描述了它所含有的數據的意義,數據表的設計實際上就是對欄位的設計。創建數據表時,為每個欄位分配一個數據類型,定義它們的數據長度和其他屬性。欄位可以包含各種字元、數字、甚至圖形。
以上內容參考網路——資料庫範式、網路——關系資料庫