導航:首頁 > 編程大全 > 資料庫第五式范

資料庫第五式范

發布時間:2023-11-14 09:55:26

『壹』 資料庫有幾種範式

目前關系資料庫有六種範式,即第一範式(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)的表。

圖學生表

圖學院表

『貳』 簡述資料庫的三大範式和五大約束

範式書上講解太拗口,自己總結一下:

第一範式:數據表中的每一列(每個欄位)必須是不可拆分的最小單元,不允許存在隱藏欄位,屬性保持「原子性」(最大細分的二維表)

第二範式:第一範式基礎上要有主鍵,所有列都必須依賴於主鍵,而不能有任何一列與主鍵沒有關系,也就是說一個表只描述一件事情(相當於這行闡述的是一個人時,你不能加一列說明天氣)

第三範式:滿足第二範式,表中的每一列只與主鍵直接相關而不是間接相關,(表中的每一列只能依賴於主鍵)

正規化範式(BCDF):所有表中的決定因素必須是一個候選鍵,如果只有一個候選鍵,那麼就和第三範式是一樣的。

有第四第五範式,更高的範式是為了解決數據冗餘問題,但可以通過其他辦法達到。所以一般用不到

五大約束:
1. primary KEY :設置主鍵約束;

2. UNIQUE :設置唯一性約束,不能有重復值;

3. DEFAULT 默認值約束,height DOUBLE(3,2)DEFAULT 1.2 height不輸入是默認為1,2

4. NOT NULL :設置非空約束,該欄位不能為空;

5. FOREIGN key :設置外鍵約束。

『叄』 數據結構中的1範式,2範式,3範式,bc範式,4範式,5範式。怎麼理解希望解釋的直白些。

這個不是數據結構的內容,屬於資料庫設計的范疇。規范化設計資料庫可以減少數據冗餘,減少數據插入、更新異常。
1範式,2範式,3範式,bc範式,4範式,5範式是規范化標准。
比如:目前的所有商用資料庫設計出來的表至少必須滿足第一範式(1nf:即滿足表的所有屬性都是不能再分解的原子屬性)。
2範式-5範式這些標准多是根據表的屬性間的不同程度的函數依賴(從1nf到5nf逐步提高標准)來區分的。由資料庫設計者把握設計出來的資料庫規范化到什麼程度。理論上滿足的規范化程度越高,設計出來的資料庫越有效、穩定。但有時候考慮到數據查詢、表連接的頻率問題,不得不反規范化,減低滿足的標准才能提高程序執行效率。

簡單的講可以這樣理解:
第一範式:指表中的屬性都是原子屬性,不能再拆分了。
第二範式:在第一範式的基礎上,要求非主屬性都完全函數依賴於主鍵。
第三範式:在第二範式的基礎上,要求要求沒有非主屬性傳遞依賴於主鍵。
BC範式:在第三範式基礎上,要求所有非主鍵屬性都必須依賴於主鍵。
第四範式:在BC範式基礎上,要求表中存在的多值依賴都必須是對主鍵函數依賴。
第五範式:在第四範式的基礎上,繼續拆分表格,消除多值依賴。
在一個表中:
主屬性:所有包含在候選碼里的屬性。
非主屬性:不包含在候選碼里的屬性。
候選碼:一個或者一組可以唯一標識一條記錄且不含多餘屬性的屬性。
函數依賴:表中屬性X的值可以唯一確定Y的值,則說:X確定Y,或Y依賴於X(記作X->Y)。
傳遞依賴:X->Y,Y->Z。則可以說Z傳遞依賴於X。
多值依賴:一個屬性的值可以確定一組屬性。(函數依賴是一種特殊的多值依賴,依賴的整組屬性只有1個,而不是多個)

