資料庫第四範式

⑴ 資料庫三大範式通俗理解是什麼

在關系資料庫中，這種規則就是範式。關系資料庫中的關系必須滿足一定的要求，即滿足不同的範式。目前關系資料庫有六種範式：

第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、第四範式（4NF）、第五範式（5NF）和第六範式（6NF）。滿足最低要求的範式是第一範式（1NF）。

在第一範式的基礎上進一步滿足更多要求的稱為第二範式（2NF），其餘範式以次類推。一般說來，資料庫只需滿足第三範式（3NF）就行了。下面我們舉例介紹第一範式（1NF）、第二範式（2NF）和第三範式（3NF）。

(1)資料庫第四範式擴展閱讀：

規范化目的是使結構更合理，消除存儲異常，使數據冗餘盡量小。便於插入、刪除和更新。

遵從概念單一化「一事一地」原則，即一個關系模式描述一個實體或實體間的一種聯系。規范的實質就是概念的單一化。

一個關系模式接著分解可以得到不同關系模式集合，也就是說分解方法不是惟一的。最小冗餘的要求必須以分解後的資料庫能夠表達原來資料庫所有信息為前提來實現。其根本目標是節省存儲空問，避免數據不一致性，提高對關系的操作效率，同時滿足應用需求。

⑵ 資料庫有幾種範式

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

圖學生表

圖學院表

⑶ 資料庫五大範式是什麼

第一範式（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）也應該構建它，否則就會有大量的數據冗餘。簡而言之，第三範式就是屬性不依賴於其它非主屬性。

⑷ 資料庫（mysql）關鍵知識

Mysql是目前互聯網使用最廣的關系資料庫，關系資料庫的本質是將問題分解為多個分類然後通過關系來查詢。 一個經典的問題是用戶借書，三張表，一個用戶，一個書，一個借書的關系表。當需要查詢某個用戶借書情況或者是書被那些人借了，就用關系查詢來實現。

關系資料庫範式

