⑴ 資料庫的三大範式
1、第一範式（1NF）
所謂第一範式（1NF）是指在關系模型中，對於添加的一個規范要求，所有的域都應該是原子性的，即資料庫表的每一列都是不可分割的原子數據項，而不能是集合，數組，記錄等非原子數據項。
即實體中的某個屬性有多個值時，必須拆分為不同的屬性。在符合第一範式（1NF）表中的每個域值只能是實體的一個屬性或一個屬性的一部分。簡而言之，第一範式就是無重復的域。
說明：在任何一個關系資料庫中，第一範式（1NF）是對關系模式的設計基本要求，一般設計中都必須滿足第一範式（1NF）。
不過有些關系模型中突破了1NF的限制，這種稱為非1NF的關系模型。換句話說，是否必須滿足1NF的最低要求，主要依賴於所使用的關系模型。
2、第二範式（2NF）
在1NF的基礎上，非碼屬性必須完全依賴於候選碼（在1NF基礎上消除非主屬性對主碼的部分函數依賴）
第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的，即滿足第二範式（2NF）必須先滿足第一範式（1NF）。
第二範式（2NF）要求資料庫表中的每個實例或記錄必須可以被唯一地區分。選取一個能區分每個實體的屬性或屬性組，作為實體的唯一標識。
例如在員工表中的身份證號碼即可實現每個一員工的區分，該身份證號碼即為候選鍵，任何一個候選鍵都可以被選作主鍵。
在找不到候選鍵時，可額外增加屬性以實現區分，如果在員工關系中，沒有對其身份證號進行存儲，而姓名可能會在資料庫運行的某個時間重復。
無法區分出實體時，設計辟如ID等不重復的編號以實現區分，被添加的編號或ID選作主鍵。（該主鍵的添加是在ER設計時添加，不是建庫時隨意添加）
第二範式（2NF）要求實體的屬性完全依賴於主關鍵字。
所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。
為實現區分通常需要為表加上一個列，以存儲各個實例的唯一標識。簡而言之，第二範式就是在第一範式的基礎上屬性完全依賴於主鍵。
3、第三範式（3NF）
在2NF基礎上，任何非主屬性不依賴於其它非主屬性（在2NF基礎上消除傳遞依賴）
第三範式（3NF）是第二範式（2NF）的一個子集，即滿足第三範式（3NF）必須滿足第二範式（2NF）。
簡而言之，第三範式（3NF）要求一個關系中不包含已在其它關系已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。
那麼在員工信息表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。
如果不存在部門信息表，則根據第三範式（3NF）也應該構建它，否則就會有大量的數據冗餘。
簡而言之，第三範式就是屬性不依賴於其它非主屬性，也就是在滿足2NF的基礎上，任何非主屬性不得傳遞依賴於主屬性。
(1)資料庫5範式擴展閱讀
設計關系資料庫時，遵從不同的規范要求，設計出合理的關系型資料庫，這些不同的規范要求被稱為不同的範式，各種範式呈遞次規范，越高的範式資料庫冗餘越小。
目前關系資料庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、巴斯-科德範式（BCNF）、第四範式(4NF）和第五範式（5NF，又稱完美範式）。
滿足最低要求的範式是第一範式（1NF）。在第一範式的基礎上進一步滿足更多規范要求的稱為第二範式（2NF），其餘範式以次類推。一般說來，資料庫只需滿足第三範式(3NF）就行了。
參考資料：網路-資料庫範式
⑵ 資料庫設計中的五大範式
對於表中的每一行，必須且僅僅有唯一的行值.在一行中的每一列僅有唯一的值並且具有原子性。（第一範式是通過把重復的組放到每個獨立的表中，把這些表通過一對多關聯聯系起來這種方式來消除重復組的。） 即無重復列。
第二範式要求非主鍵列是主鍵的子集， 非主鍵列活動必須完全依賴整個主鍵。 主鍵必須有唯一性的元素,一個主鍵可以由一個或更多的組成唯一值的列組成。一旦創建，主鍵無法改變，外鍵關聯一個表的主鍵。主外鍵關聯意味著一對多的關系。
（第二範式處理冗餘數據的刪除問題。當某張表中的信息依賴於該表中其它的不是主鍵部分的列的時候，通常會違反第二範式。）
第三範式要求 非主鍵列互不依賴。
（第三範式規則查找以消除沒有直接依賴於第一範式和第二範式形成的表的主鍵的屬性。我們為沒有與表的主鍵關聯的所有信息建立了一張新表。每張新表保存了來自源表的信息和它們所依賴的主鍵。）
第四範式 禁止主鍵列和非主鍵列一對多關系不受約束。
第五範式 將表分割成盡可能小的塊， 為了排除在表中所有的冗餘。
⑶ 資料庫三大範式是什麼
資料庫中三大範式的定義如下：
1、第一範式：
當關系模式R的所有屬性都不能在分解為更基本的數據單位時，稱R是滿足第一範式的，簡記為1NF。滿足第一範式是關系模式規范化的最低要求，否則，將有很多基本操作在這樣的關系模式中實現不了。
2、第二範式：
如果關系模式R滿足第一範式，並且R得所有非主屬性都完全依賴於R的每一個候選關鍵屬性，稱R滿足第二範式，簡記為2NF。
3、第三範式：
設R是一個滿足第一範式條件的關系模式，X是R的任意屬性集，如果X非傳遞依賴於R的任意一個候選關鍵字，稱R滿足第三範式，簡記為3NF。
範式簡介：
範式來自英文Normal form，簡稱NF。要想設計—個好的關系，必須使關系滿足一定的約束條件，此約束已經形成了規范，分成幾個等級，一級比一級要求得嚴格。
滿足這些規范的資料庫是簡潔的、結構明晰的，同時，不會發生插入(insert)、刪除(delete)和更新(update)操作異常。反之則是亂七八糟，不僅給資料庫的編程人員製造麻煩，而且面目可憎，可能存儲了大量不需要的冗餘信息。
關系資料庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、巴斯-科德範式（BCNF）、第四範式(4NF）和第五範式（5NF，又稱完美範式）。滿足最低要求的範式是第一範式（1NF）。在第一範式的基礎上進一步滿足更多規范要求的稱為第二範式（2NF），其餘範式以次類推。一般來說，資料庫只需滿足第三範式(3NF）就行了。
⑷ 資料庫設計遵守哪些範式
關系資料庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、巴德斯科範式（BCNF）、第四範式（4NF）和第五範式（5NF）。滿足最低要求的範式是第一範式（1NF）。在第一範式的基礎上進一步滿足更多要求的稱為第二範式（2NF），其餘範式以次類推。一般說來，資料庫只需滿足第三範式（3NF）就行了。
第一範式 無重復的列
第二範式 屬性完全依賴於主鍵
第三範式 屬性不能傳遞依賴於主屬性（屬性不依賴於其它非主鍵屬性）
⑸ 連接依賴 第五範式 資料庫性能
1.連接依賴和第五範式
2.連接依賴的定義
3.設關系模式R、Ri的屬性集是U、Ui，UiU(1≤i≤n).
若R每個容許的實例r均滿足r=∏U1(r)∞...∞∏Un(r)
則稱R滿足連接依賴，記作∞(R1,...,Rn).
若其中某個Ui＝U，則稱連接依賴是平凡連接依賴。
多值依賴也是連接依賴。
4.第五範式的定義
設關系模式R 、Ri的屬性集是U、Ui, UiU(1≤i≤n).
若每個連接依賴∞(R1,...,Rn)或是平凡連接依賴，或每個Ui均含候選鍵，則稱R滿足第五範式，簡記為5NF或PJNF.
例1：設關系模式R＝{A,B,C}僅滿足連接依賴∞(AB,BC).
因為ABC是唯一的候選鍵，故R不滿足5NF.但R滿足4NF.
例2：設關系模式S＝{ABC}所滿足的依賴約束集是
J＝{∞(AB,BC,AC),∞(AB,BC),B→C,C→BA}.
因為B和C都是S的候選鍵，故S滿足5NF。
4.資料庫性能：
性能調節的目的是通過將網路流通、磁碟 I/O 和 CPU 時間減到最小，使每個查詢的響應時間最短並最大限度地提高整個資料庫伺服器的吞吐量。為達到此目的，需要了解應用程序的需求和數據的邏輯和物理結構，並在相互沖突的資料庫使用之間（如聯機事務處理 (OLTP) 與決策支持）權衡。
⑹ SQL 資料庫 主鍵外鍵 還有第五範式的問題
關系型資料庫中的一條記錄中有若干個屬性，若其中某一個屬性組(注意是組)能唯一標識一條記錄，該屬性組就可以成為一個主鍵
主鍵和外鍵是把多個表組織為一個有效的關系資料庫的粘合劑。主鍵和外鍵的設計對物理資料庫的性能和可用性都有著決定性的影響。
必須將資料庫模式從理論上的邏輯設計轉換為實際的物理設計。而主鍵和外鍵的結構是這個設計過程的症結所在。一旦將所設計的資料庫用於了生產環境，就很難對這些鍵進行修改，所以在開發階段就設計好主鍵和外鍵就是非常必要和值得的。
主鍵：
關系資料庫依賴於主鍵---它是資料庫物理模式的基石。主鍵在物理層面上只有兩個用途：
惟一地標識一行。
作為一個可以被外鍵有效引用的對象。
基於以上這兩個用途，下面給出了我在設計物理層面的主鍵時所遵循的一些原則：
主鍵應當是對用戶沒有意義的。如果用戶看到了一個表示多對多關系的連接表中的數據，並抱怨它沒有什麼用處，那就證明它的主鍵設計地很好。
主鍵應該是單列的，以便提高連接和篩選操作的效率。
註：使用復合鍵的人通常有兩個理由為自己開脫，而這兩個理由都是錯誤的。其一是主鍵應當具有實際意義，然而，讓主鍵具有意義只不過是給人為地破壞資料庫提供了方便。其二是利用這種方法可以在描述多對多關系的連接表中使用兩個外部鍵來作為主鍵，我也反對這種做法，理由是：復合主鍵常常導致不良的外鍵，即當連接表成為另一個從表的主表，而依據上面的第二種方法成為這個表主鍵的一部分，然，這個表又有可能再成為其它從表的主表，其主鍵又有可能成了其它從表主鍵的一部分，如此傳遞下去，越靠後的從表，其主鍵將會包含越多的列了。
永遠也不要更新主鍵。實際上，因為主鍵除了惟一地標識一行之外，再沒有其他的用途了，所以也就沒有理由去對它更新。如果主鍵需要更新，則說明主鍵應對用戶無意義的原則被違反了。
第一範式（1NF）：當關系模式R的所有屬性都不能分解更基本的數據元素時，即R的所有屬性都處於原子特徵時，就叫做第一範式（1NF）。
例如：我們在關於員工的關系模式中，如果工資這項屬性可以再分成基本工資和獎金的話，那麼它就不屬性第一範式，如果不能再分的話就屬性第一範式，當然，需要員工這個關系模式里所有屬性都滿足這個條件。
第二範式（2NF）：如果關系模式R在滿足第一範式的基礎下，並且所有R的所有非主屬性都完全依賴於R（關於依賴自己查詢）的每一個候選關鍵字屬性，則叫做R滿足第二範式。
例如：在一個圖書管理系統中，存在如下關系模式：R=R（讀者編號，圖書編號，工作單位，借閱日期，歸還日期），在這個關系模式中，有兩個候選主屬性，（讀者編號，圖書編號），而工作單位這個屬性只需要讀者編號這個屬性就能確定，所以在這個它並不是完全的依賴於每一個候選關鍵屬性，所以它並不是第二範式。
第三範式（3NF）：假設R是一個滿足1NF的關系模式，X是R的任意屬性組，如果X非傳遞依賴於R的任意一個候選關鍵屬性，稱R滿足第三範式。
什麼叫傳遞依賴，比如，人->（男人，女人），男人->(小孩，大人，老人），這里因為小孩是男人，所以推出小孩也是人，（這個例子不是很恰當）。那怎麼來理解第三範式，我們同樣舉個例子來理解下
例如：假如KFC這個公司，它在北京有100家分店，那麼我們記錄它的時候，就會這樣記錄R=R（公司注冊號，法人代表，注冊城市，所在省），如果按照第一範式，我們需要些100次注冊城市，這就導致了數據的高度冗餘，所以我們這里想要用第三範式，公司注冊號->注冊城市，注冊城市->所在省，這里就導致了R的傳遞依賴，所以我們這里並不能用第三範式。
再接下來就是Boyce-Codd範式和第四、第五範式了，這三個範式都是這前三個範式的基礎上增加更合理的規范性而來的，所以符合第三範式以上的範式的關系模式才能稱之為標準的關系模式。
Boyce-Codd又簡稱BCNF，它比第三範式具有更強的規范性，或者又叫做約束性，符合BCNF的關系模式一定符合第三範式，但是反過來卻不一定成立。很多情況下，第三範式就是BCNF，但是二者是不等價的。
第四範式（4NF）：禁止主屬性和非主屬性一對多的關系不受約束，這個就有點涉及到了UML，不多講。
第五範式（5NF）：將表盡可能的分割成小的表，使之不存在冗餘。
⑺ 資料庫範式問題！！
資料庫中的範式問題．理論和時間要結合．
第一範式：當且僅當一個關系變數的所有的合法的值中，每一個元組的每個屬性只含有
一個值時，該關系變數屬於1 N F。
第二範式：（假定只有一個候選碼，且該候選碼是主碼）當且僅當一個關系變數屬於
1 N F，且該關系變數的每一個非碼屬性都完全函數依賴於主碼時，該關系變數屬於2 N F。
第三範式（假定關系變數只有一個候選碼，且該候選碼是主碼）：當且僅當一個關系變
量屬於2 N F且該關系變數的所有非碼屬性都不傳遞依賴於主碼時，該關系變數屬於3 N F。
注意：「不傳遞依賴」蘊涵不互相依賴，從這個意義上說，該術語的解釋和本節開始的
解釋一樣。
多值依賴： R是一個關系變數， A、B和C是R的屬性的子集。那麼我們說B多值依賴於A
—符號如下：A→→B（讀做「A多值決定B」，或簡單地稱為「 A雙箭頭B」）—當且僅當
對於每一個可能的合法R值，B值的集合對於給定的一組（ A值，C值）只依賴於A的值，而與
C的值無關。
很容易看出—參見[ 1 2 . 1 3 ]—對於給定的變數R{A,B,C}，多值依賴A→→B存在，當且
僅當多值依賴A→→C也存在。這樣M V D總是成對的一起出現。因此通常用一種語句來表示它
們：A→→B|C。例如：C O U R S E→→T E A C H E R | T E X T。
在前面我們已經提到，多值依賴是一般化的函數依賴，在這種意義上講每一個F D都是
M V D。更精確地說，一個F D就是一個只有一個依賴值（右邊的）與一個給定的決定值相符合
的M V D。因此，如果A→B，那麼一定A→→B。
第四範式：只要存在R的屬性的子集A和B，滿足非平凡的多值依賴，並且R的所有屬
性也都函數依賴於A，這樣的關系變數R滿足4 N F。
換句話說，在R中的唯一的非平凡的依賴（函數依賴或多值依賴）是K→→X形式（例如：
一個超碼K對另一個屬性X的函數依賴）。同樣，如果R是B C N F，並且R中的所有非平凡的多值
依賴事實上都是「非碼函數依賴（ FDs out of key）」，則R是4 N F的。因此特別要注意的是，
4 N F包含了B C N F。
第五範式：一個關系變數R是第五範式—也稱為投影-連接範式（ P J / N F）—當且僅當
R的每一個非平凡的連接依賴都被R的候選碼所蘊涵。
注意：下面解釋一下對於一個J D「被候選碼所蘊涵」的含義。
關系變數S P J並不是5 N F；它滿足一個特定的連接依賴，即3 D約束。這顯然沒有被其唯一
的候選碼（這個候選碼是其所有的屬性值的組合）所蘊涵。可以表示其區別如下：關系變數
S P J並不是5 N F，因為（ a）它是可以被3分解的；（b）可3分解性並沒有為其{ S #，P #，J # }是
一個候選碼的事實所蘊涵。相反， 3分解後，由於三個投影S P、P J和J S根本不包括任何（非平
凡的）連接依賴，因此它們都是5 N F。
⑻ 簡述資料庫的三大範式和五大約束
範式書上講解太拗口，自己總結一下：
第一範式：數據表中的每一列（每個欄位）必須是不可拆分的最小單元,不允許存在隱藏欄位,屬性保持「原子性」（最大細分的二維表）
第二範式：第一範式基礎上要有主鍵，所有列都必須依賴於主鍵，而不能有任何一列與主鍵沒有關系，也就是說一個表只描述一件事情（相當於這行闡述的是一個人時，你不能加一列說明天氣）
第三範式：滿足第二範式，表中的每一列只與主鍵直接相關而不是間接相關，（表中的每一列只能依賴於主鍵）
正規化範式（BCDF）：所有表中的決定因素必須是一個候選鍵，如果只有一個候選鍵，那麼就和第三範式是一樣的。
有第四第五範式，更高的範式是為了解決數據冗餘問題，但可以通過其他辦法達到。所以一般用不到
五大約束：
1. primary KEY :設置主鍵約束；
2. UNIQUE ：設置唯一性約束，不能有重復值；
3. DEFAULT 默認值約束，height DOUBLE(3,2)DEFAULT 1.2 height不輸入是默認為1,2
4. NOT NULL ：設置非空約束，該欄位不能為空；
5. FOREIGN key :設置外鍵約束。
⑼ 資料庫有幾種範式
目前關系資料庫有六種範式，即第一範式（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範式，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個，而不是多個）
（例如假設有一個人事資料的數據表，我們根據表中記錄的一個人的姓名，我們可以查到他的年齡即有： 姓名->年齡。在沒有同名存在的情況下，姓名就是這個表的候選鍵（碼），因為姓名可以唯一確定一條記錄的其他屬性，例如：姓名->(性別、年齡、職位)，同時我們把姓名選為該表的主鍵（含主屬性）。姓名以外的其他屬性即為非主屬性。有時候一個表可以有多個候選鍵，則需要選擇其中一組作為主鍵，所有候選鍵包括的屬性都是主屬性。）
以上內容都是根據自己理解信手敲出。並沒有嚴謹的校對教科書的概念。如有疏漏錯誤實屬正常，如有人補漏改錯不勝榮幸。