(例如假設有一個人事資料的數據表,我們根據表中記錄的一個人的姓名,我們可以查到他的年齡即有: 姓名->年齡。在沒有同名存在的情況下,姓名就是這個表的候選鍵(碼),因為姓名可以唯一確定一條記錄的其他屬性,例如:姓名->(性別、年齡、職位),同時我們把姓名選為該表的主鍵(含主屬性)。姓名以外的其他屬性即為非主屬性。有時候一個表可以有多個候選鍵,則需要選擇其中一組作為主鍵,所有候選鍵包括的屬性都是主屬性。)

以上內容都是根據自己理解信手敲出。並沒有嚴謹的校對教科書的概念。如有疏漏錯誤實屬正常,如有人補漏改錯不勝榮幸。

『肆』 資料庫五大範式是什麼

第一範式(1NF)

在任何一個關系資料庫中,第一範式(1NF)是對關系模式的基本要求,不滿足第一範式(1NF)的資料庫就不是關系資料庫。

所謂第一範式(1NF)是指資料庫表的每一列都是不可分割的基本數據項,同一列中不能有多個值,即實體中的某個屬性不能有多個值或者不能有重復的屬性。如果出現重復的屬性,就可能需要定義一個新的實體,新的實體由重復的屬性構成,新實體與原實體之間為一對多關系。在第一範式(1NF)中表的每一行只包含一個實例的信息。例如,對於圖3-2 中的員工信息表,不能將員工信息都放在一列中顯示,也不能將其中的兩列或多列在一列中顯示;員工信息表的每一行只表示一個員工的信息,一個員工的信息在表中只出現一次。簡而言之,第一範式就是無重復的列。 3.4.2 第二範式(2NF)

第二範式(2NF)是在第一範式(1NF)的基礎上建立起來的,即滿足第二範式(2NF)必須先滿足第一範式(1NF)。第二範式(2NF)要求資料庫表中的每個實例或行必須可以被惟一地區分。為實現區分通常需要為表加上一個列,以存儲各個實例的惟一標識。如

圖3-2 員工信息表中加上了員工編號(emp_id)列,因為每個員工的員工編號是惟一的,因此每個員工可以被惟一區分。這個惟一屬性列被稱為主關鍵字或主鍵、主碼。
第二範式(2NF)要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性,如果存在,那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體,新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列,以存儲各個實例的惟一標識。簡而言之,第二範式就是非主屬性非部分依賴於主關鍵字。

3.4.3 第三範式(3NF)

滿足第三範式(3NF)必須先滿足第二範式(2NF)。簡而言之,第三範式(3NF)要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字信息。例如,存在一個部門信息表,其中每個部門有部門編號(dept_id)、部門名稱、部門簡介等信息。那麼在圖3-2

的員工信息表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表,則根據第三範式(3NF)也應該構建它,否則就會有大量的數據冗餘。簡而言之,第三範式就是屬性不依賴於其它非主屬性。

閱讀全文

與資料庫第五式范相關的資料

熱點內容
手機的下拉菜單代碼 瀏覽:384
寧波ug編程培訓中心哪裡好 瀏覽:565
描述性別是屬於什麼數據 瀏覽:752
聽力障礙人群用哪些app 瀏覽:932
中國郵政ems微信號 瀏覽:699
win10刪除更新補丁 瀏覽:870
哪裡有賣二手電筒腦的app 瀏覽:139
希臘雅典數據中心在哪裡 瀏覽:513
pad背景文件 瀏覽:608
dellwin7開機圖片文件 瀏覽:638
linux進度條定時 瀏覽:619
重建路徑文件 瀏覽:642
買房提前准備什麼文件 瀏覽:926
cmd查看oracle版本 瀏覽:767
蘋果用什麼軟體搜番號 瀏覽:409
app數據託管多少錢一年 瀏覽:907
PE系統考文件很慢 瀏覽:284
qt文件夾路徑輸入方式 瀏覽:773
游戲app怎麼獲客 瀏覽:721
inhealthapp連不上 瀏覽:611

友情鏈接