來自英文Normal form，簡稱NF。要想設計—個好的關系，必須使關系滿足一定的約束條件，滿足這些規范的資料庫是簡潔的、結構明晰的，同時，不會發生插入(insert)、刪除(delete)和更新(update)操作異常。總共有六種範式：第一範式（1NF）、第二範式（2NF）、 第三範式 （3NF）、巴斯-科德範式（BCNF）、 第四範式 (4NF）和 第五範式 （5NF，又稱完美範式）。

1NF是指資料庫表的每一列都是不可分割的原子數據項。2NF必須滿足1NF，要求資料庫表中的每行記錄必須可以被唯一地區分。3NF在2NF基礎上，任何非主 屬性 不依賴於其它非主屬性（在2NF基礎上消除傳遞依賴）。BCNF是在3NF基礎上，任何非主屬性不能對主鍵子集依賴（在3NF基礎上消除對主碼子集的依賴）， 滿足BCNF不再會有任何由於函數依賴導致的異常，但是我們還可能會遇到由於多值依賴導致的異常。4NF的定義很簡單：已經是BC範式，並且不包含多值依賴關系。5NF處理的是無損連接問題，這個範式基本沒有實際意義，因為無損連接很少出現，而且難以察覺。而域鍵範式試圖定義一個終極範式，該範式考慮所有的依賴和約束類型，但是實用價值也是最小的，只存在理論研究中。

Catalog和Schema

是資料庫對象命名空間中的層次，主要用來解決命名沖突的問題。從概念上說，一個資料庫系統包含多個Catalog，每個Catalog又包含多個Schema，而每個Schema又包含多個資料庫對象（表、視圖、欄位等）。但是Mysql的資料庫名就是Schema，不支持Catalog。

Mysql的資料庫引擎主要有兩種MyISAM和InnoDB，MyISAM支持全文檢索，InnoDB支持事務。

SQL中的通配符『%』代表任意字元出現任意次數。『_』代表任意字元出現一次。SQL與正則表達式結合查詢一般用在WHERE table_name REGEXP '^12.34'。子查詢是從里到外執行。

資料庫聯結（join）涉及到外鍵，外鍵是指一個表的列是另一個表的主鍵，那麼它就是外鍵。笛卡爾積聯結（不指定聯結條件時）生成的記錄條目是單純的第一個表的行乘以第二個表的列數。用得最多的是等值聯結也叫內部聯結。

高級聯結還有自連接，是指查詢中的兩張表是同一張表，它通常作為外部語句用來代替從相同表中檢索數據時使用的子查詢。自然聯結使每個列只返回一次。外部聯結是指聯結包含了那些在相關表中沒有關聯行的行。例如列出所有產品及其訂購數量，包括沒有人訂購的產品。LEFT OUTER JOIN指選擇左邊表的所有行。

組合查詢是指採用UNION等將兩個查詢結果取並集。

視圖是查看存儲在別處的數據的一種工具，它本身並不包含數據，因此表的數據修改了，視圖返回的數據也將隨之修改，因此如果使用了復雜或嵌套視圖會對性能有較大的影響。視圖的作用之一是隱藏復雜的SQL通常會涉及到聯結查詢。

存儲過程類似於批處理，包含了一條或多條SQL語句。語法：

CREATE PROCEDURE name（）
BEGIN
SQL
END
-------------------------
CALL name（）//來調用存儲過程

游標有DECLARE定義，游標與存儲過程是綁定的，存儲過程處理完成，游標就會消失。游標被打開後可以使用FETCH語句訪問每一行。

觸發器是在某個時間發生時自動執行某條SQL語句。語法：
CREATE TRIGGER name AFTER INSERT ON talbe_name FOR EACH ROW

事務處理可以維護資料庫的完整性，保證批量的操作要麼完全執行，要麼完全不執行。包括事務、回退、提交、保留點幾個關鍵術語。ROLLBACK只能在一個事務處理內使用。他不能回退CREATE和DROP操作。使用COMMIT保證事務提交。復雜的事務處理需要部分提交或回退，因此我們需要使用保留點SAVEPOINT。可以使用ROLLBACK TO savepoint_name。保留點越多越好。保留點在事務執行完成後自動釋放。

⑸ 資料庫中的1NF、2NF、3NF、BCNF、4NF、5NF是怎麼回事

範式，一般意義上是指關系資料庫的設計範式
設計關系資料庫時，遵從不同的規范要求，設計出合理的關系型資料庫，這些不同的規范要求被稱為不同的範式，各種範式呈遞次規范，越高的範式資料庫冗餘越小。
目前關系資料庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、巴德斯科範式（BCNF）、第四範式(4NF）和第五範式（5NF，又稱完美範式）。
滿足最低要求的範式是第一範式（1NF）。在第一範式的基礎上進一步滿足更多規范要求的稱為第二範式（2NF），其餘範式以次類推。一般說來，資料庫只需滿足第三範式(3NF）就行了。
第一範式（1NF）無重復的列所謂第一範式（1NF）是指在關系模型中，對域添加的一個規范要求，所有的域都應該是原子性的，即資料庫表的每一列都是不可分割的原子數據項，而不能是集合，數組，記錄等非原子數據項。即實體中的某個屬性有多個值時，必須拆分為不同的屬性。在符合第一範式（1NF）表中的每個域值只能是實體的一個屬性或一個屬性的一部分。簡而言之，第一範式就是無重復的域。
說明：在任何一個關系資料庫中，第一範式（1NF）是對關系模式的設計基本要求，一般設計中都必須滿足第一範式（1NF）。不過有些關系模型中突破了1NF的限制，這種稱為非1NF的關系模型。換句話說，是否必須滿足1NF的最低要求，主要依賴於所使用的關系模型。第二範式（2NF）屬性在1NF的基礎上，非碼屬性必須完全依賴於碼[在1NF基礎上消除非主屬性對主碼的部分函數依賴]
第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的，即滿足第二範式（2NF）必須先滿足第一範式（1NF）。第二範式（2NF）要求資料庫表中的每個實例或記錄必須可以被唯一地區分。選取一個能區分每個實體的屬性或屬性組，作為實體的唯一標識。例如在員工表中的身份證號碼即可實現每個一員工的區分，該身份證號碼即為候選鍵，任何一個候選鍵都可以被選作主鍵。在找不到候選鍵時，可額外增加屬性以實現區分，如果在員工關系中，沒有對其身份證號進行存儲，而姓名可能會在資料庫運行的某個時間重復，無法區分出實體時，設計辟如ID等不重復的編號以實現區分，被添加的編號或ID選作主鍵。（該主鍵的添加是在ER設計時添加，不是建庫時隨意添加）
第二範式（2NF）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列，以存儲各個實例的唯一標識。簡而言之，第二範式就是在第一範式的基礎上屬性完全依賴於主鍵。第三範式（3NF）屬性在1NF基礎上，任何非主屬性不依賴於其它非主屬性[在2NF基礎上消除傳遞依賴]
第三範式（3NF）是第二範式（2NF）的一個子集，即滿足第三範式（3NF）必須滿足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個關系中不包含已在其它關系已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那麼在的員工信息表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三範式（3NF）也應該構建它，否則就會有大量的數據冗餘。簡而言之，第三範式就是屬性不依賴於其它非主屬性，也就是在滿足2NF的基礎上，任何非主屬性不得傳遞依賴於主屬性。巴德斯科範式（BCNF）屬性在1NF基礎上，任何非主屬性不能對主鍵子集依賴[在3NF基礎上消除對主碼子集的依賴]
巴德斯科範式（BCNF）是第三範式（3NF）的一個子集，即滿足巴德斯科範式（BCNF）必須滿足第三範式（3NF）。通常情況下，巴德斯科範式被認為沒有新的設計規范加入，只是對第二範式與第三範式中設計規范要求更強，因而被認為是修正第三範式，也就是說，它事實上是對第三範式的修正，使資料庫冗餘度更小。這也是BCNF不被稱為第四範式的原因。某些書上，根據範式要求的遞增性將其稱之為第四範式是不規范，也是更讓人不容易理解的地方。而真正的第四範式，則是在設計規范中添加了對多值及依賴的要求。
對於BCNF，在主碼的任何一個真子集都不能決定於非主屬性。關系中U主碼，若U中的任何一個真子集X都不能決定於非主屬性Y，則該設計規范屬性BCNF。例如：在關系R中，U為主碼，A屬性是主碼中的一個屬性，若存在A->Y,Y為非主屬性，則該關系不屬性BCNF。
一般關系型資料庫設計中，達到BCNF就可以了！